2005年11月9日
#
摘要: 这些天一直在为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来找模板文件，开发阶段可不想弄的如此晦涩，还是直接改回用绝对路径好了。
几个小问题虽然都解决了，但却不知道为什么，因为时间的原因我也没有深究。现在贴出来，有人知道原因的，还请不吝赐教。
用了四五年的Table排版，没觉得有什么不好，这一段时间迷上了Dojo,才发现如今已经到了不用DIV不行的年代。还是赶紧跟上潮流，把Table换成DIV吧! 改了几个页面，发现比想象的简单，更是尝到了用div的甜头。share自己一点浅浅的经验：
1. 先上网搜一下找点前人经验。推荐两篇好文：
http://www.glish.com/css/ "CSS Layout Techniques: for Fun and Profit"
http://www.alistapart.com/articles/practicalcss "Practical CSS Layout Tips, Tricks, & Techniques"
2. 随便找几个用DIV+CSS实现，结构又比较简单的网站，研究一下它的页面结构和CSS。比如我就是主要看了下面几个网站：
CSS禅花园 http://csszengarden.com/
Eclipse.org http://www.eclipse.org/
mozilla.com http://www.mozilla.com/
作为世界上CSS高手比武的擂台，CSS禅花园的模板实在多的恐怖，以前都只站在欣赏的角度不觉得，自己研究起来，也就只能是挑了一两个看看，再感慨了一番作者真是好创意好美工。有趣的是Eclipse.org的首页居然基本用的都是mozilla.com的CSS，对比着这两个网站看更能看出端倪。
3. 自己上手干吧，让你的页面内容和显示样式彻底分离，其实并不难。
GB18030 的正式名称为“中文国家标准 GB 18030-2000：信息技术 － 信息交换用汉字编码字符集－ 基本集的扩充”。它是针对在中国出售的所有产品制定的政府强制标准要求，该标准于 2001 年 9 月 1 日生效。这也意味着从理论说，每个在出售的产品都要支持GB18030字编码字符集，否则就不让卖[嘿嘿，您的产品达标了么？]。
有人曾经在他的一篇blog[ http://blog.cathayan.org/archive/1/2005-7-4 ]里非常形象的介绍过 GB18030 的历史,转贴精彩部分如下：
1，GB2312是很老的东西了，早就发现不够用了。
2，94年（还是之前）国家推出了建议性标准gb18000（还是13000我忘了），这个标准其实就是utf-8标准（除了名字，完全一样），同时也建议微软公司采纳。－－（据说是1993年，GB13000，应该是ISO10646）
3，微软借口说gb18000还不成熟，为了取得中国市场的垄断地位，自己搞了一套汉字标准，于是它就随着win95和office之类的流行起来了，国家看生米已经煮成了熟饭，只好把这套标准定为国标GBK标准。－－（其实只是指导性标准，并非强制性，GB18030是强制性标准）
4，微软到了99年（前后吧），又说GBK已经落伍了，现在流行utf-8标准，准备全盘转换成utf-8，这些把有关部门惹怒了。NND，当年我们推utf-8你说不成熟，自己搞了一套，现在赚得盆满钵满了又自己说要推utf-8了，你丫微软分明就没把政府放在眼里。
5，于是政府怒了，强制推行gb18030标准（这个标准前面兼容GBK，其他码位兼容utf-8），算是过渡标准吧。要求微软强制执行，否则产品不得在大陆买。于是基本搞死了微软的WindowsMe，差点搞死了Office2000（据说发行前几个月，微软除了改字符编码就没干其他什么事情）－－（确实，WinMe是我认为的最差的Windows版本，而office2k也是前不着村，后不着店，前后兼容性都差）
6，由于以上历史原因，现在就是GB2312，GBK，GB18030，UTF-8并存了。
7，如果不是万恶的微软，我们早就用上UTF-8了。
或许正是因为微软和中国之间为GB18030发生了这么多的恩恩怨怨和当年微软的仓促上阵，直到现在微软的很多产品对GB18030支持的依然不是很好。访问下面的页面，了解MS对GB18030支持情况及下载Windows下的GB18030安装包：
http://www.microsoft.com/globaldev/DrIntl/columns/015/default.mspx
虽然MS声明在Windows XP 和 Windows 2000 中通过"add-on"来支持GB18030，但是IE 6.0直接显示 List Box、Drop Down Menu、Text Area、Text Field中的GB18030字符依然还是有问题，下面的这篇文章有相关的介绍：
http://www-306.ibm.com/software/globalization/gb18030support/retrieve.jsp
在IBM的这篇名为"Globalize your On Demand Business"的文章里，给出的solution是在要显示GB18030的元素上加上类似 "STYLE="font-family:'SimSun-18030'"的CSS声明。在当今WEB2.0如火如荼的年代，我们当然要把内容和显示分离，在CSS中进行配置！当然实际问题要比这个文档说的略微复杂一点，有下面几个比较明显的问题：
1) 一般来说，大部分html标签(包括Input)都不要，但<Select> 要必须要在CSS中强制指定"font-family"为"SimSun-18030"。
2) 当要为一个元素指定多个字体的时候，要将"SimSun-18030"作为首选，即放在最前面。
3) 对于大部分标签,当font-family设为 SimSun-18030 时，而font-size 为：8pt,9pt,11px 时，有一部分字符比如 "㊣"和一些标点 会显示成其他的字符，对 "㊣" 这样的字符，IE 会出现乱码。原因可能是因为这些个font-size针对WEB做了优化。
小结：GB18030是个形式大于内容的东西，但是如果想要让你的产品理直气壮的再中国销售，略微花点时间设置一下还是有必要的。
昨天抽出空来装了一个Ruby，体会体会这个最近很多人提起的东西。从下载到安装，包括装Cygwin一共也就用了一个小时。看了看它自带的文档，写了两个小脚本试了一下，觉得和perl很点类似，语法很简单，上手非常快，用起来也没感到什么特别神奇之处。接着下了久仰大名的Ruby on rails 装了一下试试，发现用它建站的确很快，就像当年用傻瓜相机的感觉。
简单来说，Ruby 给我的感觉一般，没有让我有一见钟情的感觉。我不是很喜欢Ruby这种很随意的语法，对于Ruby on rails这个轻量级的构架未来内能达到的高度也有所怀疑。Ruby就是Ruby，还是不能和Java来比较，离取代Java更是差十万八千里，Ruby本身是一个普通的脚本语言，和Java差别太大，Ruby无非是在各有千秋的众多编程语言里又加了一种。Ruby on Rails 的思路是比较前卫的，不过主要就是个思路，别人很容易就借鉴了，没准用不了多久java on rails,dotnet on rails就会出来。不知道Ruby on rails在事务、安全方面是怎么处理的,运行起来效率会怎样,反正觉得Ruby on Rails好像是用来做中小型网站的。网上好像Ruby的fans很多，其实回头看看，每种流行一点的脚本语言的Fans都很多。
我认为Ruby的语法、Ruby on Rails的特点注定了它只能给一些想快速建网站的人使用，是很难得到大公司青睐从而在商业领域获得更大空间的。对于目前新流行起来的几个脚本语言，我觉得groovy的定位还是很不错的，傍着Java这个巨人，将来没准能吃香的喝辣的。虽然不是特别看好Ruby,以后有时间还是准备系统的看一下ruby的语法和试一试ruby on rails的应用开发，应该能从里面找到很多可以借鉴的东西。
刚才无意中发现自己很久以前写给同事看的东西，干脆贴出来。
- 安装环境
Wiki的功能比较简单，因此互联网上Wiki的实现非常非常的多，有各种各样的实现，基于asp、java、php、Python、perl等等，大家可以根据情况自己挑一个。从这方面看，Wiki映证了一个道理，简单的就是最美的，好像有一大筐做工精致的艺术品摆在你面前让你挑，真是人生快事。至于俺么，当然是选择基于Java的了！有人做好了给你用，爽哦。
我的安装环境：Linux + Tomcat-5.0.19 + JSPWiki 2.0.52 + jdk1.4 。
- 开始安装的准备工作
下载 JDK, Tomcat 并安装,这里就不说了,呵呵。
从 http://www.jspwiki.org/ 下载JSPWiki, 当前的稳定版本是2.0.52。当然这个网站本身也是用Wiki做的，去下载时你就已经认识到Wiki是什么东东了。下载下来的是一个压缩文件 jspwiki-2.0.52-bin.zip ，解压后进入解压的文件夹，可以看到JSPWiki.war、JSPWiki-samplepages.zip两个文件，前者就是JSPWiki的程序了,JSPWiki-samplepages.zip里是其官方给出的一些例子页面，很有价值哦。
- 安装
将JSPWiki.war解压到一个文件夹，假设叫wiki，后放到 Tomcat 的Webapps文件夹下，进入 wiki/WEB-INF/ , 编辑 jspwiki.properties ,进行相关的设置,几个重要的参数:
a) jspwiki.applicationName = your app name -------- 你这个Wiki网站的名称
b) jspwiki.pageProvider = VersioningFileProvider -------- Wiki对页面的管理方式，有三种： RCSFileProvider， FileSystemProvider， VersioningFileProvider(推荐使用).
c) jspwiki.fileSystemProvider.pageDir = /home/wiki -------- 网站内容存放地点
d) jspwiki.basicAttachmentProvider.storageDir = /home/wiki/attach -------- 网站用户上传的附件的存放地点
e) jspwiki.encoding = UTF-8 -------- 设置页面的编码格式
f) jspwiki.rss.channelLanguage = zh-cn -------- 设置rss语言格式,如果你不需要rss功能的话可以不设置
g) jspwiki.baseURL= ——wiki的基本URL，如果你不需要rss功能的话可以不设置
h)jspwiki.translatorReader.allowHTML = false -------- 是否允许wiki里面支持html，网站对外开放时最好不要设，因为wiki是协同编辑的，如果有人恶意使用js的话，就惨了，呵呵。
- 设置字符集
安装后要使有中文问题,注意看上一项4中的 e ,f 两项是不是都设置对了.
- 运行Wiki,添加页面
jspWiki内置了一些用于布局的版面page，包括Home、Index、LeftFooter、LeftMenu、LegalAndPrivacyNotice、MenuBar、RightFooter、RightMenuBar、Website、Contacts、ErrorMessage等等，只要稍加编辑就可以攒一个挺专业的网站。激活它们的方法是浏览器中输入： http://localhost:8080/wiki/Wiki.jsp?page=pageName.
- 后期处理
设置tomcat为自启动： 在startup.sh 中设置 JAVA_HOME , CLASSPATH , PATH 等环境变量，在 /etc/rc.d/rc.local 中添加启动脚本。
熟悉wiki之后可以进一步学习FitNesse之类的 Wiki 的较高级的应用。
上周末按一个朋友的要求，写一个整合Tomcat-5.5.4与apache-2.0.49的文档。很久没用Apache了，在家用了一两个小时才在自己的XP下配成功，简单整理了一个文档贴出来，与需要的人共享。我开始是在 apache 的conf 文件夹里建了一个mod_jk2.conf个文件，用JkSet config.file ***语句指到TOMCAT_HOME\conf\workers2.properties, 无论如何都不成功，最后就直接把workers2.properties拷到apache 的 conf 文件夹里就OK了。具体步骤如下：
1、假设Apache2安装在 C:\Program Files\Apache Group\Apache2, 上Apache网站下载jakarta-tomcat-connectors-jk2.0.4-win32-apache2.0.49.zip , 解压后将modules\mod_jk2.so拷贝到C:\Program Files\Apache Group\Apache2\modules里面。
2、 在C:\Program Files\Apache Group\Apache2\httpd.conf中设置Dynamic Shared Object (DSO) Support的那块区域里增加一行：
LoadModule jk2_module modules/mod_jk2.so
3、修改 Tomcat-5.5.4 HOME\conf\ 下的配置文件, 编辑jk2.properties，修改handler.list的值，要注意端口channelSocket.port设置的值，默认是8019，改成8009, 这样改各个配置文件的改动量最小。
# Set the desired handler list
# handler.list=apr,request,channelJni
handler.list=channelSocket,request
#,
# Override the default port for the socketChannel
channelSocket.port=8009
4、将 Tomcat-5.5.4 HOME \conf\ 下的workers2.properties 拷贝到 C:\Program Files\Apache Group\Apache2\conf 中，然后修改workers2.properties 内容：
[logger.apache2]
level=INFO
[shm]
file=C:\\apache\\Apache2\\logs\\shm.file
size=1048576
[channel.socket:localhost:8009]
port=8009
host=localhost
[ajp13:localhost:8009]
channel=channel.socket:localhost:8009
[uri:/*]
worker=ajp13:localhost:8009
要进一步设置的，修改[uri:/*]，比如改为[uri:/*.jsp]。当然这样记住要先将Apache的默认目录指到tomcat下的对应的应用. 此外[uri:/*] 这部分可以设置多个。
5、重新启动apache、tomcat, 访问apache的地址http://localhost/和tomcat的地址http://localhost:****/ ,如果看到一样的东西,应该就可以了。
6、配Apache的默认目录或虚拟主机，指到要用Apache来显示的目录里面去；网上很多，Apache本身的文档说的也比较清楚，就不详细说了。
7、如果是 Linux 平台的话，Apache 必须要在编译的时候加上选项，使其能动态的加载DSO模块，大概的步骤就是下载Apache源文件 ，然后依次执行：
#cd /usr/local/src/ ( /usr/local/src/ 就是保存安装源文件的文件夹 )
#tar -xzvf httpd-2.0.49.tar.gz
#cd httpd-2.0.49
#./configure --prefix=/usr/local/apache2 --enable-so (-enable-so 这个选项最重要，一定要加上 )
#make
#make install
后来的步骤和windows下应该是一样的（那个so文件应该也可以在linux用），linux下面我这次没有试，不过思路和步骤应该差不多就是这样,俺以前配过。
从年初到现在，AJAX之风预演愈烈，尤其是在国内，大多是一片叫好的声音。目前好像很多人都在搞基于AJAX的框架，国外也有一些都已经发布。对于这种一直都存在技术，Google、微软一造势，大家的热度好像有点过了头。看来现在咱们这些程序员真的都是些追星族啊！
难到AJAX真的就那么优秀，值得提升到框架的高度，让系统UI端围着它转？单纯从AJAX本身来说，其最主要不过就是解决在网页上一个无刷新获取数据的问题，再加上减少了数据的传输量，将数据解析的工作推到了客户端，的确能解决很多传统的问题，很方便的实现一些动态效果。然而，要围绕AJAX建立一个框架，通过AJAX完成UI端绝大部分内容的展现，我个人认为却是欠妥。现在很多人在网站上说，AJAX多多成熟，能达到多好多好的效果，但是问题是，AJAX技术本身成熟，但AJAX框架却是十分的不成熟。
笔者前一段一直在参与一个国外知名大公司的一个产品的开发，这套系统好几年前就开始做了，系统的UI很多是基于AJAX的，对AJAX的应用可谓登峰造极（当然，那个时候肯定还没有AJAX这个名词），其界面的可操作行几乎可与桌面系统媲美。这系统有一个强大的AJAX框架，光是相关基础JS文件就是数十个，整个UI基于Javascript事件驱动，数据由XMLHttp获取。整个方案看上去的确很棒，或许正是现在很多人想要实现的。但实际情况是如何呢？效果是实现了，程序开发和测试、维护的效率则是大大的下降了。开发就不说了，前期投入巨大，系统复杂性剧增，程序也只能用IE访问。测试的时候这边 AJAX的javascript的bug满天飞，那边调试这种错误极不方便，没有好的JS的调试器，更看不到实际输出的html代码。维护那就糟糕，加个新功能，JSP文件、标签、JS、后台类全要过一遍。或许正是这些不易克服的问题，我看到在最近开发的配套软件里，就基本没有用什么AJAX了。
大公司的尝试和经验，或许能给大家一些启示。说到底，所有的技术都是有利有弊的，AJAX也是一样。我个人认为AJAX 最适合的就是Google Map这种网上地图系统，展现方案相对比较单一，又非常的需要无刷新的获取数据。对于那些业务比较多，展现风格非常多样的业务系统，万万不可脑子一热，真的要用什么AJAX框架，到头了只回为了一点无谓的效果砸了自己的脚。
最后强调一下，AJAX是个好东西，在项目里用它来实现一些辅助效果（最传统的比如用户输入数据时实时的验证，给出相关提示）即快捷又神奇，但过度使用很容易让自己系统陷入麻烦之中，一定要慎重！此外目前公布出来的所谓的那些AJAX框架大多都是实现一个Form或者一部分页面的无刷新取数，根本谈不上什么Web框架，目前没必要抱太大的希望。最近down了几个开源的ajax的东西看了看，觉得对一般开发人员来说，ajaxtags (http://sourceforge.net/projects/ajaxtags/) 是个不错的东东，简单易懂，可以仿照它的标签做一些自己的实现，值得看一看。
声明：本博客中所有文章均为版主原创，转载请保留作者信息，并请注明出处。
昨天无意中发现教育网内也能上google了，高兴之余也颇有感慨。回想过去数年我和朋友在教育网里搜资料，每每破费周折的设代理、找国际网关，还常常不如愿，不得不用蹩脚的baidu, 现在终于是方便了。
细想起来，这事情还得感谢我一向不太看的起的百度了! 数年前百度不过是个有些小聪明的模仿者，用一个类似Google的界面，搜出一堆杂乱的糟粕，前一段时间却因为上市一下誉满神州了。在我看来百度的红火，除了百度自己说的和门户网站合作挣钱之外，两个因素发挥了很大的作用，一个百度提供的mp3搜索下载，另一个是教育网内数量巨大的网民无法使用google，迫不得已就用百度了。
前者当然不用说，为了自己的利益，百度用一份所谓“著作权保护声明”做掩护便大张旗鼓的为侵犯知识产权的行为推波助澜，就连这份用来做作的声明，估计也还是被人告了一通之后才炮制出台的。写到这里，突然想去以前百度被告时申述的理由：要告应该去告那些侵权的网站，我百度只是提供搜索服务的，这跟我没关系。呵呵，百度逻辑的荒谬，由此可见一斑！分门别类的把那些侵权的东东排列好让人去down，还说和他没关系。倘若按这种逻辑，那些销赃的人就可以说，我知道这东西是偷来的，但这不是我偷的，我只是卖的，要抓抓那些小偷去！当然，销赃的人不只是百度一家，然百度却必是其中之一。
再看第二个因素，教育网内网民无法用google是历史问题，google最早是国外网站访问要算国际流量。于是缺乏就产生了，在经济学家眼里，缺乏、竞争、物产是同义词，有了缺乏就会有竞争，于是百度来了，承担起和google来compitition的责任，结果大家都看到了，百度受益不小。现在Google当然不会容忍在地球上人口最多,经济最有活力的国家有这样一个竞争对手，也开始反思其漠视中国最具前卫性的网民群体的行为，于是我在家能上google了。红尘俗世、莫不竞争，我这个老百姓又一次深深的感受到竞争的好处。
教育网内能有google了，百度会沦为一个mp3搜索站么？百度钱圈了一大笔，但是搜索的质量没有任何提高，倒是网站的乱七八糟的东西多了不少。我绝不并是刻意的要说百度的不是，我是中国人，当然希望我们自己国家的搜索引擎能强过美国人。最盼望的是百度能认真的把搜索做好，销赃的事情少做一点，compitition的责任多承担一点。等过些年倘若大家不用因教育网能上google欣喜，我们这些网民也算是有幸了。
对CSDN的blog失望透顶，决心放弃了。在网上寻了一通，还是这里比较适合我。这里blog都是讨论侧重讨论java的话题，正符合我的需要。我之所以不在自己的个人网站上自己做一个blog,就是希望能找一个好的社区，认识更多的网路朋友，而不是在自己网站上自鸣得意的show自己。