上周电脑突发极其奇怪的bug，启动了不到一会儿CPU阻塞，所有程序打不开，安全模式查毒、修复系统、清存储卸软件均没有获得较好的效果。因此索性重装了Windows，所有一切推倒重来。
既然推倒重来，那CSGO就是不得不装的一款游戏。CSGO到现在也有10年的历史了，然而在网上能搜到的游戏优化设置要么过时，要么没有详尽的整合。因此，本文章借着装机经验，整理了自己优化CSGO的历程~
由于笔者为Win10+N卡，因此在Linux/Mac以及非N卡下玩CSGO的同学，部分配置还需另行google~
运行在Win10的游戏需要关闭Win10自带的游戏优化与配置
首先关闭XBox自带的DVR（游戏内录像之类），有很多种方法，这里通过注册表方式解决：
rpc（远程过程调用），是不同主机间的交互的机制之一。好比说，我们想要获取服务器的某个资源，我们就可以发送一条讯息给服务器，然后服务器解析信息，再返回推送资源的信息，这样，便实现了我们客户端跟服务器的相互的“远程调用”。
为了让不同主机之间能够相互理解发送的讯息，我们需要约定统一的信息格式标准，使得不同的主机可以发送基于这个信息格式的讯息，也可以解析这个格式。这种标准，我们称之为协议（protocol）。
Lua中协议选择有许多种，protobuf、json均可。但是今天，就稍微介绍一下云风同志当年为lua量身设计的sproto协议以及其用于协议测试的二次开发。So, let the party begin~
sproto是专用于lua的协议框架，相对于protobuf跟json，sproto在数据的序列化/反序列化效率上有极大的优势。rpc中为了快速效率地传送协议数据，会将数据组装压缩发送，接收端再解压拆解数据识别消息，从而减小了网络传输的开销。这个数据处理过程便可称之为序列化/反序列化。
sproto的设计类似于protobuf，基本类型为string、binary、integer以及boolean四种。对于array序列的支持，则加上引用星号*即可；对于非整数的支持方面，用户可以parse string来处理实数，或者指定integer的小数位数来处理小数（decimal）。除此之外，用户也可以像编程里面strcut那样自定义类型，类型与类型之间也可以嵌套。
我们可以从readme中寻找各种例子。数据类型的例子如下：
Github传送门
最近回忆起了在学校那会儿趣事：刚开始上数据库原理课程，一开始装Microsoft SQL Server，全班同学都在吐槽，怨声载道——这个说数据库咋启动不了，那个说数据库咋卸载不干净，个个焦头烂额，实在是好一番风景。唉，那时候就在想，要是有一个类似于软件管家的东西托管Microsoft SQL Server，让我们一键安装/卸载，可不就好了。
进入工业界，接触了运维方面的知识，才了解到docker的存在。不同于当年常用的虚拟机软件（VMWare WorkStation），docker并未对操作系统的硬件支撑做虚拟化，只是操作系统的进程，但却模拟了一个操作系统的环境，因此相对于虚拟机而言，docker更加轻量。轻量的运行环境意味着基于docker的部署，在管理与调度上会更加容易。看，kubernetes！
再回到我们的学习生活，拿MySQL为例吧——有了docker，安装卸载MySQL，就会变得无比容易。首先docker pull mysql；而后整理一下配置——通过-v映射数据在本地的存储路径，通过-p暴露出来mysql容器的端口，通过-e设置MySQL密码等环境变量；之后docker run带上上面的设置，我们的MySQL就启动了！要彻底卸载的话，只需要三行命令：docker stop ${MySQL容器ID}、docker rm ${MySQL容器ID}与docker image rm ${MySQL镜像ID}，就ok了，是不是EZPZ？
正好，docker是基于Golang编写。因此本期从零单排，我们就用Golang来挑战一下如何与docker交互吧~
首先，我们研究一下相关的技术栈：官方提供的Golang客户端库docker client为Golang与docker间搭建了桥梁，其实质是对docker engine api的抽象；而docker engine api实质则是一个HTTP后端，是对docker内部镜像与容器管理功能的抽象。
通过docker client库，我们只需关心相关的参数输入。库中的方法会自动拼装参数，发送至docker engine api，从而实现交互。docker client的一些小例子，可以参考这里。
接下来，我们必须研究一下，要部署MySQL容器，需要有哪些步骤：
提到lua，就不得不提协程coroutine。coroutine是lua的一种内在机制，为lua提供了原生的异步支持。从用户层面来看，用户不需关心coroutine的内在实现，而只需要用coroutine调度function即可，因此非常方便。
对于一个function而言，coroutine可以将function的代码分片，使得一个function可以分阶段运行。在实现上，function的状态管理会与CPU的机制相似。如果把一个function当做一个任务来看待的话，在coroutine的封装下，这个任务会被分解成多个阶段的子任务。这样，我们就可以把多个任务的子任务相互协调调度，实现更加灵活的功能交互。
因此，本期Lua杂谈，就来小试一抔coroutine的使用吧。
官方5.3.5版本的coroutine库，提供了如下的接口：
1 | // lcorolib.c |
用户可以通过coroutine.wrap与coroutine.create两种方式封装一个function（任务）。通过wrap封装任务会返回一个纯粹的lua函数（type为function），而用create封装则返回的是一个封装好的线程。
在Lua中，线程thread与协程coroutine的概念内涵有较多相似之处，但我们可以认为，线程是更加宏观广泛的概念，协程则是一种特殊的线程。线程强调的不同的routine之间运行是否独立；而协程强调的则是不同routine之间具有相互co的协作功能。
基于这两种方式调度任务的代码写法大同小异。以下以create封装任务为例，我们一起看看会是怎样的进行——
我们的日常生活离不开手机，有些同学喜欢用国产的安卓机，而另一些同学喜欢用简约的iPhone。
对比安卓和iOS的软件生态，我们可以发现：安卓软件的投放渠道繁多，题材花样繁复，质量大小不一，而iOS的投放渠道则为App Store独家，相对安卓软件来讲，不仅质量均衡，而且用户不必担心手机病毒的困扰。这一点，就归功于App Store严格的审核制度。
Github传送门
学一门新语言，如果太专注于语法，那肯定学的不够快。如果有一定的需求目标，带着这个目标去学习一门新语言，这样才能学得快。
工作中写后端的时间比例不在少数，而且传闻Go也因其适用于服务端而著名。在Go社区中最为火热的服务端框架跟数据库抽象ORM层当属gin跟gorm了，因此本期单排的目标便是用gin+gorm打一个简易的框架，实现基本CRUD的目标。走你~
在第一话中已经大致了解了Go项目的生成，故本次gin+gorm的搭建也以此为基础。
服务端领域的各种术语在不同的场景跟技术栈下有不同的含义。但总体来讲，一个简单的服务端App都会有以下的层次：
基于以上结构，大致构建了以下的目录结构：
近几天一直在思考什么是用户思维，决定结合这一年的工作，把自己的想法记录下来。
在这之前，自己一直秉持一种观念——测试开发从工作内容上，更加符合“开（码）发（农）”的定义，因此应当更加着重于技术深耕，并且在业务对接时，也尽可能地从从技术实现的角度去阐述观点与想法。但是在经过同事伙伴们的提点，以及和家中领导激烈讨（吵）论（架）了一番之后，这个观念就慢慢地改变了。
测试，不仅仅是根据需求，利用各种工具，对开发交付的产品进行功能、性能、安全等测试，发现bug而后提交复现/解决方案，从而确保产品稳定（QC）。而另一些方面在于——如何确保研发计划完备进行，预防产品设计缺陷，从而保证产品体验；如何优化产品生命周期流程，从而使产品顺利上线运营（QA）。作为偏中台的测试开发，扮演的角色更像是“优化产品生命周期”的实现者，而前线上的QA与QC，则成为了我们的用户。因此在业务对接时，首先都需要尽可能满足前线同学的需求，让他们引领效率工具/平台的设计。
Github传送门
当测试开发真不容易，入行第一年，就要在python、NodeJS、lua、C、Java等语言间无缝切换。为了快速响应需求，挺难抽出时间去深耕一门语言的特性（诶羡慕那些只搞Java的人= =）。在MTSC2019分享中也谈到，测试开发归属质量保障QA，作为一个中台角色，其终极任务保障研发效能，因此一大需求是打通产品研发运维的生产线。说到生产线就想到上云，说到上云就想到docker跟kube，说到跟容器的交互就想到了Golang。马蛋，又要学一门新语言了。
开这个坑，旨在展现以程序员的视角学习一门新语言的过程。希望大家看得欢乐。如果有启发，那就更棒啦！
家里的电脑是Windows，从官网即可下载Win的安装包。Go的版本为1.12。
下好后安装，安装完毕之后还需要设置环境变量（我的电脑——属性——高级系统设置）。GOROOT设置成Go的安装路径，还有一个关键的GOPATH，它表示你的工作目录，一般所有的Go项目，甭管第三方的还是你的，都统一放到这个目录下（从这点可以看出，Go的控制欲还是很强的）。GOPATH的一般结构如下：
安卓的fps测试，是我打开测试开发大门的一把钥匙。两年前的现在，安卓性能测试的相关资料甚少，以fps为例在网上也只有寥寥几篇文章讲述，但到了今年，已经有许多资料在各大技术论坛上供大家看到了。对于自己，一直想找一个机会把这一段技术探索写出来。所以，心动不如行动。
fps（frames per second），通常表示我们屏幕每秒展现的图片（帧）数，反映了一款应用在当前硬件下的性能消耗。比如我们抽CS的时候，就经常关注fps是否高，在高的情况下，就会有较好的流畅度。因此fps是应用性能测试中一个重要指标。
对于一个安卓app而言，为了测定fps数值，我们需要从安卓图形显示相关的模块入手。一个通用的方式是切入安卓的SurfaceFlinger服务，它是图形显示流程中软件层和硬件层的交互点，是极其关键的一环。SurfaceFlinger则是负责分析&合成各个app中的图层，而后将合成的图像数据交由硬件渲染。硬件渲染的机制复杂，因此安卓系统中，将硬件操作进行了抽象方便调用，我们将这一与SurfaceFlinger对接的层次，称之为硬件抽象层（HAL）。SurfaceFlinger与HAL在功能上有部分的耦合，一些Surface合成的工作，也会委托HAL进行。
那么我们该如何通过SurfaceFlinger获得fps数据呢？大体上，我们可以参考《Android性能测试之fps获取》一文。这种方式成功率高（虽然我家手机行不通），且不用root，较为方便
首先，通过adb，我们可以导出SurfaceFlinger服务的运行时信息。