幹壞事是進步最大的原動力
兩個不小的軟體都出新版…
Mozilla Firefox 3.5 正式版昨天放出來了，JavaScript 的速度再次提昇，另外有不少新功能，以台灣的普及率，大約等兩年後看普及狀況再決定能不能用。
另外一個是 PHP 5.3 第一個的正式版 5.3.0 也是出了，可以在 PHP 5 ChangeLog 看到比較詳細的說明。照之前國外測試的結果，除了使用過舊的 deprecated function 外，應該不會造成目前的程式不能動，不過還是要測過才會知道…
比較新的功能是 namespace，雖然用 backslash (就是「\」這個符號) 大家看了都很囧，不過畢竟是有 namespace 了，PHP library & framework 總算可以用 namespace 解決命名的問題。
依照「mod_wsgi 與 .htaccess」的設定設好後，在 index.py 內參考「Integration With CherryPy」這篇文章的範例就會動了，可以用 ab 或是 httperf 測試看看效能如何。
另外 Robert E Brewer 在 PyCon 2009 – Chicago 上講的「Introduction to CherryPy (#90)」(包含影片) 也蠻適合剛碰 CherryPy 的人看。
mod_wsgi 是 apache 上 PEP-333 的實做軟體，使用 Python 開發 web application 的人不用知道怎麼介接。
既然是 .htaccess，apache 的部份就不講了。
Update：修正 mod_rewrite 的部份。
先從最簡單的「所有 request 都丟給 index.py」開始：
SetHandler wsgi-script
RewriteEngine on
RewriteBase /~gslin/py/
RewriteRule ^index.py$ - [L]
RewriteRule ^(.*)$ index.py/$1 [L]
如果不希望連靜態檔案都透過 index.py 處理 (像是 robots.txt)，要做兩件事情。第一件是限制 wsgi-script 的範圍：
<Files *.py>
SetHandler wsgi-script
</Files>
然後修改 mod_rewrite 的條件，只有檔案不存在的 request 才丟給 index.py：
RewriteEngine on
RewriteBase /~gslin/py/
RewriteRule ^index.py$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.py/$1 [L]
不會很難，不過還是寫下來，以後應該會找到自己的文章…
只貼 code… (還蠻常用到的技巧)
(function($){
// you can use $ even if jQuery.noConflict()...
})(jQuery);
用 Google 翻資料，結果三月初的時候有人試著 benchmark，結果還蠻讓人意外：「Performance comparison of Thrift, JSON and Protocol Buffers」。
結論是 JSON 在速度上不會輸給 Protocol Buffers 與 Thrift。討論出來的原因是因為 Protocol Buffers 與 Thrift 的功能比 JSON 多出太多。
不過我應該會用 JSON 寫東西吧，畢竟是個 open standard…
之前在「WordPress 的 exporter」這篇提到 WordPress 的匯出程式很糟。最後我是直接把用不到的欄位用 preg_replace() 幹掉，避免 XML library 因為語法錯誤而無法匯入。
雖然暫時解決了，不過還是看看目前的進度，發現有計劃要以 XML library 改寫，但是沒人跳下去寫：「make export/import output valid xml and parse xml using simplexml」，這個計畫大概是遙遙無期… XD
WordPress 的 exporter 做的實在是很沒誠意…
WordPress 的 exporter 是 XML 格式，說更實際一點是 RSS 2.0 + 自訂的 namespace。不過 WordPress 實際上是自己把欄位內容 echo 出來，於是就有一卡車欄位沒有 escape…
首先是踩到「Exporter does not escape url」這個地雷，沒有對 <wp:comment_author_url></wp:comment_author_url> 這個欄位 escape，於是當 url 帶有 & 時就… *boom*
幫 WordPress patch 後又遇到另外一個問題：「wp:meta_value does not escape correctly」，這次換成 <wp:meta_value></wp:meta_value> 沒有 escape…
到底是怎樣啊… 我猜還會再中某些欄位地雷 \_/
FreeBSD 前陣子才將 Perl 5.10 放入 FreeBSD Ports System 內 (Perl 5.10 在 2007/12/18 發行，到 2009 年三月才進 ports…)
不管怎麼樣，總是進 ports 了… 得測試看看要怎麼從 5.8.9 升級到 5.10.0。在 /usr/ports/UPDATING 提供了 portupgrade 與 portmaster 的升級方式：
20080328:
AFFECTS: users of lang/perl*
AUTHOR: skv@FreeBSD.org
lang/perl5.10 is out. If you want to switch to it from, for example
lang/perl5.8, that is:
Portupgrade users:
0) Fix pkgdb.db (for safety):
pkgdb -Ff
1) Reinstall perl with new 5.10:
portupgrade -o lang/perl5.10 -f perl-5.8.\*
2) Reinstall everything that depends on Perl:
portupgrade -fr perl
Portmaster users:
portmaster -o lang/perl5.10 lang/perl5.8
portmaster -r perl\*
原則上照著 UPDATING 做就可以，不過 portmaster 的部份似乎是錯的 (看起來是軟體 bug)，用 -r 並不會將相依 perl-5.10.0 的 ports 強制更新。
後來還是先 portmaster -BDuw p5\*，然後再看還有哪些東西在 /usr/local/lib/perl5/site_perl/5.8.9 下面，手動跑 portmaster 重新安裝。
在「Progress with clang」這篇看到，由於最近有人將 FreeBSD source 視為一個超大的 test case，依照 FreeBSD compile 出來的結果不斷修正 clang 的 bug，並且補上缺少的功能，使得由 FreeBSD 衍生出來的 DragonFly BSD 也受益…
現在可以用 clang 編 GENERIC kernel 以及 buildworld 了 (只需要一個 patch)。這陣子 clang 的聲勢愈來愈大了…
前陣子把公司裡所有的 repository 全部換成 Git 了…
由於 Git 與 Subversion/Mercurial 運作的方法不一樣，換完後也跟著換 Workflow。
原先 Subversion (1.5+) 對 branch 的 Workflow：
branches 與 trunk 兩個目錄，平常測試時都在 trunk 裡測試，測完後 merge 到 branches 再 deploy 到 production 主機上。用 Subversion 用一陣子，受不了他的速度後，有陣子在評估 Mercurial 與 Git。當時一直搞不定 Git 的 hook，所以就選了 Mercurial，所以有些 repository 用 Mercurial 開發了一陣子…
在 Mercurial 上，local branch 的功能一直沒搞定，所以會轉成 Mercurial 的 repository 都是不需要 local branch 的功能。當時從 Subversion 換 Mercurial 速度快了許多。
最後全部換成 Git 的主要原因是需要 local branch (anonymous branch)，branch 的 Workflow 變成：
速度比 Mercurial 又快了不少，local branch 也成熟，gitweb 畫面還蠻好看也是主因 (也許會試看看 cgit，畫面看起來也不錯)，這次換完後大家都還蠻開心的？
Subversion 轉換成 Git 的工具是 git-svn，把 branch 抓下來後去掉 Subversion 的資訊，直接將 master branch 推上 server。
Mercurial 轉 Git 用的是 fast-export，轉的速度相當快。轉完後要更改 branch 名稱，再將 master branch 推上 server。