http://lukhnos.org/blog/zh "Entia non sunt multiplicanda praeter necessitatem" Thu, 01 Jan 2009 19:25:32 +0000 http://backend.userland.com/rss092 en 註：本文為虛構 (MP3 file) '"Yoibito Kurushii was a hard-working programmer who loved his job and his girlfriend. One day when he came home, his jaw dropped. Every piece of furniture, every book from the shelf, everything that could be said of their shared life for the past few years, was removed. The ... http://lukhnos.org/blog/zh/archives/785 我任職的公司 2009 年第一季要招募一位實習生 (trainee/intern)。 工作內容主要是協助我們建立公司內部的 build system 跟開發 in-house 工具。公司目前業務以代客開發軟體為主，也有自己的產品。我們的開發平台主要在 Mac 上，也有 iPhone 跟 Windows 的開發工作。 應徵者應該要能流利使用 C 語言，並且熟悉至少一種以上的 C 衍生語言（例如 C++, Objective-C 或者是 C#）。如果有 script language / web app / 視覺設計相關工作經驗也不錯，但不是必要。 公司很小，跟我們一起工作要分擔研讀資料以及雜務。另外我們也預期應徵者能閱讀英文資料。基本的英文寫作能力會很有用，因為我們內部的記錄多半用英文撰寫。 辦公室位於台北市大安區，師大附近。 請準備一份英文簡歷或者作品集，寄到 jobs {at} lithoglyph {dot} com http://lukhnos.org/blog/zh/archives/782 我一直以為有一段旋律是 Aaron Copland 的作品，因為常常在聽到 Fanfare for the Common Man 時伴隨著聽到，或者是軍樂隊演奏之類的。總之困擾了我很久（因為聽了很多 30 秒試聽 clip 顯然不是 Copland 的作品）。 結果有一次坐車時台北愛樂電台正好在放，探詢之下才知道原來是 Vaughan Williams 的《英國民謠組曲》 (English Folk Song Suite) 中的第一部 "March: Seventeen Come Sunday" （星期天就要十七歲）。這是一首結構上由 A-B-C-B-A 組成的作品，由三個部分民謠 "Seventeen Come Sunday", "Pretty Caroline" 以及 "Dives and Lazarus" 組成。除了是英格蘭傳統民謠外，也有宗教的主題在裡面。其中 "Pretty Caroline" 由木管演奏的旋律就是那困擾我的部份，久久不能忘懷。 因為顯然是某些儀式慶典上聽到的演出，才突然在想：不太知道這種國高中要開升旗朝會（還要像軍隊一樣行進看齊整隊立定稍息？要有主席司儀？到「司令台」上領獎？），朝會要有樂儀隊，還要演奏軍樂/進行曲的奇怪組合，到底是哪裡來的文化呢？我從來沒有在乎跟注意這些事，結果還是沒想到還是留下了一個困擾的線索；另一個學生時期早上常聽到的曲目竟然是史特拉汶斯基的《火鳥》組曲，不過這個很早就知道。 總之，果然不是 Copland 啊。不管是 Fanfare 或是好比像 Rodeo: Hoe-Down ... http://lukhnos.org/blog/zh/archives/777 有朋友讀到我之前寫的這篇 blog，來信問了幾個問題。問題來自這幾個漢語拼音的例外規則： （ㄐㄑㄒ）j→ji、q→qi、x→xi、 （ㄓㄔㄕㄖ）zh→zhi、ch→chi、sh→shi、r→ri、 （ㄗㄘㄙ）z→zi、c→ci、s→si、 轉錄如下： ｑ1；我不曉得說何時才會要多加ｉ ｑ2；還有像是“去“這個拼音 如果打ｑｙｕ就沒有 （其實智慧型你打ｑ他就會寫出“去“這個字拉）但是我還是想問說正確的拼音要怎們打 ｑ3；ㄩ→ü他正確是要打拿個字去拼阿 是ｙｕ嗎 因為我看你說ｍａｃ系統會用ｖ可視我打ｖ沒有反應 然後我看你下面的特例 “雨“字打yu 然後我打“約“字是打yue是可以找到拉只是不知道對不對 不知道正確的要打啥才會找到可以舉例一下嗎 簡單回答如下， 第一個問題，關於有那些組合要補 "i"：嚴格說來只有「ㄓㄔㄕㄖㄗㄘㄙ」這七個。原因是他們其實本來照原理是應該要補上母音的，只是注音符號的規則讓他們可以獨立（一方面也是避免跟ㄐㄑㄒ + ㄧ撞到，但這就是麻煩的地方......） 第二個問題：「去」的漢語拼音是 "qu"。請注意 w 跟 y 不會在有其他聲母的時候出現，所以 qyu 是不正確的組合。至於打 q 直接出「去」是很多漢語拼音輸入法的 shortcut，但那並不是規則。 第三個問題：先談「ㄩ」獨立成音的時候，因為 y 規則，要變成 "yu"。至於拿 v 代替 ü 那是僅限於輸入法的替代方案。實際上唯一需要區分 u/ü 的只有 nu-/nü- 跟 lu-/lü- 這兩對而已。之所以 yu/yue 直接會對應到注音的「ㄩ」而不會跟「ㄨ」搞混，是因為「ㄩ」跟「ㄨ」的組合除了上述兩對外，其餘都是互斥的，所以不會混淆在一起。 http://lukhnos.org/blog/zh/archives/775 在南部當兵期間可能是從學生時代結束到現在之間（被迫）做體能鍛鍊得比較勤快的一段時期。那時候聽到的說法是 3000 公尺是跑步運動中最令人不舒服的距離：沒有短到可以用爆發力撐完，卻沒有長到可以用穩定的速度跑完（同時時間的要求也高）。我從來沒有對跑步這項體育活動有超過耳聞以上的了解，所以不知道這說法有沒有運動學理上的根據就是了。 最近也在思考寫程式這件事情與兩種體能運用方式之間的關係：爆發力跟耐力。我們其實對爆發力應該都很熟悉：為了很快地解決問題，把身體跟精神的力量在短時間之內集中輸出。例如為了解決教科書上的一題大數運算，或者在概念已知的範圍內集中火力debug。心智的爆發力表現在於周邊世界的地平面能夠在短時間內消失，而思考很快地沉入一個越來越深的狀態。這種模式的缺點是，不是經常能夠出現、非常怕受到中斷（很諷刺的這種深度模式是單工的），從沉入到浮出的過程可能不會很好控制或甚至不會愉快，而且，隨著教養的不同，很可能週邊環境會付出一些代價，例如，不顧長期後果，或是把週邊弄髒（註 1）。 然而寫程式常常不是一個單點集中火力就可以完成的工作。只要我們開始想要處理的不再只是單一的問題，而是涉及了一個以上的元件，我們就開始要與「系統」相處。幸運的人有機會從頭建立系統，比較沒那麼幸運的人則必須跟既有的系統共存，並且在系統的夾縫之間尋找突破或救火的空間。不管是哪一種都是一種考驗。從頭建立系統的人受到到考驗是「布局」，在不同的地方設下了初始條件後，系統很可能產生出當初未曾預料的組合變化（unintended consequences）。接手的人則往往沒有砍掉重練的空間（註 2），必須背負著前人的包袱（legacy），擺爛的人可能開始在上面蓋違章建築或偷牽第四台纜線；細心的人模仿歐洲古蹟保存者，慢慢敲掉建築內部的腐朽結構，四處尋找失傳的工法或罕見的材料加以修補，或者有才華地在外頭蓋上一頂玻璃帷幕；謀略者則可能要像智巧的律師，在法典（code）跟前例（precedent）中尋找並採取對於手上工作最合理有利的路徑，然後把問題擊潰。 但是，除非擺爛，否則細心的人或謀略的人都需要有極大的耐心和耐力。尤其如果每天要跟一個比自己還龐大、（集體的）歷史比自己還長久的系統共存。事實上即使有幸布局的人，也可能突然有一天發現被自己設下的局所困了：當初沒有想到的需求，或是因為環境的突然變化，讓系統掉入了瀕臨崩解或亟需救火的危機。 結果是這兩種不同的體能模式，很可能會演變出不同的撰寫程式的態度。爆發力模式容易得到短小但多量的產出。但是耐力模式卻可能演變成「不要常常寫太多程式」的保守（負面意義上的）態度。我最近倒是覺得或許可以用正面的方式來詮釋保守的態度，只是內容的層次要提高，變成：「不要隨便布局」。用英文來歸結也許會是 "Design thriftily and design well"，中文講「少少的設計，好好的設計」。這是某種信仰精簡主義者、從事系統設計的人的夢想吧。 但是並不是說從事比解決單一短期問題的工作大一點規模的，只要靠耐力就好了。我剛剛說過了，那是一種保守的態度。這個詞有正面的有負面的意義（雖然我相信在台灣受教育的人跟我一樣對這個詞很難有正面的連結），但終究沒有「開創」或「冒險」的意義在裡面（智巧者會有突破，但那多半是靠著鑿穿系統漏洞而來的）。 另一方面光靠熱情或者爆發力並不足以成事。畢竟一個系統本身就有如一個戰場（theater），只倚靠單純的砲火猛烈不見得能夠贏得勝利。就因為深度模式有很多的缺點，或者說，有這種模式必須付出的成本/代價，因此我們的工作上需要其他模式來補其不足。「即使是熱情也需要不停添加柴火的」，我們或許可以這麼俗爛（cliché）地說。   註 1：極端的例子，會像日本小說家村上春樹（Haruki Murakami）作品《海邊的卡夫卡》（海辺のカフカ，2002）中的主角那樣形容他的藝術家父親：高度才華地完成作品，卻將刨下的惡的部份丟棄傳染給所有周遭的人。高度沉入的心靈狀態/意志力及其後遺症（或與之鬥爭）是貫穿村上各時期作品的主題之一。 註 2：即使有，也常常落入這個囧境 [sic] 之中：人從歷史中唯一能學到的教訓就是，人不能從歷史中學到任何教訓。 http://lukhnos.org/blog/zh/archives/766 雖然說 VM 是真的很方便啦...... 但是這樣也太誇張了： macbook:Shared $ du -h -d 1 738M ./Applications 183M ./ExternalLibraries 22G ./VMImageMasters 102G ./VMImages 然後上週末錄了第二集的台語Mac podcast，MP3檔案在這裡。以下是 transcript： 大家好，我是lukhnos，歡迎收聽今ah日ê Mac軟體podcast 今ah日要來跟大家介紹 ti Mac 頂kuân ê 軟體開發。軟體開發也就係人講 ê 「寫程式 (ting-sik)」，也就是英語講 ê programming 囉。有真多人頭一次用 Mac ，看到真多好用又好看 ê 軟體，可能會問：這款 ê 軟體是按怎樣開發出來 ê ？也可能有會問：阮如果也想在 Mac 頂kûan 開發一款好用又好看 ... http://lukhnos.org/blog/zh/archives/763 我在之前的blog中提到寫程式與做軟體的不同。寫程式是一種需要深度的心智活動，面對一個問題不停地往下打洞，直到鑿穿（或是跟從另一邊鑿過來的通道連接在一起）為止。而做軟體一大部分已經屬於「產業活動」了。如果我們仍然以寫程式作為軟體意義的中心的話，做軟體則涵蓋了一大堆圍繞在寫程式旁邊的活動，例如：設計icon、做網站、寫change log、做nightly/weekly build、發布內部測試、徵求beta tester、與客戶／顧客溝通、從事銷售行為、做售後服務、收集bug report、彙整bug report、回應和追蹤bug report、控制預算、充電和度假等等（好吧，度假並不算）。 微觀來看寫程式有點像讓自己的心智變成一個 debugger，你基本上是跟著程式執行的時間線一起跑著。做軟體比較像是把自己變成一個 Make/scheduler （事實上這樣的比喻還蠻精準的）：你得在諸多彼此相依的事件之間打轉，不停地 spawn off 新的工作並且在各種可能本質或情境 (context) 很不相同的事情上面切換。有時候還得把例如跟家人相處的時間暫時置換 (swap) 到你口頭承諾但其實是空頭支票的虛擬日程表上。 ● 有一次在 TV5 上面看到一則關於阿瓦里德王子的報導及專訪。電視台一行人跟著王子上到他的私人遊艇訪問，結果巧遇美國前國務卿歐布萊特（時為 2005 年，當時應為紐約證交所董事）。訪問是用法文進行的。電視台的人遇到歐布萊特打了招呼，歐布萊特問：「你們要我講英文還是法文？」電視台的人問：「講法文可以通嗎？」結果阿瓦里德王子說了：「那當然，人家可是歐布萊特女士耶！」 根據 Wikipedia 上的說法，歐布萊特「精通英語、法語、捷克文〔歐布萊特是捷克裔〕跟俄文，對於波蘭文以及塞爾維亞-克羅埃西亞語也有不錯的口語及閱讀能力」。同一篇文章也說歐布萊特是在生產完、在醫院待了六週的期間，把俄語學起來而且精通的。真是厲害。 因為讀到這篇文章我跑去問一位學過俄文的朋友。他的說法是：盡管捷克文跟俄文有語系的關係，文法也非常類似，但是關係也就到此為止。 所以人家能夠「露語六週間」（露語是日文以前講俄語的寫法）是有人家的條件的。 ● 隨便找一個語言，然後生吞活剝把該語言的書寫系統死背下來，然後學習文法，然後照著常用句型本硬湊一些句子，或是在看到別人來一個句子時，靠翻查字典的方式，把句子的意思給解出來，這些都是可能的。君不見拇指書（就是那種書上印了各種旅行用的外語詞彙）的書在書市一直有個份量。 但是「具有一個語言的知識」（例如「知道了英文的時態變化」）跟「可以不費力就脫口而出『如果昨天沒有下雨，那麼我早就出門把電影看完』」之間還是很一大段距離。 其實程式語言也是這樣的。好比說會了 C++ 雖然可以說是具有了看懂 Objective-C 的良好基礎。但是要正確寫出「可以讓版本不同的 plug-in 載入後繼承來用也不會出問題的 base class」也還是有一段距離（拿相反例子來說，在 C++ 上同樣是困難的）。 ● 好了，今天講了這麼多跟寫程式跟語言有關的事。接下來要給各位看笑話了。 上週四晚上下班後，心血來潮錄了這個podcast。原本是錄來自娛的。結果半夜放給別人聽，沒有把對方半夜醒來的小朋友嚇哭。那我想這樣應該可以貼出來娛人了。 有網友說：「如果不知作者，我會以為『這位日本朋友台語講得不錯啊』」。 我只能說，我看來是真的沒有講台語 (Hok-lo; 我的第二母語) 的天份啊（泣）。 Podcast可從這裡下載，以下是 transcript： 今日的 Mac 軟體時間，要來跟大家介紹一個好用ê軟體，叫做VMware Fusion。啥麼是VMware Fusion咧？伊就是所謂的virtual machine，虛(hi) ê機ah。不是身驅很虛ê虛啦，是人講ê虛擬 (hi-gi)，英語講ê virtual囉。譬如說你只有 (tsi-u) Mac，沒有 PC ，但是裝了虛ê機仔之後，就親像有了真正ê PC ... http://lukhnos.org/blog/zh/archives/755 Alan Fetcher, Colin Forbes, Bob Gill是三位重要的英國設計師。他們組成的F/F/G工作室後來成為Pentagram。 他們三人寫過這一本原文已經絕版的Graphic Design: Visual Comparisons。中文版由吳成桓翻譯，左耳出版（2008）。一定要提的地方是：這本翻譯書幾乎忠實地復刻了原書的設計，而中文字體的選用，也讓書有一種從 70 年代跑出來的感覺。 摘錄兩個地方。一個是關於F/F/G (p. 102): 值得一提的是，F/F/G應該算是第一個擁有員工餐廳的設計公司。當我們在貝克街 (Baker Street) 正式成立工作室時，附近很難找到好的餐廳以解決每天用餐問題，所以我們決定請一位煮飯媽媽。[...] 因為這位媽媽手藝實在太好，後來連客戶也都慕名特別前來我們工作室用餐。[...] 還有就是我們明定的「夥伴關係遊戲規則」。當一起成立F/F/G工作室時，即使沒有什麼確定的原因，但我們知道這一定會成功。所以我們決定，必須要讓日後想結束夥伴關係的人很難離開。所以我們的規則是：要離開F/F/G的人不能拿到錢與公司股份，[...]。 [...] 另一項遊戲規則就是，即使其中一個夥伴沒有直接參與這個設計案，他的名字還是永遠會出現在F/F/G所有的作品集下。例如，即使我 [Bob Gill] 和Forbes幾乎沒有參與Fletcher所設計的倫敦公車海報 [...]，但那還是合法屬於我的作品之一。 另外是關於譯本的製作 (p. 111): 在字體設定上，英文部分整體使用原書版權頁所標示的11/13 pt （11級字大小與13級字行距）Garamond字體，中文部分則使用具有飾線 (serif)、字體曲線與轉折風格相似於Garamond的明體。中文字級大小（8.75級）略小於英文，以求得兩種文字在視覺質量上的近似。[...] 另外，值得細數的是本書使用的中文走文方式：我們選擇這種「靠左對齊，並保持文字右側參差不齊 (flush left, ragged right)」的設定，而非一般中文常見的「左右齊行 (justified)」。[...] 因此，我們認為西方字體學理根據視覺 (optical) 原則去微調文字的觀念，可以應用到中文上；1946 年 Max Bill 在他撰寫的 "On Typography" 一文中，確認並使用的左右不齊行之走文方式（同時也成為瑞士國際風格的中心德目之一），對中文也有應用價值。所以，在本書的走文設定上，我們對空格過大的全型標點或筆劃少的中文字，以 kerning 去做字距調整，並對長篇文字以 ragging 方法針對文意作斷行。 書的正文（或「正圖」？no pun intended, heh）當然要看。上述屬於附錄的部分（不僅止於摘錄所及），算是書中藏寶。 http://lukhnos.org/blog/zh/archives/750 寫程式 (write a program) 跟做軟體 (develop software) 是兩個交疊但不同的概念，就好像寫作 (writing) 跟出版 (publishing) 的關係一樣。 如果我們願意承認，作者雖然是寫作的源頭（註1），但其實只是出版的一個環節，我們就能看出兩者的不同。書稿的完成只是出版的開始而已（註2），書稿要編輯、校對、排版，而這離最終產品「書」還很遙遠呢。隨便一想就有封面設計、介紹文字、印刷裝訂包裝發行，還有後面各種銷售的必要工作，例如被大書店或大通路婊。 而且，另一個常常被人忽略的面向是：這些事情不是只有商業書籍如此，主要目的不在營利的學術書籍仍然是如此。事實上，不管作者有名無名、不管主題冷門熱門，不管出版社是大還是小，甚至助印結緣書也免不了這個過程（結緣書也不是說要放哪裡就能放哪裡的）。 作者跟編輯常常不是同一群人。但是很多時候寫程式的人也得擔負類同於「編輯」的工作，這可能是很多人痛苦的來源：很多人不喜歡，或者不見得適合當自己的編輯。反之亦然。 不過，不管哪一個角色的人，都應該去認識到這兩者的不同，進而減少不必要的期望跟落差（這一點對於軟體使用者或許也是適用的：我們很少因為書皮長得醜而怪作者爛，但是同樣的事情會發生在軟體上）。但也許這就是程式寫作者們的盲點：以為高科技可以幫我們解決問題。好比說，Google Code Hosting好像解決了程式寫完後如何妥善公開一事（對一些人來說，也許「做軟體」就到這邊為止）。事實上Google Code Hosting一類的高科技正是因為減少了尋找擺放位置跟擺放方式的摩擦 (friction)，反而使得「做軟體」的本質更加急迫地顯明了：那個放上去之後的「怎麼辦」才是更麻煩的事情（註 3）。 從這點來說 programmer 跟 software developer 有著工作內容的不同，但後者涵蓋了前者。   註 1：事實上即使是這個說法還是過度簡化的，但暫且讓我們忘了「文本有兩種，一種有可讀性 (lisible)，一種有可寫性 (scriptible)」這類的說法吧，巴董事長的理念並不包括「寫作要先不傷身體，再講求效果」。但是軟體必須 do no harm 啊。 註 2：這也是過度簡化的。如果我的學生時代有哪一句話有留下深刻的銘印，應該會是：「寫作的美德只有一種，就是重寫」。 註 3：高科技（例如 CMS, VCS, BBS, DOS 等）往往只是更突顯問題的本質，而不是解決本質...... http://lukhnos.org/blog/zh/archives/728 我亂造的無意義詞。冒出這個想法的原因是 review 去年的 blog entry ： 我在想，如果台灣至今仍實施戒嚴，所有那些對媒體與思想的管制，會不會也延伸到Internet上。固然對歷史提出假設性的問題意義不大，但台灣的過去應該說明了不少事情。那些對思想的管制，以及，為了管制所加諸的對人的身體的傷害、制度與結構上的暴力，以及對那種制度性暴力的恐懼、擁有管制權力的人的腐敗等等──再加上，或許最令人不能忍受的，是那種為那管制和暴力所做的辯解。那些東西是確確實實會留下痕跡的。 新聞台播出了許多當時的新聞片段或運動人士自己留下影像記錄。今昔相較，有許多的不可思議，也有，我相信，許多當時就已被提出、而今日尚未能真的說已經克服的挑戰。或許那又得再用另一個二十年了。 http://lukhnos.org/blog/zh/archives/726