持续集成(Continuous integration，简称CI)是一种软件开发实践，即团队开发成员经常集成他们的工作，在每一天的时间中，可能会发生一次或者多次集成。而每一次的集成都是通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早的在持续集成的阶段发现软件中的错误。 持续集成给团队所带来的好处，不言而喻：
- 减少并降低软件开发中的风险：在每天一次或者多次的集成中，通过相应的测试，能尽早的发现软件中的缺陷，尽量把软件中的错误暴露在开发阶段。最常见的场景，就是在多人的团队中，别人改动相关代码影响了你的代码逻辑，但他们不知道你写过这些单元测试或者没有跑单元测试的习惯，而持续集成能帮助解决这样的问题。
- 减少重复而又枯燥的单元测试过程：代码的改动不能避免的就是需要重复并且不断回归的运行之前写好的单元测试，而这一过程往往让工程师头疼，因为编译代码，准备测试数据，运行测试并查看结果，完全是重复的体力劳动。通过自动化的持续集成，不需要人工干预，完全可以把工程师从痛苦的循环中拯救出来，降低心智负担，让工程师能够把精力放在具有更高价值的事情上。
- 随时生成可运行和部署的软件：利用持续集成的特性，我们随时可以得到可以运行和部署的软件，对于客户来说，可以部署的软件产品是最实际的资产。而对于团队成员来说，也能让他们更有信心，因为他们清楚的知道每一次构建的结果，他们知道他们对软件的改动造成了哪些影响，结果怎么样。
上面提到了持续集成的各种好处，其实，持续集成的好处还不止如此。在GitLab中，不仅仅提供了代码托管的功能，而内置的持续集成功能，也是它功能上的一大亮点。从GitLab 8.0以上的版本，就提供了GitLab CI的功能。从官网的介绍可以了解到，GitLab CI拥有许多不错的特性，其中比较惹眼的几点，包括：
- 多平台支持：很巧的是，GitLab CI的Runner是由Go所开发的，这意味着在众多支持Go的平台上，都可以运行构建，甚至是树莓派上哦！
- 多语言支持：编译脚本是基于命令行驱动的，支持Java, PHP, Ruby, C及其他语言。
- 并行构建支持：GitLab CI会把多个同时出发的构建分派到不同机器上，以实现更快的并行执行。
- 自动伸缩：在保证最小化成本的基础上，自动启动与关闭虚拟机来进行构建。
关于GitLab CI的特性还有很多，可以查看官方文档了解更多特性。
GitLab CI的大致架构，如下图：
主要分为GitLab CI和GitLab Runner两个部分。GitLab CI部分，实际上已经集成到GitLab的Web中，主要负责提供友好的界面，供用户管理项目与构建。而GitLab Runner，主要负责生成构建与运行单元测试以及完成其他后续的持续集成任务。GitLab Runner主要通过API与Web端的GitLab CI进行交互。为了实现持续集成，我们可以选用的最小化配置是一个GitLab CI实例与一个GitLab Runner。当然，如果要提高构建的效率，我们可以在条件允许的情况下，部署任意多个GitLab Runner。
使用GitLab CI的功能，首先需要安装GitLab Runner。官方不推荐在同一台服务器上既运行GitLab，又跑GitLab Runner，因此，建议搭建单独的服务器用以运行GitLab Runner。这次实验中，用到了另外一台在Azure印尼机房的Linux服务器来安装GitLab Runner。在Linux的服务器上安装GitLab Runner，过程是比较简单的：
首先，需要添加GitLab的官方源到apt或者yum中：
1 | # For Debian/Ubuntu |
完成过后，就可以直接用apt或者yum来安装了：
1 | # For Debian/Ubuntu |
安装过后，就是注册的过程。注册的过程，实际上就是把某台服务器上的GitLab Runner跟GitLab的Web关联起来。在GitLab中，runner分为两种类型：Shared Runner（共享型）和Specific Runner（指定型）
- Shared Runner: 这类Runner是全局的，意思是为整个GitLab系统范围内的project提供构建服务，只有系统管理员能创建这类Runner。
- Specific Runner: 这类Runner是被指定为某个project提供构建服务的，这意味着系统中的任何用户，都可以建立自己的Runner，并把它指派给自己的某一个project。
在注册Runner的时候，需要填入Token，GitLab根据不同的Token确定这个Runner是被设置为Shared Runner还是Specific Runner。
在这里，我们注册一个共享类型的Runner。首先，需要在GitLab的管理后台，拿到Runner的Token，然后开始注册。注册过程如下：
1 | sudo gitlab-ci-multi-runner register |
在这里，为了自动化构建Go相关的项目，我们采用docker作为Runner运行的方式，并选择golang:1.6.2的docker镜像。注册成功之后，会提示可以启动Runner了。另外，顺便提一下更新Runner的方法：
1 | # For Debian/Ubuntu |
注册成功之后，我们便能在GitLab的管理后台中看到这个Shared Runner：
接下来的过程，就是在项目中创建.gitlab-ci.yml配置文件，这个文件的意义在于告诉CI在构建的过程中应该做哪些事情，比如如何初始化环境，如何运行我们的test case。这个文件需要签入到我们工程的源代码中，并随项目的源文件一同提交。更加详细的配置项目，可以参考这里。
最后一步，就是给我们的Go工程编写test case并commit，之后push给GitLab，在检测到push的改动之后，会主动触发Shared Runner的运行和构建的动作。成功运行之后，我们能在Runner的运行情况中查看到结果：
构建情况总览： 
还可以通过点击，查看某个构建的具体情况： 
对于成功编译和构建的项目，我们还可以为这个项目打上徽标。徽标能让团队的其他成员更加直观的了解最近的一次自动构建的结果。徽标的访问URL大致如下，根据自己域名和项目名称的不同，稍有变化： http://example.gitlab.com/namespace/project/badges/branch/build.svg
通过设置，我们已经开启了GitLab CI的自动构建之旅，并配置了一个简单的Shared Runner，一切看来都非常简单。在实际的需求中，我们甚至可以根据团队的需求，配置多个Shared Runner，并为特殊的project设置指定的Runner。这样能大大节省构建的时间，提升GitLab CI的效率。
GitLab是一个贴心的开发者伙伴，内置集成的GitLab CI提供更为贴心的持续集成功能，Runner中搭配Docker更有锦上添花的感觉，最关键的是我们能以正确的姿势去使用它们，从而为团队带来最大化的收益，提升软件质量和开发效率。
最近闲下心来，重新折腾了一下GitLab，相比起一两年前折腾起GitLab的痛苦经历，各种Ruby环境配置以及依赖包的问题，搞得人一心想放弃。如今，GitLab的安装包安装起来真是方便多了，使用官方提供的Omnibus package，可以在两三分钟的时间搭好GitLab，可以看到GitLab作为一个开源产品，是一直在不断进步的。
Go中的range关键字使用起来非常的方便，它允许你遍历某个slice或者map，并通过两个参数(index和value)，分别获取到slice或者map中某个元素所在的index以及其值。
从2013年入手HHKB Pro2至今，使用了接近3年时间的HHKB，也写了一篇跟HHKB相关的开箱文《码农神器HHKB Pro2入手与开箱》，引来无数同学围观，也让不少同学中毒不浅……
从HHKB的长时间使用体验来看，HHKB确实是一款相当不错的键盘，尤其是Unix方式的键帽布局，特别适合在Unix/Linux/Mac OS系统下使用，Control键和Esc键的位置，也特别能俘获Vimer的芳心。
经常还有同学问HHKB能否在Windows下使用，答案是：不建议。考虑到Windows下对F1-F12功能键，以及方向键的重度依赖，HHKB用起来会比较别扭，因为只能靠组合键来实现。所以想在Windows下体验静电容键盘的同学，还是建议入RealForce了。
Blog又半年没更新了，荒草丛生，这半年中，blog连续搬了几个地方，从最早的DigitalOcean，搬到了OneAsiaHost，原因是因为DigitalOcean最近也比较卡。DigitalOcean我一直选的SFO机房，不过也是遇到线路抽风，ping从来没下过300ms，SSH过去也卡卡的，遂放弃之。
2013年的时候，接触到了Octopress，被静态生成博客的特性给深深吸引住了，于是，把Blog从WordPress转移到了Octopress。一直到现在，用了接近两年的时间，整体给我的感觉，就是静态博客管理起来特别方便，因为不用考虑搭建数据库，也不用担心备份的问题，所有的文章都用Git进行版本控制，然后直接推送到bitbucket或者github，让人很舒心。另外，直接用markdown写作也是现在流行的趋势。
我人生中的第一台PC机，是初中毕业的时候购入的，由于是人生中第一台电脑，我还清晰的记得当时机器的配置：
- CPU: Intel Pentium II Processor 233MHz with MMX
- 硬盘: 昆腾 BigFoot 4.3GB
- 内存: 32MB (是的,你没看错,就是32MB)
- 显卡: Trident 9750 3D Image
- 光驱: Philips 16X
- 显示器: Philips 15寸
记得买机器的时候正值98年，也正是用电脑看VCD比较流行的时候，当时超级解霸成为电脑必装软件之一。这台机器作为当时比较不错的配置，花了大概8300RMB。这台能够玩很多的游戏，比如：Quake2，古墓丽影，极品飞车，世界杯足球98，仙剑奇侠传……
我也还记得，每当小伙伴来围观这台新电脑的时候，发出的惊叹：哇，硬盘4.3G这么大，我家的才600多MB…
缘于对机械键盘的喜爱，我经常在blog上写一些机械键盘的开箱和评测的文章，供喜爱机械键盘的爱好者作对比和参考。结果让我没料到的是，这几篇机械键盘的评测文章在搜索引擎排名比较靠前，以至于在我查看blog每天的访问流量统计数据的时候，大部分的来自搜索引擎的流量，都是指向这几篇键盘的评测文章。这是让我一直比较困惑的一个问题……其实，我的blog本来是个编程技术相关的blog，没想到反倒是几篇开箱文流量最高 -_-# 嗯，其实这是一个不务正业的技术blog……
Revel是一个高生产力的Go语言Web框架，原型是由Java的Play! Framework演变而来。其实除了Revel之外，Go语言的Web框架已经有很多了，这里就不再一一列举。就Revel框架本身而言，已经具备和提供了一些非常不错的特性，比如支持运行时的代码热编译(Hot Code Reload)，提供诸多的组件，包括：路由, 参数解析, 验证, session/flash, 模板, 缓存, 计划任务, 测试, 国际化等功能。
虽然目前Revel正式release的版本还只是v0.12.0版本(2015-03-25 - Daffodil release)，不过此框架已经有被应用到生产环境中的实际案例，并且并发性能良好。因此，Revel也成为我们最近一个项目的首选框架。