對於網頁開放人員而言，不論使用的是asp/java/php，甚至是python或ruby，最令人頭痛的問題，除了各語言本身的限制、使用者不斷改變的需求之外，大家共同的痛應該就是同時支援多種瀏覽器時的測試問題。
不同的瀏覽器對javascript/css甚至是html語法，都有不同的支援，可能是對w3c標準的遵循程度，也可能是顯示方面的細節，這些不同，成為網頁開發人員最頭痛的問題。
IETester是一個可以同時以XP或Vista的IE 5.5, 6.0,7, 8 beta 1的方式，顯示相同網的測試工具，雖然在java applet跟flash上還有些問題，但還是能大大減輕開發網頁時的負擔。
最近想把一些之前用ruby/python寫的小工具加上GUI，找了一下GUI的函式，決定用Qt+Ruby/Qt+Python 來做，不過，QtRuby在windows下一直不是很好裝，還好最新版的QtRuby有了gem包裝，雖然沒辦法用gem 直接remote install，不過，總是方便一點了。
在Windows XP下安裝ruby 的Qt4 binding方法如下：
可以開始用ruby + qt寫GUI程式了
安裝Python 2.5.2 與PyQt binding方式如下
大功告成
/pluto
geronimo-admin
/testsuite
geronimo-admin
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/>
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/>
maven 是一個比較新近的java 專案開發工具，能夠簡化開發人員設置專案開發環境的程序與步驟，快速的進入專案的開發階段。透過Convention over Configuration 的概念以及設定檔的繼承機制，maven能夠讓團隊中所進行的各個開發專案有相同的檔案結構，同時也讓個別專案所需要進行的設定減到最低。
maven 預設的檔案結構如下
/src
/main
/java
/resources
/configuration
/webapp
/test
/java
/resources
/configuration
/target
以 main子目錄下放置專案的production code，test下則放置專案的testing code以及configuration，專案建置(build)的結果與過程中的中間產物則會產生在target子目錄之下。/src/main/webapp則是進行網頁專案開發時的特別目錄，放置如web.xml等等的網頁相關資訊。
maven的設定檔(如同ant的 build.xml)稱作pom.xml(project object model)，設定了如建置環境(java 版本，application server)，相依性(使用到的其他library及版本)。
設定檔的設定方式都是定義式的，如在相依性的設定中，僅需定義使用的library的名稱與版本，在建置過程中，maven會依據所設定的相依性，由repository中取得所需要的函式。定義式的設定檔另外一個好處就是與系統維持最低的相依性，同樣的設定檔，不過是在 *nix或是Windows系統下，都能夠正常的使用。
專案設定檔間的繼承提供了一個能夠設定團隊中跨專案的共通性設定的地方。在一般的團隊中有許多跨專案的共通規範，如coding convention, coding style, test rule等等，團隊能夠建立一個團隊的pom設定檔，而個別的專案，只需要繼承這個團隊設定檔即可擁有相同的設定，不需要在個別的專案設定檔中重複的進行這些共通的設定。
晚上在Ubuntu上把trac 裝好了，因為clearsilver的so link 會遇到一些問題，所以，把過程記錄下來。
sudo apt-get install trac apache2 libapache2-svn
sudo mkdir /var/lib/trac
sudo chown www-data:www-data /var/lib/trac
ScriptAlias /trac "/usr/share/trac/cgi-bin/trac.cgi"
<Location "/trac">
SetEnv TRAC_ENV_PARENT_DIR "/var/lib/trac"
</Location>
Alias /trac/chrome/common "/usr/share/trac/htdocs"
<Directory "/usr/share/trac/htdocs">
Order allow,deny
Allow from all
</Directory>
做到這邊，trac 環境應該可以正常的運作了，如果需要使用者認證的話，則需要在apache的設定中加上以下設定 (Multiple project 環境)
<LocationMatch "trac/[^/]+/login">
AuthType Basic
AuthName "Trac"
AuthUserFile /somewhere/trac.passwd
require valid-user
</LocationMatch>
重新啟動apache，trac環境就可以正常運作了。
接下來，只需要在新增專案的時候，在/var/lib/trac下用trac-admin 的initenv command建新的trac repository了。
Code from RailsServlet
runtime.defineReadonlyVariable("$stdin", stdin);
runtime.defineReadonlyVariable("$java_servlet_request", JavaEmbedUtils.javaToRuby(runtime, request));
runtime.defineReadonlyVariable("$java_servlet_response", JavaEmbedUtils.javaToRuby(runtime, response));
搞了一整天，總算試出CXF的REST介面可以運作的設定模式，雖然wrapped mode一直搞不定，不過，總算搞定unwrapped mode的設定方式。主要必需注意的事情是:
範例 (interface), spring 設定中的 serviceFactory必需設定unwrapped = false
@WebService(targetNamespace="http://employee.some.company.com")
public interface EmployeeService {
@Get
@HttpResource(location="/employees/{serial}")
@WebResult(name="Employee")
Employee getEmployee(GetEmployee getEmployee);
}
這幾天的事吧，剛開始用，有幾點還不錯的改善。
在WebWork/Struts 2的應用框架中，可以讓系統開發者在寫程式時，專注在應用系統的邏輯，透過IoC的注入(injection)方式，程式碼中可以完全看不到與JavaEE相關的程式碼。但是這種美好的世界，在遇到一些需要根據使用者傳回不同的結果的action時，就不是那麼美好，除非你所開發的應用系統自行處理使用者權限與授權相關的功能。如果是使用JAAS，那程式中不免會需要透過HttpRequest來取得remoteUser等資訊。在Struts2/WebWork中，提供了兩個介面可以做到這樣的功能 HttpRequestAware 與 PrincipalAware。
HttpRequestAware 是第一個會想到的介面，既然remoteUser的資料是從request來的，那就叫struts幫我們注入個request object不就成了？但是一但在action中引入HttpRequest，使用Struts2/Webwork的最大好處，與平台低相依性，易測試的優點就當場被破壞了。當引入HttpRequest之後，為了測試action，必需透過如spring-mock等等的JavaEE mock 套件，無法簡單的透過如jmock, 或是自行打造stub的方式來進行測試，而且，只是需要getRemoteUser, isUserInRole等function，卻把整個HttpRequest 都暴露在action中，怎麼看味道也不對。
PrincipalAware 就是為了解決上述的問題產生的，如果你只是很單存的需要getRemoteUser, isSecured, getPrincipal, isUserInRole等功能，那action只需要實作PrincipalAware，Struts2/WebWork會為action注入一個PrincipalProxy，提供getRemoteUser等需要的方法，又不需要將整個HttpRequest都暴露在action中，造成與平台過度的相依。更好的是，PrincipalProxy是一個interface，可以利用jmock, dynaMock等mock framework簡單的產生測試時需要的替代品，對自動測試可是一大利多。
使用WebWork到現在，也好幾年了，居然到現在才發現有這個interface，該說是後知後覺，還是太不認真了，不過，這個介面可是解決了以往為了測試這些需要principal 的action，而搞了幾乎整套的JavaEE stack的問題，又能夠滿足整個應用系統的味道能夠一致，真該認真點的。
以前的同事pj曾經說過一個笑話，一群人開車到郊外踏青，在差不多算是荒郊野外的地方車子故障了，一群人急得想各種辦法要把車子修好，但是都徒勞無功，最後，一位在微軟工作的軟體工程師說話了：「我們把車子熄火，全部的人下車，再上車試看看，可能就沒問題了。」凡是用過電腦的人，多多少少會遇到類似下車再上車的狀況，對像可能是特定的應用程式，也可能是整個作業系統，怎麼找就是找不出問題，但是，把程式重開或是重開機之後，問題就不見了。而開發人員遇到這種狀況的機會又比一般的使用者來得高。
這種狀況，常常是因為系統在開發過程中沒有考慮到一些特定的狀況所造成的。但是隨著作業系統愈來愈複雜，今天，除了特殊的應用之外，單工的作業環境已經愈來愈少見了，導致要在開發階段就考慮到所有的狀況已經是愈來愈不可能了。為了因應這種狀況，近代的程式語言大都包含了例外處理的機制，這個機制最主要的目的就是讓程式在遇到開發時期未考慮到的狀況時，能夠死得漂亮一點，死得優雅一點，最低限度，要讓使用者知道，程式已經死了，而不是讓使用者去和一個不穩定狀態的系統打交道。
例外處理，是程式設計的一個很重要的課題，雖然有些人認為例外處理讓部份程式流程更不容易被追蹤(trace)，但是不可否認的，在支援例外處理的程式中，程式碼可以以更容易被人類讀懂的方式來表示，而不是一長串的if/else if /else。畢竟，程式碼除了建立系統之外，也是程式設計師之間最主要的溝通工具。如果說，少男漫畫中的主角是用拳頭交心，那程式設計師就是用程式碼交心了。
這幾年，wiki (維基)愈來愈紅，不管是公司、社群，甚至個人常常都會有個wiki。但是愈來愈紅代表的也就是選擇可能會愈來愈多，在wiki的領域，可選擇的軟體也愈來愈多，甚至也可以偷懶直接使用別人的wiki 主機服務。這麼多的wiki怎麼選呢? 當然，就是要靠比較多，這次介紹的網站，就是可以幫你比較常見的wiki間的差異、支援等等，讓你更方便的選擇一個自己的wiki。
這個網站收錄了87個Wiki軟體及服務(主機服務)，可以讓你對各個wiki之間的功能作詳細的比較，更提供了一個Wiki Choice Wizard，透過幾個問題，先幫你作篩選，讓你不用在87個軟體間漫無目的的尋找，需要wiki嗎? 挑個自己合用的吧!!