作为VIMer，日常编码中，Vim编辑器依然是我的首选。以前以C语言为主要语言的时候是这样，现在以Go为主要语言时亦是这样。不过近期发现Mac上使用Vim在编写Go代码时，Vim时不时的“抽风”：出现一些“屏幕字符被篡改”的问题，比如下面这幅图中”func”变成了”fknc”: 虽然一段时间后，显示会自动更正过来，但这种“篡改”是会让你产生“幻觉”的。你会想：是不是我真的将”func”写成”fknc”了呢？久而久之，这个瑕疵将会影响你的编码效率。至于为何会出现这个问题，初步怀疑可能是因为vim加载较多插件导致的一些性能问题，我在安装了Ubuntu 16.04的台式机上至今还没发现这个问题（相同的.vimrc配置）。 ...
2016年，Go语言在Tiobe编程语言排行榜上位次的大幅蹿升(2016年12月份Tiobe榜单：go位列第16位，Rating值：1.939%)。与此同时，我们也能切身感受到Go语言在世界范围蓬勃发展，其在中国地界儿上的发展更是尤为猛烈^0^：For gopher们的job变多了、网上关于Go的资料也大有“汗牛充栋”之势。作为职业Gopher^0^，要为这个生态添砖加瓦，就要多思考、多总结，关键还要做到“遇到了问题，就要说出来，给出你的见解”。每篇文章都有自己的切入角度和关注重点，因此Gopher们也无需过于担忧资料的“重复”。 这次，我来说说在使用Go标准库中Timer的Reset方法时遇到的问题。 一、关于Timer原理的一些说明 在网络编程方面，从用户视角看，golang表象上是一种“阻塞式”网络编程范式，而支撑这种“阻塞式”范式的则是内置于go编译后的executable file中的runtime。runtime利用网络IO多路复用机制实现多个进行网络通信的goroutine的合理调度。goroutine中的执行函数则相当于你在传统C编程中传给epoll机制的回调函数。golang一定层度上消除了在这方面“回调”这种“逆向思维”给你带来的心智负担，简化了网络编程的复杂性。 ...
近期闲暇用Go写一个lib，其中涉及到error处理的地方让我琢磨了许久。关于Go错误处理的资料和视频已有许多，Go authors们也在官方Articles和Blog上多次提到过一些Go error handling方面的一些tips和best practice，这里仅仅算是做个收集和小结，尽视野所及，如有不足，欢迎评论中补充。（10月因各种原因，没有耕博，月末来一发，希望未为晚矣 ^_^） ...
Go以简洁著称，但简洁中不乏值得玩味的小细节。这些小细节不如goroutine、interface和channel那样"高大上"，“屌 丝"得可能不经常被人注意到，但它们却对理解Go语言有着重要的作用。这里想挑出一些和大家一起通过详实的例子来逐一展开和理解。本文内容较为基础，适合初学者，高手可飘过:) 一、源文件字符集****和字符集编码 Go源码文件默认采用Unicode字符集，Unicode**码点(code point)和内存中字节序列（byte sequence）**的变换实现使用了UTF-8：一种变长多字节编码，同时也是一种事实字符集编码标准，为Linux、MacOSX 上的默认字符集编码，因此使用Linux或MacOSX进行Go程序开发，你会省去很多字符集转换方面的烦恼。但如果你是在Windows上使用 默认编辑器编辑Go源码文本，当你编译以下代码时会遇到编译错误： ...
本文来自Google的Golang语言设计者之一Rob Pike大神在GopherCon2014大会上的开幕主题演讲资料“Hello, Gophers!”。Rob大神在这次分 享中用了两个生动的例子讲述了Golang的演化历程，总结了Golang到目前为止的成功因素，值得广大Golang Programmer & Beginner学习和了解。这里也用了"Golang的演化历程"作为标题。 ...
近期在某本书上看到Go跨平台交叉编译的强大功能，于是想自己测试一下。以下记录了测试过程以及一些结论，希望能给大家带来帮助。 我的Linux环境如下： uname -a Linux ubuntu-Server-14 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ go version go version go1.3.1 linux/amd64 跨平台交叉编译涉及两个重要的环境变量：GOOS和GOARCH，分别代表Target Host OS和Target Host ARCH，如果没有显式设置这些环境变量，我们通过go env可以看到go编译器眼中这两个环境变量的当前值： ...
手机(智能终端)游戏绝大多数为全屏(Full Screen)显示，这样开发人员在制作游戏时势必要考虑不同手机(智能终端）屏幕大小、宽高比的不同给游戏画面带来的影响，并且要将这种影响降低到最 小，努力使用不同终端的游戏玩家拥有几乎相同的游戏画面体验。为此各种游戏引擎在屏幕适配方面都给出了自己的方案，Cocos2d-x也不例外。 在Cocos2d-x官网Wiki上特地撰写了一篇讲解Cocos2d-x多屏幕适配原理的文章“Detailed explanation of Cocos2d-x Multi-resolution adaptation”。 ...
话说Cocos2d-x 3.0上一周迫不及待地发布了正式版，本是一件值得庆幸的事情。但由于不可解决的技术问题，引擎无奈将Android平台的NativeActivity 实现重新回退到了Cocos2d-x 2.2.x版本的实现方案。由于之前已经将 GameDemo移植到了Cocos2d-x 3.0rc0版，直观感受到了NativeActivity方案带来的游戏操作体验上的提升（触屏事件的响应），因此心里总是“挂念”引擎的 NativeActivity方案。按照Cocos2d-x官方人士的说法，只要NDK的问题修复，NativeActivity还是未来引擎在 Android平台上的第一选择。我的理解，将来Cocos2d-x的某个版本中还会恢复NativeActivity的实现方案。 ...
Cocos2d-x从2.x版本到上周刚刚才发布的Cocos2d-x 3.0 Final版，其引擎驱动核心依旧是一个单线程的“死循环”，一旦某一帧遇到了“大活儿”，比如Size很大的纹理资源加载或网络IO或大量计算，画面将 不可避免出现卡顿以及响应迟缓的现象。从古老的Win32 GUI编程那时起，Guru们就告诉我们：别阻塞主线程(UI线程)，让Worker线程去做那些“大活儿”吧。 ...
给自己的手机游戏增加些社交分享功能，有助于游戏宣传和提升知名度，是一种不错的社交营销手段。国内这方面的第三方插件有不少，比如ShareSDK、友 盟分享组件、Baidu分享组件等，之前在研究2.2.2版本时，集成了ShareSDK这个组件，这次迁移到Cocos2d-x 3.0rc2依旧选择集成ShareSDK，这里就来说说集成的过程，遇到的一些问题以及解决方法。这里仅以Android平台游戏集成为例。 ...