月記：2025-05

メーデー連休、なんで休みってこんな短いんだろう

文章構成

入力
Learning：本/小説/良い記事、動画/ポッドキャストなど形式は問わず、「見終わって得した」と感じるもの
Anime：新作/旧作、TV/劇場版など。観たアニメの記録
Others：ドラマ/映画など。その他に入れる
雑念
たぶん思ったことを書くだけ
出力
たぶん Blog。でも自分のレベルが低すぎて、1ヶ月まったく出力がないかもしれない（
旅行記
どこか行ったら書く。行かなかったらそれでよし
雑
上のどれにも入らない細々したこと

今の Hexo に特に不満はない。ただ最近フロントエンドを勉強したくて、ちょうど Astro というフレームワークを見かけた。
きっかけは数週間前に見たこのブログ：maple3142 - 把部落格從 Hexo 遷移到 Astro。Astro への移行手順がかなり詳しく書かれていて、~~読んだら「自分もいける気がする」になった~~。
それ以前にも Astro 製のブログをいくつか見たことがあって、体感がすごく滑らか。ページ下のリンクを見たら Astro だった、みたいな。例えば Frost’s Blog（ひそかに Astro を脳内メモ）。

公式ドキュメント Astro Docs - Why Astro? に「zero JavaScript by default」とあって、基本 HTML + CSS だけなので素で速い。
それ以外で一番惹かれたのは、Astro は自前コンポーネントが使えるだけでなく、複数のフロントエンドフレームワークを混在できること。React, Preact, Svelte, Vue… しかもコンポーネントごとに別フレームワークも可能。ひとつのエコシステムに縛られないから移行しやすい（~~1つのプロジェクトで React/Vue/Svelte を全部学べるってこと？強すぎる~~）。

Start with the 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 に回帰していて、いろんな抽象レイヤーを捨て、ネイティブ Web API を使う方向らしい。
JavaScript にも開発を楽にする提案がいろいろあって、例えば Temporal（標準の時間処理）や Signals（データ変化の同期）で再レンダリングを最小化する、みたいな話が出ていた。

ほかにも新しい方向性のフロントエンドフレームワーク：
- Svelte：React/Vue の旧世代 API をネイティブ寄りのインターフェースで置き換える（例：React の Virtual DOM）
- Lit：ネイティブ Web Component を使う
- Htmx：5000行の JavaScript でフロントエンドフレームワークを実装（思想が先行しすぎてて、正直よく分かってない）

この作者、結構面白い。断続的に他の動画も見ていて、学びが多い。
一番大きい感想は「局所のアルゴリズム/最適化はそこまで重要じゃない」。アーキテクチャ視点で見ると、打てる手が増えて効果も大きい。
さらに言うと、ビジネスを理解して市場を知っていれば、プロジェクトを主導できるし、上司を逆にマネジメントしたり、甲方に影響を与えたりできる。そういうのが一番強い。

印象に残った動画をいくつか：

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

アルゴリズム/最適化はそこまで重要じゃない。最初のアーキテクチャ設計が性能上限を決めてしまう。
会社全体に視野を広げると、コードはなおさら軽い。真にお金になるのはビジネス/市場など。
~~売れさえすれば、製品がクソでも、鼻をつまんで食わされる~~（例：カタツムリみたいに遅い Snowflake）。

例として、100GB のログを分析したいなら、「先進的な」分散ログ分析システムを使うより、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 がランダム書き込みより速いという物理特性を利用している。
- B-tree 系はページ（page）を最小単位にして、読み書きもページ単位で行う。これはバルクI/Oと局所性を利用している。
Jeff Dean がよく言う各種ストレージのレイテンシ指標も、物理的レンズの話。
数学的に良いアルゴリズムでも、物理特性を考えないと優位性を失うことがある。
为什么程序员都应该学用容器技术【让编程再次伟大#26】
k8s は良い。学べ。
为什么关系数据库的挑战者都没有好下场【让编程再次伟大#25】
リレーショナルDBは盤石。pg を学べ。
MongoDB は「データベース業界のトップ詐欺師」。MongoDB から離れろ。

SICP

第3章はほとんど読み終わって、最後に streaming のところが少し残っている。

この章でようやく一般的な Object-Oriented Programming（面向对象編程）が出てきた。前2章の Functional Programming の上に、state（status）を導入して assignment で mutable variables を扱い、「入力が同じなら出力も必ず同じ」だったプログラムを、「実行状態によっては入力が同じでも出力が変わりうる」プログラムに変える。
関数型に比べて OOP はできることが増える、but…代償がある。
もともと固定的だった振る舞いが、状態によって毎回変わるかもしれず、挙動が予測しづらくなる（この章は state が混乱を生まないようにどう制御するか、という話が多い気がする）。

読み進めるほど疑問が湧いた：OOP がもたらすメリットは、導入される複雑さと、それを処理するための時間/精神コストに見合わないのでは？
たぶん自分が大規模システムを書いたことがないせい。規模が一定を超えると functional が厳しくなって、OOP しかないのか？経験が少なすぎて判断できない。
ただ 2023 年からプログラミングに触れ始めて、Eloquent JavaScript などを読んでいると、みんな immutable variables と no side-effect を強調していた。

普通の学習ルート（学校でも講座でも）は OOP から入るはず（そしてたぶん OOP しか教えない）。OOP のほうが想像しやすいからだと思う。
でも SICP は最初から Functional Programming と recursive を叩き込む。前2章では「variable（変数）が変わらない」という関数型で重要な点にすら気づいていなかった。
第3章で state が入って、ようやく変数が mutable variable になった。

つまり SICP では Object-Oriented Programming のほうが Functional Programming より「複雑」な概念として扱われていて、一般的な「関数型は抽象的で難しい」という印象と真逆。これが結構面白い。

OOP の欠点といえば、Eloquent JavaScript にも不要滥用继承と書いてあったのを思い出した。
OOP の 継承 はモジュール間の結びつきを強める。ある 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話まで。制作はまあまあだけど、やっぱり少し駆け足で、展開が速すぎる。
时光流逝，饭菜依旧美味
2話見た。悪くない。
忍着与杀手二人组
何話か見たけど、続けて見る気力が湧かない。
高达 GQuuuuuuX
TV版は1話も見てない（
mono 旅
360カメラは準備OK。~~一緒に出かける友だちはどこで受け取れますか？~~
Witch Watch
少し見た。時間ができたら続きを見る。
ざつ旅
2話見たけど、つまらなく感じてやめた。

Others

最近見たドラマ/映画。できるだけネタバレは避けたい。

無名の人生

マイナー寄りのアニメ映画。正直よく分からなかった。特に後半が唐突に近未来・SFになって、しかも自分は idol 題材にあまり興味がない。

雑念

今の仕事、給料は少ないし、技術は伸びないし、それでも時間と体力をほとんど持っていかれる。
働くのは割に合わない。でもビザのためには、この移民監（足止め）は避けられない…
つらい。

出力

Astro Tutorial

冒頭のとおり、Astro 公式チュートリアル Tutorial: Build a blog をやり切って、練習用の静的ブログを作った。
成果は GitHub： KassadinL - astro_tutorial
公式チュートリアルに加えて Mermaid diagram を追加で対応した。Markdown の code block で図が描ける。

次はこのブログを本格的に Astro に移行する。
まずはそれなりの theme を探して移して、細部は後で詰める。
ここまで引き延ばしてしまったので、これ以上引き延ばすと本当にいつ終わるか分からない。

旅行記

江ノ島

本当は鎌倉に行くつもりだったけど、藤澤で降りて江ノ島電鉄に乗って、「江ノ島でちょっと降りて見てみよう」と相談した。

江ノ島電鉄、確かに写真を撮ってチェックインするのに向いてる。

平成元年。つまりこの車両は 1989 年製。
でも日本だと「古い」と言うのが少し恥ずかしい。まだ 36 歳だし、ちょうど最適化（リストラ）される年齢に入っただけ。

降りて適当に歩いていたら、近くに小さな丘があって、お寺の塔の先っぽが少し見えたので、そっちへ向かった。

翼の大きい鳥がたくさんいた。種類は分からない。

延寿の鐘。まだ叩き壊されてないのがすごい。

この小屋を見た瞬間、「小橋流水人家」が頭に浮かんだ。橋も水もないけど、静かな雰囲気がある。

この寺の印象は、とにかく庭が精緻で、植生が豊かで、すごく静か。~~山下の俗世から隔絶されてる感じ~~。
こんな景色はお金がかかるはず。和尚、金持ち（
寺を少し回って、江ノ島へ移動。

メーデー連休で、人、人、人。

中腹から見ると、橋の上も小道の中も人だらけ。

ぼっち・ざ・ろっく！ぼっちちゃん。

スライム形態のぼっちちゃん。

酒鬼。

ぼっち・ざ・ろっく！の絵馬がたくさんあって、後になって「あ、アニメでも4人組が江ノ島に来る回があったな」と思い出した。
ただ、アニメの景色のほうが圧倒的にきれい。青空と白い雲、観光地は清潔で、色も明るい。
今日は曇りで、空が灰色。そのせいで地面も建物も灰色に見えて、江ノ島が全体的にボロボロで年季が入ってる感じがした。

あと、アニメが「逆詐欺」。4人組が山登りで死にそうになって、エレベーターに乗るか悩んでいた。
だから「この山、相当高いのか？」と思ったけど、実際はカメラ持って来たのに、準備が整う前にもう頂上だった。
これだけ？この程度の階段でそんなに大変？エレベーター要る？そのエレベーター採算取れる？信じられない。

ここもたぶん映えスポット。ただ天気が悪い。