(製作分享) JBoss - Seam 2.0 正體中文手冊

老魚常跟小沙瀰們說 ...
”” 我們當前走的這條”IT路”不管您是誰, 也不管您當前的年齡是小或老,
只要停滯學習, 甚至不專注於您自己的IT領域,
隨著時代的演進, 您的IT能力就被判定過時, 而且非常之明顯迅速！
將來的您我都極大的機率被當時點的小朋友就可取代您的角色．"""

就如同下面這影片背後帶來的另一層思考 ...
過時的社會價值觀與行為的鑑定標準, 在新生代身上卻極可能是一種誤判．


首先感謝來自簡體中文團隊- 满江红开放技术研究组 的英翻中的貢獻!!!
沒有他們的付出, 老魚也無法在正體中文的語意上下功夫完成本文件來分享給大家.

繼前天老魚對 JBoss Seam 的特色介紹, 對於參考手冊也替各位製作完成,
如果您未閱讀了解為何老魚在"當前"(未來不保證~呵)較推崇 Seam 的理由文章:

• 當前較佳的 Java EE 5+ 開發用框架 - Seam Framework

在本篇同樣貢獻給想學習或正在使用 Java EE 軟體架構的正體中文朋友們.
在這篇老魚再補上幾點使用 Seam 的理由:

1. Seam 同其名只是縫合線的工具集
   Seam 在 Java EE 5 以上的版本使用, 盡可能只做為對 EE 規範的不足的"小細節"上擔任縫合的角色(如下圖)
   
   不同於其它近似 EE Frameworks, 大膽加諸自家的技術規範, 偏離 EE 規範.
   Seam是一個功能完整(full-stack)的應用程式框架。Seam的功能正如其名，它扮演了「技術縫合劑」的角色。Seam可以輕易的整合許多新世代的技術，包括JSF、EJB3、Portlet以及jBPM workflow。
   
2. 非 EE 標準框架林立帶來的資訊成本是極高的
   建構在 Java EE 之上各式開放源碼的應用程式框架(Application Framework)如雨後春筍般出現。Java 開發人員可以根據其不同的喜好和需求去選擇不同的技術，並加以組合。是的, 這結果創造了豐富的 Java 參考資源, 但評估與選擇各式開放源碼應用程式框架的工作需要許多時間與經驗，太多的選擇有時也讓新手們無所適從，在學習上也是一種很大的負擔。
   更何論站在使用其特定框架做為公司 Base 開發的軟體專案, 公司的技術框架的選用評估, 很易因一失足成千古恨的風險性提高。遵循 EE 規範可能不是最佳的, 但卻是相對選用技術風險性較低的, 且隨著最多公司採用的 Spring Fremework 也加入到 EE 6 的制定專家組的行列, 可預見的 EE 標準最終還是巨型企業的軟體架構.
   
3. Seam 是一個採用 JavaEE 5 官方規格的整合性應用程式框架
   雖然官方規格是否為最好的選擇每個人的看法不盡相同，但是儘可能遵守標準規格可以確保具有第三方廠商的IDE工具支援開發，及針對其規格所提出的實作成品，相關的解決方案和產品的支援服務也會相對的比較有保障。
4. Seam 的 MVC 架構樣式
   由 JSF 來負責展現層的資料展示，EJB 3 的 Session Bean 負責商務邏輯層，而永續層則是由 EJB3 的 Entity Bean 負責資料的存取。Seam則介接於各層之中，以簡單且統一的方法來替開發者處理各個元件間的呼叫及生成。讓使用者可以免除撰寫多餘的程式碼，專心致力於商務流程與資料的呈現。

更詳盡的說明與第一個入門範例請轉讀:

• 利用Seam框架快速開發Java EE應用程式(1) — Seam 簡介 by 林士涵
  

最後要附上老魚轉製的 JBoss - Seam 正體中文手冊

• Seam_2.0_Reference_zh_TW.HTML.20090123.7z

當然建議搭配最新的英文手冊內容閱讀, 才不致於迷失於新舊版本間的小差異 !

• http://seamframework.org/Documentation

至於如果您有學習上的問題和想進行討論請移至

• JavaWorld@TW - Red Hat JBoss 專屬社群討論區

Happy Birthday - 祝魚生日快樂

生命是一個過程 ...
可悲的是它不能重來, 可喜的是它也不需要重來 !
未來是充滿希望的, 那怕你的生命只剩下一天, 也要好好活 !
- 電影:童夢奇緣

老魚先祝自己~

生日快樂, Happy Birthday !!!

可悲的是又老了一歲, 可喜的是離"駕鶴歸X"的當神仙的大限又更近了~呵
今天可是 123世界自由 是, 難怪我的人生使命就是 GNU/GPL 嗎~XD



來幾短較有趣的生日歌選送給慶生用~呵

可愛的3D動畫人物唱生日曲~


請二位大明星來助唱~呵
祝我生日快樂 - 周杰倫&溫嵐


來個廣東版


當然囉~這首是生日必點的金曲
康康-快樂鳥日子


最後這首送給曾經與老魚在生命中遇到的每一位大小貴人們~
感謝您們豐富老魚的人生!!!

當前較佳的 Java EE 5+ 開發用框架 - Seam Framework

繼前篇的的課外音樂選, 獲得不少朋友跟老魚說"好像有一點點腦力有效...",
那老魚這回分享給大家不失活潑的對唱, 女主唱同樣是 Sissel,
這回男主唱是位風趣的小提琴家 Kalle Moraeus :


聽完了對唱, 腦袋是不是較有精神了呢 ?

明天 23 號是老魚的大壽之日 !!!
老魚將奉上新的正體書(電子檔- -), 送給各位學習參考用!

• Seam 2.0 正體中文手冊

這篇的標題要先交待一下, 老魚沒經歷過 Java EE 1.4 含以前的時代,
老魚是從 Java EE 5 才正式想深入這軟體架構,
至於為什麼 ... 嗯~當中的"苦"老魚不想罵人, 各位就當從零開始就好~呵
所以

• 如果你也是正要開始深入 EE, 那請你從 EE 5 版學起即可 !!!

繼前篇的幾個重點, 再加上網友留下的問題, 在這篇就順便交待一下.

如何開始進入 EE 5 ?
這問題離不開 Sun 精心"安排"的 Java 技術認證的目標,
您可以從這頁連結去了解自己處於在那一階段,

• Java 認證 - Sun
  

每一張都有考試範圍, 至於學習方式呢 ?
看到範圍聰明的會去找書自己K, 懶的人就花錢找個好老師教囉~
但老魚沒要求你一定要取得認證才算哦!!!
(證照"薄紙"可以短期速成取得, 相信老魚真的很薄~
有些證書根本自己用印表機印也很像呀~呵
但真正的技術是真的需要你用長歲月投入換來的!)

在前篇老魚曾說到Java Web "框架(Framework)"技術, 夠用就好,
也提到框架不一定完全遵從著 EE 5 的構成組件與堆疊理論來發展,
這問題將導致幾點您必須思考的軟體長期成本的風險估算:

1. 納投名狀，結兄弟誼，死生相托，吉凶相救，福禍相依，患難相扶。(電影~投名狀)
   這類型框架組織的發展通常會由"曾經"的輕巧, 逐漸走向自樹一格完整的平台化產品, 您的團隊被迫必須不斷學習它甚至再堆疊入你的產品, 好的是新 idea 不斷被它所創建, 該平台的產品也易於被組建, 但可能的風險就隨著像毒品般你離不開它 ...
   
2. 推陳出新的版本速度快過您開發團隊的學習曲線
   團隊被迫停在舊的框架版次上, 進退不得, 安慰自己說: 版本太新問題很多, 那反之呢 ? 框架本身的安全性修補, 你落後了!!!
   

以上的現象經常發生在 Java 當前的眾多 Web 應用框架中,
尤其是在 2006 年 EE 5 未定案前,
那到底當前站在想應用上標準規範的 EE 5 甚至今年即將定案的 EE 6,
有無較好的學習參考框架或框架入侵架構較淺的產品呢 ?
(當然如果您是位反 EE 軟體架構的人,
而堅信其它號稱仍是輕量型的框架技術追隨者, 這篇就不合您囉~)

老魚在這跟各位推薦 - Seam Framework

老魚的理由是 Seam 是當前在骨架上真的落實去使用 EJB 3.0, JSF 1.2, JPA 1.0 等 Java EE 5 堆疊的框架, 在 EE 6 時也將同時採用更佳的 EJB 3.1, JSF 2.0, JPA 1.2 等改良, 並加入 JSR #299 - Web Bean 的新 EE 6 子規範於 Seam 中實作, JSR 299 專案的領導人正是有名的 Gavin King (Hibernate 及 Seam, Web Bean 的原創者) .

Seam 框架最讓老魚欣賞的是, 在其 Seam 的文件中它自述的第一項及其中另2項特點:

• Seam 只是一個"工具"
  (真是夠誠實~呵, 同它的名字僅充當縫合 EE 中各項組件於易用性)
  Seam為你的應用程序中所有的 EE 企業邏輯定義了一種統一的元件模型。
• EE 規範也非盡善盡美
  我們認為最新的 Java EE 規範很不錯。但是我們知道它還遠不夠完美。在規範中有許多漏洞（例如，GET請求的JSF生命週期中的局限性），Seam修正了這些漏洞。 Seam的創建者們正與 JCP 專家組一道，確保這些修正恢復到標準的下一次修訂中。
• 對 Groovy 的支持是內定的
  你可以在 Seam 中靈活應用 Groovy 帶來的優點 (其實是Seam本身就有使用它~呵)
  

老魚將 Seam 文檔中提到的其它特點轉述摘要如下, 有興趣的人可以前往 Seam 官網閱讀它:

• 將 JSF 與 EJB 3.0 整合
  Seam 將 JSF 和 EJB 3 的元件模型合二為一，消除了膠合程式碼，使得開發者專注於業務問題。編寫「一切」都是 EJB 的 Seam 應用程序是有可能的。
• 在任何Java EE應用程序伺服器中都可以運行
  Seam 在任何 Java EE 應用程序伺服器中都可以運行，甚至在Tomcat中也可以。如果你的環境支持EJB 3.0
  
• 整合 AJAX
  Seam支持兩個最好的、開源的基於 JSF 的 AJAX 解決方案：JBoss RichFaces 和ICEfaces。 Seam 也提供了內置的 JavaSctipt 遠端存取層，它讓你非同步地從客戶端JavaScript 中調用元件，而不需要中間的 action 層。
• 將企業流程作為首要的基礎建築
  Seam 可以選擇通過 jBPM 提供透明的企業流程管理(BPM)。
• 宣告式狀態管理
  宣告式應用程序狀態管理通過Seam定義的豐富的context model（上下文模型）而成為可能。
  Seam擴展了Servlet規範—定義的上下文模型——請求、Session、應用程序—增加了兩個新的上下文— 交談和企業流程—，從企業邏輯的角度來看它們更具意義。
• Bijection（雙向注入）
  Inversion of Control（IoC, 控制反轉） 或者 Dependency Injection（DI, 依賴注入） 的概念出現在 JSF 和 EJB3 以及很多所謂的「輕型容器」中。
  Bijection（雙向注入）和IoC的不同之處在於它是動態的、語境相關的以及雙向的。
• 工作區管理（Workspace Management）和多視窗瀏覽
  Seam應用程序讓使用者自由地在多個瀏覽器視窗中切換，每個視窗都與一個不同的、安全隔離的交談關聯。Seam 不僅提供正確的多視窗操作，還提供在一個視窗中模擬多個視窗的操作。
• 更喜歡 XML 註解
  Seam 擴展了EJB 3.0 提供的註解，以用於宣告式狀態管理和宣告式上下文劃分。 這讓你擺脫了對繁瑣的 JSF managed bean(JSF 受管 bean）的配置，減少了所需的XML，只剩下那些真正屬於XML的資訊（JSF導航規則）。
• 整合測試輕而易舉
  你可以輕易地編寫重現與使用者完整交互的 JUnit 或 TestNG 測試，來演習除了視圖View（JSP 或者 Facelets 頁面）之外的所有系統元件。
• Web 應用程序不只是服務 HTML 頁面
  Seam 為持續化整合了JPA 和 Hibernate 3，為輕量化的非同步性整合了EJB Timer Service和 Quartz，為工作流整合了jBPM，為業務規則整合了JBoss 規則，為電子郵件整合了Meldware Mail，為完整的文本搜尋整合了Hibernate Search 和 Lucene，為訊息整合了JMS，以及為頁面片斷捕捉整合了JBoss Cache。 Seam 在JAAS 和 JBoss 規則之上，創建了一個新的基於規則的安全框架。甚至有用來輸出 PDF、在線電子郵件和圖表及wikitext的JSF標籤資源庫。
  
• Seam 元件可以同時作為一個Web Service進行調用，非同步地從客戶端 JavaScript 或者 Google Web Toolkit，或者當然也可以直接從 JSF 調用。

再接下來的日子, 老魚將陸續分享相關 Seam 的心得 ...

學習 Java EE 前應有的正確概念與觀點~老魚經

先來個課外音樂的欣賞, Sissel 與 Jose Carreras 的演唱
老魚很喜歡聽這類的演唱帶給魚腦的學習力增強波, 希望對各位也有用 ...



回到主題:
老魚整理了初探 Java EE 的小沙瀰們最常問道的概念, 如下:
(部份內容將收錄於老魚的 Java EE 研究論文)

1. Java EE 是一種軟體架構與設計思想
1. 老魚建議您長年去閱讀研究它, 而不要偏重習於特定產品, 產品會過時.
2. Java EE 的體現在於您自己, 沒有速成, 更別想從短期的課程甚至一場簡報中習得, 霧裡看花, 相信老魚這些規範內容夠你唸好多年包括實作, 還不能完全理解, 包括老魚也是其中一個, 所以到今天仍像考生般K書的老老魚~呵
   
2. 懂得開發 JSP / Servlet 不表示了解 EE
1. 這方面的Web容器知識量僅佔 Java EE 約 1/10, 但夠您完成任務.
   
2. 懂得開發只是技術上的熟練度, 但您真的了解您程序中為何而用的事由嗎 ?
3. Java EE 內的子議題更包括安全性, 各組件間的溝通, 事由 ...
   
3. Java EE 的所有組件規範基礎為 Java SE
1. 不要以為學 EE 可以減低 SE 的了解, 相對的您必須知道更多 SE 的知識內容
   
2. 請同老魚一樣保持閱讀 Java SE 習慣在每一天.
   
4. Java EE 是經由 JCP 成員投票後通過的規範, 適用於願意採用的所有企業.
5. Java EE 目前的16個表決成員中除了 SUN 還包括有:
1. Apache Software Fountation
2. Google Inc.
3. IBM
   
4. Intel Corp.
5. Oracle
6. HP
7. SAP AG
   
8. Red Hat ... 等等
6. Java EE 是規範, 產品實作由各家軟體公司實作, 不是"專屬特定"公司包括 Sun, 在一個規範標準下做良性的技術競爭.
   
7. 任何有自主開發能力的公司都可以依俱規範開發自己EE產品或其相關的子規範實作, 但必須經過測試相容性認證, 這也告訴您有高達10個以上的 JEE 產品供你選用, 目前符合 JEE 5 認證的開源專案或是商業產品如下:
1. JBoss Application Server Version 5
2. Apache Geronimo 2.0
3. Apache OpenEJB via Apache Geronimo
4. IBM WebSphere Application Server Community Edition 2.0, based on Apache Geronimo
5. IBM WebSphere Application Server V7
6. WebLogic Application Server 10.0 from BEA Systems
7. Oracle Containers for Java EE 11
8. SAP NetWeaver Application Server, Java EE 5 Edition from SAP
9. Sun Java System Application Server Platform Edition 9.0, based on the open-source server GlassFish
10. GlassFish
    
11. JEUS 6, an Application Server from TmaxSoft
8. Spring Framework 是“產品“, Hibernate Framework 不是ORM的“規範“也不是唯一的選擇, 是一項符合 JPA 規範的產品, 而非等於 JPA, 其它符合的產品:
1. Apache - OpenJPA
2. Eclipse - Eclipselink
3. Oracle - Toplink
9. JEE 的規範與其子規範群內容, JCP 的網站中均有提供完整的規範文件PDF檔可供自由下載, 每一個規範大約雍有300~1000頁間不等的詳盡內容. Java EE 的規範是嚴謹的, 強調資訊安全的風險考量, 所以規範的文件量也跟著提高.
10. 正確的學習不讓自己受限於特定的框架技術與技巧甚至IDE
1. 框架學的夠用就好, 您一輩子也學不完, 專精特定框架的代價在於, 您是否能保證該公司或是下個工作都能順利讓您使用您專精的框架, 那就值得.
2. 框架技術不一定是標準, 因其非需要嚴格遵守JEE規範, 通常也較大膽的使用創新技術或非正確的處理邏輯, 資訊管理風險必須考量.
3. 特定的框架技術通常也依賴特定的套件庫, 特定的JEE Server與IDE開發工具, 這點會讓您的自主性受制的非常深, 尤如淡水魚置入海水釭, 或反之, 這點很明顯的存在於當前的 Eclipse IDE 與 NetBeans IDE 間 Plug-in 的競合關係.
   
4. 閱讀與真正的去了解 JCP - JEE 各規範的內容, 再回來看這些框架的實作, 才是長遠之道.

[Java線上遊戲伺服器]同時線上人數上升造成的問題與解決參考

先來看幾個小篇 Videos 在 3D多人同時線上GAME中,
最經常看到的就是大型的玩家齊體的活動畫面,
例如攻城, 盟戰, 狩獵 ...等等







因為上述的遊戲內容,
造成老魚時常收到這樣類似的二岸中文用戶對 L2J 架設 Mail 來信詢問同樣的相關問題 ...

例如近日的來信:

• 您好！郭朝益老师
• 我是大陆的一个天堂２爱好者（极品玩家）.呵呵　我有一个问题困扰了我很长时间.
• 我在我们学校内架设了一个Ｌ２Ｊ版本的天堂２服务器（学校的网络是１００兆的宽带　服务器CPU：Intel 四核至强 E5320　８Ｇ内存）．不知道什么原因，只要人超过２００人在线时候服务器就会卡的很厉害，如果到３００人在线时候基本上就玩不了了．然后我把服务器端重新启动后就好了．但过一会还是一样卡的很厉害．..."""

(老魚我先聲明我沒鼓勵這樣的行為哦~呵)
(當然這現象在正式的商業線上遊戲公司是不能發生的品質現象,
商業公司可以透過購置高階資訊設備, 及增加資訊專家群來克服)

老魚今天要談論的是一項"學術交流", 更何況無商業化的經費預算~呵
"在經費受到嚴重限制下的 MMORPG Server 的管理之道"
這背後涉及到的可能問題, 卻可能來自任何一個層面...

基本上頻寬是足夠的, 但往往因GS(Game Server)處理速度過慢,
導致伺服器產生Lag(形容造成畫面延遲的現象),
這也通常大多發生在玩家們進行大型狩獵活動, 或者血盟戰時,
因同一時間瞬間大量 Data 來自玩家進行對玩家或NPC狀態變化的技能,
傷害處理程序需龐大的資料運算, 造成 Server 在處理上產生 CPU 滿載 100% ,
系統也常高次數的必須對實體儲存體進行 I/O 處理現象發生,
再加上 Server 亦需要回傳給所有Client 的玩家們 ...
以致於可能讓伺服器可能延遲超過數十分鐘, 或因RAM堆疊處理資料超出,
導致甚至更久或 Server 完全停止.

基於開放源碼 Java 與對 3D MMORPG 的研究者來說, 經費有限的情況下處理,
老魚建議由下面的參考:

除擁有保持學習心態的網路伺服器管理員之外, 目前可進行的改善空間為:

1. 當然首先更強的硬體主機, 尤其是 CPU.
   
2. 優品質的網路線路頻寛!
   
3. 作業系統的種類: 建議以 GNU/Linux 為主. (重點)
   
4. Firewall : 建議阻斷所有與遊戲伺服器有關之外的所有連入連線 Port.
   
5. 防毒軟體 : 如果有遵從上述三點, 那大可不需要, 且可大幅減少因防毒軟體對系統資源的不必要浪費性.
   
6. Java JDK 版本, 建議以較新的版次先, 通常也擁有較佳的 JVM 性能表現.
7. 隨時留意是否有 l2j 重大或者必要的更新.
8. 持續您對系統安全的監視, 例如惡意的「阻斷式服務攻擊」（Denial of Service, DoS）的來源 IP 封鎖任務.

額外的可能問題與再增強:

1. 於適當的時間點進行系統重置, Reboot.
2. 裝載以實體RAM層模擬成檔案系統儲存層的技術或軟體, 減少I/O的真實往返, 資料再定期(例如 15分)寫回真實的資料儲存層.
3. SSD 碟替代傳統軸承硬碟
   
4. 劃分 LS, GS, DB 為各自獨立的硬體主機.
5. 切割玩家的所在伺服器世界
6. 進行第三點的負載平衡(Loading Balance, LB)建置工程, 幻想著 ... SAN@@"
   

目前較無法由 Server 管理者克服的問題:

1. Client 服務對象玩家本身的頻寬品質低劣人數過多, 造成Server必須"等待"處理過長, 拖累整體Server效能表現.
   
2. NPC 獨立伺服器

更多的補充將直接載文於:

• 架站常見問題說明
• Java MMORPG 遊戲伺服器研究中心

另外 L2J-GAME 中文團隊正在招募新血成員, 歡迎想參與學習這方面的知識朋友加入,
不限二岸三地的愛好者們.

Java 7 與 Groovy 就語法上增強的關聯分析表及老魚觀點

老魚習慣在每篇文的最前頭置上我最愛的中文古思想學,
來看看一小段 Video ...
在看之前, 請試著把當中所要表達的, 全在您心中先換成您當前的“專業技能“...
磨瓦成鏡-達摩傳


何謂禪? 單心也! 直率坦真之心~
換成您的專業領域替換當中的詞, 您看了什麼？

老魚教了不少學生, 在公司的軟體專案也來來去去看了不少老魚生命中的過客,
您的技術程度和對自己的專注態度, 一言一行, 一問一答間, 都已明顯的透露著,
您的戰門值就能像“七龍珠“中那“高科技單眼鏡“估算的出來 !

“態度決定一切“, 這句話用在您自信的專業技能上也是, 是空是飽 ?
“技在精不在多“, 試著了解自己心的根本上“要“修什麼, 它將決定您的技術結果!
“罪由心生, 亦因由心滅", 要了解這"罪“字非惡也, 只是形容 Event ~呵

回到本篇標題：
Java 7 可能但也有很大的變數加入或決定不加入新的語法上的特色,
但老魚個人對這些新語法, 個人看法是不太贊成 ! 理由如下 :

• 任何語法的改變都可能深遠的破壞如文章般優雅的Java Code
  (雖有時看似煩雜的, 但細看過程卻是交代的非常清楚)
• 過多的使用如其它語言的語法"蜜糖", 簡化表現, 卻可能遮蓋了背後的問題與過程資訊.
  
• 站在初學者的立場看, 這將使原本嚴謹學習成本高的Java, 更加對初學者不友好.
• Java 應該專注在 JVM 的效能和 API集的持續增強為根本, 成為Scripting之根即可.
  
• 這些語法上的變化蜜糖, 可以透過 JVM Scripting 例如 Groovy, JRuby, Jyphon ... 來實作即可, 既不破壞原本 Java Code 的美, 又可以擁有這些豐富的新語法.

在下圖中, 為 Java 7 或者 8 .. 將“可能“納入的語法新特性:



當中有不少老魚早就透過 Groovy 擁有了大部份, 且又能編譯成 Java bytecode
(圖中的淺藍色線是目前Groovy可以做到的, 其它在不久也將納入新版 Groovy)
, 供 Java 直接執行, 透過 Groovy 老魚也很便利的一直在使用與研究著 Java 7 新API,
請見另一篇文：

• Java SE 7(JDK 1.7-nio2) 與 Groovy 關係是簡約與相輔相成

基於此老魚個人不是很贊同這方面的變化, 但老魚改變不了這過程,
該研究該學習的, 老魚還是要同學生般的"好好用功學習!!!"

(分享製圖)Java 測試框架 JUnit 與Groovy & Grails

劍法最高的境界-電影"英雄"片斷


每一部電影雖然短短才2個小時 ... 但如果拋開那聲光畫面的效果,
用您的心去聽去感受問題背後的問題(QBQ),
試著去感受那位用心寫"劇本"和導演想表達的意境,
您將擁有更多人生上自己所不能達的感悟與轉化心境!
~老魚經

JUnit: http://www.junit.org/
JUnit 是 Java 用的軟體開發的測試框架, 用來提升開發者程式的"品質",
說到"品質"對一般的開發者來說是"可忽略"的 (沒空嗎?是籍口還是 ...)
但對想自我挑戰成為一位優秀的開發者來說, 這是一把心中的"劍",
劍不是難在"招術"或"名劍"上, 而是難在"無劍", 同理用在這 ...



JUnit 僅是一種測試驅動開發(Test-Driven Development, TDD)的技術之一,
難~不是難在其 JUnit 的使用與撰寫方式,
而是其背後要您深植於心的品質測試目的"初心"!
不是強或弱在任何一種開發語言, 是"人"本身的問題!!!

(點圖放大再另存)


而 Groovy 出於 Java, 應用於 Java, 更大幅簡化 JUnit 並內化為 GDK API,
使用上也比 Java 再更精簡易於使用, Grails 則是加以變化為 Web TDD,
來提高Web應用的程序品質 !

老魚提供的圖表, 不在於協助入門, 在於協助有心人學習上的一個助力圖表.
(太公釣魚 ... , 話說 ... 三國劉"阿斗"真的有必要幫他嗎 ?! )

Java SE 7(JDK 1.7-nio2) 與 Groovy 關係是簡約與相輔相成

Java SE 7 將在今年發佈,
當中最棒的一個特點將帶來一個全新的檔案系統的API集,
這個理由最主要是：
舊有的 API 過於陳舊, 功能角色定位不清, 且不太符合當今的多樣化作業系統,
例如 java.io.File 是在 JDK 1.0 大約十年前的作業系統時代背景下制定,
十年後的今天, 各家作業系統(OS)不斷演進, 有必要且有需要一個全新的API,
來接替 java.io.File 這位API老人家的工作 ...

來看看老魚的簡單例子先：

• OS：GNU/Linux Debian (unstable)
  
• JDK: 1.7.0-nio2 , HotSpot VM 14
• Groovy: 1.7 b1
  

首先我們用Linux下的文字編輯器 vi 來分別用 Java 與 Groovy 完成二個相同結果的程序,
用來判斷指定的檔案是否存在, 以 JDK 1.7 NIO2 實作：

Java版: 嚴行命名約定, 我們為這檔案取名 PathTest.java 與程序內class同名.

import java.nio.file.*;

class PathTest {
public static void main(String[] args) {
 FileSystem fs = FileSystems.getDefault();
 Path path1 = fs.getPath("/etc/hosts");
 Path path2 = Paths.get("/etc/sysctl.conf");
 System.out.println("path1 = " + path1.exists());
 System.out.println("path2 = " + path1.exists());
}
}

"審慎的"確定code沒問題後, 請出了 javac 來為我們編譯成靜態執行碼後,
執行它 ... 其實也沒什麼大事 @"@ 就印出二小行結果,
判斷二個指定的檔案是否存在於系統中:

path1 = true
path2 = true

Groovy 版: Scripting 命名是鬆散的, 隨便您取名例如 fish.groovy ...


來看看 Groovy 對 Java 做的改變

1. 命名上可以是鬆散的, 型別也可以被省略
2. 約規的宣告式也可以省略(public static void main())
3. ; 分號可有可無
4. 不需編譯過程可以直接執行, 開發速度上變快了
5. 仍可選擇完全編譯成 java bytecode 執行
   
6. Code 變的簡潔, 可更不需要依賴IDE, 僅用 vi
   
7. Groovy 仍依附著Java, 不是替代是相輔合一
8. 可使用全部JDK的特性, 但對Java開發者來說學習成本很低, 多為簡化式子
9. 型別省略不代表它為弱型別Scripting, 由下面的 assert 可驗證

更多請見老魚獨立專案的持續分享

• 2G::Groovy.GRails:中文

New Project: JFFA(Java Financial Functions API)

人生是一個過程 ...
可悲的是它不能重來, 可喜的是 ... 它也不需重來 !
~ “童夢奇緣“電影名句

老魚無法預知Blog內的一切分享與貢獻能替老魚在未來獲得的是何種評價,
但我的內心告訴自己必須留下這些過程記錄, 留給下一位進場的學子或研究員,
終有一天我會老去, 失去原本的學習與奉獻的熱忱, 失去原有的記憶力,
但這裡的一切需要不斷前進, 我必須退場, 無私的轉交這一切給願意接棒的您 ...

“童夢奇緣“這是老魚前些年覺得內容值得思索的“讀“電影(老魚愛字幕>畫面),
下面這段剪輯中的對白, 道出了重點, 學習老魚“讀“電影字幕~呵


有興趣者~在本篇的最後放了這部電影的MV主題歌~“讀“歌詞去

回到本篇的重點：
在去年底時老魚開始寫 AIS 的內容 (和老魚有關的延伸項目都置於本Blog右上囉)

• 唯有會計人最了解自己需求的AIS! (老魚新開放專案)

讓老魚在元旦前一天, 決定發起這標題的新子專案:
JFFA - Java 財務函數庫 API
初期我想也只能由我先開工撰寫, 但老魚希望有更多人給於建議或參與開發它,
這專案的受惠者是將來的 Java 人與財經相關的專案.
寫了四天也完成了8個函數, 嗯初期是以40個Excel中的財務函數為目標.
老魚會盡可能依JDK API的開發規範(設計模式, 效能)後進行, 願它能進入 JDK SE 中.
老魚希望在離開 IT 工作前, 能留下更有價值的大腦遺產.

話說回來, 這API專案好像比較能讓老魚的貢獻走向全球性~XD
沒想到過了快十年, 還是又把“財務分析“的課本再次拿上桌 ~"~

同樣的老魚會將這專案的連結置於本Blog的右上, 但先來做點介紹的廣告:
主要開發網站置於：http://code.google.com/p/java-ffa/
API JavaDoc : http://javaffa.openfoundry.org/ (老魚我可很有心的用“中文“優先記載它)
討論區: http://groups.google.com/group/wisdomfish-ais--jffa
進度清單: http://sites.google.com/site/wisdomfishaccounting/java-accounting-api/devprogress
原始碼: http://code.google.com/p/java-ffa/source/list

目前是 0.1-dev 版, 所有API都可能重新再設計, 包含命名, 不建議產品使用,
另廣徵開發者與建議~謝謝各位

祝各位新年新如意~但老魚要自頌懺悔文

若問前生事, 今生受者是; 若問後世事, 今生做者是.
- 佛說三世因果經

元旦新年到, 希望大家年年如意 !
"因果"是佛教最重要的根本論之一,

它強調任何人事物間的時間交錯全來自"種因"與"果報",
上述的經文來自佛陀弟子問釋迦牟尼的一小句講述文摘,
佛陀說, 在輪廻三世中, 種善惡因必得相同的果報,
老魚套句更直接易了的電影"無間道"中的台詞:

出來混 ! 遲早都要還的 !
Beyond - 無間道2 長空 MV - 這首MV的詞您可以好好體會看看~

嗯~很多因果不用等到三世~"現世報"這句我想大家都可以感受到,
當然老魚自已也在今天之前, 尤其是去年親身受到這果報的業力影響甚大.
因為我自己種下的惡因, 痛失我最重要的人,
因為我的對人事物偏頗的人生價值觀, 失去好多原本應有的果報 !
先來唱頌"懺悔文"吧 / . \ (詞很有意義, 建議看看.)


老魚在今年要重新思考, 剩餘的有限人生時間分配與追逐目標是不是真的錯了 ...
也許是該離開這長年有著老魚快樂與悲傷的"高雄市", 不要再將自己鎖在井中 ...

老魚在今天向曾經因緣相會的所有人及痛失我最重要的的人說聲~
用一輩子感謝的心~謝謝您們！不管您給予我的是好與惡~
用一輩子懺悔的心~跟你說聲"對不起 ! 我真的傷到你了~"
今後老魚會將之當成警惕自己的教訓於心中~

最後老魚想用首歌來隨時告訴自己要珍惜身邊的人事物與勉勵自己在未來的每一天!

(感謝我的日文老師讓我聽到這首歌) - "千の風になって"
這首歌很悲情，當時還寫下了歌詞，悲情中帶有勵志。


這裡有篇這首歌的專題文章Blog(建議你去了解一番)
老魚僅將歌詞中譯轉載於下:

「化為千風」 （譯：張桂娥）

請不要佇立在我墳前哭泣
我不在那裡 我沒有沈睡不醒
化為千風 我已化身為千縷微風
翱翔在無限寬廣的天空裡

秋天 化身為陽光照射在田地間
冬天 化身為白雪綻放鑽石光芒
晨曦升起時 幻化為飛鳥輕聲喚醒你
夜幕低垂時 幻化為星辰溫柔守護你

請不要佇立在我墳前哭泣
我不在那裡 我沒有離開人間
化為千風 我已化身為千縷微風
翱翔在無限寬廣的天空裡

化為千風 我已化身為千縷微風
翱翔在無限寬廣的天空裡

翱翔在無限寬廣的天空裡

最後再補上一個 Video 來隨時激勵自己堅強的面對明天!!!