報個消息。中央大學陳振炎教授定於6月15日，在中央大學辦一場「敏捷方法實務研討會」。相關訊息請見網頁。
我老是在談自己的經驗，以自己的經驗去驗證書上的 XP/Agiel Method 內容。還真是挺想知道其他人是如何實踐的。如果沒什麼意外，我應該會參加。希望能向公司爭取到公假...
報個消息。中央大學陳振炎教授定於6月15日，在中央大學辦一場「敏捷方法實務研討會」。相關訊息請見網頁。
我老是在談自己的經驗，以自己的經驗去驗證書上的 XP/Agiel Method 內容。還真是挺想知道其他人是如何實踐的。如果沒什麼意外，我應該會參加。希望能向公司爭取到公假...
當我說：MIS 和 PM 應該系出同門，都屬於「資訊管理科系」。按理說溝通時應該不會有觀念的落差。然而實務經驗的落差卻很大
。其實有些挖苦的味道。我並非資訊科班出身，所以我曾經以為 MIS 和 PM 系出同門。後來發現我錯了，實際狀況並非如此。我的經驗是 在傳統升官發財的思維下，有點能力的 programmer 多數依「Peter Principle」升遷 PM 或系統分析人員
(台灣資訊軟體業缺乏資深programmer) 。在我看來，國內的 PM 多數是從資工等技術體系出身。與 MIS 並非系出同門。
同人說 關鍵不在核心，而是在邊界
(註)。 kuni 說 我覺得成敗最關鍵人物是軟體公司派去溝通需求這個人
。我在《Bug 數量與軟體品質控制》中說 甲方接口單位通常是甲方的 MIS ，通常跟乙方一樣是資訊科班出身... 難怪甲方無法參與開發流程，甚至參與後反而成為專案的阻力
。又在《甲方、end-user 與需求落差》中說 基於 Agile methods 強調使用者參與的精神，我更注重使用者在軟體開發的活動中扮演了什麼角色？
。
我們的觀點都指向同一個重點，那就是溝通。
...繼續閱讀今天在 Ruby-talk mailing list 上看到一則消息「Microsoft brings Ruby to the browser?」。重點如後述，各位姑且看看。
Microsoft 日前發表 Silverlight 。 Silverlight 是一種 RIA 開發工具與環境，其用途與目前廣泛流行的 Adobe Flash 技術相同。以 plug-in 方式增加網頁內容之多媒體支援，並提供使用者更豐富的操作互動性。由於 Silverlight 是基於 .Net 平台的應用環境，故其中將包含一個小型的 CLR 執行環境。據聞微軟亦將正式發佈 .Net 平台的 IronPython 與 IronRuby (.Net 的 PHP, Phalanger, 不在其中?)。據此，程序員將可能以 CLR 所支援的這些動態語言，開發 Silverlight 的 RIA。
我在《PHP 不需要另一個樣版引擎, part 2》中寫著：說不定哪天我們就會看到內建 PHP 引擎的瀏覽器了。也許 .Net 版的 PHP (Phalanger) 會搭上微軟 WPF 架構 的順風車，成為第一個被瀏覽器 (Vista/IE only) 內建的 PHP 引擎，用於解析 HTML, XAML 等文件中的 php 標籤
。這句話似乎即將實現。
Mr. Saturday 談到 Coding Style - 程式設計風格對軟體開發的影響 。其中提到了一位老朋友 - Hungarian Notation - 。中譯為「匈牙利命名法」。以現在的標準來看，匈牙利命名法很醜，變數名稱又臭又長。但它的存在有其特殊背景。匈牙利命名法在組合語言和 C 語言的 coding 場合其實非常好。它們沒有便利的 casting ，一個指標或一個整數沒什麼差別。不加個記號說明一下型態， coding 工作可要命了。我當年會把 struct 印成一張速查表貼在電腦螢幕旁。每寫一個符號，就瞄一下看看這變數是啥型態。若用匈牙利命名法，取一個 dwID 和一個 szID ，就可以減少不少錯誤。至少不會把整數(dword)的 dwID 當成字串指標；也不會把 szID 當成數值代號。
當然在C++或動態語言中，這種命名法就毫無意義了。大多數情形下會自動轉型，故 “1″ == 1 is true. 這又提醒我們一件事， Coding Style 跟程式語言的特性有關。不同的程式語言，因其語法特性不同，就會有不同的 Coding Style 。不必要硬套同一種 convention 。
我個人對 Coding Style 的要求頗為寬鬆。任何像我這種寫或維護過十幾萬行 C 語言程式碼、被 C 語言多樣而自由的程式風格荼毒過的程序員，應該都能適應各種怪風格。基本上我只要求三點。一、要縮排；二、以80個字元為寬度換行；三、變數命名方式一致。不過太寬鬆的結果，就是我有時會被視為常常寫怪 code 的那種人。
喲哪桑說「I Don't Like Outsourcing」。他說因為 外包，將確保你的軟體知識不再累積，軟體也無法成為你策略性的核心能耐(Core Competence)
。
基本上，喲哪桑是從 Resource Based View/Knowledge Based View (RBV/KBV) 之觀點主張不要外包。然而我以為喲哪桑的觀點有必要加以修正，才能正確表達他所要表達的意涵。「軟體」一詞沒有抓準非IT企業的核心能耐之本質，精準地說「軟體開發」並非IT企業的核心能耐，「業務流程」才是非IT企業的核心能耐。
...繼續閱讀FireFoxer 于 要不要走程式設計這一行 提到「興趣」對於一個想走程式設計這一行的人是否必要。
個人看法以為興趣是必要的。Programming 基本上是一種「設計」工作，尤其對我這種傾向 Agile method 的程序人員而言更是如此。設計就是編程，編程就是設計。我們不但要達成功能需求，更在其中追求技藝之美。如果沒興趣，將得到一個「程式碼打字人員, code typist」，而不是一個「程式設計人員, program designer」；兩者之差別在「創造力」，其差異宛如臨摹者與畫家之分。
在我看來資訊軟體產業中也分很多行，而程式設計 != 資訊軟體產業。我並不輕視 code typist ，因為資訊軟體產業這一行還是需要 code typist ，但走這條路不等於走程式設計這一行。再者就我週遭經驗，沒有興趣以及一定偏執程度的人，通常在這條路上都待不久。儘管他們不會離開資訊軟體產業，但不會再投入編程工作了。
我在《軟體工程的 GPS》說「一個人寫程式，其實很苦悶；兩個人一起寫，就頗有樂趣了」。這句話發自心腑。獨行之路不好走，沒有興趣走不下去。
Google Code 是一項開放源碼專案管理服務平台 - Google Code Home，它採用 Subversion 作為版本控制系統(See also: Programming with Subversion Quickstart)。想申請建立專案非常容易，只要到 Prject Hosting 中填好申請表格即可建立專案。唯一限制是軟體授權證一定要採用 Google Code 提供的開放源碼授權證 (如 GPL, Apache License, New BSD License)。必須先登入 Gmail 帳號之後，才會出現 Create a new project 的申請表連結。提醒事項:
...繼續閱讀在思考 Ruby 模組與混成(mix-in)概念的過程中，勾起了我當初學習 Java 的記憶。C++ 藉由多重繼承達成程式碼再用之目的，也因此衍生了類別鑽石繼承問題。而 Java 出現時，強調它使用單一繼承並結合介面宣告而避免鑽石繼承問題。然而我對介面的使用經驗卻是負面的。
介面只宣告行為的外觀而不牽涉細節，細節在類之中個別實現。舉例而言，如果有兩個不具共同父祖類別的類，假設為 A, B 類，但具有一個共同的行為、一段相同的程式。 C++ 的作法是將此共同行為 - 亦即這一段相同的程式 - 設計為一個類，假設為 C 類，再令 A, B 類多重繼承 C 類；只要 C 類之中沒有任何屬性與 A, B 類之父祖相同，就不會導致鑽石繼承，同時達成程式碼再用之目的。Java 的作法則有兩個方式，其一是介面，其二是深度繼承。
...繼續閱讀Alex Yin 在《請使用者也參與軟體專案, CMMI-ACQ》中回應：「正確而言並不適合將使用者與甲方畫下等號。現有的軟體工程在IEEE-STD-12207的Acquisition Process就是敘述甲方(軍備局)的activity。」純粹從 PM 的角度來看，確實在發出採購案前，甲方內部應先進行一套評估流程。但甲方內部流程並非我關注之事。我是一個 programmer ，所以我關心的是已進行採購且軟體專案開始實施的狀況，而且基於 Agile methods 強調使用者參與的精神，我更注重使用者在軟體開發的活動中扮演了什麼角色？
...繼續閱讀