Open Source Thoughts

EJB or Without EJB

2008-04-06T00:57:00.003+08:00

EJB的使用

我既做过使用EJB 进行开发的项目，也采用过轻量级方式开发的项目，在没有经验的时候使用EJB是应为EJB看上去能给一个项目提供更宽阔的扩展空间和可靠保障。有经验的时候就会根据实际项目的规模，时间，人员等众多因素和需要来选择是否使用EJB，什么类型的EJB。首先需要明晰的一个概念就是 EJB != J2EE. EJB之只是J2EE中的一个部分而已。 J2EE包含很多的技术，JSP, Servlet, JMS, JDBC, JAAS, JMX, 和EJBs. J2EE同时也包括了如何一起使用这些技术来构建解决方案的指导和模式(如J2EE Core Design Pattern). 所以使用J2EE本身对开发人员是由一定的技术要求的。

如果你在不需要EJB的地方使用它，它往往会对你的应用的性能带来一定的损耗。由于本身的额外损耗，它会与你的应用进行资源的竞争，包括CPU, 内存等等。

Plain Old Java Objects, 或者说叫 POJOs, 在Web应用中对于EJB是一个不错的轻量级替代方案，但是，如果你的应用项目对集群，高可靠性，等企业级运算的要求比较高，应用服务器可以是一个不错的选择，在一般的Web应用中，如果内容发布，管理等等，一个轻量级的Web服务器或许就可以满足需求。所以最后的选择还是以需求为重，不要为了使用技术而使用技术。

数据访问

大多数的Web应用除了前端的页面控制外，主要的问题的焦点就集中在了数据访问，应用本身的重点也就是在数据，如果对数据进行了比较好的管理，前端的展现如何千变万化也无妨。

在一个相对复杂的应用系统中，数据的关系往往是复杂的，可能其中有60%是简单的CRUD操作，可能有40%是复杂的关联操作，从设计之初，可能就需要来考虑是从对象到关系的设计，还是从关系到对象的设计。从我个人的观点来看，两者是需要同时考虑的，比如说有些应用的部分只要求高效率的数据存储和传递，这个时候我们可能就需要对数据库表结构进行很多特殊的设计，甚至利用到数据库特有的特性来提高性能，这种情况下我们就要以关系为主，虽然最终是用过Java对象去操作数据，但本身的重点还是在数据。

I. 小型的应用

Controller --> Business Services Layer (POJOs) --> Data Access Layer

II . 大型的应用

Controller --> Session Facade --> Business Services Layer (POJOs) --> Data Access Layer

如果你在前期应用的规模还不大的时候开用I的方式进行业务逻辑以及数据的封装，把Business Service作为一个单独的层次封装起来，当你的业务规模增长，需要使用到应用服务器的时候，你只需要在前面加一层EJB(Session Facade)，转化成模型II, 就可以很容易的把旧的应用迁移到新的体系下，而不至于要重新修改原有的业务层，或者整个重写。

在Data Access Layer 你可以使用O/R 工具来提供对数据的透明访问能力，同时对于复杂的关系处理直接采用JDBC操作的方式，都是可以的。

下面的方式或许是一个都能够满足要求的方案

740)this.width=740" border="undefined">

参考: JPetstore 4.0 提供了一个不错的Business Service Layer的设计方案

What's going on with requirement?

2008-04-06T00:57:00.001+08:00

funny requirement picture from my friend

740)this.width=740" border="undefined">

Service-Oriented Programming on MicroKernel

2008-04-06T00:56:00.003+08:00

Linux内核是一个单块软件，内核的所有部件都包含在系统上运行已大块特殊的程序上。有关内核状态的任何信息都可以立即共所有内核部件使用。如下图所示:

740)this.width=740" border="undefined">
现代操作系统中的一类内核结构是微内核。这种微类核把大多数关键的控制功能分开。
状态信息不再可供左右功能立即使用，而是作为一个功能传递到另一个功能。

如下图所示

740)this.width=740" border="undefined">

Richard Stallmas使用这种基于微内核的架构开发了GNU系统的内核GNU Hurd，Linus 说这种微内核结构增加了控制模块间消息传递的复杂性使人们更难找出内核中的软件缺陷。Richard承认开发和诊断GNU Hurd内核的复杂性大大延缓了该内核的开发。

如果我们把这种微内核思想应用到应用软件开发中来，让微内核扮演一个中介者的角色，各个组件（模块)之间通过微内核聚集在一起，在整个系统中，模块将是可扩展的，能够在任何时刻融合到系统中，而不影响系统本身的体系结构。

如果把这些组件看做是一种服务，服务间的耦合通过微内核来建立，系统就变换成一种面向服务的结构，这种面向服务是面向代码级的，并不是平时提到的更高层次的SOA, 系统内部服务调用就形成了如下的方式:

740)this.width=740" border="undefined">

代码示例:

740)this.width=740" border="undefined">

JFox on TSS

2008-04-06T00:56:00.001+08:00

JFox Application Server 2.0 M1 Released

JFox Application Server 2.0 M1 has just been released.

New features:

IoC-based microkernel and pluggable architecture
Integrate Jetty 4.2.22
Integrate Mr.Persister as DAO solution
JavaMail service support
EJB 2.1 timer service support
Build-in JPetstore as demo program

Download JFox http://sourceforge.net/projects/jfox/
Online JPetstore Demo http://www.jfox.cn/jpetstore

消息刚被发布到TSS不久，就得到很很多的反馈意见，有不屑，有鼓励，有人提到我们是在重新造轮子，为什么不加入现在已有的应用服务器团队。

现在做的比较成功的开源J2EE服务器好像也并不是很多，美国的JBoss, Apache的Geronimo, ObjectWeb的Jonas(实际上是Bull的Jonas)

JBoss现在已经是商业化的产品，基本上很难参与他们的开发，

Geronimo现在正在开发中

Jonas在欧洲实际上是由Bull公司30多人的一个专业研发团队在对Jonas在进行开发

从我个人的观点来看，像应用服务器这样的大型系统，在国外都是由专职人员全职来进行开发的，这样才能保证快速的发布和高质量的版本，虽然开源提倡的是分布式，多人协作，但是从实际情况来看，好的开源项目的核心团队一般都是由人专职进行，比如PostGreSQL有一个 6人的专职核心团队等等。

在中国可能大家都在为了生计而拼搏，其实对于很多已经相对稳定的朋友，如果每天只需抽出1小时来参与开源，不过也可能就是喝一杯咖啡的时间，或许在这一小时里有比较工作一天获得更多的收获。

总之，作为JFox Team的每一个成员，我们都希望参与这个竞争，因为有竞争才有交流，才会发现出更多好的，不同的东西，J2EE的规范也正在不断改进发展中，如果都是商业化的软件，他们大多可能会为了自己的利益而破坏技术本身的高速发展，只有不断地参与，才有更多的机会！

中国人能在奥运会上获得110米栏的冠军，JFox也会同样站在与世界众多J2EE应用服务器的相同起跑线上，与他们展开竞争！

Everything is possible!

Meet Open Source Guys

2008-04-06T00:55:00.001+08:00

9.10号，虽然上海突然下起了大雨，很多的朋友因为大雨而没有赶来，但是我还是在上海福州路的一家Coffee Bean的咖啡屋与10多位open source的爱好者见面，他们有:

SAP(Michael, Darth..) ，MySQL( Dr. Lars Thalmann CTO), ObjectWeb ( David Li)

HP(Jiao Jian), PagonSoft(Paul Qu), ShangHai FangBang Tech (Wang Qian) ， Huihoo(Steven Cheng), 来自FreeBSD的台湾朋友，等等，大家一起就开源在中国的发展，以及每个人对开源的看法，发展模式进行了交流。

让我们最高兴的是，MySQL 的Lars博士向我们介绍了MySQL的成功经验，并表示他们非常关注中国市场，也正在学习和了解中国，MySQL也非常希望在中国有更多的合作伙伴。

这里向ObjectWeb的David Li组织了这次有意义的活动表示感谢！

活动的精彩照片, :)

740)this.width=740" border="undefined">

Migrate JPetstore To JFox

2008-04-06T00:54:00.002+08:00

1.介绍

1.1 JFox

JFox 应用服务器是一个开放源码的J2EE规范的实现，JFox应用服务器具备以下功能特性:

l Web 服务器，支持Servlet 2.3, JSP 1.2

l 基于JMX的管理

l 支持EJB 2.0

l 支持JTA 1.0.1

l 支持JNDI 1.2

l 支持Java Mail 1.3.1

l 支持JDBC 3.0

l 支持JavaRMI 1.0

JFox是由开放源码社区www.huihoo.org 的开发人员协同研发完成，现在是中国NO.1 的开放源码Java应用服务器，它已经被全世界的开发人员下载了2058个拷贝，并逐步被广泛的使用。

JFox 可以运行在不同的操作系统上，如Linux, Solaris, Windows, etc.同时JFox也支持多种数据库,包括：Oracle, DB2, SQL Server, 以及MySQL。

更多关于JFox的信息，可以访问：http://www.huihoo.org/jfox

1.2 JPetStore

JPetStore是一个基于iBATIS开源持久层组件的Web应用， iBATIS包括SQL Maps 2.0 和 Data Access Objects 2.0 frameworks. JPetStore是展现如何使用这些框架实现一个典型的J2EE Web应用的优秀范例. 更多关于JPetStore的信息，可以访问: http://www.ibatis.com/jpetstore/jpetstore.html

2.运行环境

2.1软件环境

名称	版本号
JDK	1.4.2_01 or Higher
Application Server : JFox	1.2 or Higher
Database: MySQL	4.0 or higher
Operation System: Windows	2000 Server, XP

3.系统安装

3.1 Java安装

1) 从http://java.sun.com/j2se/1.4.2/download.html 安装JDK 1.4.2或更高版本, 在我的电脑à 高级à 环境变量中设置%JAVA_HOME%；

3.2 JFox 安装

1) 从http://sourceforge.net/projects/JFox下载JFox 最新版本，解压缩到指定目录

2) 在JFox安装目录的bin目录下，运行startup.bat启动JFox

3) 连接http://localhost:8080，可以访问JFox的Web界面，在这里可以执行JFox提供的例子

4) 连接 http://localhost:8082/，可以看到正在运行的系统组件，并可以进行管理

3.3 安装MySQL

1) 从http://dev.mysql.com/downloads/下载MySQL 4.0,解压缩并运行安装程序

2) 从http://dev.mysql.com/downloads/other/mysqlcc.html下载MySQL Control Center ，解压缩并运行安装程序

3) 启动MySQL, 并运行MySQL Control Center

4.JPetStore应用部署

4.1 JPetStore部署

1) 从http://sourceforge.net/projects/ibatisjpetstore/ 下载JPetStore 4.0, 解压缩到指定目录, JPetStore目录结构如下

JPetStore

/build

/ddl

/devlib

/doc

/lib

/src

/web

2) 从http://dev.mysql.com/downloads/connector/j/3.0.html 下载MySQL JDBC Driver mysql-connector-java-3.0.15-ga.zip ，解压缩并将mysql-connector-java-3.0.15-ga-bin.jar拷贝到上述JPetStore的lib目录下

3) 修改上述JPetStore的src/properties/database.properties文件

driver=com.mysql.jdbc.Driver

url=jdbc:mysql://localhost:3306/jpetstore

username=jpetstore

password=jpetstore

4）重新构建JPetStore, 在build目录下运行build.bat, 将会在build/wars/生成jpetstore.war

5) 安装数据库脚本，在ddl\mysql目录下可以找到

jpetstore-mysql-schema.sql

jpetstore-mysql-dataload.sql

jpetstore-mysql-create-user.sql

在MySQL Control Center SQL窗口中依次执行

5) 在MySQL CC中创建用户jpetstore,并设置密码为jpetstore ，并赋予jpetstore用户所有访问jpetstore schema的权限。

6) 将jpetstore.war拷贝到JFox安装目录的deploy目录下

4.2运行JPetStore

启动JFox, 在浏览器中地址栏中键入http://localhost:8080/jpetstore

您就可以看到如下的页面

740)this.width=740" border="undefined">

　运行在JFox 上的JPetStore在线演示可以从http://www.jfox.cn/jpetstore 访问到

期待有更多的成功应用被移植到JFox上，如果你有成功的案例，请分享给我们

请发送电子邮件到: jfox-developers@lists.sourceforge.net

5.参考

1. http://www.huihoo.org/jfox

2. http://prdownloads.sourceforge.net/ibatisjpetstore/JPetStore-1-2-0.pdf?download

3. http://www.ibatis.com/jpetstore/DevDays.pdf

OpenSource & OpenSource Software

2008-04-06T00:54:00.001+08:00

"OpenSource"已经不断的被更多的人认识，接受，很多人就会自然的产生这样一个概念
" OpenSource = OpenSource Software".

在几个星期前与ObjectWeb的Christophe Ney(Executive Director)的交流中,我留意到这样一句话"OpenSource is a process, OpenSource is not a product".

Eric Raymond在他的<<大教堂和市集>>中将这种开源的开发模式称之为"集市开发模式", 就是在
这种集市式的开发模式下,造就了今天著名的Linux操作系统. Linus Torvalds 使用这种开发风格
(尽早尽多的发布，委托所有可以委托的事，对所有的改动和融合开放),把Linux投入到社区中,
在各种不同的建议,方法,和问题的充实喜爱,一个一致而稳定的系统就奇迹般的从这个集市中产生.

1. 教堂式的开发和集市式的开发有些什么不同呢?

教堂开发: 在开发开始前,非常好的理解设计和功能. 架构,设计,开发,集成和测试的完成计划都非常明确和编入文档.在开发阶段中发布循环是很少的. 仅在Alpha和Beta测试循环中才能够看到外部的反馈.

集市开发: 维护者发布具有某些用途的功能,但是软件包公功能并不齐全, 有时也能发现缺陷. 频繁的进行版本的发布(有时候以天计算). 问题的反馈能够尽早的被公布出来并被很容易被大家看到.任何人都要有好的思想都可以贡献出来, 或增有意义的新功能.维护者在确定一切就绪时就宣布发布一个新的版本.

集市开发模式的优点:

. 快速的开发: 开放源码的开发人员是富有激情的,他们通过积极的合作,能够以快速,不断的推出新的版本

. 分布式的开发: 开源社区的开发人员都位于全球的各个不同地方,他们最大限度的利用Internet, 来进行沟通协作, 分布式的开发同时也充分利用了时区的优势, 每天24小时有会有人在开发,每天24小时都可以得到来自全世界各地开发人员的支持.

. 最佳的人才: 开放源代码社区是不能容忍劣质的贡献者的. 如果你想加入某一个开源项目开发,你必须持续的作出某种贡献,如文档, 设计,结构,测试等等, 如果你不能做到这些, 社区也不会吸纳你. 人才是现在公司竞争的焦点, 开源社区里激烈的竞争和开放的人才管理使社区总能拥有最佳的人才.

. 发展蓝图: 开放源码软件没有商业化软件上市的时间压力,也没有强制性的蓝图. "经过彻底的测试,准备好后才发布" 这种质量第一的思想,使得开放源码软件的质量远比商品化软件好, 内部隐藏的错误也比较少.

. 有效的人员管理模式: 开放源码社区并不像看上去的那么松散, 好的社区都会有专职的一个管理,协调团队来负责整个社区的发展,规划和协调. 比如ObjectWeb , 首先由一个理事会,在理事会下有一个5人执行团队,专职来负责ObjectWeb所有事务的协调.

上面谈到的这些用一句话简单来说就是: Open Source 是一个过程, Open Source是一种文化, OpenSource是一种人与人之间自由沟通,协作的方式.

2. 什么是开放源码软件(Open Source Software)?

开放源代码软件是一种公开源代码的软件，任何人都可以修改、使用、拷贝、分发软件的源代码。

开放源代码软件有如下特点：

1. 开放源代码软件一般是免费发布的，您可以在Internet上自由下载，用户无需缴纳License费用。

2. 开放源代码软件由一个核心组织领导, 通常由一个很大的社团在Internet上协作开发完成。这种“集市”式的开发模式使得其通常有着比封闭源代码软件更高的质量。

3. 用户可以得到软件的源代码，更容易根据自己的特殊要求，进行定制。

4. 开放源代码软件的生命周期不依附于某个公司，因此有更强的生命力。

740)this.width=740" border="undefined">

开放源代码软件，已经形成了一条完整的商业价值链，有了更加坚实的基础：

1. 开放源代码软件发起公司：启动开放源代码软件项目，他们为项目提供最初的资助，通常提供最基础的代码和开发人员。发起公司，可凭借其领导地位的企业形象，更容易得到优质的客户，进而省去市场、销售等的巨大投入。同时他们可以为其他的软件服务公司技术服务。

2. 开放源代码软件非营利核心开发团队：负责组织协调开放源代码软件的开发，建设软件社团。他们通常由资深的软件专家组成。他们接受发起公司、捐赠人的资助。

3. 开放源代码软件社团：由开放源代码软件的开发人员、用户、志愿者在Internet上共同交流形成的社团。

4. 开放源代码软件服务公司：利用开放源代码软件，为最终用户提供服务。同时他们为软件进行测试，代表用户提出软件改进意见或者特性请求。他们是开放源代码软件和最终用户之间的桥梁。任何公司都可以利用开放源代码软件提供服务。

5. 开放源代码软件最终用户：最终用户得到丰厚的回报。他们无需支付昂贵的license费用；他们选择服务有更大的自由度, 而不必和某个软件供应商锁死；同时他们可以提出软件改进的新特性。
6. 志愿者：志愿者可从自由软件中学习到众多技能，同时他们参与软件的测试、捐献自己的代码。广大的志愿者是开放源代码软件长久发展的重要基石。

6. 政府: 政府在整个生态系统中将起到指导性的作用，他将给开源码软件的使用提供有力的政策上的支持。

相信这种新的基于开放源码软件的商业模式将给我们带来很多的发展机会, 特别是对中小型的软件公司, 只有利用这种新的商业模式,打破已有的游戏规则, 才有可能获得发展.

参考:

1. Eric Raymond <<大教堂和市集>>

2. HP Linux文集

My Top 10 Reading Books

2008-04-06T00:53:00.002+08:00

I am a voracious book collector and reader as well,

I am currently reading Top10 include:

1. Expert One-on-One J2EE Development without EJB by Rod Johnson, Juergen Hoeller

2. Tiger: A Developer's Notebook By David Flanagan, Brett McLaughlin

3. Better, Faster, Lighter Java By Bruce A. Tate, Justin Gehtland

4. Hibernate in Action By Christian Bauer, Gavin King

5. Enterprise Service Bus By Dave Chappell

6. Programming Jakarta Struts, 2nd Edition By Chuck Cavaness

7. Tapestry in Action By Howard M. Lewis Ship

8. Hibernate A Developers Notebook By James Elliot

9. JavaServer Faces By Hans Bergsten

10. J2EE Open Source Toolkit By John T. Bell, James Lambros, Stan Ng

Hot to Setup SourceForget CVS with Eclipse

2008-04-06T00:53:00.001+08:00

参与开放源码项目开发已经进行了很久，但是很多朋友还是不太熟悉这种协同开发模式和方法，下面这片文章将帮助大家迈开开源开发的第一步，

---- 使用eclipse配置sourceforge.net的CVS

1. 预备资源

. Eclipse 3.0 您可以从 eclipse 的官方网站下载

. 进行下面的操作前，你必须拥有一个SourceForge的帐户！

. home_dir -- 授权密钥目录. 例如: c:\ssh (windows)

. username -- 你的SourceForge用户名;

. projectname -- 你的SourceForge项目名称

. comment -- 用户放置公钥的标识符(使用你的email地址)

2. 安装，配置 SSH (以下以均以ssh 安装在c:\ssh为例)

下载SSH , 并安装在你的机器上

2. 在Windows环境变量里配置

Path=c:\ssh

HOME=your_dir 例如: HOME=c:\ssh

3. 测试ssh

在windows命令行窗口，进入c:\ssh

运行 ssh -l your_username(sourceforge用户名) shell.sourceforge.net

这样会在你的ssh目录下创建.ssh子目录

4. 生成密钥

运行 ssh-keygen -C comment -f ./.ssh/identity (注意: comment可使用你的邮件)

根据提示键入两次你的sourceforge.net 密码

登陆Sourceforge.net my sf.net

拷贝home_dir\.ssh\identity.pub里的字符串，并粘贴到Account Options 中的

Number of SSH Shared Keys on file: 1 [Edit SSH Keys for Shell/CVS]

等待6小时吧（sourcefore.net需要6小时将你的密钥同步到服务)，密钥安装就完成

3. 配置Eclipse CVS客户端

. 进入eclipse开发环境，并选择Windows --> Open Perspective --> CVS Repository Exploring

. 在左边的窗口，点击鼠标右键，选择Repository Location...

按如下方式添加

740)this.width=740" border="undefined">

点击完成便可完成cvs客户端的安装。

740)this.width=740" border="undefined">

The Way on Professional Open Source

2008-04-06T00:52:00.001+08:00

I leave for my dream , I am on the way of professional open source

I can still remember:

Most real innovation is done by crazy people doing crazy things

The keys are:

Learn all you can before you go adventuring.
Don't be afraid to make mistakes.
Only make new mistakes.
Keep your eyes open.
Don't just look straight ahead: develop your peripheral vision.
It's the things that go in unexpected directions are the most important.

Whatever will I do, I will stick to the end.

Do one thing , and do it well.

Open Source Collaboration Platform

2008-04-06T00:51:00.000+08:00

多人协作的软件开发如果没有一定的CASE工具来支持，开发的过程将会变得非常难于控制，特别是当开发人员在地理上是分布时，软件开发协作平台就显得尤为重要。下面将介绍进行开源组织里都使用什么样的平台和工具来进行分布式的协同开发与管理。

开放源码组织的最大一个特点就是分布.

1.人员分布: 所有的开发人员，贡献者可能来自世界不同的角落，在地理上是完全分散的，有可能其中的一个他/她就是旁边的同事，也有可能他/她在地球的另一端。

2.平台分布: 由于开源组织里规模大小不同，他们提供的服务也不一样，大的组织资金充足，硬件设备齐全，他们有自己的CVS服务器，邮件服务，Web站点等，例如: http://www.objectweb.org/, 而小的组织可能是借助像http://sourceforge.net/ 这样公共的开源服务协作平台。这些平台在物理上也是分布的，对于一个开发人员来讲，你完全不知道你所访问的服务器具体在什么地方，所以整个组织是一个虚拟的网络。

下面我们就来看一看，开源组织都使用哪些工具来进行开发、协作、交流。通常这些工具分为两类: 产品管理工具和项目管理工具：

产品管理工具:

1. 版本控制工具: 现在软件开发中使用的版本控制工具很多，商业化的产品（费用昂贵的产品），如Rational ClearCase, Microsoft SourceSafe, 等等；这里简单介绍一个目前为止最流行的开源版本控制系统CVS(Concurrent Version System), 由于这篇文章不是讨论CVS的具体使用, 感兴趣的读者可以访问http://www.cvshome.org参考详细的细节。

CVS

CVS是一种基于客户端-服务器的访问方式，并且能让开发人员通过Internet从任何地方获得最新的代码的并发版本控制系统。CVS通过文件日志的方式保留了存放在系统中文件的历史变更记录，这使开发人员能够控制在开发的整个过程中跟踪程序所有的变更情况，并且能够在出现bugs时很容易恢复到原有的代码版本，以便检查代码问题的所在。当多个开发人员协作开发时，常常会出现代码冲突，CVS提供了发现冲突的机制，但是冲突最终是由人来解决的，而不是CVS系统本身。下面的图给出了Huihoo开源项目所CVS系统

740)this.width=740" border="undefined">

CVS现在也正被很多流行的开源项目所使用，如:

Mozilla http://www.mozilla.org/cvs.html

The Gimp http://www.gimp.org/devel_cvs.html

Xemacs http://cvs.xemacs.org

KDE http://www.kde.org/anoncvs.html

Gnome http://developer.gnome.org/tools/cvs.html

2. 问题管理工具

任何软件都是有问题，这个世界上没有十全十美的软件。软件有出现问题不要紧，但是如果出现了问题无法跟踪就是一个很大的问题了。尽管现在的软件开发方法中引入了很多的机制尽量来检测软件的bug, 如单元测试，集成测试等等，但这些方法只能在有限的范围内尽可能的减少产品最终交付到用户手中后的错误，就算是现在流行的Windows 系统，也常常会由于系统的问题而发生死机。有人可能会说，我做的软件系统简单，不需要什么问题跟踪。但是对于任何大规模的系统，可能涉及到几千开发人员，上千万行代码，多种不同的发布版本，不同的模块的集成，在这样的情况下，系统的复杂程度不是一般人能想象的。所以要管理这样复杂系统的开发，人员的协作就必须使用问题跟踪与报告系统，对系统的问题进行分类，标示各个模块的状态，并且能够让分布的开发人员能够很容易的了解到他们所开发模块的状态，以及与其他模块间的关系，以便能够更好的进行协作。流行的问题管理系统有:

Bugzilla

Bugzilla 是由Mozilla团队开发的问题管理系统。

JIRA

JIRA 是由澳大利亚的Atlassian公司开发的基于J2EE的问题管理系统，它被称为J2EE的bugzilla,在易用性上比bugzilla有了很大的改进，当然它还有很多的优点，就不一一列举了，我推荐大家使用这个软件来进行项目的开发管理，JIRA现在已经广泛的被很多大型的软件公司以及开源组织所使用，详细情况, 下图是http://www.huihoo.org/所使用的JIRA(Huihoo的JIRA服务将在2004年第3季度推出)

740)this.width=740" border="undefined">

项目管理工具:

1. Clearinghouse

Clearinghouses是软件开发人员为寻找感兴趣的项目而从其它开发人员那里寻求帮助的地方.

现在Internet上最著名的clearinghouse平台之一是SourceForge, 下面我们就介绍一下

SourceForge

SourceForge 为开放源码开发人员提供免费主机服务，同时还包括，CVS仓库，邮件列表，问题跟踪，消息论坛，任务管理，Web站点主机，永久文件归档，备份等基于Web的管理。SourceForge的使命是为开放源码开发人员控制和管理开放源码软件的开发提供了一个集中的环境。

那么SourceForge平台上的开源软件的版权有谁来负责呢，是属于SourceForge吗? 答案是否定的，SourceForge上任何软件的作者都拥有自己软件的版权，任何与版权相关的问题都由软件作者自己负责，SourceForge本身之负责为开源软件提供服务，不涉及软件本身。通常对开源软件的一个误解就是开源软件是没有版权的，因为它是免费的。事实并非如何，每一个托管在SourceForge上的软件都由它自己的版权。这些版权都是由开发人员在创建项目时确定的，如: GPL, LGPL等等。

其他使用SourceForge系统作为协作平台的站点有:

Bioinformatics.org (http://bioinformatics.org/)

Handhelds.org (http://handhelds.org/SourceForge/)

Linuxalpha (http://www.linuxalpha.compaq.com/sourceforge/)

Open Source Directory (http://www.opensourcedirectory.org/)

University of South Carolina (http://source.cse.sc.edu/)

ObjectWeb (http://www.objectweb.org/)

2. Groupware

辅助开源团队进行交流的计算机辅助工具被称为Groupware. Groupware通常分为两类，

(1)同步: 如ICQ, 视频会议，投票系统

(2)异步: 电子邮件，工作流系统

小结:

综上所述，管理一个开放源码项目需要四种软件工具：一个基于Internet的clearinghouse, 一个用于项目管理的群件系统，一个用于协调开发人员变更的版本控制系统，一个用于构建软件的问题管理工具。所有这些工具都是为了使开源团队能够更加流畅，及时地沟通。

Open Source Collaboration Model

2008-04-06T00:49:00.000+08:00

Huihoo.org已经走过了2年多，这篇文章以huihoo.org为例，介绍一个开放源码组织的基本组织架构，内部的运作方式，以及组织内人员角色的划分与职责。（虽然现在开源组织运作的方式各有不同，这里以huihoo.org主要是为了分享给大家一些huihoo的一些操作方式)

一般来讲，无论你是在企业，学校，或其他的地方学习和工作，实质上都是在一个实际或虚拟的组织里生存，就好像社会中不同的团体，只是这种组织的规模各有不同。我们通常把在这种组织里的互动过程看作是玩一场游戏，所以要玩好一个游戏就最基本的就是要有好的游戏规则。下面的我们就来结合http://www.huihoo.org/ 的组织模型来了解一下一个开源软件组织的基本组织结构，角色分类，每一种角色的职责，以及开源软件项目的基本游戏规则。下面的图给出了http://www.huihoo.org/ 的基本组织结构

740)this.width=740" border="undefined">

首先，一个开源软件组织都会有一个合法的机构来支撑，例如：http://www.huihoo.org/的主要职责是为这个组织中的开源软件项目提供基本的基础设施，如：website，邮件服务器，为组织内开展的丰富的活动，如技术交流会，用户大会等，提供资金的支持。有人这时候就常会提出一个疑问，它的资金从何而来? 资金的来源一般有四种: 一：个人捐助；二：企业赞助；三: 学校，科研机构的赞助；四: 自筹。http://www.huihoo.org/从成立到现在已经走过了2年多的历程，在这期间等到了很多朋友的支持与捐助，有的是直接捐钱，有的是为我们提供硬件设备。同时我们也正在与国内的各大高校展开积极的科研合作，希望能够获得一些国家科研基金的支持与帮助。我们自己也将会制作了一些组织活动的T-Shit, 用于销售给组织的成员，来获得一些活动基金，这部分资金实际上是开源软件贡献者对组织的一种捐助。

其次，项目管理委员会(PMC, Project Manager Committe), PMC的职责是负责对开源组织内的项目做出战略上的指导，并保证项目的朝着健康的方向发展。PMC同时也负责所有项目的开发指导，冲突解决，开发过程，基础设施，以及项目的技术方向。.

PMC的职责:

为组织内的所有项目整体方向提供指导和定位
为项目开发人员提供援助与支持，包括清除障碍，解决问题，解决冲突。
为开发团队建立所需的开发过程和基础设施。
为组织推荐新的子项目，并指定合适的子项目负责人。
确定子项目初始的PMC成员，并新成员的加入建立投票规则。
协助保证子项目有足够的贡献者，并帮助能够填充角色的空白。
制定”如何加入开源项目”的指南，以帮助新的贡献者加入项目。
协调组织内开源项目间的关系。
推动个人或公司对开源组织的代码捐赠或其他捐赠。
负责组织内开源项目对外界的推广

最后，技术主管、开发人员、测试人员、贡献者。从图中我们可以看到除了PMC之外，还有四种角色: 技术主管，开发人员(代码拥有者，代码评论者), 测试人员，贡献者。

技术主管: 负责项目整体方向的规划，体系结构的设计，代码的编写，以及项目组人员的交流，协调，问题的解决。

开发人员：开发人员里通常会有两类不同的角色: 代码拥有者和代码评论者，代码拥有者拥有对代码的修改权限，负责系统的开发，设计讨论，文档的编写。代码评论者，一般是有着丰富经验的开发人员，负责对代码的风格，逻辑问题进行检查，以保证代码的质量。

测试人员: 测试人员负责对代码进行测试，编写测试用例及测试代码。

贡献者: 贡献者应该是范围最广的一类人员，可以任意参与项目的讨论，问题的查找，提供软件补丁，等等。

以上四类角色除了贡献者的角色以为，都具有对代码的访问权限（即具有CVS ,或其他版本控制工具check in 许可），在下一个blog里，我们会仔细讨论，如何真正获得参与到项目开发中的权限。

那么这四类角色之间的有什么关系呢?

由于开源软件组织通常采用的是多领导人制, 非层次化的组织模型，这与传统的企业的组织模式有着截然的不同（传统企业是层次化的，有着严格的领导于被领导的关系）。从某种角度来讲这种关系的耦合程度应该是极度松散的。组织内的每一个人都是绝对平等的，所有的一切都基于信任(trust)和尊重(respect)。

在传统企业和公司里，雇佣者与被雇用者之间有一张合同来规定你所应做的和不应该做的，如果你离职，可能还需要支付一定数目的违约金。但在这里，没有！你可以选择在任何时候加入，也可以选择在任何时候离开，而且你也不需要写一张辞职报告。可想而知，在这样极度松散的环境中进行协作开发的难度，所以积极主动(self-motivation)是每一个开放源码开发人员最基本的特点，他们都是对自己的兴趣爱好有着极高热情的人，虽然这种热情在不同的时期都又所不同，但一切的都建立在信任之上，任何人都平等的。每一种角色只是分工不同，没有领导与被领导，管理与被管理的关系，对于任何问题，你都可以提出自己的看法，和见解，没有一个问题是坏问题。

开源组织里的大部分交流都是通过GroupWare(如电子邮件，论坛来进行的), 一般性的问题大家通过邮件等形式进行讨论，而对于重大的问题，如新开发人员的加入，新项目的建立等需要做出决定的问题要的都由所有成员进行投票决定，有效地票数以经常活动的开发人员为准，最后答案要根据具体的投票结果来决定。

小结:

经过实际的一些操作，我们发现这个过程中还是遇到了很多的问题和困难，希望有更多的热爱开源的朋友能帮助我们一起来解决，希望http://www.huihoo.org/会按照这种开放的模式发展得越来越健康。

What's wrong with SUN?

2008-04-06T00:38:00.001+08:00

SUN和Microsoft长达10年的对抗终于有了一个了结，微软和SUN达成$16亿和解条款，让人惊叹！

SUN现在真的没有后路了吗，还是Bill Gates和Scott McNealy密谋的结果

SUN的又一位VP Rich Green 也因此而离开了SUN, 记得去年在第六届全国Java技术大会上听过Rich先生的演讲，今年3.11在北京软件产业促进中心和Green先生就开源运动在中国的发展做了一个交流，虽然时间很短，才30分钟，但是感觉Green先生对Java,及开源支持的热情，Rich 先生曾在在与微软的反托拉斯法案中为SUN据理力争，这次的离开，实在是让人感到遗憾，同时也让我回想起SUN另一位著名的人物 Bill Joy的离开。

Java的下一步将如何，让我们很担忧。。。

Richard L. Green 简介

Sun公司副总裁

Sun开发者工具和Java 软件部

Sun Microsystems公司

Richard L. Green先生是Sun Microsystems公司负责Sun开发者工具和Java软件的高级副总裁，他的主要职责是推动Sun的开发者工具系列产品策略的实施；监督产品的高效生产和交付；以及协调和管理Sun在Java Community的各种活动，确保所有活动的协调一致。

此外他还负责监督Sun在Java Community Process之中发挥有效的作用，以便协助数以百计的许可证持有者和合作伙伴以及数以百万计的开发者相互协作，共同推动Java平台的发展。

在此之前，Green先生担任Java和XML软件部副总裁，负责将Sun的Java 平台和XML技术成功推向不同市场，包括在智能卡和掌上设备以及台式机和服务器等广泛多样的市场上创下佳绩。

在领导Java 部门之前，Green先生担任Solaris 产品部副总裁，负责Sun的Solaris操作系统的战略制定、产品设计和市场营销。

自1989年加入Sun以来，Green先生在许多不同的领域显示了卓越才能，他曾经负责管理的领域包括分布式目标系统、网络通信产品、桌面集成技术、软件开发工具和数据库系统的设计和开发。

加入Sun之前，Green先生负责管理CAD/CAM和图形设计项目并设计了用于运输研究的仿真软件。

Green先生毕业于奥尔巴尼的纽约州立大学，拥有文学学士和文学硕士学位。

Spring is Coming

2008-04-06T00:37:00.000+08:00

Dramehead 最近在他的Blog上发表了一篇关于Spring使用后的感受，我眼中的Spring,写的不错, :)

最近我自己也研究并比较了一些开源的应用框架, 虽然各有侧重，但Spring看起来更像是一个集成Application Framework，

The Core：Bean Container

从我看来， Spring 最核心的部件就是它的Bean Container, 这种IoC Type2 的轻量级容器，在整个框架中扮演了一个微内核的结构，更确切的说是一个软总线，它使框架内部的组件按照一定的耦合度组装起来，并能对使用它的应用提供一种基于服务的编程模式(SOP: Service-Orient Programming,, SOP已经不是什么很新的概念，大家可以在http://avalon.apache.org/ 找到更多SOP的影子)。从Spring本身来看，它已经将许多的System Level Service进行的集成，比如Persistence(Hibernate,etc) , 这样软件内部的编程结构就形成了下面的模式:

Application Code <---> Service Manager ( LightWeight Container) <---> Service

软件内部的体系结构的变迁，如下图所示:

600)this.width=600" border="undefined">

更多关于使用种关于IoC Container所带来的好处，建议阅读MartinFlower的文章Inversion of Control Containers and the Dependency Injection pattern

Vs EJB Container

在应用的开发过程中，你也可以将你的Business Level Service封装成一种组件部署在Spring提供的Bean Container之上，我想这时候有人可能会问，这种部署和我部属一个EJB到EJB Container里是一样的吗？我觉得不是， EJB Container 是一个Type1的重量级容器，部署在它内部的EJB都都被迫使用了EJB Container的提供的服务，比如缓冲池，并发控制，事物管理等等，所以你的EJB部署到容器内部之后，所有的控制管理已经完全托管给EJB Container, 通常有时候我们的应用实际上并不需要那么多的Service,可能只需要使用到其中的一个，但是我们如果把它封装成EJB, EJB Container就会强迫的加载这种服务，不管你是否真的需要，所以我们在使用EJB的时候也要根据具体的应用进行技术选型，先问一下自己，我真的非常需要那些EJB Container提供的好处吗，它所提供的好处能在我的应用中发挥多大的百分比，通常这种选择是一个两难的事情，我们只能在特定的环境下取得一个平衡，没有最好，也没有最坏。

什么样的类更适合于放在轻量级容器里?

刚开始使用Spring进行开发的人常见的一种惯性思维就是，我写的这个类一定要放到Bean Container里进行管理，结果形成的一个现象就是系统中有太多的类使用Spring的描述文件（xml)来定义相关之间的依赖关系，在现实世界的系统中，当程序内部的组件，服务随着项目本身的规模逐渐增大时，这种结构就有可能会导致程序变得非常难于理解，这也是是后面的部分将要提到了使用 Spring可能带来的风险。在我看来，Bean Container毕竟还是一个轻量级容器，他的主要职责是为应用组件之间的交互提供一个组装机制。

下面引用Martin Flow文章中的一段文字：

在一个真实的系统中，我们可能有数十个服务和组件。在任何时候，我们
总可以对使用组件的情形加以抽象，通过接口与具体的组件交流（如果组件并没有设计一个接口，也可以通过适配器与之交流）。但是，如果我们希望以不同的方式部署这个系统，就需要用插件机制来处理服务之间的交互过程，这样我们才可能在不同的部署方案中使用不同的实现。所以，现在的核心问题就是：如何将这些插件组合成一个应用程序？这正是新生的轻量级容器所面临的主要问题。

从这段文字我们不难看出，轻量级容器主要解决的问题是如何将插件组合成一个应用程序.

面向对象里的一个基本原则之一就是开闭原则(Open-Closed Principle)

Software Entites(Classes, Modules, Functions, and so forth) should be open for extension, but closed for modification

所以一个组件(或服务）对使用它的客户端来讲暴露的它外部的接口，看下面的使用log4j的代码片断：

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

public class FooTest {

private Log log = LogFactory.getLog("Foo.class");

public void foo() {
log.debug("debug Foo");
}

public static void main(String[] args) {
FooTest test = new FooTest()
}
}

从上面的代码我们可以发现，当我们使用Log4J这个组件时，我们并需要关心Log4J内部的实现和复杂的依赖关系，我们只需要看到它提供的org.apache.commons.logging.Log接口就可以。

这些对外暴露的部分就是插件，这类插件的思想我们可以在eclipse里看更丰富的体现,可能实现的机制有所同。

因此，我认为从软件整体的角度来看，更适合放在这些轻量级容器里的因该是组件暴露出来的一些boundary class, 他们是应用代码访问具体服务的一个Entry Point, 应用代码通过轻量级容器来获得这些boundary class，这样就形成了前面The Core：Bean Container里提到的编程模型。

再次引用Martin Flow文章中的一段文字：

我将开始介绍Dependency Injection 模式的几种不同形式。不过，在此之前，我要首先指出：要消除应用程序对插件实现的依赖，依赖注入并不是唯一的选择，你也可以用ServiceLocator 模式获得同样的效果。

Service Locator 模式背后的基本思想是：有一个对象（即服务定位器）知道如何获得一个应用
程序所需的所有服务。也就是说，在我们的例子中，服务定位器应该有一个方法，用于获得一个
MovieFinder 实例。当然，这不过是把麻烦换了一个样子，我们仍然必须在MovieLister 中获
得服务定位器，最终得到的依赖关系如图3 所示：

600)this.width=600" border="undefined">

实际上在J2EE的体系结构中已经体现出来这些思想。

我们来看一下J2EE 中ServiceLocator的一些实现

600)this.width=600" border="undefined">

当客户端的代码要访问服务器端提供的服务（比如我们所开发的EJB, 具体的某一种business service)时，客户端代码通过ServiceLocator来查找服务器里驻留的Service(在J2EE里是通过服务的JNDI命名), 获得服务对具体服务的访问,这种访问可以是本地方式，也可以是远程访问(比如使用RMI-IIOP),下面来看一下PetStore里的一段具体的代码，这样会更有助于我们来理解这个概念:

应用代码:

/*
* Use the Service locator pattern to located the Catalog
* Home and use the home to create an instance of the
* CatalogLocale EJB.
*/

private CatalogLocal getCatalogEJB() throws CatalogException {
try {
ServiceLocator sl = new ServiceLocator();
CatalogLocalHome home =
(CatalogLocalHome)sl.getLocalHome(JNDINames.CATALOG_EJBHOME);
return home.create();
} catch (javax.ejb.CreateException cx) {
throw new CatalogException(cx);
} catch (ServiceLocatorException slx) {
throw new CatalogException(slx);
}
}

ServiceLocator.java 远程调用实现

/**
* will get the ejb Remote home factory. If this ejb home factory
* has already been
* clients need to cast to the type of EJBHome they desire
*
* @return the EJB Home corresponding to the homeName
*/
public EJBHome getRemoteHome(String jndiHomeName, Class className)
throws ServiceLocatorException {
EJBHome home = null;
try {
if (cache.containsKey(jndiHomeName)) {
home = (EJBHome) cache.get(jndiHomeName);
} else {
Object objref = ic.lookup(jndiHomeName);
Object obj = PortableRemoteObject.narrow(objref, className);
home = (EJBHome)obj;
cache.put(jndiHomeName, home);
}
} catch (NamingException ne) {
throw new ServiceLocatorException(ne);
} catch (Exception e) {
throw new ServiceLocatorException(e);
}

return home;
}

使用Spring可能遇到的一些问题

1.错误检查

由于Spring使用了基于xml配置文件的方式来管理它的bean, 这样做的一个好处是使你的代码的结构更易于动态的配置(这是一种相对的动态), 但是带来的一个问题是，程序的错误的检查被延迟到了运行时，而不是编译时，虽然Spring有第三方的插件来帮助做编辑xml配置文件时的这里错误的检查，但这还是Spring本身的问题。特别是当多个人协同开发，这些配置文件需要经常进行同步时，就会带来很多时间的开销，所以一个建议是进行持续的集成，保证刚项目随着时间的推移和规模的不断增大时保证这些配置文件的正确性和可控性。这里又涉及到很多软件过程控制的问题了，已经超越了本文所讨论的范围，可以阅读我的另一篇Blog: My First XP Practice

2.代码的可维护性

软件中代码的可维护性也是衡量一个软件质量的标准，当然最后为防止被人反编译，把原代码全部变成以a,b,c命名的类也是一种不错的反盗版方法。我的一个同事在使用Spring进行开发的过程中的一个体会就是，他写完的类被装配到Spring中后，根本不知道拿去干了什么，这似乎是达到了汽车流水线装配的神奇效果，让我惊讶！如果软件开发的过程能像汽车组装工厂一样，那软件开发的过程和方法可以说是达到了相对完美的境界，但那似乎是还是一个比较遥远的梦想。在XP中说到的一个关键实践就是Collective Ownership, 保证你的代码在一定程度下更易于让他人理解和维护，对于整个项目来讲，是有益的。代码可维护性的风险将在下面的小节里谈到。

特定情况下可能带来的风险

软件结构与人员的变化的风险

如果你的人员会经常地发生变化，而且软件的规模在不断的增长，新来的人去读原来的代码就会变得异常的困难，为了尽量的避免这种风险，那你就需要经常地去和你的队友讲解程序内部的结构，保持一个良好的沟通，不会由于某一个关键人物的离开，到导致项目长时间的停滞甚至失败。我的一个实际的经验：在过去半年中带领了一个团队对原有的一个基于Model 1方式开发的Web系统使用Struts进行改造, 这个系统前后花费了2年的时间进行开发，维护，不断地升级，包括现在也是。为什么要进行改造（更确切的说是重写）？原因很简单，这个系统由于初期体系结构设计的问题，和人员的问题（参与这个项目的核心开发人员已经全部离职), 导致现在整个系统在后期需要新增一些功能的时候变得异常困难，一是没有人知道原有系统内部的结构，原有系统代码结构异常混乱，导致开发一个新的功能需要花费更多的时间，不能及响应客户的需求。二是开发人员谁都不愿意去修改那令人恐惧的庞杂代码，相互推卸责任。

结论:

本文以Dramehead的一篇对于Spring使用感受为引线，分析了使用Spring框架后给软件内部体系结构带来的变化，以及轻量级容器与EJB容器的比较。同时结合实际项目中的一些经验描述了使用这类框架结构可能产生的风险。

事实上应用框架的大战才刚刚拉开战幕，让我们参与并期待有更多新的思想的出现，使我们的应用软件的开发变得更加高效和稳定。

最后列举出现有开源框架软件的一个分类(源自CambridgeUniversity Java Framework and Component一书)，

Complete Application Frameworks

1. Name Avalon

Supplier: Apache Software Foundation

License: Apache License

Focus: Server Components

2. Name Cocoon

Supplier: Apache Software Foundation

License: Apache License

Focus: Website publishing and dynamic applications

3. Name Expresso

Supplier Jcorporate Ltd.

License Apahce-Style License

Focus Database-oriented Web Application

4. Name Arch4J

Supplier Sycamore Group, LLC

License SpiderLogic Open-sources Software

Focus Complete application framework;concentrates on model portion of the MVC architecture, business services

5. Name ACSJ

Supplier: Red Hat Software

License: ArsDigita Public License

Focus: Complete application development

6. Name Turbine

Supplier: Apache Softwre Foundation

License: Apache License

Focus: Complete Application Framework

7. Name realMethods Framework

Supplier: realMethods

License: Commercial license, per developer seat or unlimited

Focus: Complete application for full J2EE environments

8. Name: OpenSymphony

Supplier: The OpenSymphony Group

License: Apache-Style License

Focus: Flexible J2EE Framework

9. Name: Spring

Supplier: Spring Framework Community

License: Apache License, Version 2.0.

Focus: Java/J2EE Framework

Presentation Frameworks

1. Name: JavaServer Faces (JSF)

2. Name: Struts

Supplier: Apache Software Foundation

License: Apache License

Focus: JSP presentation,flexible connection to application logic

3. Name: Maverick

Supplier: Infohazard.org

License: MIT X-Consortium license

Focus: Presentation

4. Name: Scope

Supplier: Steve Meyfroidt

License: BSD-type license

Focus: HMVC Presentation

5. Name: Webmacro

Supplier: Semiotek Inc

License: Apache-style License

Focus: Template Processing

6. Name: Velocity

Supplier: Apache Software Foundation

License: Apache License

Focus: Template Engine

7. Name: Tapestry

Supplier: Howard Lewis Ship

License: LGPL

Focus: User Interface

8. Name: Barracuda

Supplier: Lutris Technologies/Enhydra.org

License: Enhydra Public License

Focus: Server Components

9. Name: Tea

Supplier: Walt Disney Internet Group

License: Tea Software License

Focus: Presentation and Templete Engine

10. Name: Freemarker

Supplier: Benjamin Geer, Johnathan Revusky

License: BSD License

Focus: Template engine for presentation

11. Name: Echo

Supplier: NextApp

License: LGPL

Focus: Sophisticated user interfaces for Web Application

Meta-Frameworks

1. Name: Keel Meta-Framework

Supplier: Keel Group

License: BSD-style License

Focus: Meta-framework: integration of multiple framework

My First XP Practice

2008-04-06T00:36:00.000+08:00

公司一直以来都采用的传统的开发模式（公司按照的是ISO9000的要求), 但由于项目客户(电信，移动) 的特殊性,项目的时间通常都是非常的紧促，项目的需求变化频度很高，我逐渐发现这种方式并不能满足客户的需求，庞大的复杂的流程，和文档反而成了项目过程中的一种负担，大多数的过程产物最终都变成了即占物理空间，又浪费人力的储存品，我们真的需要那些东西吗，我们生产的是软件还是文档？我开始尝试XP...

GiGix在不完美的XP实践谈到了一些XP的实践，下面是我的一些经验

在项目即将达到一个里程碑（或即将完成的)的时候，如果发现在确定的时间内无法完成，适当的加班是有益的，这可以使你项目在可以容忍的时间范围内保持项目发布的进度，XP项目的一个特点就是，在项目的每个小的迭代周期内要保持实时的跟踪与调整.

积极的沟通与反馈(feedback)，将更加有利与对项目的进度进行控制和保持团队成员积极向上的心态。

最近我在一个项目中实施了XP中的部分实践，项目现在进行了5个多月，产品的版本发布都按照预期可控的时间进行发布，并且工作得很好，让我感到很高兴的一件事情是：在这个过程中培养出了4个不错的新人（刚刚参加工作的本科毕业生)，现在他们基本上能够单独胜任分配给他们的任务，其中做得最出色的一个，在中途调离项目后，使用了1个多月的时间，和其它几个同事一起开发了一个中等规模的Web系统，让我非常地吃惊！

XP并没有针对特定的人，它在一定的环境下也适合新人（可塑性很强), 但是新老结合的模式下会工作得更好，在这个项目实施的过程中，还有一件让我感觉很有意思的就是:项目在开始的时候有8个人，但随着其它的变化，在项目进行的过程中人员经常发生变动，直到最后剩下4个人，但是这些变动并没有太大影响产品在定义的里程碑进行发布。

实践心得:

1. 要拥抱变化

2. 项目既需要目标，也需要计划 --- 《最后期限》

3. 短期的压力乃至于加班可能是有用的策略，因为它们能使员工集中精力，并且让他们感到工作的重要性。但是长时间的压力肯定是错误的 --- 《最后期限》

4. 积极的沟通反馈，能使组员之间保持一个更和睦的关系和积极的心态，同时有利于从中获得更多项目的信息，以便及时对项目进行适当的调整与控制。

5. 人是软件开发的最关键的因素

支持工具:

JUnit http://www.junit.org/ (TDD)

Maven http://maven.apache.org/ (Continueous Integration)

Eclipse http://www.eclipse.org/ (IDE)

JIRA http://www.atlassian.com/software/jira/ (Bug and Issue Tracking)

Open Source Licenses

2008-04-06T00:35:00.000+08:00

最近仔细看了看OSI的几种open source license, 从中也学到了不少开源与法律的问题，

ASF, BSD都是非常松散的协议,基本上对使用它的人,公司或组织没有什么限制,所以你可以把符合这样协议的os软件进行任意的包装,修改,可以公开,也可以不公开。最近ASF 2.0的协议已经修改得和BSD很靠近了。

而GPL,是一个要求比较严的,对谁严格呢,使对使用它的人严格, FSF的创始人Richard Stallman
，是一个崇尚自由的人,所以你使用GPL协议下的软件进行二次开发，包装也应该free,公开源码，感觉像把开放源码进行到底，当初他为什么从MIT实验室离开，因为他在开发出来的软件的版权就属于MIT试验室，就不能分享给更多的人。所以他创建了FSF ,GPL协议要求严格，要求你使用,修改了它的源代码也要开放修改后的代码,因此很多公司商业公司都不愿意使用的GPL下的开源软件进行商业化的开发。 LGPL就相对GPL松散一些,意思是说这个授权是由软件的作者来进行解释,至于怎么解释就由作者或作者授权的组织来解释。

总的来说open source软件的版权首先是属于作者本人,在作者本人同意的情况下可以由作者进行授权到其它组织或公司, 这些协议首先也是为了保护作者自身的版权。

Open Source Developer: Will Work for Food!

2008-04-06T00:33:00.000+08:00

最近看了Richard Monson-Haefel 在http://www.java.net/上的一篇关于open source develoer的评论 http://weblogs.java.net/pub/wlg/942
Open Source的热潮正在逐步升温，在中国做open source有时候让人也不觉迷惑，西方发达国家的程序员生活在一定程度上都有保障，但是我们中的绝大多数人是要面对一个生活的问题，如果生活都无法保证，哪还有精力来做open source. 所以我同意Richard的观点，open source 开发人员还是应该有一份工作。

在过去的3年中，把很多的业余时间都贡献给了open source，从这里我更多的感受到的是一种自由，平等。每天我扮演着两种不同的角色，commerical developer and open source developer, 晚上，我可以在open source的社区里做我喜欢做的东西，和很多的有着相同兴趣的朋友交流，共同探讨技术，解决问题，感受这种自由带来的快乐。没有欺诈，没有歧视，没有等级观念，没有管理与被管理，大家都是平等的，所有的一切都是以信任与尊重为基础。白天，作为一个商业公司的开发人员，我可以在开发商业软件的过程中把从open source中学到的知识，或者一些好的想法，在实际中的进行验证。就像struts现在已经被大家所认可一样，只有大家实践验证了，才知道open source软件的优点与缺点，在这个过程中能够与人分享，积极给予的反馈，这样既能帮助自己提高开发的能力，开阔视野，同时也为更好的改进open source软件做出自己的一份贡献。linux之所以成功并不是因为它的内核结构是多么的优秀，而是因为聪明的linus为linux 创建了一个好的开发，协作，分发模式，让全世界的开发人员都能自由的参与到linux的开发中来，这才是linux成功的之处，魅力所在。 Open Source在中国才刚刚迈开她的第一步，后面的路是什么样，谁也无法预料，但我愿意和我的朋友去探索这条让人充满激情和荆棘的开源之路！

Open Source Thoughts

EJB or Without EJB

What's going on with requirement?

Service-Oriented Programming on MicroKernel

JFox on TSS

JFox Application Server 2.0 M1 Released

Meet Open Source Guys

Migrate JPetstore To JFox

1.介绍

1.1 JFox

1.2 JPetStore

2.1软件环境

3.系统安装

3.1 Java安装

3.2 JFox 安装

3.3安装MySQL

4.JPetStore应用部署

4.1 JPetStore部署

4.2运行JPetStore

5.参考

OpenSource & OpenSource Software

My Top 10 Reading Books

Hot to Setup SourceForget CVS with Eclipse

The Way on Professional Open Source

Open Source Collaboration Platform

Open Source Collaboration Model

What's wrong with SUN?

Spring is Coming

My First XP Practice

Open Source Licenses

Open Source Developer: Will Work for Food!

3.3 安装MySQL