Unified Modeling Language 統一塑模語言

Unified Modeling Language縮寫為UML，中文普遍翻譯為「統一塑模語言」(國立編譯館學術名詞資訊網上面是「統一模型化語言」)，通常我們都用UML稱之，UML和程式語言一樣是有版本區別，目前最新的版本是2.3版，2.X版的UML通稱為UML 2.0。

UML的規範(Specification )文件分成兩部分，一部分為UML infrastructure(基礎結構)，定義UML語言的基礎語法。另一部分是UML Superstructure(上層結構)，則是定義使用者延伸的語法。兩者互補而構成完整的UML視覺化語言(Visual Language)，兩個規範文件總共大約一千頁左右，一般人大概不會去看的！所以...

這裡推薦兩本對於學習UML有助益的書籍。第一本是「UML精華第三版」，這本可說是僅寫到UML精華之處，對於初學者來說建議瀏覽過一遍有印象就好，後續學習UML更能體會作者所說的奧義，不急著第一次就看懂。第二本是「UML物件導向系統分析與設計」，雖然沒有涵蓋完整的UML內容，但是淺顯易懂平易近人，加上這本書從實務開發上介紹UML讓讀者更有感覺！

Martin Fowler著，趙光正譯，UML精華第三版：增訂嵌入式系統與工作流程概念，台北：台灣培生教育出版：碁峰資訊發行，2007。
(原書名：UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3/E)

游峰碩，UML物件導向系統分析與設計，台北：博碩文化，2010。

目前UML 2.3中定義了14種圖(Diagram)，分成結構圖(Structure Diagram)與行為圖(Behavior Diagram)兩大類，如下所述：

• 結構圖(Structure Diagram)
• 類別圖(Class Diagram)
• 合成結構圖(Composite Structure Diagram)
• 元件圖(Component Diagram)
• 配置圖(Deployment Diagram)
• 物件圖(Object Diagram)，第一版是實例圖(Instance Diagram)
• 套件圖(Package Diagram)
• 輪廓圖(Profile Diagram)
• 行為圖(Behavior Diagram)
• 活動圖(Activity Diagram)
• 使用案例圖(Use Case Diagram)
• 狀態機圖(State Machine Diagram)
• 互動圖(Interaction Diagram)
• 循序圖(Sequence Diagram)
• 通訊圖(Communication Diagram)，第一版是合作圖(Collaboration Diagram)
• 互動概圖(Interaction Overview Diagram)
• 時序圖(Timing Diagram)

結構圖指出物件於系統中的靜態結構(與時間無關)，而行為圖則用於表現物件的動態行為，UML一靜一動，其語言定義相當地有系統！不過學習UML要注意一點，每個Diagram之間其實都有關聯性，僅學習一種Diagram會造成見樹不見林的感覺，可是若學習UML全部則會有見林不見樹的感覺，我想這是學習UML必經的困惑之一。

這次推薦兩本書籍當中都有提到軟體開發流程和物件導向分析與設計(屬於方法論的部分)，UML存在的目的也就是應用在開發、分析與設計之中，若能應用UML於此過程中，我認為學習上將可避免只見樹或只見林的窘境！值得注意的是，UML是創始於Grady Booch, Ivar Jacobson與 James Rumbaugh三位物件導向大師之手(請參考Martin Fowler著的「UML精華第三版」書中1.3節)，這是否代表UML只能應用於物件導向程式語言(OOP)之上？

上述所說的是開發方法論所用的描述語言，從工具的角度來看，目前微軟在「Visual Studio 2010 Ultimate 企業旗艦版」工具中已經支援五種最常見的UML Diagram，並且整合程式碼撰寫開發流程，我認為對於UML具有指標性意義(不是紙上談兵而已)，這五種UML分別是：

• 行為圖(Behavior Diagram)
• 使用案例圖(Use Case Diagram)
• 活動圖(Activity Diagram)
• 循序圖(Sequence Diagram)
• 結構圖(Structure Diagram)
• 元件圖(Component Diagram)
• 類別圖(Class Diagram)

使用案例圖說明使用者與軟體系統之間的關係，而活動圖說明使用案例的運作流程，循序圖則解釋活動圖運作時物件之間的互動情形。軟體系統使用元件圖將系統模組化設計，而每個元件中則包含多個類別組成，這部分由類別圖說明物件的設計。從開發上來看這五個Diagram彼此互相關聯，也難怪Visual Studio 2010會引進使用。

對於未來，期望UML可以順利發展純熟，Martin Fowler提到UML的三個使用方式：草稿(Sketch)、藍圖(Blueprint)、程式語言(Programming Language)。目前大多數都將UML使用於設計草稿，藍圖方式則有賴於友善的開發工具配合(如Visual Studio之類)，最困難的就是直接將UML當作一種程式語言使用，相信這會是夢想中的軟體開發方式！

###

NTUT 100th Anniversary Commemorative Stamp Folio

國立台北科技大學的校慶大約都在10月底11月初(2010年校慶是10月30日)，今年比較特別的是建校已經99年，明年(西元2011年)將是建校百年，因此今年校慶主題是「傳承九九，卓越一百」。

為了紀念這個特別的日子，與大家分享今年11月1日首次發行的紀念郵摺！

國立台北科技大學建校百年紀念郵摺
National Taipei University of Technology
NTUT 100th Anniversary Commemorative Stamp Folio



下方是紀念郵摺的細部內容：

PHP Client URL Library 用戶端程式庫

今天介紹PHP的Client URL Library，簡稱cURL，我們利用cURL將可以使被動處理的伺服器應用程式具有主動請求的程式。

cURL提供我們和其他伺服器通訊的功能(當作一個Client端)，支援的通訊協定有HTTP、HTTPS、FTP、Gopher、Telnet、DICT、file與LDAP通訊協定，詳細的說明請參考PHP網站文件，位於PHP Manual > Function Reference > Other Services之中。

主要是因為小黑學弟最近架設了新的網站，在 php.ini設定檔中開啟cURL功能，明明就是一個很簡單的設定，可是怎麼設定都發生錯誤，錯誤訊息是：

PHP Warning: PHP Startup: Unable to load dynamic library 'c:\\php\\ext\\php_curl.dll' - \xa7\xe4\xa4\xa3\xa8\xec\xab\xfc\xa9w\xaa\xba\xbc\xd2\xb2\xd5\xa1C\r\n in Unknown on line 0
[Sat Nov 06 00:00:00 2010] [notice] Apache/2.2.16 (Win32) PHP/5.2.14 configured -- resuming normal operations
[Sat Nov 06 00:00:00 2010] [notice] Server built: Jul 30 2010 16:15:37
[Sat Nov 06 00:00:00 2010] [notice] Parent: Created child process 7520
PHP Warning: PHP Startup: Unable to load dynamic library c:\\php\\'ext\\php_curl.dll' - \xa7\xe4\xa4\xa3\xa8\xec\xab\xfc\xa9w\xaa\xba\xbc\xd2\xb2\xd5\xa1C\r\n in Unknown on line 0
[Sat Nov 06 00:00:01 2010] [notice] Child 7520: Child process is running
[Sat Nov 06 00:00:01 2010] [notice] Child 7520: Acquired the start mutex.
[Sat Nov 06 00:00:01 2010] [notice] Child 7520: Starting 64 worker threads.
[Sat Nov 06 00:00:01 2010] [notice] Child 7520: Starting thread to listen on port 80.

經過十多個小時的努力debug查明原因，「無法載入動態程式庫php_curl.dll」就是因為PHP版本，PHP 5.2.14版本不知道是什麼原因造成php_curl.dll錯誤。經過實地測試 5.2.6至5.2.13版的PHP，這些版本都能夠成功使用cURL功能。

經過這次的經驗，我們必須記住一件事：軟體版本的更新雖然存在著「向下相容」與「修正錯誤」的原則，但是永遠不代表既有功能不會發生問題。當時遇到這個cURL問題一直以為是設定錯誤，直到最後才發現是版本問題...

難道這就是「墨菲定律(Murphy's law)：凡是可能出錯的事均會出錯。」

###

Be Your Personal Best 做最好的自己

感謝李開復先生，世界因你不同。 自從上次閱讀李開復先生著作的「世界因你不同」之後，接連買了幾本他的書籍，這次和大家分享這本「做最好的自己」，我極力推薦這本書給各位！不過，由於這本書是先在大陸出版，爾後由聯經出版，對於書中一些字詞是用大陸習慣用語，沒有翻成台灣習慣用語稍微感到遺憾與不解。 建議大家的閱讀以「世界因你不同」為先，而「做最好的自己」為後，兩本書籍的內容有些連貫性，先看李開復先生的故事，再來瞭解他成功的意義與方法。 Be Your Personal Best

李開復，做最好的自己，台北：聯經，2006。

李開復先生在這本書中提出他的「成功同心圓」理論(價值觀)，並且詳述應有的方法(態度與行為)，如下圖所述，最底層(內部)為價值觀，接著是態度，最上面(外面)是行為。

整本書就是講述「成功同心圓」，總共15章。李開復先生在第一章先定義「成功」，他強調多元化成功才是真正的成功，接著第二章闡述價值觀，再接著六種態度與六種行為共12章，最後總結一章說明我們必須「完整而均衡」，因此，1+1+6+6+1=15章。

注意到，這六個態度分別是中國文化與西方文化的對偶關係，因為彼此各別強調：

• 中國文化：同理心、自省、胸懷。
• 西方文化：  積極  、自信、勇氣。

李開復先生提出的「成功同心圓」
行為	努力學習	人際交流	有效執行	發現興趣	追尋理想	合作溝通
態度	積極	同理心	自信	自省	勇氣	胸懷
價值觀	誠信

最後，真心推薦李開復先生的「做最好的自己」(定價NT$399)，我認為非常適合高中大學的青年學子一起閱讀。我認為如果我能早一點知道，也許就可以更進一步知道什麼是成功而努力前進了，這趟旅程可以更順心一點！

「人人都可以成功，我可以選擇我的成功」。──李開復

---

最值得記住李開復先生所說的一句話：

有勇氣來改變可以改變的事情，
有胸懷來接受不可改變的事情，
有智慧來分辨兩者的不同。

---

以下是「做最好的自己」的重點摘要。

「做最好的自己」是成功的途徑
價值觀+態度+行為=成功的秘訣

National Taipei University of Technology 台北科技大學

捐贈書籍的時間又到了，今年度捐贈的書籍清單如下表所述，主要都是Web相關的書籍，這次改買幾本軟體開發相關的書籍，一方面是自己讀了不錯，另一方面是近期在Web領域沒有值得購買的新書(缺乏新技術...?!)。


書籍清單：(受贈者：國立台北科技大學的圖書館)

書名	作者	出版社
ASP.NET MVC 2開發實戰	黃保翕	悅知文化
ASP.NET 4.0網站開發實戰	趙敏翔	悅知文化
Professional XHTML+CSS：網頁設計師的創意與實踐	益子貴寬‧堀內敬子‧小林信次‧千貫りこ‧伊藤學‧山田あかね‧西畑一馬	悅知文化
嵌入式系統開發之道：菜鳥成長日誌與專案經理的私房菜	邱毅凌	悅知文化
程式設計範式與OOP的思考術：冒號老師的十三堂課	鄭暉	博碩
軟體測試之道：微軟測試團隊的成功經驗、方法與技術	Alan Page, Ken Johnston, Bj Rollison著，林宗斌譯	基峯

今年度捐贈書籍10本，金額在新台幣5000元以內，主要是為了符合自己的計劃，自己現在開始人生另外一個階段，離開學校學習準備成家立業，這一切都必須要有一些財富(有形與無形的財富)，不能再像學生時代揮霍沒有壓力了。因此，評估自己的能力之下，訂定每年新台幣5000元的捐贈書籍金額，這大概可以買10本左右的中文書籍，而且行程安排為學校新學年的期間行動。

題外話，記得去年jasper312對於捐贈書籍提出「集中置放」的理論，也就是說：書籍很佔空間，把書捐給圖書館，要用的時候再去借，而且通常看完了也不會再翻第二遍，這樣的模式似乎很有效益！把圖書館當作倉庫使用，利己也利他人，重點是倉庫不用付錢啊！借書的人也不用付錢。

###

Panels in WPF 面板

Windows Presentation Foundation (WPF)的面板(Panel)功能主要是用來設計版面的配置(佈置)(layout)，主要用於配置的面板有六種：Canvas、DockPanel、Grid、StackPanel、VirtualizingStackPanel 與 WrapPanel。

Panel類別的繼承階層架構：

• System.Windows.Media.Visual
• System.Windows.UIElement
• System.Windows.FrameworkElement
• System.Windows.Controls.Panel(抽象類別)
• Canvas
• DockPanel
• Grid
• TabPanel
  [System.Windows.Controls.Primitives]
• ToolBarOverflowPanel
  [System.Windows.Controls.Primitives]
• UniformGrid
  [System.Windows.Controls.Primitives]
• StackPanel
• ToolBarPanel
  [System.Windows.Controls.Primitives]
• VirtualizingPanel
• VirtualizingStackPanel
• WrapPanel

可以看到Panel類別一樣泛生自FrameworkElement類別，與控制項Control類別相同。Panel類別有兩個比較常用的屬性，第一是Children屬性會包含所有加入Panel的WPF元素集合(屬於UIElementCollection型態)，可以使用Add、Remove、Clear等方法操作面板中的元素。第二是ZIndex附加屬性，ZIndex用來排列元素的前後景，數字越大則越上方(前景)，數字越小則越下方(背景)，若沒有指定則依照加入的順序向上堆。

面板配置使用最多的大概是Grid類別，Grid的功能類似HTML的表格，而且還可以使用
GridSplitter控制項重新分配Grid各資料行或資料列之間的間距。另外，我們可以使用Grid模擬StackPanel和DockPanel的功能，當然這樣使用會比較麻煩一些。

面板中的Canvas類別是最簡單的面板，只能利用Top、Left、Bottom與Right附加屬性設定元素的絕對位置，適合用來處理效能苛求的應用！

至於System.Windows.Controls.Primitives命名空間的面板，這類面板通常用於控制項的設計，不適用於使用者介面面板(UI Panel)，使用者介面面板應該是那些有定義附加屬性的類別(除了WrapPanel沒有定義)，附加屬性可以讓元素設定所在面板所需的呈現方式。

基本上來說，玩WPF應用程式的第一步通常就是玩面板，利用面板配置一個視窗的控制項內容，接著開始撰寫功能。其他有關面板的資訊請參考MSDN：面板概觀http://msdn.microsoft.com/zh-tw/library/ms754152%28v=VS.90%29.aspx

###

You Are What You Eat 不生病的生活

隨時開始好的習慣，永遠不嫌遲。

新谷弘實著，劉滌昭譯，不生病的生活 ─ 全美首席胃腸科醫師的健康祕訣，台北，如何出版，2007。

• 原文書名應該是「病気にならない生き方」，由Sunmark Publishing,Inc.出版。另外有一本英文書「The Enzyme Factor」。
• 新谷弘實醫師(Dr. Hiromi Shinya)推行的「新谷飲食健康法」網站：http://www.drshinya.com/

今天談談「健康」這個議題，這本書「不生病的生活」非常推薦給大家閱讀，內容多數是作者新谷弘實醫師的實務經驗與結論，沒有很深奧的醫學理論(絕對看得懂)，而新谷弘實醫師提出的論點也不同於「常識」！全書共分四章：

1. 相信常識是危險的：建立正確觀念
2. 健康長壽的飲食法：飲食部分如何去做
3. 好習慣能塑造健康的身體：生活習慣如何去做
4. 傾聽「生命劇本」：總結

整本書籍的重點在前言已將講清楚了，由於新谷弘實醫師是為胃腸科醫師，在他從事醫療工作期間發現健康與腸胃的外觀有所關聯，他提出一個結論「健康者的胃腸美麗，不健康者的胃腸醜陋」(具有突破性觀點)，這當然是醫師才會看的到的現象，我們所有人都不會察覺這點。

那為何會有這種差異呢？或者兩者是否有其關聯？新谷弘實醫師展開調查這些病患，他發現飲食與生活習慣會影響「胃相」與「腸相」(胃腸的外觀)，換句話說，飲食與生活習慣對於健康將有所影響。

究竟這些因素之間有何關連？新谷弘實醫師提出「神奇酵素(Miracle Enzyme)理論」(此書的英文翻譯是"The Enzyme Factor")，目前還無法用醫學科學證實，醫師認為神奇酵素是身體中五千多種酵素的原型，而維持生命所必要的活動都與酵素有關，因此，讓自己擁有神奇酵素的飲食與生活習慣，將能使我們具有健康的身體，於是醫師根據他的臨床經驗推論與自己的驗證提出「新谷飲食健康法」。

講了這麼多，沒有親身實行改善自己的飲食與生活習慣都是沒有用的！不過，隨時開始好的習慣，永遠不嫌遲。這是我讀這本書最深的收穫，也希望大家能有所體悟。

###

Enterprise Resource Planning 企業資源規劃

企業資源規劃(Enterprise Resource Planning, ERP)是一種資訊系統(Information System)，因此 ERP也稱為「企業資源規劃系統」。

EPR的功能是整合企業流程的營運管理，包含人、金錢、機器、物料等資源的管理，藉由整合各資源的活動流程， ERP可以將企業使用資源的效率最佳化，最佳化企業流程是ERP的核心！就系統本質上而言，ERP是一個線上交易處理(On-Line Transaction Processing)的系統，使企業流程具有即時性、關聯性和整合性的資訊特性。

有關於ERP的資訊可以閱讀炬見工作室著作的這本書！這本書總共分四篇15章介紹ERP，分別是觀念篇、功能篇、導入篇與整合趨勢篇，可說是非常詳盡的一本書籍。
炬見工作室，ERP企業資源規劃：導論與個案，台北：博碩文化，2006。

大略介紹ERP是什麼，ERP系統不是一天想出來的概念，其演進過程與年代如下：

• 1970-1980：物料需求規劃(Material Requirements Planning, MRP)
• 1980-1990：製造資源規劃(Manufacturing Resource Planning, MRP II)
• 1990-2000：企業資源規劃(Enterprise Resource Planning ,ERP)
• 2000-2005：第二代企業資源規劃(ERP II)
• 2005-2009：電子商務解決方案(E-Business Solution)
• 2010~：雲端運算解決方案(Cloud Computing Solution)

簡略來說，都是因為電腦的發明、資訊系統的發展，將商業與管理的流程電腦化，目的是為了節省成本創造競爭優勢，觀念很簡單，實作卻不是很容易！因為太複雜了。

若從ERP外部的功能面來看，可以分成六大功能，分別是：

1. 銷售訂單管理(品管)
2. 生產製造管理(生產)
3. 物料庫存管理(庫存採購)
4. 成本會計(成本)
5. 一般財務總帳會計(財務)
6. 行政支援(業務)

當視野轉換為ERP內部的功能面來看，也可以分成六大能力，分別是：

1. 全球環境支援
2. 多層式架構應用
3. 異質資料庫與平台介面整合
4. 使用者介面與使用者經驗
5. 彈性模組化變動
6. 分散式系統應用

上述這些只是書中前兩章的一些觀念，如果你看了沒感覺，絕對是非常正常的反應，因為只有到了大公司裡面才會有所體悟，當時ycwang指導我研究ERP時，我自己也是一頭霧水，見山是山，見水是水。但是今天到組織中觀察體驗之後，豁然發現見山不是山，見水不是水，生命本身就是不斷累積的經驗，現在回頭看看，我絕對相信沒有白費的努力，你/妳也可以是一樣，機會是留給準備好的人。

###

Logitech HD Pro Webcam C910

趁著週休二日前往光華商場購置新款網路攝影機，這次購買的是羅技Logitech HD Pro Webcam C910(HD Pro 網路攝影機 C910)，具備兩項優異功能：「Full HD 1080p 錄影」與「HD 720p 通話」，這大概是目前最優秀的網路攝影機，當然，價錢也大概是最高檔(請準備3張小朋友)。

上圖這些照片是用另外一台網路攝影機所拍攝，型號是羅技的「快看商務版(QuickCam® Pro for Notebooks)」。HD Pro Webcam C910的強項是在視訊(Video)方面的表現，使用起來真的比快看商務版更清楚，清楚到了可怕的地步！HD Pro Webcam C910重新定義網路視訊。

快看商務版強調真實200萬畫素，而HD Pro C910則沒有強調真實畫素，依據軟體使用上來看有四種標準規格：640*480、1.2MP、5.0MP與10.0MP，分別表示30萬、120萬、500萬與1000萬畫素。若是以寬螢幕規格設定使用HD Pro C910，同樣也有四種規格：360p、480p、720p與1080p。

技術規格上顯示照片最高可達 1 千萬像素 (軟體增強處理)，所以HD Pro C910的真實畫素一定少於1千萬像素，依據Google搜尋結果，HD Pro C910真實畫素應該是500萬左右(軟體預設值，質疑！應該是1920×1080=2073600真實兩百萬像素)。

羅技這次(2010-08-19)推出C270、C310、C510與Pro C910四款新的網路攝影機，中高階的C510與Pro C910除了照片像素的差異之外，C510也沒有Pro C910的「自動對焦」與「卡爾蔡司光學鏡頭」，當然價格也有差距(Pro C910=NT$3290；C510=NT$1690)，若是沒有功能上的強烈要求，C510看來應該也是不錯的選擇！

###

Dependency Properties in WPF 相依性屬性

相依性屬性(Dependency Property)是Windows Presentation Foundation中獨特的屬性，目的是擴充.NET Framework的CLR屬性(Property)功能。我們知道，.NET Framework的類別中基本的成員有欄位(Field)、屬性(Property)、方法(Method)和事件(Event)這四大類。因為WPF是專門用於Windows展示的用途，若是觀察WPF的類別則會發現多了相依性屬性(Dependency Property)與路由事件(Routed Event)，在應用方面與.NET稍有不同。

相依性屬性最特別的是屬性變更事件(Property Changed Events)的功能，目的是提供一個依據其他輸入值來計算屬性值的方法，有了相依性屬性WPF才能夠設定資源(Resources)、樣式(Styles)、動畫(Animations)與資料繫結(Data Binding)等功能。

與一般.NET屬性互相比較，程式使用撰寫上沒有什麼差異，但底層實作卻完全不同。因此，通常會研究相依性屬性是為了自訂相依性屬性，接下來我們介紹自訂的方法。

假設我們自訂一個相依性屬性是My(型別為Int32)，那麼程式會定義一個DependencyProperty型態的MyProperty屬性(欄位的名稱一定要是屬性的名稱附加上後置字元 Property)，注意必須是public static readonly的。

class MyClass{
public static readonly DependencyProperty MyProperty;
}

必須用DependencyProperty.Register方法的初始化，直接於宣告時設定，或是在類別的建構函式中(宣告為靜態的建構函式)。

public static readonly DependencyProperty MyProperty= DependencyProperty.Register(
  "My",
  typeof(Int32),
  typeof(MyClass)
);

基本上，這兩個步驟就已經完成自訂相依性屬性，但是通常會利用程式存取這個屬性值，所以還要將相依性屬性包裝成為.NET屬性，利用GetValue和SetValue呼叫取得(稱為「CLR包裝函式」)。

public Int32 My
{
    get { return (Int32)GetValue(MyProperty); }
    set { SetValue(MyProperty, value); }
}

若是要加入更完整的相依性屬性功能，則需要屬性中繼資料(Metadata)，利用PropertyMetadata類別宣告，通常是設定預設值(如設定為0)，或是加入屬性變更事件回呼函式(PropertyChangedCallback)。

public static readonly DependencyProperty MyProperty= DependencyProperty.Register(
  "My",
  typeof(Int32),
  typeof(MyClass),
  new PropertyMetadata(0, new PropertyChangedCallback(OnMyChanged))
);

private static void OnMyChanged(DependencyObject o, DependencyPropertyChangedEventArgs e)
{
//當屬性值改變要執行的程式碼
}

相依性屬性大致上常用到上述的四個功能，其他像是屬性值驗證、繼承等進階深入議題，請參閱MSDN資料。http://msdn.microsoft.com/zh-tw/library/ms753192(v=VS.90).aspx

###

Windows Presentation Foundation

這篇部落格文章應該早在3月就寫好了，因為當時已經撰寫關於Windows Presentation Foundation的文章。

學習使用Windows Presentation Foundation (簡稱WPF)至今已經快半年了，這段期間主要閱讀兩本書籍，另外也參考MSDN網站的說明來輔助學習，幸運的是.NET Framework 3.5的WPF文件終於有中文版了(加減參考看看)。

第一本書籍，建議初學WPF的人閱讀，觀念講述十分清楚明白，若加上MSDN的說明文件，可以擁有五成功力！
Adam Nathan原著，鄭淑芬譯，Windows Presentation Foundation新一代使用體驗開發實務，台北；悅知文化，2007。

第二本書籍，微軟官方書籍，想要有八成功力一定要再看這一本，因為字數和頁數特別多的關係，閱讀起來比較辛苦一點，加上黑白印刷比較枯燥一些，但是值得一看！
Charles Petzold著，蔡學鏞譯，微軟Windows Presentation Foundation程式設計指南，台北：碁峰資訊，2007。

最省錢的學習文件當然還是MSDN：

• Windows Presentation Foundation中文
  http://msdn.microsoft.com/zh-tw/library/ms754130%28v=VS.90%29.aspx
• Windows Presentation Foundation英文
  http://msdn.microsoft.com/en-us/library/ms754130%28v=VS.90%29.aspx

最後，也可以參考範例程式學習WPF：http://code.msdn.microsoft.com/wpfsamples

###

The Diamond Sutra and Me 一隻牡羊的金剛經筆記

郝明義，一隻牡羊的金剛經筆記，台北：網路與書出版：大塊文化發行，2009。

他，郝明義先生，1956年出生於韓國，現任大塊文化董事長，與Net and books發行人(這些資訊是書內的作者簡介)。

讀完「一隻牡羊的金剛經筆記」，我對郝明義先生有更進一步的了解(之前知道這位人物是閱讀「越讀者」這本書)，更重要的是對我自己而言，我又更認識了自己。

有一點是這本書的精神，郝明義先生在「一隻牡羊的金剛經筆記 」第七章「為什麼提起十年前寫這本書」 這篇文章中敘述：

每個人都應該站在別人的肩膀上前進。
對一個上班族而言，這句話可能另有所指。
然而在閱讀及生命的實踐上，這是好話。
人之異於其他動物，本來就在於透過彼此的分享，可以使前後代之間、同代人之間的心得與體會，可以互相分享。
一方面借助他人的分享，節省自己苦思不得付出的時間；
另一方面自己有所得，也把肩膀借給別人使用。
所有真心寫作的書，都想提供這個作用。......

這段話是讓我最有感覺的一段，與我想要做的事情理念相同！我總是認為，如果有個人(或有本書)在你最困惑的時候，可以給你一個方向思索，我們就不會不知道如何前進，至少可以看看前人的經歷是什麼，然後自己決定行動，總比自己摸索的好吧！而不是找不到、或遇不到困惑的解答。我期許自己未來可以把肩膀借給別人使用，甚至創造更多肩膀。


這本書看了兩遍，每次的閱讀都令我有感而發。對於佛經的觀點，我認為就是哲學的探討，不同的經典提供不同的觀點和層次讓我們思考。郝明義先生在書中敘述：

如果說《金剛經》是一部登峰造極的內功心要，《六祖壇經》就是這部心要的白話版、
演義版，《金剛經口訣》是註解版、分解動作版，《心經》則是濃縮的短詩。

這是多麼有系統、有架構性的觀點！萬事萬物也是如此。有幸在廿多歲可以讀到郝明義先生的「一隻牡羊的金剛經筆記 」，遇到這一本書，讀了之後，人生不再如同過往那般。

System.Xml 可延伸標記語言

.NET Framework類別庫中處理XML(可延伸標記語言)的是System.Xml命名空間，操作XML最重要的概念是文件物件模型(Document Object Model, DOM)的操作方式，除了DOM的方式還有SAX(Simple API for XML)的操作方式，不過.NET Framework沒有SAX。

System.Xml命名空間比較重要的類別(Class)有下列幾個：

• XmlNode
  表示 XML 文件中的單一節點。
• XmlDocument
  表示 XML 文件。 
• XmlElement
  表示項目。這是 W3C 文件物件模型 (DOM) 中其中一個最常用的節點類別。
• XmlAttribute
  表示屬性 (Attribute)。屬性的有效和預設值是在文件類型定義 (DTD) 或結構描述中定義。
• XmlText
  表示項目或屬性 (Attribute) 的文字內容。
• XmlComment
  表示 XML 註解的內容。

XML相關類別繼承階層架構如下：

• System.Object
• XmlNode
• XmlAttribute
• XmlDocument
• XmlLinkedNode
• XmlCharacterData
• XmlComment
• XmlText
• XmlDeclaration
• XmlElement
• XmlNodeList
• XmlReader
• XmlWriter

這裡回顧一下XML的基本觀念：

• 每一個XML文件只能有一個根元素(root element)
• 每個元素(element)必須擁有起始標記(start tag, opening tag)和結束標記(end tag, closing tag)，除了沒有內容是使用空元素標記(empty-element tag)。
• 各個元素不能相互重疊，元素之間必須是是階層式的方式，子元素必須在父元素之內。
• 所有的屬性(Attribute)必須使用單引號或雙引號封閉。
• 元素與屬性名稱都是區分大小寫的(case-sensitive)。

在.NET Framework中操作XML時通常是使用XmlDocument讀取或寫入檔案(載入和儲存 XML 資料)，再使用像是CreateElement方法、AppendChild方法、SelectNodes方法、SelectSingleNode方法等操作XmlElement節點。

###

Education 教育制度

有鑑於jasper312等人對於教育制度的疑惑，本篇文章將解釋我所知道的制度內容，以及我個人的心得感想，當然，這不是標準答案(參考就好)。

台灣的教育制度大概是長成下表這樣，以7年級(1981-1990)的觀點來看，現在的(9年級)教育制度又有些變化，我沒有深入了解！敬請酌量參考閱讀。

年	名稱
6	國小
3	國中
3	高中	高職		五專
4	大學	四技	二專
			二技
2	研究所
N	博士班

可以看到，每個人在國中以前的教育制度都是相同的！9年讀完「國民小學」和「國民中學」，這時候已經15歲左右了！

生命從你16歲那年開始變得不一樣，國中以後是三條路徑：高中、高職、五專。依據過去的案例，成績好的學生會去「高級中學」，而成績差一點的會去「高級(工業、商業)職業學校」或是「五年制專科學校」。

爾後，高中生會繼續考試入學「大學(或稱「普通大學」)」，而高職生與五專生則比較複雜一些，大概的升學路徑有：

• 高職→四技(四年制技術學院，或稱「科技大學」)
• 高職→二專(二年制專科學校)→二技(二年制技術學院)
• 五專→→二技(二年制技術學院)

注意到，這些升學的途徑之間是可以互相轉換跑道，例如：

• 高中→四技(科技大學)，容易。
• 高職→大學(普通大學)，困難。
• 五專→四技三年級、大學三年級，困難。

當你的求學階段到達22歲時(如果順利沒有留級延畢...)，你可以取得大學文憑獲得學士(Bachelor)學位，之後念研究所畢業取得碩士(Master)學位，再念博士班你就可以取得博士(Doctor of Philosophy, PhD)學位。

接下來談談考試的部分，如下：

• 國中生→高中、高職：「國民生中學學生基本學力測驗」
• 高中生→普通大學：「學科能力測驗」
• 高職生→科技大學：「四技二專統一入學測驗考試」
• 五專生→二技：「技術校院二年制統一入學測驗考試」
• 五專生→普通大學、科技大學：各校獨立舉辦轉學生招生考試
• 大學→研究所：各校獨立舉辦招生考試
• 研究所→博士班：各校獨立舉辦招生考試

這些考試之中，有個重要的分歧點，那就是高中與高職的差異，生命從你16歲那年真的開始變得不一樣，因為所受到的教育內容與方式會有所差異，社會與家人對你的期許和態度也變得不一樣。

若說，就讀高中是條康莊大道，那麼就讀高職會是一條羊腸小徑，每個途徑沿途各有它的景點，沒有絕對好壞的標準！(五專的部分真不知道如何形容，柔腸寸斷嗎...)就好比忠孝東路與市民大道，當你想要橫越台北市最好走市民大道，忠孝東路有太多的紅綠燈阻擾，雖然你都可以到達目的地，但是付出的代價會大不相同。而且若要從忠孝東路轉往市民大道，付出的努力會更多一些。

路途中的經歷也將影響你的人生，一方面是教育內容的不同(你可能吃了毒藥而不知道是毒藥)，這當然也影響考試的內容，所以轉換道路的困難度也大不相同。另一方面是你周圍的人也不同(建立不同的人脈)，認真與競爭的差異將導致你往後程度的不相同，甚至無法和他人競爭，兩個小地方的差異都將會影響你後續人生的發展。

###

Joomla Operation 運作說明

這篇是記錄研究Joomla!的運作原理，主要方法是去分析Joomla!原始碼的內容，沒什麼深奧的技術，大家參考參考就好！還是參閱官方文件網站：http://docs.joomla.org/

依據HTTP Requestfu進入的執行先後順序撰寫如下：

程式的進入點(Entry Point)只有一個：index.php(安裝根目錄中，下述路徑皆以根目錄為相對參考)

• 定義一些常數名稱
  define( '_JEXEC', 1 );
  define('JPATH_BASE', dirname(__FILE__) );
  define( 'DS', DIRECTORY_SEPARATOR );
• 呼叫定義檔，裡面更多常數名稱的定義
  require_once ( JPATH_BASE .DS.'includes'.DS.'defines.php' );
• 載入Joomla框架
  require_once ( JPATH_BASE .DS.'includes'.DS.'framework.php' );
• 匯入Joomla框架所需要的程式庫 require_once( JPATH_LIBRARIES.DS.'joomla'.DS.'import.php'); 並且利用JLoader::import方法，載入許多物件， 例如JLoader::import( 'joomla.factory');載入JFactory
• 設定Joomla框架的組態設定 require_once( JPATH_CONFIGURATION.DS.'configuration.php' );
• 產生應用程式物件，這是繼承於JApplication的JSite物件
  $mainframe =& JFactory::getApplication('site');
實際上是實體化includes/application.php的定義JSite類別， 建立JSite物件，而不是JApplication， 但是注意JSite類別是泛生自JApplication類別，而JApplication類別則是泛生自JObject類別。
• 初始化應用程式物件
  $mainframe->initialise();
• 觸發事件$mainframe->triggerEvent('onAfterInitialise');
• 路由應用程式，決定HTTP Request應該傳送到哪個Component處理，建立JRouter物件。
  $mainframe->route();
• 觸發事件$mainframe->triggerEvent('onAfterRoute');
  
• 批准授權使用者的權限，利用JMenu物件判斷
  $mainframe->authorize($Itemid);
  
• 派遣應用程式，將HTTP Request的參數資料取出派遣到對應的Component處理，建立JDocument物件
  $mainframe->dispatch($option);
• 觸發事件$mainframe->triggerEvent('onAfterDispatch');
• 提交應用程式，將Component處理後的資料與template結合，提交給JResponse緩衝暫存。
  $mainframe->render();
• 觸發事件$mainframe->triggerEvent('onAfterRender');
  
• 將JResponse輸出成為HTTP Response
  echo JResponse::toString($mainframe->getCfg('gzip'));

###

Controls in WPF 控制項

講述Windows Presentation Foundation (WPF)中的控制項(Contorls)，對於Windows應用程式開發來說，開發程式非常仰賴控制項，因為控制項就是使用者介面(User Interface)的一部分。

WPF的控制項是基於System.Windows.Controls.Control類別所泛生出來的子類別，接下來先介紹Control類別的繼承階層架構：

• ContentControl
• Frame
• GroupItem
• HeaderedContentControl
• Expander
• GroupBox
• TabItem
• Label
• ListBoxItem
• ComboBoxItem
• ListViewItem
• ButtonBase(抽象類別)[System.Windows.Controls.Primitives]
• Button
• GridViewColumnHeader
• RepeatButton
• ToggleButton
• CheckBox
• RadioButton
• StatusBarItem[System.Windows.Controls.Primitives]
• ScrollViewer
• ToolTip
• UserControl
• Window
• NavigationWindow
• FlowDocumentReader
• FlowDocumentScrollViewer
• ItemsControl
• HeaderedItemsControl
• MenuItem
• ToolBar
• TreeViewItem
• MenuBase(抽象類別)
• ContextMenu
• Menu
• Selector(抽象類別)
• ComboBox
• ListBox
• ListView
• TabControl
• StatusBar
• TreeView
• PasswordBox
• DocumentViewerBase(抽象類別)[System.Windows.Controls.Primitives]
• DocumentViewer
• FlowDocumentPageViewer
• RangeBase(抽象類別)[System.Windows.Controls.Primitives]
• ScrollBar
• ProgressBar
• Slider
• ResizeGrip[System.Windows.Controls.Primitives]
• TextBoxBase(抽象類別)[System.Windows.Controls.Primitives]
• RichTextBox
• TextBox
• Thumb[System.Windows.Controls.Primitives]
• GridSplitter
• Separator
• StickyNoteControl

非常壯觀的類別繼承架構，但是別恐慌！注意到兩個重要類別：ContentControl類別與ItemsControl類別。ContentControl是表示內含單一內容片段(single piece of content)的控制項，換句話說，ContentControl的XAML子節點只能有一個元素，這個元素代表的是ContentControl的內容(Content屬性)。相對的，ItemsControl的XAML子節點可以有多個元素，這多個元素是存放於ItemsControl的集合(Items屬性)之中。

另外，ContentControl類別與ItemsControl類別的控制項加入標頭(Header)外觀的子類別也很常使用到，分別是HeaderedContentControl 類別和HeaderedItemsControl 類別。

最後提及一下命名空間(Namespace)，控制項的命名空間主要有兩個：System.Windows.Controls和System.Windows.Controls.Primitives，其中Primitives的類別是屬於基底類別 (Base Class)的定義，主要做為其他更複雜控制項(泛生類別)的一部分，前述階層架構中的[System.Windows.Controls.Primitives]代表此類別屬於Primitives命名空間之中。

MSDN參考連結：控制項概觀http://msdn.microsoft.com/zh-tw/library/ms752069%28v=VS.90%29.aspx

###

Windows Presentation Foundation Architecture

最近又進一步深入研究Windows Presentation Foundation (WPF)，對於一個知識領域，每次閱讀都有不同的收穫，因為視野每次都越來越廣，高度每次越來越高！今天談談WPF的架構(Architecture)。

MSDN(Microsoft Developer Network)參考網址：

• 中文http://msdn.microsoft.com/zh-tw/library/ms750441%28v=VS.90%29.aspx
• 英文http://msdn.microsoft.com/en-us/library/ms750441%28v=VS.90%29.aspx

首先必須要知道，WPF是Managed Code的方式運作，也就是WPF必須使用.Net Framework，然而WPF的顯示為了效能因素，設計時不是在.Net Framework的CLR上運作，看看下面的架構圖就能懂了。

WPF是由PresentationFramework、PresentationCore 和 milcore(mil=Media Integration Layer)三個部分組成，有三個動態連結程式庫 (DLL) ：

• C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\PresentationCore.dll
• C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\PresentationFramework.dll
• .NET Framework 3.5 SP1將milcore.dll更改名稱為wpfgfx_v0300.dll，C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\WPF\wpfgfx_v0300.dll

WPF的物件非常有架構(OOP就是這樣啊)，我們來看看WPF的類別階層(Class Hierarchy)架構，因為實在是太龐大了，我們只看看10個WPF重要的類別。

• System.Object
• System.Windows.Threading.DispatcherObject
• System.Windows.DependencyObject
• System.Windows.ContentElement
• System.Windows.FrameworkContentElement
• System.Windows.Media.Visual
• System.Windows.UIElement
• System.Windows.FrameworkElement
• System.Windows.Controls.Control
• System.Windows.Freezable

比較需要注意到的是DispatcherObject類別，這是WPF的基礎運行原理，可以參閱「執行緒模型」，另外，DependencyObject也是WPF中較特別的一個地方，請參閱「相依性屬性概觀」。

最後，我想介紹FrameworkElement類別，FrameworkElement加入重要的邏輯樹狀結構功能，並且泛生許多你會用到的WPF類別，像是控制項、面板、頁面、圖形等等，FrameworkElement的類別繼承階層架構如下(僅列出重要項目)：

• System.Windows.FrameworkElement
• System.Windows.Controls.ContentPresenter
• System.Windows.Controls.Control
• System.Windows.Controls.Decorator
• System.Windows.Interop.HwndHost
• System.Windows.Controls.Image
• System.Windows.Controls.InkCanvas
• System.Windows.Controls.ItemsPresenter
• System.Windows.Controls.MediaElement
• System.Windows.Controls.Page
• System.Windows.Controls.Panel
• System.Windows.Controls.Primitives.Popup
• System.Windows.Shapes.Shape
• System.Windows.Controls.TextBlock
• System.Windows.Controls.Primitives.TickBar
• System.Windows.Controls.ToolBarTray
• System.Windows.Controls.Primitives.Track
• System.Windows.Controls.Viewport3D

###

The Sutra of My Heart 送你一首渡河的歌

我的老師(ycwang)曾經告訴我：「心定」，直到有一天我才瞭解，所有的煩惱都來自於心，而每一次的心煩又讓自己更定性。

洪啟嵩繪著，送你一首渡河的歌：《心經》The Sutra of My heart，台北：網路與書出版：大塊文化發行，2008。

大家一起來讀讀Sutra吧！

觀自在菩薩，

行深般若波羅蜜多時，照見五蘊皆空，度一切苦厄。

舍利子！色不異空，空不異色，色即是空，空即是色。

受、想、行、識，亦復如是。

舍利子！是諸法空相，不生、不滅；不垢、不淨；不增、不減。

是故空中無色，無受、想、行、識；

無眼、耳、鼻、舌、身、意；

無色、聲、香、味、觸、法；

無眼界，乃至無意識界；

無無明，亦無無明盡，乃至無老死，亦無老死盡；

無苦、集、滅、道，無智亦無得。

以無所得故，菩提薩埵，依般若波羅蜜多故，心無罣礙。

無罣礙故，無有恐怖，遠離顛倒夢想，究竟涅盤。

三世諸佛，依般若波羅蜜多故，得阿耨多羅三藐三菩提。

故知般若波羅蜜多，是大神咒，是大明咒，是無上咒，是無等等咒，能除一切苦，真實不虛。

故說般若波羅蜜多咒，即說咒曰：

揭諦揭諦
波羅揭諦
波羅僧揭諦
菩提薩婆訶

###

The Professionalism 專業：你的唯一生存之道

介紹大前研一先生著作的「The Professionalism」，中文書名是「專業：你的唯一生存之道」。

當初買這本書是因為自己想知道「專業」究竟是怎樣一回事，然而閱讀完這本書之後，大前研一先生定義的「專業」可說是非常正確，每看完一篇文章，真想說好啊！讓人越想一直看下去。(大前研一先生的文章非常具有魅力)

大前研一著，呂美女譯，專業：你的唯一生存之道，台北：天下遠見，2008。

第一章「你夠專業嗎」的第一篇文章：「什麼才是專業」，說明了「專業(Professionalism)與專家(Specialist)有點類似，卻不盡相同」，在大前研一先生定義之中，我們一般人所認知的專業其實是專家的意思，這大大誤解了專業的內涵與價值！

大前研一先生認為專業人士也應該具備醫學界「希波克拉底誓詞(The Oath of Hippocrates)」的精神(詳細內容請google)，而對象則是由病患改為顧客，我認為這就是專業的職業道德與誠信原則。

當下是一個「看不見的新大陸」時代，就像拓荒者進入一個未知的叢林，大前研一先生認為必須具備「先見力、構思力、議論力、矛盾適應力」這四個能力才稱得上是「專業」。擁有先見能力，我們才能找到新叢林前進的方向。擁有構思能力，我們才能在新叢林中勇敢前進。擁有議論能力，在新叢林中才不會走進陷阱之中。擁有矛盾適應能力，我們才能在新叢林中建立新的生存法則。

最後，我不得不承認自己的經歷實在有限，大前研一先生所說的我不能完全領悟，但這的確是一本值得細細品味思考的書籍，如他自序中所言：這是幫忙培育專業人士的教科書，教導我們不是如何去做，而是讓我們什麼才是「專業」的精神。

「我們所能倚賴的，只有自己。」書末結語非常切實！

The Daily Review 2 心得日誌2

在一群大象中待久了，整理一些組織生活的心得報告，避免日子一久遺忘自己曾經是隻怎樣的跳蚤！Thanks to Charles Handy.

「Daily Review」心得日誌第二篇：「組織這樣做應該會更好」。

每天早上的會議跟升旗唱國歌沒有兩樣，只是例行公事。
會議不是為了討論如何解決問題，而是為了釐清責任而開會，
唯一的用處是：這是一天當中我和太陽神阿波羅對話的唯一機會。

如果早上不開會，整天我就不曉得為何要存在於大象群之中，
會議的內容是跳蚤們報告每天的進度，每隻跳蚤輪流說明專案的工作進度，
阿波羅一般而言不會和跳蚤有所對話互動，純粹是單方向的溝通契約，
最後只會詢問跳蚤們還有沒有事情？或是現在進度到哪裡？
對話內容似乎只是為了善盡阿波羅的責任。

會議每次應該訂出討論議題，善用白板繪製圖像，
這樣才能發揮眾人智慧的力量，溝通交流更加順暢清楚，
而且應該每次都要記錄討論事項內容，這樣才能瞭解討論是否有所盲點，
可惜的是大象群沒有這樣的文化，似乎也不想去改善求進步，
這樣的大象可預期已經生病了。

大象群似乎不太注重跳蚤的教育訓練，而且跳蚤之間似乎沒有團隊合作的情形，
跳蚤不訓練算是沉浸理論(Immersion Theory)的實踐吧！
沉浸理論把跳蚤丟下水，看看跳蚤會不會自己學會游泳，
反正跳蚤們最後都會慢慢習慣大象群的一切，
阿波羅何必花時間教導訓練跳蚤呢？跳蚤對大象群只是過客而已。

我認為跳蚤一定要教育訓練，因為我們必須對我們的顧客負責，
阿波羅應該教導新人至一定的知識水準，不需擔心新人會學走任何知識，
因為我相信經驗是很難傳授的知識，而這正是阿波羅最有價值的財富，
更重要的是培養新人符合組織期望的工作態度。

新人沒有一定的訓練，未來一定會傷害到顧客，更反過來讓組織受傷，
從資料中可以看到麥肯錫管理顧問公司(McKinsey & Company)、通用電氣公司(GE,奇異)，
這些公司都不怕教育訓練新人，而且對於人才非常投資，因而吸引一流人才。

好的人才，才能夠形成好的組織，好的組織才能提供好的服務，
也因此能夠有好的獲利，最終滿足顧客、股東和員工的需要，形成一個正向循環的成長。
新人一定要教育訓練，而這種教導不只是依靠大象群的制度，阿波羅也必須教導新人。

跳蚤在大象群待久了，如果一開始的大象群文化不好，很容易產生劣幣驅逐良幣的情形，
因為跳蚤要影響大象群通常很困難，於是好的跳蚤會離開大象群，留下不好的跳蚤與文化。

以我看到大象群來說，團隊合作的方式很奇怪，一隻跳蚤接一個專案，
在這個專業分工化的時代，要求跳蚤應具備所有專業能力，這實在是不可思議！
或許只是為了讓跳蚤承擔所有的責任，萬一專案失敗才有人可以扛。

大象群中的分工最容易發生的問題是推卸責任，為了避免跳蚤推卸責任，
於是每隻跳蚤開始劃清責任，跳蚤盡最大努力讓事情最少，責任最小，
這樣又要如何形成開放、創新、團隊合作的文化呢？

關於這個問題，或許要從大象群的制度面著手解決，畢竟文化的改革很難，
但是對於大象群而言，只要是「改變」都是困難，通常會遭遇很多跳蚤的批評，最後不了了之。

有容德乃大，無求品自高。待續...

DirectShow.NET Principle 工作原理

DirectShow.NET用了一段時間，差不多也快忘了！趕快紀錄DirectShow.NET的原理，當時研究了一陣子好不容易搞清楚。

DirectShow.NET是一個程式庫(Library)，目的是讓你的.NET Framework可以使用Microsoft DirectShow API，DirectShow.NET基本上是利用.NET Framework的互通性(Interoperability)元件叫用方式呼叫DirectShow API，而DirectShow本身是COM元件。

可以參考MSDN這兩篇文章，你就大概清楚DirectShow.NET的工作原理：

• COM Interop Part 1
  Shows how to use C# to interoperate with COM objects. Covers a C# client.
• COM Interop Part 2
  Shows how to use C# to interoperate with COM objects. Covers a C# server.

如果還有興趣，可以打開DirectShow.NET的原始碼，你可以看到基本上都是一些定義宣告，可以自己寫(你可能需要Globally Unique Identifiers (GUIDs)或是COM Class Identifier (CLSID)，別怕，參考Windows SDK中的標頭檔，通通有寫清楚)，但是自己寫很花時間也可能有Bug，所以直接使用DirectShow.NET程式庫是最有效益的！(No Need To Reinvent The Wheel.)

對於想要利用C#來撰寫DirectShow的開發人員，你可以參考DirectShow.NET的範例程式，這會讓你更快上手！尤其是有專案壓力的情形之下。

Geometric Matching 幾何比對

這篇將介紹數位影像領域中幾何比對(Geometric Matching)的課題，幾何比對是利用幾何形狀的資訊，目的是要找出影像之中，存在與樣板(Template)影像相同(相似)的影像區域。

幾何比對的程式運作大概是這個方式：

1. 建立欲尋找物體的樣板影像，計算出幾何的特徵。
2. 程式利用樣板的幾何特徵，搜尋影像中與樣板相似的區域。
3. 計算這些區域相似的程度並於以量化評分(score)。
4. 最後依據評分的高低，程式可以找出與樣板最相似的區域(即目標物)。
5. 結果將包括目標物的數量與位置。

幾何的比對搜尋與下列特性無關：光線變化(lighting variation)，影像的模糊(blur)、雜訊(noise) 與閉塞(occlusion)，幾何空間轉換像是移動(shifting)、旋轉(rotation)與縮放(scaling)。因為幾何比對關注的是物體的幾何形狀。

我們利用幾何比對通常是為了下列的應用：

• 空間量測(Gauging)
  量測物體的長度、直徑、角度或其他量度(dimension)。
• 檢驗(Inspection)
  偵測物體上簡單的缺點(flaw)，指形狀上的瑕疵。
• 對齊(Alignment)
  找出物體的位置(position)與方向(orientation)。
• 分類(Sorting)
  基於形狀或尺寸的分類。

必須注意到利用幾何比對的前提是：欲搜尋的物體(提供的樣板)本身必須要有明顯區別的(distinct)幾何形狀資訊，通常是利用影像的邊緣(edge)，否則比對將無法順利進行(發生誤判斷)。另一方面，若欲搜尋的影像中有太多的幾何資訊(太多的邊緣資料)，程式計算比對的時間也將會增加，於是影響幾何比對運作的效能。遇到上述的情況下，則建議使用樣式比對(Pattern Matching)。

幾何比對的過程分成前後兩個階段：學習階段(Learning Stage)與比對階段(Matching Stage)。

學習階段的過程中，程式萃取樣板的幾何形狀資訊作為比對的特徵值，程式將儲存這些特徵值以及特徵值的空間資訊。在比對階段的過程中，程式將萃取影像中所有的幾何資訊，並且和先前學習的特徵值進行比對和評分計算，程式最後將選出與樣板相同的影像區域。

幾何比對技術的核心基礎是以曲線萃取(Curve Extraction)的方式取得影像中的幾何資訊，利用萃取後的曲線資訊作為比對的方法則有兩種：

• 以邊緣為基礎的幾何比對(Edge-Based Geometric Matching)
• 以特徵為基礎的幾何比對(Feature-Based Geometric Matching)

一般來說，Edge-Based是利用物體全部的幾何資訊來比對，相對於Feature-Based只用部分的特徵比對，因此，Edge-Based的辨識率較高，可以的話，盡可能使用Edge-Based的幾何比對方法。

當然，事情不是想像中的簡單，凡事都有優缺，決定前都必須權衡取捨(trade-off)，下列列出Edge-Based與Feature-Based的相對比較，可以作為選擇方法的參考。

	Memory Requirement	Matching Speed	Recognition Rate	Template Restriction
Edge-Based	大	慢	高	任意形狀
Feature-Based	小	快	低	明顯且易區別的形狀

Joomla Programming

Joomla!是一套Web的內容管理系統(Content Management System, CMS)，具有完整的前台語後台架構，Joomla的擴充模組也很多，開發模組也相當容易，本文先介紹1.5.17版本的程式架構，希望對於想要開發Joomla的人員能有所幫助。

Joomla!架構圖(取自官方網站http://docs.joomla.org/Image:Joomla_Architecture.jpg，更多資訊請參閱http://docs.joomla.org/Main_Page)

資料夾說明：

1. administrator=>後台管理
2. cache=>快取
3. components=>元件
4. images=>影像
5. includes=>副程式
6. installation=>安裝檔
7. language=>語言
8. libraries=>程式庫，包含Joomla!框架的程式庫(framework)。
9. logs=>日誌
10. media=>媒體
11. modules=>模組
12. plugins=>外掛
13. templates=>樣板
14. tmp=>暫存區
15. xmlrpc=>可延伸標示語言‧遠端程序呼叫

檔案說明：

1. CHANGELOG.php=>修改日誌檔。
2. configuration.php=>Installer安裝程式產生的組態檔。
3. configuration.php-dist=>原始的組態檔(distribution)，手動安裝Joomla才會需要用到。
4. COPYRIGHT.php=>版權宣告
5. CREDITS.php=>榮譽榜，包含貢獻者與Joomla內自由軟體的清單。
6. htaccess.txt=>Apache存取的組態檔。
7. index.php=>Joomla!進入點(Entry Point)
8. index2.php=>只顯示元件輸出內容。
9. INSTALL.php=>安裝說明
10. LICENSE.php=>授權條款
11. LICENSES.php=>完整的授權條款內容，包含BSD License，GNU Lesser General Public License (GNU LGPL) version 2.1與MIT License。
12. robots.txt=>搜尋引擎漫遊器的組態檔

Joomla是非常有架構的一套CMS，非常適合用來當作開發平台使用，而且擴充元件(Component)很多，說明文件詳細清楚。推薦！玩網頁的人也一定要會一套CMS，就是Joomla!啦。

The Daily Review 心得日誌

「Daily Review」心得日誌：在一群大象群中待久了，整理一些心得報告，避免日子一久遺忘自己曾經是隻怎樣的跳蚤！Thanks to Charles Handy.

早晨開會，
阿波羅只問我資料閱讀了沒有，我回答「看了」，
我和他的對話就此結束，彼此沒有任何交集。

阿波羅似乎不知道應該問我什麼事情，
他想了一個很普通的問題，目的只是為了破除兩人之間的寧靜。

阿波羅說：「應該加班的時候，還是要加班。
專案的里程碑(milestone)快要到截止期限了，
不要讓沒有加班變成專案延期的原罪(Original Sin)。」

專案延期究竟是人力的問題，亦或是專案規畫的問題呢？
如果是人力問題，是不是應該增加跳蚤，而不是要求加班。
不找尋專案延期發生的原因，只求跳蚤加班祈求心安，這種文化還能讓大象群存活多久？

阿波羅問我：你這個專案研發要多久？
我說「我目前無法預估，因為這個新專案我正在開始研究而且不熟悉，後續會遇到多少問題必須解決我也不知道！沒有辦法跟你預估時間」
阿波羅也說；「專案總要有個期限，你要盡量保持住時間，兩個月夠嗎？」
呵呵...(我笑了)

問題在於根本就不清楚專案的需求，又如何達到目標呢？
就像是你只說要吃飽，我弄了炒麵給你，你說如果可以吃炒飯更好。
我弄了炒飯給你，你又說炒飯要加蝦仁，最好還有紫菜蛋花湯。
我都弄給你吃了，你吃完說其實我想吃牛肉麵，好吧！
弄了牛肉麵給你，附上小菜一盤，這樣可以了吧！
你說牛肉不好，你要半筋半肉的清燉牛肉麵，麵條要刀切的...沒完沒了。
你為什麼不一開始就先說清楚！是因為你也不曉得要吃什麼才好。
要是專案遇到這種，真的會瘋掉，大象群的資源也因此浪費掉了，可惜。

跳蚤們每天下班擬定好明天早上開會的說詞，
週一敘述這週的預期進度，週五報告完成的進度，
於是只剩下三天的報告內容需要想想，內容通常是報告昨天做了什麼事情，
這就是為了開會而開會檢討，完全沒有實質的意義。

雖然說開會沒有任何意義，但是說話千萬不要低於一分鐘的內容，
這會讓阿波羅感覺你沒有做事情，跳蚤的原則就是用嘴巴做事。
只要敘述你問其他跳蚤什麼問題，跳蚤回答你的內容，再加上你閱讀什麼資料，
這樣的模式絕對可以講三分鐘，冠冕堂皇！

豈能盡如人意，但求無愧我心。待續...

Organizations and Individuals 2 組織與個人2

查爾斯‧韓第 (Charles Handy)的啟發，Thanks to Charles Handy.

接續之前曾寫過的部落格文章「組織與個人」，這是第二篇，我想記錄一些我在「大象群」中所觀察的心得感想(我附屬的是一家全球逾六萬跳蚤的大象群，故稱之為「大」)，必須說明的是這些觀點可能不完全，因為我只是位於大象群中的一個大象，自己如同井底之蛙。

大象群多數存在一個文化：「可以推就推，不可以推就閃，閃不過就躲，躲不過就拖，好過揹黑鍋。」困難的工作最好永遠不要淪落到自己的身上，輕鬆過日子領薪水會比較快樂，何必那麼辛苦呢！我認為一個人一旦有這種想法之後，個人就開始變爛了！

如同韓第先生所說的「S曲線(Sigmoid Curve)」理論，只不過我說的是相反方向。S曲線(Sigmoid Curve)理論是「解釋公司如何成長，以及最後可能如何失敗，而這條曲線運用到個人生命以同樣適合。」

個人進入組織後開始學習，到達S曲線的最高峰(也許是職位)，之後曲線向下彎曲(學習進度開始下降)，個人進入S曲線的最低點，就在這裡因為太爽(不用學習，而且擁有職位和權力)，個人思考對策展開另一段S曲線，邁入另一個低點中的高峰和另一個最低點。

總體而言，個人的學習開始僵化退步，個人開始邁向一個又一個的低點，對於組織而言，這樣的「負S曲線(Negative Sigmoid Curve)」如同癌症慢慢消耗組織的營養，個人可以不進步，可是組織必須要進步才能競爭生存。另一個角度來說，組織如果不進步，我們自己還是要進步，不能將眼光只侷限在這個組織之中，世界全球還有更多優秀的組織等著我們進入。

Collections and Generics in C Sharp C#的集合和泛型

談談C#程式語言中好用的資料類型：集合(Collections)和泛型(Generics)，這兩個資料類型簡單來說跟陣列(Array類別，System命名空間)功能相同，都是用來表示「一組聚集在一起相同類型的物件資料」，但是集合和泛型提供更多好用的功能，因此撰寫程式時會更加方便，比方說：可以任意擴充大小的資料容量、可以放置不同類型的物件...這些魔法。

集合和泛型的所屬命名空間是：

• System.Collections
  包含介面和類別，定義各種集合的物件，例如清單、佇列、位元陣列、雜湊表和字典。簡單集合是強型別 (Strongly Typed)，不需要轉型(Cast)。
• System.Collections.Generic
  包含定義了泛型集合的介面和類別，可讓使用者建立強型別 (Strongly Typed) 的泛型集合，以提供比非泛型強型別集合更好的型別安全 (Type Safety) 和效能。

泛型是在C#與.NET Framework 2.0 版和更新版本才有的功能，泛型比集合有更好的效能和安全性，因此建議撰寫程式都使用泛型！主要是因為泛型(Generics)沒有型別的Boxing和Unboxing動作，因此效率與安全性都比較好。

集合(Collections)中常用的類別有：ArrayList、Queue、Stack這幾個類別，而要建立自己的集合類別，則可以使用CollectionBase和DictionaryBase兩個類別繼承擴充。

在System.Collections命名空間中定義幾個常用的介面：

• ICollection
  定義所有非泛型集合的大小、列舉值和同步方法。
• IEnumerable
  公開能逐一查看非泛型集合內容一次的列舉值。
• IList
  表示可以個別由索引存取之物件的非泛型集合。
• IDictionary
  表示索引鍵/值組的非泛型集合。

CollectionBase繼承介面有ICollection、IEnumerable和IList，而DictionaryBase繼承的介面則有ICollection、IEnumerable和IDictionary，看到差異差異了嗎！由於集合都有繼承IEnumerable介面，因此都可以使用foreach陳述式操作。

泛型(Generics)的功能則是更強更好用！常用的類別有：Dictionary(Of TKey, TValue)、LinkedList(Of T)、List(Of T)、Queue(Of T)、Stack(Of T)。在System.Collections.Generic命名空間中也提供很多結構和介面可以使用，如果要自己定義泛型，通常是使用<T>這樣的方式，詳細請參閱泛型 (C# 程式設計手冊)，泛型功能很強大，比較複雜所以要花時間仔細閱讀。

對於C++的程式設計人員，C#的泛型相當於C++中的樣板(Template)。

Morphological Image Processing 形態學影像處理

形態學影像處理(Morphological Image Processing)，依據 Gonzalez與Woods的書本上說明\：影像處理的形態學是依據數學形態學(Mathematical Morphology, MM)的應用之一，並且是以數學理論為運算的基礎(集合理論，Set Theory)。

使用形態學處理影像，其輸入是影像，而輸出是影像所擷取的特徵和屬性，有點算是影像分析。運算中，通常會定義一個結構元素(Structuring Element, SE)，結構元素是一個小集合或子影像，其大小通常是3X3像素且原點在中心。

形態學影像處理的基本運算有兩個基礎：

• Erosion侵蝕
  集合A被結構元素B侵蝕，記為A⊝B
  
• Dilation擴張(膨脹)
  集合A被結構元素B擴張，記為A⊕B

形態學的其他運算(基於Dilation和Erosion)：

• Opening斷開
  集合A被結構元素B斷開，記為A∘B
  
• Closing閉合
  集合A被結構元素B閉合，記為A∙B
  
• The Hit-or-Miss Transformation交離轉換
  B=(B1, B2)，A⊛B=(A⊝B₁)⋂[A^C⊝B₂)]
  
• Boundary Extraction邊界抽取
  β(A)=A-(A⊝B)
  
• Hole Filling填洞
• Extraction of Connected Components連通成分抽取
• Convex Hull凸形封包
• Thinning細線化
  集合A被結構元素B細線化，A⊗B=A-(A⊛B)=A⋂(A⊛B)^C
  
• Thickening厚化
  集合A被結構元素B厚化，A⊙B=A⋃(A⊛B)
  
• Skeletons骨架
• Pruning剪除
• Morphological Reconstruction形態學的重建

基本上來說，形態學影像處理是影像分析(Image Analysis)的基礎，利用更進一步的運算處理，我們可以分析影像中的資訊。持續研究Image Processing...

Graphics Device Interface 繪圖裝置介面

談談Windows的繪圖裝置介面(Graphics Device Interface, GDI)，當我們要呈現影像在Windows中，一定會撰寫GDI的程式。

根據MSDN上的解釋：http://msdn.microsoft.com/en-us/library/ms536380%28v=VS.85%29.aspx
「As its name suggests, GDI+ is the successor to Windows Graphics Device Interface (GDI), the graphics device interface included with earlier versions of Windows. Windows XP or Windows Server 2003 supports GDI for compatibility with existing applications, but programmers of new applications should use GDI+ for all their graphics needs because GDI+ optimizes many of the capabilities of GDI and also provides additional features.
」

就目前而言，Windows作業系統都是使用XP以後的版本，因此現在多使用也建議以GDI+的API開發，而在.NET Framework中相關GDI+元件的命名空間有：

• System.Drawing
  提供存取 GDI+ 基本圖形功能。
• System.Drawing.Drawing2D提供進階的 2D 和向量圖形功能。
• System.Drawing.Imaging提供進階的 GDI+ 影像處理功能。
• System.Drawing.Text提供進階的 GDI+ 印刷樣式功能。

我們在撰寫GDI的程式上有一個觀念很重要：Windows作業系統不會記憶任何視窗上面顯示的內容。換句話說，內容必須由我們的應用程式負責處理，這通常是OnPaint()事件處理常式在做的事情。

利用Graphics類別，我們可以操作GDI+繪圖介面去做我們想要做的事情，也就是在視窗上繪圖，這裡要特別注意，使用Graphics必須呼叫Dispose()釋放所使用的所有資源，不然就是使用using 陳述式。一般來說，在OnPaint()事件處理常式中使用Graphics物件對視窗繪圖，這樣視窗每次收到Paint事件時，就會保持視窗內容的樣子，而不會是一片空白(因為Windows作業系統不會幫你繪圖)。

取得Graphics物件的方式有兩個方法：

1. 一個是前述的OnPaint()事件處理常式中，利用PaintEventArgs參數取得所需要繪製的Graphics物件，也可以使用ClipRectangle屬性取得要繪製的矩形Rectangle結構。
2. 呼叫視窗(控制項)的CreateGraphics()方法取得。

另外，常用的影像物件是Bitmap物件(點陣圖)，Bitmap可以讀取和存檔的類型有：BMP、GIF、EXIG、JPG、PNG 及 TIFF(對於一般程式撰寫已經夠用了)，你可以使用GetPixel和 SetPixel方法為影像重新上色，這裡不建議使用這種方式，GetPixel和 SetPixel方法的效能不好，建議使用BitmapData的操作方式，效能上可以加速一個數量級左右。

重點在於：使用.NET Framework的影像處理，你要用Array運算，處理之後將Array的資料轉換至BitmapData，影像處理用Array，而影像呈現還是用Bitmap，如此就能解決效能瓶頸的問題。

使用BitmapData的方式如下，注意到要使用Bitmap類別的LockBits和UnlockBits方法。參考http://msdn.microsoft.com/zh-tw/library/5ey6h79d%28v=VS.90%29.aspx

// Create a new bitmap.
Bitmap bmp = new Bitmap("c:\\fakePhoto.jpg");

// Lock the bitmap's bits.  
Rectangle rect = new Rectangle(0, 0, bmp.Width, bmp.Height);
System.Drawing.Imaging.BitmapData bmpData =
    bmp.LockBits(rect, System.Drawing.Imaging.ImageLockMode.ReadWrite,
    bmp.PixelFormat);

// Get the address of the first line.
IntPtr ptr = bmpData.Scan0;

// Declare an array to hold the bytes of the bitmap.
int bytes  = bmpData.Stride * bmp.Height;
byte[] rgbValues = new byte[bytes];

// Copy the RGB values into the array.
System.Runtime.InteropServices.Marshal.Copy(ptr, rgbValues, 0, bytes);

// Set every third value to 255. A 24bpp bitmap will look red.  
for (int counter = 2; counter < rgbValues.Length; counter += 3)
    rgbValues[counter] = 255;

// Copy the RGB values back to the bitmap
System.Runtime.InteropServices.Marshal.Copy(rgbValues, 0, ptr, bytes);

// Unlock the bits.
bmp.UnlockBits(bmpData);

另外，Bitmap的PixelFormat建議使用Format32bppArgb的格式，也就是每像素 32 位元，各有 8位元用於 Alpha、Red、Green和Blue，雖然大多數的影像都24位元的Format24bppRgb，但是在使用BitmapData複製記憶體時，最好每個Stride(掃描寬度)是4bytes的倍數，避免記憶體對映到Bitmap發生影像的移位錯誤。

Digital Image Processing 數位影像處理

One picture is worth more than ten thousand words.
(A picture is worth a thousand words.)

今天介紹數位影像處理(Digital Image Processing)的聖經，這本書是在念碩士班的時候，三位研究影像處理的同學介紹的參考書籍。當時我覺得數位影像處理很有趣，不過因為和自己研究的Web方向不同，我一直遲遲沒有去研究，現在因為需要而自修數位影像處理，順便和大家分享入門的知識。


Rafael C. Gonzalez, Richard E. Woods原著，繆紹綱譯，數位影像處理，台北縣：普林斯頓國際，2009。
http://www.prenhall.com/gonzalezwoods/

首先，關於「玩影像」這件事可以分成三個層次，如下：

• 電腦視覺(Computer Vision)
  高階，輸入資料是影像，輸出資料是理解影像的資訊，目標是電腦模仿人類視覺的能力。電腦視覺的應用則稱為機器視覺(Machine Vision)，通常是用在製造業的工廠自動化上。
• 影像分析(Image Analysis)
  中階，輸入資料是影像，輸出資料是萃取影像的特徵。
• 影像處理(Image Processing)
  低階，輸入資料是影像，輸出資料也是影像，兩者差異在於影像經過運算處理。

關於影像的成因不外乎就是「光線」，廣義為電磁波，在這個電磁波頻譜上可以區分為(依照能量大至小排列)：

Gamma射線 > X光 > 紫外線 > 可見光 > 紅外線 > 微波 > 無線電波

也有其他可以做為成像的來源，例如超音波、電子顯微鏡和電腦合成的抽象影像等，所以我們研究影像時不要僅限於我們眼睛所看到的影像而已，影像處理的技術可以用在許多面向。

影像處理的步驟有：

1. 影像擷取(image acquisition)
2. 影像濾波與增強(image filtering and enhancement)
3. 影像復原(image restoration)
4. 彩色影像處理(color image processing)
5. 小波與多解析度處理(wavelet and multiresolution processing)
6. 壓縮(compression)
7. 形態學處理(morphological processing)
8. 分割(segmentation)
9. 表示與描述(representation and description)
10. 識別(recognition)

還有支持影像處理與分析所需要的「知識庫」，研究中...

Hypertext Preprocessor 超文本預處理器

PHP全名是Hypertext Preprocessor (超文本預處理器)，PHP是一個腳本式(Scripting)的編程語言(Programming Language)，主要是用在網頁應用程式(Web Application)的開發上面(PHP的強項)，但是也可以用在Windows開發或其他方面(只是可能不太適合)。

這篇文章是為了再次談論PHP的學習心得，早在一開始進入Web世界的時候，我就採用PHP做為學習的第一種語言，這是因為PHP是自由且免費的，加上語法簡單靈活，學習門檻低，所以當時才會選擇PHP學習Web程式開發。

爾後學習各類Web伺服器編程語言，如JSP、ASP.NET、Ruby、Python等，PHP一直是「揮之不去的夢靨(nightmare)」(靨，讀音ㄧㄝˋ，部首：面。)，不想要使用PHP都不行，因為太多現有的Web服務都是利用PHP開發而成，後續的維護也必須有人會PHP。因此，身為一個專業的網頁應用程式設計人員，我認為都應該具備基本的PHP能力。

PHP被忽略的地方：

• 開發圖形使用者介面(Graphical User Interface, GUI)的視窗程式，可以用PHP-GTK。
• PHP的起始標籤<?php和結尾標籤?>，結尾標籤可以省略(要加分號結束)，但PHP程式碼區塊中不能有任何HTML，最好是不要省略，寫程式還是嚴謹比較好，省略通常是用在include或require的PHP檔案中。
• 最後一行PHP程式，可以不使用分號(semicolon)結束，因為結尾標籤前面會自動加入。
• 魔術常數(Magic Constants)，真的很神奇又好用，魔術常數有：__LINE__、__FILE__、__DIR__、__FUNCTION__、__CLASS__、__METHOD__和__NAMESPACE__七個，這些常數與預設常數(Predefined Constants)相比還要經常使用。

當然還有許許多多有趣、被忽略的地方，通常是看Code或是撰寫Code才會發現，是不是這樣呢！

DirectShow FAQ 常見問題集

DirectShow常見問題集(Frequently Asked Questions, FAQs)

資料來源：http://msdn.microsoft.com/en-us/library/dd375463%28v=VS.85%29.aspx

• DirectShow技術的系統需求為何？
  DirectShow支援Microsoft Windows 95以後的作業系統。
• 利用DirectShow開發程式，我需要知道多少關於COM元件的知識？
  對於應用程式(Application)開發人員而言，你必須知道如何與COM元件互動：就是實體化(Instantiate)COM元件，存取CO元件揭露的介面(Interface)，並且管理這些介面的指標。若是想要開發Filter，那麼就要瞭解更多COM元件的知識。
• DirectShow支援哪些媒體規格？
  請參考：Supported Formats in DirectShow
• 是否存在於一份關於DirectShow的「硬體相容性清單」(Hardware Compatibility List, HCL)？
  沒有，DirectShow是基於Microsoft DirectDraw(處理視訊影像)和Microsoft DirectSound(處理聲音)的硬體相容，如果系統不支援這些，DirectShow則利用GDI (Graphics Device Interface)繪製視訊影像，聲音則使用Windows Core Audio API輸出聲音。
• 開發DirectShow可以使用哪種程式語言？
  DirectShow 主要用於C++語言開發。然而DirectShow API的一小部分可以利用Visual Basic 6.0開發，但是不推薦使用(deprecated)。
• .NET Framework的Managed Code可以直接叫用DirectShow嗎？
  不行，微軟目前沒有針對Managed Code提供API使用，必須透過互通性(Interoperability)元件叫用。
• DirectShow和Microsoft DirectX有什麼關聯性？
  當硬體支援時，在系統內部DirectShow使用DirectSound和DirectDraw。
  視訊渲染器(Video Renderer)和重疊混音器(Overlay Mixer)使用 DirectDraw 3和DirectDraw 5。
  視訊混合渲染器7 (僅限 Windows XP)使用DirectDraw 7 。
  視訊混合渲染器9 和增強型視訊渲染器則使用最新的 Microsoft Direct3D API。
  您不需要使用其他DirectX API來開發DirectShow，雖然也可以一起結合使用。
• DirectShow 與 Microsoft ActiveMovie 有什麼關聯性？
  DirectShow的名稱原本叫做ActiveMovie， 現在ActiveMovie這個術語已經不再使用。
• Graphedt.exe是否有提供原始程式碼？Graphedt.exe可以重新發佈嗎？
  沒有原始程式碼可以使用，Graphedt.exe不可重新發佈(redistributable)。
• 我要利用DirectShow開發應用程式，要如何設定開發環境？
  請參閱：Building DirectShow Applications

本文結束...

Inside Larry and Sergey's Brain [Google為什麼贏]

花了一週的時間看完「Google為什麼贏？─超越競爭者的創新思維」，這本書是天下雜誌出版翻譯的書籍，參考官方網址http://www.cwbook.com.tw/common/book.jsp?productID=4055，原文書名是「Inside Larry and Sergey's Brain」，整本書是以觀察者的角度記錄兩位創辦人「Larry Page(賴瑞‧佩吉)」與「Sergey Brin(賽吉‧布林)」的思想。

而中文書名其實應該以「賴瑞與賽吉的Google思維」會比較恰當，但是這種書名會比較不容易暢銷吧！眾多書籍總是要提到「贏、成功、創新...」等等的關鍵字，好像這就是銷售的基本保證，編輯不用因此承擔銷售量的責任(不是書名不好，而是...的因素才賣不好)，我買這本書不是因為書名的「贏、成功、創新...」，而是我對於Google創辦人的好奇心才購買的，不然我大可以在誠品書店躺著看完(實際上是在博客來網路書店買的)，這樣天下雜誌書版也賺不到錢。

理察‧布蘭特(Richard L. Brandt)著，朱家一譯，Google為什麼贏？，台北市：天下雜誌，2010。
(封面左邊是Larry Page，右邊是Sergey Brin)

接下來看看整本書的架構(瀏覽閱讀)，我特地找了原文書Inside Larry and Sergey's Brain的標題和中文對照，期望能對於原著作者的寫作義涵有更深入的了解。

前言 策略才是關鍵(Introduction: The World's Librarians)

前言利用亞歷山大圖書館(The Great Library of Alexandria)做為開場，後續的章節也都接續這個主題，亞歷山大圖書館是世界上第一座大型圖書館，亞歷山大圖書館蒐錄了當時世界上的圖書，這是一個理想，也似乎和Google的理想相同：「Google 的任務在於組織全世界的資訊，讓全球都能使用並有所裨益。」，而現代偉大的圖書館則是Google Books。Google重視企業道德，利用科技的經營策略，實現人類善良的理想，這一切都在這本書中可以察覺，對於Google我又更進一步認識，但願未來能夠在Google工作，這是一個可以為理想世界奮鬥的位子。

• 第一章 網路空間的仲裁者(Arbiters of cyberspace)
• 第二章 意外走上創業之路(Accidental entrepreneurs)，發行版是「意外創業」
• 第三章 亂中有序的企業文化(Controlled chaos)，發行版是「亂中有序」
• 第四章 賴瑞與賽吉的夢想(Larry and Sergey's corporate vision)，發行版是「賴瑞與賽吉的企業願景」
• 第五章 大眾化廣告(Advertising for the masses)，發行版是「廣告大眾化」
• 第六章 令人心碎的上市路(A heartbreaking IPO of staggering genius)，發行版是「令人心碎的公開上市」
• 第七章 進軍中國──最感不安的決定(The China syndrome : Google as big brother)，發行版是「中國併發症」
• 第八章 隱私權又如何？(What about privacy?)
• 第九章 冷酷無情的圖書館員(The ruthless librarians)
• 第十章 Google的雲端(The Google cloud)，發行版是「點子製造機」
• 第十一章 Google，電話公司？(Google, the telephone company?)
• 第十二章 超越搜尋的思維(Thinking beyond search : the world's problems, real and fanciful.)

小時候的生長環境必定會影響一個人的未來發展，我在這本書又看到了。賴瑞‧佩吉(Larry Page)的家庭和汽車、電腦有關，因此賴瑞‧佩吉對於電腦科技似乎有著基因的遺傳，書中用工業的鐵鎚代表他。而賽吉‧布林(Sergey Brin)則是數學家庭，他也因此對於數學有著基因的遺傳，書中用鐮刀代表它舊蘇聯的生長環境。兩位都是猶太人，都曾就讀蒙特梭利學校(Montessori Schoo)，可能是生長環境與教育的影響，鐵鎚和鐮刀對於改革、理想都有著不顧一切的態度，這使得Google的基因一開始就不太一樣了。

看完這本書，你會相信Google想要改變這個世界，當然改變舊有制度必定會遭受既有利益者的抗議，這些在第九章之後會一一看到。你也會一路看到賴瑞與賽吉兩人的轉變，為了理想而固執慢慢開始妥協，一步一步想辦法改變現有的世界朝向理想邁進。

書中對後一段提到這段話，和大家分享：「賴瑞與賽吉因Google而擁有爆發的財富，也擁有龐大的力量可以做一些改變，在未來十年也持續如此。他們就像發現自己是魔法師之後的哈利波特，有了自己的魔棒，我們可以預期他們做出一些偉大的事情。」我認為，如果你真的有理想要改變這個世界，就要有龐大的金錢與力量來推行，這麼做才有可能實現理想完成夢想，是吧？

---

主題閱讀

藍道‧史卓恩(Randall Stross)，吳嘉哲、黃貝玲譯，Google衝擊，台北：遠流，2009。

傑夫‧賈維斯著，龐文真、林麗冠譯，Google會怎麼做？，台北：天下遠見，2009。

Moodle Programming 模組化物件導向動態學習環境

這篇文章是為了瞭解Moodle (Modular Object-Oriented Dynamic Learning Environment)的整個程式架構，剛好最近對於程式碼的研究有興趣，再加上學弟(專門研究Moodle的小黑)也正在開發新功能。因此，花了一些時間大概解析一下程式碼，使用的Moodle是1.9.8版本，整個Moodle的目錄有下列資料夾(共32個，可以看成是32個區塊，每個區塊皆有特定功能)：

1. admin=>管理功能
2. auth=>使用者驗證(authentication)功能
3. backup=>備份/復原(backup/recover)功能
4. blocks=>區塊功能
5. blog=>部落格功能
6. calendar=>日曆功能
7. course=>課程(活動紀錄)功能
8. enrol=>入學註冊(enrolment)功能
9. error=>謬誤輸出功能
10. files=>檔案上傳功能
11. filter=>過濾器
12. grade=>評分功能
13. group=>使用者群組管理
14. install=>程式安裝功能
15. iplookup=>地理位置功能
16. lang=>語言包
17. lib=>函式庫
18. login=>登入功能
19. message=>信息功能
20. mnet=>網路功能
21. mod=>活動中的模組功能
22. my=>"我的"(個人化)功能
23. notes=>筆記功能
24. pix=>圖片檔案
25. question=>問卷功能
26. rss=>簡易資訊聚合(即Really Simple Syndication, RSS)功能
27. search=>搜尋功能
28. sso=>單一登入(Single Sign-On, SSO)功能，已經棄用(deprecated)移至auth功能
29. tag=>標籤函式庫(Tag Library)
30. theme=>外觀主題功能
31. user=>使用者功能
32. userpix=>顯示使用者圖片

根目錄下的檔案：

1. config-dist.php=>組態設定檔的樣板，包含常用的設定範例
2. config.php=>組態設定檔，Moodle安裝完成後產生
3. COPYING.txt=>版權說明檔
4. file.php=>從資料目錄(moodledata)取得檔案的功能
5. help.php=>說明支援頁面
6. index.php=>進入點(Entry Point)
7. install.php=>安裝執行檔
8. manifest.txt=>關於檔案的檔案(貨艙清單)
9. README.txt=>讀我檔案
10. tags=>標籤檔(tag file)
11. tags.txt=>標籤檔說明文件
12. version.php=>版本資訊

開發人員文件：http://docs.moodle.org/en/Development#How_Moodle_development_works

大概對Moodle的程式碼先有個概念，之後再繼續詳細說明，特別感謝小黑討論與分享經驗。

Joel on Software 約耳趣談軟體

人月神話之外，另一本軟體開發管理的經典著作！

與大家介紹一下這本「約耳趣談軟體：來自專案管理的現場實錄(Joel on Software)」，當我買了之後閱讀，才發現所有的文章(不知道是不是全部)在網站上都有(Joel on Software Translation Project ，Joel on Software)，換句話說，你可以看免費的(還是請大家支持購買)，希望我寫這篇不會影響書籍銷售。

註：原著書名相當長，「Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity」，所以此書簡稱「約耳趣談軟體(Joel on Software)」。


約耳趣談軟體：來自專案管理的現場實錄
Joel Spolsky著，梅普華譯，約耳趣談軟體，台北市：精誠資訊，2010。

---

請參閱原始網頁(中文翻譯版本)http://local.joelonsoftware.com/wiki/The_Joel_on_Software_Translation_Project:實體書

第一部份：位元與位元組(Bits and Bytes)

• 選擇一種程式語言 - Choosing a Language
• 回歸原點 - Back to Basics
• 約耳測試：邁向高品質的12個步驟 - The Joel Test: 12 Steps to Better Code
• 每個軟體開發者都絕對一定要會的 Unicode及字元集必備知識(沒有藉口！) - The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode (No Excuse!)
• 無痛功能規格 - 第一篇: 何必麻煩呢? - Painless Functional Specifications. Part 1: Why Bother?
• 無痛功能規格 - 第二篇: 規格是什麼? - Painless Functional Specifications. Part 2: What's a Spec?
• 無痛功能規格 - 第三篇: 不過...要怎麼做呢? - Painless Functional Specifications. Part 3: But。How?
• 無痛功能規格 - 第四篇: 提示 - Painless Functional Specifications. Part 4: Tips
• 無痛軟體時程 - Painless Software Schedule
• 每日編譯(Daily Build)是你的好朋友 - Daily Builds Are Your Friend
• 絕不妥協的抓蟲行動 - Hard-Assed Bug Fixin'
• 五個世界 - Five Worlds
• 紙上原型製作 - Paper Prototyping
• 別讓架構太空人嚇到你 - Don't Let Architecture Astronauts Scare You
• 邊開火邊移動 - Fire and Motion
• 工匠技藝 - Craftsmanship
• 電腦科學中三個錯誤的想法 - Three Wrong Ideas from Computer Science
• 雙元文化主義 - Biculturalism
• 由使用者端自動取得當機回報 - Get Crash Reports From User Automatically!

第二部份：管理開發人員(Managing Developers)

• 軟體人員面試教戰守則 - The Guerilla Guide to Interviewing
• 激勵有害 - Incentive Pay Considered Harmful
• 不用測試人員 的五大(錯誤)藉口 - Top Five (Wrong) Reasons You Don't Have Testers
• 人的工作切換有害無益 - Human Task Switches Considered Harmful
• 你絕對不應該做的事 之一 - Things You Should Never Do, Part One
• 揭露冰山般的秘密 - The Iceberg Secret, Revealed
• 抽象滲漏法則 - The Law of Leaky Abstractions
• 程式設計領域的帕麥爾斯頓勳爵 - Lord Palmerston on Programming
• 測量 - Measurement

第三部份：身為約耳：對某些主題的隨想(Part three: Being Joel: Random Thoughts on Not-So-Random Topics)

• Rick Chapman在尋找愚蠢 - Rick Chapman is In Search of Stupidity
• 這個國家的狗做什麼 工作？ - What Is the Work of Dogs in this Country
• 小員工也能做大事 - Getting Things Done When You're Only a Grunt
• 兩個故事 - Two Stories
• 大麥克對原味主廚 - Big Macs vs. The Naked Chef
• 沒有事情像表面 看起來那麼簡單 - Nothing is as Simple as it Seems
• 為非我發明症辯護 - In Defense of Not-Invented-Here Syndrome
• 策略書之一： Ben and Jerry模式與Amazon模式 - Strategy Letter I: Ben & Jerry's vs. Amazon
• 策略書之二：雞生蛋蛋生雞問題 - Strategy Letter II: Chicken-and-Egg Problems
• 策略書之三：讓我換回去！ - Strategy Letter III: Let Me Go Back!
• 策略書之四：腫脹軟體 (bloatware)與80/20神話 - Strategy Letter IV: Bloatware and the 80/20 Myth
• 策略書之五：開碼源碼的經濟學 - Strategy Letter V: The Economics of Open Source
• 墨菲定律發威的一週 - A Week of Murphy's Law Gone Wild
• 微軟如何輸掉API戰 爭 - How Microsoft Lost the API War

第四部份：對.NET有點過頭的批評(A Little Bit Too Much Commentary on .NET)

• 微軟瘋了 - Microsoft Goes Bonkers
• 我們的.NET策略 - Our .NET Strategy
• 先生可以賞我一 個連結程式嗎？ - Please Sir May I Have a Linker

---

最後希望大家可以看看這些文章，充實自己對於軟體專案的認識，未來我們也才能夠開發更好的服務而改變這個世界。