2016已完，2017待续……年底特别忙，以至于到了最后一天，才想起来应该来写点什么，算作是对2016年的总结。关于工作从2015年初离开Moto以来，中途短暂的经历了一家公司。说短暂是真的，两个月的试用期还没到，打算以合伙人的身份加入一家创业公司。尽管前公司的老大极力的挽留，还让我提前转正，我还是离开了，总觉得没有创业经历的人生不算完整。跟大多数九死一生的创业公司一样，于是，从2015年3月，到2016年5月底，亲自见证了一家创业公司从起步，到衰败的过程。短暂的一年多时间里面，也算是体验了创业的艰辛和套路，个中滋味，也许只有自己才知道了。然而，我并不后悔，只是感觉人生经历又丰富了那么一点点，还顺带认识了几个合作得很愉快的同事。还依稀记得5.31日，团队宣布解散的那一天，同事们一一告别，我提议大家都一起合影留念:现在，我又加入了一家新的公司，只是不再以合伙人的身份。关于技术自从加入创业公司以来，就从.Net开发转向了全职Go开发，这也是之前我一直所希望的，尽管Go的职位在成都并不多(拉钩上面搜成都Go的相关职位，少得可怜)，我还是决定用Go来实现创业公司项目后端的所有业务，Go的简洁一直是我所喜欢的，配合Docker容器化部署，是相当方便的。也许2017我会继续关注容器化与微服务架构这一方面。关于blog上次blog搬家到Vultr后，用了一段时间感觉还不错，后来赶上国际版阿里云的 ...继续阅读 (53)

2016已完，2017待续……年底特别忙，以至于到了最后一天，才想起来应该来写点什么，算作是对2016年的总结。关于工作从2015年初离开Moto以来，中途短暂的经历了一家公司。说短暂是真的，两个月的试用期还没到，打算以合伙人的身份加入一家创业公司。尽管前公司的老大极力的挽留，还让我提前转正，我还是离开了，总觉得没有创业经历的人生不算完整。跟大多数九死一生的创业公司一样，于是，从2015年3月，到2016年5月底，亲自见证了一家创业公司从起步，到衰败的过程。短暂的一年多时间里面，也算是体验了创业的艰辛和套路，个中滋味，也许只有自己才知道了。然而，我并不后悔，只是感觉人生经历又丰富了那么一点点，还顺带认识了几个合作得很愉快的同事。还依稀记得5.31日，团队宣布解散的那一天，同事们一一告别，我提议大家都一起合影留念:现在，我又加入了一家新的公司，只是不再以合伙人的身份。关于技术自从加入创业公司以来，就从.Net开发转向了全职Go开发，这也是之前我一直所希望的，尽管Go的职位在成都并不多(拉钩上面搜成都Go的相关职位，少得可怜)，我还是决定用Go来实现创业公司项目后端的所有业务，Go的简洁一直是我所喜欢的，配合Docker容器化部署，是相当方便的。也许2017我会继续关注容器化与微服务架构这一方面。关于blog上次blog搬家到Vultr后，用了一段时间感觉还不错，后来赶上国际版阿里云的 ...继续阅读 (64)

我的Blog是基于hexo生成的纯静态页面，host在nginx server上。其实通过普通的http访问方式已经足够了，开启https纯属折腾，请叫我不折腾不舒服斯基。提到https，不得不提到免费的StarSSL证书，之前也申请了用过一段时间，感觉申请和续期证书的步骤都比较繁琐。后来随着证书过期，遂放弃之……最近，在网上火透半边天的，非Let’s Encrypt的免费SSL证书莫属了。Let’s Encrypt 是一个将于2015年末推出的数字证书认证机构，将通过旨在消除当前手动创建和安装证书的复杂过程的自动化流程，为安全网站提供免费的SSL/TLS证书，同时，它还是免费、自动化、开放的证书签发服务。Let’s Encrypt的证书申请和续期都非常方便，默认的证书有效期是90天，通过cron的定时任务可以实现自动化的续期，所以，能通过自动的方式解决的问题都不是问题，这也是这次折腾起https支持的原因。此篇blog主要记录一下申请证书，配置证书到nginx，以及自动续期的实现步骤，供有兴趣的同学参考。第一步 获取CertbotCertbot 是一个简单易用的 SSL 证书部署工具，由 EFF 开发，前身即 Let’s Encrypt 官方（Python）客户端。简单来说，certbot 就是一个简化 Let’s Encrypt 部署，和管理 Let’s Encrypt 证书的 ...继续阅读 (61)

我的Blog是基于hexo生成的纯静态页面，host在nginx server上。其实通过普通的http访问方式已经足够了，开启https纯属折腾，请叫我不折腾不舒服斯基。提到https，不得不提到免费的StarSSL证书，之前也申请了用过一段时间，感觉申请和续期证书的步骤都比较繁琐。后来随着证书过期，遂放弃之……最近，在网上火透半边天的，非Let’s Encrypt的免费SSL证书莫属了。Let’s Encrypt 是一个将于2015年末推出的数字证书认证机构，将通过旨在消除当前手动创建和安装证书的复杂过程的自动化流程，为安全网站提供免费的SSL/TLS证书，同时，它还是免费、自动化、开放的证书签发服务。Let’s Encrypt的证书申请和续期都非常方便，默认的证书有效期是90天，通过cron的定时任务可以实现自动化的续期，所以，能通过自动的方式解决的问题都不是问题，这也是这次折腾起https支持的原因。此篇blog主要记录一下申请证书，配置证书到nginx，以及自动续期的实现步骤，供有兴趣的同学参考。第一步 获取CertbotCertbot 是一个简单易用的 SSL 证书部署工具，由 EFF 开发，前身即 Let’s Encrypt 官方（Python）客户端。简单来说，certbot 就是一个简化 Let’s Encrypt 部署，和管理 Let’s Encrypt 证书的 ...继续阅读 (58)

回想上一次的Blog更新，已经是去年9月份的事了，时间过得很快，2014还未来得及回味，2015已经匆匆而至。哥在去年学Go的时候，就有了一个计划，准备把之前那个用Rails实现的Vim-Tips.com改版，并重新用Go实现一遍。其实，这已经不是Vim-Tips.com历史上的第一次改版了，下面是之前的几次更新记录：新站VimTips上线VimTips改版Vim-Tips.com数据库迁移记这次由于全部用Go重写了，所以称之为“第二版”…大致在去年六月底，我就开始了这样的尝试，并在Github上建立了仓库，开始搭建网站的框架。直到最近，终于算把Vim-Tips.com的第二版用Go给重写了，其实工作量算不上很大，因为工作繁忙的缘故，重写的中途暂停拖延了好几次，再加上时不时的拖延症复发，重写整站竟然跨了小半年的时间。不过回味一下重写的整个过程，还是挺有乐趣的，一边想着各种功能的实现，遇到问题一边google一边寻找解决办法，也算是对自己技能的一次提升吧。第二版的站点，用Go的Martini框架实现，后台数据库依旧是MongoDB，Go有一个很有名的第三方模块：mgo，提供对MongoDB的访问支持。重写后对比了一下新站和旧站的UI，突然感觉之前旧站看起来还是简单粗陋了一点。截图两张，纪念一下旧站点：新站点的配色，是从“别人家的网站”找了一套设计师推荐的搭配颜色。这次重写包括了网站的 ...继续阅读 (63)

自从哥把blog从WordPress迁移到了Octopress，整个blog页面都是生成的静态页面了，这样省去了动态渲染的过程，能让blog访问速度提高不少。Blog现在放在DigitalOcean的旧金山机房 (参见)，国内访问速度还算可以。不过，作为一个喜欢折腾的大叔，总想对blog的访问速度再进行一次优化。之前考虑过CloudFlare作为CDN加速，由于某种原因，国内访问CloudFlare似乎效果不太理想，遂放弃。后来，终于找到了一种可行的方案，就是利用Gitcafe的Pages功能。了解Github的同学，或许都有过用Github的Pages功能搭建blog的经历。Gitcafe的Pages功能跟Github的类似，设置起来也非常方便，并且支持绑定自定义域名，这是很关键的一点。具体设置，建议google一下。如何用Gitcafe来针对国内访问的请求加速blog访问呢？大致的设想是这样：国内的请求，分流去访问Gitcafe上的blog页面，其他的请求，去访问DigitalOcean上的blog页面。实现这样的功能并不难，因为DNSPod有一个叫做“智能解析”的功能，如下图：设置好智能解析规则，默认请求解析到DigitalOcean去，对于电信、联通、教育网的请求，解析到国内的Gitcafe上去。这样能实现一些智能解析和分流了。解析生效后，用国内IP和国外IP分别ping ...继续阅读 (57)

2013年的时候，接触到了Octopress，被静态生成博客的特性给深深吸引住了，于是，把Blog从WordPress转移到了Octopress。一直到现在，用了接近两年的时间，整体给我的感觉，就是静态博客管理起来特别方便，因为不用考虑搭建数据库，也不用担心备份的问题，所有的文章都用Git进行版本控制，然后直接推送到bitbucket或者github，让人很舒心。另外，直接用markdown写作也是现在流行的趋势。不过，由于我的Blog文章数量不少，大概有400多篇，每次发布重新生成整个静态站点会占用比较长的时间，这是因为Jekyll的慢造成的。还有个原因，Octopress是Ruby开发的，不得不在本机搭建和维护一个Ruby环境，MacOS和Linux还相对好一些，在Windows下搭建ruby环境会比较折腾，估计还会遇到一些莫名其妙的错误，建议还是别在Windows下折腾Ruby环境。基于上面的几点原因，我思索着替换一个博客引擎的解决方法，主要的要求，还是希望生成全静态内容的博客，另外，也是用markdown来书写。之前考虑过的两个方案：HexoHugoHexo是基于Node.js的静态博客引擎，Hugo是基于Go语言的。Hugo相比Node.js安装起来更方便一些，因为根据Go语言的特性，Hugo程序只要第一次安装编译过后，就可以直接运行了，无需其他环境，而Hexo需要安装n ...继续阅读 (63)

Blog又半年没更新了，荒草丛生，这半年中，blog连续搬了几个地方，从最早的DigitalOcean，搬到了OneAsiaHost，原因是因为DigitalOcean最近也比较卡。DigitalOcean我一直选的SFO机房，不过也是遇到线路抽风，ping从来没下过300ms，SSH过去也卡卡的，遂放弃之。说起OneAsiaHost，这个服务商在新加坡，ping值还不错，而且线路据说是跟大陆直连，进行过优化。用了一段时间还算不错，可惜遇到一段时间白天线路老是抽风，后来忍无可忍，搬去了Linode东京机房。本以为Linode东京机房的速度会很快(其实开始一段时间还确实不错的)，因为物理上的距离算比较近的了，Linode的东京机房，除了晚上会有些小卡，到前一段时间丢包严重，没法正常SSH登录了，看来国内的站长一窝蜂打挤的地方不宜久留啊……再后来，索性逃离了东京机房，回归了美帝的LA机房，选了最近口碑一直不错的RamNode，用了几天还算满意，虽然ping值没法跟东京机房比，线路还算稳定。不过，最近几天又突然发觉在晚上的时候，也有丢包严重的现象。开始以为是电信光纤的问题，后来连到其他的VPS去ping和SSH测试，发现并不是这样。好吧，继续搬家，这一次搬到了现在的blog所在地：Vultr。Vultr，其实去年就注册了他家的帐号，还充值送了一些钱，剩下30刀一直没用。之前尝试过他家的日 ...继续阅读 (56)

序从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了。HHKB其实已经不算是一个比较”新”的产品了，如果去维基百科追溯它的产品历史的话，要从1996年的第一代HHKB说起了。现今主要被爱好者们竞相购买的两个版本分别为：HHKB Professional 2 - 2006年03月24日开始销售HHKB Professional Type-S - 2011年06月29日开始销售(注: Lite2由于不属于静电容的范畴，故不在此介绍了)Type-S号称是Pro2的静音版本，也是HHKB系列中的旗舰产品，从上面可以看出Type-S的面世大概比Pro2晚了5年左右。既然是旗舰产品，从价位上也能 ...继续阅读 (55)

序从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了。HHKB其实已经不算是一个比较”新”的产品了，如果去维基百科追溯它的产品历史的话，要从1996年的第一代HHKB说起了。现今主要被爱好者们竞相购买的两个版本分别为：HHKB Professional 2 - 2006年03月24日开始销售HHKB Professional Type-S - 2011年06月29日开始销售(注: Lite2由于不属于静电容的范畴，故不在此介绍了)Type-S号称是Pro2的静音版本，也是HHKB系列中的旗舰产品，从上面可以看出Type-S的面世大概比Pro2晚了5年左右。既然是旗舰产品，从价位上也能 ...继续阅读 (58)

Blog又半年没更新了，荒草丛生，这半年中，blog连续搬了几个地方，从最早的DigitalOcean，搬到了OneAsiaHost，原因是因为DigitalOcean最近也比较卡。DigitalOcean我一直选的SFO机房，不过也是遇到线路抽风，ping从来没下过300ms，SSH过去也卡卡的，遂放弃之。说起OneAsiaHost，这个服务商在新加坡，ping值还不错，而且线路据说是跟大陆直连，进行过优化。用了一段时间还算不错，可惜遇到一段时间白天线路老是抽风，后来忍无可忍，搬去了Linode东京机房。本以为Linode东京机房的速度会很快(其实开始一段时间还确实不错的)，因为物理上的距离算比较近的了，Linode的东京机房，除了晚上会有些小卡，到前一段时间丢包严重，没法正常SSH登录了，看来国内的站长一窝蜂打挤的地方不宜久留啊……再后来，索性逃离了东京机房，回归了美帝的LA机房，选了最近口碑一直不错的RamNode，用了几天还算满意，虽然ping值没法跟东京机房比，线路还算稳定。不过，最近几天又突然发觉在晚上的时候，也有丢包严重的现象。开始以为是电信光纤的问题，后来连到其他的VPS去ping和SSH测试，发现并不是这样。好吧，继续搬家，这一次搬到了现在的blog所在地：Vultr。Vultr，其实去年就注册了他家的帐号，还充值送了一些钱，剩下30刀一直没用。之前尝试过他家的日 ...继续阅读 (50)

2013年的时候，接触到了Octopress，被静态生成博客的特性给深深吸引住了，于是，把Blog从WordPress转移到了Octopress。一直到现在，用了接近两年的时间，整体给我的感觉，就是静态博客管理起来特别方便，因为不用考虑搭建数据库，也不用担心备份的问题，所有的文章都用Git进行版本控制，然后直接推送到bitbucket或者github，让人很舒心。另外，直接用markdown写作也是现在流行的趋势。不过，由于我的Blog文章数量不少，大概有400多篇，每次发布重新生成整个静态站点会占用比较长的时间，这是因为Jekyll的慢造成的。还有个原因，Octopress是Ruby开发的，不得不在本机搭建和维护一个Ruby环境，MacOS和Linux还相对好一些，在Windows下搭建ruby环境会比较折腾，估计还会遇到一些莫名其妙的错误，建议还是别在Windows下折腾Ruby环境。基于上面的几点原因，我思索着替换一个博客引擎的解决方法，主要的要求，还是希望生成全静态内容的博客，另外，也是用markdown来书写。之前考虑过的两个方案：HexoHugoHexo是基于Node.js的静态博客引擎，Hugo是基于Go语言的。Hugo相比Node.js安装起来更方便一些，因为根据Go语言的特性，Hugo程序只要第一次安装编译过后，就可以直接运行了，无需其他环境，而Hexo需要安装n ...继续阅读 (56)

回想上一次的Blog更新，已经是去年9月份的事了，时间过得很快，2014还未来得及回味，2015已经匆匆而至。哥在去年学Go的时候，就有了一个计划，准备把之前那个用Rails实现的Vim-Tips.com改版，并重新用Go实现一遍。其实，这已经不是Vim-Tips.com历史上的第一次改版了，下面是之前的几次更新记录：新站VimTips上线VimTips改版Vim-Tips.com数据库迁移记这次由于全部用Go重写了，所以称之为“第二版”…大致在去年六月底，我就开始了这样的尝试，并在Github上建立了仓库，开始搭建网站的框架。直到最近，终于算把Vim-Tips.com的第二版用Go给重写了，其实工作量算不上很大，因为工作繁忙的缘故，重写的中途暂停拖延了好几次，再加上时不时的拖延症复发，重写整站竟然跨了小半年的时间。不过回味一下重写的整个过程，还是挺有乐趣的，一边想着各种功能的实现，遇到问题一边google一边寻找解决办法，也算是对自己技能的一次提升吧。第二版的站点，用Go的Martini框架实现，后台数据库依旧是MongoDB，Go有一个很有名的第三方模块：mgo，提供对MongoDB的访问支持。重写后对比了一下新站和旧站的UI，突然感觉之前旧站看起来还是简单粗陋了一点。截图两张，纪念一下旧站点：新站点的配色，是从“别人家的网站”找了一套设计师推荐的搭配颜色。这次重写包括了网站的 ...继续阅读 (60)

自从哥把blog从WordPress迁移到了Octopress，整个blog页面都是生成的静态页面了，这样省去了动态渲染的过程，能让blog访问速度提高不少。Blog现在放在DigitalOcean的旧金山机房 (参见)，国内访问速度还算可以。不过，作为一个喜欢折腾的大叔，总想对blog的访问速度再进行一次优化。之前考虑过CloudFlare作为CDN加速，由于某种原因，国内访问CloudFlare似乎效果不太理想，遂放弃。后来，终于找到了一种可行的方案，就是利用Gitcafe的Pages功能。了解Github的同学，或许都有过用Github的Pages功能搭建blog的经历。Gitcafe的Pages功能跟Github的类似，设置起来也非常方便，并且支持绑定自定义域名，这是很关键的一点。具体设置，建议google一下。如何用Gitcafe来针对国内访问的请求加速blog访问呢？大致的设想是这样：国内的请求，分流去访问Gitcafe上的blog页面，其他的请求，去访问DigitalOcean上的blog页面。实现这样的功能并不难，因为DNSPod有一个叫做“智能解析”的功能，如下图：设置好智能解析规则，默认请求解析到DigitalOcean去，对于电信、联通、教育网的请求，解析到国内的Gitcafe上去。这样能实现一些智能解析和分流了。解析生效后，用国内IP和国外IP分别ping ...继续阅读 (58)

从去年开始，我就把blog搬家到了DigitalOcean，DigitalOcean的VPS用起来还算不错，而且一直稳定在线半年多了，都没有重启过。直到前一段时间，Linode发来了一封信，免费送了50刀，我才又用起了Linode。今天去V2EX，看到Linode刚刚推出了10刀的套餐，套餐的大致配置如下：1CPU1G内存24G SSD硬盘2TB的流量125Mbit的出口带宽相比一直以来每月20刀的最低套餐，这个套餐总算把性价比又推进了一步。或许是因为DigitalOcean和VULTR这两家VPS最近太过于火爆，让Linode流失了一些客户，也让Linode感受到了压力，于是不得不推出更具竞争力的套餐。话说使用过三年多的Linode，总体让我对Linode还是非常满意的，我转用DigitalOcean的唯一原因就是Linode的价格不太便宜。如果以后Linode能像DigitalOcean和VULTR一样，推出5刀每月的套餐，估计会让这场抢夺客户的战争来得更猛烈一些… ...继续阅读 (59)

我人生中的第一台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…后来高中毕业的暑假，又升级过一次机器，虽然配置强劲了许多，不过印象已经有些模糊了。第三台机器，是陪伴我整个大学，一直到现在的PC机，由于平时习惯了用笔记本电脑，这台机器其实已经在毕业过后闲置吃灰很多年了。这台机器，在现在看来，已经是古董得不能再古董的机器了：CPU: AMD Athlon 1700+硬盘: 希捷80GB内存: 1.5GB (最初是256MB，升级过后到了1.5GB)显卡: Geforce 2 (后来升级到了3还是4，忘了)光驱: 三 ...继续阅读 (72)

缘于对机械键盘的喜爱，我经常在blog上写一些机械键盘的开箱和评测的文章，供喜爱机械键盘的爱好者作对比和参考。结果让我没料到的是，这几篇机械键盘的评测文章在搜索引擎排名比较靠前，以至于在我查看blog每天的访问流量统计数据的时候，大部分的来自搜索引擎的流量，都是指向这几篇键盘的评测文章。这是让我一直比较困惑的一个问题……其实，我的blog本来是个编程技术相关的blog，没想到反倒是几篇开箱文流量最高 -_-# 嗯，其实这是一个不务正业的技术blog……言归正传，或许是这几篇开箱评测文，吸引到了比特新声的主播，于是我也有幸受邀成为嘉宾，跟主播郝海龙一起，录制了一期跟键盘有关的播客。关于播客，对我来说并不陌生，从最早的在iTunes上的订阅，到后来去荔枝FM上订阅各种感兴趣的播客。只是之前还从来没有亲自参加过录制，这也算是人生的第一次了。播客的录制时间，约定在五一假期前的那天晚上。那天，成都竟然莫名的下起了倾盆大雨，还伴随着阵阵雷声。之前没有任何的准备，所以出门上班的时候也没有带伞，于是回家的时候被淋成了落汤鸡，还好赶上了录制的时间。整个播客是用远程Skype的方式录制，跟主播聊起了键盘的方方面面，话题也不仅仅限于机械键盘，还包括程序员使用的静电容键盘。对键盘有兴趣的同学可以去听一听。另外，哥是四川人，所以普通话不是很标准，大家见谅 :-)比特新声第47期：《你是如何去按Ctrl键的？ ...继续阅读 (57)

序用Go做开发有几个月了，其间尝试过Sublime Text, Atom, LiteIDE，总感觉还是不如当初用Vim来得顺手。于是，我又开始折腾了一把，把开发环境切换回了Vim。这次，主要给大家分享一下折腾的心得，以及如何把Vim，Tmux，Zsh结合起来，打造一个功能强大的IDE环境。工具清单话说，工欲善其事，必先利其器。我们需要如下几个工具的支持：Vim: 呃，这不是废话么，必须的啊……不然怎么写代码呢……各种Vim插件: 后面会列出清单Tmux: 一个功能强大的终端复用软件，不过，为啥要用这个工具呢？稍后为你揭晓答案……Zsh: Bash的完美替代品注：这次所有的环境都基于MacOS搭建，在Linux系统下亦可，至于windows环境嘛，估计会比较折腾，我没试过……IDE预览先来看看IDE的最终效果吧，最终折腾出来是这个模样：搭建步骤第一步，是安装zsh以及oh-my-zsh，其实Mac默认貌似已经自带了zsh,可以通过命令:1more /etc/shells查看zsh是否已经安装。oh-my-zsh，其实是一个用来配置和管理zsh的一个十分方便的工具，有了zsh，就有了强大的补全功能，再加上各种插件，比如git插件，可以方便的查看当前git仓库下的状态，十分方便。zsh已经是替换默认bash的最佳选择了。第二步，是安装vim以及Tmux。这里不得不提一下Tmux，强大的终 ...继续阅读 (52)

前言自从去年开始，我日常的工作环境基本都是在iTerm2+Tmux+Vim+Zsh中，这几大神器结合使用起来，能极大提升工作效率。从写代码，编译，debug，部署，维护服务器，都能在终端里面实现了，从此摆脱了对图形化IDE的依赖。为此，还专门写了一篇blog，分享如何使用这几个工具搭配，搭建属于自己的IDE：打造Go的IDE。唯一美中不足的是Vim是运行在终端里面，感觉性能还是比不上MacVim，在代码文件较多的工程，会有一些卡顿，另外，也是因为我装了一堆插件的原因，各种的语法检查，自动补全，格式化代码等过程也会降低一些速度。直到关注到一个新的”坑”:NeoVim。NeoVimNeoVim，作者称它是Vim在这个新时代的重生，因为Vim的年纪确实有点大了，还是上个世纪90年代的作品。虽然这么多年过去，Vim仍然被许多开发者使用，但Vim本身已经由于自身包含大量遗留代码，程序的维护更新，bug的修复都已经变得越来越困难。NeoVim的作者也是因为当初向Vim提交了两大补丁，包含了大量改动，不幸被Vim的作者拒绝，认为风险太大。所以，NeoVim的作者干脆另起炉灶，开始开发NeoVim。相比Vim，NeoVim的目标有几点：通过简化维护以改进 Bug 修复及特性添加的速度；分派各个开发人员的工作；实现新的、现代化的用户界面，而不必修改核心源代码；利用新的、基于协同进程的新插件架构改善扩 ...继续阅读 (54)

最近闲下心来，重新折腾了一下GitLab，相比起一两年前折腾起GitLab的痛苦经历，各种Ruby环境配置以及依赖包的问题，搞得人一心想放弃。如今，GitLab的安装包安装起来真是方便多了，使用官方提供的Omnibus package，可以在两三分钟的时间搭好GitLab，可以看到GitLab作为一个开源产品，是一直在不断进步的。搭建私有Git服务的优势就目前而言，市面上比较有名的Git服务提供商，大概就是GitHub，BitBucket，GitLab，以及国内的Coding.net(瞎说!不是还有GitCafe么？呃，已经被Coding.net收购鸟)了。实际上，这些Git服务商提供的服务，都能满足个人的需求，无论是免费的开源仓库，还是私有仓库，个人用户都可以使用。这里主要谈一谈为什么需要搭建自己的Git服务，大概是有以下几点原因：公司的项目，因为商业层面的原因，需要把代码托管到自有的服务器上，并且服务器很有可能是放在企业内网中，不对公网开放。出于安全性的考虑，暂时没有使用国内的Git服务平台的计划。GitHub和BitBucket，GitLab，由于服务商是在国外，受地域的影响，因此在网络访问上会有延迟。现有的服务商，对于免费的套餐都有一定的限制，比如GitHub只允许建立免费的开源repository，不允许建立私有的仓库。BitBucket允许建立无限制的私有项目，不过对于 ...继续阅读 (50)

持续集成介绍持续集成(Continuous integration，简称CI)是一种软件开发实践，即团队开发成员经常集成他们的工作，在每一天的时间中，可能会发生一次或者多次集成。而每一次的集成都是通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早的在持续集成的阶段发现软件中的错误。持续集成给团队所带来的好处，不言而喻：减少并降低软件开发中的风险：在每天一次或者多次的集成中，通过相应的测试，能尽早的发现软件中的缺陷，尽量把软件中的错误暴露在开发阶段。最常见的场景，就是在多人的团队中，别人改动相关代码影响了你的代码逻辑，但他们不知道你写过这些单元测试或者没有跑单元测试的习惯，而持续集成能帮助解决这样的问题。减少重复而又枯燥的单元测试过程：代码的改动不能避免的就是需要重复并且不断回归的运行之前写好的单元测试，而这一过程往往让工程师头疼，因为编译代码，准备测试数据，运行测试并查看结果，完全是重复的体力劳动。通过自动化的持续集成，不需要人工干预，完全可以把工程师从痛苦的循环中拯救出来，降低心智负担，让工程师能够把精力放在具有更高价值的事情上。随时生成可运行和部署的软件：利用持续集成的特性，我们随时可以得到可以运行和部署的软件，对于客户来说，可以部署的软件产品是最实际的资产。而对于团队成员来说，也能让他们更有信心，因为他们清楚的知道每一次构建的结果，他们知道他们对软件的改动造成了哪 ...继续阅读 (61)

前言自从去年开始，我日常的工作环境基本都是在iTerm2+Tmux+Vim+Zsh中，这几大神器结合使用起来，能极大提升工作效率。从写代码，编译，debug，部署，维护服务器，都能在终端里面实现了，从此摆脱了对图形化IDE的依赖。为此，还专门写了一篇blog，分享如何使用这几个工具搭配，搭建属于自己的IDE：打造Go的IDE。唯一美中不足的是Vim是运行在终端里面，感觉性能还是比不上MacVim，在代码文件较多的工程，会有一些卡顿，另外，也是因为我装了一堆插件的原因，各种的语法检查，自动补全，格式化代码等过程也会降低一些速度。直到关注到一个新的”坑”:NeoVim。NeoVimNeoVim，作者称它是Vim在这个新时代的重生，因为Vim的年纪确实有点大了，还是上个世纪90年代的作品。虽然这么多年过去，Vim仍然被许多开发者使用，但Vim本身已经由于自身包含大量遗留代码，程序的维护更新，bug的修复都已经变得越来越困难。NeoVim的作者也是因为当初向Vim提交了两大补丁，包含了大量改动，不幸被Vim的作者拒绝，认为风险太大。所以，NeoVim的作者干脆另起炉灶，开始开发NeoVim。相比Vim，NeoVim的目标有几点：通过简化维护以改进 Bug 修复及特性添加的速度；分派各个开发人员的工作；实现新的、现代化的用户界面，而不必修改核心源代码；利用新的、基于协同进程的新插件架构改善扩 ...继续阅读 (60)

持续集成介绍持续集成(Continuous integration，简称CI)是一种软件开发实践，即团队开发成员经常集成他们的工作，在每一天的时间中，可能会发生一次或者多次集成。而每一次的集成都是通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早的在持续集成的阶段发现软件中的错误。持续集成给团队所带来的好处，不言而喻：减少并降低软件开发中的风险：在每天一次或者多次的集成中，通过相应的测试，能尽早的发现软件中的缺陷，尽量把软件中的错误暴露在开发阶段。最常见的场景，就是在多人的团队中，别人改动相关代码影响了你的代码逻辑，但他们不知道你写过这些单元测试或者没有跑单元测试的习惯，而持续集成能帮助解决这样的问题。减少重复而又枯燥的单元测试过程：代码的改动不能避免的就是需要重复并且不断回归的运行之前写好的单元测试，而这一过程往往让工程师头疼，因为编译代码，准备测试数据，运行测试并查看结果，完全是重复的体力劳动。通过自动化的持续集成，不需要人工干预，完全可以把工程师从痛苦的循环中拯救出来，降低心智负担，让工程师能够把精力放在具有更高价值的事情上。随时生成可运行和部署的软件：利用持续集成的特性，我们随时可以得到可以运行和部署的软件，对于客户来说，可以部署的软件产品是最实际的资产。而对于团队成员来说，也能让他们更有信心，因为他们清楚的知道每一次构建的结果，他们知道他们对软件的改动造成了哪 ...继续阅读 (56)

最近闲下心来，重新折腾了一下GitLab，相比起一两年前折腾起GitLab的痛苦经历，各种Ruby环境配置以及依赖包的问题，搞得人一心想放弃。如今，GitLab的安装包安装起来真是方便多了，使用官方提供的Omnibus package，可以在两三分钟的时间搭好GitLab，可以看到GitLab作为一个开源产品，是一直在不断进步的。搭建私有Git服务的优势就目前而言，市面上比较有名的Git服务提供商，大概就是GitHub，BitBucket，GitLab，以及国内的Coding.net(瞎说!不是还有GitCafe么？呃，已经被Coding.net收购鸟)了。实际上，这些Git服务商提供的服务，都能满足个人的需求，无论是免费的开源仓库，还是私有仓库，个人用户都可以使用。这里主要谈一谈为什么需要搭建自己的Git服务，大概是有以下几点原因：公司的项目，因为商业层面的原因，需要把代码托管到自有的服务器上，并且服务器很有可能是放在企业内网中，不对公网开放。出于安全性的考虑，暂时没有使用国内的Git服务平台的计划。GitHub和BitBucket，GitLab，由于服务商是在国外，受地域的影响，因此在网络访问上会有延迟。现有的服务商，对于免费的套餐都有一定的限制，比如GitHub只允许建立免费的开源repository，不允许建立私有的仓库。BitBucket允许建立无限制的私有项目，不过对于 ...继续阅读 (56)

序用Go做开发有几个月了，其间尝试过Sublime Text, Atom, LiteIDE，总感觉还是不如当初用Vim来得顺手。于是，我又开始折腾了一把，把开发环境切换回了Vim。这次，主要给大家分享一下折腾的心得，以及如何把Vim，Tmux，Zsh结合起来，打造一个功能强大的IDE环境。工具清单话说，工欲善其事，必先利其器。我们需要如下几个工具的支持：Vim: 呃，这不是废话么，必须的啊……不然怎么写代码呢……各种Vim插件: 后面会列出清单Tmux: 一个功能强大的终端复用软件，不过，为啥要用这个工具呢？稍后为你揭晓答案……Zsh: Bash的完美替代品注：这次所有的环境都基于MacOS搭建，在Linux系统下亦可，至于windows环境嘛，估计会比较折腾，我没试过……IDE预览先来看看IDE的最终效果吧，最终折腾出来是这个模样：搭建步骤第一步，是安装zsh以及oh-my-zsh，其实Mac默认貌似已经自带了zsh,可以通过命令:1more /etc/shells查看zsh是否已经安装。oh-my-zsh，其实是一个用来配置和管理zsh的一个十分方便的工具，有了zsh，就有了强大的补全功能，再加上各种插件，比如git插件，可以方便的查看当前git仓库下的状态，十分方便。zsh已经是替换默认bash的最佳选择了。第二步，是安装vim以及Tmux。这里不得不提一下Tmux，强大的终 ...继续阅读 (60)

我人生中的第一台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…后来高中毕业的暑假，又升级过一次机器，虽然配置强劲了许多，不过印象已经有些模糊了。第三台机器，是陪伴我整个大学，一直到现在的PC机，由于平时习惯了用笔记本电脑，这台机器其实已经在毕业过后闲置吃灰很多年了。这台机器，在现在看来，已经是古董得不能再古董的机器了：CPU: AMD Athlon 1700+硬盘: 希捷80GB内存: 1.5GB (最初是256MB，升级过后到了1.5GB)显卡: Geforce 2 (后来升级到了3还是4，忘了)光驱: 三 ...继续阅读 (52)

缘于对机械键盘的喜爱，我经常在blog上写一些机械键盘的开箱和评测的文章，供喜爱机械键盘的爱好者作对比和参考。结果让我没料到的是，这几篇机械键盘的评测文章在搜索引擎排名比较靠前，以至于在我查看blog每天的访问流量统计数据的时候，大部分的来自搜索引擎的流量，都是指向这几篇键盘的评测文章。这是让我一直比较困惑的一个问题……其实，我的blog本来是个编程技术相关的blog，没想到反倒是几篇开箱文流量最高 -_-# 嗯，其实这是一个不务正业的技术blog……言归正传，或许是这几篇开箱评测文，吸引到了比特新声的主播，于是我也有幸受邀成为嘉宾，跟主播郝海龙一起，录制了一期跟键盘有关的播客。关于播客，对我来说并不陌生，从最早的在iTunes上的订阅，到后来去荔枝FM上订阅各种感兴趣的播客。只是之前还从来没有亲自参加过录制，这也算是人生的第一次了。播客的录制时间，约定在五一假期前的那天晚上。那天，成都竟然莫名的下起了倾盆大雨，还伴随着阵阵雷声。之前没有任何的准备，所以出门上班的时候也没有带伞，于是回家的时候被淋成了落汤鸡，还好赶上了录制的时间。整个播客是用远程Skype的方式录制，跟主播聊起了键盘的方方面面，话题也不仅仅限于机械键盘，还包括程序员使用的静电容键盘。对键盘有兴趣的同学可以去听一听。另外，哥是四川人，所以普通话不是很标准，大家见谅 :-)比特新声第47期：《你是如何去按Ctrl键的？ ...继续阅读 (48)

在Docker大行其道的今天，我们能够非常方便的使用容器打包我们的应用程序，并且将它在我们的服务器上部署并运行起来。但是，谈论到如何停掉运行中的docker容器并正确的终止其中的程序，这就成为一个非常值得讨论的话题了。事实上，在我们日常的项目当中，这是我们经常需要面对和处理的问题：场景A：假如我们打包在容器中的程序，提供HTTP方式的服务，负责处理各种HTTP requests并返回结果，我们必然希望在容器被停掉的时候，能够让程序有时间把已经在处理中的请求继续处理完毕，并返回结果给客户端。场景B：又比如我们打包在容器中的程序，负责写入数据到某个数据文件中，我们希望程序能够在容器被停掉的时候，有时间把内存中缓存的数据持久化到存储设备中，以防数据丢失。场景C：再比如现在流行的微服务架构中，一般会有服务发现的机制，也即每一个微服务在启动之后，都会主动把自己的地址信息注册到服务发现模块当中，让其他的服务可以知道自己的存在。而在容器被停掉的时候，微服务需要即时从服务发现模块中注销自己，以防止从API Gateway而来的请求被错误的路由到了已经被停止掉的微服务。如上的各种场景中，都要求打包在容器中的应用程序能够被优雅的终止(也即gracefully shutdown)，这种gracefully shutdown的方式，允许程序在容器被停止的时候，有一定时间做一些后续处理操作，这也是我们需要进 ...继续阅读 (87)

在Docker大行其道的今天，我们能够非常方便的使用容器打包我们的应用程序，并且将它在我们的服务器上部署并运行起来。但是，谈论到如何停掉运行中的docker容器并正确的终止其中的程序，这就成为一个非常值得讨论的话题了。事实上，在我们日常的项目当中，这是我们经常需要面对和处理的问题：场景A：假如我们打包在容器中的程序，提供HTTP方式的服务，负责处理各种HTTP requests并返回结果，我们必然希望在容器被停掉的时候，能够让程序有时间把已经在处理中的请求继续处理完毕，并返回结果给客户端。场景B：又比如我们打包在容器中的程序，负责写入数据到某个数据文件中，我们希望程序能够在容器被停掉的时候，有时间把内存中缓存的数据持久化到存储设备中，以防数据丢失。场景C：再比如现在流行的微服务架构中，一般会有服务发现的机制，也即每一个微服务在启动之后，都会主动把自己的地址信息注册到服务发现模块当中，让其他的服务可以知道自己的存在。而在容器被停掉的时候，微服务需要即时从服务发现模块中注销自己，以防止从API Gateway而来的请求被错误的路由到了已经被停止掉的微服务。如上的各种场景中，都要求打包在容器中的应用程序能够被优雅的终止(也即gracefully shutdown)，这种gracefully shutdown的方式，允许程序在容器被停止的时候，有一定时间做一些后续处理操作，这也是我们需要进 ...继续阅读 (46)

在Docker大行其道的今天，我们能够非常方便的使用容器打包我们的应用程序，并且将它在我们的服务器上部署并运行起来。但是，谈论到如何停掉运行中的docker容器并正确的终止其中的程序，这就成为一个非常值得讨论的话题了。事实上，在我们日常的项目当中，这是我们经常需要面对和处理的问题：场景A：假如我们打包在容器中的程序，提供HTTP方式的服务，负责处理各种HTTP requests并返回结果，我们必然希望在容器被停掉的时候，能够让程序有时间把已经在处理中的请求继续处理完毕，并返回结果给客户端。场景B：又比如我们打包在容器中的程序，负责写入数据到某个数据文件中，我们希望程序能够在容器被停掉的时候，有时间把内存中缓存的数据持久化到存储设备中，以防数据丢失。场景C：再比如现在流行的微服务架构中，一般会有服务发现的机制，也即每一个微服务在启动之后，都会主动把自己的地址信息注册到服务发现模块当中，让其他的服务可以知道自己的存在。而在容器被停掉的时候，微服务需要即时从服务发现模块中注销自己，以防止从API Gateway而来的请求被错误的路由到了已经被停止掉的微服务。如上的各种场景中，都要求打包在容器中的应用程序能够被优雅的终止(也即gracefully shutdown)，这种gracefully shutdown的方式，允许程序在容器被停止的时候，有一定时间做一些后续处理操作，这也是我们需要进 ...继续阅读 (47)