C

int uint int8 uint8 = byte int16 uint16 int32 uint32 float32 complex64 int64 uint64 float64 complex128 还有uintptr，一个大小足够存储一个指针的数值。 这些都是互不相同的类型；int不等于是int32，即便是在一个32位的机器上。 ...

Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It’s a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. – 摘自Go语言官方站点 ...

本文翻译自Dr.Dobb’s的"Getting Going with Go"。 本文是有关Google新的系统原生语言的五周教程的第一部分，这里将先向大家展示如何建立Go语言开发环境以及构建程序，然后带领大家浏览 一些代码范例来着重了解一下这门语言的一些有趣的特性。 ...

本文翻译自 Dr. Dobb’s主编Andrew Binstock的文章"Why Not Go?"。 Go是一种对系统原生语言的重要反思，它对C语言做了重大的改善，同时还保持了语言的极简性。 今年早些时候，我们写了一篇有关新兴系统原生(native)语言的文章。这些语言包括D、Go、Rust以及Vala。当时我们承诺将会对这些语言进行 细致的探索。从本周开始，我们将开启一系列对来自Google的新语言Go的探索之旅，该系列共有五部分。不同于以往Dr.Dobb’s的教程系列，我们 会在连续的几周内发表这些文章，这样你就可以及时且更快的了解到这门语言了。 ...

最近闲暇时间在策划实施两件事儿：一是产品的自动化回归测试；二是尝试在项目中使用一些静态代码语义分析工具。我觉得这两件事是应该做的正确的事，对提升产品质量，提前发现产品中潜在的缺陷都大有裨益。但在做的过程中才感觉到：现在做有些晚，正确的事要趁早做。 去年自动化测试组发布了自动化测试框架的第一个版本，我们的产品参加了试点。但经过自动化测试组大半年的投入，效果十分有限，根本没有达到我的预期。最主 要的问题是使用他们提供的框架编写和维护test case都十分困难，工作量投入很大，这很打击大家的积极性。今年大家决定将自动化测试框架换成nokia开源的robotframework。经过预 研，robotframework完全可以满足我们的测试需求，并且robotframework的用例编写和维护效率太高了，编写门槛却很低。 ...

随着buildc使用的深入，越来越多的新需求暴露了出来。为了满足这些需求，我们组的小兄弟又对buildc进行了一些改造，这些变化如下： 1、支持将多个子工程打包到一个安装包中 最初buildc的设计思想是为每个子工程单独制作安装包，这样具有很强的灵活性。但在对现有N个工程进行构建脚本改造的过程中发现，有些工程间存在严重 依赖，比如工程A是一个业务级公共库工程，工程B和工程C都依赖工程A构建后生成的静态共享库。而工程A又无法被当成第三方库处理，这给我们的安装包构建 制造了难题。我们的解决方法就是改造安装包工程的setup.cfg文件，让其支持多source。从正规语义上来讲，我们这么做将使得buildc支持 将多个子工程打包到一个安装包中，而间接的作用则是解决了上述有依赖关系的工程安装包制作的问题，虽然看起来不那么美。 ...

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

最近针对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节点集成过程的命令行输出，发现如下内容： ...