第2章 デモアプリケーション

http://ruby.railstutorial.org/chapters/a-demo-app#top

簡単なデモ用アプリケーションの作成をする章です。

scaffoldによるコード生成による高速なアプリケーション開発を行います。

RailsのRESTアーキテクチャの例となります。

デモアプリケーションはユーザーとそれに紐付く短い投稿(twitter風)を実装します。

アプリケーションの設計

まずは前章のようにrailsコマンドでスケルトンを生成します。

cd rails_projects
rails new demo_app
cd demo_app

次にGemfileを前章同様に書き換える

gem 'rails', '3.0.0'
gem 'sqlite3-ruby', '1.2.5', :require=>'sqlite3'

うまく動かない場合はsqlite3-rubyのバージョンを1.3.1でも試してみてください。

bundle install

bundleをインストールしたらgitでリポジトリを初期化して、初期コミットを行います。

git init
git add .
git commit -m 'initial commit.'

任意ですが、Githubにリポジトリを作成して(図2.1)pushもします。

git remote add origin git@github.com/<username>/demo_app.git
git push origin master

図2.1

ココまでが大抵のRailsアプリ開発の準備です。

開発最初のステップはアプリケーションの構造を表現するデータモデルを作成することです。

demo_appは、ユーザーと短い投稿で構成される、最小限のマイクロブログを目指します。

ユーザーモデルの作成からはじめ、投稿モデルを追加します。

ユーザーのモデリング

demo_appのユーザーモデルは最小限のデータを保持するものとします。

一意のInteger形式のid、公開されるString形式のname、ユーザー名としても機能するString形式のemailで構成します(図2.2)

ユーザーモデル(users) 図2.2

^field ^type   ^
|id    |Integer|
|name  |String |
|email |String |

投稿モデル(microposts) 図2.3

^field  ^type   ^
|id     |Integer|
|content|String |
|user_id|Integer|

後にusers、micropostsは実際のデータベースのテーブル名として使用されます。

投稿のモデリング

投稿はidと投稿の内容を保持するString型のcontentを持ちます。各投稿をユーザーに紐付けるためにuser_idのフィールドも持たせます(図2.3)

ユーザーリソース

scaffoldでユーザーリソースを生成し、アプリケーションの基礎を立ち上げます。

scaffoldにUserモデルとその属性を表現する引数を渡して実行します。

rails generate scaffold User name:string email:string

name:string email:stringを渡したことでユーザーモデルに属性を持たせました(idはRailsが自動的に割り振るので定義は必要ありません)

データベースに更新を加えるためにRakeコマンドを使いmigrateします。

rake db:migrate

データベースにはデータモデルに従ったUsersテーブルが作られました。

ここでローカルサーバを起動して動作を確認します。rails sはrails serverのショートカット版です。

rails s

立ち上がったらhttp://localhost:3000にアクセスしてみましょう。

ユーザー

scaffoldによってUserモデルを操作するページが既に生成されています。例えば、ユーザー一覧を表示するにはhttp://localhost:3000/usersに、新しいユーザーを作るには/users/newにアクセスします。

表2.1 ユーザーリソースのページとURL

|users        |index  |全てのユーザー一覧|
|users/1      |show   |IDが1のユーザーを表示|
|users/new    |new    |新しいユーザーの作成|
|users/1/edit |edit   |IDが1のユーザーを編集|

当然ですがまだユーザーはひとりもいません。(図2.4)

図2.4 ユーザーリソースの初期ページ(/users)

新しくユーザーを作るためにusers/newにアクセスします(このページは後にサインアップページとします)

見ての通り、フォームに入力してcreate userのボタンをクリックします。登録結果はusers/1で表示されます。

編集するためにはusers/1/editにアクセスし、フォームの内容を変更してupdate userボタンをクリックします。

この辺の詳しい動作については後の章で解説されます。

もう一度users/newにアクセスしてふたりめのユーザーを作成して、users/にアクセスして結果を確認します。

ユーザーを削除するには一覧画面のDestroyリンクをクリックします。確認ポップアップが表示され、OKをクリックすると削除されます(ブラウザのjavascriptが有効であることが前提です)

MVCの挙動

ユーザーリソースの動作確認をしたところでMVCパターンの説明をします。

  1. ブラウザが/usersにリクエストを発行
  2. Railsが/usersからUserコントローラーのindexアクションへルーティングする
  3. indexアクションは全てのユーザーを取得するためにUserモデルに問い合わせる(User.all)
  4. Userモデルはデータベースから全てのユーザーの情報を取得する
  5. Userモデルはコントローラーにユーザーの一覧を返す
  6. コントローラーは@users変数にユーザー一覧を格納し、indexビューへ渡す
  7. ビューは埋め込みrubyを使い、HTMLとしてレンダリングする
  8. コントローラーはブラウザにHTMLをレスポンスとして返す

ブラウザがURLをリクエストすると、URLに基づいたコントローラーとアクションに転送する、Rails Routesが応答(2.)します。

# TODO Later

ユーザーリソースの弱点

scaffoldで作成されたユーザーリソースには弱点があります。

  • バリデーションが無い:Userモデルは空の名前や間違ったメールアドレスでも許容してしまう
  • 認証が無い:ログイン/ログアウトがなく、データの操作が誰にでも出来てしまう
  • テストが無い:生成されたテストコードは醜く応用が利かなく、バリデーション、認証、その他の機能のチェックも行われない
  • レイアウトが無い:一貫したスタイルやナビゲーションが無い
  • 理解できていない:scaffoldが生成したコードが理解できるならこの本を読む必要は無いです

投稿リソース

ユーザーリソースの作成と一通りのレビューが終わったところで、投稿リソースの作業に移る。

このセクションでは投稿リソースと似たような要素を持つユーザーリソースと比較しながら進めると良いでしょう。

RailsのRESTアーキテクチャは大抵この形式で繰り返されます。ユーザーと投稿のリソースの並列な構造を見ることがこの章での主なトピックなのです。

投稿

rails generate scaffoldを使って投稿リソースを生成します。

rails generate scaffold Micropost content:string user_id:integer

Userモデルのときと同様にmigrateする

rake db:migrate

表2.3 リスト2.7の投稿リソースのRESTなルート

|GET   |/microposts        |index |全ての投稿を表示|
|GET   |/microposts/1      |show  |id=1の投稿を表示|
|GET   |/microposts/new    |new   |新しい投稿のページ|
|POST  |/microposts        |create|新しい投稿を作成|
|GET   |/microposts/1/edit |edit  |投稿の編集のページ|
|PUT   |/microposts/1      |update|投稿を更新|
|DELETE|/microposts/1      |delete|投稿を削除|

リスト2.7 投稿リソースのルールが追記されたRailsルート

DemoApp::Application.routes.draw do
  resources :microposts
  resources :users
  .
  .
  .
end

リスト2.3はUserControllerの代わりにMicropostControllerに替えると、リスト2.8のコードと同じになります。

RESTアーキテクチャが反映されて二つのリソースは共通点を持つことになります。

リスト2.8 MicropostController(app/controllers/micropost_controller.rb)

# TODO

新しく投稿するには/microposts/newにアクセスします。

投稿するときに、先ほど作ったユーザー1(ID=1)に関連づくようにuser_idに1を入れた投稿を最低一つは作ってください。

Micropostsを少し更新

投稿に140文字の制限(twitter風)を文字列長バリデーションによって実装します。

app/model/micropost.rbを開いて以下のように書き加えます。

(validatesメソッドを使っていますがコレはrails3での記述。rails2.3系互換にしたい場合はvalidates_lenght_ofメソッドを使う)

class Micropost < ActiveRecord::Base
  validattes :content, :length=>{ :maximum => 140 }
end

保存したらすぐに有効になっているので、/microposts/newを開いて、contentフォームに141文字以上入力して、エラーメッセージが出ることを確認してください。

A User has_many Microposts

Railsには、他のデータモデルとの関連づけを定義できる、という強力な機能があります。

今回の場合は、各ユーザーにはたくさんの投稿紐づくことになります。

UserモデルとMicropostモデルの追記によってそれを定義することが出来ます。

# app/model/user.rb
class User < ActiveRecord::Base
   has_many :microposts
end

# app/model/micropost.rb
class Micropost< ActiveRecord::Base
  belongs_to :user

  validattes :content, :length=>{ :maximum => 140 }
end

この関連は11、12章で、あるユーザーの全ての投稿を表示したり、twitter風にフィードを生成したりするのに使います。

ここでrailsをインタラクティブに操作できるツールのconsoleを使ってuser-micropostsの関連をチェックしてみます。

ターミナルでrails commandを実行し、User.first()でデータベースから最初のユーザーを取り出します(first_user変数に格納します)

rails console
ruby-1.9.2-p180 :001 > first_user = User.first
=> #<User id: 1, name: "hoe", email: "hoe@example.com", created_at: "2011-05-03 15:37:30", updated_at: "2011-05-03 15:37:30">
ruby-1.9.2-p180 :002 > first_user.microposts
=> [#<Micropost id: 1, content: "first micropost", user_id: 1, created_at: "2011-05-05 03:03:57", updated_at: "2011-05-05 03:03:57">]

first_user.micropostsを使ってこのユーザーの投稿を取得することが出来ました。

user_idがfirst_userのid(この場合は1)に一致する投稿をActiveRecordが自動的に取ってきてくれるのです。

継承階層

いままでdemo_appを作る中でやってきたようなコントローラーとモデルクラスの簡単な継承の説明は終わりにします。

オブジェクト指向 (OOP)に触れたことがある人にとってはより理解を深めることになるでしょう。

もし全くOOPの経験が無い場合、このセクションを飛ばしてもかまいません。特にクラス(セクション4.4で取り扱います)について親しみが無ければ、後で読み返すことをお勧めします。

モデルの継承構造から始めます。

# TODO LATER

demo_appのデプロイ

投稿リソースも完成したところでGithubにプッシュするにはキリのよい段階です。

git add .
git commit -a -m 'Done with the demo app'
git push

さらにHerokuにもデプロイしましょう。

heroku create
git push heroku master
heroku rake db:migrate

(もしうまく行かない場合はリスト1.8の修正を参照してください)

最後の行に注目してください。これはHerokuサーバー上でデータベースのmigrationを行っています。

このデータベースのアップデートはUserとMicropostモデルの為に必須です。

さらにデータもプッシュしたい場合は、gemでtapsをインストールして、db:pushコマンドを使用します。

gem install taps
heroku db:push

最後に

この章で開発したdemo_appはいくつかの強みと弱点を持っています。

強み

  • Railsの高度な概略
  • MVCの紹介
  • RESTアーキテクチャの採用
  • データモデリングの取り組み
  • 本稼働するデータベースバックエンドウェブアプリケーションの作成

弱点

  • ユーザー画像無し
  • ログイン機能無し
  • 安全性無し
  • ユーザーと投稿の結びつけが自動ではない
  • フォローする、フォローされているが無い
  • 投稿のフィードが無い
  • テスト駆動開発していない
  • 真の理解が出来ていない

残りのチュートリアルでは強みの上に構築することと、弱点を取り除くことに費やしていきます。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする