近期进入了另外一个项目组，工作沟通的时候遇到了一些碰撞。在和项目组其它伙伴交换意见的同时，自己也开始思考这个问题：测试、策划与开发，这三个主导游戏研发的部门，谁才是真正把控着游戏的质量？
从自己的职业立场与岗位的配置上来看，测试理所应当真正管控游戏的质量，但是实际上又不尽然。从策划和开发的立场上来看，一个关心游戏呈现的效果，一个关心游戏的稳定性，都是广义上的“质量管理”。但实际情况下，许多研发与策划同学会希望测试能专注于提bug，这方面没有什么问题，而希望测试同学只提出经过自己确认后的所谓的bug，这种观点倒是有点不靠谱。
近几周一直在某SLG项目内负责功能模块测试与周边工具推进的工作，渐渐感悟到了些用例设计与业务代码的联系。
游戏的业务逻辑是比一般应用复杂的。而且对于自己项目这种强玩法的游戏而言，甚至还会出现以下的现象——QA驱动策划，策划驱动开发。
策划案能够大概阐述游戏的界面、逻辑与数值，但是如果有复杂的特例，还需要QA在实际测试中去挖掘。游戏测试用例的设计过程，不仅可以看成是策划案的延伸，而且也可以看作是一份业务代码的参考文档。如果了解游戏服务端与客户端机制，跟进过代码的话，甚至可以根据它们设计一些极端的用例。
好比说，某一个建筑，占地是5x5，但是它横跨国界，一部分在A国，一部分在B国。那么这个建筑，是属于A国，还是B国呢？
Github传送门
golang在工业中用途最多的方面就是编写中间件以及上游设施，因此切入golang的话，了解其网络库是很有必要的。因此，笔者上手了自带的net包，花了一天左右的时间写了个简单的负载均衡（Load Balancer），也算是能用啦= =
我们在浏览网页时，通常会遇到服务方故障的情况，提示我们nginx、apache之类的字眼。这些，便都是负载均衡的工作了。
一个负载均衡可能会包含以下的功能：
为了实践一下（培养手感），笔者用net包弄了一个基于tcp的简易负载均衡，实现了上述最基础的负载调节与健康检查功能。
首先设计一个struct：
vlang（v语言）自从6月份突然炒热起来，不知不觉到了11月，正式版就要出来了，在11月的GitHub Trending榜中依然排在前10。这着实令人好奇，因此笔者决定试用一下vlang，写一个小应用，体验一下感受。
v语言可以在GitHub传送门中clone下载，支持多操作系统，有以下的特性：
其余的，还有自带的GUI库、结合Go与Rust的语言特性之类，也可以算作所谓的卖点。
安装v语言也很简单，比如在windows上，首先需要安装Visual Studio提供的MSVC环境，然后只需要：
1 | git clone https://github.com/vlang/v.git |
然后执行：
1 | ./make.bat |
再设置环境变量到PATH，就能够随时随地执行vlang了。
近期稍微停歇了下开发的任务，转为进入游戏项目组去探究真正的游戏测试业务是如何进行。在此前做测试工具与平台时会常常遇到业务需求不能准确击中的瓶颈，因此真实投入体验，调研项目组的测试痛点，能够对后续的技术支持工作大有裨益。
游戏，尤其是网游，是一类非常特殊的软件产品，可能会有以下的特点：
简而言之，游戏是一个高内聚、体量较大、变化需求多的软件系统，因此游戏业务测试本身就是不小的挑战。
项目组现处于刚上线的阶段，主要业务是外网缺陷修复的验收以及新功能的测试及回归。其中，新功能的回归测试在笔者认为是更为艰巨的任务。我们首先可以看一下一个基本的测试用例是怎样的:
笔者近期用技嘉（GIGABYTE）Z390装机时遇到了装上一个SSD跟一个机械硬盘后，机械硬盘无法被主板/操作系统识别的问题，经过一番研究后发现了解决方案，特地分享：
首先本经验理论上应当适用于不同厂家的Z390主板上（比如华硕之类）
SSD或机械硬盘无法识别可能是主板芯片共享频宽的问题。以技嘉为例，我们首先需要知道SSD或机械硬盘插在了哪里，以及硬盘有哪些接口。在技嘉Z390上，有以下的硬盘接口：
在说明书中应当会有这些插口所插到的位置图示。
如果不了解硬盘原来插到了哪个接口，可以开机进入BIOS，BIOS中也会显示这些接口插了哪些硬盘。如果插过的硬盘没显示，那就是没识别到了。
接下来也得翻说明书找硬盘接口相关的内容，以技嘉Z390为例，在说明书的插座及跳线介绍——M.2及SATA插座安装注意事项中，会有表格及文字显示M.2的哪个接口安装了哪种SSD，会与哪个SATA接口共享频宽，从而不兼容。借助这个表格找到兼容的接口，把原先插在SATA的硬盘换一个兼容号码的插座，就好了。技嘉的话，SATA插到3、4号（中间两个），是没问题的。
在skynet通信原理与源码分析一文中，我们已经详尽地弄清楚了skynet地通信架构，为我们上手skynet提供了极大的帮助。因此本篇文章接续上文，正式上手使用skynet。
要做一个基于skynet的项目，首先需要一个好的模板。skynet的最佳实践并非将服务卸载skynet模块中，而是将skynet当作一个单独的库/SDK看待，自己独立在另外的目录写业务逻辑。因此，笔者在数月前简单地整合了一下skynet的boilerplate项目——create-skynet，采用这个项目搭建skynet服务端结构会较为清晰。
在create-skynet的配置中，每个服务的lua文件入口以config中luaservice项为准：
skynet启动时会根据服务名注册相应服务，因此自己在service下定义的服务名最好不要与skynet原有服务重名。
skynet在为每一个服务读取lua库的时候，会根据运行skynet脚本的工作目录以及config里的设置去读取，这是由config的lua_path与lua_cpath为准的。在create-skynet里，lualib的位置有：
桌面应用的实现方式有很多，但谈到多操作系统平台兼容的话，就不得不提到electron。electron是前端开发的利好，做过web前端的同学只要稍微迁移下自己的项目，就能够将原本的web前端变成桌面应用。
因此，本文以react为例，以antd为UI库支持，讲解基于react的electron应用该如何搭建。
首先，electron-react-boilerplate项目，就帮助我们初始化了基于react的electron应用。electron-react-boilerplate内置了flow静态类型检查机制、基于webpack的electron应用打包支持以及with redux的前端架构。故在此基础上再引入其它的lib，也不会过于困难。本文采用的electron-react-boilerplate版本为0.17.1。
通过yarn add antd，就可以安装上antd库。要在内置的例子里以antd为layout的话，首先需要在app文件夹下新建app.global.less文件，填充内容：@import '../node_modules/antd/dist/antd.less';，然后我们可以再观察到，app/containers/Root.js是redux store的抽象层，wrap了路由；路由所在的文件为app/Route.js，是以<App>标签为根的路由集合；<App>主界面所在的文件为app/containers/App.js，我们通过更改其中的内容，就可以变换主界面的样式了。我们就以antd的layout为例，写一个App主界面：
提起中国的lua产品，就不得不想到skynet，一款针对游戏，但又不仅限于游戏的服务端架构。skynet充分利用了lua的特性，并且在此基础上易扩展HTTP、HTTPS、WebSocket等模块，因此由skynet入手理解lua原理以及服务端架构是一个非常不错的选择。
通过skynet，我们可以构建许多小巧而高性能、高可用的应用。废话不多说，让我们一起来探索skynet架构吧~
服务端架构中，不同子服务的通信调度是核心功能。因此，我们以单点（standalone）的skynet实例为例，由外而内，逐步剖析。
要介绍skynet的通信原理，首先要提到lua中的一个概念——lua_State。lua_State是lua的运行时（runtime），是一个原生隔离的、高性能的运行环境，若在多核并行运行lua_State，其性能一定不会差。lua作为嵌入式语言，以C为基础，可以实现操作系统粒度级的lua_State调度，因此skynet也就如同lua_State管理器一样了。
每一种业务可以看作一个service，而每一个service中，都会有一个lua_State充当执行业务逻辑的环境。举个例子，在实际开发当中，比如做一个HTTP服务的话，我们需要自己预先配置好的skynet service主入口lua文件中，写上skynet.uniqueservice("app")启动一个独特的名为app的服务，而后在其中的逻辑中，根据每一个HTTP连接，解析其中的数据包。并调用skynet.newservice动态创建单独的上下文服务ctx来处理这个请求。ctx服务还有可能需要查询数据库中的数据，并返回结果，因此我们可能还需要通过skynet.uniqueservice("db")预先创建数据库服务db二次封装skynet内置mongo、mysql库的功能，然后再通过skynet.call来与db服务通信，获得db服务某个函数执行的返回结果，再在ctx服务的处理逻辑中写入HTTP Response，从而完成整个处理过程。在这一过程中，具体业务逻辑的处理都会在各个service所拥有的lua_State中运行，但调度通信的逻辑，则就是底层的活了。
因此在skynet底层中，不仅需要支持多个lua_State的运转，而且相对更有挑战性的是，如何让service之间能够相互交流。为了解决这个问题，我们可以看到，在底层中，每一个service都属于snlua类型。snlua除了包括自己的lua_State之外，还维护了一个称之为context的运行状态：
最近小包装了一下Easy Python系列，放到语雀上整合精编了个pdf投放，完成Easy Python系列的最后一项任务。
第一次编撰一个短篇技术系列，小有成就，值得鼓励。但路还有很远，慢慢来吧~
传送门如下：