繼最後的演講之後，看到了另一段觸動內心的演講，如果是我，我會像他這麼樂觀？也許不會，但，我們可以學習認識自己，選擇不去在意杯子之外的牛奶，再出發 ^_^
2008年12月31日 星期三
081225 課程回饋
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，至少要看的懂圖示
學習心得：
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，至少要看的懂圖示
2008年12月26日 星期五
JPA - persistence.xml 設定問題
題目是沒設定在 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>
答案是在設定檔案當中加上一行 <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月19日 星期五
計畫的基本元素
服務過程中常被問到的問題之一，就是計畫，怎樣寫計畫書或者大綱結構之類的問題，專案計畫跟任何的企畫書一樣，目的都是為了溝通並確認達成專案目標的管道、步驟，因此，計劃書的資訊不宜過多或不足，這當中的分寸要怎樣拿捏呢？
以我初淺的經驗去看，我認為計畫一定要交代：人、事、時、地、物、數，
1. 人：專案組織圖，權責
2. 事：表達的重點是執行過程當中的任務，昨天提過用幾點去展開, 含：分析、設計、開發、測試、建置、移轉等基本任務
3. 時：以上這些任務要執行多久？時程安排
4. 地：除了我們認知的工作地點外，環境還代表了專案執行過程用到的設備，例如：開發環境、測試環境、版控環境
5. 物：專案執行過程中，會交付哪些成果給客戶？例：專案執行計畫、雛型系統、設計規格、使用手冊、原始程式碼。
6. 數：成本估算數字，簡單來說就是報價單
此外，再加上建議解決方案即可，除非客戶要求，絕對不要加上其他非必要資訊，以免失焦，反而造成溝通不良。
以我初淺的經驗去看，我認為計畫一定要交代：人、事、時、地、物、數，
1. 人：專案組織圖，權責
2. 事：表達的重點是執行過程當中的任務，昨天提過用幾點去展開, 含：分析、設計、開發、測試、建置、移轉等基本任務
3. 時：以上這些任務要執行多久？時程安排
4. 地：除了我們認知的工作地點外，環境還代表了專案執行過程用到的設備，例如：開發環境、測試環境、版控環境
5. 物：專案執行過程中，會交付哪些成果給客戶？例：專案執行計畫、雛型系統、設計規格、使用手冊、原始程式碼。
6. 數：成本估算數字，簡單來說就是報價單
此外，再加上建議解決方案即可，除非客戶要求，絕對不要加上其他非必要資訊，以免失焦，反而造成溝通不良。
2008年12月17日 星期三
EJB3 入門案例 <3>
前一篇 EJB3 入門案例 <2> 說明了 Stateless Session Bean 的生命週期與 AOP 處理方式, 這篇報告說明了 EJB 跟 JPA(Java Persistence API)之間的整合與開發案例, 也是最常見的 EJB 應用基礎, 希望能帶大家進入更實用的領域.
2008年12月8日 星期一
EJB3 入門案例 <2>
說明 Stateless Session Bean 的生命週期, 並對入門案例<1> 進行重構, 用代理機制包中 Remote EJB, 讓 遠端 Client 可以很方便地利用, 詳細資訊請參考以下簡報:
EJB3 入門案例 <1>
關於 EJB3 的理論部分仿間有很多參考資料, 各位可以參考 Mastering Enterprise JavaBeans 3.0一書, 這份簡報採取的是實務觀點, 用實際案例逐步前進, 希望能讓大家更快入門
環境配置如下：
1. Eclipse IDE 開發工具,
2. JBOSS v5.0 Application Server 做為 EJB Container
開發步驟如下：
環境配置如下：
1. Eclipse IDE 開發工具,
2. JBOSS v5.0 Application Server 做為 EJB Container
開發步驟如下：
2008年12月4日 星期四
夫春生夏長，秋收冬藏，此天道之大經也。~史記太史公自序
我們很幸運地碰到了百年難得一見的景氣寒冬，
但，心情卻不該因此萎靡，
在春耕．夏秐．秋收．冬藏的自然法則下，選擇適合自己的時序，
然後，仔細品味大環境帶給我們的挑戰！
慎思，才能善用
但，心情卻不該因此萎靡，
在春耕．夏秐．秋收．冬藏的自然法則下，選擇適合自己的時序，
然後，仔細品味大環境帶給我們的挑戰！
慎思，才能善用
2008年12月3日 星期三
對 CMMI 量化指標的批判
今天收到了一份 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. 不把工時當作評定績效的唯一標準
其他度量項目，容小弟花點時間整理，屆時再向各位報告
以下是小弟的初淺看法，還請各位不吝賜教：
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. 不把工時當作評定績效的唯一標準
其他度量項目，容小弟花點時間整理，屆時再向各位報告
2008年12月1日 星期一
Flexing with JavaEE <1>
1. 下載 BlazeDS
Turnkey 版本含 Tomcat, 如果懶得設定, 可以用這版本。
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
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
訂閱：
文章 (Atom)