Hibernate's SchemaUpdateTask for Ant

I was trying to set up an Ant task to handle schema update from Hibernate (3.3.1 GA), something seemingly straight forward enough. But I kept getting NullPointerException. This annoys me to the extend that I googled for a whole day (yes, I am stubborn) trying to find a solution, but to a no avail.

Finally, I read the source code (should have done this way earlier) and realized the "outputFile" was never set anywhere and therefore it has to be specified in the Ant script. Sure enough, that got rid of the NullPointerException and the task was run successfully. And I am reasonably happy.

Here is how my task was defined:

  <target name="schemaupdate">

    <taskdef name="schemaupdate"

      classname="org.hibernate.tool.

                 hbm2ddl.SchemaUpdateTask"

      classpathref="project.class.path"/>

 

    <schemaupdate

      config="src/hibernate.cfg.xml"

      text="no"

      namingStrategy="org.hibernate.cfg.

                      DefaultNamingStrategy"

      outputFile="schema-update.sql"

      quiet="no">

    </schemaupdate>

  </task>

I couldn't find the existence or the need for the outputFile attribute documented anywhere. So I guess I do it here just in case there is another poor soul like me pulling all the hairs out just trying to find a solution like this. The "namingStrategy" there may not have been necessary, but I didn't feel like doing any further investigation (yes, I have a limit). Keeping it here wouldn't hurt, I guess.

Programmer Is Not Just a Coder

When I first got into the programming field, I heard the debate on whether programming is an art or science. For my understanding, the debate ended (at least in my mind) with the consensus that it is both. So when I got my master degree of arts in computer science, I was very happy about the name.

But over the years, I have heard enormous times that people consider programming a routine work. Instead of "programmers", they were then called "coders", which implies that you are just writing code, with everything else stripped from you: requirement, design, testing, deployment, etc., as if those are other (more important) people's business. Also, programming, in the minds of some people, becomes a labor-intensive low level, low tech work.

There are many problems in this thinking, but the single most fundamental error in this is the view of "coder". A program cannot be finished without the programmer considering each and every phase in the programs' life cycle. Yes, the programmer may not actually perform those tasks, such as requirement gathering, architectural design, testing, deployment, but these elements must be embedded in the program itself before it can achieve the intended result. This requires active involvement on the programmer's side. This leads to the understanding of how the cognitive processes works for programmer to acquire the knowledge in the development processes as a whole; not only the knowledge of how to do general design, etc., but the knowledge of what have been done or need to be done.  These are a set of complicated processes. 

One of the most important and useful tool to ensure the success in this kind of cognitive processes is empowerment. So instead of calling them coders, we need to encourage them to participate in all areas of activities in software development.  Recent Studies has shown that without empowerment, people simply lost their ability to get ahead of the game.  This study shows, according to this web page, that,

Executive functions help people maintain and pursue their goals in difficult, distracting situations. The researchers found that lacking power impaired people’s ability to keep track of ever-changing information, to parse out irrelevant information, and to successfully plan ahead to achieve their goals.

In our context, executive functions are ability to handle issues coming up from those phases in software development life cycles; those are truly difficult and distracting situations.

So the programmers deserve the respect and empowerment from the management in order to do their work. If you are thinking about trying to get your software development project done, please empower your programmers.

On other token, however, the programmer themselves will have to recognize this as well. You are much more important than who you think you are!

Agile: It Is Not Because of Waterfall

When reading articles on Agile methodology, it occurs to me that a lot of people are victims of Waterfall. This shows because there are endless comparisons, when elaborating on how useful Agile approach is, between Agile and Waterfall.  What strikes me as peculiar is that when I am preaching Agile approach to others, I was also comparing this with Waterfall.

The reason that this is interesting, is that I don't think most people were victims of Waterfall. Rather, most of us are victims of the nameless chaotic situation that we can blame Waterfall for.  Don't get me wrong, I am all for Agile and not a bit for Waterfall. However, knowing where we are coming from is important, when we are trying to figure out a way out of the chaos.

I have been working in the software development field almost evenly between small companies and large corporations for almost twenty years. I haven't seen anything that came close to a formal Waterfall process being explicitly or implicitly executed. The only glimpse of Waterfall that I had, was in a rare job interview a long time ago. There I was presented with a thick design specification armed with glossy papers, carefully chosen fonts and nicely done layout and with fancy schmancy UML diagrams.  Since it was only an interview, so it doesn't count. I can also guarantee you that most developers you run into, especially on Wall Street, have no idea what Waterfall means. The first thing comes to mind would be Niagara Falls.

The point is, for most of us, the need for Agile development methodology is really not because we hate Waterfall that much (although it is pretty bad, in my mind anyways). We are more concerned with a better way to come up with a working computer program that our bosses, our customers and, perhaps more importantly, ourselves will be satisfied. The reason Agile appeals to us, is because it breaks things into manageable pieces in terms of functionality and resources. Therefore, it is not chaotic.

Because of this, I am not overly concerned about whether Agile is tool-based or human-interaction-based. I don't really care too much about the yellow stickers and the whiteboard, or the need for people to sit in room so they can casually communicate verbally. Not even the stand-up meetings. Those are not the key features; and they may not even need to be nice-to-haves. (The meeting is important, I would probably insist, but the format is not.)

By the way, this is one of the reasons why I don't see a conflict between Agile and CMMI. Please see my earlier articles for this.

EJB的意义

刚刚看到一篇有关J2EE的文章，想起一件事。记得很多年以前，我为找工作去在纽约的一个投行面谈，被人问到这样一个问题，为什么要用EJB？我回答说，这是对分布系统的概念的一个实现，最终目的是为了提高系统的Scalability。问者对这个答案显然是不以为然，认为我没抓住其重点与关键，最终面谈也不欢而散。

我后来又看过一些J2EE的书，也读过一些网上的文章，确实发现好象没什么人太重视EJB在分布系统的贡献，更多的是把它往n-tier架构上归类，比如Client/Server，Browser/Server模式，或者是往组件构件（Component）上归类。为什么会是这样，我是百思不得其解。但是现在EJB的应用越来越失势，与一般人对它的那种不正确的期望可以说不无关系。

EJB的最大特点，就是Invoke它需要很大的overhead，甚至要通过网络跨越于不同的服务器之间。难怪别人说它的性能不太好。但它的优点，也就是可以动员很多服务器一起，提高对海量数据的处理速度。在设计系统的架构时，要很充分地考虑到这点，设计得当，性能将会有很大的提升，不然的话，就象现在大多数EJB应用一样，慢慢吞吞的。

敏捷的版本管理

软件开发中的配置管理非常重要的一环是如何管理版本。版本管理的技巧是决定你的项目是否能够敏捷的关键。其实，这个所谓技巧很简单，就是做最简单的事，只要不把事情搞复杂了，事情就好办了。

假设使用的是Subversion（其他的也类似），最简单的版本管理是这样的，

1. 所有人都用Trunk，Check-in的时刻可以是每天几次，也可以是每个Sprint Backlog完成后一次。
2. 每天晚上，把Trunk重建一次，产生一个到那天为止最正式的版本，放在/tags/daily/1.0.b，这里b是一个序号，从零开始，每次加一。如有必要，也可以随时重建。
3. 每个Sprint结束时，把最后一个tag复制到/tags/release/1.0.15，假设15是最后一个版本。

可见这里其实并没有建立分支，也可以达到目的了。这当然是假设每次的发布都是包含新Product Backlog的版本，如果需要给产品只打补丁，事情就开始稍微复杂一些。我们可以这样做：

1. 到/tags/release中找到在线上的产品的版本，例如是/tags/release/1.0.15，将其复制到/branch/1.1。
2. 类似上面的步骤，每天晚上，把/branch/1.1重建一次，放在/tags/daily/1.1.b。b也是从零开始，每次加一。
   
3. 打补丁结束时，把最后一个tag复制到/tags/release/1.1.3，假设3是最后一个版本。
   
4. 如果需要，可以在这个时候把所打的补丁移植到Trunk里面去。

随便一提，这里的版本号由三个数字组成，f.p.b，其中，f是Feature号，p是Patch号，b是Build号。如果发布的版本有新的Feature，f加一；如果是一个补丁，p加一；对于任意一个f.p的组合，b都是从零开始，每次重建，都要加一。

有一种习惯是要程序员把要Check-in的东西先Submit到一个临时的Branch，到一定的时候，才把这些东西Merge到上述应该Submit的地方。这种方法显然与敏捷的概念矛盾，而且Overhead很大，不值得在敏捷项目中推荐。

CMMI与Agile的交集

最近有人在中国开展了有关将Agile与CMMI相结合的讨论，其中一个令人困惑的问题，是CMMI是一系列硬性的过程定义，与Agile的实践格格不入，很难有一个交集。

我倒不这样认为。其实，在看清楚之后，人们很容易判断象SCRUM之类的Agile实践其实并不是过程本身，它们都只是一个框架，以方便在其之下展开过程。而CMMI则真的是一系列过程的实践，也可以说是开发过程的最佳实践，而CMMI本身好象并没有要求这些实践一定要在什么框架之下进行，这就为这两者相结合创造了条件。

从另外一角度来考虑，我认为在机构中推动CMMI的最困难之处，在于没有一个适合软件开发的框架，过去实行的老一套的基于Waterfall的框架已经被实践证明不适合软件开发，而SCRUM则正好填补了这一个空缺。

以我的理解，在CMMI Level 3所要求的实践之中，基本上可是把它们分成三个类型，一个是项目管理，另一个则是机构管理，再者就是技术方案。在Agile中，前两个是SCRUM的专长，后一个是XP的专长。我们可以把一些具体的实践来出来晒一晒，比较一下。

项目管理类

在这一类里有下面几个实践领域，

• 需求管理
• 项目计划
• 项目监控
• 危机管理
  
• 配置管理
  

SCRUM基本上包括了前三个实践。需求是通过产品Backlog来管理的；项目计划和监控是通过对产品Backlog和Sprint Backlog的安排来达到的，同时也直接定义了SDLC。危机管理是通过不断地对Sprint对行总结审查而进行的。配置管理倒不是这什么明显，因为它本身就是自成一体的东西。

机构管理类

在这方面有如下几个领域，

• 度量与分折
  
• 过程与产品的质量保证
  
• 机构级过程投入
• 机构级的过程定义
• 机构级的培训
• 集成项目管理
• 决策分折与方案
  

在Agile的实践中在机构上的一些领域中并不是很成熟，但也不是所有的领域，而且也不是象想象那样不成熟。象SCRUM中的Burndown图就是度量与分析的一个实例。过程和产品质量的保证以及机构级的过程定义是通过组织机构高层对于Agile实践的承诺来达到的。现在SCRUM也已经有了一些标准的培训认证。

技术管理类

在这方面有这几个实践领域，

• 需求开发
• 技术方案
• 产品集成
• 查证
• 确认

在SCRUM里，需求开发的结果就是产品Backlog。技术方案讲的是如何设计，开发和实现需求。这在XP中都有概括，象增量设计，测试驱动开发（TDD）。产品集成在XP中有持续集成的概念。查证在XP中有结队编程。在SCRUM中，确认是一个经常性的活动，在每个Sprint之后都会进行。

总结

可见其实CMMI的各个领域是可以放在Agile的框架之下的。也就是说，在Agile的某种方法（比如SCRUM）内，CMMI的原则都基本适用。人们可以想象在SCRUM的框架内去实践CMMI，从而既享受了敏捷的好处，又达到了业介所要求的各种最佳实践，可谓一举两得。

敏捷项目中的团队管理

当我管理一个开发团队的时候，其中一个头痛的问题就是如何度量团队中个人的表现，以便在年底公司正式的Performance Review时能够公平地对员工作出评价，这对公司，经理和员工都是一个很实际的问题，与员工的经济与职业前途都密切相关。

虽说软件开发是属于创造性的行业，但其中还是有不少体力活的成分在里面，不是人人都那么争先恐后地去干的。于是我们挖空心思地去找一些可测量的参数用以衡量这个劳动强度，但可找到的不多，能找出来的有点也很难量化。比如，各程序员解决Defects的个数。在实践中，如果你的团队中有一个人能持之以恒地解决比其他人多的Defects，你心里知道他的表现是最好的，你也很愿意年终评定时给他高奖金和升工资，但作为一种机制，你不能够很科学地说Defects的个数是一个绝对的参数，也就是，你不能在年初就跟你的下属员工说，你们中解决Defects最多的人就是最好的，到年底肯定会升职长工资。最简单的理由就是Defect的复杂程度各有不同，很难将其归一化。

其实用什么参数才是最好可能并没有一个肯定的答案。选择和判断最佳表现其实也是一个“可能性的艺术”，是在动态中根据情况决定的。因此，在敏捷 实践中，对员工的评价也应该是化整为零，在每个Sprint中对员工的表现作出评价，以各个领域内积分的形式，使员工自己知道自己的客观表现。如果认为这些参数不能充分反应，员工也有机会及时向领导反映，而做领导的，也可以马上根据实际情况对记分进行加权修改，在第一时间解决问题，而不是留到年底再来慢慢回忆。

Hello, World!

Finally, I am showing up...