cahier lukhnos, a blog

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

其他的圖可以看這裡。

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

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

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

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

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

lukhnos :: Aug.08.2008 :: :: 2 Comments »

為了要研究 iTunes 幫 iPhone / iPod Touch 備份出來的資料，寫了一個名叫 mobilesync-inspect 的 open source 小工具。

然後因為考慮到 iPhone 使用者不全是 Mac 使用者，因此在想這個工具應該也要能在 Windows 上執行。

如果是自己用的工具，那選擇很簡單，我可以裝 Python 然後跑 iphone-backup-decoder ，或者類似的 scripting language。

但如果還希望一般的 Windows 使用者也能使用這樣的工具，或者說希望不要有安裝 scripting language 的額外需求，那就應該寫成獨立的應用程式。

要在 Windows 上開發應用程式也簡單，選擇很多。不過我卻又希望能跟工具的 Mac 版本共用同一組程式碼。

主要關鍵還是在於怎麼讀取 iTunes 幫 iPhone / iPod Touch 做的備份資料。格式是 Apple 的 binary property list。然後我並不想自己照著公開格式寫 parser。更何況我不只希望工具能讀，還要能寫。

於是想到了利用 Apple 自家的 CoreFoundation （以下簡稱 CF）。CF 有一點像 glib ，提供了很多基本的資料結構操作，然後透過類物件導向的方式來使用，而且有貫通的記憶體管理機制（使用 reference counting）。

不過，雖然 Apple 說 CF 有 open source，但顯然現在放出來的版本，不是你自己編得起來的。Apple 自己提供了預先編好的版本，library 連同標頭檔，供 WebKit Windows 版本開發使用。去 WebKit 網站點個同意書就可以抓到。

抓完之後，就可以用 CF 來撰寫 Windows 程式了。不過，編出來的東西，最後還是得要倚賴 Safari for Windows 提供的四個 DLL 才能執行。

所以嚴格說來還是沒有達到「建立獨立而使用同一套 code 編成的執行檔」的目標，還差那麼一點點。

但是，用同一組 C++ 程式碼，確實可以 build 岀給 Mac 還有 Windows 使用的執行檔了。

lukhnos :: Aug.08.2008 :: :: No 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 :: :: 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 :: :: 7 Comments »

批評教育的好處之一是不是專家也能做，而且不用負責任。

所以以下：我還是覺得國文作文的考法，像是某種歷史的幽靈。或者問個比較公道一點（不過請看本文第一句）的問題：考創意寫作（creative writing）到底是不是考語文科目的核心價值？

拿另外一種語言來對比吧。不管是外國人為了入學而要考的 TOEFL，還是研究所要看的 GRE，寫作在美式英文體系裡可以說是一種公式化的實用文類：為了解說和分析問題所做的議論／解說文（expository writing）。公式化能到什麼程度呢？公式化到了考試題目源自於題庫，而主辦的 ETS 會在手冊上告訴你說，你的寫作分數有一半是電腦出的──一定程度上你甚至就是在跟某種高階版的拼字文法檢查程式在鬥法。不過盡管如此公式化，沒有一點實力恐怕還是鬥不過 grammar checker 的，不然補習班的生意就不會永遠做不完了。

相比之下，嗯，國文作文，真的比較像在考 creative writing。可惜國文老師，或者更準確地說，國文老師的老師（i.e. 那些為學子們的國文程度憂心的大儒們）不會告訴你的是：只有極少數的人會成為作家。當然我們也可以問得更機車一點，好比說，這種考法（同時也可以把維護文言文教學的比重與體制等事情給算進去），到底是誰會得利呢…… 之類的。

可能受到國文的影響，我們的英文作文也什麼水果過了海變成什麼水果’。於是我兩年前寫了這篇。當然不是認真的。

lukhnos :: Jul.04.2008 :: :: 3 Comments »

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

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

lukhnos :: Jul.04.2008 :: :: 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????) _ui_config_button (_configButton…. why_is_this_stuff_named_this_way?!!) 這樣的東西了吧。我也會記得變數跟 operator 之間一定要有空白、大括號要打在正確位置、還有絕對不斷行（這一點是從 Delicious Monster 作者 Wil Shipley 學來的，他曾經說過類似人類發明寬螢幕就是給你寫程式不斷行用的、類似這樣的話）。

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

lukhnos :: Jul.04.2008 :: :: 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 :: :: No Comments »

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

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

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

lukhnos :: Jun.30.2008 :: :: 7 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 :: :: 2 Comments »