Agile

看到这个题目吓了一跳，竟然有这种事，记在这里，敲个警钟。

HashMap.get() can cause an infinite loop!

http://www.ibm.com/developerworks/cn/java/j-concurrent/ 

从一个Blog上看到的一些很不错的建议: 10 Ways to Learn New Things in Development .

摘要如下，记在这里，让自己能经常想起它们并坚持做到. 

1. Read books

2. Read Code.

3. Write Code

4. Talk to other developers 

5. Teach others

6. Listen to podcasts

7. Read blogs

8. Learn a new language

9. Learn the anti-patterns

10. Be Humble

对Groovy为什么比Java慢的一个比较好的分析Why is Groovy so slow?

作者提到了MOP（猫扑?呵呵），以前一直觉得这个东西会降低一些性能，看了这个blog之后，确信不疑了。

 

周末在家里看到A hash set puzzler ，我想了一下，用反射，但又感觉不靠谱 :(

可天杀的作者一直在卖关子，我这两天时不时的看一下有没有更新，快点公布答案吧。

或者有高手可以告诉我一下，我将非常感.

2007-12-25 更新：

 作者给出了一个最好的答案：

final Object[] foo = new Object[]{null};

set.contains(new Object() {

public int hashCode() {

return bar.hashCode();

}

public boolean equals(Object other) {

return bar.equals(foo[0]=other));

}

});
foo[0];

 这个办法太棒了，超赞。

我的解法也有人用，就是使用反射，作者对这个法子的评价是：

"The next popular variant was to use reflection to call package-protected method on the HashMap holded by the HashSet instance (it would work, but it is not as elegant as above version)."

 不够优雅 :(

什么叫Beautiful Code,这就是。 :) 

安心睡觉了。 

 

Did escape analysis escape from Java 6?

 晚上我的笔记本突然崩溃了，xp启动不了了，修复的过程中看到了上面这个文章。

文章的大意是说escape analysis在jdk6中的实现并不好，有些优化还没有实现。

我依照他提供的测试代码，也做了些测试。

不同的地方是我把整个测试提取到单独的方法里，在main里运行了20次，

java -server -XX:+DoEscapeAnalysis -XX:+EliminateLocks -XX:-UseBiasedLocking LockTest

测试结果如下：

StringBuffer: 3681 ms.

StringBuilder: 3409 ms.

Thread safety overhead of StringBuffer: 7%



StringBuffer: 3507 ms.

StringBuilder: 3384 ms.

Thread safety overhead of StringBuffer: 3%



StringBuffer: 3488 ms.

StringBuilder: 3517 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3521 ms.

StringBuilder: 3510 ms.

Thread safety overhead of StringBuffer: 0%



StringBuffer: 3494 ms.

StringBuilder: 3506 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3507 ms.

StringBuilder: 3548 ms.

Thread safety overhead of StringBuffer: -2%



StringBuffer: 3489 ms.

StringBuilder: 3497 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3505 ms.

StringBuilder: 3503 ms.

Thread safety overhead of StringBuffer: 0%



StringBuffer: 3494 ms.

StringBuilder: 3505 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3488 ms.

StringBuilder: 3513 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3495 ms.

StringBuilder: 3507 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3500 ms.

StringBuilder: 3515 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3493 ms.

StringBuilder: 3525 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3508 ms.

StringBuilder: 3561 ms.

Thread safety overhead of StringBuffer: -2%



StringBuffer: 3499 ms.

StringBuilder: 3517 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3526 ms.

StringBuilder: 3516 ms.

Thread safety overhead of StringBuffer: 0%



StringBuffer: 3511 ms.

StringBuilder: 3512 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3524 ms.

StringBuilder: 3533 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3517 ms.

StringBuilder: 3520 ms.

Thread safety overhead of StringBuffer: -1%



StringBuffer: 3538 ms.

StringBuilder: 3526 ms.

Thread safety overhead of StringBuffer: 0%

 

从结果看，StringBuffer在多数情况下的性能反而要比StringBuilder要好一点点，或者是持平。

不能说原作者的结论不对，因为我对这几个参数的研究很浅。

但是从另一个方面说，对java做性能测试，影响测试结果的因素很多，如果作者看到这个结果那又该下什么结论呢？

现在的jvm越来越智能了，同样的程序在不同的环境下运行 ，它可能选择它认为最好的优化方式进行优化，进而就可能导致不同的结果，有待深入学习研究。

写完这个Blog,xp终于恢复了，没把老婆的数据给弄掉了，万幸。 

 

Guillaume Laforge谈Groovy和DSL 

文章里的视频看不了，但是下面有采访的翻译，还不错。如下：

这里是位于QCon(InfoQ和JAOO组织的技术大会)的Floyd Marinescu和Guillaume Laforge。Guillaume，可以向我们做一个简短的自我介绍吗？
我叫Guillaume Laforge，Groovy团队的项目经理，同时也是JSR 241规范的领导者，JSR 241规范制定了Groovy编程语言的标准。在我的职业生涯里，我是OCTO科技公司的软件架构师，OCTO科技是一家专注于软件架构和敏捷方法学的咨询公司，这也是我为什么乐意参加由InfoQ组织的QCon会议的原因。
Guillaume，是你拯救了Groovy。
是的，几年前Groovy项目一直停滞不前，毫无进展，我们需要有所措施。自从前任项目经理离开 Groovy去参与其它项目，我便接手了项目的领导。我尝试吸引新的开发人员加入，以为项目和社区注入新的活力。我认为努力的结果是相当好的，因为在过去的一个月和过去的一年里，Groovy和Grails都发生了很多变化，而且在未来的时间里你可以看到更多的惊喜。
为什么对于Java来说Groovy是重要的？为什么你为Groovy项目投入了如此多的私人时间？
当初，在我加入Groovy项目之前的两个月里，我一直在编写一个应用程序，用户通过它可以在界面中定制一些窗口小部件（widgets）。最初你只能通过Java来创建它们，并且使用时必须重新部署应用程序而不能在运行中动态地完成创建。这的确让我非常厌烦，我想“如果Java中能提供脚本以支持动态创建就好了”。这时Groovy出现了，我看着它想道：“哦，这太有趣了，我要把它整合到我的Java应用程序中去”。我将业务逻辑、窗口小部件和一些配置项暴露（externalize）至Groovy程序中，然后通过XML传回Java程序，并使用一些编程约束来配置应用程序或者做得更多。如果你在暴露业务逻辑，就可以进一步借助Groovy可塑的语法和动态特性创建自有的领域特定语言。
你认为Groovy最适合用在Java项目的那些地方？
我想到一个案例，美国有一家很大的保险公司，财富杂志评出的世界500强之一，曾经构建了一个非常庞大的保险应用软件来处理健康保险以及其它保险的风险，其中用了大约45000行Groovy程序编写所有的业务逻辑——所有执行动作的规则以及如何计算某个产品或者保险单的风险。公司里的业务专家们甚至也亲手参与编写了一些规则。能将业务逻辑从Java开发组编写的代码中提取出来是相当有意义的，这使得开发人员和业务专家可以一起协作。这相当有趣，也是一个很好的用例，它说明了你应该如何在Java中使用Groovy。我认为我们会看到越来越多类似的在Java 应用程序中使用脚本语言或者动态语言的例子。
Groovy在Java还有没有其它好的用处？
你可以将Groovy用在很多领域，例如你可以用它做脚本任务（scripting tasks），就像在Linux上使用其它脚本语言那样。有趣的是，你不仅可以像使用其它脚本语言那样使用Groovy，而且可以使用所有能得到的 Java库。假如你有一些处理特定业务的Java库，现在想在Groovy中重用它们来解析一些文件或者来自遗留系统的东西，这可以轻松做到。你甚至还可以用Groovy构建一些小型应用的原型。

三个主要的用例是脚本任务，集成Groovy到Java应用程序中来外部化我前面提到的东西，还有编写完整的（full blown）应用。我想到了另外一个例子：法国司法行政部在构建应用的时候用到了Groovy。这个应用包含一个UML模型——其中存放着法官、法庭和其它各种各样的领域对象，都是通过UML设计得到的——提取为XML格式的XMI模型。通过使用Groovy模板和Groovy胶水(glue)程序，他们创建出了应用程序所需的所有内容，如JSP页面、应用程序的流程（从哪个页面跳转到哪个页面，从这个线程动作中输出结果到哪个视图）。最终的应用中没有一行 Groovy代码，但是他们借助Groovy加快了开发速度。
从哪些方面能够明显地看出Groovy正在被Java社区所采用？
Groovy得到了很好的使用，因为我们已经有了许多令人感兴趣的Groovy商业用例。尤其当我们发布了1.0版本之后，我们得到了更多的使用者，订阅我们邮件列表的用户大概是以往的两倍多，越来越多的下载量还有越来越多的人跑来咨询问题。你可以看出这其中有很多新用户，因为他们的问题差不多都是“我该怎么做（各种各样的事情）？”。可以看到自从我们发布了1.0版本，我们取得了成功。而且如果你仔细观察blog网络社区（blogosphere），就会看到每天都有很多关于Groovy和Grails的文章，这有点儿疯狂，不过确实发展显著。甚至在类似于“你更喜欢哪种脚本语言？”的调查中，Groovy也通常都名列榜首。我为成功的来临感到愉悦满足。
为什么Java社区开始关注脚本语言了？
这非常有趣，因为脚本语言已经存在很长一段时间了，事实上那些语言过去一直是作为独立的普通语言来使用的，并没有和Java结合起来。现在有了很大的不同，因为在JVM上有很多可用的语言，所以你可以混合和协调不同的语言，分离不同的程序元素，使用更有表达力的方式定义规则。当然我们也可以看到，脚本语言倍受关注与Ruby和Ruby on Rails的成功有着重要关系。我不能确切地告诉你为什么脚本语言开始受到关注，但是我认为JVM之上的脚本语言的出现，还有围绕在Ruby和其它明星脚本语言周围的讨论都起到了作用。
说到了Ruby，现在看来当Java开发人员想编写脚本的时候，似乎有两个流行的平台可供选择。那应该如何在Groovy和JRuby之间做出选择呢？
对这个问题，我得出一个规律。如果你会使用 Java，那就选择Groovy，因为它的语法与Java相似，而且还可以和Java平台以及Java库无缝集成。Groovy有着和Java相同的面向对象模型、相同的库，还有相同的正则表达式。如果你选择JRuby以便继续停留在JVM上，那选择JRuby之前最好你已经熟悉了Ruby。例如如果有些人精通Ruby，那他们可能直接会选择JRuby。但是如果他们想与Java紧密集成，那么最好选择Groovy，因为它与Java有完全相同的对象模型，这两个不同的语言，不同的范式之间不存在阻抗不匹配（impedance mismatch）。所以我的原则就是：如果你了解Ruby，那么使用JRuby；如果你更喜欢类Java的语言，那就选择Groovy。
你注意到Groovy使得DSL编程在Java中变得流行了吗？
是的，我注意到了。因为Groovy所有的动态特性使得编写类似“3.euros”、“48.dollars”或者“3.days.ago”的表达式变得很容易。你能够编写表达力非常强的东西；你能创建对专业领域、业务概念等进行建模的迷你语言（mini-languages）。虽然已经有了“IF”、“FOR”和“WHILE”循环等控制结构，只要你愿意，你还能创建属于自己的控制结构，Groovy在这方面非常灵活。我认为，那些试图将Ruby嵌入到应用程序业务规则中的人们，更趋向于用一种更简单的语言来对专业领域进行建模，业务人员和开发人员共同分享包含了业务描述的隐喻，使协作更加容易。了解如何使用动态语言为建模和领域定义特定语言是相当让人感兴趣的。
动态语言的哪些特性使得它们比Java更适合定义DSL？
Java属于静态类型语言，使用Java你需要编译器——在Groovy中也有一个编译器——确实是这样的，当你编译Java代码的时候，所有的东西都被编译器硬连接（hard-wired）起来。所以你不可能轻易地拦截方法调用、属性访问或者重写（overwrite ）类似操作一样的东西。这非常不灵活，即使你可以编写一些连续接口（fluent interfaces）来使得Java代码更易读，你通常还会有一些样板代码（boilerplate technical code）[译注：样板代码指的是在程序中重复出现的极其类似的代码块，这部分代码往往与业务无关，而且又必不可少，不如异常处理、日志记录、应用环境相关的数据传递和持久化等等。这些代码往往编写费劲而且可读性差难以维护（例如异常处理代码块）。]影响可读性，并且通常不会有业务人员站在你后面：“嗨，这个规则不应是这样的，而应该是那样”。然而从另一方面，使用动态语言，你可以捕获方法加入方法拦截，给已存在的JDK类或者数值加入新的方法，就像我前面提到的例子那样“3.dollars”就得到了一些钱。在Java中不可能这样做——3仅仅是简单类型，你不能在上面做文章来创建有用的东西。所以最终通过动态语言的元编程工具（这是Java中所没有的），你完全可以发挥想象创建一个带有新约束的语言。正因为它的强大功能，Java才会禁止这么做。
Groovy社区当今所面临的最重要的问题是什么？
我认为目前影响Groovy普及的最大问题是缺少工具支持，尤其是IDE支持，因为Java开发者往往习惯于使用快捷键ctrl-space带来的代码自动完成（code completion）功能，而不必去查找JavaDoc或者APIs的相关文档。2007年我们工作中很重要一个方面就是提供工具支持，而且我们已经拥有了一个较大的团队从事Eclipse插件开发，在接下来的几周或几个月里，就可以使用具有Groovy代码自动完成功能的Eclipse插件，使得 Eclipse中编写Groovy代码变得更加容易。

JetBrains的工作人员想在IntelliJ IDE中添加对Groovy的支持，他们为此已经跟我取得了联系。正如大家所知，他们非常擅长为语言提供杰出的支持，比如JavaScript和 Ruby，我也确信他们能够为Groovy提供很多令人惊奇的功能，比如代码自动完成，甚至重构。有了IDE的强力支持，你可以混合和协调地使用Java 和Groovy而且包括重构功能。这确实是今年我们不得不关注的工作，并且已经有了显著的进展，在年底之前我们应该会得到一些优良的工具支持。总之这绝对是我们需要继续努力的主要方面。
你特别喜欢哪两本计算机书籍？
《程序员修炼之道（Pragmatic Programmer）》是我特别喜欢的书籍之一——它确实是我喜欢阅读的著作之一。实际上我还想到了另外两本，一本是《Groovy实战》，我是该书的合著者之一，自然对其有一点儿偏向，不过它的确是一本好书。如果你在寻找一本关于Groovy的参考书，想了解语言的所有内部工作方式、类库以及编程工具，它就是一本非常棒的书。如果非要提及第三本，那就是由Graeme Rocher撰写的讨论Web框架Grails的《Grails权威指南》。

 

Hashtables, Pigeonholes, and Birthdays

一个非常不错的请Hashtable方面的文章，值得一读。 

自从用上了Ubuntu,使用GNome桌面发现是越来越慢，特别是FireFox,时常占用cpu在90%以上．

刚刚在网上搜索了一下解决的办法，已经有高人提供了一个教程帮助我们来提高Ubuntu的性能,这个教程里

讲的东西在其它的Linux版本上应该也是可借鉴的.

我只是试了其中了两项,以下是从http://www.forwind.cn/2007/05/10/ubuntu-howto-improve/2/摘录的：

2. 长期使用 Ubuntu 后有一种感觉，那就是在 GNOME 中启动应用程序时，速度越来越慢。在 Ubuntu 英文论坛那边看到一个技巧，可以对这个问题起到改善作用。打开 /etc/hosts 文件，可以看到类似下面的内容：

127.0.0.1 localhost
127.0.1.1 windstorm

现在，只需在第一行的末尾加上主机名即可

127.0.0.1 localhost windstorm
127.0.1.1 windstorm

保存后，重启系统，更改生效。

3. Pango是一个着重于国际化的，用于输出和文本渲染的库，但是这个库可能导致firefox等一些程序有着过高的cpu占用资源。我们可以

sudo vim /etc/environment

然后在其中添加:
MOZ_DISABLE_PANGO=”1″

这样就可以禁用Pango了。

将这两项修改之后，重起系统，发现系统的速度明显快了许多，通过vncviewer连接上之后，也没有明显的

停顿现象，赞一个. 

特别是FireFox的速度也快了，原来我一直在冤枉MJia同学(Mozilla中国的四号人物)，一见到他就和他抱怨Firefox在Linux下表现不好，

速度很慢，下回见了得向他澄清一下，也可以告别w3m了，呵呵.

和我有类似情况的朋友们，可以试着改一下，可能会有帮助~_~

刚装了RealPlayer在Ubuntu7.10上，在播放rmvb文件时声音和画面不同步，而且非常明显的感觉到卡的厉害。 Google了一下，找到了一个解决办法: http://www.cnitblog.com/lywaml/archive/2005/06/14/402.aspx 试着运行:aoss realplay aoss 命令未找到 先装aoss: sudo apt-get install alsa-oss 安装成功之后，再运行 aoss realplay,播放完美了，呵呵。