我爹是老师，所以我家里有一大堆收缴上来的小人书，而且都是残缺不全的，所以我常常刚看完三英战吕布，接下来就是智取生辰纲。
我
最喜欢看《水浒传》，因为里面的好汉经常可以吃肉吃到饱，我却总得吃饭，还要吃超讨厌的青菜。好汉吃饭时往往是大手一挥，让小二上n斤牛肉和n斤酒，而且
形容好汉狼吞虎咽经常是一句“吃得口滑，只顾要吃，哪里肯住”，每次读到类似情节，我总会忍不住咽口水，心中充满无限的向往和羡慕，希望自己也有朝一日能
光吃肉吃到饱，而且吃得口滑，只顾要吃……
读xin哥的blog有感：http://yishan.cc/blogs/xin/archive/2009/01/27/1015.aspx
最近，由《编程之美-微软技术面试心得》一书稿酬所捐建的第一个机房在福建省漳平一中正式投入使用了！
一个月前，《编程之美》编写小组向漳平一中捐赠了第一笔稿酬，共计16000元整。随后我们又向湖北省五峰县一中捐赠了一笔同样数额的稿酬。一个月来，漳平一中经过公开招标，用这笔钱购买了第一批5台计算机，并将发票寄给了我们。然后又开辟了一个房间安装这些计算机，做为编程兴趣小组的专用机房，并于近日正式投入使用了。从此，编程兴趣小组的同学们就有了专用机房，可以专心地练习编程了。
我们每个人都很平凡，也许一辈子都做不出什么惊天地泣鬼神的大事来，但是，我们依然可以通过努力，踏踏实实地做一些事情，来改变这个世界一点点…漳平一中编程兴趣小组的指导教师李超老师，他之前摔伤了腿行动不方便，为了布置好这个机房还不辞辛劳地奔忙。不光是他，还有博文视点的杨绣国编辑和周筠老师，以及漳平一中多位为促成此事而辛勤工作的老师们，没有他们的无私付出，我们这份微不足道的稿酬也就无法顺利地实现它应有的价值：在鼓励经济欠发达地区计算机教育方面发挥它最大的作用。因此，当我们在为同学们用上新电脑学习编程而由衷地感到高兴的同时，也要对这些为促成此善举而默默付出的人们表达诚挚的感谢。我们并非无所不能，但正所谓“勿以善小而不为”，只要我们每个人都付出一点点，就能改变世界一点点。
一周前，我正式加入了浏览器制造商Opera公司，这是我的第一份工作，我也希望自己能通过辛勤工作，为产品发布贡献力量，藉此改变浏览器之战的历史一点点…
最近，福建省漳平一中收到了由《编程之美-微软技术面试心得》编写小组捐赠的第一笔稿酬，共计16000元，这笔钱将用于购买计算机，供编程兴趣小组的同学们作为信息技术竞赛培训之用。这也是从《编程之美》稿酬中捐出的第一笔善款，今后我们还将根据此次捐赠的反馈效果，制定进一步的捐赠计划。
《编程之美》一书自去年3月出版以来销量就一直不错，在博文视点公司的大力推广以及广大热心读者的支持下，获得了：
等种种殊荣。我们几位编者看到自己的劳动成果能被大家所接受，都由衷地感到高兴。然而，随之而来的问题是，我们该如何处理这笔稿酬呢？这时，邹欣老师提议把稿酬都捐赠出去，用于鼓励和支持中学生学习计算机编程知识，这一提议立刻得到了所有编者的一致认同。
作为一个从不发达的山区小县城走出来的编程爱好者，我更是高举双手支持。因为我还记得在高一前的那个暑假初次接触计算机编程时，学校里那个要脱鞋才能进的机房，那些破旧的无盘486工作站，机箱上还有个Turbo按钮，按下去之后，似乎Turbo Pascal的编译速度都会变快一些...更让我记忆犹新的是，那时自己对上机、对敲击键盘和调试程序的渴望，有限的上机机会显得是那么弥足珍贵...从自身的经历出发，我们相信直到今天，在一些经济欠发达地区仍然有许多对计算机技术抱有无限热情和兴趣的学生，因为缺乏上机条件而苦恼。也许，我们可以做些事情来改变这种状况一点点...
经过几次邮件讨论，我们达成了如下捐赠宗旨：我们捐赠的目的是让这份微不足道的稿酬能在鼓励经济欠发达地区计算机教育方面发挥它最大的作用。
基于这个宗旨，我们将从以下几个方面来寻找捐赠对象：
- 经济欠发达地区和缺乏计算机教学资源的学校是前提之一。
- 我们会考虑这些计算机是否能在一段时间内发挥它最大的作用，把这些计算机送到最迫切需要它们的人手里才能体现出最大的价值。
- 由于我们只是捐赠计算机，学校必须有能力自己组织师资力量来维护硬件、教授计算机使用和编程知识。我们坚决反对将捐赠的计算机当成摆设品和宣传的噱头。
不久，在我和博文视点编辑的牵线搭桥下，福建省漳平一中和湖北省五峰县一中最早与我们取得了联系。大家在对学校情况深入了解之后一致决定，将这两所中学选定为第一批捐赠对象。其中，漳平一中的老师过去几年里在缺乏足够的教学资源，尤其缺少专用的计算机供编程兴趣小组进行竞赛训练的情况下，仍然坚持培养学生参加信息学奥林匹克竞赛，也取得了一些不俗的成绩，我们相信这次捐赠的计算机能极大改善他们的上机条件，并让他们在今后的竞赛中取得更好的成绩。
然而，我们也都知道全国有许多更贫困而且需要帮助的学校，它们最迫切需要的也许不是计算机，而是最基本的学费、课本、文具、教师等。我们的力量其实微不足道，只能尽自己的绵薄之力帮助其中一小部分迫切需要计算机资源，同时能将这些资源发挥最大作用的学校。更多的帮助，需要全社会的共同关注，需要每一位有爱心的人伸出援手。
我们对第一批选择的这两所学校是进行分期捐赠的，期间会不断通过校方反馈的捐赠效果来及时调整我们的捐赠策略和方法，甚至决定是否中止捐赠，我们会将这些反馈通过不同渠道公布出来。同时，我们也鼓励热心读者提供一些迫切需要计算机资源的学校信息，我们希望能与校方直接联系商谈，如果情况属实，我们会在力所能及的范围内提供最大的帮助。
捐赠计算机的具体使用是学校的自由，之前提到的捐赠宗旨已经明白无误地表达了我们的价值观，只要不违反这个最基本的原则，我们不会强加任何意志给受捐赠的学校。
《编程之美》一书上有一道题：给定一个由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;
}
有着与众不同“坎坷人生经历”的80后模范青年小飞最近很烦恼，因为他要在经济危机的求职大潮中找到一份满意的工作...一天他正在网上搜索c++相关资料准备第二天的笔试，结果无意中看到了下文：http://www.javaeye.com/topic/254179，很x很xx，"装死"的王屋村民们不妨都出来发表下看法吧...
我曾经管理和经历过使用所谓“敏捷开发”的两个相对比较大的项目。之所以是“所谓的敏捷开发”，掺杂了不少了自己的实现和理解，见笑了。
第一个所谓的敏捷开发的项目是迫不得已的，因为项目前期投入大而且人事变卦（其它公司挖墙角），后期没有足够的时间来完成项目，所以我自告奋勇承接这个项
目，CALL，其实就是为了年底能够领到更多的奖金。这个项目总价是100W，其中30多W是硬件，30多W是公关（灰色）费用，老板给我的成本价是
15W，而且很认真的给我算出这个数。当时老板给我的条件是：公司资源随便支配，其中开发资源计在成本之内，三个月交付，这个时期内最少有三个重要的里程
碑，每个里程碑必须完成工作的35%，包括质量检查。
我的做事方法，一个能力跟我相当的程序员，一个能力一般且很仔细的程序员，一个测试工程师，另外还有一个是美工，还有客户方至少有一个到现场帮助测试或者业务讲解。然后在中关村某公寓封闭开发。
我们挤在一个不大的会议室里，都在一张桌子上办公，开发程序有点像流水线，第一个是我，我写程序快，经验多，i当然BUG也多。因为是J2EE程序，我在
前一周都是在写所有表的增删改查，其中MODEL和DAO这一层自动生成，controller这一块写了通用的增删改查，页面也是简单的增删改查。然后
就是其它两个程序员帮助我修改一下错误和BUG。测试人员在写测试用例，美工在和客户方交流用户的操作体验。总之，我想要说的话是：敏捷开发当中，敏捷的生产过程非常非常重要。
。我们经常交流，且有一种努力创业的想法。
。有能力的程序员，让他写一些通用的方法和JS。（随便是google或者baidu上去抄）
。客户方帮助我们不少。每个人都了解业务，有的想去卖仪器（哈哈，客户是做仪器的）
。我们没有单元测试，每个人做完既定的功能后就提交功能测试，我们每个人的BUG很多，但是后面就很少。
。我们完成一个相对独立的模块后，就提交给实用户，到现场进行试用。
当然也少不了零食，看板，使用xplaner做管理。
结果：我们不到两个月完成项目的85%以上，如果不算BUG的话，应该是在90%以上，然后退回到公司过着朝九晚五的生活。年终我也领到了两个多月工资的奖金。一个字爽。客户如期上线。
黑五总结：跟着我的几个哥们，很讨厌我，他们最希望加薪，我只给他们的福利是每天120元/所有人的消费标准，每天工作10个小时左右，工资每天加100
元，星期六星期天加200元（可以选择过星期天）。经过这个事后，他们很疲惫，虽然他们的技术提高很快，但是对公司的不满也每天增加，终于不出半年走掉一
个，不出半年，又走掉一个。
个人感想：敏捷开发的方法是老板喜欢看到的，因为
敏捷开发方法节约成本，快速交付。但是对于员工来说，这种管理让人感觉压力很大，有点变态的感觉。我想如果一个人长期处于这种敏捷的开发当中，而自己没有
自由的空间时，员工的不满会与日俱增的。尤其我们IT程序员跟现在的小姐一样，青春就哪么几年还在变态中渡过，所以从员工角度来说敏捷开发不是很好。
我同时又想到了“计件工资”，又扩大了思维想到了“联产责任承包制”，又想到了“事业部”。感觉敏捷开发应该和员工的利益直接关联。于是我又想到了长得漂亮“出台率”巨高，美妓李师师......
可能，敏捷开发的路可能还很远，对企业的管理方式也会不断的变化。这家伙，搞的天天跟考试一样。
至今，找到的新工作也在敏捷的氛围当中进行，看看我的BLOG的更新时间你就知道我有多忙，为了生存，奉献身体，奉献青春。
个人想法，仅供参考，不要人身攻击。
软件工程, 唯一不变的是变化. -- 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
两天前, 欣闻关心老师的大作<移山之道>终于在全国隆重上市发行了, 于是趁着周末, 带上相机, 前往中国海淀图书城, 去掂一掂这本书真实的重量 :)
书店远景
书店外景
书店入口
书店全景(手机男站立处即是<移山之道>)
静静地在角落绽放 ;-P
封面特写
封面特写: 两岸bug藏不住, 轻舟已过万重山...
近一年来, 做为一个中肯的建议者和批判的读者, 我算是见证了这本书从最初的想法, 到提纲目录, 再到厚厚的书稿, 直至最后排版印刷出版的整个过程. 我不知道该用什么语言来形容这个漫长的创作过程, 因为除了作者, 也许谁都没有资格来告诉大家这一整个艰辛过程中的点点滴滴, 那些灵感的涌现, 细节的讨论, 主题的修正和改进, 还有对技术细致入微的阐述, 对过程的高屋建瓴的描写, 对人物入目三分的刻画, 以及书稿丢失的沮丧, 还有最终排版成书的喜悦...酸甜苦辣, 我没有资格述说, 从关心老师一贯幽默潇洒的blog文风中看到的也是乐观而充满激情的写作情绪, 但是我又真切地知道这一切其实都很不简单, 我只想在此由衷地祝贺关心老师: "Congratulations! You have done a great job!"
给最后一张照片配上一句话:
褪尽封面的浮华, 内容才是移山之道的精髓!
好消息! 大家引颈期待了这么久, 邹欣老师的作品《移山之道》终于要正式上市了, 迫不及待想要先睹为快的朋友请访问http://book.csdn.net/bookfiles/443/#c1试读部分章节.
好书当然要捧在手里读才有感觉咯, 大家准备好银子抢购吧 :)
小飞乱谈: 想当年, 俺的作文水平是相当彪悍啊, 初中升高中语文考试全市第一可不是盖的, 可要是碰上今年这种高考题, 估计铁挂...幸运的是我5年前就参加了高考, 不用再受这种BT命题作文的困扰了, 我十分同情那些今年高考的小弟弟小妹妹们, 在醒悟到自己其实是可以具有独立思想之前, 你们还要被这个社会和万恶的应试教育"和谐"很长一段时间...看看这些作文题目, 都已经开始玩"意识流"了...残念...orz...拜啊...学十年语文, 不如写半年blog!
转载自: http://www.sohoxiaobao.com/chinese/bbs/blog_view.php?id=667935
全国1：《人生，诗意还是失意》
——哥们既不诗意，也不失意，就被你这二逼题目弄得有些失忆。
全国2：《帮助》
——有权的、有钱的，包一二奶，那叫帮助阶级姐妹，知道吗？
北京卷：《春夜喜雨》
——别下了，第二天更堵车。
上海卷：《必须跨过这道坎》
——您说太对了，知道你们家有刘翔。
辽宁卷：《我能》
——给您添俩字儿昂——忽悠！
湖南卷：《诗意的生活》
——就是失去意义的生活，还说啥劲呢？
陕西卷：《出事了》
——多大的事儿，不就是念个错字吗？
浙江卷：《行走在消逝中》
——那躺着、趴着，在什么中？
山东卷：《时间不会使记忆风化》
——但会使记忆有伤风化。
广东卷：《传递》
——毛片。
江苏卷：《怀想天空》
——那是叶子楣的怀，咱都没戏。
福建卷：《季节》
——高考的时候是夏天。
江西卷：《心中一泓秋水》
——认字儿还不少。
《想说爱你不容易》
——那就不说。
湖北卷：《母语》
——我妈老骂我的话叫母语。
天津卷：《有句话常挂在嘴边》
——靠！
安徽卷：《提着篮子看妈妈》
——我妈农转非了，早看不上破篮子了。
四川卷：《不是一步与一生，是一生与一步》
——对，这就叫文化苦旅，自己慢慢走着吧。
重庆卷：《甜酸苦辣说高考》
——赶紧给丫废了！
关于那三个加粗的标题, 来自这里: http://www.bullog.cn/blogs/moogee/archives/68785.aspx (个中滋味, 请独自揣摩...)
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
闲来无事, 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
阿西莫夫之后, 世界上还有时间机器吗? 请看:
1975年的杂文：请看苏修的一种新行业
今天发现, 王屋村地下超市的西瓜摊有5个, 看来今后五天内的每日水果就全素西瓜鸟~~
嗯, 夏天到了...
不知道大家有没有发现一个相当奇怪的问题,很多中国的软件作者和软件团队都不愿意说自己的软件是国产软件,他们开始刻意地将自己和自己的产品隐藏起来,当他们的新产品推出时,经常以一个"外来和尚"的形式出现,Orbit Downloader,Foxit, IE7 Pro,比比皆是,比起国产软件这个名字他们更愿意让中国的用户以为他们是舶来品.并且当真相被表明后,他们也不愿意发表任何看法.
联想起到国外发展的NetAnts和第一代共享软件作者的命运,或许,我们对这种“软件海龟”的奇怪问题要思索,要检讨.
转载自: http://cnbeta.com/articles/26586.htm
判断网页蜘蛛最简单的一个办法就是设置一个时间段, 然后记录这个时间段内来自某个源的点击数, 再计算其点击频率, 如果点击频率很高, 则认为它是一个爬虫, 反之则是正常访问. 这种做法的缺陷在于:什么样的阈值才算是爬虫的标准呢? 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都是相同的, 所以我们认定他们来自一个源, 但是实际上, 它又是由两个爬虫叠加起来呈现非线性规律. 所以需要在上述基础上再进一步, 之前提出的算法还是基于对重复进行独立实验的观察结果进行分析. 实际上, 访问序列是一个时序过程, 那么我们可以在数据分析中引入随机过程的理论.
现还在进一步做实验中...由衷感叹一下统计学在预测方面的确是很强有力的工具啊!
之前曾经发布过一个阻止网页爬虫的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！
点击下载（源码稍后释出）