Unlimited Ben's Works

[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+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%

King套裝

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

緣色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%

其他道具

Processed Titanium (小心有雷！)

程式師的修練場 - 建立自己的Junkcode及測試程式庫

noreply@blogger.com (Ben Lau) — Mon, 25 Jun 2012 16:04:00 +0000

大概很少人聽過junkcode這個字，如果在Google上尋找，首先會連到www.samba.org/junkcode，那是Andrew Tridgell(Samba的原作者)的網站，存放了他的垃圾代碼。

之所以被稱為Junk，那是因為他並未有計劃把這些代碼變成任何項目、也不會提供文件、更加不會保證有任何的改良。

Andrew Tridgell在大概八九年前左右曾來港演說，時歷久遠，當時的內容大多忘記，不過有二點是現在仍記得的，其中一項就是他提到的Junkcode程式庫。（註一）

受到他的影響，之後我也開始了建立自己Junkcode程式庫的習慣，只是沒有像他般公開。

我的Junkcode主要有幾種內容：

不同語言的Hello World及語法的實驗。
不同Library/Framework的試驗
Algorithm驗証
試作性質的專案

只有空閒時會撰寫，不一定有明確的計劃，絕不保證日後有用，所以這些都是Junkcode。

因為沒責任，故此寫起上來是挺輕鬆的，除非目的是研究怎樣改良代碼，否則什麼代碼質素、易讀性的考慮都被拋諸腦後。

不過即使是垃圾，難保日後會有用武之地，所以我都有好好地做version control作為保存的手段，只是commit log就有點... 嘿嘿。

最初用CVS管理、後來git面世了，跟著就轉了去git，最後又變成了Bazaar。

像是Frontview、DQuest、PenPen、Dualless這類項目的雛型都是先在名為junkcode的source tree中開始，當漸漸成型後才獨立分離出來，故此你若查看PenPen、Dualless的提交歷史時會發現第一個版本已經包含了許多的檔案，那都是先寫在junkcode裏的。

不過因為太隨意建立專案的關係，source tree變得有點混亂，所以我開始了使用Test Driven的方式管理。

Test Driven式學習

Test Driven Development是近年一個熱門題目，當初學習時的實驗代碼全都是在junkcode裏進行，掌握這方法後不單影響了我的專案管理風格，連Junkcode的寫法也有所變化。

例如説要去學習一門新的語言時，我首先寫的不是Hello World，而是先找一個評價好的Unit Test Framework，然後用這語言寫的第一個程式不會再説Hello，祇會説Pass / fail。

假設有以下的情況，我現在要去學Javascript，找來了一本叫做《Javascript設計模式》的書本，跟著有朋友推介使用QUnit做unit test，花了點時間總算把環境建立起來。

在書本中見到以下的代碼：

var a = [3];
console.log(a.length); // 1
consloe.log(a[0]); //3

var a = new Array(3);
console.log(a.length); // 3
consloe.log(typeof a[0]); //undefined

照著書本把代碼打一遍是一種學習的過程，只要查看注解的内容就知道是否正確，若印出預期結果可以加深記憶；失敗則能鍛練除錯的技巧。

而我則喜歡更進一步，把教學用代碼變成測試條件，例如以上代碼會變成：

test("array" , function() {
    var a = [3];
    ok(a.length == 1);
    ok(a[0] == 3);

    var a = new Array(3);
    ok(a.length == 3);
    ok(typeof a[0] == undefined);
});

跟著那去browser跑... 噢！第４個測試不能通過！？

    ok(typeof a[0] == undefined);

這句不對嗎？

打錯了，原來是這様才對

    ok(typeof a[0] == "undefined");

又或者這様也對

    ok(a[0] == undefined);

在這轉换過程中不小心做出了超越作者預期的行為而犯錯，測試程式亮起了紅燈，跟著為了回復為綠燈去工作，這就是學習（而且帶了有一點兒TDD味道）

這種學習方法不限於學習語言本身，也可以用來學用不同的Library/framework、設計模式，可以簡單地驗查自己的想法是否正確，順道可以協助掌握寫測試程式的方法，對日後其他的專案開發很有幫助。

總結

無讑是編程的初心者還是經験豐富的老手，建立自己的junkcode程式庫都有一定的好處，這些積累的作品不一定可以發表，可是……

或許日後會有機會用到，成為其他專案的一部份
或許可以在Junkcode中找回以解決過的問題方法，但現在忘了。
回顧以往寫過的代碼，也是一種樂趣

而且編寫junkcode的負擔很少，因為你不需要向任何人負責。

如果加入VCS及TDD，則還有以下好處：

練習使用版本控制系統
掌握各種測試技巧、有助於引入TDD
更快掌握一門語言、Library/Framework。

通過Test Driven式的學習，習慣思考不同行為的正確結果

重新掌握一門語言、Library

太久沒有使用相關的技術，可以查看過去寫的測試代碼回想起來。
如果framework更新了,跑一次測試程式就可以知道有沒有跟過去的認知衝突的地方。

註一: 另一項記憶悠新的内容是關於在開發Samba時，曾經比較過Multi-process、Multi-threading及I/O multiplexing三種多工作業的效能，然後發現I/O multiplexing的效能是最好的，現在非常之熱門的Node.js其實也是應用了相同的原理。

故事式規劃設計

noreply@blogger.com (Ben Lau) — Mon, 18 Jun 2012 16:18:00 +0000

Agile/Scrum的開發流程中有許多傳統方法沒有的新概念，例如採用Story Point而非Ideal day/man hour去計算工作量；用Burndown Chart取代Gantt Chart等等。

比起使用Issue Tracker來管理工作，Agile/Scrum更傾向於使用Task Board，那是一面貼著各種工作的牆，猶如RPG世界中的冒險工會中擺放任務的告示板，不過更有系統也不至於混亂。

各類型的Task Board

User Story是Agile的常用語，用一二句簡單的說話描述要求、工作以至其他訊息，通常會以手寫的方式寫在便條紙又或者資料卡上。

左 - 資料卡右 - 便條紙

Task Board的作用就是放置這些User Story，通常會再以TODO、In Progress、Verify及Done等不同階段分類。每天會通過一個10~15分鐘的小型會議重新調整。

對於習慣使用Issue tracker的我而言，最初接觸這個概念只感到不可思義，為什麼有著高科技的軟件不用而走回紙本啊！？

實際經歷過後找到了答案。

剛開始引入Agile/Scrum時覺得便條紙不太可靠，所以選擇了用資料卡。很快就發現這些資料卡除了在Task board外還有很多其他的用途。

經歷一) 快速決定功能的重要性

話說有一個專案，客戶要求的功能是沒有辦法在指定的時間內完成，這點客戶都明白。

唯有先把最有價值的功能弄出來，次要的功能則在死線後加回。

把需求列表印了出來，接著大家七嘴八舌討論，意見太多、缺乏焦點、就是沒有辧法決定出優先序。

最後我把心一橫，把所有功能寫在資料卡上，在客戶面前攤開，然後玩起拼圖遊戲。

最重要的工作放在最頂點，平放代表拿不定主意，
這些平放的"故事"交由開發團隊決定優先序

最初的排列是隨機的，可是當各項工作以視覺化的形式呈現了出來後，思考會變得輕鬆，而且各人直接動手更改排序令敏捷度大增，結果很快就敲定了決議。

其實這過程還不知不覺地把問題本質改變。

最初是的要求是「請為每個工作定優先序」，這等於請你去為工作的價值估值。

當然每個人都有能力做估值這工作，可是該怎樣把各人的估值整合？平均數法固然公平，可是不一定代表能做出好的設計，基於大家的著眼點並不一致，平均數法可能得出違背最多人想法的決定。

可是通過這方法，問題卻變成－ 「請問桌上面的排序有你不滿意的地方嗎？」

現在追求的不再是優先序絕對值，而是各功能的比較值，其實各人根本沒有興趣知道功能A的優先序有多高於功能B，只要知道功能A優於功能B便可。

如果沒有反對則默認通過，反對則直接動手改變次序，當然仍然需要溝通，但反覆排了幾次，爭論點就會減少，代表大家重視的工作及衝突得以解決，漸漸一個比較接近各人心中理想的答案就會以視覺化的方式呈現在眼前。

經歷二) 快速需求分析及設計雛型

要求文件確實地收到了，不過團隊是初成立的，經驗豐富者堪少，這時候採取的方法有二，一是單獨派發任務後自動執行，二是透過共同協商解決問題。

前者自生自滅，在整合時便因為撞車而屍橫遍地；後者一不小心就會變成開會或文件地獄。

結果採用後者，一起討論需求文件，每次在文件中找出一項工作、需求、限制、疑問、資源、對應的設計策略、或者找出了潛在的要求時，都會立即寫在資料卡上。

首先把寫上疑問的資料卡收集，依此跟客戶澄清。之後把工作的卡片卡抽出，經過Planning Poker定下Story Point把所有卡片放在桌上，然後大家就再玩起拼圖遊戲，最後變成工作的計劃。

一份需求文件寫成40多張故事卡已經算少了，看似辛苦卻是先苦後甜的一項作業，首先把不確定性排除不小，而且各人對計劃都能有比較一致性的認識。

如果有經驗深厚者在場，也可以順道做出一些設計的雛型規劃，給予其他人一個明確的方向。

跟著就把工作貼在Task Board上好了，把這些資料重新輸入Issue Tracker可是一件相當之累人的工作！Defeat及Bug等工作的記錄才出動Redmine吧。

已經習慣了使用Planning Poker來計算工作難度，再推論出實際所需的時間。

Planning Poker也可以好萌 (以上二款均為Odd-e出品)

延伸應用

在Agile的定義中，User Story是指用簡短文字描述的工作要求，不過我覺得可以把Story的定義再擴闊，User Story也可以是限制、原則、假設、設計提案、設計模式、問題、疑惑、風險、不確定性，所有經過討論產生的內容，只要內容夠精練也可以是一個故事。

至於寫在資料卡上，則是一項減省文件工作量的方法，像是經歷二中提到的會議，首先可以讓各人淪流書寫，最好是提出者自己寫下，犯不著要犧牲任何一位工程師去當秘書做會議記錄，資料卡（現在可以叫做故事卡）概是記錄、也是設計的一環，只要存放在所有工程師們都能取閱的地方，概可以保持執行的一致性，也可以避免文件地獄。

這也可以算是一種協同寫作。

至於開會地獄呢，這得看主持人的功能及各人會否就個別故事展開過長的討論，關於這點我另寫一篇文章再談。

數個月就可以花掉那麼"厚"的資料卡啊

總結

資料卡有不同的大少，我喜歡購買5" x 3"這種大少的，因為書寫空間有限，所以一張卡最好只放單一的命題，並用簡短卻又切入核心的文字及圖案補充。

這種方法在資料內容上有很多的限制，但限制也不一定是件壞事，套用《The Design of Design》一書中提到的說法，限制或許是負擔，但也可能是好事，有所限制比較容易聚焦並加速設計。

用精練文字描述故事也是一種設計的磨練。

雖然這篇文章的標題是"故事式規劃設計" ，但其實真正想介紹的卻是資料卡的運用 ;)

在閣下的團隊正式引入Agile / Scrum時，不妨先試一試用資料卡書寫故事，像是在「經歷二」中的那種會議中使用，把分析出來的內容故事化，你會發覺記錄的效率會大大的提昇，而且之後還會發現更多有趣的延伸應用方法。

Evernote活用術 - 助你找尋物件

noreply@blogger.com (Ben Lau) — Thu, 07 Jun 2012 18:09:00 +0000

忘了東西放在哪裡，為了找回失物把家裏翻了一遍，相信許多人都有過類似的經驗。

當然我亦不例外，而且發生的機率相當頻繁。

所以自去年開始，我採用了Evernote來幫助管理物件的位置，方法是這樣的：

每當要費神去找一件物品，找到後我就會打開手機或平板上的Evernote程式，為該物件及其所在位置拍一張照片，標題寫上該物件的名字，最後上傳至一叫做個"Where"的Notebook裏。

例子 - USB充電器的照片

這些USB充電器是平常不用的，最初存放在一個透明的盒子中，隨意的放在桌子上。但因為每次外出公幹或旅遊時都會帶著，所以需要記錄下來。

那麼下一次尋找時，只要在Evernote上輸入該物件的名字，就會顯示出該物件的樣子及存放的位置，雖然未必就在照片中的位置，一般上都不會相差太遠。即使位置真的改變，這些照片都可以刺激自己的記憶，有助想起相關的訊息。

這方法很簡單，用相片的方式記錄相當之直觀，也可以免除寫下「廳中最大的櫃的第二格」、「床下右二的櫃中」這類沉長的文字描述。

如果物件的位置改變了，只要在原來的Note上再附上一張新的照片便可以更新位置記錄，不過是舉手之勞，而且還會自動成為了物件的移動記錄。

例子 - USB充電器的移動記錄

這些充電器以前放在一個透明的盒子中，因為增加了數個，所以改為放在一個較大的膠盒中，放置在桌面的其中一個抽櫃裏。

OSDC.tw 2012後記

noreply@blogger.com (Ben Lau) — Sun, 03 Jun 2012 08:30:00 +0000

想找時間寫Blog真不容易，COSCUP 2011後也想寫個後記，卻一直擱置到現在，難得能騰空一點時間，不過要寫不是COSCUP 2011後記，而是OSDC 2012後記。

(在這文章登出時，連JSDC.tw都已經完了...)

記得去年參加OSDC 2011時，某位會議主辦者說過，搞科技活動的要點有三：「網絡、正妹、食物。」，因為沒有提供正妹，所以網絡及食物都要盡善盡美。

今年我不能不說，你們連最難的那項都做到了！！（雙手合什，拜了一拜）

(Samsung帶來了很多Show girl啊，可是別問我拿相片，請找那些有跟Show Girl合照的人拿吧～）

詳細的議程請參考：http://osdc.tw/schedule

以下是我去了聽的議題：

Mozilla B2G: Breaking Mobile Monopolies
Cocktails – Shaken, Not Stirred
從手寫筆、滑掌截圖、陀螺儀等應用看Android應用程式開發
談手機 Internet Client 開發：我從「台灣天氣」學到的事情 (5星)
An Overview to Garbage Collection Algorithms in OpenJDK
Let's Enjoy NodeJS - All Development in JavaScript
Facing the Big Data challenge: a use case for leveraging from Hadoop and her friends
Trend Message Exchange - Open Source Realtime Big Data Processing Platform
Something about the Standardization of Android Testing
the Online Game Cloud Computing Platform base on HPC Technologies
Good collaboration in open source projects
PIXNET 的 ORM，Pix Table
Embedded Virtualization in Daily Life (0xlab)

(本來還想聽聽Thinker的Apps on HTML5 and the new WebAPIs，但那時被抓了去談電話... 不好意思……)

這次參加OSDC的香港團不及COSCUP 2011的多，除了我外，仍保持有來的是Sunny Chan，及二位新加入的。

Sunny Chan今年也繼續投稿，這次的題目是"An Overview to Garbage Collection Algorithms in OpenJDK"，為聽眾講解Java所不為人知的一面對，雖然講者本人說只是入門級的題目，不過對於喜歡Java及研究Algorithm的人來說是相當之有趣的演講。

Sunny Chan的講題 - An Introduction to Garbage Collection Algorithm in OpenJDK

繼上年在COSCUP 2011挑戰過Lightning後，今年我又做了一個嘗試，題目是「需求改變的反覆模型」，我想嘗試用一個模型去解釋沒有中央管理的需求變更是怎麼一會事，與去年的「一個嵌入式系統開發的小故事」一樣屬於非常之痛苦的題目，不過觀眾還是笑得很歡樂，這太沒有同情了吧？(笑)

不過這次對我自己來說是頗失敗，首先沒有好好地挑選內容，結果內容過份澎漲而無法在5分鐘內完成 :(

而且沒有先試過LibraOffice的新功能，結果造成梗的過早暴露，有些本人覺得好笑的笑點而觀眾又沒有反應，所以自己不禁有點荒亂；而且又想糾正自己的發音，結果又浪費時間 ~_~

無論如何，Lightning talk仍然是個很好玩的挑戰，希望下次可以再來挑戰 :)

投影片下載

像這大型的OSS會議一年可以來二次，而且另一個COSCUP更可以有上千人參與；再加上像Trend Micro及Pixnet這類公司會把By-product投入開源界中，可以看到台灣的開源界真的已經非常之成熟。與此相比，想到我們香港這邊作為中流底柱支持開源活動的僅有十來人，我真的感到很慚愧，真希望香港有天也能這樣。

這無容置疑是一場成功的會議，不過對我來說，最大的喜悅不是會議內容的，而是再次見到難得見面的台灣朋友，以及新認識的友人。正是有著地理的差距，才更顯得難能可貴。

相片

~~好多的Firefox ！~~
Pixnet的吉祥物合體

OSDC是聘請優秀工程師的好場合啊！

一樣是那麼多的食物！

Ligthning Talk報名

Noritsuna Imamura在介紹他的Mind Control robot。

（後來在Linaro Connect Q2香港又見到他)

JServ雖然病了但仍然堅持演講！

其他有關OSDC 2012的文章

OSDC.TW 2012_首次參與

其他有關OSDC 2011的文章

OSDC.TW 2011之旅

用「筆」閱讀

noreply@blogger.com (Ben Lau) — Wed, 09 May 2012 16:02:00 +0000

我喜歡塗鴉書本，最初不過是用螢光筆把內容重點標注、再畫點小符號做重點記錄這類小動作。

及後使用了Frixion的可擦除原子筆就變得肆無忌憚隨意塗鴉，經常在段落旁邊加上注解及畫上+1/-1，有時寫下當下的感想，甚至吐糟作者或者自己。

當中最有價值的塗鴉是被內容所激發的點子，或者跟其他智識的聯動關係，透過揮筆寫下一閃即逝的想法靈感，不單易於記憶及整理，更有助於把書中的資料、資訊提吸收成為屬於自己的智識。這就是用「筆」閱讀的好處。

不過這行為是有限制的。

不適合愛書如命者
書本不是自己的請不要塗鴉

(就算使用Frixion要不留痕跡地擦除也不是易事)

其實有一個簡單的方法就可以突破以上二點掣肘－使用便條紙。

首先準備一張書簽，最好大一點，我個人特別歡迎使用遊戲卡做書簽。

用魔法風雲會的遊戲卡做書簽不錯的啊

然後在書簽二面貼上便條紙

之後在閱讀時找到重點的內容，可以在書簽上寫上頁碼及一二隻字做Tag，要寫下那刻的感想、評論、點子等也可，寫滿了就從書簽撕下來貼在書本上。

書中的提議正好跟我現在做的建議一樣。

因為書簽只有二頁，所以很快就會寫完，要是在戶外看書可以考慮先把5～6張便條紙貼在最初幾頁，這些便條紙即使已經貼過一次，還可以再貼最少3～4次，所以當便條紙不足時只要翻到那頁便能獲得補給。

在歸還書本時，當然要把便條紙撕下，視乎內容的重要性，可以挑選重要的內容再抄進其他筆記或者電腦上備份，在這過程中或許會產生新的點子、想通以往未有理解的問題。

雖然有這個方法，不過我個人還是喜歡直接拿著Frixion在書上塗鴉，這才是最自由的。

需求分析－魔鬼都藏在細節裡

noreply@blogger.com (Ben Lau) — Mon, 20 Feb 2012 16:18:00 +0000

早前看到了這個故事（來源）：

=== 故事 ===

某日,老師在課堂上想考考學生們的智商,就問一個男孩: 「樹上有十隻鳥,開槍打死一隻,還剩幾隻?」

男孩反問:「是無聲手槍，還是其他沒有聲音的槍麼?」

「不是.」

「槍聲有多大?」

「80~100分貝.」

「那就是說會震的耳朵疼?」

「是.」

「在這個城市裡打鳥犯不犯法?」

『不犯.」

「您確定那隻鳥真的被打死啦?」

「確定.」老師已經不耐煩了,」拜託,你告訴我還剩幾隻就行了,OK?」

「OK.鳥裡有沒有聾子?」

「沒有.」

「有沒有鳥智力有問題，呆傻到聽到槍響不知道飛的？」

「沒有，智商都在200以上！」

「有沒有關在籠子裡的?」

「沒有.」

「邊上還有沒有其他的樹,樹上還有沒有其他鳥?」

「沒有.」「方圓十里呢?」「就這麼一棵樹!」

「有沒有殘疾或餓的飛不動的鳥?」

「沒有,都身體倍棒.」

「算不算懷孕肚子裡的小鳥?」

「都是公的.」

「都不可能懷孕?」

「………,決不可能.」

「打鳥的人眼裡有沒有花?保證是十隻?」

「沒有花,就十隻.」老師腦門上的汗已經流下來了,

下課鈴響起,但男孩仍繼續問:「有沒有傻的不怕死的?」

「都怕死.」

「有沒有因為情侶被打中,自己留下來的?」

「笨蛋,之前不是說都是公的嘛!」

「同志可不可以啊!」

「………….,性取向都很正常!」

「會不會一槍打死兩隻?」

「不會.」

「一槍打死三隻呢?」

「不會.」

「四隻呢?」

「更不會!」

「五隻呢?」

「絕對不會!!!」

「那六隻總有可能吧?」

「除非你他媽的是豬生的才有可能!一槍只能打死一隻！」

「…好吧,那麼所有的鳥都可以自由活動麼?」

「完全可以.」

「它們受到驚嚇起飛時會不會驚慌失措而互相撞上?」

「不會,每隻鳥都裝有衛星導航系統,而且可以自動飛行.」

「嗯,如果您的回答沒有騙人,」學生滿懷信心的回答,「打死的鳥要是掛在樹上沒掉下來,那麼就剩一隻,如果掉下來,就一隻不剩.」

老師推推眼鏡，強忍著要昏倒的感覺，顫抖地說道：「你可以去當程序員了……」

=== 故事完 ===

這是個極誇張的故事，不過卻道出了程式師在分析需求時的應有心態。

提出需求的人有他自己的專業，與程式師的專業很有可能走在一條沒有交點的平衡線上，但程式師的專業之一就是把這些需求變成技術的設計要求；這是一個翻譯的過程，好比如作為火星人的程式師把金星語翻譯給其他同類聽，還要為此作出各種配置。

在這時要記著一點：「魔鬼都藏在細節裡」

需求就像一道陷阱式的IQ題，解題的重點不是自己的智識，而是補捉出題者的用神，只有理解出題者的思路才會有正確的答案。

最常見的陷阱是需求的標題與細節不符，又或者在需求A中沒有的細節，卻在需求B中出現。

不是說提出需求的人在騙你，而是因為專業的不同，對方不一定了解什麼資訊是程式師最是需要，對方可能覺得要求完美，但在技術的角度卻充滿破綻，一不留神就會墮入誤解的魔鬼陷阱。

最後在交貨時，對方質疑與要求不符，他們想要的是一道滿漢全席，但你卻提供了西洋大餐，那你會怎樣做？

A - 文件就是這樣寫，我不會修改的
B - 好，我改……

選A，大家之後不相往來；選B，很快又要再做一次。

軟體工程是一件很奇妙的事，法例是不可能以立法原義去做裁決（所以香港也很奇怪），但當軟件交貨時卻可能會有這種聲音－「我才不是想要這種軟件！」

這不是傲嬌的台詞，你不會萌得起來，只會頭痛。(除非是這種客戶)

應付這種客人當然辛苦，但同時請捫心自問，技術人員有沒有為需求而與客戶溝通好呢？有沒有先找出細節中的魔鬼－可以引起誤會的地方？

其實只要在分析需求時把關好一點，很多問題都可以避免的。

用心跟客戶談需求，分析需求後，指出有些對方未有留意的細節，再因勢利道再提出建議的做法，這不但能減少日後的爭論，同時能建立自己的專業形像，更容易獲得對方的尊重，可以讓合作更容易進行。

最佳的做法是學故事中那學生，就像一位名偵探般懷疑一切的可能性，可是千萬別宣之於口，這會讓人覺得你相當之白目。而且記著你的身份不真的是偵探，別要去盤問客戶，而要以輕鬆的語氣試探，慢慢切入問題的中心－你認為最有可能因為需求理解錯誤而出錯的地方。

如果遇著對方有點迷糊時，不妨花點時間去解釋，雖然對方往往想知的僅是解決方案，不過這點解釋的時間讓對方感到被尊重而得到對方的信任。直至真的沒法構通才出最後的方案－在合約中列明不包括的事務，當然必需要跟對方解理一次。

當然像是採用像Agile/Scrum般經常快速交付的做法也是一種解決方法，不過那是另一種技巧了。

相關閱讀

故事式規劃設計

短暫卻精彩的台灣之旅

noreply@blogger.com (Ben Lau) — Tue, 14 Feb 2012 14:01:00 +0000

在2月頭因為公務的關係要去台灣一趟，其計劃之一是去參觀台北電玩展 - 看自己公司的攤位。 ;)

不過在快要起行前發現了原來台北書展也在同一時間舉行，之前看過這篇文章的介紹，得知原來台北書展有個很大的桌遊攤位，為多點了解台灣人對桌遊類遊戲的興趣，結果又多了一個公務上的行程。

除了各個展覽，這次台灣之旅還有機會可以參觀到Mozilla在台灣的辦公室，這實在是太幸運了！

抵達台灣後，得知某項創業支援的計劃在晚上有個首發會，有些平常在網上會聊的朋友參加。

在香港搞創業支援的組織都有不少，也去過一二次的活動，可是台灣的又會是什麼樣子的呢？結果抱著一份好奇的心，以唯一的外地人身份參加了那次首發會。

雖然只有短短的3天行程，卻可以參觀、參與各種不同性質的活動，這次台灣之旅真的非常之豐富及有意義。

台北電玩展

香港的電玩展基本就像是被Sony獨霸了，永遠都是最大的攤位，佔了會場很高的比重，然後就是M$，基於本地比較大的廠商少，所以大型的攤位比較單調，其餘的攤位都是販賣各種遊戲週邊、同人作品為主。

活像主題公園的平面圖

我是去玩工作的。

台灣卻有不少本地的開發商，所以大型攤位的數量也較多，而且最重要是……………… Show Girl的質素也很不同 :D

2003年時去過Computex，那時已經感到Show girl的質素與香港有著天淵之別，在game show更能感受得到。

台北國際書展

台北書展跟香港有幾處很不同，首先是場地，香港書展在香港會展舉行，是一座一體式的建築，而舉辦台北書展的台北世貿中心卻是分散式的建築，總共有3個展館，散落在101大樓的三方，不過就大少而言，或許比香港的更大。

另外有一樣是香港不會見到的，就是宅配服務的單位，不用怕買書太多，只要寄回家就好辦。

至於相同的地方呢，就是…… 動漫有關的攤位一樣有一條長長的人龍，永遠不會在營業時間散去。

桌遊攤位

就我所見在台北書展中有三個桌遊的參展商，共五個攤位，分別是新天鵝堡、桌遊列國、及Kanga Games，當中以新天鵝堡最大，三個展館都有攤位，其中在館二的動漫區以日系遊戲為主，而館一則是最大的攤位。

價錢方面，新天鵝堡比香港的戰死會稍平，但比網上店貴，另外三個參展商中以桌遊列國的賣價為最平宜的。

新天鵝堡在館3的攤位，以低齡向的遊戲為主。

新天鵝堡在館2的攤位，以日系遊戲為主，例如女僕之心系列是NTD 1500一副（日文），遠比戰死會的HKD $599(英文)為便宜...

桌遊列國的攤位，以美女招來客人，價錢是最低的……我很後悔不在這裏買……

外國的參展商？

香港館……………… 頹……

新天鵝堡在館1的攤位，大概估用了6個攤位的面積。旁邊是MTG及WarHammer。

舊遊戲是以大少定價的

然後對此我最大的感想是………………「老師，我要學英文！」

話說在館3，有歐吉桑問我要不要學英文，我沒理她。

在館1，那些穿得火辣的Show girl都是召人學英文的，但她們就是不理我.

那時我見到有3個男的被2個女的夾擊，各人一面不情願的樣子，可是當被人在背後拍了一下後就乖乖跟著走了。（拍那裏我看不到啊～位置好像有點低...）

「原來還有這一手。」那時我晃然大悟地參透了一個趕羊仔的方法。

Mozilla辦公室

Mozilla早前在台灣開了辦公室，有些台灣的朋友加入了，而這次得到他們的幫忙有幸一睹Mozilla台灣的辦公室。

在此向Thinker及柏強致謝，以及多謝他們送贈的Ion Monkey T-Shirt~

在John O'Duinn來港時提過Mozilla有一個能隔絕電波的實驗室用以測試手機版的Firefox，雖然台灣辦公室沒有這個設施，卻有一個寬闊的空間供社群舉辦活動之用，這實在是太贊了！

首發會

參與那場首發會也是個很不錯的經歷，關於詳情會遲點再補充，那是個非常之有意思的計劃。

飲飲食食

平常到台灣都會去一去度小月（看Sammy的介紹），不過因為今次行程太短，加上要去首發會，所以實際上能自由行動的晚上只有一晚，結果那晚同事帶了我們去在臨江街的紅螞蟻鐵板燒，這個實在是意想之外的美味了！

食材豐富，有蝦、帶子、豬、牛、雞，每一樣都做得很好吃，肉類以蝦、帶子及那件牛扒最為出色，但仍及不上那個煎蛋！外表就像一般的蒽煎蛋，咬開之後會發現只有蛋黃沒有完全熟透，而且二者的生熟程度有明顯的分別，造成相當之不錯的口感。

價錢也很划算，四個人的消費不超過1100台幣，每人消費大概是港幣80元左右。

小點子 - USB線收納

noreply@blogger.com (Ben Lau) — Tue, 24 Jan 2012 12:35:00 +0000

擁有的手提電子設備種類越多 , 需要的USB接線便越多。在這雲端的年代，USB線已經並非是跟電腦同步資料的必需品，最常的用途淪落為充電線。

不過電又不一定是每天都要充的，這得看設備的使用頻率，除了手機每天必須的那條外，其他USB線的使用頻率總是在常用與非常用之間。

把它們放進櫃桶，在需時便得四處尋寶；隨便放在桌上，很快便打成一團，相當惱人。

你家中的USB線是否多得可以放滿一個箱子？

要是桌面空間夠大，又或者書檯簿一些，我倒是想學一學這方法

所以我只好朝高空發展：

這個架子以一個蝴蝶夾為核心，再串起幾個文件夾，讓其夾著USB線後吊起。要使用時只需鬆開文件夾就能取出USB線，這方法比起讓USB線在桌上糾結來得整潔許多。

註：蝴蝶夾是用來整理大型文件用的文具，在大一點的文具店能買得到

屋苑範圍嚴禁擺賣

noreply@blogger.com (Ben Lau) — Mon, 23 Jan 2012 08:05:00 +0000

幾年前開始這個屋苑附近就為趕盡殺絕小販而努力不懈，每當新年時節就會把公眾地方封鎖、加派保安，絕不許小販經營。

小販的確是因此趕滅，不過住戶也被逼付出很大的代價，正常使用的公眾空間都因此被剝削，連行走的道路都被收窄。

行人通道被收窄

大量的空間被列為禁止進入

平常下棋的人限制到一旁

香港的公共空間已經夠少了，我們真的要為此付出這個代價嗎？

相關閱讀

今年是我渡過的農曆新年之中，氣氛最差的一年

2012 －不是最後一年

noreply@blogger.com (Ben Lau) — Sat, 31 Dec 2011 16:32:00 +0000

祝各位2012新年快樂！身體健康，還有那些假世界沒日之名行騙的騙徒遠離大家～

很久沒有動筆寫作，今年的籍口繁忙與去年哲然不同，變化的激烈是始料不及的，在寫下去年大計時沒想到會換了份性質很不一樣的工作，與過往的挑戰完全不同。拜此所暢，去年的大計機乎全部落空……

唯一能完成的是“參加最少一次海外的OSS會議"，在3月時去了台灣OSDC.TW(Open Source Developer Conference Taiwan)、8月份則有台灣COSCUP (Conference for Open Source Coders, Users and Promoters，開源人年會），還順道做了一場難忘的短講。另外也去了些與OSS無關的會議，例如在11月份時去了上海Game Developer Conference(GDC)，還有香港舉辦的SIGGRAPH Asia。

GDC的會場實在令人眼界大開....

可惜的是無法抽空出席在美國舉行的Qt Developer Days...不過這已經算是很充實的一年了，希望下年可以把所有的困難克服，騰出時間去遠一點的地方。

今年有以下計劃：

1. 減磅

這是永遠的新年大計，都快變成怨念了……

話說在去上海GDC時，同行的同事聲稱要減肥，結果我在晚上找吃時特別挑了些好東西，例如有一晚吃了一整盤的炒蟹粉、光是味道及外觀已經感受到膽固醇超標的咸蛋黃鍋巴、一碟不夠還要再來一碟的紅燒肉尖椒（用充滿肥膏的扣肉配上青椒，微辣的口味新鮮，令人食指大動），足以讓個多月的減磅準備前功盡廢。

所以說，別在我面前提減肥。

2. 工作

有新的突破（不能再說太多啦）

3. 遊戲設計

去年的大計之一是想設計出boardgame及一套玩具出來，雖然已經拜托朋友做了些prototype，不過還有很多地方要修正…… 》_《

4. 軟件發表

2010年弄出了Frontview、PenPen及DQuest，但2011機乎沒有作品發表過，現在腦袋裏積存了許多古怪的念頭，已經做了好幾個不同類型軟件的構想，只差什麼時候正式動手……

暫時想做的軟件以productivity為主，例如做想多年的GTD，之後還有一二個mobile app的概念，大概會有一半會以open source的形式發表。

5. 寫作

2011是Blog文量大減的一年，希望2012年可以寫多些文字，不要光是寫code。

希望2012將會是更刺激的一年！

Ducky 1087機械鍵盤開箱

noreply@blogger.com (Ben Lau) — Tue, 08 Nov 2011 16:06:00 +0000

話說我想換一個80%配置的鍵盤，到網上問得到很多湧躍的回應，大家都異口同聲地指向“機械鍵盤”。

想要個好一點配置又體積輕巧一點的鍵盤而已…何必要花那麼多錢啊？

在腦場逛了一圈，不是沒有符合尺吋要求的鍵盤，可是按鍵的佈局簡直是虐待，不然就是讓人噁心的按鍵觸感，最後還是敵不過魔鬼（那些勸你花大錢的人）的誘惑，買了個Ducky的1087紅軸機械鍵盤回家。

準備開箱

打開後，鍵盤被一個絨布袋包著，看起來比較高級

套件包括標準的USB線，還有後備的鍵帽及拆除鍵帽的工具

在選購時，基於我對什麼青紅茶黑軸鍵盤的認識不深，友人向我推薦了一間在福仁商場二樓的店家，說那裏會找到答案。

那是一間非常小的店子，門口放滿了鍵盤，也有遊戲用的滑鼠，以及各種的鍵帽，散發著一種狂熱的氣息。

在我抵達時已經在二組客人在，店主在桌上排放了數種鍵盤，一邊解說一邊讓其中一組客人試打，另一組則在門外等待。

等了一會兒，解說仍未完成忍不住問店主有沒有我想要的設備，他在回答了後又繼續投入服務原先的客人。唯有先去看其他東西吧，差不多半小時後回來，才見到原先在排隊的客人正要離開。

提出了想要80%配置鍵盤的要求，桌面很快就換上了不同的類型，雖然看過網上的評論，但觸感這東西還是要打過才會明白固中的差別，正好把各種軸都打了一遍（青軸真的很吵）

經過店主的解釋才明白原來除了軸外，鍵帽亦大有學問，觸感上的差異也很明顯。

可以隨自己喜好更換鍵帽

Ducky及Filco的機械鍵盤不過是港幣600到1000元之間的價位，這已經叫人咋舌了，在這之上還有二千元的Real Force的鍵盤，健談的店主毫不吝惜地拿了一副Real Force出來讓我試玩。嘩，這個手感及設計的確一流。可惜我未有那麼闊綽。

在有點像個人的授課、補習的最後，又請教了一些關於清潔等的智識，最後終於做出了決定。

店主卻在這時又拿了三個同款的鍵盤出來，說因為並非完全機械生產，所以按鍵的觸感或許會有不同，建議我試打，才去選出自己真正想要的。

這個服務太好了吧？如果去了別間店，大概只是隨便拿一副給我便算了，當然店員也不會解說得那麼仔細。不慚為發燒友的店，果然專業！而且我也很欣賞店主專心服務客人的態度，等那麼久都是值得的。

而當我轉頭離開時，才發現身後原來已經有二組人在排隊等著。

這樣的店子在日本或許不稀奇，在香港竟然會有就非常之難以想像，而且賣的是電子產品啊！

Good bye , Dennis M. Ritchie

noreply@blogger.com (Ben Lau) — Thu, 13 Oct 2011 11:06:00 +0000

K&R是C語言之父、The C Programming一書作者、也是Unix最初的關鍵開發者，這代號分別代表Brian W. Kernighan及Dennis M. Ritchie二人。

如今K&R的組合卻只餘下了K一人，Dennis M. Ritchie先生在上週已經離世。

Dennis Ritchie Dead at 70

在此弔念這位偉大的開發者，送上以下的程式碼：

#include <stdio.h>

int main() {
    printf("Good bye , Dennis M. Ritchie\n");
}

(改自The C Programming一書，用最原始的風格）

奮鬥吧！系統工程師1　兩週內即可上手？SE入門

noreply@blogger.com (Ben Lau) — Sun, 05 Jun 2011 04:24:00 +0000

「我應該是瘋了吧？」當書拿在手中時，我不禁這樣問自己。先要搞清楚，這不是工具書，更不是勵志書，這是「小說」，而且是「輕」小說。最少封面是這樣吐糟的……作者及插畫師的名字都是第一次聽到、封面人物也不算吸引，購書的誘因是好奇，好奇作者可以怎樣把對一般人沉悶的題目化成故事。

故事講述主角是Marketing的應屆畢業生，因為悠閒又忽視社會的殘酷結果找不到任何工作，最後亂遞信卻又給他成功取得了一份System Engineer的工作……

好強烈的概視感

微妙，最初閱讀時的感覺只有微妙，似是而非的IT行業生活在故事中逞現，正是那種口耳相傳的地獄慘況，隨便亂接工作的Sale、隨便訂下工作期限的老闆，逼你不停地與時間奮戰，在網絡上可以很容易地便能找到一大堆範例，到要用一本說來描述是完多餘的行為。

那麼有什麼看頭？經常穿著小可愛像高中生般的上司？這還真是極度的妄想~~(可憐我工作十多年都沒有跟美女共事過)~~，在死氣沉沉的辦公室裏想像就已經是一大救贖了啊！（瘋了）

現實中不可能存在的少女上司，比現實更恐怖的職場，在糖與皮鞭的驅策下奮進的菜鳥，正是此書的核心、趣味的所在。

對於在身處這行業的讀者而言，最驚奇的莫過於書中有很多耳熟能長的技術用詞，作者竟然真夠膽寫出來

除此以外，有一點作者也並非憑空想像，概然如此辛苦爆肝去工作，為何卻仍有人願做呢？

那正是因為這工作能帶來成就感以至樂趣。

（雖然現實上可能有更多的人其實是已經無法轉行……又無法在工作中找到樂趣，結果成為了負能量的集合體。）

到底這本書是否好看呢，這答案還真是微妙，視乎讀者想看什麼，要看現實的一個地獄、再踩多一腳，還是在潘多拉的箱子裏尋回最後的希望呢？

答案顯然而見。

強烈推介的短篇網絡小說 - 魔法革命

其他小說介紹

Bazaar的培訓教材

noreply@blogger.com (Ben Lau) — Thu, 26 May 2011 15:53:00 +0000

Bazaar是我最喜愛的分散式源碼管理系統，因為：

入門的難度要求低　－　不會一開始便有相當之嚇人的概念、名詞要懂
立即使用－只要能分享檔案就能進行團隊開發，不論你是用Samba、Windows的檔案分享，甚至是Dropbox也可以，服務器端不用安裝Bazaar便能立即開始新計劃。
功能強大　－　雖然在這方面總是會被拿來跟git比較，可是Bazaar所提供的功能可說是已經符合絕大部份的開發過程所需的。
便利的圖像介面　－　初學者容易掌握，也有為進階用戶而設的工具
跨平台能力優秀　－　無論是Linux、Mac及Windows都有natvie的安裝程式，而且有統一的圖像介面(Bazaar Explorer)，得到的經驗可以帶去其他平台上使用

比起以上提及的理由，還有一個更重要的原因　－　就是佈教容易，與其他工程相比，要教曉其他人的難度非常之低，只要有Subversion的底子便能很快熟識並使用。

畢竟軟體開發往往不祇是一個人的事，許多時還得為其他人著想……在香港，沒有使用或仍停留在CVS的源碼管理系統的工程師比想像中更要多……，過於複雜的系統只會拖垮他們的步伐，至於我個人也不想花太多在培訓及解決其他人各種的疑難……

即使Bazaar非常之容易掌握，可是許多人的概念仍停留在中央式的源碼管理系統上，對於分散式式系統的使用方法，以及帶來的Workflow轉變不堪了解，所以一些基本的入門培訓課程還是對初學者有幫忙的。

最近正好要辦相關的培訓，為了這個活動我特意準備一份教材，題目是：

Getting Started with Bazaar , How it change your workflow

教材以Creative Commons的CC BY-NC-SA 2.0形式授權，歡迎非商業的使用，不過所謂的商業僅是指用來贊錢而已，閣下要用來培訓員工自然是無任歡迎。

內容集中在Workflow中，列出不同的workflow，以及當中會用到的Bazaar的功能。為了照顧初學者的所需，也列出了許多非常之基本的指令，希望到你們有用。

讓文件輕鬆完成 - 協同寫作

noreply@blogger.com (Ben Lau) — Mon, 23 May 2011 14:46:00 +0000

除非是一些小型或者個人的開發計劃，否則文件是不可或缺的 ﹣ 這是大部份人都認同的想法，可是實際上無數中至大型的專案都有文件殘缺不全的問題，每次要求文件往往都會發生時空扭曲，像是回到傳疑時代要靠「口耳相傳」的方式把項目故事流傳下去。

若問為何如此，大概是因為大部份人（特別是技術人員）都把撰寫文件視為厭惡性的工作吧。

故此有些公司會找專責的人員寫文件，有時會是technical writer，有時則是manager、也有機會找Marketing/sales代勞 ﹣ 因為那是客戶要求的東西，至於是否能反應實際情況.... 天知曉。

而沒有專責人員的公司.. well.. 沒有文件是很平常，有時候更會鬧出笑話。

話說在某U公司，曾經聘請了某內地高手C開發了一件硬件產品，這產品會用於某系統上，完成後則連整個系統交付了給第一位客戶，然後就離職了，他所留下的只有線路及firmware的binary，還有一份難以理解的protocol文件。

後來要把這件產品裝嵌在另一個系統上，新晉的工程師B無法理解這是什麼鬼東西，沒有說明文件，那就自己去研究這東西是做什麼的吧，理解是理解了，不過沒有規格，所以根本不知道能力的上下限在那裹，更甚至他認為這東西其實是廢物來的，只要買個Programmable Logic Controller回來就有等效的能力，而且更平宜。

及後C回巢，B立即提出要求C補回當年的文件，殊不知老闆D與C其實是很要好的朋友，這東西本來就是他們聯手想出的「偉大構思」，基於C又是一位極度厭惡寫文件的人，而又獲得老闆的特別照顧，結果D就異想天開地想出一個方法，就是由D本人開班授徒，把這「偉大的構思」教給其他工程師，再由這些工程師去補寫文件。

那天除了D以外，還有一位manager及四位工程師。

粗略以老闆50k、manager 30k及各工程師17k的人工計算，假設22個工作天，這份大概30多頁紙的文件就得花上近7千元港幣的代價（相信已經低估了這班人的人工），而且故事也沒那麼順利，因為老闆D根本就不懂.....花了一天講的都不過是他所猜度的內容，最後另一位工程師A費了很大的勁力才真的弄出了一份文件。

這個故事告訢我們 ~~有些老闆是白痴的~~ 文件有時要花費莫大的代價…

這種完全不寫、寫不出文件的人並不是十分罕見，在某些地方會經常遇到，不過主要的原因不是出於腦子有文字處理的困難，實質是為了保障自己的措施，為了讓僱主難以把他開除才故意寫不出來。

~~如果我是老闆會優先解僱這種員工。~~

雖然一般的Programmer大多討厭寫文件，但到底討厭的是寫冗長的文件、還是真的連半點文字都寫不出來呢？老實說後者實在不太可能，這可能要去看一看醫生了，所以真正討厭的是寫沉長、甚至沒人看的文件－筆者也怕寫這種文件

不會因此就連半點文件都不寫就是非專業所為了，最低限度如規格、時程、編譯指南、簡短的使用方法等還得由programmer撰寫。

Programmer的本職畢竟不是文字上的寫手，花費過多的時間在文件上會反而影響開發的進度，而且也會讓他們卻步。

故問題是怎樣降低花上文件上的時間而又能維持一定的質素，筆者的建議是collaborative writing（協同寫作），別要一個人把整個系統的文件寫出來，而是各人分工寫不同的部份，然後再檢閱其他有關模組的文件（這通常是由別人寫的），再提出意見、修定，互相彌補不足之處。

首先要文件寫得淺白而懂、連麻瓜都看得懂等的要求拋棄，他們想看的其實是Harry Patter，但你可不是J·K·羅琳；你是一名專業的工程師，這表現在資料的詳盡程度及內容編排上，有需要的也得提供圖片。

然後你要

擔當一名有限能力的寫手，寫出自己負責的部份的文件，再拜託其他同事幫忙校對。
同時擔當一名副業的校對人員，查閱跟自己有關的文件並提出意見，有需要時會自行修改。

把以上寫、校對的過程重複幾次，一份詳盡而又足夠讓技術人員明白的文件就會誔生。

至於是否一份讓管理層贊賞的文件……？well，別做多餘的事。記得在大學工程學院讀書時，technical writing那課特別強調文件要寫得淺白易懂、更要讓麻瓜也看得明白…………這是嚇壞programmer的原由之一吧！

真的是弄出針對一般人看的文件，不如直接請個專責的technical writer吧！

別要求programmer當作家，他們的責任應當是提供一切需要的資訊，讓文字美化的工作需找其專責的人員

舉一個例子。

在筆者任職過的某公司，要用某嵌入式平台進行開發，包括筆者在內沒有任何人有過這平台的經歷，故找了某君當前鋒摸索，那時筆者要求他把結果寫成文件，而他立即面露難色。

筆者就降低要求，只需要把打過的指令及使用的檔案例出來，文件的第一版很快就完成了。

然後筆者跟著這份文件設定環境，過程中加上適當的指示，有無法進行的步驟則要求原作者補充，花了點時間終於完成了第二版的文件，其他同事就依第二版文件進行設定，大部份都能立即上手。

後來要讓其他部們的人也跟著做，基於專業有異，第二版的文件他們有許多地方看不懂，收集了他們的疑問後弄出了第三版－那是連非這個專業的人都能照著做的文件。

雖然時間長了一點，不過協同寫作對所有人的壓力都是最低的，可以讓programmer更樂於從事文件的寫作。

要做到協同寫作，最簡單的方法莫過於使用wiki，概可讓多人同時寫作，又有版本控制，追蹤修定也非常的簡單。

Wiki的好處：

協同寫作
版本控制
搜尋簡便

當然Google Doc也是一個不錯的選擇，這視乎公司的選擇。

相關閱讀

故事式規劃設計

This is not a bug but intended design feature

noreply@blogger.com (Ben Lau) — Tue, 03 May 2011 16:03:00 +0000

「This is not a bug but intended design feature.」

在欠缺上文下理時聽到這句話，你會作何想?

全盤接受？耍嘴皮？騙鬼？開玩笑？

這不能排除有這個可能，可是我會偏向負面的意思，畢竟Bug就如小強一樣，是讓人惡厭的東西，如果一項功能會讓別人以為是bug… well。

本人某天的晚餐，聯想力高者勿看

這句子成立的情況有許多，只是大多數情況下都不成立而已，比較常出現而又成立的應該是遊戲設計上。

例如我看過這篇文章 ﹣ “这不是Bug而是个Feature”，其中提到一個叫ExtremeG的N64賽車遊戲的的bug。

本來有一個AI來讓電腦玩家決定在何時使用Turbo超車，但因為編程錯誤讓電腦玩家變得非常之侵略性，即使在灣道也不許你超車，會立即使Turbo迎擊，結果就是一團糟的車禍意外.

測試者的評價是贊賞的！

類似的故事在遊戲業界還能找到許多，基於我不是屬於那個界別，而又不是不負責任之徒，所以還真是沒有說過這番話，解釋bug與defect倒是經驗豐富，因為許多客戶都把不存在的功能視為bug，費的力氣還真不少。

雖然沒有把bug當作過feature，不過把不可預測狀況的代碼送出去倒是做過。

在ThinkGeek或一些網站可以買到一個叫做USB Stress Game的玩意：

(ThinkGeek的示範，不過那是錯誤的，請看下去 ;) )

當年我為客戶設計了這個玩具的程式，這玩意能接駁電腦，你可以拉、推及扭這個“球”，然後電腦的畫面就會被你所扭曲。

最初的規格裹面定義4種扭曲，然後由一種扭曲轉到另一種之前要先把畫面還原。

依足要求完成後，客戶說：

「效果好像不太好...」

「那要怎樣的效果呢？」

「hmmm… 最好是不用變回原狀，直接變成其他扭曲。」（規格要修改了！要加入新的過渡動畫）

「那已經不是原來的形狀了，我們有4種扭曲，如果要加入過渡的動畫，就要多6種效果，你們要設計這6種，而我們又會很辛苦，這超越了預算，我們得...」

對方明白我們的難處，所以陷入了沉思之中。

這個動畫是利用物理模擬的方法製作的，基於當初的要求，改變扭曲必須在畫面還原後進行，所以有額外的代碼確保流程，不過因為程式架構做得好，改動的難度低，所以我提出：

「不如這樣子，我把確保畫面如規格般顯示的代碼關閉，我不能保證會發生什麼事，動畫可能會變得亂七八糟，先讓你看一看效果吧。」

花了數分鐘改寫代碼，成果如下：

從14秒開始就是多出來的效果，例如翻頁、螺旋、無限拉長、局部變大等等，那完全是規格外、不在設計之中的效果，而且多出的效果可不祇有6種，只要按鍵的次序及時機不同便會生出現許多無法預測的動畫，就算是作者本人我也不知道 XD

結果客戶飛快地接受了這個版本，後來還把幾項控制用的代碼刪掉，在保持原來四種扭曲時，其他過渡動畫的表現更加隨機。

想不到跟規格做的東西反而是多餘的 XDDD

說了些bug / defeat變成feature的實例，也說些完全相反的混帳事。

在上文<<買Motorola手機前請先考慮清楚 (包括Atrix)>>說過我對MO記震蛋的投訴，後來又收到了一個白目的回應：

「This is not a bug but intended design feature.」

即是代表：「震蛋是功能，不是錯誤」

（回答者是一名MOTO Expert，說是volunteer，但如果沒有跟Motorola的聯絡，又那會說得出這是design!?）

到底為何MOTOROLA的設計師/高層那麼堅持手機必須在使用震個不停來虐待用家,我是完全沒有頭緒啦，說不定他們其實有什麼特殊的使用方法，是我們好孩子們不應該知道的。

作為消費者，我認為被愚弄了，別說其他公司的產品，剛是第一代Milestone就沒有這個bug，用feature來推卸責任，我唯一想到的解釋是：「那一定是用來懲罰用家的功能！」

我強烈建議Motorola還要加入播歌功能，唱：「你真是蠢！蠢！蠢！，蠢得真奇妙！妙！妙！」

概然他們堅稱那是功能，那可以想像到之後還是會有新成員作加入震蛋系列，祝各位用家好運。

買Motorola手機前請先考慮清楚 (包括Atrix)

noreply@blogger.com (Ben Lau) — Sat, 16 Apr 2011 15:13:00 +0000

若你討厭觸動回饋(Haptic Feedback)，在選購Motorola的電話前請三思。

話說我一直在用的手機因touch screen失靈加上水貨的原故，不得不買過一部新電話，基於要盡快解決，什麼快有新機推出、所以會降價等因素一概不考慮。快速地鎖定了二個型號，分別是Motorola Milestone 2及HTC Desire Z。

最後我選了Motorola Milestone 2 ﹣﹣﹣﹣﹣ 那真是蠢弊了的選擇。

買機時當然有做檢查，試了好一段時間，大致滿意，至於預設上有不喜歡的地方，應該可以通過設定改變吧。

Murphy大神在此顯靈

許多手機都有一個叫觸動回饋（Haptic Feedback）的功能，當你按上某些軟體上的按鈕，手機便會震動代表你按對了。

有些人喜歡這個功能

有些人討厭這個功能

本來問題用不著放大，不愛便關掉吧，總之有大家都開心的方案存在。

可是包括Milestone 2、DEFY甚至Atrix在內，這些手機都是不能關掉Haptic Feedback的!!!!!

以Milestone 2為例，在設定 - 音效裏找得到「觸動回饋」，可是任你怎樣按都好，Haptic Feedback還是陰魂不散、揮之不去。

第一代Milestone的用戶表示這選項運作正常，可是找一找Internet，所有二代用戶都無辦法成功。然後再追查一下，受影響並不祇一個型號！

我是屬於討厭這功能的一群，而且是極端厭惡那種，因會令手指酸痛，到底我在用的是手機還是震蛋啊！？

軟件中有二處地方用上了Haptic Feedback，首先是螢幕下方的四個經常使用的software button，每次按動都有輕微的震動，令手指有點不舒服；然後是在解鎖時，會有很大的震動，如果放在桌面上更會令手機移動的，非常之惱人。

早在去年11月已經有人在Motorola自己的Owners' Forum匯報，當時回答說會修正，可是4個多月過去了，仍未有消息，在我追問之後，結果卻哲然不同，說在可見的將來都未有計劃去修正，更甚者是有Motorola員工認為這個不是bug!?!?!? (在後來的post中修正了，不過在其他的回應又說成是feature)

我氣炸了

基於在香港不會讓你用這種理由退貨，那只有幾個選擇：

賣出去，再買過一部
自虐地接受
Hacking

1會蝕很多、2不符合我的作風，設備用得不開心是會影響心情的，結論只有選擇3

在網上找方法，有人提過root後重包framework-res.apk便能解決…… 真好…… 第一天買回來就要去root機，本來未有計劃做Android開發，結果被逼學了許多。

可是z4root無效，看來還得花很多時間……而最近太忙了，只有退而求其次，採用硬體的Hacking方法。

這部電話有個很有趣的地方，就是用來震機的馬達只要在拆開電池殼就會見到，然後跟我一樣討厭Haptic Feedback的人想到一個方法。

只要~~加一條貞操帶~~用紙塞入去，再用膠紙固定就可以讓震蛋手機別震，而且這方法不會破壞保養，不留痕迹地移除是很簡單的。

留意：長期使用這方法有可能令馬達受損。

紙的厚度決定還餘下多強的震動能力，太厚便會令正常的來電震動也閹掉，要試好幾遍才能找到理想的大少。

看到這裏，閣下大概都會覺得………………這一連串的動作根本就是蠢弊了！

買Motorla的電話就像在懲罰自己一樣。

OSDC.TW 2011之旅

noreply@blogger.com (Ben Lau) — Tue, 05 Apr 2011 10:36:00 +0000

通過plurk認識了更多的台灣朋友，聽他們說了許多關於當地活動的趣聞，早就心癢難耐想見識一下，所以在本年度大計中就把參加OSDC TW 2011視為其中一項目標，過程中充滿變數，幸好最終都把所有問題解決－如期乘行！！

OSDC TW為期二天，在中研院舉辦，地方有點偏遠，對外地人有點不便，幸好大會有提供免費的接駁巴士，由捷運站出發直抵會場。

（抱歉，我沒怎樣拍照。）

抵達後首先就見到了pct，及後通過“座位表“找到了Thinker，認識了一二位朋友，至於Rex Tsai則要等到晚上的github聚會才有幸見到。

第一天的議程先由key note開始，共有三位講者，講題分別為「微軟與 jQuery 社群的親密接觸」、「HandlerSocket - A NoSQL plugin for MySQL」、「Apache ZooKeeper: Taming Distributed System」。

進入會場第一件事當然是嘗試連接網絡，基本上每個座位都有LAN port，可是我沒有想過可以駁網線，故只好轉用Wifi，雖然有不少人在河道投訴無線網絡慢，但我又完全感覺不到。

很有趣的是在期間經河道見到一個google doc的座位表，讓你自行填寫所在的位置，這讓我找到了Thinker。

之後都是聽講座跟人聊聊這樣的，意外地是都有不少操英語或來自日本的講者。

到了晚上，github搞了個聚會，有免費的啤酒提供，雖然我不好飲酒，難得能與當地人談天說地，自然要出席。

其間跟Rex Tsai、Thinker、macpaul、hychen及同樣來自香港的Henry Law他們談了許多有趣的想法，最為印像深刻的是有人提到：搞OSDC有三件事是特別重要的 1) 正妹 2) 網路 3) 食物，概然沒有正妹，就唯有在食物上滿足大家吧。

真是令人感動啊！

到了第二天，活動一樣是會議，不過有jserv打頭陣，另外我終於見到了Fourdollars。

會議的最後一個環節是lightning talk，讓參加者有五分鐘的時間介紹自己或其他開源題目，最先出場的是高橋征義！

wow，見識到了正宗的高橋流演講，而且他不愧是動畫宅之一，在簡報內不忘把QB / Kyubey 召喚出來跟大家定契約，支援日本現今的災難。

這節環相當之有趣啊，讓所有講者出場花了近一小時，可是卻機乎沒有悶場，可算是會議的壓軸好戲。

活動在這之後完結，我想對此最為驚訝的不單在於參加人數、籌備的規模，還有的是內容的性質，不少都是相當之hard core的題目啊，像是Perl 6 Signatures: The Full Story、Gallium3D - Mesa's new driver model、Inside A Compiler這些都在是非常之深入的題目，要在香港找到聽眾可不容易呢！

以下是我去了聽的題目：

HandlerSocket - A NoSQL plugin for MySQL
Apache ZooKeeper: Taming Distributed System
Android for tablets
A Sneak Peek on WebKit's CJK Processing: Starting from a Forthcoming EPUB 3.0 Features
從 U-boot 移植 NDS32 談嵌入式系統開放原始碼開發的一些經驗
Groonga, full text search engine
Build Programming Language Runtime by LLVM
SVG+Javascript meets Embedded Systems
Gallium3D - Mesa's new driver model
Inside A Compiler
Contributing with Git : Reducing the frictions of Open Source collaboration with the Git VCS (github)
Tor and censorship: lessons learned

接下來台灣下個大型OSS活動是COSCUP，希望也能參與吧。

OLPC及Qt扭蛋

noreply@blogger.com (Ben Lau) — Sun, 20 Mar 2011 12:16:00 +0000

此乃標題殺人之示範，若然閣下是因好奇怎會有OLPC及Qt的扭蛋才進來的話，抱歉，你被騙了。

不過我手上的確有二款能勉強扯上一點關係的扭蛋。

第一款叫做DIY Puzzle Mobile keyring (mobile series)，每隻蛋都有匙扣，連著一塊板子，並有些不同顏色的部件可以插在上面拼成不同的圖案，預設的花式為iPhone上的各種應用程式Icon：

雖然我沒有iPhone，也沒計劃買iOS的設備，還是貪得意抽了隻回來，而我所抽到的是電話應用的圖示(最右邊的那個），剛巧顏色跟Qt的圖案很接近啊，所以就試著砌成Qt會怎樣呢，成果如下：

可惜淺綠色的部件不太足夠，效果未夠理想。

參考的圖樣：

另一款是叫做Match man（火柴人）的扭蛋，有活動的關節及不同的部件，可以砌成消防員、救護員、警察等不同的職業。

其中有一款的顏色跟OLPC的看來很像，而且還帶著手提電腦部件，初出來時我們都已經叫這款火柴人做OLPC，而為了拿到這款花了我了不少金錢呢……（遠目）。

在裝嵌時又花了點心思，把手腳換成白色，看起來跟OLPC又更像了，成果如下：

現在的扭蛋真是好玩，不但有許多的花款，而且有很大的彈性，只要有創意就可以塑造成其他的模樣，有時候閒著沒事去逛逛也很有趣，話說之前我又發現了一款可以用來做魔術表演的扭蛋，價錢比起在魔術店便宜太多了，可惜我忘了那個技巧，結果沒有入貨。 ~_~

給Qt Ambassador的禮物

noreply@blogger.com (Ben Lau) — Wed, 23 Feb 2011 13:07:00 +0000

Nokia/Symbian的支持者自從 #elopocalypse 事件後就處於一片愁雲慘霧的狀況中，相比起來Qt的社群就比較穩定，雖然不少人在Nokia Blog上投下了不信任的聲音，Qt的開發人員卻表示樂觀，後來更跑出了Android-Qt的發佈消息，對社群而言最壞的結果也不過是由社群接手Qt的開發而已，LGPL的程式碼又有何懼哉？

所以我仍在快快樂樂地開發Qt的程式，今天更收到了一份由Nokia送給Qt Ambassador的禮物:

當中包括一件Qt Ambassador的T-Shirt、貼紙及一部全新的Nokia C7手機。

早在#elopocalypse之前已經聽說過會有份禮物給Qt ambassador，只是沒想到會有手機，無論是T-Shirt及貼紙我都很喜歡，有了2件T-Shirt在參加OSDC時就可以替換，貼紙則能送給其他Qt開發者們。

不過C7就有點微妙，如果在#elopocalypse前收到這份厚禮我會很興奮，現在……該怎樣處理好呢？

雖然有點苦惱，不過也得向Nokia說聲多謝，Qt這方面我仍會好好努力的，當MeeGo的設備推出時我會回來開發程式，不過現在就先容我把精力放在桌面及嵌入式設備吧。 ;)

註：這與 Nokia 將發送 E7 & WP7 開發機給軟體開發者... 一文提的事無關，那是給Nokia Forum Launchpad的會員的，C7是在#elopocalypse的概定計劃，E7及WP7大概是在這之後的救忙行動吧。

Plurk的遺言（誤）

noreply@blogger.com (Ben Lau) — Tue, 15 Feb 2011 15:56:00 +0000

在Web 2.0普及的現在，無論網站是要掛掉還是例行維修，一般都能看到一個靚靚的畫面說句抱歉，看到代碼的情況非常之罕見，不過看來仍是有例外，例如說我今晚上plurk就見到以下的訊息…… (留意當中包括什麼? ;) )

Traceback (most recent call last):
  File "/home/plurk/plurk/git_trunk/ext/parts/web/wsgiserver/__init__.py", line 1183, in communicate
    req.respond()
  File "/home/plurk/plurk/git_trunk/ext/parts/web/wsgiserver/__init__.py", line 553, in respond
    self._respond()
  File "/home/plurk/plurk/git_trunk/ext/parts/web/wsgiserver/__init__.py", line 565, in _respond
    response = self.wsgi_app(self.environ, self.start_response)
  File "/home/plurk/plurk/git_trunk/ext/werkzeug/utils.py", line 859, in __call__
    return self.app(environ, start_response)
  File "/home/plurk/plurk/git_trunk/ext/parts/web/web.py", line 295, in dispatch_request
    rv = handle_error()
  File "/home/plurk/plurk/git_trunk/ext/parts/web/web.py", line 358, in handle_error
    result = handler(e)
  File "plurk/web/error_handler.py", line 65, in error_handler
    trace_back=t_b)
  File "plurk/templates.py", line 143, in renderPlurkTemplate
    html = PlurkTemplates().addDynamicData(html, ses_user, page_user)
  File "plurk/templates.py", line 149, in addDynamicData
    'session_user': users.exposeSessionUser(ses_user),
  File "plurk/users.py", line 321, in exposeSessionUser
    session_user['notifications_count'] = Notifications().getCount(user.id)
  File "/home/plurk/plurk/git_trunk/ext/parts/cache/__init__.py", line 125, in proxy
    value = f(*args, **kwargs)
  File "plurk/models/notifications.py", line 112, in getCount
    where='status in (0, -2)')
  File "/home/plurk/plurk/git_trunk/ext/parts/db/wrapper.py", line 236, in selectCount
    res = self.select(table, cols="COUNT(%s)" % column, as_one=True, **kw)
  File "/home/plurk/plurk/git_trunk/ext/parts/db/wrapper.py", line 120, in select
    with self.cursor(sql) as cursor:
  File "/home/plurk/plurk/git_trunk/ext/parts/db/wrapper.py", line 54, in cursor
    con = self.connections.getConnection(host)
  File "/home/plurk/plurk/git_trunk/ext/parts/db/wrapper.py", line 578, in getConnection
Exception: Could not create a connection on servers [{'charset': 'utf8',
  'compress': False,
  'exception': 'Traceback (most recent call last):\n  File "/home/plurk/plurk/git_trunk/ext/parts/db/wrapper.py", line 554, in getConnection\n    if con:\n  File "/usr/local/lib/python2.6/dist-packages/MySQL_python-1.2.3-py2.6-linux-x86_64.egg/MySQLdb/__init__.py", line 81, in Connect\n    return Connection(*args, **kwargs)\n  File "/usr/local/lib/python2.6/dist-packages/MySQL_python-1.2.3-py2.6-linux-x86_64.egg/MySQLdb/connections.py", line 187, in __init__\n    super(Connection, self).__init__(*args, **kwargs2)\nOperationalError: (2002, "Can\'t connect to local MySQL server through socket \'/var/run/mysqld/mysqld.sock\' (2)")\n',
  'host': 'localhost',
  'passwd': u'plurk',
  'port': 3306,
  'refresh': True,
  'success': False,
  'use_unicode': True,
  'user': u'plurk'},
 {'charset': 'utf8',
  'compress': False,
  'exception': 'Traceback (most recent call last):\n  File "/home/plurk/plurk/git_trunk/ext/parts/db/wrapper.py", line 554, in getConnection\n    if con:\n  File "/usr/local/lib/python2.6/dist-packages/MySQL_python-1.2.3-py2.6-linux-x86_64.egg/MySQLdb/__init__.py", line 81, in Connect\n    return Connection(*args, **kwargs)\n  File "/usr/local/lib/python2.6/dist-packages/MySQL_python-1.2.3-py2.6-linux-x86_64.egg/MySQLdb/connections.py", line 187, in __init__\n    super(Connection, self).__init__(*args, **kwargs2)\nOperationalError: (2002, "Can\'t connect to local MySQL server through socket \'/var/run/mysqld/mysqld.sock\' (2)")\n',
  'host': 'localhost',
  'passwd': u'plurk',
  'port': 3306,
  'refresh': True,
  'success': False,
  'use_unicode': True,
  'user': u'plurk'},
 {'charset': 'utf8',
  'compress': False,
  'exception': 'Traceback (most recent call last):\n  File "/home/plurk/plurk/git_trunk/ext/parts/db/wrapper.py", line 554, in getConnection\n    if con:\n  File "/usr/local/lib/python2.6/dist-packages/MySQL_python-1.2.3-py2.6-linux-x86_64.egg/MySQLdb/__init__.py", line 81, in Connect\n    return Connection(*args, **kwargs)\n  File "/usr/local/lib/python2.6/dist-packages/MySQL_python-1.2.3-py2.6-linux-x86_64.egg/MySQLdb/connections.py", line 187, in __init__\n    super(Connection, self).__init__(*args, **kwargs2)\nOperationalError: (2002, "Can\'t connect to local MySQL server through socket \'/var/run/mysqld/mysqld.sock\' (2)")\n',
  'host': 'localhost',
  'passwd': u'plurk',
  'port': 3306,
  'refresh': True,
  'success': False,
  'use_unicode': True,
  'user': u'plurk'}] : {'charset': 'utf8', 'use_unicode': True, 'server_name': 'plurk_group005', 'db': '', '_rhost': u'192.168.0.18', 'compress': False, 'resolve_host': , 'shard_info': {'name': u'mothra', 'id': 2L, 'host': u'192.168.0.18', 'host_extra': u'192.168.0.16', 'balancing': u'host', 'user': u'plurk', 'password': u'plurk', 'port': 3306}, 'port': 3306, 'host': 'localhost', 'user': '*', 'refresh_host': , 'password': '*', 'id': 'shard_db_:2'}.
Error was Traceback (most recent call last):
  File "/home/plurk/plurk/git_trunk/ext/parts/db/wrapper.py", line 554, in getConnection
    if con:
  File "/usr/local/lib/python2.6/dist-packages/MySQL_python-1.2.3-py2.6-linux-x86_64.egg/MySQLdb/__init__.py", line 81, in Connect
    return Connection(*args, **kwargs)
  File "/usr/local/lib/python2.6/dist-packages/MySQL_python-1.2.3-py2.6-linux-x86_64.egg/MySQLdb/connections.py", line 187, in __init__
    super(Connection, self).__init__(*args, **kwargs2)
OperationalError: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")

看來Plurk是用Python開發，用git來管理代碼……

#elopocalypse - Stephen Elop的啟示錄

noreply@blogger.com (Ben Lau) — Sun, 13 Feb 2011 02:48:00 +0000

(請讀者自備爆谷）

將導至Nokia直接走入下陂的事件（前文），被網民戲稱為elopocalypse (Stephen Elop加上Apocalypse合拼而成)，因為群眾普遍認為Stephen Elop是眼前最大的黑手，對他的攻擊自然不少，加上裁員直接影響芬蘭，所以芬蘭的政府及傳媒也極速運作。

其中一項重要情報是，他沒有持有Nokia的股票，以CEO來說是極奇罕見的事，另一方面，他手上擁有大量的Microsoft股票，以個人持有者的數量排名，他更是第8名的持有者！！

1) 他沒有持有Nokia股票 : 證據 - Nokia自己的網頁

2) 他擁有大量的Microsoft股票

消息來源：芬蘭的報導 , Google翻釋

證據－股票資料

接下來幾天針對這消息的行動應該會開始，請各位拭目而待。

其他消息：

另外關於Stephen Elop本身，他曾經當過Macromedia的最後一任CEO，然後讓公司就被Adobe收購，對此有網民發表當年的慘況……
Nokia USA president is out, replaced by Microsoft vet Chris Weber as Elopocalypse continues . well , 進一步控制？

Nokia的悲劇

noreply@blogger.com (Ben Lau) — Sat, 12 Feb 2011 14:32:00 +0000

這個週末的工作本來是打算寫RepRap的開箱文，不過星期五發生了一件非常震驚的事，不得不先寫這邊，那就是Nokia將採用WP7作為手機的主要OS！而原先推出MeeGo的產品將會延到年尾推出。

Maemo、Nokia Blog及其他有關的網站都爆炸了！

雖然現在Nokia的fans相比起其他系統少許多，不過即使你不是fans，我也建議你們關注這件事，理由有二：

一是推動這件事現任Nokia CEO Stephen Elop 本來是 Microsoft 的 Business division的President，整件事有著很深的陰謀味道，活像一篇現代的木馬屠城記，各位請準備爆谷。

二是看著一間背叛了fans期望與員工信心的公司會發生什麼事。

基於要寫深度的評論不易，所以這篇文章將會集中在一些網上的反應。

Nokia outlines new strategy, introduces new leadership, operational structure

這是Nokia最初的新聞消息，在星期五發表，然後Nokia的股價隨即下挫，英國那邊跌了14.35%，美國那邊遲些開巿，不過不足一小時就趺了13%，可能因為消化了消息，最終沒有打破14%，以13.97%的跌幅收巿。

同時Microsoft的股票也沒有因此而上昇，到了最後更見了紅，沒Nokia那麼慘就是。（來源）

這事不單激弄了開發者，連投資者也不討好，希望下星期會聽到Stephen Elop被炒的消息(下文有更勁爆消息）。

Letter to Developers about Today’s News

後來Nokia又在blog裏發達了一封給Develoepr的信，這成為了developer們發洩渠道之一，不過還不是罵得最兇的，下一篇才是。

Five reasons to get excited about a Microsoft partnership

Nokia用了WP7有五大好處(?)，沒心機看不打緊，看網民回應就值回票價了(拿爆谷)。

#elopocalypse

Twitter上出現新的hashtag : #MeeGone及#elopocalypse (用Stephen Elop加上apocalypse合拼而成)

Maemo forum方面處於爆炸的狀態，一天內就出現了上千封以上的回應。

Poll: Would you buy a phone running WP7?

結果是一面倒的，發文時有454人投了票，90%人表示不會買，留意，這裏可算是最多N900 fans聚集的網站。

POll: After Nokia/WP7, what will you buy next

這邊很有趣，大家還會期望MeeGo嗎？結果是Android僅僅稍勝，只是比MeeGo多2%的用家支持，fans們還未完全放棄MeeGo呢！

Open Governance continues

Qt有一個叫做open Governance的計劃，就是研究怎樣由open source community去管理Qt的發展，而這個計劃並未有因此停止！！！即使Nokia出了什麼事，這個計劃仍會繼續下去，所有Qt開發者們請放心！

而且覺得Intel及Ubuntu都會有興趣接手，所以不用擔心商業支援方面。

若說有誰因此而損失的，大概就是花了$85歐元考了三張Qt證書的我吧...

Nokia員工的反應

在Nokia於Tampere的HQ，有1000們員工徒步出去公司，以示抗議。

註：我在十多年前去過這城市及參觀過Nokia的HQ，印像中不太覺得像是能容量1000人的建築啊……

Bug 13453

Nokia採用WP7而推遲MeeGo電話的發佈，是Bug來的！

Quim及Texrat

Quim及Texrat可算是Nokia在MeeGo上的社群代表，我在Ireland認識了他們，都是些很有趣的人，也是在這件事上最受到的傷害的人吧，許多人感受到被背叛，有些人會把予頭指向他們，所以他們的twitter也很熱鬧，但事實上他們也是受害者啊………

你們加油啊！還有許多人支持你們的！

這是Quim的回應

其他人的支持說話：

"Keep your head up Quim! This is but a bump in the road. If Nokia totally drops the open source ball, someone else will see the potential and take Qt and the Linux phone stack to successful completion. If it doesn't work out, I hope to see you joining Ari at HP soon"

"As a nokia shareholder I want to see Quim as the new Nokia CEO."

Stephen Elop

這位擬似現代木馬屠城記的主角，自然成為了攻擊的對像，其中有二個消息是相當之有趣的。

第一，他並沒有持有Nokia的股票：

證據：Nokia自己的網頁

CEO最賺錢的一般都是自己公司股票，但他竟然沒有持有，老實說這很奇怪……然後爆出了更大的消息：

第二，未經證實消息，他所持有的Microsoft股票量是第七高的。

這是在Twitter裏開始流傳的消息，我了幾遍，看來最早的出處是這篇comment:

據說消息是來自芬蘭的某報章，那大概是以芬蘭文寫的，看來要等一段時間才能證實，如果資料屬實……

well…………………… 芬蘭政府會出手吧？最後演變成外交衝突？

說了很多消息，至於我的想法呢

如果Nokia是把WP7視為平衡的方案，繼續玩Symbian及MeeGo，我認為影響不會那麼大。雖然說過二者仍會開發，但MeeGo廷遲到年尾，又玩大栽員，不少Symbian方面的員工會失去工作，那麼在推出WP7前，Nokia吃什麼？大家都知道Symbian是沒戲的了，炒了那麼多員工，有關的電話只會越來越差。

或許能把這個視為破而後立的必經階段，不過所許諾的遠景未免太悲涼了吧，即使存活了，Nokia的R&D能力大減，在WP7的發展上又沒什麼主導權，結果只是淪落成HTC級數的公司。

那麼有沒有可能當穩定下來後，Nokia又再搞自己的系統，踢開Microsoft呢？

沒門

如果Nokia的WP7仍留有Qt的位置，那情況將大大不同，投身Nokia的WP7開發者仍有機會轉到Nokia的其他平台上，沒把Qt併入WP7不單是長遠策略上的失誤，而且亦令難得聚集起來的開發者們感到強烈的被背叛感覺。(這二天我都盡量到我在Ireland認識的開發者們的blog、twitter裏留言，希望仍能保持一定的關係)

當投資者、開發者、fans們都走了時，還餘下什麼？

有，就是WP7的fans及開發者，不過那是WP7的，不是Nokia的，而且人數搞不好比open source community的支持者還要少。

如果以陰謀論看這件事，那只能用高明來形容，如果要買下Nokia這間公司不知要得花多少十億，但現在這麼一搞，Nokia的股價低了，支持者都少了，R&D能力大減，除了依靠外來的技術支持還可以怎樣做？

連收購都不用就把一間公司置於自己的控制之下……想起來就感到戰慓。

將來還有誰夠膽挖走他們的高層呢？

現在雖然九死一生，不過也代表著一個機會，過去Nokia決策遲緩又三心二意的主因應該是出於過於擁腫的架構，被Stephen Elop那麼一搞，留下的人裏應該也有不少準備跳糟，餘下的人若真的有心重振Nokia，再把沒前途、沒將來的WP7計劃踢走，專心做一樣以Qt為主的ecosystem的產品出來，或許仍能殺出一條血路。

新年敗物第一回 - 3D打印機

noreply@blogger.com (Ben Lau) — Thu, 03 Feb 2011 10:22:00 +0000

今年CES的最聳動產品首推Motorola的Atrix，連我也想轉陣要一台，其次應該便到MarkerBot的3D打印機。

動輒便要數十萬的3D打印機現在竟然只需花USD $1225便能擁有一台，難怪令許多人雀躍不已。

可是我個人對此的反應很冷淡，隨便看了些資料便不再深究，因為早在MarketBot推出前己經有開源的RepRap計劃，而且價錢也更要低廉，更重要的一點是RepRap的設計容許進行自我複制，只要買一台回來，跟著便能再生產另一台出來。（不包括馬達、線路版及噴嘴等無法“打印“的部件）

其實早在CES之前，我便有打算"敗"一台3D打印機回來"玩"，目標自然是RepRap，一來支持開源計劃，也想在香港推擴一下，二來是看中了能duplicate這點，更易令人有帶回家的衝動，換言之RepRap推擴潛力比起買一台完成度"可能"更高的商業產品來得優厚。

（潛台詞：我又不是當代理的，為什麼我要去推擴純商業的產品？）

找到了人合夥夾錢，找到了人幫忙進行機器的維護及日後開班的準備，跟著就突然殺出了MarkerBot的消息，雖然我沒什麼興趣，拍擋們審慎起見，還是看一看資料。

首先……資料真的不多，與RepRap的比較資料很零碎，網上有些見解甚至是把MarkerBot視作為RepStrap的機器（即是一台比較簡單的機器，可以用來製作RepRap）。就價錢而言，未組裝的RepRap比MarkerBot平，已組裝的卻要貴一點，差價都是在USD 100左右。

就外觀設計而言……有個頗糟的見解，怎麼看來就像第一代RepRap Darwin加四塊板的樣子？

軟件方面有些RepRap沒有的功能，不過算不上killer feature……

拍擋的結論是：RepRap吧。

然後速速落單，等了幾星期，大概下星期便會送來了！

(遲些再談多些關於這台打印機及我們的開源“計劃”）

Unlimited Ben's Works

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

程式師的修練場 - 建立自己的Junkcode及測試程式庫

故事式規劃設計

Evernote活用術 - 助你找尋物件

OSDC.tw 2012後記

用「筆」閱讀

需求分析 － 魔鬼都藏在細節裡

短暫卻精彩的台灣之旅

小點子 - USB線收納

屋苑範圍 嚴禁擺賣

今年是我渡過的農曆新年之中，氣氛最差的一年

2012 － 不是最後一年

Ducky 1087機械鍵盤開箱

Good bye , Dennis M. Ritchie

奮鬥吧！系統工程師1 兩週內即可上手？SE入門

Bazaar的培訓教材

讓文件輕鬆完成 - 協同寫作

This is not a bug but intended design feature

買Motorola手機前請先考慮清楚 (包括Atrix)

OSDC.TW 2011之旅

OLPC及Qt扭蛋

給Qt Ambassador的禮物

Plurk的遺言（誤）

#elopocalypse - Stephen Elop的啟示錄

Nokia的悲劇

新年敗物第一回 - 3D打印機

需求分析－魔鬼都藏在細節裡

屋苑範圍嚴禁擺賣

2012 －不是最後一年

奮鬥吧！系統工程師1　兩週內即可上手？SE入門