1。拳击运动员
他一生中的每一时刻，都在痛苦和希望之间徘徊。一个没有被打倒过的人不算是真正的拳击手，只能算是拳击运动的爱好者和参与者罢了。没有人愿意跟一个没有失 败过的人打，就连电影百万宝贝中的女人也这么想。这并不是说一个人若想称为真正的拳击手就要主动尝试被人打倒的滋味，而是说如果你从未有过被人打倒的经历 和体验，你就不能很好的知道什么时候该勇往直前，什么时候该保护自己，如何保护自己，保护自己的哪里，用什么来保护自己，甚至，牺牲自己的什么来保护自 己！一个男人必然不会是一生都不需要保护自己的人，当然，一个男人也不能时时刻刻都在保护自己，正在保护自己的男人是痛苦的，他不得不忍受“我是男人，而 男人应该去保护别人”这样狗屁不通的理论对自己的煎熬，别人的非议就更不用说，但是希望有随时都会在他的心中点燃——下一刻，我将挥出我复仇的一拳！


2。赛车手
他一生中的每一时刻，对他来说都是一次信心的考验。尤其是排名世界第二的赛车手，如果他挑战自己的极限，他有可能命丧黄泉，如果他见好就收，他毕生取得的 成就都会在他死后烟消云散，甚至在生命的最后一段时间里不仅要忍受老去的躯体的折磨，还要忍受昔日崇拜者鄙视的目光。多数处在这个位置的男人都会选择继续 挑战人生，毕竟只有第一能够博得终身的成就和死后殊荣，但这样做的结果往往也是死路一条——现实生活不会总像电影Troy那样气势磅礴。在这一点上，商界 的很多男人选择激流勇退，这样做对他们来说叫做“留得青山在，不怕没柴烧”，不知道这算不算是一种理性，倘若是，那这种理性究竟是人性的倒退，还是人类发 展的必然未来？

3。潜艇艇长
他一生中的每一时刻，都要隐藏自己内心的恐惧。他不能有恐惧，是的，就是这样，或者说，他不能让别人发现他的恐惧。在数百尺深的海底，每个人都会一定程度 的丧失他在陆地和海洋表面的理智与信心，而潜艇之长，作为几十人到数百人的领导，更要无所不知，无所不能，且每时每刻都要让别人感受到他的信心、乐观与积 极，连他自己有时都被自己的表象所欺骗，简直就像一个四处散发信心的广播。更重要的一点，也是电影U571要向我们描述的一点是，一个合格的水手可以为了 别人牺牲自己，这无可厚非，可是一个艇长不仅仅要有随时牺牲自己的勇气，还要有为了整艘船牺牲个别船员的洞察力和决策力。这往往也是一个男人不易被人理解 的地方：该牺牲自己时牺牲自己，该牺牲别人时牺牲别人。

（转载本文需注明出处：Brian Sun @ 爬树的泡泡[http://www.blogjava.net/briansun]）

What is NXUnit?

NXUnit is a NUnit -style unit testing framework about XML for .NET Framework. It is an extension to NUnit. It brings you the ability to do unit testing easily in XML applications. It helps you to concentrate on business logic of your XML application and improve your Test Driven Development(TDD) technics. You can directly compare one XML string or stream with another, er assert that they are equal, just like doing the same thing to two integers using xUnit. But without NXUnit, you must pay attention to whitespaces in XML strings, empty elements or attributes, unimportant order of elements or attributes, unneccessary comments and so on. It's similar with XmlUnit in some aspects.

Features

The current version is NXUnit 1.0rc1, July 2005. The following is the 8 features of this version, which you can find in the facade class XMLAssert:

    * Assert that two XML inputs are equal.
    * Compare two XML inputs and find all differences between them.
    * Assert that declarations of two XML inputs are equal.
    * Assert that document types of two XML inputs are equal.
    * Assert the validity of an XML input.
    * Assert that the evaluation of an XPath expression on an XML input will return the expected value.
    * Assert that an XPath expression exists for an XML input.
    * Assert that an XML input is included by another.

And you can change the properties of an instance of XMLAssert before an assertion or comparition, in order to:

    * Ignore the case of the elements' and attributes' names
    * Ignore XML comments
    * Ignore XML declarations and document types of both inputs
    * Ignore empty elements and attributes
    * Ignore orders of elements and attributes
    * Ignore unimportant whitespaces

Sample

 1    using System;
 2    using System.IO;
 3    using System.Xml;
 4    using NUnit.Framework;
 5    using NXUnit.Framework;
 6
 7
 8    [TestFixture]
 9    public class Sample
10    {
11        private XMLAssert xa;
12
13        [SetUp]
14        public void Init()
15        {
16            xa = XMLAssert.CreateInstance();
17        }
18
19        [Test]
20        public void TestMethod()
21        {
22            // Init the xml input
23            string s1 = "";
24            string s2 = "";
25
26            // Init the options for your purpose
27            xa.IsOrderSensitive = false;
28
29            // Assert two XML inputs are equal
30            xa.AreEqual(s1, s2, "Assertion Failed!");
31
32            // Compare two XML inputs and find all differences between them
33            CompareResult r = xa.Compare(s1, s2);
34            foreach (Diff d in r)
35            {
36                Console.WriteLine(d);
37            }
38            CompareResult another = xa.Compare(s1, s2);
39            r.Add(another);
40            for (int i = 0; i < r.Count; i++)
41            {
42                Console.WriteLine(r[i]);
43            }
44            if (r.AreEqual)
45            {
46                // They are equal
47            }
48
49            // Assert two XML declaration of the two XML inputs are equal
50            xa.AreDeclareEqual(s1, s2, "Declarations are not equal");
51
52            // Assert two document types of the two XML inputs are equal
53            xa.AreDocTypeEqual(s1, s2, "DocTypes are not equal");
54
55            // Assert the validity of an XML input
56            XMLAssert.IsValid("");
57            XMLAssert.IsValidFile(@"C:\");
58
59            // Assert the evaluation of an XPath expression on an XML input will 
60            // return the expected value
61            xa.AreXpathEqual("<a/>", "/r/a[2]", s1, 
62                "The xpath expression doesn't return <a/>");
63
64            // Assert an XPath expression is exist for an XML input
65            XMLAssert.XpathExist("//@b='c'", s1, 
66                "The xml document doesn't have the xpath expression");
67
68            // Assert an XML input is included by another one
69            xa.IsIncluded(s1, s2, "The {0} is not included in {1}", s1, s2);
70
71            // The Counter
72            Assert.AreEqual(6, xa.Counter);
73
74            // XMLInput can use in all the samples above
75            xa.AreEqual(XMLInput.CreateFromString(s1), 
76                XMLInput.CreateFromString(s2), "Assertion Failed!");
77        }
78    }

首先，要向大家致以我深深的歉意，因为我已经有两个多月没来关心我的这个与朋友们交流的平台了。原因有很多，最主要的原因就是太忙了。起先是忙写毕业论文，这件事很让我头疼了一把，因为我要一边上班一边完成毕业论文，于是每当我打开Blog想添一篇新文章的时候我就会立即想到还要论文要写，于是立即打开 word毫不含糊。论文忙完了之后，我着手写一篇很长的文章，记录了我这三个月来对“测试驱动开发（TDD）”的理解和体验，这篇文章对我来说非常重要，也是我一段时间工作的总结，于是我想等我把整篇文章写完之后再奉献给大家比较好。这篇文章刚有了构思和提纲之后我又收到北京总部发来的消息，要求我们每日加班到9:00，周六也工作，这耗费了我之前用来写Blog的几乎全部时间，再之后就是转出消息领导要来南京视察，尤其是视察我们小组的工作，于是我又要加班加点的赶进度，因为我们小组的几个人进度都不能另自己满意（更不用说领导了）。再之后就是领导没来，但是要求我们尽快去北京参加评审和一些开不完的会议，于是我们又Z50去Z49回来，中间转正花了一周开会花了一周。然后我就回家洗了个澡，睡了个安稳觉，然后就到今天了。

还有一件事情也是最近一段时间值得骄傲的，要提一下，就是我花了点时间把自己写的一个小工具包装成了一个开源软件，在SourceForge上登了出来，是一个单元测试工具（当然也可以叫TDD工具啦，哈哈，），对NUnit的一个扩展，使其可以方便的比较和断言两个XML，希望能对遇到同样问题的朋友们带来一些帮助。所谓“花了点时间”是指我把每个周日都耗在了提着笔记本在Starbucks要一杯Frappuccino然后写十几个小时的代码和文档上了。

但是，再多的借口也不能弥补我在春夏换季时不写Blog的罪过。所以我决心从今天开始洗心革面，重新做人，每周都写Blog，大家再给我一次机会吧！。。。。。。

致歉的泡泡

这篇文章来自我读了Mango Du的“水银看人力资源外包”一文的读后感，或者说是对该文的一个评论，只不过这个评论是以另外一种形式发表在我的Blog上的。确实可以说这两年人力资源外包被提到了很高的地位，有人说这是分工过细所致，有人认为是专业化所致，还有人认为这是企业为了降低成本，我却认为不是这样。

1。关于分工细化。
分工细化不足以产生一个行业。比方说，我们做软件的都知道软件设计、软件实现和软件测试都应该被分为很细的方面，至少应该被分为这三个方面，于是有很多人很早就预言软件企业会分裂为专做设计和专做编码两类，事实上当初我也是这种想法的坚定支持者之一，但是现在开来这是一个很幼稚的想法。在最近的几年里这种划分还不会出现，因为软件设计和实现在今天的技术框架和过程惯例下耦合度仍然很高，交流的成本非常关键，因此将这两个部分分裂成两个企业会导致企业的外部成本迅速升高，我们都知道这是违背企业存在的意义的一种做法，这一点科斯在上个世纪给出了一个著名的论证。所以人力资源外包肯定不仅仅是一个分工细化的问题，因为人力资源的工作同其它工作的耦合度确实不小。（这一点我后来想了一下，可能某个行业有自己特定的人力资源游戏规则，那样的话人力资源工作可能会和该行业内部的企业耦合度减小，规范度增大，咨询师和电视节目制作人都是这样的例子）。

所以促使一个企业外包人力资源的根本原因不仅仅是分工存在细化的问题，还有部分交易外部化的问题，也就是说如果一件事情本公司的人做不如外公司的人做成本更低效果更好，那么就可以外包。比如员工满意度调查，在公司内部进行可能会有失公允，因为很多员工都担心调查材料不能严格保密的问题。

2。关于降低成本。
降低成本和提高利润是企业一切动作的基本动机。因此人力资源的外包也有成本的原因，但可能并非是成本驱动的。比较一下在企业采购方面的例子，有很多提供采购服务的服务商在帮助企业采购（比如电子商务），我曾见过一个创业方案是关于“买手(buyer)”公司的，但是采购的很多情况是根据企业的不同而不同的，所以在操作上和决定权上仍然是买方做主。这种方式实际上可以被理解为执行和战略的分离，并且我相信这种方式在最终会在企业管理的很多方面体现出来。

简单的说就是企业把握人力资源管理的战略方面，而执行方面交给外包商去做，比如今年的招聘，公司给出计划；抽象招聘流程，公司给出安排；招聘人员的鉴定，公司给出方法和人员；但是具体招聘的安排和实际招聘的对象则是由外包商完成，比如何时招聘，在哪个学校，招多少人面试多少人笔试，谁主持，都是由外包公司完成的。

3。关于专业性。
我个人认为企业之所以会把人力资源外包出去，并非专业性的问题外，或者说专业性只是一个很小的方面，比如财务管理已经是一个规范度极强的企业了，可是把财务部门外包给服务商去做的企业可能也不是很多，原因很简单，一方面财务部门比较私密，战略性意义也比较高，另一方面财务人员市场上有的是，不需要多花几个钱就能顾的起，所以财务部门无需外包。但是仔细想想，后面一个理由是否站得住脚，为什么财务人员专业性高却资源丰富呢？原因很简单——制度完善。真正专业性很强的工作已经由金融机构和会计公司完成了，剩下的是成本低廉的非专业工作。问题又来了，企业为什么会花钱顾一些非专业性强的员工，而把专业性强的工作交给别的公司完成呢？？这难道没有违反企业存在的意义吗？？

OK，我想通了，现在我改变了自己的看法，我认为企业要外包自己的人力资源正是出于专业性的原因。事实上，合理的方式应该是为企业直接创造价值的部门（以前我们称为直线部门）我们用专业性强的员工以提高能力，不为企业直接创造价值的部门（以前我们称为职能部门）我们用非专业性强的员工以降低成本，而这些部门的专业性工作我们交给专业的企业去完成，这应该就是未来企业的部门组织，That's It！

4。小结。
现在我们总结一下我们的理论，为什么企业会把人力资源工作外包出去做？答案是提高人力资源工作的效果、更着眼于战略因素、和外部专业化内部非专业化以降低成本。现在我们再抽点时间看看其它外包服务是否也遵循同样的原理。企业外包财务给财务公司是为了提高财务的效果（严格、准确、安全、可靠），更着眼于战略因素（管理会计和金融部门），外部专业化（注册会计）内部非专业化（会计和行政助理）以降低成本。企业外包IT部门给提供服务的信息服务供应商是为了提高信息技术以加速管理的效果（有效、安全、科学化、降低管理成本），更着眼于战略因素（信息收集和信息处理的方式和制品，而不是技术），外部专业化（软件设计和实现）内部非专业化（实施顾问和硬件采购）以降低成本。还需要其它的例子吗？


差点搞HRM的泡泡



“别人看到了偶然，而我却看到了因果。”
                                      ——<<The Matrix>>

在写完了前面那篇“4月16日评点IBM”之后的某个早晨，我和领导共进早餐，由于我们吃饭的地方其实是方正的餐厅，所以席间略谈了几句方正。这是 我猛然发现，方正原来也是一个技术型很专一的企业，这几年逐渐变得平庸了，即使没有像经不起风霜的小企业一样完蛋，也不能否认这么多年屹立不倒多少也有吃 老本的嫌疑，但是，究竟是什么使这样一个显赫一时直至今日仍然在自己的领域是龙头老大的企业失去当年励精图治的成就呢？

我想答案可能与那 篇文章中提到的IBM面临的情况类似，当PC革命到来的时候，作为一个以计算机技术（整体中的大部分）为主要研究对象的龙头老大，岂能眼睁睁看到这样一块 风水宝地被后生抢走，岂能眼睁睁看着交手多年的竞争对手大把大把捞银子，岂能眼睁睁看着国内外企盼PC技术给人类带来巨大变革的一双双渴望的眼睛，即使这 种变革像雾像雨又像风，来得快也去得快！

其实仔细想想这样一个大公司的困惑吧。一个像IBM、方正、HP、Intel这样的企业，在PC 诞生之前，他们就已经名声显赫，有万贯家产，可是他们越是德高望重，面临的困惑也就越大。究竟是顺应时代变革、勇攀新的高峰，还是任凭风吹雨打、我自岿然 不动！究竟是抢占先机、舍我其谁，还是浅尝辄止、随风应变！在尝到甜头的时候，究竟是见好就收、预防否极泰来，还是孤注一掷、争取利润最大化。在遇到困难 和暂时性的挫败时，究竟是浪子回头金不换，还是去留肝胆两昆仑！（不好意思，话说大了）。很小的时候度过一本留美博士写的书，书的大概内容是讲IT发展史的，但是由于作者是DBA出身（是MBA的升级版，不是数据库管理员），所以商业思考多于技术见解。这本书中很多部分就是以这样的两难选题开始的，这在管理学中是非常可怕的战略选择，它足可以决定一个企业的生死，例子嘛，IT界有的是。

想想刚刚提到的IBM，在这样的PC大潮中不能见好就收，致使偏离了自己的轨道；方正，没有将有限的资源投入到原来那分很有前途的职业中去，当 诸多外敌进入市场时不能很好的守住阵地；HP，任凭PC部门摊薄优质资产的利润率。反过来说，IBM，成长和发展的途中没有丢弃自己计算机技术霸主的地 位；方正，依然是闪亮的明星；HP，尽管付出了沉重的代价，总算还戴上了自己梦寐以求的王冠；苹果，在尝试了诸多路线之后才发现岿然不动才是属于自己的致 胜之道。

这些毕竟都是有得有失之人。有完全失败的吗？有！王安，在不能应对突如其来的开放架构的战争中全军覆没；Novell，在不能应对突如其来的互联网大潮中几乎夭折；宏基，风采不见已经多年。

有完全成功的吗？当然也有！Intel，由于把握了合适的时机，已经时常拿Mr.Incredible（超人）和自己比较了；Microsoft，得益于IBM的培养成为人类历史的篇章。

有浅尝辄止的成功者吗？有～。想想GE吧，当PC的时代即将到来时，华尔街无一例外的认为GE将寻觅时机和IBM正面交锋，结果是人家玩的很潇洒，不知道是不是某个尚未公布的战略矩阵计算的结果。

退 一步讲，这也许就是一个大企业应该承担的责任，越大的企业应该面临越难的抉择、应对越大的风险、抵御越大的诱惑、同时享受越多的利润。但也应该注意的是， 战略选择在这样的环境下对大企业有更多的意义，所以大企业更应该重视战略问题，从自身的特点和行业的特性出发，把握任何对时代脉搏的真实未来的预言。但愿 这些对国内的企业是个借鉴。

提供有限咨询的泡泡

有人问为什么总是以“评点”命名我的Blog文章，我说那是我取错了名字，应该叫“小议”；有人问为什么总是“几月几日评点什么”呢，我说那是因为虽然我 的想法总是来源于平时的思考，但我的写作欲望却来源于一时的冲动，所以我要记住我这次冲动的日期；但是，还有更重要的一点，那就是我一时的冲动并不表示我 对一个事物的完全认识，所以我以后还会再“小议”这个事物，那时我又要写“几月几日再评点什么”了。^_^

事情要从扬州说起，昨日在博客园领导dudu的解说下游览了扬州著名的两个景点，瘦西湖和大明寺，还品尝了暴多扬州美味小吃，（全劳dudu破费，再次感 谢），既非常疲惫，又欣喜万分。席间我们谈到IBM，我又大发神经，把我对IBM的很多认识统统说了一遍，情绪十分激动，虽严重影响了周围客人的食欲，但 滋生了评点IBM的欲望，于是赶回南京，写了这篇，正在进膳的朋友免看。^_^

1。IBM的开始。
IBM的年龄比目前世界上大多数人要大，它的早期辉煌出自两代Thomas Watson夫子之手。老Thomas Watson缔造了IBM，并使得IBM的基调始终停留在商用机器的领域，当时是没有电子计算机的，所以IBM的主要产品是打孔机和计时器，但此时的 IBM已经是名利双收，它的名来自它为当时全国性的一次人口普查提供了全部设备，它的利则来自二战时不得不生产的军火工业。小Thomas Watson和他爸爸有同样的名字，只是中间名字不同，崇拜技术要多于崇拜老爸，他经常为了一点点小的技术方面的问题同老爸争的不可开交。比如曾经有一个 年轻人拿着一个旅行箱大小的设备来见他们父子，这台机器只会做基本的加法和减法，显然他的目的是找IBM要投资，这个人演示了这台机器，老Watson发 现这台机器算的还不如一个熟练使用中国算盘的小姑娘，立即觉得这个东西没有，而小Watson却觉得既然它可以算加法以后一定可以算乘法，于是很想投资。 父子两为了这件事整整吵了一夜，第二天人们发现他们在房间抱头痛哭。这个例子只是为了说明父子两对技术的重视程度，事实上，当小Watson接手IBM时 他也没有再投资那个年轻人，但是这个时候他对整个计算机工业的投资已经启动了。

小Watson和他老爸一样重视技术，记得他曾单独嘱咐过两位科学家：“一定要把System/360搞好！”这两个人当中资历比较小的那个叫做Fred Brooks，他深信自己的体系结构是正确的，而老前辈却认为他自己的体系结构是正确的，于是那段日子，Watson总裁几乎天天和他们泡在一起，他好像 一个辩论赛的教练，倾听总是多于发表意见，他让Brooks说他的体系结构有哪些优点，然后让前辈说这个结构哪里不对头，又让前辈说自己的体系结构，再让 Brooks说哪里不对头。就这样反复来回几十遍，问题总会走到两个人都满意的位置上去。最后只剩一个问题解决不了的时候，三个人同时发现这就是真正的争 议所在，这时Watson就拍板说让前辈全权负责，有最终决定权，然后前辈也没有辜负老总的一片期望，选择并培养了Brooks，并最终让Brooks担 当了System/360的主设计师。

那是一个怎样的年代，老总可以和两代技术专家坐在一起谈论一个系统的实现细节。而且这还是IBM的老总，这是一个现在想都不要想的场景，而这一切印证了 Time对IBM的一句评语：“IBM生于崇尚技术的年代！”事实上，Brooks在System/360成功很多年以后才入选IBM Fellow（名士），说明IBM的科研人才之多，可谓富可敌国。

2。IBM的衰落。
这样神话般的日子持续了几十年，历经了两代老总的时间。但是对于生来就是贵族的小Watson而言，工作并不是他的全部，所以他很早就辞掉了在IBM的全 部职务，回家过安闲的晚年。在他执政IBM的最后一段日子了，个人电脑业兴起了，Steve Jobs的一夜暴富让很多人红了眼，HP和IBM都在其中，这两大电子工业的巨头在口水快要淹死自己的同时都冲向了这个广阔的天地。IBM的PC——个人 电脑——其创意也是直接出自小Watson之手，但他万万没有想到的是，这个发明改变了整个世界的面貌！

在此之后的几十年，IBM同HP同一些兴起的小公司一起争夺PC业的霸主地位。像所以其它的事物一样，这既是IBM鼎盛时期的开始，也是必将衰落的标志， 原因很简单——它背离了自己的灵魂。在与这些公司竞争的过程中，IBM渐渐力不从心，这段时间的历史被载入了很多大学MBA的案例教材中，简单数数就会知 道，作为PC发明者的IBM很少能在这个领域呼风唤雨，成本是Dell的，新技术是Compaq的，家用电脑是HP的，时尚是Apple的，同时它还免不 了要看看Sony和Fujistu的脸色。为什么当年能在技术界称王称霸的IBM会和这些以制造业为基础的企业处在同样的竞争集团呢？这个问题的本身就是 答案。一个企业当他在自己的发明上挣够了钱之后，他就面临做精做细的问题，有些公司能处理的好，比如Adobe，有些不能，比如Apple，这不是能力问 题，这就是生活，他总是多姿多彩的，玩的起的人上天堂，输的起的人走四方！

不是谁发明了什么就一定能把它做好的！可惜绝大部分技术出身的人不能想通这个问题，即使想通了，轮到自己了也不会去做，这需要多大的勇气啊，让技术人员去 选择技术根本就不是一个稳重的大公司会做出的决定，可惜直到90年代IBM才意识到这一点，此时的IBM已是内忧外患，四面楚歌，这个时期的最后一位 CEO曾计划将IBM拆成13个子公司，彼此业务比较独立，（幸好没有让他得逞，否则人类将失去真正宝贵的财富），自身的危机和整个行业的不景气已经让他 成为一头“瘦死的骆驼”，而接下来的三个字也特别需要一位具有独特思维方式的CEO才能续写。

3。IBM的复苏。
IBM求贤若渴，董事会雇佣的猎头公司几乎跑遍了每一家IT企业，去挖他们的CEO，其中最富有戏剧性的，就是猎头公司居然找过GE的Jack， Apple的Jobs和Microsoft的Bill Gates！韦尔奇认为IBM需要认真考虑自己的业务，不该做的就不要做，至于IBM究竟哪些是不该做的，韦尔奇认为IBM在很多领域已经不占优势，最好 的办法就是IBM开拓新的领域，不仅可以卖电脑，还可以卖其它电器。Jobs认为IBM应该和Apple合并成一个公司，专心致志研究如何生产个人电脑。 Gates则认为IBM应该老老实实生产大型机，不要干预低端业务和个人领域。董事会在一次又一次的会议中几乎失去了他们所有的耐心和信心，这些疯狂的人 是不能引入IBM的，可如果没有一个能力和洞察力的双料冠军，IBM就不得不面对拆分的境地。还好，猎头公司没有让人们失望，他们为IBM找到了一个再一 次被收入主流MBA案例教材的借口——一个不懂技术的人可以入主计算机技术的发源地吗？——而他，就是Louis Gestner。

Gestner坚决反对拆分IBM，他认为IBM最重要的一件事就是调整姿态，把自己摆在一个正确的位置上。他问每一个员工：“IBM是一个怎样的企 业？”员工回答：“IBM是一个科技企业。”STOP！不要再说“IBM是一个科技企业了！”IBM哪里有一个科技企业的样子。Gestner说： “IBM是一个服务型企业！”他率先带领管理层代表团访问了很多大客户，比如P&G，此举令P&G受宠若惊。他广泛采纳客户的意见，他经 常动辄邀请200个大客户参加一个会议，为的就是想要知道客户需要什么。技术圈里的人们总是固执的认为，卖一件具有高科技含量的商品才是挣钱的道理， Gestner却要告诉人们“挣钱没有道理”，要想发展科技，就要养活一批高科技人才，要想养活这些全球顶尖的人才就要钱，大量的钱，而这些钱只能靠卖服 务来挣。在Gestner执政的时间里，IBM发生了历史上最大规模的变革，且是两代Watson父子想都不会想到的。

IBM从此变成了一家以客户为核心的价值整合型企业。在硬件方面，Gestner坚信不能要的就是不要。他首先卖出了IBM的大型机部门，可是IBM发明 了大型机！Gestner说“不是谁发明了什么就一定能把它做好的！”不久，他又卖出了IBM硬盘事业部，可是IBM发明了硬盘！Gestner又说“不 是谁发明了什么就一定能把它做好的！”如今，IBM又卖了他的PC部门，可是IBM发明了PC，Gestner虽然已经卸任，他也丝毫不回避这笔他一手创 造的买卖，“不是谁发明了什么就一定能把它做好的！”

在软件方面，当Gestner把玩IBM的数据库时，人们的惯性思维认为Gestner也要把数据库部门给卖了，因为是IBM发明了数据库，可是大人物做 事往往出人意料，Gestner不但没有卖掉数据库部门，反而大规模追加投资，让IBM派出史上最强大的研发力量把数据库包装成他的第一个软件品牌 DB2。此后Gestner悉心听取客户的意见，客户说需要具有协作能力的Office，IBM就强行收购Lotus；客户说需要加强网络管理，IBM就 买下了Tivoli；客户说需要中间件，IBM又包装了所有此类的产品为Websphere；即使在Gestner临卸任之前，他还谈妥了IBM收购 Rational的事宜，至此，IBM已经从一家做硬件的厂商，转变为拥有五大软件品牌的新蓝色巨人。

Gestner终于可以说一句“瘦死的骆驼比马大”了，虽然IBM已经不再是从前的IBM可是Gestner让他重新找回了自信，好比一个失去光芒的普通 石头，在Gestner的手上变成了另一种形式的艺术品，再次散发出了迷人的魅力。这些岂能是韦尔奇、Jobs和Gates能想到的！这就是一个非技术人 员成为IBM的CEO之后的事。此后，很多大公司纷纷效仿，HP请来了漂亮了女总裁，微软换了富有亲和力的鲍尔曼，都企图显示出自己重视客户的一面，改善 其与大客户之间的关系。然而Gestner绝没有他们想象的那么简单，在让IBM转型为一个服务企业的同时，Gestner又重新重视起IBM的科研力 量，失去的军方订单又回来了！IBM在恢复了商业巨头的形象之后又恢复了他的科技巨人形象，很多在抢夺PC业霸主地位时停滞的项目又重新焕发出了生机，这 些都是其他CEO没有想到的，他们面对的又是一个双料型的IBM，他们不得不再次朝圣以维持对计算机前沿技术的追随，Gestner没有让IBM偏离了轨 道，而是让他重新回到了大小Thomas父子领导IBM的那个年代，让他重新拥有了崇尚科技的氛围，让他重新回归了自我，百年IBM，百年回归！

4。IBM的神话。
Gestner几乎让IBM上演了一出“The Return Of The King”，这在其它公司眼里仿佛是一种潜移默化的变革，而在Gestner眼里却是一种长期战略部署和细节性技术态度的有效结合。在硬件的领域， Gestner要说的只有一句话，做不好就不做，没什么大不了，他认为官僚并不是IBM的致命弱点，相反，官僚有官僚的好处，那就是稳定，可信赖。想想 吧，一个像微软一样的公司，对于以往的技术说不干就不干了，大客户怎么放心的下；一个像HP一样的企业，总是因为分脏不均就赶走自己的总裁，大客户怎么放 心的下。Gestner认为IBM最大的问题不是他的官僚，而是他不能轻便的革新。在他入主IBM时，Sun主席Scott McNearly曾讥笑IBM要变成International Biscuit Maker（因为Gestner以前是雷诺的接班人候选，后者拥有全美最大的饼干生产企业Nabisco），Gestner没有让IBM去生产饼干，但他 却把IBM变得像一个饼干生产商一样灵活。没有什么是IBM一定要做的！没有什么是IBM一定能做的好的！没有什么是IBM能做好却又不做的！概括成一句 话就是“谁说大象不能跳舞”！

在软件的世界，Gestner仍然笃信这句由他自己创造的名言。他从不回答“哪些技术是IBM要做的，哪些是IBM不要做的”这样的问题，他总是会说“我 不是个搞技术的，这个问题我不懂”，可他却有独特的眼光和思维方式。对于任何一个软件技术，他总是带着IBM分四步缓慢进入：
1。观望。这时的IBM会说“我不做，但不排除我以后不做”。
2。研究。你会在IBM的alphaworks上看到很多关于该技术的文章，此时的IBM在向人们传达的讯息是“我不做，但是如果我的客户做，我奉陪！”
3。浅尝辄止。你会发现alphaworks上出现了该技术的专栏，IBM将相当一部分应用迁移到了该技术，可是这又怎么样，IBM在说“我做，不过随便做做。”
4。全力出击。到了这个阶段，你会发现IBM给其它该领域的竞争对手以窒息的打击，IBM像是在说“现在轮到我了，你们都不要做了！”正如Gestner在自 己的书里写的一样，“问题不在于大象能不能跳舞，而在于一旦大象开始跳舞，蚂蚁必须离开舞台！”一旦IBM开始动手，其他人才反应过来已经为时已晚。

如果你不信，可以看看Java的例子，当1995年Java诞生在Sun手里的时候，IBM持的态度是观望；1997年www蓬勃兴起，大量Java小应 用程序被应用在Web领域，IBM也做了很多，还做了JDK，此时是研究；到了1999年，Java企业版开始红红火火，大规模大利润的应用服务器浮出水 面，IBM终于看到了切入的时机，Websphere的出台让IBM“随便玩玩”；直到人们看到了以Eclipse命名的产品在2001年出台时，人们才 真正意识到IBM的野心，“一旦大象开始跳舞，蚂蚁必须离开舞台！”再看看Linux的例子吧，当IBM对Linux的支持如日中天成为Linux社团一 道亮丽风景的时候，当Linux的崇拜者们仰视IBM，等待IBM抛出一个主流Linux产品的时候，IBM却浅尝辄止，只要他的大部分产品都可以平滑过 渡到Linux就可以了，“我随便做做，你们玩吧”。

有时我们也在想，如果Gestner不是Gestner呢，如果他是一个懂技术的Gestner他还能不能做到今天的这种战略思维呢，我们不得而知，历史也不允许假设，但有一点可以肯定，只有创造奇迹的人和见过奇迹的人，才会相信奇迹的存在。

谁说泡泡不能跳舞

又是很久没有写Blog了，这两天大量的时间贡献给了两件事，一是看Eclipse的源代码（工作需要），二是不断回复以前写的文章的评论。今天请了假， 抽了点时间来讨论讨论重构。下面写的东西您可能不太赞同，可能没有遇到，也可能有其它更好的办法，而我的观点来自于我对Eclipse源代码的理解和感 悟，无论您有什么想法请评论告诉我，不甚感谢。

1。如果让您随手写一个类，多半人会写出一个以名词命名的类，是的，我们的软件中大量的类是以名词来命名的。一个名词表明了一组对象的共同类型，那么这个类型一定包括该组对象的共同属性和共同方法。

2。在几次迭代之后我们发现类的属性和方法都增多起来，这种粗放型的发展不利于软件系统的整体结构。而事实上，有很多类在80％的时间只需用到20％的属性代码，而20％的时间却需要用到80％的方法代码，因此，将访问率不同的属性和方法分开是必然的趋势。于是有了Descriptor模式，它将一个原始类分成属性集中化和方法集中化的两个类，属性类的命名方式采用原类名+Descriptor的方式，方法类可能沿用原名称，或重新取个名字以动词命名。这种重构还有一个好处就是属性类随时可以加载，而方法类可能要到需要用时才懒加载。

3。在经过多次迭代的增加该类的代码之后，我们发现Descriptor类的属性增多起来，过多的属性使代码变得重量化，同时使结构变得不清晰，一个拥有 过多属性的类也会因知识过多而不易维护，此时最好的方法是将这个类分裂为两个，或多个。分裂的方法也有横向和纵向两种。横向的分裂使类变成两个不同的类， 它们往往叫两个不同的名字且都为名词，同时也可能互相持有对方（Change Unidirectional Association to Bidirectional）。

4。纵向的分裂方法（Extract Class）往 往会将比较公共的部分分离取名为原类名+Model，另一个类名称不变，Model类是后者的父类。加过Model以后的类轻磅了很多，更便于管理，责任 也更轻。至于哪些属性应该放在父类界限不是很严格，通俗的办法是和原类名紧密相关的（特有的）属性应该留在原处，不是紧密相关的（特有的）放在Model 类，比如ID、Label什么的就应该放在Model类。

5。上面的方法反复用几次，属性集中的类就会变得越来越多。这时软件结构虽然看的很清晰，可是使用起来大为不便，因为很多相关的属性可能会在同一个场合下使用，而它们的实体却可能分布在不同的对象中。解决这个问题的方法只有增加接口的数量（Extract Interface），多使用一些小接口，每个小接口表达了一个方面的含义，使用者在使用这些小接口时无法触及它的实体对象（Prototype）， 这种方法的优劣性在于使用者对于架构的理解，如果用的好这种方法会显现出很多面向方面的特性，如果用的不好则是画蛇添足，导致了接口的泛滥（还记得Dll Hell吗，Java是不是正在形成一个Interface Hell？Eclipse是不是正在形成一个Plugin Hell？）。

6。在大量应用了方面接口之后，我们又面临着这样的问题，很多使用这些Model的人其实只是关心其中的一部分固定属性，和几个为数不多的固定方法，有时连重量级方法都不关心，只关心用以交互的查找型get方法，对于这些使用者，我们只需提供一个门面（Facade）即 可。一个Facade包括在一个Model类和Descriptor类的群体中提供一组可以找到任何一个属性的线索，其中的每一个线索都开始于 Facade，结束于存放对应属性的属性类，且遵循“最常用到的属性，其线索最短”的原则。因而Facade绝不仅仅是一个类，而是一个完整的体系结构。

7。接下来还有一个持久化的问题。如果一个类型存在对一个复杂类型的引用，这个复杂类型很可能被深深的隐藏在Facade之后，而且很可能是个不可持久化 的类型，那么如果前者要持久化，它只能保存一个该复杂类型的关键码，并在持久化唤醒时很容易通过某个服务取到该关键码所对应的对象。这个复杂过程没理由要 求Facade以外的类来完成，因此有了Reference模式（Change Value To Reference），即为那个复杂类型定义一个类，类名为原类名+Reference，其责任是保存原类型的关键码和查找原类型的真实对象。Reference类通常定义为可持久化。该模式的另一个好处是不必要常常访问Facade，因为一个Facade也有可能极其复杂。

8。在分析完属性集中化的类和类群之间的关系之后，我们来看看方法集中化的类。这个类也有可能面临方法激增的问题，此时想把一个类拆分成多个可没有拆分属 性集中化的类那么容易了，因为它们往往相互调用，耦合度极高，但又不能不拆（还记得Kent Beck曾经说过的吗，“如果一个类的责任超过三个，我们就必须把它拆开以保证每个类的责任都不超过三个”）！幸好我们有Delegate模式可 供选择，一个方法类可以由它的访问子和工作子两个角色来完成，就像销售部门和生产部门一样。访问子还以原类名来命名，但是它不做实际的工作，只作实际工作 的准备工作（比如收集信息）和后续工作（比如转换结果），生产性的工作交给工作子完成，后者通常以原类名+Delegate命名。这样做的另一个好处就是 Delegate类可能很重磅，并面临大量的资源分配，因而可以懒加载。

9。现在我们有了一个不错的体系结构，它包括一些轻量级的类、类的关系和设计模式，但是，不要以为这些东西是开始时就设计好了的，即使神仙也做不到那样，令人惊奇的是，它们都是从刚刚您写的一个名词开始的。^_^

经常重构的泡泡

最近接二连三看到好几篇讥讽Firefox的文章，文章的作者大都是拿出现在几款流行的浏览器软件相互比较一番，然后得出“Firefox无论性能还是功能都不够好”的结论，然后再说Firefox社区的网民都TMD“不够冷静”，国内国外都像炒股票似的把这个原本“不怎么样”的产品抄的沸沸扬扬，如此如此，这般这般，我真的实在是受不了了，是到了我们这些人出来为Firefox正名的时候了！

首先，我们从Firefox的来出看，Firefox是由Mozilla基金会开发的轻磅浏览器，在此之前，Mozilla已经有很多浏览器了， Mozilla Suite，Netscape都是Mozilla开发的浏览器。那么在这种情况下Mozilla为什么还要做这样一个浏览器呢？我给出的答案包括两个部分：有效性和必然性。有效性参看我的另一篇Blog[]。必然性则是因为Mozilla 迫切需要一个平台来展示他的思想、理念，并告诫正在以网页为经营手段的人们标准化的重要性！请永远记住下面这个等式：

开源软件基金会 ＝ 软件界的传道者

他们做这些事情根本就是无利可图，只能依靠别人的捐助作为开发软件的成本。比如Firefox在刚刚上市放出beta的时候，为了扩大影响力， Mozilla决定登一则广告，于是四处筹集资金，最终从数千家赞助商那里筹集了25万美元的资金，并于2004年12月中旬在The New York Times上打了两个全版广告！你想想啊，数千家软件企业的期望，就为了这两个页面的广告如果说句不好听的话这两页纸会被多少人在上厕所的时候阅读然后索性用来擦屁股完全可以通过广告业的市调公司通过概率算出来！这是为了什么？我记得自己刚刚上网的时候就有人告诉我网络上什么人都有，但至少可以分为四种：商人、教父、狂热者和迷途青年。微软是彻彻底底的第一种人，Mozilla、Eclipse、Apache、JCP都是第二种，Maxthon是第三种，幸好这个世界还有传道者们的存在，否则我们都会变成第四种人，只会跟着商人和狂热者们走路。

是的，Mozilla正是要通过Firefox教诲我们他的圣经。有些人认为Firefox就是一个使用Gecko的Maxthon，我想说这些人大错特错，根本没有理解Firefox。引擎的不同是小事，遵从于标准才是正道。MSIE使用了大量的“专有技术”，使得别人针对MSIE开发的网站在标准化（一般指W3C标准）的浏览器上不能正常显示。也许有人会问，这个很重要吗？既然现在MSIE的用户数量如此庞大，那我们针对MSIE开发自己的网站又有什么错呢？答案是很重要！有错！我举个简单的例子，我们比较一下两个互为竞争对手的网站：IBM和Dell，他们都卖个人电脑，Dell的网站只能在 MSIE上正常显示，IBM的网站无论哪个浏览器都可以，这说明IBM遵循的是行业标准，而Dell使用的是微软特性。然后我们再看看他们两家公司的产品：IBM的电脑，捆绑什么操作系统的都有；而Dell的个人电脑，全部捆绑的是Microsoft Windows！还用我再解释吗？

有人认为Firefox占用太大内存了，我想问问他有没有用过Java，感受如何？Firefox占内存不是Firefox的问题，而恰恰在于操作系统 Windows的不合理性。Firefox的存在就有一个很重要的任务那就是跨平台，Firefox要用底层代码实现一个平台无关性体系结构，既是为了传道，更是为了那些从开源软件中收益的人们。有人认为Firefox结构太复杂，我想问问他有看过xpi文件的结构吗？xpi文件就是一个zip包！这一点又是Firefox从Java世界学来的，这还能叫复杂吗？比dll文件还复杂吗？Firefox还有比Java更绝的——允许插件使用COM！并且能在非Windows平台上虚拟出一个COM服务，这使得为Firefox编写插件变得更为简单，和可移植。如果Google为MSIE写了一个插件，那么他把这个插件移植到Firefox上的工作量只占10％。

有人认为Firefox功能太少，天哪，你不知道自己下插件啊！Firefox从一开始就没有把Maxthon作为自己的竞争对手，你知道是为什么吗？因为Maxthon在增强用户体验方面确实做的很好，而“Maxthon不足的地方不是Maxthon本身的问题，仅仅来源与它使用的是IE内核，所以 Maxthon会有很多安全性和稳定性方面的问题”。Firefox的对手是MSIE，为了更好的和对手较量，Firefox把增强用户体验的工作也交给了第三方插件开发商，毕竟Mozilla没有多少人手啊。Firefox所实现的都是不得不实现的，这恰是现代成熟的软件开发方法论所要教诲我们的。你看看：多页签是能力问题，换皮肤是架构问题，搜索条是易用性问题，DOM是规范化问题，JavaScript和XUL描述界面是平台无关性问题，XPCOM 是平滑迁移问题，而RSS则又是另外一个标准问题！哪一项是还可以从Firefox中剥离出去的？

至于插件吗，Firefox的主管说的很好，他说Firefox面世后只用了两个月的时间就获得了Maxthon花两年时间都没有的插件数量，这还不能说明问题吗？最近拜读了一位ACM老牛人写的关于插件服务的文章，其中提到良好的插件服务有两类，一类适用于单用户环境下大幅度提升可伸缩性，这种架构的完美实现就是Eclipse，另一类适用于多用户环境下大幅度提升安全性、稳定性和一致性，这种架构的完美实现就是Firefox。Firefox率先使用 RDF来描述插件，使用jar文件来打包资源描述，使用“中间定义语言”IDL来描述公共的COM接口，这些都是其它软件体系结构所没有的，也是大量软件架构师敢想而不敢做的！

最后一个问题就是Firefox不仅仅是个浏览器，还是一个RIA，就像Eclipse不仅是个IDE，还是个Platform一样。可以参考我的另一篇 Blog[]（我今天怎么老是做广告啊），以后我还打算写更多关于RIA的文章。

在批驳了这些人的文章之后，让我们再来看看Firefox究竟是个怎样的产品。下面我仅仅列出我所看到的Firefox的优点，至于这些优点是否会让您迁移到Firefox平台，我并不奢求，这是您的价值取舍问题。

1。标准化。

2。简洁化，最小内核化。

3。平台无关性。

4。安全型RIA。

5。多用户环境下的插件管理。

。。。。年轻人，开在我们有缘的份上，我决定卖这本<<如来神掌>>给你。。。什么？这本不合适啊？别急！还有很多本。。。。。。


说三道四的泡泡


下面介绍几种具有坏味道的代码结构，其中很多经验学习自Eclipse，与Martin Fowler不同的是，我找到的几种坏味道都存在于设计理念之中，而不是缺乏设计模式的抽象，也不是未重构的代码。先别急着反驳，也别急着嗤之以鼻，先想 想这些设计理念的优点，看看是不是微不足道，再看看这些理念的缺点，是不是有可能铸成大错，作者还给出了去掉这些坏味道的某个思路，即作者自己的思路，仅 供参考。最后，别忘了想想自己手中的软件的设计，看看会不会遇到其中的熟面孔啊。。。。。

1。味道：控件耦合。
“如果第一个复选框被选中，那么下面的文本域全部失效。”通过这种方式表述的效果在软件开发中经常遇到，很多人称之为“界面逻辑”，想想看，界面逻辑真的可以直接变成代码吗？
典型重构思路：有限状态机。
状态与控件属性集一一对应，控件属性被改变时，状态机收到事件，检查状态是否发生了迁移，如果是则向控件属性集的控制器发出状态迁移事件，控制器批量改变控件状态。

2。味道：控件/绘制器存在状态。
有人认为Motif和Windows已经差别很大了，有没有想过它们和IBM收银机上的字符界面差别有多大呢？既然差别这么大的绘制器仍然存在相同的复杂了（有时是很复杂的）状态，那我们为什么不把它们extract出来而要让它们冗余呢？
典型重构思路：视图的模型。
视图有视图的模型，并不是MVC中的模型，这种方式就是Swing的基础。

3。味道：视图发出有意义的事件。
什么？你的意思是视图应该发出无意义的事件咯？不是这样吗？视图应该不了解任何业务逻辑，也不应该了解任何界面逻辑，如果界面逻辑真的存在的话。
典型重构思路：事件翻译器。
视图发出无意义的事件，比如鼠标事件，键盘事件，或某个控件的事件，事件翻译器把低级事件翻译为高级事件，再把高级事件包装成请求，请求被传递给一个根控制器。

4。味道：动作/命令知道自己的形象。
很多时候，一个Action或者一个Command都知道自己叫什么名字，能不能被禁用，有没有被禁用，图标如何，甚至还知道及时帮助的字符串，执行需要什么条件，返回什么结果等等，如果这么做的话Action和Command就有了自己的视图状态，发出了第2种味道。
典型重构思路：动作代理。
重磅的工作交给代理完成，动作/命令只是一个视图的模型罢了。在UI系统装载之初，动作/命令被装载并绘制在界面上，直到用户点击或触发了这个动作/命令，它的代理才被调入并开始工作。

5。味道：模型知道自己的每一个用处。
有n种视图对应同一个模型，比如对一个网页制作工具来说，一个html文件至少有三种视图：代码、设计、预览。如果模型同时能满足这三种视图的需求的话，这个模型就太重磅了，而且还不好添加一种新视图。比如Dreamwaver的代码/设计页面。
典型重构思路1：一个模型，多个维度。
如果一个模型拥有n个维度，则n个对象，就可以确定一个事实，n-1个对象就可以得到一个线性聚集，n-2个对象就可以得到一个二维表。每个维度就是一组Interface,而事实的类型，其实是不可见的，（内部的巨大类型），只能通过维度确定事实，再提取事实的属性。
典型重构思路2：适配器模式。
模型首先实现最必要的接口，然后当需要模型实现某个非必要接口时，模型会主动或被动的适配为一个满足需求接口的“意外”对象。

6。味道：控制器变成顾问类。
有些人认为我们的社会需要复合型的人才，因为每个人都要具备管理的能力，控制器也要懂管理，它要负责视图和模型之间的交互。但是仔细想想，如果被模型以外的对象知道了业务逻辑的话，那模型还可以替换吗？
典型重构思路：控制器标准化。
控制器将请求包装为命令，并将命令交给命令堆栈执行。控制器并不了解模型，模型只能由模型自己了解，控制器也不知道领域逻辑，它只是做一些机械的翻译工作，并利用视图和模型提供的（互补相关）的素材，创建和模型相关的命令。

7。味道：模型变成无所不知博士。
在没有发生上面六种情况的时候，千万不要大意啊，你很有可能发生了这一种情况，恰恰是因为控制器和视图都不知道业务逻辑，模型才有可能发展为Dr.Know。但是视图往往是树状结构的啊，它怎么和Dr.Know合作呢？通过代理？还是Facade？
典型重构思路：复杂模型结构（树状、图状、知识/操作分离）。
如果有可能，模型也是树状的，可以和视图一一对应；如果这一点做不到，不要紧，可以把大模型划分成轻量小板块，或者迭代子，再用关系对象解释它们之间的关系；如果还不行，那总得做到知识和操作分离吧。。。。。。。

做软件的泡泡



终于有时间让我们冷静下来好好谈谈Google。好在现在是凌晨，我打开了窗户，这样很冷，但是可以让我的脑子更清醒一点，看看这个我们的生活已经离之不得的工具——尽管几年前我们还没有——看看它到底有什么可谈论的话题。

在我们谈论它之前首先我要感谢它，愚人节那天Google将我的邮箱升级到了2G，感谢它给我的这个节日礼物，尽管我半年内只用了5M。

1。Google以前做什么
在Google出现之前人们只有一种搜索引擎，那就是分类引擎，这个想法来源于Yahoo，或者可以说来源于图书馆。后来人们在想如果网页不是由“人类” 添加上去的，而是“机器”自己找到的那该有多好，实现这个理想就意味要用大量的Spider搜寻整个互联网。“嘿，等等，机器怎么知道鸡肉的味道？我是说它们很可能搞错了，这有可能是三文鱼的味道！”就像<<黑客帝国>>所担心的一样，Spider怎么才能知道我们需要什么能？于是有了动态的给每个网页评分的办法，这个办法就像小朋友们做游戏，别人对你的评价要远远重要于他们对你的拜访，PageRank就是这么来的，在结合了几种天才的想法和可行的技术细节之后，人类智慧的结晶，人工智能的当代经典，Google诞生了。

Google用大量的服务器（数以万计）做着每日的网页查找，每个线程就是一个Spider，每个Spider的工作就是从一个网页去另一个网页，检查他们是否已更新，是否废弃，是否存在新创建的页面，评价他们之间的关系，生成快照，并将数据存入数据库。Spider需要很好的协调以避免重复的劳动，同时他们需要确定工作范围的优先级，否则就会“跟不上时代的变化”或者干脆淹死在某些每秒种更新数千次的网页中。在确定了两张网页的关系之后，Google分别更新他们的PageRank得分，这个得分显然已经不是一个公式能够说清楚的了，它总是处在动态更新之中，但PageRank的大意就是，别人对你的连接数量越高你就越有价值，Google就越让你的位置靠前。

Google的出现使互联网的应用向前大大迈出了一步，大量可用性很强的信息资源立即出现在它的需求者面前。为此，权威的PC Magazine将Google和同一年出现的<<The Sims>>同时称为人工智能的经典作品。但也正是Google的这种优秀表现使人们开始了先知式的担忧，著名评论家Dvorak认为 Google的存在改变了以往“小公司大喇叭”的商业格局（借用了Chuck Martin的说法），它再次使互联网变成庸俗的经过资本市场洗礼的温顺绵羊，人们真正需要的东西可能会被排在后面或者根本找不到（比如我的Blog，），而商业化的东西往往占据重要的位置（比如MSN的Blog！），最麻烦的是一旦人们依赖了Google，它就会不自然的扼杀人们对通过其它途径找寻信息的兴趣和勇气。从个人感情角度来讲，我认为这个论调是很有道理的，可这个问题的提出方式已经超出了本文讨论的范围，就像是一个生活态度问题：即使麦当劳再提供100倍的温馨服务，它也无法击败我家楼下买锅贴的；也不能指望USR公司自己维护NS-5机器人的安全，v这些都只能靠别人。同样，假如Google真的谋杀了互联网的本质，那么我相信拯救我们星球的会是一个更体现互联网本质的Hero，而不是Google自己。

2。Google后来做了什么
正如我们所期望的，Google迅速成长为互联网企业的新兴代表，不断优化的引擎使我们获得了快速获取免费信息的途径，在一片叫好声中，Google开始向其它网络产品扩展。比如Google新闻，就是对Google这个巨大资源库的一种非结构化应用。现在Google新闻不仅有了搜索能力，还有了自动选择能力，这是在公开的抢报纸编辑的饭碗。再比如Google图像搜索，也为我们解决了不少难解决的问题，还有Google Group，这些服务使Google看起来更像Yahoo，或者MSN这样的门户网站，而事实上Google用来实现这些功能的成本比其竞争者要小的多，原因很简单，他们用的是人，Google用的是Spider！Google就像互联网领域里的Matrix，随处可见。

在提供了这些网络产品的同时，Google还在客户端与竞争者们一决高下，首先是浏览器的工具条Google Toolbar，起初我觉得很有用，后来觉得没什么用占地方还损失性能，但是现在看到Firefox和Google结合的这么好，又开始使用了。然后Google推出了用于推广它自己的极好工具，这就是著名的Google API，在付出少许费用之后，你就可以在自己的程序里使用Google了（通常是Java），我曾经还一度想做一个Flash版的Google呢。此外还有用于处理“科学难题”的网格计算：Google Compute，模仿捐献家用计算能力以分析外星人电波的SETI@home，后者由Stanford提供。

Froogle也是一个伟大的设想，虽然它还没有中文版，但我已经领略到了它的能力。它提供一个商品的搜索引擎，让你可以在需要时浏览商品的价目和图片。这使得Froogle有时看起来很想ebay，况且Froogle还有它的WAP版，也就是移动版。Google Local又是一个有价值的作品，它使得Google可以作为旅游指南或者地图使用。即使是Google的web搜索也有了很多衍生用法，比如瞧天气啦，找手机归属地啦，当计算器用啦，当词典用啦，反向搜索啦什么的。

3。Google现在做什么
在客户端的竞争中Google并没有占到什么优势，MSN反而成了受益者，你想啊，搞软件设计谁能搞得过“买块肉SOFT”，Netscape、 Apple、IBM都尝试过，也不怕Google多尝试一次。但是Google却在这种内忧外患的情况下上了市，而且市场反映一片叫好！为了推陈出新，保持股价的攀升，Google采用了上市公司最喜欢华尔街最欣赏股民们最容易被欺骗的手法——虚伪扩张！一方面，Google大量投资研究操作系统、数据库和应用服务器这些网络商最赖以生存的技术；另一方面则投入大笔资金扩展业务领域，这种手段的优点是可以转嫁主营业务的成本和风险，做出更漂亮的财务报表，缺点是片面注重表面上的资源优化，往往错过改革技术和商业策略的最佳时机。

在Google陷入寻找新的扩展点而不能自拔时，一个新新人类的话题摆在了Google前进的道路上，这群人就是Blogger，他们要玩的就是Blog。说时迟，那时快！只见乌云密布，雷鸣电闪，咔喳一声晴天霹雳，Google站在Blogger.com面前，笑里藏刀的说：“天下英雄，唯使君与操尔！”在收购了Blogger之后，Google基本放弃了它建造blog.google.com的计划。

2004年愚人节，对于网络邮箱供应商来说简直就是一个鬼节，这一天Google推出了它的Gmail服务BETA版，它采用了非常具有神秘色彩并借助六度分隔和150法则而更具有神秘色彩的邀请发放方式。最令人头疼的是它提供1G的空间和压缩邮件（压缩意味着物理空间1G，而很多邮件供应商公布的空间是压缩之前的占用空间）。2005年的愚人节，Google更“丧心病狂”（开玩笑）的将这个数字增加到2G！跟进还是卖出？！这是其它邮箱供应商必须面对的一个抉择！

GDS（Google Desktop Search）是Google的另一个重磅炸弹，这个是用来对付微软的。是的，你没听错！当微软在它下一版Windows（长角）的计划中露出新版文件搜索引擎的设想时，Google已经把成型的产品送到了客户面前。但是在试用了几次之后我有点纳闷，为什么这个备受好评的GDS在我的机器上跟Lucene 一样难用（对不起一次骂了两位），它几乎搜不到什么有价值的文件——难道因为我用的是英文版？抑或是我没有掌握使用技巧？

4。Google遇到了什么困难
多少年来一个问题一直困扰着我，“一个以高科技著称于世的企业不会不在正面战场上胜过一个商业成熟的企业呢？”几乎每个受到工业革命和文艺复兴影响的人都会相信这句话。可恰恰是这句话导致了很多企业的失败。Google并未在正面击败Yahoo，相反，在与Yahoo的竞争中Google已经渐渐显出劣势的一面，这是由于“机器不能理解鸡肉的味道”的缘故吗？我们不得而知，但是有一点可以肯定，促使巴别塔停止建造的原因也在困扰着Google，简单的说就是全球化和本地化。在中文搜索引擎市场上，简体中文的第一是百度，其次是Yahoo，繁体中文的第一是Yahoo，其次是Google，日文版市场排名第一的还是Yahoo，第二名是MSN，俄文搜索引擎的老大也是俄罗斯的本地化引擎。面对这个局面，Google只能说OMG！（Oh！My God！）。下面这段文字摘自<<Google中文的三大软肋>>：

……据iResearch（艾瑞市场咨询）研究报告分析，百度仅用4年时间，远远领先于Google，百度拥有目前世界上最大的中文信息库，比Google中文更准确，更全面，快照功能也占优势……
……雅虎一直很重视本地化，收购3721则是最好的一例。在国内市场上，3721的本地化购物搜索非常好，再上本地化的商业搜索，更具竞争优势。从某种意义上来说，3721网络实名的目录，就是一个典型的中国本地化企业产品的目录。所以说，拥有3721之后，雅虎如虎添翼，对Google构成了更大威胁……
……在中文语言处理能力上，本地搜索公司的优势更让Google难堪。比如，《功夫》公映之前很久，在百度上检索“功夫”就能直接指向周星驰的电影，可是 Google搜索相同的“功夫”，则大失所望。因为这些时令性的关键词都需要专业团队去随时添加，由于Google缺乏专门针对中国市场的开发力量，尤其是对中国互联网信息检索存在的问题了解不透，所以，Google对于国内市场需求的反应速度很慢，本地化技术服务力量也跟不上，无法解决国内网民遇到的一些实际问题……

Google的新闻搜索也引来很大的争议，我们都知道如果一家媒体要摘录别人的新闻作为自己的新闻，那么他必须付费，可是如果这条新闻是搜索引擎搜出来的怎么办？如果这条新闻是和它的提供商几乎同时登出又怎么办？Google当然不会为他搜出来的每条新闻付费，而且，就像前面说的那样，Dvorak这样的同志又要大骂Google了，因为它扼杀了消费者冲浪的乐趣和获取别人没能及时获取的信息的喜悦感，以及Google的意志代替了互联网的意志等等。

5。Google以后会做什么
目前还不知道Google下一步想做什么，但是我们都知道了资本的魔力和技术的信仰在控制着它，这使它成为人类有史以来最有想象力的公司之一。

我们猜想Google不久就会开放它的Gmail供人们随意申请，但申请时仍需要提供一个唯一的其它邮箱的帐号，（就像非Logitech的老鼠标加钱换新罗技，随意一款老洗衣机加钱换新荣事达一样），现在Gmail的策略是每个用户可以邀请50个新用户参加，此外每20人次的Google Web Search使用就会放出一个新的邀请。

Picasa也将是Google发展的重头戏之一。前者是一个图片文件客户端，看起来好像很简单，肯定没有ACDSee做的好，但是在图片共享方面 Google可是从来没有放弃过啊。现在，Picasa又和Gmail结合到了一起，每个Gmail用户都可以用Picasa将图片上传到Gmail，这项功能大大加强了Picasa图片共享的能力。

此外，人工智能和大型计算技术也是Google发展的重要方向。不久之前Google发布了它的企业搜索服务器，虽然引来一路臭骂，但还是有一些专家认为这是个利好消息，说明Google正在别的盈利点上发觉自己的价值。概念已经有了，天价只是技术之不成熟性使然。这一趋势不仅可以从Google的产品上看出来，从Google的挖人策略也一样可见一斑。前不久，Google正式宣布它挖到了Java世界一只下金蛋的鹅——Joshua Bloch，这个人经常在我的梦中出现，要卖一本<<如来神掌>>给我！ 对不起，记错了，是一本<< Effective Java>>。说说J.Bloch的历史，可能很多人都会感到惊讶不已。他首先创造了曾在危难时期令整个Java世界恢复自信的Collection Framework，并获得了当年的Jolt大奖；后来为了让更多的Java程序员从Collection Framework的设计模式中收益（当时设计模式还不是很流行），他又以此为题写了<<Effective Java>>，并再次获得了Jolt大奖；为了在Java世界引入元模型的魔力，他继而提出了JSR175(A Metadata Facility for the JavaTM Programming Language)，并成为其首席专家；在Sun最危难的时刻挺身而出接掌Tiger（JDK 5.0）的大旗；在这之后，关于他的唯一新闻就是被Google挖走了。此外，Google还高薪挖走了无数把名字倒过来写我们都能认识的科学家， CSDN这样报道：

……接着，Google又把BEA的首席架构师Adam Bosworth拢入自己旗下。Bosworth在软件行业作为技术主管受到广泛的尊敬。在为新创企业Crossgain（2001年被BEA收购）工作之前，Bosworth曾在微软任职数年，并成功地从事于一些项目的开发，如微软的Access数据库。
他的跳槽来得太突然了，两个月以前，他还在供应商的“年度eWorld秀”中担任重要角色，并他的主题演讲中介绍Alchemy项目----一个建立下一代移动浏览器的计划。
Google的招兵买马计划一直在有条不紊的进行着，曾在SUN微系统工作的David Stoutamire，现在在Google工作。就在上星期，Neal Gafter,SUN公司的javac主管，也离开SUN转向Google。
不仅是Java方面，Greg Stein，曾是CollabNet项目经理,管理Subversion 项目并且发布了他们的SourceCast产品，现在在Google的博客软件组工作；Rob Pike，曾是贝尔实验室最初Unix团队成员之一,参与过Plan 9 和Inferno操作系统的开发，如今也投奔Google。
Google一直渴求人才，对于开发者来说，Google也是一个充满吸引力的地方。他只雇佣最棒的、最聪明的、近乎于天才的那些家伙，在笼络人才这方面，也只有微软可与之媲美。最近Java人才不断涌入Google究竟是巧合，或是Google准备尝试基于Java做一些事情，我们拭目以待……

如果我没记错的话，Google前不久还从微软挖走了一位足可以称为WindowsNT之父的人，Google之野心路人皆知。看看下面这则招聘启事也许你就会更了解这一点了：

Passionate about these topics? You should work at Google. • algorithms • artificial intelligence • compiler optimization • computer architecture • computer graphics   • data compression • data mining • file system design • genetic algorithms • information retrieval   • machine learning • natural language processing • operating systems • profiling • robotics   • text processing • user interface design • web information retrieval • and more! Send your resume and a brief cover letter to great-engineers@google.com.

6。Google应该做什么
这一节我们将抛弃所有商业的想法，认认真真的坐下来考虑一下技术问题，当然，这会使得我们对Google的要求过高，我们会把很多未能被实现的我们曾经的梦想都交给未来的Google，就像我们把Sun没有做到的强加给IBM，把IBM没有做到的强加给微软，把微软没有做到的强加给Netscape，把Netscapge没有做到的强加给Yahoo一样。

首先，Google应该认真考虑考虑语义网的问题了，我个人仍然认为这是互联网发展的正道。虽然RDF标准的发展雷声大雨点小，可是现在RSS已经如火如荼，这还只是语义网技术的一小部分，（就像WAP没什么用，但短信却发展起来一样），XSL和XSLT也是语义网的一小部分，它们将作为语义网与其展现之间的接口。我为什么要提语义网这个东西呢？举个例子你就能明白，比如我的Blog每篇文章每一页上都有菜单，都有最新评论、阅读排行榜和自定义列表，这些加速了访问者的效率，是富有亲和力的展现形式，但是对于Google来说这些都是垃圾，因为它们错误的表达了网页的含义，如果我要搜一篇阅读率极高的文章，可能搜出一堆没用的东西，而这些东西又不可能从页面上拿掉，所以Google必须自己去认。

反向快照可能是解决这个问题的临时方案。它的主要思想是Google首先发现别人是如何“描述”该网页的（通过链接的文字表达），再在该网页中找到与这个 “描述”相关的内容，把这部分内容作为该网页的高优先级内容，再把该网页与相同目录下的其它文件比较，将相同的部分列为低优先级的内容。（这是我个人想出来的方法，不知道可否奏效，估计可能会遇到性能问题）

其次，Google将面临语义搜索的问题。这是MSN正在开发的技术，我相信Google也一定在做。这项技术的目的是让使用者同计算机之间的交互变得更人性化，看起来好像是用户像计算机提出了一个问题，计算机利用Google这颗大脑找到答案然后告知。哈哈，这个镜头是不是有点眼熟，它多次在好莱坞的电影中出现，比如<<AI>>中的Dr.Know（无所不知博士）和<<时间机器>>中的图书馆管理员，他们都是语义Google的愿景和Use Case。其中最有趣的是Dr.Know，他首先让用户选择类别，然后提问，问题按个数记费，答案往往只给出一个——当然是人工智能觉得最符合问题的一个。这提示了我们带类别的语义识别可能将成为语义识别技术迈出的第一步。再看看Google英文版目前提供的收费服务Google Answer～～～有点意思吧？

第三是模式学习。不客气的讲，Google一直在以自己的想法在搜索。不是吗？Google把Spider找到的所有页面都认为是资源，所以对其涵盖的内容一视同仁，对其表达的形式漠不关心，而正确的方式应该是将页面和搜索用户都看成用户，把页面人性化，从页面中吸取人类思维的模式，进行模式学习。这种技术给Google带来的好处是巨大的，其实现技术也简单于语义理解。打个比方，对于Sina被盛大收购，很多新闻网站都作为专题加以报道，而对于Google来说，要等很久才能把新浪和盛大这两个单词联系起来，这中间的时间包括其它由人来更新的网站的更新时滞，其它网站对这些网站的连接的更新时滞，这些更新被Spider发现的时滞，发现后PageRank更新到合理数值（中间可能经过多次迭代）的时滞等等。这使得Google明显慢于人的反映速度，这也就直接的造成了上面所提到的<<功夫>>不能及时搜到的原因。靠人工智能实现本地化，这是一条路。

第四是信息源的深层发掘。这使得Google能触及互联网的死角，就像洗衣粉尽量触及衣物的死角一样，（“有汰渍，没污渍”），例子很简单，如果我在网页中加入一段Javascript，就可以很容易把网页引到另一个地址，而这个地址很有可能是Google没有涉及到的，浏览器却可以访问。

第五就是不得不提到的网格计算。因为Google的客户来自世界各地，一个日本人拜访Google和一个印第安人拜访Google在99.99％的概率上是不会访问相同内容的，因此将这两个人所要访问的内容放在一起实在是一种性能上的损失。最近听说Yahoo已经将中文搜索服务器迁到国内，这正是为了性能考虑的啊。当然，分布式服务器已经可以做到这一点了，那为什么还要网格呢？解释这个问题首先要从解释BT的原理开始，BT之所以让人们下载的那么快就是因为BT让Downloader成为其它Downloader的服务器，这种P2P的方式充分利用了Downloader的机器的计算能力和上行带宽。Google也可以做到这一点，例如我、我的邻居、李彦宏（百度总裁）和杨志远（Yahoo创始人之一）四人同时搜索了同一个关键字，假定服务器在中国，李彦宏首先获得了响应页面，我再访问时，Google通知我找李商量一下，李毫不犹豫的给了我页面，杨志远的请求收到处理，因为它不便于访问李彦宏或者我的机器，所以Google又给他开了一个响应页面，最后处理的是我的邻居，他的请求被推给了我，因为我们处在相同的子网内所以交流更为方便。原本四次的检索变成两次，即使加上两次简单的响应，总时间也大大缩短，假若我们四个人拜访Google的机会分别是10:10:2:1，结果就更不言自明了。如果Google在网格方面多追加一些研发资金，自然会比Yahoo做的好，这是由Google软件的架构决定的。

写这篇文章花了我整整一天的时间，我写这篇文章的开始时间是4日凌晨0点04分，现在已经快到5日的0点04分了，可是我还意犹未尽，为了不影响手头上的工作我决定就此打住，如果您有什么想法，请回帖指教，谢谢。

累死了的泡泡