感觉你们的用户会很痛苦

看懂技术文档主要需要的是：单词+阅读+领域知识

英语培训得问问清楚侧重点是什么，别培训了一圈听力+口语，还是两眼一抹黑。

先从单词开始抓起把，这个是基础。
有了单词基础，再从简单的英文版计算机领域教科书开始看。教科书的用语都很精确和简练，不常使用修辞等写作方法；同时包含大量领域专业名词，过程中可以增加专业词汇量；因为是技术书籍，还包含了大量代码示例，这类内容阅读起来基本不费力，能降低阅读时的受挫感。

教科书如果觉得太长了也可以从英文技术博客开始下手。

感觉 LZ 就是想知道一个软件在 Linux 下是不是也能用，没有 linux 版本的话，有没有什么替代品。这个倒是和怎么用命令之类的关系不大。

其实善用搜索引擎就可以了。

举个例子，比如我想在 linux 下面看 pdf ，我知道 windows 下面可以用 adobe pdf reader 。那肯定第一反应是 google “adobe pdf reader linux version”.
然后发现 adobe 的官方 linux 支持只到 9.5.5 ，2013 年的一个版本，也没有找到任何官方下载的页面。所以这个选择肯定不太好。

那我的第二反应是搜搜看 发行版+软件功能看看有没有什么替换品，所以 google “ubuntu pdf reader”，找到了如下的一个软件列表： https://askubuntu.com/questions/18495/what-pdf-viewers-are-available-for-ubuntu

然后发觉有人推荐 evince 这个软件，看着还不错。所以进入官网的下载说明： https://wiki.gnome.org/Apps/Evince/Downloads

然后官网推荐我从发行版直接获取该软件。所以我的反应是回到操作系统，用 apt 搜索一下

```
$ apt search '^evince'
Sorting... Done
Full Text Search... Done
evince/focal-updates 3.36.10-0ubuntu1 amd64 [upgradable from: 3.36.7-0ubuntu1]
Document (PostScript, PDF) viewer

evince-common/focal-updates,focal-updates 3.36.10-0ubuntu1 all [upgradable from: 3.36.7-0ubuntu1]
Document (PostScript, PDF) viewer - common files
```

发行版果然提供这个软件，然后就可以愉快的 `sudo apt install evince`安装使用了。

@leimao 1000 Read QPS 对正常的数据库都是毛毛雨；内存读写引入 redis memcache 这样的，也会徒增复杂度。

分成 3 个部分比较好。

a. 一个数据库 -- 这个负责不同程序之间的数据交换和存储
b. 一个 celery 应用 -- 负责 1 和 2 这两个定时任务( https://docs.celeryproject.org/en/stable/userguide/periodic-tasks.html )。生成的 summary 写入 a 的数据库，加上一个生成时间戳；做的粗糙一点，甚至不用 celery 这样的任务队列，直接用 crontab 也可以（但需要处理失败重试等问题）
c. 一个 flask 应用 -- 用户请求来了之后，负责去 a 里面的数据库，查出最新的 summary 返回给用户

这类软件大家这么喜欢用，怎么没见大家疯狂造开源轮子

虽然这边是用在 pandas 里面，但是拼装 sql 语句不是好习惯。

贡献一个 mvp.css - https://andybrewer.github.io/mvp/

token 这个不要犟，token 过期属于常规操作；前端可以做一些封装，请求代码写起来就没区别了

多给开源项目交 PR 把，有人免费给你 review 代码，有人教你怎么写测试和保证覆盖，多人参与的项目肯定会对结构和设计的易读性有要求。我的经验是可以参加参加大厂认真开源出来的项目。如果这个东西是谷歌拿出来的，那大量的 contributor 其实就是谷歌内部的工程师，你交 PR 的时候，其实变相过了一遍接近谷歌标准的 review 。

很不巧，这些东西很多在平时工作中都缺失了。

试试这几个：

1. 你的查询基本上都是 = 条件，所以考虑用 hash index ，不用 btree index ，大概有 10-20%的性能提升；
2. 使用 CLUSTER- 基本就是重排数据记录，让相近的数据在同一个 cluster 里面；这样应对 比如查询所有 from_addr = xxxx 的记录的时候有奇效，因为这些记录都是邻居；
3. 使用 PARTITION - 思路和 sharding 接近，但是不需要引入多机；方便 query plan 并行化执行

@yidinghe 没有 vim mode 不能令人信服

@singerll 1s = 1000ms

我觉得其实工具倒还是次要的。以下几点我觉得对 review 的效率更重要：
1. 每个 PR 只做一件事情 -- 加一个 feature ，修复一个 bug 等等；这样可以保证一次需要 review 的代码量不会太大
2. 一些格式问题，常见的语法问题等等不要人来 review ，用 linter 和分析器来解决，review 之前保证先把这些低级错误给修复了
3. 特别复杂的 PR 需要附上设计文档，作者需要阐述大概是怎么实现这个功能的
4. 测试还是需要写，否则全靠人来把握代码正确性，reviewer 的心理负担会很重

原来只有我一个人永远看的是网页。。