vgod’s blog

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

自從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公開的目的，希望開放這塊寶石後，能有更多人發揮想像力發明出更有趣更有用的東西來，並徹底打破現今使用電腦的方法，一起來改變世界吧！

之前一直沒機會跟大家分享我在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.」，而三年後的今天，我非常興奮我踏出了改變世界的第一步。

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

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

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

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

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

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

程式設計師的生產力之謎

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

其實單就解決同一個問題的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呢? (笑)

(待續)

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快速鍵列表，只是我覺得比較常用的鍵而已。）

很久以前就想過要寫一篇關於文字編輯(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，只靠這一招半式就能行遍天下，實在非常值得呀。

之前在[HCI] 談人機介面設計與Usability一文中提到了usability的概念，並用了Windows的開始鈕說明了在設計UI上容易忽略的陷阱。這篇文章我會繼續探討介面設計與usability，並以效率(Efficiency)與UI設計時最重要的定律之一費茲定律(Fitts’ Law)為重點。

設計軟體的操作介面並不難，但很多時候直覺的設計並不一定能達成想像中的目的。這就是usability的研究想要了解的，到底什麼樣的設計才是「更好」的設計？什麼樣的設計其實只會讓usability變得更糟？

以menu bar為例，menu是圖形介面(GUI)的最基本元素之一，現代軟體功能越來越強大，包山包海的結果就是menu變得越來越多、越來越深，每一個menu展開後幾乎都有sub-menu，甚至還有sub-sub-menu等等複雜的選單。我每次教我爸媽用電腦時，都覺得Windows的menu根本是設計來折磨使用者的，奇妙的是竟然很少聽人在抱怨這介面很難用，而是紛紛強迫自己「學會」這種操作模式。

我想會看到這篇文章的讀者，早就很習慣於操作GUI了，也沒想過選單能有什麼好用或難用之別。所以先讓我們來想想要開啟一個埋藏在sub-menu裡的功能是多困難的工作（就假設是檔案/最近開啟/某檔案.txt好了）。第一，把游標移到menu bar的「檔案」上，並停住不動；第二，按下滑鼠左鍵打開檔案選單，把游標「垂直往下」移到「最近開啟」上停住；第三，等sub-menu打開，把游標「水平往右」移進sub-menu裡；第四，再度「垂直往下」找到某檔案.txt，在上面停住並按下左鍵。好，想像完畢後你可以試著用你的非慣用手操作滑鼠做一次看看。

如果是已經很熟悉GUI的使用者，想必都不覺得操作選單有什麼困難的，但當你被迫用非慣用手操作時，一定會感覺到操作速度大大的降低，甚至沒辦法精準控制游標進入sub-menu，這時我們才有機會體認到操作滑鼠其實並不容易。除此之外，如果仔細觀察，還可以發現進入sub-menu又比平常把游標移到任意地方還困難，因為必須把游標保持在一條狹長的「隧道」裡水平移動，如果在移動時不小心移出了這條隧道，sub-menu就會關閉。

有個有趣的案例發生在一個著名的open source影像處理軟體GIMP上（可以說是免費版的photoshop）。當初開發GIMP的團隊曾做過一個有趣的決定，他們決定拿掉固定在視窗頂端的menu bar，並用可以在任何地方按右鍵打開的context menu取代。因為context menu可以在任何地方打開，GIMP的開發團隊認為這樣可以加快存取menu的速度。這個想法很直覺，但真的對efficiency有幫助嗎？

既然我都說了這麼多，答案當然不會是yes。

context menu對efficiency並沒有幫助，反而使之變得更差。為什麼呢？

如上圖，從第一層的選單要進入第二層時，必須先經過第一層狹窄的隧道(紅色區域)，才能進入第二層選單。如果直接走直線路徑到想要按的目標，就會先經過第一層的其他項目，導致不同的sub-menu被打開。傳統的menu bar也是有sub-menu，所以直覺上可能不會覺得多一層的sub-menu會有多大影響，但事實上是這種把游標限制在一條隧道裡的設計大大的降低了操作游標的速度，和一般可以經由任意路徑指到目標的操作有指數級的速度差異。

Fitt在1954年提出了Fitt’s Law，可以說是人機互動領域的第一條「定律」，對人類指向任一目標的動作建立了一個數學模型。基本的概念是，移到目標上的時間(T)可以表示為目標距離(D)與目標大小(W)的函數。具體來說，T = a +b log₂(D/W+1)，a和b都是一個常數。

Fitt’s Law告訴我們，移到任意目標上的時間大約跟目標距離除以目標大小的對數成正比。也就是說，目標越遠移動時間就越長，目標越小時間也會越長；反之，目標越近或目標越大的話，所需時間就越短。有趣的是，距離和目標大小的影響並不算大，經過log讓這兩個變數的影響降低了一個指數等級。例如距離變長1000倍，並不會讓時間也變成1000倍，而是變成log₂(1000)，大約是10倍而已。

在軟體介面上，Fitt’s Law有個特例值得討論一番。在電腦裡的滑鼠游標，有個基本特性是其活動範圍被限制在螢幕裡，只要游標到了螢幕邊緣，無論再怎麼繼續往同一個方向移動滑鼠，游標還是只能停留在邊緣上。這個特性讓UI設計有了戲劇性的變化，一個最有趣的例子是Windows和Mac OS X的menu bar設計。

Microsoft的Windows自古以來的UI設計都是把menu bar放在視窗的title bar下面，而Mac OS採取完全不同的設計：把menu bar固定在螢幕最頂端。一般人大多覺得這兩種設計只是習慣問題，沒有什麼客觀差別，但如果你已經學會了Fitt’s Law，你覺得哪一種設計比較好呢？

如果直接套用Fitt’s Law，第一個得到的答案很可能會是Windows的設計比較好，因為當滑鼠從視窗內移往menu bar時，距離會比移到螢幕頂端還近。可是，別忘了考慮螢幕邊緣所造成的影響。Mac把menu bar放在螢幕頂端，雖然距離變長了，但目標的大小也跟著變成了「無限大」。因為螢幕的邊緣會阻擋住游標的行動，於是使用者可以盡情的把用力滑鼠往上一甩，不用停下來「對準」目標，也就等同於目標的大小變成了無窮大。在Fitt’s Law中，當W是無限大時，整個log函數得到的結果會變成0，也就是說T就會變成一個簡單的常數值a，跟距離或大小都沒有關係了。

如此比較之下，我們就可以發現Mac把menu bar放到螢幕頂端是有其用意在的，因為它大大減少了把滑鼠放進menu bar並對準目標的時間，使用者只要把滑鼠用力往前一移，自然就會進入menu bar裡面了。我在[HCI] 談人機介面設計與Usability一文中也提過Windows開始鈕的例子，跟menu bar的例子也是相同的道理。

到目前為止，我們已經看過了三種形式的menu。對於efficiency而言，我們知道Mac的設計比Windows的設計還好，那如果和GIMP的context menu比起來呢? 從Fitt’s Law可以得知，Mac的設計已經達到極限了，無論如何也沒辦法捨去那個常數a，所以我們可以直接來比Windows的設計和GIMP的設計哪個比較差XD。

前面提過，sub-menu是一種很難的指向操作，除了要把游標移到目標上，還限制了中間經過的路徑在一個隧道裡。在Fitt’s Law之後，Accot and Zhai提出了Steering law。其結論非常簡單，讓游標經過一個寬度W的隧道移動距離D的時間 T = a + b * D / W。換句話說，把移動路徑限制住的話，其移動到目標的時間和一般性移動(Fitt’s Law)所需的時間是指數級的差距，這也就是為什麼電流急急棒可以變成一個有百萬獎金的挑戰，而隨意動動滑鼠則簡單的多。

了解了Steering law之後，再回來看sub-menu的設計，你就會發現sub-menu是一個多不人道的設計。每一層的menu其實都是一個steering操作：垂直的menu移動比較簡單，因為menu寬度通常都蠻寬的；但每當要水平移動進入下一層sub-menu時，就是一個困難的挑戰，因為這時的寬度變成了menu item的高度，通常也就是一個字母高而已。和Fitt’s Law不同的是，寬度(W)變小n倍，對時間的影響不再是對數，而真的就是讓時間變長n倍。所以說呢，如果可以迅速又準確進入多層sub-menu的滑鼠高手，其實也有參加電流急急棒比賽的能力呢！

回過頭來看Windows和GIMP的menu設計，這時就可以明顯比較出來。GIMP把所有的選單操作全都變成了steering操作，Windows雖然也有sub-menu的問題，但至少第一層還是任意的指向操作，所以就efficiency來說，GIMP的設計其實是一大失策..。

最後，再順便提兩個Windows和Mac OS X對於sub-menu造成的問題所提供的解決方法。微軟和Apple都知道sub-menu很難操作，所以他們其實都有偷偷的在介面上做了一點貼心的設計。微軟的方法是，在游標要進入sub-menu時，如果不小心移出隧道外，只要在一定的時間內移回來，sub-menu就不會消失。這個方法其實有些風險，主要是因為這個「時間」很難掌控。如果這個設定的時間太短，那就沒多大效果；但如果設定太長，使用者如果是真的想要移到別的menu item打開另一個sub-menu，就會覺得系統反應太慢（就是那種頓頓的感覺）。所以，微軟的這個方法其實並不是很有效的解決這問題。

而Apple雖然也是用同樣的方法來sub-menu不要馬上消失，但他們又加上了一個聰明的設計：sub-menu的延遲消失只有在游標到sub-menu的頂端和底端形成的三角形內有效。換句話說，如果使用者是想進入sub-menu中，他甚至可以直線移動滑鼠進入其中而不會意外打開另一個不同的sub-menu（只要在設定的延遲時間內移動完成）。而假如使用者是想打開另一個sub menu，那直覺的把滑鼠往下移動就會自然的避開這個三角形區域而避免了「頓頓的」感覺。

在UI設計上，Apple一向是比其他公司用心許多。這種聰明的設計雖然很小（甚至沒什麼人會注意到），但在每天反覆的使用中就能自然減少使用者的挫折感和提昇操作的流暢度，這也是為什麼我常說Mac有許多貼心的設計，用起來會自然讓人感覺很愉快，而其他系統在UI設計上所下的功夫就明顯不足了。

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

最近被很多人提醒這個神乎其技系列停在第八集很久了…（汗）。其實這集草稿已經存很久了，今天總算決定要把它告一段落後貼出來。

先來個題外話，台灣最近遭受莫拉克颱風帶來的巨大災難之苦，雖然我人不在台灣能幫上的忙很小，但還是希望災區的所有人都能平安度過這次災難。

高中到大學

春天的國際科展結束後，我的高中生活也即將劃下句點。回顧高中三年，從校內的資訊比賽一路走到奧林匹亞的國際舞台，在保送大學資格的保護下，到高三又誤打誤撞變成國際科展的代表。雖然從結果看來一切都是如此美好，但在我剛升上高中時，沒有人知道未來會發生什麼事。我爸媽只想要我好好唸書，考上好大學；而我對學校教的科目早已失去興趣，每天都只想泡在電腦前探索這個神秘盒子的內部。於是每次考試結束，家裡就會因為我的爛成績而引發一次大戰，我爸媽也會一再的限制我坐在電腦前的時間。

就像七龍珠裡的標準情節一樣，悟空總是可以和敵人奮戰到垂死邊緣才爆發出最後一擊取得勝利，我總覺得在逆境時才能看出一個人真正的意志力和求生能力。雖然我爸媽能不斷縮減我能用電腦的時間，但他們可沒辦法限制我在學校做什麼或是面對課本時心裡到底在想些什麼。我還記得高一時，我天天都帶著Introduction To Algorithms（當時還是第一版，很多人叫它白皮書）到學校，不管上課時老師講得多麼口沫橫飛或是下課同學們玩得多開心，我都是看我自己的書。有時碰上管得嚴的老師，我就不看書開始想ACM的題目，用筆在白紙上寫code。我還記得當時為了手邊要隨時有充裕的題目可以想，我把ACM online judge上所有的題目全都印了出來放在一個資料夾裡隨時帶在身邊。

現在想想我那時瘋狂的程度真是難以想像，我當時心思幾乎完全沒放在學校課業上，就連體育課我都躲在樹蔭下想題目的解法。於是到了要升高二選類組時，家裡又爆發了第N次的世界大戰。

還記得升高二前有個考資優班的機會，我爸媽非常想要我去考考看，但我死都不答應。我很堅持的原因是，中一中的數理資優班非常奇怪，進去後就自動變成第三類組，也就是要多念一科生物，但我已經很確定未來我只想念資訊相關的科系，所以我只想選二類，不想浪費時間多念一科生物。就為了這件事，爭執的戰火延伸到我花太多時間在電腦上未來會考不上好學校之類的陳腔濫調上。

台灣父母似乎都想要孩子選擇他們覺得的安全、穩定的路，但我大概天生叛逆了點，說什麼都只想堅持自己的路。不管成功的可能性有多小，或是風險有多大，我覺得我就是應該照著心中的聲音去走。跟他們吵了一陣子後，我決定跟他們立下一個約定：讓我完全自由到高二，如果我沒辦法在資訊比賽拿到夠好的成績足以保送大學，那我到聯考前就都不碰電腦，即使我考不上大學也是我自己的決定所造成的。

從此以後，我就更認真的拼命研究演算法，研究歷年來所有大大小小資訊比賽的題目，只要我醒著的時間，腦袋就全速運轉放在這些東西上。雖然理論上我應該是背水一戰，但那時心裡其實沒有太大壓力，反而覺得可以每天都在玩自己有興趣的東西很幸福很開心，如果比賽結果不好，那可能只是說明我沒有這個天份和這個命而已。

現在回想起來，我覺得當時的我真是不怕死到了極點。要靠資訊比賽保送，至少也要進入奧林匹亞的培訓營，並成為留到第二階段的最後十人之一才有機會（有機會的意思是大學有可能會拒收…）。簡單的說就是實力大概要在全國高中生的前十名就是了。

我想我當時一定沒有想這麼多，只傻傻的做自己想做的事，所以才會這麼有勇氣立下聯考前都不碰電腦的可怕約定。還好我運氣很好，上了高二後從第一場校內賽就把我累積一年的力量爆發出來，就這樣一路打進培訓營甚至還選上國手。

順利拿到保送資格後，父母鬆了一口氣，於是就完全放任我花更多時間泡在電腦裡了。到高三時，我誤打誤撞說要參加國際科展，於是就有了正當理由請公假，各科老師對我的缺席也見怪不怪。高三我幾乎每天都待在教官室裡玩Linux、架各種系統和server來玩，雖說要做科展，但其實也是對什麼有興趣就玩什麼。（可能很多人覺得奇怪，為什麼會待在教官室… 因為教官室是少數有電腦有網路，我又能自由進出的地方。再加上當時有教官找我幫忙做網站，所以….）

到了要畢業的時候，我才發現我高三幾乎都沒踏進教室過，班上的同學我也幾乎都不認識。雖然在自己的世界裡過得很開心，但要畢業時才發現我的高中生活和其他人都不一樣。班上老師們對我也頗有微詞，所以畢業前我還碰到了一個可怕的畢業危機：我高三的學科被當了九科……。（現在想起來還真難想像，到底有哪九科啊orz…）

這件事大概是我一帆風順的高中生活中最驚悚的一件事了。雖然台大已經張開手等我進去，但要是高中不能畢業，那我不就變成比櫻木花道還悲慘的笑話了嗎…。（註：櫻木花道在全國大賽前發現被當太多科無法參賽，所以只好閉關唸書準備補考，當然最後還是順利過關去參賽，不然灌籃高手就畫不下去了。）漫畫中的主角當然不會被要補考這種小事打倒，但現實生活中誰知道呢… orz

在畢業前遭受到如此巨大的危機，實在完全出乎我的意料之外。還好當時帶我們參加比賽的指導老師非常挺我，幫我跟各科老師要一個補考的機會。學校也很好心不打算找我麻煩，就讓我把考卷帶回家寫一天。隔天交出去後我就沒再得知過關於成績的事，我甚至不知道我畢業時每一科的成績，但總之我還是拿到畢業證書了（汗）。

回想起年輕時的瘋狂，真是覺得很不可思議。如果我當時沒有堅持自己的想法，而依照爸媽的意思「好好唸書」，我想現在的我一定過著完全不同的人生，至少不太可能憑聯考進入台大資訊系，而現在也不會在MIT了..。

(待續)

Google Wave Dev Preview

昨天透過神秘管道拿到了Google Wave的developer sandbox的邀請。這看起來是對之前有參加Google I/O的人發送的開發用測試帳號，裡面處處可以看到Google I/O的影子。

第一次登入Google Wave後，乍看之下真是個讓人摸不著頭緒的東西。左邊的Navigation和Contacts看起來很像傳統gmail的介面，但神奇的是inbox裡會一直冒出來新的”wave”，但這些wave卻不是特別寄給我，而是公開給所有人的。看起來Google Wave像個大型論壇（後來發現更像聊天室，因為你可以看到討論串中每個人正在打的每一個字元慢慢出現！），裡面已經可以看到英文、日文、中文的wave，大多是正在嘗鮮的開發者們的測試文章。

wave到底是什麼呢？

Google Wave目前給我的印象像是超大型的協同工作+溝通合作平台，
Google似乎想把wave變成一種新型態的溝通媒介，可以取代傳統的email或是可多人共享的google docs。一個wave融合了許多概念，除了文字、圖片外還可以包含一種特殊的小程式wave gadget。wave gadget是開放給所有人可以自行開發的，就像igoogle gadget一樣。wave的特色是它可以讓許多人同時編輯、回應，除了可以即時看到每個人的修改外，還有一個時間軸可以回溯整個wave的編輯和討論過程。時間軸可以讓人從最初的樣子開始播放，看每個時間點有誰進來改了什麼，或是做了什麼回應，就像錄放影機一樣。

可嵌入gadget的wave

感覺的出來當wave正式推出時又會是一場新的革命，目前先一步進去的developers就像是幫Google探路的先鋒部隊一樣，除了探索可能的殺手級應用外，也幫Google開發盡可能多的wave gadget。

目前的sandbox雖然看起來已經有基本的樣子了，但速度還蠻慢的。我想這是因為這還沒有廣泛的deploy到production機器上的關係，希望正式版時就不會有這問題。

目前我可以登入的這個developer sandbox裡已經有不少開發者在裡面亂玩，有興趣想先睹為快的人，可以試試看填這個Developer Sandbox Account Request。這是我在sandbox裡面的其中一個wave找到的連結，我不保證一定可以申請到，也不知道要多久，有興趣的人就自己試試看吧。（如果成功申請到也請順便跟我說一下，這樣我才知道這個表有沒有用。）

自從昨天拿到一隻免費的android手機(G1)後，這兩天全泡在android裡。昨天花了一晚研究怎麼不插sim card啟用這隻手機(我寫了簡單的筆記，但是是用英文寫的，我懶得再用中文寫一次了，有需要的就將就著看吧)，花了幾個小時降級、取得root、升級後，就不知不覺掉入可怕的android世界裡，這也第一次讓我親身體驗到開放平台造成的震撼。

因為android手機上的軟體完全是開放的，從boot loader、firmware、OS、系統程式、應用軟體、使用介面，無一不能自行修改。雖然我很早就知道android是開放平台，但我之前並沒辦法 想像會真的自己去玩這些hack的人有多少，可是親身體驗過後就發現這世界上有能力且願意投入的強者還真不少。網路上輕易就能找到無數版本的自製系統，經過眾多高手較調和最佳化後，不管是效能或系統功能的豐富程度都遠勝手機內預設的官方版本（像是G1硬體其實有支援multi-touch，但因為Apple把持著專利，所以android官方就不能直接支援。可是這種好康終究是藏不住的，於是有不少自製系統都包進了支援multi-touch的browser…）。更奇妙的是，還有很多HTC內流出來的系統，像是還未上市的Hero，都已經有ROM流出來，甚至還有針對G1最佳化過後的版本。

相較之下，iPhone採取的封閉策略的確讓發展可能性大大受限，開發人員只能在最上層的應用程式區打轉，難以改變系統底層的程式碼。話雖如此，世界上大部分的人買手機只是為了要用它，會像我閒閒沒事一直冒著讓機器 變成磚頭的風險不斷重裝系統的人永遠是少數。android的社群力量雖然強大，但如果社群的產出和商業利益相衝突時，製造商也不會輕易採納，於是最大眾的end user就很難享用到最完美的系統了。

我大概在一年前買了Nokia N82，衝著S60、500萬畫素的相機，加上Nokia的品牌才選了它，但實際用起來其實讓我頗為失望。最大的要害是S60實在太慢，讓操作變得很不流暢，每按個鍵都要等上好幾秒才會有反應。雖然相機解析度高，但操作相機的介面卻很糟，按下快門等他對焦並照完也是要好幾秒。S60上的軟體也不容易取得， 雖然我常用的服務(像是Google系列軟體)都有S60版本，但軟體跑得慢就讓人用起來覺得很難過，所以到最後也很少使用。說了一堆缺點後，還是要提一下N82還是有不錯的地方，繼承了Nokia手機一貫的優點：很耐摔XD （手機這種東西要不摔真的很難…）

反觀G1，我原本並不預期G1會有什麼特殊的表現，看過很多demo也沒有特別深刻的印象。但實際用過後，G1超出我預期最多的地方就是它的操作順暢度，不管是web browsing、gmail、或是許多非官方應用程式在操作介面設計上都有一定水準。雖然iphone有multi-touch，但其實並不是有那麼多場合都需要用multi-touch，再加上G1可以透過自製版的軟體用到部份multi-touch的功能，所以iphone和android在我心中的地位差距已經不那麼大了。