牛皮，pin 了一个后端的，star 了

说错了，是 akko 的 3084，手感很棒，外观也不是很差

在用 ducky 的 3084

外部排序

@xuanbg 大哥这三不信深得我心

ikbc 87 或者 akko 84，折腾这玩意儿干嘛？对 NOI 又没好处

@billytom
linksys 卖人之后出的产品质量控制和固件有衰退，netgear 也就个美国 tplink 的等级，做的产品还没 tplink 好，同样的 powerline，电力猫就是没 tplink 的快。

建议无脑 asus

不知道网易邮箱算不算 pop3 登录的，要是算的话，写个小脚本就可以当签到挂了

v2 上会做数学的根本不多，很多 VPS 根本不廉价，个人折腾用当然是家里装个服务器好

问了一个原生美国人，他的第一反应“你哪儿知道这个问题的？”哈哈哈哈哈哈

更好奇大佬用的什么主板

那算啥……我这还有个 repository，改了下 README.md 就在 CI 上挂 test case 了， 加了行注释，挂 test case。

有种“睡眠排序”的感觉

route53 只要 0.5 刀一个月，花钱买放心不好么？花了钱的东西是不会有随便搞你的情况的

如果碳原子数量超过 62 个就不好弄了 而且羟基之类的表示不方便吧

这游戏内部早就有先验知识了，上人工智能干嘛？

试一试 aws 的 simple email service

通过设置内部 registry，我们可以更进一步，在导入开源库之前就对有污染性的开源协议进行评估，如何更好的利用开源产品。
接下去，就是“ never-build-twice ”这个功能的开发，充分利用之前已有的 build 成果。

然后你还可以进一步考虑，怎么进一步接管整个灰盒测试流程啊这种，比方说，只能在线上验证的代码，怎么自动划分一部分给 pre-Prod staging/baking，怎么做 One-Box baking，怎么 lock 住 stage 防止在高峰流量的时候部署？怎么管理运行时环境的环境变量？怎么用这个做服务端 shadowing(保证除了特定流量之外行为和原来完全一致)

反正这一整套 feature 下来，估计你也升职了，我一个 SDE1 就不多嘴了

我建议这样子，用 k8s/docker 接管所有生产环境的构建流程，然后库之类的外部依赖统一走公司内部的 registry，不允许 override。
build 过程中只能访问内部 registry 就可以避免用一些 hacky 的方式拿外部包、库的问题了。
然后强制所有的库依赖都必须在 dependency.xml 或者 package.json 里面写明白。

这样就直接避免了大部分问题。

如果你们已经有内部的 CI/CD 的话，要做的就是 1.写几个包管理器的 wrapper 2.写几个包管理器的配置文件的解析，然后和你们内部的 email 系统 /工单匹配，pre-build 扫描，定期全局扫描，发现问题就发邮件。

^1. hijack 也好，包管理器 registry 设置也行，其实难度不高的。