睡到很晚的早上，在客廳邊吃早餐時邊看報紙(其實這不算是好習慣，聽說有礙消化)，雖然最近的報紙錯字率實在高得離譜(高到連自認中文不好的我都常常看到錯字[1])，不過還是趁吃早餐的時間看一下時事，本來大概只看體育版和國際版，偶而才會看政治版或社會版，今天就碰巧在政治版讓我翻到一篇標題讓我覺得頗有趣：『車牌同號要辦人 葉匡時：做錯事要懲處 誰敢創新』，這讓我想起之前看過的幾篇網路文章[2, 3, 4]，其實目前的公家機關早已經是『少做少錯，不做不錯』的文化，所以常被抱怨體制僵化(也不用笑公家機關，很多私人企業也是這樣的文化)，但卻也鮮少聽到有什麼建言，讓公家機關能從『少做少錯，不做不錯』的文化中解脫，倒是常常聽到動不動要人下台的砲火，如果下台能讓事情解決，那我舉雙手雙腳贊成，請那位官員早早下台，但已經有多少位官員下來了，事情還是一攤死水沒有解決啊？有問題確實要檢討，但在檢討任何問題時，先把焦點放在如何把問題解決，而不是誰該負責，誰該下台。
- Apr 13 Sat 2013 14:23
-
今天的報紙摘錄 (2013/4/13)
- Apr 11 Thu 2013 21:34
-
當好心變成強迫
昨天和公司的高層(含最高層，我是裡面最菜的)開會，因為目前專案的進度可以說是delay了非常非常之久，我進到這個專案時，這專案就已經是delay的狀態了(據說已經跑了快2年)，所以我要說明為什麼開發時程會這麼長的理由，以及剩下的功能能在什麼時候完成。說起來有趣，我會和目前公司結緣，是參加了北科ezScrum團隊每個月舉辦的C. C. Agile。進公司快半年，雖然PM認為團隊開始進入狀況，我也認為團隊氣氛變好，但我不敢說我貢獻了什麼？我只盡力保住由團隊成員估時程的機會，而不是上面說了一個時程然後就是那樣；再來就是讓團隊成員有更多機會學更多東西，試著讓整體的開發速度變快；在code review時，盡量提供意見及分享自己寫的程式。雖然我試著東加一些西加一些，但其餘的agile practice，我目前還幫不上忙，因為這不是一個agile team。
其實是不是agile team我並沒有這麼在意，因為我自己本身沒有任何流派(unified proecess、scrum或waterfall之類)的信仰，只是我印象中曾經看過一句話，scrum master應該是保護羊群的牧羊犬，我還在努力中。不過，下個禮拜五，我還是(很無奈地)得交出一份類似計畫書的東西，上面會有一個時程：剩下12個功能(長期目標)完成的時程，而且是根據某個公式算出來的(現在電腦不只會選土豆，還會算時程)，這讓我想起之前看過一篇吃蘋果的文章，如果開發軟體能像吃蘋果那樣，每個人速度都差不多(事實上也不可能一樣)，那或許我調整一下公式裡的參數，多留一點buffer，團隊就會很高興，但那對團隊的進步沒什麼幫助，我之所以想保住讓團隊估時程的機會，是希望當團隊進步後，不斷地修正短期目標的時程，當短期目標不斷地減少，離最後的目標也就不遠了(好啦~其實我是想偷偷把scrum塞進團隊裡)。
昨天的會議，直屬主管、架構師和處長都幫團隊近況說了不少好話，不過，有些決定還是定下來了，包含今天我宣導的一件事(暫且就稱作是A吧)，沒想到剛宣導完，就引起一點不小的抱怨(我自己也...)，但離開公司前，我還是做了A才回家(以身作則)。結果，晚上收信，看到一封過去某人做A做了一陣子覺得A很好的信，那封信就像是傳教士在宣導『信耶穌得永生』。我認為A不是壞事，但就跟讀書方法一樣，某個人B很會念書考試成績很好，但B的讀書方法不見得適用於另外一人C，也許可以好心讓C試試看B的讀書方法，但不該是強迫C用B的讀書方法，因為有時候反而會有反效果。事實上，我自己的讀書方法是自己求學過程中一路摸索出來的，如果真要說，我的讀書方法肯定不適合很多人，因為我幾乎上課都不太聽課(我連自己指導教授的課有時候都會打瞌睡了)，也不太作筆記，完全是依照自己的步調在念書。
其實是不是agile team我並沒有這麼在意，因為我自己本身沒有任何流派(unified proecess、scrum或waterfall之類)的信仰，只是我印象中曾經看過一句話，scrum master應該是保護羊群的牧羊犬，我還在努力中。不過，下個禮拜五，我還是(很無奈地)得交出一份類似計畫書的東西，上面會有一個時程：剩下12個功能(長期目標)完成的時程，而且是根據某個公式算出來的(現在電腦不只會選土豆，還會算時程)，這讓我想起之前看過一篇吃蘋果的文章，如果開發軟體能像吃蘋果那樣，每個人速度都差不多(事實上也不可能一樣)，那或許我調整一下公式裡的參數，多留一點buffer，團隊就會很高興，但那對團隊的進步沒什麼幫助，我之所以想保住讓團隊估時程的機會，是希望當團隊進步後，不斷地修正短期目標的時程，當短期目標不斷地減少，離最後的目標也就不遠了(好啦~其實我是想偷偷把scrum塞進團隊裡)。
昨天的會議，直屬主管、架構師和處長都幫團隊近況說了不少好話，不過，有些決定還是定下來了，包含今天我宣導的一件事(暫且就稱作是A吧)，沒想到剛宣導完，就引起一點不小的抱怨(我自己也...)，但離開公司前，我還是做了A才回家(以身作則)。結果，晚上收信，看到一封過去某人做A做了一陣子覺得A很好的信，那封信就像是傳教士在宣導『信耶穌得永生』。我認為A不是壞事，但就跟讀書方法一樣，某個人B很會念書考試成績很好，但B的讀書方法不見得適用於另外一人C，也許可以好心讓C試試看B的讀書方法，但不該是強迫C用B的讀書方法，因為有時候反而會有反效果。事實上，我自己的讀書方法是自己求學過程中一路摸索出來的，如果真要說，我的讀書方法肯定不適合很多人，因為我幾乎上課都不太聽課(我連自己指導教授的課有時候都會打瞌睡了)，也不太作筆記，完全是依照自己的步調在念書。
- Apr 07 Sun 2013 10:23
-
2013 京都五日遊番外篇 -- 心之谷(側耳傾聽) 千片拼圖完拼！
隨著時間和心境的變化，宮崎駿作品在心中的喜好排名總是有些變化，心之谷(側耳傾聽)的排名始終在喜好排名的前三名，所以當初在どんごいの森選拼圖時，猶豫好久，最後還是選了心之谷，預計在清明的連續假期挑個兩天把它給拼起來。4/4掃完墓累給半死，十點不到就乖乖上床睡覺了。4/5早上和書怡去看普立茲新聞攝影獎70年大展(很棒的展覽，有空再來寫感想)，晚上牛象三連戰首戰在五局因雨裁定比賽結束後，就把拼圖拿出來，這是第一次拼千片拼圖，上次拼拼圖早已忘記是什麼時候了，只記得一個晚上(到凌晨三點的樣子)一口氣把五百片拼完，現在已經不是適合搞一口氣做完什麼事的年紀了，但打開後心想(20:46)，這下子好了，看來今天晚上只能把周遭(邊邊)給拼完了，邊邊(40 + 25) * 2 - 4 = 126片找齊後(22:48)，幾乎全是白的...感覺就像是把拼圖全部翻到背面只靠形狀在拼，最後凌晨一點前終於把邊和字給拼完了，睡覺去(打哈欠)~
隔日(4/6)早上九點半開始動工，經過簡單的分類後，拼圖被分成幾群，單色區(土黃色的牆和下方的白色區塊)、主角區、門(窗)框、酒桶花盆、單車和木地板，顏色線條明顯的主角群很快就被拼起來(10:46)。
- Mar 30 Sat 2013 11:47
-
2013 京都五日遊照片集暨遊記目錄
我不確定有沒有空寫遊記，不過已經先把上千張照片放到Adobe Revel (Photoshop.com的下一版，至於為什麼不是放在痞客邦呢？因為光是前2天的照片就把我一個月的流量用完了Orz)，所以照片優先，把連結先貼出來，有空再來補遊記吧！
2013 Kyoto Travel Day 1 | 遊記
2013 Kyoto Travel Day 2 | 遊記
2013 Kyoto Travel Day 3 | 遊記
2013 Kyoto Travel Day 4 | 遊記
2013 Kyoto Travel Day 5 | 遊記
2013 京都五日遊番外篇 -- 心之谷(側耳傾聽) 千片拼圖完拼！
2013 Kyoto Travel Day 1 | 遊記
2013 Kyoto Travel Day 2 | 遊記
2013 Kyoto Travel Day 3 | 遊記
2013 Kyoto Travel Day 4 | 遊記
2013 Kyoto Travel Day 5 | 遊記
2013 京都五日遊番外篇 -- 心之谷(側耳傾聽) 千片拼圖完拼！
- Mar 24 Sun 2013 23:19
-
2013 京都五日遊 Day 5
終於來到京都五日遊的最後一天了，老實說看到韋宏還要繼續玩到四月初，就好想繼續留下來玩喔！早上鬧鐘是七點半響，但其實我和思賢蠻早就醒了，行李整理完後，準備check out，到四条車站，我和思賢得跟韋宏暫時道別，他要去接下來要住的民宿check in，然後再到伏見稻荷神社跟我們會合。
到京都車站後，先是去寄放行李，總不可能拖著行李到處走，不過這裡寄行李是按件計價，倒是讓我有點意外，因為我全部算起來是三件，頗傷的。
- Mar 23 Sat 2013 20:44
-
2013 京都五日遊 Day 4
據說今天的行程比較輕鬆點，所以睡比較晚，不過走在路上還是覺得我們起的算早了，今天早上的行程是悠哉地走到祉園。
(早上的錦市場，店家都還沒看，跟第一天晚上來時差很多，不過依舊相當乾淨)
(不過還是有相當早就開始營業的店鋪，像是魚店)
- Mar 22 Fri 2013 15:28
-
2013 京都五日遊 Day 3
- Mar 21 Thu 2013 12:25
-
2013 京都五日遊 Day 2
昨晚又是弄到12點才睡，睡覺之前大家討論要幾點起床，最後鬧鐘是設成比平常上班日還早的六點，不過鬧鐘還沒響就已經醒了，這似乎是我出國都會遇到的現象：自然而然地很早起，經過一番準備(三個人輪流用一間洗手間)，七點多搭上公車，準備前往東寺，京都很多景點不是寺(佛教)就是神社(傳統日本宗教)，但因為都是有悠久的歷史，而且跟日本人的生活結合在一起，就連在動漫裡都會常看到，至於東寺與京都文化的關係，請自行點連結啦XD。今天去的早市(弘法市集)可是每個月才一次的市集，既然有機會去，當然就不會放過啦。
公車一日券可以先買起來，不限當日搭乘，只需要在第一次搭乘時刷，刷完後就會在車票上留下搭車日期，之後當日只需要出示票卡的背面給司機看即可。
- Mar 20 Wed 2013 10:02
-
2013 京都五日遊 Day 1
畢業後沒多久就找到工作，也沒給自己一些時間放鬆放鬆，這次趁著大家都有雅興要去日本走走，就安排了五天的京都行(還是菜鳥所以只請了三天假)。這次要感謝思賢跟韋宏，行程都是他們安排的，我就像是跟團的，只出一個人。昨天下班後整理行李到快一點，早上天還沒亮四點多就出發準備前往板橋客運站，說累是有一點，但要去旅行的興奮度也很高，所以也沒什麼睡，在路上先與思賢會合，六點多就到機場，老實說，我一直覺得2個小時前到機場是一件很沒意義的事，特別是台灣的機場很無聊，沒什麼好逛的。
和韋宏在機場會合後，就各自到登機門等待登機，沒錯，因為有累積里程，韋宏搭的是比我們早5分鐘的長榮，我們是華航，下次會合就是關西機場了。
- Feb 01 Fri 2013 21:21
-
Monday
嗯，今天不是Monday，但早上輕快的鬧鐘聲響起(《借物少女艾莉緹》中斯皮勒的主題曲)，趕緊起身把鬧鐘關掉，突然有種這場景(按掉鬧鐘準備上班)好像已經出現好幾次，不斷重複的感覺，就好像穆德在《X File》第七季的《Monday》中，不斷地從有破洞的水床中起床，處理一堆鳥事，結果在負責銀行搶案時被炸死，不知重複幾次後才找到離開這循環的關鍵點。不知道哪天，我也會遇到有人問：你想要吃下紅色藥丸還是藍色藥丸？
- Jan 09 Wed 2013 21:42
-
規格
今天中午把其中一個功能給完成了，那個功能當初用IBM的公式計算需要24人時的時間，差不多就是三天多到四天(人一天工作是不可能滿8小時的)，不過我自己的time log顯示，2天搞定了，主要是因為這功能在我比較不熟的前台只有查詢，沒有任何編輯的動作，相對簡單很多，而本來就比較熟悉的後台在前開發一個功能時，留了很多可以重複使用的東西，所以省下一些時間可以拿來準備課程的投影片。下午開始忙下一個功能，老實說這個功能是我估算最麻煩的一個，因為它橫跨了好幾個畫面和動作，更有趣的是，幾乎所有的功能都有規格書，唯獨這個功能沒有，因為PM也不知道要怎麼做？
為此，不久前曾開了一個需求會議，我跟架構師、PM和大PM一起討論過，但其實還是留了一些未知數，所以下午又去找架構師討論，該怎麼處理這種跨好幾個模組、畫面的東西，最後還是決定用Spring framework去攔截action後再來處理(AOP)，定案後開始一邊看Spring framework的書一邊寫code (別懷疑，我本身不是那麼喜歡AOP的programming style，所以過去都不太碰它)，本來程式放在A專案，因為dependency和visibility的問題，後來又把程式改放到B專案，花了大概2小時把攔截action需要的程式搞定(ㄟ...這只是這個功能的其中一個步驟而已)，告一段落後找架構師code review，很好，沒什麼大問題，明天可以繼續往下做了。
回到自己的座位，隔壁的同事跟我說有個會議在C室，哈~我忘記今天有Team leader會議了，趕緊匆匆忙忙趕過去，一進去就看到投影片打著XX銀行的YY系統規格書，似乎是某位剛當team leader的同事在和主管討論規格書及開發手冊的撰寫吧！嗯~我自己是不寫那種東西的，等等，剛剛我不是才說某個功能沒有規格書嗎？那自己如果要負責一個新project卻不寫規格？其實平常我也不太看規格，現在寫程式都是根據prototype一邊操作一邊把功能實作出來，規格書只是在我測試時參考用的，就如同主管說的，當規格書越寫越多，之後程式跟規格書的差異維護就越痛苦，如果程式寫的易讀好懂，看程式有時候會比看規格書快(ok，真的只是有時候，畢竟我看到現在，讓我驚嘆的好程式不多)，我自己也是靠看程式摸索目前系統的架構，不過這方法不見得適合資淺的工程師，所以開發手冊還是要有，規格書...我倒不那麼在意，只要能溝通清楚就好。但是...凡事都有一個但是，那些規格舒是XX銀行要求的，難怪有一堆奇奇怪怪看不懂的縮寫，他們真的很愛縮寫耶！因為這樣...就只好寫給他們啦~
為此，不久前曾開了一個需求會議，我跟架構師、PM和大PM一起討論過，但其實還是留了一些未知數，所以下午又去找架構師討論，該怎麼處理這種跨好幾個模組、畫面的東西，最後還是決定用Spring framework去攔截action後再來處理(AOP)，定案後開始一邊看Spring framework的書一邊寫code (別懷疑，我本身不是那麼喜歡AOP的programming style，所以過去都不太碰它)，本來程式放在A專案，因為dependency和visibility的問題，後來又把程式改放到B專案，花了大概2小時把攔截action需要的程式搞定(ㄟ...這只是這個功能的其中一個步驟而已)，告一段落後找架構師code review，很好，沒什麼大問題，明天可以繼續往下做了。
回到自己的座位，隔壁的同事跟我說有個會議在C室，哈~我忘記今天有Team leader會議了，趕緊匆匆忙忙趕過去，一進去就看到投影片打著XX銀行的YY系統規格書，似乎是某位剛當team leader的同事在和主管討論規格書及開發手冊的撰寫吧！嗯~我自己是不寫那種東西的，等等，剛剛我不是才說某個功能沒有規格書嗎？那自己如果要負責一個新project卻不寫規格？其實平常我也不太看規格，現在寫程式都是根據prototype一邊操作一邊把功能實作出來，規格書只是在我測試時參考用的，就如同主管說的，當規格書越寫越多，之後程式跟規格書的差異維護就越痛苦，如果程式寫的易讀好懂，看程式有時候會比看規格書快(ok，真的只是有時候，畢竟我看到現在，讓我驚嘆的好程式不多)，我自己也是靠看程式摸索目前系統的架構，不過這方法不見得適合資淺的工程師，所以開發手冊還是要有，規格書...我倒不那麼在意，只要能溝通清楚就好。但是...凡事都有一個但是，那些規格舒是XX銀行要求的，難怪有一堆奇奇怪怪看不懂的縮寫，他們真的很愛縮寫耶！因為這樣...就只好寫給他們啦~
- Jan 08 Tue 2013 21:20
-
Unit test到底要測什麼？
說來慚愧，和現在Comic Surfer Core的98%涵蓋率(Statement & branch coverage)相比，進公司到現在，我目前在寫的程式，搭配有單元測試的不多，主要有幾個原因，第一是Comic Surfer共121個測試案例，全部執行完畢平均不到2秒，這是讓我寫單元測試的動力，當一個測試要跑超過10秒，除非是超大系統的整合測試，我實在不想跑，也就自然不想寫了，現在光是一個小小的converter要測試，都要靠Spring framework注入一堆web services，10秒能啟動完整的環境就算是幸運了，即使那個method的測試案例可能不到0.1秒，但整體來說一個測試案例要跑10秒，啟動環境的時間是執行測試時間的100倍？光想就覺得煩...
第二是如果不想靠Spring framework注入web services，那就寫mock的web services然後再用setter注入吧！事實上Spring framework也用類似的機制注入所需要的物件，但問題來了，以最近寫的converter為例，需要三個web services，也就是說我要一次mock三個web services，會用到這麼多web services是因為我們不直接跟DB溝通，都是透過web services，當初表格正規化的很徹底，而一張表格通常就對應了一個web service，在這樣的情況下，為了取得必要的資料，一個簡單的功能可能就需要多個web services，mock一個我還考慮考慮，mock二個我勉強勉強，mock三個我放棄，特別是公司用的mock framework，寫出來的mock不太能重複使用，我就不想寫mock了，最後還是透過Spring framework注入真的web service算了。
第三是DAO的測試有點討厭，而且很難省時間，都是需要操作真正的DB，即便可以用In memory DB加快從硬碟讀取資料的速度，但Hibernate還是要靠Spring framework注入，因為transaction是由Spring framework來管，DB已經慢了，再加上Spring framework，唉...所以，另外一個同事以及架構師都說，測試都是丟到Jenkins上離線的時候跑，若當成regression test這idea很好，每天跑時時跑(我每天都會收到一堆Jenkins的報告)，但單元測試的重點不就是快速反應錯誤然後快速修改嗎？目前Jenkins建置加上跑完所有測試案例超過半小時，我如果只是改一個小小地方，在Tomcat沒關掉，Eclipse plug-in會自動將程式更新到server的情況下，我還是寧願透過UI測試。
第二是如果不想靠Spring framework注入web services，那就寫mock的web services然後再用setter注入吧！事實上Spring framework也用類似的機制注入所需要的物件，但問題來了，以最近寫的converter為例，需要三個web services，也就是說我要一次mock三個web services，會用到這麼多web services是因為我們不直接跟DB溝通，都是透過web services，當初表格正規化的很徹底，而一張表格通常就對應了一個web service，在這樣的情況下，為了取得必要的資料，一個簡單的功能可能就需要多個web services，mock一個我還考慮考慮，mock二個我勉強勉強，mock三個我放棄，特別是公司用的mock framework，寫出來的mock不太能重複使用，我就不想寫mock了，最後還是透過Spring framework注入真的web service算了。
第三是DAO的測試有點討厭，而且很難省時間，都是需要操作真正的DB，即便可以用In memory DB加快從硬碟讀取資料的速度，但Hibernate還是要靠Spring framework注入，因為transaction是由Spring framework來管，DB已經慢了，再加上Spring framework，唉...所以，另外一個同事以及架構師都說，測試都是丟到Jenkins上離線的時候跑，若當成regression test這idea很好，每天跑時時跑(我每天都會收到一堆Jenkins的報告)，但單元測試的重點不就是快速反應錯誤然後快速修改嗎？目前Jenkins建置加上跑完所有測試案例超過半小時，我如果只是改一個小小地方，在Tomcat沒關掉，Eclipse plug-in會自動將程式更新到server的情況下，我還是寧願透過UI測試。