gruvbox yyds..

我的经验是平铺窗口管理器,例如 i3 那种,功能不多,但是出问题的机会也少

弄个本地的数据库，把数据搞里面。
根据查阅条件研究一下，应该对什么字段做索引比较好。

这么大的 CSV 文件，python 光读到内存里要花的时间就很客观吧。

其实原生的 Debian 就不大，功能还很全，坑又少，比一些奇怪的零件版本使用起来要省心很多

这个太细分了，以后基本职能继续干这行

可能和 b 树的深度，和 Page 的大小有关

Jersey

英文编码 中文注释会频繁导致输入法切换来切换去。
关键我还用 vim mode ，这个酸爽。。。

当然可以商用，付钱卖许可以了。生产资料用来赚钱还不付钱，人家公司也不是慈善机构啊

k3d 或者 docker ，都是跑在容器里面的 k8s 。
host 机只要装 docker 就可以了，也不会弄坏 host 机的环境。这两个是最方便的了。

因为国外需要算人效。

假设你一大型企业，一万名员工，现在自己做个 yubikey ，上了 5 个码农，1 个产品经理，2 个硬件工程师，一年光工资就两百万美元打不住。这还没算生产和硬件成本。

关键是你买个 15000 个 yubikey ，给员工一人发一个，一百万都不到。。。

无他，划不来而已。

成绩单

之前试过 TDD ，发觉在搞增删查改的时候并没有想象中顺手。
知道我开始写一些框架类代码的时候，才发觉 TDD 的好处。思路非常的自然，先站在用户的角度想别人要怎么使用你的框架，然后写出测试用例，最后去补实现。

这样写出来的框架，质量既稳健，同时又能站在用户的交付思考很多使用难易度的问题，非常的有帮助。

为啥 readiness 不配个 http 探针，报 200 之后再 ready 不可以吗？

教程的核心难道不是里面的内容么。。

排版啥的干净方便查询不就可以了。。

即使物理机都是你的也可以降低成本。你本来的机器利用率是 50%，跑 10 个任务假设需要 16 台机器。
现在用了 k8s ，机器利用率提升到 80%，现在跑同样的任务量，你只需要 10 台机器。

这样在采购机器的时候，就可以少买机器，电费和维护费用也会降低。
提高利用率也是降低成本的一种

看看 OPTIONS 的那个 request 返回有没有头文件

你付了钱的，叫供应商过来给你解决