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 »

長年以來我一直在尋找這一句諺語的源頭：optimum inimicum bono。字面上的意思是 “perfect is the enemy of the good”。原本一直以為會是哪個羅馬詩人的句子，最近發現似乎更像是伏爾泰（Voltaire）說的：le mieux est l’ennemi du bien。也有義大利文版本謂：il meglio è l’inimico del bene。但照這樣講起來拉丁文版本的存在應非不可能，卻始終尋找未果。

每次打開編譯器的最佳化選項時，都會想到這句話。嗯，雖然其實原意並非如此啦。

lukhnos :: Jul.01.2008 :: ことば 言語文字 :: No Comments »

一點近況，或者，毋寧說是一點思考。前陣子寫完那篇抱怨捷運的文章後，開始在思考什麼是「不滿」，以及改善的可能性。就好比說捷運這一件事好了，一個可能很容易有說服力的論點是，「你看人家國外的地鐵上都沒有/不需要這樣那樣的標示」。但是拿別人當參考點，很可能一開始就輸了，變成了一種自我擊敗（self-defeating）的起點。佐證這種事情可以比上不足比下有餘。最末改善還是要從自身的不滿/不滿足出發的。然而接下來的問題就變成了，你的不滿未必是我的不滿。要怎麼溝通、傳達、「使跨越」、「把點開回家」我的不滿呢？聽起來好像是要把我的牢騷餵食給你。並不是，也不該是這樣。在我的設想當中，不滿應該是從價值出發的。好比說我的價值是訊息應該足夠就好、反對畫蛇添足的美學價值（是的，我後來覺得畫蛇添足不是一種「問題」，而實實在在是一種價值體系）跟教條主義（一種認為事情只要由上到下「宣達」了──一種人類最古老的語言表演──就會完成的信仰）、善用歐康的剃刀法則（Occam’s Razor）跟常識。不滿不一定必然或非得是情緒上的，不滿也可能來自於空缺──這是不滿最本初的字義──一種等待被填入新事物的狀態。

雖然最初的出發點還是捷運，但是之後想的其實是，我們要怎麼樣才能從自己所感受/感知的不滿中尋找改善的可能。而不是永遠從參考點來告訴自己其實很suck，或是其實還不錯。這樣的事情。生活如此，制度如此，軟體也是這樣。

驚覺很久沒有更新 blog。顯然我對這件事情還沒有太多發自於內心的不滿。

lukhnos :: Jun.30.2008 :: realitas 真實殘酷的世界 :: 5 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 »

Lipogram 在歐語中是一種具有難度的文字遊戲。簡言之就是刻意限制不使用某幾個字母來寫東西。例如，刻意不用字母 e 來寫詩，或是重寫莎士比亞作品（真的有人這麼做過）。

那麼作為漢語書寫用的中文，有沒有這樣的東西呢？

今天想到一種：sinojapanocoreanogram (”CJKgram”)，意思是僅能使用中日韓共通的漢字來書寫。規則很簡單，不能使用另一種書寫系統不存在的字符。例如「書寫」就不能用，因為並非（嚴格定義上的）簡體字字符。

於是，以下這句話：

「僅能使用中日韓共通的漢字來書寫，繁體字才有的，或是簡體字才有的，就不允許使用。」

就可能得書寫成：

「只能使用中日以及其中那地方等三地的方型字做文，很久以前就在用的字才有的，或是容易一些的字才有的，就不能使用。」

（很不幸的，韩国的相关称呼或历史称呼，高丽、朝鲜、新罗、百濟似乎都没有好的通用字。「汉字」很不幸地本身就是非通用字。）

相對之下，antebellumkanjigram（我自造的詞，意思是使用「二次大戰前日本還沒將和製簡化漢字標準化後的漢字來書寫」）就容易多了。上述句子只要改掉「書寫」一詞就可以了，因為日文漢字似乎做「冩」（無上頭的一點）。

當然，對本身就使用繁體字的我們來說，magnacinquogram macropentagram (”Big5gram”)，或是對本身就使用簡體字來書寫的人來說，extendronatiogram (”GBgram”) 就是沒有意義的了。

一但開始練習 sinojapanocoreanogram ，就會發現有太多繁體字的常用字，在簡體字中都被簡化過（主要是偏旁部首造成的）。因此如果僅限制使用通用字，書寫的難度，看來是要比 Simple English 要難得多，如上例所示。

當然，如果按照趨勢，未來可預見，台灣各地將越來越多簡體字標示或說明，那麼除了簡繁轉換filter外，或許針對兩種文字的書寫慣例（句法風格或文法差異）的探討，也會增添更多實用價值。

註：其實， -gram 用拉丁前綴是不對的。But (1) they are all Greek to me, (2) 計算語言學家自己就用 bigram 了（照理說應該是 “digram”）, so…

lukhnos :: Apr.23.2008 :: ことば 言語文字 :: 1 Comment »

Update: 的確，還有一種場合會把 closing credit 放完，那就是有 closing credit 裡面有安排花絮的那一種。

在朋友 MSN 上看到這樣的串連活動：要求電影院把電影的完整片尾給放完。

我從來不參加串連，所以就不列出網址了（搜尋一下很容易找到）。我看了一下原發起人的文章和相關回應，很有趣。

我所記憶以來，台灣只有兩個場合會把片尾，所謂 closing credit，給完整放完。一個是影展。一個是外商影城。後者就我最近經驗，也每下愈況。

生活中保有一些「對完整的堅持」有這麼困難嗎。更何況，我們講的是「作品完整性」這一件事情呢。

就實用的價值來看，片尾有好幾種功用。會放 NG 或搞笑片段的電影排除的話，closing credit 一定會提供的資訊有：演員名單、工作人員名單、音軌清單、拍攝地點。

我其實並沒有對 closing credit 做過什麼有系統的研究。不過很可能這是小時候養成的癖好（我曾經被家人問過：為什麼就是非得把片尾看完？），再加上對名字（事實上是任何的名詞）有狂熱，我的粗淺觀察是，從小到大看的科幻片中，”visual effect” 或 “computer graphics” 一項，80 年代出現過不少日本人，90 年代華人的名字比較多，到了近十年，則幾乎非歐美人士的名字裡，都是韓國人的名字。所以，或許 closing credit 也可以視為某種產業指標？

這種都是實用主義傾向的辯護就是了──就如同我看書本的 colophon 或 copyright page 是為了想知道書本是用哪一套字體編排，或是買成藥看 fine print 是想要知道不能喝完酒後服用一樣。（事實上我有個理論是，廣告、保單、軟體授權，這些裡面的 fine print 其實我等現代人的 daily ritual，不過這有待來日說明吧）。

但是，實用的價值之外，或許更重要的還是那些一點都不實用、一點都對電影「播放」本身都沒有影響的、形而上的東西吧？保有作品的完整性，難道不是一種對作品的尊重嗎？就好比說，書本不可能截去封面封底來販賣一樣。聽音樂會，大家也不會在樂團謝幕之前就開燈走人。那麼為什麼電影不可以呢。

更何況，大家恐怕無法想像，影展片如果遭受這種對待，會是什麼德性吧。那為什麼一般的電影就不行呢。

其實會坐在觀眾席上把片尾看完的人還真不少（看影展就知道了）。有些人說，「片尾哪有什麼人看」。這其實是倒果為因。正是因為台灣太多不播片尾的電影院，大家也只能燈亮走人啊。

lukhnos :: Apr.21.2008 :: realitas 真實殘酷的世界 :: 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 »