遇到了这样的设置场景，小结一下。

IIS 7.0 下对指定网站限制IP访问的设置：

一、选中“网站”下的指定网站

二、点选IIS中间栏功能视图部分内的“IPv4地址和域限制”。

三、比如这里只限制IP“192.168.0.1”能访问网站，则可点击IIS右侧操作视图中“添加允许条目”。根据要求填写指定的IP地址，确认即可。

四、以上设置完成后，在实测时可以发现并未实际生效，还需要在右侧操作视图中选择“编辑功能设置”，设定“未指定的客户端访问权限”为“拒绝”。确认后可生效。

此时访问指定的网站，如果浏览器所在客户机IP不是“192.168.0.1”，那么看到的就是拒绝访问的406.3出错页面。其效果很吓人，很可能会让人误以为网站出了什么严重的问题，这时就需要给访问者很友好的提示信息以改善用户体验，这就需要对系统的错误页面进行自定义。

一、选中IIS管理器“网站”下的指定网站

二、点选中栏功能视图中的“错误页”

三、点击右侧操作视图中的“添加”。在弹出的对话框中“状态码”项输入“403.6”，“响应操作”中可根据情况指向自定义的错误页面。

需要注意的是，如果已经配置了“为本地和远程请求返回的详细错误信息”，系统不会返回使用自定义的错误信息页面。要在“错误页”右侧操作视图的“编辑功能设置”中选择“自定义错误页”。这样做后对网站页面调试比较麻烦，不容易看到详细的错误信息了。

3月初博文视点的徐定翔编辑告诉我说翻译可在Google Sites协作平台上进行，当时就想Google Sites原来还可以这样用。不过使用它确实省了许多沟通上的麻烦，因此我对这次协作体验印象非常深刻……

翻译前，我搭建了书中要求的系统环境，并且尽可能测试翻译中遇到的每个示例，同时在可能的情况下阅读书中建议的外部资料。这对理解原文很有效，同时还能纠正一些原文中的小错误。比如，原书第12章中曾引用了微软IIS团队所维护网站的几个链接实际却不存在，这极有可能与网站改版调整了链接形式有关。在O’Reilly网站上提出该问题后，很快就得到了回应，根据官方的勘误我修正了这个错误。O’Reilly响应颇为及时，在我写这篇序时我所提交的大部分勘误建议都得到了反馈。因此可以说，我所翻译的中文版内容已经修正了英文版书中所有已知的错误。

为求证某个专用词汇的准确译法，我常去MSDN中文版页面海量文档中检索相关信息。在第13章遇到过一个词“Breadcrumb”，如果直接用“面包屑”来翻译，肯定会有很多人对上下文意思不知所云。在寻找了一些资料后也终于理解了作者为什么要用这个词，但是我就是在中文中找不到对应的词语来翻译它。我想这应该就是文化背景差异造成的吧。这个词的典故就出现在西方儿童的睡前故事中，他们只要一见到这个词就能明白作者想要表达的意思。但是我在向身边朋友求助帮忙翻译这个词时，需要费很多口舌才能让他们明白。最后经过反复思量译成了“面包屑导航”，至少看到这个译法能让大家知道这是一种特定的导航类型了。就是看起来这么简单的事也让我折腾了很久，翻译真是件辛苦的事。但是只要能让大家理解原文所传达的意思，辛苦也就不算什么了。

老实说，我对自己的翻译原本还是很自信的，但是当看到审校的文档中批注纵横时，不禁有点吃惊，原来还是存在很多错误的。在此对负责审校我的译稿的覃彬彬表示感谢。

3月下旬ASP.NET MVC 1.0正式版发布，当得到这个消息时我正在翻译中。但是这本介绍ASP.NET的书并没有一章专门的篇幅来介绍MVC这种将成为主流的开发技术。在本书作者成书之时，对于尚未定型的产品确实不方便多说。我理解这一点，不过这种无可奈何的事情多少让我感到有些遗憾。

有个朋友翻了翻样书问：书皮上印的是什么东东？我竟不知道如何回答，翻译了这么久却没细想过这个问题。为此，我去找了些资料研究了一下，总算了解了一些情况，O’Reilly的书似乎从很久前就开始用各种动物图片做封面，本书所用的动物形象是一种形似吉他的犁头鳐（Guitarfish）。至于该动物与本书内容有什么联系，则始终没有看到相关资料说明。根据O’Reilly曾经的说法，采用动物做封面外观是根据读者的评论。 自己的调查，以及分销渠道反馈的意见，也只是为了给枯燥无趣的技术书籍带来些生气。查阅这些资料的同时也注意到另一个有趣的事实：从本书的第一版到第四版都采用了相同的动物形象，前三版说明中都声称这是一种叫刺鳐（Stingray）的鱼，可是到本版时被改称为犁头鳐。这应该是O’Reilly公司犯的一个错误吧。翻译中遇到这样的事，也蛮好玩的。

将翻译过程中的一鳞半爪罗列于此，作为序。

邹建强
2009年7月11日于北京

------------------

后记：现在Google Sites服务国内已经不能访问

这是应CSDN《程序员》杂志编辑邀请写的命题作文，前几天刚看看到五月份的刊物，只刊载了前半部分，后半部分将会在六月刊上出现。因为杂志还没有把原文全部刊出发行，应编辑要求我就暂时不把原文放在博客中了，这里只给出这Yahoo!优化20条规则的标题，每条规则后的方括号是指具体属于什么类别的优化。

一、尽早清除缓冲区 [服务器端]
二、使用 GET 方法的AJAX请求 [服务器端]
三、后加载组件    [页面内容]
四、预加载组件    [页面内容]
五、减少 DOM 元素数量    [页面内容]
六、分隔组件到多个域中    [页面内容]
七、尽量减少 HTML 标签 iframe 的使用数    [页面内容]
八、避免404页面    [页面内容]
九、减少 cookie 大小 [cookie]
十、将组件存放在无cookie的域 [cookie]
十一、尽力减少对 DOM 的访问 [JavaScript]
十二、开发智能的事件处理程序 [JavaScript]
十三、使用 <link> 标签来导入样式文件，不要使用 @import 导入 [css]
十四、避免使用css滤镜 [css]
十五、优化图片 [图片]
十六、优化 CSS sprites [图片]
十七、不要在 HTML 中缩放图片 [图片]
十八、让 favicon.ico 文件减少大小并且可缓存 [图片]
十九、保持组件大小在25K以下 [手机]
二十、将组件打包合并到一个 Multipart结构的文档中 [手机]

现在Yahoo!的优化规则加上早先的14条已经累计有34条了。

一个月前，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!是不明智的。就我而言，也很难把微软和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

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

两台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）等等

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

这次年会赞助商中最成功的恐怕是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新近在提供了的好友添加方式。尝试添加了一批好友，很容易，不过需要对方确认。这是延用了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用户而言不能维护一个统一的好友圈子，却要维护两个好友圈子，这是怎么设计的？

总之，没看明白。

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

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

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

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

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

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

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

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

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

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

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

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

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

有消息说微软将以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调用，以吸引投资人的注意。

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

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

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

这是在上台阶上拍的

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

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

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

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

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

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

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

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):没注意到，原来新浪已经公布了博客作者广告分成办法。

最近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，这个功能仍然是无能为力的，只能说这个属性有用，但作用有限。

最初没打算要参加这个聚会，因为我不是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是一款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没有关系，但是珊瑚虫肯定出问题了，其主页这几天已经无法打开。

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

在翻译《为什么选择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小组内部的任何情况时请不要妄做评价，比如“看起来象一个绝望者”。

认真的选择一个自己合用的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”工具，可以根据你开发中所需要的功能，把相应的代码文件打包在一起。

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

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

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

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

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