先说好的吧：首先，E客服就是比较有意思的东西，解决了很多客服平台的问题，过去我们为两个项目做的在线客服，跟它比起来，还是有差距的。平常店里可以同时有几个人一起打理，而且不会出现一个旺旺多个人使用的情况，它用的是子帐号的概念，各人独立一块，互不干涉。还是很不错的东西。

打印快递单应该也是个比较有意思的功能，如果货物量大的话，这个功能绝对是不可少的，大大减小了人力成本。不过估计我现在还是用不上的。

商品定时上架是个很好的功能，就是针对淘宝设计的功能，如果熟悉淘宝搜索结果规则的人，会很好的去利用这个规则，让自己的货物在最佳浏览时间出现在搜索靠前的位置。而定时上架就很好的解决了这个问题，如果有效利用的话，绝对会让你的商品卖的更好的。

在说一些不好的吧：首页有个统计最热卖的东西，但是没有找到热卖产品的排名，这个东西应该是挺有用的吧，不过似乎没有提供。查看报表里面，经常会刷不出图片，估计是 IE 的 Cache 原因，不再重新加载图片了。进销存这个东西没有和销售报告结合起来，应该算是一个缺憾了，希望下一个版本能有更多的东西。不过，不知道下个版本要到哪年，上个版本似乎已经发布半年了。

 对于开发人员来说，因为卡巴斯基更是会有诸多不爽的问题，下面列举一二，是我的惨痛教训，也和大家分享一下。

1. SVN 问题：如果你使用 SVN 做配置管理的话，有时候 check in 代码会半天没有反应，如果这时候你把卡巴禁用，就一切正常了。
2. IntelliJ IDEA 端口冲突问题：用 IDEA 启动 Tomcat 时，使用了 8080 或者 80 端口，经常会启动就报端口冲突，而端口绝对是没有被其他应用程序占用的，而在独立的 Tomcat 下运行没有出现这样的问题，把卡巴对这些端口的监控关闭就一切正常。

这两个问题都是比较郁闷的，卡巴斯基很强悍，却总是让人很无奈。

上周 Summer 推荐 Beautiful Code 的时候，也顺便找到了今年的 Jolt Awards Finalists，接着榜单，闲聊一下。

图书方面，看上去几乎是被 O’Reilly 和 Addison-Wesley 给垄断了，Pragmatic Bookshelf  也在其中占有了一席之地。图书中，最大的赢家应该是，Beautiful Code，我在国内某家被我批评过的IT书店上看到了挂上了期数的预告，名字叫《代码之美》，似乎有抄袭《数学之美》的嫌疑，第一次看到这么多作者一起写出来这么好的书，33 章的书，就包括了 33 个来自于不同领域的作者，共同创造了如此完美的代码，在 O’Reilly 的牵线搭桥下，造就了 Beautiful Code，如果有机会，我希望能由东南大学出版社出版这本书的英文影印版，让我们细细的品味。

Head First 的新书 Head First SQL Your Brain on SQL 也登上了 Jolt 的舞台，之前 Head First Design Pattern 和 Head First OOAD 是如此通俗的把面向对象的两个经典内容：设计模式和面向对象的分析与设计，聊家常一般的摆在我们的面前，精妙的内容组织，浅显易懂的语言，就连我们这些非常怕看英语的人看起来都毫不费力，不愧为大师级的功力。而这本新书料想也会给 SQL 的新手带来一种全新的体验吧。

Pragmatic Bookshelf 这个书系自从《Pragmatic  Programmer》 开始，就不断的扩大其影响。从程序员修炼三部曲中，告诉了我们版本控制，单元测试，持续集成这三个开发者的基本工具。随后的 Pragmatic  Ajax 把 Ajax 推到了大家的面前。当 Ruby on Rails 开始流行的时候，Programming Ruby 和 Agile Web Development with Rails 都在一版二版的洗礼中不断的升华，已经成为 RoR 开发的经典之作。这次的 XX It 系列又从软件项目管理角度来 Pragmatic 。我似乎看到过 Ship It 还有 Deploy It 这两本，或许也是这个系列里的吧。

The Rails Way 我一开始当成了 The Ruby Way，其实后者的风格我比较喜欢了，于是又套用了它的名号来了个 The Rails Way，虽然现在还没有拿到，我想这本书会给我们一些新意的。

开发工具大奖上已经看不到了 Eclipse 的身影，而 IDEA 依然在榜单上活跃，而我也是一如既往的使用它，即便是在 Rails IDE 中，IDEA 凭借其 Rails 插件，加上它的基础，用起来还是相当的顺手，目前除了不能 Debug，我似乎没有其他不满的地方。

Netbeans IDE 在年末闪亮登场后，带来了一个更轻更小，更完整的开发工具包，而 Eclipse WTP 一个包动辄就是 2xxM，虽然功能很齐全，不过体积实在是有些过分了，并且没有一种 IDEA 的那种让人很爽的感觉。我没有用完整的 Netbeans 包，因为 Java Web 开发已经习惯了 IDEA + Eclipse 的组合，我只关注了一下 Ruby IDE，功能上来说，确实有其独到之处，不过在写代码上还不能达到非常流畅的速度。不过 Netbeans 在两年里就来了个咸鱼翻身，我们要说 Sun 很努力了。

在开发框架上最活跃的依然是 Java 平台，这和 Java 平台一直以来保持的很好的开源社区是分不开的。EMF，Guice，JasperReports，Spring Framework 这几个一直都是 Java 领域最热门的开源项目。

Google Guice 在 Google 的天才程序员 Bob Lee 的创意中诞生了，采用了一种全新的依赖注入的方式，将效率提高了传说中的 100 倍，虽然对这个数据我不是太在意，而在 Spring 如此成熟的进入 2.0 后，却有一个后辈小生提出了全新的思路，而 Spring 2.5 也接受了这样的思路，调整了一些依赖注入的策略，在性能上有了不小的提高。

经营着 Spring 的 interface21 为了凸显其 Spring 的品牌，改名为 SpringSource，并且推出了一本《Spring In Production White Paper》，希望能够在企业应用中占有更大的份额。

作为 PHP 的领头羊的 Zend 在 Rails 推出后再也按耐不住了，PHP 一定要有一套官方的 Framework，而且它的特性要很像 Rails，于是 Zend Framework 诞生了，这在几乎没有框架概念的 PHP 中注入了一种新的活力，Rails 不光激起了 Java 世界的广泛关注，在无数个类 Rails 框架后面，Zend 从 PHP 官方的角度接受了 Rails 的思想，改善 PHP 的开发。而 Java 世界里，Grails 也伴随这 Groovy 1.5 的推出，伴随着 Grails 的第三个 RC 版，即将走到 1.0 版本。Rails 带给了 Web 开发无穷的活力。

　　老外对这方面的支持工作还是做的不错的，国内的同类系统往往只考虑到功能，好一点的考虑到性能，而在这些新技术带来的扩展性的增强上似乎没有太多的理解，虽然 WordPress 在功能上和国内的很多博客有一定的差距，但是人家支持插件，这样就可以让地球人都上来扩展一把。Eclipse 的插件风风火火的做了几年，现在人似乎没有不用插件开发的了。

　　老外在 Web 2.0 中又很多好的思想，技术，拿到国内来就有点变味了，虽说国人在 Web 2.0 技术上跟进的速度还是相当的快，不过思想还是又相当的差距的。

　　要好好学学人家做东西的思想，而不仅仅是技术。

　　一年前的时候，突然听说 Yahoo 可以和 MSN 互通了，于是从此就没用过 MSN 了，也是对 Microsoft 歧视国内用户的一种不满吧，这么多IM工具，最不稳定的也最为常用的要属 MSN 了，虽然飞信这样“国”字号的软件似乎更加的不争气，就原谅他吧，谁叫他是咱最有钱的移动运营商呢。可以说，MSN 的掉线率是相当的高，登录速度也是惊人的，在公司内部传文字的效率呢更加不用说了，反正没有人走的快。不过据我们去过美国的一些同事说，MSN 在美国速度是非常快的，包括其下属的 hotmail，MSN Space，怪不得这么被推崇了，不过没办法，毕竟是在国内，属于不被重视的使用群体，大不了就不用了，于是机子里再也没有出现过 MSN，所有重要的好友都加到 Yahoo 里了。

　　其实说来 Yahoo 也是个比较不争气的东西，功能嘛，没啥强的，不过吃内存的能力还挺强，印象中也就 Skype 可以和他有的一拼，不过好歹人家 Yahoo 还是比较重视中文用户的，起码光缆断的时候还是能用的，而且相关的本地化服务也还是有一定的可用性的，Yahoo的邮件提示是最为迅速的，基本上是新邮件来到5秒之内就得让你知道，这个功能还是挺体贴用户的，其实我的一些 IM 的一个重要作用就是 check email，比如说 Google Talk。Yahoo 的客户端程序其实是比较不稳定的，群聊功能是个杀手，一次领导通知事情，让大家开个会，结果一位老兄图方便，Yahoo 把大家全部加进来了，大家的机器全部死翘翘，只好 reset 重启，自此以后，这个功能再也不敢使用了，Yahoo 工具箱里有个看股市行情的插件，不过这个曲线也太不本地化了，中午休息的时间也画在上面，一条长长的直线，怎看都别扭。没办法啊，公司里唯一允许的 IM 工具，不得不装，也就不得不去忍受这些了。

　　Google Talk 其实是我用的最多的，极为简洁，拥有我需要的主要功能，email 通知，语音，文本聊天，传文件（大家都喜欢装中文版的，没这个功能，所以也基本找不到人传文件），其实还有一点重要的就是所有聊天记录都会保存在 Gmail 里，在哪都不会丢失，也很连贯，这对于我们经常讨论需求的人就不会有上句没下句的了。也不用担心聊天记录留在本地泄密。另外还有一点，传代码的时候绝对不会变成一堆笑脸什么的。Google Talk 其实功能上是相当有限的，但是我却非常喜欢，简洁就是美了。

　　下面隆重出场的是唯利是图、忘恩负义外加极端不安全的 QQ 了，如果不是这么多好友在里面，我是不会开 QQ 的，当然 QQ 作为国内用的最多的 IM 工具（其实叫他聊天工具更确切），QQ 还是有相当多的优势的，首先网络稳定性好，传文件速度快，有远程协助功能，语音质量也不错，可以看 IP（还不都是珊瑚虫的功劳，被忘恩负义的腾讯扼杀了），有群聊功能，也是最适合某些夜晚不甘寂寞的人寻找刺激的工具了，其他的功能我是不大能想到的了，更不用说去用了，所以嘛，QQ 对我来说，太大了，太花哨了，对公司来说也是的，基本上正规的公司，没有哪个不封 QQ 的，所以嘛，QQ 只能被远远的拒之于企业应用的门外，腾讯的 RTX 也就不是那么容易进入企业市场的，谁让你这么花哨，看了就不想好好工作了。

　　Skype 这个东西嘛，对我用处不大，自从充值卡被封事件以后就不再常开了，开会的时候才会去用，毕竟多人语音聊天功能还是挺不错的。

　　国外的大部分 IM 工具都开放互通了，包括 MSN 和 Yahoo，Google Talk 也在和 MS 谈互通的问题，国内的 IM 互通嘛，似乎完全不可能，国外那几家都不是靠 IM 吃饭的，腾讯就不一样了，如果不保持其 QQ 的占有率，疯狂的扼杀非“官方”的客户端，LumaQQ 这么优秀的跨平台解决方案也就被腾讯自己和谐掉了，最近对珊瑚虫下狠手也表示其在此方面的决心，呵呵，我的 QQ 从此不升级了。

    于是用 Java 写了一套简单的股市信息跟踪的小程序，Console 的，用于抓取相应的股市信息并显示到 console 中，谁也不会想到这个东西会是用来看股市的吧。

    这套小小的程序用到了几个非常简单的技术，HttpClient 和 正则表达式。程序功能非常简单，找到含有股市数据的页面，使用 HttpClient 抓取下来，通过正则表达式匹配自己需要的内容，在 Console 上打印出来。

    准备花两篇文章简单的介绍这个小系统中的实现细节，当然这只是简单的介绍，其实我们再稍微用点其他的技术，可以做出更多更实用的小工具。比如我就写了个小爬虫，把某个基金网站上的基金净值数据爬来了，足足有10W条，供我做基金形势分析之用，拿到这些原始数据，再动用一下自己的头脑，再配合一些方便的工具，比如 Excel，我们便可以用实际数据去辅助投资理财。

        首先我们来简单的介绍我们用到的第一个工具，HttpClient。

    HttpClient 是 Apache Jakarta Common 下的子项目，可以用来提供高效的、最新的、功能丰富的支持 HTTP 协议的客户端编程工具包，并且它支持 HTTP 协议最新的版本和建议。
    以下列出的是 HttpClient 提供的主要的功能，要知道更多详细的功能可以参见 HttpClient 的主页。
实现了所有 HTTP 的方法（GET,POST,PUT,HEAD 等）
支持自动转向
支持 HTTPS 协议
支持代理服务器等

HttpClient 可以在http://jakarta.apache.org/commons/httpclient/downloads.html下载

HttpClient 基本功能的使用
GET 方法
使用 HttpClient 需要以下 6 个步骤：
1. 创建 HttpClient 的实例
2. 创建某种连接方法的实例，在这里是 GetMethod。在 GetMethod 的构造函数中传入待连接的地址
3. 调用第一步中创建好的实例的 execute 方法来执行第二步中创建好的 method 实例
4. 读 response
5. 释放连接。无论执行方法是否成功，都必须释放连接
6. 对得到后的内容进行处理

根据以上步骤，我们来编写用GET方法来取得某网页内容的代码。

根据这样的过程，我们便可以写出一个简单的抓取页面的方法，该方法返回抓到的页面数据。传入的参数是页面的 URL。

protected String getURLResponse(String url) {
 try {
  HttpClient client = new HttpClient();
  GetMethod method = new GetMethod(url);
  int returnCode = client.executeMethod(method);
  String response = null;
  if (returnCode == 200) {
   response = EncodingUtil.getString(method.getResponseBody(), "gb2312");
  }
  method.releaseConnection();
  return decode(response);
 } catch (Exception e) {
  return null;
 }
}

HttpClient 是一个很实用的工具，用它，我们可以做很多和 Http 有关的事情。
大家可以参考： http://www.ibm.com/developerworks/cn/opensource/os-httpclient/ 来初步了解 HttpClient 的功能。
或是去找找 Jakarta.Commons.Cookbook 或者 Jakarta.Commons.Online.Bookshelf，上面介绍了包括 HttpClient 在内的很多 Apache Jakarta Commons 项目，相信合理使用，会让你事半功倍的。

下一篇我们将介绍一下如何用正则表达式处理我们抓取到的数据。

在网上做了一番搜索得到一些相关的内容。

PermGen space的全称是Permanent Generation space,是指内存的永久保存区域OutOfMemoryError: PermGen space从表面上看就是内存益出，解决方法也一定是加大内存。说说为什么会内存益出：这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。

改正方法，在 run.bat 中加入：-Xms256m -Xmx512m -XX:MaxNewSize=256m -XX:MaxPermSize=256m

因为项目中引用了很多的 jar 包，而这些 jar 包中的 class 信息会被 JBoss 的 class loader 加载到 PermGen space 区域，在 JVM 默认的情况下，该部分空间的大小只有 4M，在 jar 包非常多的情况下，显然是不够用的，所以通过 -XX:MaxPermSize=256m 指定最大值后即可解决问题。

另外，如果 heap 内存不足出现 java.lang.OutOfMemoryError: Java heap space 时，可以通过 -Xmx512m 指定最大 heap 内存来解决这样的问题。

其实 Confluence 的破解并不算难，不过在网上不是太容易找到直接能用的方案，小试了一把，发现最主要的是要处理一个 atlassian-extras-0.7.20.jar 的文件，com\atlassian\confluence\page 这下面有一个 Key.page 文件，其实这就是密钥文件了，破解的一般方法就是自己生成一个自己所知道 Key 的密钥文件，并替换掉原来的，再用这个已知的 Key 生成自己需要的密码。比 JIRA 要稍微复杂一点了。

附件里附上一个弄好的东西，直接替换已经安装的 lib 下的 atlassian-extras-0.7.20.jar 文件，然后用 keygen 生成 key 就可以用了。

下载地址见：http://www.agilejava.org/space/?1/action_viewspace_itemid_188.html

    对于分布式对象领域，EJB 3.0 还是有着不错的竞争优势的，毕竟这是他的传统优势，在群里面和大家聊天的时候，寒江也提到过用 RCP + EJB 3.0 作为方案，其实这也是一套不错的应用方案。

    EJB 3.0 比 EJB 2.0 确实要轻了很多，但并没有给我们太多的惊喜，因为 EJB 3.0 给我们带来的大部分新鲜都已经被 Spring 和 Hibernate 捷足先登了，我个人也是比较喜欢 Spring 和 Hibernate 来做项目，毕竟用起来会更加的灵活，更加的强大，特别是新版的 Spring 和 Hibernate 同时都支持了 JPA 的标准，又一次的在 JavaEE 应用上和 EJB 3.0 展开了下一轮的竞争，一切都好，就看你怎么选择，我选择的是 Spring + Hibernate，或许更加熟悉一些又或许更加轻量，更加 agile。

    过去一开始的时候，都是采用在网上选书，然后邮局汇款，发邮局包裹的方式，效率很低，也很麻烦，每次总是要往邮局跑两次，最大的问题是，网上列出来的书，往往是不一定有货的，有一次买书，选了一堆书最后发现就一本书有货，最后拿到手的只有那一本书，很是郁闷，这样就余下了一些钱在 dearbook，然后又用这些钱继续去买其它的书，最后在升级会员的时候，这些余款购买的书又没有记入积分中，升级的时候就差了这么几分，最后催了好几次才把自己会员资格提高。

    随着和当当网合作以后，付款和收货方面确实有很大的改善，付款直接用网上银行，直接送货上门，都大大的提高了我买书的兴趣，不过 dearbook 网站系统很不争气，频频出现问题，首先发现一个明显的 bug 就是在收藏夹里删除一些书籍的时候，收藏夹就变乱了，都是一些莫名其妙的书，再打开一下这个页面就好了。接着是在和 CSDN Passport 整合的时候，收藏夹里的书彻底丢光了，而这时候没有人告诉我怎么回事。

    在与当当网的合作中dearbook 的积分系统也频频出现问题，当当网是用 Email 账户登录的，dearbook 积分系统也是用 Email 账户登录的，当我修改了当当网的 Email 以后，dearbook 积分系统也换成了新的 Email，但原有 Email 对应积分没有转到新的 Email 帐号上来，打电话去问，答曰，没有提供合并积分的功能，于是一堆积分就泡汤了。

    最近积分比较多，在 dearbook 换了两本书，最后收包裹的时候，只收到一本书，觉得奇怪，打电话去问，才把第二本书给重新寄过来，浪费了我几分钟的电话费。

    这次 dearbook 又心血来潮的要把 D币积分转换为 C 币，因为过去在两个Email 账户上都是有积分的，所以想转换到同一个账户上，结果当我在 CSDN 上修改了 Email 地址后，却发现我过去的积分就消失了，很是郁闷。昨天发了邮件，今天打了电话，到现在也没有人给我答复，看了一下账户里的 C 币，还是不对。

    很多粗人都常常认为 UML 只是画图的东西，三两页就可以讲完的东西，何必弄这么多呢，还印出 n 多本书，简直就是骗钱了。其实说来，UML 难道仅仅是一种图形工具吗，它凝聚了更多更深刻的 OOP 的概念，在各种各样的应用中才发现，原来 UML 比我开始想想的要丰富的多。

    看过一些人在网上的评论，才发现，其实人民邮电出版社和机械工业出版社的书其实并不是太差了，只是机械的纸实在是说不过去，在我书架上放的一堆书中，原来清华大学出版社的书是最差的，无论从纸张，从排版，从翻译，因为有康博这样被骂死也还要出来招摇撞骗的所谓翻译团队。近些年来，一些出版社都开始建立了一些自己的图书品牌，比如说电子工业出版社的“博文视点”，比如人民邮电出版社的“图灵系列”，我个人感觉其中的书的选题和印刷都还不错，虽然也会有一些比较烂的作品出来了。

　　不过想想看，自己一直都在算是比较正规的软件企业，编码规范还是有一定的要求的，不会出现这么搞笑的问题，不过有些问题还是会经常的犯，比如说，又一次看一个同事写一个方法写了 1500 行，我立刻让他改，最后精简代码，分开写，也算是减少到可以接受的程度，另外一个恶习就是复制代码，很多开发人员自身都是不怎么会写代码的，做开发就是找过去相识的，复制，粘贴，改，所以会出现一堆比较搞笑的问题，于是，错误便不是自己犯的了，人家写错了，自己也就抄错了，我在第一次参加 Code Review 的时候就碰到这个情况，我自己的东西都是自己手工写的，出现了一些问题，被大家指出来了，其它人写的东西都是抄来抄去，发现问题都不是自己的，因为改过去的代码需要上面授权，还有一堆测试要重做，所以看大致是可以用的也就蒙混过关了，造成了越来越混乱的代码。

　　其实说来要把代码写的更好一点没有想象中那么难的，凡事从小做起，从点滴做起，慢慢的把一些好的东西变成自己的习惯，重要的是要积累，而不是放任自流，多去看看人家著名的开源项目，看看人家代码是怎么写的，多去和自己的比较，然后善于用一些 Audit 工具评估自己的代码，让自己对自己的代码中出现的问题有一个更明确的认识，然后慢慢的去改变自己的习惯，其实从长远角度来说对自己有很大的好处的，起码自己的编码能力提升了，基础更加稳固了，有能力去胜任更高级的工作，不然，天天复制别人的代码，自己又天天只能写出来一些不符合规范的代码，而自己又天天不去想不去问，一直这样下去，开发能力还能提高吗？

　　其实我还是很喜欢一本书《代码大全 2nd》，今年上半年才出来的中文版，里面针对我们开发的时候出现的问题给出了很多规范和解决方案，我会经常抽空去看看这本书，然后想想自己该如何去改善自己的开发习惯，去写出更好的代码，另外就是用一些 Audit 工具去针对自己的代码做出一些评审，比如 CodePro，另外我们一些同事在 Maven 上用一些插件对 CVS 上的代码做出 Audit 并发布在项目站点上，这些都是不错的手段了。

　　其实说来最重要的还是自己的态度，工具，好的方法都不能转变对于开发恶劣的态度的。

    虽然说讲的还不是很好了，但是这三天却给了我很大的提高，不仅仅是技术上面，更多的是在一种表达能力方面的。可以说是第一次真正意义上的上台讲东西了，因为面对的不光是同组熟悉的同事，还有很多不是太熟悉的，还有几位老大，甚至在最后一次讲JSF的时候，大老板还进来坐了一会，压力还是挺大的，虽然要讲的东西已经在之前在脑子里演练无数次了，但是要想把自己想的东西和别人讲清楚，的确不是那么容易的事情了，当发现下面的同事满脸的迷茫，就得赶紧换一个角度来说明问题，不过还算过得去的是，自己并没有太多的紧张了，虽然是第一次正式的在台上讲东西，面对面的对着大家，不过自己要讲的东西心里还比较有底，心里比较踏实了，于是也就没有太多的紧张了。

    通过三天对各个方面的技术的介绍和总结，其实也不知道大家真正能理解多少，因为太多东西没有经过实践是不会有太深刻的理解的，虽然有些东西当时是听懂了，但是却不会深深的刻进你的脑子，时间一长就忘记了。三天里，总结了这一年来我对 Java Web 开发的几个方面的理解了，虽然这一年学到了很多很多，但还有太多太多的不了解了，有些东西当自己看的时候觉得自己了解，但是当需要把这个东西和别人分享的时候，却发现自己有太多太多的不知道了。

StarTeam 对于我们最有价值的一件事要算是它的缓存机制了，对于跨地域的团队协作有不错的帮助，StarTeam 的缓存机制能够有效的加速 check out 文件的速度。对于两个在不同地点协作开发的团队，一般会通过专线互连，两边的机器都在同一个局域网内，但受到专线带宽的限制，速度还是会很慢的，过去使用 VSS 作为配置管理工具，从找到到 check out 出一个十几k的文件都要花上三分钟，用 CVS 因为在传输的过程中会进行压缩，有一点点的改善，不过还是比较慢的，当然 ClearCase 这样的东西更是慢的出奇了，一个小时都拿不了几个文件。缓存机制可以说是我感受到 StarTeam 对我们最大的好处了，check out 一个1M左右的 folder 一般只要 10 秒左右，主要原因还是因为 StarTeam 的 MPX 机制，当一个人 check out 一个远程文件，就会形成一个本地缓存，当本地的其它用户请求同样的文件，这时候就不再是从远程的服务器端获取，而是在本地这个缓存的机器上获取，感觉有点像 BT 的原理，竟然也用到这样的企业级开发应用中来了，比较的有意思。

虽然这个好处已经让 StarTeam 在我们这样的团队结构下发挥了很大的作用，不过它的一些操作上和细节上的问题还是很不能让人觉得爽，特别是以 Eclipse Plugin 形式发布的 Client，稳定性真的很差，经常莫名其妙的就与服务器失去连接，但同时开的 Windows Client 却一点问题没有，很稳定的在工作着。另外一方面，Plugin 的同步功能好像不够快，有人 check in 了一个文件，半天都看不到，但 Client 没有这个问题，立刻就刷新了。

Plugin 的同步功能还是挺好用的，感觉比 CVS 的同步要好用一些。直接点在项目的每一级文件夹下，直接就可以看到这个文件夹或 package 下有多少需要同步的文件，然后选中需要 check in / check out 的文件，Run 一下就可以了。不过 Run All 按钮在 Run 按钮旁边可能会有一些问题了，也造成了我们这边的一些错误操作，延误了一些时间。因为有人不小心删除了本地文件，同步的时候，会要求同时也删除服务器端的文件，点 Run 的时候不小心点到 Run All，服务器上的东西都没了，只好 rollback 了，花了不少的功夫。

    对 iCustomer 的理解慢慢的在加深，技术准备也到了差不多可以开工的程度了，只是心里对 Unit Test 部分不大放心，因为从来没有大规模的用过它，虽然对 XP 和 TDD 的以高度测试为中心的，但是对于传统的项目，这样的测试是很令人厌倦的，虽然说软件开发产出的是代码，但是，从来没有人敢否认测试的重要性，之所谓“软件质量是测出来的”也正是这么回事。

    一直向往着开源，向往着新的软件开发模式，一种轻松自由的，充分发挥人的作用的模式。开源为我们带来了很多，甚至在改变着软件世界的格局，从 Linux 从一开始就改变了世界，Apache 的应用无处不在，在 Java 世界 Hibernate 改变着 Java 的标准，Spring 在自己的领域不断发展，推动了整个 J2EE 的进步，JBoss 即将被 Oracle 收购的消息也显示出大型商业公司对开源的关注程度，开源不仅仅是免费的代码，更主要的是，它已经成为一种文化，悄悄的改变着世界。

同时想想看公司里做软件的经验也是，几乎不会在一个新项目里全面的去使用一系列的新技术，因为对这些技术的不确定因素，会让项目整体的不确定因素变的比较大，如果协调不好的话可能会导致整体的崩盘，所以在新的项目中通常是每次使用一种新技术替换原有的，其它继续使用原有的技术，并且在项目中积累使用这种技术的经验，通过这样的不断累积，变的对这种技术比较熟悉，这些积累再应用到新到项目中，会让不确定因素会变的比较小一点，也比较容易保证软件开发的成功。试想如果全面使用新技术的话，如果在几个问题上卡壳了，或者有这种技术无法满足到需求，可能会有比较严重的后果。

技术是需要经过一段时间的沉淀才会被广泛使用的，无数的开源框架应证这这点，像spring，hibernate被广泛的使用并不是在它们刚推出的时候，而是在不断的应用中改进，并且逐步成熟的时候。现在炒的正火的Ajax，Ruby on Rails等技术并没有大范围的使用，也是这种原因了，虽然它们都很吸引人，但是并没有多少经验表明这些技术会引发多少的不确定因素，大家都在等啊，等啊，等到有人用实践告诉我们准确答案的时候，才会是它们真正被大家接受的时候。