Liangshan

Inner peace.

选择是一种能力

今年从不同的几个人嘴里都说出了一句话:『有时候选择比能力更重要』。第一次听见这句话,感觉说对了一半:想要有很多选择,首先需要有很强的能力才行,另外选择的过程本身就是一种能力的体现。这 2 个月的经历更让我坚信了这一点。

10 月份开始动了想换工作的念头,先说说为什么想换工作。其实我之前的工作可能在一些人看来是非常完美的,甚至是很多工程师的理想环境:公司的纯技术部门,简直是技术部的特种部队,可以按照自己的想法来实践方案,受到很多工程师和领导的尊重。

但我却感觉越来越不舒服。

我的技术哲学是,不仅要不断学习,更要实践。当时的实际情况是,我们几个想要推行一些新的实践时最后的结果往往是变成小范围的玩具。因为公司几年已经积累了太多工具和代码,基本上该有的都有了。好用不好用是一个问题,但起码够用,所以公司对于改进底层技术的意愿远没有说的那么强烈。这时我想起有人说重构的一个目的就是让工程师开心,这下我彻底接受这个观点了。

有时候太安逸真的是一个问题,对于公司如此,对于我来说更是深知这份「美差」不是好事。

几经面试,有了几个选择,而对方愿意给我机会还是因为我在架构部门的独特经历。同时公司也给出了足够的诚意来挽留我,给了新的部门和薪水。在这个过程中,我仍然相信是能力带来了选择。

在得知我在找工作后,有位前辈好心教导我,应该去大公司待几年,刷刷身份,前途无限。或许他是对的,但我想如果是那样,和我留下又有什么区别?除了可能公司名字更加响亮,可以认识更多的技术人之外,「大公司毛病」我想大同小异。得益于身边的几位同事,我对于所谓的大型架构和大牛早已看透了,选合适的方案解决问题而已,我想要的氛围是 ‘Move fast and breaking things‘,这句是来自 Facebook 的名言。说句题外话,GitHub, Google 或者 Facebook 当然是非常有吸引力,但似乎离我还有点遥远,压根也就没考虑。有人能帮我过去一定让我知道,千万别客气。

这时现在的公司出现在我的选择里,看起来很奇怪的公司。

是跨国公司,但又是初创公司;是互联网公司,却还没有自己成型的研发团队;团队的中国人都会讲英文,团队的老外几乎都会讲中文。兼职和外包是当时工程师的主要来源,这些为公司干活的工程师在世界各地,他们用 slask 交流,用 GitHub 托管代码,用 AWS 托管服务器,用 jira 来管理项目,用 xbox 在办公室踢 fifa,用 CEO 戴假发在球场当拉拉队。

一直以来,我坚持认为公司的技术部门应该走精英化路线。 第一,写代码说到底还是创造性劳动,效率和质量与人的能力不是线性关系,我觉得应该接近于指数。 第二,精英喜欢且只喜欢与精英一起工作。 第三,公司不需要因为开展新的业务而大量招聘,举例来说一个传统网站想要开展新的移动业务,只需要找到一个有丰富实践经验的人,就可以让所有人都变成 iOS/Android 开发工程师,因为精英乐于接受新的挑战。 第四,最重要的一点,精英基本不需要管理,只要给一个大家都认可的方向即可。

这里唯一的问题是精英难找,不过只要找到第一个,只要让他认可你的观点,就一定能找到第二个、第 N 个。在公司达到一定规模时,可以去学校招一些优秀的毕业生。这只是我的想法,没有实践过,比如说公司正在迅速成长,一下子哪来那么多精英可招?我认为精英比例虽小,但找几个满足一家公司的需求还是不难的吧?就看你有没有决心,有没有诚意。

一些迹象表明这个团队有希望成为我想象的那样,几经交谈,我决定加入这里。

让我们再从头看一次整个过程。安逸和挑战,我选择了挑战;去上市公司、留守、创业外企,我根据自己的内心做出了选择。由于这些年的积累获得了这些选择,而这些选择本身代表了我对于技术和事业的理解。

How to Choose RPC Framework

RPC 是 remote procedure call 的缩写,意指调用远程进程的方法。这里的远程需要广义的理解,有时为了协议的统一即使调用本地进程也叫做 RPC,所以 RPC 可简单理解为进程间通信。

在选择 RPC 框架之前,要搞清楚为什么需要 RPC? RPC 主要是为了解决服务化架构中客户端与服务端以及服务之间通讯的问题。在最早接触 RPC 的时候,我一直有一个疑问: RESTful API 不就搞定了么?为什么需要 RPC?直到深入实践了 RPC,我自己总结了 RPC 与 RESTful API 最大的几个不同。

到底什么是产品经理

不知道有多少人和我一样,即使在互联网公司工作了很多年,还是没搞清楚「产品经理」到底是什么样的一个职位。我甚至特意看过很多关于产品经理的文章,仍然没有搞清楚这个问题。而在工程师的圈子里,弥漫着对产品经理的各种,恩,各种情绪。上篇文章说了,我要用自己的大脑思考取得结论,到底什么是产品经理?

换个姿势写博客

之前一直看 Hack News,最近开始看国内版本——Startup News。 结果里面看到王垠的那篇征集女粉丝的博文,后来他删了又写了篇撤回征集女粉丝,现在第二篇也已经删掉了。

以前读过别人分享他的一些文章,并没有读过他关于具体技术的见解。 这次系统了浏览一遍现在能看到的博文,之所以说现在能看到的,是因为他会删除文章,并且不许评论,应该是一个完美主义者吧(其实删除会导致一些文章中的链接失效,也不算十分完美)。 其中发现了一篇 SQL, NoSQL 以及数据库的实质,读完之后的感觉是他看问题比我要深入很多。具体的细节我可能会单独写文章说明,不在这里展开。

所有文章都看完之后,我根本不想去评价王垠这个人,只想说他的文章给我带来什么思考。

能给人带来思考的文章都是好文章,他所写的每一篇都引起我思考。这只有一种可能就是他比我要厉害,主要是在思考问题的深度(无论对错)和在计算机科学学术方面。 学术和知识上比我厉害,这个其实很难追得起来(人家毕竟上了十年博士对吧,除去清华的 4 年,也还有 6 年 :P)。 但还好这个世界并不是谁学术能力强就一定取得更大成就。我稍微总结了一下,为什么他的文章能引发我思考。

首先是不信权威。完全不信权威难免有些绝对,我想更合理的理解这句话应该是,在选择相信权威之前先经过自己思考。只有当自己彻底想明白之后再接受别人的说法,而不是某句话听起来很酷,转身就变成自己的口头禅。直觉上大家都会认为自己不这样,但仔细想想这种例子其实太多。RTFSC 就是我中枪的一条,因为这是 Linus 大神说的。在这一点上我同意王垠的观点。别人期待的是你的经验之谈,而你甩出一句 「Read The F***ing Source Code」来伤害对方真的很酷?

其次是要努力看到本质。要看清技术的本质,需要很深的功力,这个也只能尽力而为了。但要时刻提醒自己,理解一个技术,需要从它要解决的问题根源开始思考,而不是看着手册学习手册。 比如我其实从来没有思考过「到底为什么要有 SQL」这种问题,我是说为什么是通过 SQL 这种方式来跟数据文件交互?因为习惯了 SQL,最开始用 MongoDB 之类的 NoSQL 的时候反而会不习惯,其实仔细想想 MongoDB 的交互终端才比较符合作为一个程序的用法。

从这一点上来说,这个博客虽然才写了几个月,但已经诞生了很多没有什么意义的文章。因为操作手册会过时,基本是没有意义的,但我应该不会删除它们。以这篇文章做分割线,看看以后会不会好一点。

我本来以为至少要几年后才会回头鄙视自己,没想到这个日子这么快就来了。

在 Gentoo 上安装 Awesome

都装 gentoo 了,趁热装桌面环境吧。linux 的视窗系统称为 X Window System。 在开源世界里,通常是协议先行,各自实现。同样 X 只是协议,在各种实现中以 X.Org 最受欢迎,当时使用的协议为 X11,所以后来 X 也被人们称为 X11。

使用 SystemRescueCD 安装 Gentoo

在使用 Ubuntu 有 3 年之后,第一次有了换个发行版的想法。 其实我觉得做任何事情都要循序渐进,在合适的时候做合适的事情才能事半功倍。

3 年前选择从 Ubuntu 入手应该是不错的选择,现在想换一个更自由的发行版也是水到渠成。选来选去,选了 gentoo,主要是在浏览的过程中以下几点吸引了我:

  1. 自由度高,一切从头开始
  2. 升级频繁
  3. 很先进的包管理工具

其实大多数时候我不是一个爱折腾的人,所以这次抓住了一闪而过想折腾的机会,第一天下午就开始动手了。第一个动作就是买一个 U 盘,是的,要准备一个 U 盘。

七年之痒

“七年之痒”是个舶来词,人的细胞七年会完成一次整体的新陈代谢,可能七年后你就不爱这个人了。

我跟老婆不知不觉认识已经有七年了。

但今天说的跟老婆没什么关系。

因为再往前就是工作的第七个年头。

Build a Scalable Recommendation System

从接触推荐系统以来,断断续续的已经有一年半的时间了。 今天想单纯从工程角度来总结一下我得到的经验,不涉及推荐的数学算法和理论。 第一是公司还没有到必须扩展现有的推荐算法的地步,第二是本人自知没有足够能力来改进现有的推荐算法。

其实主要是因为第二点。

总体回顾

在介绍可扩展的推荐平台我是如何设计之前,还是稍微回顾一下公司推荐的发展历程,因为这可能具有一定的代表性。或许在开展新的推荐研究时有一定参考价值。

诺基亚

我开始做推荐之前一直是我们数据部门的同学来做的,当时是使用 SQL 查询来实现了推荐的相关算法。想必这也是不得已而为之吧,最起码说明算法理论很熟悉:P。 调整一些参数或是新增推荐显然很痛苦。

但有总比没有强,在 iPhone 出现之前,诺基亚一直已智能手机自居。人们的感觉是跟智能有点关系,但总觉得怪怪的。这也是当时我们公司使用推荐的感觉。

Romar

在开始做新的推荐引擎之后,我们的思路就是找一个开源实现。很快就锁定了 Mahout,原因有以下几点:

  1. Apache 基金,项目的更新和质量有保证
  2. 实现了大多数已知的推荐算法,同时考虑了机器学习的其他两个分支:聚类和分类
  3. 分布式计算,为大数据而设计

但 Mahout 只是一个类库,我一直喜欢拿 Solr 和 Lucence 的关系来类比。 Mahout 类似 Lucence 是一个底层类库,并不是上层应用和产品。 于此同时,Mahout 版本的 ‘Solr’ 还没有出现,有几款开源实现但并不理想,也不是 Apache 官方的作品。

所以我们决定自己简单的在 Mahout 上面薄薄的搭一层 API 来提供服务,起了个名字叫 Romar。很快这个目的就实现了,项目可以在 GitHub 上找到。

Romar 1.0 的版本应该足以应付千万级别用户行为的协同过滤计算,所以很快在公司内部得到了快速应用。 得益于其能够快速响应业务需求的特点,短短半年内覆盖了公司所有产品线,这也算技术推动产品的经典案例了。

但问题随之而来。

管理这些推荐引擎变得痛苦,越来越多的实例。它们的管理成了最大的问题,包括部署、监控、可靠性、平滑升级。

如何将 Octopress 的文章分享至微信和微博

昨天想把自己的文章分享到微信,没有仔细思考选了一种很土的办法。就是直接在微信的内容里输入地址,容易出错不说,效率也很低下。 今天再回头思考这个问题,想到可以像 twitter 和 google+ 一样做一个分享按钮。Octopress 自己是不带国内社交网站分享的,要稍微做点功课。

我为什么如此反感在公司放广播

最近公司决定在早中晚全公司范围内播放广播。早晚内容是「广告」和「司歌」,中午是罗振宇的「罗辑思维」片段。

对此我在微信上表达了强烈的愤怒,措辞很激进。坦白来讲,我倒是希望有人传话给决策者,让他们知道我的愤怒,不是我不想混了,因为我相信我有足够的理由和众多的支持者,只是大家都不敢出声罢了。