Opensource

昨天一位同事发了一篇小文档，文档中介绍了一种开源格式化代码的工具，名为Artistic Style(astyle)，功能看起来还是很不错的。之前我写代码时比较注意代码的风格，一直按照自己的思路来美化自己的代码，用的最多的辅助工具就是Vim自带的indent功能，对这之外的格式化工具少有涉猎。记得几年前部门曾推广一款名为checkstyle的Java代码格式规范检查工具，由于当时基本不接触Java，也没有用过。 ...

对于我个人来说，将工作环境切换到Ubuntu上来有几个“坎儿”要迈过，其中最为迫切的一个就是Mail如何在Windows和Linux下共享的问题，今天我找到了解决方法。 Thunderbird和Firefox一样，都来自Mozilla组织。和Outlook等软件不同的是，Thunderbird是可以跨平台的，更有甚者，Thunderbird可以帮助我们在Windows和Linux共享邮件，当然需要作简单设置。 我的机器上安装了三系统：WinXP、Ubuntu 9.10和Slax，其中常用的是WinXP和Ubuntu。在Windows上最常用的Mail Client端软件为Outlook 2003，但Outlook是收费软件，不支持夸平台，更谈不上Mail跨平台共享。而这些恰恰是Thunderbird吸引眼球之所在。 ...

Ubuntu 9.10版本在10月29日发布，虽然没有太多吸引我的地方，但是看了网上很多关于Ubuntu 9.10的文章后，心里面还是痒痒的，终于在上周五我用午间休息时间完成了Ubuntu 9.10版本的安装。 ...

Review Board安装成功至今已半月有余，这期间我一直在试用它，虽欣喜于其提供的强大的功能，但还是有若干使用中的问题一直让我头痛不已，同时也阻碍了在部门推广该工具的进程。 ...

安装完中文语言包支持后，Ubuntu的默认locale是zh_CN.UTF-8(即简体中文语言环境，字符集内码UTF-8)。这与我们日常开发环境中Unix设定的环境有所区别，我们日常使用的环境一般为zh_CN.GBK或zh。我们的源代码文件的字符编码也都是GBK的编码，直接在Ubuntu下用默认设置的VIM打开后，中文的注释会显示乱码。如果你直接编辑这个文件并提交，那么其他在Unix下开发的同事Checkout这份源码后打开也将显示乱码（你新增的中文内容会是乱码）。 解决这个问题至少有两种方法：一种是为Ubuntu新增加一个zh_CN.GBK的locale的支持，内码使用GBK；另外一种就是通过设置VIM，在不变换Ubuntu所支持的locale(内码依旧是UTF-8)的情况下支持对GBK内码文件的读写。 ...

在’IDEAL Garden‘上看到作者在文章中提到一个名为Vimperator的FireFox插件，该插件功能甚是强大，可以让你以Vim的操作方式来使用Firefox，对于我这个天天都用Vim写代码的人来说，Vimperator可谓有非凡的吸引力，它可以让你的手指留在键盘上。 安装Vimperator这个插件仅需十几秒的时间，重启Firefox后你就可以以Vim的操作方式来尽情操作Firefox了。重启Firefox后，Vimperator会自动打开其Tutorial页面(你也可以通过在命令行输入’help tutorial’打开tutorial页面)。Tutorial页面介绍了Vimperator的大多数基本命令，熟练掌握了这些命令你就可以自由操控Firefox了。 ...

目前部门还没有采用Pair Programming那种时时刻刻都在review代码的工作方式，代码Review多采用走查方式，即代码写完后召开一个Code Review的Meeting，集中时间和经验丰富的人力对重点代码进行筛查，这种方式的代码Review有利，但也有弊。其弊端在于低效和覆盖面小。做一次走查需要N多人参与若干个小时，而在这段时间里不是每个参与者都能极其高效的参与到走查中的，实践证明只有少数几个人能真正在一次代码走查会议上起到关键的作用。另外走查一次能覆盖的代码范围又较小，一些看似不重要却很可能带来BUG的代码在走查会上很容易被遗漏。 ...

部门服务器资源向来都比较紧张，每当忙碌季节到来，服务器资源消耗都较大，开发人员总是抱怨编辑代码慢、Build慢以及磁盘空间不足等问题，严重时甚至无法工作。部门也一直在尝试改善这个问题，无非加服务器、加磁盘等，但是这些措施似乎都难以满足开发和测试人员日益增长的对服务器资源的索求。 ...

在Unix平台工作的人都使用过Shell的重定向功能，多数人接触较多的是简单的重定向，比如： cmd > some_file 将cmd命令的标准输出重定向到some_file中 cmd < some_file 将some_file的内容作为cmd命令执行的标准输入，或者简单的说cmd命令从some_file读取输入 ...

近两天一有空就会去看看项目代码，思考一下如何利用cmockery对项目里已有的代码进行测试。项目代码中很多被调用的接口都带有输出参数，而且在这些接口中多利用返回值指示执行成败也否，而利用输出参数返回一些关键结果，这些结果值甚至影响着后续的函数执行流程。前期研究cmockery时没有注意到cmockery是否可以设置被mock接口的输出参数的值，不过回顾了一下cmockery实现的原理，觉得cmockery是应该可以支持的。遂重新翻看了一下cmockery的manual，发现在mock_query_database中确有对输出参数的mock调用，代码如下： // Mock query database function. unsigned int mock_query_database( DatabaseConnection* const connection, const char * const query_string, void *** const results) { *results = (void**)mock(); return (unsigned int)mock(); } void test_get_customer_id_by_name(void **state) { DatabaseConnection connection = { “somedatabase.somewhere.com”, 12345678, mock_query_database }; int customer_ids = 543; will_return(mock_query_database, &customer_ids); will_return(mock_query_database, 1); assert_int_equal(get_customer_id_by_name(&connection, “john doe”), 543); } ...