PyLabs 出發點

我只用最新的技術

2011-03-23T01:30:00.003+08:00

我們家開發產品用的都是最新最棒的技術。由於這技術太新了，所以市面上的書/文件因為趕不上這技術的發展，所以都過時了。

是這樣嗎？為什麼書的內容會過時呢？因為該技術 API / 架構不太管向後相容這件事。所以這件事講的白一點，就是 API / 架構不穩定。

這是我在 PragProg 買了某聖經後，pdf 拿到手的當下就已經過時所產生的心裡碎碎念。

然後昨天在 Debian Squeeze x64 上裝了 EventMachine 後，發現連寫個簡單的 echo server 都有問題後，我當下就爆炸了。

本篇文章先作個紀錄，等我找到問題點，我要把這兩年多累積起來的怨念，寫篇文章好好的 (嗶) 一翻。

《Got Git》附錄D Git 和 Hg 面對面之我見

2011-03-18T01:38:00.012+08:00

我在看完《Got Git》附錄D Git 和 Hg 面對面後，挑了幾個文中關於 Mercurial (後文簡稱 HG) 過時的描述與誤解予以回應，沒想到收到原作者蔣鑫的來信，希望能交流意見。因此，我將我個人意見寫出來，希望能降低因為諸如 Why Git is Better Than X 這類網站不知是故意還是無意的誤導 (比如 HG 沒有 cheap branch) ，而造成大家對 HG 的錯誤印象。

首先我想聲明的是，我完全承認 Git 是非常先進的分散式版本控制系統 (後文簡稱 DVCS) ，但若是以純 DVCS 的角色來看， HG 並不遑多讓，可說是扮演著恰如其份的角色，在功能和學習曲線之中取得了不錯的平衡點。這篇文章不會特別著墨於 HG 的優勢部份，也許會另外寫篇文章來聊這一部份的看法。

1. Git 速度比 HG 快

這點我想沒有人反對 (笑) 。不過我想補充的是，由於底層架構模型不同， Git 用速度飛快的代價換來了必須定時 repack 以避免 repo 急速增大。雖然後來新版的 Git 會在條件滿足下自動進行 repack ，但據我瞭解，目前看到的評測數據似乎都沒有計算到 repack 的時間？

另外一點，HG 的設計模型非常可靠，其會在若干次 changesets (後文簡稱 csets) 後，自動儲存一份完整的檔案內容，以確保運行的速度不會因為過多的 csets 而拖慢。這樣的設計好或不好見仁見智，但有訂閱 mailling list 就會知道，曾有人在檔案系統損毀的情況下，成功復原了 HG repo 的絕大部分資料，可靠度可見一斑。

2. HG 沒有進度顯示功能

HG 有 progress extension，其在 1.5 版之後就內建。

3. HG 的 rollback 只能一次

以功能性來說，沒錯， Git 這部份的功能比 HG 好； Rebase 也是一樣， Git 總是能做到比 HG 還要多的功能。

但 HG 的作者 Matt 曾經講過我很認同的一句話：大部分的開發者，都不如自己想像中的那麼聰明。打個比方來說，也許你程式碼改著改著，突然決定想要 rollback 過去的變動，或是想要修改歷史 (比如 rebase)。結果因為人為操作失誤，造成了程式碼的遺失。

仔細想一下版控系統的角色與定位：不就是要紀錄開發歷程，並盡可能確保過去的紀錄不因意外而遺失 (不論是不是人為) 嗎？所謂權力越大，責任越大， SVN 之所以可靠，就是因為其不允許修改過去的紀錄，我完全不用擔心將 SVN 導入工作環境後，會不會因為其他人錯誤的操作導致過去的紀錄遺失。

Git 作者 Linus 也說了： Rebasing doesn't result in cleaner history. It just results in_incorrect_ history that looks simpler.

我絕對同意 Git 功能比 HG 強大，但請不要用 "可否容易修改歷史的功能" 來評價版控系統的優劣，這並不合適。

4. HG 不支援分支

我要再度強調： HG 有支援分支。基本上 clone 就是分支的一種，不是嗎？而且， HG 從很早期的版本，就支援 Git 所謂的 cheap branch，只是在 HG 的世界裡，把它稱之為 heads (HG 的 named branch 我就跳過不說了)。

後來的 HG 有了 bookmarks extension ，這和 heads 搭配就等同於 Git 所謂的 cheap branch，後來進化成可以 push / pull bookmarks，於 HG 1.8 版甚至直接將 bookmarks 整併進核心之中。

5. HG 的 SVN 橋接功能無法將 HG 的變動送回 SVN server 上

這是過時的資訊，現在 hgsubversion 可完整的雙向同步，且其會自動 rebase 來降低人為失誤 (為何要 rebase 就跳過不說了，你如果不懂，代表你不用懂 XD)。

不喜歡 hgsubversion 會同步所有的歷史？你還可以選擇 hgsvn (功能稍微陽春，但可以限定同步的版次)，一樣可支援雙向同步。

Git 和 HG 都是很好、很成熟的工具，擇你所愛，幫助完成工作是最重要的，希望這篇文章可以幫助大家更加瞭解 HG。

關於 PyLabs

2011-03-09T02:03:00.005+08:00

2011 年 1 月 25 號，是 pylabs.net 誕生的日子。

玩 open source 的前幾年，身邊一直都沒有志同道合的好朋友可以一起討論技術以及感興趣的話題。雖然這樣也還是自己一個人摸索摸過來了，但心裡總還是很希望，可以像 Pocoo 一樣，可以有屬於我們自己的團隊...

（好吧，認識我的人應該知道，還有 Kobe 這號人物，但這傢伙說起來對抓迷物更感興趣，而且已經叛逃業界了，不提也罷。XD）

不過反正世界就是這麼奇妙，你總是會在預期之外的地方，遇到預期之外的人。高雄縣網的一年生活，讓我認識了團隊的另外兩個成員： Rellik 和 Benjamin。

Rellik 是我見過的人當中，數一數二對網路/系統有天份的變態高手。這樣講似乎有點老王賣瓜（根本就是吧！！），但是可以在短短一個月的時間，從沒有接觸過 Unix 系統的情況下，直接接管縣網的 proxy / mail / web 機器 (FreeBSD / Solaris)，這不是平常人辦得到的事情。更不要說現在他手上管的機器已經破百台了...

Benjamin 這傢伙就更離奇了，雖然和認識 Rellik 同時間認識這個人，但說實在我跟他其實不熟... 直到陰錯陽差，他莫名其妙的成為我現在公司工作上的夥伴後，才突然變熟的。XD 另外雖然他不願意承認自己很熟 Windows，但不需要這樣吧，熟 Windows 又不是丟臉的事情，是吧？是吧？XD

好啦，以上雖然是用戲謔的方式來介紹登場的兩位人物，但基本上都是高手，而且重點是都很宅！！能和這樣的高手們共組團隊，實在是非常開心阿（撒花撒花）。

咦，好像忘了說為什麼要叫 pylabs.net 了，原因是這樣的：基本上我是 Python 愛好者，而且註冊網域是我去弄的，所以另外兩位被我用半強迫的方式接受了這個名字。 XD

最後說點正經的：最近公司剛搬完家，下班也比較悠閒，所以我打算要趕快讓 Mercurial / TortoiseHG 的繁體中文翻譯跟上官方腳步，不然使用上半中半英實在是有點礙眼...

你家是如何進行 code review 的呢？ (一)

2011-03-07T01:42:00.002+08:00

[上圖取自： http://www.osnews.com/story/19266/WTFs_m]

以往傳統的 code review，都是發生在產品開發一陣子之後的事...

[情境：某次部門會議]

主管：我們開發這個產品也已經好幾個月了，下個禮拜開始，請各個開發人員準備一下投影片，我們安排時間，讓各位有機會展示一下自己的程式碼，以便促進交流。每個人要準備 15 分鐘的投影片來報告整體架構與程式碼... @#$#%^$%

新進阿宅工程師一號心想：啊？ code review？沒做過耶，靠腰我要準備什麼阿... (狀態顯示為兵荒馬亂中)

資深阿宅工程師二號心想：阿？ code review？還來？上次被批的體無完膚，這次得想辦法~~隱瞞事實~~改善投影片以免重蹈覆轍...

為什麼要做 code review？原因在於，在開發產品過程中，各個模組也許是由不同的團隊在開發；藉由 code review，"理論上" 可以交流對彼此的架構觀點，進而讓產品的架構更加穩固。除此之外，在同一個團隊中，工程師也有程度深淺的差距，藉由 code review，"理論上" 可以讓資深工程師對資淺工程師給予改進的建議。以上都是理想上 code review 應該要達到的效果... 理論上啦。 XD

傳統的 code review 流程，都是在產品開發過程中，"定期" 的以讀書會的方式，使用投影片來讓其他人得知你的程式碼內容與系統架構，但是這種傳統的作法有以下幾個問題：

只展示程式碼片段，與會的其他工程師無法得知更宏觀的架構。
使用 UML 等方式來展示系統架構，但是說到底，這並不是程式碼，這樣其實會失去 code review 的意義。
流於批評、沒有聚焦在應該需要檢討的部份。展示的人有可能會隱瞞有問題的程式碼，以避免被批評；與會的工程師也可能會無法給予較有意義的建議 (因為只看到片段的程式碼嘛，給予的建議就容易變成 "你縮排要空四格" 諸如此類的建議...) 。

你家就是用這樣的方式做 code review 嗎？那你應該要多多接觸 open source 社群，看看別人是怎麼做 code review 的... (待續)

該來寫寫東西了

2011-03-04T02:34:00.005+08:00

脫離了學生時代的米蟲生活，開始進入業界工作後，深深的為那些能在工作之餘，持續的更新自己的 blog 的前輩們致上最高的敬意...

雖然因為進入業界，以過去學生時代好幾倍的速度成長學習，但下了班之後只打算放空休息，完全提不起勁來寫 blog 紀錄工作心得...

然後呢，因緣際會的拿到了 pylabs.net 這個網域，就想說剛好趁這個機會，把荒廢已久的 blog 重新建立，希望之後能將一些成長紀錄放在這裡...

希望各位多多指教，Ninja~~ (車子引擎啟動聲)

小黃部長~~~ (熄火聲)