多多小虫 天行健

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

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点多了啊。不敢想象的是在明天天亮时广场人流量该多大啊。实在不敢出来了。