Strehgth@TW

關於 Java 核心與相關 API 的使用, 各位可以參考以下網址
http://java.sun.com/j2se/1.5.0/docs/

另外, 關於 Logger 的部分, 請參考以下連結,
http://java.sun.com/j2se/1.5.0/docs/guide/logging/overview.html

Logger Sample01:
public class SimpleLogger01 {
   public static void main(String[] args) {
   // 因為使用了Logger類,所以需要匯入java.util.logging.Logger
   Logger logger = Logger.getLogger(SimpleLogger01.class.getName());"
   // 因為使用了Level類,所以需要匯入java.util.logging.Level
   logger.log(Level.INFO, "this is a info");
   }
}

Logger Sample02:
public class SimpleLogger02 {
   public static void main(String[] args) {
       Logger parentLog = Logger.getLogger(SimpleLogger02.class.getName());
       parentLog.log(Level.INFO, "this is a info");
   // 設定 parentLog 的 Level 為 WARNING,
   parentLog.setLevel(Level.WARNING);
   // 以 parentLog 為範本建立新的 childLog, childLog 將會繼承 parentLog 所有特性
   Logger childLog = Logger.getLogger(SimpleLogger02.class.getName());
   // 因為繼承的關係, childLog 的 Level 為 WARNING, 所以INFO記錄不會被發布
   childLog.log(Level.INFO, "this is a child.info");
   childLog.log(Level.WARNING, "this is a child.warning");
   }
}

Logger Sample03:
public class SimpleLogger03 {
   public static void main(String[] args) {
       Logger logger = Logger.getLogger(SimpleLogger03.class.getName());
       logger.log(Level.INFO, "this is a info");
       logger.setLevel(Level.WARNING);
       try {
           // 因為使用了FileHandler類, 所以需要匯入java.util.logging.FileHandler
           // %t = System.getProperty("java.io.tmpdir") 路徑
           FileHandler fileHandler = new FileHandler("%t/"+SimpleLogger03.class.getSimpleName()+".log");
           logger.addHandler(fileHandler);
           // 因為在<>\jre\lib\logging.properties 預設了ConsoleHandler, 一般情況下可在控制台看到日誌
           // 這裡用 FileHandler 替換 ConsoleHandler
       } catch (IOException e) {}

       // 請注意看輸出的日誌, 日誌檔案中看到的輸出格式為XML格式
       Logger childLog = Logger.getLogger(SimpleLogger03.class.getName());
       childLog.log(Level.INFO, "this is a child.info");
       childLog.log(Level.WARNING, "this is a child.warning");
   }
}

相處之道

2009-03-05T21:55:00.000-08:00

朋友寄給我的一封信，簡單的幾句話，是點點滴滴積累而成的生命智慧

1. 沒有一百分的另一半，只有五十分的兩個人。
2. 付出真心，才會得到真心，卻也可能傷得徹底。保持距離，就能保護自己，卻也註定永遠寂寞。
3. 通常願意留下來跟你爭吵的人，才是真正愛你的人。
4. 有時候，不是對方不在乎你，而是你把對方看得太重。
5. 冷漠有時候並不是無情，只是一種避免被傷害的工具。
6. 如果我們之間有1000步的距離，你只要跨出第1步我就會朝你的方向走其餘的999步
7. 為你的難過而快樂的是敵人，為你的快樂而快樂的是朋友，為你的難過而難過的，就是那些該放進心裡的人
8. 就算是 believe 中間也藏了一個 lie
9. 真正的好朋友並不是在一起，就有聊不完的話題，而是在一起，就算不說話，也不會感到尷尬。
10.朋友就是被你看透了，還能喜歡你的人

20090221 課程回饋

2009-02-26T23:57:00.000-08:00

2009/02/21 JPA(Java Presistence API)課程後，節錄以下回饋資訊

學習心得：
1. JPA 技術免去過去繁瑣的 hbm.xml 的設定所造成手誤，快速增加開發速度。
2. ORM 的實踐必須完全放棄 ERM 的設計思維還有使用的設計技巧這些會造成ORM 設計上得錯誤。
3. Persistance 建立的 EntiyManagerFactory instance object 有 thread safe 的設計，但是它所建立的 instance object 本身並沒有 thread Safe 的設計，這容易遭成應用上的疏忽。
4. Unit test 提高軟體的品質。不是靠最後辛苦的亡羊補牢，而是開發過程中經過設計且綿延的測試才可產出有品質的軟體。
5. 這次上課有發現 JPA 的一些功能，如：getReference 提升效能的方法，另外對於JPA 的 Annotation 感覺有滿有用的，如果有自訂錯誤訊息的功能就更好了
6. 在這次的課程中我有提出客戶端老是喜歡變動資料庫的動作，比如說倒資料進DB，這部分在有id的Table且有關聯的狀況下會死得很慘，如果客戶的資料庫不得不變動的情況下或許所上的課程會不敷使用

改善建議：
1. 多點討論！類似像 head first 系列的書列出的問題相當有意思
2. 這次課程比較接近給用過hibernate並且要轉JPA的人來上若是沒有用過 hibernate的人來上課可能會不易聽懂
3. 這次的課程雖然很清楚的講了JPA的實作, 但是對於開發大型專案的時候較容易遇到效能的問題如果能夠有多一些多層次資料的提升效能的寫法，將會是有很大的幫助(PS 這點僅供參考)

學習方向：(近來發現的學習方向，如果學會了，對我們這個團隊應該有幫助)
1. JPA 和 Annotation 的應用 AOP 的開發概念。
2. Unit test 專案中使用的測試案例與實際UI建立後所作的測試其前期測試與後期測試誤差太高。
3. 因為我本身會 hibernate 的技術，學完JPA後覺得JPA是對於hibernate的upgrade，又加深對於資料庫存取的了解，也多了一點對Annotation的應用方面更多的思考，若是再有新專案開發，希望能夠將 JPA 搭配使用Annotation來檢核Business Object，如果再利用Annotation把多國語言也做出來，一定會讓開發更是快速且簡單

不景氣, 但心靈富足

2009-01-18T17:55:00.000-08:00

生命的饗宴

2008-12-31T18:23:00.000-08:00

繼最後的演講之後，看到了另一段觸動內心的演講，如果是我，我會像他這麼樂觀？也許不會，但，我們可以學習認識自己，選擇不去在意杯子之外的牛奶，再出發 ^_^

081225 課程回饋

2008-12-31T01:52:00.000-08:00

2008/12/25 物件導向(OO)課程後，節錄以下回饋資訊

學習心得：
1. 講師提到的TestCase是我印象最深刻的地方..因為testCase關係也對自我程式的一種防火牆.在寫程式時就先考慮了各種可能的情況.
2. 專案開發時先確定最重要的部份ex:100個需求/20重要/5務必最重要的5條需求務必要先出來.其他需求則是後面確定後再開發
3. 瞭解從需求訪談至系統上線的全部流程
4. 學習系統分析及系統設計的文件如何製作
5. 上課講的東西聽完是有感覺的，可是有感覺跟會不會是另外一回事，聽完之後覺得會的東西還真是少ㄚ，看來要好好充實自己一下了。
6. 專案開發文件部分，看起來很簡單，自己做發現還真的滿難的，我是覺得一來是要經驗累積，一來真的是要改變看事情的心態，因為我常常會以程式面來看專案，而不是以專案來分析功能
7. 對於程式部分，發現現在新的技術真是多，學完一種可能另一種又出現了，永遠趕不上；而且要把MVC架構表現出來，個人覺得不好實現，一句老話：還是經驗
8. 點醒了心中一些疑慮，讓我恍然大悟，原來就是這樣一回事。之前與同事到客戶那訪談需求時，心中所想的就是：我要怎麼解決問題，而非：問題有哪些，所以心中一直覺得怪怪的、開發的過程中也遇到很多當初訪談時沒有切確問清楚的部份，雖然進度如期，但是一路跌跌撞撞的。觀念與立場釐清之後，相信下一個案子會更順利。
9. 需求訪談的經驗分享讓我覺得受益良多，雖然說大致上知道可能會有哪些問題，但那僅只於技術上的，必須要站在使用者的立場思考，才有可能更深入的去問到使用者的問題；在訪談完分析之後再去列出相依性的的關聯來決定開發的優先順序，讓我覺得這是一個很棒的方法，之後的專案會讓自己以這樣的角度去切入寫出SD。

改善建議：
1. 目前自己還沒有一些想法,但是還滿想知道一些新的技術與應用方式的
2. 希望以我們實際開發的專案來做為教學範例，因為教材的系統範例往往比較簡單
3. 可否提供相關資料的研讀網站或書籍，可以讓我們繼續研讀

學習方向：(近來發現的學習方向，如果學會了，對我們這個團隊應該有幫助)
1. 可以試著使用TestCase方式來達到程式的穩定度.這樣對於整個的品質相信應該會有正面的效果.也減少錯誤發生的機率
2. 我需要養成良好的寫程式的習慣,以及努力學習自我本身coding的能力
3. 學習如何利用tool節省製作文件的effort
4. 學習如何準確分析需求、闡釋需求內容，讓系統從分析至開發階段不會有落差
5. 學習Junit測試工具的使用，這樣因該可以將Bug降到最低
6. 學習UML，至少要看的懂圖示

JPA - persistence.xml 設定問題

2008-12-26T15:55:00.000-08:00

題目是沒設定在 persistence.xml 當中的 class，系統還是會自動 load 並產生對應的 DB 欄位，要怎樣排除呢？
答案是在設定檔案當中加上一行 <exclude-unlisted-classes>，參閱以下範例

<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
   <persistence-unit name="sample">
   <class>sample.Bean1</class>
   <exclude-unlisted-classes/>
   </persistence-unit>
</persistence>

計畫的基本元素

2008-12-19T04:12:00.000-08:00

服務過程中常被問到的問題之一，就是計畫，怎樣寫計畫書或者大綱結構之類的問題，專案計畫跟任何的企畫書一樣，目的都是為了溝通並確認達成專案目標的管道、步驟，因此，計劃書的資訊不宜過多或不足，這當中的分寸要怎樣拿捏呢？

以我初淺的經驗去看，我認為計畫一定要交代：人、事、時、地、物、數，
1. 人：專案組織圖，權責
2. 事：表達的重點是執行過程當中的任務，昨天提過用幾點去展開, 含：分析、設計、開發、測試、建置、移轉等基本任務
3. 時：以上這些任務要執行多久？時程安排
4. 地：除了我們認知的工作地點外，環境還代表了專案執行過程用到的設備，例如：開發環境、測試環境、版控環境
5. 物：專案執行過程中，會交付哪些成果給客戶？例：專案執行計畫、雛型系統、設計規格、使用手冊、原始程式碼。
6. 數：成本估算數字，簡單來說就是報價單

此外，再加上建議解決方案即可，除非客戶要求，絕對不要加上其他非必要資訊，以免失焦，反而造成溝通不良。

EJB3 入門案例 <3>

2008-12-17T02:50:00.000-08:00

前一篇 EJB3 入門案例 <2> 說明了 Stateless Session Bean 的生命週期與 AOP 處理方式, 這篇報告說明了 EJB 跟 JPA(Java Persistence API)之間的整合與開發案例, 也是最常見的 EJB 應用基礎, 希望能帶大家進入更實用的領域.

EJB3 入門案例 <2>

2008-12-08T18:40:00.000-08:00

說明 Stateless Session Bean 的生命週期, 並對入門案例<1> 進行重構, 用代理機制包中 Remote EJB, 讓遠端 Client 可以很方便地利用, 詳細資訊請參考以下簡報:

EJB3 入門案例 <1>

2008-12-08T07:43:00.000-08:00

關於 EJB3 的理論部分仿間有很多參考資料, 各位可以參考 Mastering Enterprise JavaBeans 3.0一書, 這份簡報採取的是實務觀點, 用實際案例逐步前進, 希望能讓大家更快入門

環境配置如下：
1. Eclipse IDE 開發工具,
2. JBOSS v5.0 Application Server 做為 EJB Container

開發步驟如下：

夫春生夏長，秋收冬藏，此天道之大經也。~史記太史公自序

2008-12-04T17:57:00.000-08:00

我們很幸運地碰到了百年難得一見的景氣寒冬，
但，心情卻不該因此萎靡，
在春耕．夏秐．秋收．冬藏的自然法則下，選擇適合自己的時序，
然後，仔細品味大環境帶給我們的挑戰！

慎思，才能善用

對 CMMI 量化指標的批判

2008-12-03T04:40:00.000-08:00

今天收到了一份 CMMI 度量指標的清單，看過後，我馬上回信給發信人，也請各位慎思相關議題！

以下是小弟的初淺看法，還請各位不吝賜教：

Dear Sir，
首先，要謝謝您提供的CMMI量化指標資訊，關於MA，我的意見一定會得罪許多人，如果有得罪之處，還請包涵，但，我還是要扮演國王新衣故事裡頭的那個不知天高地厚的初生之犢

先講結論，這份MA對真正務實的軟體公司而言用處真的很低，原因羅列如下：
1. 資料收集的時機造成問題，許多數據都是專案晚期才完成，也就是說，多數的數據都是落後指標，如果是運做順利的專案，當然不成問題，但，如果是運作出問題的專案，已經問題重重、資源都不夠用了，專案還在這些度量問題上打轉，似乎有點緣木求魚。結果是，專案結束後補做這些度量，因此，工程師不知道公司要求做這些事的本意為何?甚至解讀為增加工程師負擔...產生負面效益，人員流動率上升。
2. 資料收集的用途，當中講到的度量目的完全不正確，很多度量都沒有清楚說明用途為何? 有點為了度量而度量的味道，似乎忽略了原始度量的本意，有用的數據是能夠對專案、組織或者企業找出問題與改進方向的。
3. 度量方向有點不合時宜，OO跟Functional Points、LOC這類的度量，在本質上不相容，而且LOC越多代表的意義是?程式邏輯很複雜亦或人員寫程式的功力很差?反之，LOC越少又代表啥意義?

以上報告，聽來多少有點刺耳，但，忠言逆耳阿...希望您能諒解

後語：
雖然這裡對目前的 MA有所批判，我還是要還給 CMMI 一個公道，如果我們能夠
1. 確認度量數據的實際用途、
2. 找到更適切的度量指標
3. 採用適當的做法或工具
4. 及早獲得相關數據

就可以充分發揮度量的效益，讓團隊更成熟、製程更穩健、專案成功機率更高...共勉之

關於MA，我必須採取更負責任的態度去說明各項度量可能被誤用的情形與日前我提出批判的理由，以工時預估誤差率為例，
理想是
1. 工時估算與實際差距不大，專案精準掌握成本
2. 投入皆能獲得相對的報酬
3. 累積經驗後，下次估算更精準
實際是
1. 估算當時，刻意壓低估算數字
2. 專案初期真的沒誤差，後期誤差越來越大
3. 為了縮短誤差，投入更多時間加班
原因是
1. 為了活下去，公司要求業務，業務則用低價搶案
2. 簡單的任務都完成了，剩下的都很困難
3. 工時都是人填的，虛報或浮報完全操之在我
對策是
1. 改用產能估算專案成本
2. 越困難的問題產能應該越高
3. 先處理高風險議題
4. 不把工時當作評定績效的唯一標準

其他度量項目，容小弟花點時間整理，屆時再向各位報告

Flexing with JavaEE <1>

2008-12-01T19:16:00.000-08:00

1. 下載 BlazeDS
Turnkey 版本含 Tomcat, 如果懶得設定, 可以用這版本。

Binary Distribution 則是讓已經有 App. Server 或者其他非 Tomcat 的用, 目前我用的是這版, 因為我的 App. Server 是 JBOSS。
2. 安裝 BlazeDS
3. 確認安裝結果
4. 設計 Presentation tier, UI layout
5. 設計 Business tier, Domain Model
6. 設計 Business tier, Services Facade
7. 開發 Model 層 JAVA 程式並利用 JUNIT 完成 Unit Test
8. 開發 View & Controller 層 Flex 程式, 並緩步測試
9. 重構 Model View Presentation

Future Store

2008-11-27T21:41:00.000-08:00

我心目中的未來消費跟這有點像, 但 RFID 有先天的問題, 只要穿上具有特定纖維製成的衣服, 就可以阻隔掉部分信號, 這樣, 只要付出少少的錢, 就可以拿很多的東西走, 所謂賠本身意沒人做, 誰會做這樣的投資啊!!!

尋找其他解決方案囉!!!