2006年6月26日
#
摘要: 这些天一直在为Flex程序中的各个组件之间有效的传递参数，协调组件间的行为等问题感到困惑。由于Flex程序实际上是一个运行在客户机上的的客户端程序，因此在Flex内部组件之间无法像B/S程序基于HTTP协议那样发一个请求，由服务器端通过一个标准接口读出参数，处理并做出响应。也就是说用表单、URL的方式传递参数和控制流程肯定是行不通的。前一段时间一直尝试像Javascript中那样用函数调用，甚至是全局变量来做，感觉越做越复杂，程序的OO结构也受到很大的破坏，十分的烦恼。
阅读全文
摘要: 要没用过E4X，就不知道用这东西处理XML是多简单好用！过去在Java中一直是用一些用熟了的组件操作XML，这几天用Actionscript才发现了这个好东西，真是相见恨晚啊，一定要和大家分享一下。
阅读全文
摘要: RIA会有将来会成为互联网的主流么？这是一个只有一个答案的问题，那就是“会”。不需要去纠缠那些技术细节，你至少可以相信HTML及其派生出来那些技术不能让对体验效果的追求永无止境、又十分挑剔的我们满意，那么能带给我们耳目一新的感觉的RIA有什么理由不成为主流？ Microsoft和Adobe已经磨刀霍霍，准备在RIA的时代里挑大梁了，我们可别光坐着看热闹。
阅读全文
摘要: 还在远古刀耕火种的年代，当人类意识到鸟能在天空中飞翔是因为有双翼，我们的先祖便在石头上为自己刻上了翅膀；从庄子的《逍遥游》到今天的《黑客帝国》、《哈里波特》，我们人类都幻想着能把现实生活放入另一个空间，在那个空间里我们能“水击三千里，抟扶摇而上者九万里”。而计算机和互联网的出现，给了我们发挥的想象力的一个理想的平台，
阅读全文
Flex 2.0 安装应要注意的几个小问题
1. 弄清概念
Flex 2.0 实际上是一个产品系列，初学者安装之前应当弄清楚中各个产品的功能和相互之间的联系。 参考Flex官方介绍：http://ww.adobe.com/go/flex，了解Flex 2.0 系列的各个产品特性。
2. 记得要Tomcat加入加入JTA支持
JTA的包一般都是被应用服务器自带，可Tomcat默认却不支持JTA，所以用Flex Enterprise Services 2.0时必须自己手动在Tomcat中安装JTA以获得支持。否则的话运行samples.war肯定会在控制台看到类似下面的错误：
java.lang.NoClassDefFoundError: javax/transaction/SystemException。
如果真是需要使用事务功能，推荐用Java Open Transaction Manager(JOTM) 来提供 UserTransaction。嫌配JOTM麻烦的话可以自己直接拷贝jta**.jar,jdom.jar放到samples/lib下凑合一下，例子的各个功能基本都可以正常运行。
JOTM的安装可以参考网上的一些教程，比如
http://jotm.objectweb.org/current/jotm/doc/howto-tomcat-jotm.html。基本就是下载最新的二进制发行版（http://forge.objectweb.org/projects/jotm/）,解压缩，从lib目录拷贝*.jar文件（除了log4j.jar、common-cli.jar和jotm_iiop_stubs.jar之外）到$TOMCAT_HOME/shared/lib目录下，然后再配置一下server.xml、web.xml即可。
3. 浏览器需要安装支持调试功能的Flash Player插件，否则无法使用 Flex IDE 的调试功能。
支持调试功能的Flash Player可以去官方下载：
http://www.adobe.com/support/flashplayer/downloads.html
在那些名字有debugger字样的里面找需要的吧。
//作者：王玮琳 时间：2007-12-30
//声明：本博客中所有文章均为版主原创，转载请保留作者信息，并请注明出处。
摘要: 我们都知道对于一个有一定规模的项目或者有长远算的产品,仅凭一个和数个能力突出的人的努力付出很难真正做好的。软件开发过程的个人英雄主义往往到最后是限制或者是毁了这个或许本来很有前途的软件，所有人都知道团队的整体能力是多么的重要！然而从现实来看，纵然有无数的管理学和软件开发方法的理论，在现实中打造一个有很强执行力的团队却是那么的困难重重。
阅读全文
//作者:王玮琳 时间：2006-12-12
不知道是不是巧合，今天一早便看到Blogjava有两篇关于AJAX感受的文章。而CSDN上这两天头版最显著的位置也发了一组为MS Expression造势的文章，口风一致又满怀激情的预言AJAX将迅速退场，RIA会迅速成为主流。这些个平日专业写IT文章的技术专家，也是有备而来，打出"Expression 2006最后的论战"的口号，一心在CSDN推起再一个AJAX vs RIA论战的高潮。对这个话题其实我早就憋了一肚子想说的，俺也不喜欢CSDN里那种过于关注趋势的讨论，咱们这主要是能参与一线开发的技术人员，我想在这里一定能更和各位XDJM进行更实际的讨论。小弟先在这浅谈几点陋识，不妥的地方还希望大家指正。
首先是AJAX vs RIA。表面上这是矛盾的焦点，而在我看来是不然。AJAX 技术的核心是XHTML和JavaScript，再加上CSS来做展现，其实是传统开发方式的一个发展，这也是为什么AJAX能这么快的被大家接收和喜欢的原因。从某种意义上来说，AJAX的目的正是要用传统的Web技术来实现RIA！CSDN的专家们把RIA和AJAX对立起来，是一个概念性的失误，只有用基于AXML和MXML这种XML布局的思想来实现的富客户端才是RIA么？ 退一步说，难道基于XHTML布局不是基于XML布局的一种，为什么它不能在RIA中占有一席之地？
回头看看，从XML开始普及的年代开始，就不断有人跳出来宣判HTML的死刑，而事实是直到今天HTML依然是互联网的主流。看看PHP，也有类似的经历。为什么是这样？ 我个人执著的认为这是因为创造Internet内容的不是这些鼓吹新技术的专家，而是广大的网民，是数以千万记的全世界普通的、甚至很多是不入流的半职业的程序员和普通的网民。一方面对于其中的很多人用最小的代价把内容放到网站上，能从网站上得到他们需要的反馈，他们需要传统而基础的HTML（或许将来小学生课堂里就会学HTML网页制作）；另一方面大量的只局限在PHP之类传统开发技术的程序员依然大量活跃在互联网上，这些人还在，互联网的大格局就不会变。只要HTML不会死，AJAX就不会死，至少XHMTL+CSS+JavaScript不会死，不但数年内不会，在很长的时间内都不会。
现在我想亮明一下我的态度：我喜欢AJAX的效果，但不喜欢AJAX的实现方式，我非常赞同CSDN那些人的看法，基于XML布局的RIA将异军突起，“在WPF、Flash（Apollo）等RIA技术的夹攻之下，越来越多的Web应用将同时部署传统Web页面和新的RIA UI。之后此消彼长，几年之内RIA将成为主流。”(摘自孟岩的blog)。
当然，这些用来为MS造势的文章并没有真正客观来介绍RIA技术的现状，一方面我在前面说的AJAX技术并不是站在RIA的对立面，而是恰恰是达到RIA的一种方式；另一方面RIA的持续发展、或是取得突破绝不会是因为Expression的横空出世。这次WPF出来，CSDN的几篇文章都不同程度的认为这是跨时代的大事，或许对.net开发人员是这样，但对于我们Java开发者，很幸运，我们早就可以感受到了他们迟到的震撼和快乐了！
了解事情前因后果的人都知道，RIA发展已久，Expression不过是微软运用一贯的跟风模仿的手段的另一个成果，基本就是把MM的那一套弄到他的平台里去，并不是什么有创造性的发明。在Java领域，我们一直有都是生成SWF的 开源的Laszlo + Javascript 和Adobe的MXML + Actionscript (Flex) 两套基于XML布局的优秀RIA体系，此外还有Sun的基于java的JDNC，加上AJAX来实现RIA，我们有非常丰富的选择。这几种技术都经过了多年的发展日趋完善。尤其是Flex，事实上，半年甚至一年前它推出2.0 beta的时候，CSDN这些专家就有足够的理由像现在这样欢呼雀跃了。而微软，好像在明年二季度才会出Expression的正式的第一版，不折不扣的后来者。
微软来了，作为后来者他毫无疑问会继续用一贯的打压的手段去对付竞争产品，市场洗牌是不可避免的。今年在Laszlo的压力下，Adobe已经在Flex2.0中将原来收费的Flex Data Services改成了有条件的免费使用，现在狼来了，Adobe将来肯定还要有新的拉拢开发人员动作,对我们来说形势大好。RIA的趋势无需辩论，现在的问题是作为一个Java程序员，对于面对众多可选的实现RIA的路，我们该走那一条？
我对Flex进行过一定的学习，和Java良好的集成以及大量的现有的Flash制作人员，我还是比较看好它的。希望深入用过Flex或是其他RIA技术的朋友能出来交流指点啊！
声明：本博客中所有文章均为版主原创，转载请保留作者信息，并注明出处。
//作者: 王玮琳 2006-12-07
近期在一个小项目开发组里进行推行XP，尝试了一段时间。结合过去带项目开发组的经验，说说我对在实际项目开发里应用极限编程方法一些体会，和大家交流。完全是个人理解，也不太成熟，不对的大家来拍。
一 如何看待开发方法
首先说点开发方法本身的理解。我一向认为没有哪个开发方法可以彻底的解决项目开发的各个环节的问题，任何一个开发方法，其中有些理论的东西放到自己的实践中可能就是事倍功半，在实际开发中还是要灵活，要掌握一个应用的度。过去我一直是用RUP的那一套东西，不能说它差，更不能说它好。我觉得RUP也就是给我们组织项目提供了一个参考，我们并没有严格按它的来，比如文档，我就是按国标的要求来写，而不是RUP的；甚至文档的数量、质量方面，对每个项目我们也是灵活处理，比如这个项目组的人擅长文档编写，就要求他们写的详细点，要是项目组整体文档编写能力都不行，就要求写的简略一点，能突出重点就可以了。总之，我觉得实际项目开发的模式应该是慢慢摸索出来的适合自己的方法和模式，不需要严格遵守什么东西，另外就是要根据各方面的发展进行不断的调整。
二 推广XP价值观 极限编程中用来指导开发的五个主要的价值观是：
沟通、简单、反馈、勇气、尊重。我觉得对PM而言需要重点对Team成员强化的价值观是：
沟通、简单和反馈。这三个是实际影响所有工作方式的价值观，应当在任何时间、任何条件下要求大家来理解、实践。
沟 通：在实际开发过程中，通过平时及时的口头沟通来促进团队的了解及合作，开发过程中相关人员尽可能的及时主动报告开发进度、问题，一方面自己要将所做的工作及时的告诉他人，另一方面不要等着在他人进行阶段性的汇报时才了解项目开发情况，要随时询问、关注他人的工作进度，只有大家都了解了项目的真正的进展，才能消除对开发进度的怀疑、忧虑。
应该强调沟通的作用是多方面的，绝不能把沟通理解成去了解他人的工作进度，而是通过沟通来实现工作的简单化，实现较小的反馈周期。至于进度问题，从领导角度来说，应当本着尊重、信任的价值观进行合理的关注。
简 单：开发过程中各项事务性工作应当化繁为简，沟通方式、决策尽可能的简单化；系统实现方案也应当考虑选用简单的实现方式，尽早尽快的达到效果。
反 馈：反馈是沟通的核心部分，应当成为所有开发人员的核心价值观之一。大部分情况下，我们都不可能在开始的时候知道我们最终的系统是什么样的，需要群策群力参与进来，一方面对系统的功能进行改进、提高，一方面对项目开发的沟通组织方面进行改进，提高整体的开发效率。推行反馈的价值观是非常需要技巧的，因为我感觉大部分开发人员并不是不想反馈，而是不知道如何反馈、反馈什么，对此我提出的一个说法就是：一切都可反馈，一起都要反馈！
至于
勇气、尊重则是我认为这两点和人的天生个性有关，要因人而异，有针对性的对Team的部分成员做出具体要求。我个人认为一些XP的书籍强调这两个价值观的前提是不太严谨的，举个小例子，要组里一个弟兄本来就是个勇气过剩，喜欢在项目用高风险的代码的激进分子，我再老和他强调勇气，岂不是要搬起石头砸自己的脚？
三 掌握XP原则 极限编程方法提供了一整套的开发原则，在实际开发过程中，我觉得实践中需要重点遵循的开发原则有：
- 人性化
- 质量第一
- 互相受益
- 从经济角度出发
- 不断提高
- 慢慢走 (Baby steps，很多书翻成婴儿步)
挑两个说说，其中最有感受的是第一条人性化。
人性化是什么？看看国内众多的软件公司，老板大凡都是觉得自己还算对得起员工；PM总觉得自己比手下人更难更辛苦；干活的人就算受了委屈了，想想哪都差不多，只要薪水还可以能过的去就忍了，等差不多到了时候跳个槽就是了。在这种氛围下，人性化具体下来是什么东西呢，给点加班费还是多去加几顿餐？
老外谈人性化，说要把工作和生活分开，要让员工有安全感、成就感、归属感，未来能发展，还能对其他同事感到很亲切。对咱们中国的大部分工程师来说，除了遇到个好领导能感到亲切一些，安全感、归属感、成就感，甚至长远的发展就只是少数幸运的人才能拥有的了。这个问题我也没有很明确的理解，就我自己的看法，我觉得作为领导能做到公平、宽容、鼓励优先，能尽可能的让弟兄们少加几个班，就算是有点人性化原则了。
算了，撇开让人郁闷的人性化，来说说质量第一和不断提高。其实在俺们的项目中，尤其对PM而言，质量第一有时候会成了一个自欺欺人的口号。质量和进度有冲突，怎么办？我的经验是质量第一不等于质量最先，产品有Bug不会扣钱，按期交不出活不但要扣钱，还要损失信誉；那怎么办，要降低产品质量用不好的解决方案或者弄虚作假么？也不可！现在的程序都是B/S的，方便升级，先交互，再抓紧时间出补丁在客户反馈之前去升级就是了，你去升级，客户还高兴觉得维护费用没白交呢。
这里就引出另一个原则了，慢慢走。这个我体会也很深，做项目真的就是应该一步一步做，不能好高骛远，一下把功能设计的过复杂，把摊子铺的太大。开发中把功能一个一个实现了，然后一个一个做稳定；交互给用户后，不断的能做一些功能的改善、提高；这个慢慢走不仅是一个什么成本、风险的问题，更是一种感觉，一种让项目开发人员觉得不断前进，让用户觉得你的产品在不断的改善提高的Feeling！
四 XP实践
XP编程理论里列举了大量的实践方法，我挑感触比较深的和大家来交流一下：
这一条简直是中小软件开发设计的至理名言！项目做的少的人可能很难理解这句话的重要性，极端的说，那些想一开始就把各个东西都设计好的项目,基本和没有做设计差不多。过去我们提"原型开发法",在RUP里我们讲短周期迭代，在XP中我们说要周循环，季循环，要增量设计，这都是为什么呢？就是因为我们老是发现设计和后来的变化差别太大，要回去改设计又总存在各方面的问题（懒惰嫌麻烦、怕出问题有顾虑、有风险不愿担责任，太忙了没时间等等）。最早原型开发法就是不要设计了，根据实际做出的东西来调整，RUP是有致命伤的，不敢面对这个问题，不痛不痒的说把开发过程多弄几设几个里程碑，及时调整好了。而XP提出的一点一点设计，似乎是最靠谱的，把设计过程一点一点分解到开发的过程中，或许一直一来很多的优秀的团队也正是这样做的。
这一条对PM来说也是非常有实用价值。从负责人的角度，要尽可能宽松的制定计划，避免“高承诺、低交付”对团队带来的信心、热情、积极性的负面影响。一个弟兄，活干的快了受了表扬，下次干的可能就更好了；要是活没干好交不出来，他的信心受了打击，就不是简单谈谈话能调动的起来了。
这个从实际操作来说，XP讲究实事求是，成员间信息透明，让大家了解真实情况，不允许少干不报，也不允许多干少报。但我理解这是局限在团队内部的，属于人民内部矛盾，对于自己人，我们当然不能欺上瞒下，干活时，等或者是拖，都是不对的。但是对外面对那些只要结果的客户，有时也是需要应用一些必要的策略，尽可能争取到合理的时间，尽量把客户的预期引导到正确的范围内。
可能你觉得很多少时候这种事情超出了PM的能力范围，工作量、交互时间在你接到活时就已经定下来了，只能硬着头皮上。光是咬牙做当然是愚蠢的，这种情况我过去的做法往往是在过的过程中要想办法逐步降低用户的预期，即要设法降低承诺，强调强调困难，方法得当大部分情况下客户还是可以做出一定的让步的。当然同时一定要提高交付的产品质量，保证客户的满意度。
对这个我可能有些保守，我相信结对编程其实是大家一种在用的一种编程方式，并没有什么特别神奇的。除了XP理论书籍里的提到的那些弊端，我认为结对编程的负面作用其实还有很多。比如对新人，养成编写程序的独立思考能力很要紧，不能上来就老结对，靠别人的启发来慢慢搞。因此我认为让大家知道结对编程这种方式是可取的，有必要的时候(比如有些问题自己想不太清楚)找个合适的人结个对，讨论讨论就可以了。
声明：本博客中所有文章均为版主原创，转载请保留作者信息，并请注明出处。
带着众多诱人的新特性，Dojo 0.4 发布了。抽出时间下载了一个体验了一把，结果用一句话来概况： 惊喜多多！
首先是这一版加入的几个新的 Widget: Clock, FilteringTable,ProgressBar。这些widget中比较重要的是 FilteringTable， FilteringTable的加入是用来替换以前的SortableTable，相比SortableTable, 它的新的特性包括：
Multiple Column Sorting (number of columns settable, default is 1)
Sorting in place (non-destructive)
Per-column programmatic filtering
Add and remove rows on the fly
Update field values (with typing) on the fly
No restrictions on sorting on markup
从这个地址去体验一下： http://archive.dojotoolkit.org/nightly/tests/widget/test_FilteringTable.html，功能非常强大，可以直接从传过来的JSON对象中构造出列表，动态的过滤数据，改变各个字段的值，可惜这个版本中还不支持分页，列、行的拖拉的功能，只能是期待下一版了。其他几个Widget也都非常的实用，dojo的官方网站上都有例子，感兴趣的可以去找找。
下一个是让人感到惊喜是新增的 dojo.charting 和 dojo.gfx 包， dojo.charting 提供了一个基于Vector实现了多种图表类型的charting engine，从demo上来看，非常不错哦！ 可以从这个地址体验一下：
http://archive.dojotoolkit.org/nightly/tests/charting/test_engine.html
另外一个好消息是，从昨天dojo官方网站的新闻上看到 Greenplum 和 SitePen（两个技术型的企业） 宣布把他们的一些技术捐赠给Dojo的 new charting engine。dojo.gfx是一个二维矢量图形的API，能自动的根据客户浏览器的类型决定使用SVG或是VML，也很实用，比如新增加的Clock Widget就是基于这个包实现的。这两个包的加入让我们有理由相信不远的将来，dojo必然会撑起网页图表的一片天!
然后是 dojo.a11y 包，a11y 是accessibility的缩写，主要是加入对键盘按键（快捷键）的支持。官方网站上说的是在Dojo 0.4中只有一部分widget中已经加入了这方面的支持，在0.5中会加入努力更多。
国际化支持方面，这个版本的 dojo.i18n 包做了不少的改动，加入了对 collecting localized resources 的支持，提供了更多的date and time 的格式，此外对很多 widget （DatePicker, TimePicker等等） 也做了国际化的改进，不过DatePicker，TimePicker依然是丑陋无比。可以看到和dojo 0.3.1比，国际化的框架并没有很大的变动， 这次主要是具体的进行一些完善。
还有很多其他的包，像 dojo.lfx，dojo.namespaces，dojo.html等等，在这一版中也都得到了很大的提高，详细一点的列表可以查看 http://dojo.jot.com/WikiHome/Release0Point4 。
从0.3.1 到 0.4 几个月的时间里dojo便得到如此大的提高，根据Dojo网站上的公告，dojo 0.4.1过几天也就要发布了，在几个月后又要出0.5，按照这效率，想想一年后的dojo，真是让人抓狂！
摘要: 在Oracle10g开始盛行的今天，9i依然在众多项目中得到广泛应用, 这次一个偶然的机会需要在Red Hat ES 4上装Oracle9i, 想想上次装Oracle还是三年前的事了, 由于ES4不 在 Oracle 9i 的官方支持的linux版本之内,这次安装用了近2天时间才搞定，查资料，找补丁，一遍一遍的重装，好像回到了当年刚参加工作时的那种状态，很有感触，做技术有些东西总是不会变。装的过程中发现网上对ES4上装Oracle 9i的总结不多，大部分都不是很完整，便整理了这个文档，希望对大家有用。
阅读全文
这两天花了点时间看 Dojo 0.3.1 的新功能， 发现Dojo果然兑现承诺， 在0.3.1加入了一点国际化支持的功能。最主要的是改动是引进了 dojo.locale 属性和 dojo.i18n 包， 从而于 javascript 实现了Client端的本地 message bundle 机制，从现在起，我们可以在客户端根据locale装载JS消息文件了! 完整的示例代码如下：
<script type="text/javascript">
djConfig = {
isDebug: true
};
</script>
<script type="text/javascript" src="../../dojo.js"></script>
<script type="text/javascript" src="../_bootstrap.js"></script>
<script type="text/javascript">
dojo.locale = "fr";
dojo.requireLocalization("g11n.messages","salutations","en");
dojo.requireLocalization("g11n.messages","salutations","fr");
dojo.requireLocalization("g11n.messages","salutations","zh-cn");
dojo.require('dojo.i18n.common');
</script>
<script type="text/javascript">
function init() {
var salutations_default = dojo.i18n.getLocalization("g11n.messages", "salutations");
dojo.debug("default language: "+salutations_default.hello);
var salutations_zh = dojo.i18n.getLocalization("g11n.messages", "salutations", "zh-cn");
dojo.debug("Chinese: "+salutations_zh.hello);
}
dojo.addOnLoad(init);
</script>
首先是 dojo.locale 这个属性，这个属性是一个全局，作为用户默认的locale，如果用户不明确指定，dojo会根据浏览器的locale对这个属性赋值。和Java不同，目前在dojo中locale并没有对应对象，只是一个String对象，典型的格式应该是 "zh","zh-cn"。注意后者用的是 "-" ,而不是Java中的 "_"。
现在来看最让人心动的 message bundle 机制, 首先分成三步来把message文件组织好:
1) 要建立一个集中存放message文件的目录，我建的是 g11n\messages;
2) 和在java中一样，为不同的locale建立存放message文件的文件夹，比如我建的是"en","fr","zh-cn"; 这里要注意文件夹的名称必须要全部小写，原因是dojo从文件装载消息会把传入的locale属性进行 toLowerCase() 的处理(晕，不知道作者怎么想的)。
3) 把翻译完并用native2ascii转换好的消息文件放入对应的文件夹内。和Java不同的是，dojo用 JSON 格式来组织message文件,所以要把property文件转换到JSON格式的js文件, 不过这也很容易: 在文件开始的位置加入一个"{", 结尾的地方加入"}", 将所有的 "=" 替换成 ":" , 然后在每一行结尾处加入一个"," ,最后把文件改成js结尾便可以了。一个典型的JSON格式的文件如下(假设文件名叫 salutations.js ) :
{
hello: "Hello",
dojo: "Dojo",
hello_dojo: "%{hello}, %{dojo}!",
file_not_found:"The file you requested, %{0}, is not found."
}
把消息文件放好后，便可以在 dojo 中通过 dojo.requireLocalization() 调用这些文件了,对应的代码是：
//下载需要的locale的消息文件到客户端
dojo.requireLocalization("g11n.messages","salutations","en");
dojo.requireLocalization("g11n.messages","salutations","fr");
dojo.requireLocalization("g11n.messages","salutations","zh-cn");
//调用国际化包
dojo.require('dojo.i18n.common');
现在就可以调用指定locale的 message 了！在示例代码中我举了两个简单的例子：
//调用 dojo.locale 指定的locale中对应的消息文件中 hello 那条消息
var salutations_default = dojo.i18n.getLocalization("g11n.messages", "salutations");
dojo.debug("default language: " + salutations_default.hello);
//调用"zh-cn"中 hello 那条消息
var salutations_zh = dojo.i18n.getLocalization("g11n.messages", "salutations", "zh-cn");
dojo.debug("Chinese: "+salutations_zh.hello);
怎么样，非常简单吧?
除了message bundle, dojo 还声明要支持其他的一些国际化功能，比如Date,Number,Currency等等，在0.3.1中我只发现Date有一定的实现，但是基本就是对 Javascript Date 对象的几个locale相关的方法进行了一下封装，没有多少实质性的提高，看来dojo在国际化的支持方面还有很长的路要走。无论如何0.3.1中提供的message bundle已经有了一个良好的开端，值得期待。
前几天遇到一个bug，在一个填email的文本框，当用户录入比较长的一段文本后（比如40位以上），页面就死掉了。检查后发现校验Email的是下面这样一段javascript代码：
function checkEmail(email)
{
if (email.length == 0 )
return true;
var validEmail = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/;
if (validEmail.test(email))
{
return true
}
return false
}
checkEmail("123456789012345678901234567890123456789012345abcdefghijkl");
第一反应是正则表达式写的有问题，'@'前后的 ([\.-]?\w+)* 都可能会引起效率问题。下面仔细分析一下:
1. 从输入的值来看， engine会首先匹配 \w+， 这是一个贪婪匹配，可以一直匹配到结尾；
2. 然后按优先级开始匹配 ([\.-]?\w+)*中的 [\.-]?\w+，这个时候前面的 \w+ 为了后面的匹配成功，必须要重现匹配，让出一点匹配的内容，假设先让出的是 'l'，([\.-]?\w+)*匹配成功；
3. ([\.-]?\w+)* 意味着要尽量去匹配多次，再第二次对 [\.-]?\w+ 匹配，这个时候为了第二次匹配的成功，第一次匹配的 [\.-]?\w+ 要让出能满足第二次 [\.-]?\w+ 的内容，也就是它匹配到的'l'，这个时候，第一次匹配的 [\.-]?\w+ 又不满足了，\w+ 又得让出来一个'k'。
4. 这样未知匹配次数的 ([\.-]?\w+)* 就形成了一个很大的循环，而在正则表达式中，每次匹配时被括号里模式匹配的东西都是要被存起来供以后使用的，大量的中间结果被缓存，最终导致IE死掉。
所以这是一条典型的因为循环尝试匹配导致效率低下的正则表达式， 表达式中两个 ([\.-]?\w+)* 都可能导致解释器的crash，在本例中不需要利用匹配的中间结果，所以解决的办法很简单，在括号加入一个冒号，不保存中间结果就是了。即将那个正则表达式改成如下：
/^\w+(?:[\.-]?\w+)*@\w+(?:[\.-]?\w+)*(\.\w{2,3})+$/
如果性能还是不能满足需求，可以考虑把这个正则表达式拆成几个小的表达式，分别进行验证。
1） SVN配置文件中各个属性行前不能有空格
在Windows平台下安装Subversion之后，使用时提示svnserve.conf中一些行有问题。打开svnserve.conf一看 "password-db = passwd" 这一行最前面被我无意中加了个空格，删掉后SVN便工作正常了。
2） Tomcat 5.5 连接池的古怪错误
在tomcat 5.5下配置连接池，使用时总是出错： Cannot create JDBC driver of class '' for connect URL 'null'。
一样的配置以前在5.0下都是可以正常工作的。查了Tomcat的联机文档也没有什么发现，多次尝试最后找到解决办法：在 $CATALINA_HOME/conf/Catalina/Host Name/ 下建一个和应用同名的xml文件，将原来放在server.xml文件中的该应用对应的Context定义放在这个xml文件中，便不会有这个错了。
3） Velocity配置文件中${webapp.root}变量不起作用
在spring中使用velocity作为显示层，以前一直是用绝对路径来指定velocity模板文件的根目录，这次想直接和应用的root路径挂起来。
在velocity.properties中file.resource.loader.path的注释中看到有一个${webapp.root}的描述，便在velocity.properties中设置 file.resource.loader.path=${webapp.root}\\velocity\\，不起作用。看来velocity自己并不会设置类似于${webapp.root}这样一个变量，查velocity的Developer's Guide，也没有找到有类似${webapp.root}的变量，Guide中倒是推荐将模板文件打成jar，然后用ClasspathResourceLoader来找模板文件，开发阶段可不想弄的如此晦涩，还是直接改回用绝对路径好了。
几个小问题虽然都解决了，但却不知道为什么，因为时间的原因我也没有深究。现在贴出来，有人知道原因的，还请不吝赐教。