开源

buildc这个小工具逐渐在项目组内部扩大了使用范围，还有一名专门的同事负责为每个项目制作安装包工程，这样也可以在使用中发现buildc的问题。 本次buildc 0.1.8的相关修正以及新增的feature就是我的这位年轻同事一手操刀完成的，他也是一个python新手，同样也是边翻手册边进行编码的。这次改动主要集中在templates目录下的几个文件，这里的文件多为因工程的不同而异的。 ...

刚刚过去的这一周搞得我十分疲惫，起因是岳母生病了。 果果自出生以来一直是岳母照顾，这个五一岳母将果果带回老家待了一周，也许是太过操劳导致旧病复发(腰椎肩盘轻微突出)，无法坚持照顾果果了。可这段时间 又恰逢我和我LP都很忙碌，但无奈身边没有亲戚，只能我请假待果果(LP那里集团领导检查，实在无法脱身)，还要照顾生病的岳母。本以为病两三天就能好 转，但观察两天后仍不见好转，于是我只能将母亲大人请来照顾果果，好抽身上班。万没想到，我母亲刚来一天多，居然也生病了，估计是上火所致(母亲大人十分 易上火，尤其是出远门)。于是乎又将母亲送回家里，这一顿折腾啊，转眼间5天过去了，终于盼到了周末，老婆也休息了，疲惫的我也可以缓缓了。 ...

在很多公司内部，要想访问外部互联网都需要设置代理，我所在公司也是这样，有些时候这种限制真的可以让人骂娘。不过经过几年与代理的"斗争"后，大部分需 要访问外部网络的软件(比如subversion、apt-get、git、wgetc、filezilla等)经过设置后还都可以正常工作。不过前些日 子在折腾bitbucket上的源码库时又遇到了代理问题：无论通过https方式还是ssh方式都无法clone bitbucket上的git库。 ...

今天在互动出版网看到《七周七语言：理解多种编程范型》一书已经开卖了。看到自己参与翻译的第一本书出版了，心中还是很愉悦的，因为自己的辛苦付出终于有了结果。 一、缘起 能够参与到这本书的翻译完全是机缘巧合。记得2011年初我启动了一个《Programming in Haskell》的公共翻译项目，可是由于欠缺版权的考虑，中途不得不终止了该书的翻译。当时经dreamhead介绍联系到图灵的刘江总编，希望人邮能 引进版权以促成该书的翻译，但刘总编考虑到该书是有关Haskell这门"小众"语言的，引进后受众面小，书很可能卖不出去，商业价值不高(后得知该书作 者Graham Hutton博士已经在与某出版社谈中文版版权的事宜了，并已经委托其一位同事进行中文版的翻译工作了)。不过刘总编说图灵当时已经引进了《Seven Languages in Seven Weeks》一书的中文版权，但第一译者戴玮因工作学习繁忙，可能无法按期完成全部翻译，问我是否愿意参与翻译。我的最初目标就是翻译一本英文技术书籍， 有这样的机会，而且书还可以在国内出版，于是我就欣然接下了这个翻译工作。 ...

最近针对buildc又有了一些新想法，于是今天上午又对buildc进行了多处修改，并相继发布了0.1.6版本和0.1.7版本。 * 对buildc cache upgrade的实现进行了修改。 在执行全量更新本地cache前，先对本地cache的情况进行一些检查，并判断是否与当前.buildc.rc中的配置相符。如果两者是一致的，那么只进行update操作；否则则执行真正的upgrade(remove and re-init)。 ...

这两天对buildc的改动比较频繁，今天又修正了一些问题，也增加了一些小功能。主要包括这么几点： 1、在Make.rules.in中增加了STATIC_LIBS和DYNAMIC_LIBS 项目源代码和项目中单元测试代码使用同一个Make.rules，也此编译时也就共享同一个LIBS变量。对于静态共享库还好说，但对于动态共享库，诸如Oracle的instantclient库，单元测试代码中即使没有使用到动态共享库中的接口，也要对该动态共享库产生一个依赖。这样在执行单元测试用例时就会因无法寻得动态共享库而导致用例执行失败。 为此，我在Make.rules.in中增加了STATIC_LIBS和DYNAMIC_LIBS两个变量，即将原LIBS变量中的静态共享库和动态共享库分开，分别放入STATIC_LIBS和DYNAMIC_LIBS中。然后让项目中单元测试代码的编译只依赖STATIC_LIBS，上述问题就得到了解决(如果你的单元测试真实需要链接动态共享库，那就另当别论了)。 ...

年后buildc开始逐渐在产品线的项目里应用了，随之而来的是大家反馈的各种意见和bug。尤其是bug，我都会很认真地应对，也会及时发布相应的版本修复这些bug。buildc 0.1.4版本就是一个bugfix版本，其修复的bug源于今天上午的一次持续集成的失败。 上午收到Jenkins发送的一个"build failed"的mail，一个安装包项目的CI job执行失败了，于是到Jenkins web页面上检查错误原因。这个Job会在两个slave node上执行集成，一个在x86 linux上，一个在x86 solaris上。这次失败是因为x86 linux上的一个配置问题导致的，页面显示x86 solaris那个节点的集成是成功的。我无意间查看了x86 solaris节点集成过程的命令行输出，发现如下内容： ...

印象中关于编译以及链接的问题早已是老生常谈了。但今天又遇到了一个这样的问题，这里还总想提及一下下^_^。 这次要说的问题依旧发生在使用lcut进行单元测试的过程中。一位同事在编译使用了mock函数的测试用例代码时出现了"multiple definition of ‘xxx’“的错误。这里简单模拟其场景如下： ...

lcut单元测试框架在我的项目中应用已经有一段时间了，项目组的同事对lcut的使用也是越来越熟悉，这不今天一位同事还提出了一个新需求，需求大致是这样的。 在实际项目中，经常遇到这类情况： int bar(…) { int ret; ret = foo(…); /* assert ret */ … ret = foo(…); /* assert ret */ … ret = foo(…); /* assert ret */ … } 上述代码中被测函数接口bar的实现中多次调用了某函数foo。这样当我们用mock方式测试bar这个函数时，可能需要多次重复设置foo的返回值以及输出函数的值，就像这样： ...

本文翻译自The Linux Foundation的《How to Participate in the Linux Community》(基于2012-03-21最新版本)，原作者为Jonathan Corbet(corbet@lwn.net)。 下面是该文章第七章、第八章以及第九章节的中译文。 ...