cahier lukhnos

我在很久以前的一篇文章中，提到了注音跟漢語拼音的轉換規則。

不久前我收到這篇pingback，說我的說法是有問題的，其中有一些例外。

我想該文作者顯然認為 pinyin.cin 跟 bpmf.cin （原來為 phone.cin）的資料就一定準確。而諸如「誒」被標為「ㄝˋ」，因此注音符號跟漢語拼音並不存在一對一的對應關係。

回顧來說，我當時的文章在討論拿這兩個原始資料來驗證時，就應該加註這一句的：「根據這兩個 cin 檔來說……」。

事實上，在「正規」的 Mandarin 系統中，ㄜ跟ㄝ是互斥的，而且ㄝ一定跟隨著ㄧ。就如同ㄐ跟ㄓ是互斥的道理一樣（ㄐ跟ㄓ後面不可能接相同的組合）。這也就是為什麼當初漢語拼音的設計者用同樣的拉丁字母 e 來代表這兩個音：因為用注音符號寫成的ㄝ這個音素只可能出現在ㄩㄝ跟ㄧㄝ的場合。也就是說 ue 跟 ie 中的 e 只可能轉換為ㄝ，而其他時候都只會是ㄜ。這是 Mandarin 語音系統的規律。漢語拼音的設計者同注音符號的設計者，這些學者們，當然是認識到了這個規律、服從了這個規律的支配，並且最大程度地掌握了這個規律所起到的作用，從而派生出了一個教學及語用上不會造成歧異的系統。

如果拿 pinyin.cin / phone.cin 的幾個例外來說這套轉換規則只有 “99.519%” 場合正確，那可能是對中文輸入法的資料可靠性有很大的誤會。:)

lukhnos :: Oct.23.2008 :: nil 無分類 :: 1 Comment »

這一陣子在 open source 這一塊的工作，主要是在為 OpenVanilla 0.9 做準備。目前這個名為 Oranje 的 branch 已經初步可以運作了，恢復到差不多 OV 0.6 時代的功能。

我們這一次決定打掉 OV 0.7 的 CocoaVanilla ，決定改用 IMK (InputMethodKit) 重寫 loader。IMK 應該是業界 OS-level 最棒的輸入法架構，而確實目前改用 IMK 重寫的部份，就比先前 CocoaVanilla 省下了超過一半以上的程式碼。

但是… OS X 10.4 Tiger 的使用者怎麼辦？

IMK-Tiger 是我們提出的解法。我們直接在 OS X Tiger 上架構一個 InputMethodKit 模擬層，對原本 IMK-based 的 input method server 來說，幾乎是透明的。也就是說，我們藉由這個 emu layer ，可以達到使用同一份 code base ，就可以產製出 OS X Leopard 跟 Tiger 都能使用的輸入法元件了。

IMK-Tiger 放在 Google Code Hosting 上。zonble 寫了完整的中文介紹。英文的 announcement 發表在 OV 討論區。

lukhnos :: Oct.20.2008 :: nil 無分類 :: 1 Comment »

原本以為春分秋分跟夏至冬至在外語是很難的字，結果英文的「分」是 equinox，「至」是 solstice。Equi- 是相同的意思 (例如 equivalent)，nox 是夜晚（例如夜曲或夜景叫 nocturne），sols- 是太陽（例如 solar），-stice 是停止（例如停戰是 armistice）。

很多年前大概因為這樣的機會，發現原來字根這麼奧妙。

我曾經在一個會議場合被一位顯然熱愛東亞文化的白人問：為什麼「你們」的公司都喜歡取洋名。言下之意好像是說「我們」的公司名稱一定非得要是什麼拼音轉寫之類的。

我倒反而覺得商品命名這種事情應該符合某種世界性市場性¹。Panasonic, Acer, Lenovo 都是這樣的例子。他老兄不知道是不是某種（事實上也是他的同胞發明的）所謂文學院念的XX研究讀太多了，對於他人使用歐語字根一事很有意見咧（況且，許多此類廠牌，到了別的語言中，或也有其他轉化為其他語言涵意的別種商標名，何必以文害義？）。這件事情倒是驗證了一個觀察：否定他人自主的選擇還自以為在主持（文化？政治？歷史的？）正義的人，說不定就是最不正義的呢²。

因為今天是秋分而也很久沒有寫 blog 了，充數一筆。

註 1: 可能我最近《壹週刊》看多了，每每看到「XX 性」(xx-bility)，就很想造句一則 (à 給我報報ienne)…… （以下省略一百字）

註 2: 這種鳥蛋的事情最近就有一則，還發生在 Ruby on Rails 身上。請參考這裡、這裡，還有這裡。我這麼說啦，這種操作手法叫做沒骨頭又不專業。有人抗議也不聽聽人家怎麼說，24 小時內就把 framework 當中一個每個人都在用的元件隨便 deprecate 掉然後又直接搬走，然後一邊跟所有 open source developer 宣告不要碰這個東西，一邊又跟抗議的人教誨：你要珍惜你得來不易的自由。Wow, 我從來不知道自由是這樣被尊重的，還是說你的自由比我更自由，還要我們立正站好乖乖學習？

lukhnos :: Sep.22.2008 :: nil 無分類 :: 4 Comments »

Einmal ist keinmal.
只發生過一次的事情，跟沒有發生過是一樣的──德諺

Jamais deux sans trois.
有二必有三──法諺

1. 如果你沒在使用undocumented API，那一定是因為你的程式沒什麼了不起的
2. 過早求最佳解乃萬惡根源 (Premature optimization is the root of all evils)。
3. 沒有人想當醜男或醜女。實際在出貨運轉的程式會醜，有一半是因為經歷了歲月的風霜。另一半原因是錢付得太少。
4. 關於技藝 (tekhnologia) 與複雜性：「人生苦短，技藝博大，機會稍縱即逝，經驗不可信賴，判斷甚難做成」
5. 沒有一套重要的GUI應用程式是沒有客製UI元件的。
6. 與上一條相關的是：一套重要的GUI應用程式，必然至少有一處違反所在平台UI guideline的地方。
7. 所有web的應用程式都不怕沒人用，都怕太多人用。
8. 要重視歷史。傳道者說：已有的還會再有，已來的還會再來。有時候要解決問題，最快的方法，是去幹一段 Win16 (我沒有在開玩笑) 或者 OS 9 或者 NeXTSTEP 時代流傳下來的 code …
9. 如果平台廠商跟你說，使用某某私有 API 是危險的，他們一定在隱藏什麼不方便的真相。例如，妨害競爭對手。不要太相信平台廠商說的話。
10. 基本上對於「我們將在下一版中抽掉某某 undocumented API」一事要抱持懷疑態度。試想：他們如果真的抽換了，那還在使用舊版原廠軟體的人不就掛了？
11. 跟上一條相比，documented API 會在完全沒有解釋的情況下被抽換掉的機率反而是比較高的。你要知道，做狗食的廠商，自己家裡不見得會餵同樣的食物。
12. 關於重新發明輪子。西諺如是說：If something is worth doing, it’s probably worth doing twice!
13. 美好的事物都要做出來了、送到手上才算數。古諺有云：真正的藝術家要有船 (real artists ship)。

lukhnos :: Sep.09.2008 :: nil 無分類 :: 5 Comments »

說來看了圖我才知道，這個遊戲是微軟發行的 (source: Moby Games)：

其他的圖可以看這裡。

這個遊戲對我有兩個意義。

一個是，這應該是我所能記得，孩童歲月的第一套電玩。記憶這種東西是怎麼工作的很難令人理解，但是如果說回憶像是Mac OS X的時光機那樣可以一頁頁倒回去找的話，我對「家裡有台（所謂台製）Apple II」的印象，倒回去第一頁就是那個畫面，找不到其他印象了。那個畫面大概是，我們住在舊家的頂樓加蓋，臥房裡面桌子上的灰色殼子跟綠色螢幕，還有一台嘎嘎作響的軟碟機。開完機後，電玩會用Apple II的單音喇叭，播放著我到現在都還能哼出頭幾個bar的主題音樂。在回憶之中，某個已經忘記確實時間的夏天的冷氣房裡，一台機器的嗡鳴聲響。

然後讓我思考記憶與經驗的另一個本質：需要他人的存在來見證。我隱隱約約記得有那麼一個晚上，放電腦的那個臥房點著日光燈，我爸跟我一起玩「十項全能」裡面的百米賽跑，一個人要按左右，另一個要按鍵盤的 AZ ，然後就看著螢幕上的兩個光點慢慢跩啊跩的跩到了終點線（最後當然都是大人贏）。

這樣的回憶找不到其他人證實了。我妹那時太小，我媽可能在照顧她。我可以找得到其他曾經玩過這個電玩的人，證明這並非子虛烏有的遊戲。但是那個模糊的畫面，那個一頁頁翻回去的經歷本身（Erlebnis），如果只有一個人是沒有辦法成立的。我爸如果還在世的話，問他那個夏天的事，他說不定也還記得一清二楚（他不會忘記這種事情的，雖然不免偶爾補上許多修飾的加油添醋）。經歷的存在需要透過他人的見證才能成立，大概是那樣的一個概念。

今天是台灣的父親節，藉此短文懷念一下我爸。

lukhnos :: Aug.08.2008 :: nil 無分類 :: 3 Comments »

2008 年 7 月 12 日的台灣版《蘋果日報》：

而網路上已有iPhone 3G破解圖，打開iPhone 3G發現，電池比上一代更容易拆解，對玩家來說，意謂電池較易更換，而軟體也已被破解，另外App Store線上商店同步上線，可以提供iPhone 3G使用者，付費上網下載500個遊戲與軟體，其中還有一款記帳軟體是台灣人製作，軟體與遊戲下載將使iPhone 3G更好玩。

有附圖介紹 TapExpense 喔。

另外：我們已經把 TapExpense 1.1 送進 App Store，目前還在等待 Apple 核可上架…… 這個過程相當漫長，我們也只能天天去查看上架了沒。我們陸續收到使用者意見，1.2 版會加入其中幾個重要的改進建議項目。
有附圖介紹 TapExpense，正在努力中。

此外，大家應該知道我說的「Apple 對 TapExpense 開的大玩笑」是什麼了吧…… （提示：Seller name）。這個問題還在等待 Apple 解決。在此之前，有人提議，我何不順水推舟，去把護照的 also known as 改成這個…… 囧啊！

lukhnos :: Jul.12.2008 :: commerce 工商服務 :: 2 Comments »

我們在今天發表了 TapExpense 1.0。這是 zonble 和我開發的第一套 iPhone 商業軟體。我們也很幸運能在 Apple iTunes Store 的 App Store 首賣的第一天同步發售。我們與其他 500 位左右的開發者共同見證了這個橫跨所有時區的大事件。

TapExpense 是一套為 iPhone/iPod Touch 設計的記帳軟體。軟體最大的特色，在於能夠容納各種不同貨幣的支出記錄。同時，它也提供了自行建立分類與支付方式的功能，並提供簡明的報表和匯出 .CSV 格式資料到 e-mail 中的功能。有了 TapExpense，我們在旅行途中也能輕鬆收集支出資料，方便日後在手機中直接查看整理，或匯出至試算表中運用。

設計這套軟體的想法，源自自己的記帳習慣：我從 1994 年開始學用 Excel 記錄個人支出，從 1996 年後無一日間斷。於是 TapExpense 一定程度反映了我的習慣，以及我需要的歸類方式：依照日期、分類、支付方式，以及一個許多記帳軟體都忽略的，幣別－－這一點對旅行中的人非常重要。

儘管本質上是簡易的資料型軟體，實際呈現上還是遇到了不少考驗。Zonble 與我花了許多時間在調整介面。我們希望 TapExpense 用最簡單的方式完成「在行動裝置上整理支出記錄」這個明確的任務。我們還在努力改進中：1.0 交付不久，我們馬上著手進行 1.1 的改版工作。1.1 版目前已經交出。已經購買 1.0 版的使用者，在 Apple 核可發佈 TapExpense 1.1 後，就可以透過 AppStore 自動更新功能來免費取得新版。

同時，我們也在著手加強使用者介面、外觀、安全功能，以及研究如何做匯入／匯出／同步等功能（OmniGroup 的 OmniFocus 提供了不少啟發：透過既有 desktop app 及 Bonjour 進行同步化）。

我們應該是台灣頭幾群（甚或是第一群）取得 iPhone 軟體開發資格並且正式發表軟體的團隊。開發的過程讓我們學到（或 un-學到）很多與過去滑鼠／鍵盤／視窗人機介面不同的概念與作法。

TapExpense的支出記錄畫面 (其他畫面)

更重要也更有趣的事情是：此一類新的介面，能夠帶來那些新的應用，或是，如何讓傳統的應用有不一樣的生命？

總之，zonble 和我踏出了小小的一步。希望 TapExpense 實用、合用。我們會繼續努力為大家帶來好的行動軟體。

至於開發過程與心得，或是我們對於此一模式所觀察到的一些想法或問題，或容後再敘。要先來補充想念已久的睡眠才行……。

Zonble 也針對 TapExpense 做了更詳盡的介紹，詳見此處。

在此要謝謝所有 TapExpense 的用戶及支持我們的朋友。很榮幸一起見證這一刻！

註 1：TapExpense 定價為美金 4.99 或其他貨幣相近價值價格。TapExpense 1.0 可在裝有 iPhone OS 2.0 的 iPhone 2G/3G 或 iPod Touch 上執行。1.0 版本選單語言有繁體中文及英文兩種選擇。軟體於各 iTunes Store 上銷售。Lukhnos D. Liu 及 Weizhong Yang 著作權所有。詳細資訊可參考 tapexpense.com 或者直接進入 App Store 商品頁面採購。

註 2：TapExpense 的 App Store 頁面上，藏了一個 Apple 開的大玩笑 :p

lukhnos :: Jul.11.2008 :: commerce 工商服務 :: 17 Comments »

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

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

lukhnos :: Jul.04.2008 :: tekhnologia 技術或者藝術 :: Comments Off

我第一次幫人家撰寫命名跟縮排法則是在很早、很早之前的事了。訂立這些規則是一件很有樂趣的事。或許這是某種奇怪的愛好。後來在棄絕的那些漫長的日子中，曾經一度把某一版 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????) _ui_config_button (_configButton…. why_is_this_stuff_named_this_way?!!) 這樣的東西了吧。我也會記得變數跟 operator 之間一定要有空白、大括號要打在正確位置、還有絕對不斷行（這一點是從 Delicious Monster 作者 Wil Shipley 學來的，他曾經說過類似人類發明寬螢幕就是給你寫程式不斷行用的、類似這樣的話）。

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

lukhnos :: Jul.04.2008 :: tekhnologia 技術或者藝術 :: 4 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 :: litteris 字與詞 :: Comments Off