The Third Bit 驚呼一聲 Oh My God It’s Django!：

Guido just pronounced: Django is the web framework

• Won’t be part of the core, but will be as “standard” as PIL or NumPy
• This was not what I expected the outcome of my talk would be, but hey, I’ll take it ;-)
• He hopes that Django and TurboGears will converge

不過，Kevin Dangoor 聞言是相當失望。我雖然懶得學 TurboGears，但也不是很想見到獨尊一家的情形，更何況 TurboGears 和 Django 的整合可能會比讓 Django 1.0 發行還花時間。各種不同的系統與框架必然最符合創作團隊本身與期待的需求，可以想像 Dangoor 對 Python BDFL 的這項說法會有很複雜的感受。

然而 Django 確實是一套好系統。Gustavo Picón (Feedjack 的作者) 對此事也作了一些評論與分析，可讓讀者多了解一點 GvR 的想法。我沒有資格作什麼分析或評斷，但會繼續期待 Django 以及其它 Python 網頁程設框架往後的蓬勃發展。

http://wiki.debian.org/DebianPythonFAQ

Python 2.4 已經是 sid 裡的預設版本了，不過 etch 還在用 2.3。想在 etch 裡用 2.4 版的 Python，還是得下 python2.4。

不過，etch 轉換成 2.4 版的時間，應該近了。

Ghost in the Shell: Stand Alone Complex Solid State Society.

這年頭作品名字怎麼都愈取愈長啊？啊？！Ghost in the Shell, Ghost in the Shell Stand Alone Complex, Ghost in the Shell Stand Alone Complex 2nd GIG, 現在是 Ghost in the Shell Stand Alone Complex Solid State Society.

十個單字組成的片名，這有劇情片的氣勢喔。GitS:SAC:SSS 將在日本於 2006, Sep. 1 上映，耗資三億六千萬日圓 (合美金三百二十萬)，片長 105 分鐘。近期不會去日本，所以真正重要的日期資訊是發行二區 DVD 的 Nov. 24。

對 Innocence 不滿意的個體如我，對由神山健治執導，SAC 系列的初次電影版，懷抱著無比期待的心情，等著 20061124 的到來。等不及了，請看 trailer。

啊啊，作點筆記：

$ python2.4 -c \
 "from compileall import compile_dir;compile_dir('.')"

Python 標準程式庫的 compileall 模組提供了兩個函式：compile_path 和 compile_dir。compile_path 很猛，會把 sys.path 裡找得到的所有路徑下的 .py 都編成 .pyc，有點太具侵略性了一點。compile_dir 對 Python 程式寫手可能比較好用點。

在開發 Python 程式的時候，用 compile_dir 可以把任意目錄下的所有 .py 編譯成 .pyc。上述的 command line one liner 會遞迴地把目前目錄下的所有 .py 編譯為 .pyc。應用時機？開發中版本的 web 應用程式 (httpd 使用者與 Python 程式擁有者不同時，因為權限因素，.pyc 是不會自動產生的)。

我早該想到，桃果汁是現實中的產品...

雖然看起來還不會太噁心，不過很難想象現實生活中會有人喜歡這種作法的飲料；感覺上和煮過的可樂一樣怪。

唔，話說森岡大師寫得是愈來愈慢了，戦旗 4 已經用了那麼多時間來蘊釀，結果戦旗 5 還是在慢慢生。什麼時候看得到呢。

休假，可以作些放鬆的事情。不過休息一下之後還是得辦正事 :(

為了提振精神，我決定把放著很久沒動的本 blog 程式作點昇級。本站 (http://blog.seety.org/everydaywork/，下同) 自從改用 Django 重新設計以來，一直是用 FastCGI 進行佈署的。在最近發行的 Django 0.95 中，也包含了 magic-removal 之後加入的 FastCGI 支援。當然，Django trunk 早就有這東西了，不過直到今天以前，我都還在用舊的 fcgi.py。

Django 0.95 不但已整合了 FastCGI 佈署程式，也寫好了 FastCGI 佈署文件，FastCGI 也成了 Django 建議的佈署方式之一。在某些情況下，用 FastCGI 佈署的動態程式會跑得比用 mod_python 佈署下的程式有效率，該文件有提到這一點。

好，在使用 django.core.servers.fastcgi 模組 (Django 中的 FastCGI 佈署支援) 前，要先安裝 flup。你用 Debian testing/unstable 的話，直接：

$ apt-get install python-flup

就好了 (that's one of the reasons for why I love Debian)。然後，在你的 htdoc 目錄下 (我用 Apache2) 開一個 blahblah.fcgi wrapper script 檔，在裡面寫些 Python script：

!/usr/bin/env python2.4
import sys, os

sys.path.append( '/path/to/your/packages' )
os.environ['DJANGO_SETTINGS_MODULE'] = \
    'yoursite.settings'

from django.core.srevers.fastcgi import fastcgi
runfastcgi([ "method=threaded", "daemonize=false" ])

Django 的文件裡有更詳細的說明。本來，看他們的說明應該就足夠了，遺憾的是，Django 提供的 .fcgi wrapper 裡使用的

sys.path.insert(0, "/home/user/python")

寫法，有時候會出問題。我如果像 Django 文件那樣插入 Python search path (把新的 path 放在舊的前面)，Apache2/FCGI 會報：

FastCGI: comm with (dynamic) server "blahblah.fcgi"
aborted: (first read) idle timeout (30sec)
FastCGI: incomplete headers (0 bytes)
received from server "blahblah.fcgi"

這樣的錯誤，因為 blahblah.fcgi 根本無法啟動。我得把新的 search path 放到舊的 path 後面，blahblah.fcgi 才會乖乖聽話。

在 Apache2 裡當然還得作些必要的佈署，不過 Django 文件裡寫得很清楚了。Add-Handler, RewriteRules 的設定都沒什麼問題。本小站又成長了一些 :)

Update, OT: 順帶一提，VIM 7 多了幾個令人愉快的新功能：

1. 在 remote X 上編輯的時候，gvim 的標題列上會主動秀出該 gvim instance 所在的主機位置。對編輯多主機檔案的人來說方便很多。以前一個 workspace 開十幾個 gvim，編輯好幾個主機上的檔案，檔名和路徑又都一樣，非常考驗記憶力 :)
2. undo 時會在最下面秀出該動作是在多久前執行的。這又是一個減低編輯者腦力消耗的好功能。

http://code.enthought.com/release/changelog-enthon-1.0.0.shtml

這是一篇追蹤文章，是對之前的關懷。

好玩的店。

在大阪日本橋，偶然遇到的一對小店。右邊是正牌 maid cafe，左邊樓梯上去有貓咪坐檯。

拆開幹嘛呢，合體不是很好嘛。

點上面的圖可以到 Zooomr 去看此店在 Google map 上的位置。這就是 Zooomr geotag。

Feedjack 是 Gustavo Picón 所開發的一套基於 Django 的 feed aggregator (planet) 軟體。前一陣子就注意到了，正好洗澡前有一段空檔，便把它給安裝起來。請參見 Unofficial Python@TW planet。當然，剛裝好的現在，裡面只有我一個人的 feed。

Feedjack 的安裝不難，不過使用者需要具備一定的 Django 知識。其中最重要的是，在 Django 裡的靜態檔案，與程式以及模板都是分開存放的 (靜態檔案包含樣式表與圖檔)。所以在用 setuptools 裝好 Feedjack 之後，還要把 Feedjack 裡的靜態檔案弄一份到 Django project 的 MEDIA_ROOT 裡去。無論 symbolic link 或 copy 都可以達到目的，站在便於訂製的立場來看，複製一份過去會比較好 (西方人寫的軟體呀，尤其是 web 軟體，字體都喜歡設得小小小，不改一下，眼睛讀起來可真難受)。

除了試用 Feedjack 之外，建立一個非正式的台灣 Python planet 實在是有推廣 Python 的用意。如果你也願意加入這個 planet，請留言在這篇文章下面，或是到 Freenode 上的 #pot IRC 頻道告訴我 (yungyuc)。希望能匯集更多台灣 Python 使用者的關注。

順便也廣告一下 Freenode 上的 #pot 頻道。如果你對 Python 有興趣，想找人聊聊卻不知道該去哪，來 #pot 就對了。#pot 是一個 IRC 頻道，位於 Freenode IRC 網路。你可以到 http://freenode.net/ 找到這個 IRC 網路的資訊。而關於連線方式，在 Windows 下可以使用 Chatzilla (Firefox 的姐妹產品) 或 Gaim；在 Linux 下則推薦 irssi (文字模式) 或 xchat (GUI，不過我不會用...)。語系記得設成 UTF-8 (不要用 Big5 喔，大家會看沒有)。歡迎你來。

一早起來還沒有睡醒，就在 Django-user mailing list 上看到 "Django vs. Rails vs. Symfony: Django is fastest" 這篇文章。在 wiki.rubyonrails.com (注意，是 RoR 自己的 wiki) 上有人發表了一篇測試報告："Framework Performance"，比較 Symfony/PHP5, Rails/Ruby 和 Django/Python 等三組 framework 的效能。Django 贏了 Rails 有五成左右，出我意料之外地多。

其實我本來對 Django template 的速度不是很滿意。在把這個 blog 從 COREBlog 移出來，以 Django 改寫的時候，用 ab 對首頁只能測出 x hits/sec 的數字 (現在好一點了，測試出 2x hits/sec，因為我把首頁顯示 entry 的筆數調低下來)。當然，這裡面有部分的原因是我亂組態 deployment，不給跑 Apache 的使用者對 Django app 所在目錄的寫入權限，所以每次 page hit 都要重新編譯所有的 .py 檔 (沒有寫入權限就無法把編譯好的 .py 備份到 .pyc，因此下次執行同一段程式的時候還得重新編譯)。

然而，這篇測試報告倒表現出 Django template system 的優勢。如果測試內容準確的話，他們儘可能把 page hit 的工作放在 page rendering 上，也就代表測試的大部分是 framework 本身，必定大量使用 template system。而 Django 大幅優勝的結果，表示 Django template system 相較於其它 framework/template 速度還比較快。這是很好也是很壞的結果。好的部分是可以對 Django template 有更多信心，壞的部分是我寫的 template 肯定有問題，怎麼跑的那麼慢呢 (苦笑) (看來光模仿 COREBlog 的設計可不是個辦法)。

之前我也測過 Django 的 cache，表現得不錯，完全不需要動到 mod_proxy 之類的 Apache 模組便可以把 1x hits/sec 拉高到 2xx hits/sec。由此也可驗證 RoR wiki 上的測試報告確實沒有用 cache 作弊。

好的，這樣的結果可以讓我很快樂地繼續用 Django 寫程式玩，然後說我很快 (笑)。話說回來，比起來 RoR 也只是有點慢而已，其 framework 本身大受好評不說，穩定性也不錯，在測試裡使用 lighttpd 的話，最長 transaction 時間 (1.25 sec) 更有超水準表現。Symfony 就很慘了，慢倒還不是致命的問題 (雖然速度是 Django 的 1/3，但這總可以用三台電腦 load balancing 來暴力解決)，麻煩的是連線不穩定；無論在高低壓測試組態下都會有 transaction fail。

RoR 值得玩玩，但 Symfony 看來卻該敬而遠之。