项目需要，需接入操纵杆、油门外部控制设备，以支持太空漫游相关控制操作。
0 概览
设备为罗技的X56 H.O.T.A.S.。分为油门和操纵杆两个设备。
1 尝试
之前并未接触过这类设备，首先查到的方向是JoyStick。因为仿真服务是C++，但我对C++并不是太熟。故找了一下Python相关的读取代码。
Windows下游戏手柄的读取
Windows下Python修改文件创建及修改时间
项目需要，某些场景下需要修改文件的创建(Date created)及修改时间(Date modified)，另外还有个访问时间(Date accessed)，不过这个时间打开文件夹访问时就会更新。
文档
需要安装pywin32模块。
关键代码
import pywintypes
import win32file
def change_file_time(filename: str, create_time: float, modified_time: float):
"""
修改文件的创建时间和修改时间
:param filename: 文件名
:param create_time: 创建时间
:param modified_time: 修改时间
:return:
"""
# 若为文件夹
if os.path.isdir(filename):
os.utime(filename, (create_time, modified_time))
return
handle = win32file.CreateFile(filename, win32file.GENERIC_WRITE, 0, None, win32file.OPEN_EXISTING, win32file.FILE_ATTRIBUTE_NORMAL, None)
win32file.SetFileTime(handle, pywintypes.Time(create_time), pywintypes.Time(modified_time), pywintypes.Time(modified_time))
递归方式 获取全部文件(夹)
def get_all_files(path_dir: str):
"""
获取指定目录下的所有文件
:param path_dir:
:return:
"""
files = []
for dirpath, dirnames, filenames in os.walk(path_dir):
for filename in filenames:
abs_file = os.path.join(dirpath, filename)
files.append(abs_file)
for dirname in dirnames:
abs_dir = os.path.join(dirpath, dirname)
# 添加文件夹
files.append(abs_dir)
# 递归获取文件
files += get_all_files(abs_dir)
return files
业务逻辑
将日期修改为四、五月份，时间修改为[10-19]点之间，尽量随机一些。
基于Python OR-Tools的监考老师任务分配
整体逻辑比较简单，适合对Python有一定了解，并对OR-Tools求解器感兴趣的同学，作为简单入门案例。
一、摘要
最近在浏览V2EX站时发现一个求助帖，求助：用 Python 安排监考–让科技来拯救一下手搓党，感兴趣的可以看下原贴。
主要是想通过编程代码方式，完成对监考老师的分配工作。
目前手动解决方法：（有时需要 2 次才能排出监考表）
1. 先根据场次限制，制作出所有老师的监考次数。
2. 根据特殊要求先安排必监考科目和考场和不监考科目和考场的老师，逐个复制粘贴到监考表。
3. 单科目一个人不能重复出现。还需要考虑到能一天安排安排的就别分散安排。
4. 统计老师名单中所有老师在各科中出现的次数以及总的监考场次。然后手动逐一调整。
因为最近也在做类似排产排程相关内容，也有了解过OR-Tools的基本使用。这跟官方的一个示例很接近: 员工日程安排。
基于Spring Boot + Dubbo的全链路日志追踪(二)
一、概要
紧接上一篇，完成分析之后，就要具体的实现了。
service-a: 实现dubbo服务。
service-b: 实现web服务，并调用service-a实现的服务。
二、实现
2.1 日志采集及存储
本例直接使用【阿里云·日志服务】进行数据存储和检索，使用Aliyun Log Logback Appender进行日志收集及上传。
其实就是阿里自己实现了一个Logback Appender。当然我们也可以自己实现，比如上传至自建的ELK中。
基于Spring Boot + Dubbo的全链路日志追踪(一)
一、 概要
当前公司后端整体架构为：Spring Boot + Dubbo。由于早期项目进度等原因，对日志这块没有统一的规范，基本上是每个项目自己管自己的日志。这也对后面的问题排查带来了很大的困难，特别是那些需要同时或者多级调用Dubbo的服务场景，排查起来更加的困难。
现在需要实现从请求开始，到请求结束的全程日志跟踪。需求很简单，实现思路也不难，只需要全局添加一个traceId即可。