去年偷闲的时候，挖了好多大坑(这里 ， 这里 和 这里)，怎奈挖坑容易填坑难……客观原因自然是“认真的写作有如雕刻”云云，主观上嘛，“懒”大概是逃不脱的一个字吧。

Wait，是谁说过，“懒惰是程序员的美德”来着。秉承这种美德，耗了将近两个月的业余时间，尝试了不下50个el-get package，并且认真读了不下10个package的manual，遂成 oh-my-emacs.

一切缘起于两个月前的某一天，我忽然心血来潮，想要整理下那一坨"just works"的.emacd.d。我几乎尝试了所有github上比较流行的.emacs.d，但是没有一个满足我的需求。“因为所以，科学道理”， Reinventing the wheel 和 Not invented here 大概是每个程序员必修的一课吧。索性不管那么多了，代码写的不好，又不输房子不输地，坑 挖的不好，大不了留着自己用就是。

Oh-my-emacs着重解决的问题是(引用自oh-my-emacs的README):

• Better default settings with various eye candy, powerline, scrollbar, color-theme, fonts, etc.
• Adopt el-get as the default package manager for Emacs, instead of the default builtin package.el, say goodbay to ./configure; make; make install and explicitly mananully management of load-path. el-get also provides automatic documentation management, customizable user's recipe support, etc.
• Self-adapted, only install necessary packages when it satisfy the prerequisities. You need to install clang for auto-complete-clang, for example.
• Modular, only load necessary packages as you need.
• Literate, each package have comprehensive documentation or even a tiny tutorial with it, together with necessary web links. Say goodbye to old, out-dated emacs lisp code from Google.
• Work as expected, completion every where when possible, semantic code completion through auto-complete with various ac backend, helm for minibuffer completion, etc.
• Full-blown, oh-my-emacs is not another starter kit, it is hacker kit.

这其中，补全、文档、自适应性，是我特别看重的三点。补全自不必说，作为上古大牛也 许是不需要补全的，但是对于我这样21st Century成长起来、尝试过Visual Studio强大补全甜头的程序员来讲，补全是最为迫切的需求。而Emacs/Vim作为General Purpose Editor， 其最大的使用不便就是没有代码的语义补全(semantic completion)。Emacs有一个内置的 Semantic， 来源于Emacs社区鼎鼎大名，目标远大的CEDET， 但是Semantic的使用和配置 都很复杂(参考emacser.com的文章)，而且很慢，有时会让Emacs卡住。究其原因，我认为 Semantic 的思路是不对的。用性能本就不怎么好的Elisp去实现复杂如C++这类语言的 Parser，其本身就是浩大的工作量。正确的思路是，对于不同的语言，依赖于不同的 backend，然后用Elisp写相应补全的interface。所以我认为， auto-complete 的思路是正确的。oh-my-emacs利用已有的各种auto-complete的backend(如 ac-slime, auto-complete-clang 等)基本上实现了对C/C++，Python，ELisp/Common Lisp/Clojure的语义补全。

第二点是文档，Emacs的世界从来不会缺乏选择， el-get-list-packages ，2500个 package，其中有很多package要么是已经过时，要么是年久失修，要么是语焉不详，看上去 一片繁华的Emacs世界，实则荆棘密布。如果你没有一点Elisp的功底，想开箱即用，那几乎是不可能的。单拿Python来说，Emacs和Python社区就有两套不同的 python.el ，这给很多Python和Emacs的初学者造成了困惑。Google: Python Emacs，其首页的几套解决方案，采用的是不同的 python.el ……你说对于一个好容易学会翻墙，开始习惯用Google搜索技术文档的计算机初学者而言，看完这些文章，不晕菜才怪呢。稍微复杂一些的配置，比如 TeXLive，在比如Common Lisp的各种实现和SLIME，想要得到一个比较舒适的环境，不但要配置好Emacs，还要配置好系统环境，这又是一大难题。oh-my-emacs借助org-mode Babel， 采用Literate的方式¹， 将文档和代码写在一起，在文档中尽量给出每个模块所需要的系 统环境；对于有多个选择的情况，文档中尽量给出为什么选用package A而不是package B的理由和权衡过程。有一部分文档甚至可以当作Tutorial来看。Literate方式最大的好处是保 持文档和代码的同步，这样，oh-my-emacs即可以用作是“开箱即用”的.emacs.d，也可以当作是手把手的Emacs配置教程 (统计下来，oh-my-emacs中文档和代码的LOC 比例约为3:1左 右)。另外，操作系统的环境千差万别²， 因此oh-my-emacs基本上在每个相关模块的文档里面都指明了使用这个模块所需的系统环境，这也可以看做是我为了填去年的坑所做的一点努力吧。

第三点是自适应性。这又是一个很宽泛的话题。什么叫自适应性？是支持多个操作系统吗？ 不是的，至少我没有打算让oh-my-emacs很好的支持Windows，一方面是因为Windows没有一个好的类似于apt-get这种类型的package manager³，oh-my-emacs依赖的很多底层软件如ssh，gcc/clang，TeXLive等在Windows上配置起来都很麻烦，远不如 apt-get/yum/pacman/homebrew这种一条命令来的方便。我这里讲的自适应性，主要包括：

• 采用el-get， 自动化管理load-path，以及info文档等，say goodbay to git submodule
• 如果系统环境不满足某个package的要求，就不要安装这个package，免得装完了不能用。 比如 auto-complete-clang 依赖于 clang， 如果系统中没有安装clang，那么oh-my-emacs在启动的时候就不会安装 auto-complete-clang。反之，如果你意识到这个问题并安装了clang，那么可要重启Emacs， auto-complete-clang就应该可用了。
• 尽量借助工具和代码获取相关配置，而不是在代码中写死。比如，oh-my-emacs大量使用Elisp中的 executable-find ，这需要依赖于操作系统的package manager设置好相关的 $PATH ， 这样带来的好处就是oh-my-emacs能够无缝的适应很多环境。
  • 比如 AUCTeX需要PDF阅读器作为LaTeX文档的Viewer， oh-my-emacs采取的策略是优先采用 Okular， 其次是 Evince， 如果操作系统上即没有装Okular也没有装Evince， 那么oh-my-emacs会fallback到 xdg-open， 这样可以用可移植的代码获得最大限度的灵活性和自适应性[4]。
  • 再比如 SLIME 支持多种Common Lisp Implementation， oh-my-emacs采取的策略是同时支持 SBCL/Clozure CL/CLisp ，也就是说，只要你安装了SBCL/Clozure CL/CLisp其中的一个，oh-my-emacs的Common Lisp设置就应该是可以工作的。
  • 针对auto-complete-clang， oh-my-emacs可以利用 pkg-config 检测并设置正确的 ac-clang-flags ， 可以对系统中可用的任意C/C++ lib提供语义补全。比如，你可 以用 M-x ome-pkg-config-enable-clang-flag "QtGui" RET 来获得QtGui库的补全 支持，效果可以参考这里。

Oh-my-emacs目前已经包含了对C/C++/Python/Common Lisp/Clojure的支持，基本上都提供了较好的语义补全。其他方面，设置了更友好的字体，powerline，color-theme。启用了 一些比较好的内置mode，诸如recentf/savespace/uniquify。对\LaTeX编辑提供了完整的支持，默认采用XeTeX。

Oh-my-emacs的名字来源于 oh-my-zsh， 用意嘛，自然是希望能将oh-my-emacs打造成oh-my-zsh那样。大话止于此，看行动。

最后放张图，更多美照在 这里 。Enjoy emacs, and, your life.

--

去年12月份的时候我曾经给自己写了一份"OpenStack开发基础知识"书单，贴在墙上，书单大概如下：

• 网络基础：
  • Foundations of Python Network Programming
  • 计算机网络
  • HTTP
  • 计算机网络教程
  • TCP/IP详解
  • Internetworking With TCP/IP
• 语言基础：
  • Pro Python
  • Metaprogramming Ruby
• JavaScript:
  • JavaScript 高级程序设计
  • JavaScript语言精髓与编程实践
• Web Design
  • The Definitive Guide to HTML5
  • 无懈可击的Web设计
• +Rabb+itMQ in Action
• Database
  • MySQL必知必会
  • 数据库系统基础教程
  • 数据库设计教程
• Django
  • The Definitive Guide to Django
  • Pro Django

读书进度=书名中划线部分的长度/书名的长度。之所以有这份书单，是因为在前面几个月的开发中，我发现自己的基础知识薄弱，远远不能满足OpenStack开发的需要。虽然自己已经能够按照公司的基本要求，照猫画虎地开发出几个能用的所谓Feature，但是我内心明白，自己的能力上尚不足以透彻理解OpenStack代码¹。

我认为自己还算是一个比较努力的人，并且自认为对自己目前所从事的行业还是有着满心的热爱和期待，期待自己能做出一些有用的产品，留下一些真正有用的能改善人们生活的东西。这个宏大的愿望映射到眼前，就是努力使自己成为一个合格的Full-Stack类型的Web开发工程师。而进一步将眼前目标付诸行动，就是上面的书单了。我原本定的时间是3-5个月左右，不过现在看来还是太狂妄太浮躁了。客观上是自己要工作，时间不完全都是自己的；主观上则是自己“深度优先，随性而为”的阅读习惯常常会不自主的打乱原本订好的读书计划。比方说我在读"Pro Python"的时候为了搞清楚细节会去读"Python源码剖析"，会去尝试理解Python的整个历史；在读"HTTP"的时候为了理解ReST，会去读"REST in Practice"； 而我在尝试理解Python TDD的时候会把Ruby中关于Cubumber的书加入阅读计划。这或许不是一个良好的阅读习惯，但这能保持我的兴趣，这就够了。

我不是一个Top的工程师，至少目前不是——Top的工程师不会像我一样还在费力的学习理解ReST/TDD这些概念性的东西。我知道Top的工程师在哪里 ²。这类人天赋异禀，并且在很早的时候就接触计算机。在你还在骑着自行车围着院子绕圈的时候他们已经开始理解算法和数据结构，在你刚刚写出"hello world"的时候他们已经能写出成型的软件作品，在你毕业之际为找工作焦头烂额的时候，他们已经受过了1万小时的训练，有更好的机会和最聪明的人合作更快的提高自己。这个博客基本上忠实记录了我正式开始认真学习计算机的全部历程。四年来我几乎做过各种各样的东西，Windows手机开发，Java SSH(已经忘光光)，OpenGL程序，Hadoop，Python/FFmpeg写的转码系统等等，很杂，也很浅。但我一直坚持一个方向，就是拥抱开源，先是尝试学习基础知识，用好Linux/Emacs这类基本工具，毕业工作后开始去尝试读一些开源代码，提一些无关痛痒的patch试图接近开源，这一年来又开始尝试理解OpenStack，并真正的提交了一些patch。我不敢评价OpenStack的设计是否优秀，事实上我还没有这个能力去完全理解它，更妄论评价了。但是OpenStack的开发确实让我学到了很多东西，我开始理解了TDD，开始逐理解了ReST和Web Service，开始逐渐理解作为工程语言而不是脚本语言的Python，开始理解Message Queue。而我也通过自己的努力，让基于jenkins/gerrit的自动化测试部署的全套流程在公司运转了起来。

两年前信心满满刚来北京的时候，我从未想过自己会那么快的离开百度³，一年前开始寻找新的工作机会的时候，我完全没有听过OpenStack这个词。当初一心坚持离开学校是为了远离校园里学习的束缚，现在走向工作岗位又会感慨感叹时间的宝贵和校园里相对的自由。说白了，我是一个贪心的实用主义者，胸无大志，从来不会想五年以后的事情，学校里面不想听无聊的课程，就天南海北山山水水的疯跑，哪怕一学期挂科五门依然无所畏惧不懂屈服；工作以后顶撞上司就来个偷得浮生半年闲，躲进小楼成一统，管他春夏与秋冬，云卷云舒花开花落——但为了生活还是要出来找工作。

貌似扯的有些远了……最后回到本文的正题吧，OpenStack的开发。上个星期做了两个东西，第一是做了个OpenStack代码的国内镜像，方便教育网内学生党⁴，地址是：

• http://git.oschina.net/openstack
• http://git.oschina.net/openstack-dev

第二是基于Vagrant做了个OpenStack的开发环境，地址是：

• https://github.com/xiaohanyu/vagrant-hackerbox
• https://github.com/xiaohanyu/vagrant-ansible-devstack

好了，吹牛到此结束，各位好梦晚安。

--

大概是从去年年初开始认真的写作。怎奈认真的写作有如雕刻，每次写作少则四五个小时，多则十几个小时，极耗体力，因此再不敢轻易提笔。两周前的一篇文章，更是在机缘巧合之下将鄙人推向了舆论的风口浪尖，至今想起来依然心有余悸。写的人累，想必读的人应该也不会太轻松。值此新春佳节，特奉上一篇“技术小品文”，奢望读者百忙之中施舍一笑^~^。

想象一下，如果把一整部电影压缩成一张图片，那会是怎样壮观的场景？有点迫不急待？看看这里，梯子在这里。

是不是想动手尝试下了？可是有这样的软件吗？我没找到。于是唯一的办法就是自己动手，丰衣足食了。代码在这里，依赖Linux/ffmpeg/bc/graphicsmagick。运行过程中需要保证5G以上的可用磁盘空间。转换耗时约30分钟，视电影时长而定。

#!/usr/bin/env bash

################################################################################
# Usage:    A script to convert a movie to a movebarcode
# Author:   Xiao Hanyu
# Depends:
#   ffmpeg:     get basic info of a movie and convert it to a series of images
#   graphicsmagick:
#               convert, mogrify, blur images
#   bc:         shell calculator
################################################################################

function get_duration
{
    ## [0-9]{2}:[0-9]{2}:[0-9]{2}(|\.[0-9]{1,2}) matches:
    ##      hh:mm:ss.ms
    ##      hh:mm:ss
    duration=$(ffmpeg -i $1 2>&1 | grep 'Duration' | grep -E -o "[0-9]{2}:[0-9]{2}:[0-9]{2}(|\.[0-9]{1,2})")
    duration_h=$(echo $duration | awk -F: '{print $1}')
    duration_m=$(echo $duration | awk -F: '{print $2}')
    duration_s=$(echo $duration | awk -F: '{print $3}')
    movie_seconds=$(echo "$duration_h * 3600 + $duration_m * 60 + $duration_s" | bc)
}

function get_fps
{
    fps=$(ffmpeg -i $1 2>&1 | grep -E -o "[0-9]{2}\.[0-9]{2}\ fps" | grep -E -o "[0-9]{2}\.[0-9]{2}")
}

movie=$1

get_fps $movie
get_duration $movie

## use multi-cores of cpu to improve the speed of ffmpeg, see ffmpeg man page
cpu_cores=$(cat /proc/cpuinfo | grep processor | wc -l)

time ffmpeg -i $1 -r 1 -threads $cpu_cores image%d.png
time gm mogrify -resize 0.5%x100% *png
time gm convert $(for i in `seq 1 $movie_seconds`; do ls -l image$i.png; done | awk '{print $9}') +append result1.png
time gm convert result1.png -blur 50 result2.png

# resize result2.png with a proper size
# I set new width to 2000, while keep the height intact
new_width=2000
new_geometry=$(gm identify  result2.png | awk '{print $3}' | awk -F+ '{print $1}' | sed 's/[0-9]*x/2000x/g' | sed 's/$/!/g')
gm convert -resize $new_geometry result2.png result3.png

rm image*png

if [ -e $(which xdg-open) ]; then
    xdg-open result3.png
fi

代码逻辑很少，先是通过ffmpeg进行截图，然后用graphicsmagick进行图片的接合、缩放和模糊处理，最后清扫战场，删除一些临时文件，就这么简单。最后，奉上《迁徙的鸟》和《阿甘正传》的条形码，博君一笑。

世界很小，互联网很大。昨夜随手写的一篇文章，不知受到了哪位仁兄的抬爱，被转到了百度运维的Hi群里，搞得我险些被请去“喝茶”……半夜5点发的文章，早晨9点左右，由于豆瓣九点的推荐，访问量开始突增，到了正午，豆瓣九点上已经有了近五十条推荐……而我的个人豆瓣“粉丝”也激增了20+(增幅达20%)，博客也多了很多订阅者。更奇怪的是，这篇文章到了下午5点左右的时间，豆瓣九点上的链接已经莫名失效了¹。我又尝试去微博上搜索了下，只搜到了3-4条，最下面是“根据相关法律法规和政策，部分搜索结果未予显示。”

从各种渠道收集的反馈，多数人的看法是诸如“文章比较犀利”，“有同感”之类，还有一位仁兄说这是“loser的文章，看看即可”，一位与我素未谋面的仁兄说“我知道这位刺头是谁……淘宝有怎样怎样的问题……腾讯有怎样怎样的问题……”，还有的说“文章里有个人情绪，但也有原因分析，只是分析的不够深入”等等。午饭后一位百度的朋友QQ上告诉我说“你的文章火了，有人转到百度运维官方群了”，我心想“完了完了，这下没准要被请去喝茶了……”，然后又接到了几个朋友的电话，跟我说明下说文章的内容有不实之处和个人情绪在，我说我会再做斟酌，酌情修改。

文章大概7000字，写了8个小时左右。最开始只是睡不着觉，然后就琢磨着想写一写关于狼性的看法，后来越写越多，也就不自主的加入了一些个人的情绪在里面。”不识庐山真面目，只缘身在此山中“，我只是一个小小的OP，可能看不到那么高，也看不到那么远，因此文章的各种内容观点均出自个人，与别人无关，我会为我的言论负责。

首先我诚恳地向kain同志道歉。因为我的疏忽对你做出了错误的评价。坦白地讲，我对kain同志并没有深入的了解，对北大青鸟也没有深入的了解，甚至带有很深的下意识的个人偏见。我以前并不知道kain同志并非科班出身而是化学专业出身，靠着自己的兴趣和努力走上了计算机这条路，并且通过自己的努力进入了百度，我应该对此表示恭贺。我欣赏有想法、有主见、有自己个人兴趣并按照自己计划不断提高自身的人。事实上我觉的我也是这样的人²。碰巧我在大学之前也是学习化学竞赛的，几乎不会使用电脑，大学前两年忙于户外社团，对计算机的系统学习是大三以后的事情。你说的对，一个人的出身并不能代表什么，而别人的偏见在短时间内又难于消解，总会无意间就碰上有心无心看扁你的人。对此我在此表示诚恳的抱歉，也感谢你让我对我自身的缺陷有了进一步的认知。同时我也觉得，无论别人怎么看轻自己评价自己，自己才是自己最后的裁判。一个心怀优秀信念并不断努力的自己，即便碰上一些挫折，误解，只要自己对自己怀有信心，那么别人的评价再多，也“尽可当他是清风拂山，明月映江，虽能加于我身，却不能有丝毫损伤。”

其次，关于Hadoop开源方面，由于我并不是Hadoop的RD，因此关于“几乎没有对Hadoop社区的开源回馈”这句话是不准确的。Hadoop的一个C++框架HCE是百度自己独立开发的，测试显示其效率高于传统的Hadoop程序，并且已经开源。Hadoop之外，其他的开源项目，我了解的有一个UEditor，百度前端团队有一些开源的项目，参考https://github.com/BaiduFE，剩下的我所知有限。

以上两点我已经在原有文章中做了更正。至于各条怪现状，由于上篇文章掺杂着个人的情感和经历在内，因此难免有“吐糟”，“百度黑”的嫌疑。回过头来我也想过，如果将我个人的经历和情感去掉，那么文章本身是否会变得更客观理性更具有参考价值一些。挑几条再简单阐述下吧。

关于洗脑，我认为这个也没有什么不对，因为这是员工熟悉公司文化、制度、理念的一个很好的手段。但是有两点我认为需要改进，一是学习方式上，可以讨论，但是我认为“毛主席语录“式的学习方式是不可取的，应该要允许部分”异类“的存在，你倡导“快速迭代，越变越美”，但也要允许“慢工出细活”，“一炮打响”的存在；二是要与时俱进，我记得书里面好像有关于有啊的故事，但是有啊后来失败了，却没有一个地方对有啊的失败做个总结和反思，这就难免会让人对公司所灌输的理念产生怀疑。

关于开源，这方面我强烈建议百度拥抱开源，不要死守着老观念不放。没有自上而下的推动，没有公司气氛的烘托，光靠几个有心的底层RD敲敲打打是成不了大气候的。至于为什么要拥抱开源，这个就不再多做讨论了。

关于KPI驱动，这点尤其需要改变。我坚持认为“上下异心”是百度当前最大的发展阻力。但是这种局面的改变需要自上而下，而不是自下而上。要让底层技术人员放开手脚去做、去闯、去创新，也要让中层的管理者们转变KPI报表为王的管理策略，真真正正的去抓一些实际的东西。作为一个一流的互联网公司，用wiki的方式手工维护记录可用机器列表，用人肉的方式每周去copy/paste数据到固定的模板里生成报表周报，这种行为可以视为科技公司的一种耻辱。要大力推行工具文化，自动化不是一句口号，是一点一滴。

关于会议沟通，这个大概是大公司的通病了。我认为很大一部分原因还是工具不到位，自动化的东西做得不够好，所以不得不通过人力反复沟通确认来完成事情。在Hadoop组搞机器预算的时候，每次都是人肉Excel，反复打电话确认。而这些不必要的沟通很大程度上是可以通过开发一个成熟的预算系统来解决的。后来也确实有人做出了预算系统的原型，Lisp写的，我接手的时候还修复了几个bug，可惜这么个原型系统毕竟只是个人的业余工作，加上沟通电话实在太多，没有精力完善，上面也不重视，最后也就不了了之了。

关于自由上班，这个就仁者见仁智者见智了。中国很多企业的通病就是员工一迟到就扣钱批评，但员工加班晚归却视而不见。百度当然没有这样，并且百度的工作时间，以及加班补贴和调休制度都还算比较完善。所以归根结底还是要减少不必要的会议沟通，提高白天的工作效率。

关于Geek，我不认为用Linux/Mac就是Geek的一种表现，但是作为一个互联网公司，其入职预装的系统依旧是10年前的Windows XP，难免很让某些人（诸如我这样的）大倒胃口。Geek不是一个操作系统，也不是一个手机一个平板，Geek更多的是一种对待工作的态度——倾向于用机器来代替人，DRY，对代码的洁癖，对工作效率的追求，对文档排版这类美感细节的敏感。不要小看这类细节，细节代表着专业性，比如说技术博客一个最基本的要求就是排版规范，简洁，同时要有合理的代码高亮。但是百度很多“官方”的技术博客并没有做到基本的整洁规范，比如这里、这里和这里。多余的话不多说，如果你认为这些所谓文档排版，代码洁癖无所谓的话，我也无话可说。

关于有啊。其实这个事情我了解的并不多，我入职的时候有啊基本上已经散了。但是正因为了解不多所以我才在这里提出，因为我从未看到过公司层面上对自己做的任何失败的产品有过任何的反思。还是那句话，员工犯错可以批评可以扣KPI，但是如果公司犯错了呢？如果由于高管的失误造成公司的损失和员工职业发展的挫折，又该如何呢？再进一步，如果Robin犯错了呢？我觉得百度的高管应该认真反思下这个事情，要勇于面对自己的不足，敢于拉下面子做自我批评，不要总是高高在上，犯了错都是员工的，做好都是自己的。

最后的最后，还是再允许我多絮叨几句吧。首先我不是一个百度黑，我在百度长了很多见识，学到了很多书本上无法学到的东西，也有幸和部分真正的牛人有过一面之缘，管中窥豹，了解下他们的工作，给自己树立个目标。我所指出的这些问题，我相信至少还是有一部分是许多百度同学的共识，只是迫于各种各样的原因无法像我这种离职的员工更加方便的开口讲述。我希望百度能够更多地倾听底层技术人员的声音，不要总是脱离群众去制定自己辉煌的战略路线。我希望百度发展的更好，但我也明白知易行难的道理，作为曾经的百度人，我所能做的也只有这些了。其次是每个公司都或多或少有自己的不足，百度如此，腾讯如此，淘宝也是如此，毕竟时间并无完美之物，而人生之不如意又十之八九，我觉得多数情况下可以变通，但也不要被生活磨平了棱角。其三，我想说的是，个人的职业发展，8小时之外的功夫也许有时比8小时之内的功夫更加重要。所以我也提醒各位和我一样初入职场的同学，与其天天扑在工作上，能否多花些精力在工作外，然后反过来提升工作的效率，从而给自己的工作、生活和学习都留下更多的自由空间呢？

至于我个人的经历结果，我并没有太多的遗憾甚至抱怨，或许是我运气不好，又或许是我能力真的有限而我没有意识到。事情已经过去，多说无益，只求各位看官也千万不要把我看成一个高级文艺的“百度黑”。感谢一直关心我的朋友，我现在过得很好，住在北大附近，离未名湖五分钟的路程；工作不是太忙，用Linux+Emacs+Git+Python做着我喜欢做的事情，OpenStack教给了我很多；每天晚上归家奢侈地享受4个小时的阅读（悦读）；间或周末去北大看场电影；赚得钱够家用，也能随心所欲的买书；沉浸在lambda的程序世界里；有个关心我的妞在身边。总之，一切都很好。

谨以此文，纪念我那九个月“不合格”的百度岁月。

--

----------

这篇文章发表半天后，由于某位不知名的百度仁兄的抬爱，忽然的就火了起来，也吓了我一跳。我写了另外一篇小文作为补充说明：《慎言多思》。如有任何建议指正，欢迎多多指教，xiaohanyu1988@gmail.com。

另，很多人提到说题目有些“驴唇不对马嘴”，我这里稍微解释下。首先我是明白“罪己诏”这三个字的含义的，取这三个字为题也是有意为之；其次是写这篇文章的初衷是为了“批判”下Robin的那封狼性邮件，因为我觉得百度出现的很多问题是公司层面的而非员工层面，绝不是为了博眼球。想来想去还是觉得这个题目比较好，加上引号，算一点修正，剩余不再修改。谢谢诸位提醒。