Phase 4.1: 素のRackアプリの限界を体験する

← 前へ: Phase 3.3 | 目次 | 次へ: Phase 4.2 →

概要

実行前に共通セットアップと各Phaseの確認手順を確認してください。演習コードはwork/で前のPhaseから引き継ぎます。

このフェーズでは、あえてフレームワークを使わずに素のRackアプリだけで少し大きめのWebアプリケーションを実装します。

その中で、

「なぜフレームワークが必要なのか」

を自分の手で体験します。

このフェーズの目的

以下を説明できる状態になること：

Rackだけでアプリを書くと何がつらいのか
フレームワークが解決している問題は何か
抽象化が必要になる理由

到達目標

素のRackアプリで複数ページを持つアプリを実装する
コードがどのように複雑化するかを観察する
問題点を言語化できる

前提

Phase 3.1（Rack理解）完了

課題概要

以下の仕様を満たすアプリケーションをRackのみで実装してください。

※ Sinatra / Rails 等のフレームワークは使用禁止

実装するアプリ

簡易的な「ユーザー一覧アプリ」を作成します。

必要な機能

1. トップページ

GET /

シンプルなHTMLを表示

2. ユーザー一覧

GET /users

ユーザーの一覧を表示（配列でOK）

3. ユーザー詳細

GET /users/:id

指定IDのユーザー情報を表示

4. ユーザー作成（簡易）

POST /users

パラメータを受け取り、配列に追加

制約

❌ 使用禁止

Sinatra
Rails
ルーティングライブラリ
テンプレートエンジン（ERBも禁止）

✅ 使用可能

Rack
Ruby標準ライブラリ

実装ヒント

1. ルーティング

case env["PATH_INFO"]
when "/"
  ...
when "/users"
  ...
end

2. HTMLは文字列で返す

body = "<h1>Hello</h1>"

3. パラメータ取得

req = Rack::Request.new(env)
req.params

観察すべきポイント（重要）

実装しながら以下を意識してください：

1. 分岐が増えていく

pathごとの条件分岐が増える
見通しが悪くなる

2. HTMLがコードに埋め込まれる

可読性が落ちる
変更がつらい

3. 共通処理が散らばる

ヘッダ設定
レスポンス生成

4. アプリの構造が曖昧

どこに何を書くべきか不明確

Step: 必ずやること

Step 1: 最小構成で実装

まずは動くものを作る

Step 2: 機能を追加

/users → /users/:id → POST と増やす

Step 3: コードを見直す

以下を考える：

どこがつらいか？
何が繰り返されているか？

成果物

1. ソースコード

Rackアプリ一式

2. 問題点リスト（最重要）

以下を列挙してください：

書いていてつらかった点
将来的に問題になりそうな点

3. 考察

以下を自分の言葉で説明：

「なぜフレームワークが必要なのか」

レビュー観点

問題を正しく認識できているか
抽象化の必要性に気づいているか
「つらさ」を具体的に説明できているか

AI活用

OK

Rackの仕様確認
HTTPの確認

NG

実装の生成

よくある失敗

1. 綺麗に書こうとする

→ あえて汚くなってOK
→ それが学び

2. 最初から抽象化する

→ まずはベタに書く

3. 小さくまとめすぎる

→ 少し規模を大きくすることが重要

このフェーズの本質

この課題のゴールは：

「つらさ」を体験すること

次フェーズへの接続

このフェーズで出てきた問題をもとに、

次のフェーズでは：

ルーティング
コントローラ

を導入していきます。

最後に

フレームワークは最初から存在したわけではありません。

「つらさ」から生まれています

その原点を、このフェーズで体験してください。