Tin's Blog

     摘要: TSS上面Ganesh同志的文章內容是非常有益的，討論了session的這兩個api的區別。get是每次都會從數據庫取數據以保證數據的可靠。而load則會返回一個proxy，相當于一個存根，訪問的時候從當前session或者hibernate二級緩存中查找，如果找不到則從數據庫中Lazy Load一下。從Hibernate的復雜性上來說，這個概念應該算比較容易理解的，而且這種存在也是非常合理的。順便里面還補充了一下JPA里面也有類似的getReference方法，行為類似load。看完文章你會開始注意這個細節。
可是，這個細節的下面卻引起了n多人的討論，討論的核心就是Hibernate是不是有太多細節了？
很多人說這樣不是OO的，很多人說Hibernate的細節造成它復雜，有人說Hibernate影響了他們的工作效率，等等，反正反對者站出來很多。我想這是可喜的。
說明在Java的Killer-APP組合Spring+Hibernate后面還是有很多持懷疑態度的人的，我們隨時都需要提問題的大腦！
所以，我們也思考一下吧：  閱讀全文

     摘要: 本文翻譯自IBM DeveloperWorks上的一篇文章，該文講述了測試分類(test categorization)的概念，本身這個概念很簡單，但是卻實際的解決我們常見的問題，在我們的測試龐大到一定地步的時候，測試的運行時間過長，維護成本很高，我們如何能夠保證持續集成(CI)的正常運行？那就是通過測試分類。所以我翻譯了這片文章，希望對大家有所幫助。  閱讀全文

     摘要: 這個問題出現在這種情況，你的每個testCase都需要使用某一種初始化比較耗時的對象（資源），舉例如數據庫連接、Spring Context。我們遇到的問題是Selenium測試中開啟和關閉瀏覽器，如果一個test啟動關閉（我們的程序還需要登錄和注銷），這樣測試的時間會拖的很長，給持續集成帶來了困難。
所以……  閱讀全文

     摘要: Selenium Remote Control項目組很高興的宣布Selenium Remote Control 0.9.0發布。
你可以在這里察看：
http://www.openqa.org/selenium-rc/
也可以在這里下載：
http://www.openqa.org/selenium-rc/download.action
0.9.0包括很多酷玩意，包括frame支持，多窗口支持（用來測試那些不能夠在子frame中運行的應用），一個Konqueror瀏覽器launcher，新的cookie管理功能，和Firefox 2.0與IE7的支持。還包括一個試驗性的在Selenium代理中直接的SSL支持，一個新的實驗性的“代理注入（proxy injection）”模式允許我們通過修改HTTP代理來更好的控制我們測試的應用程序。
Have Fun！  閱讀全文

     摘要: 歡迎所有對Selenium感興趣的（翻譯的過程就是很好的學習）或者已經使用Selenium的同學積極參加，參加的方式可以是：直接參與翻譯，編寫原創學習文章并添加到相關資源列表，交流心得并將心得添加到相關資源列表，提供使用的視頻片斷，推薦好的Selenium文章進入翻譯計劃，提出你自己的意見。以上方式都非常歡迎，可以發信給我進行溝通（iamtin AT gmail.com）。
目前我們使用JavaScud的Wiki進行翻譯工作，網址如下：
http://wiki.javascud.org/display/SEL/Home  閱讀全文

     摘要: 濃縮一下：
1、何時、何目的來用Selenium選擇不同。RC、Fit適合從需求階段就開始寫。而IDE錄制則適合后補。
2、重構支持。RC重構友好一些。Fit重構不友好。
3、IDE目前限定于FF，做跨瀏覽器RC比較好。但是IDE錄制后的代碼很方便轉為RC方式。
4、跨域兼容性問題，IDE解決的比較好。  閱讀全文

     摘要: 我用的是Eclipse 3.2，操作系統是WinXP SP2。
需要把eclipse\plugins\org.eclipse.swt.win32.win32.x86_3.2.0.v3232m.jar里面的swt-win32-3232.dll解壓縮出來拷貝到WINDOWS\SYSTEM32里面。
然后就OK了。
是在Eclipse里面運行Springside的ANT Task的時候，如果需要通過console輸入交互信息，則會報這個錯。應該是因為Eclipse的console依賴于那個本地庫，而平常我們安裝Eclipse不會拷貝那個庫。大概如此了。  閱讀全文

     摘要: 說說遺憾：
1、OSGi在B/S架構中還不好應用。雖然例子是B/S的，可是居然是Servlet模型，里面解釋了目前Equinox項目也在擴展應用服務器支持和JSP支持等，可是起碼目前還不成熟。
2、模塊的粒度很成問題。目前OSGi的契約機制與java interface機制對比一下。OSGi不可能完全取代本地的interface式的解藕，當然人家也沒這么說。只使我擔心過渡設計后，過細的Bundle肯定會得不償失，所以需要有人設計/計劃這個粒度。這個可能與基于Web services的SOA架構面臨類似的問題，需要好的架構師。
3、文檔不友好么？說實話，很感謝BlueDavy和OSGi觀察者那些大牛的貢獻。但是感覺production的樣例工程還是很難搞到（其實Eclipse plugins的例子滿多哈，可惜沒啥文檔，需要硬著頭皮看），對應的指導文檔還沒出現。BlueDavy提供的servlet實現我們不可能跟上，畢竟簡單也是一種需求。（那誰說過度設計比設計不足更可怕，那個我不是唱反調，我希望我們都能找到那個sweet point，有個好的參照那最好不過了）。 <  閱讀全文