過去，我提到 REST 這個字眼時，多半指的是一種常用的 Web-based 應用軟體設計慣例或樣式 (我個人偏好用"慣例"一詞，不過用"樣式/pattern"好像比較專業)。既然是慣例，那在設計和使用上就比較隨興。不過隨著 REST 樣式的大量應用，有愈來愈多案例開始使用更制式化的設計樣式，這些高度制式化的 REST 服務，就稱之為 "RESTful web service"。 "-ful" 這個字尾正是在強調它們的設計方式完全符合 REST 文獻的建議內容。
相對於 RESTful ，以往那種基於慣例與相容性的實作方式，有人就稱為 RPC 。不過說到 RPC ，我第一時間想到的是 Unix 系統的 RPC (Remote Procedure Call)，而且它的歷史更為悠久。為了避免混淆，所以我傾向於用 "REST-like" 這個稱呼。
...繼續閱讀
有一字串，其格式為以逗號 (,) 分隔的記錄，例如 "a","b","c"。當某些欄位之值為空白時，會有逗號相連的情形，例如 "a",,"c"。
現在要用字樣規則式(Regular Expression, Regex)修改空白欄位的表達方式，改成一個空字串 ("")，一般我們會寫成 s/,,/,"",/g (by Perl)。不過這種寫法碰到連續多個空白欄位時，例如 "a",,,"c"，會變成 "a","",,"c"，得不到我們要的結果。因為 Regex 解析器在找到第一組 ,, 後，會把處理指標放在第3個逗號的位置上。當 Regex 解析器進行下一個比對動作時，它將從第3個逗號開始尋找，此時它看到的只有一個逗號，故判定不符合樣式，也就不會進行替換動作。
碰到這種情形，我們要用 look-ahead assertion (前瞻斷言) 處理。 Look-ahead assertion 的語法為 (?=pattern)。See also perlre::Look-Around Assertions。
在 Web 應用系統的開發工具中， Selenium Core 是一套相當著名的測試工具。它的特點是 "直接在真實的瀏覽器中測試各項動作" 。由於現行各家瀏覽器的實作狀況各有所異，所以這項特點可以真實反應 Web 應用系統對各家瀏覽器的相容性。也正由於它是直接在真實的瀏覽器上進行測試，所以它也不可避免地受瀏覽器的功能限制，其中最主要的限制就是 "Same origin policy"(相同來源政策)。
凡是 Ajax 的開發人員，對於 "Same origin policy" 一定不陌生。這是瀏覽器保護使用者資料的重要安全措施。而 Selenium Core 是一套以 JavaScript 實作的測試工具，所以也受 Same origin policy 限制。這就使得開發人員在使用 Selenium Core 測試 Web 應用系統時，必須要把 Selenium Core 安裝在 Web 應用系統的目錄之下，以符合瀏覽器的相同來源政策。如果 Selenium Core 和 Web 應用系統的來源不相同，瀏覽器就會回應 Selenium Core 沒有權限載入 Web 應用系統的頁面。如此一來也就無法進行測試工作了。
...繼續閱讀今天看 iThome 的報導，知道 Jazz 開放申請使用。我也是這時才知道， Jazz 原來是一個軟體協作平台。
去年10月底，我參加 2007 IBM開發者大會時，雖然知道大會主題是 "Jazz" ，不過一直以為那是一個形容詞。在當天的議程中，完全沒有看到所謂 "Jazz" 軟體的影子，那天談的是 Web 2.0 和 SOA 。今天才知道原來那還是一個軟體協作平台。IBM 的宣傳也差了點吧...
...繼續閱讀Using XSLT, PHP, or Ruby on Rails to transform XML documents into XHTML documents. 展示 XSLT, PHP 與 Ruby on Rails 的樣版撰寫風格。
在使用樣版引擎之前，我們需要先將資料自外觀中分離，因此 A Note of HTML Form and XForm 算是本文的前置文章。當我們將資料和外觀分離時，我們將更進一步考慮如何將外觀樣版化。
...繼續閱讀如何分割 "資料"(Data)與 "表單外觀"(呈現層,Presentation)。
HTML Form 之中，資料與表單元件的陣述混雜在一起，增加文件編寫與閱讀複雜度。此複雜度不僅是針對人工輸入與閱讀，對應用軟體亦然，例如網頁編輯工具、Famework 工具等等。混雜的陣述方式，增加了前述工具的開發者之工作 - 編程難，除錯難 。
...繼續閱讀cf 的回應 中提到了 polymorphism 和 generic 的看法。我的看法稍有不同。
我眼中的泛型(generic)，若用非常簡化的方式來表達，就是不管型別，只看程式形式，亦即演算法。如稍候例舉的 max() 就是一種泛型演算法 (STL 也有一個同名的演算法)。我的說法和其他人的說法應該沒什麼不同。那麼多型(polymorphism)、泛型和樣板(templete)之間有什麼關係？端視程式語言的特性而定。
首先，多型(polymorphism)具有類別繼承的性質，是個體導向(OO)的概念，但泛型(generic) 不是個體導向概念。我們同樣可以在只有基礎資料型態，沒有繼承觀念的環境中使用泛型設計，只是彈性就低多了。在個體導向語言中，藉由類別繼承與動態連結的能力，才能充分發揮泛型設計的優點。
...繼續閱讀同人在《Time-Boxing 於軟體反覆演進的必要性》之中所說的情形，我也有碰過。
有時，客戶提出的需求變化其實並不是個好方法。在這種時候，我會示範或舉個例子，告訴客戶一個更好的方式。如果有示範品的話，客戶通常會很快接受。接著，我會告訴客戶這些實作方式是不是現有的。如果沒有，大約需要多少工時，並評估其重要性及時程。換言之，要評估這樣的需求變化要不要立即處理。就算客戶不能當天看到修正結果，也要在溝通的過程中，讓客戶了解前因後果以及處理時程。畢竟，「溝通」是雙向的，而不是盲目地接受客戶的要求。開發團隊單純地接收客戶指令，算不上溝通。
當然，這些內容在敏捷方法的書中都有提到，我就不再多說。我接著要提我個人的所見所聞，是上述內容在國內實行時的困境。
...繼續閱讀
同人針對我的《敏捷方法實務研討會會後筆記3》寫了篇評論。確實，週期的長短並不是關鍵。因為以「日」為單位的反覆週期，是敏捷方法重視使用者參與，將使用者拉進開發工作之後，自然而然就會發生的必然結果。敏捷方法則透過密集的溝通行為，一舉將反覆式開發的週期縮短到以「工作天」為單位
(敏捷方法實務研討會會後筆記3)。
說到 CMMI ，可是現在國內軟體公司之間的熱門話題。好像沒通過 CMMI 認證，接洽案子時就矮人家一截。我之前也待過一間通過 CMMI level 2 的軟體公司。可惜的是，我完全看不出取得 CMMI 認證的公司，他們的軟體開發品質以及程序員工作效率與以往有何不同 。雖然如此，現在台灣官方 (經濟部、資策會等) 就是相信 CMMI 那一套。我並不是說 CMMI 沒用，只是在缺乏穩固基礎的條件下， CMMI 認證只是表面文章。
「穩固基礎」是指什麼？ 就是夠多的 senior programmer 、正確的程式設計觀念等等基本功夫。舉例來說，如果有一間軟體公司幾乎所有程序員都有7年以上的資深實務經驗，那不論是 CMMI, CMMV 還是 CMMX 認證 (喔，當然沒有 CMMV, CMMX ，我只是在玩羅馬數字遊戲)，他們推起來都一定順暢無比。因為他們的觀念及實務作法早就到位了，就差套個標準流程的形式而已。
...繼續閱讀