cahier lukhnos, a blog

… 所以困難的事情才正要開始。

這大概是在邁入多核 64-bit 又要考慮 multithreading 又要考慮跨平台的年代裡開發 framework 的某種感想吧。

lukhnos :: Jul.04.2008 :: tekhnologia 技術與藝術 :: No Comments »

我第一次幫人家撰寫命名跟縮排法則是在很早、很早之前的事了。訂立這些規則是一件很有樂趣的事。或許這是某種奇怪的愛好。後來在棄絕的那些漫長的日子中，曾經一度把某一版 MLA Style Guide 給整本 k 完，而且竟然對於「到底句點要放在括號前還是括號後」或是「在又有引號又有括號的句子裡，句點要放引號裡、引號外、還是括號外？」這種事情覺得津津有味。這一定是某種不正常的表現。

重新寫起程式之後，倒是花了相當、相當、相當長的時間，才又像某種緩慢的吸體一樣，把對命名和縮排規則的看重，變為自己的一部分。然後看著自己從前寫的 code ，就會不可思議起來：天啊，我真的當時允許自己寫出這樣的東西來？！

但即使到了現在，我們仍然不時會為命名規則所苦。這裡講的是廣義的命名規則，還包括了標點符號、斷字、大小寫。我們會為了，好比說，Objective-C 的 instance variable 到底要用底線開頭（Apple/WebKit 風格）還是 m_ 開頭（業界普遍流傳、或者說某種被 MS 污染〔誤〕的 C++ 風格），就讓我們頭痛不已。那麼 Interface Builder 相關的成員呢？

命名麻煩的地方在於，它會隨著時間和潮流的改變而跟著變化。甚至，其實命名或許是第一個反應變化的事物，因為世界本來就是在命名之後才生的（這一點可以扯上更多思考與說法，在此不表）。當我們發現 Apple 竟然自己有 sample code 開始使用 mSomeVariable 的時候，著實訝異，卻還猜不透：這種命名改變背後究竟是被什麼考量所驅使的呢？

然後是看到大公司發表的 C++ 寫作風格。閱讀該文件，有如某種經文研究，裡面竟然每一條規則都以某種詰問或者至少是 pros and cons 體裁撰寫。

風格沒有一定，貴在一致和便利。但是大公司的寫作風格跟我認知或習慣所用的很不相同。有的甚至完全逆著我的考量而行之，有的則是在、例如說、前十條規則如此成立之後，就不得不然。

另一方面，這種由諸多規則堆積起來的風格，必有相當多的例外、互相衝突之處（於是又回到了以前學外語時，課堂的鐵律：規則是為了例外而存在的……），以及某種因為要想辦法推廣至每個環節，而某種制度必然帶來的不快（照說風格跟規則不至於帶來情緒……），但是這個世界往往以我們難以理解的方式彰顯自身。我們以為掌握風格，結果是風格在撰寫我們。

不過，再怎麼說，我應該再也不會、也不敢、也不願，寫出像 fooidx (fooIndex), barcnt (barCount), lahlahrfcnt (lahlah… WhatThe????) 這樣的東西了吧。我也會記得變數跟 operator 之間一定要有空白、大括號要打在正確位置、還有絕對不斷行（這一點是從 Delicious Monster 作者 Wil Shipley 學來的，他曾經說過類似人類發明寬螢幕就是給你寫程式不斷行用的、類似這樣的話）。

就好像我會記得大標題裡面 a 不能大寫但 The 首字要大寫那樣……

lukhnos :: Jul.04.2008 :: tekhnologia 技術與藝術 :: No Comments »

不少使用者曾經回報：「我的 OpenVanilla 不能用了，備份碟上的也不能用了，裝回 0.7.2 也不能用了……」

我們曾經為了這個問題困擾很久。現在犯人抓到了：Logitech Control Center。

跟一位 Growl 開發者通過信後，發現受害者名單還包括有 Growl (另有FAQ ), TextMate, AquaTerm, CrossOver games 等等。

技術上的原因是 Logitech Control Center 搶走了 Cocoa 應用程式的 [NSConnection defaultConnection]，以致於任何以這種方式取得連接的軟體，都有可能 break。這樣說好了：你好歹也是個泛應用程式層級的 plug-in，怎麼可以寫出會把應用程式搞爛的 code 呢？

雖然說 Growl 已經提出了自己的繞行方案 (workaround)，但是問題根本還是出在 Logitech 使用了非常、非常、非常、非常、非常糟糕的程式寫法。

上述 TextMate 的連結中有針對「到底是誰的錯？」做討論──許多使用者一開始會怪罪 TextMate。比較有建設性的作法，說真的，還是應該請 Logitech 用家們寫信給 Logitech 工程師。

其實感覺很不爽。Logitech 這種搞法，用一句話來說，叫：乞丐趕廟公（khit-tsia̍h kúaⁿ biō-kong）。

太不專業了吧。

lukhnos :: May.24.2008 :: tekhnologia 技術與藝術 :: 2 Comments »

iVanilla 的想法是由 ycchang 於 2007 年十月的時候提出的。最早的想法是希望在 iPhone/iPod Touch 上利用當時的 “Toolchain” 製作出一個簡單的、作為概念實證 (proof of concept) 的 OpenVanilla 實作。所使用的方法也是當時各家 iPhone/iPod Touch 輸入法外掛所使用的 dynamic library insertion （透過 DYLD_INSERT_LIBRARIES 環境變數指定）。

對我們來說，iVanilla 的 code 主要還是在驗證 OpenVanilla 框架的可移植性。用 C++ 簡單撰寫的 “MinimalLoader” 實作了所有 OV 模組所需要的基本功能：對於組字區與選字列的操作。

這個實驗是在 2007 年 10 月至 11 月間進行的。ycchang 並於去年的 COSCUP 2007 中簡單討論過 iPhone/iPod Touch open source toolchain 的概況。我也在 ycchang 之後簡單介紹了符合 OpenVanilla 框架規格的 minimal loader 的實作方式。

不過，受限於我們各自的狀況，我們後來都無法繼續關注 Toolchain 的發展。另一方面我們傾向認為，使用非官方的工具開發這類型系統軟體，還是有不少潛在問題。（我個人並沒有在 iPod Touch 上輸入大量文字的需要，實驗的動機也因此偏向 OV 驗證更甚於實用）。「非官方」的 iPhone/iPod Touch 輸入法方案已經有相當多種，從許多消息來源觀之，Apple 官方也應該會推出自家的亞洲文字解決方案。

本次送進 OpenVanilla source repository 中的 iVanilla 是當時完成的 SimpleBPMF 及 SimpleCJ，亦即簡單的傳統注音輸入法及倉頡輸入法。各自目錄中的 README.txt 有更詳細的說明。

由於我們都很久沒有在近期的 Toolchain 及 firmware 上編譯這個實驗，我們無法確定現在的 code 仍能使用。另外，我們也無法回答任何跟實驗有關的問題。本次釋出的 code 係以現狀提供 (”AS IS”)。請自負任何使用上的風險。

iVanilla 中所使用的 OpenVanilla 程式碼，以及 iVanilla 的 MinimalLoader、平台相依的本體部分，都以 OpenVanilla 的 New BSD License 授權方式釋出。如果你要將 iVanilla 使用在你的程式碼中，請遵守程式碼的授權。程式碼的著作權為作者群所有。

lukhnos :: May.20.2008 :: tekhnologia 技術與藝術 :: No Comments »

住台北縣的人可能聽過這一句：

永和有永和路，中和也有永和路， 中和有中和路，永和也有中和路； 中和的中和路有接永和的中和路， 永和的永和路沒接中和的永和路； 永和的中和路有接永和的永和路， 中和的永和路沒接中和的中和路。

最近發現，世界上存在不少類似結構的東西，例如：

Vista 64 有 System32 ，也有 SysWow64，System32 裡面裝的是 64-bit 的 binaries，SysWow64 裡面裝的是 32-bit 的 binaries。Vista 64 的 64-bit binaries 不能放進 Vista 64 的 SysWow64 裡，Vista 64 的 32-bit binaries 不能放進 Vista 64 的 System32 裡。

又或者：

Cocoa 有 NSString，Carbon 有 CFString，Cocoa 的 NSString 可以接 Carbon 的 CFString，Carbon 的 CFString 可以接 Cocoa 的 NSString。Carbon 的 CFString 沒有 garbage collection，Cocoa 的 NSString 有也可以沒有 garbage collection。Carbon 的 CFString 可以接到 Cocoa 沒有 garbage collection 的 NSString 裡，Cocoa 有 garbage collection 的 NSString 不能直接接到 Carbon 的 CFString 裡。

對，總歸一句話就是，不鬼打牆時候就不會覺得這樣的設計會鬼打牆，鬼打牆的時候就真的覺得這樣的設計真是鬼打牆……

lukhnos :: Apr.30.2008 :: tekhnologia 技術與藝術 :: 5 Comments »

投影片在這裡。

應 OSDC.tw 的邀請，上週六下午給了一個題目為「開放原始碼、開放資料與日常生活的語言應用」（Open Source, Open Data in Everyday Handling of Natural Languages）的分享。題目有點長，內容也有點雜。主要的企圖還是在區分日常生活語言問題的種類，以及圍繞在中文的核心問題──斷字──上面。

「問題意識」（problems）上，日常生活的語言問題，主要還是在怎麼將之編目索引檢索。除非你的應用程式本身就是語言應用（language-specific applications）。這個部分有一些地方跟 l10n/m17n/i18n 有重疊處，但這並不是同樣的兩件事。另外一個我試圖（但沒有很成功）想要講述的方向是，我們這些講中文的人應該試圖去處理中文以外的語言，切莫認為我們只需要處理中文就好（而且事實上中文也並非是如我們被教育成的，是一種均質的語言，「中文」本身諸元的差異或許就和中文與其他語言的差異一樣地多）。

在「方法論」（methods）的段落，我簡短介紹了兩種「正規」的方法，基於觀察中文構詞型態的MMSEG以及基於language model的方法。事實上相關的研究很多，implement說來比較偏工程問題。（中文自動選字）輸入法的問題其實只是其中的一種變體，把輸出改成音素，輸出改成可能的最佳句子就是了（用最化約的方法來說）。

在「工具」一段，所介紹的大多數工具仍是以 Perl 為主。Perl 在語言處理上仍然是最強大的語言之一，也是大多數相關工作的首選。我不熟 Python ，所以用 Python 寫的 NLTK 等工具，就無法多說什麼。Ruby 在這方面很弱。當我說「如果你用 C++ ，那沒有人救得了你」時，沒想到大家竟然反應熱烈地笑了。這句話，出自一個還是必須用 C++ 來解決問題的人嘴裡，其實是很辛酸的呀。

「資料」的問題，還是跟 Hans Rosling 在講公共衛生議題的相關 TED talks 的那句話一樣：資料就都在那邊，可是卻沒有辦法開放出來。

準備這次主題的一個額外的收獲是，我深深感受到日文相關軟體計畫，無論在規劃，募集資料、或者看問題的方法、甚或是 C library header file 的組織上，都有很多可以借鏡的地方。另一方面同樣看到的問題是，編碼的需要現代化（例如 anthy 仍是 Shift JIS-based）、程式語言的需要現代化（需要引進 C++ 來使得語言物件──音節、音素、unigram──等等可以被當做型別來操作）等等挑戰。

總之還有很多很多要努力的地方啊。

lukhnos :: Apr.15.2008 :: tekhnologia 技術與藝術 :: 1 Comment »

Flickr 也有 video 了。

雖然有很多評論者馬上拿來和 Google 的 YouTube 擺在一起比較，我倒是覺得，Flickr Video 跟 YouTube 完全是兩種概念的東西。Flickr 的 90 秒短片，一如 Flickr 員工自己說的，比較像 “moving pictures”。另外 Flickr 的 video 是圍繞在「個人」身上，也就是說那些影片跟作為上傳者的「你」是聯繫在一起的。YouTube，一定程度上，比較像一種脫個人化（de-individualized）的 video depot （影片倉儲）。同時你也很難從後者影片的留言串，跟他人建立關係。反之，Flickr 的 comment 很成功地把人跟人給拉在一起。

另外就是 Flickr 員工自己的社群經營囉。例如這個。很可愛不是嗎？

我主觀的欣賞這個新服務，當然有一些同樣主觀的因素啦。好比說，那一年去東京旅遊時，拿 Cybershot 拍的那些爛爛的 video，也終於找到了合適的地方上架。這種東西我不太可能搬到 YouTube 上。但是放在 Flickr 上卻合適極了。套用《空想科學讀本》的說法，適才適所，這樣不是很好嗎？（誤）

lukhnos :: Apr.11.2008 :: tekhnologia 技術與藝術 :: No Comments »

(是的，我有 file 過 Radar, to no avail.)

lukhnos :: Apr.07.2008 :: tekhnologia 技術與藝術 :: 1 Comment »

最近的另一個心得是，

不過，這讓我想起了多年前，歐陽應霽，當他還在幫《壹週刊》寫專欄時，引用另一位義大利設計師的話：「白白的雞蛋也是從雞屁股生出來的」。

不記得確實的用語了，害我很想找到底是典出何處呢。

PS: 把先前寫的一篇blog講得精鍊一點，修正版謂：「如果你沒用過 undocumented API ，一定是因為你寫的程式沒什麼了不起的。」

又，其實何止程式如此呢。

lukhnos :: Mar.11.2008 :: tekhnologia 技術與藝術 :: 4 Comments »

lukhnos :: Jan.22.2008 :: tekhnologia 技術與藝術 :: 3 Comments »