最近增加的关键字功能可能会对JR系统的整体性能造成比较大的伤害，原因就是JR的系统中最值得称道的缓存功能的限制。
按照原来的情况，JR的缓存系统在90％的情况下会工作得很好，这个和系统的特点有关。
JR的用户，很多是按照我们的页面给出的顺序查看我们的内容，当然也有一些是通过各种搜索引擎搜索得到某个内容，但是按照比例而言，按照顺序浏览的可能比较多，因此大部分的人查看的内容都在缓存中，不在缓存中的内容会再到数据库取，因此系统的效率比较高。
而在增加了关键字功能后，关键字相关的文章列表中的内容很可能不在我们的缓存中，因此要把文章相关的内容都从数据库中取出来，这个时候缓存的功能就没有发挥应用的作用甚至成为了负担，因为缓存的内容的频繁交换在这种情况下做了很多无用功。

其实这个问题并非不能解决，甚至可以增加各种排序功能（按照目前的情况增加排序功能对系统的损害是致命的），方法就是改造缓存系统，将目前的单级缓存修改为多级缓存。
按照jive的缓存设计，每个被缓存的对象需要提供一个大小信息，而缓存管理器会维持一个大小受限的缓存池，如果采用二级缓存，内容的主要信息缓存下来（例如标题，作者，发布日期，回复数，最后更新日期，查看数，最后回复者等等），
而帖子的内容一级回复作为二级缓存的内容，按照一定的比例分配一级缓存和二级缓存的大小，而系统中经常查看的可能是内容列表而非内容，这样
缓存的功能就可以大大增加，即使把全部的帖子信息都缓存下来也是可能的，因为这个信息相对帖子的内容而言很小。
这个改造的难点在于缓存是系统的一个非常核心的功能，缓存相关的代码可能比较多，进行重构并不容易，当然应该是值得研究下的。

目前JR的关键字功能比较简单，一个关键字实际上由并列的几个关键字构成，例如ioc，di以及控制反转都是作为同样的关键字对待的，每篇文章包含的每个
关键字都是有权重的，权重的算法目前也非常的简单，如果是标题中包含关键字，那么权重是出现的次数X关键字的长度X5，如果正文中包含关键字，那么权重是
出现的次数X关键字的长度，如果标题中包含某个关键字，那么正文中的同一关键字的权重将再乘以2，目前看，对于单一关键字这个权重的结果还是比较好的，基
本上能够反映出所有文章中和关键字的匹配程度。对于英文的单词，目前是全词匹配的，否则误判很高，例如di这个关键字，很多单词都包含这个字母序列，而我
们在判断是否包含关键字的时候都是转换为小写进行处理的。

目前正在开发中的是文章相关性功能，初步的设想是从原文章中取出其权重最高的五个关键字，然后看看其它的包含这些关键字的文章，其权重的和最高的就认为是
最相关的，目前看结果不是很理想，可能对于原文章中的关键字的权重大小不同对目前文章的关键字的权重进行相应的处理后得到的才能是比较好的结果。但是这个
也需要检验。

今天看了一下JR在google的page rank，就拿JR的首页来说，可以用很多个URL访问到，但是对于同一个页面他给出的page rank值是不同的，也许我太苛刻了？
下面是不同的URL的page rank的值：

• http://www.javaresearch.org/：5
• http://www.javaresearch.org/index.jsp：4
• http://javaresearch.org/：3
• http://javaresearch.org/index.jsp：2

用过Linux的人可能都很喜欢使用TAB键自动补齐文件名的功能，但是在DOS下怎么办呢？其实对于WIN2K系统是可以的（其它的没有试过，你可以自己试试），方法如下：
在运行中输入regedit打开注册表编辑器，修改HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor下面的PathCompletionChar的值为9，退出就可以生效了。

一直一来都在思索为什么很多公司开发的产品都不好维护，也一直在思考如何设计一个可以快速开发和快速上手的框架，并且用该框架开发的东西要易于维护。
前几天在思考spring的IoC其实也并不是很好的解决方案，虽然他将类之间的依赖关系延迟到了运行时，做到了降低系统的偶合度，但是同时意味着对于一
个新人而言，它在理解这个系统的时候会存在很多问题，特别是系统的设计文档缺失或者不完善的情况下。国内的程序员似乎都不太喜欢写文档，有时候也认为代码
很简单，根本不需要文档，甚至很多连代码注释都没有，在这样的情况你如何希望别人可以很快入手呢？
前两天在改造我的JDBCTemplate的过程中，在完成数据的持久化时，突然想到与其基于配置，不如基于规则，符合规则的就可以通过，不符合的就不
行，例如从数据库取出的数据可以自动映射到javabean，数据库的命名使用下划线分隔，而转换到java的属性就是以下划线分隔的单词，除了第一个单
词外的其它的首字母大写，而对于表间关系，可以也按照命名规范来，对于一对多的关系，可以利用JDK5中的新的特性声明其类型完成。
在基于规则的情况下，配置会减少很多，但是文档依然是不可缺少的，不同的是文档要描述的主要是规则，而这个规则是框架的规则，新人需要研读的就是这个规则，他也不能写出不符合规则的程序，因为那样就不能工作。
有必要实际的检验一下这个想法。