巴别塔上的雇工

上一次Code Inspection的时候，才知道FxCop有一条规则是建议不要使用explicit static constructor，说是这样会有损performance。我知道非显示写static constructor和显示写static constructor的区别就是会让C#编译器是否产生beforefieldinit这个flag，但是真没在意这个flag会带来多少performance影响。

   1: class Foo

   2: {

   3:     private static string _msg = "Hello world";

   4:  

   5:     public static string Msg

   6:     {

   7:         get { return _msg; }

   8:     }

   9: }

  10:  

  11: class Bar

  12: {

  13:     private static string _msg;

  14:  

  15:     static Bar()

  16:     {

  17:         _msg = "Hello world";

  18:     }

  19:  

  20:     public static string Msg

  21:     {

  22:         get { return _msg; }

  23:     }

  24: }

上面两个类Foo和Bar，功能上完全一致，区别就是Bar有explicit static constructor，C#编译器在编译这两个类的时候，Foo会有beforefieldinit，而Bar没有。性能上的影响，就是使用Bar会慢一些，因此不提倡使用explicit static constructor。

我一直不觉牺牲可读性来换取performance提高是件好事，好在大多数情况下，也不是非写explicit static constructor不可。不过让我们看看不写explicit static constructor会带来多少性能上的好处。

   1: private static void TestFoo()

   2: {

   3:     Stopwatch sw = Stopwatch.StartNew();

   4:     for (int i = 0; i < Int32.MaxValue-1; ++i)

   5:     {

   6:         string msg = Foo.Msg;

   7:     }

   8:     sw.Stop();

   9:     Console.WriteLine(sw.ElapsedMilliseconds);

  10: }

  11: private static void TestBar()

  12: {

  13:     Stopwatch sw = Stopwatch.StartNew();

  14:     for (int i = 0; i < Int32.MaxValue-1; ++i)

  15:     {

  16:         string msg = Bar.Msg;

  17:     }

  18:     sw.Stop();

  19:     Console.WriteLine(sw.ElapsedMilliseconds);

  20: }

  21:  

  22: static void Main(string[] args)

  23: {

  24:     TestFoo();

  25:     TestBar();

  26: }

运行上面的code，结果是：

16395
16113

奇了怪了，不是说Foo会比Bar快吗？结果看来是Bar比Foo快。

不过上面用的是Visual Studio缺省配置Debug版，换成Release Build试试，结果是：

1011
7229

这么一看，Foo的确比Bar要快，而且要快得多。

在Release Build下，2,147,483,646(Int32.MaxValue-2)次调用，能够节省大约6秒，当必须使用explicit static constructor的时候，是否要在意这写performacen gains，就要看你自己来决定了。

值得一提的是，有时候我们就是需要explicit static constructor，比如我们构造一个singleton模式的时候，而beforefieldinit也并不像我们想象的那么简单，如果照办Spec上的说法，被标为beforefieldinit的类（也就是没有explicit static constructor的类）“有可能”会在使用某个static 方法的时候，type initializer还没有被调用，这就麻烦了。我问过Jeff Richter这个问题，Jeff说他觉得虽然Spec是这么写的，但是并不表示CLR是这么实现的，而且似乎实际中不会出现这种情况。但是，后来我在stackoverflow上看有人说自己遇到了这个现象，所以我们还是认为实际上CLR的确是按照Spec来实现的吧。

公司时不时会发T恤下来，有时候是为了参加某个活动有统一着装；部门有时候也会发T恤，是为了纪念某个产品的发布。一个结果就是，T恤成了我拥有最多的衣服类型:)

每次发下来的T恤，我都先看看是哪里产的，我发现一个规律，如果不是Made In China的，T恤的躯干部分都是一个桶状，也就是说左右腰部没有垂直的接缝。

最近部分发了Exchange Server 2010的纪念T恤，这次是Made in Hatti，和我总结的规律一样，这套T恤又是桶状的。如下图，在腋下，大部分T恤在虚线部分都是有垂直的接缝的，也就是说躯干部分是一前一后两块布缝合而成的，但是这套T恤就是一块整布。现在就检查一下你的T恤是怎么样的：）

我就是感到好奇的是，为什么大部分国产的T-Shirt都是用传统接缝方式制作的，而海地、多米尼加共和国这样的小国却采用了比较“先进”的无缝方式生产呢？也许有缝T恤都是供应内需，无缝的大多都用来出口吧。

生产这种无缝衣服应该不只是为了酷一些，而是为了降低生产成本，因为织布和剪裁是两个步骤，现在在机器上一次就织出成型的桶状布，虽然不能有Generic用途，但是这种布就是为了T恤而织的，降低了剪裁成本。

06年，Prison Break第一季播出的时候，不敢说万人空巷，但至少占了国内观看美剧相当大一块“市场份额”。PB第一季情节紧凑，悬念层出不穷，其大部分故事发生在一个封闭的空间中（Fox River监狱），很能刺激观众的神经，有这么巨大的影响不见怪。在第一季结尾，越狱小组终于逃脱高墙，又错过接应的飞机，只好在黑暗中狂奔逃脱，观众对这个结尾接受，大家都清楚这么受欢迎的剧集不拍续集那是傻子。

大家都希望PB第二季不要狗尾续貂，但是此剧还是走了下坡路，主角没怎么出风头，倒是反角T-Bag和Mahone让人印象深刻。

第二季还算靠着第一季的余威风光了一把，到第三季已经是非常的狗尾了，剧情没有之前经凑，观众们开始挑bug取乐。

我不明白为什么还要拍一个第四季，到最后，所有的人，从演员到编剧再到观众，都只能用“心不在焉”来形容，大家都知道此剧将完蛋，但是都抱一线希望结局能够重振一下雄风。可惜狗尾就是狗尾，态度决定一切，在这么心不在焉的态度下，此剧的结尾稀里糊涂乱七八糟，几伙地下工作者在洛杉矶你出卖我我算计你，然后转站迈阿密，继续你陷害我我绑架你，最后终于在彻底交代了一个阴谋论之后，草草收场。

Prison Break就这么结束了，多年之后，我们肯定还会谈论曾经有一个惊心动魄的Prison Break第一季，但不会愿意去说其狗尾续貂的续集。

电影《高考1977》讲的三十多年前文革刚结束时恢复高考制度的故事，谁进大学谁进不了，这就是选拔制度。

文革期间是单位推荐制，单位推荐某某人，然后筛选政审，并不需要考试。不过就如同电影中描述的，某些单位推举还有民主制度，农场的知青投票决定推荐谁，这种情况下，就会出现地下交易，比如两伙人说好了，这次都推荐A伙的某个人，下次推荐B伙的某个人，这样A伙和B伙的人胜率就高，好过两眼一摸黑地投票。这种地下交易也有问题，A伙的人得了好处，下次又不想帮B伙了，所以，还是回归到最原始的选拔制度，当然也是地下选拔制度——背大包，只要有人能够背三百斤重的麻包在大家面前走上一段制定的路，“王八蛋才不投他的票”，没有帮派背景，完全靠个人能力，还有群众监督，这样的选拔最公开最公平，但是，问题又来了，又不是只有体育大学，用这种纯靠体力的方式比赛当然不合适，还有一点，电影中没说破，如果完全用这种方式，女性是根本别想上大学了:)

看了这个电影，让人觉得我国的应试教育制度，好歹比文化大革命的推荐制要强。这种优越性，好比中国古代的科举制度相比于曹操靠贴榜招贤的优越性，虽然考试制度有缺陷，但是好歹还是比较公平，而且适合批量挑选人才，难怪科举制度存活了上千年。

我国高考制度曾几何时也就和科举制度一样，一座独木桥，过去了就牛了，所以也有现代范进，但这几年味道也变了。

首先，有的学校“不完全”看分数了，这看似向国际名校接轨了，但是就如我国众多与国际接轨的行为一样，这其实给本来比较公平的高考制度打开了腐败之门，这是个人观点：）还有，某某地区高考加分大多给了权贵子弟，官方出来辟谣说加分决不会考虑家庭出身，我想这种辟谣说了和没说一样；最后，最过分的，就算考生报考只看分数的学校，也不在乎那些加分，还是可能不公平，而且这种不公平是不管多努力都没用，因为你的高考成绩会被人盗取。

这样看来，本来比较公平的高考选拔制度，看起来也不怎么公平了。当然，对于批量选拔人才，这种制度还可以凑合着用，就赌对于大部分情况还是公平竞争了。

打《忍者龙剑传2》受到相当大的挫折，到第二关就完全打不过去，于是去网上搜集“秘籍”，一无所获。

我不大喜欢这样游戏，门槛忒高了点，难度非常大不说，也不给玩家投机取巧的方法。据说《忍龙2》的制作团队是除了名的不照顾入门级玩家的感受，有很多骨灰级玩家就喜欢这样风格的游戏，不过我不是，所以我只好放弃了。

有个术语叫Konami Code，源自于Konami出的游戏中的Cheat Code，当《魂斗罗》还是很高水平的游戏的时代，这段操作序列也是广为流传。

这个序列就是“上上下下左右左右BA”，真希望《忍龙2》也支持类似的Cheat Code，可惜没有。

写一段检测Konami Code的JavaScript code:

<html>

    <head>

        <script>

            var konami = new function $konami()

            {

                this._codes = "38,38,40,40,37,39,37,39,66,65",

                this._codeCount = 10,

                this.init = function $konami$init()

                {

                    this.contentDiv = document.getElementById("content");

                    this.keySeq = [];

                    var that = this;

                    window.onkeydown = function(ev) { that.onKeyDown(ev);};

                };

                this.onKeyDown = function $konami$onKeyDown(ev)

                {

                    var keyCode= ev.keyCode;

                    this.keySeq.push(keyCode);

                    //this.contentDiv.innerHTML += this.keySeq.toString() + "<br/>";

                    if (this.keySeq.toString() == this._codes)

                    {

                        alert("Konami Hit!!!");

                        this.keySeq = [];

                    }

                    if (this.keySeq.length > this._codeCount)

                    {

                        this.keySeq.shift;

                    }

                };

            };

        </script>

    </head>

    <body onload="konami.init();">

        <div id="content">

        </div>

    </body>

</html>

值得一提的是，使用onkeydown是为了cross-browser，在keydonw/keyup的事件中中检查keyCode，是唯一各浏览器行为一致的方式，这篇文章介绍得很详细。

在看《潜伏》之前，就听说有网友总结了《潜伏》中体现的“职场规则”，我很不以为然，不管怎么样，我相信编导的创作原动力并不是要用一个革命战争时代的故事来体现当前的职场规则。

上周末，从第一集开始看《潜伏》，更觉得“职场规则说”没有道理，直到——直到情节发展到军统改组为“保密局”，而且需要裁人。哇，看到Re-Org了，这个故事有点像是职场了，从这之后，越看越像。

我依然相信这个故事本身并不是用来映射职场的，但是这世界上的道理都是相通的，情报局的职业生涯和公司的职业生涯总还是有可以互通的地方。

在微软参与某个产品开发三个月以上，就有资格拿到一个Ship IT Award的牌子，可以放在桌上炫耀，好比军人胸前的军功章。

最近我拿到了Windows Live Wave 3的Ship IT铭牌，这样就攒了三块S牌子:

• Windows Live OneCare
• Windows Live Wave 2
• Windows Live Wave 3

不大清楚Live有没有Wave 1的牌子，也许没有，那么这三块牌子正好记录了Windows Live前三个版本的历程。

一般软件做到3.0版本，应该很成熟了，但是尽力三个Wave，到现在Windows Live还不算“成熟”，不过还是要Ship啊！

Ship就是硬道理，Ship才能证明价值，Ship才能赚钱，Ship才能获得真正的用户反馈。别管有多好的想法，要是不能变成软件或者服务给Ship出去，也都是枉然。

话说回来，Ship这么多东西了，如果还是不能获得成功，就需要反省一下是不是真的Ship了用户想要的东西，Ship完之后是不是真的收集采纳了用户的反馈，不能为了Ship而Ship，要为了提供价值而Ship，别每次Ship都只是和自己的上一个版本比，这就像左手和右手扳手腕，要和竞争对手比。

按照达尔文的进化论，并不是简单的“适者生存”，而是适应环境变化的物种能够生存。环境一直在变，不能适应变化就要北淘汰。

软件世界中，这种进化很大程度上是人为的，人（对于软件体来说就是神）要它进化，它就要进化。

曾经是Microsoft的成功产品，但是现在Microsoft正积极地将IE6和Windows XP人道毁灭，因为需要推广IE8和Windows 7，不能停留在过去，要向前看。如果用户不放起旧地产品，新的产品就没法卖。

在上面的刺杀列表中，应该加一个Windows Vista，过几年后，也许还会有IE8和Windows 7。