在Tom上，我被打到12k后，下了八盘，赢了七盘，看来我的水平是长进了。看多了，有些东西就明白了。其实，世界上的事情就是这样。记得学过的一篇古文吧，“为学”。天下事有难易乎？没有，都是不难也不易，象卖油翁的说法，“手熟尔”。因此我从来不相信什么神话，我只知道接触多了以后就熟悉了，熟悉以后，你才能理解，理解之后你才能超越。因此学东西的时候，最好先记住。这是最好的方式，非但不是愚蠢，而是朴实的，有效的。以前我只注重理解，而现在我开始注重记忆，因为不记住是不行的。记住后，才能拿过来就用；记住后，才能时时回味；记住后，才谈得上积累。记住是为了忘记，是为了信手一挥，不用想，不用算的潇洒，自由。
围棋是精确的，有点像数学，大方面看上去模糊，但是，每一步都精确无比，不能有一路的误差，失之毫厘，缪以千里。有一盘棋，我的最大的一条大龙都被杀掉了，但是我还是赢了，而且赢了很多。因为对手太差了，倒不是我多高明。
下棋是一个从模糊到清楚的事情；做软件也是；谈恋爱也是；人生也是。下棋的时候，先总体有个大概的想法，是乱战还是围大模样，总得有个构思；做软件是要先有创意，之后在逐渐细分；谈恋爱更是如此，从开始模糊，到后来尘埃落定，更是从模糊到定性的过程。正所谓无名万物之始，有名万物之母。
我不喜欢有人把写代码看做挺高尚的事情。我认为做写程序和做饭差不多，没什么神奇的，都是普通的事情，没有必要高尚化，而所谓的痴迷则更加夸张。如果说以前我还不能算是太懂的化，那么现在我至少算是大部分都知道了，说实话我不喜欢没有创意的软件，比如某些网站，我实在是不愿意浪费时间在这种无意义的工作上。
我是喜欢java的风格的，我最讨厌的是c++，简直是太糟糕了。c已经够惨了，象c++这样的东西，简直让人受不了。groovy是个好主意，可是我希望有一本书才好，否则我是受不了只看电子材料的。
少则得，多则惑。现在我只用两个框架sturts，hibernate，偶尔看看spring,我觉得学了这些之后，就足够了。不要再学什么ejb3了，因为这些东西组合起来已经很强大了，完全可以承担大型应用的需要。因为spring 有一些新鲜的思想，所以应该学习一下，但是不必太着急，在学习struts和hibernate的时候偶尔看看就行了。
Ioc并非新鲜的概念，因为它和动态载入是同意的，其中组合了java的接口转换。但是aop就不得不好好注意一下了。我们可以把它想象成一种callback，只是这种调用覆盖面更广。有了一种普遍推广的意味。这种截取对于安全控制来说实在是太好了。spring已经有了一个安全框架acgie（也许拼错了）。应该抽时间好好学学。还有一个就是事务，spring 也有方案。如此，灵活明确的控制，比学习ejb清楚多了，spring才是程序员应该理解使用的东西。
因此spring才是核心，hibernate and struts都是辅助。再想想是，灵活简洁的结构才是核心。
再说一下struts，我看到好多抱怨，我其实也有抱怨。但是，struts的优点是非常的明确，正如我们的抱怨一样，有针对性。struts提供了灵活的控制层，这是web层最最需要的，也是我们使用struts的主要理由。要求完美的东西是过分的，因此，struts还是当前web层的最好选择。
再说一下ActionForm，我觉得永远也不要直接使用ActionForm作为业务层使用的Bean，因为ActionForm仅仅是个运输工具，装的一堆东西可能是打包的，也可能是散乱的。因此，必须有一个拆分和打包ActionForm的环节，处理ActionForm，这也正是struts的重大缺点（我认为这是最大的问题）。由于要处理ActionForm，使得我们分层时有点困难，也增加了一点多余的麻烦。
Validator是个好想法，用了一下觉得很方便，不错。
还有一个问题就是中间层的问题。主要的业务逻辑放在哪里呢？我们是用singlten，我并不觉得多好，但是基本解决了问题。我现在疑惑的是有没有更好的方法？（如果那位知道请告诉我）
还有一点就是struts的标签库，我实在是不太欣赏。因为它明显要比jstl的设计要差一些。它有点麻烦，不够清楚，犯了大忌。但是用struts又不得不用它的某些标签库，实在是让人很烦。