我的父母都是大学生，但严格说起来，我家并不算“知识分子家庭”：我父亲是学无线电的，母亲是学分析化学的。充其量也只算是“双料理科”家庭，少点人文气息；小时候没读过什么人文经典，不过爸爸妈妈从来都不给我太多的限制，只是根据我的兴趣，讲讲各种有意思现象背后的原理。而且，托“理工科”的福，我很小就在母亲实验室用氢气充过气球，用水银温度计测过温度，用比自然教科书上精密得多的仪器制过蒸馏水；也在父亲实验室的示波器上见过各种无线电波的“样子”，在中秋节用天文望远镜看过月亮上的环形山…当然，为此也弄过不少笑话：小朋友们都喜欢互相吹嘘自己父母的工作，有的说自己爸爸是解放军，有人说自己爸爸是大干部，我说“我爸爸是研究电子枪（电子枪是阴极射线管显示器里的元件）的”，当即引来大家的不服气，而且老师也没听说过什么是“电子枪”，于是宣布我在吹牛……
读大学之后，曾有一段时间我总抱憾小时候缺了“人文经典”的课，但这些年陆陆续续看了些书，看法又有改变：虽然没动多少人文，但大言不惭地说，好歹受了点科学的熏陶。真正的科学，总是能“养住”人的好奇心，把精力引导到大千世界的奥妙中去；即便不从事尖端的科学研究，多了解一点点科学，也能大大丰富自己的认知，看到与之前大不一样的世界，生活也会因此多了不少妙趣。
但是，要保持对科学的兴趣，对我们来说并非易事。现在许多人说起“科学”，想到的要么是不苟言笑、木讷寡言的孤僻，要么是全知全能、四处指点的霸气，所以多少有些“敬而远之”的味道。我有幸从小就接受科学的“浸染”，能够以柔润自然的方式体会到科学的妙趣，欣赏知识之美，并保持至今；另一方面也时常有些惋惜，我们本身就缺乏科学的传统，当今的科普又缺乏“柔润”，所以科学或被奉为神明，或被斥为外夷，总之就是“科普不得法”，许多人抱怨生活无聊乏味，这或许也是原因之一。
不过，科学松鼠会算是科普中的异数。借用革命导师的话说，“让科学流行起来”的口号，给科普增加了中国作风和中国气派；虽然某些人觉得不够严谨，但事实是最有说服力的：以我的经验来说，活动总是妙趣横生，嘉宾也总是和蔼严谨，这正是我所欣赏的“柔润”的方式。尤其是创始人姬十三，我见他之后最高兴的是：如今终于可以正经讨论我看《恐龙特急克塞号》时的奇怪念头——“如果几千万光年外的外星人，看到了恐龙灭绝的情形，用录像机录下来，再传回地球，我们就可以知道恐龙灭绝的原因了”，这样的人作“大当家”，还有什么好说的？后来参加“科学嘉年华”的经历，更是肯定了这一点。
在北京的时候，我参加过松鼠会好几次活动，大感意外的是，有许多年轻的家长带着孩子来参加松鼠会的活动，看到他们，我总是想起自己的童年，继而心生羡慕：他们要更加幸福，因为他们遇到的科普更丰富，更好玩，也更深刻；这样的孩子，一定能从容面对科技更加发达的生活。
今天看到松鼠会“寻科学逃兵”的活动，我立刻答应帮忙吆喝两声：年轻的时候，能做点自己真正喜欢的而又有意思事情才好，哪怕累，也是有意思的累（借用韩寒的话说，等你老了回忆自己的年轻岁月，至少敢说真正做了点有意思的事情）；真正对科学有兴趣的同学们，不妨大胆去争当“逃兵”，我相信，科学的逃兵，能在松鼠会“淘”出点意思。
——————————【北京 and 上海】招聘职位分割线—————————–
http://songshuhui.net/job/
从某种意义上说，人的一生，就是不断突破个体经验的局限，解决未知问题、体验未知生活的过程——否则，我们只需要简单重复劳动，就足以应付了。也正因为如此，要避免在未知局面下的束手无策，借鉴前人/他人的经验，就是非常有效而且高效的做法。今天我要谈的这本书，正与他人的经验有关。
97 Things Every Software Architect Should Know ，这是一本很“奇怪”的书，书名很“托大”内容很“平实”的书。我与这本书结缘也很奇特：去年博文视点的编辑徐定翔告诉我，正在翻译一本书，请我帮忙看看译稿，提提建议（后来才知道译者还有阿里B2B的章显洲）。我虽然没做过架构师，但恭敬不如从命，就答应了。
开始，我关注更多的只是文字和专业名词/术语方面，从技术本身的考虑比较少。因为一来自己不是架构师，也没有这方面的经验；二来，这种口气的标题，总觉得有点狂妄。不过，跟着译稿一篇篇看下来，我的看法逐渐改变了：虽然这本书更类似97篇随笔，但到底是经过选择和编辑的，即便“随笔”，也是围绕着“软件架构师”的“随笔”，它们大致勾勒了架构师这个职业的方方面面——职责、权力、问题等等，我之前以为架构师更多地偏向技术方面，也就是负责“规划”整个软件系统的结构，但本书各位作者，都认为架构师应当是甲方和乙方之间的桥梁，一方面，负责准确理解客户的意图，另一方面，拿出规划给技术部门实施。也正因为这种定位，软件架构师虽然大都是从技术人员成长而来，却不能继续埋头在技术（技术架构）的道路上走下去，而需要补充多方面的知识，培养多方面的能力——怎样与客户沟通，怎样选择合适的架构（不能仅仅从技术方面考虑），怎样说服（注意不是命令）技术部门采纳自己的方案。书中不仅点出了这些问题，也给出了一些解决的建议；譬如第85章就告诉读者，说服甲方，仅仅依靠技术的术语是远远不够的，必须把整个技术方案包装成有吸引力的商业模型，这样说服力才会大大增加。如果希望成为称职的软件架构师，此类知识还是尽早了解的好，毕竟，都依靠自己去摸索，在挫折中学习，实在很不划算。
鱼与熊掌不能兼得，随笔专辑性质的书，照顾了“广”，就难以照顾“深”，因此，在亚马逊网站上，指责的意见都是针对这方面的：lack of detail，random accumulation…。但是我想，书有很多种，定位当然也不一样，应当各司其职——满足了自身定位的书，就是“好书”。这本书也是如此，读者权当这是在旁听架构师的茶话会好了——资历尚浅的听一听，开阔开阔自己的眼界，资历深的听一听，整理整理自己的经验，都能收获愉快的阅读体验；况且，还有平时难得听见的“小道消息”——世界上最先进的F22战斗机，对飞行控制的要求极端严格，应当选择怎样的软件；M1A1艾布拉姆斯主战坦克，开炮的时候会产生极强烈的电磁脉冲干扰计算机工作，这情况下要采用什么数据库……
旧事难忘，一声惊午梦；新风振起，万里看朝霞。
我研究了一天的立体几何，终于把全部家当塞进了小切:)
翻译时经常遇到的一些词语和结构，译者往往会用固定的办法来翻译。后果之一就是，译文中“翻译体的特征”很明显，许多时候我们都可以透过译文，“看出”原文，这样的译文，难说地道。when的翻译，就是一个很好的例子。
当规则不够清晰，或者不是每个人都清楚这一情境是什么，或者当人们不同意规则应该被应用在某一特定场景下时……
看到“当”，一般人会条件反射地想起when，知道这是“当……的时候（时）”的结构，再接下去阅读。但是，中文里较少出现“当……”而没有“的时候（时）”的情况（“当我想你的时候”比“当我想你”更普通更流行）。所以，无论是翻译还是阅读“当……的时候（时）”结构，都会惦记着最后的小尾巴——“的时候（时）”，如果中间部分足够长（譬如上述第一个例句），就露出尾大不掉的毛病：当 + 一个近乎完整的长句 + 的时候（时）。
一，准确理解when的含义。
如果规则不够清晰，或者不是每个人都清楚此情境，或如果人们不同意规则应该应用于某一特定场景……
这种说法足够地道，相信不少人都还记得中学数学的解题步骤：若 X>Y，则……若 X<Y，则……。
二，掐头去尾。
当我心情好一点的时候，就给你打电话 -> 等我心情好一点，就给你打电话
当然，有时候也可以更进一步，把头尾都去掉，来看这个例子：
当他忙的时候，他就顾不上其它的事情了 -> 他忙起来就顾不上其他事情了。
同样道理，开头的第二个例句，就可以修改为：
我询问自己性别课上的女学员为什么要做这件古怪的事情，她们回答说……（她们的回答，必然是针对你的提问，这是不言自明的）
老话说“业精于勤，而荒于嬉”，这是非常对的。许多朋友认为我写正则表达式很有经验，其实不然，我虽然翻译《精通正则表达式》，其实自己写正则表达式的机会并不多，充其量是帮朋友写写一些“够用就好”的表达式，在“精于勤”的朋友面前，是不值一提的。
相反，2010年1月11日晚我在上海龙阳路地铁站附近见到的两位朋友rex 和cnhacktnt ，都是“精于勤”的榜样：因为工作的原因，他们几乎每天都需要用到正则表达式，所以他们几乎是“全方位地”精通正则表达式：对语法的精确把握，对未知情况的处理，对匹配效率的要求……或许平时我们不需要注意这么多的方面，但多了解一点经验以供借鉴，总不是坏事。撰写高效率的正则表达式，需要注意哪些方面 ？更极端一点：正则表达式怎样匹配“0…1…”但‘0’和‘1’出现次数相同的字符串 ？这样的问题，对正则表达式没有相当研究和经验的人，是无法回答的。而答案和讨论，也让我这种半瓶醋看得眼花缭乱，大呼过瘾。http://www.regex.me ，大家有任何关于正则表达式的疑惑，都可以提问讨论，对《精通正则表达式》有什么意见，也可以自由发问，我会尽力解答。
我曾写过《稀释》 ，也一直认为，世上许多事情的道理，就是“不讲道理”：你做了十万分的努力，对方可能“只能”感觉到十分；若觉得这不够公平，而只做九万九千九百九十九分努力，对方就很可能连一分都感觉不到。
所以，我在第一时间发布了《技术领导之路》 的勘误。惭愧之余，也希望各位读者，如果发现更多错误，一定来信指正。
《技术领导之路》（中英文对照版） 勘误：https://www.lifesailor.me/batl_errata 。
另：《精通正则表达式》（第三版） 勘误列表也已单独列出，烦请大家移步https://www.lifesailor.me/mre_errata 。
有个故事是这样说的：一群傻子，每人得了一笔钱，纷纷去开加油站，因为他们傻，所以加油站如天女散花一般开得到处都是，高山上有，峡谷里有，池塘边有，平地旁也有；也因为他们傻，所以咬定青山不放松，坚持不换地方；结果，过了几年，只有平地旁的加油站存活下来，其它地方的加油站都销声匿迹了。Variation ）而出现不同的个体，这些差异又被后代继承（Inheritance ）下来，经过自然环境的选择（Selection ），最终有一些个体表现出适应环境（Adaption ）的特性，生存下来。本来毫无方向的随机变异，与自然条件较量之后，最合适的个体存留下来，表面看来竟然是“被定向选择”的结果。达尔文的学说，大致就是这么回事，更简洁点说，就是Darwin’s VISA 。《对神创论呓语的15点回复》（一） 、（二） 、（三） 、（四） 、（五） ），即便是“相信”进化论的人，也多半“都以为自己懂进化论，其实只是一知半解”。故而，把达尔文的理论梳理清楚、阐述明白，是一件非常有意义的事情，也正是本周日（11月15日）松鼠会 组织的“达尔文与达尔文革命”讲座 的目的。
本次的主讲人是王道还先生，王先生来自海峡对岸（现任台湾中央研究院历史语言研究所人类学组助理研究员），讲座的当然也不同于我们常见的风格，他能恰到好处地把每个“知识点”后面的故事娓娓道来，颇有令人耳目一新的感觉：
达尔文虽然身为科学家，却是不同于当代的职业科学家，而是一名绅士科学家，对职业科学家来说，科学是工作（job），而对绅士科学家来说，科学是召唤（vocation），当然，这也与19世纪的社会环境有关；
达尔文身世煊赫，外祖父是Royal Potter，祖父是Royal Doctor，仅凭此，他其实不需有所作为，也可以过上殷实的生活，也不会是默默无名的小辈；
达尔文先在爱丁堡大学念了两年医学，又在剑桥大学念了三年神学，真正有兴趣的，却是自然史，所谓自然史（Natural History），更确切的说法是“自然誌”，因为在古希腊语中，history的含义乃是inquiry。
达尔文能登上小猎犬号进行环球航行，是因为小猎犬号的船长费兹罗（Robert FitzRoy）需要一名随从，当时英国海军的船长不容许与船员有私交，所以费氏报告要求一名随从陪同航行，“可进行自然史研究”的招牌，通过费氏父亲所在的剑桥大学校友圈子，吸引到了达尔文；
达尔文登上小猎犬号，收到费兹罗的礼物——赖瑞的《地质学原理（第一卷）》，依靠这本书，他完成了关于自然史的训练；到了南美，尤其在智利，先后见识到火山爆发和地震，他由此开始想到，五花八门的自然奇景，可能并非上帝的创造，或许也是大自然伟力的结果；
……
仅仅讲述这样的小故事，也就难免沦为《你可能不知道的xx点》之类的轶事文章；可如果把这些小故事一一对应到达尔文的学说，再把来龙去脉梳理明白，就是需要兴趣和功力的事情了。而且，王先生更上升一个高度，说明演化乃是永恒的过程：生物要生存，就必然对环境有所影响，而受其影响的环境，又要重新“选择”生物，这种动态平衡的过程，就是“演化”。他纵横捭阖达尔文理论的劲头，让我想起 James W. Loewen讲美国历史
王先生认为，达尔文的理论应该是“演化”而不是“进化”，“进化”应当是Progression，有明确的标准和方向的，这一点我很赞同。但是中文的“天择”就难免误导：在中文里，“天”并不对应物质自然，而更多带有人格特性、道德色彩，所以“天择”的说法难免让人误解为“苍天（上天）在选择”；
王先生也提到哈耶克与达尔文思想的相似性，恰好，我也稍微读过一点哈耶克（国内出版的译本几乎全部读过，英文原版也稍有涉猎），这确实是一个有意思的问题，哈耶克也提到，货币之类文明产物，并非“智慧设计”的结果，而是在人类历史中不断选择、淘汰的结果（所以统一计划经济必然导致文明的灭绝），但是，达尔文研究的是自然问题，哈耶克研究的是人类社会问题（王先生也说，自然选择的问题，与意志和动机无关），二者虽有相似之处，但是否可以互为佐证，在我看来，还没有确切成立的论证。
2009年3月的一天下午，我在某家饭馆静候各位已知未知朋友来相聚。七点多，进来一位文静白皙的理工男 ，虽然不认识，但听他打探的口气，我确认他是来这桌吃饭的。打过招呼，才知道是松鼠会 的大掌柜姬十三（想起来真荣幸呀），我连忙说“我知道你们我知道你们，德国之声评选十佳中文博客的时候我就知道你们了……”。《第一推动》丛书 ，到科普先驱站点三思科学 ，再到妙趣横生的博闻网 ，都成了我们的共同话题；最后我还说起了自己幼年的奇思妙想：既然我们能看到几千万光年外的星球“几千万年前”的样子，那么，距离我们几千万光年外的外星人（如果有的话），是否可以看到地球上的恐龙是为什么灭绝的，用录像带记录下来，再发送回地球（如此一来，几千万年后我们就“可以”看到恐龙究竟是怎么灭绝的）？这个“异想天开”的想法，姬十三丝毫也没嫌弃，反而正经地跟我讨论了一番可能性——这样的“待遇”，对我这种“科学票友”来说，算非常非常难得咯。科学嘉年华 ”大型科普活动，我就非常有兴趣参加了。
Continue reading 让科学流行起来——“科学嘉年华”活动侧记
beta技术沙龙 越办越有意思了，上次错过了阙宏宇的mod_cache （还有关于线程进程的讨论）就很可惜，这次关于Lucene的演讲，是无论如何不应该错过了。
到目前为止，全文检索已经完全不算高技术门槛了，记得以前看过一本书里面写：“今天，任何程序员，都可以很容易地构造一个全文检索应用”。是的，全文检索的基本原理大家都知道差不多了，剩下的只是实践。我见过纯粹自己开发的，具有AS（Advanced Search）、BS（Basic Search）、DI（Digest）等结构，“像模像样”的全文检索架构，不过应用更多的，却是在开源项目上完善、定制而来的，Apache的Lucene 就是众多开源全文检索项目中，名气最大、资格最老、应用也最广泛的一个。本期beta技术沙龙，讲的就是大型网站中lucene的应用 ，主讲人是手机之家 团队的唐福林（“手机之家”总是有些东东来共享，比如上次的DAL ，这真是不错）。
众所周知，用Lucene构造一个“索引－查询”的应用是非常简单的，搭好环境，参照（修改）示范代码，很容易就可以成功。但是，要构造一个真正大规模、稳定、可靠的应用，就不说这么简单。程序的编写、模块的分布、架构的设计，都有许多费心思的讲究。按照PPT提供的数据，手机之家目前的Lucene应用，采用的是Lucene 2.4.1 + JDK 1.6(64 bit)的组合，运行在8 CPU, 32G内存的机器上，数据量超过3300万条，原始数据文件超过14G，每天需要支持超过35万次的查询，高峰时期QPS超过20。单看这些数据可能并没有大的亮点，但它的重建和更新都是自动化完成，而且两项任务可以同时运行，另一方面，在不影响服务可靠性的前提下，尽可能快地更新数据（如果两者发生冲突，则优先保证可用性，延迟更新），其中的工作量还是非常大的。
演讲的主要内容都PPT里，非常丰富，我就不再赘述了。要补充的是，这份PPT做得非常清楚，需求-目标-进度-设计-上线-测试-上线，整个流程非常清楚，给出的数据同样非常精当，我想，这也反映了手机之家团队的开发规范。
因为对Lucene的使用稍微有些经验，我在这里补充几句，权当狗尾续貂：
在大规模的应用中，Lucene更适合用于狭义的“搜索”，而不应当负责数据的存储。我们看看Lucene的源代码也可以知道，Document和Field的存储效率是不够好看的。手机之家的团队也发现了这一点，他们的办法是，用Lucene存放索引，用Memcache + Berkeley DB(Java Edition)负责存储。这样有两个好处，一是减小了Lucene的数据规模，提高了程序的效率；另一方面，这套系统也可以提供某些类似SQL的查询功能。实际上，Lucene Project自己似乎也注意到了这个问题，在Store中新增了一个db选项 ，其实也是利用的Berkeley DB。如果仅仅用Lucene存放索引，而不存放Document，并且合理配置，一台机器可以支持几十G甚至上百G的索引；如果需要用Lucene存放索引，最好在读取时使用FieldSelector，只读取需要的Field，如果使用恰当，性能会有10％左右的提升。
在大规模应用中，Cache是非常重要的。PPT中也提到，可以在程序提供服务之前，进行几次”预热“搜索，填充Searcher的Cache。据我们（银杏搜索 ）的经验，也可以在应用程序中，再提供针对Document的Cache，这样对性能有较大的改善（同一个JVM内部的Cache，速度更快一些）。Lucene自己似乎也注意到了这个问题，在2.4版本中提供了Cache ，并提供了一个LRU Cache实现 。不过据我们测试，在极端情况下，这个Cache可能会突破大小限制，一路膨胀最后吃光内存，甚至从网络上找的许多LRU Cache实现在极端条件下都有可能出现这样的问题（这也是我们百思不得其解的地方：反复检查程序的逻辑都没有问题），最终自己写了一个LRU Cache，并修改多次，目前来看是稳定的。
在编写Java服务程序的时候，记得设置退出的钩子函数（RunTime.getRunTime.addShutdownHook ）是一个非常好的习惯。许多Java程序员都没有这种意识，或者有，也只是写一个finalize函数，结果程序非正常退出时，可能造成某些外部资源的状态不稳定。拿Lucene来说，之前的IndexWriter是默认autoCommit的，这样每添加一条记录，就提交一次，好处是如果中断，则之前添加的记录都是可用的，坏处则是，索引的速度非常低。在新版本中autoCommit默认为False，速度提升明显（我们测试的结果是，提高了大约8倍），但如果中途异常退出，则前功尽弃。如果我们添加了退出的钩子函数，捕获到退出信号则自动调用writer.close()方法，就可以避免这个问题。
目前的Lucene是兼容JDK 1.4的，它的binary版本也是JDK1.4编译的，如果对性能要求比较高，可以自行下载Lucene Source Code，用更新版本的JDK编译出.jar文件，据我测试，速度大约有30%的提升。
如果对并发的要求较高，可以考虑采用多IndexSearcher的技术，也就是在一个应用服务中，开启多个IndexReader（可以对同样的索引开启多个），每个IndexReader再生成一个IndexSearcher ，将这些Searcher放在一个“池”里头，给搜索请求调用。这样可以大幅度提高并发的性能，代价是在写程序的时候就要考虑到这一点，进行相应的调整。
P.S. 据我观察，国内公司内部的项目，一般取的名字都中规中矩，以’er’结尾的比较多，多是Indexer, Crawler, Layer之类。好像很少有外国那种“天马行空”的奇特名字，譬如Hadoop（这是一个“没来由”的名字） 、Lucene（这是个少见的姓） 。国内我接触过不多，以前抓虾有个重要的DB叫tudui（“土堆”），目前银杏有个项目叫LaserTank，都是跟实际用途毫不相关的，印象反而深刻。
出版两年之后，《精通正则表达式》 马上要第四次重印了，这个消息很是让我兴奋。
我读大学的时候，有幸接触到侯捷老师的许多文章，尤其是他谈关于选择技术书籍的言论，感觉受益匪浅——正是从此，我深刻认识到，“学习”的宾语不应该是“教材”，而是“知识”。认识到这一点，就豁然开朗了；当然，也无比真切地知道了好的书籍是多么重要。
另一方面，我也深信，总的来说，知识的价值是在传播中实现的。我经历过“有了新的收获自己保密，一人独享”，也经历过众人把自己的心得拿出来分享、彼此协作的环境，两厢对比，后者提供的满足感远远超越前者。因此，有更多的人迅速学会“卑之无甚高论”的正则表达式，不需要重走我自己当初学习的弯路，对我来说，也是一种不小的满足（相比之下，帮人写各种表达式所得到的满足，实在是“很小很小”）。
在这里还要感谢博文视点的编辑许莹 ，她细心地把目前勘误列表 列出的所有错误都做了订正。因为《精通》一书中存在的错误，始终是我的一块心病。
另外，要兑现我年初的计划，今年要写一本关于正则表达式的书，正好在这里征集大家的意见：你们是期望它更加“下里巴人”，包括Word, EditPlus等等常用软件的应用例子，以应付更广泛的工作呢；还是希望更加“阳春白雪”，与狭义的“IT行业”（也就是开发）靠的更近呢？ 或者有什么别的想法，还请不吝赐教。
