WebORB for Ruby on Rails

終於來了,而且是 open source。
note: 同時支援 AMF0, AMF3。
最近三不五時得跟 Cairngorm 這個 framework打交道,原因是大部份國外客戶與專案都在用它,結果每個合作的工程師見面第一句都是:
-you know Cairngorm, don’t you ?
-we are using Cairngorm on this project, if you are not familiar with it, ….
(通常是給個鏈結要人去看 devnet 上的 Cairngorm六篇教學)
所以在形勢比人強的情況下,就算我心裏再怎麼不認同Cairngorm,也只好忍痛傷害一下腦細胞開始用了。
正好昨天 Cairngorm 的創始人 Steven Webster 寫了一篇 Why I think you shouldn’t use Cairngorm,裏面解釋了在何種情況下,你不應該使用它。
這篇文章讓我想起累積許久的想法,就順便整理一下。
*好處
-protocol:
總的來說,大底而言 framework 的功用就是為了讓軟體開發過程中,能有一個共同的標準、手法與依規,例如相同的底層架構,程式邏輯分割等,而 Cairngorm 做的就是這樣的事。
因此它就像是一個 protocol(通訊協定),一旦制定出來,大家就有一個標準可遵從,例如 pop3 protocol定義好後,大家都知道只要透過socket 連接再送出某些字串,就一定可順利與server溝通,而如果沒有這樣一個 protocol,那就會變成大家各搞各的獨門創意,最後就沒辦法普及。
所以如果大家都用某個framework(不一定要是 Cairngorm ),那工程師間的溝通或系統分析與設計就會變的比較簡單,因為就像 UML 一樣,大家用相同的符號與概念在做同一件事。
而這就是目前 Flex 2 開發 RIA 的現況。基於某些神奇的因素, Cairngorm 被認為是 Flex + RIA 的不二法門,不管新手、老手都一致認定要開發 RIA 就是先學會 Cairngorm 。
從某個角度講,這也是好事,因為當大家都熟悉這個 protocol 後,將來的確是走到那裏都可以直接 join 專案,不需重新熟悉別人的 coding pattern。
-de-coupling:
Cairngorm 在底層架構的設計上確實是切割的很乾淨,這點在我之前幾篇相關文章中已多次說明,它將每個tier 間的關系徹底分離,所以理論上 coupling 的情況是很低的,而某些元件,例如 command, service 也的確有可能在不同的專案間重覆使用。
*壞處
-太複雜:
Cairngorm 主要的壞處,也正是它好處的反面,就是切割的太細導致編程手續變的很複雜,一個 user gesture 可能要透過五個class 才能達成。
如果你從來沒用過 Cairngorm ,這裏舉一個小例子,以login window為例,當user填好帳號、密碼後按下 submit 鈕,接下來會發生的事:
1. submit button handler 偵聽到按鈕按下的事件
2. 透過 CairngormEventDispatcher 廣播這個事件
3. Front Controller 聽到這個事件性轉手交給 command object 處理
4. Command 依事前指定的條件呼叫 delegate object
5. Delegate 物件透過 ServiceLocator 操作遠端呼叫
6. 當app server傳回result後再循反方向將 result 傳回 command
大部份新手看到這種手法大概就昏了,這還是以能看得懂為前提,而就算看懂,敢真的用到實際專案上的大概就沒幾個了。
這種過於複雜的流程導致新手難學,尤其在中小型的案子上更不適用,但許多工程師並沒有查覺這點…
-hurt flex:
Cairngorm 原先只是 Iteration::Two 這家公司提出的一個實驗性想法,但在 Adobe 買下它之後,一夜之間Cairngorm 似乎就成為 Flex RIA 的聖經、王道。
在大家的吹捧與討論之下(任何時候你到 flexcoders 上都會看到一堆Cairngorm相關問題),讓許多 developer 以為這就是唯一的選擇,就像幾年前大家以為用java開發web application 就一定是用 struts,而沒有想到自已的能力、團隊、專案性質是否真的需要?
而這種情況造成的嚴重後果現在已然浮現,也就是大家以為
flex = cairngorm = 複雜難學
意思是,大家以為要用 flex 要先學 Cairngorm, 但 Cairngorm本身太複雜難懂手續又繁雜,因此,Flex 一定也是同樣的複雜難懂所以乾脆不要用它好了。
這種類推就好比 gmail 那天掛了,大家就怪 python, javascript 與 dhtml 不好,但這實在是非戰之罪啊~
現在 Adobe 也感覺到這種危機,當初推 Cairngorm 是為了打動企業用戶,讓主管們心安,知道世界上有一個類似 struts的 frameworks 可供開發超大型企業級RIA,但結果猛虎出柵後就尤如潘朵拉的盒子開啟,出去就收不回來,搞到最後不該用的人也跑來用,然後被 Cairngorm 燒到就怪罪到Flex 頭上,最後就變的 Flex 也很難推,這就是現在Adobe 開始擔心的事。
這也是為何 Steven 會寫那篇文章,並且特別強調,在用Cairngorm之前,應該要先對 Flex 本身有徹底的瞭解,才能有足夠的能力判斷自已是否需要使用這個 framework。
*解決之道:
我一直在思考這件事可能的解決之道。
幾個可能的方向整理如下:
-很不幸的,任何一個認真的 Flex developer 都一定要會 Cairngorm,並且至少用它開發過一個application, 原因就如上所言,它已經是一個官方欽定的開發手法並流通於全世界(就像英語一樣),因此除非你不需要跟外界合作,不然的話早點摸熟工師程的共同語言是有益無害的。
-Cairngorm 並不是完全不可用,但一定要清楚知道它只是眾多framework 之一,不代表神聖而唯一的絕對,實際上當摸熟它之後,許多時候應該要理智的質疑它的缺點然後想出改善之道。(套一句 b6s 長輩的說法,這應該叫做”潛入其內、使其自爆”吧?)
-對大部份中小型專案來說,難道不能有一個更簡單易用的framework 嗎?答案是絕對有,畢竟 design pattern, best practices 大家都瞭然於心,這些是基本的大原則,掌握原則後應該可以自行依實際需要變通並設計出適用的”手法”。
*後話:
從過去幾年的 RIA 開發過程中,我們已逐漸累積並形成一套簡易的開發規則,它不算是一個framework, 而比較像是 best practice 的集合,但已証明很適合用在 Flash/Flex 為主的專案開發,速度很快且手續簡便,大部份的工作都可以在三個steps內完成,但仍然保持每個 tier 間的 decoupling 與 彈性。
未來有空時我會製作一個小型的範例程式來示範這個手法,並嚐試說明每個環節的設計理念,屆時也歡迎大家從正反兩面來檢視這個手法,看看它有什麼優缺點。
ps. 目前範例只製作到一半,也還沒寫文件,但如果有興趣想先看看的朋友歡迎留個言,我會email給你,但希望你看完後至少要提供一些意見,例如你觀察到那些問題、缺點,or better yet, 可以提供改良的意見讓它更好。
MidnightCoders 將在 8/22 公佈第一版的 Weborb for Rails (簡單來講就是 flash remoting for ruby on rails).
附帶一提,MidnightCoders 也同時提供 flash remoting for Java, .NET, PHP,它們也是第一家支援 AMF3 的 3rd party 廠商,技術實力驚人啊~
神人 Darron Schall 又出招了,原本這個用 AS3 寫成的 vnc client 只放在 IFBIN 裏供付費者下載,但在 IFBIN 創始人 Ted Patrick 加入 Adobe後,這個組織就變成完全免費,所以 Darron 也就乾脆把 fvnc 變成 open source,詳情可以在 osflash 看到。
想下載原始碼的人可以連到 svn 直接抓 trunk 回去。
這個source 珍貴的地方有幾點:
1、作者(Darron) 一向以功力高深著名,有事沒事看看他的code 就像在臨摹高人的墨寶一般,可收如沐春風醍醐灌頂之效,早晚服用有病治病沒病強身…
2、裏面有一個 1024 DES 加密/解密的演算法,應該是目前 Flash 界唯一的實作,如果有需要用到這麼strong 加密功能的人,直接把那個class挖出來就好。
3、這是 Flex 2 final 版,之前在 IFBIN 上面的是 beta2。

熱血青年又來了啊~
很多年前 Grant Skinner 曾用 AS1 做過 gOS,儘可能模擬一般os的功能也提供許多底層API,後來發展到一半他就紅了忙者接案子沒時間再寫下去。
現在另一批熱血青年又出現了,DesktopTwo 是用 Flash 8 + AS2 寫的 “類os” 系統,從名稱中就可以隱約看出他們的企圖心,web, desktop , 2.0,嘖嘖,這不是現在最火的 web 2.0 精神:
internet as the platform,
web as the desktop,
read and write the web !
目前它們提供的服務包括 Email, IM, Blogging tool, Address book… 每一樣都是用 flash 刻出來的,實在是精力旺盛毅力過人啊~
不過這也代表一個事實,只要 flash VM 本身夠爭氣,要在上面做什麼神奇的應用都是可能的,例如 Flash VNC, FC64 simulator, Flex Excel 不都有人做出來。
只是類似這樣的team可能要問一個實際的問題:做這樣的事(重新創造一票web-based 的工具軟體)是否有實質的意義?有機會成為下一個 Writely 或 Flickr 被金主高價收購或IPO 嗎?
或是換個角度問:類似這樣的軟體組,真的有辦法像 Gmail 一樣成為許多人每日必用且離不開的工具嗎?或者user只會一時好奇註冊帳號然後過幾天熱潮消退也就再也不回了?