做研究與寫論文

最近有幾篇頗有爭議的文章「陳鍾誠給李家同的一封公開信」「陳鍾誠給李家同的第二封公開信」,針對李家同批判他是現在學術界獨尊論文的始作俑者,並指出應該要有其他的研究產物或評鑑方法(像是寫一個作業系統、做一個CPU之類的)。雖然李家同常常講出令人啼笑皆非的話,但就這兩篇文章而言我還真覺得李家同挺無辜的,連學術界獨尊論文的事也怪到他頭上實在有點牛頭不對馬嘴。雖然我博士班還沒畢業,但我也寫過幾篇論文,也做過有上萬人使用的系統,我非常了解擅長實作不擅長寫論文在學術界的苦悶和無奈。但隨著我在MIT的時間越來越長,也對這個現象慢慢有了不同的看法。話說我很愛寫程式,遠勝於寫論文。我可以不眠不休的寫程式,但沒辦法這樣寫論文。如果我當初碩士畢業後直接去工作,就可以在任何我想去的公司愉快的全職寫程式,但到頭來我還是來念博士班了,為什麼?很簡單,我需要有個環境能讓我不計後果的做各種嘗試和試驗。我喜歡寫程式,尤其是沒人做過的程式(一直重複寫留言板和twitter client可不好玩)。做沒人做過的事雖然好玩,結果可能會出乎意料的好,但也有可能會大大的失敗 - 而這就是研究。在公司裡做工程師寫程式就不太能做這樣子的事情,因為公司要考量風險,可能會大成功的東西也意味著可能會大失敗,而大部分的公司沒辦法禁得起這種失敗,所以只好跟著別人的屁股走。MIT是個很酷的地方,歷史上有很多有名的系統都是在這裡誕生的,像是Ethernet、Emacs、GCC、LISP(語言和第一個compiler)...。如果說要在學術界動手做真正的系統,那MIT一定是世界上數一數二的地方。那麼在這個地方,博士班學生要如何畢業,教授要如何升等呢?很不幸的,答案是:寫論文。在資訊科學這領域,美國學校不像台灣獨尊SCI論文,事實上美國人大多不知道SCI是什麼東西,但不是這樣就代表美國不寫論文。在這邊搞電腦、資訊研究的,一樣要寫論文,而且只投到各子領域的一兩個頂尖會議去。(一個大家都知道的潛規則是,三篇頂尖會議的長論文=博士畢業)台灣有台灣的遊戲規則,美國也有自己的遊戲規則,但即使是MIT的系統hacker們,也擺脫不了寫論文的命運。(例如說,Richard Stallman其實有寫Emacs的論文,做PostgreSQL的Stonebraker也有一大票的POSTGRES論文)我以前覺得寫論文很痛苦,也懷疑有多少人會去看這些紙張(論文英文就叫paper,所以名符其實就是一堆紙),對我來說直接把程式寫出來讓人用似乎更能直接造福人們。我到現在其實還是這麼覺得,所以我花了很多時間把SIKULI open source,建立起一個community,並持續更新千百個跟研究完全無關的功能,目的就是讓所有人能更直接的享用到這個研究的成果。(而很不幸的是,做這些事情跟我能不能畢業沒什麼關係,但還好我老闆還是支持我的。)但同時,我也覺得論文的存在有其必要性。我認為做研究可以產出多樣化的「產品」,這產品可以是程式碼,可以是影片,或其他任何形式的媒介。而追朔到其核心,研究的產出最重要的是「想法」,也就是 "idea",而論文只是最簡單又最容易被其他人接受的傳播媒介而已。為什麼說論文有其必要性,就是因為論文是傳播想法最有效的媒介。論文的架構設計得讓人可以很容易抓到重點,也可以很容易的深入核心想法。如果寫過論文的都知道,論文的架構是死的,一定都有abstract、introduction、related work、conclusion等等,這種架構讓人能各取所需,要深讀或略讀都很容易。但如果說研究的產出是一個軟體系統,我們該從何了解這個系統的「想法」在哪呢?為了要讓一個系統達到「可用」的程度,整個系統裡面至少90%以上的程式碼都是純粹的工程產物,跟核心概念一點關係都沒有。而程式碼又是很難讀的東西,如果別人要了解這個研究的創新在哪,讀程式碼一定是不得已的最後手段。我絕對贊成做研究的人也得懂如何實作。很多好的idea其實老早在數十年前的論文就出現過了,但一直到現在都看不到,常常只是因為沒人去把它實作出來而已。做研究最難的事就是找到新的idea,如果只是學人家實作一個作業系統或是CPU,那也不過是照本宣科,沒什麼「研究」的價值和貢獻。像MIT這種強調"Mind & Hand"(手腦並用)的地方,很多教授都有很強的實作能力,但他們一手寫程式,另一隻手還是寫論文,因為他們知道這樣才能得到務實的經驗,而同時也能把這些貢獻和想法用最有效的方法傳播出去。如果你問我,「我在學術界,但我擅長寫程式,不擅長寫論文,該怎麼辦?」我覺得答案很簡單:如果你有很多創新的點子,那就開始練習寫作和英文,因為不管在什麼領域,如果你沒辦法好好的把想法傳達給別人,那也是孤掌難鳴;如果你沒有什麼點子,只是喜歡寫程式,那更簡單了,趕快quit去做工程師專心享受寫程式的時光吧。延伸閱讀:我看李家同的是與非。此文的觀點跟我很接近,所以他講過的很多東西我就不再重複了。附帶一提,最近在facebook上成立了粉絲頁,歡迎大家加入多多交流!阅读全文

追求神乎其技的程式設計之道(番外篇)

我的學習過程

還記得小時候我和我弟上過一個奇特的數學補習班,叫做「功文數學」。他們的「教學」方法非常特別,不像一般的教室會有一個老師在講台上教課,而是每個人會拿到一疊數學題目,每一面都有數個計算問題,像...阅读全文

追求神乎其技的程式設計之道(十一)- 抽象化與命名

追求神乎其技的程式設計之道系列休眠已久的神乎其技系列又復活了!這篇文章其實寫很久了,只是一直斷斷續續到今天才完成它,久到讓很多人覺得這系列已經完結了...。但我想只要我還有在寫程式,這系列就永遠不會結束吧。

簡潔、彈性、效率

我一直覺得寫程式是一種藝術活動。程式語言是一種要求極度精確的表達方法,只要少打一個字母就可能造成完全不同的結果,但同時卻又不限制你要如何達到目標。程式設...阅读全文

42年的鴻溝 – Dyna Book與iPad

昨天睡前心血來潮翻了一下《世紀末軟體革命復刻版》,這本我一直非常喜愛的經典書籍。(註)意外翻到書中提到Alan Kay在1970年代的Xerox PARC(Palo Alto Research Center)提出Dynabook概念的那段歷史:
曾經有好長一段時間,電腦給人的印象是處理複雜運算的龐然巨物,CPU龐大不說,磁帶機、終端機...硬...
阅读全文

為什麼我用Mac

這篇文章其實已經醞釀很久了。起因是前幾個月看了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的...)阅读全文

Change The World!

之前一直沒機會跟大家分享我在MIT到底在做什麼研究,但拜登上MIT首頁的一篇報導Picture-driven computing」所賜,我這兩年的projectSikuli像原子彈爆炸一般透過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文章,但談到寫書還真是第一次...。當個沒經驗的新手,我想就是要厚臉皮一點才能快點進步。所以呢,我決定要來公開徵求讀者們的意見,讓這本書可以變得更好。你可以簡單告訴我你的背景;告訴我你喜歡或不喜歡我這一系列文章的哪部分,為什麼?也可以告訴我哪邊可以寫得更仔細點,哪些地方想要我多補充一些細節或實例;也可以告訴我你覺得書應該怎樣編排,是要分成一篇篇獨立的散文呢,還是一氣呵成連貫到底?要保持現在這樣讓我的經歷和程式心得交織在一起,或是把他們拆成兩部分呢?歡迎大家在本文下面留言,或是透過plurktwitter,也直接寄信給我(vgod _AT_ vgod.tw),任何想法都很歡迎。即使是單純推一下,或是覺得我太衝動想要阻止我的也很歡迎XD阅读全文