Opensource

近期收到客户一个需求，我将该需求转述为下面这个等价的问题。 【问题】 * 有一个产品包装系统_S_，为某种产品_P_提供产品包装服务; * 系统_S_由若干个处理节点组成，每个节点都可以单独处理组件; ...

有一段时间，我完全沉迷于在脑海中想象机械绘图和设计新机型所带来的极致享受，这是我一生中有过的最完美的精神愉悦。创造的灵感像泉水般源 源不断 地涌出，我遇到的唯一困难就是必须设法牢牢抓住它们。对我来说，构思中的设备零件都绝对是真实的，所有细节都触手可及，甚至最细微的标识和磨损状态也是如 此。想象发动机在持续不断地运转，仿佛一道迷人的风景呈现在面前，令我欣喜若狂。 — 尼古拉. 特斯拉 ...

我们产品中的一个子模块在进行Oracle实时数据库查询时，常常因数据库性能波动或异常而被阻塞在OCI API的调用上，为此我们付出了“惨痛”的代价。说来说去还是我们的程序设计的不够完善，在此类阻塞型函数调用方面缺少微小粒度的超时机制。 ...

本文翻译自Dr. Dobb’s杂志主编Andrew Binstock的"Putting Absolutely Everything in Version Control“一文。 持续交付(Continuous Delivery)的一个关键原则就是将所有东西都放入版本控制系统中。这解决了一些重大问题，但也引入了一些其他问题。 ...

很多时候，一旦习惯了某些事情，也就习惯了它们的恶劣，习惯了它们的丑陋，习惯了它们“赋予”你的各种痛苦。 – Tony Bai 一、痼疾难解 曾几何时，在那个还没有集群化，没有分布式的时代，它还是一个不错的方案，至少在线上没有暴露出太多问题，它也不在我们关注的重点范围之内。但随 着集群化、分布式的新版本的到来，那一大坨遗留的代码就变得格外让人不顺眼，同时问题也随之在线上暴露开来了。 ...

随着buildc在内部应用的深入，buildc逐渐进入了以内部需求和问题为主要驱动力的演化模式。我们内部的C应用多是后端服务类应用，个人 觉得具有一定代表性。buildc最初就是为了针对这类C应用而设计的。因此我们内部的需求和问题应该也同样具有一定代表性，而这种演化模式在一 段时间范围内还是有意义的。 buildc 0.3.1版本修正了上一版本的若干bug，并增加了两个新功能。 * 提高容错能力 ...

我在日常工作中使用C语言中的位域(bit field)的场景甚少，原因大致有二： * 一直从事于服务器后端应用的开发，现在的服务器的内存容量已经达到了数十G的水平，我们一般不需要为节省几个字节而使用内存布局更加紧凑的位域。 * 结构体中位域的实现是平台相关或Compiler相关的，移植性较差，我们不会贸然地给自己造“坑”的。 ...

自buildc正式在项目中应用以来，我们收到了许多同事针对buildc演进的意见和建议。其中确实有些易用性的问题是在最初设计时未考虑周全的，尤其是.buildc.rc中的配置，同事们对该文件的配置已经“怨声载道”了。 .buildc.rc是用来配置某开发者在开发过程中使用的第三方库所在subversion repository信息的，例如： a_repository = (‘SVN库地址’, ‘本地缓存路径’, [ # 格式：[(“第三方库名称”, “库版本”, “特征库文件”), …] (’libevent’, ‘2.0.10’, ’lib/libevent.a’), (‘instantclient’, ‘10.2.0.5.0’, ’lib/libnnz10.so’), … ] ) b_repository = (‘SVN库地址’, ‘本地缓存路径’, []) c_repository = (‘SVN库地址’, ‘本地缓存路径’, []) … external_repositories = [ a_repository, b_repository, c_repository, … ] ...

在版本控制工具大行其道的今天，作为程序员，势必要每天与各种版本控制系统（比如Subversion、Git、Mercurial等）打交道， 每天不commit几次代码都不好意思说自己是专业程序员^_^。不过commit代码可不止敲入commit命令这么简单，对于一个专业程序员 来说，我们还要关注每次commit所携带的背景信息，这里暂且称之为“commit context”。在每次commit时，这些上下文信息只能通过commit log来体现。 ...

俄罗斯OOO Program Verification Systems公司用自己的静态源码分析产品PVS-Studio对一些知名的C/C++开源项目，诸如Apache Http Server、Chromium、Clang、CMake、MySQL等的源码进行了分析，找出了100个典型的Bugs。个人觉得这份列表对C/C++ 程序员有一定参考意义。与其说事后用静态工具分析，倒不如在编码时就提高自知自觉，避免这份列表上的错误发生在你的代码中，因此这里将部分摘录一些Bugs（Bug编号这里不连续，为的是对应原文的编号）并做简要说明。原文将这份Bug列表分为了几类，这里也将沿用这个思路。 ...