Ruby on Rails チュートリアル

プロダクト開発の0→1を学ぼう

第6版 目次

推薦の言葉

私が前にいた会社(CD Baby)は、かなり早い段階でRuby on Railsに乗り換えたのですが、またPHPに戻ってしまいました(詳細は私の名前をGoogleで検索してみてください)。そんな私ですが、Michael Hartl 氏の本を強く勧められたので、その本を使ってもう一度試してみた結果、今度は無事に Rails に乗り換えることができました。それがこの Ruby on Rails チュートリアルという本です。

私は多くの Rails 関連の本を参考にしてきましたが、真の決定版と呼べるものは本書をおいて他にありません。本書では、あらゆる手順が「Rails 流」で行われています。最初のうちは慣れるまでに時間がかかりましたが、この本を終えた今、ついにこれこそが自然な方式だと感じられるまでになりました。また、本書は Rails 関連の本の中で唯一、多くのプロが推奨するテスト駆動開発(TDD: Test Driven Development)を、全編を通して実践しています。実例を使ってここまで分かりやすく解説された本は、本書が初めてでしょう。極めつけは、Git や GitHub、Heroku の実例に含めている点です。このような、実際の開発現場で使わているツールもチュートリアルに含まれているため、読者は、まるで実際のプロジェクトの開発プロセスを体験しているかのような感覚が得られるはずです。それでいて、それぞれの実例が独立したセクションになっているのではなく、そのどれもがチュートリアルの内容と見事に一体化しています。

本書は、筋道だった一本道の物語のようになっています。私自身、章の終わりにある練習問題もやりながら、この Rails チュートリアルを3日間かけて一気に読破しました1。最初から最後まで、途中を飛ばさずにやるのが一番効果的で有益な読み方です。ぜひやってみてください。

それでは、楽しんでお読みください!

Derek Sivers (sivers.org) CD Baby 創業者

(訳注: たった3分のTEDの動画「社会運動をどうやって起こすか」を観たことがある方もいるのではないでしょうか。その方からの推薦の言葉です。)

謝辞

Ruby on Rails チュートリアルは、私の以前の著書「RailsSpace」と、その時の共著者 Aurelius Prochazka から多くを参考にさせてもらっています。Aure には、協力と本書への支援も含め、感謝したいと思います。また、RailsSpaceRails チュートリアルの編集を担当した 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, Steven 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, Pivotal Labs の方々、Heroku の方々、thoughtbot の方々、そして GitHub の方々、ありがとうございました。最後に、ここに書ききれないほど多くの読者からバグ報告や提案を頂きました。ご協力いただいた皆様のおかげで、本書の完成度をとことんまで高めることができました。

丁寧なレビュー、技術的なフィードバック、そして役立つ提案をしてくれた Andrew Thai に感謝します。また、Learn Enough to Be Dangerous の共同創業者である Nick Merwin と Lee Donahoe、日々のチュートリアルの制作をサポートしてくれてありがとう。

最後に、たくさんの読者の皆さん、そして、ここに挙げきれないほど多いコントリビューターのみんな、バグ報告や提案をしてくれてありがとう。彼ら/彼女らの多くの手助けに、最高の感謝を。

著者

マイケル・ハートル(Michael Hartl)Ruby on Rails Tutorial という、Web 開発を学ぶときによく参考にされる本の著者です。 また、Learn Enough to Be Dangerouslearnenough.com)教育系ウェブサイトの創業者でもあります。 以前は、(今ではすっかり古くなってしまいましたが)「RailsSpace」という本の執筆および開発に携わったり、また、 一時人気を博した Ruby on Rails ベースのSNSプラットフォーム「Insoshi」の開発にも携わっていました。 2011年には、Rails コミュニティへの高い貢献が認められて、Ruby Hero Award を受賞しました。

ハーバード大学卒業後、カリフォルニア工科大学物理学博士号を取得。シリコンバレーの有名な起業プログラム Y Combinator の卒業生でもあります。

  1. 3日間で読破できる人は例外です! 実際には数週間〜数ヶ月をかけて読むのが一般的です。 

第1章ゼロからデプロイまで

Railsチュートリアルへようこそ!

本チュートリアルの目的は、皆さんにWebサービス開発で必要になる基礎知識を学んでもらうことです。本チュートリアルで学んだことは、Webサービス開発者としての仕事を探したり、フリーランスとしてのキャリアを始めたり、自分のWebサービスで起業する場面などで役立ちます。既に開発の経験があれば、より短期間でWebサービス開発の流れを掴めるでしょう。

Railsチュートリアルでは汎用性の高いスキルの習得を優先しています。今後他のプログラミング言語やフレームワークも学ぶ予定の人にとっても、ここで学んだWebサービス開発の基本が役立つように仕上げています。

本チュートリアルでは『Ruby on Rails』を題材にしています。これはWebサービス開発の基本を学ぶ上で、これ以上ふさわしいフレームワークは無いと考えているからです。

コラム 1.1. Railsのさまざまな利点

Ruby on Rails(略称『Rails』)は、プログラミング言語『Ruby 』で書かれたフリーかつオープンソースのWeb開発フレームワークです。Railsは本格的なWebサービスを開発するツールとして急速に有名になり、GitHubAirbnbSoundCloudDisneyHuluShopifyといった世界的に有名な企業はもちろん、日本国内でも noteクックパッドProgateQiita などのサービスで採用されています。実際に『Rails 募集』で検索すると、機械学習系スタートアップも含め、凄まじい数のページがヒットします。

Webサービス開発にはRails以外にも多くの選択肢がありますが、Railsのアプローチはエレガントかつ強力で、うまく統一されています。初めてWebサービスを開発する人であってもRailsの標準機能だけでWebサービスが作れるだけでなく、リリースしたWebサービスが大きく成功したときの柔軟性も兼ね備えています。また、シングルページアプリケーション(SPA)やモバイルアプリを開発したい場面でも、Railsは素晴らしいバックエンドを提供できます。

Railsの大きなメリットの1つとして、『次々とリリースされる新ツール』問題と程よい距離を保っている点が挙げられます。特にこれからWebサービス開発を学ぶ人たちにとっては、数ヶ月かけて学んだツールが、半年もしないうちに別の新しいツールに置き換えられてしまうといった場面は重大です。Railsフレームワークの作者であるDavid Heinemeier Hanssonは次のようにコメントしたことがあります。

かつて、目移りするような複雑な技術をアレコレ売り歩いてたJ2EEというものがありましたが、当時と驚くほどよく似た不満を、昨今のJavaScript界隈で見かけます。Railsが登場した当初から現在に至るまで、さまざまな場所で(フレームワークに関する)議論が続いていますが、Railsが中核に据えている前提は今も残り続けています。(Railsの中核である)プログラミングの慣習をパターン化し、不要な選択肢を外し、本格的なWebアプリケーションを作りたい人に最適なデフォルト設定を提供することで、生産性を劇的に向上させられるのです。

このような設計哲学のおかげもあって、本チュートリアルで学べるWebの基本は、2014年の第3版からほとんど変わらず安定し続けています。つまり、本チュートリアルで皆さんが学んだことは、今後も当分古びることなく役に立つでしょう。

そしてRailsは今も絶え間なく進化を繰り返しています。たとえばRails 6.0のリリースでは、メールのルーティングリッチテキスト機能並列テスト複数データベースのサポートといった数々の新機能が導入されています。“scalable by default” という動画 (英語) では、GitHub社のエンジニアであるEileen Uchitelleさんによって『Railsアプリがどれほど大きく成長してもRailsはスケールできる』ということが実例で解説されています。

実際、共同開発プラットフォームとして絶大な人気を誇るGitHubは私達が安心して寄りかかれる安定性を維持し、Shopifyはオンラインストア構築で大成功を収めています。また、新しいバージョンのRailsがリリースされると、そのような成功した大企業によって即座にテストされています。

Railsは、2004年にフリーランスのWeb開発者が仕事の合間に手掛けたことから始まったとは思えない素晴らしい出来です。当時Railsを選ぶことは最先端でありリスクも伴う選択でしたが、今ではそうした苦労なしにRailsを選べます。

Railsは多くの事例によって実証され、生産性の高い機能を揃え、有用なコミュニティによって支えられています。Railsは、現在も本格的なWebサービス開発にふさわしい魅力的なフレームワークなのです。

1.1 前提知識

本チュートリアルは、Rubyプログラミング言語、Unixコマンドライン、HTML, CSS、若干のJavaScript、さらに若干のSQLまで含んだ総合的なチュートリアルであり、学ぶ上での前提条件は特にありませんが、少なくともHTMLの知識と何らかのプログラミング経験があると最適です。

そこでRailsチュートリアルでは、初心者向けプログラミング学習サービス「Progate」と提携し、日本語でWebの基礎知識を学べるコースも用意しました。同サービスは環境構築不要かつブラウザ上でコーディング体験ができるため、特にプログラミング未経験者にうってつけです。このまま本チュートリアルを読み進めてももちろん大丈夫ですが、もし読んでいて「難しい」と感じたら、本文中の「関連」で示されているコースで基礎知識を学んでみることをおすすめします。特にプログラミングの経験がほとんどない場合は、Railsチュートリアルを読み進める前に、Progateの「Web開発パス(Ruby on Rails)」から始めてみることをオススメしています。

本書と関連しているコースは下記の通りです。

さらに、Railsチュートリアルを完走するための手助けとして、以下のコンテンツやサービスも紹介します。学習マップ(図 1.1)を参考に、自分に合う学習方法で進めていただければ幸いです。

Railsチュートリアル前提知識シリーズ

ProgateとRailsチュートリアル間の学習の流れを滑らかにする手助けとして、Railsチュートリアル前提知識シリーズ『開発基礎編』があります。Railsチュートリアルでは簡略化して説明されているコマンドライン・テキストエディタ・Gitに特化したコンテンツとなっているので、『基礎知識の理解度をさらに深めたい』といった方にもオススメです。(Railsチュートリアルマガジンの登録をすると、今後Railsチュートリアル前提知識シリーズに新たなコースが追加された際に最新情報をメールで受け取れます。)

  1. 開発基礎編
  2. Web基礎編
    • Learn Enough HTML to Be Dangerous(準備中)
    • Learn Enough CSS & Layout to Be Dangerous(準備中)
    • Learn Enough JavaScript to Be Dangerous(準備中)
  3. Ruby Web開発入門
    • Learn Enough Ruby(準備中)

Railsチュートリアル解説動画

Railsチュートリアルの公式解説動画として『Railsチュートリアル解説動画』があります。Railsチュートリアルを素早く確実に理解したい読者や法人にオススメです。また、スクールやコミュニティで学ぶスタイルもあるので、お好みの方法で活用していただければ幸いです。

  • Railsチュートリアル解説動画: 実演付きの解説動画(計38時間)を視聴しながら学ぶことができます。分からない部分があれば、理解できるまで何度も繰り返し見ることができるので、自分のペースで効率よく学習したい方に最適です。30分間のお試し視聴プランもあるので、興味あればぜひ!(ハッシュタグ『#Railsチュートリアル解説動画』)
  • TechCommit: コミュニティ型の学習支援サービスです。(解説動画は【Railsチュートリアルコラボ】Rails学習支援追加パックでご覧いただけます。)
  • ShareWis: 現役Rubyエンジニアのサポート付きで学べる、解説動画の質問対応サービスです。Railsチュートリアルでは章を進めるにつれて徐々に難しくなっていきますが、オンラインの動画と質問を駆使しながら学ぶことができます。途中で挫折しそうになったときにオススメです。
  • RUNTEQ: Railsチュートリアル解説動画も利用できるWebエンジニア養成スクールです。企業が求める実務レベルの技術習得に注力していて、国際化対応Ajax 対応などの基礎が学べるカリキュラムや、Polymorphic の関連付けAPI との繋ぎ込みが学べるカリキュラムなども用意されています。オンライン説明会も随時実施されているので、興味あれば公式ページへ。
  • POTEPAN CAMP: Railsチュートリアル解説動画も利用できる渋谷のプログラミングスクールです。初学者向けの基礎カリキュラムが学べるオープンクラスコース(2ヶ月15万円)から、同スクール経由で転職が決まれば全額キャッシュバックに対応している選抜クラスコースまであるので、レベルに合わせてご利用いただければと思います。

Railsガイド

トピック毎に体系化された、1,600ページを超えるRailsの公式ガイドとして『Railsガイド』があります。Railsチュートリアル1周以上されている方や、オリジナルアプリの作成などで、さらに深く掘り下げた知識が欲しい方にオススメです。

6
図 1.1: Railsチュートリアルの学習マップ

本チュートリアルの教え方は、先に進むに連れて次第に高度になっていくサンプルアプリケーションをいくつも用いて、実際に動くソフトウェアを構築することが中心になります。始めは最小限のhelloアプリ( 1.3図 1.2)、次に少しだけ機能を増やしたtoyアプリ( 2章、図 1.3)を手掛けてから、 3章から14章で本格的なサンプルアプリ(図 1.4)に取り組みます。

これらのアプリにはこれといった特徴のない名前が付いていることからわかるように、(Railsに限らず)あらゆるWebアプリケーションで実際に通用する一般的な原則を中心に学べるようになっています。特に、完全なサンプルアプリケーションには、「ユーザー登録」「ログイン」「アカウント管理」といった、プロレベルのWebアプリで必要となる主要な機能がすべて盛り込まれています。 14章で作る最終版のサンプルアプリは、かのTwitterを連想させますが、それ以上のものでもあります。Twitterは(偶然にも)最初はRailsで構築されていたのです。

それではチュートリアルを始めましょう!

6
図 1.2: 最初に作るhelloアプリ
6
図 1.3: 次に作るtoyアプリ
6
図 1.4: 最後につくるサンプルアプリ

1.2 さっそく動かす

本チュートリアルの長所のひとつは、途中で詰まったりせずにテキパキと進められることです。本チュートリアルは、ブラウザで動かせる開発環境として著名なAWS Cloud9と長年に渡ってパートナーシップを結んでいます。そのおかげで、本チュートリアルではCloud9を用いることで、余分なツールを使わない完結した開発システムを利用できます。

ここは実に重要な点です。Rubyをインストールし、Railsをインストールし、必要な関連サポートソフトウェアを何から何までインストールするのは、ベテラン開発者にとってもかなりしんどい作業になることがあります。OS、ソフトウェアのバージョン、テキストエディタやIDE(統合開発環境)の好みなどで簡単に環境がばらついてしまいます。

だからこそ、クラウド統合開発環境すなわちクラウドIDE( 1.2.1)は特に初心者にとって有用なソリューションとなります。本チュートリアルで用いるクラウドIDEは普通のWebブラウザで簡単に動かすことができるので、プラットフォームが違っていてもまったく同じに動きます。しかも作業中の状態を保持してくれるので、チュートリアルをしばらくお留守にしてから戻ってきても以前の状態からすぐに再開できます。

もうひとつの可能性は、皆さんがお使いのネイティブシステム(Windows、macOS、Linux)でRailsを開発するためのセットアップを行う場合です。業務では最終的にはそうすることがもちろん望ましいのですが、相当時間がかかりますし、ある程度以上の熟練コラム 1.2)も必要になるでしょう。自分のネイティブな環境でセットアップを行う方法については、Learn Enough Dev Environmentの“Native OS setup”(英語)をご覧ください(Rails 6を動かすにはRuby 2.6以上が必要になることを特にお忘れなく!)。この方法で進めるのであれば、 1.2.2のRailsインストールと設定も完全に済ませてからにしてください。

コラム 1.2. 「熟練」になるとは

RailsチュートリアルLearn Enoughシリーズの一つであり、シリーズを通じて「熟練(Techinical Sophistication)」をテーマに据えています。技術的に困難な課題を魔法のように解決するには、やはりハードスキル(操作方法などの定型化しやすいスキル)とソフトスキル(デバッグなどの定型化しにくいスキル)の両面における熟練が必要でしょう。Web開発やプログラミングは一般的に高度な技術とされていますが、技術は知っていればよいというものではありません。もちろん、メニュー項目をクリックしたら何が起きるかも分からないようでは話になりませんが、一方で、エラーメッセージを検索して調べたり、もう少しだけ頑張るべきか諦めて再起動すべきかを見極める力も必要です1図 1.5)。

Webアプリケーションには動的な部品がたくさんあるので、こうした両面のスキルを身に付けるにはもってこいです。しかもRailsのWebアプリケーションの場合は、適切なRuby gemの選定方法、bundle installbundle updateの実行方法、ローカルWebサーバーが動かなくなったときの再起動方法といった技術も身に付けることができます(今私が書き連ねた用語がさっぱり分からなくてもご安心を。本チュートリアルですべて説明いたしますので)。

本チュートリアルを進めていれば、どうやっても手順通りに動かないことがあるでしょう。ハマりやすい手順についてはできるだけ情報を補うようにしていますが、すべての状況をカバーすることは不可能です。そうしたトラブルはむしろ、熟練になるための修練だと捉えて課題解決に取り組んでみましょう。それでも、どうしてもうまくいかないときは...「バグではありません、仕様です!」(開発基礎編 コマンドラインより)

6
図 1.5: 「サポート担当者のためのチートシート」(漫画: xkcdより)

1.2.1 開発環境

開発環境は、Railsプログラマ一人ひとりすべて異なります。開発者は慣れてくるに従い、自分の環境を徹底的にカスタマイズするものだからです。開発環境を大別すると、テキストエディタやコマンドラインを使う環境と、IDE(統合開発環境)の2つに分けられます。そしてRailsチュートリアルでは、環境構築の複雑さを避けるためにAWS Cloud9という素晴らしいクラウドIDEサービスを使って進めていきます。AWS Cloud9ではRubyやRubyGems、Gitなど、Ruby on Railsの開発環境の構築に必要なソフトウェアがほとんど組み込まれています。RailsやHerokuなどの一部のソフトウェアはインストールされていませんが、これらはもちろん本書の中で説明してあります(1.2.2)。

クラウドIDEにはWeb開発に必要な三種の神器であるテキストエディタ、ファイルブラウザ、コマンドラインターミナル(図 1.6)もしっかり組み込まれています。また、クラウドIDEのテキストエディタでは、Ruby on Railsの大きなプロジェクトには不可欠とも言うべき横断的ファイル検索も利用できます2。たとえクラウドIDEを今後使うことがないとしても、コマンドラインターミナルやテキストエディタなどの開発ツールで一般にどんなことができるのかを知っておくには最適です(筆者としても他のエディタの使い方は知っておいた方が良いと考えています)。

6
図 1.6: クラウドIDEの外観

クラウドIDEを利用するための手順は次のとおりです。3

解説動画「第1章 前編: 15. AWS Cloud9 のセットアップ」から詳しく解説
  1. Cloud9は現在Amazon Web Services(AWS)に統合されたため、Cloud9を使うためにはAWSアカウントが必要になります。AWSアカウントを既にお持ちの場合は、AWSにログインしてください4AWSコンソールに行き、検索ボックスから “Cloud9” と入力すると、Cloud9の開発環境を作成するためのページに行けます。
  2. Amazon Web Services(AWS)アカウントを持っていない場合は、AWS Cloud9のユーザー登録をします5。悪用防止のためクレジットカード情報の入力が必須になりましたが、Railsチュートリアルのワークスペースは1年間無料なのでご安心ください。アカウントが有効になるまで最大で24時間かかりますが、著者の場合は約10分ほどで完了しました。
  3. Cloud9の管理ページ(図 1.7)に無事たどり着いたら “Create environment” をクリックし、図 1.8のような画面になるまで進めてください。「rails-tutorial」を含む名前などの情報を適宜入力して(図1.86次のページに進みます。ここでは(Amazon LinuxではなくUbuntu Serverを選択してから“Next step”をクリックします(図 1.9)。

    確認ボタンを数回クリックしてデフォルトの設定を受け付けると、AWSがIDEのプロビジョニングを開始します(図 1.11)。このとき、“root”ユーザーになっているという警告が表示されるかもしれませんが、この段階では無視して構いません(ここでの望ましい方法は割と複雑になるので、13.4.4のIAM(Identity and Access Management)の項で後述します)。

6
図 1.7: AWS Cloud9で新しいワークスペースを作成する
6
図 1.8: AWS Cloud9の新しいワークスペースに名前をつける
6
図 1.9: Ubuntu Serverを選択する
6
図 1.10: IDEをプロビジョニングする直前の手順
6
図 1.11: クラウドIDEの初期画面

Rubyの世界では、インデントに2つのスペースを使うのがほぼ常識になっているので、このエディタのインデント設定もデフォルトの4から2に変えておくことをオススメします。インデント設定を変更するには、[Soft Tabs]設定を開いて右上のマイナス記号を値が「2」になるまでクリックします(1.12)。設定の変更はその場で反映されるので、[Save]ボタンをクリックする必要はありません。

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

なお、クラウドIDEを使っている場合はGitHubとHerokuコマンドをセットアップする必要があります。細かな手順は 1.4.31.5.1のインストール手順で説明します。

また、今すぐ設定する必要はありませんが、クラウドIDE上でテスト環境をセットアップする際の応用的な設定は3.6で解説しています。詳細は3.6.2まで進んだときに学びましょう。

1.2.2 Railsをインストールする

解説動画「第1章 前編: 18. Rails を動かしてみよう」から詳しく解説

1.2.1の開発環境には必要なソフトウェアがすべて含まれていますが、Railsそのものは含まれていません。これは意図したものです。チュートリアルを期待どおりに進めるには、Railsの正確なバージョンをインストールすることが重要だからです。

最初に、Rubyドキュメントのインストールで無駄な時間を使わないよう、コマンドに設定を少々追加してみましょう(リスト 1.17 これはシステムで1回だけ設定しておけばOKです(コマンドラインなどの慣習について詳しくは 1.7をご覧ください)。

リスト 1.1: Rubyドキュメントをインストールしないよう.gemrcファイルを設定する
$ echo "gem: --no-document" >> ~/.gemrc

Railsをインストールするには、RubyGemsが提供するgemコマンドを使います。これは、リスト 1.2でコマンドラインターミナルに入力するコマンドに関連します(クラウドでないローカルシステムで開発する場合は、通常のターミナルウィンドウに入力してください)(クラウドIDEを使う場合は、図 1.6に表示されているコマンドライン領域に入力してください)。

リスト 1.2: バージョンを指定してRailsをインストールする
$ gem install rails -v 6.0.3

-vというオプションを使うことで、インストールされるRailsのバージョンを正確に指定できます。railsコマンドに-vオプションを使うとインストールされたことを確認できます。

$ rails -v
Rails 6.0.3

このコマンドで出力されるバージョン番号は、インストールされたバージョン(リスト 1.2)と正確に一致する必要があります。

もうひとつインストールするものがあります。JavaScriptソフトウェアの依存関係を管理するYarnというプログラムです。ネイティブOS上で開発する場合は、自分のプラットフォームに合ったYarnインストール手順(英語)に従ってください。クラウドIDEで開発する場合は、このコマンドを実行するだけで必要なコマンドがLearn EnoughのCDNからダウンロードされて実行されます。

$ source <(curl -sL https://cdn.learnenough.com/yarn_install)

なお、以下のような警告メッセージがときどき表示されることがあると思います。

========================================
  Your Yarn packages are out of date!
  Please run `yarn install --check-files` to update.
========================================

そんなときは、メッセージの指示に従ってyarnコマンドを実行すればOKです。

$ yarn install --check-files

以上でインストールはおしまいです!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.3)。8

リスト 1.3: Railsプロジェクト用のenvironmentディレクトリを作る
# クラウドIDEではこの手順は不要です
$ cd                    # プロジェクトのホームディレクトリに移動
$ mkdir environment     # environmentディレクトリを作成
$ cd environment/       # 作成したenvironmentディレクトリに移動

リスト 1.3ではUnixのcdコマンドとmkdirコマンドを使います。こうしたコマンドが分からない方は、コラム 1.3をご覧ください。

コラム 1.3. 急いで学びたい人のためのUnixコマンドライン講座

WindowsユーザーやmacOSユーザーの多くはコマンドラインというものに馴染みがないことでしょう(macOSユーザーの方がほんのわずかコマンドラインを知っている人は多いかもしれませんが)。幸い、今はオススメのクラウド開発環境のおかげでUnixコマンドラインをみな同じように扱うことができ、Bashなどの標準的なシェルコマンドラインインターフェイスを実行できます9

コマンドラインの基本的な仕組みは本当にシンプルです。ユーザーはコマンドを発行(issue)することで、実にさまざまな操作を実行できます。ディレクトリの作成ならmkdirコマンド、ファイルの移動やリネームはmvコマンド、ファイルのコピーならcpコマンド、ファイルシステム内でのディレクトリの移動はcdコマンド、という具合です。GUI(グラフィカルユーザーインターフェイス)しか使ったことのないユーザーからすると、コマンドラインの黒い画面は何やら恐ろしげでとっつきが悪いように見えるかもしれませんが、見た目ほど当てにならないものはありません。コマンドラインはそれ自体が強力なツールであり、エンジニアにとってなくてはならない道具箱なのです10。そうでなければ、どうしてエンジニアが揃いも揃ってコマンドラインを使うでしょうか。経験豊富な開発者のデスクトップ画面を覗きこめば、十中八九どころか99%は、黒いターミナルウィンドウがいくつも開き、そこで多数のコマンドラインシェルが忙しく実行されているはずです。

コマンドラインについて話しだすときりがないので深入りはしませんが、本チュートリアルで必要なUnixコマンドラインのコマンドはほんのわずかしかありませんのでご安心ください(表 1.1)。Unixの基本的なコマンドラインについてもっと知りたい方は、Learn Enoughのチュートリアルや開発基礎編 コマンドラインをぜひお読みください。

説明 コマンド コマンド例
ディレクトリ内容の表示 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
表 1.1: 主要なUnixコマンド

ローカルシステムまたはクラウドIDEで行う次の手順は、リスト 1.4のコマンドを使った最初のアプリケーションの作成です。リスト 1.4のコマンドでは、Railsのバージョンを明示的に指定している点にご注目ください。このようにバージョンを指定することで、リスト 1.2と同じバージョンのRailsで、最初のアプリケーションと同じファイル構造を作成することができます。

リスト 1.4: rails newを実行する(バージョン番号を指定)
$ cd ~/environment
$ rails _6.0.3_ new hello_app
      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.13)はこのように標準化されています。ファイル/ディレクトリ構造がすべてのRailsアプリで標準化されているおかげで、他の開発者の書いたRailsのコードが読みやすくなります。これはWebフレームワークを導入する大きなメリットです。

Railsで使われるデフォルトのファイルについては表 1.2をご覧ください。これらのファイルやディレクトリの意味や目的については本書全体に渡って説明いたします。特に5.2.1以降では、Rails 3.1から搭載されたアセットパイプラインの一部であるapp/assetsディレクトリについて、詳しく説明します。アセットパイプラインによって、CSS(Cascading Style Sheet)や画像ファイルなどのアセット(資産)を簡単に編成することもデプロイすることもできます。

6
図 1.13: 新規作成されたRailsアプリケーションのディレクトリ構造
ディレクトリ 用途
app/ モデル、ビュー、コントローラ、ヘルパーなどを含む主要なアプリケーションコード
app/assets アプリケーションで使うCSS(Cascading Style Sheet)、JavaScriptファイル、画像などのアセット
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.2: デフォルトのRailsディレクトリ構成の概要

1.3.1 Bundler

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

一般に、ファイルやディレクトリがうまく表示されていない場合はこのようにファイルツリーを再表示してみてください11

6
図 1.14: テキストエディタでデフォルトのGemfileを開く
リスト 1.5: hello_appディレクトリにあるデフォルトのGemfile Gemfile
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

ruby '2.6.3'

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '~> 6.0.3'
# Use sqlite3 as the database for Active Record
gem 'sqlite3', '~> 1.4'
# Use Puma as the app server
gem 'puma', '~> 3.11'
# Use SCSS for stylesheets
gem 'sass-rails', '~> 5'
# Transpile app-like JavaScript. Read more: https://github.com/rails/webpacker
gem 'webpacker', '~> 4.0'
# Turbolinks makes navigating your web application faster.
# Read more: https://github.com/turbolinks/turbolinks
gem 'turbolinks', '~> 5'
# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder
gem 'jbuilder', '~> 2.7'
# Use Redis adapter to run Action Cable in production
# gem 'redis', '~> 4.0'
# Use Active Model has_secure_password
# gem 'bcrypt', '~> 3.1.7'

# Use Active Storage variant
# gem 'image_processing', '~> 1.2'

# Reduces boot times through caching; required in config/boot.rb
gem 'bootsnap', '>= 1.4.2', require: false

group :development, :test do
  # Call 'byebug' anywhere in the code to stop execution and get a
  # debugger console
  gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]
end

group :development do
  # Access an interactive console on exception pages or by calling 'console'
  # anywhere in the code.
  gem 'web-console', '>= 3.3.0'
  gem 'listen', '>= 3.0.5', '< 3.2'
  # Spring speeds up development by keeping your application running in the
  # background. Read more: https://github.com/rails/spring
  gem 'spring'
  gem 'spring-watcher-listen', '~> 2.0.0'
end

group :test do
  # Adds support for Capybara system testing and selenium driver
  gem 'capybara', '>= 2.15'
  gem 'selenium-webdriver'
  # Easy installation and use of web drivers to run system tests with browsers
  gem 'webdrivers'
end

# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]

(訳注: Railsは常に進化し続けるため、ここでGemfileの内容が違っていたりRailsのバージョンが6.0.0となっていなくても大丈夫です。後述するGemfileでバージョンを明示的に固定するので、その変更を加えた後でbundle updateを実行すれば本書と同じバージョンになります。)

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

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

gem 'sqlite3'

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

gem 'capybara', '>= 2.15'

最新バージョンのcapybara gemがインストールされます(これはテストで使うgemです)。極端に言えば、バージョンが7.2であっても、2.15と同じかそれより上のバージョンならインストールされます 。

2番目の方法は次のとおりです。

gem 'rails', '~> 6.0.3'

このように指定すると、rails gemのバージョンが6.0.3と同じかそれより上であり、かつ6.1より小さい場合にインストールされます。つまり、以下のコードを実行すると、>=という記法では常に最新のgemがインストールされ、~> 6.0.3という記法ではマイナーバージョンの部分に相当するアップデート済みのgemをインストールします(例: 6.0.4はインストールされますが、6.1.0はインストールされません)12

残念ながら、経験上ちょっとしたマイナーアップグレードですら問題を引き起こすことがあります。このため、Railsチュートリアルでは基本的に事実上すべてのgemでバージョンを「ピンポイントで」指定し、がっちり固定してあります。ベテラン開発者にはGemfile~>を使って指定し、最新のgemを使って進めることをおすすめしていますが、チュートリアルが思い通りに動かなくなる可能性があることはご承知おきください。

リスト 1.5Gemfileを、実際に使用する正確なバージョンのgemに置き換えたものをリスト 1.6に示します13

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

最後に、Rubyの正確なバージョン番号を指定する行をリスト 1.5から削除しています。この行はミッションクリティカルなアプリケーションでは削除しないことをおすすめしますが、本チュートリアルではこの行を残すとエラー発生の可能性が高まったり無駄に複雑になったりする可能性があります(この行を削除したことでアプリケーションがエラーになるなら、速やかに元に戻してください)。

重要: 本書のGemfileで固定した各gemのバージョンは公式リポジトリと一致している必要があります。現在の章に合わせてご参照ください。(オンラインで読んでいる場合は問題ないはずですが、電子書籍などで読んでいる場合はご注意ください。)

リスト 1.6: GemfileでRuby gemごとにバージョンを明示的に指定する Gemfile
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

gem 'rails',      '6.0.3'
gem 'puma',       '4.3.6'
gem 'sass-rails', '5.1.0'
gem 'webpacker',  '4.0.7'
gem 'turbolinks', '5.2.0'
gem 'jbuilder',   '2.9.1'
gem 'bootsnap',   '1.4.5', require: false

group :development, :test do
  gem 'sqlite3', '1.4.1'
  gem 'byebug',  '11.0.1', platforms: [:mri, :mingw, :x64_mingw]
end

group :development do
  gem 'web-console',           '4.0.1'
  gem 'listen',                '3.1.5'
  gem 'spring',                '2.1.0'
  gem 'spring-watcher-listen', '2.0.1'
end

group :test do
  gem 'capybara',           '3.28.0'
  gem 'selenium-webdriver', '3.142.4'
  gem 'webdrivers',         '4.1.2'
end

# Windows ではタイムゾーン情報用の tzinfo-data gem を含める必要があります
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]

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

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

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

ちなみに、bundle installを実行すると「まずbundle updateを実行してください」というようなメッセージが表示される場合があります。その場合は、メッセージのとおりにbundle updateをまず実行しましょう(マニュアルどおりに行かない場合に慌てず落ち着いて対応することもスキルの1つです。こうしたエラーメッセージにはその場で問題を解決する方法が含まれているものなので、よく読んでおきましょう)。

1.3.2 rails server

1.3rails newコマンドと1.3.1,のbundle installコマンドを実行したことにより、実際に動かすことのできるアプリケーションが作成されました。ありがたいことに、Railsには開発マシンでのみブラウズできるローカルWebサーバーを起動するためのコマンドラインプログラム(スクリプト)が付属しているので、rails serverというコマンドを実行するだけでRailsアプリケーションを簡単に起動することができます。

解説動画「第1章 前編: 21. rails server を立ち上げる」で詳しく解説

システムによっては(クラウドIDEであっても)、rails serverコマンドを実行する前にローカルWebサーバーへの接続を許可する必要が生じることがあります。これを行うには、config/environments/development.rbファイルを開いてリスト 1.7図 1.15に示した2行を追加します。

リスト 1.7: ローカルWebサーバーへの接続を許可する config/environments/development.rb
Rails.application.configure do
  .
  .
  .
  # Cloud9 への接続を許可する
  config.hosts.clear
end
6
図 1.15: Cloud9でのRailsサーバーへの接続を許可する

なお、リスト 1.8に表示されているこのrails serverコマンドは、ターミナルタブをもうひとつ開いてそこで実行することをおすすめします。そうすることで、最初のタブで引き続きコマンドを実行できるので便利です(図 1.16図 1.17)。リスト 1.8で「Ctrl-C」キー15を押すことでサーバーをシャットダウンできます。

リスト 1.8: Railsサーバーを実行する
$ cd ~/environment/hello_app/
$ rails server
=> Booting Puma
=> Ctrl-C to shutdown server
6
図 1.16: 新しくターミナルを開く
6
図 1.17: Railsサーバーを別のタブで実行する

(クラウドでない)ネイティブOSでrails serverの結果を表示するには、ブラウザのアドレスバーにhttp://localhost:3000を貼り付けてください。クラウドIDEの場合は、Previewを開いて[Preview Running Application]をクリックして(図 1.18)ブラウザのウィンドウかタブで表示します(図 1.19)。いずれの場合も、図 1.20のように表示されるはずです。

6
図 1.18: クラウドワークスペース上で実行するローカルサーバーを共有する
6
図 1.19: 実行中のアプリをブラウザウィンドウやタブで開く
6
図 1.20: rails serverを実行したときのデフォルトのRailsページ

演習

Railsチュートリアルには多くの演習問題が含まれています。チュートリアルを学びながらこれらの演習を解くことを強くおすすめします。

演習と本文を分けて扱うため、演習の後にあるコードリストをこっそり見ても一般には参考になりません(演習の解答をその後で使うことがまれにあるかもしれませんが、その場合は明示的に本文で解答を示しています)。つまり、演習の解答を自分のコードに反映していくうちに、コードがチュートリアルから少しずつずれる可能性もあるということです。このようなずれを自力で解決することは、「熟練」にとても役立つ学びとなります(コラム 1.2)。

用意されている問題の多くはそう簡単に解けませんが、まだ最初なのでウォーミングアップとしてやさしい演習から始めることにしましょう。

  1. デフォルトのRailsページに表示されているものと比べて、今の自分のコンピュータにあるRubyのバージョンはいくつになっていますか? コマンドラインでruby -vを実行することで簡単に確認できます。
  2. 同様にして、Railsのバージョンも調べてみましょう。調べたバージョンはリスト 1.2でインストールしたバージョンと一致しているでしょうか?

1.3.3 Model-View-Controller(MVC)

まだ始まったばかりですが、今のうちにRailsアプリケーションの全体的な仕組みを知っておくことは後々役立ちます(図 1.21)。デフォルトのRailsアプリ構造(図  1.13)を眺めてみると、app/というディレクトリがあり、その中に「models」「views」「controllers」という3つのサブディレクトリがあることに気付いた方もいると思います。ここにはRailsがMVC(model-view-controller)というアーキテクチャパターンを採用していることが暗に示されています。MVCでは、アプリケーション内のデータ(ユーザー情報など)と、データを表示するコードを分離します。アプリケーションのグラフィカルユーザーインターフェイス(GUI)は多くの場合このようにして構成されます。

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

6
図 1.21: 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!」という文字列を表示するだけのコントローラのアクションを追加し、図 1.20のデフォルトRailsページを置き換えてみましょう(コントローラのアクションについては2.2.2で詳しく解説します)。

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

$ ls app/controllers/*_controller.rb

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

リスト 1.9: Applicationコントローラにhelloを追加する app/controllers/application_controller.rb
class ApplicationController < ActionController::Base

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

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

Railsのルーティングファイル(config/routes.rb)にはRailsガイドの「ルーティング」を参照するようコメントがあり、ルートルーティングの構成方法がリンク先に示されています(リスト 1.10)。具体的なルーティングの文法は、次のような形式になります。

root 'controller_name#action_name'

上のコードの場合、コントローラ名はapplicationであり、アクション名は helloです。変更後のコードをリスト 1.11に示します。

リスト 1.10: デフォルトのルーティングファイル(見栄えのためフォーマットを若干修正) config/routes.rb
Rails.application.routes.draw do
  # For details on the DSL available within this file,
  # see https://guides.rubyonrails.org/routing.html
end
リスト 1.11: ルートルーティングを設定する config/routes.rb
Rails.application.routes.draw do
  root 'application#hello'
end

リスト 1.9のコードとリスト 1.11のコードを使うと、ルートルーティングから「hello, world!」が返されるようになります(図 1.2216

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

演習

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

1.4 Gitによるバージョン管理

実際に動作するRailsアプリを初めて完成させることができましたので、さっそくアプリケーションのソースコードをバージョン管理下に置いてみましょう。これを行わないとアプリケーションが動かないということではありませんが、ほとんどのRails開発者はバージョン管理を開発現場において必要不可欠なものであると考えています。また、バージョン管理システムを導入しておけば、プロジェクトのコードの履歴を追ったり、うっかり削除してしまったファイルを復旧(ロールバック)したりという作業が行えるようになります。バージョン管理システムを熟知することは、今ではあらゆるソフトウェア開発者にとって必須のスキルであると言ってよいでしょう。

バージョン管理システムにもさまざまなものがありますが、Rails開発者コミュニティではLinus TorvaldsがLinuxカーネルのために開発した分散バージョン管理システムであるGitが主流になっています。Git はそれだけで大きなテーマなので、すべてを説明しようとすると軽く一冊の本を超えてしまいます。バージョン管理システムの基本について詳しくは開発基礎編 Gitをご覧ください18

ソースコードのバージョン管理は「何としても」導入してください。バージョン管理はRailsのどんな場面でも必要になりますし、バージョン管理システムを応用して、自分の作成したコードを他の開発者と簡単に共有したり(1.4.3)、最初の章で作成したアプリケーションを本番サーバーへデプロイしたりすることもできる(1.5)からです。

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

推奨環境であるクラウドIDE(1.2.1)にはデフォルトでGitが導入されていますので、追加で導入する必要はありません。何らかの理由で導入が必要な方は開発基礎編 Git「Gitのインストールとセットアップ」などを参考に、Gitを導入してみてください。

解説動画「第1章 後編: 6. Git によるバージョン管理」から詳しく解説

初回のシステムセットアップ

インストールしたGitを使う前に、最初に1回だけ若干の設定を行う必要があります。これはsystemセットアップと呼ばれ、コンピュータ1台につき1回だけ行います。

最初かつ必須の手順は、自分の名前とメールアドレスを設定することです(リスト 1.12)。

リスト 1.12: 名前とメールをGitに設定する
$ git config --global user.name "自分の名前"
$ git config --global user.email your.email@example.com

Gitに設定する名前やメールアドレスは、今後リポジトリ上で一般に公開されますのでご注意ください。

クラウドIDEを使う場合は、次にGitで使うデフォルトのエディタを設定します(編集や、“amend”でプロジェクトを変更するのに使われます)。ここでは、比較的使いやすくクラウドIDEのデフォルトエディタでもあるnanoエディタを使うことにしましょう。この設定を書き込んでもログアウト時にデフォルトエディタはログアウトしてしまいますし、パスも正しくないので、リスト 1.13を実行してシンボリックリンク(symlinkとも呼ばれます)を作成してnanoの実行ファイルを正しく指すようにしましょう19リスト 1.13のコマンドは初心者には少々難しいので、今読んで理解できなくても心配は不要です)。

リスト 1.13: クラウドIDEでデフォルトのエディタを設定する
$ sudo ln -sf `which nano` /usr/bin

次のエイリアス設定は必須ではありませんが、checkoutコマンドを短く入力できるので、設定しておくと便利です(リスト 1.14)。

リスト 1.14: git coをcheckoutのエイリアスに設定する
$ git config --global alias.co checkout

本チュートリアルでは、誰が入力しても動くように、省略なしのgit checkoutで記述してありますが、実際の筆者はほぼ毎回git coと入力しています。

最後の手順は、pushコマンドやpullコマンドを入力するたびにパスワードを入力しなくてよいようにする設定です( 1.4.4)。このオプションはシステムによって設定方法が若干異なりますので、Linux環境以外をお使いの方は“Caching your GitHub password in Git”をご覧ください。Linux環境(もちろんクラウドIDEも!)をお使いの方は、cache timeoutを設定するだけで完了します(リスト 1.15)。

リスト 1.15: Gitでパスワードを一定時間保持するように設定する
$ git config --global credential.helper "cache --timeout=86400"

リスト 1.15を設定すると、Gitはパスワードを86,400秒(つまり1日)の間保持してくれます20。セキュリティ意識の高い方は、デフォルトの900秒(つまり15分)のようにもっと短い時間にしてもよいでしょう。

初回のリポジトリセットアップ

今度は、リポジトリリポ(repo)と略されることもあります)ごとに作成の必要な作業を行います。まず、helloアプリケーションのルートディレクトリに移動し、新しいリポジトリの初期化を行います。

$ cd ~/environment/hello_app    # Just in case you weren't already there
$ git init
Reinitialized existing Git repository in
/home/ubuntu/environment/hello_app/.git/

リポジトリが初期化されたという意味のメッセージをGitが出力することにご注目ください。その理由は、Rails 6以降ではrails newコマンド(リスト 1.4)を実行すると自動的にGitリポジトリも生成するためです(Gitがtech業界でどれほど定着しているかがよくわかりますね)。このため、技術的にはgit initを必ずしも実行する必要はないと言えます。しかし他の一般的なGitリポジトリはそうではないので、常にgit initを実行する癖をつけておくのはよいことです。

次はgit add -Aを実行して、プロジェクトの全ファイルをリポジトリに追加します21

$ git add -A

このコマンドを実行すると、現在のディレクトリにあるファイルがすべて追加されます。ただし、.gitignoreに記載されているパターンにファイル名がマッチする場合、そのファイルは追加されません。.gitignoreファイルは、rails newコマンドを実行すると自動的に生成され、Railsプロジェクト用のパターンも記入されます。もちろん、自分でパターンを追加しても構いません22

Gitにプロジェクトのファイルを追加すると、最初はステージング(Staging)という一種の待機用リポジトリに置かれ、コミットを待ちます。安全のため、いきなりコミットしないようになっているのです。ステージングの状態を知るにはstatusコマンドを使います。

$ git status
On branch master

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
        .
        .
        .

ステージングエリアで控えている変更を本格的にリポジトリに反映(コミット)するには、commitコマンドを使います。

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

-mフラグを使うと、コミットメッセージをコマンドラインで直接指定できます。-mフラグを使わない場合はシステムのデフォルトのエディタが開き、そこでコミットメッセージを入力します(本チュートリアルでは常に-mフラグを使っていきます)。

ここでコミットについて重要な点を解説しておきます。Gitにおけるコミット操作は、あくまでローカルマシン上にしか記録されないことに注意してください。git pushコマンドで変更をリモートリポジトリにプッシュする方法については1.4.4で解説します。

ちなみに、logコマンドでコミットメッセージの履歴を参照できます。

$ git log
commit b981e5714e4d4a4f518aeca90270843c178b714e (HEAD -> master)
Author: Michael Hartl <michael@michaelhartl.com>
Date:   Sun Aug 18 17:57:06 2019 +0000

    Initialize repository

ログがある程度以上長い場合は、qキーを押して終了します。開発基礎編 Gitでも解説していますが、git logではlessコマンドをインターフェイスとして使っています。なお、lessについての詳細は、開発基礎編 コマンドライン「使うならmoreよりless」で説明しています。

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コマンドのlsapp/controllers/ディレクトリの中身を表示した後、rmコマンドをうっかり実行してしまい、このディレクトリを削除してしまったとします(表 1.1)。なお開発基礎編 コマンドライン「ディレクトリのリネーム/コピー/削除を行う」でも説明したように、ここで使っている-rfフラグは、「recursive」(サブディレクトリやその中のファイルもすべて削除する)と「force」(削除して良いかどうかをユーザーに確認しない)を指定するオプションです。

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

$ git status
On branch master
Changes not staged for commit:
  (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
        deleted:    app/controllers/concerns/.keep

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 tree clean
$ ls app/controllers/
application_controller.rb  concerns/

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

1.4.3 GitHub

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

GitHubを始める方法は単純明快です。GitHubアカウントをお持ちでない方はGitHubアカウントに登録(サインアップ)しましょう(図 1.2523

6
図 1.25: GitHubにユーザー登録する

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

6
図 1.26: “New repository”オプションを選択する

新しいリポジトリページのフィールドに、リポジトリ名(hello_app)と適当なdescription(説明)を入力したら、万全の注意を払って確実に“Private”オプションを選択してください( 1.27)。公開されているpublicリポジトリで自分のRailsアプリをうっかり人目にさらしてしまっても原理的には安全ではありますが、それでも秘密鍵を漏らしてしまうなど、何があってもおかしくありません。ですから、何か起きる前にリポジトリをデフォルトでprivateにしておく用心深さが大事です24

6
図 1.27: GitHubでprivateリポジトリを作成する

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

6
図 1.28: 既存のリポジトリを追加する

最後にリスト 1.16のコマンドを実行すると、最初の1回はGitHubのパスワードを入力しなければいけませんが、以後はリスト 1.15の設定のおかげでパスワード入力は(設定したキャッシュタイムアウト期間が過ぎるまでは)不要になります。

リスト 1.16: GitHubをリモートoriginに追加してそのリポジトリにpushする
$ git remote add origin https://github.com/<あなたのGitHubアカウント名>/hello_app.git
$ git push -u origin master

リスト 1.16の最初のコマンドは、GitHubをリポジトリのoriginとしてGitの設定ファイルに追加するためのものです。次のコマンドでは、ローカルのリポジトリをリモートのoriginにプッシュ(push)します(-uフラグについては気にする必要はありません。気になる方は "git set upstream" で検索してみてください)。なお、リスト 1.16<あなたのGitHubアカウント名>の部分は実際のユーザー名に置き換える必要があります。たとえば著者が行うのであれば、実行するコマンドは次のようになります。

$ git remote add origin https://github.com/mhartl/hello_app.git

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

6
図 1.29: GitHubのリポジトリページ

1.4.4 ブランチ、編集、コミット、マージ

 1.4.3の手順に沿って進めた場合、READMEファイルの内容が自動的にGitHub画面に表示されることに気付いたでしょう(図 1.30)。このREADME.mdファイルは、リスト 1.4のコマンドを実行すると自動生成されます。ファイル名の拡張子が「.md」となっているファイルは、Markdownという人間にとってもう少し読みやすい記法を使って書きます26。Markdownは簡単にHTMLに変換でき、GitHubでも前述のように.mdファイルを自動的にHTMLで表示してくれます。

Railsが自動生成したREADMEをそのまま使ってもよいですし、プロジェクトに合わせて内容を書き換えてももちろん構いません。ここでは、READMEをRailsチュートリアル固有の内容に合わせて書き換えてみましょう。それと同時に、Gitでbranch、edit、commit、mergeを行う際にお勧めのワークフローの実例をご覧いただきます27

6
図 1.30: GitHubのデフォルトRails READMEの表示

Branch(ブランチ)

Gitは、ブランチ(branch)を極めて簡単かつ高速に作成することができます。ブランチは基本的にはリポジトリのコピーで、ブランチ上では元のファイルを触らずに新しいコードを書くなど、自由に変更や実験を試すことができます。通常、親リポジトリはmasterブランチと呼ばれ、トピックブランチ(短期間だけ使う一時的なブランチ)はcheckout-bフラグを使って作成できます。

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

2つ目のコマンド(git branch)は、すべてのローカルブランチを一覧表示します。「*」はそのブランチが現在使用中であることを表します。1番目のgit checkout -b modify-READMEコマンドで、ブランチの新規作成とそのブランチへの切り替えが同時に行われていることにご注目ください。modify-READMEブランチに「*」が付いていることで、このブランチが現在使用中であることが示されています

ブランチの真価は他の開発者と共同で作業する時に発揮されますが28、本チュートリアルのように一人で作業する時にも非常に有用です。masterブランチはトピックブランチで行った変更に影響されないので、たとえブランチ上のコードがめちゃくちゃになってしまっても、masterブランチをチェックアウトしてトピックブランチを削除すれば、いつでも変更を破棄する事ができます。具体的な方法についてはこの章の最後で説明します。

ちなみに、通常このような小さな変更のためにわざわざブランチを作成する必要はありませんが、「よい習慣を身につけるのは早ければ早いほど望ましい」ので、今のうちに少しでも練習しておきましょう。

Edit(編集)

トピックブランチを作ったら、READMEを編集してカスタムコンテンツを追加しましょう(リスト 1.17図 1.31)。

リスト 1.17: 新しいREADMEファイル 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!
6
図 1.31: READMEファイルを編集する

Commit(コミット)

変更が終わったら、ブランチの状態を確認してみましょう。

$ git status
On branch modify-README
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

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(-)

-aフラグは慎重に扱ってください。最後のコミット後に新しいファイルを追加した場合は、まずgit addを実行してバージョン管理下に置く必要があります。

コミットメッセージは現在形かつ命令形で書くようにしましょう29。Gitのモデルは、(単一のパッチではなく)一連のパッチとしてコミットされます。そのため、コミットメッセージを書くときには、そのコミットが「何をしたのか」と過去形の履歴スタイルで書くよりも「何をする」ためのものなのかを現在形かつ命令形で書く方が、後から見返したときにわかりやすくなります。さらに、現在形かつ命令形で書いておけば、Gitコマンド自身によって生成されるコミットメッセージとも時制が整合します。詳しくは開発基礎編 Git「Gitにコミットするとは」をご覧ください。

Merge(マージ)

ファイルの変更が終わったので、masterブランチにこの変更をマージ(merge)します。

$ git checkout master
Switched to branch 'master'
$ git merge modify-README
Updating b981e57..015008c
Fast-forward
 README.md | 27 +++++----------------------
 1 file changed, 5 insertions(+), 22 deletions(-)

Gitの出力には34f06b7のようなランダムな文字列(ハッシュ)が含まれていることにご注目ください。Gitはこれらをリポジトリの内部処理に使っています。この文字列は環境の違いにより上記のものと多少異なるかもしれませんが、他の部分はほぼ同じはずです。

変更をマージした後は、git branch -dを実行してトピックブランチを削除すれば終わりです。

$ git branch -d modify-README
Deleted branch modify-README (was 015008c).

トピックブランチの削除は必須ではありません。実際、トピックブランチを削除せずにそのままにしておくことはよく行われています。トピックブランチを削除せずに残しておけば、トピックブランチとmasterブランチを交互に行き来して、キリの良い所で変更をマージする事ができます。

上で述べたように、git branch -Dでトピックブランチ上の変更を破棄することもできます。

# これはあくまで例です。ブランチでミスをした時以外は実行しないでください。
$ git checkout -b topic-branch
$ <ココで何か変更を加えてみてください>
$ git add -A
$ git commit -a -m "Make major mistake"
$ git checkout master
$ git branch -D topic-branch

-dフラグと異なり、-Dフラグは変更をマージしていなくてもブランチを削除してくれます。

Push(プッシュ)

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

$ git push

デフォルトのREADMEと同様、更新されたREADMEもGitHubでよしなにHTMLに変換してくれます(図 1.32)。

6
図 1.32: GitHub上の更新したREADMEファイル

1.5 デプロイする

まだ第1章の途中ですが、このRailsアプリは既に本番環境にデプロイしようと思えばできる状態になっています。1.4でバージョン管理システムを設定済みなので、技術的にはこの時点でのアプリケーションのデプロイは必須ではありませんが、頻繁に本番環境にデプロイすることによって、開発サイクルでの問題を早い段階で見つけることができます。開発環境のテストを繰り返すばかりで、いつまでも本番環境にデプロイしないままだと、アプリケーションを公開するぎりぎりの時になって思わぬ事態に遭遇する可能性が高まります30

かつてはRailsアプリの本番デプロイは大変な作業でしたが、ここ数年急速に簡単になってきており、さまざまな本番環境を選択できるようになりました。Phusion Passenger(ApacheやNginx31 などのWebサーバー用のモジュール)を実行できるさまざまな共有ホストや仮想プライベートサーバー(VPS)の他に、一通りのデプロイ環境を提供するEngine YardRails Machine、クラウドサービスを提供するEngine Yard CloudHerokuなどがあります。

私のお気に入りはHerokuで、Railsを含むRuby Webアプリ用のホスティングプラットフォームです(お気づきの方がいるかもしれませんが、Heroku自身もRailsで構築されています)。Herokuは、ソースコードのバージョン管理にGitを使っていれば、Railsアプリケーションを簡単に本番環境にデプロイできます(Gitを導入したのは、まさにこのHerokuで使うためでもあります。まだGitをインストールしていない方は1.4を参照してください)。さらに、Herokuのfree tier プランには、チュートリアルでの利用を含むさまざまな用途のための機能が十分過ぎるほど備わっています。

この章では、最初のアプリケーションをHerokuにデプロイします。作業内容の一部に少しばかり高度な部分も含まれていますが、今はすべてを理解しておく必要はありませんのでご安心ください。今大事なのは、この章の終わりまで手順を進めることで、作成したアプリケーションを実際のWebサービスとしてデプロイすることです。

1.5.1 Herokuのセットアップとデプロイ

解説動画「第1章 後編: 10. Heroku にデプロイする」から詳しく解説

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

group :production do
  gem 'pg', '1.1.4'
end

HerokuではSQLiteがサポートされていないため、リスト 1.6の変更を行って、sqlite3 gemが本番環境に導入されないようにしておきます32

group :development, :test do
  gem 'sqlite3', '1.4.1'
  gem 'byebug',  '11.0.1', platforms: [:mri, :mingw, :x64_mingw]
end

最終的にGemfileリスト 1.18のようになります。

重要: 本書のGemfileで固定した各gemのバージョンは公式リポジトリと一致している必要があります。現在の章に合わせてご参照ください。(オンラインで読んでいる場合は問題ないはずですが、電子書籍などで読んでいる場合はご注意ください。)

リスト 1.18: 追加や並び替えを行ったGemfile Gemfile
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

gem 'rails',      '6.0.3'
gem 'puma',       '4.3.6'
gem 'sass-rails', '5.1.0'
gem 'webpacker',  '4.0.7'
gem 'turbolinks', '5.2.0'
gem 'jbuilder',   '2.9.1'
gem 'bootsnap',   '1.4.5', require: false

group :development, :test do
  gem 'sqlite3', '1.4.1'
  gem 'byebug',  '11.0.1', platforms: [:mri, :mingw, :x64_mingw]
end

group :development do
  gem 'web-console',           '4.0.1'
  gem 'listen',                '3.1.5'
  gem 'spring',                '2.1.0'
  gem 'spring-watcher-listen', '2.0.1'
end

group :test do
  gem 'capybara',           '3.28.0'
  gem 'selenium-webdriver', '3.142.4'
  gem 'webdrivers',         '4.1.2'
end

group :production do
  gem 'pg', '1.1.4'
end

# Windows ではタイムゾーン情報用の tzinfo-data gem を含める必要があります
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]

本番用のgem(この場合はpg gem)をローカルの環境にはインストールしないようにするために、bundle installに特殊なフラグ「--without production」を追加します(リスト 1.19)。

リスト 1.19: 本番用以外のgemをインストールする
$ bundle install --without production

リスト 1.18で追加したgemは本番環境でしか使わないので、このフラグを追加したコマンドを実行してもローカル環境には本番用gemは反映されません。ではなぜ今リスト 1.19のコマンドを実行したかというと、pg gemを追加したことやRubyバージョンを指定したことをGemfile.lockに反映させないと、本番環境へのデプロイで失敗してしまうためです。これから行う本番環境へのデプロイを成功させるために、変更した内容のコミットも忘れずにおこないましょう。

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

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

$ heroku --version

Herokuがインストールされていると、バージョン番号とともにherokuのコマンドラインインターフェース(Command Line Interface: CLI)が利用可能であるというメッセージが表示されます。ただしほとんどの場合は最初からインストールされていないので、The Heroku CLIからインストールする必要があります33。クラウドIDEを使っている場合は、リスト 1.20のコマンドを実行することでHeroku CLIをインストールできます。

リスト 1.20: クラウドIDE上でHerokuをインストールするコマンド
$ source <(curl -sL https://cdn.learnenough.com/heroku_install)

リスト 1.20のコマンドでインストールできたかどうかは、次のコマンドで確認することができます。正しくインストールできていれば、バージョン番号が表示されるようになります(バージョン番号は異なっていても大丈夫です)。

$ heroku --version
heroku/7.27.1 linux-x64 node-v11.14.0

Herokuのコマンドラインインターフェイス(CLI)がインストールされていることが確認できたら、いよいよherokuコマンドで、Herokuユーザー登録時に使ったメールアドレスとパスワードを入力してログインします(なお--interactiveオプションを使うと、herokuコマンドでブラウザを開かないようにできます)。

$ heroku login --interactive

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

リスト 1.21: Herokuに新しいアプリケーションを作成する
$ heroku create
Creating app... done, blooming-bayou-75897
https://blooming-bayou-75897.herokuapp.com/ |
https://git.heroku.com/blooming-bayou-75897.git

この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.21)を実行した際に生成されたアドレスをブラウザで開くだけです34。実行結果を図 1.33に示します。ページの内容は図 1.22とまったく同じですが、今やそれがインターネット上の本番Webページとして確かに公開されているのです35

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

演習

  1. 1.3.4.1と同じ変更を行い、本番アプリでも「hola, mundo!」を表示できるようにしてください。
  2. 1.3.4.1と同様、ルートへのルーティングを変更してgoodbyeアクションの結果が表示されるようにしてください。またデプロイ時には、Git pushのmasterをあえて省略し、git push herokuでデプロイできることを確認してみてください。

1.5.4 Herokuコマンド

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

$ heroku rename rails-tutorial-hello

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

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

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

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

ここで使ったコード片は第4でまた登場します。37

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

演習

  1. heroku helpコマンドを実行し、Herokuコマンドの一覧を表示してみてください。Herokuアプリのログを表示するコマンドはどれですか?
  2. 上の演習で見つけたコマンドを使って、Herokuアプリの最近のログ(log)を調べてみましょう。直近に発生したイベントは何でしたか?(このログを調べるコマンドを覚えておくと、本番環境の不具合を見つけるときに役立ちます)

1.6 最後に

この章では開発環境のセットアップやインストール、バージョン管理、本番環境へのデプロイなど、多くの課題を乗り越えました。次の章では1で学んだことを基礎として、データベースも備えたtoyアプリを作りながらRailsでできることの概観を学びます。

また、各章の最後にはTwitterで進捗を投稿できるボタンがあります。ハッシュタグ『#Railsチュートリアル』を使って他の学習者と繋がることもできるので、ぜひお気軽にご活用ください。

Railsチュートリアルには公式Twitterアカウント『@RailsTutorialJP38もあります。Railsチュートリアルの最新情報を周知したり学習者のコメントをハイライトしているので、よければこちらもフォローしてみてください。

1.6.1 本章のまとめ

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

1.7 本チュートリアルで用いている慣習

本チュートリアルで用いているコマンド操作などの慣習のほとんどは、見ればすぐわかるものです。このセクションでは、見ただけではわからない可能性のある慣習について補足します。

本チュートリアルでは、Railsチュートリアル前提知識シリーズの開発基礎編 コマンドラインで解説されているコマンドを多用しています。簡単のため、コマンドラインの例に使っているプロンプトには、以下のようにUnixスタイルのドル記号を用いています。

$ echo "hello, world"
hello, world

Railsにも、コマンドラインで実行できるコマンドが多数備わっています。たとえば、 1.3.2では次のようにrails serverコマンドを実行してローカル開発用のWebサーバーを起動しています。

$ rails server

Railsチュートリアルでは、コマンドラインのプロンプトと同様、ディレクトリの区切り文字もUnixの慣習に従って表記しています(スラッシュ文字/)。たとえば、サンプルアプリケーションのproduction.rb設定ファイルが置かれているディレクトリは以下のように表します。

config/environments/production.rb

上のファイルパスは、そのRailsアプリケーションのルートディレクトリを起点とする相対パスとして理解すべきです。そしてこのルートディレクトリの位置はシステムによって異なります。たとえば、クラウドIDE(1.2.1)の場合は以下のようなディレクトリに配置されます。

/home/ubuntu/environment/sample_app/

つまり、この場合のproduction.rbの完全なファイルパス(フルパス)は以下のようになります。

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

本チュートリアルでは、こうしたアプリケーションパスを常に書くことはせず、基本的にconfig/environments/production.rbのように省略した形で表記します。

Railsチュートリアルではさまざまなプログラムからの出力を多数掲載しています。これらの出力結果は、システムによって微妙に異なりますが、そうした些細な違いはいくらでも見つけられるので、掲載されている出力結果と自分の環境での出力結果が一字一句違わず一致するとは限りません。しかしこうした微細な違いは、はっきり言えば問題にはなりません。もうひとつ言うと、システム環境が違うとエラー出力が変わるコマンドもあります。そうしたエラーを本チュートリアルでひとつ残らず網羅しようとすれば、筆者がシジフォスと同じ苦しみを味わうことになりますので、エラーについてはそのアプローチではなく「エラーメッセージはググってください」とGoogleに丸投げする手法を採用しています。これは現実のソフトウェア開発においても非常に有用な手段なのです(コラム 1.2)。本チュートリアルを進めていて詰まってしまったらRailsチュートリアルのヘルプページに掲載されている情報源にあたってみることをオススメします39

RailsチュートリアルではRailsアプリケーションをテストする方法についても解説していますので、ほんの小さな特定のコード片の違いが原因でテストスイートが失敗することもあれば(テストスイートが失敗すると赤い文字で表示されます)、パスすることもある(テストスイートがパスすると緑色の文字で表示されます)ことを知っておくと何かと役に立ちます。わかりやすくするため、失敗するテストには red 、パスするテストには green と書いてあります。

最後になりますが、Railsチュートリアルではサンプルコードをよりわかりやすくするため、2つの慣習を採用しています。1つ目は、注目して欲しい行を以下のように色を変えてハイライトしています。

class User < ApplicationRecord
  validates :name,  presence: true
  validates :email, presence: true
end

このようにコード行をハイライトすることで、そのコードサンプルで追加された新しい行を示すこともあれば(例外もありますが)、その前のコードサンプルとどこが違うかを示すこともあります。2番目は、同じコードを何度も書かずに省略するために、以下のようにドットを縦に並べて省略を表します。

class User < ApplicationRecord
  .
  .
  .
  has_secure_password
end

この縦のドットはコードが省略されていることを表しているので、そのままコピペしないでください。

1. Google Brainでも採用された15分ルール:「何かに詰まった時、まず自分で15分解決を試みなさい。そして、15分経ったら、他の人に助けを求めなさい。」が参考になります。
2. 例えばfooという名前のメソッド定義を見つけるには、「def foo」をグローバル検索します。
3. AWSのサイトのように継続的に更新されているため、詳細な手順は異なっているかもしれません。コラム 1.2の「熟練」の考え方を参考に細かな差異にも対応してみましょう。
6. 本チュートリアルをやった経験のある方なら、“rails-tutorial-6”のようにちょっと名前を変えて新しい環境で始めるとよいでしょう。
7. ここでは開発基礎編 コマンドライン2.23.1で解説したechoコマンドと>>(append)コマンドを使います。>>は賢いので、append先のファイルが存在しなくても作ってくれます。
8. この手順は、ネイティブシステムとクラウドIDEのディレクトリ構成を一致させるためのものです。「熟練」している方はこの手順をスキップしてお好きなディレクトリ構成で進めていただいて構いません。
9. 「シェル」とは、実際に動くコマンドやプログラムに「殻(shell)のようにかぶさっている」インターフェイスと考えるとよいでしょう。
10. 操作を誤ったときの被害もその分甚大ですが。
11. これは「熟練」の典型的な例と言ってよいでしょう(コラム 1.2)。
12. 同様にして、~> 6.0と指定するとバージョン6.9のgemがインストールされる可能性はありますが、6.0がインストールされることはありません。この指定法は、gemのプロジェクトがセマンティックバージョニング(略称: semver)と呼ばれる方式でバージョン番号を管理している場合、特に便利です。セマンティックバージョニングとは、ソフトウェア同士の依存関係を壊さないよう変更を最小限にしてリリース番号を与える方法です。
13. コマンドラインでgem list <gem名>を実行して各gemの正確なバージョン番号を知ることもできますが、リスト  1.6を使うのが無難でしょう。
14. 表 3.1に示したように、実はinstallを省略できます。bundleコマンドそれ自体がbundle installのエイリアスであるためです。
15. ここで“C”はキーボードの文字を指していますが、大文字という意味ではありませんので、わざわざShiftキーを押して大文字の“C”にする必要はありません。
16. 本チュートリアルで使っている図中のCloud9のURLは、rails-tutorial-c9-mhartl.c9.io からAWS上の特定のURLに変更されています。スクリーンショットを撮った時点と現時点との合間にURLの規則が変わる可能性がありますが、都合上、元のままにしています(図 1.22)。この程度の小さな不一致であれば自力で解決できるぐらいのスキルを、一緒に本チュートリアルで身につけていきましょう(コラム 1.2)。
17. 利用しているエディタによっては「invalid multibyte character」といったエラーメッセージが表示されることがあるかもしれませんが、気にする必要はありません。このメッセージを表示しないようにする方法が知りたい場合は、エラーメッセージでググってみてください。
18. 日本語でWeb上から無料で読める書籍としては Pro Git が有名です。
19. 筆者はこういう場合自分のGitにVimというエディタを設定するのが好みですし、開発基礎編 テキストエディタ「最小限の環境で使えるVimエディタ」にも書いたように、Minimum Viable Vim™という最小限の設定(あるいはもっといい設定があれば)をお使いの方にはおすすめです。vimを使いたい方は、リスト 1.13`which nano`の部分を`which vim`に書き換えて使ってください。
20. 理論上はもっと長い時間パスワードを保持することもできますが、クラウドIDEではどうやらこのタイマーが1日1回ぐらいの感じでリセットされているようなので、これ以上長い時間を設定してもあまり意味はなさそうです。
21. 多くの開発者は、このコマンドとほぼ同等git add .コマンドを使います(このドットはカレントディレクトリを表します)。両者に違いが生じることはめったにありませんが、普通はgit add -Aを使いますし、Gitの公式ドキュメントにもそう書いてあるので、本書ではこの書き方を採用しています。
22. チュートリアル本編ではこのファイルを修正することはありませんが、3.6.gitignoreファイルへの追加例があります。これは、3.6で行うオプションの詳細テスト設定の一部です。
23. HerokuやAWS、SendGridやTravis CIなどの有料プランが無料で使える「GitHub Education 学生開発者パック」という学生向け支援プログラムもあります。学校が発行するメールアドレスまたは学生証などの証明書類で登録・申請できるので、学生の方はぜひ検討してみてください。
24. 現在のGitHubは、public/privateを問わずいくつでもリポジトリを作成できます。
25. もうひとつのSSHオプション(図 1.28)は中級ユーザー向けなので、SSH鍵の生成や設定を問題なくできる方はそうしていただいて構いません。なお、SSHオプションにするとパスワードが自動的にシステムにキャッシュされるので、リスト 1.15で説明した手順は不要になります。
27. Gitリポジトリをビジュアル表示するには、AtlassianのSourceTreeアプリケーションが便利です。
28. 現在のGitHubでは、public/privateを問わず人数の制限なしにリポジトリを共有できます。共同開発については開発基礎編 Git4章「Gitで共同作業する」の例などをご覧ください。
29. これは英語で書く場合のルールです。日本語であれば「〜を追加」などの体言止めがよいでしょう。
30. Railsチュートリアルのサンプルアプリケーションでは気にする必要はありません。作りかけの恥ずかしいWebアプリケーションをネットにうっかり公開してしまわないだろうかと心配する方もいらっしゃるかと思いますが、それを防ぐための方法はいくつもありますのでご安心ください。1.5.4はその方法の1つです。
31. “Engine X" と発音します。
32. SQLiteはスマートフォンなどの組み込みデータベースとして広く用いられており、セットアップがとても簡単なのでRailsでもデフォルトのデータベースとして使われていますが、データベースをバックエンドに持つWebアプリケーションで使う設計ではありません(訳注: Webアプリケーションではデータベースにきわめて多数の更新を同時にかけることがありますが、SQLiteはこうした同時更新が得意ではありません)。詳細については3.1を参照。
34. もちろんここに表示されている著者のアドレスではなく、あなたのアドレスを使ってください。クラウドIDEではなくローカルコンピュータで作業している場合は heroku open コマンドで自動的にブラウザ表示することもできます。
35. 1.3.4.1の演習を完了した方は表示結果が少し違うかもしれません。
36. このソリューションは通称「あいまいさを利用したセキュリティ」と呼ばれ、ホビー目的程度であれば十分有効です。最初からもっとまともなセキュリティを導入したいのであれば、RailsのHTTP BASIC認証の利用をオススメします。とはいえ、BASIC認証の実装はやや込み入っているので、それなりの熟達したスキルが必要となります(コラム 1.2)。また、この問題を指摘してくれたAlfie Patesに感謝いたします。
37. Rubyではよくあることですが、実はもっとコンパクトに書けるのです。今回の例では、Rubyのsampleメソッドを使うことで ('a'..'z').to_a.sample(8).join と書くこともできます。指摘してくれた読者のStefan Pochmannに感謝! 著者もまた新たなRubyの一面に触れられました。
38. 最新のRailsチュートリアル情報が分かるRailsチュートリアルマガジンもオススメです。フォローすると最新記事をメールでお知らせします。
第1章 ゼロからデプロイまで Rails 6.0 (第6版)