爱生活，爱自己

看到墨问便签上有小伙伴分享了一段话，个人非常喜欢，必须摘录下来：

当我真正的开始爱自己，我睡得越来越早，也越来越喜欢锻炼。我不再纠结和焦虑，变得自信满满，去追求有意义的人和事情，并为之燃烧自己的热情。

我发现人生才真正开始，你永远不可能真正的去了解一个人，除非你穿过他穿过的鞋子，走过他走过的路，站在他的角度思考问题，可当你走过他走过的路之后，你连路过都觉得难过。

把时间分给睡眠，分给书籍，分给运动，分给花鸟树木，山川湖海，分给你对这个世界的热爱，而不是将自己浪费在无聊的人和事上。

当你开始做时间的主人的时候，你会感受到：平淡生活中喷涌而出的平静的力量，至于那些焦虑不安，自然都会烟消云散。我们有限的人生，为何不用有限的精力去热爱呢，去感受呢，去拥抱所有的快乐呢。

生活已经太多的坎坷与苦难，但是又充满着美好和希望，何不妨及时行乐，与自己和解呢。去靠近滋养你的人而不是消耗你的人，去听你喜欢听的歌，看你想看的电影，拍你想拍的照片，约你相约的人，做你想做的事情，任性一点，好运就多一点。

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

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

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

以前只知 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）来说，可维护性的价值更高。