Liangshan

Inner peace.

在 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 的代码与源代码隔离,并达到相同的效果。

The Twelve-Factor App

前些年翻译的 12-factor。一直放在公司内部的博客上,现在复制一份过来。


中文翻译:梁山
英文原文:Adam Wiggins

翻译问题反馈

简介

如今,软件通常会作为一种服务来交付,它们被称为“互联网应用程序”(web apps),或“软件即服务”(SaaS)。这篇“互联网应用的十二要素”为构建如下的互联网应用程序提供了指导方法:

  • 使用标准化流程自动配置,从而使新的开发者花费最少的学习成本加入这个项目;
  • 和操作系统之间尽可能的划清界限,在各个系统中提供最大的可移植性
  • 适合部署在现代的云计算平台,从而在服务器和系统管理方面节省资源;
  • 将开发环境和生产环境的差异降至最低,并使用持续交付实施敏捷开发;
  • 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展

这套理论适用于任意语言和后端服务(数据库、消息队列、缓存等)开发的应用程序。

背景

本文的贡献者参与过数以百计的应用程序的开发和部署,并通过 Heroku 平台间接见证了数十万应用程序的开发,运作以及扩展的过程。

本文综合了我们关于 SaaS 应用几乎所有的经验和智慧,是开发此类应用的理想实践标准,并特别关注于应用程序如何保持良性成长,开发者之间如何进行有效的代码协作,以及如何 避免软件污染

我们的初衷是分享在现代软件开发过程中发现的一些系统性问题,并加深对这些问题的认识。我们提供了讨论这些问题时所需的共享词汇,同时使用相关术语给出一套针对这些问题的广义解决方案。本文格式的灵感来自于 Martin Fowler 的书籍:Patterns of Enterprise Application ArchitectureRefactoring

读者应该是哪些人?

任何 SaaS 应用的开发人员;部署和管理此类应用的运维工程师。

安居客导师指南

安居客近年来非常重视校招,尤其是研发方向。实际操作下来,感觉校招还是不错的选择,这次我主要站在公司的角度来说。

使用 Virtualenv 绿色安装 Ansible

Ansible 是一个自动化配置管理工具 (Automate configure management)。用 python 编写,所以安装方式一般有以下几种:

pip 安装

1
$ pip install ansible

MacOS 用户可以选择使用 homebrew 安装

1
$ brew install ansible

但这两种方法都不可避免将「污染」系统的 python 环境。所以本文主要介绍如何绿色安装 Ansible。