雖然我們總是說著動態語言(dynamic language)、靜態語言(static language)，但區分方式並不是語法，而是運行環境。
如果程式影像在載入前便確立並儲存，那麼是靜態語言[If the image of program which including op code and data is static in disk before loaded, we call it 'static language'.]。這句話對學過作業系統概論或組合語言的人比較容易理解。因為在組合語言中，要求程序員設置 code 節區， data 節區等內容載入記憶體的位置。所以我們很容易聯想記憶體中的程式影像儲存在檔案系統中的情形。與之相對的是，若程式影像在載入後才建立，則是動態語言。
...繼續閱讀喔，各位沒看錯，陳教授確實把資料結構與演算法列入他規劃的敏捷方法 (myAgile) 條目中。我看到這一點是非常 Orz
陳教授有提到理由，台灣的程式設計教育重視計算與解題，而不重視思考與建構。所以程序員常常學了資料結構與演算法之後，卻不會運用在實際的編程工作上。故此他特別把這一點列入 myAgile 條目中。
...繼續閱讀測試驅動開發 (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月刊)。
三不五時就會聽到有人問寫程式需不需要懂數學，例如《寫程式到底需不需要懂數學》。在我這個大學時五修微積分才過關的人聽來，還真是刺耳。這根本是個偽命題。
若說寫程式要懂邏輯與代數，這我同意。但若說寫程式要懂數學，那我就反問要懂數學的哪一部份？
...繼續閱讀本文將指引讀者，如何在 Windows 平台上快速安裝 GTK2/Glade 暨 PHP 與 Ruby 的開發環境。
在泛Unix環境下，我們通常使用 GTK+ 開發圖形化使用介面(GUI)的應用程式。GTK+ a multi-platform toolkit for creating graphical user interfaces
. 許多動態語言，如 Perl, Python, Ruby, PHP 等等，皆可利用 GTK+ 開發圖形化使用介面程式。由於上述動態語言之軟體開發環境與 GTK+ 皆具有跨平台的特性，因此利用它們所設計出的應用程式，通常可運作於多種作業平台之上，包括 Win32 (Windows 2k/XP) 平台。
報個消息。中央大學陳振炎教授定於6月15日，在中央大學辦一場「敏捷方法實務研討會」。相關訊息請見網頁。
我老是在談自己的經驗，以自己的經驗去驗證書上的 XP/Agiel Method 內容。還真是挺想知道其他人是如何實踐的。如果沒什麼意外，我應該會參加。希望能向公司爭取到公假...
當我說：MIS 和 PM 應該系出同門，都屬於「資訊管理科系」。按理說溝通時應該不會有觀念的落差。然而實務經驗的落差卻很大
。其實有些挖苦的味道。我並非資訊科班出身，所以我曾經以為 MIS 和 PM 系出同門。後來發現我錯了，實際狀況並非如此。我的經驗是 在傳統升官發財的思維下，有點能力的 programmer 多數依「Peter Principle」升遷 PM 或系統分析人員
(台灣資訊軟體業缺乏資深programmer) 。在我看來，國內的 PM 多數是從資工等技術體系出身。與 MIS 並非系出同門。