@西津渡
我已经受到了很多关于简洁的批评。

也提醒我，对他人的简洁的文档，一定要全神贯注。

上士闻道，勤而行之；中士闻道，若存若亡；下士闻道，大笑之。不笑不足以为道。

独登高楼，望尽天涯路。
以此为记。

@西津渡
我最后还是确认了我的结论.
参见:http://jimcgnu.javaeye.com/blog/54469

这是文中的测试结果。

Java C++
Fibonacci 10767 ms 7468 ms
Heapsort 5454 ms 4344 ms
NestedLoops 8022 ms 3453 ms
CopyData 1204 ms 1125 ms

代码也是有的。

引用：
I would admit that it is correct to say java is slower than c++ when it comes to primitve datatypes and optimizing nested loops but there are real objects also where the numbers may change somewhat. In fact it will depend upon the tasks.

顺便，说一声：
我是试图对比 bdb c edition vs java edition 's benchmark 的时候，发现这篇文档的。

@abc
写java 系统级的程序员很少。

类似的系统指：
tomcat,jboss 之类的中间件
hadoop 之类的分布式系统
Tangosol Coherence 之类的cluster 软件。

所以，我似乎提出了错误的论题。

空洞

试下oci直接路径装载数据，看还是不是20%的差距，没索引的情况下应该是数量级的差距
C++，java看怎么比，写得好的java比烂c++快也很正常
GC不要谈了，论效率和c++自己处理没得比，论内存消耗也没得比
java优势在web，分布式上，在应用层很合适，c++和c在系统级合适，用来在server端处理压力最大的部分比较合适，如果是处理记录数目在10k/s级别的应用上c++比java优势大

空洞，不严谨。

请教zookeeper for hdfs and hbase具体如何用？

看了之后，感觉受益匪浅，真的是有相当的经验才能写的出啊。谢谢。

呵呵，看来咱们关注的东西还是不同的。
我更多关注这个应用，可能你关注更多的是技术。

我本人对垂直搜索比较有兴趣，只不过不仅仅是搜索，而是对这些数据进行分析，给用户提供处理后，并分析好的数据！更多是数据挖掘的层面。

现在大部分都是抓取、处理。做分析的貌似不多，至少我还没看到过。

@车夫
直接一点：
gwt,javascript,flex, java Fx ,等等，无非是提高web2.0 的生产效率（etc,可用性，等等），who is next killer?

gfs,kfs ,etc 无非是提高server 端的廉价存储能力，how can i?
hadoop,ec2(?),无非是提供server 端的廉价海量计算能力，how can i?

呵呵，为了回复这个帖子，我搜了不少东西：
web2.0的定义：Web2.0，是相对Web1.0（2003年以前的互联网模式）的新的一类互联网应用的统称，是一次从核心内容到外部应用的革命。由Web1.0单纯通过网络浏览器浏览html网页模式向内容更丰富、联系性更强、工具性更强的Web2.0互联网模式的发展已经成为互联网新的发展趋势。
Web1.0到Web2.0的转变，具体的说，从模式上是单纯的“读”向“写”、“共同建设”发展；
这么看的话，web2.0只是怎么用，从技术角度看可能没太多可讨论的东西吧？我了解的也不深入，所以只是我个人意见。我只知道所谓web2.0的网站相对比较简洁，前台多用DIV+CSS了。后台貌似还是那些东西吧，大网站架构可能还是差不多的。使用ajax或者xml相关的东西，这确实在我5年前接触做网站的时候就用过的。应该不新奇。

云计算，这个东西就更直接了，我没搜索，但我理解这个意思。在5年前这个东西叫ASP（APPLICATION SERVICE PROVIDER），现在叫SAAS。但说白了就是不用你企业自己买硬件搭环境，也不用人维护，你租我的，我还帮你维护。这些软件提供商应该就是云计算的服务提供商了吧。至于云计算这个硬件和网络平台，那就是IBM和SUN还是HP的这些服务器提供商的天下了。所以他们非常主推这个东西，就是因为会有大量的买服务器的需求！而且都是大订单的。我觉得这个纯粹是个商业的新名词！其实一直都不缺乏！租用模式其实对客户来说确实有好处的。只是哪些应用适合云计算，还不知道。GOOGLE现在就已经是云计算了，他要干的活，恐怕就是提供技术解决方案吧，这也是一笔不错的钱景。

注释是写给自己看的。

无意进得贵宝地，看来大侠是镇江老乡

太感谢了、

啥意思？

写的不错

字体排版有点乱

今天又增加了部分图形。
增加了效率关键指标。

总结的不错，都来自实践的精华。
大部分总结的都是对事情的管理，对人员的管理总结的相对来说比较少（你不是说过“所有的管理都是对人的管理”吗？）

很有个性的总结，COOL，不错。

fdsfdsfffddf

今天上传了一个修订本。

呵呵，BeanSoft功德无量啦。

word 文档, 未发现病毒, 文本内容摘要如下:
李建奇图解软件项目管理
李建奇
2007-02
第一章 4个要素-What，how，who，when.
What- 从幻想到specification
How- 从架构到code
Who-谁？
When- 何时？

第二章 过程
一、 娶妻

从一个模糊的想法（imagination，vision），到形成若干条件(specification)，最后找到几个人选(prototype)。
 Vision
 Spec
 prototype
二、 火星飞行器

从一个解决的办法（solution ,idea），到验证关键技术问题(prototype)，最后到架构设计(architect)。
 Solution
 Prototype
 architect
第三章 设计系统功能,形成spec
一、 最重要的是使用它
Spec 是让人使用的。(customer，manager,本人，designer, architect , programmer, tester, user ,etc)

信任是最重要的使用条件！

二、 最重要的创造性工作
对大部分项目，设计Spec 是具有挑战性的创造性工作。


三、 产品有用最重要
一般情况下，性能问题都可以在架构设计阶段考虑。


四、 比较才知道优劣
至少有一种可以比较的方案。


第四章 设计系统UI
一、 一幅图胜过千句话
UI 原型是 Spec 的最好的解释。

 草稿
 主要的window
 prototype
二、 比较才知道优劣

第五章 系统技术原型
一、 关键的技术问题

第六章 系统架构和软件架构
一、 功能可扩展




二、 性能可扩展

第七章 风险
一、 设计风险


二、 技术风险


三、 所有的风险是人的风险


四、 最重要的是记住70%以上的项目以失败告终

让项目成功，或者尽早结束！

第八章 保持项目的进展
一、 对项目负责，做出决定

二、 执行，并检查
第九章 总结经验

ERTERTRT

当然欢迎改变了，不改变就没有生命力了。

以下论述：没有来得及仔细核对资料：
比如 struts1 ，原班人马很多都去了 shale，改变是巨大的。如果追随一个expert
的话，struts1 的追随者，应该去 shale ，而不是 struts2.

Tapestry是好,我也一直看好,不过Tapestry5的基本核心又要变了,作者在介绍Tapestry5时,说的第一句话就是Tapestry4升级到Tapestry5不是一个简单的事.巨郁闷.既然选择了Tapestry,那就等待吧.希望5以后能稳定下来.至少不要再变核心的东西了.

rails 刚试用了一下 建个表 几个命令就出来了一个crud 确实不错
只是数据库操作好象有点慢 不知道是否是在window下的原因
打算自己应用一下

spring,hibernate,webwork,dwr ,ehcache ,castor,xfire，acegi ,dbcp(c3p0),log4j,ant,displayTag ,clickstream ,infoma ,etc.
这么一堆 有点头大

displayTag 为什么不用下valuelist extreme