Electrical Engineering By t5318019® In NTUT™

National Taipei University of Technology 台北科技大學

2011-12-26T19:30:00.000+08:00

今年(2011年)捐贈書籍的時間又到了，這次捐贈的數量較少，主要是找不到什麼好書可以捐贈。每次捐贈知會先調查圖書館是否已經購置，沒有購置才會列入我的選書清單之中，接著再將評估看看是否是一本好書，以及總金額是否超出今年的預算。

所謂「好書」，我所指的是內容的品質，主要看有沒有架構與深度。若是國外著作的翻譯本，一般來說都是好書，不好通常是翻譯品質不好，詞不達意、專有名詞錯誤等的問題。

如果是國內電腦相關出版品的話，內容上有濫竽充數、品質參差不齊的現象，用大量貼圖膨脹版面、觀念不敘述(只講述操作步驟)的問題，所幸近幾年已經改善不少，然而多數書籍出版依舊以中初級的程度為主，可能是國內市場不夠大的關係。

這次捐贈的書籍清單如下所述：

Paul Barry著，蔣大偉譯，深入淺出 Python，台北：歐萊禮，2011。
David Powers著，陳亦苓譯，跟Adobe徹底研究Dreamweaver CS5與PHP，台北：上奇資訊，2011。
Alan Beaulieu著，張偉超、林青松編譯，陳佳新審校，SQL學習手冊(第二版)，台北：碁峯資訊，2011。
Bruce Lawson, Remy Sharp著，陳亦苓譯，Hello！HTML5，台北：松崗，2011。
Zoe Mickley Gillenwater著，張雅芳譯，想做好網站一定要會的CSS3，台北：碁峯資訊，2011。
呂昶億、杜慎甄著，Dreamweaver CS 5.5全新進化，台北：松崗，2011。

期望國內能有更多的優良書籍出版，好讓我捐獻給學校。(大家都去借書了，誰來買啊...)
###

Design Patterns 2nd 物件導向設計模式 2讀

2011-12-22T20:43:00.000+08:00

書不怕被多翻閱幾次，每次閱讀總會有不同的收穫！拿起身旁的「物件導向設計模式」這本書，兩年前(2009)對於設計模式非常有興趣，不過看完沒有多少體悟，經過兩年的軟體開發經歷，現在對於設計模式有不同的心得感想。

設計模式(Design Patterns)開宗明義指出：「設計物件導向軟體很難，設計可再利用(reusable)的物件導向軟體更難。(Designing object-oriented software is hard, and designing reusable objectoriented software is even harder.)」設計模式的目的與意義就是解決這個設計問題，由四人幫(Gang of Four, GoF)將物件導向設計的成功經驗整理成為「設計模式」，藉由設計模式將成功的設計與架構更容易可再被利用，讓設計師更快設計出正確的軟體，讓新的系統開發者更容易進入狀況。

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides著(所稱「四人幫」)，葉秉哲譯，物件導向設計模式：可再利用物件導向軟體之要素，台北：台灣培生教育，2001。

「設計模式」一詞源於美國建築理論學家─克里斯多福‧亞歷山大(Christopher Alexander)，他解釋：

每一則模式都在描述某種一再出現的問題，並描述解決方案的核心，讓你能據以變化出各種招式，解決上萬個類似的問題。

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

物件導向的設計模式由四人幫提出3大類(依據目的劃分)共23種設計模式，由他們對設計模式命名與編纂(ㄗㄨㄢˇ)成型錄。

X		目的
X		生成模式 (Creational Patterns)	結構模式 (Structural Patterns)	行為模式 (Behavioral Patterns)
範疇	類別	工廠方法模式 (Factory Method)	轉接器模式 (Adapter)	解譯器模式 (Interpreter) 範本方法模式 (Template Method)
範疇	物件	抽象工廠模式 (Abstract Factory) 建造者模式 (Builder) 原型模式 (Prototype) 獨體模式 (Singleton)	轉接器模式 (Adapter) 橋接模式 (Bridge) 組合模式 (Composite) 裝飾模式 (Decorator) 外觀模式 (Façade) 享元模式 (Flyweight ) 代理模式 (Proxy)	職責鏈模式 (Chain of Responsibility) 命令模式 (Command) 迭代器模式 (Iterator) 仲介者模式 (Mediator) 備忘錄模式 (Memento) 觀察者模式 (Observer) 狀態模式 (State) 策略模式 (Strategy) 訪問者模式 (Visitor)

由上表可以看到設計模式使用的範疇分為兩類，一是類別，另一是物件。類別模式處理類別與子類別之間的設計方式，在程式編譯期間(compile-time)就已經決定，屬於靜態關係。而物件模式則是處理物件之間的設計方式，在程式執行期間(run-time)才運作，屬於動態關係。

有關物件導向設計模式必須慢慢仔細品嚐，才能發覺其中設計的精神！

###
延伸閱讀
物件導向設計模式

Learning Python 學習手冊

2011-12-15T21:37:00.000+08:00

Python程式語言在台灣似乎沒有很多人使用，可能是學校教育大多數是教C和C++這類的程式語言，如果有興趣學習其他程式語言，我優先推薦學習Python，因為Python免費、可移植、功能強大(自動記憶體管理)、易於使用等優點。

中文Python參考書籍是相當少，這裡推薦台灣歐萊禮翻譯出版的「Python學習手冊」，這本書的內容範圍夠廣，討論深度夠深，說是Python聖經本也夠資格。不過目前看來中文已經絕版，不曉得是不是因為英文已經出了第4版，所以第3版的Python學習手冊才不繼續發行。

Mark Lutz原著，陳建勳譯、蘇秉豐編，Python學習手冊‧第三版，台北：歐萊禮，2008。譯自：Learning Python, 3rd Edition. O'Reilly Media.

學習程式語言除了瞭解語法之外，最重要的是程式語言本身的精神(觀念與特質)要掌握住，Python是一種物件導向描述語言(object-oriented scripting language)，加上Python是動態定型的方式(資料型態不用宣告)。對於熟悉C++的人而言，很多觀念很像但卻是不一樣，特別是動態定型的特性，這是Python具有彈性的根源，也是讓Python在程式語言的實作上和使用上有所差異的原因。

全書分成8卷共29章，內容不外乎講述語法和觀念，但這本書有講到Python核心，像是「第六章動態定型簡介」就屬於程式語言如何實作的部份。此外Python的套件(package)、模組(module)是Python獨有的概念，學習上一定要建立觀念，而在物件導向方面則要注意類別(class)物件和實體(instance)物件的觀念。

卷 1 入門簡介

第一章 Python 簡介
第二章 Python 如何執行程式
第三章如何執行程式

卷 2 型態和運算

第四章 Python 物件型態簡介
第五章數字
第六章動態定型簡介
第七章字串
第八章串列和辭典
第九章 Tuple、檔案、以及其他一切

卷 3 敘述和語法

第十章 Python 敘述簡介
第十一章指定敘述、運算式、以及列印
第十二章 if 測試
第十三章 while 與 for 迴圈
第十四章說明文件插曲

卷 4 函式

第十五章函式基礎
第十六章範圍和引數
第十七章高等函式議題

卷 5 模組

第十八章模組：大藍圖
第十九章模組撰碼基礎
第二十章模組套件
第廿一章高等模組議題

卷 6 類別和 OOP

第廿二章 OOP：大藍圖
第廿三章類別撰碼基礎
第廿四章類別撰碼細節
第廿五章類別的設計
第廿六章高等類別議題

卷 7 例外事件和工具

第廿七章例外事件基礎
第廿八章例外事件物件
第廿九章例外事件的設計

卷 8 附錄

附錄 A 安裝和組態
附錄 B 每卷練習題解答
附錄 C Python 中文處理

「Python學習手冊‧第三版」以Python 2.5為執行環境，目前Python 2已經有2.7版，而且已經有Python 3了，使用上要注意版本的差異。期望有更多人加入學習Python的行列！也希望中文版的Python學習手冊能有第4版。

###

Object-Oriented Analysis and Design with Applications 物件導向分析設計與應用

2011-12-15T18:23:00.002+08:00

物件導向(Object-Oriented, OO)是目前軟體開發中經常使用的設計典範(paradigm)，很重要的概念但我一直以來沒有好好瞭解清楚，「物件導向分析設計與應用」這本書正好補足我這方面的知識，閱讀之後感覺相見恨晚，書中內容都是物件導向的經典！這本書的翻譯相當流暢且確實，非常感謝譯者蔡煥麟先生的用心。

Conallen, Young, Maksimchuk, Houston, Booch & Engle著，蔡煥麟譯，物件導向分析設計與應用，台北：碁峯資訊，2009。譯自：Object-Oriented Analysis and Design with Applications, 3/E。

「物件導向分析設計與應用」如同書名一樣，內容主要是講述物件導向分析(OOA)與物件導向設計(OOD)，較少在物件導向程式設計(OOP)上著墨。全書分成3篇共12章，分別是概念(Concepts)、方法(Method)與應用(Applications)三個部分，前兩部分較偏向理論說明，而最後一部分透過實際案例的分析設計，讓我們讀者對於OOAD能有實務的經驗。

我認為這本書最重要的地方是第一篇概念，學習物件導向往往偏重於設計方法與實作的部分，可是卻造成「知其然而不知其所以然」，我們在這本書中可以清楚知道為何需要「物件導向」的原因，難得一見(也可能是自己看的聽的不夠多)。使用物件導向是為了解決軟體複雜性的問題，這個精神一定要謹記在心，分析和設計都是為了這件事。

物件導向利用物件模型(object model)降低系統的複雜性，於是我們才能比較容易處理問題，其中物件模型包含抽象化、封裝、模組化、階層、定型、並行性、續存性等概念，這些都是物件導向的核心概念。使用物件模型提高程式的可再用性與可維護性，讓軟體開發及維護更有效率。

對於正在學習物件導向程式語言(programming language)的人，我特別推薦閱讀這本「物件導向分析設計與應用」，你將可以結合物件導向的精神和程式碼，學習上將更有所體悟。

###

延伸閱讀
System Analysis and Design 系統分析與設計
Unified Modeling Language 統一塑模語言
Object-Oriented Programming物件導向程式設計
Design Patterns物件導向設計模式

Brownfield Application Development in .NET 軟體構築美學

2011-12-11T17:59:00.000+08:00

軟體開發當中，最不想遇到的情形就是「接手既有的專案」，因為不曉得藏有多少bug，加上各個開發者撰寫程式風格的差異，於是必須先看懂程式碼才能改善或加入新功能，這有時比重新開發要花更多心力，如果又沒有相關的開發文件或規格，接手這樣的專案只能祈求神明保佑。

現在，「軟體構築美學：當專案團隊遇上失控程式，最真實的解決方案」這本書提供我們面對上述這類「棕地應用程式」應該如何處理。所謂棕地(brownfield)這個詞彙是借用建築領域中的定義：

棕地土地(簡稱棕地)，主要是用在工業上或商業上的一塊土地，並且這塊土地可能被低濃度的放射性物質或危險的廢物所污染，一旦清除這些污染，有可能將再次的重新使用。

Kyle Baley & Donald Belcham著，蔡煥麟、張簡才祿譯，軟體構築美學，台北：精誠資訊，2010。譯自：Brownfield Application Development in .NET。

棕地應用程式(Brownfield Application)指的是一個既有的軟體專案，此專案可能因為用了一些不好的開發方式、結構、或設計而產生許多問題，但若經過仔細的整理和重構(refactoring)，還是有機會繼續發展使用。棕地應用程式包含三個基本元素：(1)既有程式碼、(2)差勁實務做法所造成的污染、(3)仍有改善或重複使用的潛力。

注意到「棕地」不同於「老舊(legacy)」應用程式，棕地介於「綠地(greenfield)」與老舊之間，綠地應用程式沒有舊專案或技術的歷史包袱，而棕地應用程式通常有很沉重的，至於老舊應用程式則是處於維護不開發。有了這些概念之後，就會清楚瞭解這本書主要想說明什麼內容了。

「軟體構築美學」總共13章，分成開發環境(The ecosystem)和程式碼(The code)兩個部分，一個開發人員面對的不外乎這兩個範疇。第1章是介紹棕地應用程式，後續幾章則說明棕地應用程式在這兩個範疇中有哪些痛點(pain point)和解決方法。

第1章，認識棕地應用程式(Understanding Brownfield Applications)

Part 1 開發環境(The ecosystem)

第2章，棕地專案的版本控制(Version Control in Brownfield Applications)
第3章，持續整合(Continuous Integration)
第4章，自動化測試(Automated Testing)
第5章，軟體度量與程式碼分析(Software Metrics and Code Analysis)
第6章，瑕疵管理(Defect Management)

Part 2 程式碼(The code)

第7章，在專案中導入好的物件導向實務(Bringing Better OO Practices to the Project)
第8章，應用程式的重新分層(Relayering Your Application)
第9章，鬆散一些：降低程式碼的依賴性(Loosen up: Taming your Dependencies)
第10章，重整使用者介面(Cleaning up the User Interface)
第11章，重構資料存取(Refactoring Data Access)
第12章，管理系統外部的依賴(Managing External System Dependencies)
第13章，持續改善(Keeping the Momentum)

多數軟體專案常常受到「汙染」(通常不是惡意的，是不得已或無知之錯)，隨著開發時間的增長，汙染程度與日俱增，最後根本無法維護利用。「軟體構築美學」適合推薦給專案管理與系統開發人員，裡面有太多正確的觀念和務實的作法非常值得學習，期望閱讀後不要再有「汙染」產生。

###

How We Test Software at Microsoft 軟體測試之道

2011-12-08T22:26:00.000+08:00

在實際工作環境之中，軟體測試(Software Testing)在軟體開發流程似乎沒有受到重視，大都將軟體重心放在開發(Development)上，這樣的態度實在不好，最後往往導致有產品卻不能用，Bug太多沒有品質。

「軟體測試之道」介紹微軟(Microsoft)這間大型軟體公司的如何去做軟體測試，書中提到微軟的開發人員與測試人員的比例大約是1比1，並且落實軟體工程。我想因為有這些因素，微軟才能做出複雜又高品質的軟體系統(平台與應用程式)，其中微軟的工程領域有鐵三角 (triad)，指的是測試、開發與計畫管理三個專業領域，這也說明軟體測試是一個專業的技術。

Alan Page, Ken Johnston, Bj Rollison著，林宗斌譯，軟體測試之道－微軟測試團隊的成功經驗、方法與技術，台北：碁峯資訊，2010。譯自：How We Test Software at Microsoft。

本書分成四大部分，總共16章：

Part I, 關於微軟(About Microsoft)

Chapter 1, 微軟的軟體工程(Software Engineering at Microsoft)
Chapter 2, 微軟的軟體測試工程師(Software Test Engineers at Microsoft)
Chapter 3, 工程生命週期(Engineering Life Cycles)

Part II, 關於測試(About Testing)

Chapter 4, 測試案例設計的實務作法(A Practical Approach to Test Case Design)
Chapter 5, 功能測試技術(Functional Testing Techniques)
Chapter 6, 結構測試技術(Structural Testing Techniques)
Chapter 7, 分析複雜程式碼的風險(Analyzing Risk with Code Complexity)

Chapter 8, 以模型為基礎的測試(Model-Based Testing)

Part III, 測試工具和系統(Test Tools and Systems)

Chapter 9, 管理臭蟲和測試案例(Managing Bugs and Test Cases)
Chapter 10, 測試自動化(Test Automation)
Chapter 11, 非功能性測試(Non-Functional Testing)
Chapter 12, 其他工具(Other Tools)
Chapter 13, 用戶反饋系統(Customer Feedback Systems)
Chapter 14, 測試軟體加服務(Testing Software Plus Services)

Part IV, 關於未來(About the Future)

Chapter 15, 防患未然(Solving Tomorrow’s Problems Today)
Chapter 16, 創建未來(Building the Future)

第一部分主要說明微軟的軟體開發運作情形，可以看到微軟的開發人員有兩種：軟體開發工程師(Software Development Engineer, 簡稱SDE)與軟體測試開發工程師(Software Development Engineer in Test, 簡稱SDET)，微軟的測試人員本身就是開發人員！SDET除了設計測試案例(Test Case)之外，還需提出設計改善建議、問題原因分析、参與程式碼複閱...等，不是只有找bug就沒事。

第二部分與第三部分則偏重於軟體測試本身的方法與技術說明，我想這部分對於軟體開發人員都應該好好閱讀瞭解，你會發現軟體測試本身真的不是一件簡單容易的事情！這點常常會被忽略而輕視。最後第四部份則是說明微軟未來在測試和品質的方向。

「軟體測試之道」這本書除了講述軟體測試，也包含很多組織與團隊的內容，不只是一本技術的書籍，也適合管理職位的人閱讀，微軟的軟體工程值得借鏡。

###

Designing Web Interfaces 網頁介面設計模式

2011-12-06T21:35:00.000+08:00

自從AJAX技術盛行之後，使用者介面(User Interface, UI)設計越顯得重要，期望能夠提高使用者經驗(User Experience, UX)。

現在，網頁設計師可以參考「網頁介面設計模式」這本書，作者整理網頁介面的精隨成為設計原則(design principles)，也就是「設計模式(design patterns)」，相信不管你是不是設計師，藉由參考設計模式也可以做出相當品質的使用者介面。

Bill Scott & Theresa Neil著，古又羽譯，網頁介面設計模式，台北：碁峯資訊，2011。譯自：Designing Web Interfaces: Principles and Patterns for Rich Interactions, O'Reilly Media。

官方網站(英文)：http://designingwebinterfaces.com/

這本書的架構以6個設計原則為主體，共14章，包含75種介面設計模式：

原則1, 操作直接性(Make it Direct)

第一章，頁內編輯(In-Page Editing)

單欄直接編輯(Single Field Inline Edit)
多欄直接編輯(Multi-Field Inline Edit)
覆蓋視窗編輯(Overlay Edit)
表格編輯(Table Edit)
群組編輯(Group Edit)
模組組態設定(Module Configuration)

第二章，拖放功能(Drag and Drop)

拖放模組(Drag and Drop Modules)
拖放清單(Drag and Drop List)
拖放物件(Drag and Drop Object)
拖放動作(Drag and Drop Action)
拖放集合(Drag and Drop Collection)

第三章，直接選取(Direct Selection)

雙態觸變選取(Toggle Selection)
集合選取(Collected Selection)
物件選取(Object Selection)
混合選取(Hybrid Selection)

原則2, 保持輕質(Keep it Lightweight)

第四章，情境工具(Contextual Tools)

永遠顯示工具(Always-Visible Tools)
滑過顯示工具(Hover-Reveal Tools)
雙態觸變顯示工具(Toggle-Reveal Tools)
多層級工具(Multi-Level Tools)
副選單(Secondary Menu)

原則3, 同頁作業(Stay on the Page)

第五章，覆蓋視窗(Overlays)

對話型覆蓋視窗(Dialog Overlay)
詳細型覆蓋視窗(Detail Overlay)
輸入型覆蓋視窗(Input Overlay)

第六章，嵌入面板(Inlays)

對話型嵌入面板(Dialog Inlay)
清單型嵌入面板 (List Inlay)
詳細型嵌入面板(Detail Inlay)
欄標(Tabs)

第七章，虛擬頁面(Virtual Pages)

虛擬捲動(Virtual Scrolling)
直接分頁(Inline Paging)
捲動分頁(Scrolled Paging)
虛擬平移(Virtual Panning)
可縮放使用者介面(Zoomable User Interface)

第八章，程序流程(Process Flows)

互動式單頁程序(Interactive Single-Page Process)
直接輔助程序( Inline Assistant Process)
對話型覆蓋視窗程序(Dialog Overlay Process)
組態設定器程序(Configurator Process)
靜態單頁程序(Static Single-Page Process)

原則4, 送出邀約(Provide an Invitation)

第九章，靜態邀約(Static Invitations)

採取行動邀約(Call to Action Invitation)
遊覽邀約(Tour Invitation)

第十章，動態邀約(Dynamic Invitations)

滑過邀約(Hover Invitation)
可視線索邀約(Affordance Invitation)
拖放邀約(Drag and Drop Invitation)
推理邀約(Inference Invitation)
更多內容邀約(More Content Invitation)

原則5, 善用轉換效果(Use Transitions)

第十一章，轉換模式(Transitional Patterns)

打亮與轉暗(Brighten/Dim)
展開與摺疊(Expand/Collapse)
自我復原淡出(Self-Healing Fade)
動畫(Animation)
聚光燈效果(Spotlight)

第十二章，轉換效果的目的(Purpose of Transitions)

滑進與滑出(Slide In/Slide Out)
面板(Faceplate)
翻轉(Flip)
手風琴式展開(Accordion)
旋轉木馬跑馬燈(Carousel)
淡入(Fade)
放大(Zoom)
知覺效能(Perceived Performance)

原則6, 即時反應(React Immediately)

第十三章，查詢模式(Lookup Patterns)

自動完成(Auto Complete)
即時建議(Live Suggest)
即時搜尋(Live Search)
精煉搜尋(Refining Search)

第十四章，回饋模式(Feedback Patterns)

即時預覽(Live Preview)
漸進式揭示(Progressive Disclosure)
進度指示器(Progress Indicator)
定期重新整理(Periodic Refresh)

作者在每個設計模式中，除了說明功能和特色之外，還有「問題探討」與「重要常規」兩個部分，「問題探討」講述這個設計模式可能淺在的議題，而「重要常規」則是使用上建議必須遵守的規則。這些內容都只有在書籍中才有敘述，官方網站上沒有細部說明，因此建議購買或借閱來看，這些寶貴的經驗絕對值得。

推薦序提到一個建築觀念，以設計原則為主並以設計考量(design considerations)為輔去建構出建築物，我想這個概念同樣適用於網頁設計上，只要我們掌握住上述這些設計模式，設計時考量各種限制與衝突，則建立優異的使用者經驗將不會是一件困難的事情！

###

Stunning CSS3 想做好網站一定要會的CSS3

2011-12-05T21:35:00.000+08:00

Cascading Style Sheets (CSS)是網頁中用來設計樣式的語言，重要性與HTML和JavaScript相當，一個網頁設計師應該要熟悉這三種語言。W3C持續訂定CSS第3版的規範，稱為CSS3，CSS3不只是舊版CSS2.1的延伸，還加入一些新功能！

目前有關CSS的書籍不多，這本「想做好網站一定要會的CSS3」講述CSS3的重要功能，並提出「漸進式增強(Progressive Enhancement)」的網頁製作方式，雖然CSS3標準尚未制定完全(請參考目前CSS3工作進度)，各瀏覽器也未必完全支援，但作者認為漸進式使用CSS3的好處多於缺點。

Zoe Mickley Gillenwater著，張雅芳譯，想做好網站一定要會的CSS3，台北：碁峯資訊，2011。譯自：Stunning CSS3: A Project-based Guide to the Latest in CSS。

本書共分成7章，第1章說明CSS3的概況，第2章至第7章介紹CSS3的重要功能，基本上是對應於CSS3中不同模組(module)的規範，書中介紹的主題如下：

非影像的視覺特效、區塊變形(transforms)

特殊字型

CSS Fonts模組

選取器(selector)

Selectors模組

轉換(transitions)、動畫(animations)

媒體查詢(Media Queries)

Media Queries模組

多欄版面(Multi-column Layout)

推薦這本書給想認識CSS3的人，注意「想做好網站一定要會的CSS3」不是參考工具書喔！想要看CSS規範請至W3C網站查詢。

###

延伸閱讀
3 Elements of A Web Page網頁三元素

HTML5: Up and Running

2011-12-03T11:10:00.000+08:00

HTML5的話題一直持續不斷，HTML5已經是未來網頁的標準(據說要到2022年才會定案)。最近仔細研究了一下HTML5，發現HTML5的範疇比想像中還要大，不能只說是網頁(Web pages)的標準，由於HTML5新增不少功能，可不只是定義網頁的元素標記(tag)。

因此，我認為HTML5是一個網頁應用程式(Web Applications)的標準，這幾乎是全新的一個「HTML網頁標準」！很多HTML5新功能需要JavaScript的操作才能使用，於是要學好HTML5可能需要花費更多心力，變成HTML5和JavaScript都要熟悉了。

Mark Pilgrim著，莊惠淳譯，「HTML5：建置與執行」，台北：碁峰資訊，2011。譯自：HTML5: Up and Running。

這本書總共10章，第一章「從頭說起」說明HTML的歷史，第二章說名檢測HTML5的方法，使用Modernizr這個JavaScript程式庫工具，從第三章到第十章探討8個主題：

新的語義元素，HTML5新增的語義元素標記。
繪圖，使用<canvas>標記。可以參考HTML5 canvas - the basics的說明
可以內嵌在網頁中的影片，使用<video>標記。
地理位置，位於navigator物件的geolocation屬性。
永久性的本地端儲存功能，位於window物件的applicationCache屬性。
離線的網頁應用程式，位於window物件的localStorage屬性。
改良的HTML表單，新增input標記的型別。
微資料(microdata)，客製用語典(custom vocabularies)。

整體而言，這本書可以讓我們窺見HTML5的概況，內容方面是講述大方向、以概念為主，因此，「HTML5：建置與執行」適合給想認識HTML5的人。若想細部瞭解HTML5的語法和用法，需要再去閱讀HTML5的規範與相關應用的程式碼。

###

延伸閱讀
3 Elements of A Web Page網頁三元素

Learning SQL

2011-11-28T11:28:00.001+08:00

SQL語言是使用資料庫時的基礎能力，對一個資料庫管理系統操作就是「說」SQL語言！這裡介紹一本學習SQL語言的入門書籍，由歐萊禮(O'Reilly Media)出版，碁峰資訊發行，非常適合想學習SQL語言的初學者。

Alan Beaulieu著，張偉超、林青松編譯，陳佳新審校，SQL學習手冊(第二版)，台北：碁峯資訊，2011。譯自：Learning SQL, 2nd Edition (Master SQL Fundamentals), O'Reilly Media。

SQL語言可分為三類：

SQL結構描述陳述式(SQL schema statements)
有關建立資料庫(資料表、索引、條件約束)，通常是資料庫管理員要熟悉的工作內容。
SQL資料陳述式(SQL data statements)
建立、操縱和擷取儲存在資料庫中的資料，通常是程式開發人員與資料庫使用者，以及資料庫管理員必須熟悉的工作內容。
SQL交易陳述式(SQL transaction statements)
在多使用者的環境之下，用來開始、結束和回復交易，通常是程式開發人員與資料庫使用者必須熟悉的工作內容。

作者將重點放在講述SQL資料陳述式，全書總共15章，用了前面12章說明資料操作的語法，因此這本書適用於程式開發人員與資料庫使用者。另外，這本書以MySQL做為範例操作的資料庫系統，由於MySQL自由免費，而且安裝與使用都很簡單，因此沒有理由學不會SQL語言！

注意到，書中使用MySQL 6.0版本，目前2011年只有MySQL Community Server 5.5版本。從Wikipedia搜尋發現，MySQL使用新的發行模型(New Release Model)，6.0.11是最後一版，詳細可以參閱MySQL開發週期。

###

延伸閱讀
Database 資料庫

System Analysis and Design 系統分析與設計

2011-11-11T13:44:00.001+08:00

前些日子研讀系統分析與設計(System Analysis and Design)，有個問題讓我感到疑惑，為何系統分析與設計的書籍都是討論「資訊系統(Information System)」呢？若是如此，那書名應該改成「資訊系統分析與設計」。因為我認為「系統」是一個很大範圍的主題，不應該只侷限於資訊系統的分析與設計。同樣介紹一本書，資訊如下所示，聽jasper312說這是「系統分析與設計」領域的聖經本，各大考試的題目與解答都從參考這本喔！

吳仁和、林信惠，系統分析與設計—理論與實務應用，台北：智勝文化，2010。

書籍只討論資訊系統的理由，我認為有二個原因。第一，討論資訊系統比較簡單容易，目前資訊系統的分析設計工具與方法很多，因此討論會比較具體且容易。第二，萬物皆是「資訊系統」，自然界中不外乎存在三種：物質、能量與資訊，討論資訊系統也就等於包含所有的系統。雖說是如此，但系統分析與設計的書籍看到最後，好像就是一本「軟體工程(Software Engineering)」的書籍，變成都是講述軟體開發流程。關於這點，希望未來能有書籍從不同的角度去討論「系統分析與設計」。

「系統分析與設計—理論與實務應用」這本書從兩個主要技術方法討論系統的分析與設計：「結構化技術」與「物件導向技術」，各別使用5章與6章的篇幅說明。結構化技術是將資料與流程分開考慮，而物件導向技術則是將資料與流程封裝成物件處理。除了這兩種技術外，還有其他如元件導向、服務導向等新技術。

整本書的架構如下：

第01章資訊系統開發概論
第02章資訊系統開發模式
第03章需求分析
第04章 結構化技術
第05章結構化分析與設計－流程塑模
第06章結構化企業流程塑模個案
第07章結構化分析與設計－資料塑模
第08章結構化企業資料塑模個案
第09章 物件導向技術
第10章使用個案塑模
第11章物件互動行為塑模
第12章使用者介面塑模──結構與狀態
第13章物件資料結構塑模
第14章系統元件與結構塑模
第15章結論與展望

若想對系統分析與設計有所認識，我想這是一本入門的參考書，淺顯易懂。另外，建議搭配一本軟體工程的相關書籍一起閱讀，對於資訊系統開發將會有更深入的認識。

###

延伸閱讀
 Unified Modeling Language 統一塑模語言

Golden Rules for Writing E-mails 英文書信寫作

2011-11-08T21:02:00.000+08:00

介紹一本實用的英文書信寫作書籍，這是「LiveABC互動英語教學集團」出版發行的書本和互動光碟，書中包含35篇主題的書信，內容除了講述撰寫英文書信的格式外，也詳述200個左右的常見錯誤說明，推薦大家這本書非常實用。

吳嘉玲，E-mail寫作不出錯(Golden Rules for Writing E-mails)全新增修版，台北：希伯崙公司，2008。

以下記錄電子郵件與一般書信的書寫格式重點。

一封電子郵件(e-mail)通常有9個項目：

From：寄件人
To：收件人
Cc：副本，是carbon copy的縮寫
Bcc：密件副本，是blind carbon copy的縮寫
Subject：信件主旨
Attachment：附加檔
Salutation：稱謂語
Body：信文
Closing Segment：結語
Complimentary Close：結尾敬語

一般書信(非電子郵件)包含9個項目，由信件上至下依序為：

Letterhead：信頭
Date：日期
Addressee：收信人
Address：收信人地址
Salutation：稱謂語
Subject：主旨
Body：信文
Closing Segment：結語
Complimentary Close：結尾敬語
Signature：簽名

另外，商用書信的三大格式分別是：

Full-block Form齊頭式
Semi-block Form半齊頭式
Indented Form縮格式

###

Beginning Programming 學習程式語言

2011-11-02T19:18:00.000+08:00

如何學習一個程式語言？這個問題學校教育似乎沒有好好告訴我們青年學子們。以我自己的經驗來看，學校的程式語言課程大部分都是講述程式語法的使用，我認為這是錯誤的方法，教育程式設計的正確方式是：傳授程式設計的核心概念。

以下分享自己在程式設計學習之路的心得，期望能幫助正在學習程式語言的青年學子們。

首先，我們必須知道程式語言(Programming Language)的意義為何？我認為程式語言是「幫助人類完成處理資料的目的」，重點在於「處理」與「資料」兩個部分。

開始學習之前，根據「工欲善其事，必先利其器」原則，必須先準備好開發工具，不過這又關係到程式語言的種類。個人認為選用自由軟體的開發工具作為學習較好，例如Eclipse或NetBeans，也可以使用微軟的Visual Studio的Express版本。重點不在於開發工具和語言種類，這些都只是工具，學習程式設計在於程式設計本身！

開發工具有了，第一步先了解「資料」這個部分，你必須先認識資料型態，常見的資料型態有：整數、浮點數、字元、字串等，這些屬於基本資料型態。由這些基本資料型態組合成的資料型態有：陣列、結構、類別等，稱為複合資料型別。學習的核心概念在於認識與瞭解每種資料型態的特性，什麼時候適合採用哪種資料型態，更進階學習則屬於「資料結構(Data Structures)」的領域了。

第二步是了解「處理」這個部分，程式處理資料不外乎兩種模式：重複與判斷。重複(或稱反覆)在程式語言中是迴圈，人類利用迴圈自動化處理重複的工作，一般來說有：for迴圈、while迴圈、do-while迴圈、foreach-in迴圈等，用於處理相同的動作。判斷(或稱選擇)在資料處理中依據資料狀態做不同的動作，通常有：if-else判斷、switch-case判斷等。重複與判斷互相搭配使用，已經足夠幫助我們完成處理資料的目的，同樣的，學習的核心概念在於認識與瞭解每種重複與判斷的特性。更進階學習則屬於「演算法(Algorithm)」的領域了。

再來，更進階一些的就是函式(副程式)的觀念，程式寫多的會發現程式碼重複，因此，你可以利用函式將常用的功能包裝起來成為函式，減少後續修改維護的麻煩。更進階的學習則是使用程式庫(library)與開發程式庫。

資料型態、重複與判斷這三類程式語言的基礎知識，如果可以掌握好，我相信你已經有程式開發的基礎能力。至於其他像是物件導向(Object-Oriented, OO)這個部分，我認為這是屬於更進階的程式設計學習，是讓你成為真正的「程式設計師」。

物件導向其實是程式語言的一部分(對於物件導向的語言來說，目前流行的程式語言時之八九都是OO)，很難抽離去獨立學習程式語言。因此我建議剛開始學習程式語言，重心放在資料型態、重複與判斷這三類程式語言的基礎知識，物件導向若不明白以後再學習，千萬不要因為不懂物件而受挫，學習程式語言真的是很有趣的一件事情！

###

延伸閱讀
Web Programming Language網頁程式語言

Server Architectures 伺服器系統架構

2011-10-27T00:16:00.000+08:00

伺服器(Server)在現在的網路世代非常重要，所有服務都必須由伺服器提供，不過伺服器的組成結構是什麼，對網路使用者而言可說是虛無飄渺像一朵雲！這次介紹這本「Server Architectures」，提供技術決策者(technology decision-maker)與系統架構師(system architect)認識伺服器的組成架構，如此在爾後的系統規劃上能有更高層次的視野。

這本書以目前來看稍微舊了一些，第一次在2000年以法文發行，我買的這本書是2005年以英文版發行，並加入一些新的內容(2002至2004的技術背景)，也許在今日科技技術快速變遷時代，部分的內容已成為過去式，但是其中伺服器架構的核心概念仍具有學習價值！

René J. Chevance, "Server Architectures: Multiprocessors, Clusters, Parallel Systems, Web Servers, Storage Solutions", Elsevier Digital Press, 2005.

這本書分成兩個部分，主要有三個主題，先介紹伺服器的組成硬體(CPU, Memory, I/O)與軟體，接著介紹伺服器系統的架構，最後說明選擇架構的效能評估標準。整本書的目錄如下：

Part 1: Architectural Options and Technology Evolution

1 Processors and Memory
2 I/O
3 Evolution of Software Technology

Part 2: Systems Architecture Options

4 Symmetrical (Tightly-Coupled) Multiprocessors
5 Clusters and Massively Parallel Machines
6 Data Storage
7 Systems Performance and Estimation Techniques
8 DBMS and Server Architectures
9 The Terminology of High-Availability Systems
10 Hardware and software Solutions for High Availability
11 Selection Criteria and Total Cost of Ownership
12 Conclusions and Prospects

認識伺服器架構之前，必須對更高層次的系統架構(Systems Architecture)有基礎的認識，書中將系統區分成兩類，注意這是以多處理器(multiprocessor)的角度來看：

Tightly-coupled，或稱為Symmetrical Multiprocessor (SMP)
在一台主機上有多個處理器，只有一個作業系統，各個處理器共享所有的系統資源(Memory與I/O裝置)。所謂Symmetrical是指每個處理器在作業系統中都是具有相同能力的意思。
Loosely-coupled
由多個獨立主機互相連接的系統，每個主機有各自獨立的資源(處理器、Memory與I/O裝置)與作業系統，系統中的每個主機稱為節點(node)，各個主機之間通常沒有共享記憶體資源。代表的系統架構有：叢集(cluster)與MPP(Massively Parallel Processing)，也是分散式系統(distributed system)的概念之一。

有了這些基礎認識之下，伺服器通常會有容量的議題存在，因而需要擴充性(scalability)。伺服器的擴充有兩個維度：

Scale-up，或稱vertical growth。
在一個主機上增加資源，增加處理器數量、記憶體、儲存容量。
Scale-out，或稱horizontal growth。
增加系統中的節點數量，進而擴充整體系統的容量或效能。

上述只是稍微講述伺服器架構的基本觀念，還有很多知識需要進行研讀，後續再撰寫文章介紹。
###

Drive: The Surprising Truth About What Motivates Us 動機

2011-10-22T10:26:00.002+08:00

這本書是討論動機的真相，如同原文書名「Drive: The Surprising Truth About What Motivates Us」，動機是行為的驅動力。研究指出，過去認為的動機論(原理、理論)與真相之間有著錯誤，導致「激勵制度」建築在有問題的動機論之上，進而產生一些深信不疑的觀念。

丹尼爾‧品克(Daniel H.Pink)著，席玉蘋譯，「動機，單純的力量(Drive: The Surprising Truth About What Motivates Us)」，台北：大塊文化，2010。

科學研究指出動機有三種驅力：

生理上的驅力：食物、性。
外在環境的驅力(外在誘因)：獎勵懲罰制度(胡蘿蔔和棍子)。
工作的績效表現(內在激勵)：滿足感、成就感、樂趣。

不過在1940年代，科學界普遍認為只有前兩種驅力存在(雙驅力理論)，所幸有教授哈利‧哈洛(Harry F. Harlow)與研究生愛德華‧戴西(Edward Deci)這兩位先鋒的研究，動機的第三種驅力逐漸受到重視，讓我們對於人類行為有了更正確真實的解釋。

激勵1.0：人類是生理動物，努力是為了求生。
激勵2.0：人類除了生理驅力，也會對環境中的獎懲做出回應。
激勵2.1：加入道格拉斯‧麥葛瑞格(Douglas McGregor)的學說，主張人類有更高層次的驅力。
激勵3.0：從「I型行為」做基礎，強調內在激勵的第三驅力。

作者提出「I型」與「X型」兩種行為的觀點，「I型」象徵內在(Instrinsic)，指內在驅力大於外在誘因的行為，而「X型」象徵外在(Extrinsic)，指外在誘因大於內在驅力的行為。作者認為「I型行為」的優點比「X型行為」的優點要多，建議我們朝著「I型行為」學習。

I型行為有三大要素：自主(Autonomy)、專精(Mastery)、目的(Purpose)。當這三個要素具備的時候，內在驅力將大於外在驅力，因而產生「I型行為」。

整本書從動機論切入，探究目前企業的激勵制度，作者認為目前工作型態的轉變，已由過去強調利益目標的改變為以內在驅力為導向的工作內容(例如創新、目的感...)，激勵制度已經不適用於這個時代，我們必須塑造適合「I型行為」的環境。

###

Linux Filesystem Hierarchy 系統架構與目錄

2011-10-17T22:29:00.001+08:00

用過微軟Windows系統之後，看到Linux的檔案系統(File System)還真是不習慣，兩者之間有些差異，我認為這是作業系統的設計觀點不同導致，真正的答案還需要蒐集求證才會知道。

有關Linux檔案系統的書籍，目前大概只有邱世華先生(Juergen S.H. Chiu)撰寫的這一本，很可惜的是已經絕版，強烈希望再版並建議添加新內容，這是難得一見的好書。作者提到一個重點：「基本上，Linux的精神就是要將所有作業系統中的資訊，全部都變成檔案，以方便管理。」由此可見檔案系統的重要性！了解檔案與目錄的架構有助於我們認識Linux作業系統。

邱世華，Linux系統架構與目錄之解析，台北：悅知文化，2008。

由於Linux是自由開放原始碼的作業系統，各廠商推出不同的Linux版本有所差異，因此造成系統檔案架構而有所不同，所幸差異不大，加上目前已經有Filesystem Hierarchy Standard (FHS)的標準規範Linux檔案架構，學習起來不會太困難(因為有參考資料)。

目錄中最為重要的就是根目錄(root directory)，這是檔案系統的開始位置，在「Linux系統架構與目錄之解析」也有提到根目錄是怎麼產生的由來，除了告訴我們是什麼，還讓我們知道為什麼。

重要的目錄還有虛擬檔案系統(Virtual File System, VFS)的部分，所謂VFS是指不存在於實體的檔案與目錄(不佔磁碟空間)，存在的目的是為了操作作業系統，記得前述「所有作業系統中的資訊全部都變成檔案」的觀念，VFS就是用來做這件事情。重要的目錄有：/dev、/proc與/sys三個目錄，分別代表：裝置(device)資訊、行程(process)資訊與系統(system)資訊。

作業系統執行檔的目錄則是：/bin、/sbin、/usr/bin與/usr/sbin四個目錄之中，usr目錄的檔案通常是非必要性，大多屬使用者安裝的共用指令檔案，注意到usr不是user的縮寫，而是Unix Software Resource的縮寫，其中sbin目錄則用於系統管理之用(system binary)，這裡類似於Windows中的C:\WINDOWS\system32目錄的功能。此外，使用者安裝的應用程式，則是位於/usr/local/bin目錄中，類似Windows中的C:\Program Files目錄的功能。

有關軟體「設定」的目錄是：/etc目錄，包含各類程式服務執行的設定參數，檔案目錄的數量相當多，所以才稱為「etcetera directory」。

感謝邱世華先生，您序中提到：「重點就在要做的事情貢獻大不大，是不是自己要的，這是唯一重要的事，只要做的事是對的，就一定會有人欣賞。」我認為世界就是需要有這樣的人、做這樣的事！

Delight Press
請再版，好嗎！

###

Bourne Again SHell 命令列介面

2011-10-13T07:44:00.001+08:00

最近重新開始學習Linux的Command-line Interface (CLI)使用操作，過去使用Linux的經驗是Mandriva或Fedora，這次選擇的則是Ubuntu 11.04桌面版的作業系統，因為安裝方便容易。

一般來說，Linux上的CLI都是bash的「殼(shell)」，bash全名是Bourne Again SHell，bash的前身是Bourne Shell(通稱為sh)，除了bash與sh之外，還有其他shell提供使用者操作作業系統。

相關知識可以在GNU Bash網站取得：http://www.gnu.org/software/bash/，或是參閱「Linux Shell程式設計實務」一書，這本書偏向Linux管理的程式撰寫，不過從基礎到進階的操作都有提及到，我推薦這本書給大家。

臥龍小三，Linux Shell程式設計實務，台北：精誠資訊：2009。

查詢Linux用的Shell是哪一種的指令：echo $SHELL
Ubuntu 11.04桌面版是bash，執行檔是/bin/bash

查詢Bash Shell的版本(從Shell變數的值可以知道)：echo $BASH_VERSION
Ubuntu 11.04桌面版的bash是4.2.8(1)-release版本

查詢Bash Shell內建的命令有哪些：help
或是參考http://www.gnu.org/software/bash/manual/html_node/Builtin-Index.html#Builtin-Index

注意，Bash Shell的命令是區分大小寫(case-sensitivity)！。換句話說，Linux的檔案系統是區分大小寫的(命令是對應到執行檔)，不同於Windows檔案系統是不區分大小寫。

除了內建命令之外，還有位於/bin路徑與$PATH路徑之下的指令，這些路徑下的執行檔就相當多了，也包含自己安裝的應用程式指令。CLI的操作其實不難，熟悉後就得心應手了。
###

Stay hungry stay foolish 求知若渴，虛心若愚

2011-09-01T00:54:00.002+08:00

神一樣的傳奇。「賈伯斯本身就是一個傳奇，比任何虛構的小說都更精彩。」李開復說。

感謝李開復先生，策劃這本書的誕生，讓我們可以閱讀這本賈伯斯傳記，故事精彩而且好讀，讀完之後我更堅信自己的想法，一定做自己想要做的事情、喜歡的事情、擅長的事情，追尋「求知若渴，虛心若愚」的精神。

本書共分9章，從賈伯斯回歸蘋果的那天開始說起，之後從蘋果創立的過程開始敘述，直到最近2011年6月發生的事情，整個故事其實都是圍繞著賈伯斯與蘋果的人事物，也提及一些重要人物：Jonathan Ive(產品設計), Jon Rubinstein(硬體工程), Avadis Tevanian(作業系統軟體)，這些A+的人讓Apple更為傳奇。書中收錄一些賈伯斯語錄，相當具有「警世」作用。

這是一本值得推薦的書，推薦給想要改變世界的人。

王詠剛、周虹，世界跟著他的想像走：賈伯斯傳奇，台北：天下遠見，2011。

賈伯斯語錄(部分)：

我非常幸運，因為我在很早的時候就找到了我真愛的東西。
有時，生活會拿起一塊磚頭在你腦袋上猛拍一下。不要失去信心。我們清楚，我之所以能夠一直堅持，唯一的理由是，我熱愛我所做的事情。
我們沒有機會去做很多事情，而且，每一件事都要做到完美。因為，這就是生命。生命是短暫的，你會死去，不是嗎？既然我們選擇用我們的生命去做這件事，那最好做到完美，最好值回生命的價值。
有時候人們會擔心自己將會失去某些東西。避開這個念頭的最好辦法是，記住自己將要死去。你已經了無牽掛，沒有理由不去追隨自己的心。
你在憧憬未來時不可能串聯起以前累積的點點滴滴，你只能再回顧過去時這麼做。所以你必須相信，當前累積的點點滴滴，會在未來的某一天串聯起來。你必須相信某些東西─你的勇氣、目的、生命、因緣等等─相信它們會串聯起你的生命。這會讓你更有自信追隨自己的心，甚至指引你不走尋常路，使你的生命與眾不同。
時間有限，不要將時間浪費在重複他人的生活上。

###

Are Your Lights On 你想通了嗎

2011-08-05T01:20:00.002+08:00

介紹解決問題的經典著作，這本書是「真正的問題是什麼？你想通了嗎？」原著書名：Are Your Lights On? How to Figure Out What the Problem RELLY Is，於1990年首次出版，中文版由城邦出版集團於2005年第一次發行。

唐納德‧高斯(Donald C. Gause)、傑拉爾德‧溫伯格(Gerald M. Weinberg)合著；蘇耿弘譯，「真正的問題是什麼？你想通了嗎？：解決問題之前，你該思考的6件事」(第二版)，台北：經濟新潮社，2010。

整本書如同書名所說：解決問題之前，你該思考的6件事。這6件事分別是書中的6章，總共分成20篇。作者用一些故事說明解決問題的觀念，淺顯易懂，一些觀念甚至有違背我們的常識，但卻是十分有道理，不愧是問題解決的經典著作。

內容架構如下所述：

第一章，問題是什麼？
- 誰有問題？你認為問題的本質是什麼？
- 問題往往來自於期望和感受之間出現了落差。
第二章，這是什麼問題？
- 不要把別人解決問題的方法，當成是問題的定義，尤其是當解決方案是由你自己提出的時候。
- 如果你很輕易就解決了別人的問題，那麼，他們將不會相信你解決了他們真正的問題。
- 你永遠無法確定自己是否已經取得了正確的問題定義，即使問題已經被解決了。
- 你永遠無法確定自己是否有了一個正確的定義，但絕不要放棄去試著追尋一個。
第三章，真正的問題是什麼？
- 每一個解決方案都是下一個問題的根源。
- 某些問題最難處理的地方就是去意識到它們的存在。
- 如果以你對問題的了解，你想不出至少三個可能出錯的地方，那麼，你就不是真的理解這個問題。
- 每個新觀點都會引發一個新的不合身(misfit)。
- 一旦你用文字來描述一個問題，請不斷調整你的遣詞用句，直到它進到每一個人的腦袋裡為止。
第四章，這是誰的問題？
- 不要急著幫別人解決問題，當他們自己就可以處理得很好的時候。
- 如果這是他們的問題，就讓它成為是他們的問題。
- 如果一個人是因為職位而被迫處理和他無關的問題時，你要做的就是─讓他的問題也產生關係。
第五章，問題是從哪來的？
- 問題的起源通常和你自己大有關係。
- 在這世界上有兩種人，一種人會做事，另一種人則是找事情給別人做。
- 問題是誰出的？他的企圖是什麼？
第六章，我們真的想解決它嗎？
- 不管看起來如何，人們其實很少真正知道他們需要的是什麼，直到你給了他們要求的那些東西。
- 到了最後的分析階段，其實沒有多少人是真的希望他們的問題被解決。
- 我們永遠沒有足夠時間可以把事情做對，不過，我們總有足夠時間可以把事情重做一遍。
- 我們永遠沒有足夠時間思考自己是否需要它，不過，我們總有足夠的時間可以後悔。
- 魚，總是最後一個看到水的。

我們每天生活都會遇到問題，而書中的觀念讓我們可以正確地解決問題，這是一本值得一讀再讀的經典，推薦。

###

Taiwan Software 台灣軟體

2011-08-01T21:38:00.004+08:00

談談台灣軟體的未來，記錄自己在軟體開發上的心得感想。

台灣的大企業仍以代工製造為主，這些高階管理人員依舊留著代工製造的血，然而我認為軟體開發不是製造業，軟體開發是服務業，因此若再以製造思維引領軟體開發，必定是行不通的！在工作上常聽到「軟體改一改很快嘛！」軟體開發人員一聽到就懂了。

「The Mythical Man-Month(人月神話)」和「Peopleware(人件)」這兩本經典說明軟體開發必須要有的觀念，軟體的本質是複雜性(Complexity)、配合性(Conformity)、易變性(Changeability)、隱匿性(Invisibility)，而軟體開發是腦力工作而不是製造業的勞力工作，太多觀念都與製造代工不一樣。

台灣的未來應該是以軟體產業與文化產業為導向發展。台灣的環境資源有限，不像大陸型國家什麼資源都有，不過台灣的地理位置造就我們的文化相當多元豐富，台灣人接受新觀念很快，更具備靈活創新的特質，教育程度的質量也很高，這些都是我們的優勢啊！「人多半只看到自己所沒有的，卻忘了自己所擁有的。」我認為台灣發展軟體和文化是最適合不過了。

若從IT資訊科技產業來看台灣的軟體，台灣微軟王森先生在「Visual C# 2010程式設計經典」推薦序提到：(曹祖聖、蔡文龍，Visual C# 2010程式設計經典，台北：碁峰資訊，2010。)

『微軟把IT技術人員大致上區分IT-Pro(系統管理專家)與Developer(軟體開發人員)這兩類型的專業人士，在國外因為人口眾多，所以這兩種專家通常各有專精，雖然會重疊，但是比例不高；

到了台灣，卻因為IT技術人員常常要身兼數職(從硬體採購→網路架設→伺服器安裝設定→軟體開發→系統管理，全部統包)因此微軟既有的分眾方式，到了台灣變成有了一個很大的模糊地帶......』

的確，台灣人是很「強」的！軟體開發人員通常需要做系統管理專家的工作，只要跟電腦有關的工作都要處理，可能也和台灣都是中小企業有關吧！

###

Component Object Model 元件物件模型

2011-07-07T01:06:00.002+08:00

最近重新研究元件物件模型(Component Object Model, COM)，再次閱讀MSDN上的文件，並且在MSDN上面加上解釋，不過貼了一陣子之後卻被取消張貼，我想可能是我在英文版MSDN貼上中文的關係吧！現在趕緊將內容編寫在自己的部落格中記錄下來，避免閱讀心得遺失。

什麼是Component Object Model (簡稱COM)？中文微軟翻譯成「元件物件模型」，COM是一個標準(standard)，定義元件要長什麼樣子，以及元件跟元件之間要如何互動。COM真的很重要！COM是OLE與ActiveX兩個的技術基礎。除了MSDN的資料之外，有關COM的資料相當稀有，參考書籍大概只有Dale Rogerson著的「Inside COM」，中文書名是「完全剖析COM」(黃昕暐編譯，徐銘志校閱)，不過都已經絕版，以後大概沒有人會寫COM了！http://www.microsoft.com/mspress/taiwan/Pages/c0089_1061.htm

有關COM的中文資料相當少，書籍更少，只能參考MSDN的說明。COM是一個「標準(Standard)」，規範二進制機器碼的元件要如何實現，不要把COM想得很困難，唯一需要做的就是花時間研讀這些文件，建議先從「COM Fundamentals/Guide/The Component Object Model」開始閱讀。在Visual Studio中開發COM的話，則是使用「ATL專案」類型。

一般來說，軟體的物件(想像成一個資料結構，這裡不是特別指OOP的物件)會包含資料(data)與函式(function)兩個部分。COM規範存取資料只能透過函式，所以說COM元件都是一堆函式。COM標準將一組函式稱為「介面(Interface)」，介面裡的函式COM稱之為「方法(method)」，注意這裡的介面與方法和物件導向程式的定義不相同，觀念不要混淆了。

這文件寫那麼多，重點只有一個觀念，介面(interface)與介面實作(interface implementation)是不相關的，兩者是獨立的兩件事情。COM標準只有定義介面，介面是一堆方法(method)，也就是函式原型(function prototype)，但COM標準沒有規定方法要如何實做，實作部分留給程式設計師去做。介面定義是一種協議(contract)，因此各個物件與應用程式就知道如何去使用COM元件，這就是COM的精神。注意介面實作不一定要實現，但是介面一定要存在於元件中，換句話說，函式中的程式碼可以是空的，不做任何事情。

COM元件中的資料處理只能透過「介面(interface)」存取，COM所謂的介面指的是一組預先定義的函式原型，另一個角度來說，COM的標準就是只有定義介面(不只一個，參閱COM的Reference)。而所謂「實作(implement)」則是表示實做介面，撰寫介面所定義函式的程式碼。

我們已經知道COM是個標準，COM是定義一群介面。那要如何實現介面？介面的實作是用：指向函式表(function table)的指標，稱為介面指標(interface pointer)，函式表是一個函式指標的陣列，陣列中的函式指標都是介面所定義的方法。注意，每個介面都有一個識別碼，COM稱為IID(unique interface identifier)，是一種GUID(globally unique identifier )的資料類型，我們因此可以透過IID取得COM元件的介面。

IUnknown介面是COM標準中最重要的一個介面，所有介面都繼承這個IUnknown介面，換句話說，COM 元件一定具有IUnknown介面，我們一定可以呼叫這三個方法：QueryInterface、AddRef與Release。

使用COM標準實做出來的是什麼？答案是動態連結程式庫(DLL)或可執行檔(EXE)，因為COM是「二進制的標準(binary standard)」，直接定義最底層執行碼的標準。注意，COM不是要與DLL競爭或取代，而是將DLL運用地更好的一種方式，使用DLL可以解決的，若是換成使用COM的方式會處理地更好。

Visual C++在COM介面的實作是：宣告一個類別當作COM的介面(interface)的實作，在這個「介面的類別」中宣告虛擬函式(virtual function)當作COM方法(method)的實作。

COM這個標準討論的都是介面(interface)，都是介面啊！介面！介面！一定要了解什麼是介面。這些介面當中，又以IUnknown介面最為重要，而且IUnknown介面的QueryInterface方法幾乎定義了整個COM元件。

這裡的重點是「介面繼承(Interface Inheritance)」的觀念，COM的繼承觀念不同於物件導向程式設計的繼承。介面繼承是指重複使用「函式原型」(COM中稱為方法)，不是程式碼的重複使用，在COM的標準下最重要的介面是IUnknown介面，每個COM標準下的介面都會繼承IUnknown介面。IUnknown介面定義3個重要的方法，分別是QueryInterface、AddRef與Release方法，其中QueryInterface是用來取得COM元件中其他的介面，而AddRef與Release則是用來管理COM元件的生命週期。

COM標準除了定義介面和互動之外，COM也有提供一個程式庫(library)，程式庫提供操作COM元件的常用動作給開發者使用，這裡的function就是COM程式庫提供的功能，動態連結的程式庫位於C:\Windows\System32\Ole32.dll之下，靜態連結的程式庫則位於C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\Ole32.Lib，標頭檔是C:\Program Files\Microsoft SDKs\Windows\v7.1\Include\ObjBase.h，路徑是對於Microsoft Windows SDK for Windows 7 and .NET Framework 4而言。

登錄資料庫(Registry)是Windows記錄有關軟硬體與使用者的資訊，應用程式可以從Registry加入或讀取資訊。在Registry中會包含所有已經安裝在系統的COM元件資訊，應用程式利用CLSID或ProgID的機碼取得DLL或EXE所在的路徑。

COM標準是規範元件的介面與互動方式。使用COM標準做出來的COM物件，在Windows中是利用CLSID機碼識別各物件，一個物件會有多個介面，而介面的識別則是利用IID機碼。

相當於Dll中DllMain函式的用途。當呼叫CoCreateInstance或CoGetClassObject建立物件時，透過COM程式庫會呼叫DllGetClassObject，概念像是COM元件的Entry Point。細部動作則是透過IClassFactory介面的CreateInstance方法建立物件。

呼叫CoCreateInstance函式的動作是：由COM程式庫去呼叫DLL中的DllGetClassObject函式。

呼叫CoFreeUnusedLibraries函式的動作是：由COM程式庫去呼叫DLL中的DllCanUnloadNow函式。

COM物件再利用的方法採用：包含(containment/delegation)與聚合(aggregation)兩種方式。

COM的安全性是基於Windows與底層RPC的安全機制，透過驗證(authentication)與授權(authorization)方式取得，驗證是判斷呼叫者的身分，而授權是指判斷呼叫者是否可以去執行某個函式。在COM標準中有兩種安全性形式：活動安全性(activation security)與呼叫安全性(call security)，活動安全性是指客戶端是否可以進入伺服端，而呼叫安全性則指進入伺服端之後，判斷是否可以存取伺服端的物件。

「COM is still valuable」對，同意COM依舊有價值。COM元件是本身就是二進制的執行碼，所以執行效能很高，微軟目前以.NET Framework為主要開發平台，使用Assembly組件，.NET Framework不須管控記憶體，加上.NET Framework的元件多，進而提高生產力，代價就是效能差了一點！兩者的優劣在開發使用上必須取捨(tradeoff)。學習COM，同樣需要去了解ATL，COM與ATL就像「雞生蛋，蛋生雞」的關聯性，建議先從COM切入，再去了解ATL，反覆咀嚼才可破。

使用COM程式庫之前，必須呼叫CoInitialize函式進行初始化。使用完成，必須呼叫CoUninitialize函式關閉COM程式庫以釋放使用的DLL。使用記得#include "objbase.h"(如果是用Visual Studio可以不需要)，接著呼叫「::CoInitialize(NULL);」就可以了。

使用元件的先決條件：(參考「完全剖析COM」一書)

元件必須是以動態連結的方式加入應用程式
元件必須隱藏(或封裝)實作的細節。

元件必須符合的限制：(參考「完全剖析COM」一書)

元件必須隱藏實作時所使用的程式語言
元件必須以二進位格式存在
元件的升級不能造成目前使用者的困擾
元件必須具有網路通透性。

要把COM搞懂，概念與實作都不困難，但是需要花時間閱讀文件。
###

Infrastructure as a Service 基礎架構即服務

2011-06-17T22:25:00.001+08:00

基礎架構即服務(Infrastructure as a Service, IaaS)是屬於雲端運算架構的最底層(稱為「基礎設施層」)，幾乎是把底層的硬體資源提供給用戶，包含運算資源、儲存資源與網路資源，IaaS是針對軟體開發人員、軟體開發商的用戶提供服務。

想要實現IaaS的技術是虛擬化(Virtualization)，將雲端上面的伺服器虛擬成一個個虛擬機器(Virtual Machine)提供給用戶，於是用戶就會有他自己的運算資源、儲存資源與網路資源。用戶將會在他自己的虛擬機器上安裝作業系統，這不就變成一個虛擬主機了！接著可以建構自己的平台與應用程式。

基礎架構必須具備的功能有：

資源抽象
將實際硬體抽象化成為一個虛擬裝置，對上層架構提供硬體資源。
資源監控
抽象化的硬體資源有了，必須可以監控量測，這是為了管理。
負載管理
利用資源監控所獲得的資訊，對各個硬體資源進行負載管理，在校與成本之間取得平衡。
資料管理
雲端的資料不是存放於單一實體裝置，資料的所有特性必須可被管理。
資源部署
用戶所需的資源必須由系統提供，必須可以自動化部署給用戶。
安全管理
這是系統的基本要求，沒有人會去使用一個不安全的雲端。
計費管理
雲端的商業模式採用按量計費，利用資源監控可以得到計費所需的使用量資訊。

上述每項功能，如果真的要動手實作完成，要做的事情可是非常非常多的，不過這已經是雲端運算架構當中最基礎的功課。如果要完成基礎架構上面的平台層，事情可是多更多，因為平台的工作=平台層+基礎架構層。

###

延伸閱讀
Cloud Computing Strategy 雲端運算策略

Love Catch 22 愛情的22個關鍵詞

2011-06-10T11:01:00.001+08:00

愛情的22個關鍵詞在一開始的序用了「善財與悅意」的愛情故事開場，而善財就是釋迦牟尼佛，透過動人的愛情故事，祂告訴我們在人世間，透過愛情的修練，人的生命層次可以提高的。序的最後面寫著：

愛情，在生命中的確佔有一個極特殊也極重要的位置。
對於每個人來說，都有一個需要面對的愛情功課。而我們在這門功課上用功如何，拿到了什麼樣的成績，往往攸關著我們整個生命品質的層次。
因此，我們有必要了解有關愛情的關鍵詞。
這些關鍵詞影響的不只是愛情，也影響著我們的生命。

這已經說明洪啟嵩先生寫這本書的意義，這本書是獻給「對不圓滿的現實想要超越；及對圓滿的愛情心生嚮往的人。」透過22章(關鍵詞)的內容，對於愛情這們功課我們獲得更深的瞭解，洪啟嵩先生透過文字與繪畫的方式傳達，真是以心傳心的體悟感動。

洪啟嵩，愛情的22個關鍵詞，台北：網路與書，2005。

書中的22個關鍵詞如下：

「自愛」：愛情的第一個學分。
「健康」：健康，可以使愛的能力順暢自然。
「專注」：每天把心思自然地專注在心愛的人身上。
「佔有」：「佔有」是「分裂」的開始。
「嫉妒」：嫉妒是一種不知道如何處理愛的愛。
「理由」：如果愛情沒有理由的發生，也就會沒理由的消失。
「單戀」：這讓我們真實地面對愛情的修鍊。
「永恆之一」：「永恆」，可能是令人喘不過氣的壓力。
「永恆之二」：愛情不應永恆不變，而應越變越好。
「忍耐」：心生忍耐，是在傷害自己的生命。
「寬容」：寬容，不是忍耐，也不是縱容。
「負擔」：一個總是披著「責任」外衣出現的傷害。
「恐懼」：想要緊緊擁住的同時，我們正在失去。
「犧牲」：這是一種與愛情無關的苦行。
「精進」：愛情的勇氣與行動力。
「業障」：愛情中有「業」，但不必然是「業障」。
「前世」：一場美麗的夢，不能作為愛情的必然保證。
「網路」：不必以為網路是虛幻的，人生才是真實的。
「劈腿」：劈腿，需要具備三個條件。
「一夜情」：愛情的逃亡。
「同性戀」：愛情的關鍵詞是沒有性向之分的。
「分手」：這是愛情最重要的一個學分。

推薦給想修習愛情學分的人。

###

Education 教育應該不一樣

2011-06-08T16:11:00.003+08:00

「教育必須是為學生照亮未來的探照燈，而非重複過去的後照鏡。教育不應是倒滿一壺水，而是點亮一根蠟燭。」

這段話是嚴長壽先生在「教育應該不一樣」一書中所提的，說的正確，教育本來就應該是這樣。這本書點出目前台灣教育各個方面的錯誤，這些錯誤是「台灣教育最不願面對的真相」，嚴長壽先生透過這本書試著改變台灣教育的現況，我聽到了！而我現在唯一能做的就是盡我所能將這些觀念告訴更多人，請大家一起告訴更多人，如此才有機會改變。

曾經，我們都是深受其害的學生，特別是我這群7年級世代，我記得學生時代的「教改」(就是這一代開始當白老鼠，他X的...)，沒有發言權的學生在「前無古人，後無來者」的情形之下，面對所謂「教改」不知所措、不知所云！7年級這個世代體會最深、經歷的改變最大，我相信「改變會從7年級世代開始進行」。

嚴長壽，教育應該不一樣，台北：天下遠見，2011。

這本書總共7章，前3章分別從家長、老師與(青年)學生3個「共錯結構」探討，而第4、5章則從教育制度上討論，第6章是提高到每個人可以做的方法，最後第7章總結教育應該不一樣。以下是整本書的大綱：

醒醒吧！家長
不是每個人都要當國家棟梁，社會更需要腳踏實地、堅守岡位、熱愛工作的螺絲釘。
老師可以更勇敢
教育不應是倒滿一壺水，而是點亮一根蠟燭。
年輕朋友請走一條追尋自我天賦之路
只有專注和熱情，生命火光終會帶領你穿越人生迷霧。
只有創意和實力才能面對高學歷通膨時代
教育應該是讓學生關懷自己以外的人事物，激發對社會、對世界的熱忱。
技職教育的黑洞
教育必須是為學生照亮未來的探照燈，而非重複過去的後照鏡。
我們都是選民，更是公民
監督教育政策事責任，也是權利。
教育應該不一樣
台灣過去的文化優勢，必須轉變成未來的台灣核心教育元素。

推薦這本書給台灣的每一個人，台灣教育的未來必須靠我們一起改變，如同嚴長壽先生他明知道未必有所改變，但他帶著天生的社會使命感，他仍選擇再做一次「豬頭」。不論我們是否能夠改變什麼，但只要現在開始行動(不能只說不做)，就一定有變好的那一天。

###

Certainty 確信

2011-06-07T17:17:00.005+08:00

紀錄並分享生活心得，我與Jasper的對話錄。

Jasper:

不確定(uncertainty)就像沙漠中"找水"，當你水壺剩一半時，就有點小緊張了，眼見水壺裡的水越來越少時，就會開始懷疑，"方向"是否正確，"工具"是否齊全，....等，此時，如何以"聖嚴法師之詞"化解心中的不安?

倘若是遇到問題，或許"聖嚴法師之詞"可化解心中的"煩躁"，但"不確定(找水)"不是個問題，是連問題(方向)在哪都找不到!!

Me:

「找水」
沙漠中只有你一個人，你只有手中的行囊，儘管內心的煎熬無比難受，腳下炙熱的沙礫與頭上的太陽，緊張懷疑並不能幫助你什麼，大概只會讓你猶豫不決的前進。你得持續找水，沒有退路，別無他法。

「方向」
已經很確定！就是找到水，持續前進。

Jasper:

你如何確定"水在前方"，不是左前，不是右前，不是偏左，不是偏右，不是你腳下，不是你後面??

說不定"止渴"不是只有"找水"，還有其他方法!!

不確定 -- 是指都不知道，所以不適用"聖嚴解法"!!

Me:

確定你確定的，相信你相信的。
剩下的：不確定、不相信的，就放下吧！

Jasper:(這段經典...一定會在歷史上留下)

"剩下的：不確定、不相信的，就放下吧！" 等死就對了!!
往前走，有水(活)，沒水(死)，有沒有水不知道，走就對了!!

有此阿Q精神我只認識一位叫"阿甘"的!況且"阿甘"並不是找水，而是一直往前走居然遇到水，才發現"水"是不錯的東西!
先要"無目的"的往前走，才可能一直往前走
若"有目的"的往前走，應須確認"目的地"在前方再往前走!!

Me:

不然要怎樣...

有沒有水不是自己可以控制的，考試考不考得上也多半不是自己可以控制的，
只能「做自己能做的，改變自己能改變的」，剩下的就放下讓它去吧！
專心在當下的「目的」。

體悟

不順心、不如意的事情，可以放下它。
不確定的事情，還是不確定！別讓它擾亂自己的心。
###