「地球へ...」(奔向地球)，故事背景是未來，由於地球的環境汙染過於嚴重，所以人類決定組成特殊的聯合政治體制 Superior Dominance，簡稱 SD 。接著展開太空移民計劃，將地球淨空，等待環境自然淨化。

測試驅動開發 (Test Driven Development, TDD) 的觀念由來以久。寫程式時會順便寫測試碼，幾乎是所有有經驗的程序員在不自覺下養成的習慣。例如我在《運用訊息溝通網絡及軟體工程方法建立開放源碼專案之個人淺見》一文中，提到我以前用 C 語言寫程式時順手寫測試碼的習慣。不過那個時候，xUnit 這類測試工具還不普遍。當時看其他人寫的開放源碼程式，幾乎是人人各有一套測試碼的撰寫風格。但是隨著 xUnit 工具的普及，測試碼的撰寫方式也愈來愈一致了。同時，也改變了程序員編程時的習慣，帶動了先寫測試碼的「測試驅動開發」觀念。

TDD 的好處，基本用不著我多加說明。 Robert C. Martin 在《敏捷軟體開發-原則、樣式及實務》中寫的再明白不過了。儘管如此，在研討會中，我還是針對 TDD 提了一個問題。我的問題是：能不能藉由測試案例建立更準確的工作時程量測指標，以便掌握確切的工作時程。

雖然每本敏捷方法的書，都會提到測試驅動開發(TDD) 及反覆式開發過程(或稱迭代式開發) ，然而它們並不是敏捷方法獨有的要素。這兩者都是存在已久的編程實務。XP 並沒有新的觀念，它的觀念與程式設計的歷史一樣老(Kent Beck)。但敏捷方法確實把這兩者發揚光大，讓人們注意到這兩種實務作法所蘊涵的強大威力。

陳教授在會中也一再強調反覆式開發過程。但對陳教授解說的內容，我持有兩點不同看法。雖然當時提問了，奈何時間有限，並沒有足夠的時間討論。

敏捷方法強調溝通，且溝通行為不僅發生在負責軟體開發工作的程序員之間，也要包含使用者。所以敏捷方法的實踐作法中，重視並要求「使用者參與」。陳教授在會中使用「駐廠使用專家 (On-site usage expert)」表示在敏捷開發過程中的使用者代表。一般則稱為「駐點客戶(On-site customer)」。

電脳コイル (電腦線圈) 的主角是一群小學生，所以人設也像是給小學與中學生觀看的動畫。但故事背景的概念其實非常前衛，連大人也未必能理解。

在電脳コイル的世界中，人們已經實現了「資訊實體化」的概念。看到這，程序員會很高興。因為資訊實體化的意義就是我們在電腦系統中所創造一切事物，都可以轉成實體，看得到摸得著。甚至連生活空間都是資訊實體化而來。在那裡，人們幾乎無法區分數位資訊與實體的差別了。資訊就是實體，實體就是資訊。當然，在物理學的概念中，所有實體都是一種資訊。但是令數位資訊成為人體可以感覺得到的實體，現在還只是人類的想像。

中央大學資工系在6月15日舉辦了一場「台灣敏捷方法實務研討會」，由陳振炎教授主講。我將聽到的內容與自己的感想做了一番整理。

敏捷方法的特色與重點，絕對是「人際溝通」。 Ivar Jacobson 說「敏捷是一門社會科學。它關注的是如何讓大家像一個團隊般工作、如何激勵成員、如何相互合作等等」(CSDN《程序員》2007年4月刊)。

前些日子閱讀《沒有時間的世界》，書中說，圖靈 的圖靈機概念，最偉大的貢獻在於「把程式當資料儲存」的想法。我一時無聊，又想起了以前在 DOS 時代的記憶，就寫了一段 C 語言程式，把程式碼當資料複製，然後再去執行那段被複製的程式碼。

原問題: 查詢結果附上條件?。需求是有一個來自使用者輸入的對照表，由於其內容每次輸入都不同，故並未建立在資料庫中。現在需要在查詢結果中加入此一對照資訊。

純 SQL 的方式可配合 CASE 關鍵字，但受限於查詢句子的長度及複雜度，僅適用於少量資訊。

最近在《不存在時間的世界》一書中，看到了哥德爾的不完備定理，其中也有提到不完備定理的的計算機形式，即圖靈的停機問題(Halting problem)。但不知是書籍翻譯還是哪裡的問題，我覺得我看不懂它的說明。

看了書中的說明後，我的程式設計經驗直接告訴我兩件事: 一、程式不具可計算性。編譯器會明確告訴我變量未定義。二、這是無窮遞迴。程式實際執行時，會發生遞迴深度超出限制或堆疊滿溢的錯誤。我總覺得書中的說明怪怪的。

前一篇舉了一個簡單的例子，粗略地說明管理者的管理績效，應該看員工的平均工時的理由。

當然，我有更堅實的理由支持我的觀點。而且是有科學性的理由，並非個人感覺云云。我畢竟是個受過專門學術訓練的 MBA ，就以經濟學和管理學的觀點闡述管理者的管理績效，應該看員工的平均工時的理由。

順便回應喲哪桑，喲哪桑開玩笑地問我是不是也坐在台下聽那場演講？嗯，按照我的個性，如果我在台下聽一定會當場吐槽...

日前在《寫程式需不需要懂數學》一文的討論中，一位回應者引用了維根斯坦(Ludwig Wittgenstein)在《邏輯哲學論》中的名言: 凡是不能說的事情，就應該沉默 (Whereof one cannot speak, thereof one must be silent)。當對方的回應中出現這句話時，我剎時感到非常地錯愕。當時為了避免離題扯到研究方法論上，我只是輕輕提示這句話是維根斯坦說的，並沒有指出這句話是斷章取義，引用失當。

根據對方的回應內容 - 箇中奧秘，學數學的學生都懂，但是是只能意會，不能言傳 - ，他似乎是想表達數學之中，有些內容是不可言的。然而，維根斯坦口中所稱不可言之事，並不是數學。就我所知，不論是在前期的邏輯實證主義時期，或是後期的分析哲學時期，維根斯坦從未認為面對數學時應當保持沈默。

我們多數人使用的鍵盤是美式鍵盤(101/104鍵)，安裝微軟的日文輸入法後會發現轉換輸入法狀態很麻煩，常常要用滑鼠點來點去。因為微軟日文輸入法提供的使用說明，是針對日本特殊鍵盤的使用者，沒提到美式鍵盤的轉換快速鍵。

常常看到有新手問這問題，我也不藏私。在此提供我個人經過多次嘗試後找出的美式鍵盤轉換快速鍵的對照表。

she96965 問: 我想要過三秒後執行一次函數，再過三秒在執行一次，一直反覆一直反覆。

答: 用 sleep() 。另一方面， PHP 有一個最大執行時間的限制，故尚須配合 set_time_limit() 重置最大執行時間的計時。

我們一般對 PHP 的印象是：寫 Web 應用程式的工具。其實它也可以作為單純的解譯器運行一般的本地程式， PHP 稱此運行模式為 CLI mode。若進一步結合 PHP-GTK 擴充模組 (關於 PHP-GTK 的安裝，請參考《Glade/GTK2 for Windows with PHP5 and Ruby 快速安裝指南》) ，我們仍然可以使用 PHP 設計具有圖形使用者介面的桌面應用程式。

本文不只單純地說明如何利用 PHP-GTK + Glade 設計桌面應用程式，更要混合現成的 Web 應用程式，一併為各位展示 MVC 架構所帶來的高度彈性與可用性。

喲哪桑的《管理者的工作時數》引述了一個評量管理者能力的方法，即「優秀的管理者，其工作時數必然長；因此，我們可以把管理者的工作時數，當做其績效衡量的指標之一」。

我說這個指數不準。當你要量自己的身高時，怎麼可以拿自己的手臂去比呢？要拿別的基準物才準。我說把工作時數的對象換一下才對。我評量的方法是，看管理者底下的工作者的平均工作時數來決定管理者的績效。

假設同一批員工，先後在2位主管手下做同樣的事。在第1位主管手下，每個員工天天都準時下班，還能提早整理桌面、聊天打屁(平均工時<8hr)。在第2位主管手下，每個員工天天「基於工作責任」多做1~2小時工作，連喝下午茶的時間都沒有。

不必計算什麼東西，我們就能評量哪位主管的管理績效好。把員工當成管理者的 reflection ，觀察員工，我們就能評量管理者的績效了。

原問題見: SESSION怎麼釋放不掉。在 PHP 中使用 Session 前，請務必閱讀: PHP Manual::Session Handling Functions。

1. Session and global variable

PHP Manual::session_register: If you are using $_SESSION (or $HTTP_SESSION_VARS), do not use session_register(), session_is_registered(), and session_unregister().

$_SESSION 已經是一個 superglobal variable (全系統域變數)，使用 $_SESSION['yourKey'] 的寫法就可以了。

薔薇少女漫畫版倉卒地結束了。聽說因為作者和出版社編輯不和，導致作品提前結束。只留下一大堆未解的謎題，以及在鏡中即是生也是死的人偶們。最終回的劇情，我透露在《薔薇少女 漫畫最終回... 囧》。我沒有把所有日文對白翻譯出來，不過我透的內容也夠多了。

那隻喜好故弄玄虛的怪兔子 - 拉普拉斯之魔，最後出來擺了道選擇題。「箱の中の猫が生きているのか死んでいるのか。全ては開けてみてのお楽しみ」。以「薛丁格的貓」比喻鏡中的人偶即是生也是死。要開門嗎？還是不開門嗎？還真是巧妙的引喻。

昨天我還在跟人討論「寫程式需不需要懂數學」。我主張數學家和程序員同樣運用邏輯與代數概念進行思考。差別在於數學家用數學式記述思考過程，程序員用程式語言記述思考過程。僅此而已。不過我發現在討論這問題時，就連我自己也陷入數學指的是某一種記述形式的框框。這只能怪國內的記憶式數學教育方式太成功，以致於我們都默認數學的記述形式只有固定一種了。

為什麼我會發覺自己陷入形式的框框呢？這是因為我偶然看到一段影片展示了圖形式乘法(Easy Graphical Multiplication Trick)。它會呈現的形式，比電腦程式更不像我們這些人所認定的數學形式。但是他們說這是「建構式數學」。他們沒有因為這種形式不夠「優雅」，就說這麼做的人不懂數學。同理，我們又為何要喋喋不休地討論是否一定要用我們所習慣的數學形式思考與記述才能寫出效率高的程式？

YungLee 說: 如果我不顧你的感受，硬是要說 Scilab 是自由軟體 (但我當然不會說他是 FSF 所定義的自由軟體)時，請問我犯了甚麼法 ? 如果你無法精確說出可以引用的法源時，你就不能使用你的感受，來裁判別人，尤其是牽涉法律問題時，這一點你似乎不很在意。

YungLee 要如何稱呼，與我的感受無關。而且幸運的是，「Free software」及「自由軟體」這兩個詞都沒有註冊為商標(trademark)。所以 YungLee 稱呼 Scilab 是「自由軟體」並不會觸犯商標法。

三不五時就會聽到有人問寫程式需不需要懂數學，例如《寫程式到底需不需要懂數學》。在我這個大學時五修微積分才過關的人聽來，還真是刺耳。這根本是個偽命題。

若說寫程式要懂邏輯與代數，這我同意。但若說寫程式要懂數學，那我就反問要懂數學的哪一部份？