Archive

Archive for the ‘Fresh’ Category

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

April 28, 2008 (Monday) 4 comments

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 / GrailsJRuby 等也可以做到同樣的事情,何必大驚小怪呢?

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?這個就留待日後驗證好了。

Openkapow – 夢幻 mashup 工具

March 8, 2007 (Thursday) 5 comments

自從 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:, , , ,

Blogged with Flock

Shelfari 書架 — 個人書籍管理

February 27, 2007 (Tuesday) 1 comment

念碩士班時,有個半路出家的同學問過我,有沒有程式可以管理個人的書籍。我當時是說,好像是沒有,但要寫也不難。她就一直很想要自己去寫一個,因為她的書實在多到不像話,超出能控制的範圍,書借給誰、有什麼書可能都要程式的幫助才行。

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:, ,

Blogged with Flock

JBoss Rules (Drools) 的發現 – 以大廠手法玩 open source?

August 20, 2006 (Sunday) 3 comments

前幾天剛好有談到 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:, ,

Blogged with Flock

AJAX 掀起 Javascript 的戰國時代

June 20, 2006 (Tuesday) 2 comments

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

  1. Google Web Toolkit
  2. Dojo
  3. Yahoo! User Interface Library
  4. Direct Web Remoting
  5. Spry framework for Ajax
  6. Mochikit
  7. Script.aculo.us

The JavaScript Library World Cup

  1. Dojo
  2. Yahoo! User Interface Library
  3. Mochikit
  4. Prototype and Script.aculo.us

第一篇裡面的 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:, , , , , , ,

Blogged with Flock

AJAX 技術應用在 Worldcup 2006

June 10, 2006 (Saturday) Leave a comment

這次第一場看的比賽是今天英格蘭對巴拉圭。對於台灣的球評還是不太滿意,不過在沒有選擇的情況下也只好認了。四年前在埔里租房子,電視在一樓,電腦在二樓,沒辦法一邊看球賽一邊用電腦。這次就不同了,看到球評不怎麼樣,就想說上 Worldcup 2006 的官網看看或許有些好玩的東西也不一定。

一進官網就有正在比賽的比數,旁邊有個小小的 Live 的 Button。點下去之後,就跳出一個小視窗,不出所料,果然是個好玩的東西。視窗的樣子就長這樣:

fifaworldcup.jpg

有什麼特別的呢?這個 page 是由 Flash 做的,兩隊出賽球員跟比數等等所有你想要的資料在上面大概都找得到。中右方那塊大塊一點的區域,有比賽即時狀況的文字解說,雖然只有射門、犯規、罰球等等狀況的說明,不過這樣搞不好已經比台灣的球評講得好了(香港的球評可是連戰術、技巧都可以評論的)。同一區塊的另一個 tab 是一個簡單的聊天室,大家可以馬上發表意見。至於上圖看到的是 Man of the Match 的 tab,那是比賽結束後才出現的。好玩的是,比賽快結束的時候,聊天室出來一個 FIFA Editor 問大家覺得誰是 Man of the Match。我想這些聊天室上的回答應該也不至於影響 FIFA 專業的判斷啦,但是的確是上面大部份的回答確也真的跟最後出現的結果不某而合,想來聊天室上的觀眾水準也是蠻高的。

我覺得這個整合的介面還不錯,至少該有的都有了,使用 Flash 在 backend 更新,可以說是廣義的 AJAX 技術,不是很難想像的應用,不過也看得出來算是有用心了。在全球這麼大的流量下也頂得住,這點的確是 Yahoo 可以自豪的地方。本來是有點期待可以更炫的啦,例如用 AJAX 做一個小小球場的圖,每位球員的位置是一個點。然後像共同畫圖一樣,讓你知道球員跟球的動向。哈哈,意想天開啦,這樣的流量或許沒辦法做這種事啦。

technorati tags:

Blogged with Flock

Flock version 0.7

June 9, 2006 (Friday) Leave a comment

Flock 出了新版囉,這版看起來又更完整了一點。

一些中文會有問題的地方有改進了,雖然還是沒有完全改好。

其實沒多少新功能,主要是使用性上的改進。

多了一個 News 的功能,可以加入一堆 RSS。

可惜我有在用 Netvibes,所以用不到啦。

Blog Post Editor 有不錯的改進,支援的 Blog 跟 API 都有增加,

也用成 JavaScript Rich Text Editor 的樣子。

其他除了畫面上的改進,大都是增加功能的整合廣度,

看來方向是對了,Web 2.0 Browser 看來慢慢走出跟 Firefox 的差異了。

Keep on Flock ~ !!

technorati tags:, , , ,

Blogged with Flock