多多小虫天行健: Blog

Cacheman —— .NET架构下的分布式缓存

Mon, 31 Mar 2008 06:15:33 GMT

一个月前，fcicq邮件给我提供了一个Windows平台下的 memcached 类型的缓存软件 Cacheman。这是由微软旗下的 Popfly 项目组成员 Sriram Krishnan 的作品。是他用业余时间开发的。于是开始关注这个缓存项目。

最新的情况是，微软的 Popfly 网站已经“悄悄地”的做了更新，就是采用了 Krishnan 的 Cacheman，更新了缓存机制。该项缓存技术更新带来的性能提升非常显著，根据Popfly团队中的 John Montgomery 的说法：加载一个已有的Mashup应用时，可以带来2到6倍的性能提升。

这些说法也得到了 Krishnan 本人的确认。他提到这是 Cacheman 的第一次的实际应用，并自豪的说 Cacheman 不费吹灰之力就拿下了 Popfly 的全部访问量。

有意思的是 Montgomery 说他很开心这玩意儿运行正常，然后他又画蛇添足的补充了一句“至少现在如此”，然后 Krishnan 调侃说“我喜欢你说‘至少现在如此’的方式”。

简单介绍一下 Cacheman 这个项目。资料主要来源于 Krishnan的博客对Cacheman的介绍。

Cacheman是一个基于Windows平台的快速分布式哈希表。是由纯托管代码实现。中间搁置了有几个月，直到最近(似乎是今年1月低2月初)才开始重新上马这个项目，极可能就是因为Popfly项目需要的缘故才开始着手的。

Krishnan本人对 memcached 很感兴趣，于是创建了 Cacheman。Cacheman上有很多 memcached 的影子，比如与memcached相似的文本通讯协议。Cacheman的通讯协议公开，任何人可以根据自己偏爱的语言环境写客户端。 Krishnan 在自己家用电脑（2.4GHz Intel Core 2 带2GB内存）上进入测试，达到了每秒16000次左右的请求，并且还是服务器与客户端都是在同一台服务器下完成的。

现这款产品还不太完善，作者自身也提到：在Cacheman做指定key的GET/SET/DELETE操作时，客户端需要弄清需要与哪一台Cacheman服务器通讯，为此要对该key做一个快速FNV哈希然后求余得到应该和几台服务器中的哪台服务器通讯。但该法的缺点在于新增或删除一个服务器节点时，缓存节点需要大规模迁移。修复该问题需要一致性的哈希算法，作者表示还没有时间解决此事。作者提出了采用中心架构的“主缓存服务器”的解决办法，让客户端轮询主缓存服务器来获取应该与那个缓存服务器通讯，但他也觉的这样做增加了复杂性，会带来些新问题。

可以感觉到，由于 Cacheman 这个个人项目已经介入到 Popfly 这个正式产品中，可能很快就会被微软吸纳为正式产品，因此如果有人采用这个产品做自己缓存的解决方案的话，应该不必太担心后续的产品升级及文档支持服务，它的未来前途值的期待。说不定 Krishnan 会从 Popfly 项目脱身出来专职负责这个 Cacheman 项目。

目前最新的版本是0.0.2版下载：http://www.sriramkrishnan.com/projects/cacheman/Cacheman_0_0_2.zip 。虽然有人希望作者把它作为一个开源项目，遗憾的很，似乎作者并无此意，目前仅提供了二进制文件。

收购Yahoo，微软错了吗

Sat, 02 Feb 2008 02:59:40 GMT

目前争论都认为微软收购Yahoo!是不明智的。就我而言，也很难把微软和Yahoo!两家公司形象等同起来。
Yahoo!对微软而言共同点似乎很少，极难整合，至少在短期内是这样，那么微软错了，但是问题在于微软直的错了吗？假如微软没有错呢？

看看微软2007年的两次大收购：
2007年5月微软出价60亿美元收购在线广告商aQuantive 。
2007年10月　微软2.4亿美元收购Facebook的1.6%股份。

微软的收购行为已经明确表达出它认为互联网最大有盈利模式的市场是广告，互联网的斗争将围绕广告展开。收购Facebook部分股份的行为应该认为微软最主要的目的是其精准的广告服务。

同样的，回过头再来看看Yahoo!的收购。的确短期内两家公司确实很难整合，但是两家的互联网广告业务却可以联合起来对抗Google。
微软对Google在互联网广告业务的迅速发展是非常重视的。Google收购广告业务商DoubleClick公司时，引起了包括微软在内几家大型网络公司的紧张，联合指控Google搞垄断，反对其收购行为。Yahoo!同样也面对这样的压力，它和微软将面临共同的敌人。从这一点讲，这次收购就是合理的。

作为结尾，引用一下微软官方的新闻稿 http://www.microsoft.com/presspass/press/2008/feb08/02-01CorpNewsPR.mspx 中对互联广告市场的预测：
The online advertising market is growing at a very fast pace, from over $40 billion in 2007 to nearly $80 billion by 2010.

有趣的是，当年微软收购Facebook时也有类似的争论，看看这篇关于微软入股Facebook

解读豆瓣的“指环王架构”

Thu, 20 Dec 2007 05:44:29 GMT

豆瓣的官方博客前几天发表了"豆瓣技术团队的指环王文化"，文中笔调谐趣地道出《指环王》渗透入豆瓣的方方面面的场景，不经意间也透露出些许网站的“指环王架构”信息。我稍微做了一下整理，对有些信息做一些适当推测。

两台Web服务器承担。一台可能负责读书、电影、小组等；另一台负责9点。这两台服务器应该不是在前端的，豆瓣的网址应该都经过反向代理Rewrite过的，因此放在前端的可能还有几台硬盘缓存服务器（Squid？）做静态文件缓存，数目不详。
原文：梅里(Merry)和山姆(Sam)这两个霍比特人挑起了大梁，承担起所有用户的请求，向豆友们展现丰富多彩的页面。

应该还有几台Web服务器运行豆瓣的英文版及官方博客。不过从注册用户分离上看豆瓣英文版架构与中文版架构间关联度不大。
原文：运行着英文版豆瓣和豆瓣blog的服务器在美国，由于它离我们比较远，因此我们用中土世界跑得最快的马命名它——甘道夫的坐骑影疾(Shadowfax)。）

四台数据库服务器。这四台服务器的职能如何切分的还不清楚。如果这四台服务器是采用主从的架构，难道双胞胎爱隆和爱洛斯这两台是Slave服务器，森林女王凯兰崔尔(Galadriel)和灰港之主瑟丹(Círdan)是Master服务器？呵呵，瞎猜。
原文：四个神仙级的精灵：双胞胎爱隆(Elrond)和爱洛斯(Elros)，森林女王凯兰崔尔(Galadriel)和灰港之主瑟丹(Círdan)用他们伟大的智慧和不死的生命保护着用户的所有数据。

一台服务器做整站的全文检索
原文：爱隆之女，美丽的亚玟公主(Arwen)帮助用户迅速搜索到想要的信息。

两台服务器做后台服务。可能是RSS抓取及爬虫搜索的服务。
原文：另一个霍比特人皮聘(Pippin)和英俊的精灵王子勒苟拉斯(Legolas)执行着一些后台任务。

三台数据挖掘服务器
原文：人皇阿拉贡(Aragorn)和刚铎摄政王的儿子波罗莫(Boromir)，这两个强壮的人类和矮人金雳(Gimli)一起，承担着数据挖掘的重担。

一台图片文件服务器。以后豆瓣用户的头像、图书、电影等的图片都会由这台服务器来存储维护。从更广的方面讲，可能所有的css、js角本这样的静态文本都会被存储在这台服务器上。
原文：而波罗莫的弟弟法拉墨(Faramir)则逐步接管起图片的显示。

以上豆瓣的服务器架构的分配，实际上从这个服务器架构上还很难了解到到豆瓣如何处理负载均衡的。这里仅做初步认识好了。下面是豆瓣团队的软件开发项目。

豆瓣现有的软件项目：
豆瓣主站、数据挖掘、搜索爬虫、RSS抓取(9点)、高性能分布式计算平台。

开发：
开发团队采用了SCRUM敏捷模型的开发方法，Sprint的周期7天（周一迭代），以迅速响应不断变化的需求。每周的进展都会有一个code name。

看看以后豆瓣官方能否透露出更多的“指环王架构”细节。比如那个高性能分布式计算平台（这个名字很邪恶，叫魔多），或者一些没有提到的功能超级无敌的项目（似乎豆瓣的命名规则是越邪恶功能越强大，因此这个项目可能是未知的“索伦之眼”:-D）等等

2007中文网志年会旁观者印象

Mon, 05 Nov 2007 04:27:33 GMT

所谓“旁观者”，即未在现场之意。仅从一个全程看网络直播的参与者来谈一些想法。

这次年会赞助商中最成功的恐怕是jiwai.de。它的大屏幕互动提供了一种比手机短信更容易参与并且直观的展示形式。在场内场外恐怕互动是最为活跃的区域，从留言内容分类看极为广泛，有直接对正在进行的发言嘉宾提问、建议或评论的，有寻人的，有解释现场出现的某些问题的，有发布在会后召集的，不一而足。这极可能成为以后活动的标准样板形式。

现场的音频直播是采用某个语音聊天室进行的。在第一天上午有一段时间转播很容易断线，庄老师可能想上传几张现场照片给聊天室的参与者，但一上传就断线。后来得知是无线方式上网转播的，可能与无线方式转播不稳定有关。后来转播比较稳定。转播声音质量不是很好，听起来很吃力。在第二天zola自己在自己页面上发布了视频转播时况，声音效果很好。因此极可能语音聊天室的语音采集话筒离现场音箱距离很远，这造成直播质量的下降。2008南京的中文网志年会应该避免这一点，同时应该能提供视频直播。另外，在去年yupoo提供过照片直播，今年没提供。

官方指定了irc聊天频道和语音转播频道，irc进行的文字直播效果很不好，开头还有人会发出现场的情况文字，后来几乎没有人在上面了。官方指定的文字直播irc频道名存实亡了。从参与的容易程度而言，irc频道实在不适合进行文字直播。不过我想比较好的形式应该是聚合几个志愿参与转播的twitter或jiwai.de，把消息统一在一个页面实时显示应该会比irc效果好。因为大多数人活动区域主要集中在自己的“微博”上。比如本来参与主持irc直播者之一的zola，后来的更新主要集中在自己的twitter上了，甚至在嘉宾席上发言间隙还在更新自己的twitter。

虽然本次年会号称公益，先不提报名费用问题，其中有一个关于“Map服务”的议题，基本是主讲人在谈论展示自己公司的产品。我并不反对在这样的场合谈自己的产品，但是应该有所侧重。比如可以谈谈对于博客作者或一些创业者如何轻松整合自己公司的资源实现一些好的有前景的应用。毕竟参加年会的不是来此不是进行产品洽谈会，而是来进行思想交流的。赞助商可以在现场或网络等合适的位置发布广告信息，但是会议话题还是不要被“赞助”的好。在讲到“Map服务”这个话题时，语音聊天室主持人发出几个字“大家可以休息5分钟”。

说到会议话题，就想到了会议的日程安排。本来自己想参加现场的，但是现场离我住的地方距离实在太远，不能在会议指定时间前赶到现场，又想周末睡懒觉没去成。但是实际会议开始的时间仍然延时了。会议日程说是9:00开幕，但实际上10点以前现场一直在进行签到。在10点以后才开始。头天如此，第二天也延迟了。

关于中文网志年会的话题，有人认为话题应集中于“网志”上，围绕博客作者方方面面的话题进行。如果真这样我觉得这限制了年会的意义，而且随着发展年会发展议题会越来越窄。如果集中在互联网的草根技术方面的应用探讨，应该会有比较广泛的话题。

今年偷懒了，明年希望能去南京的年会现场。

Live Spaces的好友功能

Tue, 30 Oct 2007 09:25:20 GMT

Live Spaces新近在提供了的好友添加方式。尝试添加了一批好友，很容易，不过需要对方确认。这是延用了Live Messenger的交友方式。

如FaceBook这样的很多交友类网站都借用注册会员提供的Live Messenger帐号中的好友列表迅速建立起自己的好友圈子，本来如果Live Spaces去做这件事时应该更简单、容易一些的，因为还有什么网站能比Live Messenger与Live Spaces结合更紧密的吗？Live Messenger的帐号本身就是Spaces的帐号。但是很难理解的是，Spaces并没有直接把Messenger已经添加的好友列表直接加入到Spaces好友列表当中，而是需要单独添加。

其它交友类网站需要有一个导入Messenger好友列表的操作，但对于Spaces完全没必要，可以直接把Messenger好友列表拿出来直接用就是，但是Spaces偏偏也非要加入一个导入的操作，是不是有些画蛇添足。

Spaces中除了提供导入选择的Messenger好友为好友的功能外，还可以根据Spaces上好友的交友活动的简单记录随时加入一些新的好友，而这些好友不在你的Messenger列表当中，你既不认识，也不了解，更没有过交流，这使得Spaces好友的质量低于Messenger好友的质量。

这样实际上Spaces人为的造成了两套好友圈子，一套是Spaces的，一套是Messenger的，Spaces的好友不一定是Messenger的，Messenger的好友不一定是Spaces的，两个好友圈子相对独立。对Windows Live用户而言不能维护一个统一的好友圈子，却要维护两个好友圈子，这是怎么设计的？

总之，没看明白。

微软MinWin的未来猜想

Sun, 28 Oct 2007 08:16:26 GMT

10月13日，Eric Traut在伊利诺斯州大学第一次演示了一个新版本的Windows，其开发代号为Windows 7。在这个演示中，Eric首先为该虚拟机分配了40MB内存，然后运行该操作系统并启动了10个进程，共消耗大概33MB内存。
据称，这个新版本的Windows的实际核心大小约为4MB。其最小化安装将包含：
100个文件
占用25MB磁盘空间
不提供图形用户界面
一个最小化的HTTP服务器
启动时间小于20秒

以上内容引自http://www.infoq.com/cn/news/2007/10/minwin-windows7

根据对微软周边消息的掌握，这里做一些对MinWin未来的猜想。

一、现在微软同时在在维护多个核心的Windows（参见上面引用链接），这在开发和产品一致性上会存在一些问题。MinWin将是统一核心的开始。以后，手持设备(PPC/Smartphone)、桌面设备(PC)的操作系统核心都将变成统一，对不同的硬件设备可能只需采取相应的编译开关即可。

二、MiniWin将会全面进军硬件嵌入式开发的主要操作系统。现有的路由器、硬件防火墙、网关、工控机等的主要核心Rom基本上是Linux内核。MinWin将会全面进入这个市场。

三、用MinWin的核，添加其他定制服务将更加容易。如果遇到类似欧盟要求移除Vista安全特性这样的操作时，可以很容易完成，根据不同国家的法律制度要求来提供相应的功能服务模块。同时对服务器端用户与客户端用户定制也更容易。从开发上讲，最终用户版与服务器版的发布时间最终将趋向同步。

MinWin只是核心模块剥离外加一个简单Shell的小型化。我不信微软单纯会因为所谓的“广大用户的呼声”而这样做，更多的是对未来商业发展战略的考虑。

十一晚上的天安门广场

Tue, 02 Oct 2007 02:58:03 GMT

小区地处偏远，到了晚上11点几乎感受不到节日气氛，决定去天安门广场看看。外面天气太冷了，穿了厚外衣。

以为在这个时间段上广场游人会比较少，但是在车快到广场时就看到长安街两侧大量的游人。

从天安门西侧准备进入广场，但是似乎夜间清场已经开始了。守着西侧入口的警察只准游人出不准游人进了，后悔来晚了。警察告诉我们说明天早晨5点后来就可以进广场了。

这一张是刚到时拍的，很多游人正在涌出广场，我们进不去了。

没办法了，在外围拍了张背景是前门的照片。

倒霉的很，没拍几张相机没电了，要不应该可以拍到更多现场照片的。只好徒步由西走到东单然后返回。途间游人不断，有很多警察在维持秩序，广场上的广播也在循环播放着让游人注意的事项。延途马路一侧停造着很多移动公厕。在过地下通道时，还有武警也在指挥疏导地下通道的人流。在通道两侧有很多学生或躺或卧或玩在玩手机，极有可能是在准备看明天的升旗仪式。想起了我当年刚到北京上学，也是为了等凌晨升旗要在广场上等一宿。今年十一太冷了，在地下通道里相对来说还比较暖和些。

走到东单时，人流量已经逐渐减少了一些，看到王府井的麦当劳24小时店，准备进去坐坐吃点什么。走近一看，好家伙里面都是人啊，好些人还在排队，这可已经是晚上12点多了啊。不敢想象的是在明天天亮时广场人流量该多大啊。实在不敢出来了。

关于微软入股Facebook

Mon, 01 Oct 2007 02:13:57 GMT

有消息说微软将以3到5亿美元收购Facebook的5%的股份。于是出现了几种观点，总体上是认为微软会把它与SharePoint产品整合，会让Facebook变成一个企业级的应用，不利于普通用户应用；微软的介入会让该产品失去创新；微软的投资行为可能会使投资人高估类似Facebook社区类网站的价值导致新一轮互联网泡沫化开始。

这几种观点都或多或少的存在着问题，只能说他们并不了解微软。IDC的分析师Mark Levitt只知道微软的SharePoint产品不知道微软还有面向互联网用户的Windows Live系列产品吗？Facebook有庞大的用户群，微软怎么可能仅仅为了企业应用的产品SharePoint而放弃这些普通用户呢？如果真的的放弃了，微软在8月份花了60亿美元收购网络广告商aQuantive，那么难道这些广告仅仅是给企业用户准备的吗？放弃巨大的普通用户的注意力资源，又白白花巨资买网络广告公司，微软会这么傻？微软没有放弃与Digg的广告合作，难道会放弃Facebook?

所以可以肯定的是Facebook对于微软而言绝不是把它自废武功般的整合成狭小的SharePoint企业级应用。微软未来的战场在向互联网上转移，在互联网上，微软最大的敌人是Google，可以说微软近期的一系列互联网动作都与Google有关，比如Windows Live Search 2.0的推出。Facebook也不例外。

对微软而言，Facebook约不仅仅是一个社区。Facebook是第一个抢占开发互联网资源开发API的网站，他把自己成功的变成了一个平台。Facebook对社区的未来发展方向，可以说正好契合微软的理想。微软在传统PC世界，努力把Windows打造成一个环境、一个生态，开放其系统资源调用、制订种种标准调用规范，让无数的开发者为其开发扩展其功能，无数使用Windows的用户因此获益。而在互联网世界，微软需要延续他的成功，他需要做的就是一个类似Facebook这样的平台，然后立足于这样一个平台，强化Facebook的现有API应用。这不仅不会限制Facebook而且会有利于Facebook的未来发展。

一个值的注意的相关事件，在微软收购Facebook股份消息公开的前后，也同时有另一则消息公布，即：Google将大规模公开API，将会比Facebook更将开放。这两则消息无论谁先谁后，至少表明一点微软和Google都意识到互联网开发平台建立的重要性。

关于会引起泡沫化的问题，我以为不会。请注意我上面对微软收购Facebook真实意图的分析。如果Facebook单纯是一个Myspace那样的社区是不会引起微软的如此兴师动重。在今年7月份一度有消息称微软准备以60亿美元收购Facebook，单纯一个社区的话微软的这笔钱应该有更好的选择方向。这倒会引发另一个潮流：一大批社区开始逐渐开发和开放自己的API调用，以吸引投资人的注意。

拥挤的天坛

Tue, 18 Sep 2007 07:46:26 GMT

昨天下午陪老姐逛天坛，出发前认为天坛的游客会很少，因为是周一，不是周末，结果也是人山人海。说明：门票有15元、35元，这种价格绝对是陷阱，因为如果买了15元的票，在天坛里转，你无法游览圆丘、回音壁、祈年殿，如同在一个树比较多的普通公园散步，还不如玉渊坛。只有35元才包括上述三个景点。不幸的是我们买的就是前者，感觉很受骗。

拍了些照片，为避免大家看了照片产生误解，所以我再强调一下，以下照片拍摄时间不是十一国庆节拍的。

这是东侧古道上拍的，看看人多不多。

这是在上台阶上拍的

祈年殿门口。进不去只好在门外拍了。

相当部分的景点尚未开放还在施工，看看左侧的隔离铁皮及上面的标语。也许十一时能完全开放吧。

拍摄的这条古道没有开放，我是从围栏外拍摄的，道路上还有些民工在休息。

有一些古建筑已经包给一些纪念品小买部或照相馆之类商家，当时心想，如果这些商家是星巴克肯定有人会表示抗议了。但是现在这种场景下大家似乎重没有觉的有无不妥。

北天门下有三个门洞，两侧的门洞被两个票友“占据”。东侧门洞是一个胖胖的妇女拿着一个麦克高唱评戏，西侧的是一个男子也在唱不知道在唱什么戏，门洞的回响效果很好，但是正因如此就显得太吵了。之所以说“占据”，就是因为太吵了，游人都不敢从两侧门洞走，只从中间门洞走。这样的文化古迹里，外国人看到这样的场景也许会认为这也是天坛“文化”的一部分吧。

过一两周就到十一国庆了，我觉的就到北京来玩就千万别去这样的景点，那时人恐怕更多，抢一个合适的拍摄角度也会极难。我还不确定某些景点会否开放，但是可以肯定的是，这样的历史文化景观里，会增加一些与时俱进、符合现代特色的“景观”。因为我已经看到一些花坛之类的东东也在施工中，也许是拼一个庆祝国庆的文字，也许是拼成一个奥运五小强图案吧。

由新浪博客的广告谈起

Wed, 12 Sep 2007 16:47:56 GMT

新浪博客首页已经开始投放大量的广告，从别人的文章里才注意到这个事实。但映像中博客作者页面实际上也早已经有一些商业性不是很强的广告了。

keso说放下Alexa，不过我这里仍然想引用Alexa有关新浪的一组相对数据：
blog.sina.com.cn - 15%
finance.sina.com.cn - 14%
news.sina.com.cn - 12%
sports.sina.com.cn - 10%
book.sina.com.cn - 8%

以上数据是新浪各频道访问百分比较高的前五名。可以看到博客所带来的访问量已经不知不觉的超过了新浪引以为傲的新闻频道，成了新浪的第一流量频道。这样的流量构成下，新浪在博客上放广告是迟早的事也是必然的事。但是如何在博客作者页面中投放商业广告，这值得关注。它不能引起博客作者的太大的反感，尤其有这么多明星驻博。而且在奥运新闻播报上，博客应该是新浪应对搜狐又不违反规则的重要一环。所以新浪应该会很慎重。比较现成的而且已经有案例的思路是广告与博客作者分成。这个思路如此简明，新浪不会没有看见，这么久没有采用这样的方式，也许他有别的打算吧。

新浪曾经下很大力度去推广的爱问居然在Alexa关于新浪流量前十名都没有排进去，失败。（流量低也许与它也用另一个域名www.iask.com有关吧，不过这个域名流量也很低。而且现在这个域名的搜索结果也由Google去处理了。）

以前新浪的访问量第一的绝对是新闻频道，而现在屈居第三让位于博客频道。这是否表明个人媒体正在逐渐崛起呢？

Update(2007-9-13 8:0:0):没注意到，原来新浪已经公布了博客作者广告分成办法。

Cookie的优化使用

Fri, 07 Sep 2007 17:25:38 GMT

最近IE项目经理EricLaw在微软官方的IEBlog上发了篇文章解释说明上个月（8月份）IE累积更新中MS07-045中关于Cookie Jar的部分的功能变化。

原来IE每个域限制cookie项目为20个，现在增到50个。以前为规避20个cookie的限制，很多编程者都是通过字典cookie的方式来解决。

但是有两个限制仍然没有改变：
1、DOM中的document.cookie属性只能检索客户端计算机上 cookie 的 4096 个字节。如果 cookie 字符串的长度超过 4096 个字节，则该属性将返回空字符串。
2、如果“Set-Cookie”头的长度超过 5118 个字节，则 Internet Explorer 和 HTTP Wininet API 将忽略“Set-Cookie”头。

虽然提升了cookie项目数量的限制，但是EricLaw出于功能和性能的原因考虑仍然建议尽量降低 cookie 的使用数量，并且要尽量使用小 cookie。另外，应用程序应能够处理 cookie 丢失。

他解释说：存在多个cookie时会增加HTTP请求次数，极大的降低浏览速度，如今的web用户上行/下行带宽是不对称的，通常下载速度要比上传速度快两到五倍。这意味着某些情况下，决定整体传输时间消耗时，HTTP的Request次数的影响比服务器端的Response次数的影响更大。

他提供了三种使用cookie的策略减少对站点性能的影响：
1、最小化cookie大小:使用最短的cookie名和cookie值
2、把静态内容发布到不同域上去：如果使用了许多静态资源（CSS、imgages、JS），它不会随cookie值变化，使用该法能取得良好的效果。比如你浏览Office Online clipart网站，你会注意到图片都来自http://officeimages.microsoft.com，而不是http://office.microsoft.com。这意味着大量设置在office.microsoft.com域的cookie不会发送到officeimage.microsoft.com站点上。
3、必要时用Path属性发送cookie：这类似于第2条。

文中还提到了如何保证cookie的安全性问题，他的建议是使用HttpOnly属性，说这样可以避免客户端跨站角本窃取cookie。根据我所了解的资料，HttpOnly属性是微软在IE上的一个功能扩展，这决定了这个功能可能受限于IE环境下。另外，如果有人用Flash内嵌的角本功能来窃取cookie，这个功能仍然是无能为力的，只能说这个属性有用，但作用有限。

2007北京WordCamp聚会流水帐

Mon, 03 Sep 2007 17:45:38 GMT

最初没打算要参加这个聚会，因为我不是WordPress用户，但是fcicq说可以认识一些朋友，检查了一下已经登记参与的名单，报了名。

在报完名后几次收到活动组织者杨远骋同学群发的邮件，其中一封是是急召活动主持人希望得到大家帮助的。以为急召的主持人会有问题。不过等到了现场，发现主持人是有名的白鸦。白鸦成了会场最忙碌的人，因为会场大，人数多，当进行Q&A的环节时，就看见白鸦同学满场飞奔为的就是把话筒传到提问同学的手上。

上午吕欣欣说keso同学正在睡觉，下午可能会过来。满怀期待，但是下午我没看到以为没有来过，但事后有人告诉我说keso真的来过了。午餐后，我有午睡的习惯，那时有两位女生在拉中提琴，我睡着了，莫非是在那个时候keso来了？

aw说Windows Live Writer是最好的写Blog的桌面软件。我不用WordPress，以为与大家没有共同点了，原来还是有那么一点点的。

有人问饭否抄袭twitter的问题，穆荣均答：就国内而言不是我们抄袭twitter的问题，更多的是国内同类网站抄袭我们的问题。
有人问饭否的商业营利模式，穆荣均说还没有找到。
在穆荣均的幻灯片其中一节涉及饭否的未来的风险：腾讯滔滔、移动。

在会议室外有一面墙做Post Corner，看看这墙你就了解沙发党真是无处不在。这里面的“天花板” 比较过分，强行在“沙发”上方的空隙里占一个位置，形同流氓插件。不过后来“天花板”真的贴在了上方的天花板上。其它照片在我的flickr上，请用tor访问。

花絮：

一个同学用英语向金亮提了三个问题，全场鸦雀无声，金亮迟疑了一下然后说，对不起我没听明白你的问题。那个提问同学只好投降，用汉语重复了一遍问题。这时候会场一扫前面紧张的气氛，很好玩。

吕欣欣说：今天来到这里的不敢说都用WordPress，但也是全都是写博客，有没有不写博客的也参加会议的？如果有的话大家应该一起BS一下。结果有一个女生举起了手。

aw报告时说：“从2005年10月到现在Google Adsense给我博客贡献的收入是600美元，大家认为是多还是少？”会场沉默片刻，然后有几个声音弱弱的说“少”。我的分析估计有很多博客作者觉的这个数应该挺高的了。虽然还不到足以养家糊口的地步。但是根据aw的上下文主旨是在讲不能把博客做一种谋生手段，所以造成大家的迟疑。如果aw换成“这些钱能养活自己吗”这样的表述可能会让大家的答案更明确些。

从MSNShell到珊瑚虫

Thu, 16 Aug 2007 05:38:10 GMT

MSNShell是一款Windows Live Messenger外挂。新装了MSNShell最新4.2版。不为别的，主要是可以过滤掉Windows Live Messenger本身的广告内容，其它功能很少用。但是这个最新版让我看到它也开始提供广告了，以前也有，不过仅限于标签面板内，只要关闭即可。现在已经没办法回避了，查看一个用户个人信息，它也要把广告图片硬塞进来，强迫你关注。这在Windows Live Messenger版本里是没有这个广告位的，MSNShell强占了这个位置。

三国蜀汉的光禄大夫谯周在曹魏大军兵临城下的时刻谏刘禅说，只能投降，投降江东孙吴，恐怕以后仍然要再投降曹魏。因此投降曹魏只受一次侮辱，投降江东要受两次侮辱，前者更划算。

我们通常把这种乱放广告的强奸用户眼球的行为称之为一种流氓。如果微软是一这样的“流氓”，MSNShell现在也是，那么作为普通用户，我凭什么要同时忍受两大“流氓”呢？或者说为了赶走一个“流氓”引进一个新的。于是我卸载了MSNShell。只忍受一个流氓好了。

珊瑚虫是QQ的外挂。我相信其用户安装量远超过MSNShell。但是珊瑚虫的却没有MSNShell那么大量投放的广告位置，仅在标签面板中占着一个小位置，但我从不用它。但并不能因此而断定珊瑚虫肯定比MSNShell更高尚，珊瑚虫肯定也是有类似MSNShell一样的商业利益考量，但是它表现的似乎并没有象MSNShell这样“嚣张”的广告，为什么？

MSNShell的上游是微软，珊瑚虫的是腾讯。他们的商业模式是否成功其实完全取决于他们的上游。

微软的商业竞争力来源于微软生态，微软一直在培养这种生态环境，它提供解决方案的底层实现，协助用户用微软的方案来搭建所需要的操作平台。多少年的积累，微软的这种生态环境下培育了很多成功的用户（虽然在近一段时期内，Google正试图建立新的生态圈以破坏微软现有的生态。以后我会有文章分析这两种生态）。在这个生态圈里，微软鼓励用户采用微软的产品来实现其具体应用。

腾讯的商业核心就是依托QQ这款IM软件，再辐射周边产品，任何染指QQ增值服务的第三方都是在侵犯腾讯的核心商业利益。

依托不同的上游商家产生的商业模式结果理所当然的就出现了不同结果。MSNShell可以很“嚣张”，而珊瑚虫只能小心谨慎，稍有企图马上会得到腾讯的法律诉讼。腾讯的商业模式决定了它不能容忍任何第三方非合作机构提供增值服务，在这样的背景下，腾讯一手制止了最早的显IP的OICQ作者邹丹的更新，然后是木子QQ。现在轮到了珊瑚虫，现有条件下它只能生存于腾讯的阴影下。

不久前有文章提到国内Twitter克隆网站叽歪de说：它还具备一个在国内打败 Twitter 的坚实基础QQ，Twitter 估计一时半会儿还不可能支持 QQ。这貌似优势其实无异于与虎谋皮。腾讯怎么能容忍别人从自己产品增值服务里分一杯羹呢。这种想法很快得到了证实，几天前腾讯滔滔上线了。所以设计产品的商业模式时最好不要打QQ的主意，或者千万不要把与QQ功能整合当作一个优势而沾沾自喜。

Update(2007-8-19):真巧，本文刚发布次日就有消息说珊瑚虫出事了，后续的报道虽然已经表明与265没有关系，但是珊瑚虫肯定出问题了，其主页这几天已经无法打开。

15分钟搞定jQuery(jQuery in 15 minutes)

Thu, 09 Aug 2007 06:48:09 GMT

才发现的好东东。jQuery架构的开发者之一Simon Willison在前天新提供了一个简洁明了的用法演示—— 15分钟搞定jQuery（jQuery in 15 minutes）。开发人员提供的教程更应该能体现jQuery的神髓。

内容：

jQuery特点
CSS选择器用法
jQuery集合
jQuery集合操作
获取匹配元素的值
DOM元素遍历
事件处理
安静加载运行
对象链串访问
疯狂链串(Crazy Chaining)
Ajax用法
推荐了几个插件

基本上是一部14页的幻灯片，但每页的幻灯片的容量都很大。其精选的例子相当有代表性。以我个人来看，在jQuery的官方公开的API文档没有讲清的细节，比如关于jQuery中end()的用法，我在单看API文档时范例很难看懂，但是看了这个第11张幻灯片的示例就比较清晰了。另外关于CSS选择器的各种写法示例也比较明了。

当然真的想凭这个幻灯片要15分钟搞定jQuery恐怕还是有难度的，需要有些相关参考的一定开发量的。作者最后推荐了jQuery的官方网站和一个API指南网站作为延伸阅读。

Update(2007-11-26):Willison在最近的讲演幻灯片中已经充实这个内容，并把题目改成“30分钟搞定jQuery”(Learning jQuery in 30 minutes)。呵呵，时间延长了一倍,不过内容也充实详细了些，有了更多的示例。

翻译：《为什么选择Dojo》－兼评测其它主流的JavaScript框架工具包(之二)

Wed, 11 Jul 2007 05:14:36 GMT

在翻译《为什么选择Dojo》这篇文章的过程中发现了有关该文章的讨论链接（http://ajaxian.com/archives/why-choose-dojo）。这些讨论中也涉及了很多常用框架的评价，都可以做为第三方的参考意见，同时Dojo官方的开发人员也加入了这场争论当中。讨论中也涉及到其它主流的框架技术特点比较，具有一定参考意义。从讨论中可以看出Dojo早期的版本确实问题多多，而且因为种种问题似乎正在走向衰落。不过还好有Dojo官方开发人员介入讨论才有新的认识，同时也可以感知新版Dojo0.9版应该是被Dojo官方寄予厚望的产品，也许借助这个版本能重新赢得开发人员的支持。这些辩论非常精彩，觉的有必要翻译过来，于是对部分有价值的发言做了翻译整理，放在此处。可以与《〈为什么选择Dojo〉－兼评测其它主流的JavaScript框架工具包(之一)》对照参看。这个系列仅两部分，本文为截止篇。

＝＝以下是相关讨论的译文＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
原文链接：http://ajaxian.com/archives/why-choose-dojo
翻译：多多小虫(bigqiang)

AsiaPartTime：
有人把微软的Ajax框架与Dojo比较过吗？有人做过把这两个框架结合在一起使用的尝试没有？我希望能碰到这方面的高手。
（译注：翻译完才发现原来主流框架里面漏了微软的ASP.NET AJAX控件工具包（以前叫Atlas），不用说这个框架的服务器端部分会局限在微软的架构上，不能跨平台。）

Timothy Dang：
如果你不在乎那个Dojo框架提供的离线功能，我相信 jQuery 和 Ext 在所有框架中是最优选择，而且他们二者可以非常完美地结合在一起。

M：
我特别在意“社区”那一部分。
我用的最后一个框架是 Mootools。但是那个“社区”总是一副对人爱理不理的傲慢面孔，比如那个Mootools的论坛(the Mootools forums)。我以后的项目再不会用那个 Mootools 。
(译注：不是技术而是一个社区的气氛竟然影响了开发者的选择取向，值得深思。)

gonchuki：
文中没有专门对 Mootools 的评价，仅在涉及JQuery的部分稍微提了一下…
希望 moo 1.2 发布后能得到大量它应得的关注。

r：
我在做一个 OSS 项目，在这期间我从一个框架跳到另一个框架：最初是dojo，然后是 prototype/script，而现在是 jquery+yui。
虽然在博客上发这样的文章是个很好的宣传，但是它仍然不能回答人们为什么象躲避瘟疫一样远离 Dojo 的真正原因。
Dojo 是为软件工程师们写的，他们绞尽脑汁地想在Javascript上封装所有应用。但绝大多数Web开发者想做的仅仅是把“能用”的代码东东放在一起就好。可是来到Dojo 网站看到了什么，它给了我一个8MB tar文件的下载链接。那样的情况下我只好去搜索 Prototype，而它提供的链接只是一个小小 JS 文件。
对这一切而言，“Dojo 0.9”在大小上与 Prototype 和另的库文件根本不具可比性。不仅如此，学习 Dojo 代码困难程度也是令人难以置信。可以尝试装上 Prototype 和 Dojo 核心JS文件，然后自己感受一下哪一个会让你开发速度更快捷。
我许多朋友不是从事Web开发的，但由于一些课题必须做一些轻量级的Web开发。对 DOM操作部分，我建议他们用jQuery，因为绝大多数人熟悉XPath，并且他们会很喜欢jQuery链串的那种语法表达方式。我知道 Dojo 0.9 已经有了CSS3选择器，但除此而外就一无所有了（如果我错了请指正）。使用这种模仿的选择器太笨了，不是我一个这样认为。
当然他们也做了些好的技术决策，比如Prototype 的Array()对象操作真是杀手级的应用，但是显而易见这些似乎并不能赢得更多开发人员的关注。

ajaxus.net：
读完后还是不能使我信服，为什么要用Dojo。

Cyril：
“YUI 目标人群是专业的PHP开发者”
不相信那篇文章的说法。尽管Yahoo使用PHP，但是YUI不是一个以特殊服务器端为基础的技术。

kangax：
我实在没有认识到widgets有什么好处，Dojo似乎拔高了它作为他们主要功能特点的好处。
我喜欢的是打包系统(packaging system )和命名空间——那些原型所缺乏的东西，不过YUI不需要额外开销就做到了这些。

Jonathan：
我选择dojo是因为它的许可协议，也与我个人经验有关。它很容易与 EXT 或别的框架集成。作为一个开发者，我希望将来的框架能彼此很好的集成在一起。

Hank：
这篇文章应该改名为“为什么不选择Dojo”，这才是必然的结果。太缺乏开发文档的情况下导致这种情况是理所当然的，这是开发一个富集API的最重要的方面。浏览一下他们的API文档根本没有真正提供什么有效的东西，他们不解释说明某些对象是做什么用的，也不提供一个他们如何起作用的示例。甚至在 the Dojo Book 0.9 中仅有一个架构图。

Tom Trenka：（译注：这个似乎是Dojo的官方人员）
回复r: 你下载的 8MB tar文件包，是因为它包含了所有的工具，这些工具可用于创建适用于你自己的简洁构造版本。在所有代码文件中，如果你是想和Prototype做比较，那么所需要的应该是这个工具包里面dojo目录下的dojo.js文件来与Prototype进行大小比较。我们使用CSS3选择器是因为我们痛苦地意识到 XPath还没有得到我们所想看到的开发团体的某种认可。就个人而言我认为CSS3语法已经足够满足所需（尽管可能不能满足你的需要，我想我们能拥有完整的 XPath能力）。我想你可能仍然在思考0.4.x 子版本“太过笨重”；Dojo Core (0.9) 对我而言相当轻量级。
回复Cyril：我还不能完全确定，但是我感觉Alex那样说的原因在于从YUI开发团队那里直接得到的印象就是如此。
回复kangax：声明使用标记的widgets的能力所带来的大量好处远超过你的想像，关于在许多讨论中认为Dijit完全占优的问题，在我们的Dojo论坛里有说明。回复Hank：的确如此，我们知道这一点，我们正努力改变文档缺乏这一状况。每个软件共享项目都会遇到这个问题：花所有时间去写出整洁漂亮的代码却不想花时间为它写任何文档。不过新的API文档即将发布(http://redesign.dojotoolkit.org 在我们解决这些问题前，这是一个临时页面)，并且，我们一直在构建一些周边的图标，我们必须做这些事，这将使得文档更容易理解。

Darby Flanagan（译注：这个似乎也是Dojo官方人员）
我在Lotusphere 2007年会上介绍过dojo工具包。我可能和你们大多数人一样不是一个资深的开发人员，但是我必须承认把dojo和我们为Lotus Notes/Domino定制的portal应用整合在一起非常容易。
我正在给所有我们IBM Domino Web开发者洗脑，让他逐渐地接受Dojo工具包所带来的好处。
我唯一不满意的就是文档。
但是我们会面对它，直到彻底被冲入下水道……(译注：后面略了全是blabla的空话)

Randy：
回复r：Prototype 现在也有那种链串式的语法结构了。示例如下：
$(’tab’).hide().addClassName(’something’).update(’inner text is neat’);

steve heron：
有能提供一个“high-profile, high-traffic”网站使用dojo的案例吗。他们广泛采用dojo widgets的情况。我正在做这方面的评估。

Albert:
我以前在各种项目中用过dojo (0.4)，并且最终决定弃用dojo，主要是两个原因所致：
1、文档太糟糕了
2、性能糟糕。使用一个简单的组件需要下载巨量的js文件让页加载速度非常缓慢。
可能新版本功能会好些吧。

Dylan Schiemann：
回复Albert：那正好是Dojo 0.9所要解决的问题，请看 http://ajaxian.com/archives/dojo-09-the-next-generation-is-here
回复steve：太多了，bloglines.com、renkoo.com、aol的web mail beta版、aim页面、apple的店辅。我认为Dojo 0.9的大小和性能已经有了更大的改善，这不应该再做为讨论的重点。

Jesse Kuhnert：
回复Dylan:还有ebay的shopping.com。

Brad Neuberg：
鉴于Dojo文档的问题，我提供了一个高质量的文档，这是关于Dojo offline功能部分的。关于Dojo Offline功能参考我拥有完整的操作指南。
http://docs.google.com/View?docid=dhkhksk4_8gdp9gr
希望既能帮助新用户，也能给想钻研的开发者提供许多先进用法。

r：
回复tom：感谢回应。问题关键在于我要做什么，对于一个要使用Dojo的新的潜在的开发者而言，要做的第一件事就是不得不下载一个8mb的tar文件，他们会很难容忍这一点。然后需要认真仔细的考虑自己需要什么功能去自己定制。这不是Dojo自身的问题，但是你们在你们站点发布时只发布了一种下载方式。我很喜欢prototype的作法，仅链接一个自身的js文件。对一个技术复杂度跟Dojo一样的项目而言，这种作法非常简单。我想你们能够领会这些意思 (请不要把你们自身置于有20多个不同版本同时下载的那种乱糟糟的情形之下)。
回复randy：你难道不知道 dojo 已经有链串功能。

rip747：
我在过去曾尝试应用Dojo，它每次都能在加载时让我的浏览器崩溃。
我不用Dojo是因为它太臃肿了。我喜欢用jQuery，因为它非常小，我能通过一些插件去扩展它。
Dojo阵营的这篇文字看起来象一个绝望者，他想将那些被他们抛弃的人重新拉回来，悲哀啊。

Tom Trenka：
回复r: 你提到了0.4子版本的问题，我们会给0.9版只提供一个下载，我完全同意你关于20个版本的想法。
回复rip747: 你有权做出你的个人选择。但是在你还不了解Dojo小组内部的任何情况时请不要妄做评价，比如“看起来象一个绝望者”。

翻译：《为什么选择Dojo》－兼评测其它主流的JavaScript框架工具包(之一)

Tue, 10 Jul 2007 14:05:03 GMT

认真的选择一个自己合用的Ajax应用平台比较伤脑筋，因为有太多选择了。随便举几个：Prototype、jQuery、Ext、MochiKit、GWT（Google Web Toolkit）、YUI（Yahoo! UI Library）。初次下手为了评测优劣如果每个JavaScript应用框架都学习一遍成本太高了。还好，Dojo Javascript工具包的官方网站前几天出了篇文章《Why Dojo?》(为什么选择Dojo)。这篇文章由于发表在Dojo官方网站因此其结论可能会受其立场影响，但这并不是最重要的问题，重要的是作者在做结论前对市面上主流的JavaScript应用框架功能特点做了一个完整比较，这些对开发者选择一个合适的框架非常具有参考价值。因此我花了些时间来翻译这篇文章。网络转载本文需要指明出处，传统媒体采用本译文需要先联系本人。

就我个人而言最先接触的是Prototype，做了些简单的Ajax项目后很久没有用了。最近一段时间接触了JQuery，感觉真的很好用。有一种说法说Prototype就像Java，而jQuery就像ruby，可惜我既没碰过Java也对ruby涉猎不深，所以这种感受不强烈。不过不妨碍我喜欢jQuery，除简单小巧易于学习外，我觉的最大的特点应该是jQuery能做到JavaScript代码与html生成页面分离。最近设计的项目全用了这个架构，页面内除了在head标签内嵌入js文件的链接外，看不到一行JavaScript代码，真是酷啊。不过因为没有涉及过其它的框架结构，所以在翻译时会遇到一些问题，如果你发现了请指正。

在翻译的过程中发现了有关《为什么选择Dojo》文章的讨论链接（http://ajaxian.com/archives/why-choose-dojo）。这些讨论中也涉及了很多常用框架的评价，都可以做为第三方的参考意见，同时Dojo官方的开发人员也加入了这场争论当中。这些辩论也非常的精彩，我对部分发言做了翻译整理，会放在《〈为什么选择Dojo〉－兼评测其它主流的JavaScript框架工具包(之二)》中。

＝＝以下是译文＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
译文名：为什么选择Dojo?
原文名：Why Dojo?
原文链接：http://dojotoolkit.org/book/dojo-book-0-9/introduction/why-dojo
作者：alex
翻译：多多小虫(bigqiang)
时间：Fri, 07/06/2007 - 06:39

如今可供选择的JavaScript工具包有很高质量水准的只有几个，另外因质量和完整程度不同的工具包有几百个。在这海量选项中，为什么要选择Dojo呢？

宽度和广度：Dojo是一个“full stack”的应用框架。不是那种把几个不同的源码简单拼凑在一起的组件。Dojo通过提供集成的底层架构和广泛的可选模块允许每个组件构造成一个高质量积木式的可信赖集合。这些组件给普通用户遇到的问题提供了良好的解决方案，他们也很容易调整以满足你的需求。从基于面板的设计到客户端图表、到数据绑定、到久经考验的模块系统，Dojo是一个考虑了众多用户体验的刚性的底层架构。

质量：国际化及易访问的底层架构是通过Dojo“纤维”编织而成。每次击键都会有正确提示。所有组件做为一个粘着的整体契合在一起。每件东西都是可以很容易与CSS一起进行定制。只消稍做调整即可获得一个漂亮整洁的外观变化，以大量的用户体验为基础（这些人不仅有普通用户，还有设计师和开发人员）做了设计和测试，这些都是它的特点。

性能：Dojo被用于每天都有高访问量和高流量的站点上，采用Dojo的构造工具是为什么如此的一个关键原因。Dojo软件包系统很容易管理大规模的UI开发项目以及构建顶部的系统层，可以做出令人吃惊的应用。所有这些无需代码修改。Dojo也把高性能的普通应用实现打包到了它的核心内，并且Dojo0.9版在性能上给予了更多的关注，减少了代码。它是个小巧、紧凑的工具包并且速度飞快。这些特点使Dojo成为扩展和构建的理想平台。

社区：Dojo是一个开源的社区，个人和公司都能走到一起公平竞争，这使得大家在使用这些工具时彼此获益。Dojo工具包的许可协议被设计成尽可能与政治无关保持中立。我们努力工作也是为了确保在遇到棘手的问题时能很容易得以解决。所有开发都是在开放的环境中进行，并且有意识的降低学习门槛。我们不关心你在哪工作或你是否资深，你在社区中的地位由你所参与的工作质量决定。我们正致力于改变那些可能是开源社区贡献者人的观念，并且我们邀请你加入我们，如果你构造一个伟大的产品并且认为你能帮助我们，我们愿意接受你的任何建议。

Dojo 与别的工具包大比拼

这里拿几个经常与Dojo比较的工具包。下面不是完整的比较，而是基于较高层次上的比较，比如功能特点、设计目标等以及这些特点、设计过程、哲学比之于Dojo有何不同。

MochiKit:
MochiKit 是高质量的JavaScript工具包，它书写JavaScript代码类似Python语言风格，并且性能出重。它在封装、命名以及全局名字空间的用法上遵守与Dojo相同的保守主义。它主要由Bob Ippolito 一个人完成，它拥有完善的文档和测试代码，但是不同于 Dojo ，它没有配备一个widget系统或一个广泛的组件集。某些代码在Mochi和Dojo间可以共享（当然是在CLA协议下）。Mochi没有基金支持，并且代码来源无从验证，不过它有很宽松的许可授权限制。

Prototype+Scriptaculous:
他们广泛深入的库函数提供了很多与Dojo核心相同的功能，但关于全局命名空间争议上并不具有Dojo那种保守哲学，他们偏爱短名称用于常用函数甚于其他。他们拥有优秀的开发文档和广泛的社区支持，以及与Ruby On Rails非常好的紧密集成。Scriptaculous 提供了一些控件（自动完成、幻灯片等)，但没有一个 widget 工具箱，而且也不支持轻松构建一个widgets的能力。Prototype+Scriptaculous有很多 add-on 库可利用，但他们没有同库文件一些发布。他们没有打包功能和构造系统功能(除了他们自己的distributables外). Prototype和Scriptaculous没有基金支持，并且代码来源无从验证，不过他们有很宽松的许可限制。
(译注：实在不知道这个打包功能package是个什么功能，姑且这样译吧，后面几处也都一并这样处理。)

YUI:
YUI是Yahoo内部开发的产品，应用广泛，拥有高质量的文档和示例。以速度做为设计标准，目标人群是专业的PHP开发者。YUI以满足Yahoo规模级别的需求为考量来设计。工具包是有用的CSS常化和设计样式表，他所包含的可用控件列表不断增长。无打包系统可用，常用功能“roll up”文件被发布，并且文档说明了装载文件的顺序。无CSS查询或标记驱动的 widget 构造系统可用。 YUI拥有一个活跃的社区和自由的许可协议，但是在项目中不允许外部提交，Yahoo还没有澄清过代码渊源以及其他与工具包有关的知识产权问题。没有从源头控制任意数据种类的访问。YUI在Yahoo的所有CDN上都可边际缓存（edge-cached）。

JQuery:
主要关注DOM结构的操作的最小需求系统。JQuery 特点是其混合了XPath/CSS的查询语言（Dojo使用了标准的CSS 3查询），并且在这些查询结果的基础上提供了一个操作和选项的富集。JQuery 封装了Ajax、效果(effects)以及别的应用进入一个微核心内(这一点除了MooTools似乎无人可比)。它同样没有 widget或打包系统，有以jQuery以基础的第三方组件库可供应用。JQuery 社区高度活跃，彼此互助，并且接受外部的贡献和开发的补丁。优秀的开发文档很容易得到。JQuery 具有MIT和GPL双重许可的所有版权，版权归John Resig所有。还不清楚这个知识产权以什么条款从别的贡献者那里指定归John所有。有几个框架(特别是Drupal系统)集成了JQuery。

EXT:
类似于Dojo的Dijit系统，EXT是一个组件库，它展示了大量一致的、好看的着重于像素完美布局以及兼容各种浏览器的类似桌面UI的widget。最初开发用于YUI上，后来是JQuery。EXT 现在有它自己的底层库，不再需要依靠第三方。EXT社区也非常活跃，有优秀的文档且容易获取，它的许可授权是依据以LGPL的条款和各种可用的商业授权许可表单为基础的。在这些条款下，无论外部贡献被接受与否其知识产权归属都不明确，并且匿名子版本的访问许可也将受限于在某方面商业上支持该项目的那些人。

GWT:
直接集成了服务器商开发和客户端的开发，GWT接受这样的观点，JavaScript是一个应该被解决的bug，并且使用高级的编译器技术允许开发者用Java写代码，并且产生动态的基于Google UI风格的JavaScript代码。默认的widget集严格来讲是Dijit提供的一个子集，不过GWT在优化所产生的代码上花了很多的心思。add-on 库一直在增长，大大增强了默认的组件功能。与YUI和EXT不同，GWT是一个真正开源运行的项目，允许外部贡献提交。在一个开源的环境进行开发时知识产权管理问题非常复杂(CLAs、code review等。有大量象Apache 或 Dojo的项目)。GWT应用仅能用Java写，并且多是部署在Java容器环境内。它有优秀的文档并且，并且社区也在逐渐成长壮大。

作为比较也列出Dojo：
允许外部贡献提交并且使用CLAs许可(同GWT 和 Apache) 以确保没有知识产权问题。
非常宽松自由的授权许可，提供匿名SVN访问功能给每一个人。Committer privs are earned
提供了一个富客户端的组件集，并不强求与任何服务器端语言（协议、无API）紧密绑定。
力求在网线传输大小和常规功能调用间提供一种平衡。Dojo的基础类库大小与Prototype接近。
在不触犯涉及别人的代码以及保留全局命名空间上我们非常保守。
支持在AOL的CDN上进行边际缓存(edge-cached)。
提供了一个打包系统，它可以让你知道在一个未确定的问题中加载的东西是以什么顺序进行的。
允许通过标记增量加强功能，并提供一个非常容易使用的widgett系统，用于构建你自己的可重用组件，它可以通过标记很容易将其实例化。

update(2007-10-7):
1、感谢http://cloudreams.spaces.live.com/的指正。关于EXT的Subversion翻译问题，再次查看了原文，觉的他理解应该是更准确些，我当时可能因这个词首字母是小写的而没有留意，感谢cloudreams。我想“并且匿名子版本的访问许可也将受限于在某方面商业上支持该项目的那些人”这应该译为“并且Subversion匿名访问许可也将受限于在某方面商业上支持该项目的那些人”
2、在重新review本文发现在译到Prototype部分时出现了package，当时不太知道怎么回事。根据一段时间的积累，所谓的Package是这样一种功能：由于一些框架功能太多代码体积庞大，为了更好的减少体积仅把功能相适应的部分加载到对应的页面，某些框架对体系内的代码做了功能拆分，基本上有一个最小功能核，然后有图形部分、特效部分等，把一个庞大体积的框架功能代码分散在多个体积较小的文件当中。为便于开发者选择合适的功能代码，提供了这种打包“package”工具，可以根据你开发中所需要的功能，把相应的代码文件打包在一起。

天气太热了

Tue, 12 Jun 2007 14:32:41 GMT

一、持续几天都是30摄氏度以上的高温。上海的朋友说，那边现在很凉爽，不超过30度。

二、室内太热，又没有空调，自己找到解暑的办法。拿来盛酸牛奶的塑料袋洗净装满水，放在冰箱的冷冻室内冻成冰袋。用时取出几个放在桌子上。溶化后再拿到冰箱冷冻室里冻上。效果有一点但是不显著。打电话给老妈解释自己的解暑办法，古时皇帝避暑即用此办法，把在冬天储存于冰窖中的冰块盛夏拿出消暑，我现在的待遇和皇上差不多。老妈听后笑。

三、电脑速度奇慢，进行了系统优化、查杀毒、停止运行不必要的服务进程。但是仍然不能解决问题。后来发现稳压电源和主机箱CPU部位超烫。找了个SpeedFan的免费软件实时监控电脑体温，在系统很慢时的CPU温度达到了近90度。天气热让我的电脑也受不了了。现有的CPU散热风扇和稳压电源风扇只适合冬天，它们老化得已经不能胜任高温工作了。改日换了它们。

四、早晨被窗外马路边的电钻声吵醒，一看时间才刚到7点。马路对面一个建筑工地，以前都早九晚五的，这几天工人也怕热，大大提前了上班的时间，似乎把一些高强度的工作放在早晨去做，已经持续好几天了。感觉北京就是这个样子，无论到哪里都有建筑工地，都有噪音。

五、写这篇文字时，天地昏黄，象极了沙尘暴的天气。似乎要下雨了。希望下一场暴雨。

《300壮士》观后

Thu, 17 May 2007 12:57:15 GMT

一、美丽的画面。几乎每一个画面静止下来就可以成为一幅中油画。其颜色都是以暗色调为主。唯一鲜艳的颜色就是300壮士的暗红色的披风，在任何时候都能突出他们在电影画面中的主体位置。300个斯巴达勇士无一不体形健美犹甚于米开朗基罗手下的英雄大卫。该故事取材于一部漫画作品，导演及相关创作人员可能深受漫画的画面感影响吧。但是这些美仑美奂的画面串成连续的画面后总有MTV的效果。

二、这是部血腥的电影。单从电影标题那血淋淋的300字样也可以看出一二。感觉上似乎导演为降低血腥程度做了些努力。比如电影画面的色调处理上。在任何血肉横飞的场景中，你能看到的唯一的血红色就是300个勇士披风，飞溅的鲜血都被处理成暗黑色。但是仍然有些镜头很暴力。比如片中一场景，敌军一骑快马偷袭，一刀将一战士人头劈于马下。如果你是看《三国演义》这样描写可能会不以为然，但在这部影片中几乎没有怎么切换镜头全景展现，即使你看惯了《三国演义》中类似的场景，亲眼目睹电影呈现这样的景象时还是会头皮发麻的。电影在美国被分级为R级也就自然了。这也提醒你想和亲朋好友一起看这部片子时得选择合适的人。

三、这部大片取材于漫画，漫画取材于希腊历史。很自然有人想到了国内大片取材问题，为什么国内的大片不会从我们国家的丰富的历史资料中汲取素材呢。有一个与该片情节相近的一段中国历史被人从《资治通鉴》中挖了出来：“耿恭以单兵固守孤城，当匈奴之冲，对数万之众，连月逾年，心力困尽。凿山为井，煮弩为粮，出于万死无一生之望。前后杀伤丑虏数千百计，卒全忠勇，不为大汉耻。”这事拿出来说无妨，如果真有某导演要拍，恐怕会有很多局限。美国人拍斯巴达的勇士不是着眼于其爱国的精神，而是其为追求自由独立尊严荣誉所表现出的决绝的气概。如果我们要拍这样的片子，受种种制约恐怕立意有限。不过可以大胆推测一下可能用的立意。一、宏扬爱的力量，完全可以讲耿恭为了爱孤军奋斗，至于为了什么爱，编剧可以思考；二、为了和平，部分思想可参见《英雄》，由于最终为耿恭的爱好和平的执着精神感动，最终匈奴将领领悟到了和平的珍贵而退兵。暂时想到两则，其它大家可以放开去想其它立意。不过必须以最终拍出的片子能通过审核而且是宏扬主旋律方可。

Google谷歌拼音输入法还是搜狗拼音输入法的思考

Fri, 06 Apr 2007 08:22:49 GMT

这个标题让人感觉是在做输入法的推荐，其实不是，只是看到近期Google谷歌拼音输入法和搜狗拼音输入法打口水仗打的不可开交，然后我就想着凑个热闹。

关于此事有几点看法：

一、就本质而言这并不是单纯因抄袭的问题而引发的争论，严格说起来谁能保证搜狐拼音的词库就是百分百原创的？这其实是利益之争。从Google趋势上看紫光拼音等几款输入法比搜狗热门的多，但是搜狗与之井水不犯河水。但是在谷歌输入法刚一出现，搜狐反应如此强烈，说明了这样的一个事实：紫光拼音只是开发方的单一产品，并且难以象搜狗拼音输入法能在培育用户群的同时，借助门户网络的优势开发出衍生的新生品。就网络优势而言紫光输入法的竞争力对搜狐而言不值一提。可以想象，免费的搜狗拼音输入法在搜狐未来的发展战略上有其重要位置。但是现阶段仅是培育用户群阶段，远未到其收获季节。在这个时候谷歌输入法出现了，这是一个拥有强大网络流量优势的公司，在未来发展中，必然与搜狐的战略存在很多交叉点。搜狐肯定会感觉自己的生存空间被压缩了。就此推测，这种争论背后隐藏着深刻的利益。与抄袭无关。

二、双方危机公关的思考。搜狐面临强大对手推出的与自己产品同质化程度很高的产品时，他目前出手的第一招就是指责对方抄袭。现阶段在互联网的环境下，很多产权都很难得到保护，抄袭复制是常态，尤其是技术含量不高易复制的东西。因此谁也不能说谁绝对干净。搜狐这样的企业面对竞争对手时所采用的手段应该是我们国家互联网企业的通行做法，就是打口水仗，互相指责对手，贬低对手。这并不是独搜狐为然。但是这种竞争的层次实在太低了。因为目前只看到搜狐的各种言论均是这种口水，所以这很只是第一招。我很希望看到搜狐在面对谷歌这样的对手下一步的应对手段，也就是第二招。如果要上升到法庭上论高下的话这还是中国国情下口水仗的延续升级版，还是属于第一招。我更期待搜狐应对的第二招是什么。在互联网上创业，谁都可能会遇到来自对手开发的功能相同产品的竞争，甚或复制。如果搜狐第二招成功应对，这真是我们大家学习的活教材。
谷歌方面对此事处理的很低调，我没有看到任何他们有关此事的回应。我倒觉的他们这么做很高明。因为抄袭辩解很难说清除，而且从搜狐方面提供的证据看，即使不是百分之百挪用了搜狗的词库，估计也借用了不少。但是真要辩论起来，无论谷歌是胜或是负都不光彩。还记得那句话吗：和狗打架，打赢了你比狗强；打平了，你和狗差不多；打输了，你连狗都不如。明智的处理办法就是不和狗打架。

三、关于两种输入法的未来。在搜狗拼音输入法出来以后，我在推荐输入法时一般是推荐搜狗拼音输入法。但是现在多了一个谷歌拼音输入法，我虽然极少用拼音输入法，但是我会推荐谷歌。原因有几点，在隐私保护上我更相信国外公司而不是国内公司，这不是一个支持国货的问题；其次Google是一家很有创意的公司，会不断给我提供更多免费的便利(插一句：本文特别写明是谷歌输入法，其实旨在强调国内的谷歌并不能等同于Google，这其实也是官方的叫法，但是谷歌仍然保持着Google的余威)；再次谷歌拼音确实有很多亮点，比如用户个性化的词库可以同步到服务器上，这样在任何地方都可以按自己习惯的词汇打字。因此搜狗拼音如果应对不好的话，这不仅会严重挫伤搜狗拼音开发者的积极性，而且这个产品可能会就截止到2.0版就止步了。真是很关心搜狐下一步如何出牌。这也同样说明了一件事，选择一个产品如果不能迅速突破领先对手，那么也要慎重选择实力比自己强的巨头可能染指的产品项目。

四、关于潜在竞争对手的思考。在市场研究方面，明显搜狐对可能出现的潜在竞争对手的情况估计不足。另一方面可能也说明谷歌的保密工作做的很好。谷歌拼音输入法是前天即4月4日推出的，但是实际上有关谷歌要出输入法的言论早在半个月前就有了，甚至有人在更早的时候出了一张照片来证明此事。但这似乎都没有引起搜狐市场部门的注意，而且如果搜狐市场人员如果能及早获取到这些信息的话，这应该会对搜狗拼音以后发展调整提供很多时间。如果在立项时，充分分析已经存在和潜在可能的对手的情况，也许会好很多。

在指责对手抄袭之后，现在搜狐也在进行着其它的活动，比如现在出现了大量有关两者评测指导的文章。搜狐也许想尽量让更多的人认识到搜狗拼音输入法的优势吧。如果市场部门洞察先机，及早做这样的宣传和普及工作，成本应该会比现危机处理方式节省的多。不过不好意思，这成本的想法是我想象的。

Yahoo!免费邮箱支持客户端收发邮件了

Thu, 05 Apr 2007 10:52:07 GMT

有段时间是通过Foxmail的本地的Web收邮件代理来收取信件，这个代理很不稳定，很长一段时间以来无法收取邮件，只能用浏览器登录邮箱收发邮件。Yahoo!的帮助说明也提到只有收费用户才可以享有用客户端收发邮件的便利。不过今天确实能通过foxmail收信了，而且是用的是pop3服务器。检查了一下其官方网站的帮助说明，仍然说的是pop3和smtp服务仅提供给收费用户。感觉上似乎是Yahoo! Mail在Beta测试期的临时行为，不过还要观察一段时间。

Yahoo!开通这项服务显得非常低调，没有看到任何资料的宣传。似乎也是在悄悄积攒力量以应对Gmail。

据说yahoo.com.cn的邮箱是可以用pop3服务的，但是yahoo.com的邮箱却不可以。不明白yahoo!这样的用意是什么，因为感觉上在互联网服务这一块，一般而言，是国外的免费服务更多些，而国内相对来说可供选择的免费服务少些。比如Gmail在测试时最先开始的是欧美、日本等，中国要落后一步。包括Google现在某些服务也是如此，比如Google Video服务，国内用户就无法享用。但在Yahoo!邮箱服务上却反其道而行之。也许这是雅虎中国在“高度自治化”的前提下自己进行的所谓的“本地化”的操作步骤。却背离了Yahoo!总部的pop3、smtp服务要收费的想法。不过经过了这么久，电子邮箱新模式的出现，也许Yahoo!也开始转变他的思维方式吧。

附：我的yahoo!邮箱的相关设置。smtp服务器：smtp.mail.yahoo.com，pop3服务器：pop.mail.yahoo.com

2006年个人总结

Wed, 10 Jan 2007 17:17:46 GMT

　　2005年写的总结《年终纪事》的那段日子里，是情感和现实矛盾最尖锐的时候，思考的问题很多。在事件过去大半年后的某些文字里仍然流露出悲观的情绪。现在翻看那段日子的文字，还能想起那些很久的记忆。

　　对我而言，2006年的一个重要关键词就是“放弃”。这一年里我放弃了很多东西，放弃既有的，不再挽留难以强求的。几乎断绝了所有亲人、同事、朋友间的往来，只维持着少数几个人的联系。放弃每样东西，内心都要挣扎许久。不管心境如何，这是个人的一种情感经历，并不想因此影响别人。始终控制自己，在任何时候都要表现出乐观开心的心情，并且以这种情绪感染他人。

　　一个收获，认识了自己。一个人有充分时间独处时面对最大的困难是和自己相处。我有两个自己，做很多决定时，这两个“自已”都在反复较量，都在彼此试图说服另一个“自己”。所以2006年里内心总是处在一种挣扎的状态，做每一个决定都很艰难。不过在这其中，我得以反复审视自己，比以往的任何时候都更清晰的认识了自己，也比以往任何时候明确了自己的方向。似乎我比其它人花了更长的时间来认识自己，感觉自己比别人晚熟。

　　另外说下一年里被触动的几件小事：
　　在2006年3月份的时候知道一个朋友有朋友了。之前一直以为自己已经不在乎了。
　　5月份时对互联网有了全新的认识，自己很开心，似乎以后的很多的灵性的想法都源于这个认识。
　　在6月因什么事按捺不住自己的情绪与家人治气，晚上一个人躺在床上，想了一圈不知道给谁打电话聊天，从没有的孤独。
　　8月，街上碰到一个有五六年没有联系过的同事，开着车载着他的家人强邀我一同吃饭。席间很沉闷，感觉无话可说。就这样看着他们一家其乐融融。
　　8月，写了篇北京网通ADSL强迫性广告方式初探，受到多方关注。
　　10月，大学同学校庆北京聚会会餐，借口回上海未去。
　　12月，也是一个久未谋面的朋友打电话过来，问到这段时间在忙什么。虽然我竭力希望别人能认同的我的梦想，但自己与他的现实环境差别如此之大，我不知道我如何对他解释明白我的梦想。2007这应该不是个问题了。

　　2007年是农历猪年，除了希望事业顺利外，也祝心情快乐.

地震之后

Wed, 03 Jan 2007 08:23:46 GMT

　　2006-12-26晚间台南地震，一震惊天下。国内网络陷入信息孤岛状态。对这一突发事件业内表现各有不同。

　　直接影响是MSN不能访问，从我的经验看，在27日早晨9点前可以访问，但之后无法访问（可能正是上班时间上网人数陡然增多，导致仅有的出口带宽被堵塞），在当天晚上MSN可以上线，以后几天表现尚可，但时不时出现登录失败的情况，而且在线好友数量比平时有所减少。在发布本文时，我的MSN仍然不能正常登录，只好采用代理服务器登录进来。

　　令人惊讶的是，在众多国外网站服务不能访问的时候，Google的相关服务仍然能访问，GTalk也使用正常。原来Google与国内部分电信运营商合作，购买3-4G带宽做为数据转发，避免此次断网造成的影响。在这次危机应变中，可以看出Google的应变能力，比之于微软高下立判。

　　本来这事对国外网站影响很大，但似乎这也影响到了腾讯QQ，MSN大面积瘫痪，许多商务人士现转向QQ，如此成绩腾讯应该在偷笑了。但是没想到在12月28日QQ也遇到了不能访问的问题，虽然公告中说明是因为机房的电源故障，但是海底光缆断开这件事相隔如此之近由不得我做出这样的分析：因msn不能访问导致QQ同时在线用户激增，腾讯的部分服务器出现了负载过高的情况，是这个原因造成了部分QQ不能登录的情况。历史上腾讯公司有过多次以机房电源为由来解释QQ不能访问的记录的，看这里，还有这里。腾讯应该考虑改善自己机房供电问题了，希望下次QQ出现不能访问时不再是这个原因。

　　在12月29日，在各方尚未提及索赔问题时，著名电信专家、北京邮电大学经济管理学院博士生导师曾剑秋（原文引）认为地震属不可抗力运营商无需赔偿。有意思的是在同一天中国台湾的中华电信说将免去网络中断用户该月的网络费。对这次我无法判定曾博士的言论是否适当，但是从今年9月份新网被黑造成大量用户网站不能访问，新网对用户损失的态度中已经可以看出，想让这个行业的大企业在这些突发情况下做出赔偿是不太可能的事。所以曾教授完全没必要进行“不可抗力”的高端说明来论证不赔偿的合理性。

孤独的墨者－《墨攻》

Fri, 29 Dec 2006 09:29:59 GMT

　　城门外，远处，无边的蓝天黄土，一个人影在行走，芒鞋粗衫。城门上喊：“来者何人！”，行者撩起斗篷，抬起头，露出杂乱的胡须和一脸仆仆的风尘，站定脚步朗声道：“墨者革离”。

　　这是《墨攻》开局墨者出现的场景，我看到墨者那份装扮时，不由的想到了星球大战中的Jedi武士。

　　中学有篇课文《公输》，提到了墨家的“兼爱非攻”的思想。墨子听说楚国准备攻宋，他应该是认为这是不正义的战争，所以“非攻”，从齐国出发走了十天十夜才到达楚，说服楚王放弃攻宋，并与楚国制作攻城云梯的巧匠公输盘切磋攻防技巧，迫使公输盘认输。我记得当时我还写了篇议论文来论证墨子说服楚国的逻辑是有问题的。不过现在认真回想这件事时，觉的在那样的一个时代，墨子为了自己“兼爱”的理想，花很长时间走很远的路去说服别人不要攻打一个他自己毫不相干的国家，而且为防万一还派自己的弟子禽滑厘去帮助防守宋国，真是一个伟大的人。墨子在说服楚王后返回途经宋国，又逢下雨，去闾门避雨居然被拒。《墨攻》的思想情节应该有很多来源于《公输》这篇文章。

　　墨家学说把战争分为正义和非正义两方，非正义的叫“攻”，所以墨家主张“非攻”，同时墨家也承认正义的战争。墨子认为人们应该“兼受”、“非攻”才消除自身的苦难实现天下大同。墨家弟子不同于其它同时代的诸子百家，他们不依附于任何一个国家君主来推行自己的思想。他们只是每个人身体力行，奔波各国间推行自己的思想。

　　战争是有双面性的，墨家竭力将战争清晰的分成正义和非正义双方，但实际上却很难。《墨攻》中革离改造了箭头，使箭的射程大大增加帮助梁国打击了赵军，但同样这种箭被梁国用在了追杀他，差点让他丧命。革离用水攻逼退赵军，但同样是这水也淹死了自己的爱人。也许革离想通过防守制止赵军来防止更多的杀戮，但实际上并没有防止，不是杀赵人就是杀梁人。你还能说谁是正义的？

　　没有一个国家君主真正想推行墨家的和平思想，只是把他们作为一种应急的工具，而墨家也许想通过帮助各个弱小国家抵抗外侮的方式赢得他们对自己的思想的支持，但是结果并不能如他们所愿。片尾革离带着梁城战后的几个孤儿又走在了蓝天黄土间。乱世之中，虽然墨者很孤独，但他们仍然坚守理想，片中这个结尾的寓意应该是，他们要把这些思想通过下一代传承下去。

多多小虫 天行健: Blog