codedump的电报频道

#杂
上周到知乎上写了一则与公司相关、带有PR性质的回答。

按照我之前的习惯，并不愿意在网上暴露自己的公司，原因很多，主要还是怕麻烦。

换了新工作之后，老板的要求：多在社交媒体上宣传公司，于是上面的习惯就难以保持了。

回到这个问题本身来，我当时的想法是：即便是一个带有PR性质的回答，也并不妨碍说一些真话。于是我整理回顾了一下当时做出选择时的心路历程，以及对这个行业方向的一些思考，写进了回答里面。

脑子里想到一句话来形容：“尽管是预设的舞台，并不影响我表达真实的想法。”（原创）

所以，如果有时候不得不说话，尽量做到说的都是自己认可的话，这种话的维护成本最低，因为能够闭环与自己的价值观自解释。

除此之外，我还想到了另外的问题：假设某一天，我离开这家公司，或者不欢而散，今天写下的这些回答，是不是就变成了到时候打脸的文字？

我的考虑是：做任何事情，遵循当时的想法即可，当时怎么想的就怎么做。瞻前顾后的话，就什么都别做了。

总结下来：言和行都要尽量遵循当时内心的想法，这是维护成本最小的做法。说到底，对当时的自己负责，这就足够了。

最后，吐槽一下知乎：早期好好的一个问答平台，现在成了营销平台，广告、营销满天飞，正经人已经很少到上面写回答了，可惜。

https://www.zhihu.com/question/499510958/answer/2232593756

#杂

“
May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give.
”

每次看sqlite代码里的这段话都会肃然起敬，这个相当于把自己的价值观写到了自己的作品里面，随着作品一起发布吧？

喊的口号要跟做的事情对应起来一起看才能看出东西来。比如有的公司是光谈价值观（最受人尊敬的XXX之流），看到作品实则臭不可闻。但是像这样把价值观直接写在作品里，“不但听其言，还能观其行”，这是一件需要更多勇气的事情。

SQLite Blessing license: https://spdx.org/licenses/blessing.html

#不推荐

没有看错，今天这个推送的标签是“不推荐”。既然有“推荐”的东西，就应该有那种我认为名不符实“不推荐”的。

“推荐”或“不推荐”，都是个人主观的看法。我且说一说，读者就权且看一看吧。

第一篇“不推荐”，留给《Database Internals》（简体中文版也已经出版，名为《数据库系统内幕》）这本书。

之所以不推荐，是因为这本书虽然号称“internal”，但是深度方面距离还太远。

本书属于那种典型的“知道分子”写出来的书：什么都能给你涉及一点，但只是隔靴搔痒得点到为止。就好比那些饭桌上能给你侃侃而谈中美形势、台海局势、股市行情等的中年油腻男：什么都能说一点，但是也仅仅局限在“茶余饭后谈资”的程度了。

如果这本书的名字不是“internal”，而是类似“primer”这样的词汇，倒是觉得可以接受，毕竟这个领域的知识点大体能给你科普一遍。但是如果是“internal”，深度还远远不够。

由于之前作者在推特上营销的有点多，于是我对本书的期望值从一开始就挺高，但是当我拿到这本书，想在一些我有疑问的领域想找到深度的解答（比如Btree的实现等）而大失所望时，就得出了前面的结论。

“他什么都懂，直到说到你的领域”，这是我对本书的总体印象。

遂，不推荐。

#推荐

由于经常需要阅读代码，就少不了使用工具来统计一个项目的大体代码量，以做到心里有底。

早期，我使用的是find + grep + `wc -l`等命令的组合来统计。这类基于纯文本的统计，最大的问题是无法将文件中的注释和代码区分统计。

后来，发现了cloc（ https://github.com/AlDanial/cloc ） 这个工具，就一直用来统计项目代码量，看实现内部用的是Perl脚本。

最近，其他朋友给我推荐了Rust实现的tokei（ https://github.com/XAMPPRocky/tokei ） ，这个工具在我的机器上，统计速度是cloc的5倍以上，还有更多的统计维度：空行、注释、代码等等，用法跟cloc大体是一样的。

如果一个产品有各种维度，“快”和“资源占用”少，肯定是对这个产品最开始的印象之一。

我打算全面将统计代码行数这个需求切换到tokei来了。

补充：laixintao为这个工具写了一个图形化展示的辅助功能，见：https://github.com/laixintao/tokei-pie

#推荐

《Readings in Database Systems》（数据库圈常说的“小红书”）第五版的在线阅读版，给出了数据库领域常见的问题以及这个领域相关的重要论文，可以当成数据库领域的论文导读吧：

http://www.redbook.io/

（别看我推荐了，其实我也没有看过：）

#冷知识

b-tree数据结构中的“b”到底是什么单词的缩写？

下意识的，都认为是“balance”的缩写，毕竟这是一个平衡的树形数据结构。但是其实，连几位发明人，也从来没有解释过。

有可能是“boeing”的缩写，因为作者当时就职于波音公司；还有可能是第一作者Bayer的名字首字母。

#博客

新写博客，讲解为什么Raft论文里不允许提交之前任期的日志。这部分论文内容有点难懂，这是因为经常忽略了这个图示展示的是错误的情况，即允许“提交之前任期的日志”可能导致的问题。如果允许这样做，图示展示的是会导致备份到多数的日志被覆盖的情况，这是不允许出现的。

https://www.codedump.info/post/20211011-raft-propose-prev-term/

#推荐

这次推荐投资人Naval Ravikant的书《Almanack of Naval Ravikant》，可以在线或者下载免费阅读：

https://www.navalmanack.com/almanack-of-naval-ravikant/table-of-contents

最早知道此人，是看到和菜头翻译的《如何不靠运气致富》（How to Get Rich (without getting lucky)）：

https://mp.weixin.qq.com/s/TfhBCbr8-IoHyPKtB3hTlw

里面给了很多箴言式的建议，比如：

“你不会通过出租自己的时间而变得富有。”

“互联网极大拓展了一个人职业生涯的可能性。”

等等，风格有点像《穷查理宝典》这种充满智慧的书籍。而《Almanack of Naval Ravikant》一书，相当于把这些箴言式的建议，又给展开详细讨论了一下，还加上了作者其他的一些思考。

据说这本书的中文版就要出版了，网上能找到其他人翻译的中文版：

https://www.yuque.com/qingmiyang/naval

个人阅读下来的体验，看原版会更畅快一些。

#可能是错的

人生没有“一蹴而就”这种事，好比软件设计里没有“银弹”：能解决一切的问题的神器。

以前某个工作干烦了，会羡慕另一个人或另一个公司的状态，其实换了工作蜜月期过后，又会面临各种新的问题。类似的，小时候会羡慕别人怎么样，真到了他那个程度，又会有新的烦恼，等等等等。

年轻时总会认为到了某个程度就能解决所有的烦恼，实际并不是这样的。

所以，不存在那么一个状态，你到了这个状态就没有任何烦恼；反倒是，一个阶段有这个阶段的问题和收益。就好比爬一座山，有那座山的风景还有阶梯，然后继续往下走。

除非死了，否则一辈子都会跟着各种问题。与其想着解决所有的问题，不如先调整心态，想想怎样和各种问题共存，在问题的夹缝里，找到自己的方向，做自己想做的事情。

以上结合自己经历和最近的思考有感而发，正好昨天看到了2014年世界杯贺炜解说西班牙与澳大利亚赛后总结的台词（向不太了解足球的同学交代一下背景：西班牙是2010年世界杯的冠军，而在2014年世界杯小组赛上前两场比赛都输了，这场比赛即便赢了澳洲也会在小组赛阶段被淘汰）：

“人生当中成功只是一时的，失败却是主旋律，但是如何面对失败却把人分成了不同的样子。有的人会被失败击垮，有的人会不断爬起来继续向前，澳大利亚队是如此，西班牙队也是如此。我想真正的成熟应该并不是追求完美，而是直面自己的缺憾，这才是生活的本质。罗曼-罗兰说过：“这个世界上只有一种真正的英雄主义，那就是认清生活的真相并且仍然热爱它。”

这一段解说的视频版见：

https://www.bilibili.com/video/BV1cf4y1X7w2

接纳自己的不完美，直面缺憾，热爱生活。

#推荐

B站上纯纯甘的节目《浮生一日》是我每期都会看的节目，主题是每次采访跟踪一个不同行业素人的生活：

https://space.bilibili.com/110930331

最开始知道这个栏目是看了《国企外卖小哥的一天》，背景是这位小哥由于疫情原因失业，所以找了一份国企的工作；媳妇买P2P赔光了积蓄，赶上老人得病要治疗，所以晚上得出来兼职跑跑外卖。

里面有句话让我感动：“结婚时面对自己媳妇儿最漂亮的时候，你说我愿意和你同甘共苦，然后现在又开始责怪她，那当初又何必说这四个字呢？”

https://www.bilibili.com/video/BV1V54y1h7Zr

这个栏目里还有各色不同职业的人：程序员、投资者、早餐摊位主人...等等。

不同的职业，都有各自不同的生活轨道和选择。

油管上有同名频道：https://www.youtube.com/channel/UCIs3-LcOCdpiGve6yu1-Fug

#项目推荐

之前已经清楚了b-tree大体的算法思想，最近想找一个简洁的b-tree实现看看生产级都是怎么做的，发现一个不错的项目：https://github.com/madushadhanushka/simple-sqlite

看介绍，作者把sqlite2.5里b-tree相关的部分代码抽取出来了，我编译运行了一下用例都能正常跑，代码量不过几千行，就从这里入手开始吧。

按照sqlite官网上记载的发布历史，sqlite 2.5是2002年6月的版本了：

https://www.sqlite.org/changes.html

附带博客里整理过的B、B+Tree算法原理：

https://www.codedump.info/post/20200609-btree-1/

https://www.codedump.info/post/20200615-btree-2/

#文章推荐

JuiceFS创始人的一篇文章，很同意里面的一句话：“互联网的人口增长的红利结束了，但是数据增长的红利还很足，而且应该能持续很久，甚至不知道会不会有结束的那天。”。前者表现在内卷越来越严重了，后者原因是场景（AI、智能）、上网设备（车联网、物联网）越多越多了。

https://mp.weixin.qq.com/s/AQk7dd2g0MDzYMdwmjzL5g

知乎上看到很好的一句话，“向别人学，跟自己比”，对我这样的后进生很有鼓舞作用。

https://www.zhihu.com/question/359652140/answer/1824572882

#博客

上个月写过一篇memcached的文章，最近项目实现了cache库之后，发现很多细节当时理解的并不够细致，于是重新又写了一篇memcached的文章：

https://www.codedump.info/post/20210812-memcached/

这次将slab、分段LRU、读写操作中的锁、安全回收item、hash表的扩容操作等都讲到了，希望以后也不需要再写memcached的文章了。

总体感觉是实现一个多线程安全且高效的cache库还是有不少细节要考虑的，细节是魔鬼。

#职场

跳槽时的薪水，由什么因素决定？

你自身的能力（水平、资源、学历等），肯定是决定因素之一，这已经是共识，不再多说。除此以外，跳槽的薪水，还取决于你当前工作的薪水，因为跳槽薪水还有一部分因素是“给你多少钱能让你离开现在的工作”。

水平能决定你是否满足这份工作的要求下限，而现有薪水能决定你在满足要求下限之后，拿到这份工作薪水范围的哪个点。

以一个例子来说明，假设一份工作的薪水范围是1W~2W。同样满足这个工作要求的两个人，一个人现有薪水8K，另一个人10K，假设至少都要涨薪5成才够跳槽吸引力，那么8K的人只需要给12K，而10K的人则需要15K了。讽刺的是，大部分情况下这两人的水平差距也许并没有8K和10K的差距，而仅仅由于上一份工作的薪水就能决定多少钱能挖的动ta了。

因此，跳槽时的薪水溢价，有相当一部分来源于“多少钱能让你离开现在的公司”。

当然，一份工作的吸引力，除了待遇还有别的维度，可以回看前面的文章《选择的维度》，在这里只谈论待遇这个维度。

Channel photo updated

#博客

因为博客里都是很硬的技术文章，于是想慢慢写一些非技术的文章，这是第一篇《选择的维度》：

https://www.codedump.info/post/20210803-choice-dimension/

简单介绍了做选择时的一些方法论，简而言之：做选择时要精简出最重要的几个维度以及划分维度的权重。

#推荐

DeepL是由德国一家AI创业公司的推出的翻译服务，主打使用人工智能、深度学习技术来进行翻译服务，支持 简体中文、英语、德语、法语、日语、西班牙语、意大利语、荷兰语及波兰语之间的翻译。

我自己尝试了一下这个翻译工具，将我博客的一篇中文博文翻译成英文，几乎不加修改就能比较顺畅了：

《如何阅读一份源代码？（2020年版）》 https://www.codedump.info/post/20200605-how-to-read-code-v2020/

《How to Read Code(En Version)》 https://www.codedump.info/post/20210215-how-to-read-code-en/

感觉对于技术类文章的翻译来说，这个工具的表现已经很好了。

Mac、Win桌面版可以免费下载，也有网页版本，但是免费版本有每次翻译的字数限制，文章长了需要自己多倒腾几次：https://www.deepl.com/translator

#博客 #分布式 #Raft #etcd

之前对etcd raft的wal、快照部分理解的不够深入，导致一些问题理解的不到位，于是单独整理了一篇这部分的分析：

https://www.codedump.info/post/20210628-etcd-wal/

看完之后应该能回答这个问题：follower节点是在收到leader节点的日志广播之后，还是在日志达成一致之后，才将日志落盘到WAL的？为什么以及恢复流程是怎样的？

写完这篇博客之后，发现我已经写了5篇raft、etcd的文章了，其中第一篇是纯的raft原理篇，其余4篇都是结合etcd来分析其raft实现的。


我应该不用再写etcd的raft实现分析文章了吧 🙂 #flag

旧金山大学制作的系列算法可视化交互动图，包括常见的堆、栈、队列等。学习算法数据结构的时候，如果能图示化的展现其变化过程，理解起来就会更顺畅，在学习B+Tree算法的时候，我就用过这里的演示来理解流程。 https://www.cs.usfca.edu/~galles/visualization/Algorithms.html #推荐 #算法 #数据结构