1.1.1 前提知識

本チュートリアルで学ぶうえで必要となる前提知識は、「公式には」ありません。Railsチュートリアルには必要な要素がすべて盛り込まれています。中心となるのはもちろんRailsですが、他にもRuby言語やminitest (Railsのテスティングフレームワーク) 、HTML、CSS、若干のJavaScriptとSQLのチュートリアルもあります。これまでにも、驚くほど多くの初心者がRuby on Railsチュートリアルで学んできた実績があります。Web開発経験の少ない方も、まずは挑戦してみるのがよいと思います。学習中に知識不足を実感する箇所が出てきたら、この後でご紹介する資料でいつでも学び直してから先に進めばよいのです。「チュートリアルを2回通して行う」という方法もお勧めです。続けてもう一度やってみると、1回目のときよりもずっと知識が身に付いたことを実感できますし、2度目にはもっと短い時間で終えられるでしょう。

「先にRubyを勉強してからRailsを学ぶ方が良いでしょうか？」という質問をよく受けます。この質問への回答ですが、読者の学習スタイルやプログラミング経験次第で異なるため、一口には言えません。Web開発を最初から体系的に学びたい方や、プログラミングの経験が全くない方は、やはりRubyを最初に学んでおくのがよいでしょう。Peter Cooperの『Beginning Ruby』がお勧めです。その一方で、これからRailsで開発を始めようとする人は「とにかくWebアプリケーションを作りたい！」と考えていることがほとんどなので、たった1つのWebページを作成するために分厚いRuby本を一気読みする気にはなれないでしょう。Rubyの概要を急いで学びたいのであれば、Rubyを対話的に学習できるWebサービスTry Ruby³をやってから本チュートリアルを学ぶことをお勧めします。本チュートリアルが自分にはまだまだ難しいと思う方には、Learn Ruby on Rails (Daniel Kehoe) やOne Month Railsを先に学んでおくとよいでしょう。どちらもまったくの初心者を対象としており、本チュートリアルよりも敷居が低く設定されています。

本チュートリアルを読み終える頃には、取り組み前の知識量の多少にかかわらず、より高度なRailsの情報源を理解できるようになっているはずです。その中でも特にお勧めのRailsの情報源を紹介します。

• Code School: プログラミングを対話的に学習できるコース
• Turing School of Software & Design: コロラド州デンバーで開催されているフルタイム27週間のトレーニングプログラムです。本チュートリアルの読者であれば、RAILSTUTORIAL500のコードを使用して500ドルの割引サービスを受けられます。
• Bloc: 体系化されたカリキュラムを使った、オンライン上のブートキャンプで、参加者に応じて適切なメンターを配置したり、プロジェクトを通した学習に特化している点が特長です。RAILSTUTORIAL500というクーポンコードを使うと、入会費を500ドル割引できます。
• Tealeaf Academy: オンラインで受講できるRails開発ブートキャンプです。高度な資料も充実しています。
• Thinkful: プロのエンジニアと組んでプロジェクトベースで授業を進めるオンラインクラスです。
• Pragmatic Studio: Mike ClarkとNicole Clarkが教鞭を執っているオンラインのRailsクラスです。2006年に筆者が受講したRailsのコースでは、Mikeの他にProgramming Rubyの著者Dave Thomasも講師を務めていました
• RailsCasts (Ryan Bates) : 極めて質の高い (ほぼ) 無料のスクリーンキャストです。
• RailsApps: さまざまなRailsプロジェクトやチュートリアルがトピック別に詳しく特集されています。
• Railsガイド: トピック毎に分類された最新のRailsリファレンスです (訳注: RailsGuidesの日本語版を「Railsガイド」と呼んでいます。)

1.1.2 本チュートリアルの記法について

本チュートリアルで使用している取り決めや表記は、説明不要なものがほとんどです。ここでは、説明が必要と思われるものについてのみ補足します。

本チュートリアルでは、コマンドライン (ターミナル) のコマンド例が多用されています。簡素化のため、次のようなUnixスタイルのプロンプト (行の頭に「$」を表示するスタイル) を使用して、その例がコマンドラインであることを示しています。

$ echo "hello, world"
hello, world

1.2でも述べているように、本チュートリアルではUnixコマンドラインを最初から利用できるクラウド開発環境の利用 (1.2.1) を、すべてのOSユーザー (特にWindows) の方におすすめしています。Railsにはコマンドラインから実行するコマンドが多数あるので、最初からコマンドラインが利用できるクラウドは非常に便利です。たとえば、1.3.2では以下のrails serverコマンドでローカルdevelopment Webサーバーを実行しています。

$ rails server

Railsチュートリアルにおけるディレクトリの区切りは、コマンドラインのプロンプトと同様にUnixスタイルのスラッシュ「/」を使っています。たとえば、サンプルアプリケーションproduction.rbの設定ファイルは以下のように表します。

config/environments/production.rb

このようなファイルパスは、アプリケーションのルートディレクトリからの相対パスであると理解してください。ルートディレクトリの位置はシステムによって異なり、このクラウドIDE (1.2.1) の場合は以下のようになります。

/home/ubuntu/workspace/sample_app/

この場合、production.rbへの絶対パスは以下のようになります。

/home/ubuntu/workspace/sample_app/config/environments/production.rb

表記を簡単にするため、本チュートリアルでは原則としてconfig/environments/production.rbと記述し、ルートディレクトリより上のパスは省略します。

Railsチュートリアルでは、様々なプログラムの出力結果 (シェルコマンド、バージョン管理ツール、Rubyプログラムの出力結果など) をこまめに記載するようにしています。出力結果は、コンピュータシステムによって微妙に異なるので、本チュートリアルの出力結果と実際の出力が正確に一致するとは限りません。しかし、こうした細かい出力結果の差異が問題になることはないので、それほど気にする必要はありません。コンピュータシステムによっては、コマンドを実行した時にエラーが発生するかもしれません。しかし本チュートリアルでは、あらゆる場面を想定してエラー対策をもれなく記載するような不毛な作業は行っていません。そのような場合は、即座にエラーメッセージをGoogleで検索してください。エラーメッセージをGoogleで検索することは、実際のソフトウェア開発でも使われている基本的なテクニックなので、よい練習にもなります。本チュートリアルのチュートリアルを進めていくうちに何か問題が生じたら、Railsチュートリアルのヘルプ⁴に記載されているリソースをご覧ください。

RailsチュートリアルではRailsアプリケーションのテスティングも扱っているので、コードでどんなことをするとテストスイートが失敗 (赤色で表示)し、どうするとテストスイートがパス (緑色で表示) するかを実地で学べるようになっています。本チュートリアルでは読みやすさのため、テストが失敗するコードをRED、テストがパスするコードをGREENで表記します。

チュートリアルの各章の最後には演習問題を配置しました。必須ではありませんが、挑戦をおすすめします。本編と演習問題を分けるために、その後のコードリストには原則として解答を付けていません。演習の解答が少ない分、本編で解答を示すようにしています。

最後に、Ruby on Railsチュートリアルで使用されている多くのサンプルコードをわかりやすく記述するために、2つの工夫を加えました。1つは、コードの重要な部分にハイライトを追加したことです。

class User < ActiveRecord::Base
  validates :name,  presence: true
  validates :email, presence: true
end

ハイライト行は通常、コードに追加された行を示しますが、その前に示したコードとの違いを強調していることもよくあります (常にというわけではありませんが)。2つ目は、長いコードの途中を次のように垂直連続ドットで省略したことです。

class User < ActiveRecord::Base
  .
  .
  .
  has_secure_password
end

連続ドットは省略を表しているので、他のコードと一緒にコピーしないようご注意ください

1.2.1 開発環境

開発環境は、Railsプログラマ一人ひとりすべて異なります。開発者は慣れてくるに従い、自分の環境を徹底的にカスタマイズするものだからです。開発環境を大別すると、テキストエディタやコマンドラインを使う環境と、IDE (統合開発環境) の2つに分けられます。そしてRuby on Railsチュートリアルでは、複雑さを避けるためにCloud9という素晴らしいクラウドIDEサービスを使って進めていきます。特に今回の第3版では、Cloud9と提携して読者の皆様にチュートリアル用に最適化された開発環境を提供できたことを心から嬉しく思っています。このようにして構築したRailsチュートリアル用Cloud9ワークスペースには、Ruby、RubyGems、Gitなど、プロ級のRails開発環境に必要なソフトウェアがすべて組み込まれています。Railsだけはインストールされていませんが、これはもちろんチュートリアルのために意図的にそうしてあります (1.2.2)。このクラウドIDEには他にも、Web開発に必要な三種の神器であるテキストエディタ、ファイルブラウザ、コマンドラインターミナル (図1.1) もしっかり組み込んであります。また、クラウドIDEのテキストエディタでは、Ruby on Railsの大きなプロジェクトには不可欠とも言うべきグローバルファイル検索も利用できます⁶。最後にこのクラウドIDEですが、たとえ今後使うことがないとしても (筆者としても、他のエディタの使い方もぜひ知っておく必要があると考えています)、テキストエディタなどの開発ツールで一般にどんなことができるのかを知っておくには最適です。

図1.1: クラウドIDEの外観

クラウド開発環境を利用するための手順は次のとおりです。

1. Cloud9⁷でユーザー登録 (無料) を行います。
   (注意: Cloud9を悪用するケースが増えたため、2016年7月よりクレジットカードの入力が必須になりました。後述の手順でRailsチュートリアル専用のワークスペースを作成すれば課金されることはありませんが、Freeプランから別のプランにアップグレードすると課金されるようになるのでご注意ください)
2. [Go to your Dashboard] をクリックします。
3. [Create New Workspace] を選択します。
4. 図1.2に示したように、「rails-tutorial」(「rails_tutorial」にしないようご注意ください) というワークスペース名を入力し、[Private to the people I invite] を選択し、Railsチュートリアルのアイコン (Ruby on Railsのアイコンではありません) を設定します。
5. [Create] をクリックします。
6. Cloud9でのワークスペースの準備が完了したら、ワークスペースを選択して [Start editing] をクリックします。

Rubyの世界では、インデントに2つのスペースを使用するのがほぼ常識になっているので、このエディタのインデント設定もデフォルトの4から2に変えておくことをおすすめします。インデント設定を変更するには、右上の歯車アイコンをクリックして [Code Editor (Ace)] を選択し、[Soft Tabs] 設定を開いて編集します (図 1.3)。設定の変更はその場で反映されるので、[Save] ボタンをクリックする必要はありません。

図 1.2: Cloud9に新しいワークスペースを作成する。

図 1.3: Cloud9でインデントをスペース2つに設定する。

1.2.2 Railsをインストールする

1.2.1の開発環境には、必要なソフトウェアがすべて含まれていますが、Railsだけは含まれていません⁸。Railsをインストールするには、gemというコマンドを使用します。このコマンドは、RubyGemsというパッケージマネージャによって提供されているもので、リスト1.1のコマンドをコマンドラインターミナルに入力するときに使用します。なお、ローカルシステム上で開発する場合は普通のターミナルを使用します。クラウドIDEを使用している場合は、図1.1のコマンドラインエリアに入力します。

$ gem install rails -v 4.2.2

コマンドの後ろにある-vフラグによって、インストールするRailsのバージョンを指定できます。本チュートリアルではすべてこのバージョンを前提としていますので、バージョン番号を変えるとチュートリアルと異なる結果になる可能性があります。

1.3.1 Bundler

Railsアプリケーションを新規作成したら、次はBundlerを実行して、アプリケーションに必要なgemをインストールおよびインクルードします。1.3でも簡単に説明したように、Bundlerはrailsによって自動的に実行 (この場合はbundle install) されます。ここではデフォルトのアプリケーションgemを変更してBundlerを再度実行してみます。そのために、テキストエディタでGemfileを開きます (クラウドIDEの場合は、ファイルナビゲーターで矢印をクリックしてサンプルアプリのディレクトリを開き、Gemfileアイコンをダブルクリックします)。Gemfileの内容は、だいたい図1.5やリスト1.4のようになります。バージョン番号など細かな点で多少の違いがあるかもしれません。Gemfileの内容はRubyのコードですが、今は文法を気にする必要はありません。Rubyの詳細については第4章で説明します。ファイルやディレクトリが図1.5のように表示されない場合、ナビゲーターの歯車アイコンをクリックして [Refresh File Tree] を選択します (一般に、ファイルやディレクトリがうまく表示されていない場合はこのようにファイルツリーを再表示してみてください)。

図1.5: デフォルトのGemfileをテキストエディタで開く。

source 'https://rubygems.org'


# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '4.2.2'
# Use sqlite3 as the database for Active Record
gem 'sqlite3'
# Use SCSS for stylesheets
gem 'sass-rails', '~> 5.0'
# Use Uglifier as compressor for JavaScript assets
gem 'uglifier', '>= 1.3.0'
# Use CoffeeScript for .js.coffee assets and views
gem 'coffee-rails', '~> 4.0.0'
# See https://github.com/sstephenson/execjs#readme for more supported runtimes
# gem 'therubyracer', platforms: :ruby

# Use jquery as the JavaScript library
gem 'jquery-rails'
# Turbolinks makes following links in your web application faster. Read more:
# https://github.com/rails/turbolinks
gem 'turbolinks'
# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder
gem 'jbuilder', '~> 2.0'
# bundle exec rake doc:rails generates the API under doc/api.
gem 'sdoc', '~> 0.4.0', group: :doc

# Use ActiveModel has_secure_password
# gem 'bcrypt', '~> 3.1.7'

# Use Unicorn as the app server
# gem 'unicorn'

# Use Capistrano for deployment
# gem 'capistrano-rails', group: :development

group :development, :test do
  # Call 'debugger' anywhere in the code to stop execution and get a
  # debugger console
  gem 'byebug'

  # Access an IRB console on exceptions page and /console in development
  gem 'web-console', '~> 2.0.0.beta2'

  # Spring speeds up development by keeping your application running in the
  # background. Read more: https://github.com/rails/spring
  gem 'spring'
end

ほとんどの行はハッシュシンボル #でコメントされています。これらの行では、よく使われているgemとBundlerの文法の例をコメント形式で紹介しています。この時点では、デフォルト以外のgemをインストールする必要はありません。

gemコマンドで特定のバージョン番号を指定しない限り、Bundlerは自動的に最新バージョンのgemを取得してインストールします。たとえば、Gemfileに以下のような記述があるとします。

gem 'sqlite3'

このsqlite3というgemのバージョンを指定する主な方法は2とおりあります。これにより、Railsで使用されるgemのバージョンを「ある程度」制御できます。1番目の方法は次のとおりです。

gem 'uglifier', '>= 1.3.0'

uglifierのバージョンが1.3.0以上であれば最新バージョンのgemがインストールされます。極端に言えば、バージョンが7.2であってもそれが最新ならインストールされます (なお、uglifierはAsset Pipelineでファイル圧縮を行うためのものです)。2番目の方法は次のとおりです。

gem 'coffee-rails', '~> 4.0.0'

このように指定すると、coffee-rails (これもAsset Pipelineで使用するgemです) のバージョンが4.0.0より大きく、4.1より小さい場合にインストールされます。つまり、>=という記法を使用すると常に最新のgemがインストールされ、~> 4.0.0という記法を使用するとマイナーバージョンの部分に相当するアップデート済みのgem (例: 4.0.0から4.0.1) をインストールします。後者の場合、メジャーバージョン (例: 4.0から4.1) のリリースはインストールされません。経験上、残念ながらちょっとしたマイナーアップグレードですら問題を引き起こすことがあります。このため、Railsチュートリアルでは基本的に事実上すべてのgemでバージョンを「ピンポイントで」指定し、がっちり固定してあります。ベテラン開発者であれば、Gemfileで~>が指定されているgemも含め、基本的に最新のgemを使用しても構いません。ただし、それによって本チュートリアルに記載されている挙動と異なる可能性がありますので、その場合は各自でご対応願います。

リスト1.4のGemfileを、実際に使用する正確なバージョンのgemに置き換えたものをリスト1.5に示します。なお、この置換えのついでに、sqlite3 gemをdevelopment環境とtest環境 (7.1.1) だけで使用する (つまりproduction環境では使用しない) ように変更している点にもご注目ください。これは、後でHerokuで使用するデータベースと競合する可能性を防ぐための処置です (1.5)。

source 'https://rubygems.org'

gem 'rails',                '4.2.2'
gem 'sass-rails',           '5.0.2'
gem 'uglifier',             '2.5.3'
gem 'coffee-rails',         '4.1.0'
gem 'jquery-rails',         '4.0.3'
gem 'turbolinks',           '2.3.0'
gem 'jbuilder',             '2.2.3'
gem 'sdoc',                 '0.4.0', group: :doc

group :development, :test do
  gem 'sqlite3',     '1.3.9'
  gem 'byebug',      '3.4.0'
  gem 'web-console', '2.0.0.beta3'
  gem 'spring',      '1.1.3'
end

アプリケーションのGemfileの内容をリスト1.5で置き換えたら、bundle installを実行してgemをインストールします⁹。

$ cd hello_app/
$ bundle install
Fetching source index for https://rubygems.org/
.
.
.

bundle installコマンドの実行にはしばらく時間がかかるかもしれません。完了後、アプリケーションが実行可能になります。

1.3.2 rails server

1.3のrails newコマンドと1.3.1のbundle installコマンドを実行したことにより、実際に動かすことのできるアプリケーションが作成されました。ありがたいことに、Railsには開発マシンでのみブラウズできるローカルWebサーバーを起動するためのコマンドラインプログラム (スクリプト) が付属しているので、以下のコマンドを実行するだけでRailsアプリケーションを簡単に起動することができます。現在の環境に応じてアプリケーションを起動する正確なコマンドは次のとおりです。ローカルシステムの場合は、rails serverを実行するだけで済みます (リスト1.6)。Cloud9の場合は、IPバインディングアドレスとポート番号も指定する必要があります。(リスト1.7)¹⁰。これらの値は、クラウドの外からRailsサーバーにアクセスするために使用されます (Cloud9 では特殊な環境変数「$IP」と「$PORT」を使用してIPアドレスとポート番号を動的に割り当てます。コマンドラインでecho $IPまたはecho $PORTと入力すると値を確認できます)。JavaScriptランタイムがインストールされていないというエラーが表示された場合は、GitHubのexecjsページにあるインストール可能なランタイムの一覧からJavaScriptランタイムを入手してください。個人的にはNode.jsがおすすめです。

$ cd ~/workspace/hello_app/
$ rails server
=> Booting WEBrick
=> Rails application starting on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server

$ cd ~/workspace/hello_app/
$ rails server -b $IP -p $PORT
=> Booting WEBrick
=> Rails application starting on http://0.0.0.0:8080
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server

どちらのオプションを使用する場合であっても、rails serverコマンドの実行は別のターミナルタブで行うことをおすすめします。こうしておけば、rails serverコマンドに邪魔されずに、最初のターミナルタブで他のコマンドを実行できるからです図1.6と図1.7。既に最初のタブでサーバーを開始している場合は、Ctrl+Cを押すとサーバーを終了できます¹¹。Railsアプリケーションを表示するには、ローカルサーバーの場合はhttp://localhost:3000/をブラウザで開きます。クラウドIDEの場合は、[Share] を開いて、開きたいアプリケーションのアドレスをクリックします (図1.8)。どちらの場合も、図1.9のようにブラウザにRailsアプリケーションが表示されます。

図1.6: 新しいターミナルタブを開く。

図1.7: 別のタブでRailsサーバーを実行する。

図1.8: クラウドワークスペース上で実行しているローカルサーバーを共有する。

図1.9: rails serverを実行したときのデフォルトのRailsページ。

最初のアプリケーションに関する情報を表示するには、画面の [About your application’s environment] リンクをクリックします。図1.10のように詳細な情報が表示されます (バージョン番号などは異なることもあります)。もちろん、いずれデフォルトのRailsページは不要になりますが、アプリケーションが動いているのを見るのは気分のいいものです。1.3.4ではこのデフォルトページを削除し、カスタマイズしたホームページに置き換える予定です。

図1.10: アプリケーション環境が表示されているデフォルトページ。

1.3.3 Model-View-Controller (MVC)

まだ始まったばかりですが、今のうちにRailsアプリケーションの全体的な仕組みを知っておくことは後々役立ちます (図1.11)。デフォルトのRailsアプリ構造 (図1.4) を眺めてみると、app/というディレクトリがあり、その中に「models」「views」「controllers」という3つのサブディレクトリがあることにお気付きでしょうか。RailsがMVC (model-view-controller) というアーキテクチャパターンを採用していることがここに示されています。MVCでは、ドメインロジック (ビジネスロジックともいいます) を入力/表示ロジック (GUI と密に関連します) から分離します。Webアプリケーションの場合、「ドメインロジック」はユーザーや記事、商品などのデータモデルに相当し、GUIはWebページを指します。

Railsアプリと通信する際、ブラウザは一般的にWebサーバーにrequest (リクエスト) を送信し、これはリクエストを処理する役割を担っているRailsのcontroller (コントローラ) に渡されます。コントローラは、場合によってはすぐにview (ビュー) を生成してHTMLをブラウザに送り返します。動的なサイトでは、一般にコントローラは (ユーザーなどの) サイトの要素を表しており、データベースとの通信を担当しているRubyのオブジェクトであるmodel (モデル) と対話します。モデルを呼び出した後、コントローラは、ビューをレンダリングし、完成したWebページをHTMLとしてブラウザに返します。

図1.11 model-view-controller (MVC) アーキテクチャの概念図

今はまだこの解説が少し抽象的に思えるかもしれませんが、この章は後に何度も参照する事になるのでご安心ください。1.3.4ではMVCを使用するお試しアプリケーションをご覧に入れます。2.2.2では、このtoyアプリを使ってMVCの詳細を解説します。サンプルアプリケーションでは、MVCの3つの要素をすべて使用します。3.2ではまずコントローラとビューを使用し、モデルは6.1から使い始めます。 7.1.2では3つの要素が協調して動作します。

1.3.4 Hello, world!

記念すべき最初のMVCフレームワークアプリケーションとして、先ほど作ったアプリにほんのちょっぴり変更を加えることにしましょう。「Hello World」という文字列を表示するだけのコントローラのアクションを追加します (コントローラのアクションについては2.2.2で詳しく解説します)。この改造が終わると、デフォルトのRailsページは図1.9のように「hello, world」ページが表示されます。これがこのセクションでの目標です。

名前から想像されるように、コントローラのアクションはコントローラ内で定義します。ここでは、Applicationという名前のコントローラの中にhelloという名前のアクションを作成することにします。実際、この時点ではコントローラはApplicationひとつしかありません。次のコマンドを実行すると、現在あるコントローラを確認できます。

$ ls app/controllers/*_controller.rb

新しいコントローラの作成は第2章で行います。リスト1.8に、helloを定義したところを示します。ここではrender関数で「hello, world!」というテキストを表示しています。この時点ではRubyの文法については気にする必要はありません。第4章で詳しく解説します。

class ApplicationController < ActionController::Base
  # Prevent CSRF attacks by raising an exception.
  # For APIs, you may want to use :null_session instead.
  protect_from_forgery with: :exception

  def hello
    render text: "hello, world!"
  end
end

表示したい文字列を返すアクションを定義したので、今度はデフォルトのページ (図1.10) の代わりにこのアクションを使用するようRailsに指示します。そのためには、Railsのルーター (router) を編集します。ルーターはコントローラとブラウザの間に配置され (図1.11)、ブラウザからのリクエストをコントローラに振り分ける (=ルーティング) 役割を果たします (図1.11では簡単のためルーターは省略していますが、2.2.2で詳しく解説します)。ここではデフォルトのページを差し替えたいので、ルートのルーティング (ルート URLにアクセスした場合のルーティング) を変更することにします。たとえばhttp://www.example.com/というURLの末尾は「/」になっているので、ルートURLは単に「/」(スラッシュ) と簡略表記することもあります (訳注: 本チュートリアルではrouteやroutingを「ルーティング」、rootを「ルート」と表記します)。

リスト1.9に示したように、Railsのルーティングファイル (config/routes.rb) には、ルートルーティングの構成方法がコメント行に示されています。「welcome」はコントローラ名、「index」はコントローラ内のアクションです。ルートルーティングを有効にするには、「#」文字を削除してコメントを解除し、コードを書き換えます (リスト1.10)。これにより、RailsのルートルーティングにアクセスするとApplicationコントローラのhelloアクションが動作します (1.1.2でも説明したとおり、途中のドットだけの行は省略を意味しているので、その部分はそのままコピーしないでください)。

Rails.application.routes.draw do
  .
  .
  .
  # You can have the root of your site routed with "root"
  # root 'welcome#index'
  .
  .
  .
end

Rails.application.routes.draw do
  .
  .
  .
  # You can have the root of your site routed with "root"
  root 'application#hello'
  .
  .
  .
end

リスト1.8のコードとリスト1.10のコードを使用すると、期待どおりルートルーティングから「hello, world!」が返されるようになります (図1.12)。

図1.12: 「hello, world!」をブラウザで表示する。

1.4.1 インストールとセットアップ

推奨環境であるクラウドIDE (1.2.1) にはデフォルトでGitが導入されていますので、追加で導入する必要はありません。その他の場合は、InstallRails.com (1.2) の指示に従ってGitをシステムに導入してください。

$ git config --global user.name "Your Name"
$ git config --global user.email your.email@example.com
$ git config --global push.default matching
$ git config --global alias.co checkout

$ git init
Initialized empty Git repository in /home/ubuntu/workspace/hello_app/.git/

$ git add -A

$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

  new file:   .gitignore
  new file:   Gemfile
  new file:   Gemfile.lock
  new file:   README.rdoc
  new file:   Rakefile
  .
  .
  .

$ git commit -m "Initialize repository"
[master (root-commit) df0a62f] Initialize repository
.
.
.

$ git log
commit df0a62f3f091e53ffa799309b3e32c27b0b38eb4
Author: Michael Hartl <michael@michaelhartl.com>
Date:   Wed August 20 19:44:43 2014 +0000

    Initialize repository

1.4.2 Gitのメリット

今の時点では、ソースコードをバージョン管理下に置かなければならない理由が今ひとつよくわからないという方がいるかもしれませんので、例を1つご紹介します。仮に、あなたが重要なapp/controllers/ディレクトリを削除してしまったとしましょう。

$ ls app/controllers/
application_controller.rb  concerns/
$ rm -rf app/controllers/
$ ls app/controllers/
ls: app/controllers/: No such file or directory

ここでは、Unixコマンドのlsでapp/controllers/ディレクトリの中身を表示した後、rmコマンドをうっかり実行してこのディレクトリを削除してしまったとします (表1.1)。-rfフラグは、「recursive」(サブディレクトリやその中のファイルもすべて削除する) と「force」(削除して良いかどうかをユーザーに確認しない) を指定するオプションです。

現在の状態を確認してみましょう。

$ git status
On branch master
Changed but not updated:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

      deleted:    app/controllers/application_controller.rb

no changes added to commit (use "git add" and/or "git commit -a")

ファイルがいくつか削除されましたが、この変更が行われたのは現在の「作業ツリー」内のみなので、まだコミット (保存) されていません。つまり、以前のコミットをcheckoutコマンド (と、現在までの変更を強制的に上書きして元に戻すための-fフラグ) でチェックアウトすれば、簡単に削除前の状態に戻すことができます。

$ git checkout -f
$ git status
# On branch master
nothing to commit (working directory clean)
$ ls app/controllers/
application_controller.rb  concerns/

削除されたディレクトリとファイルを無事復旧できました。これでひと安心です。

1.4.3 Bitbucket

Gitを使用してプロジェクトをバージョン管理下に置くことができたので、今度はBitbucketにソースコードをアップロードしてみましょう。BitbucketはGitリポジトリのホスティングと共有に特化したサイトです (以前のチュートリアルではGitHubをリポジトリとして使用していました。乗り換えた理由についてはコラム1.4をご覧ください)。リポジトリをBitbucketにわざわざプッシュするのには2つの理由があります。１つ目は、ソースコード (とそのすべての変更履歴) の完全なバックアップを作成することです。２つ目は、他の開発者との共同作業をより簡単に行うことです。

Bitbucketの利用開始は簡単です。

1. Bitbucketアカウントがない場合はアカウントを作成します。
2. 公開鍵をクリップボードにコピーします。リスト1.11に示したように、クラウドIDEを使用していればcatコマンドで公開鍵を表示できるので、それを選択、コピーします。クラウドIDEを使用しておらず、リスト1.11のコマンドを実行しても何も表示されない場合は、Bitbucketアカウントに公開鍵をインストールする方法 (英語) を参照してください。
3. Bitbucketに公開鍵を追加するには、右上にあるアバター画像をクリックして [Manage account]、[SSH keys] の順に選択します (図1.13)。

$ cat ~/.ssh/id_rsa.pub

図1.13: SSH公開鍵を追加する。

公開鍵の追加が終わったら、[Create] をクリックして新しいリポジトリを作成します 図1.14)。プロジェクトの情報を入力したら、[This is a private repository] チェックボックスが「オン」になっていることを確認します (オフにしないでください!)。[Create repository] をクリックしてリポジトリを作成したら、[Command line] > [I have an existing project] をクリックしてそこに表示される指示に従います (リスト1.12)。リスト1.12のように表示されない場合は、公開鍵が正しく追加されていない可能性がありますので、公開鍵の追加をやり直すことをおすすめします。リポジトリをプッシュするときに「Are you sure you want to continue connecting (yes/no)?」と表示されたらyesと入力します。

図1.14: Bitbucketに最初のアプリのリポジトリを作成する。

$ git remote add origin git@bitbucket.org:<username>/hello_app.git
$ git push -u origin --all # リポジトリとブランチをすべてプッシュする

リスト1.12の最初のコマンドは、BitbucketをリポジトリのoriginとしてGitの設定ファイルに追加するためのものです。次のコマンドでは、ローカルのリポジトリをリモートのoriginにプッシュします （-uフラグについては気にする必要はありません。気になるのであれば "git set upstream"で検索してみてください）。もちろん、<username>は自分の名前に置き換えてください。たとえば、著者が実行したコマンドは以下のとおりです。

$ git remote add origin git@bitbucket.org:mhartl/hello_app.git

上のコマンドを実行すると、hello_appのリポジトリのページがBitbucketに作成されます。このページでは、ファイルの参照、全コミット履歴などさまざまな機能を利用できます (図1.15)。

図1.15: Bitbucketのリポジトリページ。

1.4.4 ブランチ (branch)、変更 (edit)、 コミット (commit)、マージ (merge)

1.4.3の手順に沿って進めた場合、README.rdocファイルが自動的に認識されず、READMEがないというメッセージが表示されることに気付いたでしょう (図1.16)。この表示は、rdoc形式がBitbucketでは標準のREADMEとしてサポートされていないために起こります。実のところ、著者も含めほとんどの開発者はMarkdown形式を使用しています。ここではREADME.rdocファイルの名前をREADME.mdに変更し、チュートリアル中にコンテンツを追加できるようにしておきましょう。それと同時に、Gitでbranch、edit、commit、mergeを行う際にお勧めのワークフローの実例をご覧いただきます¹³。

図1.16: Bitbucketで表示される「READMEが見つからない」メッセージ。

$ git checkout -b modify-README
Switched to a new branch 'modify-README'
$ git branch
  master
* modify-README

$ git mv README.rdoc README.md

# Ruby on Rails Tutorial: "hello, world!"

This is the first application for the
[*Ruby on Rails Tutorial*](http://www.railstutorial.org/)
by [Michael Hartl](http://www.michaelhartl.com/).

$ git status
On branch modify-README
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

  renamed:    README.rdoc -> README.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

  modified:   README.md

$ git commit -a -m "Improve the README file"
2 files changed, 5 insertions(+), 243 deletions(-)
delete mode 100644 README.rdoc
create mode 100644 README.md

$ git checkout master
Switched to branch 'master'
$ git merge modify-README
Updating 34f06b7..2c92bef
Fast forward
README.rdoc     |  243 --------------------------------------------------
README.md       |    5 +
2 files changed, 5 insertions(+), 243 deletions(-)
delete mode 100644 README.rdoc
create mode 100644 README.md

$ git branch -d modify-README
Deleted branch modify-README (was 2c92bef).

# 以下の操作は説明用です。ブランチを汚してしまったとき以外は行わないでください。
$ git checkout -b topic-branch
$ <really screw up the branch>
$ git add -A
$ git commit -a -m "Major screw up"
$ git checkout master
$ git branch -D topic-branch

プッシュ (push)

READMEファイルの更新が終わったので、Bitbucketに変更をプッシュして結果を見てみましょう。既に1.4.3で一度プッシュを行ったので、大抵のシステムではgit pushを実行するときにorigin masterを省略できます。

$ git push

1.4.4.2で約束したとおり、Markdownで記述したファイルがBitbucket上できれいに整形されました (図1.17)。

図1.17 Markdowndでフォーマットされた改良版READMEファイル

1.5.1 Herokuのセットアップ

HerokuではPostgreSQLデータベースを使用します (ちなみに発音は “post-gres-cue-ell” で、よく“Postgres”と略されます)。そのためには、本番 (production) 環境にpg gemをインストールしてRailsがPostgreSQLと通信できるようにします¹⁷。

group :production do
  gem 'pg',             '0.17.1'
  gem 'rails_12factor', '0.0.2'
end

rails_12factor gemが追加されている点に注目してください。これは画像やスタイルシートなどの静的なアセットを提供するためにHerokuで使用されます。

また、sqlite3 gemが本番環境には含まれていない点にも注目してください。これは、今回の本番環境であるHerokuではSQLite3をサポートしていないため、明示的に本番環境からsqlite3 gemを外す必要があります (本番環境に含めてしまうと、デプロイ時にエラーが発生します)。更新したGemfileを1.14に示します。

source 'https://rubygems.org'

gem 'rails',        '4.2.2'
gem 'sass-rails',   '5.0.2'
gem 'uglifier',     '2.5.3'
gem 'coffee-rails', '4.1.0'
gem 'jquery-rails', '4.0.3'
gem 'turbolinks',   '2.3.0'
gem 'jbuilder',     '2.2.3'
gem 'sdoc',         '0.4.0', group: :doc

group :development, :test do
  gem 'sqlite3',     '1.3.9'
  gem 'byebug',      '3.4.0'
  gem 'web-console', '2.0.0.beta3'
  gem 'spring',      '1.1.3'
end

group :production do
  gem 'pg',             '0.17.1'
  gem 'rails_12factor', '0.0.2'
end

bundle installに特殊なフラグ「--without production」を追加すると、本番用のgem (この場合はpgとrails_12factor) はローカルの環境にはインストールされません。

$ bundle install --without production

リスト1.14で追加したgemは本番環境でしか使用しないので、このフラグを追加したコマンドを実行すると本番用gemはローカルに追加されません。今このコマンドを実行するのは、後の本番環境へのデプロイに備えてGemfile.lockを更新し、pg gemとrails_12factor gem、Rubyバージョンの指定をGemfile.lockに反映する必要があるためです。以下を実行して変更をコミットできます。

$ git commit -a -m "Update Gemfile.lock for Heroku"

次にHerokuのアカウントを新規作成して設定します。最初にHerokuでユーザー登録します。続いて、自分のシステムにHerokuコマンドラインクライアントがインストールされているかどうかを確認します。

$ heroku version

クラウドIDEをお使いの場合は、Herokuのバージョン番号とともにheroku CLIが利用可能であるというメッセージが表示されます。クラウドIDEを使用していない場合は、Heroku Toolbeltをインストールする必要があります¹⁸。

Herokuのコマンドラインインターフェイス (CLI) がインストールされていることが確認できたら、いよいよherokuコマンドでログインしてSSHキーを追加します。

$ heroku login
$ heroku keys:add

最後にheroku createコマンドを実行して、Herokuサーバーにサンプルアプリケーションの実行場所を作成します (リスト1.15)。

$ heroku create
Creating damp-fortress-5769... done, stack is cedar
http://damp-fortress-5769.herokuapp.com/ | git@heroku.com:damp-fortress-5769.git
Git remote heroku added

このherokuコマンドを実行すると、Railsアプリケーション専用のサブドメインが作成され、ただちにブラウザで表示可能になります。今はまだ何もありませんが、すぐにデプロイしてWebページを表示させましょう。

1.5.2 Herokuにデプロイする (1)

Railsアプリケーションを実際にHerokuにデプロイするには、まずGitを使用してHerokuにリポジトリをプッシュします。

$ git push heroku master

(警告メッセージが若干表示されることがありますが、今は無視してください。詳しくは7.5で解説します)。

1.5.3 Herokuにデプロイする (2)

失礼、その2はありません。以上でおしまいです。デプロイされたアプリケーションの表示は、heroku create (リスト1.15) を実行した際に生成されたアドレスをブラウザで開くだけです (もちろんここに表示されている著者のアドレスではなく、あなたのアドレスを使ってください)。クラウドIDEではなくローカルコンピュータで作業している場合は、heroku openコマンドでブラウザ表示することもできます。スタイル追加の結果を図1.18に示します。ページの内容は図1.12とまったく同じですが、今やそれがインターネット上の本番Webページとして堂々と公開されているのです。

図1.18: Heroku上で動いている最初のRailsチュートリアルアプリケーション。

1.5.4Herokuコマンド

Herokuのコマンドはたくさんあるので、ここでは簡単に触れる程度にとどめますが、少しだけ使ってみましょう。アプリケーションの名前を変更してみます。

$ heroku rename rails-tutorial-hello

注意: この名前は、著者のサンプルアプリケーションで既に使用していますので、「必ず他の名前を使用してください」。実際は、Herokuで生成されたデフォルトのアドレスでも十分です。本当にアプリケーションの名前を変えてみたい場合は、次のようなランダムなサブドメイン名を設定し、この章の冒頭で説明したアプリケーションのセキュリティを実装してみる方法もあります。

hwpcbmze.herokuapp.com
seyjhflo.herokuapp.com
jhyicevg.herokuapp.com

このようなでたらめのサブドメイン名なら、URLを教えない限りサイトにアクセスされる心配もありません。(ちなみに、Rubyの威力の一端をお見せするために、ランダムなサブドメイン名を生成するためのコンパクトなコードを以下に記します。

('a'..'z').to_a.shuffle[0..7].join

最高ですね。)

Herokuでは、サブドメインの他に独自ドメインも使用できます(実を言うと、このRuby on RailsチュートリアルWebサイトもHeroku上に置かれています。本チュートリアルをオンラインで読んでいるのであれば、まさにHerokuにホスティングされたWebサイトを見ているということになります)。カスタムドメインや他のHeroku関連の情報については、Herokuドキュメントを参照してください。

1.6.1 本章のまとめ

• Ruby on Railsとは、Web開発のためのフレームワークであり、Rubyプログラミング言語によって記述されている。
• 事前設定済みのクラウド環境を利用することで、Railsのインストール、アプリケーションの生成、生成されたファイルの編集を簡単に行うことができる。
• Railsにはrailsという名前のコマンドラインコマンドがあり、rails newで新しいアプリケーションを生成したり、rails serverでローカルサーバーを実行したりできる。
• コントローラのアクションを追加したり、ルートルーティングを変更したりするだけで「hello, world」アプリケーションを作成できる。
• Gitによるバージョン管理を導入し、Bitbucketの非公開リポジトリにプッシュする理由は、データの喪失を防止し、他の開発者との共同作業を行えるようにするため。
• 作成したアプリケーションをHerokuの本番環境にデプロイした。