本文デザイン

本文の表示確認を兼ねたページ。ダミー文を並べても読む気にならないので、エンジニアが日常的に使っている言葉の発祥と、引用されがちな警句を題材にした。出典はすべて一次資料か、それに準じるものを確認している。

名前はどこから来たのか

普段何気なく打っている単語のいくつかには、驚くほどはっきりした発祥がある。

bug ― 最初の一匹は、本当に虫だった

1947年9月9日、Harvard Mark II?ハーバード大学が米海軍向けに作った電気機械式の計算機。リレーの開閉で演算する。Log Book With Computer Bug（Smithsonian） のリレーから蛾が見つかった。発見者はそれをログブックに貼り付け、こう書き添えている。

First actual case of bug being found.

このログブックは現在、スミソニアン国立アメリカ歴史博物館に収蔵されている¹。当時 Mark II のチームにいた Grace Hopper がこの逸話を語り広めたことで、「バグの語源は蛾」という話が定着した。

ただし、この説明は半分だけ正しい。

foo と bar ― 語源を定めた RFC がある

サンプルコードの変数名に困ったとき、多くの人が foo と bar を打つ。この2語には、語源を調査した公式文書が存在する。

発行日で察しがつくとおりジョーク RFC?4月1日に発行される冗談のRFC。番号は正規に振られ、体裁も本物と変わらない。RFC 1149 の一種だが、調査自体は真面目で、複数の系統を挙げている。

• 漫画『Smokey Stover』（1930年代〜）が FOO を車のナンバープレートなどに多用した
  • 作者は中国の置物で見つけた語だと説明していた
• 第二次大戦中、レーダーに映る正体不明の反応が foo fighters と呼ばれた
  • 英軍では FOO was here という落書きが流行した
• 軍のスラング FUBAR?第二次大戦期の軍のスラング。foobar への合流は RFC 3092 が整理している が foobar として合流した

計算機の文脈では、MIT の Tech Model Railroad Club?MIT の鉄道模型クラブ。独自の用語集を残し、初期のハッカー文化の語彙の源になった。1959年の用語集（Computer History Museum） が1959年の用語集にすでに収録している。

The sacred syllable (FOO MANI PADME HUM); to be spoken only when under obligation to commune with the Deity.

foo に意味を持たせない、という約束ごとはここから始まった。意味のない名前をあえて選ぶことで、コードの構造だけに注目させる。

const foo = (bar: string) => bar.trim();

daemon ― 悪魔ではなく、マクスウェルの悪魔

バックグラウンドで動き続けるプロセスを daemon と呼ぶ。この名付けを行ったのは MIT の Project MAC?MIT が1963年に始めた計算機研究プロジェクト。時分割システムの研究から Multics が生まれた。MIT CSAIL Mission & History にいた Fernando Corbató で、1963年ごろのことだという。

We fancifully began to use the word daemon to describe background processes that worked tirelessly to perform system chores.

由来は宗教的な悪魔ではなく、熱力学の思考実験に登場するマクスウェルの悪魔である。分子を黙々と選り分け続けるあの存在が、システムの雑事を黙々とこなすプロセスに重ねられた。

ps aux | grep -c daemon

hello, world ― 最初に書いたのは B 言語の入門書

初出は1972年、Brian Kernighan が Bell Labs 内部向けに書いたA Tutorial Introduction to the Language Bとされている。直前の例が hi! を出力するもので、もう少し長い文字列の例として hello, world! が登場した。

Kernighan 自身は、なぜこの言葉を選んだか正確には覚えていないと語っている。卵から出たヒヨコが “Hello, World” と言う漫画を見た記憶がある、というのが本人の弁だ。

広まったのは1978年、K&R?著者 Brian Kernighan と Dennis Ritchie の頭文字。C の事実上の標準教科書を指す通称。Brian Kernighan の著作一覧『The C Programming Language』§1.1 に載ってからだった。

main()
{
    printf("hello, world\n");
}

$ cc hello.c && ./a.out
hello, world

いま書けばコンパイラに叱られるコードだが、当時の C はこれで通った。書ける 動く 通らない の境界は、言語のバージョンとともに動いていく。

ここまでの4語を、初出の資料とともに並べておく。

引用される警句と、引用されない続き

有名な言葉ほど、短く切り取られて流通する。元の文脈まで読むと、印象が変わるものが多い。

早すぎる最適化は諸悪の根源である

Donald E. Knuth が1974年の論文『Structured Programming with go to Statements』（ACM Computing Surveys 6巻4号）に書いた一節。引用されるのはほぼ常に真ん中の一文だけだ。

プログラマは、プログラムの非クリティカルな部分の速度について考えたり心配したりすることに膨大な時間を浪費している。そうした効率化の試みは、デバッグと保守を考えると実際には強い悪影響を及ぼす。我々は小さな効率については、たとえば97%の場合において忘れるべきだ。早すぎる最適化は諸悪の根源である。 とはいえ、残りのクリティカルな3%における好機を逃すべきではない。

最後の一文まで含めると、これは「最適化するな」ではなく「測ってから、効く場所だけやれ」という主張になる²。

テストは欠陥の存在を示せるが、不在は示せない

Edsger W. Dijkstra が1969年、NATO のソフトウェア工学会議で述べた言葉（会議録 p.16）。ここから導かれる実務上の態度は単純だ。

1. テストが通ったことは、バグがないことの証明にはならない
2. したがって、バグを見つけたら「なぜテストで捕まらなかったか」まで遡る
3. 再現するテストを書いてから直す

同じく Dijkstra の EWD498?Dijkstra が生涯書き続けた手稿 EWD の498番。番号で参照される。EWD498 の翻刻（1975年）には、単純さは信頼性の前提である、という一行がある。あとでリファクタリングする と書いたコメントが1年後も残っているなら、それは単純化の機会を逃し続けているということだ。

堅牢性原則と、その後の再検討

be conservative in what you do, be liberal in what you accept from others

Jon Postel が RFC 761（1980年1月）§2.10 に書いた一文で、Postel の法則として知られる。送るものは厳格に、受け取るものは寛容に。

ところが2023年6月、IETF?インターネットの技術仕様を策定する組織。成果を RFC として番号付きで公開する。About the IETF は RFC 9413『Maintaining Robust Protocols』でこの原則を明確に再検討している。

Time and experience show that negative consequences to interoperability accumulate over time if implementations silently accept faulty input.

壊れた入力を黙って受け入れ続けると、その実装のバグが事実上の仕様になり、後発の実装まで同じ誤りを再現する羽目になる。RFC 9413 はこれをprotocol decay?寛容な受け取りが積み重なり、実装のずれが相互運用性を蝕んでいく現象。RFC 9413 が名付けたと呼び、寛容さの代わりに「仕様と実装をまとめて直し続けること」を勧めている。

型定義の世界でも似た構図がある。受け取りを緩めるつもりで外した設定は、たいてい後から効いてくる。

{
  "compilerOptions": {
    "target": "ES2022",
    "strict": true,
    "noImplicitAny": false,
    "strictNullChecks": false
  }
}

Talk is cheap. Show me the code.

Linus Torvalds が2000年8月25日、linux-kernel メーリングリスト?Linux カーネルの開発議論が行われる公開メーリングリスト。略して LKML。vger.kernel.org のリスト一覧への返信に書いた一行。設計論が長引いたときに投げ込まれる言葉として定着した。

議論を止める呪文としては便利すぎるので、使いどころは選んだほうがいい。動くコードが出てくるまで判断を保留できる場面と、そもそも何を作るかが決まっていない場面は違う。

GitHub - torvalds/linux: Linux kernel source tree

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

冗談として語り継がれてきたもの

笑い話の形で共有されている経験則には、たいてい元ネタがある。

自転車置き場は何色か

C. Northcote Parkinson が1957年の著書『Parkinson’s Law, or the Pursuit of Progress』で示した「些末さの法則」。架空の委員会が3つの議題をどう扱ったかという例が挙げられている。

金額が大きいほど議論が短い。誰も内容を理解できないからだ。逆に自転車置き場は全員が意見を言えるので、いつまでも終わらない。

ソフトウェアの文脈に持ち込んだのは Poul-Henning Kamp で、1999年に FreeBSD のメーリングリストへ投げた「Why Should I Care What Color the Bikeshed Is?」という文章による。きっかけは sleep(1) が小数秒を受け付けるべきかという長い議論だった。

ヤクの毛を刈る

2000年2月11日、MIT AI 研究室の Jeremy H. Brown がメーリングリストに書いた定義が初出とされている。

yak shaving is what you are doing when you’re doing some stupid, fiddly little task that bears no obvious relationship to what you’re supposed to be working on, but yet a chain of twelve causal relations links what you’re doing to the original meta-task.

本来やりたかったことと、いま自分がやっていることの間に、十数段の因果関係が挟まっている状態を指す。

• バグを1件直したい
• ローカルで再現させたい
• 依存関係を入れ直す必要があった
• Node のバージョンが合わなかった
• バージョン管理ツールの設定ファイルを書き直している

毛刈りそのものが悪いわけではない。問題は、何段目にいるかを自分で把握できなくなることにある。作業を始める前に元のタスクを書き留めておくと、戻る場所が残る。

アヒルに話しかける

Andy Hunt と Dave Thomas の『達人プログラマー』（1999年）で紹介された手法。相談相手は返事をしなくてよく、ゴム製のアヒルでも構わない。

the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself

効くのは、説明しようとすると「自分が何を前提にしていたか」を言葉にせざるを得ないからだ。次のコードを声に出して読むと、2行目と3行目の間にある飛躍に気づきやすい。

export const toDisplayName = (user: User) => {
  if (!user.name) return "名称未設定";
  return user.admin ? `${user.name}（管理者）` : user.name;
};

難しいことは2つある

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton の言葉として広く知られている³。ただし一次資料は見つかっておらず、Tim Bray が1996年ごろに聞いた、という経路で伝わっているにすぎない。後に「3つ目はオフバイワンエラー?境界をひとつ数え違える誤り。ループの終了条件や配列の添字で起きやすい。CWE-193」という続きが付け足され、これも誰が言い出したのか判然としない。

出典が曖昧なまま生き残っているのは、内容が実感に合っているからだろう。命名は、あとから直すのが最も面倒な種類の負債になる。

const user: User = { id: "u_01", name: "山田", admin: true, isAdmin: true };

そしてもう一方のキャッシュ無効化?古くなったキャッシュを捨てて取り直させること。いつ捨てるかを決めるのが難しい。RFC 9111 §4.4は、たいてい「返す値そのものは正しいが、返すべきではなかった」という形で現れる。

export const findUser = (users: User[], id: string) =>
  users.find((user) => user.id === id);
  users.find((user) => user.id === id) ?? null;

HTTP のキャッシュがなぜ難しいかは、MDN の HTTP キャッシュの解説が、プライベートキャッシュと共有キャッシュの区別から丁寧に説明している。

どれを選ぶか

語源や警句と違って、技術選定には正解の形がない。用途に対して向き不向きがあるだけだ。

Islands という呼び方の実装がどうなっているかは、リポジトリを読むのが早い。

GitHub - withastro/astro: The web framework for content-driven websites.

The web framework for content-driven websites. Contribute to withastro/astro development by creating an account on GitHub.

github.com

選んだ結果は、たいてい設定ファイルの数行に凝縮される。

{
  "name": "example-app",
  "version": "1.0.0",
  "scripts": {
    "dev": "vite",
    "build": "vite build"
  }
}

設定ファイルは単体では効かない。置き場所とセットで意味を持つ。Astro が公式に示す構成はこうなっている。

• astro.config.mjs
• package.json
• tsconfig.json
• public/
• src/
  • components/
  • layouts/
  • pages/
  • styles/

必須は src/pages/ だけで、ここに置いたファイルがそのままルートになる。components と layouts の区別は慣習であり、フレームワーク側は強制していない⁴。

参考

• RFC 761 Transmission Control Protocol — Jon Postel, 1980-01, 2026-09-18 参照。堅牢性原則の原文
• E.W. Dijkstra Archive — The University of Texas at Austin, 2026-09-18 参照。EWD の原典群
• 『達人プログラマー』Andy Hunt, Dave Thomas 著, 1999。アヒルに話しかける手法の出典