和许多面向对象的编程语言一样，Golang也存在interface接口这样的概念。interface相当于是一个中间层，下游只需要关心interface实现了什么行为，利用这些行为做些业务级别事情，而上游则负责实现interface，把这些行为具象化。本文就来通过一个简单的缓存cache模块的实现，来示范一下Golang的interface该怎么用。
首先，从业务service角度而言，一个cache模块可能需要以下几种方法：
那么这些个方法，就可以用一类叫Cache的interface来表示：
很多同学在自己机器上玩开发的时候，都会用到VMWare、VirtualBox之类的虚拟OS容器装一个带GUI的Linux OS，然后在里面另外安装开发工具做开发。这里面遇到的最经典问题，就是比如我在虚拟机里面起了个MySQL、Redis之类的服务，如果DB的客户端/GUI工具是放在主机里面，不在虚拟机里，那怎么连进去？这个问题，本文提供一种解决方案。
本文采取的虚拟机环境如下：
首先需要了解到，VMWare场景下，我们通常用NAT模式新开一个网段来管理虚拟机的网络配置，而虚拟机内部，假设使用IPV4，会默认采取DHCP机制，自动设置一个IP跟相应的网络配置。相关资料可以看这几篇文档：
而为了让我们主机能连到虚拟机内部，实际上是满足下面两个条件之一即可：
在应用日常开发的过程中，不论是在测试、开发联调，还是实际构建发布的时候，我们都需要一定的指标去衡量技术产物的质量，从而判断技术产物是否符合质量标准，是否能够继续发布投产，如果不符合投产标准则拦截发布。从发布过程的角度，由于一般发布过程会收口到特定的CI流水线上，因此在做这类能力的时候，通常是采用开发一个特殊的质量红线原子的方案，集成到CI流水线当中，实现发布准入准出的原子能力。
准入准出质量红线能力的开发者，通常是DevOps中台，中台提供原子能力以及配置化的能力，用户可以根据自己的业务去配置相应的指标产出与拦截规则，也可以直接套用特定的模板来快速实现准入准出的效果。本文就来讨论，这类能力要开发出来，在技术实现上，需要做怎样的考虑跟设计。
首先，针对真实业务，要用到准入准出质量红线的话，可能会考虑以下场景：
因此，从技术实现角度上，这里可以拆解成几个维度：
Golang的反射功能，在很多场景都会用到，最基础的莫过于rpc、orm跟json的编解码，更复杂的可能会到做另外一门语言的虚拟机。通过反射模块，我们可以在编程语言的runtime运行时期间去访问内部产生对象的信息。了解反射模块的实现，对我们了解Golang对象机制本身，也是莫大的帮助。
今天，恰逢阳康+新年，就决定来探究一下Golang的反射模块——reflect。
从最基础的开始，reflect模块，以获取整数对象的类型信息为例，我们可以这么用：
在以前写过的一篇关于游戏策划配置检查工具设计的文章里，笔者讲述了一种表格检查工具的分层设计方法，简而言之也就是两部分：
repo，通过自定义脚本解析repo中文件，提供实际的配置数据excel-diff等等其中，配置数据源服务，在许久以前写过一个样例的版本repomaster，
实际也就是一个管理git-repo的小服务，在这篇博客里有详细阐述实现内容。
而今天的主题则是配置数据处理服务方面的内容，笔者采纳通过配置化方式声明数据处理过程的设计，编写了一个数据聚合工具：daggre，全称为DAta-AGGREgator，专门用于处理数据的联表视图、过滤检查相关的需求。
以游戏业务测试为例，daggre的使用场景，我们可以看两个例子：
《从零单排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图标就没了。