1。拳擊運動員
他一生中的每一時刻，都在痛苦和希望之間徘徊。一個沒有被打倒過的人不算是真正的拳擊手，只能算是拳擊運動的愛好者和參與者罷了。沒有人愿意跟一個沒有失 敗過的人打，就連電影百萬寶貝中的女人也這么想。這并不是說一個人若想稱為真正的拳擊手就要主動嘗試被人打倒的滋味，而是說如果你從未有過被人打倒的經歷 和體驗，你就不能很好的知道什么時候該勇往直前，什么時候該保護自己，如何保護自己，保護自己的哪里，用什么來保護自己，甚至，犧牲自己的什么來保護自 己！一個男人必然不會是一生都不需要保護自己的人，當然，一個男人也不能時時刻刻都在保護自己，正在保護自己的男人是痛苦的，他不得不忍受“我是男人，而 男人應該去保護別人”這樣狗屁不通的理論對自己的煎熬，別人的非議就更不用說，但是希望有隨時都會在他的心中點燃——下一刻，我將揮出我復仇的一拳！


2。賽車手
他一生中的每一時刻，對他來說都是一次信心的考驗。尤其是排名世界第二的賽車手，如果他挑戰自己的極限，他有可能命喪黃泉，如果他見好就收，他畢生取得的 成就都會在他死后煙消云散，甚至在生命的最后一段時間里不僅要忍受老去的軀體的折磨，還要忍受昔日崇拜者鄙視的目光。多數處在這個位置的男人都會選擇繼續 挑戰人生，畢竟只有第一能夠博得終身的成就和死后殊榮，但這樣做的結果往往也是死路一條——現實生活不會總像電影Troy那樣氣勢磅礴。在這一點上，商界 的很多男人選擇激流勇退，這樣做對他們來說叫做“留得青山在，不怕沒柴燒”，不知道這算不算是一種理性，倘若是，那這種理性究竟是人性的倒退，還是人類發 展的必然未來？

3。潛艇艇長
他一生中的每一時刻，都要隱藏自己內心的恐懼。他不能有恐懼，是的，就是這樣，或者說，他不能讓別人發現他的恐懼。在數百尺深的海底，每個人都會一定程度 的喪失他在陸地和海洋表面的理智與信心，而潛艇之長，作為幾十人到數百人的領導，更要無所不知，無所不能，且每時每刻都要讓別人感受到他的信心、樂觀與積 極，連他自己有時都被自己的表象所欺騙，簡直就像一個四處散發信心的廣播。更重要的一點，也是電影U571要向我們描述的一點是，一個合格的水手可以為了 別人犧牲自己，這無可厚非，可是一個艇長不僅僅要有隨時犧牲自己的勇氣，還要有為了整艘船犧牲個別船員的洞察力和決策力。這往往也是一個男人不易被人理解 的地方：該犧牲自己時犧牲自己，該犧牲別人時犧牲別人。

（轉載本文需注明出處：Brian Sun @ 爬樹的泡泡[http://m.tkk7.com/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分了，可是我還意猶未盡，為了不影響手頭上的工作我決定就此打住，如果您有什么想法，請回帖指教，謝謝。

累死了的泡泡