vgod's blog

42年的鴻溝 – Dyna Book與iPad

2010-08-31T07:50:28Z

昨天睡前心血來潮翻了一下《世紀末軟體革命復刻版》，這本我一直非常喜愛的經典書籍。（註）意外翻到書中提到Alan Kay在1970年代的Xerox PARC(Palo Alto Research Center)提出Dynabook概念的那段歷史：

曾經有好長一段時間，電腦給人的印象是處理複雜運算的龐然巨物，CPU龐大不說，磁帶機、終端機…硬體設備本身便以大著稱。這些「巨物」處理的事務也是龐大的：大量的數據、大量的資料…。電腦是不折不扣的資料處理機，和人們的生活其實是八竿子打不著邊的。

1969年，一位Ohio大學的研究生Alan Kay提出了一個構想：他希望創造一「本」可以帶著跑的電腦，並且利用電腦的資料儲存和運算能力，模擬甚至取代現有的紙跟筆。這台電腦的理想體積要和紙張的筆記本相近，能夠用它來從事寫作、繪畫、個人行程編排或是財務管理、通訊，或者是用它來取代傳統的教科書等「死板」的文字。

如果書本不再只是單向地灌輸知識，而是能對讀者的迴響做出反應（從最簡單的回答問題的正確到複雜的全文檢索等），甚至讓讀者也參與創作的過程（例如透過網路，作者可以和讀者交流，而在「筆記本」上的內容可以隨時更動），那麼我們所得到的，將是一個和當時截然不同的文化 – 對「電腦」的概念不同了，以往對「書本」、「資訊」的概念也將翻新。Kay把他理想電腦稱作Dyna Book，是「動態」的「書」，而不是xx computer，等於不再把電腦當做「電腦」了。

這段歷史我很久以前就知道了，但我一直以為Dyna Book的概念是更接近於筆記型電腦的東西。但昨天看到這段文字時，我卻有了完全不同的感覺，心裡異常的激動，因為這段文字描寫的Dyna Book，似乎更像另一個東西，一個直到今年才出現的東西。上網查了一下Alan Kay當初的論文，看到這圖我才明瞭，原來Dyna Book的設計根本就不是電腦！！

1968年Alan Kay的Dyna Book，其實就是2010年Apple iPad的原型啊。

看到這讓我不禁感嘆，1970年的Xerox PARC真是個傳奇性的研究單位，從以太網路(Ethernet)、最早的個人電腦Alto、圖型使用者介面(GUI)、物件導向程式設計(OOP)和第一個物件導向語言Smalltalk都是在這被發明出來的。（附帶一提，GUI、OOP、Smalltalk的發明人其實都是Alan Kay。）可是Xerox畢竟是個做影印機的公司，PARC做出了這麼多驚世發明，雖然跟影印機都沒關係，但不論哪一樣東西持續發展下去都大有可為，結果Xerox就這樣讓這些概念被Apple和Microsoft免費拿去創造了現今的電腦王國…。

但話說回來，即使在70年代Xerox就投下資源去做Dyna Book，結果也一定不會成功。對當時的環境來說，Dyna Book的概念實在太過先進，能實現這個產品的軟硬體技術都還不存在。除此之外，當時的電腦是只有大型企業或是尖端研究機構才會有的東西，大眾還沒辦法接受每個人都需要一台有「運算能力的機器」(computing device)這件事。即使到了1993年，那個個人電腦才剛開始普及的時代，Apple推出的Newton（最早被稱為PDA的機器，話說回來也還是想實現Dyna Book所描繪的遠景），最後也是慘淡收場。

商業界有本很有名的書叫「跨越鴻溝」(Crossing the Chasm)。這本書的核心概念是說一個新科技被接受的時間可以分為五個時期，過了最早的創新期後，要先讓一群對新科技比較敏感及狂熱的「早期接受者」（early adopters）接受後，再來才能大量擴張到「早期的主流大眾」（early majority)。但很要命的是在early adopters這個區域有一個巨大的鴻溝，如果一個創新的科技不能得到夠多early adopters的支持，就會直接跌落谷底而死亡。

Dyna Book在1968年前提出的概念，一直到2010年才真正實現並跨過鴻溝讓主流大眾接受。不知道該說是Alan Kay的思想超前時代太多，還是相關科技與大眾進步得太慢…。

但話說回來，從The iPad was invented 38 years ago一文所做的比較看來，iPad已經距離Dyna Book的願景非常接近了，但還是有兩點不是那麼容易解決的問題：第一，「Kay把Dyna Book視為一個創造並閱讀資訊的裝置，但iPad主要是設計為一個閱讀裝置。」第二，「使用者要能在這個裝置上創造他們自己的程式。」

很有趣的是，這兩點都是人機互動上的難題。40年來，硬體技術的成長把iPad變得又輕又薄又帶有非常強大的運算能力，但在軟體的使用介面上一直還是沒有很大突破。尤其是讓每個使用者都有能力寫他們自己的程式(end-user programming)，更像一個終極的聖杯，能徹底解放人類使用機器的自由，但到底該怎麼做卻沒人有頭緒。（註二）

寫到這裡，不禁擔心起來，如果Alan Kay在40年前提出的概念到今天才開始要進入early majority的普及程度，那麼到現在都還沒有出現的end-user programming聖杯，究竟要多少年後才能真正普及到全人類手上呢？

註：《世紀末軟體革命》由劉燈、賀元、賴明宗所著，這三人都是台灣資訊界早期的傳奇人物。這本書有三個版本，1994年的第一版，1996的第二版，2006又出了復刻版。這本書是中文電腦書中難得一見能把物件導向和GUI相關架構與理論概念完全融會貫通再加以清晰闡述的書。如果有心想融會貫通物件導向與GUI系統核心概念的人，這本書真的值得一看再看。

註二：Alan Kay所描繪的Dyna Book主要使用者是小孩，所以說如果是以讓小孩子能創造自己的程式為目標的話，MIT Media Lab的Scratch可以說是一個很成功的里程碑。（Scratch用「積木」來寫程式的概念在今年被Google做成了App Inventor for Android，可以用同樣的方式寫Android程式。）（雖說是打Google的招牌，但其實App Inventor是MIT CSAIL教授Hal Abelson去年輪休時去Google做的。）

後記：
很多人說iPad是抄襲Dyna Book的概念，這點其實很難說得清楚到底是抄襲或是「實現共同的願景」，畢竟Dyna Book是40年前的提出的概念了。但Apple在iPad出來後不久就拒絕了Scratch的iPad app，原因是Apple不想要使用者能藉由第三方的平台來執行程式，否則使用者就可以繞過App Store取得其他軟體了（Flash主要也是因為同樣的原因被封殺）。這個決定可以看出Apple並不是想做Dyna Book，而是一個一定要先繳錢成為會員後才能開發程式的…….i板子。

iPad電子書及電子漫畫閱讀軟體試用心得

2010-07-23T07:02:48Z

最近買了iPad，老實說主要的目的是拿來看漫畫。在美國待久了最惆悵的就是很難找到中文漫畫看，現在在加州還算好，10 mile內就有一家中文漫畫租書店，但在Boston則是想都別想…。所以iPad出來後我就一直很關心拿來看漫畫的效果如何，結果之前看到了Apple IPad 漫畫迷的褔音 (含開箱及漫畫測試多圖)這篇文章，就讓我決定要來試試iPad到底能不能滿足我長久缺少漫畫灌溉的心靈。

我總共試了GoodReader、CloudReaders、Bookman、iBunko HD、iBooks這五個app。上面那文章還有提到一個Comic Reader Mobi，但據說作者之前對Apple耍了點小花招，結果被懲罰下架一年，所以現在根本就買不到了。（花15塊買的人不知道做何感想……）

這五個軟體我本來是最看好iBunko HD（他也最貴，$5.99讓我猶豫了挺久才買的），但全部試一輪下來還是覺得免費的CloudReaders拿來看漫畫最好用。
無奈CloudReaders的介面實在不太好看，讓我很想去問這個作者能不能幫他免費改寫一下，還是我乾脆自己來寫一個算了。
（本來想說花點錢買iBunko HD應該就能滿足我，但結果他很致命的不能直著讀一次掃兩頁的漫畫… 唉，為什麼ipad軟體不能要求退錢呢）

anyway，下面是試用心得的簡單記錄，就分享給有興趣的人參考了。

GoodReader

GoodReader(itunes連結)是超級強大的檔案管理和閱讀程式，除了PDF外也能看Office或是iWork的檔案，但偏偏就是不支援jpg.zip，就變得不太適合拿來看漫畫。但如果要看其他格式的文件或是看Google Docs上的文件，GoodReader是非常好的選擇。

優點：

超強大的檔案管理功能，一般電腦上能做的他幾乎都能做
可直接從Web下載檔案（內建瀏覽器）
支援超多格式txt, pdf, doc, ppt, xls, iwork 08/09, HTML, Safari webarchives
可從Mail server, MobileMe, Google Docs, Dropbox, WebDAV server, FTP server下載檔案
內建web server，可用wifi或bonjour直接上傳檔案進去
PDF閱讀器的功能非常強大，支援超連結，單頁或雙頁顯示，裁切邊緣、書籤、跳頁、搜尋
可把檔案送到其他支援的app中開啟，所以也可以把GoodReader當做一個通用的檔案管理器

缺點：

以看漫畫來說最大的缺點是不支援jpg.zip
要價0.99，但以這麼強大的功能來說實在是很便宜
PDF翻頁後的繪製速度有點慢，有時候要會閃一下背景後才會出現

CloudReaders

CloudReaders簡直是完美的漫畫閱讀器，也是我目前最喜歡的一個！
唯一缺點是沒有呈列封面的書架，主頁面只是簡單的用條列出檔名，還蠻醜的。

優點：

支援jpg.zip、jpg.rar、pdf
可直看兩頁的一半或是一頁，也可橫看兩個一頁，會聰明的把頁面塞進螢幕中。
很輕鬆就可以翻頁，可以用點的也可以輕輕滑動，單指就能看完整本漫畫
可設定翻頁方向
內建web server，可用wifi上傳檔案
免費！

缺點：

主頁面很醜。只有簡單條列出檔名和每本書的「進度條」（很妙的設計）
不支援資料夾分類。雖然支援tag分類，但使用方法不太直覺

Bookman

Bookman(itunes連結)蠻適合看漫畫的，不管PDF或jpg.zip都支援，不管單雙頁掃描都能直讀也能橫讀，而且免費。最大缺點是只能用iTunes傳檔案進去，對我來說要一直插線總是不太方便。除此之外我也不習慣他的操作方式，一般手指滑動都是翻一頁，但他會根據滑動速度決定要翻的頁數，可是無論滑多慢都沒辦法翻一頁。一定要點左下或右下才能翻一頁，操作上不太方便。

優點：

支援jpg.zip和PDF
主畫面可陳列每本書的封面
支援直式橫式和單頁雙頁閱讀的各種組合
可設定閱讀方向
用slider快速瀏覽時可同時預覽前後兩頁
免費

缺點：

一定要點畫面左下角或右下角才能翻一頁。如果用滑動的會一次翻十幾頁。
移動檔案到資料夾的方式的visibility太差。我本來一直以為沒辦法移動檔案到資料夾，用了很久才突然知道怎麼用
資料夾不能設定封面圖示
只能用iTunes sync檔案進去

iBunko HD

iBunko HD(itunes連結)是這幾個app中最貴的一個，功能上可以說是值5.99，但他的UI設計上缺點不少，導致實際上用起來不怎麼好用。

優點:

跟iBooks相同的封面呈列書架，非常漂亮
可看TXT、PDF、JPG.zip
有手動、自動書籤
可設定翻頁方向
可有多個書架
可用FTP上傳檔案
可做複雜的UI設定（點選區域大小、手指滑動速度、翻頁特效）

缺點:

不會記住放大的倍率, 想看一次掃兩頁的漫畫就只能橫著看了
FTP上傳的檔案系統跟書架是完全分離的，無法整批加入書架（但可以直接在FTP目錄中一個個閱讀，閱讀後自動加入書架）
雖然可以有多個書架，但最多只會出顯示六個
PDF中的超連結無法點選（看漫畫不重要，但看電子書就很糟）
預設的UI不好用，要滑動很大距離才會翻頁。而且設定介面也太複雜
要價5.99，不算便宜

iBooks

iBooks是不錯的PDF和epub電子書閱讀器，但不適合看漫畫。

優點：

免費，而且iPad一開始就內建了
介面最漂亮
有快速瀏覽介面
可以搜尋內文
可連接Apple的書店直接買電子書

缺點：

只支援epub和PDF
不能橫著同時閱讀雙頁
不會記憶縮放大小，不適合直式閱讀雙頁掃描的漫畫

為什麼我用Mac

2010-05-25T19:46:41Z

這篇文章其實已經醞釀很久了。起因是前幾個月看了tinyfool的为什么我认为每个程序员都应该用Mac OS X？和youxu的开发人员为何应该使用 Mac OS X 兼 OS X 小史，我當時就很想順便分享一下我的經驗，但那時忙著Sikuli實在沒法靜下心來寫文章，直到最近稍微閒下來了才又想起這件事。

我從2005升上研究所前買了第一台Mac mini到現在已經五年了，說起來其實沒有很長，但自從2005年起，我就成了非Mac不用一族。但用Mac是一回事，我要先澄清我不算是狂熱的Apple粉絲，我除了Apple的電腦外，只有跟朋友以超低友情價買過一台開學優惠送的ipod touch來玩，除此之外，我沒有iphone、沒有ipad、也沒有Apple鍵盤滑鼠以外的周邊產品。在2005年以前，我高中和大學約6年都是用Linux作為主要工作環境。我一路從Slackware、RedHat、Mandrake(後來改名Mandriva)、玩到Debian、Ubuntu，那段時期我有數台24hr online的Linux server，還換過3台laptop，但都是裝Linux。在更之前呢，從國小的386 PC算到高一將近10年就是用DOS和Windows了。

這篇文章主要想分享的是作為一個programmer使用各種作業系統開發的經驗，不是想要說服大家全改用Mac。雖然從時間上看起來我用DOS和Windows最久，但我真正開始大量寫程式是國中開始用Visual Basic的事，所以我在DOS和Windows平台的開發經驗其實算是最少的。而大學階段是我最密集寫程式的時候，所以我的經驗和使用的工具也都是以UNIX派的為主，不見得適用所有人。

我在DOS+Windows、Linux、Mac這三大主流平台上都混過一段時間，這個遷徙的歷史其實也代表了我個人心態上的轉換。

在剛開始學電腦的時候，我是純粹的使用者。我用電腦玩遊戲，國中幫老師用excel做全班的成績單，閒來無事就隨手玩玩photoshop、3D studio等軟體自娛娛人。我記得在386的DOS時代要玩個遊戲還挺不簡單，雖然很多遊戲都說只要打play.bat就可以玩了，但事實上總要修改config.sys和autoexec.bat裡的一些記憶體或音效卡的設定才能玩。所以那個時代的使用者其實大都是玩家級的人物，多少都對Adlib、EMS、XMS、可恨的640K限制有些了解才有辦法「玩」電腦。

國中開始寫程式之後，我的心態就不太一樣了。像一般玩家般玩電腦已經不能滿足我，我開始熱切的想了解電腦內部運作的一切原理，想了解每個程式是怎麼寫出來的，每個零件是怎麼運作的，每一個細節我都想知道。而我剛好就在這段時間接觸到Slackware Linux。

Slackware Linux其實是一個不太好用的Linux distribution，可能很多人也沒聽過它。現在的Ubuntu和Windows沒兩樣，一直按「next」就能裝完整個系統並開始使用。但那時的Linux裝完後可是「什麼都沒有」。沒有X11，更別提其上的GNOME或KDE；文字編輯器只有vi（不是vim）和joe；沒有make、沒有gcc、…，總之，真的什麼都沒有。那個時候裝Linux其實是為了自己架MUD server，但當時Linux的安裝教學都說裝完的一件事就是自己重新compile kernel。（因為預設的kernel很陽春，幾乎什麼driver都沒有，不自己compile的話很多硬體都動不了。）其實當時我覺得這還蠻酷的，make config打完出現數百個選項可以慢慢勾選，讓我這種想要一窺作業系統裡面在搞什麼鬼的人非常過癮。（一開始我還不知道有make menuconfig可以用，所以其中一個選項不小心選錯就會非常痛苦要整個重來……）但過了一段時間我就發現，MUD server沒架起來，但倒是很會重編Linux kernel和設定xf86config。

國中我還在用Visual Basic寫程式時，其實沒有注意到「平台」不同的影響，因為當時我只用Windows和VB寫程式，也不會其他語言，更不用提在不同平台寫程式。一直到上高中學了C，開始寫比賽的程式時，才讓我注意到Turbo C和gcc雖然都可以compile C的程式，但有某些header檔（像是conio.h）是只有Turbo C中才能用的。發現這件事後，我才突然搞懂library是什麼，還有Linux下有一堆libxxxx及libxxxx-dev的套件是在做什麼的。

Windows和Linux的關鍵差異 – 資訊透明度 – 也就在這裡顯現出來。在我學VB的時候，我把當時一本VB5的經典書籍從頭到尾全讀過了，但我竟然對library一點概念都沒有。我以為我能用的東西就是VB提供的那些元件，後來我多學了一點後發現我還能呼叫Windows API做一些VB辦不到的低階功能，我從來沒想過要去利用別人已經寫好的程式和函式來節省自己的開發時間。簡單說，我以為要造一輛車子，就是要從輪子甚至是螺絲釘自己做起。

某方面來說這是個好事，因為我的第一個VB遊戲「黑白棋」，就是這樣一個個pixel從無到有自己畫出的。但如果要寫更大的程式，每次都從輪子做起就不是個好主意了。接觸到Linux後，我也學了很多open source界的「哲學」，其中最重要的就是重用別人的輪子。

記得很久以前在Redhat和Mandrake上裝軟體非常痛苦，雖然每個程式都被包裝成一個RPM檔，但RPM之間的相依性常會讓人發瘋。每裝一個軟體都有可能會跳出數個相依的library或套件需要安裝，然後使用者必須自己去找這些相依的RPM，更糟的是這些相依套件可能會沒完沒了的依賴更多其他的套件…。（還好後來改用Debian就不用再被這個RPM地獄折磨了。）

這個過程讓我深刻的體會到，軟體應該是像金字塔一樣一層疊著一層往上蓋的，Linux套件的包裝方式清楚的讓使用者能夠看出來一個軟體是利用了哪些library建構起來的，如果自己想寫有類似功能的程式，很容易就可以找到相關的library來用。但在Windows下就不是這麼一回事了。Windows的軟體是為end-user設計的，目標使用者很可能什麼都不懂，所以發佈軟體時應該要把所需要的library或套件全部包進去變成一個龐大的自動安裝程式，使用者只要一直按下一步就可以裝完了。這讓使用者變得比較輕鬆，但同時也一些對開發者有益的細節也隱藏起來了。

Windows的軟體大多是完全不透明的，安裝時你不知道它裝了什麼，也不知道它寫了什麼到registry，更別提要知道他的某某功能是怎麼做的。但Linux是在另一個極端，每個程式的一切都是透明易懂的，RPM或DEB套件裡有什麼東西一個指令就一清二處，每個套件需要用到哪些相依套件也是明明白白。此外，Linux下的設定檔都是純文字，只要文字編輯器就可以修改，不但方便編輯，也方便寫自動化的script或是備份系統。當然，更不用提Linux下幾乎所有程式都是open source的，只要有興趣，隨時可以打開每天在用的軟體的source研究它是怎麼做的。這些事情在Windows底下則是天方夜譚，所有的細節都被自然的包裝和隱藏起來了。這種透明度的差異對於充滿好奇心的程式設計師會產生南轅北轍的影響，當你接觸的東西越開放，就能自然而然接觸和學習電腦從裡而外的各種知識；但當你接觸的東西越封閉，就只能受限於黑盒子的限制而當個單純無知的使用者。

高中時轉到Linux作為工作環境還有另一個很大的原因:「效率」。Linux的世界是架構在文字設定檔和command line工具上的，整個OS的操作都可以用command line解決。更方便的是搭配shell script或是Perl、Python這種script language，可以輕易把系統裡各種小工具結合起來完成複雜的工作。command line有個很大的好處，你每天用的操作介面，和寫自動化script的介面是完全一樣的。也就是說，你只要把每天打的指令串起來放進一個檔案，就自然變成了shell script，而日後只要執行這個script就能自動完成需要一連串指令的工作。這種工作方式滿足了我身為一個「懶人」的慾望，因為我懶得每天用手親自重複做同樣的事情，所以我寫script將這些事自動化。當script寫的越多，就會面臨越複雜的工作，這時就會想要學更多”UNIX power tools”的用法（這是O’REILLY的一本好書）或是更強大的「黏合」語言（像是Perl）來組合不同工具。透過這種正向循環，可以不斷刺激自己提昇工作效率：事情做得越快，就可以想得更多，解決更複雜的問題，進而就能學得更多，做得更快。

大學那幾年我成了虔誠的Linux command line信徒，不管是什麼樣的事情我都可以用各種小工具加上Perl或shell script來解決，而Windows在這方面就完全比不上Linux。Windows的哲學是一套軟體可以做N種事情，但如果你想做的事情不在它原本設計的功能裡，只能兩手一攤什麼事也做不了。

資訊的透明度和command line帶來的高效率讓我非常享受在Linux上工作的樂趣，然而Linux也不是沒有缺點。當我學得越多，對系統底層的好奇心漸漸被滿足後，Linux的缺點就漸漸暴露出來，其中最讓我受不了的是殘破不全的driver支援。讓我印象最深刻的是在802.11b無線網路剛開始流行時，我花了很多時間在找driver和當白老鼠compile最新的driver，重編kernel幾乎是每日例行公事。除了無線網卡外，就算是有線網卡Linux都不見得支援，最惡名昭彰的莫過於Dlink系列的卡，他們的530TX甚至還被暱稱為惡魔卡。（這張便宜的卡在當時非常流行，但偏偏在Linux上就是不能用…）

雖然我是個programmer，但我同時也是一般user。在我想要快樂用電腦看電影或上網時，還要不時的處理系統內部的問題其實有點惱人，更別提當我只想寫一般的桌面程式或是Web app時，為什麼我還得跟Linux kernel奮戰呢？

除了硬體相容性外，Linux這種過於開放的平台還有個大問題是缺乏統一且一致的user experience design，導致usability常常奇差無比，而這也是很多open source軟體普遍共有的問題。程式設計師在乎的是功能面的設計，每個人做自己想要或喜歡的功能，雖然看起來和樂融融，但很少project有專門的團隊負責思考user是誰，他們想要什麼，以及他們會怎麼用這個軟體。同樣的功能但由不同的介面呈現，帶給使用者的感覺也會有天南地北的差異，而由千百個open source軟體拼湊起來的Linux系統帶給使用者的就是千百種不同的設計和使用方式。（後來Ubuntu的出現大大的改善了這個問題，但那時我早已跳到Mac上了…。）

就在Linux的缺點慢慢浮現後，我同時也注意到身邊很多FreeBSD/Linux hacker們開始改用Mac OS X。深入了解後，我很快發現Mac是一個完美解合Linux的效率和開放，同時又兼顧了精心設計過的user experience design的平台。Mac作業系統核心是BSD的近親Darwin，上層有跟Linux相同的command line shell，所以我以往在Linux慣用的設定檔和程式（bash、screen、vim…）全都可以直接帶到Mac上使用。（更棒的是還能像在Debian下一樣用apt-get install或是port install一個指令就自動裝完所有相依套件）

而在command line的上面則是Apple設計的GUI系統，美觀、一致、充分為使用者「設計」過的介面，輕易的就打敗我在Linux上較調半天的FVWM設定。（我換過和較調過無數的window manager，從enlightenment、GNOME、KDE、Window Maker、FVWM…）除此之外，我也不用再自己重編kernel和找driver，每一台Mac都是買來後一打開就能用了。

後來Mac用久了，漸漸發現更多Mac的好處，尤其是對於programmer而言。

每一台Mac都有附Mac OS X的安裝光碟，裡面同時附帶Xcode。而只要把Xcode裝上去後，我整台Mac就已經準備好可以讓我工作了。Xcode是Apple開發的IDE，可以開發各種常見的程式語言，但其實我不用這個。我都用Xcode底層的command line工具，像是gcc、make、svn，加上OS X內建的screen、vim、perl、python、apache（只用這些的話其實連Xcode都不用裝，每一個OS X都內建），我就有了完整的程式開發環境，而且我甚至還不需要連上網路就可以有這些。除此之外，Xcode裡還附帶很多好用的開發、除錯工具，像是我最愛的Shark（非常好用的profiling和memory debug工具）、或是Malloc Debug（找memory leak的好東西）、BigTop（監看每一個process耗用的資源記錄）。

自從我轉到Mac後，後來因為需要寫跨平台程式而切到Windows時，都覺得極端痛苦。因為Windows是給一般使用者的系統，而且所有程式都是獨立分開的，每次光要把開發環境準備好就要先耗上一整天在下載和安裝。後來我學乖了直接裝cygwin弄一個假的UNIX環境出來，但cygwin畢竟還是跑在Windows上，系統設計的哲學不同讓cygwin還是格格不入。（像是Windows就是沒有用文字檔存放系統設定，所以也沒辦法用一般的文字工具自動操作；Windows也沒有提供夠多的command line工具可以控制系統；Windows也沒有符號連結(symbolic link)，我之前想用Bazaar check out一個有符號連結的repository就爆炸了…）

從Linux轉到Mac，讓我可以花更多時間專注在我想寫的程式上，而不是拿去研究driver的相容問題，或是Linux kernel新增的設定選項。對於一個應用程式或網頁程式的開發人員來說，這些底層的細節都是不重要的。雖然說Windows也把系統底層的細節藏起來了，但它實在藏的太徹底了。萬一偶爾需要看系統底層的訊息來debug，在Mac上還是跟Linux一樣直接到/var/log下grep一下就有了，但在Windows上除了「回報給微軟」外，也沒太多辦法可以自力救濟。

Mac上很多設計也改變了我使用電腦的方式。例如說QuickSilver讓我可以用鍵盤快速啟動任何程式，甚至是做更複雜的操作。Spotlight讓我不再需要思考怎麼把檔案文件分類整理到不同folder裡，需要什麼就像用google一樣只要直接用spotlight找就好了。Mac上的繪圖、設計軟體都有很貼心的設計，例如OmniGraffle的自動對齊線，可以幫忙使用者輕易設計出平衡、一致、美觀的圖像、網頁、或是圖形介面。Mac上幾乎什麼都可以自然地用drag and drop操作（例如Safari很早以前就可以把檔案拖到網頁裡上傳），但很奇怪Windows上就是有些地方可以有些不行。

整體來說，Mac是一個融合Windows和Linux雙方優點的平衡點，我可以像一般使用者一樣不費心力的操作電腦，也可以用高效率的command line處理複雜的任務，甚至是在需要的時候扮演hacker挖掘底層的錯誤訊息，或是利用Darwin Ports安裝和修改我需要的open source軟體。但除了Mac外，其實我還是有在用Linux，只是都跑在遠端的server上而已。主要原因是在沒有圖形介面時，Mac就沒有什麼優勢了。所以到現在即使我的laptop都改用Mac，我也還是會有一個terminal連到我的Linux server上。（雖然說主要是拿來掛IRC和BBS的…）

Do the right thing and do the thing right

2010-05-07T04:31:52Z

這學期糊里糊塗的就忙過去了，回頭看看blog，學期中竟然連po篇文章的時間都沒有。（順便跟有留言的讀者道歉，之前太忙也沒時間回，留言似乎就這樣積到喜瑪拉雅山上了….）

因為畢業前一定要做一次助教，剛好老闆這學期開課人少不夠，就被拉去做助教了。在MIT做助教還真不是普通花時間，難怪拿的薪水比之前做RA還多。在這當助教一學期後，有個簡單的心得：全天下的學生其實都沒兩樣，MIT的學生也沒有比台大的學生厲害。以前在台灣當鄉民，聽過很多外國月亮比較圓的謠言，最經典的像是「美國大學生都不蹺課，因為學費很貴」（才怪XD MIT學費一年三萬多美金，蹺課的也多的是），「美國名校學生都強如鬼神，人人考試都100」（才怪XD 考試出來成績也還是常態分佈；期末project也一堆做得亂七八糟，能讓人眼睛一亮的一隻手都數不滿。)

以前我也在台大當過助教，相較之下，兩個地方能讓人眼睛一亮的學生比例其實差不多。這實在蠻令人納悶的，這兩個學校的學生原本也都是各地頂尖的「強者」，但被聚集在一起後，整體程度也還是回歸到常態分佈。（這就是所謂的人外有人，天外有天，一山還有一山高？）

觀察這些強者中的強者其實是蠻有趣的事，到頭來我覺得這些人其實也是普通人，一樣要吃飯睡覺，一樣有男/女朋友，一樣有各種千奇百怪的興趣。但唯一不同的是，這些強者似乎比較知道怎麼做「對的事」。

昨天我跟其他兩個助教加教授四個人馬拉松5個小時看了四十幾組的project demo，因為題目是各組自訂的，大家應該都是選了自己最有把握最有興趣的東西做。每一組都或多或少有做出點東西，有的組雖然做的功能很單純，但他們把這些簡單的事做得非常好；有的組雖然做了很多東西，但其實大多跟我們在意的重點沒什麼關係。

馬拉松一天後，晚上有個助教就收到其中一組的抱怨信。他們說10分鐘的demo時間根本不夠，他們花了很多心思把程式修到沒有bug，還花了很多時間做了功能A、B、C、D、E，但成績竟然不到全班平均。

收到這樣的信其實還蠻囧的。他們其實不是做得不好，只是根本沒搞清楚重要的事是什麼，所以雖然花了很多力氣，但方向完全就搞錯了，不重要的事做到200%也不會變重要。此外，更糟的是他們一直都沒有意識到哪裡不對了，所以才理直氣壯的來討分數。反觀能讓人眼睛一亮的組，他們一開始就花了比較多力氣確定要做什麼才是對的，一旦確定後，雖然做的事情可能比較小，但因為做了「對的事」並且也把事情「做對了」(do the right thing and do the thing right)，成果就能讓非常人印象深刻。

一個最好的現代例子莫過於twitter。twitter的功能實在簡單到不行，在web 1.0甚至bbs時代就有一大票功能遠強過twitter的留言板或論壇網站，但twitter卻異軍突起了。原因很單純，twitter選擇了幾個對的事（WEB+限制長度的短訊+公開API），然後把他們做到最好。

Do the right thing and do the thing right雖然是很簡單的概念，但令人意外的，即使在世界上可能是天才密度最高的地方，卻還是只有非常、非常少人能同時做到。

Sikuli帶來的意義與無限的潛力

2010-01-30T07:15:54Z

這禮拜真是我人生中最瘋狂的一天了..。

自從Sikuli發表後，我本來還打算一封封回覆所有的問題，後來發現排山倒海而來的郵件和留言速度遠大過我能閱讀和回覆的量。前幾天我優先把Sikuli比較大的bug和一些平台問題修掉，昨天釋出了0.9.7讓各平台都提升到同樣的版本（只剩Linux還是沒有抓圖的快捷鍵了），整體運行的速度也提昇了不少，並且新增了一個.skl格式讓人能透過command line或double-click直接執行script。如果之前下載過舊版的朋友強烈建議升級到0.9.7。

修完緊急的bug後，我們會再陸續補上一些文件和教學，說明一些常見的問題要怎麼解決。例如說，畫面上有多個一樣的元件(像check box, radio button)要怎麼處理、如果按特殊鍵或是在不同的鍵盤排列上使用(用dvorak的人還真不少，一堆人跟我說type()在dvorak上會有問題)..。

但這篇文章中我想談的不是被上萬人盯著的壓力，而是關於Sikuli能帶來的改變，以及未來的潛力。

有些人說Sikuli看起來只是另一個按鍵精靈或是AutoHotkey，但其實Sikuli還有許多在這個直觀意義之上的潛力我們沒直接說出來。

第一，Sikuli最重要的革命是程式碼的可讀性(readability)和易用性(usability)。把螢幕截圖直接放在程式碼裡面，讓人能直接「看到」他想控制的東西，這是從來沒人想過的事情。以往的方法，不管是透過應用程式自己的程式介面(API)或是透過XPath拿到網頁裡的某個元件，都是只有程式設計師才能寫、才能讀懂的神秘外星語言。機器喜歡精確的語言，人類花越多力氣把事情描述的越清楚，機器就越容易讀懂。

可是，有沒有人想過，人類發明這麼多程式語言來操控電腦，究竟是便利了人類還是便利了電腦？現在我們每天用的程式語言，不管是C++、Java、C#、Python、Javascript..都是只有程式設計師才能寫才能讀的語言。更諷刺的是，這些「現代」語言跟五十年前就有的LISP、Fortran本質上並沒有什麼不同，一樣都是純文字，一樣要求精確嚴謹的語法，一樣是架在百層高塔的系統架構上。即使是訓練有素的程式設計師，要寫程式做些有用的事情也都得先翻翻充滿黑話的說明文件，看看需要的功能對應到什麼函式，運氣不好可能還得學個COM+之類的鬼東西才能使用。

如同我在追求神乎其技的程式設計之道（十）：程式設計師的生產力之謎中提過的一樣，即使同為程式設計師，運用電腦的效率依然會有數十倍甚至百倍的差距。如果每天都要按一百個按鈕，程式設計師可以找到適合的命令列工具使用，或是自己寫程式呼叫應用程式提供的函式，就可以用一個按鍵取代這一百個按鈕。那完全不懂程式的一般使用者呢？恐怕只能兩手一攤任由別人寫好的軟體擺佈。也就是說，即使一個人掌控了鍵盤和滑鼠，但實際上卻是被別人的軟體限制住，如此使用電腦其實完全沒有自由可言。

Sikuli的革命把寫程式的門檻降低了，人們和系統或應用程式溝通不再需要讀用黑話寫的文件，也不用搞懂底層的架構是怎麼做的，只要把平常使用鍵盤滑鼠的方式，再加上想控制目標的螢幕截圖，就可以輕易寫成能自動執行的程式。

除了好寫外，任何人看程式和圖都能很容易讀懂程式到底做了什麼事，於是Sikuli很自然就能成為一種寫教學文件的最佳媒介。以往的教學文件常常step by step列出使用者要做的事，加上使用者應該要看到的畫面，很巧的是這兩者Sikuli script都有。但比傳統的文字描述更好的是，只要把Sikuli的指令混用在文件中，或是透過簡單的對應把文字描述轉成script，這樣一份文件不只人能看懂，連電腦都能執行這些步驟並且一步步告訴你要按的按鈕在哪裡。

第二，除了直觀上的GUI自動化外，其實Sikuli更重要的意義是提供了一種把使用者操作UI的互動過程記錄下來的新方法。以程式設計師的黑話來說，這可以說是GUI操作過程的serialization，如果用一般人的方法說，這就是把人機互動過程「數位化」的一種方法。

電腦發展的過程中，一條必經之路就是把人類周遭的一切資訊全部數位化。一旦資訊被數位化，就可以輕易儲存在電腦裡，或是透過網路分享給別人，電腦科學家也才能發展更多方法來處理、分析、運用這些資料。在21世紀的今天，人們把聲音、影像、文字全都數位化了，所以我們可以輕易的複製、傳播、使用這些資訊。但在人們如此依賴電腦的今天，人和電腦的互動過程其實一直沒有一個好方法可以記錄，所以更別提要複製或是分享這種互動過程。

而Sikuli在這個人機互動領域開了一條全新的道路，這也是為什麼Sikuli的論文是出現在「User Interface Software and Technology」的會議上，而不是在討論程式語言的會議上。

人機互動的過程一旦能被一個標準的方法記錄下來，接著就能複製，就能分享，就能讓電腦自動執行或是演算這些過程。未來的應用方式有千百種，唯一的限制只是看我們的想像力而已。

第三，Sikuli把電腦視覺的研究領域，從真實世界延伸到電腦的桌面上。這點說起來真是很有趣，電腦視覺的研究人員數十年來嘗試想讓電腦能像人一樣「看」這個「真實世界」，可以像人一樣認得別人的臉，或是認得馬路長什麼樣才能讓電腦自動開車，但卻沒什麼人想到讓電腦「看」電腦自己輸出的畫面。在技術上來說，電腦螢幕上的資訊全都是電腦自己產生出來的，沒有光影問題，沒有角度問題，辨識上的難度遠低於真實世界所需的難度。以現在的電腦視覺技術來說，辨識螢幕上的東西簡直可以說是殺雞用牛刀。

Sikuli把電腦視覺和人機介面兩個研究領域打通了，有很多古老的問題（例如OCR，文字辨識）在真實世界很難解決，但在電腦桌面上卻可能可以發展出又快又準確的方法。Sikuli也可能激發更多人把電腦視覺應用到軟體介面上的創意，讓使用者介面不只是簡單使用，也能讓每個人能真正隨心所欲的操控電腦。

第四，建立在Java平台上並且open source的Sikuli，很有潛力能讓每個人都能打造給自己的專屬程式。

Sikuli不只是提供了一堆自動按滑鼠和按鍵的指令集而已，每一個Sikuli script都是一個和Python語法相容的程式。這意味著你可以使用任何的Python語法，不管是迴圈、if、定義function、或是定義class，每一個Sikuli script都是一個真正的Python程式（嚴格來說，應該是Jython，但這中間的差別並不太重要）。除此之外，Sikuli核心是跑在Java平台上，所以可以輕易的使用任何Java的函式庫。例如說，你可以用swing建立一個新的視窗包含了兩個按鈕，按下第一個就用Sikuli執行每天上班前的例行工作，而按下第二個紐則執行下班前的例行工作。會寫程式的人可以輕易混用Sikuli和現有的函式庫，把Sikuli當成和系統或其他應用程式溝通的媒介，並在上層建立自己的新介面。也就是說，這就是桌面環境的mashup，可能的應用是無限大。

雖然不懂程式設計的人，難以撰寫複雜的GUI程式或是資料處理。但Sikuli結合了現有的平台並且open source，這樣的好處是會有來自世界各地有閒有能力的人幫忙讓Sikuli變得更簡單更好用，並結合其他的程式語言或是函式庫讓寫程式的整體門檻大大降低。

雖說Sikuli現在還不是那麼完美，但我相信open source會加快Sikuli的發展，讓更多有興趣的人進來幫忙。很多技術上的問題其實都好解決，例如有人問到是不是桌面換個skin後script就廢了，或是能不能在背景執行script。這些問題其實都有好幾種可能的答案可以解決，只是有沒有必要現在就做而已。技術問題向來都不是能阻擋我的絆腳石，真正困難的只有突破自身創意和想像力的界線而已。

每個人使用電腦的方法都不同，軟體公司設計的軟體也只能按照大部分使用者的需求和習慣所設計。但不論有多少功能，總是不可能涵蓋到每個人的大大小小需求。讓每個人都能寫程式（不論他們是不是知道他們正在寫程式）是我一心嚮往的目標之一，或者說是我希望每個人都能100%按照自己的意願花最少力氣完成最多工作。但在今天的電腦環境上，不會寫程式就有太多事都無法做到，即使會寫程式的人，也不見得願意花那麼多力氣去研究讓自己未來更省力的方法。

這個問題的癥結不在於使用的人太懶惰或是不夠聰明，而是電腦太難用。一個人得經歷幾年的訓練才能熟悉這種用程式「掌控」電腦的感覺，實在太不合理。或許沒有人想研究讓寫程式變得更簡單是因為怕丟了自己的飯碗，但我偏偏就覺得每個人應該要有聰明使用自己工具的自由，而不是反過來被工具限制了自己。所以，我希望Sikuli能讓更多人把使用電腦的自由搶回自己手中，而不是被軟體工程師們掐住脖子動彈不得。

寫到最後，能參與Sikuli這個project其實最需要感謝的人是和我合作的Tom Yeh，在我進MIT前他就在跟我老闆Rob Miller討論用螢幕截圖來搜尋文件的可能性，所以其實在我還在當兵時我們就已經搭上線開始合作了。後來我到了MIT後，一連串的討論就激發出許許多多混合螢幕截圖和電腦視覺所產生的點子，其中第一個成果就是現在的Sikuli。

Sikuli Script只是這一串研究的開端和基石，在這之上其實我們還做了很多東西。例如說我們已經有一個能錄製螢幕和使用者動作的程式，可以把使用者的動作自動轉換成Sikuli Script，也就是說使用者一行程式都不用寫，只要把想做的步驟做一次，程式碼和螢幕截圖就會自動產生出來讓你修改或直接使用。用這個錄製程式，我們可以輕易的在現有的GUI系統上觀看全系統的操作歷史，甚至是自動redo某一部分操作。有這些系統做基礎，我們能做的事情實在太多了，我只怕自己時間和能力有限，沒辦法把所有的點子都做出來。所以，這也是我們把Sikuli公開的目的，希望開放這塊寶石後，能有更多人發揮想像力發明出更有趣更有用的東西來，並徹底打破現今使用電腦的方法，一起來改變世界吧！

Change The World!

2010-01-25T04:46:37Z

之前一直沒機會跟大家分享我在MIT到底在做什麼研究，但拜登上MIT首頁的一篇報導「Picture-driven computing」所賜，我這兩年的project Sikuli像原子彈爆炸一般透過slashdot和twitter以不可思議的速度擴散開來。而這幾天，剛好碰上學校每年都會舉辦的滑雪三天三夜旅行，我照著計劃坐上遊覽車到四小時車程外的緬因州滑雪。第一天晚上到旅館發現沒網路可用，只好早早上床睡覺養足隔天的精神。到了隔天中午，在雪場的餐廳吃午飯時，我想說該來試試有沒有網路用，於是拿出ipod touch連上網後，沒想到迎面而來的是近百封關心sikuli的郵件。在震驚之餘，我還沒意會過來到底發生什麼事了，直到我看到一封來自跟我同實驗室的學長Michael發給實驗室所有人的信，標題寫著:「Sikuli on Slashdot!」，接著我才意識到：啊！原來是遭到slashdot effect攻擊了！（slashdot是全世界關心科技、網路、電腦技術的人幾乎必看的網站，只要某個網站一被登上slashdot，馬上就會遭到來自世界各地數以千計的閱覽攻擊，其效果等同於分散式阻斷服務(DDoS)攻擊，而這現象就被稱為slashdot effect。我以前都以為只有網站會有突然出現的巨大流量，沒想到連我的信箱也會…）

在這件事情之前，我從沒體驗過媒體和網路的力量可以有多麼驚人。從MIT News發出的一篇報導，隔天被轉載到一小部分科技、技術網站，並且在twitter上開始有人開始口耳相傳這個新玩意。再過一天，有人把這消息推上了Slashdot: MIT Offers Picture-Centric Programming To the Masses With Sikuli，很快的sikuli這名字開始傳遍世界。我在twitter上搜尋了sikuli，想看看人們都說些什麼，結果看到由各種不同語言寫的tweet不斷湧出，就在我還沒看完一頁時又冒出「xx more tweets since you started searching」的訊息。搜尋出來的tweets除了絕對多數的英文外，也看到很多俄文、法文、日文，反倒是中文的消息最少，實在讓我有點哭笑不得。（關於訊息的傳播，我也透過這次的事件觀察到不同國家對同一事件反應的一些有趣現象，以後再另寫新文跟大家分享。）

人在偏僻的山中滑雪，突然看到這麼多人們在討論著我的project，還有信箱裡塞滿各種關於sikuli的問題，讓我興奮得不得了。當時我的心情其實完全顧不得滑雪了，但難得的旅行還抱著電腦一直坐在餐廳裡實在也有點可惜，只好趁著有網路時把每封信大略瀏覽一下，下午就趁著坐纜車上山的空檔想想怎麼回覆這些郵件。

太陽下山後，我終於按奈不住卸下裝備就拿著電腦回到餐廳裡繼續連上網，結果又是更多的郵件湧入、更多的tweets、更多的衝擊。而當初把sikuli open source的決定，也讓我接到來自世界各地開發人員的意見和回饋，有人在一天內幫我把Linux上還沒實作的幾個功能寫完並送了patch給我，也有人為了在它的64-bit Windows上執行而直接hack了沒有原始碼的二進位EXE wrapper。除了寫程式的人外，有專業的user experience designer願意加入，也有人志願幫忙移植到Linux的工作。看著這些不知道什麼時候才能回完的信，我突然發現，我似乎真的做了一件不得了的事….。

在MIT裡其實常常能看到許多很驚人的點子，但可惜的是即使在MIT，大部分的東西也都停留在為研究而做的雛形階段，研究人員雖然產出了論文，但如果沒有對的人讀到那些文章，很多好點子也不過是停留在紙上變成可回收的資源而已。

Sikuli的論文其實在去年九月就在ACM關於user interface中最頂尖的會議UIST上發表了，在當時還拿了Best Student Paper Award，但為什麼一直到今天才突然爆發開來變成人們口中「革命性的新發明」呢？

說起來這還是得感謝MIT有自己的News office，一個記者剛好問了我老闆最近有沒有什麼有趣的研究，於是sikuli這個字就從這篇報導散播開來。但除此之外，我也蠻慶幸之前自己決定要把sikuli release出去，而且老闆也很支持我這麼做，整學期都沒問我「研究」上的進度。（把程式release跟研究本身沒什麼關係，有些教授對這些研究結果的實作是否能實用也不太關心，甚至覺得做這些事是浪費時間。）

其實一般人可能很難想像，要把一個研究用的雛型打磨到能夠公開讓任何人用的程度，所花費的力氣可是遠超過寫出最重要的核心功能。我花了幾個星期研究怎麼把Java程式包成Mac上的.app，研究怎麼把.sikuli變成能夠點兩下就打開的document package，怎麼把sikuli會用到的一大包dynamic libs包進.app中讓使用者不用安裝其他的相依函式庫…。搞定Mac後，我又花了一陣子把Sikuli移植到Windows上，雖然上層是Java寫的很好解決，但有部分程式碼是透過JNI連結到C++呼叫OS提供的API才能完成的。因為我一直都用Mac開發，所以這些東西本來都只有寫Mac版的，但為了要真正讓多數人能用這個軟體，只好跟老闆要了一台PC裝上Windows來完成這些相依平台的程式碼。Windows並不是我熟悉的平台，除了國中時玩過VB外，之後就幾乎沒在Windows上寫過什麼程式了。所以為了搞定Windows的移植，除了得速成學會一些Windows API外，還得搞定DLL+EXE的包裝，最後再包成installer讓人能一路按Next就裝完整個軟體。雖然這些事情我都是第一次做，但還好沒遇到太多困難，即使每個禮拜都要花兩三天寫Distributed Algorithms的作業，剩下的時間也剛好夠我處理完這些瑣碎的工作。

完成Mac和Windows初步的包裝後，我也一邊開始做網站、API文件，也請跟我合作的Tom一起寫了一些教學文章，順便讓實驗室的同學們當一下測試的白老鼠。因為周圍沒什麼人用Linux desktop（真是有點出乎意料?），所以Linux版就暫時被我擱著沒動。
後來大家都去放聖誕假期時，我趁著空閒做了一個demo的影片放到youtube上，但因為我也還不急著釋出public beta，所以也沒跟其他人說我做了這個影片。

就在MIT News來採訪的前幾天，0xlab剛好有幾個人突然寫信問我有沒有Linux版的sikuli。雖然不知道他們怎麼發現的，但看到有人想用我也就有了勁想把Linux版趕快完成。花了一天在我新要來的PC上裝好ubuntu後（還包含一個小時在搞定這台電腦的無線網卡driver…。沒想到到了2010年我竟然還在做這種事情…），再修一修Makefile後就包了一個功能不全的Linux版放到網站上。

有句話說「機會是留給準備好的人」。當sikuli被公諸於世的時候，之前做好的事情就突然就派上了用場。MIT News促成了這個好機會讓sikuli這個很酷的想法脫離UI研究會議的小圈圈，進入世界上有網路的每個角落，這時我之前憑著一股熱血就自顧自的作了這麼多的雜事，突然都有了它的意義。於是，在機會到來時，demo的影片加上能下載試用的軟體讓人們親眼看到並且能把玩這個革命性的點子，結果就讓twitter上充滿了一大片的「holy crap this is awesome! http://sikuli.csail.mit.edu」。

我一直夢想著要做些不一樣的事情來改變世界，徹底發揮我的長處做出能夠對世界產生巨大影響力的東西。還記得三年前我在申請MIT時，在SOP上大膽的寫了我的目標「I believe that programming environments should be smarter and more intuitive, and it is my goal to reinvent one that allows beginners to learn easily and adepts to be more productive.」，而三年後的今天，我非常興奮我踏出了改變世界的第一步。

寫書計畫 – 追求神乎其技的程式設計之道

2010-01-19T06:10:11Z

人生中很多事情做起來總是比看起來難，不親身去做永遠也無法體會其中的辛酸。最近有出版社跟我聯絡，想幫我把blog內容整理成書，很湊巧的是我也動過幾次這個念頭，所以也沒想太多就答應了。

目前我的計畫是把「追求神乎其技的程式設計之道」系列文章重新整理，並且把後面還沒寫完的連載繼續完成補在書內。雖然是這麼想，但光是要擬定書籍結構就讓我和編輯們傷透腦筋。之前我在寫神乎其技系列時，把我個人的經歷以及對於程式設計一些相關的想法混合在一起，其實就是很隨興的寫。但說到要成書，事情就沒這麼簡單了。首先第一個問題就是，什麼樣的人會對這本書有興趣？是初學程式的人，還是有點經驗的人，或者是程式高手呢？之前曾經有讀者留言過說看了我的文章後都燃起熱血想動手學習程式設計了，說實在這真是超乎我的預期，但如果可以的話我也很希望有人因為看了我的書而立志成為一個優秀的程式設計師。無奈我雖然寫了很多blog文章，但談到寫書還真是第一次…。

當個沒經驗的新手，我想就是要厚臉皮一點才能快點進步。所以呢，我決定要來公開徵求讀者們的意見，讓這本書可以變得更好。

你可以簡單告訴我你的背景；告訴我你喜歡或不喜歡我這一系列文章的哪部分，為什麼？也可以告訴我哪邊可以寫得更仔細點，哪些地方想要我多補充一些細節或實例；也可以告訴我你覺得書應該怎樣編排，是要分成一篇篇獨立的散文呢，還是一氣呵成連貫到底？要保持現在這樣讓我的經歷和程式心得交織在一起，或是把他們拆成兩部分呢？

歡迎大家在本文下面留言，或是透過plurk、twitter，也直接寄信給我(vgod _AT_ vgod.tw)，任何想法都很歡迎。即使是單純推一下，或是覺得我太衝動想要阻止我的也很歡迎XD

追求神乎其技的程式設計之道（十）

2009-12-23T18:54:38Z

追求神乎其技的程式設計之道系列：一二三四五六七八九

程式設計師的生產力之謎

很多人都聽說過，同樣是寫程式，一個頂尖程式設計師和一個普通程式設計師之間的生產力可以有十倍甚至百倍的差距。這是其他行業很少見到的現象，於是不禁令人納悶，為什麼會這樣呢？

其實單就解決同一個問題的coding能力來說，差別還不至於這麼巨大。我在高中參加奧林匹亞和大學參加ACM比賽時，已經遇過全世界數一數二的coding高手，這些人每天都在練習解題和實做各種複雜的演算法和資料結構，隨便說一個演算法都能直接把code透過肌肉記憶反射出來給你。他們能在數十分鐘內想出高效率的演算法並寫成程式解決一個複雜的難題，即使我高中時已經花了一整年在訓練，依然不是他們的對手。這些人除了絕頂聰明外，每個人在高中時少說也寫過至少十萬行的code。但我發現，即使他們能解一般人解不出來的問題，打字快到鍵盤會冒煙，在做一個大系統時，這方面的差距還不一定會如此明顯。

所以我想，除了先天的智商和後天對於寫程式的熟悉度與經驗外，一定還有什麼因素造成巨大的生產力差異。

我後來發現，程式設計師和其他行業有個很大的不同點：一般行業只能在現有的工具上磨練自身的技術，但程式設計師除了磨練技術外，還可以獨自創造、修改自己使用的工具；換句話說，程式設計師的能力就是在電腦上創作出更好的軟體，不但能便利他人，也同時能增進自身使用電腦的工作效率。舉例來說，理髮師能磨練使用剪刀和設計髮型的技術，但理髮師並不知道怎麼發明及製造新的剪刀讓自己更有效率的剪頭髮；電機、化工、土木工程師要設計IC、化學製程、建築結構，但他們得依賴電腦軟體才能設計，並且靠許多大型機器和工具才能生產，即使想提昇自身的工作效率，也不是自己一個人想做就能辦到的。但軟體工程師就不同了，我們只靠一台電腦就能工作，我們的工具是軟體，我們的產出也是軟體，我們的所依賴的一切都是軟體，只要自己願意投入心力，隨時可以修改每天使用的工具和系統讓自己更有效率的工作。

這一點可以說是程式設計師的先天優勢，也是頂尖的程式設計師和普通程式設計師的生產力差距的關鍵。

Eat Our Own Dog Food

我發現厲害的程式設計師常有種共同特質：寫工具給自己用，解決自己日常工作碰到的問題或改善自己的工作效率。英文有句話叫eat one’s own dog food，字面上意思是說一家公司應該要吃自己做出來的狗食，實際上是引申為一家公司應該要在內部用自己的產品解決自身的問題，才能發現真正的問題，並且說服人這東西真的很實用。Google是奉行「吃狗食」原則的典型公司，Google內部有一個獨立的搜尋引擎搜尋公司內部網路的資料，新技術也都能在上面先行測試；Google內有獨立的gmail、google docs，都在對外公開前先讓內部的人實際用上好一陣子；Google甚至做了自己的Linux distribution給工程師用、自己的compiler、自己的瀏覽器…。

會這樣做的動機其實很簡單：如果我每天都要花10分鐘手動做同樣的事情無數次，為什麼不花一個小時寫個程式把這件事情自動化，以後可以省下更多時間做點真正有意義的事；如果我每天都要用這個彆腳的軟體，忍受他設計上的不便，為什麼不想法辦改善它或自己做一個呢？

程式設計師每天都用電腦在工作，尤其做一個系統時常常需要花時間做一些瑣碎的工作，像是編輯設定檔、把一些檔案搬來搬去、重開伺服器、清除暫存檔…等等。這些工作通常不難，但可能步驟繁雜，或是每個步驟都要等待它慢慢完成，累積起來每天就很容易浪費許多時間手動做這些無趣的事情上。

出於「懶惰」的美德，頂尖的程式設計師工作時想的不只有產出最終產品就好，而是如何花最少力氣最少時間把產品做到最好。但這件事說來容易做來難，能不能實行往往跟程式設計師工作的系統環境有很大關係。

UNIX是Programmer的天堂

如果要說我高中時期最大的收穫是什麼，我想有兩件事的重要程度不相上下：一是我確認了自己對寫程式的熱情，並且花了足夠多時間打好基礎；二是我在這段時間內摸熟了Linux，並且愛上了UNIX世界工作的哲學。

UNIX可以說是一個非常適合程式設計師工作的天堂，UNIX的工作哲學（泛指所有UNIX like的系統，像是Linux、BSD、Mac OS X..等等）是提供許多小工具，每樣小工具只做一件事，使用者可以合併使用多種工具完成複雜的工作。此外，UNIX的工具都是以command line為介面，非常適合寫script做自動化的操作。而在Windows的世界中則完全不同，Windows上的軟體傾向於提供整合式的GUI環境，把所有相關或可能會用到的功能全都一手包下，雖然方便使用者，可以點幾個按鈕就自動做完所有事情，但對於程式設計師來說其實不是一件好事。

以寫程式的工具來說，在UNIX下可以選自己喜歡的文字編輯器，不管是Vim或Emacs，也可以選自己喜歡的compiler，可以用makefile加上command line工具自動化整個程式編譯、測試、執行的流程，並且隨時都可以加入shell script或是perl script把開發流程中瑣碎的工作一併自動處理，不管需求有多麼特別，這種完全自訂的流程彈性可以說是無限大。

但在Windows環境，主流開發軟體以整合開發環境(IDE)為主，像Visual studio這種無所不包的巨獸，對於新手來說按一個鍵就能搞定一切，不用去想底下的細節，實在方便得很。可是依賴於IDE卻有個致命缺點：只要是IDE的設計者一開始沒考慮到的事，你就沒辦法做。

舉例來說，早期visual studio不支援版本控制系統(version control system)時，程式設計師就很難把版本控制整合到開發過程中（例如說在編譯成功時自動commit、或是自動加入新的原始碼…）；即使到現在visual studio已經支援了一些常見的版本控制系統，用它的人依然要看這個支援的清單包含哪些系統，如果是想用新的系統，或是用非標準的方法使用這些系統，恐怕只能遺憾的兩手一攤什麼事也不能做。有些IDE雖然有提供plugin功能（像是Eclipse），但其實也沒好到哪，因為IDE龐大無比，寫plugin的難度和所需時間遠高於使用者手動完成這些日常瑣事所花的力氣，自然不會有多少人願意去做。

簡單來說，用IDE的話，程式設計師沒辦法掌控自己用的工具，也沒辦法改善開發流程中的問題，開發效率的極限很自然會被IDE限制住。但UNIX上的環境就不一樣了，採用多種工具的組合讓自己能掌控開發流程中每個步驟。因為每個步驟和所用的工具都是透明的，只要有需求或是發現哪裡可以改善，很容易可以從滿手的工具中抓出一個來解決，或是寫個迷你的script來自動處理較複雜的工作。即使哪天有新的小工具出現（例如說一個新的版本控制系統），因為每個小工具都是獨立運作，靠程式設計師自行整合的，所以也比較容易把舊的「零件」替換掉。除此之外，open source興起後，帶有原始碼的系統更帶給程式設計師一個「完全控制」的機會，除了能替換零件外，有能力的人還能直接對零件本身做修改以符合自己的需求。種種因素加起來，讓程式設計師不再被單一個工具能力所限制，而是手中握有無數可以自由運用的籌碼，唯一的限制只有自身的創意和熱情而已。

狗食是生產力的關鍵

我一直覺得念資訊系的人不應該依賴於用IDE寫程式，當然這並不只是因為「用command line才是真男人」這種geeky的理念，而是念資訊系的應該要能擅長於「把電腦能做的事交給電腦做」。今日的軟體介面大多是以多數的日常使用者為目標，雖然方便操作，但設計者不可能把所有使用者可能會想做的工作列表做出各種排列組合放在選單裡。如果是設計者沒考慮到的功能，使用者往往也只能手動慢慢處理。但程式設計師和一般使用者是不同的，程式設計師的能力就是和電腦溝通，讓電腦用我們想要的方式幫我們完成工作。如果我每天要重複按照順序按100個不同的按鈕，為什麼不寫個程式自動按這100個按鈕？

我跟一些人聊過這個想法，但典型的反應是「正事都做不完了，哪裡有時間先做一個工具？」

但我覺得很諷刺的是，正是因為抱持這種觀念才會讓生產力低落，所以讓正事做不完，時間越緊迫就越不敢花時間做這種沒有立即產出的事情。相反地，如果在意識到自己已經三番兩次手動重複執行同樣的冗長工作時，就應該靜下來好好想想是不是有什麼辦法可以讓電腦來做這些事，只要常有這種想法，寫這些script和小工具所節省下來的時間和自己得到的經驗是一輩子都用得上的。

現在有許多open source軟體一開始都只是程式設計師為了方便自己所寫的小工具，在做正事的時候撥出時間先做好工具，然後不知不覺可能就成了偉大的軟體。最有名的例子是Knuth為了寫他的The Art Of Computer Programming，他竟然先重頭自己打造一個針對數學環境設計的排版系統，最後就成了著名的TeX。他不但完成了電腦科學界的聖經，還「順便」完成了一個經典的排版系統並分享給全世界使用。

如果持續抱持著這種態度寫程式，說不定你我也能成為下一個Knuth呢? (笑)

(待續)

給程式設計師的Vim入門圖解說明

2009-12-16T19:49:44Z

12-09 Update: The English version of Vim Visual Cheat Sheet is also available. PNG, PDF)

(更新: 在圖內加入基本指令表和說明以及PDF版，方便大家列印出來貼在牆上隨時查看。)

剛在寫那篇關於vi和文字編輯器的文章時，本來想附上一個vim的超簡單入門連結，但找了一下都沒有很滿意的，所以決定自己動手先來畫個入門用的說明圖。

PDF版下載

這個圖把vim中基本的移動方法都畫上去了，為了方便programmer，特別列出了很多只有寫程式才會用的按鍵。除了這些以外，其實還有一些好用的東西我還沒想到怎麼畫上去比較好(像是tags、沒有標準快速鍵的tab、man..)，如果大家有idea歡迎提供。

這些圖示依照移動的單位大小分為以下幾個種類，分別用不同顏色標示：
（注意，這不是完整的vim快速鍵列表，只是我覺得比較常用的鍵而已。）

字元(character)
h	左
j	下
k	上
l	右

單字(word)
w	下一個word
W	下一個word(跳過標點符號)
b	前一個word
e	跳到目前word的尾端

行(line)
0	跳到目前行的開頭
^	跳到目前行第一個非空白字元
$	跳到行尾

段落(paragraph)、區塊(block)
{	上一段(以空白行分隔)
}	下一段(以空白行分隔)
[{	跳到目前區塊開頭
]}	跳到目前區塊結尾
%	跳到目前對應的括號上(適用各種括號,有設定好的話連HTML tag都能跳)

螢幕(screen)、絕對位置
H	螢幕頂端
M	螢幕中間
L	螢幕底部
:x xG	跳到第x行(x是行號)

搜尋(search)
/xxxx	搜尋xxxx
#	往前搜尋目前游標所在的字(word)
*	往後搜尋目前游標所在的字(word)
fx	在目前行往後搜尋字元x
gd	跳到目前游標所在的字(word)的定義位置(寫程式用, 跳到定義變數/函式的地方)

分割視窗
:split	分割視窗(可加檔名順便開啟另一檔案)
:diffsplit xxx	以分割視窗和檔案xxx做比較(diff)
Ctrl-W p	跳到前一個分割視窗(在兩個分割窗來回切換)
Ctrl-W j	跳到下面的分割窗
Ctrl-W h	跳到左邊的分割窗
Ctrl-W k	跳到上面的分割窗
Ctrl-W l	跳到右邊的分割窗

自動補齊(Auto-completion) (在Insert Mode中使用)
Ctrl-N	自動補齊檔案內的下一個可能字(word)
Ctrl-P	自動補齊檔案內的上一個可能字(word)
Ctrl-X Ctrl-F	自動補齊檔名

[HCI] 淺談模式”mode”與文字編輯的技術與學習

2009-12-06T21:54:56Z

很久以前就想過要寫一篇關於文字編輯(text editing)的文章，當然我要講的不是要怎麼寫文章，而是關於使用文字編輯器(text editor)的技術。

文字編輯可以說是電腦歷史上最古老也最被廣泛使用的功能之一，無論是古老的mainframe或是現代的PC、Mac，甚至是手機，上面一定都有文字編輯的功能。人們每天都在用文字編輯器，不管是寫blog、打報告、寫程式，即使只是用twitter或plurk寫一句話，也都是在做文字編輯。既然這件事每個人每天都在用，還有什麼好談的呢？有趣的地方就在於，雖然大家每天都在用文字編輯器，但很少人會仔細去想要如何才能把這件事做得更快更好。怎樣的編輯器才是一個好用的編輯器？怎樣的編輯器用起來才能讓人感到行雲流水、人機合一的美妙境界？

我們先從一般最常見的編輯器說起。一個常見的編輯器就像Windows的記事本一樣，或是瀏覽器內預設的文字輸入區(textarea)，支援游標移動/選取、新增/刪除/修改文字、複製/剪下/貼上、搜尋/取代等基本功能。這種常見的編輯器用起來很簡單，只要在鍵盤上打字就能新增文字，按下backspace或delete鍵就能刪除文字；用滑鼠點擊任何文章內的地方游標就會移動過去；複製、搜尋等功能可以透過menu bar找到，或是利用一些約定俗成的快速鍵(Ctrl-C, Ctrl-V..)就可以在編輯文章中快速呼叫這些功能。這種編輯器的特色是學習門檻很低，要記憶的只有一些特殊的快速鍵，即使不記得也能透過menu bar或是context menu找到。

如果用之前說過的usability來分析這種編輯器，大概可以知道這樣子的UI具有容易學習(高learnability)、不容易忘記(高memorability)、不容易產生Errors、一般用起來也不會有太大不滿(satisfaction)。一切看起來都很美好，唯一的問題是，這種編輯器的efficiency到底是好還是不好？

回答這個問題前，先繼續看另一種編輯器的設計，我們才能比較不同設計的好壞。

在1976年UNIX剛誕生不久時，出現了一個特殊的編輯器叫做vi。vi引入了一個很特殊的概念：模式(mode)。

vi和一般常見編輯器最大的不同在於它有兩種模式，命令模式(command mode)和插入模式(insert mode)。在命令模式下任何鍵盤輸入都會被解讀成送給編輯器的特殊指令，例如移動游標、複製/貼上、搜尋..等等全都是送給編輯器的命令。而在插入模式下，鍵盤輸入的字會被送入編輯中的文件內，這模式也就是一般編輯器預設的模式。

在HCI的研究中，模式(mode) 是一個很常被探討的概念。在不同的模式下，使用者即使給了相同的輸入，但系統卻會產生不同結果。日常生活中最常見的例子就是汽車的排檔：在D檔時踩油門車子會前進，但在R檔時踩油門車子卻會後退。而有多種模式的UI會帶來最大的問題是mode error，也就是使用者分不清或是忘記現在系統所在的模式，而得到了非預期的結果。這種error問題可大可小，最嚴重可能就是開車時忘記在R檔而踩了油門想往前進卻撞上後面的車。也有些比較輕微的，像是在打字時忘記caps lock是開著的而不小心打出一連串的大寫文字就比較無所謂，因為看到後馬上就能回頭修正。

但如果是在看不到的時候意外開著caps lock打字呢？（像是打密碼的時候）還好最近幾年出現下面這種設計，在密碼輸入框上面顯示caps lock的狀態，用來避免打密碼時不小心開了caps lock造成的mode error。

vi引入mode到編輯器中，最大的問題就是產生了mode error的可能。也就是說，使用者如果以為他在insert mode而快樂的開始打字，但結果卻是什麼事都沒發生(除非他剛好按到a或i進入了insert mode..）。這問題也是造成vi難以入門的原因：你可以想像有許多第一次進到vi的人，打半天字卻什麼都沒有跑出來會帶來多大的挫折感。而且mode error可怕的地方在於，不是只有新手會碰上這種error，即使是vi的專家也常常會在insert mode打指令或是在command mode中打文章。（如果你在文章中看到:wq這種怪東西，就知道那人是用vi的了）

說起來mode帶來不少壞處，但它也不是沒有好處。讓我們反觀一般編輯器的”mode”設計。常見編輯器其實不是沒有mode，而是他們的mode是「暫時」的（這叫spring-loaded mode），靠Ctrl、Shift、Alt、Cmd、Win這些功能鍵來「暫時」進入命令模式。例如說Ctrl-C可以複製文字，這其實就是靠Ctrl賦予”C”這個鍵暫時的特殊功能，而取消原本在文件裡插入”C”的預設功能。用spring-loaded mode的好處是不容易產生mode error，因為使用者平常就只處在一種mode中，只有當使用者想要用特殊功能時，才必須先刻意按住某些特殊功能鍵來啟動它。spring-loaded mode的壞處在於，Ctrl、Alt、Shift這些鍵的位置在鍵盤的邊緣，再加上還必須按住不放(有時候還要兩三個鍵一起按住)，使用者常常就得用彆扭姿勢讓小指和無名指按住，造成精神與肉體上的折磨。在按住這些功能鍵的同時，快速鍵的位置還不能距離太遠才能用單手按到，所以我們才會看到最常用的快速鍵都集中鍵盤左下角(Z undo、A全選、X剪下、C複製、V貼上、F搜尋…)。

後來文字編輯器變得越來越複雜，快速鍵也大量增加，這時在有限的空間內分配快速鍵的位置並且讓使用者容易學習又不容易忘記就成了一件困難的事。現代的一般編輯器，包括很多寫程式用的IDE，大量使用各種混合Ctrl、Shift、Alt的快速鍵，這種快速鍵設計哲學是把每一個功能對應到一組複合鍵上。理所當然的，功能越多，快速鍵就越多越難記。

因為多了mode，vi和一般編輯器的命令設計哲學也非常不同。vi的哲學是把功能分解成最小單元，再把這些最小單元一一對應到不同按鍵上，最後再利用一連串的按鍵組合產生使用者想要的複雜功能。以移動游標來說，vi把這件事分得非常仔細，從字元(character)、單字(word)、行(line)、句子(sentence)、段落(paragraph)、螢幕(screen)、區塊(block)、到檔案(file)都有對應的鍵可以以不同的單位大小來移動游標，例如按w可以跳到下一個單字(word)，}可以跳到下一個paragraph…等等。乍看之下似乎很複雜，連移動游標看起來都這麼麻煩，但這樣設計的好處在後面。文字編輯還有很多動作可以做，像是刪除、剪下、複製..等等。vi把動作和操作的單位分解開來，例如：刪除(delete)是d、複製(yank)是y，這樣我們就只需要分別記憶動作對應的鍵和單位對應的鍵，就可以交叉組合出多種一般編輯器做不到的複雜功能。例如說，dw就是刪除(delete)一個單字(word)的意思，y}可以複製(yank)一個段落(paragraph)。如果你想要的話，單位前面還可以加上量詞，例如說d2w是刪除2個單字。

vi的這種設計避免了快速鍵的組合爆炸（想想看如果把各種組合都對應到一個ctrl-alt快速鍵會有多少個..），並且讓使用者能完全使用鍵盤來精確、快速的編輯一個文件，一旦熟悉這種操作後，手都不用離開鍵盤，不管是寫程式或是寫文章都有了一種人機合一的流暢感，心中想到哪裡游標就能精確移動到哪裡，不管多複雜的文字操作都能快速解決，心中的爽快感其實是難以用筆墨形容的。一般編輯器依賴於滑鼠作為移動和選取的主要工具，其實不管在learnability、memorability、errors都優於vi的鍵盤設計，但最大缺點就是efficiency很低。原因之一是，要用滑鼠一隻手就得離開鍵盤，光是這個時間用鍵盤操作的人都已經做完了（用laptop的touch pad就是另一回事了）；原因之二是，滑鼠移動是不精確的，要把游標對準某一點所花的時間遠比按下鍵盤上固定位置的按鍵來得長（請參閱之前關於Fitt’s Law的文章）；原因之三是，即使是用鍵盤控制游標，也沒辦法針對不同單位大小做控制，所以常常會看到一般使用者按住方向鍵等游標慢慢移動到某個地方..。（註：一般文字編輯器有個小技巧，這裡順便告訴大家：Windows上按Ctrl+左/右可以以一個word為單位移動，Mac上是Alt+左/右。幾乎所有可以打字的地方都能用。）

身為一個靠打字（不管是寫程式或是寫論文）吃飯的人，文字編輯可以說是我在電腦上花最多時間的工作之一。我很幸運在國中就接觸到Linux，所以也就接觸到了vim（vi後來的延伸版，是目前最流行的vi版本），沒想到這一用就用了十年…。vim也是我從國中開始用的每一台電腦裡都必裝的軟體，即使學了數十種程式語言，從Windows、Linux換到Mac，我到現在都還是用vim寫程式、寫論文、寫報告..。甚至在command line (bash)下面，都可以設定成vi mode，接著就能用vi的快速鍵來編輯指令。寫程式如果沒有vim，我等於被打斷一條腿一樣（不誇張，每次被迫在IDE裡寫程式我都有種武功被廢了的感覺…）。雖然一開始學vi/vim的門檻較高，但我很高興一開始花了點時間去學它，後來就再也不用學新的editor或IDE，只靠這一招半式就能行遍天下，實在非常值得呀。