工作

想了若干种开场白，但无论哪种都不能令我满意，于是索性就这么开场了。 工作了若干年，不经意间就形成了自己的行事和决策风格，这里权且称之为工作原则吧。这些原则引导我制定工作目标、实施过程改善、作出方案决策、选择和培养团队人员以及进行自我改进等。我也相信这些原则是主观的、具有时间和环境局限性的。也许若干年后，随着我的角色和工作的变化，许多原则将 不再适用，但这不妨碍我现在将其总结和分享出来。 ...

今天一早发现Ubuntu 12.04坏掉了，于是用了大半天对其做了修复，修复过程十分坎坷，但结果还不错，遂记之以备忘。 * 毁掉Ubuntu Ubuntu坏掉完全是由于我的错误决策。昨天一天Ubuntu桌面右上方的状态拦一直有一个红色的错误提示符，提示系统包冲突，建议执行sudo apt-get install -f解决。apt-get也提示索引冲突，无法卸载和安装任何包。于是执行了sudo apt-get install -f，虽然我不知道这个命令对系统做了哪些更改。但结果是那个错误提示符的确不见了。 ...

工作效率提升，是所有企业组织都追求的一个目标。高效率意味着用更少到人可以做更多的活儿，赚取更多的利润。员工收入也会有较大提升，有面子；管理层的收 入就更水长船高了。但说起来容易，做起来难。工作效率低下一直是让各个组织的管理者头疼的问题，组织无论大小，无论中外，皆如此。 ...

又是一年毕业季。自从九年前坐车驶出母校大门，我就再也没有回过母校，确是十分怀念，但更是怀念那些一起生活了四年的大学同学们。刚毕业那会儿，与同学们 还都保持着联系。后来大家都有了自己的新圈子，渐渐的联系少了，甚至断了。最初的校友录也荒废了，QQ我早就不用了，于是乎与大家天各一方，各自发展。 ...

一直在纠结要不要就这个话题写点什么，之前梳理过一些思路，但感觉这个题目似乎没什么大意义。不过将东西憋在肚子里的滋味总是不好受的，最终我还是选择写出来一些，即便它真的没有什么意义^_^。 ...

随着buildc在内部应用的深入，buildc逐渐进入了以内部需求和问题为主要驱动力的演化模式。我们内部的C应用多是后端服务类应用，个人 觉得具有一定代表性。buildc最初就是为了针对这类C应用而设计的。因此我们内部的需求和问题应该也同样具有一定代表性，而这种演化模式在一 段时间范围内还是有意义的。 buildc 0.3.1版本修正了上一版本的若干bug，并增加了两个新功能。 * 提高容错能力 ...

我们知道Make工具是支持命令行变量的，这种手段为我们提供了很好的灵活性，我们可以通过敲入不同的命令行参数来决定Makefile脚本的行为。 make [variable1=value1 variable2=value2 … … ]。 # Makefile CMODE = 64-bit ifeq ($(CMODE), 64-bit) CFLAGS += -m64 endif all: gcc $(CFLAGS) -o foo foo.c $> make gcc -m64 -o foo foo.c $> make CMODE=32-bit gcc -o foo foo.c 近期我们的一个Python脚本工具也有类似的需求了，但Python脚本原生并不支持这种命令行变量，我们来看看是否可以利用Python提供的机制实现一种可以满足我们需求的命令行变量。 ...

事实证明：有效的代码评审(Code Review，也有叫代码审查的），对保证代码质量具有十分重要的作用。因此这两年来我一直尝试着在这块不断改进和完善，以期望能形成一套合理、规范、有 效且高效的代码评审流程，这包括引入在线代码评审系统、走查和在线评审结合、规范评审Request的规模与有效性、设立评审专员等，用心不可谓不良苦 ^_^。大家也的确形成了及时提交Code Review Request或组织进行代码走查的良好习惯。不过我还是发现了一些问题。 ...

如果你看到一个C程序员在通宵熬夜神情紧张地对着电脑敲代码或阅读代码，多数只有两种可能：一是为了赶进度；二就是查找内存Bug。 — 个人感悟 ...

如果你问十个C程序员：你觉得C语言的核心是什么？这十个程序员都会回答：指针。 指针具备成为C语言核心的两个关键要素：强大与争议。 * 指针的强大源自于其天生与机器内存模型的适配。使用指针让代码紧凑，并可获得仅次于汇编代码的执行效率；使用指针可以让C程 序员毫不费力地尽情操纵着内存中的每个byte甚至是bit；使用指针可以为C程序员提供无与伦比的操作灵活性。总之，在C语言中指针几乎是无所 不能的代名词。得指针者得天下，没有指针，C语言将变得平庸。 ...