对应现实中标准的自动化生成流程

非标转标

非标不能太宽泛..所以有接口限制

@bxb100
你说的没错, spec 和接口的设置本身就是要适配需求、甚至要预留未来需求，本身就是需要比一般代码人员更熟悉的人来编写的

但是实际项目中,根本没人、或者根本没时间干这个事, 大部分时间都再怼业务代码、需求还改来改去导致接口与结构都一直在变化

这种情况下还把文档、结构和代码分开，那么反而会成为累赘,还不如写什么代码就生成什么文档和结构


这种反向自动生成行为本身就是为了适应环境的结果,是结果,不是目的

你要知道更差劲的结果是: 设计的文档、结构、接口和代码根本对不上、因为根本没人管

这本质是一个工程问题
方式 1： 设计人员设计好结构, 接口, 编写文档,由设计指导代码编写
方式 2： 开发人员编写代码后,同步文档

1 和 2 的本质区别,在于结构、接口、文档是开发人员负责还是专门的部门、人员负责

如果根本不存在一个专门部门或者人员负责文档和结构设计,自然倾向于自动生成文档和结构

注解生成只是自动生成的方式

那还不 explain 看

传感器数据还不上时序!换 pg!

备份整个数据库 然后重设了看看呗

golang 看 pitaya

@wzw
code 不能确定具体错误, 很多错误需要解析错误文本才能确定具体错误

@kuanat

你不怎么写 python 才会有这个问题, python 有 contextlib.contextmanager

golang 的很多问题就是 TM 的太丑了....还在那里犟,一开始还吹逼不要泛型呢,后来呢？
有些丑的好改有些改不了了而已...大家凑活着用罢了。

pg 最好指定 lc_message=en_US.UTF-8

@kuanat
defer 你解释那么多都没啥意义....

defer 怎么实现大家并不关心,纯粹语法上难看而已
python 的 with 就是漂亮,defer 就是丑

openstack 的工具库都非常棒
oslo.config 非常棒的配置文件库
oslo.messaging rpc 库
taskflow 工作流
oslo.service 进程管理
oslo.versionedobjects 数据结构体版本管理,支持 rpc,方便数据兼容、升级

gen8 8700t 的 nas 好得很....就是 fedora29 想换了但是懒得折腾

pg 直接 copy csv 啊,为什么转 sql

dos2unix

还有一个可能 60000-65000 之间的端口 是 win 某些服务的默认端口....
你可以尝试把 ip_local_port_range 改到 3w 或者 4w
避开系统已经用到的端口,或者之际从 win 的默认动态端口里扣出来

win 系统默认的你别改多啊,改少一点试试
我也是猜的

先确定你要多少个链接,然后按照具体数量设置/proc/sys/net/ipv4/ip_local_port_range
设置完后到 windows 中,找到对应分配端口的注册表
设置动态端口避开 ip_local_port_range 占用的动态分配端口
重启系统