啥都懂一点，痛苦少一点，比如要不要生二胎， 是不是必须得生一个儿子。

很多时候都是封建传统，可惜已经植入到了国人心中，尤其是落后的农村地带，这就是为什么教育如此的重要。在我们老家，很多人家为了生儿子，生了很多胎，甚至提前去查性别……

ε=(´ο｀*)))唉，如果懂点科学就好了，不用痛苦，也不用受罪。

以前只知 Navicat 香，却不知 JetBrains 出品的 DataGrip 也很香。

每个人的知识体系都只是知识图中的一部分拼图，我们都有盲区。

站在“巨人”的肩膀上，同样适用于日常生活。

4 月 29 号下单的 4k 显示器，第二天就到了，某东的速度还行。

很早之前就想买一台高分辨率的显示器，却迟迟未下手，其中一个原因就是怕笔记本散热不行，CPU 飙到 60 度，之前的 mbp 2016 款就是这样。

用了两天，发现 Arm Chip 很给力，CPU 没有发烧，温度基本没变化。所以，我有点后悔了，应该早买早享受。

市面上的 4k 显示器那么多，各种参数配置，看花了眼，选哪一款？同事说，他在 B 站看了很多评测，最后选了 ASUS PA279CV。我问了 AI 的意见，还是不知道 3000 块左右的预算买哪款。

既然同事都研究了那么多，为啥我还要再研究一遍，直接参考他的不就行？于是，看到评测里讲到了 PA279CV 的升级款 PA279CRV，心动了。

上某东看价格，却发现这两款的价格一样，这是故意让大家买新款吧。站在同事的肩膀上，省时又省力。

除了 CPU 不发烧之外，还有一点必须点赞，就是 USB-C 接口，既是转接线，也是反向充电线，香啊。可惜 65w 的功率有点低，不敢多用，怕影响笔记本电池寿命。

DDD 中有一个概念：防腐层（Anti-Corruption Layer）

防腐层是最具防御性的一种关系，简言之，就是指我们要在外部模型和内部模型之间建立起一个翻译层，将外部模型转化为内部模型。

但凡有可能，就要建立防腐层，将外部模型完全隔离开。

手欠，在个人笔记本上执行了 rm -rf ~ o(╥﹏╥)o

用打电话和电话留言来解释命令式编程和声明式编程，很形象，有点意思。

摘自范学雷老师《深入剖析 Java 新特性》：

传统的指令式编程模型，就像我们通常打电话一样。我们拨打对方的电话号码，然后等待接听，然后通话，然后挂断。当我们挂断电话的时候，打电话这一个过程也就结束了，我们也拿到了想要的结果。

而非阻塞的异步编程，更像是电话留言。我们拨打对方的电话，告诉对方方便的时候，回拨电话，然后就挂断了。当我们挂断电话的时候，打电话这一个过程当然也是结束了，但是我们没有拿到想要的结果。想要的结果，还要依靠回拨电话，才能够得到。

而类似于回拨电话的逻辑，正是非阻塞的异步编程的关键模型。映射到代码上，就是使用回调函数或者方法。

当我们试图使用回调函数时，我们编写代码的思想和模型都会产生巨大的变化。我们关注的重点，就会从指令式编程模型的“控制状态”转变到“控制目标”。这时候，我们编程模型也就转变到了声明式的编程模型。

如果指令式编程模型的逻辑是告诉计算机“该怎么做”，那么声明式的编程模型的逻辑就是告诉计算机“要做什么”。指令式编程模型的代码像是流水线作业的工程师，事无巨细，拧好每一个螺丝；而声明式的编程模型的代码，更像是稳坐在军帐中的军师，布置任务，运筹帷幄。

Lens - Kubernetes IDE 感觉不错，刚刚使用上，有点后悔没早发现。

为啥之前没想过会有 Kubernetes Client 这种东西呢？思维局限了。

当 docker push 到 Docker Hub 一直失败时，可能不是你脚本写错了，而是你没充钱 🐶🐶🐶

• buildx failed with: ERROR: failed to solve: failed to push xxxx/xxx:xxx: server message: insufficient_scope: authorization failed
• denied: requested access to the resource is denied

异常处理：代码的可维护性 vs 性能

对于编程语言中的异常处理机制，范老师在课程中说：

C 语言时代的错误码，和 Java 语言时代的异常处理机制，就像是跷跷板的两端，一端是性能，一端是可维护性。在 Java 诞生的时候，有一个假设，就是计算能力会快速演进，所以性能的分量会有所下降，而可维护性的分量会放得很重。然而，如果演进到按照计算能力计费的时代，我们可能需要重新考量这两个指标各自所占的比重了。这时候，一部分代码可能就需要把性能的分量放得更重一些了。

对于这道题，Java 选择前者，C/Go 选择后者（当然，Go 做了优化，通过设计多值返回，解决了 C 中返回值一值多用的弊端）。我个人也觉得，对于大多数业务系统，以及 90% 的普通程序员（CRUD BOY）来说，可维护性的价值更高。

代码好看有啥用，在我们编译器和 CPU 眼里没有漂亮的代码，只有能跑的 0 和 1……😂😂😂

读这类书最大的好处，就是让你跳出来，从千头万绪意大利面式的代码中跳出来，以一个旁观者的角度来理解其设计思路，透视其底层逻辑。书中好多例子都是这样，掰开了给你看，比如进程，线程，日志，Spring，版本管理，消息队列，泛型，动态代理等。然后，你发出了 aha 的笑声，说：我好像懂了。

好像懂了，其实并没有懂，如何可以，像作者一样，用自己的话再把它们写下来，并结合程序示例演示。此时，你可能真懂了。

这本书买来时，快速看了最后两章，然后第一章翻阅了一点，再然后一年过去了……

最近重新打开，把前面几章快速翻完了，特定去查了一下，在某东上的下单时间是 2022 年 1 月 6 日，时间啊……

听说有第二季，期待。