又到了一年一度的 Java Two 大會啦，今年照例有閃閃亮亮的 Java Girl，個個穿的像輕飄飄的仙女... orz 可能是我老了吧，對這種打扮過度的提不起什麼勁... (還是我還不夠老？！)。Anyway 早上一開場就是東吳國標舞社團帶來的熱辣森巴舞蹈，呃... Java 跟這個有什麼xxx.... ...還真有點突兀，但辣妹們奮力地扭腰擺臀到是不錯的提神劑啊~~ 緊接著卻是大官們的八股致詞... 馬上 orz... 雖然能聽到 Java 超高的應用數字還是令人感到無比欣慰，十年有成啊！
這一次請來了兩個原廠的員工，第一個是 Matt，講 Sun 在 open source 和開發環境的策略和企圖心.... 老實說儘管 Sun 的新動作很多、Open 的 source 也很多、IDE 投注的心力也很多... 但實際上為什麼一直不賺錢？不被開發者認同？IDE 沒啥人用呢？背後的原因也許很複雜吧... 個人倒是覺得最大的原因是：Sun 並沒有聽開發人員真正的心聲
另一個員工 Rima (?) 講的是 Java ME，這不是個人專長的領域，又是講英文，聽的霧煞煞... 最後，在有限的時間之內，Moli 把這兩天的要講的議題用幾個主題串接起來，大致地介紹了一遍。短時間內講的有調有理真的算很厲害了，但也狠狠地桶了講師幾刀。呵呵
第一個議題我選了 C-JDBC，這玩意以前曾k 過一些資料，後來發現不符需求就沒有試了。這一次希望能夠聽到實務的經驗... 可惜講師只準備了概念性的介紹... 而實務上像是 RAIDb 能夠增加多少效能啦，各種異質資料庫混用時要注意的地方等等比較重要的議題，就沒有提到了，而後來 live demo 也掛了。哎...
第二個議題選了 Java / .Net inter-operation。聽 Browser 轉述 Moli 說：講師李宗達乃 "神人" 也。好奇心趨使下就選了這個議題 (本來跟 .Net 有關的不大想碰)。一聽之下，乖乖，果然是神級的人物啊！inter-op分類的很清楚哪，總共四種作法：一是靠資料庫、二是靠 message、三是靠 runtime bridge、四是靠 adaptor ，各有優劣。講師也不唱高調，只拿真正有用的 solution 出來講，因此也談了一些 SOA、Web Service。雖然之前一直對這種東西很感冒，但聽講師這樣分析下來，沒這玩意還真難把系統給兜起來。後來的 Live demo，即使時間不大夠，中途還是寫了個小 JUnit，而不省去 Unit Test 這個重要的步驟。而可以 Unit Test，也代表這個 solution 是 POJO-aware 的。看了大是另人感動，此公真乃我輩中人啊！
最後一個議題選了 J2EE Anti-Pattern，講師慢調思理的風格跟上一場完全相反 (上一場東西多，又快)。雖然名為 J2EE Anti-pattern ，不過內容比較 general 一點，跟 J2EE 沒啥直接關係。他提到一個重點： Anti-pattern 多半靠管理層面來解決。這一點過去到是從來沒有想到... 嗯，其實這句可以更廣泛的解釋：任何專案失敗都得靠管理來解決 -- 有人程式寫不好，造成專案失敗，其實不管是他程式是哪種爛法，管理者都得花精神去處理這個人的問題，不然他就只有一直爛下去，下個專案再度失敗....；如果架構爛，表示沒有人有經驗、或是技術差、又或者是上位者根本就是眼睛瞎了，毫無遠見... 這當然也只有管理階層能解決；如果管理出了問題... 這個就不用說了，當然只有管理的人他們自己能解決了。大方向是由管理層面來負責，而實際上解決的方法、手段則需依各種症狀下藥，探討 Anti-pattern 就是探討病症以及如何下藥。
對於 Anti-pattern，講師提到是用 iterative 的方式來解決，而 design pattern 則是一次性的、完整設計好就採用。前者沒錯，refactoring 的確是漸近，iterative的；但是對於 design pattern 的觀念就不大對了。Design Pattern 並不是一次性的，他也是 iterative 的。講師在會議中不時提到，按照正統 RUP/UML 規畫設計，就可以得到良好的 OOP 設計，不然就會淪落為 structured, non-OOP 設計。這種說法並不完全正確... 除非這個系統已經做過好多次了，而且變化不大，不然按照 正統 RUP/UML，得到的 OOP / design pattern 只能算是半成品而已，甚至是完全 "套用錯了"。
"相信一次性的設計就能搞定，這個想法本身就是個 AntiPattern"
要解決這個 AntiPattern，就是重新思考 design pattern 的運用 -- 運用 design pattern 是 iterative的，它隨著使用者需求的增減變化，經過數次的 refactoring，才會漸漸成形。這個作法再廣義一點也可以應用在一般 OOP 的設計上。