葉難

Raspberry Pi的FAQs

2012-01-16T23:22:00.001+08:00

Raspberry Pi官方網站的常見問答集，我把它翻譯成中文。

對Raspberry Pi有興趣的話，請到官方網站晃晃，裡頭有部落格、論壇、維基、商店、常見問題集、聯絡資訊。也可到Twitter追蹤最新消息。IRC頻道在freenode的#raspberrypi。

目前Raspberry Pi尚未正式問世，底下的問答也都具有時效性。

問：Raspberry Pi是啥東東？
答：Raspberry Pi是個只有信用卡大小的電腦，連接顯示器或電視、鍵盤後即可使用，就像一台小型個人電腦，任何桌機可做的事情，譬如試算表、文字編輯、遊戲，它都有能力可以處理，還能播放高畫質的視訊影片。我們希望看到，全世界的孩童都能用它來學習程式設計。

問：何時可購買？
答：之前，我們希望能在2011年底開放訂購，我們仍然希望可以在2011年結束前上網拍賣幾塊beta板（耶誕節後，請密切注意）；我們將在2012年1月開始量產。
（譯註：在ebay拍賣十塊板子，已經結束。）

問：多少錢？
答：Model A要25美金，Model B要35美金。
（譯註：兩個model的差異，可看這篇。）

問：我可以加入mailing list嗎？
答：當然可以，請到官方網站的首頁，右上角可填入email與姓名進行註冊，註冊後，一旦我們確定了產品問世日期，就會馬上以email通知。

問：Raspberry Pi的尺寸大小是？
答：長寬高為85.60mm x 53.98mm x 17mm，在邊邊有個搭接的地方，用來插SD記憶卡，重量是45g。

問：為什麼Raspberry Pi沒有xxx硬體，沒有yyy連接埠？
答：我們主要以非營利的慈善組織進行運作，我們試著打造最便宜的電腦，提供一定程度的基本功能與水準，也就是說，必須痛苦地決定，在該包含哪些硬體與軟體間做出取捨。

問：如何連接滑鼠與鍵盤？
答：滑鼠、架盤、網路卡、外部儲存設備，通通透過USB集線器連接。

問：我可以使用什麼種類的顯示器？
答：板子上有Composite RCA（AV端子、又稱複合端子，通常是黃色的RCA端子）與HDMI連接埠，所以你可以接上類比電視或數位電視，或是DVI螢幕；不支援VGA，不過有轉接頭可用。

問：聲音呢？
答：有個標準的3.5 mm TRS端子（就是一般常見的耳機插頭），或是，你可以使用HDMI（HDMI可輸出影像與聲音），透過USB集線器，你可以插入USB麥克風。

問：板子支援網路連線嗎？有Wi-Fi嗎？
答：Model B支援10/100 Ethernet，Model A沒有Ethernet（我們認為教育市場大都會採用這個版本），但你可以插上USB網路卡，加入Wi-Fi功能。

問：電源需求？
答：透過micro USB供給5V電源，詳情見此。

問：將來會有買一送一的方案嗎？
答：是的，我們將會有類似的計畫。但，若你想要的話，可以只買一塊啊。

問：全世界都可以買嗎？還是只有英國？
答：我們打算從一開始就出貨到全球，或許會建立適當的散佈網路。

問：訂貨最少數量是多少？
答：最少要買1塊。

問：接受預訂嗎？
答：不。我們資金充足，也不想要先收錢，我們想把東西準備好才開始賣。

問：我想代理Raspberry Pi成為經銷商，該怎麼做？
答：因為我們非營利事業，利潤很低，當我們的轉賣商，模式跟一般狀況不同，就算一次大量購買，我們也不能提供任何折扣，雖然大量購買你可以省下一些貨運費，我們也不會跟任何地區、任何轉賣商建立獨家專賣授權，如果你想轉賣Raspberry Pi，你只能跟一般顧客一樣，上我們的網站下訂單，轉賣商並沒有特殊的購買流程。

問：是否有GPU二進位執行映像檔？
答：是的，映像檔裡還含有第一階段的bootloader。

問：你使用哪一顆SoC（系統單晶片）？
答：SoC是Broadcom公司的BCM2835，含有ARM1176JZFS、浮點運算、700Mhz，含有Videocore 4 GPU，這個GPU能夠播放藍光品質的視訊，以40MBits/s解碼H.264，裡頭有個快速的3D繪圖核心，透過OpenGL ES2.0與OpenVG存取。

問：除了插上電源插頭，可以用電池啟動Raspberry Pi嗎？
答：是的，可以用4顆AA電池。

問：它可以跑xxx程式軟體嗎？
答：一般來說，你需要看看該軟體是否編譯成ARMv6架構，大部分的情況，答案是YES。特定軟體會在我們的論壇裡討論，你可以去哪找找看。

問：可以跑WINE（或Windows、或其他x86軟體）嗎？
答：NO。

問：正式問世時，會支援哪套Linux發行套件？
答：一開始就會支援Debian、Fedora、ArchLinu，我們希望將來別的發行套件也會開始支援。我們將會販售SD記憶卡，事先裝好Linux作業系統發行套件。（2011年9月4日，這份常見問答集原先說Ubuntu也會支援，但新版本的Ubuntu跟我們使用的ARM處理器之間有點問題，所以，目前Ubuntu不能承諾支援Raspberry Pi。）

問：有外殼嗎？
答：一開始沒有，將來會有（可拿掉，假設你想要做些焊接功夫的話）。

問：PoE（power over ethernet、透過以太網路線供給電源）？
答：現在沒有，但很多人詢問這個功能，所以，我們會考慮要不要在新版本裡加入。

問：搞壞了怎麼辦？
答：重新寫入SD記憶卡，即可還原。

問：一次可以買幾塊板子？
答：一開始，我們限制一個人只能買一塊板子，當產線全力運作後，就會鬆綁這個限制，我們保證會讓所有想買的人都買得到，避免有人在Ebay漫天喊價（或多或少），而且，確保盡量讓每個獨立個體都能取得Raspberry Pi！

問：可以執行Android嗎？
答：受限於只有256 MB的記憶體，所以，新版Android（ICS）跑起來應該很不順，不過，舊板應該沒問題，話雖如此，本基金會並不打算將Android移植到Raspberry Pi上，由社群自主進行。

問：可以執行新的ARM版的Windows 8嗎？
答：跟Android ICS的情況一樣，記憶體不夠跑Windows 8 for ARM，同樣地，本基金會不進行移植工作。

簡介Raspberry Pi，ARM CPU加上Linux只要25美金的電腦

2012-01-05T21:32:00.024+08:00

之前翻譯了一本嵌入式系統的書，發現很多好玩的東西，有BeagleBoard、PandaBoard、Arduino、各種Plug Computer、琳琅滿目，但也沒有下手買來玩，哈哈。不過，最近發現一台超便宜、跟信用卡差不多大的電腦，只要美金25元喔。

Raspberry Pi基金會成立於2009年5月，位於英國南劍橋郡，創辦人們看到學校竟然在教Word、Excel，有感於現代孩童不再親手「做」東西，接觸的都是圖形化介面、遊戲機，發現現在年輕人越來越不懂得怎麼寫程式，於是，想找回學習電腦運算與程式設計的樂趣，特別是帶回校園中，致力推廣資訊科學與相關知識，所以打造出這台超便宜、性能卻不差的電腦。

（在1980年代，英國BBC也有幫助孩童學習電腦的推廣計畫，著名產品是Acorn Computers公司的BBC Micro）

Raspberry Pi的logo。

官方網站上頭的標語寫著：
「An ARM GNU/Linux box for $25. Take a byte!」
以ARM微處理器加上Linux作業系統打造出來的電腦系統，價格迷人。

底下稍微介紹一下歷史。

2006年，概念板，那時使用的是Atmel的ATmega微控制器。

2011年5越，雛形板，跟USB隨身碟差不多大，一頭是USB連接埠，另一頭是HDMI。上了BBC的新聞報導。

2011年8月，alpha板，可以跑Debian與LXDE桌面環境，以1080p的解析度跑Quake 3，以HDMI輸出H.264的視訊畫面。

2011年12月，beta板，找到一個電路板繞線錯誤，修正後，接下來，就是準備正式問世啦。

示範影片裡頭有：以Linux開機、播放1080p的電影預告片、OpenGL ES效能測試。

2012年1月，板子好囉，先在eBay上放10片拍賣，居然競標到幾百、幾千英鎊。

2012年1月底，即將量產10000片販售。

2012.01.21，釋出修改後的linux核心原始程式碼，放在github的raspberrypi / linux（repo部分約520 MB，working directory部分約415 MB）。

底下簡述Raspberry Pi的性能規格，詳情請看這裡。

會有兩個版本Model A（美金$25、英鎊約£16）與Model B（美金$35、英鎊約£22），主要不同處為：SDRAM、USB埠、以太網路、耗電需求，除此之外皆相同。

系統單晶片(SoC)：Broadcom BCM2835 (CPU + GPU + DSP + SDRAM)
CPU：核心為ARM1176JZF-S（ARM11），700 MHz
GPU：Broadcom VideoCore IV、OpenGL ES 2.0、OpenVG 1080p30 H.264高速解碼∕編碼
SDRAM：A：128 MB，B：256 MB

視訊輸出：Composite RCA（AV端子、又稱複合端子，通常是黃色的RCA端子）與HDMI，不能同時使用
音訊輸出：標準的3.5 mm TRS端子（就是一般大小的耳機插座∕插頭）與HDMI（HDMI可輸出影像與聲音）

USB 2.0：A：1個，B：2個
網路卡：A：沒有（需要的話也可以自己插USB網路卡），B：10/100 Ethernet，一個RJ45埠（控制晶片應該是這顆SMSC LAN9512）

Model A，由SoC(Broadcom BCM2835)提供1個USB介面。
Model B的話，從SoC的USB介面接到網路控制晶片，它除了提供以太網路介面，還提供2個USB埠。

儲存空間：SD記憶卡插槽（SD/ MMC/SDIO）

板子上沒有硬碟光碟，也沒有NAND、NOR快閃記憶體。板子上有個SD記憶卡插槽，軟體部分都會放在SD記憶卡上，其中一個FAT32分割區，裝著GPU的韌體與作業系統核心的映像檔，另一個EXT2分割區裝著根檔案系統。

根據官方網站說的，應該會另外販賣SD記憶卡，裡面會放著完整的軟體部分，不過會放在網路上自由下載。

作業系統：Fedora、Debian、RISC OS、ArchLinux、MeeGo、Gentoo、QEmu、Android、等等，詳情請看這裡。

電源輸入：以MicroUSB輸入(5 Volt)或GPIO針腳
耗電需求：A：500 mA(2.5 Watt)，B：700 mA(3.5 Watt)
低階周邊：2x13的針腳，GPIO、SPI、I²C、UART、+3.3 Volt、+5 Volt
尺寸：85.60mm x 53.98mm x 17mm（跟信用卡差不多）
重量：45g
其他連接埠：DSI Connector另一條視訊輸出的管道，CSI Controller特別用來連接相機模組，JTAG Headers以JTAG介面除錯。
LED：有個紅色LED，代表接上電源了。

其他：板子上沒有時鐘、沒有電池

所以，要使用這塊板子，你還需要準備其他東西：
1. 一條Micro USB連接線，供給電源。
2. SD記憶卡，裝軟體。
3. 一台電視或螢幕，要有AV端子或HDMI。
4. 鍵盤、滑鼠。
5. RJ45網路線（Model B）。
6. 一般普通的3.5 mm耳機。

有興趣的話，請到官方網站Raspberry Pi晃晃，裡頭有部落格、論壇、維基、商店、常見問題、聯絡資訊。也可到Twitter追蹤最新消息。IRC頻道在freenode的#raspberrypi。

想買的話，要到Raspberry Pi的線上商店下訂單，目前裡面只有賣貼紙，可以先去註冊帳號、填填資料。

好想要啊，不知道搶不搶得到，運費不知多少？飄洋過海會不會撞壞啊？

讀後想法：挖開兔子洞、愛麗絲鏡中棋緣（張華）

2011-11-22T13:44:00.001+08:00

書名：挖開兔子洞──深入解讀愛麗絲漫遊奇境

書名：愛麗絲鏡中棋緣──深入解讀愛麗絲走進鏡子裡

原著：路易斯‧卡洛爾(Lewis Carroll)
原插圖：約翰‧田尼爾(John Tenniel)
譯註：張華
出版社：遠流

這兩本書，一言以蔽之，就是愛麗絲漫遊奇境(Alice's Adventures in Wonderland)與愛麗絲走進鏡子裡(Through The Looking-Glass And What Alice Found There)的註釋版，以中英對照的方式呈現，並且加上非常詳實的注釋。

為什麼要看漫遊奇境與走進鏡子裡，簡單講，這兩本是經典，你可以享受書中幻化無方天馬行空的想像力，你可以研究書中的詩詞、雙關語、玩弄語文的技巧、邏輯道理與謬論，另外，因為是經典，很多其他作品常會引用借用這兩本長青不朽著作裡的梗；更有與其直接相關的作品，譬如電影魔境夢遊，為原著故事的延續，講述19歲的愛麗絲重返魔境後的經歷，如果不知道兩本書的內容就去看電影，雖然不能說一定會看不懂，但電影中的很多梗、笑點、典故，你就會錯過、甚至一頭霧水。

不知為何，我以前常常要求一部作品應該要"自成一套完整體系"，不要要求讀者事先知道太多背景與設定，不過有些電影譬如驚聲尖笑，該影片明顯地以「惡搞、戲弄」為宗旨，將90年代的電影全部拙劣地愚弄一番，所以，如果沒看過那些被模仿惡搞的電影情節，就會看不懂。現在我改變想法了，正如教你讀懂文學的27堂課裡面說的一個理論，這個世界只有一個故事，所有事物都是有關係的，我現在認為，應該要極盡所能，找出其中相似的點、象徵性的共通表象，加以聯想並觸類旁通，自己要"主動"地去閱讀，而不要只是被動地接受。就算想錯了也沒關係，就算作者其實原本沒有那個意思也沒關係，因為能夠在抽絲剝繭串連關係時享受其中，不是會讓閱讀更有趣嗎。

愛麗絲的故事，喜愛並研究的人不計其數，譯本多如牛毛；想當初我翻閱時，只能說完完全全看不懂，不過就是一些瘋言瘋語的童話故事罷了。我曾經看過一本科普書愛麗絲漫遊量子奇境，也是完全看不懂裡面的梗。而這兩本注釋本，就是要幫你了解其中的奧祕，書中有些背景知識，是維多利亞時代那時的一般常識，與現在不同；有些梗，是英文的語文笑點；有些故事情結，牽扯到原作者與愛麗絲之間的默契，光只看原文，是很難了解這些的，而這兩本注釋本，搜羅中外各家的註釋與研究成果，細細地展現給你，這不單單只是被動地閱讀一本書了，而是主動地去了解原作者的背景，查詢書中創作的源頭，譬如赤霞貓的原型在哪兒，變成跟原作者在玩遊戲，看看讀者能不能破解書中的隱密與機關。

英文翻譯（語言翻譯），是很難的，譬如原著裡，用了某一首外國知名童謠，配上新歌詞，置入改編的樂趣與笑點，那麼，你該怎麼翻譯呢？若直接翻譯歌詞，但讀者並不知道原曲啊；選一首讀者熟悉的歌曲，將翻譯後的歌詞放進去，這樣能譯的傳神嗎；Tweeddle Dun與Tweeddle Dee的譯法至少有十餘種，有把精神譯出來嗎？諸如種種，實在太多了，像這兩本書以中英對照的方式呈現，或許是最好的辦法了吧。

總而言之，愛麗絲是西方的重要經典，不可不知不可不讀，但光讀原文理解有限，就好好看看這兩本注釋書裡研究搜羅的詳實解說罷。

PS 小小抱怨一下排版，英文中文沒有頁頁對齊，註釋跟註釋號碼上標，也沒有一定在同一頁。我知道要做到很難，這兩本書的編排算很不錯了，所以我只是"小小"抱怨一下。

讀後想法：秘本三國志（陳舜臣）

2011-11-21T19:50:00.002+08:00

書名：秘本三國志
作者：(日)陳舜臣
出版社：中華書局(香港)

作者為日本著名作家，1924年生於日本神戶，祖籍台灣。這部故事，以三國志、後漢書和資治通鑑等史料為藍本，佐以三國演義、華陽國志、典略、洛陽伽藍記與世說新語等文史著作為輔助材料，加入自己的構思創作的歷史小說。

本作品不尊劉，也不捧曹，以五斗米教的教母少容（張魯之母）、以及其養子陳潛為主角，從黃巾起義開始，直到孔明星落五丈原，小說裡，此兩者為檯面下的人物，但對於三國情勢與事件走向有重大影響。書裡以大致的手法概略寫出三國時期的情節演進，加強重點描寫各人物的性格，當然啦，礙於篇幅，不可能每個角色都得到充分的對待。

我本來以為這是部新作品，後來才發現早在30多年前就出版了，只不過最近才翻譯成中文罷了。如果你搜尋本書名，就會看到"日本人究竟懂不懂三國志"的字樣，大體而言，我也都認同網路上寫的評論，日本人熟悉的是吉川英治筆下的三國，一般人熟悉的是羅貫中的柴堆三國，每個人心中都有一部屬於自己的三國故事，所以，看到改編的地方，免不了要大肆批評一番。我對這本書的評價，平心而論，如果是在十幾年前讀到這本書，會認為是很不錯的好作品，但現在，已經看過各式各樣的三國改編作品，現在來看這部作品，就只能給出普通的好作品這種評價，這部小說寫的是很不錯的，但其中很多情節的安排，我就不太能接受了。如果從稍微嚴謹一點歷史研究的角度來看，這部作品有很多奇怪的歷史事件的看法與解釋（不過我要再次強調，這本書是30多年前的作品了），如果以輕鬆一點看小說的角度說來，這部作品可以算得上有趣的消遣讀物。

書裡有提到關於預言、匈奴單于、月氏、佛教、白馬寺、蔡琰、等等，都是我比較不熟悉的、覺得比較新鮮的，不錯，有長知識；至於我接下來講的，呃，可能會讓你覺得這是部爛作品，其實不是，我只是把我認為怪怪講不通的地方、我不能理解的地方列出來：

＊少容跟陳潛，這兩人對三國局勢發展似乎影響太多太大了吧，真有那麼神？影響黃巾起義、影響劉焉佔蜀、張魯據漢中等等，這兩人還跟曹操、劉備、孫權、諸葛亮都有交情，太厲害了吧。

＊五斗米教，影響力真有那麼大嗎？

＊少容說服三十萬青州軍，交給曹操使用，認定曹操有資格能統一霸業。

＊呂布喪命時，關羽奪走貂蟬，曹操卻誤會，反而奪走秦宜祿之妻。

＊劉備跟曹操有秘密協議，去袁紹那裏臥底，袁紹敗後又去劉表那裏臥底。這個我覺得太誇張了，劉備幫助曹操去臥底，有撈到什麼好處嗎？書中對於此事有鋪陳解釋，但我還是覺得很牽強。

＊因為顏良被劉備騙了，以為關羽會陣前倒戈，所以被關羽斬了。

＊七擒孟獲這齣戲碼，是孟獲跟孔明兩個好朋友事先套好招的。哇哩咧，有沒有這麼麻吉啊。

＊五丈原的對峙，是司馬懿與孔明私下說好雙方保持不進不退的態勢。書中的解釋我還是覺得很勉強。

＊荀彧自願假裝自己是反對曹操稱王的反對黨，藉以找出異議份子。

＊書中把曹丕描寫成是個非常冷酷的角色，敢廢漢自立，所以被曹操選為繼承人。曹丕居然讓曹植跟甄妃偷情，造成謠言，進而塑造出曹家長子被冷落的假象，藉以找出藏在暗處反曹的勢力。

總而言之，我覺得作者置入太多異想天開的陰謀論，讓人無法接受。

一些鮮為人知（我不知道）的情節：

＊孫吳因為人口外流，所以孫權派人去日本抓人當兵，也有可能是指台灣、琉球。

＊南匈奴為了進行漢化，搶奪宮女，包括蔡邕之女蔡琰，後來被曹操贖回，作胡笳十八拍。書中有詳細描寫。

＊三國演義中，陳宮因曹操殺呂伯奢而轉投呂布，在本書中，曹操因喪父之痛而屠城，違反陳宮的理念，另外，書中描寫陳宮夢想成為張良一樣的人物，而曹操自己就有智謀了，所以背叛投呂布、攻擊曹操。

另外我有個不爽的地方是，這些人都是前知一千年後知五百年的智者啊，隨隨便便就能看出將來是誰會勝誰會敗，哼，相命的說曹操是能臣奸雄也就罷了，你還能知道將來一定就是三強鼎立，誰必成大器誰會日暮西山，根本毫無根據嘛，說大話不負責。感覺就像是作者透過這些角色說話，可是作者是全知全能的上帝啊，不應該隨便跳進書中亂說話啊。這就是我很不爽的地方，作者知道後段誰誰誰會崛起（我也知道啊），就在前段透過某人很漂亮地說出"誰誰誰將成龍飛天"，哇哩咧。

總而言之，以今日看來，可以把這部作品當做有趣的消遣讀物，至於裡面的歷史解釋觀點，我就敬謝不敏了。

延伸閱讀：

1. 小說，三國殤，李民發。如果我們把三國分成3個段落，從黃巾起義到孔明出山，再到孔明病逝五丈原，再到晉國滅吳，其時間分別是34年、27年、46年，而三國演義分別用了34回、71回、15回的篇幅，其中諸葛亮活躍的時期居然有71回的巨大篇幅，不能不說羅貫中是個孔明崇拜者，但也造成一個問題，讀到越後面，越覺得沒有趣味。作者李民發補續三國演義，寫出蜀殤、吳殤、魏殤，詳述後三國時期，補足這個缺憾。

2. 小說，反三國演義，周大荒。蜀漢統一天下，帥吧。

3. 漫畫，火鳳燎原，陳某。這部作品讓故事符合歷史史實，譬如董卓火燒洛陽、劉備失徐州等等，但情節內容與過程卻被翻天覆地徹頭徹尾地改編了，趙雲是司馬家的暗殺集團首領，呂布不僅有勇且有謀，貂蟬是宦官，士氣論、暗黑兵法，各種名言，譬如"殺一個高手總比殺一百個嘍囉來得方便"，等等等等，值得一看。

4. 漫畫，天地吞食，本宮宏志。龍王之女為保青春，每隔一段時間就會下凡擷取童精，並答應對方一個願望，曹操想當天下之王，孔明獲得洞悉森羅萬象的智慧，而劉備得到了"膽"，因為我非常喜愛這部漫畫改編的大型電玩，所以找出這部相當誇張的作品來看，不過畫到劉備封禪就停了，不知道在作者腦袋中，要怎麼安排接下來的情節啊？

5. 漫畫，龍狼傳，山原義人。剛開始似乎是想讓兩個穿越時空的學生走覽三國時期，但後來就變成天地志狼的武術之道了。

6. 漫畫，超三國志霸，武論尊原作、池上遼一作畫。劉備是日本人？趙雲是女人？老實說，我看不懂，所以就沒有繼續追了，如果只是找個大家熟悉（有市場能賣錢）的歷史朝代，然後異想天開地惡搞改編，嗯，我看不下去。

7. 漫畫，蒼天航路，李學仁編劇、王欣太作畫。沒看過，聽說是以曹操為主角。

8. 電視劇，三國，2010年，導演高希希、編劇朱蘇進。雖然網路罵聲不斷，雖然曹操在劇中時不時出現太現代太雷人的台詞，不過我覺得還不錯，對於劉備曹操之間關於平天下的論述，對於孫權周瑜魯肅之間的描寫，對於曹操曹丕司馬懿之間的描寫，我覺得都很棒，另外，張飛在古城審案很好笑、貂蟬很漂亮、戰爭場面也不錯，武將單挑也不錯。看到喜歡的歷史小說變成電視劇，總是有欣喜之情，編劇幾乎都遵從著小說三國演義的路子，加入一些讓人物更深刻的設定，但又不會打亂原著的精神，我認為很不錯。

9. 電視劇，三國演義，1994，導演王扶林等，編劇杜家福等。全套三國演義變成真人連續劇，連對白也都照抄小說，想當初，真是非常感動啊。

讀後感想：教你讀懂文學的27堂課(How to Read Literature Like a Professor) by Thomas C. Foster

2011-11-09T09:20:00.000+08:00

書名：教你讀懂文學的27堂課(How to Read Literature Like a Professor)
作者：Thomas C. Foster
譯者：張思婷
出版社：木馬文化

不知曾幾何時，我越來越沒有耐心，電影、書籍、文章、部落格、動畫、漫畫、文件、等等，如果一開始覺得無趣就會隨手丟開，如果看完後抓不到內涵就會直言爛斃了，失去細細品嚐的閑情逸致，失去推敲琢磨後豁然開朗的那種欣喜，就某方面而言，在這個資訊爆炸的時代，快速過濾資料並切中核心擷取重點是不可或缺的能力，為了避免成為巨大訊息怪獸的奴隸，不得不功利、現實，有用才花時間、沒用即丟，就另一方面而言，我欣賞、解析、品味的能力長久以來都沒有提昇，很多需要好好閱讀的作品，打從一開始便被我揚棄了，許多需要細細思索的作品，看一點便被我束之高閣，這實在是個可悲可憐的現象，我可悲，作品可憐。

這本書的主題是文學，大體上指的是小說、長篇文章、短文、詩歌、等等，教導你如何看懂讀懂，雖然書中所說也可應用到其他領域，譬如戲劇、電影、電視廣告，不過書中的例子大都是文學出版品，對了，這本是講西方文學的，作者的專長是英國、愛爾蘭、美國文學。

文學作品並不是單獨存在的，互相引用、互相模仿抄襲、諷刺，有些流傳已久的典故、象徵、形象、情節，會一再地被使用、再創作。哈利波特第一集，哈利三人小隊前往阻止佛地魔竊取魔法之石的第一道關卡，是隻長著三顆頭的大狗，若不知典故，這就是道關卡罷了，知道演奏音樂能使其沈睡這個訣竅後就能過關，若是知道地獄守門犬這個典故，便感受到作者營造出冥府、地獄的用心，哈利小隊接下來將走進危險地帶，邁向未知的冒險。老人與海的最後，從海港回家的路上（耶穌前往刑場），一路上都把船桅扛在肩上（背著十字架），到家後老人躺在床上雙臂攤開露出皮開肉綻的手掌（釘在十字架上），隔天，對村民來說，老人就如同死後復生一般（復活），看到那巨大的魚骨，原本懷疑他的人又充滿信心，老漁夫為這個墮落的世界贖罪，替這個沈淪的社會帶來希望，哇，如果不知道聖經、耶穌，怎麼會聯想到這些呢，一個不知道聖經典故的人讀了老人與海，當然他會有所獲得、感動，但顯然地，他無法看出耶穌受難記這個典故。這是讀經典的必要之處，書中強調：聖經、莎士比亞、童話故事、神話，這些是必須的。當然，有些人聽到說要讀經典，就覺得暮氣沉沉，能讀當然最好，不想要的話也可以多多閱讀其他好作品，重點是，能夠在作品與作品之間，建立起連結，觸類旁通，找出相似處；意思是說，教授看到某情節可能會聯想到亞瑟王或唐吉柯德，我不認識那些傢伙啊，但我還是可以聯想，我看到某情節、某人物，可能會聯想到悟空與達爾、令狐沖、曹操啊；前人創作會引用聖經、莎士比亞、希臘神話，但我們可以引用海賊王、周星馳、還有"殺很大"啊，只不過，採用流行一時的話語也就只能在一時一地引起共識而已，那就是另外一個問題了。

我常常用自己的觀點來閱讀、用現代的視角來看作品，太執著要求虛擬世界應該要符合真實世界，這是很要不得的，不僅沒有樂趣，也妨礙對於創作的理解。不同文化、不同時空、不同背景，各有其價值觀、理想、流行指標、束縛與共識，嘗試了解多元的觀點，進而欣賞作者創造出來的世界，比較對方與自己的不同，感受其中的相同處與不同處，這樣才算盡到一個讀者的本分。

小說的一頁，你只需要花3分鐘，但卻可能耗去作者3天的時間。作品裡，每個安排都是精心設計過的（也有可能不是），為什麼在此安排飯局，雨水、河流有何意義，暴力就只是暴力嗎，為什麼要賜死這個角色，為什麼死於心臟病，翅膀與飛行的形象為何，等等等等，場景的描述，細節的刻劃，在在都有其意義，多花點心思聯想，多多觸類旁通舉一反三，在心理建立起一張網，將所有作品連結起來，作品不是從天下掉下來的，是人創作的，創作給你我看的，試著更深入了解其中的象徵與譬喻，才能挖掘出更大的樂趣。

讀後推薦：了解「人」，你才知道怎麼設計！(100 Things Every Designer Needs To Know About People) by Susan M. Weinschenk

2011-11-08T11:03:00.000+08:00

書名：了解「人」，你才知道怎麼設計！(100 Things Every Designer Needs To Know About People)
作者：Susan M. Weinschenk
譯者：謝靜玫
出版社：旗標

很久以前，當我需要報告在做投影片時，我只會使用預設的、黑白的、醜醜的樣式，還自以為很酷，自以為像我這種沒有美感的人，不需要搞"設計"這回事，現在我知道錯了。之前看了給非設計人員閱讀的設計書，了解雖然不是人人都可以成為藝術大師、設計鬼才，但只要花一點點時間學習基本的設計原則，就能讓你的投影片、海報、網頁版面、名片、傳單、各式各樣的作品，從不及格提升到80分的程度，而這本書，了解「人」，你才知道怎麼設計！，裡面提出的要點，都是以科學實驗為基礎，對照前人累積下來的經驗，關於設計不可不知的100條規則。

譬如流行的社群網站，有些人擁有幾百個甚至上千個朋友，相當驚人，但是，其中到底有多少是有聯絡、有互動的的呢？一個人最多能夠跟多少人維持緊密聯繫呢？如果說通電話、見面吃飯是種"強"連結，那麼email與社群網站這種"弱"連結是不是會越來越重要呢？寫程式的往往只註記三個數字，0、1、無限大，如果某軟體有某項"20"個的限制，寫程式的一看就會感到不妥，為什麼是20、為什麼不是40，為什麼要限制20個，然後就會著手修改。但是實際上，譬如說"最近開啟的檔案"列表，從來就沒有人需要100個或200個，大概就是10或20個，以20個當做限制來設計、來撰寫程式，跟以沒有限制為前提來進行，這兩者可是天差地遠。

人的視覺是最重要的感知器官，所以，人類是如何看、如何閱讀，有必要研究一番，以致於如何處理看到的東西、如何知道該把注意力放在哪部分、如何思考，在在都影響了你該怎麼設計產品。假若你知道9%的男性與0.5%的女性是色盲，會不會影響你畫地圖時該採用哪些顏色標示；假若你知道人們瀏覽螢幕時，會根據過去經驗與期望，以閱讀越少"字"越好為前提，你還會在網站上放上一堆有跟沒有差不多的廢話嗎；你在設計時，腦袋裡想的那一套，跟使用者實際操作時的心智模式，不知道其中的差異就不能設計出方便易用的產品了。

書中分為10個類別：人們如何看、人們如何閱讀、人們如何記憶、人們如何思考、人們如何集中注意力、人們的動機來源、人類是社群動物、人們如何感覺、犯錯乃人之常情、人們如何做決策。以各種學問與科學實驗為基礎，包括認知心理學、腦神經學、文化差異、神經與神經元、組織行為、視覺理論、等等，小小一本卻含有豐富的內容，值得一看，每一篇最後都以短短數語重點整理，非常實用。

你的設計是自我感覺良好呢？還是因為你真正了解「人」呢？

翻譯：話說平台（Stevey's Google Platforms Rant）by Steve Yegge

2011-10-18T11:42:00.003+08:00

文章：Stevey's Google Platforms Rant 話說平台
日期：2011.10.13
作者：Steve Yegge
作者的部落格（2006至今）：Stevey's Blog Rants
作者舊的文章（2004與2005）：Stevey's Drunken Blog Rants

作者簡介：
目前任職於Google，之前任職於Geoworks與Amazon。程式語言生涯中有過兩次非常關鍵性的轉換，一次是組合語言，一次是Java 跟Perl，因為發現解決語言本身設計帶來的問題所花的時間，竟然比真正用在開發軟體系統的時間還多。其文章以長度聞名，長到應該稱為論文而非部落格，兼帶詼諧筆風，發表頻率大約一個月一到兩篇，作者總是說這些是在凌晨三罐啤酒下肚後的誇誇其談，但每一篇都是經過長時間醞釀，內容充實有見地的傑作。
獨立以Java/JPyton開發多人線上遊戲Wyvern，可讓玩家自行創建擴充遊戲內容。其工作團隊將Rails移植到Rhino上，Rhino是運作於JVM平台上的JavaScript引擎，Rails(Ruby on Rails)為一套受到廣泛喜愛使用的網站開發模組；為Emacs撰寫完整的JavaScript環境，期望在Emacs上可以有一套 JavaScript IDE，以及將來可用JavaScript而非elisp來開發Emacs extensions。

注意：作者已經刪除原文，因為原本應在公司內部流傳跟同事間互相討論的文章內容，卻意外地發佈到公開網路上。希望你能夠站在不同立場來閱讀，而不是斷章取義只看自己想看的部份。

這邊有原文的備份以及留言。
Steve的Google+頁面。

話說平台（Stevey's Google Platforms Rant）

我曾在Amazon工作了六年半，現在算一算，我在Google的日子也差不多那麼長了。關於這兩家公司，有個衝擊性的差異──在我的腦袋裡這樣的印象幾乎每天都在加深中──那就是，Amazon每件事都做錯了、而Google每件事都做對了。當然啦，這是很籠統的概括評論，但卻出乎意料的是個精確說法，很瘋狂吧。你可以舉出大概一百甚至兩百種不同的項目來比較兩家公司，而Google每一項都能勝出，除了其中3項以外。如果我記的沒錯，我確實曾用試算表列出來加以比較一番，不過法律部門不會允許我秀給任何人看，即使人事招募部門會愛的不得了。

讓我給你個例子稍微體會一下：Amazon的人事雇用流程存在著根本上的缺陷，每個團隊獨自為自己招募新人，以至於，各團隊之間的雇用標準，有著天差地別的不一致性，即使他們通過各種努力來撫平差異，仍然相去甚遠，而且，他們的操作方法一團糟，沒有真正的SREs，工程師們什麼事都要做、幾乎沒時間撰寫程式碼──當然啦，各部門情況不同，取決於你的運氣。他們不碰慈善、不幫助需要幫助的人、不鳥社群集體貢獻、或是任何類似的活動，相關話題從來沒有浮現過，或許只有在閒談說笑時才會提到，他們的辦公室是個滿佈灰塵的農場隔間，連一分錢都不會花在裝潢或是公共場地與會議室，他們的薪資與紅利遜斃了，最近因為來自Google與Facebook的競爭才好多了，不過，我們有津貼或額外獎金，他們都沒有──他們只是想要讓薪資帳面上的數字好看一點，就這樣子而已。他們的程式碼就像是災難過後滿目瘡痍，沒有工程標準或撰碼規則，除了團隊各自選擇性地、局部性地自己搞自己的以外。

話說回來，公道一點，他們的確有套不錯的程式庫版本控管系統，這是我們真的應該要盡力趕上的地方，以及發佈/訂閱系統，我們也沒有相對應的東西，不過，就大體而言，他們有的不過是一堆低劣的工具，藉以將狀態機裡的資訊，讀取或寫入到關聯式資料庫中罷了。我們不該模傚或借鏡，就算可以免費取得也要棄之不理。

我認為，他們的發佈/訂閱系統、程式庫版本控管系統，是Amazon比Google強的那3個項目之中的2點。

我猜你或許可以為他們辯護，"早早推出服務並不斷反覆地改進"，他們對於此作法有著近乎偏執的狂熱，你可以說他們這點做的很好，不過，關於這點，我們也可以從另一角度來爭辯，他們把"早早推出"這點，擴及應用到所有其他事項上，譬如說軟體工程守則與戒律跟其他一票的事項與流程，而這些都是會造成長期性的影響，所以說，即使這點讓他們在市場上有了某種程度的競爭優勢，但也造成其他許許多多的問題，總結而言，這不能算得上是個漂亮灌籃得分的項目。

但～是～，他們有一件事做的非常非常好，好到把其他政略上、理念上、技術上的缺失通通彌補回來。

Jeff Bezos是位惡名昭彰的微控經理人，他對Amazon零售網站頁面上的每一點像素都要微控管理，他雇用Larry Tesler，Apple的領頭科學家，可說是全世界中最有名且最受尊敬的人機介面專家，然後，Jeff不理會Larry提出的每一項建言，整整三年，直到Larry最後──明智地──終於離開了公司。Larry應會實踐大型的可用性測試，然後憑著研究報告、不存著一絲絲疑惑地證明出，根本就沒有人能夠搞懂、使用那該死的網站，可是，對於頁面上幾百萬個都包含著意義的像素，Bezos就是不能放手，就好像是對待寶貝兒子般呵護著，所以結果是，像素通通還留著，而Larry走人。

喔，對了，微控管理不是第三項Amazon做的比我們好的地方，我的意思是，沒錯，他們微控管理做的很好，但我可不會把這項列在強項或優勢清單上，以上所言只是為了下文鋪陳，幫助你了解背景。我們現在討論的人，是個在很多公開場合說過，而且是很認真地說，人們想進Amazon工作應該付他錢才對呀，當有人跟他意見不同時，他會遞出黃色便利貼有著Jeff的名字在上頭，提醒人們"誰才是公司的老大"，這傢伙可說是一個較守規矩的，嗯，Steve Jobs，我想應該可以這麼說，除了他沒有流行品味或是關於設計的理解力以外；可別誤解我了，Bezos可是超級聰明的仁兄，只不過呢，他的所作所為，讓那些一般般的控制狂看起來只不過像是抽大麻的嬉皮罷了。

有一天，Jeff Bezos發布一份命令書，當然啦，他總是不斷地在下命令，而如螞蟻般忙碌爬行的員工就會像被橡皮槌敲擊般地受到震撼，不過，有一次的情況是──大概是2002年吧，我想，誤差1年內──他發布一份命令書，發布範圍非常廣，內容龐大且沈重，讓你的眼珠子都快掉下來了，跟這份命令書相比，其他的就好像突然收到來自同儕的獎勵。

這份大大的命令書，其內涵大致如下幾點：

1) 從今以後，每個團隊要以透過服務介面(service interfaces)的存取方式，將資料與功能開放出來，。

2) 團隊間的溝通，都要透過這些介面。

3) 行程間的溝通(interprocess communication)，其他形式一概不允許：不能直接鏈結、不能直接讀取其他團隊的資料、不能使用共享記憶體模式、不能走後門、等等，唯一的溝通管道就是在網路之上的服務介面呼叫。

4) 任何技術皆可使用，HTTP、Corba、發佈/訂閱系統、客製的網路協定、等等，都可以，Bezos不管這些。

5) 所有的服務介面，毫無例外，都必須從骨子裡設計好，能夠對外界開放，也就是說，團隊必須做好規劃與設計，能夠把介面開放給外界的開發人緣使用，沒有例外。

6) 不做的人會被炒魷魚。

7) 謝謝，祝你有個愉快的一天！

哈哈！你們這群150位前Amazon員工，一眼就看出第7點是我加上的，純為搏君一笑，因為Bezos才不會去關心你今天過的好不好咧。

不過第6點就是認真的了，所以人們紛紛埋頭苦幹，Bezos指派了幾位上級牛頭犬來監督並確保進度，由超高級跟熊一樣大的牛頭犬Rick Dalzell領軍，Rick是前陸軍突擊隊員、西點軍校畢業生、前拳擊手、前Wal*Mart的首席虐刑官斜線首席技術長，而且也是個高大、和藹、令人敬畏的男人，經常使用"硬化介面(hardened interface)"字眼的男人，Rick本身就是個會走路會說話的硬化介面，所以不消多說，每個人都做出重大的進展並確保讓Rick知悉一切。

在接下來的幾年內，Amazon的內部轉變成服務導向架構(service-oriented architecture)，在這蛻變的過程中，他們學到了一拖拉庫的知識，在當時，是有著關於SOA的文件，但跟Amazon那種超大規模比起來，那些技巧就跟告訴印第安那瓊斯過馬路前要先看看兩旁有無來車一樣沒用，Amazon的研發團隊在這過程中學到了不少、發現了不少，其中的極少極小的抽樣範例如下：

- pager escalation變得異常困難，因為ticket可能會送過來送過去，過程中會超過20個服務呼叫，然後才能找到真正的擁有者，如果每一個呼叫都花去團隊的15分鐘的反應時間，那在找到真正的團隊之前幾小時就過去了，除非，你建構出很多很多的scaffolding、metrics、reporting。

- 你的同儕團隊，每一個，突然間都變成潛在性的DOS攻擊者，你沒辦法有進展，直到在每一個服務裡放上配額限制(quota)與節流閥(throttling)的機制。

- 監控(monitoring)與品質控管(QA)是同一回事。你過去不會這麼想，直到試著進行大規模的SOA才會有此體悟。但是，等到你的服務說"喔沒錯，我很好"的時候，到那時的情況可能是，伺服器裡唯一正常運作的功能就只是那一小塊懂得用愉快機器人的聲音說"我很好，收到了，收到了，停止通話"的部份而已，為了要確認整個服務是否真正運作無虞，你必須對每一個部分都發出呼叫要求，同樣的情況會遞迴式地出現，直到你的監控系統能夠全面性地對整個服務與資料做出各種面相的檢查，到那時，就跟自動化QA沒什麼兩樣了，所以這兩者皆位於同一連續帶上。

- 如果你有上百個服務，而且你的程式只能經由這些服務來跟其他團隊的程式做溝通，那麼，沒有一套服務探索機制(service-discovery mechanism)的話，你就不能找到想要的服務，而且在那之前，你得先有一套服務註冊機制(service registration mechanism)，而這本身也是一項服務，所以，Amazon有一套全體適用的服務註冊機制，以反射可程式化(reflectively, programmatically)的方式找出服務，得知API為何、目前狀態是否可用、在哪裡。

- 跟他人程式有關的除錯，這問題變得更難了，基本上是不可能的，直到有一套全面性的標準方式，能夠在可除錯的沙盒環境內執行服務。

上面這些只是少數幾個例子，Amazon在蛻變得過程中，逐漸發現、學習了數十個、甚至數百個像這樣子的知識，關於把服務開放出去，會有幾個想都想不到的冷僻知識，不過不會像你想的那麼多，將功能重新加以組織劃分成服務後，團隊學會了不該信任彼此，就如同他們也不該相信外部的開發人員一樣。

當我在2005年中離開Amazon加入Google時，這轉變過程還處於進行式，但已經相當先進了，從Bezos頒佈法令的時間點到我離開之時，Amazon已經從文化心態上轉變成一家凡事以服務架構為優先考量的公司，到如今，已經成為他們進行所有設計時的基本原則，即使是那些僅在內部絕不會被外部世界使用的功能。

現在，他們不是怕被解雇才朝這個方向進行，我是說，他們仍然怕被炒魷魚，這點佔了在那兒生存的一大部分，在可怕海賊王Bezos的底下工作。不過，他們朝"服務"的方向前進，因為他們已經相信這就是正確的方向，關於SOA這種作法，不用說當然有優點也有缺點，某些缺點還很大，但是整體而言，這是正確的，因為，以SOA來進行設計，會產生出平台(platform)。

沒錯，這就是Bezos他的法令想要達成的目標，他以前（現在也是）對各團隊過的好不好一點都不在乎，不關心他們使用的技術為何，事實上也不去管他們怎麼進行他們的工作，除非他們有搞砸的跡象，但是，Bezos很早很早以前就領悟到，在絕大部分的Amazon居民都不知道以前，Amazon必須成為一個平台。

你應該不會想到線上賣書的網站需要成為一個有擴充性、可程式化的平台吧，你會嗎？

嗯，Bezos領悟到的第一件大事是，為了販賣銷售書籍與各種商品所打造出來的架構，可以轉變成為用途可再定義的絕佳運算平台，所以，現在他們有了Amazon Elastic Compute Cloud(亞馬遜彈性運算雲端)、Amazon Elastic MapReduce、亞馬遜關聯式資料庫服務(Amazon Relational Database Service)，以及其他可在aws.amazon.com查得到的一狗票服務，這些服務是某些相當成功的公司的後端架構，我喜歡舉的例子之一是reddit。

另一個大領悟是，他知道，他們不可能永遠都打造出對的東西，我認為，當Larry Tesler說他媽媽完全搞不懂怎麼使用那個見鬼的網站時，Bezos的某條心弦被撥動了，也不清楚說的到底是誰家媽媽，但無關緊要，因為沒有人的媽媽能夠使用那個天殺的網站，事實上，我自己都覺得Amazon網站的介面令人膽寒、卻步，那時我已經在那裡工作超過五年了，我後來終於學會，如何控制眼睛的焦點、關注在那接近頁面中間的幾百萬個像素。

我不是很確定Bezos是如何體悟到這點的──洞察到他不可能打造出一套適用於所有人的產品，不過這不重要，重要的是他領悟了，其實，這玩意有個正式的名稱，叫做可存取性(accessibility)，這是運算世界中最重要的事情。

最重要的事情。

如果你在心理嘀咕著，"啥？你是說，盲人聾人那種可存取性嗎？"，你不是唯一一個這麼想的人，我已經知道有很多很多像你這樣的人：上述那玩意對你們來說沒有可存取性，所以這觀念還沒能進入到你的腦袋裡，不了解也不是你的錯，就好像有人眼盲、耳聾、行動不便、或有其他殘疾也不是他們的錯一樣，當軟體──或可稱為概念體──不管是什麼理由，如果不能被某人存取、使用，那麼，就是軟體的錯、或是那概念的傳遞出錯了，這就是失敗的可存取性。

就如同生命中任何重要的大事，可存取性有個邪惡的雙胞胎哥哥，在幼年期享有父母的偏愛溺愛，已經成長為同等強大的復仇邪神第一名（是的，對可存取性來說，復仇邪神有好幾個），其名為安全性(security)，但是，乖乖隆個咚，這兩個從來沒被公平對待過。

不過，我主張可存取性比安全性來的重要多了，因為，可存取性若為零，你根本沒有產品，而若安全性為零，你仍然能夠得到在相當程度上算是成功的產品，譬如說Playstation Network。

所以說，對了，假使你還沒注意到，我其實可以寫出一整本書來討論這個主題，厚厚一本，填滿了那家我曾工作過的公司裡關於螞蟻與橡皮槌的有趣軼事，但那樣一來，我就永遠不可能發表這篇短短的夸夸其談了，而你也就無法讀到，除非我現在開始收尾做總結。

Google做的不太好的最後一點是平台，我們不了解平台，我們沒抓到它的意涵，你們其中一些人領悟了，但你們是少數民族，過去六年來，越清楚這一點就越讓我痛苦，我曾有一度希望，從Microsoft與Amazon來的競爭壓力，以及近來的Facebook，會讓我們集體清醒過來，並且開始動手打造泛用型的服務，不是半生不熟、特製的那種，而是，大致上類似Amazon的那種方式，一次全部到位，真正的，沒有作弊抄捷徑，並且從現在起把這點放在優先順序的第1位。

但是實際上沒有，它好像被我們放在第10還是第11位，或是第15位，我不清楚，只知道相當低；有少數幾個團隊很認真地看待這個觀念，但大部分的團隊，不是從來沒有思索過，就是只有一小搓人以小尺度的心態想過這個議題。

對大多數的團隊來說，若要求他們提供讓其他人以可程式化的方式存取他們的資料與運算資源，就算只是提供簡單粗略的服務，也是翻天覆地的大動作；他們大部分人都認為他們在打造產品，而且提供粗略服務是可悲的，回頭看看Amazon那串學習到的知識，然後告訴我，哪一點是粗略服務可以達成的，就我所知，沒有。僅提供粗略服務就好像需要汽車時卻只有零件。

沒有平台的產品是沒用的，說的更明白更正確一點，無平台的產品總有一天會被另一套平台化的產品所取代。

關於我們沒能了解平台的重要性，Google+是個超明顯的例子，從最最上層的管理領導人（嗨，Larry、Sergey、Eric、Vic，哈囉，您好），一直到最最底層的員工（嘿，就是你），都沒能了解，我們全部通通沒能體悟，平台的黃金守則是吃你自己的狗食，Google+這個平台是個可悲的後見之明，在啟動之日完全沒有API，最近我查了一下，目前也只有極少數可用的API。團隊成員之一在發佈API之時走進來通知我，我問道："所以，這是個跟蹤者API嗎？"，她臉現怒容說"對啦"，我的意思是，我那時是在開玩笑啊，但是，喔不，我們提供的唯一的API就是取得某人的訊息串流，所以，我想我把玩笑開到自己身上了。

Microsoft知道狗食守則已經有至少20年了，這已經是他們文化的一部分，已有一整個世代之久，你不能吃人類食物而給你的開發人員們狗食吃，那麼做只是為了短期的成功果實而劫掠了平台具有的長期價值。所謂平台，就是要考慮到長遠以後。

Google+就像膝蓋猛然一動的反射動作，就像是短期思考後的研究報告，根據錯誤的想法做出的結論，以為Facebook會成功其原因是他們打造出偉大的產品，但那可不是他們成功的理由，Facebook能夠成功是因為，藉由允許外界在其上開發，進而建立起一整群的產品，所以對每個人來說Facebook都不一樣，有些人把全部時間花在Mafia Wars上，有些人只玩Farmville，另外還有上百個甚至上千個不同的高品質的時間消耗機可用可玩，所以，所有人都可以在其上找到他們想要的某種玩法、用法。

我們的Google+團隊，看了看現況後說："天啊，看來似乎我們需要有遊戲，找一些人承包，嗯，為我們寫些遊戲吧"，現在，你是否開始能看出這樣的思考模式錯的多麼嚴重嗎？癥結在於，我們試圖預測使用者想要的，然後推出產品給他們。

你沒辦法做到，真的不能，沒有可靠的方法，在這個世界上，在整個電腦運算歷史上，從過去到現在，只有少數幾個人能夠穩穩地做到這點，Steve Jobs是其中一位，可是我們沒有Steve Jobs，我很抱歉，我們真的沒有。

Larry Tesler可能說服過Bezos相信他不是Steve Jobs，但Bezos明白他不需要成為Steve Jobs才能提供給所有人對的產品：大家喜歡的介面與覺得容易使用的操作流程，Bezos明白他只需要提供出平台，讓第三方開發人員來做，自然而然就會有了。

我要向某些（很多）人道歉，這些人會覺得我以上所說的不是再明顯不過了嗎，沒錯，的確是超超明顯到不行，但是我們並沒有朝那個方向前進，我們沒有領會平台這玩意，而且我們沒有體悟到可存取性的重要，這兩者基本上是同一件事，因為平台會解決可存取性的問題，擁有一套平台就是擁有可存取性。

嗯沒錯，Microsoft有平台的概念，你知道我也知道這多麼令人震驚啊，因為就其他事情來說他們通常"領會"到的程度多半不深，他們能夠了解平台完全是意外性的副產品，因為他們一開始的生意與業務就是提供平台，所以他們在這個領域有著三十多年的學習經驗，如果你去逛逛msdn.com花點時間瀏覽，假設你從沒去看過，等著被嚇到吧，那裡面的東西可是多如牛毛啊，他們擁有幾千、幾萬、幾十萬個API呼叫啊，他們擁有一套巨大的平台，其實話說回來，太巨大了，因為他們要面面俱到，不過至少他們朝著平台的方向在作事。

Amazon也領會了平台的概念，Amazon的AWS(aws.amazon.com)很棒，去看看吧，瀏覽一下，令人感到羞愧啊，我們可沒有那些東西。

很明顯的，Apple也體悟了，環繞在他們的行動平台上，基本上是非開放的形式，不過他們了解可存取性的重要，他們明白善用第三方開發團體的力量，而且他們吃自己的狗食，你知道嗎，他們做的狗食不錯吃喔，他們的APIs跟Microsoft比起來又乾淨又清爽，不能放在一起比較，而且是從很久很久以前就是如此了。

Facebook也體悟了平台這玩意，這點是真正讓我擔憂的，使得我抬起懶惰的大屁股寫下這篇，我恨寫部落格文章，我恨...加一下（譯註：指到Google+上發表），不管怎麼稱呼，反正就是在Google+上發表長篇大論，就算這是個糟糕的發表園地，但你還是這麼做了，因為說到底你真的希望Google能夠成功，我真的這麼希望！我的意思是，Facebook想找我去，其實說去就去滿容易的，但Google是我的家，所以我堅持我們要展開這場小小的家庭爭論，就算你感到不舒服也要做。

等到你被Microsoft與Amazon提供的平台嚇到後，嗯，我想也會被Facebook嚇到（我沒仔細看，因為我不想變得太沮喪），回頭到developers.google.com瀏覽一下，有很大的差別，對吧？看起來就好像你五年級的侄子搞出來的東西，當他被指派功課，試著描述一家大而有力的平台公司可能會打造出來的東西，前提是他們擁有的資源，僅是一個五年級生而已。

請不要誤解我──我知道，其實呢，dev-rel團隊可是經過一番"搏鬥"後才能把那些API向外公開，就我所知他們是很棒的，因為，他們真的領會了平台這玩意，而且如同英雄般努力掙扎地要創建出一套出來，可是，他們所處的四周環境卻是，講好聽一點是對平台冷感，難聽一點是對平台這觀念抱持著敵意。

我只是直白地描述出在一個外人眼裡developers.google.com長什麼樣子，看起來很幼稚。拜託，老天爺啊，Maps APIs在哪呢？其中有些東西還是實驗性質的專案，我有點進去看過的APIs都很瑣碎無用，很明顯地都是些狗食，甚至稱不上是好的有機食品，跟我們內部APIs比起來，簡直就是豬鼻跟馬蹄。

還有，也不要誤解我對Google+團隊的看法，他們可不是唯一的例子，現今，我們在內部進行的是一場戰爭，一邊是受壓迫、少數的平台推廣者，打一場或多或少逐漸敗退的戰鬥，而對手是勢力強大、信心堅定的產品家。

應該打造出外界以可程式化的方式存取的平台，若有任何人成功地將這觀念消化吸收、從頭到腳內化，這種團隊都是受壓迫者──我立刻想到Maps跟Docs，而且我知道GMail是往這個方向踏出第一步的團隊，但是他們很難得到資金挹注，因為這觀念不屬於我們文化的一部分，Maestro獲得的資金跟龐大的Microsoft Office開發平台相比有如九牛一毛：就好像小毛兔跟暴龍相比，Docs團隊心知肚明，除非他們能趕上Office的腳本語言功能，不然無法跟它競爭，但是，他們得不到任何關愛啊，我在此假定如此，根據Apps Script只能在Spreadsheet裡運作這點來看，而且API裡甚至沒有鍵盤快捷鍵的功能，就我來看，Docs團隊並沒有受到重視。

諷刺的是，Wave是個絕妙的平台，願他們在地底長眠，但搞出平台並不會帶給你立即的成功果實，平台需要殺手級應用軟體，Facebook──在這裡指的是，那一堆他們提供的服務，包括塗鴉牆、朋友、其他等等──就是Facebook平台的殺手級應用軟體。若你得出結論說，沒有Facebook平台，光有Facebook應用軟體也能像如今這麼成功，這可是個非常明顯的誤解。

你知道，外面的人總是不斷地說Google好自大傲慢喔，我是個Google員工，跟你一樣，每次我聽到那些話都覺得很煩躁憤怒，大體上而言，我們並不傲慢，大約99%不自大，我在文章開頭寫道──如果你回首看看久遠前的記憶──Google"每件事都做對了"，當有人說我們很自大，大部分的情況是因為我們沒有雇用他們，或是因為他們對我們的政策感到不爽，或是那一類的事情，他們推斷出傲慢這回事，因為這樣會讓他們覺得好過些。

但是，當我們擺出姿態，說我們知道如何為全部的使用者設計出完美的產品，那麼我們就是笨蛋，相信我，我可常常聽到有人這麼說，你可以用傲慢自大、天真浪漫、或其他字眼來形容──不重要，重要的是這就是愚蠢，不可能有這麼一個完美產品適用於所有人。

照這樣的思路下來，我們的瀏覽器居然不能讓人設定預設的字型大小，這不就是公然對可存取性(accessibility)的冒犯嗎，當我年紀越長，總有一天會失明，講的實在一點，我一輩子都在近視下過活，一旦當你到了40歲，你就沒辦法看清近距離的東西了，所以，字型選擇變成是生與死的問題了：可能把某使用者完全排除在產品之外，但是Chrome團隊就是這麼傲慢自大：他們希望打造出零組態的產品，而且相當自豪，誰理你是瞎子或聾子啊，誰管你，去你的吧，用你的餘生在每一個頁面按下Ctrl-+吧。

不僅是他們，我說的是所有人，問題癥結是，我們是家"產品"公司，一直都是，我們打造出成功的產品，擁有廣泛的吸引力──搜尋引擎──而那樣巨大的成功使得我們心有成見、視野偏了。

Amazon過去也是家產品公司，因為有道異常的力量，才使得Bezos領悟到他們需要平台，那道力量是他們的市值逐漸蒸發，他被逼到牆角了，不得不想方設法突圍，但他擁有的不就是一群工程師跟一堆電腦嗎...要怎麼樣才能變成印鈔機呢...你可以看出他是如何達到AWS這個結論，不過這是放馬後砲。

Microsoft從一開始就是個平台，所以他們有很多經驗與知識。

Facebook，嗯：他們讓我感到憂慮，我不是專家，不過我很肯定他們一開始也是產品，並且取得很長久的成功，所以我不知道他們何時轉變成為平台，應該是很久以前，因為他們要成為平台後那些像Mafia Wars（這些東西已有一定年紀了）才會出現。

或許，他們做的僅是將我們檢視一番後問道："我們如何擊敗Google？他們缺少了什麼？"

我們面臨一堵巨大的問題高牆，需要經過一番有如腥風血雨般的文化心態轉變後，才能開始迎頭趕上，我們對外沒有在做服務導向的平台，同樣的，內部也沒有，這表示說，整個公司都"沒有領悟"：PMs沒有、工程師沒有、產品團隊沒有、沒人有，即使單獨個人有、即使你有，那也無關緊要，除非我們把目前情況當做生死存亡之秋來處理，我們不能不斷推出產品，然後假裝之後會把產品轉變成又美又迷人的可擴充式平台，我們試過了，沒成功。

平台的黃金守則，"吃自己的狗食"，可以換句話說"先打造出平台，然後用它打造任何東西"，你沒辦法事後才把平台放進去，再怎麼說事後才想要做太困難了──去問問那些動手把MS Office平台化、或是把Amazon平台化的人，如果你放在後面才動手，事情會比從一開始就做好難上十倍，你沒辦法作弊、沒有捷徑的，你不能讓內部軟體走秘密後門擁有特殊的優先存取權限，不管理由為何都不能這麼做，難題必須從一開始就起手解決。

我並沒有說現在動手已經太遲了，但我們等的越久，就越接近"太遲了"的那一天。

老實說，我不知道怎麼收尾，我已經把今天想說的都寫下來了，這篇文章醞釀了6年之久，如果言詞間有冒犯之處，或是我誤解了某產品、某團隊、某位同僚，還請包涵，或是其實我們真的有在進行打造平台，卻剛好我以及跟我討論過的人從未聽說過，我在此說聲抱歉。

不論如何，我們必須開始把它做對。

翻譯：Xcode的建置設定Build Active Architecture Only（Xcode Build Active Architecture Only ）by Keith Harrison

2011-09-14T16:27:00.000+08:00

文章：Xcode Build Active Architecture Only（Xcode的建置設定Build Active Architecture Only）
日期：2010.04.21，
作者：Keith Harrison
作者的部落格：Use Your Loaf

作者簡介：
任職某IT公司，下班後在iPhone上開發，以及在mac上使用Ruby on Rails。

Xcode的建置設定Build Active Architecture Only

今天在Stackoverflow上看到某個問題，讓我想起在Xcode 3.2.2裡，有些新加入的建置設定，值得在這裡說明一下。隨著iPhone/iPod Touch新型機種推出，以及iPad的加入，你可以決定要將軟體編譯成哪一種處理器架構的格式，下面的設定，都放在target info的標籤Build之下（在target上按滑鼠右鍵然後選Get Info）。

Standard (armv6)

原先的armv6架構，現在以"Standard"字樣出現，產出的二進位檔案，可在所有機種上運行，如果你的軟體還需要在iPhone OS 2.x上跑的話，你應該選擇此設定，因為，根據一些報告指出，2.x的機子跟universal binary二進位檔有點不對頭。

Optimized (armv6 armv7)

若是選"Optimized"的話，這會建置出universal或稱為"fat"的二進位檔，裡面含有armv6與armv7兩套二進位檔，顧名思義，這樣的軟體檔會比較肥大，不過，當放到armv7機種上運作時，就能充分完整地利用處理器的能力。在實務上，使用者到底能不能感受到效能的提升，取決於應用軟體需要處理的事情與運算。如果你的目標對象是OS 3.x或之後的版本，一般來說，你應該選這個項目。

Other (armv7)

如果你的對象只有iPad的話（iPhone OS 3.2），你可以手動把架構設定為armv7，這樣就不會去建置armv6的部份。

Build Active Architecture Only

到目前為止，都很容易理解，但是，有件事要注意。在target的建置設定中，在Architectures那一部分裡有個叫"Build Active Architecture Only"的設定，這會影響二進位檔的建置方式，其預設值是，若是Debug組態，此設定值會被勾選，如下：

Xcode現在會偵測你有連接的機子，根據機型來設定此項目，所以，如果你插入iPod Touch二代的話，Xcode會將active architecture設定為armv6，此時，若你用上面的Debug組態來建置，那麼只會建置出armv6的二進位檔，以節省時間（除非你的專案很大，大到感覺不到，不過，我想你多多少少都能察覺出建置所需的秒數）。

當你新增Distribution組態來發佈軟體到App Store上時，你應該要確認一下，這個選項應該是"不勾選"的狀態，這樣才會建置出肥大的universal binary，如下：

每當蘋果公司推出新機型，建置流程就變得更加複雜，花時間留意一下Xcode裡出現的新選項設定是值得的，即使大家都有共識，Xcode在隱藏細節與複雜設定這一方面，做的還不錯。

Cocos2D-iPhone的安裝、移除與Hello World

2011-09-13T05:23:00.001+08:00

這篇是Cocos2D-iPhone的安裝與移除，我的環境是Mac OS X Snow Leopard(10.6.8)、Xcode 4.1 for Snow Leopard(Build: 4B110f)。

安裝非常容易，下載打包壓縮後的檔案，目前最新的穩定釋出版本是cocos2d-iphone-1.0.1.tar.gz，大小約32 MB，然後在終端機下命令：

（如果你想追求最新版本的話，cocos2d的最新原始碼放在GitHub上。）

先解壓縮
$ tar zxvf cocos2d-iphone-1.0.1.tar.gz

解壓縮後會有一個目錄cocos2d-iphone-1.0.1，基本上，這是cocos2d開發人員的工作區，我們並不直接在裡面寫程式，不過你可以用xcode開啟cocos2d.xcworkspace（如果你是Xcode 3.x版，請開啟cocos2d-ios.xcodeproj），裡面有非常多的範例與測試，請執行看看。

首先選擇好你想看的範例。

然後執行看看。

當然，這些是供測試用的範例，你可以到這裡看看用cocos2d寫的遊戲的畫面，大概了解一下cocos2d的能力。

接下來要安裝，先cd進之前解壓縮後的目錄，然後：

$ ./install-templates.sh
（可能要用 sudo ./install-templates.sh 以root權限安裝）

這支script會把cocos2d的project template跟file template安裝在/Library/Application Support/Developer/Shared/Xcode之下，在這個路徑下，會有Project Templates/cocos2d 1.0.1與File Templates/cocos2d 1.0.1兩個子目錄。

這支script有參數可用，如果用-u，那麼會安裝到使用者的家目錄下$HOME/Library/Application Support/Developer/Shared/Xcode，如果用-f，可以強迫安裝，覆蓋掉先前安裝的。

（你看到安裝路徑有含版本字串在裡面，也就是說，你可以安裝多個cocos2d版本，會被安裝到不同路徑下。）

接下來，讓我們用安裝後的project template弄出一個基本的Hello World。

執行xcode-File-New-New Project...，選擇cocos2d這個project template，

取個名字、選個目錄存放後，你可以看到：

不多說，直接按Run執行：

哇，已經出現Hello World啦。你可以試試看其他兩個project template，那是跟物理引擎有關的。

接下來，就請你看看這篇列出的Cocos2D-iPhone的學習資料，開始動手吧。

如果你想移除的話，很簡單：
1. 刪除目錄cocos2d-iphone-1.0.1，這是解壓縮cocos2d-iphone-1.0.1.tar.gz後得到的。

2. 刪除project template與file template，路徑是/Library/Application Support/Developer/Shared/Xcode/Project Templates/cocos2d 1.0.1與/Library/Application Support/Developer/Shared/Xcode/File Templates/cocos2d 1.0.1。

（或是到家目錄下去找，路徑是$HOME/Library/Application Support/Developer/Shared/Xcode）

3. 刪除你自己產生出來的xcode專案。

Cocos2D-iPhone的學習資料

2011-09-12T09:45:00.007+08:00

Cocos2D這套開放原始碼的遊戲引擎，最初是以Python寫的，後來被移植到各平台和程式語言上，有Objective-C的iPhone版、有Java的Android版、有C++跨平台版、有JavaScript的瀏覽器版。

這裡講的是Cocos2D-iPhone，以Objective-C寫的，目標平台是iOS（現在也開始支援Mac OS X）。所以，底下提到cocos2d時，指的都是這一套。

這是Cocos2D-iPhone的logo，快樂的圖案給iOS用，生氣的給Mac用。

Cocos2D-iPhone的學習資料：

1. Cocos2D-iPhone的官方網站、最新原始碼放在GitHub上、論壇、開發出來的遊戲列表。

2. 討論遊戲開發的論壇：iPhone Dev SDK討論遊戲的板面、Stack Exchange的遊戲開發QA論壇。

3. 書，Learn iPhone and iPad Cocos2D Game Development，Apress 2010年12月出版，作者Steffen Itterheim。書中用的版本應該是cocos2d 0.99.3。作者不是只出本書就算了，出書前就在自己網站上發表cocos2d的遊戲開發文章、還架設了論壇網站。另外，還把cocos2d與Wax(Lua)、iSimulate、Cocos2D-iPhone-Extensions、Cocos3D、SneakyInput、Chipmunk SpaceManager等等整合起來，名為Kobold2D，用起來就更方便了。

更新：這本書的第二版，Learn cocos2d Game Development with iOS 5，2011年11月出版，更新到cocos2d 1.0.1、iOS 5、Xcode 4。

4. 書，Learning Cocos2D: A Hands-On Guide to Building iOS Games with Cocos2D, Box2D, and Chipmunk，Addison-Wesley 2011年7月出版，作者Rod Strougo與Ray Wenderlich。書中用的版本似乎是cocos2d 0.99.5。作者Ray的部落格在此，上面有很多cocos2d遊戲開發的文章。

5. 書，Cocos2d for iPhone 0.99 Beginner's Guide，Packt 2011年1月出版，作者Pablo Ruiz。書中用的版本應該是0.99.5之前的。

以上這三本書所使用的cocos2d版本，都是1.0以前的版本，目前最新的穩定釋出版本是1.0.1。要注意的是，有些類別與方法的名稱會改變，譬如在0.99.5裡，CCLabel改名為CCLabelTTF、CCBitmapFontAtlas被CCLabelBMFont取代，所以如果你使用的cocos2d版本與書中不同的話，會遇到這些煩人的差異處，詳情請看各版本的release note。不過，1.x已經進入維護狀態，應該不會再有大改變。

6. 書，Cocos2d for iPhone 1 Game Development Cookbook，Packt 2011年11月出版，作者Nathan Burba。

7. 書，Learning iOS Game Programming: A Hands-On Guide to Building Your First iPhone Game，Addison-Wesley 2010年9月出版，作者Michael Daley。

這本不是講cocos2d，而是在iOS SDK與OpenGL ES之上開發遊戲，舉個例子，在cocos2d裡，我們有CCLabelBMFont可用來繪製點陣字型，而這本書則是自己寫出程式碼來繪製文字。概略來說，這本書的內容是，介紹各種遊戲開發的概念（sprite sheet、tile map），開發一套遊戲引擎（書中的程式碼），並實際寫一支遊戲做範例（寫出來的遊戲Sir Lamorak's Quest有放在App Store上）。

8. 書，Beginning iOS 5 Games Development: Using the iOS SDK for iPad, iPhone and iPod touch，APress 2011年11月出版，作者Lucas Jordan。

這本不是講cocos2d，而是在iOS之上寫遊戲。

9. iPhone Game Tutorials上有非常多的文章，介紹cocos2d來寫遊戲，有入門的也有進階的。

10. Cocos2D Podcast，主持人為Mohammad Azam與Steffen Itterheim。

11. YouTube上有cocos2d教學影片。

12. 書，iOS 射擊遊戲程式實務，博碩 2011年12月出版，作者松浦健一郎、司ゆき，譯者彭俊人。

除了cocos2d外，還有其他選擇，譬如Unity3D、Corona、SIO2、Oolong、Torque、Bork3D、ShiVa 3D、Galaxy、Sparrow、Irrlicht、Game Salad、Unreal Development Kit、等等，令人眼花撩亂，有2d的有3d的，有免費的有要錢的，有只支援單一平台的有支援多重平台的，挑選iOS遊戲引擎時，可以參考以下資料：

1. iPhone Game Engine Comparison – Open Source
2. The Commercial iPhone Game Engine Comparison (3D and 2D)
3. Review of 3D Engines for the iPhone
4. Thoughts on Unity3D
5. Best iPhone Game Frameworks
6. Cocos2d Podcast的Game Engines and Frameworks as Alternatives to Cocos2d
7. 其他。記得，要注意資料的時效性，某些遊戲引擎可能已經有了長足的進展，某些遊戲引擎可能逐漸式微。

寫程式用的字型

2011-09-07T13:43:00.004+08:00

這裡列出一些等寬字型（fixed-width or monospaced fonts），主要用在寫程式時，以及終端機命令列模式下使用。有些我喜歡，有些我不喜歡，見仁見智，大家試試看，自己看的順眼最重要。

挑選時，有些注意事項。

英文字母大寫O、小寫o、數字0，必須能夠清楚辨識。
英文字母小寫l，大寫I、小寫i，數字1、符號|，必須能夠清楚辨識。
符號`與'，必須能夠清楚辨識。
字型的筆劃粗細適中。
有些字型，設定在某種大小下時，非常漂亮，但可能在放大或縮小後，卻變差了。

本來我要擷取各字型的顯示當做範例參考，但是，現在作業系統各有其獨特的文字描繪技術，同一套字型在不同編輯器下看起來也不盡相同，在我的環境下可能很棒，但在你那邊可能差強人意，更何況，每個人的感覺不同、偏好不同，所以我就不放上擷圖，請自己實際用用看，要注意各種相關參數的設定，譬如anti-aliasing、ClearType、等等。

Courier、Courier New
由IBM根據打字機的字型所設計的，因為沒有維護其專利，所以流傳廣泛。
我的感覺：Courier太難看。Courier New中規中矩，筆劃有點細。
下載：各系統上應該都有安裝此字型；Courier New可到這裡找找。

Andale Mono
很多系統預設安裝的字型。
我的感覺：比Courier New好，但有更棒的。
下載：請到這裡。

Monaco、Menlo
Monaco是Apple的Mac作業系統內建的終端機預設字型，在Mac OS X 10.6被Menlo取代。Menlo是由Bitstream Vera Sans Mono改過來的。
我的感覺：不錯，在Mac上嫌麻煩的話就直接用這兩個字型吧。
下載：據我所知，只能在Mac OS上合法使用。

Consolas
Microsoft的字型，很不錯。
我的感覺：很不錯，符號*的位置偏上，我不喜歡。
下載：有版權的，據我所知，很多Microsoft的產品都會附上這個字型。

ProFont
我的感覺：不錯，推薦。
下載：請到這裡：

Bitstream Vera Sans Mono
我的感覺：整體看起來筆劃夠黑，我喜歡，但是符號*的位置偏上，我不喜歡。
下載：請到這裡。

Deja Vu Sans Mono
由Bitstream Vera Sans Mono改過來的，免費。
我的感覺：很不錯，推薦。整體看起來筆劃夠黑，我喜歡，但是符號*的位置偏上，我不喜歡。
下載：請到這裡。

Proggy
我的感覺：很不錯，推薦。
下載：請到這裡。

Inconsolata
我的感覺：很不錯，推薦。我覺得有點不夠黑。
下載：請到這裡。

Anonymous Pro
Mark Simonson設計，免費。
我的感覺：很不錯，推薦。
下載：請到這裡。

參考資料：

MoonScript幾支小程式

2011-08-23T13:10:00.000+08:00

這篇要寫幾支MoonScript程式。

關於MoonScript的概觀介紹請看這篇，如何安裝看這篇，完整的MoonScript語言參考手冊在這裡（英文）。

注意：我假設你已經會Lua了。

首先，向世界說聲哈囉吧。

寫一支沒有參數的函式並呼叫它。

func_hello = -> print "hello world"

func_hello!

func_hello()

輸出：

hello world

用->（箭頭）來產生函式，用=（等號）把產生出來的函式指派給func_hello，無參數的函式，除了可以用一般的()括號來呼叫，也可以用!（驚嘆號）來呼叫。而且這支函式的內容只有一個述句(statement)，所以直接寫在->的後面即可。

如果函式內容多於一個述句，要縮排後一行一行放在->之下。

func_hi = ->

name = "John Smith"

print "Hi, I am " .. name

接下來，有參數的函式，要把參數宣告在->之前，以,（逗號）分開，以()括號包起來。

func_add = (x, y) -> return x + y

func_add2 = (x, y) -> x + y

print(func_add(1, 2))

print(func_add2(3, 4))

輸出：

func_add有return，func_add2沒有，但兩者是一樣的，這叫做implicit return，函式執行時最後的運算式，會回傳給呼叫者。

函式可以回傳多個值。

power_of_2_3 = (x) -> x*x, x*x*x

a, b = power_of_2_3 5

print a

print b

輸出：

125

函式呼叫可省略掉括號。

print(func_add(7, 8))

print func_add 7, 8

輸出：

省略括號後，參數會被傳進離它最近的函式，所以上面的7跟8會被傳進func_add。

當情況比較複雜會搞混時，當你想控制誰是誰的參數時，就用()括號來區分。

print "9 + 10 =", func_add(9, 10), "11 + 12 =", func_add(11, 12)

可以讓參數有預設值。

func_inc = (a, b=1) -> a + b

print func_inc 10, 5

print func_inc 10

輸出：

參數預設值的運算式，會一個跟著一個被執行，所以，後面參數可以使用前面參數。

foo = (x=100, y=x+5) -> x + y

print foo!

print foo 95

輸出：

205

195

接下來，介紹非常好用的table comprehension。過去，第一次看到Python的list comprehension時，就覺得這玩意兒怎麼這麼強啊，真是太好用了，程式碼會變得更簡短，光一行就能完成超多事情。comprehension就好像把資料結構、迴圈、條件判斷式通通攪和在一起，是個高階的程式概念，底下，就讓我用MoonScript來練習寫幾支table comprehension的程式吧。

若scores裡面是學生的成績，考的太差了，只好開根號乘以10，調整一下成績，以免當太多人，下次開課會教室不夠大。

scores = {64, 33, 25, 38, 48}

scores_modified = [math.sqrt(s) * 10 for i, s in ipairs scores]

print s - s%1 for i, s in ipairs scores_modified

首先，宣告變數scores，用{}大括號產生出table，裡面放了五個人的分數，在這裡，我們把table當做array或list來用，也就是說，裡面的項目是逐一排列的。然後，我們要把這個table裡面的項目，一個一個拿出來，也就是for i, s in ipairs scores這段所做的事情，i會是index，從1到5，在這裡沒有用到，s會是那五個成績，拿到成績後，開根號乘以10，算出調整後的成績，然後用[]方括號包起來，這就是comprehension，結果會是一個table，指派給scores_modified。

然後，用迴圈輸出成績，其中s - s%1是取出整數的部分，小數我們就不要了。

讓我們算一算調整前後各有幾個人被當。

stemp = [s for s in *scores_modified when s < 60]

print #stemp

同樣使用comprehension，因為逐一取出項目這個動作很常見，所以MoonScript加入一個語法，請看for s in *scores_modified，這個*星號，會等於for i, s in ipairs scores_modified，還有，我們用when來篩選出想要的項目，在這裡是小於60的成績，也就是不及格的，然後把結果放進table stemp裡。

#井號接table，表示table的大小，不過，這只有在我們把table當做array來用時，這個運算子#才會得到正確的結果。

執行看看吧，調整成績後，還有多少人會被當呢？

接下來，MoonScript與Lua有個不一樣的地方，就是if與for不僅是statement，也是expression，意思是說，它們都能回傳值。先看看if。

寫一個函式，給定一個成績參數，判斷是否過關或被當，第二個參數可有可無，若有，表示過關的最低成績，預設值是60。

pass_or_fail = (score, score_to_pass = 60) -> score >= score_to_pass

result = ""

if pass_or_fail 60

result = "Pass"

else

result = "Fail"

result = if pass_or_fail 60

"Pass"

else

"Fail"

如果if只是statement，不是expression的話，我們就必須要用上半部那種寫法；但MoonScript是expression，所以就能用下半部那種寫法。這兩種寫法的結果result會是相同的。

接下來看看for可以怎麼用。假設從1到10，奇數就保留，偶數就乘以2，怎麼寫呢？

doubled_evens = {}

for i=1, 10

if i % 2 == 0

doubled_evens[i] = i * 2

else

doubled_evens[i] = i

doubled_evens = for i=1, 10

if i % 2 == 0

i * 2

else

如果for只是statement，那就要用上半部的寫法，但MoonScript的for也是expression，所以可以用下半部的寫法，for每次迴圈的值，會被收集起來，放進table裡，最後被指配給doubled_evens。所以，這兩種寫法的結果相同。

另外，雖然Lua也可以寫OOP，但沒有直接的語法支援，總是會有礙手礙腳的地方，MoonScript加入了class、inheritance等支援，請你自己看看吧。

MoonScript概觀介紹

2011-08-22T11:29:00.016+08:00

這一篇把MoonScript的首頁，概略翻譯出來。

MoonScript是個動態腳本語言，以CoffeeScript的語法為基礎，不過，編譯後的語言是Lua。

成功安裝MoonScript後，你會得到：兩支執行檔moon與moonc，以及Lua模組moonscript。使用moon可以直接執行一支MoonScript程式檔；使用moonc可以把MoonScript程式檔編譯轉成Lua程式檔，之後再執行；在Lua程式裡加上require "moonscript"，就能看懂、載入、執行MoonScript檔案了。

因為編譯後的結果是Lua程式碼，所以相容於各種Lua實作，包括LuaJIT，也相容於所有已經寫好的的Lua程式庫。

完整語言的介紹，請見MoonScript語言參考手冊（英文），我也寫了幾支小小的程式。接下來要概略介紹一下，因為我們可把MoonScript想像成為Lua披上並擴充較好看的語法外衣，所以你需要對Lua具有一定程度的了解。

概觀

MoonScript提供簡潔的語法，利用縮排來判斷並分割程式碼的各部分，而不是像Lua一樣使用囉嗦的關鍵字，也不是像C語言一樣使用大括號，利用縮排來定義語法的程式語言，有名的有Python。底下是MoonScript的一些述句構成。

export my_func

x = 2323

collection =

   height: 32434

   hats: {"tophat", "bball", "bowler"}

my_func = (a) -> x + a

print my_func 100

其了較簡潔的語法外，還加入了其他特色，包括table comprehensions、函式裡的implicit return、類別(class)、繼承(inheritance)、scope的管理述句import與export、以及很便利的物件建構述句with。

import concat, insert from table

double_args = (...) ->

   [x * 2 for x in *{...}]

tuples = [{k, v} for k,v in ipairs my_table]

當有錯誤發生時，它還能指出是在原先檔案裡的哪一行出錯，而不僅是編譯後的檔案。

安裝

最容易的方式是利用LuaRocks，以底下提供的rockspec來安裝：
> luarocks build http://moonscript.org/rocks/moonscript-0.1.0-1.rockspec

詳細安裝過程，我寫在另外一篇。

選用功能

如果你使用Linux，並且想用watch模式，此模式會監視.moon檔，當有變動時就自動編譯成.lua檔。你需要安裝linotify。

原始碼

專案原始碼放在GitHub上：https://github.com/leafo/moonscript

有任何問題，請到這裡回報：https://github.com/leafo/moonscript/issues

最新的開發版本（或許不能動喔）可以用底下的rockspec安裝：
> luarocks build http://moonscript.org/rocks/moonscript-dev-1.rockspec

相依於其他軟體套件

除了Lua 5.1外，MoonScript還需要底下的Lua模組：

LPeg

LuaFileSystem

alt-getopt

linotify（在Linux上的選用功能）

若你使用LuaRocks來安裝MoonScript，這些套件都會被自動取回並安裝。

學習

完整的語言參考手冊（英文）在此。

其他外掛

Vim的語法支援：https://github.com/leafo/moonscript-vim

差異處的概略介紹

利用縮排與空白字元來定義出程式區塊

所有變數宣告，預設為區域變數。

用export關鍵字來宣告全域變數，用import關鍵字來匯入table裡的東西，也就是取得一份區域性的拷貝。

函式呼叫時，括號是可有可無的，類似於Ruby。

胖箭頭，=>，用來產生具有self參數的函式。

在名稱之前加上@（小老鼠），用來指稱它是個self裡的東西。

運算子!（驚嘆號），可用來呼叫無參數的函式。

根據函式裡最後一個述句的型別，自動加上implicit return。

使用:（冒號）來分開table裡的鍵與值，而不是用=（等號）。

換行(newline)可用來區分開table裡的每一項目，逗號(,)也可以。

用\（反斜線）來呼叫物件的方法，而不是用:（冒號）。

支援+=、-=、/=、*=、%=運算子。

!=是~=的別名。

table comprehension，很便利的slicing與iterator語法。

程式碼若一行，可以在後面加上迴圈與if述句。

if述句，可當做運算式使用。

具有繼承的類別系統，建構在metatable __index屬性之上。

建構子的參數，若以@開頭，會自動指定給物件。

魔法般的super函式，將同名的類別方法對應到父類別的方法。

with述句，讓你以較短的語法存取無名的物件。

關於

MoonScript的語法，有很大程度是被CoffeeScript激發而來的。

沒有LPeg這個超棒超強的語法解析工具，MoonScript是不可能誕生的。

MoonScript安裝

2011-08-21T11:27:00.003+08:00

這一篇要講如何安裝MoonScript，至於概觀介紹可看這一篇。

我先試著在Windows XP與Cygwin上安裝，但都沒有成功，MoonScript作者也說他主要的開發平台是Linux，所以我才在我的小白Mac OS X 10.6.8上安裝，滿順利的，後來又在Windows XP裡的VirtualBox裝Ubuntu 11.04，也滿順利的。

概略步驟如下：
1. 安裝Lua
2. 安裝LuaRocks
3. 安裝MoonScript（其中某部分需要安裝git）

在Windows上的安裝過程：
我沒有成功，你可以參考這一篇，看看眾多複雜的過程，以及最後出現的問題。

在Ubuntu上的安裝過程：
因為軟體都以套件打包好了，所以安裝很順利。

1. 安裝Lua
sudo apt-get install lua5.1

2. 安裝LuaRocks
sudo apt-get install luarocks

3. 安裝MoonScript（其中某部分需要安裝git）
sudo apt-get install git（若你沒有安裝過git的話）
然後以LuaRocks安裝MoonScript（底下這行指令是MoonScript官方網站寫的）：
luarocks build http://moonscript.org/rocks/moonscript-0.1.0-1.rockspec

MoonScript需要LPeg、LuaFileSystem、alt-getopt這三個套件，所以會先安裝它們。

安裝成功後，moon跟moonc這兩個執行檔會在~/.luarocks/bin/下。

在Mac OS X上的安裝過程：
1. 安裝Lua
到官方網站的下載區下載原始碼，我下載安裝的版本是lua-5.1.4.tar.gz。
tar zxvf lua-5.1.4.tar.gz，解壓縮。
cd lua-5.1.4，進解壓縮後的目錄裡。
make macosx，建構。
make install (sudo make install)，安裝。

預設值會安裝到/usr/local下，執行檔（lua與luac）在bin底下，其他檔案散佈在include、lib、man、share底下。

2. 安裝LuaRocks
到官方網站下載，我下載的是luarocks-2.0.5.tar.gz，

tar zxvf luarocks-2.0.5.tar.gz，解壓縮。
cd luarocks-2.0.5，進解壓縮後的目錄裡。
./configure
make
sudo make install

預設值會安裝到/usr/local下，執行檔（luarocks與luarocks-admin）在bin底下。

3. 安裝MoonScript（其中某部分需要安裝git）
到這裡抓取Mac OS X的git安裝程式，按照下載後的dmg檔裡面的README.txt的指示安裝。

然後以LuaRocks安裝MoonScript（底下這行指令是MoonScript官方網站寫的）：
luarocks build http://moonscript.org/rocks/moonscript-0.1.0-1.rockspec

MoonScript相依於LPeg、LuaFileSystem、alt-getopt這三個套件，所以會先安裝它們。

安裝成功的話，最後應該會出現如下的訊息：
moonscript 0.1.0-1 is now built and installed in /usr/local/ (license: MIT)

moon a.moon to run moonscript script file
moonc a.moon to compile it to lua code

moon跟moonc這兩個執行檔會在/usr/local/bin/下。

接下來就是寫MoonScript的程式，附檔名用.moon，以"moon xyz.moon"來直接執行，或是以"moonc xyz.moon"把MoonScript程式轉成Lua程式。請確定moon與moonc這兩支執行檔有在你的執行路徑PATH下。

完整的語言參考手冊在這裡（英文）。

神偷天下（by 鄭丰）讀後感

2011-08-01T16:17:00.002+08:00

注意：內有惡犬（劇情），請慎入。
注意：基本上這是一篇寫給自己的讀後感，拜讀鄭丰三部作品後把想法記錄下來；但這不是為了推薦此小說所寫的介紹文章，所以，如果你還沒看過此書，我想，還是不要往下看這篇文章比較好。

書名：神偷天下（共三卷）
作者：鄭丰
出版社：奇幻基地

昨日到書局走走逛逛，要啟程回家之時，才突然瞥見這套鄭丰的新作，心中覺得奇怪，怎麼沒在其他家書店發現呢，一看書後的出版日期，7月28日初版一刷，這可是熱騰騰的新書啊，或許其他書店尚未到貨上架吧，話不多說，立刻帶走（喂，小子，要先付錢啊）。

主角是個小偷，不過從書名可知，必定不會單純是個雞鳴狗盜之輩，內文一開始也引用了莊子的“竊鉤者誅，竊國者侯”詞句，隱隱指出主角會扮演影響整個國家舉足輕重的角色。

本書的年代設定在靈劍之前，所以間或提及在天觀雙俠與靈劍中出現的前輩人物，諸如醫仙、文風流、神卜子、虎俠、雪豔、胡兒、百花仙子、丐幫趙漫、青幫成傲理等等，譬如醫仙為主角治傷、百花仙子取走萬蟲噬心蠱等情結，但出現篇幅不算多，情節描寫概略敘述帶過，說到底，主角其實不算個武林人物，共三本的頁數裡，第一本前半花在主角的出身，以偷盜為業的三家村，後半開始，主角便在東廠、皇宮、錦衣衛四處周旋，第二本作者讓主角遠離京城，跑到了邊蠻之地，瑤族、苗族、蛇族、大越國（交趾）等地，第三本再回到京城，主角打交道的角色，都是皇宮朝廷的人物，太監、貴妃、皇帝、太子、將軍、錦衣衛等等，雖然有虎俠這個武林中人對主角與情節發展有重要的影響，但畢竟不是重點所在，主角的所作所為，最終將會盜取天下，但又不是給自己，而是幫賢明的太子在爾虞我詐危機四伏的處境裡登上皇位，最後還犧牲自己的性命換取太子的壽命。老實說，我覺得，這真的是個很奇怪很奇怪的設定。

主角的能力，就是超高明的飛技與取技，也就是輕功與盜竊的技巧，不過武功就很普普通通了，書中主角最常做的事情，就是潛伏在他人宅邸，竊聽情報，不論是皇宮禁城還是監牢，來去自如無影無蹤，但這麼一來，就有別於一般武俠小說主角的行事與情節發展的過程了，譬如尋秦記的項少龍，作者會“偶爾”讓他偷聽到敵人的陰謀，以便扭轉情勢反將一軍，但本書卻是以竊聽為主軸，生於黑夜行跡隱密，倒掛屋樑絕無聲息，花上時間就能聽到敵方的詭計，一切都在主角的掌握之中，這會不會太方便了啊？段獨聖與凌霄有特異功能，那是種能顛覆整個世界的能力，所以靈劍要花上篇幅來介紹、處理（後來也把靈能毀去），本書主角有此超隱密的能力，而且無往不利，每每都能竊取到需要的情報，但到了最後的最後，卻沒能竊聽找出敵人的陰謀，以致於，主角要賠上自己的性命換取太子的壽命，這會不會太奇怪了啊，怎麼偏偏到了最後會竊聽不到呢？“偷聽”這回事，似乎在武俠小說裡在情節安排上免不了要出現，但如果要讓它常常出現，如我所說的，那就會跟一般武俠小說的基本設定不一樣，需要好好安排啊，不然會讓人（我）覺得不合理。

我看了尋秦記小說好幾遍，也看了電視劇，古天樂演的真不錯。

在天觀雙俠裡，有對於使毒精采的描寫，讓我眼睛一亮。本書中雖有對於偷盜的描寫，開鎖、陷阱、暗格、密室等等，但我沒有覺得太特別，難道是因為我看過鬼吹燈盜墓的小說嗎，所以，雖然本書有描寫了一些特殊練功的法門、各種寶物的來歷與介紹、竊取時的情境與過程、盜之有道的敘述，不過，或許是因為已經看過盜墓小說裡誇張有趣、天馬行空、荒誕不經的描寫，以致於看這本書時但並沒有讓我感到太特別。

另外，在第二本裡，主角跑進了邊荒之地，到一望無盡的靛海（叢林）裡去冒險了，有拜蜘蛛的瑤族與操控蛇群的蛇族、有天下奇物血翠杉，與老虎搏鬥、中了蜈蚣毒，還到了大越國（越南），幫國王黎灝攻下占城，還中了蠱毒，作了苗族苦力，參與了苗族巫王的爭鬥，雖然過程描寫的不錯，但我總有一種感覺：為什麼要有這些情節呢？為了要描寫主角與百里緞的情感糾結嗎，為了要詳細描寫主角的個性嗎，為了鋪下後文所以要介紹苗族的蠱毒嗎，為了除了描寫中原也寫寫邊疆地帶的風土民情嗎，種種問題在我腦里盤旋不休，對了，同前，因為看過了鬼吹燈到雲南、湘西、西域各地異想天開的冒險故事，以至於，這第二本並沒有讓我感到新奇有趣。

覺得神偷天下第二本裡的歷險故事很有趣嗎？可以看看鬼吹燈系列與其他相似的作品喔。

第三本，要開始進入結局了，主角得知他的身世卻又帶來給他甩脫不去的煩惱，亂七八糟的皇宮、東廠西廠權力傾軋勾心鬥角，主角為保太子不得不做盡壞事，差點被被虎俠所殺，不過，都不算是一般武俠小說的情結（啊，對了，是我搞錯了，這部作品不是武俠類的），愚昧的皇帝、擅權的貴妃、互別苗頭的太監們，我讀這些劇情，並沒有什麼感覺，讀著主角的發展，倒是總有一股很怪異的感覺，主角的個性，作者應該算是有描寫出來了，但我又覺得怪怪的，抓不住他到底是個怎麼樣的人啊，極度壓抑嗎，捨己為人嗎，因為備嘗艱辛所以一心要助太子登基讓這個世界更美好嗎，他的所做所有最後終於偷到了天下，但最後自己也死了，這是怎麼樣的一個人物啊，雖然作者從一開始就極細心地描寫，劇情人物與心境轉折都有寫出來，不過我卻不太能領略，或者是因為主角是個我不能代入的角色吧，不能將自己想像成主角，也就不能想像出那是個怎麼樣的情形，也就不能了解主角是作者所說的，是個活在無可奈何的情境下、身不由己的人物。

作者在後記中寫著，天觀雙俠是歡快的，靈劍是悲壯的，神偷天下是沉鬱的，我深有所感，神偷裡的人物，似乎沒有一個是能讓人高興快樂起來的，看著看著心情會變得很糟糕，作者又說，心境變了、作品也不斷轉型，以前，大家說金庸的鹿鼎記不是武俠小說，現在，我也認為神偷天下不像是武俠小說了。

[廣告] Embedded Linux 嵌入式系統開發實務第二版

2011-07-30T10:30:00.010+08:00

嗨，我翻譯了一本書，在這裡打打廣告。

書名：Embedded Linux 嵌入式系統開發實務 第二版
原書名： Embedded Linux Primer: A Practical Real-World Approach 2/E
作者：Christopher Hallinan
譯者：我
出版社：旗標

這是一本嵌入式 Linux 系統的入門實務手冊，作者憑藉著極為豐富的經驗，廣泛且詳盡地介紹嵌入式 Linux 系統裡各個需要研習的主題，包括：處理器、Linux 核心、初始化的過程、bootloader 開機載入程式、驅動程式、檔案系統、BusyBox、開發環境與工具、除錯技巧、建構系統、即時作業、udev等等，手上擁有這麼一本書，就能一窺嵌入式系統的堂奧，進而繼續深入研究。

本書從下到上、從硬體到軟體，都能深入淺出地加以著墨解釋，書中使用了各種範例，譬如Beagleboard、ARM XScale 平台，讓你了解眾多平台其相同與不同處，作者將多年業界戰績提煉出來，在書裡各個角落常常有一字千金的寶貴經驗談，可千萬小心不要錯過了。

書中每一章的最後一小節，作者都盡責地附上延伸閱讀與參考資料，這是非常重要的，因為以一本書的篇幅，不可能把嵌入式 Linux 系統的所有細節通通涵蓋，有了作者細心挑選出來的著作，讀者可以進一步鑽研某主題。

本書原文書是本非常棒的好書，銷售量據說是市場上數一數二的，翻譯時我盡量秉持著技術正確且語句通順的原則，讓大家看到的是一本中文書而不是英式中文，還希望我的翻譯能夠讓大家滿意。

最後在此感謝能有這個機會來翻譯這本好書，也感謝翻譯過程中前後兩位編輯（黃先生、張先生）的細心與付出。

相關連結：
1. 旗標網站關於此書的介紹。
2. 天瓏書局。
3. 博客來、金石堂。
4. 原文書的網站。

勘誤表：
2-17，2.3.4小節上面那一段的最後一句。少了中文翻譯。
把"(MTD)"改成"(記憶體技術設備, MTD)"

2-28，最下面。參考書籍的書名與作者名弄混了

把"Bruce Perens Prentice"改成"Bruce Perens"
把"Hall"改成"Prentice Hall"

4-22，表格4-6
仍然有些地方因為太長而被強迫斷行，有些地方沒有對齊。

7-42，7.6.3第一段。標點符號錯了
"Micromonitor："的冒號改成分號"；"
"：LinuxBIOS"的冒號改成分號"；"

9-5，列表9-2最後面
"180"跟"days,..."應該在同一行

9-11，最下面的命令列
提示符號跟指令之間應該有個空白
把"$tune2fs"改成"$ tune2fs"

10-2，第一段。打字錯誤。
把"底階"改成"低階"

10-7，最上面第四行。文句不順。
把"跟 loopback 裝置不同的, 是被複製"改成"跟 loopback 裝置不同的是, 被複製"

[廣告] 馬上就能用! iPhone SDK 程式碼即可貼

2011-07-29T21:23:00.000+08:00

嗨，我朋友翻譯了一本書，在這裡打打廣告。

書名：馬上就能用! iPhone SDK 程式碼即可貼
作者：高山恭介、広部一弥、松浦晃洋
譯者：我朋友負責翻譯，我負責審校程式碼的部份。
出版社：旗標

這是一本iPhone開發超好用的工具書，因為你需要的功能十之八九已經有人寫過了！書中有113招，都是寫好的程式碼，直接用，又快又省時！

市面上有很多 iPhone SDK 程式開發的入門書，這些書都教我們從無到有的學習寫程式，然而，一旦實際開發程式，卻碰到很多需要自己解決的問題──例如「該怎麼鎖住畫面不讓他旋轉」等等...這類問題接連地發生，難道得花時間一一從頭寫起？

本書是以開發過程中常需要的小功能為主題，像是Xcode專案管理的小技巧、Objective-C程式撰寫的訣竅、UIKit使用介面的過場效果與動畫效果、如何處理圖片、音效音樂播放與錄音、硬體版本與功能的判別、網路連線的小訣竅、資料庫SQLite的注意事項、各種外部函式庫的使用等等，這些功能其實已經有人寫過了！你可以隨時拿這些程式碼兜在自己的程式中，而不必自己再花時間找資料研究如何撰寫，大大節省程式開發的時間！

書中內容皆為常見的問題，作者一一整理加以介紹解說，可以省下你大把的寶貴開發時間，這是一本非常有用的好書。

相關連結：
1. 旗標網站關於此書的介紹。
2. 天瓏書局。
3. 博客來、金石堂。

翻譯：Xcode裡要用哪支編譯器─GCC還是LLVM？（Compiler Options in Xcode - GCC or LLVM? ）by Keith Harrison

2011-07-23T08:32:00.000+08:00

文章：Compiler Options in Xcode - GCC or LLVM?（Xcode裡要用哪支編譯器─GCC還是LLVM？）
日期：2011.03.21，
作者：Keith Harrison
作者的部落格：Use Your Loaf

作者簡介：
任職某IT公司，下班後在iPhone上開發，以及在mac上使用Ruby on Rails。

Xcode裡要用哪支編譯器─GCC還是LLVM？（Compiler Options in Xcode - GCC or LLVM?）

如果你用的Xcode是3.x版，而且還沒摸過改過專案裡的建置設定，那麼，你用的編譯器大概還是GNU Compiler Collection(GCC)。蘋果公司對GCC所投注的維護人力正緩慢地抽離減少，而且逐步轉移到一套嶄新的編譯器技術上，Low Level Virtual Machine(LLVM)，這是一個開放原始碼的專案。築基LLVM之上的開發工具，Xcode 3跟4都有（有些許差異），所以，不必等你過渡到Xcode 4，在那之前就可以開始享受LLVM帶來的好處。

LLVM計畫

所謂的LLVM計畫，是一套開放原始碼的工具組（完整列表請見LLVM.org），建構在一組核心函式庫之上，這組函式庫提供了optimizer（程式碼優化器）與code generator（機械碼產生器），LLVM計畫裡的其他工具還包括，Clang frontend parser（前端語法解析器）與LLDB debugger（除錯器）。Xcode利用了這一套模組化的作法來提供新功能，譬如，加強syntax highlighting（語法加亮、上色）、提供撰碼時常見錯誤的修正建議。

當我寫這篇時，GCC還是Xcode 3裡預設的編譯器，但Xcode 4釋出後，新建專案預設的編譯器改為LLVM-GCC。在這篇裡，我要來檢視一下Xcode 3、4可用的選項。

Xcode裡的編譯器選項(Compiler Options)

在Xcode裡，透過建置設定(build settings)來更改專案(project)或目標(target)的編譯器選項，版本3跟版本4的編譯器選項，有著些許差異，請看：

Xcode 3可用的編譯器版本

Xcode 4可用的編譯器版本

實務上，我們有三個選擇，看你要繼續用GCC、改用LLVM、或是混著用以取得向後相容性，GCC 4.0就不提了，因為已被揚棄不用了，在Xcode 4裡也看不見了，底下這張圖秀出三種選項的不同處：

各選項背後所代表的意涵有些許差異，看你的Xcode是3還是4，還有，看你是以iOS還是Mac OS X為開發對象。

繼續用GCC老古董(GCC 4.2)

如果你需要，是可以繼續用GCC 4.2，但是，蘋果公司已經發出聲明，他們不會繼續維護修正GCC裡的臭蟲，所以，這不是個長遠的可靠選項。GCC 4.2是Xcode 3裡的預設編譯器，Xcode 4裡還看得見。

LLVM-GCC 4.2

這個選項將兩者混著用，以GCC當frontend parser，把LLVM當後端的optimizer和code generator，這是Xcode 4新建專案的預設編譯器選項，在Xcode 3裡你要自己手動選用。改用LLVM-GCC的主要理由是，它同時具有效能提昇與更快的建置(build)速度，不過，建置時間僅為有限程度的縮短，因為，這個選項仍然以GCC為前端解析器，而且，若你建置的是除錯版（這是你花上大部分時間的地方），它不會啟用optimizer。

LLVM編譯器

這個選項完整使用LLVM的工具組，使用Clang為前端，LLVM為後端的optimizer與code generator，蘋果聲稱，除錯建置時，Clang parser的運行速度是GCC的三倍快，而且還維持著與GCC的相容性，另外，Clang的優點，不僅是速度較快，如果你已經使用過Xcode的Build and Analyze（建置並分析），那你已經見過Clang的威力了，它能夠提供更準確的錯誤與警告訊息，並提供如何修正程式碼的建議。

譬如說，如果你要使用某個之前宣告過的變數，卻打錯字，Clang很聰明，可以找出你真正想要的變數名，並且提出修正建議，然後，在處理後面的程式碼時，它會假設該錯誤已經修正過，這樣一來，會減少無意義的錯誤訊息，你就能輕易地找把心力放在真正發生錯誤的地方，Xcode利用這點，提供Fix-it功能，你會在程式碼裡看到修正建議，點一下就能接受並訂正程式碼：

所以，如果我這麼寫：
NSString *myText;
myTest = [[NSString alloc] init];

Xcode會利用Clang作出如下的訂正提示：

iOS與Mac OS X的差別

較早版本的Xcode僅支援OS X，但從Xcode 3.2.3之後，LLVM編譯器就開始支援iOS與Mac OS X兩個平台；之前Xcode+LLVM不支援C++，不過這項限制我相信已經不存在了，所以，不論你要在iOS或Mac OS X上開發，都可以使用LLVM。

需要注意的限制是，LLDB除錯器僅在Xcode 4上有，目前只支援Mac OS X，如果你開發的是iOS軟體，就沒辦法選擇LLDB除錯器，目前，你只能用GDB。

要選哪個？

那麼，三選項你該選哪個呢？目前我絕對不會用的是，老舊的GCC 4.2，除非你有很強的理由堅持要用，蘋果已經不再維護它了，而且LLVM-GCC看起來更好。在專案中途更改編譯器選項，這可是個大變動，所以，如果你要改，當然要經過審慎完整的測試。

對新的軟體專案而言，LLVM-GCC看起來應該是個安全的選項，蘋果公司認為它夠穩定夠成熟，所以才把它當做Xcode 4的預設選項（你或許不會把穩定成熟這兩個字眼跟Xcode 4本身畫上等號），而且，既然這選項使用的是GCC parser，向後相容性應該沒問題。

我說LLVM-GCC是個安全的選項，但我並不是指Clang/LLVM比較不安全，只是成熟度還沒那麼高罷了，我將一些以前的程式碼拿到Xcode 4上，使用LLVM 2.0編譯器重新編譯，到目前為止還沒發現任何問題，如果你也試過卻問題，我很有興趣聽聽詳細的細節，請留言告知。

一致性

2011-05-22T11:17:00.001+08:00

在很久很久以前，看完一本書，通常是指某程式語言的書，就可動手開發軟體了，現在可不同了（早就不同了），就算你能在24小時內學會某語言，你還要學會成堆成山的函式庫與類別庫，許許多多約定俗成的慣用法與程式片段，多少的青春歲月就花在這些層層疊疊的架構中，多少的辛酸血淚就灑在這些有臭蟲又不更新、不想用又不得不用的醜陋框架(framework)裡，唉，怎一聲長嘆了得。

寫程式時，需要一種天份，能夠在短時間內記住很多小細節的天份，變數名稱、函式名稱、回傳值、上下繼承關係、這段程式碼應該要寫在哪裡才好、等等，久了之後，自然而然熟極而流，越寫越順，當你能夠控制環境，這裡指的是掌握開發軟體時的環境，就會感到快樂，對每一行都確實知道在幹嘛，不用寫一寫就要停下來查文件，能夠處於那種優遊自在的狀態，真是美妙地不可言喻啊，所以，如果很不幸地要你換一種語言、換一套開發環境，那將會是極端苦痛、痛不可言、言語無法形容地不幸啊，光程式語言本身就會有很多的差異，有大有小，大的也就算了，畢竟是不同的語言，如果沒有一定程度以上的差別，那幹嘛存在多一種的語言了，至於小的，就很惱人了，有些一樣、有些差不多一樣、有些不太一樣、有些不一樣又有相似處，煩死啦。

請看一下底下這兩張圖，這一張是Perl的布林比較，當我在Perl書裡讀到其比較的判斷法則時，心理只有一種想法，瘋啦瘋啦，誰能記住這玩意兒啊？這什麼規則啊？（當然，我記不住不代表別人記不住。）

這一張是JavaScript的，好像好一點，但也處處是陷阱，一不小心程式的結果就會跟你想的不一樣。

顯然地，各程式語言的創作者對於這麼一個小小地方都能夠有眾多分歧的意見，什麼是true、什麼是false，nil又能代表什麼，nil能代表空串列嗎、nil等同於false嗎，等等等等。

當某語言有太多細微細節要花心思記得的話，用起來就很礙手礙腳，我認為Perl就是其中之一，Perl還標榜著"There's more than one way to do it"，聽起來是不錯，不過怎麼能記住這種種不同的用法呢？通常是選出一兩種好的，然後一直用吧。C++比較好一點但也差不多，當開始使用C++各種較進階的功能時，例如exception或template或operator overloading，哇賽，各種眉眉角角就出現了，要記住的地方就變多了。

很佩服那些跨平台的框架或軟體，光要搞定windows、mac、linux就快死人了，其中的差異可不是隨便就能講完列出來的，若是說到手持式裝置上，那就更加分歧了，再加上封閉、保護公司資產、追求與眾不同市場區隔、刻意與別人不一樣，嘿，真是混亂的世界啊。

在這裡有個小小的希望，至少、至少在語言層級，能夠有一致性，不是每個人都能像翻譯機精通八國語言聽說讀寫樣樣行，我知道，語言設計者是大師們，他們有思想有文化有所堅持，但是還是請你們至少把布林比較這麼基本的地方設計出一致性吧。

如果你對程式語言的歷史以及各種語言特性有興趣的話，看看這段影片吧。這根本是大師級的火力展示，裡面一堆聽都沒聽過的語言，例如KRL、COMIT、等等。

別再遜了 Don't suck

2011-05-21T20:20:00.002+08:00

看完了Mike Lee的演講Making Apps That Don’t Suck，隨手寫寫。

先簡介一下Mike，他長久在mac圈打滾，曾在蘋果公司工作，曾在Delicious Monster工作，這是一套得到Apple設計獎的軟體，是Taplous的創辦人之一，這家公司的Tap Tap Revenge是在iPhone上超紅的遊戲，或許你沒聽過，請想像一下，在幾年前，這遊戲就像現在的Angry Birds一樣紅。

演講的主題，就是怎麼生產出好東西，特立獨行如Mike，自然會給出跟一般認知不同的見解。一般我們常聽見的，有好的團隊、好的點子、好的技術，既然這麼好，所打造出來的自然而然地會是偉大的產品，接下來就會有個疑問，為什麼我們沒賺錢呢？想啊想，想啊想，想辦法獲利啊。

Mike的三步驟可不是這樣，開宗明義就要假定我們遜斃了，要誠實，然後找出原因，接下來，想辦法不要那麼遜。這就是打造偉大產品的三步驟。

抱歉，其他細節就不多說了（我很懶），大家自己看看演講影片吧，對我而言，看完後得到的一個整體映像就是，要追求品質，不要想錢的事情。嗯，好像太老生常談了。影片中有舉Trism為例，這是支賣很好的iPhone遊戲，可是沒想到，在Mike眼裡，其介面如此不堪啊。

在很久很久以前，讀到了Joel Spolsky的邊開火邊移動，我大笑，節錄一段如下：

當你進入狀況後, 要繼續維持並不算太難. 我的一天通常都是這樣子的: (1) 上班 (2) 看信看網頁等等 (3) 決定應該吃過午飯後再做事 (4) 吃完午飯回來 (5) 看信看網頁等等 (6) 終於決心該開始幹活 (7) 看信看網頁等等 (8) 再度下定決心真的該開始做事 (9) 把該死的編輯器叫出來然後 (10) 不斷地寫程式直到突然發現已經下午7點半了.

哈哈，相信每個人都曾經歷過這樣的循環。我最近寫了支在iPhone上打逼逼的軟體，有時也會發生提不起勁、整天打混的情況，所以，我想，要生產好產品，要成功，就目前而言，我的三步驟是：

１．打開那該死的編輯器。
２．進入那無以名的狀態、忘記時間、忘記全世界。
３．保持士氣高昂。

PS 寫完這篇，發現內容實在很跳脫，嗯，真糟糕啊。

[廣告] Hit BBS，在iPhone上打bbs的軟體

2011-05-11T08:48:00.000+08:00

嗨，我寫了一支在iPhone上打bbs的軟體，在這裡打打廣告。

希望大家多多支持。

想知道更詳細的說明，請到Hit BBS的官方網站。

Hit BBS是支iPhone軟體，讓你瘋狂打逼戰鄉民。

Hit BBS大體上會有四種畫面。

1. 站台列表，可以一次上好幾個bbs站台。
2. 站台編輯，輸入網址與帳號密碼，登入時自動送出。
3. bbs畫面，有放大縮小功能，看的清楚。
4. 若bbs畫面上有網址，可以開啟瀏覽器，哇，瀏覽PTT的表特版真方便啊。

如何取得iPhone的UDID（識別碼）

2011-04-15T13:29:00.001+08:00

每部iPhone都有一個獨一無二的UDID（Unique Device IDentifier，識別碼），由40個字母及數字所組成。

譬如說像這樣：2b6f0cc904d137be2e1721536f5664094b000000。

可用以下步驟取得：

將iPhone連結至電腦後，打開iTunes，會出現底下這個畫面：

此時，在序號(serial number)上用滑鼠點一下，就會變成UDID（識別碼）。

利用編輯-拷貝(Edit-Copy)，即可把這串UDID複製下來。

時間是什麼？Rethinking Time in Distributed Systems by Paul Borrill

2011-04-10T11:02:00.000+08:00

主題：Rethinking Time in Distributed Systems: Can We Build Complex Systems Simply?
演講者：Paul Borrill

放在YouTube上的演講錄影，投影片在此。

在史丹佛大學演講的錄影，探討“時間”到底是什麼玩意兒。

我們有分散系統、雲端運算、多核心處理器、多行程多緒程、平行處理等等，就算是單一支程式裡也會有好多個物件在交互作用，軟體規模越來越大，系統越來越複雜，我們要怎麼建造呢，能夠控制得宜嗎，有好方法嗎？硬體部分，處理器的核心越來越多，但是軟體方面呢，有誰思考過了嗎；網路儲存部分，數量這麼多的資料中心，其軟體呢，有誰思考過了嗎？

在科學界，時間已經不斷地被檢驗不斷地被思考，愛因斯坦說：時間不過是幻覺而已。馬赫(Ernst Mach)說：我們根本沒有能力以時間來測量事物的變化，相反的，我們是透過事物的變化因而產生時間流動的抽象概念。可是在電腦科學界，我們對於時間概念的認知，遠遠落後於物理學家跟哲學家。電腦科學家的時間概念，大概是從涂林機來的，在一條一維的帶子上面打洞，我們也接受了牛頓的絕對時間觀，但這已經在一百多年前就被證明是錯誤的啊。

演講中提到的延伸閱讀：Leslie Lamport關於分散式系統的論文，譬如Time, Clocks, and the Ordering of Events in a Distributed System以及The Byzantine Generals' Problem。

時間沒有方向性，時間不會流動，時間不是連續的，因果律是個迷思，“現在”這個概念，如果不加上“這裡”是沒有意義的。哇嗚，好慘喔，講到這裡我已經迷迷糊糊了，境界太高囉，還是請大家看看演講錄影，自行體會吧。

什麼都沒讀

2011-04-03T15:48:00.001+08:00

去台北逛了一圈圖書街（重慶南路從衡陽路到忠孝西路），四處晃晃，到處看看，很多書想看，卻又提不起勁閱讀，這是怎麼回事呢？真是糟糕啊。

之前看了萬城目學的《鹿男》原著小說與日劇，雖然有些故事情節有破綻、有點說不通，不過看著看著還滿有趣的；《鹿男》（奈良）、《鴨川荷爾摩》（京都）與《豐臣公主》（大阪），被稱為關西奇幻三部曲，本想求個完整通通看完，就字數上來講這也不是什麼難事，但卻又一拖再拖，感覺一旦錯過了時機、錯過了心情、錯過了奇蒙子之後，就不太想碰了。去書店看到新作出爐──《鹿乃子與瑪德蓮夫人》，似乎又燃起一點點的上進心，但一想到理應先把缺看的補回來比較好，就又開始懶懶的，怠惰之心一起，便無計可施徒呼負負也。

九把刀新作《殺手，價值連城的幸運》，因為之前看了九把刀對直銷的打臉文，所以對這本有興趣，沒想到，居然包膜封起來了，有這麼貴重嗎？

看到《新文化苦旅》，裡面有新作、有把之前的《文化苦旅》與《山居筆記》整理精選，文章依舊是好的，想當初學生時代看到余秋雨的《文化苦旅》時，大驚失色下巴都快掉了，怎麼文章這麼好，怎麼文化底子這麼深厚這麼廣博啊，現在似乎少了那麼點激情，下手買是不成問題的，但又怕放上書架後積灰塵，忘記是誰說過：書是越看越少的，這句話似乎可以成為我惰性的開脫之詞。

發現台北地下街（新光三越一帶），那裡跟台鐵高鐵捷運以及市民大道的地下街都打通了，在那裡，新開了誠品，我駐足了一會重讀了幾頁的《傷心咖啡店之歌》（朱少麟），很喜歡這本書，現在還是很喜歡，我好像把這本跟《燕子》送給某朋友了，不過還好，最喜歡的《地底三萬呎》還在我書架上，能夠有幾本這種過段時間重新閱讀會有不同感受的書，真的非常幸福。

中午到市民大道地下街的美食區吃午飯，發現那裡有女僕服務茶飲店耶，呵呵。這裡還有電玩、轉蛋、模型、日文書雜誌等等，哇賽，海賊女帝蛇姬的模型耶，好讚啊。

看到一本《彩繪山海經》，生動地彩繪了山海經裡的奇人異獸，而且旁徵博引了其他文化裡同類型的神話與傳說，譬如中國有女媧，那其他神話裡類似的存在呢？相當不錯，不過我書架上已經有一本《圖說山海經》，所以也沒下手買，哈哈。

看到一本《戰國武將家紋軍旗事典》，介紹各種家紋的緣起，軍旗的形式等等，這些家紋是一大特色，相較之下，在電玩三國志裡，都是用面旗子繡上君主的姓氏就完啦。

到天瓏晃晃，發現中文書排行榜的前幾名都是Android的，厲害。發現一本新書《Objective-C Phrasebook》，滿不錯的，作者很熟悉各種Objective-C runtime的歷史與現況，先看完第一本學Objective-C的書後再看這本，會有很大的幫助，釐清很多觀念。很久很久以前，到天瓏只會看到男的，現在偶爾會看到女的了。看到有位爸爸帶著小孩，大概國中吧，在挑選C++、C#之類的書，居然還打算買VB的書，嗯。好多我想要的書都好貴啊，嗚嗚。另外，《Orange's 一個作業系統的實現》與《30 天打造 OS！作業系統自作入門》，很想買，但是，買了又覺得沒時間細看，不細看的話其實就不需要買了，唉。

喜愛的圖文書作者高木直子的新作《一個人吃太飽：高木直子的美味地圖》，不錯不錯，在書店站著看了一半，應該會買吧。

《誰在地球的另一邊：從古代海圖看世界》，這本書我很感興趣，以前人是怎麼畫出地圖的呢，就算是現代人，也常常不知道哪裡是哪裡。

翻了翻金庸最新修訂版，老實說很不喜歡，何必呢，不想多說了。

有些書店的員工要穿制服，拜託拜託，花點錢嘛，制服都那麼難看，那不是選舉背心嗎？搞什麼鬼啊。

PS 沒看到什麼正妹，殘念。

讀後推薦：老貓學出版

2011-04-01T17:45:00.000+08:00

我看了這篇部落格，「書渴望自由」出版實驗：老貓學出版 EPUB 版無保護上市，讀了老貓實驗性地免費散佈出來的新書〈老貓學出版〉。你可以到這篇部落格裡的連結下載epub格式的電子書，然後去找適合你平台的電子書閱讀器，譬如這裡，就可以閱讀這本電子書了。

書裡內容非常豐富，有關於出版的基本知識與名詞解釋，有探討排版、封面設計、書籍的頁數與定價，有述說編輯的辛酸血淚，有翻譯外文書的種種內幕，有出版社的經營手法與成長故事，網路與數位化對發行書籍的衝擊，有回憶有話當年，等等，非常值得一看。

「電子書」到底是什麼？要怎麼推廣？可否完全取代紙本書？國外情況如何？台灣情況又如何？如何向音樂產業取經？書店、經銷商、出版社、作家等角色，將來又會如何？作者不僅身處這道浪流之中，也時時在思考將來的走向，書中很多篇文章以及作者的部落格都在對這個議題不斷地提出看法與思索，這次作者實驗性地把一本新書免費以電子書形式散佈出來，不知道結果會如何，總之，有實驗有數據，才能依此制定下一步吧。

你猜，我有沒有實際拿錢出來贊助作者呢？

讀後想法：孤劍不折（柴田鍊三郎）與祕劍．柳生連也齋（五味康祐）

2011-03-31T16:47:00.000+08:00

這類小說被稱為「時代小說」或「劍豪小說」，時間通常設定在戰國、江戶幕府，在那樣子的大時代背景底下，故事圍繞在擊劍的藝術打轉，主角通常是劍豪，追求劍的極詣。

我看了下面兩本，很少，寫寫這篇感想。其實已經看完很久了，居然拖到現在。也不想再看其他同類型的小說了，又是三分鐘熱度的表現，哈哈。

孤劍不折（柴田鍊三郎）

祕劍．柳生連也齋（五味康祐）

因為設定在歷史朝代中，書中多半有真實歷史的根據，幾分實幾分虛就看作者的需求了，或許弄出個國家滅亡殘存的公主由主角來保護，或者在有實際考證之中插入想像的外傳，譬如說，孤劍不折的主角，神子上源四郎，其受業師傅正是小野忠明，生存年代為1569-1628。

下圖在信長之野望-革新裡，小野忠明的能力值。這類劍豪角色多半被設定為統率很低（帶低打仗能力差），武勇很高（使出絕招時很厲害），同類型的角色還包括：宮本武藏、佐佐木小次郎、上泉信綱、柳生宗嚴、丸目長惠等。

書中最吸引我注意的，大概就是劍術（刀術）與戰鬥的描寫，譬如說：
柳生流有一招奧義叫「月陰」，那是從日月陰陽中，選定月與陰的劍法奧義。月有形，照明暗夜；陰無形，代表黑暗。正因為有月光，才看得見陰。例如在暗夜決戰時，看不見敵人的身影，也看不見自己的影子。這樣要以什麼作為對象呢？敵我雙方都像在黑暗中探物般，揮刀掃動地面。看出對手以長劍探尋時的光影，展開攻擊。

當然了，招式是劍尖朝下的下段招式，當敵人看準我方小腿出劍時，配合其劍身的光芒，接連使出反照出我方劍光的快劍，此稱之為「月陰」。

月陰又轉化出「山陰」這項奧義。這是陰陽表裡，對敵人的變化能應付自如的一種變化。山陰又轉化出宛如烈風吹襲海面，激起波濤的「浦波」這招秘技。

當我初看時，有一種新鮮感，跟熟知的金庸古龍等武俠小說的描寫不太一樣，讓我眼睛一亮，書中還有很多這類劍術招式奧義的描寫，當然，老梗不能一直用，作者也會竭盡腦汁想出天馬行空的招式，配合日落、配合心氣神等等，最後往往達到劍人合一的境界，劍招就代表使劍的人，劍手是什麼樣的人才能使出那樣的劍招。

書中也會有描寫時代背景、人物故事、情節鋪陳等，雖也不錯，但我看過便罷，或許是沒興趣吧，也許是無法領略其筆法吧，總之，並不會特別記得些什麼。

我是先看孤劍不折，這是一本四百多頁的故事，覺得很不錯，所以又買了祕劍．柳生連也齋，這裡面是11個短篇故事集結成書的，有喜歡的也有看的昏昏沉沉的。後來就提不興趣看其他本了，感覺興致已盡，況且，書架上還有好幾本小說沒看咧，orz。

我對這種日本劍道會產生些許的興趣想多了解一點，大概是來自玩太閣立志傳跟看日劇鹿男吧。

日劇鹿男，堀田取得大和杯優勝時的場景。

太閣立志傳是個靈活度很高、遊樂性很強的遊戲，從早期你只能當武將，到後來你可以當劍豪、忍者、商人等等。下圖為比劍的畫面，以卡片來戰鬥，修煉後可取得秘技奧義等強力卡片使出招式。

一個人格格不入，格格不入的一個人。

2011-03-31T10:11:00.000+08:00

PS 這篇部落格不過是些無病呻吟，沒什麼好看的。

人生啊，總會浮現許許多多的問題，有些簡單有些複雜，有些無限多解有些無解，就算自以為找到了，免不了一定會有是見樹還是林的疑惑，又再次陷入重複循環的陷阱裡，如此一而再再而三，不是發瘋就是放棄。

此時，就算是走完長長的哲學之道，也只會腳酸，腦子也不會更清楚。

人啊（我是說我啦），就算在一群人之中，也會突然恍神，魂魄不知道飄到哪兒去了，哇哈哈。

霸王傳說第十八卷中巽凱與獵火的對話。

有人說，就算把全世界的財富集合起來然後平均分配給所有人，不出十年二十年，財富又會回復到原本的分佈狀況。有朋友的人去到哪都交得到朋友，另一種人的朋友數目只會越來越少。所以說，個性決定命運，我越來越相信了啦。

聽著陳綺貞的歌，旅行的意義，我們知道，有些話真的不能也不會被說出來。

You can't find it, create it. 這是我在澳洲旅行時看到最感動的話，尋找只是過程，創造成為結果。

哈哈，不知所云，睡吧睡吧，田園將蕪胡不歸，月明星稀胡不睡。

翻譯：多型不行時（When Polymorphism Fails ）by Steve Yegge

2011-03-30T21:04:00.000+08:00

文章：When Polymorphism Fails（多型不行時）
日期：2004.08.25
作者：Steve Yegge
作者的部落格（2006至今）：Stevey's Blog Rants
作者舊的文章（2004與2005）：Stevey's Drunken Blog Rants

作者簡介：
目前任職於Google，之前曾任職於Geoworks與Amazon。程式語言生涯中有過兩次非常關鍵性的轉換，一次是組合語言，一次是Java 跟Perl，因為發現解決語言本身設計帶來的問題所花的時間，竟然比真正用在開發軟體系統的時間還多。其文章以長度聞名，長到應該稱為論文而非部落格，兼帶詼諧筆風，發表頻率大約一個月一到兩篇，作者總是說這些是在凌晨三罐啤酒下肚後的誇誇其談，但每一篇都是經過長時間醞釀，內容充實有見地的傑作。

獨立以Java/JPyton開發多人線上遊戲Wyvern，可讓玩家自行創建擴充遊戲內容。其工作團隊將Rails移植到Rhino上，Rhino是運作於JVM平台上的JavaScript引擎，Rails(Ruby on Rails)為一套受到廣泛喜愛使用的網站開發模組；為Emacs撰寫完整的JavaScript環境，期望在Emacs上可以有一套 JavaScript IDE，以及將來可用JavaScript而非elisp來開發Emacs extensions。

多型不行時（When Polymorphism Fails ）

每個愛好OOP(object-oriented programming)的人順理成章地也會是多型(polymorphism)的狂熱份子，有很多本來可以更好的書籍（譬如Fowler那本講重構(refactoring)的），竭盡所能地傳達出一種信念：如果你用了執行期間型別檢查(runtime type checking)，也就是Java的"instanceof"運算子，那麼你大概是個壞胚子，是那種會手拿switch恐嚇小孩子的邪惡角色。

總括來說，若是用上了"instanceof"，這通常就表示程式的OO作的不好，這點我是同意的，那表示設計的技巧不足，兩相比較起來，應該要盡量使用多型，而不是執行期間型別檢查，寫出來的程式碼會比較乾淨比較容易維護，然而，我認為，至少存在一種狀況，這種狀況很常見到處都有，有資格稱為一個範式，在這種情況下你根本無法使用多型，如果你知道怎麼用，拜託告訴我，我很渴望知道，但我認為不太可能，至少在Java或C++這種靜態語言裡是不可能的。

多型的定義

若是你不是很熟悉OOP的術語，讓我解釋一下，多型是個矯揉造作的詞彙，它的概念其實就是延遲連結(late binding)，而延遲連結這個詞彙也很矯揉造作（繼續往下看你會知道其中的奧妙），它的意思是，把找出哪個方法(method)要被呼叫的決定延遲到執行期間才作，到那時才判斷被呼叫的對象目標是不是能回應訊息。

以效能為優先考量的語言，譬如C++、Java、OCaml，方法(methods)會被賦予數字編號，每個類別都有一張表記錄著有哪些方法，在執行時會掃描這張表找出被呼叫的方法；而另外一方傾向於在執行期間時能夠擁有較大彈性的語言陣營，其找出方法的手段，通常是對方法的名字作雜湊(hashing)來判斷，除此之外，這兩種方式其實可看做是同等的。

光有虛擬方法(virtual methods)並不會帶來多型，多型冒出來的條件是：當你有好幾個子類別(subclass)繼承自某一個類別，每一個子類別都實作自己的多型方法，而且各自處理方式皆不相同。舉一個教科書上用到爛的例子，如果你去動物園，你會看到，動物們處理createBadSmell()訊息的方法都不一樣，嗯，或許從某些觀點來看會有共通極為類似之處，我猜啊，做那回事時的聲音大小算是個重點，我還是無法判斷出，到底是河馬還是長頸鹿的表現能力比較好，不過，有興趣的話你可以在過段時間後再來問問我。

多型大搖大擺地炫耀著

舉個實際一點的多型範例吧，讓我們來看看一個面試中會問的經典評估問題，就我所知，這是由Ron Braunstein帶進Amazon的，這問題的內涵相當豐富，企圖要探測出求職受試者是否擁有各種重要的技能：OOP設計、遞迴、二元樹、多型與執行期間型別檢查、一般撰碼技巧、以及（如果你要搞成這麼難的話）語法解析理論(parsing theory)。

進行在某個時間點，求職者應該能夠領悟到，可以把數學運算式以二元樹表示出來，在此假設只有二元運算子的情況，如"+"、"-"、"*"、"/"，樹葉節點皆為數字，內部節點皆為運算子，想求出運算式的值就表示要把這棵樹走過一遍，如果受試者想不到這點，你可以適當地引導他們走到這一步，或是，若有必要的話，直接告訴他們也行。

即使你直接提示他們，這仍然會是個有趣的問題。

這問題的前半部分，某些人（為了人身安全我不敢點名，但他們的名字字首是Willie Lewis）覺得"如果你叫自己是個程式開發人員而且想在Amazon工作的話，這是一定要會的啦"，但事實上是有些困難的，問題的前半部分是：你如何把一個數學運算式（例如在一個字串裡），例如是"2 + (2)"，轉換成一棵運算樹，在我們的ADJ挑戰賽中應該有出現過這一題。

問題的後半部分是：假設這是個兩人專案，你的夥伴，讓我們叫他"Willie"，負責把字串轉成樹，你負責簡單的部份：決定Willie應該用什麼類別把樹建構出來。你可以挑任何一種語言來用，但一定要確實挑出一種來，要不然Willie會用組合語言寫好交給你，要是不幸遇到他心情不好，那麼會更慘，他會用那種處理器已經停產的組合語言寫給你。

有很多面試求職者被這梗擊中爆笑不已喔，驚訝吧。

我不會給出解答，不過，標準的壞答案是，使用switch或case的語法（或是老派一點，一連串的if）；稍微好一點點的答案是，使用儲存函式指標的表格；而大概稱得上最佳的解答是，使用多型。我鼓勵你做做看這題，很有趣喔！

諷刺的是（底下你就會看到），如果你想要打造一套可擴充有延伸性的系統，使用多型是相當理想的解答，如果你想要在系統內加入新的函式，而不想重新編譯整個系統──特別是，不想在那個有500個case的巨大分支指令裡加入更多的case，那麼，你就會想要使用多型。

用三種多型形式的歡呼來為多型喝采

所以，多型，講了這麼多，看起來還滿有用的。至今，多型最有用的地方是，呃，多型print。如果你用過Java、Python、Ruby或其他"真正"的OO語言，那麼多型print對你來說不是什麼新鮮事，你下命令叫物件把自己印出來，天呀，就印出來了，每個物件會印出內部狀態，恰恰好是你所需要知道的，在除錯、追蹤、記錄時非常有用，甚至在製作說明文件時也很有用。

如果你用的是有著扭曲OO外表的語言，例如C++或Perl這種強加裝上物件導向配件的語言，就好像是把一對價值美金2500的輪胎邊框裝在1978年的速霸陸老舊車款上，那麼，你能用的就是除錯器，或是Data::Dumper，或是類似的東西。哈，可憐喔，你啊！

（反問句：為什麼我們選擇使用C++與Perl呢？此兩者為世上最爛的語言是也！照同一標準的話，也可以用Pascal和Cobol啊，哭吧，大聲一點。）

順便說一下，最近我都沒提到OCaml，主要原因就是多型print，OCaml沒有提供多型print，原因我還沒完全搞懂，但大概落在"設計者的嚴重精神失常"那附近，因此，你沒辦法為了除錯而隨便叫一個物件在主控台上print出來；我希望他們這麼設計是有其必須性的，譬如為了能讓OCaml達到那擊敗C++效能表現的神奇傳說，若非如此，那就好像在使用便利性上打了一巴掌污辱人嘛，不過至少OCaml有支能夠穿越時空往回走的除錯器，你必定會需要它的。

總之！我們喜歡多型，多型就是微控管理的反面，你叫物件做事情，無需告訴他們要怎麼做，而他們就會忠實無誤地到網路看上整天的Strong Bad影片，嘿，那群笨笨的物件啊！愛死他們了。

可是，可是，多型啊，就好像所有的正義角色，擁有黑暗的一面，就多型這個案例來說，並不像，嗯，安納金天行者的黑暗面那麼黑，不過，不管怎麼說，黑暗面就是黑暗面。

多型的矛盾

要在程式碼裡使用多型，有個不明顯但非常要緊的條件：在之後你還能增加東西進去。至少，對靜態語言來說，例如Java與C++，如果你增加了一個多型方法，你必須重新編譯那些實作出方法的類別，也就是說，你需要擁有原始程式碼，並且能夠進行修改。

在我的能力範圍內，至少可以說出，的確有某一類系統是做不到這件事的，那就是：可擴充系統(extensible systems)。

讓我們假定，你正在打造一套嶄新的系統，允許使用者自行加進程式碼，這可不是件簡單的任務，有很多理由要考量，包括保密安全性、緒程安全、以及其他許許多多的地方，不過這種系統是存在的！譬如說，有些線上遊戲可以讓玩家放進他們自己寫的程式碼，毋須存取原先的遊戲原始碼程式，大部分的多人線上遊戲都朝著這個方向前進──管理階層意識到，使用者想要而且有能力創造出好的內容出來，所以讓遊戲把APIs公開出來，讓玩家能夠打造他們自己的怪物、法術等等，藉此擴充延伸遊戲系統。

嗯，我聽到某種聲音告訴我說，網站服務(web services)也走向類似的道路。

在任何時候你想打造出這種可讓使用者進行擴充的系統，就需要花費三倍多的心力，多出來的兩倍工作量在於，把你內部APIs與類別安排整理好，使得它們是可以被使用者所修改運用的。

Java的Swing就是個很好的範例，打造可擴充系統時，你就會跑進創造者矛盾(Inventor's Paradox)的弔詭中，你可以上網找找看，不過它的中心大意就是，你沒辦法事先預想出，你的使用者想要對系統的哪些部分進行修改。你可以把限制一直往外推──就算是你把系統裡的每一行程式碼都搞成虛擬函式並公開出去──即便如此，你的使用者最終仍然會跑到某個他們沒辦法客製修改的地方。這真不幸啊，我也不會假裝我知道答案。Swing的應對方式是：搞出一拖拉庫的掛勾(hooks)，使得它變成一套龐大無比的API而很難搞懂。

怪物問題

為了讓說明更加具體，讓我們回到線上遊戲的案例，假設，你已經極盡所能地把APIs與類別都弄好公開出去，可以用來創造與操縱法術、怪物、以及其他遊戲中的物件，假設你已經寫好許許多多的怪物類別了，我想你一定可以想出不少。

現在，假想有一個玩家，想要參與並寫一隻叫做OpinionatedElf小怪物。這是個故意設計出來的假設，就好像自動機停機問題(halting problem)證明自己的論點那樣不自然，不過，在實際上的確會發生類似的狀況。

假設，這隻OpinionatedElf其唯一的使命，就是大聲嚷嚷著他喜歡還是不喜歡其他種類的怪物，他會坐在你肩膀上，無論何時當你碰見一隻，譬如說獸人(orc)，他就會歇斯底里抓狂叫喊著："我恨獸人！！！啊啊啊啊啊！！！"（附帶一提，這句話就是我對C++的感覺。）

這個問題的多型解法相當簡單：找出你那150個怪物類別，每一個都加進doesMrOpinionatedElfHateYou()方法。

天啊，聽起來白痴極了，但是，這真的就是使用多型的解法，沒錯吧？如果你有一堆類似的物件（此例就是一堆怪物），這些物件都要根據某種狀況做出不同的回應，所以，你加進一個虛擬方法，然後替每個物件實作出不同的程式碼，沒錯吧？

顯而易見，這該死的解法行不通，即使你硬來（你沒辦法硬來，因為撰寫這隻小elf的玩家並不持有原始碼），也是一種差勁的設計法，沒道理把這麼特殊的方法(method)放進遊戲裡每個怪物物件裡，這點很清楚，假如一段時間後，我們發現OpinionatedElf有版權問題而必須移除掉，怎麼辦？到時你就必須回頭找出那150個怪物類別，一個一個移除掉。

就我所知（我並沒有聲稱自己是個程式設計高手，僅是個想知道正確答案的人罷了），正確解法會是使用執行期間型別檢查(runtime typing)，程式碼大概會長的像下面這樣：

    public boolean doesElfLikeIt ( Monster mon )
    {
        if ( mon instanceof Orc ) { return false; }
        if ( mon instanceof Elf ) { return true; }
        ...
    }

我知道我知道，你這個OO狂，你可以寫出150個附加類別來幫助OpinionatedElf，每一種怪物由一個類別負責，可是，那樣並沒有真正解決根本的問題喔，問題核心所在是，這些眾多紛紜的行為全部都落在呼叫者(caller)身上，而不是被呼叫者(callee)，那就是這些行為的歸屬之地，在呼叫者裡，就是那裡。

較高階的程式語言，對這個問題擁有稍微好一點的優雅解法，注意，我強調只是"稍微好一點"，譬如說Ruby，你可以為其他類別加進新的方法(methods)，即使是內建的類別也行，即使是你沒有原始碼也行，舉例而言，你可以把下面程式碼放進OpinionatedElf檔案裡：

    class Orc
      def doesElfLikeMe; return false; end
    end

    class Troll
      def doesElfLikeMe; return false; end
    end

    class ElfMaiden
      def doesElfLikeMe; return true; end
    end

    ...

如果還沒載入的話，Ruby實際上真的會把你指定的類別通通都載入，並且把你加入的方法放進每個類別裡，一般而言，這是個相當不錯的特色。

不過呢，在這裡讓我來說說這種作法的優缺。對Ruby（以及其他大部分高階語言）來說，方法(methods)就是放在雜湊表(hashtable)裡的項目罷了，每個類別分別有一張表，上面所述的特色，實際上發生的動作就是，跑進每個怪物類別裡，把你的東西塞進雜湊表裡去。優點有：

    * 所有關於OpinionatedElf的程式碼都被封裝在他的檔案裡面
    * 在elf檔案被載入前這些程式碼並不會被載入
    * 系統裡的任何其他人都可以向某物件詢問，問elf喜不喜歡他

缺點是當加入了新怪物，而elf無法辨別時，此時你需要有預設的行為。如果某人加入怪物類別小精靈(gremlin)，你的elf就會卡住，亂吼亂叫地說"啊呀，那是什麼啊？"，直到你更新加入處理小精靈的程式碼為止。

我猜想，如果你能以某種手法列舉出系統裡的所有類別，然後檢查是不是繼承自怪物類別，然後就應該能以數行程式碼達到上面所說的。若是Ruby，我打賭你做得到...不過僅限於已經被載入的類別，而對那些還躺在磁碟裡的類別可沒用啊！你或許還是可以想辦法解決，但可別忘了網路的存在啊...

話雖如此，需要有預設的行為這點，還不算太糟，還有更慘的缺點，緒程安全(thread-safety)是其中之一，這點深深地困擾著我──以這個案例來說，我不認為Ruby對於緒程安全所下的語意是定義清楚的，有把類別鎖住(class lock)嗎？載入elf類別前所執行的物件，其執行所在緒程，鎖定又會做些什麼呢？我日文不夠好，無法得知證明的方法存在於標準規格文件中還是在實作程式碼裡。

但是，真正的問題，真正困擾我的問題是，你的程式碼會跑進系統裡並且散佈到所有的類別中，這感覺起來，就像是違反了封裝(encapsulation)原則。

事實上，比那還要更深層一點，這感覺起來像是個差勁的設計，我們的情況是，有個觀察者，做出判斷的呼叫，而我們把判斷的程式碼塞進被觀察者裡，這不就好像是，我走到所有員工面前，交給他們一塊牌子，說："請拿著這張牌子，上面寫著我喜歡或是不喜歡你"。這可不是真實世界的運作方式，而OOP不是應該要模擬這個世界嗎。

再次審視多型

嘿！至此，我已經說的相當明白了，多型不再能被當作銀色子彈了，即使是一個無擴充性的系統，如果你需要根據目標對象的型別來決定做什麼動作，那麼，把判斷的程式碼放進目標類別裡是不對不好的。

一個更實際更樸實的例子是，身分認證(authentication)，讓我問你：如果你要設計一套權限管理系統，你的設計裡會有一個虛擬的doYouHaveAccess()方法，然後讓所有來人自行實作該方法？換句話說，你會請一個保全警衛，讓他去問每個人是否有權限進入建築物嗎？

絕對不會，你會在程式碼裡做執行期間型別檢查：

    public boolean denyEntryToBuilding ( Person p )
    {
    return ( p.hasNoBadge() ||
        p.isSuspiciousLooking() ||
        p.hasMachineGun() );
    }

但是，等一下，這些檢查並不是公開檢查類別啊，譬如，我並沒有說"p instance of MachineGunBearer"，這是怎麼回事？

嗯，所謂物件的"型別(type)"，實際而言，指的是它的類別(class)（幾乎是寫死的，就像是基因）以及屬性(properties)總合起來的合集，在執行期間可能會也可能不會改變。

那將是另一篇部落格了，但，我認為這代表了，型別最好由屬性而非類別來代表，因為類別有著與生俱來的固定性，但是在"傳統"語言裡，像是C++與Java，這會讓程式碼更難以共享，因為沒有支援語法委託(syntactic delegation)的特色，如果你覺得我說的沒道理，it's OK：我正在喝第三杯酒，快要不省人事了，讓我們把這個題目留到另一篇文章罷。

在此，我希望我把論點說的夠清楚了，也就是，當多重行為是目標對象的行為時，使用多型才有意義；當行為屬於觀察者一方的話，你需要執行期間型別檢查。

總結

嗯，我希望你在今天的醉後部落格有學到一些東西，我知道我有，其一，我學到Google的搜尋引擎的確有足夠的智能可以把"anikin skywalker"修正為"你是說anakin skywalker嗎？"哎呀，那群厲害的渾球，這不像是他們擁有著作權呀。

我也學到了，一篇部落格的長度應該剛好是兩杯葡萄酒，如果超過，你就會開始半昏迷語無倫次，打字也會打到地獄去了。

下週見，接下來的主題是...

Stevey's Drunken Blog Rants(tm)
(發表於2004年8月25日)

兩個影片網站，InfoQ與Channel 9。

2011-03-28T23:21:00.004+08:00

最近在網路上東點西連的時候，似乎常常會跑到這兩個影片網站，上面有不少好東西。

Channel 9 Videos about the people building Microsoft Products & Services
顧名思義，這網站以Microsoft的技術為主，不過也會有別的，例如Dr. Ralf Lämmel的functional programming教學五部曲，談論expression problem、type classes、language interpretation、monads、folds(aka bananas)，哇，好多不懂的喔，什麼是banana（香蕉）啊？

InfoQ Tracking change and innovation in the enterprise software development community
這網站很豐富，有人物訪談，例如請Rob Pike談談Go語言，也有技術展示，譬如Clojure的爸爸Rich Hickey介紹這個在JVM上的新functional語言，聽聽Douglas Crockford對JSON vs XML的看法也不錯。

世界真是大啊，網路真是浩瀚啊。

遞迴很重要啊

2011-03-28T21:08:00.000+08:00

Recursion（遞迴、遞歸、迴歸），很重要啊。

最近，幫某人檢查他寫的程式，是用Matlab寫的，雖然我不太會，但他也沒用到什麼了不起的特色功能或是函式庫，所以我邊看邊學倒也OK。

他需要看一篇論文，理論證明的部份搞懂後，論文最後有跑程式模擬得出數據，但是論文作者似乎沒有公布原始碼，所以指導教授要他寫出程式出來，一來可以實際動手並且更了解論文內容，二來，有新的理論模型時，可以修改程式，跑出新的數據，測試看看新的模型可不可行，可行的話，我想那就是一篇論文囉。

細節部分就不多說，最難（對他來說）的一個地方是，給定n個東西，要用窮舉法排列出所有的排列組合（總共n!種），每種排列組合都要做某種運算，所有組合的運算值得知後，找出其中最大的值。

老實說，當我看到他用iteration（疊代）的方式來寫，也就是說用loop（迴圈）來寫，真的嚇了我一跳，因為，我看不懂啊！我雖然幫他用recursion的方式寫了那部分的程式碼，不過他執意要用迴圈寫，唉，搞不懂為什麼耶。經過一番努力後，我終於看懂網路上用iteration寫recursion的程式碼，不過我還是沒看懂他的程式碼，Orz。

遞迴很重要啊，很多演算法用遞迴寫是多麼自然、多麼簡單啊，會寫程式的人可別說你不會recursion。

翻譯：趕羚羊之程式設計宣言（The Motherfucking Manifesto For Programming, Motherfuckers）by Zed A. Shaw

2011-03-28T15:26:00.001+08:00

文章：The Motherfucking Manifesto For Programming, Motherfuckers 趕羚羊之程式設計宣言
日期：2011.03
作者：Zed A. Shaw
作者的部落格：ZED SHAW

趕羚羊之程式設計宣言（The Motherfucking Manifesto For Programming, Motherfuckers）

草泥馬們看過來，
這是一份程式設計之
趕羚羊宣言。

我們是一群每天都在趕羚羊的程式設計獅，多少年來，我們被所謂的軟體開發方法論(software development methodologies)不斷地羞辱踐踏。

我們已經受夠了，不論是插屁(XP)、爭球(Scrum)、看版(Kanban)、瀑布(Waterfall)、軟體工匠技藝(software craftsmanship，也稱為戳屁屁"XP-Lite")，還是任何其他阻礙干擾程式設計的一切事物，夠了夠了，草泥馬的咧。

我們真的受夠了，我們被認定是孤僻且以自我為中心的蠢蛋白痴，說我們必須被加以操控，必須被束縛在強迫配對(Forced Pair Programming)的模式下工作，而沒有一滴滴的時間可以發揮創意創造力，因為，專案裡的那10位經理，沒有一個能夠做...程式設計，賽羚羊咧。

我們必須摧毀這些妨礙程式設計工作的方法學，草枝擺啦。

我們的價值

他們宣稱會衡量的價值	他們實際上衡量的價值	我們真正要幹的
個體能力以及與他人的交流分工	許許多多可換算成薪資的工作時數	程式設計，趕羚羊啦
能跑能用的軟體	可用的單元測試(unit tests)	程式設計，趕羚羊啦
與客戶間的協力合作	把客戶榨到乾	程式設計，趕羚羊啦
對需求變更的回應能力	不穩定性與貌似老實卻有推諉不知情的能力	程式設計，趕羚羊啦

我們認為，左邊那排米田共，其實就是把中間那排反過來看，而我們真正需要做的是在右邊那排...程式設計，法克魷。

簽名：
Zed A. Shaw與會趕羚羊的程式赦祭屍。

變成一位程式色妓蝨獅然後趕羚羊吧

如果你不會但想學寫程式，那麼，我大力推薦我寫的書Learn Python The Hard Way，寫的真是太好了，不論你的程度高低，任何人都可以讀一讀，至少可以學會了解趕羚羊...ㄟ...程式設計的基本功夫，贛林老母啦。

寫程式取名稱令人抓狂啊

2011-03-28T14:10:00.000+08:00

在Reddit Programming上看到一個連結，OpenBSD shutdown.c, line 93，一看，笑死我了啦，哈哈哈。

1.34 cloder 93: void __dead die_you_gravy_sucking_pig_dog(void);

哇哩咧，這是什麼東東啊，左思右想就是不了解這個函式到底有啥用途？惡作劇？亂搞？開發人員發瘋了？精神異常？還是想不出好名稱了？

命名真的是一件很難的事情啊，取的不好的話心裡就會有個疙瘩在，取的好就神清氣爽，譬如有人把null terminated pascal strings以fucked strings稱呼之，真是妙啊，哈哈。有個叫做匈牙利命名法(Hungarian naming convention) 的規則，可以參考參考，不過根據Joel的說法，大家都誤解誤用這套規則了。

回到上面那個函式的命名，我想，應該跟命名學沒什麼關係，而是壓力太大的惡搞結果吧。

花札（花牌、花鬪）

2011-01-16T23:36:00.001+08:00

花札，源於日本的一種傳統紙牌遊戲，隨著歷史演進與賭博的閉鎖性，有很多種版本與地區規則，不過大多已經失傳，目前一般的花札都是所謂的「八八花」，卡片上畫有12個月份的花草，每種各4張，整組48張。

底下這張圖是花札的牌。

兩人玩時，就像上面這張圖，手上分發八張，桌面開八張，然後輪流出一張牌，如果牌的月份相同，就可以吃下來，譬如上面這張圖，我可以出鹿那一張，桌面上也有楓葉，是同月份的，就可以取回，然後翻開一張牌，同樣如果有同月份的就可以取回。

當你收集到一定的組合，就可以結束此局，拿下點數，或是你覺得還可以收集到更多的牌，可以喊koi-koi（こいこい），表示繼續，但萬一此時對方收集到小點數的牌型結束回合，那你就欲哭無淚了。這就好像玩麻將，想作大牌胡高台數，卻被別人屁胡，哎呀。

「五光」，五光牌有五張，松上鶴、櫻上幕簾、芒上月、柳間小野道風、桐上鳳凰。湊到這五張的話，就可以叫對方脫褲子了。這也是電影夏日大作戰裡女主角在最終打敗愛的機器的牌。

「四光」，除了柳間小野道風外，收集其他四張五光牌。
「雨四光」，包含柳間小野道風加三張五光牌。
「三光」，除了柳間小野道風外，收集三張五光牌。
「豬鹿蝶」，顧名思義，收集萩間豬、楓間鹿、牡丹上蝴蝶。

另外還有其他的規則，點數算法也各異，還請參考維基百科。

其實玩法很簡單，我在這邊不多說，可以參考底下的文章，或是直接玩玩吧！這裡跟這裡都可以線上玩花札喔。

參考文章：
1. 日本花札牌 -- Hanafuda
2. [桌遊開箱] 任天堂花札大統領
3. 【收藏】任天堂花札
4. 日本花札打法图文说明指南+心得技巧（fate花札道中记应景帖）
5. 花札遊戲列表
6. 遊戲介紹--日本花札牌

我的Mac軟體安裝列表 Snow Leopard

2011-01-14T22:40:00.003+08:00

之前寫了一篇我的Mac軟體安裝列表 Leopard，最近把Mac OS X升級為10.6 Snow Leopard（我當初還以為MacBook White不能升級咧），所以更新一下這份清單。

即時通訊：
Adium：多合一的即時通訊軟體，包括MSN、Yahoo Messenger、Google Talk、AOL、ICQ、Facebook Chat、QQ等等。
Skype：就是...Skype。

影片播放：
QuickTime、Windows Media Player、VLC、MPlayer、RealPlayer：播放程式
Flip4Mac、Perian：codec解碼器。

網路連線：
Firefox：瀏覽器，哇賽，10.6啟動firefox的速度超快的。外掛寫在另外一篇。
Chrome：瀏覽器，看YouTube與使用其他google的服務效能會比較好。
AlienBBS、Nally、Welly：打逼逼，個人偏好Welly。
aMule：不過我都用桌機Windows執行P2P啦。
Transmission：BitTorrent。
BwanaDik：快速查閱IP與連線狀態，會在狀態列放上一個小圖示。
RealVnc：遠端遙控。
FileZilla：ftp client，也支援SSL/TLS。

網路相簿：
Picasa Web Albums Exporter: iPhoto的外掛, 從iPhoto輸出照片上傳到Picasa Web Albums上.
Picasa Web Albums Uploader: 獨立的程式, 上傳照片到Picasa Web Albums上.
(上面兩個是包在同一個檔一起的)
Picasa for Mac: 太好了，Picasa有mac版了。

系統類：
香草輸入法OpenVanilla：輸入法。
Yahoo!奇摩輸入法：因為在Windows上也是用這個，所以mac上也改用這個。
OnyX：提供更多的設定項目。
Quicksilver、Butler：自訂快速鍵，還有很多其他增加操作性的功能。
macfuse、NTFS-3G：讓mac可以讀寫NTFS檔案系統（原本只能讀）。安裝方法請看這篇。
Growl：是個訊息通知機制，其他軟體（譬如Adium、Firefox、等等）會用這個機制發送訊息。

工具類:
Adobe Reader：看pdf檔。
Skim：看pdf檔，能夠加註解、編輯書籤。
Chmox：看chm檔。
DOSBox：模擬dos，打骨灰遊戲用。
CocoViewX: 看圖的，不過我都用iPhoto or Picasa來看圖了，或是只用quick look。
Xee：小巧的看圖軟體。
Alarm Clock：鬧鐘。
iTerm：終端機模擬程式，其實Mac OS X內建的終端機(Terminal.app)就滿不錯的，不過這套可以輕易地修改色彩配置。

壓縮解壓縮：
zip：mac內建。
Keka：壓縮格式7z、Zip、Tar、Gzip、Bzip2，解壓縮格式RAR、7z、Lzma、Zip、Tar、Gzip、Bzip2、ISO、EXE、CAB、PAX、ACE (PPC)。
Stuffit Expander：sit、stix，不過我已經很久沒遇見這種格式了。
UnRarX：rar，被Keka取代了。

燒錄：
Toast：專業燒錄軟體，商業軟體。
Burn：功能稍少的燒錄軟體，Freeware。

Dashboard widget：
Starry Night Widget：看星空的好東西.

Pemdas：功能齊全的計算機。
Weather：看天氣。

其他還有很多好用的widget，看你喜歡什麼就裝什麼囉。

執行Windows：
Boot Camp，讓你的Mac可以同時擁有Mac OS X與Windows兩套OS，在開機時選擇切換；蘋果推出這個玩意實在是明智之舉，可以切換回Windows會減低很多人跨進Mac世界的門檻，我就是。
Parallels Desktop for Mac，更棒，在Mac OS X內模擬執行Windows，不用重開機，要錢。
VirtualBox，同上，更棒，而且不用錢。

軟體開發（寫程式）：
TextMate：程式員用的編輯器。
Xcode：mac與iphone軟體的開發環境。
0xED：十六進位編輯器。
？：比較檔案內容，我想用Beyond Compare啊。有人可以推薦一下mac上的檔案比較軟體嗎。
Git for OS X：git版本控管。

沒繼續用的軟體：
Thunderbird：email軟體，可是我覺得過濾廣告信的功能不夠強。
Safari：Apple出的瀏覽器。

相關文章：
[ Mac ] OS X 上一些實用的免費軟體
Mac OSX 的軟體列表筆記

你是不是覺得某個軟體超棒一定要用沒有不行呢？可以留言告訴我喔。

git and Beyond Compare 3 on Windows XP + Cygwin

2010-12-30T17:44:00.000+08:00

這篇記錄一下我git的設定，使用Beyond Compare 3來做為git的diff與merge時的工具。我的電腦是Windows XP，我用的是Cygwin裡的git，不是msysgit。

修改每個repository裡的.git/config或是家目錄裡面的~/.gitconfig。

[diff]
    tool = bc3
[difftool]
    prompt = false
[difftool "bc3"]
    cmd = \"c:/program files/beyond compare 3/bcomp.exe\" "$(cygpath -w $LOCAL)" "$REMOTE"
[merge]
    tool = bc3
[mergetool]
    prompt = false
[mergetool "bc3"]
    #trustExitCode = true
    cmd = \"c:/program files/beyond compare 3/bcomp.exe\" "$LOCAL" "$REMOTE" "$BASE" "$MERGED"

裡面用了cygpath把cygwin下的路徑$LOCAL（類似/tmp/U5VvP1_abc這種東西）轉成windows的路徑，因為bc3是個windows下的軟體。

然後，可以用git difftool來比較檔案，git mergetool來做整合。

關於truExitCode的意思是，若外部工具的exit code可以代表檔案整合的成功與否，那麼就可以設為true，要不然，git mergetool會向使用者詢問整合是否成功。詳情請見說明文件。

翻譯：在家工作保持生產力的二十個方法（ Twenty Ways to Stay Productive When Working at Home） by Scott Young

2010-12-27T20:51:00.000+08:00

文章： Twenty Ways to Stay Productive When Working at Home（在家工作保持生產力的二十個方法）
日期：2007.05.23
作者：Scott Young
作者的部落格：Scott H Young's Get More from Life

在家工作保持生產力的二十個方法(Twenty Ways to Stay Productive When Working at Home)

自己在家工作，你怎麼保持生產力呢？很多在家工作的人雖然能享受著充分的自由與便利，不過，一旦身處工作環境之外，很容易就心生懶散，在家工作擁有的彈性，有可能讓你變得非常非常有生產力，但，如果你不能善加利用的話，恐怕會白白浪費大把的時間。

由於經營這個部落格，加上其他專案計畫，我常常每週至少要花去20到30小時在家工作，除了上網、研究、其他相關支援任務外，每週需要回上百封信，每天至少要寫3000字，比起某些人應該算少的，但是，除了工作與學校外，這也足夠讓我忙個不停了。

底下是我發現的一些策略，當在家工作時，可以有效地保持生產力，這些方法，不論你是接案子、自由工作者、在家創業、或是你想進行某個人計畫，都一體適用。

1. 建立工作規範──在辦公室裡工作會強迫產生出紀律，沒有系統與規定，沒有上司在你脖子背後吹氣監督的話，你很難堅定地遵守計畫時程表，在腦海裡記著你的生產力與工作規範，並設定提昇目標，若昨天只有4小時，今天就以4.5為目標。

2. 不要高估你的生產力──當人們開始在家工作，都會說這樣的一句謊言，以為生產力會提昇，以為有8小時可以做事，就假設能完成8小時的事情，醒醒吧，變得真的有生產力是可能的，但這需要建立起工作規範，先從小處小範圍著手，然後漸漸往上發展。

3. 不要把低價值的任務算進去──分辨出哪些比較重要，先算這些，我常聽到在家創業的人說他們每天工作10-12小時，可是，我看到他們上論壇發表文章以及寫落落長的郵件，令人不禁想問，這些算是工作內容嗎？只算那些極端重要的工作項目與艱難的任務，那才算數才準確。我花一小時寫部落格文章，或是寫出好幾頁的新書，都比花數小時回信件有價值多了。

4. 隔離會分心的事物──把自己放進真空的環境裡，盡最大努力降低會造成精神散亂的可能性，我一定會把門關上鎖上，而且不會使用網路，除非需要找段句子或圖片，絕對要跟微博、聊天室、電子郵件與RSS說不，我知道這些東西的吸引力有多大，可是，如果能不要切來換去的話，你就可能以兩倍速度完成工作，省下時間之後再來使用這些軟體。

5. 早一點開始──早一點起床在早上開始工作，是個不錯的主意，這使得你沒有機會拖拖拉拉的，還有，若是在2:00或3:00就完成8小時的工作，你會有好爽的感覺唷。

6. 知道你的能量限度──了解你何時會開始覺得勞累與精疲力盡，我自己的準則很簡單，當注意到我的能量值下降了，很難張開眼皮，我就會休息十分鐘（有時候昏昏欲睡就是創造力的最大障礙），如果這樣還不行的話，我會來個5-10分鐘的小憩，最後還不行的話，那可能需要長一點的運動了。

7. 學會說不──在家工作擁有很高的時間彈性，你的朋友、家人、跟其他夥伴就會有很棒的機會可以佔用掉花去你的時間，有時候他們會讓你覺得內疚，因為，“他們（不像你）必須去上班”，但請堅定立場別給他們有寸進的空間，別讓他們不尊重你的時間分配，學著說“不”，無需多做解釋。

8. 設定每日目標──我不會把不必要的工作事項排進時程表，但我會把明天結束時應該要達成的目標確實地寫下來，藉由設定每天要達成的目標，把工作量分成一份份可管理的區塊，你就不會感覺要一次完成所有的事情。

9. 使用帊金森定律──這個定律基本上是說，你給一件任務多少時間，它就會擴展成需要那麼多時間的任務，當完成比完美重要時，自己給自己幾分鐘的時間，把工作做完，確實地解決一定的工作量。

10. 學會把東西擠出來──當你身為作家/程式設計師/設計師，卡住時怎麼辦，學會把東西生出來擠出來，也就是說，當沒有點子創意時，你告訴你自己，這時候的目標是量而非質，告訴自己說，如果真的弄的太糟糕了，之後會再做一次，不過真相事實通常會是，質已經夠好了，亂擠亂搞幾分鐘後，你就會回復到常態。

11. 建立起專業的工作空間──身處的環境應該要讓你感覺到在工作，如果不是的話，該是時候重新裝飾一下了，不用很精美，但是，如果在家工作只讓你覺得是在玩電腦遊戲的話，請把擺設佈置換一換吧。

12. 設定工作時數──別把工作跟生活混在一起，設定該有的工作時數，工作時認真地把生產力提升到最大值，並把工作留在那些時間裡，我常常設定含糊不清的工作時間，但只會讓我變成毫無生產力的工作狂而已。

13. 你的MIT是什麼？──隨時都要清楚你的最重要的任務(Most Important Task, MIT)是哪些，ZenHabits的Leo建議把MIT放在最前面，這樣你才不會延遲耽擱，即使一天之後的時間毫無作為，這一天仍然是有價值了，因為你把最重要的完成了。

14. 有社交的生活──在家工作往往會排除掉一堆社交活動，參加團體與活動，譬如祝酒或宴會主持人，這會比較容易認識新朋友，找回在辦公室裡上班裡才有的那種社交網路，沒有朋友，你就不會有活力，我曾一直試著絕世獨立自己埋頭苦幹，不過我認為那是不切實際的。

15. 變更任務的種類──如果你到健身房，你會一整個小時只做伏地挺身嗎？應該不會吧，所以，如果你是個作家或程式設計師，你會十個小時連續不斷地寫寫寫嗎？我喜歡把不一樣的工作項目分散到一天的不同時段裡，這樣我才能使用大腦裡不同部分的“肌肉”，這讓我保持新鮮感有活力，保持生產力，而不需要長時間的中斷休息。

16. 直到厭煩才能跳脫工作──當記事板上沒有我想寫的點子時，我常常會經歷一段5或10分鐘的時間，什麼事情也沒做，但最後會得到新靈感，如果這也發生在你身上，請抗拒上網作其他事情的誘惑，再堅持10或15分鐘，即使你能推遲工作時間。

17. 取得外界觀點──當你是自己孤立一人時，你往往會限於一種視野，不利於解決手上的問題，建立起一套人際網路（特別是線上的），當你撞牆時可以有人詢問，我認識好幾個朋友，當我的解法太差時，可以有他們來回激發創意。

18. 讓你超時工作──如果你真的沉浸在專案中，多做個一小時把今天的東西收拾收拾，這是可以的，次日給自己補償一下，少一些工作量，這樣你才不會開始一睜開眼睛就是工作，直到睡覺。

19. 再多15──當你卡住時，或是很想很想丟下筆時，告訴自己，再多作個15分鐘就好，通常這就足夠讓你拔出泥沼繼續往前，如果不能，那你就需要休息了。

20. 善用時間彈性──好好利用你在家工作所享有的彈性，這表示，你可以根據新的機運修改工作時程表，或是配合生活調整工作腳步，當有好機會來臨時，拿下它並保證在之後會補償自己，這需要多一點的紀律，但這是在家工作最大的優點之一。

我的FireFox附加元件列表

2010-12-11T13:56:00.003+08:00

記錄一下我用的FireFox附加元件（外掛、addons）。

Adblock Plus：擋廣告。
Element Hiding Helper for Adblock Plus：輔助Adblock Plus的，可以更精準地選出網頁上的某一部分，然後擋掉。

Download Statusbar：在狀態列上看下載進度，功能雖小但必裝。
DownThemAll!：多線程續傳下載，需要同時進行大量下載時用的，下載大檔用的，因為有續傳功能。

Xmarks 書籤同步套件：讓兩台電腦的FireFox書籤同步更新。不僅firefox可用，還支援chrome、safari、ie。

Gmail Notifier：在右下角的狀態列增加一個gmail圖示，顯示並定期檢查有無新信件。前一陣子開始故障不能用，所以我改用Gmail Manager。
Gmail Manager：在右下角的狀態列增加一個gmail圖示，顯示並定期檢查有無新信件，可以設定很多個gmail帳號。對我來說，基本上跟Gmail Notifier差不多但功能強一點。最近故障了，聽說作者不再更新了，所以改用Gmail Watcher。
Gmail Watcher：在右下角的狀態列增加一個gmail圖示，顯示並定期檢查有無新信件。

Tab Mix Plus：強化各種分頁功能，例如，滑鼠停在分頁標籤上就切換顯示該分頁，開啟分頁時要怎麼排放，關閉分頁後要跳回哪一個分頁，等等，非常多的設定。
FireGestures：用滑鼠畫手勢操控瀏覽，例如回到上一頁、關閉分頁、開新分頁、重新載入剛剛關閉的分頁、等等。
Easy DragToGo：文字、鏈結、圖片，用滑鼠時，不同拖曳方向你可以設定不同功能，譬如，圈選一段文字，然後用滑鼠往上拖代表用google搜尋並且另開分頁，往下拖代表用google搜尋但是直接顯示在原本分夜裡，譬如，在圖片上用滑鼠往左拖代表直接儲存圖片到特定資料夾，等等。

Brief：訂閱RSS、Atom等feed，隨時得知最新消息。用起來很簡單，很棒。
ScrapBook：將完整的網頁擷取下來，也可以畫線圈重點，其資料很容易地可以傳到windows的firefox，反之亦然。

IE Tab：在Windows上要裝的，有些網站只能用IE開，我FireFox升級後就不能用了，我改用IE Tab Plus。
IE Tab Plus (FF 3.6+)：在Windows上要裝的，有些網站只能用IE開。

1-Click YouTube Video Download：專門下載YouTube的影片，會直接在網頁上顯示"FLV MP4 3GP"，點了就可下載，因為我看的影片絕大部分都是在YouTube上，所以這個元件對我來說很方便，至於其他少數我會去的影片網站，都有提供下載連結，所以沒問題。
Video DownloadHelper：支援下載影片，很多網站都適用。以前有裝。

有些附加元件都有很強的競爭對手或取代品，譬如Tab Mix Plus有人嫌太笨重，上面這些只是我個人在使用的外掛清單，能符合我的需求，但並不一定適合你，除非有需要，我很少會改用別的，也很少會去玩新元件，如果你有什麼建議，還請留言。

幾個我常看的YouTube頻道，練習英文聽力。

2010-12-11T13:12:00.004+08:00

首先，Ray William Johnson，每一集的內容大概是，摘錄幾支點閱率很高的影片，做出評論（其實也不是評論，就是亂哈啦亂打屁而已），每一集差不多是5分鐘，大概一個禮拜會有兩集。

譬如說，當然啦，網路上的王道影片："貓"。這一集裡面有貓打架而不是去追旁邊的鴿子。

這一集，總之，生活太無聊了，有個女孩被朋友個塞進洗衣機（烘乾機？）裡。

每一集在最後面，會開放大家提個問題（譬如What would your smurf name be），要用影片的方式提問題，然後其他人可以留言回答，他會剪輯一些好笑不錯的回答（譬如Eddie Smurfy、Chronic Masturbator Smurf）放在影片末段。

然後是雀斑妹，meekakitty，表情非常非常豐富，音調有高低起伏，喜歡打game，內容其實也沒什麼，就是一般的打屁哈啦，練練聽力囉。

這一集談到她很喜歡薩爾達。

這一集還cosplay星艦(Star Trek)的服裝。可惜她並沒有常常cosplay，不過有趣的t-shirt倒不少（話說回來，外國人有趣的t-shirt本來就不少）。

以前有提過的Marina Orlova(Hot For Words)，俄國口音，影片內容是講解英文單字的起源。

我們都知道，很久以前的事情有些都忘記了，但有一些不知道何，就是記在腦海裡，我想，那是因為伴隨著強烈的情緒。若有個美女老師，這應該可以增強你的記憶情緒吧。

不過呢，我不太喜歡她最近的短髮造型，orz。

蘋果迷，iJustine。很搞怪。

譬如說，在蘋果的店面裡面跳舞！

譬如說，在路上騎著一輛小小的兒童車。

另外，也可以看各大學的上課錄影，譬如Berkeley、Stanford、MIT等等。

另外，這兩個技術影音網站，InfoQ與Channel 9，也常有高品質的電腦資訊科技的演講錄影。

另外，Khan Academy，有很多科學數學的課程教學影片。

還有，Google放上YouTube的演講錄影、技術研討。

最近這一支，裡面有各個國家的口音，真的很難聽懂啊...orz，被打敗了。

大概就是這些了，還請留言告訴我你喜歡的頻道。

翻譯：這不是物件導向程式設計啦（What OOP Isn't ）by Benjamin Supnik

2010-12-11T11:46:00.002+08:00

文章：What OOP Isn't（這不是物件導向程式設計啦）
日期：2010.12.09
作者：Benjamin Supnik
作者的部落格：The Hacks of Life

這不是物件導向程式設計啦(What OOP Isn't)

想當初，我開始上第一堂的電腦科學課程（不過在那以前，我已經自己開始寫程式有一段時間了），系上教職員正在打一場內戰，某部分人信仰著物件導向程式設計(object-oriented programming, OOP)，他們相信世間萬物皆物件，物件就是王道啊，他們教授要我們學生用OOP的方式來實作鏈結串列(linked list)：哇賽，每一個節點都是被完完全全封裝起來的物件！

（什麼，你有興趣知道嗎，讓我告訴你，串列大部分的編輯動作，都必須是堆疊-遞迴式(stack-recursive)──當呼叫一個節點的next時，節點要把它的'next'設定為呼叫的回傳值，讓某節點能夠'把自己切掉'。嘿嘿，聽的懂算你強，這讓那些從沒碰過鏈結串列的學生，一個頭兩個大，根本不知道到底自己在幹嘛，因為，他們在同一個時間，碰到了遞迴與鏈結串列，而寫出來的程式，結果是，執行起來有著LISP的效能，而程式碼看起來像C++的優雅，真是糟糕可怕啊。）

他們說，OOP的三大支柱是封裝、多型、繼承(encapsulation, polymorphism, inheritance)，我以前已經發表文章說過為什麼最後一項通常會是個不好的概念，回想那時在學校的時光，我還沒有足夠的程式開發經驗，所以只能說，當時我們被教的東西（全部都是OOP，不論何時何地）比我一直以來在寫的程式（用物件來表示某種很大的東西，例如遊戲裡的一個角色）要難上好幾倍，寫出來的程式碼，又囉嗦也沒有特別快，現在，我有了軟體工程的經驗，我想，可以把其中問題所在更精確地描述出來。

有時，看到程式新手眼裡閃著OOP字眼，努力學會這到底在講些什麼，我會跟他們說，封裝、多型、繼承的相對重要程度大概是90%、10%、0%，OOP絕大部分的價值所在，是它提供機制與作法，可以把一段程式碼跟其他不相干的程式碼分離開來，而不會混雜在一起，而這點對大型軟體開發專案很重要，而你不可能教會大學生這一點，因為他們還沒有夠多的程式開發經驗，無法體會其中的重要性。

多型也不錯，但據我的經驗，它不像封裝那麼有用，如果你有個多型介面，有個介面就表示，它是被封裝的，但是，有許多的案例顯示，有些介面就只會用一次，而且沒有多型這項性質，粗略來講大概是90%-10%吧，所以我認為扮演舉足輕重角色的是封裝。當然，有些產品與領域比其他地方更常使用多型，WorldEditor（Laminar Research的開放原始碼場景編輯器）大部分的核心元件採用多型介面的架構，但X-Plane本身就很少。

我提出這點，因為我大概（在以後的發表文章中）會把OOP與其他技術（與軟體工程碰到的實質困難有關的）作個比較，不過OOP有一點歷史包袱，過去常常講，OOP可以讓我們變成更好的程式設計師，可以幫助我們寫出無臭蟲的程式碼，執行速度更快了，或是可以幫助差勁的程式設計人員升級成優良的，這些都被時間證明了，只不過是些天真白痴一廂情願的想法（特別是，差的程式設計師，不論給予什麼樣的技術或方法，照樣可以生產出低劣的程式碼，一大沱）。

所以，我希望幫OOP這玩意作類似如下的定義：在語言上提供好的支援來進行封裝，有時候需要有多型介面，加速撰碼。這對我來說就非常好用了！我可以僅用純C語言寫出相同的東西，但不僅需要花更多時間打字，還會讓我變成很嘮叨的人，不斷囉囉唆唆血壓上升，何苦呢？

讀後介紹：情感行銷的符碼(The Culture Code) by 克勞泰爾·拉派爾

2010-11-07T14:35:00.000+08:00

書名：情感行銷的符碼(The Culture Code)──消費生活文化
作者：克勞泰爾·拉派爾(Clotaire Rapaille)
譯者：馮克芸

人常常口是心非，有時出於刻意，有時出於不自覺；人常常話中有話，有時礙於語言的貧乏而無法正確表達心意，有時巧妙地以話術包裹上糖衣或詼諧或高深莫測；男人常常說謊，有時是因為現實的需求，有時是因為這個世界就是一個大謊言；女人常常說謊，有時是因為太理想太夢幻，有時是因為真話難為假話通行四海。

好像有一點點離題，讓我們回頭檢視一下作者在這本書裡討論的主題。這本書是作者在三十多年來為世界各大公司破譯顧客心理想些什麼的經驗總談，設法了解人們自己都不知道的行事原由，你不能只是聽顧客說，你要從文化視野找出烙印在內心深處大腦底層的銘記，那會強烈影響思考過程與未來行動的烙印，所以要了解人們真正的意思的第一步就是忽略他們所說的話。

這並非暗示人們有意說謊，而是一般人會用腦中控制智能的部份想像發問者想聽些什麼話，然後提出對方想要的答案，但實際做決定行動時，用的是帶有強烈情緒的經驗做判斷，從小到大的經歷以及文化加諸其上的情感連結，才是真正左右行事的準則。

每個文化都是不同的，所以光一套絕對不可能吃遍全世界，我一點都不愛吃起司但法國人愛死了，德國與美國的“工程”其涵意就不同，你在日本跟歐洲賣咖啡的策略絕對有很大的差異，酒、性、肥胖、美麗、青春、家庭等等，每個文化都有不同的銘記，每個國家從其他國家文化看來也都不同。想賣東西，先了解該國文化吧。

書中說，人腦分成三部分，腦皮質負責學習、思考、想像，邊緣系統負責情緒，還有爬蟲類腦負責生存以及繁衍，猜猜哪部分最具影響力？

作者用這樣的角度在書中討論各種事情，晚餐、工作、食物、品質、逛街、美國、健康等等，了解我們每一行動所背負的意義，將讓我們獲得極大的自由。

翻譯：皮諾丘難題（The Pinocchio Problem）by Steve Yegge

2010-10-17T17:50:00.000+08:00

文章：The Pinocchio Problem 皮諾丘難題
日期：2007.01.17
作者：Steve Yegge
作者的部落格（2006至今）：Stevey's Blog Rants
作者舊的文章（2004與2005）：Stevey's Drunken Blog Rants

作者簡介：
目前任職於Google，之前任職於Geoworks與Amazon。程式語言生涯中有過兩次非常關鍵性的轉換，一次是組合語言，一次是Java 跟Perl，因為發現解決語言本身設計帶來的問題所花的時間，竟然比真正用在開發軟體系統的時間還多。其文章以長度聞名，長到應該稱為論文而非部落格，兼帶詼諧筆風，發表頻率大約一個月一到兩篇，作者總是說這些是在凌晨三罐啤酒下肚後的誇誇其談，但每一篇都是經過長時間醞釀，內容充實有見地的傑作。
獨立以Java/JPyton開發多人線上遊戲Wyvern，可讓玩家自行創建擴充遊戲內容。其工作團隊將Rails移植到Rhino上，Rhino是運作於JVM平台上的JavaScript引擎，Rails(Ruby on Rails)為一套受到廣泛喜愛使用的網站開發模組；為Emacs撰寫完整的JavaScript環境，期望在Emacs上可以有一套 JavaScript IDE，以及將來可用JavaScript而非elisp來開發Emacs extensions。

皮諾丘難題（The Pinocchio Problem）

過去一年來，我將自己每月花在寫部落格的時間限定在四小時左右，通常我會有很多主題可以寫、很多東西可以討論，選一個出來並不會太難，但上個月在我腦袋裡只有一件事在打轉，我不斷在嘗試著用各種方式把它說出來，都快抓狂了──你知道的，用一種又好又簡潔的方式表達出來，讓讀者能夠把它嚥下去，可惜到目前為止都沒成功，我想那代表我還不真的懂這主題，或許試著寫下來可以幫我更了解。

這主題是關於軟體設計；你瞧，似乎有著某種好方法可以用來設計軟體，甚至有人認為存在著一種最好的方法，但沒人實際運用啊，嗯，或許一小撮人有，即使如此，我認為那些少數例子有一半僅是碰巧吧了。

斷斷續續地，這個題目我已經思考研究了很長一段時間，十八年的光陰過去了，而我依然不能清楚明確地說出……嗯，設計的原則，如果這是我們要的答案的話；但上個月，我覺得我好像又更靠近了一點，或許你可以幫我一下！我會告訴你我知道的，那你可以告訴我你知道的，或許我們可以合作出某種非凡的結果。

先為今天這篇設定一些背景，讓我用一個句子將所有我寫過的文章內容做總結：我認為大部分的軟體都是大便。嗯，好像不夠正確，更誠實地說，我認為所有軟體都是大便；耶，沒錯，你聽到了，Stevey一言以蔽之：軟體皆大便。

即使如此，我認為某些軟體系統確實比其他的好：某些大便生產者可能有吃過一些金幣，所以他們的大便看起來比較亮晶晶一點，偶爾有人吞下紅寶石，他們的大便就又好看又值錢，嗯，記得站遠一點看。但是，不論吃進了多少寶貴的石頭，大出米田共就還是米田共。

多麼可愛有趣的譬喻啊，對吧？我自己想的喔！

每想到我最喜歡的軟體系統時──像熟悉的老朋友們、像適合居住的福地──我看到它們都擁有某些特質，很快我就會告訴你是什麼特質，至少是那些我注意到的，別急，我保證不拖戲，但事情還沒結束；一旦你將這些特質加進一個軟體系統中，如果做的對的話，那麼通常你可以得到一套跟時下做得出來的好軟體一樣好。不過，仍只能算是大便而已。

在我開始思考若能脫離屎的層次來打造軟體系統時，真正的難題就開始浮現，這樣的思索引發出各種有趣的問題，而我一點頭緒也沒有，但我會把這些問題也丟出來，只要我還沒超過四小時的時間限制，還沒被生活瑣事招喚過去的話。

我喜愛的系統

在上個月左右的某個時刻我領悟到一個重點，那就是，我喜歡的軟體系統所共同擁有的那些特質都是由一個根本原因所衍生出來的：某單一特質、或稱為設計原則，軟體如果擁有這特質的話會自然而然地呈現出正確的特性。

哪些是我喜愛的軟體系統呢？以下列出最好的幾個：Unix、Windows XP、Mac OS/X、Emacs、Microsoft Excel、Firefox、Ruby on Rails、Python、Ruby、Scheme、Common Lisp、LP Muds、Java Virtual Machine。

有幾個差一點點的：Microsoft Word、OmniGraffle Pro、JavaScript、Perforce。

還有幾個應該可以排上去，但我因不夠熟悉而不敢亂說的系統：GIMP、Mathematica、VIM、Lua、Internet Explorer。

流行的軟體系統大部分都挨不上名次，雖然它們都相當有用，但是我認為缺少了理想軟體設計的本質，例如：IntelliJ、Eclipse、Visual Studio、Java、C++、Perl、Nethack、Microsoft PowerPoint，所有任天堂與PlayStation的遊戲，幾乎所有的電腦遊戲，除了著名的毀滅戰士(Doom)與雷神之鎚(Quake)，還有大部分的網站服務，包括那些很有用的Amazon.com或是Google Maps。

我就不賣關子了，我認為在所有的軟體設計理念之中，最最重要的原則是：系統毋須重新啟動。

如果你設計一套系統可以不需要重新啟動，那麼，你終將會，就算是以很迂迴的方式，終將實現出一套可永久存活的系統。

我上面列出的系統，仍需要偶爾重新啟動一下，也就是說，它們實際上的壽命會落在數十年到一百多年之間，其中有幾個才剛開始──大部分都在二十出頭跟三十出頭左右，少數幾個已經有四十年的資歷了，然而，它們還是離不朽不死的境界很遠很遠。

我心中第二最最重要的原則，實際上算是第一原則的推論，是一套系統必須能成長而毋須重新啟動；一套不能隨時間成長的系統是靜止的，其實不能算是一套系統，應該說是一支函式，它可能是支非常複雜的函式，可以接受很多不同的輸入與產生輸出，它可能是支非常有用的函式而且存活相當久的時間，但函式一定會被取代掉，或是被可成長的系統吸收掉；我現在相信，經過了將近二十年的思考研究，能夠成長改變而毋須重新啟動的系統可以永久地存活下去。

必備特質

下面列出目前世界上最優質軟體共有的幾點特性，我列出來的它們並非全都都有，我想只有少數幾套系統擁有我列出來的全部特點，你應該會發現，一套系統有的必要特質越多，就會越強大、更重要、活的更久。

注意：這些特點都是給程式設計師看的，芸芸使用者們在乎的功能跟一套系統的壽命無關；我相信適當的時刻一到，程式設計能力就會會變得跟識字能力一樣普遍，所以這不重要。

第一：偉大的軟體系統都有命令列模式(command shell)，這是系統不可或缺的部份，與系統同生同存，系統設計者無法想像沒了命令列模式的日子要怎麼過啊，命令列模式是完整的系統操控介面：任何你以其他方式操作系統完成的動作都可以透過命令列模式達成，光搞一套優秀的命令列模式本身就是一個大主題（大部分的必備特質都是這樣的，想想吧），我概略說一下：一套優秀的命令列模式一定會包含下命令的語言(command language)、互動式的查詢工具、腳本語言(scripting language)、擴充機制、命令歷史紀錄機能、以及命令列編輯器(command-line editor)，一套超棒的命令列模式就是一套好系統的最佳典範：可以比使用它的母系統存活更久並可以移棲到別套系統中。

所有現存的命令列模式都是大便，但它們是今日可以被打造出來的好軟體不可或缺的元件之一。

我們可以把Emacs想像成一套非常厲害的終極命令列模式：想想如果把命令列模式推到理論極限會是什麼樣的光景，或至少推到現今人們可以構思出來的境界。

最佳軟體系統共有的必備特質還有很多，命令列模式不是唯一一個，所以，讓我們繼續談下去。

偉大的系統還要包含“advice”，這項特質並沒有一個大家都同意的名稱，有時稱為hooks（掛勾）、或filters（篩檢器）、或aspect-oriented programming（剖面導向程式設計、面向側面的程式設計、觀點導向編程；譯註：這怎麼翻啊？）；就我所知，Lisp最早有這項特質，並以advice稱之；所謂的advice是一套小小的開發框架，在系統執行某動作或函式時，讓你以置入程式碼的方式，在動作之前、之中、之後插入你想要的功能，藉以改變系統的行為；每套advice系統都不一樣，它能夠介入的範圍越廣──意思是，它可以修改系統行為的範圍越大──那麼使用它的母系統功能就越強大。

Ruby on Rails有一套小小的advice系統，稱為“filters”，它（只）可以附加行為到controller actions中，所謂controllers actions是處理描繪頁面要求的特殊函式，你沒辦法在系統中的其他函式加上“之前、之後、之中”的filter，不過透過Ruby的metaprogramming機制可以在某種程度上做到；但一套advice系統不能僅是紙上談兵理論上沒問題，那是不夠的，advice必須從頭從底層融合進系統之中，以first-class形式、以有詳細文件說明的介面開放出來；advice非常強大有用，即使是Rails中簡單的action-filtering系統，都釋放出驚人的彈性；想想沒有它的話，要怎麼寫支Rails程式啊。

Emacs有套非常精密的advice系統；Common Lisp有一套可以說是世上最強大的advice系統，這支語言這麼強有很大的因素就是因為它；Aspect-Oriented Programming企圖在Java語言放進一套advice系統，野心很大，但因為Java的先天限制，必須以附加在語言外的擴充機制出現，有自己的編譯器與其他工具，這麼一來就大大阻礙了大家採用的意願，另外一個障礙物是，Java程序員偏愛撰寫死寂的軟體系統，任何能讓系統有生命的呼吸跡象都讓他們感到頭痛不已。

我要承認我也感到頭動，有生命的軟體聽起來有點嚇人，不意外，大部分的程式設計師都偏好開發牽線木偶而非真實的活人，掌控牽線木偶容易多了，但我認為有生命的軟體更加有趣也更有用些，坦白說這是無論如何都不能避免的趨勢，所以我們最好努力了解，對我而言，那就代表著實際動手建造一個出來。

讓我們繼續往下說，世界級的軟體系統都有套擴充語言(extension language)與外掛系統(plug-in system)──讓開發者可以延伸系統的基礎機能，有時候外掛(plug-in)又稱為“mods”，這是一種機制，讓使用者們以設計者不須參與的方式來擴充延伸系統的能力。

Microsoft Excel有一套絕佳的mod系統，這是一套令人激賞的開發框架，幾乎就等於是一套平台了，如同其他優質的mod系統一樣，它是一層一層的，從簡單Excel macros（Excel巨集），一直到完整的COM介面，可以被VB甚至是Python或Ruby驅動，只要那語言有COM bindings的話。

讓毀滅戰士(Doom)與雷神之鎚(Quake)這麼受歡迎的必殺特質之一就是它們的mod系統，毀滅戰士有一些基本的機制，以腳本驅動你建造的關卡、敵人、甚至是遊戲運行邏輯；雷神之鎚有QuakeC，仍然是，我認為啦，電腦遊戲腳本驅動語言的優良標準，不過我的資訊有點過時了，因為過去五年多來我都在玩電視遊樂器，很悲哀地，那些遊戲都死的不能再死了。

最強的外掛系統，強到能夠把整支應用軟體以plug-in的形式開發出來，這就是Emacs跟Eclipse的核心理念；先有一層很小的啟動層，可以看做是整個系統的硬體，系統其餘的部分，其所涵蓋的範圍（通常被效能因素限制住），都是由擴充語言寫出來的。

Firefox有套外掛系統，這真的是一套大便，但有總比沒有好；如果你有一套外掛系統，你很快就會發現，一定會有一些發狂的開發人員學習使用它並且榨乾它的能力直到極限，這會讓你誤以為你建構出來的外掛系統還不錯，但它應該要有容易使用跟毋須重起系統這兩項特性；Firefox打破了這兩項重要的規則，所以它的壽命處於一種不穩定的狀態下：要不然修正這兩項，要不然更好的系統會出現把大家都吸引過去。

真的讓我吃驚的是，連Firefox extension的開發人員都沒有特殊的管道跳過重新啟動這條災厄之路，他們的開發流程很痛苦，每有更動就必須手動重新安裝外掛（使用GUI操作方式），藉由某些技巧可以避掉大約一半的步驟，但整個開發社群對這點真的在皺眉表示不滿了！他們很明顯地感受到，如果使用者要經驗安裝外掛的痛苦一次，那外掛開發人員每當改一行程式碼就必須痛一次，每一次都在提醒他們：Firefox的外掛系統是沱大便，根本不能做事嘛。嘿嘿，真是有趣！

有位開發人員名叫Aaron Boodman送給了Firefox一塊瑰寶，這人現在在Google，那瑰寶就是GreaseMonkey，提供了另一種方式來寫Firefox extensions，不像Firefox的外掛系統，GreaseMonkey的extensions可以被安裝且更新，不需要重啟系統，而且相當容易撰寫，這瑰寶替Firefox注入了新動力，我打賭大部分的Firefox開發人員（先不管使用者社群）都能了解並感激GreaseMonkey的重要性，因為它讓Firefox能長期存活下去。

有趣的是，GreaseMonkey本身是個Firefox外掛，但又提供它自己的外掛系統，這是外掛系統中常見的一個模式：有些外掛會成長變大，變得可組態化，最後可被視為獨立的程式系統；Emacs有很多這種外掛：advice套件就是一個好例子。順帶一提，Rails的filter系統也是以系統外掛的形式實作出來的。外掛(plug-ins)，跟其他軟體系統一樣，也有生命週期，視乎它們納進多少我今天在談論的特質，它們最終都需要命令列模式、advice、擴充語言、等等，然而，外掛因為是立基於另一套系統之上，通常一開始就有這些東西。

打造可延伸擴充的系統比不能擴充的系統要更加困難，一般說來大約是三到五倍；在一開始就加入外掛系統比較容易，想在一套現存的系統上加進擴充能力，那可是夭壽困難的功夫啊，而且需要大規模地進行系統重構(refacotring)，可不是Java圈圈流行的那種小小可自動化的重構，其需要花費的心力幾乎就跟重寫整套系統差不多，不過以重構的方式進行的話，可以靠縝密完善的unit tests來減低改錯的風險。

現今有很多軟體系統都只能透過網路遠端存取，例如經由瀏覽器與HTTP，一些建造這種系統的大公司們，包括Yahoo!、Amazon.com跟eBay，都開始意識到提供給程序員的擴充延展能力是他們系統永續存活的關鍵，他們開始釋出內部系統的部分介面給外界使用，通常以web service的方式，這提供了某程度的擴充性：讓外界獨立軟體開發人員可以打造特別的介面來存取系統；隨著時間演進，我認為在網路服務這塊領域分高下的主要分水嶺將取決於供程序員存取系統的介面的品質高低。

外掛系統要考慮到安全性，要考慮到易用性，要考慮命名空間，要考慮元件相依性，要考慮向後相容的問題，要搞一套就已經是該死的難了，更別提要搞的好；外掛絕對是軟體系統想要永續存活所需要的特質。

優良的軟體系統還需要哪些特性呢？

我認為有點很重要，至少在今天來說，偉大的軟體系統都有或是需要一支殺手級應用程式，每套世界級的軟體系統本質上就是一個平台，如果你有命令列模式、擴充語言跟advice以及外掛架構，那麼你有的就是平台的組成要素了，但你需要某理由來說服使用者們使用你的平台；所以，GIMP打出影像編輯這賣點，Eclipse是撰寫Java程式碼，Emacs是一般文字的編輯器，Rails是建造網站服務，Firefox是瀏覽網頁用的，Python是腳本語言用來驅動其他東西，Lua可用在嵌入式環境，Mathematica是數學運算，等等，它們也都可以被延展應用到其他領域，但它們在其利基領域中是最強的。

最泛用的軟體系統，我認為，是作業系統跟程式語言，即使如此，它們也都有個主要的領域，作業系統主要用於資源管理，大部分成功的程式語言通常都切割出一塊利基市場加以佔據：需要速度就用C++，做Unix系統管理時可用Perl，要用很肥大的API來嚇嚇客戶的話可以用Java，瀏覽器上幾乎都只能選用JavaScript，在Emacs上就只能用Lisp，還有，Ruby開始爆紅要歸功於Rails。

所以軟體系統要有個利基點。或許將來有一天，有套超級泛用的軟體系統，超級強大、設計超良好，以至於任何事情都適合用它來完成；或許會有那麼一天吧，或許你就是打造這套系統的人。

接下來是今天我要講的重要特質的最後一項，跟其他項一樣重要，就是優良的軟體系統是能夠自我檢視有內省能力(introspective)，你可以在執行時到處戳戳看檢視系統的狀態，理想情況是由系統自己戳自己、自己檢視自己，至少要做基本的狀態監視，即使是一個已經有一堆靜態檢查的小小系統，你仍然需要監控，例如輸入與輸出佇列，對大系統來說，你什麼東西都需要做監控，包括監控系統本身。（若是不做這種監控系統的監控，可能會發生一件糟糕的事情，你的系統進入某種狀態，所有狀態檢查都OK，但系統實際上已經在擺爛了。）

內省機制(introspection) 可以（且應該）有各種不同的形式，不僅是狀態監控，系統管理工具與診斷工具也是一種內省，一步步除錯追蹤也是，效能分析也是，動態連結也是：系統必須能夠（舉例而言）執行bytecode verifiers以確保剛載入的程式碼能通過一些基本的安全性檢查。內省機制通常會降低效能，所以很多程序員不會在執行時做任何的內省檢測，或是極簡化地採用底層系統提供的內省機制（例，RTTI或Java的reflection），如果你用內省機制來換取速度，等於折掉你軟體數年甚至數十年的壽命，如果你是個顧問公司，或是你只想要讓系統可運作後就不管了，那麼或許這點不是太重要，但我認為大部分寫軟體人的都偏好在能長久永存的系統上做開發。

優質軟體共有的特質還有一長串可寫，但行文至此，我想最好談一下為什麼這些特質都根源於“毋須重新啟動”，之後遇到其他特質你就可以輕易地辨識出。

重新啟動等於死亡

今天我沒辦法很公平地談這個主題，部分原因是這個題目很大，部分原因是我還沒通徹搞懂，所以我最多只能把輪廓描繪出來，希望你能看出這問題完整的面貌。

首先，讓我們從比較哲學的觀點來看看，我用一種很廣義的觀點來看待軟體：大部分的軟體都不是人類創造的，那些人造的都是些大便，有很多相當棒的自然存在的軟體，例如人類大腦的運作，其大部分可以被看做是軟體，還有我們身體的組成運作很明確地是軟體。（見鬼了，我們甚至可以在DNA中看見組合語言指令碼，雖然還沒被完全解碼。）所以人們至少帶著兩套軟體系統：肉體與心靈。

我也認為穩定的生態系統也算是軟體系統，喔，順帶一提，穩定的政府也算，還有，人群組成的組織也是，例如你的公司；除非我整個誤解涂林的觀點，要不然軟體可以是任何能做運算的東西，而計算只需要一台有著幾個簡單機制的機器，這些機制是用來改變機器的狀態，包括條件式分支、跳躍指令、讀寫狀態、加上一組指令（程式）來指示該做哪些動作。

我假設我在這給軟體下的定義，是相當清楚且不證自明的，所以，關於軟體並非皆人造這觀點，我就不用再多做解釋辯護了。

所以，我的第一個反對重新啟動的論點是，在自然界中可沒這回事，或更精準地說，真的發生的話後果都很悲慘；如果你不喜歡一個人的所作所為，你不能殺掉他們、修正DNA、然後從小孩再成長一次；如果你不喜歡政府，你不能說關就關、找出錯在哪、然後重新開始，那麼，為什麼我們幾乎都用這種方式開發軟體呢？

反對重新啟動的下一個論點，看看現在開發人員建造的過時舊軟體，把你寫程式時戴的眼鏡拿下來，以一般使用者的角度想想重新啟動這回事，你喜歡被迫使重新啟動軟體嗎？當然不囉，多不方便啊。

大約十年前，微軟下了個決定要把Windows NT中需要重開機的地方都修改掉，你還記得嗎？我從未在微軟工作過，也是輾轉得知這故事，所以我不是確切了解事情始末，聽說那時每個小小的組態改變都需要系統重開機，好像是某個高層忍不下去了，然後他就組織統整了很多人力來修改程式，當我聽到這軼聞時，已經減少到大約剩下五個地方需要重開機；想想這對美國財政的衝擊吧──數以百萬的人們每天省下5到30分鐘的時間等待Windows重開機，很巨大的影響對吧，如果他們能夠將藍天白雲死機畫面也改好，那這就是一套相當棒的軟體，對吧？

Linux在這方面也經歷了不少成長的苦痛，終於開始越來越好，但我猜今時今日它需要重開機的次數仍然比Windows還要多。

不論如何，重新啟動這問題不僅僅是帶來不便而已，應該還有更深的意涵，從一個比較激進但仍可加以辯護的觀點看來，一次重新啟動就等於一件謀殺案。

怎麼會呢？嗯，古今中外尚未解決的難題之一是關於意識(consciousness)的問題：這是個啥玩意？有意識代表著什麼？到底什麼叫做自我察覺(self-aware)？寵物有意識嗎？昆蟲呢？捕蠅草呢？分界線要畫在哪裡呢？

歷史上各個時代，關於意識的問題有時流行有時不流行，不過在過去數十年間這是個非常風行的話題，哲學家跟認知科學家正攜手合作試著找出解答，據我所知，主流的觀點（或是叫領先的理論，什麼都好啦）是這麼說的：意識是遞迴式的自我察覺與認知，而且是漸層式的（對比於簡單的開與關），很明顯的是一種的函數，複雜度視乎可以處理多少輸入以及大腦可以同時處理的自我察覺之遞迴階層的多寡而定。所以，寵物是有意識的，只不過不像人類那樣。至少這是我從過去三十多年所出版的書籍、研究報告和論文，所得到的結論。

舉個例，我過去一直把我的狗──奇諾（一隻獅子犬）──當做一台非常簡單的狀態機：噓噓、拉屎、睡、吃、玩、花數小時舔鼻子，但每當我更進一步了解他，就逐漸辨識出更多的狀態，有數百個之多，甚至數千個，但我依然尚未完全被說服他的行為不是決定性的(deterministic)，我愛他愛到每一根毛我都愛，所以就假設他有懷疑的能力以及有自由意志(free will)吧，但不用太費心就可以有90%的準確率猜中他的行為；我想像這套用在我身上也同樣成立吧！

狗似乎比老鼠複雜多了，而老鼠應該比蟑螂複雜許多，一直循線追下去（或許是螞蟻？扁形蟲？單細胞有機體？），看起來到那時，動物的行為應該是具有完全可決定性的。

起初那說法對我很合理，但我現在的想法改了，我個人認為所有的生物都具有某些不可決定性(nondeterminism)，其程度視乎他們的組成因素中軟體的範圍有多廣，硬體部分肯定是可決定性的，奇諾在出生後任何不用教就會做的事情不是硬體就是軔體（一種內建的軟體，無法移除或更改），進行尿尿的程序（以及何時該去）、打噴嚏跟其他反射動作、處理感官資訊、消化食物、以及其他上千個程序通通都是直接編碼在他的大腦軔體或身體軔體中，可被精準地預測其行為，任何觀察到的差異處都是因為軟體部份對當前環境做出的修正。

換句話說，我認為意識與自由意志（也就是不可決定性nondeterminism）兩者皆為軟體性質。

沒人會為殺死一隻阿米巴變形蟲而掉眼淚，呃，大部分的人不會，同樣的，當你的程式印出“Hello, World!”後就離開main()並消失的無影無蹤，也不會有人會心情激動，但我想我們已經建立起一個共識，每一次執行“Hello, World!”程式就會產生出一段短短的意識活動。

呃…有幾分意味啦，一支“Hello, World!”，沒有迴圈也沒有分支，不具有任何不可決定性（除非由外界強加上去，例如一個亂數產生的硬體錯誤），所以你可以把它當做純硬體，只不過是用軟體程式寫出來，但在“Hello, World!”跟Hal 9000之間應該存在著一支擁有初步意識能力的軟體程式，若是這樣的話，把它關掉就等同於殺掉他一樣。

我們今日的軟體有那樣的複雜度嗎？夠複雜而且有足夠的自我感知能力，從倫理道德的觀點來看可以被認為具有意識嗎？答案大概是否定的，但我認為總有一天我們會達到那個地步，到那時，我真心希望我們不是用今日的方法在開發軟體，也就是編譯加上重新啟動的開發循環週期。

我想今日我們建造出來的軟體，大部分都像是在玩骨牌，這叫做骨牌設計法，你非常小心排著骨牌，只能跑一次，所有的骨牌都依照排好可預測的順序倒下，而且如果需要的話你將所有骨牌重新排一遍；最終結果可以比玩骨牌更精美更棒──想想玩具總動員裡面的一張一張畫面，本質上並沒有太大的差異，但的確更精美。

每一套真的很複雜的軟體，像是搜尋引擎或是電子商務系統，通常都是用骨牌設計法建構出來的，如果你主要以C++或Java寫程式，幾乎一定是用這種方法。

重新啟動一套骨牌系統是不可避免的動作，每有改變每次升級都需要重新啟動這樣的概念，跟這些系統在我們心中的形態緊緊相連，對我而言，我不喜歡骨牌，我個人想要跟一支變形蟲玩，而且如果他拒絕學習怎麼走迷宮或其他事物的話，我會把他壓扁然後發現得到新型阿米巴，不過在那之前我會先多想個兩次。

DWIM and QWAN

我的思考能力到現在已經有點模糊了，所以我盡量長話短說。DWIM是個可愛的頭字縮寫，我想是由Larry Wall發明的，意思是“Do What I Mean”，Perl社群常常使用這個字眼。

DWIM背後的概念是完美的軟體就好像一個從瓶子跑出來且滿懷感激讓你許願的精靈，我不是在說那些你對著噴泉或流星所許的不值錢願望，大家都知道你必須注意許願時的遣詞用字，因為許願精靈會以字面的意思給你要的，而不是你真正想要的，就好像所有你在使用的軟體一樣；相對的，DWIM精靈站在你這邊，可容忍文法或邏輯上的錯誤，不會得到錯誤的結果。（“一個男的走進酒吧，帶著迷你鋼琴跟一把十二英吋的鋼琴家…”）

每個程式設計師表面上都試著把DWIM寫進他們的軟體內，但幾乎都是用臆測的方式，事先假設使用者的行為會如何如何，有時候是以協力過濾(collaborative filtering)或其他以規則演算的方式來寫，但同樣也是會錯誤百出；唯一能讓DWIM不再只是驚鴻一瞥的方法是創造一支真正有智能(intelligent)的軟體──不僅是有意識，而是有智能，希望也有智慧和感知能力，以及（咽口水）友善的。

但這就會令人憂心了，大家都知道“智能”並不必然對你會產生有同理心，特別是你做了一些白目的事情。

所以到底要不要DWIM啊？就一方面而言，我們希望軟體可以更好，預測你想要的，回應你的需求，所以你可以過著你一直渴望的快樂幸福的生活，就另一方面而言，想達到這樣的境界的唯一方法是打造比我們更聰明的軟體，到那時，好一點的話我們要擔心會不會被邊緣化，壞一點的情況是我們要擔心會不會被奴役或被消滅掉。

我認為這解釋了，至少某部分解釋了，為什麼我們業界大部分都在打造越來越大的死系統來達到假假的DWIM（而且，打造這種大而麻木的系統，有什麼語言會比Java更好嗎？），死系統很安全，它們是決定性的且完全可控制的。

讓我們野心先別那麼大，省下口水先假設在我們有生之年不可能建造出有意識、有智能的軟體，那麼，比起現今我們大多數人產出的一般般的大便，有可能建造出比那更好的軟體嗎？

有另外一隻精靈叫做QWAN，建築師Christopher Alexander所發明的詞彙，意思是“Quality Without a Name”，而且（就跟這篇論文的其他難懂的觀點一樣）這是他早就了解的概念，終其一生不斷嘗試想把它描述出來跟找方法確實把它打造出來；簡短一點講的話，QWAN是一種無形無影“看見了自然就懂了”的空間或結構的特質，帶有 (a) 經由有機成長可以達到的境界，以及 (b) 詭秘地跟人類大腦中某部分硬體或軔體有關係，因為每個人都會有那靈光一閃抓到那模糊意義的時刻，但沒人真的知道為什麼會這樣。

在過去晦暗的時代，一些軟體專家們領悟到軟體也可以有QWAN，然後又發現在軟體跟從實體結構中想把它揪出來都一樣困難。

我在這裡主張，在之前列出我喜愛的系統，剛剛好在這些系統中可以找到明顯的QWAN，而我說那些缺乏重要特質的那些系統，都沒有QWAN的蹤影。（我之前有列舉出幾個較明顯的例子，然後含糊帶過其餘的，還記得嗎。）

人們都看出Emacs擁有QWAN這特質：美好、有生氣、舒服、正確，好像舊舊的牛仔褲那麼合身，猶如圖書館內火爐旁舒適溫軟的椅子；我現在說的恰恰是非常偏右腦的東西，情愫與感性：剛剛好這正是搞軟體的人很憋腳不擅長的，難怪我們不知道怎麼把這玩意放進軟體內，但不像使用者介面設計，軟體QWAN只可能從程式設計師手底下出現，因為對那些在你的軟體平台上開發的人來說，你擔任的角色就猶如室內裝潢師、主廚、人體工學顧問一樣。

那就是為何我認為大部分的軟體都是大便的原因，我不是在講一般使用者的使用經驗與感受，我是在講開發人員的開發經驗與感受（如果有的話），設計是一種藝術，不是科學，而且芸芸眾生皆非天生的藝術家，所以當QWAN出現在軟體系統中，即使只有一點點，也是很非凡的成就。

注意，順帶一提，軟體系統給一般使用者的使用經驗跟給開發人員的開發感受根本就是兩回事，Visual Studio提供相當精緻的使用者經驗，在這裡我說的使用者是指寫C++或C#程式碼的程式設計師（相對的另一方是，寫工具軟體幫助其他人寫程式，或是幫助別人把一些常做的事情自動化）；Emacs讓使用者超難上手，但給開發人員的介面無與倫比好的不得了；Eclipse在兩者之間，但看得出來比較偏向一般使用者那一邊。

最後，QWAN有某部分是無法言喻的，把我的配料（命令列模式、擴充語言、advice系統、等等）加進去會讓系統更好，但不保證QWAN就會浮現出來，QWAN那些部分最終還是要回歸到品味(taste)，既然品味人人皆不同，而且QWAN遠遠比不上DWIM那麼聰明，一個人的QWAN或許會是另外一個人的惡夢。

不過我依然認為我們應該試著將它打造出來。

型別系統(type systems)扮演的角色

太好了，來龍去脈說的夠多，我終於可以解釋一下我對型別系統的看法。

簡單講，型別系統是用來建造硬體的。每套軟體系統都有台機器在底下運轉──其實應該說有一整疊的機器，很多很多，從馮紐曼機器的CPU與暫存器與匯流排，往下到半導體元件，再到原子與夸克，以及量子力學的理論基礎。

不過我對硬體有更廣義的定義，硬體可以是任何事物，可以產出決定性的運算結果，非常硬而沒彈性，你必須先把它弄破才能做點修改要不然就要整個換新。所以，它並不只是由原子組成物理結構意義上的硬體；就我的觀點看來，一台機器的硬體部分也包含了那些需要重新啟動才能做修改的軟體。

型別系統的概念跟“編譯期間”與“靜態檢查”緊緊相連，我對型別系統也有非常廣的定義，我認為所有加諸在運算上的限制都是某種型別系統，包括scoping跟visibility(public/private/protected/friend/...)的限制，安全性限制，甚至程式的基本運算架構也算，我的看法中的“靜態”型別檢查其實包括了某些發生在執行週期的檢查。

但當談到靜態型別系統時，大部分人指的都是編譯週期的檢查與驗證（語言的語法中的型別標示，從AST建立推論出來的型別資訊），這些是在執行時就會不見了的東西。

跟把限制與檢查延到執行時才做相比較，靜態型別系統有一些優點，其一，程式碼跑的比較快，因為如果你執行前就做好檢查的動作，而且你若能保證執行時程式不會有改變，那你就不必在執行時做檢查，另外一個，靜態的限制條件，通常都可以用編譯器之外的工具加以分析（例如你的IDE），這可以幫助你了解程式執行的流程為何。

真是太棒啦。

靜態型別系統沒什麼不好，只是你必須知道，當你用它時，你是在建造硬體，而非軟體。

對一個寫好的程式而言，靜態型別系統絕不會對執行效能有所影響：不論系統提供多少的型別可用，產生出來的機械碼是一樣的，有個恰當的例子：C就只有那麼一點點最基本的型別，但C++程式不會比C跑的更快，C沒有動態型別檢查(dynamically typed)，但也不太能算是靜態型別，單單用C也可以寫出又快又穩的程式。（Emacs跟Linux核心就是兩個好典範。）

靜態型別系統的正確使用時機是當我們想把軟體固定下來變成硬體的時候；每當一組運算法則（例如OpenGL繪圖指令）變得很普遍很穩定時，就值得犧牲一些彈性來將它轉到機械層以獲得較高的效能，也就是轉成硬體，但通常效能最佳化會對彈性造成很大的損害（其中非常小的一部分是標準化過程所帶來的，我想）。

因為眼下大部分的程序員都偏愛打造牽線木偶而不是會讓人恐慌的真人小孩，大部分的程式設計傾向於建構一層又一層的硬體；C++跟Java程式設計師們（我想C#也是）基本上在一開始就用型別系統來塑模任何問題，也就等於把每一行程式都轉成硬體的形式。

僅用陣列、鏈結串列、雜湊、樹結構與函式就可以用C++跟Java寫出鬆散型別檢查(loosely-typed)的程式，但這樣會被兩個陣營的人強烈抨擊（或至少皺眉不屑），在兩個陣營裡，嚴格型別檢查跟詳細塑模設計在過去十年來逐漸成長成主流，他們認為型別檢查鬆散的程式會危害生產力（也就是指會影響開發時程），也會危害彈性（也是指會影響時程表，因為沒彈性表示很難納進新的功能）。

Hindley-Milner型別系統（源於學界，幾乎打不進業界）的虔誠教徒相信H-M型別系統遠遠優於Java或C++的，因為（理由之一）它漏洞較少。

H-M不被業界所使用，各位，聽我說，正是因為它沒有任何漏洞。如果你正在開發軟體，但你相信（同大多數人）開發方法是在一個長又痛苦的循環中不斷地建造硬體然後丟棄，直到那塊硬體是你想要的東西才停止，那麼有時候你會需要掙脫型別系統的限制：告訴型別系統閉上鳥嘴、我知道我在做什麼、我的程式寫的沒錯正是我想要的，型別轉型(type casts)、縮減或放寬的轉換、用friend functions來繞過類別的存取保護機制、把自訂的迷你語言放進字串內然後自己手動解析，有數十種方法可以跳過Java跟C++的型別系統檢查機制，而且程式設計師們一直都有在用，因為（很少人知道這點）他們真正試著建造的是軟體，並不是硬體。

以沒路用的形式上的數學觀點看來，H-M是很優美的，它處理起某些運算結構與概念特別巧妙；在Haskell、SML、OCaml可以找到的樣式比對後分發(pattern matching dispatch)非常非常好用，但不意外地，它處理起其他一般常見且大家都需要用的運算結構與概念非常笨拙，不過那些擁護者反而辯解說成是你錯了、其實你不需要這些東西，例如像是，你知道的，設定變數這種基本動作，你才不想要這種東西咧，相信他們吧。（OCaml讓你做，但提到這點時他們的目光都下垂看著自己的鼻子。）

沒錯，加上一點努力，你可以用Haskell打造出漂亮柔軟的牽線木偶，但永遠就是個小木偶皮諾丘，絕不會有好心腸精靈讓你美夢成真變成小男孩，Haskell中幾乎沒有動態程式碼載入或是執行週期的反射機制(runtime reflection)這些東西；這些概念對他們來說太怪異了，以至於連想跟他們討論這些概念為什麼有用都很困難：他們的世界觀裡沒有軟體是活生生的可以成長可以呼吸這樣的思想。

讓我們來看看動態型別檢查的天地裡稍微不那麼體面的語言，大家都知道很多程序員都把動態語言跟玩具看做同一類；主要流行的動態語言包括Perl、PHP、Python、Visual Basic、JavaScript、Ruby、Tcl跟Lua，除了這些語言設計者應得的尊敬之外，我不得不說他們在學生時代的編譯器課程應該是被當掉的吧，舉個例：他們都沒弄好lexical scoping；諷刺的是，他們的腳本語言放到鎂光燈下後反而讓他們（Larry, Guido, Matz, Brendan, ...）搖身一變成為世界級的語言設計者，這也讓他們，跟Salieri一樣，能夠以大部分人不了解的觀點來理解領會他們設計語言的不足與弱點（現在想修正已經太太困難了）。

Scheme大有前途，但它有個致命缺陷，就是它不能成長，跟已被業界廣泛採用的語言與平台情況不同，它們是為了保住廣大的使用群，Scheme是為了維持小而美才能佔據它的利基市場，也就是用在電腦科學教學課程上。

多方看來Common Lisp是個理想的選擇：它是動態型別檢查的語言，但可選擇性地加上型態標記（換句話說，你建造軟體，然後可以選擇要不要轉成硬體），很多好工具可用，說明文件也都有，具有好軟體之必備特質，我在這篇文章舉出來的它都有，而且還有相當程度的QWAN，然而，它已經停止繼續發展了，程序員就像鯊魚嗅到一樣敏感察覺到它沒氣勢了，Common Lisp擁有的能量跟William F. Buckley, Jr.和Charleton Heston激辯不相上下。（我看過一次，我發誓他們兩個一定有一半時間在打呼）。

單純的Lisp缺少了C的語法結構，在C語法根絕之前：這項任務可能要花上五十年，我們絕不可能在電腦運算與語言設計上有什麼真正的進展，在那之前若想往前走，唯一之道是把程式語言中的模型（AST)與表示（語法）分離開來，允許語法外衣，讓愛用者們繼續用C語法直到他們全死光，Common Lisp本可以加進額外的語法規則，但它既然已不再成長，也就不可能發生。我會到別處尋找下一個主流物(the Next Big Thing)。

結論

時間是凌晨三點三十分，已經超出我每月部落格寫作限制時間兩小時了，你下個月或許會在我這看到一篇簡短的部落格！不論如何，我想我已經把胸中的不吐不快都寫下來了。

我想，我們的理想是軟體能夠按照你的意思執行動作，不過因為DWIM只可能發生在真正有智能的軟體上，而想要依據變動中的世界來預測軟體該怎麼寫太困難了，話雖如此，我認為那是我們想要的。

我懷疑短時間內不可能有那樣的東西出現，因為大部分的程序員一股腦地專注在打造硬體上，勤奮地將型別系統使用在他們的軟體上，太過度了反而搞壞了原本還不錯的軟體。

在魔法油燈變出DWIM前，我認為我們應該建造有生命的軟體，或許只是像樹一樣的生物，但那就足以喚醒其體內的QWAN，任何只要有一丁點的QWAN的系統都真的很棒、值得使用──至少對寫程式的人來說；一般使用者對這些系統對評價參差不齊。

有生命的軟體，擁有命令列模式，因為你需要能像個成年人一樣跟他說話，擁有擴充語言，因為要能夠幫助他成長，擁有advice系統，因為你需要訓練跟修正他，擁有一塊利基市場，因為他需要使用者們才能成長茁壯，擁有外掛系統，這樣你才能幫他打扮參加舞會，而且他是有自我察覺(self-aware)能力的，能力的最大值只會受限於外在效能的約束，這些特質都必須巧妙優雅地整合在一起，花在每個子系統上的心力與詳細程度都跟整個系統一樣。

而且你不應該在每當需要修改時就要謀殺它一遍，如果你對待你的軟體像個活跳跳的生物，那麼最終他就會開始變得像個真的。

如果我們能喚醒真的人工智慧，我想皮諾丘是個適合的名字。

讀後推薦：程式設計師的自我修養：連結、載入、程式庫 by 俞甲子/石凡/潘愛民

2010-10-11T11:10:00.000+08:00

我看了這本書，覺得還不錯，對我很有幫助，釐清了很多概念與疑問。

書名：程式設計師的自我修養：連結、載入、程式庫
作者：俞甲子/石凡/潘愛民
出版社：碁峯

史瑞克說妖怪像洋蔥一樣，是有層次的，資訊科學這玩意兒更是如此，從上到下不知有多少層，有應用軟體層、有整合開發套件跟永遠看不完的類別庫與函式庫、有作業系統提供的API跟系統呼叫、有軔體層、有硬體層，每層都還可以繼續細分下去，另外還有網路服務跟雲端運算，各種數也數不清的結構與架構，嘿嘿，看來咱們比妖怪更有層次啊。

這本書的主旨就是副標題所說的，關於軟體程式從寫好開始，編譯成組合語言，組譯成機器指令，加上執行階段程式庫靜態連結成執行檔，執行時由作業系統載入到記憶體裡，動態載入與連結所需的程式庫，這一連串的過程；這本書解說了在x86架構下的ELF檔與PE檔格式，分別是在Linux與Windows系統下所使用的檔案格式，用來儲存執行檔(無附檔名或.exe)、中間目的檔(.o or .obj)、靜態程式庫(.a or .lib)、動態程式庫(.so or .dll)等等，書中有概念的闡述，也分解簡單的小程式來當實例，對我來說，幫助我釐清了很多觀念，例如什麼叫做runtime(runtime environment, runtime library, 執行階段程式庫)、編譯器之後的靜態連結器要處理哪些東西、動態程式庫(.so or .dll)背後的道理是什麼、符號表(symbol table)到底有多重要、在main()執行之前作業系統做了哪些事情、等等，真是太棒了，好書一本。

有一些書，偏重理論與概念，例如鐵甲武士惡鬥吐火龍，對於一個在應用軟體層的人來說，較不實用，我想要的是實際上用的工具與技術(compiler, dynamic linking, etc..)的概略說明，我想要的是當前廣泛使用的作業系統(Linux, Windows)與工具(gcc, Visual C++)與檔案格式(ELF, PE)的探討，當理論書籍說有哪些方法可以用來實作出什麼什麼技術，本書則告訴你Linux與Windows用的技術是什麼；這樣當我在其上開發軟體時，才不會被華麗文藻包裝過的說明文件迷惑，搞不懂共用物件與plug-in的差別。

PS 不要誤會，龍書是經典，編譯器也是資訊科學必修的課程。

還記得當初寫第一支程式的時候嗎？從寫好到執行看到螢幕上印出hello, world.，其實中間經過了許許多多的關卡，編譯器、組譯器、靜態連結器、作業系統載入、動態連結、虛擬記憶體系統、等等，不說不知道，稍稍往下鑽研就會被嚇到，疊床架屋一層又一層的技術，才能讓我們鍵入少少幾行程式按下個按鈕就可以寫出hello, world.，當我們在其上享受各種新式技術與便利之餘，也別忘了要了解一下底層的原理，因為三不五時，底層的東西會跑上來嚇人，有時候程式當的亂七八糟，可是又看不懂錯誤訊息，有時候甚至連錯誤訊息都沒有，這時若心理有底層技術的概念，解決問題的機會就會多個幾趴。

如作者所言，關於載入器(loader)與連結器(linker)的資料是不多的，就算有也是那種看起來很硬很技術性的著作，有這麼一本算是研究心得的著作，要謝謝作者所花的心力。

翻譯：Windows程式設計的革命簡史(A Brief History of Windows Programming Revolutions) by Ron Burk

2010-09-07T21:34:00.001+08:00

文章：A Brief History of Windows Programming Revolutions（Windows程式設計的革命簡史）
日期：2009.12.01
作者：Ron Burk
作者的部落格：Ron Burk - Programming, psychology, and "stuff".
作者簡介：
曾擔任Windows Developer's Journal的編輯職務；正在寫一本書，書名為"The Pop Psychology of Programming"；這裡有一段5分鐘的影片，Ron Burk講解三種computer programming的定義。

Windows程式設計的革命簡史

爬出DLL地獄──再一次

首先，我們有Windows API以及DLL地獄(DLL Hell)，第一波的革命技術是DDE──還記得熱連結(hot links)讓我們可以產生出狀態列來顯示微軟股票目前價位嗎？

大約就在那時，微軟搞出了VERSIONINFO這玩意，用來揮除DLL地獄這夢靨，但微軟的另一個團隊發現DDE有一個致命性的缺陷：那不是他們發明的！

為了解決這個問題，他們創造出OLE（跟DDE差不多，看起來不同而已），而且我還深深記得在一場微軟討論會上，有位演講者公開聲明Windows API很快就會改寫成OLE API，螢幕上的每個控制元件將會變成OCX；OLE引進介面這玩意，用來跟DLL地獄說掰掰，還記得那"就地(in situ)"狂熱嗎，還記得那時我們幻想著有一天所有應用軟體通通內嵌在一支（很明顯地，非常大的一支）Word文件中嗎？

就在那時期左右，微軟改拜C++，MFC也出來了，再一次地解決老問題，但這一次有繼承(inheritance)這玩意，不過咧，OLE可不會坐著發呆，重新包裝後以COM之名現身，突然我們醒悟了，OLE（還是DDE啊？）才是王道啊──裡面包含了精心打造的元件版本系統，是用來避免陷入DLL地獄的，與此同時，微軟某搗蛋團隊發現MFC有一個致命性的缺陷：那不是他們發明的！

他們毫不猶豫地修正了那缺陷，創造出ATL，跟MFC差不多，看起來不同而已，並且試著把COM團隊費盡心思教會我們的技術細節通通藏起來，這可刺激到了COM團隊（還是OLE啊，搞不清楚？）重新改名為ActiveX後再出發，釋出數以百磅計的新介面（甚至有新的版本控管介面，用來防止DLL地獄的玩意），還有，讓我們的程式碼可經由瀏覽器來下載的能力，加上各種病毒（哈哈──想辦法跟上腳步吧，你們這群ATL傢伙們！）；就像個被忽視沒人裡的小孩一樣，作業系統團隊大聲呼喊著看過來喔，"準備好等著迎接Cairo吧"，ㄘㄟˊ，他們從來沒能好好解釋說明過那是啥東西，更別提出貨見人了，不過有一點功勞要算在他們身上，作業系統團隊確實導入了"系統檔案保護機制(System File Protection)"，是用來遠離DLL地獄的玩意兒。

與此同時，微軟另一支團隊發現Java有一個致命性的缺陷：那不是他們發明的！怎麼補救呢？於是有了J、Jole、ActiveJ（老實說，我記不得名字了），跟Java差不多，看起來不一樣而已，很興奮吧；不過昇陽開始告微軟，用的是某古老的法條說一家公司不能在一年內放出太多的技術，很明顯地是在試著阻止微軟創造雷同但只是看起來不一樣的產品，結果是讓微軟有了全新的自由，可以把錢塞進國會議員的褲子裡；還記得J/Jole/ActiveJ的產品經理用他的鞋拍桌保證微軟絕對不會終止放棄他的產品嗎？傻孩子！這一切只代表了一件事──ActiveX（還是應該叫COM啊？）團隊得到的關愛眼神太少了，這一群身段柔軟的API打造者，以更強的姿態COM+（不是應該叫ActiveX+嗎？）還有MTS（我不懂，為什麼"MTS"裡沒有"COM"或"ActiveX"或"X"或"+"等字眼呢──這次我整個被他們嚇到了！）回來了，他們還威脅說不久之後就要在所有術語後面再加上一個"+"；大約在那個時候，某人大聲嚷嚷著"Windows DNA"和"Windows Washboard"一段時間，不過在我搞懂之前就死掉出局了。

那時，微軟注視著網際網路(internet)的發展已有數年，越來越不安，他們發現，網際網路有個致命性的缺陷：哎呀呀，你大概知道我要說什麼了，於是把我們帶到.NET（唸起來像是"doughnut甜甜圈"，看起來不一樣而已），跟網際網路雷同，只不過有著更多的文宣廣告與宣傳；讓我把一點說的非常非常清楚：.NET解掉了DLL地獄這個麻煩，.NET有一個新的程式語言，叫做C#（發現Active++Jspresso有個致命性的缺陷，所以下場是出局了），.NET包含一個虛擬執行機器，所有語言都在上面跑（發現依賴英代爾CPU有個致命性的缺陷），.NET只用一套登入系統（如果不把你所有的密碼都存放在微軟的主機上，那是有致命性的缺陷的），事實上，比較簡單的方式是把.NET沒有的東西列出來；毫無疑問的，.NET將會是Windows程式設計的革命性的徹底改革的新方式...到明年就不是了。

翻譯：C++的編譯速度(C++ Compilation Speed) by Walter Bright

2010-08-22T00:06:00.003+08:00

文章：C++ Compilation Speed（C++的編譯速度）
日期：2010.08.17
作者：Walter Bright
作者的部落格：Walter Bright Home Page
作者簡介：
Walter Bright是位電腦程式設計師，是D語言的設計者，第一套C++原生編譯器的主要開發員，也就是Zortech C++（後來變成Symantec C++，現在是Digital Mars C++），在C++編譯器之前，他開發了Datalight C編譯器，先以Zorland C後以Zortech C之名販售。

C++的編譯速度

我常聽到有人抱怨說C++程式碼編譯速度很慢，有時候甚至要花上整夜的時間，編譯慢是exported templates這玩意的源由之一，甚至列在發展Go語言的理由清單上，這點確實是個問題；既然我身在C++編譯器的產業中，三不五時就會被問到這點。

為什麼C++編譯速度慢？一旦我們合理假設開發C++編譯器的人都擅長於寫出效能高的程式碼，那麼，一定有某個深植於C++語言本身的原因；的確，不同牌的C++編譯器速度快慢相差極大，但還沒完喔，其他語言通常能夠快上一整個等級，而且厲害的編譯器專家應該不會只為其他語言寫編譯器吧（！）。

我從1987就在寫C++編譯器了，對比今日想當年，電腦可是慢的不得了，所以我投注極大的精神讓編譯器能夠快一點，花上大把的時間做效能分析以及微調各個小地方來讓編譯器更快，我發現，語言本身的某些特性讓編譯速度快不了。

理由是：

1. 轉譯過程中有七個階段[1]。雖然有些可被合併處理，但在前端處理原始碼最少要有三個階段，至少我還沒找到降到三以下的法子。要快的話語言設計時就只能有一個階段，C++0x惡化了這點，居然要求trigraph轉換與行尾為\與下行接合這兩個功能要能夠支援string literals[2]。

2. 每個階段都相依於前一個階段，意思是，沒有可靠的方式可以做往前先看的動作，例如，往前先去找#include然後先去讀進檔案；編譯器沒辦法往前先看出是個string literal所以不要做trigraph轉換，必須先做trigraph轉換，但要做好回到上一步的準備；我從沒找出能夠平行編譯C++程式碼的方法，除了在make時加上-j參數這種很粗略的作法。

3. 因為#include是種文本逐字置入(textual insertion)的機制，而不是符號式(symbolic)的，當一個檔案被#include很多次，編譯器只能悲情地做白工地一再地處理，即使是被#ifndef包起來也一樣。（Kenneth Boyd跟我說，如果將標準文件讀的仔細一點，是有可能允許編譯器省略被#ifndef包起來的#include，但我不知道有哪一支編譯器利用了這點。）

4. 程式檔案中總是傾向於，通通#include進來就對了，當責任全部落在編譯器身上時，每一個.cpp檔通常都會連帶引出一拖拉庫的檔案要處理，在Ubuntu上，就算只把標準函式庫#include進來，居然需要處理74支檔案總共37,687行耶（不包括同支檔案被#include多次的情形）；templates以及generic programming的興起更惡化了這點，而且，把更多的程式碼放進標頭檔(header files)中的壓力也逐漸升高，更是雪上加霜。

5. 語意上的與語法上的（不只是詞彙上的）處理單位依賴處在它之前的整個原始文本，意思是，沒有東西是上下文無關的；不把#include的東西先看一看，就不能正確地解析(parse)檔案，甚至是先做lex的動作也不行，標頭檔在第二次#include時可能含有不一樣的內容（事實上，確有標頭檔利用這點）。

譯註：語意上的 semantic，語法上的 syntactic，詞彙上的 lexical。

6. 因為第5點，編譯器在某個TU[3]所編譯的#include的結果，不能下一個TU共用，每個TU都必須從頭開始。

7. 因為不同的TU之間彼此不知道對方的存在，常用的templates在每個TU都會被產生出來，鏈結器(linker)會將重複的刪除，但當初所花的時間都白費了。

預先編譯標頭檔(precompiled headers)解決了一些問題，但那是對非標準的C++做出某些簡化後的假設，才可辦到，例如，標頭檔被#include還是會含有同樣的內容；所以你必須小心，不能違反這些假設。

想解決這些問題又要跟舊有的程式碼保持相容性，真是高難度的挑戰啊，我預期在C++0x之後，會有相當份量的心力花在這些問題上，但那至少是10年後了。

在那之前，並沒有哪個方法可稱得上是解答，exported templates被廢棄了，precompiled headers是不符合標準的，imports被踢出C++0x標準之外，以及往往你沒有選擇編譯器的權力，諸如此類的；現在來說，有效地使用make -j參數可算得上是最好的方法了。

我會再談談關於語言的設計，哪些特性能夠導致快速的編譯速度。

註解

[1] C++98標準文件的2.1章節，七個階段是：

1. Trigraph與萬國碼轉換。
2. 行尾為\時接到下一行
3. 轉換成預先處理的標記(preprocessing tokens)，標準文件註明說這是上下文相依的。
4. 預先處理的指令執行，展開巨集，#include的讀取以及再跑一次1到4。
5. 將原始碼中處在char與string literals的字元轉換成執行字元集(execution character set)。
6. string literal的接合。
7. 將預先處理的標記轉成C++的標記(C++ tokens)。

[2] 在C++0x標準文件中的例子在2.14.5-4：

const char *p = R"(a\
b
c)";
assert(std::strcmp(p, "a\\\nb\nc") == 0);

[3] 一個TU，也就是一個轉譯單位(Translation Unit)，通常就是一支C++原始碼檔案，通常是以.cpp為副檔名，編譯一支TU會生出一個目的檔(object file)，每個TU的編譯過程都與其他TU不相關，最後由鏈結器(linker)將目的檔整合成單一的執行檔。

感謝

感謝Andrei Alexandrescu、Jason House、Brad Roberts以及Eric Niebler給予這份文章草稿時的有用建議。

翻譯：Java簡史(A Brief History of Java) by Jeff Foster

2010-08-16T17:40:00.000+08:00

文章：A Brief History of Java（Java簡史）
日期：2010.08.13
作者：Jeff Foster
作者的部落格：Fatvat : Exploring functional programming

Java簡史

話說當年1995之時，昇陽(Sun)公司釋出Java程式語言，做為整個Java平台策略的一部分，當初喊著“一次編寫，到處運行”的口號，要讓Java遍地開花，從腕錶到手機到筆電到超級電腦，隨處皆可運行。

剛開始時Java的接受度有高有低，當出現Java力有未逮之處，就會有福音天使出來保證這技術將會改變世界，你看，靠Java運作的烤吐司機就在不遠的角落了。

隨著時間演進，為了守住“一次編寫，到處運行”的承諾，Java也逐漸背上更多的負擔，標記為廢棄的方法(deprecated methods)到處可見，但昇陽必須留下這些功能來保持向後相容性；java.util.DateTime此套件變成了劣質設計的同義字，差勁的命名規則總是在修正中（叫它size好還是length好呢？）。

微軟(Microsoft) 的.NET開始蠶食Java的領地，微軟團隊導入delegates，一種有做型別確認的函式指標，使得事件處理(event handling)變得容易許多；Java要趕快反擊，所以在版本1.1時，Java生出了inner classes，能夠有類似的效用，但以一種較有限制與用起來較麻煩的方式出現，一份Java白皮書斷定地說『bound method references是不必要的東西....這玩意減損了Java語言的簡單性與一致性』，但與此同時，將bound method references放進Java裡的勢力從沒消失過。

當Java到了版本1.4時，為了對抗微軟的.NET，昇陽決定要有一套新的策略手段，思索良久之後，昇陽將版本1.4改成“5”，試圖一舉超前.NET的2.0。

同時間附帶了另一個決策，實作generics，一種能夠有額外的型別安全檢查的技術，不幸的是，隨型別安全而來的代價是要多打字，工程師引入generics後，每次又要寫一遍List<Foo> foos = new ArrayList<Foo>敘述時，就會常被聽到咒罵聲。

大學很快地就接納了Java；學生們不再需要學習手動記憶體管理與指標的種種艱澀難懂的奧祕，反之，他們可以依賴Java來做這些苦功夫，集中精神在解決問題上，不幸的是，這也導致一批同等級的開發者，被稱作“設計模式使徒(Patternistas)”，手上只有鎚子且把所有問題都看做釘子去敲，在他們的領導下，Java命名規則越來越可笑，當這種類別名“RequestProcessorFactoryFactory”成為一種常態時，一些開發人員開始質疑無限制地構築抽象化高塔是否真為明智之舉。

當開發人員意識到他們終日所為僅是把數千行的程式碼搬來搬去而已，他們需要一個字眼來辯護他們的存在意義，那個字就是“重構(refactoring)”，所有的設計模式使徒欣喜不已；他們不但能運用工廠的工廠模式(factory factories)、獨身模式(singletons)與訪問者模式(visitors)來解決問題，而且還能朝三暮四改變心意，並用個時髦字眼來正當合理化！

整個產業的演進方向只是為了滿足設計模式使徒們而已，跟別人與別的語言比起來，老鳥們覺得Java越來越弱，所以新型開發環境出現了，IntelliJ與Eclipse的目標是將開發人員受的傷害最小化，靠著極佳的程式碼自動補足機制(code completion)與重構功能，只需按幾個鍵而不用輸入一長串的程式碼來達到那想要卻沒有的語言功能。

Java開始向企業端進攻，招攬了一些有領導地位的的架構大師，打造出一套會造成典範轉移的協同式架構方法來建置企業軟體，其結果不小於一場革命；爪哇豆(beans)現身了，Beans顯然是一種伺服端的元件架構，用來當企業應用軟體的建構基本模組。

使用generics所帶來的角括號障礙一旦減低之後，Java邁步向前跳上了XML的列車，藉由使用XML，開發人員就能將簡單明瞭的概念表達成一整個龐大囉嗦的角角惡夢，好處是XML檔案（不同於其他檔案類型）可以輕易地被電腦看懂處理，至於對人難以閱讀這種小代價是值得的，像是Ant和JBoss這些軟體都是由可執行的XML所建構出來的。

與此同時，在這些架構大師的宇宙之外，一群新種程式員認為將該死的工作完成遠比一整天都花在打字重要，這種想法誕生出一些框架，例如Rails，設計的重點在於不擋路讓你能解決真正的問題，其中心思路以“約定俗成先於設定(convetion over configuration)”之名廣為人知，Rails獲得正面的迴響，而且至少有一些Java信徒轉投向Ruby的陣營；Java不再能緊抓人心的第一個徵兆開始浮上檯面。

2006年8月，Java 7計畫啟動，很多開發人員都要求一個叫做lambda expressions的功能，毫無疑問地會簡化很多原先Java搞的很痛苦的撰碼作業，可惜，Java委員會四年後還在為這項功能的細微差別爭辯不休，而且有可能會被排除掉，Java 7的無作為引出了新一代更迷人的語言，例如Clojure和Scala，設計在Java環境中運行，但不需要Java語言。

2009年4月，甲骨文(Oracle)公司宣布計畫將收購昇陽，此乃敲下棺材釘的最後一鎚，由“黑暗王子拉瑞”所領軍的甲骨文是一部併購機器，擅長於企業軟體與賺進大筆鈔票，當甲骨文的律師們了解一份份的軟體專利文件，他們會挑個大目標然後引起戰鬥，而還有哪個目標比谷歌(Google)更大呢（一家網路廣告的領導品牌），所以甲骨文的律師猛撲而出，戰爭就此展開。

這會給Java帶來什麼後果呢？從15年前的小小開端起，在昇陽的領導下，Java爬上了最熱門的程式語言的頂端，而在甲骨文的控制下，不但到底會不會有下一版的Java情況不明，更別提開發人員渴望許久的功能了，這是Java的新開始還是結束呢？

翻譯：命名專案的十項提示(10 Tips for How To Name Your Project) by J Wynia

2010-08-12T07:00:00.160+08:00

文章：10 Tips for How To Name Your Project（命名專案的十項提示）
日期：2006.06.22
作者：J Wynia
作者的部落格：The Glass is Too Big

命名專案的十項提示

這已經是數年前我寫的一系列文章中的一篇，但我想要再次分享出來，考慮到有這麼多人開發的產品與服務的名字，居然需要落落長的解釋與說明，才能夠了解、念出來或是正確寫出來，我想這篇的內容仍然還是跟我當初寫的時候一樣重要。

命名你的專案的方法（與避免事項）

1. 如果你想到的名字是直接取自於某科幻或奇幻小說、電影、漫畫等等題材，放棄吧，在軟體業中這些都已經被用爛了，不僅想出有原創性的名字的可能性相當低，而且，科幻題材中大部分的角色與地點名稱都已經被註冊了，你有被告的風險。

2. 如果你是從希臘、羅馬或古北歐神話中取材，再嘗試別種作法看看，我們不知收到多少封談到以“墨丘利(Mercury)”命名的軟體的電子郵件。

3. 拜拜股溝(Google)大神，找找你想要取的名字，找到的項目越少越好，如果什麼也沒找到，恭喜你囉。

4. 如果你想要錯拼幾個字母來打造獨特的名字，別！把你嶄新的視窗膽案系統稱作Phat32，使用者在搜尋引擎只會看到關於“fat32”的結果，你覺得他們會高興嗎。

5. 如果你取的名不能在五零或六零年代的電視上說出來，你的方向大概是錯的，特別是當你想要產品在工作環境中被每一個人使用，如果單單念出產品名就有可能會被告性騷擾，那自然沒人會推薦給同僚。

6. 如果你的產品名連發聲念出來都是件不可能的任務，你就得不到口耳相傳帶來的好處，同樣的，如果沒人知道怎麼念，人們也就不會試著大聲說出來詢問相關疑惑。你怎麼念MySQL？PostgreSQL？GNU？幾乎所有地球上有人用的語言都是有某種子音/母音的音節系統，輪流使用子音與母音來拼名字是個相當好的方法，確保某人可以發音出來。

7. 跟女人的裙子一樣，越短越好。

8. 查看看.com的網域名稱是否可用，如果已經被申請走了，這是一項很好的指標，表示某人已經想到這個名字而且比你搶先要用它。做這個動作即使你不打算申請網域名。

9. 別把產品本身的限制條件加在名字上，把產品叫做LinProduct或是WinProduct的話，那將來要釋出跨平台版本怎麼辦。

10. 別把你自己的姓名用在開放原始碼計畫上，如果將來你不再參與，那這計畫就必須改名，或是你的名字將會以你不喜歡的方式被運用。

翻譯：專案之名有什麼意涵？(What's in a Project Name?) by Jeff Atwood

2010-08-11T11:48:00.000+08:00

命名，看似簡單卻絕不容易，啟動新專案要有個codename（內部專案代碼），寫程式要替變數、函式、類別取名，當專案完成變成產品，那也要有個又酷又炫的名號；取的好心情佳，取的不好整天就不順；看看這篇關於專案命名的文章吧。

文章：What's in a Project Name?（專案之名有什麼意涵？）
日期：2007.11.12
作者：Jeff Atwood
作者的部落格：Coding Horror

專案之名有什麼意涵？

從我進Vertigo公司以來，曾經參與過這些個專案：

米開朗基羅(Michelangelo)
納許(Nash)
威士忌小鎮(Whiskeytown)
超大硬糖(Gobstopper)

這些我們內部使用的專案代碼，是從一份放有各種“東西”的清單中按照字母順序選出來的，每個新專案都是這樣被命名的，我們從A開始用，當到Z用完時，我們會選出一組新的清單，作為命名專案的靈感來源，你可以猜出上述專案名的靈感清單從何而來嗎？別偷看啊！

關於專案命名，我們有以下這些鬆散的方針：

我們偏好一個單字的名字。
必須相當容易就可以念出名字來，拼出來也很簡單。
對客戶來說須是親切適宜的。
在整個公司內這名字必須是獨一無二的，沒有重複使用。
我們需要一個夠多的靈感清單可以選，照字母順序。

當然，一篇關於命名的文章若要說得上完整，就一定要引用於達康(dot-com)狂熱之最高峰時出現在線上雜誌-沙龍(Salon)的經典大作，命名競賽(The Name Game)：

最後，嘗試將命名一個專案所帶來的利益加以數字化，就如同試著量化一個名字所能帶來的好處，可能兩者同樣都很眼光狹隘，對一個找到跟他們一拍即合的命名商的幸運客戶來說，其邊際效益遠超出單純的取個名字，有新的詞彙字可以學，好玩的遊戲可以參與；還有，以百猴（一家幫人命名的公司）的例子來說，無可懷疑的溫暖與關懷，『我們得到的遠超出單單一個名字』九十八點六(98point6)的羅賓巴爾這麼說，『我是說，我替我女兒找了個好名，我們一個資深董事對‘梅斯卡蘭札(Mescalanza)’有強烈的認同歸屬感，大家不再稱呼他為吉姆(Jim)，他的名字就是梅斯卡蘭札。』與此同時，她還說，『我們網路開發部門的資深經理就莫名地愛上了‘果醬餅乾(Jamcracker)’，以致於，哈維(Harvey)會議已經改稱果醬餅乾會議，這家公司有三百個人將果醬餅乾視做哈維的代名詞。』

巴爾用手捂住嘴巴，『喔天啊，』她說，『我忘了，我不應該向一個記者提到這些名字，技術上來說，我們沒有這些名字的所有權，果醬餅乾這名字仍然是百猴的資產。』

巴爾停頓了一下，好像在思考些什麼，然後她爆笑起來，『聽著，』她說，『我收回剛說的，你想寫啥就寫啥，如果外面真有人想要將他們的公司命名為果醬餅乾，願神保佑，也祝他們幸運。』

不論如何，困難點在於，如何生出一些新的靈感用來激發專案命名時的來源，我們先看看微軟的專案代碼以及蘋果的專案代碼，當做想法的出發點，

這裡是過去不同時間點時，我們考慮用來命名專案的各種想法：

食物種類

電玩遊戲（Atari 2600，大型機台，等等）

啤酒品牌

羅馬帝王

卡通人物 / 節目

神話中的名字 / 神祇

汽車

GUIDs （個人最愛之一）

寶石

咖啡飲品的種類

州名

鄉村名

植物

希區考克的電影

狗的品種

顏色

著名的探險家

樹木

美國稅務表

英國君王

名人（例：沙岡）

維基百科文章名

單一字母（包括萬國碼）

無線電通訊的字母系統

糖果品牌

恐龍

歷史地點

城市街道名

IKEA宜家家居產品名稱

扣件種類（螺帽，螺栓，鉚釘，等等）

滑雪度假村

國家公園

山之顛

第二次世界大戰時代的船隻

鳥類

海灘

橋

Web 2.0的命名

魔獸爭霸的王國名

起司

國家

穀類早餐品牌名

如果有我沒列出來，但你認為是命名專案的好點子的話，還請留言。

開新專案之時，挑選一個新名字總是有其樂趣所在，我很驚訝我們很快就用光一整個A-Z循環，從我進公司的2005年算來，我們已經經歷過4次循環了，那是我們的作法，那麼，你又是怎麼命名你的專案的呢？

Lisp + GNU Emacs + SLIME on Windows

2010-06-25T11:06:00.012+08:00

上一篇講了GNU Emacs on Windows，其主要目的是為了這篇，安裝lisp系統與SLIME，on Windows。

首先是安裝lisp系統的部份，如果要從原始碼自行編譯的話，那會較困難，所以我通通使用已經打包好的套件。雖然只要一套實作即可，但我安裝了三個（CLISP、SBCL、CCL），這是為了試試看比較不同實作的差異，你不一定要這樣。

下面的鏈結是我使用的版本，你可以造訪官方網頁看看有沒有較新的版本。

首先是目錄的問題，太長或有空格都有可能會出問題，因為Emacs、lisp都有很深的unix背景，所以我新增了這些目錄：
C:\home
C:\home\bin
C:\home\bin\emacs （GNU Emacs放在這）
C:\home\yehnan （我的使用者家目錄）

開始下載安裝吧。

第一：CLISP (GNU CLISP)
在網頁上找到給Windows使用的套件，clisp-2.48-win32-mingw-big.exe（3.9 MB）。
我安裝在C:\home\bin\clisp下。安裝套件會增加這個路徑到環境變數PATH中。

有個小問題，安裝後執行，“找不到svm.dll”，解決方法是把libsvm\svm.dll拷貝到full\下即可，原因大概是Windows沒有symboloc link這種東西。

註：clisp-2.49-win32-mingw-big.exe修正了這個小問題。

執行後看到這個畫面就表示成功了。

第二：SBCL (Steel Bank Common Lisp，從CMUCL分支出來)
在網頁上找到給Windows使用的套件，sbcl-1.0.37-x86-windows-binary.msi（10 MB）。
我安裝在C:\home\bin\sbcl下。安裝套件會增加這個路徑到環境變數PATH中，並且新增一個環境變數SBCL_HOME指向這個路徑。

執行後看到這個畫面就表示成功了。

第三：CCL (Clozure CL，前身為OpenMCL)
在網頁上找到給Windows使用的壓縮檔，ccl-1.5-windowsx86.zip（34 MB）。
我解壓縮安裝在C:\home\bin\ccl下。

執行C:\home\bin\ccl\wx86cl.exe後得到這個畫面就表示成功了。

哇，很簡單嘛，lisp系統的部份已經搞定了。接下來就是安裝與設定SLIME。

SLIME全名為Superior Lisp Interaction Mode for Emacs，顧名思義，是一個Emacs的擴充套件（外掛），專門用來輔助寫lisp程式。包括一個slime-mode(minor mode)用來增強Emacs原有的lisp-mode，一個比較好用的REPL(read-eval-print-loop)，SLDB(debugger)，以及其他輔助工具。

怎麼取得呢？要用cvs指令，最好不要抓取一些網路上的壓縮檔（官方或非官方），因為那些可能都太舊了。

cvs -d  :pserver:anonymous:anonymous@common-lisp.net:/project/slime/cvsroot co  slime

怎麼安裝呢？把上面取得的整個slime目錄放進Emacs的load-path有設定的地方，我放在C:\home\bin\emacs\site-lisp\slime\。

怎麼設定呢？這就困難了。
首先在C:\home\bin\emacs\site-lisp\新增檔案site-start.el，內容是
(setenv "HOME" "C:/home/yehnan/")
。因為Emacs預設的家目錄會是類似這種的C:\Documents and Settings\Username\Application Data，太長且有空格，所以改掉。

然後是在C:\home\yehnan\新增檔案.emacs，各種設定都會放在這裡。什麼，你沒辦法新增一個開頭是小數點"."的檔案？使用Emacs新增吧，其實Windows是容許這種檔名的。然後編輯，加入以下的內容：
;pathname of Lisp executable file, to run an inferior lisp process
(setq inferior-lisp-program "C:/home/bin/clisp/full/lisp.exe -B C:/home/bin/clisp/full -M C:/home/bin/clisp/full/lispinit.mem -ansi -q")

(add-to-list 'load-path "C:/home/bin/emacs/site-lisp/slime/")
(require 'slime)
(slime-setup '(slime-fancy))

以分號開頭的是註解。
inferior-lisp-program那一行，是設定你的lisp的執行檔與參數。參數是從網路上找來的。
load-path那一行，將slime的路徑加入。
require跟slime-setup那兩行，是要Emacs載入SLIME。詳情可看這裡。

怎麼執行呢？在Emacs下鍵入M-x slime（M代表Alt鍵，M-x表示按著Alt不放，然後按x，然後輸入slime，按Enter）。如果沒問題，應該就會看到以下的畫面。

這是SLIME的REPL，你可以看到buffer的名字是*slime-repl clisp*，在這裡就可以輸入各種lisp expression並作evaluation了，REPL的指令請看這裡。

剛剛執行M-x slime，slime會進行以下的動作，先啟動在.emacs設定的lisp系統（在Emacs->Buffers會看到一個*inferior-lisp*）；還有一個叫做"Swank"的server，並建立起Swank跟inferior lisp之間的連線，然後開啟一個REPL。

恭喜你，已經有完整的lisp開發環境了。

對了，剛剛不是裝了三套lisp系統嗎？
請在.emacs把inferior-lisp-program那一行換成這個：
(setq slime-lisp-implementations
'((clisp ("c:/home/bin/clisp/full/lisp.exe" "-B" "c:/home/bin/clisp/full" "-M" "c:/home/bin/clisp/full/lispinit.mem" "-ansi" "-q"))
(sbcl ("sbcl"))
(ccl ("C:/home/bin/ccl/wx86cl.exe"))
))

如果直接打M-x slime，預設會執行第一個lisp系統，也就是clisp。
如果打M-- M-x slime，然後輸入clisp or sbcl or ccl，就會執行指定的lisp系統。

哇，好棒，想開始使用SLIME的slime-mode有哪些指令可以用，就看這裡吧。

參考文件：
1. Installing CLISP, Emacs, and SLIME on Windows XP from What’s In Peter’s Head。
2. Installing SBCL, Emacs, and SLIME on Windows XP from What’s In Peter’s Head。
3. SLIME User Manual from the offical website.
4. SLIME-HOWTO from Cliki

學習lisp :
1. Practical Common Lisp by Peter Seibel
2. The Common Lisp Cookbook
3. Structure and Interpretation of Computer Programs video lectures by Hal Abelson and Gerald Jay Sussman
4. Berkeley The Structure and Interpretation of Computer Programs by Satish B Rao and Brian HARVEY

GNU Emacs on Windows

2010-06-25T10:43:00.003+08:00

問：這篇要講什麼？
答：要講如何在Windows XP上使用GNU Emacs，主要是給程序員看的。我的電腦是Windows XP。

問：為什麼？Emacs這個古董不是很難用嗎？
答：雖然常常聽說Emacs很難學難用，卻是功能最強大的編輯器，也是程序員終極的工具，所以我就想說用用看囉。

這是GNU Emacs的logo。

問：你欠揍嗎？難用還用？
答：或許吧，別打我臉啊～不~哪裡都別打～。

問：Emacs到底是什麼東西？
答：很難解釋，讓我試試看。Emacs是個功能超強大的編輯器，但這不是重點，重點是它的擴充延展性超強，任何人都可以在上面“開發”，所以有人說Emacs是一個完整的開發平台，可以跟火狐Firefox對比一下，任何人都可以在上面開發各種功能的外掛；一般普通的編輯器（或是其他軟體），如果沒有某項功能，你就無計可施，如果某項操作行為不合你意，你也莫可奈何，如果是功能強一點的編輯器，會提供很多設定參數讓你修改，譬如修改各功能對應的快捷鍵；但在Emacs上，遇到這樣的情況，你都可以自己動手寫程式加功能進去，或者修改原有的操作行為，譬如說寫程式時，關鍵字、變數函數名稱、字串、註解等等你希望用不同顏色顯示，你就可以自己寫出這樣的功能；其實既然可以在其上寫程式，那你想要什麼功能都是可以辦得到的，譬如執行shell、讀寫email、呼叫外部程式（例如compiler、spell checker）、科學計算機、甚至瀏覽器都可以。

這種可以讓使用者自己“擴展、延伸”原有軟體功能的特性，在其他軟體也可以看得見，Firefox的外掛就不用說了；還有Microsoft Excel，你可以因特殊需要來寫數學運算式；很多編輯器也都可以錄製巨集，把一連串的指令錄下來，重複使用節省操作時間。

累了嗎？打打打俄羅斯方塊吧。

在Emacs裡面顯示圖檔。

當然別忘了寫程式喔，詳細看看這張圖，其中有寫程式的、有列出目錄檔案的、有執行shell的、有列出函式清單等等，甚至可以執行版本控管指令(cvs, svn...)。

問：可是我不想開發那些功能啊？
答：Emacs已經有三十多年的歷史了，很多功能都已經開發出來了，一般來說你不必擔心，只要找一找，應該都有你想要的外掛功能。想想看Firefox上面豐富的外掛吧。

哇，編輯LaTex耶，好棒。

問：哦，那如果沒有呢？
答：那就要用Emacs的開發語言"Emacs Lisp(elisp, Elisp)"來撰寫，elisp是Lisp程式語言的一個分支，時至今日其主要用途就是在Emacs上開發各種功能，事實上，Emacs的核心部分是以C撰寫，其他大部分都是以elisp撰寫；所以如果沒有你要的功能，也沒有別人要開發的話，請你自己寫吧。本篇不介紹elisp。

問：聽起來很不錯，但是，看圖、打遊戲、讀email，我只要另外執行一支軟體不就得了，為什麼一定要在Emacs內執行？還有，你說的很多編輯功能，我的編輯器也都有啊？
答：是的沒錯，但我上面說的重點是：Emacs是個強大完整的開發平台，發現不足時，就會有人開發各種外掛，這是某些編輯器沒辦法做到的。

而上面強調說“你可以在Emacs裡面做任何事！”，你可能看不出有什麼好處，讓我解釋一下其中的歷史背景，在很久很久以前，沒有『視窗介面』的那個時代，你執行編輯器寫程式，寫一寫離開，執行compiler，在shell下執行程式看看結果，然後再回去編輯器修改，累了就執行email軟體，或是西洋棋，這樣跳來跳去很麻煩，因為整個畫面會被你的軟體佔據，不像現在一個軟體有自己的一個視窗，所以自然會產生希望“一支軟體通吃”這樣的想法；雖然後來這種文字命令列模式也發展出很多機制（譬如同時使用很多個終端機畫面，還有screen這隻程式讓你在多個軟體間跳來跳去）來因應，但對於習慣視窗圖形化操作介面與滑鼠的人來說，那些機制都不夠便利，所以“你可以在Emacs裡面做任何事！”對於以前在命令列下工作的人來說是一大福音，但現在我們在各種環境(Windows, Mac, Linux...)都有圖形化操作介面了，所以這點已經不是那麼有吸引力了。

不過再強調一下，因為Emacs是個強大完整的開發平台，如果你願意學習elisp，那你可以把Emacs調整成你最喜歡的樣子，如果你不願意，也可以找到一堆別人開發出來好用的外掛。

想想看以前沒有滑鼠的時代（嗯，好像很難想像），Emacs是那種時代的產物，所有的動作都要用鍵盤完成，想想看，你要把一整塊文字做搬移的動作，沒有滑鼠游標可用，只有鍵盤要怎麼達成，很難吧；而且，Emacs還有個中心思想：讓雙手保持在打字區，利用各種按鍵組合完成任務，減少把手移動到鍵盤右邊（上下左右方向鍵、編輯鍵Delete、Page Up、Home）的機會，所以要記憶很多按鍵組合。結論就是，對於習慣滑鼠操作的人，Emacs以鍵盤為主的操作方法很古老很難學。

有了視窗介面與滑鼠，就不需要記憶一堆指令與參數；現代人用電腦時大部分時間都只需要瀏覽器與滑鼠。

問：好吧，那麼Emacs都有三十多年的歷史了，說些故事來聽聽吧？
答：這就免了吧，可以拜拜孤狗大神，或是查查維基百科吧。

問：難道都沒有其他同等的好產品嗎？
答：有的，但每個人都有不同的看法。有人不管什麼程式語言都用UltraEdit，我以前在寫C/C++時，用的是Source Insight，但我很多同事都是用SlickEdit，當我在寫簡單的Java程式時，用的是TextPad，但現在開發Java的首選Eclipse，另外還聽說TextMate(Mac)與E Text Editor(Windows)很棒（聽說其外掛能力也很強大，但我只有些許的使用經驗），我最近寫簡單的程式時，都是用NotePad++，寫大程式是用Visual Studio(Windows)與Xcode(Mac)，在unix上我還用過joe與pico，但資深的都用vi或emacs；如果你問其他人，這份編輯器清單會長到不像話，編輯器之優劣爭論似乎跟程式語言優劣爭辯一樣，永無止息之日，所以就此打住。

這張圖是Source Insight，是我第一個接觸到功能夠強大的編輯器，改用Source Insight後就再也不可能回到Visual C++ 6.0的編輯器了。

問：那你用Emacs是為了什麼？
答：雖然理想上我們希望一支編輯器走遍天下，但現實上，不同的情況會有不同的最佳選擇。而我用Emacs主要是為了學寫lisp程式（但非elisp而是common lisp與scheme），而寫lisp程式最好的開發環境似乎就是Emacs。所以我會另外寫一篇關於在Windows上安裝common lisp系統，以及SLIME（輔助開發的Emacs外掛）。

問：除了Emacs就沒有其他選擇來寫lisp程式嗎？
答：當然有，Lispbox、vim+limp、LispIDE、Jabberwocky 、Cusp on Eclipse。有空就自己試試看囉。

問：我不需要寫lisp，我的編輯器也夠強，我不想學Emacs，再見。
答：不送了。

問：好吧，我想用看看，聽說Emacs有很多版本？
答：Emacs有很多版本分支，例如GNU Emacs、XEmacs、Aquamacs等等，這篇用的是GNU Emacs on Windows。另外在Cygwin上也有GNU Emacs，但我用了覺得怪怪的，譬如一開始居然沒辦法關掉程式離開。

問：去哪下載？
答：在官方網站的下載區，可以下載原始碼，不過編譯好的Windows版已經準備好了（不支援95與NT之前的版本）。目前（寫這篇的時候）最新版本是23.2，進去後可以看到兩種檔案，一種是emacs-23.2-barebin-i386.zip，裡面只有編譯過後的執行檔，沒有elisp code以及一些文件，不是我們要的；另一種是emacs-23.2-bin-i386.zip(43 MB)，這才是完整的。

問：怎麼安裝？
答：安裝只需把檔案解壓縮即可，但解壓縮後的目錄名最好不要有空格或太長，避免發生一些奇怪的問題。因為Emacs以及相關軟體都有很深的unix背景，為避免麻煩，我採用無空格的目錄名。還有，為了配合unix的一些習慣，我在C:\下新增了一些目錄：
C:\home
C:\home\bin
C:\home\bin\emacs （Emacs放這裡，我把解壓縮後的目錄名emacs-23.2改成emacs。）
C:\home\yehnan （這是我的使用者目錄）

PS 因為我之後還要安裝lisp systems，所以才會有這些目錄，如果你不需要，只要把Emacs解壓縮到任何一個地方即可。

然後執行C:\home\bin\emacs\runemacs.exe，哇，出現了。自己拉個捷徑到桌面吧。注意，不是emacs.exe，其實也可以，但會多出一個沒用的命令列視窗。

沒錯，不用安裝，Emacs也不會在其他地方產生奇奇怪怪的檔案，你甚至可以把Emacs放進隨身碟帶著走，沒有問題。

如果你想要文字模式的話，在命令列模式下輸入c:\home\bin\emacs\bin\emacs -nw即可。

問：我改變心意了，怎麼解除安裝？
答：把剛剛那些目錄通通砍掉，還有你建立的捷徑，這樣就好了。

問：接下來呢？怎麼用？
答：嗯，你可以看看Emacs Tutorial（Emacs快速指南），就在Emacs的開始畫面上；或是GNU Emacs Manual（官方手冊），可以線上閱讀或是下載；或是看本書Learning GNU Emacs 3/E，這本書我只有大概翻過，覺得還不錯。

問：這些文件怎麼看起來怪怪的？
答：我覺得Emacs官方寫的文件都很奇怪很囉嗦，因為：

第一，寫的人把用的人都當做初學者，沒有使用編輯器的經驗、甚至沒有使用電腦的經驗。看看這段話：
"Files are named units of text which are stored by the operating system for you to retrieve later by name."，拜託，我還需要你教我“檔案”是什麼東西嗎？

第二，寫文件的人似乎停留在1980年代，裡面很多術語都很老舊了，看看這個：
" We use the term frame to mean the entire terminal screen or graphical window used by Emacs."、"The main area of the frame, below the tool bar (if one exists) and above the echo area, is called the window."，哇哩咧，你的frame是我的window，你的window又是什麼鬼？

第三，寫文件的人還在緬懷以前的時光，有些在以前算特殊的功能，已經不再特殊了，例如：
"You are reading about GNU Emacs, the GNU incarnation of the advanced, self-
documenting, customizable, extensible editor Emacs."，啥？self-documenting？哪個編輯器沒有說明文件啊？extensible, customizable？現在很多編輯器多多少少都可以客製化了。

第四，有些功能太過強大，所以解釋起來很麻煩：
"You can yank text from the kill ring into any position in a buﬀer, including a position in a diﬀerent buﬀer; the kill ring is shared by all buﬀers."，yank&kill在這裡等於cut&paste，而kill ring呢？大概是指你cut好幾次後，不會只剩下最後一次cut的東西，之前的都還在kill ring裡面。

第五，因為Emacs以鍵盤為主，雖然現在有滑鼠可以用了，可是其中心思想還是要求所有的功能動作都要能用鍵盤達到，以至於像“把一段文字圈選”這種以滑鼠可以輕易達到的功能，手冊要用好多篇幅講解鍵盤的指令。譬如說：
"Setting the mark at a position in the text also activates it. When the mark is active, Emacs indicates the extent of the region by highlighting the text within it, using the region face. After certain non-motion commands, including any command that changes the text in the buﬀer, Emacs automatically deactivates the mark; this turns oﬀ the highlighting. "，什麼鬼啊，滑鼠點一點拉一拉就好了啦。

傳說中，能學會Emacs眾多指令的人，可以得到美女的青睞。真的還假的啊？

我會建議你找找網路上的入門介紹，比較快上手，要詳細一點的話Learning GNU Emacs應該是本不錯的書，至於我嘛，我把GNU Emacs Manual當做參考手冊，不會一頁一頁看，而是碰到問題再去裡面找答案。而我接下來要做的就是幫你入門，介紹一些基本觀念。

注意：老實說我不熟悉Emacs，我只是將一些基本的東西寫下來，能夠用就好，慢慢地再去學高階一點的功能與用法。我使用Emacs最主要的目的是要寫lisp程式，並不打算將Emacs當做我唯一的編輯器。

問：首先講解一下畫面上的各個區域吧？
答：
首先，你看到的整個畫面，稱之為frame（一般的術語會稱之為window視窗），
然後在上面有一條Menu Bar（選單列，File Edit Options Buffers Tools Help），
然後是一些常用功能的Tool Bar（工具列），
最下面那一條叫做echo area（目前顯示著"For more information about GNU Emacs..."）；
在Tool Bar下面、echo area上面的整個區域稱之為window，是用來顯示編輯內容，window還包括灰色的那條Mode Line。

重點：Emacs把整個畫面叫做frame，把編輯一個檔案的地方叫做window。

問：好，接下來，怎麼新增檔案、開啟舊檔？
答：
方法一：用滑鼠把檔案從檔案總管拖曳進Emacs的畫面。
方法二：使用File->Visit New File...，新舊檔都可以。
方法二：使用File->Open File...，開舊檔。

稍微介紹一下“visit”（Emacs術語），意思是，產生出一個新的buffer，把檔案內容拷貝進去，然後把buffer內容秀在window上。接下來你就可以編輯了。

重點：所謂buffer就是一塊記憶體，Emacs把放檔案內容放進去讓我們編輯。

這裡要解說一下那條灰色的Mode Line。
最左邊的“-”，無意義。
左邊數來第二欄，代表編碼系統(Coding System)。如果是“-”，大概代表“undecided”或是“us-ascii”，表示英文，如果是“B”，代表“chinese-big5(cp950)”，表示中文，這是中文版Windows預設的編碼，如果是“U”，表示unicode，可以把滑鼠移到上面，會出現一些資訊；通常我們都不用去管，Emacs都可以正確判斷與處理。
左邊數來第三欄，代表End-Of-Line。如果是“\ or DOS”表示CRLF;“/ or Mac”表示CR;“: or Unix”表示LF。如果忘記了，就把滑鼠停在上面，會顯示資訊給你看。通常我們也不用管這個。
左邊數來第四欄跟第五欄，第四欄表示buffer是否唯讀，第五欄表示buffer是否有被修改（跟檔案內容不一樣了），“--”表示buffer未修改，“**”表示buffer有修改，“%*”表示buffer雖是唯讀但有修改，“%%”表示其他狀態。
左邊數來第六欄，通常是“-”，滑鼠停在上面會顯示檔案路徑，如果路徑是在遠方機器上，會顯示“@”。

好吧，你是不是頭昏眼花了，其實上面這些，通常我們都不用管，而且你把滑鼠移上去就知道了，不需硬記。

然後是buffer名稱，通常跟檔案名稱一樣。但有時候你會看到*Message*、*scratch* 、*GNU Emacs*、*Help*等等，這些有星號的buffer，都是Emacs內部會用到的，不用管他也不用急著把他們關掉。譬如你在echo area會看到很多訊息，這些訊息也會寫入到*Message*內。

然後是位置資訊，可能是“All or Top or Bot or nn%”，看就知道了。
然後是游標在第幾行，Lxx。

然後是所謂的Major Mode跟一些附加資訊（如果有的話），所謂major mode就是根據你在編輯的文件種類的不同，設計的編輯模式，例如“Text”、“HTML”、“Fundamental”、“C”等等。

然後是一連串的“---”，把滑鼠移上去會發現可以對window調整大小、放到最大、或移除掉；自己試試看就清楚了。

問：怎麼儲存檔案、另存新檔？
答：請問File->Save或是File->Save As...。

問：開了很多檔，到底有多少buffers啊？怎麼切換？
答：到選單Buffers就可以看到全部的buffers，點選就會切換。

問：怎麼把frame分割成多個windows用來分別顯示不同的buffers？
答：File->Split Window，可以上下分割。至於要左右分割的話，Emacs沒有把這個命令放到選單內，所以，我們終於要輸入Emacs指令囉，

左右分割的指令是“C-x 3”，C代表Ctrl，C-x代表按住Ctrl不放的同時按下x，然後放開，再按3。

任何時候，如果發現輸入指令有錯，可按C-g取消，或是按兩三次的ESC。

問：怎麼把window移除？
答：在mode line上按滑鼠右鍵即可。雖然把window移除，但buffer還是存在的。

問：那怎麼把一個buffer關閉？
答：File->Close。

問：我打錯東西要按C-z取消，怎麼反而把Emacs縮到最小了？
答：想要做undo（一般軟體都以C-z表示），Emacs的指令是C-/。

問：怎麼C-c、C-x、C-v不是複製剪下貼上啊？
答：可以到Options->C-x/C-c/C-v Cut and Paste (CUA)，打開這個模式即可。

問：怎麼搜尋？
答：C-s往下尋找，C-r往上尋找。

問：那怎麼把Emacs關掉？
答：按整個畫面右上角的叉叉，或是File->Quit，如果有未存檔的buffer，會詢問你。

問：那接下來？
答：接下來就靠你自己了，我不是Emacs高手，只是因想寫lisp程式需要用Emacs，所以把初步介紹寫下來，下面有一些參考文件，可以作為你的下一步。

聽說Emacs很難學是不是真的啊？不是，正確說法應該是：很詭異。

參考資料：
1. GNU Emacs Manual
2. GNU Emacs FAQ For MS Windows
3. Xah's Emacs Tutorial
3. 炎龍的筆記本
4. Emacs 初學者

Joel Spolsky on Software文章選

2010-06-14T22:14:00.029+08:00

不知道是從什麼時候開始讀Joel Spolsky（周思博、約耳）的文章，還記得一開始看的是中文翻譯『周思博趣談軟體』，後來開始看原文部落格Joel on Software（這裡有另有各種語言的翻譯），幾乎每篇都不放過，對他的文章與意見，我從崇拜學習到有贊成有反對，惠我良多，可惜的是在三個月前，Joel宣布不再寫部落格了（不過好像會找其他管道作另一種形式的發表），心中升起一股淡淡的哀傷感；為記錄我的一些感想，選出以下的文章，並寫下我的意見與感想。

這裡有Joel的背景介紹，簡單講就是耶魯大學畢業，在Microsoft、Viacom Interactive Services與Juno Online Services工作過後，與夥伴在紐約創立Fog Creek Software至今，其產品包括FogBugz（專業管理與臭蟲追蹤）、Fog Creek Copilot（遠端控制電腦，可穿過各種防火牆與NAT）以及其他軟體。過去十年來Joel寫過超過1000篇的文章，討論軟體開發、專案管理、軟體與商業與電腦科學等等，Joel的網站聽說是每個寫程式的、搞軟體的定期都要拜訪的。

以下是我挑的選輯，以及我的感想與看法並配上一幅漫畫。另外有點要事先聲明，有些文章都好幾年前了，有些內容仍然擲地有聲，但有部分或許以現在的觀點看來已經過時或是老掉牙了，甚或你會覺得不正確了，希望你可以想像當年的時空背景，發掘其內涵。我依照我的想法把內容有關連的放在近一點的位置，所以不是照發表日期排列。

Five Worlds，2002.05.06：
斯斯有兩種，軟體不只兩種，這篇文章將軟體分類為五種，五這個數字不是絕對的，重要的是要搞清楚你是在哪個領域開發何種軟體，誰會是使用者，搞錯就好像穿西裝去運動場，格格不入。這裡要注意的是，Joel的領域是他文中所謂的shrinkwrap軟體，是要賣給很多人的那種，當看Joel的文章時，要把這點謹記心。

User Interface Design For Programmers（共九篇），2000.04.10：
這是給軟體工程師看的使用者介面設計的入門手冊，道理雖淺但不可不知。摘錄一段：
人的資質分佈是個鐘型曲線. 你的客戶可能有98%夠聰明到能使用電視機. 大約70%能使用Windows. 有15%能使用Linux. 只有1%能寫程式. 不過卻只有0.1%能用C++之類的語言寫程式. 而只有0.01%能攪懂Microsoft ATL程式設計 (而且他們都留鬍子戴眼鏡, 沒有例外.)

The Joel Test: 12 Steps to Better Code，2000.08.09：
想增進軟體開發的效率嗎？要怎麼評量一個軟體開發的環境呢？這十二項是個簡單又具關鍵性的指標。

Daily Builds Are Your Friend，2001.01.27：
所謂"build是指將原始程式碼經過一連串的程序轉成最後的產品，隨時保持整個軟體專案在可build可執行的狀態是很重要的，人越多就越難達到，如果壞了造成的損害也越大，開發的人就沒辦法把新增修改的部份放上去，也沒辦法抓到最新狀態的程式。

Painless Functional Specifications（Part 1, Part 2, Part 3, Part 4），2000.10.02：
你覺得寫規格書是個惡夢嗎？不知道怎麼寫，寫了沒人看，不斷地要求修改，到底為什麼呢？

The Iceberg Secret, Revealed，2002.02.13：
不論你在什麼職位，你一定有"客戶"，可能是上司、主管、同儕、買家，你寫的程式總會有人要用要看要測試要審核，這篇告訴你一個秘密，客戶不知道他們想要的是什麼，千萬別預期他們能夠告訴你；文中有更多的探討與因應對策。

Top Five (Wrong) Reasons You Don't Have Testers，2000.04.30：
凡實驗必有誤差，凡程式必有bug，就我所知，號稱自己寫的程式絕對沒有臭蟲的人好像只有Linus Torvalds（linux kernel的爸爸）而已，所以，測試吧！

A Hard Drill Makes an Easy Battle，2001.11.20：
Windows有這麼多版本怎麼辦？不要以為你用的是Win32 API就可以通吃，沒測過到時候就會出現一堆奇奇怪怪的問題，測試吧。雖然這是篇很早的文章，講的是在Windows上開發軟體，但看看今日的狀況，這麼多不同血統的瀏覽器與版本，可供借鏡。

Painless Software Schedules，2000.03.29，Evidence Based Scheduling，2007.10.26：
開發進度的追蹤，是件極度不可能的任務，最常見的狀態就是不斷的delay，有人說訂schedule的意義就是用來delay的。

Painless Bug Tracking，2000.11.08：
軟體工程師不只是一直寫程式寫程式，事實上，根據統計，花在debug的時間反而是最多的，所以花點時間想想該怎麼做臭蟲追蹤吧。

Making Wrong Code Look Wrong，2005.05.11：
寫程式是件困難的事情，要盡力把各種阻礙除去，降低寫錯的機率以及提高除錯的效率與可能性，譬如採取一套正確的命名法可以幫助我們看出寫錯的程式碼，文中也點出，如果同一行程式碼可能會有不同的行為（技術上叫做context-sensitive），譬如overloading，有些程式碼的行為需要參考更多其他程式碼才能得知，譬如exception，都應該令人擔心，使用上要非常注意，因為會大大提高修改與維護的困難度。

Getting Things Done When You're Only a Grunt，2001.12.25：
就算你只是個大組織中的小螺絲，還是有很多事情你可以做可以努力，以個人的力量來讓整個專案與團隊變得更好。

How to be a program manager，2009.03.09：
你從小工程師晉升到軟體專案的管理者嗎？你知道專案管理需要哪方面的知識與技巧嗎？看這篇就對了。

The Development Abstraction Layer，2006.04.11：
不是會寫程式就能夠成立一家軟體公司的，除了技術還需要什麼呢？

Fire And Motion，2002.01.06：
一個簡單的概念，但卻不可不知，要不然被人牽著鼻子走（不斷地追求新技術）卻不知向何方而去。

Three Wrong Ideas From Computer Science，2000.08.22：
盡信書不如無書，有些不知不覺中形成的映像，有些約定俗成看似大家都同意的概念，其實可能是錯的，譬如這裡有分散式計算的一些錯誤假設，這本書講軟體工程的謬論，這篇提出三個電腦科學看似正確卻有問題的觀念。

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)，2003.10.08：
現代人不可不知Unicode、character set、encoding、code page、UTF8、UTF16、ASCII等等，這篇算是初階入門的文章，讓你有個簡單清楚的開始。

Platforms，2002.08.30：
有些人寫的軟體是"平台"，其真正的目標對象應該是"寫程式的開發人員"，而非一般的使用者，但有人（或公司）搞不清楚這點，以致於其平台無法成功。

The Law of Leaky Abstractions，2002.11.11：
整合開發工具、高階語言、低階語言、作業系統、軔體、CPU與memory、電子電路、量子力學、等等，一層一層堆砌起來的技術，經過一道又一道的抽象化手續，讓你產生錯覺，誤以為底下住著一隻精靈，有如魔術般地忠實完成你提出的需求，可是，萬一有一天，某一層有破洞，地底妖魔跑出來大亂天下，怎麼辦呢？

Lord Palmerston on Programming，2002.12.11：
很久很久以前（我指的是Peter Norton那個年代），你只要讀完一本書，大概就可以動手開發軟體了，現在，想的美喔，你要花上大把大把的時間在一拖拉庫的"物件"上打轉；有人說可以在一星期學會某某語言，但是，那又如何呢？

Can Your Programming Language Do This?，2006.08.01：
工欲善其事，必先利其器。有時候要回過頭重新檢視一下寫程式最重要的工具：程式語言，其優劣如何，是否是最適合目前工作的選擇。

How Microsoft Lost the API War，2004.06.13：
Win32 API一度是王者，造就了Windows平台上各式各樣的軟體可用，但漸漸地失去了風采，原因是什麼，因為網際網路浪潮是擋不住的嗎？難道Microsoft都沒有做任何努力？WinForm、.NET 1.0 1.1 2.0...、Avalon、Visual Basic .NET各種新的技術都無所用嗎？看看這篇吧。

Biculturalism，2003.12.14：
解釋windows一方的文化與unix一派的文化之間的不同與差異，既然用到"文化"這個字眼，沒有對兩方都有一定程度的了解是無法做出公平客觀的評價的。

The Perils of JavaSchools，2005.12.29：
談論美國電腦科學系所改採Java當做的教學語言所造成的傷害。文中論及，Java並不適合，不夠難，沒辦法在學生中區分出一流與二流的程式員；教OOP也不是，學校教的OOP只是記憶一堆術語，諸如inheritance、encapsulation、is-a vs has-a、polymorphism等等；不是說這些東西不該教或不用教，而是真正電腦科學該教的重點是proofs (recursion)、algorithms(recursion)、languages(lambda calculus)、operating systems (pointers)、compilers (lambda calculus)，真正該建立的能力是同時能以多層的抽象化方式來思考問題，有興趣的看看MIT教授在二三十年前的教學錄影，或是這裡也有Stanford最近的上課錄影，看看他們對電腦科學一年級生教些什麼。

Strategy Letter II: Chicken and Egg Problems，2000.05.24：
先有雞還是先有蛋，這問題不妨無著邊際討論一番，但是，這問題萬一發生在你的產品上，那該怎麼辦？譬如你要賣手機平台，如果很多消費者買，那就會吸引很多開發者寫軟體，如果很多開發者寫軟體，那就會吸引很多消費者買，沒完沒了，變成雞蛋問題。

Strategy Letter VI，2007.09.18：
隨著CPU越來越快，memory越來越大，寫程式似乎不需要在意效能了，錯了，新的戰場是在瀏覽器上跑著JavaScript的AJAX程式，依然還是有限制條件，網路頻寬與執行效率，但是，歷史會一再重演，有人汲汲營營於效能，有人忽略這些會被時間解決的問題（或者說，會有其他人出來解決），盡力地寫出功能更多更好的應用軟體，你覺得以長期而言，誰會贏呢？

Why are the Microsoft Office file formats so complicated? (And some workarounds)，2008.02.19：
以銅為鏡，可以正衣冠；以史為鏡，可以知興替。但世界變化的這麼快，技術演進的這麼迅速，連讓人喘口氣小憩一會兒的工夫都沒辦法了，哪來的時間讀歷史故事啊。雖說如此，但如果不了解一些技術的背後理念，不清楚前人作法之後的歷史因素，有些事情就很難理解。這篇敘述了Microsoft Office檔案格式看起來這麼古怪的原因。

Martian Headsets，2008.03.17：
闡述為什麼web發展到今日的局面，網站與瀏覽器之間多對多的關係，致使開發網站很困難，開發瀏覽器也很困難，原因就是沒有一個標準，啥？沒有標準？明明有W3C的HTML啊，錯了，看起來是，但其實沒有，原因詳見內文。

這只是我的選輯，事實上，還有很多好文章我沒有挑選進來，如果你覺得有遺珠之憾，請寫在留言板，謝謝。你可以到Joel Spolsky的網站去找其他文章，有以主題分類好了。

回憶起一次出包經驗

2010-06-13T18:46:00.002+08:00

很久很久以前，工作內容是在手機平台上寫程式，曾經出過一次包，當時六神無主，手足無措，因為執行到我的程式就當機，更慘的是一點概念都沒有，不知道哪裡錯了，一當機就驚醒我夢中人，嚇的我屁滾尿流失了魂，。

後來，光用看的看不出所以然，就把改過的跟原來正常的版本作比較，但也還是不知道錯在哪，於是出動硬體偵錯的工具，邊執行邊追，一行一行追，終於得知問題所在。

錯在compiler/linker身上。你相信嗎？

我有些global static的資料，應該要對齊(align)偶數的記憶體位址的，但卻沒有，所以存取時就會發生bus error。

我的天啊，segmentation fault倒是很常見，指標沒弄好就會存取到不該存取的記憶體，可是bus error，講正確一點是unaligned access，有學過沒看過，真是讓我學到一課啊。

後來跟幾個同事討論，雖然知道這是個compiler/linker的bug，但我們也不能去修改這些工具，所以解決方法就是改用別的方法，避開這個問題。我又想，怎麼只有我出現這個問題，把所有程式碼都掃一遍，卻這麼剛好，只有我用的寫法剛剛好compiler/linker會產出錯誤的程式碼，真是夠了。

回憶起一個很難抓的臭蟲

2010-06-12T22:25:00.006+08:00

很久很久以前，那個時候沒有iPhone、沒有Android、iPod還很大一台的時候，記得當時我的工作是在手機平台上寫程式，已經算是半熟的新人了，對於整個系統有了初步的掌握，已經可以愉快地獨自工作，不用別人的幫忙了。後來進來了一個新人，本來他跟我不同小組，不太會有交集，但同為年資最少的菜鳥，有幾個禮拜的時間我們倆被叫去品保部門支援，起初我有點小小不高興，認為那是苦力工作，不過上級有令只好遵從，我叫咱們是悲情苦命小工程師，不過後來發現那是段很不錯很有用的經驗，至少去支援的時候認識幾個正妹，嘿嘿；總而言之，在如此的因緣際會之下，後來他常常找我去幫他除錯抓臭蟲(debug)，因為實在太沒效率（聊天太大聲）、浪費人力（兩人解一題）而且又跨界管事（有應該帶他的人），沒多久就被我主管禁止，雖然大部分的問題都是因為他還不熟平台以及各種API，但還是有少數幾個很難解的bug，以下就是其中之一。

聽說"debug"這個詞的由來，是真的在電腦裡面找的一隻蟲(bug)，哇！

他開始負責維護安全認證方面的程式碼，譬如SIM卡可以設定密碼，開機時要輸入，不然就只能打緊急電話(No SIM)，而且打錯太多次，SIM還會被鎖起來。其實功能大體上都好了，不過還有bug，帶他的人就交給他解解看，說了這麼久，到底是什麼bug呢？

BUG：開機時輸入正確的SIM卡密碼，有時候正常開機，有時候卻整個重開機。

哇哩咧，老實說，以我多年闖蕩江湖上斬北海蛟龍下劈南山猛虎的輝煌戰績看來，這種bug最難解的啦！有時候出現，有時候不出現，羚羊掛角，無跡可尋，搞不清楚狀況，一整個完蛋。

SIM卡小小一片，讓你幾乎讓了它的存在。

還好小弟在下不才我是有練過的，劣者我用壞螢幕的速度可追讀書破萬卷的杜甫，打爛鍵盤的數量可比寫黑一池水的王羲之；我一試之下果然有鬼，手機時好時不好，腦中閃過幾個可能，然後再看看程式碼，心理已經有個底，於是乎我告訴他說：我抓到規則了，只要你開機，看到輸入密碼的畫面就用很快的速度輸入密碼按確定，那就有可能會重開機，可是如果你等個幾秒鐘，然後才輸入按確定，那就平平安安。哇賽，真是太佩服我自己了，然後就跟他說只能幫到這回座位了，留下他一臉狐疑直說怎麼可能會這樣，慢慢苦戰吧，呵呵。

金田一跟柯南到底誰比較強啊？我以我爺爺的名號發誓，真相只有一個！如果debug能夠跟他們倆解謎一樣厲害，那就好囉。

那到底原因是什麼呢？還好我有看過Scott Meyers的Effective C++: 55 Specific Ways to Improve Your Programs and Designs，知道裡面有這麼一條寫著：the relative order initialization of non-local static objects in different translation units is undefined，啥？

PS 在這本書第三版出現在Item 4，第二版出現在Item 47。

用書中的C++例子來說明：


class FileSystem { ... };

FileSystem theFileSystem;

在某個檔案定義了一個類別FileSystem，並且有一個global static的物件theFileSystem。

然後在另外的檔案：


class Directory {
public:
Directory();
...
};

Directory::Directory()
{
//會使用theFileSystem這個物件
}

Directory theDir;

同樣也有一個global static的物件theDir，而且這個物件的constructor需要用到另一個global static物件theFileSystem來做初始化的動作，問題是，你怎麼知道theFileSystem會在theDir之前就先準備好呢？

答案是：你不能，theFileSystem跟theDir，皆為non-local static物件，其執行各自的constructors的順序是沒有定義的。所以當theDir執行constructor時，如果theFileSystem還沒，那就當然會當機或重開機了。

所以我猜，當手機開機開到輸入密碼時，背景其實還在跑很多其他的東西，此時如果快速輸入密碼按確定，就有可能會去用到還沒有準備好的物件，造成重開機；但如果等一等，那就沒事。

哇，這真是太神奇了。

至於怎麼解決這樣的問題，那就請你看看書囉，好書，值得推薦，另外還有姊妹作More Effective C++: 35 New Ways to Improve Your Programs and Designs，學 C++不可錯過的著作喔。

葉難

Raspberry Pi的FAQs

簡介Raspberry Pi，ARM CPU加上Linux只要25美金的電腦

讀後想法：挖開兔子洞、愛麗絲鏡中棋緣（張華）

讀後想法：秘本三國志（陳舜臣）

讀後感想：教你讀懂文學的27堂課(How to Read Literature Like a Professor) by Thomas C. Foster

讀後推薦：了解「人」，你才知道怎麼設計！(100 Things Every Designer Needs To Know About People) by Susan M. Weinschenk

翻譯：話說平台（Stevey's Google Platforms Rant）by Steve Yegge

翻譯：Xcode的建置設定Build Active Architecture Only（Xcode Build Active Architecture Only ）by Keith Harrison

Cocos2D-iPhone的安裝、移除與Hello World

Cocos2D-iPhone的學習資料

寫程式用的字型

MoonScript幾支小程式

MoonScript概觀介紹

MoonScript安裝

神偷天下（by 鄭丰）讀後感

[廣告] Embedded Linux 嵌入式系統開發實務 第二版

[廣告] 馬上就能用! iPhone SDK 程式碼即可貼

翻譯：Xcode裡要用哪支編譯器─GCC還是LLVM？（Compiler Options in Xcode - GCC or LLVM? ）by Keith Harrison

一致性

別再遜了 Don't suck

[廣告] Hit BBS，在iPhone上打bbs的軟體

如何取得iPhone的UDID（識別碼）

時間是什麼？Rethinking Time in Distributed Systems by Paul Borrill

什麼都沒讀

讀後推薦：老貓學出版

讀後想法：孤劍不折（柴田鍊三郎）與祕劍．柳生連也齋（五味康祐）

一個人格格不入，格格不入的一個人。

翻譯：多型不行時（When Polymorphism Fails ）by Steve Yegge

兩個影片網站，InfoQ與Channel 9。

遞迴很重要啊

翻譯：趕羚羊之程式設計宣言（The Motherfucking Manifesto For Programming, Motherfuckers）by Zed A. Shaw

寫程式取名稱令人抓狂啊

花札（花牌、花鬪）

我的Mac軟體安裝列表 Snow Leopard

git and Beyond Compare 3 on Windows XP + Cygwin

翻譯：在家工作保持生產力的二十個方法（ Twenty Ways to Stay Productive When Working at Home） by Scott Young

我的FireFox附加元件列表

幾個我常看的YouTube頻道，練習英文聽力。

翻譯：這不是物件導向程式設計啦（What OOP Isn't ）by Benjamin Supnik

讀後介紹：情感行銷的符碼(The Culture Code) by 克勞泰爾·拉派爾

翻譯：皮諾丘難題（The Pinocchio Problem）by Steve Yegge

讀後推薦：程式設計師的自我修養：連結、載入、程式庫 by 俞甲子/石凡/潘愛民

翻譯：Windows程式設計的革命簡史(A Brief History of Windows Programming Revolutions) by Ron Burk

翻譯：C++的編譯速度(C++ Compilation Speed) by Walter Bright

翻譯：Java簡史(A Brief History of Java) by Jeff Foster

翻譯：命名專案的十項提示(10 Tips for How To Name Your Project) by J Wynia

翻譯：專案之名有什麼意涵？(What's in a Project Name?) by Jeff Atwood

Lisp + GNU Emacs + SLIME on Windows

GNU Emacs on Windows

Joel Spolsky on Software文章選

回憶起一次出包經驗

回憶起一個很難抓的臭蟲

[廣告] Embedded Linux 嵌入式系統開發實務第二版