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 阅读(583) | 评论 (3)编辑 收藏

     摘要: 春节长假即将结束,想想已经有好久没更新自己的blog了,正在等Arsenal和Crystal Palace的比赛转播,也睡不着,就写写最近的一些感想吧。这些天除了走亲访友、合家团聚、请客吃饭之外,也看了一些电影,玩了一些游戏。印象最深的是那一部一年前在美国上映的......  阅读全文

posted @ 2005-02-15 02:09 laogao 阅读(444) | 评论 (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 阅读(301) | 评论 (0)编辑 收藏

 

大半年的时间都在忙这个项目,虽然现在离UAT还有一段时间,但是还是觉得应该给自己一点小小的奖励了,于是和LP一起去选购了一套迷你音响。见下图:

ONKYO1.jpg

怎么样,还不错吧?

买了之后才有闲暇去想这件事背后的东西:原来适当的消费对于长期高度紧张的IT类工作相当有好处,有助于改善工作状态和调整心情。毕竟谁都受不了成天对着电脑,担着沉重的压力,而没有合适的途径去宣泄的。

希望大家不要跟我前段时间一样,把工作当成了全部,忽略了生命中其他美好和重要的东西。

 

posted @ 2005-01-24 13:02 laogao 阅读(463) | 评论 (1)编辑 收藏

 

<回复格式>

First Name:

Last Name:

E-mail:

请完整填写以便顺利接收邀请。

posted @ 2005-01-21 09:15 laogao 阅读(1990) | 评论 (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 阅读(837) | 评论 (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 阅读(809) | 评论 (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 阅读(705) | 评论 (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 阅读(504) | 评论 (0)编辑 收藏

     摘要:   [版权声明]作者保留本文的版权。如需转载,请保持文章完整,注明出处,并保留此声明;如需用于商业目的,须作者本人书面许可。作者的联系E-mail: gaoyuxiang@gmail.com     [准备工作]   首先,为了了解J2SE(TM) 5.0的新的语言特性,你需要下载新版的JDK,在这里可以找到下载链接:http://java....  阅读全文

posted @ 2005-01-12 22:49 laogao 阅读(5718) | 评论 (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 阅读(397) | 评论 (0)编辑 收藏

仅列出标题
共34页: First 上一页 26 27 28 29 30 31 32 33 34