Ruby on Rails チュートリアル
-
第7版 目次
- 第1章ゼロからデプロイまで
- 第2章Toyアプリケーション
- 第3章ほぼ静的なページの作成
- 第4章Rails風味のRuby
- 第5章レイアウトを作成する
- 第6章ユーザーのモデルを作成する
- 第7章ユーザー登録
- 第8章基本的なログイン機構
- 第9章高度なログイン機構
- 第10章ユーザーの更新・表示・削除
- 第11章アカウントの有効化
- 第12章パスワードの再設定
- 第13章ユーザーのマイクロポスト
- 第14章ユーザーをフォローする
![]() |
||
|
||
![]() |
第7版 目次
|
![]() |
購入する |
Ruby on Rails チュートリアル
プロダクト開発の0→1を学ぼう
下記フォームからメールアドレスを入力していただくと、招待リンクが記載されたメールが届きます。リンクをクリックし、アカウントを有効化した時点から『30分間』解説動画のお試し視聴ができます。
メール内のリンクから視聴を開始できます。
第7版 目次
- 第1章ゼロからデプロイまで
- 第2章Toyアプリケーション
- 第3章ほぼ静的なページの作成
- 第4章Rails風味のRuby
- 第5章レイアウトを作成する
- 第6章ユーザーのモデルを作成する
- 第7章ユーザー登録
- 第8章基本的なログイン機構
- 第9章高度なログイン機構
- 第10章ユーザーの更新・表示・削除
- 第11章アカウントの有効化
- 第12章パスワードの再設定
- 第13章ユーザーのマイクロポスト
- 第14章ユーザーをフォローする
推薦の言葉
私が前にいた会社(CD Baby)は、かなり早い段階でRuby on Railsに乗り換えたのですが、またPHPに戻ってしまいました(詳細は私の名前をGoogleで検索してみてください)。そんな私ですが、とある本を使ってもう一度試してみた結果、今度はRailsに無事乗り換えることができました。それがこの Ruby on Rails チュートリアルという本です。
私は多くのRails関連の本を参考にしてきましたが、真の決定版と呼べるものは本書をおいて他にありません。本書ではあらゆる手順が『Rails流 (the Rails Way)』で行われています。で行われています。最初のうちは慣れるまでに時間がかかりましたが、この本を終えた今、ついにこれこそが自然な方式だと感じられるまでになりました。また、本書では多くのプロが推奨するテスト駆動開発をほぼ全編に取り入れています。実例を使ってここまで分かりやすく解説された本は、本書が初めてでしょう。極めつけはGitやGitHub、本番環境へのデプロイまでも含めている点です。このような実践もチュートリアルに含まれているため、読者はまるで実際のプロジェクトの開発プロセスを体験しているような感覚が得られ、それでいてチュートリアルとして見事に一本化されています。かのような感覚が得られるはずです。
物語のような一本道の構成も素晴らしいです。私自身、演習問題もやりながら、このRailsチュートリアルを3日間かけて一気に完走しました。最初から最後まで、途中を飛ばさずにやるのが有益な読み方です。それでは、楽しんでお読みください!
Derek Sivers (sivers.org) CD Baby 創業者
(訳註: たった3分のTED動画『社会運動をどうやって起こすか』を観たことがある方もいるのではないでしょうか。その方からの推薦の言葉です。)
謝辞
Ruby on Rails チュートリアルは、私の以前の著書「RailsSpace」と、その時の共著者 Aurelius Prochazka から多くを参考にさせてもらっています。Aure には、協力と本書への支援も含め、感謝したいと思います。また、RailsSpace と Rails チュートリアルの編集を担当した Debra Williams Cauley 氏にも謝意を表したく思います。
私にインスピレーションと知識を与えてくれた Rubyist の方々にも感謝したいと思います: David Heinemeier Hansson、Yehuda Katz、Carl Lerche、Jeremy Kemper、Xavier Noria、Ryan Bates、Geoffrey Grosenbach、Peter Cooper、Matt Aimonetti、Mark Bates、Gregg Pollack、Wayne E. Seguin、Amy Hoy、Dave Chelimsky、Pat Maddox、Tom Preston-Werner、Chris Wanstrath、Chad Fowler、Josh Susser、Obie Fernandez、Ian McFarland、Steph Bristol、Pratik Naik、Sarah Mei、Sarah Allen、Wolfram Arnold、Alex Chaffee、Giles Bowkett、Evan Dorn、Long Nguyen、James Lindenbaum、Adam Wiggins、Tikhon Bernstam、Ron Evans、Wyatt Greene、Miles Forrest、Sandi Metz、Ryan Davis、Aaron Patterson、Aja Hammerly、Richard “Schneems” Schneeman、Pivotal Labs の方々、Heroku の方々、thoughtbot の方々、そして GitHub の方々、ありがとうございました。最後に、ここに書ききれないほど多くの読者からバグ報告や提案を頂きました。ご協力いただいた皆様のおかげで、本書の完成度をとことんまで高めることができました。
初期のドラフトで丁寧なレビュー、技術的なフィードバック、そして有用な提案をしてくれた Andrew Thai に感謝します。また、Learn Enough の共同創業者である Nick Merwin と Lee Donahoeによる日々のチュートリアル制作作業のサポートにも感謝いたします。
最後に、たくさんの読者の皆さん、そして、ここに挙げきれないほど多いコントリビューターのみんな、バグ報告や提案をしてくれてありがとう。彼ら/彼女らの多くの手助けに、最高の感謝を。
著者
マイケル・ハートル(Michael Hartl)は、Webサービス開発を学ぶときによく参考にされる『Ruby on Rails Tutorial』の著者であり、Learn Enoughの共同創業者でもあります。カリフォルニア工科大学(Caltech)で物理学の講師を務めた経験があり、そのときにLifetime Achievement Award for Excellence in Teachingを受賞しました。
ハーバード大学卒業後、カリフォルニア工科大学で物理学博士号を取得。シリコンバレーの有名な起業プログラム Y Combinator の卒業生でもあります。
著作権とライセンス
Ruby on Rails チュートリアル: プロダクト開発の0→1を学ぼう Copyright © 2016–2022 by Michael Hartl(最終更新日: 2022/11/09 12:39:59 PT)
Ruby on Rails チュートリアルで掲載しているすべてのソースコードは、MIT ライセンスおよびBeerware ライセンスの元で提供されています。なお、これらのライセンスはいずれか一方が有効になります。つまり、MITライセンスに基づいて使用する場合は、ビールも購入する必要はありません。
また「すべてのソースコード」とは、Railsチュートリアル内で題材としている「Sample App」などのRailsアプリケーションのソースコードを指します。「Railsチュートリアル」という教材コンテンツ自体は上記ライセンスで提供されていないのでご注意ください。法人向けには研修支援サービスや教材連携サービスを提供しているので、よければぜひ!
The MIT License
Copyright (c) 2020 Michael Hartl
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
THE BEERWARE LICENSE (Revision 42)
Michael Hartl wrote this code. As long as you retain this
notice you can do whatever you want with this stuff.
If we meet some day, and you think this stuff is worth it,
you can buy me a beer in return.
第1章ゼロからデプロイまで
Railsチュートリアルへようこそ!
本チュートリアルの目的は、皆さんにWebサービス開発で必要になる基礎知識を学んでもらうことです。本チュートリアルで学んだことは、Webサービス開発者としての仕事を探したり、フリーランスとしてのキャリアを始めたり、自分のWebサービスで起業する場面などで役立ちます。既に開発の経験があれば、より短期間でWebサービス開発の流れを掴めるでしょう。
Railsチュートリアルは、Rails以外にも幅広く通用する「汎用性の高いスキル」の習得を重視しています。今後他のプログラミング言語やフレームワークを学ぶ予定がある人にとっても、ここで学んだWebサービス開発の基本が役立つように仕上げています。
本チュートリアルでは『Ruby on Rails』を題材にしています。これはWebサービス開発の基本を学ぶ上で、これ以上ふさわしいフレームワークは無いと考えているからです。
Ruby on Rails(略称『Rails』)は、プログラミング言語『Ruby』で書かれたフリーかつオープンソースのWeb開発フレームワークです。
Railsは本格的なWebサービスを開発するツールとして急速に有名になり、GitHubやAirbnb、DisneyやHulu、SoundCloudやShopify、イギリス政府などで採用され、また日本国内でもCookpadやnote、freeeやマネーフォワード、YAMAPやCrowdWorks、ProgateやQiitaなどのサービスで採用されています。2021年にはRailsを使い続けるGitLabが上場し(時価総額: 約1.2兆円)、『Rails 募集』で検索すれば凄まじい数のページがヒットします。
Webサービス開発にはRails以外にも多くの選択肢がありますが、Railsのアプローチは豪快かつ強力で、幅広い場面で使えます。初めてWebサービスを開発する人であってもRailsの標準機能だけでWebサービスが作れるだけでなく、リリースしたWebサービスが大きく成功したときの拡張性も兼ね備えています。また、シングルページアプリケーション(SPA)やモバイルアプリと組み合わせて柔軟に開発したい場面でも、Railsは素晴らしいバックエンドを提供できます。
加えて、RailsにはPHPやNode.jsのフレームワークにも影響を与えた設計哲学があります1。現在も毎年のように新しいフレームワークが公開され、多くの開発者がさまざまな議論を交わしていますが、Railsの作者であるDHH(David Heinemeier Hansson)は設計について次のようにコメントしています。
Railsが登場した当初から現在に至るまで、さまざまな場所でフレームワークに関する議論が続いていますが、Railsが大切にしている設計哲学は今も残り続けています。すなわちプログラミングの慣習をパターン化し、不要な選択肢を外し、最適なデフォルト設定を提供することが、生産性を劇的に向上させるのです。
リリースから15年以上生き残り続けているRailsの一貫した設計哲学のおかげもあって、本チュートリアルで学べるWebサービス開発の基本は2014年の第3版からほとんど変わらずに安定し続けています。つまり皆さんが本チュートリアルで学ぶことは、今後も当分古びることなく役に立つと言えるでしょう。
そしてRailsは今も絶え間なく進化を繰り返しています。たとえばRails 6では、メールのルーティングやリッチテキスト機能に加えて、並列テストや複数データベースのサポートといった高度な機能も新たに導入されました。“scalable by default” というYouTube動画 (英語) では、当時GitHubのエンジニアだったEileen Uchitelleさんによって『アプリがどれほど大きく成長してもRailsはスケールできる』と解説されています。
さらに、画期的な進化を遂げたRails 7ではHotwireとTurboなどの新技術が統合されたことで、複雑なSPA(シングルページアプリケーション)と対照的に、快適なユーザーエクスペリエンスを提供するのに必要なほとんどの機能をRails 7でとてもシンプルに実現できるようになりました2。
これは実際にRailsで運用されているWebサービスからも明らかでしょう。共同開発プラットフォームとして絶大な人気を誇るGitHubには安心して寄りかかれる高い安定性があり、オンラインストア構築(EC)の分野で大成功を収めたShopifyは今なお成長し続けています。そしてこのようなRailsで成功を収めた大企業がコミュニティに還元し、2022年も進化し続けているという点は私たちにとっても大きなメリットです。
Railsは、2004年に1人のWebエンジニアが仕事の合間に手掛けたことから始まったとは思えない素晴らしい出来です。当時Railsを選ぶことは最先端でありリスクも伴う選択でしたが、今ではそうした苦労なしにRailsを選べます。
Railsは数々の事例で実証された生産性の高い機能を揃え、有用なコミュニティによって支えられています。Railsは、現在も本格的なWebサービス開発にふさわしい魅力的なフレームワークなのです。
まずは学習ロードマップで「全体像」を押さえよう
Railsチュートリアルでは「学習の流れ」をイラストでまとめています(図 1.1)。自分に合った学び方を見つけていきましょう。詳細は次の「前提知識」で1つずつご紹介していきます。

1.1 前提知識
Railsチュートリアルでは、題材となるSNSを作りながらプロダクト開発に関するさまざまな知識を学んでいきます。具体的には、Ruby、テスト駆動開発、コマンドラインによる実践的なプログラミング、Gitやテストを使ったコード管理、HTML、ある程度の量のCSS、JavaScript(およびHotwireとTurbo)を少々、SQLをごくわずか、セキュリティに関する設計と実装、RenderやAWSを使ったWebサービスの公開方法などが学べます。
ゼロから学べたという事例もありますが、プログラミングの学習経験があると良いです。「プログラミングが初めて」という人向けにも、初心者向けプログラミング学習サービス「Progate」と提携し、Webの基礎知識が学べるコースを用意しています。Progateは学習の難関である環境構築が不要で、ブラウザ上でコーディング体験ができるため、特にプログラミング未経験者にオススメです。このまま1章ずつを読み進めても大丈夫ですが、もし章の途中で「難しい」と感じたら下記の関連するコースまたはWeb開発コース(Ruby on Rails)で基本を押さえましょう。
- 第1章 ゼロからデプロイまで
- 第4章 Rails風味のRuby
- 第5章 レイアウトを作成する
- 第14章 ユーザーをフォローする
- Web開発の練習
上記コースを学んだ上で、それでも「難しい」と感じる方は下記の追加コンテンツや質問対応サービスもぜひご検討ください。
Railsチュートリアル実践入門シリーズ
Progateと本書の違いの1つに、「ブラウザで開発するかローカルで開発するか」があります。実践入門シリーズではこれまでブラウザで学習してきた人を対象として、ローカル環境での開発に役立つ実践的な知識を詰め込んでいます。例えばコマンドラインやテキストエディタの環境構築や、GitやGitHubに特化した解説など、ローカル環境で躓きがちな部分を重点的に補足しています。
- 開発環境の基本(詳細)
また、ローカル環境の難しさと同じことが、複雑かつ高度になっていくWeb技術にも言えます。本書ではRuby on Railsという実践的なWeb開発フレームワークを題材としていますが、JekyllやSinatraといった比較的シンプルで小さなフレームワークを間に挟むことで、段階的にWeb技術を学ぶこともできます。
- Web技術の基本(詳細)
- 『HTML編』
- 『CSS & Design編』
- 『JavaScript編』
- 『Ruby & Sinatra編』(準備中)
実践入門シリーズは今後も追加される予定です。最新情報は公式のnoteマガジンやYouTubeチャンネルからも発信していくので、ぜひチェックしてみてください。
Railsチュートリアル解説動画
『ただ学ぶのではなく早く学びたい』といった方向けに解説動画と質問対応サービスも提供しています。企業の社員研修や大学/大学院の講義などでも採用されている好評のコンテンツとなっているので、効率的に学びたいときはぜひご検討ください。
- イラスト付き解説動画 + 回答付き問題集で早く学ぶ
イラストと実演で効率的に学べる解説動画で、すばやく学習を進めたい人にオススメです。2022年から回答付き問題集「トレーニング」も同梱され、70問以上の問題を通して各章の理解度もチェックできます。「コードは動いたけど理解できたか不安」という人に特にオススメです。
- 質問対応サポート付きで学ぶ【提供: ShareWis】
現役Rubyエンジニアのサポート付きで学べる、解説動画の質問対応付きサービスです。後半の章ほど難しくなっていきますが、サポートを受けながらしっかり学ぶことができます。
- コミュニティに参加しながら学ぶ【提供: TechCommit】
コミュニティ型の学習支援サービスです。独学での学習が不安な方にオススメです。(【Railsチュートリアルコラボ】Rails学習支援追加パックでお申し込みください。)
Ruby on Railsガイド
本書で紹介する各機能を詳しく知りたいときに役立つのが、1,400ページを超えるRuby on Railsの大型リファレンス『Railsガイド』です。
Railsチュートリアル完走者が対象となっているので、本書を完走後、自分のWebサービスを開発するときや、仕事でコードを書く場面などでお使いください。全文検索やダークモードに対応したProプラン、ダウンロード可能な電子書籍版もあります。
Railsチュートリアルの構成
本チュートリアルは、実際に動くWebアプリケーションを開発しながら学ぶ構成になっています。最初は簡単なページ表示のみですが、章が進むにつれてユーザー登録やログイン機構など、少しずつに高度なWebアプリケーションになっていきます。始めは最小限のhelloアプリ(1.3、図 1.2)で各種セットアップを整え、次に少しだけ機能が増えたtoyアプリ(第2章、図 1.3)を体験してから、最後に本格的なWebアプリケーション『Sample App』(第3章〜第14章、図 1.4)の開発に取り組みます。
本チュートリアルでは、あらゆるWebサービス開発で通用する一般的なトピックを中心に学べるようになっています。例えばユーザー登録やログイン機構、メールを使ったアカウント認証やパスワード設定といったトピックなどです。実際のWebサービスのほとんどでは、これらの主要な機能が盛り込まれています。それだけでなく第14章で完成するSample Appの最終版では、初期のTwitterを連想させるような仕組みになっています。そういえば偶然にも、Twitterも最初はRailsで構築されていましたね。(当時の開発者も「初期にRubyを選んだのは間違いではなかった」と強調しています)
それではチュートリアルを始めていきましょう!



1.2 さっそく動かす
本チュートリアルの特徴の1つは、難関であるローカル環境のセットアップを後回しにしている点です。本チュートリアルはブラウザで動かせる開発環境として著名なAWS Cloud9と長年に渡ってパートナーシップを結んでいます。そのおかげで、本チュートリアルではCloud9を用いることで、ローカル環境で躓きがちなセットアップを後回しにしてプロダクト開発が学べるようになっています3。
ここは実に重要な点です。Rubyをインストールし、Railsをインストールし、必要な関連ツールを何から何までインストールするのは、ベテラン開発者にとってもしんどい作業になることがあります。また、お使いのOS(Windows・macOS・Linux)やOSのバージョン、テキストエディタやIDE(統合開発環境)の好みなどでセットアップ方法がバラつくため、検索で見つかった記事が自分にとっては逆効果になることもあります。
だからこそ、クラウド統合開発環境すなわちクラウドIDE(1.2.1)は、特に初心者にとって役立つサービスとなります。クラウドIDEはWebブラウザで簡単に動かせるので、読者のOSがそれぞれ違っていてもまったく同じに動きます。しかも作業中の状態を保持してくれるので、チュートリアルをしばらくお留守にしてから戻ってきても以前の状態からすぐに再開できます。
とはいえ、いずれはお使いのローカル環境でセットアップする必要が出てきます4。特に業務で開発する場面では、ある程度以上の熟練度(コラム 1.2)も必要になるでしょう。しかし焦ってはいけません。現在のベテラン開発者が歩んできたように、私達も少しずつ熟練に近づいていけばよいのです。
Railsチュートリアルや実践入門シリーズでは、シリーズを通じて「熟練(Techinical Sophistication)」をテーマに据えています。
技術的に困難な課題を魔法のように解決するには、やはりハードスキル(操作方法などの定型化しやすいスキル)とソフトスキル(デバッグなどの定型化しにくいスキル)の両面で熟練になる必要があるでしょう。Web開発やプログラミングは一般的に高度な技術とされていますが、技術は「知っていればよい」という類のものではありません。もちろん、メニュー項目をクリックしたら何が起きるかも分からないようでは話になりませんが、一方で、エラーメッセージを検索して調べたり、もう少しだけ頑張るべきか別の方法を探すべきかを見極める力も必要です5(図 1.5)。
言い換えると、Webアプリケーションには動的な部品がたくさんあるので、こうした両面のスキルを身に付けるにはもってこいです。しかもRailsのWebアプリケーションの場合は、適切なRuby gemの選定方法、bundle install
やbundle update
の実行方法、ローカルWebサーバーが動かなくなったときの再起動方法といった技術も身に付けることができます(今私が書き連ねた用語がさっぱり分からなくてもご安心を。本チュートリアルですべて説明いたしますので)。
本チュートリアルを進めるうちに、手順通りに動かないこともあるでしょう。ハマりやすい手順についてはできるだけ補足するようにしていますが、すべての状況をカバーすることは不可能です。そうしたトラブルはむしろ、熟練になるための修練だと捉えて課題解決に取り組んでみましょう。それでも、どうしてもうまくいかないときは...「バグではありません、仕様です!」(『コマンドライン編』より)

1.2.1 開発環境
開発環境は、1人1人すべて異なります。なぜなら開発者は慣れてくるにつれて、自分の環境をカスタマイズするものだからです。開発環境を大別すると、テキストエディタやコマンドラインを組み合わせて使う環境と、IDE(統合開発環境)の2つに分けられます。そしてRailsチュートリアルでは、環境構築の複雑さを避けるためにAWS Cloud9という素晴らしいクラウドIDEサービスを使って進めていきます。AWS Cloud9ではRubyやRubyGems、Gitなど、Ruby on Railsの開発環境の構築に必要なソフトウェアがほとんど組み込まれています。Railsなどの一部のソフトウェアはインストールされていませんが、これらはもちろん本書の中で説明してあります(1.2.2)。
クラウドIDEにはWeb開発に必要な三種の神器であるテキストエディタ、ファイルブラウザ、コマンドラインターミナル(図 1.6)もしっかり組み込まれています。また、クラウドIDEのテキストエディタでは、Ruby on Railsの大きなプロジェクトには不可欠とも言うべき横断的ファイル検索も利用できます6。たとえクラウドIDEを今後使うことがないとしても、コマンドラインターミナルやテキストエディタなどの開発ツールで一般にどんなことができるのかを知っておくには最適です(筆者としても他のエディタの使い方は知っておいた方が良いと考えています)。

クラウドIDEを利用するための手順は次のとおりです。AWSのサイトは継続的に更新されているため、詳細な手順は異なっているかもしれません。コラム 1.2の「熟練」の考え方を参考に細かな差異にも対応してみましょう。
- Cloud9は現在Amazon Web Services(AWS)に統合されたため、Cloud9を使うためにはAWSアカウントが必要になります。AWSアカウントを既にお持ちの場合は、AWSにログインしてください。AWSコンソールに行き、検索ボックスから “Cloud9” と入力すると、Cloud9の開発環境を作成するためのページ(図 1.7)7に行けます。
- Amazon Web Services(AWS)アカウントを持っていない場合は、AWS Cloud9のユーザー登録をします。悪用防止のためクレジットカード情報の入力が必須になりましたが、AWSには無料利用枠があるのでご安心ください。アカウントが有効になるまで最大で24時間かかりますが、著者の場合は約10分ほどで完了しました。
- Cloud9の管理ページ(図 1.7)を開けるようになったら、 ドロップダウンメニューから住所に近いリージョンを選択し、“Create environment” をクリックして図 1.8の画面に進みます。Detailsセクションでは「rails-tutorial」を含む名前などの情報を適宜入力し(図 1.8)8、Environment Typeでは“New EC2 instance”を選択します。次のNew EC2 instanceの設定では、PlatformのドロップダウンメニューからUbuntu Serverを選択します(図 1.9)。
図 1.7: AWS Cloud9で新しいワークスペースを作成する図 1.8: AWS Cloud9の新しいワークスペースに名前をつける図 1.9: Ubuntu Serverを選択する
- 次のNetwork settingsはAWS Systems Manager(SSM) を選択していることを確認し、VPS settingsやTags-optionalはデフォルトのまま“Create”をクリックします(図 1.10)。このとき、“root”ユーザーになっているという警告が表示されるかもしれませんが、この段階では無視して構いません(ここでの望ましい方法は割と複雑になるので、13.4.4のIAM(Identity and Access Management)の項で後述します)。
図 1.10: ネットワークの設定を確認してクラウドIDEを作成する
- 上の手順で“Create”をクリックすると管理ページに移動します。しばらくすると図 1.11のようにメッセージが表示されるので、openをクリックして作成したクラウドIDEを開きましょう(図 1.12)。
図 1.11: 作成が成功したらクラウドIDEを開く図 1.12: クラウドIDEの初期画面
Rubyの世界では、インデントに2つのスペースを使うのがほぼ常識になっているので、このエディタのインデント設定もデフォルトの4から2に変えておくことをオススメします。インデント設定を変更するには、右上の歯車アイコンをクリックして[Project Settings]を開き、[Soft Tabs]設定でマイナス記号をクリックして値を「2」にします(図 1.13)。このとき、[On Save, Strip Whitespace]設定もオンにしておくことをオススメします(不要なホワイトスペースが自動削除されるので、チーム開発で他のメンバーに迷惑をかけずに済みます)。設定の変更はその場で反映されるので、[Save]ボタンをクリックする必要はありません。

最後に、本チュートリアルはRuby 3.1.2を標準として使います。rvm
(Ruby Version Manager)を利用すれば、さまざまなバージョンのRubyを指定してインストールできます9。
$ rvm get stable
$ rvm install 3.1.2
$ rvm --default use 3.1.2
1.7でも後述するように、本チュートリアルではUnixのプロンプトとして$
記号を使いますので、上の各行冒頭にある$
記号は入力しないでください。
Rubyのインストールが完了したら、以下を実行してRubyのバージョンを確認できます(実際に表示されるバージョンはこれと異なることもあります)。
$ ruby -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]
1.2.2 Railsをインストールする
1.2.1の開発環境には必要なソフトウェアがすべて含まれていますが、Railsそのものはまだ含まれていません(これは意図したものです)。チュートリアルを期待どおりに進めるには、Railsの正確なバージョンをインストールすることが重要だからです。
まずはインストール時間を短縮するため、インストールに時間のかかるRubyドキュメントをインストールしないようにする設定を追加してみましょう(リスト 1.1)10。このコマンドは1回実行するだけでOKです(コマンドラインの慣習については 1.7で説明します)。
.gemrc
ファイルに追加するコマンド
$ echo "gem: --no-document" >> ~/.gemrc
Railsをインストールするには、RubyGemsが提供するgem
コマンドを使います。リスト 1.2のコマンドをターミナルに入力してください。クラウドIDEを使っている場合は図 1.6の右下にあるコマンドライン領域に入力してください(ローカル環境で開発している場合は通常のターミナルウィンドウに入力してください)。
$ gem install rails -v 7.0.4
-v
というオプションを使うことで、インストールされるRailsのバージョンを正確に指定できます。rails
コマンドに-v
オプション渡せばインストールされたことを確認できます。
$ rails -v
Rails 7.0.4
このコマンドで出力されるRailsのバージョン番号は、インストールされたRailsのバージョン(リスト 1.2)と正確に一致する必要があります。
経験上、リスト 1.3で示すようにbundler
gemのバージョンも揃えておくとよいことがわかっています。
$ gem install bundler -v 2.3.14
bundler
gemは重要です。詳しくは 1.3.1で学びます。
最後に、Cloud9環境でディスク容量が不足しないよう、ワークスペース環境のディスク容量を追加するコマンドも事前に実行しておくことをオススメします(リスト 1.4)。
$ source <(curl -sL https://cdn.learnenough.com/resize)
apt-get: command not found
のようなエラーメッセージが出た場合は、図 1.9でUbuntu Serverを選んでいない可能性があります。その場合は一度ワークスペースを削除し、新しいワークスペースを作成し直しましょう。ディスク容量の追加は必須というほどではないので、ワークスペースを作成し直してもうまくいかない場合は、そのままチュートリアルを続行してください。 以上でインストールは完了です!Ruby on RailsでWeb開発を行うための準備が完全に整いました。
1.3 最初のアプリケーション
コンピュータープログラミングを学ぶときの伝統に従い、最初に作るアプリケーションは「Hello World」を表示するプログラムにしましょう。具体的には、Webページに「hello, world!」という文字列を表示するだけの単純なアプリケーションを、開発環境(1.3.4)と本番環境(1.5)でそれぞれ作成します。
どんなRailsアプリケーションも、最初の作成手順は基本的に同じです。rails new
コマンドを実行して作成します。このコマンドを実行するだけで、指定のディレクトリにRailsアプリケーションのスケルトンを簡単に作成できます。1.2.1で推奨しているCloud9 IDEを利用しない場合は、Railsプロジェクトで使うためのenvironment
ディレクトリを作成しておいてください(リスト 1.5)11。
environment
ディレクトリを作る
# クラウドIDEではこの手順は不要です
$ cd # プロジェクトのホームディレクトリに移動
$ mkdir environment # environmentディレクトリを作成
$ cd environment/ # 作成したenvironmentディレクトリに移動
リスト 1.5ではUnixのcd
コマンドとmkdir
コマンドを使います。こうしたコマンドが分からない方は、コラム 1.3をご覧ください。
WindowsユーザーやmacOSユーザーの多くはコマンドラインというものに馴染みがないことでしょう。幸い、今はオススメのクラウド開発環境のおかげでUnixコマンドラインをみな同じように扱うことができ、Bashなどの標準的なシェルコマンドラインインターフェイスを実行できます12。
コマンドラインの基本的な仕組みは本当にシンプルです。ユーザーはコマンドを発行(issue)することで、実にさまざまな操作を実行できます。ディレクトリの作成ならmkdir
コマンド、ファイルの移動やリネームはmv
コマンド、ファイルのコピーならcp
コマンド、ファイルシステム内でのディレクトリの移動はcd
コマンド、という具合です。
GUI(グラフィカルユーザーインターフェイス)しか使ったことのないユーザーにとっては、コマンドラインの黒い画面は何やら恐ろしげでとっつきが悪いように見えるかもしれませんが、見た目ほど当てにならないものはありません。コマンドラインはそれ自体が強力なツールであり、エンジニアにとってなくてはならない道具箱なのです13。そうでなければ、どのエンジニアもコマンドラインを使っているはずがありません。経験豊富な開発者のデスクトップ画面を覗いてみれば、ほとんどどころか99%は、黒いターミナルウィンドウがいくつも開いていて、その中で多数のコマンドラインシェルが忙しく実行されているはずです。
コマンドラインについて詳しく説明し始めるときりがないので深入りはしませんが、本チュートリアルで必要なUnixコマンドラインのコマンドはほんのわずかしかありませんのでご安心ください(表 1.1)。Unixの基本的なコマンドラインについてもっと知りたい方は、『コマンドライン編』をぜひお読みください。
説明 | コマンド | コマンド例 |
ディレクトリ内容の表示 | ls |
$ ls -l |
ディレクトリの作成 | mkdir <ディレクトリ名> |
$ mkdir environment |
ディレクトリの移動 | cd <ディレクトリ名> |
$ cd environment/ |
上のディレクトリに移動 | $ cd .. |
|
ホームディレクトリに移動 | $ cd ~ もしくは $ cd |
|
ホームディレクトリ直下のenvironmentに移動 | $ cd ~/environment/ |
|
ファイルの移動やリネーム | mv <移動元> <移動先> |
$ mv foo bar |
mv <現在の名前> <変更後の名前> |
||
ファイルのコピー | cp <コピー元> <コピー先> |
$ cp foo bar |
ファイルの削除 | rm <ファイル名> |
$ rm foo |
空のディレクトリの削除 | rmdir <ディレクトリ名> |
$ rmdir environment/ |
中身のあるディレクトリの削除 | rm -rf <ディレクトリ名> |
$ rm -rf tmp/ |
ファイルの内容の結合と表示 | cat <ファイル名> |
$ cat ~/.ssh/id_rsa.pub |
ローカルシステムまたはクラウドIDEで行う次の手順は、リスト 1.6のコマンドを使った最初のアプリケーションの作成です。リスト 1.6のコマンドでは、Railsのバージョンを明示的に指定している点にご注目ください。このようにバージョンを指定することで、リスト 1.2と同じバージョンのRailsで、最初のアプリケーションと同じファイル構造を作成できます。リスト 1.6では、本章では扱わないActive Recordファイルの生成をスキップするためのオプション-O
を追加しています。また、デフォルトのbundle
コマンドもスキップしています。こうすることで、先ほどリスト 1.3でインストールしたバージョンのbundle
コマンドと互換性が保たれるようになります14。
rails new
を実行する(バージョン番号を指定)
$ cd ~/environment
$ rails _7.0.4_ new hello_app -O --skip-bundle
create
create README.md
create Rakefile
create .ruby-version
create config.ru
create .gitignore
create Gemfile
run git init from "."
Initialized empty Git repository in /home/ubuntu/environment/hello_app/.git/
create package.json
create app
create app/assets/config/manifest.js
create app/assets/stylesheets/application.css
create app/channels/application_cable/channel.rb
create app/channels/application_cable/connection.rb
create app/controllers/application_controller.rb
create app/helpers/application_helper.rb
.
.
.
ご覧のとおり、rails
コマンドを実行すると大量のファイルとディレクトリが作成されます。Webアプリケーションのディレクトリをどう構成するかは本来自由なのですが、RailsのようなWebフレームワークでは、ディレクトリとファイルの構造(図 1.14)はこのように標準化されています。ファイルやディレクトリの構造がすべてのRailsアプリで標準化されているおかげで、他の開発者の書いたRailsのコードが読みやすくなります。これはWebフレームワークを導入する大きなメリットです。
Railsで使われるデフォルトのファイルについては表 1.2をご覧ください。これらのファイルやディレクトリの意味や目的については本書全体に渡って説明いたします。特に5.2.1以降では、Rails 3.1から搭載されたアセットパイプラインの一部であるapp/assets
ディレクトリについて、詳しく説明します。アセットパイプラインによって、CSS(Cascading Style Sheet)や画像ファイルなどのアセット(資産)を簡単に編成することもデプロイすることもできます。

ディレクトリ | 用途 |
app/ |
モデル、ビュー、コントローラ、ヘルパーなどを含む主要なアプリケーションコード |
app/assets |
アプリケーションで使うCSS(Cascading Style Sheet)、画像などのアセット |
bin/ |
バイナリ実行可能ファイル |
config/ |
アプリケーションの設定 |
db/ |
データベース関連のファイル |
doc/ |
マニュアルなど、アプリケーションのドキュメント |
lib/ |
ライブラリやモジュール置き場 |
log/ |
アプリケーションのログファイル |
public/ |
エラーページなど、一般(Webブラウザなど)に直接公開するデータ |
bin/rails |
コード生成、コンソールの起動、ローカルのWebサーバーの立ち上げなどで使うRailsスクリプト |
test/ |
アプリケーションのテスト |
tmp/ |
一時ファイル |
README.md |
アプリケーションの簡単な説明 |
Gemfile |
このアプリケーションに必要なGemの定義ファイル |
Gemfile.lock |
アプリケーションで使われるgemのバージョンを確認するためのリスト |
config.ru |
Rackミドルウェア用の設定ファイル |
.gitignore |
Gitに取り込みたくないファイルを指定するためのパターン |
1.3.1 Bundler
Railsアプリケーションを新規作成したら、次はBundlerを実行して、アプリケーションに必要なgemをインストールします。Gemfile
は、rails
コマンド(リスト 1.6)によって自動的に作成されますが、ここではGemfile
に記載されているデフォルトのアプリケーションgemを少し変更します。
そのために、テキストエディタでGemfile
を開きます(クラウドIDEの場合は、ファイルナビゲーター画面で矢印をクリックしてサンプルアプリのディレクトリを開き、Gemfile
アイコンをダブルクリックします)。
Gemfileの内容は、だいたい図 1.15やリスト 1.7のようになります(バージョン番号など細かな点は異なる可能性があります)。Gemfileの内容はRubyのコードですが、ここでは文法を気にする必要はありません。Rubyの詳細については第4章で説明します。
ファイルやディレクトリが図 1.15のように表示されない場合、ナビゲーターの歯車アイコンをクリックして[Refresh File Tree]を選択します。
一般に、ファイルやディレクトリがうまく表示されていない場合は、このようにファイルツリーを再表示してみてください15。

hello_app
ディレクトリにあるデフォルトのGemfile
をテキストエディタで開く
hello_app
ディレクトリにあるデフォルトのGemfile
Gemfile
source "https://rubygems.org"
git_source(:github) { |repo| "https://github.com/#{repo}.git" }
ruby "3.1.2"
# Bundle edge Rails instead: gem "rails", github: "rails/rails", branch: "main"
gem "rails", "~> 7.0.4"
# The original asset pipeline for Rails
# [https://github.com/rails/sprockets-rails]
gem "sprockets-rails"
# Use the Puma web server [https://github.com/puma/puma]
gem "puma", "~> 5.0"
# Use JavaScript with ESM import maps
# [https://github.com/rails/importmap-rails]
gem "importmap-rails"
# Hotwire's SPA-like page accelerator [https://turbo.hotwired.dev]
gem "turbo-rails"
# Hotwire's modest JavaScript framework [https://stimulus.hotwired.dev]
gem "stimulus-rails"
# Build JSON APIs with ease [https://github.com/rails/jbuilder]
gem "jbuilder"
# Use Redis adapter to run Action Cable in production
# gem "redis", "~> 4.0"
# Use Kredis to get higher-level data types in Redis
# [https://github.com/rails/kredis]
# gem "kredis"
# Use Active Model has_secure_password
# [https://guides.rubyonrails.org/active_model_basics.html#securepassword]
# gem "bcrypt", "~> 3.1.7"
# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem "tzinfo-data", platforms: %i[ mingw mswin x64_mingw jruby ]
# Reduces boot times through caching; required in config/boot.rb
gem "bootsnap", require: false
# Use Sass to process CSS
# gem "sassc-rails"
# Use Active Storage variants
# [guides.rubyonrails.org/active_storage_overview.html#transforming-images]
# gem "image_processing", "~> 1.2"
group :development, :test do
# See https://guides.rubyonrails.org/
# debugging_rails_applications.html#debugging-with-the-debug-gem
gem "debug", platforms: %i[ mri mingw x64_mingw ]
end
group :development do
# Use console on exceptions pages [https://github.com/rails/web-console]
gem "web-console"
# Add speed badges [https://github.com/MiniProfiler/rack-mini-profiler]
# gem "rack-mini-profiler"
# Speed up commands on slow machines / big apps
# [https://github.com/rails/spring]
# gem "spring"
end
group :test do
# Use system testing
# [https://guides.rubyonrails.org/testing.html#system-testing]
gem "capybara"
gem "selenium-webdriver"
gem "webdrivers"
end
bundle update
を実行すれば本書と同じバージョンになります。 ほとんどの行はハッシュシンボル #
(4.2)でコメントされています。これらの行では、よく使われているgemとBundlerの文法の例をコメント形式で紹介しています。この時点では、デフォルト以外のgemをインストールする必要はありません。
gem
コマンドで特定のバージョン番号を指定しない限り、Bundlerは自動的に最新バージョンのgemを取得してインストールします。例えば、Gemfileに次のような記述があるとします。
gem "sprockets-rails"
このgemのバージョンを指定する主な方法は2通りあります。これにより、Railsで使われるgemのバージョンを「ある程度」制御できます。1番目の方法は次のとおりです。
gem "capybara", ">= 3.26"
これで最新バージョンのcapybara
gemがインストールされます(これはテストで使うgemです)。極端に言えば、バージョンが7.2
であっても、3.26
と同じかそれより上のバージョンならインストールされます 。
2番目の方法は次のとおりです。
gem "puma", "~> 5.0"
このように指定すると、バージョンが5.0
以上(つまりマイナーアップデート)のpuma
gemがインストールされますが、バージョンが6
以上(つまりメジャーアップデート)のpuma
gemはインストールされません。つまり、>=
という記法では最新のgemを探してインストールし、~> 5.0
という記法ではバージョン5.1
などの新しいマイナーバージョンがあればインストールされますが、バージョン6.0
のようなメジャーバージョンアップはインストールされません16。
gemのバージョン指定に~>
を使う主な理由は、「一般には」マイナーアップデートの方が安全度が高いからです。しかし経験上は、ちょっとしたマイナーアップデートでも問題が発生することがあります。
このため、Railsチュートリアルでは基本的に事実上すべてのgemでバージョンを「ピンポイントで」指定し、がっちり固定してあります。ベテラン開発者にはGemfile
で~>
を使って指定し、最新のgemを使って進めることをオススメしていますが、チュートリアルが思い通りに動かなくなる可能性があることはご承知おきください17。
リスト 1.7のGemfile
を、実際に使用する正確なバージョンのgemに置き換えたものをリスト 1.8に示します18。
最後に、リスト 1.8ではRubyの正確なバージョン番号を指定する行(ruby '3.1.2'
)をリスト 1.7から削除している点にもご注意ください。また、最後の行はWindows環境特有の設定なので、ネイティブのWindows環境でRailsを実行する場合は、この行のコメントアウトを解除しておきましょう19。
Gemfile
の内容を一新させ、Rubyのバージョン番号を削除する Gemfile
source "https://rubygems.org"
git_source(:github) { |repo| "https://github.com/#{repo}.git" }
gem "rails", "7.0.4"
gem "sprockets-rails", "3.4.2"
gem "importmap-rails", "1.1.0"
gem "turbo-rails", "1.1.1"
gem "stimulus-rails", "1.0.4"
gem "jbuilder", "2.11.5"
gem "puma", "5.6.4"
gem "bootsnap", "1.12.0", require: false
group :development, :test do
gem "debug", "1.5.0", platforms: %i[ mri mingw x64_mingw ]
end
group :development do
gem "web-console", "4.2.0"
end
group :test do
gem "capybara", "3.37.1"
gem "selenium-webdriver", "4.2.0"
gem "webdrivers", "5.0.0"
end
# Windows ではタイムゾーン情報用の tzinfo-data gem を含める必要があります
# gem "tzinfo-data", platforms: [:mingw, :mswin, :x64_mingw, :jruby]
前置きが長くなりましたが、いよいよBundlerを使ってhelloアプリに必要なgemsをインストールする準備が整いました。アプリケーションのGemfile
をエディタで開き、リスト 1.8の内容で置き換えて保存したら、bundle install
を実行してgemをインストールします20。
リスト 1.6のrails
コマンドのときと同様に、リスト 1.9でもバージョン番号を明示的に指定しています。これにより、正しいバージョン(つまりリスト 1.3でインストールしたバージョン)のbundler
gemを使ってbundle
コマンドが実行されるようになります。本チュートリアルでは、互換性を最大限に高めてスムーズに作業するためにこの方法を使っています。ただしこれはあくまでチュートリアル向けの方法なので、実際の業務では一般にbundle
コマンドでバージョンを指定しないことが多いでしょう(コラム 1.4)。またリスト 1.9の最後には、一部のシステムで必要となるLinuxデプロイプラットフォーム向けの行も含めてあります。
$ cd hello_app/
$ bundle _2.3.14_ install
Fetching source index for https://rubygems.org/
.
.
.
$ bundle _2.3.14_ lock --add-platform x86_64-linux
bundle install
コマンドの実行には少し時間がかかるかもしれません。完了後、アプリケーションが実行可能になります(なお、ネイティブのWindowsでRailsを実行する場合は、リスト 1.8の末尾の行のコメント解除をお忘れなく)。
リスト 1.6では、rails new
の代わりにrails _7.0.4_ new
と入力しました。リスト 1.9でも、bundle install
ではなくbundle _2.3.14_ install
と入力しました。こんなふうにコマンドでわざわざバージョンを指定する理由は何でしょうか?
種明かしすると、これは「将来の互換性を最大に保つため」です。
今後RailsやBundlerのバージョンが新しくなると、本チュートリアルに記載されている通りの手順ではうまくいかなくなる可能性がまれにあります。本チュートリアルでは、可能な限りそうしたトラブルを防ぎたいのですが、不具合の原因を事前にすべて予測するのは不可能です。技術の「熟練」(コラム 1.2)を身に付ける必要がある理由のひとつがこれです。
しかし、RailsやBundlerのバージョンを明示的に指定することで、少なくともチュートリアルを学ぶときにそうしたトラブルが起きるリスクを最小化できます。
本チュートリアルでRailsやBundlerのバージョンを指定するのは、ちょうど自転車の乗り方を練習するときに補助車輪を取り付けるようなものです。自転車に乗れるようになったら補助車輪を外すのと同じように、本チュートリアルを終えて業務で実際にコマンドを使うときは、以下のように「バージョン指定なし」のコマンドを使うことになります。
$ rails new hello_world
そして
$ bundle install
Bundlerの場合は、以下のようにinstall
を付けなくても使えます。
$ bundle
(bundle
はbundle install
の省略形であることがこれでわかります)
上述したように、コマンドにオプションを付けずに実行する「ベテラン向きの方法」では、将来互換性が失われる可能性がゼロではありません。
たとえば、リスト 1.6のコマンドにある--skip-bundle
を省略すると、bundle install
コマンドでRailsがインストールされるときに、システム上で見つかる最も直近のバージョンのBundlerが使われます。見つかったBundlerのバージョンは、リスト 1.3でインストールされたバージョンのBundlerと(偶然)同じかもしれませんが、同じでないかもしれません。
ただし、これは別に大した問題ではありません。実を言うと、以下のコマンドなどを実行すれば、少なくとも互換性の問題は解消します。それを避けるための補助車輪なのです。
$ bundle update
または
$ rm -f Gemfile.lock $ bundle
しかしRailsやRubyに慣れていないうちは、こうしたコマンドで問題を解決できることをまだ知らない可能性があるので、この問題を解決しようとして余計なフラストレーションを抱えてしまうかもしれません。それを避けるための補助車輪なのです。
では、補助車輪はいつ外してよくなるのでしょうか?
本チュートリアルを完了したら、コマンドを実行するときに、試しにバージョン指定なしで(またはリスト 1.7のように~>
でバージョンを指定して)やってみるとよいでしょう。冒険が好きな人なら、本チュートリアルの途中でやってみるのもありです。
バージョン指定なしで問題が起きなければ、もちろんOKです。 問題が起きたときは、これまで身に付けた「熟練」を駆使しましょう。それでもうまく行かないときは、また補助車輪をつけ、日を改めて挑戦してみましょう。
1.3.2 rails server
1.3のrails new
コマンドと1.3.1のbundle install
コマンドを実行したことにより、実際に動かせるアプリケーションが作成されました。さて、アプリケーションを起動するにはどうすればよいでしょうか?
ありがたいことに、Railsには開発マシンでのみブラウズできるローカルWebサーバーを起動するためのコマンドラインプログラム(スクリプト)が付属しているので、rails server
というコマンドを実行するだけでRailsアプリケーションを手軽に起動できます。
システムによっては(クラウドIDEであっても)、rails server
コマンドを実行する前にローカルWebサーバーへの接続を許可する必要が生じることがあります。これを行うには、config/environments/development.rb
ファイルをエディタで開き、リスト 1.10と図 1.16に示した2行を追加してから、ファイルを保存します。
config/environments/development.rb
Rails.application.configure do
.
.
.
# Cloud9 への接続を許可する
config.hosts.clear
end

なお、リスト 1.11に表示されているこのrails server
コマンドは、ターミナルタブをもうひとつ開いてそこで実行することをオススメします。そうすることで、最初に開いたタブで引き続きコマンドを実行できるので便利です(図 1.17と図 1.18)21。リスト 1.11で「Ctrl-C」キー22を押すことでサーバーをシャットダウンできます。
$ cd ~/environment/hello_app/
$ rails server
=> Booting Puma
=> Ctrl-C to shutdown server


(クラウドでない)OSでrails server
の結果を表示するには、ブラウザのアドレスバーにhttp://localhost:3000を貼り付けてください。クラウドIDEの場合は、Previewを開いて[Preview Running Application]をクリックする(図 1.19)ことで、実行中のアプリをブラウザのウィンドウまたはタブで表示します(図 1.20)。ブラウザの設定によってはうまく表示されない場合があります。「WEBサイトによるトラッキング」をブロックしている場合は、解除して23IDEを再読み込みすることで表示できます。いずれの場合も、図 1.21のように表示されるはずです。



rails server
を実行したときのデフォルトのRailsページ
演習
Railsチュートリアルには多くの演習問題が含まれています。チュートリアルを学びながらこれらの演習を解くことを強くオススメします。
本編と演習問題を分けて扱うため、原則として演習問題の解答はその後の本編コードリストで使わないようにしています。つまり、演習の解答を自分のコードに反映していくうちに、コードがチュートリアルから少しずつずれる可能性もあるということです。このようなずれを自力で解決することは、「熟練」にとても役立つ学びとなります(コラム 1.2)。
用意されている問題の多くはそう簡単に解けませんが、まだ最初なのでウォーミングアップとしてやさしい演習から始めることにしましょう。
- デフォルトのRailsページに表示されているRubyのバージョンを見て、今の自分のコンピュータにインストールされているRubyのバージョンがそれと同じかどうかを調べてください。コマンドラインで
ruby -v
を実行することで簡単に確認できます。 - 上と同じ要領で、Railsのバージョンも調べてみましょう。調べたバージョンはリスト 1.2でインストールしたバージョンと一致していますか?
1.3.3 Model-View-Controller(MVC)
まだ始まったばかりですが、今のうちにRailsアプリケーションの全体的な仕組みを知っておくと後々役立ちます(図 1.22)。デフォルトのRailsアプリ構造(図 1.14)を眺めてみると、app/
というディレクトリがあり、その中に「models
」「views
」「controllers
」という3つのサブディレクトリがあることに気付いた方もいると思います。ここにはRailsがMVC(model-view-controller)というアーキテクチャパターンを採用していることが暗に示されています。MVCでは、アプリケーション内のデータ(ユーザー情報など)と、データを表示するコードを分離します。アプリケーションのグラフィカルユーザーインターフェイス(GUI)は多くの場合このようにして構成されます。
ブラウザがRailsアプリと通信する際、一般的にWebサーバーにリクエスト(request)を送信し、これはリクエストを処理する役割を担っているRailsのコントローラ(controller)に渡されます。コントローラは、場合によってはすぐにビュー(view)を生成してHTMLをブラウザに送り返します。動的なサイトでは、一般にコントローラは(ユーザーなどの)サイトの要素を表しており、データベースとの通信を担当しているRubyのオブジェクトであるモデル(model) と対話します。モデルを呼び出した後、コントローラは、ビューを描画(レンダリング)し、完成したWebページをHTMLとしてブラウザに返します。

今はこの解説がまだ少し抽象的に思えるかもしれませんが、この章は後に何度も参照しますのでご安心ください。特に1.3.4では、MVCを扱うお試しアプリケーションをご覧に入れます。2.2.2では、このtoyアプリを使ってMVCの詳細を解説します。サンプルアプリケーションでは、MVCの3つの要素をすべて扱います。3.2でまずコントローラとビューを扱い、モデルについては6.1から扱い始める予定です。その後、これら3つの要素を協調動作させる方法を7.1.2で見ていきます。
1.3.4 Hello, world!
記念すべき最初のMVCフレームワークアプリケーションとして、先ほど作ったアプリにほんのちょっぴり変更を加えることにしましょう。「hello, world!」という文字列を表示するだけのコントローラのアクションを追加し、図 1.21のデフォルトRailsページを置き換えてみましょう(コントローラのアクションについては2.2.2で詳しく解説します)。
コントローラという名前から想像できるように、コントローラのアクションはコントローラ内で定義します。ここでは、Applicationという名前のコントローラの中にhello
という名前のアクションを作成することにします。実際、この時点ではコントローラはApplicationひとつしかありません。次のコマンドを実行すると、現在あるコントローラを確認できます。
$ ls app/controllers/*_controller.rb
新しいコントローラの作成は第2章で行います。リスト 1.12に、hello
を定義したところを示します。ここではrender
メソッドで「hello, world!」というテキストを表示しています。この時点ではRubyの文法については気にする必要はありません。第4章で詳しく解説します。
hello
を追加する app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
def hello
render html: "hello, world!"
end
end
表示したい文字列を返すアクションを定義したので、今度はデフォルトのページ(図 1.21)の代わりにこのアクションを使うようRailsに指示します。そのためには、Railsのルーター(router)を編集します。ルーターはコントローラとブラウザの間に配置され(図 1.22)、ブラウザからのリクエストをコントローラに振り分ける(=ルーティング)役割を果たします(図 1.22はわかりやすくするためルーターを省略していますが、2.2.2で詳しく解説します)。ここではデフォルトのページを差し替えたいので、ルートのルーティング(ルート URLにアクセスした場合のルーティング)を変更することにします。例えば http://www.example.com/ というURLの末尾は「/」になっているので、ルートURLは単に「/」(スラッシュ)と簡略表記することもあります。本チュートリアルではrouteやroutingを「ルーティング」、rootを「ルート」と表記します。
Railsのルーティングファイル(config/routes.rb
)にはRailsガイドの「ルーティング」を参照するようコメントがあり、ルートルーティングの構成方法がリンク先に示されています(リスト 1.13)。たとえば、具体的なルーティングの文法は次のような形式になります。
root "controller_name#action_name"
上のコードの場合、コントローラ名はapplication
であり、アクション名は hello
です。変更後のコードをリスト 1.14に示します。
config/routes.rb
Rails.application.routes.draw do
# Define your application routes per the DSL in
# https://guides.rubyonrails.org/routing.html
# Defines the root path route ("/")
# root "articles#index"
end
config/routes.rb
Rails.application.routes.draw do
root "application#hello"
end
リスト 1.12のコードとリスト 1.14のコードを使うと、ルートルーティングから「hello, world!」が返されるようになります(図 1.23)24。

演習
- リスト 1.12の
hello
アクションを書き換え、「hello, world!」の代わりに「hola, mundo!」と表示されるようにしてみましょう。 - Railsでは「非ASCII文字」もサポートされています。「¡Hola, mundo!」にはスペイン語特有の逆さ感嘆符「¡」が含まれています(図 1.24)25。「¡」文字をMacで入力するには、Optionキーを押しながら1キーを押します。この文字をコピーして自分のエディタに貼り付ける方が早いかもしれません。
- リスト 1.12の
hello
アクションを参考にして、2つ目のアクションgoodbye
を追加しましょう。このアクションは、「goodbye, world!」というテキストを表示します。リスト 1.14のルーティングを編集して、ルートルーティングの割り当て先をhello
アクションからgoodbye
アクションに変更します(図 1.25)。


1.4 Gitによるバージョン管理
実際に動作するRailsアプリを初めて完成させることができましたので、さっそくアプリケーションのソースコードをバージョン管理下に置いてみましょう。「バージョン管理をしないとアプリケーションが動かない」ということはありませんが、ほとんどの開発現場において必要不可欠であると考えられています。また、バージョン管理システムを導入しておけば、プロジェクトのコードの履歴を追ったり、うっかり削除してしまったファイルを復旧(ロールバック)したりという作業が行えるようになります。バージョン管理システムを熟知することは、今ではあらゆるソフトウェア開発者にとって必須のスキルであると言ってよいでしょう。
バージョン管理システムにもさまざまなものがありますが、Webアプリケーション開発ではリーナス・トーバルズがLinuxカーネルのために開発した分散バージョン管理システム「Git」が主流になっています。Gitはそれだけで大きなテーマなので、すべてを説明しようとすると1冊の本を軽く超えてしまいます。本セクションではバージョン管理システムの基本について説明していきますが、詳しく知りたい方は『Git/GitHub編』をご覧ください。
ソースコードのバージョン管理システムは「何としても」導入してください。バージョン管理はRailsのどんな場面でも必要になりますし、バージョン管理システムを応用して、自分の作成したコードを他の開発者と簡単に共有したり(1.4.3)、最初の章で作成したアプリケーションを本番サーバーへデプロイしたりすることもできる(1.5)からです。
1.4.1 Gitのセットアップ
推奨環境であるクラウドIDE(1.2.1)にはデフォルトでGitが導入されていますので、追加で導入する必要はありません。何らかの理由で導入が必要な方は『Git/GitHub編』の「Gitのインストールとセットアップ」などを参考に、Gitを導入してみてください。
クラウドIDEの場合は、以下を実行してGitのバージョンが2.28.0以上であることを確かめれば十分です。
$ git --version # 2.28.0以上であること
git version 2.17.1
上のようにGitのバージョンが2.28.0未満の場合は、Gitをアップグレードする必要があります。クラウドIDEの場合は、以下のリスト 1.15のコマンドを実行すればアップグレードできます。
$ source <(curl -sL https://cdn.learnenough.com/upgrade_git)
クラウドIDE以外の環境でGitをアップグレードする必要がある場合は、『Git/GitHub編』の第1章「Gitのインストールとセットアップ」を参照してください。
初回のシステムセットアップ
インストールしたGitを使う前に、最初に設定を行う必要があります。これは、コンピュータ1台につき1回だけ行います。
最初のステップは、自分の名前とメールアドレスを設定することです(リスト 1.16)。この手順は必須であり、省略できません。
$ git config --global user.name "自分のニックネームまたは名前など"
$ git config --global user.email your.email@example.com
ここで設定した名前やメールアドレスは、今後リポジトリ上で一般に公開されるためご注意ください。もし公開できるメールアドレスをお持ちでない場合は、第三者に悪影響を与えないことが保障されている@example.comをそのまま使うこともできます。
次の手順は、Gitのデフォルトブランチ名の設定です(リスト 1.17)。
$ git config --global init.defaultBranch main
リスト 1.17では、main
をGitのデフォルトブランチ名に設定しています。Gitのブランチについて詳しくは1.4.4で解説します。
次のエイリアス(alias)の設定は必須ではありませんが、コマンドを短く入力できるので設定しておくと便利です。リスト 1.18では例としてstatus
コマンドを設定しています。
git s
をstatusのエイリアスに設定する
$ git config --global alias.s status
これでgit s
と打つだけでgit status
を表示できるようになりました。なお、本チュートリアルでは誰が入力しても動くように省略なしで記述してあります。
最後の手順は、push
コマンドやpull
コマンドを入力するたびにパスワードを入力しなくて済むようにする設定です(1.4.4)。このオプションはシステムによって設定方法が若干異なるので、Linux環境以外をお使いの方は「Git に GitHub の認証情報をキャッシュする」をご覧ください。クラウドIDEなどのLinux環境をお使いの方は、以下のようにcache timeoutを設定するだけで完了します(リスト 1.19)。
$ git config --global credential.helper "cache --timeout=86400"
リスト 1.19を設定すると、Gitはパスワードを86,400秒(つまり1日)保持してくれます26。セキュリティに不安がある場合は、デフォルトのcache timeout設定である900秒(つまり15分)などの短い時間にしてもよいでしょう。
初回のリポジトリ・セットアップ
今度は、ソースコードの状態を保存する場所「リポジトリ」に対して必要なセットアップを進めていきます。今回の場合はhello_app
の状態を保存したいので、以下のコマンドでhello_app
のあるディレクトリ(ルートディレクトリと呼びます)に移動し、新しいリポジトリの初期化(git init
)を実行します。
$ cd ~/environment/hello_app # ディレクトリに移動済みの場合は不要
$ git init
Reinitialized existing Git repository in
/home/ubuntu/environment/hello_app/.git/
リポジトリが「再初期化された(Reinitialized)」というメッセージが表示されている点にご注目ください。つまり、これまでの操作で既に1度初期化を実行していたわけです。実は、Rails 6以降でrails new
コマンド(リスト 1.6)を実行すると、Gitリポジトリも自動的に初期化してくれます。GitがWebアプリケーション開発の業界でどれほど定着しているかがよく分かる事例ですね。このためRailsアプリケーションの開発においては、git init
を必ずしも実行する必要はないと言えます。しかしRails以外の開発でも同じとは限らないので、常にgit init
を実行する癖をつけておくのはよいことです。
次はgit add -A
を実行して、プロジェクトの全ファイルをリポジトリに追加します27。
$ git add -A
このコマンドを実行すると、Git管理下にあるすべての変更ファイルが追加されます。ただし、.gitignore
に書かれているパターンにマッチするファイルは追加されません。.gitignore
ファイルもrails new
コマンド実行時に自動生成され、Railsでよく使うパターンが追加されています。もちろん、自分でパターンを追加しても構いません28。
Gitで変更したファイルを追加するときは、最初ステージング(Staging)という一種のコミット待ち状態にします。安全のため、いきなり変更を保存(コミット)しないようになっているのです。現在のステージングの状態を知るにはgit status
コマンドを使います。
$ git status
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: .browserslistrc
new file: .gitignore
new file: .ruby-version
new file: Gemfile
new file: Gemfile.lock
.
.
.
ステージングに控えている変更をリポジトリに保存(コミット)するときは、git commit
コマンドを使います。
$ git commit -m "Initialize repository"
[main (root-commit) df0a62f] Initialize repository
.
.
.
-m
オプションを使うと、コミットの内容を説明するためのコミットメッセージをコマンドラインで直接記入できます。-m
オプションを使わない場合はデフォルトに設定されているエディタが開き、そこでコミットメッセージを入力します(本チュートリアルでは常に-m
オプションを使っていきます)。
git commit
で保存したコミットは、あくまでローカルマシン(Cloud9など)にしか保存されない点にご注意ください。ローカルマシンに保存したコミットを、GitHubに置かれているGitリポジトリに反映(プッシュ)する方法については1.4.4で解説します。
ちなみに、git log
コマンドでこれまでのコミットメッセージの履歴を確認することもできます。
$ git log
commit b981e5714e4d4a4f518aeca90270843c178b714e (HEAD -> main)
Author: Michael Hartl <michael@michaelhartl.com>
Date: Wed Mar 9 17:57:06 2022 +0000
Initialize repository
コミットログがある程度長い場合は、q
キーを押して終了します。『Git/GitHub編』でも解説していますが、git log
ではless
コマンドをインターフェイスとして使っています。なお、lessコマンドの詳細は、『コマンドライン編』の「使うならmoreよりless」で説明しています。
1.4.2 Gitのメリット
「ソースコードのバージョンを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 main
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore -- <file>..." to discard changes in working directory)
deleted: app/controllers/application_controller.rb
deleted: app/controllers/concerns/.keep
no changes added to commit (use "git add" and/or "git commit -a")
ファイルがいくつか削除されましたが、この変更はまだステージングに追加されておらず、コミットもされていません。つまり、restore
コマンド(と、対象ディレクトリまたはファイル名)を使えば、直前にコミットした状態まで簡単に戻すことができます29。
$ git restore .
$ git status
On branch main
nothing to commit, working tree clean
$ ls app/controllers/
application_controller.rb concerns/
うっかり削除してしまったディレクトリやファイルが、無事に復旧できましたね。これがGitを使うメリットの1つです。
1.4.3 GitHub
Gitを使ったソースコードのバージョン管理ができるようになったので、今度はGitHubにソースコードをアップロードしてみましょう。GitHubはGitに特化したソフトウェア開発のプラットフォームです30。
ローカルマシンにあるGitリポジトリを、わざわざGitHubにプッシュする主な理由は2つあります。1つ目は、ソースコードとそのすべての変更履歴(コミット記録)の完全なバックアップを作成するためです。2つ目は、他の開発者との共同作業をより簡単に行うためです。
GitHubを始める方法は単純明快です。GitHubアカウントをお持ちでない方はGitHubアカウントに登録(サインアップ)しましょう(図 1.26)31。
GitHubにアカウントを作るときに、2要素認証(2FA)も設定しておくことをオススメします(特に「Git に GitHub の認証情報をキャッシュする」を読んでおくとよいでしょう)。

ユーザー登録が完了したら、+記号のドロップダウンメニューをクリックして“New repository”を選択します(図 1.27)。

新しいリポジトリを作成するページが表示されたら、リポジトリ名にhello_app
を入力しましょう。Description(説明欄)の内容は空欄でも大丈夫です。そして万全の注意を払って、確実に、“Private”オプションを選択してください(図 1.28)。
Publicオプションを選択し、本チュートリアルで取り扱うRailsアプリのソースコードをうっかり公開しても原理的には安全です。とはいえ、特にGitを今回初めて使うような場合は秘密鍵のような重要なファイルをうっかりコミットしてしまう可能性もゼロではありません。ですから、何か起きる前にひとまずPrivateにしておく用心深さが大事です32。

“Create repository”ボタンをクリックすると、図 1.29のように既存のリポジトリをGitHubに追加するコマンドが表示されるはずです。ここではHTTPSオプションを選択してください。33

最後にリスト 1.20のコマンドを実行し、メッセージに従ってGitHubのユーザー名(Username)と、デフォルトブランチ名を設定します。
[website (main)]$ git remote add origin https://github.com/<ユーザー名>/hello_app.git
[website (main)]$ git branch -M main
[website (main)]$ git push -u origin main
1行目のコマンドは、GitHubに置いたGitリポジトリをプッシュ(push)先の1つとして登録するコマンドです。今回はoriginという名前で登録しています。
2行目のコマンドは、main
ブランチをデフォルトブランチ名に設定します(ここでは既にmain
になっているので何も変更されません)。
3行目のコマンドは、ローカルマシンにあるGitリポジトリを、先ほど登録したorigin(GitHub)にアップロードしています34。
今はこれらの操作について詳しく知らなくても大丈夫です。このようなコマンドはGitHubのWebページのリポジトリに表示されるものをコピペして使えば済むので、意味を理解していなくても作業できるでしょう。
リスト 1.20の<ユーザー名>
の部分は、実際のユーザー名に置き換えてください。たとえば著者のユーザー名mhartl
の場合は以下のようになります。
[website (main)]$ git remote add origin https://github.com/mhartl/hello_app.git
[website (main)]$ git branch -M main
[website (main)]$ git push -u origin main
リスト 1.20の3行目のコマンドを実行すると、ユーザー名とパスワードの入力を求められます。ユーザー名はGitHubのユーザー名をそのまま入力しますが、パスワードには次に説明する個人アクセストークンを入力します。GitHubのWebページにログインするときのパスワードではありませんのでご注意ください。

繰り返しますが、「Password:」に入力するのは個人アクセストークンでなければなりません35 。個人アクセストークンは、GitHubの「個人アクセストークンを使用する」ドキュメントの手順に沿って作成できます36。
なお、個人アクセストークンを作成するときは、「No expiration」(期限なし)を選び、トークンの適用範囲に「repo」を選んでおくことをおすすめします(図 1.31)37。こうすることで、個人アクセストークンをコマンドラインで使えるようになります。

個人アクセストークンを作成したらメモ帳アプリなどに保存しておきましょう38。コマンドラインでリスト 1.20のgit push
を実行してパスワード入力を求められたら、この個人アクセストークンをコマンドラインにコピペしてください39。
リスト 1.20の通りに最初のgit push
を実行したら、ブラウザで「Cmd-R」キーを押すか図 1.32のアイコンをクリックしてページを再読み込みしてください。これで、GitHubのhello_appリポジトリページが表示されます。このページで、リポジトリのファイルを見たりコミット履歴を参照するなど、さまざまな機能が利用できるようになります(図 1.33)。


1.4.4 ブランチ、編集、コミット、マージ
1.4.3の手順に沿って進めた場合、READMEファイルの内容がGitHubリポジトリのページに表示されることに気付いたでしょうか(図 1.34)。このREADME.md
ファイルは、リスト 1.6のコマンドを実行したときに自動生成されました。ファイル名の拡張子が「.md
」となっているファイルは、Markdownという人間にとって読みやすい記法を使って書きます40。Markdownは簡単にHTMLに変換できるため、GitHubでもMarkdownで書かれたREADME.md
ファイルをHTMLで表示してくれます。
Railsが自動生成したREADMEをそのまま使ってもよいですし、プロジェクトに合わせて内容を書き換えても構いません。とはいえ良い練習になるので、今回はREADMEを書き換えながらGitの使い方に慣れてみましょう。具体的には、Gitの基本的なコマンドであるブランチ(branch)、編集(edit)、コミット(commit)、マージ(merge)の4つを紹介します41。

Gitのブランチ(Branch)
Gitはブランチ(branch)を簡単かつ高速に作成できます。ブランチとは基本的にはコード全体のコピーで、元のコードにいつでも戻れる状態を維持しながら、新しくコードを追加したり変更したいときに便利です。通常、大元のコードがあるリポジトリはmainブランチと呼ばれ、ブランチを新たに作りたいときはswitch
と-c
オプションで作成できます42。
$ git switch -c modify-README
Switched to a new branch 'modify-README'
$ git branch
main
* modify-README
2つ目のコマンド(git branch
)は、ローカルブランチの一覧を表示します。「*
」は現在使用中のブランチを表しています。1つ目のgit switch -c modify-README
コマンドで、新しいブランチの作成と、そのブランチへの切り替えが同時に行われている点にご注目ください。modify-README
ブランチに「*
」が付いているので、現在はmodify-README
ブランチにいることが分かります。以後、このような新たに作成したブランチを本書ではトピックブランチと呼びます。
トピックブランチは他の開発者と共同作業するときにその真価を発揮しますが43、本チュートリアルのように1人で作業するときでも有用です。modify-README
ブランチで行った変更はmain
ブランチに影響しないため、たとえば試行錯誤を繰り返してコードがめちゃくちゃになってしまってもmain
ブランチに戻れればいつでも元の状態に戻せますし、もしもう一度書き直したい場合はmodify-README
ブランチごと削除することもできます(具体的な方法は本章の最後で説明します)。
ちなみに、通常このような小さな変更のためにわざわざブランチを作成する必要はありませんが、「よい習慣を身につけるのは早ければ早いほど望ましい」ので、今のうちに少しでも練習して慣れておきましょう。
2020年10月、GitHubからアナウンスがありました。それは新規作成されるリポジトリのデフォルトのブランチ名が、従来のmaster
からmain
に変更されたというものです。デフォルトブランチ名が変更された理由についてはWikipediaに譲りますが、master
もまだ広く使われているため、皆さんが今後ドキュメントや書籍などでmaster
というブランチ名を見かけることもあるかもしれません。その場合は適宜main
に読み替えて理解すると良いでしょう。詳しくはブログ記事「Default Git Branch Name with Learn Enough and the Rails Tutorial(英語)」をご参照ください。
Gitの編集(Edit)
トピックブランチを作ったら、READMEを編集(edit)してコンテンツを追加しましょう(リスト 1.21と図 1.35)。
README.md
# Ruby on Rails Tutorial
## "hello, world!"
This is the first application for the
[*Ruby on Rails Tutorial*](https://railstutorial.jp/)
by [Michael Hartl](https://www.michaelhartl.com/). Hello, world!

Gitのコミット(Commit)
変更が終わったら、git status
コマンドで現在の状態を確認してみましょう。
$ git status
On branch modify-README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore -- <file>..." to discard changes in working directory)
modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")
この時点で1.4.1.2と同じようにgit add -A
と実行することもできますが、git commit
にはすべての変更ファイル(git mv
で作成したファイルも含む)をまとめてコミットする-a
オプションもあります。このオプションを使うと、以下のようにコミットすることもできます。
$ git commit -a -m "Improve the README file"
[modify-README 34bb6a5] Improve the README file
1 file changed, 5 insertions(+), 22 deletions(-)
ただしgit commit -a
やgit add -A
では、意図していないファイルを誤ってコミットしてしまう可能性もあるため注意が必要です。不安な場合は、git add README
やgit add .
のように追加するファイル名またはディレクトリ名を指定し、git status
で対象ファイルを確認後、git commit
でコミットしましょう。
git commit
のコミットメッセージを英語で書く場合は現在形かつ命令形で書くようにしましょう44。というのも、コミットメッセージではそのコミットが「何をした」のかを書くよりも、「何をする」ためのものなのかを書く方が後から見返したときに分かりやすくなるからです。さらに、現在形かつ命令形で書いておけば、Git自身が自動的に生成するコミットメッセージ(例えば Merge pull request #123 ...
など)とも時制が一致します。詳しくは 『Git/GitHub編』の 「Gitにコミットするとは」をご覧ください。
Gitのマージ(Merge)
ファイルの変更をコミットし終えたら、mainブランチにこの変更をマージ(merge)します。
$ git switch main
Switched to branch 'main'
$ git merge modify-README
Updating b981e57..015008c
Fast-forward
README.md | 27 +++++----------------------
1 file changed, 5 insertions(+), 22 deletions(-)
上の例では015008c
と表示されていますが、これはGitが生成するランダムな文字列(ハッシュ)のため、一致しなくても大丈夫です。ハッシュの値は環境によって多少異なりますが、他の部分はほとんど同じように表示されるはずです。
変更をマージした後は、git branch -d
を実行してトピックブランチを削除しましょう。
$ git branch -d modify-README
Deleted branch modify-README (was 015008c).
なお、トピックブランチの削除は必須ではありません。実際、トピックブランチを削除せず、そのままにしておくケースもあります。トピックブランチを削除せずに残しておけば、トピックブランチとmaster
ブランチを交互に行き来して、キリの良い所で変更をマージすることもできます。
最後に、git branch
の-D
オプションを使った、マージ前のトピックブランチを破棄する方法も紹介します。
# これはあくまで例です。誤ってブランチを作ったとき以外は実行しないでください。
$ git switch -c topic-branch
$ <ココで何か変更を加えてみてください>
$ git add -A
$ git commit -a -m "Make major mistake"
$ git switch main
$ git branch -D topic-branch
-d
オプションと異なり、-D
オプションは変更をマージしていなくてもブランチを削除できます。
Push(プッシュ)
READMEファイルの更新が終わったので、プッシュ(push)コマンドでGitHubに変更をアップロードしてみましょう。既に1.4.3で一度プッシュしているため、今回はgit push origin main
を省略したgit push
でも実行できるはずです。
$ git push
無事にアップロードできたら、GitHub上にあるhello_app
のページを確認してみましょう。README.md
の部分が更新されていれば成功です(図 1.36)。

1.5 デプロイする
まだ第1章の途中ですが、1.4でバージョン管理システム(Git)の設定が完了しているため、この時点でRailsアプリのソースコードを本番環境にアップロードし、動かすことができます。本書では、この一連の作業を以後「デプロイ」と呼びます。
技術的にはこの時点でのデプロイは必須ではありませんが、継続的にデプロイすることで問題を早い段階で見つけるメリットがあります。例えば開発環境のテストを繰り返すばかりで、いつまでも本番環境にデプロイしないままだと、アプリケーションを公開するギリギリになって思わぬ事態に遭遇する可能性が高まります。
かつてはRailsアプリを本番環境にデプロイする作業は大変でしたが、ここ数年で急速に簡単になりました。国内大手のSAKURA internetではレンタルサーバーやVPSなどで簡単に借りられますし、一通りのデプロイ環境を一気通貫して提供するRenderやHerokuなども便利です。
本チュートリアルではRenderを採用しています45。Renderはソースコードのバージョン管理にGitを使っていれば、Railsアプリケーションを簡単に本番環境にデプロイできます。(まだGitの設定をしていない方は1.4を参照してください)。Renderの無料プランには、90日間(約3ヶ月間)データベースを保存できる機能もついており、本チュートリアルを進める上では十分といえます。このセクションでは、最初のRailsアプリケーションをRenderにデプロイする流れを体験してみましょう。
まずは、Renderのユーザー登録を行います。1.4.3で作成したGitHubアカウントで登録すると便利です(図 1.37)。

次に、Web Serviceを新たに作成し(図 1.38)、GitHubと連携させます(図 1.39)。


リポジトリのアクセスは「All repositories」を選択し46、1.4.3で作成したリポジトリを連携します(図 1.40)。

アプリケーション名を設定し、Build Command等の設定はデフォルトのままFreeプランを選択します。Regionについては、原則として現在あなたがいる地域から地理的に近いものを選択するのが望ましいので、たとえば日本から近い「Singapore」を選択しておくと良いでしょう。
仕上げに、プラン選択の下部にある“Advanced”設定を開き、“Add Environment Variable”から、Railsアプリケーションを本番環境で動作させるための環境変数RAILS_MASTER_KEY
を設定します(図 1.41)。keyにはRAILS_MASTER_KEY
、Valueにはconfig/master.key
ファイルの中身を設定します47。

RAILS_MASTER_KEY
を設定
これで“Create Web Service”をクリックすると、自動でデプロイが始まります。無事デプロイが完了したら、生成されたURLをクリックし(図 1.42)Webページとして確かに公開されていることを確認してみましょう(図 1.43)。


1.6 最後に
この章では開発環境のセットアップやインストール、バージョン管理、本番環境へのデプロイなど、多くの課題を乗り越えました。次の章では第1章で学んだことを基礎として、データベースも備えたtoyアプリを作りながらRailsでできることの概観を学びます。
また、各章の最後にはTwitterで進捗を投稿できるボタンがあります。ハッシュタグ『#Railsチュートリアル』を使って他の学習者と繋がることもできるので、ぜひお気軽にご活用ください。
Railsチュートリアルには公式Twitterアカウント『@RailsTutorialJP』48もあります。Railsチュートリアルの最新情報を周知したり学習者のコメントをハイライトしているので、よければこちらもフォローしてみてください。
1.6.1 本章のまとめ
- Ruby on Railsとは、Webアプリケーションを開発するためのフレームワークであり、プログラミング言語Rubyで作られている。
- クラウドIDEを利用すると、Railsのインストールやアプリケーションの生成、生成したファイルの編集などが簡単にができる。
- Railsには
rails
コマンドが用意されていて、rails new
で新しいアプリケーションを生成したり、rails server
で開発環境用のサーバーを立ち上げられる。 - コントローラのアクションを追加したり、ルーティングを変更するだけで「hello, world」を表示するアプリケーションを作成できた。
- データの喪失を防止し、他の開発者と共同作業できるようにするため、Gitによるバージョン管理を導入し、GitHubの非公開リポジトリに保存した。
- Gitを導入していたため、アプリケーションを本番環境(Render)にすぐデプロイできた。
1.7 本チュートリアルで用いている表記の慣習
本チュートリアルでWebアプリケーション開発を進めるときは、大きく分けて「コマンドを実行するとき」と「コードを変更するとき」の2つがあります。コマンドライン上でコマンドを実行して欲しいときは、以下のように先頭にドル記号($
)を付けて表記します。
$ echo "hello, world"
hello, world
たとえば本章の1.3.2では、rails server
コマンドを実行してWebサーバーを起動するときは次のように表記しました。
$ rails server
コマンドラインでは、特定のディレクトリ内にあるファイルを指定することもあります。ディレクトリはスラッシュ記号(/
)を使って表記するため、たとえばRailsアプリケーションの本番環境用設定ファイル(production.rb
)の中身をコマンドライン上で表示する場合は、以下のように表記します。
$ cat config/environments/production.rb
上の例では、Railsアプリケーションのルートディレクトリ(README.md
ファイルがあるディレクトリ)でコマンドを実行している点に注意してください。このルートディレクトリの位置はシステムによって異なります。たとえばCloud9(1.2.1)を使っている場合は、以下の場所がルートディレクトリになります。
/home/ubuntu/environment/hello_app/
つまり、上で示したproduction.rb
ファイルの場所を省略せずに表記する(絶対パスで表記する)場合は、以下のようになります。
/home/ubuntu/environment/hello_app/config/environments/production.rb
本チュートリアルでは、1つ1つのファイルを絶対パスで書くことはせず、基本的にconfig/environments/production.rb
のように省略した形で表記します。
(ここまで読んで「よく分からない!」と感じても大丈夫です。そういった方々を対象とした 『コマンドライン編』もあります。必要になったらぜひご活用ください。)
Railsチュートリアルで「コードを変更するとき」は、サンプルコードをより読みやすくするため、次の2つの工夫をしています。1つ目は、注目して欲しい行のハイライトです。
class User < ApplicationRecord
validates :name, presence: true
validates :email, presence: true
end
上のようにコード行をハイライトして、そのコードサンプルで追加された新しい行を示したり、その前のコードサンプルとの違うを示すことがあります。2つ目は、同じコードを何度も書かずに省略するために、以下のようにドット(.
)を縦に並べる表記です。
class User < ApplicationRecord
.
.
.
has_secure_password
end
この縦のドットはコードが省略されていることを表しているので、そのままコピペしないようご注意ください。
RailsチュートリアルではRailsアプリケーションをテストする方法についても解説していますので、ほんの小さな違いが原因でテストが失敗することもあれば(テストが失敗すると赤い文字で表示されます)、テストがパスすることもある(テストスイートがパスすると緑色の文字で表示されます)ことを知っておくと何かと役に立ちます。わかりやすくするため、失敗するテストには red 、パスするテストには green と書いてあります。
最後に、Railsチュートリアルでは今後さまざまなコマンドやコードを紹介し、可能な範囲でその出力結果も載せていきます。掲載されている出力結果と皆さんの出力結果が完全に一致しなくても、慌てないでください。こうした微細な違いが問題になることはほとんどありません。
一方で、上で紹介したファイルパスの読み間違えて違うファイルを修正したり、Cloud9以外の環境で開発したり、ファイル内にタイポが混入したり、コミットするのを忘れるなど、皆さんは今後さまざまな要因でエラーを目にすることになるでしょう。実際の現場の開発がそうであるように、一度もエラーを発生させずに本チュートリアルを完走することは滅多にないと思ってください。
そうしたエラーを本チュートリアルで1つ残らず網羅しようとするのは現実的ではないため、本チュートリアルを進めていてエラーが出たときは「エラーメッセージで検索する」という手法をオススメしています。これは現実のソフトウェア開発においても非常に有用な手法です(コラム 1.2)。また、本チュートリアルのヘルプページでは(網羅はしていませんが)よくあるエラーの解決手段も紹介しています。こちらも皆さんが本チュートリアルを進めていくときのご参考になれば嬉しいです。
エラーメッセージは、開発者のデバッグを助ける心強い味方です。エラーが出たときは本セクションを思い出し、ぜひ落ち着いて対応してください。より多くの方が本チュートリアルを完走できるよう願っています。
foo
という名前のメソッド定義を見つけるには、「def foo」をグローバル検索します。echo
コマンドと>>
(append)コマンドを使います。>>
は賢いので、append先にファイルが存在しない場合は新たに作ってくれます。rails _7.0.4_
のようにバージョンを指定する必要はありません。そのおかげで、リスト 1.11ではrails server
のようにコマンドだけを入力すれば済みます。Railsの他のコマンドについても同様です。git add .
やgit add ファイル名
といった対象ファイルを明示的に指定するコマンドを使います。本書では読者の躓きを減らす目的で-A
を使いますが、もしそれぞれの違いが気になったらGitの公式ドキュメントで各コマンドの違いを調べてみましょう。checkout
コマンドでも同じことができます。git push
の-u
オプションは、GitHubをupstreamリポジトリとして設定するためのものです。これによって、git pull
を実行するとupstreamリポジトリの変更内容を自動的にダウンロードできるようになります。なお本チュートリアルではgit pull
を実行することはありません。詳しくは 『Git/GitHub編』 を参照してください。git checkout -b
コマンドでも同じことができます。
Railsチュートリアルは YassLab 社によって運営されています。
コンテンツを継続的に提供するため、書籍・動画・質問対応サービスなどもご検討していただけると嬉しいです。
研修支援や教材連携にも対応しています。note マガジンや YouTube チャンネルも始めたので、よければぜひ遊びに来てください!