上午对一段代码进行单元测试，由于需要用到mock，所以选择使用cmockery 作为Unit Testing框架(lcut还未提供mock功能)。测试代码里需要mock malloc以模拟分配内存失败的异常情况。 编写一个用例后，Build，提示出错：multiple definition of `malloc’。经检查发现Makefile中定义mock malloc的那个目标文件(.o文件)居然被link了两次，类似于下面的这种错误情形： $ gcc testmain.c malloc.o malloc.o malloc.o: In function `malloc’: malloc.c:(.text+0×0): multiple definition of `malloc’ malloc.o:malloc.c:(.text+0×0): first defined here collect2: ld returned 1 exit status ...
昨天看了“外刊IT评论”上的一篇名为《软件编程21法则》的文章，文章中提到的一条法则是：“软件直到被变成产品运行至少6个月后，它最严重的问题才会被发现”，当时表示认同。不过仅仅相隔一天，这条法则就变成了眼前的现实。 今天上午我们的某版本系统在某省出现了故障，该版本在这个省上线恰好将近6个月^_^，系统上线以来一直运行良好，直到这次故障。故障现象为"挂死":所有进程都挂死在某一把锁的lock上。以前出现这种情况多为某个进程加锁后，在锁内异常退出，未能释放锁而导致其他进程挂死。这种"挂死"多是代码中访问非法内存地址导致的，一般都会有core文件dump出来。不过这次出现挂死后，我们并未找到core文件的影子。查看系统运行日志也无果。通过脚本将所有该应用的子进程的运行栈快照收集到一个文件中，然后对这个数据庞大的文件进行分析，以试图找到一些蛛丝马迹。 ...
基于各种xUnit框架的单元测试早已不是什么新鲜玩意儿，不过在"古老"的C语言领域，还尚未有哪种框架可以成为“寡头”。 记得2005年末的时候，初出茅庐的我吸取xUnit的设计思想在业余时间编写了一个轻量级的C单元测试框架lcut(Lightweight C Unit Test framework)，当时还写了一篇文章《C单元测试包设计与实现》记录了最初的设计和实现思路。本打算将这个小工具在部门内至少是项目内推广，可无奈当时部门内部尚未认识到使用框架工具进行单元测试的好处，或者尚未形成此种技术风气，当时的我也是“人轻言微”，因此这个小工具也没能吸引足够的眼球。这么长时间以来，都是我自己一直在使用， 其间，lcut做了两次小规模修改。特别是最后一次修改，通过增加测试用例执行的返回状态(增加LCUT_TEST_RESULT()宏)，让lcut可以与一些持续集成工具（如cruisecontrol.rb)结合在一起使用。 ...
部门绝大多数的产品都运行在Sun的小型机上，底层的操作系统是Solaris。这两年公司开始主推刀片机(物美价廉^_^)，不过刀片机上运行的也是Solaris 10 for x86版本。基于同种OS的前提下在Sparc和x86两种体系之间做移植比较简单，主要考虑字节序问题就可以了。不过对于可移植性的考虑不足还是让我们付出了较大的工作量。 在即将进行的新版本产品开发中，可移植性依旧没有被列入到必须要考虑实现的特性列表中，不过从未来产品演化和发展的角度考虑，现在就应该未雨绸缪，在可移植性方面多下工夫！ ...
今天下午花了一个小时分别和两位同事做了一些代码讨论，这两位同事正在编写的代码都具有一定的试验性质(暂不能进入项目代码库)。这里不谈代码如何如何，而是就我发现的一个问题谈谈我的看法。 ...
近一段时间重读了一些经典书籍，诸如《敏捷软件开发：原则、模式与实践》、 《程序员修炼之道》、《Unix编程艺术》等。这些书中关于如何衡量或评价一个类或函数设计好坏的几个原则(Principle)让人印象深刻。《敏捷软件开发》中谈到了SRP、OCP、DIP; 程序员修炼之道则以DRY、“正交性”为话题展开;《Unix编程艺术》围绕紧凑性、SPOT、分离等阐述作者立场。这么多经典原则，如何学习把握？我们不妨来挖掘一下这些新设计原则背后的本质。 追本溯源，从计算机编程语言的发展历史来看，成熟的结构化程序设计语言(如C语言、Pascal等)要先于成熟的OO设计语言(C++、Java等)出现，那么其成熟的设计理论显然也是要早于后者的。这里就不能不提到经典结构化设计的代表作：《Structured Design: Fundamentals of a Discipline of Computer Program and System Design》，这本书出于1975年(年份来自维基百科，Amazon上卖的是1979年版)。说实话我也没有看过此书原版，不过书中的内容和思想早已被其他后继书籍引用和借鉴，我们在市面上能看到的关于结构化设计方面的书籍，尤其是中文书籍，多照搬了此书内容和思想，所以也算是间接学习到了。 ...
每次安装Ubuntu后，主文件夹(你的$HOME目录)下都会默认建立起一些目录，诸如：下载、音乐、图片等，这些目录的用途通过其名字都可以猜个八九不离十，只有一个叫作“模板”的目录一直让我摸不到头脑。直到这次彻底迁移到Ubuntu，我才发现这个“模板”目录的妙用！ 平时工作中常常需要新建一些文档，以前用Windows时都会使用右键菜单，点击“新建”，然后选择不同的文档类型。但在Ubuntu上却发现右键快捷菜单中“创建文档”的二级菜单项中默认只有"空文件”这一种文档类型，这显然不能满足我的需求！ ...
今天做了一些项目版本库的搭建工作，主要是将相关模块和库目录建立好，将Makefile编写好，并添加到SVN库中。 工作接近尾声时，无意中发现提交到SVN库中的文件居然都带着可执行权限(以下称x属性)，如： -rwxr-xr-x 1 tonybai tonybai 203 2010-04-21 17:26 Makefile* 这着实让人觉得别扭！Svn居然记录了文件的权限信息，至少我以前还没有关注过这点。 ...
今天遇到一个奇怪的问题：明明我在.vimrc中开启了expandtab选项，但是当我编辑Makefile文件时，敲入的TAB就是无法被VIM自动转换为四个空格(已经设置tabstop=4，shiftwidth=4)，通过":set expandtab?“查看该选项值也居然是"noexpandtab”;编辑其他文件（如.c、.h文件甚至是无扩展名的文件)时expandtab却都是开启的，TAB也可被自动转换，百思不得其解! ...
每当你Build Project代码的时候，如果看到的是满屏的Warning，那么提醒你小心了，不妨看看《高效程序员的45个习惯》中对Warning的态度和处理方式。该书中的第34个习惯讲的是“警告就是错误”！ 当然这个“习惯”所阐述的内容并不是这本书首创，在很多经典的传授编程之道的书中也都提到过。 ...