David Berlind原著‧陳奭璁譯 2003/02/06 (摘自Taiwan.CNET.com)
http://www.zdnet.com.tw/enterprise/technology/0,2000085680,20065321,00.htm
這篇文章非常好，如何解決因內部各種異質IT基礎設施與OS專用的老舊程式阻礙公司進步? 如何讓系統間相容，容易整合? 整理為下面四部份
1.每個平台商業邏輯都必需經過標準化，以便與其他平台作溝通, 例如採用Java當作商業邏輯層
2.選擇一個整合開發平台，一體適用在整個基礎設施上
3.加入一層界面來作統一的呈現，例如用Web為統一的呈現層。
4.選擇適用於各個部分的開放原始碼元件包括IDE、Web伺服器、J2EE伺服器等。
2005年12月27日
2005年12月23日
Java繼承結構中建構子的注意事項
本例中Panda及Koala新增一個物件, 其成員變數count會加一, 但是執行結果Bear的count也會計數, 為何會這樣?
原因 :
程式編譯時Java都會自動在所有類別的建構子(Constructor)的第一行加上super()來呼叫父類別的建構子
因此下面例子中不但Koala, Panda的count會計數, 連父類別Bear的count也會計數Koala為1, Panda為3, Bear為4
原因 :
程式編譯時Java都會自動在所有類別的建構子(Constructor)的第一行加上super()來呼叫父類別的建構子
因此下面例子中不但Koala, Panda的count會計數, 連父類別Bear的count也會計數Koala為1, Panda為3, Bear為4
2005年12月22日
Java多型在member variable與method的差異
一個物件的成員變數(member variable), 是存取自物件所宣告的Class
本例中物件b, 被宣告為Bear, 因此b.name的內容為Bear成員變數name的內容
但是呼叫此物件的方法(method), 則是執行自此物件實體的Class
本例中物件b,實體的Class為Koala, 因此b.name()將執行Koala的name()
2005年12月20日
SAP xCQM(xApp Cost and Quotation Management)簡介
From www.sap.com
多數製造業,Quotations(報價)是關鍵成功要素, 報價過高會失去新的生意,報價太低則影響到利潤, SAP xCQM可以控制報價產生的因素的可行性,如成本資訊, 可以管理報價並提升內外部成本的估算,可以讓報價更為準確, 透過xcqm可以整合成本估算及報價準備, 以加速議價的速度. 另外可以指定適當的資源, 用於最有希望的商機上面. 因此可以取得競爭優勢及穩定的客戶基礎. 創造企業更多的利潤.
xCQM是組合現有SAP系統功能的應用系統
Please see: SAP Cost and Quotation Management (SAP xCQM)
多數製造業,Quotations(報價)是關鍵成功要素, 報價過高會失去新的生意,報價太低則影響到利潤, SAP xCQM可以控制報價產生的因素的可行性,如成本資訊, 可以管理報價並提升內外部成本的估算,可以讓報價更為準確, 透過xcqm可以整合成本估算及報價準備, 以加速議價的速度. 另外可以指定適當的資源, 用於最有希望的商機上面. 因此可以取得競爭優勢及穩定的客戶基礎. 創造企業更多的利潤.
xCQM是組合現有SAP系統功能的應用系統
Please see: SAP Cost and Quotation Management (SAP xCQM)
2005年12月11日
[觀念筆記]多型的觀念與實用範例
多型的目的在於 "實作與介面分離" ,
一般多型是應用在繼承的關係裡面, 假設甲寫好一個 Base class 給大家拿來extends , 我們拿到這個 Base class 之後,會在新的 subclass 中去 override base class 的 method ,甲寫的 base class 基本上可以被視為是一種 interface (概念上的), 其他人寫的subclass 中的 method 則是實際 implementation 的部份 (你可以假設甲的 base class 中完全沒有任何 method 的 implementation )這樣一來, 外界只需要知道 甲的 base class 中定義的 method 有那些, 不必管是如何 implement
再舉個更實際的範例, Collection 這個概念, collection 在JDK 裡面其實是個 interface, 像是 vector ,stack 這些東西都是去 implement collection 這個interface .
當我們在寫程式的時候, 可以這樣寫 :
Vector c = new Vector();
另外可能會有一個 method (別人寫的) 它的格式是這樣的
public void test (Vector c) {
......
}
別人寫的這個 method 嘗試著要把我們宣告的 vector object 當作參數傳進去, 試著想想看, 如果當有一天我們要從 Vector 改用其他的資料結構如 stack, 會付出多大的 effort ?
除了修改我們自己的 code, 我們必須去修改所有把我們的 vector object當作參數的 method ~~~
這個時候多型就派的上用場了 :-) 如果別人程式是這樣寫的:
public void test(Collection c) {
......
}
直接把最高層的 interface / class 拿來當作參數, 那麼我們要從 vector 改成stack 只要做一件事情 :
Collection c = new Stack();
就是這麼簡單,
當別人的 method 接收到 c 這個 "reference variable", c 會去自動連結對應的subclass 及其 method (或是 implement 此 interface 的 class)
也就是說, 外界的人根本不必 care 我們實作的方式改變與否, 它們只要跟 base class (interface) 溝通即可~~
如此一來便達成 "實作與介面分離" 的目的囉 ~~
另外補充一下, 所謂的 interface 是可以拿來宣告 "reference variable" 的, 也就是像 Collection c ; 這樣做,但是後面要實際 new 一個 object instance 出來, interface 就做不到了, 它雖然也是class 的一種, 但是 interface 裡面根本沒有任何實作 ~~~
所以後面應該接 implement 此 interface 之 class 的 constructor (Vector, Stack 均 implement Collection interface)
Author : Silver
一般多型是應用在繼承的關係裡面, 假設甲寫好一個 Base class 給大家拿來extends , 我們拿到這個 Base class 之後,會在新的 subclass 中去 override base class 的 method ,甲寫的 base class 基本上可以被視為是一種 interface (概念上的), 其他人寫的subclass 中的 method 則是實際 implementation 的部份 (你可以假設甲的 base class 中完全沒有任何 method 的 implementation )這樣一來, 外界只需要知道 甲的 base class 中定義的 method 有那些, 不必管是如何 implement
再舉個更實際的範例, Collection 這個概念, collection 在JDK 裡面其實是個 interface, 像是 vector ,stack 這些東西都是去 implement collection 這個interface .
當我們在寫程式的時候, 可以這樣寫 :
Vector c = new Vector();
另外可能會有一個 method (別人寫的) 它的格式是這樣的
public void test (Vector c) {
......
}
別人寫的這個 method 嘗試著要把我們宣告的 vector object 當作參數傳進去, 試著想想看, 如果當有一天我們要從 Vector 改用其他的資料結構如 stack, 會付出多大的 effort ?
除了修改我們自己的 code, 我們必須去修改所有把我們的 vector object當作參數的 method ~~~
這個時候多型就派的上用場了 :-) 如果別人程式是這樣寫的:
public void test(Collection c) {
......
}
直接把最高層的 interface / class 拿來當作參數, 那麼我們要從 vector 改成stack 只要做一件事情 :
Collection c = new Stack();
就是這麼簡單,
當別人的 method 接收到 c 這個 "reference variable", c 會去自動連結對應的subclass 及其 method (或是 implement 此 interface 的 class)
也就是說, 外界的人根本不必 care 我們實作的方式改變與否, 它們只要跟 base class (interface) 溝通即可~~
如此一來便達成 "實作與介面分離" 的目的囉 ~~
另外補充一下, 所謂的 interface 是可以拿來宣告 "reference variable" 的, 也就是像 Collection c ; 這樣做,但是後面要實際 new 一個 object instance 出來, interface 就做不到了, 它雖然也是class 的一種, 但是 interface 裡面根本沒有任何實作 ~~~
所以後面應該接 implement 此 interface 之 class 的 constructor (Vector, Stack 均 implement Collection interface)
Author : Silver
[觀念筆記]Java 存取修飾子 protected 與 default的差別
作者 : Fred Wang 日期 :2005/12/11 修訂日期 : 2013/5/26
private methods 只能在同一個class存取
default methods(不加修飾子) 同個package內的class 都可以存取or繼承
下面範例顯示五種變數存取權，i1是private, i2是default, i3是protected, i4是public, i5是method中的local變數，同一個package中class Base中的i1無法被子class j0302中的method讀取，default, protected與public都可以
protected 具有 default 的權限, 不同之處在於, 如果"subclass"(如上例中的j0302)與主class(如上例中的Base)在不同的package中, default 就無法讓subclass存取了, protected與public才可以
假設甲寫好一個Base class, 放在 com.free.util 的package裡面,在此 class 中的變數與methods 有 default 與 protected 兩種
現在乙另一個名為com.free.app1的package中寫一個 class j0302 要繼承(extend)甲寫好的 Base class, 在此 subclass 中, 僅能去存取Base class中 protected形態的methods與變數, 對於 default形態的methods 與變數是無法使用的 !
所以結論是 : 當您撰寫一個 class, 希望有一些 methods與變數不要給所有人用(public才是給所有class都可以用), 僅給會繼承(extend) 此類別的 subclass 使用 (此 subclass 可能位於相同或不同的package中) 請將這些 methods 與變數設成 protected
private methods 只能在同一個class存取
default methods(不加修飾子) 同個package內的class 都可以存取or繼承
下面範例顯示五種變數存取權，i1是private, i2是default, i3是protected, i4是public, i5是method中的local變數，同一個package中class Base中的i1無法被子class j0302中的method讀取，default, protected與public都可以
protected 具有 default 的權限, 不同之處在於, 如果"subclass"(如上例中的j0302)與主class(如上例中的Base)在不同的package中, default 就無法讓subclass存取了, protected與public才可以
假設甲寫好一個Base class, 放在 com.free.util 的package裡面,在此 class 中的變數與methods 有 default 與 protected 兩種
現在乙另一個名為com.free.app1的package中寫一個 class j0302 要繼承(extend)甲寫好的 Base class, 在此 subclass 中, 僅能去存取Base class中 protected形態的methods與變數, 對於 default形態的methods 與變數是無法使用的 !
所以結論是 : 當您撰寫一個 class, 希望有一些 methods與變數不要給所有人用(public才是給所有class都可以用), 僅給會繼承(extend) 此類別的 subclass 使用 (此 subclass 可能位於相同或不同的package中) 請將這些 methods 與變數設成 protected
2005年11月29日
只有中小企業用OpenCMS嗎?
答案是錯的！
德國第二大銀行、歐洲第五大銀行 : HVB集團
德國的健康保險基金 : DRAGER & HANSE
世界上最大的進行石油和天然氣勘探、生産、提煉和銷售的公司之一 : British Petroleum（英國石油公司，簡稱BP）
義大利最大的能源公司 : AEM S.p.A
世界最大的冶金用煤生産商 : BHP Billiton Mitsubishi Alliance
德國最大的房地産公司之一 : AGIV
雷諾汽車
僅次於波音的世界第二大航空公司 : EADS
3M德國公司
世界最大的眼鏡鏡片生産商 : Essilor
世界著名的戶外運動用品生産商 : the North Face
義大利最大的糖業公司 : Zuccheri
...等 都用OpenCMS!
德國第二大銀行、歐洲第五大銀行 : HVB集團
德國的健康保險基金 : DRAGER & HANSE
世界上最大的進行石油和天然氣勘探、生産、提煉和銷售的公司之一 : British Petroleum（英國石油公司，簡稱BP）
義大利最大的能源公司 : AEM S.p.A
世界最大的冶金用煤生産商 : BHP Billiton Mitsubishi Alliance
德國最大的房地産公司之一 : AGIV
雷諾汽車
僅次於波音的世界第二大航空公司 : EADS
3M德國公司
世界最大的眼鏡鏡片生産商 : Essilor
世界著名的戶外運動用品生産商 : the North Face
義大利最大的糖業公司 : Zuccheri
...等 都用OpenCMS!
開源業務流程管理(BPM)
功能齊全的業務流程管理套件也許最先不是來自開源社群，不過這正是諸多專案在竭力使之實現的目標。隨著SOA的興起，人們對管理及編寫不同服務和Enterprise JavaBeans（EJB）的業務流程引擎的需求空前高漲，甚至對以其他方式依靠開源技術的網站來說也是如此。
這就是爲什麽Apache軟體基金會考慮採用Project Agila的原因。在該基金會的Jakarta Java工具套件當中，這個專案可以說是 “皇冠上的寶石”。Agila是Gluecode軟體公司在2004年10月捐獻的初始代碼開發而成的，這個輕便、可嵌入的開源業務流程管理引擎適合與 J2EE和較低階的平臺如J2ME一起使用。Apache的代表聲稱，正因爲如此，Agila是Apache Java中間件(Middleware)系列當中的最後一個重要部分，可以同BEA或者IBM等主要商業開發商提供的産品相媲美。目前這個專案還處於孵化階段，沒有授權文件，不過已經向公衆開放。但預計大規模的開發工作很快就會啓動。
Apache軟體基金會不是惟一遵循這條思路的組織。JBoss 也在期望把産品系列擴大到其核心應用伺服器以外的領域。JBoss近期購買了名爲jBPM的開源工作流引擎，把其豐富的Java開發經驗帶到了業務流程管理(BPM)市場上。
與Project Agila一樣，jBPM也可以作爲獨立的應用運行，或者作爲另一個應用裏面的嵌入式元件運行。與Apache專案不同的是，jBPM代碼已經可以從 JBoss的網站下載，採用該公司的制定的寬鬆通用公共許可證 （LGPL）。除了引擎本身外，jBPM還包括圖形化的流程設計器，用於建立工作流。該專案的未來計劃包括: 增加對業務流程執行語言（BPEL）的本地化支援; 就長遠而言，專案的目標是要擴展jBPM的功能，使其成爲一種成熟的企業服務匯流排（ESB）。
除了這兩個主角外，還有其他許多開源工作流引擎（有的正在擬議中），不過這些專案的發展狀況往往很難確定。不過，管理業務流程這項複雜工作需要專門技能。如果你在尋求這類軟體的開源方案，穩妥之計就是，選擇得到像Apache或者JBoss這些財力雄厚、專業的組織支援的專案。
(From : http://www.ccw.com.cn/cio/solution/htm2005/20051103_135RB.asp)
這就是爲什麽Apache軟體基金會考慮採用Project Agila的原因。在該基金會的Jakarta Java工具套件當中，這個專案可以說是 “皇冠上的寶石”。Agila是Gluecode軟體公司在2004年10月捐獻的初始代碼開發而成的，這個輕便、可嵌入的開源業務流程管理引擎適合與 J2EE和較低階的平臺如J2ME一起使用。Apache的代表聲稱，正因爲如此，Agila是Apache Java中間件(Middleware)系列當中的最後一個重要部分，可以同BEA或者IBM等主要商業開發商提供的産品相媲美。目前這個專案還處於孵化階段，沒有授權文件，不過已經向公衆開放。但預計大規模的開發工作很快就會啓動。
Apache軟體基金會不是惟一遵循這條思路的組織。JBoss 也在期望把産品系列擴大到其核心應用伺服器以外的領域。JBoss近期購買了名爲jBPM的開源工作流引擎，把其豐富的Java開發經驗帶到了業務流程管理(BPM)市場上。
與Project Agila一樣，jBPM也可以作爲獨立的應用運行，或者作爲另一個應用裏面的嵌入式元件運行。與Apache專案不同的是，jBPM代碼已經可以從 JBoss的網站下載，採用該公司的制定的寬鬆通用公共許可證 （LGPL）。除了引擎本身外，jBPM還包括圖形化的流程設計器，用於建立工作流。該專案的未來計劃包括: 增加對業務流程執行語言（BPEL）的本地化支援; 就長遠而言，專案的目標是要擴展jBPM的功能，使其成爲一種成熟的企業服務匯流排（ESB）。
除了這兩個主角外，還有其他許多開源工作流引擎（有的正在擬議中），不過這些專案的發展狀況往往很難確定。不過，管理業務流程這項複雜工作需要專門技能。如果你在尋求這類軟體的開源方案，穩妥之計就是，選擇得到像Apache或者JBoss這些財力雄厚、專業的組織支援的專案。
(From : http://www.ccw.com.cn/cio/solution/htm2005/20051103_135RB.asp)
OpenCMS與Struts結合是很容易的
From http://www.opencms-forum.de/viewtopic.php?t=684&sid=34de0ed0c1e9f5b624b218e38d8b0d7d
內容如下:
To use struts in unison with OpenCms is very simple.
Everything is the same EXCEPT!
* Your jsps are in OpenCms
* In your struts-config.xml, when your doing a forward include the OpenCms servlet and the full path to the file within the VFS. So all
your forwards to jsp's would begin with /OpenCms/directories-in-vfs/the-file-in-vfs.jsp. Remember that OpenCms is "JUST" a servlet. So your really doing a forward to the opencms servlet with parameters (sorta). The paramaters being the path to the file in the vfs.
Setup your web.xml with both the OpenCms servlet and the struts servlet. Put in all the tag libraries that you need from both. And
that's it, you'll have all the advantages of managing your pages in OpenCms and all the mvc capabilites of struts.
The struts-OpenCms sourceforge project was attempting to put actions, actionforms, and all the configs files and jars in the VFS. IMHO I
don't think that's a good idea.
The approach I mentioned, just puts the JSPs in the VFS so it requires NO code changes to OpenCms or Struts.
內容如下:
To use struts in unison with OpenCms is very simple.
Everything is the same EXCEPT!
* Your jsps are in OpenCms
* In your struts-config.xml, when your doing a forward include the OpenCms servlet and the full path to the file within the VFS. So all
your forwards to jsp's would begin with /OpenCms/directories-in-vfs/the-file-in-vfs.jsp. Remember that OpenCms is "JUST" a servlet. So your really doing a forward to the opencms servlet with parameters (sorta). The paramaters being the path to the file in the vfs.
Setup your web.xml with both the OpenCms servlet and the struts servlet. Put in all the tag libraries that you need from both. And
that's it, you'll have all the advantages of managing your pages in OpenCms and all the mvc capabilites of struts.
The struts-OpenCms sourceforge project was attempting to put actions, actionforms, and all the configs files and jars in the VFS. IMHO I
don't think that's a good idea.
The approach I mentioned, just puts the JSPs in the VFS so it requires NO code changes to OpenCms or Struts.
2005年11月28日
開源商業智慧(BI)
客戶和獨立軟體發展商在購買現有商業智慧（BI）軟體的許可證(License)時往往面臨高昂費用，這也就難怪在Open Source 社群內部BI方面的工作開展得如火如荼。首先是Eclipse基金會，它已把BI列爲自己的七個最高級別專案之一。該基金會已在6月發佈了1.0版本的商業智慧軟體和報表工具（BIRT），採用其自己的Eclipse許可證，該許可證得到了開源促進會（OSI）的批准。
BIRT的主要目的是將Java-based的Web應用充當報表系統。它包括兩個部分: 一個是JAR（Java Archive）文件，該文件包括可部署在應用伺服器上的運行時元件; 另一個就是報告設計器(Report Designer)，它可以作爲Eclipse插件(Plug-in)，提供了方便的所見即所得的編輯功能以及標準報表專案調色板。該工具包含名爲”開放資料訪問”的框架，這樣在選擇資料來源時具有很大的靈活性。
對需要專業支援、維護及培訓的人來說，Actuate公司爲BIRT技術提供了這些服務。此外，Actuate提供的自己版本的BIRT使用商業許可證，該許可證含有知識産權保障條款。
值得關注的另一家組織就是Pentaho，這家新興公司致力於開發全面的開源BI平臺，包括報表、分析、儀錶板、資料挖掘及工作流等工具。該公司的開發隊伍聲稱，隊伍成員以前在Cognos、Oracle和SAS 等公司從事過BI應用軟體的開發。這個專案的主要伺服器架構將搭建在J2EE上，與BIRT相似的地方是，客戶端環境將基於Eclipse平臺。開發人員已努力把先進技術整合到平臺裏面，譬如對所有內容統一使用XML定義; 對分析元件使用Web服務介面，確保最大的靈活性等。
Pentaho目前還沒有提供下載版本，不過該公司稱，它計劃在年底(2005)前交付所有專案的版本，採用寬通用公共許可證（LGPL）以及所謂的“類似LGPL”的許可證，其中包括Apache、BSD和Eclipse。公司網站上提供了詳細的Roadmap。
雖然Pentaho目前也許是個霧件（vaporware），但它具備了在BI市場成爲重要競爭者的所有必要條件。該專案的開發人員說: “我們沒指望用戶僅僅是因爲它是開放的就採用它。我們希望用戶選擇它，是因爲它更好。至於這個專案結果如何，幾個月後可見分曉。”
(From : http://www.ccw.com.cn/cio/solution/htm2005/20051103_135RB.asp)
BIRT的主要目的是將Java-based的Web應用充當報表系統。它包括兩個部分: 一個是JAR（Java Archive）文件，該文件包括可部署在應用伺服器上的運行時元件; 另一個就是報告設計器(Report Designer)，它可以作爲Eclipse插件(Plug-in)，提供了方便的所見即所得的編輯功能以及標準報表專案調色板。該工具包含名爲”開放資料訪問”的框架，這樣在選擇資料來源時具有很大的靈活性。
對需要專業支援、維護及培訓的人來說，Actuate公司爲BIRT技術提供了這些服務。此外，Actuate提供的自己版本的BIRT使用商業許可證，該許可證含有知識産權保障條款。
值得關注的另一家組織就是Pentaho，這家新興公司致力於開發全面的開源BI平臺，包括報表、分析、儀錶板、資料挖掘及工作流等工具。該公司的開發隊伍聲稱，隊伍成員以前在Cognos、Oracle和SAS 等公司從事過BI應用軟體的開發。這個專案的主要伺服器架構將搭建在J2EE上，與BIRT相似的地方是，客戶端環境將基於Eclipse平臺。開發人員已努力把先進技術整合到平臺裏面，譬如對所有內容統一使用XML定義; 對分析元件使用Web服務介面，確保最大的靈活性等。
Pentaho目前還沒有提供下載版本，不過該公司稱，它計劃在年底(2005)前交付所有專案的版本，採用寬通用公共許可證（LGPL）以及所謂的“類似LGPL”的許可證，其中包括Apache、BSD和Eclipse。公司網站上提供了詳細的Roadmap。
雖然Pentaho目前也許是個霧件（vaporware），但它具備了在BI市場成爲重要競爭者的所有必要條件。該專案的開發人員說: “我們沒指望用戶僅僅是因爲它是開放的就採用它。我們希望用戶選擇它，是因爲它更好。至於這個專案結果如何，幾個月後可見分曉。”
(From : http://www.ccw.com.cn/cio/solution/htm2005/20051103_135RB.asp)
2005年11月24日
[超基本] Java Static and non-Static
重點: Class 未被初始化(New instance)以前靜態方法(static method)只能存取靜態變數(static variable) 與區域變數 local variable
如下面範例 c2,c3,c4,c5無法被static method - main所存取
public class j0227 extends Object {
static int c1=5; // 靜態變數
public int c2=6;
private int c3=7;
final int c4=8;
int c5=0;
public static void main(String args[]) {
int c6=4; // 區域變數
System.out.println(c1);
System.out.println(c2);
System.out.println(c3);
System.out.println(c4);
System.out.println(c5);
System.out.println(c6);
}
}
/*
產生compile error如下:
E:\JavaExercise\Fred>javac -d . j0227.java
j0227.java:10: non-static variable c2 cannot be referenced from a static context
System.out.println(c2);
^
j0227.java:11: non-static variable c3 cannot be referenced from a static context
System.out.println(c3);
^
j0227.java:12: non-static variable c4 cannot be referenced from a static context
System.out.println(c4);
^
j0227.java:13: non-static variable c5 cannot be referenced from a static context
System.out.println(c5);
*/
結果靜態方法main()只能讀取靜態變數C1與區域變數C6。
同樣，Class 未被初始化(New instance)以前靜態方法static method(如main)不能直接呼叫非靜態方法non-static method。
public class TypeConversion {
public static void main(String[] args){ // 靜態方法 main()
int a = 10;
long b = testConvert(a); // 因為class TypeConversion 尚未初始化,因此會產生錯誤
System.out.println(b);
}
long testConvert(long a) { // 非靜態方法
return a;
}
}
靜態方法main()無法直接呼叫非靜態方法testConvert()，會產生錯誤。
只要改成這樣就可以了
(1)
public class TypeConversion {
public static void main(String[] args){ // 靜態方法 main()
int a = 10;
TypeConversion1 t = new TypeConversion(); // 加上這行用來產生初始化物件
long b = t.testConvert(a); // 呼叫此物件的方法
System.out.println(b);
}
long testConvert(long a) { // 非靜態方法
return a;
}
}
為該非靜態方法所在的class建立初始化物件，再用該物件呼叫該非靜態方法。
或
(2)
public class TypeConversion {
public static void main(String[] args){
int a = 10;
Conversion c = new Conversion(); // 建立另一個class "Conversion"的初始化物件
long b = c.testConvert(a); // 呼叫這個物件的方法
System.out.println(b);
}
}
class Conversion { // 將該非靜態方法放在另一個class
long testConvert(long a) {
return a;
}
}
[超基本] Java Timer程式範例
分成三部分TimerService class程式, 被TimerService 定時驅動執行的程式, 啟動,停止或設定Timer Service的JSP程式
程式一 TimerService class程式
import java.util.Calendar;
import java.util.Date;
import java.util.Timer;
public class TimerService {
Timer timer = new Timer();
public TimerService() { };
public void start() throws Exception {
Calendar date = Calendar.getInstance();
date.setTime(new Date());
date.add(Calendar.DAY_OF_MONTH,1); // 驅動此程式的後一天
date.set(Calendar.AM_PM,Calendar.AM); // 上午
date.set(Calendar.HOUR,11); // 11點
date.set(Calendar.MINUTE,0); // 0分
date.set(Calendar.SECOND,0); // 0秒
date.set(Calendar.MILLISECOND,0); // 0毫秒
// timer.schedule(param1,param2,param3)
// param1: 就是要定時驅動執行的程式
// param2: 設定開始執行的時間,如上面的Calendar設定
// param3: 執行間隔時間(單位: 毫秒)
timer.schedule(
new DailyRun(),
date.getTime(),
1000 * 60 * 60 * 24
);
} // end of method
public void stop() throws Exception {
timer.cancel();
} // end of method
} // end of class
程式二 被TimerService 定時驅動執行的程式
public class DailyRun extends TimerTask {
public DailyRun() {
}
public void run() {
// 這裡是要執行的程式內容
} // End of method
} // end of class
另外要寫一支JSP來啟動與關閉Timer Service, 或者可以將執行時間與間隔透過JSP進行設定
相關文章: 使用標準的Java Timer API執行Scheduled Job
程式一 TimerService class程式
import java.util.Calendar;
import java.util.Date;
import java.util.Timer;
public class TimerService {
Timer timer = new Timer();
public TimerService() { };
public void start() throws Exception {
Calendar date = Calendar.getInstance();
date.setTime(new Date());
date.add(Calendar.DAY_OF_MONTH,1); // 驅動此程式的後一天
date.set(Calendar.AM_PM,Calendar.AM); // 上午
date.set(Calendar.HOUR,11); // 11點
date.set(Calendar.MINUTE,0); // 0分
date.set(Calendar.SECOND,0); // 0秒
date.set(Calendar.MILLISECOND,0); // 0毫秒
// timer.schedule(param1,param2,param3)
// param1: 就是要定時驅動執行的程式
// param2: 設定開始執行的時間,如上面的Calendar設定
// param3: 執行間隔時間(單位: 毫秒)
timer.schedule(
new DailyRun(),
date.getTime(),
1000 * 60 * 60 * 24
);
} // end of method
public void stop() throws Exception {
timer.cancel();
} // end of method
} // end of class
程式二 被TimerService 定時驅動執行的程式
public class DailyRun extends TimerTask {
public DailyRun() {
}
public void run() {
// 這裡是要執行的程式內容
} // End of method
} // end of class
另外要寫一支JSP來啟動與關閉Timer Service, 或者可以將執行時間與間隔透過JSP進行設定
相關文章: 使用標準的Java Timer API執行Scheduled Job
2005年11月23日
[超基本] Java Exception訊息的傳遞
作者 : Fred Wang 日期 :2005/11/23
在Multi-pier的J2EE程式設計,往往層次過多, 而難於除錯,通常會用Exception來將訊息傳到顯示端,來判斷錯誤點, 下面範例為Exception訊息如何由被呼叫的最下層method傳到主程式
範例如下 :
public class j1123 extends Object {
public static void main(String args[]) {
try {
aaa();
} catch (Exception e) {
System.out.println("Exception:"+e.toString());
}
} // end of method
// 由於bbb()會丟出exception,則aaa()必須宣告throws Exception且必須有try{ }段
// 否則會有編譯錯誤的訊息
private static void aaa() throws Exception{
try {
bbb();
// 這裡如果不要對Excption訊息加工則不須加catch
// catch (Exception e) throw e; 是不需要的!
} finally {
}
} // end of method
private static void bbb() throws Exception{
// 在程式中利用throw來產生Exception message
throw new Exception("bbb() exception!");
} // end of method
} // end of class
在Multi-pier的J2EE程式設計,往往層次過多, 而難於除錯,通常會用Exception來將訊息傳到顯示端,來判斷錯誤點, 下面範例為Exception訊息如何由被呼叫的最下層method傳到主程式
範例如下 :
public class j1123 extends Object {
public static void main(String args[]) {
try {
aaa();
} catch (Exception e) {
System.out.println("Exception:"+e.toString());
}
} // end of method
// 由於bbb()會丟出exception,則aaa()必須宣告throws Exception且必須有try{ }段
// 否則會有編譯錯誤的訊息
private static void aaa() throws Exception{
try {
bbb();
// 這裡如果不要對Excption訊息加工則不須加catch
// catch (Exception e) throw e; 是不需要的!
} finally {
}
} // end of method
private static void bbb() throws Exception{
// 在程式中利用throw來產生Exception message
throw new Exception("bbb() exception!");
} // end of method
} // end of class
2005年11月21日
SAP Business One Implementation Methodology
聽過SAP Business One的產品介紹,這個產品功能對中小型企業而言相當好, 操作及設定也十分方便
下面是SAP Bueinese One專案計畫步驟:
Project plan template :
1 Implementation Hand off from Pre sales
a. Collect as much information from the Pre-sales stage:
* Get First Meeting - Conversational Role Questions from Pre-sales.
* Get Evaluation Plan from Pre-Sales
* Get Organizational Impact Map from Pre-Sales
* Get Functional Requirements Assessment from Pre-Sales
* Get the Pre-Sales Representative to present the PROOF PRESENTATION to you. Ideally, join the Pre-Sales Representative at the customer site at that stage.
b. Identify unconventional business processes
c. Identify proposed solutions
d. Identify activity amount and data conversion amount if possible
2 Kick off Meeting with Customer
a. Present implementation methodology
b. Review Resources Available
c. Create Skills Matrix to Leverage Team Members Experience
3 Scope Analysis
a. Clarify and elaborate on All Business Processes defined in the pre-sales phase
b. Get customers business process needs in details. Divide into subjects:
* Sales Process
* Purchasing Process
* Inventory management
* Production process
* Financials and Chart of Accounts
* Sales Opportunities
* Service
* Banking
* SAP Business One hardware requirements vs. existing hardware (Allow time for any upgrades to hardware)
* Review Data conversion needs - type and amount of Data
* Establish any required integration points for third party
* Determine Backup and restore Strategy
c. Review Critical Success Factors in each section
d. Identify any limitations in the out-of-box solution and discuss work around
e. Document all major business process
f. Create a list of limitations or opportunities of the design
g. Review results of limitations and suggest improvements to current B.P.
h. Work Around possibilities - UDF's/Formatted Search/Queries/SDK
i. Establish the post production review parameters. (See Going Live Check List)
j. Create Project Plan and assign Tasks
k. Once all steps in the Scope Analysis phase have been completed, send to the client for sign off
4 Create and Agree on Monitoring Methods
a. Who on the team is responsible for tasks
b. What are the agreed upon benchmarks to judge the projects success
c. Determine how often will you check on the progress
d. Prepare periodic progress reports
5 Install and configure server and client machines
a. Install SAP Business One on Server per Install Guide
b. Install SAP Business One on Client Machines per Install Guide
c. Request & Install License from Service Market Place
d. Create databases for SAP Business One
6 Configure System set up
a. Complete System Initialization in SAP Business One
b. Complete Definitions in SAP Business One
7 Data Conversion
a. Establish data migration methodology based on import capabilities of each module and export capabilities of current system and prepare import data files
b. Deliver relevant template to customer, including user fields needed to be imported
c. Review Conversion Strategy doc - (See Section 4)
d. Refer to open balances document for specific information related to converting data (See Section 5)
e. Determine a timeline for data conversion based on the technical survey
f. Receive raw data for manipulation
g. Allow client to test the validity of their data once it has been converted
h. Obtain client sign off for imported data
8 Business Process Requirements - Execution Phase:
a. Create DB Backup after every major step has been completed
b. Create users and authorizations
c. Create User Defined Fields
d. Print out Templates
e. Define Numbering Series for Documents
f. Create queries as defined
g. Create formatted searches as defined
h. Create Reports as defined
i. Create Alerts as defined
j. Define Approval Procedures in Administration module
k. Configure Sales A/R
l. Configure Purchasing A/P
m. Configure Inventory
-1. Define Alternative Items
-2. Define Catalog Numbers
-3. Define Serial Numbers
-4. Define Batches
-5. Define Price Lists information that was not imported
n. Configure Production
o. Configure Service
p. Configure HR
q. Configure Sales Opportunities
r. Configure Financials
-1. Budgets
-2. Cost Accounting
s. Configure Banking
t. Configure Reports
u. Review users authorizations and adjust as necessary
v. Create customizations specific to users
-1. Screen Layouts
-2. Queries
-3. Reports templates - design and printing
w. Configure Service Manager per documentation in the installation package
9 User Acceptance Testing
a. Perform any necessary upgrade if a new patch was released.
b. Review the results and decide if ready for production
c. Simulate all major business processes defined above
d. Simulate major business processes with super user from the client side
e. Compare the data to established reports
f. Review results and have client sign off
10 Pre Go-Live Phase
a. Review go-live check list
b. Create or import Opening Balances
c. Create custom user manuals
(From www.sap.com)
下面是SAP Bueinese One專案計畫步驟:
Project plan template :
1 Implementation Hand off from Pre sales
a. Collect as much information from the Pre-sales stage:
* Get First Meeting - Conversational Role Questions from Pre-sales.
* Get Evaluation Plan from Pre-Sales
* Get Organizational Impact Map from Pre-Sales
* Get Functional Requirements Assessment from Pre-Sales
* Get the Pre-Sales Representative to present the PROOF PRESENTATION to you. Ideally, join the Pre-Sales Representative at the customer site at that stage.
b. Identify unconventional business processes
c. Identify proposed solutions
d. Identify activity amount and data conversion amount if possible
2 Kick off Meeting with Customer
a. Present implementation methodology
b. Review Resources Available
c. Create Skills Matrix to Leverage Team Members Experience
3 Scope Analysis
a. Clarify and elaborate on All Business Processes defined in the pre-sales phase
b. Get customers business process needs in details. Divide into subjects:
* Sales Process
* Purchasing Process
* Inventory management
* Production process
* Financials and Chart of Accounts
* Sales Opportunities
* Service
* Banking
* SAP Business One hardware requirements vs. existing hardware (Allow time for any upgrades to hardware)
* Review Data conversion needs - type and amount of Data
* Establish any required integration points for third party
* Determine Backup and restore Strategy
c. Review Critical Success Factors in each section
d. Identify any limitations in the out-of-box solution and discuss work around
e. Document all major business process
f. Create a list of limitations or opportunities of the design
g. Review results of limitations and suggest improvements to current B.P.
h. Work Around possibilities - UDF's/Formatted Search/Queries/SDK
i. Establish the post production review parameters. (See Going Live Check List)
j. Create Project Plan and assign Tasks
k. Once all steps in the Scope Analysis phase have been completed, send to the client for sign off
4 Create and Agree on Monitoring Methods
a. Who on the team is responsible for tasks
b. What are the agreed upon benchmarks to judge the projects success
c. Determine how often will you check on the progress
d. Prepare periodic progress reports
5 Install and configure server and client machines
a. Install SAP Business One on Server per Install Guide
b. Install SAP Business One on Client Machines per Install Guide
c. Request & Install License from Service Market Place
d. Create databases for SAP Business One
6 Configure System set up
a. Complete System Initialization in SAP Business One
b. Complete Definitions in SAP Business One
7 Data Conversion
a. Establish data migration methodology based on import capabilities of each module and export capabilities of current system and prepare import data files
b. Deliver relevant template to customer, including user fields needed to be imported
c. Review Conversion Strategy doc - (See Section 4)
d. Refer to open balances document for specific information related to converting data (See Section 5)
e. Determine a timeline for data conversion based on the technical survey
f. Receive raw data for manipulation
g. Allow client to test the validity of their data once it has been converted
h. Obtain client sign off for imported data
8 Business Process Requirements - Execution Phase:
a. Create DB Backup after every major step has been completed
b. Create users and authorizations
c. Create User Defined Fields
d. Print out Templates
e. Define Numbering Series for Documents
f. Create queries as defined
g. Create formatted searches as defined
h. Create Reports as defined
i. Create Alerts as defined
j. Define Approval Procedures in Administration module
k. Configure Sales A/R
l. Configure Purchasing A/P
m. Configure Inventory
-1. Define Alternative Items
-2. Define Catalog Numbers
-3. Define Serial Numbers
-4. Define Batches
-5. Define Price Lists information that was not imported
n. Configure Production
o. Configure Service
p. Configure HR
q. Configure Sales Opportunities
r. Configure Financials
-1. Budgets
-2. Cost Accounting
s. Configure Banking
t. Configure Reports
u. Review users authorizations and adjust as necessary
v. Create customizations specific to users
-1. Screen Layouts
-2. Queries
-3. Reports templates - design and printing
w. Configure Service Manager per documentation in the installation package
9 User Acceptance Testing
a. Perform any necessary upgrade if a new patch was released.
b. Review the results and decide if ready for production
c. Simulate all major business processes defined above
d. Simulate major business processes with super user from the client side
e. Compare the data to established reports
f. Review results and have client sign off
10 Pre Go-Live Phase
a. Review go-live check list
b. Create or import Opening Balances
c. Create custom user manuals
(From www.sap.com)
導入服務導向架構 SOA 的策略
導入服務導向架構必須有整體的規劃，確實執行每個步驟，方能克服障礙，確保成功，下列是為一些寶貴的經驗法則，對導入 SOA 有相當大的助益。
1.制定統一的 Data Schema(Canonical Schema)：例如原來的 Customer 資料在 ERP 與 CRM 系統有不同的格式，在 SOA 中必須有統一的 Schema。
2.延伸 Legacy System：使用 Web services 把 Legacy System 包裝起來提供開放的服務，是一種不錯的選擇。
3.建立管理服務的機制：包括佈署、監控、量測、Routing 等等。
4.彙集服務 (Orchestrate services)：如果彙集一些互動服務可以具有商務意義，則可提供彙集服務給客戶使用，通常對應 User Task 且具有 Business Transaction 特性。
5.使用可靠的訊息傳輸機制：例如使用 Message Queue 比使用 TCP/IP 的 Socket 較穩定。
6.按 Internet/Intranet 的不同，採用適當的身份識別系統與安全機制。
7.採用 Services Interface、Services Facade、Services Implementation 三層架構，提高 Services 的彈性。
From : 如何導入服務導向架構 SOA
1.制定統一的 Data Schema(Canonical Schema)：例如原來的 Customer 資料在 ERP 與 CRM 系統有不同的格式，在 SOA 中必須有統一的 Schema。
2.延伸 Legacy System：使用 Web services 把 Legacy System 包裝起來提供開放的服務，是一種不錯的選擇。
3.建立管理服務的機制：包括佈署、監控、量測、Routing 等等。
4.彙集服務 (Orchestrate services)：如果彙集一些互動服務可以具有商務意義，則可提供彙集服務給客戶使用，通常對應 User Task 且具有 Business Transaction 特性。
5.使用可靠的訊息傳輸機制：例如使用 Message Queue 比使用 TCP/IP 的 Socket 較穩定。
6.按 Internet/Intranet 的不同，採用適當的身份識別系統與安全機制。
7.採用 Services Interface、Services Facade、Services Implementation 三層架構，提高 Services 的彈性。
From : 如何導入服務導向架構 SOA
2005年11月17日
做一個比你可以成就的還要大的夢想
史考特，在新書《牛奶如何變成牛》中，道出他自身的成功致富之道，為讀者解讀了決定成敗的關鍵就在「瞄準月亮」。
瞄準月亮要從願景規劃地圖的初期開始，它不像定義及設定可達到的夢想及目標一樣，你設立了一些看起來無法由你單獨一人完成的夢想。不管這個夢想是否可以達到，但是它反映了你在當時想要成就的任何結果。
使用傳統的目標設定方法來設立可以完成的目標會大大地改善你的工作表現，它可以在短時間之內加倍你的收入，它可以改進你的婚姻關係與友誼。但是如果你採用瞄準月亮的方法，做一個比你可以成就的還要大的夢想，將會有更大的改變與改善。不只是改善你的關係，你可以針對關係重新注入生命。除了雙倍增加你的收入，你可以到達一個自己從未想像過的境界。
瞄準月亮策略共有以下五個步驟：
1.做出決定在特定的夢想、目標、計劃上瞄準月亮。
2.列出可能阻止你在特定的夢想、目標，或計劃上面瞄準月亮的阻礙。
3.確認你需要哪些類型的夥伴或外界資源，幫助你克服所列出的阻礙。
4.確認你將嘗試運用的特定人選或資源。
5.確實地運用這些夥伴或資源，開始你在願景地圖中所定義的步驟與工作。
把瞄準月亮變成一個習慣及生活方式，你也可以成為卓越成就者。（本文摘錄自高寶書版公司出版的《牛奶如何變成牛》）
瞄準月亮要從願景規劃地圖的初期開始，它不像定義及設定可達到的夢想及目標一樣，你設立了一些看起來無法由你單獨一人完成的夢想。不管這個夢想是否可以達到，但是它反映了你在當時想要成就的任何結果。
使用傳統的目標設定方法來設立可以完成的目標會大大地改善你的工作表現，它可以在短時間之內加倍你的收入，它可以改進你的婚姻關係與友誼。但是如果你採用瞄準月亮的方法，做一個比你可以成就的還要大的夢想，將會有更大的改變與改善。不只是改善你的關係，你可以針對關係重新注入生命。除了雙倍增加你的收入，你可以到達一個自己從未想像過的境界。
瞄準月亮策略共有以下五個步驟：
1.做出決定在特定的夢想、目標、計劃上瞄準月亮。
2.列出可能阻止你在特定的夢想、目標，或計劃上面瞄準月亮的阻礙。
3.確認你需要哪些類型的夥伴或外界資源，幫助你克服所列出的阻礙。
4.確認你將嘗試運用的特定人選或資源。
5.確實地運用這些夥伴或資源，開始你在願景地圖中所定義的步驟與工作。
把瞄準月亮變成一個習慣及生活方式，你也可以成為卓越成就者。（本文摘錄自高寶書版公司出版的《牛奶如何變成牛》）
2005年11月16日
讓網站管理員最頭痛的七件事
1. 上層主管不了解, 忽略網站的重要
2. IT部門過於重視技術考慮,而非實際使用者或內容的需求
3. 行銷部門喜歡大量的圖形及花俏的動畫
4. 管理者堅持特有的喜好及特色
5. 責任多而權力少
6. 內容貧乏或者過於氾濫
7. 太少的預算及人力
更多...
2. IT部門過於重視技術考慮,而非實際使用者或內容的需求
3. 行銷部門喜歡大量的圖形及花俏的動畫
4. 管理者堅持特有的喜好及特色
5. 責任多而權力少
6. 內容貧乏或者過於氾濫
7. 太少的預算及人力
更多...
2005年11月15日
OpenCMS摘要
from www.opencms.org
•OpenCms是一個網站內容管理系統
•於2000年三月第一次公開發行
•Version 5.0 (stable) released May 2003
•Version 6.0 (alpha) released September 2004
•OpenCms is true Open Source Software
•OpenCms is available under the LGPL license
•No licensing costs
•OpenCms可在下面網站免費下載 http://www.opencms.org
•特別適合用來建立公司網站及內部網站
•適用於中大型企業現有的IT基礎環境
•多數功能是根據現實世界客戶的需求開發出來的
•高度彈性及客製化
•百分之百由Java寫成
•使用許多open source Java community經過驗證的元件
•由Alkacon Software領導開發
•有活躍的開發社群 –1000+ mailing list subscribers
•廣泛的商業支援
–More then 50 official “Solution Providers”
–200+ web companies offer support
•大量的文件可供參考
–第一本OpenCms的書已經發行 (written/edited by community members)
–Interactive documentation / examples
軟硬體規格 :
•Soft & Hardware requirements
–Software:Open Source to „High End“
•e.g. Linux + Tomcat + MySQL
•e.g. Win NT + IIS + Tomcat + MS SQL
•e.g. Solaris + BEA + Oracle
–Hardware:High flexibility
•Runs on a notebook computer
•Standard configuration: Normal Intel PC, 2Ghz CPU, 1 GB Ram
•Other: SUN Sparc, cluster configuration possible
•Installation is wizard based for default components (e.g. Tomcat, MySQL/ Oracle), takes just 5 minutes
•OpenCms是一個網站內容管理系統
•於2000年三月第一次公開發行
•Version 5.0 (stable) released May 2003
•Version 6.0 (alpha) released September 2004
•OpenCms is true Open Source Software
•OpenCms is available under the LGPL license
•No licensing costs
•OpenCms可在下面網站免費下載 http://www.opencms.org
•特別適合用來建立公司網站及內部網站
•適用於中大型企業現有的IT基礎環境
•多數功能是根據現實世界客戶的需求開發出來的
•高度彈性及客製化
•百分之百由Java寫成
•使用許多open source Java community經過驗證的元件
•由Alkacon Software領導開發
•有活躍的開發社群 –1000+ mailing list subscribers
•廣泛的商業支援
–More then 50 official “Solution Providers”
–200+ web companies offer support
•大量的文件可供參考
–第一本OpenCms的書已經發行 (written/edited by community members)
–Interactive documentation / examples
軟硬體規格 :
•Soft & Hardware requirements
–Software:Open Source to „High End“
•e.g. Linux + Tomcat + MySQL
•e.g. Win NT + IIS + Tomcat + MS SQL
•e.g. Solaris + BEA + Oracle
–Hardware:High flexibility
•Runs on a notebook computer
•Standard configuration: Normal Intel PC, 2Ghz CPU, 1 GB Ram
•Other: SUN Sparc, cluster configuration possible
•Installation is wizard based for default components (e.g. Tomcat, MySQL/ Oracle), takes just 5 minutes
2005年10月25日
在IT技術領域工作十年以上,您仍保有對技術的熱情嗎?
下面這篇文章是在國外論壇熱烈討論, 在IT技術領域工作十年以上的朋友, 您的如何保有對技術的熱情?
-------------------------------------------------------
Subject : lost my passion for this field
I entered the IT field in the mid 90s when there were plenty of high paying jobs and job security to go around. I finished my BS degree in computers and found myself in jobs where I do everything from programming to networking to databases.
After nearly 10 years in the field, I'm burnt out. A successfuly IT pro has to constantly learn new stuff that has a limited shelf life. If you learn to be a bricklayer, that information is good for life. Your knowledge doesn't become obsolete after a few years. But in this field, ya gotta be CONSTANTLY learning boring (IMO) technical details in order to remain competitive.
Quite frankly, I think I lost my passion for the field. Outside of work, I never read computer books/magazines/websites just for fun anymore. I'm more interested in reading about stuff like business and psychology.
I bought some Cisco certification books a couple years ago and still can't seem to bring myself to go through the certification process. I keep putting it off and putting it off. I started a few times but couldn't stay motivated. It seems like a drawn out, boring, time consuming chore to learn a bunch of information that will eventually be obsolete.
I like working with computers but they're a means to an end. I now see them as a tool to help businesses, nothing more. I don't about the different types of graphics cards or the "next version of Red Hat" or object oriented programming (yuck). I'm more concerned about using computers as a tool to help the company save/make profits.
Definitely thinking about a career change while I'm still young enough to do it. Can anyone else relate?
from : http://ct.techrepublic.com.com/clicks?c=599671-72143263&brand=techrepublic&ds=5&fs=0
------------------------------------------------------------------------------------
這篇文章也Post到程式設計師俱樂部
我的感想是 :
感謝大家熱情回應, 在論壇中的"真情"有時比現實生活中人與人的相處更為真實而不虛偽.
一般而言, 讓一個人成為某方面技術的好手又能持續精進而成為專家(From Good to Great), 應該具備三種驅動力 :
經濟驅動力 : 這個技術在經濟上能支持您的生活, 如果生活難以為繼, 則很難持續
核心能力 : 具備這方面的能力或特長, 例如邏輯思考能力不足, 可能無法達到更好的境界
興趣 : 對這方面技術有高度興趣, 這也就是本討論中的熱情
我想在這個領域十幾年前面兩個應該都沒有問題, 但是第三個興趣或熱情的部分, 可能如首文所說的burnt out
也許有人認為熱情這件事是十幾或二十多歲的人才有的, 年近四十的人談的是家庭, 事業, 財務等, 這就是思想漸趨成熟或稱"世故", 但是當您金錢無虞, 也沒有能力的問題, 在人生未來的日子, 您還會選擇怎樣的工作, 還是IT技術嗎? 若是則表示您的熱情尚未消退, 低潮是難免的, 而能夠重新站起而保持熱情的 (賺錢的因素除外)有哪些呢?
我想到的有 :
a. IT技術不斷推陳出新, 喜歡接受挑戰
b. 學習新的東西, 這對自己來說是很有趣的
c. 成為專家的感覺很好, 因為爬上高山頂端的成就感帶來的快樂
d. 喜歡將學來的東西分享給他人, 分享是件快樂的事
e. 對特定IT技術例如程式語言有高度的興趣, 而與年輕同事談起當年的COBOL, RPGII, FORTRAN回憶年青的時光也很快樂
您還能想到哪些呢?
當然, 也許想想真正失去這些熱情了, 因為賺錢, 工作壓力, 家庭壓力, 壓得透不過氣了, 哪還有心情談熱情, 這時我會帶著妻小, 到山上或海邊, 忘掉這些東西, 或與好友聊天暢飲, 享受人生其他的快樂.
-------------------------------------------------------
Subject : lost my passion for this field
I entered the IT field in the mid 90s when there were plenty of high paying jobs and job security to go around. I finished my BS degree in computers and found myself in jobs where I do everything from programming to networking to databases.
After nearly 10 years in the field, I'm burnt out. A successfuly IT pro has to constantly learn new stuff that has a limited shelf life. If you learn to be a bricklayer, that information is good for life. Your knowledge doesn't become obsolete after a few years. But in this field, ya gotta be CONSTANTLY learning boring (IMO) technical details in order to remain competitive.
Quite frankly, I think I lost my passion for the field. Outside of work, I never read computer books/magazines/websites just for fun anymore. I'm more interested in reading about stuff like business and psychology.
I bought some Cisco certification books a couple years ago and still can't seem to bring myself to go through the certification process. I keep putting it off and putting it off. I started a few times but couldn't stay motivated. It seems like a drawn out, boring, time consuming chore to learn a bunch of information that will eventually be obsolete.
I like working with computers but they're a means to an end. I now see them as a tool to help businesses, nothing more. I don't about the different types of graphics cards or the "next version of Red Hat" or object oriented programming (yuck). I'm more concerned about using computers as a tool to help the company save/make profits.
Definitely thinking about a career change while I'm still young enough to do it. Can anyone else relate?
from : http://ct.techrepublic.com.com/clicks?c=599671-72143263&brand=techrepublic&ds=5&fs=0
------------------------------------------------------------------------------------
這篇文章也Post到程式設計師俱樂部
我的感想是 :
感謝大家熱情回應, 在論壇中的"真情"有時比現實生活中人與人的相處更為真實而不虛偽.
一般而言, 讓一個人成為某方面技術的好手又能持續精進而成為專家(From Good to Great), 應該具備三種驅動力 :
經濟驅動力 : 這個技術在經濟上能支持您的生活, 如果生活難以為繼, 則很難持續
核心能力 : 具備這方面的能力或特長, 例如邏輯思考能力不足, 可能無法達到更好的境界
興趣 : 對這方面技術有高度興趣, 這也就是本討論中的熱情
我想在這個領域十幾年前面兩個應該都沒有問題, 但是第三個興趣或熱情的部分, 可能如首文所說的burnt out
也許有人認為熱情這件事是十幾或二十多歲的人才有的, 年近四十的人談的是家庭, 事業, 財務等, 這就是思想漸趨成熟或稱"世故", 但是當您金錢無虞, 也沒有能力的問題, 在人生未來的日子, 您還會選擇怎樣的工作, 還是IT技術嗎? 若是則表示您的熱情尚未消退, 低潮是難免的, 而能夠重新站起而保持熱情的 (賺錢的因素除外)有哪些呢?
我想到的有 :
a. IT技術不斷推陳出新, 喜歡接受挑戰
b. 學習新的東西, 這對自己來說是很有趣的
c. 成為專家的感覺很好, 因為爬上高山頂端的成就感帶來的快樂
d. 喜歡將學來的東西分享給他人, 分享是件快樂的事
e. 對特定IT技術例如程式語言有高度的興趣, 而與年輕同事談起當年的COBOL, RPGII, FORTRAN回憶年青的時光也很快樂
您還能想到哪些呢?
當然, 也許想想真正失去這些熱情了, 因為賺錢, 工作壓力, 家庭壓力, 壓得透不過氣了, 哪還有心情談熱情, 這時我會帶著妻小, 到山上或海邊, 忘掉這些東西, 或與好友聊天暢飲, 享受人生其他的快樂.
2005年10月20日
什麼是常駐程式 igfxtray
igfxtray.exe is a process which allows you to access the Intel Graphics configuration and diagnostic application for the Intel 810 series graphics chipset. This program is a non-essential system process, and is installed for ease of use via the desktop tray.
用來存取Intel繪圖晶片的程式
用來存取Intel繪圖晶片的程式
What are Adobe Gamma Loader and Adobe Reader Speed Launch?
1. 安裝了Photoshop後自動增加在'啟動'清單內, 用來調整螢幕Gamma值的簡易校色軟體, 較正Monitor用
2. 安裝Acrobat Reader 7.0之後，"啟動"中增加adobe reader speed launch，預先在開機時
就先載入一些東西, 讓7.0的啟動速度變快.
2. 安裝Acrobat Reader 7.0之後，"啟動"中增加adobe reader speed launch，預先在開機時
就先載入一些東西, 讓7.0的啟動速度變快.
2005年10月11日
學一個新的程式語言, 要如何開始, 步驟如何?
Fred Wang 2005/10/11 (http://fredwang.blogspot.com)
當您要學一套全新的程式語言, 要如何開始, 步驟如何?
最基本的有下面幾大部分 :
* 資料型態
* 基本運算
* 順序控制邏輯判斷與平行處理
* 副常式
* 資料控制
* 記憶體管理
* 作業環境控制, 如輸入及輸出處理等
* 如何轉換(編譯或直譯)與執行
這些基本的元件了解後再學習其特有的指令與APIs
資料型態
1. 基本資料型態
如bit, byte, character, integer, float, binary, boolean
較複雜的如 string, number, stack, date等
2. 變數與常數
* 初始值
* null
* data binding
結構化資料結構
* 陣列(Arrays), 集合(Set), 串列(Lists), 指標(Pointers)
* 紀錄(Records), 表格(Table), Stacks, Queues, 檔案(Files)
* 自訂型態
基本運算
* 型態轉換, 型態檢查
* 數字運算, 邏輯運算
* 字串處理
順序控制邏輯判斷與平行處理
* Goto
* 條件式if-then-else
* 迴圈while, do-whlie, loop, for-loop
* 迴圈中斷 : break, exit, continue
* 多重條件式 : case ..
* 副程式 : call..return, perform, Remote Call
* 例外處理 : raise, exception
* 事件處理, 平行處理 : signal, event, task, fork
資料控制
* 變數可見範圍(Public, Private..)
* 動態配置與靜態變數(Static)
* 參數傳遞 (Call by Value, Call by Reference, Call by Name)
記憶體管理
* 遞迴與非遞迴
* Stack, Heap
* Queue, Buffer
* Allocate, New
* Clear, Free, Release, Dispose
* Garbage Collection
作業環境控制, 如輸入及輸出處理等
* 輸入,顯示,列印,儲存
* Export/Import, Upload/Download
如何轉換(編譯或直譯)與執行
* 批次處理,交談式環境
* 編譯,直譯
* 執行環境
* Deployment
* Embedded System
當您要學一套全新的程式語言, 要如何開始, 步驟如何?
最基本的有下面幾大部分 :
* 資料型態
* 基本運算
* 順序控制邏輯判斷與平行處理
* 副常式
* 資料控制
* 記憶體管理
* 作業環境控制, 如輸入及輸出處理等
* 如何轉換(編譯或直譯)與執行
這些基本的元件了解後再學習其特有的指令與APIs
資料型態
1. 基本資料型態
如bit, byte, character, integer, float, binary, boolean
較複雜的如 string, number, stack, date等
2. 變數與常數
* 初始值
* null
* data binding
結構化資料結構
* 陣列(Arrays), 集合(Set), 串列(Lists), 指標(Pointers)
* 紀錄(Records), 表格(Table), Stacks, Queues, 檔案(Files)
* 自訂型態
基本運算
* 型態轉換, 型態檢查
* 數字運算, 邏輯運算
* 字串處理
順序控制邏輯判斷與平行處理
* Goto
* 條件式if-then-else
* 迴圈while, do-whlie, loop, for-loop
* 迴圈中斷 : break, exit, continue
* 多重條件式 : case ..
* 副程式 : call..return, perform, Remote Call
* 例外處理 : raise, exception
* 事件處理, 平行處理 : signal, event, task, fork
資料控制
* 變數可見範圍(Public, Private..)
* 動態配置與靜態變數(Static)
* 參數傳遞 (Call by Value, Call by Reference, Call by Name)
記憶體管理
* 遞迴與非遞迴
* Stack, Heap
* Queue, Buffer
* Allocate, New
* Clear, Free, Release, Dispose
* Garbage Collection
作業環境控制, 如輸入及輸出處理等
* 輸入,顯示,列印,儲存
* Export/Import, Upload/Download
如何轉換(編譯或直譯)與執行
* 批次處理,交談式環境
* 編譯,直譯
* 執行環境
* Deployment
* Embedded System
2005年10月6日
商業模式決定電子商務模式
Fred Wang(http://fredwang.blogspot.com) 2005/10
下面是自己整理的資訊, 提供大家對商業模式與電子商務模式間的關係各進一步的了解.
一個企業決定推動電子商務, 往往因商業模式, 商業對象而有所差異, 可以簡單分成下面幾種 :
企業對企業的電子商務模式(B2B)
: 此類的模式通常為較大型的企業為主推動與其他往來較小規模但電子化程度高的公司或較大規模且業務相依關係較高的公司, 交易大多是兩造雙方直接進行的，無須透過中間人。透過B2B資料交換工具達到企業之間各式互動行為的電子化、效率提升的目標
企業對消費者的電子商務模式(B2C)
: 企業對消費者的電子商務模式，重點在於販賣商品及服務與對個人做行銷。這種方式通常是提供網站供消費者上網註冊後, 再進行交易, 這往往也用於企業對與其往來較小規模且電子化程度低的公司, 或提供給眾多的小型通路商交易及資訊服務的管道
消費者對消費者的電子商務模式(C2C)
: 消費者對消費者的電子商務模式，是將網站經營成一市集 (market place)，讓消費者提供想要出售的商品與服務給其他的消費者。著名的eBay (www.ebay.com) 即屬C2C的電子商務公司。C2C這種商業模式重點在於網站的經營, 利用提供資訊平台來獲取利潤, 而上面兩種模式則是利用資訊技術於傳統商業模式而獲利來源仍來自於商品本身
以台積電為例,
TSMC-Direct : 採用Extricity,主要是系統對系統間的整合, 提供客戶晶圓生產狀況的相關資訊與雙方公司的ERP系統結合，將接單、物料與出貨等程序大幅簡化，係為中大型客戶所量身訂做
TSMC-Online : 提供全球客戶利用網路下單, 即時查詢晶片生產進度和出貨狀況，針對小型的ＩＣ設計公司，即使沒有內部的ERP系統， 也可以方便地利用網站進行簽約、下訂單、觀察晶圓進度等動作。
TSMC-Direct就是B2B模式, TSMC-Online就是B2C模式
B2C的模式, 對大型客戶而言, 如果依存度不高, 也就是若非是這家公司的關鍵性上游廠商, 不太容易要求大型客戶登入您提供的網站, 特別是或許他還要面對數十或數百家上游廠商, 這也許就是許多大型企業透過代理商進行採購的原因.
而身為零件供應的上游廠商對於關鍵性客戶則會提供更主動的服務方式, 主動提供推(Push)式的服務, 主動傳送資訊給客戶, 而非被動式的拉式(Pull)的網站資訊, 但是這種模式提供給許多的小型客戶則是沒有這種問題.
因此客戶規模及業務依存關係影響商業模式, 而商業模式決定電子商務模式.
下面是自己整理的資訊, 提供大家對商業模式與電子商務模式間的關係各進一步的了解.
一個企業決定推動電子商務, 往往因商業模式, 商業對象而有所差異, 可以簡單分成下面幾種 :
企業對企業的電子商務模式(B2B)
: 此類的模式通常為較大型的企業為主推動與其他往來較小規模但電子化程度高的公司或較大規模且業務相依關係較高的公司, 交易大多是兩造雙方直接進行的，無須透過中間人。透過B2B資料交換工具達到企業之間各式互動行為的電子化、效率提升的目標
企業對消費者的電子商務模式(B2C)
: 企業對消費者的電子商務模式，重點在於販賣商品及服務與對個人做行銷。這種方式通常是提供網站供消費者上網註冊後, 再進行交易, 這往往也用於企業對與其往來較小規模且電子化程度低的公司, 或提供給眾多的小型通路商交易及資訊服務的管道
消費者對消費者的電子商務模式(C2C)
: 消費者對消費者的電子商務模式，是將網站經營成一市集 (market place)，讓消費者提供想要出售的商品與服務給其他的消費者。著名的eBay (www.ebay.com) 即屬C2C的電子商務公司。C2C這種商業模式重點在於網站的經營, 利用提供資訊平台來獲取利潤, 而上面兩種模式則是利用資訊技術於傳統商業模式而獲利來源仍來自於商品本身
以台積電為例,
TSMC-Direct : 採用Extricity,主要是系統對系統間的整合, 提供客戶晶圓生產狀況的相關資訊與雙方公司的ERP系統結合，將接單、物料與出貨等程序大幅簡化，係為中大型客戶所量身訂做
TSMC-Online : 提供全球客戶利用網路下單, 即時查詢晶片生產進度和出貨狀況，針對小型的ＩＣ設計公司，即使沒有內部的ERP系統， 也可以方便地利用網站進行簽約、下訂單、觀察晶圓進度等動作。
TSMC-Direct就是B2B模式, TSMC-Online就是B2C模式
B2C的模式, 對大型客戶而言, 如果依存度不高, 也就是若非是這家公司的關鍵性上游廠商, 不太容易要求大型客戶登入您提供的網站, 特別是或許他還要面對數十或數百家上游廠商, 這也許就是許多大型企業透過代理商進行採購的原因.
而身為零件供應的上游廠商對於關鍵性客戶則會提供更主動的服務方式, 主動提供推(Push)式的服務, 主動傳送資訊給客戶, 而非被動式的拉式(Pull)的網站資訊, 但是這種模式提供給許多的小型客戶則是沒有這種問題.
因此客戶規模及業務依存關係影響商業模式, 而商業模式決定電子商務模式.
2005年10月3日
學然後之不足
"人類基於研究上的立場、角度和方法上的不同，所獲得的知識往往是部分的、相對的、暫時的，不代表有「絕對」的意含。因此我們在求的過程中，必須要懂得謙虛、包容和體諒，而不應有妄自尊大、自以為是-------知識份子的傲慢心態。進一步言，求知的目的仍在明理，在開拓一個人的胸襟和視野，最後仍須回歸到「做人」的本分，否則一切必落於空談而毫無智慧可言。"
- 許國宏「知識與人生」 －－通識教育的重要
學然後之不足, 各種領域充斥著兼具專業與傲慢的人, 往往讓人將專業與傲慢劃上等號, 事實上, 所知越多越廣博者, 應該越知道所了解的不足, 而能更謙虛與客觀, 而非傲慢. -- Fred Wang
其他文章 :
1. 專業的傲慢與持續的欺騙
2. 一場「傲慢」與「偏見」的對抗
3. 媒體工作者的傲慢
4. 警惕專業權威型傲慢
5. 職場中的佼佼者
- 許國宏「知識與人生」 －－通識教育的重要
學然後之不足, 各種領域充斥著兼具專業與傲慢的人, 往往讓人將專業與傲慢劃上等號, 事實上, 所知越多越廣博者, 應該越知道所了解的不足, 而能更謙虛與客觀, 而非傲慢. -- Fred Wang
其他文章 :
1. 專業的傲慢與持續的欺騙
2. 一場「傲慢」與「偏見」的對抗
3. 媒體工作者的傲慢
4. 警惕專業權威型傲慢
5. 職場中的佼佼者
2005年10月2日
個人的藍海策略
Fred Wang 2005/10/02 (http://fredwang.blogspot.com)
在商業周刊"藍海策略"文中提及"創造新價值曲線的四項行動架構, 應用在個人價值的提昇上可以用下面的方式表達 :
消除 : 工作中習以為常的因素有哪些應予消除？
降低 : 哪些因素應降低至遠低於一般人的標準？
提升 : 哪些因素應提升到遠超過一般人的標準？
創造 : 哪些工作中從一般人無法或不易達成的因素，自己應該建立
擬定與執行藍海策略的階段的六項原則就可以用下面的方式表達 :
原則一：改造市場疆界 : 提昇自我, 擴大視野, 讓自己有多樣化的能力, 以提昇自己的市場及可工作的種類
原則二：聚焦願景 : 專注於長期的願景, 投資自己, 不要只汲汲營營與短暫的利益
原則三：超越現有需求 : 學習的方向不要限於短期工作所需, 而是要以培養真正的實力為目標
原則四：策略次序要正確 : 確定你努力的方向與目標是一致的, 正確的工作與學習的態度, 做好時間管理, 確實建立自我無可取代的能力與價值
原則五: 設法克服「認知與慣性、資源有限、缺乏動機、政治問題」這四項重大障礙, 相對於個人就是工作與學習有低潮, 人類有惰性, 時間有限, 家庭無法配合等
原則六: 一開始就把執行與策略整合，建立使命感 : 激勵自己不斷朝目標前進
在職場上人與人不免有競爭, 與其花時間在與人勾心鬥角, 或憤世嫉俗, 不如致力於個人價值的提昇, 重新訂定個人的藍海策略.
在商業周刊"藍海策略"文中提及"創造新價值曲線的四項行動架構, 應用在個人價值的提昇上可以用下面的方式表達 :
消除 : 工作中習以為常的因素有哪些應予消除？
降低 : 哪些因素應降低至遠低於一般人的標準？
提升 : 哪些因素應提升到遠超過一般人的標準？
創造 : 哪些工作中從一般人無法或不易達成的因素，自己應該建立
擬定與執行藍海策略的階段的六項原則就可以用下面的方式表達 :
原則一：改造市場疆界 : 提昇自我, 擴大視野, 讓自己有多樣化的能力, 以提昇自己的市場及可工作的種類
原則二：聚焦願景 : 專注於長期的願景, 投資自己, 不要只汲汲營營與短暫的利益
原則三：超越現有需求 : 學習的方向不要限於短期工作所需, 而是要以培養真正的實力為目標
原則四：策略次序要正確 : 確定你努力的方向與目標是一致的, 正確的工作與學習的態度, 做好時間管理, 確實建立自我無可取代的能力與價值
原則五: 設法克服「認知與慣性、資源有限、缺乏動機、政治問題」這四項重大障礙, 相對於個人就是工作與學習有低潮, 人類有惰性, 時間有限, 家庭無法配合等
原則六: 一開始就把執行與策略整合，建立使命感 : 激勵自己不斷朝目標前進
在職場上人與人不免有競爭, 與其花時間在與人勾心鬥角, 或憤世嫉俗, 不如致力於個人價值的提昇, 重新訂定個人的藍海策略.
傾聽的技巧
Fred Wang譯
如何暸解客戶或部屬在想甚麼, 這看來簡單, 但最好的方法還是傾聽, 但是多數人只能聽進25%, 下面有十點提昇傾聽技巧的方法:
1. 傾聽你有興趣及你應該要知道的想法
2. 注意力放在談話的內容而不是姿勢, 分出"說甚麼"及"怎麼說"
3. 不要遽下結論或自以為知道對方要說甚麼
4. 專注在談論主題的主要想法上
5. 保持彈性且不要強迫對方下結論來迎合你心中既定的模式
6. 藉由眼睛接觸與臉部表情讓對方知道你很專心在傾聽
7. 排除及忽略一些會分散注意力的事情如關掉手機, 專注在談論主題
8. 小心你的偏見, 不要讓這些偏見影響你傾聽對方訊息的能力
9. 不要讓自己失了神, 人們一般而言, 思考的速度會比談話速度的快四倍,
不要因為講話的人速度慢而失去耐心, 可以利用這個時間概括整理你所聽到
的
10. 聽出話跟話之間及說的話背後真正的含義及要傳達訊息的內容
如何暸解客戶或部屬在想甚麼, 這看來簡單, 但最好的方法還是傾聽, 但是多數人只能聽進25%, 下面有十點提昇傾聽技巧的方法:
1. 傾聽你有興趣及你應該要知道的想法
2. 注意力放在談話的內容而不是姿勢, 分出"說甚麼"及"怎麼說"
3. 不要遽下結論或自以為知道對方要說甚麼
4. 專注在談論主題的主要想法上
5. 保持彈性且不要強迫對方下結論來迎合你心中既定的模式
6. 藉由眼睛接觸與臉部表情讓對方知道你很專心在傾聽
7. 排除及忽略一些會分散注意力的事情如關掉手機, 專注在談論主題
8. 小心你的偏見, 不要讓這些偏見影響你傾聽對方訊息的能力
9. 不要讓自己失了神, 人們一般而言, 思考的速度會比談話速度的快四倍,
不要因為講話的人速度慢而失去耐心, 可以利用這個時間概括整理你所聽到
的
10. 聽出話跟話之間及說的話背後真正的含義及要傳達訊息的內容
2005年9月30日
提升自信控制壓力的十個祕訣
Fred Wang譯
1.想想看在你離開人世時希望留給別人怎樣記憶,這決定你是怎樣的一個人,銘記在心,做你想要變成的那種人
2.每日給自己一個激勵的話幫助自己養成正面思考的習慣
3.將您過去的成功事例列表記在筆記本上,時常檢視及更新
4.避開消極的思想與消極的人
5.脫離你的舒適(或懶惰)領域,大膽去做些你害怕做的事情
6.不管任何狀況盡你的可能做好, 但不要騙自己認為自己是最完美的
7.原諒自己所曾經犯過的錯誤, 感謝自己努力所得的成就, 把自己當成自己最親密的朋友
8.信賴自己的判斷並在自己的能力範圍內做好的決策
9.學習對將耗盡你的時間與能量的要求說不
10.成就是做出來的不是夢想出來的, 積極的努力成為你希望變成的那種人
1.想想看在你離開人世時希望留給別人怎樣記憶,這決定你是怎樣的一個人,銘記在心,做你想要變成的那種人
2.每日給自己一個激勵的話幫助自己養成正面思考的習慣
3.將您過去的成功事例列表記在筆記本上,時常檢視及更新
4.避開消極的思想與消極的人
5.脫離你的舒適(或懶惰)領域,大膽去做些你害怕做的事情
6.不管任何狀況盡你的可能做好, 但不要騙自己認為自己是最完美的
7.原諒自己所曾經犯過的錯誤, 感謝自己努力所得的成就, 把自己當成自己最親密的朋友
8.信賴自己的判斷並在自己的能力範圍內做好的決策
9.學習對將耗盡你的時間與能量的要求說不
10.成就是做出來的不是夢想出來的, 積極的努力成為你希望變成的那種人
下一波程式設計的挑戰-multithreading 讀後感
看過另一篇文章"程式設計師的保鮮期只有十年", 恰巧Java誕生至今剛好十年, 不過Java的熱度未退, 如同Pascal, Fortran, COBOL 沒有什麼語言,什麼技術是永遠的主流的, 程式設計的思維從結構化到物件導向, 從單機處理,Client-Server,到Multi-Tier, 隨著硬體發展而重新被提起的平行處理/多執行緒的應用.
不要讓自己成為"過期"的IT人員, 只有持續的學習, 保持謙卑與彈性來面對改變!
-- Fred Wang
下面文章是冼鏡光老師(資訊科系的學生應該很熟悉吧!)在程式設計師俱樂部發表的文章, 這裡還有許多的討論
http://www.programmer-club.com/pc2020v5/forum/showsametitleN.asp?board_pc2020=general&id=3499
下一波程式設計的挑戰:multithreading
作者 : shene(冼鏡光)
也許說平行處理太曲高和寡，因為沒多少人買得起，談起來總是相當遙遠。但是我們的桌上型電腦的速度卻也愈來愈快，想當年有一台8mhz的PC就可以引以自豪，再比一比目前3.4ghz的PC，兩者的差別何止千里！問題是，CPU的速度不可能無止境地加快，終有到達瓶頸的一天；沒有人知道這一天何時到來，但若目前的瓶頸無法突破（事實上也很難突破），我們寫程式的人終究有一天會覺得CPU不夠快，我們有對策嗎？我們的知識與技術足以克服這個障礙嗎？
在硬體方面，Intel與其它廠家已經加上了hyperthreading的功能，但效能的增加在最好的狀況也不過是10%到15%而已。所謂的 hyperthreading，指的就是CPU中會把待執行的指令分成幾條執行線(thread)，讓CPU可以在一條線無法繼續時（譬如等待cache 來的資料，或是等待另一條線完成某項工作），能夠執行另一條線的工作。但是運算單元與邏輯單元在CPU中都只有一個，所有執行線都搶著用，於是瓶頸就出現了。
今年，各廠家可能會推出multicore的CPU，把兩個或更多個CPU的功能放在固一個CPU中，因此CPU中的執行線就至少有兩組運算單元與兩組邏輯單元可以使用，這樣hyperthreading的效能又可以再度提高。聽說Intel會把兩個Xeon合併在一個CPU中，並且在今年上市；AMD據說也有類似計劃，當然PowerPC與SPARC也不會落後太遠。
如果這些新一代硬體出現，一般的程式設計技術就不太夠用了，用為我們從頭開始所學的都是「序列式」(serial)的思考方式，所以寫成的程式很可能使hyperthreading與multicore 的架構無用武之地。然而，複線作業(multithreaded programming)的觀念在1960年代末遂漸成型，從IBM PL/I F，全錄(Xerox)的Star，到Modula 3、Ada與Java，這些語言本身都具有複線作業的能力。另外，Unix在1980年代中期也引進了複線作業的能力，後來ANSI的POSIX加上 Pthread標準，以及OS/2、Windows與Sun Solaris都有此等能力。
為什麼複線作業那麼重要？很簡單，如果一個程式有個分身來做額外的事，程式的效率與CPU的使用率就都會提高。好比說，當一條執行線正在等輸出輸入完成時，我們可以起動另一條線進行計算的工作，於是 CPU就不會閒置，從而CPU使用率就會比較高，程式也執行得比較快。這些觀念在您的OS課程中應該學過，正因為如此，我很想請教各位一個很嚴肅的問題：
您準備好迎接下一波程式設計的挑戰了嗎？
過年放假不少天，在吃喝玩樂之餘，我們得真心想一想這個問題的答案。
後記：不知道什麼人始作俑者，把thread譯成「執行緒」而不是上面用的「執行線」。這個「執行緒」譯名的確有點滑稽，程式或系統中何「緒」之有？
不要讓自己成為"過期"的IT人員, 只有持續的學習, 保持謙卑與彈性來面對改變!
-- Fred Wang
下面文章是冼鏡光老師(資訊科系的學生應該很熟悉吧!)在程式設計師俱樂部發表的文章, 這裡還有許多的討論
http://www.programmer-club.com/pc2020v5/forum/showsametitleN.asp?board_pc2020=general&id=3499
下一波程式設計的挑戰:multithreading
作者 : shene(冼鏡光)
也許說平行處理太曲高和寡，因為沒多少人買得起，談起來總是相當遙遠。但是我們的桌上型電腦的速度卻也愈來愈快，想當年有一台8mhz的PC就可以引以自豪，再比一比目前3.4ghz的PC，兩者的差別何止千里！問題是，CPU的速度不可能無止境地加快，終有到達瓶頸的一天；沒有人知道這一天何時到來，但若目前的瓶頸無法突破（事實上也很難突破），我們寫程式的人終究有一天會覺得CPU不夠快，我們有對策嗎？我們的知識與技術足以克服這個障礙嗎？
在硬體方面，Intel與其它廠家已經加上了hyperthreading的功能，但效能的增加在最好的狀況也不過是10%到15%而已。所謂的 hyperthreading，指的就是CPU中會把待執行的指令分成幾條執行線(thread)，讓CPU可以在一條線無法繼續時（譬如等待cache 來的資料，或是等待另一條線完成某項工作），能夠執行另一條線的工作。但是運算單元與邏輯單元在CPU中都只有一個，所有執行線都搶著用，於是瓶頸就出現了。
今年，各廠家可能會推出multicore的CPU，把兩個或更多個CPU的功能放在固一個CPU中，因此CPU中的執行線就至少有兩組運算單元與兩組邏輯單元可以使用，這樣hyperthreading的效能又可以再度提高。聽說Intel會把兩個Xeon合併在一個CPU中，並且在今年上市；AMD據說也有類似計劃，當然PowerPC與SPARC也不會落後太遠。
如果這些新一代硬體出現，一般的程式設計技術就不太夠用了，用為我們從頭開始所學的都是「序列式」(serial)的思考方式，所以寫成的程式很可能使hyperthreading與multicore 的架構無用武之地。然而，複線作業(multithreaded programming)的觀念在1960年代末遂漸成型，從IBM PL/I F，全錄(Xerox)的Star，到Modula 3、Ada與Java，這些語言本身都具有複線作業的能力。另外，Unix在1980年代中期也引進了複線作業的能力，後來ANSI的POSIX加上 Pthread標準，以及OS/2、Windows與Sun Solaris都有此等能力。
為什麼複線作業那麼重要？很簡單，如果一個程式有個分身來做額外的事，程式的效率與CPU的使用率就都會提高。好比說，當一條執行線正在等輸出輸入完成時，我們可以起動另一條線進行計算的工作，於是 CPU就不會閒置，從而CPU使用率就會比較高，程式也執行得比較快。這些觀念在您的OS課程中應該學過，正因為如此，我很想請教各位一個很嚴肅的問題：
您準備好迎接下一波程式設計的挑戰了嗎？
過年放假不少天，在吃喝玩樂之餘，我們得真心想一想這個問題的答案。
後記：不知道什麼人始作俑者，把thread譯成「執行緒」而不是上面用的「執行線」。這個「執行緒」譯名的確有點滑稽，程式或系統中何「緒」之有？
2005年9月28日
"Java天生麗質亂人眼"讀後感
全文 : http://blog.clubbenq.com.cn/904569/archive/2005/09/05/17625.aspx
最後一段, 最有哲理!
"一種語言都有它閃光的地方，都有它迷人的特徵，每一個人在學習電腦的時候，要根據自己的實際情況選擇一門讓自己能夠提高最快的語言來學習。學習語言本身就是學習電腦的末流，是附屬。程式思想才是一個程式師要掌握的核心。
很多問題，用各種語言都可以描述，語言本身沒有貴賤之分，倒是人們刻意的去尋找這種貴賤區別，迷惑了自己，也迷惑了別人。
C 的程式師們可以放下顧慮，認真地學習Java，這就表明了很多C程式師的博大，也許這些高手已經參透了電腦的本質，學習語言只是因爲學了它可以偷懶而 以。那麽就請很多Java程式師不要在做井底之蛙，來嘲笑一個C語言程式師了。要知道，一個C的高手學Java，只是須臾之事，根本花不了太多的精力和時 間。
我們學Java，只是爲了工作的更好，並不是因爲不會Java，我們就無所適從。任何一門語言消失了，世界都依舊存在，依舊美好。"
感想 :
本文真是太好了! 給一些擁抱一種技術就以為是全世界的人當頭棒喝!
從74年開始學Basic, 後陸續學過Fortran, Pascal, Forth, COBOL, RPGII, dBase3/Clipper, C, Assembly Lang., Prolog, Lisp, HTML, Javascript, Java, ABAP/4, 不論是用到多少, 我從來不認為哪種程式語言是最完美的! 重點是 "程式思想才是一個程式師要掌握的核心" 使用電腦語言, APIs, Programming Library, Tools, IDE等, 都是為了讓工作更好, 創造價值, 因此只要能創造最大效益的就是最好的.
最後一段, 最有哲理!
"一種語言都有它閃光的地方，都有它迷人的特徵，每一個人在學習電腦的時候，要根據自己的實際情況選擇一門讓自己能夠提高最快的語言來學習。學習語言本身就是學習電腦的末流，是附屬。程式思想才是一個程式師要掌握的核心。
很多問題，用各種語言都可以描述，語言本身沒有貴賤之分，倒是人們刻意的去尋找這種貴賤區別，迷惑了自己，也迷惑了別人。
C 的程式師們可以放下顧慮，認真地學習Java，這就表明了很多C程式師的博大，也許這些高手已經參透了電腦的本質，學習語言只是因爲學了它可以偷懶而 以。那麽就請很多Java程式師不要在做井底之蛙，來嘲笑一個C語言程式師了。要知道，一個C的高手學Java，只是須臾之事，根本花不了太多的精力和時 間。
我們學Java，只是爲了工作的更好，並不是因爲不會Java，我們就無所適從。任何一門語言消失了，世界都依舊存在，依舊美好。"
感想 :
本文真是太好了! 給一些擁抱一種技術就以為是全世界的人當頭棒喝!
從74年開始學Basic, 後陸續學過Fortran, Pascal, Forth, COBOL, RPGII, dBase3/Clipper, C, Assembly Lang., Prolog, Lisp, HTML, Javascript, Java, ABAP/4, 不論是用到多少, 我從來不認為哪種程式語言是最完美的! 重點是 "程式思想才是一個程式師要掌握的核心" 使用電腦語言, APIs, Programming Library, Tools, IDE等, 都是為了讓工作更好, 創造價值, 因此只要能創造最大效益的就是最好的.
2005年9月26日
Lotus Quickplace的問題與答覆
問題 :
我是某大學教授的助理
幫忙教授管理還有製作工作區
能否麻煩請教一些有關quickplace的問題
目前我在自訂佈景主題那邊有一些問題
就是在版面配置的問題
我想讓TOC的table能往下移一點
那個是要在清單資料夾配置的htm檔裡面去設定嗎?
另外我幾乎不會什麼程式或java
我之前是先用IBM的REDBOOK的相關檔案下載
IBM做為範例的檔案
但裡面並沒有清單資料夾配置的htm檔(Listfolder.htm)
當然平台也可以自動幫我產生那個檔
可是就沒有辦法配合我想要的樣子
請問一下有沒有什麼辦法
把平台自動產生的那個檔捉下來
我才能參考
另外請問一下除了IBM的那個REDBOOK
還有沒有什麼資源可以讓我參考
怎麼自製QUICKPLACE的佈景主題
關於版面配置
我幾乎都不會
不知道要怎麼去設定
- Holisi
答覆 :
問題一: 更改TOC要改哪些檔案?
答:
要更改TOC table的位置, 要同時到資料夾清單(list folder)及Page theme file(html)中更改, 若您有使用slide or headline 形態的folder, 也要到其他兩個theme file修改, 否則在顯示單一網頁內容會與顯示資料夾清單會有不同的TOC, 除非您有特殊需要, 要讓兩者有所不同.
問題二.請問一下有沒有什麼辦法,把平台自動產生的那個檔捉下來?
答:
Quickplace系統只提供一個標準的template給你下載, 其他的template則無法下載, 可以做的是用Dreamware or frontpage做這些Theme files(html)再逐一將Quickplace Component tags加入這些Themes, 然後上傳到您的Quickplace site
這種方式, 不需要懂Java, 但是設計的好不好, 則與美學設計有關了, 當然熟HTML是基本的, 另外Quickplace Customizing 手冊中第四章介紹的Theme and Quickplace components也要熟悉
-- Fred Wang 2005/02/25
我是某大學教授的助理
幫忙教授管理還有製作工作區
能否麻煩請教一些有關quickplace的問題
目前我在自訂佈景主題那邊有一些問題
就是在版面配置的問題
我想讓TOC的table能往下移一點
那個是要在清單資料夾配置的htm檔裡面去設定嗎?
另外我幾乎不會什麼程式或java
我之前是先用IBM的REDBOOK的相關檔案下載
IBM做為範例的檔案
但裡面並沒有清單資料夾配置的htm檔(Listfolder.htm)
當然平台也可以自動幫我產生那個檔
可是就沒有辦法配合我想要的樣子
請問一下有沒有什麼辦法
把平台自動產生的那個檔捉下來
我才能參考
另外請問一下除了IBM的那個REDBOOK
還有沒有什麼資源可以讓我參考
怎麼自製QUICKPLACE的佈景主題
關於版面配置
我幾乎都不會
不知道要怎麼去設定
- Holisi
答覆 :
問題一: 更改TOC要改哪些檔案?
答:
要更改TOC table的位置, 要同時到資料夾清單(list folder)及Page theme file(html)中更改, 若您有使用slide or headline 形態的folder, 也要到其他兩個theme file修改, 否則在顯示單一網頁內容會與顯示資料夾清單會有不同的TOC, 除非您有特殊需要, 要讓兩者有所不同.
問題二.請問一下有沒有什麼辦法,把平台自動產生的那個檔捉下來?
答:
Quickplace系統只提供一個標準的template給你下載, 其他的template則無法下載, 可以做的是用Dreamware or frontpage做這些Theme files(html)再逐一將Quickplace Component tags加入這些Themes, 然後上傳到您的Quickplace site
這種方式, 不需要懂Java, 但是設計的好不好, 則與美學設計有關了, 當然熟HTML是基本的, 另外Quickplace Customizing 手冊中第四章介紹的Theme and Quickplace components也要熟悉
-- Fred Wang 2005/02/25
2300萬個工作狂比不上5800萬個哲學家
台灣的工作時數是世界最多，經濟表現幾乎是敬陪末座的第四十名； 法國的工作時數是世界最少，經濟表現卻是世界第八名。 這樣的結果讓人困惑，為什麼2,300萬個工作狂，卻比不上5,800萬個哲學家？ (From 2002年11月 CHEERS雜誌)
世界不斷創造出各式各樣的商品, 科技產品推陳出新, 價格也越趨低廉, 而多數人的生活卻越來越趨忙碌而失去生活品質, 您有意識到您的努力有讓世界變的更好,讓生活品質變的更好, 讓自己變的更好嗎? 如果沒有, 重新思考您要走的路與重新規劃您的生活吧! -- Fred Wang
名言 :
「不要追求成功，試著追求生命的意義！」～愛因斯坦
世界不斷創造出各式各樣的商品, 科技產品推陳出新, 價格也越趨低廉, 而多數人的生活卻越來越趨忙碌而失去生活品質, 您有意識到您的努力有讓世界變的更好,讓生活品質變的更好, 讓自己變的更好嗎? 如果沒有, 重新思考您要走的路與重新規劃您的生活吧! -- Fred Wang
名言 :
「不要追求成功，試著追求生命的意義！」～愛因斯坦
新成立的公司資訊系統建構的順序 - 製造業為例
Fred Wang (2002/05/02)
一般公司建立到申請上櫃,需八大內部控管循環:
. 銷售及收款循環
. 採購及付款循環
. 固定資產循環
. 融資循環
. 薪工循環
. 生產循環
. 投資循環
. 資訊管理循環
1. 其中財務主體有三項, 與財務相關有三項
2. 而協助制度的建立為首要, 其次才是自動化系統的建立
3. 若是製造業則以生產系統為必要建立的系統
4. 營運系統(ERP) 則以財務第一, 人事其次, 然後倉/物管及生管最後才是採購及接單
5. 至於CRM, 電子商務, 資料倉儲, EIS等, 則是建立在這些基礎之上
因此優先順序:
制度建立--基礎建設(Infrastructure)--生產系統--營運系統(財務--人事--倉/物管/生管--接單/採購)--CRM/eBusiness/EIS/DW
當然系統尚未建構前, 例如接單系統較晚建立, 則須透過書面文件的方式作業.
一般公司建立到申請上櫃,需八大內部控管循環:
. 銷售及收款循環
. 採購及付款循環
. 固定資產循環
. 融資循環
. 薪工循環
. 生產循環
. 投資循環
. 資訊管理循環
1. 其中財務主體有三項, 與財務相關有三項
2. 而協助制度的建立為首要, 其次才是自動化系統的建立
3. 若是製造業則以生產系統為必要建立的系統
4. 營運系統(ERP) 則以財務第一, 人事其次, 然後倉/物管及生管最後才是採購及接單
5. 至於CRM, 電子商務, 資料倉儲, EIS等, 則是建立在這些基礎之上
因此優先順序:
制度建立--基礎建設(Infrastructure)--生產系統--營運系統(財務--人事--倉/物管/生管--接單/採購)--CRM/eBusiness/EIS/DW
當然系統尚未建構前, 例如接單系統較晚建立, 則須透過書面文件的方式作業.
實作ERP系統時料號編碼策略問題探討
在導入物料管理系統時，往往會有料號編碼原則的問題，要將料號賦予意義的編碼原則還是用系統自動產生沒有意義的編碼? 下面是一個CPIM專家的回答 :
實作ERP系統時料號編碼策略問題 :
. What part numbering strategies have other companies employed during implementation of an ERP system?
. Why was this strategy chosen?
. What problems arose during implementation because of this decision?
. If you were to do this all over again, would you make the same decision?
顧問解答如下 :
This issue comes up in most ERP implementations. I have had this discussion with almost every company that I have been involved with. My recommendation would be the same as your SAP consultants. No matter how much or little intelligence you put in your part numbers you will run out of numbers some time. Or your business will change enough that your part numbers don't mean as much as they used to. SAP has a good solution to this problem. Let SAP auto-generate your part numbers and use Classification to classify the numbers into the groups that you want. You can then build reports or search queries to find the part number or groups of part numbers that you want. SAP also has "material groups" that you can assign to a group of part numbers. This would be like a commodity code.
By using classification you also help eliminate the possibility of having two part numbers for the same physical part because you could not find the part number and just created a new one.
During implementation the problem is that you have to retrain people to not rely on the part number and that they should rely on the description to identify the physical part. Descriptions have to be very specific using Noun, Adjective, Adjective, etc.
Another thing that I have seen is that in the storeroom or warehouse people try to put the inventory in part number order. This might be of some help when trying to find a part number but it is very inefficient for storage space. You should use a part locator to store material and not the part number sequence.
Would I do it again?? Without a doubt I would use system generated part numbers.
這個問題發生在大多數ERP導入過程。我幾乎跟每一個參與導入的公司有過這樣的討論。我的建議跟一般SAP顧問一樣。無論您把公司的料號編碼加入多少智慧(意義)，執行一段時間，號碼就會用完。或者是因為業務的改變，造成料號編碼的原則已經不敷使用。
SAP對這個問題具有很好地解決方法。讓SAP自動產生料號並使用Classification來進行分類分群。您可以建立報表或透過搜尋，找到需要的料號或料號群組。 SAP還有“material groups(物料群組)”，你將它指定給料號。就像一個商品代碼，藉由分類可以避免相同實體料件，建立了兩個不同的料號。
在導入過程中的問題是，你必須訓練同仁，不要再依賴於料號編碼，讓他們依靠的料號的描述，了解物料的實體特性。這個描述必須要非常具體的使用名詞，形容詞，形容詞等。
我曾看過在儲藏室或倉庫的人試圖把庫存以料號來排序。這可能有助於找到一個物料，但對這種方式對存儲空間是非常沒有效率的。而應該使用"料號定位碼"(part locator)，來存放物料，而不是料號的順序。
毫無疑問，我會用系統來自動產生料號。
Steve Blair CPIM
Quality Systems Consulting
感想 :
料號採系統自動編碼機制? 也就是無意義的料號編碼! 但是在實際的生產及倉儲人員卻無法透過無意義的編號進行溝通, 因此生產及倉儲人員透過另一種方式描述料號, 但是必須有良好的管理方式及嚴格的轉換機制, 否則容易造成錯誤. - Fred Wang
實作ERP系統時料號編碼策略問題 :
. What part numbering strategies have other companies employed during implementation of an ERP system?
. Why was this strategy chosen?
. What problems arose during implementation because of this decision?
. If you were to do this all over again, would you make the same decision?
顧問解答如下 :
This issue comes up in most ERP implementations. I have had this discussion with almost every company that I have been involved with. My recommendation would be the same as your SAP consultants. No matter how much or little intelligence you put in your part numbers you will run out of numbers some time. Or your business will change enough that your part numbers don't mean as much as they used to. SAP has a good solution to this problem. Let SAP auto-generate your part numbers and use Classification to classify the numbers into the groups that you want. You can then build reports or search queries to find the part number or groups of part numbers that you want. SAP also has "material groups" that you can assign to a group of part numbers. This would be like a commodity code.
By using classification you also help eliminate the possibility of having two part numbers for the same physical part because you could not find the part number and just created a new one.
During implementation the problem is that you have to retrain people to not rely on the part number and that they should rely on the description to identify the physical part. Descriptions have to be very specific using Noun, Adjective, Adjective, etc.
Another thing that I have seen is that in the storeroom or warehouse people try to put the inventory in part number order. This might be of some help when trying to find a part number but it is very inefficient for storage space. You should use a part locator to store material and not the part number sequence.
Would I do it again?? Without a doubt I would use system generated part numbers.
這個問題發生在大多數ERP導入過程。我幾乎跟每一個參與導入的公司有過這樣的討論。我的建議跟一般SAP顧問一樣。無論您把公司的料號編碼加入多少智慧(意義)，執行一段時間，號碼就會用完。或者是因為業務的改變，造成料號編碼的原則已經不敷使用。
SAP對這個問題具有很好地解決方法。讓SAP自動產生料號並使用Classification來進行分類分群。您可以建立報表或透過搜尋，找到需要的料號或料號群組。 SAP還有“material groups(物料群組)”，你將它指定給料號。就像一個商品代碼，藉由分類可以避免相同實體料件，建立了兩個不同的料號。
在導入過程中的問題是，你必須訓練同仁，不要再依賴於料號編碼，讓他們依靠的料號的描述，了解物料的實體特性。這個描述必須要非常具體的使用名詞，形容詞，形容詞等。
我曾看過在儲藏室或倉庫的人試圖把庫存以料號來排序。這可能有助於找到一個物料，但對這種方式對存儲空間是非常沒有效率的。而應該使用"料號定位碼"(part locator)，來存放物料，而不是料號的順序。
毫無疑問，我會用系統來自動產生料號。
Steve Blair CPIM
Quality Systems Consulting
感想 :
料號採系統自動編碼機制? 也就是無意義的料號編碼! 但是在實際的生產及倉儲人員卻無法透過無意義的編號進行溝通, 因此生產及倉儲人員透過另一種方式描述料號, 但是必須有良好的管理方式及嚴格的轉換機制, 否則容易造成錯誤. - Fred Wang
2005年9月22日
SAP是甚麼的縮寫-Joke
Stupid And Pay
Shutup and Pay
Send Another Payment
Stop All Processes
Suffer After Purchase
Slow and Painful
Slow And Problematic
Submit And Pray
Stress, Anxiety, Panic
Reference : "What does SAP stand for?" From http://www.experts-exchange.com
如同微軟, 最大的公司往往目標也最明顯, 最容易成為眾矢之的.
ps. 正確解答是 "System Analysis and Programming"(早期) 或 "System, Application and Product in the data processing"的縮寫
Shutup and Pay
Send Another Payment
Stop All Processes
Suffer After Purchase
Slow and Painful
Slow And Problematic
Submit And Pray
Stress, Anxiety, Panic
Reference : "What does SAP stand for?" From http://www.experts-exchange.com
如同微軟, 最大的公司往往目標也最明顯, 最容易成為眾矢之的.
ps. 正確解答是 "System Analysis and Programming"(早期) 或 "System, Application and Product in the data processing"的縮寫
SAP - Stops All Production ?
在J-Walk Blog中看到兩個對SAP的評論 :
(1)
We have SAP in our large corporation, and, what used to take one person to do in a half day, now take three people three days.
The standing joke is that SAP stands for "Stops All Production".
It is a horrible control system that tries to be all things to anybody who makes anything.
Is the screw you ordered the wrong thread? Good luck. It will take half a dozen people to correct the situation, IF they are authorized to do so, and probably they are not.
(I hate SAP, in case you wondered...)
SAP a great system to buy, for your competitor.
-- By Jim Arnett . Comment posted 28-Apr-2005
(2)
All I know is the guy in the next office over, on a daily basis, is on the phone talking Oracle and SAP, and we use SAP for equipment and services rendered cost codes. You have to look in a 3" thick book to find the SAP cost code. Then when we are done with drilling a well, someone in town adds up all the SAP costs and starts b******g about the million dollars spent to drill the well. To confusing for me. I'm far enough up the ladder right now, that it's gonna hurt like heck if I take a fall.
-- By Rance . Comment posted 28-Apr-2005
http://j-walkblog.com/index.php?/weblog/comments/sap_and_erp/
SAP是功能齊備的豪華轎車, 不是所有企業玩得起的, 不過近年已提出中小企業的解決方案,
企業仍因其企業規模,需求,投資等審慎評估再決定是否採用.
(1)
We have SAP in our large corporation, and, what used to take one person to do in a half day, now take three people three days.
The standing joke is that SAP stands for "Stops All Production".
It is a horrible control system that tries to be all things to anybody who makes anything.
Is the screw you ordered the wrong thread? Good luck. It will take half a dozen people to correct the situation, IF they are authorized to do so, and probably they are not.
(I hate SAP, in case you wondered...)
SAP a great system to buy, for your competitor.
-- By Jim Arnett . Comment posted 28-Apr-2005
(2)
All I know is the guy in the next office over, on a daily basis, is on the phone talking Oracle and SAP, and we use SAP for equipment and services rendered cost codes. You have to look in a 3" thick book to find the SAP cost code. Then when we are done with drilling a well, someone in town adds up all the SAP costs and starts b******g about the million dollars spent to drill the well. To confusing for me. I'm far enough up the ladder right now, that it's gonna hurt like heck if I take a fall.
-- By Rance . Comment posted 28-Apr-2005
http://j-walkblog.com/index.php?/weblog/comments/sap_and_erp/
SAP是功能齊備的豪華轎車, 不是所有企業玩得起的, 不過近年已提出中小企業的解決方案,
企業仍因其企業規模,需求,投資等審慎評估再決定是否採用.
2005年9月16日
當您想要的太多, 往往也忽略失去了什麼
商業周刊 "裁員一半，蘭奇卻衝出宏碁美國四倍價值" 文中提到宏碁電腦總經理蔣凡可．蘭奇（Gianfranco Lanci）的致勝之道不是加法，而是「減法」，他的心法是：「搞清楚不必做什麼事，比學會該做什麼事還要困難。」
我想人生也是如此, 簡單而專注, 才能成就一項事業
蘭奇說到:「每一小時，太陽都會朝地球散發數以億計千瓦的能量，戴頂帽子，加上一些遮陽裝備，可以在大太陽底下，享受好幾小時的日光浴；但只凝聚數千瓦而形成的雷射光，卻能夠鑿穿鋼板，或消滅癌細胞。」這就是專注與聚焦的力量
因此,
當您的思想過於複雜, 將無法進行更深層的人生體會與思考
當您的夢想過多, 將無法專注在任何一個夢想的實現
當您的交友過多, 將無法真正的找到知心的對象
當您學習過於廣泛, 將無法成為特定領域的專家
當您想要的太多, 往往也忽略失去了什麼
Fred Wang 2005/09/16 商業周刊讀後感
我想人生也是如此, 簡單而專注, 才能成就一項事業
蘭奇說到:「每一小時，太陽都會朝地球散發數以億計千瓦的能量，戴頂帽子，加上一些遮陽裝備，可以在大太陽底下，享受好幾小時的日光浴；但只凝聚數千瓦而形成的雷射光，卻能夠鑿穿鋼板，或消滅癌細胞。」這就是專注與聚焦的力量
因此,
當您的思想過於複雜, 將無法進行更深層的人生體會與思考
當您的夢想過多, 將無法專注在任何一個夢想的實現
當您的交友過多, 將無法真正的找到知心的對象
當您學習過於廣泛, 將無法成為特定領域的專家
當您想要的太多, 往往也忽略失去了什麼
Fred Wang 2005/09/16 商業周刊讀後感
2005年9月12日
SAP工廠維護模組(PM)主要物件名詞解釋
SAP工廠維護模組(PM)主要物件名詞解釋
Fred Wang 2005/09/11 (http://fredwang.blogspot.com)
第一部份 Functional Locations
Functional Locations
功能位置(Functional Locations)為技術結構的組成元素，例如: 工廠的功能性子單元; 功能位置以階層式方式建立， 可以根據下面條件來建立其結構
1.功能
2.流程導向
3.空間
一個功能位置代表一個執行維護工作的場所。
需定義的欄位有 :
-Structure Indicator
-Functional Location
-Functional Location Category
-Object Type
-Maintenance Plant
-Plant Section
-Cost Center
-Planning Plant
-Planner Group
-Main Work Center
-Catalog Profile
主要欄位描述如下 :
Structure Indicator
決定功能位置的結構建立時階層編號方式(edit mask)
欄位 :
-Structure Indicator
-Description
-Edit mask
Object Type
定義技術物件的型態。用來將技術物件分組以區分主檔資料或維護資料。
欄位 :
-Object Type
-Description
Maintenance Plant
維修工廠(maintenance plants)是一個可以管理技術元件(technical objects)和負責執行工作的工作中心(work centers)的工廠
Plant Section
從生產的角度將維護工廠區分成一些工廠區域。負責這個工廠區域的人就是協調生產與工廠維護的聯絡人。
欄位 :
-Plant
-Plant Section
-Person Responsible
-Telephone
Maintenance Planning Plant
定義維修工作清單，在工作清單中以BOMs基礎執行物料規劃和執行維修工令，管理及安排維修時程，為相關的維修工廠輸入維修通知和處理維修工令的工廠。
欄位 :
-Planning Plant
-Name
Planner Group
定義計劃工廠相關的計劃小組(Planner Group)
欄位 :
-Planning Plant
-Planner Group
-Name
-Telephone
Maintenance BOM
第二部份 Equipment
Equipment
設備只一個獨立的維護單元，每一個設備可以個別管理。因此可以 :
-從維護的角度管理個別的資料
-產生個別的工廠維護行動
-紀錄每一個工廠維護工作
-蒐集並評估跨一段長時間的技術資料
設備可以在功能位置(Functional Location)安裝及採解。每個設備在功能位置的作業時間可以按照時間先後被紀錄下來。
欄位 :
-Equipment Category – 設備類別，ex: Q: Test/Measurement Equipment
-Description
-Type of Technical Object – 設備類型
-Vendor Number – 供應商
-Manufacturer – 製造商
-Manufacturer model number
-Manufacturer serial number -製造商設備序號
-Plant - 維護工廠
-Company Code
-Planning Plant
-Planner Group
-Main Work Center
-Material
-Serial Number
Material with Serial Number Profile
這種物料指定給設備(在設備主檔的serialization view)用來建立及管理設備的維護紀錄，這類的物料不會使用在別種作業上。
欄位 :
-Industry sector
-Material type
-Plant
-Storage Location
-Description
-Base unit of measure
-Material Group
-Purchasing Group
-Serial no. profile
第三部份 Maintenance Plan
General Maintenance Task List
一般維護工作清單記錄所有需要的維護工作。維護計劃建立時會指定一般維護工作清單。清單中的作業(operations)此時會轉入維護計劃內，後來將轉到維護工令內。
欄位 :
-Description
-Planning Plant
-Work Center
-Usage : 4 (Plant Maintenance)
-Planner Group
-Task List Status : 4 (Released)
-Inspection points
Operations
-Operation
-Control Key
-Operation Description
-Work : 維護工作時間
-Unit : “H” for hours維護工作時間單位
-Number of Person
Maintenance Plan
欄位 :
-Maintenance Plan Category
Single Cycle Plan View
-Description
-Cycle - 維護週期的長度
-Unit - 維護週期的單位, ex: “MON” (month)
-Offset - 從維護計劃開始到啟動工令的時間
-Equipment – 要維護的設備
-Planning Plant
-Order type – PM02 (Maintenance Order)
-Main Work Center
建立後自動給一個Maintenance Plan Number
-Planner Group
-Maintenance Activity Type - 002 (Preventive Maintenance)
-Type - Task List Category
-Task List Group
-Group Counter
Maintenance plan scheduling parameters
-Shift Factor Late Completion
-Tolerance (+)
-Shift Factor Early Completion
-Tolerance (-)
-Cycle Modification Factor
-Call horizon
-Scheduling period
-Completion Requirement – Order operations是否需要確認(confirmation)
-Cycle start
在維護計劃可以使用前，必須進行排程(Scheduling)並啟動的程序，排程就是依據上面的排程參數來進行。
第四部份 Maintenance Order
Maintenance Notification
當技術物件不能正確或正常運作或產生較差的結果, 此時員工必須開立維護通知，如果使用解決方案資料庫(solution database), 則可以根據問題搜尋可能的解決方案。維護通知可以描述詳細的技術異常狀態，並藉此提出維護需求。
欄位 :
-Notification Type : 分為兩種 : 故障報告(M1)及故障需求(M2)
-Equipment
-Assembly
-Description
-Subject Long Text
-Reported by
-Object part
-Damage
-Text
-Cause Code
-Cause Text
System availability and System Condition
-Functional Location affected
-Availability before malfunction - 故障發生前的可用程度
-Availability after malfunction - 故障發生前的可用程度
-System availability after task -維修後系統的可用程度
-Condition before malfunction – 故障發生前的情況
-Condition after malfunction – 故障發生後的情況
-Condition after task – 維修後的情況
Breakdown
-Malfunction start - 故障開始的時間
-Malfunction end -故障修好的時間
-Breakdown – 是否已經完全修好
-Breakdown duration – 故障總時間 (自動計算)
Maintenance Order
維護工令用來規劃更細的維護工作，例如決定維護工作要內部處理或外部處理，需要那些原件(物料)，另外也可以用來搜集維護工作的成本
欄位 :
-Order Type
-Priority
-Functional Location
-Equipment
-Assembly
-Maintenance planning plant
Assembly Structure List :
-Order short text
-PM Activity type : ex: 003 (Repair)
-System condition
-Basic start
-Basic finish
-Operation text
-Work duration
-Number
Operations
-Operation Number
-Operations Short text
-Control key : ex: PM02 (external processing)
If Control key is “external processing”, select “External” (輸入採購資訊)
-Operation quantity
-Price
-Purchasing group
-Purchasing organization
-Recipient
-Unloading point
-Vendor number
Explanation for Including Components (Spare Parts)
-Description
-Item category
-Unit of measure
-Quantity or requirement
-Operation Number
-Component (material number)
-Material type
-Material description
Fred Wang 2005/09/11 (http://fredwang.blogspot.com)
第一部份 Functional Locations
Functional Locations
功能位置(Functional Locations)為技術結構的組成元素，例如: 工廠的功能性子單元; 功能位置以階層式方式建立， 可以根據下面條件來建立其結構
1.功能
2.流程導向
3.空間
一個功能位置代表一個執行維護工作的場所。
需定義的欄位有 :
-Structure Indicator
-Functional Location
-Functional Location Category
-Object Type
-Maintenance Plant
-Plant Section
-Cost Center
-Planning Plant
-Planner Group
-Main Work Center
-Catalog Profile
主要欄位描述如下 :
Structure Indicator
決定功能位置的結構建立時階層編號方式(edit mask)
欄位 :
-Structure Indicator
-Description
-Edit mask
Object Type
定義技術物件的型態。用來將技術物件分組以區分主檔資料或維護資料。
欄位 :
-Object Type
-Description
Maintenance Plant
維修工廠(maintenance plants)是一個可以管理技術元件(technical objects)和負責執行工作的工作中心(work centers)的工廠
Plant Section
從生產的角度將維護工廠區分成一些工廠區域。負責這個工廠區域的人就是協調生產與工廠維護的聯絡人。
欄位 :
-Plant
-Plant Section
-Person Responsible
-Telephone
Maintenance Planning Plant
定義維修工作清單，在工作清單中以BOMs基礎執行物料規劃和執行維修工令，管理及安排維修時程，為相關的維修工廠輸入維修通知和處理維修工令的工廠。
欄位 :
-Planning Plant
-Name
Planner Group
定義計劃工廠相關的計劃小組(Planner Group)
欄位 :
-Planning Plant
-Planner Group
-Name
-Telephone
Maintenance BOM
第二部份 Equipment
Equipment
設備只一個獨立的維護單元，每一個設備可以個別管理。因此可以 :
-從維護的角度管理個別的資料
-產生個別的工廠維護行動
-紀錄每一個工廠維護工作
-蒐集並評估跨一段長時間的技術資料
設備可以在功能位置(Functional Location)安裝及採解。每個設備在功能位置的作業時間可以按照時間先後被紀錄下來。
欄位 :
-Equipment Category – 設備類別，ex: Q: Test/Measurement Equipment
-Description
-Type of Technical Object – 設備類型
-Vendor Number – 供應商
-Manufacturer – 製造商
-Manufacturer model number
-Manufacturer serial number -製造商設備序號
-Plant - 維護工廠
-Company Code
-Planning Plant
-Planner Group
-Main Work Center
-Material
-Serial Number
Material with Serial Number Profile
這種物料指定給設備(在設備主檔的serialization view)用來建立及管理設備的維護紀錄，這類的物料不會使用在別種作業上。
欄位 :
-Industry sector
-Material type
-Plant
-Storage Location
-Description
-Base unit of measure
-Material Group
-Purchasing Group
-Serial no. profile
第三部份 Maintenance Plan
General Maintenance Task List
一般維護工作清單記錄所有需要的維護工作。維護計劃建立時會指定一般維護工作清單。清單中的作業(operations)此時會轉入維護計劃內，後來將轉到維護工令內。
欄位 :
-Description
-Planning Plant
-Work Center
-Usage : 4 (Plant Maintenance)
-Planner Group
-Task List Status : 4 (Released)
-Inspection points
Operations
-Operation
-Control Key
-Operation Description
-Work : 維護工作時間
-Unit : “H” for hours維護工作時間單位
-Number of Person
Maintenance Plan
欄位 :
-Maintenance Plan Category
Single Cycle Plan View
-Description
-Cycle - 維護週期的長度
-Unit - 維護週期的單位, ex: “MON” (month)
-Offset - 從維護計劃開始到啟動工令的時間
-Equipment – 要維護的設備
-Planning Plant
-Order type – PM02 (Maintenance Order)
-Main Work Center
建立後自動給一個Maintenance Plan Number
-Planner Group
-Maintenance Activity Type - 002 (Preventive Maintenance)
-Type - Task List Category
-Task List Group
-Group Counter
Maintenance plan scheduling parameters
-Shift Factor Late Completion
-Tolerance (+)
-Shift Factor Early Completion
-Tolerance (-)
-Cycle Modification Factor
-Call horizon
-Scheduling period
-Completion Requirement – Order operations是否需要確認(confirmation)
-Cycle start
在維護計劃可以使用前，必須進行排程(Scheduling)並啟動的程序，排程就是依據上面的排程參數來進行。
第四部份 Maintenance Order
Maintenance Notification
當技術物件不能正確或正常運作或產生較差的結果, 此時員工必須開立維護通知，如果使用解決方案資料庫(solution database), 則可以根據問題搜尋可能的解決方案。維護通知可以描述詳細的技術異常狀態，並藉此提出維護需求。
欄位 :
-Notification Type : 分為兩種 : 故障報告(M1)及故障需求(M2)
-Equipment
-Assembly
-Description
-Subject Long Text
-Reported by
-Object part
-Damage
-Text
-Cause Code
-Cause Text
System availability and System Condition
-Functional Location affected
-Availability before malfunction - 故障發生前的可用程度
-Availability after malfunction - 故障發生前的可用程度
-System availability after task -維修後系統的可用程度
-Condition before malfunction – 故障發生前的情況
-Condition after malfunction – 故障發生後的情況
-Condition after task – 維修後的情況
Breakdown
-Malfunction start - 故障開始的時間
-Malfunction end -故障修好的時間
-Breakdown – 是否已經完全修好
-Breakdown duration – 故障總時間 (自動計算)
Maintenance Order
維護工令用來規劃更細的維護工作，例如決定維護工作要內部處理或外部處理，需要那些原件(物料)，另外也可以用來搜集維護工作的成本
欄位 :
-Order Type
-Priority
-Functional Location
-Equipment
-Assembly
-Maintenance planning plant
Assembly Structure List :
-Order short text
-PM Activity type : ex: 003 (Repair)
-System condition
-Basic start
-Basic finish
-Operation text
-Work duration
-Number
Operations
-Operation Number
-Operations Short text
-Control key : ex: PM02 (external processing)
If Control key is “external processing”, select “External” (輸入採購資訊)
-Operation quantity
-Price
-Purchasing group
-Purchasing organization
-Recipient
-Unloading point
-Vendor number
Explanation for Including Components (Spare Parts)
-Description
-Item category
-Unit of measure
-Quantity or requirement
-Operation Number
-Component (material number)
-Material type
-Material description
2005年9月6日
SAP R/3 與外部系統整合設計概述
Fred Wang(20050906) http://fredwang.blogspot.com
整合設計常出現的現象如下 :
1.多數的時間與成本花在定義與實作跨系統的流程與介面
2.不好的介面設計造成效能,資料一致性及管理上的問題
除了跨系統間的介面設計外還有許多問題需要思考的, 下面將整合設計粗分為三階段:
初部設計階段
產出 :
. 商業流程圖與描述
. 限制因素
. 資料物件 :
必須詳細瞭解交換的物件及物件在兩個系統間的差異, 除了意義上的差別, 在資料內容上也可能不同,必須考慮其轉換的方法
. 實作策略
問題 :
1.介面應建立在商業流程的那個地方?
2.有那些限制因素, 如non-SAP系統環境, 用到的SAP功能, 實作策略等
3.必須在那個時間點交換那些資料物件
細部設計階段
產出 :
1. 資料物件的輸入與輸出
2. 取得一些樣本資料
3. Coding或客製化 (SAP and External System)
問題
1.有資料交換的標準解決方案? 如ALE, RFC and other middleware
2.評估使用的技術考量 : 資料量, Online or Batch, 同步或非同步, Monitoring/Recovery機制等
3.有沒有Sample Codes?
實作階段
產出 :
1. 介面程式設計
2. Test Scenarios
3. Test Reports
問題
1. 有否建立測試環境(含SAP, non-SAP)?
2. 那些流程要測試, 有那些Test Scenario?
3. 有足夠的測試資料以進行測試?
4. 任何錯誤的狀況應如何用文件加以記錄?
結論 :
因此, 整合設計應確認下面事項:
1. 定義經常且必須的介面Scenario
2. 找出管理上的限制
3. 找出技術上的限制
4. 列出Scenario上的資料物件
5. 描述每個物件的輸入輸出
6. 找出可能的替代方案
7. 找到每個替代方案與物件的sample codes
整合設計時除了商業流程整合之外, 還要考慮下面幾點:
1. 資料的一致性
2. 錯誤處理
3. 管理成本 (介面的管理是否容易)
4. 安全性
整合設計常出現的現象如下 :
1.多數的時間與成本花在定義與實作跨系統的流程與介面
2.不好的介面設計造成效能,資料一致性及管理上的問題
除了跨系統間的介面設計外還有許多問題需要思考的, 下面將整合設計粗分為三階段:
初部設計階段
產出 :
. 商業流程圖與描述
. 限制因素
. 資料物件 :
必須詳細瞭解交換的物件及物件在兩個系統間的差異, 除了意義上的差別, 在資料內容上也可能不同,必須考慮其轉換的方法
. 實作策略
問題 :
1.介面應建立在商業流程的那個地方?
2.有那些限制因素, 如non-SAP系統環境, 用到的SAP功能, 實作策略等
3.必須在那個時間點交換那些資料物件
細部設計階段
產出 :
1. 資料物件的輸入與輸出
2. 取得一些樣本資料
3. Coding或客製化 (SAP and External System)
問題
1.有資料交換的標準解決方案? 如ALE, RFC and other middleware
2.評估使用的技術考量 : 資料量, Online or Batch, 同步或非同步, Monitoring/Recovery機制等
3.有沒有Sample Codes?
實作階段
產出 :
1. 介面程式設計
2. Test Scenarios
3. Test Reports
問題
1. 有否建立測試環境(含SAP, non-SAP)?
2. 那些流程要測試, 有那些Test Scenario?
3. 有足夠的測試資料以進行測試?
4. 任何錯誤的狀況應如何用文件加以記錄?
結論 :
因此, 整合設計應確認下面事項:
1. 定義經常且必須的介面Scenario
2. 找出管理上的限制
3. 找出技術上的限制
4. 列出Scenario上的資料物件
5. 描述每個物件的輸入輸出
6. 找出可能的替代方案
7. 找到每個替代方案與物件的sample codes
整合設計時除了商業流程整合之外, 還要考慮下面幾點:
1. 資料的一致性
2. 錯誤處理
3. 管理成本 (介面的管理是否容易)
4. 安全性
2005年8月31日
應用系統整合層次
Fredwang 20050831 (fredwang.blogspot.com)
企業應用系統間如何整合，使用怎樣的整合層次往往與企業的規模，成長與發展過程，商業的需求及投資策略有關，下面是不同的整合層次
1. 系統間整合前 : 每個系統間的介面很少，每個系統就是一個”資訊孤島”，缺乏跨組織的流程，需人工重新輸入讓應用系統間的資料能一致。
2. 層次一 - 點對點的整合 : 使用API或資料同步化工具(如抄寫工具)建立點對點自訂的介面，以訊息導向的中介軟體來整合，系統間耦合性低。
3. 層次二 - 結構化整合 : 介面架構為Hub狀或星狀或Message bus等資訊集中式的架構，中介軟體包含訊息代理(message broker)或應用伺服器，中介軟體的功能包括 : 資料轉換及轉換規則處理，交易處理。這種層次又稱企業應用介面模型(EAI model)。
4. 層次三 - 流程整合 : 以層次二的架構為基礎，系統間的資訊不僅可以分享也可以管理，中介軟體包含流程自動模型化(modeling)工具，中介軟體的功能包括 : 工作流程整合，自動路徑安排(routing)等。
5. 層次四 - 外部整合，以層次三的架構為基礎，系統間有共同的網路基礎架構，如Internet，共同的資料標準，如XML，中介軟體的功能包括 : 交易安全機制，智慧代理程式，資料對映(mapping)等，一致的應用系統，如B2B或B2C
企業應用系統間如何整合，使用怎樣的整合層次往往與企業的規模，成長與發展過程，商業的需求及投資策略有關，下面是不同的整合層次
1. 系統間整合前 : 每個系統間的介面很少，每個系統就是一個”資訊孤島”，缺乏跨組織的流程，需人工重新輸入讓應用系統間的資料能一致。
2. 層次一 - 點對點的整合 : 使用API或資料同步化工具(如抄寫工具)建立點對點自訂的介面，以訊息導向的中介軟體來整合，系統間耦合性低。
3. 層次二 - 結構化整合 : 介面架構為Hub狀或星狀或Message bus等資訊集中式的架構，中介軟體包含訊息代理(message broker)或應用伺服器，中介軟體的功能包括 : 資料轉換及轉換規則處理，交易處理。這種層次又稱企業應用介面模型(EAI model)。
4. 層次三 - 流程整合 : 以層次二的架構為基礎，系統間的資訊不僅可以分享也可以管理，中介軟體包含流程自動模型化(modeling)工具，中介軟體的功能包括 : 工作流程整合，自動路徑安排(routing)等。
5. 層次四 - 外部整合，以層次三的架構為基礎，系統間有共同的網路基礎架構，如Internet，共同的資料標準，如XML，中介軟體的功能包括 : 交易安全機制，智慧代理程式，資料對映(mapping)等，一致的應用系統，如B2B或B2C
2005年8月17日
[推薦文章]Java能夠成爲完美的技術平臺嗎？
作者：wafd譯 來自：CSDN 2004/03/16
前言
像許多在不斷發展的平臺/語言一樣,Java讓很多程式師又愛又恨。當然，當然這不包括那些狂熱的Java愛好者，對於他們來說Java比.Net,LAMP或任何其他語言或平臺都要好,但是，我們還是不得不面對複雜的Swing，龐大的EJB規範等對硬體的額外要求以及J2ME的變化多端的實現方式等等等等。抛開以上這些Java的弱點，我們可以說Java是一個完美的技術平臺，那麽Java到底有沒有成爲一個完美的技術平臺的潛力呢？這篇文章將從兩個方面討論這一主題，開始，我會詳細的告訴你什麽是完美的技術平臺以及爲什麽Java平臺能夠成爲完美的技術平臺。之後我會偏重於具體的解決方案，如何通過設計的優化避免Java平臺的弱點。 ...
內容詳見Java能夠成爲完美的技術平臺嗎
感想(Fred) : 要了解一個技術, 只有熟悉技術的內容, 功能及優點是不夠的, 熟悉技術的限制與缺點才算真正的懂得這個技術. 唯有如此, 才能在這些限制下靈活的應用這個技術.
前言
像許多在不斷發展的平臺/語言一樣,Java讓很多程式師又愛又恨。當然，當然這不包括那些狂熱的Java愛好者，對於他們來說Java比.Net,LAMP或任何其他語言或平臺都要好,但是，我們還是不得不面對複雜的Swing，龐大的EJB規範等對硬體的額外要求以及J2ME的變化多端的實現方式等等等等。抛開以上這些Java的弱點，我們可以說Java是一個完美的技術平臺，那麽Java到底有沒有成爲一個完美的技術平臺的潛力呢？這篇文章將從兩個方面討論這一主題，開始，我會詳細的告訴你什麽是完美的技術平臺以及爲什麽Java平臺能夠成爲完美的技術平臺。之後我會偏重於具體的解決方案，如何通過設計的優化避免Java平臺的弱點。 ...
內容詳見Java能夠成爲完美的技術平臺嗎
感想(Fred) : 要了解一個技術, 只有熟悉技術的內容, 功能及優點是不夠的, 熟悉技術的限制與缺點才算真正的懂得這個技術. 唯有如此, 才能在這些限制下靈活的應用這個技術.
使用標準的Java Timer API執行Scheduled Job
FredWang (http://fredwang.blogspot.com)
2005/08/17
有些事情或技術沒有記下來, 時間一過就忘記了, 下次用到又要花許多時間回憶與研究, 因此用Blog做筆記作為備忘
第一節. 在Server端Stand-alone執行的Job
範例一 : 立即執行, 每三分鐘執行一次
/* class ReportGenerator */
package sche.*;
import java.util.Date;
import java.util.TimerTask;
public class ReportGenerator extends TimerTask {
public void run() {
Date now = new Date();
System.out.println("Generating report:"+now.getTime());
//TODO generate report
}
}
/* class MainApplication */
package sche.*;
import java.util.Date;
import java.util.Timer;
import java.util.TimerTask;
public class MainApplication {
public static void main(String[] args) {
Timer timer = new Timer();
Date now = new Date();
// 立即執行, 每三分鐘執行一次
timer.schedule(
new ReportGenerator(),
now,
1000 * 60 * 3
);
}
範例二 : 每週日午夜零時執行一次
/* class MainApplication */
package sche.*;
import java.util.Calendar;
import java.util.Date;
import java.util.Timer;
import java.util.TimerTask;
public class MainApplication {
public static void main(String[] args) {
Timer timer = new Timer();
Calendar date = Calendar.getInstance();
date.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
date.set(Calendar.HOUR, 0);
date.set(Calendar.MINUTE, 0);
date.set(Calendar.SECOND, 0);
date.set(Calendar.MILLISECOND, 0);
// 每週日午夜零時執行一次
timer.schedule(
new ReportGenerator(),
date.getTime(),
1000 * 60 * 60 * 24 * 7
);
}
註 : ReportGenerator程式不變
第二節. 用JSP來控制Job的啟動與關閉
/* 立即執行, 每三分鐘執行一次 */
package sche.*;
import java.util.Date;
import java.util.Timer;
import java.util.TimerTask;
public class TimerService {
Timer timer = new Timer();
public TimerService() { };
public void start() throws Exception {
Date now = new Date();
// 立即執行, 每三分鐘執行一次
timer.schedule(
new ReportGenerator(),
now,
1000 * 60 * 3
);
}
public void stop() throws Exception {
timer.cancel();
}
}
註 : ReportGenerator程式不變
JSP程式範例
1. scheControl.jsp : 根據application屬性, 顯示開始或停止的按鈕
<%@ page import="sche.*" %>
<form action="sche.jsp" method="post">
<%
TimerService service = (TimerService)application.getAttribute("timerService");
if(service == null) {
out.print("<input type=submit value='Start Service'>");
} else {
out.print("<input type=submit value='Stop Service'>");
}
%>
</form>
2. sche.jsp : 根據application屬性決定開始或停止
<%@ page contentType="text/html; charset=Big5" %>
<%@ page import="sche.*" %>
<%
TimerService service = (TimerService)application.getAttribute("timerService");
boolean isStart = true;
if(service == null) {
service = new TimerService();
application.setAttribute("timerService",service);
service.start();
System.out.println("Timer service is startup.");
} else {
service.stop();
isStart = false;
service = null;
application.removeAttribute("timerService");
System.out.println("Timer service is stop.");
}
%>
<html>
<body>
<%=(isStart?"start ok":"stop ok")%>
</body>
</html>
第三節 其他
其他進一步的做法有 :
1. 將TimerService改寫為服務多個Job的Service[2]
2. 利用Servlet Context Listerner來啟動與關閉Service (實作javax.servlet.ServletContextListener的contextInitialized() and contextDestoryed() [3]
3. 使用Quzrtz API建構功能更強大的Job-scheduling System, 例如: Persistence(持續性), 可以不因系統當機重開, 造成Jobs的消失, 且提供比Java Timer API更有彈性的定時驅動方式, 例如每週六及周日的中午12點才執行, 可以分別管理許多不同的Jobs與不同驅動方式(Triggers) [1]
參考 :
1. Dejan Bosanac, "OnJava.com : Java Scheduling in Java", 03/10/2004, http://www.onjava.com/lpt/a/4637
2. "一個簡單的timer service", http://66feifei.com/info_Print.asp?ArticleID=140
3. 徐榮勝, "如何在Web工程中實現任務計畫調度"
2005/08/17
有些事情或技術沒有記下來, 時間一過就忘記了, 下次用到又要花許多時間回憶與研究, 因此用Blog做筆記作為備忘
第一節. 在Server端Stand-alone執行的Job
範例一 : 立即執行, 每三分鐘執行一次
/* class ReportGenerator */
package sche.*;
import java.util.Date;
import java.util.TimerTask;
public class ReportGenerator extends TimerTask {
public void run() {
Date now = new Date();
System.out.println("Generating report:"+now.getTime());
//TODO generate report
}
}
/* class MainApplication */
package sche.*;
import java.util.Date;
import java.util.Timer;
import java.util.TimerTask;
public class MainApplication {
public static void main(String[] args) {
Timer timer = new Timer();
Date now = new Date();
// 立即執行, 每三分鐘執行一次
timer.schedule(
new ReportGenerator(),
now,
1000 * 60 * 3
);
}
範例二 : 每週日午夜零時執行一次
/* class MainApplication */
package sche.*;
import java.util.Calendar;
import java.util.Date;
import java.util.Timer;
import java.util.TimerTask;
public class MainApplication {
public static void main(String[] args) {
Timer timer = new Timer();
Calendar date = Calendar.getInstance();
date.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
date.set(Calendar.HOUR, 0);
date.set(Calendar.MINUTE, 0);
date.set(Calendar.SECOND, 0);
date.set(Calendar.MILLISECOND, 0);
// 每週日午夜零時執行一次
timer.schedule(
new ReportGenerator(),
date.getTime(),
1000 * 60 * 60 * 24 * 7
);
}
註 : ReportGenerator程式不變
第二節. 用JSP來控制Job的啟動與關閉
/* 立即執行, 每三分鐘執行一次 */
package sche.*;
import java.util.Date;
import java.util.Timer;
import java.util.TimerTask;
public class TimerService {
Timer timer = new Timer();
public TimerService() { };
public void start() throws Exception {
Date now = new Date();
// 立即執行, 每三分鐘執行一次
timer.schedule(
new ReportGenerator(),
now,
1000 * 60 * 3
);
}
public void stop() throws Exception {
timer.cancel();
}
}
註 : ReportGenerator程式不變
JSP程式範例
1. scheControl.jsp : 根據application屬性, 顯示開始或停止的按鈕
<%@ page import="sche.*" %>
<form action="sche.jsp" method="post">
<%
TimerService service = (TimerService)application.getAttribute("timerService");
if(service == null) {
out.print("<input type=submit value='Start Service'>");
} else {
out.print("<input type=submit value='Stop Service'>");
}
%>
</form>
2. sche.jsp : 根據application屬性決定開始或停止
<%@ page contentType="text/html; charset=Big5" %>
<%@ page import="sche.*" %>
<%
TimerService service = (TimerService)application.getAttribute("timerService");
boolean isStart = true;
if(service == null) {
service = new TimerService();
application.setAttribute("timerService",service);
service.start();
System.out.println("Timer service is startup.");
} else {
service.stop();
isStart = false;
service = null;
application.removeAttribute("timerService");
System.out.println("Timer service is stop.");
}
%>
<html>
<body>
<%=(isStart?"start ok":"stop ok")%>
</body>
</html>
第三節 其他
其他進一步的做法有 :
1. 將TimerService改寫為服務多個Job的Service[2]
2. 利用Servlet Context Listerner來啟動與關閉Service (實作javax.servlet.ServletContextListener的contextInitialized() and contextDestoryed() [3]
3. 使用Quzrtz API建構功能更強大的Job-scheduling System, 例如: Persistence(持續性), 可以不因系統當機重開, 造成Jobs的消失, 且提供比Java Timer API更有彈性的定時驅動方式, 例如每週六及周日的中午12點才執行, 可以分別管理許多不同的Jobs與不同驅動方式(Triggers) [1]
參考 :
1. Dejan Bosanac, "OnJava.com : Java Scheduling in Java", 03/10/2004, http://www.onjava.com/lpt/a/4637
2. "一個簡單的timer service", http://66feifei.com/info_Print.asp?ArticleID=140
3. 徐榮勝, "如何在Web工程中實現任務計畫調度"
2005年8月16日
轉貼 徐江屏的"傲慢與偏見"
請見徐江屏的Blog
讀到一篇張大春的文章，談的是批評別人不讀書的傲慢。不知怎地，總讓人想起李敖。這用功至勤但稱不上氣度廣闊的讀書家，總喜歡批評別人不讀書，死讀書，不會讀書，那理直氣壯的態度，相較之下，只能以自己真是如此而悶不吭聲，沈默以對。這究竟能不能看成是「知識的傲慢」，一時之間也說不上來，大家習慣了李敖式的謾罵，在實在拿不出比他更恢宏的知識背景，根本連批評反擊都談不上，只能小家子氣小聲地說諸如：「就算書讀得多也不用那麼刻薄」之類的話語末節批評，或敬而遠之，或忽略他所提出可能是很有見地的觀點或看法。反倒是如南方朔般淊淊說理氣定神閒，引得更多人的尊敬與推崇。終究是制錮在「中道」的民族，不偏不倚才是知識份子該有的態度，儒雅自持才是知識份子該有的風範。
可就有人不同意，艾德華．薩依德就以為，知識份子本來就該有自己的態度與看法，本就該為自我理念的實踐付出應有的心力，所以才有「丟石塊」事件。知識份子上街頭抗議公部門不當舉措與國家暴力發生衝突，又有什麼了不起呢？
這實在也不是什麼馴服或僕役能夠說明清楚的。威權時代的知識份子幾乎都是黨國的文宣機器，在國家機器前噤若寒蟬，能有勇氣向威權抗拒的能有幾人（也許就因此李敖現在說話才會這麼大聲：「你們又算是什麼東西！」）。而在這個意識型態對立的當下，站在兩端發言的學者專家，各自會得到支持者的叫好與掌聲，但激情之後究竟對論述的形成有多少幫助？如果避而不談什麼各擁其主的臆測思考，這其間又有多才知識辯駁中因著情緒而出的「傲慢與偏見」？
說傲慢太沈重，說偏見太平常，生活中相對瑣碎的零零總總，幾乎把一天的時間就要填滿，也沒少有氣力去追究到底讀了多少書才算有點水準，讀了那些書才算有些氣質。但總能看到一些睥睨的眼神，以為讀了些書就了不得，大放厥辭而不以為意，又容不下別人的意見，總認為他人所言不過是婦人之見。真要比較是比較不完的，談人生閱歷，閱人無數的總還有看錯人的時候。讀書千冊就以為與古今智慧交融並進，知識與智彗的積累早遠遠在眾人之上，恐怕也太高估了自己的能力。
古時形容知識份子的謙沖態度，總以「溫文儒雅」形容。那翩翩的風範，不免又讓人懷想著玩弄竹雕雅飾的脫俗樣貌，不論世事，不與政爭，仙風道骨，不食人間煙火，那是象牙塔裏自我保護的清高模樣，只求自我學識的飽脹，不管塵世俗務，不管百姓死活。說傲慢有些誇張，卻也點出擁知識而自重的偏誤心態。除非術業專攻，以市井小民每日營生的困頓境地，能以閱讀為樂已是難得的癖好，談不上以學富五車而敝帚自珍，孤傲起來。怕的卻是學有專精卻吝於與人分享成就，自我隔離而斷絕所有對話的可能，孤傲到了不可一世的地步，而失落恐非三句兩言得以形容。更不要提經國淑世的寬闊襟懷，報國衛民，擁護個人的基本權利而強悍堅持不懼強權的入世精神，將如何動人了。
傲慢與偏見當然會如影隨形，亦步亦趨地跟隨。對知識份子的不與人交，自視甚高，那付醜態，無比厭人。這是偏見，以為知識份子就必然扛著知識的大鼎，不喜與人為善，依附於國家強權之下，趨炎附勢。知識才有力量，卻是鞏固國家權力的御用力量，將自己的人格放在地上踐踏。那是威權時代的知識份子了。許多為民主改革社會再造付出畢生精力的知識份子，所在多有，絲毫看不到任何傲慢與偏見的痕跡。放棄那些先入為主的印象與觀念，重新感受知識的力量，才會有真實的感動。
反而是半吊子的愛書人，讀了幾冊書後就自以為專家，四處賣弄所學的結果，往往是暴露了自己的拙劣容顏，也褻瀆了知識的莊嚴。那種傲慢，反而遲滯了再向前進的步子，那股莫名的偏見，遮掩了觀照全局的視野。故步自封，無以為甚。
再回望那老派的知識份子，為了那份對人的熱愛，對自由與尊嚴的必要堅持，對知識所抱持的尊重態度，讀了這幾冊書又算得了什麼？謙卑地躲在書房裏，踏著前人智慧累積所舖陳的路子，試著走出一條自己的路。觀照四週的風光山水，向著莊嚴的殿堂走去。傲慢與偏見，就不必了！（2002/11/7）
讀到一篇張大春的文章，談的是批評別人不讀書的傲慢。不知怎地，總讓人想起李敖。這用功至勤但稱不上氣度廣闊的讀書家，總喜歡批評別人不讀書，死讀書，不會讀書，那理直氣壯的態度，相較之下，只能以自己真是如此而悶不吭聲，沈默以對。這究竟能不能看成是「知識的傲慢」，一時之間也說不上來，大家習慣了李敖式的謾罵，在實在拿不出比他更恢宏的知識背景，根本連批評反擊都談不上，只能小家子氣小聲地說諸如：「就算書讀得多也不用那麼刻薄」之類的話語末節批評，或敬而遠之，或忽略他所提出可能是很有見地的觀點或看法。反倒是如南方朔般淊淊說理氣定神閒，引得更多人的尊敬與推崇。終究是制錮在「中道」的民族，不偏不倚才是知識份子該有的態度，儒雅自持才是知識份子該有的風範。
可就有人不同意，艾德華．薩依德就以為，知識份子本來就該有自己的態度與看法，本就該為自我理念的實踐付出應有的心力，所以才有「丟石塊」事件。知識份子上街頭抗議公部門不當舉措與國家暴力發生衝突，又有什麼了不起呢？
這實在也不是什麼馴服或僕役能夠說明清楚的。威權時代的知識份子幾乎都是黨國的文宣機器，在國家機器前噤若寒蟬，能有勇氣向威權抗拒的能有幾人（也許就因此李敖現在說話才會這麼大聲：「你們又算是什麼東西！」）。而在這個意識型態對立的當下，站在兩端發言的學者專家，各自會得到支持者的叫好與掌聲，但激情之後究竟對論述的形成有多少幫助？如果避而不談什麼各擁其主的臆測思考，這其間又有多才知識辯駁中因著情緒而出的「傲慢與偏見」？
說傲慢太沈重，說偏見太平常，生活中相對瑣碎的零零總總，幾乎把一天的時間就要填滿，也沒少有氣力去追究到底讀了多少書才算有點水準，讀了那些書才算有些氣質。但總能看到一些睥睨的眼神，以為讀了些書就了不得，大放厥辭而不以為意，又容不下別人的意見，總認為他人所言不過是婦人之見。真要比較是比較不完的，談人生閱歷，閱人無數的總還有看錯人的時候。讀書千冊就以為與古今智慧交融並進，知識與智彗的積累早遠遠在眾人之上，恐怕也太高估了自己的能力。
古時形容知識份子的謙沖態度，總以「溫文儒雅」形容。那翩翩的風範，不免又讓人懷想著玩弄竹雕雅飾的脫俗樣貌，不論世事，不與政爭，仙風道骨，不食人間煙火，那是象牙塔裏自我保護的清高模樣，只求自我學識的飽脹，不管塵世俗務，不管百姓死活。說傲慢有些誇張，卻也點出擁知識而自重的偏誤心態。除非術業專攻，以市井小民每日營生的困頓境地，能以閱讀為樂已是難得的癖好，談不上以學富五車而敝帚自珍，孤傲起來。怕的卻是學有專精卻吝於與人分享成就，自我隔離而斷絕所有對話的可能，孤傲到了不可一世的地步，而失落恐非三句兩言得以形容。更不要提經國淑世的寬闊襟懷，報國衛民，擁護個人的基本權利而強悍堅持不懼強權的入世精神，將如何動人了。
傲慢與偏見當然會如影隨形，亦步亦趨地跟隨。對知識份子的不與人交，自視甚高，那付醜態，無比厭人。這是偏見，以為知識份子就必然扛著知識的大鼎，不喜與人為善，依附於國家強權之下，趨炎附勢。知識才有力量，卻是鞏固國家權力的御用力量，將自己的人格放在地上踐踏。那是威權時代的知識份子了。許多為民主改革社會再造付出畢生精力的知識份子，所在多有，絲毫看不到任何傲慢與偏見的痕跡。放棄那些先入為主的印象與觀念，重新感受知識的力量，才會有真實的感動。
反而是半吊子的愛書人，讀了幾冊書後就自以為專家，四處賣弄所學的結果，往往是暴露了自己的拙劣容顏，也褻瀆了知識的莊嚴。那種傲慢，反而遲滯了再向前進的步子，那股莫名的偏見，遮掩了觀照全局的視野。故步自封，無以為甚。
再回望那老派的知識份子，為了那份對人的熱愛，對自由與尊嚴的必要堅持，對知識所抱持的尊重態度，讀了這幾冊書又算得了什麼？謙卑地躲在書房裏，踏著前人智慧累積所舖陳的路子，試著走出一條自己的路。觀照四週的風光山水，向著莊嚴的殿堂走去。傲慢與偏見，就不必了！（2002/11/7）
2005年8月12日
優質Blog介紹之一
1. EVHEAD
站主 : Evan Williams
開站日期 : 1999/02
說明 : 這是Blog元老級的人物的網站
網址 : http://www.evhead.com/
語言 : 英文
2. 中文網誌組織(CNBlog)
站主 :
開站日期 : 2002/10
說明 : 許多中國Blog老手的共同創作園地
網址 : http://www.cnblog.org
語言 : 簡體中文
3. Zonble's promptbook
站主 : Zonble
開站日期 : 2003/01
說明 : 一個有特色有個性的Blog, 也有不少技術文章
網址 : http://zonble.twbbs.org/
語言 : 正體中文
4. Judysmile Experimental Blog
站主 : Judy
開站日期 : 2002/08
說明 : 生活記事的網站, 頗有特色
網址 : http://blog.yam.com/judysmile
語言 : 正體中文
5. 中時電子報編輯部落格
站主 :
開站日期 :
說明 :
網址 : http://blog.chinatimes.com/
語言 : 正體中文
站主 : Evan Williams
開站日期 : 1999/02
說明 : 這是Blog元老級的人物的網站
網址 : http://www.evhead.com/
語言 : 英文
2. 中文網誌組織(CNBlog)
站主 :
開站日期 : 2002/10
說明 : 許多中國Blog老手的共同創作園地
網址 : http://www.cnblog.org
語言 : 簡體中文
3. Zonble's promptbook
站主 : Zonble
開站日期 : 2003/01
說明 : 一個有特色有個性的Blog, 也有不少技術文章
網址 : http://zonble.twbbs.org/
語言 : 正體中文
4. Judysmile Experimental Blog
站主 : Judy
開站日期 : 2002/08
說明 : 生活記事的網站, 頗有特色
網址 : http://blog.yam.com/judysmile
語言 : 正體中文
5. 中時電子報編輯部落格
站主 :
開站日期 :
說明 :
網址 : http://blog.chinatimes.com/
語言 : 正體中文
2005年8月5日
Blog的發展, 證明了知識經濟的偉大
Blog的發展, 證明了知識經濟的偉大, 大家可以透過網路分享自己的所知所學與心得, 從網路上學習知識也無私的分享給他人, 在這裡不管身分地位學歷背景大家一律平等, 不管見解是否成熟想法是否正確, 大家可以自由的發表言論(合法範圍內).
可笑的是, 在Blog蓬勃發展的今日, 還有人無法了解這些真義, 曲解知識經濟, 將別人發表的的文章視為炫耀性的行為, Peter Senge 第五項修練提到學習性組織, 透過團隊學習可以提升組織的競爭力, 而學習性組織中沒有職位高低之分, 也沒有聞道先後與術業專攻的問題, 大家互相貢獻所學所知, 沒有炫耀與等級, 如此才可以拋開成見, 看到更廣的視野, 一人所知所學, 無法像團隊學習來的廣泛, 一人所見到的問題也不如團隊所看到的問題哪麼全面.
許多專業人員常常陷入專業的盲點, 而無法以更寬廣的角度, 看事情及與人相處, 這在另一篇文章有提到(" 專業的危機，來自於盲目的自信" http://fredwang.blogspot.com/2005/05/blog-post_24.html) 這就是說過於專注與自信, 往往無法接受自己所專注的事物與見解之外的事物與見解.
廣大的Blog作家們, 默默的為知識經濟貢獻著, 而這股潮流將讓這個冷漠, 自私與功利的世界有所不同, 例如, 南亞海嘯的報導透過Blog讓大家更快速的了解到狀況, 並透過許多的共同作者與回應號召援助. 而這群人正不停的增加中.
-- Fred Wang
可笑的是, 在Blog蓬勃發展的今日, 還有人無法了解這些真義, 曲解知識經濟, 將別人發表的的文章視為炫耀性的行為, Peter Senge 第五項修練提到學習性組織, 透過團隊學習可以提升組織的競爭力, 而學習性組織中沒有職位高低之分, 也沒有聞道先後與術業專攻的問題, 大家互相貢獻所學所知, 沒有炫耀與等級, 如此才可以拋開成見, 看到更廣的視野, 一人所知所學, 無法像團隊學習來的廣泛, 一人所見到的問題也不如團隊所看到的問題哪麼全面.
許多專業人員常常陷入專業的盲點, 而無法以更寬廣的角度, 看事情及與人相處, 這在另一篇文章有提到(" 專業的危機，來自於盲目的自信" http://fredwang.blogspot.com/2005/05/blog-post_24.html) 這就是說過於專注與自信, 往往無法接受自己所專注的事物與見解之外的事物與見解.
廣大的Blog作家們, 默默的為知識經濟貢獻著, 而這股潮流將讓這個冷漠, 自私與功利的世界有所不同, 例如, 南亞海嘯的報導透過Blog讓大家更快速的了解到狀況, 並透過許多的共同作者與回應號召援助. 而這群人正不停的增加中.
-- Fred Wang
2005年7月29日
程式設計功力提升的方法與Joel on Software網站
作者 : Fred (Hainchu-Taiwan) 日期: 2005/7/29
每天沒日沒夜的寫程式, 這樣過了幾年, 程式設計的功力, 真正就會自然提升嗎?
我想這是很困難的, 如同每天造橋鋪路, 過了幾年就可以蓋大樓了嗎? 砌磚久了就可以變成建築師了嗎?
我想提升程式功力, 不外乎幾個方向 :
1.實作中學習, 解決實作過程中的任何問題, 但是成功的完成每個專案, 不表示您的程式品質就好
2.深入的程式技巧學習, 例如Design Patterns, Programming styles, Refactoring Technology等等, 多看書, 多練習, 將這些東西真正變成您程式設計的習慣
3.縱向的學習, 程式設計的上下游的東西, 如系統分析, 架構設計, 細部設計, 資料模型, 系統測試, 軟體品質衡量, 軟體專案管理, 等等, 為什麼要了解這些東西, 例如: 架構設計, 架構的選擇將影響程式設計很大, 軟體品質的程式再用性,可擴充性, 可移植性, 甚至使用者要求的系統效能需求, 都可能牽涉到非常複雜的程式設計技術與技巧. 如果能夠提升縱向的視野, 當然有助能力的提升
另外推薦Joel on Software網站, 好好看看, 有助程式設計素養的提升
內容有:
程式師的使用介面設計手冊
讓錯的程式看得出錯
無痛錯誤追蹤
無痛功能規格
約耳測試: 邁向高品質的12個步驟
無痛軟體時程
軟體人員面試教戰守則
2005年7月26日
2005年7月25日
SAP Web Dynpro 專案開發程序
Fred Wang(http://fredwang.blogspot.com) 2005/07/25
SAP Web Dynpro是一套快速建構的Java Web Application Framework, 在SAP Netweaver Developer Studio的開發環境中提供特有Component-Based的MVC架構 。
不過，網路上鮮少文獻或討論有關使用Web Dynpro開發Web Application完整的軟體工程方法或程序。在SAP出版, Chris Whealy, “Inside Web Dynpro for Java”書中, 第27-31頁僅以五頁的篇幅描述這個程序。對於多數開發者而言，一個新的架構，需要更多的時間，更多的學習資訊協助以了解Web Dynpro如何用在真實的應用專案中。下面是筆者近幾個月開發Web Dynpro專案整理的一些心得筆記，希望對準備學習或使用Web Dynpro的人有所幫助。也歡迎先進給予指正。
需求分析
Web Dynpro開發專案的分析階段應該與Web Dynpro的技術無關，建議可採用UML的技術來描述系統需求。
架構設計
架構設計階段則與系統規模，非功能需求如可靠度，可擴充性等有關，例如: 是否使用異質資料庫，是否分散式處理，效能需求的要求如何，是否採用Design Patterns，採用何種Design Patterns，採用哪些基礎性與平台性的APIs, 例如: Logging , Exception Handling, Authentication,
Authorization, Asynchronous Processing, Scheduling, Configuration, Messaging等。 採用哪應用APIs, 例如 : Workflow, Reporting, Content Management, Transaction等。 另外使否使用JDI, 是否整合SAP Portal, 是否與其他Project互相整合等。
細部設計與實作程序
第一 使用者介面設計與系統雛形(Prototyping)
1. 根據Activity Diagram中的畫面建立View : 可以一個畫面建立一個View或多個類似的畫面共用一個View
1.1 View中進行畫面設計, 表格, 欄位, 按鈕等
1.2 建立畫面所需Binding的Context nodes and value attributes，並設定UI elements property的binding關係
1.3 若Context nodes或attributes需要跨Views來使用，則要在Component Controller複製相同的若Context nodes或attributes，並用Data Modeler(Component Diagram)建立Context mapping。
1.4 若是共用的View則應增加一些value attributes並bind到特定UI元件的read-only, enabled, visible等欄位, 來控制這些View在不同的狀況下可否輸入，是否顯示等。
2. 建立View間的Navigation關係 : 建立Window, 在Window Diagram建立View的Inbound plug與Outbound plug及連結關係
2.1 若Inbound Plug與Outbound Plug間要傳遞參數, 則兩者都需建立相同名稱的參數
2.2 找出Trigger Outbound Plug的UI元件，建立Event Handler，並指定Outbound Plug
2.3 要注意，畫面除了有進入的Inbound Plug，也應該要有返回的Outbound Plug，因此也要指定一個UI元件來啟動Outbound Plug
2.4 若View為多個功能畫面共用，則在Inbound Plug Method中根據不同的參數或不同的Inbound plug，設定畫面的read-only, enabled, visible (透過value attributes)
3. 使用者進行介面測試 : 完成上面的程序，畫面的Navigation已接近完成，此時可以與使用者進行介面測試，確認畫面樣式與畫面操作流程是否正確。
3.1 此時可以在Context node的supply function中，設定一些測試資料，以利操作過程中雛型的測試。
3.2 完成上面的程序可以提早在此階段與使用者確定規格，避免在開發的後期才更改規格, 造成專案進度更大的影響。
第二 商業功能設計與單元測試
1. 完成每個商業功能
1.1 畫面顯示前的處理, 在wdDoInit()或onPlugXXX() (Inbound Plug)中的商業處理
1.2 商業功能處理, 每一個會Trigger Event的UI元件，實作這些Event的Event Handler功能
1.3 Context Node的Supply Function，若與Data Model整合可以到後面資料模型設計階段來處理。
2. 這階段，可能有自行開發的程式，採用外界的APIs, 或自訂的公用APIs， 盡量可以讓程式高度模組化，提高程式的可再用性。
3. 如果使用者前端設計及商業功能設計為不同開發人員，則負責商業功能設計的開發人員需撰寫單元測試程式進行商業功能的單元測試，一般採用JUnit測試架構。
第三 資料模型設計與整合測試
1. 建立Database Tables
2. Data Model可以用不同的方式實作
2.1 Java Bean : 用EJB or POJOs(DAO design pattern)
2.2 Web Service
2.3 SAP RFC Function
3. 將Data Model Map到View Context Node或Component Controller的Context Node
4. 進行整合測試
4.1 此時的測試就是包含Data Model, Business Function與UI設計的整合測試。
SAP Web Dynpro是一套快速建構的Java Web Application Framework, 在SAP Netweaver Developer Studio的開發環境中提供特有Component-Based的MVC架構 。
不過，網路上鮮少文獻或討論有關使用Web Dynpro開發Web Application完整的軟體工程方法或程序。在SAP出版, Chris Whealy, “Inside Web Dynpro for Java”書中, 第27-31頁僅以五頁的篇幅描述這個程序。對於多數開發者而言，一個新的架構，需要更多的時間，更多的學習資訊協助以了解Web Dynpro如何用在真實的應用專案中。下面是筆者近幾個月開發Web Dynpro專案整理的一些心得筆記，希望對準備學習或使用Web Dynpro的人有所幫助。也歡迎先進給予指正。
需求分析
Web Dynpro開發專案的分析階段應該與Web Dynpro的技術無關，建議可採用UML的技術來描述系統需求。
架構設計
架構設計階段則與系統規模，非功能需求如可靠度，可擴充性等有關，例如: 是否使用異質資料庫，是否分散式處理，效能需求的要求如何，是否採用Design Patterns，採用何種Design Patterns，採用哪些基礎性與平台性的APIs, 例如: Logging , Exception Handling, Authentication,
Authorization, Asynchronous Processing, Scheduling, Configuration, Messaging等。 採用哪應用APIs, 例如 : Workflow, Reporting, Content Management, Transaction等。 另外使否使用JDI, 是否整合SAP Portal, 是否與其他Project互相整合等。
細部設計與實作程序
第一 使用者介面設計與系統雛形(Prototyping)
1. 根據Activity Diagram中的畫面建立View : 可以一個畫面建立一個View或多個類似的畫面共用一個View
1.1 View中進行畫面設計, 表格, 欄位, 按鈕等
1.2 建立畫面所需Binding的Context nodes and value attributes，並設定UI elements property的binding關係
1.3 若Context nodes或attributes需要跨Views來使用，則要在Component Controller複製相同的若Context nodes或attributes，並用Data Modeler(Component Diagram)建立Context mapping。
1.4 若是共用的View則應增加一些value attributes並bind到特定UI元件的read-only, enabled, visible等欄位, 來控制這些View在不同的狀況下可否輸入，是否顯示等。
2. 建立View間的Navigation關係 : 建立Window, 在Window Diagram建立View的Inbound plug與Outbound plug及連結關係
2.1 若Inbound Plug與Outbound Plug間要傳遞參數, 則兩者都需建立相同名稱的參數
2.2 找出Trigger Outbound Plug的UI元件，建立Event Handler，並指定Outbound Plug
2.3 要注意，畫面除了有進入的Inbound Plug，也應該要有返回的Outbound Plug，因此也要指定一個UI元件來啟動Outbound Plug
2.4 若View為多個功能畫面共用，則在Inbound Plug Method中根據不同的參數或不同的Inbound plug，設定畫面的read-only, enabled, visible (透過value attributes)
3. 使用者進行介面測試 : 完成上面的程序，畫面的Navigation已接近完成，此時可以與使用者進行介面測試，確認畫面樣式與畫面操作流程是否正確。
3.1 此時可以在Context node的supply function中，設定一些測試資料，以利操作過程中雛型的測試。
3.2 完成上面的程序可以提早在此階段與使用者確定規格，避免在開發的後期才更改規格, 造成專案進度更大的影響。
第二 商業功能設計與單元測試
1. 完成每個商業功能
1.1 畫面顯示前的處理, 在wdDoInit()或onPlugXXX() (Inbound Plug)中的商業處理
1.2 商業功能處理, 每一個會Trigger Event的UI元件，實作這些Event的Event Handler功能
1.3 Context Node的Supply Function，若與Data Model整合可以到後面資料模型設計階段來處理。
2. 這階段，可能有自行開發的程式，採用外界的APIs, 或自訂的公用APIs， 盡量可以讓程式高度模組化，提高程式的可再用性。
3. 如果使用者前端設計及商業功能設計為不同開發人員，則負責商業功能設計的開發人員需撰寫單元測試程式進行商業功能的單元測試，一般採用JUnit測試架構。
第三 資料模型設計與整合測試
1. 建立Database Tables
2. Data Model可以用不同的方式實作
2.1 Java Bean : 用EJB or POJOs(DAO design pattern)
2.2 Web Service
2.3 SAP RFC Function
3. 將Data Model Map到View Context Node或Component Controller的Context Node
4. 進行整合測試
4.1 此時的測試就是包含Data Model, Business Function與UI設計的整合測試。
2005年7月14日
應用系統該如何選擇使用哪些J2EE Design Pattern?
應用系統該如何選擇使用哪些J2EE Design Pattern?
Fred Wang(http://fredwang.blogspot.com)
方法如下 :
1.依照樣式(Pattern)的目的加以分類
例如Presentation Tier的樣式可以加以分類如下:
. Intercepting Filter, Front Controller, Context Object and Application Controller: 用來處理需求, 或將需求轉交商業服務來處理。都是處理需求但是實際應用上略有差異。
. View Helper, Composite View : 都是用來將回應或需求處理的結果加以呈現
. Service to Worker, Dispatcher View : 從需求處理, 商業邏輯呼叫及View的呈現的架構
2. 了解每一種樣式要解決的問題與適用範圍
例如Service Activator專門用於非同步服務的呼叫。Session Facade用於使用EJB提供遠端商業服務的狀況。
3. 閱讀每個樣式的描述, 解決方案。特別要了解其Class Diagram and Sequence Diagram。
4. 找出樣式間的關係
例如 : Session Facade, Application Service與Business Objects間的關係, Front Controller, Context Object與Application Controller間的關係。
5. 系統可變因素是甚麼? 在不需重新設計下如何讓系統有更高的可擴充性:
例如 : 設計的樣式是否考慮不同的網路協定, 使用端的環境, 是否支援不同的資料庫。簡單而言, 您的系統可否增加Rich Client, Mobile Client, 是否可以增加另一種資料庫的存取。
6. 與第5點相反的就是訂出什麼狀況會造成系統要重新設計 :
例如 : 商業處理由POJOs提供服務, 增加EJB的遠端商業服務時, 系統是否要重新設計? 增加一種後端系統(Backend)存取需求時，系統是否要重新設計? (只要增加處理的元件而既有的元件仍可再用)
參考 : Craig A. Berry, John Carnell..etc, "J2EE Design Patterns Applied"
Fred Wang(http://fredwang.blogspot.com)
方法如下 :
1.依照樣式(Pattern)的目的加以分類
例如Presentation Tier的樣式可以加以分類如下:
. Intercepting Filter, Front Controller, Context Object and Application Controller: 用來處理需求, 或將需求轉交商業服務來處理。都是處理需求但是實際應用上略有差異。
. View Helper, Composite View : 都是用來將回應或需求處理的結果加以呈現
. Service to Worker, Dispatcher View : 從需求處理, 商業邏輯呼叫及View的呈現的架構
2. 了解每一種樣式要解決的問題與適用範圍
例如Service Activator專門用於非同步服務的呼叫。Session Facade用於使用EJB提供遠端商業服務的狀況。
3. 閱讀每個樣式的描述, 解決方案。特別要了解其Class Diagram and Sequence Diagram。
4. 找出樣式間的關係
例如 : Session Facade, Application Service與Business Objects間的關係, Front Controller, Context Object與Application Controller間的關係。
5. 系統可變因素是甚麼? 在不需重新設計下如何讓系統有更高的可擴充性:
例如 : 設計的樣式是否考慮不同的網路協定, 使用端的環境, 是否支援不同的資料庫。簡單而言, 您的系統可否增加Rich Client, Mobile Client, 是否可以增加另一種資料庫的存取。
6. 與第5點相反的就是訂出什麼狀況會造成系統要重新設計 :
例如 : 商業處理由POJOs提供服務, 增加EJB的遠端商業服務時, 系統是否要重新設計? 增加一種後端系統(Backend)存取需求時，系統是否要重新設計? (只要增加處理的元件而既有的元件仍可再用)
參考 : Craig A. Berry, John Carnell..etc, "J2EE Design Patterns Applied"
2005年7月13日
[推薦文章]e天下: 席捲企業的新勢力！Blog Inc.
根據部落格搜尋引擎Technorati指出，部落格以每天新增2萬3,000個的驚人速度成長，甚至迫使企業必須開始改變遊戲規則。美國《財星》（Fortune）雜誌則將部落格列為2005年度十大趨勢之首。微軟董事長比爾‧蓋茲更指出，部落格是繼e-mail、BBS、即時訊息（如MSN Messenger）之後，第四個改變世界的網路殺手級應用。...
根據美國網路調查機構Perseus估計，全球部落格的數量5年內數量成長超過1,000倍，從2000年的2.95萬個，快速成長到今年第一季的3,160萬個，到今年底，預估全球部落格數量將達到5,340萬個。...
http://www.techvantage.com.tw/content/055/055082.asp
2005年7月12日
J2EE Design Pattern : Service Activator筆記
J2EE Design Pattern : Service Activator筆記
正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
- 需要呼叫非同步的服務，如: Mail Service, Order Processing等, 這些服務因為處理時間較長或耗用資源較大等因素, 無法在短時間內完成並提供即時的回應。另外部分Business processing可能跨應用系統, 可能整合企業內外的應用系統, 而這些較長的處理不適合讓客戶端等待商業處理的完成。
重點 :
. 以非同步的方式叫用商業服務, POJOs(Plain Old Java Objexts,傳統Java物件)或EJB元件。
. 整合出版/訂閱及點對點通訊來啟動非同步處理服務。
. 執行的商業工作是由許多的商業工作(business tasks)所組成。
解決方案
- 使用Service Activator來接收非同步需求並呼叫一個或多個商業服務。
Service Activator實作成一個JMS Listener用來監聽並接收JMS訊息。如果你的應用系統使用EJB元件且EJB Container(Web Application Server)支援EJB 2.0以上的版本，則可以使用Message-Drivern bean(MDB)來接收非同步需求，否則就必須自己撰寫Java Message Service(JMS)。
步驟 :
1. 需求端建立並送出一個訊息給Service Activator
2. Service Activator收到此訊息並解析,轉譯這個需求
3. Service Activatorr必須指定正確的商業服務元件並呼叫它來處理這個需求(非同步)
4. 處理完成後, 需求端可能需要接收結果。為了要通知需求端這個處理的結果，Service Activator可以將回應訊息送回給需求端。這個回應訊息可能是告訴需求端處理是否成功並提供結果。也可能有處理失敗的狀況，此時回應訊息就包含造成失敗的細節，這個細節可能指出需求端如何回復，是否要重新送出需求或修正造成錯誤的因素來進行回復處理。
此Pattern參與的成員與責任 :
. Client(需求端) : 需要對商業服務發出非同步處理的需求，可能是各種型態的應用系統元件，如POJO或EJB元件，必須可以建立並發送JMS訊息。
註 : 當舊系統(Legacy System)為需求端時，Java應用系統可以代替舊系統作為訊息的產生器。這個舊系統可能不是用Java，而是與訊息導向的中介軟體(middleware)整合來發送與接收訊息。而Java應用系統中的Service Activator可以接收來自這些舊系統的需求訊息並進行非同步的處理。
. Request : 需求端產生的訊息物件, 透過Message-oriented middleware(MOM)送給Service Activator。必須實作javax.jms.Message interface.訊息型態有TextMessage, ObjectMessage等。
. Service Activator : 實作javax.jms.MessageListener,其中onMessage() method, 在訊息收到後會被啟動。Service Activator用來解析此訊息並決定要完成的事情。通常使用Service Locator找到並建立BusinessService元件。
. BusinessService : 進行同步處理的目標物件滿足需求端的商業需求，通常為Session Facade 或Application Service, 詳細的商業邏輯可能再封裝於商業物件(Business Object)。
. Response : 也是一個訊息物件, 由Service Activator或BusinessService建立並傳送, 這個Response可能是一個確認訊息，讓需求端知道Request已經被收到, Response也可能是非同步處理的結果。
Class Diagram :
參考 :
http://www.corej2eepatterns.com/Patterns2ndEd/ServiceActivator.htm
正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
- 需要呼叫非同步的服務，如: Mail Service, Order Processing等, 這些服務因為處理時間較長或耗用資源較大等因素, 無法在短時間內完成並提供即時的回應。另外部分Business processing可能跨應用系統, 可能整合企業內外的應用系統, 而這些較長的處理不適合讓客戶端等待商業處理的完成。
重點 :
. 以非同步的方式叫用商業服務, POJOs(Plain Old Java Objexts,傳統Java物件)或EJB元件。
. 整合出版/訂閱及點對點通訊來啟動非同步處理服務。
. 執行的商業工作是由許多的商業工作(business tasks)所組成。
解決方案
- 使用Service Activator來接收非同步需求並呼叫一個或多個商業服務。
Service Activator實作成一個JMS Listener用來監聽並接收JMS訊息。如果你的應用系統使用EJB元件且EJB Container(Web Application Server)支援EJB 2.0以上的版本，則可以使用Message-Drivern bean(MDB)來接收非同步需求，否則就必須自己撰寫Java Message Service(JMS)。
步驟 :
1. 需求端建立並送出一個訊息給Service Activator
2. Service Activator收到此訊息並解析,轉譯這個需求
3. Service Activatorr必須指定正確的商業服務元件並呼叫它來處理這個需求(非同步)
4. 處理完成後, 需求端可能需要接收結果。為了要通知需求端這個處理的結果，Service Activator可以將回應訊息送回給需求端。這個回應訊息可能是告訴需求端處理是否成功並提供結果。也可能有處理失敗的狀況，此時回應訊息就包含造成失敗的細節，這個細節可能指出需求端如何回復，是否要重新送出需求或修正造成錯誤的因素來進行回復處理。
此Pattern參與的成員與責任 :
. Client(需求端) : 需要對商業服務發出非同步處理的需求，可能是各種型態的應用系統元件，如POJO或EJB元件，必須可以建立並發送JMS訊息。
註 : 當舊系統(Legacy System)為需求端時，Java應用系統可以代替舊系統作為訊息的產生器。這個舊系統可能不是用Java，而是與訊息導向的中介軟體(middleware)整合來發送與接收訊息。而Java應用系統中的Service Activator可以接收來自這些舊系統的需求訊息並進行非同步的處理。
. Request : 需求端產生的訊息物件, 透過Message-oriented middleware(MOM)送給Service Activator。必須實作javax.jms.Message interface.訊息型態有TextMessage, ObjectMessage等。
. Service Activator : 實作javax.jms.MessageListener,其中onMessage() method, 在訊息收到後會被啟動。Service Activator用來解析此訊息並決定要完成的事情。通常使用Service Locator找到並建立BusinessService元件。
. BusinessService : 進行同步處理的目標物件滿足需求端的商業需求，通常為Session Facade 或Application Service, 詳細的商業邏輯可能再封裝於商業物件(Business Object)。
. Response : 也是一個訊息物件, 由Service Activator或BusinessService建立並傳送, 這個Response可能是一個確認訊息，讓需求端知道Request已經被收到, Response也可能是非同步處理的結果。
Class Diagram :
參考 :
http://www.corej2eepatterns.com/Patterns2ndEd/ServiceActivator.htm
J2EE Design Pattern : Application Controller筆記
J2EE Design Pattern : Application Controller筆記
正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
. 將Action與View的管理集中化與模組化
在展示層中在接收到需求後有兩件主要的工作 :
. 第一, 收到的需求由特定的Action來提供服務, 稱為Action Management
. 第二, 控制權轉交給適當的View, 稱為View Management
這些也可以集中在Front Controller處理, 但是當應用系統及程式複雜時，最好將這些行為移到不同的classes以提高程式的模組化，重用性及擴充性。
重點:
. 重用(reuse)action與view management的程式碼
. 提升需求控管的可擴充性, 例如逐漸將Use case的功能加到應用系統內。
. 提升程式碼的模組化及可維護性, 更容易擴充您的應用系統, 更容易測試你每一部份的需求控管程式, 而這些程式與Web Container是不相關的(與Web Contrainer相關的需求管控在Front Controller完成)。
解決方案 :
- 使用一個Application Controller集中需求處理元件(如Commands與Views)的擷取與呼叫
註 : 真正處理需求及展現結果的元件不是Application Controller, 而是Commands與Views, Application Controller可以視為根據需求找到對應處理的Command(或Action), 並分派給合適的View來處理要呈現的結果。
將這些程式碼從Front Controller分離的好處有 :
1. 從Front Controller中與特定網路協定相關的程式碼分離以提升程式模組化與重用性, 例如特定的application controller元件可以提供給許多的channels(如web application與web service)重複使用來控管需求。這些控管有資料驗證(Validation), error handling, authentication, 存取控制(access control)等。
2. 與Servlet-based Front Controller分離以便於在Web container外進行測試
註 : Application Controller內部會有與Servlet及Web Container有關的API呼叫, 因此, 程式設計師進行這部份功能的單元測試就不一定要與未來執行環境相同(不需用相同的Web Container)
Pattern內的成員及責任
. Client(需求端) : 負責呼叫Application Controller, 通常維Front Controller或Intercepting Filter
. Application Controller : 使用Mapper解決收到的需求及對應的Action及View之間委派(Delegate)或分派(Dispatch)
註 : Delegate與Dispatch不同, Delegate只是將部分工作委派特定對象處理, 但控制權還在本身, 但Dispatch則是將控制權交給分派的對象。
. Mapper : 使用Map來轉譯收到的需求為合適的action和view, 可視為工廠(factory)
. Map : 放置目標資源的參考關係, 可能是Class或registry。
註 : 直接控管方式是直接可從Map中取出參考關係, 而間接控管方式是Map內包含物件, 須透過此物件才可找到目標資源。
以Jakarta Struts為例, Command Factory將request與action對應的關係從struts-config.xml中找出來, 傳回Command Map(ActionMapping)物件。這裡的Command Factory就是Mapper, ActionMappig就是Map。
參考 : http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationController.htm
正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
. 將Action與View的管理集中化與模組化
在展示層中在接收到需求後有兩件主要的工作 :
. 第一, 收到的需求由特定的Action來提供服務, 稱為Action Management
. 第二, 控制權轉交給適當的View, 稱為View Management
這些也可以集中在Front Controller處理, 但是當應用系統及程式複雜時，最好將這些行為移到不同的classes以提高程式的模組化，重用性及擴充性。
重點:
. 重用(reuse)action與view management的程式碼
. 提升需求控管的可擴充性, 例如逐漸將Use case的功能加到應用系統內。
. 提升程式碼的模組化及可維護性, 更容易擴充您的應用系統, 更容易測試你每一部份的需求控管程式, 而這些程式與Web Container是不相關的(與Web Contrainer相關的需求管控在Front Controller完成)。
解決方案 :
- 使用一個Application Controller集中需求處理元件(如Commands與Views)的擷取與呼叫
註 : 真正處理需求及展現結果的元件不是Application Controller, 而是Commands與Views, Application Controller可以視為根據需求找到對應處理的Command(或Action), 並分派給合適的View來處理要呈現的結果。
將這些程式碼從Front Controller分離的好處有 :
1. 從Front Controller中與特定網路協定相關的程式碼分離以提升程式模組化與重用性, 例如特定的application controller元件可以提供給許多的channels(如web application與web service)重複使用來控管需求。這些控管有資料驗證(Validation), error handling, authentication, 存取控制(access control)等。
2. 與Servlet-based Front Controller分離以便於在Web container外進行測試
註 : Application Controller內部會有與Servlet及Web Container有關的API呼叫, 因此, 程式設計師進行這部份功能的單元測試就不一定要與未來執行環境相同(不需用相同的Web Container)
Pattern內的成員及責任
. Client(需求端) : 負責呼叫Application Controller, 通常維Front Controller或Intercepting Filter
. Application Controller : 使用Mapper解決收到的需求及對應的Action及View之間委派(Delegate)或分派(Dispatch)
註 : Delegate與Dispatch不同, Delegate只是將部分工作委派特定對象處理, 但控制權還在本身, 但Dispatch則是將控制權交給分派的對象。
. Mapper : 使用Map來轉譯收到的需求為合適的action和view, 可視為工廠(factory)
. Map : 放置目標資源的參考關係, 可能是Class或registry。
註 : 直接控管方式是直接可從Map中取出參考關係, 而間接控管方式是Map內包含物件, 須透過此物件才可找到目標資源。
以Jakarta Struts為例, Command Factory將request與action對應的關係從struts-config.xml中找出來, 傳回Command Map(ActionMapping)物件。這裡的Command Factory就是Mapper, ActionMappig就是Map。
參考 : http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationController.htm
2005年7月11日
J2EE Design Pattern : Transfer Object筆記
J2EE Design Pattern : Transfer Object筆記
正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
跨層(presentation tier, business tier and integration tier)轉送多個資料元素, 並減少遠端呼叫造成網路的負擔。
J2EE應用系統用Session Facade 或Business Objects作為伺服器端商業元件並由其中的一些methods傳資料回需求端。這些商業元件常用如session beans與entity beans等遠端物件來實作。若這些商業元件採用較小的get及set methods，則需求端必需呼叫很多的getter methods才能取得所需的屬性內容值。
因為這些method的呼叫對enterprise bean而言都是遠端呼叫, 因此可能會造成效率上的問題。因為遠端呼叫會造成網路的負擔。即使需求端與EJB container在相同的JVM, OS或相同的實體機器上執行效能都會受影響。因此使用許多的遠端getter method的呼叫, 每次只傳回一點點資料, 這種方式非常沒有效率。
因此即使不是存取遠端元件，仍然需要存取封裝在不同層內的資料元件, 如商業層的Business Objects, 整合層的Data Access Objects, 仍需要以較大顆粒(傳遞物件)介面來傳送及與接收資料。
重點 :
. 需求端要存取其他層的元件來擷取或更新資料
. 要減少網路上遠端的需求次數。
. 要避免存取頻繁的應用系統造成高的網路流量使網路效能下降。
解決方案
- 使用Transfer Object來攜帶跨層間傳遞的多個資料元素。
Transfer Object用來讓跨層間的資料最佳化，Transfer Object將需求與回應間的傳送與接收的所有元素包含在單一個資料結構內。
Transfer Object以傳值的方式被傳送到需求端, 因此需求端對Transfer Object的所有呼叫, 是針對原始Transfer Object的副本，而非遠端的原始Transfer Object。
步驟 :
1. Component因需求來建立Transfer Object的instance並傳回給需求端
註 : Component可能是展示層的view helper, business delegate或command object; 或商業層的Business Object, Application Service或Service Facade等; 或整合層的Data Access Object。
2. 此時的Transfer Object為序列化的(serialized)並跨網路傳送到需求端, 需求端收到並使用這個Transfer Object的本地副本(local copy)
3. 需求端也可以產生自己的Transfer Object instance送到Component來執行資料更新。
實作上Transfer Object是一個Serializable plan old Java Object(POJO), 包含許多的members(attributes or fields), 且用單一的method call來完成所有資料的傳送。
實作策略 : (待續)
Class Diagram
參考 :
http://www.corej2eepatterns.com/Patterns2ndEd/TransferObject.htm
正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
跨層(presentation tier, business tier and integration tier)轉送多個資料元素, 並減少遠端呼叫造成網路的負擔。
J2EE應用系統用Session Facade 或Business Objects作為伺服器端商業元件並由其中的一些methods傳資料回需求端。這些商業元件常用如session beans與entity beans等遠端物件來實作。若這些商業元件採用較小的get及set methods，則需求端必需呼叫很多的getter methods才能取得所需的屬性內容值。
因為這些method的呼叫對enterprise bean而言都是遠端呼叫, 因此可能會造成效率上的問題。因為遠端呼叫會造成網路的負擔。即使需求端與EJB container在相同的JVM, OS或相同的實體機器上執行效能都會受影響。因此使用許多的遠端getter method的呼叫, 每次只傳回一點點資料, 這種方式非常沒有效率。
因此即使不是存取遠端元件，仍然需要存取封裝在不同層內的資料元件, 如商業層的Business Objects, 整合層的Data Access Objects, 仍需要以較大顆粒(傳遞物件)介面來傳送及與接收資料。
重點 :
. 需求端要存取其他層的元件來擷取或更新資料
. 要減少網路上遠端的需求次數。
. 要避免存取頻繁的應用系統造成高的網路流量使網路效能下降。
解決方案
- 使用Transfer Object來攜帶跨層間傳遞的多個資料元素。
Transfer Object用來讓跨層間的資料最佳化，Transfer Object將需求與回應間的傳送與接收的所有元素包含在單一個資料結構內。
Transfer Object以傳值的方式被傳送到需求端, 因此需求端對Transfer Object的所有呼叫, 是針對原始Transfer Object的副本，而非遠端的原始Transfer Object。
步驟 :
1. Component因需求來建立Transfer Object的instance並傳回給需求端
註 : Component可能是展示層的view helper, business delegate或command object; 或商業層的Business Object, Application Service或Service Facade等; 或整合層的Data Access Object。
2. 此時的Transfer Object為序列化的(serialized)並跨網路傳送到需求端, 需求端收到並使用這個Transfer Object的本地副本(local copy)
3. 需求端也可以產生自己的Transfer Object instance送到Component來執行資料更新。
實作上Transfer Object是一個Serializable plan old Java Object(POJO), 包含許多的members(attributes or fields), 且用單一的method call來完成所有資料的傳送。
實作策略 : (待續)
Class Diagram
參考 :
http://www.corej2eepatterns.com/Patterns2ndEd/TransferObject.htm
2005年7月9日
J2EE Design Pattern : Application Service筆記
J2EE Design Pattern : Application Service筆記
正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
要集中跨許多商業層元件與服務的商業邏輯提供簡單的介面給需求端。
Service Facade如Session Facade或POJO Facade內含很少甚至沒有商業邏輯，僅用來提供簡單的介面, 當應用系統實作的使用案例(use cases)由許多的商業物件(Business Objects)及商業服務(如Web Services)所完成, 不應該用商業物件來實作這個User Case內的商業物件與服務間的協調工作, 這將增加了商業物件間的耦合性(coupling)。
註 :
1. Session Facade及POJO(Plain Old Java Object) Facade都是一種Service Facade, Session Facade是一種提供遠端商業服務(如Web Services)的介面。POJO Facade提供的近端商業服務的介面, 這些近端商業服務為POJO, 如Business Object(另一種Design Pattern)
2. 簡單的說, Service Facade提供一個Use Case對外的單一服務介面。
重點 :
. 盡量減少Service Facade內的商業邏輯
. 商業邏輯包含在商業物件與服務內
. 在現有的商業層的元件與服務之上提供簡單的介面
. 將使用案例特定的邏輯(控制與協調邏輯)在商業物件外加以封裝
解決方案 :
- 使用一個Application Service集中與彙整商業處理,提供統一的服務層。
Application Service的七項功能 :
1. Application Service 提供一個集中的地方來實作商業邏輯, 這些商業邏輯內含商業物件及服務。也就是說用Application Service將高層次的商業邏輯封裝在一個元件, 而這個元件叫用一些商業物件與服務。
2. 即使你不使用商業物件, Application Service也可以提供集中的商業邏輯實作層。Application service 可以包含程序控制的商業邏輯, 這些商業邏輯用來實作不同的服務(要依序完成)及資料存取物件(Data Access Object)。
3. 在非EJB的應用系統, Application Service提供展示層與商業層物件(如商業物件或服務)間的中介功能以減少兩個層的耦合性(Coupling)。就介面的粗細緻的層次而言Application Service介於Service Facade與Business Object之間。
4. Application Service提供Service Facade基礎架構, 讓Service Facase變得更簡單, 包含更少的程式碼, 因為Service Facade只要將商業處理委派(Delegate)給Application Service就好了。 (Application Service包含商業邏輯而Session Facade不包含商業邏輯)
5. 以Session Facade為例, 當商業邏輯(高層次)變得複雜, 如果將這些邏輯放在特定的Session Facade內, 則這些邏輯將很難被其他的Session Facade叫用, 只能用copy and paste方式重用, 如此一來這些Session Facade將變的難以維護。Application Service就可用來放置這些可重用的邏輯，讓Session Facade變的簡單, 優雅且好維護。
6. Application Service 可用來處理應用系統間的互動, 不同Use Cases間的互動及不同需求端型態的互動。如Use Case特有的處理或特定需求端形態的處理。
7. Application Service也可以用來實作存取外部服務的邏輯, 如eMail system, legacy system或Web Service, 並提供可重用的服務元件。
實作這個Pattern的策略 : <準備中>
參考 : http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationService.htm
正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
要集中跨許多商業層元件與服務的商業邏輯提供簡單的介面給需求端。
Service Facade如Session Facade或POJO Facade內含很少甚至沒有商業邏輯，僅用來提供簡單的介面, 當應用系統實作的使用案例(use cases)由許多的商業物件(Business Objects)及商業服務(如Web Services)所完成, 不應該用商業物件來實作這個User Case內的商業物件與服務間的協調工作, 這將增加了商業物件間的耦合性(coupling)。
註 :
1. Session Facade及POJO(Plain Old Java Object) Facade都是一種Service Facade, Session Facade是一種提供遠端商業服務(如Web Services)的介面。POJO Facade提供的近端商業服務的介面, 這些近端商業服務為POJO, 如Business Object(另一種Design Pattern)
2. 簡單的說, Service Facade提供一個Use Case對外的單一服務介面。
重點 :
. 盡量減少Service Facade內的商業邏輯
. 商業邏輯包含在商業物件與服務內
. 在現有的商業層的元件與服務之上提供簡單的介面
. 將使用案例特定的邏輯(控制與協調邏輯)在商業物件外加以封裝
解決方案 :
- 使用一個Application Service集中與彙整商業處理,提供統一的服務層。
Application Service的七項功能 :
1. Application Service 提供一個集中的地方來實作商業邏輯, 這些商業邏輯內含商業物件及服務。也就是說用Application Service將高層次的商業邏輯封裝在一個元件, 而這個元件叫用一些商業物件與服務。
2. 即使你不使用商業物件, Application Service也可以提供集中的商業邏輯實作層。Application service 可以包含程序控制的商業邏輯, 這些商業邏輯用來實作不同的服務(要依序完成)及資料存取物件(Data Access Object)。
3. 在非EJB的應用系統, Application Service提供展示層與商業層物件(如商業物件或服務)間的中介功能以減少兩個層的耦合性(Coupling)。就介面的粗細緻的層次而言Application Service介於Service Facade與Business Object之間。
4. Application Service提供Service Facade基礎架構, 讓Service Facase變得更簡單, 包含更少的程式碼, 因為Service Facade只要將商業處理委派(Delegate)給Application Service就好了。 (Application Service包含商業邏輯而Session Facade不包含商業邏輯)
5. 以Session Facade為例, 當商業邏輯(高層次)變得複雜, 如果將這些邏輯放在特定的Session Facade內, 則這些邏輯將很難被其他的Session Facade叫用, 只能用copy and paste方式重用, 如此一來這些Session Facade將變的難以維護。Application Service就可用來放置這些可重用的邏輯，讓Session Facade變的簡單, 優雅且好維護。
6. Application Service 可用來處理應用系統間的互動, 不同Use Cases間的互動及不同需求端型態的互動。如Use Case特有的處理或特定需求端形態的處理。
7. Application Service也可以用來實作存取外部服務的邏輯, 如eMail system, legacy system或Web Service, 並提供可重用的服務元件。
實作這個Pattern的策略 : <準備中>
參考 : http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationService.htm
2005年7月8日
J2EE Design Pattern : Service to Worker筆記
正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
在View顯示前要執行主要的需求控管(request handling)並執行商業邏輯處理。
檢視下面的問題，了解在View準備階段的需求處理過程有多少工作要完成:
. 控制邏輯有多複雜?
. 要傳回的內容有多少動態資料?
. 商業邏輯及資料模型有多複雜?
重點 :
. 一個需求透過指定的商業邏輯來取得用來產生回應的資訊(例如資料庫或檔案內的資訊)。
. View的選擇決定於商業服務(邏輯)產生的回應訊息(HTML, JSP等)。
. 可以使用Framework或library, 如Jakarta Struts, JSF等。
解決方案 :
- 用Service to Worker來集中控制與需求控管在控制權交給View前取得展示資料模型(Presentation Model 例如儲存在Session內的資料), View 就是基於這個展示模型來產生動態的回應。
註 : Service to Worker與Dispatcher View為兩個最常使用的方法。Service to Worker是以控制器(application controller)為中心的架構，Dispatcher View是以View為中心的架構, 它的商業處理是到View的處理時才被執行(例如在JSP中的scriptlet or tag library)
Service to Worker pattern 由許多的patterns所組成，包含Front Controller, Application Controller與 View Helper
步驟 :
1.Front Controller接收需求(request), 並處理與網路協定相關的元素(如HttpServletRequest..)然後產生Context Object, 交給Application Controller, 並委派Application Controller進行Action與View的管理。
2.Application Controller扮演Command Handler將request中的邏輯名稱(例如http://some.server.com/Controller?action=login中的"login")找到對應的Command(例如LoginCmd), 並呼叫(invoke)這個Command
3.特定Command用來呼叫特定的商業服務來產生展示資料模型。
4.然後Application Controller再將控制權轉交給特定的View
5.這個View透過View Helper將展示資料模型內的資料轉換成View所需的內容。這個View也可能是個合成的View(Composite View)
在此要注意的是, 商業邏輯在控制權轉交給View前就完成了, 而Dispatch View則在制權轉交給View之後才執行這些商業邏輯。
實作這個Pattern的策略 :
1. Front Controller有Servlet Front Strategy與JSP Front Controller兩種, 前者較好。(在Front Controller的筆記中介紹)
2. View Helper有Template-Based View Strategy, Controller-Based View Strategy, JavaBean Helper Strategy, Custom Tag Helper四種策略 (在View Helper的筆記中介紹)
3. Dispatcher in Controller Strategy : 就是將控制權轉交給View的派送程式放在Front Controller內, 這也是在Front Controller的筆記中介紹。
參考 : http://www.corej2eepatterns.com/Patterns2ndEd/ServiceToWorker.htm
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
在View顯示前要執行主要的需求控管(request handling)並執行商業邏輯處理。
檢視下面的問題，了解在View準備階段的需求處理過程有多少工作要完成:
. 控制邏輯有多複雜?
. 要傳回的內容有多少動態資料?
. 商業邏輯及資料模型有多複雜?
重點 :
. 一個需求透過指定的商業邏輯來取得用來產生回應的資訊(例如資料庫或檔案內的資訊)。
. View的選擇決定於商業服務(邏輯)產生的回應訊息(HTML, JSP等)。
. 可以使用Framework或library, 如Jakarta Struts, JSF等。
解決方案 :
- 用Service to Worker來集中控制與需求控管在控制權交給View前取得展示資料模型(Presentation Model 例如儲存在Session內的資料), View 就是基於這個展示模型來產生動態的回應。
註 : Service to Worker與Dispatcher View為兩個最常使用的方法。Service to Worker是以控制器(application controller)為中心的架構，Dispatcher View是以View為中心的架構, 它的商業處理是到View的處理時才被執行(例如在JSP中的scriptlet or tag library)
Service to Worker pattern 由許多的patterns所組成，包含Front Controller, Application Controller與 View Helper
步驟 :
1.Front Controller接收需求(request), 並處理與網路協定相關的元素(如HttpServletRequest..)然後產生Context Object, 交給Application Controller, 並委派Application Controller進行Action與View的管理。
2.Application Controller扮演Command Handler將request中的邏輯名稱(例如http://some.server.com/Controller?action=login中的"login")找到對應的Command(例如LoginCmd), 並呼叫(invoke)這個Command
3.特定Command用來呼叫特定的商業服務來產生展示資料模型。
4.然後Application Controller再將控制權轉交給特定的View
5.這個View透過View Helper將展示資料模型內的資料轉換成View所需的內容。這個View也可能是個合成的View(Composite View)
在此要注意的是, 商業邏輯在控制權轉交給View前就完成了, 而Dispatch View則在制權轉交給View之後才執行這些商業邏輯。
實作這個Pattern的策略 :
1. Front Controller有Servlet Front Strategy與JSP Front Controller兩種, 前者較好。(在Front Controller的筆記中介紹)
2. View Helper有Template-Based View Strategy, Controller-Based View Strategy, JavaBean Helper Strategy, Custom Tag Helper四種策略 (在View Helper的筆記中介紹)
3. Dispatcher in Controller Strategy : 就是將控制權轉交給View的派送程式放在Front Controller內, 這也是在Front Controller的筆記中介紹。
參考 : http://www.corej2eepatterns.com/Patterns2ndEd/ServiceToWorker.htm
2005年7月5日
透過Jakarta Beanutils將ResultSet轉成ArrayList
有關Jakarta Commons的Beanutils請見http://jakarta.apache.org/commons/beanutils
將ResultSet轉成ArrayList的範例程式 :
import java.sql.*;
import java.util.*;
import org.apache.commons.beanutils.*;
public class DynaBeanArrayList {
public DynaBeanArrayList() {
}
public ArrayList getArrayList(ResultSet rs) throws Exception{
ArrayList results = new ArrayList(); // To hold copied list
try{
ResultSetDynaClass rsdc = new ResultSetDynaClass(rs);
BasicDynaClass bdc = new BasicDynaClass("DynaBeanTemplate", BasicDynaBean.class, rsdc.getDynaProperties());
Iterator rows = rsdc.iterator();
while (rows.hasNext()) {
DynaBean oldRow = (DynaBean) rows.next();
DynaBean newRow = bdc.newInstance();
PropertyUtils.copyProperties(newRow, oldRow);
results.add(newRow);
}
return results;
}
catch(Exception e){
return null;
}
}
}
將ResultSet轉成ArrayList的範例程式 :
import java.sql.*;
import java.util.*;
import org.apache.commons.beanutils.*;
public class DynaBeanArrayList {
public DynaBeanArrayList() {
}
public ArrayList getArrayList(ResultSet rs) throws Exception{
ArrayList results = new ArrayList(); // To hold copied list
try{
ResultSetDynaClass rsdc = new ResultSetDynaClass(rs);
BasicDynaClass bdc = new BasicDynaClass("DynaBeanTemplate", BasicDynaBean.class, rsdc.getDynaProperties());
Iterator rows = rsdc.iterator();
while (rows.hasNext()) {
DynaBean oldRow = (DynaBean) rows.next();
DynaBean newRow = bdc.newInstance();
PropertyUtils.copyProperties(newRow, oldRow);
results.add(newRow);
}
return results;
}
catch(Exception e){
return null;
}
}
}
2005年6月20日
J2EE Design Pattern - Business Delegete筆記
Fred Wang中譯與整理 2005/06/20 (http://fredwang.blogspot.com)
解決問題 :
隱藏遠端存取商業服務(business service)元件的複雜度
直接存取遠端商業服務(business service)元件的問題如下 :
1. 直接與商業服務(business service)介面程式互動，當商業服務程式碼異動時，需求端的程式碼也要異動。這將增加所需的維護量及降低系統的彈性。
2. 與網路的效能有關，當需求端直接與商業服務API互動時，需求端單一的動作可能需要與商業服務(business service)多種的互動，這將導致商業邏輯包含到需求端程式內, 且沒有任何需求端的暫存機制(caching)或服務結果的彙整，將降低可維護性。而這些行為跨網路執行也降低網路的效能。
3. 與商業服務API緊密的互動表示需求端程式內需要一些與遠端分散式中介層(remote distributed middle tier)有關的基礎程式碼，這些基礎程式碼就是命名服務(naming services)如JNDI, 網路連線失敗的處理與重試的邏輯。
重點 :
1. 從展示端元件及客戶端如devices, web services and rich clients等存取商業層元件。
2. 將客戶端與商業服務的耦合關係最小化，隱藏商業服務內含的應用細節如naming / lookup services and access
3. 將網路例外處理(exceptions)轉成應用或使用端的例外處理，如java.rmi.Remote exceptions, JMS exceptions等。
4. 隱藏服務的建立，重新設定及失敗重做(retry)等，不必將問題丟回給需求端。
5. 將商業服務的結果暫存(cache)以降低網路負擔，提升效能。
Business Delegate使用Service Locator來找到business service，Service Locator負責隱藏商業服務的lookup程式碼內的應用細節。
與 Session Façade為一對一的關係，因為與多個商業服務互動的邏輯封裝在Business Delegate內，而這些商業服務的細節又封裝在Session Façade。
Class Diagram
Sequence Diagram
實作策略
1. Delegate Proxy Strategy
Business Delegate以interface的形式存取商業服務API內含的功能，作為遠端商業服務的代理(proxy)，除此之外還可加上一些驗證及暫存商業資料的機制。暫存(caching)機制可以包含對session bean’s home or remote objects的遠端參考，藉由減少lookup的次數以提升效能。
Business Delegate也可以使用Service Locator將遠端的參考轉成字串表示(IDs)。
2. Delegate Adapter Strategy
在B2B的環境，與你的系統互動的系統可能不是J2EE的應用，那麼必須提供與這些外部系統互動的解決方式，最常見的是使用XML。
Sequence Diagram using Adapter Strategy
解決問題 :
隱藏遠端存取商業服務(business service)元件的複雜度
直接存取遠端商業服務(business service)元件的問題如下 :
1. 直接與商業服務(business service)介面程式互動，當商業服務程式碼異動時，需求端的程式碼也要異動。這將增加所需的維護量及降低系統的彈性。
2. 與網路的效能有關，當需求端直接與商業服務API互動時，需求端單一的動作可能需要與商業服務(business service)多種的互動，這將導致商業邏輯包含到需求端程式內, 且沒有任何需求端的暫存機制(caching)或服務結果的彙整，將降低可維護性。而這些行為跨網路執行也降低網路的效能。
3. 與商業服務API緊密的互動表示需求端程式內需要一些與遠端分散式中介層(remote distributed middle tier)有關的基礎程式碼，這些基礎程式碼就是命名服務(naming services)如JNDI, 網路連線失敗的處理與重試的邏輯。
重點 :
1. 從展示端元件及客戶端如devices, web services and rich clients等存取商業層元件。
2. 將客戶端與商業服務的耦合關係最小化，隱藏商業服務內含的應用細節如naming / lookup services and access
3. 將網路例外處理(exceptions)轉成應用或使用端的例外處理，如java.rmi.Remote exceptions, JMS exceptions等。
4. 隱藏服務的建立，重新設定及失敗重做(retry)等，不必將問題丟回給需求端。
5. 將商業服務的結果暫存(cache)以降低網路負擔，提升效能。
Business Delegate使用Service Locator來找到business service，Service Locator負責隱藏商業服務的lookup程式碼內的應用細節。
與 Session Façade為一對一的關係，因為與多個商業服務互動的邏輯封裝在Business Delegate內，而這些商業服務的細節又封裝在Session Façade。
Class Diagram
Sequence Diagram
實作策略
1. Delegate Proxy Strategy
Business Delegate以interface的形式存取商業服務API內含的功能，作為遠端商業服務的代理(proxy)，除此之外還可加上一些驗證及暫存商業資料的機制。暫存(caching)機制可以包含對session bean’s home or remote objects的遠端參考，藉由減少lookup的次數以提升效能。
Business Delegate也可以使用Service Locator將遠端的參考轉成字串表示(IDs)。
2. Delegate Adapter Strategy
在B2B的環境，與你的系統互動的系統可能不是J2EE的應用，那麼必須提供與這些外部系統互動的解決方式，最常見的是使用XML。
Sequence Diagram using Adapter Strategy
2005年6月17日
搜尋引擎的其他選擇 - 使用群組技術的搜尋引擎
使用群組技術的搜尋引擎
搜尋引擎的技術, 仍不斷演進, 下面幾個運用群組技術的搜尋引擎, 也令人驚艷
群組技術 : 試著在最吻合搜尋條件的網頁之中尋找模式，以便把搜尋結果分類成更小的群組。分類模式可能包括常用字、同義字、相關字，甚至可能利用特殊的規則，辨識出高層次的觀念架構。這類系統會為每個連結群組標上相關字詞，使用者可選擇其中某個群組，進一步縮小搜尋範圍。
1. Clusty
2. Mooter :以視覺方式把群組呈現在搜尋者眼前。在搜尋結果頁面的正中央，有個代表所有結果的按鈕，周圍則是各個代表次分類的按鈕，看起來就像一個輪軸。只要點選群組按鈕，就可讀取相關連結的清單，新的相關群組也會列在一旁。Mooter還會記憶使用者選擇的群組，只要鍵入新的查詢項目，然後點選「縮小搜尋範圍」（refine），Mooter就會在先前選取的群組中進行新的檢索，為使用者找出更精準的結果。
3. Kartoo : 運用了視覺效果。把使用者的查詢傳送到其他搜尋引擎，然後以視覺方式呈現出匯整後的結果。Kartoo不僅列出了各網站的關鍵字，而且會顯示一張「地圖」。地圖中以圖示代表重要的網站，不同的網站之間連有路徑，並且在路徑上標示著網站之間的關係。使用者可點選標示，縮小搜尋結果的範圍。
參考 : 比Google厲害的搜尋引擎
搜尋引擎的技術, 仍不斷演進, 下面幾個運用群組技術的搜尋引擎, 也令人驚艷
群組技術 : 試著在最吻合搜尋條件的網頁之中尋找模式，以便把搜尋結果分類成更小的群組。分類模式可能包括常用字、同義字、相關字，甚至可能利用特殊的規則，辨識出高層次的觀念架構。這類系統會為每個連結群組標上相關字詞，使用者可選擇其中某個群組，進一步縮小搜尋範圍。
1. Clusty
2. Mooter :以視覺方式把群組呈現在搜尋者眼前。在搜尋結果頁面的正中央，有個代表所有結果的按鈕，周圍則是各個代表次分類的按鈕，看起來就像一個輪軸。只要點選群組按鈕，就可讀取相關連結的清單，新的相關群組也會列在一旁。Mooter還會記憶使用者選擇的群組，只要鍵入新的查詢項目，然後點選「縮小搜尋範圍」（refine），Mooter就會在先前選取的群組中進行新的檢索，為使用者找出更精準的結果。
3. Kartoo : 運用了視覺效果。把使用者的查詢傳送到其他搜尋引擎，然後以視覺方式呈現出匯整後的結果。Kartoo不僅列出了各網站的關鍵字，而且會顯示一張「地圖」。地圖中以圖示代表重要的網站，不同的網站之間連有路徑，並且在路徑上標示著網站之間的關係。使用者可點選標示，縮小搜尋結果的範圍。
參考 : 比Google厲害的搜尋引擎
2005年6月15日
J2EE Design Pttern - Interceping Filter 筆記
J2EE Design Pttern - Interceping Filter 筆記
Fred Wang (http://fredwang.blogspot.com)
2005.06.15
用來解決什麼問題
將request前置處理與response的後置處理與核心應用程式碼分離, 並集中處理避免相同的程式碼, 在不同的程式內剪貼使用
Interceping Filter的用途 :
1. login checking : 檢查是否合法使用者 (這個常用!!)
2. IP banning : 禁止或允許某些IP
3. 限制http request只能用哪些url path
4. 檢查是否使用者為網站所支援的瀏覽器型態
5. Character encoding : 例如將 response/request 轉成一致的格式
6. 檢查request是否加密或壓縮
7. 紀錄(Logging)每個request的資訊
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/Filter.html
內提到的應用有下列九種 :
1) Authentication Filters
2) Logging and Auditing Filters
3) Image conversion Filters
4) Data compression Filters
5) Encryption Filters
6) Tokenizing Filters
7) Filters that trigger resource access events
8) XSL/T filters
9) Mime-type chain Filter
Class Diagram
Sequence Diagram
實作策略
Standard Filter Strategy
- 使用deployment descriptor(web.xml)增加或移除Filters, 並設定相關的控制
- Servlet 2.3 Interface : javax.servlet.Filter
- 不提供postprocessing
Custom Filter Strategy
- 彈性及功能都比Standard Filter Strategy差(用Servlet 2.3的標準功能較有彈性也比較強大)
Base Filter Strategy
- 當作所有Filters的共用superclass
Template Filter Strategy
- 專注於preprocessing and postprocessing logic的實作
Web Service Message-Handling Strategies
Description :
- Handle pre and postprocessing of web service requests
- Message handling : intercept incoming messages and perform pre and postprocessing on information in the message
Ex:
- Validate a digital signature
- Sign a message
- Log information about a message
A. SOAP With Attachments API for Java or SAAJ
- Custom SOAP Filter Strategy
- Using a SOAP library, such as SAAJ
B. JAX-RPC Filter Strategy
- Performed by the JAX-RPC runtime engine
- Build message handlers with JAX-RPC using SAAJ
參考 :
1. Core J2EE Patterns - Intercepting Filter , Sun Microsystems
2. JavaWorld技術論壇 http://www.javaworld.com.tw/jute/post/view?bid=25&id=19581&sty=1&tpg=1&age=0
3. Core J2EE Patterns : http://corej2eepatterns.com/Patterns2ndEd/InterceptingFilter.htm
Fred Wang (http://fredwang.blogspot.com)
2005.06.15
用來解決什麼問題
將request前置處理與response的後置處理與核心應用程式碼分離, 並集中處理避免相同的程式碼, 在不同的程式內剪貼使用
Interceping Filter的用途 :
1. login checking : 檢查是否合法使用者 (這個常用!!)
2. IP banning : 禁止或允許某些IP
3. 限制http request只能用哪些url path
4. 檢查是否使用者為網站所支援的瀏覽器型態
5. Character encoding : 例如將 response/request 轉成一致的格式
6. 檢查request是否加密或壓縮
7. 紀錄(Logging)每個request的資訊
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/Filter.html
內提到的應用有下列九種 :
1) Authentication Filters
2) Logging and Auditing Filters
3) Image conversion Filters
4) Data compression Filters
5) Encryption Filters
6) Tokenizing Filters
7) Filters that trigger resource access events
8) XSL/T filters
9) Mime-type chain Filter
Class Diagram
Sequence Diagram
實作策略
Standard Filter Strategy
- 使用deployment descriptor(web.xml)增加或移除Filters, 並設定相關的控制
- Servlet 2.3 Interface : javax.servlet.Filter
- 不提供postprocessing
Custom Filter Strategy
- 彈性及功能都比Standard Filter Strategy差(用Servlet 2.3的標準功能較有彈性也比較強大)
Base Filter Strategy
- 當作所有Filters的共用superclass
Template Filter Strategy
- 專注於preprocessing and postprocessing logic的實作
Web Service Message-Handling Strategies
Description :
- Handle pre and postprocessing of web service requests
- Message handling : intercept incoming messages and perform pre and postprocessing on information in the message
Ex:
- Validate a digital signature
- Sign a message
- Log information about a message
A. SOAP With Attachments API for Java or SAAJ
- Custom SOAP Filter Strategy
- Using a SOAP library, such as SAAJ
B. JAX-RPC Filter Strategy
- Performed by the JAX-RPC runtime engine
- Build message handlers with JAX-RPC using SAAJ
參考 :
1. Core J2EE Patterns - Intercepting Filter , Sun Microsystems
2. JavaWorld技術論壇 http://www.javaworld.com.tw/jute/post/view?bid=25&id=19581&sty=1&tpg=1&age=0
3. Core J2EE Patterns : http://corej2eepatterns.com/Patterns2ndEd/InterceptingFilter.htm
J2EE專案10大風險
J2EE專案10大風險
原文在 http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html
避免本文所列之10大J2EE風險，確保企業級Java專案成功
作者：Humphrey Sheil
簡體中文翻譯參考：Blueski
繁體中文整理與翻譯 : Fred Wang (http://fredwang.blogspot.com)
風險1:沒有真正理解 Java, EJB, 和J2EE
這個問題可以分解為3個部分，以便於分析：
1． 沒有真正理解Java
症狀：
A 重複開發JDK核心API中的功能或Classes
B 不懂下列中的某些項目：
- 垃圾收集器 (train, generational, incremental, synchronous, asynchronous)
- 物件在何時能被進行垃圾收集 -- dangling references
- 使用的繼承機制及其優缺點
- over-riding和over-loading方法
- 為什麼java.lang.String 提供的性能不好
- Java中的Pass-by reference語意和EJB中pass-by value語意的比較
- 使用 == 或者使用equals() 方法 for nonprimitives (非基礎型態, 基礎型態primitives有char, byte, short, int, long, float, double, boolean )
- 在不同平臺上Java threads的運行順序方式(例如是否是pre-emptive方式)
- 新線程(Green thread)和本地線程(Native thread)的比較
- Hotspot技術(以及為什麼舊的性能調整技術降低了Hotspot 的優化效果)
- JIT，以及什麼時候好的JIT變得不好
- The Collections API
- RMI
解決方案：
需要不斷加強Java方面的知識，尤其是深入瞭解Java的優勢和不足之處。Java的存在價值已經遠不止是一種語言，了解平臺(JDK及工具等)也同樣重要。嚴格地說，你應該是經過認證的Java程式師，如果不是的話，也許有時會為還有那麼多不知道的內容而感到驚訝。另外，也可以加入Java的郵件列表(Mailing List)等。從同行中學到技術，這將是你最好的資源。
備註:
如果你或者團隊中的成員不真正瞭解程式語言和平臺，怎麼還能希望企業Java應用系統能夠成功呢？能幹的Java程式師之于EJB和J2EE，就像是鴨子之于水一樣。相反的，比較弱、沒有經驗的程式師只能開發出品質低劣的J2EE應用程式。
2. 沒有真正理解EJB
症狀:
- EJB在第一次被叫用後沒有再被叫用到(尤其是stateless session bean)
- 沒有重複利用價值的EJB
- 不理解開發者要做什麼，容器(Container)提供什麼
- EJB沒有依照規範定義(fire thread, 載入了native libraries，試圖執行I/O，等等)
解決方案:
要加強關於EJB方面的知識，可以找一個周末來閱讀EJB規範 (1.1版有314頁)，然後閱讀2.0規範(524頁!)，這樣可以瞭解到1.1沒有定義而在2.0規範中補充的內容。EJB開發者從18.1及18.2章節開始閱讀是比較合適的。
備註:
不要從供應商(Vender)的角度去看EJB，要確切地知道規範所支援的標準EJB模型和基於這些模型的特殊應用之間的區別。這也有助於移轉到別的供應商平台(或版本)的時候所用。
3. 沒有真正理解J2EE
症狀:
- "Everything is an EJB"的設計方式
- 用手工交易(transaction)管理取代了容器-提供(container-provided)的機制
- 自行設計安全機制 -- J2EE平臺在企業級計算中，從表示邏輯到後臺處理，已具有最完整的整合安全架構。
解決方案:
學習J2EE的關鍵元件，並且瞭解它們的優缺點，依次用它們替代每一個服務；“知識就是力量”在這裏行之有效。
備註:
只有知識能夠彌補這些問題。好的Java開發者會成為好的EJB開發者，此後也應逐漸成為J2EE得道高手。Java和J2EE知識掌握得越多，設計和開發工作就會越出色。在設計階段一切都會有條不紊。
風險2: 過度設計(Over-engineering) (採用 EJB或者不採用EJB)
症狀:
- 過於龐大的EJB
- 開發者無法解釋EJB做什麼，以及其間的關係
- 當需要重複使用某些EJB、元件或服務時, 卻無法做到
- EJB啟動了新的交易，而該交易本該由一個已存在的EJB啟動
- 為了安全，把資料分離級別(Data isolation levels)定得太高
解決方案:
過度工程化的解決之道就是極限編程 (XP)方法：用最小的設計和程式碼來滿足需求。除非明確知道今後可能的需求，如將來的負載要求，或者系統在最高負載下的表現，否則大可不必為系統將來的情況做太多考慮或猜測。另外，J2EE平臺已經定義了可擴充性(scalibility)及容錯(failover)等特性，可以讓伺服器系統為你進行處理。
在小型系統中，只包含一個個小元件，這些元件只做一件事，且只要把這件事做好，系統穩定性就已經得到了提高，而且，系統的可維護性會變得很強，在未來要增加功能以滿足新的需求也將變得容易。
備註:
除了上面所列方案之外，可以運用設計模式(Design Pattern) -- 它們可以顯著地改進你的系統設計。EJB模型也廣泛使用了設計模式。例如，每個EJB所帶的Home 介面就是Finder和Factory模式的實例。EJB的remote介面扮演了一種實際bean實現的Proxy，並且對於提供容器的能力也是至關重要的，這些容器截取叫用信號並提供如透明（transparent）的負載平衡的服務。
另外：僅僅是為了使用EJB而使用EJB是危險的。在你的應用系統中的某一部分可能並不需要EJB，甚至你的整個應用系統都不需要。這是過度工程化所走的極端，而且我確實也目睹了一些良好的servlet和JavaBean應用被重構為EJB，而這樣做並沒有很好的技術上的理由。
風險3: 沒有將商業邏輯與前端顯示邏輯分離
症狀:
- 過於龐大、不便的JSP程式
- 在商業邏輯改變的時候必須修改JSP
- 在要求改變使用者介面顯示的時候需要修改並重新配置EJB和其他後臺元件
解決方案:
J2EE平臺使你有機會將顯示邏輯和流程控制分離，進而與商業邏輯分離。這稱為Model 2架構。
備註:
使用一致性的設計來進行用戶介面框架(UI Framework)的連接(例如可以使用taglibs)，這將幫助你避免邏輯分離的問題。不要擔心需要自己建構GUI framework, 已經有許多現成的應用可供選擇(例如Struts等, 對每一個分別進行評估，然後採用最合適的框架(framework)。
風險4: 沒有在開發環境中進行適當的配置
症狀:
- 經過多日或數周的時間才能轉到實際(Live)系統
- 上線過程仍存在大量的風險，有很多不確定性及主要的功能情境(scenario)沒有被測試到
- 實際(Live)系統中的資料和開發、測試中的資料不同
- 無法在開發者機器上進行建構 (Build)
- 應用行為在開發、測試及生產環境中各不相同
解決方案:
解決之道是忠實地複製實際(Live)環境到開發環境，讓開發環境接近於要上線的實際環境。如果未來環境是JDK 1.2.2及Solaris 7，那麼不要在JDK 1.3及Red Hat Linux上進行開發。對於所用的應用伺服器也是如此。不可預期的資料透過下面過程就不會發生：
- 資料核對(Validation)規則
- 系統行為測試
- 系統元件間的協定(特別包括：EJB-EJB間以及EJB-資料庫間)
最糟糕的是，這樣還可能發生異常、空指標，以及你從沒見過的問題。
備註:
開發人員常把安全性問題放到Test階段才開始解決。要防止這樣的陷阱產生，你也可以花費同樣多的時間在業務邏輯中改進安全性。
上線(Go live)是一個複雜的過程，其中充滿了技術性問題和非技術性問題。你可能會陷於想不到的問題中。開發及測試環境過程提供更多產生這些問題的機會，及發現這樣的問題的地方，利用它，就可以大大減少風險。
你做的專案越多，你就越能瞭解什麼是可行的，什麼是不可行的。盡量將工程問題記錄下來，以避免同樣的錯誤重複發生。
風險5: 選擇了不當的供應商
症狀:
- 開發人員要使用更多的時間來處理工具方面的問題，而不是很有成效地使用這些工具
- 為了應付已知的和未知的問題，而不得不進行大量的系統重新設計
- 在不同的工具之間很難進行整合（應用伺服器與IDE工具，IDE工具與除錯器，原始碼控制與建構(Build)工具，等等）
- 對於IDE工具和除錯器等，開發人員往往排斥它們，而推崇自己所喜歡的工具
解決方案:
為了避免風險5，你需要一個很好的供應商選擇程序，風險10的解決方案也適用於此。
要真正評估IDE工具的方法就是實際地使用它。而評估一種J2EE應用唯一的方法是建立一種概念試驗(POC)來進行證明，在試驗中要包含你的應用框架。你不會希望在花費了3個月時間進行了培訓和開發後，在使用時又發現一些bug。
假設在開發到一半的時候，突然發現你的工具集有問題，你就會發現工具的驗證比其他的事情更為重要。如果所選的應用伺服器不能充分滿足你的需要，你只好修改原先的設定。如果IDE不好，則需要設置最低限度的程式設計標準，並讓開發人員任意選擇他們認為最有效的工具。
備註:
要真正瞭解到哪一個供應商對一項特殊的任務來說最合適，其實並不是一件一次性決定的事情。你需要不斷地跟蹤與評估這個市場。例如，在過去的一年裏我用過4種不同的IDE工具，這取決於我使用了什麼樣的應用伺服器、平臺，是否使用EJB等。
風險6: 不瞭解你的供應商
症狀:
- 開發所用時間超過了最壞預測的時間1/3以上
- 供應商已經提供了某項功能，但開發者在不知道的情況下重新進行了該項功能的開發
解決方案:
為了避免這樣的風險，可以訂閱供應商的網上資源，例如郵件列表、新聞群組、版本資訊（尤其是其中的bug修復的說明等），你能從中得到無法估量的重要資訊。
一旦你已經選定了供應商，那麼立即就要投資進行培訓，並且盡可能趕在專案啟動以前完成。然後，逐漸在團隊中建立對此供應商的認識及信任。試著建立幾個EJB並部署一下，再用表示層技術 (Swing GUI, JSP等)來叫用它們。如果你既要建立開發環境，又要同時在實現專案目標，就會產生一些不必要的衝突。實際上，我也見到過一直沒有進行建構過程的情況：“我們沒有時間。”因此，這些工作必須提早進行。有些人會說：“我們的計劃中沒有為我們提供這些時間。”我的回答是：“你的計劃中並沒有不給你時間使你不這麼做啊。”
備註:
在J2EE世界裏，各供應商產品的技術相容性究竟如何？讓我們看一下IBM和BEA的具體分析吧。兩者都分別在各自的應用伺服器中支援EJB 1.1。那麼，實際上BEA WebLogic 5.1和IBM WebSphere 3.5究竟有多少相似之處呢?
1. BEA WebLogic和IBM WebSphere的系統配置和管理方式幾乎完全不同。
2. IBM在WebSphere中採用了全面的GUI環境，而與之相對的是，BEA 在WebLogic中提供一整套命令行。
3. IBM WebSphere使用IIOP來和CORBA異常進行通訊，這些異常對程式師來說是可見的；WebLogic根本沒有CORBA構造，而預設使用t3協定。
4. WebSphere和Visual Age銜接緊密，而WebLogic是IDE無關的，實際上，你幾乎可以使用任何的開發工具。
由此可見，差異還是相當多。如果你是一種應用伺服器的專家，並不意味著你就是所有應用伺服器的專家。這種差異主要在IDE，debugger，build工具，配置管理等等方面。具備某供應商的某項特殊工具的使用經驗，可以在評估該供應商的競爭對手產品時具有一些便利。但是，不要奢望在不同產品之間進行無縫(seamlessly)的轉移。因此，你不得不花費更多的時間在熟練掌握這些工具。
風險7: 設計中沒有充分考慮到可擴充性和產品性能
症狀:
- 無法忍受的緩慢速度
- 系統給伺服器端增加的沈重負擔，而無法利用到一些聚簇(Clustering)技術。
解決方案:
把精力集中於性能和可擴充性(Scability)方面的需求，明確開發要達到的性能指標。如果你需要每秒50個交易，而你的EJB設計只能提供40個，那你就需要考慮替代方案，諸如儲存過程，批次處理，或者重新考慮OLTP的設計。
盡可能讓你的供應商加入，他們應該非常清楚其產品的強項和弱處在哪裡，然後給你提供最直接的幫助。
備註:
本風險與風險2 (over-engineering)似乎有些衝突。實際上，兩者相互影響。 我對風險2給出的解決方案是，只在絕對必要的情況下才進行構建。而對與性能和可擴充性，你要預先劃分好什麼是必須要做的。
如果你認為強大的可擴充性是關鍵的需求，那首先需要選擇一個有很強的Cluster支援及Transactional Cache的應用伺服器。另外，應把業務物件(Business Object)設計為EJB，以充分利用伺服器架構的優勢。
風險8: 過時的開發過程
症狀:
- 專案計劃看上去類似瀑布模型: “首先進行系統設計，然後在一個很長的周期裏進行開發。”
- 由於沒有構建（build）程序，因此每次構建都像是噩夢
- 構建的日期等於損失開發的日期，因為什麼也沒有做成
- 在整合以前元件沒有分別被充分地測試過，而整合測試意味著將2個不穩定的元件放在一起，然後查看堆疊裏的追蹤(Trace)結果。
解決方案:
好的軟體方法學將提高你的軟體生命期。此前我已經提到XP方法，你可以在網上找到很多這方面的資料。
備註:
JUnit可以用來進行單元測試，Ant工具可以進行編譯與構建，這2種工具都對XP方法有很好的支援。
風險9: 沒有好的架構(Framework)
症狀:
- 核心庫中有Bug的部分在程式碼中使用了很多次。
- 沒有建立日誌(Logging)標準 -- 因此系統的輸出很難讀取或者解析。
- 不良且不一致的異常處理。在有些網站中甚至可以看到，低階的系統錯誤訊息直接顯示使用者，例如在使用者在他的購物車核帳時發送一條SQLException Stack Trace資訊，用戶接著會怎麼做？打電話給資料庫管理員要求修正primary key限制嗎？
以下工作已經以各種方式處理過，這些應該列為架構設計的首要目標。
- 日誌(Logging)
- 異常處理 (Exception handling)
- 與資源的連接(資料庫，Naming service等)
- 建立JSP頁
- 資料正確性檢查(Data Validation)
解決方案:
我是一個輕架構(Lightweight Framework)的信徒和實踐者。我在JavaWorld 上的第一篇文章 -- "Frameworks Save the Day" -- 就是研討在企業Java環境中的架構。即使你已經開始開發，此時考慮一下架構仍然是值得的。可能你不得不忍受一下重構帶來的異常處理和日誌處理，但從長遠來看還是值得的，這樣既省時間又省錢。
備註:
思考一下架構及元件開發的可重用性區分不同等級。第一級別是plumbing，具有0.9以上的可重用比例，也就是說，有90%的專案可以對它重複利用。 服務越特殊，重用比例就越低。換句話說，我需要建立一個會計服務，以提供資源的使用及管理，並便於其他50%專案中可以對它們進行重複利用。對那些需要這些資源的專案開發者來說，能得到這些資源，那真是太棒了！
風險10: 根據市場宣傳決定專案計劃和設計，而非實際技術需求
症狀:
- 輕率地進行技術決策，認為EJB只是為了可移植性(portable)的目的
- 選擇供應商的時候沒有隨即進行產品的試用
- 在專案的生命周期內還需要更換工具
解決方案:
不要輕易相信專案外部的任何人的看法，這些人可能已經有一些既得利益，不要相信供應商的說法（除非你早已經瞭解），也不要相信白皮書。如果要取得關於應用伺服器的建議，可以在網上取得。還可以下載這些工具進行評估，用它們做一些原型(prototype)，並執行一下其中的案例。(好的供應商都有這樣的案例)。
總而言之，你的專案選擇最好的供應商及工具需要時間，而你可能沒有太多的時間。你可以把選擇範圍限制在3-4個種，然後用一周時間進行比較和檢驗。最後從中選出比較滿意的工具和產品。
備註:
如果你缺少J2EE經驗，則可能會在專案前期就產生問題。在前期所確定的決策會影響整個過程，並進而影響專案的成功。好的J2EE諮詢專家將能夠幫助你選擇好的供應商，並為設計和開發刻劃出一個好的架構。
結論
總而言之，以上10大風險是企業級Java專案開發過程中將面對的主要困難。相信在你的旅程中一定還有更多的陷阱，相信上面所提到的風險已經涵蓋了主要的問題。最後按照優先順序重新列舉一下10大風險：
- 沒有真正理解Java, 沒有真正理解EJB, 沒有真正理解J2EE
- 過度設計(Over-engineering)
- 沒有將業務邏輯和顯示邏輯相分離
- 沒有在開發環境中進行適當的配置
- 選擇了不當的供應商
- 不瞭解你的供應商
- 設計中沒有充分考慮到可擴充性和產品性能
- 過時的開發過程
- 沒有好的架構(Framework)
- 根據市場宣傳決定專案計劃和設計，而非實際技術需求
原文在 http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html
避免本文所列之10大J2EE風險，確保企業級Java專案成功
作者：Humphrey Sheil
簡體中文翻譯參考：Blueski
繁體中文整理與翻譯 : Fred Wang (http://fredwang.blogspot.com)
風險1:沒有真正理解 Java, EJB, 和J2EE
這個問題可以分解為3個部分，以便於分析：
1． 沒有真正理解Java
症狀：
A 重複開發JDK核心API中的功能或Classes
B 不懂下列中的某些項目：
- 垃圾收集器 (train, generational, incremental, synchronous, asynchronous)
- 物件在何時能被進行垃圾收集 -- dangling references
- 使用的繼承機制及其優缺點
- over-riding和over-loading方法
- 為什麼java.lang.String 提供的性能不好
- Java中的Pass-by reference語意和EJB中pass-by value語意的比較
- 使用 == 或者使用equals() 方法 for nonprimitives (非基礎型態, 基礎型態primitives有char, byte, short, int, long, float, double, boolean )
- 在不同平臺上Java threads的運行順序方式(例如是否是pre-emptive方式)
- 新線程(Green thread)和本地線程(Native thread)的比較
- Hotspot技術(以及為什麼舊的性能調整技術降低了Hotspot 的優化效果)
- JIT，以及什麼時候好的JIT變得不好
- The Collections API
- RMI
解決方案：
需要不斷加強Java方面的知識，尤其是深入瞭解Java的優勢和不足之處。Java的存在價值已經遠不止是一種語言，了解平臺(JDK及工具等)也同樣重要。嚴格地說，你應該是經過認證的Java程式師，如果不是的話，也許有時會為還有那麼多不知道的內容而感到驚訝。另外，也可以加入Java的郵件列表(Mailing List)等。從同行中學到技術，這將是你最好的資源。
備註:
如果你或者團隊中的成員不真正瞭解程式語言和平臺，怎麼還能希望企業Java應用系統能夠成功呢？能幹的Java程式師之于EJB和J2EE，就像是鴨子之于水一樣。相反的，比較弱、沒有經驗的程式師只能開發出品質低劣的J2EE應用程式。
2. 沒有真正理解EJB
症狀:
- EJB在第一次被叫用後沒有再被叫用到(尤其是stateless session bean)
- 沒有重複利用價值的EJB
- 不理解開發者要做什麼，容器(Container)提供什麼
- EJB沒有依照規範定義(fire thread, 載入了native libraries，試圖執行I/O，等等)
解決方案:
要加強關於EJB方面的知識，可以找一個周末來閱讀EJB規範 (1.1版有314頁)，然後閱讀2.0規範(524頁!)，這樣可以瞭解到1.1沒有定義而在2.0規範中補充的內容。EJB開發者從18.1及18.2章節開始閱讀是比較合適的。
備註:
不要從供應商(Vender)的角度去看EJB，要確切地知道規範所支援的標準EJB模型和基於這些模型的特殊應用之間的區別。這也有助於移轉到別的供應商平台(或版本)的時候所用。
3. 沒有真正理解J2EE
症狀:
- "Everything is an EJB"的設計方式
- 用手工交易(transaction)管理取代了容器-提供(container-provided)的機制
- 自行設計安全機制 -- J2EE平臺在企業級計算中，從表示邏輯到後臺處理，已具有最完整的整合安全架構。
解決方案:
學習J2EE的關鍵元件，並且瞭解它們的優缺點，依次用它們替代每一個服務；“知識就是力量”在這裏行之有效。
備註:
只有知識能夠彌補這些問題。好的Java開發者會成為好的EJB開發者，此後也應逐漸成為J2EE得道高手。Java和J2EE知識掌握得越多，設計和開發工作就會越出色。在設計階段一切都會有條不紊。
風險2: 過度設計(Over-engineering) (採用 EJB或者不採用EJB)
症狀:
- 過於龐大的EJB
- 開發者無法解釋EJB做什麼，以及其間的關係
- 當需要重複使用某些EJB、元件或服務時, 卻無法做到
- EJB啟動了新的交易，而該交易本該由一個已存在的EJB啟動
- 為了安全，把資料分離級別(Data isolation levels)定得太高
解決方案:
過度工程化的解決之道就是極限編程 (XP)方法：用最小的設計和程式碼來滿足需求。除非明確知道今後可能的需求，如將來的負載要求，或者系統在最高負載下的表現，否則大可不必為系統將來的情況做太多考慮或猜測。另外，J2EE平臺已經定義了可擴充性(scalibility)及容錯(failover)等特性，可以讓伺服器系統為你進行處理。
在小型系統中，只包含一個個小元件，這些元件只做一件事，且只要把這件事做好，系統穩定性就已經得到了提高，而且，系統的可維護性會變得很強，在未來要增加功能以滿足新的需求也將變得容易。
備註:
除了上面所列方案之外，可以運用設計模式(Design Pattern) -- 它們可以顯著地改進你的系統設計。EJB模型也廣泛使用了設計模式。例如，每個EJB所帶的Home 介面就是Finder和Factory模式的實例。EJB的remote介面扮演了一種實際bean實現的Proxy，並且對於提供容器的能力也是至關重要的，這些容器截取叫用信號並提供如透明（transparent）的負載平衡的服務。
另外：僅僅是為了使用EJB而使用EJB是危險的。在你的應用系統中的某一部分可能並不需要EJB，甚至你的整個應用系統都不需要。這是過度工程化所走的極端，而且我確實也目睹了一些良好的servlet和JavaBean應用被重構為EJB，而這樣做並沒有很好的技術上的理由。
風險3: 沒有將商業邏輯與前端顯示邏輯分離
症狀:
- 過於龐大、不便的JSP程式
- 在商業邏輯改變的時候必須修改JSP
- 在要求改變使用者介面顯示的時候需要修改並重新配置EJB和其他後臺元件
解決方案:
J2EE平臺使你有機會將顯示邏輯和流程控制分離，進而與商業邏輯分離。這稱為Model 2架構。
備註:
使用一致性的設計來進行用戶介面框架(UI Framework)的連接(例如可以使用taglibs)，這將幫助你避免邏輯分離的問題。不要擔心需要自己建構GUI framework, 已經有許多現成的應用可供選擇(例如Struts等, 對每一個分別進行評估，然後採用最合適的框架(framework)。
風險4: 沒有在開發環境中進行適當的配置
症狀:
- 經過多日或數周的時間才能轉到實際(Live)系統
- 上線過程仍存在大量的風險，有很多不確定性及主要的功能情境(scenario)沒有被測試到
- 實際(Live)系統中的資料和開發、測試中的資料不同
- 無法在開發者機器上進行建構 (Build)
- 應用行為在開發、測試及生產環境中各不相同
解決方案:
解決之道是忠實地複製實際(Live)環境到開發環境，讓開發環境接近於要上線的實際環境。如果未來環境是JDK 1.2.2及Solaris 7，那麼不要在JDK 1.3及Red Hat Linux上進行開發。對於所用的應用伺服器也是如此。不可預期的資料透過下面過程就不會發生：
- 資料核對(Validation)規則
- 系統行為測試
- 系統元件間的協定(特別包括：EJB-EJB間以及EJB-資料庫間)
最糟糕的是，這樣還可能發生異常、空指標，以及你從沒見過的問題。
備註:
開發人員常把安全性問題放到Test階段才開始解決。要防止這樣的陷阱產生，你也可以花費同樣多的時間在業務邏輯中改進安全性。
上線(Go live)是一個複雜的過程，其中充滿了技術性問題和非技術性問題。你可能會陷於想不到的問題中。開發及測試環境過程提供更多產生這些問題的機會，及發現這樣的問題的地方，利用它，就可以大大減少風險。
你做的專案越多，你就越能瞭解什麼是可行的，什麼是不可行的。盡量將工程問題記錄下來，以避免同樣的錯誤重複發生。
風險5: 選擇了不當的供應商
症狀:
- 開發人員要使用更多的時間來處理工具方面的問題，而不是很有成效地使用這些工具
- 為了應付已知的和未知的問題，而不得不進行大量的系統重新設計
- 在不同的工具之間很難進行整合（應用伺服器與IDE工具，IDE工具與除錯器，原始碼控制與建構(Build)工具，等等）
- 對於IDE工具和除錯器等，開發人員往往排斥它們，而推崇自己所喜歡的工具
解決方案:
為了避免風險5，你需要一個很好的供應商選擇程序，風險10的解決方案也適用於此。
要真正評估IDE工具的方法就是實際地使用它。而評估一種J2EE應用唯一的方法是建立一種概念試驗(POC)來進行證明，在試驗中要包含你的應用框架。你不會希望在花費了3個月時間進行了培訓和開發後，在使用時又發現一些bug。
假設在開發到一半的時候，突然發現你的工具集有問題，你就會發現工具的驗證比其他的事情更為重要。如果所選的應用伺服器不能充分滿足你的需要，你只好修改原先的設定。如果IDE不好，則需要設置最低限度的程式設計標準，並讓開發人員任意選擇他們認為最有效的工具。
備註:
要真正瞭解到哪一個供應商對一項特殊的任務來說最合適，其實並不是一件一次性決定的事情。你需要不斷地跟蹤與評估這個市場。例如，在過去的一年裏我用過4種不同的IDE工具，這取決於我使用了什麼樣的應用伺服器、平臺，是否使用EJB等。
風險6: 不瞭解你的供應商
症狀:
- 開發所用時間超過了最壞預測的時間1/3以上
- 供應商已經提供了某項功能，但開發者在不知道的情況下重新進行了該項功能的開發
解決方案:
為了避免這樣的風險，可以訂閱供應商的網上資源，例如郵件列表、新聞群組、版本資訊（尤其是其中的bug修復的說明等），你能從中得到無法估量的重要資訊。
一旦你已經選定了供應商，那麼立即就要投資進行培訓，並且盡可能趕在專案啟動以前完成。然後，逐漸在團隊中建立對此供應商的認識及信任。試著建立幾個EJB並部署一下，再用表示層技術 (Swing GUI, JSP等)來叫用它們。如果你既要建立開發環境，又要同時在實現專案目標，就會產生一些不必要的衝突。實際上，我也見到過一直沒有進行建構過程的情況：“我們沒有時間。”因此，這些工作必須提早進行。有些人會說：“我們的計劃中沒有為我們提供這些時間。”我的回答是：“你的計劃中並沒有不給你時間使你不這麼做啊。”
備註:
在J2EE世界裏，各供應商產品的技術相容性究竟如何？讓我們看一下IBM和BEA的具體分析吧。兩者都分別在各自的應用伺服器中支援EJB 1.1。那麼，實際上BEA WebLogic 5.1和IBM WebSphere 3.5究竟有多少相似之處呢?
1. BEA WebLogic和IBM WebSphere的系統配置和管理方式幾乎完全不同。
2. IBM在WebSphere中採用了全面的GUI環境，而與之相對的是，BEA 在WebLogic中提供一整套命令行。
3. IBM WebSphere使用IIOP來和CORBA異常進行通訊，這些異常對程式師來說是可見的；WebLogic根本沒有CORBA構造，而預設使用t3協定。
4. WebSphere和Visual Age銜接緊密，而WebLogic是IDE無關的，實際上，你幾乎可以使用任何的開發工具。
由此可見，差異還是相當多。如果你是一種應用伺服器的專家，並不意味著你就是所有應用伺服器的專家。這種差異主要在IDE，debugger，build工具，配置管理等等方面。具備某供應商的某項特殊工具的使用經驗，可以在評估該供應商的競爭對手產品時具有一些便利。但是，不要奢望在不同產品之間進行無縫(seamlessly)的轉移。因此，你不得不花費更多的時間在熟練掌握這些工具。
風險7: 設計中沒有充分考慮到可擴充性和產品性能
症狀:
- 無法忍受的緩慢速度
- 系統給伺服器端增加的沈重負擔，而無法利用到一些聚簇(Clustering)技術。
解決方案:
把精力集中於性能和可擴充性(Scability)方面的需求，明確開發要達到的性能指標。如果你需要每秒50個交易，而你的EJB設計只能提供40個，那你就需要考慮替代方案，諸如儲存過程，批次處理，或者重新考慮OLTP的設計。
盡可能讓你的供應商加入，他們應該非常清楚其產品的強項和弱處在哪裡，然後給你提供最直接的幫助。
備註:
本風險與風險2 (over-engineering)似乎有些衝突。實際上，兩者相互影響。 我對風險2給出的解決方案是，只在絕對必要的情況下才進行構建。而對與性能和可擴充性，你要預先劃分好什麼是必須要做的。
如果你認為強大的可擴充性是關鍵的需求，那首先需要選擇一個有很強的Cluster支援及Transactional Cache的應用伺服器。另外，應把業務物件(Business Object)設計為EJB，以充分利用伺服器架構的優勢。
風險8: 過時的開發過程
症狀:
- 專案計劃看上去類似瀑布模型: “首先進行系統設計，然後在一個很長的周期裏進行開發。”
- 由於沒有構建（build）程序，因此每次構建都像是噩夢
- 構建的日期等於損失開發的日期，因為什麼也沒有做成
- 在整合以前元件沒有分別被充分地測試過，而整合測試意味著將2個不穩定的元件放在一起，然後查看堆疊裏的追蹤(Trace)結果。
解決方案:
好的軟體方法學將提高你的軟體生命期。此前我已經提到XP方法，你可以在網上找到很多這方面的資料。
備註:
JUnit可以用來進行單元測試，Ant工具可以進行編譯與構建，這2種工具都對XP方法有很好的支援。
風險9: 沒有好的架構(Framework)
症狀:
- 核心庫中有Bug的部分在程式碼中使用了很多次。
- 沒有建立日誌(Logging)標準 -- 因此系統的輸出很難讀取或者解析。
- 不良且不一致的異常處理。在有些網站中甚至可以看到，低階的系統錯誤訊息直接顯示使用者，例如在使用者在他的購物車核帳時發送一條SQLException Stack Trace資訊，用戶接著會怎麼做？打電話給資料庫管理員要求修正primary key限制嗎？
以下工作已經以各種方式處理過，這些應該列為架構設計的首要目標。
- 日誌(Logging)
- 異常處理 (Exception handling)
- 與資源的連接(資料庫，Naming service等)
- 建立JSP頁
- 資料正確性檢查(Data Validation)
解決方案:
我是一個輕架構(Lightweight Framework)的信徒和實踐者。我在JavaWorld 上的第一篇文章 -- "Frameworks Save the Day" -- 就是研討在企業Java環境中的架構。即使你已經開始開發，此時考慮一下架構仍然是值得的。可能你不得不忍受一下重構帶來的異常處理和日誌處理，但從長遠來看還是值得的，這樣既省時間又省錢。
備註:
思考一下架構及元件開發的可重用性區分不同等級。第一級別是plumbing，具有0.9以上的可重用比例，也就是說，有90%的專案可以對它重複利用。 服務越特殊，重用比例就越低。換句話說，我需要建立一個會計服務，以提供資源的使用及管理，並便於其他50%專案中可以對它們進行重複利用。對那些需要這些資源的專案開發者來說，能得到這些資源，那真是太棒了！
風險10: 根據市場宣傳決定專案計劃和設計，而非實際技術需求
症狀:
- 輕率地進行技術決策，認為EJB只是為了可移植性(portable)的目的
- 選擇供應商的時候沒有隨即進行產品的試用
- 在專案的生命周期內還需要更換工具
解決方案:
不要輕易相信專案外部的任何人的看法，這些人可能已經有一些既得利益，不要相信供應商的說法（除非你早已經瞭解），也不要相信白皮書。如果要取得關於應用伺服器的建議，可以在網上取得。還可以下載這些工具進行評估，用它們做一些原型(prototype)，並執行一下其中的案例。(好的供應商都有這樣的案例)。
總而言之，你的專案選擇最好的供應商及工具需要時間，而你可能沒有太多的時間。你可以把選擇範圍限制在3-4個種，然後用一周時間進行比較和檢驗。最後從中選出比較滿意的工具和產品。
備註:
如果你缺少J2EE經驗，則可能會在專案前期就產生問題。在前期所確定的決策會影響整個過程，並進而影響專案的成功。好的J2EE諮詢專家將能夠幫助你選擇好的供應商，並為設計和開發刻劃出一個好的架構。
結論
總而言之，以上10大風險是企業級Java專案開發過程中將面對的主要困難。相信在你的旅程中一定還有更多的陷阱，相信上面所提到的風險已經涵蓋了主要的問題。最後按照優先順序重新列舉一下10大風險：
- 沒有真正理解Java, 沒有真正理解EJB, 沒有真正理解J2EE
- 過度設計(Over-engineering)
- 沒有將業務邏輯和顯示邏輯相分離
- 沒有在開發環境中進行適當的配置
- 選擇了不當的供應商
- 不瞭解你的供應商
- 設計中沒有充分考慮到可擴充性和產品性能
- 過時的開發過程
- 沒有好的架構(Framework)
- 根據市場宣傳決定專案計劃和設計，而非實際技術需求
部落格(Blog)的歷史
終於了解Blog怎麼誕生的!
"博客中國網站董事長方興東指出，部落格最早的原型誕生於一九九三年，原本是一種網路過濾器（filter），功能僅限挑選一些網站，並做些簡單的介紹。一九九四年美國史瓦斯摩爾大學（Swathmore College）大學生霍爾（Justin Hall）建立了第一個Blog，然而卻因受限於技術，直到一九九九年「Blog」名稱正式出現時，全球也不過只有二十三個部落格。
但也在那一年，美國網路工程師威廉斯（Evan Williams）開發出方便市井小民自助架設部落格的網站Blogger後，和其他類似的網路服務商一舉帶動起「部落格全球風潮」，至今全球已經有三千一百萬個部落格（與加拿大一國人口相當）。美國網路產業調查公司Perseus更預估，此一數字在微軟和雅虎相繼推出免費部落格設站服務後，預計到二○○ 五年底將再成長到五千三百萬個，也就是平均一天冒出四萬──當下每過一分鐘，就有二十八個新部落格在世界各地誕生。"
- 摘自 數位時代電子報 "解讀Blog全球旋風", 2005/06/13
"博客中國網站董事長方興東指出，部落格最早的原型誕生於一九九三年，原本是一種網路過濾器（filter），功能僅限挑選一些網站，並做些簡單的介紹。一九九四年美國史瓦斯摩爾大學（Swathmore College）大學生霍爾（Justin Hall）建立了第一個Blog，然而卻因受限於技術，直到一九九九年「Blog」名稱正式出現時，全球也不過只有二十三個部落格。
但也在那一年，美國網路工程師威廉斯（Evan Williams）開發出方便市井小民自助架設部落格的網站Blogger後，和其他類似的網路服務商一舉帶動起「部落格全球風潮」，至今全球已經有三千一百萬個部落格（與加拿大一國人口相當）。美國網路產業調查公司Perseus更預估，此一數字在微軟和雅虎相繼推出免費部落格設站服務後，預計到二○○ 五年底將再成長到五千三百萬個，也就是平均一天冒出四萬──當下每過一分鐘，就有二十八個新部落格在世界各地誕生。"
- 摘自 數位時代電子報 "解讀Blog全球旋風", 2005/06/13
2005年6月14日
多數成功者做著自己最喜愛的工作
Fred Wang(http://fredwang.blogspot.com)
工作如果能與興趣結合那麼即使一天工作12小時也不會覺得苦. 《選對池塘釣大魚》書中，作者雷恩吉爾森引述一項關於美國成功人士的訪談調查，發現九四％以上的人回答成功的關鍵因素都指向一個：「他們都做著最喜愛的工作。」
不過對自己的目標設定要廣一點, 例如 : "網頁程式設計師", 這個範圍比較小, 可以改變目標設定涵蓋網頁設計師, 及網站架構師(Architector), 最好的目標是網站專家.
網站牽涉到的技術能力很廣, 要做頂尖的網站專家, 可能的領域有 :
1.網頁設計(美工設計含靜動態設計, 可用性設計, 可存取性設計)
2.網站應用系統設計(網站技術架構規劃, 電子商務, 電子交易系統, 網頁內容管理系統, B2B, B2C, 電子市集, 電子行銷系統, 客戶關係管理系統, 後勤系統整合, 流量分析系統等等)
3.網站經營與管理(網站企劃與策略規劃, 網路廣告, 網站推廣與行銷, 網站效能管理, 網站系統與資料庫管理, 網站安全管理)
上面從美工, 程式設計, 規劃及管理, 所涉及的能力相當廣, 當然與溝通協調的能力也不可少, 而除了大型公司, 才可能有比較精細的工作角色區分, 而一般企業可能一到二人就要負責這所有的工作, 要成功的做好並不容易. 而且這樣的人才在市場上也少. 市場價值也越高.
其他行業也是, 當競爭者多時, 如何多提升自己增加能力, 多用心, 多努力, 做的比別人好, 哪麼也能成為這行的佼佼者.
參考: 商業週刊916期'選對行業，當黑馬！'
工作如果能與興趣結合那麼即使一天工作12小時也不會覺得苦. 《選對池塘釣大魚》書中，作者雷恩吉爾森引述一項關於美國成功人士的訪談調查，發現九四％以上的人回答成功的關鍵因素都指向一個：「他們都做著最喜愛的工作。」
不過對自己的目標設定要廣一點, 例如 : "網頁程式設計師", 這個範圍比較小, 可以改變目標設定涵蓋網頁設計師, 及網站架構師(Architector), 最好的目標是網站專家.
網站牽涉到的技術能力很廣, 要做頂尖的網站專家, 可能的領域有 :
1.網頁設計(美工設計含靜動態設計, 可用性設計, 可存取性設計)
2.網站應用系統設計(網站技術架構規劃, 電子商務, 電子交易系統, 網頁內容管理系統, B2B, B2C, 電子市集, 電子行銷系統, 客戶關係管理系統, 後勤系統整合, 流量分析系統等等)
3.網站經營與管理(網站企劃與策略規劃, 網路廣告, 網站推廣與行銷, 網站效能管理, 網站系統與資料庫管理, 網站安全管理)
上面從美工, 程式設計, 規劃及管理, 所涉及的能力相當廣, 當然與溝通協調的能力也不可少, 而除了大型公司, 才可能有比較精細的工作角色區分, 而一般企業可能一到二人就要負責這所有的工作, 要成功的做好並不容易. 而且這樣的人才在市場上也少. 市場價值也越高.
其他行業也是, 當競爭者多時, 如何多提升自己增加能力, 多用心, 多努力, 做的比別人好, 哪麼也能成為這行的佼佼者.
參考: 商業週刊916期'選對行業，當黑馬！'
2005年6月10日
公告: 已更新網頁的RSS連結
2004年12月本網站由http://fmwang.blogspot.com改登記網址為http://fredwang.blogspot.com
但是網頁中的rss連結仍是舊的網址, 因此部分RSS reader只會讀到舊網址的內容, 現在已經更正!
Fred Wang 2005/06/10
但是網頁中的rss連結仍是舊的網址, 因此部分RSS reader只會讀到舊網址的內容, 現在已經更正!
Fred Wang 2005/06/10
2005年6月7日
Xoops Add-on模組整理
Fred Wang(http://fredwang.blogspot.com) 20050607
Xoops標準模組有系統模組, 夥伴網站, 友站新聞, 票選, 常見問題及解答(Faq), 精華區, 新聞區, 討論區, 網站連結, 檔案下載等, 除了這些標準模組外, Xoops有許多人致力於開發Add-on模組的開發, 讓Xoops能有更多網站應用功能, 如本文介紹的各種模組, 小型工具到大型的應用都有
主題 :
Plugin 模組
1.xoops討論區 - newbb
2.訪客計數統計模組 - istats
3.線上報名表單 - eGuide
4.萬用嵌入網頁程式 - isstpage
5.文件管理系統 - iContent
6.自訂表單 - Liaise
7.嵌入自製內容模組 -TinyD2.0
8.Blog軟體 - WordPress
9.強悍的電子相簿 - xcgal
10.超讚行事曆模組 - piCal
11.樹狀選單模組 - treemenuxl
12.電子商務模組 - Xoops Shop, osCommerce
13.專案管理模組 - wsproject
14.WebMail系統模組 - SquirrelMail
15.企業內容管理模組 Enterprise-X
16.入侵防護模組 - Xoops Protector
17.文字擷取分類工具模組 - FreeContent
18.事件管理模組 - Agnedax
下面各模組的簡介摘自其模組說明文件
xoops討論區 newbb 2.0.1 Final
用來取代舊版的討論區模組
功能概要：
●結合投票模組(xoopspoll)，能夠擁有投票的功能。
●支援附加檔案上傳，可以利用附加檔案的方式上傳檔案。
●搭配KARMA值(社區威望)，並讓文章可以分別不同威望者的觀看權限。
●能設定必須回覆後才能觀看的權限。
●討論區代表標題圖示。
●可以自己定製樣板圖示並在後台作設定。
●文章評價功能，可以針對文章來做評分，讓文章的可信度或歡迎度公開。
●可以針對不同的討論區設定不同的權限。
●快速回復以及更改log的顯示，新增了直接回覆主題的快速回覆框。
●可選擇編輯模式的切換。
●啟用網路串連格式(RSS)。
●修改過本文時會有修改紀錄顯示。
●精華文章功能，可以標示好的文章為精華文章。
●多樣化瀏覽模式，未讀文章、精華文章或是只顯示未讀文章的瀏覽模式。
●內定搜尋選項，可以根據文章內容、標題或是文章加標題的進階搜尋選項。
●自由排序討論板。
●可以設定某些特定討論區標題類別的前置選項。
●在討論區下方可以有個專屬的誰線線上區塊，依照等級顯示不同顏色的帳號。
●可於後台開啟 HP/MP/EXP 等級顯示模式。
●可以使用真實姓名替代帳號的顯示模式。
●所屬群組顯示欄位對每個發表者在網站裡的所屬群組顯示。
●快速連結下拉式選單，可以方便於通往各討論區的快速連結。
●使用者每進入討論區時下方會有權限列表的顯示。
●可以開關顯示張貼者IP位置於版主或網站管理員。
●版主以上可設定於討論區標題內使用HTML標籤能有多樣變化比較醒目。
●依照設定值，無論是會員或是訪客都能夠有匿名發表的可能。
●可以針對連續發表、編輯訊息、或是刪除的時間限制。
●免責聲明的提醒，可依討論區性質決定是否使用免責訊息。
●結合新聞模組，直接發表文章為新聞。
●文章可以自動轉換為pdf檔。
訪客計數統計模組 istats
功能簡介：
● 訪客計數器
● 每小時、每日、每週、每月流量分析
● 瀏覽頁面分析表
● 訪客系統分析表(瀏覽器、作業系統、解析度、上線主機)
● 可以設定是否顯示計數區塊或是分析區塊
● 日期顯示格式的設定
● 可自訂Cookie的有效時間
● 可自製計數器圖檔
線上報名表單 eGuide
這是一個可以在XOOPS網站內公開活動訊息的模組，同時也支援線上報名表單的生成，可以在線上直接填寫報名申請。報名方式支援人數限制以及自動審核功能，也可以開放讓特定群組新增活動內容。
同時也可開放讓使用者自己登記電子郵件信箱，有新活動發佈時會自動以電子郵件通知已登記的使用者。
萬用嵌入網頁程式 isstpage
instpage 是一個可以讓您把網路上的任一網頁或網站嵌入您的XOOPS2網站中的工具，您只要把他解壓縮，並放到XOOPS2的根目錄底下，然後利用瀏覽器執行：http://網址/instpage.php
即可開始設定嵌入網頁。
文件管理系統 iContent
iContent 是一個XOOPS2專用的文件管理模組，您可以利用它從線上新增網頁，也可以上傳自己的網頁，它具有完整的文件管理後台，您可以自行新增各種資料夾來擺放文件，也可以很方便的啟動、移除或隱藏資料夾或檔案。
自訂表單 Liaise
不錯的表單模組，從連絡站長到問卷調查應用範圍可以相當廣泛。預設一組表單提供參考，其變化可以依照網站需要自己設定，可支援多組不同的表單生成。
嵌入自製內容模組：TinyD2.0 多國語言版
TinyContent是一套相當好用的網站內容編輯模組，您可以利用該模組，在 XOOPS2 網站中崁入任何您所需要的內容。而TinyD則是TinyContent的改良版，因為有時候我們會因為網站需求，而想要同時安裝好幾個TinyContent模組，若您是用原來的TinyContent模組，那麼是很麻煩的，您必須修改設定檔，修改資料庫檔案，還得修改主程式，相當棘手。但是利用此模組，您只要會複製模組目錄，並改個名稱即可做到，而無須修改任何程式，例如：Tinyd0、Tinyd1、Tinyd2...等，最多可安裝 11 個TinyD模組
Blog軟體 WordPress
WordPress是目前最流行的Blog軟體之一，WordPress原始程式官方網頁：
http://wordpress.org/
模組原作者： http://www.kowa.org/
簡體中文化： http://xoops.org.cn/ 作者：phppp(D.J)
繁體中文化： http://briian.com/
強悍的電子相簿 xcgal
此模組是由著名的 Coppermine 電子相簿改編而來的！非常好用！功能強大，除了可開設各類相簿外，還可做電子賀卡，並支援批次上傳，有多種方式可以製作縮圖，此外，還有非常多的區塊可以使用。
超讚行事曆模組 piCal
piCal 是一強大的Xoops2行事曆模組。此模組可以動態產生 iCalendar 的資料檔，亦可經由連結或電腦硬碟資料來匯入 iCalendar 的資料檔。
piCal 也有一些群組軟體的小功能，當然，此模組有完整的行事曆功能，例如有四種的觀看模式：每日（view -Daily）, 每週（Weekly）, 每月（Monthly）, 或整年（Yearly）。
此模組包含英語、日語、德語、西班牙語、法語、荷蘭語、俄語、繁體中文、瑞士語、葡萄牙語等國的語言檔。本站主選單的行事即為 piCal 行事曆，非常適合各種單位使用。
樹狀選單模組 treemenuxl
很可愛的樹狀選單模組，可以用來取代主選單區塊。
電子商務模組 Xoops Shop(osCommerce)
http://www.xoops.org/modules/news/article.php?storyid=1948
http://www.myxoopsshop.org
專案管理模組 - wsproject
WebMail系統模組 - SquirrelMail
SquirrelMail has all the functionality you would want from an email client, including strong MIME support, address books, and folder manipulation.
企業內容管理模組 Enterprise-X
Enterprise-X is a Corporate Presentation module for Xoops Content Management System
入侵防護模組 - Xoops Protector
Xoops Protector 是一個可以讓您的 XOOPS2 免於病毒或各種入侵攻擊的侵擾
文字擷取分類工具模組 - FreeContent
FreeContent allows you not only to present easily a variety of contents but also to make concept/topic oriented WebIntelligence, to organize community discussion with always up to date and fresh content and information.
Freecontent WebDigest uses advanced and powerful Text Retrieving Technics to automatically generate relevant contents for your website.
事件管理模組 - Agnedax
Agenda-X is a flexible and feature riche calendar application for Xoops with recurring events, Smarty templates, Category, Search, Image upload, day-week-month-flat views and (much) more.
Xoops標準模組有系統模組, 夥伴網站, 友站新聞, 票選, 常見問題及解答(Faq), 精華區, 新聞區, 討論區, 網站連結, 檔案下載等, 除了這些標準模組外, Xoops有許多人致力於開發Add-on模組的開發, 讓Xoops能有更多網站應用功能, 如本文介紹的各種模組, 小型工具到大型的應用都有
主題 :
Plugin 模組
1.xoops討論區 - newbb
2.訪客計數統計模組 - istats
3.線上報名表單 - eGuide
4.萬用嵌入網頁程式 - isstpage
5.文件管理系統 - iContent
6.自訂表單 - Liaise
7.嵌入自製內容模組 -TinyD2.0
8.Blog軟體 - WordPress
9.強悍的電子相簿 - xcgal
10.超讚行事曆模組 - piCal
11.樹狀選單模組 - treemenuxl
12.電子商務模組 - Xoops Shop, osCommerce
13.專案管理模組 - wsproject
14.WebMail系統模組 - SquirrelMail
15.企業內容管理模組 Enterprise-X
16.入侵防護模組 - Xoops Protector
17.文字擷取分類工具模組 - FreeContent
18.事件管理模組 - Agnedax
下面各模組的簡介摘自其模組說明文件
xoops討論區 newbb 2.0.1 Final
用來取代舊版的討論區模組
功能概要：
●結合投票模組(xoopspoll)，能夠擁有投票的功能。
●支援附加檔案上傳，可以利用附加檔案的方式上傳檔案。
●搭配KARMA值(社區威望)，並讓文章可以分別不同威望者的觀看權限。
●能設定必須回覆後才能觀看的權限。
●討論區代表標題圖示。
●可以自己定製樣板圖示並在後台作設定。
●文章評價功能，可以針對文章來做評分，讓文章的可信度或歡迎度公開。
●可以針對不同的討論區設定不同的權限。
●快速回復以及更改log的顯示，新增了直接回覆主題的快速回覆框。
●可選擇編輯模式的切換。
●啟用網路串連格式(RSS)。
●修改過本文時會有修改紀錄顯示。
●精華文章功能，可以標示好的文章為精華文章。
●多樣化瀏覽模式，未讀文章、精華文章或是只顯示未讀文章的瀏覽模式。
●內定搜尋選項，可以根據文章內容、標題或是文章加標題的進階搜尋選項。
●自由排序討論板。
●可以設定某些特定討論區標題類別的前置選項。
●在討論區下方可以有個專屬的誰線線上區塊，依照等級顯示不同顏色的帳號。
●可於後台開啟 HP/MP/EXP 等級顯示模式。
●可以使用真實姓名替代帳號的顯示模式。
●所屬群組顯示欄位對每個發表者在網站裡的所屬群組顯示。
●快速連結下拉式選單，可以方便於通往各討論區的快速連結。
●使用者每進入討論區時下方會有權限列表的顯示。
●可以開關顯示張貼者IP位置於版主或網站管理員。
●版主以上可設定於討論區標題內使用HTML標籤能有多樣變化比較醒目。
●依照設定值，無論是會員或是訪客都能夠有匿名發表的可能。
●可以針對連續發表、編輯訊息、或是刪除的時間限制。
●免責聲明的提醒，可依討論區性質決定是否使用免責訊息。
●結合新聞模組，直接發表文章為新聞。
●文章可以自動轉換為pdf檔。
訪客計數統計模組 istats
功能簡介：
● 訪客計數器
● 每小時、每日、每週、每月流量分析
● 瀏覽頁面分析表
● 訪客系統分析表(瀏覽器、作業系統、解析度、上線主機)
● 可以設定是否顯示計數區塊或是分析區塊
● 日期顯示格式的設定
● 可自訂Cookie的有效時間
● 可自製計數器圖檔
線上報名表單 eGuide
這是一個可以在XOOPS網站內公開活動訊息的模組，同時也支援線上報名表單的生成，可以在線上直接填寫報名申請。報名方式支援人數限制以及自動審核功能，也可以開放讓特定群組新增活動內容。
同時也可開放讓使用者自己登記電子郵件信箱，有新活動發佈時會自動以電子郵件通知已登記的使用者。
萬用嵌入網頁程式 isstpage
instpage 是一個可以讓您把網路上的任一網頁或網站嵌入您的XOOPS2網站中的工具，您只要把他解壓縮，並放到XOOPS2的根目錄底下，然後利用瀏覽器執行：http://網址/instpage.php
即可開始設定嵌入網頁。
文件管理系統 iContent
iContent 是一個XOOPS2專用的文件管理模組，您可以利用它從線上新增網頁，也可以上傳自己的網頁，它具有完整的文件管理後台，您可以自行新增各種資料夾來擺放文件，也可以很方便的啟動、移除或隱藏資料夾或檔案。
自訂表單 Liaise
不錯的表單模組，從連絡站長到問卷調查應用範圍可以相當廣泛。預設一組表單提供參考，其變化可以依照網站需要自己設定，可支援多組不同的表單生成。
嵌入自製內容模組：TinyD2.0 多國語言版
TinyContent是一套相當好用的網站內容編輯模組，您可以利用該模組，在 XOOPS2 網站中崁入任何您所需要的內容。而TinyD則是TinyContent的改良版，因為有時候我們會因為網站需求，而想要同時安裝好幾個TinyContent模組，若您是用原來的TinyContent模組，那麼是很麻煩的，您必須修改設定檔，修改資料庫檔案，還得修改主程式，相當棘手。但是利用此模組，您只要會複製模組目錄，並改個名稱即可做到，而無須修改任何程式，例如：Tinyd0、Tinyd1、Tinyd2...等，最多可安裝 11 個TinyD模組
Blog軟體 WordPress
WordPress是目前最流行的Blog軟體之一，WordPress原始程式官方網頁：
http://wordpress.org/
模組原作者： http://www.kowa.org/
簡體中文化： http://xoops.org.cn/ 作者：phppp(D.J)
繁體中文化： http://briian.com/
強悍的電子相簿 xcgal
此模組是由著名的 Coppermine 電子相簿改編而來的！非常好用！功能強大，除了可開設各類相簿外，還可做電子賀卡，並支援批次上傳，有多種方式可以製作縮圖，此外，還有非常多的區塊可以使用。
超讚行事曆模組 piCal
piCal 是一強大的Xoops2行事曆模組。此模組可以動態產生 iCalendar 的資料檔，亦可經由連結或電腦硬碟資料來匯入 iCalendar 的資料檔。
piCal 也有一些群組軟體的小功能，當然，此模組有完整的行事曆功能，例如有四種的觀看模式：每日（view -Daily）, 每週（Weekly）, 每月（Monthly）, 或整年（Yearly）。
此模組包含英語、日語、德語、西班牙語、法語、荷蘭語、俄語、繁體中文、瑞士語、葡萄牙語等國的語言檔。本站主選單的行事即為 piCal 行事曆，非常適合各種單位使用。
樹狀選單模組 treemenuxl
很可愛的樹狀選單模組，可以用來取代主選單區塊。
電子商務模組 Xoops Shop(osCommerce)
http://www.xoops.org/modules/news/article.php?storyid=1948
http://www.myxoopsshop.org
專案管理模組 - wsproject
WebMail系統模組 - SquirrelMail
SquirrelMail has all the functionality you would want from an email client, including strong MIME support, address books, and folder manipulation.
企業內容管理模組 Enterprise-X
Enterprise-X is a Corporate Presentation module for Xoops Content Management System
入侵防護模組 - Xoops Protector
Xoops Protector 是一個可以讓您的 XOOPS2 免於病毒或各種入侵攻擊的侵擾
文字擷取分類工具模組 - FreeContent
FreeContent allows you not only to present easily a variety of contents but also to make concept/topic oriented WebIntelligence, to organize community discussion with always up to date and fresh content and information.
Freecontent WebDigest uses advanced and powerful Text Retrieving Technics to automatically generate relevant contents for your website.
事件管理模組 - Agnedax
Agenda-X is a flexible and feature riche calendar application for Xoops with recurring events, Smarty templates, Category, Search, Image upload, day-week-month-flat views and (much) more.
訂閱：
文章 (Atom)