前些天在抓虾老同事的群里聊些话题，才发现在抓虾的日子竟然已经过去十年了。如今还会有人提到抓虾，但往往是把它当成徐易容的一次创业失败的教训。但是对亲身参与的人来说，那段经历并不只是“一次失败的教训”。
我和抓虾网的缘分，得从2006年说起。当时我正在如日中天的IT新闻（江湖）站点Donews供职。那时候的“IT圈”名副其实，Donews很像“江湖”上的“聚贤庄”，每周五晚上还有定期的聚会。我虽然只是个程序员，但也因此有机会近距离观察李想、王志东、李开复等等IT大佬。这样的机会刷新了我的很多认识，也让我掌握到不少“小道消息”，我第一次听说抓虾和徐易容，就是在聚会上。
大概从2006末年开始，聚会上谈得更多的话题就不再是IT，而是房市、股票（Keso当时也在，他前段在一篇文章里也谈到这点）。Donews本身也发生了些变故，我当时混得还不算差，但也在考虑下份工作了。
有一天，老大转来一封邮件让我去接洽。原来是徐易容希望开展内容合作，用RSS输出定制内容给抓虾。因为之前做过RSS相关的开发，这方面我确实比较擅长。
如今很多网民大概不知道什么叫RSS了，RSS也确实没落了。但是在十年前，RSS绝对算开天辟题的技术，即便在今天也有很多启发意义。所以，我在这里多作些讲解。
简单说，RSS就是进行站点内容分发的“开放API”，而且是“洗剥干净”的纯内容。普遍的做法是，由内容提供方按照RSS规范，把最单纯最核心的内容（去掉了广告之类无关的内容）用XML格式输出来，由其他人抓取。
这种技术如今看来不可思议，当时却是价值非凡。在我看来，原因由好几点。
第一，当时的抓取技术远没有如今这么先进，想在繁杂的网页中准确提取原文相当困难，甚至许多网站的数据库里存储的都是混杂在一起的内容，RSS推动了数据和表现的彻底分离；第二，当时大家都在努力获得流量，通过提供RSS输出“纯”内容，很容易把自己的内容推送到各个平台，建立众多触达入口；第三，或许也是最重要的，RSS提供了“合烧”的功能，因为各站点都提供了分门别类的RSS输出，你很容易把信息重新组织聚合，“简单拼拼XML”就可以把新浪体育、搜狐体育、网易体育的内容集合到一起，这可以算作如今大红大紫的个性化阅读的先驱；第四，你不再需要频繁刷新网页去看更新了，RSS阅读器可以定期检查更新，提醒读者。
正是因为RSS有诸多优点，大家很快发现，有了RSS，就不用大费周折去浏览一个个网站了。或许，这就是未来的方向？
我记得第一次收到易容的短信是个周六的下午。当时天气很好，我正在二环边修自行车，忽然接到一条礼貌而客气的短信，于是约好第二天上午见面。
第二天我特意提早出发，因为听说徐易容特别守时，说几点就必然是几点。到了抓虾以后见到两个人，热情开朗的是徐易容，同样热情的是合伙人谌振宇（还是我的湖南老乡），印象里他好像还留长发。当时主要聊了聊技术合作的事情，大家很快就敲定了合作方案，输出哪些频道的内容，怎样输出，因为大家都是做技术的，所以沟通相当愉快。
等周一上班了我就开始计划开发，很快就开发完成，对接成功，易容还发了个恭敬客气的邮件专门表示感谢——当时抓虾是小站点，内容合作算是借Donews的光。事情到此，就算告一段落了。
不久，易容又给我发了个邮件，说要再约吃饭聊聊。我虽然感觉有点奇怪——合作已经完成了。不过易容说“感觉大家还不熟，多聊聊就熟了嘛”，所以我欣然答应。
这次吃饭还是易容和振宇做东，聊的话题更多了些。顺带他们也介绍了自己在做的事情，抓虾未来要做的事情。我本来也比较感兴趣，所以就这么一直聊下去。
然而话锋突变，易容和振宇对视一眼，然后站起探身过来，拉住我的胳膊说：我们觉得你挺合适，想请你加入，不知道你是什么意见？
虽然我当时在考虑看其它的工作，但易容这个举动还是让我大感意外（在我以后的工作中，也再没有过这样的经历）。但是我又想到，他们说得这么直接，态度又那么真诚，于是答应回去认真考虑下。没几天我就下定决心加入了。那时候大家都很爽快，我还没有提离职，振宇给我发短信说“你的工位和电脑都已经准备好了，就等你来了”。
刚加入抓虾的时候，整个团队已经有十多人了。技术团队里，除了两位创始人，还有几位工作了五六年的同事：昌乐、明珠，分别负责后端和前端。再就是像我这样刚工作三四年的，崇利、王曦、永辉、一弢。再往下就都是在校的实习生了：刁、陈凯、路明、国栋、永超等等。当时负责UI的是潇潇，后来是新浪来的王达。比我稍晚一点，又来了海鹏、熹熹（姜志熹）、朱荣等人。再晚点，又来了实习生陈拓。总的来说，团队很年轻，活力十分充沛，相处也很融洽。
我当时印象比较深的是实习生。我自己到了毕业那年费了不少周折才找到工作，想起来要庆幸运气不错。而像国栋、永超都是北大计算机系的，基础相当好，工作也很卖力。我这才发现，实习原来不是外界传说的“廉价劳动力”，对实习生来说能提前体验职业和职场，对公司来说能提前锁定优秀的在校生——原来，好苗子还在大二大三就已经被瓜分完毕了呢。
从我后来的经历来看，或许北京在这方面有得天独厚的优势。无论在长三角、珠三角，都很难有“名校高材生愿意去前途未卜的创业公司实习”的普遍氛围。无论在哪里，这样的孩子们可选的去处都很多，但只有在北京，会有相当部分的人不怎么考虑生活的压力，投身去做自己想做的、有意思、但前途还不明确的事情。但是话说回来，“改变世界”这回事，很多时候确实不是靠算计，而是靠情结和信念来完成的。
当然，这或许也和那些年北京的气氛有关。我曾经和很多在北京的朋友讨论过，什么时候的北京最可爱。比较普遍的答案是，06年到08年那一段。虽然大家没有什么钱（我每次从朝阳门去保福寺都是骑自行车），但那个时候的北京有无比的包容感，加上各方面的管制都在逐渐放松，人人都有点“美好前途全力创”的感觉。
我自己感觉也是如此，那段日子真让人怀念。记得我刚工作不久，听说德国人开发了一种新的Web服务器，叫Lighttpd，于是找来研究了一番，写了点东西放在网上。过了不久，有人联系我希望聊聊Lighttpd，见面了才知道，这个人是豆瓣的创始人阿北。今天想来似乎不可思议，但当时却是“意料之外、情理之中”的事情。
这样的经历还有不少。06年有一天晚上我和韩磊、霍炬、朱辉龙一起在簋街喝酒到很晚，这时候来了两位流浪歌手，于是我们也跟着一起唱。唱着唱着，店家又给上了很多啤酒。我们都觉得很奇怪，一问才知道，大堂对侧另一桌的朋友虽然不认识我们，但觉得唱得不错，所以给我们点了一打啤酒。于是，大家端杯走向那桌不认识的朋友，一边连声说“谢谢”，一边喝了几杯，这样就算尽了礼数。
07年夏天我设了个饭局，谁会来完全不知道，只靠朋友口耳相邀。结果，一开始来了个挺斯文的年轻人，自我介绍说“我松鼠会的姬十三”……过会儿又来了个家伙，一问原来是DBA Notes的冯大辉。过会儿，李笑来老师、博文视点的周筠老师也陆续来了。很多朋友之前都没有见过面，只是在网络上听说过。当面见了，轮流做个自我介绍，谁也没什么架子，大家一边吃一边聊。现在我已经离开北京很多年了，
回来说抓虾的团队。这个团队就是在那样的年代，由一群热情洋溢的年轻人组成，所以虽然说不上多么严谨专业，但感觉是幸福的。办公室的二楼有供加班休息用的房间和小床，虽然卫生很糟总是臭气熏天，但大伙就靠这张床（还有漱口水），熬过了很多不眠之夜。
吃午饭这件事也很能体现团队的风格。当时抓虾是包午饭的，定点在华清嘉园附近的一个饭店，从保福寺走过去大概要二十分钟。每天吃饭的程序都是异步沟通，确保高效：首先打电话过去点菜，然后等电话通知上菜时间，估摸着快到了，组队去吃饭。走进饭店通常所有菜刚刚摆上桌，大家就坐之后一顿猛吃，通常桌子刚转两圈就吃完了，前后不到10分钟。有一次，易容有事来晚了五六分钟，结果被告知“你们的人都走了，桌子都收拾完了”。这种作风有深刻的后遗症，我离开抓虾之后，陆续被很多人说起“吃饭速度好快”。
同样有意思的是团建。07年组织了一次自驾去河北涞源和空中草原，露营的那天晚上，男生挤的那张帐篷里臭气弥漫，等我早上起来已经有好几个人受不了气味，跑去看日出了。那天晚上易容也没仔细看防潮垫下面的情况，据他说睡的那块地方下面正好有一大块马粪，导致他胃受寒了好些天。回程我们在八达岭高速遇上特大堵车，从中午12点到夜里8点基本没动地方。这是我第一次在高速上的汽车里过夜，半夜我还拿三脚架和单反出来拍了不少高速夜景。夜里有好几次前面疏通了一两公里，坐在副驾驶的我醒来就喊“易容，可以走了”，于是他发动汽车往前开一段，接着又睡着。第二天早上8点多我们才回到北京，结果是皆大欢喜：当天不上班，全员多休息一天。我还追问易容记不记得前天晚上我叫他开车的事情，他竟然完全没有印象。
当然，对于公司来说，团队年轻，气氛好，只是一个方面。团队年轻就意味着可能犯错，需要严格要求、反复锤炼。尤其是因为没有大公司成套的规章制度，这方面需要付出的努力就更多。后来我每次回想，都觉得这方面易容和振宇肯定花了很多心思，没有靠打鸡血也没有靠蛮力逼迫，就能保持整个团队的技术追求和信任保持在很高的水平。就我所见，真正能做到这一点的人，着实不多。
我记得有一次偷空看到海鹏的代码，惊异发现内部管理系统也写得那么漂亮，真是自愧不如，这才相信他之前呆的IBM并不只有笨拙死板的流程，还会培养良好的规范意识和职业素养，自己之前真是知道得太少了。当然我也是只有佩服其他人的份，有次我花了些心思写了个周边的小模块，也被同事称赞“写得真漂亮”，当时真是心花怒放。滋养技术追求，并且这种追求会被明确肯定，对良好的技术氛围功不可没。 实习生陈拓来的第一天就说，他的电脑不要装Windows，直接装Linux，真是让我吃了一惊。许多年后我和他在长沙见面聊起此事，他嘿嘿一笑说“其实我Linux不怎么熟悉的，但是当时看身边的人一个个都用命令行，再用Windows肯定说不过去”。
或许正是因为有这样的团队和这样的气氛，所以后来我回忆起自己在抓虾的经历，也深刻觉得在技术上获益匪浅。
有几个例子我印象很深。第一是整个抓取的任务分派系统。因为要抓取的RSS Feed（内容源，也可以理解为某个URL地址对应的XML）很多很多，如何高效调度它们，保证尽快抓到更新，又不能做太多的无用功，就成了大问题。新闻的更新时间比较好预测，但还有大量的RSS来自博客，博客的更新时间往往取决于作者心情，完全没有规律，什么算法都不好用。这个问题采取了一个非常取巧的办法来解决：从读者出发。只要发生读者登录事件，就检查这个读者订阅的RSS Feed，如果对应的Feed上次的抓取时间在半小时之前，就立刻触发再抓一次。
换句话说，重要的不是技术要做到无所不能，而是要给读者“抓得够多够快”的感觉，真正的问题是用有限的资源实现最佳的效果。后来在很多工作中我发现，技术人员往往忽略了这点，明明可以用很低成本实现的效果，非要去钻牛角尖。或许，这并不是因为他们笨，只是因为没有见过让人“开窍”的例子。
第二是抓虾的存储。为了保证阅读效果，抓虾抓来的内容都需要存储在本地，几百万Feed每天产生的数据量相当可观。那时候HDFS之类的东西根本没有成气候，更谈不上云计算、云存储了。如果数据量大了，充其量是使用Tokyo Cabinet之类的类库来完成，但这种东西本身又不甚可靠，工业上使用总是问题多多。
抓虾解决这个问题也是用的简单粗暴的方式。把内容用Gzip压缩成二进制存到MySQL的表里，只提供ID和GUID的查询。这样单张表可以存放3亿的数据，分表的规则也相当简单。
这种方案听起来有些土也不可思议，但当时确实解决了问题，而且依托MySQL现成的主从复制，数据的一致性也有很好的保障。正好那一年《容量规划的艺术》中文版面世，我找来一边读，一边思考MySQL的存储方案，深刻体会到一个道理：方案本身并没有绝对的优劣， 根据实际情况提炼关键指标，综合考虑各种变量，通过分析、估算、设计、验证，得出合适的方案，到后来能把各种约束、条件、关注点烂熟于胸，这才是工程的真正含义。
这或许是那个年代技术人员的“通病”。因为没有那么多现成的类库和框架，大家只能因陋就简，靠内家功夫取胜。最近讨论技术方案时，我提出了一个看起来简陋直接，与“高大上”一点关系都没有的办法，大家细看之后觉得确实可行。我说，“我们那个年代成长起来的技术人员，一般都会这样的思考”。
上面说的还只是刚去抓虾的印象，随着工作时间的增常，我也见到、学到了更多让我印象深刻的东西。
在去抓虾以前，我的关注点主要集中在开发上。写好代码，能跑起来，工作就算完成了。但是去了抓虾之后我才发现，工业级的程序不是这么玩的。首先所有的服务程序都有专门的启动程序，保证真正的程序不死，死了也能迅速重启。同时，所有的程序运行的状态，也必须一目了然，不但要有实时查看，还要有日报、周报等等各种报表。
这相当于一边写程序一边问自己：我的程序里应当提供哪些关键信息，通过它们就可以鉴别程序的状态，这些信息通过什么途径可以访问——这是一个“元设计”的过程，促使我们更深层次地思考我们的工作。我也深刻领会到了“输出给程序处理的信息应该是什么样”，它和给人看的信息有哪些差别。
可惜到如今，我发现还有大量的程序员从来不思考这样的问题，自己的程序在跑着，既看不到实时的状态，也不提供每天的统计。出现问题只能通过肉眼排错，不但意识不到效率的低下，反而乐于扮演“救世主”的角色。这些，其实都是缺乏严格训练的表现。回想我们都离职之后，服务器“裸奔”了大半年竟然没有出问题，靠的都是之前在工程上做的各种努力。
值得一提的还有“负责任的精神”。当时有一些基础的模块是振宇早期写的，当时抓虾有著名的十大谎言，第一大谎言就是“振宇的程序没有bug”，每次说起这个振宇都是笑笑，“这不是谎言嘛”。结果有天中午吃饭时聊到程序，似乎振宇的程序逻辑真的有个bug，只见他神色凝重，立刻放下筷子回去了，把这个bug修好了才算解脱。其实那个bug并没有立刻的重大的影响，而且振宇已经很忙了，但是他仍然保持着对质量和技术的执着追求，让我汗颜，也让我佩服。
这种汗颜和佩服是有理由的。有一次线上出现了bug，我两三天也没有解决，每次被问起来就说“正在解决”。直到有一天振宇问我，我才承认“我调不出来”，敷衍等到明天再说。我记得他当时神情一变，凛然正色道：“不可能，我不相信有调不出来的bug”。然后拉着我一起调试。多机器、多线程的系统，本来调试就很复杂，但他就靠着GDB，蹬着转椅在几台电脑前晃悠，从吃过晚饭一直调到深夜，我们终于定位、解决了问题，出公司回家已经是星斗漫天，一看表已经三点了。我总觉得IT行业虽然年轻，还是可以从传统的师徒制借鉴很多的。起码，后来我自己带领技术团队时，我也有好几次说“不可能，我不相信有调不出来的bug”，然后拉椅子现场坐下来证明我说的对。
抓虾在技术上要求很严格，但不死板。很多时候都是“任务式管理”，你领到的是个抽象的任务，并没有限制解决的办法，但要求实现最终的效果。这样看起来很自由，真正解决起来很痛苦，但也锻炼人。
在我入职后不久，就有博客作者反馈抓虾的抓取比较慢，他们自己新发表一篇博客，其它在线阅读器可能半小时就抓到了，我们却要一个小时。当时在我看来这是小概率事件（几十万种子里有个案抓取慢而已），意义不大。但是，连着几次开周会的时候易容都在强调这件事情，我不得不顶着巨大的压力去解决“怎样能在抓取速度上全面超过竞争对手”，绞尽脑汁想了各种办法，终于算是解决了问题。在那之后，我开始领悟到什么是“解决复杂问题”了。
还有一次，因为抓取程序的频率调整机制失控，新浪微博把我们的抓取服务器IP给屏蔽了。我还记得当时振宇给我发了条短信“今天必须把新浪的事情搞定”，没有任何关于方法的指示。我找到之前在新浪工作过的朋友，辗转打了二十多个电话，终于联系到执行屏蔽的技术人员。在我确认承诺修正程序，以后不超负荷抓取之后，封锁的问题终于得到了解决。
这件事也给了我很多启发：当时有一种建议是找大批代理服务器来抓，但我没有采取这种办法。技术产生的问题当然可以用技术解决，但是这不是唯一的途径，我们也可以靠沟通来解决，而且也应当靠沟通来解决。明白了这个道理，我在后来的工作中受益很多，甚至在求职中也受益很多。从抓虾离职后，有次面试中HR让我举例说明自己的专业素质，我举的就是这个例子。从最终的结果来看，这个答案应该是不错的。
我本来以为十年前的故事应当很容易写完，但今天真正坐下来动笔，才发现根本不能一一记录。虽然已经过了十年，那些记忆还那么真切。十年前的每一个傍晚，我在保福寺高高的写字楼上看到四下居民区的灯渐次亮起，入夜再渐次熄灭，然后自己才下班，那画面仿佛就在昨天。无论今天的人如何评说，那段经历已经和自己融铸为一体，无可剥离，也无可冷冰冰地“客观”看待。
年轻的时候，我们往往会被成功的故事所激励，被“出类拔萃”、“与众不同”、“卓尔不群”的话语所感动，最终却发现，自己很可能只不过是“类”、“众”、“群”的一份子而已。但是谁又能说，这一定不是好事呢？
