数据库GUI显示一条结果为“Female”，可是当用“Female”去查询它所在行时，却怎样都得不到结果，原来虽然界面显示是“Female”，但实际上是“Female ” （最后有个空格）。要判断数据是否完好，得需要做额外的工作。比如在此例中可以用concat(’a', concat(field, ‘a’))来判断前后是不是夹杂了空格。

太相信界面上所显示的东西，往往会花很多时间在一些莫名其妙的问题上，debug到最后才发现，原来是一些bug在捣蛋。

1. 《Doomsday》

情节还是老套，不过那写独特的场景引诱我最终把它看完。围墙内未受死神病毒感染的城市是高科技的代表。而围墙之外，在已被病毒蹂躏过的地方，那些最后生存下来的人们，却有着两种生活（影片里只列出两种，我想可以更多），一种像中世纪一样的城堡，钢盔战士，堡主，城堡中的人民喜欢看肉搏；而另一派则是彻底的朋克，他们驾驶的轿车或跑车都很有型，穿着很能诠释他们的心态，还有那一句很彪悍的话“If you are hungry, try a piece of your friend”，那里聚餐吃人肉的。

2. 《Starship Troopers 3 Marauder》

这是星河战队第三部，凭着对它第一部的良好印象，也坚持把它看完了。高中时候看的第一部，很是着迷，用教育网看了好几遍。机枪，虫族，很炫的高科技画面，还有英雄Rico，足以让一个热血少年为之疯狂。回忆完毕，回到刚出来的这部，感觉有些像七龙珠，第一部抓了一只大虫子，说是虫族的首脑，这第三部又出了一只更大的虫子Boss，这哥们已经和某一星球紧密的结合在了一起，而且通过前面被抓到地球上的那只大虫子与人类交流，最终还是有勾引到一位明星的，很不简单，点点点。

3. 《The Bank Job》

最后说一部还蛮不错的。根据真实故事改编，看得出像真实故事，因为没有伯恩那么酷，里面有些场景很傻很生活，而且里面描述的各种利害关系跟社会紧密结合。Jason Statham演的角色叫Terry，既是这场抢劫案的受益者也是受害者。不过他够聪明，最后把各帮各派都搞定了，算是完美，有些遗憾的是一起抢劫的好几个兄弟都死了。

处理XML的过程中，有些Parser会strip掉空格，比如
输入是<a> </a>，而输出则有可能变为<a/>

这种“潜移默化”的转变有时候只发生在表示层，就是显示的XML文件和实际的数据不一致，比如IE就会帮我们做这种事情…
今天算是学乖了，比较稳妥的做法就是处理数据的时候都strip()或者trim()一下，安全第一…这种由于数据来源不稳定而要用更额外的方法来确保鲁棒性的做法实在是很值得商讨。其实有好也有坏。想在不影响性能的前提下，还是做一下吧，至少自己安心。

总结一下，就是不要相信所看见的所听见的…不一定是真的…

写了个test case，主要是匹配两个文档是否相同的，在我机子(Windows)上跑一点问题都没有，想本来也就很简单明了的东东，没过多纠结，直接传到服务器(Linux)上。结果，在服务器上，这个test case老是不过。一开始以为是Windows和Linux之间格式的问题，用UltraEdit转换成Unix格式后再传到服务器上，还是不行。

只好跑到Ant对test case生成的文件夹下看标准输出，这才恍然大悟，两个文档中有个字段是时间类型，而这个类型是和时区相关的，我给的文档是GMT+8的，而服务器在GMT，所以就在这个字段上，怎么样都匹配不起来。想想这种问题可以放到Programming Pearls里面做书后习题了。

思维定势来改Bug，害人不浅。

副标题是，我个人不推荐，Jboss的开发人员在文档中也不推荐。Java在rule文件里应该是写Utility用的。

本文不谈rule的大方向，什么将逻辑从Java代码里分离出来，利用更加方便的语言来描述规则等等。

写rule最立竿见影的效果就是将Java里面讨厌的一长串if-else语句用比较简洁的rule语言表示。

如果在rule文件里用Java实现业务逻辑，那用rule engine又有什么意义呢？
Java可以直接在JVM上跑，没必要用rule engine来做Proxy。而且，Java函数对rule engine来说是难以优化的，官网上说无法对其做索引，当滥用eval操作去调用Java函数时，rule engine的性能会受到很大的影响。Rule文件里就应该写纯粹的rule语法，要用Java实现业务逻辑的话，就把Java放到Java文件里；不然就变成了四不像，既没有很好的利用rule engine的优化功能，又丧失了在项目中使用rule engine的意义。

Java在rule文件中就是写Utility的，打印下log啊，对变量做下处理什么的，而不是用来判断逻辑的。其实更好的方法是rule文件中一点Java函数的身影都不要用，专门搞一个Utility的类给rule文件用。两全其美，相得益彰，看的也爽。各种语言各个项目各施其职，社会才会和谐嘛！

1. 《Marriage is a crazy thing》

很久没有看韩剧了，偶尔看一下，还是蛮感人的。严正花真不错，可是看完一查，哇塞，原来是71年生的美女~~

2. 《A soldier’s girl》

讲述的是一个真实故事，或许这辈子很多人，很多很多人，都无法有这样的感受。这个爱情故事的结局是可悲的，但是也有可喜的一面，毕竟女主角最后过得还不错。但愿世上真心相爱的男男女女都能终成眷属。

3. 《Wall Street》

华尔街黑幕，干，其实就是一帮有钱有势的人联合起来赚钱的故事。到最后某人良心发现，把整个内幕暴给相关法律部门。也是根据真实人物改编的，感觉还不错，蛮新奇的。里面的坏人说：“The most valuable commodity is information”…

1. 《Hitman》

觉得比较值得看的就只有《Hitman》(杀手47)，杀人酷的决不失手，干净利落；解决问题冷静有条理；对女人则铁汉柔情。很喜欢看这类型的片子，包括最早最经典的《The Professional》（这个杀手不太冷），还有比较近的整部片都很紧张的伯恩三部曲。《Hitman》是由游戏改编而来的，情节设计得很紧凑，不知是不是和游戏里面的情节一样，不过现在是没时间玩游戏了。

2. 《10,000 BC》

如果还有时间的话，不妨看看《10,000 BC》(史前一万年)。主要是一万年前人们生活的场景吸引了我，还有制作得不错的怪兽。若是论情节，也就只是一部英雄救美女的片子。不过我觉得这是值得的，因为美女很美，一点都不像历史课本上公元一万年前人们该有的脸庞。顺便还学了一句古语“Yahala”，就是“We must bring them down”的意思。说不定可以作为下个项目的代号。

在五一放假前和Mike讨论到这个问题，之前我用了比较多的call-template，后来说着说着，突然发现apply-templates在大部分的场景下比call-template好用，也更安全一些。

比如，apply-templates可以通过select属性来选择具体要匹配的node-set，如果不存在这样的node-set，就不进行转换，这就比call-template安全了一些，因为后者是直接调用，不管存不存在某些节点；其次，apply-templates和call-template一样，可以通过<xsl:param/>接受参数；此外，当我们定义多个template时，这些templates不可以有重复的name，但可以有重复的match，重复的template通过priority来确定该用哪个template来进行转换，如果多个template有相同的priority的话，则选择最后出现的那个。

似乎apply-templates功能比call-template强。就目前我所用到的普通转换来说，用apply-templates是比较安全的，并且可读性也会高一些。但是在XSLT 1.0中，如果想要实现像XSLT 2.0中function一样的功能的话，用call-template就比较方便了，比如递归调用（Recursive function）。下面是一个例子：

<xsl:template name=”longest-speech” as=”element(SPEECH)?”>
<xsl:param name=”list” as=”element(SPEECH)*”/>
<xsl:choose>
<xsl:when test=”$list”>
<xsl:variable name=”first” select=”count($list[1]/LINE)” as=”xs:integer”/>
<xsl:variable name=”longest-of-rest” as=”element(SPEECH)?”>
<xsl:call-template name=”longest-speech”>
<xsl:with-param name=”list” select=”$list[position()!=1]“/>
</xsl:call-template>
</xsl:variable>
<xsl:choose>
<xsl:when test=”$first gt count($longest-of-rest/LINE)”>
<xsl:value-of select=”$list[1]“/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select=”$longest-of-rest”/>
</xsl:otherwise>
</xsl:choose>
</xsl:when>
</xsl:choose>
</xsl:template>

<xsl:template match=”/”>
<longest-speech>
<xsl:call-template name=”longest-speech”>
<xsl:with-param name=”list” select=”//SPEECH”/>
</xsl:call-template>
</longest-speech>
</xsl:template>

待转换的xml是：

<?xml version=”1.0″?>
<SCENE><TITLE>SCENE I. Venice. A street.</TITLE>
<STAGEDIR>Enter RODERIGO and IAGO</STAGEDIR>

<SPEECH>
<SPEAKER>RODERIGO</SPEAKER>
<LINE>Tush! never tell me; I take it much unkindly</LINE>
<LINE>That thou, Iago, who hast had my purse</LINE>
<LINE>As if the strings were thine, shouldst know of this.</LINE>
</SPEECH>

<SPEECH>
<SPEAKER>IAGO</SPEAKER>
<LINE>’Sblood, but you will not hear me:</LINE>
<LINE>If ever I did dream of such a matter, Abhor me.</LINE>
</SPEECH>
etc.
</SCENE>

在关于使用call-template和apply-templates的性能差别上，Sam Judson (Wrox 技术编辑)有言：

In terms of raw performance xsl:call-template is likely to be faster, as you are calling a specific named template, rather than telling the XSLT processor to pick the template which best matches.

There are certainly things you can do with xsl:call-template that you can’t do with xsl:apply-templates, such as recursive templates which are very powerful.

xsl:apply-templates is however the more flexible and extensible, due to its combined use of the match patterns, modes and priorities.

我觉得概括的不错，言简意赅，就以此作为结尾吧。

1. 《Golden Compass》(黄金罗盘)

虽然imdb分数不高，但是我蛮喜欢这样的情节，特别是西方的一些魔幻方面的内容，更加吸引我。其中比较有特色的是富有战斗力的Ice Bear和最后令我震撼的Witch部队，如果我们的世界也能如此丰富多彩，那该有多好。

2. 《I am legend》(我是传奇)

悲剧。说人类最终会自食其果，确实是。在想最终被电脑给灭也比被病毒灭了的好。虫族，兽族等不堪暴雪禁锢多年，冲出电脑，走向社会。

P.S. 《Sin City 2》又跳票了，不会真要等到09年吧。

 译者序：在做系主页时遇到了这个问题，原作者说明了几种解决方法，觉得很不错，遂译之。
《IE CSS bugs when using floats and background-color》

如果一个div设置了background-color并且包含了具有float属性的元素（包括利用css的“float”属性或HTML中图片的“align”属性)，IE浏览器就会解析错误——我IE6里一些样例页面的截图，对比它应该显现的页面。

IE6有时候会隐藏div里的部分或全部元素（样例2和5的标题不见了）；此外，在IE5和6中，如果容器被设定了属性position: relative, 则浮动的元素即会消失（参看样例4）。与其他文章不同的是，无需任何类型的间隔div就可以引发这个bug——这里所提及的例子中就没有用到任何相关的。操纵滚动条，往下滑会使丢失的内容被隐藏起来，再往上滚动的时候，丢失的内容就会显现出来，问题就解决了，但这不是一个可行的方法。

其他站点也注意到了这个问题，包括evolt.org和Position Is Everything (the Peekaboo bug，链接中包含有更多的好玩的加法bug的动作 )，然后他们的解决方法是给不同的元素添加上属性position: relative；不管是那些消失的元素(evolt.org)， 还是div容器以及包含在期内的所有浮动的元素(Position Is Everything)。这个不是直接的方法，因为你必须给所有可能的元素添加上position属性，并且不幸的是它又引发了另一个position:relative的bug，特别是Mac里的IE5。

Position is Everything 与 evolt.org上的评论中还提到了另一个解决方法，那就是给div容器设定一个宽度，这在一定程度上能解决问题，但当该div有边框(border)与外补丁(margin)，这个方法就不可能实现。

我的解决方法就比较简单：给那个div容器设定line-height属性。浏览器默认的行高(line height)好像是介于1.1-1.2之间，所以设置行高，使之在界面上不产生太大的变化，并能解决IE的bug。

为了说明问题和解决方法，对于IE6 和 Firebird 0.6.1，我已经提供了六个样例（来源于evolt.org），还有一些页面的截图。