#网站

搜韵网，收录了诗词、诗人地域分布、一生轨迹等，比如苏东坡的轨迹：
https://sou-yun.cn/PoetLifeMap.aspx?author=%e8%8b%8f%e8%bd%bc

#文章
早上起来，翻知乎读到姚勇的一篇文章：

《软件技术人员的瓶颈，为35岁之后做准备》

很同意里面的一句话：“我发现对一个程序员最大的阻碍，就是一种对解决问题极限难度的感受。 他决定了你最差的情况。或者收入。这个很有可能和性格有关。半天生。”

这个素质天生与否不好说，但是同意前半句面对难题的态度决定了这个人在技术方向上的走向。

BTW：姚勇是前水木清华成员，作家王小波的侄子，主业现在应该是游戏公司的老板，可以看看百度百科对他的介绍。

#书单

Rust打造的KV库 sled 作者的 推荐书单，不得不说里面好些书都没听过，即便听过也没有读过，其中很多主题是关于调试、软件检测的，马克一下。

#数据库

《数据库学习经验杂谈（长期更新）》，列举了数据库学习相关的很多资料。

#文章
上周有感而发写了一条推：

“人际交往里，“兼容”别人最好的人，可能是最被忽视感受的那个人。

软件也是一样，越能容忍用户输入、需求的，最后虽然用户面更广，但是要处理的各种边界条件也更多，而且口子一开难以收敛。

有时候大胆说个“不”明确一下边界，不见得就不好。”

下面的回复里有人推了这两篇文章：

《复杂度是不灭的，只会转移，难道一切都是徒劳的吗？》
《架构设计-复杂度是不灭的》

【趣文】用 Rust 收获 HATETRIS 的世界纪录

世界上有一款俄罗斯游戏的变体，叫做 [Hatetris](https://qntm.org/files/hatetris/hatetris.html) （“可恶的俄罗斯方块”，亲自去玩一下就知道这个版本的俄罗斯方块有多么令人抓狂，我最多消了三行。。），号称世界上最难的俄罗斯游戏，是由程序员和科幻作家Sam Hughes于 2010 年编写的俄罗斯方块版本。曾经的世界纪录也只能做到消去32行（32分），然后在去年被一个日本选手 knowjade 推到了66 分。 现在这个分数已经被(痴迷于一个问题并付诸实践且刚学了几天 Rust）的两个开发者给推到了 86 分高分。

该团队最初选择了三门语言来实现：Mathematica、python 和 Rust。

Mathematica 平均每场比赛耗时 4.3 秒，Rust 平均每场比赛耗时 0.035 秒。这是一个如此大的差异，所以该团队认为与 Rust 的借用检查器进行谈判的所有麻烦和斗争都是值得的。

他们尝试的实现：
- MCTS（蒙特卡洛树搜索）是游戏模拟中的一条行之有效的路径。核心理念是将游戏中的每一步都变成树状结构，然后探索树。然后他们从树搜索重构为 DAG 搜索，产生了可喜的结果。（MCTS 中的“Graph vs Tree”实际上是这个专业圈子里有争议的，并有相关论文）
- 他们尝试 rust + pytorch-c绑定制作了AlphaHATETRIS，但是失败了
- 实现了一个模拟器，然后受 knowjade 写的相关文章启发，使用了 heuristic beam search （启发式光束搜索，https://gist.github.com/knewjade/586c9d82bd53f13afa8bcb7a65f8bd5a），但是他们得到的分数是 53 分，而不是 knowjade 的66分。
- 从图论中得到启发，结合 heuristic beam search ，经过优化参数， 奢侈地使用了 aws 上的一个实例，然后花了56 个小时得到了 86分。一共花费140美元。

收获的教训：

- 学会了使用火焰图分析程序性能：字符串格式化代码占用总运行时间 17% ； 避免循环嵌套；使用 clone() 解决借用问题，但并没有花费什么时间成本，因为编译器将它们优化掉了。
- 切换数据结构。他们需要一个读取速度和插入速度都比较平衡的数据结构，所以从 Vec（读O(1)， 写O(n)） 换成了 BTreeSet （读写都是O(log(n))）。
- 再多的优化代码都不会消除对机器学习硬件的荒谬需求。不管你的模拟器有多好，你玩游戏的速度有多快……大量的训练数据和所需的训练时间使得尝试解决消费硬件上的复杂问题变得非常具有挑战性。

这篇文章涉及很多算法细节，感兴趣的可以点击原文阅读

https://hallofdreams.org/posts/hatetris/

#游戏技术

前阵子，看到一篇文章讲述游戏技术在各领域的应用：《游戏技术已成为一个国家技术创新能力重要标志》。

正好最近看到一部纪录片《青年理工工作者生活研究所》里面有一集也讲了 游戏技术的应用。

N年前刚开始从业的时候，看了一本书《DOOM启示录》，详细讲述了卡马克、DOOM、QUAKE的故事，那时候就对做“游戏引擎”很感兴趣。可是自身基础差、从业机会少等各方面原因，最终还是没能如愿。

尽管未能相关从业，并不影响《DOOM启示录》在我心中的位置，书中有卡马克有一句名言：“在信息时代，进入编程领域的壁垒完全不存在了。即使有也是自我强加的。如果你想着手去开发一些全新的东西，你不需要数百万美元的资本。你只需要足够的比萨和健怡可乐存在你的冰箱里，有一台便宜的PC用于工作，以及让你坚持下来的奉献精神。”。这段话对我这样的技术宅男来说可谓有很大的激励作用。

（英文原文：“In the information age, the barriers [to entry into programming] just aren't there. The barriers are self imposed. If you want to set off and go develop some grand new thing, you don't need millions of dollars of capitalization. You need enough pizza and Diet Coke to stick in your refrigerator, a cheap PC to work on, and the dedication to go through with it. We slept on floors. We waded across rivers.” 见 维基百科的卡马克页面）

BTW1：说起“游戏引擎”这个技术，算是游戏开发领域的掐脖子项目，国内几个最好的游戏公司，好像也只有网易有自研并落地到项目中使用的自研游戏引擎，只是因为未开源以及没有在外部使用，所以并不太为人所知，可以看这些文章的介绍

*《专访网易Messiah自研引擎领衔者：“做真正made in China的游戏”》
*《8年时间，29款产品，揭秘网易自研引擎的背后故事》

BTW2：为什么腾讯这么有钱，却没有去自主研发“游戏引擎”这类卡脖子的技术？答案是有钱，买就完了。当前世界上最流行的两款商业级别的游戏引擎，Unity和Unreal，背后都有腾讯的投资。见：《Unity美股IPO，腾讯成大赢家：一文带你了解游戏引擎》。（补充：据知乎的这个问题记载，腾讯是有自研引擎并得到应用的《如何评价腾讯的QuicksilverX游戏引擎？》）

BTW3：通常聊到“游戏引擎”，很多人都会认为只有图形图像引擎才被称为“游戏引擎”，实际上也存在服务器端的“游戏引擎”。基于服务器的游戏引擎，开发者通常只需要写脚本层的业务逻辑即可，网络收发、数据库访问、自动的负载均衡等技术都在引擎底部实现了，比如“BigWorld”这款服务器引擎，曾经创下过最高在线玩家数的世界纪录。

我的上一份工作还在游戏行业，如果当时能给我去做服务器端的游戏引擎，可能不会离职离开这个行业。之前的周报里也写过一篇游戏服务器技术的文章：《周刊（第3期）：一个前游戏开发者眼中的游戏后端技术》。

#文章
https://architecturenotes.co/ 这个网站有几篇不错的图解科普类的技术文章，比如：

《Redis Explained》
《Things You Should Know About Databases》

#项目
Databend v0.8版本正式发布：这个版本历时5个月，全球120多位贡献者参与，5000+ commits， 4600+ file changes，新增420K行代码，160K行代码被删除，几乎把Databend每个模块都迭代了一遍。新的调度器、新的执行计划和优化器、完整支持复杂的JOIN和子查询(TPC-H)，让Cloud Warehouse更加Cloud。Databend v0.8 release:

《What's Fresh in Databend v0.8》 Databend项目地址：https://github.com/datafuselabs/databend

#八卦
前两天的有关游戏引擎的推送里，评论区提到了腾讯的Milo。很多人知道他，都是因为他的开源项目、知乎上的回答、翻译的书籍。

实际Milo在这之前，就以一种很意外的方式出现在中文技术圈里过。

这是2010年的一篇关于《0 bug--C/C++商用工程之道》的书评《有点失望》，大体过程是Milo在这篇书评里指出了这本书的很多错漏，但是作者并不接受随后也一口咬定Milo及之后其他批评他的人都在故意抹黑他，进而引发了当时中文技术圈的一场声势不算小的讨伐。

这个事情当时的围观群众很多，也让人们认识了当时不知道哪里冒出来的Milo，再过了几年Milo就入职腾讯、开源RapidJson、翻译《游戏引擎架构》一书，这些都是后话了（我才发现Milo的知乎账号已经停用了）。

Milo自己关于这个事情的一个记录：《《有点失望》的经过及其背后意义》。

我后来也写过一本书，如果有一天被人公开指出各种错漏，不知道到时我该怎么应对。所以当写过一本书之后，真心体会到“心智成本”是非常高的，因为别人付费买了你的产品，就不能出现纰漏，何况是纸质出版物这种印刷出来了就很难修改的输出品。所以我现在不太想写书，时间、心智等等成本太大，除非有特别想写的主题，怕是以后都很难写书。还是写写博客好，读者不付费就能看我大可以抱着“爱看不看”的态度，而且有错误了修改起来很方便，更重要的是以这种方式来学习，反馈路径短更有利于整理学习知识。

#播客

《EP 15. 【硅谷连线回放】中美基础软件与开源创业市场：实践，异同与机会》

这个叫“OnBoard!”的播客节目，播主是投资机构专注基础软件领域的投资人，所以聊到的领域和我现在工作的领域很接近，这一期请到了PingCAP的创始人一起聊基础软件的创业等话题。

#分布式

jepsen官方教程，一步一步讲授如何给etcd服务写jepsen测试：

https://github.com/jepsen-io/jepsen/tree/main/doc/tutorial

#杂
去年12月因为新工作要使用Rust，于是买来两本Rust编程的书开始学习：

《Rust权威指南》和《Rust程序设计》。

我记得当时离职之后有个一周左右的空窗时间，就把这两本书看了个大概，直接到新工作开始干活，边干边加深对Rust的理解。

前两周整理出给多抓鱼的闲书，于是把第一本出掉留下了第二本，正好今天推上一位朋友晒图说在多抓鱼刚好收了我出的这本书。

我回想了一下就学习一门知识的步骤：

1. 找一两本这个领域的书籍来阅读。这个流程不能太长，尽量控制在一个月以内，也不要求面面俱到。这个阶段的目标是：对这门知识的大体结构有了了解，掌握最常用的用法。

2. 上手实践。遇到有难以理解掌握的知识就累积起来，找一个大块的时间做一个总结归纳。我的周刊里有写过Rust并发相关的一篇文章，就是这第二步的总结：《周刊（第19期）：Rust并发安全相关的几个概念(上)》。

3. 了解这个知识领域常用的搜索工具，知道在哪里可以快速找到答案，以Rust而言最好的工具就是浏览器插件：Rust search extension。

4. 有了知识体系、实践、知道怎么搜索，这时候实际上书的重要性进一步下降了，因为很多时候我已经知道怎么查找答案了，这也就是为什么会把这本书二手出掉的原因之一，另一个原因是对比起《Rust程序设计》来说，权威指南有点浅了，所以我宁可先留着《Rust程序设计》。

当然回想起来，能快速使用Rust开始干活，也是拜其他工具所赐：

* Rust Analysis插件、Rust编译器都能给出更好的报错信息，“教”我如何写好Rust代码，出错的时候告诉我哪里错了该怎么改。
* 我换了性能更高的笔记本（M1、64G内存），这样编译速度更快，这些编译工具也就能更快的提示我了。

#杂
我记得大概是去年这个时候，由于前公司要重构一下存储元数据的存储引擎，开始研究怎么实现一个轻量级的存储引擎。

当时想研究一下市面上的B+Tree版本的存储引擎，可是有的项目很大（Innodb、WireTigger等），有的项目就是个玩具，只能演示原理做不到生产级别。这段时间可以说压力很大，印象最深的是当时去北京团建外出到景区，当天凌晨有世界杯亚洲区预选赛澳大利亚对中国，睡不着就一边看代码一边听比赛。

这时候偶然看到的一个精简的2.5版本的sqlite btree库，只有几千行代码，这个简单的实现打开了理解生产级B+Tree实现的大门。

在这之后就是“顺势”看了更高版本的sqlite btree实现，这些故事都写在了：《sqlite3.36版本 btree实现（零）- 起步及概述》。

仅就“生产级B+Tree”实现而言，sqlite的实现虽然还是有各种问题：比如效率不高等，但是都向我展现了总体的实现思路，后面再看这方面的实现也有了基础，比如今年研究了ARIES这篇论文，最近还在看BW-Tree的论文。

现在一年时间过去了，我又开始探索一个新的领域：Jepsen，想在项目里使用上这个项目来验证我们系统的实现，初期仍然跟以往自己独立研究一些问题一样遇到很多困难，因为太多新的知识点没有接触过：Clojure、模型检验（Model checking），等等。

回头来看，很多我后来看来获得技术上很大成长的时候，都是这种独立、深入研究某个领域之后带来的：身边没人请教、自己找答案、深入阅读文档、代码，等等。这样的经历多了以后，对这种压力似乎也感到适应，对压力之后的收益也清楚，甚至对解决这些难题有一些期望了。

#杂
程序员始终逃不过所谓的“35岁年龄问题”（有可能这个问题过了几年又变成了40：）

我今年已经40了，而且：

* 我是从大学一毕业就开始做程序员的。
* 从来没有做过一天的管理，从来的身份都是“工程师”，未来也不想转方向。
* 我非常喜欢写代码，未来打算一直写代码到退休。

尽管如此，仍然有很多其他人可能关心的问题，我解决（解答）不了：

* 如何做到“财富自由”？（我工作这些年也没有达到，还欠了一屁股的债，惭愧：）
* 程序员如何转管理？（没想过，和代码打交道比跟人打交道轻松多了：）
* 如何成为“技术大牛”？（别问我，我不是，你认错人了：）
* 如何确保学习的技术永不过时？（空气凝固了：）

....

以上这些别人关注的问题，有些我不关心，还有一些确实是能力所限解答不了。

而且我还有可能将来某天面对这样现实的问题：

* 假如某天我失业了，如何确保一定能再找到一份程序员的工作？
* 新知识你要是学不动了，该怎么办？

....

无法回答。

我对这些现实问题的处理方式就是等真的有问题了再来处理吧（懒惰是程序员的美德之一）。现阶段能做的就是做好工作、在所在领域保持学习。

我这样的“大龄、非成功程序员样本”，可能对陌生人的意义，更多的在于：当你开始问所谓的“35岁年龄问题”时，不妨可以看看我这个“异常样本”。

虽然是“异常样本”，虽然可能不太具备参考价值，也不是“标准答案”，不具备“可复制性”，但是由于我相当多的输出都在网上可见，所以总归可能对所谓的“35岁年龄问题”提供另一种角度和思考。

至于什么角度、如何思考，这就见仁见智了。我只提供事实，不参和观点和评论。

以上。

#科普视频
前阵子推荐了腾讯视频上《青年理工工作者生活研究所》这个节目，今天在B站发现其中两部视频：

《万字解析：今天的游戏技术究竟发展到了什么程度？》
《为了搞明白美颜这件事，我给自己做了 5 张脸》

这两部视频是关于游戏技术和人工智能技术在美颜方面应用的很好的科普视频。

https://github.com/rui314/chibicc

一个C语言编译器项目。为了让读者可以从头到尾清晰地理解项目演进的过程，作者非常用心地编排每一次的commit。虽然这是一个挺“玩具”的编译器，但是已经可以对一些项目进行编译了，这些项目包括Git、SQLite、libpng，它甚至也已经实现了自举。

挺有意思的。

#杂
这个动图通过物理的实验演示了一下有的时候最短路径并非最快路径。

数学里有一个结论“两点之间直线最短”，可是注意了这个说法里只说“最短”，并没有说一定“最快”。

以前总以为很直接的做一些事情能够最快得达到目的，因为背后有这个直线最短的理论支撑（理工傻直男）。

经历很多捶打之后，慢慢理解一些事情要圆滑、妥协、曲线前进，因为假如你非得走所谓的“直线”，路上的阻碍不见得一定比绕点弯路就少。

回过头看这个动图里的演示，才恍然大悟：其实“长短”更多是一个数学上的概念，只交待了距离维度而没有时间维度，“快慢”则是物理上的概念。用各自领域来解释都没错，错在了自己看问题的维度不够。

#杂
《详解 OpenDAL ｜Data Infra 研究社第三期》

由于Databend是一个面向多云环境的云数据库，所以数据需要支持保存在不同云厂商的对象存储里，另外测试的时候也有类似于写入本地fs等的需求，于是需要一个通用的数据读写层来抽象数据在不同存储介质里的读写操作，这个项目就是OpenDAL（DAL，“Data Access Layer”的缩写）。这个项目有挺高的社区活跃参与度，比如前两天有人提交了读写ftp的支持。

本期的Data Infra 研究社OpenDAL的作者xuanwo老板将介绍OpenDAL的实现等内容。

#八卦

《当年 1.6 亿美金估值的公司—— Digg 是如何被一句 Python 函数可变默参毁掉的》

来源于对文章《Digg's v4 launch: an optimism born of necessity.》的整理。

这个故事也太戏剧了。

按说查一个Python服务的内存泄露应该不难，另外即便一时半会解决不了也还是有别的办法顶一下的，说到底是技术不行？

#推特
作者用推特thread简单总结阐述了现在主要的经济观念，由于这个领域我不懂，于是就只是纯转发做了标记以后看到相关的可以回顾一下。

https://twitter.com/myanTokenGeek/status/1564855220617695232
BTW：作者孟岩是以前CSDN上很出名的那位孟岩，早年知道他还是《程序员》杂志刚创办的时候，现在CSDN的 博客 还在。