2.1.1 ユーザーのモデル設計

Webでのユーザー登録の方法が多岐にわたることからもわかるように、ユーザーという概念をデータモデルで表す方法はたくさんありますが、ここではあえて最小限の表現方法を使います。

各ユーザーには、重複のない一意のキーとなるinteger型のID番号（idと呼びます）を割り当て、このIDに加えて一般公開されるstring型の名前（name）、そして同じくstring型のメールアドレス（email）を持たせます。メールアドレスはユーザー名としても使われます。ユーザーのデータモデルの概要を図 2.2に示します。

図 2.2: ユーザーのデータモデル

詳しくは6.1.1から解説しますが、図 2.2のユーザー（users）はデータベースのテーブル（table）に相当します。また、 id、name、 email の属性はそれぞれテーブルのカラム（column: 列）に相当します。

2.1.2 マイクロポストのモデル設計

マイクロポストは比較的短い投稿であると最初に説明したことを思い出しましょう。マイクロポストは“ツイート”とTwitterの用語で呼ばれますが、本質的には一般用語です（“micro”というプレフィックスを使っているのは、Twitterが初期に用いていた“micro-blog”という説明に従った結果です）。マイクロポストのデータモデルの中核部分はユーザーよりもさらにシンプルです。idとマイクロポストのテキスト内容を格納するtext型のcontentだけで構成されています³。しかし実際には、マイクロポストをユーザーと関連付ける（associate） 必要があります。そのため、マイクロポストの投稿者を記録するためのuser_idも追加します。これにより、データモデルは図 2.3のようになります。

図 2.3: マイクロポストのデータモデル

2.3.3では、user_idという属性を使って、1人のユーザーに複数のマイクロポストが関連付けられるという構造を簡潔に説明します。詳細は第13章で完全に説明します。

2.2.1 ユーザーページを探検する

Usersリソースをscaffoldで生成したことで（2.2）、ユーザー管理用のページが多数追加されます。たとえば、/usersを表示すればすべてのユーザーの一覧が表示されますし、/users/newを表示すれば新規ユーザー作成ページが表示されます。このセクションでは以後、ユーザーに関連するページについて手短に説明します。その際、表 2.1に記載されている、ページとURLの関係を参照するとわかりやすいと思います。

まずはユーザーの一覧を表示するindexアクションのURL（/users）を見てみましょう。もちろん、この時点ではまだユーザーは登録されていません（図 2.4）。

図 2.4: Usersリソース（/users）ページの最初の状態

ユーザーを新規作成するには、図 2.5のnewページを表示します。なお、第7章ではこのページがユーザー登録ページに変わります。

図 2.5: 新規ユーザー作成ページ（/users/new）

テキストフィールドに名前とメールアドレスを入力して［Create User］ボタンを押してください。図 2.6のようにshowページが表示されます（緑色のウェルカムメッセージは、7.4.2で解説する flashという機能を使って表示しています）。ここで、URLが /users/1 と表示されていることに注目してください。ご想像のとおり、この1という数字は図 2.2のid属性そのものです。7.1では、このページをユーザーのプロフィールページに作り変える予定です。

図 2.6: ユーザー表示用のページ（/users/1）

今度はユーザーの情報を変更するため、［Edit］をクリックして/users/1/edit にあるeditページを表示してみましょう（図 2.7）。この編集ページ上でユーザーに関する情報を変更し、［Update User］ボタンを押せば、Toyアプリケーション内のユーザー情報が変更されます（図 2.8）。（詳細は第6章で説明しますが、このユーザー情報は、Webアプリケーションの背後にあるデータベースに保存されています）。サンプルアプリケーションでも、ユーザーを編集または更新する機能を10.1で実装します。

図 2.7: ユーザー編集用のページ（/users/1/edit）

図 2.8: 情報が更新されたユーザー

ここで /users/new にあるnewページに戻り、ユーザーをもう1人作成してみましょう。indexページを表示してみると、図 2.9のようにユーザーが追加されています。7.1ではもっと本格的なユーザー一覧ページを作成する予定です。

図 2.9: 2人目のユーザーが追加された一覧ページ（/users）

ユーザーの作成、表示、編集方法について説明しましたので、今度はユーザーを削除してみましょう（図 2.10）。図 2.10の［Destroy］リンクをクリックするとユーザーが削除され、indexページのユーザーは1人だけになります（もしこのとおりにならない場合は、ブラウザのJavaScriptが有効になっているかどうかを確認してください。Railsでは、ユーザーを削除するリクエストを発行するときにJavaScriptを使っています）。なお、10.4ではサンプルアプリケーションにユーザーを削除する機能を実装し、管理権限（admin）を持つユーザー以外は削除を実行できないように制限をかけます。

図 2.10: ユーザーを削除する

2.2.2 MVCの挙動

これでUsersリソースの概略についての説明が終わりましたが、ここで1.3.3で紹介した MVC（Model-View-Controller = モデル-ビュー-コントローラ）パターンの観点からこのリソースを考察してみましょう。具体的には、「/users にあるindexページをブラウザで開く」という操作をしたとき、内部では何が起こっているかについてMVC（図 2.11）で説明します。

図 2.11: RailsにおけるMVC

図 2.11で行われている手順の概要を以下に示します。

1. ブラウザから「/users」というURLのリクエストをRailsサーバーに送信する。
2. 「/users」リクエストは、Railsのルーティング機構（ルーター）によってUsersコントローラ内のindexアクションに割り当てられる。
3. indexアクションが実行され、そこからUserモデルに、「すべてのユーザーを取り出せ」（User.all）と問い合わせる。
4. Userモデルは問い合わせを受け、すべてのユーザーをデータベースから取り出す。
5. データベースから取り出したユーザーの一覧をUserモデルからコントローラに返す。
6. Usersコントローラは、ユーザーの一覧を@users変数（@はRubyのインスタンス変数を表す）に保存し、indexビューに渡す。
7. indexビューが起動し、ERB（Embedded RuBy: ビューのHTMLに埋め込まれているRubyコード）を実行して HTMLを生成（レンダリング）する。
8. コントローラは、ビューで生成されたHTMLを受け取り、ブラウザに返す⁵。

上の流れをもう少し詳しく見てみることにします。最初にブラウザからのリクエストを見てみましょう。このリクエストは、アドレスバーにURLを入力したりリンクをクリックした時に発生します（図 2.11の①）。 リクエストはRailsルーティングに到達し（②）、ここでURL（とリクエストの種類: コラム 3.2参照）に基づいて適切なコントローラのアクションに割り当てられます（ディスパッチ）。 ユーザーからリクエストされたURLを、Usersリソースで使うコントローラのアクションに割り当てるためのコードは、リスト 2.6のようになります。 このようなマッピングするコードはRailsのルーティング設定ファイル（config/routes.rb）に書きます。Railsではconfig/routes.rbで、URLとアクションの組み合わせ（表 2.1）を効率よく設定していきます（:usersという一見奇妙な記法は、Ruby言語特有の「シンボル」と呼ばれるものです。詳細については4.3.3で説明します）。

Rails.application.routes.draw do
  resources :users
  root 'application#hello'
end

それでは、このルーティングファイルを変更してみましょう。サーバーのルートURLにアクセスしたら、デフォルトのページの代わりにユーザー一覧を表示するようにします。つまり、「/」（スラッシュ）にアクセスしたら/usersを開くようにします。リスト 2.3で次のような変更をしたことについて思い出してください。

root 'application#hello'

これにより、ルートにアクセスするとApplicationコントローラ内のhelloアクションにルーティングされるようになったのでした。今回の場合は、Usersコントローラのindexアクションを使いたいので、リスト 2.7のコードを元に書き換えてみましょう。

Rails.application.routes.draw do
  resources :users
  root 'users#index'
end

2.2.1以降で紹介した各ページは、Usersコントローラ内のアクションにそれぞれ対応しています。リスト 2.8は、scaffoldで生成したコントローラの骨格です。class UsersController < ApplicationControllerという記法では、Rubyのクラス継承の文法をそのまま使っていることにご注目ください（継承の概略については2.3.4、詳細については4.4で説明します）。

class UsersController < ApplicationController
  .
  .
  .
  def index
    .
    .
    .
  end

  def show
    .
    .
    .
  end

  def new
    .
    .
    .
  end

  def edit
    .
    .
    .
  end

  def create
    .
    .
    .
  end

  def update
    .
    .
    .
  end

  def destroy
    .
    .
    .
  end
end

ページの数よりもアクションの数の方が多いことにお気付きでしょうか。index、show、new、editアクションはいずれも2.2.1のページに対応していますが、それ以外にもcreate、update、destroyアクションがあります。通常、これらのアクションは、ページを出力せずにデータベース上のユーザー情報を操作します（もちろんページを出力しようと思えばできますが）。

表 2.2は、RailsにおけるRESTアーキテクチャ（コラム 2.2）を構成するすべてのアクションの一覧です。RESTは、コンピュータ科学者Roy Fieldingによって提唱された「REpresentational State Transfer」という概念に基づいています⁶。表 2.2のURLには重複しているものがあることにご注目ください。例えば、showアクションと updateアクションは、どちらも/users/1というURLに対応しています。これらのアクション同士の違いは、それらのアクションに対応するHTTP requestメソッドの違いでもあります。HTTP requestメソッドの詳細については3.3で説明します。

UsersコントローラとUserモデルの関係をさらに考察するために、リスト 2.9でindexアクションを整理してみました（コラム 1.2でも紹介しましたが、たとえ完全に理解できなくても、コードの読み方について学ぶことは非常に重要です）。

class UsersController < ApplicationController
  .
  .
  .
  def index
    @users = User.all
  end
  .
  .
  .
end

indexアクションに@users = User.allという行があります（図 2.11の③に相当）。これによって、Userモデルからすべてのユーザーの一覧を取り出し（④）、@usersという変数に保存します（⑤）。なお、@usersは「あっと ゆーざーず」と発音します。

Userモデルの内容はリスト 2.10にあります。驚くほどシンプルな内容ですが、継承（2.3.4および4.4）によって多くの機能が備わっています。特に、Active RecordというRubyライブラリのおかげで、リスト 2.10のUserモデルはUser.allというリクエストに対して、DB上のすべてのユーザーを返すことができます。

class User < ApplicationRecord
end

@users変数にユーザー一覧が保存されると、コントローラはリスト 2.11の ビュー を呼び出します（⑥）。 @記号で始まる変数をRubyではインスタンス変数と呼び、Railsのコントローラ内で宣言したインスタンス変数はビューでも使えるようになります。この場合、リスト 2.11のindex.html.erbビューは@usersの一覧を並べ、1行ごとにHTMLの行として出力します（今はこのコードの意味がわからなくても問題ありません。これはあくまで説明のためのものです）。

<p id="notice"><%= notice %></p>

<h1>Users</h1>

<table>
  <thead>
    <tr>
      <th>Name</th>
      <th>Email</th>
      <th colspan="3"></th>
    </tr>
  </thead>

  <tbody>
    <% @users.each do |user| %>
      <tr>
        <td><%= user.name %></td>
        <td><%= user.email %></td>
        <td><%= link_to 'Show', user %></td>
        <td><%= link_to 'Edit', edit_user_path(user) %></td>
        <td><%= link_to 'Destroy', user, method: :delete,
                         data: { confirm: 'Are you sure?' } %></td>
      </tr>
    <% end %>
  </tbody>
</table>

<br>

<%= link_to 'New User', new_user_path %>

ビューはその内容をHTMLに変換し（⑦）、コントローラがブラウザにHTMLを送信して、ブラウザでHTMLが表示されます（⑧）。

2.2.3 Usersリソースの欠点

scaffoldで作成したUsersリソースは、Railsの概要を手っ取り早く説明するには良いのですが、次のようなさまざまな問題点を抱えています。

• データの検証が行われていない。 このままでは、ユーザー名が空欄であったり、でたらめなメールアドレスを入力したりしても通ってしまいます。
• ユーザー認証が行われていない。 ログイン、ログアウトが行われていないので、誰でも無制限に操作できてしまいます。
• テストが書かれていない。 厳密にはこれは正しい表現ではありません。というのも、scaffoldで生成したコードにはごく簡単なテストが一応含まれているからです。ただ、scaffoldのテストコードはデータ検証やユーザー認証、その他の必要な要求を満たしていません。
• レイアウトやスタイルが整っていない。 サイトデザインも操作法も一貫していません。
• 理解が困難。 scaffoldのコードを理解できたら「熟練」（コラム 1.2）に達していると言っても良いほど複雑です。

2.3.1 マイクロポストを探検する

Usersリソースの場合と同様に、Micropostsリソースもscaffoldでコードを生成してみましょう。rails generate scaffoldコマンドを使って、図 2.3のデータモデルを実装してみます⁷。

$ rails generate scaffold Micropost content:text user_id:integer
      invoke  active_record
      create    db/migrate/20160515211229_create_microposts.rb
      create    app/models/micropost.rb
      invoke    test_unit
      create      test/models/micropost_test.rb
      create      test/fixtures/microposts.yml
      invoke  resource_route
       route  resources :microposts
      invoke  scaffold_controller
      create    app/controllers/microposts_controller.rb
      invoke    erb
      create      app/views/microposts
      create      app/views/microposts/index.html.erb
      create      app/views/microposts/edit.html.erb
      create      app/views/microposts/show.html.erb
      create      app/views/microposts/new.html.erb
      create      app/views/microposts/_form.html.erb
      invoke    test_unit
      create      test/controllers/microposts_controller_test.rb
      invoke    helper

      create      app/helpers/microposts_helper.rb
      invoke      test_unit
      invoke    jbuilder
      create      app/views/microposts/index.json.jbuilder
      create      app/views/microposts/show.json.jbuilder
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/microposts.coffee
      invoke    scss
      create      app/assets/stylesheets/microposts.scss
      invoke  scss
   identical    app/assets/stylesheets/scaffolds.scss

新しいデータモデルでデータベースを更新するには、2.2のときと同様にマイグレーションを実行します。

$ rails db:migrate
==  CreateMicroposts: migrating =============================
-- create_table(:microposts)
   -> 0.0023s
==  CreateMicroposts: migrated (0.0026s) ======================

これでMicropostsを作成する準備ができました。作成方法は2.2.1と同じです。既に気づいたかもしれませんがscaffoldジェネレータによってRailsのroutesファイルが更新され、リスト 2.12のようにMicropostsリソース用のルールが追加されました⁸。ユーザーの場合と同様に、resources :micropostsというルーティングルールは、表 2.3で示すようにマイクロポスト用のURIをMicropostsコントローラ内のアクションに割り当てます。

Rails.application.routes.draw do
  resources :microposts
  resources :users
  root 'users#index'
end

Micropostsコントローラ自体の構造をリスト 2.13に示します。リスト 2.13の内容は、UsersControllerがMicropostsControllerに置き換わっていること以外はリスト 2.8と完全に同一である点に注目してください。これは、RESTアーキテクチャが2つのリソースに同じように反映されていることを示しています。

class MicropostsController < ApplicationController
  .
  .
  .
  def index
    .
    .
    .
  end

  def show
    .
    .
    .
  end

  def new
    .
    .
    .
  end

  def edit
    .
    .
    .
  end

  def create
    .
    .
    .
  end

  def update
    .
    .
    .
  end

  def destroy
    .
    .
    .
  end
end

マイクロポストのインデックスページで［New Micropost］をクリックして/microposts/newページをブラウザで開き（図 2.12）、新しいマイクロポストの情報を入力してマイクロポストを実際にいくつか作成してみましょう（図 2.13）。

図 2.12: マイクロポストのインデックスページ（/microposts）

図 2.13: 新しいマイクロポストの作成ページ（/microposts/new）

ここではひとまずマイクロポストを1つか2つ作成し、少なくとも片方のuser_idが1になるようにして、2.2.1で作成した最初のユーザーのidと同じにします。結果は図 2.14のようになるはずです。

図 2.14: マイクロポストのindexページに数件投稿がある状態

2.3.2 マイクロポストをマイクロにする

マイクロポストのマイクロという名前にふさわしくなるように、何らかの方法で文字数制限を与えてみましょう。Railsではこのようなとき、バリデーション（validation）を使って簡単に制限を加えることができます。例えばTwitterの元の設計に倣って140文字制限を加えたいときは、lengthを使うだけです。テキストエディタかIDEを使ってapp/models/micropost.rbを開き、リスト 2.14の内容を書き加えてみてください。

class Micropost < ApplicationRecord
  validates :content, length: { maximum: 140 }
end

リスト 2.14のコードは、これで本当に動作するのかと思えるかもしれませんが、ちゃんと動作します（検証機能については6.2でさらに詳しく説明します）。141文字以上の新規マイクロポストを投稿してみればわかります。図 2.15に示したとおり、マイクロポストの内容が長すぎるというエラーメッセージがRailsによって表示されます（エラーメッセージの詳細については7.3.3で説明します）。

図 2.15: マイクロポストの作成に失敗した場合のエラーメッセージ

2.3.3 ユーザーはたくさんマイクロポストを持っている

異なるデータモデル同士の関連付けは、Railsの強力な機能です。ここでは、1人のユーザーに対し複数のマイクロポストがあるとしましょう。UserモデルとMicropostモデルをそれぞれリスト 2.15とリスト 2.16のように更新することでこの関連付けを表現できます。

class User < ApplicationRecord
  has_many :microposts
end

class Micropost < ApplicationRecord
  belongs_to :user
  validates :content, length: { maximum: 140 }
end

この関連付けを図で表したものが図 2.16です。micropostsテーブルにはuser_idカラムを作成してあったので、それによってRailsとActive Recordがマイクロポストとユーザーを関連付けることができるようになっています。

図 2.16: マイクロポストとユーザーの関連付け

第13章と第14章では、関連付けられたユーザーとマイクロポストを同時に表示し、Twitterのようなマイクロポストのフィードを作成する予定です。ここでは、Railsのconsoleを使って、ユーザーとマイクロポストの関連付けを確認するにとどめます。Railsのconsoleは、Railsアプリケーションを対話的に操作することができる便利なツールです。

まず、ターミナルでrails consoleコマンドを入力します。続いて、User.firstと打ち込んでデータベースから1人目のユーザー情報を取り出し、first_user変数に保存します（リスト2.17）⁹。

（最後の行にはexitを置いて、コンソールを終了する方法を示しています: ほとんどのシステムでは、Ctrl-Dを押して終了することもできます）¹⁰。

$ rails console
>> first_user = User.first
   (0.5ms)  SELECT sqlite_version(*)
  User Load (0.2ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" ASC
  LIMIT ?  [["LIMIT", 1]]
 => #<User id: 1, name: "Michael Hartl", email: "michael@example.org",
 created_at: "2019-08-20 00:39:14", updated_at: "2019-08-20 00:41:24">

>> first_user.microposts
  Micropost Load (3.2ms)  SELECT "microposts".* FROM "microposts" WHERE
  "microposts"."user_id" = ? LIMIT ?  [["user_id", 1], ["LIMIT", 11]]
 => #<ActiveRecord::Associations::CollectionProxy [#<Micropost id: 1, content:
 "First micropost!", user_id: 1, created_at: "2019-08-20 02:04:13", updated_at:
 "2019-08-20 02:04:13">, #<Micropost id: 2, content: "Second micropost",
 user_id: 1, created_at: "2019-08-20 02:04:30", updated_at: "2019-08-20
 02:04:30">]>

>> micropost = first_user.microposts.first
  Micropost Load (0.2ms)  SELECT "microposts".* FROM "microposts" WHERE
  "microposts"."user_id" = ? ORDER BY "microposts"."id" ASC LIMIT ?
  [["user_id", 1], ["LIMIT", 1]]
 => #<Micropost id: 1, content: "First micropost!", user_id: 1, created_at:
 "2019-08-20 02:04:13", updated_at: "2019-08-20 02:04:13">

>> micropost.user
 => #<User id: 1, name: "Michael Hartl", email: "michael@example.org",
 created_at: "2019-08-20 00:39:14", updated_at: "2019-08-20 00:41:24"

>> exit

リスト 2.17では多くのログが表示されていますが、こういったログを頑張って読み取こうとする姿勢は「熟練」になるための欠かせない要素です（コラム 1.2）。ログには実行したSQL（Structured Query Language）や、結果として取得したRubyオブジェクトの情報が含まれています。少しだけ説明しましょう。

冒頭のfirst_user = User.firstを実行した後、リスト 2.17では次の３つを実行しています。

（1）first_user.micropostsを実行し、最初のユーザーが投稿したすべてのマイクロポストを取得します。つまりuser_idがfirst_userのid（ここでは 1）と一致するマイクロポストをすべて出力しています。

（2）上記（1）で取得できる投稿（マイクロポスト）の中から、最初の投稿をmicropost変数に保存しています。

（3）上記（2）で保存したmicropost変数から、その投稿をしたユーザー情報をmicropost.userで取得しています。

細かなRubyの文法は第4章の 2.17で、ユーザーとマイクロポストの関連付けは第13章と第14章で詳しく説明するので、今は雰囲気を掴むだけで十分です。

演習

1. ユーザーのshowページを編集し、ユーザーの最初のマイクロポストを表示してみましょう。同ファイル内の他のコードから文法を推測してみてください（コラム 1.2で紹介した技術の出番です）。うまく表示できたかどうか、/users/1 にアクセスして確認してみましょう。
2. リスト 2.18は、マイクロポストのContentが存在しているかどうかを検証するバリデーションです。マイクロポストが空でないことを検証できているかどうか、実際に試してみましょう（図 2.17のようになっていると成功です）。
3. リスト 2.19の（コードを書き込む）となっている箇所を書き換えて、Userモデルのnameとemailが存在していることを検証してみてください（図 2.18）。

リスト 2.18: マイクロポストのコンテンツが存在しているかどうかの確認 app/models/micropost.rb

class Micropost < ApplicationRecord
  belongs_to :user
  validates :content, length: { maximum: 140 },
                      presence: true
end

図 2.17: Micropostモデルの存在確認バリデーションの結果

リスト 2.19: Userモデルに存在性のバリデーションを追加する app/models/user.rb

class User < ApplicationRecord
  has_many :microposts
  validates （コードを書き込む）, presence: true    # （コードを書き込む）の中身を書き換えてください
  validates （コードを書き込む）, presence: true    # （コードを書き込む）の中身を書き換えてください
end

図 2.18: Userモデルの存在性がうまく検証できた場合の結果

2.3.4 継承の階層

最後に、Toyアプリケーションで使っているRailsのコントローラとモデルのクラス階層について簡単に解説します。この節を理解するには、多少なりともオブジェクト指向プログラミング（OOP）の経験が必要です（特にクラスを理解している必要があります）。「まだクラスを知らない」という方も心配しないでください。4.4でクラスの概念についてじっくり解説するので、ここでの説明が理解できなくても問題ありません。

最初に、モデルの継承構造について説明します。リスト 2.20とリスト 2.21を比較してみると、UserモデルとMicropostモデルはいずれも、ApplicationRecordというクラスを継承しています（Rubyでは継承関係を<記号で表現します）。また、ApplicationRecordクラスは、Active Recordが提供する基本クラス ActiveRecord::Base を継承しています。図 2.19は、このクラス間の関係をまとめたものです。このActiveRecord::Baseという基本クラスを継承したことによって、作成したモデルオブジェクトはデータベースにアクセスできるようになり、データベースのカラムをあたかもRubyの属性のように扱えるようになります。

class User < ApplicationRecord
  .
  .
  .
end

class Micropost < ApplicationRecord
  .
  .
  .
end

図 2.19: UserモデルとMicropostモデルの継承階層

コントローラの継承構造も、モデルの継承構造と本質的には同じです。リスト 2.22とリスト 2.23を比較してみると、UsersコントローラとMicropostsコントローラはいずれもApplicationControllerを継承しています。リスト 2.24をみると気づくように、ApplicationControllerがActionController::Baseというクラスを継承していることがわかります。このクラスは、RailsのAction Packというライブラリが提供しているコントローラの基本クラスです。これらのクラス同士の関係を図 2.20に示します。

class UsersController < ApplicationController
  .
  .
  .
end

class MicropostsController < ApplicationController
  .
  .
  .
end

class ApplicationController < ActionController::Base
  .
  .
  .
end

図 2.20: UsersコントローラとMicropostsコントローラにおける継承関係

モデルの継承関係と同様に、UsersコントローラもMicropostsコントローラも最終的にはActionController::Baseという基本クラスを継承しています。このため、どちらのコントローラもモデルオブジェクトの操作や、送られてくるHTTP requestのフィルタリング、ビューをHTMLとして出力するなどの多彩な機能を実行できるようになっています。Railsのコントローラは必ずApplicationControllerを継承しているので、Applicationコントローラで定義したルールは、アプリケーションのすべてのアクションに反映されます。例えば9.1では、ログインとログアウト用のヘルパーメソッドをサンプルアプリケーションのすべてのコントローラで利用できるようにしています。

2.3.5 アプリケーションをデプロイする

Micropostsリソースの説明が終わりましたので、ここでリポジトリをGitHubに登録しましょう。

$ git status    #追加の前にこうやって状態を確認するのはよい習慣です
$ git add -A
$ git commit -m "Finish toy app"
$ git push

通常、Gitのコミットはなるべくこまめに行うようにし、更新をあまりためないことが望ましいのですが、この章の締めくくりとしてサイズの大きなコミットを1度だけ行うぐらいであれば問題ありません。

この時点で、Toyアプリケーションを1.5のようにHerokuに展開してもかまいません。

$ git push heroku

（上のコマンド操作では、2.1のHerokuアプリを作成済みであることが前提です。アプリを作成していないのであれば、先にheroku create、git push heroku masterを実行してから上のコマンド操作を実行してください。）

図 2.21: Herokuのエラーページ

このような場合は、Herokuのログを調べて問題を分析します。

$ heroku logs

ログを上にスクロールしてさかのぼると、以下のような行があるはずです。

ActionView::Template::Error (PG::UndefinedTable: ERROR:  relation "users" does
not exist

「usersテーブルが見つからない」という大きなヒントを得られました。ありがたいことに、解決方法についてはリスト 2.4で説明済みです。必要なのは、データベースマイグレーションを実行することだけです（これでmicropostsテーブルもついでに作られます）。

こうしたコマンドをHerokuで実行するには、以下のように、通常のRailsコマンドの前にheroku runを追加します。

$ heroku run rails db:migrate

このコマンドを実行すると、先ほど定義したユーザーとマイクロポストのデータモデルを使って、Heroku上のデータベースが更新されます。マイグレーションが完了すれば、Toyアプリを実際のPostgreSQLデータベースをバックエンドに配置した本番環境で利用できるようになっているはずです（図 2.22）。¹¹

最後に、もし2.3.3.1の演習をやっていれば、「最初のユーザーのマイクロポストを表示する」というコードを削除する必要があることに注意してください。削除し忘れていた場合でも慌てないで。該当する行を削除して、もう一度コミットをして、そして、Herokuにpushするだけです。

図 2.22: Toyアプリを本番環境で実行する

2.4.1 本章のまとめ

• Scaffoldでコードを自動生成すると、Web上からデータモデルにアクセスし、やりとりできるようになる
• Scaffoldは素早く開発するための機能で、学習用では無いため、ScafolldだけでRailsを理解するのは難しい
• Railsでは、Webアプリケーションの構成にMVC（Model-View-Controller）というアークテクチャーを採用している
• Railsでは、HTTP requestメソッドとその送信先（URL）に応じて、呼び出されるコントローラやアクションが決まる
• Railsでは、データのバリデーション（validation）がサポートされており、データモデルの値に制限をかけることができる
• Railsには、データモデル同士を関連付けするためのさまざまなメソッド（has_manyなど）が用意されている
• Railsコンソールを使うと、コマンドラインからRailsアプリケーションを操作することができる