月记：2025-05

本文最后更新于：2025-06-30

五一黄金周，为什么假期都这么短呢

文章结构

输入
Learning：书/小说/优秀文章，视频/播客，不限形式，感觉看完有收获的内容
Anime：新番/老番，TV版/剧场版，记录一下自己看的动画
Others：电影、电视剧等，归入其他
胡思乱想
也许会记录一下所思所想
输出
也许是 Blog，但水平太菜，也许一个月都没什么输出（
游记
有去哪里玩就记一下，没有就算了
杂
不属于上面任何部分的零碎事项

输入

Learning

Astro Tutorial: Build a Blog

准备迁移博客框架，从 Hexo 改成 Astro

为什么选择 Astro

对目前的 Hexo 并没有什么不满，只是最近想学习前端，又正好看到 Astro 这个框架
起因是前几周看到一篇博客 maple3142 - 把部落格從 Hexo 遷移到 Astro，详细介绍迁移到 Astro 的过程，~~看完感觉我也行了~~
之前也有看到过几个用 Astro 的博客，体感非常顺滑，点开页面底部链接一看，是 Astro，例如 Frost’s Blog（默默把 Astro 记在了心里）

官方文档 Astro Docs - Why Astro？说 zero JavaScript by default，只有 HTML + CSS，所以天然速度快
除了这个，最吸引我的是 Astro 不仅可以用自己的 component，还能混合使用多个前端框架，如 React, Preact, Svelte, Vue，甚至可以做到每一个 component 使用不同框架，不需要被绑在一个生态里，方便迁移（~~岂不是能在一个项目里把 React、Vue、Svelte 学个遍吗，这可太厉害了~~）

Start with official tutorial： Build a blog

Astro 官方教程 Tutorial： Build a blog 手把手教你搭建一个静态博客
跟着教程做一遍应该就差不多会了

我把成品放在了 GitHub 上： KassadinL - astro_tutorial，相比官方教程增加了 Mermaid diagram 支持，可以在 Markdown 里直接用 code block 画图，非常优雅（

YouTube 原子能

上面提到 Astro 默认 zero JavaScript，所以非常快，正好最近在 YouTube 上看到一位技术博主的视频

在你不知道的角落，前端的未来正在回归本源【让编程再次伟大#27】
视频里提到前端近年来的趋势是回归 HTML CSS JS，抛弃各种抽象层，使用原生 WebAPI
JavaScript 语言近来也有许多便利开发的提案，例如 Temporal 原生时间处理库、Signals 同步数据变动，最小化重新渲染

还有一些新方向的前端框架
- Svelte，用原生接口取代 React、Vue 的老一代接口（例如 React 的 Virtual DOM）
- Lit，使用原生 Web Component
- Htmx，5000 行 JavaScript 实现一个前端框架（好像思想有点超前，具体不清楚）

感觉这个作者讲的比较有意思，陆陆续续看了他的其他视频，收获良多
最重要的感受是，程序局部的算法/优化没有那么重要，把眼光放在架构层面，能做的优化更多，效果显著
更进一步，能够理解业务，了解市场，就可以主导项目，反向管理 or 影响甲方，这样才是最好的

记几个印象深刻的视频

那些年，那些学了也没用的知识【让编程再次伟大#5】

算法/优化并没有那么重要，因为最初的架构设计就已经决定了性能上限
甚至视野放大到整个公司，代码更是无足轻重，业务/市场等能拿到真金白银的才是重点
~~只要能卖出去，就算产品做成一坨屎，别人也得捏着鼻子吃这坨屎~~（例如慢如蜗牛的 Snowflake）

作者还举了个例子：如果有一个 100GB 的日志要分析，最佳做法不是用什么 “先进的” 分布式 log 分析系统，而是直接买一条 128GB 内存条，全部读进内存处理
后一种做法架构简单，方便维护，另一方面，公司财务也会喜欢这种方式，因为 128GB 内存条可以记入资产
上面那张性能图，在另一个地方也看到了类似的讨论：Telegram - codedump 的电报频道
Andrej Karpathy 的一条推：
A major mistake I made in my undergrad is that I focused way too much on mathematical lens of computing - computability, decidability, asymptotic complexity etc. And too little on physical lens - energy/heat of state change, data locality, parallelism, computer architecture. The former is interesting; The latter bestows power.
（我在本科阶段犯的一个重大错误是过于关注计算的数学视角——可计算性、可判定性、渐近复杂性等，而太少关注物理视角——状态变化的能量/热量、数据局部性、并行性、计算机架构。前者很有趣；后者赋予力量。）

简单聊一聊我的理解。
数学视角，常见的就是算法视角，例如各种算法时间复杂度、空间复杂度的分析就属于数学视角。物理视角，考虑存储介质的特性、数据分布的局部性，我举几个例子。
- LSM类的存储引擎，写入WAL就认为写入成功，这利用了append操作比随机写操作更快的物理特性；
- btree类存储引擎，以页面（page）为最小存储单位，读写的时候以页面为单位，既利用了批量读写数据的特性，又利用了数据的局部性。
Jeaf Dean常说的各类存储的延迟数据，也是物理视角。
通常会发现，一个算法即使数学上很好，但是如果不考虑物理特性，也会丧失它的优势。
为什么程序员都应该学用容器技术【让编程再次伟大#26】
k8s 是个好东西，去学
为什么关系数据库的挑战者都没有好下场【让编程再次伟大#25】
关系型数据库江山稳固，去学 pg
MongoDB 是「数据库行业头号诈骗犯」，远离 MongoDB

SICP

第三章大部分看完了，还剩最后一点 streaming 的部分

这一章终于讲到了常见的 Object-Oriented Programming 即面向对象编程，在前两章的 Functional Programming 基础上引入 status，通过 assignment 操作 mutable variables，把 输入一致情况下，输出肯定一致 的程序变成 根据程序运行状态不同，输入一致的情况下，可能会得到不同输出 的程序
相较于函数式编程，面向对象的方式能做到更多事情，but….这是有代价的
原本行为非常固定的程序，根据不同状态，每次执行都可能得到不同的结果，程序的行为变得难以预测（感觉这章很多篇幅都在讨论如何控制 status 不至于引起混乱）

读到后面我都有点疑惑：面向对象编程带来的那些好处，似乎远远无法抵消其引入的复杂度以及处理这些复杂度所花费的时间精力
也许是因为我现在没有写过什么大型系统的原因，难道是项目复杂到一定程度就不适合 functional 的方式，只能 OOP 了吗？目前我的经验太少，还无法做出判断
不过我 2023 年开始接触编程，读 Eloquent JavaScript 和其他一些资料时，大家都在强调 immutable variables 和 no side-effect

普通的学习路线，不管是学校还是培训班，应该都是从 OOP 开始（而且大概率也只会教 OOP 了），大概是 OOP 比较容易想象的原因？
但是在 SICP 这本书里，却是一开始就灌输 Functional Programming 和 recursive，我甚至都没有注意到前两章中 variable（变量）没有变 这个在函数式编程里非常重要的东西
直到第三章引入 status，变量才真正成为 mutable variable

所以在 SICP 中，Object-Oriented Programming 反而是比 Functional Programming 更 “复杂” 一些的概念，与传统观念里「函数式编程非常抽象，不容易理解」的印象完全相反
这一点我觉得还挺有意思的

说到 OOP 的缺点，顺便想起来之前在 Eloquent JavaScript 里面也提到不要滥用继承
因为面向对象编程中常见的 继承 加强了模块之间的联系，继承一个 class 时，你必须详细了解父类 class 的内容，违背了黑盒（black box）的思想
而 封装（或者叫抽象） 和 多态 都可以减少模块间的联系，让我们可以不用关心黑盒的内部细节，只了解如何使用这个黑盒就可以

Inheritance allows us to build slightly different data types from existing data types with relatively little work. It is a fundamental part of the object-oriented tradition, alongside encapsulation and polymorphism. But while the latter two are now generally regarded as wonderful ideas, inheritance is more controversial.

Whereas encapsulation and polymorphism can be used to separate pieces of code from one another, reducing the tangledness of the overall program, inheritance fundamentally ties classes together, creating more tangle. When inheriting from a class, you usually have to know more about how it works than when simply using it. Inheritance can be a useful tool to make some types of programs more succinct, but it shouldn’t be the first tool you reach for, and you probably shouldn’t actively go looking for opportunities to construct class hierarchies (family trees of classes).

Anime

末日后酒店
cy 王朝，脚本和制作都凸显游刃有余
第 6 话太神了，浪漫且克制，非常喜欢这种做法
Summer Pocket
看到第 6 话，制作还行吧，虽然还是有点仓促，剧情进展太快
时光流逝，饭菜依旧美味
看了两话，还可以
忍着与杀手二人组
看了几话，但好像没有继续看的动力
高达 GQuuuuuuX
TV 版一点没看（
mono 旅
360 相机已就位，~~所以一起出去玩的小伙伴去哪里领？~~
Witch Watch
看了一点，有时间再看吧
ざつ旅
看了两话，但感觉没意思，不看了

Others

最近看的电视剧/电影，点评尽量不涉及剧透

無名の人生

小众动画电影，没太看明白，特别是后段唐突近未来、科幻，而且我对 idol 题材不太感兴趣

胡思乱想

现在的这份工作，钱没几个，技术无法提升，还占据了我大部分时间精力
上班实在是太亏了，但为了签证，这个移民监是不得不坐啊….
太难了

输出

Astro Tutorial

如开头所说，做完了 Astro 官方教程 Tutorial： Build a blog，搭建一个练手用的静态博客
成果放在 GitHub ： KassadinL - astro_tutorial
相比官方教程额外支持 Mermaid diagram，可以在 Markdown 里直接用 code block 画图

接下来准备把博客正式迁移到 Astro
先找一个差不多的 theme 迁移过去，细节之后再完善吧
不然已经拖了这么久，再拖就真的不知道什么时候才能完成了