看完四個 js 的分析後，可以看出來一些 pattern：

• 用 async script。Google 曾經介紹 Google Analytics 可以使用 async script：「Google Analytics Launches Asynchronous Tracking」。
• 當使用 async script 時無法使用 document.write (會有奇怪的結果)，就算不是 async script 也應該儘量避免使用。常見的方法是建立一個帶有 id 的 div，然後在 script 內用 document.getElementById() 或是等價的方式取得後在裡面插入元素，或是直接修改 innerHTML。
• 用 div 再修改的模式時，如果可以先確定 div 的大小，最好在 class 與對應的 CSS 上先定義 (像是廣告的版位)，可以避免頁面 re-layout。
• 在 Cache-Control 內設定夠長的 max-age (尤其是幾乎不會改動的圖片)。
• 如果是 tracking 機制，應該傳回 204 而非 200。

這個計畫應該還會再繼續分析，有興趣的人可以訂 RSS 看。

由於這次改寫避免使用 unsafeWindow 以及複雜的 GM_* 函式，在 Google Chrome 除了遇到一個小問題之外 (可以寫一段 code workaround)，目前跑起來還蠻正常的。

參考：「Wretch Album Expander」以及 GitHub 上的「gslin’s albumexpander」。

另外一個想法是透過 FTPS 抓檔案，有不少 server software 都有支援 FTPS。在找 bsdftpd-ssl 的資料時找到以前寫的「在 FreeBSD 上支援 SSL 的 ftpd」這篇，結果發現這篇文章是因為當初 bsdftpd-ssl 在 FreeBSD 上無法編譯而改用 ftpd-tls 所寫的。現在這個問題已經解決了，但找不到之前用 bsdftpd-ssl 所設的設定可以抄，只好再 man ftpd-ssl 看一次參數。

除了先到 ports 的 ftp/bsdftpd-ssl 目錄下安裝外，還需要產生 self-signed certification。產生的步驟可以參考「OpenSSL Command-Line HOWTO」這篇的「How do I generate a self-signed certificate?」這個部份。把 certification 輸出到 /etc/ssl/certs/ftpd.pem (如果目錄不存在則建立一個)，並把檔案權限改成 600 或是 400。

再來是設定 /etc/rc.conf.local (bsdftpd-ssl 不屬於 system 內建軟體，所以放到 local)，增加兩行：

bsdftpd_ssl_enable="YES"
bsdftpd_ssl_flags="-D -h -l -p /var/run/ftpd.pid -z secure"

然後用 /usr/local/etc/rc.d/bsdftpd-ssl start 跑起來就可以了。測試時要注意 active 與 passive 以及防火牆的設定，在 debug 時除了錯誤訊息外，可以用 sockstat | grep ftpd 以及 tcpdump 觀察。

實際抓一個 500MB 的檔案，到最後面可以跑到 295KB/sec，比起 SFTP 快上不少。

不過 lenny (5.0.0) 從去年二月到現在也已經過了一年，雖然一直有在更新 (現在是 5.0.4)，但為了穩定性，並不是所有的軟體都有更新。印象中有個計畫是專門解決這個問題的，可以讓你在 stable 使用新版，但不是整個系統都換到 testing 或 unstable。

在印象中跟 “backport” 這個關鍵字有關，翻了以後找到 Debian Backports，看起來就是我要的…

依照「instructions [Debian Backports]」操作，直接把 entry 加到 /etc/apt/sources.list 內，用 apt-get update 更新一次，這時候會出現不認得 public key，不管他直接 apt-get install debian-backports-keyring 就收工了。測過沒問題後，就在「Backports.org worldwide mirror sites」這邊找亞洲區的 mirror site，看起來只有日本有做，改過去再測一次 update，沒問題收工…

由於預設仍然會使用 lenny 內的套件，如果要裝 backport 內的東西，需要用 -t lenny-backports 讓 apt-get 或是 aptitude 知道。

另外，在「Diffs between lenny-backports and squeeze」這邊可以看到 lenny-backports 與 squeeze (目前的 testing) 的差距。

在 FreeBSD 上可以利用 httpready 把一些事情丟到 kernel module 處理：

listen 80 default accept_filter=httpready;

httpready 參數必須設定在有 default 的 listen 之上，而且必須在 default 之後，不然會回報設定錯誤。

server_tokens 也應該關掉，除了 security 理由外，另外一個很簡單的理由是，可以少送 7bytes…：

server_tokens off;

有人曾經建議 Mozilla 直接使用系統的 codec 避開這個問題，但 Mozilla 認為這種作法跟 ActiveX 一樣，直接把系統不安全的部份暴露在 Internet 上，當 codec 有漏洞時就會受到影響。(我覺得專利問題還是比較嚴重)

因為這些原因，Mozilla 選擇內建 Theora 而非使用 H.264。最早支援 video tag 的 Opera 也是選擇 Theora。

Google 與 Apple 手上都有與 H.264 相關的專利可以丟進專利池而取得免費使用權，所以 Google Chrome 以及 Safari 都是支援 H.264。

Update：如同 Azel 在 comment 所講的，Google 沒有專利丟到專利池內，而是購買授權。(參考 AVC/H.264 Licensors 與 AVC/H.264 Licensees 資訊)

除了專利問題外，有些人研究 H.264 與 Theora 在技術上到底哪個比較好，如果兩個差不多的話，沒有必要用 H.264 讓別人綁死。

在 OSNews 的「Comparing Theora to H264」裡講到有三篇測試文章。

最早的是「YouTube / Ogg/Theora comparison」這篇，這篇不是講 H.264，而是 YouTube 使用的 H.263。這篇文章之前有上過 Slashdot，但當時看過以後有個印象而已，因為他用的方法是肉眼，而非科學方法。雖然如此，還是很明顯可以看出來在 500Kbps 以下時 Theora 比 YouTube 的 H.263 好不少。

最近的兩篇分別是「Ogg vs H264 – Round One」以及「Video encoder comparison」，後面這篇是我第一次看到有人用科學方法 SSIM 計算壓縮前後的相似性。不管哪一篇，都可以主觀或客觀的看出來品質上 H.264 大勝 Theora，而壓與解的速度則是反過來。

不過下面的 comment 提到 Theora 目前真正在開發的不在 trunk 內，而是在其他 branch 下，另外 Theora 如果設定 bitrate，會是 CBR mode，品質會比 VBR mode 差。實際要比較每個 codec 最好的情況應該要跑 2-pass。

過幾天應該會有新的 report 出來，到時候再來看差異…

他們討論到 IE 到目前所有版本的 cookie 都不支援 max-age 參數，所以有個避免 MySQL master/slave replication lag 的技巧在 IE 上沒辦法用的很好：當寫入資料時 (例：使用者發表文章)，server 會設定一組 30secs 的 cookie，當 web server 收到這個 cookie 時會用 MySQL master server。

workaround 不難做，本來是只有設定 cookie，現在把把 server timestamp 與 signature (用 HMAC) 都放到 cookie 後就可以了，當 web server 收到後可以驗證並且決定是否要用 master server。

其他的限制可以看一看留個印象，之後遇到時會比較有機會猜到…

Eventual consistency 以 CAP theorem 中的 Consistency 妥協，試著解決 scale 問題，但缺點是 stale read (可能會讀到舊資料)，對要求比較嚴謹的子系統 (像是遊戲內的各種點數，身上帶的金幣之類的) 會很麻煩，而對於要求更嚴謹的系統 (像是商品搶購時的「剩餘數量」) 幾乎無法直接使用。

像是 Colin Percival 曾經解釋他得在 S3 與 SimpleDB 上做不少 workaround：「How Tarsnap uses Amazon Web Services」以確保資料正確性。

AWS SimpleDB 這次提供了新的功能，要求寫入時一定要等到 consistent 才 return，將 consistent 的權限放給上層 application 決定，開發者可以自己拿捏。

DRBD 是一套以 block-level replication 為基礎提昇可靠度的軟體，有時候為了方便解釋，也被稱為 Network RAID1，常搭配 Heartbeat 或是其後繼的 Pacemaker 偵測節點是否還活著，並在必要時自動切換。

由於 DRBD 已經出來很久了，而且又是以 GPLv2 釋出，早期有不少文件介紹如何使用 DRBD 達到 HA，算是一種已經被摸熟的方案。

另外是 FreeBSD 的 HAST Project 到一個階段，被 commit 到 -HEAD 了：「Please welcome HAST – Highly Avalable Storage.」，再加上 block-level replication 會需要 Filesystem 快速恢復的 SUJ (SU+J) 也在一月底放 source code 先讓自願者測試，一口氣補了 HA 領域兩塊重要的缺陷。

不過依照慣例，新東西都不太穩定… 玩玩還可以，如果是要跑 HA 的話等一兩個版本會比較好。

非 Comcast 用戶沒有辦法參與，丟 query 過去會收到：

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 54496
;; flags: qr rd ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0