巴别塔上的雇工

这周一获得一次关于Communication Skill的培训的机会，难得是这个培训是One on One的，一对一单挑，所以也不是教员宣讲学生做笔记，而是相当交互性的。

这个培训几乎完全摧毁了我的自信心 按照导师的说法，我的发音(Articulation)很成问题，吐词该停顿的不停顿，全绞在一起他不能相信我的英语能够被我的美国同事听懂！额滴神呐，我还一直以为我的英语还算中上等呢。以我的经验，教Communication的老师会认为报名的同志都是觉得自己有交流障碍的同志，所以都把受训者当小宝宝教育。不过这个老师指出的我的缺点也很中肯，比如我说话太快，这是我的老毛病了，以后一定要改正，实际上这周我都在训练自己把语速放慢。

就我的问题，导师还指出，让我不要害怕开会，不要害怕争吵。其实，我自认为不是不会开会和争吵，而是觉得实在太浪费时间，能不去就不去吧，不过如同导师所说，这个项目再继续一年，会议还是要开，争吵还是要继续，为什么不参与进去把争吵的事情解决了呢，TMD，总得有人去把事情解决了，好吧，那就让我们在会上来把事情解决吧。

昨天下班后去楼下的健身房，也许是因为过年期间有日子没有运动了，所以运动的比较卖力，而且这个健身房我第一次来，发现力量训练的器械还比较齐全，更是斗志昂扬。45分钟后觉得有点体力不支，想今天就到这里吧，回到更衣室，发现自己连换衣服的力气也没有了，感觉很难受，想睡过去，在板凳上坐下，闭上眼睛休息，在半睡半醒之间忍受痛苦，不会这就是我的命运吧 好半天才缓过劲来，收拾收拾回家了。

以后训练还是要控制好节奏，尤其对于新环境，一定要悠着点。

就我所知，影史上有两部只有一个镜头的电影，一个是希区柯克的《夺魂索》(Rope)，还有一个是《俄罗斯方舟》(Russian Ark)。

《Rope》严格说来不是一个镜头拍下来的，虽然给观众的感觉是一个镜头。当年希区柯克在四十年代收技术条件制约，一个镜头最多就能拍十多分钟，因为一盒胶片只够撑十几分钟的，所以希区柯克玩了些花招，在剧种安排了几次镜头的移动让镜头中只出现静物或者只是演员的后背，然后就在这个时候换了胶带继续拍，衔接得天衣无缝，如果不知道这个trick可能真地发现不了。

《俄罗斯方舟》就是完全的一个镜头拍下来的电影，可惜我对俄罗斯历史不大了解，所以坦白地说，没怎么看懂。整个电影就是镜头的第一视角如梦游般穿梭在俄罗斯宫殿之中，穿越不同俄罗斯历史不同年代，据说该片有800多名参演演员，只有拍摄4次的资金，结果在第四次终于成功了。

Jeff Prosised对Sliverlight的支持非常狂热：“The future is not HTML, not Javascipt, not AJAX. The future is Sliverlight.”这一天培训下来，我的感觉是，Sliverlight将来的确会有巨大的影响，不过目前版本的感觉就是——非常凑合

The future is Silverlight，首先RIA(Rich Internet Application)是整个行业的趋势，这块肉大家都是虎视眈眈；其次Silverlight和.net战略结合得不错，Silverlight程序(2.0之后)用不着改code就可以转成WPF程序，而且Silverlight有跨平台的特点，不要求客户端必须是Windows + IE。微软无疑会继续投入资源在Silverlight上，即使RIA之战不能完胜，至少也不会输。

另一方面，目前的Sliverlight给人感觉太糙了，1.0版简直就只能用来做Toy Application，三月份的MIX08会议上应该会正式发布2.0版，目前的2.0 Preview感觉比1.0进了一大步，可以用C#而不是像1.0一样只能用javascript，但是一些功能现在还没确定最后会是什么样子，拭目以待MIX08吧。

今天Steve Ballmer等一干大佬们宣布了一些开放性的战略，这是件好事，不管对Microsoft还是对整个Industry。不过让我们面对现实，资本运作的目的是赚钱，不是搞慈善，这样的动作也是为了加强Microsoft对业界的影响力，别指望Microsoft接着把Windows内核之类的代码也公开了，嘿，别还纠缠什么源代码了，标准才是最重要的。有一个“小细节”，下个月就要决定Microsoft提出的OOXML(Open Office XML)标准的命运，是否能够成为ISO标准在此一举（据说我国政府上次投了反对票)，这个时候进一步Open Up，我想目的很明显吧

我刚入行的时候听说过一段话：三流公司卖劳力，二流公司卖技术，一流公司卖标准。

        上次参加Jeff Prosise的ASP.NET AJAX培训，觉得很Boring，也没学到什么，今天重新上了一天这个课程，收获不小。老实话，虽然Client端部分的Javascript Library的确可以不依赖ASP.NET Server存在，但是如果不懂ASP.NET，要弄懂ASP.NET AJAX就很费劲，而且，开发应用常用的ASP.NET AJAX Toolkit又是依赖ASP.NET的，所以也不要自欺欺人了，这玩艺就是依附于ASP.NET的，你可以让MS AJAX Library和PHP Server合作，但是谁会这么折腾呢？PHP或者任何一个其他Web Programming社区又不是没有自己的AJAX Framework。网上有人介绍如何在PHP中使用Microsoft AJAX Library，但是我想没人会真的用PHP+MS Ajax开发产品。

        微软部分贡献了AJAX的产生，XmlHttpRequest是微软在IE 5中最早引入的，当然最后把AJAX玩得神乎其技的还是Google。这两天听Jeff讲Microsoft内部的一些轶事，让我更相信，AJAX并不是Microsoft的主攻方向，Silverlight和WPF/WCF等技术才是。当然，Microsoft的风格就是内部不同技术不同团队之间还存在竞争，AJAX is not dead，还会继续有人力物力投入在上面，但是在web programming方面，如同Jeff所说，Silverlight才是最有希望的。

        明天接着培训Silverlight，连续听了三个整天的英语，现在感觉耳朵根有点疼:)

今天ASP.NET Advanced的培训终于结束了，两天之内被灌输了这么多东西，真是够累的。Jeff说如果我们只能从培训中学到一样东西的话，那么他希望是ASP.NET的Asynchronous Programming Model，专家这么说，可见其重要性，但是在课余聊天的时候，似乎有的同事还是不大理解。

晚饭去麦当劳买麦辣鸡翅吃，嘿，他们的服务流程就是Async的，下次你去麦当劳吃饭可以注意一下这种Async服务，我相信中国所有的麦当劳点在高峰期都是这样的服务方式(美国大多都是开车的Drive-thru，有点不一样)。

收款台永远是有限的，顾客多的时候就得排队，而且实际上每个柜台有两个队，一个是排队订餐的(叫A队吧)，另外一个是等着拿食物的(B队），你首先在A队，轮到你的时候，收款员问你要什么吃的，下了单，收了钱，然后就请你去B队等着拿食品，然后他/她就可以服务下一位顾客了，准备食物需要一些时间，当你订的食物准备好了的时候(你的食物完全有可能比排在你前面的人早做好，所以B队实际上也不是先来先走），服务员（可能是刚才的收款员也可能是其他服务员）会把食物拿到柜台，你拿走，这个过程就结束了。这个过程是不是很合理，这其实就是异步(Asynchronous)方式。

如果不是Asynchronous方式，换作Synchronous方式，那会是怎样？那就只有一个队，轮到你的时候，接待的服务员全程提供服务，服务员下单收钱，然后就去拿食品，结果这个食品可能还没做好(比如我最喜欢的麦辣鸡翅，似乎每次都要花点时间)，这位服务员就等着，你也等着，后面排队的顾客也等着，等到鸡翅做好之后，服务员把食物给你，然后才能服务下一个顾客。在非高峰期的时候，麦当劳也这么做，但是如果人一多，这样就弄不过来了。

假如下单收钱平均需要5秒，准备食物平均需要10秒，这种同步(Sync)方式一分钟之内只能服务60/(5+10)=4位顾客；用上面讲的异步(Async)方式，一分钟能够服务60/5=12位顾客，4:12=1:3，差异太明显了。你可能要说，麦当劳商家是爽了，但是从顾客的角度来看，我从点餐到拿到餐不还是需要15秒吗？没错，但是从你走进麦当劳开始排队到拿到食物的时间变短了，你不能指望每次进麦当劳都不用排队吧:) 假如一开始你前面有10个人，同步方式下，你需要等10*15+15=165秒才能拿到吃的，在异步方式下，你只需要等10*5+15=65秒就能拿到吃的，165:55，耗时只有以前的三分之一。可见，无论对服务方(Server)还是顾客方(Client)，异步方式都是好事情。

能理解麦当劳的工作方式，也就难理解Web Application开发的Asynchronous Programming Model，我相信每一个成熟的Web开发语言都提供了Asynchronous支持，不然没法开发出Scalable的应用来。

就ASP.NET而言，对于每个请求(Request)，都从线程池(ThreadPool)里分配一个线程来处理这个请求，同步方式下，这个线程得全程服务，直到处理完，才能被分配去处理另外一个请求。如果处理请求的操作都是需要CPU运算的，同步方式无可厚非，但是一些操作是I/O，读取数据库，或者是调用另外一个web service，做这些I/O操作的时候，工作线程也不会消耗CPU，就是干等着，而此时可能还有很多请求正在排队等待处理呢，这合理吗？当然不合理。注意，线程池里面的线程数量是有上显的，假如是250，那么同时最多处理250个请求，再来请求就要排队了。

一个自然的想法是，增加线程池里的线程数量能够解决Sync方式的问题吗？一定程度上也许能缓一下燃眉之急，但绝对不是正道，属于饮鸩止渴。你要是把线程池的线程数量设为1000，真的就能同时处理1000个请求吗？我很怀疑，首先线程之间切换就消耗CPU资源，其次，每个线程都要占内存，.NET中一个线程大约占1M的栈空间，1000*1M就是1G，Holy God！

我们把麦当劳和ASP.NET做个类比，收银台好比CPU，服务员好比线程，顾客好比请求。要是使用更多的CPU，增加线程还有意义，不然，让多个服务员抢着用一个收银台肯定没有一人一个收银台快。理想情况，一个系统有K个CPU，就应该只有K个线程，不过历史原因导致现在不是这么回事，线程数一般都是CPU数的一个倍数，但这个倍数不能太大。

异步能够提高多大的效率，参考前面麦当劳的例子，不多说了。不过虽说异步是个好东西，但是也不是说就该把所有的服务都换成异步的，对于有I/O的服务才适用，如果完全就是CPU运算，使用异步就完全没有意义。好比你去银行取钱，一般就不会有异步服务，银行职员不会拿了你的存折之后给你一个条让你过一会拿钱，因为取钱的过程银行职员没有I/O操作，他/她在服务过程中要忙个不停地数钱做记录，不会等待什么操作，他/她也没空闲服务下一个顾客，所以银行里都是同步操作。当然我这么说有点绝对，假如你要取10000美元，而他/她手头没这么多钱，这时候也许会让你等一会，指派一个人去金库拿钱(I/O操作)，然后他/她在你等待的时候，可以服务另一个顾客:)

讲得这么多，全都是ASync的必要性，如何Async Programming，这点文字是说不完的，而且写Async程序着实比谢Sync程序要复杂，改日再说吧。

年前收到一批关于培训的Email通知，当时不管三七二十一全都报了，年后发现全都报上了，而且时间都堆在这周剩下来的四天，今天下午又是Microsoft 2008 Annual Party，所以这一周整个就是一个培训周。

四天三个培训，都是Jeffrey Prosise讲，去年他来北京讲过ASP.NET AJAX（那时候大家习惯还叫Atlas），我傻呵呵的报了名去听，满怀诚意的以为会讲一些AJAX如何实现的问题，结果全是讲如何使用AJAX Control，当时我还有眼不识泰山觉得这人讲的净是些没用的，后来才知道此人事Wintellect三大牛人之一。这一年下来也算多积累了一些知识，希望这次再听能多些收获

微软给Yahoo!开了个天价，但是Yahoo!觉得价开低了，这也是预料之中的事情，不管Yahoo!董事会是根本不想卖，还是想买个更好的价钱，还是想刺激一下其他公司参加竞标，这一步棋都是合理的，市场上讨价还价是很正常的事情。

Yahoo!现在也是问题也是一大堆，微软买下来短期内可能也赚不了钱，一艘岌岌可危的船还要卖高价有点困难，当然Steve Ballmer如同海神波塞东一样，钱是挑在三叉戟上的，软的不行，来硬的绕过Yahoo!董事会直接向股东收购股权也是一个办法。