Read Sean

          Read me, read Sean.
          posts - 508, comments - 655, trackbacks - 9, articles - 4

           

          由Craig Walls和Ryan Breidenbach合著的新書《Spring in Action》已交付印刷,北美市場和Amazon應該很快會上架,期待國內的引進版。另外不知道有沒有人愿意翻譯,如果有時間,我也想參與,呵呵。有路子的朋友別忘了通知一聲哦。

          sia_thumb.jpg

          你如果對這本書和Craig Walls感興趣,可以上Craig的blog了解該書的最新動向。

           

          posted @ 2005-02-17 00:28 laogao 閱讀(599) | 評論 (3)編輯 收藏

               摘要: 春節長假即將結束,想想已經有好久沒更新自己的blog了,正在等Arsenal和Crystal Palace的比賽轉播,也睡不著,就寫寫最近的一些感想吧。這些天除了走親訪友、合家團聚、請客吃飯之外,也看了一些電影,玩了一些游戲。印象最深的是那一部一年前在美國上映的......  閱讀全文

          posted @ 2005-02-15 02:09 laogao 閱讀(463) | 評論 (2)編輯 收藏

           

          幾天不上技術網站,今天在Apache News Blog Online發現一個新東東:Struts Shale。這個是由Craig McClannahan發起并新近加入Struts的子項目,在這篇blog文章中,原來的Struts項目被稱作Struts Classic。Struts Shale的主要目的是提供一個開源的基于JSF的Struts框架。

          可能不少朋友還記得我前不久一篇關于Craig如何評價Struts和JSF的文章,看來Craig確實還挺有號召力的。

          感興趣的上這里下一個Shale版本預覽一下吧:

          http://cvs.apache.org/builds/jakarta-struts/nightly/struts-shale/

           

          posted @ 2005-02-01 22:33 laogao 閱讀(320) | 評論 (0)編輯 收藏

           

          大半年的時間都在忙這個項目,雖然現在離UAT還有一段時間,但是還是覺得應該給自己一點小小的獎勵了,于是和LP一起去選購了一套迷你音響。見下圖:

          ONKYO1.jpg

          怎么樣,還不錯吧?

          買了之后才有閑暇去想這件事背后的東西:原來適當的消費對于長期高度緊張的IT類工作相當有好處,有助于改善工作狀態和調整心情。畢竟誰都受不了成天對著電腦,擔著沉重的壓力,而沒有合適的途徑去宣泄的。

          希望大家不要跟我前段時間一樣,把工作當成了全部,忽略了生命中其他美好和重要的東西。

           

          posted @ 2005-01-24 13:02 laogao 閱讀(476) | 評論 (1)編輯 收藏

          ?

          <回復格式>

          First Name:

          Last Name:

          E-mail:

          請完整填寫以便順利接收邀請。

          posted @ 2005-01-21 09:15 laogao 閱讀(2011) | 評論 (34)編輯 收藏

           

          一個典型的J2EE項目通常應該使用哪一種開發流程呢?流行開發流程有很多種,應用比較廣泛的有:瀑布式、迭代式、以及RUP (Rational Unified Process)。每一種都有其優點和不足,所以通常我們應該把它們結合起來而不是認定其中一個然后100%按著它的規范走。

           

          首先來看看每一種大致是什么意思:

           

          [瀑布式]

          這種模式的流程強調在開始編碼和測試之前完成所有的需求分析和設計,這種模式歷史相當久遠,也很成熟,甚至到了今天,這種模式還是被廣泛的采用到絕大多數公司和項目中。采用這種模式開發的項目通常很大,并且需要較長時間交付。正因為如此,這些項目通常會有更多的風險:在業務需求不斷變化的今天,如果待開發的系統不能及時反應出這些需求的變化,最終開發出來的產品可能已經不是客戶真正需要的了。

           

          [迭代式]

          為了應對傳統瀑布式的開發在處理需求變更上的不足,近些年出現了一種全新的極限編程的概念。極限編程(XP)的核心思想在于:從長遠看,早期發現錯誤以及降低復雜度可以節約成本。極限編程強調我們將任務/系統細分為可以在較短周期解決的一個個子任務/模塊,并且強調測試、代碼質量和及早發現問題。通常,通過一個個短小的迭代周期,我們就可以獲得一個個階段性的進展,并且可以及時形成一個版本供用戶參考,以便及時對用戶可能的需求變更作出響應。

           

          [RUP]

          RUP的全稱是Rational Unified Process,是一套定義得很完整的軟件工程模型。它強調編碼前的需求分析和設計,以及短迭代周期的開發和發布。它鼓勵團隊首先開發項目中風險最高的模塊,用更多的時間發現和應對問題,當設計需要變化時,它也能夠在一定程度上減輕一些重復工作。不過,因為RUP十分嚴謹,也比較具體,通常要完全跟著這個流程走也不是100%必要。

           

          下面我們來看看實際上我們應該采取什么樣的流程或者策略:

           

          實際的J2EE項目中,RUP的應用呈逐年上升的趨勢,不過也并非所有這些采用了RUP的項目也是完完全全RUP式的。我們可以考慮一種綜合上面三種流程的優點的方式,根據具體的項目量體裁衣。需要對這幾種的優點來一個總結:瀑布式由于比較成熟,通常很好的強調了先需求后設計再編碼的重要性,也比較適合大公司先預算后執行的方式;極限編程強調測試先行和簡單是美,這樣有利于及早發現問題以及更好的應對變化;RUP強調的集中化的分析和設計也有其不可替代的優越性。

           

          要做出一個結論性的答案并不容易,如果貴公司相對較大并且愿意支付一定的管理成本來推一套成熟且完整的開發流程并在公司內部所有項目或者是大多數項目嚴格執行,我想RUP應該是首選;如果貴公司希望有更大的靈活性,可以考慮一些折衷的方案,根據具體的項目,從上面三種流程提取有價值的部分,來確定具體的流程。

           

           

          posted @ 2005-01-16 23:18 laogao 閱讀(860) | 評論 (0)編輯 收藏

           

          有人做了一個總結:一個J2EE項目組通常會有怎樣的人員結構,或者說,一個J2EE項目通常需要怎樣一組代表不同的工作性質及內容的角色。實際情況中,一個人可能同時承擔多個不同的角色,一個角色也可以有很多不同的人來分擔。這些角色包括:

          • 項目經理
          • 架構師
          • 領域專家
          • 美工
          • 前端開發人員
          • 后端開發人員
          • 數據庫設計師
          • 數據庫管理員
          • 數據移植專員
          • 系統管理員
          • 測試人員

          其中,項目經理負責安排和協調整個開發小組的任務和進度,向決策層和用戶代表反饋項目進展和狀態,以及負責保證項目組或者其成員所需的所有資源足夠完成項目開發并及時到位;架構師負責項目的總體技術選擇、系統設計和指定具體的技術標準和細節,通常也需要跟整個小組緊密協調;領域專家負責采集和分析用戶需求,在整個項目開發過程中了解和確保產品能夠符合最終用戶的要求;美工設計用戶界面;前端開發人員按照美工的藍圖增加具體的前端處理邏輯;后端開發人員實現具體的業務邏輯,通常包括持久層的操作;數據庫設計師負責通過領域專家提供的需求設計數據庫的表結構和表關系,如ER圖;數據庫管理員根據ER圖生成實際的數據表,并對數據庫進行維護,以及協助優化數據庫和SQL查詢語句性能等;數據移植專員負責編寫移植腳本,幫助客戶將原有系統數據導入新的系統;系統管理員負責維護開發工作中需要的所有開發、測試、產品環境,以及進行產品發布;測試人員負責測試,保證開發出來的產品滿足需求文檔并沒有bug,測試人員應該具備一定的領域知識。

          拿一個具體的項目組來說:

          這是一個J2EE外包項目的開發組,共有人員30名,1個項目經理、2個領域專家、22個開發人員開發人員、1個數據庫管理員、以及4個測試人員。由于設計部分是由甲方做好,項目組沒有專職的架構師和數據庫設計師。項目采用EJB+Struts的總體結構。

          項目經理負責同甲方的項目經理確認任務安排和進度,以及協調項目組內部各成員的工作進展,并提供必要的行政和軟硬件支持,同時執行項目經理的其他日常工作,如配置管理等。2個領域專家參與同甲方領域專家的溝通,確保拿到的需求文檔和設計文檔充足且合理,并參與SIT,確保最終的產品符合文檔的需求。數據庫管理員負責維護并同步甲方提供的數據庫,同時協助開發人員優化SQL。測試人員負責在不同模塊完成后進行功能測試以及最后的SIT。開發人員按照不同的模塊分成5個組,每個組又進一步細分為1個后端開發人員和多個前端開發人員,后端開發人員同時是該組組長。所有組長統一向項目經理匯報。

          由此可見,上面總結出的那個J2EE項目組成員角色清單還是相當有說服力。總體上,在這個項目組中,項目經理是其協調和溝通作用的單點,項目組的主體由開發人員構成(這不奇怪,本身就是要開發產品嘛),領域專家和數據庫管理員主要還是配合開發人員的工作,而測試人員則除了一般意義上的測試和配合之外,因為相對獨立于開發,也起到一定的對項目開發流程的監督作用。

          J2EE這個東東(可以理解為一組規范)本身就強調角色分工,當這些分工不同的角色都盡心盡力做好自己的工作,文檔齊備,并且各個不同的角色之間保持足夠的溝通,加上確定的流程,面向企業的Java項目就會更傾向于朝著健康可控的方向發展。

           

          posted @ 2005-01-16 22:11 laogao 閱讀(830) | 評論 (0)編輯 收藏

           

          前兩天在Java的官網上看到一篇Craig McClanhahan的采訪,是有關Struts、JSF和Java Studio Creator的。其中比較大的篇幅在說Java Studio Creator,對此我沒有興趣。我感興趣的是有關Struts和JSF的關系那一段,大意是這樣:

          JSF其實完全可以和Struts共存。在現有的Struts應用基礎上,開發人員可以逐個頁面的將JSP換作使用JSF的實現。Struts和JSF的最大區別在于Struts的特點在于它很好的實現了MVC模式的架構,而JSF則把重點放在了MVC其中的一部分:V,也就是視圖。所以它們應該是互補的而不是互斥的。

          對于未來的Struts 2.0,Craig也提出了一些設想,如把現在的三個類處理一個流程的模式改為使用單個類對應一個頁面的做法。

          這篇文章還提到有一點,就是J2EE 5.0的API將包含JSF這一部分的API,所以今后實現了J2EE 5.0的應用服務器上將都可以運行JSF。

          原文見:
          http://java.sun.com/developer/technicalArticles/Interviews/jsf_mcClanahan.html


          posted @ 2005-01-15 13:12 laogao 閱讀(716) | 評論 (0)編輯 收藏

           

          在TSS.com上看到一篇好文,有關Struts使用中各種不同的Action和ActionForm組合的利弊。我先消化一下,整理好,供大家參考。原文標題:Struts action mappings: Divide Et Impera,作者:Michael Juravlev。在TSS上的URL:http://www.theserverside.com/articles/article.tss?l=StrutsActionMapping

          說明:閱讀本文需要一定的Struts基礎。
          注:文中小寫的action不一定代表具體的Struts Action類,有時也指作為一個整體的action mapping。


          [1] 完整的action

          <action path="/aFullAction"
              type="somePackage.someActionClass">
              name="someForm"
              input="someJSP.jsp"
              <forward name="successful" path="someJSP.jsp"/>
              <forward name="failed" path="someOtherJSP.jsp"/>
          </action>

          首先,Struts的ActionServlet接收到一個請求,然后根據struts-config.xml的配置定位到相應的mapping(映射);接下來如果form的范圍是request或者在定義的范圍中找不到這個form,創建一個新的form實例;取得form實例以后,調用其reset()方法,然后將表單中的參數放入form,如果validate屬性不為false,調用validate()方法;如果validate()返回非空的ActionErrors,將會被轉到input屬性指定的URI,如果返回空的ActionErrors,那么執行Action的execute()方法,根據返回的ActionForward確定目標URI。

          這樣做的效果是:execute()僅當validate()成功以后才執行;input屬性指定的是一個URI。


          [2] 僅有Form的action

          <action path="/aFormOnlyAction"
              type="org.apache.struts.actions.ForwardAction"
              name="someForm"
              input="someJSP.jsp"
              parameter="someOtherJSP.jsp"
          />

          首先,Struts會在定義的scope搜尋someForm,如果找到則重用,如果找不到則新建一個實例;取得form實例以后,調用其reset()方法,然后將表單中的參數放入form,如果validate屬性不為false,調用validate()方法;如果validate()返回非空的ActionErrors,將會被轉到input屬性指定的URI,如果返回空的ActionErrors,那么轉到parameter屬性指定的目標URI。

          這樣做的效果是:沒有action類可以存放我們的業務邏輯,所以所有需要寫入的邏輯都只能寫到form的reset()或者validate()方法中。validate()的作用是驗證和訪問業務層。因為這里的action映射不包括forward(也沒有意義),所以不能重定向,只能用默認的那個forward。這種僅有form的action可以用來處理數據獲取并forward到另一個JSP來顯示。


          [3] 僅有Action的action

          <action path="/anActionOnlyAction"
              type="somePackage.someActionClass">
              input="someJSP.jsp"
              <forward name="successful" path="someJSP.jsp"/>
              <forward name="failed" path="someOtherJSP.jsp"/>
          </action>

          首先,ActionServlet接收到請求后,取得action類實例,調用execute()方法;然后根據返回的ActionForward在配置中找forward,forward到指定的URI或action。

          這樣做的效果是:沒有form實例被傳入execute()方法,于是execute()必須自己從請求中獲取參數。Action可以被forward或者重定向。這種action不能處理通過HTML FORM提交的請求,只能處理鏈接式的請求。


          [4] 僅有JSP的action

          <action path="/aJSPOnlyAction"
              type="org.apache.struts.actions.ForwardAction"
              parameter="someOtherJSP.jsp"
          />

          首先,ActionServlet接到請求后調用ForwardAction的execute()方法,execute()根據配置的parameter屬性值來forward到那個URI。

          這樣做的效果是:沒有任何form被實例化,比較現實的情形可能是form在request更高級別的范圍中定義;或者這個action被用作在應用程序編譯好后充當系統參數,只需要更改這個配置文件而不需要重新編譯系統。


          [5] 兩個action對應一個form

          <action path="/anAction"
              type="somePackage.someActionClass">
              name="someForm"
              input="someJSP.jsp"
              <forward name="successful" path="/anotherAction.do"/>
          </action>
          <action path="/anotherAction"
              type="somePackage.someOtherActionClass">
              name="someForm"
              input="someOtherJSP.jsp"
              <forward name="successful" path="someResultJSP.jsp"/>
          </action>

          就每個單獨的action來講,處理上并沒有和完整的action有什么實質的區別。這個組合模式可以被用來傳遞命令對象(form)。需要注意的是在后一個action中同樣會調用form的reset()和validate()方法,因此我們必須確保form中的信息不被重寫。

          處理的方式大致分為兩種:a) 在request中放入一個指示器表明前一個action有意向后一個action傳遞form,從而在后一個action可以保留那個form中的值,這一方式只能在使用forward時使用。b) 當使用redirect而不是forward時,可以把指示器放在session或更高的級別,在命令鏈的最后一環將這個指示器清除。


          [6] 兩個action對應兩個form

          <action path="/anAction"
              type="somePackage.someActionClass">
              name="someForm"
              input="someJSP.jsp"
              <forward name="successful" path="/anotherAction.do" redirect="true"/>
          </action>
          <action path="/anotherAction"
              type="somePackage.someOtherActionClass">"
              name="someOtherForm"
              input="someOtherJSP.jsp"
              <forward name="successful" path="someResultJSP.jsp"/>
          </action>

          這個組合方式跟前一種在流程上沒有太大區別,只是我們現在對于兩個action分別提供了form,于是代碼看上去更加清晰。于是我們可以分別處理WEB應用程序的輸入和輸出。值得注意的是,后一個action同樣會嘗試往form中寫入那些參數,不過我們可以這樣處理:a) 在后一個form中使用另一套屬性名;b) 只提供getter而不提供setter。

          大致的處理是這樣:
          前一個action接收輸入、驗證、然后將數據寫入業務層或持久層,重定向到后一個action,后一個action手動的從業務層/持久層取出數據,寫入form(通過其他方式),交給前臺JSP顯示。

          這樣做的好處是不必保留輸入form中的值,因此可以使用redirect而不是forward。這樣就降低了兩個action之間的耦合度,同時也避免了不必要的重復提交。


          posted @ 2005-01-15 13:10 laogao 閱讀(516) | 評論 (0)編輯 收藏

               摘要:   [版權聲明]作者保留本文的版權。如需轉載,請保持文章完整,注明出處,并保留此聲明;如需用于商業目的,須作者本人書面許可。作者的聯系E-mail: gaoyuxiang@gmail.com     [準備工作]   首先,為了了解J2SE(TM) 5.0的新的語言特性,你需要下載新版的JDK,在這里可以找到下載鏈接:http://java....  閱讀全文

          posted @ 2005-01-12 22:49 laogao 閱讀(5744) | 評論 (7)編輯 收藏

           

          我最近遇到了MSN登錄的奇怪問題,重裝N遍MSN也沒有用,登錄Hotmail似乎也是同樣的問題,最后發現原來是IE安全設置的問題。現在解決了,如果你遇到類似問題,希望這個blog對你有所幫助。

          我的系統是Windows Server 2003,IE6.0SP1,默認的IE設置會自動檢查服務器的證書是否有效,這就是罪魁禍首。解決方法如下:在IE中打開工具->選項->高級,勾掉"檢查服務器證書吊銷狀態(需要重新啟動)",重啟機器就好了。不知道這個是個bug還是MS自己的MSN服務器證書出現了過期現象?

          BTW,如果你用的是MSN Messenger 7.0的beta,你無法正常登錄時應該會看到這樣的錯誤代碼:80072f19


          posted @ 2005-01-12 22:40 laogao 閱讀(410) | 評論 (0)編輯 收藏

          僅列出標題
          共34頁: First 上一頁 26 27 28 29 30 31 32 33 34 
          主站蜘蛛池模板: 丹寨县| 富蕴县| 炎陵县| 临洮县| 攀枝花市| 秭归县| 马关县| 呼伦贝尔市| 南汇区| 井冈山市| 顺义区| 内丘县| 普兰店市| 广东省| 建阳市| 全椒县| 巴彦淖尔市| 永春县| 凤山县| 南靖县| 绥中县| 共和县| 方城县| 宁武县| 平塘县| 庐江县| 周至县| 南溪县| 建湖县| 巩留县| 陈巴尔虎旗| 三原县| 阿拉善右旗| 景宁| 金门县| 思茅市| 瑞丽市| 天峻县| 外汇| 达尔| 徐汇区|