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 的心理负担会很重

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

如果发觉自己只会一个语言 X -- 换一个就很费劲，那确实应该有点担心

直接.raw 把，别勉强

也是分支到分支的。只不过是你 fork 出来的这个仓库的一个分支，到原仓库的分支；
因为你没有推送原仓库分支的权利，所以只能这么弄了；这个一般是给开源库贡献代码的姿势。

如果你们是自己组织内部用，那直接在原仓库里面开分支，推送原仓库，然后发起 PR 合并分支就可以了；没必要走这个模式。

你们的量这么大，建议联系那些公司的销售单独谈价钱。

grpc 有类似 https://github.com/grpc-ecosystem/grpc-gateway 这样的项目，http rpc
一条龙；不知道 dubbo 有没有类似的支持？

希望有朝一日分布计算框架可以变的和 LZ 描述的这么易用；

言归正传，LZ 如果想用 MPI 搞多机 CPU 并行的化，可以看一下 hovord - https://github.com/horovod/horovod/blob/master/docs/mpi.rst

还有一条路，django 一把梭，模板引擎服务端渲染，不是太复杂的 app 都能搞定。JS 会点轻量的就行

找写 pytorch ，tensorflow 的 machine learning engineer 职位；
视觉相关你要看这公司是干什么的。大厂基本没有主营业务是做计算机视觉的，一般都是混在搜索推荐里面，做做多模态，预训练模型之类；
spark, sql 默认你会，毕竟数据你得会拉把

如果 LZ 觉得调薪的时候需要涨 20%才能符合市场情况，建议你直接找公司和老板提出来，不要留遗憾。

@TimPeake 接入本地的容器也是远程开发。
远端服务器都不用跑 ui ，浏览器，聊天工具，其实不那么吃性能。大部分应用开发也不差那么一点点的编译时间。

真正非常吃编译性能的，一般都要上编译服务器，本机也搞不定。

建议加入一键铸造 NFT 功能