Programmer

挖掘简单现象背后的复杂本质。– Tony Bai^_^ 上文讲到Linux Kernel的配置和编译十分简单，甚至简单到可以与一个用户层应用相媲美。这一切都是因为Linux Kernel实现了一套易于使用、变更和后期维护的配置和编译体系。要知道最新Linux Kernel版本的代码量可是千万级别的，并且模块众多，其背后的配置和编译体系一定不那么简单，这次我们就来尝试Hack一下这套体系。 ...

Linux Kernel之于C程序员，就好比世界之巅珠穆朗玛之于专业登山客。 — Tony Bai^_^ 作为到目前为止最为成功的开源项目，Linux Kernel总是散发着无穷的魅力，就好比那珠穆朗玛，让人魂牵梦绕，心潮澎湃并总是想尝试征服。 ...

近期在为产品线的知识库编写一些指南类的文档，其中有一项就是对现有的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模式还真的是源于对电源适配器的再思考和挖掘呢。 ...

我们的后端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"，其他配置这里就不赘述了。 ...

虽然部门一直在做C应用，但这么多年来，在C应用的安装包制作以及部署方面做得还是很初级，可以说还没有达到规范的程度。各个产品线的C应用安装包种类多样，水平参差不齐：有些产品的源码包即是安装包，把源码包拿到生产环境下编译后使用；有的项目则将编译好的目标文件(.o)以及第三方库放在安装包中，在生产环境下重新链接生成可执行文件；有的组则稍微专业一些，安装包中放的是编译好的可执行文件，但在目标主机上安装和执行时也都遇到了一些问题，诸如运行环境中的第三方库版本号与程序所依赖的不一致等。 去年年底，我就将"C应用安装包制作和部署"的改进作为今年的一个工作重点。这两天我粗略地考量了一下这方面的内容，这里也简单地谈谈。 ...

构建是软件开发过程中最常见的活动之一，也是很容易被忽视的环节。规范以及高效的构建对软件开发过程而言是大有裨益的。C语言并非一门年轻的语言，其历史已甚为悠久了(相对于还年轻的IT领域^_^)。从C语言诞生以来，市面上存在的C语言应用何止千千万万。这些C应用的源码组织形式种类万千，从最简单的单个源文件，到复杂的诸如Apache httpd server这样庞大的Project。不过无论这些C应用的源码组织形态如何，构建都是这些应用开发过程中必不可少的一步。 ...

restrict关键字是C99标准中新引入的一个类型修饰符(type qualifier)。如果你看过GNU C库的源码或是其manual，你就会发现restrict修饰符被广泛地应用在GNU C库中。restrict关键字到底是用来做什么的呢？估计很多对C语言细节研究不够的程序员都无法给出答案，我个人也只是停留在"知道"这一关键字的层次上，于是乎今天我又对着C99规范钻研了一番，略有收获，这里也说道说道。 为何C标准委员会要在C99标准中引入restrict呢？这当然是有历史原因的。我们先来看看下面这个例子： /* foo.c */ void foo(int *p, int *q, int *r) { *p += *r; *q += *r ; } ...

上个周末花了些时间将《Pro Git》（Git高手进阶之必读书籍，严重推荐^_^）快速地浏览了一遍，在感叹于Git强大的同时，也见识到了Git的复杂。可以肯定的是Git学习曲线远没有学习Subversion那样平坦。比如，Subversion工作目录下的文件只有三种状态：Untracked、Modified和Committed(即Unmodified)；而以Git本地工作目录下则有四种状态：Untracked、Staged、Modified和Committed(即Unmodified)。虽然只多出了一种状态，但感觉其复杂度又上了一个台阶。 Git在这里只是一个引子，我真正要说的还是设计模式，只不过这个模式对应的例子实现与Git的一个命令相关罢了。这个命令就是Git status。Git status可以根据当前工作目录下文件的不同状态输出不同的提示信息，例如，对于工作目录中处于"未跟踪"状态的文件foo.txt，Git会输出下面信息： $ git status # On branch master ...

提到Transaction模式(即事务模式)，很多人会感到陌生。这并不奇怪，在大名鼎鼎的GoF的《Design Pattern》一书中，它仅仅是Command模式的别名罢了。不过在实际的开发中，我们却经常会遇到可以应用事务模式的场景。本文可以理解成Command模式在事务领域的应用，但这样说有些麻烦，我们莫不如直接称之为Transaction模式。 与前几篇设计模式C实现系列文章一样，这篇文章也源于对实际问题的思考和总结。这次的问题是这样的：我们的业务系统实现了一个ftp上传文件的功能，其v1版代码的结构简化后大致如下： int ftp_upload_file(const char *filename, const remote_server_desc *desc) { int ret; ...