程式設計師最討厭的工作，並不是撰寫難度很高的程式，而是維護一堆缺少完整文件又長得醜的程式。尤其現在能具備完整文件的系統專案已經少得可憐，所以美化 程式碼的要求才會日益增高，如果能做好基本功，即使沒有文件輔助，工程師也能輕鬆追蹤程式碼。不過，要寫出好的程式碼是需要功力的。

Beautiful Code＝專案問題最佳解法

要寫出完美的程式，需要透過實務經驗或前人智慧，一點一滴累積實力，並非一蹴可幾。但軟體專案常因時程要求，在系統開發上只求在時限內達到目的，往往忽略軟體工程上強調的重點（例如物件導向的觀念、設計模式的運用等）。

書名中的「Beautiful」一字，代表著解決程式難題的最佳撰寫方法，這些解法是專家在執行專案及設計系統架構的過程中，不斷地累積、歸納、 整理而得出，等同於系統設計好手們常高談闊論的設計樣式（Design Patterns）。閱讀本書，就如同站在巨人肩膀上，瞭望整個軟體開發世界，透過高手的文字描述，洞悉他們面對軟體專案發生問題時，如何思考出解決方案 的過程。

本書內容構成十分有趣，透過作者Greg Wilson的召集，將業界大師級的軟體設計師及科學家統統拉進來，貢獻出畢生所學，集結三十餘篇的文章，簡短且精闢的文字流露著專業及縝密的思路。本書 作者所有出版收入均做為公益之用，捐獻給國際特赦組織（Amnesty International）。

既然稱為程式「設計」，當然也需要融入美感。要寫出具有美感的程式，讓人稱為藝術之作，除了需要掌握程式語言本身的特性，多看、多研究高手的作品 之外；也要如同寫文章一般，具備足夠的知識、打好基礎，才能夠文思泉湧，寫出好的程式，就如同本書Ruby之父Yukihiro Matsumoto所提到的觀念：Treating Code As an Essay。

除了要Beautiful Coding，Beautiful Debugging也是一門學問，在開發過程中，除錯常是影響程式撰寫能否順利進行的關鍵。透過系統化流程處理程式錯誤的偵測，並有效找出問題徵結，才能有效率地在最短的時間內完成除錯。

想知道有經驗的專家們，在面臨軟體開發的難題時，如何發揮智慧迎刃而解？本書如同論文集般，收錄各領域技術大師的文章，以各式各樣的案例，搭配不 同的程式語言呈現多元化的應用。像是以極簡的正規運算式（Regular Expression）語法，比對複雜的檔案內容或應用在搜尋網站系統記錄檔內容；以Perl提供的現成Bio套件，辨識生物科技基因；利用NumPy快 速處理多維度的陣列資料等。

用對程式語言，才能事半功倍

一個系統或程式，可以用不同的程式語言撰寫，各家寫法也大不同。因此，需要考量到程式語言本身的特性，選用適合的語言開發。針對各種目的，運用不同的程式語言實作，不但能發揮該語言的優點，程式也不致過於繁雜，增加閱讀及日後維護的困難。

本書不限定於探討單一特定程式語言，包含XML、Ruby、Linux等，涵蓋領域很廣。從NASA太空總署專案，到作業系統核心設計等主題，你 可以從不同角度體會各類應用。雖然有許多案例是一輩子都不可能參與的專案類型，但都能從專家的經驗分享中，獲取這些程式撰寫技巧。

就實務而言，軟體專案時程的不合理壓縮已經成為常態，身為程式設計的一員，更應該以撰寫漂亮的程式碼為要務，在有限時間之內發揮最大的設計價值。

如何撰寫漂亮的程式碼？本書作者歸納整理出以下建議：程式碼需內容簡潔（brevity）；穩健低風險的方法（conservatism）；擁有 變更之彈性（flexibility）；並在這些特性之間取得平衡（balance）。如果你能夠掌握這些原則，再透過閱讀本書，思考咀嚼出一番心得，相 信你撰寫的程式碼，便能夠美得內外兼俱！

網站的視覺設計及內容，是能否吸引訪客的重要因素之一，但也不能因而顧此失彼，造成網站效能的瓶頸。從過去的訪客行為研究 分析指出，等待一個網頁的呈現時間不能超過9秒鐘，但面對目前網頁內容多媒體化的現實挑戰，要達到這樣的目標，在前端頁面的設計上，也就需要多花些心思。

著重網頁前端的效能改善

《High Performance Web Sites》內容主要針對網站前端的設計人員所設計。作者曾經擔任雅虎CPO（Chief Performance Officer），在雅虎負責研究改善網站效能的方法，他以多年的經驗整理出14個網站前端設計需要注意的準則。全書內容簡明扼要，具有網站設計經驗的讀者，可以快速領略要點；初次接觸的生手，也可以透過本書建立良好的網站設計觀念。

14條必勝定律

如何有效提升網站效能？作者針對網站效能最佳化歸納出以下方針，並舉例加以說明：

1. 減少需要發出HTTP Request的數量

當你設計的網頁中包含的元件數量越多，Client需要對網站伺服器發出的HTTP Request也會增加，同時也會延長網頁處理的時間。

2. 採用Content Delivery Network服務

由Mirror Image、Akamai、SAVVIS等業者所提供的Content Delivery Network（CDN，內容遞送網路服務），可以供應強大的全球網路基礎架構，將網站以最有效的方式傳送給全球使用者，並自動幫網站選擇最佳路徑傳送資料，例如，根據瀏覽者所在地、網路品質及流量狀況，選擇距離用戶端最近的資料中心傳送資料，確保網頁的瀏覽品質及運作速度。

3. 在網頁中加入過期檔頭

你可以利用這個設定讓網頁具備快取機制，縮短頁面載入時間，尤其是針對內容不常變動的網頁。當然這樣的運用，得視你的網頁性質而定，若內容變動頻率高的網頁，則不適用此方式。

4. 善用Gzip壓縮機制

以XML/HTTP做為資料交換的開放格式已經十分普遍，傳輸的檔案體積，較過去單純的EDI方式增加許多，用傳送壓縮時間換取傳輸時間，也是一種提升效率的策略，目前常見的網站伺服器大都支援此項技術。你甚至也可以視情況選擇壓縮HTML、CSS及JavaScript的檔案內容。

5. 將Stylesheet置於網頁頁首

將樣式表（Stylesheet）置於頁首，可以讓CSS設定先行載入，在第一時間套用設定直接呈現網頁。相較於把樣式表放置在頁尾，等所有內容都下載完畢後才套用，樣式表置於頁首的作法，除了頁面呈現速度較快，載入過程中也較不易造成空白頁的出現。

6. 將Script內容置於頁尾

許多實際狀況中，網頁包含的Script程式，本身並不需要在載入後立即執行，所以作者建議將這些程式碼置於頁尾，至少內容可以在傳輸前段時間即備妥，讓使用者有較佳的瀏覽體驗。

7. 避免CSS Expression的撰寫方式

CSS Expression的目的，在於讓自訂樣式的語法可以取代部分的Script內容，雖然這麼做很好用，但因網頁顯示過程中花費較多的邏輯判斷時間，造成網站效能的致命傷。

8. 將JavaScript及CSS內容獨立於網頁內容之外

透過獨立內容的方式，讓HTML本文檔案縮小，而且可以同時被瀏覽器下載，以縮短網頁呈現的時間。

9. 減少DNS查找的次數，縮短取得網頁內容之前的前置時間

雖然網頁可以串連不同網站來源的內容，但是不同網站來源的內容一旦太多，便會延遲頁面載入速度；如果能夠減少網頁內不同網站來源的內容，就可以減少從用戶端發出的DNS Request數量，縮短DNS的查詢時間。

10. JavaScript內容精簡化

網頁中的JavaScript也是下載的一部分，所以當程式碼內容較多時，亦會直接影響網頁下載的速度。檢視一下程式碼，移除不必要的部分。

11. 避免重導向

網頁重新導向是很方便的功能，但對於使用者而言，他必須等待更多的時間直到最終頁面被載入，所以應該盡可能避免使用重導向轉址功能。

12. 移除重複的Script程式碼

重複的Script程式碼需要花費更多的下載時間，這個問題通常發生在程式碼未能妥善模組化的情況下，檢查一下你的Script程式吧。

13. 善用Etag

透過設定Web Server中的Entity Tag方式，能決定網頁中被快取的內容，以加速網頁呈現，但也得視網頁內容特性而定，Etag主要運用在靜態頁面上，而動態顯示內容的網頁則不適用此方式。

14. 讓Ajax程式可做到暫存快

Ajax架構透過非同步的傳輸方式，讓使用者具有較佳的使用體驗，卻不見得是效能的保證。除了可以透過利用Gzip壓縮、避免DNS查找次數、簡化JavaScript內容之外，控制HTTP過期檔頭來快取Ajax網頁，也能發揮明顯效果。

拿知名網站開刀，保證你大呼過癮

本書最後以全球十大網站做為案例分析的對象，包括Yahoo、Google、Amazon、YouTube等。這些網站之所以成功，除了透過內容及社群機制吸引訪客，在網站效能的表現上，也必須克服流量提高所帶來的問題。

作者使用3個度量值（Page Weight、Response Time、YSlow Grade）逐一檢視這些網站，找出問題點以及可以改善的地方，配合前述建議的14項準則，解決效能表現不佳的現象。

作者表示，這些準則都經過實務證明為有效的解法，可以幫網站減少平均二至三成的網路傳輸時間。對照本書，檢視你的網站架構出了哪些問題，並對症下藥加以落實，我相信可以讓訪客感受到明顯的效能提升。

專案進行的過程中，階段性的文件產出（Deliverables）一直是被視為十分重要的一環。而許多專案也常常將文件列為重要的驗收項目之一，筆者曾經 手接受兩大箱的系統文件要求驗收，可能這樣客戶端才會覺得付了錢，獲得拿到東西的滿足感吧。還真懷疑這些人到底會不會看這些文件。

先不論客戶是否會看，文件內容必須符合實務需求，才能夠在真正需要的時候發揮參考價值，如果只為了驗收交差了事，而硬擠出一堆不具任何參考價值的陳腔濫調，還不如響應環保，少砍點樹比較好。

文件應重「質」，而非「量」

針對專案文件的規範，在許多系統分析設計的參考文獻中都能找到不少範例，如果你採用物件導向分析及設計方法，UML系列的文件必然也不陌生。

就實務面來看，許多專案因時程及人力不足的雙重壓力下，一人球隊從頭到尾「校長兼撞鐘」的悲慘案例，已不再是什麼稀奇的事，文件撰寫常常變成事後補件的作業程序。所以，目前專案的當務之急，是提高文件品質而非數量。

《Communication Design》希望從事網站設計開發專案的相關人員，能花對的時間在對的文件上。在規畫網站設計專案過程中，本書針對專案進行過程中的3種不同角色設計， 包括文件製作者、文件審核者，到最後文件使用者。在文件的架構及撰寫用意上，本書則提出三層式資訊表達方法，依文件內容的詳細程度，分別適用3種不同的閱 讀需求。

提供多種文件撰寫綱要及範本

本書針對3類用途列出10種文件，分別著重在使用者需求文件（User Need Documentation）、策略性文件（Strategy Documentation）以及設計文件（Design Documentation）。

● 使用者定義文件（Personas）：定義主要使用者（Stakeholder），並清楚描述他們會如何使用這套系統。將所有可能會使用網站的使用者都列進來，在設計流程及測試過程時會更完整。

● 可用性測試計畫（Usability Test Plan）：系統上線前必然經歷測試的項目及方式過程，定義這些內容之前，針對網站對於不同對象的使用方式均需要充分了解，才能掌握正確方向。

● 可用度報告（Usability Report）：針對上述的計畫執行後所產生的報告文件。

● 競爭力分析（Competitive Analysis）：就網站而言，競爭力分析等於是與其他競爭對手的優劣比較分析，從網站內容、提供的產品服務以及使用者經驗比較。

● 概念模型（Concept Model）：在系統分析中，在概念上定義出與系統有關的物件及彼此之間的關係，後續系統分析設計的主要基礎得以紮穩。

● 資訊內容（Content Inventory）：呈現網站的資訊架構及分類方式。

● 網站地圖（Site Map）：這應該是最常見、也最基本的網站階層架構示意文件，讓網站規畫人員與設計人員可以明確得知，每個網頁的內容及功能之間的關連性。

● 網站流程圖（Flow Charts）：架構是靜態的呈現，透過流程圖能分析使用者使用網站的行為動線，以及例外狀況處理。

● 視覺版面設計（Wireframes）：使網站主要內容的樣式及視覺化呈現具有一致性，包括版面格局、圖片色系的制定、文字內容。

● 畫面設計（Screen Design）：在許多系統設計方法論中，畫面的呈現設計一直被視為與使用者溝通的重要文件內容。唯有使用者看到實際的畫面，才有辦法確認設計的成品是不是他所想要的，並且降低認知上的差異。

審視、最佳化手邊的系統文件

上述文件，在本書都有專章說明如何撰寫，包括文件所應具備的文件大綱，而讀者在撰寫的過程中，必須與其他文件之間相互參照，例如在進行畫面設計時，也需要同時參照概念模型內容，以維持文件資訊的一致性。

也許你手邊已經有不少系統文件規範格式，但本書可以當作檢視既有文件完整度的工具，讓文件更臻完美。

在軟體專案運作期間，團隊成員經過長期高壓折磨後（請容許筆者用這樣的形容詞，但軟體專案確實是個壓力密集度高的工作），團隊成員會出現腦力疲乏、反應不佳、情緒偶有失控、思緒無法有條不紊地運作的症狀，就像顆電力被消耗殆盡的電池，執行效能處於殘弱的狀態。

專案成員理應經常充電，以保持良好的使用效能。企業不斷地倡導從A到A+的觀念，套用在資訊軟體專案中，專案團隊也會遭遇到相同的問題：你要選擇向上提升，抑或向下沉淪？

想要向上提升，你可以選擇透過坊間的充電課程提升戰力，不過，對於大多數企業而言，課程需要的成本及耗費時程，無法允許已經忙到抽不出空的軟體專案團隊去充電，使得教育訓練大多落於理想而難以付諸實現，造成專案成員異動頻繁，軟體專案品質嚴重低落。

就管理技巧而言，「從作中學」是學習專業能力及養成經驗效果最好的方式，也就是所謂的On-Job Training。《Agile Retrospectives》即強調從工作中來學習、強化你的專案團隊。

作者設計許多演練的方式，只要按表操課，相信會有不錯的效果。閱讀本書可以有助於：

● 設計出有效的專案團隊實戰準則
● 學習找出專案問題，進而思考得出最佳解法
● 試著強化團隊的優勢，發揮超出預期的團隊績效
● 不只是強調技術專業能力，也重視人在團隊中可能的影響
● 有效運用建議的管理技術及方法

往覆式開發讓專案開發保持在正確方向

Retrospective就字義上而言，著重在過去事物的回顧及反省，以記取過去的經驗，有「知古推今」、「前人種樹後人乘涼」的味道在。

運用在軟體專案上，則代表曾經在專案中遭遇的技術及管理難題、團隊成員間有待改善的合作方式，或是未臻完美的專案成果及實務教訓，這些都是身為專案領導者或成員的你，在過去專案經常遇到的問題，以期在未來能找出改善的做法。

也許你也有這樣的經驗：在執行專案的過程中，面對眾多管理或是技術上的抉擇時，會有「這樣做是不是最好？」、「這樣做是不是對的？」的疑惑。在專案邁向下一個階段時，也不斷地思考，如何在眾多做法中找出最佳方案。

一般傳統式專案開發都是到執行末期才發現問題所在，這時候早已回天乏術、付出慘痛的代價。但透過Agile往覆式開發精神，在專案各個階段結束時，即可以 針對問題進行改善，持續修正方向直到專案結束，不會等到整個專案結束後，才能回顧與檢討。因此往覆式的專案開發所造成的偏差，遠低於傳統式專案開發。

5個步驟將管理技巧導入專案開發

本書重點在於讓軟體團隊可以在專案進行過程，透過作者建議的工具及方法降低失敗機率。敏捷開發的迭代式開發特性，可以讓專案成員在進入下一個Iteration時，發現問題並及早因應，提出改善方法。

本書有5個步驟，從設定目標、收集資訊、激發想法、決定做法、到最後的結束，這些步驟是經歷實務考驗的累積成果。各個步驟都提供許多活動 （Activities）以達到每階段的目標，從這些活動你可以學習許多管理實務上的技術及方法，例如：用來找出問題根本原因的魚骨圖 （Fishbone）、找出多個面向計量標準的雷達圖（Radar），以及利用3M便利貼及色點貼紙收集資料及定義重要性，這些都是可以被應用在不同層面 的通用方法。

本書提供不少管理層面的技巧及作法，讓專案團隊可以透過敏捷開發搭配管理技巧，改善團隊績效、發揮潛力。雖然本書強調的是管理技巧與敏捷（Agile）專案開發製程的搭配，不過它提供的準則及方法，也都適用於一般專案團隊。

談到如何設計出以使用者為中心的網站，你不能錯過在Web Usability領域享譽盛名Jakob Nielsen的作品，在這位大師的眾多著作中，針對Web設計及可用度研究領域的《Prioritizing Web Usability》，是設計網站時不可或缺的參考工具書。

Web已是大眾廣泛接受的操作方式

應用程式Web化已經是系統設計演進發展的趨勢，不論是開放式或企業內部的應用系統，為求異質系統間的高度整合性，Web-based已經是系統設計的首選。加上大多數的使用者已經熟悉Web平臺的特性，點選超連結的行為及網頁呈現方式，對於現今使用者是十分直覺的動作。

目前硬體、寬頻、軟體技術等條件以及資訊環境，已經跟上內容複雜的需求，網路人口大幅成長，這些使用者不只是單純的資訊接收者，同時也是資訊提供 者（透過文字／影音部落格，C2C拍賣交易平臺等數位媒介發布訊息），全球網站的數量及資訊內容已呈現爆炸性的成長。如果網站設計得不夠人性化，便無法加 強對使用者的黏度。

本書根據近年來網路在使用及技術上的發展趨勢，彙整作者所在公司過去所完成的研究調查報告，建立紮實的實務統計數據，並強調如何從可用性 （Usability）的角度提升網站設計的層次，讓使用者能更快速且有效地使網站達到他造訪的目的，包括資訊提供、商業交易及服務取得等。

Web設計老問題依舊存在

Web發展至今已經十餘個年頭，雖然技術演進上已經有大幅度的成長，但一些積存已久的問題並未因此而減少：

● 彈跳視窗（Pop-Up Windows）的不當使用，造成使用者反感。
● 套用CSS效果使得超連結點選後未改變顏色，浪費使用者時間。
● 點選連結後未在原視窗呈現，而是開啟新的瀏覽視窗，破壞瀏覽動線。
● 破壞了「回上一頁」按鈕的原本功能，使用者需重新輸入資料。
● 提供密密麻麻的資訊內容，使用者無法在最短時間內找到所需資訊。
● 內容設計讓使用者覺得像是廣告，而忽略不去留意。

資訊基礎建設的興起，常會讓一些設計問題被隱蔽而未突顯，例如Flash動畫、Table版面配置等設計如果濫用過度，便成為網站效能的殺手。

透過設計問題模式，為網站體檢

針對網站設計常見的問題，書中將其優先順序一一列出，供讀者依序審視及處理：

● 搜尋功能：避免該查的資訊查不到，不該查的，跑一堆出來。
● 網站的資訊及導覽架構：使用者是否能在最短路徑找到他要的東西。
● 內容的簡潔及易讀性（包括文字、圖片、其他多媒體內容）：不會有訪客願意多停個幾秒，去猜內容是否有隱含寓意。
● 網站上產品元素的完整性，是否能有效促成交易的實現。
● 是否有足夠的網頁寫手，能幫網站豐富內容。
● 在使用者需求及技術層面上取得雙贏的局面。

也許會有讀者表示：「網站架構（SiteMap）及頁面流程通常都是由行銷人員規畫後，請視覺設計人員將頁面框好，再交給我們套程式，所以IT人 員在整個設計規畫的過程中並沒有主導的地位。」不過話說回來，同事在未考量使用及技術層面的可行性之前，所提出的天馬行空式網頁需求，身為IT人員的你， 必定常常會遇到。本書能讓行銷同仁們在需求與技術之間取得平衡，提出符合Web Usability的網站企畫書。

要求所有訪客都依照你的設計方式使用網站，是本末倒置的想法，在網站功能日益複雜的同時，你無法預測使用者的行為，任何的網頁流程都有可能被點選或使用。當你規畫、設計的網站，不需要透過大量的頁面說明文字或手冊協助使用者操作，網站就算是成功了。

若你也像筆者一樣，以逛大賣場為假日主要消磨時間的方式，應該會有自己偏好的去處（像是大Ｘ發、家Ｘ福、Ｘ買……等）。這些賣場吸引你持續消費的原因，可能是商品的價格，可能是現場商品陳列的方式以及實際逛的感覺，也有可能是停車的方便性，或是紅利點數的誘因。

最近中元普渡造成賣場人潮洶湧，因此，賣場購物動線是否順暢、人手一輛購物車會不會造成通道壅塞、特價商品的標示是否明顯到能被顧客快速找到、結帳櫃臺是否夠多，或者是結帳流程是否夠快速，不讓顧客大排長龍等因素，突顯出賣場的整體規畫設計是否適當的問題。

賣場規畫與網站設計概念如出一轍

同樣地，賣場規畫的觀念也可以套用在網站設計上。例如訪客在瀏覽網站的過程中，網站是否提供良好的導覽說明及連結，能迅速地指引使用者快速找到需要的資 訊；資訊內容是否以組織化方式呈現，並依相關性串連整合資訊；在流量尖峰時刻能否保持良好的效能表現。這些考量在在顯示出網站的規畫是否能夠符合使用者需 求。

以往網站設計的書籍，絕大多數著重在談論視覺版面構成、網頁技術或是程式端的開發細節。《The Design of Sites》作者歸納整理全球許多知名網站的設計方式及原則，涵蓋跨產業不同功能型態的實例說明，分析每個案例網站設計上所面臨的問題，並擬定可行的改善 方案供讀者參考。

本書目前發行至第二版，距離前一個版本已經間隔4個年頭，這段期間網路世界已有大幅變化，新技術的問世對於網頁設計方式亦有所衝擊。因此，新版內 容增加17個設計樣式，包括目前盛行的部落格（blog）；另外，針對影響網路使用行為甚鉅的Ajax技術，以及行動通訊的應用．也在本書探討範圍之內， 目的都在設法讓網站設計能結合最新網路相關技術而發揮綜效。

利用網站設計樣式，解決設計問題

談到設計的課題，就免不了會討論到架構上的網站設計樣式，這裡談的是Web Design Patterns。設計樣式是針對過去一些成功經驗所歸納出來的設計理念及最佳實踐方案，讓後人可以依循參考並降低失敗的機率。

設計樣式可以視為設計端與使用端的共同語言，使網站設計者與實際的使用者彼此的想法趨於一致，如此一來，網站不需要多餘的文字說明，造訪者就能夠直覺地了解到網站所要傳遞的訊息及重點。

本書在設計樣式上依功能需求分為幾大類：如何建立網站導覽框架讓瀏覽更簡易、內容管理機制完整的設計方式、提高網站可信度的作法、電子商務型態網 站的建議方案、協助使用者完成特定工作的功能網站、提供快準狠的搜尋機制、設計高效能的網頁版面等。這些大類之下都再細分出數個實作時的設計細節，方便讀 者針對需求查詢、閱讀。

在網站設計的過程中，如果能試著找出真正的客群，甚至讓他們也能參與網站設計，才能使網站的設計方向真正符合使用者的想法。本書也有專章討論這些提高可用度的方法，讓網站企畫設計人員更能規畫出符合使用者的內容。

設計使用者導向的網站，為本書中心思想

設計一個網站不難，但要設計出一個好的網站，讓你的目標訪客可以樂在其中，並認同網站提供的價值則是另一門課題。目標訪客可能會因為你的主業及營 運內容而有所不同，但是，提供良好互動介面，同時提供有形價值給你的訪客，這樣的終極目標是不變的。針對不同特性的使用族群，所使用的設計樣式也會不同， 本書提供了近百種的設計樣式，教你提供對的資訊給對的對象。

本書主要針對行銷人員及網站企畫人員所寫，內容並非在鑽研網站開發所需的技術細節，而是著重在如何透過標準的設計開發流程，利用由眾多知名網站驗 證出的良好設計原則，設計出以客戶導向（Customer－Centered）為核心概念的成功網站。你可以透過本書，回頭審視已經設計的網站是否有本書 提到的問題，或在未來規畫新網站時奉為圭臬。

記得十多年前建置網站時，由於當時網路環境還未普及，加上大部分使用者仍以數據機撥接上網，所以網頁設計人員對每個網頁的內容及大小，可說是已經到了錙銖 必較的地步，希望以最精簡的方式呈現最多元的內容，包括HTML程式中的語法、圖檔的壓縮格式或版面的切割方式，都會被一再要求。

反觀現在任何一個Flash檔案，往往將近幾百KB甚至超過MB般地奢華，圖檔也不特別最佳化處理（常見於行銷導向的活動頁面上），像這種網頁在過去可是會被前輩們斥責的。

正巧最近筆者公司因為進行系統上線，相關效能問題一直受到不斷地討論著，針對網頁的部分，恰巧找到一套網頁效能的測試工具，它提供的分析報告可以 剖析網頁組成元素，提供許多效能相關數據，接著又找到《Speed Up Your Site》這本書。在閱讀過程中，我發現，書中許多設計觀念並沒有隨著時代、技術的演進而過時，所以推薦這本書給網頁設計人員。

讓研究數據告訴你「快」的定義

讓使用者傻傻盯著空白網頁等結果，是很不明智的（除非你是弄個1元搶購Wii的活動，那就另當別論），畢竟只有極少數的訪客會如此堅持，如果你忽視他們的感覺，網頁下載過慢卻不設法解決，導致訪客快速流失，將會是你要面對的問題。

網站要多快才算好？要在幾秒之內完成網頁呈現，使用者才會滿意？

這些問題一部分涉及到使用者的心理因素，一部分與網頁的呈現方式及設計流程有關。《Speed Up Your Site》第一部分討論網頁回應速度的可接受值，針對這個魔術數字，書中談到不少相關的學術研究報告及理論依據，作者提出設計者應留意網頁的大小，透過適 當的訊息回饋以減少訪客跳離率；當頁面資訊量較多時，作者也建議從流程面的設計來改善，例如：提供清楚的導引及回饋訊息，減少不必要的動態效果及內容，以 直接清楚的方式提供使用者應該獲得的資訊。

各式各樣的網頁瘦身技巧

在網頁設計上，HTML語法能否妥善使用，對於網站效能的提升也是關鍵之一，而本書第二部分深入討論HTML相關技術，作者特別提供通盤體檢網頁的方式，改善HTML結構達到最佳化。

另外，網頁的組成，除了上述的HTML外，CSS與JavaScript也是不容忽視的重要角色，由於CSS與JavaScript是透過程式產生動態效果，若設計不良，便會造成速度上的瓶頸。

增添效果的圖片及多媒體元件，如果設計不當，同樣也會直接影響到整個網頁的大小，進而延遲下載及呈現的速度。書中提供了針對各種圖片檔、影音檔、PDF檔等多媒體格式的最佳化方式，讓你掌握如何在網頁視覺呈現效果與多媒體檔案大小之間，取得平衡點。

在進階技術方面，針對如何讓你的網站在搜尋引擎上具有較佳的排名，伺服器端的程式開發技術，以及將壓縮技術應用到網站上的不同技巧，本書也有專章討論，加上Yahoo.com的案例研究，這些議題都有助於網站的瘦身。

養成良好設計習慣

隨著網路頻寬的升級，光纖到府已經逐漸深入大多數使用者的家庭，網站瘦身的必要性似乎不高，造成現在的網頁程式設計人員，在這方面的功力及觀念也就相對缺乏，往往在網頁設計初期無法意識到潛在風險，都是等到問題爆發時，站方才回頭抽絲剖繭找問題所在。

針對這樣的窘境，本書著重於建立良好的網站設計觀念，不單純討論如何做，而是強調如何做得好。作者提出的論點都是歸納分析自相關研究統計報告，具有強力的理論依據。這些設計建議可能是你平常所忽視的，所以，在你的使用者還沒反應問題之前，先將你的網站來個全身健檢吧！

你應該對於Flickr網站中可以直接在圖片上選定範圍，註記說明的酷炫特色印象深刻吧？以往你認為需要透過JavaScript才能搞定的功能，是否想過可以輕而易舉地達成？CSS（Cascading Style Sheets）是包括字體、顏色、排版所發展出來的網頁樣式技術，至今已發展到第三版，其強大功能可以大幅取代許多傳統開發方式。

先前收到朋友轉寄的一個推崇CSS技術的網頁，以鮮明的漫畫手法強調CSS的好處，文中提到一些思維，著實讓筆者對CSS有了全新的看法。該文作者強烈摒棄以往以表格方式排版，認為這是不明智（其實是不客氣地評為愚蠢）的作法，尤其是在複雜度較高的版面時，不僅容易造成HTML檔案過度肥大，而且網頁呈現效能也相對受到影響。

CSS無所不在，就怕你不用它

在強調使用者介面至上的當代，CSS隱然已成為網頁技術的重要利器，市面上常見像是部落格平臺的版面配置、Webmail電子郵件信箋的選用，以及個人化網頁的樣式設定功能，以達到風貌切換而內容不變的效果，幾乎都是基於CSS技術所發展出來的網頁應用。由於視覺化的設計已經是網頁程式中重要的一環，透過妥善運用CSS屬性，除了能在網頁中呈現完全相同的效果外，還有以下的特性：

● 檔案相對較小，可讓網頁更快速呈現
● HTML程式碼減少，修改網頁更有效率
● 透過統一的樣式定義，讓整個網站保持視覺美感一致，在瀏覽上更具親和力
● 強化文件內容的可讀性，使得文件的結構更加靈活
● Write Once，Run Anywhere，樣式只要定義一次，在不同的網頁間都可以套用

HTML功能太多，要通盤了解所有屬性有實務上的困難，因此大多數的讀者在設計網頁時，大都會依賴功能較強的HTML編輯工具（像是Dreamweaver、FrontPage等），或是參考別人網頁的製作方式來加速製作。不過若要將CSS發揮到淋漓盡致，洞悉原始碼是免不了的。

《CSS Mastery》作者群都是具有多年經驗的網頁設計師，在HTML與CSS技術上學有專精，並將他們過去在工作上曾經遭遇到的問題都記錄下來。書中提到不少程式建議寫法，採用了許多進階的技巧，以較少的程式碼表現出相同的效果。

融合實務經驗彙集而成的好書

HTML雖說簡單易學不是什麼新的技術，但也許正因為它的彈性，可能讓讀者使用錯誤而不自覺，使得網頁結構不佳造成日後維護的負擔。本書一開始便讓讀者思考如何正確使用HTML，省思以往在使用網頁設計時是否有些不當或設計不佳的手法，應進而採用較佳的方式。

本書在前面幾章中介紹了CSS的基本概念，對屬性名詞有了明確的定義，讓初學者可以奠定良好的學習基礎。除了瞭解如何將CSS結合到既有的HTML程式碼中外，程式碼的結構化設計也是重點所在。

當然，本書同樣討論到一般網頁設計常見的應用，像是分欄版面、邊界空間的配置、各種樣式的連結設定、網頁導覽列的進階設計、運用背景圖案處理特效等。作者在內容中結合了過往經驗中遭遇到的狀況以及建議的作法。

另外，當你依賴CSS的程度愈高，即可能因結構複雜造成除錯不易的狀況，本書亦有專章討論如何有效除錯，亦為異於坊間同類書之處。

以案例帶出CSS設計的精神所在

紙上談兵了那麼久，本書的最後附上了兩個具有實作價值的Case Study，直接拿現有的網站實例說明，抽絲剖繭地將網站元素逐一分離，從版面的配置，透過畫面說明對應到屬性值的設定，加深讀者對常用屬性的掌握程度。

身為程式開發人員的你，不要認為CSS只是美工人員需要了解的技術，其實它只需短短幾行定義，便可以省去你冗長的開發時間，是相當值得研究的一門課題。

不妨仔細想想，你目前使用CSS的比重有多少？還是單純以HTML Tag的方式設計版面嗎？本書可以讓你擺脫傳統利用Table指令與空白GIF笨拙的設計方法，以CSS取而代之。

魚與熊掌真的無法兼得？

在使用便利性與功能完整性上要得到一致，單純以現行的JVM架構下是比較困難的。由於Java語言的特性著重Strong Type的撰寫語法，這在編譯過程及執行時期固然可以達到較嚴謹的資源分配，然而對於開發人員來說，無論是在撰寫上較費時，或是可能會經常因為一個小小語 法上的錯誤，無法快速除錯成功而造成開發時程延宕的問題，在現實專案的需求上是很難被允許的。雖然JDK不斷演進，Java語言還是少了那麼一點敏捷 （Agile）的味道，所以在敏捷理論盛行之下，Java開發人員似乎只能望梅止渴，有些使不上力的感覺。

Java被採用的廣泛程度，已經在許多的應用可見一斑，基於如此良好的使用基礎，發展出更方便的開發方式，過去幾年內一直都有相關的議題被討論 著。這些議題也因為其他強大的直譯式語言（Scripting）的出現，影響到不同的發展方針及理念，像是最近才正式發表，結合Python精神的 Jython 1.0版、因應最近兩年當紅炸子雞Ruby的JRuby，以及嘗試混合多方優點自成一格的Groovy。每個語言都有它的獨特性，但共同之處都是為了透過 精簡的腳本式語言特性來加速開發時程。

Groovy = Java + Scripting

Groovy自2004年發展至今，嘗試擷取其他直譯式語言的部分優點，加上JDK十餘年優良傳統的加持，它試圖在開發的領域上多一些樂趣及簡 捷。Groovy可以採用直譯方式以便於開發，或是編譯成Bytecode提升執行效能。終極理想是支援所有的Java功能，讓使用者可以同時使用兩者的 撰寫方式及程式庫，並將兩者的優點發揮到極致。

《Groovy in Action》第一部分即介紹Groovy程式語言的語法及資料型態等基本觀念。 第二部分則是深入Groovy程式庫的應用，包括建構工具（Builder）、開發套件（GDK）、資料庫及XML技術的整合。Groovy的出 現可以讓已經熟悉Java語法的讀者，無需因為學習一套完全不同的程式語言而必須接觸完全陌生的語法，直接切入擴充程式庫的學習，可以更快地掌握 Groovy的精髓，快速運用在實務工作上。

第三部分則彙整了Groovy的使用技巧、安裝方式、撰寫Groovy相關程式時常會遭遇的問題及解答，以及需要查閱的工具書等內容。

Groovy讓Java開發者更簡便

若你已是熟悉使用Java的資訊人員，Groovy的出現對你有什麼重要意義呢？也許你曾遇過類似狀況，在撰寫一些所謂系統管理性的小程式時，若以一般常見的Script語言開發僅需短短數行，但若用Java似乎又太麻煩。

而使用其他Scripting語言不見得是系統預設的套件、能夠在現有的系統環境即能進行開發，而運作中的正式環境也並非說動就動，可以隨時安裝自己偏好的直譯/編譯器在上頭。

Groovy的出現讓系統管理者可以結合Java的威力，透過Command-line即可簡單完成任務，省去了繁雜的宣告及編譯過程。當然，如 果你是一個崇尚敏捷開發的人，Groovy的特性多少可以讓你對Java的沉重包袱改觀不少。簡潔的語法減少開發時可能遭遇的錯誤，讓開發過程更加順利。

對於搭配Groovy的開發工具，無論在Java IDE或是一些文書編輯器也都已經有獲得廣泛的支援，由於Groovy與Java平臺密切結合，因此像是Ecilpse、IntelliJ IDEA、JEdit，甚至UltraEdit都有相關的套件（Plug-ins）或輔助功能，讓你在Groovy開發的路途上順利而不孤獨。

當Java遇上PDF…

在Java的開發世界中，只要你曾經思考過如何產生PDF格式文件，iText套件你必然不陌生。iText也是Java開放源碼中十分活躍的套 件之一，發展至今功能成熟且完整，許多知名的開放源碼報表軟體（像是JasperReport、JFreeReport等），甚至商用軟體套件都採用 iText為其PDF文件之產生核心引擎。iText說穿了，就是個PDF文件產生器。

在什麼樣的情境及條件下，以PDF格式來輸出檔案是較佳的選擇呢？

● 需要結合動態網頁產生PDF內容，而非手動方式可以單純完成。

● 網站中提供文件下載功能，但當Office等文件格式檔案容量較大，易造成下載速度過慢時。

● 針對文件內容有保全上的考量，避免內容被修改或列印。

● 講求列印內容之呈現效果，而不想直接以HTML網頁格式進行輸出，造成格式無法有效控制，像是特殊字型的顯示等。

● 提供異質平臺上瀏覽器的可讀性文件，尤其像是Linux、Mac OS等非Windows的作業系統。

雖然iText套件也支援非Java平臺（像.NET），但本書則著重在Java方面的整合開發，因此在本書中，你可以習得如何透過iText結合Java/J2EE發展出具備管理PDF文件的應用系統。書中的所有程式範例你都可以從iText的官方網站下載取得，直接安裝執行搭配閱讀本書可提升學習效率。

簡單5步驟，PDF即可得

也許你對iText套件十分陌生，本書開宗明義免不了對iText套件的發展沿革作概括性的說明。若你只是需要在實務上提供單純格式的文字內容輸 出，本書第二章便有讓你可以快速上手的內容，只要簡單的5個步驟、不到10行的程式碼，便可以幫你快速產生一個標準的PDF文件檔，處理的邏輯與一般文字 檔案的概念一樣，只需要初始化iText所屬的Document物件即可。可以快速上手產生PDF文件，或針對現有PDF文件內容處理。

當然實際專案的狀況中，報表或文件的輸出一定不會只是單純印印文字就作罷，搭配表格圖片、不同字型呈現、分段等多樣化的版面需求應該是免不了的。 書中第二部分則再進一步將文件中的每個元素逐一抽絲剝繭，從第四章操作文字基本元素、第五章處理文章內容中的圖片影像、第六章建構多樣化的表格、第七章的 分欄版面控制等，這些章節都能讓你深入了解如何利用iText掌控每個文件元素，建構出你所想要的PDF文件內容。

第三部分則深入介紹文字及圖片的處理，像是多國語系字型的控制、直書/橫書、特殊發音符號的處理、在頁面上產生線條、多邊形等快取圖案，以及設定顏色等功能。

不只單純瀏覽PDF，還可進階互動

若你對PDF文件需要提供使用者更友善的閱讀感受、在文件產出的同時搭配較優的偏好設定，讓使用者除了獲得應有的文件內容之外，透過互動方式更能清楚掌握到文件所要表達的重要訊息。

第四部分討論利用iText套件處理與瀏覽功能上的相關設定，像是利用書籤或頁面縮圖的導覽方式、快速在原文件中或跨文件跳頁及快速連結的功能、結合瀏覽器的呈現效果等，可以提供使用者更方便的瀏覽體驗。

本書為iText研發團隊成員Bruno Lowagie所撰寫，除了官方文件外，你可以透過本書獲得最完整、最原汁原味的iText資訊。秉持Manning著重實作細節的一貫作風，你可將本書 視為iText開發的實務手冊，依照章節來找出你在實務上的應用需求，搭配書中的程式碼來解決你的難題。依照程式碼逐行說明的內容，可讓讀者掌握每個實作 細節，相信本書可以讓你立即上手。

軟體專案要成功已經是IT專業人員渴望的目標，難道做一個成功的軟體專案真的這麼難嗎？前一陣子也有雜誌媒體用心良苦，遠從國外請了許多號稱大師級人物來 臺演講，將其在國外著名軟體公司的豐富軟體專案經驗與國內的專業同好們分享，從該研討會的與會盛況看來，開發人員一直被軟體專案凌虐，已是長久以來不可磨 滅的事實。

相信大家對許多軟體工程方法論也耳熟能詳，但仍然有絕大多數的專案開發者，對於如何將這些理論落實在專案進行中，一直無法掌握到其精華，這也是很 多人至令仍尚未接納這些方法論的原因。而本書作者有鑑於此，排除大家常見的理論灌水篇幅，而改以在實際專案運作的建議做為主要內容。作者本身也是開發人員 出身，所撰寫的內容均為經過多個專案的實戰經驗得出的寶貴結論，以做為讀者的建議。

基礎建設、管理技術與開發流程三者環環相扣

在本書開宗明義即勾勒出軟體專案管理的藍圖，從該圖你便可清楚體會軟體專案需要成功，一些基本元素是無可避免的。它分成基礎建設 （Infrastructure）、管理技術（Technique）、開發流程（Process）三大領域，彼此環環相扣缺一不可。有了這完整的規畫，可 以提升專案團隊的執行力，清楚且明確地將客戶的需求完成並及時交付。

只要是軟體專案，一些基本機制是必備的，即在軟體工程理論中所談到的組態管理（Configuration Management），像是版本控管、自動及連續建構腳本程式、測試程式撰寫、錯誤及問題追蹤等，這些機制可讓軟體專案在建構階段具備較高的可管理性， 節省無謂的時間，讓你的專案團隊效率更高。

本書也介紹了一些搭配上述機制的工具，通常是各位耳熟能詳的開放源碼軟體，但重要的是在使用這些工具時，作者歸納了不少在實務上需要考慮的要點，以及建議的實作步驟和可能避免的錯誤，讓你在使用時更能發揮該工具的優點，有效提升工作效能。

在藍圖中，專案管理技術亦是不可忽視的範圍，在這裡作者列出了幾項較為實用的建議方法，像是利用一些管理表格來進行團隊管理，如：待辦事項、任務 及功能完成度等，藉以有效掌控專案內容；另外作者也強調技術經理角色（Tech Lead）的重要性，每日適當利用會議針對特定要項進行有效溝通、針對每個開發成員撰寫的程式碼進行審查（Code Review）、發布程式碼變更通告讓每個成員知道等。當然這些管理技術亦可輔以一些已經發展成熟的工具，讓管理不會因為這些繁瑣事項而模糊焦點。

曳光彈式開發著重於前期骨架的搭建

軟體專案中，開發流程的選擇常常是決定專案成敗的重要因素之一，有別於過往各位常聽到的RUP、XP等製程方法，作者提出了曳光彈開發方式 （Track Bullet Development，TBD），基本精神與Java創始企業Sun所提出的AM（Architecture Methodology）類似，強調開發流程先以快速建構雛型系統的方式，搭配Mock Object及介面設計的使用，在專案初期便確保軟體架構面上的風險降到最低，再進行後續各功能項目的開發工作。

在筆者認為相當精彩的第五章，作者歸納了18個在軟體專案進行中常見的問題，每個問題都針針見血，你會發現這些建議並不是先前常常讀到，又臭又長 的理論式解答，而是作者自己親身經驗後所提出的想法，內容相當吸引人。你在閱讀本章時，必然會回想到自己曾經遭遇的類似經驗而發出會心一笑。像是接手別人 寫的程式碼還要增加新功能時，你該如何快速上手？當客戶看到你日以繼夜完成的嘔心瀝血之作，卻仍覺得不甚滿意時，你要如何面對？當沒有專責的測試人員時， 好的測試程序應該如何進行？

而附錄章節則提供了關於專案進行時常會使用到的工具及相關技術，做為實作時的參考，像是自動構建腳本的撰寫、原始程式碼管理機制等。本書適合專案 經理、技術經理、開發人員等不同角色閱讀，以多維角度來思考成功軟體專案的必備條件。不同於其他專案管理書籍的設計，本書重實務而非拘泥於枯燥理論，加上 篇幅不多，相信你可以得到不錯的閱讀經驗。

其他軟體專案管理相關之中文書籍

• 溫伯格的軟體管理學：系統化思考（第1卷)(Quality Software Management, Volume 1: Systems Thinking), 經濟新潮社, 2006年9月
• 人月神話：軟體專案管理之道（20週年紀念版）, 經濟新潮社, 2004年4月
• 專案管理黑皮書, 碁峰, 2007年1月
• 最後期限：專案管理101個成功法則, 經濟新潮社, 2003年11月

從先前iThome對中小企業所進行的調查顯示，整體看來企業花在IT方面的投資已經有逐年下降的趨勢，在有限的預算中要能有效推動企業E化，的確讓這些資訊主管他深深感到巧婦難為無米之炊。「又要馬兒好，又要馬兒不吃草」，相信這一直是資訊單位主管心中一直無法磨滅的痛，資訊單位通常都是屬於業務支援單位，所以在預算及人力的配置上，總是很難被受到重視及優先處理，尤其是在經濟不景氣的今日，成本總是會被錙銖必較，所以如何化腐朽為神奇，有效利用手邊資源創造非凡價值，就是資訊主管眼前相當重要的任務之一。

不容忽視的LAMP勢力

單純從建置成本的角度來看，LAMP的確是十分吸引人的，它的開放架構及資源充沛的程式碼，穩定成熟的技術讓許多中小企業愛不釋手，紛紛投入它懷抱。雖然在維護上及開發上相對於Microsoft的人才較不普遍，但是現在熟悉LAMP平台技術的人才也比過去好找，所以技術也不像以往那樣讓人覺得門檻太高而無法掌握，尤其在Web 2.0架構行情看漲，如此的技術完全不褪流行。

若您接觸過開放源碼（Open Source），經常下載一些好用的工具及應用系統來使用，您會發覺LAMP技術一直是開放源碼社群裡十分活躍的一群，也因為這些前輩貢獻的成果，讓我們節省了不少時間，可謂是前人種樹後人乘涼，這也正是開放源碼社群的基本精神之一。

在企業應用層面上，其實開放源碼也有不少現成的應用系統可以幫助企業解決一些作業標準化的問題，讓處理流程更一致，各功能單元之間的互動更緊密而發揮綜效。這些開放源碼吸取了不少實際的經驗，累積不少使用者反應的問題，在功能上不斷更新改良，讓接受度逐漸提高，這也是開放源碼成功的重要原因。

這些企業應用的開放源碼應用系統，一般而言會有以下特性：

• 以Web-based為主要設計架構，幾乎都可以搭配一種以上的資料庫系統
• 由於大多是PHP網頁程式，安裝相當方便，而且依功能提供不同的擴充模組，提供使用上高度的系統彈性
• 設定方式一般是以網頁方式進行（像是install.php），在第一次執行首頁時會引導設定，協助建立資料庫連結（包括使用者帳號，密碼，指定的資料庫名稱等）及需要使用到的資料表內容，不需要會寫程式也可以輕鬆完成
• 提供功能強大的管理功能及系統彈性，讓使用者依不同需求的使用者以組態設定的方式即可進行功能調整
• 字元編碼方式則以UTF-8為主，可以依您所需的語系進行設定，一些發展較為成熟的軟體專案還提供繁體中文的版本，也方便於大家使用。

雖然免費，仍需妥善評估

當您在選擇評估建置這些開放源碼應用系統時，本身的整合性成為十分重要的課題。這些來自不同開發單位的軟體必須要能彼此整合，在資料的串連上能夠具開放彈性，在軟體架構上的評估就需要花點心思。從軟體的功能上，以下幾點可以在評估時列入考量的重點：

• 應用系統在使用者認證（Authentication）及授權（Authorization）的機制，是否可以與現有的機制整合，而達到SSO的理想？
• 應用系統本身的資料匯出／匯入機制是否完整？其格式是否支援開放標準？
• 在功能的擴充上，是否提供方便快速不需要撰寫或透過修改程式碼的方式？
• 系統功能在操作上，是否能與現有作業流程結合？彼此之間的差異是否造成額外的成本？

而就開放源碼本身的可採用度及發展成熟度，可以依據以下的幾個角度來評估：

• 該開放源碼的更新版本是否頻率且及時？這反映出版本產生的錯誤及問題是否會被及時修正及解決。
• 該開放源碼提供的技術資源是否充足？是否被網路社群所熱烈討論？這反映出未來建置遭遇問題時，是否可以方便地尋得解決之道。
• 與其他軟體專案之間及開發平台的整合程度？這表示它的設計理念是否能處理目前技術的主流地位。
• 開放源碼本身所採用的技術是否為開放標準或市場主流？相關的專業人員是否容易尋得？
• 自己是否有相關技術人員可進行後續的功能強化及維護？這影響到自行維運涉及的成本及開發時效性。

以下的章節便針對企業活動中會使用到的應用系統逐一介紹。

網路甘仔店—OSCommerce

開家網路商店，做做小生意，相信是許多想自行創業的老板們曾經想過的方法。至今消費者對電子商務的接受度已經提高，在技術的成熟度及相關的安全機制亦十分完備，故企業亦漸漸投入除了在傳統通路以外的網路平台，開發新市場以提高業績。無論與消費者之間旳交易或是廠商間的採購買賣，皆可透過電子商務系統準確迅速達成交易，無形中節省許多人事、溝通及時間成本。

電子商務平台的取得可以有幾種方式：您可以透過平台供應商，以租用方式取得完整機制，包括前台（使用者瀏覽之商城內容）、後台（提供商品、訂單、供應商等管理功能）、金流（提供多種線上或離線付款機制）、物流（提供像是店配、宅配等商品配送方式）。若您自己具備IT專業人員，可自行負責軟硬體環境建置，後台金流物流機制亦有能力自行串接，即可採用下載開放源碼的方式來架設。

OSCommerce是目前電子商務平台採用度最高的解決方案，目前提供Web Hosting的服務平台亦大都採用此。國內亦有網路社群（www.kmd.com.tw）已提供中文化版本，搭配的外掛模組亦十分完整。在金流與物流的機制上亦有符合台灣地區的解決方案模組搭配，方便使用者直接下載安裝使用。

專案管理的好幫手－dotProject

只要是企業的運作，就免不了專案管理的需求。近年來PMP不斷地被倡導下，除了相關理論基礎的落實之外，搭配的資訊科技工具也是不可或缺的。業界常見的方式是利用Microsoft Project工具來進行專案管理，在專案團隊的協同運作上還需要搭配Project Server的套件，成本所費不貲。當然開放源碼軟體也有專案管理的解決方案：dotProject。

dotProject提供了一般專案管理需要使用的功能，從管理企業客戶及聯絡人資料，建立專案及相關任務的人力時程及成本，提供專案甘特圖(Gantt Chart)的呈現，還提供結合專案任務的行事曆，方便每個專案成員每日檢視。除了個人專案管理的功能，在團隊協同運作上，專案經理可以利用此平台的任務指派，讓每位專案成員從系統的待辦事項(ToDo)及今日工作（Today），便可以明確得知自己負責的任務內容，而每項任務的完成率也可經由每個成員在系統上的回報，而輕易彙整至專案經理的報告中進而有效控管。

dotProject也提供SMTP服務的整合，結合電子郵件的發送將專案更新訊息傳遞給相關人員。成員也可以透過內建的討論區功能，針對專案內容進行討論及資訊分享，同時對上傳的文件檔案亦提供管理的機制。系統亦提供一簡單的工單跟催(Ticket)系統，依據客戶需求型態及問題的嚴重性加以分類記錄，分派後以利後續追蹤及處理。

dotProject的系統管理功能也是十分強大，除了支援多國語系外，每個字詞的對應內容都可以自行修改；另外在功能的擴充上，直接點選需要增加的功能項目即可快速安裝新增的功能模組，您也可以從dotProject的官方網站上下載其他您需要的擴充模組，輕輕鬆鬆即可強化平台功能，不需要撰寫複雜的程式碼。

協同運作群組軟體平台—eGroupWare

群組軟體主要是讓一群人之間能共同密切作業而設計的軟體，結合日常活動及作業流程，讓彼此的協同運作更為密切。常見知名的群組軟體解決方案像是IBM Lotus Notes，Microsoft Exchange Server等平台，但其高額的建置成本讓許多企業望塵莫及，而大多數的企業也僅僅將其視為電子郵件系統使用，在投資效益上無法有效發揮。

開放源碼中的eGroupWare，最新版本提供了數十個發展完整的模組，提供個人資訊管理功能的行事曆、通訊錄、記事本等模組，提供Webmail (FelaMiMail) 模組與現有電子郵件伺服器整合，提供個人文件夾及檔案管理功能，在專案及資源（像是會議室、投影機等公用資源）的管理上也有對應的模組提供使用，讓它能夠滿足企業多元化的需求。

目前最新版本支援許多新技術，像是結合LDAP、AD等使用者認證機制、利用XML-RPC與外部應用程式整合、使用SyncML標準與您的行動裝置進行資料同步、AJAX等動態介面讓操作更友善。就這套軟體而言，可以視其為打雜的好幫手，尤其是對於工作日益繁重的資訊工作者，適當的群組軟體的確是不可或缺的。

密切掌握您的客戶—SugarCRM

常常可以從一些CRM書籍或研究報告的得到以下類似資訊：開發一個新客戶的成本，大約是維護一個舊客戶的五倍；而對企業貢獻的80%中，都集中在特定20%的忠實客戶身上。而CRM課題也不再是風聲大雨點小，根據調查報告顯示，它已經是目前中小企業E化中急欲建置的系統之一。然而建置一套知名大廠的CRM解決方案，動輒百至千萬不等，的確讓這些野心勃勃躍躍欲試的企業們著實潑了一盆冷水。

值得欣慰的是，在開放源碼的世界裡，當然也不會忘了CRM這個領域，較知名的像是SugarCRM、Vtiger CRM等，都是已經發展完整的應用系統，功能不亞於知名大廠的旗艦產品。SugarCRM是基於業務、行銷、專案、及客戶服務等功能CRM應用系統，它包含聯絡人資訊管理、成交機會分析管理、客戶活動追蹤管理、圖表及報表分析功能。從企業運作初期的業務活動拜訪，到最後的客戶關係維持，整個流程所需的資訊管理功能都被完整的包含在內。

本系統提供給不同功能角色的人員同時使用，像是銷售業務人員，行銷活動人員，專案執行人員，總務行政人員，客戶服務人員，及系統管理者等。透過SugarCRM的整合式平台，不同功能之間的資訊均能密切整合，讓協同運作之效益發揮到最大。

每個使用者登入後的首頁顯示出屬於個人化的重要資訊，讓使用者可以在第一時間查詢所有重要事宜，包括個人待辦事項，待回覆電話，專案任務項目，主管指派事項等，結合數位儀表版（Dashboard），將個人化首頁（My Portal）的機制發揮到極致，您可以自行調整及設定資訊內容，版面配置等，所有重要資訊一目瞭然。

對於與桌面應用程式的整合，提供了Microsoft Word及Outlook的軟體插件(Plug-in)，讓您可以將現有的Word文件內容直接上傳到SugarCRM系統中使用，結合SugarCRM中的聯絡人資料進行套表功能。而透過Outlook環境將電子郵件、行事曆、通訊錄等資料與SugarCRM進行同步，在個人資料管理上節省不少重覆作業的時間。

讓別人也能認識您的公司—Mambo

企業的門面很重要，尤其是在現今網路發達的世界裡，透過企業網站來得到第一印象已經是希鬆平常的事，如何快速建立屬於自己企業特色的門戶網站，提供正確無誤的相關訊息給您的客戶，透過強大的企業門戶網站平台工具來處理是絕對必要的。

在過去像是行銷部門要公佈最新活動訊息，人事單位要更新徵才資訊，財務單位要公佈財務資訊，總是需要透過資訊單位將資料轉換成網頁格式再佈署至企業網站，若單純只是靜態網頁的內容，這樣的流程常常會讓內容更新時間加長，而且就資訊單位而言，會覺得這樣毫無技術深度的工作有些無趣。

Mambo是針對企業需求所設計的門戶網站平台系統，無論是網頁功能選單的編輯，企業最新消息或熱門話題的公佈，都可以不假手網頁設計師，直接以Mambo現有的後台功能來處理。像是會員管理機制（提供登入、註冊新會員、電子報發送），投票機制（自訂熱門話題供訪客投票），內容管理（提供文章及圖片閱讀、評價、及回覆機制），橫幅廣告管理（提供上下檔、輪播機制），網站全文檢索（結合知名Google搜尋技術），網站使用統計（點閱率、訪客數等統計報表）。這些功能都是架設網站的基本要素，您不需要再撰寫任何程式碼，在Mambo中已經完整提供。

RSS格式內容的散播及已經是時勢所趨，Mambo提供了RSS格式產生機制，讓您的網站資訊也能隨者RSS方式，方便迅速地傳送到訂閱者手中。

文件管理不再紊亂無章法－Knowledge Tree

企業經營的過程中，知識累積常常會以文件的形式儲存，但當數量多到一個程度時，如何在短時間找到您要的知識便是令人困擾已久的問題，若未能有一管理良好的知識平台來儲存，在這些寶貴的經驗在傳承上則會面臨很大的問題，加上人力資源的流動，經常造成管理上相當繁重的成本。

Knowledge Tree文件管理平台提供方便操作的Web界面及Client桌面軟體工具。由於企業內部文件格式中多以Microsoft Office為大宗，故針對Microsoft Office文件亦提供軟體插件，可結合Office操作環境與平台整合以方便管理。而透過掃瞄器儲存成影像檔的文件，Knowledge Tree也提供影像文件管理功能，直接與光學掃瞄器結合，可以將掃瞄的影像檔案直接轉成PDF格式，以便於日後索引管理。

在Knowledge Tree中，您可以定義及編輯文檔的架構（像是文件目錄的分類），提供文件內容分享，調閱，進階查詢，版本管理，調閱歷史記錄等基本功能。此系統亦提供工作流程（Workflow）機制，文件可以結合使用者及群組身份進行權限控管，或是結合工作流程機制提供權責單位進行文件調閱申請及審核作業，可應用在技術資料室或智產專利相關具機密性之文件管理。

平台亦提供線上討論的機制，內建互動討論區功能可與相關文件串連，有效發揮知識及經驗分享的優點。使用者亦可依其所需訂閱相關議題內容，系統透過電子郵件方式主動通知更新內容，方便使用者之間的互動。

總結

心動了嗎？是不是也手癢想要小試一下身手呢？以上的介紹只是眾多軟體中的冰山一角，開放源碼何其多，仍然有許多會讓您如獲至寶的深刻體驗，介紹了這麼多的應用系統，也許您會覺得十分驚訝，這些功能一點也不亞於業界知名的商業軟體，是否有相見恨晚的感覺呢？

不過這些軟體的取得成本雖然低廉，但企業活動及作業流程亦需要進行適當的調整，導入這些系統才能發揮真正的效益；另外資訊單位日後的維護及系統功能強化亦需要有專才負責，否則可能只是三分鐘熱度，最後流於形式而毀了這些原創者的美意了。

在軟體開發流程的討論中，敏捷式軟體開發（Agile Software Development）一直被熱烈且廣泛地討論著。也由於軟體專案多變的特性，使得傳統的開發流程及軟體工程方法論已經是過於繁重而不切實際。所以像是 XP（Extreme Programming）、Agile等輕量級方法論成為新一代軟體工程的寵兒，而許多工具及實作方法亦圍繞著它們的基本精神而不斷繁衍。

程式語言及軟體架構也為了能因應開發流程的敏捷化需求，不斷地透過彈性的軟體框架（Framework）的推出，或是結合強大的整合式開發環境來配合這樣開發流程的體現，希望能及時且有效地反應真正的需求，並快速實作出合乎使用者理想的軟體。

但你會發現，彈性的軟體框架伴隨而來的，便是複雜的組態及物件層級，對於規模較小的應用需求，會有殺雞用牛刀的感覺，絲毫感受不到輕快敏捷的味道。

過去許多程式語言都能有搭配的軟體框架及整合式開發環境，試著要利用一些自動化的機制幫開發人員節省時間。但當你在採用時會發覺，針對這些軟體框架，開發人員需要先花不少時間學習使用方式，來提高掌握度，尤其是在編寫令人頭痛的組態檔時。

這次玩真的，敏捷製程不再是唱高調

自從Ruby on Rails的出現，透過RoR官方網站令人印象深刻的影片展示，許多開發者皆驚歎著Agile時代終於真正來臨，它的快速開發特性讓許多開發者為之著迷， 簡潔的軟體架構搭配著優雅的物件導向本質，讓寫過其他物件導向語言的開發人員，能快速領會其精神所在。

你不再需要針對不同的複雜問題，實作打造連自己都不是很熟悉的Design Patterns；你也不需要為了採用不同的軟體框架，而迷失在組態檔設計檔的叢林裡。因為以單純而明確的MVC架構用來做為基本的設計框架，透過URL 的命名方式Convention取代複雜的組態設定，對於大多數的軟體專案需求其實就十分足夠了。

相信你也聽了不少關於Ruby on Rails的精彩事蹟，一定想要動手試試，但受限於中文相關資源的缺乏，讓這樣的技術還未能被廣泛使用。目前已有多本專門討論Ruby程式語言的經典好 書，但中文版至今才出現2本翻譯專書，包括歐萊禮出版的《超越Java（Beyond Java）》、《Ruby on Rails：建置與執行（Ruby on Rails：up and running）》。對於初次接觸想要學習RoR的同好們，建議還是嘗試閱讀原文版書籍，較能在第一時間掌握較新的技術資訊。

談到與Ruby相關的書，其實早在2001年就有相關專書，像是O'Reilly的《Ruby in a Nutshell》，當時只是針對程式語言本身的特性及撰寫方式進行討論，並未提到Ruby在Web領域的應用。而開始被廣泛討論則是從Bruce A. Tate的《Beyond Java》一書緣起，在該書中便提到Ruby如何搭配Rails的軟體框架，以便快速地實作簡易的Web應用程式，但由於該書當時的討論重心並未在RoR 上，所以還不算是專書。

經典加上得獎，你不得不試試

Ruby結合Rails軟體框架的強大威力，在Web技術的應用上發揮得淋漓盡致，加上Web 2.0的加持，更是將其快速開發的特性展露無遺。在《Agile Web Development with Rails》一書中，即是將Ruby語言充分發揮在Web應用上的經典書籍。

在眾多討論RoR的書籍中，享譽盛名的不外乎就是《Agile Web Development with Rails》。本書為RoR之原創者David Heinemeier Hansson所著，而另一位作者Dave Thomas深諳敏捷製程，同時也是經典書《Programming Ruby》的作者。本書第一版並獲得了2006年Jolt Award大獎，可謂實至名歸。

由於本書銷售狀況甚佳，不到1年的時間再推出第二版，因此在書中你除了可以習得作者忠於原味的技術內容，第二版的內容採用了較新的Rails框架(1.1版)，並加入RJS、Ajax的應用範例，作為實作的基礎。

章節編排適合初學者閱讀，著重實作範例

《Agile Web Development with Rails》與一般書籍章節設計的差別在於：作者以深入淺出的方式，先以簡短的章節對RoR進行概略性的簡介，然後直接以實例方式切入RoR的程式撰寫， 再回頭探討RoR的核心架構，最後透過附錄章節提供Ruby程式語言的介紹。你可以依循作者設計的章節順序逐一閱讀，透過實際的範例操作引領你進入RoR 的世界。你完全不需要有Ruby撰寫的經驗也可以快速上手，適合有興趣的入門者研讀。

Rails的出現便是為了讓開發流程更簡捷，所以書中第一部分便從架構簡介開始，讓你先對Rails的軟體架構有基本的認識，除了貫穿核心的MVC模式之外，透過Active Record的OR Mapping機制來進行資料層的處理，也是框架的重點所在。

紙上談兵不過癮，動手開始進行安裝吧！你會覺得安裝RoR一點也不難，而且支援多種作業平臺，依照你所喜愛的平臺種類，將RoR裝到你的開發環境中。除了RoR的核心套件之外，你同時需要搭配的整合性開發環境及資料庫系統，在第三章也對此有詳細說明。

動手實作加深印象

當歡迎畫面呈現在你的瀏覽器中，表示你的RoR已經安裝完成。第四章便教你從專案的建立，產生定義你的Controller及Action內容， 並撰寫動態頁面的Template程式。本章的討論可以讓你了解在RoR專案中目錄的結構，以及Controller、Model、View與目錄分布之 間的互動關係。這些關係僅僅以URL的語法即可以完整定義，不需要再透過煩雜的組態設定。

有了前幾章的基本觀念後，接下來第二部分的章節，作者設計了一個網路書店的案例，讓你對RoR的印象更深刻。若你曾經接觸過電子商務的網站，你便會十分熟悉這些功能的需求及運作方式，每個章節不是單純的程式片段介紹，而是可以前後貫穿、相互呼應的內容。

記住！本書開宗名義就強調是Agile，所以為了落實敏捷開發的精神，從分析階段開始便以反覆(Iteration)進行，手繪幾張頁面流程圖便開始進行程式撰寫，而不拘泥在以往的UML標準圖例上，這夠敏捷了吧！

範例搭配敏捷製程，更突顯快速開發特性

作者設計了8個任務個別包括了數個Iteration，功能涵蓋商品管理、型錄瀏覽、購物車機制、結帳流程及系統管理等，讓讀者從學習建立RoR 應用程式及資料庫設定開始，一步步了解如何利用建立Model的方式，配合Database Migration來建立資料庫結構，並透過scaffold來快速產生資料維護頁面。每個章節都詳細說明整個程式細節及建置步驟，方便讀者學習。作者在 程式中亦頗具巧思地設計實作上的錯誤及陷阱，讓讀者加深學習印象。

每個Iteration之間以漸進方式強化範例的功能，Iteration的設計也是作者精心策畫，每個Iteration的結束都產出完整可執 行的功能。而在這些實作中，亦提到中途如有需求變更時，實作面的因應做法為何，這也是我們平時在專案執行時常常遇到的，像是新增資料欄位、調整版面設計。 傳統的程式語言開發也許會因架構調整而耗工費時，在這裡會讓你感受到RoR敏捷的威力。

在透過程式範例認識RoR之後，第三部分則回頭來探討Rails框架的技術細節。此部分的章節便按部就班地介紹Rails架構，為你建立更紮實的 理論基礎。除了框架基本精神以及MVC各元件的撰寫及設計方式外，在Web Services的應用、系統安全性以及測試與部署方式亦有專章討論，這些都是平常程式開發人員所容易疏忽的。

章節編排適合初學者閱讀，著重實作範例

也許你在閱讀本書時對Ruby的語法十分陌生，對於書中的範例程式一時還無法完全掌握，你可以同時參考附錄中的Ruby專章，補足你對Ruby程式語言的缺憾。另外書中也收錄了組態參數的設定方式、本書範例的完整原始碼及相關資源列表等。

對於準備學習Ruby on Rails技術的程式開發人員，《Agile Web Development with Rails》是不錯的選擇。你可以將本書視為Ruby on Rails開發的最佳實踐(Best Practices)書籍，從無到有地建立一個實用參考價值頗高的網站，可以讓你紮實地打好基礎，也足以讓你掌握Ruby on Rails的重要特性，讓你一書到位。若你想針對Ruby語言進行更深入的研究，不只是Web方面的應用，像是Pragmatic出版的 《Programming Ruby》、O'Reilly的《Ruby in a Nutshell》、《Ruby Cookbook》都是你可以搭配閱讀的經典。

• 強化網站功能(Enhance Your Web Site)

若您已經有自己的網站或部落格，可以透過這類功能來強化您網站的機制，以及提供完整的網站分析管理功能，讓經營您的網站更省事，更簡單。

• 一般使用者功能(Reach Google Users)

主要針對Google所提供的Client軟體，適用於一般使用者，提供可以安裝在個人電腦桌面中的小工具(Gadget)。這些以XML為主要撰寫語言，讓您的日常工作可以透過桌面與Google之間的密切結合更有效率。

• 提供整合界面(Integrate with Google)

這是針對進階使用者，尤其是具有程式撰寫能力的開發人員所提供的程式界面，您可以依您所擅長的程式語言(Java, Perl, Python, PHP, Ruby及.NET等)，透過標準的傳輸協定及開放標準來進行實作。

接下來便針對一些熱門的API功能進行介紹。

Google AJAX Search API

在所有Google的Web服務中，最常被大家使用的便是其強大的搜尋引擎功能。在一個功能完整的網站裡，搜尋機制已經是基本配備，在過去這樣的功能需要導入某特定搜尋引擎的軟體套件，安裝在自己的機器上才能達成的理想，現在僅僅需要在Google網站上申請一組API License Key，便可以享受Google既有的搜尋功能，而不需要在自己家裡搞一套搜尋引擎主機。

若您對撰寫程式有很大的學習障礙，Google提供了一種懶人機制，以增加HTML及JavaScript程式碼的嵌入方式，就可以將Google的搜尋機制免費安裝到你的網站中，而且還結合了最酷炫的AJAX技術，這樣的搜尋機制遠比自己動手寫程式來得容易多了。

從圖中您便可以很清楚看到，透過這樣的整合，不只是提供網頁內容的搜尋，連視訊、部落格、新聞、地圖等內容都可以一併呈現。這些不同性質的內容是透過Google Gadget元件組合而成，像是Video Gadget、Map Gadget等，模組化的結構讓您可以彈性變動搜尋的結果，而在這個內嵌框架的裡頭所使用的AJAX呈現技術，讓操作方式更加友善便利。

Google Web API

當然，除了簡單的嵌入整合方式，手癢的程式開發者也可以透過Google所提供的API來將它的服務整合到自己的應用程式中，Google針對搜尋機制提供的API十分完整，您可以透過Web Services的業界標準界面讓整個操作使用更加流暢，這便需要花點心思寫點程式才有辦法達到的，可以依照您的需求進行客製化，整合程度更高。

這個函式庫裡包括了.NET（C#）, VB及Java的範例程式、WSDL描述檔、API參考手冊，及Java Doc文件。由於目前的Google Web API是透過Web Services的架構，所以只要依照WSDL描述檔的定義，以SOAP的方式呼叫取得搜尋結果即可，所以只要程式語言本身可以撰寫出SOAP Client就可以使用。若您是採用Java為主要開發語言，Google Web API提供已經包裝好的SOAP Client程式庫，只花幾行程式即可撰寫完成，相當容易。

為了讓資源能有效分享給普羅大眾，Google針對每個申請者有使用上的限制。針對每個使用授權每日僅能呼叫1000次，而且每次的查詢結果僅回傳前1000筆，回傳則以最多10筆為一個單位，而搜尋內容則不包括圖片、新聞等其他內容，僅限於網頁資料，如此設計均是為及提昇執行效能所做的考量。

當然，這樣的函式庫是提供研究性質之使用，而未被授權於任何與商業有關之應用。在使用之前您最好還是詳讀一下授權合約內容。

Google Web Toolkit (GWT)

相信您使用了一些Google所提供的服務後，會對它在網頁上呈現的AJAX動態效果印象深刻，這樣的設計對於使用者經驗是有正面評價的。但對AJAX這樣的技術也許對許多開發人員仍然是陌生的技術，要能及時熟練上手也許會有困難，加上AJAX本身在開發測試過程中會有一定的困難度，故貼心的Google研發團隊便將其相關的技術以Java方式來呈現，提供更廣泛的Java使用者也能開發出AJAX的應用程式。

您可以將GWT視為Java軟體框架，GWT具備了動態可重用的特性，開發者只需要引用GWT提供的程式庫即可設出美美的AJAX UI畫面，避開了在Javascript程式撰寫時不易除錯的問題，所有的開發方式可以依循原有的Java開發程序，結合您所熟悉的Java IDE工具(像是Eclipse)進行開發，同時也可以與JUnit整合，將單元測試自動化以提高效率。

GWT提供了Java-to-JavaScript Compiler，可以將您結合GWT所撰寫的Java程式碼轉譯成具備AJAX功能的JavaScript內容。在開發過程中，您可以利用Host Mode對Java程式進行測試，而不需要每次都轉成JavaScript才能測試最終產生的結果。而Web Mode則是將所有的Java程式轉成JavaScript後實際以Web界面執行的方式。

在GWT裡已經幫您解決了AJAX對不同瀏覽器的支援問題，您只需要針對UI版面配置進行設計即可。GWT提供了數種Panel應用在不同的版面配置，類似AWT中的Layout Manager功能，所以你會發覺程式的寫法有點像在寫Swing應用程式。

Google Map API

若您的應用程式中需要提供地理資訊，包括地理行政圖、地區街道明細、以及路線規劃建議等， Google Map服務是個不錯的選擇。它提供了世界各地的地理資訊，同時可以選擇地圖、衛星鳥瞰圖、以及混合顯示等呈現方式。進一步它還可以提供您設定起迄點之間的實際距離，以及最佳路線建議等。

若您只是使用呈現地圖的單純功能，那就太小看Google Map了。為了讓地圖能更具可讀性，在上面加註資訊是免不了的。Google Map API提供了Marker（以標識符號突顯某特定的地點），InfoWindow（加註說明文字於訊息框中），及Polyline（以畫線方式標示路線或範圍）等註記方式。其實在技術上的整合亦十分簡單，此API亦是利用HTML與JavaScript內嵌方式來達成。

此服務整合常見的應用如房屋仲介（提供查詢物件的所在地理資訊），求職訊息（提供徵才企業的所在位置），旅遊情報（提供旅遊景點位置及重點地標），交通路況查詢（提供兩地之間最佳路徑）等，讓僅僅只是冰冷的地址文字加上更豐富的圖像資訊。

美中不足的是，目前Google Map對於台灣地區的地圖資訊提供僅限於衛星影像，而行政地圖的部份仍然未臻完整，對於想要提供區域性網站資訊的內容則稍嫌不足。而類似的服務您也可以參考由國人開發的UrMap你的地圖網(www.urmap.com)，此網站服務亦提供Web API可供呼叫，使用的元件架構也十分類似Google Map的設計方式，加上其提供的台灣地圖街道行政區資訊較為完整，比較符合國內網站的應用需求。

Google Toolbar API

對於Google工具列應該大家都不陌生，其方便強大的功能已經成為瀏覽器的必備套件。在下載安裝Google工具列之後，在工具列上預設的按鈕功能也許仍然無法滿足您的需要，所以Google工具列提供了API讓有興趣自行設計工具列按鈕的玩家們來使用，您也可以在Google 工具列上設計自訂按鈕功能，將一些常用的網址連結、RSS資訊提供內容放到工具列上，在使用上更為便捷。

只需要撰寫簡單的XML檔案，引用Google工具列特定的標籤語法，就可以製作出您想要的功能按鈕。您也可以到Google工具列的按鈕集頁面中，搜尋別人已經提供的工具列按鈕，也可以將您的精心傑作與其他Google工具列的使用者分享。

Google Desktop SDK

Google除了在網路服務上有著卓越的使用率外，對於個人桌面的市場亦野心勃勃，自行推出桌面搜尋工具後，連微軟也不得不承認一向佔有優勢地位的桌面也感受到威脅，也推出類似的桌面搜尋工具，頗有相互較勁的意味。

新一版的Google Desktop 4除了包含既有的桌面搜尋功能之外，還提供可以與網路服務直接連結的側欄（Sidebar）功能，讓您不需要開啟網頁瀏覽器也可以使用Google提供的網路服務。側欄可以讓您下載安裝許多與Google現有網路服務結合的Gadget小工具，像是即時新聞氣象服務、Gmail個人郵件瀏覽、個人相簿、行事曆及待辦事項等等。Google已經將Desktop視為網路服務的延伸平台，讓它的服務更能深入個人桌面前端，結合得更密切。

當然在Desktop平台方面，Google也提供了開發Gadget的SDK，讓您可以設計出屬於個人色彩的桌面小工具，成為側欄的一部份。SDK支援JavaScript, C, C++, C#, and/or VB.Net等技術，下載的SDK中也包含一視覺化設計工具Gadget Designer。Google也鼓勵那些網站內容提供者，利用Google Gadget SDK開發出自己網站專屬的Gadget，並公佈到Google的目錄中供下載使用，進而讓更多的使用者認識這些具有特色的網路服務，打響自己的知名度。

其他Google API

Google API種類繁多琳瑯滿目，以上僅針對較常被使用的部份進行介紹。如果您需要參考關於Google API的技術資料，您可以造訪http://code.google.com，這兒包括了所有的API分類及相關說明，函式庫也是從這兒下載使用。以下便列出所有Google API的清單供大家參考：

與開放源碼社群的緊密結合

除了Google自己提供的工具套件及程式介面外，您也可以在開放源碼社群中找到不少與Google服務有關的專案。為Google如痴如狂的使用者不在少數，這些開放源碼提供了Google功能的延伸應用，也是您的不賴的另類選擇。

若您是Mozilla FireFox的愛用者，除基本功能已經提供了Google的搜尋功能列之外，您還可以下載安裝針對Google量身設計的擴充套件（Extension）來使用，像是CustomizeGoogle等。

結語

在Web 2.0的世界中，Google只是其中一個比較顯著且知名的例子，其他像是Amazon, Delicious, Cocomment等許多網路服務平台，也都提供Web API的機制。單純來自一種資料來源已經無法滿足現今網路使用者的需求，未來的服務將是以軟體混搭（Mashup）的概念（意即Web應用系統整合多種不同的資訊來源）來發展，資訊的整合勢必是未來的趨勢。

重構（Refactoring）這個字眼想必大家應該不陌生，由Martin Fowler提出此革命性的觀點，基本精神是在外觀不被更動的前提下，進行內部重整的動作。而重整的對象通常是指軟體架構、演算邏輯、物件關係及程式碼內 容，當時《Refactoring》一書主要針對程式內容的改良進行討論，並未將資料庫設計納入範疇。

歷史的包袱是資料庫明日的負擔

然而，在應用系統不斷地進行功能擴充或版本升級時，原本設計的資料庫規格必然會有異動的需求。當功能變動幅度不大時，也許會以在基本原始架構下新 增資料表的方式進行；然而，時間一久，資料表之間的關聯錯綜複雜，資料的一致性及正確性可能因此大打折扣，在資料模型上較不如設計初期時那麼具備語意及行 為概念，慢慢變成疊床架屋後的高風險違建，更談不上什麼符合資料庫正規化的理想了。

這樣的狀況在資料量不多的情況下，或許感受還不太明顯。當資料量成長一段時間後，在資料的一致性及處理效能上，就會付出較高的維護成本。

資料庫重構（Database Refactoring）的動機，即是在改善資料庫因長時間發展所造成的設計問題，在不增加新設計的前提下，針對現有資料庫結構設計及資料內容的重整。除了讓後續的設計能更容易維護，在擴充上也更具彈性。

真的要重構，那該怎麼做？

《Refactoring Databases》第三章提到資料庫重構的建議步驟，依照這些標準作業程序，可使進行重構時將風險降到最低：

● 評估重構的需求是否真的適用在你現有的資料庫系統上。

● 依照你的資料庫現況選擇最適合的重構方式。
● 在重構的過渡時期保留原有資料結構。
● 不斷地測試，測試完成後便著手進行重構作業。
● 重構完畢後執行原始資料的轉移作業
● 修改外部程式對資料庫的存取方式。
● 持續進行迴歸測試，確保重構的作業順利無誤。
● 對變動內容進行版本控管。

資料庫重構的觀念立意雖佳，但規畫及執行的過程必須十分謹慎周延。大部分的狀況下，資料庫不會僅單純提供給某一個應用系統使用，若因重構處理不當 而中斷服務，來自開發人員、使用者等四面八方的抗議聲會蜂湧而至，所以在執行策略上必須妥善設計。在本書第五章便討論到這些內容。

包含完整的資料庫重構技術
作者在本書歸納整理了過去的成功經驗，將重構的方法大致分成以下幾大類：

● 結構性（Structural）重構：針對既有的Table、View重新設計。像是欄位的搬移、分割、刪除等。

● 資料品質（Data Quality）的重構：提高資料內容值的正確度或嚴謹度。像是減少非空值欄位以提高資料的可讀性，或是強迫定義格式（像是電話欄位），使其內容規格一致，或是加入欄位的限制條件（Constraints）等。

● 資料關連一致性（Referential Integrity）的重構：確保不同資料表之間的資料關連性都能正確。像是透過Trigger輔助進行跨資料表中之關連性資料刪除、加入外來鍵（Foreign Key）限制資料之間的一致性。

● 架構性（Architectural）的重構：架構設計的改善，藉此讓外部存取資料時更容易處理。

● 方法（Method）的重構：針對資料庫相關程式（像是Stored Procedure、 Function、Trigger等程式）的修改，可能是換上一個比較容易識別的名稱，或是將多個程式合併等。

● 其他改變：上述都是屬於重構，但也有機會不是以重構的方式變更系統，像是在現有資料表中增加欄位。

列了這麼多的資料庫重構方式，此時你便得審慎評估需要採取那一種。本書從第六到十一章便針對這些不同的重構方式逐一討論。每個大類中包括了作者提 出的許多重構方法，內容從需求的動機（Motivation）談起，了解需要使用該方法的真正原因為何，指出其潛在可能發生的問題供讀者評估；也列出更改 資料庫綱要之建議步驟、結構變更後的既有資料轉移方法以及技術實作方式。

資料庫重構的工程可大可小，花時間進行這樣的投資仍然是值得的。規畫者在事前的評估規畫及執行所需的方法，在本書的章節都可以找到你要的答案。字字珠璣，絕對是值得一讀的好書。