なぜ私がBEAMの本を書いたのか (2025)

なぜ私はBEAMの本を書いたのか

目次

1. なぜ私はBEAMの本を書いたのか
   1. 起源
   2. 私を突き動かしたもの
   3. 本書の内容と対象読者
   4. 学んだこと
   5. 完了の定義
   6. 参加する

なぜ私はBEAMの本を書いたのか

Klarnaのコアシステムを10年間維持してきた経験から、私はこれを理解しています。BEAMにおける15ミリ秒の停止は、ピーク時のショッピング決済を数百万件も停止させ、真夜中3時のクリスマス・イブの事後検証を招き、CEOからの非常に眠い電話を受けることになります。私は『The BEAM Book』を書きました。それは、次のエンジニアがコーヒーが冷める前にその停止を修正できるようにするためです。

［画像: 印刷された2冊のBEAMの本の写真。］

起源

私は2012年10月12日に、4行のテキストと過剰な楽観主義を込めた単一のDocBookファイルでプロジェクトを開始しました。2週間後、コミットログは主に構造の追加、見出しの移動、メタデータの更新で占められていました。そのほとんどが足場作りでした。実際のコンテンツはまだ数行の希望に満ちたものでした。

11月までに、私はDocBookをAsciiDocに切り替え、カスタムビルドスクリプトを作成し、この本が6ヶ月で完成できると確信しました。初期のコミットはエネルギーに満ちています。追加、書き直し、そして書き直しを修正するためのさらなる書き直し。妄想は過小評価されています。

2013年に、私はO'Reillyに公開を依頼することに成功しました。リポジトリを彼らのAtlasシステムに移行することは簡単そうに聞こえましたが、Atlasは私のメインファイルを隠し、未完成の章を上書きし始めました。

Gitの履歴は、フラストレーションの日記のように読めます。「Atlasに対処するためにファイルをトップレベルに移動」、「Atlasがbook.asciidocを上書きしているようだ」。単語数は120,000を超えましたが、実際の進捗は遅々として進みませんでした。2015年3月10日、ビルドをグリーンに保つために、私は文字通り「章をセクションに押し込んでいました」。

静かなキャンセルは2ヶ月後に来ました。ドラマはなく、丁寧な電話と契約への線が引かれただけでした。安堵と当惑が入り混じりました。私は2年間、文章を完成させるのではなく、ファイルを整理することに費やしていました。

Pragmatic Bookshelfが同年引き継ぎました。私は彼らのプロダクションシステムでCVSを使い続けましたが、進捗は遅かったです。結局、彼らもキャンセルしました。2017年1月20日、私はすべてを新しいリポジトリにインポートしました。それは6,622ファイル、100万行を超える巨大なコミットでした。書き直しは停滞し、プロジェクトも停滞しました。

2017年3月23日、私はプライベートGitHubリポジトリでAsciidoctorを使ってゼロから始め、まだ意味のある部分だけをコピー＆ペーストしました。2週間後の4月7日、チャルマーズでの講義の直前に、私はリポジトリを公開しました。24時間以内に、見知らぬ人々がタイポを修正し、図を追加し、クリエイティブ・コモンズBY-4.0ライセンスをマージしました。

私を突き動かしたもの

［画像: GitHubのスター数が3000を超えた写真。］

私はBEAMを正しく理解したかったので、続けました。表面的な説明だけでなく、実際のロジックを追うことには価値があります。

コミュニティからのフィードバックが違いを生みました。リポジトリが公開されるとすぐに、人々は修正、例、改善を送り始めました。

GitHubでリポジトリにスターを付けている人の数を見ることは、私を続けさせました。ハイライトの一つ：Issue #113 - 「素晴らしいことを続けてください。」（私はその問題について投稿全体を書きました）。その絵文字で飾られたドライブバイ励まし（2018年8月）は、モチベーションが低下するたびに今でも頭に浮かびます。

［画像: Issue 113: この本は信じられないほど良いです。まだ数ページしか読んでいませんが、すでに多くのことを学びました。素晴らしいことを続けてください！］

この本は、ErlangとBEAMカンファレンスのトークで参照として登場し始めました。時には同じイベントで数回も登場しました。それは、他の人も私と同じくらいこれを必要としているという明確なシグナルでした。

Twitter（昔のTwitter）も役割を果たしました。誰かが本に言及したりリンクを共有したりするたびに、それを続けるための追加のきっかけとなりました。

ほとんどの場合、私は自分で信頼できるマニュアル、つまり問題が発生したときに重要なVMの部分のリファレンスが欲しかったのです。それが、3回目の書き直し後でも、書き続ける十分な理由です。

本書の内容と対象読者

本書は、大規模なErlangシステムを構築・運用していたときに欲しかったものをカバーしています。

• スケジューラとプロセス管理：BEAMが実際の負荷下でプロセスをどのようにスケジューリング、優先順位付け、バランスを取るか。
• プロセスとそのメモリ：プロセスヒープ、スタック、メッセージ、バイナリがどのように管理され、これらの詳細が本番環境でなぜ重要なのか。
• ガベージコレクションとメモリ：プロセスごとのおよびグローバルなガベージコレクタ、バイナリ参照、メモリリークで実際に何が起こるか。
• タグ付けスキームとターム：BEAMがデータ（整数、浮動小数点数、タプル、バイナリ、参照）をタグビットまでどのように表現するか。
• コンパイラとVM：コードがどのように命令に変換されるか、コンパイラが何をするか（そしてしないか）、エミュレータがそれをどのように実行するか。
• トレーシングとデバッグ：メッセージ、イベントを追跡し、ボトルネックを特定するためのdbg、erlang:traceなどのツールの実践的な使用法。
• パフォーマンスチューニング：実際のコードのプロファイリング、削減の理解、現実世界のレイテンシ問題の追跡において何が重要か。
• システムアーキテクチャ：ERTS、BEAM VM、およびそれらのサブシステムが、実行中のノードで実際にどのように連携するか。

ErlangまたはElixirシステム、特に大規模なシステムを構築または運用している場合は、この本が最適です。メーリングリスト、散在するドキュメント、コードコメントを検索して、「なぜVMはこのように動作するのか？」という疑問に答える手間を省きます。

学んだこと

持続は完璧に勝る。2回の出版契約のキャンセルは履歴書には悪く見えますが、未完成のアイデアはさらに悪く見えます。

境界が重要です。私は執筆のために時間をブロックし、通知をオフにし、集中を実際の締め切りとして扱いました。14:30のフィーカは交渉の余地がありません。

群衆が助けてくれます。リポジトリを公開することで、修正、励まし、そしてモチベーションが低下したときのちょっとしたきっかけが得られました。

スコープがすべてです。ダーティスケジューラ、新しいJIT、デバッガの詳細をカットしました。それらは付録になるかもしれませんが、コアには含まれません。このスコープ設定プロセスについては、The BEAM Book Is Almost Doneで詳しく書きました。

出荷し、反復する。BEAMは毎年変化します。生きているGitリポジトリは追いつきます。

実際の締め切りが役立ちます。今年の1月、年次レビュー中に、Code Beam Stockholmに間に合うように本を印刷することを決定しました。秋までだと思っていましたが、カンファレンスは6月2日でした。それが、何が本当に不可欠であるかを知る方法です。

完了の定義

印刷物を手に持ち、ついに完成したと感じました。少なくとも今のところは。何年にもわたる散在したコミットが、現実のものに束ねられました。だから、私はこれを完了と呼びます。

参加する

ペーパーバックを入手できるようになりました。The BEAM Book 1.0がAmazonで公開されました。こちらから購入してください。Amazon

エラーを見つけたり、何かを改善したい場合、または単に内部でどのように機能するかを知りたい場合は、リポジトリにスターを付けるかフォークしてください。問題を報告するか、さらに良いことに、プルリクエストを送信してください。貢献者は謝辞でクレジットされます。GitHub: theBeamBook

本を読んだら、正直なレビューをお願いします。アルゴリズムはマーケティングコピーよりも実際のフィードバックに気づきます。

チームが詳細な調査を必要とする場合は、私は実践的なBEAM内部ワークショップを開催しています。これは、ハローワールドだけでなく、実際のシステムに合わせて調整されています。それが必要な場合は、私にメールしてください。happi@happihacking.com