我在 TechEd 2009 演讲的资源 (Silverlight & Ajax)

这是TechEd第二天下午的Silverlight课程资源。关于百度Hi的Silverlight实现方面的任何问题，都欢迎与我讨论。

基于Silverlight的RIA架构及百度应用

View more presentations from Cat Chen.

这是TechEd第三天下午ASP.NET 4课程资源。与ASP.NET AJAX 4.0相关的问题可以在此讨论。

建站大业，实战ASP.NET 4

View more presentations from Cat Chen.

User Friendly 2009

这个周末有幸去上海参加了UPA China组织的用户体验行业大会User Friendly 2009。参会人员大多数都是设计师，会议内容也是他们熟悉的内容，但对于像我这样少数的参会工程师来说，这样的会议确实让人大开眼界。

在整场会议当中，我觉得让我印象最深刻的就是Jared M. Spool的Keynote了，我觉得其中一些观点是非常有价值的。至于其它的Workshop，也都能学到一些实实在在的东西，不过就没有Keynote那么震撼了。下面就分享一些我印象最深刻的内容：

从ROI到ROX

Jared M. Spool的Keynote标题为The Dawning of the Age of Experience（体验时代的来临）。这跟我们传统所说的产品设计有什么不同？那就是我们需要把视觉从产品放大到体验上来。在这里，我想借用MIX 09上Bill Buxton的Keynote中的几页幻灯片来解释一下：



Bill Buxton有一辆这个型号的自行车，而且这也正是Roland Green获得公路赛冠军所用的自行车型号。画面上给你传达的是这辆自行车相关的信息，但又如何？这世界上还有千万款不同的自行车，为什么要在乎这特定的一辆？这不是人们想要购买的东西。



这张幻灯片是同一辆自行车的不同摆放方式，就像是Pixar动画短片里面的那个独轮车一样。这赋予了它一定的个性，这个思路是对的，但这仍然不是你想要购买的东西。



这才是体验设计师应该关注的事情——你骑着车从山上沿着小径冲下来，一直冲到溪谷里，伴随着你的尖叫水花四溅。这是一辆什么型号的自行车？从画面上看不出来。这是一辆什么牌子的自行车？也说不清楚。这从根本上就和自行没有关系，真正有关系的是你尖叫着冲进小溪里的那种刺激的体验。

过往我们谈论的是投资回报（ROI），现在我们谈论的是体验回报（ROX）。我们想要向用户推销我们的产品，但实际上他们想要从我们这里购买体验，因此我们必须改变思维方式，考虑向用户提供什么样的体验。

举个例子，用户在你的网站上购买机票，他想要买的其实不是机票这样一个商品，而是一趟舒适的商务旅行。因此，过往只卖机票的网站开始加上酒店服务。在你输入往返日期后，不仅仅搜索往返机票，还搜索目的地的酒店信息。只有我们向用户提供符合他们预期的体验时，我们才能够获取到高回报。

Chicken Sexer的故事

什么是Chicken Sexer？就是一些判断小鸡性别的专业人员，他们盯着眼前一群两星期大的小鸡，就能指出每一只是公的还是母的，精确率最高可达97%！你让他们说说经验，他们也可以归纳出一些来，例如根据毛色、屁股来判断小鸡性别，但这些规则对于外行人来说一点意义都没有，你实在无法看着一只小鸡然后利用这些规则判断出它的性别。

那么Chicken Sexer是如何练成的呢？新人必须跟着一位大师一起工作，新人负责指出小鸡性别，说错了大师就狠狠地打一下新人的手臂。在接受训练之前，任何正常人都有 50%的正确率；在开始接受训练之后，新人的正确率会先下跌到40%——因为他想得太多了。三个月后，正确率会慢慢恢复到50%，一年之后，你的正确率能够提高到60%；再过两三年，你的正确率能够提高到80%。如果你真的把这当作你毕生的事业来做，正确率可以提升到95%。

Jared M. Spool对这个故事的总结是，有些事情是可以学习而无法自省（introspection）的。在这里，“自省”是指对自身心智或情感变化的观察和检验。设计工作也属于可以学习无法自省——你可以通过学习让自己的设计能力获得提升，但你无法归纳出你在学习过程中发生了哪些变化，以便让其他人直接通过同样的变化以获得同样的结果。

我对这类技能的学习方法看法是，你必须在大师级人物的指导下学习，你才能成为大师。这不是任何人能够通过理论知识的学习或者基础技能的训练就能习得的，这些只能让你胜任需要这些技能的工作，但不能让你成为大师。在你成为大师后，你也无法将你的技能归纳为一组理论，你只能通过亲自训练让更多人习得跟你一样的技能。

企业内推广的两个关键

在Tencent CDC的统一体验的设计Workshop上，我了解到了在企业内推广统一体验的两个关键：老板和项目。

首先，需要老板重视这件事情。例如在Tencent内部，马化腾相当于“首席体验官”的角色，他重视这个事情，对于做得不好的他会站出来指责，别人自然愿意接受你要推广的，因为没有谁想被老板指责。其次，需要通过有价值的项目来证实你推广的东西。如果你的东西你应用于QQ，对其它Tencent产品来说自然就有说服力了。

上述就是User Friendly 2009对我最有启发的几点。如果你对此类会议的信息有兴趣，欢迎订阅我的博客：

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

Tech·Ed 2009

今年是我第一次以讲师身份参加TechEd，碰巧TechEd所在的周末我们要搬家到百度大厦，所以我星期四早上搞掂打包工作后就赶到了会场。凭着《讲师指南》进入会场后，我直奔讲师休息室领取证件和衣服，然后再跑到MVP站台领取印章，接着等待第一天下午的Keynote开始。

尽管我没有参加Windows 7 Launch而跑去参加SD2C了，但我仍然觉得第一天Keynote的一半是Windows 7 Launch的重播。至于Keynote的另外一半，则是与Windows 7并列于New Efficiency系列的Windows Server 2008 R2以及Exchange Server 2010。我认为比较有趣的是Exchange Server 2010的演示，这个演示通过丢失笔记本电脑的场景来说明虚拟桌面的强大——换一台电脑，同一个桌面；这个演示还通过丢失手机的场景来说明远程擦除手机数据的特性。没错，这些功能都很好，但我个人的观点是——如果你经常丢失手机和电脑，Exchange Server 2010的价值才会被凸显出来。最后，我觉得Exchange Server 2010最有价值的功能就是内置的VoIP了，这相当于内置了一个Google Voice，搭配Outlook 2010的邮件视图，你就可以在自己的企业内享受全套的Gmail + Google Voice体验了。

Keynote之后的是面向Microsoft员工和讲师的Welcome Dinner，也是难得的交流时间——白天大家都忙于会务、讲课、停课，晚上才有时间停下来聊聊技术。当看到有人说自己讲了十年TechEd之后，就如同看到Rick Strahl博客上的的“MVP since 1997”一样震撼——原来有人一直在做这样的事情，并且坚持了10年之久。有兴趣有动力去做好一件事情不难，难就难在坚持做10年。

第二天上午我抽空去郭晓颖的Session上听了一下她是怎么讲Silverlight的，顺便在她的Q&A环节为自己的Session卖了一下广告。其余时间，我都在忙于调整我自己的pptx，直到下午我的Session开始为止。在Session结束后，我又花了一些时间解答大家的问题，以及帮大家盖MVP的章，然后才赶往Jeff的Session听他讲MVC。

第二天晚上是MVP Dinner，很高兴又能跟一群MVP朋友聚会了。为什么MVP Dinner有价值？这并不在于MVP为Microsoft创造了多少价值，而在于MVP擅长通过沟通来创造价值，因此能够跟一群MVP沟通一定能为你带来价值。因此，MVP Global Summit、MVP Open Day、MVP Dinner等等每年固定的聚会我都尽量不缺席。

最后一天，除了在王洪超的Session上讲讲我熟悉的ASP.NET AJAX 4.0，我就没什么别的工作了，因此我有时间就在会场周围走走，看看有谁要盖章的。有一次我走在三层展区，看到一位美女迎面走来，她看着我想要说什么但又没说，我就猜她想要找我盖章，但又不确定我是不是宣传单张上的那个人。于是我直接走过去问她，“你是要找我盖章吗？”她说是，然后还呼唤她的同伴过来盖章。我不知道如果我不主动问她的话事情会怎么样，但机会有时候就是这个样子，如果你看到了又不主动问，你就有可能错过，而问一下又不会有什么不好的。对我来说，不为她盖章并没什么损失；对她来说，或者就要多花一些时间去找另外一位MVP了。

SD2C 2009 (Part 2 - Session & Forum)

SD2C的第一天晚上，我在「开放平台」和「PPT制作秘诀」两者之间犹豫，最后选择了去听蔡学镛的「尼古丁+咖啡因...不瞌睡的PPT制作秘诀」，原因是我觉得如果蔡学镛能教别人写不瞌睡PPT，那么他自己的PPT至少也应该是不瞌睡的。事后证明我的选择是没错的——别人告诉我「开放平台」论坛成了平台和开发人员互相责骂对方的战场。

蔡学镛把制作PPT比喻为制作生鱼片，要经过选材、处理、装饰这三步。在选材方面，一个PPT讲的内容最好是相当于一章书的内容，时间不能超过90分钟，而讲述的事情不能超过7件。接下来的处理，要注意做好破题，引起受众的兴趣，并且每一小节的结束时都要有总结。一页PPT所表达的意思，有可能相当于一个词、一句话、一段话，我们应该多用表达一句话的PPT页面。最后的装饰会需要用到不少图片，通过使用正确的关键字联想策略，往往都能搜索到你想要的图片。

SD2C的第二天，我原计划要听听周爱民的「实践者思想」和蔡学镛的「DSL设计与实践」的，结果上午听完Gary Bennett的「iPhone SDK简介」之后就被吸引住了，下午的时间都放在iPhone相关课程上了。这说明了，课程的首要条件还是要能把人吸引住，不会让人想要睡觉，也不会让人想要换个课室看看。在满足这个前提条件后，才有资格来讨论内容的知识性如何。我在听了几节iPhone开发的课程后，又开始对iPhone开发充满兴趣了。

晚上的「程序员软技能」论坛是我最期待的，因为这个话题可以讲得非常有震撼性。讲得好的话，这可以让很多程序员发现自身的unknown unknown（不知道自己不知道的事情）来，把这变为known unknown（知道自己不知道的事情）之后，只要努力了就能获得改善。结果主持人刘江自己戴上了嘉宾的帽子就开始不停地说，搞到台下有人举手说「在刚才的30分钟里面您已经讲了20分钟喇」。同时，估计因为刘江是做图书的，所以花了不少时间在读书的话题上，此外再提到了一些企业文化和沟通技能之类的东西，顺便还鄙视了一轮内地的高等教育连幼儿教育都不如（来自台湾清华的蔡学镛很无辜地无法参与到这个话题中来）。可能是我原本对这个话题的期望太高，所以我对这个论坛挺失望的。将来有空我会专门写文章讨论一下程序员常见的unknown unknown。

最后一天的SD2C我没有参加，因为已经没什么让我想要听的了，所以我选择了去参加Windows 7 Community Launch。有微软社区的人说SD2C是「傻蛋2.0大会」，选择了Visual Studio 2010 Beta 2 Launch、Windows 7 Launch、Windows 7 Community Launch这三天来举行，分明就是跟微软过不去。说实在的，我也觉得今年的SD2C日期选择失策了，明知道Windows 7对Microsoft有多么重要，也明知道发布日期是哪一天，还偏要选择一个冲突的日期。希望明年的SD2C能够选择一个更好的时间吧，相信会务今年已经通过举手投票搞清楚大家的喜好了——最好是在星期二三四开会，因为星期一和星期五工作压力小，同时星期六日是用来休息的。

SD2C 2009 (Part 1 - Keynote & Meal)

一年一度的SD2C又来了，今年的时间由去年的两天半扩充到三天，第一天只设主会场，全部都是keynote。

跟去年的情况类似的是，keynote环节基本上就是赞助商专场，每个赞助商都来从技术的角度说一下自己当前最重视的市场。例如说Microsoft开始重视Team Foundation Server的市场占有率了，于是就在Visual Studio 2010的keynote上介绍TFS的特性，所占比例比VS2010自身还要多。当然，keynote里面也有一些是有启发性的，例如IBM讲的大型企业中的敏捷实践，这就属于我认为比较好的keynote。

由于今年的话题集中在云和移动上面，所以keynote大多与这两个领域相关。能够上去讲keynote的人，当然是要有一定水平的，不能讲一些很肤浅的内容，但如果因此就把keynote弄得很高深或者很抽象又弄巧成拙了。高深的内容固然能够表现出演讲者很有水平，问题是这样一个面向上千受众的活动，有多少人能够对如此多个keynote的话题都有深入了解呢？就算你对其中一个话题很有了解，觉得讲得如此有高度很对你胃口，但你也总有n个其它不了解的话题吧，那些话题你听起来也会觉得是云里雾里的。

在我看来，优秀的keynote应该是这样子的——它能够阐述一个很新颖的观点，或者提供一种全新的视觉，使得无论你原本对这个话题了解多少，你都会被震撼到——这个事情我有所了解，但为什么我之前就没有尝试过从这个角度来思考呢？这其实也就是Punch Party的优势，无论受众具备怎么样的背景，都能感受到全新观点带来的冲击力。如果能够打到这样的效果，我并不在意一个keynote是否顺便在推销某个企业或者产品。

接下来要说说吃饭的问题，但在此之前让我先说说我对MVP Program的一些观点，这纯粹是个人观点，也不一定符合事实。我觉得，就拿MVP Summit这样一个全球峰会来说，每年要接待来自全球各地的几千人，为他们提供四天的食宿，平均分摊到每个与会者身上的费用肯定是不少的。如果MVP Summit的作用仅仅在于让大家聊聊技术，我想Microsoft作为一家商业公司是不会愿意花这笔钱的，就算Microsoft想要这样做，股东们也不会同意。因此，MVP Program必然是能够产生价值的，并且分摊下来每位MVP为Microsoft创造的价值应该大于Microsoft为他所作的花费。这些价值可能包括，MVP为用户解答问题，为客户带来技术培训，也就相当于节省了Microsoft的服务成本和市场费用。同时，MVP也会积极反馈关于产品的各种问题，这也属于创造价值的部分。

回到SD2C的事情上来，CSDN其实对热心贡献的用户非常好，例如说提供SD2C赠票。但是CSDN从来都对此事保持非常低调的姿态，生怕激怒那些付钱买票的人，同时也怕更多人去找他们要赠票。我的疑问是，为什么这些对热心用户的正面激励不能好像MVP Program那样光明正大的做呢？如果一位热心用户为CSDN创造的价值能够大于SD2C门票的成本价，那送他一张赠票肯定还是赚了的。

为什么我要说这件事？因为今年的赠票不包括背包和晚餐。不包括背包我觉得可以理解，金融危机嘛，能够让我免费来参加SD2C我已经非常满足了，没有背包也没所谓。但是不包括晚餐就非常不人性化了——这不是逼拿赠票的人不参加晚上的活动提前离场吗？况且，班车还要等晚上活动结束后才有，傍晚离开还是挺不方便的。于是我就在会场的做啥大屏幕发起讨论，问问没晚餐票的人准备如何吃晚餐——我的本意只是想组织落单的赠票使用者一起吃饭，反正拿赠票的大多是CSDN活跃用户，大家也都是认识的。同时我考虑到CSDN不希望公开有赠票这件事，我一开始也刻意回避了这个话题，后来有人公开讨论了我也就跟着讨论了。

结果是什么呢？CSDN会务组单独给我一张晚餐票，并告诉我原因是蒋涛看到做啥大屏幕的内容了。这就让我感觉到很奇怪了，两天的晚餐票值多少钱呢？值得把事情搞到这样子吗？CSDN自己是做媒体的，应该十分清楚媒体的影响力。赠票邀请来的人，都是技术社区上最活跃的人，他们的博客都是具有相当影响力的媒体，给这些人留下这样一个负面印象，CSDN损失的是多少价值呢？这是否已经超过了两张晚餐票的价钱呢？我相信以蒋涛在CSDN这么多年来做媒体的经验，应该在这件事被搬上大屏幕讨论之前就把帐算清楚了吧。

最后一点，也就是这样做是否厚道。如果CSDN以媒体身份受邀参加这样一场大会，本来是希望借此机会向自己的读者传递更多更好的技术资讯的，然而却受到大会主办方不公平的对待，搞到连饭都没得吃，你们会喜欢被这样对待吗？如果你们自己也不喜欢被这样对待，那就在如此待人之前先考虑清楚。

国际长途比国内市话便宜

众所周知，在国外买国际长途电话卡打到中国，比国内市话还要便宜。这说明了国内话费之高完全是垄断造成的，其实根本就不值这样的价格，因此我们能够打国际长途就打国际长途吧，尽量别再为国内垄断行业支付额外的话费了。

在国内要通过国际长途拨打国内电话，通过VoIP就行了，Skype和Google Voice都可以，它们的价格都很便宜。就拿移动话费来说，非漫游非长途要¥0.29，漫游或/且长途要¥0.39，但是Skype只要$0.021（每次接通需要$0.039连接费），而Google Voice只要$0.02（无需连接费）。

如何使用Skype拨打国内电话呢？你可以用信用卡通过PayPal购买Skype credit，然后就可以用任何Skype客户端拨打国内号码了。对我来说最方便的是，iPhone上面有Skype客户端，只要在有Wi-Fi的地方我都可以用它来打电话。当然，Skype通话质量会受带宽影响，如果你所在的区域信号不好或者带宽有限，通话质量就会下降。

在没有Wi-Fi的时候怎么办呢？通过Google Voice的回拨服务可以解决问题，当然前提是要通过网络（GPRS/EDGE或3G）访问Google Voice。Google Voice拨号可以拨通对方的国内电话，但回拨只能拨美国电话，怎么办呢？我们可以通过购买Skype Online Number解决这个问题。这时候Google Voice和Skype会同时拨通双方电话，然后建立双方通话，话费也就是$0.041而已，还是比移动话费稍微便宜一点。

可能很多人会怀疑，花那么多美元来拨打国际长途，真的比国内话费要便宜吗？这就要看你的具体使用方式和套餐组合方式喇。我曾经因为每天漫游加长途贡献了不少人民币给中国移动，换成Skype后至少省了一半的钱，所以从此我就决定改为贡献美元给Skype好了。如果你并不介意花$10购买Skype credit试试，可以实际使用一段时间后对比一下烧钱速度后再决定。

你的网站「被兼容」了吗？

一般情况下，我们只会讨论我们的网站如何主动兼容某某浏览器，被动地等待浏览器来兼容我们的网站是不切实际的幻想——哪个浏览器会那么伟大，原意主动为一个不兼容的网站而作出改变呢？IE8就是这样一个伟大的浏览器，Microsoft就是一家这样伟大的企业。

故事是这样的，我们有一小段JavaScript依赖于userAgent属性，同样是用IE8进行浏览，在测试环境上userAgent显示为MSIE 7.0，而在生产环境上userAgent显示为MSIE 8.0。为什么会这样呢？打开Developer Toolbar后，发现原来是Browser Mode这个开关在搞鬼——当Browser Mode是Internet Explorer 8的时候，userAgent就是MSIE 8.0；当Browser Mode是Internet Explorer 8 Compatibility View（兼容性视图）或Internet Explorer 7的时候，userAgent就是MSIE 7.0了。

接下来的问题是，我们并没有刻意去拨动这个开关啊，两个相同的页面怎么在不同的环境中默认显示为不同的Browser Mode呢？我的猜想是，这是由于域名不同而引起的——Microsoft自己维护着一个Compatibility View List，当访问该List中的站点时，IE8会自动启用Compatibility View，也就是将Browser Mode切换到Internet Explorer 8 Compatibility View。接着我在地址栏输入以下地址，检查了一下我本地最近更新的List：

res://iecompat.dll/iecompatdata.xml

事实表明，我们测试用的baidu.com域名确实在上述List中，但部署到baidu.jp后也就脱离了该List。这就很好地解释了我们遇到问题，同时也提醒我们域名已经成为了IE8测试中不可避免的一个紧耦合因素。在过去，我们可以简单地认为，部署在不同URL的相同页面在同一款浏览器中显示出来总是一样的。但现在我们必须修正这句话了，仅当不同URL都基于同一个域名时上述命题仍然成立。

通过这个案例，希望能让大家了解到在开发与测试过程中保持域名一致的重要性。如果你开发的页面要部署到example.com，你最好在develop.example.com上开发，在test.example.com上测试，然后再部署。如果你需要在本机进行开发测试，也要通过改hosts模拟一个localhost.example.com来进行测试与调试，以确保代码在最终部署后能执行在相同的环境下。

Twitter Suspension

我的Twitter帐号，也就是@CatChen，经历了一次长达半个月的suspension。



8月5日早上醒来，发现我的Tweetie不能再更新，打开Web看看，发现如下提示：

This account is currently suspended and is being investigated due to strange activity. If we have suspended your account mistakenly, please let us know. See Suspended Accounts for more information.

这时候我觉得很无辜，竟然被误判为发垃圾信息的用户了。当然，这可能和最近Twitter系统不稳定有关，因为有些人的following被清空了，自然会导致另外一些人的followers数量暴跌，由此触发垃圾用户判别标准也是有可能的。无论如何，我只能按照它给出的Suspended Account帮助链接寻求帮助了。

打开帮助页后，发现了一条令人极度无奈的信息——“帐号有可能要被封禁至少30天以备研究之用”。你Twitter要研究和改进反垃圾信息策略可以啊，但你不应该为了自己的研究就封禁我的帐号30天吧！不过我还是先提交请求好了，反正现在也没什么更好的解决方案了。

第一次在Web上提交请求，系统发了一封自动回复给我，我大概看了一下，就存档了。结果请求第二天就关闭了，问题没有得到解决。第二次提交请求，质询为什么请求关闭了但封禁没结束，系统再发了一封同样的自动回复给我，我仔细阅读后才发现，信的末端说明要回复此信解释为什么我觉得这个封禁是错误的。回信后，系统指派了人负责跟踪这个问题，但一直没有任何进展。

后来我在Twitter上看到有人说，要联系suspended@twitter.com，我就再发信去质询进度，这相当于创建了第三个请求。系统继续发回自动回复，我又继续回信解释，接着问题第二天就解决了。虽然我并不能确定，是不是联系suspended@twitter.com确实帮助我快速解决了这个问题，但我建议不幸被封禁的人都应该试一试这个方法，然后告诉我这是不是一个有效的方法。

最后，这次事件引起了我的一个想法——Twitter如此错误封禁我的帐号半个月，和GFW随意封禁一些无关紧要的网站随后又解封，有什么本质上的区别吗？对我造成的影响其实是没有区别的，这两者都只会提高我日常生活的成本。

一直以来，我们依赖于网络从不同的网站获取信息，而GFW有能力随时终止网络服务的能力，所以GFW让人觉得讨厌。最近，Twitter也成为了我们获取信息必不可缺的一个途径，它自身同样具备随时终止服务的能力，因此Twitter并不可爱。与Twitter类似的其它核心服务也如此，如果你的Gmail帐号有一天被封禁了，你使用的所有Google服务随之而终止，Google无论如何都坚持它封禁你的帐号是没有违反服务条款的，这时候Google本质上和GFW还有任何区别吗？

jQuery is DSL (Part 2 - jQuery)

jQuery的Internal DSL形式

在上一篇文章里面，我们了解到了Internal DSL的具体形式，形如：

/* Method Chaining */
computer()
  .processor()
    .cores(2)
    .i386()
  .disk()
    .size(150)
  .disk()
    .size(75)
    .speed(7200)
    .sata()
  .end();

然后我们在看看一段典型的jQuery代码：

$("ul#contacts li.item")
  .find("span.name")
    .click(function(e) { $(e.target).siblings(".more").toggle(); })
    .end()
  .find("input.delete")
    .click(function(e) { $(e.target).parents(".item").remove(); })
    .end()
  .find("div.more")
    .hide()
    .end();

从结构上来说，是不是跟上面那一段Internal DSL的例子很相似？就算我们不看对应的HTML，我们也能猜到这段jQuery代码的含义：

• 遍历<ul id="contacts">中的每一个<li class="item">
  （这看起来是个联系人列表）
  • 对于里面的<span class="name">
    • 绑定click事件，操作是显示/隐藏class="more"兄弟节点
      （这是估计联系人姓名，点击后切换详细信息的显示/隐藏）
  • 对于里面的<input class="delete">
    • 绑定click事件，操作是把class="item"父节点删除
      （这应该是用来删除联系人的）
  • 对于里面的<div class="more">
    • 隐藏这个div
      （默认隐藏详细信息？）

从这里我们已经能够看出jQuery的Internal DSL形式带来的好处——编写代码时，让代码更贴近作者的思维模式；阅读代码时，让读者更容易理解代码的含义。不信？我们看看与jQuery拥有相似功能的Prototype是如何实现上述逻辑：

$$("ul#contacts li.item span.name")
  .invoke("observe", "click",
    function(e) { $(e.target).next(".more").toggle(); });
$$("ul#contacts li.item input.delete")
  .invoke("observe", "click",
    function(e) { $(e.target).up(".item").remove(); });
$$("ul#contacts li.item div.more")
  .invoke("hide");

这是我用Prototype所能写出的最贴近Internal DSL的形式了。（如果你能够写出一个更自然的版本，欢迎分享。）在Prototype里面，能够返回一组元素的操作就只有$$()，并且它只能作用于全局，缺乏jQuery中find()或者filter()的功能，所以这一组描述联系人列表行为的语句无法组合在一起，必须逐一定义每类元素的行为。此外，此例子中每类元素都仅仅指定了一个行为，因此Prototype的invoke()写法看起来还是和jQuery的click()写法很相近的。但如果一类元素拥有多个行为，Prototype的invoke()就不能好像jQuery那样链式调用下去了，必须每一个行为重头写一个$$()，或者把invoke()改成each()加匿名函数。无论是那种做法，都只会降低代码的可读性。

jQuery的语法分析器

我们都知道，Internal DSL的实现依赖于对语法分析器的封装，对Internal DSL的调用其实都是对语法分析器的调用，经过语法分析后再构造出对底层API的调用。例如jQuery当中的click()，它依赖于当前的状态，也就是前面$()筛选出来的节点集合，把click()解释为要为这一组节点绑定DOM的click事件，最后再调用DOM API完成任务。在这个例子当中，DOM API相对jQuery API而言就是底层API了。

jQuery可以说是挑了一个最容易实现的语法模型来做，永远只有一种token，因此永远也只有一种状态，这种状态当然也是永远有效的，你根本不可能给jQuery输入一个当前状态无效的token。jQuery的唯一状态就是一个jQuery对象实例，其本质就是一个元素集合。读入的token可能是各种针对这个元素集合的操作，但它的返回一定还是一个元素集合。这使得jQuery的语法分析器不会进入无效状态，也就无需判断无效状态，因此大大简化了Internal DSL实现中常见的一个难题。

小结

通过拿jQuery和Prototype做对比，我们可以发现jQuery用非常低的成本实现了Internal DSL，同时带来了Prototype所没有的明显好处。这可以看作是一个很好的范例——如果你需要描述的业务逻辑能够归纳为简单的语言模式，为此实现一门Internal DSL的性价比将会是很高的。你需要做的仅仅是为这个简单的语言模型实现一个简单的解释器，接着你就可以享受贴近人类思维模式的接口了。

最后，如果你喜欢我的文章，可以考虑订阅我的博客：

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

jQuery is DSL (Part 1 - DSL)

jQuery刚刚出来的时候，我没有太多关注它，觉得这不过是Yet Another JavaScript Library。早期的jQuery专注于DOM节点的筛选与操作，不提供众多的基础类扩展，更不提供UI组件，因此体积能够做到很小。然而，我实在看不出它和我熟悉的Prototype比有什么明显的优势——jQuery能做的各项独立的操作，Prototype都能做。

后来用jQuery的人越来越多，并且大家都爱用它的链式方法调用，甚至还把这种写法推广到其它语言中去。例如ASP.NET MVP Omar AL Zabir就把他的服务器端C#组件设计为支持链式方法调用的。这时候我才开始关注jQuery，并且逐渐喜欢上了链式方法调用的写法，也在我自己的JavaScript组件中实现类似的API（参考Async和Overload）。最后，我突然明白到，这其实就是一种Internal DSL嘛！

在这篇文章里，我准备先讨论Internal DSL，在下一篇文章里面再解释为什么jQuery是Internal DSL。现在我们就从最根本的问题开始吧——

什么是Internal DSL？

DSL是指Domain Specific Language，也就是用于描述和解决特定领域问题的语言。例如说，我们有专门描述字符串特征的正则表达式，有专门描述数据库查询的SQL，有专门描述XML结构的DTD和XSD，甚至有专门描述XML变换的XSLT，这些都是DSL。

当然，并非我们关注的领域都有现成的DSL，这时候我们有三个选择：

1. 使用通用语言描述该领域的问题（non-DSL）
2. 发明一门全新的语言描述该领域的问题（External DSL）
3. 在一门现成语言内实现针对领域问题的描述（Internal DSL）

例如说，我们现在要描述一个很简单的金融领域问题，“我在花旗银行存款$200”这样一句话对应的三种法写法可能是：（假设已经存在I和CitiBank两个实体实例）

1. I.DepositTo(new USD(200), CitiBank); /* C# */
2. I deposit 200USD to CitiBank /* E-DSL */
3. I.deposit(200.USD()).to(CitiBank); /* I-DSL */

第1种做法的成本最低，你只需要有OO的思想就可以了，你总能把实体类设计出来，但可能和人类描述此领域问题的思维方式有一定偏差（为什么USD可以new？为什么不是deposit [something] to [somewhere]？）。

第2种做法的成本最高，你需要写一个全新的解释器，至少是写一组全新的规则，然后让YACC这类工具帮你生成一个解释器，但这样出来的语法最贴近人类思维方式，甚至就如同自然语言一样流畅。

第3种做法术语上述两者的折中方案，如果语法不太复杂可以使用Builder模式实现语法分析，写出来的语法相当贴近自然语言，但还是有学习门槛。由于脚本语言有相当的灵活性，所以现在很多人倾向于选择在脚本语言内实现Internal DSL。

如何构造Internal DSL？

常见的两种Internal DSL实现方法是Method Chaining和Function Sequence。如果我们需要描述一台机器的硬件组成，两种实现方式的代码分别如下：

/* Method Chaining */
computer()
  .processor()
    .cores(2)
    .i386()
  .disk()
    .size(150)
  .disk()
    .size(75)
    .speed(7200)
    .sata()
  .end();

/* Function Sequence */
computer();
  processor();
    cores(2);
    processorType(i386);
  disk();
    diskSize(150);
  disk();
    diskSize(75);
    diskSpeed(7200);
    diskInterface(SATA);

无论是哪一种写法，中间都必须写一个分析器层。就如同语法分析器需要使用状态机一样，Internal DSL的实现也必须内置一个状态机，以记录当前执行到什么状态了，并且接下来可以转移到哪些有效状态。

由于这不是一篇专门讲语法分析器和状态机实现的文章，所以我们把关注点保持在API层面就可以了，不深入讨论其实现细节和成本。我们知道链式方法调用能够实现Internal DSL就够了，至于jQuery是如何利用好这一点的，我们在下一篇文章里再作讨论。

小结

在这篇文章里，我们了解了Internal DSL与External DSL之间的区别，同时还了解到实现Internal DSL的具体方式，这为我们接下来讨论jQuery的Internal DSL式接口做好了铺垫。在下一篇文章里，我们将深入地来看看为什么jQuery的接口要如此设计，它能为用户带来了怎样的便利，同时它自身的实现上又有什么优势。

如果你不希望错过下一篇文章，你可以考虑订阅我的博客：

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

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

在上一篇文章里，我们设计了一套能在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这样的语言是如何处理函数重载匹配的。一般语言进行函数重载匹配的流程都是这样子的：

1. 参数个数 - 参数个数不对的重载会被排除掉
2. 参数类型 - 参数类型无法隐式转换为签名类型的会被排除掉
3. 匹配个数 - 排除完毕后，剩下匹配的签名个数不同处理方法也不同
   • 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 - 设计)

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 - 实例 & 模式)

我们用了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) {
  return 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 - 链式实现)

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

调用入口

链式调用存在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)

中国程序员有美国梦吗？

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 - 链式调用)

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

现实开发中，要按顺序执行一系列的同步异步操作又是很常见的。还是用百度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 - 代码实现)

在上一篇文章里，我们说到了要实现一个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 - 用例设计)

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

传递回调

我们首先要考虑的一个问题是，如何传递回调入口。在最传统的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 - 问题 & 场景)

问题

在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)

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

如果说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)

这次去参加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)

虽然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)

在上一篇文章里，我们说到了如何使用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>

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

1. 在body元素上声明有关的xmlns，将JavaScript中的名字空间映射到HTML上，或者你可以理解为映射到XML/XHTML上。
2. 通过sys:activate="*"这个声明，让ASP.NET AJAX知道它需要去解释页面上所有的声明性语法，并激活对应的组件。
3. 将原本使用$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)

自从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 书籍

在美国旅行时，无聊地在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

这是我第一次参加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 上的内容强调与弱化

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

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

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



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

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



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

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

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



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

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

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

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

GMP Party EP2

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

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

• 尚文欢: 为什么喋喋不休？
• Jinghua: Where to meet pretties
• Webleon: Blogger黑板报─GMP新年山寨特别版
• Chloe: What a girl wants? a feminine user behavior for fashion website design
• Leo: 你为什么找不到喜欢的工作
• 龚纹: 其实我们可以更懂星座
• 璎珞天色: 如何组织一场Open Party
  

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成为一个相对稳定的活动。

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

这篇文章是接着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

这几天参加了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。

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

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

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

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

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

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

WinHEC 2008 China

今天是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

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

第一天去到会场，就见到了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

最近在用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

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，如果图灵引进这本书的话，我也去看看是否能够参与翻译。

以服务器端为中心的 ASP.NET AJAX 模式 (Part 2 - Control)

在上一篇文章当中，也就是《以服务器端为中心的 ASP.NET AJAX 模式 (Part 1 - Behavior)》，我们探讨了较为易用的Behavior模式。之所以说它较为易用，是因为它不涉及和原有Page处理流程的交互，即使访问网络也是访问独立的Web Service（包括Page上的[WebMethod]），因此和Page处理流程的设计绝对是正交的。但有时候我们需要的就是与Page处理流程的交互，这时我们不得不使用与服务器端逻辑紧耦合的Control了，这正是本次文章要讨论的内容。

在基本的 ASP.NET AJAX框架下，我们有三种方法来做基于Control的Ajax操作，它们分别是UpdatePanel、ICallbackEventHandler 和IScriptControl，下面我们就分别看看它们的特点和使用场景。

UpdatePanel

UpdatePanel 是与服务器端逻辑进行交互的多种方案中最易用的一个，甚至就不能称之为交互——你根本就不需要触及任何客户端逻辑。一个服务器端操作，经过 UpdatePanel的“劫持”，变成了一个客户端操作，而这个客户端操作又直接调用对应的服务器端操作，就这么简单。

如果用UpdatePanel来做一个带分支的选择对话框，那应该如何设计？思路可别跑到客户端的confirm方法上去，那可太绕了，或者说太不 ASP.NET AJAX了。用UpdatePanel，就应该坚持它的理念，一切客户端操作都是幻象，所有操作其实都是在服务器端进行的，包括选择对话框。要按 ASP.NET的思路来做，我会做一个选择对话框控件，它的实质可能是一个浮动层模拟的对话框，这属于实现细节，我们不用太关注。重点是，这个选择对话框的分支逻辑是完全在服务器端进行的，Async PostBack之后服务器端根据提交回来的数据决定如何触发事件。这样做整个分支选择的逻辑就是内嵌在Page处理流程当中的，不需要通过 Cookies或者Session来做数据的中转媒介，避免了Page处理流程与更大作用域中的数据的紧耦合。

UpdatePanel 适用于逻辑完全在服务器端的开发，并且我建议使用UpdatePanel时也就把所有逻辑放在服务器端，不要去写一些混合服务器端逻辑与客户端逻辑的代码。有人会说，你看老赵就很喜欢去动那个 Sys.Net.WebRequestExecutor来改变UpdatePanel的行为啊，但其实这属于分层设计思想中的一部分，他去动那个东西改变的也就是一个分层内的逻辑，只要层与层之间的接口不变，具体实现是可以按需设计的。但如果你用了UpdatePanel，同时又用Cookies或者 Session来传值，这就跨越了n个层，增加了不少耦合度。

ICallbackEventHandler

关于ICallbackEventHandler，我已经说过无数次了，重点还是你必须用Page处理流程来思考，只要你理解了Page处理流程，你就明白为什么ICallbackEventHandler在.NET Framework 2.0 Beta2中只有一个方法，而到了RTM要分拆成两个方法。具体可以参考《ASP.NET 2.0 ClientScript Callback》，我就不再重复了。

如果用 ICallbackEventHandler实现一个带分支的选择对话框，又如何做？和使用UpdatePanel的做法类似，我还是会做一个选择对话框控件，并且这个控件继承自ICallbackEventHandler。为这个控件编写JavaScript并实现 ICallbackEventHandler接口时，我会确保JavaScript对Callback给出正确的调用参数，并在接口方法的实现中接收这些参数然后触发正确的事件，就这么简单。和UpdatePanel一样，不要偏离了ICallbackEventHandler的设计思想，它的处理流程必须是合并到Page处理流程中的，你的控件也就必须这样设计。

至于在什么情况下选择 ICallbackEventHandler？如果你有一个轻量级的Ajax操作，但使用UpdatePanel更新整个区域的HTML开销很大的话，那么你可以考虑使用ICallbackEventHandler。当然，前提是你懂得控件开发和JavaScript。

IScriptControl

这是最复杂的解决方案了，你需要实现一个Control的两个副本——一个服务器端的，一个客户端的。有一部分逻辑，是要在客户端和服务器端重复实现两次的，而另外一部分逻辑，只需要在客户端或服务器端之中的一个实现一次。IScriptControl的经典例子，当然是ASP.NET AJAX自带的Timer控件。它的计时器是纯粹的客户端逻辑，然而Tick事件却在服务器端触发，Async PostBack成为了两者之间的桥梁。当然，就Control本身而言，它并不在乎PostBack是不是异步的，Tick事件只因PostBack而触发。

如果用IScriptControl来实现带分支的选择对话框，那将会和 ICallbackEventHandler的版本十分相似，唯一不同的地方就是它在客户端的逻辑会被封装为一个Sys.UI.Control的派生类，而ICallbackEventHandler的客户端逻辑往往是不封装的。这样的好处显而易见，那就是代码更容易维护了，并且客户端的Control可以同样可以加入事件支持，并提供和服务器端一样的代码分支事件。要知道在CTP阶段的Timer控件，其客户端版本Sys.Timer（而非RTM的 Sys.UI._Timer）是拥有tick事件的，和服务器端的Tick事件对应，只不过RTM取消了此项功能，因为ASP.NET AJAX 1.0的侧重点完全就是服务器端功能，客户端功能都被砍掉了。

什么情况下选用IScriptControl？如果你认为你的客户端逻辑应该封装为Sys.UI.Control的派生类，那就选择IScriptControl吧。

小结

我们分别讨论了三种通过Control实现Ajax调用的方案，并且一再强调了设计必须基于Page处理流程，不要在此流程之外增加不必要的复杂度和耦合度。值得一提的是，有很多人质疑为什么要在Web上提供这样一个支持分支的选择对话框功能，我的看法是这样的：既然客户端软件的流程会有此功能，那么 Web应用也有此功能就实在是太正常了，你删除blog post的时候问你一下是否确认删除，难道会有人觉得这个功能是设计错误？可能不同的只是表现形式而已，到底是confirm还是弹出层，甚至是一个专用的过渡页面。然而从用户体验的角度来说，这其实并不是最优的方案，多数时候用户删除就是确认删除，并不需要再问一次是否确认之类的愚蠢问题，但开发人员觉得用户错手删除的后果应当由用户自己承担，所以就做了这样一个对话框来推卸责任。真正好的用户体验是不需要确认的删除，但用户一定能够恢复，最好是按一下 Ctrl+Z就可以了，然而对于开发人员来说还是有很多操作是无法做到可恢复的，这时候除了显示对话框也没有更好的解决方案了。

最后，如果你喜欢我的文章，可以通过订阅feed来及时获得更新：

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

软件安装时到底是否应该让用户选择路径

周末和Google UX Team的Junyu聊天，说到Google现在统一使用Google Installer安装软件了，点一下Web上面的链接就自动开始下载安装并运行，开头我还以为是Microsoft的ClickOnce呢。由于安装过程是全自动的，就如同Microsoft的ClickOnce和Adobe的AIR一样，所以是不允许用户选择安装路径的。

到底不让用户选择安装目标好不好？我们认为用户分为三个层次：

1. 入门用户 - 购买的是品牌机，可能就一个C:和一个用于一键恢复的D:。这时候有什么好选择的呢？当然是不选择最好了。
2. 熟练用户 - 经受过文件难以搜索或者忘记及时备份误删文件的种种磨难，学会了分门别类存放文件，自己有计划地把硬盘分成C:, D:, E:, F:四个盘。这时候你不满足他分类存放文件的习惯，他就会觉得很不爽了。
3. 高级用户 - 经过无数次备份与重装后又在返璞归真，只用一个C:，安装时多数选项都直接next，不选择安装路径。

当然，这个分类主要是针对Windows用户，因为Windows的成长过程就是典型的“问题少年”——不停地向用户抛出各种问题，这个你选什么啊，那个你选什么啊。对于Linux和Mac用户来说，大家早已习惯了安装时一路next到底。Linux命令行安装甚至不用next，只是本地编译的话有时候需要yes一下。

事实上，我认为给用户那么多选择是没必要的，文件的搜索与备份应该通过其它手段来改进，而不是让用户手动归档。要求用户理解文件系统，就如同要求调用者理解API实现方式一样，其实是很不合理的。

对于现在的品牌机而言，只有一个C:，培养Windows用户好像Mac用户那样，什么都装到一个盘里面，这才是正确的发展道路。Mac有Spotlight，Windows Vista现在也有不错的磁盘索引与搜索系统，将来实现了WinFS或许能做得更好。

现在Windows缺的是一套好用的备份与迁移方案，问题来源于Windows软件都没有规范地把可执行代码与数据分离存放，所以没有一种统一的模式来备份软件数据。如果Windows上面的软件能够按照Vista的指引，把数据都存储到C:\ProgramData，那么接下来的事情就容易多了。况且我之前也说过了，这也是UAC的意义所在，有助于提高Windows的安全性。

以服务器端为中心的 ASP.NET AJAX 模式 (Part 1 - Behavior)

早在ASP.NET AJAX从CTP转向Beta再转向RTM时，看着客户端的Control被逐步放弃，与此同时ASP.NET AJAX Control Toolkit越来越多地使用Behavior，我就想深入说说ASP.NET AJAX的模式。不过由于我比较懒，所以这个话题只在《理想的 ASP.NET AJAX (Part 2 - Server Centric)》中一笔带过，没有深入讨论。今天看到volnet的《我们究竟是否有在“Asp.net中模仿Winform的MessageBox ”的必要？》，决定写一个文章系列来说说ASP.NET AJAX的模式。

什么是Behavior？

什么是Behavior？Behavior与Control有什么不同？这是首先需要回答的问题。

在Windows开发当中，Behavior的概念是不存在的，有的只是Control。ASP开发连Control都没有的，到了ASP.NET才引入了Control的概念。为什么Ajax开发要引入Behavior这样的概念呢？因为Behavior意味着不需要改变原有的组件逻辑，而改变原有组件的逻辑在客户端往往是不可行的，至少是难以实现的。

举个最简单的例子，一个<input type=”text” />就是一个浏览器内部的对象，你无法扩展这个对象的类型，也无法为它加上新的属性与方法，至少并非所有浏览器都允许你在JavaScript中这样做。然而如果你想要让它加上auto-complete（或曰suggest）的功能，这是可以做到的，并且很多人都做过了，例如ASP.NET AJAX Control Toolkit的AutoComplete，或者是script.aculo.us的autocompleter。这些实现都基于同一种方式，就是尝试基于input已有的接口在它之外添加新功能，而非尝试继承input并在它之内添加功能。

类似的做法在Ajax开发中普遍存在。例如说拖放吧，现在离HTML5拖放的全面普及不知道还有多远，所以大家都只能基于现有的鼠标事件来开发拖放功能。又或者说带有验证功能的输入框，无论是input还是select，无论是客户端验证还是服务器端验证，也都是基于现有HTML元素的事件来完成的。这一切都是Behavior。

什么情况下使用Behavior？

简单归纳，就两个条件：

1. 需要基于特定的一个组建进行扩展
2. 组建本身所处的环境缺乏可扩展性

单看第1个条件，我们有丰富的选择。很多人的第一反应就是继承自该组件，把扩展功能做到子类里面。熟悉设计模式的话，可能还会想到decorator pattern。然而在浏览器的环境当中，受到第2个条件的限制，继承或者decorator pattern都是不可行的。这时候，我们就需要使用Behavior了。

在一定程度上，我们可以把Behavior看作一种折衷了的decorator pattern。在decorator pattern中，decorator也继承自组件，因此当一个组件使用decorator pattern后，我们就把decorator放在原组件所处的位置上，而原组件就成了decorator的一个子节点（基于树的角度来看的话）。如果再加一个decorator，原decorator就会如同一个普通组件那样再被封装一次。在多个decorator的情况下，decorator之间是串联的关系。Behavior本身不是一个浏览器内部的组件，它无法继承自input的基类，因此Behavior也不能串联。Behavior本身本也不会取代input在树中的位置，这使得Behavior可以并联起来——一个input可以有多个Behavior，例如一个是自动完成，另外一个是输入验证。

总之，如果你原来的工作就是和UI打交道，并且熟练使用decorator pattern，那么在进行Ajax开发时把decorator pattern换成Behavior就可以了。

小结

回过头来看文章开头所说的MessageBox（或曰confirm）的问题，如果这个功能不需要对服务器端进行反馈，完全可以使用Behavior实现。ASP.NET AJAX Control Toolkit就有ConfirmButton这样一个东西，在客户端叫Behavior，在服务器端叫Extender，其实Extender就是对Behavior在服务器端做一下封装而已。当然，ConfirmButton不能完全实现MessageBox的功能，它只能在用户选择“取消”时取消整个提交操作，但不能够执行另外一个服务器端的代码分支。这算是Behavior的一个限制，就是它只能在客户端添加额外的功能，但是它不能影响到与服务器端的交互。但很多时候，正是这种限制确保了我们开发的组件是与服务器端解耦的。

如果我真的需要一个与服务器端交互的客户端组件，例如支持调用服务器端代码分支的confirm，怎么办？这时候你就真的需要一个与服务器端Control对应的客户端Control了。请关注本系列的下一篇文章，《以服务器端为中心的 ASP.NET AJAX 模式 (Part 2 – Control)》。通过订阅feed，你可以及时获得文章更新：

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

P.S.既然提到了Behavior和Extender的一一对应关系，就不得不说一下，服务器端的Extender就是真正的decorator pattern。

远离国内的 SNS

最近我一直在想是否要把海内的帐号终止掉，原因只有一个——我很久不上海内了。既然我不用它，我就没必要把我的个人信息放在上面，让更多不认识的人有机会获取到这些信息。

如果要详细解释这件事，就要从很久很久以前说起，就是海内刚刚开放注册的时候。在改为邀请注册之前，海内曾经开放注册过几天，让及时获得消息的geek们第一时间获得了帐号，那时候我还没有多少好友在上面，已有的好友没有多少活动，news feed自然不值得一看。

后来，海内上的好友逐渐多起来了，大家也更活跃了，这是我认为海内最好的一段时候了。虽然，这时候的news feed算法也不怎么样，例如不会把同类项合并了，也不会对信息按照重要程度进行过滤。我之前也说过，Facebook的真正价值就在于它的news feed，news feed的算法不行也就以为着海内能为用户带来的价值优先。

随后，海内开始把重心转移到游戏开发上来。买卖好友可以说是为了刺激用户数量的扩张，但越来越多的游戏上线让我觉得整个海内都变得以娱乐白领为首要目标了。我的个人观点是跟Bean和Awflasher差不多，虽然中国人口众多必然导致劳动力过剩，但让每个人都把自己过剩的劳动时间投入到游戏当中并不是好事情。当海内的news feed充斥着各类游戏相关的信息时，我就不再去看海内了。

说完了海内，国内的其他SNS我想也没必要一一列举了。海内曾经是国内最用心用力想称为白领SNS的一个了，国内其他成功SNS的目标从一开始就定为娱乐性SNS，短期内不可能得到比海内更有价值的结果。在这里我所说的价值不是指SNS本身的商业价值，而是指推动国内SNS用户素质提升的价值，是指创造SNS之外的商业价值的可能性。

China MVP Open Day 2008

一年又过去了，去年的MVP Open Day在三亚，今年改成了在北京，我甚至连飞机也不用搭了，只需要打的参加（也要¥99）。

我是17号晚上和飞飞一起从中关村打的去汤山的。Bean则是当晚深夜飞过来，很可惜Bean不知道联合航空到北京的飞机是停南苑机场的，结果从南苑机场打的到汤山还费了他不少时间和金钱。Dflying早些时候就飞来北京了，不过不知道去哪里玩了，竟然18号晚上不到酒店让我一人独占房间。18号晚上去到后，人都散了，只是见到了Sisley、Eddie等人在筹备第二天的晚会，当然还有排舞的老葛等人。

由于晚上看Wanted看到凌晨两点，18号一起来就赶去吃早餐，接着就见到了Mango和Bean。由于我第一天晚上没有签到，吃完就马上赶去签到领衣服——没办法，早上的keynote规定大家要穿统一的衣服。keynote上讲了很多东西，还颁了奖——就是MVP每年一块的水晶座，今年是奥运年所以是火炬造型的水晶座——不过整个早上最让大家兴奋的应该就是那台Surface了。据说中国只有一台Surface，放在MSRA，估计就是那一台了，现在拿来向我们展示WPF如何开发Surface应用程序，keynote之间我们就都冲上台玩这台Surface顺便拍照。

中午的午餐组织得有点混乱，实际上整个MVP Open Day都组织得比较混乱，不知道是不是因为会务外包了给CSDN。据说因为会务很赚钱所以CSDN现在热衷于做这个，不过确实不太专业。

接着就是下午的一对breakout session了，不过没有哪个我特别感兴趣的——完全没有ASP.NET或者Silverlight的session嘛……我和Bean在户外找了个地方坐下来上上网聊聊天，后来俞晖也加入进来了，包包跑过来和我们照相，Dflying说公司有事要立即赶回上海（他还真没在酒店住过一晚）……整个下午我就没有专心听过一个session，都是周围跑去见别的MVP。

午餐按照技术特长来分组，晚餐就是按照地区来分组，俞晖和紫柔跑来我们广东桌装广东人，俞晖还是忘记不了说他喜欢吃螃蟹并且对于没有螃蟹感到可惜。我则一再要求紫柔把我从Web版主调回ASP.NET版主，因为当初无拉拉被分到Web版主实在让人郁闷，大部分IIS、IE之类的问题我都无法回答上来，也不确认其他人的回答是否正确。

晚餐之后就是晚会了，一个半小时其实不算长，不过留下更多时间给MVP交流也是对的，随后就是博客园的MVP聚会。在博客园上的大部分MVP都来了，没来的据包包统计大多都是上海的，例如Jeffery Zhao——我很好奇他所谓的减肥成功到底是什么效果，可写他就是不出现。博客园的聚会，就是大家各自自我介绍，然后分组讨论，晚上黎波来了——他虽然没有MVP连任成功，不过刚好也在北京为Microsoft的客户部署项目——我就和他聊了一下Sharepoint。回到房间之后，我叫了Bean过来聊天，不过没聊到什么他就回去睡觉了。

19号早上是拓展训练，就是盲人方阵和毕业墙两个项目，我们组做得还不错。中午吃饭后就是期待依旧的参观鸟巢了——其实我一直不认为鸟巢如何如何特别，不过倒还是个很值得拍照的地方。一群MVP搭大巴来到鸟巢，被告知水立方和玲珑塔都不对外开放了，于是只能进入鸟巢参观。整个广场确实很大，不过设计确实不怎么样，很多地方都很不人性化——鸟巢很多长长的楼梯，出去少数电梯后竟然没有扶梯，这叫来自发达国家习惯走到哪都是扶梯的人怎么适应呢？整个广场那么大，座位放了很多但就是不见洗手间，垃圾分类就不要期望了因为连垃圾桶都是那种很丑陋带轮子的。简单来说，看看鸟巢就知道典型的北京本地价值观了——很追求体积上的庞大，或者说是“排场”，但是不注重细节，也不懂得什么叫人性化。

参观完鸟巢后，拍了几张集体照就解散了，去机场的、去火车站的、直接回家的……基本上都涌进了地铁站，然后各自超自己的方向走。

有空要做个 Theme Software Corp 的游戏

当年Theme Hospital的搞怪实在让人怀念。各种奇特而富有创意的病症，与之配合的神奇治疗方法，还有行为略显怪异的医生和护士，组合起来是那么的有趣。现在在IT公司中的生活，感觉也很有趣，虽然有些事情也挺烦人，不过却是不错的谈资。

将来如果有时间做游戏，就做一款Theme Software Corp。市场是有各种奇怪的需求，然后要请PM来做研究并得出产品开发计划，再要请SDE来开发，之后还要请SDET来提高质量。为了保证这群人的满意度，和招聘到更加高级别的人员，必须购买各种设备来满足他们奇怪的生活需求，从咖啡机到按摩椅，还有Wii、XBox360或者PS3，甚至自己建移动大厦加一个游泳池。结果发现这些人每天来到就去拿咖啡或者可乐，然后开始看看feed，最后工作一会儿又闪出吃饭了。你想尽办法利用他们的才能，但是innovation的发挥却是很不稳定的，项目不停delay士气下降，你又要投资点什么来补救。

总之，这个游戏应该继承Theme Hospital的一些关键特性，游戏中的各种事件都是很无厘头的，同时你又要努力balance游戏中不同的指标——正如Dreaming in Code中说到的质量三角，时间、金钱、特性三者不可能都得到，在追求其中一个的时候必然削弱另外的两个。这样在有相当游戏难度的同时，又有娱乐性可言。

最糟糕的一次飞行经历

星期天晚上从广州飞北京，登机和下机的安排都极差！

在广州白云机场的B区登机，又是一层登机口，意味着肯定是搭摆渡车的。开头以为好像上次那样，飞机是国际航班转飞国内，所以停在A区空地了，结果还真是这样，而且还不是停在A区空地——是泊在A区登机桥边了！那天广州暴雨，如果飞机停在空地，登机专用车是有遮顶的，这样登机还不至于淋湿。但飞机泊在登机桥边了，就要从地面爬上登机桥（我终于知道登机桥边的楼梯有什么用了），楼梯是没有遮顶的，所有人都是淋雨之后才走进飞机的。

到了北京首都机场后，被告知地面在调整停机位，要重新分配机位后才能下机，然后飞机就停在了机场空地上足足等了30分钟！不知道乘客与空姐吵起来是否有推进作用，最后停机位并没有怎么“分配”法，飞机就在原地把我们放下，然后让摆渡车接我们走。浪费那么多时间才出摆渡车，一早这样做不就好咯，机场的调度真是差。

什么时候才能在网上收到广州和香港的节目呢

Sean O'Driscoll的一条tweet，说能够在网上听到Seattle的电台感觉离家里近了，让我再次想起如何能够在北京接受粤语节目的问题。

在北京最郁闷的事情，暂时来说，就是无法接收到任何广州或者是香港的节目，无论是电视还是广播。试用过很多P2P的网络电视平台，暂时来说最满意的就是TVU收看凤凰卫视了，至于TVB——虽然有人转发到网络上，但是peers太少，从来没有成功看到过，就是见到list上面有TVB的名字。

关于接收TVB，Catfish总是建议我接收卫星信号，因为他以前在北大就是负责把信号送上卫星的。但是这个方案对我来说也太不现实了——我连电视机都没有呢！我从来只有电脑，电视对我来说是多余的，所以在北京租的房子自然不会买电视。

除此之外，还有别的办法吗？我不停地问身边的人这个问题，但一直没有找到有效的解决方案。

Vista 为什么要引入 UAC

UAC的目标就是：干扰用户！这其实不是我独创的，而是从TWiT上听到的一种见解。

UNIX的命令行有sudo，Mac在GUI上也能够在需要sudo调用时弹出对话框要求输入密码，然而这两者的出现频率比Vista的UAC要低得多。为什么UAC的出现频率那么高呢，难道是Vista的用户体验设计得有问题？显然不是这样，Vista的UAC就是设计来不停地干扰用户的。

干扰用户随之而来的是什么？就是用户觉得这个软件很烦，然后逐步放弃使用这个软件，转而使用同类软件中不那么烦人的。这个过程会逐步把经常进行UAC调用的软件从是场中淘汰掉，如果你的软件不希望被市场淘汰，你就必须尽量减少UAC调用，也就是减少系统调用。

最终，市面上大量滥用系统调用的软件会逐步消失，要么自身改进，要么自然淘汰，从而提高了Windows的安全性。等一下，这跟Windows的安全性有什么关系？假若你的代码要执行系统调用，同时你的代码是有漏洞的，就可能由于你的程序漏洞而导致系统受到攻击。但如果你的软件本来就不需要做任何系统调用，就算有漏洞也不会连累Windows，Windows也就显得安全多了。

P.S.当然，还有一些非系统调用也需要UAC，例如对C:\Program Files的写入操作。这是因为Vista认为这也是个危险操作，而程序应该将数据存放到C:\ProgramData来实现可执行代码与数据的分离。

强烈推荐 Spore 这个游戏

由Spore发布到现在，一直在玩这个游戏，觉得挺有趣的。虽然有人说创意没利用好，操作具有重复性，不过这个游戏享受的正式创造的乐趣，而非好像RPG或者RTS那样，要通过竞技赢取什么。如果你以竞技的心态去玩，那么这个游戏就很无聊了，因为你赢了一次之后，就发现再玩也是走类似的路线，不值得重玩。但是如果你享受创造不同的生物，利用他们不同的特性来进行游戏，那就很好玩。

Spore有趣的地方在于，你在里面总能够碰到各种各样奇怪的事情。在cell stage，你会发现合理组合装备的重要性，刚刚开始有针刺的时候就可以把针刺装在前侧，然后刺体积比你大多了的生物。如果你发现不够灵敏，总是没把对方刺死就被吃掉了，那么你可以加高性能的运动器官，但前提是你又要先杀死一只有该器官的生物来获取它。到了creature stage，你可以看到举行的epic creature，这其实是其它space stage文明通过supersize工具制造的。在tribal stage，你可能会看到UFO──也就是其它文明在space stage的飞船，他们可能把地上的生物吸走。总之，在整个游戏过程中，你都会感觉到银河系中充满了各式各样的文明，在你还没觉醒的时候他们就来造访你所在的行星了，而且还会制造各种奇怪的事件，例如麦田怪圈。

暂时Spore只有英文版和繁体中文版，不知道什么时候才在内地上市，或许我会去买一套简体中文版，把它的cd-key用到英文版上，然后连上EA的服务器玩。Spore是我认为挺值得收藏的一个游戏。

第一次开 OT 开到 1:30AM

终于体会到软件工程嘅焦油坑，唔单止需求唔明确成日变，而且相关人员太多──我啲嘅项目相当于通用型项目，同各个已有嘅产品线都有合作，项目嘅任何改动都要通知各个有关产品线嘅PM，等佢哋嚟确认新嘅行为係合理嘅，同时又要各个产品线个QA嚟重新测试，确保哩啲改动唔会影响到原有嘅协同功能。

如果浏览器 geek 到能够随意换 kernel

Google Chrome是开源的，所以只要你有兴趣你都可以去Google Chrome的SVN把源代码check out下来看看，然后你会发现它用到了大量第三方的开源组件。

在过去，浏览器总让人觉得是一个monolith般的东西，一个大整体，内部耦合度高，很难在一个浏览器中复用另外一个浏览器的组件。准确来说，浏览器按照内核分成了几族，族内的组件倒是通用的，但族外的就不通用了。但是在看到Google Chrome如此组装开源组件后，才发现其实浏览器也有可能发展到能够跨族相互融合的程度。例如Google Chrome是基于Webkit的，然而JavaScript引擎换了V8，所以执行效率比Safari高多了，而渲染引擎换了Skia，因此暂时看起来没Safari那么精致，支持的CSS3也没有Safari那么全面。

将来的浏览器，或许会像Linux一样按照distro（distribution）来划分。安装插件已经不能满足geek的需求，所以选用什么组件变得可以自定义。浏览器与浏览器之间的组件复用壁垒不会好像现在那么高，programmer已经可以轻易地从一个浏览器借用代码复用到另一个浏览器上，然后制作自己的distro。

Firefox Ubiquity

对于喜欢命令行（command-line）或者喜欢Mac上的QuickSilver的人来说，Ubiquity实在是太好用了。如果你的Firefox还没装上Ubiquity，那就快掉去装一个吧，虽然现在的只是0.1.1 alpha。

装完之后，可以体验一下Ubiquity内置的command，地图搜索或者翻译之类的其实还是挺好用的，但我觉得重点还是在于可以自己写新的command。官方的Author Tutorial简单介绍了一些开发command的基础知识，如果要深入学习的话就要看看别人的command是怎么写的，以及看看Ubiquity的源代码。

由于我觉得Ubiquity实在太符合QuickSilver的用户习惯了，所以我以后做Web应用程序都会考虑加上Ubiquity的支持。