Michael Chen’s Blog

花了大约整整两周的时间，在地铁上，电梯里，等车的，上厕所的光阴里，读完了凤歌的新作《沧海》。洋洋六册，数百万字，我居然在两周的空隙时间里读完。比起《昆仑》，我觉得《沧海》场面虽大，但表述的内容却不见得精细。掉的书袋太多，解释的太详细，读起来却没有《昆仑》的酣畅淋漓。

然而，毕竟写成了。21个月笔耕不辍的光阴，两年间不停留的写作，这个庞大的世界，这个完整的世界观，那些有血有肉的角色，已然形成了。凤歌花了3年写《昆仑》，2年写《沧海》。就在大多数碌碌的时候，惊雷无声响起，端的是又一片天。

昨晚看到章子怡的访谈。我惊奇的发现，自己以前完全不入眼的花瓶演员──《尖峰时刻》里面那个只有一个镜头的，《蜀山传》中完全看不出特点的──已经悄然长大，成熟，知性，举手投足，自信，光彩照人，令人不能直视；以至于在出现在我昨夜的梦中：我们在一家西餐厅吃饭，她谈笑自如，而我却惴惴不敢前去，直至天明梦醒。写作时，我随意到她的官网上去看，原来，这些年来，她的努力和进步，从未停止过。无声处，庸人依然是庸人，惊雷于无声处，响起。

天之道，损有余而补不足。

这句话最早出现在《射雕英雄传》的“九阴真经”中老子的《道德经》中；然后不断出现在《射雕英雄传》、《昆仑》和《沧海》中，乃至成为很多内功心法的理论基石。莫非大多数庸庸碌碌的人，精力和时间太有余，补给了那些需要的人们，使他们成为不敢直视、掩耳叹息的惊雷？！

11/4 UPDATE: 那句话最早是老子《道德经》里面的，多谢zzzhc。

前天上地铁，跟同事突然说起弹吉他的事情，不知怎么说到谈得不好的人就跟弹棉花一样。我却不大乐意，反问一句：你见过弹棉花没？他摇头。我就跟他解释如何弹棉花，解释弹棉花的韵律和美感。他依然一头雾水，却最终同意弹棉花也并非意味着毫无技术含量。

今天突然想到，随意上网搜了一下，发现了这个：

不得不说，这个人弹的真的不怎么样，没什么节奏不说，院子里面棉絮满天飞。记得小时候，在一个比被子稍大的房间，任何一个弹花匠都可以踩着四四拍，三下闷音一下长音或者两短一长一短，几小时内弹出一床厚厚的棉被来。

有一句流行的黑话，形容友谊：一起同过窗，一起扛过枪，（还有两句不太和谐，想知道的人自然有办法知道）

稍微花点时间回顾一下，作为具备一般性收入从事一般工作过着一般生活的普通人，与朋友、同事在一起的除工作外的生活是什么？KTV或者其他类似的娱乐项目？健身？吃饭？再回忆一下，你与同事朋友们之间的这些社交活动，你还记得多少？

我的回答是，那些活动在大脑里只能存在一个模糊的轮廓，具体的记忆几乎没有。我更记得的是与他们一起工作的日子。

作为我一贯的写作风格，还是说一段小故事。

去年7月开始的时候，由于种种原因，我重新开始玩魔兽世界。在三区找了一个人最少的服务器，开始了一个联盟的圣骑士。圣骑士在20级的时候有一个史诗级别的职业任务，这个职业任务有一步需要到影牙城堡去找点东西。当时我与一个20级不怎么会玩的战士，20级的新手法师从铁炉堡出发，一路穿过丹莫罗，萨尔多大桥，湿地，阿拉希高地，南海镇。稍微了解这个游戏地形的人应该知道有多远……他们俩人（战士是女生）陪着我从一开始就跑过去，一路上见到了湿地的阴晦，阿拉希瀑布的壮观，一边体会着游戏的景色，一边聊天。最后到达了影牙城堡。影牙城堡是适合18~23级的5人副本，里面的怪都是精英级别——血量以及各项攻击、防御属性比它同级的怪要高的多。我们三人死了很多次，每次都停下来商量怎么打，不知道多长时间后终于拿到了任务物品。

游戏中我不知道他们怎么想的，现实中我们从未谋面，后来战士在43级的时候AFK(注：离开)，在以后的三个月里从未上过线；法师也AFK很久。但我对这个过程却一直铭记于心：有一段不是很容易的经历我们曾经一起度过，我们每个人都为此付出努力。虽然不是在现实——但游戏中的体验谁又能说不是一种现实呢。

类似的体验不可多得。后来我还有其他的帮忙，满级的角色来帮我完成，他们毫无难度的完成了任务，我也没有那种一起完成事情的激动；帮其他的低级别小号做任务，自己没有什么成就感，更不谈记得那些我帮助过的人了。

回到工作中吧。IT从业者是脑力劳动者。我们无法知道，一个人在看起来冥思苦想的时候，他究竟是不是真的如此。然而我们可以知道（或者明显感觉到）的是，花一段时间共事，这个人到底有没有如他看起来那样努力工作。每天上班，第一件事情是开浏览器看新浪，还是看前天的构建结果？是在构建的间隔扫一眼娱乐头条，还是与你身旁的同事讨论有没有更好的解决方案？一个人工作的时候，是做着与工作相关还是不相关的事情？这些问题涉及到拷问一个人的专业精神，然而我却觉得，他更影响到团队成员之间的友谊。成员之间交流的时候，更多的是看双方共同的体验。一个人在工作的时候他的同事在做别的事情，他们之间在同一件事情上不会产生共鸣。如果一段时间都两个人都不在一个共同的场景中，那么这段时间他们不会产生共鸣。如果这样的次数多了，勤奋工作的一方很快对不怎么勤奋的一方不信任。而信任，才是友谊的根本。

再来一个很简单的问题：在过去的从业经验中，你对你的同事的回忆，集中在哪些方面呢？技术上的争执，一起加班，……

毫无难度的共事会让记忆匮乏，毫无冲突的共同经历会让经历平淡。友谊是建立在一起处理那些高难度的工作上。所以，善待与同事一起的时间吧，若干年后，你们还有记忆一起分享。

不像gigix, 动不动来个许愿，我翻看了一下从2004年到现在的blog, 几乎没有任何关于许愿的帖子。这不是意味着自己没有计划，相反，而是将计划看得太重要，重要到以至于在新年到来的时候做回顾，都不曾记起曾经计划过什么。

2007年碌碌却无大作为。buffalo成功发布新版本，我却莫名奇妙的在后续的日子里做WPF富客户端应用开发到年底，看起来要做到明年；因为不想某人而开始玩魔兽世界，却有了做企业应用完全没有的新的技术体验。去软件开发2.0大会做关于混合语言开发的演讲，或多或少找到了技术传道者的感觉。

然而有太多的东西盘旋在脑海挥之不去：做一些用户群更广泛的东西是我一直的想法，然而这些想法在没有被天才般的同事打败之前，就被自己缺乏行动力的想法打败。太熟悉，太聪明并非都是好事。至少从外观看来，我除了工作本身，没有多少值得提及的东西。

另外郁闷的是，活动的圈子小了，转来转去，看来看去，都是熟悉的人名，熟悉的字眼。

2008对我而言，将是破冰的一年。让想法盘旋而去的最好做法是让它实现。无论是技术的或是非技术的，这里列举余下：

- 一个成熟到至少100人在线的应用 [0/1]
- 参加一次义工活动(组队) [0/1]
- 写一本非技术的书 [0/1]
- 每周至少一篇Blog [0/51]

世事真无常。05年这个时候我计划着离开北京，两年后的今天又回到了这里。刚到就赶上2007年第一场大雪，然后我就狠狠的再次领略了北京的交通：出站花了一小时等到出租，出租车司机说别去东直门了，送你到军博地铁吧。看着军博地铁两分种一辆呼啸而过，拖着巨大行李的我实在没有勇气挤进去。等了好一会儿，横下心反方向坐到八宝山……到公司时，已经是三小时后了。

这次大会的规模远远超出了我的想象。两天，4个分会场，40+个session, 1000+开发者。准备了一个多星期（实际上从1一个多月钱就开始构思）的幻灯片，现场效果自我感觉还不错。然而作为第二天最后一场，会场只有一半人左右参加，多少觉得有点失望。

见到了老朋友Peter Cheng, Ben Wang，还有若干平时常见到名字的人。总体来说，这次大会感觉非常棒！

这次演讲的幻灯片下载：

混合语言开发

关于可用性设计，说到底是对用户操作心理期待的把握。如果操作反馈低于用户期待，感觉会很差；如果正好符合期待，用户感觉会很平滑；如果超出用户期待，做得比用户想象的更多，大多数用户都会惊喜并很快接受新的方式。

界面的表现形式占据了很大分量。在过去C/S年代，几乎没有非结构化内容。界面约等于数据库表，无论是外观或是功能。而随着Web2的介入，越来越多的应用引入了非结构化形式来表现结构化内容，以达到更好整合信息的目的。关于非结构化形式，有一些非常明显的特征：

* 使用用户用户的语言而不是计算机语言作为界面。非常典型的如使用“昨天”、“前天”取代2007-7-29等计算机友好时间。
* 使用松散布局而非紧凑布局。几乎绝大部分成功的Web2应用都拥有独一无二过目难忘的布局和色调
* 几乎不使用Grid控件。作为C/S年代代表的Grid, 几乎每个写代码的人都会用到。然而在成功的消费类应用的中，几乎没有人使用Grid, 如果需要使用，也是美化过后，或者采用能够表现对应单元格属性的表现方式。例如一条 张三 男 记录很可能被表现为张三的小图标以及象征性别特征的图片。
* 尝试将更多的信息而不是更少的信息放在首页。对于常规应用的开发者而言，这几乎是噩梦。因为这意味着信息整合。Portal就是这类问题的解决方案。然而看看Campfire的basecamp, 通过将常用的信息摘要放在首页，用户几乎不用进行额外的点击。

然而，非结构化形式并非意味着凌乱。凌乱的排版和信息堆砌给用户一种暗示：我可以在这里为所欲为。破窗户理论在这里同样有效。这可以解释为什么绝大多数看着很乱的聊天室内容也很乱。真正有意义的非结构化信息及其组织方式完全来自于真实用户的真实体验。

得出的结论是，结构化的表现形式造出的软件像工具，因为大多数人对工具的理解就是灰色、规整、耐用，同时乏味。非结构化表现形式造出的软件像精致的消费品，美观舒心。值得一提的是，Dell公司已经开始在沃尔玛摆起了柜台卖电脑。笔记本这个曾经商务人士标榜的东西，已经成为消费品。我们现在正在为客户开发的项目中，已经加入了很多消费类程序才有的UI特性。从长远看，消费品将是不可避免的终极目标，因为用户不是机器。

AJAX毫无疑问，增强了单个用户的体验。然而，对于如何能够增强“参与感”的技术，能够见到的论著寥寥无几。例如，聊天室，如何能有效、低延迟、高伸缩性的进行多人聊天？我们能够想到的方式有如下几种：

* HTTP pull. 通常的实现方式是隐藏帧刷新，或者XMLHTTP访问。每隔一段时间（2秒或者更多）对服务器进行访问从而获得更新信息。
* HTTP Push. 现在有了一个更流行的名词：Comet。基本实现原理是通过服务端向客户端回复一个永远不会断开的连接。通过不断输出可以直接执行的javascript代码，或者一块可以被应用程序解析的字符串，达到相互通信的目的。

第一种方法的缺陷一目了然：效率低，延迟高。由于并非每一次请求都会有返回的数据，当次请求的返回值则毫无意义。而这其中建立HTTP 连接的时间，服务器处理的时间，客户端消耗时间等，让这些请求毫无价值。没有数据的请求让服务器疲于应付无效请求，浪费了计算资源。另外，由于没有一个合理的请求频率策略，导致应当及时返回的消息在最坏的情况下于延迟时间返回。例如，用户在00:01发送了一条消息，系统每隔2秒扫描一次，在00:03秒，另外一个用户才得到这个消息。当然在聊天应用没有关系，但是实时性要求更高的场景下这些往往不一定可以接受。

第二种方法解决了实时连接的问题，然而这要求更高超的服务器端编程技巧。现在看到的WEB服务器都并非为长连接而设计，你可以看到将这种方案部署到常见的Web应用服务器上的时候性能下降得多么厉害。更为现代的Web服务器，如twisted, 基于MINA的asyncWEB采用了event driven IO以及线程重用等技术，在这方面表现很好。然而，这种长连接最大的问题是，无状态架构不能很好的被应用，从而影响了系统的伸缩性。

目前更好的一种方案是：BOSH。这种原本为了jabber设计的规范，在应付这种需求的时候显得格外合适。它的基本原理不是常见的采用1条HTTP通道，而是不多不少的两条。策略如下：

* 系统启动后，客户端向服务器端发送请求（通道1）
* 如果有消息，服务器直接向客户端返回消息。客户端收到消息后，除了完成业务处理外，还立即向服务器发送一条新的请求。
* 如果没有消息，服务器保持通道1的请求。如果这个时候客户发来另外一个请求（通道2），服务器立即向通道1返回空响应，并保持通道2的请求。
* 如果很长一段时间没有任何消息（例如，30秒），服务端返回空给持有的通道。这个消息立即会触发客户端的一个新的请求。
* 如果很长时间没有接到用户的请求（30秒，例如），服务器断开客户端相关的session信息并清理相关资源。

我们看看有没有解决上述的问题：
* 效率：可以看到，只有当有数据的时候才会真正的完成请求（完成传输），无效的传输大大减少。通过规划合理的心跳检查时间，可以最大化传输的有效性。
* 延迟：由于在任意时候都有一条HTTP通道保持连接，因此可以想象延迟降到了最低。
* 伸缩性：由于采用两条通道轮换处理，常见的无状态架构可以被应用，不会影响伸缩性。

可以看到，通过增加一条HTTP通道进行轮换处理，提升了传输效率，降低了延迟同时不牺牲系统的可伸缩性，值得尝试。

我一直以为自己已经不需要看任何与AJAX相关的书籍了──无论是我过去的工作（XMLHttp based BI client, LiveChat…），还是我现在在这方面所做的工作(amowa, buffalo, OPOA)，都或多或少不能让我看清楚这个领域更多更新的东西。然而大概读完《AJAX模式与最佳实践》后，我才了解到，自己那些对AJAX这个buzz word的零散理解居然可以被系统整理到这样清晰、易懂并且可实践。

任何实践都只能是一个系统化理论的切片。虽然AJAX赖以生存的关键技术XMLHTTP早已实现，但自从Google推出Gmail之后，相关的讨论才如雨后春笋纷纷出土。各种语言、各种平台、各种所谓的最佳实践、对这种技术的种种好处、罪过的讨论，瞬间涵盖了去年至今的大部分技术话题。这种出现既有历史的原因──IT系统已经不仅仅满足到“能工作”这个阶段，还上升到了“可用”、“易用”了；还有技术成熟度的原因──悄然之间Xmlhttp已经在主流浏览器全部实现了。由于优秀的部署模型，越来越多的企业采用Web技术来实现他们的业务系统。AJAX成为改善用户体验的关键技术。然而，正如前面所说，太多的实现、讨论，让开发人员在进行选型与技术实现的时候思考再三。特别是刚开始进行技术转型的开发人员，在众多的迷惑面前，往往不知道怎么做才是正道。

《AJAX模式与最佳实践》解除了所有的迷雾。通过模式的阐述方式，这本书将每一种模式意图、动机、适用性、架构、实现以及注意事项表现在你面前。读这本书的时候，我发现自己之前所做的思考和工作，居然都在这9种模式中，而且有了贴切的名字。模式中的阐述，已经远远超过了零星的思考，更加全面，更具指导力。作者Christian Gross深厚的技术背景，将这些看似繁杂的技术分解，总结出适用于绝大多数人场景的9种模式。同时应该感谢李锟及其团队的努力。在翻译这本书的过程中，我听到了李锟的诉苦。谢天谢地，他坚持下来了。

从没有想法到有想法：1步。

从想法到开始行动：1公里。

从行动到完成：100公里。

从完成到成功：100光年。