注意：這個分析在 2008 年夏天進行，起因於 Google Code 評估加入分散式版本管理功能

摘要

這份文件總結了 Google Code 在希望加入分散式版本管理功能所做的初步研究，基於普及性，只考慮了兩個分散式版本管理系統： Git 與 Mercurial 。這份文件說明了兩個系統的功能，也提供一個將它整合進 Google Code 所需要進行的工作。

分散式版本控制

在傳統的版本控制系統，一般會有一個集中的資料庫控管所有記錄，用戶必須與這個資料庫互動來驗證檔案的記錄、檢視其他分支與提交異動。通常用戶端會複製一份資料進行處理，但是這個版本並不會儲存早期版本與其他分支的資料。

分散式版本管理系統(以下簡稱 DVCS)使用了不一樣的結構，使用 DVCS 時，每個使用者會有一個本地端的資料庫、完整的專案異動記錄、分支等等，切換到不同的分支、檢驗檔案異動記錄或甚至提交異動都是在本地端進行操作。而個別的資料庫間可以透過推(push)與拉(pull)操作進行資訊的交換，一個推的操作會將本地端的部份資訊傳送到遠端資料庫，而拉的操作則會將遠端的資料複製到本地端資料庫。需要注意的是，沒有任何一個資料庫具有較高的權威性，兩個資料庫也許都會有些本地端的記錄還不會出現在另一端，任何的 DVCS 系統都有一個關鍵性功能，就是讓資料庫可以清楚傳達本地端所擁有的記錄(以及它所需要的記錄)，而 Git 與 Mercurial 兩者都是透過 SHA1 雜湊值來檢驗資料(檔案、目錄結構、版本異動等)。

DVCS 讓開發者在工作流程上有更多的彈性，他們可以用傳統版本控制系統的習慣進行操作，也就是透過一個集中、具有權威的資料庫讓開發者進行同步；而對於比較大的專案，它也可以提供具有階層關係的資料庫，只要每個資料庫的維護者允許來自下層開發者的異動以及將這些異動提交給上層。 DVCS 還允許開發者彼此間分享工作成果，例如兩個開發同樣功能的開發者可以在相同的分支上進行開發，但是兩者之間成果的分享不需要透過一個權威性的伺服器；當他們完成了開發，就可以將成果推到公開的資料庫，讓更多人使用。

因為沒有集中的資料庫，所以不會有所謂的主從架構，當談論到兩個資料庫時，一般是指本地端與遠端，而不是伺服端與用戶端的關係。不過在 Google Code 實作的概念中，在 Google 的資料庫還是會被當作伺服端，而使用者的資料庫會被稱為用戶端。

功能比較

事實上， Git 與 Mercurial 有許多相仿之處，因此在這裡不會提供兩者都有的冗長功能清單，這個部份希望點出兩者間顯著的差異。

Git 的優點

* 用戶端儲存管理， Git 與 Mercurial 都允許使用者選擇從其他資料庫拉回分支，這提供了一個前端結構來減少本地端儲存的異動記錄。除此之外， Git 允許捨棄較早拉回的分支， Git 還允許從本地端資料庫將舊有的版本異動刪除(同時仍然會保留這些分支的最新版本資料)。而在 Mercurial ，如果一個分支是儲存在本地端資料庫，所有版本異動(從最初提交的版本)都必須存在，除了建立一個新資料庫選擇性將分支推進資料庫外，沒有辦法刪除分支資料。雖然他們正在開發這個部份，但是還沒正式推出。

* 父階層的數量， Git 在合併時支援無限數量的父階層版本異動，而 Mercurial 只允許兩層。如果希望在 Mercurial 做到 N 階層合併，使用者必須執行 N-1 次的兩層合併，雖然一般合併 N 個父階層資料時會建議採用 Mercurial 的作法，但使用 Git 時使用者可以一次完成。

* 分支點變更(Rebasing)， Git 提供一個 rebase 指令，可以在一個本地端分支修改分支點到一個較新的版本，例如某個人在開發一個產品的新功能，本地端分支也許已經從 1.0 版開始，而如果開發過程主要的產品線已經更新到 1.1 ，也許需要將 1.0->1.1 的異動拉回本地端功能開發中的版本，並且將分支點從 1.0 改為 1.1 。在其他系統中，會透過合併 1.1 的異動進入分支，合併也是從版本控制系統角度看來正確的事情，如果將焦點放在"過去狀態的重製能力"。不過如果焦點是 "製作一個簡潔的軟體改版記錄" ，分支點變更有時會比較好。 git-rebase 允許讓一個過去未連續的異動記錄能夠連貫，讓異動記錄可以簡潔些。正確的說，這個功能其實是將 1.0 版的所有異動個別提交到 1.1 版，分支點變更功能是安全的執行這些操作，並且刪除 1.0 版，因此不會讓樹狀結構變得混亂。

備註： Mercurial 在這份文件完成後已經有加入了分支點變更功能。

Mercurial 的優點

* 學習曲線，基於許多的事實， Git 跟 Mercurial 比起來有著比較陡峭的學習曲線。 Git 有比較多的指令與選項，這些功能的說明可能會讓新使用者備感威脅。 Mercurial 的文件對於新手來說相對完整與容易閱讀，Mercurial 的用詞與指令也比較接近 Subversion 與 CVS ，因此對於從那些系統轉移的人們來說會比較親切。

* 支援 Windows ， Git 有著強大的 Linux 包袱，在 Windows 執行它的正式作法是透過 cygwin ，對於一個 Windows 使用者來說不是非常理想。一個使用 MinGw 改寫的 Git 漸漸受到歡迎，但是 Windows 在 Git 世界中仍然是一個次等公民。在有限的測試中， 使用 MinGW 改寫的版本看來提供了完整的功能，但是有點遲鈍。一些在  Linux 或 Mac OS X 幾乎是即使反應的操作，在 Windows 中可能需要十幾秒。 Mercurial 是使用 Python 開發，而且正式版本在 Windows 下執行順暢(在  Linux, Mac OS X 等系統也是)。

* 維護， Git 需要定期維護資料庫(例如 git-gc)，而 Mercurial 不需要。不過需要注意的是， Mercurial 對於用戶端磁碟空間的管理也比較沒那麼複雜(可以參考上面關於用戶端儲存管理的說明)。

* 記錄是不容侵犯的， Git 非常強大，可以執行任何你想做的事情，不幸的是，這也意謂著 Git 也很容易遺失記錄。舉例來說， git-push –force 會讓遠端資料庫的版本異動消失；Mercurial 的資料庫結構比較像是不可變物件持續成長的集合，雖然在部份情況下 (像是 rebase) ，改寫記錄是有優點的，但這也很危險，可能會導致無法預期的結果。不過需要注意的是， Git 伺服器可以透過設定來避免遺失資料，所以 Mercurial 這個優點並不是那麼明顯。

其他差異

* 檔名更改/複製的追蹤， Git 並不會明確的追蹤檔名更改與複製，取而代之的是像 git-log 指令用來比對資料庫記錄中是否有同樣的檔案來推論檔名更改或複製。 Mercurial 以比較熟悉的形式，提供明確的檔名更改與複製指令，並且將這些操作儲存到檔案的記錄中。 兩種方式各有其優缺點，哪個比較好並沒有比較明確且普遍的答案。

* 架構， Git 原本是以 C 設計的大量 shell scripts 與 unix 指令，隨著時間推演，在指令間共用的函式庫已經開發完成，許多指令已經內建在主要的 git 執行檔。 Mercurial 大部分是用 Python 設計(少部份使用 C)，包含一個外掛的應用程式介面，允許透過自行設計的 Python 模組加強 Mercurial 功能。

* 私有記錄，在 Git ，開發者操作的預設模式是使用自己本地端(與私有)的標籤、分支與版本異動，而且在公開後可以運用許多控制。而 Mercurial 強調另外一種方法，預設的推/拉行為會共享所有資訊，如果只想共享一部份就需要額外的步驟。這沒有列在任一系統的優點，因為兩者都支援另外一種操作。

* 分支命名空間，在 Git ，每個資料庫有自己的分支命名空間，使用者可以設定本地端分支名稱與遠端對應情形。在 Mercurial ，所有資料庫共用一個分支命名空間。

實作考量

資料儲存

Git 與 Mercurial 內部使用非常相近的資料：檔案版本異動與少量的後設資訊(父層資料、作者等)，兩者都有代表整個專案提交的物件，這些物件也都有版本記錄。兩者都有記錄每次提交所有檔案的版本。在 Git 使用的是一個樹狀物件 (一個樹狀結構，包含目錄的樹狀物件與檔案版本參考的樹葉結點)。在 Mercurial ，使用一個物件清單(一個對應路徑名稱到檔案版本物件的清單)。除了物件清單與樹狀結構的差異外，兩者在物件的搜尋與走向都相當接近。

Git 直接在檔案系統使用一個儲存物件的集合 (透過 SHA1 雜湊索引) 並且將多個物件打包成更大的壓縮檔；而 Mercurial 使用一個改版記錄結構 (基本上是一個連續的改版差異，加上定期的完整版本備份)。在實作時都不會使用原本的儲存方式，物件都會儲存在 Bigtable 中，基於 Git 與 Mercurial 在基礎資料物件的相似情形，無論使用哪個應該花費的時間一致。

在資料儲存時的唯一主要差異是使用的語言，如果要重複運用大部分 Git/Mercurial 的程式碼， Git 的部份需要使用 C ，而 Mercurial 則是使用 Python (或也許是 C++ 與 SWIG 的結合)。

Mercurial 整合

Mercurial 在遠端資料庫的推拉操作提供基於 HTTP 不依賴狀態特性的良好支援，開發者花費了許多精神在減少用戶端與伺服器間往返檢查需要交換的資料，且一旦完成檢查，所有相關資料會集合起來一次大量傳輸，這符合了 Google 的架構，所以在用戶端不需要任何改變。

Git 整合

Git 包含了推向 HTTP 的功能 (與推向 WebDAV )，但是程式假設伺服器端對於 Git 沒有任何準備，它的設計是以 Apache 將 Git 資料庫當作靜態檔案的情況下，這個方式需要大量為了同步化的請求往返，不適合用在 Google Code 。

Git 也提供了一個自訂的、依賴狀態的協定，支援比較快速的資訊交換，但是不符合 Google 的架構，因為 Google 非常需要不依賴狀態的 HTTP 協定，因為已經在這個架構上投入了大量資源讓它穩定且有效率的執行。

備註： 在這份文件完成後 Git 社群已經開始有些改善 HTTP 支援的討論。

總結

基於實作上的差異， Mercurial 有著明顯的優勢，因為它對於 HTTP 傳輸協定的支援。

不過就功能性而言， Git 確實比較強大，但也相對意謂著使用上更加複雜。

在實際使用 CakePHP 前，我已經是個以設計 PHP 應用為主的工程師，也是開始體會到，程式設計其實還有蠻多煩瑣的工作必須完成，不是每天都可以接觸新玩意兒。

一個使用者在操作過程發現，好像應該加一個欄位進去，需求進到工作清單，在資料表開了對應的欄位，接著就是在表單新增一個欄位，確認資料可以塞進資料庫後，就開始著手修改畫面，簡單測試後就請使用者試試。然後使用者會發現，這個欄位並不只是要顯示而已，應該加入一些判斷，讓他更好做事，這種工作就這樣成了無限迴圈，使用的人越多，發生的頻率越高。

接著老闆突發其想，要將某某流程透過程式自動化，在需求訪談過程會驚覺，原來這個某某流程平時根本沒有標準可言，文件亂、例外狀況多，儼然就是個燙手山芋。在老闆執意進行之下，這系統還是莫名其妙出現了，接著就是操作單位與開發單位的大亂鬥，老闆見情況不妙就開始躲在一旁，在兩個單位沒能夠達成共識之前，功能的雛型就是一直晾在那裡。

最經典的還是那句話，「為什麼誰誰誰有，我們卻沒有？」，這句話可以讓一個需求衍生為全面且多樣性的功能，也可以讓開發單位被要求每天得盯著競爭對手的網站，其中的無奈可想而知。

當然，使用 CakePHP 並不會像拿了什麼寶物一樣讓那些人全部閉上嘴巴，只是在逐漸趨於追逐時效性的現實情況下，能夠有個快速滿足需求的工具會讓生活好過些。

只有 CakePHP ？

在腦子裡開始出現求生念頭時，其實懷抱著許多憧憬，當時耳聞有工具可以將 UML 資料直接轉換為程式碼，或是透過拖拉與設定就可以搞定程式，於是就貪心的把類似的工具當作目標尋找，雖然過程有接觸過 CakePHP ，但是覺得它離理想工具還有些差距，所以一開始並沒有將焦點放在它身上。即使在確認沒有那種夢幻般的工具後，我一開始是使用 Seagull PHP Framework 嘗試進行開發，發現它得花好長一段時間進入狀況，加上接觸當時的文件並不齊全，所以沒有繼續使用。

接著接觸到 Qcodo 這個程式架構，它強調可以自動產生更多、更完整的程式碼，一段放在網站上的展示影片吸引了我；只是吸引我的並不只有 Qcodo 這個工具，還包括他所使用的編輯器，因為在那個時候我還是使用 UltraEdit 這類只有提供程式碼醒目標示的工具(也就是透過各種顏色顯示程式碼，讓程式碼更容易閱讀)，這才更加認為自己應該在工具的使用上多下些功夫。

很幸運的，在掙扎是否要購買 Zend Studio 時，出現了一個免費的工具 PHP Development Tool ，剛好能夠滿足比較迫切的一些需求，所以現在也還是這個工具的忠實用戶。

在 PDT 的協助之下，對 Qcodo 有比較深一層的認識，只是也開始遇到了瓶頸，因為 Qcodo 背後的開發團隊不大(初期只有一個人)，使用的人也不多，加上持續發展當中，所以許多情況下得試著深入核心程式來找出問題，而能夠投入的時間有限，後來主要開發者也消失了一陣子，我就開始轉換跑道了。

期間也有試過 PRADO 與 symfony 等專案，因為複雜度較高而選擇放棄；同時間 Zend 也開始推出自己的程式架構 ，跟另一個公司所分享的 eZ Components 類似，專注在提供高品質的程式元件，並不是很吸引人。

最後，在眾多的程式架構中，我選擇了 CakePHP ，因為它的社群很活躍，進入的門檻較低，相關的介紹與教學也很豐富。

CakePHP 哪裡快？

嚴格說起來，CakePHP 的執行速度並不快，但是它的架構允許你透過各種快取來彌補執行速度不快的問題；真正快的地方是開發速度，自動產生資料增刪改查的程式、資料表的維護、多國語言的語系檔案產生以及單元測試等，這些都可以透過指令完成，而系統本身提供了豐富的元件，加上高擴充性的架構，讓 CakePHP 吸引了許多的程式開發人員。

一個典型的功能開發過程：
1.先透過工具在資料庫完成資料表建立
2.產生資料的增刪改查介面雛型
3.調整操作畫面後進行延伸功能開發
4.設計單元測試範例
5.抽出程式碼中的語言定義
6.上線前設定快取規則
7.納入權限管理設定

最值得一提的是，CakePHP 對於關聯資料的取得相當方便，許多過去要輸入大量 SQL 查詢語法才能產生的資料，在 CakePHP 中只要簡單的幾行程式就能夠做到，而且可以做完整的控制。不過這個好處只有在雛型開發時可以盡情享用，因為預設取得關聯資料的方式會產生大量資料庫查詢，這對於應用程式的速度相當不利，一些預期會需要大量使用的資料存取還是建議手動設計查詢語法。

CakePHP 的演進速度也很快，因為社群龐大，所以許多問題在自己還沒發現之前就被提出、解決了，討論群組的文章數量、網友透過部落格分享的心得以及使用各種語言的在地化社群都持續在增加當中，每隔幾分鐘就會有新資訊從世界的某個角落進入到網際網路中。

另外，CakePHP 的許多概念承襲自 Ruby on Rails ，如果是 愛好者且有 PHP 程式開發需求，CakePHP 或許是個比較快上手的選擇。

停止抱怨，開始寫程式

這個世界總是有喜歡抱怨以及聽了抱怨會擔心、害怕的人，這篇文章並不是為了對抗這種勢力而存在；我是個實際的使用者，在採用 CakePHP 後確實獲得了許多好處，希望藉由這篇文章做個分享。有人喜歡喝自己壓的柳橙汁，有人喜歡用機器壓，也有人接受工廠大量生產的濃縮還原柳橙汁，這只是選擇，別想的太嚴重。

其實很早就有人思索這個問題了，只是完整的解決方案大多所費不貲或難以掌控，對於預算不高卻隨時得應付客戶需求的小公司而言，少有機會接觸這方面資訊；在開放原始碼的世界裡，我還沒發現一個能夠完整解決我問題的方案，但是我所需要的功能其實透過一些現成的工具可以分別滿足部份需求，雖然仍有缺憾，卻已經強過什麼都沒有的窘境。備份： rsync

其實透過 Linux 環境的壓縮與網路傳輸指令，我已經能夠組合出本地端與遠端主機的備份方案，只是 rsync 提供了更多功能，像是差異備份、安全連線傳輸與錯誤控制等，讓這方面的工作簡化許多。

版本控制： subversion

很久以前就知道 CVS 的存在，但是它一堆專有名詞加上維護不易讓我遲遲無法享有它帶來的好處；但幸運的是 subversion 出現了，除了讓我克服心理障礙外，還提供了比 CVS 方便的功能，像是將路徑的變化也納入版本控制範圍等。而且還有 TortoiseSVN 這個超方便的用戶端工具。

專案管理： trac

其實我還沒真的去管理 trac 的系統，只是在一些專案中透過它與開發者互動，感覺它的介面設計相當友善，而且完整的與 subversion 結合。

=== 以下只適用於 PHP ===

API 文件產生器： phpDocumentor

其實這個工具對我自己寫的程式幫助不大，因為我的註解不多…而且很少照著它的格式…，只是用它來產生其他函式庫的文件相當方便，省去許多需要直接打開程式碼找答案的步驟。

程式碼整理工具： PHP_Beautifier

過去我並沒有遵循標準來寫程式的習慣，但是後來發現自己連自己的程式都看不懂時，我才開始逼著自己去熟悉一些標準，即使那些大多是不成文的標準；對於過去沒有照著標準走的程式碼，或是一些其他人提供的部份，透過 PHP_Beautifier 可以統一他們的風格，我因此省了很多揣測的功夫。

程式碼產生器： *

目前這個部份都還在實驗當中，因為有太多的選擇存在，並沒有任何一個具有權威性的解決方案；不過我想 CakePHP 在台灣已經有不少朋友採用， symfony 有許多開發者支持，PRADO在技術層次獲得最多迴響，以及幾乎是PHP代名詞的Zend也有相對應的方案剛在醞釀當中，這幾個應該都值得持續關注。

其實有些理想的狀態是，透過 UML制定流程與行為後，讓程式去產生所需的程式碼、API文件甚至是使用者操作手冊，這種東西用想的應該可以做到，但是離實際產品出現應該有很長的一段路得走（據說 IBM 那些貴死人的方案中已經離這個目標很近了）。有生之年不知道會不會看到 AI成熟到可以自動發掘需求然後轉化為程式…然後程式設計師只負責鬼扯…（其實現在就常常在鬼扯了…）。

總之，別將自己寶貴的生命花費在可以輕易被取代的工作上，用些現成的工具把工作早點完成，多花些時間在自己和家人身上；只是同時也得權衡輕重，別讓方便成了隨便，資訊系統的效益還是在使用者身上。

希望透過這篇文章拋磚引玉，讓各位前輩們可以秀些傳家寶給我們後進學習。

（打到一半隔壁突然傳來了一句刺耳的評論： "你真的很喜歡瞎掰ㄟ"……無言…）

一個客戶緊急求救，因為過去的程式調整並沒有留下太多文件，因此我接手後加入一些現成的模組讓客戶使用；不過最近有個網友提醒新的模組有問題，會洩漏個人資料，因此客戶要我檢查。

這個問題的原因是舊有系統的部份欄位被挪作他用，而我套用現成的模組時並不清楚細節，因此新的模組會把那些被設定為不該顯示的欄位抓過來使用，造成資料的混淆與外洩。

問題來了，我找到有問題的程式碼將它停用，可是狀況依舊；我一度以為是自己沒有找對位置，所以試著翻遍所有程式碼，後來才突然理解，新加入的模組使用了傳址方式引用函數、物件，程式在執行時會先看看記憶體有沒有載入過該函數、物件，如果有就會直接拿來用，而沒有檢查實際檔案中的資料有無更新，造成我無論作什麼調整都無法即時看到效果。

解決這個問題的方法也許是重新啟動網頁伺服器，但是這個時間點（中午）執行這個動作可能會干擾到其他使用者，因此我選擇暫時將有問題的功能整個抽離，等晚點再將它還原，並且重新啟動網頁伺服器。

經過這次的事件，對於傳址方式的好與壞多了些概念。

問題來了，我該全部改寫還是延續這個爛攤子？

全部改寫其實不會花費太多功夫，因為舊有系統的功能並不會很多，而且透過一些現成的程式架構（ framework ）很快就能搞定，還多了一堆莫名其妙的功能；特別是想要透過這次機會實做幾個先進的程式架構，藉此提昇自己。只是這樣一來，系統的複雜度增加，未來問題發生時可能不好掌握關鍵；而且加了太多新功能可能造成使用者困擾，使用者困擾的時候就是工程師的惡夢了。另外有個折衷的想法，如果將程式架構當作物件庫來使用呢？這可能有些難度，因為對於程式架構的瞭解還沒有那麼深入，隨意的拆解開來可能需要花更多的時間去深入程式碼運作流程。平常沒想那麼多，遇到的時候才想要臨時抱佛腳；選擇這個方案可能因此耽誤了專案的時程，心中想著四個字…萬萬不可…

採用現有程式架構的好處：
1. 功能一堆
2. 程式碼精簡
3. 架構容易理解
4. 文件齊備
5. 可以跟很多前輩請教
6. 自我提昇
7. 練英文…

壞處：
1. 複雜度增加
2. 架構龐大
3. 既有功能需要全部改寫
4. 自找麻煩…orz

延續爛攤子的好處：
1. 自己跟客戶都很熟悉…orz
2. …

壞處：
1. 問題一堆
2. 要打很多字（程式碼）
3. 自己看不下去
4. 以後接手的人也看不下去

比較了一下，感覺還是使用程式架構改寫比較好；只是要試著讓介面盡量跟過去一致，否則使用者可能會一堆問號，我的臉上也會有一堆線…

其實之前也在想，一個符合 CMMI 規範的 ISV 能夠有什麼樣的產能？畢竟在一個人寫程式的過程中，經常缺這個、缺那個的，而在台灣的客戶又經常趕著要，即使明白埋頭苦幹不利於長期發展，但是要跳脫那種壓力慢慢來確實也不太容易。

寫程式是一個蠻充實的工作，因為無論到那個階段都有著無窮無盡的挑戰；只是在台灣很難只做這件事情生活，三不五時就要修修電腦、送送文件。即使真的只做這件事情，台北是個很擁擠的生活環境，隨時可以聽到樓下經過一台拔除消音管的車子、因為辦公空間不足而容易因為眼前雜物分心，加上三不五時不看看新消息或透過通訊軟體跟朋友哈拉兩句好像怪怪的，所以如同之前一個阿斗仔講的，平均起來一天真正花在寫程式的時間可能不超過一個鐘頭（當然，那個阿斗仔的理由跟我不太一樣，人嘛…）。

程式設計這種事情的重複性蠻高的，特別是開發與資料庫有關的網頁程式，每次新增一個資料表就要花點時間做出相對應的增、刪、改、查，這個過程相當的無趣，特別是沒有像VB, JAVA那樣的IDE工具可用時。

剛開始看到Seagull包含了那麼多東西，所以一直想說如果要搞定它不就得看一堆文件，因此開發專案還是用自己的想法去做；但是寫到一半，天氣很熱、心情煩躁，特別是必須要做重複性高的工作時，於是又再次的下定決心去K英文文件。

昨天還有點不知所措的(其實是前天沒有睡好需要補眠)，今天就看懂了一些基本操作，而且發現真的是…方便，為什麼到現在才開始用這種東西…為過去莫名奇妙浪費的時間哀悼…

剛開始只要照著文件做一個簡單的模組就有個輪廓，接著就從現有的模組參考比較複雜的語法，把主要的物件與方法寫完後就可以執行，不用去考慮什麼呼叫、傳值與認證的問題，前端也使用樣板來產生畫面。

其實感覺跟PLOG蠻像的，只是Seagull多了些自動化與通用的函式庫(PEAR)，一個模組的基本樣貌與資料庫結構對應的物件都可以透過程式產生，參考一個比較完整的模組( user/classes/UserMgr.php )就可以把一些過去撰寫的程式移植到Seagull中，享受它的好處。

跟XOOPS比較的話，在XOOPS開發模組感覺像是爹不疼、娘不愛，可以使用的資源不多(也不熟悉)；Seagull給開發者的照顧就比較多了，除了整合了PEAR，也把一些可能想到的共用物件搞定，開發者可以專注於商業邏輯的核心。

課程中使用了 Borland 的 Jbuilder，雖然過去在學 VB 時就見識過 IDE 的方便性，因為後來都是用土法煉鋼的方式寫程式(UltraEdit )，所以慢慢淡忘 IDE 這種東西；今天跟著老師的步驟操作，發現真是方便到了極點，有很多小細節都由 IDE的智慧功能補上，也經常會出現一堆必要的提示，讓寫程式的難度降低許多。
不知道 Zend 的 IDE 工具有沒有那麼聰明，我想我該試著去找一套能夠簡化現在寫程式流程的IDE工具了！ Zend 的那個要不少錢，可能會試試 eclipse 吧。

額外一提，要搬到大房間了，結果前一個房客好像整年都沒有整理房間似的，害我清理半天還是覺得很髒；雖然不是我看過最糟的狀況，但是現在要找個乾淨的房間好像越來越不容易了…

1.管理區的選單有現成的物件可以使用，只要引入 /include/cp_header.php 執行 xoops_cp_header()，接著就可以使用$xTheme->loadModuleAdminMenu(2, \’Category\’) 來產生/modules/module_name/xoops_version.php所指定的管理介面選單；第一個參數是選單項目的索引值，第二個參數則是這個頁面的名稱。在該物件的定義檔案為 /class/theme.php

2. 內建的表單物件很難搞，把 /class/xoopsformloader.php 引入後有一堆東西要看清楚怎麼用( /class/xoopsform/* )，做個簡單的表單就要變的這樣：

 $form = new XoopsThemeForm($title, \'guide_form\', $url); $pgid_tray = new XoopsFormSelect(\'Parent Guide\', \'pgid\', $data[\'pgid\']); $pgid_tray->addOptionArray(glist($data[\'pgid\'])); $form->addElement($pgid_tray); if(!is_null($data)) {  $tid_tray = new XoopsFormSelect(\'Parent Component\', \'tid\', $data[\'tid\']);  $tid_tray->addOptionArray(tlist($data[\'type\'])); } else {  $tid_tray = new XoopsFormSelect(\'Parent Component\', \'tid\', $_GET[\'tid\']);  $tid_tray->addOptionArray(tlist($_GET[\'type\'])); } $form->addElement($tid_tray); $form->addElement(new XoopsFormText(\'Guide\'s Name\', \'name\', \'40\', \'100\', $data[\'name\'])); $form->addElement(new XoopsFormTextArea(\'Content\', \'content\', $data[\'content\'])); if(is_object($xoopsUser) && in_array(\'1\', $xoopsUser->_groups)) {  $status_tray = new XoopsFormSelect(\'Status\', \'status\', $data[\'status\']);  $status_tray->addOptionArray($status_array);  $form->addElement($status_tray); } else {  $form->addElement(new XoopsFormHidden(\'status\', \'0\')); } $tray1 = new XoopsFormElementTray(\'Action\'); $tray1->addElement(new XoopsFormButton(null, null, \'Submit\', \'submit\')); $cancel_button = new XoopsFormButton(null, null, \'Cancel\', \'button\'); $cancel_button->setExtra(\'onclick="location=\'.xoops_getenv(\'PHP_SELF\').\'"\'); $tray1->addElement($cancel_button); $form->addElement($tray1); $form->addElement(new XoopsFormHidden(\'action\', \'_save\')); if(!is_null($data)) {  $form->addElement(new XoopsFormHidden(\'gid\', $data[\'gid\']));  $form->addElement(new XoopsFormHidden(\'type\', $data[\'type\'])); } else  $form->addElement(new XoopsFormHidden(\'type\', $_GET[\'type\'])); $form->display();

3.標準的開發模式也不是很人性化，也許是我還不熟悉物件化的開發方法吧；我必須在/modules/module_name/class/classname.php 定義物件，物件的名稱還得跟檔案名稱一致，像是guide.php 這樣的檔案名稱中就是 Guide 物件(記得首字大寫)；還要定義資料庫存取物件(ResourcesGuideHandler )，然後透過 $guide_handler =&xoops_getmodulehandler(\’guide\’, \’resources\’) 取得物件。

物件開頭像這樣：
class Guide extends XoopsObject
{ … }

class ResourcesGuideHandler extends XoopsObjectHandler
{ … }

繼承的方法與特性可以參考 /kernel/object.php ，好像沒把物件搞的那麼大過 ^^||

看來XOOPS的開發人員是比較建議透過這種方式來讓模組比較好掌控，class Guide定義基本特性、方法，而 classResourcesGuideHandler 則是用來存取的主要物件，大部分放的是資料庫查詢功能，新增基本物件時也是透過Handler物件。

後來想說，等到功能OK之後再回頭改就麻煩了，所以還是透過XOOPS核心物件進行設計；也同時想到，該以目前穩定版本(2.0.13)為基礎還是拿開發中的版本(2.1.X)，後來想想還是別太皮，因為開發中的版本意味著許多的異動，沒必要盲從。

雖然已經透過網路訂購書籍，但是可能要下個星期才會出現，所以昨天晚上跑去誠品把它翻完了；好像前面半本都跟要做的事情無關，不過後半部對於一些變數的說明可以省去一一測試的時間。也嘗試去官方網站看文件，但是少的可憐；有一個用phpDocumentor製做的文件，但是版本為2.0.6，所以我自己下載工具嘗試製作文件。

不知道是我從沒真的安裝完還是以前的設定真的很麻煩，最新版本的phpDocumentor我幾乎沒有進行安裝工作就開始運作，調整一下設定就可以產生文件，而且在WINDOWS環境下不管透過WEB介面或是那個陽春到不行的指令模式都能夠順利產生，工具的作者想必技術相當高超。不過要花蠻多時間等候就是了。

氣溫的關係吧，冷氣不打開就好像靜不下來；可是開了冷氣又感覺很浪費電(真是龜毛…)。想說要去圖書館，但是大的附近沒什麼餐飲設施，小的又很多怪咖，想想還是窩在家裡好了。到底要不要開冷氣咧……