The Old Blog Archive (Traditional Chinese), 2004-2009

Archive for July, 2008

報紙摘錄與 Updates

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 改成這個…… 囧啊!

TapExpense: 我們的第一套 iPhone 商業軟體

我們在今天發表了 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

因為最難的事情我們OS平台幫你搞定了…

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

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

看舊 code

我第一次幫人家撰寫命名跟縮排法則是在很早、很早之前的事了。訂立這些規則是一件很有樂趣的事。或許這是某種奇怪的愛好。後來在棄絕的那些漫長的日子中,曾經一度把某一版 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 首字要大寫那樣……

“Optimum inimicum bono”

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

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