Archive

Archive for the ‘Buzzwords’ 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?這個就留待日後驗證好了。

Advertisements

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

Full Stack Framework 的流行 – 從單點變套餐

October 11, 2006 (Wednesday) 5 comments

我們去餐廳的時候,很常會點套餐。套餐省略了一一挑選的麻煩;對不了解菜色的人而言,套餐會從前菜到點心配好好的;通常也有一些折扣或是附餐。雖然失去了單點的自由度,但還是有很多人都會選用套餐。

Java,尤其是用在 web development 上,有各式各樣的 framework 跟技術。如果要一一選用跟搭配起來,往往是一種痛苦。畢竟能享受從挑選零件再組出一台跑車的人是極少數的人。每個元件都要弄懂也是一種很大的學習負擔。自從 Ruby on Rails 問世以來,很多人都喜歡上它的簡化跟整套 full stack 的 framework。或許是接受到 Ruby on Rails 的刺激,Java community 有很多類似的想法出現,如果你覺得慢慢把 Struts、Spring、Hibernate 等等全都學會再組裝起來很難的話,或許選用一個 full stack framework 也可以達到類似的效果。

以下點名一部份的 full stack framework,有些其實在 Ruby on Rails 之前已經出現了:

AppFuse:或許他不該叫 framework,它是一個把 Struts, Spring, Hibernate 等等 framework 預先組裝好的環境。其組裝的方式可以作為學習對象。Presentation Tier 可以選用 Struts/WebWork/JSF/Tapestry/SpringMVC;Persistence Tier 可以選用 Hibernate/iBATIS。AppFuse 已經在蠻成熟的一個階段了,我本身也在實際的 project 上運用過它,節省了不少開發時間。缺點是所用的 framework 也許不是在最新的版本。

JBoss Seam:這是 Hibernate 的作者 Gavin King 的力作。我個人非常喜歡這個 framework,原因不在它使用了 JSF+EJB3 這些 JCP 的標準,說真的如果不好用標準早是華而不實的東西。我喜歡它是因為大量運用了 annotation 減少了要開發的 code,而且那些 annotation 看得出來是在多次的經驗中提煉出來的,非常切合開發者真正的需求。而 JSF 跟 EJB3 的無間結合讓所要開發的 number of class 大量減少。如果沒有任何負擔的情況之下,我覺得 JBoss Seam 是最佳選擇。只是它目前還有些許的不成熟。

RIFE:一個很成熟的 framework,不過它的概念有點特立獨行,也沒有用到一些主流的 framework。看過它的 demo 我覺得它的想法有達到目的,但因為離主流有點差距,能得到的資源較少。它也可以跟 Spring 等等做整合。

Grails:由 groovy 為主軸的 full stack framework,目前還在很早期的階段。不過 groovy 這種 scripting language 的簡便,讓 Java 也有機會跟 Ruby on Rails 一拼。後端是以 Spring+Hibernate 為基礎。我覺得這個 framework 潛力很大。

其他如 TrailsProject Able 等等因為我沒有太多的研究,不一一詳列,事實上一定還有很多我沒看過或是已經忘記名字的 framework 存在。所能看到的是 full stack framework 的興起,如果是你要追求快速開發,也許要改為注意 full stack framework 的動向,而不單單是個別 framework。在以上的 framework 裡,幾乎都用到了 Spring,也就是說 Spring 這種 middle tier 的 framework 佔有重要的角色。當然 JBoss Seam 是用了 EJB3,不過功能上類似。而 middle tier 的能力就決定了 full stack framework 整合的能力。所以未來 Spring 或是 EJB3 的角色會更重要而使用更廣泛。

如果你還在煩惱用哪些 framework 作為你的 baseline,在學習怎麼把不用 tier 的 framework 組裝在一起的話,那麼何不看看以上幾個 full stack framework 呢?或許你單點的菜色其實跟套餐差不多,而套餐還送你附餐飲料呢!

technorati tags:, , , , , , , , , ,

Blogged with Flock