灰色後門

在過去，類似下面的程式碼很常被用在取得元素位置 function findPos ( obj ) {      var left , top ;      left = top = 0 ;      if ( obj . offsetParent ) {          do {              left += obj . offsetLeft ;              top  += obj . offsetTop ;          } while ( obj = obj . offsetParent ) ;      }      return {          x : left ,          y : top ,      } ; } ; objPos = findPos ( document . getElementById ( 'test' ) ) ; alert ( "x:" + objPos . x + " | y:" + objPos . y ) ; offsetParent會回傳距離傳入物件最近 的容器 這個屬性會依傳入物件及其父元素是否有設定 postion屬性(absolute、relative)變動 一般沒有指定定位的情形下，最外層的offsetParent就是document.body 這個方法的成本偏大，特別是若需進行較多次迴圈運算時 使用時將結果儲存為 local 變數會是比較好的處理作法 既然說了在過去，表示這個做法一定有那裡不夠好 除了上述提過會使用較多的資源來進行計算外 offsetParent也有可能有相容性的疑慮，而卷軸捲...

原文 為有物報告翻譯自Dropbox的文章 恭喜 Dropbox，達到使 用者人數一億人 ，預估營收也來到美金5億（台幣150億）。去年 Dropbox 被投資人估值約在40億美金（1200億台幣）左右，不論從各方面來看都是一個超級成功的創業故事。

談到壓縮資料時必須先有個概念 壓縮資料可以減少資料的傳輸成本，但相對的會增加計算上的成本 CPU可能會因為壓縮的工作而降低系統的整體處理能力，使用上必須依需求選擇 當然現行系統主要的資料傳遞需求仰賴網路，通常啟用壓縮會是較好的選擇 以網路應用實務上的一般情況來說，效率的瓶頸主要是資料的傳輸 上圖是分別以3G和4G通信取得 20KB 資料的時間，可以看出資料量大時的影響 另一個要點則是行動裝置的電量，行動裝置使用網路時會大幅減少其電池使用時間

Glassfish 是有 open source 版本的 Java EE Server 另一個在Java EE開發中常用到的Tomcat相較之下只涵蓋了web container的部分 以支援的規格、後台的豐富性來說，這是Glassfish較出色的部分 雖然Glassfish功能較多也較強大些，但配置的設定也會較為複雜 如果開發上用不到這麼多東西的話，較輕量且被大量運用的Tomcat會是較好的選擇

標題其實是想說 elementA.onclick = func; 這樣一回事 之前都已經看慣&習慣這個寫法倒也沒有想太多 直到今天寫了一個要輸入參數的function function specialSetting(obj){ ....   //original code  } 然後就直覺寫上了 elementA.onclick = specialSetting(elementA); 畢竟一開始學寫JavaScript都是 <div ... onClick="specialSetting(this);" > 這樣開始 然後執行時就發現函式一開始就馬上被呼叫一次... 仔細想想才覺得應該是圓括號的關係 猜測 JavaScript 的執行方式是 elementA.onclick =  specialSetting(elementA) ; 先執行一次呼叫 specialSetting(obj); 之後才綁定事件 function在JavaScript中是物件 elementA.onclick = specialSetting;  表明事件綁了個函式物件，而不是要立刻執行函式 那如果要傳入參數呢? 改用匿名函式就好了 elementA.onclick = functionn(){ specialSetting(elementA); }; 回想要傳入事件作參數給函式的作法是 elementA.onclick = functionn(evt){ func(); }; 從這裡其實就看得出端倪了

*修改自網路文章，文章源頭不確定 HTTP 壓縮可以大大提高瀏覽網站的速度 它的原理是，在客戶端請求網頁後，從Server將網頁文件壓縮 再下載到Client，由Client的瀏覽器負責解壓縮並瀏覽 相對於普通的瀏覽過程HTML ,CSS,JavaScript , Text ，它可以節省40%左右的流量 更為重要的是，它可以對動態生成的 包括CGI、PHP、JSP、ASP、Servlet、SHTML等輸出的網頁也能進行壓縮

StringBuilder 和 StringBuffer 底層都使用char[]來做為資料儲存庫 而且常常需要調整容量大小 調整容量大小的方法就是配置一個容量更大的新的char[] 接著將舊資料複製過來後再拋棄舊的char[] 類似的調整過程也可能發生在使用陣列當作底層資料儲存庫的Java SE Collection 依OpenJDK的實作方式 當儲存文字超過底層資料儲存庫的容量時 會配置一個原本容量兩倍大的新char陣列，而底層的char陣列大小預設為16 實務上很少StringBuffer 或StringBuilder的物件最後只使用了16以內的char元素 要避免StringBuffer 或StringBuilder調整大小的動作，我們可以指定大小給其建構子 如ArrayList、Vector、HashMap和ConcurrenthashMap等Collections因使用陣列儲存資料 同StringBuffer 或StringBuilder，很容易在增加元素時引發調整大小的動作 需要額外的CPU週期來配置新陣列、複製舊陣列的資料，將來也需要回收舊陣列 以HashMap為例，預設建構子的容量是16筆資料，也是經常不夠用 其資料擴張時也是使用原本陣列2倍大的新陣列 又因每次調整時都要計算雜湊(hash)值，當資料量大時耗費的成本也更驚人 遇到這種情形時，比較好的處理方式就是直接將計算容量的算式傳給HashMap的建構子