先吐槽下CUBlog，这个项目编号实在做得太烂了，1、2、3里面用的是bullets，发布之后就变成数字了——这叫“所见即所得”么？敬请各位看官注意保持头脑清醒。
好久没有更新博客了，今天主要是来吐个槽，顺便黑下雇主公司和某些同事。
好吧，首先我承认还有半年才完成第二个五年；其次，这篇博文其实是2012总结，以及2013年的大致计划。对于“二五”收官，就一个短语：别扭以及沉沦的五年；再次，我不懂围棋，若用错“收官”一词，敬请各位棋迷轻拍。
在现在这家N公司（第一个东家也姓N）已经快5年了，总体上来说很失败。也就是说“二五”很失败。尤其是今年，职场可谓一挫再挫，因为年终绩效考核成绩只有可怜的2分（满分5分），这里也不想过多解释自己所理解的原因，只一句话：作为技术人员与家庭妇女的发生了一些不愉快，而且不懂务虚，今后应当极力改善。老板对给2分的原因进行了解释：因为前三个季度我参与的两个项目负责人给的评价是负面的，而我在现老板手下只干了一个季度，因此全年绩效以前三个季度为准。我也象征性地申辩了一下，但老板的意思是：小子，这些人的确很难打交道，你第四季度表现也很抢眼，但我没看见你前三个季度的表现，所以只能以他们的评价为准。其实，早在2011年底，就已经奠定了我在2012年的基调，详情请参阅今年2月份写的“[原]时光荏苒“。
N公司北京研发中心并不是一个具有很强软件能力的公司（不止一个现雇员或者前雇员说过N公司不适合搞软件）。确切地说，它是一家牛逼的硬件集成公司，在这里，工业设计和用户体验部门是一等公民，硬件部门是二等公民，而我们软件部门则是第三等。因此，我们软件部门就像受气的小媳妇一样，这也是为什么我说“别扭”。这里发生了很多很多有意思的事情，公司许多同事不断刷新着搞笑下限：
- 某技术架构师（技术出身，用C写过设备驱动，我看过那个驱动的源码，已无力吐槽）居然连sizeof都不知道；
- 该架构师在我们做GNSS时需要我们反反复复给她讲相关知识，而且她眼里只有”这个不是我们部门的职责，不应该由我们做“。（——现在我依然觉得为了做GNSS项目，我们真的是克服了重重困难）
- Touch & Display硬件部门的小伙子要求demo版的驱动程序不能有问题（他是不知道bug这个术语的，也无法定义什么叫做”有问题“），而且要在一天之内完成；
- Sensor硬件部门的领导说，你们平台软件需要做什么？我们把硬件给你按照规格连接好了，你们用一两天不就能搞定驱动么？不够？那三天行不行？（在”[原]设备驱动开发与状态机建模“里提到，我获得三周来做demo驱动，应经是万幸了，当然，也是我力争的结果）
- Sensor硬件部门的小伙子找到我们同事，要求一个下午搞定因为他们把accelerometer的中断pin和layout改掉之后引起的一系列bug，而做这一系列改动时压根没有知会我们；
- CWS硬件部门的领导说，S公司（竞争对手）半年能做三家GNSS芯片的demo，而你们软件部门只能做一家半，是不是你们能力不行？（——人家用安卓，所有软件都现成的，只需要集成；而我们连OS都要改，来增加GNSS框架，要不是厂商提供了部分参考实现，一年都做不出一家！）
- GNSS项目做到现在，从最初5个工程师，一个架构师，一个PO，一个经理参与，到现在3个工程师，数个架构师，一个PO，数个经理参与，完整地体现了N公司的行事方式：一个项目团队，10%的人干活，90%的人指手画脚
- ……
大家应该可以看出来软件部门经常会跟硬件部门吵架以争取合理的项目时间，否则软件部门累到吐血也无法满足硬件部门的淫欲。类似的事情很多，不一一列举，因为重要的槽点都列出来了。在这里只能客套地说一句：N公司是个牛逼的公司，但不是个牛逼的软件公司，所以才会在现在的平台软件之争里走向没落——我是平台软件部门的一员，但我丝毫不觉得我需要为我们平台软件没有竞争力而承担责任，当然我也没有这个资格。因为每个行业都有自己的规律，如果不按照规律办事，公司的命运就是死亡。N公司恰恰是在用违背软件工程规律的方式做软件：用硬件工程规律来做软件工程。这也能很好地解释到底是什么导致N公司的Linux梦一个接一个破灭，为什么会在20110211选择完全使用第三方的封闭平台。（所谓平台软件部门，就是设备驱动 + OS部门。这里的OS指的是NOS，一个实时操作系统）
槽吐完了，该说点得失，总结下经验教训了。可能会比较枯燥，不像前面吐槽那样狗血，将就着看吧，不愿看就关掉。
去年我基本上只做了五件事：
- 参与两个系统配置项目。（我知道你想了解些细节，但我真的是懒得动笔）
- 通过做两个项目的memory layout和budget相关的配置工作，了解了系统中最重要的一些组件；
- 深入了解了NOS的一些细节，例如在flash里系统怎么布局，在RAM里又是什么样子；
- 系统如何加载，如何保证安全，如何换页，如何进行内存管理；
- 如何使用各种工具对NOS的image进行分析；
- 系统的语言包以及文件系统如何分布；
- 关于堆、栈、静态内存的一些internals。
- 系统地学习了Scheme语言。
- 能较为顺畅地使用尾递归，大致理解了continuation以及continuation passing style，理解了闭包和宏等等（详见我的”重新开始学习Scheme“系列）；
- 为部门同事进行了相关培训，不过效果不好，因为我确实讲得比较枯燥，而这些知识点有比较抽象。
- 另，又发现一个槽点：很多天天用Scheme开发的北京同事水平还不如我这个不用Scheme的高，真是可笑啊。正因为如此，很多Scheme相关的工作，另一个site都不愿意交给北京，因为不放心。
- 利用Scheme进行UI编程。
- 系统地研究了camera的软件架构设计，并为camera team的同事增强了camera应用（Scheme），同时发现了NOS从底层驱动到上层应用的架构模型。
- 另外一个就是为touch pad用Scheme编写了一个测试UI，使他们能够非常方便地进行测试——北京的同事用得不多，倒是国外的同事用得挺high
- 开发GNSS系统。
- 了解了GNSS的工作基本原理，并运用自己所学的软件架构与设计模式知识，根据NOS的特点设计了GNSS服务在NOS中的框架（当然，不是我一个人完成的O(∩_∩)O）；
- 学习并初步学会了如何使用Lauterbach来调试硬件设备；
- 学会了如何分析系统dump出来的寄存器、调用栈以及NOS相关的信息；
- 逐步完善了在纯异步环境里如何进行等待操作的设计；
- 大致了解了UART的工作方式以及如何为其编写设备驱动；
- 较为深入地了解了NOS的Makefile体系，为项目搭建了源码树及Makefile体系；
- 初步完成了GNSS框架和设备驱动的编码工作，目前处于调试阶段。
- 巩固了git知识和技能，为GNSS项目创建了专属的branch并进行管理；偶然充当team的git coach。
看起来好像每项做得都还不错，可惜第一项工作持续了三个季度，第二、三、五项只是我自己利用第一项工作的闲暇完成的（难道这就是我前三个季度表现不佳的原因？毕竟作为一个结果导向的公司，第一项才是重中之重。但我显然为第二、三项分配了过多的时间，因为我认为我本质上是个编码人员）。第四项是在新老板手底下开始做的，正好填满了第四季度。
事实上，正因为第二、三、五项分担了我太多经历，而我对于第一项工作的态度也没有摆正，导致自己在做第一项工作时跟两个家庭妇女发生了一些不愉快，因此可以说第一项工作，我在技术上收获不小，但公司在产出上收获不大，或者说，并没有从我这得到太多的价值。虽然最终产品按时交付了，但依然无法抹去我给这两位妇女带来的不愉快。
说实话，技术上的收获并不让我感到满意。真正让我感到满意的是在当了数年（<=3）年书呆子之后，我越来越体会到务虚和沟通的重要性，并且逐渐拾回在第一家公司练就的”见人说人话，见鬼说鬼话“的忽悠能力——这才是我这一年最大的收获。
2013年大致的计划如下：
- （首要）继续发展自己的务虚和沟通能力
- （重要）尽力把GNSS做好，以满足产品化的时间表
- （可选）温习天体物理、微积分、统计学，学习些算法知识（以能够满足工作需要为准）
总结一下：在产品/结果为导向的公司，技术是最次要的。作为一个十年经验的职场老人，是时候摆正心态了，要尽最大努力克服对技术的兴趣，专心做好职场上一切对升职加薪有利的事情。