有这样一段代码： /* foo.c */ #include “stdio.h” inline void foo() { printf(“inline foo in %s\n”, __FILE__); } int main() { foo(); return 0; } 我采用C99标准，并在不加任何优化选项的情况下编译之： $ gcc -std=c99 foo.c -o foo foo.c: In function ‘foo’: /tmp/ccLGkuIK.o: In function `main’: foo.c:(.text+0×7): undefined reference to `foo’ collect2: ld returned 1 exit status ...
Paul Graham不愧被誉为Lisp的超级推手，他的煽动力真的是很强悍。这不才刚刚看完一遍他编写的《黑客与画家》后，我就决定将Common Lisp作为今年计划学习的那门新语言，而且从现在就开始。 去年曾囫囵吞枣般的学习过Haskell，一门通用且庞大的纯函数式编程语言。在惊叹于Haskell如此与众不同且功能强大的同时，也为Haskell Monad那魔鬼般的蹩脚语法所苦恼，而Monad的引入就是为了隔离副作用，并让你可以利用些过程式命令式语言解决问题的范式。 ...
多数公司不会仅有一个项目，当你为一个项目引入持续集成实践后，其他项目就会接踵而来。这时你会重新考量BuildBot，考虑如何让BuildBot可以服务于多个项目。 如果你有足够的主机资源和人力资源，那为每个项目单独搭建一套CI环境是再好不过的了，每个项目都有专人维护CI环境，各个项目的配置互不干扰。不过对于一些公司来说，这显然有些浪费，BuildBot Master的资源消耗是不大的，我们完全可以使用一套BuildBot Master来服务于多个项目，至少BuildBot是可以支持这样做的。 ...
最近观察到这样一种情况，项目组内的两位比较资深同事似乎都习惯于这样来编码：他们可能会花上两、三周时间将一个模块的成百上千行代码一气呵成的编写完，然后再去与其他人编写的代码集成在一起编译，测试，最终提交。这种情况让我有些惊讶，因为我觉得一个良好的编码节奏不应该是这样的，原因有三： ...
在“使用BuildBot搭建持续集成环境”一文中我曾经说到：公司使用的mail服务器只支持SSL连接，而BuildBot似乎对SSL连接的支持有些问题，导致构建结果mail无法发送“。BuildBot实际上使用的是Twisted的mail库来发送邮件的，我下载了Twisted的一些mail发送的例子程序，并使用我的公司mail账户配置，但依旧发送失败。看来这个问题与Twisted的实现有关了。 这个问题已经折腾我许久了，难道非得让我去debug Twisted库？还好，今天我想到了另外一种方法：使用stunnel。原理是这样的：通过stunnel将非SSL连接转换为到公司mail服务器的SSL连接，通过stunnel建立的这条转化通道，mail发送的问题就应该可以解决了。想法归想法，实际上能否达到我的目标，还得通过试验验证。 首先我们需要在BuildBot的master服务器上安装stunnel。 ...
这两天参加了一个Android开发入门培训，讲师的水平不敢恭维，课讲的基本上也是一塌糊涂，不过通过这次培训，我算是达到了Android开发快速入门的预期目标。 一般来说Android应用开发的标准工具组合是JDK + Android SDK + ADT (Android Development Tools) + Eclipse，大家基本上是通过IDE GUI进行开发操作的。不过我个人更喜欢命令行，所以这次我也尝试探索了一下使用命令行方式开发Android应用的方法。 入门的第一步就是搭建开发环境。关于Android开发环境搭建的资料早已汗牛充栋，不过我也看了一下这些资料多是关于如何在Windows下使用Eclipse搭建环境的，而在Linux环境下不用Eclipse的手工搭建环境的资料甚少。而我用的是Ubuntu 10.04，所以在这里我想说说Ubuntu下搭建Android开发环境的过程，以及在此过程中遇到的诸多问题的解决。 ...
有了BuildBot搭建的持续集成环境还远未结束，具体的构建脚本还得自己来写。我们用的是Make工具，对应要编写的脚本就是Makefile。 Make是日常代码构建常用的工具，尤其是绝大多数C和C++项目都会将Make作为首选构建工具。平时多数情况大家都是直接敲入make命令便开始了构建过程，很少有人为make传入什么参数的（调试Makefile的情况除外）。但是有些时候自定义的Make命令行变量还是很有用处的，特别是在将Make与持续集成环境集成的时候。 ...
部门的持续集成一直做的不太好，我们开发部这边甚至一直没能做起来，这其中有各种原因：工具、意识、执行力、沟通等等。将持续集成引入到我们的开发过程中也一直是我的一个目标。去年末启动的一个项目让我感到时机变得成熟了。 新项目的代码是完全重写的，这样的机会甚是难得。因为大多数情况下大家都是在维护现有系统：做些添添补补、修正Bug以及优化之类的事情。项目初期，我特别向大家强调了要严格遵守统一代码风格并将astyle代码格式化工具介绍给大家，手把手地教大家如何利用类似LCUT这样的单元测试框架编写单元测试，讲解什么是Mock测试。前些时间我又将代码风格检查 脚本加入到工程的构建过程中，并将代码风格检查作为最终构建目标的关键依赖，强制大家编写出统一风格的代码。 ...
市面上关于优秀编程风格和习惯养成的书籍还真不少，其中“叫好又叫座”的书诸如《代码大全》、《编程精粹:编写高质量C语言代码》、《编程匠艺》、《重构》以及《Clean Code》等。不过前些天我在网上下载了一本名为《The Elements of Programming Style》的电子书，看过此书后，我才知道开创编写优秀风格代码之路的鼻祖是谁（不知道是否还有比这本书更加古老的且系统地讲述优良编程元素的书籍了？）。 ...
本文翻译自”Comments Only What the Code Cannot Say“，来自于《程序员应该知道的97件事》一书中的某个章节。 我们知道理论与实践之间存在差异。在实践中，这个差异远大于其在理论中所描述的那样 – 一份对注释（comments）的观察数据也证实了这一点。理论上，通常的注释代码的想法听起来是值得的：它可以为读者提供更多的细节，可以解释发生了什么事情。有什么能比自我帮助更具可帮助性的呢？然而在实践中，注释却经常变成一个破坏因素。与其他书面形式一样，编写好的注释也是有技巧的。这个技巧的主要内容是知道何时不写注释。 ...