虽然部门一直在做C应用，但这么多年来，在C应用的安装包制作以及部署方面做得还是很初级，可以说还没有达到规范的程度。各个产品线的C应用安装包种类多样，水平参差不齐：有些产品的源码包即是安装包，把源码包拿到生产环境下编译后使用；有的项目则将编译好的目标文件(.o)以及第三方库放在安装包中，在生产环境下重新链接生成可执行文件；有的组则稍微专业一些，安装包中放的是编译好的可执行文件，但在目标主机上安装和执行时也都遇到了一些问题，诸如运行环境中的第三方库版本号与程序所依赖的不一致等。 去年年底，我就将"C应用安装包制作和部署"的改进作为今年的一个工作重点。这两天我粗略地考量了一下这方面的内容，这里也简单地谈谈。 ...
对于我这个上班族来说，这假期真的不能太长，否则就适得其反了：不但不会得到很好的休息，反而感觉更累了。也许很多朋友和我有同样的感受^_^。这不，这个春节在家待得就比较"闹心"，特别是后几天，想上班的冲动那叫一个此起彼伏啊，终于今天如愿了^_^。 ...
构建是软件开发过程中最常见的活动之一，也是很容易被忽视的环节。规范以及高效的构建对软件开发过程而言是大有裨益的。C语言并非一门年轻的语言，其历史已甚为悠久了(相对于还年轻的IT领域^_^)。从C语言诞生以来，市面上存在的C语言应用何止千千万万。这些C应用的源码组织形式种类万千，从最简单的单个源文件，到复杂的诸如Apache httpd server这样庞大的Project。不过无论这些C应用的源码组织形态如何，构建都是这些应用开发过程中必不可少的一步。 ...
每至年关，回首一年工作中的成长，便有一种充实和幸福的感觉。 2011年我在工作中的成长可概括为如下几点： 1、建立并围绕原则为中心开展工作 现在想来，以前的工作有些盲从，心中没有原则，自然也就没有主线，也许这与当初的职位角色有关。2011年职位提升了，思维方式也有所了转变。我花了更多的时间对当前的工作进行考量，而且考量的过程不是过去那种仅仅从项目组或产品线的角度，而是尽量上升到组织的角度，并针对当前工作建立起一系列原则，这些原则成为了我在工作中决策的基本出发点。以这些原则为基础，安排自己与他人的工作就有了着力点，一切显得十分自然合理。 ...
这周五我做了一件"恶事" – 劝退了一名员工。这样的事情在部门成立10年的历史中发生的次数都是屈指可数的，但却真实地让我给碰到了。 ...
近期完成了与组员的年终绩效面谈，收集上来一些意见和建议，其中有一些涉及到部门对大家反馈的意见和建议处理不妥的情况，对此我也做了认真的考量，于是就有了这篇短文。 ...
2011年我的确读了不少书，掐指算来纸版和电子版加在一起近50本，其中以技术类居多，但其他方面的也有一些。这里列出来做个简单回顾。 一、技术类 · 《你必须知道的495个C语言问题》 早在这本书出版前，其译者已经在网上完成了C FAQs的翻译(在这里)。这本书是基于最新C FAQs做了重新整理(包含C99)。虽说是最新，但因C语言近几年来变化很小，内容与之前译者在网上公开的那个免费版本相差不多。这本书适应面很广，初学者可以从中了解到很多谭氏教程中没有的东西；有经验的C程序员可以把它当成一本手册，需要时翻看。对于那些很在乎C语言细节的程序员来说，翻看一遍也未尝不可。 ...
2011年眼看就要接近尾声了，这里也对自己在2011年的"所作所为"做个小结^_^。 这一年来工作之外的我过得还是比较充实的，从下面的数字也可以看出： - 写了81篇博文 - 开源了2个工具(CBehave和buildc) - 合译了一本书（"Seven Languages in Seven Weeks"，不过尚未出版） - 读了近50本书（通过豆瓣读书统计） - 新学了一门语言 – Common Lisp - 新用了一门语言 – Python ...
这几年我一直从事C语言项目的开发。这些项目的规模都不算小，少则十几万代码，多则几十万行代码，至少也都算得上是中型项目吧。项目构建工具使用的是传统的Make工具，构建脚本都是自行编写的，构建时直接在顶层目录下敲入make即可。 这种传统的构建方式其实是很耗时费力的。比如执行make之前你需要根据项目代码的实际路径重新设定一些环境变量或修改Makefile中的某些标识路径的变量；你还要将项目依赖的各种内部公共库、第三方开源库悉数找到，并安装在指定目录下，修改Makefile中这些第三方库的路径配置。只有做完这些后，你才能顺利地执行Make。以后每当你更换一个环境，你就要将上面的步骤重复执行一遍。有的项目第三方依赖较多，要完整地搭建一个项目构建环境所耗费的时间也是很惊人的，特别是对一些不熟悉项目构建的新人更是如此。另外随着产品被要求具备在多个平台上运行的能力，你的构建脚本还要支持在多个平台上的构建，你要为项目所依赖的第三方库准备多个平台的版本；当某个依赖库版本进行了升级，你还要手工在多个环境下进行更新。 ...
我们在平时编码过程中很少考虑代码的安全性(security)，与正确性、高性能和可移植性相比，安全性似乎总被忽略。昨天从安全性角度泛泛地Review了一下现有的代码，发现了不少具有安全隐患的地方。我们的程序员的确缺乏系统地有关安全编码方面的训练和实践，包括我在内，在安全编码方面也都是初级选手，脑子中对安全性编码缺乏系统的理解。 ...