Spirit的異想世界

　　老媽真的很喜歡花，一聽到有花展，馬上就說要去看，今天看到的蘭花還真是漂亮。回程幫老媽辦了一張悠遊卡，她說：就算我跟我弟沒空，她也可以自己搭捷運到處走走，這是好事，不然整天待在家也很無聊。

OS：SkyDrive的相簿功能超級爛...

　　今天把圖都貼上去了，當初設計圖片時，每個Block是24 * 24，但第一次顯示時，Android竟然自作聰明把圖顯示成36 * 36，找了一下原因，似乎跟Android裝置現在有多種螢幕尺寸有關，所以把圖片從res/drawable資料夾移到res/drawable-hdpi資料夾就沒事了，意思是這些圖片是專門為高解析度設計的，不需要做縮放的動作，不過24 * 24實際看起來真的有點小，所以後來又重新設計了一次圖片，改成40 * 40，這次看起來就還不錯，剩下的是把搬運工(Android委屈你了，除了讓你安桌椅，還讓你搬箱子)的移動跟搬班箱子的動作加進去，以及判斷是否過關的程式加入，就算完成了。

　　有廣告有差喔！以前寫技術類文章根本沒人要看，沒想到經學長的廣告，技術類文章竟然變成痞客邦本日熱門文章，而且單日超過200人閱讀，well，希望大家會喜歡，如果文章有錯也歡迎告知。

　　這又是一篇源自於學長在其『搞笑談軟工』部落格上的關於Design for testability問題，同樣這也引起網友的討論，但總覺得偏向於『對測試程式的修改』或是『使用第三方套件存取私有變數』，而不是修改程式讓程式變好測(Design for testability)，所以就野人獻曝，提供一個我覺得比較合適的解法。問題中的WidgetFactoryV2類別同時肩負了Simple Factory和Singleton的責任，前者負責針對Windows平台和Motif平台提供不同的factory instance；後者則讓factory在一個JVM只有一個instance。這樣的設計會讓測試不好測試，就如同問題中提到的，但事實上，這問題和Singleton是無關的，更貼切地說應該是『如何測試由平台引起的Simple Factory』，所以我將WidgetFactoryV2改成如圖1的SimpleWidgetFactory，只負責平台相依的問題，Singleton不再是它的責任，此外，我也將『平台』的資訊從程式內部直接呼叫System.getProperty()的方式，換成從參數傳入，如此一來，針對SimpleWidgetFactory就變得很容易測，如圖2所示。

　　今天的內容源自於一個學長於Facebook上問的問題：『你的軟體即將於這個sprint結束之後就要準備送給測試部門進行測試，但是軟體還有幾十個open issues (bugs)還沒解完，而其中大部份的issues都只有某一位programmer可解。請問假設你是Scrum Master，你將如何處置？』這問題一出，引來許多人的討論，也有人開玩笑地說在解決完issue後要把那一位唯一能解的programmer開除，因為他程式寫得不好，所以別人才看不懂無法解決問題，真的是這樣嗎？有時候程式看不懂，並不是因為程式寫得不好，而是領域差太遠。如果整個專案都在同一個領域中，大家都是該領域的programmer，還出現這樣的情形，或許那位programmer真的要稍微檢討一下，但如果一個跨領域的專案，而且跨得很遠，如果沒有另外一個領域的知識，寫程式都很難寫了，更別說要解bug了。
　　另外，bugs明明是學長放在括號內的補充說明，大家似乎都把open issues跟bugs畫上等號，但有時候open issues不見得是bugs，例如有一個車牌辨識的模組，由團隊中唯一一個影像處理專才A開發，大多數的情況下都能辨識出車牌號碼，但前一個sprint結束後，QA實測後發現當在黃昏接近晚上時，辨識率就很差，甚至比晚上還差，因此QA列出一個issue希望能夠改善辨識率，這是一個issue但不是bug (目前沒有100%辨識率的影像處理技術)，問題來了，車牌辨識的過程中，有許多參數可以調整，調整了x參數可能可以提高黃昏時的辨識率，但也降低了白天的辨識率，或者是這個演算法本身就是有在白天到夜晚這之間昏暗不明時辨識率下降的問題，但其他時間辨識率很高，要解決這個issue，沒有影像處理相關知識，短時間內要解決基本上不可能，最後還是交給A來處理。
　　雖然大多數Scrum的書都說，當一個Scrum team要組成時，成員的能力必須涵蓋開發整個專案所需要的各種知識，現實狀況中，如果專案沒有跨很大的領域，這可能容易達成，例如幫銀行開發某個行銷活動的配合系統，那大概就是由具database / network / security能力的programmers，加上有處理過金融系統經驗的programmer，這樣的團隊就組成了。不過話說回來，會用database的programmer好找，懂得最佳化database的programmer就不見得好找；直接用network API寫程式的programmer好找，會設計protocol或實作protocol的programmer難找，當網路出現異常，能排除網路問題的programmer也不好找；會用加解密API寫程式的programmer好找，但對流程是否安全、金鑰是否安全等問題清楚的programmer就不見得好找，於是，在公司經費有限或是徵才不順的情況下，可能出現一個團隊裡都是只會用API的programmer，外加一個經驗老到的天才programmer (同時具備上述三種技能的最高等級)，如此一來，即使不定期的由經驗老到的programmer和其他人pair programming，當發生問題時，可能還是由經驗老到的programmer處理。

　　自上次在電影院看完動畫後，一直想找個時間來看原畫展，但由於始終沒有找到人一同前往，只好在展覽快結束前，一個人來看展覽。本來以為今天是非假日，人應該會少一點吧！但買完票進場後就發現我錯了，人還是蠻多的，而且大家都看得很仔細，所以大家都走得很慢，不知道是因為這電影主題的關係，還是小學已經開學了？少了頑皮小孩的嬉鬧聲，這真的是值得高興的事。

　　展出的內容真的很棒，原稿上彩筆的筆觸，跟電影上看到的完全不同，從沒有色彩的線條草稿，就可以看得出細膩的地方，而且光是主角的神韻到外型，就有好幾個版本，可以看出其中的改變，真的是很有趣，上色後，就更看得出上色的細膩筆觸，而且連續看了幾張後，他們的腦中好像有個3D立體模型式的，幾個重要場景的細節、位置和相對關係，通通都沒有錯。

　　其實我是來當間諜的，ㄟ...開玩笑的，免得人家把我當成拒絕往來戶，以後不能參加產品發表會，不過確實是因為實驗室最近的研究跟雲端儲存有點關係，想來看看他們賣什麼葫蘆。之前有注意過Synology的產品，覺得他們公司的ID做得還不錯，至少產品外觀比很多廠商的要簡潔清爽許多，官方網站也做得不錯(蠻有apple.com的味道)，不過身為窮學生一個，買iPhone都存了好久才下手，所以也遲遲沒買他們家的產品，只能說可惜今晚DS212j沒抽中我。以一個硬體廠來說，肯為軟體(Disk Station Manager)辦發表會我覺得是好事一件，也看的出來他們確實花不少心思在軟體上，UI的改善幅度頗大(從網站上可以找到過去版本的圖片)，有看我部落格的都知道，對於硬體廠的軟體開發抱怨頗久的我來說，我覺得Synology似乎是頗有『軟』味的公司。

　　在國際會議中心附近的麥當當吃完四盎司牛肉堡晚餐後，漫步走到會場，報到後，有位金髮的外國美女跟我說歡迎(別跟我要照片，我也沒有)，她應該是員工吧！在會場裡找個地方坐下後，發現人還不少耶，過沒多久，會場幾乎坐滿人了，七點開場，發表會分為上半場和下半場，就主題來說，我對上半場比較有興趣，應該說對『私有雲』比較有興趣，所以接下來只會提到私有雲(其實這樣蠻吃虧的，畢竟我也想用這篇文章去參加Synology的貼文抽獎活動)。

　　說道尺寸，每個人的喜好都不太一樣，有人喜歡粗一點，有人喜歡長一點，也有人喜歡瘦一點，當然也有人喜歡大一點，但如果是虛擬機器的硬碟映像檔(Virtual Disk Image)，我想大概沒有人喜歡它無限制大下去，特別是要傳送映像檔給另外一個人的時候，不管用網路傳，還是用隨身碟傳，都要傳上好一陣子，小一點3、4 GB，大一點1x GB，有時候隨身碟不夠大還塞不下去。

圖1 肥胖的映像檔(4.43 GB)
　　但真的映像檔都需要這麼大嗎？其實不盡然，有時候那個檔案只是虛胖或水腫而已，只要稍微用點方法還是榨得出油來。在Guest系統內，實際使用的硬碟大小其實都比映像檔小，比較圖1和圖2可以發現(這裡以VMWare為例)，有部分空間被吃掉了。

　　最近在幫老師弄下周三要去X策會上課的教材，上課的內容是單元測試、整合測試、Mock object等，我準備的教材裡都要涵蓋這些東西，為了盡可能達到100%的statement coverage和branch coverage，所以，只要有>、>=、=、<和<=等二元符號，測試案例都要考慮到boundary test，最後，因無法在測試案例裡製造發生IOException的case，導致某些catch block測不到外，教材裡model的程式碼都測到了，這樣弄下來還蠻累的。
　　沒想到回家的路上，就出現了某位總統候選人的輔選志工在測驗我的boundary，到底是怎麼回事呢？從府中站的電扶梯要出去捷運站回家時，門口站著一大票志工，沒看到候選人本人(在攝影棚準備政見發表會)，平時下班時間就很多人的捷運站出口這時又更擠了，我往我的左邊看去，電扶梯旁明明還寫著：｢捷運站區域內禁止競選活動｣，不知道那些志工們有沒有看到那個標語，還是說他們認為門口不算是捷運站區域內呢？他們心中那條切割捷運站區域內或外的boundary在哪裡？
　　或許有人覺得我雞蛋裡挑骨頭，那我再說另外一件事吧！幾天前又是一個下雨的早上，無法騎腳踏車的我，又走到捷運站搭車，在還沒到捷運站前的板橋農會門口前，也是一位跟剛剛那位總統候選人同黨的立委候選人，親自站在那裡拜票，板橋農會和捷運站門口隔著一條馬路，說近很近，但在我的眼中，她不是在捷運站區域內從事競選活動，至少她不會妨礙到要進出捷運站的人，那麼冷的天氣，要在哪裡站上好幾個鐘頭，跟沿路經過的民眾拜託，我還蠻佩服她的。
　　隔著一條馬路，我覺得那些志工是在游走規定(法律？印象中，在捷運站區域內從事競選活動有罰款)邊緣。如果法律是那些搞政治的人弄出來的，那我更不接受政治人物自己在游走法律邊緣。離投票日沒剩下幾天了，說真的，我還沒決定要投給誰，不過，今天的事件，也許可以當作一個參考。

　　之前在寫Comic Surfer的時候，都是想到什麼就寫什麼，沒什麼組織，所以常常某功能A寫到一半就被放著，然後又跑去寫另外一個功能B，當程式碼還不多的時候，事後補齊倒還容易，之後應該就沒辦法這樣了，所以之後會一次只專注在一個小功能上，參考國外都喜歡替開發中的project命名(例如Eclipse的Ganymede、Helios及Indigo等，或是Android的Cupcake、Donut及Ice Cream Sandwich等)，每個小功能都會是一個小project，然後有一個code name，個人英文字彙沒多到可以自由發想，因此code name都是電影名稱，接下來近期的五個projects如下(刪除線表示已完成)：
　　1. The bodyguard《終極保鑣》(1992)：補足所有的單元測試及整合測試。之前在寫功能時，並沒有寫太多的單元測試，倒不是因為時間不夠(沒有deadline，怎麼會時間不夠XD)，主要是Comic Surfer牽扯到的大多是檔案處理，單元測試要寫好的話，準備資料比較討厭一點，也就一直不太想碰，但既然要繼續開發下去，還是先把單元測試給補足，因為修改時一但有bug，單元測試這個『終極保鑣』應該會告知有錯了，之後改程式也比較心安。