前段时间在将公司的 SVN 项目迁移到 Git 上面去，遇到一个很少见的问题： 有一个小伙伴使用 git-svn 做 rename 操作时候，将一个目录 svn mv 了， 导致新目录只存了最近几个月提交历史，丢失了历史信息。对团队开发而言， 历史提交是非常宝贵的财产，我们想了一些办法，把这些数据提取出来。

2013 年末，我给自己制定了几个年度目标：

离梦想更近一步

找一个靠谱的姑娘，我感觉她需要我，我也需要她了

1. 成为一个为百万用户级别提供技术支撑的人物，要能独当一面
2. 帮助网站进行性能优化
3. 制定规则，平衡猥琐实现和优雅
4. 继续写博客，分享积累 + 翻译文章

关于感情

先来谈谈感情，我和她在一起一年半了，虽然偶尔有小摩擦，但总体上面还是非常幸福的。 找到一个能产生共鸣，生活兴趣相近，相互欣赏的人太难了。一定会珍惜的。

作为一个 Linux 的老用户，我再一次验证了那句老话「Linux 用户有钱就换 Mac」。 前段时间，托朋友从香港购入一台 rMBP，下面就是我的 Mac 使用安装记录。

Brew

Brew 是 Mac 下面的包管理工具，通过 Github 托管适合 Mac 的编译配置以及 Patch，可以方便的安装开发工具。

安装 Brew：

我安装的 Brew 包：

原文地址：Postfix Basic Configuration 。 有少许编译。

介绍

Postfix 的配置文件 main.cf 有数百个配置参数， 幸运的是，所有参数都有合理的默认配置项。 大部分时候，只需要配置两三个参数即可。

安装 Postfix 的方法可以参见 安装方法。

特殊场景用途的配置方式，如邮件中枢，防火墙，拨号环境客户端的说明可以在 标准配置说明 里面查看。

大约一年前，我接触了 Java 中的 Btrace 能够不停机查看线上 JVM 运行情况的特性让我艳羡不已。 另外还有强悍的 jStack 和 jConsole 来进行运行期侦测，JVM 的工业级强度果然不是盖的。

当时公司技术方面也遇到了一些瓶颈，一部分原因是 CPython 本身的 IO 模型问题， 另一方面也和早期代码写的极不工整脱不了关系。万般无奈之下，我们用 Jython 推翻重做了主要业务，效果立竿见影，但同时也把真实问题给规避掉了。

在这之后我们在 JVM 的领导下，走上了康庄大道。但我心中始终还有一个梗， 就是想对性能遇到瓶颈的 Python Process 进行线上侦测。 这篇文章就是开始的第一步。

PS:这篇文章理论上是可行的，但是在我机器（Ubuntu 12.04 / 系统自带 Python） 无法正常执行，会爆出 unable to read python frame information 的问题。解决方法我会在下篇文章中写出。这里只是单纯翻译一下原文。

原文可以移步 https://wiki.python.org/moin/DebuggingWithGdb。

仗着自己有几门语言的基础，我在学新语言时候，都会选择一些快速入门教程。 比如 Learn X in Y minuts 就是我经常光顾的站点。

前段时间，小柒在用 R 写数据分析脚本，我就建议她把 Learn X in Y minuts 里面的 R 语言教程翻译出来。话说 Learn X in Y minuts 里面的中文贡献还是非常多的，赞。

Learn X in Y minuts 的源码托管在 Github。 小柒被我逼着把这篇 R 语言教程 翻译到 R 语言教程中文版。

下面是译文，有不妥的地方可以留言或者直接去 Github 上面 Pull request。

R 是一门统计语言。它有很多数据分析和挖掘程序包。可以用来统计、分析和制图。 你也可以在 LaTeX 文档中运行 R 命令。

年前看了这本书《大规模Web服务开发技术》，当时给的评价是：

很好，让我这个渣渣看的很感动，数据翔实，经历可靠，翻译的也不错，我给 4.2 分

现在经历过 Python / Django / 烂代码的阵痛，开始有更多的想法， 在整理这些粗糙的想法之前，我又把这本书翻了一遍，写个流水帐读书笔记。

《大规模Web服务开发技术》@豆瓣： http://book.douban.com/subject/6758780/

规模

小规模 / 大规模 / 超大规模的侧重点各不相同：保持扩展性/保持冗余/低成本运维/开发合作方便

内存、磁盘、负载

内存快，磁盘慢，ＩＯ 速度的差异

数据分布式

1. 使用局部分布式，热数据独立出来。
2. Partition 分布式，按模块分割数据。
3. 按 ID 分割，比如 a-g, h-z
4. 按访问类型，一般请求 / feed / 图像（#毒药计划的原理）

Arch 是我真正使用的第一款 Linux 发行版，大约使用了三年， 现在的这个 VPS 跑的系统也是 Arch。 然而随着时间变化，我从最早的天天更新狂，到一周、一个月、三个月和不主动更新。 彻底从从不折腾会死星人变成了一个尽量避免变更的老用户。

事情起源于动态语言和静态语言之争，最后争论焦点转移到：「相信人本身的能力重要， 还是通过语言/工具来约束人重要」。 我认为项目开发中最重要的是个人能力和团队协作能力，工具只是加分项。 如果代码质量差、监控难、性能难以优化，解决根本问题的关键还是在人身上。 并不是静态编译和工具检查就能搞定了。

我愤愤的在 QQ 对话框中写道：

我工作第一年痛苦于开发流程，阅读了《人月神话》，就开始坚信软件工程的哲学 后来痛苦与代码质量，阅读了《重构》，开始坚信代码质量决定产品质量 现在痛苦于人和语言的冲突，动态和静态的冲突，我想读《人件》了

人件已经绝版，只能在找线上版，我花了两个星期把它读完。 书中给了我一部分答案，另外还有一些意外的收获。

感谢好基友 @daodao 送了我这本《打造 Facebook》， 年前一直忙，最近腾出两个晚上，把这本很火的书看完了。