今天，终于对隐喻（metaphor）有了一点点进一步的认识。根据我现在的理解，隐喻表现为一组形象贴切的，彼此关联的，并且是自包含的名词集合。它涵盖了人们对系统未来功能和特性的愿景。如果用隐喻向一个对系统还知之甚少的局外人作解释，应该可以使他快速的认识和理解，并且打消存在于其大脑中的诸多疑惑。另外，隐喻的使用者，自身也可以通过不断比较实现与隐喻之间的差异来确知实现是否偏离愿景。这也就是为什么时常采用拼图这个比喻来描述隐喻的原因，现在想想确实十分形象：拼块就是实现，完整的拼图就是愿景，拼图的过程——尝试、调整、剔除不合要求的拼块——就是软件开发的过程。
不过我觉得，要找到这样一组词汇也并非易事。比喻毕竟是比喻，对于复杂系统而言，首先自包含就是一个问题，如何能找到一组不多不少，刚好可以完全说明系统愿景的词汇呢。另外，如果自己对系统轮廓还比较模糊的时候，很有可能形成一些似是而非、模棱两可，看似贴切、实则误导别人的隐喻。这也许是一个逐步进化的过程（听起来有点向迭代）。
终于试验通过了在Eclipse下用lomboz结合Jboss的EJB和Servlet开发。
换了一个Eclispe3.0还真是很管用，以前在2.1上配置时，一直存在classpath找不到的错误，如今也迎刃而解了。由此也可看到，Eclipse与其插件以及服务器的版本不兼容问题还是很麻烦的。
现在我用的版本分别是：
- JBoss 3.2.5
- Eclispe 3.0.o
- Lomboz 3.0.1
(more…)
编译自《Java Development with Ant》
- 签入。安全起见，将所有内容签入，并标以BEFORE_ANT标志。
- 清理。清除旧的.class文件以免混淆，将旧的JAR文件备份至安全的地方。此时项目中不应该有任何生成文件。
- 明确交付内容。通过检查你现有的build工具，列一个有关于你的项目输出结果的清单，以及生成它们的步骤；再列一个Ant target的清单及其依赖关系。
- 定义目录。定义你的目录结构以及用于引用这些目录的porperty名称。
- 设计build文件。初步设计你的build文件，或是复用一个现成货。
- 安置源文件。如果你需要放置源文件到新的目录，现在做。
- 实现build文件。创建你已经定义好的build文件，或是定制一个现成货。
- 以verbose运行build。以verbose标记运行build文件，验证其是否工作正常。
- 添加一些测试。开始编写测试，如果先前没有的话。
- 完善build文件。根据需要添加更多的target。
编译自《Java Development with Ant》
- 要牢记以目标为出发点
- 在构建过程中集成测试
-提供自动化部署的支持
- 让构建脚本文件可移植
- 让构建脚本文件可定制
(more…)
这是一个摘自《Java Development with Ant》的Java archieves的UML图，很直观，也很贴切：WAR文件和JAR文件是JAR文件的子类，而JAR文件自身则是ZIP文件的子类。WAR文件可以包含JAR文件，EAR则可以包含JAR和WAR。JAR文件通常包含一个manifest文件，以及一些编译过了的class文件。图中省略的一点实事是，Zip和经过gzip的tar文件通常也被用来发布JAR、WAR和EAR文件。 (more…)
译自《Java Development with Ant》
- 测试每一处可能出错的地方。这是XP所坚持的一条格言。
- 一个优秀的测试是很难通过的。如果所有测试都顺利通过了，那么你的测试很可能不够充分。
- 为你发现的每一个bug添加一个新的测试用例。
- 一旦测试失败，通过编写更多的测试来捕获问题，而非马上求助于debugger。测试越多越好。
- 以无效参数测试每个方法，而非仅是有效数据。工业级软件需要识别和处理非法数据，而且以错误数据通过测试往往是最说明问题的。
- 在运行新的测试之前，先清除既往的测试结果。
- 测试用例采用统一的命名规范：*Test.java。
- 将测试代码与产品代码分开存放。以同样的包命名结构为两者提供各自独立的目录树。这使得测试与被测对象处于相同的包中，而创建时又保持各自独立。
- 一旦产生错误（error）或失败（failure），终止创建过程。
- 为测试起名要贴切。
- 每个测试方法尽量测试一件事情。
乍一看，ant的target/task概念十分的简洁，可是当你开始深入了解其背后的“语法”时，那简直是一幅让人发怵的情景——一个何其庞大的体系。
想想三年前的ant，是多么的简洁（或者说简陋更合适些）。可现如今，随着不同的tasks，不同的datatypes，不同的properties被引入，在build.xml的表达能力极度丰富的同时，其语法体系也极度膨胀了。有时候，尤其对一个不十分熟练的newbie而言，dir、srcdir、destdir的幻化有如移形大法般让人摸不着头脑，更不用说那些刚刚引入不久的新特性了。
不明白这种复杂化是否真的有必要。诚然，功能是强大了，可学习的门槛又提高了（这让我想起了struts里的tag library）；而与此同时，在多数情况下或许我们对ant的使用就仅仅是日常部分罢了。换句话说，我们对ant的80%的使用只涵盖了其功能集的20%。这是一个老话题了。一个典型的例子是所谓的“regexp mapper”，引入了貌似功能强大正则表达式，可这种mapper的使用会带来极大的复杂性，而现实中又有多少可以真正让regexp mapper一展身手的机会呢？
上次对开源项目的运作方式一直迷惑不解，今天在看《Java Development with Ant》中有关Ant的演化过程时，总算是有了点眉目，受了些启发。 (more…)
如何了解一个产品研发的全过程？眼下也许是一个契机。尽管以前兼职期间我也曾亲历过产品研发的过程，但毕竟是在产品成熟时期介入的，并且中途又离开了。因此，很多时候都是局部的割裂的和感性的，而无法从认识上一窥全貌。很遗憾，一直都想把当初经历的点滴整理记录下来，却又因为时间和懒惰的原因，久未付诸行动，恐怕现在已经记忆模糊了。
不管眼下的产品最终会否成功，如果全力投入，总会对自己大有裨益，不单是技术，还包括技术之外的方方面面。这是纯粹的软件开发所无法体验到的。我要注意积累。
另一方面，纯粹的技术体验，可以从开源软件中获得，这方面我也有所打算。从设计到实现，作一个全程的跟踪。很久没有做这样的事情了。
Everything should be as simple as possible,but no simpler.
——爱因斯坦
我喜欢简单，也崇尚专注。 (more…)
终于可以在Eclipse+Tomcat下顺利调试Jsp了。下午顺利实现Tomcat上的特定配置，即：定义一个workDir为j2src的Context：
<Context path="/helloWorld" debug="0" reloadable="true" docBase="C:/eclipse/workspace/helloWorldJsp/helloWorld" workDir="C:/eclipse/workspace/helloWorldJsp/j2src"> </Context>
http://www.theserverside.com/news/thread.tss?thread_id=27998
http://www.jdocs.com，作为javadoc APIs的网上仓库，看起来确实是个不错的主意。目前已经有了50个大大小小的流行的Projects了，还在继续中。
除了有待完善的APIs搜索外，还提供了用户提交Comments的功能，这个很像wiki，每个人都可以为这个网上仓库贡献自己的绵薄之力。另一个不错的建议是：提供配套的Samples的搜索，以及网上运行Samples的功能。
也许这是未来的Java Community的Kowledge Center，不知道能热乎多久，拭目以待。
有是一个莫名其妙的错误，在eclipse中成功启动了Tomcat，可是在Browser里输入http://localhost:8080之后，IDE中的Console蹦出了一串异常：
java.lang.NoClassDefFoundError: org/apache/commons/el/ExpressionEvaluatorImpl
at org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:144)
…
于是效仿几天前的做法，在网上搜索了一番，果然没有让我失望，也有人曾经遇到和我一样的困惑，虽然所提供的解决方法，在我的环境里并没有成功，但这启发了我。既然是NoClassDefFoundError，那我就顺藤摸瓜，找到了该问题类所在的文件：common/lib下的commons-el.jar。然后在Windows->Preference->Lomboz->Server Definitions的对应处添加了该jar包。果然，问题解决了。
同学问我如何获取数据库中字段的名称，结果还是他自己找到了答案。后来在网上查了资料，现把它诸于此，以备后查：
// sample codes: display the whole column names of a result set ResultSet rs = stmt.getResultSet() ResultSetMetaData rsmd = rs.getMetaData();int columeCount = rsmd.getColumnCount() for (i = 1; i < = columnCount; i ++) { System.out.println(rsmd.getColumnName()) }
现在的IT，有很多单位都在做自己的产品。传统的产品研发是从轮子造起，一点一点，集腋成裘。这样的产品研发方式，我也经历过。但是，在有同类产品先期流于市场，且颇具竞争力的前提下，这样的方法难免风险过大，恐怕任何一个中小企业的决策者，除非有十足把握和雄心壮志，否则万不敢冒此风险。 (more…)
今天早上看了同事的一篇文章，文章写于2002年底，不过里面的内容依然颇值得玩味。
题目：浅评微软，Java, 和开放源码运动
我也在IT里混了近十年了（当然是从大学三年级开始算的）。一直都在MS战线上混，很崇拜MS。是MS的忠实拥趸。其实偏向于反微软阵营的人和老记之流挂在嘴边的是微软没技术，微软只会抄袭模仿。其实就我感悟的来说，就总体上而言，微软是最有技术的。技术上模仿、借鉴、和创新超越的路子，其实每个公司都是一样的，特别对于市场上已经有先行者，而你又要击败先行者。既然是先行者，就有很多东西是已经经过摸索和证明了的，再做出来的东西类似，也就是必然的了。微软不是世界的全部，因此你不能指望微软能攘括所有的创新，任何公司都有自己的主要战线和技术局限性。
(more…)
周末一直在为一件事情苦恼，本想试验一下在Eclispe中调试Jsp，却遇到了Tomcat启动失败的错误。在命令行下运行一切正常，可在IDE下就是不行。虽然搜索了很多网上介绍用Eclispe结合Tomcat的文章，可是大都泛泛而谈，隔靴搔痒，走个过场也就结束了。另外，这些文章所使用的环境版本也不尽相同，我所使用的是：Eclispe 2.1 + Lomboz 2.1 + Tomcat 5.0.27。
好在今天突然想到用错误信息作为google的搜索关键字，结果问题迎刃而解，原来是Tomcat版本的问题，如果使用5.0.24就不会出现类似错误，不过另一种稍微高明一点的办法是修改lobmoz的plugins下的tomcat50x.server文件，把该文件中的startWorkingDirectory和stopWorkingDirectory一项中的-Djava.endorsed.dirs调整为："${serverRootDirectory}/common/endorsed"。这个解决办法的思路来自于Tomcat的bin目录下的启动脚本catalina.bat
完整的解决方法可以在objectweb的论坛里找到。
看来搜索的技巧也是很关键的:)
要学习的技术实在是太多了，一再感到书到用时方恨少。并且，许多知识点都是彼此关联，有着千丝万缕的联系的。因此，就像乱麻一样，很难一下理清思路，很难一下看清该从哪里入手。现在的我，正处在一个“艰难”的时期。
我想，首先需要花时间和力气，从横向的面上了解（但不是深入），对领域有大致的总体认识（这正是我目前在做的事情）；在经过这段困难时期之后，结合实际选定某几个点，进行深入的学习、研究，并用到实际。前一点有助于解决千头万绪的困惑和左突右闯的盲目；而后一点，则是经历必经的混沌期之后的更为重要的一步，深入扎根于某一两项技术是自己得以有质的飞跃的关键，否则就只能是无源之水，无本之木，始终游走于技术的“围城”之外。
外面的人想冲进去，里面的人想出来。我现在的处境大概属于前者，因为想立足于技术的人，总还是想要进到围城里面的，虽然世事总难得兼:)
今天因为要修改一篇有关Ice使用入门的稿子，对“Distributed Programming with Ice”中涉及Slice部分的那一章又大致的翻看了一下。尽管Slice比起CORBA IDL来已经砍去了许多不太实用的特性，但是也加入了许多新特性。因此看起来并不像想象当中那么简单。不过的确，Slice包含了许多特性，甚至是c/c++风格的注视，以及预编译指令。还有一个类似namespace的被称为module的东西，真是包罗万象。 (more…)
Powered by WordPress
