周四下午，收到同事的一封mail，他告诉我他的业务代码中使用的一个库接口的行为与预期不同，并在mail中给出了测试代码和测试结果。而这个接口是之前由我封装实现的。 

这个库仅仅是对libevent做了一层薄薄的封装，目的是使其接口的使用方式符合部门的一贯风格。虽说封装简单，但单元测试也是一应俱全，不敢马虎，必要的地方mock也一并上阵，总体来说我个人还是比较满意的。

不过还是出现了问题，问题出在libevent提供的timer的行为上。这是我们第一次使用libevent，我基于以前对timer的事件处理机制的理解作出了错误的假定：libevent提供的timer是PERSIST的。同事的测试结果却表明这个timer设定是一次性的：只运行一次便失效了，除非在timer的callback handler中重新添加timer事件。

《程序员修炼之道》中在介绍如何深思熟虑而不是靠巧合编程时说过：要测试你的假定。我恰恰是在这块儿犯了错误。尚没有明确libevent的行为就做出了假定而且没有对这个假定做细致测试，最终导致了这个问题的发生。

这个问题最终是这么解决的：了解了一下，libevent 1.x.x版本确实不支持persist timer事件处理，但是在libevent 2.x.x版本中，作者增加了对persist timer的支持。我们原本使用的是1.4.10的libevent，为了支持persist timer，我将库升级到2.0.10(已经是stable版了)。不过仅仅是升级库版本还是不行的。我们不能直接使用libevent提供的evtimer_set接口，因为使用该接口后，我们得到的依旧是一次性的timer。这里需要用event_set(e, -1, EV_PERSIST, eh, arg)替代evtimer_set(e, eh, arg)，这样设置后得到的timer才是persist的。 

年终岁尾，又到了该做年终总结的时候了。有些人觉得年终总结很难写，于是自欺欺人的在网上到处高价找枪手；亲自动手写总结的人也是抓耳挠腮，迟迟无法下笔。其实我倒不觉得总结有这么难，自己做过的事写出来又有何难呢!也许是你的心魔在作怪罢了(什么心魔，你懂的!)。对自己负责的人肯定是会主动积极地去做总结的，总结的第一对象也一定是自己，其次它的另外一个用途才是用来提交给领导看的。你的总结无需文采飞扬，关键要言之有物，切中要害，否则与一张废纸无异。总结无非是回顾过去，展望将来，甚至连结构形式都大同小异，所以你只需要认真思考内容就行了。

写总结时有些人眼里只有成绩，过去一年的成绩能写上几个篇幅，但一到该发掘问题时候就显得耳目闭塞，憋了半天也憋不出来一个字。其实你的领导对你的成绩早已是心中有数，如果这点都做不到的话，那他绝对不是一个合格的领导。我想作为领导的除了下属成绩外，更关心的其实就是下属对工作是否用心了。而总结恰恰就是一种领导了解下属是否对工作用心的渠道。

我和许多人恰恰相反，我的总结里成绩一笔带过，那些东西毕竟属于过去了，我更多的是向前看，总结的更多是现存的问题以及如何改进的思路和方案思路。

和去年想比，我的总结也越来越简明扼要了。过渡到简明扼要不是一蹴而就的。年末我也写了一份内容翔实的总结，后来我把它彻底从我的电脑里删除了。把大脑腾空，静下心来想了想：我到底要向我的领导传递什么信息？于是一篇算上落款才一页多两行的pdf格式的总结完成了，其中没有大段的论述，更多的是条目和对条目的诠释，至于成绩那部分，只占了区区四行文字。我这份总结不具备典型特征，大家不必要学^_^。

对于有心人而言，总结不是年终那几天的事，是全年的时时刻刻都要考虑的事，如果你做到了时时刻刻，那么还害怕那份年终总结吗！