fix contents

Author: dak2

articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md

@@ -93,13 +93,23 @@ created_on: 2025-01-27
 
 * 録画: https://example.com/
 
-僕は、Ruby そして Rails からキャリアを始めた都会っ子です。
+moznion さんの発表内容は、Rails と Perl の違いを比較しながら、それぞれの特徴をもとにした開発スタイルに焦点を当てたものでした。
+それらの違いを「Simple vs Easy」の構図で語っていた点が印象的です。
 
-キャリアの最初は Rails の easy 具合がイマイチ掴めていなかったんですが、キャリアを経て違う言語を触ってみることで Rails ってほんとに便利だなと気づいたことを思い出しました。
+例えば、Rails は、規約があるフルスタックなフレームワークで Easy に作れる仕組みがある一方、隠蔽されている部分が複雑です。
+一方で、Perl などの Simple 組み合わせでは、必要なものだけを組み込めたり、自分たちのベストプラクティスを作れたりする柔軟性があります。
+とはいえ、Simple と Easy は完全に相反するものではないという点が重要なポイントです。
 
-話を聞きながら、Rails が詳細を隠蔽しており、クオリティコントロールが容易な面やオンボーディングが楽という側面は、ビジネスを進める上でコスト感が見積りやすく採用しやすい部分はあるよなあと思っていました。
+Rails と Perl などの Simple 組み合わせは、それぞれが Easy と Simple を両立しています。
+Rails は、作るための仕組みは Easy ですが、ビジネスロジックは Simple に実現できます。
+一方、Perl などの Simple 組み合わせは、最大公約数的な Easy ではなく、ドメインに特化した Easy を Simple とともに得られます。
 
-逆に Rails が easy だからこそ中身が気になってしまう人が多いのではなかろうかなども。
+私は Simple 組み合わせ村の経験はあまりありませんが、自社のドメイン知識をベースにシステムを考えていくことで、確かにドメインに特化した Easy と Simple が得られるのだろうと感じました。
+逆に Rails は "Rails Way" という言葉があるように、最大公約数的な Easy と Simple を目指しているのだなという気づきも得られました。
+
+特に印象的だったのは、「Simple 組み合わせでは自分たちに最適化したベストプラクティスを作れるので、レールを外れることを恐れなくて良くなる」という部分です。
+Rails を書いている身としては、レールに沿っているかを気にする場面があるので、確かにと共感しました。
+レールに沿ったものがベストプラクティスであるため、ベストプラクティスを考える手間はある程度省けており、ドメインロジックの実現に集中できるということなのだと思いました。
 
 改めて Rails の立ち位置を考える機会となった発表でした！
 
@@ -112,17 +122,71 @@ created_on: 2025-01-27
 
 * 録画: https://example.com/
 
-PDF の構造は知らなかったので、知見となることも多く、自分だったらどう書くんだろうと思いながら拝見させていただきました。
-
-どんどん適度な粒度で抽象化されていく過程を楽しく眺めていました。
-
-PDF の位置指定は結構めんどくさい気がするので、ご自身のスライドの調整もちょっと苦労されたのかなあと勘ぐったりしました。
-
-業務で使っているツールなどをハックして再実装するなどの試みは、そのツールとの機能差分が比較できてより理解が深まって良いですよね！
-
-自分も何か Ruby で再実装できないかなあと思いました。
-
-発表のスライド自体もご自身が書いた DSL で生成するというオチも素晴らしかったです(笑)
+Ogawa さんは、Ruby DSL を使って PDF を生成するという内容でした。
+
+PDF の仕様の話をすると、ヘッダー / ボディー / クロスリファレンステーブル / トレイラー の4つで構成されているようです。
+その内、ボディー部のオブジェクトの構造は下記のようになっています。（一部省略）
+
+```
+1 0 obj << /Type /Catalog /Pages 2 0 R >> endobj
+2 0 obj << /Type /Pages /Kids [ 3 0 R ] /Count 1 >> endobj
+3 0 obj << /Type /Page /Parent 2 0 R /MediaBox [ 0 0 720 405 ]
+  /Resources 4 0 R /Contents 5 0 R >> endobj
+...
+xref
+0 6
+0000000000 65535 f
+0000000009 00000 n
+0000000058 00000 n
+0000000115 00000 n
+0000000227 00000 n
+0000000319 00000 n
+```
+
+この構造を見ると、Catalog -> Pages <-> Page -> コンテンツストリーム という流れが見えてきます。
+Catalog がエントリポイントとなり、Pages が描画するページを探し、Page で実際のコンテンツをたどる流れです。
+
+また、数字の羅列はクロスリファレンステーブルというもので、ファイル内の各オブジェクトの位置を一覧化した情報です。
+例えば `0000000009 00000 n` という記述は、「このオブジェクトは PDF ファイルの 9 バイト目にある」ということを示しています。
+
+この情報があることで、PDF の任意のページにランダムアクセスが可能になります。もしこの情報がなければ、目的のページにアクセスするために 1 ページ目から順に読む必要があるでしょう。
+しかし、人間がこの計算を行うのは難しいため、DSL 側でオフセット計算をしながら PDF を組み立てる仕組みになっていました。
+
+```ruby
+class OffsetIO
+  attr_reader :offset
+  def initialize(io)
+    @io = io
+    @offset = 0
+  end
+  def <<(b)
+    @io << b
+    @offset += b.bytesize
+  end
+end
+
+code do
+  content <<~RUBY, style: JotPDF::Tokyork12::Highlighter::Ruby
+    def obj
+      @io << "obj "
+      yield
+      @io << " endobj"
+    end
+  RUBY
+  list x: 350, y: 150, size: 25, color: 0xffffff do
+    item "Ruby にはブロックがある"
+  end
+end
+```
+
+紹介のあったコードの一部を抜粋しましたが、`<<` メソッドを使ってクロスリファレンステーブルのバイトサイズを計算しつつ、content ブロック内で PDF の中身を組み立てる構造になっています。
+ブロック構文を利用することで階層構造が視覚的に明確になり、code ブロックの中に content の内容や list の内容が含まれるという構図がわかりやすくなっています。
+
+適度な粒度で抽象化されていく DSL の構築過程をとても楽しんで拝見しました。
+業務で使っているツールなどをハックして再実装する試みは、そのツールとの機能差分を比較でき、より深い理解につながるので良いですよね！
+私も何か Ruby で再実装できないかと考えさせられました。
+
+さらに、発表のスライド自体もご自身が作った DSL で生成されていたというオチも素晴らしかったです（笑）。
 
 (dak2)