光の技术屋

最近开始研究一些游戏自动化测试方面的内容。游戏自动化测试是游戏测试研究领域的难点之一，当前主流的方案有两种，一种是采用纯粹的UI识别方法进行，典型的例子是Airtest，另一种是直接嵌入到游戏引擎中获取节点树等元素从而对实体进行操作，典型的例子是GAutomator。由于笔者先前略微接触过Airtest方面的内容，因此本次决定上手GAutomator尝试游戏自动化。

本次上手过程具体则用GAutomator对Unreal4.24示例mobile项目中的元素进行操作，利用安卓手机进行调试。基本原理上，GAutomator会作为插件嵌入到Unreal项目中，自己包含一些获取World中信息的功能，而后listen一个端口，从而外部请求该插件可以获取World中的信息。通过adb进行搭桥，在外部，用户可以基于GAutomatorAndroid编写，从而不仅可以与GAutomator的Unreal插件打通，而且也可以通过预先集成的UIAutomator这样的工具直接模拟屏幕操作。

hugo是当前热门的个人博客框架之一，和hexo同样是markdown文件跟博客帖子一一对应。有些同学想利用hugo制作个人视频博客，但发现在hugo博客中不支持直接在markdown里输入iframe标签，从而没有办法将其它网站的视频（比如b站）嵌进来。这种情况下，我们可以采用hugo内置的shortcode机制完成这个需求。

我们参考的文章是create your own shortcodes，在这个文档中介绍了自定义shortcode从而快速渲染网页的方法，并且举了youtube以及vimeo的例子。照葫芦画瓢，我们也可以定义b站的shortcode。

我们首先在layouts/shortcodes目录下创建bilibili.html，然后填充内容如下：

本月，eclipse theia发布了1.0版本。作为一个云端/桌面IDE框架，并且顶着eclipse foundation的名声，theia在github上受到万众瞩目。因此笔者决定上手eclipse theia，提前品尝一下云端IDE的滋味。

笔者选择了gitpod而非本地docker作为theia的实验对象，这是因为gitpod本身就是theia的扩展版，并且支持github/gitlab上的项目导入，相当于云端github/gitlab项目的IDE，这样就可以实现在theia中启动一个theia项目，一探其中究竟。

登录gitpod，选择theia项目。项目的预设中会自动构建并在容器的3000端口启动theia。点击右侧的preview，就可以在gitpod的theia中打开原生的theia网页。当然也可以利用gitpod的open in browser方法，在自己浏览器的新标签页中打开原生的theia。

最近在项目组测试有开发一个导表检查的需求，大致是在策划提交表更新到svn之后，svn发送post-commit到策划表数据服务，而后策划表数据服务下载excel文件，更新数据之后，将导表检查下游服务所需的检查数据进行整合，然后post到导表检查服务。在这个过程中，由于做的仓促没有考虑设计，最后策划表数据服务的JVM发生了OOM问题。经过一番排查改进了设计，解决了这个问题。

JVM的内存结构跟GC流程是老生常谈的话题。Java8去掉了永久区的设定，更改为了Metaspace存储类的元信息、常量等内容，而剩下来依然是新区eden和老区old。当eden区空间满的时候触发young gc，将eden区根节点不可达的对象清除，存活的对象转到survivor区。survivor区的对象如果经历了某一个数（可配置，最高15）的young gc后仍然存活，就会转到old区。如果短时间内创建大量对象，且eden区放不下，young gc没有清除过多数据的情况下，多余的数据会转到old区。如果old区也放不下，就出现OOM（Out Of Memory）。一般业务层面导致OOM的原因基本上是一次产生大量对象，或者是内存泄露，没有及时清除不需要的数据引用。

策划表数据的业务逻辑上是下载数据->更新数据->进行导表检查的一个流程，其中下载、更新数据这一环节会产生大量的对象，而同样进行导表检查时为了发导表检查所需的数据，也会产生大对象——需要将数据序列化为json字符串。在这个流程里自己犯了几个错误导致OOM的问题，具体如下：

近期项目组准备做一个新的工具，因此自个儿做的start-fastapi框架正好能派上用场试试水。在起草需求搭建最初框架的时候也逐步发现原先的start-fastapi有一些不足的地方，因此做了一些针对性的优化。

首先必须重新介绍一下start-fastapi，其本身是轻量级web框架fastapi的延伸，但是由于fastapi给的例子过于简单，因此就基于此做了一个简单的web后端脚手架，借鉴了eggjs的目录组织模型，使得整个框架更加易于投产。如果稍微看过start-fastapi其中的代码的话就能够发现它并不是一个OOP的框架，这是因为一方面python本身不是向java一般与OO设计理念强耦合，且其module隔离与动态加载机制已经足够区分每一个功能模块了；另一方面轻量的HTTP Web Server本身作为无状态的服务，各个功能模块应该是静态式、单例式的存在。在start-fastapi上也可以继续扩展底层。从起草工具的效果来看，多人协同开发时，每个人负责的模块应当也不会有太大冲突的概率。

接下来是近期优化的一些点，首先是application目录下的优化。原先application分为了service、middleware、config等多个模块，但现在直接缩减为controller、logger跟router，这是因为service跟middleware里全局性的功能模块一般都是用户自定义的，而controller的response可以约定，logger factory也可以统一提供。而router作为后端app的固有功能，这块就必不可少了。

Vuetify是Vue的一套前端组件框架，基于Material Design设计，界面较为整洁。最近由于项目需要开始入手，但在写自定义v-autocomplete组件的时候却踩了许多坑。因此本文果断记录一下踩坑的过程。

首先新上手vue的话肯定耳边都会萦绕着“双向绑定”一词，用的最多的属性就是v-model了。但是我们参考官方文档可以发现v-model只是语法糖，除了绑定默认组件的值（比如select元素是value，而checkbox元素是checked）之外，还会绑定监听用户输入事件（比如text元素是input，而radio元素是change）。因此要用v-model的话需要关注相应的元素是否本身就支持语法糖。我们在v-autocomplete官方文档中可以发现，其扩展了v-select组件，因此如果用自定义组件包一层的话，一般主要关心的是怎样传递最终选择的value，就可以了。

比如要做一个异步检索items的v-autocomplete组件，我们可以用如下的方式自定义：

其中template如下：

本月，一款名为FastAPI的轻量级Web框架在trending榜上有名。本着踩坑的心态试用了fastapi，发现其坑并没有许多相同量级web框架（比如flask）来的多，上手极其容易。因此果断整理了一下fastapi的上手过程。

FastAPI基于Starlette网络框架进行封装，不仅性能优异，并且解决了许多用python开发效率工具或是轻量级应用的后端同学的痛点。比如：

• 结合pydantic，实现param与body的静态类型检查
• 用妥当的方式接收/返回json body
• 结合Starlette，从而自带restful api以及middleware的支持
• 自带调试router，基本顶替postman的工作
• etc

安装fastapi需要python3.6以上，预先pip3 install fastapi uvicorn。我们来看一下FastAPI的例子：

国内的游戏研发团队里许多策划同学都习惯采用excel作为配表工具。因此对策划同学校对与QA同学验收工作来说，需要相应的diff工具去检测excel文件的变更，从而能够尽早发现配表的问题。为此，在笔者启动的游戏效率工具集gameff-toolset小项目中，首个小脚本便做了excel diff。

diff的算法有非常多，但是如何体现策划表与策划工作的特性，这才是最需要注意的。许多项目的策划表都通过SVN进行存储，因此从SVN的commit信息中就可以知道哪些策划表发生了变更/增加，因此，我们只需关心每个excel文件如何进行diff运算就可以了。

策划的excel配表有如下的特点：

在实际使用mongodb的场景中，我们经常遇到多个请求同时在某个collection里update多条document的需求。这个需求看似有许多种解法，但是具体哪种好也说不准。现在便让我们一探究竟吧~

首先我们利用pymongo添加1000000条数据，name字段为hello：

1
2
3
4
5
6
7
8
9
10
11
12
13

from pymongo import MongoClient

client = MongoClient()
db = client['test']
coll = db['concurrency']

coll.insert_many([
    {
        "name": "hello",
        "num": i
    }
    for i in range(1000000)
])

然后，我们另外加一个进程，启动任务为将num字段为偶数的documents的name字段给update成aa，而主线程则update所有documents的name字段为bb。代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

from pymongo import MongoClient
import pprint
from multiprocessing import Pool, Process


client = MongoClient()
db = client['test']
coll = db['concurrency']


def f(name, m):
    coll.update_many(
        {"num": {"$mod": [m, 0]}},
        {"$set": {"name": str(name)}},
    )
    return 1


if __name__ == '__main__':
    p = Process(target=f, args=('aa', 2))
    p.start()
    coll.update_many({}, {"$set": {"name": 'bb'}})
    p.join()
    docs = coll.find()
    d = dict()
    for doc in docs:
        n = doc['name']
        if n not in d.keys():s
            d[n] = 0
        d[n] += 1
    pprint.pprint(d)

最后结果是：

近期进入了另外一个项目组，工作沟通的时候遇到了一些碰撞。在和项目组其它伙伴交换意见的同时，自己也开始思考这个问题：测试、策划与开发，这三个主导游戏研发的部门，谁才是真正把控着游戏的质量？

从自己的职业立场与岗位的配置上来看，测试理所应当真正管控游戏的质量，但是实际上又不尽然。从策划和开发的立场上来看，一个关心游戏呈现的效果，一个关心游戏的稳定性，都是广义上的“质量管理”。但实际情况下，许多研发与策划同学会希望测试能专注于提bug，这方面没有什么问题，而希望测试同学只提出经过自己确认后的所谓的bug，这种观点倒是有点不靠谱。