使用 Django 的雜感

換工作後大概很少會用到 Django, 在這對它做個了結吧。

先說結論

對於不熟 web 又想用 python 開發的人來說, Django 仍是首選, 主要的優勢有:

1. 官方文件超級豐富, 網路上文件也豐富, 也有出一些書, 不過書上內容應該沒官網新, 看官網就夠了。不夠的話再看原始碼也比較方便。
2. 社群龐大, 有許多 middleware 和 plugin 可用, 像多人合寫 web 一定會需要 database integration, South 相當好用。其它像用 Facebook / Google / Yahoo 等帳號登入, 也都有整合好的套件可用。
3. 框架本身實作了許多 web 相關功能 (像 session、cookie、cache、傳輸 zip 後的內容), 可避免犯錯 (像是有擋 CSRF), 很多東西是新手從來沒想過的, 但框架都有考慮到並且實作好了。在使用的過程中可學到這些知識。
4. 極佳的向下相容。官方的 roadmap 會明確提到那些功能已 deprecated, 並會在未來的那一版移掉, 有滿長的過渡期。使用者升級的負擔相當小。
5. 提供一組規範, 切開 model、view、control, 還有 class / table 命名規則等, 減少團隊合作的問題。

當初選 Django 的主因是第一、二點, 第三點稍微有想到, 而第四、五點是使用後得到的驚喜。

說完結論後, 要開始碎碎念我的不滿, 請各位看倌記得, 即使如此, 我還是推薦不熟 web 又想用 python 開發的人使用 Django, 理由如前所述。

關於 template

Django 內建的 template 不好用, 效率也差, 甚至在 FAQ 裡有一項提到「I can't stand your template language. Do I have to use it?」。有些人可能覺得 template 的效率不是重點, 瓶頸會在 database。當我費盡心力減少 SQL、改 schema、改index、改寫 SQL 將 database 花的時間壓到極致後, 卻發現 template 怎麼縮都要 0.1s, 讓我很無力。更別提在關掉 i18n / l10n 前, template 要 0.2s。看著簡單的 template 內容, 很難理解為什麼這樣的東西要花到 0.1s。

此外, template 的語法很受限, 不過到 1.3 版後 include 多了 with 的語法方便代入子版面後, 變得好用許多, 不然有類似這種簡單需求時要另寫 templatetag, 實在是多餘又不易懂。相關心得見之前寫的文章。實在是換掉也為難, 不換也為難。

關於 ORM

先來個免責聲明, 若是需要頻繁地寫多個不同的小型網站, 用 ORM 是利多於弊, 可減少重覆的程式碼。以下的論點基於我的個人經驗, 需求是長期維護一個資料量大且有嚴苛速度需求的網站。

之前已寫過幾篇 ORM 心得, 在《Django 和 Python 操作 database 時的額外負擔》提到實測大量數據的情況有多慢, 注意我的使用情境有超過百萬筆資料, 若資料量沒那麼大, 這個負擔較無所謂。

在《撰寫資料庫相關程式的心得》有提到使用 ORM 的成本。這裡要補充的是, 無論如何, 我們都需要分開「資料庫的操作」和「邏輯操作」。而在程式裡直接使用 ORM 並沒有隔離好兩者。

舉例來說, 在頁面裡使用 get_user("fcamel") 會比 User.objects.get(name="fcamel") 來得好。想想要如何針對這個頁面寫 unit test, 會發覺後者仍和 database 有很大的相依性, 不容易 mock。或著換個說法, get_user() 的抽象程度比直接使用 ORM 高。get_user() 裡是使用 ORM 還是下 raw SQL, 都和使用者無關。當需要連續幾個 ORM 操作以達成一個目的時, 另外包函式的優勢會更明顯。

若能接受上面的論點的話, 會發覺 ORM 的優勢又少了一點。所以, 我個人的看法是: 重點是必須另外包一層 API 存取資料, 供邏輯操作使用。所以, 對前端開發者來說, 是否使用 ORM, 影響不大。但對後端開發者來說, ORM 的缺點遠大於優點。ORM 最吸引人的地方是提供不錯介面隔離 database, 可以有彈性地存取資料並且不用太了解如何寫 SQL。但隨著使用經驗漸增, 會發覺這些優點並非事實。但若一直不去了解 database, 不會發覺付出的隱性成本。

題外話, 聽說 SQLAlchemy 相當強大, 不知實際用起來效果如何。我後來淡化使用 ORM 的場合, 加上需要使用 South (基於 Django ORM 的 plugin), 不方便換掉, 就沒有研究 SQLAlchemy 了。

關於 test

內建的 django.test 相關模組不太好用, 而且執行 test 要先重建全部 table, 然後在每個 test case 前 truncate 全部 table, 效率不好。若能指定只 truncate 需要的 table, 可省下許多時間。通常 test case 是愈寫愈多, 實務上執行 test case 的效率相當重要。

使用 South 後更會有 production schema 和 test schema 不同的問題, 因為 production 用 South 建 schema, 中間可能用到客制化的 SQL 改 schema (如建 multiple column indexes), 但 django.test 不會呼叫 South, 而是用 Django 原本讀 models.py 建 schema 的方式。我後來改用自己寫的模組來建 test database, 沒研究後續發展, 不知後來是否有修正。

關於 coding style

Django 違反許多 PEP 8 的規則或 Python 精神, 像是:

• 在程式碼裡面 import 別的 module (而非開頭), 並且有 circular import。
• 有多種方法做一件事。我很討厭這點, 像自訂 login 的重導頁面卻沒成功, 除錯時很麻煩, 要搞清楚多種規則的執行順序, 才知道問題出在那。
• 有許多 lazy initialization。我不確定這是否違反 Python 社群的 "explicit is better than implicit", 我個人不喜歡一堆 lazy initialization, 很難掌握程式的行為。

以上這些事對使用者有什麼影響? 當行為不合預期, 文件也看不出所以然時, 讀原始碼並加 log message 是滿有效率的除錯方法。上述都是我在研究功能 (像是如何使用 cache) 或除錯時, 讀原始碼遇到的困擾。

結語

除前面一再強調的「結論」外, 再多強調一下, 一個東西愈多人罵, 表示愈多人用, 出事也愈好處理。本篇不是建議別用 Django, 也不是反串推廣, 只是之前一年多的使用心得。

撰寫資料庫相關程式的心得

我是用 MySQL + Django，處理的資料量有小有大。資料量大的情況下，通常有上萬筆，甚至會到上億筆。相關心得大概分成四類，依實務經驗記錄一下心得。

是否應該使用 ORM？

我是使用 Django ORM，以下指的 ORM 問題可能不適用全部 ORM framework，但我猜大部份應該是半斤八兩。

剛開始不熟 SQL 時，很喜歡用 ORM，ORM 有些學習門檻，不過習慣後用起來相當順，也容易閱讀程式。但是在好寫好讀的背後，卻犠牲掉極大的效率。原因有幾點：

• 需要大概了解 ORM 產生的 SQL，才知道如何寫出有效率的操作。比方說用到 foreign key 時，可以在取物件時順便 join。若沒特別處理，預設行為是參考到關聯物件才取資料，於是取一萬個物件並讀取它們的關聯欄位，就會多下一萬次 SQL。
• 即使了解 ORM 各項操作避免一些地雷寫法，ORM 不見得能產生最快的操作方式。明顯的缺點是讀寫 N 個物件時，很可能會轉成 N 次 SQL，而不是一次。
• ORM 為了提供一致的抽象介面，沒有支援各家 DBMS 完整的語法，減少一些最佳化的機會。如缺少批次操作，以及使用 force index、決定 join order、技巧性地用 IN 不用 range query 等。
• 即使 SQL 沒有問題，產生 object 的時間成本比自己執行 SQL 取資料來得高 (見這篇)，資料量大的時候會變成瓶頸。

我一開始寫的專案全用 ORM。第二個寫的大部份用 ORM 但遇到一堆難解的效率問題。第三個寫的開始刻意減少 ORM 操作。最後則是全面禁用 ORM。原因很簡單，弄懂 ORM 操作並做最佳化的時間，比直接寫函式封裝 SQL 操作多，而且最後達成的效率又較差。除此之外，複雜的 ORM 操作可能有 bug 或是令人誤會，導致取出不對的資料，看 ORM 產生的 SQL 才明白問題出在那。

愈懂 MySQL 後，愈覺得 ORM 不順手，最後就改成寫模組封裝 SQL 操作。結論是，若有意願硬啃 DBMS 相關知識的話，將時間投資在所用的 DBMS 上，會比學習 ORM 操作和理解背後運作方式划算。

也許有人會質疑不用 ORM 會增加換 DBMS 的成本，我沒這樣的經驗不清楚用了 ORM 能省下多少成本，相較於前述的問題，整體來說是否划算。至少我會選擇先專精一個 DBMS，還有自己寫模組隔離應用層邏輯和資料庫操作，減低轉換 DBMS 的成本。

Database migration tool

雖然我上面將 Django ORM 說得很慘，但是用 Django ORM 搭配 South 到是滿不錯的。South 是 Django 的 migration tool，提供一個框架維護資料庫的變動，並且可以偵測 Django model 的變化，產生對應改變 schema 的操作。在說明 South 的優點前，要先談談為何需要用 database migration tool。

使用 database migration tool 有兩個好處：

• 記錄目前這版程式用的 database schema。既然程式碼需要版本記錄，database schema 當然也要一併記錄，才能確保每版都能正常運作。
• 方便其他組員更新資料庫。更新程式碼後執行 database migration，就能擁有和其他人同步的資料庫。

當然，有很多方式可以達成以上目的，像是每次更新 schema 就 dump schema，並存成一個 SQL 檔存在 VCS 裡。我沒這樣做過，不知會有什麼大問題。目前只想到幾個小問題：不方便多人同時修改 schema，之後要 merge schema 可能會比較麻煩，特別是改到同一 table 時。不方便追踪 schema 各步的轉換，像是加入 table A、B、C 以支援功能 X。但是回頭翻 VCS log 似乎也能滿足這個需求。唯一無解的大概是有些情境拆開 schema 執行會比較有效率。像是先建好 table、填完實體資料後，再建 covering index。

若改成維護多個 SQL 檔，第一個起始 SQL 產生基本 table，後面的 SQL 都是「schema diff」，則方便多人同時開發。但要人工產生 schema diff 有點辛苦，沒記好每個操作，手動改完 table 後，要回頭比對差別才能寫出 schema diff，容易出錯並增加確認的成本。

除了滿足基本需求外，South 另外提供下列功能：

• 提供單線前進的 migration 方式。能在各版本之間前進、後退。
• migration 分成 schema migration 和 data migration。並且提供偵測 Django model 變化自動產生 schema migration 的程式碼。data migration 只是空殼，由工程師自己填程式碼。
• 提供修改 schema 的 API，像是加減欄位、加減 index。

使用 South 的額外好處是，可以避開 Django model 的限制，像是不支援多欄 index、不支援使用不同的 MySQL Engine。用 South 的話，只要自己在 schema migration 裡用 alter table 修改即可。

不清楚別家 database migration tool 怎麼運做的，感覺這方面的工具有很大的發揮空間，值得了解一下各家工具提供的功能。目前遇到的最大困擾是，無法明確看出那些 migration 有相依關係，更新資料或程式時，不方便只執行有影響到的範圍，若更新在很前期的 migration，就得回溯到前面再重跑。

包工具箱

將資料庫操作和應用層邏輯分離的好處應該不用多說，使用統一的介面有其它好處，目前覺得最實用的是可以寫 try catch 自動記下所有出錯的 SQL，再依參數決定要吃掉 exception 或丟回應用層。由於出錯的 SQL 都有被 log，程式出錯時可以馬上找到有問題的 SQL，縮短除錯時間。

單元測試

我原本是用 Django 內建的方式重建測試資料庫，但是最近開始用 multiple database 後，遇到一些問題。由於我在 South 裡做了一些不合 Django 規定的操作，不想花時間理解 Django model 和 test 詳細的運作方式，最後決定自己寫簡單的模組來建置測試環境，速度也會比較快。還在小規模的試用中，看看之後能不能投多點時間打穩這塊，再來寫心得。

《別鬧了，費曼先生》閱讀中的雜記

讀《別鬧了，費曼先生》的過程裡，偶而有寫片段感想。這篇是這些短記整理後的記錄。

通用的學習法則

《別鬧了，費曼先生》提到費曼常跨領域學些不同東西，不管是哲學、數學、生物學，費曼都用他學習科學的習慣判別對錯，掌握基本原理。最近做研究也有這種體會。即使沒有背景知識，有良好邏輯，掌握假設和觀察結果，通常能做出正確的判斷。前提是我們能明確判讀那些是客觀事實，那些是主觀判斷，數據不會騙人，可是人會，而且我們自己也可能會騙自己。

舉例來說，看到別人的實驗結果和實驗報告，一定要自己讀一遍數據，不然無法判斷別人說明中那些部份為主觀推測。像是兩個方法有效程度差了千分之一，是否可說有顯著差異？去除人有私心的因素外，我們也沒有想像中的聰明，容易將一些相似的資訊混在一起，不知不覺認定是事實。「誤把有相關性視為有因果關係」是常見的例子，有興趣的人可以看些寫給大眾看的統計書籍。反用「判讀個人觀點和事實」的原則在自己身上也很有效，可以找到自己思路的盲點，不會過於武斷主張自己的看法。

此外，舉例說明是最佳的討論方式。費曼提到他和數學家討論數學原理時，他的判斷方式是心中想像一些實例，對方描述問題時，他就想像心裡那些物體會怎麼變化，於是當對方說某某性質如何，他發覺在他想像世界裡有矛盾時，就能做出辯駁。另一方面，我相信只有當我們能舉例說明時，我們才算真的明白，藉由逼自己舉例，可以思考的更靈活，找出忽略的細節。

別死記名詞

另一方面，費曼也指出許多人記了一堆名詞，卻沒掌握基本精神，他在 MIT 的大學同學如此，愛因斯坦的研究助理也會犯這種錯。費曼一再提到很多學生只會背名詞，不會理解背後的含意，不明白他們在學什麼。這種精神從他小時候就存在，和父親在林中散步時，費曼的父親向他解釋生物行為而不背名字，費曼將自己的成就歸功於父親童年時的教導，不無道理。

費曼在問學生問題時，會舉例討論，而不問教科書式的問題。我在確認別人能力時也是這麼做，不問專有名詞解釋（像是請說明 X 演算法為何），盡量用應用題直接看對方怎麼運用知識，這樣能立即明白對方有沒有理解背後含意。反過來看，不知道某些名詞不代表什麼，就算對方不知道 Dijkstra’s Algorithm，但若能提出相似的解法，反而更高明。只要和對方說明這些知識，他們立即能掌握精神加以運用。反之，知道 Dijkstra’s Algorithm 卻無法活用，知道更多演算法、累積更多經驗，成長也有限。

名詞只是方便溝通的工具，若不能理解背後的含意，光記許多名詞毫無意義。在資訊爆炸的時代，每天產生一堆新的名詞，吸收這堆雜亂的詞彙時，得時時提醒自己，是否明白背後含意。以前我曾落入背誦知識為樂的陷阱，後來發現知道很多皮毛卻無法做進一步運用，才驚覺自己浪費不少時間。舉例來說，現在當紅的 Android，即使我知道 Android 是 Google 發佈的手機平台，也沒任何幫助，只是一堆名詞堆砌。到不如了解為何會有 Android？適合解什麼樣的問題？需要時可視需求對相關知識做進一步研究。 (備註：我並不了解這兩個問題，只是舉例而已。）

並不是說記名詞毫無意義，費曼童年時自己發明一套數學符號，他覺得讀起來比較好理解，很高興地用了一陣子。但後來發現他無法和人溝通，就把這些符號丟了，改用共通符號。與人溝通需要專有名詞，不然難以進入問題核心，講半天還在說「你是說如果有 n 個點，點可以是任意東西，像是城市，或想像成座標也行，這 n 個點之中部份兩點有互相連接，連接的距離長短不一，而你想從某個起點 A 走到終點 B，想問如何走才能花最少的步數嗎？」（即最短路徑問題）。

寫 Blog 好幫手 TD-Post！

為了方便寫 Blog，寫了個小程式讀 wiki code 產生 WordPress 吃的格式，順便藉機練習 TDD，沒想到寫了十小時才完成。剛好最近在看虎x龍的動畫，就將它命名為TD-Post (Tiger x Dragon Post) 吧。

緣起

換過多家 WordPress 用的編輯器後，我還是找不到滿意的工具。為縮短寫 Blog 的時間，我決定自己做一個。

寫 Blog 最惱人的事有幾點：

1. 得輸入麻煩的 HTML，特別是要匹配結束標籤特別麻煩。而且 HTML code 不易閱讀，改文章時很不方便。
2. 加超鏈結很麻煩，常用的幾個超鏈結，得重附貼多次，像 TDD 我就重貼了許多次。
3. 無法用自己慣用的編輯器。若能用 Vim 寫 Blog，速度必能大增啊！

功能簡介

對我來說，寫 wiki code 相當方便，所以輸入格式決定用 wiki code。但 wiki 格式有許多種，我比較常用的有 PmWiki、DokuWiki、TWiki，其中以 PmWiki 語法最簡單，但原始碼沒後兩者好讀。最後聽從 York 的建議，採用 Trac 的 wiki 格式。選它的主要原因除好讀好寫外，我特別喜歡它 Preformatted Text 的格式，很適合用來貼程式碼。

接著，針對第二點問題，加上自動補超鏈結的功能，只要寫過一次超鏈結，TD-Post 就會自動記下來，自動補上對應的位置。像在這段裡，因為我在第一段已寫過 TD-Post 的位置， TD-Post 的超鏈結都會自動補上。初步估計，以後寫一篇 Blog 至少可以省十分鐘，所以差不多用個六十次．．．這幾天的辛勞就．就回本啦。

程式下載

本程式採 BSD License ( 簡單說就是隨便使用 )，歡迎大家玩玩。雖然沒什麼註解，但我照 TDD 流程寫的，測試碼應該很完整。這裡是一些相關資訊：

• 下載：http://code.google.com/p/td-post/downloads/list
• 程式語言：Python
• 程式碼總行數：682 行
• 測式碼：346 行 ( 主要是準備測試的例子 )
• 非測試碼：336 行
• 實作時間：原本預估兩小時完成，卻花了約十小時。大概是一小時查語法、一到兩小時寫測試。其中花最多的時間在解決 list 和 performatted text 的衝突，這部份從開始實作到結束花了三小時才解決。

其它

有原始碼有真相，最後附上本文的原始碼：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

為了方便寫 Blog，寫了個小程式讀 wiki code 產生 [http://wordpress.org/ WordPress] 吃的格式，順便藉機練習 [http://en.wikipedia.org/wiki/Test-driven_development TDD]，沒想到寫了十小時才完成。剛好最近在看[http://zh.wikipedia.org/wiki/虎與龍_(小說) 虎x龍]的動畫，就將它命名為[http://code.google.com/p/td-post/ TD-Post] (Tiger x Dragon Post) 吧。   ==== 緣起 ==== 換過多家 [WordPress] 用的編輯器後，我還是找不到滿意的工具。為縮短寫 Blog 的時間，我決定自己做一個。   寫 Blog 最惱人的事有幾點： 1. 得輸入麻煩的 HTML，特別是要匹配結束標籤特別麻煩。而且 HTML code 不易閱讀，改文章時很不方便。 1. 加超鏈結很麻煩，常用的幾個超鏈結，得重附貼多次，像 [TDD] 我就重貼了許多次。 1. 無法用自己慣用的編輯器。若能用 [http://www.vim.org/ Vim] 寫 Blog，速度必能大增啊！   ==== 功能簡介 ==== 對我來說，寫 wiki code 相當方便，所以輸入格式決定用 wiki code。但 wiki 格式有許多種，我比較常用的有 [http://www.pmwiki.org/ PmWiki]、[http://www.dokuwiki.org/ DokuWiki]、[http://twiki.org/ TWiki]，其中以 [PmWiki] 語法最簡單，但原始碼沒後兩者好讀。最後聽從 York 的建議，採用 [http://trac.edgewall.org/ Trac] 的 [http://trac.edgewall.org/wiki/WikiFormatting wiki 格式]。選它的主要原因除好讀好寫外，我特別喜歡它 Preformatted Text 的格式，很適合用來貼程式碼。   接著，針對第二點問題，加上自動補超鏈結的功能，只要寫過一次超鏈結，[TD-Post] 就會自動記下來，自動補上對應的位置。像在這段裡，因為我在第一段已寫過 [TD-Post] 的位置， [TD-Post] 的超鏈結都會自動補上。初步估計，以後寫一篇 Blog 至少可以省十分鐘，所以差不多用個六十次．．．這幾天的辛勞就．就回本啦。   ==== 程式下載 ==== 本程式採 [http://zh.wikipedia.org/w/index.php?title=BSD许可证&variant=zh-tw BSD License] ( 簡單說就是隨便使用 )，歡迎大家玩玩。雖然沒什麼註解，但我照 [TDD] 流程寫的，測試碼應該很完整。這裡是一些相關資訊： * 下載：http://code.google.com/p/td-post/downloads/list * 程式語言：[http://www.python.org/ Python] * 程式碼總行數：682 行 * 測式碼：346 行 ( 主要是準備測試的例子 ) * 非測試碼：336 行 * 實作時間：原本預估兩小時完成，卻花了約十小時。大概是一小時查語法、一到兩小時寫測試。其中花最多的時間在解決 list 和 performatted text 的衝突，這部份從開始實作到結束花了三小時才解決。   ==== 其它 ====   有原始碼有真相，最後附上本文的原始碼：{{{ #!html _QUINE_ }}}   身為資工人，這段原始碼當然也是自動貼上的啦，不過我沒用像 [http://en.wikipedia.org/wiki/Quine_(computing) Quine] 那樣的技巧，只是單純地取代關鍵字。

身為資工人，這段原始碼當然也是自動貼上的啦，不過我沒用像 Quine 那樣的技巧，只是單純地取代關鍵字。

裝了 ScribeFire Blog Editor

由於 Windows Live Editor 對 WordPress 的支援不夠完整，這篇改用 Scribefire 試看看。

Scribefire 也有很炫的預覽功能，而且多了可以將網頁的標題和連結取出加入編輯內容內，挺方便的。Category 部份到是有支援一半，可點選要加入那些目錄，但沒有顯示出原本目錄的階層關係。唯一的缺點是不能加入<!–more–>。或許之後可以改用 ScribeFire 看看。

Update

ScribeFire 也加了部份討厭的 tag，像是 <br> 和 <div>，這樣日後要回頭手動編輯時，文章內容挺醜的。

裝了 Windows Live Writer

剛才不小心關掉網頁而遺失了正在寫的文章，一怒之下就裝了 Windows Live Writer。現在這篇就是用它來試寫。

初步用起來還挺方便的，不過每打一個字畫面就閃一下，感覺挺怪的。還有不能插入 WordPress 專用的一些 tag，得自己切到 Source mode 輸入（例如<!—more—>）。 Preview mode 看起來挺屌的，可以直接看到文章送出後，在自己的 Blog theme 下看起來是什麼樣子。

Update

Windows Live Writer 竟然加了多餘的 tag，像是 <p>，而且不能用<!—more—>，發文章時找不到選 category 的地方，只有看到加 tag。改來試用別套好了。

如何啟動 TWiki Debug 模式

這篇的另一個標題是「TWiki Plugin 讀取和設定 Preference 的方法」，因為要成功地啟動 TWiki Debug 模式，得弄清楚 Preference 設值和讀值的方式才行。

我想這樣的標題就和有人寫了篇《The Amazon.com Customer Service Phone Number》一樣蠢，但實情就是如此糟。一位網友完全道出我摸索這過程的心聲：

TWIKI is SO DAMN CONFUSING on how to debug. It has taken me 4 hours of reading everything and all the docs and I still don’t understand how to turn on debugging. I set DEBUG = 1 in twiki/bin/view/TWiki/ExcelImportExportPlugin, like described in another place (that took me hours to find) http://twiki.org/cgi-bin/view/Support/HeadLinePluginDebugLog

So, the plugin does not work. Twiki documentation assumes you have a PHD in Twiki configuration in order to debug. Seriously it is so confusing. Please someone point out where the docs clearly state where you turn on/off plugin configurations? I have seen docs that say “you do it in configuration” FALSE, you only turn on or off plugins there (and that took me 2 hours to find after installing the plugin and wondering why it did not work)

Will someone please take the to write some documentation that makes sense?

– JeffEller - 30 Nov 2007

問題原因在於 TWiki plugin 的變數設法和取法有兩種，得先弄清楚 plugin 作者是用那個方式取變數值，才有可能把值傳到 plugin 裡。

TWiki 設變數方式很簡單，在任何一頁裡寫如下的 wiki code 即可，存檔後立即生效（注意 * 前有三個空白，後有一個空白）：

1	* Set VAR = VALUE

當這行 wiki code 寫在 TWiki.TWikiPreference 時，就是全站都讀得到，TWiki script 可透過如下的方式取得值並存在 $preferenceVar 裡：

1	$preferenceVar = TWiki::Func::getPreferencesValue('VAR');

然而，Plugin 有另一個讀值的方法，Plugin 可以用如下的 code 取值：

1 2	$preferenceVar = TWiki::Func::getPluginPreferencesValue('VAR'); $preferenceVar = TWiki::Func::getPreferencesValue('PLUGINNAME_VAR'); # 效果同上行

用 getPluginPreferencesValue 讀到的變數名稱，實際上是對應到 PLUGINNAME_VAR，比方說在 EditTablePlugin 裡執行上面這行 code，讀到的是 EDITTABLEPLUGIN_VAR，所以得在 TWiki.TWikiPreference 寫成：

1	* Set EDITTABLEPLUGIN_VAR = VALUE

或是在 TWiki.EditTablePluginTopic 寫成：

1	* Set VAR = VALUE

總而言之，最保險的作法是稍微 trace plugin code，確定它怎麼輸出除錯訊息，得設那個變數名稱才能啟動它，以及它用那個函數取得 preference variable。設對的話會立即生效，也就是將除錯訊息寫入 twiki/data/debug.txt 裡。Code 的改變也是立即在下次讀網頁時生效。

附帶一提，我改 code 時犯了兩個小錯，結果一直沒有效果（也沒看到錯誤訊息）。其一是行末忘了打分號（寫 Python 的習慣．．．）；其二是我在 variable name 後面不小心多加了一個空白，即「getPluginPreferencesValue(’VAR ‘);」，結果就沒取到 ‘VAR’ 的值，浪費了我不少時間啊。

備註

Foswiki 的 ReleasePlan 上指出，本季會出 1.1 版，提高 Foswiki 的品質，我想等那之後再轉用 Foswiki 吧。新版 WYSIWYG 修了一些 bug，而且 NatSkin 很帥，超想用的啦。

多一點點的好服務

最近用了 Read it later 後，讀起文章方便許多，點出來的一堆文章挑重要的看，看累了就把仍有興趣未看的文章收到 Read it Later 裡，輕輕點一下 Firefox 網址列右側紅色小勾即可。在不同電腦間還可透過 Read it Later 同步，看起文章來輕鬆自在。大幅減輕文章看不完的焦慮，反正有留著，不怕忘了看（其實是自欺欺人)。

看到 rainstring 說以前他都用 bookmark 做這件事，有 Read it Later 後方便多了。轉念一想，對哦，用隨便一家可同步的 bookmark tool （例如 Foxmarks、Google Bookmark、Delicious），自己定一個 read_it_later 的 tag，不就是一樣的東西？至於 read / unread 的區別，自己多加個 tag 管理就行，剩下的文章排序也只是一點小差異，到不是我選用 Read it Later 的原因。更何況，用 bookmark 的話，分類可以更仔細，像是 read_it_later_must_read、read_it_later_someday，為什麼會選用 Read it Later 呢？

大概是 Read it Later 快了那麼一點點吧。

Read it Later 針對文章讀不完的問題，讓標記文章只要一個點擊，不像 bookmark 要「點擊 -> 下 tag -> 確定儲存」。看完的文章，也是一個點擊完成，不用到 bookmark tool 的管理介面改 tag。若在 Read it Later 這服務出來前，就算有想到這個點子，也許我會懷疑地問「有必要專門做一個工具嗎？又沒快多少」，但真的試過後，確實體會到這必要。插個題，這讓我聯想到 Paul Buchheit 寫的《Communicating with code》，與其爭論不休功能好壞，不如用最簡單快速的方式寫個 prototype 給大家玩玩，才有具體的經驗可討論未來發展。

Dropbox 也是一個類似的服務，它的功能就是同步檔案，相信大家可以想到許多替代方案，像是架個 SVN server，並在每個人電腦上裝 TortoiseSVN ，大家就能在不同電腦上分享檔案。既然如此，Dropbox 看來似乎也是有些多餘？答案如同 Read it Later 的情況，Dropbox 針對分享同步檔案而設計，操作就是簡單了一點，快了一點，而有它存在的必要。

相關介紹

• [FF] 這篇文章我等一下再看 - Read it Later
• 真好用的「Dropbox」！

更新 WordPress！

看了 WordPress 2.7 的介紹後超心動的，趁過年回家陪爸媽看電視的時間來更新！

與其說是更新，不如說是砍掉重練吧。舊的 plugin 全丟掉，反正重要的也只有那幾個，為了省事，重找和 2.7 相容的 plugin 比較方便。新版面看來還不壞，後台又超好用的，留言速度好像有比較快（還是我的錯覺 XD）。看看之後回新竹時能不能把欠一堆的文章慢慢補齊吧。

文末來測一下常用標籤的外觀吧

我是 H3

我是 H4

很久很久以前寫的片段 python code：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

import sys   def decode(n, len): """Hello, this is document string. Happy Chinese new year!!.""" input = [] for i in range(0, len, 1): if n & (1< <i) != 0: input.append(1) else: input.append(0) return input # No comment. # No comment. # No comment.   if len(sys.argv) > 1: print sys.argv[1] print simulate(int(sys.argv[1])) else: print simulate(1)

順便來測圖，有圖有真相（公司發的年終禮物．．．，裡面是柳丁）：

最後是大概不會用到的表格：

head	head
ohoh data	ohoh data

Gmail 裡好用的 Quick link 和 Right-side labels

之前因為 label 太多，而找了 Folders4Gmail 把一些 label 合成一個資料夾，剛才發現 Gmail labs 裡的 Right-side labels 可以把 label 放到右邊，這樣就更完美啦！這年頭螢幕都很寬很大，反而讓文章變得不好讀，多放些東西在右邊，少捲動一下螢幕，用起來方便多了！Gmail labs 裡還有很多有趣的東西，像 Quick link 可以把 search 的輸入存成 link，比方《[tip] 善用 Gmail 新功能 化身超強 ToDo List》裡提到可以用 has:attachment (*.pdf || *.doc) 來找附加檔。

備註

Gmail labs 位於 Settings -> Labs。

Oh my god, TWiki 分家了！

最近剛架好 TWiki ，學會 WikiForm + Template + Search 的技巧後（見 ChangeRequest 的 source code），覺得 TWiki 實在太威了！正想深入了解 TWiki 架構並加裝新功能時，才發現 TWiki 分家了！

整件事的始末可以參閱 Foswiki 的聲明，大意是說 TWiki 的創始人想把 TWiki 商業化，並聲稱 TWiki 的商標、名稱、網域為他個人所有。難怪 TWiki 社群出走，要自己另外弄個 Foswiki。Foswiki 官網的說明還滿清楚的，看起來 TWiki 4.2 可以「簡單」地變更為 Foswiki，這幾天找時間來試吧。而 plugin 的部份，也有和 TWiki 既有 plugin 相容，檔案格式依舊，應該不用太擔心。這裡引用官網 Foswiki Release 1.0.0 - 09 Jan 2009 的說明：

A TWikiCompatibilityPlugin has been created that enables most extensions made for TWiki to work under Foswiki, and to support seamless migrations from TWiki to Foswiki.

…

Foswiki is compatible with content of TWiki releases up to and including 4.2, as part of its design.

文末說明 Foswiki 為了避開 TWiki 定的詞而定的新詞彙，讓我聯想到當初大然倒了，東立接手後的情況啊．．．。Anyway，我滿喜歡 Foswiki 官網的版面設計，看來挺清爽的，現在 TWiki 站上已沒什麼發展，遲早要搬過去，這幾天找個時間來試。

備註

• TWiki 是我裝過最難裝的 wiki，雖說 4.2 版比以前好裝許多，apache configure 可以輕鬆填表產生，configure tool 也很便利，但整體來說，安裝和設定還是很繁瑣。變更 TWiki 到 Foswiki 的步驟涵蓋裝好 Foswiki，所以我覺得不會簡單到那去啦，但也不會像以前那樣難裝。
• 個人認為安裝順手度是 DokuWiki > PmWiki > MoinMoinWiki > TWiki，前兩者用 PHP + text file，裝起來超簡單；後兩者用到 CGI，需要多一點設定。

知識管理工具 (3)

( 前兩篇見這裡：第一篇、第二篇。）

最近的使用習慣變成 Google Notebook + Dokuwiki + BBS + Plurk。。

我對工具的基本要求是在任何地方都可以存取以及容易備份，再來是考量輸入和閱讀的便利性，以及資訊的流通性。這四項工具中，Google Notebook 和 DokuWiki 是方便個人維護知識，但流通性差，不易和其他人互動，自然也難以得到回饋；後兩者則相反。下面各別簡介我的用法：

• Google Notebook 操作超方便的，記錄條列式訊息比 Wiki 還方便，會自動存檔，按 Tab/Shift+Tab 可以 加深/減少 條列項目的層級，可以輕易地管理權限和分享給限定的人士。用來存暫時用到的資料，如待看書單、未整理清楚的隨手筆記、todo list。
• 自己架的 DokuWiki 則是存技術性文章（像是架 server、Unix commands、programming language 筆記），供日後方便索引。Wiki 的好處是版面排列彈性極大，可視需求附加功能，方便貼 code，並含 syntax color。DokuWiki 的預設顯示和編輯介面，可說是我用過的系統裡最棒的（其它用過的有 Google Site、PmWiki、TWiki）！不需做任何更動即有 section editing、code syntax、以及簡單好用的編輯介面。加上是 text file db，把整個目錄 tar 起來就能備份。
• 我一直覺得 BBS 是個很怪的平台，相當不適合儲存資訊，但它的極快操作和極簡單的閱讀介面卻是 Web 目前無法取代的。我用 BBS 存粗糙的心得，日後也能回頭索引，還有能和其他人分享及得到回饋。
• Plurk 是最近剛開始玩的，真是理想的碎碎念平台，輕易地和分散各地的朋友串起來。類似 IRC 的感覺，不過是每人各自形成一個聊天室，使用者可同時看到所有訂閱的「聊天室」內的訊息匯入自己看的頁面。加上簡單易用的介面，輕楚的時間軸表示，比 IRC 親切多了。好處是當有疑問想請問朋友，卻不知問誰時，可以輕易地和所有人待上線。目前似乎沒有搜尋訊息的功能，有的話就方便存片段資訊了。

至於以上沒提的 Blog，仍然用來做為整理長期整合的心得，或是記錄人生的片段。除非極有分享的必要（例如網路上很少這類資訊），或是較適合文章形式的表現，才會寫在這裡吧。而 bookmark 部份，我已很少用 delicious 了，原因是存取不夠迅速，我覺得 bookmark 應該要像本機 browser 存取一般才適用。目前暫時改用 Google Bookmarks ，裝 Google Toolbar 後就可取存，介面雖然簡單，操作卻相當快速。由於我很少會回頭點 bookmark，反而較常點存在 Google Notebook 和 Wiki 裡的超鏈結，暫時還不確定怎麼維護 bookmarks 較適當。

Firefox 無法開啟新分頁 (New Tab)

最近不知為何，升上 Firefox 3 後變得不能用中鍵開新分頁，這樣一來 Firefox 等於殘廢一大半，根本不能用。試了一陣子終於找到解法。

重裝 Firefox 也沒用，原本想降回去用 Firefox 2，但官方公告說不久後不會支援 Firefox 2，只好打消這個念頭。網路上的文章大多指出是 Google Toolbar 新版的問題，不過我 disable 或 uninstall 後也沒效。後來索性用 Safe Mode 關掉所有 Add-on，結果就好了。於是再換回一般模式關掉所有 Add-on，也是好的。再把 Google Toolbar 3.1.20081127W 裝回去，仍是好的，怪哉。

Anyway，總之 Firefox 能用後就方便多啦。

備註

移除 Google Toolbar 的方法是在開著 Google Toolbar 的情況下，按 Setting -> Help -> Uninstall。

social network推薦機制

最近在做 social network 的研究，進度相當緩慢，心力被分散到一堆雜事上，這就是沒壓力的下場啊。

這篇文章與該blog裡和facebook相關的文章都很有意思，了解現今最紅的 social network site 如何獲利。看了幾篇介紹後，發現都是相當簡單的推銷機制，我原本也和Mr. Saturday想的一樣，以為facebook會分析使用者的資料，再做出推薦，這也是我現在著手的研究。也許這些學術方法太耗計算資源 ，又無法明確地證明其有效程度，所以 facebook 採最簡單的做法吧？相較於Google極力避開人的因素浮上台面，facebook大辣辣地挑明人的存在，雖然直觀上能讓使用者相信推薦系統，卻更難過隱私權一關。

去除隱私權的問題從研究的角度來看，只使用既有的 social network 發揮的效力有限，只能找到使用者週遭的人，無法找到「沒有直接關聯，但特徵相當相似」的人，大幅減弱龐大資源背後的金礦。但要找出隱藏的金礦，方法不只要算得準，更要算得快，scalability 是首當其衝的問題，這要長時間的研究、試驗、修正，才會有好成果。考量到日後的發展，比較「高深」的方法應該會在日後再漸漸導入吧。

搜尋與推薦

原本想下的標題為「資訊傳播的推與拉」，轉念一想，這麼遜的標題大概沒人想看。

依《隨意搜尋》的分類，資訊傳播的方式可分為「推」 (push) 和「拉」 (pull) 兩種。舉例來說，傳統入口網站如Yahoo的做法，是透過人工編排網站，將資訊「推」給使用者；相反的，Google的搜尋引擎則是讓使用者自己「拉」資訊。廣為人知的關鍵字廣告，則是成功將「推」、「拉」兩者整合成功的獲利方式。相較於傳統橫幅式廣告，關鍵字廣告的成功如今已不需多做說明，有興趣了解背景歷史的話，可以參閱《搜尋未來》，書內有提到當初Overture的創辦人Bill Gross怎麼提出這個構想，以及被Google拿去使用後的發展。

前陣子有幸參與一場很辦的討論，聽到搜尋的可能性，如今Google發展成熟的關鍵字搜尋，其實不過是搜尋發展的冰山一角吧，搜尋的方式仍有很多可能性，現今諸多 Vertical Search 網站是很好的例子，以 location based service (LBS) 為例，我們可以問：「離我最近的加油站在那？離我最近的餐廳有那幾家？半徑五公里內有那些電影院？」從而產生大量的新應用和獲利模式，不在此多提。值得注意的是，搜尋的輸入方式不止有關鍵字；輸出方式也不止有網頁。

除了搜尋種類的變化外，依人、時、地來看，任何搜尋都可以變得更精緻。以關鍵字為例，若你是珠寶商，搜「Ruby」時，你預期看到珠寶相關的事；若你是程式設計師，你預期看到程式設計相關的事。搜新聞時，當我們鍵入「颱風警報」，預期看到的是最近的消息，再者，預期看到的是自己所處地域的消息。搜尋的延伸變化多端，絕不如我們現今看到的如此單調。

然而搜尋有個極限：使用者必須提供資訊。有時候使用者不知道他要什麼，或著是他沒想到。創造未知的服務，正是開拓新市場的契機。舉例來說，統計過各個消費者的購物記錄後，可以推測出他們可能在什麼時候需要補貨，也可以依貨品的互補性提供優惠，比方小明常買泡麵，告知小明最近熱水壺在特價，或是買十箱泡麵送熱水壺，可以促銷。推廣一層來看，除了個人的過去記錄外，可以分析他的社交圈，比方小明常和大毛、二毛一起看電影，最近大毛、二毛看了部新電影，小明還沒看，可以推薦小明去看。再廣義點來看，小明並不需要真的認識大毛和二毛，只要他們的興趣相似就夠了。於是 social network 帶來了新的發展，從最近火熱的 FaceBook 相關新聞可窺知一二。當然，個人使用記錄和 social network 也可以用在搜尋，強化個人化搜尋功能。

這看起來像是「推」與「拉」模式的變化，當「推」的方式變得更靈活、不如傳統入口網站笨重時，應該會出現別於關鍵字廣告外的全贏模式。全贏是指平台經營者 (例如Google)、服務提供者和消費者都滿意，都能從中獲利。

群眾機制評價的問題

相較於專家機制的評價，群眾機制的評價普遍存在強者強，弱者弱的問題。以YouTube來說，很多人看過不見得是好影片，後進的讀者看到很多人看，跟著點那些「熱門」影片，發現很無趣後也來不及了。雖然有評分機制，多人看的影片似乎是4或4.5星，參考價值不大。像熱門排行榜更是極端，除非有做適當的分隔，像依上傳時間區隔，否則新產生的內容難以追過舊有的熱門內容。

有些網站會用文章是否被捲到底，來判斷是否真的有被閱讀（也許再加上一點時間判斷），而非點了就算一次。依人類閱讀的習性來判斷影片或網頁是否有被完整觀看，甚至是自動判斷觀後旳評價，應該有發展的價值。影片用時間判斷，文章可用時間和被捲動的情況。配合真的有給評價的數據，這可視為classification的問題：

• 基本屬性：觀看時間長度內容被看過的比例
• 外部屬性：使用者的個人資訊、過去的行為如看過的影片（網頁）、好友清單
• 分類的目標：給予的評價（例如：0~5顆星）

研究進行的流程大致上是：

1. 分析問題的嚴重性，即影片熱門指數的誤報比率（定性分析，這問題是否真的存在，誤差到一定的值視為有）或各影片誤報程度的平均值（定量分析，將誤差量化，了解問題的嚴重性）
2. 在給定基本屬性的情況下建classification model的結果，能改善多大程度？可用cross validation做驗證手段
3. 考慮外部屬性，先討論如何整理外部屬性成可用的資料，再看引入後對問題的影響程度
4. 應用到實驗平台，觀察使用者的反應，分成使用者回報感想和自動判讀指標（參考第一步的分析），綜合判斷改進的程度

若能拿真實資料玩玩，應該很有意思。忘了是誰說的，真正的研究，應該是來自於日常生活的體驗。

Bill Gross真是有趣的人

最近在看《搜尋未來》，第五章介紹Bill Gross，一位從少年時期就有經商頭腦不斷賣公司的強者。由於他有太多點子想做，不滿於專心做一件事，或著做一陣子就會嫌無趣，在賣了幾次公司後，創了Idea Lab，有點像育成中心，Bill Gross想許多點子，由此機構協助人力、空間、經費成立新公司，做個一陣子，可能又拿去賣掉。成功地開創並賣掉一個公司已很困難了，沒想到竟然有持續賣公司賺錢的人，真強！

Bill Gross賣掉的公司裡以Overture最為有名，是第一個提出點擊廣告付費模式的公司，不過後來被Google沿用後，反而被Google幹掉了，最後以十六億多美元的金額被Yahoo收購。近年來許多Blogger用的SNAP，也是Gross的作品，這個2004年秋天產生的公司，提出了新的搜尋付費模式，Gross在《搜尋未來》裡說他有信心成功。本書的原文版出版於2005/09，沒有足夠資料分析SNAP的概況，總之SNAP算現在進行式的產品，不知道後續發展如何，真有意思。

MoinMoin、PmWiki和DokuWiki editor比較

整理一下最近用Wiki的心得。MoinMoin的GUI editor超威，特別是table的編輯，還可以按右鍵選table/cell property，包含 text/border/background color，text alignment等設定，而且速度很快，GUI editor和text editor之間的切換也很快。有GUI editor後語法也不用查，先用GUI editor產生後再切到text editor看，很方便 ，基本上除表格外，我都用text editor，自由度較高，比較習慣（個人偏好）。

PmWiki和DokuWiki都是text editor加上輔助按鈕，按了可以產生sample code，DokuWiki的功能強一點，還有特殊符號字元表。語法文件方面，PmWiki列得很詳細，分基本和進階的教學，Wiki裝好後預設放在sidebar上，方便查詢。DokuWiki則是放在編輯頁面的上方，點了syntax鏈結後可以看到全部語法和範例，也滿清楚的，文件部份PmWiki和DokuWiki都不錯，MoinMoin因為GUI editor太方便了，我還不知道它的Wiki code文件放在那，因為一次也沒查過。

雖然乍看下PmWiki editor較弱，但我最喜歡PmWiki的Wiki syntax，簡潔易讀。而section editing部份，DokuWiki預設就有，PmWiki要裝plugin SectionEdit，而MoinMoin的作者認為可以用Include page的做法，而不需要section editing的功能，所以沒有這功能。

Parse invalid HTML by Hpricot (2)

關於Hpricot的基本介紹，可以參見前篇，Hpicot的API文件可以參見這篇和這篇，怪的是好像沒在官網看到連到這些API網站的鏈結，我從Google找到的。Hpicot雖然好用，但文件似乎沒有很齊，這裡簡單說明crawl web pages會用到的部份。

開檔

可以從檔案或URL開啟，用法：

require 'uri' require 'open-uri' require 'rubygems' require 'hpricot' doc = Hpricot(open('http://fcamel.twbbs.org/'))

會得到一個Hpricot::Doc物件，接著可以使用search()找出特定部份的資料，我都是用CSS path，配合Web Developer查CSS path，容易使用。

Search

example code：

doc.search("//div#sidebar.list/ul/li/a").each do |t| ... end

這個例子裡，search回傳Hpricot::Elements，Elements是類似陣列的資料結構，每個元素的型別是Hpricot::Elem。t.inner_text的型態是String，tag內的純文字；t.attributes[…]是Hash，存放各屬性的值，比方用t.attributes[’href’]取出超鏈結指向的URL。

Hpricot::Elements可以繼續search，可以先取出一大區塊的HTML後，再配合if, else來找資料：

doc.search("//div#sidebar.list/").each do |e| if e.search("//h3.label").inner_text =~ /Introduction/ # find data in <h3 class='label'>Introduction</h3> ... elsif e.search("//h3.label").inner_text =~ /Related Work/ # find data in <h3 class='label'>Related Work</h3> ... end end

MoinMoin Wiki心得

簡介

MoinMoin官網

聽老光頭說，在他接觸的open source project裡，用MoinMoin當Wiki的居多，看到Fedora官網做得如此精緻，想來試看看MoinMoin，適合的話可以用來做lab首頁。

MoinMoin是用Python寫的CGI，由於用到CGI的緣故，裝起來比PHP寫的Wiki麻煩一些，由於安全考量，通常各目錄預設都是不能執行CGI，所以apache要多做設定。雖然沒有PmWiki或DokuWiki這麼好裝（1 ~ 5 mins即可裝好），但相較Twiki來說，MoinMoin Wiki好裝許多。

安裝

官網的安裝教學頗為散亂，我大概和MoinMoin Wiki的文件不合，有時寧願自己試也懶得翻文件，總覺得文件的脈絡沒有整理清楚。相較之下PmWiki和DokuWiki清楚多了。

1. 從官網下載
2. 解開後，參照Basic Installation執行安裝的script：
   

   python setup.py install --install-data='/usr/local'

3. 參照Wiki Instance Creation新增Wiki base，直接用網上提供的script較快。
4. 從網頁上按 login -> UserPreferences 註冊account，修改wikiconfig.py：
   

   superuser = [u"YourAccount", ]

   設定permission：

   acl_rights_before = u'YourAccount:read,write,delete,revert,admin Known:read All:read'

   Known表示已註冊使用者，All表示所有人(包含未登入者)，這樣設完包含註冊的人和guest在內，預設權限都是唯讀，需要其它權限的話再改acl_rights_before。

（待修，改天再補完整點）

過程裡有錯誤發生時，可以參照web page的回應，或是看/var/log/http-error.log，error message寫得很清楚。可能會遇到的問題像CGI不能執行、Python版本不對或缺Python module，或是改config檔時沒照Python規定的縮排，懂一點Python有助於除錯。

Plugin

對我來說，一個Wiki的好處，除了安裝容易、Wiki code好寫、權限設定完整外，最重要的是plugin的質和量，這裡簡記一些plugin相關的心得。

對MoinMoin來說，

wiki code: [[XXX(args)]]

parser讀到這行wiki code後，會呼叫data/plugin/macro/XXX.py內的procudure “execute(macro, args)“。

相當簡單易懂的plugin做法，把plugin的python code放到data/plugin/macro/下，即可使用（CGI每次都會重讀，但standalone server可能要重跑server），因此史上最簡單也最有威力的plugin：in-line HTML，只要這麼寫:

in data/plugin/macro/HTML.py：

def execute(macro, args): return args or " "

wiki code example，貼flickr的圖（兩行合一）：

[[HTML(<a href="http://www.flickr.com/photos/12203797@N00/287454598/" title="Photo Sharing"> <img src="http://farm1.static.flickr.com/112/287454598_d5c67feb2a_o.png" width="555" height="376" alt="couplet" /></a>)]]

表格

MoinMoin的table可以做到rowspans和colspans，而DokuWiki和PmWiki做不到colspans。使用table必備的plugin：MiniPage

雖然code有點醜，但透過MiniPage可以在table cell裡塞wiki code，做到像是table內的list，table中的table應該也OK，我沒試就是了，因為wiki code必需寫成一行，可讀性接近於 0，詳細介紹參照MiniPage上的說明。

surge protection

原意是避免被DoS，讓使用者各項操作到限定數量後，禁止對方的操作，但在我反覆測試編輯的情況下，反而是我一直被封，要等一會才能用。雖然可以調高限定數量，但還是很麻煩，後來發生狀況後我就直接砍surge log ( data/cache/surgeprotect/surge-log )。

ps.

• WikiMatrix有四個database用flat-file（用檔案當DB)的比較，寫得比WikiPedia上的介紹清楚。
• Wiki推廣，安裝PmWiki
• DokuWiki推廣

有機會的話，再來寫篇三個Wiki的試用心得，現在是覺得各有好處，不見得那一個比較好或比較不好。