零雨其蒙's Blog

做优秀的程序员
随笔 - 59, 文章 - 13, 评论 - 58, 引用 - 0
数据加载中……

2007年3月21日

游戏开发入门

     摘要: 游戏服务器:SmartFoxServer:smartfoxserver.com简单的游戏可以用apache minawebsocket provider:jetty客户端:可以转换成任何平台的开发工具:http://china.unity3d.comHTML5&JS游戏引擎/框架基于HTML5的游戏框架:http://www.cnblogs.com/sc-xx/archive/2011/0...  阅读全文

posted @ 2012-06-01 16:08 零雨其蒙 阅读(1059) | 评论 (5)编辑 收藏

Oracle Coherence初啼

     摘要:      昨天写了个Coherence的小例子,使用了Oracle Enterprise Pack for Eclipse,直接用它创建了一个ADF项目,连带创建了JPA项目,在Configuration里添加了Coherence,这样就有了配套的jar包了。      Coherence利用多播自动组成集群,类可以不实现序列化接口,这...  阅读全文

posted @ 2012-05-23 16:41 零雨其蒙 阅读(1914) | 评论 (0)编辑 收藏

JVM源码分析-Java运行

     摘要: 最近在看Java并发编程实践和Inside JVM两本书,发现如果不真正的了解底层运作,那么永远是雾里看花。因此从http://openjdk.java.net/groups/hotspot/上下载了源代码,准备研究一番。要想完全研究懂我觉得得对计算机体系结构,C,C++编程,Linux内核都有比较深入的理解。由于并非从事JVM开发工作,因此不会研究的那么深入。 入手就从“java ...  阅读全文

posted @ 2012-04-26 18:05 零雨其蒙 阅读(23627) | 评论 (2)编辑 收藏

京城七高校,贫嘴大联欢

     摘要:   阅读全文

posted @ 2009-06-09 11:33 零雨其蒙 阅读(453) | 评论 (0)编辑 收藏

gigix早年间与andyyehoo的论战

 

http://www.javaeye.com/topic/8007?page=1

andyyehoo:

比较一下下面的两段代码,说真的,虽然说Java效率低一点可以原谅,不过比较一下这两段代码的效率,真是..............虽然java效率比Cn个等级大家都接受了,可是不意味着就可以把系统效率丢到爪哇国去了啊

第一个是直接new一个对象,接着调用一个方法。

第二个是首先getApplicationContext,这个过程就首先不知道耗费多少了。然后是间接的getBean,创建一个对象。接着通过调用3个比reflaction更低效率的方法,设置各个参数,最后是调用。

纯粹的比较方法数,已经是第一个的3倍了,更不提每个方法的效率比第一个还慢多少。

当然,第二段的灵活性可能是高很多,但是这样的灵活性真的需要嘛?在大部分系统的大部分区域,我们需要大量的在EJB,JMS 或者 WEB SERVICE 里面切换嘛?


我们公司的答案不是,所以这个也是我们到现在还不普遍使用spring,而是部分使用spring的原因,也是spring的好处。系统小部分的灵活性需要非常高的部分,我们才利用springbeanfactory功能,事务控制要求严格部分,才使用它的事务管理功能。但是绝大部分,我们不使用。可以说是刚柔并济吧,不灵活的部分是刚,灵活部分是柔,系统如果全部是柔的话,那就软绵绵无力了,如果全部是刚的话,那么就太脆而易断,作为一个真正实用的系统,刚柔还是按80/20原则的好。


引用

UserManager userManager = new UserManager();

String userIDRetured = userManager.addUser("John Smith")

引用

ServiceRequest bsr = this.getApplicationContext().getBean("businessServiceRequest");

bsr.setServiceName("User Services");
bsr.setOperation("addUser");
bsr.addRequestInput("param1", "addUser");

String userIDRetured = (String) bsr.service();

gigix:

andyyehoo 写道:

比较一下下面的两段代码,说真的,虽然说Java效率低一点可以原谅,不过比较一下这两段代码的效率,真是..............虽然java效率比C低n个等级大家都接受了,可是不意味着就可以把系统效率丢到爪哇国去了啊

第一个是直接new一个对象,接着调用一个方法。

第二个是首先getApplicationContext,这个过程就首先不知道耗费多少了。然后是间接的getBean,创建一个对象。接着通过调用3个比reflaction更低效率的方法,设置各个参数,最后是调用。

纯粹的比较方法数,已经是第一个的3倍了,更不提每个方法的效率比第一个还慢多少。

当然,第二段的灵活性可能是高很多,但是这样的灵活性真的需要嘛?在大部分系统的大部分区域,我们需要大量的在EJB,JMS 或者 WEB SERVICE 里面切换嘛?


你讲这么大一通,我说你纯粹扯淡。只要addUser方法里面访问一次数据库,你所有那些性能考量全都是白费。哪怕你节约一万次对象创建和方法调用,连接数据库的网络开销就足以让你的整个努力化为乌有。你也知道80/20原则,按照80/20原则,J2EE应用根本就不应该考虑性能问题,除非涉及到RPCI/O操作。你在内存里优化得再好,如果由于架构上的原因多一次RPC调用,整个系统的性能立马就掉下来了。与其追求这种毫无价值的、微秒级的性能提升,我宁可追求全面的灵活性。

andyyehoo:

gigix 写道:

你讲这么大一通,我说你纯粹扯淡。只要addUser方法里面访问一次数据库,你所有那些性能考量全都是白费。哪怕你节约一万次对象创建和方法调用,连接数据库的网络开销就足以让你的整个努力化为乌有。你也知道80/20原则,按照80/20原则,J2EE应用根本就不应该考虑性能问题,除非涉及到RPCI/O操作。你在内存里优化得再好,如果由于架构上的原因多一次RPC调用,整个系统的性能立马就掉下来了。与其追求这种毫无价值的、微秒级的性能提升,我宁可追求全面的灵活性。

addUser调用数据库的时间,大家都是一样的,为什么我不能考虑这里调优?
这样写,并不会多出一次数据库或者RPC的调用。除非是很复杂的部分,那么我会考虑局部使用。对于系统80%的代码,简单化处理是不会带来任何问题的。


J2EE应用根本就不应该考虑性能问题?那我所有字符串连接都用+好不好?我做一步catch一次exception好不好?我所有Java方法的调用都通过reflection进行好不好?根本这个词用得太过了。

"我宁可追求全面的灵活性",这个正是问题所在,过分的追求灵活性,将降低效率,我们必须在灵活性和效率中间取得平衡点。xxx说了添加多一个中间层,可以解决大部分的问题。中间层越多,当然灵活性约好,但是效率是低了。其实当然,效率这个东西是两头大,中间小的一个东西,最耗费时间的,往往是一开始的调用(用户点击传到处理层)和最后的调用(调用数据库,WEB service),但是这并不意味着,我们就可以无节制的,忽略中间的效率。

gigix:

andyyehoo 写道

addUser调用数据库的时间,大家都是一样的,为什么我不能考虑这里调优?
这样写,并不会多出一次数据库或者RPC的调用。除非是很复杂的部分,那么我会考虑局部使用。对于系统80%的代码,简单化处理是不会带来任何问题的。

你是真不明白呢还是故意抬杠?一次数据库操作或者RPC的速度是十毫秒级的,通常一个J2EE业务操作包括几次网络传输和几次数据库操作,也就是说在最理想的情况下一个业务操作的速度是百毫秒级甚至秒级的。我请问你,你要节省多少次对象创建、多少次方法调用才能把响应时间提升100毫秒?有个成语可以贴切地形容这种优化:杯水车薪。

andyyehoo 写道

J2EE应用根本就不应该考虑性能问题?那我所有字符串连接都用+好不好?我做一步catch一次exception好不好?我所有Java方法的调用都通过reflection进行好不好?“根本”这个词用得太过了。

你还真说对了。我所有字符串连接都是用+;我的业务对象外面有动态代理提供的AOP,也就是说所有方法调用都是通过reflection进行的;我的动态代理里面对异常全部做了包装,也就是说每个方法调用都有try...catch...的包裹。我得到的效果是什么?更清晰的代码,更优雅的架构,以及,更容易找到系统的性能瓶颈,更容易优化性能。有些事情也许你没有听说过,但不代表它不是真的。

andyyehoo 写道

"我宁可追求全面的灵活性",这个正是问题所在,过分的追求灵活性,将降低效率,我们必须在灵活性和效率中间取得平衡点。xxx说了“添加多一个中间层,可以解决大部分的问题”。中间层越多,当然灵活性约好,但是效率是低了。其实当然,效率这个东西是两头大,中间小的一个东西,最耗费时间的,往往是一开始的调用(用户点击传到处理层)和最后的调用(调用数据库,WEB service),但是这并不意味着,我们就可以无节制的,忽略中间的效率。

同样一个问题,我换另一个角度来问你:你要做多少次字符串连接,才能浪费100毫秒时间?你可以自己写个程序,对比一下StringBuffer.appendString.+的性能差距,看看需要多大的字符串才能让你损失100毫秒。如果你能告诉我这个结果,我一定很有兴趣知道。别忘了,100毫秒仅仅是一次普通J2EE业务操作整体响应时间的数十分之一而已。

andyyehoo:

引用:

你还真说对了。我所有字符串连接都是用+;我的业务对象外面有动态代理提供的AOP,也就是说所有方法调用都是通过reflection进行的;我的动态代理里面对异常全部做了包装,也就是说每个方法调用都有try...catch...的包裹。我得到的效果是什么?更清晰的代码,更优雅的架构,以及,更容易找到系统的性能瓶颈,更容易优化性能。有些事情也许你没有听说过,但不代表它不是真的。


lol:
我相信你的系统是这样的,但是不代表所有的系统都需要象你这样。对于很多中小型系统来说,如此优雅的架构并不都是必须的。

而且,你这样对开发的效率有影响,代码量又多啦,呵呵,对开发人员总体素质的要求也高了不少,公司的成本又高囖。 这些都是需要考虑的。:evil:

当然,我承认后一种方法的先进性和灵活性,但是,还是那个问题,不需要拿牛的杀鸡,而现在的市场,鸡还是比牛多一些。

gigix这也是你的想当然。如果采用一个优雅的架构,普通程序员只需要编写面向对象的程序就足够了。他不需要考虑如何管理事务,他不需要考虑如何记录日志,他甚至不需要考虑如何获得和关闭数据库连接,而且他写的每个模块都可以从系统中摘出来单独测试。难道开发这样的程序会更慢、写更多的代码、对开发人员要求更高?相反,如果做太多代码级的优化,势必损害架构的优雅和灵活,会导致更多的重复代码,会使得各个模块耦合紧密而不能独立测试,那样的系统才是代码量更多、对开发者要求更高的。

我只举一个最简单的例子。你认为如果我们需要一个UserManager,那么就直接new UserManager()好了。但是这样一来,开发client代码的人就无法只测试他自己的业务逻辑,他的单元测试还必须同时兼顾UserManager的逻辑。我请问你,这是不是比写一个mock来测试自己这一个模块有更高的难度?一旦UserManager修改了实现,它的作者必须与所有使用者沟通,以保证这些人的单元测试不会失败,这是不是增加了工作量降低了开发效率?如果client代码能够这样写:

[code:1]
public class MyClass {
private UserManager _um;
public void setUserManager(UserManager um) {
_um = um;
}
public void doSomething() {
_um.doSomething();
}
}
[/code:1]

编写client的人不必考虑该创建UserManager的哪个实现类,也不必考虑如何创建,也不必关心这个对象的生命周期,也不用管它是本地对象还是RPC stub。难道这样写程序不是更轻松、代码量更少、对程序员的要求更低吗?

andyyehoo

gigix写道:

这也是你的想当然。如果采用一个优雅的架构,普通程序员只需要编写面向对象的程序就足够了。他不需要考虑如何管理事务,他不需要考虑如何记录日志,他甚至不需要考虑如何获得和关闭数据库连接,而且他写的每个模块都可以从系统中摘出来单独测试。难道开发这样的程序会更慢、写更多的代码、对开发人员要求更高?相反,如果做太多代码级的优化,势必损害架构的优雅和灵活,会导致更多的重复代码,会使得各个模块耦合紧密而不能独立测试,那样的系统才是代码量更多、对开发者要求更高的。

在正规公司里面,分工明确的话,都是专人写好架构,普通程序员按照架构往里面填代码就是的啦。正常情况下,他也是不需要如何管理事务,记录日志,获得和关闭连接,每个模块也可以单独测试。

但是,程序调试出错的时候,他们也需要自己查看日志,考虑一下各方各面的因素才能调试,按照第二种写法,无疑,这些程序员的素质要相对高一些,考虑的问题更多一些,才能进行调试的。

gigix写道:

我只举一个最简单的例子。你认为如果我们需要一个UserManager,那么就直接new UserManager()好了。


这个是例子这么写的,需要灵活的部分,我们自然会用其它方法写。不过在最简单的情况中,我们是会这么写,更简单的情况,直接还调用静态方法,不会不给吧,呵呵

gigix

andyyehoo 写道

这个是例子这么写的,需要灵活的部分,我们自然会用其它方法写。不过在最简单的情况中,我们是会这么写,更简单的情况,直接还调用静态方法,不会不给吧,呵呵 :lol:


别的不多说,就说这一件事好了。我要求所有程序员严格遵循“针对接口编程”的原则,每个组件必须提供一个接口和一个实现,获得组件必须以接口的形式、通过dependency injection获得。而按照你的说法,你要求程序员在提供功能时有时针对接口编程,有时针对对象编程,有时静态方法实现,也就是说你要求程序员清楚这三种设计的语义区别和利弊权衡。我想请问你,究竟是谁对程序员的要求更高呢?

andyyehoo

引用

别的不多说,就说这一件事好了。我要求所有程序员严格遵循针对接口编程的原则,每个组件必须提供一个接口和一个实现,获得组件必须以接口的形式、通过dependency injection获得。

佩服佩服,没有程序员抗议嘛?

引用

有时针对接口编程,有时针对对象编程,有时静态方法实现,也就是说你要求程序员清楚这三种设计的语义区别和利弊权衡。

我们现在是这样,不过,这个好像是JAVA程序员的基本功吧,虽然现在很多程序员基本功不好,那样的话,还是我们要求高点,按照你那样写的话,都快可以机器产生代码了,呵呵,可以考虑开始向自动产生代码发展了。

不过嘛,还是那个问题,出了bug,你们调试还是比较困难点吧?

gigix

andyyehoo 写道

引用

别的不多说,就说这一件事好了。我要求所有程序员严格遵循针对接口编程的原则,每个组件必须提供一个接口和一个实现,获得组件必须以接口的形式、通过dependency

injection获得。

佩服佩服,没有程序员抗议嘛?

引用

有时针对接口编程,有时针对对象编程,有时静态方法实现,也就是说你要求程序员清楚这三种设计的语义区别和利弊权衡。

我们现在是这样,不过,这个好像是JAVA程序员的基本功吧,虽然现在很多程序员基本功不好,那样的话,还是我们要求高点,按照你那样写的话,都快可以机器产生代码了,呵呵,可以考虑开始向自动产生代码发展了。

不过嘛,还是那个问题,出了bug,你们调试还是比较困难点吧?



对象怎么创建、对象的生命周期怎么管理,这些都是跟业务没关系的infrastructure。让程序员可以不操心这些infrastructure,一心关注自己的业务逻辑,怎么会有人抗议?

你说调试比较困难,我就真的很怀疑你究竟有多少经验了。任何一个有经验的J2EE开发者都会知道,OOD做得越好,debug越轻松。OOD做得好,你才可能做出完备的单元测试,然后用单元测试快速锁定debug的范围。我们调试比较困难吗?我真的不知道该怎么回答这个问题,因为我已经好久没开过debugger了。

andyyehoo

引用

你说调试比较困难,我就真的很怀疑你究竟有多少经验了。任何一个有经验的J2EE开发者都会知道,OOD做得越好,debug越轻松。OOD做得好,你才可能做出完备的单元测试,然后用单元测试快速锁定debug的范围。我们调试比较困难吗?我真的不知道该怎么回答这个问题,因为我已经好久没开过debugger了。



所指的bug,是指需要在spring的配置,aop搭建的事务控制,日志中穿梭寻找的bug,不过这个对于你来说应该是很熟了,所以没什么感觉了,一样快速锁定了。应该就是良好的架构使这定位个过程很快的。反正有固定步法的话,走7步和走5步差不多吧,呵呵。

gigix

andyyehoo 写道

引用

你说“调试比较困难”,我就真的很怀疑你究竟有多少经验了。任何一个有经验的J2EE开发者都会知道,OOD做得越好,debug越轻松。OOD做得好,你才可能做出完备的单元测试,然后用单元测试快速锁定debug的范围。我们调试比较困难吗?我真的不知道该怎么回答这个问题,因为我已经好久没开过debugger了。

所指的bug,是指需要在spring的配置,aop搭建的事务控制,日志中穿梭寻找的bug,不过这个对于你来说应该是很熟了,所以没什么感觉了,一样快速锁定了。应该就是良好的架构使这定位个过程很快的。反正有固定步法的话,走7步和走5步差不多吧,呵呵。



这些事情更不需要debug,因为它们都在冒烟测试的范围内。只要一开始测试通过,你做了一件事以后变得不通过了,马上就可以知道是你刚才的改动造成了破坏。这里没有5步、7步的调试,只有1步:回退你上一分钟做的修改。

说起来,好象你也开始赞成:OOD和良好的架构才是真正重要的,而不是20毫秒的性能提升。

andyyehoo:

引用

说起来,好象你也开始赞成:OOD和良好的架构才是真正重要的,而不是20毫秒的性能提升。

:lol: 我一直的观点是,OOD和良好的架构当然很重要的,但是要根据项目选择合适灵活的架构,而不必全部采用最灵活的系统,而在这个基础上,“20毫秒的性能提升”,也是需要考虑的事情之一,而不可以完全抛之脑后。

突然想到A计划2成龙说的,我不能接受任何人,以国家民族利益的崇高名义,草菅任何无辜市民的生命。(记不太清,大概)哈哈,有点象

posted @ 2008-08-04 15:47 零雨其蒙 阅读(619) | 评论 (1)编辑 收藏

统一软件开发过程学习笔记

统一软件开发过程

 

 UP的几个核心概念,也可以说是最佳实践:用例驱动(所有的分析设计测试都是围绕用例展开),迭代(因此我们会不断地编写用例,绘制用例图,进行分析,设计,实现,部署和测试活动),基于组件(我们看到最后软件是由组件构成的),以架构为中心(分层架构,完整的对象模型,核心领域模型)

核心工作流

模型

过程

UML

需求

用例模型

1 描述企业的业务流程,编写业务用例,然后以用例图来表示各个用例之间的关系(include/extend),及使用(use)该用例的参与者(Actor

用例图

2 使用活动图来表示业务流程

活动图

3 根据业务流程,明确系统功能,编写系统用例,使用用例图表示各个用例之间的关系,及使用该用例的参与者。

用例图

4 使用系统顺序图描述系统事件与系统操作

顺序图

分析

分析模型

描述用例实现的对象模型,它是工件:设计模型的一个抽象。 分析模型包含用例分析的结果、工件:分析类的实例。

 

用例实现-分析

5 对于用例中的一个或多个场景进行分析,然后抽象出一些分析类(包括边界类,控制类和实体类),分析类将被映射为设计类(分析类代表角色,一个分析类可以由1或多个设计类实现)。分析类也可以称之为业务模型,或者是领域模型。分析类通常可跨越多个用例,其表示领域中的概念。

类图

6 分析类与分析类之间的交互,由协作图来表示。这样称之为用例实现。

协作图

以上两者再辅之以文本,可以用来描述用例实现,每个用例对应于一个用例实现[1]

 

设计

设计模型

 

 

用例实现-设计

7 设计类代表系统中完成功能的类。它受到分析类的启发或者是为了解决一些软件问题而被设计出来。

类图

8 用例实现。根据分析模型中的用例实现,来完成设计模型中的用例实现。

顺序图

 可以使用包图来表示系统的分层架构。

 

10 某些设计对象是由状态决定的,也就是说根据其状态的不同,其会表现出不同的行为。状态图可以表示一个对象的状态转换关系及顺序,可以理解为对象状态流程图。

状态图

实现

实现模型

11 将系统抽象为组件,实现模型即由组件构成。这符合UP包含基于组件的思想。(Jacobson是组件开发之父)

组件图

实施

实施模型

12 实施模型根据相互连接的节点定义实际的系统架构。

实施图

 

 



[1] [Larman03]RoseRUP模板中都认为用例实现属于设计模型,然而本书认为分析模型和设计模型中都存在用例实现,在分析模型中,用例实现表现为领域对象与领域对象之间的交互,设计模型中,表现为设计类与设计类之间的交互。不过由于UP是用例驱动开发的,因此,基于用例的分析与设计,都可以理解为用例实现。

posted @ 2008-06-24 00:11 零雨其蒙 阅读(498) | 评论 (1)编辑 收藏

信管人的财会笔记(记帐)

     摘要:   账户与会计科目: 会计科目与账户是两个既有区别又有联系的概念。其共同点在于两者都按会计对象的内容设置,相同名称的会计科目与账户反映的经济内容相同。两者的区别在于,会计科目只是一个名称,只表明某类经济内容,而账户既有名称又有结构,可以记录和反映某类经济内容的增减变动及其结果。在实际工作中,会计人员往往不加区别地把会计科目与账户作为同义语。 账户结构如下: 账户名称(会计科目) ...  阅读全文

posted @ 2008-06-06 14:28 零雨其蒙 阅读(865) | 评论 (0)编辑 收藏

项目组内部推荐书目

     摘要: 本文介绍理解本项目所有架构、设计思想和具体技术、工具使用的著作,阅读以下著作,可以更好的理解我们的项目为何如此架构,为什么要使用这些工具,以及过去在项目中出现的文档中所简单描述的内容的背后原理是什么。

  阅读全文

posted @ 2008-02-14 15:27 零雨其蒙 阅读(711) | 评论 (0)编辑 收藏

企业应用架构模式学习笔记(2)

     摘要: 这一部分完成了对于该书第一部分的学习,并且学习了领域层模式,特别是领域模型模式,并对于数据层的活动记录进行了研究  阅读全文

posted @ 2008-02-01 23:47 零雨其蒙 阅读(566) | 评论 (0)编辑 收藏

企业应用架构模式学习笔记(1)

     摘要: Martin Fowler的《企业应用架构模式》,很经典,这一部分的笔记主要对应于书中第一章和第二章的部分内容,对于领域逻辑层进行了部分人讨论,对领域模型与事务脚本模式做了简要分析。还包括对于对象到数据库映射的简单讨论,与现实使用的DAO模式和Hiberante进行了概念映射  阅读全文

posted @ 2008-01-27 23:54 零雨其蒙 阅读(353) | 评论 (0)编辑 收藏

如何判断对方是否喜欢自己的信息经济学解释

     摘要: 本文旨在利用信息经济学的知识解决我们在恋爱之前的阶段中需要决策问题:如何判断对方是否喜欢自己?
  阅读全文

posted @ 2007-12-11 00:17 零雨其蒙 阅读(2351) | 评论 (2)编辑 收藏

8月6日到9月15日项目小结(一)

     摘要: 8月6日到9月15日项目小结,第一部分主要回顾了在过去的一个多月里我们都做了什么~  阅读全文

posted @ 2007-09-18 01:24 零雨其蒙 阅读(704) | 评论 (3)编辑 收藏

项目随想录

        发现自己不怎么会起题目了。中午回去还没走到寝室,就接到刘老师的电话,说要把程序调通,于是中午吃完饭立马跑回去,把显示问题解决了。其实那个无效数字问题是因为在HQL语句中使用了cast(pw as integer),将字符串转成Integer型,可是数据库中的内容编程了字母加数字,自然会转换失败了,唉,真不理解随便改什么业务主键啊。

   下午上企业资源规划,我的名字成了所有老师举的例子的主角,三个小时,我的名字被提及至少50次,每隔2分钟就要提一次,后来我都听麻木了,不知道自己叫什么了。

   老师主要讲了4方面的内容:1、信息管理专业的知识架构(技术基础层,技术应用层(ms是这个吧),管理应用层)、应用与研究的关系,2、信息技术缘何发展3、流行的信息系统概念(ERP,MIS,EC,EAI,BPR,SCM)4、还有啥来着?记不住了,老师还让总结笔记呢,唉,明天问别人吧。

    晚上和球去跑步了,本来感觉自己挺疲乏的,可是跑步过程感觉疲乏一点点消退,跑完后感觉有点晕,看来还是感冒有点虚,再加之没睡好觉,运动量有点大,于是买了盒奶,和果汁,坐着和球聊了好久,又去吃了串,回来洗了澡,别提有多爽了,感觉人也有精神了,我觉得锻炼什么太重要了,运动就应该像吃饭睡觉一样不可或缺,一样重要,减肥其次,增强体魄才是最重要的。

 

    我需要花费一定时间好好总结一下从8月13号到9月15号,这一个月时间项目总结,仔细分析一下经验和教训,我们得到了什么,验证了什么,出了什么问题,症结究竟是什么,要分得很清楚很细致,这样才行。我是觉得收获很大,不过想想以后的项目开发感觉有些绝望,使用现在的开发方式实在是太痛苦了,我今天想了想我们的系统经常做的用户交互就是在一个ComboBox中选择了某个选项,其他若干个Text或ComboBox框中的内容要随之变化,使用我们现在的方法,实现这个东西要动用好多代码,而且其方式就好比在Delphi中随意拖拽Query一样有害。并且遭遇到复杂的页面流程又该怎么办,如何测试,莫非只能使用alert?看来我们的系统好像并不适合B/S模式,其实从垂直切片的角度来说,我们的验证工作做得很成功,可是从老板的角度来考虑,或许我们就是失败的了,因为我们没有做出一个足够丰富的原型。

    要学的东西很多,明天去复习运筹,晚上写总结报告,周一老板他们估计就回来了吧

posted @ 2007-09-16 00:12 零雨其蒙 阅读(191) | 评论 (0)编辑 收藏

又看到希望了

    昨天还在困扰Hibernate的复杂,今天看了一上午Spring,把HibernateTemplate,HibernateDaoSupport两个类的源代码看了一下,发现Spring绝对是大大简化我们的开发,降低我们学习Hibernate的门槛。Hibernate中的许多写法,Spring把它们统一和简化了。下午跟老邢分了分工,我负责看关联和映射,他负责看CRUD,再加上Spring的简化,我想起码我们现在上路还不算太危险。

    表现层在用Ext,一个新的Ajax库,资源非常之少,和DWR没法比;不过它的丰富程度远远超越了Ajax JSP Tags。刚才刚和老大一起完成一个实验,我们终于可以取到某一行记录的内容了!花费了一个多小时的时间。 

    如今Struts似乎只是用一个Action了,标签和Form Bean没必要用了,Ext代替了,其实觉得还不如用Spring MVC好了。多引进一个框架,无端增加了复杂性,又需要多学一种技术。不过Struts的Validate还是需要进一步研究的,不过它的优先级可以推后一些。

 

     似乎又看到一些希望了,使用Ext我们实现了取一条记录的内容,那么接下来对这条记录进行修改和删除就没问题了。接下来,在页面上利用div弹出一个添加/修改的页面还需要研究,之后就是“冒泡”。

    某些工作还比较无序,比如使用MyEclipse生成的POJO,DAO和部署文件总是需要重构,移动位置,修改名字等,不过这个也可以放在稍后研究。

 

     明天开会希望能给老师们演示一些基本功能,毕竟我们也做了有近20天了,按照XP来说,2周算是一个迭代过程,那么也该展示一些东西了。

     明晚SHE演唱会,希望下午的会不要开太久,那个地方真的是好远啊~

 

posted @ 2007-08-31 18:42 零雨其蒙 阅读(174) | 评论 (0)编辑 收藏

J2EE持久化策略考察——为项目做技术选型准备的一点资料

     摘要: 为了项目技术选型,最近一直在对比各种技术,这一部分是对于使用O/R映射原因的考察,EJB和Hibernate的抉择,因为自己没在项目中用过EJB(就是那时候去软件学院蹭过课),因此基本上都是听Rod Johnson的话,不过觉得他的言论非常有道理  阅读全文

posted @ 2007-08-25 20:33 零雨其蒙 阅读(317) | 评论 (0)编辑 收藏

终于……

 刚开完会,不知道心情是怎样的,是压力抑或动力,其实大多数时候开完会的感觉就是不想干活……

    终于暂时把做“垂直切片”的工具和环境定下来了,早上来的时候还在查JBoss,因为刘老师又提要全面的开源策略。其实问题就在于他们总是认为SSH与特定服务器之间存在某种特殊的渊源,一定要加以组合方显专业,不过,甭管是EJB还是Hibernate,Weblogic还是JBoss,AIX还是Windows对于我们来说都差不多,关键是先定下来一个让我们把这个Demo做出来就好。

    老板说要一周搞定,我觉得简直是天方夜谭,而且还把我的搭档派去广州了,以后我就要孤独的开发了~

 

    不知道心里什么感觉,不过,终于可以知道确定要学什么了,老板还说Demo做完后再评估,可能会换技术框架,也好,研究生毕业时,收获也将满满的了~

posted @ 2007-08-25 17:46 零雨其蒙 阅读(154) | 评论 (0)编辑 收藏

唉,程序员要是自学能力不行就等死吧!

     摘要: 唉,程序员要是自学能力不行就等死吧!最近的生活就是这样的,每天都在学习新技术~项目需要  阅读全文

posted @ 2007-08-24 19:07 零雨其蒙 阅读(563) | 评论 (0)编辑 收藏

Struts2.0,超屌

   今天看了一篇叫《myeclipse和struts2+spring+hibernate混合编程》的文章,作者应该是CSDN上某位大虾,不过it168没有道德,转载也不留链接。

   目前项目是用Struts1.2+Spring2.0+Hibernate3.0,原来还觉得Struts1.2刚用上怎么又升级成2.0了,而且还是和WebWork2.3整合的,不知道学习曲线如何,可是今天看了这个例子,觉得无论是Action类,配置文件,还是标签都相当简洁,十分富有表现力,直接看代码就明白是怎么回事了~

   用MyEclipse自动生成Hibernate的POJO总是生出很恶的代码,不知道哪里出了问题,明天继续钻研吧~

  

posted @ 2007-08-21 00:30 零雨其蒙 阅读(295) | 评论 (0)编辑 收藏

不能说的秘密 终极解密

     摘要: 周杰伦最新自编自导自演自唱的电影《不能说的秘密》,完全解密,强力推荐~~  阅读全文

posted @ 2007-08-09 17:35 零雨其蒙 阅读(2112) | 评论 (8)编辑 收藏

瀑布模型与结构化方法

     摘要: 瀑布模型之父在那篇号称孕育了瀑布方法的文章里竟然支持的是迭代方法,而瀑布方法实际上是文中的反例!而结构化方法之父又创立面向对象方法。今天发现了这些,万分惊奇!  阅读全文

posted @ 2007-06-06 20:06 零雨其蒙 阅读(1622) | 评论 (0)编辑 收藏

DOS命令

     摘要: 偶尔在网上看到的DOS命令的总结,比以前看的都要多,留作参考  阅读全文

posted @ 2007-05-19 08:49 零雨其蒙 阅读(1114) | 评论 (0)编辑 收藏

开发者应该到现场去

     摘要: 由于今天跑去地磅,解决了一个莫名其妙的问题,让我深深地感觉到开发人员到现场去的重要意义:看看用户在做什么,怎么使用我们编写的软件,听听他们的想法,也是敏捷方法论所提倡的基本原则。  阅读全文

posted @ 2007-05-16 23:06 零雨其蒙 阅读(248) | 评论 (0)编辑 收藏

[转]SOA的国际标准进展:SCA/SDO已完成关键部分

     摘要: SOA的最新趋势,了解一下,在我看来,SOA的发展就是新一轮技术的生命周期,会跟分布式、J2EE一样,不信你走着瞧  阅读全文

posted @ 2007-05-03 22:40 零雨其蒙 阅读(126) | 评论 (0)编辑 收藏

我一定要进IBM!

     摘要: 我一定要进IBM!  阅读全文

posted @ 2007-04-09 12:55 零雨其蒙 阅读(439) | 评论 (1)编辑 收藏

Fowler's New Methodology读后感

     摘要: Fowler的这篇论文从宏观上讲述了新方法论,包括其动机,发展历史,和其实质,高屋建瓴,让人受益匪浅  阅读全文

posted @ 2007-04-09 11:05 零雨其蒙 阅读(299) | 评论 (0)编辑 收藏

关于IE7无法设置首页的问题

装完IE7后,打开一个IE,就会连向微软的网站,将首页设成空白页也不行,后来在网上搜到了下面这个答案,一改就OK了.


第一次用IE7时~会连接到一个微软的网站~~~其实是在线设置你的IE7~~~设置好了才能自定义首页~~~
否则无论怎么调都没用~~~
或者~~你已经设置好了


然而比较郁闷的是,IE7打开后总是好像需要连接什么东西,不能马上输入网址,也或许是因为我的机器慢?

posted @ 2007-03-26 11:40 零雨其蒙 阅读(4528) | 评论 (4)编辑 收藏

零雨其蒙关于吴莹莹事件的深度思考

     摘要: 本文主要讨论了吴莹莹事件引发的思考,主要选择了四个关键词:看不得人好,炒作,造假和草根。对于民众话语权与民主言论的进步进行了阐发,个人觉得,经过两年的Web 2.0的发展,和中国经济的发展,人民的素质的提高,我们看到了更多理性的声音,更多基于事实的讨论,本文主要就是用来发现这些进步的。   阅读全文

posted @ 2007-03-25 22:35 零雨其蒙 阅读(331) | 评论 (1)编辑 收藏

零雨其蒙《对象设计:角色、责任和协作》学习笔记(六)

     摘要: 第四章 责任(下)  阅读全文

posted @ 2007-03-25 22:21 零雨其蒙 阅读(370) | 评论 (1)编辑 收藏

零雨其蒙《对象设计:角色、责任和协作》学习笔记(五)

     摘要: 第四章 责任(中)  阅读全文

posted @ 2007-03-24 22:15 零雨其蒙 阅读(193) | 评论 (0)编辑 收藏

零雨其蒙《对象设计:角色、责任和协作》学习笔记(四)

     摘要: 第四章 责任  阅读全文

posted @ 2007-03-23 14:10 零雨其蒙 阅读(357) | 评论 (0)编辑 收藏

网上测试结果

     摘要: 在网上做测试,Baihe网的结果是我是专家型,中华英才网觉得我是企业型,觉得还满有意思的,虽然不见得很准,不过很多方面说的我觉得还是很有道理的~  阅读全文

posted @ 2007-03-23 13:52 零雨其蒙 阅读(202) | 评论 (0)编辑 收藏

零雨其蒙《对象设计:角色、责任和协作》学习笔记(三)

     摘要: 第三章 发现对象  阅读全文

posted @ 2007-03-21 17:06 零雨其蒙 阅读(399) | 评论 (0)编辑 收藏