模仿学习（Imitation Learning，后面简称IL）的思想就和它的名字一样，借助“专家”示范样例，机器会记住这些样例，并模仿着做。
GameAISDK中的IL沿用了上述思路，使用训练集和验证集两个样本集，样本由截屏与行为的映射信息组成。训练成模型后传入截屏进行行为预测，预测结果为对应需要执行的行为。
腾讯在今年8月份的时候开源了自家基于AI的游戏自动化测试工具GameAISDK（https://github.com/Tencent/GameAISDK）。这个东西最吸引人的地方就是使用了CV+AI的技术来实现游戏自动化。
区别与以前的脚本或者UI自动化工具，对业务代码侵入少，技术前沿。
总分100分的话，我给60分，主要槽点如下：
下面我选取一下典型的例子来分析一下，可能每个点都提一下核心问题和总结，因为要展开说每个点都可以形成单独文章。
后面简称GameAISDK为工程。
Read More →九月初的时候，安装在云服务器上的Mysql被人盗了，数据被删，留下了一段勒索信息，所幸是Mysql除了我的博客数据外并没有什么重要的数据。
勒索信息大概意思是付0.06个比特币（当时行情价差不多4000RMB）就把Mysql数据还给我。这绝对是过高的预估了我的数据价值，这些数据去个0，顶多值400。
比较遗憾的一点是，因为我的疏忽，云服务器Mysql没有开启binlog，若直接通过Mysql数据文件恢复，会存在数据损失（因为库表内容已经被盗取者覆盖过了）。
硬盘快照自动短期备份设置只保留7天，但是数据库的修改是在7天之外，求助了官方说备份删除了就删除了，无法恢复（这点我是存疑的）。最终无奈只能恢复二年前的备份，然后云上的硬盘镜像最后一次永久备份是二年前，若恢复这个备份，会有若干评论交互和十几篇博文信息缺失。权衡之下无奈恢复了二年前的备份，再通过“外部网站备份”拷贝回原有的文章信息。
事情过程不复杂，只是思考了几点：
站在黑客角度
站在受害者角度
这次mysql被盗可能是因为使用了Tars教程推荐公网权限的账号，并未修改密码导致的。
站在云服务角度
（全文结束）
一篇迟来的文章，这个问题先在公司内部做了分享，然后才搬运到博客上面来。
2020年4月底《山海镜花》开服即炸服，随后玩家串号。作为一个游戏开发者，客观评估串号应该在网游事故中排第三。
个人心中的网游事故排名（同一量级下）：
一二可能相对比较好理解，串号这个东西比较玄乎，为什么玩家A会登陆到玩家B账号上面进行操作？甚至连开发同学可能对这个问题开始都是一脸懵：怎么会这样？下面我们逐一来分析串号问题。
（所有分析站在全局角度，并不仅仅针对《山海镜花》的问题）
Read More →名字发现服务（后文简称Naming）一般使用在分布式系统中，当新节点加入时，如何让其他节点知道？
原始的做法是使用配置文件，对每个节点可相连的节点进行配置。这种方法费时费力还容易出错。所以现代系统中一般使用配置中心或者Naming对新加入的节点进行管理，让其他节点感知到它的存在，从而进行通信。
剔除节点的情形也类似，使用Naming机制能更方便的屏蔽失效节点。所以Blue也内置了一套简单的Naming。
Read More →blue 的整个CS网络通信设计参考了TarsGo（ https://github.com/TarsCloud/TarsGo ），在其基础上做了一些优化与微创新。
目前只提供了基于TCP通信协议的相关接口，后续会加入UDP或者RUDP通信。
代码包里提供了一个简单的TCPClient封装，里面有连接服务器、收发包基本功能。一般来说用不到，因为使用go做客户端的比较少。目前仅仅在blue的样例中使用。
Read More →blue的配置功能实现在：
https://github.com/lanyutc/blue/tree/master/conf
blue的日志功能实现在：
https://github.com/lanyutc/blue/tree/master/util/log
目的是暴露出重要的运行参数，通过配置文件的形式进行设置，比如应用名字，服务名字，提供服务的IP:Port等等。
配置文件使用最简单的key=value格式，同时约定以‘#’开始的行为注释行；配置项分为必需配置项与可选配置项，必需配置项若留空则程序启动时会出错，可选配置项若留空则使用默认值。
Read More →写在前面的废话
最近几年一直关注Golang（后面简称Go）的发展，最开始翻看了很多关于Go独特优点以及如何解决传统C/C++程序员痛点的文章，这几年也断断续续的使用Go写一些工具来辅助开发或者服务器事务处理，一方面是在实践中学习Go，另一方面是体验一下Go的“妙处”，看看是不是真说的那么神。但从目前来看收效并不明显，或者说自己没有明显感觉到Go的魅力，归结原因还是对Go使用程度不够。
纸上得来终觉浅，绝知此事要躬行。所以我决定使用Go来造一个服务器框架的轮子。在此之前见过太多的服务器框架，凡是和“框架”两字沾边，必然有一些个人偏好或者选择倾向（从模块结构，代码组织，使用方式等几个角度），而且一般都是针对某种特定场景的框架，比如Http服务、游戏服务、微服务等等。
所以这个轮子也逃不出“凡是”：它会带有一些个人偏好，并且倾向于游戏服务，甚至因为个人经验水平有限会有一些不成熟的设计。不管怎么说，欢迎一起讨论学习。
目前来说初步的功能已经实现，包括一些基本的功能测试用例，后续除了未知BUG的修改，还会出一版完整的使用样例，扩容一下CS通信相关，以及接口易用性的调试修改。
Github地址： https://github.com/lanyutc/blue
Read More →Tars的开源Web管理没有提供 SET区域层级 批量发布的功能（内部版本里面我记得有），提了Issue（ https://github.com/TarsCloud/TarsWeb/issues/13 ）也没回馈。想想自己也算对Tars熟悉，于是便挽起袖子造轮子。
需求比较明确，在上面的Issue里面也说的比较清楚：对一个app众多set里的同一server服务进行发布更新。
最终实现： https://github.com/lanyutc/TarsBatchPatch
Read More →（全文谨代表个人观点）
毕业后进入了一家几百人的游戏公司做开发工作，当时满心欢喜，原因有三：钱够，游戏行业，离女朋友近。进入公司后，并不是965或者996工作时长，而是 周一、二10：00~19：00（开发功能），周三10：00~24：00（开发+测试），周四11：00~周五1：00-13：00（改BUG+发版本），通宵是常事，周六周日很少加班 。
开始的1年我成长很快，一方面是 有高人指点 ，一方面是 自己的努力，有时能搞定别人搞定不了的事情，或者提出更加合理的实施方案 。那会比较年轻，对于“每周通宵一次”丝毫没在意，更何况当时的游戏DAU高峰有50W，月流水高峰有400W，一片欣欣向荣（现在回过头来看已经是我职业生涯所处项目的巅峰了！）。过了一年半慢慢意识到“通宵”的伤身，但是公司的制度无法改变（周四发版本）， 最终选择和组员商量轮班：第一周周四A、B晚11点回去，C、D留守发版本，周五A、B早些过来处理线上问题，第二周轮换 。
Read More →