Posts filed under '新鮮事'
Openkapow – 夢幻 mashup 工具
自從 Web 2.0 興起，國外網站的 mashup 大行其道。不過要自己去做 mashup 一直以來都不是件簡單的事，除非 service provider 本身就有提供夠強的 api 才會比較簡單一點。這也是我一直認為 Web 2.0 的網站應該要主動的提供 api，讓別人有機會去 mashup 你的 service。但國內各種 service provider 自然是不會想得這麼開了，幾乎全都是以鎖國政策以保護自己的廣告收入。歷史的教訓尤在眼前，鎖國政策可以長久嗎？自由與創意無限的網路世界，又怎麼會止於鎖國政策之前？只有提供使用者真正需要的內容與資訊才是長遠之計。接下來介紹一個可以把網站做成 mashup api 的工具。
TechCrunch 最近有一篇文章：5 Ways to Mix , Rip, and Mash Your Data，比較了幾個做 mashup 的工具，包括了剛剛推出很有名的 Yahoo! Pipes。而其中最強大的，就是 Openkapow，它的 mashup service 由一個 robot 的製作工具以及一個 hosting service site 所組成。使用者下載以及安裝它的工具之後，可以在本機開發出 mashup robot，再把 robot publish 到 service site 上分享給大家使用。雖然 robot 只有 publish 出來才能使用，但是對於 Web 2.0 的精神來說已經很足夠，不一定需要能在自己的控管範圍之內。Mashup robot 的型態分為：RSS/Atom、REST service 以及 Web clip，RSS/Atom 的 mashup 應不該不用多說了，把沒有 RSS 的網站做出 RSS。REST service 就是常見的 web services 模式，簡單的開發工具可以吃進一個網頁、輸入資料、頡取輸取。完全破解了沒有 mashup api 的網站，鎖國政策至此被強逼開關。而 web clip 的功能應該是 kapow 的老本行，把網站的一部份取出並存下來留作後用。雖然要下載工具，但工具簡單易用，加上 REST service 這個觀念正常的做法，讓 openkapow 發展出很多的可能性。
在mashup 工具日漸成熟之後，鎖國政策愈來愈不切實際，畢竟在資訊爆炸的時代，每個人都只想關心自己想關心的事情。使用 Openkapow 時快速上手的感覺讓我覺得 mashup 界的夢幻工具已經出現，破解鎖國政策的工具也已經出現，不管 service provider 是否願意，接下來 mashup 會愈來愈多，使用者為了單一事件到單一網站的情況會降低，個人化、而且可以由使用者群的意志去加強功能的系統，應該會愈來愈常見。或許不久之後，國內的 service provider 會對 Web 2.0 有新的定義。
technorati tags:Openkapow, RSS, Atom, REST, webclip
Blogged with Flock
5 comments March 8, 2007 (Thursday)
Shelfari 書架 — 個人書籍管理
念碩士班時，有個半路出家的同學問過我，有沒有程式可以管理個人的書籍。我當時是說，好像是沒有，但要寫也不難。她就一直很想要自己去寫一個，因為她的書實在多到不像話，超出能控制的範圍，書借給誰、有什麼書可能都要程式的幫助才行。
Web 2.0 的興起總是帶來很多驚喜，也許我已經太後知後覺了。Shelfari 是一個個人的書籍管理系統，user 在上面建立自己的書籍王國，只要在書架上一本一本加入你的書籍就可以了。而書的資料其實不會輸入到手酸，因為資料是由 amazon 取得，只要用書名等等去找就好了。加入之後，在個人的書架上，就會一本本的陳列在上面，連封面的圖都有！書籍的各種資料應該都蠻齊全的，而且也可以加入個人對書籍的資訊，比如說書什麼時候買的，什麼時候讀的，借給誰等等。每個人的書架，還可以細分 reading list、wish list。在書架上的書籍可以加 tag 、加書評、提出問題、直接連結 amazon 購買。書架上的書也可以做 import/export。
Web 2.0 網站不能免俗的總是要有 community 的概念，Friends、Groups 自然不會缺少了，Groups 的型式可以想像為讀書會，這點蠻不錯的。如果你是在看別人的書架，當然也可以留言給對方。跟你有同一本書的人在 Shlefari 上很容易找到。有最多書的人、寫最多問答、書評的人也會列出來。
總體而言，Shelfari 的功能並不強大，但簡單精準，操作容易。跟 amazon 結合的好也許是它的一項優勢，我沒有詳細研究其他像 LibraryThing 做得如何。但概念簡單好操作，貼近使用者的需求，而且不用輸入一堆東西才能建立書籍是一大優點。目前最大的缺點就是中文書好像沒有辦法找到。如果你也有很多書，交給書架去幫你管理吧！
technorati tags:Shelfari, Book, Amazon
Blogged with Flock
1 comment February 27, 2007 (Tuesday)
JBoss Rules (Drools) 的發現 – 以大廠手法玩 open source?
前幾天剛好有談到 JBoss Rules，才在想說 JBoss 哪時候也這麼先進，連 rule engine 都有了。之前的印象 Java open source 最有名的 rule engine 應該是 Drools 才對呀。結果，原來 JBoss Rules 就是 Drools … 很顯然在場的人功課都做不夠，外人不清楚就算了，做介紹的人也不清楚就讓人笑話啦。
話說回來，JBoss 已經從主打 AP server 完全換了一個樣子，上面應有盡有，連 Enterprise Service Bus (ESB) 的 solution 都快要推出了。只是這一下子推那麼多產品線，除了 JBoss Rules 這種買下市場上最強產品的做法，其他的要應付那麼多本身已經很專業的產品 (像 JBoss Portal vs Liferay)，JBoss community 是不是有這樣的 power 呢？
其實這又引出 open source commmunity 怎麼玩，是要用大廠的併購手法把自家的產品線變廣，還是沒必要做這種事呢？這個其實我沒有什麼答案，但如果是一個 business lead 的 open source，那也許已經失去了 open source community 的正真意義了。即使是 business product，很少有 user 是全部只買一家公司的產品的，因為大家都想說不要把蛋全放在同一個藍子。Open source 的 user 大部份都會有能力去判斷一個產品的好壞，而 open source 也沒有價格的問題，所以選擇的時候幾乎是產品的成熟度、技術的合適度以及 Community 的大小來做決定。這樣的情況下，何不把一兩個產品做好，而突然大開戰線呢？
套句五洲製藥的廣告詞：「有好的產品才有好的商標，有好的商標才有百年企業」，Apache 底下其實一堆 project，但不少人一聽到 Apache 就只知道是 HTTP Server，一個十年來無人能敵的產品。JBoss 就是 open source J2EE AP Server 的代號，如同大家順口說”寫 JSP 要灌 Tomcat“，”寫 EJB 就要灌 JBoss”。產品多元化是好事，但 open source 畢竟是貴精不貴多。再說 JBoss 在 AP Server 中永遠是被大廠拿來當炮灰或對照組用的，地位跟 Apache HTTP Server 可差多了。
technorati tags:JBoss, Drools, J2EE
Blogged with Flock
3 comments August 20, 2006 (Sunday)
台灣不再是 ACM 強國
商業周刊 970 期其中一篇講到台大學生在 ACM 國際大賽中不敵中國大陸，看了真的蠻有感觸的。「台灣科技島的美名 靠 3 個台大生撐著」，台灣只有一隊進入世界賽，大陸光是得名的就有十一隊。1997 年的 ACM 大賽得獎隊伍以美國為首，台灣勇奪第四。2006 年得獎的為首是俄羅斯，接著是東歐國家以及中國大陸為主。這幾年東歐國家、中國大陸以至於韓國，都以國家力量去訓練人才，當然已經今非昔比。
如同商業周刊所說，很多國際大廠都看著這些得獎者要努力爭取他們到公司工作。ACM 代表的是演算法的能力，也就是資訊技術的研發能力。台灣的電腦科技一直在世界上有一屆之地，當年 ACM 大賽取得佳績，後來也一直都有好成績，證明了台灣在這個項目一直都很有機會做得比別人好。只是當別國努力訓練選手時，政府又在幹什麼呢？台灣在基因定序解碼上一直是技術蠻強的，跟有很多能在 ACM 大賽取得佳績的優秀人材絕對有關。如果台灣以後都沒有在 ACM 大賽裡出頭，那麼下一代的生物資訊科技也不用談了，因為根本就沒有足夠的研發能力去創造演算法。
會這麼有感觸，其實是因為當初自己也參加過兩屆台灣區的校際 ACM 賽事，當年是因為系上老師號召學生參賽，我跟幾個同學﹝不怕死的小大一﹞就說好，我們要去比看看。講實在話，以我的程度，根本就不是比 ACM 的料，但學校也沒多少人要參加，就當作去玩吧。比賽是三個人一組只有一台電腦，時間是 5 小時，題目大約 6 ~ 8 題左右，只要解出一題就會得分，但得到的分數隨解題時間的長度遞減。答對的定義就是程式可以跑過所有測試資料，但資料只有評審有。當初 60 隊參賽，我們那組，不小心給它答對了一題，就已經砍掉 30 隊了。而台清交永遠都是這個比賽中的強手，每年去都看到清交兩校的人一題一題的解，而我們就只有在那抓頭苦叫的份。台灣參加 ACM 世界賽的選手就是這樣打敗其他學校的人一路殺上去的，但這些人去到世界賽就會遇到更強的人，題目更難，情況可能就跟我差不多了吧。所以如果中國大陸每年都有一堆人進入世界賽而且得名，那可以想見他們國內是有多少有能力在這方面發揮的人呀！而看到那些超越我自己很多的大學生，去比世界賽居然輸中國大陸，也實在感到自己在這個領域實在差別人差太遠。
政府常說什麼要讓台灣走出去，如果在世界賽中都看到台灣的名字不是很好嗎？ACM 參賽是用校名為主，付地名，也就是說，如果得到冠軍就會出現 xx University, Taiwan，這可是不會被中國大陸要求改成中華台北的比賽，為什麼不要多投資源呢？
technorati tags:ACM
Blogged with Flock
1 comment June 29, 2006 (Thursday)
AJAX 掀起 Javascript 的戰國時代
AJAX (Asynchronious Javascript And XML) 已經紅了好一陣子了，最近看到一些公司在畢業學生班版 po 的求職廣告居然也出現了 AJAX 這個字，還說熟 Web 2.0 尤佳，雖然那間公司是在做 CIM 的。CIM 需要用 AJAX？CIM 用 Web 2.0？我不予置評，不過很明顯的，AJAX 已經被人重視，相對的，Javascript developer 的需求會提升。
說起來，developer 都不滿足於只用 language level 去開發，因為事實上那是永遠都不足的，需要一些 component 或 framework 提升 developer 開發的效能。就因為 AJAX 的出現，最近 Javascript 的 component / framework 推陳出新，要選一個來用還真不簡單。
介紹評比這些 framework 的文件也很多，其中寫得不錯的有以下兩篇：
Seven Ajax Frameworks / Toolkit to watch out for
The JavaScript Library World Cup
第一篇裡面的 1, 4 兩項嚴格來說不算是 Javascript library，扣除之後，跟第二篇幾乎一樣。所以不難想像 Dojo, YUI, Mochikit 跟 Scriptaculous 可以算是 Javascript library 的前四強了。在這裡要評論哪一個比較好其實還太早，因為其實每個的出發點跟對象也不是完全相同。但是可見的是，好幾家大廠都對 Dojo 做了一些投資，原因很簡單，Dojo 的方式最合符大廠使用完整 framework 跟 IDE 的模式。另一個有趣的東西，就是完全不是主打 developer 的 Yahoo 跟 Google 在這波出現了，以前都是 IBM, Oracle, Borland。最後，就是上面完全看不到 M$ 的影子。M$ 會有什麼打算呢？照慣例從後趕上嗎？會使用 VBscript 還是 Javascript？還是繼續沿用 win form / web form 的方式變成 IDE 的內建元件？
Javascript 的比重加強，這年頭要寫個 Javascript 也得好好選用元件，絕對不能上網 copy 一下亂貼！而同樣是 Javascript，由 art design 的人出手跟由 developer 出手的結果很不一樣，也各有優缺。以上有哪一個 framework 可以想出一個漂亮的解法解決 art design vs developer 的問題呢？
AJAX 讓戰國再起，誰會一統天下？W3C？M$？還是會像以前的 Javascript 一樣，亂到在anti-pattern中出現然後泛人問津？
technorati tags:Dojo, YahooUI, GoogleWebToolkit, GWT, YUI, Mochikit, Scriptaculous, Prototype
Blogged with Flock
2 comments June 20, 2006 (Tuesday)
AJAX 技術應用在 Worldcup 2006
這次第一場看的比賽是今天英格蘭對巴拉圭。對於台灣的球評還是不太滿意，不過在沒有選擇的情況下也只好認了。四年前在埔里租房子，電視在一樓，電腦在二樓，沒辦法一邊看球賽一邊用電腦。這次就不同了，看到球評不怎麼樣，就想說上 Worldcup 2006 的官網看看或許有些好玩的東西也不一定。
一進官網就有正在比賽的比數，旁邊有個小小的 Live 的 Button。點下去之後，就跳出一個小視窗，不出所料，果然是個好玩的東西。視窗的樣子就長這樣：
有什麼特別的呢？這個 page 是由 Flash 做的，兩隊出賽球員跟比數等等所有你想要的資料在上面大概都找得到。中右方那塊大塊一點的區域，有比賽即時狀況的文字解說，雖然只有射門、犯規、罰球等等狀況的說明，不過這樣搞不好已經比台灣的球評講得好了(香港的球評可是連戰術、技巧都可以評論的)。同一區塊的另一個 tab 是一個簡單的聊天室，大家可以馬上發表意見。至於上圖看到的是 Man of the Match 的 tab，那是比賽結束後才出現的。好玩的是，比賽快結束的時候，聊天室出來一個 FIFA Editor 問大家覺得誰是 Man of the Match。我想這些聊天室上的回答應該也不至於影響 FIFA 專業的判斷啦，但是的確是上面大部份的回答確也真的跟最後出現的結果不某而合，想來聊天室上的觀眾水準也是蠻高的。
我覺得這個整合的介面還不錯，至少該有的都有了，使用 Flash 在 backend 更新，可以說是廣義的 AJAX 技術，不是很難想像的應用，不過也看得出來算是有用心了。在全球這麼大的流量下也頂得住，這點的確是 Yahoo 可以自豪的地方。本來是有點期待可以更炫的啦，例如用 AJAX 做一個小小球場的圖，每位球員的位置是一個點。然後像共同畫圖一樣，讓你知道球員跟球的動向。哈哈，意想天開啦，這樣的流量或許沒辦法做這種事啦。
technorati tags:Worldcup2006
Blogged with Flock
Add comment June 10, 2006 (Saturday)
Flock version 0.7
Flock 出了新版囉，這版看起來又更完整了一點。
一些中文會有問題的地方有改進了，雖然還是沒有完全改好。
其實沒多少新功能，主要是使用性上的改進。
多了一個 News 的功能，可以加入一堆 RSS。
可惜我有在用 Netvibes，所以用不到啦。
Blog Post Editor 有不錯的改進，支援的 Blog 跟 API 都有增加，
也用成 JavaScript Rich Text Editor 的樣子。
其他除了畫面上的改進，大都是增加功能的整合廣度，
看來方向是對了，Web 2.0 Browser 看來慢慢走出跟 Firefox 的差異了。
Keep on Flock ~ !!
technorati tags:Flock, Firefox, Browser, 瀏覽器, Gecko
Blogged with Flock
Add comment June 9, 2006 (Friday)
泡沫化 2.0 – 當 Web 2.0 被套到葡式蛋塔的模式裡
Web 2.0，本年最 hito 的話題，有些人知道什麼叫 Web 2.0，有些人不知道但天天在用。這 Web 2.0 的浪潮自然是源自國外，台灣好歹是亞洲區資訊龍頭之一，怎麼可以在這一波缺席呢？亞洲跟西方國家有很大的文化以及語言的隔閡，這對本土資訊服務也許是一個機會，我們不需要是世界第一，也不需要想破頭要做什麼，把國外的模式 localize 就是一個不錯的方法了。
看到國外這一波 Web 2.0，國內 portal 大戶的 pchome、yam 等怎麼可能放過這個機會，當初他們是入口網站的大哥大，但不知道哪天開始，大家查東西用 google，愛寫 blog，愛貼相薄，無名就冒了上來。yam 全力推行 Web 2.0，不過沒看到什麼具體的產品。PChome 強打 Portal 2.0，裡面一堆掛了 2.0 的服務，很明顯想要順這一波浪來重新洗牌一次。Yam 的東西我沒研究，PChome 剛看了一下，就服務而言，換湯不換藥，連皮都沒換，只是多套件 Web 2.0 的外套而已。而個人化的 Portal，倒是用了一個跟 Netvibes 有 80% 相似的介面，當下是嚇了一跳，難道 Netvibes 跟 PChome 有合作？雖然如此，但 PChome 跟 Netvibes 差那 20% 就是要命的地方，PChome 能加的服務都是它自己體系內的東西，我連個 RSS 都看不到在哪加入。或許是我走馬看花看走眼了，只是可以確定的是，我第一次用 Netvibes 就沒看走眼。
說這些東西有多少技術多難我不相信， PChome 跟 yam 老早就是 portal service provider，content 早就有了，現在才反應固然是有夠慢了，做出這種東西更是讓人覺得沒花多少心在上面。也許投資了不少錢，但這不會是 user 想知道的。要知道 Web 2.0 最大一個重點倒也不是 AJAX，是 Mashup。要做 Mashup，系統先要有 possibility of mashup，如果你的系統都不能跟別人整合，別人也不能整合你，那你就是一個孤島。也許台灣的 user 不知道天外有天，會覺得這已經夠好了。只是追蹤表面的現象，沒有任何核心技術或是門檻，別人 Web 2.0 大家也跟著 Web 2.0，這樣是絕對會掛的。就像葡式蛋塔，當年一紅起來，多少人跟著開店，以為反正就做幾個蛋塔就有人排隊買。這樣是可以過一段日子啦，但如果大家蛋塔不想吃了呢。想想如果當初葡式蛋塔紅的時候，如果有人開一家葡萄牙菜的餐廳，點心是用最好吃的葡式蛋塔，只要菜夠好吃，那大概蛋塔沒落，餐廳還可以維持吧。
這一陣子看下來，其實對 Web 2.0 本來有很多想法，但最後發現什麼都有人做了，跟兩年前找論文研究題目的感覺很像，管你點子再好，是不會找到全世界沒人做的東西的。不過如果點子夠爛，倒是很容易發現全世界都沒人做 XD。很多東西看到也見怪不怪了，對沒看過的人也許新奇，不過這是以技術人而言。以 end user 而言，也許一點感覺都沒有。
總體來說，目前台灣還沒看到對 Web 2.0 反應正確的人提供很好的 service，大家都還是在用葡式蛋塔的心態看待 Web 2.0，也許對 portal service provider 來說，不做白不做，不管你用不用，在台灣他就是佔有很多 user。其實，Mashup + 核心技術 + end user 無痛導入 (end user 對新技術沒有感覺) 大概是 Web 2.0 可以在台灣發展的方向，事實上不必大張旗鼓說那是 xxx 2.0，誰真的在意這個，台灣知道 Tim O’reilly 的人根本少得可憐。如果什麼都要這樣衝，什麼都要大張旗鼓做 xxx 2.0 的話，那麼泡沫化 2.0 應該不遠了。
3 comments June 2, 2006 (Friday)
再談 Trendio – 新一代的新聞
之前已經介紹過 Trendio 了，
今天再仔細看了一下，
發現上面股價的起落也不是亂玩的，
事出必有因，股價的下面其實是關於這個 "Word" 最近的文章，
閱讀一下就不難發現 5/27 日，Steve Jobs 大跌的原因。
而文章似乎是來自於一些 Blog 或新聞網站。
目前在 Trendio 上沒看到 RSS 的訂閱，實在非常可惜，
如果有訂閱的話，我新聞就只要關心我想知道的就好了，
不用看那些有的沒有的。
Trendio and Technorati 都是 Tag Repository 一類的網站，
雖然好玩，但卻又沒興趣在上玩很久，原因很簡單，
看那個 Tag Cloud 就沒感覺呀 …
1 comment May 27, 2006 (Saturday)
訂閱 Peace Palace
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？這個就留待日後驗證好了。
3 comments April 28, 2008 (Monday)