繼最後的演講之後，看到了另一段觸動內心的演講，如果是我，我會像他這麼樂觀？也許不會，但，我們可以學習認識自己，選擇不去在意杯子之外的牛奶，再出發 ^_^
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
2008年11月27日 星期四
Future Store
我心目中的未來消費跟這有點像, 但 RFID 有先天的問題, 只要穿上具有特定纖維製成的衣服, 就可以阻隔掉部分信號, 這樣, 只要付出少少的錢, 就可以拿很多的東西走, 所謂賠本身意沒人做, 誰會做這樣的投資啊!!!
尋找其他解決方案囉!!!
尋找其他解決方案囉!!!
2008年11月26日 星期三
2008年11月17日 星期一
軟體加(+)減(-)法
忘記在哪篇討論教改的文章看過華人社會習慣減法，美系國家則習慣於加法計算方式，那篇文章說明了一種生活態度，也因為如此，國人在便利商店常會有買55元東西支付105元讓店員找錢的狀況，店員也習慣性地用減法計算然後找了50元給顧客，這種情況如果換到美系社會，肯定會造成困擾...之類的評論；我很認同那篇文章的部分觀點
小弟認為不論是加法、減法，這反映出來的不僅僅是一種現象，更是一種文化，這代表的是傳承的過程，也帶著點強迫的性質，文化的傳遞過程主要是老一輩怎麼說，我們就怎麼做，偶爾加點懷疑、衝突、創新，但日子久了，也就變成另一種約定成俗了；因為工作的關係，近來腦子裡不斷產生類似的疑問，這種加減法的文化背後代表的本質是？
從現象來看，加法文化下成長的小孩較有自信，相信是他們不斷鼓勵各種成就的原因吧；相對的，減法文化培養的小孩確是認為自己還有許多不足處，還有許多可以努力的空間，課後輔導、補習、明星學校...都因為這樣的文化而蓬勃，從這點看來，似乎加法文化比較好！
但是，加法無限擴張之後，大頭症就來了，認為沒有不可能，甚麼事都能做到(也的確做了很多豐功偉業)，但也造就了信用無限擴張與全球性金融風暴的重大危機；反觀華人社會的發展，因為從小的教育使然，總覺得做的不夠好，所以步步為營，採取的策略總是一步一腳印，站穩腳步才往前邁進，也因為如此，華人社會受到的衝擊相對較輕，深思熟慮的做事方法，也凸顯在危機處理的速度上...
講了這麼多，到底跟軟體有甚麼關係？主要是因為目前軟體工法有兩派爭論，一是CMMI之類的全面論點，認為可以透過 CMMI之類的方法去建立軟體工廠；另一派則是講人文，尊重人本的Agile方法論。這兩派方法論的支持者都能講出對方的優點與困難，也都很有道理，贊成CMMI的一方認為Agile過度簡化...，認同Agile的一方則認覺得CMMI過度要求...。
我認為，Agile 就像加法文化，能獲得多少，是累積上去的，因此有許多發展的可能性；而CMMI也可以類比成減法文化，需要透過很多努力去實踐，以達成組織設定的目標，這兩者的優劣，請各握透過加減法的觀點去分析，或許能有新的見解產生喔 ^_^
無論採取加法或減法，提醒各位【勿忘初衷】，先想想專案需要甚麼？然後才思考要採取何種解決方案吧！
小弟認為不論是加法、減法，這反映出來的不僅僅是一種現象，更是一種文化，這代表的是傳承的過程，也帶著點強迫的性質，文化的傳遞過程主要是老一輩怎麼說，我們就怎麼做，偶爾加點懷疑、衝突、創新，但日子久了，也就變成另一種約定成俗了；因為工作的關係，近來腦子裡不斷產生類似的疑問，這種加減法的文化背後代表的本質是？
從現象來看，加法文化下成長的小孩較有自信，相信是他們不斷鼓勵各種成就的原因吧；相對的，減法文化培養的小孩確是認為自己還有許多不足處，還有許多可以努力的空間，課後輔導、補習、明星學校...都因為這樣的文化而蓬勃，從這點看來，似乎加法文化比較好！
但是，加法無限擴張之後，大頭症就來了，認為沒有不可能，甚麼事都能做到(也的確做了很多豐功偉業)，但也造就了信用無限擴張與全球性金融風暴的重大危機；反觀華人社會的發展，因為從小的教育使然，總覺得做的不夠好，所以步步為營，採取的策略總是一步一腳印，站穩腳步才往前邁進，也因為如此，華人社會受到的衝擊相對較輕，深思熟慮的做事方法，也凸顯在危機處理的速度上...
講了這麼多，到底跟軟體有甚麼關係？主要是因為目前軟體工法有兩派爭論，一是CMMI之類的全面論點，認為可以透過 CMMI之類的方法去建立軟體工廠；另一派則是講人文，尊重人本的Agile方法論。這兩派方法論的支持者都能講出對方的優點與困難，也都很有道理，贊成CMMI的一方認為Agile過度簡化...，認同Agile的一方則認覺得CMMI過度要求...。
我認為，Agile 就像加法文化，能獲得多少，是累積上去的，因此有許多發展的可能性；而CMMI也可以類比成減法文化，需要透過很多努力去實踐，以達成組織設定的目標，這兩者的優劣，請各握透過加減法的觀點去分析，或許能有新的見解產生喔 ^_^
無論採取加法或減法，提醒各位【勿忘初衷】，先想想專案需要甚麼？然後才思考要採取何種解決方案吧！
2008年11月14日 星期五
加解密技術入門
加解密技術(Cryptography)有許多種，仿間也有很多相關的書籍介紹，如果您想了解理論部分，例如：Cryptographic Message Syntax、Public key infrastructure...，請善加利用搜尋引擎
如果您要知道怎樣用 Java 語言去開發相關的程式，這篇簡報將是有用的入門資料，這當中提到的程式包括：
1. 單向加密(不可逆)
2. 對稱式加密(可逆)
3. 非對稱式加密
4. 數位簽章
提醒一：要提醒各位的是，關於安控的議題不僅僅是簡報當中報告的這些，還有：使用者身分驗證、URL 驗證、Access Control List、Data Access Control、Logging、Exception Handling、Security Session...等議題都跟安控有關，市面上許多 AP Server 都有提供相關的 API，也還有許多環節被忽略掉，但還是有許多的安全漏洞，如果你要開發嚴謹的系統，建議你可以從這些面向去思考。 ^_^
提醒二: Session Id 是很嚴重的安全漏洞，尤其現在的 RIA/AJAX 當道，正種情況又更加嚴重了，怎說呢？登入系統前駭客程式可以把 session id 擷取下來，等你登入系統取得授權後，駭客程式便可以使用該 session id 去模擬授權成功後的所有作業，這過程中完全不用知道使用者的帳號 & 密碼...
如果您要知道怎樣用 Java 語言去開發相關的程式，這篇簡報將是有用的入門資料，這當中提到的程式包括：
1. 單向加密(不可逆)
2. 對稱式加密(可逆)
3. 非對稱式加密
4. 數位簽章
提醒一：要提醒各位的是，關於安控的議題不僅僅是簡報當中報告的這些，還有：使用者身分驗證、URL 驗證、Access Control List、Data Access Control、Logging、Exception Handling、Security Session...等議題都跟安控有關，市面上許多 AP Server 都有提供相關的 API，也還有許多環節被忽略掉，但還是有許多的安全漏洞，如果你要開發嚴謹的系統，建議你可以從這些面向去思考。 ^_^
提醒二: Session Id 是很嚴重的安全漏洞，尤其現在的 RIA/AJAX 當道，正種情況又更加嚴重了，怎說呢？登入系統前駭客程式可以把 session id 擷取下來，等你登入系統取得授權後，駭客程式便可以使用該 session id 去模擬授權成功後的所有作業，這過程中完全不用知道使用者的帳號 & 密碼...
2008年11月12日 星期三
ORM 繼承與複合鍵設計
客戶用 hibernate 實做中提出一個關於繼承與複合鍵的問題，題目是這樣的：
1. 父類別是抽象類別，父類別已定義 主鍵 = 序號
2. 有兩個子類別繼承
3. 子類別的 主鍵 = 子類別型態 + 父類別序號
要怎樣用 hibernate 的 ORM 實現這種設計?
以下是我的答覆：首先須了解 ENTITY_TYPE 代表類別型態這件事的定義，我猜測 ParentEntity, Child1Entity, Child2Entity 裡頭有有對應的 entityType 屬性，如果答案是肯定的，我就不會用 <discriminator column="ENTITY_TYPE" type="string" length="10" /> 這樣的設定去識別子類別，我會用以下的 ORM 方式去設計
<discriminator column="CLASS_TYPE" type="string" length="10" />
<property name="entityType" column="ENTITY_TYPE" />
<subclass name="Child1Entity" discriminator-value="Child1">
...
</subclass>
<subclass name="Child1Entity" discriminator-value="Child2">
...
</subclass>
如果ParentEntity, Child1Entity, Child2Entity 裡頭沒有對應的 entityType 屬性，那麼複合鑑的問題又要怎樣處理? 這部分有幾種選項
1. 採用 hibernate 提供的 composite-id 設定方式
2. 由物件負責處理，以 ParentEntity 為例
class ParentEntity {
String serial;
String entityType;
public String getSerial() {
return serial;
}
public String getEntityType() {
return tokenType;
}
public String getEntityId() {
return getEntityType()+getSerial();
}
protected void setEntityId(String eid) {
// do nothing
}
}
其 ORM 可以宣告如下
<id name="entityId" column="ENTITY_ID" length="128"/>
3. 另外寫一個 EntityID 產生程式
不知道各位是否有其他見解? 歡迎加入討論
1. 父類別是抽象類別，父類別已定義 主鍵 = 序號
2. 有兩個子類別繼承
3. 子類別的 主鍵 = 子類別型態 + 父類別序號
要怎樣用 hibernate 的 ORM 實現這種設計?
以下是我的答覆：首先須了解 ENTITY_TYPE 代表類別型態這件事的定義，我猜測 ParentEntity, Child1Entity, Child2Entity 裡頭有有對應的 entityType 屬性，如果答案是肯定的，我就不會用 <discriminator column="ENTITY_TYPE" type="string" length="10" /> 這樣的設定去識別子類別，我會用以下的 ORM 方式去設計
<discriminator column="CLASS_TYPE" type="string" length="10" />
<property name="entityType" column="ENTITY_TYPE" />
<subclass name="Child1Entity" discriminator-value="Child1">
...
</subclass>
<subclass name="Child1Entity" discriminator-value="Child2">
...
</subclass>
如果ParentEntity, Child1Entity, Child2Entity 裡頭沒有對應的 entityType 屬性，那麼複合鑑的問題又要怎樣處理? 這部分有幾種選項
1. 採用 hibernate 提供的 composite-id 設定方式
2. 由物件負責處理，以 ParentEntity 為例
class ParentEntity {
String serial;
String entityType;
public String getSerial() {
return serial;
}
public String getEntityType() {
return tokenType;
}
public String getEntityId() {
return getEntityType()+getSerial();
}
protected void setEntityId(String eid) {
// do nothing
}
}
其 ORM 可以宣告如下
<id name="entityId" column="ENTITY_ID" length="128"/>
3. 另外寫一個 EntityID 產生程式
不知道各位是否有其他見解? 歡迎加入討論
2008年11月11日 星期二
測試方法與案例
單元測試是確保成果的基礎，沒有完成單元測試的軟體只是把風險移轉給使用者，這是一種鴕鳥心態，也是驗證莫非定律的不良示範，凡映出來的結果將是更多的客訴，投入更多資源去除錯，成本增加，驗收困難，工作負荷增加...，這些都是沒有妥善執行測試的現象；反之，如果為了品質而過度測試，這當中的資源浪費又要算在誰的頭上呢？
因此，測試必須執行，但也要避免過度，怎樣找出平衡點？軟體開發者必須累積經驗並從中獲得真正適合該組織的知識...歡迎加入討論
衍生閱讀：Test Driven Development(TDD)
因此，測試必須執行，但也要避免過度，怎樣找出平衡點？軟體開發者必須累積經驗並從中獲得真正適合該組織的知識...歡迎加入討論
衍生閱讀：Test Driven Development(TDD)
2008年11月5日 星期三
OOAD CASE [會議室預約管理]
物件導向分析設計，這是多大的題目阿，習慣上，大家可能會從物件導向的概論開始談起...最後才會切到實務，從邏輯推演的角度去看，這樣比較有次序，但，卻不能滿足即時的需要，所以，這裡從案例出發，各位在看簡報之前，請先從自己習慣的方式去設計，待初步設計完成後再對照這份簡報吧！以下是CRRS會議室預約的題目：
1. 有 20 間會議室可供預約
1.1. 基本設備不同
1.2. 可容納人數不同
1.3. 可預約時段為 08:30~20:00, 以 15 分鐘為單位
2. 有 8 套投影機可供運用
2.1. 預約會議室成功且會議室沒有安裝投影機, 才能預約
3. 預約時, 須記錄與會人數、會議主題、 時段、預約者姓名、 部門、職稱、聯絡資訊等
4. 會議室皆被預約時, 使用者可要求加入先進先出的排隊名單
5. 取消預約時, 系統會依先進先出通知排隊者
6. 使用者可查詢會議室使用情形
7. 管理者可調閱會議室使用紀錄&報表
提醒 : 看簡報前務必先自行做設計，最好能用程式碼去驗證自己的設計!!!
1. 有 20 間會議室可供預約
1.1. 基本設備不同
1.2. 可容納人數不同
1.3. 可預約時段為 08:30~20:00, 以 15 分鐘為單位
2. 有 8 套投影機可供運用
2.1. 預約會議室成功且會議室沒有安裝投影機, 才能預約
3. 預約時, 須記錄與會人數、會議主題、 時段、預約者姓名、 部門、職稱、聯絡資訊等
4. 會議室皆被預約時, 使用者可要求加入先進先出的排隊名單
5. 取消預約時, 系統會依先進先出通知排隊者
6. 使用者可查詢會議室使用情形
7. 管理者可調閱會議室使用紀錄&報表
提醒 : 看簡報前務必先自行做設計，最好能用程式碼去驗證自己的設計!!!
CMMI or AGILE
最近有很多類似的題目，CMMI 很完備，Agile 很輕量，中間的差異似乎非常大，軟體公司到底要採用哪一種方法?
CMMI 當中有許多環節是 Agile 沒有提到的，熟悉 CMMI 的人應該都清楚它的背景 & 立意，因此，從健全系統發展的觀點去看，我會把 CMMI 當成類似字典的工具書，這種工具，讓我在碰到問題的時候，可以從更多元的角度去思考，但，決不照單全收。
Agile 很輕量，實務上也非常貼近現實，因此，我完全支持 "Agile 的立意"，可視的結果是我們需要的，否則為啥要做專案? 消化預算 or 浪費生命?
然而，各位奮力擁抱 Agile 之前，請各位注意以下議題：
1. agile 當初成立的大堆頭是哪些人?
2. 這些人的背景是? 他們曾經歷過哪些?
3. 怎樣的演變過程才有 agile 產生?
4. 我們是否有同樣的基礎去實施 agile ?
結論是，CMMI or Agile 都適合也都不合適...因為，我們不曾想過自己真正 "需要" 什麼，貴專案真的需要是啥? 成員是否有面對改變的共識?
後語：有人問我 Agile 不適合的原因，以下是我的答覆
Agile不適合的原因?如果用原因這個詞，感覺有點強制，因此我改用不適合的可能狀況
1.跨地區開發，如果沒有良好的配套/溝通橋樑，可能會造成溝通瓶頸，訊息流通速度慢－因為要跑許多流程...，或者訊息沒有被好好地解讀，或許大家會有opensource來當反例，但我要問的是，這些參加opensource開發者的工作心態是怎樣的積極，你清楚嗎? 跨地區的團隊是否有相同的態度呢?
2.工作基準不一致，如果連團隊協同合作的基礎都沒建立，怎樣實施Agile?
3.客戶屬性，如果你碰到的客戶工作要求是僵化的waterfall基準，而且不能說服，公司又一定要賺這筆錢?你可以完全適用Agile?
4.對測試驅動的認知&實務
5.團隊屬性...
太多可能狀況了，但我要強調的是，Agile真的很好用，客戶很喜歡我們採用類似Agile的做法
衍生閱讀：
1. 軟體設計思維
2. 建構管理
CMMI 當中有許多環節是 Agile 沒有提到的，熟悉 CMMI 的人應該都清楚它的背景 & 立意，因此，從健全系統發展的觀點去看，我會把 CMMI 當成類似字典的工具書，這種工具，讓我在碰到問題的時候，可以從更多元的角度去思考，但，決不照單全收。
Agile 很輕量，實務上也非常貼近現實，因此，我完全支持 "Agile 的立意"，可視的結果是我們需要的，否則為啥要做專案? 消化預算 or 浪費生命?
然而，各位奮力擁抱 Agile 之前，請各位注意以下議題：
1. agile 當初成立的大堆頭是哪些人?
2. 這些人的背景是? 他們曾經歷過哪些?
3. 怎樣的演變過程才有 agile 產生?
4. 我們是否有同樣的基礎去實施 agile ?
結論是，CMMI or Agile 都適合也都不合適...因為，我們不曾想過自己真正 "需要" 什麼，貴專案真的需要是啥? 成員是否有面對改變的共識?
後語：有人問我 Agile 不適合的原因，以下是我的答覆
Agile不適合的原因?如果用原因這個詞，感覺有點強制，因此我改用不適合的可能狀況
1.跨地區開發，如果沒有良好的配套/溝通橋樑，可能會造成溝通瓶頸，訊息流通速度慢－因為要跑許多流程...，或者訊息沒有被好好地解讀，或許大家會有opensource來當反例，但我要問的是，這些參加opensource開發者的工作心態是怎樣的積極，你清楚嗎? 跨地區的團隊是否有相同的態度呢?
2.工作基準不一致，如果連團隊協同合作的基礎都沒建立，怎樣實施Agile?
3.客戶屬性，如果你碰到的客戶工作要求是僵化的waterfall基準，而且不能說服，公司又一定要賺這筆錢?你可以完全適用Agile?
4.對測試驅動的認知&實務
5.團隊屬性...
太多可能狀況了，但我要強調的是，Agile真的很好用，客戶很喜歡我們採用類似Agile的做法
衍生閱讀：
1. 軟體設計思維
2. 建構管理
2008年11月3日 星期一
Spring MVC
Spring IoC & AOP 基本概念與運作原理, 同時介紹 Spring MVC 的簡單用法
後語：最近 Spring 又發行了新版，有興趣的人可以去下載，有趣的是，Spring 似乎不再是輕量級...這種發展，是否合乎 Spring framework 的初衷？這種發展是宿命？你會採用哪種觀點...
後語：最近 Spring 又發行了新版，有興趣的人可以去下載，有趣的是，Spring 似乎不再是輕量級...這種發展，是否合乎 Spring framework 的初衷？這種發展是宿命？你會採用哪種觀點...
2008年10月28日 星期二
Hibernate Entity Manager / JPA Annotation
ORM 除了用 xml 設定方式之外, 例一種方式就是用 @annotation, 這裡一樣透過案例展示, 直接示範幾種常用的關聯
包括：
1. 單一物件
2. 一對一關聯
3. 一對多關聯
4. 多對多關聯
5. 繼承關係
相關資訊:Test Driven Development(TDD)
包括：
1. 單一物件
2. 一對一關聯
3. 一對多關聯
4. 多對多關聯
5. 繼承關係
相關資訊:Test Driven Development(TDD)
2008年10月23日 星期四
第 21 頁
今天看了李家同教授的"第 21 頁"這本書，感觸很多，許多兒時記憶也浮上心頭，小時放學後，總在嬉鬧的氣氛中返家，放學的感覺真的很好，因為，只要回到家，就可以跟玩伴們到住家旁邊的黑森林去探險，對於六年級前段班的我們而言，兒時生活就是這樣驚險！
每日固定的返家路線定會經過一位女同學的家，我也從來不以為意，但，自從那天之後，我改變了路線，刻意避開這位同學的家...為什麼呢？
那天，玩伴們在相同的嬉鬧氣氛中返家，途經那位女同學家時，我被她的母親叫住了，當我還停在路上搞不清楚怎麼一回事的時候，就被一連串的責罵聲給嚇壞了...這位母親怪罪我前一天弄翻了他女兒的便當，害他女兒沒有午餐吃，我辯稱沒做這件事，這位母親回答說:「他女兒說是啞巴的兒子...」...
是的，我是啞巴的兒子，但罪魁禍首並不是我，真正弄翻他女兒便當的人是我的另一位同學，而這位同學...是喑啞人士。
年幼的我，碰到這種情形，心裡自然充滿了無奈，更多的是疑問！難道, 啞巴的兒子就該被羞辱？父母親也是努力討生活的台灣人阿...，一直以來，我沒得到對方的道歉，也沒想過要對方道歉，因為我知道，父母親一定承受了比我更多的橫逆，只是他們沒有說出來而已。雙親雖然不會說話，但他們始終努力承擔我們這六位子女帶來的重擔，無怨無悔。對自己而言，這樣的生活態度，一直影響著我，至今！
看看李教授的文章，想想自己為這社會帶來怎樣的影響吧...
推薦書籍:
每日固定的返家路線定會經過一位女同學的家，我也從來不以為意，但，自從那天之後，我改變了路線，刻意避開這位同學的家...為什麼呢？
那天，玩伴們在相同的嬉鬧氣氛中返家，途經那位女同學家時，我被她的母親叫住了，當我還停在路上搞不清楚怎麼一回事的時候，就被一連串的責罵聲給嚇壞了...這位母親怪罪我前一天弄翻了他女兒的便當，害他女兒沒有午餐吃，我辯稱沒做這件事，這位母親回答說:「他女兒說是啞巴的兒子...」...
是的，我是啞巴的兒子，但罪魁禍首並不是我，真正弄翻他女兒便當的人是我的另一位同學，而這位同學...是喑啞人士。
年幼的我，碰到這種情形，心裡自然充滿了無奈，更多的是疑問！難道, 啞巴的兒子就該被羞辱？父母親也是努力討生活的台灣人阿...，一直以來，我沒得到對方的道歉，也沒想過要對方道歉，因為我知道，父母親一定承受了比我更多的橫逆，只是他們沒有說出來而已。雙親雖然不會說話，但他們始終努力承擔我們這六位子女帶來的重擔，無怨無悔。對自己而言，這樣的生活態度，一直影響著我，至今！
看看李教授的文章，想想自己為這社會帶來怎樣的影響吧...
推薦書籍:
2008年10月21日 星期二
Hibernate Entity Manager / ORM
使用過 hibernate 開發程式的人, 都會碰到 ORM 的問題, 這份簡報整理了常用的關聯案例,
包括：
1. 單一物件
2. 一對一關聯
3. 一對多關聯
4. 多對多關聯
透過案例展示, 方便大家日後查詢之用, 強調一下, 寫好的程式必須"通過測試才能算是真正完成"
需要完整的範例程式? 連同你的建議寄送到我的信箱! 歡迎各位提供建議 ^_^
相關資訊:Test Driven Development(TDD)
包括：
1. 單一物件
2. 一對一關聯
3. 一對多關聯
4. 多對多關聯
透過案例展示, 方便大家日後查詢之用, 強調一下, 寫好的程式必須"通過測試才能算是真正完成"
需要完整的範例程式? 連同你的建議寄送到我的信箱! 歡迎各位提供建議 ^_^
相關資訊:Test Driven Development(TDD)
2008年10月20日 星期一
UML Overview
學習 UML 過程中, 免不了要整理這些圖, UML Notations / Diagrams 是溝通的基礎, 即便是簡單的一張圖都代表了許多的意涵, 重點是解讀的人, 大家是否具備相同的認知基礎? 學習 UML Notation 的語意, 就像學了軟體世界的共通語言, 也像學習一般外語, "使用"才是真正的"學會"
這份文件也可以當做考 OCUP 認證的參考資訊, 但, 我要強調, 重點還是"用這個工具去溝通"
衍生閱讀：敏捷塑模
這份文件也可以當做考 OCUP 認證的參考資訊, 但, 我要強調, 重點還是"用這個工具去溝通"
衍生閱讀：敏捷塑模
2008年10月14日 星期二
建構與變更管理課程後
講完建構與變更管理課程後, 我收到了以下回覆：「我們是一個 embedded 系統廠，每個案子的變數都相當的多，有硬體，軟體，客人臨時要求 .... 這種不同的變數。我想上課的內容的確給了許多觀念與想法，可以讓我們在執行時多想想的。...軟體初開發時，哪些事情是要注意的，在開發過程中，哪些資料需要建立，還有面臨變化時，怎麼樣可以把問題降低，解決。讓PM可以把工作控制的更安全。這是我們希望能學到的。」
很謝謝你的回饋, 關於你信件中提到的問題, 我盡可能回覆如下：
案子成立之初
1. 初步決定系統規格 (機構, 硬體, 軟體, 韌體...)
2. 釐清設計限制 (空間, 容量, CPU 等級)
3. 確立遊戲規則, 例如: 用 Issue Tracking 記錄與處理各方需求的流程
軟體開發過程...面臨變化時，怎麼樣可以把問題降低，解決
1. 確認規格 -> 設計具彈性的軟體架構, 例如引用 design patterns
2. 確認軟體架構的相依性, 先做底層部分, 例如：採購, 銷售與庫存, 最底層的部分應該是"庫存"
3. 逐步開發 -> 測試(一定要寫測試個案) -> 確認完成後 -> Check In (Commit 記得要加註記, 若使用 CodeBeamer 將可看到相關資訊, 知道問題的處理進展)
4. 持續整合 -> 測試並驗證各項問題已經被處理
5. 如果有其他需求, 回到步驟 1 (可能會需要調整設計)
以上說明, 若有任何意見, 歡迎隨時來信
衍生閱讀:
1. JAVA 軟體開發基準
2. 建構與變更管理
很謝謝你的回饋, 關於你信件中提到的問題, 我盡可能回覆如下：
案子成立之初
1. 初步決定系統規格 (機構, 硬體, 軟體, 韌體...)
2. 釐清設計限制 (空間, 容量, CPU 等級)
3. 確立遊戲規則, 例如: 用 Issue Tracking 記錄與處理各方需求的流程
軟體開發過程...面臨變化時，怎麼樣可以把問題降低，解決
1. 確認規格 -> 設計具彈性的軟體架構, 例如引用 design patterns
2. 確認軟體架構的相依性, 先做底層部分, 例如：採購, 銷售與庫存, 最底層的部分應該是"庫存"
3. 逐步開發 -> 測試(一定要寫測試個案) -> 確認完成後 -> Check In (Commit 記得要加註記, 若使用 CodeBeamer 將可看到相關資訊, 知道問題的處理進展)
4. 持續整合 -> 測試並驗證各項問題已經被處理
5. 如果有其他需求, 回到步驟 1 (可能會需要調整設計)
以上說明, 若有任何意見, 歡迎隨時來信
衍生閱讀:
1. JAVA 軟體開發基準
2. 建構與變更管理
整合性開發環境
軟體系統開發過程需要用到的各項工具，如何整合到一個環境中讓開發團隊可以輕鬆上手，管理者能夠精準掌握進度，組織的智慧財產能夠有效累積呢?
整合性開發環境結合了專案團隊協同作業需要的基礎元件，透過簡單的內規(SOP)，讓整體作業能夠更加順暢；以下案例是筆者最近提供的諮詢服務之一，本案例整合了開發工具(ECLIPSE IDE)、軟體建構管理工具(SUBVERSION)、議題追蹤管理工具(CODEBEAMER)等工具，從諮詢服務與案例演練的過程中，我發現到，具備品質觀念的工作團隊加上適合的工具，就像關老爺遇到了赤兔馬一樣，一拍即合。
能夠為顧客提供適切的服務，是最愉快的事業了...真慶幸自己可以從事這種性質的工作 ^_^
整合性開發環境結合了專案團隊協同作業需要的基礎元件，透過簡單的內規(SOP)，讓整體作業能夠更加順暢；以下案例是筆者最近提供的諮詢服務之一，本案例整合了開發工具(ECLIPSE IDE)、軟體建構管理工具(SUBVERSION)、議題追蹤管理工具(CODEBEAMER)等工具，從諮詢服務與案例演練的過程中，我發現到，具備品質觀念的工作團隊加上適合的工具，就像關老爺遇到了赤兔馬一樣，一拍即合。
能夠為顧客提供適切的服務，是最愉快的事業了...真慶幸自己可以從事這種性質的工作 ^_^
2008年10月5日 星期日
實現兒時的夢想 BY Randy Pausch
我們改變不了上帝發給我們的牌, 但, 我們可決定怎麼打這手牌
這場演講可以讓自己反省很多事情, 困難永遠存在, 面對困難的處理方式卻有很多種...我們打算怎樣面對?
或許, 聽聽看 Randy Pausch 的觀點, 讀讀自己內心的想法...
Randy Pausch Last Lecture: Achieving Your Childhood Dreams
推薦書籍:
這場演講可以讓自己反省很多事情, 困難永遠存在, 面對困難的處理方式卻有很多種...我們打算怎樣面對?
或許, 聽聽看 Randy Pausch 的觀點, 讀讀自己內心的想法...
Randy Pausch Last Lecture: Achieving Your Childhood Dreams
推薦書籍:
建構與變更管理案例 [Subversion]
近來講了幾回建構管理實際案例[Subversion]的課程, 發現大家都有使用類似的建構管理(版本管控)環境,但卻很少人注意到這個工具可以為團隊工作帶來的其他好處, 多數工程師都認為這工具有用助於分工合作, 也有少數工程師認為建構管理帶來某些困擾, 例如: 修正好的程式一定要逐一簽入(check in)嗎? 能不能整批一塊做?
先看看以下案例吧!!
先看看以下案例吧!!
2008年9月25日 星期四
建構與變更管理[CodeBeamer]
關於建構管理的理論與實務, 如果各位有興趣, 可以看看這份簡報, 其中有談到議題追蹤管理的相關資訊,
當我提到:議題是有生命的, 有些人會覺得納悶...
當我提到:議題的年齡時, 就更搞不懂了...
以上議題我不多說, 大夥可以用毒奶事件這個議題, 好好思索一下囉!!
對筆者而言, 基礎很重要, Know-How 也很重要, 但更重要的是, "馬上去做"...不要再拖了
當我提到:議題是有生命的, 有些人會覺得納悶...
當我提到:議題的年齡時, 就更搞不懂了...
以上議題我不多說, 大夥可以用毒奶事件這個議題, 好好思索一下囉!!
對筆者而言, 基礎很重要, Know-How 也很重要, 但更重要的是, "馬上去做"...不要再拖了
2008年9月3日 星期三
JAVA 軟體開發基準
團隊合作就像參加一場盛會, 每個人都被賦予特殊任務, 也都要演活自己的角色, 但, 如果大家沒有相同的舞台, 這場戲要如何演下去?
基於團隊合作的需要, 建議開發團隊應該要有一套共通的作業基礎, 也就是遊戲規則, 你的團隊是否有一套遊戲規則呢? 如果沒有, 或許可以參考這裡!!!
基於團隊合作的需要, 建議開發團隊應該要有一套共通的作業基礎, 也就是遊戲規則, 你的團隊是否有一套遊戲規則呢? 如果沒有, 或許可以參考這裡!!!
2008年8月29日 星期五
2008年8月11日 星期一
有趣：軟體 Bug 的起源
軟體運行中因為程式本身有錯誤而造成的功能異常、當機...等現象統稱為臭蟲 (Bug), 這名詞是怎樣來的?
Software Bug 一詞起源於1945年後期，當時還是真空管電腦的時代，9月9日當天哈佛大學實驗室內的計算機出現了問題，Hopper 女士仔細地檢查過 Mark II 計算機後，發現繼電器上有一隻蛾貼附在上頭，後來他們將這隻蛾拿掉後，貼在工作日誌上頭，此後，我們就開始指稱電腦系統異常為 Bug 了。
以下是原文的片段
In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book September 9th 1945 [sic]. Stemming from the first bug, today we call errors or glitches [sic] in a program a bug
^_^ 真有趣
相關文章：品質與度量
Software Bug 一詞起源於1945年後期，當時還是真空管電腦的時代，9月9日當天哈佛大學實驗室內的計算機出現了問題，Hopper 女士仔細地檢查過 Mark II 計算機後，發現繼電器上有一隻蛾貼附在上頭，後來他們將這隻蛾拿掉後，貼在工作日誌上頭，此後，我們就開始指稱電腦系統異常為 Bug 了。
以下是原文的片段
In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book September 9th 1945 [sic]. Stemming from the first bug, today we call errors or glitches [sic] in a program a bug
^_^ 真有趣
相關文章：品質與度量
2008年8月8日 星期五
Google App Engine 練習<1>
GAE 基本概念
鑑於WEB應用程式從概念、分析、開發到建置過程有太多的問題需要克服，Google 提供了更簡單的方式，讓概念成真的過程變得更加迅速&容易，投資者更可減少概念驗證過程中的各項投資，包括：軟體、硬體、時間與成本…等。
為什麼筆者會這樣說呢？沒有Google App Engine (簡稱GAE)之前，我們要發展 WEB 應用，需要申請頻寬、架設伺服器、安裝各種系統軟體、每月支付主機代管費用給 ISP 業者…，然而，以上這些費用都會在我們無法確定概念是否真能成功之前就需要投入的，更不用說每月要付出的其他成本了。
Google 提供的GAE 其實是一種開放的環境，讓許許多多的網路應用可以在這樣的平台上運作，而且幾乎免費，只有當使用頻率高到某種程度的時候才要收費，也就是說，從概念到成功之前，幾乎不會發生各種不必要的花費，看到這裡，你是否躍躍欲試了呢! 讓我們一起學習吧!
講在前面
GAE 目前支援的程式語言是 Python 2.5，如果你想用其他程式語言，可能要再等等
GAE 目前沒有支援 SSL，如果你的 WEB 須要用到 SSL，建議採用 proxy
GAE 採用 schema less 的分散式資料儲存模式，跟關聯式資料庫的觀念截然不同，要有心理準備
除了以上三點之外，GAE 真的很好用 ^_^
準備動作
下載並安裝Python 2.5開發工具
網址：http://python.org/download/到 Google 申請 GAE 服務
網址：http://code.google.com/appengine/下載並安裝 GAE SDK 程式
網址：http://code.google.com/appengine/downloads.html用IDE或者文字編輯工具開發WEB 應用程式
參閱：http://code.google.com/appengine/docs/gettingstarted/
於Eclipse 安裝 Python 開發工具
PyDev Plugin
使用功能表中選擇 [Help]/[Software Updates]/[Find and Install]
選擇 Search for new features to install 後點選[Next]按鍵
點選 [New Remote Site] 建立PyDev 的下載點
name : PyDev
url : http://pydev.sourceforge.net/updates/
設定完成後，勾選PyDEV 並點選 [Finish] 按鍵
安裝完成後，重新啟動 Eclipse 即可
用Pydev 開發 Python 程式
建立 Pydev 專案
功能表中選擇 [File]/[New]/[Pydev Project]
輸入專案名稱並點選 Python 2.5，然後點選 [Finish] 按鍵
專案名稱：HelloWorld
設定 GAE SDK 到HelloWorld專案中
於 HelloWorld 專案中點選滑鼠右鍵，並選擇 [properties] 選項
於屬性設定畫面中，選擇 [Pydev – PYTHONPATH]頁籤，並於External Source Folder當中指定GAE 安裝路徑
點選 [OK] 按鍵完成設定
撰寫第一支 Python程式
功能表中選擇 [File]/[New]/[Other]
選擇 [Pydev]/[Pydev Model] 後點選 [NEXT] 按鍵
選擇檔案存放路徑並輸入檔案名稱後，點選 [FINISH] 按鍵
檔案名稱：helloworld
於 IDE 中撰寫程式，寫好程式後請存檔，開發者將會在Package Explore 專案畫面中看到剛剛存檔的Python程式。
以下是 Helloworld的Python 範例：print 'Content-Type: text/plain'
print ''
print 'Hello, world!'
於Package Explore點選 helloworld 程式並點選滑鼠右鍵，選擇 [Run As]/[Python Run] 執行這支程式
開發者可以在 Console 畫面中看到本程式的執行結果
確認後，就可以把程式上傳並安裝到 GAE 平台了，
上傳Python 程式到 GAE
連線到 GAE 並完成 Sign In 動作
網址：http://appengine.google.com/Sign In 後，請點選 [Create an Application] 申請本WEB應用程式的上傳空間
申請過程中請務必輸入 Application ID 並點選 [Check Availability] 按鍵確認沒有其他人申請過，請記住Application ID以便後續上傳&識別
我申請的Application ID是：isample
申請完成後，請到Helloworld 專案中建立一份設定檔，檔名一般為：app.yaml 但開發者仍可自行決定檔名。
檔案內容如下：application: isample
version: 1
runtime: python
api_version: 1
handlers:
- url: /.*
script: helloworld.py
指定上傳的Application ID，剛剛申請的
說明設定檔的版本
說明採用的runtime, 目前僅有 python
說明採用的 GAE SDK 版本
說明 WEB 網站的進入點, 本例為根目錄
指定 Python 程式檔名
上傳到 GAE 環境
啟動命令提示畫面，並切換到HelloWorld 專案目錄，從該目錄底下，應該可以看到剛剛完成的程式(helloworld.py)跟設定檔(app.yaml)
輸入並執行以下命令
appcfg.py update .
appcfg.py 是 GAE 的上傳指令
update 是其中一個參數. 則是用來指出設定檔(app.yaml)的所在路徑
請依照提示輸入你的 Google 帳號與密碼即可完成上傳
註：關於appcfg.py的用法，請參閱以下
網址：http://code.google.com/appengine/docs/appcfgpy.html
連線到 GAE 網站即可看到上傳完成的程式及其版本
網址：http://appengine.google.com/
只要點選該版本連結即可執行我們開發好的 WEB 應用，恭喜你成功了 ^_^
衍生閱讀：
1. Python WiKi
2. Python 教學文件
2008年8月6日 星期三
反思：品質與度量?
關於品質的想法
測試要測哪些?對應的測試項目與規格?
測試人員與時間是否充分?
測試人員的素質?
測試人員該怎樣發揮?(提問的藝術)
問答過程能不能找到問題背後的原因?
問答過程能否釐清可能的解決方案?
問答過程都可以有效地追蹤與管理?
我是一個知識工作者?反思：問題應該修正成『身為一位知識工作者，我應該多做些甚麼?』
觀點：問對問題比較重要
該怎樣提問呢?
重要性如何決定?
練習提問的藝術
換個角度思考，例如：工作管理，工作涉及到的人員、任務與進度該怎樣管理比較恰當?是否有其他可能方案?
任務 | |||
人員 | 待處理 | 執行中 | 已解決 |
張三 | … | ||
李四 | … | ||
王五 | … | ||
典型的工作分配表
任務 | |||
人員 | 待處理 | 執行中 | 已解決 |
張三 | … | ||
李四 | |||
王五 | |||
換個角度思考之後的分配表
追問：兩個方案的優缺點分別為何?兩方案分別適用怎樣的情況?有無假設與前提?
問：IT 專案可以度量的項目為何?好處與缺點?
很多地方都會提到的基本度量如時間、成本、範疇、品質。
直覺看到的是時間、投入、產出、瑕疵(defects) 等輸出，但真的只是這樣?還有沒有其他可能性?
反思：以上這些量化資訊是在怎樣的假設或者前提之下建立的?
反思：這些資訊的真正用途為何?只為了取得認證?
有的度量可以很多，通常都會包括非常多的衍生性數據，差異就是很有用的資訊，例如：投入與產出的差異、規劃與實際的差異、需求改變的次數…
反思：為了量化所投入的成本是否值得?
反思：真正適合公司/組織的核心指標為何?
觀點：如何評估真正的baseline?
自省：我是 IT 經理人?
身為資訊產業經理人，我應該把時間投入在哪些面向?
9 PAs：
以上 9 PAs是書本上教導的，也是很多人的智慧結晶，實務上，也常常發生類似的狀況需要應用以上知識去處理，但，主管們迫切擔心的事情，卻往往是另外一回事，
主管真正擔心的事有：
沒有業務、訂單、合約
營收不正常，現金流量管制失衡
員工無法於時限內完成交付的任務
…
捫心自問，我們究竟有沒有投入時間去思考這些問題的成因與解決方案?
問：業務開展困難的原因究竟為何?
時間、成本、品質或者專案範疇控制不當?
市場供給過剩?需求降低?市場供需失衡的因應之道?
委外，我們是否有足夠的能力確保委外的成果?
擴大需求，有看到潛在的市場?還是打算壓低售價?品質能同時兼顧?
減少供給，退出紅海?
少量多樣，怎樣做到?
市場售價過低?
為何其他公司仍能承擔?
業務受限、觸角不夠深遠?
公司希望業務做到甚麼程度?
業務的疑問是，公司到底能做些甚麼?
反思，我們是否有給公司清楚的資訊反饋?(客戶心聲)
問：降低售價提高品質的方法?
有效率的標準化作業
採取預防型的QA/QC，測試優先
可重複使用的標準化元件設計，例：OSGi, SOA 的概念
提升員工素質
只做擅長的事，並且每 25 周更新擅長的領域知識
正視成本結構，清楚理解自己跟競爭廠商的差異
問：可以最常被重用的元件有哪些?特性為何?
底耦合度
高內聚力
品質可以掛保證，有品質防火牆
Self Contained
具焦於特定 Features，例：SSO
問：因為沒有團隊配合就不能做事?
答：應該思考的面向是，還可以多做些什麼?
IT 知識共享
Domain Know How 共享
知識延續之外，智慧是否能累積?
問：我到底擅長甚麼?
團隊培養，我真的有培養出高級團隊?怎樣才稱得上是高級團隊?
人材人才，技術能力養成、溝通協調
人才人財，解決方案提供、共好
能夠盡一己之力的地方
專案管理與團隊合作
品質追蹤與標準化製程
有效率的元件規劃與系統架構
觀念：要做就要追求極致，而非完美
訂閱：
文章 (Atom)