Tin's Blog

     摘要: 自己申請域名把blog遷移了一下。因為內容也很少和Java相關，感興趣的朋友輕修改一下訂閱地址。
Rss: http://feed.feedsky.com/iamtin
Blog: http://tin.zztin.com  閱讀全文

     摘要: 在中文網織年會上和啄木鳥老大HD討論了一下好看簿的架構問題，而后老黃寫了一個blog entry：
架構考量-選擇的難度
里面談到了架構一個高支撐能力的Web 2.0應用需要考慮的架構選型問題，對我很有幫助。我也回復一下他的建議：  閱讀全文

     摘要: Twitter的水平擴展的一些關鍵點，雖然它是個RoR應用，但是這些建議絕對是放之四海而皆準的，非常好的總結。
因為年初Twitter曾經遇到了性能瓶頸，而且幾乎束手無策。當初很多人開始懷疑Ruby的性能問題，而后Twitter站起來了 ^__^
有時間的朋友看看這個slide：http://www.slideshare.net/Blaine/scaling-twitter，沒有時間的看看我的摘要。  閱讀全文

     摘要: 一位ID是jackson1225的網友在javaeye詢問了一個大型Web系統的架構和部署選型問題，希望能提高現有的基于Java的Web應用的服務能力。由于架構模式和部署調優一直是Java社區的熱門話題，這個問題引發了很多熱心網友的討論，其中一些意見對其它大型Web項目也有很好的指導意義。  閱讀全文

     摘要: 架構師這個概念比較虛。在國內，架構師其實就是有強烈基礎傾向的開發者，他們有很大的熱情來實驗一個自己熟悉或者感興趣的東西，從概念上這不是架構師。
我很關注國外的一些架構師描述如何成為架構師。架構師其實最重要的是見識！要無傾向性的研究技術和需求。我很喜歡的印度的一位精神導師克里希姆納提說過自由的前提是要學會聆聽，而聆聽就是在聽的時候心理不要有任何反抗或者評論的去聽，所有的思考都要留在聽到以后。電影《教父》里面有一句臺詞我非常喜歡，不要仇恨你的敵人，因為那會影響你的判斷力。我想這都是一個意思。如果想要成為架構師就要多聆聽，然后思考，又清楚的判斷力，這樣選擇才會是正確的！  閱讀全文

     摘要: 我覺得fins同學的一些說法會造成沒有深入使用這幾個框架的朋友的誤解。因為這幾個框架的思想是不一樣的，所以它們的語法也是不同的。fins同學的評價似乎更像從Java的OO想法來評價幾個js框架。
其實，moo一開始的想法就是light weight，所以它的很多語法其實就是沒有語法。fins說的json語法，其實就是js里面的散列對象嘛，javascript語法本來就是這個樣子呀，不包裝就是這樣。而這種方式如果寫的好讀起來很像DSL，很舒服，moo充分發揮了這個好處。
prototype和JQuery都沒有強調繼承這樣的概念。javascript的強大很大就來自它的原形繼承，如果要用好它就要利用好原形繼承。prototype在這方面很像Ruby，比如 Enumerable，這是一種按照行為的抽象，很符合Ruby/Python里面Module的想法，并非所有行為都要抽象到一個對象再繼承，行為本身也可以抽象再混入。  閱讀全文

     摘要: javaeye的hax最近在他的blog上進行了一場關于如何寫css的討論，其中反思和討論了一些關于基于標準或trick進行設計的選擇問題，這個問題也是David Heinemeier Hansson對于XHTML/CSS/Javascript標準進行RIA開發話題的一個延展。我們可以從中思考如何在不完美的技術中選擇一條相對完美的技術路線？  閱讀全文

     摘要: 非常好的職業建議，來自Scott Adams
從一個非常喜歡的人的blog看到的，這個人是Tomcat的作者，現在是Apple的Object C開發者，兼重要的RoR作者，兼資深攝影師，兼Mac大fans，他叫James Duncan Davidson（http://duncandavidson.com/）。
在一篇Blog講到，Scott Adams說：
每個人都可以找到通過一些努力就可以躋身前25%的行業。例如我，我可以比大多數人畫的好，但是我還夠不上藝術家的水平。我也沒有達到喜劇演員那種好笑的水平，但是我比大多數人好笑。魔法在于沒什么人即畫得好又會寫笑話。所以混合一下我就很稀有了。加上我的商業知識背景，我突然發現我比其它的動畫人更能理解它（商務）。  閱讀全文

     摘要: 本文已經發表于InfoQ中文站點（http://www.infoq.com/cn/news/2007/07/light-web-servers）

IBM developerWorks網站上最近發布了一則Cameron Laird的關于輕量級Web服務器的文章，里面列舉了很多的輕型的Web服務器實現和它們的特點，Cameron還從自己的經驗出發總結了評價Web服務器的一些指標。這篇文章目的在于擴展我們在 Web應用部署時的思路，讓我們重新思考Web應用的架構和部署方案。眾多的輕量級Web服務器其實見證了動態腳本語言實現Web應用的火爆，給實現 Web應用提供了更多解決方案。

輕量Web服務器這個概念關注“輕巧性”，這意味著簡單、易于安裝、流線化、要求低和健壯。這種“輕巧”主要是相對于目前市場占有率占優的 Apache和IIS而言的，輕量Web服務器應該更小更簡單，并且它們至少要有一些性能／特性超過這兩個產品（這樣它們才可能分得市場份額）。 Cameron這樣對比了“輕量”相比“重量”的一些優勢：  閱讀全文

     摘要: 有幸在InfoQ的飯局里面認識了王翔，他對.Net和MS技術的確有非常深的造詣。今天看到他的一篇評論：“C#正變得越來越臃腫”
發表了一些感想：

先進與成熟的確是矛盾，但是現在的新技術成熟的都比較快，可能是人接受新事物的速度提高了吧。
Haskell 這樣的語言是函數式編程的代表，更多的需要從頭開始。所以國外學計算機理論首選Haskell，很多老外抱怨過上學的時候這個東西學的頭疼，但是后來他們也都表示獲益匪淺。我們的計算機教育是本末倒置，所以我們這些程序員覺得他們晦澀難懂。但是看到Erlang這樣的語言，在未來多核環境下的前途，我們還是會動搖的。  閱讀全文

     摘要: 本文已經發布于InfoQ中文站（http://www.infoq.com/cn/news/2007/07/java-securejsh-publish），感謝Complystill為我們貢獻了SJSH這個項目。

JavaEye上活躍的開發者Complystill（歆淵）最近發布了自己的開源SecureJSH項目，提供了一個通過SSH交互進行Java應用開發或者管理的工具。

在項目的介紹中可以得知，SecureJSH與Ptyhon里面的ipython或者Ruby里面的irb非常相似。它們都允許交互式運行語言的代碼，以方便跟蹤或者調試應用。但是，Java與Ruby、Python不同，后者是動態腳本語言，它們天生具有解釋執行的特點（注意：當然Python支持預編譯，Ruby也將在YARV中開始支持，這里指它們的解釋執行狀態）。我們常見的Python和Ruby發行版本基本上都包括自己的解釋器（這也是它們的核心組件），但是Java是一種需要中間編譯過程的語言，默認情況下它無法直接解釋運行，也沒有相應的解釋器。  閱讀全文

     摘要: http://developer.yahoo.com/yslow/

這是一個配合Firebug工作的firefox插件。能夠對你訪問的頁面進行分析。
它可以：
* 性能報告
* HTTP/HTML信息匯總
* 列出頁面中的組件
* 包含了JSLint  閱讀全文

     摘要: 在這里發現了一個技巧：http://rubyisawesome.com/2007/7/10/mysql-secrets-g-instead-of
在Mysql的命令行工具里面給查詢加入一個\G參數。橫向的表結構會轉為使用縱向表結構輸出，利于閱讀。  閱讀全文

     摘要: 這是敏捷中國的一個討論，我問了一下架構設計是否在敏捷迭代過程中有一席之地？大家產生了如下討論。如果我的引用冒犯了當事人，請email我，我會及時修改的。我希望大家能夠一起討論這個topic。  閱讀全文

     摘要: 13日，Joyent宣布基于GPL v2將Slingshot和Connector開源。Joyent Slingshot允許開發者將Rails應用程序部署為與桌面應用行為一致，可以在線或者離線（保持同步），可以拖拽，與所有其它桌面應用程序交互等。另外，Joyent還提供了Connector產品和一組可以與Joyent Slingshot協同工作的第三方應用程序。  閱讀全文

     摘要: JavaEye的站長Robbin Fan在他的博客中對SAAS(軟件即服務)進行了一番討論，他總結了目前常見的一些SAAS應用，并且總結了這些應用的特點，展望了SAAS的發展方向。
2005年，David Heinemeier Hansson將自己在項目中使用的基于Ruby的開發框架剝離并開源，從此世界上有了RoR（Ruby on Rails）的響亮名號。很快，Rails在其它語言中也架設了自己的高速軌道，從此Rails思想處處開花，受到了廣大開發者的擁護，這是Rails的敏捷本質決定的。隨著RoR閃現在開發者眼前的還有Rails背后的公司37signals，這是一家位于芝加哥的創業型小公司，雖然他們的員工目前還是個位數，但是開發出的產品卻有超過100萬人在使用……  閱讀全文

     摘要: David Heinemeier Hansson（以下簡稱DHH，Ruby on Rails作者）在最近的一篇Blog“如果我真的喜歡HTML、CSS和Javascript，那又怎么了？”（What if I actually like HTML, CSS, and JavaScript?）中闡述了他對RIA未來的一種看法。他認為目前在三大Web標準規范下的HTML、CSS和Javascript是一套足夠強大的工具箱，這些技術提供給開發人員的功能并沒有影響到Web應用的發展，并且隨著像Firebug和其他優秀Javascript庫的支持下，Web程序員的日常開發工作已經非常愜意了。  閱讀全文

     摘要: 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，有個好的參照那最好不過了）。 <  閱讀全文

     摘要: 先分析一下在輕量化的Java EE下面他們存在的意義：
1、有的人說過在Web項目中Manager和DAO是同意的，尤其是在透明ORM存在下，DAO由于往往是CRUD的實現場所，而Manager卻往往是薄薄的一層門面，很多人就在質疑兩者的合并問題?？墒莚obbin曾經進行過一個精辟的分析，雖然兩者做的看起來差不多，可是兩者的事務屬性卻不一樣，Manager應該有清晰的事務界限，而DAO不應關心于此。也就是說Manager可能會將幾個DAO方法組合調用，然后封裝在一個事物中。這樣說明確了兩者的一個重要區別，我們也能體會在使用聲明事務的時候有一個分明的事務界限是很有意義的，否則就有可能把Manager中的一個事物拆分，這樣實際上就錯誤了。
2、有些人質疑透明ORM存在的情況下DAO存在的意義，因為透明ORM基本已經隔離了不同數據庫的方言區別。這個也很簡單，Rod大叔分析過。透明ORM存在的情況下DAO起到了隔離透明ORM與EJB或者JDBC實現的作用，這幾種實現實際上是應該考慮到的。
3、還有一個問題，就是DAO是否應該隱藏透明ORM的API。因為前面說到了DAO起  閱讀全文