about:blank

Change the world in a small way...

小飞 — Sun, 19 Apr 2009 06:03:00 GMT

最近，由《编程之美-微软技术面试心得》一书稿酬所捐建的第一个机房在福建省漳平一中正式投入使用了！

一个月前，《编程之美》编写小组向漳平一中捐赠了第一笔稿酬，共计16000元整。随后我们又向湖北省五峰县一中捐赠了一笔同样数额的稿酬。一个月来，漳平一中经过公开招标，用这笔钱购买了第一批5台计算机，并将发票寄给了我们。然后又开辟了一个房间安装这些计算机，做为编程兴趣小组的专用机房，并于近日正式投入使用了。从此，编程兴趣小组的同学们就有了专用机房，可以专心地练习编程了。

我们每个人都很平凡，也许一辈子都做不出什么惊天地泣鬼神的大事来，但是，我们依然可以通过努力，踏踏实实地做一些事情，来改变这个世界一点点…漳平一中编程兴趣小组的指导教师李超老师，他之前摔伤了腿行动不方便，为了布置好这个机房还不辞辛劳地奔忙。不光是他，还有博文视点的杨绣国编辑和周筠老师，以及漳平一中多位为促成此事而辛勤工作的老师们，没有他们的无私付出，我们这份微不足道的稿酬也就无法顺利地实现它应有的价值：在鼓励经济欠发达地区计算机教育方面发挥它最大的作用。因此，当我们在为同学们用上新电脑学习编程而由衷地感到高兴的同时，也要对这些为促成此善举而默默付出的人们表达诚挚的感谢。我们并非无所不能，但正所谓“勿以善小而不为”，只要我们每个人都付出一点点，就能改变世界一点点。

一周前，我正式加入了浏览器制造商Opera公司，这是我的第一份工作，我也希望自己能通过辛勤工作，为产品发布贡献力量，藉此改变浏览器之战的历史一点点…

《编程之美》编写小组的第一笔捐赠

小飞 — Mon, 16 Mar 2009 09:55:00 GMT

最近，福建省漳平一中收到了由《编程之美-微软技术面试心得》编写小组捐赠的第一笔稿酬，共计16000元，这笔钱将用于购买计算机，供编程兴趣小组的同学们作为信息技术竞赛培训之用。这也是从《编程之美》稿酬中捐出的第一笔善款，今后我们还将根据此次捐赠的反馈效果，制定进一步的捐赠计划。

《编程之美》一书自去年3月出版以来销量就一直不错，在博文视点公司的大力推广以及广大热心读者的支持下，获得了：

等种种殊荣。我们几位编者看到自己的劳动成果能被大家所接受，都由衷地感到高兴。然而，随之而来的问题是，我们该如何处理这笔稿酬呢？这时，邹欣老师提议把稿酬都捐赠出去，用于鼓励和支持中学生学习计算机编程知识，这一提议立刻得到了所有编者的一致认同。

作为一个从不发达的山区小县城走出来的编程爱好者，我更是高举双手支持。因为我还记得在高一前的那个暑假初次接触计算机编程时，学校里那个要脱鞋才能进的机房，那些破旧的无盘486工作站，机箱上还有个Turbo按钮，按下去之后，似乎Turbo Pascal的编译速度都会变快一些...更让我记忆犹新的是，那时自己对上机、对敲击键盘和调试程序的渴望，有限的上机机会显得是那么弥足珍贵...从自身的经历出发，我们相信直到今天，在一些经济欠发达地区仍然有许多对计算机技术抱有无限热情和兴趣的学生，因为缺乏上机条件而苦恼。也许，我们可以做些事情来改变这种状况一点点...

经过几次邮件讨论，我们达成了如下捐赠宗旨：我们捐赠的目的是让这份微不足道的稿酬能在鼓励经济欠发达地区计算机教育方面发挥它最大的作用。
基于这个宗旨，我们将从以下几个方面来寻找捐赠对象：

经济欠发达地区和缺乏计算机教学资源的学校是前提之一。
我们会考虑这些计算机是否能在一段时间内发挥它最大的作用，把这些计算机送到最迫切需要它们的人手里才能体现出最大的价值。
由于我们只是捐赠计算机，学校必须有能力自己组织师资力量来维护硬件、教授计算机使用和编程知识。我们坚决反对将捐赠的计算机当成摆设品和宣传的噱头。

不久，在我和博文视点编辑的牵线搭桥下，福建省漳平一中和湖北省五峰县一中最早与我们取得了联系。大家在对学校情况深入了解之后一致决定，将这两所中学选定为第一批捐赠对象。其中，漳平一中的老师过去几年里在缺乏足够的教学资源，尤其缺少专用的计算机供编程兴趣小组进行竞赛训练的情况下，仍然坚持培养学生参加信息学奥林匹克竞赛，也取得了一些不俗的成绩，我们相信这次捐赠的计算机能极大改善他们的上机条件，并让他们在今后的竞赛中取得更好的成绩。

然而，我们也都知道全国有许多更贫困而且需要帮助的学校，它们最迫切需要的也许不是计算机，而是最基本的学费、课本、文具、教师等。我们的力量其实微不足道，只能尽自己的绵薄之力帮助其中一小部分迫切需要计算机资源，同时能将这些资源发挥最大作用的学校。更多的帮助，需要全社会的共同关注，需要每一位有爱心的人伸出援手。

我们对第一批选择的这两所学校是进行分期捐赠的，期间会不断通过校方反馈的捐赠效果来及时调整我们的捐赠策略和方法，甚至决定是否中止捐赠，我们会将这些反馈通过不同渠道公布出来。同时，我们也鼓励热心读者提供一些迫切需要计算机资源的学校信息，我们希望能与校方直接联系商谈，如果情况属实，我们会在力所能及的范围内提供最大的帮助。

捐赠计算机的具体使用是学校的自由，之前提到的捐赠宗旨已经明白无误地表达了我们的价值观，只要不违反这个最基本的原则，我们不会强加任何意志给受捐赠的学校。

面试趣题1：求不连续子数组最大和的值

小飞 — Sun, 28 Dec 2008 17:18:00 GMT

《编程之美》一书上有一道题：给定一个由N个整数元素组成数组a，写一个函数在其中找出连续子数组和的最大值。例如给定数组为{1, -2, 3, 5, -1, 2}，则和最大的连续子数组是{3, 5, -1, 2}，函数返回值是9。这是一道典型的动态规划问题，书中循序渐进地通过分析给出了一个时间复杂度为O(N)空间复杂度为O(1)的最优解。我在面试时碰到了这道题的一道有趣变体，即同样给定一个数组，写一个在其中找出不连续子数组和的最大值，也就是说子数组里的任意相邻的两个元素，在原数组里都必须是不相邻的才行。同样以数组{1, -2, 3, 5, -1, 2}为例，则和最大的不连续子数组是{1, 5, 2}，函数返回值是8。

显然，最直接的思路我们可以采用穷举法，对于此类寻找符合条件的子数组的问题，无非就是对原数组上每位元素是否属于子数组做一次遍历判断。由于每位元素都有属于和不属于子数组两种可能性，那么穷举的时间复杂度为O(2^N)。即使考虑“不连续”这个限制条件，即某位元素被选中属于子数组后，则其相邻元素就一定不能被选中，也对时间复杂度的数量级不会有太多影响。因此很明显，这绝对是个愚蠢的答案……

从《编程之美》一题中得到启发，我们是不是也可以用动态规划的方法来解这道题呢？假设从原数组a第i位开始的最大不连续子数组和为m[ i ]，那么它的值有两种可能，一种是当前元素a[ i ]与隔一位上子问题解m[ i+2 ]之和（由不连续性质决定），另一种是不包含当前元素而直接等于前一位上子问题解m[ i+1 ]，那么我们可以写出递推公式为：m[ i ] = max(a[ i ] + m[ i+2 ], m[ i+1 ])。

等等，也许你要说，好像这个递推式有漏洞啊，因为前一位上的解m[ i+1 ]本身就有可能是包含或不包含a[ i+1 ]，假如m[ i+1 ]不包含a[ i+1 ]，那么岂不是还要考虑a[ i ]+m[ i+1 ]这种可能性呢？

这个递推式真的经不起推敲吗？我们不妨重新整理一下思路：由于原数组上每一元素都有取与不取两种可能，那么也就对应有包含和不包含该元素的两个子数组的最大和。对于原数组a中第i位上的元素，假设包含a[ i ]元素的子数组最大和为s[ i ]，而不包含元素a[ i ]的子数组最大和为ns[ i ]，因此所要求的不连续子数组最大和m[ i ] = max(s[ i ], ns[ i ])。那么根据题意我们可以整理出递推关系如下：

s[ i ] = max(a[ i ] + ns[ i+1 ], a[ i ] + m[ i+2 ])

ns[ i ] = m[ i+1 ]

m[ i ] = max(a[ i ] + ns[ i+1 ], a[ i ] + m[ i+2 ], m[ i+1 ])

有趣的地方在于ns[ i ] = m[ i+1 ]这一项上，根据它我们可以得到ns[ i+1 ] = m(i+2)，也就是说假如m[ i+1 ]不包含a[ i+1 ]的话，那么它一定等于m[ i+2 ]，所以a[ i ]+ns[ i+1 ]等价于a[ i ] + m[ i+2 ]，递推式m[ i ] = max(a[ i ] + m[ i+2 ], m[ i+1 ])是正确的！

从《编程之美》给出的解法中得到启发，我们也只需要使用两个变量来记录m[ i+2 ]和m[ i+1 ]的值就行了，而且同样只需要O(N)的复杂度就可以解这道题，代码如下：

int maxsum(int* a, int n)
{
    int m2 = 0;
    int m1 = a[ n-1 ];
    for(int i = n - 2; i >= 0; i--)
    {
        if(m2 < 0) m2 = 0; //处理最后一位为负数或全为负数的情况
        int tmp = m1;
        m1 = max(a[ i ] + m2, m1);
        m2 = tmp;
    }
    return m1;
}

对如何防止"过度设计"的一点拙见

小飞 — Wed, 28 May 2008 13:40:00 GMT

软件工程, 唯一不变的是变化. -- p41, <移山之道>

"永远在变化"让回答"如何界定过度设计"这一问题变得非常困难, 因为在真正的需求来临前, 你无法确信这是否一定是过度的设计. 但是避免"过度设计"还是可以做到的, 根据我在"移山公司"中有限的软件开发经验, 首先, 我们在需求阶段会进行更精确客观的预估计. 在前期需求分析和设计阶段, 软件采用何种技术, 什么架构, 具有哪些feature, feature都要怎么实现, 开发schedule制订, 都必须综合考虑开发团队的真实水平, 过往的经验和教训, 项目实际需求等客观条件进行比较精确的预估计, 而不是主观地过分追求新潮技术, 以老板或客户开心为目的制订时间表, 对客户不精确的需求描述想当然地制订feature, 对每个feature事无巨细地连函数和变量名都设计好...相信我, 虽然这些一开始看上去会让大家都感觉到很美好, 但是项目蜜月期一过, 这些立刻会成为大家无穷无尽的烦恼源泉. 其次, 我们必须对可能的需求变更这一风险做好准备. 不要奢望用户一开始就会把需求讲清楚, 而且你真正理解了他们的需求. 如果一开始就意识到需求变更的风险是必然存在的, 那么在设计阶段就应该做出某些应对的策略. 特别是在架构和工作流逻辑的设计时, 就应该令其能够应对某种程度的变更. 制订schedule时留好buffer, 对含混不清的需求不做想当然的设计. 甚至, 在过去项目中"过度设计"的教训, 也能够成为避免再次犯错的绝佳参考.

但是正所谓"人算不如天算", 之前提到的两种应对"过度设计"的策略也是被动的"兵来将挡, 水来土掩". 所以我们的领导阿超最常说的一句话是: "既然软件开发中的'变数'是永远存在的, 那么何必寄奢望于一开始就能够将所有的可能性都考虑在内呢? 还不如轻装上阵, 随机应变."

MSF原则之(6): 保持敏捷, 预期变化. (Stay agile, expect change) -- p30, <移山之道>

不要让所谓"制订好"的开发计划, 设计文档, 技术架构等成为束缚, 而要根据不断变更的需求对其作出持续的改进. 项目管理者的职责不是说在项目前期就把一切都谋划好, 然后接下来就是持续不断地赶着开发人员按照"规定"的进度完成任务而已. 在开发过程中, 管理者要审时度势不断作出一些决策, 这些决策往往需要很痛苦地改变我们已经"制订好"的设计和进度计划(换句话说, 既然改变这么痛苦, 何必一开始就做得事无巨细呢?). 同时, 他要在"质量"和"不断变化的需求"间做出"折衷"的决定, 既要适应用户"不断变化的需求"又必须保证不能太低的"质量". 为了保证这两点, 所谓的开发进度/实现细节也许每天都会在变, 我们常常要根据当前团队的能力和变化的需求, 合理地裁减feature, 重新安排工作项的优先级, 从而赢得更为合理的时间安排, 让团队把注意力集中在关键功能的质量上. 同时, 在对用户的变更需求说yes之前, 也要好好考虑一下这是否一定是必要的, 及时澄清双方的误解, 让每一次变更都是合理的, 避免绕了一圈回到原地, 做无用功.

对当前项目开发的源起和目的永远保持清醒的认识, 所有的变更都围绕它来做决定. 阿超就常常教导我们在做开发时不妨时常想一想: "我们究竟要做什么? 我们为什么要这么做?". 软件开发就好比是将一车货物(features)从A点运到B点, 在途中, 我们有时会卸下一些货物, 同时换上更有价值的货物, 或者重新包装已有的货物, 从而腾出更多的空闲空间来装载更多货物. 在行进过程中, 我们会遇到不同的路况, 不同的天气, 不同的麻烦, 车子会抛锚, 轮子会爆胎, 路面会有障碍, 有时为了过一条河, 我们甚至得立刻把车改造成潜水艇或者在上面架一座桥. 当最终到达B点时, 车上的货物和出发时比起来已经大不相同了, 但是我们的目的始终只有一个, 那就是能在这一趟运输过程中, 为B点及时运去他们最需要, 而且价值尽可能高的货物. 这肯定不是一趟轻松的旅程, 在出发时, 我们无法预知即将面临的困难, 但是我们会准备两名司机轮流驾驶来防止疲劳(人力), 制订一个粗略的行程计划, 带够前往下一个补给点的水和食物(资源), 准备好备用胎和零件(风险), 盘算好一些B点当前最需要货物(其中一些货物在运到B点之前就会变得一文不值), 把货物捆得结实又容易装卸(这样的架构的确不简单), 并在上面盖好一顶遮雨棚. 然后我们就上路了...在行进过程中, 我们要根据不同的路况采用不同的驾驶策略, 根据手中的食物和水调整行程计划, 根据货物的易碎程度调整它的包装方式和行进速度. 时刻为爆胎和零件修理做好准备. 当发现前面的道路不允许当前车辆通过时, 我们要立刻卸下货物换上另一辆合适的车(工具), 或者, 为什么不抄一条边上的近路呢? 最后, 这会成为一趟长久的旅行, 也是一趟有趣的冒险之旅, 我们饱览了一路的盛景, 也经历了凶险的磨难, 当我们重新启程把货物从B点运到C点时, 我们会变得更加轻车熟路(也许吧).

以上是小飞我在"移山公司"将近一年软件开发经验的总结吧, 一点拙见, 感兴趣的童鞋不妨来这里讨论一下http://yishan.cc/forums/thread/916.aspx

"探索●发现" 周末特别奉献: 寻找<移山之道>

小飞 — Sun, 05 Aug 2007 16:56:00 GMT

两天前, 欣闻关心老师的大作<移山之道>终于在全国隆重上市发行了, 于是趁着周末, 带上相机, 前往中国海淀图书城, 去掂一掂这本书真实的重量 :)

书店远景

书店外景

书店入口

书店全景(手机男站立处即是<移山之道>)

静静地在角落绽放 ;-P

封面特写

封面特写: 两岸bug藏不住, 轻舟已过万重山...

近一年来, 做为一个中肯的建议者和批判的读者, 我算是见证了这本书从最初的想法, 到提纲目录, 再到厚厚的书稿, 直至最后排版印刷出版的整个过程. 我不知道该用什么语言来形容这个漫长的创作过程, 因为除了作者, 也许谁都没有资格来告诉大家这一整个艰辛过程中的点点滴滴, 那些灵感的涌现, 细节的讨论, 主题的修正和改进, 还有对技术细致入微的阐述, 对过程的高屋建瓴的描写, 对人物入目三分的刻画, 以及书稿丢失的沮丧, 还有最终排版成书的喜悦...酸甜苦辣, 我没有资格述说, 从关心老师一贯幽默潇洒的blog文风中看到的也是乐观而充满激情的写作情绪, 但是我又真切地知道这一切其实都很不简单, 我只想在此由衷地祝贺关心老师: "Congratulations! You have done a great job!"

给最后一张照片配上一句话:

褪尽封面的浮华, 内容才是移山之道的精髓!

《移山之道》即将上市, 火热试读中!

小飞 — Thu, 19 Jul 2007 05:32:00 GMT

好消息! 大家引颈期待了这么久, 邹欣老师的作品《移山之道》终于要正式上市了, 迫不及待想要先睹为快的朋友请访问http://book.csdn.net/bookfiles/443/#c1试读部分章节.

好书当然要捧在手里读才有感觉咯, 大家准备好银子抢购吧 :)

Milan! Milan! San AC Milan!

小飞 — Wed, 23 May 2007 21:13:00 GMT

Milan! Milan! San AC Milan!

一场充满悬念的比赛, 戏剧性的进球, 差点重演的绝地反击, 到最后创造历史的的球员们, 这场比赛虽然场面上不甚好看, 但是充满了一切经典比赛需要的所有要素!

关键时刻, 还是要靠睡神, 帅哥, 还有那个能用PP进球的男人...伊包揽鸟Milan所有两个进球, 第一个是接睡神的任意球暴抽用脸蹭进去的(貌似很痛的说, 庆祝时连表情都没有...), 第二个则是过了门将雷纳打身下慢慢滚进去的...其实看那厮几次带球, 那水平真不是一般的菜啊, 基本上接到球就被定在那里了...

Dida上半场扑掉小杰的单刀也是相当关键啊~~

最后pippo刚被换下liverpool就让kuyt顶进了个头球, 心里一沉, 还以为历史悲剧又要重演了, 加上ESPN两个白痴解说在耳边聒噪, 干脆直接关掉声音一直熬到比了赛结束, 还好, Milan最不缺的就是防守妖人, 玩5CB+2DMF神仙都难进球.

马大帅作为milan的精神领袖和历史性球员, 真是太幸福了!

太兴奋了, 白天睡觉都会笑, 嘿嘿!

ps: 肥罗这张照片狂像丹泽尔.华盛顿啊~~http://sports.163.com/photo/00BV0005/18669_2.html

Yishan, It's about time!

小飞 — Wed, 23 May 2007 11:14:00 GMT

闲来无事, fix了在firefox下几处显示不正常的样式表, 顺手在首页上加了个到7月3号的count down timer, 关心老师辛苦了这么久, It's time to enjoy the victory :)

套用一下StarCraft2的广告语: "Hell, It's about time!", 希望能早日收到关心老师的签名赠书, 嘿嘿;-P

"Hell, It's about time!"

StarCraft2

今夕何夕

小飞 — Thu, 17 May 2007 05:44:00 GMT

阿西莫夫之后, 世界上还有时间机器吗? 请看:

1975年的杂文：请看苏修的一种新行业

今天发现, 王屋村地下超市的西瓜摊有5个, 看来今后五天内的每日水果就全素西瓜鸟~~

嗯, 夏天到了...

对判定网页爬虫的一点思考

小飞 — Sat, 12 May 2007 13:11:00 GMT

判断网页蜘蛛最简单的一个办法就是设置一个时间段, 然后记录这个时间段内来自某个源的点击数, 再计算其点击频率, 如果点击频率很高, 则认为它是一个爬虫, 反之则是正常访问. 这种做法的缺陷在于:什么样的阈值才算是爬虫的标准呢? 10秒内点击12次, 还是5秒内点击6次? 而且, 对于那些一次性打开多个并发请求的爬虫类型来说(比如突然来个20并发请求的burst), 这个方法可以说是很有效, 但是对于那些周期性的请求爬虫来说(比如每隔1秒请求一个页面), 这种算法就完全失效了, 所以你网站上的信息还是在不知不觉中流失.

对于周期性请求的爬虫, 也有数学方法可以判断, 那就是将每次请求的间隔记录成数组X[ n ], 对这个数组求其方差, 如果方差很小, 那么就可以判断这是一个周期性请求的爬虫, 这又引出了最初的问题, 多大的方差阈值才是爬虫标准?

那么再进一步, 周期性是一种数字的定性规律, 而不是由方差可以定量衡量的. 因为爬虫访问服务器是有规律的, 即频繁且具有一定的周期性, 如果说正常的人类点击可以看成随机分布的话, 那么爬虫的访问数据模型则可以用近似均匀分布来描述. 所以我们可以对请求时间间隔数组X[ n ]求其数学期望e(其实就是均值), 构造另一个数组{Y[ i ] = sum(X[ i : n ]), (i = 0, 1, 2, 3...n)}, 即Y[ i ]为X[ 0 ]到X[ i ]的累加, 再对Y[ n ]和{Z[ i ] = e * i, (i = 0,1,2,3...n)}数组做一元线性回归分析, 对于爬虫来说, 由于X[ n ]接近均匀分布, 那么Z[ i ] = i * e将很有可能约等于Y[ i ], 也就是说Y[ n ]与Z[ n ]数组是线性相关的, 而对于人类点击来说, X[ n ]则更有可能近似于随机分布, 那么Y[ n ]与Z[ n ]则不应该具有线性相关的性质, 基于以上数学基础, 我们通过判断Y[ n ]与Z[ n ]数组是否线性相关, 就可以判断访问是否是爬虫的点击, 即如果得到的直线斜率越接近1 == tan(45'), 则说明其具有周期性规律, 反之则不然. 之所以将回归直线构造到斜率为一的附近, 是根据tan(x)函数的性质, 因为它在离靠近0'时增长缓慢, 而靠近90'时又增长过快, 都不利于性质判定.

下面是我根据上述方法对两个真实iis log记录进行分析的结果(各取300次点击记录, 单位为秒):

图一: ip为222.41.178.219的人类访问记录散点图, x轴为时间线, y轴为两次访问的timespan间隔

图二: 根据上述算法的到的散点图, x轴为Z[ n ]数组, y轴为Y[ n ]数组, 很明显, 他们不具有线性相关的关系

图三: baiduspider的爬虫访问记录散点图, x轴为时间线, y轴为两次访问的timespan间隔(貌似有点规律 :) )

图四: 根据上述算法的到的散点图, x轴为Z[ n ]数组, y轴为Y[ n ]数组, 很显然, 他们具有线性相关的关系

分析: 两组数据都为300次点击的记录, 单位为秒, 其中人类的访问具有一个很明显的特征, 就是会有许多同时的并发访问, 这是因为, 当人类的浏览器载入一个网页时, 它会同时请求这个网页上的所有图片, 脚本和多媒体, activeX插件文件等, 表现在[图一]中, 就是许多timespan都等于0. 而爬虫由于只需要爬网页内容, 所以他们并不需要访问网页上的图片, 而是遍历网页上的所有超链接来进一步爬整个网站! 从matlab画出来的图看, 我提出的这个线性回归分析算法看上去还是相当有效的说, ^_^

Crawler analysis第一阶段实验数据(实验数据, 包含两个真实的log文件, 感兴趣可以拿去玩玩!)

通过对[学生之友]stuclub.cn网站真实iis日志的分析发现了另一种新类型的网络爬虫, 即来自同一个源的多个周期性爬虫同时爬一个站点. 例如有两个爬虫, 一个周期为2s, 一个周期为2.5s, 那么当它们一同爬一个网站时, 对于我们服务器来说, 他们的ip和user-agent都是相同的, 所以我们认定他们来自一个源, 但是实际上, 它又是由两个爬虫叠加起来呈现非线性规律. 所以需要在上述基础上再进一步, 之前提出的算法还是基于对重复进行独立实验的观察结果进行分析. 实际上, 访问序列是一个时序过程, 那么我们可以在数据分析中引入随机过程的理论.

现还在进一步做实验中...由衷感叹一下统计学在预测方面的确是很强有力的工具啊!

用ISAPI Filter阻止网页爬虫

小飞 — Wed, 09 May 2007 07:10:00 GMT

之前曾经发布过一个阻止网页爬虫的HttpModule，虽然效果很棒（yishan.cc服务器就正在用哦 :)），但HttpModule是在CLR当中处理请求的，还是会消耗部分服务器计算资源，最佳实践还是为IIS写一个ISAPI Filter，当服务器第一次接受到来自客户端的http request header时会触发一个OnPreprocHeaders事件，所以通过在ISAPI Filter中注册一个callback方法到这个事件上，我们就可以根据来自header中的ip address和user agent信息来判断请求是否是一个爬虫。阻止访问的black list保存在SpiderBlockerFilter.config文件中，当ISAPI Filter初始化时把这个文件中的内容加载到内存中的一个singleton对象里缓存起来。匹配则是用了CAtlRegExp这一号称世界上最快的正则表达式类。

我一直在考虑一个feature，即设计一个算法来自动判定来自某个源的访问是否是一个爬虫，最简单的方法是计算它某个时间段内的访问频率，但是我想更进一步，因为爬虫访问服务器是有规律的，即频繁且具有一定的周期性，如果说正常的人类点击可以看成随机分布的话，那么爬虫的访问数据模型则可以用均匀分布来描述，也就意味着如果我们记录来自某个源的每次访问时间间隔，再对这个数组做一下回归分析将会十分有趣，猜想它可以和某个因变量数组构成一个线性相关模型，用散点图描述的话，他们会回归地落在某条直线上。那么判断爬虫的问题就可以转化成一个线性相关是否成立的问题。（全拜这段狂A统计学习书籍所赐）

正在做实验测试自己的想法中，如果成功就会在下一个版本里面加入这个feature！

点击下载（源码稍后释出）

两个bug

小飞 — Mon, 07 May 2007 11:08:00 GMT

今天小白了两次...

1. 尝试写一个BHO（Browser Helper Object），用来实现一旦发现网页中有sex or illegal相关内容时，就redirect到一个警示页面。因为是个com组件，所以用guidgen.exe替所有的自定义接口都分配了一个GUID，结果发现组件死活无法工作，用attach process的方式发现ie根本没有加载我写的组件。无奈上网下载多份源码读罢，才发觉自己把系统接口IObjectWithSite的GUID也替换了，直接导致QueryInterface函数无法使用...改回声明文件中的GUID，bug解决。

2. 写一个ISAPI Filter，用来过滤网络爬虫，编译顺利通过，IIS一加载就整个crash掉。本采用的是继承自CHttpFilter的省力方式，改写为原生DLL，问题消失，最后发现问题在于没有把自定义继承自CHttpFilter的类实例化，bug解决。

两个bug的fix都只需要更改一行代码即可，所以说越是严重到showstop的bug往往就存在于我们潜意识里“假设”它“绝对没有问题”的地方！

五一节快乐

小飞 — Mon, 30 Apr 2007 10:46:00 GMT

五一劳动节到了，小飞祝大家节日快乐！

王屋村女性力量的崛起

小飞 — Sat, 28 Apr 2007 16:12:00 GMT

Don't make me think? We should think about it!

小飞 — Fri, 27 Apr 2007 07:28:00 GMT

UI设计有一条经典准则，就是所谓的“Don't make me think”，真正优秀的UI设计会让使用者感觉不到设计的存在，因为一切的操作都是顺理成章符合普遍思维习惯的。

要达到这个目的很难...即使说技术上发达到可以做很多很炫的界面效果，如果没有考虑到使用者的心理和操作习惯甚至是文化多样性，往往会让操作者百思不得其解！

yishan社区的tag editor正是面临了这种两难境地，大家不知有没有发现，我们的tag cloud上往往有好长一大拖用空格隔开的单词呢，那是因为tag editor默认是采用";"和","两种符号来作为tag间的分割符的，而空格不是！为什么要这么做？实际上这还与中文和英文的本质区别有关系！因为英语是音形字，对英语使用者来说，一个短语比如“Visual Studio”，其中的空格作用在于分割音节而不是分割语意，分割语意有专门的半角逗号和分号。中文则不然，中文是象形字，当我们在说一系列词组时，由于每一个汉字就代表了一个完整的音节，不需要专门的音节分割符，所以空格往往被用来作为语意的分割符。那么作为中文的native speaker，我们顺理成章地会认为，当我们在发帖时往tag editor里面打入多个单词或短语，用空格就可以表示他们是表示不同意思的，系统会自动把他们拆分成多个tag，所以当我希望给帖子加上"王屋村"和"小飞"的tag时，我会很自然地输入输入"王屋村小飞"。而英文的native speaker，则会知道，空格是用来分割音节的，所以当他希望给自己的帖子加上“Visual Stuido“和“ASP.NET”的tag时，他会输入"Visual Studio;ASP.NET"，显然，我们会觉得很失望，因为系统没有如我们所愿根据空格分开”王屋村“和”小飞“，于是我们就会很沮丧，因为我们被冰冷而愚蠢的机器bs了...

请不要认为我是在找借口，如果tag editor能够自动分析用户输入字符串的语意而自动分割开各个tag，那么我上面提到的冲突就可以完美解决，遗憾的是，语意层面的机器学习，至今还是学术界的一大难题...

所以我作出的work round是，除了原有的","和";"两个半角分隔符，再把全角的分号，逗号，句号，顿号也加入作为分割符，鉴于大家既会加中文也会加英文的tag，空格还是不作为分隔符，同时再在每个编辑帖子的地方加一条hint，”(请用以下符号分割各个tag，空格不作为分割符：, ; ，；。、) “。

当拿到一个tag输入串时，我会先把所有多于一个的连续空格过滤为仅一个空格，再过滤掉冗余的分隔符（恶意用户输入连续的无意义分隔符：；；；，，;、、；），然后才使用上面提到的分隔符分割各个tag。至此，我只能说，for you won't think, I try my best :-)

俺是王屋村的小芳	小芳
《大道至简－软件工程实践者的思想》推荐	阿超
4月20日yishan.cc社区正式发布了	小东彭彭
要的还是男生	小芳
跟着老猫学出版——找译者	晓菲

about:blank

Change the world in a small way...

《编程之美》编写小组的第一笔捐赠

面试趣题1：求不连续子数组最大和的值

对如何防止"过度设计"的一点拙见

"探索●发现" 周末特别奉献: 寻找<移山之道>

《移山之道》即将上市, 火热试读中!

Milan! Milan! San AC Milan!

Yishan, It's about time!

今夕何夕

对判定网页爬虫的一点思考

用ISAPI Filter阻止网页爬虫

两个bug

五一节快乐

王屋村女性力量的崛起

热门讨论博客

Don't make me think? We should think about it!