搞两个字典，对每一个字母计数，然后比较两个字典的字母计数。
复杂度 n log n

https://teachyourselfcs.com/
有中文翻译

其实可以换位思考，你要是公司的老板或者 CTO，你怎么在公司现金火烧屁股，只能支持个半年多的时候去选择技术。

1. 第一肯定是你们团队对什么东西最熟悉就上什么，短时间就能发挥最大化工作效率。团队大部分人都是 Elixir 老鸟，偏要去赶热门上什么 Go 肯定不合理。人效在企业早期最重要。
2. 第二是要考虑框架 /语言本身的开发效率和对业务的支持程度。这个也是一般意义上大家优先关注的。你们公司开发数据库的，硬要去用 PY 写肯定不合理。
3. 第三才是去考虑长期的计划。这个我觉得可能是最不重要的。长期我们这个框架能不能支持业务的发展？长期是什？我们能不能活过今年？等我有了钱，招个一整个团队来整吧。就像 FB 干的，硬生生要去杠最好的语言 PHP，整了 jit 编译器，运行时虚拟机，类型系统，重写标准库，一整个团队去支持它们的 PHP fork Hack 语言，一样能扛起大量的业务。真是有钱任性。

你这代码是多进程而非多线程。
CPU 报警得分析分析原因：
1. 是否是因为单个 worker 的 CPU 占用率过高？单个 worker 内部的任务代码是怎么样的？有些代码是可以释放 GIL 的，例如 numpy 的向量化，一个 process 也可以利用多核 CPU
2. 是否是因为 job 太多导致整体负载高？
3. 负载是一直很高还是瞬时有大量任务进来导致短时负载？
4. 其他原因等等

1 的话，如果单个 worker 就能跑满 CPU，建议减少 worker 的数量，同时 scale up，换用更强的 CPU
2 的话，scale out，堆更多的机器
3 的话，建议考虑使用 MQ 来异步处理任务，避免瞬时负荷过大

google 搜索

10 分钟一条消息问这个借口怎么用，那个借口怎么用。直到人家忍不住说 “你 tm 不会看文档 /源码”。。。

我也有段时间觉得什么东西都用的很熟，憋着一股劲儿但又不知道做什么。
后来我找到三个比较好的解决方法
1. 我开始向平时使用高频的一些库和软件贡献代码，慢慢从这些软件的用户，转变为维护者开发者
2. 开始写一些博客。我一般这么判断一个话题值不值得写一篇文章：如果 Stack Overflow 上面我一下没有找到特别好的答案，最后我自己摸索了一阵搞定之后，我会考虑写一篇采坑的文章
3. 辞职了开始全职创业。。。这个是真的变成全干工程师

@iEverX 具体的原理我也不太清楚，但是公司有几个比较特别的代码管理方法，导致了做这类工具的可行性，应该不是每个企业都适用：
1. 采用了 monorepo 管理代码，所有代码全在一个 repo 里。
2. 采用了 bazel/buck 这样的模块化编译工具。所以代码之间的依赖关系可以通过解析 bazel 的文件得到。

curl 你值得拥有，还有比这玩意儿更快的吗？

可以考虑数字游民的生活方式（ digital nomad ）。一般都是找个远程工作，然后去个生活成本低的区域过日子。
比较热门的生活目的地 - 南美、东欧、东南亚海岛。

有些国家 比如罗马尼亚，对远程工作员工申请工作签证还挺友好的。

CKA，CKAD，AWS 各种证书，方便你以后出来自己干，全干工程师必备

有忧郁症的倾向，建议找个心理咨询

这得放个代码 peer review 一下才好，否则有种搞个大新闻的感觉。
有些简单的算法训练，GPU 构不成性能瓶颈，V100 这么大的显存都是空置，这时候再去比较谁训练快没啥意义。

我在公司看到过的几个神奇的自动化测试管理工具

一个工具会侦测下游被你代码影响到的部分，交 pull request 的时候除了你自己写的测试，还会把那部分测试也跑一遍
一个工具会侦测哪些测试已经失效，会自动暂停这部分有问题的测试

感觉这些工具都不是标准工具，但是对管理大量自动测试非常的重要

只要我的手速够快，冲突就找不上我。

下次记得 ping 一下 reviewer 。还有如果不是功能或者架构性质的意见，（例如只是改改格式，重命名一下函数名之类的没营养的 comment ），建议直接 approve 之后，交给 MR 作者改正更新后直接自行合入。

建议改成 最好用的个人 linux 操作系统

工作期间写的代码属于公司所有。
要是写了什么很牛🍺的代码，建议离职之后另起炉灶，写个开源版本出来

弄个 dept -> user 的 map，是不是就快一些了

macFuse + sshFS 把。
但是性能好像很捉鸡