石頭閒語

前一陣子在工作場所碰到一件事，我的同事抱怨 SVN 不能幫他合併他修改過的分支內容。我覺得很奇怪，因為我並沒有碰過這種情形。一開始我以為他是不熟悉 TortoiseSVN 工具，後來我實際看了他操作後，看到他竟然一次要合併近百份源碼檔，當場無言以對。

我記得我曾說過 SVN 可以幫我們程序員自動合併分支的源碼內容，並在衝突時提示我們。然而，在碰到同事這件例子後，我發覺我忘了加一個但書: 「請在持續整合(Continuous Integration)的原則下利用合併功能」。否則再好的版本控制工具也無法幫你合併。

jaceju 說: Oracle 的表格、欄位名稱都要大寫這個限制實在很鳥...不曉得有沒有哪位 Oracle 前輩能指點一二？

關於欄位名稱，其實是可以指定大小寫的，但要用 雙引號 (") 括起來。一個「非雙引號括起的」欄位名稱都要大寫這件事，其實是 SQL Standard。而且這是內定程序。

10)The <identifier body> of a <regular identifier> is equivalent to an <identifier body> in which every letter that is a lower- case letter is replaced by the equivalent upper-case letter or letters. This treatment includes determination of equiva- lence, representation in the Information and Definition Schemas, representation in the diagnostics area, and similar uses. SQL 92

但是 SQL Standard 也允許你用雙引號(doublequote) 字元括起名稱，這時就會抑制大小寫轉換的動作。這是 SQL Standard 配合國際字元集所定的規則。在這種情形下，也 SQL Standard 也允許你用保留字做為欄位名稱。

Oracle 在這方面完全遵循 SQL Standard 。也可以參考 Oracle reference 的內容: Oracle Database SQL Language Reference 11g Release 1::Schema Object Names and Qualifiers。就我個人實際使用經驗， PostgresSQL, MS SQL Server, IBM DB2 以及我最不喜歡的 MySQL方言，都遵循這個作法。

話說回來， MySQL 也是一樣，你把欄位名稱輸入小寫符號，MySQL DBMS內部也是全部轉大寫在處理(還是小寫？我忘了，反正結果一樣)。除非你用雙引號括起來，才會保留大小寫差異。

今天一早打開電子信箱，開始慣例的週一工作: 慢慢地一封一封地過濾信件。這工作可以讓我混一個上午。Ok, 那不是重點。重點是公司發了一封重要公告，內容很簡單，就是公司通過 CMMI level 3 認證了。

啥？有人要恭喜我？且慢，別誤會。我是新進員工，而那個認證申請工作已經進行一年了，而且我也不在參加 CMMI 審核的人員名單中。這公司能通過 CMMI level 3 認證跟我是一點關係都沒有。

這件事對我來說真正重要的是: 看來會有一段雞飛狗跳的日子了。千萬別以為通過 CMMI 後，"馬上就會好"。這公司跟我以前待過的公司一樣，雖然通過 CMMI 了，但其實還沒有在真正的開發工作上 準備好。我幾乎可以預見日後我們程式人員要開始力抗 PM 擬定的 "非結構化、不具重用性的規範文件" 等官僚系統了。我實在無法理解那些人在想什麼，CMMI 導入指引中從未規定過開發過程中的產出文件格式，但就是有人有辦法定出一套 "非結構化、不具重用性的文件格式"。在我觀察中，那種文件不只是程式人員覺得麻煩，就連 PM 自己也無法認真而快速地從中找出多少有用的資訊。因為那些文件格式不具結構性也不具重用性。從資訊管理的角度來看，這完全是不專業的表現。

Anyway, 也許日後我的 blog 又有不少題材可以寫了... 希望是好事比較多，我也不喜歡寫批文。

在 Web 應用的設計工作中，我們常常會讓"資料新增"、"資料編輯"與"資料檢視"這幾個動作共用同一個頁面樣板，差別僅在於檢視動作下的表單欄位輸入控制元件是不可編輯的。而要讓輸入控制元件不可編輯的方式很簡單，僅需要設置輸入控制元件的 disabled 或 readonly 即可。只不過，我們最好能在視覺上美化一下不可編輯表單欄位，讓使用者可以看出哪些欄位是不可編輯的。特別是 disabled 的輸入控制元件，其預設的顯示樣式實在很醜。非美化不可。

如果你使用 Selenium Core 編寫 Web 應用的測試案例，那麼關於輸入控制元件的 readonly 屬性有一些測試上的注意事項，請參考《A patch of isEditable of Selenium Core 0.83》。

日前配合 Selenium 撰寫一個 Web 應用軟體的測試案例，案例中有一句斷言要判定指定的表單輸入欄位是唯讀的 (readonly)。我個人很直覺地使用了 assetrNotEditable，但測試結果卻是錯的。後來我又試了 assertEditable、assertAttribute 及 assertNotAttribute 等寫法。始終無法正確而一致地判定輸入欄位的唯讀屬性 (readonly)。

依據參考文件 (Selenium IDE Reference) ，assertEditable/assertNotEditable 的說明，這兩種斷言都是調用 isEditable() 判斷。於是我開啟 selemium-api.js 後搜尋 isEditable ，找出它的源碼內容。結果發現它只判斷輸入控制元件 (input element) 的 disabled 屬性，而未判斷 readonly 屬性。

PHPUnit 預置了一個純文字型式的 TextUI Runner，在大多數情形下，它足夠應付我們的需求。不過，當我想要把 TestSuite 放到專案網頁上，讓小組成員 - 特別是 PM - 可以上網查看立即的測試結果時，那個文字型式的 TextUI Runner 就顯得太簡略了。至少要把測試工作及結果輸出成 HTML 的條列式清單，最好還加上顏色區別成功或失敗。

所幸 PHPUnit 提供了良好的擴充性，要自定一個可以將測試內容輸出為 HTML 網頁的 HTML Runner 相當簡單。

延續《分割程式功能以及 mix-in 和 include》的討論。tokimeki 說: 既然已經在外部定義了function，直接調用function不就好了嗎？

我直接委派函數的原因是 PHP 語法限制。用函數比用靜態成員函數(類別方法)或一般成員函數(個體行為)要容易寫。請看我在另一篇的回應: 這牽涉到 PHP 的動態能力限制。。