大纲：
- 使用开源代码能提高你的google搜索的能力和英文能力
最近又做了一个商务类型的项目，我们使用了很多的开源的项目的代码，他们不约而同的出了一些问题，让我到处救火，google了无数的页面，这个过程中发现搜索能力和英文阅读能力。
首先遇到问题的是sitemesh，在tomcat下面一点问题都没有，但是一转到websphere下面后就发现首页出错了，而且是使用http://www.mydomain.com/这种方式出错，但是如果访问http://www.mydomain.com/welcome.do的方式就没有错，开始想过很多的解决方法，最后我们的一个同事点醒了我干脆把首页那种默认的方式取消，就直接访问welcome.do这样就解决了，看来还是我太死板了。
然后遇到问题的是我们的jasperReports这个开源的报表工具，在windows下面一点问题都没有，然后一移到aix的websphere里面，这不问题又来了，然后我就google了一天，没有头绪，都郁闷坏了，看上去没有问题的都用不上，而且我们用的ibm的jdk，解决方案是sun的jdk的，晕倒，最后用了一个最傻的方法，在aix的图形用户界面下面运行webphere，这样报表就出来了，都是xserver惹的祸，害我这两天都编程了aix的系统管理员了在命令行下面搞了无数次，再晕。
Django最近搞了一下，还是比较有收获的，准备用来开发一下原型，顺便试试用它来直接开发一些轻量的应用试试，就是上次的提到的利用搜索引擎方式的销售平台也可以用这个平台来搭建试试，脚本语言还是有无限可能的。
ajax其实也就是学习了一个javascript的库叫做mochikit，它以python的方式来写javascript，挺合我口味的。我们在项目里面用最多也就是在一些时间比较常的地方用用，提高一下用户体验。
最后要说的是最近的一个小心得，是关于“小马过河”故事的，以前做选择往往都是随大流，看多数人使用什么我就选择什么，如果这样的话那么最近应该选择的脚本语言是ruby，web框架应该是ror，但是最后我选择了python、Django，一个是因为我的知识积累主要在python，而且另外一个是python的语法我比较喜欢，Django是因为需要一个快速开发的平台，因为国内有limodou在推动，我就乐得其成了。
选择是一个客观＋主观的过程，是一个比较个人化的事情，如果有人拼命向你推荐什么东西你一定要提高警惕，不要忘记历史啊，尤其是我国这种全民狂热的历史。
文章来源:
http://blog.donews.com/crabhn/archive/2006/04/25/845988.aspx
昨天和Aero同学（现在他不叫kevin了：）讨论了关于企业知识管理的问题。我也提出了自己的一些观点，这里作一个记录：
1、系统的基础blog、wiki、网摘、书评收藏（豆瓣）
2、系统的输入就是这些系统里面的内容
3、系统的输出分三类：
一个是对于自己，希望梳理自己的知识体系。
那么输出中要体现个人的进步，也就是需要评估文章的价值，这里我提到可以利用各种条件给内容打分，blog可以以浏览的人数，回复的条数，链接的个数，也许是在alexa里面的排名，或者就简单的使用在bsp这个系统里面的打分机制。wiki就是个人的修改的保留程度以及对内容的贡献度。网摘也可以使用网摘自带的排名功能。至于豆瓣嘛还是自带的排名机制。这样看来我们系统只需要维护自己的blog和wiki，而且根据Aero已经实现的方式blog可以同时和wiki互通，可以在发表blog的同时把文章发到wiki里面去，Aero觉得这个应该是一个选择的方式，我觉得这里可以作成强制的，blog的文章一定会根据你选择的标签被聚类发表到相应的wiki模块里面去，这样就可以很方便的结合wiki和blog的优点，而且也符合用户的使用方式，毕竟多数人不会主动的给wiki贡献内容，而blog的方式更容易让大家接受。
另外是需要对知识进行分类，这里Aero提出使用tag的方式，我觉得tag还是有点随意，最好是在tag的基础上进一步作文本聚类。这样就可以在系统里面看到个人的进步，以及自己的知识体系。
二是对于别人，能够在系统中得到你的整理得很好的一个知识体系的文集，也许就是一本质量很高的书籍，可以很容易得学习到你的知识。
三对于企业，能够把所有人的知识体系汇总，能够进一步形成企业知识的沉淀，而且管理层可以很容易的通过这个系统的输出来分析企业员工的各种关注点，辅助管理工作。
我想还有很多东西没有好好考虑到，也许需要把时间管理和工作日志管理也加到这个系统里面：）
文章来源:
http://blog.donews.com/crabhn/archive/2006/03/07/755905.aspx
IOC容器大家都经常用了，但是不知道有没有人注意到在web层我们也可以使用很好的“IOC容器”，就是可爱的sitemesh了，在使用sitemesh之前我们都是直接使用include来包装页面，把一个普通的页面include head.jsp menu.jsp footer.jsp这样就组装好了一个页面，但是这里这三个文件就和所有的这些使用他们的jsp硬编码放在一起了，这就像我们在系统里面用new来生成一个instance，这样页面也一样造成了很高的耦合度。这样在页面级别如果出现需要更改就非常的麻烦了，比如客户说你这个页脚我不想要这个，需要另外一个，或者菜单不放在左边，我要放到右边去了，这样你就晕倒了，由于include到处都是，你要一个个找出来修改，也许你会说可以把它们变成空的文件就可以，当然可以，但是这毕竟不是最好的解决方式。
这时候你就可以看看sitemesh了，他和spring一样，在配置文件里面配置页面之间的关系，比如很多的前台页面都需要一个页头，一个菜单，一个页脚，那么你就可以作一个页面的模板，包括这些元素，但是在需要插入的地方作一个插入占位标签，这样sitemesh就会把被修饰的页面的body部分抽取出来无缝地插入到页面模板里面去。sitemesh理解html，这样它就可以抽取指定的标签到模板相应位置，比如title，比如body里面的onload事件还有head里面的javascript代码。你不用担心它会插错位置。
这样你就可以独立的进行页面的编写，每个页面只需要维护它自己的功能，至于它需要和哪些页面来组合一概不知，这样就把页面级别的耦合全部去除，非常符合DRY（Don't Repeat Youself）原则。
如果sitemesh+web标准的css和无table的方式来设计页面，就可以完完全全做到页面的干干净净，而且显示和内容完全分开，对于直接接触到jsp源码的程序员是一种享受了：）
文章来源:
http://blog.donews.com/crabhn/archive/2006/03/02/750132.aspx
我们在作订单提交的时候需要作一个嵌套着对象和对象数组的form，例如:
class OrderForm extent ActionForm
{
Contract contract;
Consumer[] consumers;
...
...
}
然后在html form里面用点属性的方式来进行提交：
<form ...>
<input name="contract.name"/>
...
<input name="consumers[0].name"/>
...
<input name="consumers[1].name"/>
...
</form>
我想当然这样就可以提交过去了，因为以前我们有类似的代码，我也没有去看文档（不过我去找了文档也没有看到，估计需要看源代码：），但是提交失败了，页面完全出不来，而且代码都没有运行到Action里面去，说明struts在装载Form的时候就出了Exception。我研究了一个天都没有搞清楚，如果换成String数组的方式又太不直观，这时候就郁闷了。
不过昨天睡觉前我又理了一下思路，想起自己可能是没有初始化变量出错了。Struts往没有初始化过的变量里面set当然会有exception。：）
所以今天早上我就把Form改了一下：
class OrderForm extent ActionForm
{
Contract contract = new Contract();
Consumer[] consumers;
...
...
}
而consumers在Action里面初始化，把它根据需要初始化足够的Consumer。
但是，最后发现还是出不来页面。
这次也很直接，在xml配置里面把form的scope从request改成session，就ok了。
但是，struts还是没有搞得太清楚。最近听说struts和webwork合并了，作了一个Struts Ti，而且基于webwork2得核心，看来可以直接去看看webwork的文档，看看什么时候有机会把它引入我们的项目里面来。
文章来源:
http://blog.donews.com/crabhn/archive/2006/03/01/748078.aspx
在企业开发过程中最头痛的就是DA层（Data Access）的开发了，关系数据库这个冬冬最讨人嫌了，我就因为讨厌关系数据库，大学有一段时间很讨厌写web程序。
这些问题主要都是因为以前都是直接用Sql和数据库打交道，每次web项目一把以上的时间花在了DA层了。工作后接触的第一种DA技术是Spring support的DAO编写，这样就可以减少了很多的代码，而且我还写了一个代码生成器来自动生成代码，这样开发速度就上来了，但是就算是这样我们还是很烦恼，因为单表的操作是简单了，但是多表的操作也是很烦恼，我们是用java代码建立了一个DBManger层专门用来组装多表的，当然很多人都是用sql进行多表的拼装，这样运行效率高，但是我们当时是选择了开发效率，所以多表都是在DBManager层用java代码组装的，没有利用数据库的特性，这样增加了web服务器的负担。而且在做查询的时候特别苦恼，每次都是把整个List全部给load出来了，这样更加耗费内存了。比如我们的订单列表的功能现在还没有多少个订单的时候都慢得不行了，一个是因为我们每次都load所有的Order对象，二是把Order对象的子对象也全部都Load出来了，本来用户只是想看其中几个订单而已，而且我们也没有做缓存，总之我们原来项目里面的DA层真的是问题重重。
这两天把Hibernate引入了我们现在新的项目中来了，开心啊，开心，给我们带来了解决上述问题的曙光：
1、在开发效率上面，我们现在所有的工作就是建立数据表，根据数据表生成hbm.xml的表对应Java bean的映射，以及生成java代码。而DAO只是需要一行代码。多表的联合也是定义在hbm.xml中的，整个过程看不到一行sql语句，开心。这样我们体系结构里面的DBManager就没有存在的必要了。而且DAO也只是需要做一个DAO，现在我们就只有Order的DAO了，所有的操作都在这里进行。
2、运行效率上，首先利用了延时加载，数据如果不用就不load出来，这样我们的Web服务器就没有那么大的负担了，然后就是多表的操作自动生成多表联合的Sql充分利用数据库的特性，这样也是减少web的负担。
接着最重要的问题就是在做订单列表的时候，这里真的要好好赞扬一下HQL，这个Hibernate的查询语言，用完全面向对象的方式解决了我们所有的问题：
a、分页问题：这里我们可以使用Query接口的来限制每次从第几个开始最多获取多少个数据，这样就可以按页获取数据，而且可以利用sum来得到数据的总量，这样分页功能就可以很容易实现了。根据我的试验，速度比原来快了一倍以上，而且原来根据数据量的增长还是线性下降的，而现在保持比较平稳的速度。
b、构造小对象的问题：这个问题来自于订单列表的时候只是需要几个简单的字段，而不需要整个order，这个问题可以通过在HQL的select语句中利用new语句来构造一个小的order对象，这样进一步节省了web服务器的内存：）
c、联合表查询：比如需要根据联系人信息查order，而联系人是order的一个子表，这个时候可以利用HQL很直观的写出这样的查询:eg：select new SmallOrder(order.a,order.b,order.c) from Order as order where order.contact.name='crab'（结合了b问题）这样我们根本就不需要担心客户的bt要求，他想怎么查询订单我都可以很容易的给他加上查询条件。
最后就是我们的产品模块，原来为了能够最大限度的扩展，利用了万能表的方式，这样什么产品都可以定义出来，但是这样的设计不利于做报表和查询，现在可以利用Hibernate重新设计产品模块，也可以很方便的万能化，但是查询和报表就可以很方便了。
总之，Hibernate给我们项目带来了真真实实的好处，从开发效率和运行效率上都是，特别是可以使用面向对象的方式去操作数据库，这样可以很面向对象地写企业程序，可以带来开发时候真实地快乐：）
还有一个最大的体会是Hibernate很少违反我的直觉，很多时候我只是觉得这个特性Hibernate应该支持，然后就试验，然后就成功了，根本不需要去看文档，这个和Python的“最少惊奇”原则妙曲同工。
文章来源:
http://blog.donews.com/crabhn/archive/2006/02/24/739825.aspx
昨天下午做了一个变更，变更了一个jsp页面，但是页面的修改不能体现出来，不过这个页面比较特殊，是a.jsp include b.jsp，我们修改了b.jsp，但是在websphere上面死活显示不出来我的修改，看来websphere判断了a.jsp的修改日期，没有判断b.jsp的修改日期，下午试着清空了jsp的缓存区，可是没有用，今天记起来jsp页面是要编译成servlet的，所以清空了全部的缓存，终于修改成功了：）
文章来源:
http://blog.donews.com/crabhn/archive/2006/02/22/737143.aspx