#推荐

这次推荐投资人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

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

#博客

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

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

#冷知识

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

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

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

#推荐

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

http://www.redbook.io/

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

#推荐

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

早期，我使用的是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

#不推荐

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

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

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

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

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

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

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

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

遂，不推荐。

#杂

“
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

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

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

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

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

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

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

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

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

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

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

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

#推荐
这一次推荐一个人，看过他的文章和代码，以及现实中也算认识了，他更多混迹在游戏圈，圈外的人可能并不是太知道他。

网名skywind3000，他相关的链接有：

知乎：https://www.zhihu.com/people/skywind3000
github：https://github.com/skywind3000
博客：http://www.skywind.me/blog/
推特：https://twitter.com/skywind3000

skywind擅长的领域主要包括：游戏（引擎）开发、网络传输、音视频开发等。这几个方面，他是既有理论技术文章的输出，也有开源项目的，最出名的开源项目当属KCP：

https://github.com/skywind3000/kcp

我认真读过KCP的代码，就是我喜欢的那种风格：小巧精悍，扩展性高，仅有几千行代码量。

他是我认识的人里编码、理论水平都很高的人，推荐关注。

#杂
要么不说，要说就尽量说你真正想的话，是“维护成本”最低的一种办法，因为很容易就能跟你的行为保持一致，毕竟一直装是很难的。

想起来某大V，某次微博里面说：要尽量读英文书，中文都是二手知识。话是说的很漂亮，但是他本人就在某大平台卖课割韭菜。

于是我去回复了一句：你的课也是中文的。遂，被拉黑。

以Git分支的角度来解释一下“言行一致”为什么是“维护成本”最低的办法。

言、行好比是从你的主干分支里拉出来的两个不同的分支，如果出现不一致的情况，那么等到合并回去主干的时候都要解决冲突。于是，言行不一致的情况越来越多，解决冲突时就越来越麻烦，最后甚至可能出现就是解决不了冲突合并不回去的情况，这就变成了要维护超过一个主干代码的情况，所谓的难以“自圆其说”。

而言行一致，就是每次都不用解决冲突就能合并回去主干，你需要的只是维护一个主干的代码即可。这就是“维护成本”最低的办法。

做为一个普通人，幸运的是，我到现在为止还没有遇到不得不说违心话的时候，很多时候有一些我不愿意说的话，我会选择沉默，再或者直接回答不愿意说。当普通人，也是有好处的。

#推荐

输入用户名，找到你在Github上的第一次提交信息：

https://www.amitmerchant.com/your-first-commit-ever/

#推荐

这个页面里对GNU coreutils 8.3每个命令实现都做了详细分析，有整体实现分析图和具体源码解析：

http://maizure.org/projects/decoded-gnu-coreutils/

可用于初学者学习C语言、Linux系统编程时参考。

除此以外，我深度遍历了一下这个作者的其他文章，也是挺硬核的，比如：
http://maizure.org/projects/evolution_x86_context_switch_linux/index.html

作者自己把这一系列文章称为“Decoded”系列文章，我当初网名定为“codedump”，就是因为喜欢把“code”的原理给“dump”出来。

#杂
今天看到心动创始人黄一孟的推特：

“第一次和阿北认识是在十几年前的上海，当时和Mtime的马锐拉三个人约在徐家汇的一个星巴克里，商量如何把豆瓣、VeryCD、Mtime的电影资料用开放协议打通。
那是Web2.0的黄金年代，大家都认为开放是理所应当的，各网站各司其职拼凑起一个更丰富的互联网。无需登录注册的API、RSS、XML导出都是当年的标配。”

https://twitter.com/DashHuang/status/1468043778128711682

想起刺猬乐队《火车驶向云外，梦安魂于九霄》里的那句歌词：“一代人终将老去 但总有人正年轻”。

做为经历过那个年代的人，看到这段文字真是心情复杂。世界真的有在变得更好吗？我没有答案。

#推荐

最近几天，我在各种场合看到了PostgreSQL相关的赞美，比如：

https://www.infoq.cn/article/TKAkZijRFoRGCYrhBYtQ

再比如一位认识的朋友N年前在知乎的回答：

https://www.zhihu.com/question/20010554/answer/15863274

还有一位朋友，去基于PostgreSQL打造的GreenPlum团队面试之后，给出了很高的面试体验评价：

https://twitter.com/yihong0618/status/1467778716981817345

以前只是大体知道和听说而已，现在对PostgreSQL很感兴趣了，有时间也要看看这个神奇的数据库。

#杂

《礼记·中庸》：“正已而不求于人，则无怨，上不怨天，下不尤人，故君子居易以俟命，小人行险以徼幸。“

“正已而不求于人，则无怨，上不怨天，下不尤人”说的是我们学习君子风度，要严格要求自己，端正自己的言行，不去向别人乞求不属于自己的东西。人没有这种妄念，就不会产生怨恨。对上呢，不会怨恨老天不公平，对人呢，不会怪责别人对你不公平。

“故君子居易以俟命，小人行险以徼幸。”君子的“居易”并不是指居住简陋，而是指“居心”平正温和，“俟”是等待的意思。所以上半句是说，所以君子居心平正坦荡等待上天使命。天命来了怎么办，当然是抓住机会，一举成功。“小人行险以徼幸”，“行险”就是和“居易”相对应的行为，指把自己置身于险境。为什么小人要这么做呢？因为小人见识不够，看不到真正的机遇，总是心存侥幸，以为很多事情可以涉险过关。

#推荐
最近开始在学Rust语言，在知乎上看到一个回答：

https://www.zhihu.com/question/432640008/answer/2265793228

最开始吸引我的是这个答主的身份，按他的自我介绍是个警察，回答的开头也以“初心”、“使命”开头。

但是细读内容，可以说算是一个高质量的回答，尤其同意其中的一句话：“C++这个把一切可能出现的严重错误写到教科书里，就是不写在编译器里。”。这个对C++的批评，太到位了。

利用 log4j2 的任意代码执行漏洞在 MC 里运行 Doom
https://fxtwitter.com/gegy1000/status/1469714451716882434?s=20

#杂
最近工作又发生了很大的变化，某些原因让我不得不在今年内要做出第二次换工作的决定。

导致做出离职决定的过程很突然，也让我很意外，甚至是愤怒，我一度想在社交媒体上曝光整个流程来讨个公道。

经过大概一周左右的冷静思考，最终还是放弃了这样做的打算。往前走，专注在我的下一个目标上，而不是继续纠缠在以前的事情上。与之相关的，我已经在各种社交网络上删除了我能删除的所有与之相关的内容，以后不想再提及这个公司。能让我这么急切划清楚界限的公司，我工作了这么多年，应该是没有的。

整个思考过程中，最终我拿出来说服自己的依据是：如果做一件事情，仅仅只是为了解决情绪上的问题（比如讨说法、泄愤），而于其他事情无益，那么这件事情看起来就只有短期的作用，且于个人今后的事情无益甚至有负作用，这样的事情还是谨慎些，大概率是不能做的。

永远不要在情绪出现巨大波动（愤怒、低落）的时候，做出重大的决定。如果很难做到，这个时候提醒自己：先睡个觉，精神好了再想想。

补充一句：在我的频道里，只表达我想说、愿意说的话，我没有义务也没有责任，必须回答别人提的问题。我且一说，你且一听，就是这样。

#杂
最近由于某大厂员工的事件，抑郁症又回到人们的视线中。

以我个人以前的体验来说，情绪低落（轻度抑郁）的时候，与之相伴的总是失眠，失眠完了还要继续面对繁重的工作，恶性循环了。

让我真正从这里走出来的是，我意识到抑郁-失眠-抑郁是一个恶性循环，所以只要打破其中一个缓解就能发生改善。于是，后来再出现类似情绪，就首先保证自己的睡眠，什么都不做，早早睡觉。如果睡不着，就使用褪黑素来助眠。为了减少赖药性，给自己定一个时间阈值，比如凌晨一点还睡不着，就上褪黑素助眠。很快，这种情绪就得到了很大的缓解。

就这段经历和体会，我想说的是：

1、情绪低落时，优先保证睡眠，睡好了精神好了，再想别的事情。读书却并不见得是这种时候最好的选择，因为“读书”会带来很多外来的观点，这种时候更多的不是输入，而是休息。
2、推广开来，如果你不知道该做什么的时候（aka “迷茫”），就去锻炼身体和好好休息，这两件事情总不会有错。
3、永远不要在情绪发生异常波动（低落、愤怒）的时候，做出重大的决定。

#博客

这是一系列讲解sqlite btree实现文章的开篇（aka “第零篇”），讲述了我探索btree生产级实现的过程，以及概述了sqlite btree模块的架构。

如文中所言：“本系列文章就sqlite 3.36版本的btree实现展开描述，希望对那些和我一样对“生产级btree类存储引擎实现”有好奇心的人有一点帮助。”

文章最后有彩蛋。

https://www.codedump.info/post/20211217-sqlite-btree-0/

#杂

发现Github不知道啥时候开始，支持给star的项目自定义分类了，这样就方便后面回头查找，这个功能对于像我这样的用户来说挺友好的。