一年多前，出于显而易见的原因，下定决心肉身翻墙。经过一番考虑，放弃了读书这条途径，决定直接找工作，通过H1B签证出去。于是去年八月份从百度辞职，开始着手准备。当时觉得今年拿到H1B的成功率大致能有个六七成，加上周围朋友们的不断鼓励，可以说还是相当自信的。然而，时至今日，在历经Google、Amazon、Facebook三家公司之后，这第一次尝试却可耻地失败了……
战绩概览：
- Google：仓促应战，HR电面一轮，技术电面一轮，北京onsite两轮，惨败；
- Amazon：技术电面两轮，在面试官反馈良好的情况下莫名挂掉，详情见下；
- Facebook：HR电面一轮，技术电面两轮，Menlo Park总部onsite五轮，惜败；
- AeroFS：因为是startup，临时告知无法提供H1B，于是告终。
个人背景参见这里。
失败的原因，简而言之就是两个字——自大。在百度四年多，技术方面长进不少；虽然从未以做管理为目标，却也阴差阳错地干了两年管理，从零带出了一支二十多人的研发队伍，同样获益颇丰。再加上离职时恰逢耗时一年之久的首部译作正式出版，自我感觉良好，信心爆棚。周围的朋友和同事们听说了我的计划之后都鼓励说“肯定可以”，于是我也就飘飘然地认为“肯定可以”了。这种自大心理使得我没有尽早将目标公司的面试方式研究透彻，也未能及时采取最为有效的方法弥补自己客观能力上的不足。
无论如何，这段经历还是相当宝贵的：经历了第一次英语面试、第一次办签证、第一次出国、第一次倒时差，还有第一次误机…… 虽然求职失败，但仍然获益良多。本文便是对这次求职全过程的记录，一方面警醒自己，一方面也为其他有类似打算的朋友们留一个参考。由于几家公司的面试是交错进行的，下文并没有完全按照时间顺序进行描述。此外，出于NDA协定等原因，本文不会透露具体的面试题。
More...
6月29日，Amazon EC2美国东部1号区域的一个availability zone遭大规模雷暴袭击而断电，该事故殃及了包括Netflix、Instagram、Pinterest在内的一大批服务，详情参见Amazon针对此次事故的官方报告。几天后，偶然在Channel 9上看到一篇文章，进而顺藤摸瓜找到了Richard Cook的这篇发表于1998年的How Complex Systems Fail。这篇文章总结了十八条关于复杂系统故障的经验，言简意赅却一针见血，读之让人击节叫好，大有拨云见日之感。
回顾Amazon针对这次事故的官方报告，以及自己在过去若干年间遇到的种种线上事故，几乎无不落入这十八条之内。这篇文章并没有将视线局限在技术领域，而是从系统、从业人员、事故评估等一系列角度全方位地探讨了复杂系统故障的性质，点破了复杂系统中的一系列“潜规则”。有意思的是，本文讨论的本是医疗IT系统，得出的结论却同样适用于大规模互联网基础服务，真可谓大道归一。在今年的Velocity大会上，Richard Cook就同一主题发表了演讲（YouTube视频），同样值得推荐。
需要指出的是，这篇文章没有任何量化分析，也没有提供任何实际案例，这种情况下文中的观点很容易引发争议。所谓经验，无非就是以非形式化的语言对过去遇到过的问题进行建模。对于采纳相关经验的人来说，如果当前面对的问题与该经验背后的模型相契合，那么经验就生效；反之，该经验便无效。若这十八条能够给读者带来启示，那最好不过；反之，若认为文中观点有偏颇之处，也请先结合具体场景再加以讨论。
独乐乐不如众乐乐，特将此文译出，以飨读者。这篇文章字数不多，译起来却颇费功夫。如果有错译之处，还请在评论中不吝赐教。
More...
TL;DR
最近把blog从WordPress迁移到了Jekyll。方便起见，目前暂时托管在GitHub上（更新：本blog已经从GitHub迁移至自购DreamHost主机）。Jekyll内置了多种标记语言支持，可惜其中并不包含我最喜爱的reStructuredText（以下简称为reST）。虽然也有现成的Jekyll reST插件，但GitHub出于安全考虑禁用了Jekyll插件。在Jekyll内置支持的若干标记语言中比较了一番之后，决定开始用Markdown写文章。然而很快便发现，Markdown实在是让人爱不起来。这篇就来批一批Markdown。作为对比，我还会写一写同样的问题在reST中是怎么解决的。
注意：我从来没有说Markdown是最烂的标记语言，比Markdown更烂的标记语言还有的是。但Markdown自身的确有一些严重的缺陷，尤其是在中文文档书写方面，无论是文档的结构语义表达还是样式套用，都令我非常不满意。
在我看来，Markdown的应用范围应当限制在千字以内、仅包含少量格式、无复杂结构的文档撰写，典型应用如类Doxygen的代码文档注释和blog评论等。除此之外，科技文档撰写、书籍撰写等场景下，Markdown都不是什么好的选择。并且，在这些应用中应当尽可能只使用Markdown的标准格式。Markdown的各种实现版本还各自新增了各式各样的语法扩展，这些扩展虽然便利，但却大大折损了Markdown文档及相关工具的互操作性。
后记：这里所说的互操作，主要指用不同的Markdown实现转换同一份Markdown文档。Jekyll支持自定义Markdown实现，然而一旦用了某种实现的特定扩展，今后想换一个Markdown实现的时候就郁闷了（例如原先用的是Maruku，并且用了它的meta syntax，后来因为性能原因换了rdiscount）。相较之下reST只有一份主流标准实现。
More...
GMP (the GNU MP library) is a widely known library for arbitrary precision arithmetic on integers, rational numbers and floating-point numbers. When using GMP in C/C++ projects, one must face some subtleties.
Using GMP in C
According to GMP's official documentation:
All declarations needed to use GMP are collected in the include file gmp.h. It is designed to work with both C and C++ compilers.
#include <gmp.h>
Note however that prototypes for GMP functions with FILE * parameters are only provided if <stdio.h> is included too.
#include <stdio.h>
#include <gmp.h>
Likewise <stdarg.h> (or <varargs.h>) is required for prototypes with va_list parameters, such as gmp_vprintf. And <obstack.h> for prototypes with struct obstack parameters, such as gmp_obstack_printf, when available.
(I wonder why GMP doesn't include these required header files itself?)
More...
题记：本文可不是关于DoS或DDoS的技术文章 前两个月受Pluskid之托，给浙大MSTC十周年的月刊（说是月刊，实际上按发刊速度已经是年刊了）写篇文章，于是便有了这篇。原文名为《拒绝》，为了放到Blog上而找题图时才突然想到DoS这个名字。
IT是个辛苦的行业。新人尤其辛苦，特别是刚刚毕业步入职场的应届毕业生。这种辛苦的直接体现就是加班：前一晚刚通宵上线完毕，今天还要赶调研报告？连续两个月的周末都没有出去玩，全窝在公司干活？白天开会、晚上干活，分身乏术？为什么总是这么忙、这么多工作呢？其中一个重要原因就是不懂得拒绝。
前几天面试时，有一个同学也提到自己当前的工作非常忙，手头很多个任务并行在做。从面试情况可以看出这个同学的个人能力很不错。当前手头上的任务既有短期的重要项目任务，又有中长期的技术储备任务。当时问他既然这么忙，为什么不推掉一些任务呢？他回答第一自己本来就是新人，应该多干；第二老大让干的怎么能不干？
于是我问：如果你带着一个队伍，老大让你干什么你也都接吗？干不完就逼着弟兄们加班吗？
More...
