網頁

搜尋此網誌

2011年12月26日 星期一

National Taipei University of Technology 台北科技大學

今年(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。
期望國內能有更多的優良書籍出版,好讓我捐獻給學校。(大家都去借書了,誰來買啊...)
###

2011年12月22日 星期四

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

書不怕被多翻閱幾次,每次閱讀總會有不同的收穫!拿起身旁的「物件導向設計模式」這本書,兩年前(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。譯自:Design Patterns: Elements of resuable object-oriented software

「設計模式」一詞源於美國建築理論學家─克里斯多福‧亞歷山大(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目的
生成模式
(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)才運作,屬於動態關係。

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

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

2011年12月15日 星期四

Learning Python 學習手冊

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 物件導向分析設計與應用

物件導向(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物件導向設計模式

譯者在他的部落格中的書籍資訊
Huan-Lin 學習筆記: 《物件導向分析設計與應用 第三版》書籍相關資訊

2011年12月11日 星期日

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

軟體開發當中,最不想遇到的情形就是「接手既有的專案」,因為不曉得藏有多少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)
多數軟體專案常常受到「汙染」(通常不是惡意的,是不得已或無知之錯),隨著開發時間的增長,汙染程度與日俱增,最後根本無法維護利用。「軟體構築美學」適合推薦給專案管理與系統開發人員,裡面有太多正確的觀念和務實的作法非常值得學習,期望閱讀後不要再有「汙染」產生。

###

2011年12月8日 星期四

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

在實際工作環境之中,軟體測試(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就沒事。

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

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

###

2011年12月6日 星期二

Designing Web Interfaces 網頁介面設計模式

自從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)為輔去建構出建築物,我想這個概念同樣適用於網頁設計上,只要我們掌握住上述這些設計模式,設計時考量各種限制與衝突,則建立優異的使用者經驗將不會是一件困難的事情!

###

2011年12月5日 星期一

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

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)的規範,書中介紹的主題如下:
推薦這本書給想認識CSS3的人,注意「想做好網站一定要會的CSS3」不是參考工具書喔!想要看CSS規範請至W3C網站查詢。

###

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

2011年12月3日 星期六

HTML5: Up and Running

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個主題:
  1. 新的語義元素,HTML5新增的語義元素標記。
  2. 繪圖,使用<canvas>標記。可以參考HTML5 canvas - the basics的說明
  3. 可以內嵌在網頁中的影片,使用<video>標記。
  4. 地理位置,位於navigator物件的geolocation屬性。
  5. 永久性的本地端儲存功能,位於window物件的applicationCache屬性。
  6. 離線的網頁應用程式,位於window物件的localStorage屬性。
  7. 改良的HTML表單,新增input標記的型別。
  8. 微資料(microdata),客製用語典(custom vocabularies)。
整體而言,這本書可以讓我們窺見HTML5的概況,內容方面是講述大方向、以概念為主,因此,「HTML5:建置與執行」適合給想認識HTML5的人。若想細部瞭解HTML5的語法和用法,需要再去閱讀HTML5的規範與相關應用的程式碼。

###

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

2011年11月28日 星期一

Learning SQL

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

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

SQL語言可分為三類:
  1. SQL結構描述陳述式(SQL schema statements)
    有關建立資料庫(資料表、索引、條件約束),通常是資料庫管理員要熟悉的工作內容。
  2. SQL資料陳述式(SQL data statements)
    建立、操縱和擷取儲存在資料庫中的資料,通常是程式開發人員與資料庫使用者,以及資料庫管理員必須熟悉的工作內容。
  3. 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 資料庫

2011年11月11日 星期五

System Analysis and Design 系統分析與設計

前些日子研讀系統分析與設計(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 統一塑模語言

2011年11月8日 星期二

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

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

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

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

一封電子郵件(e-mail)通常有9個項目:
  1. From:寄件人
  2. To:收件人
  3. Cc:副本,是carbon copy的縮寫
    Bcc:密件副本,是blind carbon copy的縮寫
  4. Subject:信件主旨
  5. Attachment:附加檔
  6. Salutation:稱謂語
  7. Body:信文
  8. Closing Segment:結語
  9. Complimentary Close:結尾敬語
 一般書信(非電子郵件)包含9個項目,由信件上至下依序為:
  1. Letterhead:信頭
  2. Date:日期
  3. Addressee:收信人
    Address:收信人地址
  4. Salutation:稱謂語
  5. Subject:主旨
  6. Body:信文
  7. Closing Segment:結語
  8. Complimentary Close:結尾敬語
  9. Signature:簽名
 另外,商用書信的三大格式分別是:
  1.  Full-block Form齊頭式
  2. Semi-block Form半齊頭式
  3. Indented Form縮格式
###

2011年11月2日 星期三

Beginning Programming 學習程式設計

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

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

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

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

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

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

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

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

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

###

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

2011年10月27日 星期四

Server Architectures 伺服器系統架構

伺服器(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。
    增加系統中的節點數量,進而擴充整體系統的容量或效能。
上述只是稍微講述伺服器架構的基本觀念,還有很多知識需要進行研讀,後續再撰寫文章介紹。
###

2011年10月22日 星期六

Drive: The Surprising Truth About What Motivates Us 動機

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

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

科學研究指出動機有三種驅力:
  1. 生理上的驅力:食物、性。
  2. 外在環境的驅力(外在誘因):獎勵懲罰制度(胡蘿蔔和棍子)。
  3. 工作的績效表現(內在激勵):滿足感、成就感、樂趣。
不過在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型行為」的環境。

###

2011年10月17日 星期一

Linux Filesystem Hierarchy 系統架構與目錄

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

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


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

由於Linux是自由開放原始碼的作業系統,各廠商推出不同的Linux版本有所差異,因此造成系統檔案架構而有所不同,所幸差異不大,加上目前已經有Filesystem Hierarchy Standard (FHS)的標準規範Linux檔案架構,學習起來不會太困難(因為有參考資料)。另外,你也可以使用man hier指令顯示目錄階層的說明,這個指令非常實用。

目錄中最為重要的就是根目錄(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 (或 UNIX source repository) 的縮寫,其中sbin目錄則用於系統管理之用(system binary),這裡類似於Windows中的C:\WINDOWS\system32目錄的功能。此外,使用者安裝的應用程式,則是位於/usr/local/bin目錄中,類似Windows中的C:\Program Files目錄的功能。

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

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

Delight Press
請再版,好嗎!

其他參考資料:https://wiki.debian.org/FilesystemHierarchyStandard

###

2011年10月13日 星期四

Bourne Again SHell 命令列介面

最近重新開始學習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
或是使用指令: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的操作其實不難,熟悉後就得心應手了。
###

2011年9月1日 星期四

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

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

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

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

這是一本值得推薦的書,推薦給想要改變世界的人。
王詠剛、周虹,世界跟著他的想像走:賈伯斯傳奇,台北:天下遠見,2011。

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

2011年8月5日 星期五

Are Your Lights On 你想通了嗎

介紹解決問題的經典著作,這本書是「真正的問題是什麼?你想通了嗎?」原著書名: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)。
    • 一旦你用文字來描述一個問題,請不斷調整你的遣詞用句,直到它進到每一個人的腦袋裡為止。
  • 第四章,這是誰的問題?
    • 不要急著幫別人解決問題,當他們自己就可以處理得很好的時候。
    • 如果這是他們的問題,就讓它成為是他們的問題。
    • 如果一個人是因為職位而被迫處理和他無關的問題時,你要做的就是─讓他的問題也產生關係。
  • 第五章,問題是從哪來的?
    • 問題的起源通常和你自己大有關係。
    • 在這世界上有兩種人,一種人會做事,另一種人則是找事情給別人做。
    • 問題是誰出的?他的企圖是什麼?
  • 第六章,我們真的想解決它嗎?
    • 不管看起來如何,人們其實很少真正知道他們需要的是什麼,直到你給了他們要求的那些東西。
    • 到了最後的分析階段,其實沒有多少人是真的希望他們的問題被解決。
    • 我們永遠沒有足夠時間可以把事情做對,不過,我們總有足夠時間可以把事情重做一遍。
    • 我們永遠沒有足夠時間思考自己是否需要它,不過,我們總有足夠的時間可以後悔。
    • 魚,總是最後一個看到水的。
我們每天生活都會遇到問題,而書中的觀念讓我們可以正確地解決問題,這是一本值得一讀再讀的經典,推薦。

###

2011年8月1日 星期一

Taiwan Software 台灣軟體

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

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

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

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

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


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

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

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


###

2011年7月7日 星期四

Component Object Model 元件物件模型

最近重新研究元件物件模型(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」一書)
  1. 元件必須是以動態連結的方式加入應用程式
  2. 元件必須隱藏(或封裝)實作的細節。
元件必須符合的限制:(參考「完全剖析COM」一書)
  1. 元件必須隱藏實作時所使用的程式語言
  2. 元件必須以二進位格式存在
  3. 元件的升級不能造成目前使用者的困擾
  4. 元件必須具有網路通透性。 

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

2011年6月17日 星期五

Infrastructure as a Service 基礎架構即服務

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

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

基礎架構必須具備的功能有:
  1. 資源抽象
    將實際硬體抽象化成為一個虛擬裝置,對上層架構提供硬體資源。
  2. 資源監控
    抽象化的硬體資源有了,必須可以監控量測,這是為了管理。
  3. 負載管理
    利用資源監控所獲得的資訊,對各個硬體資源進行負載管理,在校與成本之間取得平衡。
  4. 資料管理
    雲端的資料不是存放於單一實體裝置,資料的所有特性必須可被管理。
  5. 資源部署
    用戶所需的資源必須由系統提供,必須可以自動化部署給用戶。
  6. 安全管理
    這是系統的基本要求,沒有人會去使用一個不安全的雲端。
  7. 計費管理
    雲端的商業模式採用按量計費,利用資源監控可以得到計費所需的使用量資訊。
上述每項功能,如果真的要動手實作完成,要做的事情可是非常非常多的,不過這已經是雲端運算架構當中最基礎的功課。如果要完成基礎架構上面的平台層,事情可是多更多,因為平台的工作=平台層+基礎架構層。

###

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

2011年6月10日 星期五

Love Catch 22 愛情的22個關鍵詞

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

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

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

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

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

2011年6月8日 星期三

Education 教育應該不一樣

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

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

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

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

這本書總共7章,前3章分別從家長、老師與(青年)學生3個「共錯結構」探討,而第4、5章則從教育制度上討論,第6章是提高到每個人可以做的方法,最後第7章總結教育應該不一樣。以下是整本書的大綱:
  1. 醒醒吧!家長
    不是每個人都要當國家棟梁,社會更需要腳踏實地、堅守岡位、熱愛工作的螺絲釘。
  2. 老師可以更勇敢
    教育不應是倒滿一壺水,而是點亮一根蠟燭。
  3. 年輕朋友請走一條追尋自我天賦之路
    只有專注和熱情,生命火光終會帶領你穿越人生迷霧。
  4. 只有創意和實力才能面對高學歷通膨時代
    教育應該是讓學生關懷自己以外的人事物,激發對社會、對世界的熱忱。
  5. 技職教育的黑洞
    教育必須是為學生照亮未來的探照燈,而非重複過去的後照鏡。
  6. 我們都是選民,更是公民
    監督教育政策事責任,也是權利。
  7. 教育應該不一樣
    台灣過去的文化優勢,必須轉變成未來的台灣核心教育元素。
推薦這本書給台灣的每一個人,台灣教育的未來必須靠我們一起改變,如同嚴長壽先生他明知道未必有所改變,但他帶著天生的社會使命感,他仍選擇再做一次「豬頭」。不論我們是否能夠改變什麼,但只要現在開始行動(不能只說不做),就一定有變好的那一天。

###

2011年6月7日 星期二

Certainty 確信

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

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

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

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

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

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

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

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

Me:
確定你確定的,相信你相信的。
剩下的:不確定、不相信的,就放下吧!

Jasper:(這段經典...一定會在歷史上留下)
"剩下的:不確定、不相信的,就放下吧!" 等死就對了!!
往前走,有水(活),沒水(死),有沒有水不知道,走就對了!!

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

Me:
不然要怎樣...

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

體悟

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

2011年5月30日 星期一

Diamond Sutra 金剛經

讀了一陣子金剛經(Diamond Sutra),似懂非懂。直到最近遇到煩惱,才有機會「心行」,體會一些道理了!

金剛經不是容易讀懂的內容,只能意會,不能言傳。郝明義先生一隻牡羊的金剛經筆記,這本書已經是容易地讓人瞭解金剛經是什麼、做什麼。

最近,2011年5月蔡志忠先生的「漫畫金剛經:安頓心的力量」則是另一個較輕鬆的版本,圖文新解的方式,真的是金剛經的入門,讓更多人可以瞭解金剛經,非常推薦給你,我自己讀起來好像看故事書一般(不過金剛經還是金剛經啊~)。

蔡志忠,漫畫金剛經:安頓心的力量,台北:圓神,2011。

這本書分成三個部分,(建議)可以依照第1部、第2部、第3部的順序閱讀。
  • 第1部:金剛經‧入門篇
  • 第2部:金剛經‧漫畫新解
  • 第3部:金剛經‧全文
第1部是講述金剛經的要點與名詞註解,讓我們有基礎去閱讀金剛經。第2部則是漫畫與白話文的解釋,有了圖文的想像更能瞭解金剛經的涵義。第3部是金剛經的原文,如果前2部都懂了一些,請直接品嘗原汁原味的全文。

下列是金剛經的架構,共分為32個段落(應該是不能區分段落,這是梁昭明太子所定之32分),這本書特別在於加入引號中的八個字(意義是?)。
  • 法會因由分第一「說法聚會,由此起因」
  • 善現啟請分第二「善現長老,啓請佛訓」
  • 大乘正宗分第三「最大之乘,最正之宗」
  • 妙行無住分第四「奧妙之行,本無住著」
  • 如理實見分第五「自如之理,乃見真實」
  • 正信希有分第六「生正信心,最為希有」
  • 無得無說分第七「空則無得,寂則無說」
  • 依法出生分第八「諸佛之法,依此生出」
  • 一相無相分第九「只此一相,本來無形」
  • 莊嚴淨土分第十「成就莊嚴,淨明心地」
  • 無為福勝分第十一「修無為福,勝於布施」
  • 尊重正教分第十二「受持正教,天人尊重」
  • 如法受持分第十三「當如此法,承受奉持」
  • 離相寂滅分第十四「離諸形相,自得寂滅」
  • 持經功德分第十五「受持此經,功德無量」
  • 能淨業障分第十六「若能清淨,業障盡消」
  • 究竟無我分第十七「成佛究竟,本無我相」
  • 一體同觀分第十八「萬法歸一,更無異觀」
  • 法界通化分第十九「法身遍界,通化無邊」
  • 離色離相分第二十「色相皆妄,離妄見性」
  • 非說所說分第二十一「法無可說,所說非法」
  • 無法可得分第二十二「悟性空故,無法可得」
  • 淨心行善分第二十三「以清淨心,行諸善法」
  • 福智無比分第二十四「福智甚大,無物可比」
  • 化無所化分第二十五「聖凡同性,化無所化」
  • 法身非相分第二十六「清淨法身,非屬相貌」
  • 無斷無滅分第二十七「依法修持,不應斷滅」
  • 不受不貪分第二十八「一塵不染,何貪何受」
  • 威儀寂靜分第二十九「真性寂靜,不假威儀」
  • 一合理相分第三十「一合之理,實無有相」
  • 知見不生分第三十一「如此知見,法相不生」
  • 應化非真分第三十二「應現設化,亦非真實」
這本書的註解非常值得一讀,其中「應無所住而生其心」的意思是:面對任何情境時,應無我地融入情境,不以分別心去評斷好壞順逆。(解釋是清楚明白,但是心行...就難囉!用心若鏡)

###

2011年5月22日 星期日

Uncertainty 不確定

不確定(uncertainty)」這個性質對於某些人來說是種煎熬,這種心理上的折磨可能比生理的痛苦要來的難受。自從3月底至今5月底兩個月的時間,由於自己改變一些事情,我的感受特別深刻,加上Jasper312的實例呼應(公職考試),在這裡有必要記錄分享。

人是個很矛盾的組合,感性與理性的結合,追求穩定狀態又喜歡改變現況,於是「不確定」的狀態油然而生,隨著年紀的增長,遭遇到的「不確定」只會讓自己更加煎熬(因為都更不確定且更複雜)。如果沒有好好面對處理,我認為身心都會發生問題(沮喪、悲觀、無奈...),特別是那些時間特別長的「不確定」。

「不確定」讓自己只能去猜測結果,「如果怎樣...就怎樣...萬一....」的推測,只會讓人越去想到最糟情況(worst-case)。以考試這個例子來說,為了讓考試結果達到預期目標,除了自己充分準備之外,其餘的「不確定」太多了,考題超出能力範圍、考生水準提高、錄取名額降低...等,都讓達到目標的「不確定」更不確定,相信Jasper312一定有所體悟。

現在自己看來,用智慧去面對「不確定」是最好的方式(實踐金剛經),讓自己的「心」減少煎熬(若要沒有可能要成佛了...)。那智慧要怎麼獲得呢?我建議記下一些話語,並且體悟話語的涵義,我認為這是比較務實有效的方式!

我很希歡聖嚴法師的這段話「面對它、接受它、處理它、放下它。」確實一開始看不是很懂,然而隨著經歷的豐富,遭遇到的苦惱一個比一個煎熬,慢慢有所體悟!與你分享。

###

2011年5月19日 星期四

Peopleware 人件

介紹與「The Mythical Man-Month 人月神話」齊名的(軟體)專案管理經典著作!這本書是「Peopleware:腦力密集產業的人才管理之道」,簡稱「Peopleware(人件)」,是一本探討團隊管理的書籍。

原著書名是「Peopleware: Productive Projects and Teams, 2nd ed.」,出版商是Dorset House Publishing,Peopleware於1987年初版,在1999年發行第二版,中文版則是於2007年翻譯第二版發行,2007年恰好是「Peopleware」的20週年(作者Timothy Lister特地寫了中文版序)。

湯姆‧狄馬克(Tom DeMarco)、提摩西‧李斯特(Timothy Lister),方亞瀾、錢一一譯,Peopleware:腦力密集產業的人才管理之道,台北:經濟新潮社,2007。

整本書的內容,每一句話都說得太好了、太真實了,不愧是造成轟動的書籍!分成6個部分總共64章,前5部分是第一版的內容,在發行第二版時增加第6個部分(共8章),每個部分各別討論團隊管理的不同角度。
  1. 第一部,管理人力資源:從管理的角度探討團隊。
  2. 第二部,辦公室環境:從環境的角度探討團隊。
  3. 第三部,適任的人:從人員的角度探討團隊。
  4. 第四部,培育高生產力的團隊:從團隊的角度探討團隊。
  5. 第五部,在此工作應是樂事一樁:從工作的角度探討團隊。
  6. 第六部,續集:加入歷史的角度探討上述觀點。第六部份的文章值得細細咀嚼品味,太多「對」的觀念了。
這本書有太多值得一讀再讀的觀點。如果你像我一樣是基礎開發人員,這本書值得我們相互取暖,世界還是有些希望和理想的存在。若你是管理人員,請別再用你「以為正確的方式」進行團隊管理,除非你已經看過Peopleware(請不要只閱讀一次),否則你認為的那些方法只會越弄越糟而已。不幸的是,目前許多管理人員都還是那舊時代的觀念啊!

以下是書中極為經典的幾段話。

這段是整本書的基本論點:「我們在工作中所面臨的,在本質上,主要都是社會性(sociological)的問題,而非技術性(technological)的問題。

「處於時間壓力下的人不會把工作做得更好,只會做得比較快。」

帕金森定律(Parkinson's Law):「無論配置多少工作時間,該工作都會把配置的時間耗光。」,對於一個組織則是「組織裏沒有效益的白工,傾向於會把工作時間耗光。」

「大量的文件只會製造問題,而非解決問題。」

「團隊的目的並不在於達成目標,而在於統一目標。」

對了,這裡要感謝譯者方亞瀾、錢一一兩位,以及經濟新潮社對於「Peopleware」一書的用心翻譯出版,讓我們有機會輕鬆閱讀這本經典著作。
###

2011年5月2日 星期一

The Mythical Man-Month 人月神話

人月神話(The Mythical Man-Month), 1975年初版,1995年發行20週年紀念版。現今2011年已經過了36年,這本書還是軟體專案管理的經典

一年前開始閱讀人月神話的幾個章節,撰寫一篇關於「No Silver Bullet 沒有銀彈」的文章,主要是討論人月神話中第16章的內容。隨後工作忙碌加上對於書中的內容未能有所體悟,因而將人月神話擱置書房一隅,最近隨著軟體專案的混亂情形,於是我再次品味這本經典著作。

Frederick P. Brooks, Jr.著,錢一一譯,人月神話:軟體專案管理之道,台北:經濟新潮社,2004。

原文書是Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2/E,由Addison-Wesley Professional於1995年出版。

此篇文章,我想談談軟體團隊這個部分。從我過去的經驗當中,每個專案都是由一個人(或二至三個人)從頭到尾負責,因此一個人必須學習各類知識與技巧,時間一久練了不少好功夫(卻累死自己),自己倒是習以為常!

可是,當自己進入一個企業組織中,竟然發現這組織也是這樣玩!這是績效制度下的結果嗎?擔心考績評比不好計算、還是希望有人可以揹黑鍋啊!軟體不是製造業,軟體不能這樣玩的,難怪怎麼搞就怎麼失敗。

我認為人月神話中的「外科手術團隊(Surgical Team)」的概念值得借鏡,這個團隊是由Harlan Mills所提出的觀點,他建議大系統中的每個小部分都分別交給一個「外科手術團隊」負責,這種團隊的工作優點在於工作是同心且一致的方向,具有概念整體性(Conceptual Integrity)。雖然說是適用於大系統的組織,我(個人直觀)認為小型專案也是可以適用「外科手術團隊」。

「外科手術團隊」的成員是10人,角色如下(其工作內容且參閱書籍):
  • 外科醫師(surgeon),軟體專案上稱為首席程式設計師(chief programmer)
  • 副手(copilot)
  • 行政助理(administrator) + 秘書(secretory)
  • 文書編輯(editor) + 秘書(secretory)
  • 程式助理(program clerk)
  • 工具專家(toolsmith)
  • 測試員(tester)
  • 語言專家(language lawyer)
補充:應該還需要管理者,也就是產品專案經理。再加上一位技術總監(technical director)。

這種團隊對於軟體專案而言似乎是夢幻,也許是因為軟體不關乎人命,軟體開發可以允許發生失敗(這都快變成定律了...)。因此,一個軟體開發者(軟體工程師)可以從規格制訂、軟體設計、撰寫實作,到後期整合測試與撰寫文件,通通一個人自己來!專案的成敗自己扛,反正程式碼改一改都很快嘛!(這句話你熟悉嗎?)

重要的「Brooks定律」:
在一個時程已經落後的軟體專案中增加人手,只會讓它更加落後。
Adding manpower to a late software project makes it later.

感謝錢一一先生與經濟新潮社對於「人月神話」一書的用心,翻譯品質非常好。
###

2011年4月22日 星期五

The Grand Design 大設計

這本書「大設計(The Grand Design)」是史蒂芬‧霍金的新書,這本書圍繞一個主題:為什麼宇宙中有個法則!這本書不是說明宇宙中存在什麼法則,強調是「為什麼」這個觀點,或者說這本書是探討「科學哲學」的議題。

Stephen Hawking(史蒂芬‧霍金) and Leonard Mlodinow(雷納‧曼羅迪諾)著,郭兆林、周念縈譯,The Grand Design(大設計),台北:大塊文化,2011。

「大設計」這本書讀起來比較像是故事書,一個問題接著一個解釋,引出另一個問題又接著另一個解釋,大致是依據歷史的先後順序敘述「大設計」。整本書共分成八章:
  1. 存在的奧秘(The Mystery of Begin)
  2. 法則的支配(The Rule of Law)
  3. 真實是什麼(What is Reality)
  4. 多重歷史(Alternative Histories)
  5. 萬物理論(The Theory of Everything)
  6. 選擇我們的宇宙(Choosing Our Universe)
  7. 乍看下的奇蹟(The Apparent Miracle)
  8. 大設計(The Grand Design)
書中解釋科學理論用了非常平易近人的方式說明,用一些例子講述這些理論的概念,像是相對論量子理論我就是在這本書中有了認識!其中第三章的「真實是什麼」用了金魚缸的例子特別有趣。

魚缸中的金魚透過圓弧形的魚缸看到外面的世界,因此,金魚所見是個扭曲的世界。我們可以認定,金魚看到的世界不真實嗎?或者,金魚提出的科學法則是宇宙的法則嗎?非常有趣的問題。我們人類是不是也像魚缸中的金魚呢?這本書提供了答案。

我認為這本書非常適合學習科學(物理與化學...等學科)之前閱讀,可以使我們瞭解「科學的本質」與「什麼是真實」兩個哲學問題。除此之外,書中用了非常容易理解的概念解釋何謂相對論、量子理論、大霹靂理論值得推崇!

這本書的後半部解釋終極理論:M理論(M-Theory)是萬物理論的候選理論,這滿足我十多年前當學生的好奇心,當時總是認為物理學這些背後總有什麼統一理論,總算在這本書中看見曙光,雖然有部分讀了不是很懂(屬於科學的專業領域),卻已經照亮心中那個大問號。

我推薦「大設計(The Grand Design)」給喜歡追根究柢的人!
###

2011年4月6日 星期三

Database 資料庫

資料庫(Database)看來是越來越重要了!幾乎只要有電腦的地方都會使用資料庫,例如每天都使用的搜尋引擎,後端就是一個龐大的資料庫,紀錄Internet上的網頁內容供User搜尋。

討論一個議題,必須先定義清楚。首先,依據「Ramez Elmasri & Shamkant B. Navathe, Fundamentals of Database Systems 5th edition, Addison-Wesley, 2007」,資料庫的定義是:「A database is a collection of related data.」這個定義相當簡略,就是「資料」。這裡還要提一點,描述資料庫的資料,稱為meta-data(或metadata,中文稱為中繼資料、元資料...)。

什麼又是資料庫管理系統(Database Management System, DBMS)?所謂DBMS定義:「A DBMS is a collection of programs that enables users to create and maintain a database.」管理資料庫的軟體。DBMS的主要功能有四項:定義(Defining)、創建(Constructing)、操作(Manipulating)與分享(Sharing)資料庫。另外,多數DBMS也會提供保護(Protecting)與維護(Maintaining)兩項功能。

注意,上述提到Database與DBMS兩個觀念,我們一般說資料庫通常是指「資料庫系統(Database System)」,Database System = Database + DBMS,像是MySQL、Microsoft SQL等等。

關於資料庫的書籍,中文可以閱讀這本:
楊先民,實戰資料庫設計,台北:精誠資訊,2009。

英文的書籍,則推薦Ramez Elmasri & Shamkant B. Navathe撰寫的Fundamentals of Database Systems第五版。
###

2011年3月22日 星期二

Cloud Computing Strategy 雲端運算策略

雲端運算(Cloud Computing)在2009年是一個熱門的話題,但對於我或是一些人來說,真的實在無法清楚明確定義何謂「雲端運算」,今天介紹這本書「雲端策略:雲端運算與虛擬化技術(Cloud Computing Strategy)」,作者們是:陳瀅、王慶波、金涬(ㄒㄧㄥˋ)、趙陽、何樂、鄒志樂、吳玉會、楊林。

陳瀅著,雲端策略,台北:天下文化,2010。

這本書的內容正如其名,前半部分(1~4章)介紹雲端運算,後半部分(5~7章)介紹虛擬化技術,雲端運算仰賴虛擬化、自動化、標準化三項核心技術的技術基礎是虛擬化(virtualization),沒有虛擬化可說是很難實現雲端運算的目標(可以不需要虛擬化技術)。書籍架構如下:
  • 第一章 雲端運算概論
  • 第二章 迎向智慧新生活──雲端產業創新
  • 第三章 雲端架構
  • 第四章 雲端運算的關鍵技術與挑戰
  • 第五章 虛擬化概論
  • 第六章 虛擬化的關鍵技術
  • 第七章 虛擬化的業界動態
  • 第八章 業界動態
雲端運算的理念是將計算與儲存簡化成像公共水電一樣便利的資源,用戶只要藉由網路就可以方便使用,依據用量付費。雲端運算的最大意義在於商業模式的創新,提供運算服務如水電一般讓用戶使用,不同於其他運算模式(Cluster Computing、Distributed Computing、Grid Computing)。

雲端運算的特徵此書中提出四點:
  1. 硬體和軟體都是資源(在雲端),透過網路以服務的方式提供給使用者。
  2. 資源可以根據需要進行動態擴展和配置。
  3. 資源(軟硬體)以分散式的共用方式存在,最後以單一整體的形式呈現(給使用者)。
  4. 用戶依照需求使用雲中的資源,按照實際使用量付費,不需要負擔管理的責任。
我們從不同觀點看雲端運算,依據服務類型則分成三種:
  1. 基礎設施雲(Infrastructure Cloud):以Amazon EC2為代表,靈活度最高,需要開發應用程式服務,使用者運用操作較困難。
  2. 平台雲(Platform Cloud):以Google App Engine為代表。
  3. 應用雲(Application Cloud):以Salesforce.com為代表,靈活度最低,直接提供特定服務,使用者運用操作最簡單。
再從另一個觀點來看,依據服務方式則分成三種:
  1. 公有雲:「雲端的服務」是由雲端供應商提供。
  2. 私有雲:企業或組織獨立建置使用的雲端運算環境。
  3. 混合雲:公有雲和私有雲的混合。
敘述了這們多資訊,這也只是「第一章 雲端運算概論」的內容而已,若各位想清楚瞭解何謂「雲端運算」,這本書的確說得夠清楚有系統!

最後談談,雲端運算的優勢有哪些?書上提到這五點:優化產業布局、推進專業分工、提升資源利用率、減少初期投資、降低管理開銷。

###

2011年3月20日 星期日

Karajan Forever

趁著前些日子累積下來的購物金,買了一張卡拉揚的CD,這張是「永遠的卡拉揚(Karajan Forever: The Greatest Classical Hits)」,價格是NTS429包含2CD共29首,可說是低價版的入門選擇,CD是歐洲製造(Made in the E.U.),內容細節請看CD專屬網站

雖然錄音是1970至1980年代的產物,但是聽起來卻有高質感(或許經過處理),有點像是影片FullHD的感受。封面個人認為是Herbert von Karajan很帥的一張相片!



###

2011年3月19日 星期六

Zend Framework 禪 框架

最近開始使用「Zend Framework」開發一個系統,起初搜尋Zend Framework關鍵字時發現:它的架構非常複雜...,看到這不免令人擔憂,爾後我更進一步研究認為這問題應該還好,因為官方文件寫的頗為詳盡!缺點是中文參考書籍與資料較為匱乏(問題不大)。

目前學習「Zend Framework」的心得是不困難,前提是你必須擁有Django或是Ruby on Rail的開發經驗,大致上這類Web Application框架的使用觀念相同,我認為「Zend Framework」設計非常詳盡,元件數量相當多但權責劃分清楚,推薦大家放心用來開發(有前提啊)。

「Zend Framework」的元件分成8類
  • Model-View-Controller (MVC)
  • Tooling and Rapid Application Development (RAD)
  • Database
  • Internationalization (i18n) and Localization (l10n)
  • Authentication, Authorization, and Session management
  • Web and Web Services
  • Mail, Formats, and Search
  • Core Infrastructure
學習上建議先從QuickStart文件開始閱讀,你將可以瞭解MVC架構和熟悉命令工具的操作(zf Command Line Tool)。

###

2011年3月8日 星期二

PHP Debug

記錄PHP除錯心得,通常使用PHP開發網頁應用程式(Web Application)時,為了看到變數的值,我們會使用echoprint(陣列用print_r)把值丟到網頁上查看,這是一個爛方法!

使用PHP這麼久,最近為了開發更複雜大型的應用程式,開始尋找有沒有好的除錯方式,最好像是Visual Studio的方式,可以單步執行設定中斷點的方法。

方法是必須安裝Xdebug或是Zend Debugger(Studio Web Debugger),並且需要設定php.ini組態檔,爾後還需要Eclipse(外掛PDT)設定Debug Configuration,稍微複雜但可以正常運作喔!Eclipse的設定沒有什麼大問題,倒是debug元件安裝比較有疑問(安裝說明不清楚),以下為安裝步驟記錄。

Xdebug的安裝是:
  1. 下載php_xdebug-2.1.0-5.3-vc6.dll複製到php\ext之下
  2. php.ini設定檔加入下列指令,絕對路徑才可以動。指令請參考http://www.php.net/manual/en/ini.list.php
zend_extension="C:\php\ext\php_xdebug-2.1.0-5.3-vc6.dll"
xdebug.remote_enable=true
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.profiler_enable=1

Zend Debugger的安裝是:
  1. 下載ZendDebugger.dll複製到php\ext之下
  2. 複製 dummy.php到網站根目錄下(document root directory)
  3. php.ini設定檔加入下列指令,絕對路徑才可以動。
zend_extension_ts="C:\php\ext\ZendDebugger.dll"
zend_debugger.allow_hosts=127.0.0.1
zend_debugger.expose_remotely=always

記得最後重新啟動Apache網頁伺服器,重新載入PHP直譯器,接著去設定Eclipse玩玩吧!
###

2011年3月5日 星期六

View

2011年2月25日重新配了一副新的眼鏡,今天配戴後有一些心得。鏡架我一直選擇 Dr. Swan這個牌子,而鏡片的部分則改用ASAHI-LITE(朝日光學)的非球面鏡片,全部加起來讓我花了不少小朋友。我對眼鏡有更進一步的了解來自於「韋在兄」,他是一位特別的人!他對於眼鏡可以說出一連串的故事,例如鏡架是什麼人所設計和背後的故事、鏡片的差異有哪些...等,此外,對於古典樂、文學、品酒等等的一些「趣事(對我而有是相當有趣的事情)」他都很了解。

眼鏡,對我而言,就像是敲門磚,把我推向另一扇窗,讓我有機會看到窗外的世界,認識到各種人生的可能性。我相信任何人對於一件事情,如果可以深入瞭解,這就會是一個敲門磚。

眼鏡是消耗品。這次想換眼鏡是鏡片發生脫膜(多層膜鍍膜掉落),加上鏡片用久三年已經變黃(為什麼會變黃),看起東西來清晰度、舒適度不佳,變成不得不替換鏡片。如果依照這個情形下去,每三年左右就必須更換鏡片,那麼眼鏡就會是消耗品!靜下來看看四周,每個人使用的東西都是一種消耗品,手機、房子、車子、知識...等,差別只在於時間消耗的長短,不是嗎?

在我開始瞭解眼鏡之後,我才真正開始研究球面、非球面、雙非球面的結構差異,而且材質有折射率1.5、1.6、1.67...等的區別,折射率也影響厚度,鏡片的製造商也有他們各自的強項特點,不過可惜這方面的資訊(書籍)不多。

換了眼鏡之後,物體的顏色和清晰度明顯提高,豁然開朗。從另一個角度來說,假設我的眼睛沒有變差,隨時間增加我看東西的品質越來越差,只因為我戴的眼鏡的關係,這會不會讓我誤以為某些東西品質不好?好比區分不出Full HD的螢幕與一般CRT螢幕的差異,太可怕了!只因為自己慢慢習慣鏡片的磨損與老化。

如果你是戴眼鏡的一群,適時的替換有其必要性!
###

2011年2月22日 星期二

Solve

記錄有關於解決問題的方法,這是三年前教導別人的心得。

生活中常常會遇到很多新問題(解答不在自己既有的經驗中),這些問題對於青年學生(引用李開復先生常說的青年學生)而言往往不知所措,可是沒有人告訴(或教育)他們應該怎麼辦,好似出生就應該會的本領!

我一直認為,一定要告訴青年學生如何解決問題,這個問題就像如何讀書、如何考試一樣重要。中國的文化長久以來就是要求青年學生讀書考試,可是卻沒有去教育他們,讀書考試是有方法的、有技巧的、有策略的。再把層次往上提高,讀書可說是解決問題的一個方法之一,這個解決問題的方法非常重要,足以影響一個人的一生,可是(我的記憶中)卻沒有人告訴教導我們。

解決問題的方法的方法大概有下列幾個:

1.「問人」,這大概是每個人出生就會的,而且使用最頻繁的方法。但要問什麼人?小時後問父母長輩,學生時期問老師,青年時問同伴,出社會後什麼人都問了!這個方法需要良好的人際關係技巧,也就是人脈的重要性。

2.「找資料」,找了資料就是要看懂才有用,讀書大概就屬於這方面的技巧。要如何看懂又是另一個問題,我們可以利用前一個「問人」的方法來解決,或是找更多資料,資料中總會有比較容易看懂得部分,我們要從這一點切入。那麼,要去哪找資料?以前大概只能從書籍紙本上著手,現在可以從網際網路上搜尋,所以搜尋的技巧很重要,資料如同人脈一樣廣度必須要夠廣,換句話說,我們不能侷限於單一語言的限制!

3.「自己嘗試」,如果前述第一、二方法無效要怎麼辦,研究生大概會遇到這類問題,做沒有人做過的研究,新的領域沒有參考資料,這時候就屬「嘗試中學習」可以找出解答了,我不太想用Try & Error(Trial by error)這個字眼,因為Try & Error需要知道哪裡錯誤,爾後才有可能將利用刪除法找出解答,可是有數人多半是亂Try...。我認為需要自我對話的能力,否則無法「自我嘗試」。

4.「花錢」,花錢也是方法之一,重點在於口袋要夠帶夠深,俗話說:花錢可以解決的問題都不是問題。

5.「創新解決」,像是牛頓被蘋果打到的方法,榨乾腦袋想出任何可能的辦法,如Post上網、請求中研院協助、等待奇蹟、冥想...等。

希望此文可以幫助青年學生
###

2011年2月17日 星期四

Start

看看自己的Confession這篇文章,我到底想寫什麼呢?唯一的意義在於自己高興,花了近60分鐘左右,寫了958個字(使用Microsoft Word計算),越看越不知道我的文章有什麼結論!

似乎寫部落格就是在抒發一種心情、記錄當下的感覺。當時,只感覺到很多想法在腦中一閃而過,閱讀的記憶與當下的念頭就馬上交織成為Confession這篇文章,算是抒情與記述文吧!

對於未來撰寫部落格的方向,我決定採取下列行動:

1.
字數限制在560字左右,自認為大概可以撰寫一篇短文的字數。千字以上太花時間培養,目前能力不及。微博的140字(這類的微網誌)又稍嫌過短,不足以心中醞釀的情感如實記錄。560個字能夠以四個140字的段落組成起承轉合的作文,我想也是不錯的方式!

2.
內容會依舊限制在一些閱讀書籍的心得感想,不過,不會以整本書的方式為主題撰寫文章,看書看到哪裡就寫什麼,有什麼想法和感想,我會趁著還很新鮮的時候就馬上撰寫,期望可以封存最初的原汁原味。

目前我會持續朝向這個方向改進。

繼續
###

2011年2月16日 星期三

Confession

經過2009、2010兩年撰寫部落格的經驗,最近,我想從這些回憶中對自己坦白一些事情。主要是近幾個月寫文章的數量越來越少,自己也越來越提不起勁,反省起來發現自己事情太多了,所謂「少則得,多則惑」的道理吧!

2009、2010兩年的期間,買書讀書的數量每個月比每個月多,2010一年平均每個月買書2000元的額度是有達成的!一年花費至少2萬4千元買書。藏書的數目增加近一倍,粗估有三四百本,這個月買的書下個月已經讀不完,確實是該檢討自己。

2010年底曾經覺得必須訂定閱讀計畫!否則如何消化我的藏書?是否為了閱讀計畫又去買書來讀!現在,我讀書的速度與體悟能力絕對有倍增的實力,然而到現在還沒訂定,更別談開始執行。(羞)

2009、2010兩年的期間,往回看看自己的部落格文章,每年大約60篇左右,內容上從一開始亂寫,寫給自己高興的。到後來慢慢針對一本書撰寫心得感想,有些確實是為了撰寫而寫的流水文,希望分享自己閱讀的喜悅與感想,此外,自己也針對技術領域撰寫摘要,記錄自己學習上的心得。

2010年底我卻提不起勁撰寫文章,不是沒有閱讀書籍,也不是沒有研究任何技術。我反省認為需要對自己的習慣與做法有所改善!除了檯面上發布的文章之外,庫藏文章也有30餘篇,多半是寫了一半沒有發佈,因為自己總希望對一個書籍內容或技術領域有完整的瞭解才開始動筆,這個想法好壞參半,好處在於文章可以有架構,循序漸進引人入勝,壞處在於當時收穫的熱度已退,雖有收穫卻不想起步行動。(殘)

光是這篇文章,早在過年初一就想動筆記錄了,我想我必須有所改變!今後只要自己有什麼想法,我就會開始寫下來,也不管有沒有架構,也不在乎完不完整,我告訴自己:「寫就對了!」自己快樂高興就好,不是嗎!

我一直很喜歡伏爾泰(François-Marie Arouet)的這段話:「我做的事情是多麼微不足道,可是我去做的本身,是無比重要。」這是我在閱讀查爾斯‧韓第(Charles Handy)先生的「你拿什麼定義自己」一書中看到的(全文最末段),隨即觸動我的心底,對阿!個人不就是該如此嗎!

現在,更讓我想起書中的這段(第一章末):「eBay的創辦人之一史科爾(Jeff Skoll)說,當他父親回家宣布自己被診斷患了末期癌症那天,父親告訴當時十四歲的他,自己並不害怕死亡,卻因為還沒做過這輩子想做的所有事而難過。換句話說,他怕會在親身體驗自己每一個可能面向之前就死去。幸好醫生診斷錯誤,他獲得了另一次機會。我們其他人也許不會這麼幸運。」

開始
###

2011年1月21日 星期五

Component Object Model 元件物件模型

談談元件物件模型(Component Object Model, COM)這個主題吧!前一陣子都在研究 DirectShow,常常看到 COM 這個關鍵字。由於最近才變成 Windows 程式開發人員所以不熟悉 COM,趁此機會好好研究一番吧!

請注意:COM 是一個標準 (Standard,也參照為Binary Standard,定義物件的結構),不是什麼工匠技藝 (craftsmanship) 的產品,也不是程式語言。COM 標準定義一個物件模型 (Object Model),使得 COM 物件(也稱為 COM 元件,或簡稱物件)可以和其他的物件互動工作。物件可以位於執行的行程 (process) 中,或其他行程,甚至是遠端電腦。

COM 是一個標準,因此可以使用多種物件導向語言 (Object-Oriented Language) 撰寫開發,通常是用 C++ 撰寫開發比較容易簡單,原因在於 COM 是 Binary Standard ,C++ 撰寫比較可以控制結構。

軟體中的物件包含資料 (data) 函式 (function) 兩部分,而 COM 僅有(唯一)利用函式的呼叫操作資料(換句話說,沒有資料這部分),這類函式在 COM 中稱為介面 (interface),而操作COM介面的函式稱為方法 (method) ,注意這些詞彙很容易讓人混淆,COM 的介面不同於C++的,一定要搞清楚!

更進一步來說,COM 要求這些介面必須是用指標 (pointer) 的方式實現(這是技術上關鍵的地方),COM 標準也定義一些元件通用的介面(部分介面必須具備,例如 IUnknown 介面)、元件之間的互動與安全性等。總結,COM 標準是定義介面,而介面實現 (interface implementation) 則由程式設計人員編寫。

COM 標準是微軟 OLE(Object Linking and Embedding) 和 ActiveX 技術的基礎,如果要學習這些技術,我們對 COM 的觀念一定要正確建立,以下是我認為 MSDN 上比較重要的觀念(要多讀幾遍):

###

2011年1月10日 星期一

Domain Name System網域名稱系統

今天談談網域名稱系統(Domain Name System, DNS)的觀念,記得當初ycwang授課的時候,我自己以為DNS是個簡單的系統,只不過就是把網址(URL)轉換為網際網路協定位址(Internet Protocol Address)的功能而已。

然而這樣的認知大概懂了一成,從這幾年的經歷看來,我對DNS的理論基礎沒有完全搞清楚,我太小看DNS系統了!沒關係,學習就是不斷發現自己的不足,然後趕緊補足遺漏的知識,最怕的是不知道自己缺了什麼。

從網頁應用程式的技術角度來看,URL(Uniform Resource Locator,)可以分成五個部分,以Google我的帳戶的URL為例:

https://www.google.com/accounts/ManageAccount?hl=zh-tw
  1. 通訊協定配置名稱(Scheme Name):即通訊協定,如https或http
  2. 主機名稱(Host Name):指的是www.google.com
  3. 連接埠編號(Port Number):與通訊協定有關,http是80的埠號
  4. 路徑名稱(Path Name):在主機上的資料路徑,這個範例是accounts/ManageAccount
  5. 查詢字串(Query String):http中指的是GET參數,如hl=zh-tw
從DNS的角度來看,DNS所做的是將URL的主機名稱(Hostname)轉換成IP位址(IP Address),提供「Hostname-to-IP-Address Translation Service」的功能,那麼大費周章的意義有二:

第一,網路上的主機位置是由IP位置判定識別,這是一個32位元的資料(一般以192.168.1.1之類的四段十進位字串表示),非常不容易讓使用者記憶與識別,所以我們才會需要主機名稱。

第二,主機名稱雖利於人類記憶與識別,但對於網路系統來說會有實現困難,因為主機名稱千百萬種長度不一,非常不利於網路設備(路由器)判斷,效率也不夠好,這也就是為何IP位置要定義32位元的固定長度

DNS除了上述功能外,還可以有三個用途:
  1. 主機別名(Host Aliasing):如果主機名稱(網址)不好記憶,可以用另一個做為別名。
  2. 郵件伺服器別名(Mail Server Aliasing):與主機別名用途相同,這指的是對於郵件用途。
  3. 負載分配(Load Distribution);利用DNS將同一個主機名稱分配至不同的IP位置。
從系統面來看,DNS網域名稱系統是一個分散式的(Distributed)大系統,並且是具有階層的(hierarchical)資料庫系統,DNS在網路架構上屬於應用層(Application Layer),底層傳輸層依賴的是UDP通訊協定,使用Port 53的埠號。

值得注意的一點,雖然說DNS屬於應用層,但是應用層之中的HTTP、FTP、SMTP等等應用服務都是依賴於DNS(都會使用到URL),我們可以說DNS是應用層的基礎設施(infrastructure)也不為過!

DNS伺服器的階層架構可分成三類:
  1. Root DNS servers:最上層,全球共13台,分別標示A至M
  2. Top-Level Domain (TLD) servers:第二層,管理網域如com, org, edu, gov或各國的網域位置。
  3. Authoritative DNS servers:被TLD授權的DNS,通常是組織自己建置的DNS,管理自己私人的URL。
另外為了效能上的提升,也有建置Local DNS servers與DNS Caching的功能。

以上是DNS大致上的概念,細節部分還真是多啊!千萬不要小看DNS,當你真正使用DNS做一些事情才知道DNS博大精深。其他比較重要的參考資料有:
  • RFC 1034(Domain Names - Concepts and Facilities)
  • RFC 1035(Domain Names - Implementation and Specification)
  • RFC 2136(Dynamic Updates in the Domain Name System (DNS UPDATE))
等等,還有很多有關DNS的RFC,請參考DNS RFC - Domain Name System RFC's (IETF)


###

熱門文章