Cat in Chinese

让 JavaScript 轻松支持函数重载 (Part 2 - 实现)

2009-07-02T15:28:00.002+08:00

在上一篇文章里，我们设计了一套能在JavaScript中描述函数重载的方法，这套方法依赖于一个叫做Overload的静态类，现在我们就来看看如何实现这个静态类。

识别文本签名

我们先来回顾一下上一篇文章中提到的Overload用例：

 var extend = Overload
  .add("*, ...",
    function(target) { })
  .add("Boolean, *, ...",
    function(deep, target) { });

我们允许用户输入一个字符串，表示某一个重载的签名。在用户调用函数时，我们需要拿着用户输入的参数实例去跟签名上的每一个参数类型作比较，因此我们需要先把这个字符串转换为类型数组。也就是说，字符串"Boolean, Number, Array"应该转换为数组[Boolean, Number, Array]。

在进行转换之前，我们先要考虑处理两个特殊类型，就是代表任意类型的"*"，和代表任意数量的"..."。我们可以为它们定义两个专有的类型，以便在Overload内对它们做出特殊的兼容性处理：

Overload.Any = function() {};
Overload.More = function() {};

在有了这两个类型之后，字符串"Boolean, *, ..."就会被正确转换为数组[Boolean, Overload.Any, Overload.More]。由于Overload.Any和Overload.More都是函数，自然也都可以看做类型。

在这两个类型得到正确处理后，我们就可以开始编写识别文本签名的转换函数了：

if (signature.replace(/(^\s+|\s+$)/ig, "") == "") {
  signature = [];
} else {
  signature = signature.split(",");
  for (var i = 0; i < signature.length; i++) {
    var typeExpression =
      signature[i].replace(/(^\s+|\s+$)/ig, "");
    var type = null;
    if (typeExpression == "*") {
      type = Overload.Any;
    } else if (typeExpression == "...") {
      type = Overload.More;
    } else {
      type = eval("(" + typeExpression + ")");
    }
    signature[i] = type;
  }
}

我想这段代码相当容易理解，因此就不再解释了。我第一次写这段代码时忘记写上面的第一个if了，导致空白签名字符串""无法被正确识别为空白签名数组[]，幸好我的unit test代码第一时间发现了这个缺陷。看来编写unit test代码还是十分重要的。

匹配函数签名

在我们得到函数签名的类型数组后，我们就可以用它和输入参数的实例数组做匹配了，以此找出正确的重载。在讨论具体如何匹配函数签名以前，我们先来看看C#或VB.NET这样的语言是如何处理函数重载匹配的。一般语言进行函数重载匹配的流程都是这样子的：

参数个数 - 参数个数不对的重载会被排除掉
参数类型 - 参数类型无法隐式转换为签名类型的会被排除掉
匹配个数 - 排除完毕后，剩下匹配的签名个数不同处理方法也不同
- 0个匹配 - 没有命中的匹配
- 1个匹配 - 这个就是命中的匹配
- 2个或以上的匹配 - 如果能在这些匹配中找出一个最佳匹配，那就命中最佳匹配；否则不命中任何匹配

在这一节里面，我们先处理流程中的前两个步骤，把参数个数或参数类型不一致的签名去掉：

var matchSignature = function(argumentsArray, signature) {
  if (argumentsArray.length < signature.length) {
    return false;
  } else if (argumentsArray.length > signature.length
      && !signature.more) {
        return false;
  }
  for (var i = 0; i < signature.length; i++) {
    if (!(signature[i] == Overload.Any
      || argumentsArray[i] instanceof signature[i]
      || argumentsArray[i].constructor
        == signature[i])) {
          return false;
    }
  }
  return true;
};

为了作长度对比，我们需要在这个函数外对表示任何参数个数的"..."作一下特殊处理：

if (signature[signature.length - 1] == Overload.More) {
  signature.length = signature.length - 1;
  signature.more = true;
}

这一段代码将会整合到第一节的转换函数末端，以便matchSignature函数能够轻易判断出参数与签名是否匹配。在最理想的情况下，我们对输入参数类型匹配到0个或1个重载，这样我们很容易就判断出命中哪个重载了。但如果有2个或以上的重载匹配，那么我们就要从中挑选一个最优的了，这正是下一节要讨论的内容。

处理多重匹配

关于C#是如何从多重匹配中选出较为匹配的重载，可以看C# Language Specification中的有关章节。我觉得通过三个简单的例子就能说明问题：

 long Sum(int x, int y) { return x + y; }
 long Sum(long x, long y) { return x + y; }
Sum(0, 1);

由于0和1这两个参数会被编译器理解为int类型，对于第1个重载它们都不用进行类型转换，都与第2个重载它们都要进行类型转换，因此第1个重载较优。

 long Sum(int x, long y) { return x + y; }
 long Sum(long x, int y) { return x + y; }
Sum(0, 1);

在第1个参数上，第1个重载较优；在第2个参数上，第2个重载较优。在这种情况下，任何一个重载都不优于另一个，找不到较优重载编译器就报错。

 long Sum(int x, int y) { return x + y; }
 long Sum(int x, long y) { return x + y; }
 long Sum(long x, int y) { return x + y; }
Sum(0, 1);

在第1个参数上，第1个重载优于第3个重载，于第2个重载无异；在第2个参数上，第1个重载优于第2个重载，于第3个重载无异。尽管第2个重载于第3个重载分不出个优劣来，但我们可以确定第1个重载比它们都要好，因此编译器选择了第1个重载。

假设我们有一个overloadComparator的比较函数，可以比较任意两个签名之间的优劣，我们需要对签名仅仅两两比较，以找出最优重载吗？事实上是不需要的，我们可以利用Array的sort方法，让它调用overloadComparator进行排序，排序后再验证前两名的关系就可以了——如果并列，则不命中任何一个；如果有先后之分，则命中第一个。

具体的overloadComparator代码就不在这里给出了，它依赖于另一个名为inheritanceComparator的比较函数来对比两个签名的参数类型哪一个更贴实际传入的参数类型，里面用到了一种比较巧妙的方法来判断两个类型是否为继承关系，以及是谁继承自谁。

小结

现在我们有了一个JavaScript的函数重载库，完整代码请看这里：函数重载库Overload。希望这个库能有效帮助大家提升JavaScript代码的可读性，降低大型Ajax项目的维护成本。如果大家希望将来继续读到类似的JavaScript开发模式相关的文章，不妨考虑订阅我的博客：

Cat in Chinese (feed)
Cat in dotNET (feed)

让 JavaScript 轻松支持函数重载 (Part 1 - 设计)

2009-07-02T09:16:00.001+08:00

JavaScript支持重载吗？

JavaScript支持函数重载吗？可以说不支持，也可以说支持。说不支持，是因为JavaScript不能好像其它原生支持函数重载的语言一样，直接写多个同名函数，让编译器来判断某个调用对应的是哪一个重载。说支持，是因为JavaScript函数对参数列表不作任何限制，可以在函数内部模拟对函数重载的支持。

实际上，在很多著名的开源库当中，我们都可以看到函数内部模拟重载支持的设计。例如说jQuery的jQuery.extend方法，就是通过参数类型判断出可选参数是否存在，如果不存在的话就对参数进行移位以确保后面的逻辑正确运行。我相信很多人在写JavaScript时也写过类似的代码，以求为功能丰富的函数提供一个（或多个）简单的调用入口。

不过做种做法一个根本的问题，那就是违反了DRY原则。每个支持重载的函数内部都多出来一段代码，用于根据参数个数和参数类型处理重载，这些代码暗含着重复的逻辑，写出来却又每一段都不一样。此外，这些代码要维护起来也不容易，因为阅读代码时你并不能一眼看出函数支持的几种重载方式是什么，要对重载做出维护自然也困难。

描述重载入口的DSL

我希望能够在JavaScript中以一种简单的方式来描述重载入口。最好就如同在其它语言中一样，使用函数签名来区分重载入口，因为我认为函数签名就是这方面最好的DSL。我假想中最符合JavaScript语法的重载入口描述DSL应该是这样子的：

var sum = new Overload();
sum.add("Number, Number",
  function(x, y) { return x + y; });
sum.add("Number, Number, Number",
  function(x, y, z) { return x + y + z; });

在描述好重载入口与对应函数体后，对sum函数的调用应该是这样子的：

sum(1, 2);
sum(1, 2, 3);

上述代码在我看来非常清晰，也非常容易维护——你可以一眼看得出重载入口的签名，并且要修改或者增加重载入口都是很容易的事情。但是我们遇到了一个问题，那就是JavaScript里面的函数是不能new出来的，通过new Overload()获得的对象一定不能被调用，为此我们只能把Overload做成一个静态类，静态方法返回的是Function实例：

var sum = Overload
  .add("Number, Number",
    function(x, y) { return x + y; })
  .add("Number, Number, Number",
    function(x, y, z) { return x + y + z; });

必要的重载入口支持

想象一下，有哪些常见的JavaScript函数入口是用上述DSL无法描述的？我所知道的有两种：

任意类型参数

假想我们要写一个each函数，对于Array就迭代它的下标，对于其它类型就迭代它的所有成员，这两个函数入口的参数列表如何声明？如果用C#，我们会如此描述两个函数入口：

void Each(IEnumerable iterator) { }
void Each(object iterator) { }

然而在JavaScript当中，Object不是一切类型的基类，(100) instanceof Object的结果为false，所以我们不能用Object来指代任意类型，必须引入一个新的符号来指代任意类型。考虑到这个符号不应该与任何可能存在的类名冲突，所以我选择了用"*"来表示任意类型。上述C#代码对应的JavaScript应该是这样子的：

var each = Overload
  .add("Array",
    function(array) { })
  .add("*",
    function(object) { });

任意数量参数

在JavaScript的函数里面，要求支持任意数量参数是很常见的需求，相信使用率比C#里面的params关键字要多得多。在我们之前制定的规则当中，这也无法描述的，因此我们要引入一个不和类名冲突的符号来表示C#中的params。我选择了用"..."表示params，意思是这里出现任意多个参数都是可以接受的。让我们看看jQuery.extend的重载应该如何描述：

 var extend = Overload
  .add("*, ...",
    function(target) { })
  .add("Boolean, *, ...",
    function(deep, target) { });

小结

在这篇文章当中，我们尝试设计出一种适用于JavaScript且易读易维护的函数重载写法。在下一篇文章当中，我们将会尝试编写Overload类，以实现这一设计。如果你不希望错过的话，欢迎订阅：

Cat in Chinese (feed)
Cat in dotNET (feed)

写个 JavaScript 异步调用框架 (Part 6 - 实例 & 模式)

2009-07-01T21:17:00.002+08:00

我们用了5篇文章来讨论如何编写一个JavaScript异步调用框架（问题 & 场景、用例设计、代码实现、链式调用、链式实现），现在是时候让我们看一下在各种常见开发情景中如何使用它了。

封装Ajax

设计Async.Operation的最初目的就是解决Ajax调用需要传递callback参数的问题，为此我们先把Ajax请求封装为Async.Operation。我在这里使用的是jQuery，当然无论你用什么基础库，在使用Async.Operation时都可以做这种简单的封装。

var Ajax = {};

Ajax.get = function(url, data) {
  var operation = new Async.Operation();
  $.get(url, data, function(result) {
    operation.yield(result);
  }, "json");
  return operation;
};

Ajax.post = function(url, data) {
  var operation = new Async.Operation();
  $.post(url, data, function(result) {
    operation.yield(result);
  }, "json");
  return operation;
};

在我所调用的服务器端API中，只需要GET和POST，且数据都为JSON，所以我就直接把jQuery提供的其它Ajax选项屏蔽掉了，并设置数据类型为JSON。在你的项目当中，也可以用类似的方式将Ajax封装为若干仅仅返回Async.Operation的方法，将jQuery提供的选项都封装在Ajax这一层内，不再向上层暴露这些选项。

调用Ajax

把Ajax封装好后，我们就可以开始专心写业务逻辑了。

假设我们有一个Friend对象，它的get方法用于返回单个好友对象，而getAll方法用于返回所有好友对象。于此对应的是两个服务器端API，friend接口会返回单个好友JSON，而friendlist接口会返回所有好友名称组成的JSON。

首先我们看看较为基础的get方法怎么写：

function get(name) {
  return Ajax.get("/friend",
    "name=" + encodeURIComponent(name));
}

就这么简单？对的，假如服务器端API返回的JSON结构正好就是你要的好友对象结构的话。如果JSON结构和好友对象结构是异构的，或许你还要加点代码来把JSON映射为对象：

function get(name) {
  var operation = new Async.Operation()
  Ajax.get("/friend", "name=" + encodeURIComponent(name))
    .addCallback(function(json) {
      operation.yield(createFriendFromJson(json));
    });
  return operation;
}

Ajax队列

接下来我们要编写的是getAll方法。因为friendlist接口只返回好友名称列表，因此在取得这份列表后我们还要逐一调用get方法获取具体的好友对象。考虑到在同时进行多个friend接口调用可能触发服务器的防攻击策略，导致被关小黑屋一段时间，所以对friend接口的调用必须排队。

function getAll(){
  var operation = new Async.Operation();
  var friends = [];
  var chain = Async.chain();
  Ajax.get("/friendlist", "")
    .addCallback(function(json) {
      for (var i = 0; i < json.length; i++) {
        chain.next(function() {
          return get(json.shift())
            .addCallback(function(friend) {
              friends.push(friend);
            });
        });
      }
      chain
        .next(function() { operation.yield(friends); })
        .go();
    })
  return operation;
}

在这里，我们假设friendlist接口返回的JSON就是一个Array，在获取到这个Array后构造一个等长的异步调用队列，其中每一个调用的逻辑都是一样的——取出Array中首个好友的名称，用get方法获取对应的好友对象，再将好友对象放入另一个Array中。在调用队列的末端，我们再追加了一个调用，用于返回保存好友对象的Array。

在这个例子当中，我们没有利用调用队列会把上一个函数的结果传递给下一个函数的特性，不过也足够展示调用队列的用途了——让多个底层为Ajax请求的异步操作按照固定的顺序阻塞式执行。

由于底层异步函数返回的就是Async.Operation，你可以直接把它传递给next方法，也可以用匿名函数包装后传递给next方法，而匿名函数内部只需要一个return。

延时函数

在上面的例子中，使用队列是为了避免触发服务器的防攻击策略，但有时候这还是不够的。例如说，服务器要求两个请求之间至少间隔500毫秒，否则就认为是攻击，那么我们就要在队列里面插入这个间隔了。

在原本next方法调用的匿名函数中手动加入setTimeout是一个办法，但为什么我们不写一个辅助函数来解决这类问题呢？让我们来写一个辅助方法并让它和Async.Operation无缝结合起来。

Async.wait = function(delay, context) {
  var operation = new Async.Operation();
  setTimeout(function() {
    operation.yield(context);
  }, delay);
  return operation;
};

Async.Operation.prototype.wait = function(delay, context) {
  this.next(function(context) {
    return Async.wait(delay, context);
  });
}

在有了这个辅助方法后，我们就可以在上述getAll方法中轻松实现在每个Ajax请求之间间隔500毫秒。在for循环内的加上对wait的调用就可以了。

for (var i = 0; i < json.length; i++) {
  chain
    .wait(500)
    .next(function() {
      return get(json.shift())
        .addCallback(function(friend) {
          friends.push(friend);
        });
  });
}

小结

通过一些简单的例子，我们了解到了Async.Operation常见的使用方式，以及在有需要的时候如何扩展它的功能。希望Async.Operation能够有效帮助大家提高Ajax应用的代码可读性。

最后，如果大家希望将来继续读到类似的JavaScript开发模式相关的文章，不妨考虑订阅我的博客：

Cat in Chinese (feed)
Cat in dotNET (feed)

写个 JavaScript 异步调用框架 (Part 5 - 链式实现)

2009-06-30T23:33:00.002+08:00

在上一篇文章里面，我们为异步调用框架设计了一种链式调用方式，来增强异步调用队列的代码可读性，现在我们就来编写实现这部分功能的代码。

调用入口

链式调用存在Async.go方法和Async.chain方法两个入口，这两个入口本质上是一致的，只是Async.chain方法在调用时先不提供初始参数，而Async.go方法在调用时提供了初始参数并启动异步调用链。

Async.chain = function() {
  var chain = new Async.Operation({ chain: true });
  return chain;
};

Async.go = function(initialArgument) {
  return Async.chain().go(initialArgument);
}

在这里我们可以看到，链式调用本身也是一个Async.Operation，链式调用所需的go方法和next方法都是在Async.Operation上面做的扩展，并且这个扩展不会很难，这将在下一小节说明。

扩展方法

我们都知道，通过addCallback方法添加的回调函数是会被逐一执行的，至少同步函数如此，因此我们可以用Async.Operation的这一特性来维护异步调用队列，前提是我们为它加上对异步调用进行队列的支持。

对于异步调用进行队列的支持，我们稍后再来处理，首先我们利用现成的addCallback方法和yield方法扩展出go方法和next方法。

this.go = function(initialArgument) {
  return this.yield(initialArgument);
}

this.next = function(nextFunction) {
  return this.addCallback(nextFunction);
};

实际上，go方法和next方法直接调用的正是yield方法和addCallback方法。go方法的语义与yield方法一样，传递一个参数给Async.Operation实例，并且启动调用队列。同时，next方法的语义和addCallback方法，添加一个调用到队列的末端。

异步队列

如何才能让原本仅支持同步的队列变得也支持异步？这需要检测队列中的每一个调用的返回，如果返回类型为Async.Operation，我们知道是异步调用，从而使用特殊的方法等它执行完后再执行下去。

callbackResult = callback(self.result);
self.result = callbackResult;
if (callbackResult && callbackResult instanceof Async.Operation) {
  innerChain = Async.chain();
  while (callbackQueue.length > 0) {
    innerChain.next(callbackQueue.shift());
  }
  innerChain.next(function(result) {
    self.result = result;
    self.state = "completed";
    self.completed = true;
    return result;
  });
  callbackResult.addCallback(function(result) {
    self.result = result;
    innerChain.go(result);
  });
}

如果调用返回了一个Async.Operation实例，我们就利用它自身的addCallback方法帮我们执行队列中余下的调用。准确来说，是我们构造了一个新的调用链，把队列余下的调用都转移到新的调用链上，然后让当前异步调用在回调中启动这个新的调用链。

此外还有一些地方我们需要略作修改，以兼容新的异步调用队列的。例如result、state、completed的状态变更，在链式调用中是有所不同的。

小结

我们在原有的Async.Operation上略作修改，使得它支持异步调用队列，完整的代码看这里：支持链式调用的异步调用框架Async.Operation。

现在我们已经拥有了一个功能强大的Async.Operation，接下来我们就要看看如何将它投入到更多常见的使用模式中去，如果你不希望错过相关讨论的话，欢迎订阅我的博客：

Cat in Chinese (feed)
Cat in dotNET (feed)

中国程序员有美国梦吗？

2009-06-15T02:30:00.001+08:00

Jeff最近转载了一篇名为《贺计算机成“就业最困难专业”》的文章，然后抛出了一个问题来，问大家对此看法如何，接着自然又引起了新一轮博客园首页发文热潮。对此，我站在我的角度说说我的看法。

大浪淘沙，金子难寻

1848年，美国爆发了加州淘金热潮，大量人口涌到加州进行淘金，其直接后果就是让一个叫旧金山小村庄的转眼间变成了一座大城市。在淘金热潮之初，你拿个筛子在河床里筛泥沙也能找到金子，这是何其容易的事情。但我们假想一下，如果当时一个淘金者拿着他的筛子跑到中国来，他能够淘到金子吗？我觉得是不可以的。这不是说中国的黄金矿藏量就比不上美国的一个州，而是中国没有如此高浓度而且可以进行露天开采的金矿。

1971年，旧金山湾区南端由于“淘沙子”出了名，因而被大家叫做硅谷。1998年，Google在硅谷诞生了，然后开始疯狂地吸收硅谷乃至全球的技术人才。2006至2007年，Google在中国进行大规模招聘，这时候他们遇到了跟淘金者中国之行一样的难题……

中国是第一个成功迫使Google进行笔试的国家。这句话说出来可能会让大家觉得十分搞笑，国内哪家公司招聘一线工程师不是先笔试再面试的。在人力资源供求相当的国家里，确实不需要笔试这轮筛选。有资质并且自信有资格来应聘的人，一般都能够得到充分的沟通，然后再确定这份工作是否适合。但这在人力资源明显供过于求的中国来说，就一点也不现实。

Google中国也有高层承认，以ACM/ICPC竞赛成绩来挑人确实有所缺陷，很多适合这份工作的人会被直接淘汰掉，连面对面或电话沟通的机会也没有。但假如你去看一下Google中国的校园招聘场面，看一下在各省重点大学里连开多个大教室进行笔试的情景，你不得不承认，要跟所有这些学生进行沟通的成本实在是连Google中国也支付不起。

总结一下，中国不是没有人才，也不是培养人才的方法有严重缺陷，至少这些都不是根本问题。根本问题是，在如此庞大的人口基数下，再好的企业都只能选用一套折中的人才选拔方案。你不能怪企业，说假如能生在美国你就能被Google美国所挖掘，而现在则被Google中国拒之门外。

人人都会发光的时候你该怎么办？

有时候用“是金子早晚会发光”的说法来自我安慰一下，也不是什么坏事。但当你发现人人都会发光的时候，你就知道事情有多不好了。

我们来做个数学建模，假设美国计算机人才中的top 100, top 1,000, top 10,000分别叫做A类、B类、C类。那么美国的人力资源供需关系大概是这样的：

需求：100人；供应：100人。
需求：1,000人；供应：1,000人。
需求：10,000人；供应：10,000人。

在保持A类、B类、C类界线不变的情况下，放到中国来很可能就是这样子的：

需求：500人；供应：1,000人。
需求：5,000人；供应：100,000人。
需求：50,000人；供应：10,000,000人。

就算中国的人才需求是美国的5倍，但依然供过于求。就算顶级人才的供求矛盾不明显，人才结构上的不合理也会给底层造成巨大的压力。

在A类里面，只有500人做不了自己应做的工作，被迫降级去做B类的工作。对于人口如此众多的一个国家来说，让500人屈就一下不是什么大问题。在B类里面，会有95,000人做不了自己应做的工作。而到了C类里面，会有9,950,000人做不了自己应做的工作，这时候问题就很严重了。

如果你搞不懂上面那堆数字说的是什么，那么我尝试换用浅白一些的语言来再说一次。如果你在美国，并且你达到了Microsoft美国招聘的要求，那么你成功加入Microsoft的概率就相当高了，因为你和Microsoft相互需要对方。

但如果你在中国，并且你达到了Microsoft中国招聘的要求，那么你成功加入Microsoft的概率并不怎么高，因为跟你一样符合这一条件的人数要远多于Microsoft的需求。如果你想要确保一个较高的应聘成功率，那么你必须远高于Microsoft的招聘要求。

没有压力的都跳槽了

假如我们把胜任某个职位的人简单分为两类：刚刚好胜任的，以及过度胜任的。那么，我们可以得到一个有趣的推论。

刚刚好胜任的人，是一定很有压力的。如果上面的分析没错的话，你之所以能够获得这个职位，一定程度上依赖于运气。好几个拥有同等实力的人跟你抢这个职位，尽管他们没能抢到，但依旧对此虎视眈眈，时刻准备着抢你饭碗。企业没理由对此坐视不理，一定会让你一直处于失业的边缘，以此作为筹码逼你好好干活，这时候你没压力才怪。

过度胜任的人，忠诚度一定会打折扣。总有更好的职位在对你招手，尽管你知道那些职位你只能凭运气获得，尽管你知道得到了你也站到了失业的边缘上，但你就不心动吗？肯定还是会心动的。

知足常乐者？估计在顶端会多一些。我和Jeff这样的，属于在国内少数算是享有American Dream的人，也就是能够通过自己的奋斗来获得应有的财富与社会地位。Jeff倾向于认为这对广大程序员普遍适用，并且鼓励大家都去追求自己的梦想。然而我得到的结论却并非如此。对于这事情，你怎么看？

写个 JavaScript 异步调用框架 (Part 4 - 链式调用)

2009-05-08T15:29:00.004+08:00

我们已经实现了一个简单的异步调用框架，然而还有一些美中不足，那就是顺序执行的异步函数需要用嵌套的方式来声明。

现实开发中，要按顺序执行一系列的同步异步操作又是很常见的。还是用百度Hi网页版中的例子，我们先要异步获取联系人列表，然后再异步获取每一个联系人的具体信息，而且后者是分页获取的，每次请求发送10个联系人的名称然后取回对应的具体信息。这就是多个需要顺序执行的异步请求。

为此，我们需要设计一种新的操作方式来优化代码可读性，让顺序异步操作代码看起来和传统的顺序同步操作代码一样优雅。

传统做法

大多数程序员都能够很好的理解顺序执行的代码，例如这样子的：

var firstResult = firstOperation(initialArgument);
var secondResult = secondOperation(firstResult);
var finalResult = thirdOperation(secondResult);
alert(finalResult);

其中先执行的函数为后执行的函数提供所需的数据。然而使用我们的异步调用框架后，同样的逻辑必须变成这样子：

firstAsyncOperation(initialArgument)
  .addCallback(function(firstResult) {
    secondAsyncOperation(firstResult)
      .addCallback(function(secondResult) {
        thirdAsyncOperation(secondResult)
          .addCallback(function(finalResult) {
            alert(finalResult);
        });
    });
});

链式写法

我认为上面的代码实在是太不美观了，并且希望能够改造为jQuery风格的链式写法。为此，我们先构造一个用例：

Async.go(initialArgument)
  .next(firstAsyncOperation)
  .next(secondAsyncOperation)
  .next(thirdAsyncOperation)
  .next(function(finalResult) { alert(finalResult); })

在这个用例当中，我们在go传入初始化数据，然后每一个next后面传入一个数据处理函数，这些处理函数按顺序对数据进行处理。

同步并存

上面的用例调用到的全部都是异步函数，不过我们最好能够兼容同步函数，让使用者无需关心函数的具体实现，也能使用这项功能。为此我们再写一个这样的用例：

Async.go(0)
  .next(function(i) { alert(i); return i + 1; })
  .next(function(i) {
    alert(i);
    var operation = new Async.Operation();
    setTimeout(function() { operation.yield(i + 1); }, 1000);
    return operation;
  })
  .next(function(i) { alert(i); return i + 1; })
  .next(function(i) { alert(i); return i; });

在上述用例中，我们期待能够看到0, 1, 2, 3的提示信息序列，并且1和2之间间隔为1000毫秒。

异步本质

一个链式调用，本质上也是一个异步调用，所以它返回的也是一个Operation实例。这个实例自然也有result、state和completed这几个字段，并且当整个链式调用完成时，result等于最后一个调用返回的结果，而completed自然是等于true。

我们可以扩展一下上一个用例，得到如下用例代码：

var chainOperation = Async.go(0)
  .next(function(i) { alert(i); return i + 1; })
  .next(function(i) {
    alert(i);
    var operation = new Async.Operation();
    setTimeout(function() { operation.yield(i + 1); }, 1000);
    return operation;
  })
  .next(function(i) { alert(i); return i + 1; })
  .next(function(i) { alert(i); return i; });

setTiemout(function() { alert(chainOperation.result; }, 2000);

把链式调用的返回保存下来，在链式调用完成时，它的result应该与最后一个操作的返回一致。在上述用例中，也就是3。

调用时机

尽管我们提供了一种链式调用方式，但是用户不一定会按照这种固定的方式来调用，所以我们仍然要考虑兼容用户的各种可能用法，例如说异步地用next往调用链添加操作：

var chainOperation = Async.go(0);
chainOperation.next(function(i) { alert(i); return i + 1; });
setTimeout(function() {
  chainOperation.next(function(i) {
    alert(i);
    var operation = new Async.Operation();
    setTimeout(function() { operation.yield(i + 1); }, 2000);
    return operation;
  })
}, 1000);
setTimeout(function() {
  chainOperation.next(function(i) { alert(i); return i + 1; });
}, 2000);

在这个用例当中，用户每隔1000毫秒添加一个操作，而其中第二个操作耗时2000毫秒。也就是说，添加第三个操作时第二个操作还没返回。作为一个健壮的框架，必须要能兼容这样的使用方式。

此外我们还要考虑，用户可能想要先构造调用链，然后再执行调用链。这时候用户就会先使用next方法添加操作，再使用go方法执行。

var chainOperation = Async
  .chain(function(i) { alert(i); return i + 1; })
  .next(function(i) {
    alert(i);
    var operation = new Async.Operation();
    setTimeout(function() { operation.yield(i + 1); }, 2000);
    return operation;
  })
  .go(0)
setTimeout(function() {
  chainOperation.next(function(i) { alert(i); return i + 1; })
}, 1000);

在上述用例中，用户通过chain和next添加了头同步操作和异步操作各一个，然后用go执行调用链，在调用链执行完毕之前又用next异步追加了一个操作。一个健壮的框架，在这样的用例当中应该能够如同用户所期望的那样提示0, 1, 2。

小结

针对链式调用的需求，我们设计了如此多的用例，包括各种奇怪的异步调用方式。最终如何实现这样的功能呢？如果你想知道的话，欢迎订阅我的博客：

Cat in Chinese (feed)
Cat in dotNET (feed)

写个 JavaScript 异步调用框架 (Part 3 - 代码实现)

2009-05-07T14:51:00.002+08:00

在上一篇文章里，我们说到了要实现一个Async.Operation类，通过addCallback方法传递回调函数，并且通过yield方法返回回调结果。现在我们就来实现这个类吧。

类结构

首先我们来搭一个架子，把需要用到的似有变量都列出来。我们需要一个数组，来保存回调函数列表；需要一个标志位，来表示异步操作是否已完成；还可以学IAsyncResult，加一个state，允许异步操作的实现者对外暴露自定义的执行状态；最后加一个变量保存异步操作结果。

var Cat = {};

Async = {
  Operation: {
    var callbackQueue = [];
    this.result = undefined;
    this.state = "waiting";
    this.completed = false;
  }
}

addCallback方法

接下来，我们要实现addCallback方法，它的工作职责很简单，就是把回调函数放到callbackQueue中。此外，如果此时completed为true，说明异步操作已经yield过了，则立即调用此回调。

this.yield = function(callback) {
  callbackQueue.push(callback);
  if (this.completed) {
    this.yield(this.result);
  }
  return this;
}

我们假设yield方法会把callbackQueue中的回调函数逐个取出来然后调用，因此如果compeleted为true，则使用已有的result再调用一次yield就可以了，这样yield自然会调用这次添加到callbackQueue的回调函数。

至于最后的return this;，只是为了方便jQuery风格的链式写法，可以通过点号分隔连续添加多个回调函数：

asyncOperation(argument)
  .addCallback(firstCallback)
  .addCallback(secondCallback);

yield方法

最后，我们要实现yield方法。它需要将callbackQueue中的回调函数逐个取出来，然后都调用一遍，并且保证这个操作是异步吧。

this.yield = function(result) {
  var self = this;
  setTimeout(function() {
    self.result = result;
    self.state = "completed";
    self.completed = true;
    while (callbackQueue.length > 0) {
      var callback = callbackQueue.shift();
      callback(self.result);
    }
  }, 1);
  return this;
}

通过使用setTimeout，我们确保了yield的实际操作是异步进行的。然后我们把用户传入yield的结果及相关状态更新到对象属性之上，最后遍历callbackQueue调用所有的回调函数。

小结

这样我们就做好了一个简单的JavaScript异步调用框架，完整的代码可以看这里：异步调用框架Async.Operation。

这个框架能够很好的解决调用栈中出现同步异步操作并存的情况，假设所有函数都返回Async.Operation，框架的使用者可以使用一种统一的模式来编写代码，处理函数返回，而无需关心这个函数实际上是同步返回了还是异步返回了。

对于串行调用多个异步函数的情况，我们现在可以用嵌套addCallback的方式来书写，但随着嵌套层数的增多，代码会变得越来越不美观：

firstAsyncOperation().addCallback(function() {
  secondAsyncOperation().addCallback(function() {
    thirdAsyncOperation().addCallback(function() {
      finalSyncOperation();
    });
  });
});

我们能否把嵌套形式改为jQuery风格的链式写法呢？这是我们接下来要思考的问题，如果你不希望错过相关讨论的话，欢迎订阅我的博客：

Cat in Chinese (feed)
Cat in dotNET (feed)

写个 JavaScript 异步调用框架 (Part 2 - 用例设计)

2009-05-07T01:03:00.002+08:00

在上一篇文章里说到，我们要设计一个异步调用框架，最好能够统一同步异步调用的接口，同时具体调用顺序与实现方式无关。那么我们现在就来设计这样一个框架的用例。

传递回调

我们首先要考虑的一个问题是，如何传递回调入口。在最传统的XHR调用当中，回调函数会被作为最后一个参数传递给异步函数：

function asyncOperation(argument, callback)

在参数相当多的时候，我们可以把参数放到一个JSON里面，这样参数就如同具名参数一样，可以通过参数名选择性的传递参数，不传递的参数相当于使用默认值。这是从Prototype开始就流行起来的做法：

function asyncOperation(argument, options)

然而这两种做法都有一个坏处，就是把同步函数改为异步函数（或同步异步混合函数）时，必须显式地修改函数签名，在最后增加一个（或多个）参数。

由于在调用栈的底层引入异步函数对我们来说太常见了，为此可能要更改一大堆上层调用函数签名的成本实在是太高了，所以我们还是想一个不用修改函数签名的做法吧。

在这里我参考了.NET Framework的IAsyncResult设计，把异步操作有关的一切信息集中到一个对象上来，从而避免了对函数签名的修改。在此，我们假设一个异步函数的调用原型是这样子的：

function asyncOperation(argument) {
  operation = new Async.Operation();
  setTimeout(function() { operation.yield("hello world"); }, 1000);
  return operation;
}

在这段代码里，我们返回了一个Operation对象，用于将来传递回调函数。同时，我们通过setTimeout模拟了异步返回结果，而具体的返回方式就是yield方法。

接着，我们还要设计传递回调函数的方法。由于我们不能好像C#那样重载+=运算符，所以只能用函数传递回调函数：

var operation = asyncOperation(argument);
operation.addCallback(function(result) { alert(result); });

在C#里面做这样的设计是不安全的，因为在异步操作可能在添加回调之前就完成了。但在JavaScript里面这样写是安全的，因为JavaScript是单线程的，紧接着asyncOperation的同步addCallback必然先执行，asyncOperation中的异步yield必然后执行。

调用顺序

可能有人要问，如果用户使用同步的方式来调用yield，这时候执行顺序不一样依赖于yield的实现吗？没错，不过yeild是在框架中一次性实现的，我们只要把它做成异步的就可以了，这样即使对它进行同步调用，也不影响执行顺序：

function psudoAsyncOperation(argument) {
  operation = new Async.Operation();
  operation.yield("hello world");
  return operation;
}
var operation = asyncOperation(argument);
operation.addCallback(function(result) { alert(result); });

就算把代码写成这个样子，我们也能确保addCallback先于yield的实际逻辑执行。

事后回调

有时候，框架的使用者可能真的写出了先yield后addCallback的代码。这时候，我认为必须保证addCallback中添加的回调函数会被立即触发。因为用户添加这个回调函数，意味着他期望当异步操作有结果时通知这个回调函数，而这与添加回调函数时异步操作是否完成无关。为此，我们再添加一个用例：

function psudoAsyncOperation(argument) {
  operation = new Async.Operation();
  operation.yield("hello world");
  return operation;
}
var operation = asyncOperation(argument);
setTimeout(function() {
  operation.addCallback(function(result) { alert(result); });
}, 1000);

小结

到这里，我们就设计好了一个名为Async.Operation的异步操作对象，具体如何实现关键的yield方法和addCallback方法将在下一篇文章讲述如果。你不希望错过的话，欢迎订阅我的博客：

Cat in Chinese (feed)
Cat in dotNET (feed)

写个 JavaScript 异步调用框架 (Part 1 - 问题 & 场景)

2009-05-06T00:11:00.001+08:00

问题

在Ajax应用中，调用XMLHttpRequest是很常见的情况。特别是以客户端为中心的Ajax应用，各种需要从服务器端获取数据的操作都通过XHR异步调用完成。然而在单线程的JavaScript编程中，XHR异步调用的代码风格实在是与一般的JavaScript代码格格不入。

额外参数

考虑一个除法函数，如果它是纯客户端的同步函数，那么签名会是这样的：

function divide(operand1, operand2)

然而假设我们对客户端除法的精度不满意，于是把除法转移到服务器端来执行，那么它是个需要调用XHR的异步函数，签名也就可能会是以下几种之一：

function divide(operand1, operand2, callback)
function divide(operand1, operand2, successCallback, failureCallback)
function divide(operand1, operand2, options)

我们必须在签名中引入新的参数来传递回调函数，不能选择让函数变成阻塞式的同步调用。

可传递性

不仅仅直接操作XHR的函数需要引入新的参数，这种复杂性还会顺着调用栈向外传递。例如说，我们对加减乘除四则运算作了封装，只向外暴露一个运算接口：

function calculate(operand1, operand2, operator)

这个calculate函数根据operator参数来调用内部的plus, subtract, multiply, divide函数。然而，因为divide函数变成了异步函数，所以整个calculate函数不得不也转变为异步函数：

function calculate(operand1, operand2, operator, callback)

同时，在调用栈之上凡是需要调用到calculate的函数，都必须变成异步的，除非它并不需要向上一级调用函数返回结果。

同步并存

尽管calculate函数变成了一个异步函数，它所调用的plus, subtract, multiply函数还是同步函数，只有调用divide时是异步的，这时候calculate就是一个异步同步并存函数。

这会带来什么问题？calculate的调用者看到函数签名自然会认为calculate是个异步函数，因为它需要传递回调函数，然而calculate的执行方式却是不确定的。考虑如下调用：

calculate(operand1, operand2, operator, callback);
next();

这里涉及到callback和next两个函数，它们哪个先执行哪个后执行是不确定的，或者说是依赖于calculate具体实现的。

如果calculate的实现是，当不需要进行异步操作时，直接调用callback。那么，在执行加减乘法时callback会在next之前被调用；在执行除法时next会在callback之前调用。

如果我们不喜欢这种不确定性，我们可以改变一下calculate的实现，把同步调用也都改为setTimeout形式的，这样在任何情况下next都一定会在callback之前被调用。

然而后面一种做法依赖于成本较高的实现方式，开发者一个不小心（或者摆明偷懒）就会漏掉setTimeout，导致函数调用顺序变得不确定，所以我们会希望这是框架帮助实现的功能，在使用框架时无法把这绕过。

场景

在这里，我举一个关于上述问题的具体应用场景。（为简化问题，描述已略作修改，与实际应用并不一致。）

在百度Hi网页版里面，我们会在客户端保存一个用户对象列表，在打开和这个用户的聊天窗口时，我们需要从中读取这个用户的信息。这个操作就涉及很多可能同步又可能异步的分支：

用户对象未缓存
- 异步读取用户信息
用户对象已缓存
- 用户是好友（信息更新会由服务器端推送）
  - 同步读取用户信息
- 用户不是好友（信息更新需要由客户端拉取）
  - 可以接受缓存信息
    - 同步读取用户信息
  - 必须获取最新信息
    - 异步读取用户信息

可以看到，分支的结果最终既有同步的，也有异步的。并且这些分支还不是在一个函数里完成，而是在几个函数里实现。也就是说，按照传统的模式，这些函数一部分是同步的，一部分是异步的，由于异步的传递性，最终调用栈顶层的函数都是异步的。

为了解决这个问题，我们需要写一个异步调用框架，用一种统一的方式来进行调用，把同步和异步调用都合并为一种返回方式。

具体的解决方案会在下一篇文章中给出，如果你不希望错过的话，欢迎订阅我的博客：

Cat in Chinese (feed)
Cat in dotNET (feed)

豆瓣的『请勿联系我们』页面

2009-04-12T14:13:00.001+08:00

如果说Don't Make Me Think的基本思想是让用户凭直觉都能找到他们需要的东西，那么豆瓣的联系我们页面就做了一个绝佳的例子，或者说是绝佳的反例，这视乎你怎么看这个问题。

联系我们

还是用Don't Make Me Think里面的比喻，在网站上寻找内容就如同在商店里寻找商品，最理想的情况自然是一抬头就看到导向牌说你想要的商品在哪一行的哪一个货架上。在这方面，豆瓣的联系我们页面是做得非常好的，通过清晰的分类说明了不同情况应该联系不同的邮件地址。就如同清晰的导向牌一样，你能够径直走到摆满你想要的商品的货架前。

接着搞笑的事情发生了，你发现这个货架其实是个锁上了的玻璃橱窗，上面有一个牌子写着『如需取商品，请找售货员』。这时候你会想，这不是一家便利店吗？还是有什么我理解错了？这就是豆瓣的联系我们页面给我的感觉，因为那些邮件地址不仅仅不可以点击，还刻意设计为图片使得不能够复制。

如果你跟我一样，习惯有什么想法直接点击网站的联系我们链接，你应该明白常见的联系我们页面是怎样的。网站往往为了保护邮件地址免受垃圾邮件骚扰而不会直接公开邮件地址，为此他们会设计一个专门的表单让你提交反馈信息并留下你的联系方式。随后如果你提交的信息确实有价值，网站会主动联系你，之后的通信就都可以在邮件里进行了。

这是用户对联系我们页面的印象，就如同对便利店的印象一样——自由地在货架前选取商品然后再去埋单。然而豆瓣选择了在便利店里放置锁上了的玻璃橱窗，这就会导致用户迷失方向，他们会想『这是一家便利店吗？还是说我走进了一家「珠宝便利店」？那算了，我就不买了，或者到附近的便利店买吧。』

帮助中心

这个联系我们页面上面，只有一个链接可点击（除去全局链接外），那就是帮助中心链接了。用户找不到熟悉的反馈表单，自然会凭直觉沿着链接点击下去，而这个链接是唯一的选择。进去之后仍然是一个清晰分类的页面，不过就是没有用户需要的反馈表单。或许用户会浏览一下分类列表，然后发现他要反馈的问题不能算是严格属于某个特定分类。这时候就如同顾客根据导向牌走进了唯一一行他认为正确的货架，但是货架上的分类标识他想要的东西不属于这里的任何一个货架。

这又是一个让用户感受挫折的地方，然而这还不是最后一个。如果用户坚信反馈表单存在，就如同顾客坚信这是每一家便利店都卖的东西一样，那么他们自然会继续找下去。在点击进入任何一个分类链接后，用户会看到又一个清晰的Q&A列表，然后他必须再一次经历同样的挫折，最后才在一个不显眼的地方找到他想要的东西，一个写着『没搞定？给管理员捎个话』的链接。

为什么说这个链接不显眼？因为特殊链接往往会放在页头、页脚或侧栏这类视觉上与内容分离开来的区域，而这个链接放在问题列表和解答列表之间的狭缝。这处的留白本应只用于表示两个列表互相对立的关系，在两个块区元素之间插入一个行内元素只会让人以为那也是分隔符的一部分而已。

小结

这就是为什么我说豆瓣的『联系我们』页面应该叫做『请勿联系我们』页面。它在向用户传达一种意思，那就是『我们豆瓣是刻意增加你联系我们的成本的，因为我们就是不欢迎你联系我们。』这就好比说，我们都知道每一家7-11都会在cashier前有一个放满了condom的架子，而豆瓣是一家和特别的7-11，它在那里放了一个牌子然后写上『我们就是不卖condom，你就不要找了，也不要问我们的售货员』。

Microsoft MVP Global Summit 2009 （Part 2 - Sessions)

2009-03-29T23:13:00.001+08:00

这次去参加MVP Summit，我计划主要是听ASP.NET 4.0及Silverlight 3有关的session，结果在Microsoft Campus的两天也就泡在MSCC，也就是往返于Hood和Rainier这两个room。这些内容之前一直都不能说，现在MIX09开完之后，大部分的内容我们都可以自由讨论了。

ASP.NET 4.0

ASP.NET 4.0方面，我最关注的是ASP.NET AJAX 4.0，不过Preview 4和Preview 3比起来没多少新增功能，我只能希望在Preview 3中存在的bug在Preview 4都修复了。在demo方面，DataView控件加上Live Binding确实非常cool，可以一个DataView做master另一个做details，在其中任何一处作出的修改立即同步到所有地方，包括对ADO.NET Data Service作出更新请求。不过demo始终就只是demo，现实中的场景总有一些更复杂更需要创意的地方。

此外，ASP.NET 4.0还包括ASP.NET MVC和Dynamic Data，前者终于发布了1.0，后者比最初我看到的第一个Preview已经要强大很多了，当然也换上了Entity Model这样的数据访问层组件。

Silverlight 3

我对Silverlight 3的关注原本只是很表面的，但却发现Silverlight 3的新增功能比ASP.NET 4.0要多得多，这意味着Microsoft对Silverlight的投入巨大吧，因此我也觉得有必要去好好研究Silverlight 3了。

Silverlight 3的突破是巨大的，假如我们都承认原来的Silverlight 2其实很弱的话。在工具方面，现在终于可以在Visual Studio 2010里面拖放编辑XAML了，而Expression Blend也支持C#编辑了，不再像过去的版本那样，Visual Studio和Blend各自只能完成一半的工作，必须在两个工具之间切换来切换去。

视频播放一直都是Silverlight非常重视的功能之一，Silverlight 3将会支持H.264，并把H.264/AAC/MP4作为标准的视频封装格式。如今有越来越多的设备支持H.264的硬件解码，而且Adobe与Apple的软件也广泛采用H.264作为高清视频的编码格式，所以将来我们无需再为编码格式的区别而烦恼了。

另外，Silverlight 3还引入了GPU硬件加速的支持，用于UIElement的合成与拉伸，同时支持浏览器内嵌模式与全屏模式。不过，如果你要让你的Silverlight 3应用支持GPU加速，还必须在浏览器插件及UIElement两个层面声明启用GPU加速，以保证其他内容不受此新功能引入的影响。

GPU硬件加速带来的是什么？当然是视觉上的新功能啦。过去Silverlight 2无法做梯形变换，所以也就做不了真正的Coverflow。现在Silverlight 3可以做Perspective 3D了，Coverflow也就能实现了。另外WPF拥有的Effects在Silverlight 3中也能用了，虽然Silverlight 3现在的Preview仅仅自带了两个Effects，但WPF自带的Effects甚至是第三方的Effects都可以导入到Silverlight 3中使用，因为它们都是用HLSL写的Pixel Shaders。

如果你对这些新功能感兴趣，我建议你去看看MIX 09的视频，里面涵盖了我所说到的所有内容。我准备接下来用Silverlight 3做一个Coverflow，如果你有兴趣了解这是怎么做的，欢迎订阅Cat in Chinese。

Microsoft MVP Global Summit 2009 （Part 1 - Trip & Food)

2009-03-23T00:38:00.001+08:00

虽然MVP Summit发生在3月初，但由于我一直都很懒，所以现在才来写写文章。而且，很多MVP Summit上讨论的受NDA保护的内容，过了MIX09也就成为公开内容了，我也就可以在这里说说了。

今年买票的时候，竟然找不到第二个人跟我同行。上海的一群MVP，都为了省钱买了海航的机票，从上海飞到北京再直飞西雅图。我还是更愿意飞NWA，因为里程可以积累到我的南航帐号上，所以虽然票价贵一些，我还是选择了一个人飞NWA。直到起飞前两天，才确定上海的包包跑来北京了，因为面签时被check了拖到最后一刻才买票，结果就和我同机了。

飞到东京之后，有趣的事情发生了，我们见到了一群穿着校服的日本女生走进来候机室，登机之后其中一位就坐在我旁边。我在吃完机上第一餐之后，无所事事就开始找她聊天，问问她有没有用过Baidu.jp，然后说说去美国做什么，她说她其实是去Vancouver参加交流活动。因为飞机引擎噪声很大，我们又都不太懂对方的口音，所以我拿了一个小本子出来把英语写下来让她看。在她有不懂表达的意思时，她拿了一个电子词典出来用日文查对应的英文，不过有时候我看看其中的日文解释，上面的汉字也足够我理解了。这样的沟通挺有趣的。

到了Seattle之后，打车去Sheraton Seattle Hotel，然后还是和去年一样带着今年第一次来的MVP去海边走走，去Crab Pot吃蟹。我们要了便宜的snow crab和dungeon crab，没有选最贵的king crab，吃起来感觉还不错，不过snow crab实在是太小了。最后一天晚上也是在Crab Pot吃，就是吃king crab，但这其实不是我们吃过最好的king crab。

说到这里，就不得不重点推荐一下我们在Oceanaire Seafood Room吃的那一餐Alaska red king crab了。虽然这里的king crab要$45/pound，而Crab Pot的只要$22/pound，但是这里的king crab确实比较大，而且非常甜！如果你想要尝一尝king crab是有多么的好吃，那就一定要去Oceanaire Seafood Room点Alaska red king crab。一般来说，一个人吃1~2 pounds是没问题的，如果你不再点其他东西的话。面包是送的，但既然是专门来吃king crab的，当然就不再点其他东西了，甚至连面包都不吃。

美国人吃法比较奇怪的地方在于，他们用石头那么硬的面包来搭配甜美的king crab。不仅仅这样，他们还会上热好了的黄油，让你点king crab来吃。我试了一下，发现这一点都不好吃，原本爽口的蟹肉变得油油的，感觉很奇怪。

今年MVP Summit的开场中说到去年MVP Summit抱怨最厉害的事情，那就是salmon吃得太多了，每餐都有salmon，所以今年的口号是No Salmon。我自然很失望啦，Seattle作为一个salmon产量如此多的地方，我过来自然要吃salmon啊，怎么可以没salmon呢？结果后来几天真的很多人在Twitter上抱怨No Salmon，于是乎今年最大的抱怨也就正好与去年相反了。看来做如此大的一场活动，关于吃什么的问题真是众口难调哦。

有关MVP Summit旅行与饮食的话题就说到这里吧，如果你有兴趣了解我接下来要说的技术内容，欢迎订阅Cat in Chinese。

ASP.NET AJAX 4.0 Preview 3 (Part 2 - ASP.NET AJAX Template)

2009-03-14T11:37:00.004+08:00

在上一篇文章里，我们说到了如何使用ADO.NET Data Service Client Library能够轻松访问到存在服务器端的数据，然而将数据展现出来仍需要人手拼接HTML这点就实在是让人难以接受，所以我们现在就来看看如何利用 ASP.NET AJAX Template解决这个问题。文章中所用到的示例代码，可以在这里下载：ASP.NET AJAX 4.0 Preview 3 Demo，然后参考里面的AspNetAjaxTemplateDemo.aspx。

Sys.UI.DataView

为了解决展示数据的问题，我们需要用到一个全新的客户端控件，那就是Sys.UI.DataView 了，简称DataView。我们会用DataView替换掉上一篇文章中所说到的人手拼接HTML的部分，用于迭代生成一个ul中的li元素，因此看起来是把DataView当作Repeater来用。实际上，DataView的功能类似于ListView加上DetailsView。

如果你把一个Array绑定到DataView上，它会显示为一个ListView。与ListView 的LayoutTemplate相类似的是，它也能够定义控件展示的整体布局，并且仅仅是迭代输出其中的一小部分。例如说，编写一个有thead的table，并且仅仅是迭代输出thead之后的tr。在这方面，是DataView和ListView完全一致的。唯一不同的是，客户端暂时还没有DataPager这样的控件，所以DataView必须一次性的完整显示整个Array的数据。

如果你把单个Object绑定到DataView上，它就会显示为一个DetailsView。这使得你可以使用两个DetailsView就做出经典的Master-Details展示模式，和在服务器端分别用ListView和DetailsView做出来的一样。当然，你不能指望DataView能够好像DetailsView那样，自动帮你分析每一个数据项并映射出对应的HTML模板，因此HTML 模板还是要你自己手写的，但至少那是在HTML中编写模板，编写时能够享受IDE带来的各种好处，维护时也更容易看懂自己（或别人）原来写下的 HTML。

JavaScript语法

接下来，我们就要把DataView投入到实际应用中去了。首先，我们说一下如何用JavaScript来实例化一个DataView。有编写ASP.NET AJAX客户端代码经验的人对$create应该不会觉得陌生，因为DataView继承自Sys.UI.Control，我们仍然可以用$create来实例化它。不过，在此之前，我们先要把对应的 HTML编写好：

<ul id="itemTemplate" class="sysTemplate">
  <li>
    <span class="award">{{ Award }}</span>
    <span class="winner">{{ Winner }}</span>
    <span class="film">{{ Film }}</span>
  </li>
</ul>

然后我们就可以基于itemTemplate这个HTML元素创建控件了：

$create(Sys.UI.DataView, {
    dataSource: new Sys.Data.AdoDataSource(),
    serviceUri: "WebDataService.svc",
    query: "OscarWinners"
  }, {}, {}, $get("itemTemplate"));

现在，页面显示出来的结果和之前我们人手拼接HTML的版本完全一致，不过我们已经不在需要维护嵌入在JavaScript中的HTML代码了。

声明性语法

如果你觉得上面的做法还不够好，要在pageLoad()里面写一个$create，那么声明性语法可能正是你需要的。大家应该记得很久很久之前，在ASP.NET AJAX还叫做Atlas的时候，就已经有过声明性语法的设计，那就是xml-script。不知为何，后来Microsoft放弃了这一设计，现在声明性语法又回来了，而且设计得比以前的xml-script还要更好。假如不用$create的话，通过声明性语法实例化一个DataView仅需要这样做：

<body
  xmlns:sys="javascript:Sys"
  xmlns:dataView="javascript:Sys.UI.DataView"
  sys:activate="*">
  <ul id="itemTemplate" class="sysTemplate"
    sys:attach="dataView"
    dataView:datasource="{{ new Sys.Data.AdoNetDataSource() }}"
    dataView:serviceuri="WebDataService.svc"
    dataView:query="OscarWinners">
    <li>
      <span class="award">{{ Award }}</span>
      <span class="winner">{{ Winner }}</span>
      <span class="film">{{ Film }}</span>
    </li>
  </ul>
</body>

我们所需要更改的代码包括：

在body元素上声明有关的xmlns，将JavaScript中的名字空间映射到HTML上，或者你可以理解为映射到XML/XHTML上。
通过sys:activate="*"这个声明，让ASP.NET AJAX知道它需要去解释页面上所有的声明性语法，并激活对应的组件。
将原本使用$create初始化时传递给实例的属性、事件、引用改为用声明性语法，直接写在HTML元素的定义上。

经过这三步，我们就可以将原来使用$create创建的组件改为使用声明性语法创建了。

小结

DataView 使得我们能够使用HTML模板，来避免手工拼接HTML带来的种种问题，同时声明性语法让我们能够如同声明服务器端控件一样声明客户端组件。虽然在 ASP.NET AJAX 4.0 Preview 3中这些功能仍有小bug，例如我想用声明性语法创建我自己编写的InPlaceEditoBehavior，这在初始化阶段毫无问题，但却会在页面卸载销毁对象之时抛出脚本错误。

由于我觉得ASP.NET AJAX 4.0 Preview 4很快就要出来了，所以我也就不准备去深入研究Preview 3了，等Preview 4出来了再去好好看看源代码。如果你有兴趣关注这方面的技术文章，欢迎订阅我的博客，点击侧栏上的订阅链接就可以了。

ASP.NET AJAX 4.0 Preview 3 (Part 1 - ADO.NET Data Service Client Library)

2009-03-13T16:22:00.002+08:00

自从Microsoft与jQuery合作以来，ASP.NET AJAX与jQuery就被定位为两个互补的AJAX库。既然jQuery已经实现了如此多轻量级的AJAX特性，自然ASP.NET AJAX会继续专注于富客户端所需的一些重量级特性。

在ASP.NET AJAX 4.0 Preview 3里面，开发人员能够接触到的两个重要的新特性就是ADO.NET Data Service Client Library以及ASP.NET AJAX Template。对于熟悉ASP.NET服务器端开发但不熟悉客户端开发的人来说，你可以简单地把这两个特性理解为存在于客户端的DataSource 以及ListView，只要把数据通过ADO.NET Data Service输出到前端，你就可以如同使用DataSource和ListView的组合一样在客户端开发数据驱动的应用程序了。

在这篇文章里，我们将来看看如何使用ADO.NET Data Service Client Library，将ADO.NET Data Service暴露的REST数据接口直接拿到客户端JavaScript代码中去调用。文章中所用到的示例代码，可以在这里下载：ASP.NET AJAX 4.0 Preview 3 Demo，然后参考里面的AdoNetDataServiceDemo.aspx。

服务器端准备工作

在我们接下来要讲到的示例当中，我们会用到一个SQL Server 2005 Express Edition的数据库，里面有一张名为OscarWinners的表，记录的是本年度奥斯卡获奖名单，字段包括AwardID、Award、 Winner、Film。然后我们为这张表创建ADO.NET Entity Model，接着再为它生成的实体类创建ADO.NET Data Service。这些都是在Visual Studio 2008中点几下鼠标就能完成的操作，就不再详细解释了。在ADO.NET Data Service的InitializeService()方法内，我们仅仅给它提供一个最宽松的规则：

config.SetEntitySetAccessRule("*", EntitySetRights.All);

到这里，我们就把服务器端的要做的工作都准备好了。打开你创建的ADO.NET Data Service地址，看看是否输出了正确的Atom格式数据。如果没有，请检查一下你机器上的WCF是否已经正确安装和配置好了。确保服务器端的准备工作都做好了，然后再进入客户端的开发工作。

连接Data Service

在客户端使用ADO.NET Data Service，我们需要接触到的类只有一个，那就是Sys.Data.AdoNetServiceProxy。首先，我们要连接到ADO.NET Data Service，也就是使用ADO.NET Data Service的URL来实例化此类：

var dataService = new Sys.Data.AdoNetServiceProxy("WebDataService.svc");

然后，我们就可以利用dataService来调用ADO.NET Data Service进行CRUD操作了。

CRUD操作

所有的CRUD操作都在Sys.Data.AdoNetServiceProxy对象上执行，方法分别名为query()、insert()、update()、remove()。在我们的示例当中，会用到query() 和update()方法，另外两个方法是用起来和update()很类似，就不再详细说明了。

查询操作

dataService.query("OscarWinners", function(result, context, operation) {
  /* display result */
}, errorHandler);

使用上述语句，我们查询出了OscarWinners表中的所有数据。随后的第一个回调函数会在查询成功时被调用，因此我们可以在其中编写拼接HTML以显示结果的逻辑，具体的代码请参考下载中的AdoNetDataServiceDemo.aspx。第二个回调函数会在查询失败时被调用，我们可以编写一个统一的错误处理函数，名为errorHandler，然后将它传递给此参数。

如果需要传递复杂的查询参数，使用ADO.NET Data Service的格式就可以了，这可以在MSDN上查到。例如说查询Slumdog Millionaire这部电影夺取了多少个奥斯卡奖项，然后把奖项按照名称排序输出，可以这样子写：

dataService.query("OscarWinners?$filter=Film eq 'Slumdog Millionaire'&$orderby=Award", function(result, context, operation) {
  /* display result */
}, errorHandler);

更新操作

dataService.update(item, function(result, context, operation) { }, errorHandler);

尽管将查询结果保存下来成为items集合，并且根据用户在界面上执行的操作修改item上的属性，这些逻辑都需要我们手动维护，然而最后将item更新到服务器上则只需要如此简单的一句调用。

在我给出的示例代码中，我自己写了一个InPlaceEditBehavior，也就是所谓的“就地编辑器”，能够让用户点击显示文本后把显示文本变成输入框。然后我把这个InPlaceEditBehavior绑定到每一条记录显示的Winner字段和Film字段的span上，使得这些span都能接收用户输入。最后，我为InPlaceEditBehavior添加了一个onchanged事件，并在该事件的处理函数中完成更新item以及调用update()的操作。

小结

在这篇文章里，我简单地介绍了ADO.NET Data Service Client Library的易用性，并且通过一个具体的示例说明了如何用它来节省大量的数据交互代码。

如果你曾经写过AJAX-Enabled WCF Service，你应该知道把实体类暴露为WCF Service接口是多么麻烦的事情，就算每个实体类就简单地支持CRUD方法，你也必须手动编写这4个方法。ADO.NET Data Service相当于帮你把这一切都做好了，只要给它实体类和规则，它就帮你生成一个Data Service。另外，通过AJAX-Enabled WCF Service所包括的数据接口，会自动生成一大堆客户端代理类，而ADO.NET Data Service Client Library则只有一个固定的代理类，客户端代码体积不会随着接口复杂度的增加而增加。

说了 ADO.NET Data Service Client Library的那么多好处，那么这个示例中又有什么做得不够好的地方呢？我觉得最难维护的地方就是获取到数据后拼接HTML的代码了，人手写的HTML 拼接代码难免容易出错，而且日后更新起来也很麻烦，出错了调试时也不容易定位问题。ASP.NET AJAX Template能够帮助我们解决这个问题，这就是下一篇文章中将会讲到的内容。

如果你不想错过接下来的文章，欢迎订阅我的博客，点击侧栏上的订阅链接就可以了。

如何购买 Amazon Kindle 书籍

2009-03-13T15:53:00.001+08:00

在美国旅行时，无聊地在iPhone上装了Kindle for iPhone，然后挑了几本技术书的sample来看看，发现在iPhone上这样看电子书还是挺方便的，就是有些代码块不能自动放大到正常显示字体看起来有点辛苦。我觉得Amazon的sample还是做得挺大方的，每本书都开放了整个chapter 1，技术书的话基本上看chapter 1就能看出作者讨论问题的深度。

我利用旅行的时间，看完了LINQ Unleashed和Pro LINQ的sample，然后决定买一本来学习一下LINQ。我个人更倾向于买Pro LINQ，因为它在chapter 1就提到了deferred query这样的概念，应该是一个本深入讨论LINQ内部技术的书籍。不过我还是看了一下Amazon上的评分，发现两本都是5星的，但Pro LINQ有32个review，而Linq Unleashed只有4个，于是决定就买Pro LINQ。

开头以为买本Kindle书就是直接刷卡那么简单的事情，结果发现Kindle书是有区域限制的，只能发送到美国。但是我上次买LEGO Mindstorm NXT也是这样买啊，中国的信用卡加美国的送货地址就可以了，不允许送到美国之外的东西就让别人在美国待我签收。神奇的是，Kindle书是只能1-Click购买的，不能在购买时填写送货地址，那Amazon凭什么说我就是在美国之外呢？虽然我禁用了1-Click购买，但保留在1-Click购买的默认地址是美国地址，真是想不明白。

在网上看了很多资料，别人都是可以在美国境外购买Kindle书的，我想来想去也不明白Amazon凭什么判定不能把Kindle书卖给我。本来我不想把帐号上记录了的信用卡信息和地址信息删除的，这样将来要用时又要重新输入，最后实在想不到办法了，决定把这些信息都删掉！接着点1-Click购买，Amazon重新问我要了一个地址，我填了一个美国地址，就购买成功了。

另外，大家都说只能用中国的信用卡购买Amazon Gift Card，再用Gift Card买Kindle书，我也不知道是不是这样，反正我是这样买的。一开始Amazon提示区域限制时，我就怀疑是信用卡的区域问题，所以就去买了Gift Card。能否不用Gift Card直接购买我还不知道，下次可以这样试试。

最后，Amazon是有iPhone版页面的，但它默认打开的购买Kindle书页面缺不是iPhone版的。如果在iPhone版页面上搜索Kindle书，结果能显示出来，然而旁边会写着『This item is currently unavailable』，并且点击进去就会说找不到。只能说，Kindle for iPhone确实还没完全准备好，配套的购买功能都还做好针对iPhone的优化。

Beijing Open Party

2009-02-22T20:46:00.001+08:00

这是我第一次参加Beijing Open Party，主要是为了了解unconference的具体组织形式，其次是想谈谈GMP Party与Beijing Open Party合作的事情。

下午1:00，我们到达了东直门的ThoughtWorks办公室，门口的签到挺方便的——假如曾经在网上报名或者参与过过往活动，输入名字后其他信息就会自动显示出来。然后进入了ThoughtWorks的办公区域——一个无阻隔的大hall，四周除了窗户就是涂鸦墙，水房仅仅用吧台分隔开来，只有娱乐室是用墙壁分隔的。这样的办公区域感觉挺好的，特别是用来做各种创意活动的话，但是如果想要专心coding，不知道会不会很容易受周围讨论的影响。无论如何，这样的地方用来举办Open Party倒是不错的。

1:30开场之后，先有30分钟的『调侃5分钟』活动，任何人都能够上去做个简单的分享或者广告，每个人的时间限制在5分钟之内。有些人上去介绍了一下自己的网站或者开源项目，也有些人上去分享了一些想法和工作成果。这种形式的分享在同一专业人群内总是很有效率的，不需要演讲者有非常优秀的演讲技能把专业内容转化为适合大众口味的内容或调动听众情绪，只要能把专业内容正确表达出来，听众们一定能听懂，并且也知道哪些内容是更能体现演讲者的技术深度。

在『调侃5分钟』结束后，正式开始对话题的投票，虽然不限制每个人的投票次数，不过还是鼓励大家只投真正想听的话题，以便把话题分散开来，人人都能听到自己想听的，而对能拿到奖品的top 3话题评价也更准确一些。投票完毕，根据4 tracks * 3 periods选出了12个话题，然后就正式进入话题演讲阶段了，其中每个period为一个小时。

我一直留在大厅听较为大众化的话题，偶尔去各个会议室看看其他小众话题是如何进行的。由于这次是Mozilla赞助的活动，所以有3个Mozilla相关的话题，其中第一个是在大厅的Seth演讲，讲的是Mozilla Community Localization。

随后还有图灵的书友会以及CC商业模式介绍的话题，讲得都不错。比较可惜的是，到后期饮料都被拿光了，剩下很多曲奇却没有人吃。

总的来说，Beijing Open Party确实挺geeky的，不过放在大厅的话题还算是大众化，而且演讲的质量也挺高的，所以即使没有哪个小众话题吸引你，也可以在大厅听听，或者走到旁边跟其他人聊聊天。

Facebook News Feed 上的内容强调与弱化

2009-02-14T16:24:00.001+08:00

我之前曾经思考过Facebook News Feed的价值，觉得News Feed中良好的信息筛选与排序算法是我喜欢使用Facebook的原因之一。当时我只想到了News Feed显示的是一种trend，以及这种trend能够带来的经济利益，不过貌似至今Facebook也没有开发这方面潜在赢利点的倾向。

最近我又对比了一下Facebook和众多国内SNS网站的首页输出，发现Facebook的News Feed其实很侧重于用户交互，并且这个侧重点不仅仅与信息输出的条数有关，还与版面设计有关。

如果你把Facebook的News Feed当作报纸来看，那么哪些是能够第一时间成功吸引你注意力的“头条”？我想应该是用户上传或分享的视频、图片，以及有评论的信息。首先，这些信息占的版面大；其次，视频与图片的丰富色彩及评论区域的背景颜色明显地和颜色单调的描述性文字区分开来。我们来看一个具体的例子：

我想你肯定能够轻易地看得出中间照片集一段的强调作用——占用空间更大、粗体的标题、字号更大的评论链接。这说明了，Facebook是刻意设计为强调这一条信息的，而非仅仅因为照片占用更多空间而“意外”造成的效果。

那么有评论的信息呢？评论区域淡淡的背景色，也成功地将它从其他同等级别的信息中凸显出来：

大量弱化的信息，往往会被淹没在News Feed中，然而只要有评论，你就一定不会错过。评论区域的背景色一定会捕捉到你的注意力，甚至你会因为评论数量之多，而好奇到底是什么事情吸引了那么多人的注意力。

校内在一定程度上抄袭了Facebook的这些设计，所以首页看起来还是挺顺眼的，虽然我实在搞不懂校内是如何选择强调哪些信息的，而且在中文字体上用粗体能得到的强调效果我觉得并不明显，此外弱化信息的弱化做得也不够明显。

海内在这方面显得有点点“自作聪明”了，结果得到的效果更糟糕。例如用户改变状态（或曰“签名”、“迷你博客”……），这类信息数量之大，显然应该弱化之，最多仅仅强调有评论的几条。海内则是反过来做：

这种对好友意义不大的信息（相对发照片或写博客来说），竟然要暂用三行的空间。而且，海内还默认把评论隐藏起来了，在一堆同类信息当中，你实在看不出哪一条是因为能够得到别人注意而拥有评论的，于是扫一眼就全部跳过去了。此外，海内的评论（或曰“回复”）也不突出，即使默认展开了强调效果也不明显。

最后总结一下，SNS的首页信息必须做到两点

能够有所侧重地选择推送给用户的内容
在版面设计上把重点强调出来

至于哪些是应该重点推送的信息，我想除了可以通过复杂的算法计算之外，有些简单的规则是普遍适用的。例如说评论，能够引起部分人注意的信息，至少比没人会留意到的信息更值得我关注。又例如说照片，别人原意花时间上传的照片，至少比无意修改的状态更值得我关注。

GMP Party EP2

2008-12-30T01:02:00.003+08:00

Geeky meets Pretty的第2场大party终于来了（平时的小聚会不计算场次）。自从我在网志年会上见识到了Punch Party后，我就一直想在GMP内搞这样一个活动，在小组内进行过若干讨论后我们最终决定要搞一个2008年年度“大”party，形式当然就是Punch Party了。

这次party，要感谢Chloe和Piggest帮忙组织，是她们帮忙确定了整个活动的rundown和预订到了场地（奇遇花园）。然后要感谢所有的speakers，是他们带来了如此丰富的speech：

Jinghua和Chloe的session做成了series，让大家非常期待下一个episode。其中Jinghua说到清华校园不适合搭讪美女时，方军立即表示反对并解释了清华哪里适合寻找美女。Leo因为是在看过广州Punch Party的视频后做的准备，所以他的session风格也更接近之前广州Punch Party的，据说他之前按照7分钟的时间安排排练了好几次哦。龚纹的星座解释好复杂哦，听着听着就让我感觉在上高中的政治课，可惜现场没有人主动出来让龚纹做一下分析，否则会好玩很多。

作为一个party，少不了的当然是回答问题抢奖品的环节，我的geeky问题加上Chloe的fashion问题还有龚纹的星座问题，确保了大家不仅仅要有实力还要有运气才能拿到奖品。对我来说，最好玩的就是问Office 2007下一版本号的问题了，竟然那么多人不知道Office 13这个版本号被跳过了。

这次的party虽然并没有Carol组织的Punch Party那么紧凑和快节奏，不过我觉得作为第一次已经做得不错了，相对来说不够2.0（主要是单向交流，听众互动少），而且也没有sponsor。方军建议我们可以和Beijing Open Party合作，做成他们的一个track，因为我们在某些方面正好和他们互补哦——他们缺少美女，而我们性别比例极力保持在1:1；他们缺乏非技术话题因而显得范围比较窄，而我们追求多样性有各式各样的话题；我们没有sponsor所以要收场地费用，而他们拥有不少的sponsor；我们还没有固定的流程，而他们已经有相当的活动经验。

anyway，接下来我们GMP也要建立一个对外发布信息及接受投票和留言的blog，然后逐步把GMP Party的筹办过程流程化，让GMP Party成为一个相对稳定的活动。

假如你愿意以原版或影印版价格购买翻译书籍的话

2008-12-12T12:00:00.001+08:00

这篇文章是接着Tony Qu的《批“觉得有必要记一下的东西——关于翻译”一文》写的，就讨论一个问题——你原意以原版或影印版的价格购买翻译书籍吗？

为什么问这个问题？这源自Tony Qu批判的原文中的一句话：

很多国内程序员看书就只看英文原版，开发就只用原版VS，就是这个原因。

我承认，在英语能力相当的程序员当中，这句话说的是事实。能够看原版书的尽量看原版书，不仅仅因为看起来舒服，更因为容易在P2P网络上找到OCR后完美排版的PDF（甚至是官方PDF）。但这部分人当中，又有多少是真真正正是去买原版书的（原价格按汇率算），或者至少去买影印版的（价格是翻译版的一倍以上，原版的一半以下）？我想就很少了，我仅仅知道Jeffrey Zhao会从国外买二手原版书。很老实说，假如读者原意为翻译版支付引进版的价格，那么翻译版能够做得比现在的要好得多。但有多少人是连翻译版的价格也不愿意支付的，宁愿上网找极度难看的未OCR扫描版？此时，结论已经很明确，翻译版质量差不完全是出版社或者译者的问题，是经济利益驱使，这有电影工业与唱片工业在大陆的做法为证！

虽然现在DVD的分区对购买者来说已经毫无意义，但当初就把大陆分作一个6区是有理由的。话说刚刚有DVD的时候，大陆的DVD市场跟国际市场同一个运作方法，电影上映后至少3个月才发行DVD，以免影响票房。但DVD就是卖不出去，不仅仅是因为太贵，还因为国内的购买者不愿意等那3个月，当然也不愿意买票进电影院看。他们买什么？买盗版DVD。因为DVD必须有正版片源出来后，才可能有正版片源的盗版DVD，所以3个月未到，所有的盗版都只可能是枪版DVD。然而大陆消费者就是不在乎画质和音质，他们就是想以最低的价格抢先看到电影，看完就算。当这种需求被中国电影工业从业人员知道以后，一种新的商业模式发展出来了，以满足这部分消费者的需求——大陆的引进版DVD的发行和电影的上映几乎同步进行，价格仅仅比盗版略高，并且最重要的是，人为地把画质和音质降低到枪版的水平。就这样，电影工业能够在大陆盗版市场上分到一杯羹，我的意思是他们算是卖官方枪版的了，同时也不影响他们的国际市场价格——即使存在购买渠道，港台消费者也不会接受这样廉价的劣质DVD，仍然会等上映3个月后买原版DVD。

唱片工业做的事情是类似的，大陆所谓的引进版虽然价格更容易被消费者接受，但音质是经过人为降低的。这就是价格歧视，因为大陆消费者只愿意支付一个更低的价格，也只需要购买质量更低的商品，所以供应商就可以把这划分为一个独立的价格歧视区域市场。我不知道图书行业是否存在这样人为控制的“阴谋”，但只要大陆消费者的需求还是这样的“另类”，价格歧视原则就会一直适用，这样的事情就会无意识的继续存在，以远低于影印版价格售卖的翻译版质量就肯定还是那么低。对了，顺带说一句，港台翻译版的价格是和大陆影印版差不多的。

总结一下，我也是译者，翻译工作低廉的价格以及编辑工作的效率低下Tony Qu说过我就不再说了。如果大陆翻译版最终按照港台翻译版的价格去销售也能获得同样的销量的话，我相信译者可能愿意为这份价钱做全职的翻译工作，我相信出版社愿意聘请更多专业编辑并且合理安排他们的工作量。

P.S.如果要认真学习和研究中国的传统语言文化，我个人还是建议去台湾。

SD2C 2008

2008-12-07T00:36:00.004+08:00

这几天参加了SD2C，也就是“软件开发2.0技术大会”。规矩当然是照旧的，social第一，session第二。

Day 1

第一天想着12:00开始签到，于是慢吞吞地准备出发，去到九华山庄已经是11:00。这是我第一次在没有车接送的前提下一个人跑来九华山庄，路上浪费了不少时间。签到后开始乱逛，然后陆续找到了公司不同部门来的同事，发现大家都没吃午餐。虽然我自己从McDonald's带了一个汉堡来，不过还是跟大家一起打车到小汤山街口的镇上吃饭。吃完饭就13:00了，应该开场了，可是打车回九华山庄实在太难，最后无奈打了黑车回去。我个人认为，把开场放在13:00但又不提供午餐是十分不体贴的。在市区的话也就算了，在九华山庄这样一个三流装一流的地方，选择不多又不怎么好吃的自助餐竟然要¥68一位，方便面也要¥20一盒，不提供午餐这样的做法实在是不人道。

下午的议程看起来全是keynote级别，听过后才发现那完全是赞助商专场——逐个赞助商轮流上去宣传自己的技术或者观点，而且还不提供任何课程反馈的机会，它讲得再烂我也不能表达一下我的不满。赞助商专场分为上下两个半场，上半场的人都是来吹水的，就吹嘘自己公司的东西，泛泛而谈，听了也没什么收获；下半场讲的东西稍微实在一些，雷军和戴志康上来讲的话都很真诚，也很有感染力。总之，要是早知道第一天下午是赞助商专场的话，我就去WinHEC玩到15:00再过来好了，然后18:00吃饭，接着参加晚上的活动。这只能怪我参加会议的经验还是太少了，没有把这么明显的安排给看出来。

下午听了那么多个小时，最让我感到震撼观点来自于雷军。他在说他投资的UCWeb时提到了这样一个观点：我们曾经都是互联网用户中的领头羊，有什么新鲜的东西出来我们都先去尝试，然后慢慢普及到大众用户。但在移动互联网就不是这样，移动互联网的主要用户是那些比较少机会通过计算机接入互联网的人，例如学生、民工和军人。也就是说，我们这些每天使用计算机连接着互联网做开发的人，其实是不可能知道移动互联网的真实需求的，我们无法体会使用不到计算机接入互联网会使怎样的。过往我一直认为移动互联网用户就是高端移动用户和高端互联网用户的交集，现在我终于明白到不是这么一回事了。

晚上去各个沙龙看了一下，没有什么印象特别深刻的。只记得在“职业规划与成长论坛”上听到这样一句搞笑的话——“我们的HR自裁了，也就没有HR了”。晚会后有班车把我们送回到地铁站，然后回到家也就是23:00了。

Day 2

第二天早上9:00出发，去到就是11:00了。我觉得把第一个session放在9:00开始是很不合理的，九华山庄这么偏僻的地方外加不包住宿，谁原意那么早起床赶7:00从市区开出的班车啊，结果当然是大家都很晚才到啊。对于speaker来说，如果自己的session被放在早上，可能也会觉得大会不重视他的session，因为早上能赶来参加session的人就是少一些，这个大家都明白的。我去到时已经是11:00，然后去听了一下郭安定的课，中午和郭安定、老孟、莫依等MVP一起吃饭，还是挺好玩的。

从郭安定讲的内容来看，他很注重企业生态圈。也就是说，只要你能够帮助别人解决实际问题，赚钱的机会总是有的，但也没必要自己把什么都做了，也要留机会让别人帮你，赚你的钱。把这个道理传播出去，让更多人赚得到钱，让更多人受惠。这种思想我是十分认同的，如果帮助别人的同时又帮助了你自己，这有什么不好呢？

下午我去听了一下周爱民的JavaScript+Delphi+ErLang，语言层面的东西不用怎么在乎，他也没做很应用性的展示，我觉得最重要的一个思想还是分层——只要实现了分层，层与层之间是针对接口设计的，那么随时换掉一个层都是可以的，只要接口保持不便，什么语言并不重要，不同层的需求不同实现语言自然也可以不同。另外还听了李建忠的.NET设计模式，讲的是一些老生常谈的内容，没什么非常特别的。其实讲什么技术并不重要，最重要是把那种思想说清楚，让听众都能领悟到，那就算是成功了。

晚上是CSDN专家沙龙，本来说是让各位专家说说对CSDN服务的不满与建议的，结果大家的自我介绍都拖得很长，介绍完也就完了，赠送给各位专家一人一本绝影签名的《疯狂的程序员》，然后就赶班车去了。其中最有趣的一幕，就是莫依问老孟说，“是什么让你多年坚持在论坛上帮助别人解答问题”，旁边的郭安定小小声说了两个字，“伟哥”。

Day 3

最后一天，依旧是9:00出发11:00到。原本计划去听听iPhone开发的，发现基础部分都讲完了，开始讲OpenGL的使用，我又完全听不懂，听了三分钟就睡着了。

下午听的是使用YSlow2.0优化网络性能，主要是了解一下YSlow2.0的新特性，也就是如何自己设计符合自身网络特性的网络性能评分规则。接着去听了Amazon运计算服务的架构分析介绍，确实比较介绍性，让你知道就是有那么多的服务在运行着，并且能为企业省钱，就这么简单。最后听的一个session是面向对象的JavaScript，这是作为当今JavaScript开发人员必须知道的基础知识啦，听他说一遍只是为了好玩。

SD2C结束后，马宁准备把我和莫依还是陈敏送到地铁站，最后大发慈悲把我们都送回家了，超级好人，在这里需要感谢一下。建议明年真的不要选择九华山庄这样的地方了，交通实在是不方便。

P.S.发现自己最近参加的会议不少啊，整个blog塞满了关于各个会议的文章，如China MVP Open Day 2008、TechED 2008 China、Chinese Blogger Conference 2008、WinHEC 2008 China。

大陆技术书越来越台湾化了

2008-12-06T22:36:00.001+08:00

这次SD2C我总共搬了4本书回家，2本买的2本送的。我发现现在大陆出版的技术书越来越台湾化了，也就是“更多搞笑，更少大道理”，而这正好符合我近期的读书倾向。

在CSDN专家沙龙上，每位专家都拿到了一本绝影的《疯狂的程序员》，听说是绝影自己经历的写照。虽然我还没仔细看，不过相信这本书会是本十分轻松的小说，这正是我喜欢的。之前看《梦断代码》也是足够轻松的，不过轻松背后也发人深思，让你不得不去思考很多软件工程和组织架构的问题。

在SD2C的签售会上，我还买了一本《悟透JavaScript》。我已经不需要看任何对JavaScript泛泛而谈的书，但我仍然买了这本书，就是想看看其娱乐性的一面，如果确实写得好，包括插图画得好，那也是十分值得我学习得。什么时候我也要在我的blog上加上专业插图，否则就太没有竞争力了。

另外我最近还买了一本《大话设计模式》，同样也是因为它搞笑的一面。虽然读起来会觉得某些剧情比较牵强，但至少这是一种写作风格，可能在大陆还不成熟，不过将来会被越来越多的作者采纳，自然会成熟起来。

总的来说，我现在也看纯技术书看得有点累了，况且很多东西看了不用等于没看，过一段时间还真变成没用的了。轻松娱乐的东西，至少保证了阅读的过程是愉快的，即使将来用不着，用得着也就算是赚了。

WinHEC 2008 China

2008-12-03T20:25:00.001+08:00

今天是WinHEC第一天。WinHEC就是Windows Hardware Engineering Conference，中文名是做Windows硬件工程大会。昨晚紫柔告诉我9:00到场签到就可以了，因为9:30正式开始，但我早上还是忍不住多睡了一会儿，所以10:00才到场。当时还是张亚勤的演讲，我进入主会场后迅速找到剩余的几个空位坐下来了。

张亚勤的演讲当然紧接着若干个demo，其中Surface的demo在MVP Open Day已经看过了，这次还是同一个人来做。还有那个health care的video，也是MVP Open Day上面放过的，看来这两个月没什么变化嘛。整体而言，张亚勤演讲后的中文demo都是做一些我们已经知道的东西，没什么值得看的。

原本张亚勤的演讲只有1个小时，结果延长了很多，然后Dennis Flanagan才上来讲Windows 7。Windows 7的demo就非常有冲击力了，特别是device stage这样的特性。

在Windows 7里面，每个外设（包括网络外设）都有自己的图标，厂商可以设计一个和外设外观一样的图标，使得用户更容易在Windows 7中识别这一设备。例如你有黑白两个USB drive，都插入到电脑后，你会发现不知道哪个盘符是哪个USB drive的，要看看里面的内容才知道。在Windows 7里面，只要厂商制作了对应的图标，用户就能在图形界面上看到有区别的两个图片，也就可以在不了解何谓盘符的前提下正确操作这两个USB drive了。

此外，每一个外设都可以有自己的device stage，例如连接一部Zune后可以显示容量、电量，还可以显示为你推荐的MP3销售信息；又例如连接一部Nokia手机后可以显示有关的内部信息，以及Nokia网站上为这部手机推荐的新游戏。简单来说，硬件设备销售后不再是与硬件厂商脱离关系了，只要它连接到安装了Windows 7的PC，并且这台PC还连接着网络，硬件厂商就能得知这台设备的使用情况，并且为你推介更多的商品和服务，当然也可能包括免费的服务与技术支持。肯定有人会说这会导致隐私问题之类之类的，我相信最终Windows 7和硬件厂商会引入访问控制机制，让用户选择一台设备连接到Windows 7后是否允许相关信息通过网络传输，这个大家不用担心。

两个keynote结束后，就是抽奖环节。早上每一个人进来时都拍了一张照片用于抽奖，然后用这些照片拼成了一个巨大的奥运五环徽标，最终用Silverlight Deep Zoom来随机zoom in到某一个人的照片之上。这样的抽奖形式还是挺有创意的，不过有些照片实在太不清晰了，最后拿到了大奖的人到底是不是照片上的人，我们都不知道。

午餐是跟紫柔以及其它MVP一起吃的，紫柔带来了一个90后的实习生，是一个拿了国家奖学金去新加坡读高中的女生。她应该是紫柔的助手吧，不过我们说的东西她都听不懂，应该会觉得十分无聊。

随后，让我最不满的事情就发生了！今年的WinHEC和TechED一样，通过盖章来增加互动，总共有1200份Windows 7光盘和1000只2G USB drive可以通过盖全10个章后获得，并且日程表写着下午2:00开始换领的。但我们2:00回到会场发现今天的400只2G USB drive已经换领完毕了，虽然Windows 7光盘还是有的，但因为必须同时换领，所以也就相当于不能换领。既然日程表写着下午2:00开始就应该下午2:00开始啊，怎么能够提前开始发呢？！

下午的课程我们都没有去听，一群MVP聚在一起聊天。最有趣的一幕就是，竟然有人来主动搭讪那位90后女生。是不是非80后的人就分不清什么人是90后的呢？又或者是IT人士太闭塞了？反正我觉得90后的化妆和穿衣风格挺容易辨别的。我们分散地坐在媒体展示区的长沙发上，那个人直接无视我们问她还有没有盖章的那张纸。她说没有，那个人就问她是哪里的以及有没有名片。这时候作为大版主的紫柔自然冲出来说——我们都是微软中文技术论坛的！我相信那个人已经很无语了，但又不知道我们是干什么的，还是问我们有没有名片。紫柔就告诉他，你上微软中文论坛技术就知道啦。他估计还是不知道微软中文技术论坛是什么，不过很无奈地走了。真是难得见到有人如此直接搭讪的，而且还是在硬件工程大会上哦！

最后一个session解释时，会根据收回的反馈表抽奖，于是我们就找了一个讲用VHD（虚拟硬盘）引导启动的session去听听。最后提问阶段，有人问了能否引导启动一个装有Linux的VHD，speaker说VHD的技术都是开放的，虽然Microsoft没有实现的意向，但开源社区可以去做这样的事情。其实我有个问题，不过一直懒得问，那就是Microsoft能否和Apple合作，做一个Mac上从VHD引导启动的东东，那么将来我就可以在MacBook装Windows 7并且仅仅装到VHD里。

会议结束后，MVP在讨论是否组织一起吃饭，因为我约了人，要去拿张CF卡，所以就先走了。明天我要去参加SD2C，也就无法参加WinHEC了。

P.S.这篇文章不是因为MVP换取赠票而必须写的，而是因为换领礼品这件事实在搞得太不合理了，当时我就决定要写WinHEC的负面。

Chinese Blogger Conference 2008

2008-11-23T20:34:00.001+08:00

上个周末请了两天年假，回广州参加网志年会顺便回家。

第一天去到会场，就见到了LEMONed和hidecloud，然后拿到了我的fail whale tee。接下来的session……其实我不知道session讲什么，我想大多数人都跟我一样不关心session讲什么，大家只是找个机会来聚会而已。中午跟Elliot Ng一起吃了午餐，并且拿了一件CNReviews的tee。下午的session也是不知道讲了什么，然后就是自助晚餐了和Punch Party了。

自助晚餐吃的是点心，虾饺和牛肉丸都不错，但是鸡翅就很难吃。接着Punch Party正是开始，第一位上台的是Carol，介绍什么是Punch Party。所谓的Punch Party，就是每位speaker有7分钟的时间，大概就是20个slide每个slide讲20秒的时间再多一点。当晚的Punch Party做得非常perfect，每一个人讲的话题都十分之吸引人，做到了Punch Party所强调的punch效果——让人感觉耳目一新。Carol作为第一个speaker，把全场的气氛都调动起来了。中间有介绍大陆吃喝玩乐之行有多艰险的工头坚，还有介绍胖卡如何把宅男配送到乡下的。最后一位导演先生，表演了7分钟的无声演讲——开头只说了一句，“由于接下来的内容都很晦涩，所以自动进行静音处理”，接着做了7分钟演讲的动作与口型，幻灯片翻了几页，但是没说过一个字。对于所有参加Punch Party的人来说，这样的结尾实在是太impressive了！

Punch Party的好处显而易见，能够在最短的时间内让你了解到一些你可能永远都接触不到的知识，同时给你无限的震撼感。不过我觉得Punch Party对speaker的要求也挺高，否则也不容易做好。而且作为organizer，一场Punch Party必须组合不同类型的speaker。

第二天的session稍微有趣一些，不过依然没怎么听，莫非年会的习俗就是把重点放在晚上？下午年会结束后大家就跟着Issac Mao到“友鸡会”吃了火锅，然后到北风的凸凹酒吧去聊天。我也不知道最后大家是什么时候才回家的，我快到凌晨时已经想睡觉了，于是就回家了。

Live Mesh vs MobileMe

2008-11-13T22:59:00.001+08:00

最近在用Live Mesh在多台计算机上同步文件，而之前一直用MobileMe同步联系人、日程等信息外加系统备份，真希望把这两个服务的好处叠加起来。

Live Mesh的好处是可以指定任何一个目录进行同步，而非指定一个同步目录然后要同步的东西必须放在里面，这方面就比MobileMe要好。而且Live Mesh的自动同步客户端同时兼容Windows和Mac，而MobileMe仅仅支持Mac同步。Live Mesh唯一不足就是没有版本控制，不过我想要是有版本控制占用的网络空间和流量开销就成倍增加了。

MobileMe给我印象最深刻的是，我重装了我的MacBook后一登录MobileMe帐号就帮我把整个System Preferences给恢复了。当然，联系人和日程信息也都恢复了，这是现在Live Mesh完全没覆盖到的功能。另外对iPhone的push服务也做得很好，更新什么信息都在Mac上进行就可以了，根本不用管它什么时候同步到iPhone上。

我觉得最好就是把这两种服务结合到一起，一个帐号一个服务就把这些都覆盖了，当然我不介意付费。在TechED MVP Dinner上，我和一位做Azure的Microsoft员工聊了一下，说最好Windows上的程序都遵守Vista的规范，把代码和数据分开存放，也就是数据都放到C:\ProgramData下面，这样Windows也就如同Linux一样能够轻松备份纯数据了。接着只要把数据同步到cloud上面，例如说是Azure上层的Live Mesh，重装机器后就能够把数据重新同步回来了，只要再装上应用程序就一切恢复原装了。

开始翻译 Adobe AIR in Action

2008-11-10T00:03:00.001+08:00

Prototype and Scriptaculous的翻译已经是一年前的事情了，翻译了半年，休息了大半年，现在继续接受翻译的工作。仍然是图灵引进的书，仍然是Manning的In Action系列，这次的是Adobe AIR in Action。

其实AIR出来之前我就想去学习，很多很多技术都如此，不过翻译算是一个很好的学习过程，因为它逼着你认认真真把一本书读懂。这次着手翻译Adobe AIR in Action，我想半年后我也会熟悉AIR相关的技术。虽然我一直以来都对Flash和Flex没什么深入了解，但我希望这些知识反过来也能用到Silverlight开发上，结合两派的模式从而进化出一种更好的实践方法。

另外我还介绍了身边的朋友去翻译Practical Prototype and Script.aculolus。Manning即将发布Silverlight 2 in Action，如果图灵引进这本书的话，我也去看看是否能够参与翻译。