CQ Web login url

搞了半天，原來不是ClearQuest web 沒裝好，而是url弄錯了，不是http://host/cqweb，要用http://host/cqweb/login才行，真是白忙一場。

Upgrade from WebLogic 9.1 to 9.2 on AIX

上線兩個星期，這個小小的不成材的系統，一直有一些莫明其妙的問題，今天，忍不住把整個WebLogic 從9.1 昇級到9.2，反正死馬當活馬醫，總不能過著每天被全院追殺的日子。9.2跟9.1變化不大，不過，為防萬一，還是重新建立一個新的domain，然後，啟動WebLogic Server準備開始設定LDAP跟DataSource，沒想到，最不該出事的地方，總是會出事 --
Parsing Failure in config.xml: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = 441862298102654515, local class serialVersionUID = -9120448754896609940

這這這，這叫我如何是好，google了一下，原來是JavaEE在不同版本間，變更了QName的serialVersionUID, 依照網站上的建議，加上了 -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0, 果然就能夠順利的啟動9.2的domain。

設了LDAP, DataSource, 再把這個不成材的應用系統放上去，果然，日子好過多了，不再出現那個奇怪的XAER_PROTO的問題了。

總算有空了

最近，真的是忙到翻掉，大約在一個月前，一個同事離職，而他身上的一個預定要在12/7上線的系統，就順理成章的落到了我的身上，於是，一個agile到不能agile的專案，就這麼開始了，距離上線時間不到三週，所有功能都不確定，整個上線的環境是 WebLogic + Oracle 9i on AIX，其中，我只對AIX有一點點的認識。
這算是我第一次以這種型式做專案吧，之前待的環境，總是有還算正規的開發流程，再怎麼樣也不會是功能需求可以任意修改的狀態，這次，完全不一樣，每天都有新功能，每天都有需求變更，甚至在系統已經上線一週的現在，還持續有功能變更以及新功能的要求。這當然不算太離譜的狀態，真正離譜的是，這個系統的壽命，最多最多只到明年的一月中，也就是剩大約一個月的時間，而且，使用者會隨著壽命的結束，而慢慢的變少，直到壽命終止。
打從系統開始上線到今天，系統總算處於比較穩定的狀態，原因是因為AIX+WebLogic的組合的系統調效，連續一個星期的File Open too many..直到昨天，才利用修改WebLogic 啟動script的方式，將file descriptor limit開到2000，才撐得住，原因是因為在WebLogic 9的startup script (setCommEnv.sh)中，有個resetFd的函數，會在系統啟動前，執行ulimit -n 1024的動作，導致系統執行過程中，發生File Open too many的問題。非正規解法則是，將ulimit -n 的值，調到至少與AIX的系統預設值相同(2000)，就可以在一定程度避免File Open Too many 的問題，至於會不會引發其他的問題，目前，還看不出來，看起來是還好就是了。

WebWork if tag 與 action property

WebWork if tag 中的 test 條件，要使用action的property來作為判斷條件時，必需先透過set 將action屬性設為一個單獨的變數，才能做測試。

<ww:set name="local" value="property">

<ww:if test="#local == %{abc}">
</ww:if>

昨天為了這個問題，搞了快一個下午，還好最後有找到解法，不然，還不知道要花多少時間咧

method/function spec -- 如何寫好 JavaDoc

寫Java寫了那麼久，一直不知道怎麼寫JavaDoc會比較好，最近剛好在看MIT的線上課程，其中有關於function/method規格的部份，發現如果依據這種方式來寫的話，既可以清楚的表達function/method的行為，又不會把太多的實作細節寫出來，是一個很好的寫JavaDoc的格式。

規格定義

規格同時定義了使用者以及實作者雙方的責任 -- 在使用者滿足規格中所定義的條件下，實作者保證能達到規格中要求的結果。

一個function/method的規格，包含了三個部份

• precondition -- 一般用關鍵字 requires來表示
• postcondition -- 一般用關鍵字 effects來表示
• frame condition -- 一般用關鍵字 modifies來表示

precondition 規範了使用者的責任，如果precondition中的條件沒有滿足的話，實作者可以用任意的方式來完成實作 (包含終止整個程序)。

postcondition 則是規範了實作者的責任，在precondition滿足的條件下，實作必需要滿足postcondition中所規範的條件。

frame condition 和 postcondition有關，讓寫規格的人能夠比較簡單、清楚的表達其他的 postcondition。在frame condition中必需明確指出其他會受要變動的物件，所有沒有列在frame condition中的物件，預設狀態都是靜態的，也就是在function/method執行期間，不會受到任何改變。

不同的軟體規格寫法

規格的寫法可分為兩大類: operational specification 跟 declarative specification，虛擬碼就是 operational specification最常見到的做法。declarative specification 並不明確定義實際達行的步驟，而是把執行前後的狀況明確的定訂下來。

在大部份的狀況下，declarative specification是比較好的寫法，因為他比較短，比較容易了解，更重要的是，declarative specification 不會提到實作的細節，讓實作的人有更大的空間，也避免使用者過度依賴特定方式的實作。

規格的強度

A specification A is at least as strong as specification B if

• A's precondition is no stronger than B's
• A's postcondition is no weaker than B's, for the stats that satisfy B's precondition

規格的強度，在考慮繼承的時候，更能顯示出他的重要性。

開張大吉

決定把跟軟體開發的文章獨立出來，不然，死人窩那邊真的是有點亂。