jieba/hanlp

起码是能力不差，工作态度良好的才值得培养

@wangyzj 就像工程师用 web 框架开发 api 吧，很多场景都有成熟的模型可以套，但算法本职的理论知识深厚，能进一步优化模型或是本土化改造。也不排除任何岗位都有混子

和 java 对接过加密，就是 padding 策略不一致

人工智能难在模型研发和底层数学算法理解，仅仅学一下 tf/torch 框架搞神经网络，抄抄公开模型，做做数据预处理，搞搞离线部署，其实对我们工程师来讲并不难

blpop 换成 lpop 然后加一个取到空数据的小延迟

可以做到，约等于爬虫，但对方可以检测到你的 IP 调用频率然后封掉

有没有把指针转为 uintptr，过一阵又转回去取内容的

如果更换协程后仍然限制 1600 总并发，猜测 cpu 稍微减轻，内存较大下降；不限制并发，cpu 和带宽会有一个顶满

@matrix67 感谢告知，方便给一下安装文档吗？在百度和谷歌试着搜了一些关键词，没有找到这个命令

开发时间特别紧用*，否则好好写

搞 freeswitch 的时候弄过 stun 服务，专门获取外网 ip 的协议

frp/ipv6

盯上了倒数第三行，扫描行数高一个数量级

这是我不喜欢 go 的一个地方，没有构造函数，方法没有默认参数

最简单粗暴的方法是 while(sleep(1000)) {data = select db;if(data) break;}

@xylophone21 我更倾向于在 APP 聚合，让后端接口层更原子化，尤其是产品快速迭代时期，减小前后俩部门的沟通成本和联调复杂度。UI 变化时，前端仅需改变组装方式，只有业务逻辑变动时需要后端针对某个模块做修改。两个数据有交叉的页面，也只用维护一个接口。不太了解 APP，是不是原子接口也更容易封装组件。如果某个模块发生异常，其他数据可以正常显示。当然讨论前提必须是 h2，1.1 要么阻塞排队要么创建新连接，肯定无法接受

如果能上 h2 协议，觉得聚合的优势不大，反而增加维护成本

@x97bgt 大概算是更复杂的负载均衡吧，istio 的虚拟服务可以控制流量