我已向Wired付费获得授权，翻译文章版权为译者本人所有，未经许可，不得转载。 1 Russel Guy怀抱着装满25万美元的公文包，来到爱沙尼亚的塔林市附近的直升机坪时，一架军用直升机已经停在那里了。Guy感觉不太自在，这里怎么看也不像军事基地，但是旁边站着的一看就是军人，而且带着枪。 这是1989年。苏联行将崩溃，部分军官正忙于出卖物资。Guy走近直升机坪的时候，大多数物资已经从直升机上卸下来，瓜分完毕。Guy想要的东西正是剩下的那些大箱子。他打开一个箱盖看货，闻到浓重的松树味。箱子里装的是另一个箱子，箱子之间垫着松针。Guy想，装货的人以前一定对付过缉毒犬，不过现在，他要的货可不是毒品。 苏联军方秘密制作了全世界的地图，但是迄今为止，只有少数外人见过这些地图。 这些箱子里都是地图，有几千张之多。每张地图的右上角都印着红色的俄文секрет，意为“机密”。 (more…)
按：今天在网上看到阮一峰推荐的《Hype Driven Development》，忍俊不禁，联想到工作中的很多经历又百感交集。趁春节假期翻译出来（练练手），与大家共享。 软件开发团队所做的软件架构或技术栈的决策，很多并没有经过踏实的研究和对目标成果的认真思考，而是不准确的意见、社交媒体的信息，或者就些是“热闹”的玩意。我称这种作派为“热闹驱动开发（Hype Driven Development，HDD）”，眼见它的危害，我赞成更专业的做法，就是“脚踏实地的软件工程”。下面我们一起看看HDD的来龙去脉，想想能如何改进。 (more…)
本文翻译自 TokuMX Fractal Tree(R) indexes, what are they? TokuMX的一大创新在于，它打破了一条长久存在的关于数据库的规则：要保证好的写入性能，索引的工作集应当能够放在内存里。标准答案是这样的：如果索引的工作集比内存要大，写入就需要执行I/O，I/O就会成为限制因素，性能就会下降。所以，要么让索引小到能全部放进内存，要么提供一种索引写入模式，避免工作集过大，比如MongoDB所采用的，内存中只为最近插入的数据保存索引。 但对TokuMX来说，这是绝对不成立的。依靠TokuMX所提供的创新性的分形树索引，索引的工作集可以比内存更大，同时写入性能不受影响。分形树索引为什么在重度写入（无论是MongoDB还是MySQL）的评测中能表现优异，原因就在这里。 (more…)
按：此为最近我翻译的《简约之美（Code Simplicity）》的译者序。 1776年，美国独立战争爆发，当时北美尚有很多民众对“独立”充满怀疑: “北美真的要脱离英国吗”、“新的国家需要怎样组织”,这些今天看来不是问题的问题，并没有清晰明确的答案。就在此时，有位叫托马斯•潘恩（Thomas Paine）的人站了出来，单枪匹马解开了人们心中的疑惑，大大鼓舞了北美民众的独立情绪，而他所依靠的，只是一本名为《常识》的小册子。 《常识》这本小册子说了什么呢？我随便摘录几句： 如果没有人监督，对国王是不能信任的；或者换句话说，渴望保持专制政权的欲念是君主政体的固有弊病 独立自主的问题不外乎意味着：究竟是我们将自己制定我们的法律，还是让这个大陆的目前和将来最大的敌人——英王来吩咐我们，除我所喜欢的法律以外不准有任何法律 让我们为宪章加冕，从而使世人知道我们是否赞成君主政体，知道北美的法律就是国王 200多年后再读，仍然可以感受到这些文字的力量，所以不难想象，在美国独立战争时告知民众这些道理，能发挥多么重要的作用——据载，在当时只有二百多万人的 北美，成年男子几乎人手一册《常识》。不夸张地说，这本书推动了美国建国的进程。 潘恩既不是高明的政治哲学家，也不是熟谙宣传的政客，他的书也谈不上多么高深，在我看来，主要原因是《常识》用朴素平实的语言把道理讲出来，告诉大家“原来是这样的”。换句话说，许多道理其实并不高深，但必须以“常识”的形式表达出来，大家才能听进去；否则，终究难逃曲高和寡的悲惨命运。 读者或许会觉得奇怪，一本技术书籍的译者序，为什么要花这么多篇幅介绍历史呢？之所以这么做，是因为我在翻译这本看似平淡无奇的书籍时，数次想到托马斯•潘恩的《常识》。我深刻觉得，在软件开发的各种书籍和资料中，也应当有类似《常识》的文本来告诉大家：道理原来是这样的，就是这样。 我相信，任何一位读者，只要认真看过全书，都会发现《简约之美》其实只强调了几条非常简单的道理： 软件是必然要变化的，变化乃是常态； 有变化就需要维护，随时间推移，维护成本会远远超过初期开发的成本，占据成本的大头； 因此，在软件开发中，最重要的是要降低维护成本； 维护成本正比于系统的复杂程度，所以要降低维护成本，系统的设计就应当追求简单清晰； 这链条看似简单，其实并非如此。不少有经验的开发人员，似乎对这类“道理”不屑一顾，他们更在意新潮的技术、先进的架构、流行的语言……新出了哪种类库，什么软件新发布了版本，大数据该怎么处理，说起来头头是道，但真刀真枪地写起程序来，往往错漏百出（甚至不自知）。 我曾经见过一套系统，设计和开发这套系统的人几乎用到了.Net的所有高级特性，但95%以上都用错了，结果就是系统层次混乱、类责任混淆、通讯完全不可靠。诡异的是，许多错误都属于“地雷”，如果业务一直维持在原始状态，它们几乎不会爆炸。不幸，业务无可避免地要扩展、要增长、要规范，于是地雷一颗接一颗地爆炸，只能投入大量优秀程序员，花比开发时多好几倍的精力，去维护和重构系统，才勉强保证了业务的发展。最终，当系统重构告一段落之后回头看，其实所谓的“维护”，也无非是“降低维护成本”，一点点地去掉之前那些花哨的特性，用简单的技术构建清晰的架构，而已。…
我为何爱读代码？你为何也应当爱？ 原文：Why I Love Reading Other People’s Code And You Should Too by Alan Skorkin 翻译：Yurii 我恨读代码 我发现，许多程序员都讨厌读代码——拜托别掩饰了，承认吧。差不多每个人都喜欢写代码——写代码乐在其中。可是，读代码真是不容易，而且还很烦人，又无可逃避，其他人写的代码总是很垃圾（即便不说，我们心里也这么想的）。即使自己写的代码，过几个小时再看也有点垃圾，过的时间再久点，就更垃圾了。那么，还有什么理由去看别人的蹩脚代码，而是不自己写几手漂亮的？能不能暂且忽略这个问题，花上几个小时看别人的代码，再回头来看自己的是不是还那么漂亮？即便有位大师坐在你面前，如果你不能从他身上学习，你永远也成不了大师。办法之一就是找到这么一位大师，让他手把手地教会你全部知识。有这可能吗？——当然有，只是很难遇到这顶好的运气。不过你也不必奢求那么幸运，做程序员这行就很幸运，因为大师们的所有思想和技艺都凝铸在他们的代码里，供我们学习。你要做的只是阅读代码——当然，如果有人给你一点点地讲肯定更节省时间，但这基本属于痴人说梦。换句话说，要相当个好木匠，得仔细研究大量的精美家具。 我热爱读代码，我总是直观地认为读代码的收获很大，没错，它可能有点讨厌甚至烦人，但你的收益绝对大过这点麻烦。举个例子，你要当大作家，是不是只关心自己写东西就够了？你可以试试看，但是估计不会折腾不出什么名堂。公认的事实是，多数大作家都是会如饥似渴大量阅读的。想写出好的作品，必须先阅读其他大作家的作品，吸收不同的风格，了解他人的尝试，然后才可以培养自己的创造力。这样，你的知识才能逐渐积累，最终你写的东西才有几分成熟，你也才会找到“感觉”。写代码也是这样，如果你不去阅读那些伟大的代码，怎么可能把程序写的漂亮？阅读伟大的代码之于程序员，就如同阅读伟大作品之于作家（我不敢掠美，这句话是Peter Norvig(译注：Peter…
欢迎转载，转载请注明出处。 Founders at Work, Chapter 12 Yurii 翻译 Livingston:你提到，Gmail最开始是“有争议的”，能接着说下去吗？ Buchheit:我觉得，一般来说，人们会不太适应不一样的东西。即使是现在，我谈到给Gmail增加新特性，除非是很小的改动，或是不改变现状，只做些调整，否则大家都不会喜欢。人们对“可能”的理解非常狭隘，相比真正的可能性，对于“可能”，我们的思维有许多局限。所以他们会不适应，他们有点喜欢想尽办法来反对。 但是我个人更钟爱新的东西，所以我总是非常愿意看看会发生的事情。这是我加入Google的最大理由。这理由足够强，强到我确信这是一桩好事：我只是觉得这很有意思，看到将要发生的事情，我很激动。 就这样，Gmail之所以让我激动，也是因为想看看大家会是什么反应。我喜欢某些不确定，因为这有点悬念、有点激动，好像是冒险，对吧？即便没有做成，你也可以从中学到很多。但不是每个人都喜欢冒险。许多人好像就是讨厌不确定。在生活的每个方面都讨厌不确定。 我忽然想起来，某段时间我问大家，如果他们在玩俄罗斯轮盘赌，有一把枪，枪有10亿个弹筒（或者非常多的，也就是说，他们被杀的可能性微乎其微），他们愿意花多少钱玩一盘？许多人都觉得这个问题很不礼貌，他们回答，“给我多少钱我也不玩”。但我们其实每天都在玩这个游戏。他们开车来上班，挣工资，其实一路都是在冒险，但是他们不希望知道自己其实在冒险。他们希望自欺欺人，假装一切都与风险无关。 (more…)
欢迎转载，转载请注明出处。 Founders at Work, Chapter 12 Yurii 翻译 Livingston： 那时候Google一门心思关注搜索，你有没有担心过自己的项目被抛弃？ Buchheit：一直都是。我还得说，现在看来Gmail很不错，但我们开发是很早时候的事了。Gmail是第一个真正偏离单纯“web搜索”的产品。Groups其实也依赖搜索——只不过它搜索新闻组里公开的帖子。 Livingston：Gmail还必须要邀请才能加入吗？ Buchheit：不用，你可以用手机申请。 Livingston：也可以通过Blogger，对吗？ Buchheit：我们已经向许多不同的方面开放了。大学生可以申请，我们希望开放给学生。 Livingston：为什么要邀请加入，这背后是怎么想的？ Buchheit：理由有好几个。我又得说一遍，邮件的问题很麻烦，不只是在数据规模那些方面。有个问题很重要，那就是，我不希望数据有任何损失，因为没人愿意弄丢邮件。如果web搜索出了问题，你可以退回去，重抓一遍网页，但是邮件不同，一旦丢了就不可挽回。 我非常关心系统的稳定性。策略之一就是控制用户的规模，这样就不会超出限制。你必须时刻确保当前用户享受到优质的服务。同样，这做法也约束了某些滥用email的行为，举例来说，这样发垃圾邮件的人就很难获得1000万个帐户——那样的后果很糟糕。 (more…)
欢迎转载，转载请注明出处。 Founders at Work, Chapter 12 Yurii 翻译 Livingston：还有哪些新特性是独创的？ Buchheit：对话视图——你打开某个对话，其中的所有邮件会像卡片一样列出来，而不是单独出现。 Livingston：这是你想出来的？ Buchheit：其实有好几个原因。其中之一是，我曾做过Groups，那里同样有归类(threading)。另一个是，我们内部有太多的邮件。 如果没有会话，就会出现这种情况：有人发出了一封邮件，有四个人回复了，五个小时之后还有人在回复，其他人会觉得，“这已经重复谈论过五次了，你还要回复。” 据我们观察，人们费那么大力气管理邮件的原因之一在于，他们尝试把对话归拢到一起。他们把邮件放到同一个文件夹——否则就会忘记，或是放错文件夹，对话就完蛋了，再也没法回复。 大家用各种工具和诀窍来管理会话。为什么不把它们直接归拢到一起呢？后来我们又想到，“我们来把引用他人的邮件内容隐藏起来吧”。因为这样阅读速度更快，而不需要浪费精力。我们同样希望集成IM聊天。做第一版的时候，我们没时间集成那个功能，但是很早的原型中就有聊天功能的，因为我们希望把聊天和email做到一起，这两者是一体的。所以，我们会从聊天的角度来看待email，所以我们给聊天加入email功能，而不是走其他的路。显然，聊天是为谈话服务的——没有人受得了分割成一条条的聊天纪录。所以，谈话视图也是从此而来——有段时间我们甚至把email的格式设定得更像聊天。 (more…)
欢迎转载，转载请注明出处。 Founders at Work, Chapter 12 Yurii 翻译 Livingston：这么说，你花了一天来做Gmail，而你不知道自己在做的事情的意义——之后呢？ Buchheit：很长时间里就只有我一个人，然后Sanjeef Singh加入进来。但是，在Google更换项目，尤其是那时候的Google更换项目，并不容易。不是说，某一天你就忽然去做一个新的项目了。那时候他正在做企业搜索，所以他还得花很多时间在企业搜索上。过了很久，Sanjeef才把大部分时间用在Gmail上。所以有很长的时间，Gmail的进展非常慢。 开始主要是我，然后是我和Sanjeev，之后另一个家伙Jing Lim也来了。团队的增长非常缓慢。做一个email那样迥然不同于Google传统的东西，这想法人们还是不太确定。 Livingston：你宣布：“这是了不起的东西，我们要发布了”。这是什么时候？ Buchheit：是发布几天以后。这项目很大。有些时候，我们似乎根本不可能完成它。 (more…)
Founders at Work是一本有意思的书，讲述了若干有意思的创业故事，我看得兴起，顺手把访谈Gmail创始人Paul Buchheit的一章翻译出来，给有兴趣的朋友看看。 欢迎转载，转载请注明出处。 Founders at Work, Chapter 12 Yurii 翻译 Paul Buchheit是Google第23名员工。他创造并领导开发了Google的Web邮件系统，Gmail，该产品引领了当今所谓“Web2.0”的众多特性。除此之外，Buchheit开发了Adsense的第一版原型，Google依靠这个程序在其它网站显示广告。在2000年一次关于公司价值的一次会议上，他提出了现在众所周知的公司信条：不做恶（Don’t be evil）。 尽管Buchheit算不上创始人，但他对Google的贡献，可能比其他许多创始人在创业时的贡献更大。Gmail其实是在Google内部诞生的——这是一个传奇般的项目，起初，它并不是公司的主要业务，只是由一小群人发起，而且，许多人开始并不看好它。 Livingston：讲讲事情的开头吧。Gmail是非正式项目（side project）还是公司指派的任务？ Buchheit：实际上两种因素都有。我很早就在做Email软件，当时大概是1996年，但只是个小项目。但Gmail的想法从来没有实现过。奇怪的是，大概因为一些别的理由，那时候我似乎就想叫它Gmail。这只是凑巧——它并不必然是Gmail的前身，却是我一直在思考的，因为我长久以来就对email不满意。…