在專案管理領域中，有PMI（國際專案管理學會，總部設在美國）與IPMA（國際專案管理協會，總部設在荷蘭）之兩大不同體系。PMI運用在企業界，IPMA被學術界所重用；另外PMI是基於全球化的考量，如目前全球化語言是英文，反觀，歐洲較注重在地文化，強調各國在地化特色。
美國應用專案管理領域非常廣泛，包含最難大量生產的電影業，好萊塢電影是美國的藝術事業，電影使用專案管理手法，讓流程標準化，其衡量指標為「票房」，讓票房顯示出電影事業的競爭力、績效，像是「鐵達尼」、「哈利波特」，這些都是歐洲的小說，卻在美國拍攝成電影，票房獨步全世界。相對的，歐洲強調在地文化，例如：法國是美學電影的代表、德國的民族電影代表、義大利的寫實電影代表等，這些差異顯示出歐洲在地文化與全球化走在兩種截然不同的軌道上。
在認証制度體系方面，也是有分PMP（Project Management Professional，專案管理師）和IPMA。其中PMP是以美國PMI的統一標準核發證照，取得PMP資格者即為「專案管理專業人士」，全世界只有一種標準，不管您是在美國，日本，台灣或大陸水準統統一樣；而IPMA是以各會員國依不同程度檢定認可認可發與證照，然而其分級檢定界線模糊，像是托福、 TOEIC，而檢定後的核定標準以「專案的職稱」來分界，例如：D級等同於專案副理、A級等同於專案副總，假如今天一個學生考取IPMA的D級證照就等同於專案副理，但其專案實務能力是否等同於專案副理，其實是一個問號，專案人仕考取A級即可擔任公司專案副總嗎？這名稱的設計在企業會有些許的爭議性。
若是以通行性來說，由於PMP由美國PMI統一發照，通行於世界各地，而IPMA是以歐洲各國為大本營，由各會員國自行發照，而IPMA由台灣認定核可程度,，到其它歐洲國家認定卻不一定相同，又各國認証名稱的不一致，大陸叫IPMP、台灣稱IPMA、美國稱PMC。
PMP分佈141國家（遍及五大洲），有美洲的美國加拿大、亞洲的大陸日本新加坡、歐洲的德國英國、大洋洲的澳洲、非洲的南非…等；而IPMA都集中在 42國家（以歐洲為主），波蘭、捷克、塞爾、烏克蘭、匈牙利、葡萄牙、羅馬尼亞…等歐洲國家，少數非歐洲國家如：伊郎、南非、科威特…等。
應用方面，PMP為企業界及實務界所重用，而IPMA為學術合作之領域所重視。像是中鋼、台積電、日月光、104人力銀行、精誠資訊等對於員工PMP取得的要求，又或者今天想從副理晉升為經理、經理晉升為處長，PMP證照即是很棒的考核標準；IPMA以教授教學為主，因業界專案實務經驗有限，故偏向理論論點 出發，合作對象與民間學校龍華科技大學，大漢或育英護校等尚有其它學術單位合作，以上僅是兩者之差異，在不同的領域中各領春秋。
閱讀全文...
這3大社群套件各有擅長，並且都源自相同的Linux核心--2.6.27、使用相同的GNOME 2.24，也經常名列DistroWatch.com普及率調查的前茅。Ubuntu經常是最受歡迎的Linux套件；OpenSUSE已站穩歐洲市場，並積極揮軍美國；由Red Hat資助的Fedora近幾年雖然的普及率雖有下滑，但由於Red Hat身為最大的Linux公司，Fedora也經常率先嘗試新技術，因此Fedora依然位居重要地位。
Ubuntu是以容易使用而聞名並成為最普及的Linux套件，然而擁有廣大的社群支援（例如論壇和Wiki文件，台灣的Ubuntu社群也很活躍），更是Ubuntu深受使用者喜愛的重要原因。儘管Ubuntu適合有經驗的Linux玩家，但更適合初學者，尤其是完全沒有Linux經驗而想要嘗試Linux的電腦使用者。
Ubuntu還包含了戴爾的DKMS（Dynamic Kernel Module Support），這項功能會在使用者更新Linux核心時，縱使Linux核心尚未內建支援顯示卡或其他硬體，也能自動下載並更新符合機器的驅動程式。這就不用擔心新增硬體或更新Linux核心之後而導致系統無法運作。
OpenSUSE兼具了用戶端桌面與伺服器能力，對於經常得在混合了Linux、Unix、Windows的企業網路環境工作，OpenSUSE對此提供了最佳的支援。此外目前最新版本內建的是Novell客製過的OpenOffice.org 3.0，這個版本能讓使用者讀、寫微軟目前所有的Office檔案，包括Office 2007的Open XML格式。
OpenSUSE不只提供了相當優越且穩定的伺服端能力，更能在安裝時讓管理者自動設定Web、檔案、資料庫等伺服器。而除了提供KVM（Kernel-based Virtual Machine）、Xen、VirtualBox等虛擬化功能，OpenSUSE也內建了Mono--Linux開放源碼版的Microsoft .NET。
Fedora經常扮演實驗先鋒的角色，率先將新技術加入Linux套件讓更多人嘗試，而加入的新技術也會隨著不斷的改進而逐漸穩定、成熟；例如PulseAudio在Fedora已經有相當傑出的表現。此外，Fedora也加入了許多值得注意的新功能，包括利用LinuxTV V4L-DVB和Linux UVC讓Fedora擁有更好的webcam支援。
連線共享是Fedora 10特有的新功能，這能讓電腦同時兼具Wi-Fi AP/路由器，將頻寬分享給其他電腦。而能簡化軟體安裝的PackageKit功 能，也獲得相當的改進，不僅能簡化軟體搜尋、下載、安裝流程，甚至也能自動辨識出媒體播放程式所缺少的編碼/解碼器，而且找出並自動安裝適當的編碼/解碼器（雖然目前有時候還會有點小狀況，但Red Hat承諾會再改善）。另一項特點是從USB隨身碟安裝、執行Fedora，這等於能將個人的桌面和工作資料帶著到處跑；而且Fedora 10還能加密家目錄，以免隨身碟遺失而致資料外洩。
由於實驗本質使然，Fedora經常內建較為先鋒、前進的功能，但這類的功能往往會讓Fedora不適合用在關鍵、重要的工作。但是對Linux專家，或如果想在第一時間搶先瞭解尖端技術，Fedora就是最佳選擇。
總結這3套Linux套件：Ubuntu是初學者最佳選擇，OpenSUSE提供很好的商用 功能--尤其適合橫跨Windows和Linux環境的人，Fedora則較為適合Linux專家。但不論所選為何，目前這些多元多樣的套件不只展現出 Linux桌面的成熟，也證明人人都有適合的Linux套件。
http://distrowatch.com
閱讀全文...
Spring最初是Rod Johnson在2002年由其著作Expert One-on-One: J2EE Design and Development中提出的，另外一本書Expert One-on-One J2EE Development without EJB更進一步闡述了在不使用EJB（Enterprise JavaBean）開發J2EE企業級應用的一些設計思想和具體的作法（題外話：EJB是sun的伺服器端元件Model，最大的用處是部署分散式應用程式，類似微軟的.com技術。Sun在2006年5月2日發布了JSR 220定義，也就是EJB3.0，企圖減輕EJB以往開發過於複雜以及不必要的負擔。參見-
伺服器端元件Model－EJB3.0(Enterprise JavaBean 3.0)論述）。
Spring在2004年初發佈1.0版本，到2006年10月3日發佈了2.0版本，基本上維持著每半年就會有一次大的更新，可到http://www.springsource.org/下載最新版本的Spring。
Spring是一個應用於J2EE領域的輕量應用程式框架，其核心是一個IoC（Inversion of Control）以及AOP（Aspect-oriented programming）。在核心上面的一個主要部份是資料存取DAO框架，包括一個自己的JDBC資料存取封裝以及對眾多ORM框架的工具集支持。Spring內置了一個功能強大、靈活的Web MVC框架Spring MVC框架，以提供快速的Java Web應用程式開發，在程式開發中，程式開發者可以直接使用Spring框架內建的Spring MVC框架。除此之外，對於現在比較流行的各種層面上的框架（如Hibernate、JSF、Struts等），Spring也提供了與它們相互整合的方案。
Spring框架系統架構如圖，從圖中看出Spring提供了很多J2EE應用的基礎設施及解決方案，便於開發J2EE應用。
其中Core是框架的最基礎部分，提供IoC（Inversion of Control，控制反轉）和DI（Dependency Injection，依賴注入）特性。所謂的控制反轉是指控制權由程式改到Spring Container（容器），控制權的移轉，是所謂的反轉；或可說是依賴注入，將原先程式間的耦合降到最低，改由Spring容器注入程式間的關連。使用IoC通常會使得程式碼非常清晰，更為重要的是，IoC可以使得程式碼之間、類別與類別之間有很好的解耦性。DI有三種形式：Setter-based、Constructor-based、Getter-based，Spring推薦使用第一種方式，Setter-based類似典型的JavaBean，帶有一個無參數的構造函數和setter方法。
BeanFactor代表了Spring的心臟，可以配置和管理幾乎所有的Java類別，在存取和操作IoC的初期充當了IoC容器的作用。然而在大多數的情況之下，不會直接使用BeanFactor而是使用ApplicationContext，因為ApplicationContext具有更多的企業級特性如多國語言支援、資源存取、事件傳播和多實例載入等等。
Bean在Spring容器中大致要經歷以下四個階段：Bean定義、初始化、準備狀態以及銷毀。
Spring的AOP是OOP（物件導向程式設計）的延續，提供了符合AOP Alliance規範的層面導向程式設計（Aspect-Oriented Programming）的具體實現，讓使用者可以定義，像方法攔截器（method-interceptors）和切入點（PointCuts），從軟體設計上看，通過這樣的方式可以降低耦合性（coupling），提高內聚性（cohesion），從而在軟體結構上得到改善。
DAO模式是一種資料存取物件模式，它通過抽象方法來提供資料存取的介面，這樣便消除了冗長乏味的JDBC編碼，並且通過這樣的封裝方式更容易為程式設計提供介面，而且對所有的POJO適用。
ORM封裝提供了物件關係對應的API介面，使用ORM工具集的產品除了提到過的Hibernate，還包括了如JDO等產品。
<未完 待補充更新>
閱讀全文...
Struts框架最早是作為Apache Jakarta專案的組成部分問世運作，專案的創立者希望通過對該專案的研究，改進和提高JAVA Server Pages、Servlet、標籤庫(tag library)以及物件導向的技術水準，它的目的是為了減少在運用MVC設計模型來開發Web應用的時間。
建立基於Struts框架的web應用程式最快捷的方式就是利用Struts框架發佈包中包含的struts-blank.war文件。該檔不僅定義了struts web應用程式的標準的目錄結構而且還包含了開發struts web應用程式所必需的包。
如果使用Eclipse IDE作為開發工具，並部署在應用伺服器Tomcat 5.0中執行，然後再import struts-blank.war進來。由於struts框架本身就是基於servlet，因此需要將tomcat目錄下common\lib中的servlet-api.jar拷到strutsSample\WebContent\WEB-INF\lib中。
在探討Struts MVC運作架構之前我們先來看看基本的MVC運作模式，如圖所示：
所有進入到系統中的Request都會導給一個Controller程式，由Controller來判斷目前這個Request必須交由哪一個程式處理(那一個Request必須交由哪一個程式處理可能是設定在另外一個地方)，接著便會呼叫執行該處理程式，並將收到的Request當作參數傳給該程式。在處理過程中需要進行商業邏輯處理的部分就會呼叫執行Model中的程式，Model處理完之後再將結果回傳給Controller，Controller再將結果傳給指定的View來進行畫面呈現。在這個架構中Controller是所有Request的唯一進入點，Model的部分只負責處理系統中的商業邏輯，畫面呈現則全部都由View來負責。
Struts的運作模式是採用MVC的架構，整個運作方式大致如圖所示。當Request進入到Struts時會導給一個ActionServlet來處理，這個程式會根據設定檔struts-config.xml中的設定呼叫執行我們所撰寫的Action處理程式，並將Request當作參數傳給這個Action處理。Action在處理過程中會呼叫一些商業邏輯物件(Business Objectc)中的程式存取後端的資料庫；當Action處理完之後會將結果回傳給ActionServlet，最後ActionServlet再將這個結果可以在struts-config.xml中設定一些JavaBean(ActionForm)來接收Request中的資料，此時Struts便會幫我們將資料塞到JavaBean中，讓我們可以在Action中直接取用，讓我們可以在Action中直接取用，在使用上會比較方便。
我們在使用Struts開發系統時，必須撰寫流程控制程式(Action)、商業邏輯處理程式(Business Object)、畫面呈現程式(JSP)並在設定檔(struts-config.xml)中設定這幾個元件之間的運作關係。當然，如果在流程控制與商業邏輯處理程式之間有使用到一些物件來當作資料傳遞的參數(DTO，Data Transfer Object)，那麼這些傳遞資料的物件也必須由我們自行撰寫。
閱讀全文...
在SQL Server中，我們可以使用二種方法來設定自動化的資料處理規則：
1.
條件約束(Constraint)可以直接設定於資料表內，通常不需另外撰寫程式。但此方法只能進行比較單純的運作，包括自動填入預設值(DEFAULT)，確保欄位資料不得重複(PRIMARY KEY/UNIQUE KEY)、限制輸入值在某個範圍內(CHECK)、維護資料表間的參考完整性(FOREIGN KEY)...等。
2.
觸發程序(Trigger)是針對單一資料表所撰寫的特殊預存程序，當該資料表發生INSERT、UPDATE或DELETE時會自動被觸發(執行)，以進行各項必要的處理工作。由於是撰寫程式，因此無論是單純或複雜的工作都可一手包辦。
當然，如果只是單純的自動化工作，我們應儘量利用條件約束來完成，因為這樣做一方面容易設定及維護，另一方面執行效率也會比較好。只有當條件約束無法滿足實際需求時，才應考慮使用觸發程序來處理。
那麼，觸發程序到底有什麼特異功能呢？底下來看幾個例子：
檢查所做的更改是否允許：
雖然我們可以用資料表的條件約束來維護資料完整性，例如CHECK、PRIMARY KEY/UNIQUE KEY、FOREIGN KEY等，但觸發程序可以做更多樣、更複雜的檢查。例如同時檢查許多個資料表，或使用IF...ELSE等來做更有彈性的檢查。
‧進行其他相關資料的更改動作：
例如當某筆訂單被取消時，我們可以利用觸發程序去自動刪除相關的送貨單資料，並將業務員的獎金扣一半；或是在更改員工的薪資時，將更改的日期及原薪資存入另一個薪資異動資料表中。
‧發出更改或預警的通知：
例如當有新進員工的資料被輸入時，觸發程序可以自動發Mail通知該部門的所有人員；或是當庫存量小於安全量時，即發Mail通知倉庫管理員要趕快進貨。
‧自訂錯誤訊息：
當操作不符合條件約束時，所回應給前端應用程式的錯誤訊息都是固定的內容。利用觸發程序，則可以回應我們自訂的錯誤訊息。
‧更改原來所要進行的資料操作：
利用SQL Server 2005的INSTEAD OF觸發程序，我們可以撰寫程式來取代原本應該進行的資料操作。例如當新增一筆記錄時，我們可以將該記錄的資料另做處理，而不存入資料表中。
‧檢視表也可以有觸發程序：
檢視表中的計算欄位通常是不允許更改的，但同樣是利用INSTEAD OF觸發程序，我們可以打破這個限制，將預備要更改的資料欄截出來另外處理。例如可將使用者輸入的地址先分解成縣市與街道二部份，再分別存入縣市與街道欄位。
其實觸發程序就像是倉庫的管理員一樣，當有貨物要進出時，管理員即會出面做查核或協調，以維護整個倉庫的正常運作。因此，如果您是資料庫的管理者(DBA，DataBase Administrator)，那麼就應該好好利用觸發程序的功能，為每個重要的資料表都設計一個最佳的倉庫管理員，這樣就不用擔心使用者胡作非為，或是不按照牌理出牌了。
觸發程序的種類與觸發時機
觸發程序可分為2種：
‧AFTER觸發程序：這類的觸發程序要在資料已變動完成之後(AFTER)，才會被啟動並進行必要的善後處理或檢查。若發現有錯誤，則可用ROLLBACK TRANSATION敘述將此次操作所更動的資料全部回復。
‧INSTEAD OF觸發程序：INSTEAD OF是"取代"的意思，就是這類觸發程序會取代原本要進行的操作(例如新增或更改資料的動作)，因此會在資料變動之前就發生，而且資料要如何變動也完全取決於觸發程序。
INSTEAD OF觸發程序能夠適用於資料表及檢視表(View)上；而AFTER觸發程序則只能使用於資料表。
另外，當我們在建立觸發程序時，還必須指定程序要被觸發的操作時機：INSERT、UPDATE或DELETE，至少要指定一種，當然一個觸發程序也可同時指定二種或三種時機。在同一個資料表中，我們可以建立許多的AFTER觸發程序，但INSTEAD OF觸發程序針對每種操作(INSERT、UPDATE、DELETE)最多只能各有一個。
如果針對某操作同時設定了INSTEAD OF及AFTER觸發程序，那麼只有前者會被觸發，後者未必會被觸發。
觸發程序的建立與修改
用SQL建立觸發程序的簡易語法如下：
CREATE TRIGGER trigger_name
ON {table | view}
[WITH ENCRYPTION]
{FOR | AFTER | INSTEAD OF} { [DELETE] [,] [INSERT] [,] [UPDATE]}
AS
sql_statements
閱讀全文...
當我們在撰寫SQL程式時，多少都會用到一些系統內建的函數，例如GETDATE()、CAST(...)等。而SQL Server 2005的「使用者自訂函數」功能，則讓我們也可以自己來建立函數，然後直接應用於SQL敘述或運算式中。
自訂函數其實和預存程序是很類似的，都是由多行T-SQL敘述所組成的程式單元。不過它們之間還是有一些明顯的差異：
1.預存程序只能傳回一個整數值；而自訂函數則可傳回各種資料型別的值(但text、ntext、image、timestamp、cursor及rowversion除外)，甚至包括了sql_variant及table型別。
2.預存程序可以經由參數來傳資料(將參數設為OUTPUT)；但自訂函數則只能接收參數，不可由參數傳回資料。
3.在預存程序中可以做任何的資料異動，例如新增或修改資料、更改資料庫的設定...等；但自訂函數則不允許更改資料庫的狀態或內容。
4.預存程序必須以EXECUTE來執行，因此不能使用在運算式之中，例如myProc會傳回2，那麼「SET @var=myProc」或「SELECT * FROM myProc」都會造成錯誤。而自訂函數則除了可用EXECUTE來執行外，也可用於運算式中，並以傳回值來取代其名稱，例如假設myFun(3)會傳回"Good"，則「SET @var=myFun(3)+'!'」就相當於「SET @var='Good'+'!'」。
一般來說，預存程序比較適合做一些對資料庫的操作或設定，其執行結果通常不必傳回，或將結果傳回到執行該程序的應用程式中(例如將SELECT敘述的結果傳回到SQL查詢或前端應用程式中)；而自訂函數則適用於計算或擷取資料，然後將結果傳回給呼叫它的運算式或SQL敘述(例如SELECT或FROM子句)中使用。
自訂函數的建立
您可以在SQL Server Management Studio中建立自訂函數，其操作方法也和預存程序差不多，只是SQL語法有所不同而已：
自訂函數依傳回值及函數內容可分為兩大類：
1.純量值函數(Scalar-valued function)：這類函數會傳回單一的資料值，而資料值的型別可以是除了text、ntext、image、cursor及rowversion(timestamp)之外的任何型別。若是傳回table型別的資料，則歸屬於下列二類函數。
2.傳回資料集(Rowset)的自訂函數：這類函數可傳回一個table型別的資料集，依其定義語法的不同，又分為2小類：
‧嵌入資料表值函數(Inline table-valued function)：或稱為「行內資料集函數」。函數的內容僅有一個SELECT敘述，而傳回值即是該SELECT的查詢結果。
‧多重陳述式資料表值函數(Multistatement table-valued function)：或稱為「多敘述資料集函數」。函數內容包含許多的敘述，而最後也會傳回一個table型別的資料集。
閱讀全文...
