你才知道啊。老大，我早说不要去了吧。呵呵。

哇赛！这你都知道，真了不起，好，再来！～

再给你三句话，分别猜一个药品/保健品的名字：
1。乌龟盖了一所房子，然后住进去。
2。乌龟把刚才那所房子拆了，然后又盖了一所房子，然后住进去。
3。乌龟又把刚才那所房子拆了，然后又盖了一所房子，然后又住进去！

答案见下期。
^_^

现在，Eclipse基本上已经完成了所有大型软件开发产品的天下归一。。。。。。。等等，还有两个公司——也只有这两个公司不愿意接受Eclipse，他们是～～～～SUN～～～和～～～～Microsoft！！

^_^

陈叙远？你是人机工程部的吗？我在南京，不能上公司的内部网，你能跟我用邮件联系吗？

泡泡

是的，三种说法各有各的道理，所以他们是三个不同的学科，或者三个不同的环节，但是总有些人把他们混淆，或者不承认存在其中的一种UI，本文是想给这些人多一种选择吧。

好，现在饿补大众文化：给你三句话，分别猜一个歌星的名字：
1。猪从猪圈里跑出来了，怎么办？
2。猪又从猪圈里跑出来了，怎么办？
3。猪再次从猪圈里跑出来了，怎么办？

^_^

P.S. 然后他们还会取一个特别吸引人的标题！

一流的公司做标准，二流的公司做服务，三流的公司卖产品，四流的公司写软件！

我们公司界与三流和四流之间，不过比KD好，他们只是四流公司。

您好，我是BlogJava的管理员，欢迎来到BlogJava！

我很喜欢您的Blog，而且我越来越发觉我们有着某些相似的爱好，Aspect，Tiger，Persistence等等，如果您有时间，欢迎来我的Blog看看，谢谢。

Brian Sun

支持你，现在只是精神上支持你，有时间的话可以帮你写点代码（物质上支持）。

目前博客园、BlogJava和博客生活的团队功能还不太好玩，只是可以相当于一个多人的Blog，每个注册上去的人都可以发文章跟随笔，以后会向Wiki方向发展。谢谢大家的支持。

顺便说一句，本人已经被提升为BlogJava的管理员，庆祝一下，^_^。

哦，这说明俺不怎么上那些无聊的网站罗，呵呵。

例子：面向方面语言

A: 面向对象语言
B: AspectJ 1
B1: AspectJ 2
B2: AspectWerkz
C: AspectJ 5

例子：Java的持久化问题

A: 二进制序列化
B: Entity Bean
B1: EJB 2.x/容器托管
B2: Hibernate
B3: JDO
C: 还不敢肯定，可能会是EJB 3.0
D: 可能会是JDO 2.0

吉安人，这你都知道。。。。

所以这就是Plato的洞穴寓言所要说的事。

哇赛，知音啊，我也是一直在用3.0.1版，觉得这个版本比较成熟，比较稳定，比现在最近版3.1M4或者3.1M5a好多了！

自我批评一下，由于没有经过认真仔细的调查，犯了巨大的错误，其实上面所谓的第五条BlogJava目前已经做的很好了。真是“不调查就没有发言权”！老毛讲的一点都不错！

目前的BlogJava不仅可以被Google很好的搜到（新文章大约要等3～4天才可以），而且还可以反向搜索！：）比如我的首页用Google反向搜索可以搜到Blog里面的具体文章，用Yahoo的反向搜索还可以搜到我的几个好友的Blog！（包括dudu）。这也是Yahoo在我心目中首次超过Google！

唉，俺们都是程序员，哪有那么多搞笑细胞，好不容易搞两个笑话，还是从别人那里拷来的，你还笑俺，太没人性了！真是地道的吉安人！

据说JDO2.0已经获得了通过，下面是第二次投票的结果:

JSR #243
Java^TM Data Objects 2.0 - An Extension to the JDO specification
Public Review Reconsideration Ballot

These are the final results of the Public Review Reconsideration Ballot for JSR #243. The Executive Committee for SE/EE has approved this ballot.

Votes

SE/EE Apache Software Foundation Apple Computer, Inc. BEA Systems Borland Software Corporation Fujitsu Limited Google Inc. Hewlett-Packard IBM IONA Technologies PLC Intel Corp. JBoss, Inc. Lea, Doug Nortel Networks Oracle SAP AG Sun Microsystems, Inc.

Icon Legend Yes No Abstain Not voted

---

View Vote Log

SE/EE
On 2005-02-22 Sun Microsystems, Inc. voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-28 Intel Corp. voted Yes with the following comment: An agreement between the Spec Leads of 2 Expert Groups is not binding on the Executive Committee. That said, the extra time for review has demonstrated that the JSR 243 Public Draft is consistent with the "letter" from the Spec Leads so there is no problem there in any case. In similar situations in the future, it would be better to use the usual process of initiating a new JSR rather than a letter from Spec Leads. That would provide more transparency and involvement of the community. ------------------------------------------------------------------------------ On 2005-02-22 Google Inc. voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-22 Apache Software Foundation voted Yes with the following comment: Let a thousand flowers bloom :) ------------------------------------------------------------------------------ On 2005-02-23 Lea, Doug voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-23 Nortel Networks voted Yes with the following comment: Nortel supports the JDO Technology and its ongoing use. ------------------------------------------------------------------------------ On 2005-02-25 IONA Technologies PLC voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-27 JBoss, Inc. voted Abstain with the following comment: Since this newly proposed specification is essentially identical to the one proposed during the Public Review Ballot vote, we would see no reason to change our vote, hence our previous comment remains. However, while this vote is fundamentally a NO vote, we cast it as an ABSTAIN to acknowledge Sun's role in trying to clarify the situation through their FAQ, and most specifically the central role of persistence in the JSR-220 specification and in the Java platform as a whole: "The new persistence API as defined by JSR 220 will be the standard Java persistence API going forward.". This JSR-243/JSR-220 discussion, initiated by some JSR-243 proponents, has only brought disruption on the JSR-220 side and no sign of flexibility on the JSR-243 side. This could give the feeling of a coup to slow down the JSR-220 EG. The J2EE/EJB specification set represents the significant part of today?s Java ecosystem. Hence, in order to remain competitive, it is critical to make sure these specifications don?t get disrupted. ------------------------------------------------------------------------------ On 2005-02-28 Hewlett-Packard voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-28 BEA Systems voted Yes with the following comment: After further review, BEA has concluded that there is a vibrant JDO community which needs this specification, regardless of whether we are successful in achieving an overarching persistence strategy. As a result, I see no reason to hold this community hostage to a goal that may or may not be achieved. ------------------------------------------------------------------------------ On 2005-02-28 Oracle voted Abstain with the following comment: Oracle's primary concern has been partially addressed with the FAQ published by Sun reiterating that JSR 220 is the intended standard Java persistence API moving forward. Given the clear direction set by Sun on this issue, we will not object to the evolution of the specification to serve the existing JDO community. It is vital that the persistence work in JSR 220/EJB 3.0 for the mainstream J2EE community not be disrupted. EGB 3.0 is making excellent progress as part of the umbrella J2EE 5.0 specification and has been well received. ------------------------------------------------------------------------------ On 2005-02-28 IBM voted Abstain with no comment. ------------------------------------------------------------------------------ On 2005-02-28 SAP AG voted Yes with the following comment: SAP thanks the JSR 220 and JSR 243 Spec Leads for the additional clarifications that were provided for this reconsideration ballot. We are satisfied with the clarifications regarding the future roadmap of EJB 3, JDO 2 and the new J2SE persistence model that is being developed as part of JSR 220 and therefore do not see an impediment for JDO 2 to proceed. Given that JSR 220 has the challenging goal to deliver an overarching persistence strategy for Java, it is important that the interests of all existing persistence communities, including JDO, are equally represented in this Expert Group. ------------------------------------------------------------------------------ On 2005-02-28 Borland Software Corporation voted Yes with no comment. ------------------------------------------------------------------------------ On 2005-02-28 Fujitsu Limited voted Yes with no comment. ------------------------------------------------------------------------------

最近用了一下wiki，感觉不是很好用，即使是最权威的MediaWiki也不太好用，但愿dudu能开发出一个让我们大家收益非潜的wiki系统来。
呵呵。

发到我的邮箱里来吧，挺有意思的。Gmail的邮箱。

你指的是哪个广告？有什么意思？

辩论出现在软件开发中的几个场景：

1。偷换概念。“你说的这不是xx，我说的那个才是xx”

2。将概念外延一味扩大。“我所说的xx包括yy和zz，所以你还没理解我的意思”

3。主题转移。“对于用户来说是xx，但是对于开发人员来说却不是xx，而是yy”

4。打比方。（这在辩论场上是很有力的一招，但是太流氓）

5。旁征博引。“既然微软认为xx，那我们也不会比微软好到哪去，也xx吧”

。。。。。。

未完待续

这是一个好现象，因为会C只是会一种实现方法，而实现有many人去做，CORBA既是一种广泛的实现方法，也是一种高层设计手段，还对重用遗产系统有很大的好处，所以应该有更多的人去用。

中国人学习计算机（其实所有理科都是这样）最喜欢从底层做起，我见过一个程序员花一年的时间自己写了一个Java虚拟机，实在是没必要。大部分中国程序员觉得不懂CORBA可以，不懂C就不是程序员！这种现象叫眼低手高，比眼高手低还可怕。

但我相信会有很多人愿意选择第三个，只是因为他们（或她们）上我的blog的机会很小，所有没有看到这篇文章。我猜想很多搞艺术设计或者网页制作的人会喜欢第三个方向，有点CG的味道。

呵呵，你说“佩服佩服”，我是不是应该说“失礼失礼”就像古代人，或者“过奖过奖”就像现代人啊。：）

产品的最终设计就是工程设计。简单的解释一下二者的区别，比如键盘，工程设计就是指设计一个附和人体工学的键盘布局，例如把打字区一分为二，或者采用更缜密的弹簧增加击键时获得的舒适感，抑或加入键底薄膜可以防水。而工业设计就涉及其生产制造的过程，例如采用什么塑料可以降低生产成本，采用什么形状的弹簧可以减少生产环节，降低次品率等等。

那你所谓的设计师是什么含义呢？是我前面提到的UP中的一个环节？还是搞产品最终设计的？或者说，你的设计是专注于工业设计还是专注于工程设计？

呵呵，这说明dudu是一个典型的程序员，如果是我，我愿意选择第一个，稍带一些研究性质。

呵呵，没想到还有高手前来讨论，其实利润分离在人类社会经济进化的历程中处处都有，关键在于是不是所有人都从中受利。比如给NIKE做OEM的工厂如果生产自有品牌，可能就面临更多的风险和开拓市场所需的成本，其销量也不会有NIKE那么好，但是如果给NIKE生产商品，利润率就会有所提高。至于NIKE，如果它自行生产所有商品，必然陷于资金的不足，融资又有成本，利润率也不够，但是如果专注于设计和品牌营销，把这两样做好了，利润自然滚滚而来。既然对而者都有好处，他们就会这样去做。

但是在国内就不同了，因为市场竞争不充分，专注于设计和品牌的企业可能面临巨大的风险，又由于消费者的维权意识很差，消息又闭塞，导致很多工厂自己做销售会赚的更多，所以就有自己的贸易公司了。

这样做导致的结果很不好，因为销售公司是为生产部门服务的，所以经常出现生产多少销售部门就有多少销售任务的情况。销售部门也不承担质量问题，生产部门也不会自己跟自己过不去，于是消费者的权益就无人理睬了。

如果让你选择上面提到的三个方面中的一个去研究，你会选择哪一个？

据说是“不爱红妆爱武装”的意思，因为powder的解释很多。

这本书提及的软件设计和我所理解的软件设计是同一回事，但是和现在很多人理解的软件设计不是同一回事。

现在的人们理解软件设计好像是UP中的一个环节，所以方方面面都要到位，但又不能超格，就好像是生产线的一个流程一样，失去了设计的本意。而这本书唤醒了人们心中对设计的美好理想，设计表达的应该是软件最终的样子，包括界面和交互式设计，当然还有载体等等其它因素，设计应该是对设计者和开发者整体思路的构造，而不是一个面面俱到的东西。

但话又说回来，现在的软件功能性往往多于交互性，比如一个系统，80％的程序员可能根本就遇不到系统的界面和交互，设计对于他们来说多少就有点架构的意思了。

泡泡

看到他们回的帖了，实在无聊，和我想象中他们会回的帖子一样，所以我不会再回，因为再回帖就意味着吵架或者是他们所谓的“辩论”，我的“辩论”不是这样，在我的辩论世界里我只谈自己的看法，不回击别人对我的指责，直到有人真正看懂了我的理论体系并对此提出致命性打击时，我才会出手。而我出手的时候，也就意味着我知道自己之前的言论错了，或在某个层面错了，并且我已发现了改进的方法。 当然，也不排除这种可能，那就是有人从根本上驳倒了我，让我觉得自己之前的立场如一堆废纸般毫无意义，那我会帖出我全新的认识，毫不犹豫的！总而言之，我的原则就是——我只参与见解的分享，不参与见解的评论！

感觉如何？

呵呵，MSN Space慢主要是因为它的图片和广告，还有花里胡梢的外观，建议Microsoft可以考虑提供一种简单设计的blog，功能恰到好处，采用单独的服务器运行。

我的邮箱是
briansun.vip@gmail.com

我的MSN上班时间都开着
javaboy2010@hotmail.com

我是这样考虑的。我们先来看一个简单的比喻。我们都知道图有两种基本的表示法——邻接表和邻接矩阵，两种方法都可以全面的反映图的信息，这意味着前一种表示法能做到的事情，后一种表示法也都能做到，同样后一种表示法所做到的事情，前一种也不会做不到。所以图只要以其中的一种表示法表示就可以了，（由于两种表示法对不同操作有不同的反应性能，所以）除非有特殊的性能需求，否则不需要使某个图同时具备这两种实现方法。

现状也很类似，既然“Facade＋懒加载”与“容器＋Service”同时为解决问题的两种方案，或者可以说是两种实现方法，我们的系统又相对稳定，不会出现一会要加载5个服务，一会又变成50个的情况，所以我认为两种方案不需要同时具备。此外，如果同时采用这两种实现方法的话，很可能会在设计时出现这样的尴尬局面：当程序员需要get一个对象时，他将面临一个选择，是将这个get方法放在容器里呢，还是放在门面上，或者，干脆，他两个方法都提供，“既然后期需要大量重构，不如现在来点冗余代码”的想法真的很深入人心。。。。。。

做平台的泡泡

＃……×※◎……＃×※◎！￥％◎！……￥◎……￥×◎！
热烈祝贺树懒同学进入复试！
等全部确定下来后我去与你汇合，
并亲赴你不得不请的饭局！
无论你在合肥、青岛、北京、南京……
＃……×※◎……＃×※◎！￥％◎！……￥◎……￥×◎！

说得对，MacOS X确实对MacOS支持的不是很好，前者是苹果公司在彻底抛弃了原来的操作系统架构之后完全重做的，采用了类Unix内核。后者是原来的产品，从八十年代末就开发了，使用的是Windows第三版以前的内核（Windows95是第四版。。。。。），两者不能很好兼容是很正常的事，但是身为硅谷和好莱坞都著名的双料大腕，苹果公司显示出了一个业界领导人应有的风采，给予了合作伙伴不少的支持。要知道，每个新版的图形工作产品或媒体产品如Photoshop都是先发布苹果版再发布PC版的，可见苹果对软件供应商的支持远多于某些厂商。
（这又给了我们一个启事，既然像苹果这么大的公司都可以选择如此大规模的变革——谁说大象不能跳舞？！）

呵呵，哪里哪里，一般一般。。。。呵呵。。。这个嘛。。。其实。。。。我也不懂的很多啦。。。。嘻嘻。。。我懂的也不是很多啦。。。哦。。常来看看喔。。。

ERPII与ECM之战
摘自ZDChina [http://www.zdnet.com.cn/biztech/e-business/story/0,1000001984,20029349,00.htm]

Thursday, September 20 2001 1:40 PM

从商业界为了产品的商标而煞费苦心这一点上可以看出IT业现在的发展趋向。各大公司都在利用内部保密的新策略努力为自己的产品定名，这一行为好象自然界的动物为了生存空间而相互竞争一样。
Click here to find out more!

Gartner 公司正在进行ERP II的升级，AMR Research也在致力于ECM的工作。ERP II和ECM都是缩写词语，它反映了互联网技术正在使得各公司不用自己公司的名称来定义它们软件产品的趋势。ECM（enterprise commerce management）即企业商务管理，在当今也许就是一种超前的概念，它更准确地描述了它的用途，也就是让人们一目了然知道它是用来做什么的。这两个术语也只是刚刚脱离传统走向新型定名概念的开始，现在说它们能够准确地描绘出未来电子商务的发展趋势还为时过早。

ERP II其实是相当于在原有的建筑上添砖加瓦。Gartner早在十年以前就创造出了这个词——ERP (enterprise resource planning) 即企业资源计划，是为了描述一种新型的软件，这种软件是集中了多种工作任务于一身的集合体，这些任务包括金融方面、人力资源方面、命令和单独运行共享数据库等。ERP销售商，如：Oracle, PeopleSoft, 和 SAP 一直销售情况良好，直到一年多以前业内不景气之时情况才发生变化。原因也很显而易见，就是新兴起的SCM（supply-chain management）即供应链管理；CRM（customer relations management）客户关系管理；电子购物；电子市场；以及其它一些商业对商业应用抢占了市场，夺取了ERP原有的光彩。

关于ERP II的构想的确有它自己的道理，很有可能再次刮起一阵ERP旋风。因为，尽管现在很多公司在使用新的应用产品，但是过去的ERP系统还没被各公司抛弃。原来的ERP销售商也期待着有一天能够重新拾起老本行的工作，把新的B2B（business to business ）应用功能添加到原来的ERP上使得ERP重新焕发青春。比如：Oracle, PeopleSoft, 和SAP这几个原来青睐于ERP的公司，现在正提供它们自己的CRM产品。然而在ERP II一路走来的时候，颇具讽刺的是，除了以前曾经经营过ERP的几家公司之外Gartner还没有确认新的公司作为ERP II的经营者。这使得Ariba, i2,和 Siebel Systems等一些销售公司大为失望，因为这些公司为ERP 重新杀回市场做了不小的贡献，它们通过开发新的B2B应用程序从而提供更好的合成应用，为ERP 的东山再起奠定了实力的基础。与此同时，老的ERP销售商打算放弃原有的ERP商标，作为重铸自我形象——建立新型电子商务供应商形象的关键一步。

ECM已经把诸多因素都考虑进来。AMR Research的观点是ECM要比Gartner的ERP II更高级，因为ECM已经认识到了B2B软件销售商家的重要作用。正如July AMR 的报告所说的那样，ECM的其中一个规则就是把多个销售商的共同系统作为一项现实目标去实现。ECM还为应用合成提供了更广阔更具实用性的步骤。ERP II希望各个公司能够把外向型应用（如：CRM和SCM）与原来的ERP系统联合起来。ECM升级了一个合成框架结构，可以提供一个介于个别的ECM 模板和B2B应用模式之间的新型应用。现在ECM不再期望完全的合成功能，而是接受了秘密的贸易交流，这作为一种途径为公司在降低成本和复杂性的同时与用户加强了联系。

尽管ECM的构想很不错，但无论是它还是ERP还都缺乏前瞻性。两个概念只为IT提供了一个中介模式，那就是适应电子商务的需要。这一步迈出的方向是正确的，但是力度还远远不够。

ERP II和ECM都认为单个的企业仍然将是电子商务市场的骨干力量。它们都以企业为主要依靠，直到电子商务的核心转移到互联网上来。公司们也都认识到她们必须配置软件和程序以满足众多客户公司的需要。有的公司也将不得不放弃一部分它们曾经所追求的独立性，因为这样做使得它们可以获得协作带来的利益。同时，他们也将更加地开放，以便能够与它们的客户和供应商建立更密切的联系和分享信息。

我是有兴趣的，但我没翻译过书，只翻译过一篇文章（在非程序员第37期，署名也是briansun），不知道难度如何，你有样章可以给我看看吗？

briansun
email:briansun.vip@gmail.com
blog:http:/www.briansun.com

兼容性分三个方向讲，一个是自兼容，即兼容本体系的产品，比如Office组件间相互兼容，Windows XP和Windows 2K明明是采用不同的内核，确几乎相互兼容90％以上的应用。

另一个是横向兼容，是讲本产品与其它同类产品的兼容性，这种兼容性多数是根据大企业或第三方机构所发布的标准来定的。比如StarOffice声称自己和Office兼容的很好。

第三种兼容性就是纵向兼容，意思是本产品能兼容多种平台，或兼容很多下游软件商的产品。比如StarOffice兼容很多操作系统，Linux、Solaris、Win32，但是Office却只兼容Windows。

苹果的Mac体系产品和MacOS X操作系统确实是值得崇拜和研究的对象。我们都知道它不兼容IBM PC体系，但并不是说它缺乏兼容性，相反，它的自兼容和横向兼容都做的很好了，现在在MacOS X上已经可以运行多款微软产品Microsoft Office、Microsoft Internet Explorer、Microsoft Media Player、Microsoft MSN Messenger等等，加上以前就对它支持的Adobe，Coral，Java，Mozilla，Macromedia，EA，暴雪等品牌，苹果产品已经对PC兼容的很好了。他们唯一不放弃的就是纵向兼容性，也就是说MacOSX不能在PC上跑（尽管它用的是类Unix内核），而Mac系列个人电脑也不能用Windows/Linux。这样做的好处是

a.几乎没有苹果电脑能感染的病毒。

b.由于没有其它厂商可以生产苹果的个人电脑，保证了它的质量、售后服务和市场形象。

c.由于没有消耗资源的Windows，苹果机的性能非常好，使其可以胜任高性能图形工作站的角色。

d.有限的应用杜绝了很多横向兼容性问题，使其bug的数量呈几何级数递减。并可以专注于设备的外形设计。

e.有限的硬件供应商使升级频率减少，耐用性大大加强，一般的苹果电脑使用十年以上是没有问题的。

f.独特的定位使得IBM、HP、Dell等“黑手”无法撼动苹果“个人电脑之王”的称号，苹果也是据我所知的唯一一个在某领域各方面都击败Sony的企业。

想买苹果产品的泡泡

呵呵，谢谢Yuko的回复，你是我最好的朋友之一。你的信我已经帮你寄出了，而且保证没有看。。。。

在HR的招聘环节中，招聘方式的选择往往存在一个成本性指标的问题。简单的说，就是如果两个同等效力的方案之中的某一个更便宜，企业就会选择，无论是企业的规模与行业的差别。

具体的说，应该遵循下面这个过程。

1。如果存在一种方法，正确的衡量某个人的能力与企业对这个人的愿景，那么企业就会选择。

2。遗憾的是脑经正常的人都知道这种方法是不存在的，那么企业必然会选择层层考核加试用来衡量一个人的能力。这对大企业来说是很应该的，因为他们有的是钱，而需要合格的人来花这些钱。素质高的员工是利润的来源，客户信赖的对象，企业的门面，也是减少内部沟通成本的最佳选择。比如P&G在很多大学都只招一个人，Intel和麦肯锡都只要硕士以上学历的人。

3。现在我们有了一种衡量能力的合理方法，可是对于中型企业来说，这种方法成本太高了，大多数中型企业面临人才的极度需求状态，但是他们确实没有什么地方能够留住人才的，因此中型企业往往是薪水最高的，一般都会比大型企业要高。这时中型企业无法忍受应聘者的慢热情况，他们需要立即能上手的人才，所以这些企业往往不看重应聘者的学历，而重视能力，园长就是这样进入国内最大的独立软件供应商的。

4。小企业又是完全另外的一回事，因为小企业愿意花更少的成本来衡量一个人的能力，他们既不愿花钱来判断谁最有能力（这个需要有伯乐，而请伯乐需要花钱），也不愿意花钱给人做大量的培训，更不愿意让人随随便便实习。这些企业能找到的最省钱的判别人能力的方法就是请学历和社会经验代劳。这也就是说到这样的企业找工作，做一份好简历是个非常重要的秘诀。

想知道如何成生这些图片吗？写信给园长就告诉你！

这个bug也臭了点吧。。。。

买个本本怎么会有这么好的配置呢。。。再说买个8000块钱的本本肯定是国产货中的劣等货，呵呵，不值得一买。。。。

楼上这句话说得还有点道理，我顶你。。。呵呵。。。。