ShawTim’s Gossip

子曰：「朝聞道，夕死可矣。」《論語‧里仁第四》

子曰：「知之者不如好之者，好之者不如樂之者。」《論語‧雍也第六》

子曰：「中人以上，可以語上也；中人以下，不可以語上也。」《論語‧雍也第六》

子曰：「甚矣吾衰也！久矣吾不復夢見周公。」《論語‧述而第七》

某日，仲尼老師正在跟大客戶談論項目。客戶說，我這項目很急趕的，甚麼時候可以交貨啊？

朝聞道，夕死可矣⁽¹⁾

「(伸起食指，囂張貌)嘖嘖嘖，我們早上收到你的requirement，拼了命，晚上就能交貨了！」
有顏回這個加班到死的前車之鑑，學生們聽到後，紛紛鼓躁！
於是，仲尼老師就這樣說︰

知之者不如好之者，好之者不如樂之者

「你們都知道是要拼命的了嘛，反正到頭來也是要做，倒不如喜歡上拼老命好了。嗯，與其說喜歡，倒不如嘗試去享受拼老命！實踐！注重實踐！」
沒想到這話說服不了學生們，反而更激起他們的情緒，子路最激動，更大叫「倒不如你來做啊笨？」
仲尼老師不慌不忙的回答說︰

中人以上，可以語上也；中人以下，不可以語上也⁽²⁾

「職級中層以上如我者，當然可以講些『你來做』的上層語言，不過職位低下如你們嘛，這些說話是講不得的。」
學生們更憤怒，仲尼老師沒有辦法，迫於無奈下也加入了開發工程的行列…
仲尼老師做下來，哇靠，還真的好惡頂！畢竟已經年紀一大把…

甚矣吾衰也！久矣吾不復夢見周公

「受不住了！我老了老了！好眼睏！再這樣下去，別說夢見周公啊，我都要親自下去找周公了！好！各位！Deadline postpone~！」
「(淚目)老師仁德！！！！」

Teacher Johnny的教訓
要多些了解團隊的實際狀況，別貪一時之快胡亂硬迫交貨喔！即使是Teacher Johnny的好學生也是會生氣的！

註︰
(1) 「夕死可矣」在這裏可以分拆成「夕死，可矣！」，就是說只要我們拼到晚上死幾個，交貨沒問題！「朝聞道，夕死可矣」原來有幾種解法︰「早上聽到真理，晚上死了也沒有遺憾」「人生短暫，隨時就要死了，所以應該把握時間去追求真理」「聽到真理，就有如重獲新生，過去的自己已經死了」「聽到真理，應該固守(死作固守解)」一般來說都是用第一種解法，不過古文一來沒有標點二來沒有註釋，不好解。看倌們知道有幾種解法就好，不必深究。
(2) 這句話本來的意思是，智慧分成上中下三等，跟有智慧的人要講有智慧的話題，跟沒智慧的人就不要了。這是很能反映出孔子因材施教的觀念，但與此同時也突顯了孔子的階級觀念其實十分之重。至少，他把農、工、商都看成下等人看待。

哀公問：「弟子孰為好學？」孔子對曰：「有顏回者好學，不遷怒，不貳過。不幸短命死矣！今也則亡，未聞好學者也。」《論語‧雍也第六》

某日孔子與大客魯哀公會面，美其名研究項目進度實質閒話家常之際，魯哀公問我們的Teacher Johnny…

弟子孰為好學？
哀︰「你團隊中，哪個小弟最勤奮好學啊？」

有顏回者好學
孔︰「有個叫顏回的小弟，十分好學喔！我常說做學問就是需要實踐嘛，所以他每天都花時間去加班實踐！⁽¹⁾」

不遷怒，不貳過。不幸短命死矣⁽²⁾
「怎樣加班也沒有半句怨言！即使滿腔不滿也能忍耐！而且哦，加班『實踐』出來的code呢，必定一take pass，絕不需要第二take，不會又讓測試員把軟件退回來，了不起，了不起！可惜，他終於受不住死去了啊，可惜可惜。」

今也則亡，未聞好學者也
「現在啊，都沒有這樣的小弟了，也沒有聽聞有誰可以好學如此了。大家都不拼死加班，都不敢拿性命開玩笑了，唉唉，回啊回啊~ 為師想你~⁽³⁾」

Teacher Johnny的教訓
加班別太超過了喔，Teacher Johnny會很傷心的！

註︰
(1) 這不是我故吹的。「學而優則仕」就是說學習的時候如果時間許可的話，好應該去仕官實踐所學。事實上孔子本人也極想當官去實施他的政治理想以及實踐他的學術主張，亦在魯、衛、陳三國當過十四年官，不過沒甚麼成效就是了。孔子可不是只會空談講些空道理的賢者，他更注重實踐。
(2) 「遷」可以解作「轉移」，但更好的解法應為《說文解字》的「登」，即上升。不遷怒，就是控制住怒氣不使其上升，這是顏回的修養。
(3) 孔子的確是十分喜歡顏回這位高徒的。

「子曰：吾，十有五，而志于學，三十而立，四十而不惑，五十而知天命，六十而耳順，七十而從心所欲，不踰矩。」《論語‧為政第二》

話說孔子拿著學生們到大機構打工的薪水(子貢︰「老師… 這是這個月魯國及衛國得來的上繳…」)周遊列國去宣揚他的系統開發理念。這一天學生如常地做了一份Issue Tracker的報告出來，哇，好多defect！我們的萬世師表孔子孔仲尼Johnny Hung對此感到很不滿，覺得學生們完全沒有理會Issue Tracker，就對他們照肺了︰

「我們的defect太多了！現在各位馬上打開Issue Tracker來看！」

吾，十有五，而志于學
「先看看我自己… (哇，有15個defect在我手，好多！)咳嗯，我有15個，可是近來比較忙啦，要跟齊景公開會，又要跟魯照公討論項目細節，這的那的… 嗯，其實我對Issue Tracker還不太會用，我有努力去學怎麼用！好！下一位！(呼，敷衍過了)」

三十而立
「手頭上有30個defect的人，罰站！站到你把30個defect都fix完為止！」

四十而不惑
「甚麼？居然會有擁有40個defect的白痴！給我滾出來！你不明白我罵到你明白為止！出來！」

五十而知天命
「你… 甚麼？50個defect？哼！這是你的warning letter，你的前途命運，自己最清楚！」

六十而耳順
「60個… 人來先給他一封warning letter… 這… 你滾蛋是一定的了，不過算我求求你，你滾蛋前可以把defect fix一fix嗎… 40個，不！30個也好…」

七十而從心所欲，不踰矩
「老師！有人有70個defect，怎辦好？」
「70個！？哎… 算了，你跟他講，他喜歡怎樣就怎樣，別太過份就好… 哎，我不管了！」

Teacher Johnny的教訓
無視Issue Tracker的話，Teacher Johnny可是會生氣的喔！

近來MSN強迫user upgrade…結果MSN hang的次數多了，真是混漲。所謂的upgrade原來又不過是一堆產品推廣，真是討人厭。

說遠了，其實想說說IM bot。IM bot是甚麼？IM即instant messenger(MSN就是其中之一)；bot就是robot的意思。IM bot就是一個機械人，你跟它說話，它會作出相對的回應的。這些說話可以是一些閒聊(有一些閒聊專用的IM bot)；可以是一些資訊搜尋類(問問題，它會答你)；也可以是一些指令(例如Plurk有一個IM bot來接收指令的)，諸如此類。

從ICQ說起

ICQ！曾經一度大受歡迎的IM，但幾乎需要超過五分鐘啟動；contact超過400個就會當機，加上競爭對手相繼出現，基本上都被無情地淘汰了。

我人生第一個接觸的IM bot就是ICQ來的，說來大家一定不陌生，就是那種廣發咸網的那種煩人bot。有一天我手痕，對咸網bot的宣傳語句回應了回去，沒想到它竟然會繼續回答！我覺得好有趣，繼續跟它談話，發覺它的對答真是有板有眼，好神奇！在當時技術來說，這已經是非常了不起的bot AI了！要知道中文字多難啊，可以利用十多年前的技術對中文字作出回答，真驚人啊。

IM notification的觸發

早年偶然間看到Remember the Milk有一個IM notification的選項。Remember the Milk是一個管理工作的工具，當中的IM notification就是提醒你夠鐘工作了！我當時在想，這好易做啊，我也能夠做。於是便有自己做IM bot的想法。

IM RSS Reader - Anothr

在我真正想做IM bot的時候，我有過做RSS Reader的想法。就在此時竟被我看到Anothr。Anothr正正就是一個IM RSS Reader，還support MSN/Skype/Gtalk呢！當時心裏有氣，有種被搶先的感覺，決心也要做一個出來。雖然後來證明IM RSS Reader是失敗的…Anothr也收皮了…

MoliuSN出現

坦白說，IM bot在技術上不難，重點是可能性太大了。我就抱著「無聊試試看」的心情寫出了MoliuSN。這傢伙現時做到的主要都是資訊搜尋類型的，例如查股票(有段時間有即時報價的…)、中英翻譯、查看新聞等等…(當初是有RSS reader的，但其實那跟SPAM沒兩樣…)啊，其實自己覺得查股票跟中英翻譯還好用的啦，很方便。MoliuSN的重點是所有資訊都是來自公開的資源︰股票來自Yahoo!；中英翻譯來自Google；新聞來自各大報章。我只希望MoliuSN是一個方便使用者的平台，重點不在於其資訊而在其方便性。所以打工仔可以公然在辦公室查看自己喜愛的股票…

令人失望的Gtalk Translate

大約過了一年後Gtalk推出了GtalkTranslate。我當時心裏真是暗罵了一聲，「怎麼比我遲推出這麼多，比我做的還有點不如啊」甚至寫Blog罵它呢…

Plurk bot與IM bot

Plurk也有一個IM bot，叫Plurk Buddy。它的作用是notify你有人回覆過你的Plurk就會通知你，你也可以直接用Plurk Buddy去post Plurk，也可以下一些指令做一些個人設定之類的。

近來Plurk出現了一些Plurk bot，占卜啦、找youtube啦、post美女圖啦…我不知道它們是怎麼做的，但如果要我做的話一定是用IM bot去做，太易做了，寫一個IM bot去跟Plurk Buddy溝通就好了。原來還有這一招啊，Plurk提供了一個IM bot給你下指令，我就寫一個IM bot去下指令，變相就是一個Plurk bot了。值得參考。

一點點的小結

我還是覺得IM bot的可能性十分大，尤其在這個IM盛行的年代。我自己最起初的概念是，一個方便的平台，就像你的管家你的副官，你一言一語，一個指令，一個問題，你要做的事就解決了，你要問的問題就有答案了。不過後來又發現原來可能性可以有更多更多，就等時代來發掘了。

也談談IM client

看到Facebook的那個status的處理手法，其實不錯啊，share link、share video、share圖片，都只是在那裏輸入自動完成。IM client其實也可以這麼做啊，我send flickr給對方，直接就看到圖片怎麼樣？我send youtube給對方，直接在IM client裏播又怎麼樣？這些其實不難做啊？別老是讓MSN賣一些無謂的廣告，加一些無謂的function…

由於需要在Perl處理一些TimeZone的工作，考慮過一些系統存在的歷史因素，以及看看CPAN module的最後更新日期，最後選用了DateTime::TimeZone(其實沒得選，本來就在用)。看了一看，最新的release是2009年八月，還不錯嘛。這玩意兒聲稱自己支援Olson TimeZone(其實也只是lookup一個Olson Database而已)，好，就看看你有多威。

在這裏我用「Etc/GMT0」來做實驗，不用說，即死。對，不是throw Error，是die。在OlsonDB.pm第155行裏頭可以看得清清楚楚︰假如不支援這個TimeZone的話，他會die。

這裏我們清清楚楚的看到兩個問題︰
一、不支援「Etc/GMT0」，我們也可以假定部分其它的Olson TimeZone也不支援。
二、作為library實在不應該die。試想這是Java Library的話，我在Library裏頭有System.exit(0)你會覺得怎麼樣？die是可以catch的，但重點是不應該die。

現在看看Catalog.pm。原來那些Olson TimeZone都儲在這裏…在這裏又發現了幾個問題︰
一、Zoneinfo還是放在/usr/share/zoneinfo/比較好吧？
二、很不完整，幾乎全部的ETC TimeZone也沒有，甚至連GMT也沒有！
三、我看了src code，又看了網頁…很驚訝的發現，兩條TimeZone support list竟然是不同的呀~的呀~的呀…

另外，不說我還真不知道，原來有個TimeZone Mideast/Riyadh89 (GMT+03:07)，沒錯是GMT+03:07，或者更正確的說是GMT+03:07:04。這個時間是給Muslims用作計算麥加的natural sun time以作朝拜用的。原來如此原來如此。

真係頂唔順IT膠人，真係要鬧一鬧。以下用廣東話，勿怪。

首先，居然想叫特首去召開網上答問大會？駛乜咁煩呀？你試下叫特首上高登逛個圈留個言咪知結果囉。黃子華講得好呀︰「想知特首夠唔夠民望連任？你叫特首求其搵個大型屋村入到兜一轉，如果可以無事走番出來，你連任喇！」

仲有呀，個網上搞個答問大會？個系統點得來先？睇死你政府野都唔慌會用街外web2.0既野架啦，咪又係自己寫。想寫幾多年？(特首早就換左人啦！)用幾多錢？經唔經得起一眾網民既QA考驗？我發現到個系統有bug，會唔會告我不誠實使用電腦？而且慌你唔會搞埋D和諧系統呀？我保證無一條問題係鬧特首既！因為統統和諧哂！

好啦，正經野講完，講膠野…

丫，我仲以為譚膠人係想問特首「你識唔識用網絡語言同網民溝通？」呢句好合理，雖然我唔知特首答咩，但譚膠人竟然原來係想問「你會用中文定英文？」

救命呀！！！！！而家做咩呀？封建時代呀？八股文取士？識中英文就識IT？識中英文就可以統紿香港呀？

「請問特首會點樣管治香港？」「你係咪問我會用咩政策呢？」「我問你用中文定英文呀！」

最後…特首最後答果個答案…我仲以為佢講緊霸王洗髮液添…

我現在日日都在用，日日都用，我不是這樣落後，我正在用。
起碼我用了很~舒服
現在每天還在用呢！
還給曾鈺成用！
來來來試試看！

作為Web Developer，support幾個Browser這些基本要求就不用說了。不過相信各位都很有同感的是，MSIE(尤其IE6)是一樣乞人憎的東西，真是WTF…

JavaScript、CSS就不用說了，近來遇到了Form-Enter-To-Submit的問題，還真是慨歎一句MSIE奇哉怪也。

Form-Enter-To-Submit，簡單點說就是在一張Form內的Text Field或Password Field按Enter來作Form Submit。如果Form內有幾個Submit Element的話(<input type="submit"/>或<input type="image"/>)，一般Browser是會選擇Form內第一個Submit Element作Submit的。因此，假如要設定一個Default Submit Action的話，只需要很爛的簡簡單單放一個Hidden的Default Submit Element在Form內開頭的位置就好。

可是遇到我們偉大的MSIE就沒辦法了。經過細心測試，發現MSIE的Form-Enter-To-Submit有如此的情況︰

• Form內只有一個Text/Password Field，不會把Submit Element Submit上去。
• Submit Element不是User肉眼可見的，如加上display: none、overflow: hidden、visibility: hidden；甚至乎用position放到頁面以外的，鐵定不會Submit上去。(值得一提是Submit Element假如沒有高度及闊度，以及用一些iehacks的方法都算是「肉眼可見」的，不過有些Browser不支援這些東西，結果只會更煩而已)
• Submit Element在Load Time不存在的(即後來用JavaScript加上去)，不會Submit上去。

那麼何時會才把Submit Element Submit上去呢？如果有幾個Submit Element又會把哪個Submit上去呢？結論是︰

• 當Form內有兩個或以上Text/Password Field，MSIE會把第一個Load Time存在而肉眼可見的Submit Element Submit上去。(說完也不知自己在說甚麼)

如果要硬來的話又怎麼辦？以下是我這個豬腦想出來的方法︰

• Form內只有一個Text/Password Field，Submit Element只有一個︰加個無用的隱藏Text Field(不建議，好核突)，又或者加個跟Submit Element的Name及Value一樣的Hidden Field就可以。
• Form內只有一個Text/Password Field，Submit Element有幾個︰千萬不要用剛才加Hidden Field的那招，會令所有Submit都變成Default Submit Action的。唯有加個好核突的隱藏Text Field算了。
• Submit Element有幾個，但Default Submit Element卻不是第一個︰只好將Default Submit Element強放做第一個，然後用CSS作排位。

以上解決方法都十分爛，沒法子，Frontend不是我專長…歡迎意見。

最近公司來了一個新的Part time鬼佬，寫JS的，近來幫我的大忙著手搞Rich Text Editor(RTE)。

今天他走來向我說了一句︰「(翻譯)這個RTE用Table做Layout不好。」(順帶一提，這RTE我沒有碰過)

為甚麼呢？「If a blind person views the site, the screen reader will say “table cell 1″ and then there is no data inside.」

我聽完呆了，囧。嘩，堅，連盲人也照顧在內，我完全壓根兒沒想過！當時的感覺簡直是窩囊極了！完全是自慚形穢，一副被收了皮的樣子…我輸了！

但話又說回來…盲人用甚麼RTE呀…還用Smilies…可以讀可以寫明明就已經是天官賜福…

真的被收皮了。

this.uid = this.uid;

這是甚麼爛Code呀…基本上，拿著這句Code去見工，被踢出門口是理所當然的事。在公司寫這句Code，被老細炒魷魚也是很自然的事。

但這句神奇的Code解決了我的問題，簡直匪夷所思！

我用了Tapestry 5.0.14這個Framework。Tapestry很強調一件事，就是當進行Form POST之後Server會Response一個Statue Code 302，使Browser對自己進行Redirect。這樣做的原因是防止Ugly URL以及避免User進行Refresh Page時會重新做多一次Form POST的動作。

而Tapestry呢，每個Page都會有一堆Local variable，Life Cycle是一個HTTP Request。所以，基本上再進行Form POST到另一個Page後再來一個302 Redirect，那堆要POST過去的value是會死掉的(即Life Cycle完結)。

Tapestry對於Life Cycle的問題是以@Persist去解決的。對一個variable加上@Persist，就是說延長其Life Cycle直至永久，加上@Persist(”flash”)就是可以生存兩個HTTP Request，很明顯就是為了要把Form Data從一個Page帶到另一個Page去的(Form POST + 302 Redirect = 2 HTTP Request)。至於@Persist(”cookie”)等就不作討論。

前言完，而如圖中所見，現在我有一堆Object在Page A的Scope內。我希望由Page A進行Form POST到Page B，再由Page B Form POST回到Page A後，那堆Object還在。(注意︰中間過程那堆Object的Life Cycle有否完結我並不在乎，只要到最後那堆Object還是那堆value就好)

主要可以用Client-side或者Server-side的去解決︰

• Client-side
  • Form hidden field︰這是最常見亦最可行的方案。把那堆Object在Page B的Form裏用hidden field記好，然後再POST回Page A。不過首先那堆Object能否Serialize是首個問題(在我的情況是可以的，不過會費一番功夫…)，其次假如那堆Object是Dynamic(每次的Object數目、Type都不一樣)那也有一番麻煩。但總之是可以解決問題的方法。
  • Cookie︰根本不用考慮。首先同樣會有Serialize的麻煩(雖然@Persist(”cookie”)的話好像可以把麻煩丟給Tapestry)，其次我們無從得知那堆Object的容量有多大。總沒可能有10Mb的Cookie吧？加上Cookie這種隨意被User改動的東西基本上不能100%信任的，個人認為。
  • HTTP GET Parameter︰就是把整個Object放進URL裏。同樣有Serialize的麻煩，加上Ugly URL、URLencode等等麻煩…更容易被User改動，還有某些Browser對URL長度有限制，不作考慮。
• Server-side
  • Server-side-session︰就是@Persist了。由於@Persist(”flash”)在進行⁽²⁾302後早就死掉了，在⁽³⁾Form POST時根本幫不上忙。使用@Persist連把Object pass過Page B也不用，是最簡單的解決問題方法。只不過，他的Life Cycle是優點也是缺點︰他不會自己死！簡單點說就是要人手去控制那堆Object的Life Cycle(總不能一直Persist吧！？)，在複雜的System下還真是叫救命。加上User有些Action是Out of system control的，例如Browser refresh、手動輸入URL等等，要一併Handle的話，well…

最可行的方法似乎就是Form hidden field了吧。不過我還是死心不息的想搞Server-side-session。其實@Persist(”flash”)本來是最好的選擇，因為他自己會死掉嘛，如果@Persist(”flash”)能夠生存三個HTTP Request就好了，一切的麻煩都可以解決。在⁽¹⁾Form POST時的Object在⁽³⁾Form POST回去時還在，而且自行在Page B死亡，真好。

逆轉思考︰要控制variable何時死實在麻煩，但要控制一個variable在何時應該繼續生存，似乎就簡單多了。

又再細想︰@Persist(”flash”)的Life Cycle是兩個HTTP Request，然而是怎麼開始計算的呢？在這裏我就做了一個假設︰從variable被Assign value那一刻開始，variable可以生存兩個HTTP Request。

這就有趣了，所以我在⁽¹⁾Form POST完結後加上了一句爛Code︰

@Persist("flash")
private Integer uid;
...
this.uid = this.uid;

結果這個uid成功地由Page A pass過Page B，並且成功生存至⁽³⁾Form POST並在⁽⁴⁾302 Redirect中pass回Page A。這句爛Code的作用，就是令variable的壽命延長，達到簡單解決問題的效果。

好神奇！

昨晚在旺角的稻香吃火鍋，不幸地困Lift，被營救出來時還被職員罵我們亂按云云，真是莫名其妙。

右邊這幅老土到爆的圖就是那電梯的使用者介面的大概樣子。相信大家都不能不同意，這個使用者介面實在太簡單了吧。

就當是我們這群乘電梯的使用者亂按好了，細想一下，如果在一個只有有限輸入的使用者介面上亂按也會造成系統錯誤(就是困Lift了)，那麼這究竟是使用者的問題呢，還是設計者的問題？

簡單的介面，就是要易用，對象就是一群Dummy User，亦即猴子也懂得使用。試想猴子又怎麼會懂得何謂亂按呢？這好像在嬰兒玩具中放進手槍，然後責罵嬰兒胡亂選擇玩具一樣的笨。

話又說回來，我們可以常常看到電影中的政府國防機構裏，總會有一個很大的紅色按鈕，按下不外乎就是發射導彈，又或者是基地自爆之類的。好方便！我個人的感想是︰

• 十年也未必會發射一次導彈，百年也未必會自爆！這種使用率極不頻密的功能，要那麼方麼幹甚麼？
• 要發射導彈又或者是自爆，總要有一大堆複雜的設定才對，一個紅按鈕就能做到這麼神奇的功能嗎？導彈要射向哪裏？基地幾秒後自爆？如果是有額外的設定介面的話，那這個紅按鈕的作用又是甚麼呢？
• 簡單的介面就是要易用，對象通常都是比較沒那麼聰明的。難道政府高級機關入全都是白痴嗎…
• 回歸主旨，這個簡單的紅按鈕，如何群免使用者亂按的問題？(這個紅按鈕的吊詭情況跟電梯內有一個「困Lift」的按鈕一樣的詭異)如果說使用者都是一群很Advanced的用家，那麼又為了甚麼而設計一個簡單易用但又無法做設定的紅按鈕呢？

畫公仔懶得畫出腸了。每天都在設計UI的人當然會明白這簡單的道理(真的很簡單，我自己也猶豫寫不寫這篇文章)。當然，簡單易用(User-friendliness)也不一定只能做一些簡單的工作，不過，一定有取捨。另外，既然是簡單易用，那就對Robustness要有很高的要求才行，不然就只是在設計一個易用的介面去摧毁系統而已。

想要用一個紅按鈕就能精確對某地點進行定位，並完美地通過各項最後檢查，然後自行倒數發射導彈，還能夠防止任何錯誤輸入，這在現階段來說，我想還是一個痴人說夢話的夢想。

當然，我舉的例子也太極端了。