虽说sublimetext3+gosublime+gocode是目前较为 流行的Golang开发环境组合，但作为一名VIMer，没有一套得心应手的Vim for Golang dev心里总是过不去的。Golang虽然年轻，但即便是从Go 1版本发布(2012年3月28日)算起，掐指算来也有小三年了。全世界的开发者已经为Golang贡献了较为成熟的Vim插件了。有了这些插件，搭建出 一套高效的Golang开发环境还是不难的，网上也有大量的资料可以参考，其中就有vim-go作者自己发表的一篇文章《Go development environment for Vim》。不过看别人 写的与自己搭建体验的还是有大不同的，于是想来想去还是把整个过程记录下来。 ...
很多人学习和使用Golang一段时间后，都会被golang的第三方包依赖版本搞得有些烦躁，golang设计者最初过于乐观的设计使得今天大 家不得不各自想办法解决这个问题。godep就是综合了多年第三方包依赖问题的解决方案后的一个趋向统一的方案，至少是在go get的设计没有进化前的一个比较不错的方案。 今天试用了一把godep，不过“体验”并不理想，这缘于我遇到了godep的一个“坑”，不过是那种你在正式项目中不一定遇到的“坑”，这里来说到说到。 ...
本月初golang官方blog(需要自己搭梯子)上发布了一篇文章，简要介绍了近几个月Go在一 些技术会议上（比如Google I/O、Gopher SummerFest等）的主题分享并伴有slide链接。其中David Crawshaw的“Organizing Go Code”对Golang的代码风格以及工程组 织的最佳实践进行的总结很是全面和到位，这里按Slide中的思路和内容翻译和摘录如下（部分伴有我个人的若干理解）。 ...
近期在试验如何将我们的产品部署到docker容器中去，这其中涉及到一个技术环节，那就是如何让docker容器退出时其内部运行的服务程序也 可以优雅的退出。所谓优雅退出，指的就是程序在退出前有清理资源（比如关闭文件描述符、关闭socket），保存必要中间状态，持久化内存数据 （比如将内存中的数据flush到文件中）的机会。docker作为目前最火的轻量级虚拟化技术，其在后台服务领域的应用是极其广泛的，其设计者 在程序优雅退出方面是有考虑的。下面我们由简单到复杂逐一考量一下。 ...
在进入正式内容前，我这里先顺便转发一则消息，那就是Golang 1.3.2已经正式发布了。国内的golangtc已经镜像了golang.org的安装包下载页面，国内go程序员与爱好者们可以到"Golang中 国"，即golangtc.com去下载go 1.3.2版本。 ...
给自己的手机游戏增加些社交分享功能，有助于游戏宣传和提升知名度，是一种不错的社交营销手段。国内这方面的第三方插件有不少，比如ShareSDK、友 盟分享组件、Baidu分享组件等，之前在研究2.2.2版本时，集成了ShareSDK这个组件，这次迁移到Cocos2d-x 3.0rc2依旧选择集成ShareSDK，这里就来说说集成的过程，遇到的一些问题以及解决方法。这里仅以Android平台游戏集成为例。 ...
近期研究了一下Game App做社交分享，最后选择了ShareSDK来集成，不仅是因为ShareSDK支持国内外主流社交平台，更重要的是ShareSDK提供了专门的 cocos2d-x集成方案，有专门的文档和代码Demo供开发者参考。 文档中提到了三种集成方式：纯Java方式、plugin-x方式以及Cocos2d-x专用组件方式，这里选择了ShareSDK Cocos2d-x专用组件（v2.3.7版本)的方式。按照文档中描述的步骤进行的相对顺利，在各个社交平台的appkey生效后，我们对demo app进行了测试，居然发现app经常随机性的崩溃，有时甚至是每次都崩溃，经过深入分析，发现这是ShareSDK Cocos2d-x专用组件的一个严重Bug，下面详细说明一下Bug的产生原因以及Fix方法。 ...
2013年的个人年终总结比以往来得晚了一些，至于原因，我也说不清楚，拖延症也罢，其他原因也罢，总之是晚了。 写年终小结已经有小几年了，风格一直如一，无非是老三样：工作得失、生活酸甜以及新年展望，今年也不利外。 ...
很多时候，一旦习惯了某些事情，也就习惯了它们的恶劣，习惯了它们的丑陋，习惯了它们“赋予”你的各种痛苦。 – Tony Bai 一、痼疾难解 曾几何时，在那个还没有集群化，没有分布式的时代，它还是一个不错的方案，至少在线上没有暴露出太多问题，它也不在我们关注的重点范围之内。但随 着集群化、分布式的新版本的到来，那一大坨遗留的代码就变得格外让人不顺眼，同时问题也随之在线上暴露开来了。 ...
自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, … ] ...