《从零单排Golang》系列，又重新开张了。后续会不定期更新自己学习Golang的笔记跟心得。
这次的话，就介绍一款名为奎爷kratos的微服务框架，以及讲述一下基础的使用机理。
kratos是B站开源的微服务框架，不仅提供了grpc、http协议支持，而且有较为完善的层级架构、微服务中间件以及第三方组件的编写约定，可以说是非常方便上手跟扩展。
要上手kratos，我们可以从两个地方入手：
通过kratos的quickstart文档，我们可以创建一个名为kratostest的项目。项目的目录结构遵循kratos-layout，具体如下：
在互联网上，关于游戏测试（开发）领域的技术分享，实际是非常稀少。尤其针对游戏功能测试领域，很多文章的思想维度仍然停留在很久以前，关注的更多是测试用例设计以及质量管理这些更加偏向业务方面的内容。很多同学认为游戏业务测试缺乏技术含量，其实本质上是因为，很少同学愿意投入精力去研究这个领域的技术，以及研究这些技术如何更好地契合到实际的业务当中。
为此，针对游戏测试（开发）的工作特性，笔者根据自己以前的博客整合了两个文集，分别是：
在一些无缝大世界的游戏当中，我们通常能够体验到游戏的自动寻路功能，通过自动寻路，玩家可以不用任何操作就到达任务或者玩法的目的地，从而让游戏过程更加轻松。在测试寻路功能时，不仅需要检查寻路是否成功到达，而且也需要关注寻路路径呈现的效果，从而确定玩家是否走在策划预想的路径上。
由于寻路起点、终点选择的随机性，人工执行寻路测试时，往往需要根据自定义的规则遍历多个特定的起点终点，这样操作起来不仅非常耗费人力，而且针对再后台存储navmesh数据、做动态烘焙以及计算寻路路径的场景，在验收寻路效果时，测试人员还需要多次手动从后台拉取一定范围的navmesh数据并绘制在客户端的路面上，才能知道玩家是走在什么样的路面。为了解决寻路效果测试的效率问题，引入自动化技术显得非常有必要。
因此，笔者将结合自己实际的工作经验，分享一种在UE4大世界游戏中，寻路效果自动化测试的方案。
《Game Of AutoTest》的最后一篇文章，聊一下游戏自动化测试的价值。
一千个人心中有一千个哈姆雷特。仅以笔者的角度，游戏自动化测试的价值，可以体现在这几个方面：
做好自动化测试的价值分析，不仅能够自动化测试技术落地做足理论基础，而且也能在任意时候指引自动化技术落地者做好当下的决策，从而逐渐把自动化测试做出更大的规模跟成果。
近期装Ubuntu22.04虚拟机，发现侧边菜单栏多了个Floppy Disk图标。软驱这东西毕竟是上世纪的了，2022年也没什么用，但就是找不到入口去掉这个冗余的图标。
今天偶然之间发现去掉图标的方式，供大家参考：
电源/声音/网络按钮，选择Settings设置Appearance，就是能调Light/Dark风格的页签Dock栏目下，点击Configure dock behaviorShow Volumes and Devices下，有一个Include Unmounted Volumes项。反正软驱一般也不会挂载，所以取消点选这个项，Floppy Disk图标就没了。正值十一假期，近期准备把自己的python笔记精编整理，做一个pdf电子书。在调研如何把多个markdown文档转化为单个pdf的时候，试了很多种方法。最后找到了最佳方案，也就是本文的主角，由phodal前辈整理的电子书生成项目ebook-boilerplate。这个项目不仅支持批量转markdown为pdf，而且还支持转成ebook等多种格式。
使用这个项目的时候，也踩了一些坑，需要做一些额外的配置。以笔者的场景为例，电子书生成环境是Ubuntu22，需要转化一堆中文的markdown。clone了这个项目之后，除了ebook-boilerplate本身README.md里描述的内容之外，实际还需要留意以下环节：
在游戏自动化测试技术落地过程当中，如何保证自动化测试的稳定性，是一个需要重点优先解决的困难问题。
以手机游戏客户端自动化测试为例，和一般服务架构的自动化单元测试或集成测试不同，自动化驱动的过程，其本质更加类似于网络爬虫，每次测试执行都是一个时间较长的过程，而流程一长，不稳定因素则随之而来。游戏自动化的整个过程，大致是这样的：
要分析如何保障整个自动化过程的稳定性，我们可以根据这几个步骤进行细节切分，对每一个环节影响稳定性的因素逐个理顺，从而最终，我们就可以得到一整套自动化稳定性保障的解决方案。在这四个步骤当中，前置环境准备和用例脚本执行这两步，对自动化流程稳定性的影响面最大，而最后面两步的影响程度，则相对较低。
近期笔者因工作原因，需要做一个安卓手机的文件浏览功能，集成在笔者以前用PyQt5做的一个的工具当中。文件浏览功能大概做成这样：
其中，文件列表选型用了QListView组件，但在实现兼容双击进入文件夹+右键菜单功能时，稍微踩了下坑。为了解决这个问题，笔者在网上查阅了许多资料，最后找到一种解决方法，决定记录于本文当中。
首先需要了解，Qt对于QListView这类数据容器组件，是遵循MVC的设计模式的。QListView数据的初始化，方法是这样的：
自动化在技术层面上，除了基础的技术选型之外，最终还是需要落实到具体的工具框架，才能够助力我们自动化脚本开发的过程。因此，本文将讲述一下如何对游戏自动化测试框架进行设计。
在上一篇文章讲到，自动化测试的方式可以有客户端、服务器、编辑器三种方式，除了编辑器需要强依赖引擎层面的特性之外，其他两种自动化方式在工具或者框架的技术实现上有这么几个特点：
考虑到当前我国有许多游戏企业的工作习惯是，测试由中台dispatch到各个项目，不直接参与研发过程（Code Review？不存在的），项目产品以提测的方式交付测试，测试侧可以运用自己的测试手法和工具去完成任务。从这样的角度看，拥有一个功能性强且通用的自动化测试工具，不仅是对于项目所需要自动化测试的场景，更是对于测试组整体的技术基建提升而言，都显得非常重要。
以笔者工作经验为参考，要做到游戏自动化框架得以通用，设计上需要遵循如下准则：