全站HTTPs的那些坑
“全站HTTPs”俨然成了目前的热门话题，很多网站都在摩拳擦掌要实行全站HTTPs。凑巧，我们（沪江）也在推行这个计划。
一开始大家想得都很简单，把证书购买了、配好了，相应的路径改一改，就没有问题。事实也确实如此，单个独立站点的HTTPs改造是很容易的。一旦走向“全站”，才发现事情远远比想象的要复杂，全站意味着所有资源面对所有客户端，涉及的因素异常多，网络上又没有太多资料，只能自己摸索。下面我简单讲讲遇到的几个问题，提供一些经验给大家参考。
再谈创业不是金字招牌
之前的《创业不等于职业生涯加成》是我根据最近的面试经历，随手而作，没想到创下了近期阅读和传播的新高。随之也引起了不少讨论，某些反对意见认为“创业并非一无是处”，并列举了创业能给人带来的技能上、性格上、思维上的各种磨练和收益。这些论据当然有道理，但是和我说的观点并无矛盾——“不等于”的意思是，不要以为你创过业，你的职业生涯就自动升华了。
说得更直接点，“创业”绝不是职业生涯中的金字招牌，单纯“为创业而创业”，很可能结果是头撞南墙、遍体鳞伤，却无甚收获。这次我把话题说更详细点，希望理解的人更多，误解的人更少。
前段时间一个工作不久的朋友跟我说，离开了某创业公司，才觉得之前的同事都很苦。他们做的是大量重复性的劳动，却是公司业务发展不可或缺的支柱。但是，公司完全是出于“降低劳动力成本”的考虑在安排这些同事的工作，低廉的待遇，超长的加班时间，唯一能维系大家的，就是公司创始团队对牺牲精神的强调，以及不断吹嘘的愿景，当然那些诱人的长期回报从来都只是若隐若现，没有扎实的落地措施。
正心诚意，当好面试官
面试，无论对哪家公司来说，都是件重要的事。
因此许多公司很重视面试，制定了面试规范，以及对面试官的一系列要求，网上关于面试礼仪的文章更是汗牛充栋。然而，很多面试的效果仍然不够满意。最显然的表现是迟迟没有找到合适的候选人——尽管他们本来合适的，更糟糕的是没有给候选人留下好印象。在这个“人人都有麦克风”的时代，这种印象很可能通过面试官和公司意料不到的渠道传播出去，造成一系列的麻烦。这种情况，相信是任何公司都不愿意看到的。
要如何避免这种问题？怎样才能真正把面试做好？在我看来，规范、技巧、礼仪都不是最重要的，最重要的是公司对待人才的态度，具体落实下来就是面试官的态度。如果面试官能做到“正心诚意”，面试的效果通常不会太差。
正心诚意，用直白的话说，就是两个词：尊重、诚恳。
创业未必给职业生涯加分
最近面试了很多技术人员，其中不少之前的工作履历还不错。但是，因为他们之前的创业经历，我并不能发offer。
看到这里先别着急下结论，让我仔细说说理由。
怀念孟老师
我本来是不应该认识孟老师的。
2001年，我在寝室夜谈里第一次听到孟老师的名字。当时有同学说“公共选修课的《法学概论》讲得真好，那个老师叫孟繁超”，开始我不怎么在意，慢慢才发现这么说的人还不少。那个年月网上的资料正丰富，出版管制也不那么严格，刚进大学不久的我正自由自在地看得过瘾，心想“大学里的法学概论讲再好，能讲些什么，还不是教科书上老一套”，所以这种课，不听也罢。
但生活就在这么奇妙。那年冬天，有天中午我吃过饭正准备午睡，忽然有人敲门问“计算机系有位叫余晟的同学在这里吗？” 大中午的谁会来找我？我正好奇这个问题，门一推开就有同学喊“孟老师，孟老师来了”。
尸位素餐的“软件工程”课程
按：本文的很多观点来自与七牛云存储首席架构师道哥（李道兵）的讨论，在这里对道哥表示感谢。
高校的计算机教育与时代脱节，这已经成为大家的共识。如果要问哪些课程脱节最严重，我的答案是“软件工程”。其他的课程虽然也有脱节，但多少有点用处：编程语言虽然不教怎么把程序写漂亮，至少教了语法；网络课程虽然没有形象直观的展示，毕竟通讯协议还在使用；数据库课程不讲数据库的安装和调优，关系代数理论仍然是不少问题的原型；数据结构与算法即便看起来与开发没有直接关联，有了概念总不会吃亏……
只有软件工程，是例外。顾名思义，“软件工程”讲的应当是把软件开发出来的学问。所以，它是名不副实的：如果你按照“软件工程”教的去做，多半开发不出来软件，至少开发不出好的软件。一方面大量毕业生不会写程序、写不出好程序，另一方面合格的“软件工程师”奇缺，对这种怪异的景象，名不副实的“软件工程”功不可没。
技术领导要不要写代码？
技术领导要不要写代码？这是一个问题。
我刚工作的时候就听说，程序员（那时候还没有“码农”的说法）是吃青春饭的，到30岁就熬不了夜写不动代码了，所以要尽早转管理岗。相应的，如果你走上管理路线成了技术领导，自然就不必干写代码这种低级重复的体力劳动了。所以当时自己代码写得很多，技术能力增长很快，但总感觉有点别扭。那感觉就像，你能把车开得又快又熟练，最终只是为了能按时到达机场赶上飞机。然后，你就再也不用开车了。
不过无论如何，赶上飞机看来是更高级的选择，为了它，放弃苦心修炼的车技也可以接受罢。
但是等我真正走上管理岗位，才发现事实和我想的完全不一样。当时公司的业务增长飞快，支持业务的系统却是几年前“一锤子买卖”的外包项目，更要命的是技术团队的人员组成和工作习惯还处在作坊状态。从我的角度来看，四下里全是大坑，填坑的速度慢得让人着急，在此过程中还经常挖下新坑…… 在我的职业生涯中，我从没有在那么短的时间里写过那么多代码。几年后大家查提交排名，我的名字仍然第一。好在我的努力没有白费，系统终于没有垮掉，顺利回到正轨。
当时我身为技术领导，除去招人、定流程、做运维，还花了大量时间写代码，这样的做法是对的吗？如果是对的，后来我再没有写过那么多代码，好像也与“不称职的领导”无缘，甚至还被夸奖过“忍住放手让下属去做事，锻炼了组织”，这又是怎么回事呢？
拒绝刻板印象
- 城乡差异，那必然是先进和落后的对比；
- 代际冲突，那必然是古板和文明的对比；
- 陆港矛盾，那必然是“不服穷亲戚”的心理作怪；
这样的论调我们已经看得太多了，每次有类似的事件出现，基本都可以装到“那必然”的框框里。那么我们能怎么办？什么也做不了。唯有时间是我们可以依靠的对象：等着，等着先进取代落后，等着文明战胜古板，等着“我们有钱了你不服也得服”。
这样真的对吗？我看不对。
读懂英文不容易
如今有一种流行的说法，说翻译的最大问题是中文，很多翻译的问题来自译者无法准确妥当地用中文表达原文的意思。这种说法暗含的前提是：译者能完整准确理解原文的意思。确实，现在大家的英语水平都有很大提高，读读英文材料都没什么问题。但是这也只是“读读”而已，真正要做好翻译，必须能读懂英文，而读懂英文恐怕不是太容易的事情。
很多人认为英文比中文更容易阅读。中文像写意的水墨画，讲究“文气流通”，不一定要有严格的主谓宾、定状补；英文则更像严密的组合体，讲究逻辑清晰、结构完整。总的来说这种说法没错，如果具体到非小说类题材，英文应当更容易理解。然而无论英文中文，文字背后的信息应当是连贯的，逻辑应当是自洽的，知识应当是有规律。这也不难理解，作者在文字背后的思维应当是顺畅的，不会前一段说天上后一段说地下好，上一段说东边好下一段说西边好——即便真是这样，也需要有恰当的转折。
在写作时这往往不是问题，因为作者是先有统一观念，明确知道自己要说什么，然后才落实为多段文字的，如果逻辑混乱经脉逆行，多半写不出来东西。但是读者和译者却是要反过来，要根据文字逐字逐段“还原”出来原作者的意思。读者没法钻到作者的脑子里去看看作者当时真正想说的是什么，只能通过文字来设想和拼凑译者“想说的东西”，如果是译者，还需要根据译者“想说什么”来对译文做必要的改动，保证译者“真正想说”的话得到了准确的传达。如果做不到这一点，哪怕单词都认得，搭配都熟悉，句子全明白，也未必能做好翻译。换句话说，这时候其实不算“读懂英文”。
从静不稳定设计说起
时常与一些同行朋友说起“软件难做”的话题，一方面软件确实挺难做，变数着实太多（推荐《梦断代码》），另一方面，让人理解软件难做，更是不容易的事情。如果说第一个问题靠苦练内功还能看到希望，第二个问题就近似无解而让人绝望了。下面两个场景，相信大家都不陌生：
头儿说：你们开发怎么这么慢？拿这么高的薪水，做事还这么慢？我急得不得了，只可惜我不懂开发。我如果懂，我去学校招50个码农，连续熬夜一两个礼拜，绝对可以做出我想要的系统。
头儿说：我真是对系统失望透顶了。想我以前刚创业的时候，七八个人，五六台电脑，什么事都是靠喊，那时候工作效率多高，人均产值多高？现在人才到几百个，就成了这个鬼样，说要上系统，上了系统有变好吗……
我有时候会想，这些说法在普通人看来似乎也没有错，但行业中人都知道错得厉害。那么，问题究竟出现在哪里呢？我想来想去，觉得原因大概在于，持这样说法的人往往只依靠来自生活经验的“逻辑”和“直觉”，还没有真正理解“软件”（或者说“系统”）到底是怎么一回事。