從 Tipsy 那裡看到了台灣電影上映日曆。Google Calendar 公開沒多久，就已經有人作出這麼好用的行事曆囉。

雖然我沒時間看，不過 Web 2.0 真好。

現在的 scripting language 一大票，有了 Perl, Python, PHP，再多一個 Ruby 也不會改變什麼？其實會啦，寫 Java 好無聊 (笑)，多一個可以選當然比較好。

這個世界上的東西如果都只能用來生產，作正事，想來我們的物質會相當匱乏。少了那些無病呻吟的詩人、只認數字不認人的科學家，和閒得發慌的程式語言發明者，或許現在的程式設計師都要去排真空管？啊，不會啦，應該有進步到打卡的機會。如果不是因為舊的方法有所侷限，也就不會被新方法取而代之；如果組合語言很好用，幹嘛用 C 來寫 Unix 和 Windows 呢？在創造新方法的過程中，總是會出現一些不那麼切實際的嚐試，而最後，其中的一些被證明有效。

銀子彈這種東西，別費力去找。作什麼事情，用什麼工具；用 C++ 來寫網站留言版就是事倍功半，說不定用 shell script 還會方便點。要作簡單的計算，當然是

python -c "from math import *; print 3.0*2.0*pi"

一行解決；叫出小算盤我都嫌麻煩。

像 Python 和 Ruby 這種語言實在有個大優點：看起來很簡單，也真的很簡單。如果我想學好演算法、資料結構和系統分析，為什麼要捨易取難呢？

Be happy! Finally Django magic-removal branch is going to be merged back to trunk.

Andian Holovaty 在 4 月 21 號對 django-developers 和 django-users 列表發出了 "magic-removal call for testing" 的郵件。Django 開發團隊從現在開始凍結新功能，專注於 magic-removal 的除錯與修正，預計在下禮拜五 (2006/4/28) 開始 merge。

一直以來，Django 的模板系統規定模板檔的副檔名須是 .html。從今天起，這個限制解除了。我們現在可以把 Django 模板檔取作任何一種副檔名；是的，不再需要為檔案關聯傷腦筋。

當然，模板檔的副檔名仍然不會影響到網頁內容的 mimetype。

對已經使用 M-R 的 Django 開發人員，這個改變迫使我們必須修改所有 view 裡面的 render_to_response() 參數。由於模板系統不再限制副檔名，它不像以前一樣會自已幫我們加上 .html (現在它不知道要加什麼副檔名了)；render_to_response() 函式裡用來指定模板位置的第一個參數 (以及所有相關函式的模板指定參數)，得自已加上 .html (或其它副檔名)。

竟然因為 sqlite db 檔權限的問題，搞掉我一個小時。這是第二次了....

Django M-R 使用 sqlite 作後端的時候，如果對 db 檔案缺乏寫入的權限，又以 Apache2 FCGI 進行佈署的時候，有時候 FCGI 會送回 "Unable to close due to unfinalised statements" 的錯誤。

明明錯誤訊息清清楚楚地說是 sqlite 有問題，之前也遇過類似的狀況，卻還是花了那麼多時間找錯誤。這就是說有些東西不記下來不行，人類的記憶非常地不可靠 :-) (或許事實上是我該承認腦袋秀逗了)。

無論如何，利用吃飯前的一點時間，再加上前兩週有一搭沒一搭的修改，這個網站已經從 Django trunk，順利地移植到 magic-removal。因為改到一半出現上述的權限問題，晚飯又作好了，所以本站掛了一段時間；如果有人剛剛連不上或是看到花螢幕，抱歉抱歉。

近來 django-user 列表上有兩大串討論，其一是對 0.91 舊系統，以及很快就會面世的 magic-removal 的討論。有些人認為雖然目前的 trunk 距離早先的 0.91 release 進行了許多修訂，但為了避免夜長夢多，magic-removal 應該直接作為下一版發行 (這也是 magic-removal 原訂的計畫)。然而，更多人覺得現在的 trunk 已經作了很大的改進，不進行發行，以照顧一下舊系統的使用者，有點說不過去；或許在 magic-removal 發行時，也應該把目前的 trunk 同步發行為 0.91 的 fix。

把 0.92 發行為 0.91 的支援性修正版，而將 magic-removal 直接推到 0.95，這主意聽起來很棒；因為，感覺離 1.0 近得多了 :-)

再者，有些人想為 Django 撰寫 e-commerce 的支援，而且已經有所動作。

Google Calendar 開始測試。

我想想看。有 (G)mail，有 (G)calendar，平常上班開 outlook/notes 看的大概就是這兩個東西。Google 的 groupware 還缺什麼呢。

Gcalendar 具備多行事曆的設計。使用者可以組態多個獨立的行事曆，也可以和他人共享行事曆。多行事曆是設計給不同屬性事務使用的，譬如家人的事情放在 A 行事曆裡，辦公室的事情就放在 B 行事曆裡，如此即可針對不同的對象進行分享。

Gcalendar 目前已經附了好幾個國家/文化族群的節日行事曆。我覺得這是很好的設計。在 outlook 裡面雖然有各地節日套件可以新增，但一旦加入後，節日就很難被移除。因為那些節日套件會把各節日當作獨立的事件加進行事曆中。Gcalendar 讓節日變成選項，隨時可以增刪開關，方便性就高多了。

中小企業買 Exchange server 作什麼呢？Google 都幫你們想好了。當然，還是等 beta 兩個字拿掉以後再用比較好。

假的東西很好。有些事物本來就具有假的屬性；如果不是因為其中部分的不真實，這些事物的價值就會大大地減少。譬如戲劇、故事，完全真實的情節反而不能激動人心的共鳴，而且也沒有必要存在。如果想要追求真實，那麼現實社會裡到處都是真實，何必創造出「真實的故事」來假裝很真實呢。所以我喜歡看動畫勝於看電影。

新聞不能帶有假的屬性。昨天看到了兩則和「iThome online : The First IT Portal : 愚人節駭客惡搞Linux網站」相關的新聞，今天看到 chihchun 「國際駭客發動網路戰」。昨天看到新聞時只覺得好笑，但今天看到 chihchun 的「後續報導」時，發現調查局電腦犯罪偵辦科如此的查案品質後，一股厭惡的感覺卻油然而生。

根據 chihchun 的調查，該段時間 (4/1~4/4) 台灣被 un-root 摸的機器才 17 台，媒體的報導卻是將近 200 台。或許是媒體報導時不求甚解？那麼聯合報、中國時報和 iThome 全都一起不求甚解。

Python 內建函式裡有一個 __import__()，可以用來自訂 package/module 的匯入 (import) 動作。Django 就利用這個函式來取得 DJANGO_SETTINGS_MODULE 和其它相關的功能模組。

當我們要在程式裡面設計可選擇的組件 (plugin) 時，讓它們被 __import__() 動態載入是蠻理想的方法。Python 官方文件裡對 __import__() 的介紹就給了一個剛好適用的範例：

def my_import(name):
    mod = __import__(name)
    components = name.split('.')
    for comp in components[1:]:
        mod = getattr(mod, comp)
    return mod

把模組的名稱字串 name 丟進 my_import() 去，就可以得到該字串所指涉的模組。這和一般所用的 import mod1.mod2 有什麼不一樣呢？我們寫：

import mod1.mod2

所得到的是一個 mod1 名稱，這個敘述會把 mod1 模組加進當前的命名空間中，同時把 mod2 加進 mod1 模組的命名空間；實際上，在當前的命名空間中得到的是 mod1 這個模組，而不是 mod2 。

my_import() 不一樣，當我們寫：

wantedmod = my_import( 'mod1.mod2' )

會把當前命名空間的 wantedmod 變數指定為 mod2 這一個模組。或者，也可以直接操作 my_import() 傳回的模組物件：

my_import( 'mod1.mod2' ).some_func_in_mod2()

當然，如果我們只是想要能夠比較方便地 mod2 這個模組，那麼：

from mod1 import mod2

或：

from mod1 import mod2 as wantedmod

都可以達成任務。使用 __import__() 的重要性在於，它可以在執行期決定要匯入的模組，不像 import 和 from foo import bar，撰寫程式的時候一定要把模組名稱寫死。

還想弄些更奇怪的操作？請使用 imp 模組來變魔法。

Relative 和 absolute import syntax、conditional expression、with statement 等都是在 Python 2.5 裡很受注目的更新，但今天看過limodou 的學習記錄之後才發現 Python 2.5a1 連 sqlite3 wrapper module 都包進去了。

這應該是第一個被加進 Python official module library 的 RDBMS 支援 (如果我弄錯了，請指正我)。偉哉 sqlite，然而，Python 2.5a1 並沒有把 sqlite3 的程式碼包進去，故自行編譯者，須先行安裝 sqlite3 library 及 header files。

這是一段筆記。

Serial ATA (SATA) chipsets — Linux support status 對 Linux 下的 ATA (IDE), SATA 以及 Hardward/Software RAID 支援作了很詳細的說明。整個支援的狀況距離我上一次的亂搞已經進展了不少。這份資料對採購新的硬體有很重要的參考價值。