gcc提供了一組供函數／型別／變數用的宣告屬性，其中 __attribute__ ((deprecated)) 對開發API/程式庫的人，是上好的好物。只要在函數／型別／變數宣告後頭加上 __attribute__((deprecated)) ，程式在使用到這些函式／型別／變數的時候，就會顯示警告，跟你說這個函數／型別／變數已經被討厭了（事實上deprecate是個意思蠻負面的字）。
最近覺得所謂API這種事，就是一連串新寵與老梗的混合與鬥爭啊……
不過Objective-C的API作者們，得等到Objective-C 2.0才能在objc method後面加上這個屬性。說了快六年才終於看到，唔，總是「更好遲到比絕不」吧。
（最後那一句是「我不能同意更多」式類語…… XD）。
PS. 重看該討論串，這個gcc功能似乎源起自Apple的需求。
lukhnos :: Jan.29.2007 :: tekhnologia 技術或者藝術 :: 1 Comment »
有人這麼形容用Cocoa寫程式的感覺：
It’s as though you have .NET 3 on every machine, only it’s been shipping since ‘99, and you program in something like Smalltalk, only it’s fast, and in your installer, you can replace files without having to reboot.
lukhnos :: Jan.28.2007 :: tekhnologia 技術或者藝術 :: 1 Comment »
WWDC 2006的相關影片前陣子陸續發布到了iTMS上，WWDC的與會者可以下載回來看。
雖然說OS X裡有越來越多Cocoa相關的程式庫，但是大多數 Core- 開頭的東西還是以 C 言為基礎的 API。意思是說，任何想在OS X深入一點的開法者，起碼還是得了解 CFRelease、NS- 與 CF- 開頭的資料結構的免費橋接 (“toll-free” bridging)，這一類 CoreFoundation 的基礎。
有人曾經問我：到底 OS X 上能不能用 C++ 來開發？更進一步的問題是：難道一定得在 C (Carbon) 和 Objective-C (Cocoa) 間做選擇？
我本來還真找不到什麼好的說法，結果意外在 survey Managed C++ 的時候，讀到這一段 Microsoft 的人寫於 2001 年的話，我笑了：
Unfortunately, as powerful and flexible as managed C++ is, it’s not the native language of .NET, which means that books, articles, courses, code samples, and so on, are not going to be written in managed C++—they’re going to be written in C#. But this should come as no surprise. C++ has never been the native language of any popular platform. Unix and Win32® have C. The Mac has Pascal. NeXT had Objective C (of all things). COM has Visual Basic. Only the BeOS has C++ as its native language, and when was the last time you wrote any BeOS code? The fact that .NET favors C# merely means that another language will be translated into the C++ equivalent, as has been done since 1983.
斜體是我加的。NeXT “had” Objective C. Now OS X has Objective-C. :)
lukhnos :: Jan.26.2007 :: tekhnologia 技術或者藝術 :: 2 Comments »
《經濟學人》的悼文（obituary）是該雜誌的特色。曾經有一次有朋友問我，英文的悼文怎麼寫。那時我只知道這個英國雜誌有刊登這樣的文字。這個文類已經算英美系大報的體例之一。《經濟學人》則將之發揮，使得obituary不再只是告知性質的訃聞，反而更像蓋棺論定的人物品評。我自朋友問起，才注意到原來該雜誌每期必登一則，而文章通常寫得極為精采。悼文的對象有的惡名昭彰（例如智利的獨裁者皮諾契）、有的平淡中帶有欣賞（例如美國前總統福特）、有的在讚揚中帶點惋惜（例如為美國冷戰的圍堵政策定調的肯楠）。
至於這一期的這一則，怎麼說呢，有一種充滿日式泡麵廣告的誇張喜感，也算是對能改變人類生活的人的一種稱讚吧。以下是節譯：
安藤百福
安藤百福（Momofuku Ando），速食麵發明人，1月5日去世，享年96歲。
幾世紀以來，男男女女紛向東方尋求生活、健康與快樂的奧義。安藤百福卻教導人們，奧義既不需半裸爬高山、不必在座墊上打坐幾小時，更不用把腿纏在脖子上、一邊用上鼻腔發出「嗡嘛尼巴咪吽」的聲響。奧義只需要：
掀開杯蓋
倒入熱水
泡三分鐘
攪拌食用再簡單不過。當然啦，慧根不夠的還是會偶爾碰壁，像是燙到舌頭，或是才靜靜冥想了一分鐘，就把叉子伸進去亂戳，結果弄斷叉子，湯汁還濺到鍵盤上。有耐心的信徒，倒是得以功德圓滿：不管是雞汁口味還是鮮蝦口味，溫暖而形狀歪歪扭扭的麵，就這樣一口接一口。
[......]
速食麵是全球的宗教。全世界在2005年時吃掉了860億包速食麵。而這一切都從一個願景開始；如此規模的事，起初皆如此。安藤先生在1957年一個寒冷的夜裡從他在大阪的製鹽廠走回家，他看到街上冒出白煙，一群人在那邊。他們在等待一鍋鍋的麵在滾水裡燙熟，而且做好等候多時的準備。安藤先生心想，為什麼不把這事弄得簡單些？而且，他自己何不動手試試看？
他的人生至此之前，算是有些糟糕。[. . .] 但從此之後，那「裊裊上升」的白煙（或者也可能如他在大阪速食麵博物館的首頁動畫裡那般，是一朵上面綁了只水壺的白雲）向他啟示了通往奧義的道路。
那是一條漫漫長路。他在自家後院的棚子裡日以繼夜試了一整年。[. . .] 秘密來自他太太炸天婦羅時的訣竅：用棕櫚油酥炸煮過的麵條。這就是速食麵「魔力」的來源。
速食麵於1958年上市，[. . .]。安藤先生再也沒回頭過。1971年時，以隔熱的保麗龍包裝的杯麵上市，至此挨餓的人甚至連去櫥櫃裡拿碗的力氣都省了。日本人票選，速食麵是他們二十世紀最重要的發明，Sony的Walkman隨身聽被比下去。安藤先生的公司也成為了年營業額30億美金的全球事業。
但速食麵絕非一家公司之事，製造速食麵從來也不僅僅是一種產業。安藤先生的三句話成為了一種生活哲學：
有東西吃，就有和平
吃得聰明，能養顏美容，延年益壽
製造食品能服務社會安藤先生力行他的教誨。他幾乎天天吃原味雞汁麵，直到去世。雖然有人質疑速食麵脂肪高又有味精，安藤先生倒是又瘦又元氣。亞洲地區的海床上到處堆滿泡麵杯，那並不是他的錯。
安藤先生的電視廣告呢，倒是展現出速食麵的真意義。世人只要吃泡麵，則人與人的隔閡消失，孩童露出笑顏，人們彼此相愛。所有解放人心的革命，都源自那隨時想吃一碗熱騰騰泡麵的人性渴望。2006年時，發現號太空梭上的一位日本太空人就著真空包吃了碗安藤先生的泡麵。電視廣告上的太空人在無重力下露出微笑，他已然修成正果。
lukhnos :: Jan.21.2007 :: bon vivant 活 :: 3 Comments »
他日路過友人網誌，見巧圖二幅。友素以彩繪技高，吾近來有果則松，邃厚顏索之。
是圖題「不過一介艾克斯寇德黑客爾」。艾克斯寇德者，工具也；林檎開發，面向對象丙語言首善也。黑客者，俠客也；有碼則黑，路見臭蟲拿斧就砍也。或有云黑客者黑，世人不解，輒以斧頭記號如映畫斧頭幫，不可與之親近。實則斧頭者，利器也，自羅馬該薩時代，即團結象徵。則黑客非盡孤癖難搞者流，而除蟲亦須循其道、批大郤、導大窾，躊躕滿志，善刀而藏之；鬼斧神工，德馨造福世人者，乃稱寇德。偈曰：大道不行聖人出，萬碼奔騰黑客鬆。
今日厚顏有成，得貼紙一，洋洋之餘，乃設鏡檯前，著墨鏡，自閃之。
按：閃者，泰西人稱flicker，近世正音脫落，或有少一字母，稱flickr者，則松果屯、疊疊樂、大食團，如恒河沙不可盡數。
lukhnos :: Jan.19.2007 :: bon vivant 活 :: 5 Comments »
配樂和圖表方式非常德國（讓人想到Der Spiegel）。看就是了。Via Presentation Zen.
(No, I won’t embed Youtube Flash in my blog.)
看完心情變得蠻好的。唔，居然看圖表看到心情會好。也許我快變成 PC 了。標題 Le grand content 除了「大內容」外似乎還有弦外之音，無法確定。
lukhnos :: Jan.18.2007 :: tekhnologia 技術或者藝術 :: 1 Comment »
TextMate 和 Delicious Library 兩套知名的 Mac 軟體已經宣佈它們的 2.0 版將只支援 OS X 10.5 ，暱稱為 “Leopard” 的作業系統。
至於當初被請上台去為 Objective-C 2.0 背書的 OmniGroup，看來還沒決定是否要這麼做。但是 OmniFocus 的延宕似乎透露了點什麼，um-hum。
OS X 10.5 到底對開發者來說有什麼好處？至少對我來說，有三件大事：Objective-C 2.0、CoreText、新的輸入法架構。其中又以 Objective-C 2.0 最令人期待。畢竟，如果有 gc 支援，那麼 Objective-C 總算可以走進「現代」語言的行列──而且它仍然是個compiled language!
比起從Panther到Tiger，似乎有更多人願意為Leopard割捨舊版的支援。
這陣子以來我寫的 blog 都和技術有關。有在考慮是否分割成兩個 blog，一個寫技術性的東西，另一個寫所有跟技術無關的事情呢……
lukhnos :: Jan.17.2007 :: tekhnologia 技術或者藝術 :: 6 Comments »
（2007-01-13 16:51 GMT+8: OpenFoundry回神，原始碼已更新。）
相信對許多Mac使用者來說，OpenVanilla所提供的酷音輸入法模組，是輸入中文絕不可少的工具。我們終於要發佈「OV酷音」的新版本了！
本次發佈的測試模組，是酷音輸入法最新版本。在此徵求beta用戶。
不過請注意！目前的版本真的是「測試版」，可能並不適合需要大量文字輸入的場合使用（有截稿壓力的朋友請不要雞蛋放在這個籃子裡）。
安裝新版「酷音輸入法」模組的步驟如下：
這個版本在詞庫正確性上相信較舊版來得高。但可能有一些原本 SpaceChewing 的功能在這版有不太一樣的地方。因為我本身不是酷音的使用者，可能會有疏忽。如果有這樣的問題，請直接在本則 blog 上留言告知。留言時請您告知您使用的機型（請務必標明Intel或PowerPC）、作業系統版本、在使用哪個應用程式時出問題，以及測試版的版號（例如酷音 0.3.091）。
新版本的酷音詞庫檔改名為 uhash.dat ，因此不會與舊有的 hash.dat 衝突到。不過我自己試用到目前，加詞的功能似乎還是不太靈光。這一點可能要請各位酷音的使用者再確認這樣是否正常了。另外先前SpaceChewing的「漢音符號表」功能（CTRL-OPT-[英數字鍵]）這個版本是不提供的。
Beta發佈順利的話，就會包裝發佈正式版本。謝謝大家！
以下是這一次beta測試版本的技術說明，供輸入法開發者以及關心技術內容的朋友參考。
lukhnos :: Jan.13.2007 :: tekhnologia 技術或者藝術 :: 12 Comments »
Update: llwang也包裝過FreeBSD port，原文被我誤植的HTML code遮住了，特此更正。
OpenVanilla 在 2005 年春天時曾經發布過一個透過 SCIM 能夠在 Linux/FreeBSD 的 X11 環境下使用的輸入法套件。這個部份是由 vgod 完成並準備出第一份 Debian 套件，後來有 llwang 的 FreeBSD port 跟 marr 的 RPM 包裝等套件。在此之後這支被稱為 OV-SCIM 的 loader 便進入開發停滯，然而在最近一個版本 (0.7.2) 中，OV-SCIM 仍然是可以順利編譯使用的。
在測試過 OV-SCIM 仍然可用，並且可在例如 Ubuntu 6.10 Installer CD 這樣的環境下使用後，我想該是時候來做一點修改的動作。
於是，OV-SCIM 在沉睡了一年半後，又開始動了起來。其中長久以來一直缺乏的設定管理（config management）和游標支援已經完成。
我們在這邊準備了一個可以 untar 到 Ubuntu 環境的套件，可以從這裡下載。下載完只要 sudo untar 到 Ubuntu 環境（或 Ubuntu Live CD 下），就可以使用了（可能需要重新啟動 X11、scim 或者調整 XMODIFIERS 等設定，在此不詳述）。
包裝內容包括 OV-SCIM Loader、幾套常用的 OV 輸入法模組（泛用模組 [包括倉頡、簡易、大易等]、傳統注音、台灣閩南語白話字 [Holo POJ]、行列、藏文），以及 OV 需要的 ltdl 程式庫。
以下是最近一次更動的說明：
技術說明和目前的問題如下：
測試套件可從 openvanillla.org 的 beta 測試區取得。以下是 screenshot：
lukhnos :: Jan.09.2007 :: tekhnologia 技術或者藝術 :: Comments Off
前陣子FlickrBooth（TUAW有提過）作者Tristan O’Tierney寄信來和我討論在ObjectiveFlickr中加入Zooomr（註1）與23HQ API支援的可能性，於是研究了一下。
這兩家照片網站都號稱建立了一套和Flickr一模一樣的API layer，在去年春天時還頗引起一陣轟動，特別是Zooomr因為還去跟Flickr申請commercial API key來搬資料，弄得很是熱鬧（以商業觀點，這是很成功的PR戰術）。兩位朋友的試用報告可以看這裡和這裡。
我對照片網站的興趣缺缺，又是Flickr滿意的付費用戶，因此並沒有很想去深入瞭解Zooomr和23HQ有什麼特別的地方（註2）。但是兩家不約而同地跟進使用Flickr API layer是挺有趣的發展。那麼，API developer的眼中看到的Zooomr和23HQ會是怎樣呢？
雖然說Zooomr號稱照著Flickr API做了一套，事實上還沒有完整移植。目前能用的只有upload和簡單的照片查找而已。這個技術選擇，目的不證自明：要讓原本Flickr的上傳工具能無痛移植到Zooomr上。但是簡單兩件事就讓我對目前狀況抱持保留態度：首先，Zooomr必須要使用e-mail來申請API key，而Flickr的non-commercial API key是可以線上申請的。光是這一點就讓想要提供Zooomr支援的人卻步了。雖然ObjectiveFlickr大可不管這事（反正要申請API key的人是那些要寫uploader的），但我也想要有API key來做unit testing或測試我的demo app。如此一來我就只好寫信和等待（他們blog留言上有人說寫信去了很久還沒回音，也不見該公司的人出來澄清）。而在此之前我只好不release Zooomr support了。
除此之外呢，Zooomr的static photo URL規則竟然也和Flickr不同，而Zooomr在blog上竟完全不提這件事，彷彿他們最希望convert的對象，就只有uploader的作者們。而Zooomr在張貼完該篇blog之後，就再也有後續消息啦。Google “Zooomr API” 竟然什麼都沒有，還是找 “Zooomr blog api” 才在第三名找著。光是這樣一陣折騰，我就想轉台了……
至於23HQ呢？其實是因為意外讀到有人藉更換FlickrBooth裡的ObjectiveFlickr來使用23HQ上傳，才知道23HQ原來也照Flickr API複製了一整份。比較起來23HQ就兇狠多啦，不但Flickr API已經移植得差不多了，連手冊也都大方地連到Flickr那邊，不用再多寫什麼。URL endpoint完全無痛轉換，包括static photo URL也都照Flickr格式（23HQ甚至還寫了這個網頁教你怎麼”switch”）。但是比較奇怪的是23HQ竟然提供了Flickr早就不用的舊式authentication（讓使用者把帳號和密碼放在HTTP GET參數裡！）。還有一個不知算是優點還是缺點的東西：23HQ不需要申請API key。照他們的說法，你要不就是自己隨便選一個名字，要不然直接用你在Flickr拿到的API key也是可以的啦…… 這點就讓我不太放心了，總覺得這像是某種收集API key的陰謀（雖然shared secret是收集不到的），除此之外我也在想：不用API key，是否代表API usage monitoring也就隨便做了，難道23 HQ不怕有人寫惡意程式搞死他們的API server嗎……？
23HQ倒是有API forum，這點就比Zooomr強太多了。顯然要在API war中佔塊地，恐怕還是得像Joel曾說的，developers, developers, developers! 但是23HQ只支援REST似乎是致命傷，因為有太多XMLRPC和SOAP的程式庫，這對「傳統」一點的desktop app發展者來說仍然挺重要的。
結論是什麼呢？我想 23HQ 在「照著 Flickr 刻一套」這個criteria上，顯然比 Zooomr 要高明多了。不過 Flickr 的 API 也日新月益，仍然每幾個月又多吐幾條新的 API method 出來，讓大家很是目不暇給（就這點上，Flickr 顯然學到了微軟的招式）。而 Flickr 前陣子也更新了自家 static photo URL 的格式，對上傳和其他工具的開發者來說，大概又有得忙了，如此一來，對23HQ、Zooomr或其他家網站的支援，是否就因此會被擱到較後頭呢……
雖然鄉民們一定會說lock-in是壞事，但Flickr的API已經完整到寫個「把自己所有照片通通搬回來」不是問題的程度，所以「Flickr只進不出」的說法，恐怕是FUD。至於技術上呢，Flickr自己就是自家API的最大消費者（但是要用他們家API做一套跟Flickr一樣的網站則是被禁止的），而Zooomr看來是先有了照片網站，才開始做相容性layer。
ObjectiveFlickr針對23HQ做了一些測試，發現傳回來的response block有一些問題，上傳等候回應的速度也和Flickr完全不能比（不是連線速度，而是傳完照片之後，等待XML response block的時間）。
如是觀之，後發者要靠 API 與大玩家搏一局，或者要爭取 developers 跳船換旗，看來還有很多關鍵細節得照顧。
（ObjectiveFlickr最新的原始碼已加入23HQ支援，近期內發佈新版。）
lukhnos :: Jan.09.2007 :: tekhnologia 技術或者藝術 :: Comments Off