Unlimited Build Works

QML Snapshot Testing與TDD的連㩗

noreply@blogger.com (Ben Lau) — Sun, 06 Aug 2017 13:57:00 +0000

到底應該怎樣做GUI的自動化測試呢？這個問題一直都困擾著我。

並不是不會做，而是怎樣做得有效率，基本流程有三個步驟，首先要模擬環境、然後模仿實際輸入，最後核對結果。

要是架構設計失誤，光是第一步的環境模擬就夠嗆了，模仿輸入及核對結果就是一項會隨test coverage要求上昇而變得更加吃力的苦力工作。

最慘的是每當UI設計修改，以前寫的test case就有可能要面臨推倒重來的困境。

在UI改動頻繁的項目，我甚至會直接放棄自動化的GUI測試，盡量簡化UI的元件，只把力氣放在程式邏輯及數據上，直至我見到Jest的Snapshot Testing。

Jest - Snapshot Testing

有一種GUI的自動化測試方法會制作元件的Screenshot圖像，再跟之前的版本進行對比，若然二者不符測試就會失敗，要麼修改程式、要麼更新Screenshot。

Jest的Snapshot Testing的概念也是一樣，但不弄screenshot圖像，而是把視覺元件轉換成一個像XML/HTML的文字描述的snapshot，然後作出比較。

這樣子就不用找地方存放圖像，可以直接把文字描述直接存放在版本控制內。

在見識到這種GUI自動化測試方法後，我就一直在想能不能拿到QML上用呢？會不會可以解決很多問題呢？

QML - Snapshot Testing

為了把Snapshot Testing帶進QML中，我試著做了這個項目。

QML Snapshot Testing
https://github.com/e-fever/snapshottesting

跟Jest的版本不一樣，文字描述並沒有使用XML的形式，改為使用像QML語法的表達方法，同時加入了GUI版本的”比較視窗”，可以提供更加詳細的資訊。

安裝及使用方法等就不在這裹談了，可以看Github的說明，這裹想寫的是有關於TDD的配合。

Test Driven Development

在Jest的FAQ提過TDD並不適合配合Snapshot Testing使用，主要問題是人手寫Snapshot file（即是那個UI的文字描述）太麻煩，Snapshot Testing的原意並不是提供設計指引，而是找出有沒有出乎意料的修改。

但QML的Snapshot並非完全跟Jest一樣，有二項很大的分別：

QML版提供GUI的介面，不單提供Diff，還可以瀏灠完整版本的Snapshot
與此同時，被截取Snapshot的UI元件依然可以運作，開發者可以手動輸入並用肉眼視察結果

就著這二點的不同，要進行TDD式的做法並非不可能的事。

TDD的主要精神有2個 -「Write Test code first」、「Red-Green-Refactor Cycle」

我會用以下的例子說明如何利用Snapshot Testing並配合TDD的2個要求

任務：寫一個元件，最初會顯示”Ready?”，點擊後會變成”Go!"

工作一：Write (Failing) Test code first

大概是這個樣子。（程式代碼）

tst_CustomItem.qml

import QtQuick 2.0
import QtTest 1.0
import SnapshotTesting 1.0

Item {
    id: root
    width: 320
    height: 240

    CustomItem {
        // Don't put this under TestCase object.
        id: customItem
        anchors.fill: parent
    }

    TestCase {
        name: "CustomItem"
        when: windowShown

        function test_CustomItem() {
            var snapshot = SnapshotTesting.capture(customItem);
            SnapshotTesting.matchStoredSnapshot("test_CustomItem_default", snapshot);

            mouseClick(customItem)

            snapshot = SnapshotTesting.capture(customItem);
            SnapshotTesting.matchStoredSnapshot("test_CustomItem_clicked", snapshot);
        }
    }

}

至於CustomItem的內容就先讓他一個預設的內容 - Item {}

這樣測試程式⋯⋯就完成了！

咦，不用測試顯示的文字嗎？

正常來說需要這個步驛，還要提供介面，告訢元件以外的人正在顯示的文字.

/// CustomItem.qml
Item {
    property alias displayText : text.text
    Text { 
        id: text
    }
}

但這個屬性本身僅僅是為測試提供服務，本身是沒有需要的。

在用了Snapshot Testing後就不再需要用到這個屬性，即管跑一跑以上的程式吧。

因為是第一次執行，並沒有儲存過任何snapshot，所以Snapshot.matchStoredSnapshot會彈一個”比較視窗"出來詢問，概然CustomItem還只是個空白的元件，當然回答”No”，測試程式回報失敗，我們寫了一個失敗的測試，第一項工作完成。

工作二：Red-Green-Refactor Cycle

現在測試程式亮紅燈，無法通過，開始寫CustomItem

import QtQuick 2.0

MouseArea {
    Text {
        id: text
        text: qsTr("Ready?")
        font.pixelSize: 28
        anchors.fill: parent
        verticalAlignment: Text.AlignVCenter
        horizontalAlignment: Text.AlignHCenter
    }
}

再跑一次測試程式，同樣地停在相同的地方，但不同的是程式的視寫中顯示了”Ready?”的字句。

經過肉眼的判斷，程式符合預期，所以按下yes.

之後程式繼續跑，模擬滑鼠輸入後，又進行了一次snapshot test，基於MouseArea沒有實現所需的功能，故此元件仍然顯示”Ready?”，選擇”No”

再做一次修改吧，這次加入所需要的功能。

import QtQuick 2.0

MouseArea {
    Text {
        id: text
        text: qsTr("Ready?")
        font.pixelSize: 28
        anchors.fill: parent
        verticalAlignment: Text.AlignVCenter
        horizontalAlignment: Text.AlignHCenter
    }

    onClicked: {
        text.text = "Go!";
    }
}

因為UI沒有修改，第一個Snapshot Test會直接通過，再次停在第二項測試。

這次沒錯了，所以按”Yes”，大功告成，可以commit push上伺服器了

任務三：UI規格修改

對開發者來說規格的修改是最為苦惱的，改動太大或許會讓前功盡廢，其中受到影響最大的多數是自動化GUI測試。

假設現在要一項小的修改，文字要要改成大寫”READY!?” / “GO?”，所以CustomItem變成

import QtQuick 2.0

MouseArea {
    Text {
        id: text
        text: qsTr("READY?")
        font.pixelSize: 28
        anchors.fill: parent
        verticalAlignment: Text.AlignVCenter
        horizontalAlignment: Text.AlignHCenter
    }

    onClicked: {
        text.text = "GO!";
    }
}

（註：其實用font.capitalization便行，但示範就裹就不用這個方法了）

再跑一次Test Case，因為Snapshot不符的關係，比較用的UI又再次彈出來詢問，當然全部都回答”Yes”。

在就這種小改動的情況下，用上Snapshot Test的測試項目甚至不用作出任何的修改，程式會自動找出被改動過的元件，經開發者確認後便自動修新，這大大滅輕維護的成本。

結論

當QML的Snapshot Testing配合TDD使用時，有一點跟傳統的做法不同，就是不用先寫預期的條件判斷，在開發的過程中改為經肉眼判斷是否正確，一旦確認正確，SnapshotTesting便會自動記錄在案，那些超煩人判斷條件都交由SnapshotTesting負責，變相減輕篇寫測試程式的工作量。

20萬用戶成就達成！

noreply@blogger.com (Ben Lau) — Sat, 08 Apr 2017 13:06:00 +0000

Dualless的用戶數人數突破20萬了！太感動了，謝謝大家的支持！

又來超糟糕的登入設計

noreply@blogger.com (Ben Lau) — Fri, 29 Apr 2016 07:58:00 +0000

我想差勁UX的極致表現就是懲罰用戶，用戶每次使用都會叫苦連天、氣得血氣上湧，其中一個例子是上一篇文章中「再見了，超糟糕的登入設計」中提過的一個超糟糕的登入設計，幸好對方已經放棄這個設計，用戶不用再受苦。

但最近從Facebook上的朋友處得知，有銀行採取了相若的登入設計。

圖片於2016年4月29日截取

首先輸入密碼必須使用虚擬鍵盤，然後大家有留意到數字盤的問題嗎？竟然不是常見的排位，是會隨機改變的！

而且－－－

用戶名稱要最少3個數字，以及採用大小寫英文字母！？用戶名也是密碼嗎！？

傳送門：

電子網絡銀行服務
點擊登入，選擇電子網絡銀行服務

繼續站著工作 - 自己動手做standing desk (流動版)

noreply@blogger.com (Ben Lau) — Sat, 05 Dec 2015 12:59:00 +0000

上一次寫standing desk有關的文章已經是2年前，本身也用了相同的時間，別以為我會因此變得能站個8小時不停，那恐怕比坐8小時所造成的傷害更大，主要都是交替姿勢，時坐時站。

身體是否有因此變得健康呢，實在很難說，減肥的作用就肯定地說沒有效果，不過腰痛的問題就機乎不會出現。曾經試過因為運動而弄傷膝頭，坐了幾天，腰就開始酸痛。頸就沒法了呢，唯有多點轉動。

在上一篇文章中提過幾張可以在香港買得到電動昇降桌，價錢都比較高，或許大家都未必願意花那個錢吧？

不過有一個好消息，Ikea的Bekant昇降桌(油壓)已經來到香港了！價錢是HKD $1890。

BEKANT 五邊形書檯 - 棕黑色/白色 - IKEA

不過最合用的地方應該是辦公室，在家的需求沒那麼大，但公司不配合就沒辦法。

Ergotron Workfit-s可能是個比較好的選擇。

如果閣下在辦公室也是用Laptop電腦的話，這裹有一個更划算的方法：

LEVIT8: The Flat Folding Portable Standing Desk. by Levit8 Co. —Kickstarter

這個是Kickstarter的籌款項目，簡單來說就是一個portable laptop stand，但高度是為站立使用而設計的。

價錢只是USD $32 (連運費$40)

筆者的行動

不過集資期而過，而且預計出貨日期是2016年6月，作為Backer之一的筆者也覺得實在是太久了。

結果在無法等待的情況下，決定自己動手做了一個：

成品！！

跟13" MBA的比較

材料：

50.9 x 38cm的大硬卡紙二塊 HKD $15
少量黑色膠紙 $0

工具：

界刀一把
60cm 鐵尺一把

成品呎吋：

摺疊狀態：23*38cm
打開狀態：23*23*30cm

用的材料只是硬卡紙，不過已經有足夠的承托力放置13” MBA，而且雙手可以壓在MBA上，本身也很穩定。

缺點是打開時不是那麼順暢，要一點技巧，摺就很輕鬆。

優點當然是價錢以及可以度身定做，事實上筆者自制的版本的高度就比Levi8 M為高，但又比Levi8 L小巧。

至於怎樣制作呢，首先建議大家跟video用A4紙試作一次：

Folding Techniques For Designers: Other Pleats on Vimeo

意外地簡單吧？

在正式制作前要先考慮一個問題－尺吋，你要多高呢？

假設你要做一個高度為H，你需要4張闊度為W、長度為L的紙。

他們之間的關係依從畢式定理：

W^2 + H ^2 = L^2

W的建議大少為23cm，這是跟MBA相應的大少。

步驟：

1) 在材料上按所需要呎吋畫上剪裁線

因為邊長最少要92cm (23 * 4)，要買這樣的硬卡紙並不容易，可以斬成2份，又或者4份，之後在步驟(5)時用膠紙連著便可以。

2) 用界刀把不需要的部份裁走

3) 在需要摺合的位置上用界刀輕輕地畫上一刀，方便下一個步驟

不小心界破也沒關係，可以在步驟5中救回，但呎吋偏差太大的話就請重造吧。

4) 按線段摺合卡紙，二個方向都要摺一次。

5) 用膠紙進行連接及為接口進行補強

6) 摺成這個形狀

7) 雙手放在這個位置，然後翻開

這裹有一點小技巧，很難說明，請自行多嘗試幾次。

8) 完成！

受材料所限，展開的過程沒Levit8的影片般那麼輕鬆，要依一個正確的程序，材料方面也不算輕，跟Levit8相比有所距離，而且概不防水，外表也不特別討好，果然是商業的設計比較棒，當Levit8出貨之後我會建議大家去買一個回來更好，現在就先用手作品來湊著用吧。

就這樣無論在家又或者辦公室都有standing desk用了。！

家中其他的Standing desk組合：

放置流動設備的斜架

Laptop專用的區域

再見了，超糟糕的登入設計

noreply@blogger.com (Ben Lau) — Wed, 25 Nov 2015 15:20:00 +0000

轉用SmarTone的服務有近一年左右吧，當初在建立了網上戶口後就跟自己說－「誰叫我登入SmarTone，我就跟他反面。」

因為那個登入系統實在太糟糕了，無法想像是什麼人、擁有怎樣的思路才可以設計出這種概不特別安全，又會充份懲罰用戶的登入介面。

今天SmarTone寄了一個電郵過來，說簡化了用戶名稱及密碼的要求：

很普通，沒什麼奇怪吧？

對，因為這才是正常的，是過去的SmarTone把東西設計得太變態了！

(1) 首先，用戶名稱跟密碼要求一樣：

這是搞什麼啊？為什麼用戶名稱要有大細楷及最少3個數字？用戶名稱本來是一種可以告知別人也無妨的東西，SmarTone當我們都是特工，連名字都不能告訢別人嗎？

(2) 虚擬鍵盤輸入?!

當時不能用實體鍵盤輸入，一定要用On-screen的虚擬鍵盤，而且你們有發現到嗎？

鍵盤上的數字不是按1-9,0這種順序擺放，而且每次輸入都會重排。

天啊！！這是什麼懲罰？

用滑鼠打虚擬鍵盤已經夠慘了，按鍵的位置還會改變。

大家記得建立帳戶時有一個慣例是什麼嗎？

就是輸入密碼二次。

用這工具輸入2次最少有3個數字的密碼？

在錯誤輸入了數次後，還會出現：

在經過無數嘗試、失控地拍了三次檯面，總算成功地建立了帳戶－之後一年我都沒有再登入過。

SmarTone終於放棄這些懲罰用戶的措施，實在是一件令人感到高興的事－－－－－但我記不了自己的帳戶名稱，你可以幫我改回一個正常的名字嗎？

Dualless - 10萬用戶達成紀念

noreply@blogger.com (Ben Lau) — Sat, 10 Oct 2015 15:39:00 +0000

自從在2012年發佈Dualless自來，經過3年多的時間，就在昨天用戶的人數終於突破10萬了！

特此一貼以示慶祝，並且想向各位支持者說一聲：「謝謝！」

記得在最初發佈時，就想著做一個實驗，就是在不費力氣宣傳的情況下，用戶數會怎樣增長呢？

在3年後達到這個數字應該不能說很好，但也不算太差吧。

不過最初獲得2千用戶時就費了近半年的時間(當時估計有一半用戶來自越南)，當初就因此太過灰心而放棄實驗，雖然還有更新，但不再關心用戶數。

現在回想起來，花費的時間總算沒有白費。

p.s Dualless的source code已經由Launchpad搬了去Github.

2015年10月10日的螢幕截圖

Side Project : Team Color - 在試算表上研究顏色

noreply@blogger.com (Ben Lau) — Mon, 29 Jun 2015 03:26:00 +0000

在做正式產品時總是想做點side project，這大概是多想法的人的宿命吧？希望大家都不會變成這樣子就好了...

雖然現在公司的成員都是香港人，但基本上以remote team的方式運作，有時候想要一個問題的答案並不是立即便知道。

你說用Instant Messenger不就行了嗎？那麼你可以在05:00立即回應嗎？你可以在跟男/女朋友獨處時也回應嗎？

實在太多老闆認為Instant messenger就代表要立即回應，殊不知只會令員工更加討厭公司的事務。

所以一個knowledge base對remote team是很重要的，有問題先在裹面找，找不到再來發問。

在我們開發時其中一樣需要記錄的是色版，一個程式在什麼地方該用什麼顏色，這是設計師的工作，但設計與開發並不一定是同步，開發者有時候要在設計師回覆前工作，而設計師在思考用色時又需要參考原來的色版，以避免每次都用不一樣的顏色，做出不一致的設計。

最初我們用Google Spreadsheet記錄，不過開發者沒有只看Hex Color便知道顏色的能耐，故要求設計師要把Cell的背景色設定到跟內容一樣，但因為色版改了很多遍，變成了壓惡性工作。

最終的解決方法是寫Add-on，在用戶輸入十六進位的顏色代碼後就會自動把背景顏色變成該顏色.

就這樣啪啪啪的輸入:

#
#F
#FF
#FFA
#FFA5
#FFA50
#FFA500 [Enter] 立即變色

然後我們把這個視為side project放了出來，並取名為 Team Color

TeamColor的功能:

輸入16位的顏色代碼後，背景顏色會自動轉成該顏色
支援3/6/8位的16進制碼，8位為ARGB碼
提供Custom Formula用來處理顏色(e.g colorRgb, colorArgb , colorSetOpacity , colorRed , colorSetGreen etc) 詳細請看說明文件
反轉文字及背景色

可以在Google Spreadsheet上玩漸變色啊

安裝連結: Team Color - Google Sheets add-on

在試用後能給我們意見回饋及星星嗎？如果想到有趣的use-case，不妨分享一下～

相關文章

#github 我都只是fork別人的project，你fork我又何苦呢

noreply@blogger.com (Ben Lau) — Sun, 01 Feb 2015 05:30:00 +0000

以上標題沒什麼特別意思、動機，只是有天隨便在Facebook上說的話，怎料大家的回應都很"奇妙"（笑）

近況

noreply@blogger.com (Ben Lau) — Wed, 25 Jun 2014 04:55:00 +0000

很久沒空更新了，若說近況如何，我覺得這張圖就能解釋。

註：

Testing的東西不一定只是code，還有不同的生活方法
作為fans向遊戲的SAO虚空斷章讓我感到很滿足。

讓Github幫你管理放在Amazon S3的網站 - 網站更新的自動化部署

noreply@blogger.com (Ben Lau) — Sat, 01 Feb 2014 04:47:00 +0000

用版本控制軟件(Version Control System)來管理網頁並非什麼稀奇的事情，概能容許多人同時修改，又可以追蹤變化，除了這些優點外，配合自動化部署(Auto Deployment)系統更可以自動把內容上傳到網站，大大簡化繁複的部驟，減少出錯的機會。

這裹我會用Tinyboy開源3D打印機計劃的網頁做例子，講解怎樣用Github及Travis-CI來管理網頁的發佈，設定好後絕大部份的發佈工作都可以經Github的介面完成，不用裝FTP，也不用碰網頁服務器，而且所有發佈都有記錄可尋，隨時都能回復(Rollback)到舊版本。

理論上以下的框架也可以應用到其他軟件的自動化部署上，需要的是只是按個別需求客制化。

預覽流程

一般來說開發者／設計師都能在自己的電腦內查看及修改網頁內容，不過有時難免會大意弄錯，所以讓其他人檢查及回饋意見也很重要。那些Reviewer卻未必像開發者／設計師般精通技術，可以自已下載最新版的網頁，故此一般都會上傳一個預覽的版本供他們觀看。

把這個過程自動化可以節省不少力氣，不用重覆“修改->上傳”的步驟。

流程

開發者／設計師利用Git把最近的修訂推到Github
Github會通知Travis-CI進行自動化的部署
及後Travis-CI再把內容上傳到Amazon S3檔案伺服器，該伺服器提供http://www2.tinyboy.net 預灠網站的內容
Reviewer在不同設備、瀏灠器上查看 http://www2.tinyboy.net
然後回饋意見給開發者／設計師，讓他們再重新修改

Travis-CI

Travis-CI是一套為Github而設的Continuous Integration(CI)系統，每當收到新的commit就會自動執行測試程序，若成功則進行部署動作，過程中發生任何錯誤都會用電郵告知。

Travis CI: Getting started

Amazon S3

S3是Amazon提供的檔案伺服器，功能繁多，包括存放靜態網頁，因為價錢划算加上有API支援，這使得S3很適合用作自動化部署系統的一部份。

以美國東岸N. Virginia計算，少於1TB的情況下，每GB的儲存費用是USD $0.095，流量則是USD $0.12/GB，每1000個請求是USD $0.005，而且使用越多單價越平，加上Amazon經常派Coupon，基本上可以不太花錢就能擺放靜態網頁。

正式版本的發佈 - Pull Request

預灠版本是為了收集意見及測試之用，過程全自動，並不存在任何審批的流程。但正式版並不一樣，總不能把未檢查的內容向公眾發佈，故除了各位Reviewer外，通常也會有一個至數位Gatekeeper存在，由他們操刀釋放正式版本。

S3並不支援FTP上傳，必須配合專用的工具，這使得Gatekeepr必須懂得使用這些工具，也需共享[密碼]，前者要求用戶學習，然後後者又要擔心不小心讓密碼外流，出了事也沒有方法追查成問題所在。

最理想是用戶本身有自己的帳戶，然後上傳又能留下記錄追查，在這些要求下，github是個不錯的選擇。

流程

當Developer / Designer希望發佈正式版時，他們在Github上向Release分歧提交一個Pull request的伸請
Gatekeeper在Github的介面上批準這個伸請
Github從Master分歧中把修訂整合到Release的分歧
Github通知Travis有新的修改
Travis把內容上傳至www.tinyboy.net的S3 Bucket

在這流程中應用了一個Github的功能 - Pull Request，平常在軟件開發時會有機會出現不同的分歧，這個機制可以讓Github幫你進行分歧內容整合的動作，並且在網頁上留下記錄。

基於這個特性，也可以用作正式版的發佈之用。首先在這個項目中有二個分歧，一個是master，平常工作的地方，任何修改都會自動上傳到預覽網站。

另一個分歧是release，平常不會修改，當需要發佈正式版時，就會向這個分歧提出一個Pull Request。

Gatekeeper只要查看這個Pull Request的細節便能得知有什麼地方被條改了，Github的介面甚至能顯示圖檔在修改前後的變化：

Pull Request #2 · benlau/tinyboy

確認一切妥當，只需要按下這個按扭便能發佈：

參考文件

不明白Facebook的苦心就不許使用Facebook啊

noreply@blogger.com (Ben Lau) — Fri, 01 Nov 2013 07:25:00 +0000

Facebook一直在說要讓全世界都能找到你("Who can lookup your Timeline by name")，這次的改動不再是突然而來，而是有所準備而來，大概是以前被人罵了太多遍吧。

不過我沒有興趣去理解，因為這本來就是強逼性的行為，理解了又如何？可以反對嗎？可以伸訴可以反對，那才有了解的意義。所以間中彈出來叫你去了解的提示全都被我無視了。

到了昨天，由不定期的提示變成固定、除非你表示"OK , I Understand"否則繼續下去。

那又如何？繼續被我無視。

然後到了今天，終於不許我用Facebook。

除非按下"OK , I Understand"，不然就無法使用Facebook，唯一例外是Mobile版本。

為了先向其他用戶傳播這個消息，我安裝了User Agent Switcher的插件，扮成Android貼文，那時大概是14:40左右。

一小時回來，發現這個漏洞已經被堵了，只要你的browser曾經用原來的agent設定連上，後來再改成Mobile也沒用。

看來Facebook已經下定鐵心，逼用戶“了解”，即使根本無法了解。包括以沉默對抗的權利都會被剝奪。

2013-11-01 16:14 在Desktop browser裹用m.facebook.com可以跳過限制

開始站著工作 - 自己動手做Standing Desk

noreply@blogger.com (Ben Lau) — Sat, 28 Sep 2013 05:41:00 +0000

[關於流動的standing desk組合，請參閱新文章：繼續站著工作 - 自己動手做standing desk (流動版)]
不知是因為年紀日長、還是缺少運動，這年間感覺到專注力、健康等都有所下降，在這時留意到越來越多人站著寫程式，聽說比起坐下來健康。

站著寫程式兩年後我身體上的變化 - Inside 硬塞的網路趨勢觀察

7 Amazing Benefits of a Standing Desk | Jeff Sanders

站一站有助健康 | PanSci 泛科學

實際使用後覺得這方法真的非常之累，一小時是極限，之後坐下來就不想再動。

但在這過程中卻不怎樣會分心，異常地集中令效率提昇，至於要休息的問題反而是好事，有效地提醒自己要改變姿勢，及令眼晴休息。（比軟件有效）

那時候的Standing desk：

這是用現有的實惠(PriceRite)鐵架組裝的，只是改變層板的高度遷就自己而已。高度上挺不錯，可是很貴，而且有一個致命的缺點 - 不穩定。

只是打字產生的震盪就會令Monitor產生搖晃，變相令眼晴更容易疲勞，就算是Ikea的鐵架也有同樣的問題，看來是這材料先的天性的問題。

選項有二:

☐ 買現成可昇降的桌子
☐ DIY - 繼續自己組裝傢俬

Freemax TCT-G3

Freemax的TCT-G3 Desk是一張很讚的人體工學桌，有三種姿勢任君選擇，在陣列室使用過非常之滿意，不過加上螢幕掛架就要近HKD $8000，價錢有點難以抉擇，而且我要先把家中的L型書檯拋了才容得下，工程過於浩大。

Ergotron Workfit-s

Ergotron's Workfit-S可以加在原有的電腦桌上，價錢也沒有TCT-G3那麼昂貴，不過來貨等候時間很長。

DIY

同時我也在找有沒有其他比較便宜的方案，在網上最多人的做法是用Ikea的LACK角几改造：

Source : A standing desk for $22

這個做法概便宜又方便(HKD $79.9一張)，可是遇到一個問題，原來放鐵架的地方並沒有桌子，要先買一張桌子後再放這個LACK角几，如果桌子下面的空間只能放雜物的話，那會相當之浪費。

最後的解決方法還是用了LACK角几，但不是一張，而是2張：

最底一層放雜物，中間放打印機，上面則是工作的空間，讓空間的使用效率大大提高。

用2張LACK角几充當儲物空間，是頗出名的Ikea Hack，一來便宜，二來輕巧(LACK角几是非常之輕的）。

然後在上面再放床頭几(RAST BDS TABLE)，在組裝時底板不要上足三口螺絲，並讓底板拉出一點，從側看會呈現一個L的型狀，之後再放一塊木板提供Keyboard及Mouse的活動空間便大功告成！

在Keyboard板及Lack角几之間有一個空位，可以放入雜誌、常用文件等東西。

中間可以放書本或文件架、在使用電腦時參考紙本的內容。

材料

RAST BDS Table 52x30 129.90
LACK Side Table (55x55cm) 79.9 * 2 = 159.8
EKBY LAIVA SHELF 24x59 $39.9
幾口鋼牙螺絲

總造價：$329.6

規格：

Keyboard離地高度 : 97cm

Monitor離地高度 : 130cm

簡報上線 : Making Chrome Extension with AngularJS

noreply@blogger.com (Ben Lau) — Thu, 22 Aug 2013 16:03:00 +0000

Making Chrome Extension with AngularJS from Ben Lau

這是我在第三次HK Web Developers Meetup上做的簡報，雖然主題是Chrome Extension及AngularJS，不過結果聽眾的關注點都放了在Web Store上的Malware XD

p.s 在簡報中間，我拿了一個Web Store上的Malware做例子，講解Chrome Extension的結構

第二屆Hong Kong Mini Maker Faire

noreply@blogger.com (Ben Lau) — Tue, 13 Aug 2013 15:00:00 +0000

為了推擴Marker文化、靈感創意、DIY製造，創意設計及巧手工藝之完美結合，並推動本地創意產業及科技產業有所啟發，一群有心人將會舉辦一項名為Hong Kong Mini Maker Faire的活動!

這次是第二屆舉行，將於今個星期六(2013年8月17日)在PolyU的N112~N116室進行~歡迎大家參觀及互相交流!

2nd Hong Kong Mini Maker Faire

另外我有份參與的Tinyboy計劃也會參加這個活動，屆時會展出由我們設計的小型3D打印機，並向大家分享如何把3D打印用在教育上的各種心德經驗。記得來我們的25號攤位啊~　謝謝大家!

誠徵開源軟件測試者 - Dualless 0.4 RC

noreply@blogger.com (Ben Lau) — Sat, 20 Jul 2013 16:20:00 +0000

我準備發佈一款叫做Dualless的Chrome擴充套件的0.4版本(開源軟件)，不過因為有些UI的嘗試，希望在Chrome Web Store發佈前能有人幫忙測試及給予意見改善，有沒有人願意幫忙呢?

下載檔

這個軟件可以在Chrome裏進行視窗分割，把視窗分割成3:7,6:4,5:5等各種比例。

那麼用家可以一邊瀏覽Twitter/Facebook/Plurk，另一邊觀看其他網頁，又或者打開Google Keep/RMilk/Wonderlist的工作清單然後同時工作。

用法就跟一般的雙螢幕配置一樣,但不需要實際地使用二個螢幕,因為現在的16:9螢幕已經有足夠的解像度讓二個視窗同時顯示,Dualless活用這項特性來模擬雙螢幕的效用.

V0.3 功能

以特定比率分割視窗

同時支援水平及垂直分割

合拼視窗

把二個視窗合拼成一個，並且以最大化形式顯示

複制分割

按著滑鼠中間鍵點擊分割視窗，會在分割出來的視窗上打開一個跟現在分頁上同樣的網頁　(試幻想你在Google Drive中修改一份很長的文件，突然間發覺需要查看幾頁前的內容，用這功能就不用把畫面移上去又移回來)

Mac OS的視窗管理模疑

分割後的視窗會自動霸佔整個畫面，在移到其他應用程式再回來，也會保持這個現像

V0.4追加功能

自動最大化

進行過視窗分割後，如果其中一方被關閉，另一個視窗會自動進行最大化佔據空白的空間

當中最需要測試的是書籤功能,那功能讓分割的同時載入一個已登記的網站，讓用戶記錄習慣了的使用模式，例如把工作清單的網頁放在右邊，把聊天網站族在左邊等等。

有誰能幫個忙嗎?

關於Bookmark功能的描述　(不看文件也可以，如果自己可以模懂怎樣處理，就代表UI沒有問題 :D )

Dualless - Bookmark

下載檔

安裝方法:

在Chrome，打開工具 - 擴充功能
把已下載的crx檔,Drag and Drop至"擴充功能"畫面
確認後就能安裝

介紹影片

第二屆 World Internet Developer Summit !

noreply@blogger.com (Ben Lau) — Tue, 18 Jun 2013 14:33:00 +0000

香港一向都缺乏大型的開發者活動或會議，而World Internet Developer Summit是其中十分難得的一個。今年是第二年舉行，題目是 big data: Cloud - scale your application to million users，邀請了來自Google ， Linkedin ， Twitter ， Mozilla ， Microsoft ， Square及Blackberry等世界性機構的人來分享他們關於Big Data及把應用擴展於數百萬人規模的經驗。

日期: 6月27-28日
地點: Cyberport (27號) 及科學園(28號)

詳情及報名:
http://www.isoc.hk/wids2013/

參考資料:

科技巨擘雲集暢談大數據 | 香港互聯網協會 | 主場新聞

=== 不正經的分割線 ===

記得xdite提過「辦出人人滿意的網路聚會之黃金三點」，分別是「正妹、網絡、食物」，要是每個活動都有以上三點，你說有該好呢?可惜就是太理想，而現實總是殘酷的.... 事實上有個不錯的網絡,還有令人滿以的紀念品,我就已經心滿意足...

上年派的Facebook手指不少人爭著搶,今年的紀念品好像也不錯?

(轉自Facebook)

週末的軟件開發計劃 - Angular Loading Promise

noreply@blogger.com (Ben Lau) — Sun, 16 Jun 2013 15:51:00 +0000

有太多時候想做一件「實事」是非常之困難的，有無數的東西要先打點及考慮，無論是資源，人際關係，市場等等，結果與想做的事越走越遠。

放開這些得失，不考慮計較成敗，只是盡力地投入一項工作，意外地有著調整身心的效果。

所以有時會構思一些可以在週末完成的開發計劃，而今個星期的結果就是一個叫做Angular Loading Promise的套件:

Github : benlau / bnloadingpromise

當你做一個網頁的時候，有時候會希望可以當所有資源都載入之後才顯示，在這之前則顯示Loading Spinner的提示。

而這個套件的作用就是讓你的Angular應用可以輕鬆地做到這個功能，甚至不用寫上JavaScript.

例子:

<html ng-app="bn.loadingPromise">
<head>
    <title>Demo1 - Use it without coding</title>
</head>
<script src="lib/angular.js"></script>
<script src="../src/bnloadingpromise.js"></script>

<body>
    <div bn-promise-show="loading">
        Loading <img src="assets/ajax-loader.gif">
    </div>
    
    <div bn-promise-hide="loading">
        All the content loaded.
    </div>
    
    <div style="width:680px;" bn-promise-show="success">
        <img src="assets/01.jpg" bn-promise>
        <img src="assets/02.jpg" bn-promise>
        <img src="assets/03.jpg" bn-promise>
        <img src="assets/04.jpg" bn-promise>
    </div>

</body>

</html>

示範:

Demo1

在以上的例子裏只是使用了3個directive : bn-promise ， bn-promise-show ， bn-promise-hide。

bn-promise
只要把bn-promise加入標籤，那影像的載入就會被追蹤

bn-promise-show / bn-promise-hide
二者的的作用跟ng-show及ng-hide差不多，視乎狀況決定DOM tree的顯示與否

。

雖然bn-promise-show不及ng-show般用途廣泛，但因為針對資源載入，可以簡單地設定loading spinner。

例如說:

<div bn-promise-show="loading"> Loading... </div>

以上的內容只有在Loading時會顯示，當所有資源都載入後就會自動消失。

那樣就能簡單地做出Loading spinner的效果。

註:進階使用方法請參考Github網頁

。

新簡報上線: Effective TDD - Less is more

noreply@blogger.com (Ben Lau) — Sun, 12 May 2013 05:25:00 +0000

Effective TDD - Less is more from Ben Lau

擴充Google Docs的應用(1) - 在試算表中建立連結

noreply@blogger.com (Ben Lau) — Sun, 05 May 2013 09:00:00 +0000

Google Docs的強大在於協同寫作的能力，幾個人一起修改較對，飛快地把文件弄出來。當要提供參考資源時又可以直接把Hyperlink加進文件，讓讀者直接點擊而不需要大量的引文。

不過這好處祇限於Document，Spreadsheet則有點麻煩，雖然可以放入超鏈結，但不能直接加標題，必須使用公式(formula)這種迂迴的方法。

就算把超鏈結拷進Spreadsheet，結果只會顯示URL，沒了標題

解決方法:

=hyperlink("https://www.google.com.hk/","Google")

結果:

真的有人願意打這種公式嗎!?

*廣告出沒注意*

如果你是Chrome的用家，可以安裝Kifier這個擴充套件簡化以上過程:

使用方法:

1. 開啟要制作鏈結的網站

2. 在工具清單上點擊Kifier的圖示

3. 選擇Google Spreadsheet格式

註:不用按Ctrl+C，鏈結會自動拷進Clipboard.

4. 回到Google Spreadsheet，用Ctrl +V又或者Edit -> Paste把鏈結貼上去.

步驟1~3

源碼: benlau/kifier · GitHub

其他推介套件

Dualless - 雙螢幕模擬套件

相關文章

Side Project : Team Color - 在試算表上研究顏色

限制搜尋空間加速設計

noreply@blogger.com (Ben Lau) — Sat, 06 Apr 2013 17:34:00 +0000

在2月份Barcamp中跟Steven Mak一起做了一場演講，題目是「少文件、大設計、快開發」，講述以少量文件開始計劃，並以設計技巧加速開發的心德分享。因為涉獵的範圍太廣，當初就題目的決定可真費煞思良。實踐果然是最佳的驗証法，收到不少的意見，其中有段的反應不錯，所以決定獨立成文跟大家分享。

關於限制

限制總是令人討厭，有時會聽到說要是當初沒有這個限制就能好了～事情一定更美滿之類的說辭。

可是細心思考，失去所有限制真的是好事嗎？

試想像突然間要你寫一篇作文，題目不限，你會寫什麼？結果是飛快把文章寫出來，還是遲遲動不了筆？

<<人月神話>>的作者Frederick. P Brooks，在他的新書<<設計的設計>>中提到：

「限制或許是負擔，但也可能是好事。限制可以縮減設計師的搜尋空間，有所限制，比較容易聚焦並加速設計。
……
讀國中的時候，我們很多人都不喜歡「自訂題目的作文」，我們發現有些事是真的；把限制統統拿掉，會使「設計」作文的工作更加困難，而不是更簡單。

……

人為限制對設計工作來說，好處是可自由放寛限制，理想情況下，它可以把設計師推向設計空間中未經探索的角落，從而激發出創意。」

限制並非創意的制肘、相反詞，好的限制反而可以激發出創意，問題是一些誤解、過時甚至矛盾的限制，例如下圖……

要平？要好？又要快？去你的。

需求不清

沒有限制的作文令人猶疑不決；需求不清的軟件開發則舉步為艱，二者的情況其實很相似。

有些人明確地認知到，有些人潛意識地知道，完全的自由並不存在，沒有說明限制不代表沒有限制，通常在交付時才知道。故總是恐懼著做出少於隱藏限制的工作，又害怕做出多於要求的事浪費氣力，結果精力都消耗在摸索那條不可視的界線。

所以一份清楚的需求可以幫助導論出明確的限制，但不幸的是需求不清下開發已經變成了業內的常態，雖然不支持卻只能照著辦。

設計不足的困境

常見於菜鳥或技能狹窄的團隊，以不變的舊方法挑戰新問題，缺乏對應問題的設計，又因解決方案的涵蓋範圍不足，結果問題多多最終難尾收場。這種團隊的常見特質是把High Risk的東西都放到最後。

過度設計的抓狂

另一種極端是過度設計，為了應付不清淅、未知的需求多想多設計不是壞事，但往往會無止盡地思考、搜尋可能性，不自覺地做出過於複雜的架構，拉長了開發時間，而更糟的是有可能做出超出能力的設計，直接出局。

有點相當之有趣，就是設計不足的團隊往往比過度設計的團隊成功，因為前者最少能做出讓客戶收貨的第一個版本，雖然會因為需求修改、又或者結構太爛導至technical debt的債台高築，令開發的時間及成本不斷上昇。

但最少能快速地做到第一個版本，投資者願意付錢，又能發佈出去令士氣得以維持，正付合MVP的精神；總好過因為不肯定是否需要的問題而拖長開發時間，所以Extreme Programming有所謂"You aren't gonna need it" (YAGNI)的原則，需求修改則以TDD及Refactoring應對。

明確的時限是一種避免過度設計的限制

把想法歸成四類的分析法

有次跟某開發團隊會面，討論他們的設計，期間提出了許多試探性的問題，例如做不做得到一項不在規格內的功能？為什麼要用／不用這方法？這個問題發生時該怎麼辦？

大部份問題都是無理，甚至是愚蠢的，持續發問是為了考驗他們對自身設計的掌握，但結果工程師的回答速度越來越慢，漸漸失去自信。

這不能怪責他們，因為需求本身就處於不清淅的狀態，在無限制的設計中，搜尋（回答）的速度必然下降。

為了讓設計得到限制，我們做了一個嘗試。

就會議中提出的所有點子、Story，不論是問題、原則、想法、猜測，只要認為重要的，請寫下並歸類成以下四種狀況：

Requirement

明確地由客戶、老闆提出的需求，那是一種proven fact，無用質疑的Story都歸類在這裹。

在那次會議中可以被歸類為Requirement的想法遠比其他種類少，正是問題的所在。

Constraint

在項目管理中，Constraint指應被檢查、限制、禁止的資源及要避免的行為，同時又包括為此而採取的行動，用途是為專案所覆蓋的範圍定出明確的界線。你可以理解為完成需求而應該及不應該做的事。

Assumption

也可以稱之為Educated Guess，沒有實質的証據支持，但憑籍經驗進行猜度的各種想法。

Uncertainty

專案中的大敵，混沌的根源，理應盡早排除，但若因此過份賣力，卻會陷入過度設計的地獄。最糟的其實不是項目存在不確定、不清淅的地方，而是自己都不知道不清楚什麼，所以把Uncertainty記錄下來是有幫助整理思考的作用。

參考

若Requirement及Uncertainty處於二個極端，那麼Constraint及Assumption就是彌補二者之間的空缺，在進行軟件分析及設計時會在腦中跑出許多的點子，對這些點子過早進行批判是無益的，一來在大藍圖清淅前欠缺足夠理據下決定，二來為每個點子進行深度分析是很費時的，需要的僅是記錄及歸類。

完全不明白、猜不透的想法	Uncertainty
我覺得專案需要...吧...?	Assumption
我們要做或不要做個	Constraint
原來文件有寫的	Requirement

這個歸類是很簡單的，建議可以先自行準備，然後拿出來給團隊一起研究，他們可以幫助確認想法的正確性，例如把不對的Assumption拿掉、跟客戶老闆談Uncertainly，最後變成Requirement或者Constraint等等。

故此這個分析表的內容會隨著時間而改變，理應越來越準確，在這個前提下第一版與最後版本必定有很大的出入，所以起草人不妨「大膽假設」，而非慢慢分析，寧可快點拿出起討論，反正有錯是正常的。

限制搜尋空間的設計

並非所有編程師都有規劃的能力，按部就班編程還可，規劃整個軟件卻無能為力或者費時日久，這與經驗有關，也與思考方法有關，試想像同時把數十至數百項要求同時放進腦部思考有多困難？

能同時處理、思考的數目多寡主要由天資及思維決定，不過可以用方法補救，就是利用之前寫下的分析列表，以檢核表法(Checklist Method)方式輔助思考。

在未有一個大藍圖之前，先由Requirement著手，就每個單獨的要求做一個設計：

只針對這個要求做設計，不考慮其他。（除非你認為行有餘力)
內容可以是Use-case diagram、Class Diagram、Activity Diagram、Sequence Diagram、Deployment Diagram、Collobration Diagram，建議採用圖像化方式，但Pseudo Code及point form也可

如果做的是Class Diagram，不用把需求外的Class列入，比起一張overall的Class diagram，針對use-case所繪的class diagram更容易令人理解.

建議手繪，因為快，易加入注解，在設計成形後才轉用數碼方法

註:如果之前已經有重覆的設計，可以考慮修改而非做一個新設計

檢核表法驗証

為一個單獨的需求做的設計可以很快很簡單，但驗証卻要難得多，會無止盡地思考擔心是否足夠呢？

這時候就該把之前的分析成果拿出來用。

首先把剛完成的設計跟過往的設計比較：

有衝突的地方嗎？ => 有則一起修改，尋求一致性
有重覆的地方嗎？ => 抽出來變成模組

然後跟分析結論再做比較：

有未完成的條件嗎？

再設計 or
列入Uncertainty (其實可能是不需要的做的，先記下來再討論吧！)

有分析文件中沒有的功能嗎？

再設計、刪除 or
列入Assumption (憑我的經驗推斷，這功能是需要的)

結論

以上嘗試提出的是一種系統性的分析及設計方法，檢核表法的作用是限制搜尋的空間，放棄無止盡地去思考，而是與過去的設計及分析結果逐一對比，若沒有修改就代表初部設計完成，定出一個明確的完成條件.

對於經驗豐富的架構師來說，大概用途不大，因為他們已經有自己一套的分析及設計論，最大的作用是用來培育仍不得要領的新手，在有限制的時間內讓他們累積設計經驗.

事實上當我們完成了以上的分析後，工程師們回答問題的速度明顯地提昇了許多，另外發現到設計出現問題的原因多數在於Assumption出錯或Constraints不足，基本上只要協助澄清這些需求及分析結果，他們就能自行修正設計。菜鳥的話則加多把勁吧。

這方法其實是把分析及設計放在一起進行，在設計完成時分析的內容或會因此改變，這跟傳統的SDLC的先分析再設計有一定的分別，但若果說這其實更接近Winston Royce(提出Waterfall model的人)原來的想法，而且他本人就不相信Waterfall model，你會相信呢？

好比如這篇文章的主旨「利用限制加速」一樣，有時候有些固有的觀念並不一定通用，不妨用更靈活的方式去思考問題吧。這是一個初步提出的想法，歡迎大家一起討論。

[冷笑話] 我的咖喱炸豬扒飯不見了

noreply@blogger.com (Ben Lau) — Sun, 31 Mar 2013 04:35:00 +0000

沒有末日的2013年

noreply@blogger.com (Ben Lau) — Mon, 31 Dec 2012 16:52:00 +0000

祝各位新年快樂～

2012的馬雅末日預言雖然傳得甚囂塵上，最後當然什麼都沒發生，幸好相信的人也不多，大家更樂於拿末日來開玩笑。

12月21日的天氣預報

這種傳說式的末日毫無實際理據，苦非有關題材的電影大熱，要真心膠相信其實都幾難，但換個角度說，如果沒有這些末日傳說點綴生活，不是更無聊嗎？

這年的Blog產量同樣地非常之少，與其說過去一年過於煩忙，不如說要花心費神的事情太多，無法集中精力去做一件事，被各種變化牽著鼻子走，想要的事連一半都沒有實現，去年說的各種計劃，僅變成願望。

所以今年不會許任何的願望，而是去踏出那一步，所需要改變的是 ﹣ 生活質素。更正確的說法是生活的方式及態度。

回顧過去一年，首先出現問題的是健康。

健康

許多年來都有關注膽固醇及肥胖的問題，每年都嚷著要減肥，諷刺的是當身體出現毛病，卻與肥胖問題完全無關，不過結果卻無異，一樣要控制飲食、多做運動。

幸好現在已經接近康復，但為免復發，運動及工作之間要做一個平衡，要多運動，而不能運動的日子則多點拉筋，而且要定一個目標。

沒有目標的運動是很難以持久的，以體重為目標是一個方法，可是多年來的經歷証實只要工作一忙，這目標都會被拋棄，所以除此以外要定一個比較實際的計劃 ﹣ 讓身體回復到足以支持在台灣進行連續幾天的單車行。

受天氣所限，最適宜進行活動日子只有幾個月份，死線的壓力可以逼自己保持一定的運動量。

已經開始做功課...

社群活動

雖然工作繁忙，但仍有參與開源社群的活動，而且不限於本地，今年也有去OSDC、COSCUP這類會議，可惜找不到機會去其他地區。

可是作為開源活動的搞手，則處於停業狀態，最多只贊助過GNOME Asia。

相對地卻多搞了其他類型的活動，例如有WIDS、Agile Tour，10月的GAME Jam都有插花幫一幫忙。（有趣的是所有活動都是第一次在香港舉辦)

接下來大概都是同樣的步調吧，大概還會參與一項開源軟件的開發。

興趣

結果這年只有在聖誔舉辦過一次Boardgame聚會，連參與其他聚會的次數都屈指可數，這門興趣處於荒廢狀態，更莫說去年計劃了想做的遊戲設計…幸好軟件方面沒有交白卷，最少都發佈了一個小工具Dualless。

沒有時間玩桌上遊戲，但買了很多回來... (特別是同人類)

難得一次的聚會，自製了一點薯片宴客

動輒花上數小的活動無法進行，卻多了一門時間消費較少而且有助舒緩壓力、改變心情的嗜好 ﹣ 書寫筆記本。

動筆書寫是一件很有趣的事，雖然效率比打字差，靈感卻得來更易，所以我有幾本A5的活頁簿(Hipster PDA)寫滿了各種靈感、創意，而且也習慣先在紙本（廢紙）上書寫Blog的草稿，之後才敲進電腦。

在年初時參考了些筆記術的書本後，放棄了把草稿寫在廢紙上的習慣，改為在有收藏價值的筆記本上書寫，並且將記錄的範圍擴闊。一閃即逝的靈感、生活上的趣事、隨意的塗鴉、旅行的點滴、食譜、工作的經驗得著等一概寫進一本筆記簿，只要有靈感就書寫，短暫離開電腦以便休息。

當累積的想法足轉化成行動時，就會到數位筆記本(Evernote)出場。Evernote作為剪貼工具是相當之棒的，但以行事曆及專案規劃而言，功能比較陽春，而筆記術正好能彌補這方面的不足，二者相輔相乘有助想法釐清。

拜這所暢，去年累積的想法及各種計劃遠超過去，將這些想法付諸行動將會是2013的重要行動。

2012年寫了超過300頁的各種想法，使用了二本筆記本，下一本將會是Moleskine Evernote。

Global Game Jam Hong Kong 2013

noreply@blogger.com (Ben Lau) — Sun, 30 Dec 2012 13:26:00 +0000

Global Game Jam 2013 香港站

日期：2013年1月25日到27日
地點：香港九龍紅磡，香港理工大學，PQ002
活動網站：Global Game Jam Hong Kong

自去年10月香港第一次舉行Game Jam後，下一個Game Jam又快來了！這次是Global Game Jam香港站，有興趣想寫遊戲的朋友就不要錯過了！

自動化部署本機網絡測試環境

noreply@blogger.com (Ben Lau) — Sat, 10 Nov 2012 09:56:00 +0000

雖然我並非一位專職的網絡應用開發者，間中都要寫一點網絡應用，又或者會動手試檢不同技術的利與弊，基於很討厭在自己的Ubuntu做代碼安裝以及改動太多設定，所以通常都會在VM裹進行。

完成後都會寫一篇筆記，經驗告訢我，日後再依這篇筆記執行的成功率遠低於50%，可能有遺漏，可能軟件有修改，又或者要求根本不同了，幸好這總比重新RTFM快許多。

為了減省筆記上的錯漏，一直都想把文字script化，概可說明步驟，也可以日後依樣執行。可是若沒有好的framework配合，弄出來的script只會更加難懂…… 其實我想要的script跟自動化部署(auto deployment)系統很相似，大可直接拿來用。

花了點時間，利用ubuntu-vm-builder,fabric及puppet總算做到了這個要求。現在可以把建立測試環境及測試的程式全都放在VCS裹管理，只需要把幾個指令就可以把程式抄去VM後執行。

例子 - 建立一台VM執行Nodeload(node.js)的測試程式

指令

fab create #建立VM
fab setup #設定VM，例如下載node.js及其node.js模組
fab deploy #把測試程式拷到VM執行
fab view #開啟Browser查看結果

完成的代碼

準備工作

首先你要有一台Ubuntu，然後安裝以下軟件

sudo apt-get fabric ubuntu-vm-builder #你不一定需要裝Puppet，也不需要安裝Node.js，請看下文。

如果沒有建立自己的ssh key，請先用ssh-keygen建立。

測試的環境是12.04，12.10相信也沒有問題，若然是11.10則要調整建立VM的參數，基於12.04是LTS版本，所以建議使用。

在接下來的例子中，會利用Nodeload建立一台Node.js的測試伺服器，即使上面的指令沒有安裝node.js也不用補回，因為將會執行的是VM而不是host/桌面機。

Fabric及Puppet的簡介

這二個軟件都可以歸類為自動化部署系統，例如可以把設定及執行檔安裝至複數的伺服器上，但二者之間的運作原理卻非常之不同。

Puppet採用Agent/Master架構，複數Agent自動向Master取得新的設定，這是一種叫做pull機制。

而Fabric則是採取相反的Push機制，由本機把設定通過ssh推至複數的伺服器上。

單純就自動化部署系統這一範疇來說，Puppet發展迅速，不過Pull的機制對開發人員來說卻有所不便，因為要先設定多一台Master變相令建立測試環境的過程變得複雜，Push的形式比較簡單，所以我採用了混合的做法：

使用Fabric把設定檔推至VM，再執行Puppet把設定更新。

建立VM

在這個例子中我不打算使用VMWare或者VirtualBox這類方案，而是使用Kernel-based Virtual Machine(KVM)配合QEMU+libvirt，介面上當然比不過前二者，不過勝在可以透過ubuntu-vm-builder輕易地建立可執行的Ubuntu影像，並自動執行初始化設定。

第一步是建立fabfile.py，內容如下：

from __future__ import with_statement
from fabric.api import local, settings, abort, run, cd , put
from fabric.contrib.console import confirm
from fabric.api import env
from fabric.context_managers import prefix
 
machine = "nodejs" # Name of the testing machine
 
def create():
    # Create a testing machine
   
    # Remarks: You should not permit root logins via SSH in a networking
    # environment, because this is a big and unnecessary security risk.
    #
    # It is enabled here for simplify the tasks required to build
    # a testing machine. Never do it in production and even on
    # a machine within your office network.
   
    dist = "precise"
    mem = 128
   
    packages = ["openssh-server" , "puppet" , "nodejs" ,"npm"]
    package = " ".join([ "--addpkg %s"  % x for x in packages]);
   
    options = ["--libvirt qemu:///system", # Add to libvirt
                "--lang=C",  
                "--ssh-key ~/.ssh/id_dsa.pub",
                "-d /var/lib/libvirt/images/%s" % machine,
                "--hostname %s" % machine,
                "--mem=%s" % mem,
                "--name=%s" % machine ]
    option = " ".join(options);
 
    command = "sudo ubuntu-vm-builder kvm %s qemu:///system %s %s" % (dist , package,option)
    local(command)

上例中有一個叫做create()的函數，可以通過指令`fab create`執行，

完成後可以用指令`sudo virsh start nodejs`來起動VM。

註1：我把自己的SSH key放入VM的root中，使得可以經ssh登入root而不需要密碼，對於測試環境來說是相當之方便，但千萬不能在網絡環境中卻是採用，那是非常之壞的習慣。
註2：Ubuntu-vm-builder大概已經不會再有大的發展，之後的開發核心看來是lxc/juju，之所以沒有採用後者是因為還未學會使用。另外你喜歡使用VirtualBox的話，則可以選擇Vagrant。

執行Puppet

開動VM後下一步是進行系統設定，這部驟由Puppet進行。在VCS中有二個.pp檔，那是Puppet的設定檔，用以宣告資源，當中記錄了要安裝的軟件，但因為要使用到apt、gems、npm三種不同的套件管理程式，所以並不能用幾行描述完成。

像Fabric般使用script方式來進行設定是相當之直觀的方法，Puppet的描述語言則相對迂迴，但以configration management的角度看，追蹤修改比較容易。另外統一的資源／模型描述方法，使不同軟件之間的設定的差異化減少，有便於管理。（詳情)

要進行這部驟的指令是`fab setup`，代碼：

def setup():
    # Setup the testing machine using puppet
    put("setup*.pp" ,"/tmp")
    run("puppet apply /tmp/setup-phase1.pp")
    run("puppet apply /tmp/setup-phase2.pp")

Fabric在這裏的作用只是把.pp檔拷到VM後執行`puppet apply`而已。

進行測試

最後一步是把測試程式放入VM執行，指令是`fab deploy`，然後在另一個Terminal中輸入`fab view`就會自動打開browser查看實際結果.

$ fab deploy
[192.168.122.118] Executing task 'deploy'
[192.168.122.118] put: ../src/nodeload-server.js -> /tmp/nodeload-server.js
[192.168.122.118] run: killall -9 node;echo
[192.168.122.118] out: node: no process found


[192.168.122.118] run: node /tmp/nodeload-server.js 
[192.168.122.118] out: Started test server.
[192.168.122.118] out: Started HTTP server on localhost:8000.

執行結果

總結

如果只為一次測試寫上以上的程式，老實說我也覺得小題大造，但如果考慮到日後可以重覆使用，這一切就會變得物超所值。這刻只有建立node.js的.pp，日後可以加入MongoDB、Redis、MySQL，Nginx、Memcache、ZooKeeper..... 你想怎樣配搭都可以，當你不需要時只需把VM關掉，會佔用的僅是硬碟空間。

要是對這種測試方法有興趣，又想尋找更多的use-case，可以參考 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

[Buddy Rush] 3對3模式套裝資料

noreply@blogger.com (Ben Lau) — Wed, 18 Jul 2012 15:16:00 +0000

很少寫與電子遊戲有關的文章，大概是因為我壓倒性地較喜歡圖版遊戲吧，畢竟有著欲罷不能的手感及對戰氣氛，不過也不是說不玩電子遊戲，只是比較簡擇而已。

其中一款我會玩的遊戲叫做Buddy Rush，可以在Android/Facebook及iOS上玩的RPG遊戲，本來已經有一段時間沒有玩了，可是最近改版，整調了3對3模式的寶物入手難度，加上衝等及的獎勵，結果忍不住又開始了玩。

最初3對3模式要打贏差不多30場才會有一件有用的道具掉出來，雖然相當之不錯，例如白色的King's Flamberge只要等級10就能裝配，可以增加32點的攻擊力，以那個等級來說是逆天的強度。

現在大概是3~5場左右就會掉出來，今天我甚至打出了4件頂級紫裝！可惜未能儲得一套獲得加剩的效果。

順帶一提，新版的套裝效果，不再限於紅色！任何顏色只要儲齊一套就可以額外的加剩！而且只要花掉Bug就可以提昇道具的效果！

以下是一些我所獲得的套裝及其能力值(持續更新中）：

Lord系統套裝

Lord's Hammer
Lord's Belt
Lord's Glove
Lord's Shoulder Armor

白色Lord套裝

全套效果

Att+82

Def+26

HP+112

MP+24

Skill Power +27%

Hit Speed +3.5%

Skill Cool Time -0.8

Critical +2%

Evade+1.5%

MP Regen+2.5%

緣色Lord套裝

全套效果

Att+114

Def+36

HP+184

MP+40

Skill Power +37.5%

Hit Speed +5%

Skill Cool Time -1.2

Critical +3%

Evade+2.5%

MP Regen+2.5%

藍色Lord套裝

全套效果

Att+148

Def+46

HP+240

MP+56

Skill Power +49.5%

Hit Speed +6.5%

Skill Cool Time -1.6

Critical +4%

Evade+3%

MP Regen+3%

紅色Lord套裝

全套效果

Att+192

Def+58

HP+304

MP+72

Skill Power +64.5%

Hit Speed +8%

Skill Cool Time -2

Critical +5%

Evade+3.5%

MP Regen+3.5%

King套裝

King's Flamberge
King's Ring
King's Plate Mail
King's Necklace

白色King套裝

緣色King套裝

全套效果

Att+96

Def+14

HP+232

Skill Power +31.5%

Hit Speed +4.5%

Skill Cool Time -1s

Critical +3.5%

Stun+2.5%

紅色King套裝

其他道具

Processed Titanium (小心有雷！)

Blood of Phoenix

Scroll系列

Unlimited Build Works

QML Snapshot Testing與TDD的連㩗

Jest - Snapshot Testing

QML - Snapshot Testing

Test Driven Development

工作一：Write (Failing) Test code first

工作二：Red-Green-Refactor Cycle

任務三：UI規格修改

結論

20萬用戶成就達成！

又來超糟糕的登入設計

繼續站著工作 - 自己動手做standing desk (流動版)

再見了，超糟糕的登入設計

Dualless - 10萬用戶達成紀念

Side Project : Team Color - 在試算表上研究顏色

#github 我都只是fork別人的project，你fork我又何苦呢

近況

讓Github幫你管理放在Amazon S3的網站 - 網站更新的自動化部署

預覽流程

Travis-CI

Amazon S3

正式版本的發佈 - Pull Request

不明白Facebook的苦心就不許使用Facebook啊

開始站著工作 - 自己動手做Standing Desk

簡報上線 : Making Chrome Extension with AngularJS

第二屆Hong Kong Mini Maker Faire

誠徵開源軟件測試者 - Dualless 0.4 RC

第二屆 World Internet Developer Summit !

週末的軟件開發計劃 - Angular Loading Promise

新簡報上線: Effective TDD - Less is more

擴充Google Docs的應用(1) - 在試算表中建立連結

限制搜尋空間 加速設計

關於限制

需求不清

把想法歸成四類的分析法

限制搜尋空間的設計

檢核表法驗証

結論

[冷笑話] 我的咖喱炸豬扒飯不見了

沒有末日的2013年

Global Game Jam Hong Kong 2013

自動化部署本機網絡測試環境

準備工作

Fabric及Puppet的簡介

建立VM

執行Puppet

進行測試

總結

[Buddy Rush] 3對3模式套裝資料

限制搜尋空間加速設計