愛德華日誌

本想要在網路上找一些記事服務來用。在幾經比較之下，NoteFish 跟 stikkit 是我比較中意的對象。雖然這兩者已經是記事服務的一時之選，可卻都還是有他們各自的限制(例如都不支援 WYSIWYG 編輯)。幾經思量之下，我還是覺定拿部落格來當作記事軟體。

既然要作為記事用途，部落格服務必需具備某些條件才行。以下是我的查驗清單：

• 支援分類，最好是 category 跟 tag 都支援
• 支援 WYSIWYG 編輯
• 支援 private post。記事跟 blog 最為不同的地方，是記事大部分是寫給自己看的，而 blog 則是一種對外發聲的管道。
• 速度別太慢。
• 可時指定記事的時間，若能把時間指定在未來，就可以透過這種方法將某記事置頂。

我大概比較了國外幾個知名的 blog 服務: Blogger Beta, WordPress, Dandelife.com 及 Vox。最後屏雀中選的是 Vox，原因是：

• Vox 的操作反應極快，也許是因為這個服務剛 announce，使用的人還不多的原因吧！
• 上述的查驗項目都符合。雖然 Vox 只支援 tag 分類，不支援傳統的樹狀結構目錄分類 :(
• 極為注重隱私，可以加入家庭跟朋友的關係。
• 可以在現在 post 未來的文章。用這種方式可以用來設定某個 deadline，時時提醒自己，相當於是一種簡易排程記事。

至於 Blogger Beta 跟 WordPress 敗下陣來的原因為：

• Blogger Beta：Private 或 Friend Only post 是以一整個 blog 來作設定，無法針對每篇文章。
• Dandelife.com：Time line 的概念很棒，可是使用 tag 瀏覽時，不知怎的就是會一直瀏覽到大家的 tag。在 IE 及 firefox 上顯示都有怪怪的…
• WordPress：速…度…極…慢…慢…慢…

如果網友試過其他在網路上的記事方式，也歡迎一起討論。

原本我是要尋找網頁更新檢查服務的。我的理想是，這樣的服務應該能讓我輸入想要監測的 URL，待該網站一有更新訊息時，就用 RSS/Atom 之類的 feed 形式，將網頁的更新內容自動 outline 出來。為什麼希望是 feed 形式呢？因為我已用慣了 Pageflakes 這樣的個人化入口網站，它嚴然成為我的情資中心，feeds 也自然成為我搜集各種情報的主要方法。

Part 1: Web Page to RSS Converter

後來我並沒有在這類服務中找到用的順手的，於是便將心念一轉，想說也許有人提供可將 webpage 轉成 RSS 的服務也說不定。就這樣，找到了一些不錯網頁轉換服務。包括：

• Feed43.com
• Ponyfish
• RSSxl - Convert an HTML Web Page to RSS

其中當以 Feed43.com 最具知名度。不過當我試著以 Feed43.com 為想要監視的網站建立 rss feed 時，它卻說無法解析我所輸入的樣式，要我再把 help 研究透澈一點。哎~ 我越來越不會 coding 了...

我再試試 Ponyfish。哇，這個讚，完全不用 coding 什麼 patterns, templates 之類的，反正就是輸入你所關注的 URL，然後再於你所想要轉成RSS feed 內容的連結上 click, click, click 就好了。底下有圖為證：

不過當然 Ponyfish 也不是什麼都好，免費的會員只能抓取連結的文字及 URL 導入 RSS。其他更進階的轉換功能，像是加上摘要什麼的，可是要付費會員才有的。

至於 RSSxl，使用界面看起來不怎麼討喜，每月還要換一次什麼 validation code 的，那就別了吧！

Part 2: Web Site / Web Page Monitor

回頭來談談原本想找的網站監視服務。其實這樣的服務或程式可大致分為兩類：「網站伺服器監視系統」及「網頁更新監視系統」。

站監視系統不時的探測某些主機位址，這些主機可能是 HTTP, SMTP 或 FTP 等伺服器。然後當異常狀況發生，像是無法連線時，於第一時間以 email, IM 或 pager 等方式通知使用者 (通常是網站管理員)，好讓問題可以於第一時間排除。這類系統中我個人所知做的最出神入化的要算是 mon.itor.us 了。它不但提供了許多種型式的伺服器監測、各種效能報表、還讓你可以使用 email, IM(包括 MSN, ICQ, Gtalk 及 Yahoo!) 及 RSS 訂閱監測狀態。而最驚人的，它的使用界面與功能竟與 Pageflakes 及 Netvibes 一樣，本身就是個個人化的入口網站。

至於網頁更新監視系統，通常用來作為競爭對手的網站監控或是新聞網站的情報蒐集。TrackEngine 與 WatchThatPage 要算是這類網站中比較優質的了。它們都提供了網頁版及 email 版的監視報告，但卻都沒有提供 RSS 訂閱功能。其實我們想想，每個網頁通常都會有固定的結構，當網頁變更時，只用透過簡單的演算法，就可完全自動的識別出不同的地方，甚至萃取出其中的連結與 摘要。這樣一來，要自動產生 RSS 也不是什麼難事 (甚至連 click, click, click 都不用)。多希望國內那些 Web 1.0 時代就做 information retrieval 的廠商腦筋轉一下，趕上 Web 2.0 的熱潮…

興趣盎然的閱讀著 tempo 所作的投影片「AJAX 的 client/server 溝通機制探究」，裡面提到了「如果你流落荒島, 但是只能帶一個 AJAX Framework, 建議你帶 DWR」。這句話引起我對 DWR 極大的興趣。

其實我們公司內部已經採用 Echo2 開發產品 (而且用的很高興)。Echo2 最大的優點是可讓我們完全擺脫 HTML、Javascript 編輯時擾人的細節，完 完全全以乾淨的 Java 程式碼開發出極為動態的 Ajax 應用程式，但相對的它的缺點是會耗費大量的 Session 資源。因此如果想要開發 Community Style 的網站時，就不適合採用 Echo2 了。所以一直以來，我對較為傾向於 stateless, 單純 RPC 導向的 ajax framework 還是保持一定的注意。

看著 DWR 的範例程式碼，讓我有種似曾相識的感覺。我突然回想起，先前在 JavaTwo 中我所介紹的 Tuscany SCA 也有提供 Ajax Remoting 的功能。再回頭去翻翻 Tuscany SCA 所提供的 ajax client 端範例程式碼，嗯！它的風格一樣也是簡潔明瞭。

以 Tuscany 設計 Ajax 的 Server 端服務

直接以 Tuscany 的範例做說明，假設我們在 Server 端有個類別如下：

public interface HelloWorldService {
    public String getGreetings(String name);
}

@Service(HelloWorldService.class)
public class HelloWorldServiceComponentImpl implements HelloWorldService {
    public String getGreetings(String name) {
        return "jsonrpcHello " + name;
    }
}

為了要讓這個類別變成 Client 端 JSON-RPC 可以呼叫的服務，我們在 sca.module 中定義其 entryPoint 及 component wire：

<module ... name="sampleHelloworldJSONRPC">

    <entryPoint name="HelloWorldService">
        <interface.java interface="...HelloWorldService"/>
        <jsonrpc:binding.jsonrpc/>
        <reference>HelloWorldServiceComponent/HelloWorldService</reference>
    </entryPoint>

    <component name="HelloWorldServiceComponent">
        <implementation.java class="....HelloWorldServiceComponentImpl"/>
    </component>
    
</module>

在 Client 端使用 Ajax 服務

最後，我們在 client 端就可以使用 Tuscany 所提供的 "SCA 物件"，簡單的使用 server 上的服務操作：

:
<script type="text/javascript" xsrc="SCA/scripts/sca.js" mce_src="SCA/scripts/sca.js"></script>
:
<script language="JavaScript">
   function getGreeting() {
      var name = document.getElementById("name").value;
      var result = SCA.HelloWorldService.getGreetings(name);
      document.getElementById('greeting').innerHTML=result;
   }
</script>
:
<div id='greeting'></div>
:

嗯嗯... 這裡似乎隱約就可嗅到 SCA 所強調的 unified programming model。即使使用 javascript 來呼叫 service，它的用法幾乎與標準的 Java client 沒有多大差異。

在 Ajax client 呼叫 Web Services

另外，SCA 還有一項特長，就是可以「把別人家的 Web Services 包裝起來變成自家的元件」。這在 Ajax 手法下特別有用，因為受限於 security issues，Ajax 無法由 client 端向不同的網站發出 ajax request。透過 SCA「把別人家的 Web Services 包裝起來變成自家的元件」的特長，我們可以在 sca.module 中集成不同網站的 web services，然後用 entryPoint 匯出成可在 client 端以 JSON-RPC 呼叫的服務。 有興趣的朋友，可以參考 Tuscany 所附的 scahelloworldjsclient 範例。

一點提醒

到這裡，有朋友心動，想用 SCA 來寫 Ajax 了嗎？哎~~ 還是提醒心動的朋友，出了事情要想辦法自己解決，因為網路上很少人談到這樣的作法。而且肯定的，至少在目前為止，在網頁元素的 binding 上，SCA 所提供的支援應該較為單調。至少我還不知道，是否有內建的 function call，只要一個指令，就可以把 service 傳回 string array binding 到 html 的 select 元素上。當然自己寫也不會太難就是了！

一個問題

最後，有一個問題我納悶很久了，很想問問 tempo：既然流落荒島，那為什麼還要帶一本 Ajax 的書呢？那時候我可能會帶「與食人族共舞」或「24 小時學會獨木舟造船術」。嗯…「螃蟹的 24 種吃法」也不錯，如果有的話。

在這 Web 2.0 的時代，現今的 Java Web Framework 也與過去第一代的 Java Web Framework 有些不同，先列出我所關注的幾個：

Spring Framework

• Spring Framework - http://static.springframework.org/
  
  輕量級的 Java 應用程式容器，同時支援 Rich Client、Web及 Java EE 應用系統之開發。
  
  
• Spring Web MVC Framework - http://static.springframework.org/spring/docs/2.0.x/refer...
  
  Spring Web MVC 是一簡單易用的 web MVC 套件，可讓開發人員把 View, Controller 及 Model 分離，開發出容易維護的 Web 程式碼。由於其 View 端採用 pluggable 方式設計，可搭配 JSP, Struts 或 JSF 展示框架使用。
  
  由於 Struts 架構因限制特定用途且開發動能不足，目前已呈老化之趨勢，開發新專案時，不建議採用。對過去只採用 JSP 的系統來說，採用 Spring Web MVC + JSP 將是最可行而簡易的升級方案。
  
  
• 中文版的 Spring Framework 教材 - http://caterpillar.onlyfun.net/Gossip/SpringGossip/Spring...
  
  良葛格寫的，其中對 Spring Framework 有深入淺出的介紹。若對 Spring Framework 不熟悉，建議先看這裡的介紹，大致上看完後對基本的應用就足夠了。若有不足處，可再參考官方參考手冊(http: //static.springframework.org/spring/docs/2.0.x/reference/)。
  
  
• Spring Web Flow - http://opensource.atlassian.com/confluence/spring/display...
  
  Spring Web Flow 讓開發人員定義一組態設定檔，透過定義 page 及 action 的 binding，完成 page flow 的定義。令人興奮的是，在 Spring IDE(http://springide.org/project/wiki/SpringideFeatures) 中，提供對 Spring Web Flow 的支援，讓開發人員可以透過視覺化的方式(http://springide.org/project/wiki/WebFlowEditor)， 來定義 網頁流程。

Echo2

• Echo2 - http://www.nextapp.com/platform/echo2/echo/
  
  支援 Ajax 最徹底的 Web Framework，其特色是 Echo2 將網頁元素完全物件化，透過它所開發出來的網頁程式，不用寫到一行 HTML, javascript 程式碼。如果開發者對 Swing 熟悉，那麼開發 Echo2 程式將會輕而易舉。想要了解 Echo2 所開發出來的程式風格，可參考其 demo(http://www.nextapp.com/platform/echo2/echo/demo/)。 看過 Echo2 令人印象深刻的展示程式後，會覺得其他 Web Framework 的展示程式是那麼軟弱無力。
  
  另外，我發現 Echo2 的社群也是非常活躍，像是其 forum(http://forum.nextapp.com/forum/) 或 wiki(http://wiki.nextapp.com/echowiki/) 裡，可以找到不錯的參考資源。而 EndPointNG (http://wiki.nextapp.com/echowiki/EchoPointNG) 則提供了許多額外的元件，像是 Tree, TreeTable, PageableTable 等。
  
  在應用上，把所有 web 元素通通轉換成 Java 資源放在 session 裡面，對於使用者眾多的應用程式將非常不利(但若是像我們公司這類程式由於非訴諸一般 end user，則無所謂)。
  

Google Web Toolkit

• Google Web Toolkit - http://code.google.com/webtoolkit/
  
  Google 所出品的 Java Ajax Web Framework。其實說它是 Java Web Framework 有些不對，因為它在開發的過程中，採用與 Echo2 類似的 Approach，是以 Java 物件來代表/處理 Web 元素。但是真正佈署前，必須將這些 Java 物件 compile 成 HTML 及 Javascript，再佈署這些轉譯後的 web 資源。因此這些資源極有可能佈署至一般的 web server 內(如 Apache)，而不需要特定的 Java web container(如 tomcat)。
  
  由於 GWT 已經實際應用於 Google 的產品線(如 Gmail、Google Calendar 等)由於 Google 的Ajax 技術已經過實際應用，因此可以確認的是它的效能不成問題。另外由於它的展現層與邏輯層完全分離，兩者之間採用 jscon 或 RPC 的方式進行呼叫，因此 server 端完全免除 UI 的 loading，只要專注於 service 的邏輯即可。再加上它可透過 JavaScript Native Interface (JSNI) 來整合既有 javascript 撰寫的網頁元件，對於 third-party 的元件，將較容易整合與移植。結論是：GWT 是一適用於高負載，運用彈性靈活的 web framework。

Wicket

• Wicket - http://wicket.sourceforge.net/
  
  Wicket 是 web 應用程式中，將 Java 程式與 HTML 源碼切割的最乾淨的一套 web framework。與 JSP 一樣，Wicket 將 view 端的 UI 定義在 HTML 中，但與 JSP 不同的是，它並不是採用 <%%> 這類特殊的 tag 來夾注 server 端的邏輯，而是利用 XML namespace 的方式，在一般的 html tag 中加注 Wicket id 來達到 server 端邏輯連結的效果。
  
  Wicket 與 Echo2 一樣，將所有的 UI 元素都轉換成 Java 物件存在 session 裡，對於流量大的應用程式非常不適用。實際試用 Wicket 之後，發現在使用既有元件的情況下，要完成相同的工作，它所需的程式碼要比 Echo2 來的多。且由於 Echo2 是所謂 "一頁式" 的 web 應用程式，而 Wicket 可支援多個頁面，因此它在 URL 連結及 session 的處理上更為複雜。所得到的益處是，Wicket 同時支援 Ajax 與 refresh based 的 web 應用程式開發，且支援 bookmarkable URL。
  
  另外，由於 Wicket 使用 HTML 作為網頁元素樣版，因此可以在美工人員與程式設計師之間作良好的分工。而既有的 javascript 在整合上，也會較 Echo2 來的簡易。
  

接下來，我想透過分析以上幾個 frameworks，檢視應用程式框架發展、轉變背後所隱含的意義：

支持輕量級開發

所謂輕量級開發，可以由幾個角度來檢視，一個是元件模型，UI 與 Server 端的邏輯是否容易連結。另一是在開發應用程式的過程中，是否需要採用特殊的工具，如特殊的 GUI Builder 或 configure file editor。最後，則是其執行環境是否單純，或是需要特定的 web 容器。

在第一點上，個人認為 Wicket 及 Echo2 皆有良好的表現。因為它們所採用的方式，是直接撰寫視覺元件的 action listener，與 Swing 的作法一致。而 Spring Web Framework 則承襲第一代 web framework，採用 dispatcher/handler 的作法，在觀念是 request/response 模式。至於 GWT，由於 client 端邏輯純粹由 javascript 負責，它所提供的 javascript 包含 RPC 呼叫程式，用來呼叫 server 端的應用程式邏輯。而 GWT 的 server 端邏輯，是一種特殊型式的 servlet。因此，如果系統中後端邏輯複雜多變，需要多個 server 端元件時，採用 GWT 預計就要維持很多個 servlet，可能會令人相當頭疼。

第二點，應用程式之開發環境，在 GWT, Wicket 及 Echo2 中，都是直接以既有的 Java IDE 即可開發，至於 Spring Web Framework 在這一點上，因為其 View 端採 plugable 設計，基本上是獨立的。不過其 config file，個人認為若有合適的 editor，會較容易使用。最仰賴 GUI builder 的，我想是 JSF，不過也不排除有存在樂於 hand coding JSF tags 的天才。

最後是運行環境，這方面的贏家是 GWT，因為它在運行時甚是不需要 server 環境。至於 Spring、Wicket 及 Echo2 等，則需要(只要)一搬的 java web container, 加上 framework 特有函式庫即可。 

另外，這裡我並未強調元件模型是否為 POJO，因為繫結視覺元素與後端邏輯，本身就是 glue code。你只能看它是否夠不夠簡易，而無需用 model layer 的標準來要求，

支援新一代的動態網頁技術

Wicket、Echo2 及 GWT 都支援所謂的 Ajax 技術。在使用上，Echo2 的方式相當靈活，因為它讓你可以動態的在 clinet 端加入與移除視覺元件。Wicket 在使用上感覺就有些限制，因為它要求 Web UI 元件與後端的處理元件，需存在一對一的對應。

對於標準的支持

這一項有些含糊，因為每個 framework 所重視的標準不一。像是 GWT 重視的是平台的獨立性，而 Spring 重視的是支援既存的各種 framework，達到中立性。Wicket 重視的是 HTML 語法的相容性，而 Echo2 重視的則是瀏覽器的相容性，以及 Swing 風格的設計思路。不過總而言之，新一代的 web framework 在這個面向已進步許多。

視覺元件與程式邏輯更明確的分割

這可分為「看起來是」與「實際上是」，像是 Wicket 就做到看起來是。有趣的是，Echo2 是看起來不是，但實際上卻是。至於 GWT 嗎，由於它的 server 端的邏輯是另外寫成 service，而 client 端的視覺元素在開發時也是以 java 撰寫。兩者採用一致的方式，不過卻必須分開撰寫，可以說它是實際上是，至於看起來是不是，就見仁見智了。

與其說這是一篇對 2006 年的預測，不如說這份清單是我看到，目前正在發生的事情。不過既使不是預測，其中也充滿了個人觀點，也許你會有不同的看法，歡迎交流囉!

關於應用系統的整合與開發

SOA, SOA, SOA... 今年炒熱一整年的 SOA(服務導向架構)，明年還會繼續，而其相關的應用與資源 - ESB, JBI, SCA(Service Component Architecture), SDO(Service Data Objects)...，於2006年會更加成熟，而且實際的應用於產業中。會有許多產品宣告它是 SOA Enabled。

相較於 SOA 的炒作的熱絡與實質應用的成功，MDA(Model Driven Architecture)會遭遇理論與實質應用上的挑戰。為什麼這裡我會將 MDA 與 SOA 這兩個看似不相關的東西擺在一起，簡而言之，是他們對於所要解決的問題，有高度的相似性。只是採用的作法完全不同，這可以是另一個故事。

流程與方法學在政府及顧問公司的推波助瀾下更受重視

PMP, Project+, CMMI… 簡而言之，既然對大家都有好處(個人可以獲得專業上的認證，顧問公司及教育訓練機構可以賺到錢，公司可以改善組織流程，進入所謂的贏者圈)，這麼好的 Business Story, 還會有誰來反對? 除了錢的問題…

Ajax Application向傳統網頁應用程式進軍，有些桌面應用程式也改以類 Ajax 技術實作

今年 (2005年) 可說是 Ajax Application 大放異彩的一年，一些網路服務應用先趨已經為了 Ajax Application 作了良好的示範。而在 2006 年，將會有更多軟體開發工具、套件實質支援 Ajax。另外一些傳統的Web 應用程式，像是 CMS(內容管理系統)、Portal(以及其上的 portlet)，Report Querier … 也都會有 Ajax 應用出現。甚至一些原本的桌面應用，像是專業的資料分析、探勘程式，也都可能出現"類 Ajax"版本。

專門為 Firefox 設計的網站應用程式

以前在瀏覽網站時，常會發現某些網站是 for IE only，相信在今後也會有 for Firefox only 的網站。與過去for XXX瀏覽器網站最大的不同點是，這些for Firefox only的網站，會充份利用Firefox 所提供的Extension, XUL, Canvas功能，將網站與瀏覽器無縫整合在一起，使整個網站的瀏覽體驗，更像是在使用桌面應用程式。

VoIP 持繼發熱

網路電話持續加溫，傳統電話業務會因此而停止成長。Skype 加入NetMeeting的功能，eBay 將透過 Skype 的NetMeeting功能提供線上影音即時拍賣。

Eclipse 仍為開放工具平台的實質標準

雖然 NetBeans 越做越好，在穩定度與易用度上甚且超越 Eclipse，但仍然無法力挽狂瀾。其中一個很大的原因是，Eclipse 已成為開放工具平台的實質標準。你可以在 Eclipse 上找到 PHP, Python, Perl, C/C++… 等其他語言的 IDE plugins，這是 NetBeans 無法追趕得上的。

軟體開發廠商生存更加困難

因為有越來越多各式各樣的套裝軟體出現，代表著有越來越多的"大眾化需求"被滿足。未來新興的軟體公司，極可能會面臨沒有應用程式可寫的壓力。因為你能想到的應用程式，都被別人開發完成了。

一般軟體廠商，面對這種情勢，有三件事可以做

1. 要以專案模式，朝客製化方向前進
2. 把握特殊領域應用，開發利基市場
3. 尋找過人的創意，解決市場尚未被滿足的需求，或創造出市場需求。 有創意的廠商能迅速脫穎而出。

軟體服務化，成為廠商延伸市場觸角的法寶

接續前面所提的 Ajax Application 中的推想，有許多傳統上應該是執行於個人電腦上的桌面應用程式，會在技術成熟，以及"商業策略"的因素下轉而Web化。將傳統桌面軟體 Web化，除了可以延伸市場觸角外，還可以支援許多傳統上難以達到的商業策略。諸如提供客戶 live experience, 改變軟體計價方式，迅速收集客戶回應等。

接續前面「軟體開發廠商生存更加困難」的話題，即使傳統軟體廠商想朝向軟體服務化方向走，前方的道路依然充滿困難… 因為這方面做的最好的，依舊是現有優勢者： Google, Yahoo!及微軟三家公司霸占著大多數的線上服務市場；而IBM, Oracle 等老大哥也是策略創新的高手。想冒出頭來的新興廠商，只能在不到 10% 的市場機會中尋找生存的空隙。

Drupal 成為最受歡迎的 CMS/Protal 系統

Drupal是一套以 PHP 開發、模組化、架構簡易，功能卻強大的內容管理架站系統。在Java開發者的眼中，這樣的系統不但不物件導向（完全用callback 方法實作），甚至還不夠格稱上 3-tier system（因為 drupal 事實上就是 web-tier + DB），它的DB存取還不用DAO、Model Object的觀念呢…，可怎樣，功能就是很強，就是可以加入無限擴充的模組，要氣死物件導向派的高手了。

不可諱言的，我自然也是Java社群的一員。初次觀看drupal程式碼時，還是覺得PHP實在不是優美的語言，drupal 程式碼中更夾雜著SQL與HTML（附帶一提，drupal可能已是PHP 內容管理系統裡面程式碼寫的最優雅的了。以PHP的標準，如果說 Mambo 是金玉其外，那 drupal 則是文質彬彬）。

無論如何，在Mambo分家，而Nuke、Xoops在分支眾多的情況下，Drupal已然成為 PHP CMS 中開發社群凝聚力最強的一支隊伍。相信在2006年會有更多開發人員為 drupal 建立外掛模組，使drupal成為 Apache+MySQL+PHP 上實質的的應用軟體開發、整合平台。

OpenOffice 會吸收更多的死忠支持者，就如有一群人死忠支持 Firefox 一樣

更多政府機構會實質採用 OpenOffice, 更多學校會採用 OpenOffice 授課。

微軟會成為智慧型手機、PDA、家庭數位娛樂電器的實質贏家

這已是事實，不用多說。

應用程式繼續朝向精簡型架構設計，EJB 3.0 叫好不叫座

(雖然Jini大力推EJB 3.0)

這是一個最重視物件導向的年代，也是最不重視物件導向的年代。舉例來說吧，現在的Java應用程式框架，強調要支持POJO的觀念，可是事實上，MVC卻大行其道，MVC是物件導向嗎？有人打圓場，說這叫separation of concerns。再以前面的 drupal 實作為例，callback不算物件導向吧！可是它卻是標準的 IoC (Inversion of Control)，符合 Hollywood principle -"Don't call me, I will call you"。

"物件導向不再無限上綱"。這句話一出，怕是要引起不小的爭論了。讓我簡單的說吧! 在未來的應用系統開發，你所強調的是架構，是服務，是功能，是流程。而物件，則是堆砌這一切的基本單元。也就是說，你只有在構築"程式的基本單元"時，才會採用物件導向的思維模式。當你往上堆砌系統，或一開始即採用架構導向系統開發方法(Architecture Oriented System Development)時，比較適當的思維模式，是將系統看作一部"機器"，你考慮的應當是系統各部元件之間的連結，彼此間如何互動，最後才是各部元件各自的角色與職責。

這與傳統的物件導向方法的差異是，這樣的方法是由整個系統，由整體到部份，由外往內，由多數到單一，再由單一推進至物件裡面。而不是一開始就著重在各個功能物件上。甚至在各功能物件之間尚未完成定義前，就必須先設計整個系統的訊息交換機制。要深入探討，這又是另一個故事，就此打住。

剛剛想到一個 idea, 那就是如果我們把 rss 或 atom feeds 的 url 存入 del.icio.us 之中，放入固定的 tags 裡面(如 !subs)，再為 firefox 提供一個 plugin, 讓它去讀取這些 feeds 的 url，那不就可以把 del.icio.us 當作 feeds 的 server 了嗎! 這樣做的好處很明顯，就是我們只需用同一組服務，就能使用 bookmark manager 跟 feeds reader 的功能。

這樣的作法，可以想像我們有一個 sage+foxylicious 的綜合體。透過 foxylicious 來同步 feeds 的訂閱清單(並分類)，再透過 sage 來顯示 feeds 的內容。當然，在這樣的綜合體還沒出現之前，你也可以各別的應用這兩個 plug-in 達到我所說的效果，只是 foxylicious 預設會下載全部的 bookmarks，而 firefox 在處理 bookmarks 時是一次全部載入記憶體，這會讓 clinet 端幾乎不能負荷。

不過因為 del.icio.us 只能存放 feeds 的 url，但是無法存放 feeds 讀取及更新的狀態，因此必須把 feeds 的讀取狀態像 sage 一樣存在 client 端。其缺點就是，你無法在兩部電腦上維持同樣的 feeds 閱讀狀態。

另一個作法是允許 recursive 的 live bookmarks。也就是若一 live bookmark 裡面存放的是一組 feeds 的 URL，則 firefox 或 sage 應能聰明的辨認出子節點亦為 live bookmark, 而能將其展開。

從 trendalicious! 上看到 GTD TiddlyWiki。TiddlyWiki 是個 "一頁式" 的動態 Wiki，順著連結閱讀內文，充份的展現了超本文 (Hypertext) 的閱讀樂趣。

作者很有心的把它開發成一個 PIM 軟體。在下載之後，你就可以利用它來管理自己的工作目標與計畫。而在 TiddlyWiki 中的任何修改，都可透過 Timeline 面版追蹤，因此你也可以把它當作是一個日誌使用! 這樣的東西還有什麼用途呢? 如果把它放入像是 Subversion 般的版本控制系統中，應該可以作為簡單的專案資訊分享面版吧。

這是至目前為止，我看到 Javascript 在 Client 端應用的最出神入化的例子了!

del.icio.us 正悄悄的更新了它的功能與介面設計。其中比較顯著的項目包括：

• tag bundles
• experimental post to del.icio.us
• new scheme, 以及
• daily blog posting

tag bundles

就功能上來說，最大的改進要算是 tag bundles 了。簡單來講，tag bundles 就是把相關的 tags 群組在一起。例如，我便把 [blog community forum portal web wiki] 等 tags, 歸納入 web 這個 bundle 中。

其實這樣的功能在別家的 social bookmark 系統中早已存在，但是我覺得 del.icio.us 的巧思在於它的介面設計。因為從畫面上我們可以看出，它並沒有把各個 bundle 的內容放置在不同的畫面中 (加以群組化)，而是把各個 bundle 疊在一起；而同一個 bundle 內集的各個 tag，更是可以自由切換。這樣的設計，可以讓你把相關的概念 "連結" 在一起，而不只是一般 group/directory 設計所強調的 "分類"。

experimental post to del.icio.us

這個功能，就是以前 nutr.itio.us post 的翻版。看看下圖，當能望圖生義吧!

new scheme

del.icio.us 這次也提供了一個新的頁面展示方式，大概是因為還在試驗之中，你必須由 "http://del.icio.us/new/你的帳號" 這樣的位址進入才看的到。整體介面設計相當簡約與實用 (與 Google 的風格一致?)。bundles 與 tags 一目了然，容易切換。如果是只有一個 post 的 tag，其連結顏色較淡。如果某個 tag 的 post 數目較多，還會以較大的字體展示，真是不錯!

不過我還是發現了一個小小的缺點。舉個例子：當你進入 http://del.icio.us/new/edwardsayer/computing+grid 頁面時，若是我現在想要排除與 grid 有關的資料，就必須在 grid tag 之前小小、小小的 ! 連結上按一下。我可以確定， ! 對許多人來說，是很難 "瞄準" 的!

daily blog posting

知之為知之，不知為不知。這倒底是什麼東西，我還看不出個究竟!

本站相關網誌:

• 整合 delicious extension 與 nutr.itio.us
• Social bookmark 無責任評比

Web Application Framework:

MVC(Model-View-Controller)架構向來是設計GUI架構的標準架構。Java 在 web based 的 MVC 架構尤其大放異彩，百家爭鳴。Here is a Feature Matrix。比較著名的解決方案包括：

• Struts + JSF + JSP + JSTL: See also:
• • Display tag library: The display tag library is an open source suite of custom tags that provide high level web presentation patterns which will work in a MVC model, and provide a significant amount of functionality while still being simple and straight-forward to use.
  • Layout Helper: Tiles, SiteMesh,
• Tea/Velocity
• Tapestry
• Echo
• Wicket: Wicket is a Java web application framework that takes simplicity, separation of concerns and ease of development to a whole new level. Wicket pages can be mocked up, previewed and later revised using standard WYSIWYG HTML design tools. Dynamic content processing and form handling is all handled in Java code using a Swing-like component model backed by POJO data beans that can easily be persisted with Hibernate.
• XMLC/??
• JPublish: 不過我覺得它不是一個完整的Content Management系統，它反倒比較像是Content Management底層的一個 Framework。另外，如果你檢視它的設計，你也會發現它是一個很好的 MVC 架構。
• • ps: alternate to JPublish, OpenCms is a pure CMS, but don't integration with potal.
• WebWork: WebWork is a web application framework for J2EE. It is based on a concept called "Pull HMVC" (Pull Hierarchical Model View Controller)
• SOFIA: SOFIA sets a new standard for Java development by delivering so much more in a framework matching best-of-breed tools integration with robust JSP class and tag libraries. SOFIA shortens application development time on the strength of its visual development capabilities and pre-built Java components that dramatically simplify coding.
• Japple: Japple is a rapid application development environment for building web applications and services. Built on the JavaTM2 Platform and open-standards, Japple allows you to develop and deploy web applications faster, easier and more efficiently than traditional methods.

Server Application Framework:

• Spring:
• Keel Framework: Keel is ready made server side infrastructure. Keel incorporates multiple open source projects to provide you with a best of breed framework that works right out of the box.
  • Security layer
  • Database abstraction layer
  • Messaging layer
  • Business logic layer
  • User Interface layer
  • Struts
  • Cocoon
  • Velocity
  • Others in the works.
• eXo platform: Based on the most innovative tools, API and frameworks such as Java Server Faces, Pico Container, JbossMX and AspectJ, the eXo platform is probably one of the most promising Open Source project these days.
• J2EE for sure ....

Java web server 的 performance report

下列連結顯示各種 Java web server 的 performance report,

http://webperformanceinc.com/library/ServletReport/index....

由其中可以看出，Tomcat 的 performance 算是相當不錯。在 6 種測試的產品中，總體效能位居第 2 至第 3。