Google AppEngine for Java Announced

Today is a great day while Google announced the Java version of AppEngine.

The first thing to keep in mind is the security sandbox on the AppEngine server. And obviously it would be the challenge for many Java frameworks to run on AppEngine server out-of-the-box.

After having a brief run, here are something I found:

• SiteMesh cannot work since it called javax.naming.InitialContext somewhere.
• Stripes cannot startup by default because the DefaultMultipartWrapperFactory delegate to somewhere called System.getProperty(“java.io.tmpdir”). By providing a empty implementation of MultipartWrapperFactory, this could be solved easily. (Without considering the multipart function really works, since the AppEngine sandbox locked the file writing).
• Freemarker works fine except there is an error on using JSP tags.
• Spring framework seems fine as far as I go.

Looks like most of the issues can be solved. But the local environment does not work as the sandbox on AppEngine server. This makes the debug harder and the cycle longer.

即時共同 Coding – Cola

自從 Web 2.0 時代以來，share editing 是一個常見的應用，像 Zoho Writer 就可以即時共同修改同一個文件檔。但在程式開發方面，雖然一直都有 Collaboration 的觀念，但工具方面一直都沒有看到可以 share editing 的 (可能是有，不過我還沒有看過)。

Eclipse 的新版 Ganymede 最近 release，主打的除了更強化 Mylyn 的功能以外，ECF (Eclipse Communication Framework) 也出了一個新版。在這個版本裡，名為 Cola 的的 share editing 環境是主打的功能，有一段清楚的 demo 在這裡，也可以看 DocShare Plugin 的介紹。其實一堆名稱我也覺得很困擾，到底哪個代表什麼，不過既然作者在 demo 裡都說是 Cola，那就跟他一樣叫 Cola 吧。

使用時必需案裝 ECF plugin，可以在這裡找到。其實目前 Cola 的功能並不算強大，在 ECF 使用 XMPP (Google Talk) 或 Skype 的 provider 時，才能使用 Cola 的功能。在 communication perspective 中連上 XMPP 或 Skype，之後加入好友名單，就可以選要要 share editing 的好友，檔案內容一開始只要有一方擁有就好，coding 時雙方的修改都會即時被看到。

實際操作時覺得還蠻順暢的，不過如果沒有配上同時使用 Skype 語言溝通的話，那感覺上就像有個不知名的人在偷偷亂改你的檔案。憑心而論，這個功能目前趣味性大於實用性，我能夠想像的是搭配語音溝通的情況之下，讓身處兩地的一位老手帶著一位菜鳥去寫 code，這樣子對菜鳥的進步是有很大的幫助。若是實際上開發 project，大多不必如此大費周章去搞 share editing。但是我還是很樂見這樣的功能終於能夠看到比較成形的產品，畢竟先有了技術平台，運用就有機會出現。

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

Unitils — 一次滿足所有 unit test 的需求

談到 unit test，大家馬上想到的應該會是 JUnit；又或許是比較新一點的 TestNG。有些比較有經驗的人可能就會提出，那 servlet 如何測試？Spring bean 又如何測試？DAO 又如何測試，怎麼去建立 DB 的資料？如何去 mock 一個物件？

這些問題早就出現了，也早就有解法了，只是每一個問題可能都會對應到一個  library 或小型的 framework。 一直都沒有一個一次把問題解決的方案，直到 Unitils 的出現。Unitils 發源於 Ordina J-Technologies 的一個 unit test discussion group，會中他們討論出一份 Unit testing 的 Guidelines，而 Unitils 正是這份 guideline 的實作。

在 unit testing framework 的部份，Unitils 是 JUnit3, JUnit4, TestNG 三種都支援，所以不管你最熟悉的是哪一個都可以順利的使用 Unitils。在功能方面，Unitils 主要 support 以下幾項功能：

• Assertion utilities
• Database testing
• Unit test database maintenance
• Testing with Hibernate
• Testing with Spring
• Testing with mock object

這些功能的文件都寫得很簡單易懂，其實觀念也很簡單，歸納一下只有幾個：

• 使用 Java 的 equals 去 compare 通常不會是我們真的要的狀況，所以提供了比較寬鬆的比較
• Unit Testing Database 必需要能夠自動的維護 (建立與更新版本)
• DB 的資料必需要能夠在測試中自動加入
• Test fixture 像是 Spring bean, mock object 等等盡量使用 annotation 標註，由 framework 自動產生

另外，Unitils 本身是由一堆 module 所組成的，如果它所提供的 module 還是無法滿足你的需求的話，要擴充其實很簡單。有興趣的人看一下 Unitils 的 source code 以及 unitils-default.properties 這個設定檔應該就知道怎麼做了。其實很難得一個小小的 unit testing framework 居然在模組化上做得這麼精美。

以前在這裡討論過 full stack application framework 的興起，同樣的 Unitils 這個可以滿足所有 unit test 需求的 framework 也很有可能慢慢會變成主流。只要一種技術成熟到一個程度之後，將會有整合的環境出現。在 JUnit、TestNG 都沒有太多的突破之後，Unitils 補足了這個空缺的需求。 如果你還在煩惱要怎麼開始做 unit test，那就用看看 Unitils 吧！

當 Spring 2.5 遇上 Hibernate Annotations – 自動搜尋 classpath 內的 entity

最近推出的 Spring 2.5 提倡使用 annotation 的方式取代 xml 的設定，這個部份幾乎完全取代了 Spring Annotations 的功能，看來這個 project 應該已經沒有什麼生存空間。但 spring annotations 的 hibernate module 所提供的 AutomaticAnnotationSessionFactoryBean 一直是我很喜歡的功能。以往使用 Hibernate Annotations 時我們只能以 fully qualified class name 或 fully qualified 的 package name 來指定 entity class。透過 AutomaticAnnotationSessionFactoryBean 我們可以自動找到所有標示為 @javax.persistence.Entity 的 classes 自動加入到 hibernate 的 mapping classes。Spring 2.5 既然本身就可以自動的搜尋到 @Component 以及相關的 bean class，那我們應該也可以做到 @Entity 的搜尋囉。

我按照 spring annotations 的做法，提供一個自製的 session factory bean：

import org.hibernate.HibernateException;
import org.hibernate.cfg.AnnotationConfiguration;
import org.springframework.core.io.Resource;
import org.springframework.core.io.support.PathMatchingResourcePatternResolver;
import org.springframework.core.io.support.ResourcePatternResolver;
import org.springframework.core.type.classreading.CachingMetadataReaderFactory;
import org.springframework.core.type.classreading.MetadataReader;
import org.springframework.core.type.classreading.MetadataReaderFactory;
import org.springframework.core.type.filter.AnnotationTypeFilter;
import org.springframework.core.type.filter.TypeFilter;
import org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean;
import org.springframework.util.ClassUtils;

import javax.persistence.Entity;
import java.io.IOException;

/**
 * Created on: 2007/11/24
 *
 * @author Alan She
 */
public class ClasspathScanningAnnotationSessionFactoryBean extends AnnotationSessionFactoryBean {

    private static final String DEFAULT_RESOURCE_PATTERN = "**/*.class";
    private ResourcePatternResolver resourcePatternResolver = new PathMatchingResourcePatternResolver();
    private MetadataReaderFactory metadataReaderFactory = new CachingMetadataReaderFactory(this.resourcePatternResolver);
    private final TypeFilter entityFilter = new AnnotationTypeFilter(Entity.class);
    private String resourcePattern = DEFAULT_RESOURCE_PATTERN;
    private String[] basePackages;

    public void setBasePackages(String... basePackages) {
        this.basePackages = basePackages;
    }

    protected void postProcessAnnotationConfiguration(AnnotationConfiguration config) throws HibernateException {
        for (String basePackage : basePackages) {
            try {
                String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX +
                        ClassUtils.convertClassNameToResourcePath(basePackage) + "/" + this.resourcePattern;
                Resource[] resources = this.resourcePatternResolver.getResources(packageSearchPath);
                for (int i = 0; i < resources.length; i++) {
                    Resource resource = resources[i];
                    MetadataReader metadataReader = this.metadataReaderFactory.getMetadataReader(resource);
                    if (isEntity(metadataReader)) {
                        String classFileFullPath = resource.getURL().getPath();
                        String basePackageResourcePath = ClassUtils.convertClassNameToResourcePath(basePackage);
                        int startIndex = classFileFullPath.indexOf(basePackageResourcePath);
                        final String classFilePath = classFileFullPath.substring(startIndex,
                                classFileFullPath.length() - ClassUtils.CLASS_FILE_SUFFIX.length());
                        Class entityClass = null;
                        try {
                            entityClass = ClassUtils.forName(ClassUtils.convertResourcePathToClassName(classFilePath));
                        } catch (ClassNotFoundException e) {
                            throw new HibernateException("Entity class not found during classpath scanning", e);
                        }
                        config.addAnnotatedClass(entityClass);
                    }
                }
            }
            catch (IOException ex) {
                throw new HibernateException("I/O failure during classpath scanning", ex);
            }
        }
    }

    private boolean isEntity(MetadataReader metadataReader) throws IOException {
        if (entityFilter.match(metadataReader, this.metadataReaderFactory)) {
            return true;
        }
        return false;
    }
}

這個 class 的內容是以 Spring 2.5 的 ClassPathBeanDefinitionScanner 為骨幹而來的。原理很簡單，以 PathMatchingResourcePatternResolver 去找到所以 basePackage 下的 classes，一一比對是否有 annotate 了 @javax.persistence.Entity，如果有就加入到 session factory 的 annotationClass。

<bean id="sessionFactory" class="package.ClasspathScanningAnnotationSessionFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <property name="hibernateProperties">
    <props>
        <prop key="hibernate.dialect">${hibernate.dialect}</prop>
    </props>
    </property>
    <property name="basePackages">
        <list>
            <value>package.model</value>
        </list>
    </property>
</bean>

使用上也非常簡單，跟一般 spring 宣告 session factory 一樣，只需指定 basePackage 作為搜尋的範圍即可。

自動搜尋當然有優點也有缺點，但我個人討厭一一去設定 entity。有人可能會覺得萬一如果我有在 classpath 裡的 entity 又不想加入那不就只能全都用手動設定？其實如果想要有些彈性可以加入 include / exclude pattern 等東西，讓設定更活。畢竟設定檔時代已經慢慢過去，在 convention over configuration 的大趨勢之下，想辦法制定規則以及將規則以自動化落實才是長久之計。

自製 Firefox 的 Search plugin

使用 Firefox 的人一定都有在用右上方的搜尋工具，除了 Google, Wikipedia 以外，也有不少網站有提供自己的 Search plugin。但是你平常最常搜尋的網站有這樣的 plugin 嗎？國外的大站也未必都有 plugin，更別論台灣的網站了。

其實這樣的 plugin 很簡單，大概有寫過網頁程式的程度就可以做出來了。 首先，去 Firefox 的安裝目錄 (可能是 C:\Program Files\Mozilla Firefox\) 打開 searchplugins。然後你會看到 google.xml 之類的檔案，那就是一個 search plugin。我們要做的事很簡單，copy 一個出來改成自己要的 (wikipedia 的那個語法相對簡單，可以用簡單的先改)。以下大概解釋一下每個 element 的改法：

• <SearchPlugin>: 這個 plugin 的 xml root element，不用動
• <ShortName>: 這個 search plugin 的名稱
• <Description>: 說明
• <InputEncoding>: 輸入文字的編碼，請視你要搜尋的網站使用的編碼決定
• <Image>: 16×16 的小 icon， 以 base64 編碼直接放在 tag 裡。可以使用這個網站把 ico檔轉成 base64。
• <Url>: 相信會寫網頁程式人的對這一定不會太陌生，template 裡填入 query 的 url，裡面的 <param> tag 填入要送過去的參數。可以送一些固定的值，唯一動態的值是 {searchTerms}，那就是在 search box 填入的文字。至於 query 的 url 跟 param 到底會是什麼就視網站而定了，對熟網頁程式的人一定不難。
• <SearchForm>: 沒有輸入時按 enter 就會跳到這個 url，一般可以設定為搜尋頁。

修改好之後重開 Firefox 就會多出你剛改好的選項了，這樣就可以自製自己常用網頁的 search plugin，而不用每次都連到網站上囉。

優美的 UI component – YUI and yui-ext

不少人都知道 Yahoo! 的 YUI (Yahoo! UI Libraray)，那是一個簡單又好用的 UI component。因為使用的技術是 HTML + JavaScript + CSS，所以並沒有限制在什麼平台或語言下使用。YUI 最強的地方是它的 packing 跟 ease of use，不會因為你要用一個小元件就要裝一大包東西，文件跟範例也算是很完整了。在 Ajax 開發時如果找機套上 YUI 去使用應該會事半功倍。比起 Dojo、Qooxdoo、x-desktop 等，YUI 的功能其實不強，但卻很實用。

yui-ext Documentation Center 是一個叫 yui-ext 的 library，很明顯它是 YUI 的一個擴充。也許因為 YUI official 提供的功能其實不夠強大，就有人來做擴充啦。繼承了 YUI 包裝上的便利性、文件完整和容易使用的特性，yui-ext 提供了不少很實用的功能。有些功能其實是把 YUI 過於基層的功能再做一些包裝。功能大概有以下幾項：

• Dialogs： 跳出一個 <div> 對話框，彈出跟收入的 animation 動作看了就讓人快樂。
• Grid： 幾乎是無敵的 component，Table、Form 通通可以由它來做，還有 js coloumn sorting、inline editing，有這個我應該就懶得用其他的東西了。
• Layouts： 強大的 layout manager，雖然很難說明，但可以看一下 Feed Viewer 的 example。
• Resizable： 沒錯！圖片、文字框都可以即時改變大小！
• Tab Panel： 這已經是 Ajax 時代必備的元件了，不用多解釋了。

總觀 yui-ext 的功能要比還是比不過 Dojo 等超強的 js 元件，但問題是實用性。為了一個 dojo fisheye 去用 dojo 可能有點痛苦，而 YUI 及 yui-ext 在絕大多數的情況你只要選你用的元件就好了。在 code 的撰寫方面，YUI 系列的 javascript 更是優雅到一個極點，寫起來完全跟在寫一般的 local application 的 UI 有接近。是一個非常推薦使用的元件，不管是只用一小部份還是全系統套用，都非常有價值。

在 web-based application 的環境，大家都想把很多很多的功能放在網站上，版面就變成亂七八糟，也佔得滿滿的，使用者永遠找不到它要的東西。如果有 Tab Panel 跟 Layouts 兩個元件，就像 Feed Viewer 的範例一樣，把版面做最好的利用。有時候，user 也會無聊的跟你要求什麼要大一點，什麼又要小一點，與其為了這種雞毛蒜皮的事情浪費人力，不如弄個可以 resize 的給 user 自己去調！當 web 不再是只有 page 的時候，可以套用的外觀設計也會跟著開闊。

technorati tags:YUI, Yahoo, yui-ext, UI

Blogged with Flock

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

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

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 潛力很大。

其他如 Trails、Project 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:Appfuse, RIFE, JBossSeam, Grails, Trails, ProjectAble, Struts, Spring, Hibernate, EJB, EJB3

Blogged with Flock

Validation with Annotations — 驗證新趨勢

Validation 是每個像樣一點的系統必備的功能，不過做法就有很多了。以 Java Web AP 為例，從 JavaScript 的 Validation 到使用 Java Code 去做，或是使用 Jarkata Commons Validator 都是很常見的方法，也各有優缺點。

最近在網路上出現了一些跟 Validation 相關的文章，包括有 Hibernate can meet your validation needs 和 Spring Validation with Java Annotations。或許你會奇怪，Hibernate 跟 Spring 並不是在處理 Validation 的事情的。到底是怎麼回事呢？原來現在最流行的 Validation 方法是使用 Annotation！在 domain model class 的 getter/setter 上加上 Annotation Tag，例如：@Required 就代表這個值是必需填入的。@Length(max = 10) 代表最長不能起過 10 個字元等等。在 domain model 宣告完成後，在需要時再由 Java 程式去執行驗證，而驗證是自動依據 Annotation 的設定所做的。

不管用 Hibernate 或是 Spring 做，概念上都大同小異。把 Validation 資訊放在 domain model 的好處是，不管在哪個 level 想做驗證，都會用到同樣的資訊。否則很有可能會變成在 User Input 寫一段，存取 DB 時又寫一段。而事實上驗證的資訊放在 domain model 事實上是最適合的了，因為驗證限制可以說是 domain model 的一項註解。

Annotation 在 Java 5 出現以來，有很多範例應用。但相對實戰上使用，而且必需要使用 Annotation 才能達成的任務一直都不是很多。直到最近，不少 Annotation 應用都已經成熟。不久的將來，Annotation 就會變成常用的 Java 語法，而系統中出現 Annotation 就跟出現平常的 code 一樣自然。

technorati tags:Annotation, Validation, Spring, Hibernate

Blogged with Flock

13 本 Ajax 最重要的書

Agile Ajax: Social Network Analysis of Ajax Books

這篇文章的作者做了一個有趣的研究，由幾本 Ajax 的書開始，透過 Amazon 的 “customers who bought this book also bought…” 的功能，找出以下 13 本最重要的 Ajax 書籍。

1. “Ajax in Action”
2. “Professional Ajax (Programmer to Programmer)”
3. “Head Rush Ajax”
4. “Ajax Patterns and Best Practices (Expert’s Voice)”
5. “DOM Scripting: Web Design with JavaScript and the Document Object Model”
6. “Foundations of Ajax (Foundation)”
7. “Hibernate in Action (In Action series)”
8. “DOM Scripting: Web Design with JavaScript and the Document Object Model”
9. “Programming Ruby: The Pragmatic Programmers’ Guide, Second Edition”
10. “Bulletproof Web Design: Improving flexibility and protecting against worst-case scenarios with XHTML and CSS”
11. “CSS Mastery: Advanced Web Standards Solutions (Solutions)”
12. “Professional JavaScript for Web Developers (Wrox Professional Guides)”
13. “Ajax Design Patterns”

研究所的時候看到不少人用這種社會網路手法做研究，而這個卻是我看過這種手法中得出最實用的結果，至少告訴你別人都看了什麼書，輸人不輸陣，跟著看也準沒錯。比較怪的結果是第 7 本，Hibernate in Action，那本質上跟 Ajax 也沒有什麼關係，不過也突顯了 Hibernate 的重要性。休閒時，多看書，如果想要對 Ajax 更了解，這些想必是不錯的選擇。而我，已經看完第 1,7 兩本了。不過如果是想看 Hibernate 的入門書，最好還是先看 Hibernate Quickly，Hibernate in Action 太深了一點。

technorati tags:Hibernate, Books

Blogged with Flock