VIVOTEK Digest

最近因為工作的關係，很需要從 USB 不斷的開機。在實體的機器，開機需要等待兩分鐘以上的 BIOS 過程，生命不斷的流逝下，興起了採用 VM 進行測試的念頭。剛好最近買了一台新的 notebook，記憶體特意買大一點，所以就開始試起 VM boot。

過去同事們最常使用的是 VM Ware，所以先說說 VMWare ，簡單的答案是，VMWare 沒有支援從 USB 開機。但是有好心人寫了一套 plop boot manager，只要在 VMWare 中選擇建立一個以 iso 為開機的新 vm，其中的 iso 可以指定從 plop 的 zip 中取出的 plpbt.iso檔。然後當你 boot 時，就可以看到 usb 開機的選項。選了就可以從 usb 開機。但這個方法我用了身邊的所有 usb 碟，一直沒有成功 ，Clonezilla 可以，但 Windows embedded 7 的安裝 usb 就是不行 (FAT32 or NTFS 皆不行)，我得到的畫面如下
大概就是說找不到可以 boot 的 device。另一個問題是 VMWare 的字在我的 notebook 上實在太小了，為了眼睛，我就跳槽到 virtual box 的懷抱了。

VirtualBox 是 Oracle 的 Open Source project，所以免費。另外他支援 VMWare 的 vmdk 檔案，這代表過去我們已經用了多時的 vm 基本上都可以繼續使用。不過小地方可能要注意，那就是兩個 vm 系統模擬的硬體可能會有些差異，所以一些 driver 可能得重裝。

進入正題，VirtualBox 有沒有支援 USB 開機呢? 答案是：也沒有。因為開機能不能選 USB 是 BIOS 的事情，所以簡單的說就是 VirtualBox 的 bios 並沒有提供 USB 開機，我看到有人在 virtualbox 的論壇上提到此事，開發人員的回應是，這樣的工程相當浩大，目前有更重要的事情是讓 vm 內 USB 3.0 的速度不要插實體的太多。聽起來是有點道理，但，我的大計不就報銷了 Orz。

不過幸好請教G大神後，找到很多人教你怎麼讓  VirtualBox 可以用 USB 開機，其中最多人教的做法是：利用 VirtualBox 的 command line 命令 VBoxManage internalcommands createrawvmdk -filename c:\usb.vmdk -rawdisk \\.\PhysicalDrive# 產生一個 raw disk，然後將這個 raw disk 加到 virtualbox 的 vm 內。記得這個 disk 看起來像 hard disk，所以一定要跟原來 vm 內的 hard disk 在同一個 storage controller 內 (一般來說是 SATA)。而且這個 disk 一定要是編號最小的一個，可以將原來硬碟的編號改大，再將 usb.vmdk 改到最小。


這樣就可以開機了。但是，我照做之後，得到的畫面是



看起來結果跟 VMWare 差不多(Clonezilla 也是可以)。後來猜想應該是  file system 的問題，所以費了九牛二虎之力 (中間的故事也很黯然銷魂，不過就不贅述了)，終於讓我可以從  USB 開機了，所以 VirtualBox 的 bios 看來無法支援 NTFS 的 USB 開機，不過高興只有一下下，就又被塞了這個訊息



幸好 G 大神根據錯誤訊息給了一個指引：Virtual Machine USB Boot。
下載，免安裝，一切 OK，真是太完美了。Virtual Machine USB Boot + Virtual Box 看來將會是我最近的好幫手。

2/22 與 2/23 兩天去參加了一個外訓課程 - Advance Scrum Master。這個課程主要是給擔任過 scrum master 的人，想要提升自己的能力，或者組織要跑跨團隊產品的 scrum 的人聽得。我雖然沒有擔任過 scrum master，不過後面的那的目的，倒是即將在我們的單位內發生，因為我們在 Q2 開始，有一個專案會加入新的團隊成員，所以該專案的總人數已經超過一個 scrum team 的建議範圍，因此我們有必要開始注意跨團隊開發同一個產品的作法該怎麼進行。我在這裡借用一些篇幅，紀錄一下課程的收穫。


2007 年左右 Nokia 進行了一個 500 人左右的大型 scrum pilot，這就是後來 LeSS 的主要參考專案。跨團隊跑 scrum 有兩個主要門派，一個就是剛剛說的 LeSS，另外一個就是 SAFe。LeSS 叫做 Large Scaled Scrum，SAFe 則是 Scaled Agile Framework。比較上來說
LeSS 真的是比較 Less，而 SAFe 則是比較 Safe。聽起來好像甚麼都沒說對吧! 所謂比較 Less 是指在架構上，Less 跟跑一個團隊的 scrum 類似，幾乎不需要增加甚麼新的角色與流程，所以他的 Less 可以說是與 SAFe 的比較。而 SAFe 雖然增加了新的角色、流程、協作，但是這些新增的東西反而跟傳統開發模式比較容易接軌，例如 Architect 與 PMO 這些傳統瀑布下的角色在 SAFe 下反而會存活下來，所以他 Safe 的地方是對於一個跑慣傳統流程的公司來說，反而衝擊比較小。反過來說 LeSS 就會對傳統流程的公司是屬於破壞性的改變，所以才會說 SAFe 比較 Safe。但是 LeSS 的做法也會遇到比較難適應更大型的團隊，所以 LeSS 還有一個叫 LeSS Huge 的架構，基本上就是讓一定程度的人數組成一個 Requirement Area，這個 Requirement Area 相當於 LeSS，只是 Requirement Area 的 area product backlog 組起來還不能稱為產品，只是產品的一部分，所以會增加一個管理 Requirement Area 的架構。但那個管理架構本身也跟 scrum 類似，所以所有的設計理念都圍繞在scrum 本身。



LeSS 的做法，其實就是讓 PO 與 scrum master 可以管理多個 team，除此之外，所以的作為都跟原來的 scrum 一樣，除了在 planning 時有分上下半場，上半場由 PO 講解這個 sprint 的功能，並由各 team 領取 story，下半場則是各個 team 進行 story 的討論與切分，跟點數的評估。



而 SAFe 的做法是引進一個新的概念叫 Agile Release Train。Release
可以看成是由幾個 sprint 所組成，例如 5 個 sprint 加上一個整合的 sprint 組成一個 Release。所以各團隊的 sprint 可以不同步，但在 Release 前那個 sprint 要兜在一起。這個 Release 有個專有名詞叫 Program Incremental (PI)，而那個整合的 sprint 則叫做 Hardening Innovation Planning (HIP)，這個原來是進行整合並且 plan 下一個 PI 的機會，Hardening 有淬鍊的意思，不過後來因為大家覺得用 Hardening 似乎有鼓勵大家到這個 sprint 才進行整合，所以就把 Hardening 拿掉，稱為 IP 了。SAFe 成三層，最底下是 TEAM，也就是原來的 scrum team，只是多了剛剛說的 IP sprint，另外因為每個 team 看到的不是整的 product，所以稱 backlog 為 team backlog。第二層叫 Program 層，就是在這層定義 PI，這層的人稱呼也不同，原來的 PO 叫做 Business Owner，另位會有 Product Management 將 BO 整合在一起。最上層叫做 Portfolio，Architect 就放在這一層，也有 Epic Owner 負責大項目功能的定義，這一層會跟原來公司管理層銜接，所以會有 Budget、Stretagy 等在內。看完是不是覺得 SAFe 真的有點複雜! 我們在公司內目前如果遇到跨兩個以上 team 時，應該會以 LeSS 為主要的實作方式。

起因

Diro 分享了一個影片


以下簡單記錄我看完的心得

內容簡介

Speaker 是 Brian Lonsdorf (CTO of Loop/Recur, 多麼 geek 的公司名 XD)
LinkedIn: https://www.linkedin.com/in/drboolean
GitHub: https://github.com/DrBoolean

整個影片的重點在說明 Underscore 這個 library 雖然宣稱提供了一些有用的 functional programming helpers, 但是它的介面設計讓使用的人很難寫出真的 functional language 特性的 codes

Currying

以下他用幾個例子來說明 Underscore 的問題
要看以下他舉的例子前, 先說明一個東西 - Currying
假設你有一個 function 叫 add

var add = function(x, y) {
    return x + y;
}

假設你希望可以這樣寫

var add2 = add(2); // return: function()

add2(10); // return: 12
add2(5); // return: 7

那你就要修改一下你的 add 定義

var add = function(x) {
    return function(y) {
        return x + y;
    }
}

var add2 = add(2); // return: function(y) {...}

add2(10); // return: 12
add2(5); // return 7

有更 generic 的作法, 請參考 http://blog.rx836.tw/blog/javascript-currying/
作者也有提到一個幫你把你的 function 轉成 curried function 的 library (wu.js)
所以假設這樣寫會把你的 function 轉成 curried function\

var add = function(x, y) {
    return x + y;
}.autoCurry();

舉幾個實際點的例子 (畢竟 add 有點沒感覺)

var modulo = function(divisor, dividend) {
    return dividend % divisor;
}.autoCurry();

modulo(3, 9); // return: 0

var isOdd = module(2);

isOdd(6); // return: 0
isOdd(7); // return: 1

var filter = function(f, xs) {
    return xs.filter(f);
}.autoCurry();

filter(isOdd, [1, 2, 3, 4, 5]); // return: [1, 3, 5]

var getTheOdds = filter(isOdd);

getTheOdds([1, 2, 3, 4, 5]); // return: [1, 3, 5]

講者提的範例

• 範例一

var firstTwoLetters = function(words) {
    return _.map(words, function(word) {
        return _.first(word, 2);
    });
};

firstTwoLetters(['jim', 'kate']); // return: ['ji', 'ka']

因為 Underscore 的參數順序是先 array 再 function
所以沒辦法寫得更好
他認為如果 Underscore 能把參數順序顛倒且 API 是 curried functions
就可以寫成這樣

// _.first(n, array) 參數顛倒
var firstTwoLetters = function(words) {
    return _.map(words, _.first(2));
};

// 更進一步, _.map(f, array) 參數顛倒
var firstTwo = _.map(_.first(2));

filterTwo(['jim', 'kate']);

• 範例二

var sortedPhones = function(users) {
    return _.chain(users)
            .sortBy(function(user) { return user.signup_date; })
            .map(function(user) { return user.phone; })
            .value();
};

sortedPhones(users);

他將其改寫為

var sortedPhones = _.compose(
                    _.map(function(user){ return user.phone; }),
                    _.sortBy(function(useR){ return user.signup_date}));

sortedPhones(users);

更進一步

var dot = function(prop, obj) {
    return obj[prop];
}.autoCurry();

var sortedPhones = _.compose(_.map(dot('phone')),
                            _.sortBy(dot('signup_date')));

sortedPhones(users);

結論

我個人認為, 看完這個影片比看 Functional Javascript 這本書還更能感受 functional language 的特性 XD
不過我也還不是很懂, 大家就一起學習吧

https://blog.qt.io/blog/2013/04/15/evolution-of-the-qml-engine-part-1/
這一系列 QML engine 的文章(其實目前也只有一篇....)深入探討了 QML engine 的內部運作機制。Lars Knoll 指出了目前 QML engine 比較大的問題包括：

1. Several object models
1. 也就是一個 QML item 必需有3個object models，分別存在於 V8 engine, QML engine, Native Qt (以QObject 形式存在)，不但耗費很多記憶體，要 sync 三個物件的值也是一大工程
2. Bindings done through JS closures
1. 每個 property binding 都是一個 JS closure，因此要先重新把 binding expression 重組成 JS closure，然後 V8 再 parsing 一次這個 closure。很慢，因此提出了一個輕量、快速的 V4 engine 來幫忙處理簡單的 expression（這也是為什麼官方的 performance tuning 文件叫你要盡量簡單化 binding expression）。
3. Data type conversions
1. Qt 跟 V8 之間的 data type 轉換很花時間，此外如果是 string 的話，memory copy 的成本也不低。當然，有些改善方法，但那就是拿記憶體或程式複雜度換來的了 
4. QML scoping rules
1. QML element 實際上是樹狀結構，跟傳統的 JS engine 其實不大一樣，QML engine 用了很複雜的方法來處理這段(through nesting slow and deprecated with() statements)。
5. Throwing away QML type info
1. type info 會被丟棄..
6. iOS and WinRT support
1. V8要求系統記憶體可以被設定成 executable，但這在iOS及WinRT是做不到的...所以只能另外做一套 JS engine 了..
7. Working with upstream V8
1. Qt 裡面的 V8 跟標準版的 V8 程式碼已經差很多了..而且好像很難 merge 了...

其中第2.點提到了 V4 engine，但是它在 5.4 的時侯，因為手誤，所以預設是沒有開啟 JIT 的(https://bugreports.qt.io/browse/QTBUG-43171)，因此效能會比較差，請趕快換到 5.4.1 之後的版本吧 :)

在 Scrum Team 中很強調 透明(transparency)，這次跟大家分享的是 Developer Resource 透明化帶來的好處。

傳統團隊

在傳統的開發方法上，常常都是以”月”、”季”為時間單位，因此常會聽到 PM 說：可不可以再加這個 X 功能、這個 Y 功能，還有那個 Z 也順便加進來好了，這一季完成這些，應該沒問題吧？
身為 developer 能拒絕他嗎？有點難，因為感覺一季的時間應該可以做蠻多事情的，就算你覺得不可以，PM也很容易這樣感覺：一季耶，三個月你竟然沒辦法幫我多做 X+Y+Z?
在 Developer Resource 不透明的的狀況下，還真的很難回答。而不透明的原因，其實是因為週期太長、功能多且不明確，倒不是因為什麼溝通或互信的關係。

敏捷團隊

但在敏捷團隊中，我們在每個 Sprint Planning Meeting 時，便會先算出這個 sprint 有多少資源可以用：6(hours) * 6(developer) * 8(days) = 288 points

接著在 Story 介紹、Story Point 估算、決定 priority 等等活動之後，便開始討論 PO 這次最後決定的 stories：A,B,C,D,E,F，把這 6 個 stories 再細拆分成各個 tasks，例如 Story A 可能會被拆分成下列 tasks：

1. QML：這個功能有 UI 介面，需要實作 QML
2. C++：實際功能由 C++ 完成
3. Unit Test：要對 C++ 實作單元測試
4. UAT：要完成自動化驗收測試
5. Code Review：這次的 C++ 還蠻難的，雖然有 Unit Test，但還是要進行 Code Review

然後，接下來團隊成員根據每一項 tasks 開始打牌，決定每一項的 tasks 所需的時間。這裡是關鍵，因為要由這過程去弄清楚 PO 真正想要的東西，也讓 PO 了解這個 task 為什麼需要這些時間來開發。

以 C++ 這項 task 來看，如果一開始大家出的點數差異有點大，例如：3,3,3,5,20,3,5，便要請出3及20的成員們分別說明一下他認為是3及20的原因。
張飛(RD)：我覺得這個 雙向語音 很簡單，用原本單向語音模組來改就可以了！
關羽(RD)：可是他不是全雙工嗎？這樣我們要改很多地方才能做全雙工..
劉備(PO)：耶，不用考慮全雙工，我們這個應用基本上只要雙工就可以了！
關羽(RD)：原來如此，是我想太多了..

在一番討論後，大家才能真正清楚 PO 想要的東西，而不會多做或少做，或著方向不對。此時再出一次牌，通常就能取得共識了。
在經過撲克牌大賽後，可以得到每個 tasks 需要的時間：QML 5, C++ 20, Unit Test 20, UAT 20, Code Review 8，合計73小時。
剩餘的 Story B ~ Story F 也是照一樣的方式去得到需要的時間，可能是 B:80, C:100, D:64, E:38, F:48，這樣 PO 就很清楚，在這個 sprint 有限的資源內(288)，可以去完成那幾個 stories(D應該做不完，E跟F就不要想了...除非運氣很好。

在 PO 很清楚知道資源有限的狀況下，他就必需去做抉擇。如果現在只有 1 個 sprint 的時間，你沒辦法 A~F 全做，你要考慮清楚最重要、對客戶最有價值的到底是那幾個!全做當然最好，但資源攤在你眼前，很清楚的告訴你：不可能！

所以我覺得透明性的帶來的好處，除了明確了解需求外，也可以讓 PO 理解資源有限，他必需非常認真的選擇他要的功能!


註1:我們認為每位 developer 一天當中完全專注在工作上的時間是六小時左右，扣掉上廁所、休息、上網，工作轉換的overhead等）。
註2:一個 sprint 為二週，扣掉第一天的 Planning Meeting 及最後一天的 Review ＆ Retrospective meeting，剩下8天。
註3:估算的過程重點在”溝通”，實際上的時間可能還是會不一樣。

早在我加入目前公司的第二年，大概是 2004 年左右，我就拿到一本同事給我的 Extreme Programming 的書籍。在書上第一次看到 TDD，看書上寫的，TDD 看來是相當美好的。所以當年曾經想要進行嘗試，不過當然最後是失敗了。失敗的原因是 - "那有時間這麼搞，快寫 code 吧"

四年前，有一段時間致力於將內部使用的一個模組改寫成 C++，那時候還是想要再嘗試一遍 TDD，不過寫了兩天，就又放棄了。這次並不是因為時間壓力，而是寫起來很彆扭，又急著想要看到結果，所以寫著寫著，TD 就不見了，只剩下最後那個 D。這個專案後來我還是加了不少測試，但是因為不是邊寫邊開發，有些測試變得相當困難，所以測試 coverage 也不高。

這次之後，我幾乎對 TDD 已經死心，半年前看到 Uncle Bob 為 Kenbeck 的實作模式一書所寫的序，對於書中 TDD 的描述，讓我又再次讚嘆不已，但我認為那是大師才做得到的境界，凡人不可能達到。所以看過，也就放掉了。

前幾天，利用坐高鐵下南部的來回時間，將 Uncle Bob 的 Clean coder 翻了一遍，我終於知道，為什麼我 TDD 總做不來。其實就像一個連轎車都不會開的人，想要開飛機就會很困難，因為你不夠熟練。在 Clean coder 的第六章，Uncle Bob 寫到他每天都要花一些時間進行程式寫作的練習。而且將這種練習比喻成彈鋼琴或者運動選手的每日基礎練習，頓時讓我豁然開朗：TDD 是一個寫程式的方式，如果沒有經過練習，就開始應用在中大型的專案，當然很難會成功。就像一個鋼琴選手，每天不練習，就直接上台參加蕭邦鋼琴大賽，結果應該不難想像。

所以從現在開始，想了解新的語言或寫程式的方式，不要只是念書，該練習。如果你只想要練習 TDD，又不想花一大把時間去架設環境，安裝軟體，可以試試 cyber dojo。只要有 web browser 就可以做練習，還支援一大票 language 喔。