Kassadin.moe
中文 ZH English EN 日本語 JA

月記：2025-05

公開日

原文言語: 中国語 。 AI翻訳: 英語 、 日本語 。

ゴールデンウィーク、なんで休みってこんな短いんだろう

文章構成

  1. 入力
    Learning：本/小説/良い記事、動画/ポッドキャストなど形式は問わず、「見終わって得した」と感じるもの
    Anime：新作/旧作、TV/劇場版など。観たアニメの記録
    Others：ドラマ/映画など。その他に入れる

  2. 雑念
    たぶん思ったことを書くだけ

  3. 出力
    たぶん Blog。でも自分のレベルが低すぎて、1ヶ月まったく出力がないかもしれない（

  4. 旅行記
    どこか行ったら書く。行かなかったらそれでよし

  5. 雑
    上のどれにも入らない細々したこと

入力

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 は自前コンポーネントが使えるだけでなく、複数のフロントエンドフレームワークを混在できること。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章はほとんど読み終わって、最後に streams のところが少し残っている。

この章でようやく一般的な Object-Oriented Programming が出てきた。前2章で積み上げた Functional Programming の上に state を導入して、assignment によって mutable variables を扱うようになり、「入力が同じなら出力も同じ」だったプログラムが、「実行時の状態によっては同じ入力でも違う結果になる」プログラムへ変わっていく。
関数型に比べて OOP は確かにできることが増える。でも、そのぶん代償も大きい。
もともとかなり固定的だった振る舞いが、状態しだいで毎回変わるかもしれなくなり、挙動の予測が難しくなる。この章は、state が混乱を生まないようにどう制御するかをずっと考えている印象だった。

読み進めるほど疑問が湧いてきた。OOP がもたらすメリットは、本当に、導入される複雑さと、それを管理するための時間や精神コストに見合っているのか？
たぶんこれは、自分がまだ大規模システムを書いたことがないからこそ出てくる疑問でもある。規模が一定を超えたら functional だけでは厳しくなって、OOP に寄らざるを得ないのかもしれない。そこはまだ経験不足で判断がつかない。
ただ、2023 年からプログラミングに触れて Eloquent JavaScript などを読んできた中では、みんな immutable variables と no side-effect を繰り返し強調していた。

普通の学習ルートなら、学校でも講座でも、おそらく OOP から入るし、そのまま OOP しかやらないことも多い。たぶんそのほうがイメージしやすいから。
でも SICP は最初から Functional Programming と recursive を叩き込んでくる。前2章を読んでいた時点では、そもそも「変数が変わらないこと」自体が関数型でかなり重要だ、ということにすら自分は気づいていなかった。
第3章で state が入って、ようやく変数が本当に mutable になる。

つまり 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人組が坂道で死にそうになっていて、エレベーターに乗るか本気で悩んでいた。
だから「この山、かなりきついのか？」と思っていたのに、実際はカメラを担いで来ても、準備が整う前にもう頂上だった。
これだけ？ この程度の階段でそんなに大変？ エレベーター要る？ そのエレベーター採算取れる？ 本当に？


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


江ノ島の上にある、何かの塔。


島を出る頃には夕方。少しだけ夕日を見よう。


でも厚い雲に遮られて、ほとんど何も見えない。

時間の都合で鎌倉は無理だった。次回に持ち越し。また来ます.jpg

雑

特に書くことなし。略。

結語

5月の月記、いつもどおり6月末まで引きずった。本当は「5月の月記を書き終えたらブログ移行を始める」予定だったのに、そこからさらに丸1ヶ月伸ばしてしまった。
これ以上はもう引き延ばせない。雑でもいいから、とりあえず出しておく。
次に会うときは新しいスタイル。お楽しみに〜（あるいは…あまり期待しないほうがいいかも？）

コメント