脆笛酥：今天公司下午茶提供的餐點是『起司烤馬鈴薯』耶，送來的時候還熱熱的，好好吃喔。
豆豆龍：對啊，訂下午茶的小妹終於做了點功課，換了新菜色了。
脆笛酥：如果下次能夠換成烤地瓜也不錯喔，健康又幫助消化。
豆豆龍：No, No, No。 烤地瓜不太優喔。
脆笛酥：為什麼？
豆豆龍：如果下午茶吃烤地瓜，那豈不變成大家『嘴巴也放屁，屁股也放屁』。
脆笛酥：對厚，應付嘴巴放出來的屁就已經夠累人了，沒必要自找麻煩再應付屁股放出來的屁了。
***
友藏內心獨白：萬能的捧油，請賜與我搞笑的點子。
l
2011年8月25日 星期四
改行寫網路小說算了 (4)
August 25 20:20~22:58
脆笛酥：今天公司下午茶提供的餐點是『起司烤馬鈴薯』耶，送來的時候還熱熱的，好好吃喔。
豆豆龍：對啊，訂下午茶的小妹終於做了點功課，換了新菜色了。
脆笛酥：如果下次能夠換成烤地瓜也不錯喔，健康又幫助消化。
豆豆龍：No, No, No。 烤地瓜不太優喔。
脆笛酥：為什麼？
豆豆龍：如果下午茶吃烤地瓜，那豈不變成大家『嘴巴也放屁，屁股也放屁』。
脆笛酥：對厚，應付嘴巴放出來的屁就已經夠累人了，沒必要自找麻煩再應付屁股放出來的屁了。
友藏內心獨白：萬能的捧油，請賜與我搞笑的點子。
脆笛酥：今天公司下午茶提供的餐點是『起司烤馬鈴薯』耶，送來的時候還熱熱的，好好吃喔。
豆豆龍：對啊，訂下午茶的小妹終於做了點功課，換了新菜色了。
脆笛酥：如果下次能夠換成烤地瓜也不錯喔，健康又幫助消化。
豆豆龍：No, No, No。 烤地瓜不太優喔。
脆笛酥：為什麼？
豆豆龍：如果下午茶吃烤地瓜，那豈不變成大家『嘴巴也放屁，屁股也放屁』。
脆笛酥：對厚，應付嘴巴放出來的屁就已經夠累人了，沒必要自找麻煩再應付屁股放出來的屁了。
友藏內心獨白：萬能的捧油，請賜與我搞笑的點子。
2011年8月23日 星期二
原來這就是 internal DSL
August 23 20:31~23:54
幾個禮拜前 Teddy 看了一點 DSL (Domain Specific Languages) 的書，後來有學弟問 Teddy 使用過 external DSL 還是 internal DSL，Teddy 答曰：『只用過 external DSL』。沒想到好死不死 好巧不巧，最近 Teddy 把 Quartz 從 1.8.x 版升級到 2.0.x 版，居然在新版的 Quartz 就有用到 internal DSL 的設計，幸運地讓 Teddy 找到了一個活生生的 飯粒 範例。
看一小段從 What's New In Quartz Scheduler 2.0 節錄下來的文字：
The most obvious differences with version 2.0 are the significant changes to the API. These changes have aimed to:
modernize the API to use collections and generics, remove ambiguities and redundancies, hide/remove methods that should not be public to client code, improve separation of concerns, and introduce a Domain Specific Language (DSL) for working with the core entities (jobs and triggers).
講到這邊先稍微介紹一下 Quartz，這是一個用 Java 開發的開放原始碼工作排程系統（job scheduling system），這樣的系統有什麼用途呢？假設鄉民們所開發的軟體需要定期的執行許多工作，例如，
以上扯了這麼多，都沒還講到 Quartz 的 internal DSL。上面的程式碼是 Quartz 1.8.x 版的程式碼，鄉民們可以發現 Quartz 是採用 getter/setter 的方式來操作 JobDetail 與 Trigger 物件。到了 Quartz 2.0.x 版之後，Quartz 改用了 internal DSL 的方式來產生 JobDetail 與 Trigger。請看範例：
兩相比對之下就很容易看出不同之處。套用 Martin Fowler 在書中（Domain-Specific Languages，p. 16）的講法，Quartz 1.8.x 版使用的是 command-query API，而 Quartz 2.0.x 版則改用 fluent interface。
友藏內心獨白：今天有點拼...XD。
幾個禮拜前 Teddy 看了一點 DSL (Domain Specific Languages) 的書，後來有學弟問 Teddy 使用過 external DSL 還是 internal DSL，Teddy 答曰：『只用過 external DSL』。沒想到
看一小段從 What's New In Quartz Scheduler 2.0 節錄下來的文字：
The most obvious differences with version 2.0 are the significant changes to the API. These changes have aimed to:
modernize the API to use collections and generics, remove ambiguities and redundancies, hide/remove methods that should not be public to client code, improve separation of concerns, and introduce a Domain Specific Language (DSL) for working with the core entities (jobs and triggers).
講到這邊先稍微介紹一下 Quartz，這是一個用 Java 開發的開放原始碼工作排程系統（job scheduling system），這樣的系統有什麼用途呢？假設鄉民們所開發的軟體需要定期的執行許多工作，例如，
- 每一，三，五的晚上三點半執行備份檔案工作。
- 每天早上七點叫你起床
順便泡一杯咖啡。 - 隨時（每 5 秒）幫你監看硬碟中的檔案是否有異動。
- 每個月第一個禮拜四提醒你去繳信用卡卡費。
- 每隔兩週的週四下午一點幫你發 sprint demo meeting 的開會通知。
- Scheduler：用來排程工作與觸發工作的物件。Scheduler 可以設定 thread pool size，用以決定同時間有多少個 thread 可以執行 job。
- Job：要執行的工作邏輯定義在你自己的 Job 物件上面（要實做 Quartz 的 Job interface，如下圖所示）。基本上 Job interface 就類似 GoF 裡面的 Command pattern，只定義了一個 execute() method。
- Trigger：用來紀錄『觸發時間』的物件，一個 trigger 物件必須要關聯到一個 job 才會發生作用，但是一個 job 卻可以有很多個 trigger。例如，你希望每天早上八點和下午八點自動執行資料備份的程式，那麼你就可以產生兩個 trigger 物件，把他們的 start time 分別設定為早上八點和下午八點，然後再將這兩個 triggers 與備份資料的 job 建立關聯並使用 Scheduler 來排程這兩個 triggers。如此一來 triggers 設定時間一到 Quartz 就會自動執行這個 job。請看以下範例（Quartz 的 CronTrigger 物件有支援使用 Cron expression 來設定觸發時間，會用之後還滿方便的）。
- JobDetail：雖說 Quartz 『概念上』是將 trigger 關聯到一個 job 身上，但實際上在 Quartz 的實做中 trigger 是關聯到一個稱之為 JobDetail 的物件上。JobDetail 首先會關聯到某個 job，此外 JobDetail 還有一個 Map 物件，可以用來『夾帶』任何需要傳給 job 的資料，如下圖所示。
***
以上扯了這麼多，都沒還講到 Quartz 的 internal DSL。上面的程式碼是 Quartz 1.8.x 版的程式碼，鄉民們可以發現 Quartz 是採用 getter/setter 的方式來操作 JobDetail 與 Trigger 物件。到了 Quartz 2.0.x 版之後，Quartz 改用了 internal DSL 的方式來產生 JobDetail 與 Trigger。請看範例：
這是 Quartz 1.8.x 版的範例
這是 Quartz 2.0.x 版的範例
兩相比對之下就很容易看出不同之處。套用 Martin Fowler 在書中（Domain-Specific Languages，p. 16）的講法，Quartz 1.8.x 版使用的是 command-query API，而 Quartz 2.0.x 版則改用 fluent interface。
***
雖然剛開始不習慣，但 Quartz 的 fluent interface 用久了還滿好用的說...時間不早，該睡了，明天 8:30 還要開會....***
友藏內心獨白：今天有點拼...XD。
2011年8月20日 星期六
幸福有感
August 19 23:01~ August 20 00:0
上個禮拜五早上起床之後，『腰』覺的痛痛的，本來想說週末休息一下就好，結果到禮拜一還是沒有改善，只好在 Scrum Planning Meeting 之後下午請假去看復健科門診。到了醫院，復健科的『老師（復健治療師）』看到 Teddy 就說了一聲：『好久不見喔』... 是啊，自從上次『二度』治療脖子痛到現在也已經過了 10 個月了。在醫院，就好像一個犯人出獄一樣，最不想說的兩個字，就是『再見』。雖然每個月繳了不少的健保費，但是沒事還是不要使用為妙。
本以為醫生會叫 Teddy 去照 X 光，結果並沒有。聽完 Teddy 的描述之後，醫生說先復健（深層熱療和電療），如果下次門診（就是今天啦）還沒改善再照 X 光。這可能是一個好徵兆，因為之前 Teddy 去看脖子痛時，第一次門診就去照了 X 光，結果是頸椎有問題，壓到神經。應該是長期姿勢不良加上電腦用太多了，可能低頭看書也有影響。結果一週復健六天，連續復健了 3 個月。那時候，Teddy 真的了解『小王』的辛酸，復健真的好累啊。而且聽復健治療師說，很多病人的問題都無法根治（有些是老化的自然現象，有些是因為沒有耐心持續復健下去），待症狀減緩之後，就停止復健，過一陣子問題復發，又乖乖回來報到。所以在復健科常常可以見到『回鍋的熟客』。Teddy 脖子的問題，也是沒有根治，前後治療了兩輪，到後來只能靠減少一些電腦的使用以及注意看書的姿勢來避免復發。
Teddy 腰痛的問題，經過五次的復健，症狀從原本的『疼痛』，變成『酸』，已經算是有改善，醫生說要繼續復健。希望這次能夠在一個月之內痊癒。
前幾天腰痛的厲害，Teddy 不太敢用電腦，自然也沒寫部落格了。這一，兩天狀況稍微好點，Teddy 突然有所感慨。約五年多前，Teddy 身體狀況開始不太好，一開始是胃潰瘍，到現在只要喝含有咖啡因的飲料或是可樂，養樂多，胃就會不舒服。所以 Teddy 只好忍痛把喝咖啡的習慣給戒掉了。約兩年前脖子痛，Teddy 就慢慢減少寫程式的數量，偶爾手癢忍不住卯起來連續寫了幾天之後，脖子就會不太舒服，所以現在寫程式都要提醒自己『寫慢一點』。最近腰痛期間，最嚴重的時候連從椅子上面站起來腰都無法打直；沒想到一個這麼簡單的動作，此時卻是如此的困難啊。
古人說『能吃能睡就是福』，現在 Teddy 才深深體會到這個道理。對大多數的人來說，喝一杯熱熱的拿鐵咖啡，扭扭腰，擺擺頭，是多麼簡單與自然的事，沒什麼了不起。對 Teddy 而言，能做到這幾件事，就是幸福。前幾天在雜誌上面看到『伊甸基金會』為『發展遲緩兒』的募款廣告，上面登了一張照片，照片中是一個坐在輪椅上的小女孩，她讓 Teddy 想起之前在復健科看到的另一個小女孩，因為某種原因不良於行，要靠復健來練習走路。對大多數的人來說，走路是多麼簡單與自然的事，對小女孩來說，能正常走路是幸福。
什麼是幸福？健康就是幸福，正常就是幸福，簡單就是幸福，吃的飽穿得暖就是幸福，做自己喜歡的事就是幸福，有能力助人就是幸福。錢，夠用就好。
路人甲：問題是我的錢永遠都不夠用啊。
友藏內心獨白：寫部落格算是拿命來拼滴...XD。
上個禮拜五早上起床之後，『腰』覺的痛痛的，本來想說週末休息一下就好，結果到禮拜一還是沒有改善，只好在 Scrum Planning Meeting 之後下午請假去看復健科門診。到了醫院，復健科的『老師（復健治療師）』看到 Teddy 就說了一聲：『好久不見喔』... 是啊，自從上次『二度』治療脖子痛到現在也已經過了 10 個月了。在醫院，就好像一個犯人出獄一樣，最不想說的兩個字，就是『再見』。雖然每個月繳了不少的健保費，但是沒事還是不要使用為妙。
本以為醫生會叫 Teddy 去照 X 光，結果並沒有。聽完 Teddy 的描述之後，醫生說先復健（深層熱療和電療），如果下次門診（就是今天啦）還沒改善再照 X 光。這可能是一個好徵兆，因為之前 Teddy 去看脖子痛時，第一次門診就去照了 X 光，結果是頸椎有問題，壓到神經。應該是長期姿勢不良加上電腦用太多了，可能低頭看書也有影響。結果一週復健六天，連續復健了 3 個月。那時候，Teddy 真的了解『小王』的辛酸，復健真的好累啊。而且聽復健治療師說，很多病人的問題都無法根治（有些是老化的自然現象，有些是因為沒有耐心持續復健下去），待症狀減緩之後，就停止復健，過一陣子問題復發，又乖乖回來報到。所以在復健科常常可以見到『回鍋的熟客』。Teddy 脖子的問題，也是沒有根治，前後治療了兩輪，到後來只能靠減少一些電腦的使用以及注意看書的姿勢來避免復發。
Teddy 腰痛的問題，經過五次的復健，症狀從原本的『疼痛』，變成『酸』，已經算是有改善，醫生說要繼續復健。希望這次能夠在一個月之內痊癒。
***
前幾天腰痛的厲害，Teddy 不太敢用電腦，自然也沒寫部落格了。這一，兩天狀況稍微好點，Teddy 突然有所感慨。約五年多前，Teddy 身體狀況開始不太好，一開始是胃潰瘍，到現在只要喝含有咖啡因的飲料或是可樂，養樂多，胃就會不舒服。所以 Teddy 只好忍痛把喝咖啡的習慣給戒掉了。約兩年前脖子痛，Teddy 就慢慢減少寫程式的數量，偶爾手癢忍不住卯起來連續寫了幾天之後，脖子就會不太舒服，所以現在寫程式都要提醒自己『寫慢一點』。最近腰痛期間，最嚴重的時候連從椅子上面站起來腰都無法打直；沒想到一個這麼簡單的動作，此時卻是如此的困難啊。
古人說『能吃能睡就是福』，現在 Teddy 才深深體會到這個道理。對大多數的人來說，喝一杯熱熱的拿鐵咖啡，扭扭腰，擺擺頭，是多麼簡單與自然的事，沒什麼了不起。對 Teddy 而言，能做到這幾件事，就是幸福。前幾天在雜誌上面看到『伊甸基金會』為『發展遲緩兒』的募款廣告，上面登了一張照片，照片中是一個坐在輪椅上的小女孩，她讓 Teddy 想起之前在復健科看到的另一個小女孩，因為某種原因不良於行，要靠復健來練習走路。對大多數的人來說，走路是多麼簡單與自然的事，對小女孩來說，能正常走路是幸福。
什麼是幸福？健康就是幸福，正常就是幸福，簡單就是幸福，吃的飽穿得暖就是幸福，做自己喜歡的事就是幸福，有能力助人就是幸福。錢，夠用就好。
路人甲：問題是我的錢永遠都不夠用啊。
***
友藏內心獨白：寫部落格算是拿命來拼滴...XD。
2011年8月8日 星期一
防弊還是興利
August 08 22:46~23:30
這一期的科學人雜誌，有一篇前任衛生署長『楊志良』先生所寫的『全民健保的迷思』（2011年8月號，pp. 74-76），短短的三頁，清楚說明了全民健保幾個重要且容易被誤解的觀點，寫得非常的棒。今天 Teddy 想引用一下其中楊志良先生提到關於『為了抑制浪費，應該提高部份負擔』的這個觀點。在讀這篇文章之前，Teddy 每次到醫院看完醫生批完價的時候，看到帳單都覺的『這個部份負擔也太便宜了吧，難怪有那麼多人沒事勤跑醫院，浪費醫療資源，應該要提高部份負擔以減少浪費才對』。接下來 Teddy 引用一下這篇文章的這一小段內容：
台灣每人每年平均就醫高達14次，是歐美一般國家4-6次的兩倍以上，因此不少人倡言，應該提高部份負擔以抑制醫療浪費。價格提高，消費必然減少，但部份負擔提高，則可能有些貧困者無法獲得必要的醫療。更困難的是，我們永遠無法訂出一個適切的部份負擔，因為同樣的金錢對每個人的效用不一樣，同樣的50元對有些富人如同無物，一點都不在乎，而一家四口只有一碗泡麵者，則是一餐的代價。
由於不可能針對每個人訂定部份負擔，因此不管如何訂，對某些人總是太低，而某些人則是太高，那麼我們就要問：健保的目的是什麼？如果是減少浪費，那就訂部份負擔愈高越好，甚至100%負擔。天下沒有完美的制度，有利就有弊，兩害相權取其輕，兩利相權取其重，去掉弊常也把利取消掉了。若健保的目的是要達到全民健康照護，那麼部份負擔就只能訂得低，但接受某種程度的浪費。
***
看完這一段，Teddy 就了解了，原來部份負擔有這樣一個層面的意義。很多制度的設計，都想要在『防弊』和『興利』兩者之間取得平衡點，有時候做『防弊防過頭』，就會造成文中所講得『去掉弊常也把利取消掉了』。舉的例子，今天看到某位學弟 Plurk 上面的留言：
說 扯~ 因為專案需要買平板電腦 會計室竟然有意見 請問是怎樣? 買平板電腦是什麼不道德的事情嗎? 虧還號稱是科技大學 這群會計室的人都活在遠古時代
這就是學校單位標準的『防弊』心態，幾乎是把每位老師都當成『賊』來防備。之前 Teddy 還有聽說過，用X科會計畫買『數位相機』，結果X科會的人來查帳的時候，說該專案執行不需要使用『數位相機』，因此要求計畫主持人自己買單。奇怪了，這些人那麼會查，怎麼社會上那麼多官商勾結的案子，隨隨便便都是以『億』起跳的，都不去查，只會欺負這些老實人。
不要一天到晚把什麼『卓越』啦，『頂尖』啦放在嘴邊，能夠『落實』才是王道。如何落實？先把這些『週邊行政人員與法規』提昇一下吧，至少 Teddy 在念書的時候，從學校行政大樓得到的，幾乎只有『阻力』，鮮少得到什麼幫助。他們可能都在想：
總之，如果以『興利』為出發點，就得有『接受某種程度的浪費』的覺悟。否則，一味地想著『防弊』，那乾脆什麼事都不要做好了，回到『多作多錯，少做少做，不做不錯』的時代。
友藏內心獨白：『愛新覺羅，普羅旺斯』，這就是你治理下的偉大公務體系。
這一期的科學人雜誌，有一篇前任衛生署長『楊志良』先生所寫的『全民健保的迷思』（2011年8月號，pp. 74-76），短短的三頁，清楚說明了全民健保幾個重要且容易被誤解的觀點，寫得非常的棒。今天 Teddy 想引用一下其中楊志良先生提到關於『為了抑制浪費，應該提高部份負擔』的這個觀點。在讀這篇文章之前，Teddy 每次到醫院看完醫生批完價的時候，看到帳單都覺的『這個部份負擔也太便宜了吧，難怪有那麼多人沒事勤跑醫院，浪費醫療資源，應該要提高部份負擔以減少浪費才對』。接下來 Teddy 引用一下這篇文章的這一小段內容：
台灣每人每年平均就醫高達14次，是歐美一般國家4-6次的兩倍以上，因此不少人倡言，應該提高部份負擔以抑制醫療浪費。價格提高，消費必然減少，但部份負擔提高，則可能有些貧困者無法獲得必要的醫療。更困難的是，我們永遠無法訂出一個適切的部份負擔，因為同樣的金錢對每個人的效用不一樣，同樣的50元對有些富人如同無物，一點都不在乎，而一家四口只有一碗泡麵者，則是一餐的代價。
由於不可能針對每個人訂定部份負擔，因此不管如何訂，對某些人總是太低，而某些人則是太高，那麼我們就要問：健保的目的是什麼？如果是減少浪費，那就訂部份負擔愈高越好，甚至100%負擔。天下沒有完美的制度，有利就有弊，兩害相權取其輕，兩利相權取其重，去掉弊常也把利取消掉了。若健保的目的是要達到全民健康照護，那麼部份負擔就只能訂得低，但接受某種程度的浪費。
***
看完這一段，Teddy 就了解了，原來部份負擔有這樣一個層面的意義。很多制度的設計，都想要在『防弊』和『興利』兩者之間取得平衡點，有時候做『防弊防過頭』，就會造成文中所講得『去掉弊常也把利取消掉了』。舉的例子，今天看到某位學弟 Plurk 上面的留言：
說 扯~ 因為專案需要買平板電腦 會計室竟然有意見 請問是怎樣? 買平板電腦是什麼不道德的事情嗎? 虧還號稱是科技大學 這群會計室的人都活在遠古時代
這就是學校單位標準的『防弊』心態，幾乎是把每位老師都當成『賊』來防備。之前 Teddy 還有聽說過，用X科會計畫買『數位相機』，結果X科會的人來查帳的時候，說該專案執行不需要使用『數位相機』，因此要求計畫主持人自己買單。奇怪了，這些人那麼會查，怎麼社會上那麼多官商勾結的案子，隨隨便便都是以『億』起跳的，都不去查，只會欺負這些老實人。
不要一天到晚把什麼『卓越』啦，『頂尖』啦放在嘴邊，能夠『落實』才是王道。如何落實？先把這些『週邊行政人員與法規』提昇一下吧，至少 Teddy 在念書的時候，從學校行政大樓得到的，幾乎只有『阻力』，鮮少得到什麼幫助。他們可能都在想：
- 只要是出國參加研討會，就是要趁機跑出去玩。
- 只要是買墨水匣，就是要拿回家自己用。
- 只要是買數位相機，也是要拿回家自己用。
- 只要是買平板電腦，還是要拿回家自己用。
- 只要是....反正不管買什麼，都是老師要拿回家自己用就對了啦。
***
總之，如果以『興利』為出發點，就得有『接受某種程度的浪費』的覺悟。否則，一味地想著『防弊』，那乾脆什麼事都不要做好了，回到『多作多錯，少做少做，不做不錯』的時代。
***
友藏內心獨白：『愛新覺羅，普羅旺斯』，這就是你治理下的偉大公務體系。
2011年8月7日 星期日
麥甲我蓋布袋, Part 4：老闆，我不是來殺價滴
August 07 20:45~23:25
『麥甲我蓋布袋』 系列文章蟄伏了一年七個月之後，今日重出江湖，可見 Teddy 的修為還是不夠，EQ 太低，尚未達到『視而不見，聽而不聞』的境界。
今天下午三點出門搭火車到鶯歌，準備參觀陶瓷博物館。先講結論，鶯歌陶瓷博物館蓋的還真不錯，館內的服務人員也很多，感覺是一間很有國際水準的博物館。不過 Teddy 萬萬沒想到，第一眼看到陶瓷博物館的感覺居然是：『怎麼跟京都由安藤忠雄所設計的陶板名畫庭那麼像』，只是鶯歌陶瓷博物館的規模大了許多。不過 Teddy 可以確定一點，鶯歌陶瓷博物館不可能是安藤忠雄設計的，答案等一下揭曉。先看一下幾張陶板名畫庭的照片：
陶板名畫庭佔地不大， Teddy 後方是陶板名畫庭的入口處。由於陶板名畫庭就在大馬路旁，站在入口處會覺的有一點吵，因此安藤忠雄特別在入口處設計了一個水簾，藉由水流的聲音，遮蔽了車輛的噪音（此為 Teddy 的猜測）。此外，這樣的設計還有降溫的作用。一走入陶板名畫庭，會突然有一種很『沁涼』的感覺。
為什麼 Teddy 一開始的時候可以肯定的說鶯歌陶瓷博物館不是安藤忠雄設計的，請仔細看一看上面這張照片中的清水混泥土（就是擋在畫前面的這面牆壁），表面是如此的平滑細緻。鄉民們有機會可以去鶯歌陶瓷博物館（或是台灣各地也都可以看到類似的清水混泥土建築....『貴校』的科技大樓就是...XD），施工水準說真的比不上安藤忠雄的清水混泥土。只能算是學到人家的『形』，而沒有學到『瓍』（基本上連『皮』都沒有學好）。
講了一大堆，都還沒講到今天的重點。Teddy 17:30 分左右離開鶯歌陶瓷博物館來到鶯歌老街，本來想找個舒服一點的餐廳吃晚餐（又是吃吃喝喝...好像某種動物...XD），但是沒找到，只在街尾吃了一碗黑豆花。吃完豆花想說回到板橋火車站吃飯好了，於是從老街街尾往回走，快到老街入口處，看到有一家專門在賣『杯子』的店。Teddy 一直都想要買一些特別一點的杯子，於是到店內逛了一下。這家店的杯子種類還真多啊，看起來品質也都不錯。從最便宜的 199，399，499 到一組要 1 萬多的下午茶具組都有，還有一幅約 799 左右的進口小型陶版畫（這個 Teddy 很喜歡）。Teddy 和 Kay 在店內逛了好一會，好多東西都好想買。此時 Teddy 突然想到，身上的現金快用完了，只剩下一張五百和六張一百元紙鈔，正在猶豫到底是要找地方領錢，還是少買一點的時候，在店內看到幾個還不錯看的『杯蓋』，只要 199。Teddy 和 Kay 挑了其中的一個，由於這些杯蓋看起來已經擺了一陣子了，有點髒髒的，因此 Kay 就問了一位不知是店員還是老闆的小姐A：
Kay：請問你們這個杯蓋有新的嗎？
小姐A的回答很奇怪，劈頭就說：
小姐A：這是英國進口的杯蓋，一個賣 199 已經很便宜了。我們只進了十二個，賣到剩三個。我用水幫你擦一下。
此時 Teddy 覺的這位小姐A怎麼這麼奇怪，我們又沒說她的東西貴，也沒有要跟她殺價，她幹麼一開口就說『一個賣 199 已經很便宜了』？只是問她有沒有新品，有就說有，沒有就說沒有這不就好了。在小姐A清理杯蓋的時候，Teddy 又仔細看了幾個杯子，算一算，想買的東西大概需要快 3 千元，但是 Teddy 又不想跑出去找 ATM（逛完陶瓷博物館之後腰酸腿也酸），此時 Teddy 往櫃台看了一下，隱約發現似乎有一台刷卡機。於是 Teddy 問小姐A...
Teddy：請問妳們可以刷卡嗎？
小姐A居然用很『輕蔑』（至少 Teddy 聽起來是這樣的感覺）的態度回答說...
小姐A：你在跟我開完笑嗎？
奇怪了，看過 Teddy 的人應該知道，Teddy 嚴肅的臉加上理了一個很短的小平頭，長得就不像是在開玩笑的樣子，倒是比較像『艋舺』裡面的小混混...XD。聽到小姐A這個回答，Teddy 火氣就上來了...
Teddy：做生意有必要這樣子嗎？我身上現金不夠，問妳能不能刷卡。可以，妳就說可以，不行，就說不行，我可以到外面提款機領錢，有必要用這樣態度對待客人嗎。我是來花錢，不是來跟妳乞討的。
此時小姐A好像有點被 Teddy 的反應嚇到，突然說...超過 300 塊以上就可以刷卡，199 不行。
不管這家店的東西再好，Teddy 已經不想在此消費了。緊接著 Teddy 就跟 Kay 說，我們不買了，走吧。
『麥甲我蓋布袋』 系列文章蟄伏了一年七個月之後，今日重出江湖，可見 Teddy 的修為還是不夠，EQ 太低，尚未達到『視而不見，聽而不聞』的境界。
今天下午三點出門搭火車到鶯歌，準備參觀陶瓷博物館。先講結論，鶯歌陶瓷博物館蓋的還真不錯，館內的服務人員也很多，感覺是一間很有國際水準的博物館。不過 Teddy 萬萬沒想到，第一眼看到陶瓷博物館的感覺居然是：『怎麼跟京都由安藤忠雄所設計的陶板名畫庭那麼像』，只是鶯歌陶瓷博物館的規模大了許多。不過 Teddy 可以確定一點，鶯歌陶瓷博物館不可能是安藤忠雄設計的，答案等一下揭曉。先看一下幾張陶板名畫庭的照片：
陶板名畫庭佔地不大， Teddy 後方是陶板名畫庭的入口處。由於陶板名畫庭就在大馬路旁，站在入口處會覺的有一點吵，因此安藤忠雄特別在入口處設計了一個水簾，藉由水流的聲音，遮蔽了車輛的噪音（此為 Teddy 的猜測）。此外，這樣的設計還有降溫的作用。一走入陶板名畫庭，會突然有一種很『沁涼』的感覺。
館內有一福很長的清明上河圖陶板畫，有多長，這...麼...長...。真的好好看喔，請看（故宮怎麼沒想到把這些古代名畫作成陶板畫呢，感覺很有 fu）。
為什麼 Teddy 一開始的時候可以肯定的說鶯歌陶瓷博物館不是安藤忠雄設計的，請仔細看一看上面這張照片中的清水混泥土（就是擋在畫前面的這面牆壁），表面是如此的平滑細緻。鄉民們有機會可以去鶯歌陶瓷博物館（或是台灣各地也都可以看到類似的清水混泥土建築....『貴校』的科技大樓就是...XD），施工水準說真的比不上安藤忠雄的清水混泥土。只能算是學到人家的『形』，而沒有學到『瓍』（基本上連『皮』都沒有學好）。
鶯歌陶瓷博物館入口處外觀。
鶯歌陶瓷博物館入口處也有水池。
挑高且十分明亮的大廳，感覺很棒。
換個角度從下往上看，三樓有一個可以喝飲料的地方，view 非常好...不過飲料看起來好像不是很吸引人...XD。
來一張全景圖（看到館外的其他建築物，突然覺得整個感覺弱掉了）。
裡面的展覽品也很有料，先看一張馬桶裡面有電視的照片。
忘了這是什麼，總之很可愛。
這是一福畫，也很可愛。
最後，請看一下照片右方的清水混泥土，細緻度有待加強（如果 Teddy 是負責驗收公共工程的公務員，應該會被廠商打死...XD）。
鶯歌陶瓷博物館是很值得一遊的地方，這麼好的博物館居然不收門票，吸引了很多人去參觀。不過 Teddy 覺的有幾點尚可加強之處：
- 冷氣不夠冷：不知道是 Teddy 胖子怕熱還是怎樣，覺的館內溫度如果可以稍微降個1-2度會比較舒適一點。
- B1 有一個空間還算滿大的餐廳居然還在『招標中』，少了一個可以休息吃東西的地方（怎麼滿腦子都是吃吃喝喝的...XD）。
- 館內的服務人員很多，手上都拿著一個一面寫著請輕聲細語另一面寫著請勿觸摸展品的牌子善意的提醒參展的民眾。這是很好的作法，可以維持展館的秩序。但是，Teddy 覺的這些服務人員的『眼神』很有『侵略性』，而且有種『把參展民眾全都當成破壞王』的感覺。因此，Teddy 覺的好像在『被監視下』參觀完整個博物館。這種感覺，說不上來，但總是覺的不太舒服，有點不自在的感覺。以前去歷史博物館，故宮或是台北市立美術館看展覽時，館內也有服務人員盯著看，但是就是不會有那麼強烈的『被監視感』。（路人甲：應該是 Teddy 你最近壞事做太多了吧）。
- 最後一點，也是 Teddy 覺的此行最失敗的一點，就是要從鶯歌火車站走到鶯歌陶瓷博物館這一段路實在是太難走了（太亂了）。一出鶯歌火車站，路旁商家把汽車停在人行道上，導致行人必須走在馬路上。之後的道路幾乎沒有行人可以走的地方，所以基本上幾乎都是走在馬路上，路上車輛很多，遊客也很多，覺的有點危險而且『整體使用者經驗』因為這段路程整個感覺很差。
***
講了一大堆，都還沒講到今天的重點。Teddy 17:30 分左右離開鶯歌陶瓷博物館來到鶯歌老街，本來想找個舒服一點的餐廳吃晚餐（又是吃吃喝喝...好像某種動物...XD），但是沒找到，只在街尾吃了一碗黑豆花。吃完豆花想說回到板橋火車站吃飯好了，於是從老街街尾往回走，快到老街入口處，看到有一家專門在賣『杯子』的店。Teddy 一直都想要買一些特別一點的杯子，於是到店內逛了一下。這家店的杯子種類還真多啊，看起來品質也都不錯。從最便宜的 199，399，499 到一組要 1 萬多的下午茶具組都有，還有一幅約 799 左右的進口小型陶版畫（這個 Teddy 很喜歡）。Teddy 和 Kay 在店內逛了好一會，好多東西都好想買。此時 Teddy 突然想到，身上的現金快用完了，只剩下一張五百和六張一百元紙鈔，正在猶豫到底是要找地方領錢，還是少買一點的時候，在店內看到幾個還不錯看的『杯蓋』，只要 199。Teddy 和 Kay 挑了其中的一個，由於這些杯蓋看起來已經擺了一陣子了，有點髒髒的，因此 Kay 就問了一位不知是店員還是老闆的小姐A：
Kay：請問你們這個杯蓋有新的嗎？
小姐A的回答很奇怪，劈頭就說：
小姐A：這是英國進口的杯蓋，一個賣 199 已經很便宜了。我們只進了十二個，賣到剩三個。我用水幫你擦一下。
此時 Teddy 覺的這位小姐A怎麼這麼奇怪，我們又沒說她的東西貴，也沒有要跟她殺價，她幹麼一開口就說『一個賣 199 已經很便宜了』？只是問她有沒有新品，有就說有，沒有就說沒有這不就好了。在小姐A清理杯蓋的時候，Teddy 又仔細看了幾個杯子，算一算，想買的東西大概需要快 3 千元，但是 Teddy 又不想跑出去找 ATM（逛完陶瓷博物館之後腰酸腿也酸），此時 Teddy 往櫃台看了一下，隱約發現似乎有一台刷卡機。於是 Teddy 問小姐A...
Teddy：請問妳們可以刷卡嗎？
小姐A居然用很『輕蔑』（至少 Teddy 聽起來是這樣的感覺）的態度回答說...
小姐A：你在跟我開完笑嗎？
奇怪了，看過 Teddy 的人應該知道，Teddy 嚴肅的臉加上理了一個很短的小平頭，長得就不像是在開玩笑的樣子，倒是比較像『艋舺』裡面的小混混...XD。聽到小姐A這個回答，Teddy 火氣就上來了...
Teddy：做生意有必要這樣子嗎？我身上現金不夠，問妳能不能刷卡。可以，妳就說可以，不行，就說不行，我可以到外面提款機領錢，有必要用這樣態度對待客人嗎。我是來花錢，不是來跟妳乞討的。
此時小姐A好像有點被 Teddy 的反應嚇到，突然說...超過 300 塊以上就可以刷卡，199 不行。
不管這家店的東西再好，Teddy 已經不想在此消費了。緊接著 Teddy 就跟 Kay 說，我們不買了，走吧。
***
後來 Teddy 又被 Kay 念了。Teddy EQ 太低，修養不夠，遇到這樣的事情，應該想一想：如果是『周星星』或是『無中線』，會怎樣回答？
周星星：我一秒鐘幾十萬上下，沒時間跟妳開玩笑。
無中線：嘿嘿....嫂子啊...我就是在跟妳開玩笑的啦...妳笑了嗎？
***
友藏內心獨白：出門還是多帶一點現金比較保險。
2011年8月4日 星期四
HCI 之動線安排
August 04 22:26~23:30
Teddy 有位朋友最近在裝潢住了 10 幾年的房子，廚房安裝了新的櫥櫃與流理台，收納空間增加了不少。有一次朋友告訴 Teddy：『廚房裝潢好之後，我們就在思考如何擺放像是盤子，碗筷，刀叉，湯匙，米缸，電鍋，等廚房用品的位置，使得在使用的時候可以在行走最短路徑的前提下拿取所需的東西。』
看到這邊鄉民們應該知道 Teddy 的這位朋友是念 Computer Science 出身的，不過這不是重點，重點在於，只要有在做家事或是經常需要在廚房走動的人，一定可以體會『最短路徑』或是『動線流暢』的重要性。例如，要煮飯的時候，米缸，量杯，裝米的鍋子，水槽（洗米與裝水），和電鍋，就應該要可以讓人在『移動距離最短』的情況下完成整個煮飯的任務。
當然廚房不是只有用來洗米這項任務，包括切菜，做菜，切水果，做蛋糕，加熱食品，打果汁，泡咖啡，洗碗，洗抹布等等活動，都要一併考慮進去（讀到這邊應該可以看得出來 Teddy 是一個經常做家事的好男人...XD）。套句 pattern languages 的術語，如果一個廚房使用起來很『順手』，無論這個廚房的大小，中式或是西式，廚具高級或是平價，我們就說這個廚房具有 Quality without a Name 的特性。
扯了一堆，其實『最短路徑』或是『順手』這件事，都在在反應了人類的一個特性，那就是一字曰之『懶』。正所謂『需要為發明之母』...錯，應該改成『懶惰為發明之母』，所以說，一個『設計』的好壞，其中有一項很重要的因素，就是能不能夠讓人類變得更懶惰一點。能夠少走幾步路，就少走幾步路（所以網路購物會大紅大紫這是必然的）。能少打幾個字，少按幾次 mouse click，少捲動幾次 scrollbar，少讓眼珠子上下移動幾次，這些看起來小不拉機的事情，其實往往都是決定使用者買不買單的因素。
舉個例子，有一個老師傅手工打造的網頁長成下面這個鳥樣子：
這是一個顯示某種『趨勢圖』的畫面，使用者在畫面下方勾選要顯示的內容（圖中的 X, Y, Z... U, V, W, T），然後在 Time 欄位選擇要顯示多久的資料（例如，30分鐘，1小時，1天等等），最後下 Query 按鈕資料就會顯示在畫面上方的圖形元件中。另外，畫面上還有一個 Show Avg. 的 check box，點選之後在趨勢圖上會自動畫出一條平均線。
這個設計有一個小問題，就是可以選擇的顯示的內容太多了，會超出一頁畫面，因此畫面右方會出現 scrollbar。當使用者要選擇，例如說， C 的時候，就要把 scrollbar 往下拉才可以看到 C 這個選項。問題來了，雖然選到 C，但是趨勢圖也因為之前拉了 scrollbar 的緣故跑出畫面之外，使用者又要在把 scrollbar 往上拉才可以看到圖形。
切，你可能會想，這個問題很簡單啊，爭什麼，摻在一起做成撒尿牛丸啊，笨蛋...嗯嗯....把畫面切成兩半不就好了。以下為某中切割的結果：
這樣子拉 scrollbar 的時候，就完全不會影響上面的圖形元件了，也就是說不管選了畫面下方的那一個項目，立即可以看到相對應的趨勢圖了。
錯，為什麼？因為 scrollbar 往下拉的時候，雖然不會動到上方的圖形元件，但是 Time，Query button 和 Show Avg. 卻會跟著往上被捲動。也就是說，使用者還是要把 scrollbar 往上拉，才可以按下 Query button 更新上方圖形元件的資料。這個設計還是有改善的空間，留給鄉民們自由發揮。
如果想要以更『科學化』的方式來分析這個使用者介面，可以參考『歪批 GOMS (1) 』，簡單的算一下要達成某個 goal （例如，看到 C 這個項目最近1天的資料，並且要顯示平均線）需要幾個 Operators 就可以算出你到底幫使用者『偷了多少懶』。
介面如果設計的讓人用起來感覺好像在用滑鼠罰跑操場 10 圈，這樣的設計可是沒有人會喜歡滴...除非你想減肥或是想早點得到腕隧道症候群...XD
友藏內心獨白：學弟，接下來該怎麼做，知道了吧。
Teddy 有位朋友最近在裝潢住了 10 幾年的房子，廚房安裝了新的櫥櫃與流理台，收納空間增加了不少。有一次朋友告訴 Teddy：『廚房裝潢好之後，我們就在思考如何擺放像是盤子，碗筷，刀叉，湯匙，米缸，電鍋，等廚房用品的位置，使得在使用的時候可以在行走最短路徑的前提下拿取所需的東西。』
看到這邊鄉民們應該知道 Teddy 的這位朋友是念 Computer Science 出身的，不過這不是重點，重點在於，只要有在做家事或是經常需要在廚房走動的人，一定可以體會『最短路徑』或是『動線流暢』的重要性。例如，要煮飯的時候，米缸，量杯，裝米的鍋子，水槽（洗米與裝水），和電鍋，就應該要可以讓人在『移動距離最短』的情況下完成整個煮飯的任務。
當然廚房不是只有用來洗米這項任務，包括切菜，做菜，切水果，做蛋糕，加熱食品，打果汁，泡咖啡，洗碗，洗抹布等等活動，都要一併考慮進去（讀到這邊應該可以看得出來 Teddy 是一個經常做家事的好男人...XD）。套句 pattern languages 的術語，如果一個廚房使用起來很『順手』，無論這個廚房的大小，中式或是西式，廚具高級或是平價，我們就說這個廚房具有 Quality without a Name 的特性。
***
扯了一堆，其實『最短路徑』或是『順手』這件事，都在在反應了人類的一個特性，那就是一字曰之『懶』。正所謂『需要為發明之母』...錯，應該改成『懶惰為發明之母』，所以說，一個『設計』的好壞，其中有一項很重要的因素，就是能不能夠讓人類變得更懶惰一點。能夠少走幾步路，就少走幾步路（所以網路購物會大紅大紫這是必然的）。能少打幾個字，少按幾次 mouse click，少捲動幾次 scrollbar，少讓眼珠子上下移動幾次，這些看起來小不拉機的事情，其實往往都是決定使用者買不買單的因素。
舉個例子，有一個老師傅手工打造的網頁長成下面這個鳥樣子：
這是一個顯示某種『趨勢圖』的畫面，使用者在畫面下方勾選要顯示的內容（圖中的 X, Y, Z... U, V, W, T），然後在 Time 欄位選擇要顯示多久的資料（例如，30分鐘，1小時，1天等等），最後下 Query 按鈕資料就會顯示在畫面上方的圖形元件中。另外，畫面上還有一個 Show Avg. 的 check box，點選之後在趨勢圖上會自動畫出一條平均線。
這個設計有一個小問題，就是可以選擇的顯示的內容太多了，會超出一頁畫面，因此畫面右方會出現 scrollbar。當使用者要選擇，例如說， C 的時候，就要把 scrollbar 往下拉才可以看到 C 這個選項。問題來了，雖然選到 C，但是趨勢圖也因為之前拉了 scrollbar 的緣故跑出畫面之外，使用者又要在把 scrollbar 往上拉才可以看到圖形。
切，你可能會想，這個問題很簡單啊，
這樣子拉 scrollbar 的時候，就完全不會影響上面的圖形元件了，也就是說不管選了畫面下方的那一個項目，立即可以看到相對應的趨勢圖了。
錯，為什麼？因為 scrollbar 往下拉的時候，雖然不會動到上方的圖形元件，但是 Time，Query button 和 Show Avg. 卻會跟著往上被捲動。也就是說，使用者還是要把 scrollbar 往上拉，才可以按下 Query button 更新上方圖形元件的資料。這個設計還是有改善的空間，留給鄉民們自由發揮。
如果想要以更『科學化』的方式來分析這個使用者介面，可以參考『歪批 GOMS (1) 』，簡單的算一下要達成某個 goal （例如，看到 C 這個項目最近1天的資料，並且要顯示平均線）需要幾個 Operators 就可以算出你到底幫使用者『偷了多少懶』。
介面如果設計的讓人用起來感覺好像在用滑鼠罰跑操場 10 圈，這樣的設計可是沒有人會喜歡滴...除非你想減肥或是想早點得到腕隧道症候群...XD
***
友藏內心獨白：學弟，接下來該怎麼做，知道了吧。
2011年8月3日 星期三
老狗學新把戲之 Groovy
August 03 21:59~23:11
已經想不起來最近一次學新的程式語言是什麼時候了...第一次學 Java 已經是 10 幾年前的事情，Fortran 與 C/C++ 更不用說了都快要 20 年了。至於 Teddy 從學會第一個程式語言 Pascal 至今也有 22 年的光陰了，還真有點懷念 Pascal 啊。五專畢業當兵之前用 VB 3.0 + SQL 接了幾個 cases，當兵的時候算是幸運也是不幸，有一年的時間有機會在部隊中用 VB 3.0 + SQL 寫了『教點召報到程式』。退伍之後工作，學了 ASP（這算程式語言嗎？），Javascript 與 VBScript。
後來回學校唸書，在修課中學了 ML 還有另外一兩個已經忘了什麼名子的程式語言。另外因為研究需要也學了一點 Eiffel，C# 和 Java bytecode，不過這幾個語言應該不能算是真正有學會，因為並沒有拿來開發什麼偉大的程式，只是寫寫作業和練習一些小範例而已。
這幾年很多程式語言如雨後春筍般的冒出，可惜 Teddy 已經不是當年的年輕小伙子，可以毫無顧忌的狂學新的程式語言。想當年要學一個程式語言也不是那麼簡單，連 compiler 或是 IDE 都是要錢滴，不像現在幾乎都可以從網路上找到免費的開發工具與環境。記得好幾年前 Teddy 在讀 The Pragmatic Programmer 這一本書的時候，作者在書中建議開發人員每年應該要學一個新的程式語言。因為不同的程式語言對於解決相同的問題有不同的作法，例如 OO languages 和 functional languages 的風格就大不相同。如果能夠學習各種不同的程式語言並了解其背後解決問題的思維模式，那麼對於開發人員而言，等於多了很多『武器』可以使用。這就好像切菜，剁肉要用菜刀，切水果要用水果刀，削鉛筆要用超級小刀是一樣的道理。
在看完 The Pragmatic Programmer 的當下，Teddy 立志每年要學一個新的程式語言，N 年過去了，好像半個新的語言都沒學，還是在靠 Java 打通關...好薄弱的意志力...XD。
最近因為看了一點 DSL （Domain Specific Language）的書，書中用 Ruby 當作 internal DSL 的例子，於是 Teddy 就想說那去稍微看一下 Ruby 長什麼樣子。結果在找資料的時候發現有用 Java 實做的 JRuby 可以用，那就想說改看 JRuby 好了。但是，繼續 google 一陣子之後，發現 Groovy 這個 script language 和 Java 相容性最好，結果最後變成跑去看 Groovy...XD。
DSL ---> Internal DSL ---> Ruby ---> JRuby ---> Groovy
| ^
｜ |
------------------------------- ? ---------------------------
今天稍微玩了一下 Groovy 發現還真有趣耶，處理 list 很方便，又支援 closure，覺的很多 ML 可以做的事 Groovy 也都可以做，還有很多對於 Java programmers 來講非常貼心的小功能，例如：
println "ls -l" .execute().text
可以直接印出類似這樣的結果：
drwxr-xr-x 7 root root 4096 2010-01-01 19:21 Capivara
drwxr-xr-x 7 root root 4096 2007-11-26 14:28 ies4linux-2.99.0.1
drwxr-xr-x 4 root root 4096 2010-11-05 23:58 java
-rw-r--r-- 1 root root 105990528 2009-12-30 21:36 jdk1.6.0_17.tar.gz
drwxr-xr-x 4 root root 4096 2010-09-26 12:57 Mobile Atlas Creator 1.8
想起當初跟 Java 的 Process, ProcessBuilder 物件奮鬥的過程，和 Groovy 的便利性相比，眼淚簡直快掉下來。
不過只試了幾個小時而已，現在除了覺的『很有趣』以外，還沒有想到什麼實際的用途。幾個可能的方向是：
友藏內心獨白：DOS 批次檔應該也算是程式語言喔！
已經想不起來最近一次學新的程式語言是什麼時候了...第一次學 Java 已經是 10 幾年前的事情，Fortran 與 C/C++ 更不用說了都快要 20 年了。至於 Teddy 從學會第一個程式語言 Pascal 至今也有 22 年的光陰了，還真有點懷念 Pascal 啊。五專畢業當兵之前用 VB 3.0 + SQL 接了幾個 cases，當兵的時候算是幸運也是不幸，有一年的時間有機會在部隊中用 VB 3.0 + SQL 寫了『教點召報到程式』。退伍之後工作，學了 ASP（這算程式語言嗎？），Javascript 與 VBScript。
後來回學校唸書，在修課中學了 ML 還有另外一兩個已經忘了什麼名子的程式語言。另外因為研究需要也學了一點 Eiffel，C# 和 Java bytecode，不過這幾個語言應該不能算是真正有學會，因為並沒有拿來開發什麼偉大的程式，只是寫寫作業和練習一些小範例而已。
這幾年很多程式語言如雨後春筍般的冒出，可惜 Teddy 已經不是當年的年輕小伙子，可以毫無顧忌的狂學新的程式語言。想當年要學一個程式語言也不是那麼簡單，連 compiler 或是 IDE 都是要錢滴，不像現在幾乎都可以從網路上找到免費的開發工具與環境。記得好幾年前 Teddy 在讀 The Pragmatic Programmer 這一本書的時候，作者在書中建議開發人員每年應該要學一個新的程式語言。因為不同的程式語言對於解決相同的問題有不同的作法，例如 OO languages 和 functional languages 的風格就大不相同。如果能夠學習各種不同的程式語言並了解其背後解決問題的思維模式，那麼對於開發人員而言，等於多了很多『武器』可以使用。這就好像切菜，剁肉要用菜刀，切水果要用水果刀，削鉛筆要用超級小刀是一樣的道理。
在看完 The Pragmatic Programmer 的當下，Teddy 立志每年要學一個新的程式語言，N 年過去了，好像半個新的語言都沒學，還是在靠 Java 打通關...好薄弱的意志力...XD。
最近因為看了一點 DSL （Domain Specific Language）的書，書中用 Ruby 當作 internal DSL 的例子，於是 Teddy 就想說那去稍微看一下 Ruby 長什麼樣子。結果在找資料的時候發現有用 Java 實做的 JRuby 可以用，那就想說改看 JRuby 好了。但是，繼續 google 一陣子之後，發現 Groovy 這個 script language 和 Java 相容性最好，結果最後變成跑去看 Groovy...XD。
| ^
｜ |
------------------------------- ? ---------------------------
今天稍微玩了一下 Groovy 發現還真有趣耶，處理 list 很方便，又支援 closure，覺的很多 ML 可以做的事 Groovy 也都可以做，還有很多對於 Java programmers 來講非常貼心的小功能，例如：
println "ls -l" .execute().text
可以直接印出類似這樣的結果：
drwxr-xr-x 7 root root 4096 2010-01-01 19:21 Capivara
drwxr-xr-x 7 root root 4096 2007-11-26 14:28 ies4linux-2.99.0.1
drwxr-xr-x 4 root root 4096 2010-11-05 23:58 java
-rw-r--r-- 1 root root 105990528 2009-12-30 21:36 jdk1.6.0_17.tar.gz
drwxr-xr-x 4 root root 4096 2010-09-26 12:57 Mobile Atlas Creator 1.8
想起當初跟 Java 的 Process, ProcessBuilder 物件奮鬥的過程，和 Groovy 的便利性相比，眼淚簡直快掉下來。
不過只試了幾個小時而已，現在除了覺的『很有趣』以外，還沒有想到什麼實際的用途。幾個可能的方向是：
- 用 Groovy 來做 test automation。
- 用 Groovy 當作 internal DSL 使用，不過不確定是否合適。
- 用 Groovy 來寫 plug-ins。
***
2011年8月2日 星期二
People over Process (3)
August 02 21:37~22:40
前兩集提到 People over Process: Key Challenges in Agile Development 這篇 paper 中提到的關於 people challenges 的兩個因素：『Developer fear of skill-deficiency exposure』與『Broader Skill Sets for Developers』，今天談一下第三點。
Increased Social Interaction
雖然不敢說大部分的 developers 都是『宅男』或是『宅女』，但是相信絕大多數的 developers 內心深處還是隱藏著『寧可和電腦打架，也不願意和人類講話』的傾向。Agile practices 卻是大大地違反這樣的『宅性』，像是 collocation, real customer involvement, stand-up meetings, retrospectives, pair programming 等等，在在都要求 developers 需要具備良好的溝通與 presentation 技能。所有十七個受訪單位都對於培養人際互動技能抱持正面的態度，但是也提出了幾點顧慮：
不管是不是採用 agile methods，communication & presentation skills 在現在的軟體開發活動中算是很重要的一個技能。有時候客戶在講什麼 developers 聽不懂，甚至 developers 彼此溝通都有障礙，導致做了許多虛工並造成不必要的誤會。說真的，溝通的技巧，有時候是要講一點『天分』滴，對於技術出身的人來說，還真是不知道要怎麼訓練其他人提昇 communication & presentation skills。這一點 Teddy 覺的比前兩點都還要難克服。
友藏內心獨白：難道這種現象就是所謂的『很難了解他的明白』的啦...。
前兩集提到 People over Process: Key Challenges in Agile Development 這篇 paper 中提到的關於 people challenges 的兩個因素：『Developer fear of skill-deficiency exposure』與『Broader Skill Sets for Developers』，今天談一下第三點。
Increased Social Interaction
雖然不敢說大部分的 developers 都是『宅男』或是『宅女』，但是相信絕大多數的 developers 內心深處還是隱藏著『寧可和電腦打架，也不願意和人類講話』的傾向。Agile practices 卻是大大地違反這樣的『宅性』，像是 collocation, real customer involvement, stand-up meetings, retrospectives, pair programming 等等，在在都要求 developers 需要具備良好的溝通與 presentation 技能。所有十七個受訪單位都對於培養人際互動技能抱持正面的態度，但是也提出了幾點顧慮：
- 在十五個受訪單位中，都存在著那種『技術能力很強，但是溝通與表達能力天生不良』的人，可見這種現象應該是一個常態。
- 有八個受訪單位提到讓他們曾經在『讓 developers 直接面對客戶』這件事情上面吃了大虧。為什麼？因為，有些事情你現在不必問，有些人你永遠不必等，有些 developers 你永遠不要放出門...XD。嗯嗯...，如同 company O 的經理表示『being a good communicator is one thing. Knowing what not to communicate is much more important』。有些 developers 太老實，一條腸子通到底，很容易一不小心說出了足以動搖國本的真相，將公司的機密一五一十的告訴客戶。例如，把公司和其他客戶簽訂合約的內容，員工的薪水，還有開發團隊的弱點等等毫不保留的一吐為快。這算是『養老鼠咬布袋嗎』？
- 有些跨國公司表示，溝通與表達能力比較好的人，比較容易獲得工作機會，但是等這些人進公司之後，他們所宣稱的技術能力與實際的表現並不相符。翻成白話文就是，比較會唬爛的人，比較容易在跨國公司找到工作。至於技術能力...先混進去再說吧，俗話說：『頭過身就過』。有些人則剛好相反，是屬於『我真憨慢共威（我不善於講話），但是真實在』。
***
不管是不是採用 agile methods，communication & presentation skills 在現在的軟體開發活動中算是很重要的一個技能。有時候客戶在講什麼 developers 聽不懂，甚至 developers 彼此溝通都有障礙，導致做了許多虛工並造成不必要的誤會。說真的，溝通的技巧，有時候是要講一點『天分』滴，對於技術出身的人來說，還真是不知道要怎麼訓練其他人提昇 communication & presentation skills。這一點 Teddy 覺的比前兩點都還要難克服。
***
友藏內心獨白：難道這種現象就是所謂的『很難了解他的明白』的啦...。
2011年8月1日 星期一
People over Process (2)
August 01 21:25~22:40
剛剛去南機場夜市的『芋頭大王』買了一碗冰，現在邊吃著冰，邊吹冷氣，邊寫部落格，這種感覺真是...肚子好脹啊。現在的冰怎麼料那麼多，如果把冰拿去微波，會變成好像在吃『八寶粥』一樣...XD。
在第一集中談到 people challenges 的第一點『Developer fear of skill-deficiency exposure』，今天談一下第二點。
Broader Skill Sets for Developers
傳統的軟體開發團隊，依據所負責的工作內容不同，可以區分為架構師，系統分析師，程式設計師，資料庫管理員，使用者介面設計師，測試員等等。Agile methods 則傾向打破這些角色的界線並且要求 developers 儘量具備各種技能。Paper 中引用了 company M 某位經理的話：
理想上，agile developers 應該是十項全能的『全才』，為什麼呢？因為這樣有很多好處：
要求『全才』這件事是 agile teams 成功的關鍵，但也是很多 teams 實施 agile methods 失敗的原因。短期來看，要開發人員『什麼都懂』的確是不容易，尤其是那些『很有經驗』或是『上了年紀』的開發人員（Teddy 內心獨白：這是在影射 Teddy 嗎？），原本已經很熟悉某一塊特定領域的軟體開發，只要『固守』這塊領域就可以平安度過晚年。導入了什麼鬼 agile methods 之後，這個也要學，那個也要懂，沒事還要被迫去做 pair programming，誰受得了。
以 Teddy 的經驗，『變成全才』這件事，要『以時間換取空間』。不要希望短時間（幾個月）內開發人員都變成專才，這是不可能的，除非這幾個月大家都不開發功能，全部在學習 skills（即使是這樣也不太可能，因為 skills 永遠學不完，而且不開發功能，怎麼知道有那些 skills 是真正需要的呢！）。所以應該把時間拉長到 3 - 5 年來看，希望到時候每個開發人員的技能至少能夠有 80% - 90% 以上是重疊的。軟體專案一開始每個開發人員都有自己專精的那一塊，慢慢地每一個 sprint 藉由 pair programming 的方式把自己專精的技能傳授給其他人。久而久之，團隊個人專精的技能，就會在整個團隊中發散開來。這樣的作法同時可以兼顧到『技術越專精，開發速度愈快，品質愈好』與『全才的 agile 團隊』這兩個要求。
最後以 paper 上面的一句話作為本篇的結尾：
友藏內心獨白：認命吧，做軟體這一行就是沒有學完的一天。
剛剛去南機場夜市的『芋頭大王』買了一碗冰，現在邊吃著冰，邊吹冷氣，邊寫部落格，這種感覺真是...肚子好脹啊。現在的冰怎麼料那麼多，如果把冰拿去微波，會變成好像在吃『八寶粥』一樣...XD。
***
在第一集中談到 people challenges 的第一點『Developer fear of skill-deficiency exposure』，今天談一下第二點。
Broader Skill Sets for Developers
傳統的軟體開發團隊，依據所負責的工作內容不同，可以區分為架構師，系統分析師，程式設計師，資料庫管理員，使用者介面設計師，測試員等等。Agile methods 則傾向打破這些角色的界線並且要求 developers 儘量具備各種技能。Paper 中引用了 company M 某位經理的話：
To be a successful agile developer, you need to be a coder, a tester, an architect, a customer, a quality assurance expert, and a multitude of other things software-related.
理想上，agile developers 應該是十項全能的『全才』，為什麼呢？因為這樣有很多好處：
- 能夠真正依據重要性來挑選 stories ：Product Owner （PO） 每個 sprint 在挑選 stories 時，理論上要先挑重要性比較高的那些 stories 先做。但問題來了，假設這個 sprint PO 挑了三個 stories 都需要寫很多的 SQL，但是在一個五個人的團隊中，只有一個人懂 SQL，這樣子 PO 挑選 stories 的彈性就變小了（因為還要考量到 developers 實做 stories 的能力）。如果團隊成員都是全才，或者至少有 1-2 人 SQL 很熟，其他人的 SQL 屬於中等水準，這樣子問題就很少很多。
- 認領 tasks 的自由度變高：和前一點很類似，當 stories 被切割成 tasks 時， developers 理論上應該要先做重要性較高的 tasks。但是如果團隊成員不是全才，那麼很可能會造重要性較高的 tasks 剛好都只有某位 developer 會做，而他剛好很忙，以至於開發活動卡在他一個人身上，無法在 sprint 結束時完成所有的 stories。
- 較容易達到 Shared Code 的目標：XP 有一個 practices 叫做 shared code，要做到這一點，如果團隊成員不是全才，不可能達到。
- 有人請假不怕事情沒人做：這一點很重要，根據莫非定律，每次你請假的時候，就是你負責的工作出包的時候。如果大家都是全才，那麼就不用說什麼事情都非你不可了。
- 不怕員工拿翹或是人員異動：這是從比較負面的角度來看，如果有員工耍大牌，或是有人離職，對於團隊『戰鬥力（生產力）』的影響可以降到最低。
- 人才難尋：幾乎所有十七個專案都有遇到很難找到具備所有所需 agile skills 開發人員的困難（無論從公司內部或是外聘）。
- 訓練困難：有四個公司把整個團隊送去上課以便學習所有需要的技能，但是這樣做成本很高。在這些公司導入 agile methods 之前，開發人員只受到與他工作相關的某個特定領域的訓練（例如，寫 Java 程式，寫 SQL，寫 Javascript 等等）。因為 agile methods 要求全才，因此開發人員被迫要『東學一點，西學一點』，有些人因此擔心會淪落到『什麼都懂一些，但什麼都不專精』的下場。
***
要求『全才』這件事是 agile teams 成功的關鍵，但也是很多 teams 實施 agile methods 失敗的原因。短期來看，要開發人員『什麼都懂』的確是不容易，尤其是那些『很有經驗』或是『上了年紀』的開發人員（Teddy 內心獨白：這是在影射 Teddy 嗎？），原本已經很熟悉某一塊特定領域的軟體開發，只要『固守』這塊領域就可以平安度過晚年。導入了什麼鬼 agile methods 之後，這個也要學，那個也要懂，沒事還要被迫去做 pair programming，誰受得了。
以 Teddy 的經驗，『變成全才』這件事，要『以時間換取空間』。不要希望短時間（幾個月）內開發人員都變成專才，這是不可能的，除非這幾個月大家都不開發功能，全部在學習 skills（即使是這樣也不太可能，因為 skills 永遠學不完，而且不開發功能，怎麼知道有那些 skills 是真正需要的呢！）。所以應該把時間拉長到 3 - 5 年來看，希望到時候每個開發人員的技能至少能夠有 80% - 90% 以上是重疊的。軟體專案一開始每個開發人員都有自己專精的那一塊，慢慢地每一個 sprint 藉由 pair programming 的方式把自己專精的技能傳授給其他人。久而久之，團隊個人專精的技能，就會在整個團隊中發散開來。這樣的作法同時可以兼顧到『技術越專精，開發速度愈快，品質愈好』與『全才的 agile 團隊』這兩個要求。
***
最後以 paper 上面的一句話作為本篇的結尾：
Developers must have broad knowledge on all aspects of software development but should also specialize and hone their skills in certain areas.
***
友藏內心獨白：認命吧，做軟體這一行就是沒有學完的一天。
訂閱：
文章 (Atom)