覺得Xoops的確是一個非常優秀的網站建構與管理的軟體
下面舉出台灣一些用Xoops建構的網站
社群
數位網路社群 http://www.dns.com.tw
圓球城市 http://www.roundballcity.com
組織
新竹市動物保護協會 http://www.sawh.org.tw
財團法人仰山文教基金會 http://www.youngsun.org.tw
台灣動物科技研究所 http://203.204.110.36/xoops/modules/news/
台灣國際醫學聯盟 http://www.tima.org.tw/xoops/html/modules/news/
企業
艾桃科技 http://www.osobiz.com/xoops/
竹山自然療法資訊站 http://www.chushan.com.tw/
網站達人 http://www.meto.com.tw
風水命理專業網 http://www.cnbc.com.tw/xoops/
教育
人文社會科學教育先導型計畫 http://hss.edu.tw/ or
http://hss.edu.tw/xoops/modules/news/
北區中小企業研訓中心 http://nsme.nccu.edu.tw/xoops/modules/news/
新竹市科園國小 http://www.kyps.hc.edu.tw/ or http://163.19.138.131/xoops/
台中縣教師會 http://www.tccta.org.tw
個人
島先生的家 http://www.mrbert.idv.tw/xoops/
如果引用或轉貼,麻煩註明出處與本網誌連結，否則視為侵權。
2005年6月7日
2005年5月31日
研讀PetStore的重要參考網址
研讀PetStore的重要參考網址
Author: Fred Wang(http://fredwang.blogspot.com)
Date : 2004/10/27
看Java PetStore這個個案研究是學習J2EE Architecture and Design Patterns者必經的過程，下面是一些參考的網址:
1.SUN官方網站 PetStore : 位於Sun Java Developer Network Site, 在此下載最新版的PetStore, 並連到重要的參考文件The design guidelines of the JavaTM Blueprints program
另外這份Design Guidelines的線上手冊在這裡,
線上瀏覽原始碼
2.Java Blueprints Program : 包含三大Demo, 一為Java Adventure Builder, 一個就是有名的Java PetStore, 另一個為Wireless : Java Smart Ticket Sample Applicartion, 都可以在這裡下載
有一些問題嗎? 這裡還有PetStore的常見問題解答
3. JavaGen’s Java PetStore Demo Site :
要瞭解PetStore的操作不必自己安裝, 到這裡就好, 你也可以到這裡 看看Richard Easterling如何用JavaGen code generator花七週就將這個Java PetStore開發完成
4. Java PetStore的安裝, 使用, 編譯, 組態(簡體中文版) :
這個網站內也有許多值得參考的Java文件
, 英文版的安裝, 使用, 編譯, 組態在官方網站的這裡
5. 中文Java技術網的PetStore1.3.1專案 :
其中PetStore小組成果發表了幾篇文章, 以”動物園的豬”發表的那篇最好(翻譯自SUN網站這篇文件 極力建議看原文的更好)
6. xPetStore : 用兩種方法重寫PetStore :
a. A pure EJB solution based on JSP, Struts, Sitemesh, EJB 2.0 and CMP 2.0
b. A Servlet solution based on Velocity, WebWork, Sitemesh, POJO and Hibernate.
7. PETSTORE 原始碼追蹤記(作者歐亙修)
目前共寫了三篇, 可用Google搜尋工具尋找
Author: Fred Wang(http://fredwang.blogspot.com)
Date : 2004/10/27
看Java PetStore這個個案研究是學習J2EE Architecture and Design Patterns者必經的過程，下面是一些參考的網址:
1.SUN官方網站 PetStore : 位於Sun Java Developer Network Site, 在此下載最新版的PetStore, 並連到重要的參考文件The design guidelines of the JavaTM Blueprints program
另外這份Design Guidelines的線上手冊在這裡,
線上瀏覽原始碼
2.Java Blueprints Program : 包含三大Demo, 一為Java Adventure Builder, 一個就是有名的Java PetStore, 另一個為Wireless : Java Smart Ticket Sample Applicartion, 都可以在這裡下載
有一些問題嗎? 這裡還有PetStore的常見問題解答
3. JavaGen’s Java PetStore Demo Site :
要瞭解PetStore的操作不必自己安裝, 到這裡就好, 你也可以到這裡 看看Richard Easterling如何用JavaGen code generator花七週就將這個Java PetStore開發完成
4. Java PetStore的安裝, 使用, 編譯, 組態(簡體中文版) :
這個網站內也有許多值得參考的Java文件
, 英文版的安裝, 使用, 編譯, 組態在官方網站的這裡
5. 中文Java技術網的PetStore1.3.1專案 :
其中PetStore小組成果發表了幾篇文章, 以”動物園的豬”發表的那篇最好(翻譯自SUN網站這篇文件 極力建議看原文的更好)
6. xPetStore : 用兩種方法重寫PetStore :
a. A pure EJB solution based on JSP, Struts, Sitemesh, EJB 2.0 and CMP 2.0
b. A Servlet solution based on Velocity, WebWork, Sitemesh, POJO and Hibernate.
7. PETSTORE 原始碼追蹤記(作者歐亙修)
目前共寫了三篇, 可用Google搜尋工具尋找
Labels:
Java
2005年5月29日
Web Content Management(WCM)的定義與功能
Fred Wang譯 (http://fredwang.blogspot.com)
Source: Gartner Group, "Gartner Group's Checklist of Core Web Content Management Functions"
定義 : WCM是透過特定工具來控制網站內容的程序，這些工具可以對HTML網頁進行管理。Gartner Group將WCM分成下面九大功能。
變更管理 : 控制內容的開發，程式開發與版本控制。
動態內容 : 內容需不斷的更新以提供新或是更新的資訊。
工作流程 : 允許自動的工作程序，輔助內容建立者，編輯者，瀏覽者及應用者間的互動。
設計樣板 : 讓使用者放文字及圖形在空白的表單上。透過預定的規則將樣板自動與內容結合。
WCM儲存體 : 專注在管理特定內容格式，至少包含HTML與XML
複製及部署(Deployment) : 複製及部署將內容在伺服器間搬移並允許網站鏡射(Mirror)。特別是將內容從測試和臨時(staging)系統搬移到上線使用(production)的伺服器。
個人化 : 為特定的網站訪客或訪客類別做資訊的剪裁。
安全管理 : 控制存取WCM應用，以角色為基礎。
可移植性 : WCM應用系統可以移植到不同架構，如從MS Windows NT到Sun Solaris。
整合和開發工具 : 讓使用者將WCM應用系統與其他應用系統綁在一起，包含與舊系統的整合。
http://www.softwaremag.com/L.cfm?Doc=archive/2000oct/GartnerGroup.html
Source: Gartner Group, "Gartner Group's Checklist of Core Web Content Management Functions"
定義 : WCM是透過特定工具來控制網站內容的程序，這些工具可以對HTML網頁進行管理。Gartner Group將WCM分成下面九大功能。
變更管理 : 控制內容的開發，程式開發與版本控制。
動態內容 : 內容需不斷的更新以提供新或是更新的資訊。
工作流程 : 允許自動的工作程序，輔助內容建立者，編輯者，瀏覽者及應用者間的互動。
設計樣板 : 讓使用者放文字及圖形在空白的表單上。透過預定的規則將樣板自動與內容結合。
WCM儲存體 : 專注在管理特定內容格式，至少包含HTML與XML
複製及部署(Deployment) : 複製及部署將內容在伺服器間搬移並允許網站鏡射(Mirror)。特別是將內容從測試和臨時(staging)系統搬移到上線使用(production)的伺服器。
個人化 : 為特定的網站訪客或訪客類別做資訊的剪裁。
安全管理 : 控制存取WCM應用，以角色為基礎。
可移植性 : WCM應用系統可以移植到不同架構，如從MS Windows NT到Sun Solaris。
整合和開發工具 : 讓使用者將WCM應用系統與其他應用系統綁在一起，包含與舊系統的整合。
http://www.softwaremag.com/L.cfm?Doc=archive/2000oct/GartnerGroup.html
2005年5月24日
專業的危機，來自於盲目的自信
專業的危機，來自於盲目的自信
2005.05 Fred F.M. Wang(http://fredwang.blogspot.com)
登高必自卑，行遠必自邇，歷來越是偉大的科學家，越能體會人類知識的渺小，誠如牛頓所謙稱的，他不過是像一個被海邊景象所吸引的好奇小孩，在海灘的探險遊戲中偶然有所發現而已。[1] 而電腦專業技術人員，往往因為熟悉或熟練某種技術而產生盲目的自信，這又可稱為霧窗的效應，在蓋滿霧氣的玻璃窗上擦去一小圓圈的霧氣，所能看清楚的僅是這一小區域所能看到的世界。
盲目的自信將使工作困難推展，導致專案失敗，團隊無法和諧相處，得罪上司與客戶，屬下紛紛離去，甚至影響到朋友，家人，產生專業的危機。
下面的十一種症狀用來檢視自己是否患了這種毛病:
1. 不能開放自己，接受善意或惡意批評
有些人因為對自己的期許很高，害怕面對自己的不足、不完美，所以無法接受別人善意或惡意的批評。
有些人則是因為習慣害羞閉塞，使他很少表達自己的想法和意見，當然能從別人那裡得到的回饋也就非常有限。
還有一種情形是「信仰堅定」，太過於肯定自己原有的信念，不僅忽略或聽不進去跟自己不同的觀點或想法，甚至還摒棄它！
如果能把別人善意或惡意的批評，都當成是成長的契機，反倒比較可能突破個人專業的瓶頸。畢竟人都有盲點，自己 注意不到的東西，根本不會進入思考，也不可能成為判斷的依據。所 以別人的回饋，反而是反省、澄清、補充、延伸自己思考的機會。
如果在心態上可以容忍自己和別人一樣是不完美，都是會有疏失 、出錯、犯錯的人，以這樣的平常心、自然人的態度，試著讓自己和 別人經常有互動的機會，然後比較一下自己是否在這樣的互動中得到一些過去所沒有的互動經驗，才能使自己和別人一起成長。[2]
2. 只願意做自己想要做的技術，想要用的技術如電腦語言，工具或平台
當能力受限於單一技術，或習慣於特定技術，有些人懼怕改變，因為自己在此專業上為組織內的權威，而學習或使用其他技術將對自己的地位的造成影響，因為新東西每個人的立足點相同，而熟悉的技術是自己最安全，最舒適的領域，只要用這個技術就如魚得水，用其他技術就如臨深淵。最明顯的例子就是在專案技術的評估上明顯加入個人主觀的因素，影響評估的結果。
另外就是單一技術帶來工作的便利性，減少工作的複雜度，因此自然無法從多種技術來選擇及評估合乎成本效益的方案，更無法從企業利益或客戶需求來決定出最佳的解決方案，只要是用此技術，其他角度的成本及效益，對他而言是微不足道的。
3. 缺乏學習其他技術的意願
由於過於習慣於特定技術，認定該技術的所有優點，內心抗拒其他技術而造成學習意願的低落。
4. 捍衛某特定的技術如電腦語言或資訊產品，猶如捍衛自己的榮譽
某些人投注極大的心力於特定的技術，而這些心血是用許多不眠不休與青春歲月換來的，無法接受其他人對此技術的一點批評，這些批評猶如指出他這些心血是白費時間生命的，因此必然努力捍衛這項技術。
常見的.Net and Java的論戰，論壇上各人就其所熟悉的技術，各言其是，而很少有兩種都熟悉而以客觀的角度，去評價的。
論戰若能就事論事，相互切磋，則可互相學習而有進步，但是某些人因為自己信仰的特定技術，猶如自己名譽般的重要，不容他人侮蔑，如此流於名譽的捍衛，將他人的批評視為名譽的損傷，就是意氣之爭了，在專業論壇中常看到這種動氣的言論。
5. 過於專注技術而忽視專案成功的其他要素
專案成功有許多因素如預算，時程，組織，團隊，人力，技術能力，主管的承諾，等，任何一個因素無法達成就會造成專案的失敗，而有些技術人員常只專注於技術而不理會其他因素。許多技術人員喜歡專注於單一技術的研究及開發，而有時則過於理想化，無法接受因預算，時程及客戶等因素進行的調整，若是因此造成專案延遲或失敗，自然怪罪於其他因素所造成。
猶如Peter Senge "第五項修練"書中提到 "熟練的無能"，也就是過於本位主義往往造成團隊或企業的失敗。
6. 生涯規劃依賴於特定的技術如電腦語言或資訊產品
選擇工作時，只選擇使用特定技術的工作才肯做，現在常見的是有些人只找用Java語言的公司，這讓我想起過去老COBOL人的生涯危機，當企業慢慢將Mainframe汰換，進入個人電腦時代，C語言興起，進入網際網路時代，Java語言興起，而一些只會COBOL的前輩們，面臨後浪推前浪的危機，被取代的恐懼。
而生涯的成就也依賴於在特定技術上的成就，而其他人生的要素如家庭，健康，朋友與人際等一蹋糊塗也不在乎，於是生命中所擁有的東西只有這項技術，離開這些就一無所有。
7. 敝帚自珍的觀念，不願分享
發表文章，也是專業成長的方式，專業能力的成長，代表的是自己能看見從前看不見的現象，能做到從前做不到的事，或是能把所做的事做的更好！ 在專業領域中，自己可能會疏漏很多重要的訊息，也可能有許多 不自知的壞習慣，所以，與同事、或同業人士進行專業的討論，文章的分享非常重要。[2]
把自己的工作、研究心得發表出來，無論是在小小的論壇上、小型的期刊雜誌上，或是正式的期刊上發表文章。除了傳遞資訊，貢獻自己的經驗與知識之外，每一篇文章都會是一個成長的里程碑，留下自己的腳印，同時也可以獲得很多的回饋與鼓勵，更能激勵自己思考，帶動自己更進一步的發展。 [2]
但是害怕自己被取代，害怕暴露自己的不足而不願意與他人分享，將阻礙自己的成長。
8. 過度自卑後的過度膨脹的自尊，不願接受指導及管理
由於懂得不多，害怕不能得到他人的尊重，因此如蟾蜍面對敵人時盡量膨脹自己，以虛張聲勢，此種防衛的心態，造成不能接受他人的指導及管理，凡是只要別人配合自己，不肯配合他人，自己的決策一定要他人接受，而不在乎其他成員的看法，而如果出問題一定是別人的問題。
過度膨脹的自尊造成對他人與自己相關的工作與技術的言行，都相當敏感，因此造成多疑的心理狀態，不如我的意就以為是對我的不尊重，所有喜怒哀樂決定於別人對自己的讚美，感謝或批評。
過度膨脹的自尊當然看不到別人的優點，別人的努力與成就，更不屑於技術能力(自己擁有的技術)比自己差的主管。
9. 過於技術導向，缺乏人文的素養，人性化的考慮與人際溝通的能力
有些生活在技術的世界的人，唯有技術才是最實在的，最腳踏實地的，而人文素養對他而言則是不切實際的代表，因此所做的事即決定都是缺乏人性化的考慮，因此做出來的系統，則完全不考慮到使用者操作的便利性，更不用說美感了。
缺乏人際溝通的能力，也常出現在技術人員身上，習慣用技術的術語，與使用者或客戶溝通，自然造成溝通的障礙，若在組織內部則永遠希望別人找他溝通，而非主動找他人溝通。
10. 不能系統化的思考，只著眼於片段，單一角度或短暫期間的問題解決
只看有利於自己的解決方式，只從單一個角度解決問題，只看短暫的解決方案，這些都是缺乏從整體及群體巨觀的角度思考，最後並無法解決真正的問題，甚至讓問題更加惡化。 (有關系統思考可以參考Peter Senge的"第五項修練")
11. 不能有系統的整理自己內在的經驗
當我們遇到困難時，拿問題問別人是最常見的方法之一，有時會 想到翻書、查閱資料；有時，也會從討論會，或是別人演講中聽到一些很好的觀念，但這些方法，卻未必能促進我們的專業成長。[2]
其中，最大的問題在於，從這些方法中，我們所學到的東西，可能是支離破碎的知識片段，也可能是一些充滿相互衝突、矛盾的觀念，與我們自己原本所有的知識、觀念不相容，或不相關聯，而我們卻不自知。[2]
例如一位電腦工作者，工作前五年用C語言開發系統，後五年用Java開發系統，但如果不能找出Java與C的差異，找出前五年哪些開發的經驗可以用在後五年，則每次使用不同的語言都無法為將來的工作帶來任何的好處，也沒有增進多少程式設計的功力，如此只能說經驗的增加而不能說是專業的成長。
所有專業無法脫離人性，不妨偶而跳出專業從人性角度檢視自己，學習一些自己專業外的知識，例如第五項修練，與成功有約等心智成長的書籍，如專案管理，人際關係管理等管理書籍，如繪畫，建築，音樂，美術設計等人文素養的知識，拓展視野，將會發現自己的渺小，然後重新建立新的人生觀與成熟獨立的價值觀，如此才能邁向更圓滿的人生。
Reference :
1. http://www.ksml.edu.tw/cmenu/read/club/014/1405.html 大滅絕讀後感
2. http://www.tmtc.edu.tw/~kidcen/epaper/20000916.htm，本文原刊載於86.5.19,86.5.26國語日報
3. Peter Senge,"第五項修練"
2005.05 Fred F.M. Wang(http://fredwang.blogspot.com)
登高必自卑，行遠必自邇，歷來越是偉大的科學家，越能體會人類知識的渺小，誠如牛頓所謙稱的，他不過是像一個被海邊景象所吸引的好奇小孩，在海灘的探險遊戲中偶然有所發現而已。[1] 而電腦專業技術人員，往往因為熟悉或熟練某種技術而產生盲目的自信，這又可稱為霧窗的效應，在蓋滿霧氣的玻璃窗上擦去一小圓圈的霧氣，所能看清楚的僅是這一小區域所能看到的世界。
盲目的自信將使工作困難推展，導致專案失敗，團隊無法和諧相處，得罪上司與客戶，屬下紛紛離去，甚至影響到朋友，家人，產生專業的危機。
下面的十一種症狀用來檢視自己是否患了這種毛病:
1. 不能開放自己，接受善意或惡意批評
有些人因為對自己的期許很高，害怕面對自己的不足、不完美，所以無法接受別人善意或惡意的批評。
有些人則是因為習慣害羞閉塞，使他很少表達自己的想法和意見，當然能從別人那裡得到的回饋也就非常有限。
還有一種情形是「信仰堅定」，太過於肯定自己原有的信念，不僅忽略或聽不進去跟自己不同的觀點或想法，甚至還摒棄它！
如果能把別人善意或惡意的批評，都當成是成長的契機，反倒比較可能突破個人專業的瓶頸。畢竟人都有盲點，自己 注意不到的東西，根本不會進入思考，也不可能成為判斷的依據。所 以別人的回饋，反而是反省、澄清、補充、延伸自己思考的機會。
如果在心態上可以容忍自己和別人一樣是不完美，都是會有疏失 、出錯、犯錯的人，以這樣的平常心、自然人的態度，試著讓自己和 別人經常有互動的機會，然後比較一下自己是否在這樣的互動中得到一些過去所沒有的互動經驗，才能使自己和別人一起成長。[2]
2. 只願意做自己想要做的技術，想要用的技術如電腦語言，工具或平台
當能力受限於單一技術，或習慣於特定技術，有些人懼怕改變，因為自己在此專業上為組織內的權威，而學習或使用其他技術將對自己的地位的造成影響，因為新東西每個人的立足點相同，而熟悉的技術是自己最安全，最舒適的領域，只要用這個技術就如魚得水，用其他技術就如臨深淵。最明顯的例子就是在專案技術的評估上明顯加入個人主觀的因素，影響評估的結果。
另外就是單一技術帶來工作的便利性，減少工作的複雜度，因此自然無法從多種技術來選擇及評估合乎成本效益的方案，更無法從企業利益或客戶需求來決定出最佳的解決方案，只要是用此技術，其他角度的成本及效益，對他而言是微不足道的。
3. 缺乏學習其他技術的意願
由於過於習慣於特定技術，認定該技術的所有優點，內心抗拒其他技術而造成學習意願的低落。
4. 捍衛某特定的技術如電腦語言或資訊產品，猶如捍衛自己的榮譽
某些人投注極大的心力於特定的技術，而這些心血是用許多不眠不休與青春歲月換來的，無法接受其他人對此技術的一點批評，這些批評猶如指出他這些心血是白費時間生命的，因此必然努力捍衛這項技術。
常見的.Net and Java的論戰，論壇上各人就其所熟悉的技術，各言其是，而很少有兩種都熟悉而以客觀的角度，去評價的。
論戰若能就事論事，相互切磋，則可互相學習而有進步，但是某些人因為自己信仰的特定技術，猶如自己名譽般的重要，不容他人侮蔑，如此流於名譽的捍衛，將他人的批評視為名譽的損傷，就是意氣之爭了，在專業論壇中常看到這種動氣的言論。
5. 過於專注技術而忽視專案成功的其他要素
專案成功有許多因素如預算，時程，組織，團隊，人力，技術能力，主管的承諾，等，任何一個因素無法達成就會造成專案的失敗，而有些技術人員常只專注於技術而不理會其他因素。許多技術人員喜歡專注於單一技術的研究及開發，而有時則過於理想化，無法接受因預算，時程及客戶等因素進行的調整，若是因此造成專案延遲或失敗，自然怪罪於其他因素所造成。
猶如Peter Senge "第五項修練"書中提到 "熟練的無能"，也就是過於本位主義往往造成團隊或企業的失敗。
6. 生涯規劃依賴於特定的技術如電腦語言或資訊產品
選擇工作時，只選擇使用特定技術的工作才肯做，現在常見的是有些人只找用Java語言的公司，這讓我想起過去老COBOL人的生涯危機，當企業慢慢將Mainframe汰換，進入個人電腦時代，C語言興起，進入網際網路時代，Java語言興起，而一些只會COBOL的前輩們，面臨後浪推前浪的危機，被取代的恐懼。
而生涯的成就也依賴於在特定技術上的成就，而其他人生的要素如家庭，健康，朋友與人際等一蹋糊塗也不在乎，於是生命中所擁有的東西只有這項技術，離開這些就一無所有。
7. 敝帚自珍的觀念，不願分享
發表文章，也是專業成長的方式，專業能力的成長，代表的是自己能看見從前看不見的現象，能做到從前做不到的事，或是能把所做的事做的更好！ 在專業領域中，自己可能會疏漏很多重要的訊息，也可能有許多 不自知的壞習慣，所以，與同事、或同業人士進行專業的討論，文章的分享非常重要。[2]
把自己的工作、研究心得發表出來，無論是在小小的論壇上、小型的期刊雜誌上，或是正式的期刊上發表文章。除了傳遞資訊，貢獻自己的經驗與知識之外，每一篇文章都會是一個成長的里程碑，留下自己的腳印，同時也可以獲得很多的回饋與鼓勵，更能激勵自己思考，帶動自己更進一步的發展。 [2]
但是害怕自己被取代，害怕暴露自己的不足而不願意與他人分享，將阻礙自己的成長。
8. 過度自卑後的過度膨脹的自尊，不願接受指導及管理
由於懂得不多，害怕不能得到他人的尊重，因此如蟾蜍面對敵人時盡量膨脹自己，以虛張聲勢，此種防衛的心態，造成不能接受他人的指導及管理，凡是只要別人配合自己，不肯配合他人，自己的決策一定要他人接受，而不在乎其他成員的看法，而如果出問題一定是別人的問題。
過度膨脹的自尊造成對他人與自己相關的工作與技術的言行，都相當敏感，因此造成多疑的心理狀態，不如我的意就以為是對我的不尊重，所有喜怒哀樂決定於別人對自己的讚美，感謝或批評。
過度膨脹的自尊當然看不到別人的優點，別人的努力與成就，更不屑於技術能力(自己擁有的技術)比自己差的主管。
9. 過於技術導向，缺乏人文的素養，人性化的考慮與人際溝通的能力
有些生活在技術的世界的人，唯有技術才是最實在的，最腳踏實地的，而人文素養對他而言則是不切實際的代表，因此所做的事即決定都是缺乏人性化的考慮，因此做出來的系統，則完全不考慮到使用者操作的便利性，更不用說美感了。
缺乏人際溝通的能力，也常出現在技術人員身上，習慣用技術的術語，與使用者或客戶溝通，自然造成溝通的障礙，若在組織內部則永遠希望別人找他溝通，而非主動找他人溝通。
10. 不能系統化的思考，只著眼於片段，單一角度或短暫期間的問題解決
只看有利於自己的解決方式，只從單一個角度解決問題，只看短暫的解決方案，這些都是缺乏從整體及群體巨觀的角度思考，最後並無法解決真正的問題，甚至讓問題更加惡化。 (有關系統思考可以參考Peter Senge的"第五項修練")
11. 不能有系統的整理自己內在的經驗
當我們遇到困難時，拿問題問別人是最常見的方法之一，有時會 想到翻書、查閱資料；有時，也會從討論會，或是別人演講中聽到一些很好的觀念，但這些方法，卻未必能促進我們的專業成長。[2]
其中，最大的問題在於，從這些方法中，我們所學到的東西，可能是支離破碎的知識片段，也可能是一些充滿相互衝突、矛盾的觀念，與我們自己原本所有的知識、觀念不相容，或不相關聯，而我們卻不自知。[2]
例如一位電腦工作者，工作前五年用C語言開發系統，後五年用Java開發系統，但如果不能找出Java與C的差異，找出前五年哪些開發的經驗可以用在後五年，則每次使用不同的語言都無法為將來的工作帶來任何的好處，也沒有增進多少程式設計的功力，如此只能說經驗的增加而不能說是專業的成長。
所有專業無法脫離人性，不妨偶而跳出專業從人性角度檢視自己，學習一些自己專業外的知識，例如第五項修練，與成功有約等心智成長的書籍，如專案管理，人際關係管理等管理書籍，如繪畫，建築，音樂，美術設計等人文素養的知識，拓展視野，將會發現自己的渺小，然後重新建立新的人生觀與成熟獨立的價值觀，如此才能邁向更圓滿的人生。
Reference :
1. http://www.ksml.edu.tw/cmenu/read/club/014/1405.html 大滅絕讀後感
2. http://www.tmtc.edu.tw/~kidcen/epaper/20000916.htm，本文原刊載於86.5.19,86.5.26國語日報
3. Peter Senge,"第五項修練"
Labels:
職涯智慧
2005年5月23日
UML各種圖示法的使用時機整理
UML有許多的圖示法可以使用, 我將這些圖示法的使用時機整理在一起, 作為專案使用時的參考:
Use Case Diagram
使用時機 : 在規劃階段根據使用者目標, 找出使用案例(User Case), 再畫出互動關係, 用來確認專案範圍及掌控專案。
Class Diagram
使用時機 : 專案的每個階段幾乎都用得到, 在分析階段, 分析從使用者角度看到的物件及其繼承關係, 在設計階段用來明確的定義實作階段要完成的介面(Interface)與類別(Class), 在實作階段則定義出屬性及方法(methods)作為系統文件。
Interaction Diagram - Sequence Diagram or
Interaction Diagram – Collaboration Diagram
使用時機 : 進入設計階段, 已經清楚定義Classes, 透過Interaction Diagram可以清楚的看出class間的互動關係。有時維護一套只有原始程式的系統可以透過檢視程式的過程畫出Interaction Diagram與Class Diagram來了解系統的全貌。
Package Diagram
使用時機 : 在設計階段當Class數量很多時, 可將Classes分類存於不同Package, 使用Package Diagram可以概觀的看出Packages間的關係。
State Diagram
使用時機 : 在設計階段, 單一物件有清楚的生命週期或狀態變化, 需要狀態圖才可將哪些事件造成哪些狀態的改變描述清楚。
Activity Diagram
使用時機 : 在分析階段用來分析一個使用案例(Use Case)內有哪些動作, 這些動作間的關係。(此時尚未定義物件Class, 還未將動作分配給Classes)。也可以提供設計與實作階段的重要參考。
Deployment Diagram
使用時機 : 用於分散式系統, 在架構設計階段用來表達可用元件(如EJB, WebServices)分散於不同的Application Servers的狀況。
最常用的四種Diagrams是Use Case Diagram, Class Diagram, Sequence Diagram 與Activity Diagram。
2005.5.20 Fred Wang
Use Case Diagram
使用時機 : 在規劃階段根據使用者目標, 找出使用案例(User Case), 再畫出互動關係, 用來確認專案範圍及掌控專案。
Class Diagram
使用時機 : 專案的每個階段幾乎都用得到, 在分析階段, 分析從使用者角度看到的物件及其繼承關係, 在設計階段用來明確的定義實作階段要完成的介面(Interface)與類別(Class), 在實作階段則定義出屬性及方法(methods)作為系統文件。
Interaction Diagram - Sequence Diagram or
Interaction Diagram – Collaboration Diagram
使用時機 : 進入設計階段, 已經清楚定義Classes, 透過Interaction Diagram可以清楚的看出class間的互動關係。有時維護一套只有原始程式的系統可以透過檢視程式的過程畫出Interaction Diagram與Class Diagram來了解系統的全貌。
Package Diagram
使用時機 : 在設計階段當Class數量很多時, 可將Classes分類存於不同Package, 使用Package Diagram可以概觀的看出Packages間的關係。
State Diagram
使用時機 : 在設計階段, 單一物件有清楚的生命週期或狀態變化, 需要狀態圖才可將哪些事件造成哪些狀態的改變描述清楚。
Activity Diagram
使用時機 : 在分析階段用來分析一個使用案例(Use Case)內有哪些動作, 這些動作間的關係。(此時尚未定義物件Class, 還未將動作分配給Classes)。也可以提供設計與實作階段的重要參考。
Deployment Diagram
使用時機 : 用於分散式系統, 在架構設計階段用來表達可用元件(如EJB, WebServices)分散於不同的Application Servers的狀況。
最常用的四種Diagrams是Use Case Diagram, Class Diagram, Sequence Diagram 與Activity Diagram。
2005.5.20 Fred Wang
訂閱：
文章 (Atom)