Uncertainty 不確定

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

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

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

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

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

###

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」一書的用心翻譯出版，讓我們有機會輕鬆閱讀這本經典著作。
###

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.

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

###

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)」給喜歡追根究柢的人！

###

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第五版。
###

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. 混合雲：公有雲和私有雲的混合。

敘述了這們多資訊，這也只是「第一章 雲端運算概論」的內容而已，若各位想清楚瞭解何謂「雲端運算」，這本書的確說得夠清楚有系統！

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

###

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很帥的一張相片！

###

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)。

###

PHP Debug

記錄PHP除錯心得，通常使用PHP開發網頁應用程式(Web Application)時，為了看到變數的值，我們會使用echo和print(陣列用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玩玩吧！
###

View

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

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

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

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

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

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