工作雜記：2007/05

發覺自己在工作上，若找不到比較大的目標，很容易因失去方向感而倦怠。

從記事本中，可以看到這個月主要的工作事項。嗯... 自己在 5/16 就把論文初稿交給項老師了。少了這麼大的一個工作項目，難怪這兩個星期都覺得有些茫然。

生命似乎充滿了矛盾。物質匱乏時，以為豐衣足食就是幸福美滿；衣食無缺，卻又發現日子無聊難耐。貧困的生命積極進取，富足的生活慵懶無助，存在到底為了什麼？
_{--- 摘自《道德：幸福的必要條件》}

但其實日子過得匆忙，每天都有許多「必要的雜事」得做。

其中比較重要、有一些時間緊迫性的工作項目，就是利用先前開發的 THDL Prototype System，把圖書館特藏組的一些需求實作出來。為什麼要做這件事？因為項老師發現，特藏組的系統外包給廠商後，最後通通都「很難使用」。

而我因為論文剛寫完，心情正好，就「相當有效率」地在兩三天內，就把最基本的檢索需求用 THDL Prototype 給弄出來了。

於是，接下來就有更多的事情可做：因為圖書館所給的 metadata 有著許多錯誤_{（這是現實中很重要的定律：人工處理必會有錯）}，因此我就必須找機會向辛苦的編目人員解釋，她們可以怎樣運用資訊處理技術，改善現有的流程與產出物的品質_{（通常這些流程會因為「太細節」而被大官們所忽略，但其實沒有這些細節，就很難得到好品質的產品）}。

有人曾問我一個問題：為什麼公家機關的許多系統，外包出去之後，一開始看起來沒什麼問題，但最後做出來的東西就是「不能用」、「不堪用」、「不好用」？

大哉問。撇開政治因素不談_{（公家機關想當然政治優先，自古皆然）}，我覺得這個問題彰顯出落實軟體工程的許多困難。

遇到困難，其實也正彰顯這個問題的重要。雖然這個問題遠超過我目前所知所能，但與其束手無策、甚至相互推卸責任，不如深切思考問題的本質_{（包含問題的抽象本質與實務考量）} ，並且實際動手去做_{（邊學邊做、同時也邊做邊學）}，不是嗎？

為什麼我還頗喜歡 PHP5

為什麼我近來頗喜歡用 PHP5 來寫些「不大不小」的程式？

我猜想，最主要的理由，應該是 PHP5 體積不胖、夠簡單、也夠便利。此外，自己目前所寫的程式與系統，利用現成元件與資料庫來開發後，通常也不算太複雜。

為了防止世界被破壞、為了守護世界的和平，我們不得不將各種應用程式的變異性考慮在內 --- 我們在實務上需要有一套通用的程式開發環境。

就個人的喜好，我比較欣賞「小而美、便利性好、實用性強、且各類延伸環境支援度高」的程式語言與開發工具。雖然從程式語言的角度來說，PHP5 並不算很美；但從理論與實務兼顧的角度來看，我覺得它是一個相當好的工具，頗適合被用來快速開發一般的網頁應用程式。

有人說，PHP 不是相當「髒亂」的程式語言嗎，為什麼我不選用 Java、C#、或者像是 Python、Ruby 之類的語言？但我認為，PHP5 其實也支援了物件導向的語法，寫程式會弄到「髒亂」的地步，通常是程式設計者自己的訓練不夠、習慣不好、經驗不足，似乎不應該把責任推到程式語言的頭上。

這幾年來，主流的程式開發，使用的工具應該是 Java 與 .NET framework （新近的 Python 或 Ruby 或許也能算上「半個主流」），但 PHP 的使用者似乎也不少。跟隨「主流」有個優點，就是「使用者多，就比較能夠吸引目光，取得較多資源」。而大家都這麼選擇，通常也暗示「若跟著這樣做，相對的風險並不會太高」。

另外，現代的電腦運算能力強，而一般常見的 Web Applications 通常並不需要太多的數學計算（什麼叫做龐大的數學運算？嗯... 算 Ackermann's function 的值應該就算吧 :p）。一般說來，繁瑣的中文編碼的轉換、網頁內容的編排、人員帳號的控管、資料庫內容的讀寫（通常是字串的處理，而非數值的運算），就會佔去大半設計與開發時間。

當然，還是有許多工作，需要用到龐大的運算能力。遇到這種狀況，通常的解決方式是，先把耗時的運算結果先存起來，當使用者發出 request 時，就用「查表」的方式來減少所需的即時運算。

這樣，若不是想把 scale 弄到「非常大」，就應該能解決大半的實務問題了。至於「理想中的程式語言，應該有什麼樣貌」這類問題，就留給理論學者去爭辯囉。

摘錄：關於寫作的一些要領

這是路易斯 (Clive Staples Lewis，「納尼亞傳奇」的作者) 關於寫作的建議。
_{--- 內容取自：「父親給孩子成就一生的 100 封信」(The Father Drives The Life For The Child 100 Letters)。}

• 語言必須簡潔有力，能夠清晰地表達文章的主旨。千萬不要讓自己的句子寫出來之後走樣，甚至讓別人誤解。


• 寧願用直接而淺白的語句來表達，放棄使用冗長而模糊的詞藻。儘量遵守規則，但不必墨守成規。


• 如果有具體的詞語可以使用，就不要用那些抽象的詞句。例如你要表達「很多人死了」，最好不要寫成「玫瑰紛紛凋謝」。


• 在文章當中，如果你要描述對一種事物的感覺，一定要細緻具體。你希望讀者產生怎樣的感覺，不要只用形容詞就完事了。
  
  比如說，你說一樣東西很可怕，你要多加描述，使讀者也產生「害怕」的感覺；你要表達高興的事情，不要只是說「很高興」、「很喜悅」。任何可怕的、美好的、醜惡的、優美的事情，如果只是一筆帶過，怎麼能使讀者感同身受呢？


• 用詞不要過於誇張。比如說，該用「很」、「非常」這類詞彙的時候，就不要使用「無與倫比」、「不可思議」。不然，等到真正該誇大的時候，你就不知道要用什麼詞彙來描述了。

我覺得 Lewis 的建議相當中肯平實。問題是... 說來容易做來難啊。這些建議看起來沒什麼，但實際上要切實做到，沒有經常練習或深厚的寫作功力，恐怕都不易達成呢。

十分之一的網站很危險？

在中文 CNET 網站上看到一則新聞：「Google：十分之一的網站很危險」。

新聞的內容說，Google 對 450 萬個網站做了深入分析，發現其中每十個網站就有一個可能順便把木馬程式病毒成功下載 (drive-by-download) 到訪客的電腦裡。

我對這個比例感到好奇與不解。對於「網站」或「網頁」而言， 10% 都算是相當大的比例耶。因此多花了些時間，找到 CNET 的英文網頁，以及那篇 Google 的報告_{（ The Ghost in the Browser: Analysis of Web-based Malware）}。

翻譯的人並沒有錯，英文網頁上也是這麼寫：Google: 10 percent of sites are dangerous。網頁下的讀者意見，有的是建議使用者改用 Mac，有的是批評 Google 只說不做，任憑這些網頁為非作歹。

在好奇心的驅使下，今天早上「很難得」地看過 Google 的這篇論文，然後...

然後，發現新聞的報導是錯的。

不是「10% 的網站裡有『有害連結』_{（在此不用『惡意連結』這個詞，是因為網站可能非惡意，但卻含有這些連結）}」，而是「數十億個 (several billions) 網頁 URLs 中，經 heuristically 篩選後的 450 萬個 URLs 中，約 10% 含有這類連結」。

只是，若只是看論文的某個段落，還真的頗容易被誤導：

... we have conducted in-depth analysis of about 4.5 million URLs and found 450,000 URLs that were engaging in drive-by-downloads. ... That means that about about（原文似乎是因為筆誤，多寫了一次 about） 10% of the URLs we analyzed were malicious ...

要算出「有多少比例的 URLs 內含有害連結」_{（論文中沒有提到有多少比例的「網站」內含有害連結）}，必須回溯到論文第二頁的一段文字：

We analyzed the content of several billion URLs and executed an in-depth analysis of approximately 4.5 million URLs. From that set, we found about 45,000 URLs that were successfully launching drive-by-downloads of malware binaries ...

看吧，45 萬（確認有害的 URLs）除以幾十億（Google 索引到的 URLs），其實比例還不到 0.05% 呢！_{（當然啦，沒被篩選出來的 URLs 也有可能內含有害連結，所以真實比例有可能會高上許多。）}

所以啊，網路新聞還真的很容易誤導大眾呢。令我好奇的是，Google 怎麼沒有（在第一時間）出面澄清呢？這麼龐大的公司，還標榜不會「do evil」，卻任由大眾莫名其妙地散佈不實謠言（或甚至被資安業者加油添醋後造成心理上的恐慌），實在也說不過去吧？

工作與生活：2007/05

看到廖在 MSN 上寫著「老公加班無窮盡，此恨綿綿無絕期」。

最近許多朋友的生活品質，似乎都被「工作」給攪壞了。MPH 工作超級忙碌_{（看看他的這份 Blog：「這三個月打字最多的一天按了兩萬九千多鍵，平均約一萬多鍵，滑鼠移動都在一兩百公尺上下，至於滑鼠大概都點了數千下」。每天耶，真是驚人）}，最近大概也經常加班到夜半。因此，廖會有些抱怨，想想也是很自然的。

另外，貓的工作也似乎從「瘋狂的四月」變成「長時間工作的麥當勞工讀生」；珍珠圓在工作上許多朋友的離去，讓她難過到也想「跳船」。看來，還是當老師的 jlchang 和阿尼，在工作上比較穩定自在些。

是整體經濟環境惡化的影響嗎？在激烈的商場競爭下，公司賺錢越來越不容易，連帶使得員工也不得不承受更大的壓力，被迫以更多的勞力「至少在表面上」顯示自己已經盡了心力。只是，長久下來，這會惡化生活品質的。但是，賺錢來提高生活品質，不是原本「工作」所承諾給予的嗎？

真是複雜又弔詭的現象。

我自己呢？論文初稿在有些「虎頭蛇尾」的狀況下，算是完成（交給項老師）了。工作上的待辦事項雖然不少，但排排優先順序，也還算不上有太大的壓力。但是，怎麼這幾天一直有「快要虛脫」的感覺啊。難道這是「一陣忙亂」之後的正常現象嗎？（這兩個星期忙到沒什麼時間陪小朋友玩。）

基本上，回鍋作 Post Doctor 的工作，有部分原因也是想讓自己能夠多騰出時間，做些自己比較感興趣的事，並陪伴小朋友一同成長。只是，現實生活中，即使自己想「從忙碌的工作中掙扎、探索出悠閒的機會」，也總是「說來容易做來難」呢。

忙裡偷閒

待辦事項越來越多，有時脾氣也變得焦躁不安。

覺得應該掙扎出一些時間帶小傢伙出外走走。就是這樣，昨天出發前往淡水。非假日的捷運站外，顯得相當空曠。而即使在五月的豔陽下，小朋友仍然顯得相當興奮。


大人們可以慵懶地閒坐，欣賞河岸的景觀。小朋友呢？最簡單的吹泡泡遊戲，就能讓她全神專注、玩得興高采烈。


欣賞小朋友的天真模樣，心裡的感覺很滿足。
      

不必等升官發財、也不必等功成名就。在忙碌的生活中偷閒，有時更能讓自己感到該珍惜生活中的美好事物。

自言自語

最近工作得有些莫名其妙。

工作些什麼呢？雖然有許多是屬於「寫寫程式」之類的系統開發工作，但其實自己心裡有數：最傷神的還是寫論文這件事。寫程式通常看得出進度或成果，但寫論文... 唉，一言難盡啊。

說「工作得莫名其妙」，是因為實在想不出什麼好理由或好藉口，能夠強而有力地說服自己：「花這些時間與精力是很自然、甚至是必要且值得」的。

文章是用中文寫的、實驗是學弟去年就做的、主要的材料也都來自那位學弟去年的碩士論文。那麼，為什麼我已經耗上兩個多月，卻連「初稿」都尚未完成？（更糟的是，寫到快沒力了，就有些想偷懶，但這樣論文後半可能就會顯得有些「虎頭蛇尾」的味道。）

我覺得，自己在寫論文這件事情上，應該還算是認真且盡力。那麼，除了「寫篇像樣的論文，本來就不是件容易事」與「自己寫作表達能力不佳」之外，我還能有什麼理由或藉口呢？

難道... 難道，另一個原因，竟然是「年紀稍大，導致生產力下降」？

Joel 的「抽象滲漏法則」

對「約耳談軟體」(Joel on Software) 的這篇文章頗有共鳴。

「抽象」(abstraction) 是系統化增加生產力的有力工具，因為它可以將許多複雜的東西，隱藏在一組簡單的概念或動作之下。它讓開發人員能夠經由這組簡單的概念思考，運用這組簡單的動作寫程式，因而簡化了系統開發的複雜度。

有意思的是， Joel 說「所有重大的抽象機制在某種程式上都是有漏洞的」，並舉了許多實例來說明。

我看到這句話的第一個感覺像遭到小小的電擊。喔，對啦，他說出了我心底對軟體開發「為什麼總覺得某些地方怪怪地」的一個重要原因，他也用這個「抽象滲漏法則」(The Law of Leaky Abstractions) 說明為什麼「漂亮的理論模型」在實務中不見得可以幫上我們太多忙。

因為... 如果實際上的系統頗複雜或頗新穎_{（因此，很少實際的他人經驗可以借鑑）}，在套用這個模型之前，我們必須弄懂那個抽象模型的原理、以及它所隱藏的東西。否則，當我們遇到問題時，就很可能被卡住，然後不知道該如何解決問題！

不是嗎？即使先進的程式語言都提供了各式套件來處理 unicode 或各類文字編碼的問題，但實務上每隔一陣子就會看見有人卡在「中文轉碼」的問題上。即使自認為已經對中文轉碼頗有經驗，碰到問題時_{（例如，先前在「又遇編碼問題」的狀況）}也很難在短時間內找到好的解決方式。

所以，Joel 說「這一切都似非而是地表示，即使我們擁有愈來愈高階的程式設計工具，抽象化也做得愈來愈好，要成為一個純熟的程式師卻是愈來愈難了」。

真是令人感傷。

8-puzzle

解 8-puzzle 是一個古老的益智問題。

年少時對解這類「益智問題」，總有著那麼些興趣。學生時期，在人工智能 (AI: Artificial Intelligence) 的課程裡，教授們介紹 searching methods 時，有時也可以看到這個問題。可惜的是，或許是因為當時的課程內容太豐富，反倒沒有機會真的將這個程式寫出來玩玩。


這一陣子想整理一些從前感興趣的小程式，偶然間就想起 8-puzzle（或者更大盤面的「15-puzzle」）來。於是，花了些時間用 PHP5 把它實作出來。

演算法是採用 IDA* (Iterative Deepening A*)，因此理論上求得的應該是最佳解_{（什麼時候不是最佳解？就是我程式寫錯的時候啦）}。上圖左方的盤面，程式花了 22 步才走到右方的目的地。