部门的持续集成一直做的不太好，我们开发部这边甚至一直没能做起来，这其中有各种原因：工具、意识、执行力、沟通等等。将持续集成引入到我们的开发过程中也一直是我的一个目标。去年末启动的一个项目让我感到时机变得成熟了。 新项目的代码是完全重写的，这样的机会甚是难得。因为大多数情况下大家都是在维护现有系统：做些添添补补、修正Bug以及优化之类的事情。项目初期，我特别向大家强调了要严格遵守统一代码风格并将astyle代码格式化工具介绍给大家，手把手地教大家如何利用类似LCUT这样的单元测试框架编写单元测试，讲解什么是Mock测试。前些时间我又将代码风格检查 脚本加入到工程的构建过程中，并将代码风格检查作为最终构建目标的关键依赖，强制大家编写出统一风格的代码。 ...
今天是Ubuntu 11.04版本(Natty Narwhal)发布的正日子！想必全世界的Ubuntu Fans们都会或多或少的兴奋上一阵儿。我接触Ubuntu这个Linux发行版较早，甚至可以追溯到Ubuntu 5.10。不过真正将Ubuntu作为我日常工作学习的第一操作系统还是在去年Ubuntu 10.04LTS版本发布之后。从那时起到现在整整有近一年时间了。这里我也来说说这一年来使用Ubuntu的感受。 ...
本文翻译自"The Boy Scout Rule"，来自于《程序员应该知道的97件事》一书中的某个章节。 童子军有一条规则：“永远保持离开时的露营地比你发现它时更整洁”。如果你在地面上发现了脏东西，那么无论是否是你留下的，你都要将它清理干净。你有意地为下一组露营者改善环境。（实际上，由童子军之父罗伯特·斯蒂芬森·史密斯·贝登堡编写的原版规则是这样的：“尝试让这个世界在你离开时比你发现它时变得更美好。”） ...
代码风格（style）一直是一个见仁见智的问题，但是对于一个团队而言，如果能在代码风格上达成一致，显然无论对团队还是对个人来讲都是大有裨益的。 ...
本文翻译自"Fulfill Your Ambitions with Open Source"，来自于《程序员应该知道的97件事》一书中的某个章节。 如果你在工作中没能开发那些可以实现你雄心壮志的软件，那你将有很不错的机会。也许你正在为一家庞大的保险公司开发软件，然而你实际上却宁愿供职于Google、Apple、Microsoft或是你自己初创的公司去开发下一个对世界影响巨大的软件。如果你去为你根本不关心的系统开发软件，那你永远也实现不了你心中的抱负。 ...
当今的软件开发更多是团队合作，团队的所有成员均工作在同一份代码库上。这样即便是有了先进的版本控制管理工具（诸如Subversion、Git等），出现冲突（Conflict）的情况也是在所难免的。这就需要你学会解决冲突。 以Subversion为例，多数人在学习这类工具时都选择了浅尝辄止，仅仅停留在会使用update和commit这些常用的命令上。这样大家就错过了那些可以帮助你快速解决冲突的命令，以致很多人无论遇到任何冲突情况都采用了低效的全手工处理的方式。实际上不同的冲突情形处理的方式是有差别的。某些情况下，利用类似svn resolve这样的命令可以帮你快速解决冲突。我们应该有意识地采用一些专业的做法，不是吗？^_^ ...
自从换装Ubuntu后，就一直使用Thunderbird。很是喜欢Thunderbird超快的搜索速度、按主题组织和展示Mail以及易用的快捷键。不过这两天Thunderbird一直在给我制造麻烦。通过Top查看，我发现我的Thunderbird一直在持续占用20%-30%的CPU，这导致我的本子变得很慢。虽然能看到这个进程，但是并不清楚Thunderbird究竟在做什么。开始怀疑它在后台压缩文件夹，我遂显式对每个mail较多的文件夹进行了一次压缩。压缩后Thunderbird似乎安静了一会儿，不过好景不长，不久那个进程又开始运转起来了。我怀疑这是个Bug，于是有了升级Thunderbird的想法。 翻看了一下Thunderbird的菜单，发现它似乎不支持在线升级更新。我使用的版本是3.0.6，官方最新稳定版本为3.1.9。下载最新安装包后菜发现这个包不过就是一个压缩的文件夹，文件夹里有Thunderbird可执行程序和一切它依赖的资源文件。这样看来Thunderbird的升级实际上就是一个“替换”的过程。 ...
近期产品线研发体系正式将Review Board这款优秀的基于Web的代码评审开源工具引入到开发过程中，作为产品线内各项目组进行代码评审的辅助工具。我对Review Board近两年多的关注总算没有白费，算是有了一个还算不错的结果。不过Review Board的正式使用并不代表一种结束，反而恰恰是一个新的开始。我们下一步要关注的是如何用好Review Board，让它真真正正地为改善产品质量和开发效率出力。 ...
部门一直使用Subversion作为源码版本的管理工具。说实话，Subversion比较适合目前部门的绝大多数项目：没有异地团队开发，代码中心化管理；基本上都在trunk上开发，较少使用分支，基本上没有在各个branch间切换的成本。但对于我来说，有些情况下Subversion并不能满足我的需求。 问题主要集中在本地代码的备份和版本管理上。也就是说对于尚未或暂无法提交到Subversion服务器的本地代码来说，存在着被误删除和版本更新无法回退两大杯具情形。而对于这些情况，Subversion工具是无能为力的。 这时我们就需要借助其它工具来帮我们解决问题。Git就是这样一款很给力的工具，它是一款分布式版本管理工具，由linux的缔造者Linus Torvalds设计并实现，具体关于Git的介绍和使用方法可参见其官方站。这里要说的是Git是如何做到既可以管理好本地代码又可以与已有的SVN中心库进行同步的。 ...
周四下午，收到同事的一封mail，他告诉我他的业务代码中使用的一个库接口的行为与预期不同，并在mail中给出了测试代码和测试结果。而这个接口是之前由我封装实现的。 ...