@JudyHal 原来都是学校限制了神仙的发展

iterm2 和 tmux control mode 有整合，可以用 iterm 的热键去控制 tmux，支持窗口分割，多窗口等功能，还是挺好用的。

因为找不到其他什么需要特别关注的地方，就只能关注学历这种没营养的东西。
只要你身上有比学历更令人挪不开眼的东西，学历就不是瓶颈了。

比如这位高中学历持有者 geohot - https://en.wikipedia.org/wiki/George_Hotz

或者像上面说的，你是 ASF 的 committer，内核维护者等。。这时候 HR 还来纠结学历的问题，估计招聘经理会手撕了 HR

人力滑板

其实取决于几个合伙人都是怎么想的，如果大家想一起干点啥，顺便玩点平时不常玩的，那其实你用些平时不熟悉的技术也不是什么大问题；
要是大家拼的就是个抢滩登陆，那这么玩儿有点说不过。。

挽救的方法，我觉得可以平时可以和合伙人一起多多总结交流一些做的好的，做的不好的，让他们给一些反馈；你也给他们一些反馈，比如怎么更好的帮助你确定优先级、制定日期期限等；在互相反馈中慢慢加强信任。

半个小时左右。跑个脚本就齐全了。如果公司比较大的话，最好把这些配置工作都脚本化，还是能省不少时间的。

你需要 vagrant

一大票初创企业都是跑 python web 的，特别是非 2c 导向的（其实就是公司里面前端比较少，一般都是一些后端出来干的）。

对初创企业来讲，性能一般不是优先考虑点。团队的熟悉程度和开发的效率都更重要。

你觉得一些特别无聊的框架，例如 django，DRF 这种好像一直都没什么变化的，其实才是一个初创团队的好框架，上下限稳定，无微不至的保姆服务，对用最快速度搞出一个还不错的产品来投放市场来讲是很重要的。

web 其实占很多 2b 产品的部分很少。后面的 infra 管理、存储、数据密集型运算需要更多的精力来完成。正巧很多时候做这些的人都能整两手 python，所以选 web 框架的时候，django flask 这类会变成很自然的选择。

参加开源项目，贡献代码，找到同志

搞两个字典，对每一个字母计数，然后比较两个字典的字母计数。
复杂度 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 你值得拥有，还有比这玩意儿更快的吗？