Liangshan

Inner peace.

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 自己是不带国内社交网站分享的,要稍微做点功课。

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

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

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

Isolate Ansible Code and Source Code

我们经常要开发一些「系统」,这些「系统」具备以下特点:

  • 用到很多系统软件。比如 ngnix, compass, ruby, mongodb 等等;
  • 项目本身有很多组件组成。比如 web 程序,job 系统和对应的消息队列;

那么在开发这类系统时就会遇到一些问题:

  • 开发环境和线上环境不等价。平台可能不同,软件版本可能不同;
  • 开发环境配置复杂,任意环节出错就会影响整个系统的启动;

为了解决这些问题,我们将整个环境安装在虚拟机内,这在安居客被认为是一种最佳实践,成功的应用在很多系统的开发当中。 而开发环境,生产环境的部署则交给 ansible 来完成。那么我们的项目目录看起来是这样:

1
2
3
4
 .                  # root
 |-- .provisioning/ # ansible 脚本目录
 |-- src/           # 源代码目录
 |-- Vagrantfile    # vagrant 启动脚本

这样有一个好处,虚拟机启动之后,源代码对应 /vagrant 这个共享目录,修改源代码会同时在虚拟机内生效。 但这样 ansible 或是其他一些 CM(Configure Management) 工具的代码和源代码就会混在一个仓库内。

本文就介绍一种简单的方法可以将 DevOps 的代码与源代码隔离,并达到相同的效果。