Spirit的異想世界

　　印象中我應該是個電視小孩，雖然到念幼稚園之前有保母照顧，到小學三年級之前有外婆照顧，直到母親辭掉在公所的工作後當家管，我放學回家才是由母親照顧，這段期間，寫完作業就是看電視，特別是卡通和影集，但說也奇怪，對於變形金剛的印象卻是民視開台時引進的那個版本，相較變形金剛，我小時候最愛的卡通是最近剛過誕生前100年周年的藍色貓《多啦A夢》(其實小叮噹也很順口啊)，還會去錄影帶出租店租回來看，看了這麼多卡通卻沒記得幾部XD，倒是影集還蠻多印象的，像是《百戰天龍》、《虎膽妙算》、《天龍特攻隊》、《銀河飛龍》、《飛狼》、《超人》、《閃電俠》...
　　回歸正傳，沒想到變形金剛從1974年就開始了。

　　但我目前印象最深的版本其實是電影中的版本。所以照片也大多是拍知道的角色，像是柯博文、大黃蜂、密卡登等等，下面這張是真實比例大小的大黃蜂，挺酷的。

　　自從有了AJAX技術開始，越來越多網站都使用AJAX技術開發，好像沒用Asynchronous (或是event-driven)的方式寫程式就很落伍了，就連最新的WinRT API都加了一大堆Asynchronous API，但我常常看到一堆網站，在點下某個按鈕後，整個畫面變成灰色的，然後有個輪子轉啊轉的，轉個半天什麼事也不能做，這其實跟傳統的Synchronous網頁沒什麼差別啊！只差在有個輪子轉啊轉，讓使用者誤以為server還在(其實早就死了)，比較好的方式應該是只Block需要同步的部分，不需要同步的部分應該還是要讓使用者操作吧！GMail在load信件時會把整個頁面block住嗎？不會吧！不然不就失去Asynchronous的好處了嗎？
　　自己寫程式倒是很少用Asynchronous方式開發程式，主要的原因跟這篇學長的文章相似：難測！Comic Surfer一直到2.0才有會轉動的輪子，不過，我的設計只封鎖Navigation的事件，其餘動作功能依然能夠使用，ㄟ...這不是重點，有點離題了，2.0核心沒有加任何Asynchronous method，但多了multi-thread，搭配polling的UI，所有會耗比較多時間的動作(載入大張圖片)和要平行處理的事情(快取其他頁面)都是用獨立的thread處理，這些功能原本都是Synchronous method，所以測試上就和傳統的測試一樣：呼叫method，當程式return檢查結果和物件狀態。至於不同thread之間怎麼同步，例如什麼時候該轉圈圈？什麼時候要把畫面上的圈圈拿掉？看情況，有時候用lock，有時候就跟Swing的event dispatch thread機制一樣，送event給等待的thread。
　　其實Synchronous和Asynchronous之間的差異沒有像一個是天和一個是地那麼大，把Synchronous method丟到一個獨立的thread執行加上call back method就可以包裝成Asynchronous method，Asynchronous method加上一個busy waiting lock、time out和exception機制就可以包裝成一個在失敗時(time out)會拋出例外的Synchronous method，開發程式時，我個人還是喜歡先寫Synchronous版本，真的有必要，才用thread轉成Asynchronous方式，畢竟測試時，還是Synchronous比較好測！

　　2013年上班第一天，老實說狀態完全狀況外，早上同事轉過來問我今天有要Stand up meeting嗎？我說：『上次不是說禮拜三再開』，同事點點頭轉回去，不到30秒後又轉過來說：『對啊！今天是禮拜三』，我臉上冒出三條線，哈~完全忘記今天是禮拜幾了(怎麼不是忘記今天要上班)，後來也沒開Stand up meeting，打開瀏覽器進到XPlanner (一種紀錄iteration、story和task的open source軟體)，開始規劃這個iteration的task，不用懷疑，這個project不是run scrum，接著打開JIRA (一種issue tracking的軟體)，把assign給我的issue都塞到XPlanner，然後開始寫code，不過效率不高就是了。
　　一邊解issue一邊想起禮拜天回學校跟老師改journal paper時，老師問起工作如何？我說了一句：『工作是工作』，後來又跟先前原本想去的公司主管聊了一下下，那位主管最後的結語是『我也不做沒趣味的東西』，之前有一篇關於選擇工作的文章，引起蠻多人點閱的，但現在回頭看那篇文章，在工作內容那一項中，我似乎少列了一點，就是工作內容或是開發的產品是否有趣，有時候我真的想問在當工程師的朋友：『你現在開發的東西你覺得好玩嗎？』，所以下次找工作，一點要把這一點列進去(這是在暗示我想跳槽了嗎？)

　　因為老媽說從沒去101現場看過煙火，所以已經有兩三年沒去現場的我，今年跟老弟帶老媽去101看煙火，9點多到市府捷運站，帶老媽四處逛逛，像是某個很有名的貴婦百貨、新光和101。在11點左右到Att旁的馬路上找好位置，等待煙火開始，今年煙火很漂亮，可能是沒什麼煙，感覺顏色特別鮮豔，而且樣式也活潑許多，真意外這樣的煙火秀竟然找不到台灣的廠商願意贊助？說真格的，在這四、五個小時的東區跨年夜中，除了煙火外，印象深刻的是一個很讓我討厭的品牌，因為到處都有該廠商的活動攤位，不論是電視體驗區、手機/平板體驗區或是巨幅廣告，幾乎每個百貨的主要出入口附近都可以看到這家廠商的影子(和Show girl)，之前某個公司的董事長曾說：『我們的產品是很優秀的，只是行銷做得不夠好...(以下廢言省略)』，是啊！但在一個有數十萬人聚集的機會，我卻沒看到這家公司的任何搭配應景的活動，當然也沒看到其他台灣的廠商有什麼樣的活動，倒是Att百貨的派對好像吸引了不少男女，看到長長的排隊人龍，跨完年後可能有很多人在等著檢屍體吧。行銷除了花錢，還要花對地方，這讓我想起一個超經典的廣告，這部廣告花了很多錢，但只在1984年的超級盃第三節的廣告時間播過僅此一次，卻成為了經典。我不是廣告人，但101煙火結束後打上台灣的廠商名稱，透過轉播這畫面出現在其他國家的新聞報導時，我想效益會很大。又或者是在那歡樂的氣氛哩，跟附近的百貨業者合作推出活動，讓更多人體驗產品，那也是很好的行銷。希望2013年的台灣廠商能多加油！

　　標題是今天到公司後，接近中午休息時間時突然有感而發的po在社群網站上(還好自己的社群網站還沒有讓公司主管知道)，其實工作到現在快滿二個月，雖然沒有像另一個同事那麼熟(他已經寫web好幾年了)，但用的技術大概都了解(所以最近都被指派去處理一些比較複雜的功能，畢竟我的Title掛的是資深兩個字啊)。聽到架構師跟坐在我背後的另一位同事以有點興奮的感覺在聊XX Framework升到幾版，又ABC Library升到幾版，其實這些東西我一早到公司就看到架構師的mail，也更新了整個project，但老實說我無法感受為什麼他們會如此興奮？
　　還記得剛開始用Eclipse時，每隔一陣子就會去看一下Eclipse和Java官網，常常抓最新版下來玩，然後看看有什麼新技術，但技術玩久了，總覺得大同小異。最近幾年還是會注意和玩新東西，但是心裡想的不是新技術哪裡好玩，而是我應該用這些新技術來做什麼？所以開始寫一些小玩具，像是Comic Surfer，這些小玩具反而可以點燃內心的熱情，就像前天一整天，我可以在電腦前一直寫test cases，甚至code coverage還超過當初訂定的目標(超過60%了)，可是進到公司後，寫的東西比較像是在澆冷水，並不是東西沒有技術(其實還蠻瑣碎複雜的)，不過就是無法點燃樂情，總是想早點下班XD
　　昨天的實驗室大聚餐，從第2屆的畢業生到第12屆今年的碩一生，都有代表出席，很多學長已經都是主管了，其間聽到一些內幕八卦，看來即使想換工作，原先想去的公司情況越來越糟糕了，然後再問問其他公司的情況，用產品內容在點燃工程師熱情的公司不多，大多是靠『薪水』，我的薪水雖不滿意但已經比很多人要好了，但我想這大概也是為什麼我總覺得台灣的3C產品、相關廣告和文案，看不到讓我感動的一面，開發的人都沒有投入感情在裡面，只是當成一個要完成的功能而已，這時候也許該慶幸我開發的是內部系統，不是公司要拿出去賣的東西嗎？

　　工作已滿二個禮拜，雖說工作還算順利(應該吧XD)，但回到家依舊在看書充實過去沒接觸過的東西，沒太多餘的時間能拿來開發Comic Surfer。不過看書還是不錯的，像是最近在看的《Patterns of Enterprise Application Architecture》就非常的好(下圖)，解開我過去在思考如何改善ezCMS (Easy Conference Management System，實驗室開發的研討會管理系統)的許多問題，事實上，我很多的想法也在這書中得到證實，只是我當時不知道我的想法原來已經是一種pattern了。

　　在有限時間裡，還是打算抽出一絲絲的時間(看每天是否能抽出1小時)，把Comic Surfer 2.1的半成品變成完成品。由於2.1版支援外掛，所以自己也寫了一個外掛去讀取某知名漫畫網站上的漫畫，惡夢也就此開始，該網站程式似乎有固定的更新頻率(防止盜連？)，每次程式一更新，外掛程式也得一併更新，但也因為這樣發現了一個Comic Surfer目前的缺點：程式雖然不會因為例外而當掉(Crash)，而且能保持繼續運作，但卻沒有讓使用者知道發生什麼事了。再加上公司的What's New會議上，我想拿Comic Surfer當例子說明Domain model的設計(還不一定真的用這主題)，用更高的層次看自己的程式後(看書也幫助自己提升層次)，覺得某些物件的耦合(Coupling)還能再打掉，有助於單元測試的進行。所以2.1 M3的規劃如下：
　　1. 降低Core套件中，物件間的耦合：用Observer pattern拆散某些直接耦合的物件，變成間接耦合，提升測試的方便性(只需要製造Mock subject即可)。
　　2. 增加錯誤訊息的處理：目前程式的強健性(Robustness)還算是不錯，在例外拋出後大多能維持在可繼續運作的狀態，但在使用者體驗的部分要加強一下。
　　3. 提高測試涵蓋率到40%以上：過去測試涵蓋率曾經一度到45%，但Refactoring後，部分測試被移除掉，涵蓋率降到31%，希望在降底耦合後，把測試補回去，然後看有沒有機會將涵蓋率提升到40%以上。
　　4. Slideshow (幻燈片播放)：Java的全螢幕API我已經試玩過了，而且從J2SE 4就開始有支援(當然，此API和Android的全螢幕API不相容)，原則上會有幻燈片播放功能，但我還在考慮用視窗模式做幻燈片播放，還是用全螢幕做幻燈片播放？

　　今天主管一大早我連咖啡都還來不急泡，就找我討論接下來要做什麼，順便問了一下我對於現在這個系統的感覺如何？礙於保密協定，我沒辦法透露我參與的系統是什麼，暫且就以代號G表示好了，會找上我似乎跟昨天下午的高層會議有關，感覺得出來G系統的PM希望時程能夠再快一些，所以主管問我，目前這個系統的架構，有什麼方法能讓負責前台的人和負責後台的人合作更流暢一點？老實說，昨天算是到職滿一週，看了幾天的source code下來，這系統用了一個很複雜的架構，2-tier (presentation tier也就是所謂的前台及後台的domain tier)、tier裡又用layer，presentation tier用Struts 2做Web MVC，tier之間以RESTful的web service溝通，layer之間用Spring處理AOP和IoC (Dependency Injection)，最後domain tier用Hibernate做資料的persistence。所以我的第一個直覺是，架構師把當今熱門的Java技術都用上了，而且是蠻常見的技術組合，至於合不合適我不敢說，畢竟我看到的規格文件只是一部分而已，無法評估未來的擴充性是否需要這樣的架構，不過，我還是回饋了一些我的想法。
　　首先，我說這個架構還是有table-driven的影子，雖然不像用Microsoft的Visual Studio工具所開發的系統那樣：直接從前台到後台操作DB這麼誇張，但這個系統的domain model跟我想像中的domain model不太一樣，雖然有不少物件，但物件本身卻沒什麼行為，感覺比較像C裡面的struct，行為雖然也是用物件包起來，但整個感覺就像是一推的function物件操作資料物件。一提到這一點，主管就說公司裡目前也是兩派，一派就是Microsoft的.Net派或稱table-driven派，另一派也就是最近開始的domain-driven派，可能是經驗的關係吧，很多人還是不習慣domain-driven，所以聽主管說，有些工程師有點微微抱怨：以前用Servlet + JSP直接更新DB，雖然程式沒辦法reuse，但開發速度很快，現在光是前台後台整合就要花上不少時間做資料轉換，這跟我從source code看到的情況吻合，資料轉換的code還蠻多的，但我覺得如果是真的OO系統，有不少資料轉換應該是可以避免的。
　　再來是我覺得這個系統的架構也被框架(Framework)影響了，如果不熟悉某些annotation (JPA、Spring、Struts 2、lombok和Apache CXF的annotation非常多)，光看source code可能會完全看不懂系統是怎麼運作的(我也是一開始先問了Program Analyst整體大架構後才開始看程式碼，不然見樹不見林很耗時間)。甚至連IDE的啟動都要換載入器，否則只會看到一堆compile errors，雖然這些都可以說是開發環境設定的一部分，而且可以少寫很多行程式，算是目前Java蠻流行的作法。annotation是很方便，但我不喜歡這樣的程式碼，沒什麼可攜性，讀起來很不乾脆，而且domain model帶了很多跟domain無關的東西(用annotation騙自己說沒寫跟domain無關的程式嗎？)，假設domain model要reuse，除非上述那些library都要一併攜帶，否則根本不work，但如果我只是要reuse domain model做desktop工具，我攜帶Struts 2的library做什麼？只是為了讓compile能過？

　　邁入而立之年，所做的第一個重要決定就是自己的工作，雖然還在期待能有去美商台灣謀智(Mozilla)面試的機會，不過透過各式管道的嘗試，似乎沒有下文，在現在的景氣情況下，拿到兩個頗優的offer，還是得做出決定，畢竟其中一家公司已經等了近三個禮拜了。我想就稍微讓自己試著自問自答的方式來評估這兩家公司吧！說來也算是有緣吧！含先前研發替代役的求職，我一共投了六家公司，參加了其中四家公司的面試，這四家公司的英文名稱通通是G開頭的。 

　　噹！噹！Comic Surfer 2.1 M2終於完成了，和上一次大約兩個禮拜(2012/09/10~2012/09/22)就完成了M1的速度相比，這次只多了一個偏好設定的對話框，卻用了將近一個月的時間，開發速度上確實慢了許多。其中一個原因是最近在找工作，有時候面試就用了一整天，像是去汐止某家公司面試，光筆試(程式和多益模擬考)部分就耗去兩個多小時了，然後才跟主管(學長)面試，接著是和人資面談，這還不含來回通勤也用了兩個小時，雖然收穫很多(免費考了一次多益模擬考、得到許多業界資訊)，但一整天就沒了。

　　這次Comic Surfer 2.1 M2的重點真的只有上面那個對話框，如果用寫程式硬拚出上面的對話框，老實說不用一天我就搞定了，但這次花這麼久的時間，跟當初寫Comic Surfer的初衷有關，早在Comic Surfer之前，我正在開發一個叫Javs Sway的套件，當初會想開發這套件是因為過去參與蠻多專案的，包含自己的論文，常常在GUI上需要重複寫一些一樣的東西，於是想把之前寫的部分GUI Widgets整理成一個套件，之後就能重複利用了，開發到後期，發現少了一個可以Demo的Application，這才開啟了Comic Surfer的計畫(Comic Surfer從1.0開始就有一個jsway.jar的檔案，沒錯，那就是Java Sway套件)。

　　最近在修改Comic Surfer的Preferences模組，由於需要大量的字串(String)和各種形態(Integer, Double, Color, etc.)之間的轉換，寫著寫著，有個地方一直有問題，後來發現了一個有趣的地方，所以放了一段程式碼，裡面有10個問題，請猜猜看每題的Type應該是Integer還是Double？(點圖會放大，請別先偷看答案XD)
     

　　我不確定這是bug還是規格就是如此定義(Java執行環境：J2SE 7 Update 6)，不過如果用上if shortcut表示法，Java似乎只會使用其中一種Type表示冒號的左右兩側的物件，以例子的第九和第十題來看，以能表示範圍最大的Type為主，也就是Double，但如果是正常的if else就不會，所以如果你的程式對Type很敏感，還是盡量別用if shortcut表示法(雖然我蠻喜歡用的，省空間)。