人月神話讀後筆記


花了很多天終於看完了著名的專案管理聖經─『人月神話』
在此整理一下大致的重點

1. 開發一個軟體系統產品要付出的代價是一般組件程式的九倍。因為產品化是一般組件程式的三倍時間,設計整合測試又是三倍時間,這兩方面的成本計算基本上是獨立的。

2. 以成本會計為基礎的時程預估方式,使我們誤把工作量和專案進度混為一談,人月是一個危險並容易遭到誤解的迷思,因為他假設人力和工時可以互換。

在此本書裡面,提到,專案管理人員不應該把人/月這樣的標準來做為專案規劃的標準,因為當人員多起來後,整個專案的運行會需要花更多的時間在溝通、管理、協調上,人月之間的關係並非線性關係。

並且勿忽略掉新的程式師要學習上手的開發時間,以及要耗費掉的老手的教育時間。因此,在一個已經延遲的專案中增加人手,只會讓它更加的落後,這邊較建議的方式是重新安排時程、或者刪減工作。

在這一章裡,也提出建議的專案軟體時程安排方法

1/3 規劃

1/6寫程式

1/4組件測試和早期系統測試

1/4系統測試和完成所有的組件

3. 從第三章到第七章,都是在討論保有『整體概念性』的重要。

一個專案的規劃必需出由同一人之手,也就是說,一個專案不應該有兩個領導者。
我們必須選出一個能力強的人,來帶領整個專案的開發及方向,我們寧可忽略掉一些可能新奇、或很棒的想法,也必須讓整個專案都能呈現同一個設計理念。此一概念便是這本書所一直提及的整體概念性

在第三章裡,此本書提出了一個外科手術團隊的做法,來解釋該如何去達到這個整體概念性的目的。

(1) 首席程式設計師:也就是整體概念性裡所提到的做決策的主腦。負責定義功能、設計程式、測試程式並撰寫文件。
ps: 此本書也提到,真正優秀的專案管理人員,也應該要寫程式,沒有真正去撰寫一些程式的PM,是無法做好專案管理的工作的。

(2) 副手:外科醫生的分身,可以做所有首席設計師所做的事,或提出想法,但是首席設計師不一定要接納他的想法。

(3) 行政助理:幫忙處理首席程式設計師的所有庶務。一位行政助理可同時處理兩個以上團隊的工作。

(4) 文件撰寫人員、秘書(負責專案協調事宜及產品無關文件)、程式助理、測試員、語言專家、工具專家。

4. 第五章的地方,提到了第二系統效應,這個效應是指說,最容易失敗的專案,反而是我們第二個設計的系統,原因是加入了太多不相關功能。我們要慎防在設計第二個系統的時候過度設計(自律)。

5. 第六章在說意念的傳達設計必須出於同一人之手,那些有規範那些沒有應定義清楚。溝通方式包括:將定義(指規格書裡的定義)直接融入實作、開會(分為每週召開的會議、和公開大會,討論一些重大議題及無法預見的瑣碎事項)、多重實作(當規格與程式衝突時兩方都有可能要更改)、電話紀錄(現在可用email)、產品測試(專案經理最好的朋友)

6. 在第七章探討了巴別塔失敗的原因

(1) 充分的溝通十分重要

(2) 工作手冊的結構十分的重要,且每一位成員都應看到全部的文件內容

(3) 專案管理的權力結構應該要是樹狀的,也就是第三章所講的整體概念性,任何人都不能同時聽命於兩個老闆。而組織內的溝通結構則應該是網狀

7.  第八章是在討論專案時程預估要注意的點

(1) 員工只有50%的時間真正在寫程式

(2) 溝通時間應要納入估算

(3) 開發程式的類型不同以及大小之間的關係必須算進去。專案大小及費力程度大概是1.5的指數關係

8. 必須做好整體空間規劃,不單包括常駐空間的、背後有連帶關係的動作也應納入考量(ex: 記憶體分頁錯亂)
方法1. 確保大家的本事是真正通過程式設計的訓練而來
方法2.認知組件是去創造才有,每個專案都應有個手冊是專門蒐集關於佇列、搜尋、堆疊、雜湊(hashing)、Sorting的副程式且要有兩套方法,一個是用的空間最少的、一個是速度最快的。

9. 規劃軟體開發的文件:目標、產品規格、時程、預算、場地配置、組織編製圖

10. 把一次必然的失敗納入正式計劃之中(失敗是成功之母)

(1) 表格驅動技術:將設定值寫在表格檔案之中

(2) 軟體開發十分容易面臨無窮無盡的改變,因此 將改變量化,使組織利於改變

(3) 軟體測試在維護時期要用更多的資源(要做迴歸測試),也會需要進一步、退兩步,任何修改都有可能會破壞掉原有的軟體結構。

11. 第十二章在講開發工具的重要性,通常我們開發時的工具機器和最後程式要跑的目標機器是不一樣的,因此我們需要採用成熟的機器避免偶爾出現/偶爾正常的問題被忽略。程式語言的選擇也是工具的選擇之一,在這邊提到採用高階語言可以大量提高生產力。

12. 在專案開發中要如何避免錯誤的發生呢?在第十三章的地方提到了幾點重點

(1) 整體概念性的具備:也就是不同開發人員做出了彼此不協調的假設,具備了整體概念性的軟體容易使用、易於開發、也比較不容易發生錯誤。

(2) 規格審查:規格書應交給獨立的測試小組進行審查,而不應該給程式設計人員去審查

(3) 由上而下的設計方式:這是一種持續細分精製的步驟,先勾勒出粗略的工作定義和執行方案以得到主要的結果,然後做更深入的探討,看看跟我們真正要的東西有何不同。也就是把大步驟細分成幾個更小的步驟。

(4) 結構化程式設計:由Dijkstra所提出的最短路徑方式,在說由某一節點到另一個結點的最短路徑。

13. 要如何避免大災難的發生,有以下幾點:

(1) 里程碑應要明確、不模陵良可,要明顯到無法讓人自己騙自己,可以輕易查證

(2) 團隊應充滿幹勁,我們亦可提出計劃評核圖(PERT chart)或要徑時程表(critical-path schedule)來顯示什麼做完才可以做什,並告訴我們什麼事情是重要的需要先做

PERT chart
a:最樂觀時間 (Optimistic Time)為最短時間
m:最可能時間 (Most Likely Time)為適中時間
b:最悲觀時間 (Pessimistic Time)為最長時間

要徑的概念:通過網路最長的路徑,稱為要徑。若最長路徑的作業延遲了,整個專案就延遲,若要縮短專案完成時間,只要縮短要徑作業的工期即可。要完成專案,所有的路徑都必須通過。

(3) 避免隱匿不報的狀況發生:為了避免下面的人明知專案延遲卻不往上報的狀況,在組織上應降低角色衝突(老闆不應干涉部屬可以自己解決的問題),並且訂定一些審查技巧。

初探Hadoop開放原始碼平台環境

開放原始碼的雲端運算平台技術(1)

初探Hadoop開放原始碼平台環境
文/圖 沈炳宏.責任編輯/洪羿漣

大量資料的處理一直是電腦科學與實務應用中非常重要的課題,雲端運算的風起雲湧也使得分散式運算這項技術成了新顯學,整合MapReduce演算法並已被 各大企業所廣泛採用的Hadoop套件,更是開發雲端運算技術的佼佼者,本系列文章將會帶領讀者一步步瞭解並活用該技術。


近年來最熱門的雲端運算(Cloud Computing),其概念結合了IaaS、PaaS、SaaS、Web 2.0和其它相關技術(如MapReduce、Ajax、虛擬化),共同在網際網路架構上,來滿足使用者在運算資源的高度需求。目前雲端運算有各家專業研 究機構分別提出了不同的定義,如表1所示。

雲端運算不是一項新興技術,而是一種過去就有分散式運算(Distributed Computing)的形式,與代表多台電腦同時進行運算與叢集運算(Cluster Computing)的概念類似,皆是指透過整合大量電腦的運算資源來處理運算需求。

不過叢集運算多為硬體業者採用,強調同一資料中心中的大量電腦;雲端運算則納入網際網路的概念,由遠端網際網路上的伺服器群進行資料的存取與運算,由於這 些伺服器群可能分散在各處不同的資料中心,同時處理來自各地成千上萬使用者的需求,從使用者的觀點來看,根本無從分辨是哪一台伺服器處理了自己送出的運算 需求,如同把需求送入模糊的雲朵中一般,因此便將這種分散式運算模式稱為雲端運算。

諸如Google、Yahoo和Amazon等大型網路公司,由於財力雄厚,可以採購數以萬計的伺服器,叢集便成為一個龐大的運算資源,讓使用者得以透過 網路來存取資料或進行運算,而近年來爆紅的Facebook,也將Hadoop使用在分析Facebook塗鴉牆上某一關鍵詞出現頻率的Lexicon專案,以及改善使用者體驗、搜尋結果等功能上。

雲端服務 vs. 雲端運算
除了雲端運算這項口號之外,還有人提出了雲端服務的概念,這是由於雲端運算通常指的是在網路上提供且為商業和客戶服務的消費模型,這些服務包含了以資訊科 技為主的服務,如軟體即服務(SaaS, Software as a Service)以及提供伺服器運算及儲存能力的服務等,但實際上還有更多和資訊科技無關的商業和客戶的服務,如線上購物、銷售、娛樂等,而這些服務多半 與運算的功能無關,而更為貼近人們的生活,對這些客戶而言,他們所使用的不是雲端運算這項功能,而是由雲端運算環境所提供的雲端服務。

若要更明確的定義這兩者的區別,雲端服務專注在藉由網路連線從遠端取得服務,如提供使用者安裝和使用各種類型作業系統的Amazon EC2服務。這類型的雲端運算可以視為軟體即服務概念的延伸,利用這些服務,使用者甚至可以只靠一支手機做到許多過去只能在個人電腦上完成的工作。

雲端運算則是著眼於利用虛擬化以及自動化等資訊技術,來建構和普及電腦中的各種運算資源,這種類型可以視為傳統資料中心(Data Center)的延伸,且不需要經由第三方機構提供外部資源,便可套用在整個公司的內部系統上。

IDC研究機構則針對雲端服務和雲端運算提供了更清楚的定義,所謂的雲端服務應該有如表2的特性。

透過這些特性,可讓雲端服務的提供者和消費者享受到比起傳統服務遞送模式更為簡易且便宜的優點,這些特性可以降低花費,加速服務遞送的速度,簡化存取的方式,大量增加可用服務的數量和內容,並增進了服務整合性的可能。

雲端運算包含了六種特性,如表3所示;可提供的遞送模型則有SaaS、PaaS、IaaS等三種類型,如表4;部署模型則有私有雲、社群雲、公眾雲和混和雲等四種類型,如表5。

雲端運算架構
實際上雲端運算就是一種分散式運算的實作模式和概念,透過由網際網路所構成的「雲」中,以動態可擴展性和虛擬化的運算資源來提供Web服務,將龐大而複雜 的運算處理程序自動拆解成無數個較小的子程序,交由多部伺服器所組成的龐大電腦叢集進行分散和平行運算分析後,將處理結果回傳給雲端使用者。

對於這些雲端技術和基礎設施,使用者無須擁有專業知識和任何控制權,透過雲端運算,服務提供者可以在數秒之內,達成處理數以千萬計甚至億計的資訊,達到和超級電腦同樣強大效能的各式各樣網路服務。

提供雲端運算時,會涉及的軟體系統架構,通常涵蓋多重的雲端元件,這些元件會透過應用程式設計介面如Web服務來相互通訊,雲端架構會延伸至用戶端,讓用戶端的瀏覽器和軟體應用程式得以存取雲端應用程式。

軟體應用程式的設計,可透過網際網路隨需使用服務,以雲端架構做為建置基礎的應用程式,是一種基本的運算基礎架構,有需要時才會使用(例如處理使用者要 求);可以隨需獲取必要資源(例如運算伺服器或儲存設備)、執行特定工作,然後放棄不需要的資源,通常會在完成工作後自我處置。

透過雲端運算可以解決與大規模資料處理有關的重大難題,如:
●在不同機器上分配與協調大規模工作、在不同機器上執行程序,並在某一部機器故障時,提供另一部機器以供回復。
●根據動態工作量,自動調整所需資源。
●在完成工作時擺脫這些機器。
●取得應用程式所需的大量機器。
●在有需要的時候取得機器。

組成雲端運算的架構則如圖1所示,由下而上分別為基礎架構平台、儲存服務、平台服務、應用程式服務以及客戶端所組成。基礎架構提供了虛擬化運算、電腦叢集、硬體抽象化、虛擬化等硬體服務功能,以及可由使用者配置的運算環境作業系統、網路,記憶體、磁碟、CPU等設定。

圖1:雲端運算架構。

儲存服務表示雲端上的分散式持續資料儲存,其可能使用不具結構化的傳統式檔案系統來進行資料儲存,例如:HDFS、Key-Object pair、Amazon S3,或者結構化的資料儲存如Amazon SimpleDB、Google AppEngine DataStore;平台服務則是提供開發與執行應用程式服務的雲端平台,例如Google App Engine可讓開發人員在Google的基礎架構上,執行Web應用程式,其中也提供了Java與Python程式語言的執行環境,並完全支援通用的 Web技術與服務,以便用來執行MapReduce應用程式的開放原始碼分散式運算平台;客戶端則是仰賴雲端運算架構來執行應用程式服務,主要操作介面是 透過主流的瀏覽器,如微軟Internet Explorer、Mozilla Firefox、Google Chrome,以及智慧型行動裝置,如Android、iPhone、Windows Mobile。

接下來的文章中將會介紹由Apache所提供開放原始碼的Hadoop雲端運算開發環境,並分別探討在Hadoop中核心的Map-Reduce演算法概念,以及由Hadoop所延伸的HDFS、HBase、Pig、ZooKeeper等套件。

Hadoop簡介
Hadoop的原始作者是Doug Cutting先生,其過去就開發了Apache Lucene文字搜尋引擎,這是用Java設計的高效能文件索引引擎API,其可索引文件中的每一字,讓搜尋的效率比傳統逐字比較還要高的多,而在開發這個元件的過程,也進而開發了Apache Nutch這個基於開放原始碼所開發的網頁搜尋引擎元件。

其利用了Lucene函式庫開發,並加入了許多與網頁協定相關的特性,如網頁爬蟲(Web crawler)、網頁連結架構資料庫、HTML和其他文件格式的剖析器等,在Nutch 0.8版之後,Hadoop為獨立項目演變為獨立的Hadoop開發套件。

Hadoop這個代號並不代表任何英文字彙或者縮寫代碼,其是一個無中生有被創造的名稱,作者曾經針對這個名稱做過相關解釋,Hadoop名稱來自於作者 小孩的一個絨毛填充黃色大象玩具,而官方的吉祥物也採用了該圖案(圖2),主要原因在於開發這項套件的過程中作者需要為開套件提供一個代號方便溝通,而 Hadoop這個名字具備了幾個特性,如相當容易拼字和發音,毫無意義、且沒有在任何地方使用過,因此雀屏中選。

在Hadoop其後所發展的幾個相關套件和模組也都參考了這樣的方式,名稱都不會與主要功能實際相關,而會採用與大象或其他動物的概念來命名作為其開發代號,某些較小的模組功能則會給予較有意義的名稱,如jobtracker會用來追蹤MapReduct的作業。

其實Hadoop(圖2)命名的概念也非常類似當年Google命名的由來,Google是英文單詞「Googol」按照通常的英語拼法改寫而來的。Googol是一個大數的名稱,也就是10的100次方,表示1後面加上100個零。

圖2:Hadoop吉祥物。

乍看之下好像沒有特殊之處,但實際上該數字比宇宙所有的基本粒子數量總和還要大。Googol這個字是由美國數學家Edward Kasner九歲的侄子Milton Sirotta發明的,後來在數學家Edward Kasner和James Newman的著作《Mathematics and the Imagination》(http://tinyurl.com/lxunra)中被引用,Google公司使用這個字顯示了公司想征服網路無窮無盡資 料的夢想,最後沒有選用Googol可能是因為版權的問題,而且當註冊Google.com網域的時候已經被註冊。

Hadoop的定位是用來處理與保存大量資料的雲端運算平台,目前屬於Apache頂層專案,在Hadoop中包含了最著名的分散式檔案系統(HDFS)、MapReduce框架、儲存系統(HBase)等元件,如圖3所示,以及根據Hadoop延伸發展的其他子專案:
●Core:一組用於分散式檔案系統和一般性I/O之用的元件和介面。
●Avro:提供高效能、跨語言以及可保存資料的RPC資料序列化系統。
●Pig:超大資料集的資料流語言以及執行環境,可在HDFS和MapReduce叢集環境中執行。
●ZooKeeper:分散式且高可用性的協調服務,可為建置分散式系統提供分散式鎖定等原始鎖定功能。
●Hive:分散式資料倉儲,透過Hiave可管理存放於HDFS的資料,並提供根據SQL發展的查詢語言來查詢資料。
●Chukwa:分散式資料收集和分析系統,其會執行收集器以便在HDFS中儲存資料,且會使用MapReduce來產生報表。

圖3:Hadoop組成元件。

Hadoop主要核心完全使用Java開發,而使用者端則提供C++/Java/Shell/Command等程式開發介面,目前可執行於Linux、Mac OS/X、Windows和Solaris作業系統,以及一般商用等級的伺服器。

在Hadoop中最核心的演算法參考了由Google針對大量資料處理所累積的經驗,並於2004年所發表的MapReduce演算法,隔年Doug Cutting隨即公佈Apache Nutch開始採用全新的MapReduce實作。而在2006年Hadoop程式碼從Apache Nutch移至全新的Lucene子專案,2008年Hadoop成為 Apache頂層專案。

MapReduce
MapReduce誕生源由是Google需要進行大規模資料處理,而在這個過程中,發現了處理大量資料時會面臨某些共同問題,如需要使用許多機器協同計算,以及處理輸入資料時有兩項基本作業:Map和Reduce。

這兩項作業主要是受到函數編程的啟發,以Map/Reduce為基礎的應用程式,能夠運作在由上千台PC所組成的大型叢集上,並以一種可靠容錯的方式平行處理上P級別的資料集。

在函數編程中很早就有了Map和Reduce觀念,其實類似於演算法中各個擊破的作法(Divide and Conquer),也就是將問題分解成很多個小問題之後再做總和。Map函數的輸入是一個鍵/值序對組,輸出則為另一組中繼過渡的鍵/值序對組。而 Reduce函數則負責針對相同的中繼過渡的鍵/值序對組合併其所有相關聯的中繼值,並產生輸出結果的鍵/值序對組,如圖4所示。

圖4:MapReduce運算方式。

MapReduce則是由Google所發展的軟體框架,目的是對電腦叢集上的大型資料集執行分散式運算,讓使用者可以把心力放在定義Map和 Reduce函數,MapReduce框架會協調機器資源配置並處理的程式輸入、輸入與執行,所有的執行細節交由MapReduce框架處理。透過 MapReduce可以用於大型資料處理,例如:搜尋、索引製作與排序,大型資料集的資料採礦與機器學習,大型網站的網站存取日誌分析等應用。

HDFS
HDFS的設計理念是在分散式的儲存環境裏,提供單一的目錄系統 (Single Namespace),一個典型的超大型分散式檔案系統中,通常會有數萬個節點、數億個檔案、以及數十Peta Bytes的資料量,而這樣的分散式檔案系統具備的資料存取特性為Write Once Read Many存取模式

也就是檔案一旦建立、寫入之後就不允許修改,在這之中,每個檔案被分割成許多區塊(block)與異地備份,每個區塊的大小通常為128 MB,系統會將每個區塊複製許多複本(replica),並分散儲存於不同的資料節點(DataNode)上。

除此之外,HDFS中很重要的概念是其認為移動運算到資料端通常比移動資料到運算端來的成本低,這是由於資料的位置資訊會被考慮在內,因此運算作業可以移至資料所在位置,處理資料的檔案複本預設是每個檔案儲存3份,該設定可由開發人員自訂。

HDFS採用的是一般等級伺服器,因此透過複製資料的方式以因應硬體的故障,當偵測到錯誤時,即可從複製的備份資料執行資料回復。圖5所示為HDFS架構,未來會陸續在專欄文章中進行更深入的HDFS探討。

圖5:HDFS架構。

HBase
簡而言之,HBase的目標是作為Hadoop所使用的資料庫,這可讓我們需要在隨機且即時的讀寫超大資料集時所使用。HBase是一種分散式儲存系統, 其類似RDBM資料表的資料結構(Multi-Dimensional Map),並具備高可用性、高效能,以及容易擴充容量及效能的特性。

HBase適用於利用數以千計的一般等級伺服器上,來儲存Petabytes級的資料,其中以Hadoop分散式檔案系統(HDFS)為基礎,提供類似Bigtable的功能,HBase同時也提供了MapReduce程式設計的能力。

在HBase中使用了和Bigtable非常相似的資料模型,使用者在資料表中儲存許多資料列,每個資料列都包括一個可排序的關鍵字,和任意數目的資料列,資料列的格式會以:

所有的更新操作都有時間戳記(Timestamp),HBase對每個資料列單元,只會儲存指定個數的最新版本。客戶端可以查詢從某個起始點的最新資料,或者一次得到所有的資料列版本,圖6所示為HBase架構,未來會陸續在專欄文章中進行更深入的探討。

圖6:HBase架構。

小結
將服務搬到網際網路已逐漸為現今各資訊服務業者的共識,因此,本土軟體業者在研發新的軟體產品時,應以雲端服務的方式進行產品研發,至於早就出現在市場且系統功能趨於成熟的軟體產品,如企業資源規劃(ERP)等系統,則應視狀況開發出一套可於雲端執行的版本。

發展雲端運算及雲端服務是台灣軟體業者走入國際舞台及擴大市場占有率的捷徑,雲端服務市場的崛起將會是未來1、2年的事情,台灣軟硬體業者能否立即投入該 市場,將是決定其能否在該市場占得一席之位的關鍵。透過Hadoop的協助,開發人員將無須深入瞭解分散式運算應用程式所需的各種知識,僅需要將大量資料 和解決方式實作Map和Reduce,快速建構出雲端運算的執行環境和服務。

【原文刊載於RUN!PC雜誌:2009年11月號】

在flex裡內嵌字型

在flex裡內嵌文字有幾種方式
1. FLEX 動態更換中文字型 ( 非嵌入方式 )
這個請參考下面這篇的教學
http://blog.corausir.org/programing/ausir-777
不過上面的方式 必須以PHP配合
並且空間要支援PHP的EXEC呼叫外部EXE檔的功能
許多空間伺服器並沒有支援這個功能
另外我在測試時也發現一個問題
就是當我要產生的文字過長(ex: 400~500字)
會發生讀取錯誤的問題

2. 直接內嵌字體
(1) 使用css

(2)使用as3嵌入

直接嵌入文字會遇到一個很大的問題,就是文字太肥了,
這時,若我們只需要嵌入該字型檔的部份字型,而不需要全部嵌入
就可以設定unicodeRange
例如下面的範例

可以只嵌入部份的文字,
若我們希望只嵌入中文字的話,則可以參考flash-unicode-table.xml裡面
有一般文字檔案的unicode編碼字集範圍
這樣可以大大改善embed文字造成檔案過大及編譯過久的問題了!

參考資料: http://hi.baidu.com/sitoto/blog/item/12528ab1124a345c0923028b.html