人生如何評量？

之前 William 寄了一篇文章 “幸福課“ 給我，看了真的覺得很有感觸。

的確評估企業我們就應該用錢去評量，相對的人生就要用幸福快樂去評量。我完全同意人生是要用幸福去評量的，也終於懂為什麼很多時候被人問一些問題時我根本答不出來。答不出來不是因為我沒答案，而是答案不被提問的人接受，價值觀完全不同，我沒有更好的答案可以讓他們接受我的想法了。大家常常不自覺的用錢去評量人生，幸福很難被量化，金錢容易多了，而且比評量人比評量企業還不客觀，大家都只看收入不看支出 (？)。

另一個讓我很認同的觀點是，大家都習慣認為快樂必需付出痛苦換取，好像只要後面能有一點點快樂，再苦再痛都值得？在華人圈更是很多古人的故事都一直提到必需要 “吃得苦中苦，方為人上人“ 只不知這些人上人是幸福還不幸福就是了。幸福課的開課者在得到比賽冠軍卻沒有感到真的幸福，看來別人認定的成功也未必就是幸福。努力是必需要的，但因為要努力就不幸福好像就有點太超過了。

評量人生也許有很多觀點，但至少我相信，用財務報表來評估人生絕不是唯一的路，而且財報是一條讓人快樂不起來的路。不過幸福快樂怎麼評量真的很難，很考驗人的智慧。不過應該不會是填幾題問卷就決定誰快樂誰不快樂吧？

Google App Engine – 新時代來臨的震撼

Google App Engine (GAE) 月初在公開發表，announce 的那幾天每天都佔據了各大技術網站的版面。一個全世界都在看，全世界都在玩的產品，一定有它獨到之處，當然一定要來研究研究。Download 了 SDK，試著開發了一個簡單的程式，其實我對 python 並不熟，加上對 Django 一無所知，但卻不會覺得開發很困難，反而覺得比開發 Java 還要快還要順。雖然使用 GAE 的經驗很淺，不過 GAE 給人一種新時代來臨的感受。

在 Business model 方面，其實有太多太多的討論跟介紹了，一定很容易找到。會覺得是一個新時來的來臨，不是因為這是一個可以跟 Amazon S3 / EC2 對抗的 service，而是在開發技術上面 GAE 也做了一些突破。

跟 Java web development 比較起來，GAE 在開發上讓人覺得最驚艷的地方就是修改 code 的 feedback 速度。一般的 Java web development 在修改 code 之後，需要 compile -> deploy -> restart web container 才能看到修改，但使用 GAE，基本上你的修改馬上可以 apply，沒有 compile、沒有 restart server。這個說法也許有點落伍，很多人馬上就會想到 Ruby on Rails (RoR)；也有人會想到這不是本來 Python + Django 就有的能力？就算是 Java 界，Groovy / Grails、JRuby 等也可以做到同樣的事情，何必大驚小怪呢？

GAE 當然不是只是拿 Python 跟 Django 出來騙騙小孩的玩意，真正強大的就在 Big Table 的部份。不要問我 Big Table 是什麼，我答不出個所以來，但站在 GAE developer 的角度而言，沒有 DB 這個東西。使用 GAE 在開發時，你的 code 中的 domain model 就是唯一的 model，沒有 DB，也沒有 DB schema、版本等問題。修改 domain model 的 code 馬上反應在下一次執行裡。GAE 的 domain model code 建立在 Django data model 之上，用起來很方便，類似 RoR 的 Active Record，但是少了 DB 的麻煩。

即使使用 RoR，在 domain model 上還是有得頭痛，因為 DB 的 schema 如何跟 code 裡的 domain model 保持同步就是一個大問題，一般 DB Migration 可以應付這個問題，在 domain model 改變的同時，準備一段 migration 的 code / description 就可以讓開發架構幫你把 DB 改到同一個版本。在 Java 也有 liquibase 可以做到這件事。但免不了要下去改東西，更嚴重的是，這個修改很可能沒有辦法即時反應 (至少在 Java 應該還是免不了要 compile -> db migration -> restart)，所以又掉回了比較慢的 development lifecycle。

那麼用 Big Table 有什麼 trade off 嗎？有的，就是大家熟悉的 SQL / relational model 等等武功全廢。雖然 GAE 提供了一個叫 GQL 的東西，語法類似 SQL，但沒有 join 等等在 SQL 裡威力最強大的功能，思考也不宜使用 relational model 去想你的 data，因為這樣會完全想不通要怎麼辦。會不會有什麼事變成做不到了？我想有可能，但絕對不會太嚴重，因為絕大部份講究 OO 的 code 本來就很少直接運用 relational model 在操作，所以才有 OR mapping 的出現。如今 GAE 一不做二不休使用了 Big Table，除了宣示它在 scalability 上舉世無雙以外，也帶領 GAE 的 developer 進入一個新的時代，一個不去用 relation model 思考的年代。

我不是花了很多的時間在 GAE 上，寫進階的系統會不會出問題我沒有辦法知道，但以基本 web 常見的功能而言，很容易開發。Big Table 完全不會影響到我的思考，反而在 development lifecycle 上給了很大的進步，幾乎所有修改都能馬上看到 feedback。Agile development 中，fast feedback 佔了很重要的一個地位，愈快有 feedback 代表了開發的速度愈快。拿 Java 作比較，在 code 的修改上 Python + Django 的 feedback speed 就已經快了一大段，再加上 Big Table 又勝過了所有使用 DB 的 solution (包括 RoR、Django、Grails and JRuby 等等)。這個開發速度上的震撼讓我一直在想，用 Java 開發 web 是不是已經過時了呢？在 GAE 的範圍以外又如何去趕上這個突破，跨入這個新的時代呢？我想世界上有其他更多的人已經在想這個問題，新的工具、機制我想很快就會出現，open source big table 的技術也慢慢的浮上來了，新時代也許會靜靜的到來。至於這個新的突破跟誰會有關？是不是只有如 Google 般大的公司才適合用 Big Table？這個就留待日後驗證好了。

Spring framework 市場持續擴大

SpringSource (以前為 Interface21) 接二連三在市場上有大動作。

首先是推出認證機制，通常能夠推出認證的都應該是市場上比較主流的技術，而且能夠被多數人所學習的。而且認證對於教育的市場有非常大的相關，也代表了將會有更多更多的人學會 Spring framework。

第二是在 SpringSource Team Blog 上公佈了 Spring framework 與 EJB 工作職缺的比較，內容發現了：

1. EJB 職缺需求持平
2. Spring framework 需求大幅提升
3. EJB 與 Spring framework 總需求有一定幅度的成長

這點正好呼應了為什麼 SpringSource 敢推出認證機制。

最後就是今天的新聞，SpringSource 買下 Covalent，Covalent 是一家做 Apache HTTP server 或 Tomcat 等等的技術顧問公司，也有在推 Terracotta。技術顧問公司本身沒有產品，SpringSource 買下來主要一定是看重它在市場上推廣技術的資源，而且有顧問公司，也可以更有力的深入企業客戶。

以往 JBoss 也是走顧問導向的方式，SpringSource 也走向這一步，是否能夠比 JBoss 的顧問方式做得更成功呢？ 如果 SpringSource 真的能夠再把市場擴大的話，就很有可能成為 Java enterprise development 的必要條件了。也許真的有那麼一天，所有的 Java developer 幾乎都會使用 Spring。當然到時會 Spring 也就不是什麼了不起的事情了。不管是不是真的有那麼一天，Spring 在市場上繼續擴大是沒有問題的，就技術而言，Spring 有很多替代品跟競爭者，但就市場面去看，Spring 目前是沒有什麼對手呀！

Xuite.net Personal Portal 的新風貌

最近連上 Xuite.net 會發現首頁又有了新改變，這個 personal portal 的首頁進入 Beta II。如果有使用過 Netvibes, iGoogle 等服務的人當然不會陌生。國內對於 personal portal 的做法一向很愛用鎖國政策，portal 上的元件再怎麼設定都只讓客戶連到自己的服務，對於外面的服務大都不願提供連結方式。Xuite.net 在這方面就好多了，有 RSS component 可以連結外部，至少有達到一個 personal portal 的最基本要求。版面可以自由拖拉設定，新增 tab 等等。每個 tab 能有自己的 layout 以及背景的設定，這點是很多國外的 personal portal 也沒有的。

另一個比較特別的地方是它有一個 public 的個人首頁。 一般的 personal portal 只能由 portal 的 owner 連入去，而 Xuite 提供了一個個人首頁的機制，可以讓別人連進來看到你所設定的首面。這個算是一大特色，算是結合了國內很多個人網站以及國外 personal portal 兩方好處的一個想法。至於日後有什麼發展，就要看能夠提供多少吸引人的元件了。

不要放棄學習之心

學習是進步的來源和動力，而人其實都是好奇又有學習心的。但在環境的影響之下，都漸漸變得現實。現實的確是眼前最需要解決的問題，但如果太過於現實，就會變得很急功近利。

如果在看到一件事物時，不要單單的問我們能不能用或是可以用來做什麼，而是去欣賞它的優點，去了解它背後的原因，再來看是不是適合拿來用，那應該會有更好的效果。有些事是急不來的，而且絕對不可以放棄學習之心。很多人都會投資，也知道長期投資的成長力道是非常可怕的。如果把學習視為一種長期投資，常常維持了解視物背後原理的心態，那長期下來，會是指數成長的。

一旦急功近利，大概都只會看到事情的表面。是美侖美奐的外表在吸引人嗎？也許是貼近人心才真正的吸引人。堅持自己的信念，相信只要不放棄學習之心，一定可以做得更好的！

Blogged with Flock

香港機場 Cathay Pacific 的無線網路

這趟旅程帶著我的好戰友 – 我的 Compaq NB，在桃園跟香港的機場都有拿出來試一下能不能當個 WiFi 乞丐。當然啦，乞丐是不挑食的，倒也沒有說非 FON 不用。在桃園機場，只有中華電信的 WiFi 可以使用，雖然如果要付費還蠻方便的 (對台灣人而言)，不過實在沒有付費上網的必要，當然就不會去用它了。而在香港機場方面，一連上預設當然是 PCCW 的網路，同樣需要付費上網，我一時也弄不清楚要怎麼付費。不過搜尋一下無線網路列表，卻找到一個 cathay 的 access point。二話不說一連，果然接上了！不愧是 Cathay Pacific，大方提無線網路給人免費使用，我猜應該是在 Cathay Pacific 固定的候機區才會有訊號，不過這倒是一個很不錯的服務。

有時候腦筋可以不用跟那些斤斤計較，秒秒計費的電信業者一般見識。提供一些無傷大雅的免費服務是很讓人貼心的。畢竟從小處就能知道公司對顧客的用心，顧客導向不是用講用喊的，是用心去做的。

technorati tags:WiFi, CathayPacific, HK, HongKong

Blogged with Flock

在香港的一po

第一次帶著 NB 回香港，打開 WirelessLAN，不出所料，出現一大排可以連的網路。然後就開始一個一個試，果然還是有可以連上網路的機會。雖然連了一下又被斷掉了，不過還是斷斷續續的有上線了。當然如果是住飯店就不用這樣偷用啦，在完全沒得用之前，還是必需要給他 po 一篇留念一下的啦。

無線網路，加上 Web 2.0 的各個網站，以及 MSN。去到哪都是一樣呀~ 我的 Netvibes、Flock、MSN 等等照樣如常運作！！

technorati tags:香港, HK, HongKong, WLAN

Blogged with Flock

點閱破萬心得

不知不覺本 Blog 的 W3 Counter 居然已經破萬了，而 WordPress 的 BlogStats 計數器也快要 1.5 萬了。雖然一陣子沒有寫新的文章，但部落格觀察仍在 400 名左右，比起 300 名的門檻沒有很遠。

以前在系上的 BBS 站有經營過一個技術討論版，隨著自己畢業，認識的人畢業，該站上沒有人知道那個版是幹嘛的，也就廢版了。現在的 Blog 放在 WWW 上，加上有 RSS feed，每天就有固定的人潮，也可以由 Google 等搜尋引擎找到這裡。比起 BBS 的固定的客群，WWW 的確是比較流通的地方，當然像 ptt 等 BBS 大站的人潮流通率可以跟 WWW 比較。

其實相對於點閱率，部落格觀測的指數更有參考價值。因為他分析了這個部落格在網路上的重要性，使用了 Technorati 等等的指標，算是很客觀的指數。漸漸的，Blog 的分析也比以前來得仔細，除了一些知名的排名網站以外，還有一些針對文章格式的易讀性等等做分析的工具，而且我認為這些分析指標還在發展中，日後一定有更多的部落格分析工具。

行文到此，照例吐一下無名，雖然在 Alexa 排名在全球 25 (2007/1/6 中午資料)，不過那個流量跟點閱率並沒有辦法反影該站的重要性。無名站內也沒有提供很多分析工具，這點跟國外很多大站真的差多了。其實一個 Blog Service Site 的重要性也許可以用站內所有 Blog 的分析加總或平均來分析。雖然這樣評比無名還是很有可能會在很前面啦，畢竟方文山的 Blog 在無名 (Technorati Top 100 唯一個一台灣的 Blog)。如果仔細思考無名的流量跟重要性指標，不難發現，流量其實可能不能直接代表任何事情。

最後，無名小站你嘛幫幫忙，在 Alexa 上的 Top 100 唯一一個說明是亂碼的 (簡中、日文、韓文、連阿拉伯文人家都正常顯示呢！)，都 2007 年了，請用 UTF-8 吧，很丟臉呢。

technorati tags:無名, Wretch

重拾 Unified Process – 別讓自己書到用時方恨少

在資訊科系裡，大家或多或少會上點系統分析之類的課。也許上課的時候會想，這些東西以後真的用的到嗎？也許不會用到，也許不知道什麼時候突然要你用出來。

最近因為工作的需要，居然把 Unified Process (UP) 的聖經本拿出來用了，這真是意想不到的事情。我本來以為那本書應該會是供在書架上，閒來沒事拿下來擦一擦灰塵，順便模拜一下三巨頭作者們的偉大 (偉大到需要二門 3 學分的課才修完整個 UP)。沒想到居然要把三巨頭的書請去公司，哈哈。其實需要把書請出來也不是什麼光榮的事，代表自己對書中的內容還不夠熟練。不過既然在負責一些需要做事有依據的事情，那不把三巨頭請出山來鎮壓一下是不行的了。除了Unified Process，還請了一本 UML Components，同樣是一本 UML 方法論中的經典之作。加上一本最近同事介紹才去買的 Analysis Patterns，三本書都算是舊書了，大概都有五年以上了，Analysis Pattern 更已經有十年之久了。

我先是興幸自己當年一咬牙去修了一門 UP 是對的決定，因為如果沒有修的話自己看 UP 要看懂真的要花很久很久。再來就是想到，自己看的書居然是人家在多年前已經寫好的，那代表了自己在軟體工程方法論的層面居然落後了十年之久！多麼可怕一個發現，十年！很幸運的，我所念的研究所有 UML 的課程、還有更進階的 UP 可以修。這些課在學校真的不多見，職場上很多人都很訝異我能在學校修到這種課。這個機緣，讓我至少還看得懂人家十年前寫的東西，而不用在十五年或二十年前的東西慢慢爬回來。

工作之後，要能做學生一樣，從完全不懂到慢慢弄懂，機會不是很多，時間也不長。你永遠不知道什麼時候會需要用到什麼技能，但是如果看到一些難得一見的課，大概都很值得去修一下，別讓自己書到用時方恨少。

technorati tags:UnifiedProcess, UML

Blogged with Flock

Web 2.0 的台灣奇蹟

全球 Web 2.0 的風氣一直燃燒下去，台灣呢？

在台灣，Web 2.0 似乎只是一個口號，一個徽章。各大雜誌都先後以封面故事報導過 Web 2.0，在很多的文宣、標語中也看到 Web 2.0 的字樣。很多站台都號稱自己就是 Web 2.0 或是運用了 Web 2.0 的觀念。一些教育中心也打起了 Web 2.0 的旗號，推出以 Web 2.0 為號召的課程 (我很好奇誰教？教什麼？)。

每次看到雜誌的封面故事出現 Web 2.0，都忍不住要拿起來翻一下。很可惜每次都讓人失望，不知道是為了讓大眾讀者能比較好理解 Web 2.0 還是什麼原因，雜誌對 Web 2.0 的解釋都太過保守。Web 2.0 的各種解釋下，其開放、串連等等最有價值的觀念並沒有被詮釋出來。所謂開放是指使用開放的標準、架構，並提供開放的 API，從而讓使用者的使用管道多元化。串連是指利用開放的 API 串接各個不同的服務，或是讓自家的服務能與別人做更好的串接。單單上傳個文章、分享一些影片，就號稱 Web 2.0，那 ptt 應該就是 Web 2.0 台灣的龍頭了吧。

不過，論 Web 2.0 在台灣所開出來的市場居然不在網路上，而是在雜誌、行銷以及教育，這點倒是 Tim O’reilly 等人也始料未及的。或許，這個超越網路、超越限制的市場創造可以稱得上是 Web 2.0 的台灣奇蹟了。

technorati tags:Taiwan, 台灣

Blogged with Flock