joyfire

　　我在北京生命科学园。10分钟前有明显震感。

　　在实验台旁看lz做实验，旁边同事说电子天平无法调平，总在跳，lz教她：去掉手套，用手掌放掉静电；另一个mm在液相前面配置设备，突然后退两步，问她怎么了，她说突然头晕站不稳，怀疑不慎吸入了甲醛……

　　大一在jiuqi打工，喜欢带着冰激凌去找oyy，总架构师，他的屋里有舒服的空调和沙发。oyy爱吃冰激凌，但没几个人知道，大概是因为喝咖啡才符合程序员的职业形象。oyy很和气，所以我经常在沙发上放肆地手舞足蹈。（曾经竭力模仿身边的职业程序员：昼夜颠倒，喝很浓的不加糖的咖啡，染红色的头发，甚至一边点鼠标一边心不在焉抓起杯子喝水的神态……直到有一天发现oyy偷偷去买冰激凌，哈哈）

　　当时刚学会CGI和ASP，觉得会有越来越多的软件采用WEB方式。身边的朋友说不明白，决定有机会问问oyy的看法。可是没说两句，老板闯进来，把我客气地轰出去：总架构师应该做些更重要的事。临走oyy说“有意思，但我猜不会很快变成主流”。

　　跑到身份不符的地方胡闹，被老板当胸抓住，还有什么话好说，回工位老老实实写我的ETL代码，这才对得起薪水。

　　没过多久，在展会上见到用友的新一代ERP，完全使用Web UI，宣传手册里有个新鲜的名词叫B/S结构。

　　Google App Engine不顾俺三番五次申请，就是不给试用帐号。郁闷呀。

　　这里有一段视频，演示了简单的Google App Engine开发步骤。尤其是用GQL调用传说中的MapReduce海量分布式存储，看得俺直掉口水。趋势不可逆转，很快多数软件都会以ASP（Application Service Provider）方式提供服务。我很想知道微软首席架构师Ray Ozzie看到这东西是什么感觉。

　　按一般观点，类似俺们pFind这种计算密集型应用，核心模块必须使用C/C++ API，否则慢得难以忍受。然而，一旦基础架构的分布式规模达到Google所谓的“云计算”这种级别，就算有几十万张谱，也可以充分地分而治之，被分解到巨大的PC Farm里，让集群节点一对一PK，甚至进一步按蛋白数据库再细分任务。这种情况下，即使单个节点的线性效率稍差，也可以接受，可能用Python就够了（对比：按我们现在的经验，没经过精心优化的Matlab代码鉴定一张质谱大约5分钟，当然可以进一步采用各种优化加速手段，例如psyco）。到时候，最主要的速度限制也许就来自网络带宽，上传多少即时鉴定多少。

　　未来某天的软件创业故事：逃课的小孩在大学宿舍里编写了一款网路游戏（比如，也许是跑在iPhone或Android上的多人联机MMORPG），上传到Google App Engine，再到常去的论坛发个帖子，邀请大家来试玩，结果这个游戏一炮而红，Google和中国电信作为基础服务提供商，对利润进行分成。这个故事不会很快变成现实，但是也不会很慢，技术演化总是被低估。

　　最近一期《程序员》开头有篇关于招聘的经验，第一条要求就是“对技术细节有激情”，真是所见略同。其实也是老生常谈了。记得还看过一篇国外文章，提到很多网络创业失败的原因在于，发起者是不了解网络和软件技术的商人，没有接触过优秀的职业软件工程师，甚至根本不知道出色的程序员和架构师应该是什么样。他们仅仅想找人把自己的idea实现出来，这就注定招到的人没有判断和反馈能力。Google的招聘邮件说，“技术天才是喜欢扎堆的物种，别让哪怕一个二流货色混进你的团队”。

　　类似的事，我们身边每天都在重复上演。作为老牌“人贩子”，我从大学二年级开始参与各种推荐、面试和考核。总见到招聘者出于各种原因（比如资金、关系、性格、印象、说辞）选择了不合适的人，给未来挖下大坑。

　　《程序员》还有一篇MMORPG架构师的文章，里面提到“赞成某位同行的单线程多进程思路”，一看就知道说的是云风。文章提到“分布式对象系统VS自定义协议”的选择问题，不过他坚持认为，分布式对象系统是更好的选择，专门提到了ice。也许他参加了SDChina2.0，搞不好，我问云风为什么不考虑ice时，他也在场。

　　一直感觉我和云风很像：年龄、经历、爱好和技术观点。云风刚发了一系列回忆职业生涯的BLOG，看了以后这种“相像感”更强了（这个，往牛人身上硬扯，实在有点傻）。“没有哪个程序员的代码一开始就能写的成熟稳健，我们都经过幼稚的年代”。选择太多，很多人无法坚持工程技术的积累，过早改变了职业生涯的方向。狐狸和刺猬最终谁会赢？

　　前些天太忙。现在有空列书单，最近两周买了勒庞的《乌合之众》、色诺芬的《会饮》、凯鲁亚克的《在路上》和尤金·菲尔德的《书痴的爱情事件》。

　　买色诺芬的书，是因为之前对《长征记》超级迷恋。

　　下班路上逛五道口光合作用，发现这本《在路上》，在回去轻轨上读完了第1章。但之后就没机会再翻开。这次随身带着，今天早餐后坐在农家院子里一口气看到第9章，也许是因为阅读环境本来就on the road，感觉很好。推荐。

　　BTW：那个时代，牛仔裤和爵士乐都是另类。昨日的叛逆，今天的经典。IBM的蓝衬衣曾经特立独行，挑战“白领”惯例；可是一旦成为时尚主流，“IT蓝”就显得陈腐。

　　憋了好久，今天出来吓人。刚刚抄送全组一封邮件：

　　从上午的述职报告开始就不断有人问，哪些招数带来了如此明显的性能改进？其实都是纯粹的工程手段，而算法流程方面并没有应用激进的创新思路，基本沿用了pFind 2.0里的成熟方案。

　　MYSQL被SUN收购，以及在此之前JBoss被Redhat收购，这段时间太忙没顾上点评。不过，两年前俺已经写了这篇足够好玩的BLOG，评价企业级软件市场的春秋争霸。

　　提起这篇BLOG，俺又在考虑用孔子的学生们来命名pFind 2.1的各个模块，比如冒冒失失的“子路”和善于周旋的“子贡”。若有漫画高手帮忙创作几幅卡通肖像，就更有意思了。

　　hp已经给两台服务器起好名字了，一台叫Donkey，一台叫Shark。都是兄弟们喜欢的电影角色。

　　这两天Shark很忙，2.1和2.0在上面来来回回跑测试。还有18个小时就是pFind 2.1 Alpha 1的deadline。时间一到，我就要从SVN下载源代码，编译，建索引，然后随机挑选一组数据进行鉴定，如果正确无误就算验收通过。“要是有纰漏”，我威胁浩哥说，“我就拉着你们一起跳楼！”。

　　一直听说那部获得奥斯卡最佳纪录片奖的An Inconvenient Truth很不错。据说戈尔实际上就是凭借这部片子获得诺贝尔和平奖的。今晚回家，发现中央电视台在播放这部片子，看过以后，果然很受震动。郑重推荐。这里是第一部分，我认为片子的开头和结尾是最出色的地方。

　　BTW：有意思的是，刚刚发现老白也在他的BLOG上提到了这部纪录片，他也是昨晚从中央台的数字频道看到的。

　　pFind 2.0昨天整理完毕，清理实验性或过时的算法，例如原有8个搜索流程只保留了最新的“发车模式3”。调整界面隐藏尽可能多的选项，以减少参数配置的出错机率。一口气删掉了5万多行代码。下周一pFind 2.0 final release，成为历史坐标。

　　这是四月初，我请全组到新家吃饭。Boss H在网上订的黑森林蛋糕，据说有四百多块钱。

　　最近一段，pFind 2.1开发进入关键战役，今天是第三个milestone，预计下午2点开始第一次集成测试。

　　按组里惯例，C++和Matlab版同时展开。fy大侠带M团队，我带C团队。C版只实现最成熟的技术路线，保证工程质量，关注速度和吞吐上限；而M版还要验证一些相对激进的思路，昨天一问，M版也在不断重构架构优化速度，代码质量很高。很期待两个版本的PK。以前各个软件C、M两个版本最后“对答案”时，或者异曲同工，或者不约而同，相互印证借鉴，很有乐趣。

　　周四要在全组讲pFind技术报告。为表示对一线开发者的尊重，除了简单提一下系统设计编码原则，我本人不会多讲，而打算让各个模块的作者亲自演示：先后实现了哪几种不同方法，跑了哪些数据和参数，在精度和速度上有多少进步……在所有人面前汇报自己创造的成果，体验成就感，鼓舞士气。

　　从本科大一假期到软件公司打工开始，我总是天经地义的开发主力。这次pFind 2.1却只扮演项目经理角色，不负责模块的具体编程实现。精力都放在接口设计、代码审核、双人编程培训、进度监控和文档上。心情有些复杂：不挽起袖子敲代码，就没有那种“百万军中取上将首级”的快感了。

　　刘未鹏今天的BLOG里，讲了一个关于思维方式的幽默段子。看得我在屏幕前笑起来：

　　笑还没收住，又收到fy今天从生物实验室那里交流回来发的邮件，他也听到一个异曲同工的段子：

　　今天在家又养了一天病。正事不能干，躺在那里就想些无关紧要的点子。比如给新版本的pFind2.1各个模块起名字。

　　不少科研团队都喜欢给产品和工作设备起昵称。微软Windows各版本的昵称都是加拿大滑雪胜地附近的景物；豆瓣用《指环王》里的角色命名服务器；我到过的一个生物学实验室里，每一台显微镜都用诺贝尔奖得主的名字来命名。

　　pFind2.0时代，我就想用NEO来命名蛋白鉴定引擎。但是，当时刚好在反向工程分析Mascot（pFind的头号竞争对手），脚本代码的注释里有不少程序员相互的玩笑和批注，发现他们居然已经抢走了这个好名字。我猜对方的研发人员里一定有不少MATRIX迷，这下知道他们为什么给自己的公司起这种名字了。

　　又考虑GATTACA。这部科幻电影对生命科学家的影响，就像MATRIX给程序员的震撼一样。主题上符合俺们pFind的生物信息功能。GATTACA这个名字是一种暗喻：它同时就是一段DNA碱基序列片段（人类基因组计划完成以后，网上也有好事者在人的基因库里做过blast）。

　　也想过用Made in China的东西。比如传统神话里的“孙悟空”就很酷，或者到中国科幻作家的作品里寻找灵感，例如刘慈欣的“三体”。不过已经有互联网公司用“孙悟空”来命名自己的搜索引擎了；后者又显得不吉利：不可解的十八阶积分方程，不可预测的动态体系，感觉好像BUG总也调不完一样

　　除肽鉴定引擎以外，pFind系统的其他模块都等着起名字。按以前的想法，它们也都是MATRIX里的角色：数据索引模块命名为“ORACLE”（那个先知老太太，她实际是一个拥有高级权限的内核进程，负责索引和检测MATRIX系统里的异常变量，协助系统升级）；日志和异常抛出处理部分叫“SUBWAY STATION“（NEO昏迷后，throw exception的地方，里头是个死循环，等待系统catch）；授权和注册码部分叫“MR KEY”（中国匠人，其实就是盗版软件里常见的注册码生成器）；肽到蛋白归并模块叫“ZION”（清醒人类的总部，所有飞船的基地，虽然，最后NEO发现，所谓真实世界，只不过是另一层Virtual machine，又一个MATRIX）……一旦引擎的昵称换了，它周围的模块都要跟着重命名。例如鉴定引擎叫孙悟空，其他模块就应该叫八戒、沙僧、白骨精什么的。

　　征求意见中，欢迎贡献灵感。大伙儿也可以秀一秀自己系统的昵称。

　　BTW：欧美科幻小说与理工研发领域的联系源远流长。科学家和工程师们都很喜欢借用科幻小说里的人和物。比如美军第一艘核动力潜水艇，就用凡尔纳小说《海底两万里》里的海底机器来命名。美国冷战高潮时期的太空军备竞赛计划，借用了电影《星球大战》的名字。反过来，小说家和电影人对科学的理解也非常到位。比如斯皮尔伯格的AI中，对人工智能、感情和灵魂的探讨。反观国内，影视编导往往把科学表达成了现代巫术，长生不老药和阿拉丁神灯的新版本。

　　在光合作用买了《塔西佗编年史》和《偷书贼》。

　　《塔西佗编年史》读起来感觉不如《塔西佗历史》有趣，大概因为后者描述的是暴君尼禄死后一年内遍及整个帝国版图的宏大内战：四个枭雄轮番登场，相互攻伐，罗马政权频繁易手，众多人物事件集中涌现；而前者记录的是此前四个元首统治的时代，是帝国逐步崩坏的漫长的堕落过程，里面有太多腐败、阴谋、放荡和残暴。

　　提到古罗马帝国的元首（imperator）和凯撒（caesar），很多书里中文翻译为皇帝和太子，其实它们和中国古代皇权概念是不同的。imperator名义上仍然是元老院选举出的领袖（特定条件下民众或军团也可以拥立），是披着共和外衣的独裁者，有时会由多人分享这个称号；对应的，caesar是对元首指定继任者的尊称，他未必与元首有血缘关系，不过经常被元首收为养子。

　　《偷书贼》的描述方式很特殊，整本书是由很多场景的记忆的碎片拼起来的，对我这种前后乱序乱翻的读法来说正合适。讲了个好故事，只是有些悲惨压抑，不忍卒读。

　　单从新闻摄影角度来看，这是一张特别有质感的新闻图片。

　　画面中的每个人：两个警察、女护卫者、记者、暴力分子、护卫车内的其他火炬手，分别作出各种不同的紧张激烈的表情和动作。而处于漩涡中心的独腿女孩和盲人青年，却保持着雕塑般的静态。火炬手冷冷的神态和坚定的姿势很容易打动读者。

　　以后若干年，可能我们都会把这张照片当作这次事件的象征。这是新闻摄影记者一辈子梦寐以求的作品。

　　说完客观的，就要说主观情绪了。我对政治没兴趣，不过这一次，他们真的惹火我这个小老百姓了。作为一个普通北京市民，向上海美女致敬。

　　刚刚发生了两件大事：

　　第一件，俺们的pFind 2.1版的开发完成了第一个milestone，万事开头难，比计划晚了2天。

　　第二件，Google发布了App Engine，看起来很牛很得力。 俺希望Guido van Rossum开发的那个传说中的Mondrian也可以加进去。

　　基本看完了上次说的几本古希腊罗马史书。不多写感想了，不是专业人士。

　　对比起来，在古希腊罗马，很多学识很高的贵族拥有担任将军或执政官的经历，由将领本人撰写战争史也是一种传统；而在中国古代，史官很少亲临战场，更别提作为主帅指挥战争了。因此我们的史书，例如同时代的《史记》，对军事行动的描述就往往比较粗略和肤浅；而色诺芬的《长征记》和凯撒的《内战记》简直就是经典的兵法教材：由著名统帅亲自带入重大战例现场，描述当时收到的各种战场信息，解释作判断的原因，并给出战争的后续发展作为验证。

　　收获？哦，这个，我是拿来散心的。

　　因为周围的太多人看过并推荐，包括Boss H和JW。今天和老妈逛第三极，买了冯仑的《野蛮生长》，回来一口气看完，的确很有阅读乐趣。

　　老妈在用http://www.haochi123.com/S_Caipu/Caixi/Yuanliao70.htm学炒菜。

　　喜欢集中性买很多本书，再并行处理，东一本西一本放着，随手拿起一本翻到某一页就看起来。这个月买的大都是古希腊罗马历史。包括修昔底德的《伯罗奔尼撒战争史》、色诺芬的《长征记》、凯撒的《内战记》、《亚历山大里亚战记》、《阿非利加战记》、《西班牙战记》（凯撒战记五部曲现在只剩下《高卢战记》哪里都买不到，悬赏收购，大伙帮我留心）、塔西佗的《历史》。再加上与古罗马历史有很多联系的马基雅维里的《佛罗伦萨史》。

　　“清风不识字，何必乱翻书”。据说蒋介石读书很严谨，必须正襟危坐，从第一页开始顺序慎读。这么老老实实当然很好，但真的很闷。如果你像我一样，每次都从某个随机位置开始读，除了期待接下来内容，也必须猜测之前的情节，这是一件很好玩的事。据说床上桌子上到处乱放书的坏毛病毛老爷子晚年也有。

　　“随机乱翻法”也是区分质量的有效招数，好书的前因后果总是比较难猜，即使是历史或传记。金庸和古龙的武侠，我都是从半路读到结尾，再回头去看前半截，仍然津津有味；而梁羽生的小说，就算最精彩的《七剑下天山》，看过几页就能把前面的情节猜个八九不离十。（另一方面，武侠小说的骨架大多是有借鉴的，金庸的《连城诀》来源于《基督山伯爵》，古龙的《流星·蝴蝶·剑》来源于《教父》，梁羽生的《七剑下天山》脱胎于《牛虻》，我读武侠小说时年龄小，还没接触到《基督山伯爵》和《教父》，只看过《牛虻》，也许导致不公平）。

　　本想上来写读书杂感的，没想到乱写了一堆别的。晚了，下次再写。

　　如果要给最头疼的C++特性投票，我会选ABI兼容：C++标准没有明确跨编译器的二进制兼容，于是各个编译器的实现都不同。用VC在Extension Dll里实现一个类，到了gcc代码里就不能直接调用。这带来了很多麻烦，尤其在有移植和平台兼容需求的大项目里。最近我的项目进行下一步规划，就为培训新手挠头。

　　更糟的是，这还导致其他编程语言不能简明地“胶合”C++：大多数编程语言的编译器或解析器都是以C/C++实现的。按理说来，在这些语言中调用C++的类应该是很容易实现的天然属性。但是正由于ABI不兼容，这些语言要支持C++二进制调用就必须先选择编译器：到底是支持VC还是gcc？因此很多语言避开C++，以纯C形式的动态链接库（Windows下就是Regular Dll）作为对外胶合的二进制接口。这进一步影响到不少混合语言项目选用C而非C++与动态语言进行高低搭配。

　　作为实现“底层硬核”的系统级语言，C++的调用接口这种基础机制不理想，负面影响有些大。

　　当然也有不少对应的解决方案。最有名的是COM，它利用类似虚函数表的方法，建立语言无关的接口兼容模型，微软把Windows系统的几乎所有的模块接口都变成了COM，比如ActiveX和DirectX。还有其他一些常用方案，像SWIG。普通一点的方法是用C语言接口做桥接。

　　前几天刘未鹏征求中国程序员给B.S.的问题，俺问ABI标准啥时候有指望。据说问题的关键不是技术，而是C++标准委员会各大厂商间的政治原因。

　　BTW：最近玩D语言，本来就是一帮C++高手另立山头搞出来的，自然是针对后者的软肋作改进，目前看起来的确很美好。不过二十年前C++刚从C里面蜕变出来时，看起来也很美。路漫漫其修远兮。