Hibernate Entity Manager / JPA Annotation

ORM 除了用 xml 設定方式之外, 例一種方式就是用 @annotation, 這裡一樣透過案例展示, 直接示範幾種常用的關聯
包括：
1. 單一物件
2. 一對一關聯
3. 一對多關聯
4. 多對多關聯
5. 繼承關係



相關資訊:Test Driven Development(TDD)

第 21 頁

今天看了李家同教授的"第 21 頁"這本書，感觸很多，許多兒時記憶也浮上心頭，小時放學後，總在嬉鬧的氣氛中返家，放學的感覺真的很好，因為，只要回到家，就可以跟玩伴們到住家旁邊的黑森林去探險，對於六年級前段班的我們而言，兒時生活就是這樣驚險！

每日固定的返家路線定會經過一位女同學的家，我也從來不以為意，但，自從那天之後，我改變了路線，刻意避開這位同學的家...為什麼呢？

那天，玩伴們在相同的嬉鬧氣氛中返家，途經那位女同學家時，我被她的母親叫住了，當我還停在路上搞不清楚怎麼一回事的時候，就被一連串的責罵聲給嚇壞了...這位母親怪罪我前一天弄翻了他女兒的便當，害他女兒沒有午餐吃，我辯稱沒做這件事，這位母親回答說:「他女兒說是啞巴的兒子...」...

是的，我是啞巴的兒子，但罪魁禍首並不是我，真正弄翻他女兒便當的人是我的另一位同學，而這位同學...是喑啞人士。

年幼的我，碰到這種情形，心裡自然充滿了無奈，更多的是疑問！難道, 啞巴的兒子就該被羞辱？父母親也是努力討生活的台灣人阿...，一直以來，我沒得到對方的道歉，也沒想過要對方道歉，因為我知道，父母親一定承受了比我更多的橫逆，只是他們沒有說出來而已。雙親雖然不會說話，但他們始終努力承擔我們這六位子女帶來的重擔，無怨無悔。對自己而言，這樣的生活態度，一直影響著我，至今！

看看李教授的文章，想想自己為這社會帶來怎樣的影響吧...

推薦書籍:

Hibernate Entity Manager / ORM

使用過 hibernate 開發程式的人, 都會碰到 ORM 的問題, 這份簡報整理了常用的關聯案例,

包括：
1. 單一物件
2. 一對一關聯
3. 一對多關聯
4. 多對多關聯

透過案例展示, 方便大家日後查詢之用, 強調一下, 寫好的程式必須"通過測試才能算是真正完成"



需要完整的範例程式? 連同你的建議寄送到我的信箱! 歡迎各位提供建議 ^_^

相關資訊:Test Driven Development(TDD)

UML Overview

學習 UML 過程中, 免不了要整理這些圖, UML Notations / Diagrams 是溝通的基礎, 即便是簡單的一張圖都代表了許多的意涵, 重點是解讀的人, 大家是否具備相同的認知基礎? 學習 UML Notation 的語意, 就像學了軟體世界的共通語言, 也像學習一般外語, "使用"才是真正的"學會"

這份文件也可以當做考 OCUP 認證的參考資訊, 但, 我要強調, 重點還是"用這個工具去溝通"



衍生閱讀：敏捷塑模

建構與變更管理課程後

講完建構與變更管理課程後, 我收到了以下回覆：「我們是一個 embedded 系統廠，每個案子的變數都相當的多，有硬體，軟體，客人臨時要求 .... 這種不同的變數。我想上課的內容的確給了許多觀念與想法，可以讓我們在執行時多想想的。...軟體初開發時，哪些事情是要注意的，在開發過程中，哪些資料需要建立，還有面臨變化時，怎麼樣可以把問題降低，解決。讓PM可以把工作控制的更安全。這是我們希望能學到的。」

很謝謝你的回饋, 關於你信件中提到的問題, 我盡可能回覆如下：
案子成立之初
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)等工具，從諮詢服務與案例演練的過程中，我發現到，具備品質觀念的工作團隊加上適合的工具，就像關老爺遇到了赤兔馬一樣，一拍即合。



能夠為顧客提供適切的服務，是最愉快的事業了...真慶幸自己可以從事這種性質的工作 ^_^

實現兒時的夢想 BY Randy Pausch

我們改變不了上帝發給我們的牌, 但, 我們可決定怎麼打這手牌

這場演講可以讓自己反省很多事情, 困難永遠存在, 面對困難的處理方式卻有很多種...我們打算怎樣面對?
或許, 聽聽看 Randy Pausch 的觀點, 讀讀自己內心的想法...



Randy Pausch Last Lecture: Achieving Your Childhood Dreams

推薦書籍:

建構與變更管理案例 [Subversion]

近來講了幾回建構管理實際案例[Subversion]的課程, 發現大家都有使用類似的建構管理(版本管控)環境,但卻很少人注意到這個工具可以為團隊工作帶來的其他好處, 多數工程師都認為這工具有用助於分工合作, 也有少數工程師認為建構管理帶來某些困擾, 例如: 修正好的程式一定要逐一簽入(check in)嗎? 能不能整批一塊做?

先看看以下案例吧!!