近期在为产品线的知识库编写一些指南类的文档，其中有一项就是对现有的C语言编码规范进行一些修订。为了"有米下锅"，我还特意在网上找了一些相关资料。关于C语言编码风格和标准的资料大多都成稿于上个世纪90年代，也就是在C90发布之后的若干年里；在C99发布后，部分资料根据最新的规范做了修订，但也有些资料认为C99对整体风格影响不大，也就保持了原样。 在这些资料中，我重点关注了一下这份文档《Recommended C Style and Coding Standards》，它是著名的"Indian Hill C Style and Coding Standards"的更新版，从Google的搜索结果来看，似乎影响很广。这份文档内容不多，言简意赅，特别是后面的几个小节，例如宏、条件编译、可移植性以及ANSI C等章节很值得细致阅读和理解。 ...
Adapter(适配器)模式是《Design Pattern》一书中结构类模式集中的第一个模式，也是一个真正被我的同事在产品代码中应用的模式。 Adapter模式也是一个相对容易理解的模式，多数书籍和网络资料在描述这个模式时都使用了一个与电源适配器有关的例子，说不定Adapter模式还真的是源于对电源适配器的再思考和挖掘呢。 ...
今天着实是一个值得纪念的日子，因为我终于完成了从BlogBus到WordPress的搬家工作，从此我的Blog将站在一个新的起点上。 自从2004年开博以来，我坚持了七年多，至今仍孜孜不倦，写博客已经成为我的生活中不可或缺的一部分，即使在微博等大行其道的今天，我亦然如此。作出搬家的决定显然是十分痛苦的，因为要抛弃已经建立起来的使用习惯以及Blog人气(包括搜索引擎索引、外部引用的等)是十分艰难的。但我还是决定搬家，更多是因为我的一个小小的梦想：拥有一个自己可以完全控制的独立域名的个人站点。 tonybai.com这个顶级域名是在2010年申请的，2010年末曾经尝试过一次搬家，但因技术原因最终没能实现。但鉴于BlogBus提供的服务愈发地不稳定，我又动了搬家的念头，而且有了上次失败的教训，这次我做好了充足的资料和技术准备。但即使如此，搬家过程依旧很辛苦，并且足足花了我一周多的业余时间，下面就来罗嗦一下搬家的过程。 ...
我们的后端C应用都是支持跨平台的，至少目前在Linux和Solaris上运行是没有问题的，这样一来我们在配置持续集成环境时就要考虑如何实现在代码Commit后触发多平台并行(同时)集成这个需求。 之前使用Buildbot时是通过为一个Scheduler配置多个Builder满足这个需求的。但现在要换成Jenkins，我们如何来实现呢？昨天在折腾Jenkins时我把问题想简单了，今天细致查看了一下Build Log后才发现之前的配置并未真正实现多平台并行集成。 最初的Jenkins配置大致是这样的：我在Jenkins上添加了两个节点(Slave Node)，分别为x86-linux-ci-slave和x86-solaris-ci-slave，并且为这两个节点设置了一个相同的标签"foo-ci-slaves"。之后我创建了一个新Job – “foo-multiplatform-ci”，选择的是"构建一个自由风格的软件项目(Build a free-style software project)"。为了使得该Job执行并行集成，我选择了"Restrict where this project can be run"，在"Label Expression"中填上了"foo-ci-slaves"，其他配置这里就不赘述了。 ...
Buildbot是产品线C应用项目中采用的唯一持续集成工具，一直以来用得还不错。但前些日子部门负责过程改善的同事找到我，说今年部门计划统一各个项目组所使用的Continuous Integration工具，Buildbot有些小众，没有入大家的法眼，部门期望使用的是Jenkins(即原来的Hudson)。既然组织有统一规划，那我自然积极支持。但首先要做的就是评估Jenkins是否能满足我们的需求，并且看看从Buildbot迁移到Jenkins的难度及工作量有多少。这不，今天下午就一直在折腾Jenkins。 一、安装Jenkins Jenkins(前身Hudson)很流行，在各大主流操作系统平台上都有很好的支持，其安装甚是方便，特别是在各主流的Linux发行版平台上，均可使用OS自带的应用包管理工具进行自动安装；当然你也可以直接在官方下载war包。我采用的就是第二种方式，旨在获得更高的Jenkins版本，不过让我失望的是在Ubuntu 9.04(Java version: 1.6.0_20)上，最新的1.451和1.450版本均启动失败，这也是我之前不太喜欢使用Java实现的工具的一个原因之一 – 总是容易出现莫名其妙的异常，而且较难找到原因，也很难fix，除非自己重新构建war包。在这方面像Python等动态脚本语言就有先天优势，一旦出现问题，我可以直接在源码中定位和修改。 ...
在"也谈C应用安装包制作与部署“一文中，我提到了为每一个源码工程建立单独的安装包制作工程(setup project)的想法，这两天我就一直在折腾这件事儿^_^。 最初我并没有想去搞一个通用的安装包制作工具，只是为一个现有的源码工程建立了一个试验性质的安装包工程，并实现了其构建脚本(build.py)。但之后考虑到各个项目都要建立一个对应的安装包工程，安装包工程的构建脚本build.py势必会沦落成被copy来copy去的下场，这显然不是一个很好的解决问题的办法。那是否需要再单独设计和实现一个安装包制作工具呢？工具多了，大家用起来肯定会很烦，不能自找没趣^_^。要知道为程序员编写工具可是一件很困难、很头疼，需要你很谨慎的事情。现在我们已经有了源码工程构建工具buildc，我前几天还为buildc添加了安装脚本，并用之改造了一个真实的工程，并给大家做了讲解，可以说大家对buildc算是接受了。 ...
buildc在发布0.1.0版时并没有做好安装脚本，当时的建议是直接下载0.1.0的源码包或svn export/checkout源码包，并手工将buildc目录位置加入到用户的PATH环境变量中。近期buildc计划正式投入到项目中使用，为了方便大家安装以及以后的统一升级维护，我花了些时间给buildc加上了setup脚本。 Python有标准的程序分发方案，不过我对这些了解不多。buildc本身很简单，我觉得没有必要把安装做得很复杂，所以就自己动手编写了一个setup.py，不到100行，用于安装buildc。 Python的标准安装脚本也叫setup.py，我这里也借鉴了这个名字。有了setup.py，buildc的安装就简单多了： * 下载buildc Release包(当前最新是buildc-0.1.1) * 解压发布包，在发布包路径下，执行setup.py install [–prefix=YOUR_INSTALL_PATH] ...
虽然部门一直在做C应用，但这么多年来，在C应用的安装包制作以及部署方面做得还是很初级，可以说还没有达到规范的程度。各个产品线的C应用安装包种类多样，水平参差不齐：有些产品的源码包即是安装包，把源码包拿到生产环境下编译后使用；有的项目则将编译好的目标文件(.o)以及第三方库放在安装包中，在生产环境下重新链接生成可执行文件；有的组则稍微专业一些，安装包中放的是编译好的可执行文件，但在目标主机上安装和执行时也都遇到了一些问题，诸如运行环境中的第三方库版本号与程序所依赖的不一致等。 去年年底，我就将"C应用安装包制作和部署"的改进作为今年的一个工作重点。这两天我粗略地考量了一下这方面的内容，这里也简单地谈谈。 ...
对于我这个上班族来说，这假期真的不能太长，否则就适得其反了：不但不会得到很好的休息，反而感觉更累了。也许很多朋友和我有同样的感受^_^。这不，这个春节在家待得就比较"闹心"，特别是后几天，想上班的冲动那叫一个此起彼伏啊，终于今天如愿了^_^。 ...
2012，是农历龙年，也是中华民族的本命年。龙，是我们民族的图腾，大家对龙都是有着特殊的情感的，比如壬辰年的生辰龙票就特别抢手。 龙年了，果果也长大了，越来越像女孩儿了，呵呵（因头发短，常被人误认为是男孩儿），下面是果果近期的一些写真^_^，请您欣赏： ...