在使用單向一對多mapping，一種簡單的作法是在「many」的一方中的table中的某一個欄位用來儲存「one」一方的主鍵，如果以下方範例來說， Address表中有一欄叫personId是Person表中的主鍵。 create table Person ( personId bigint not null primary key ) create table Address ( addressId bigint not null primary key, personId bigint not null ) 取自Hibernate reference Documentation 3.3.2.GA, 7.2.3 set 要加上 cascade="all" or cascade="save-update" 當我們在儲存Person物件（含有Address）的時候，hibernate可以自動幫我們將Person的主鍵填入Address表的personId欄位中而不需要手動寫程式。 關鍵在Person的mapping document上 key column中 not-null="true" 的這個設定。 public class OneToMany { public static void main(String[] args){ Address add1 = new Address(); Address add2 = new Address(); Person p1 = new Person(); p1.sets(new HashSet()); p1.getAddresses().add(add1); p1.getAddresses().add(add2); Session session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = session.beginTransaction(); session.save(p1); // cascade tx.commit(); ...
發表文章
今年在教會上了 培基文教基金會 的理財課程，感覺非常實用，第一次發現聖經中的道理這麼實際而貼近生活，第一課就先談「財務自由」這個觀念，現在流行的財務自由觀念，大概來自富爸爸、窮爸爸系列的書，可以參考以下連結。 什麼是財務自由 簡言之，就是 持續性(非工資性)收入大於單次性(工資性)收入。 也就是說，如果你現在躺著不工作，也能透過之前的投資（或其他財務措施）擁有一份穩定又持續性的收入（現金流），那你就達到財務自由了，也就是不用一直努力每天工作才有收入（單次性）。 但 這不是聖經觀點的財務自由 。 透過培基的理財課程，我們知道聖經所透露出的財務自由是全面性的，是由人的生命角度出發來看的財務自由，其包含上帝的誡命、聖經的真理，以及人跟財務與上帝之間的關係。 而富爸爸所講得財務自由是很片面的，淺薄的一種財務自由，從定義來看就隱含了很多假設，如果這些假設不成立，那根本沒有所謂的自由。 第一個最明顯的假設就是： 持續性的穩定收入要大於你的經常開支。 例如個性浪費，愛亂花錢，隨意刷卡，或是賭博，那就算你每個月透過投資有穩定的高收入，最後還是會被你自己花光，還是得不到財務自由。這一點假設引申下去就是 忽略了人性的墮落面 ，不管你有多少錢，人性各式各樣的墮落都會使人失去自由。 這定義隱含財務自由的焦點只有「金錢」 也許你窮盡一生創造了驚人的持續性高收入，但是回頭卻發現你的老婆要跟你離婚，分走你一半的積蓄，或是兒子偷偷騙走你的錢，更或是子女們為了爭奪財產搞得雞犬不寧，這是「富爸爸財務自由」不會提到的。 這種定義似乎假設人生沒有意外 雖然擁有持續性的穩定收入不用工作，但萬一你父母生重病、不可預期的投資失敗、金融海嘯、出車禍、朋友倒債等等，這些任何一項都有可能一下子就摧毀所謂的「富爸爸財務自由」。 所以，如果我們不該把目標定在膚淺的、片面的「富爸爸財務自由」。而理財課程告訴我們，在上帝的旨意裡管理財務，才能得到全面的、平衡的財務自由。所以培基的理財課從聖經的觀點談上帝對金錢設定的目的與旨意、十一奉獻的意義，以及比較方法性的記帳、詐騙、借貸、作保、購買、合夥，還有家庭、妻子、遺產等主題，可說是全方面造就我們在理財上得觀念，進而達到真正的財務自由。
在Web Dynpro中提供3種資料流機制[1]，只要適當地設定，可以不用寫程式就將畫面、中間層控制器(controller)到後端模型物件的資料自動化地、牢靠地綁在一起，使得不管前後端某一方有資料變動，變動部份都會自動地流動來保持一致性，使得前後端都能存取到同一份資料。 context 關鍵元件是 context，每個controller都有一份屬於自己的context，它扮演MVC架構中的M (model)，web dynpro的實做方式比較像是該controller的「資料空間」，它由node(資料節點）與attribute（資料屬性）組成，controller可以透過wdContext這個預先產生好的 shortcut variable（捷徑變數）去取得context的資料內容。 context中必須要建立node才可以儲存資料，一個node代表一個collection(集合物件)裡面仍可以含有node, attribute，node裡面的一份資料實體就是一個element，一個node可以有一個或多個element（這部份可以透過cardinality property設定），其結構就是該node所包含的結構。 data binding 此種機制可以將UI元件的資料跟context中的某個node或attribute綁定在一起，context中的改變會自動 更新到UI元件上，UI元件的改變也會自動寫入到綁定的context node(or attribute)中。通常UI元件所綁定的node（attribute)是由component controller對應過來的。 context mapping 每一個controller都有屬於自己的context(資料空間)如果要達到彼此共享資料，則要透過context mapping機制，一旦mapping設定好，則會在另一個context產生一個同樣的結構的node，兩邊的controller會存取到的是同一分資料，任何一邊的資料更動都會散佈到設定好mapping的node。 不過在web dynpro裡，只允許將custom controller or component controller的node對應到view controller去，不允許從view controller對應回來，主因是嚴格遵守MVC...
特長： 清晰的MVC架構 自動化建立模型類別(model class) 透過3種data model機制(model binding, context mapping, data binding)可以很容易保持資料模組化與前後端一致性 利用context node機制抽象化、統一化對後端各種不同model的存取方式 各種重用性高、可設定的UI元件，只要拖拉即可快速建立畫面 UI元件可與office、Adobe flex作某種程度整合 各種工具類別提高開發效率(ex: Window Manager, Message Manager) 畫面可以重複使用在不同的client裝置（web browser, pocket pc, blackberry)，無須重新開發 缺點： 沒有提供使用者輸入驗證的架構（要自行實做） UI元件無法客製 必須使用NetWeaver server，是SAP獨有技術 必需要用NetWeaver Development Studio開發，雖然是基於eclipse的IDE，但是許多好用的功能與快速鍵都被改掉，反而較不好用 不易與其他third party framework整合，如Hibernate
在jdk1.5下使用StringBuffer，如果在同一行連續使用append StringBuffer sb = new StringBuffer(); sb.append("test").append("test2"); 有些IDE會出現以下compilation error訊息： The Type AbstractStringBuilder is not visible. 但如果分開寫就沒有這個error： <big><br />sb.append("test");<br />sb.append("test2");<br /></big> 原因有兩個 其一是，Java2SE5.0 開始有covariant return types這個新feature，意思大約是「可變回傳型態」，主要是讓子類別在覆寫(override)父類別的某個method時，回傳型態可以是父類別回傳型態的子類別。例如 <br />Parent class{<br /> Parent getObj(...){...}<br />}<br /><br />Child class extends Parent{<br /> Child getObj(...){<br /> ...<br /> return Child;<br /> }<br /> 其 二是1.5之後新增了AbstractStringBuilder為StringBuffer, StringBuilder的父類別，但他卻是private類別，甚至從javadoc上也看不到此類別，你只會看到StringBuffer, StringBuilder都繼承自Object。 所以，第一種寫法，StringBuffer append()可能被IDE compiler判定回傳AbstractStringBuilder然後又呼叫其append()，導致發生找不到 AbstractStringBuilder情形，這應該是IDE可以解決的問題，我聽說ecli...
在執行專案過程中有些事件，就跟「你想通了嗎」[1]一書中提到的情景類似，不過當下卻沒有察覺，都是事後解決才發現問題的癥結。 案例一： 在系統即將完成的後期，客戶才表示，其中一項W功能要增加一個新的表單，當初只談好要作2個表單，每個表單其實是對應到他們現有 一項業務，客戶負責提需求的人忘了提出他們還有另一項業務是不同於前2項的，必需要作一個新表單來專門處理這項業務。如果幫客戶做，則延長開發時間，不合 成本，但若拒絕，則這個系統又少了一項執行重大業務的功能，客戶接受度降低。當然我方大可以不符合約的理由正當的拒絕，但似乎不夠圓融，雖然後來我方委婉 說明，希望客戶打消此念頭，但客戶仍持續提出要求，這似乎是個兩難個局面。 後來的解決方法是在兩個原有的表單加上一個可以自由輸入的欄位，這樣，原有2項表單便免強可以轉作第三項業務使用，算是兩方都滿意的解法。不過這方法一開始也沒想到，是跟客戶討論的時候，被提醒的。這件事， 問題的擁有者 是 客戶 ，並不是我，也就是問題並不是「要不要作第三個表單？」，而該是客戶心理想的：「怎樣才能讓系統幫我處理第三項業務？」如果這樣思考就能跳脫出先前作新表單的思維中。 案例二： 我們要接手前一家公司做好的系統，並對其作部份的修正，需求很明確，但在專案一開始我們對技術與對方的程式碼都不熟悉的狀況下，客戶基層主管R就要我們提 出每項功能的時程，因為距離預定上線的時間只剩一個月，我們彼此又是第一次合作，因此主管R希望我們儘早告訴他我們的schedule。不過在不熟悉對方 系統架構與程式碼的狀況時，實在是很難估計明確的時間。這是一個兩難局面，隨意給一個時程，恐怕造成我們自己未來難做事，不給時程，客戶又相當堅持。 這問題的解決仍然是因為跟客戶溝通的拉鋸過程中，他偶然提到的訊息，因為他要給系統的user、主管一個交代，因此才要我們提出明確時程，因為距上線只有 一個月，我們就答應在三個星期後完成，中間的時程，之後再提出，這樣才算達成共識。一開始問題好像是「怎麼估計出工作時程？」，但是如果換到問題的擁有 者，主管R身上時，問題變成「我怎麼跟主管、user報告，系統何時可以完成？」 雖然我們常常聽過「換個角度想」，但是要換到哪個角度，卻是個問題，以上兩個都是比較簡單的狀況，只要我們換到問題的...
常常有人覺得為甚麼基督教這麼霸道、自以為是，就說自己的神是唯一真神，其他宗教的神都是假的，為甚麼不能彼此尊重一下，大家都是神呢？大家的神都在天上和平共處，一起打個麻將不是很好嗎？ 唐崇榮牧師給了很好解釋。
軟體開發工程師的十大特質（上） 軟體開發工程師的十大特質（中） 軟體開發工程師的十大特質（下） 非常認同以上文章觀點，不過不知道這樣特質的工程師在台灣業界市場機制中是否真有價值。尤其是IT委外的紅海當中，工程師似乎不管能力，只有一個價錢，而且還越來越低，如果優秀的工程師不能令客戶出更多的錢，那麼有誰會願意努力成為優秀的工程師。 我也不瞭解，難道系統真的隨便一個人都可以作嗎？走了隨便找一個人都可以取代嗎？
簡單心得： my.ini [mysqld] ...略 # The default character set that will be used when a new schema or table is # created and no character set is defined #default-character-set=latin1 default-character-set=utf8 注意：是utf8不是utf-8，寫錯將導致MySQL服務無法啟動。 每個table在設定欄位都要指定為utf-8(column charset, column collate) 此圖是MySQL Query Browser的設定畫面。 如果你原本已經設定了其他編碼，要改成utf8，文字內容可不會自行轉碼，你要自己想辦法將文字內容轉換再存進去。
1. use context object to register a document and the return value for document id. 2. use document id to load it's policy. 3. new a LimitList and set desired owner and set the LimitList to the document 4. change the document owner 5. save the document, that document now can only be opened by the desired owner.
使用Spring過程中突然發生application server啟動即出現bean definition file parsing的以下錯誤： BeanDefinitionStoreException: Unexpected exception parsing XML doc ument from class path resource.. nested exception java.lang.ClassFormatError: Unknown constant tag 0 in class file com/sun/org/apache/xerces/internal.. 詳細檢查了數次都找不到xml哪裡有錯。 ClassFormatError這個錯誤很少見，似乎是JVM內Hotspot相關的錯誤，而且同時其他所有舊的project使用Spring原本可以正常執行的，現在都會產生這個錯誤。 研判可能是JVM出了什麼問題，重裝JDK1.5這個問題就消失了。
在專案中我們使用DAO這個pattern來封裝資料庫存取層，Hibernate Quickly (Manning)中建議我們可以繼承Spring所提供的HibernateDAOSupport來簡化DAO程式碼，這是很常見的作法。 原本method重複性很高的部份： public void create(Event event) throws DataAccessLayerException { try { startOperation(); session.save(event); tx.commit(); } catch (HibernateException e) { handleException(e); } finally { HibernateFactory.close(session); } } 可以被簡化為： public abstract class AbstractSpringDao extends HibernateDaoSupport{ public AbstractSpringDao() { } protected void saveOrUpdate(Object obj) { getHibernateTemplate().saveOrUpdate(obj); } protected void delete(Object obj) { getHibernateTemplate().delete(obj); } ... } 都透過Sprgin提供的HibernateTemplate幫我們作掉那些重複的開、關session, transaction動作。 以下擷取自Spring原始碼 package org.springframework.orm.hibernate3; ... public class HibernateTemplate extends HibernateAccessor implements HibernateOperations { ... public Object execute(HibernateCallback action) throws DataAccessException { Session session = (!this.a...
近期使用這三套framework作系統，系統架構如下: 其中使用的Design Pattern: MVC: To separate core business model functionality from the presentation and control logic that uses this functionality. Such separation allows multiple views to share the same enterprise data model, which makes supporting multiple clients easier to implement, test, and maintain. Front Controller Use a controller as the initial point of contact for handling a request. The controller manages the handling of the request, including invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies. DAO(Data Access object) To abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data. 如果同時運用這三個application framework，這樣的架構算是很常見。 Pros: 運用struts前端控制器(front controller)來集中管理頁面導引 Struts custom tag來強化 JSP的不足 用Sp...
瞭解考試主題範圍 。因為相關的文件很多，如果要全部讀完才參加考試太過耗時。因為考試題目完全以官方所列的主題為主，連認證成績單上的得分率都以官方所列的主題作分類來評分。 [考試成績單] 所以考試主題作為準備的主軸會是比較有效率的方式，官方網站上可以抓到E20-120 Content Management Foundations Exam Exam Description。 [ExamDescription] 詳讀每個主題內容所描述的子題，以此準備可以確保不會漏掉任何一個方面。 [subTopics] 閱讀各項使用手冊 。單純只讀官方訓練教材只能給你一些基本概念，但是有些細節還是需要查手冊。以下是可能會需要參考的手冊清單 Content Server Fundamentals Content Server Administration Guide Content Server DQL Reference Manual Object Reference Manual Documentum Administrator User Guide 官方網站上的產品介紹 作筆記。 自行整理相關概念，可以幫助記憶。我是採用心智繪圖(Mind Map)來作筆記。 [DocumentumMindMap] 反覆作模擬試題來確定自己準備的狀況 。 EMC官方網站有模擬試題（ 連結 ）不過數量很少，只能算熱身瞭解一下題型。 dm_cram 有討論區與大量模擬試題的資源，還依照主題將模擬試題分類，所以你可以讀一個主題就練習該個主題的模擬試題，非常有利於複習。雖然模擬試題有許多複選題，不過實際考試的時候都是單選。 另外還有討論區可以與其他參加認證的人交流，這是我目前查到唯一的Documentum認證考試資源網站。 Documentum Content Mangement Foundations: EMC Proven Professional Certification Exam E20-120 Study Guide這本書的作者 Pawan Kumar也在這個論壇上活動，所以應該可以得到很正確的解答。 不過網站上的模擬試題有部份我覺得太刁鑽，如果真的查詢手冊找不到答案，我想應該可以忽略。
使用FreeMind有好一段時間，不過畫面單調一直是我不滿意之處。 XMind在畫面上好看很多，節點形狀樣式、分支線樣式有多樣選擇，也可以匯入FreeMind的檔案。 類似Excel般，工作頁活頁的概念也很不錯，可以將多個相關的心智圖存在一起。 可以某個分支為中心來檢視的功能也很令人激賞，完全符合心智圖那種可見樹、可見林的特性。 不過使用上有幾項缺點: 1.不能設定節點的預設文字大小。 預設應該是10點字，太小了，但是「喜好設定」內沒有地方可以修改，需要每次自己加大字型，很麻煩。 2.沒有加大字型的動作可以設定快速鍵。 我喜歡不只是用顏色，還有用字型的大小來凸顯主幹、分支的差別，不能快速的增大、縮小字型很不便。