更好奇大佬用的什么主板

那算啥……我这还有个 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 设置也行，其实难度不高的。

录音+调解啊？这都要人教？

感觉还是 withings 好 续航长真的太重要了，其实就需要闹钟 心率 提醒这几个功能罢了

亚马逊有一整个 builder tools team 维护了一个内部的版本管理系统 依赖写在 config 文件里面，有个组会扫描依赖文件然后自动化发邮件的

Avg?lz 原来做哪部分的？代码？

@Osk 大佬啥叫菜羊 SoC，可以讲讲吗？

高度设定成 node.height = max{node.left.height, node.right.height} + 1, splay(x)的时候顺手维护，在取的时候就找一条路满足 node.height = node.[left/right]+1 就可以一路找到最长路了

第二个在 splay 的时候做一下不就完了？把最常用的扭上来之后更新被扭的那个节点的高度就成了

建议找个大公司的职位学学正确的设计方法，感觉偏野路子了

日系微整容比韩式一刀切强很多，也贵太多