1.1.1 Попередні вимоги

Немає формальних попередніх вимог для цієї книжки — Ruby on Rails Tutorialмістить інтегрований курс не тільки для Rails, але також для підлеглої мови Ruby, тестового фреймворку Rails по замовчанню (MiniTest), командного рядка Unix, HTML, CSS, невеликої кількості JavaScript, та навіть трохи SQL. Є багато матеріалу для засвоєння, тим не менш, та я загалом рекомендую мади деякий досвід в HTML та програмуванні, перет тим, як розпочати цей курс. Кажучи так, велика кількість початківців використовують Ruby on Rails Tutorial для вивчання веб розробки з самого початку, так що навіть якщо ви маєте обмежений досвід, я рекомендую зробити спробу. Якщо ви почуваєтесь спантеличеним, ви завжди можете повернутись назад, та почати з одного з ресурсів, перелічених нижче. Інша стратегія, рекомендована багатьма читачами, це просто пройте цей курс двічі; ви можете здивуватись, як багато ви вивчили за перший раз (та наскільки легше робити це вдруге).

Одне велике питання, коли вивчають Rails, це чи слід спочатку вивчати Ruby. Відповідь залежить від вашого персонального стилю навчання та наскільки багато досвіду програмування ви вже маєте. Якщо ви звикли вивчати все систематично, з початку і до кінця, або коли ви ніколи не програмували до цього, тоді вивчення Ruby спочатку може добре спрацювати для вас, і в цьому випадку я рекомендую Learn to Program від Chris Pine та Beginning Ruby від Peter Cooper. З другого боку, багато починаючих розробників на Rails захоплені можливістю створювати вебзастосування, і скоріше не чекатимуть, щоб завершити цілу книжку по Ruby, перед тим, як написати одну веб сторінку. В цьому разі я рекомендую слідувати короткому інтерактивному курсові на Try Ruby³Rails Tutorial. Якщо ви знайшли цей курс дуже складним, іи можете спробувати почати з Learn Ruby on Rails від Daniel Kehoe або One Month Rails, обі з яких більше націлені на повних початківців, чим Ruby on Rails Tutorial.

В кінуі курсу, не важливо де ви почали, ви будете готові для значно більшої кількості середніх та складних ресурсів Rails за рамками цієї книжки. Осб деякі, що я практично рекомендую:

• Code School: Добрі інтерактивні курси програмування онлайн
• Turing School of Software & Design: повний час, 27 тижнів програма тренінгу в Denver, Colorado, з $500 снижкою для читачів Rails Tutorial, використовуючи код RAILSTUTORIAL500
• Tealeaf Academy: Добрий оналйн розробницький буткамп Rails (включає ускладнений матеріал)
• Thinkful: Онлайн клас, що поєднує вас з професійним інженером по мірі просівання по базованому на проектах розкладу
• Pragmatic Studio: Онлайн курси Ruby and Rails від Mike та Nicole Clark. Разом з автором Programming Ruby Dave Thomas, Mike започаткував перші курси по Rails, що я відвідував в далекому 2006му році.
• RailsCasts від Ryan Bates: Чудові (здебільше безкоштовні) скринкасти з Rails
• RailsApps: Велика різноманіть деталізованих, розібраних по темах проектів Rails та курсів
• Rails Guides: По темах, та завжди оновлені довідники з Rails

1.1.2 Домовленості в цій книжці

Домовленості в цій книжці загалом пояснюють самі себе. В цьому розділі я зупинюсь на тих, що можуть викликати питання.

Багато прикладів в цій книжці використовують команди командного рядка. Для спрощення всі приклади командного рядка використовують підказку командного рядка в стилі Unix (знак долараa dollar sign), як тут:

$ echo "hello, world"
hello, world

Як зазначається в Розділі 1.2, я рекомендую, щоб користувачі всіх операційних систем (особливо Windows) використовували хмарне оточення розробки (Розділ 1.2.1), що іде з вбудованим командним рядком Unix (Linux). Це, крім іншого, корисно, оскільки Rails іде з багатьма командами, що можуть виконуватись в командному рядку. Наприклад, в Розділі 1.3.2 ми виконуємо локальний веб сервер розробки за допомогою команди rails server:

$ rails server

Як і з підказкою командного рядка, Rails Tutorial використовує домовленість Unix для роздільників каталогів (тобто звичайний слеш /). Наприклад, приклад застосування  production.rb має файл конфігурації в такому вигляді:

config/environments/production.rb

Цей шлях файлу має розумітись як відносний до корньового каталогу застосування, що буде відрізнятися в різних системах; в хмарній IDE (Розділ 1.2.1він виглядатиме так) :

/home/ubuntu/workspace/sample_app/

Таким чином, повний шлях до production.rb буде

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

Для скорочення я типово оминаю шлях  застосування, та пишу тільки config/environments/production.rb.

Rails Tutorial часто показує вихід різних програм (команд оболонки, статусі контроля версій, програм Ruby, таке інше). Оскільки є незліченні малі відмінності міжрізними комп’ютерними системами, вихід, що ви бачите, мож ене завжди точно співпадати з показаним в тексті, але це не є причиною для стурбованості. На додаток, деякі команди можуть продукувати помилки, в залежності від вашої системи; скоріше ніж спробувати завдання Sisyphean по документуванню всіх таких помилок в цьму курсі, я делегую це алгоритму “пошукай повідомлення про помилку в Google”, що, окрім іншого, є гарною практикою для розробки програмного забезпечення в реальному світі. Якщо ви отримали любі проблеми, слудуя цьому курсу, я рекомендую проконсультуватися з ресурсами, переліченими в Rails Tutorial help section.⁴

Оскільки Rails Tutorial покриває тестування застосувань Rails, часто є корисним, чи буде якісь з фрагментів коду викликати збій тестової сюїти (на що вказує червоний колір) або пройде (на зо вказує зелений колір). По домовленості код, що буде викликати збій тесту, вказується червоним, тоді як код, що проходитиме тест, вказується чк зелений.

Кожна глава в цьому курсі включає розділ Вправи, виконання яких необов’язкове, але рекомендоване. Щоб утримувати загальну дискусію незалежоною від вправ, рішення загалон не включаються в подальші лістинги коду. В рідких випадках, коли рішення використовується в подальшому, воно явно вирішується в головному тексті.

Нарешті, для зручності Ruby on Rails Tutorial адаптує дві домовленості, розроблені для того, щоб дільшість прикладів коду було легше зрозуміти. Перше, деякі лістинги коду включають один або більше підсвічених рядків, як показано нижче:

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

такі підсвічені рядки типово вказують найбільш важливий новий код в наданому прикладі, та часто (хоча і не однак) представляють різницю між представленим лістингом коду, та попереднім лістингом. Друге, для скорочення та простоти багато лістингів коду в книжці включають вертикальні крапки, як наведено нижче:

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

Ці крапки представляють пропущений код та не мають копіюватися буквально.

1.2.1 Оточення розробки

Зважаючи на різні ідіосинкразичні настроювання, можливо є стільки оточень розробки, як і програмістів на Rails. Щоб уникнути ціх складностей, Ruby on Rails Tutorial стандартизується на чудовому хмарному отченні розробки Cloud9. Зокрема, для цієї третьої редакції я радий бути партнером Cloud9, та запропонувати оточення розробки, спаціально скроєне для птреб цього курсу. Результуючий робочий простір Rails Tutorial Cloud9 надходить попередньо налаштованим з більшістю потрібного програмного забезпечення для професійної розробки на Rails, включаючи Ruby, RubyGems, Git. (Поза це,  єдина велика частина программного забезпечення, що ми встановимо окремо, є сам Rails, і це зроблено навмисно (Розділ 1.2.2).) Хмарна IDE також включає три базові компоненти, потрібні для розробки веб застосувань: текстовий редактор, навігатор файлової системи, та термінал командного рядка (Малюнок 1.1). Поміж інших можливостей, текстовий редактор хмарної IDE підтримує глобальний пошук “Find in Files”, що я вважаю за основу для навігації любого великого проекту  Ruby or Rails.⁶ Нарешті, навіть якщо ви прийняли рішення не використовувати виключно хмарний IDE в реальному житті (і я рекомендую вам вивчити інші тулкіти також), він провадить чудове введення в загальні можливості текстових редакторів та інших інструментів розробки.

Малюнок 1.1: Анатомія хмарного IDE.

Ось кроки для початку з хмарним оточенням розробки:

1. Безкоштовно зареєструйтеся на Cloud9⁷
2. Клацніть на  “Go to your Dashboard”(насправді це лівий сайдбар, прим. перекладача)
3. Оберіть “Create New Workspace”
4. Як змальовано на Малюнку 1.2, створіть робочий простір з назвою “rails-tutorial” (не “rails_tutorial”), встановіть його як “Private to the people I invite” (Приватний для запрошених людей), та виберіть іконку для Rails Tutorial (неіконку для Ruby on Rails)
5. Нажміть  “Create”(Створити)
6. Коли Cloud9 завершить налаштування робочого постору, оберіть та клацніть “Start editing”(Почати редагування).

Оскільки використання двох проміжків для відступів є майже універсальною домовленостю в Ruby, я також рекомендую змінити редактор для використання двох проміжків, замість чотирьох по замовчанню. Як показано на  Малюнку 1.3, ви можетее зробити це, клацнувши на іконці шестерні в верхньому правому кутку, та потім обрати “Code Editor (Ace)”, щоб змінити налаштування “Soft Tabs”. (Зауважте, що це набувє чинності беспосередньо; вам не треба натискати на кнопку “Save”).

Малюнок 1.2: Створення новго рабочого простору на Cloud9.

Малюнок 1.3: Встановлення Cloud9 для використання двох проміжків для відступів.

1.2.2 Встановлення Rails

Оточення розробки з Розділу 1.2.1 включає все програмне забезпечення, що нам треба для початку, окрім самого Rails.⁸Щоб встановити Rails, ми використаємо команду gem, надану менеджером пакунків RubyGems, що включає друкування команди, показаної в Лістингу 1.1 в вашому терміналі командного рядка. (Якщо ви розробляєте на вашій локальній системі, це означає звичане вікно терміналу; якщо це хмарне IDE, це означає використання інструменту командного рядка, показаного на Малюнку 1.1.)

$ gem install rails -v 4.2.0

Тут флаг -v дає впевненість, що буде встановлена вказана версяія Rails, що є важливим для отримання результатів, співпадаючих з цім підручником.

1.3.1 Bundler

Після створення нового застосування Rails, наступним кроком є використання Bundlerдля встановлення та включення gems, потрібних для застосування. Як коротко зазначено в Розділі 1.3, Bundler виконується автоматично (через bundle install) командою rails, але в цьому розділі ми зробимо деякі зміни до gems застосування по замовчанню, та виконаємо Bundler знову. Це включає відкриття файлу Gemfile в текстовому редакторі. (З хмарним IDE, це включає клацання на стрілці в навігаторі для відкриття каталогу застосування, да подвійне клацання на іконці Gemfile). Хоча точні номери версій та деталі можуть трохи відрізнятися, результат повинен виглядати дещо подібно до Малюнку 1.5 та Лістингу 1.4. (Код в цьому файлі є Ruby, але не турбуйтесь на цей момент щодо синтаксису; Глава 4 пояснює Ruby з більшою глибиною). Якщо файл та каталоги не з’являються, як показано на Малюнку 1.5, клацніть на навігаційній шестерні та оберіть “Refresh File Tree” (Оновити дерево каталогів). (Як головне правило, ви маєте оновити файлове дерево кожного разу, коли файли або каталоги не виглядають так, як очікується).

Малюнок 1.5: Gemfile по замовчанню в текстовому редакторі.

source 'https://rubygems.org'


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

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

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

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

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

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

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

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

Багато з ціх рядків закоментовані за допомогою символу #; вони присутні тут щоб показати вам деякі загально потрібні gems та надати приклади синтаксису Bundler. На цей момент нам не потрібні ніші gems, ніж встановлені по замовчанню.

Якщо ви не вказали номер версії кодманді gem, Bundler буде автоматично встановлювати найостаннішу версію gem. Це, наприклад, так виглядає в коді

gem 'sqlite3'

Є також два загальні шляхи, щоб задати диапазон версій gem, що дозволяє нам мати деякий контроль над версіями, що використовуються в Rails. Перший виглядає так:

gem 'uglifier', '>= 1.3.0'

Це встановлює останню версію uglifier gem (що обробляє компрессію файлів для конвеєру активів), доти, доки вона більша, ніж, або дорівнює версії 1.3.0 — навіть якщо це, скажімо, версія 7.2. Другий метод виглядає так:

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

Він встановлює gem coffee-rails, до тих пір, як вона новіша від версії 4.0.0, та не новіша, ніж 4.1. Іншими словами, нотація >= завжди встановлює останній gem, тоді як нотація ~> 4.0.0 встановлює тільки оновлені gems, що представляють мінорну точку релізу (наприклад, з 4.0.0 до 4.0.1), але не релізи мажорні точки (наприклад, з 4.0 до 4.1). На жаль, досвід показує, що навіть мінорні версії можуть зруйнувати речі, так що для Ruby on Rails Tutorial ми будемо стояти на засадах застереження, включаючи точні номери версій для усіх gems. Ви можете використовувати найбільш нові версії кожного gem, включаючи консрукцію ~>в Gemfile (що я загалом рекомендую для більш доствідчених користувачів), але будьте попереджені, що це може призвести до того, що ця інструкція буде діяти непередбачено.

Перетворення Gemfile в Лістингу 1.4 на використання точних версій gem versions призводить до коду, показаному в Лістингу 1.5. Зауважте, що ми також застосовуємо цю можливість, щоб змусити sqlite3 gem бути включеним тільки в оточенні розробки або тестування (Розділ 7.1.1), що запобігає потенційному конфлікту з базою даних, що використовується Heroku (Розділ 1.5).

source 'https://rubygems.org'

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

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

Коли ви розмістите вміст Лістингу 1.5 в Gemfile застосування, встановіть gems з використанням bundle install:⁹

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

Команда bundle install може зайняти деякий час, але коли він скінчиться, наше застосування буде готове до виконання.

1.3.2 rails server

Завдяки виконанню rails new в Розділі 1.3 та bundle install в Розділі 1.3.1, ми вже маємо застосування, що можна виконати — але як? На щастя, Rails іде з програмою командного рядка, або скриптом, що виконує локлаьний веб  сервер, щоб сприяти нам в розробці нашого застосування. Точна команда залежить від оточення, що ми використовуємо: на локальній системі ми просто викликаємо rails server (Лістинг 1.6), тодя як на Cloud9 вам треба надати додаткову IP адресу прив’язки та номер порту,щоб сповістити Rails серверу адресу, що він може використовувати, щоб зробити застосування видимим для загалу світу (Лістинг 1.7).¹⁰ (Cloud9 використовує спеціальні змінні оточення, $IP та $PORT, щоб присвоїти IP адресу та порт динамічно. Якщо ви бажаєте побачити значення ціх змінних, наберіть echo $IP або echo $PORT в командному рядку). Якщо ваша система скаржиться на відсутність робочого оточення JavaScript, навідайтесь на сторінку execjs в GitHub для переліку можливостей. Загалом я рекомендую встановити Node.js.

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

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

Яку б опцію ви не обрали, я рекомендую виконувати команду rails server в другому термінали (вкладинці), так що ви зможете надавати команди в першому терміналі, як показано на Малюнку 1.6 та Малюнку 1.7. (Якщо ви вже запустили сервер в першій вкладинці, нажміть Ctrl-C, щоб завершити його).¹¹ На локальному сервері спрямуйте свій браузер за адресою http://localhost:3000/; на хмарній IDE, перейдіть до Share на клацніть на Application address, щоб відкрити його (Малюнок 1.8). В жодному разі результат має виглядати як на Малюнку 1.9.

Малюнок 1.6: Відкриття нової вкладинки терміналу.

Малюнок 1.7: Виконання серверу Rails на окремій вкладинці.

Малюнок 1.8: Відкриття локального серверу, що виконується у хмарному просторі.

Малюнок 1.9: Сторінка Rails по замовчанню, що обслуговується як rails server.

Щоб побачити інформацію щодо першого застосування, клацніть на посиланні “About your application’s environment”. Хоча точні номери версій можуть відрізнятись, результат повинен виглядати я на Малюнку 1.10. Зрозуміло, що ми не потребуємо сторінку Rails по замовчанню в далекій перспективі, але вже зараз приємно побачити, що вона робить. Ми приберемо цю сторінку (і замінимо її на власну домашню сторінку) в Розділі 1.3.4.

Малюнок 1.10: Сторінка по замовчанню з оточенням застосування.

1.3.3 Model-View-Controller (MVC)

Навіть на ранній стадії є корисним отримати високорівневий огляд того, як робить застосування Rails (Малюнок 1.11). Ви можете вже знати, що стандартна структура застосування Rails (Малюнок 1.4) має каталог з назвою app/ с трьома підкаталогами: models, views та  controllers. Це підказка, що Rails слідує архітектурному шаблону model-view-controller (MVC), що змушує відділяти “логіку домену” (також її назівають “бізнес логікою”) від логіки вводу та презентації, що асоціюється з графічним інтерфейсом користувача (GUI). В разі веб застосувань, “логіка домену” типово представлена моделями даних для речей, таких як користувачі, статті та продукти, а в ролі GUI виступає звичайна веб сторінка в веб браузері.

Під час взаємодії з застосуванням Rails, браузер надсилає запит, який отримується веб сервером, та передається до Rails контроллера, який відповідає за те, що робити далі. В деяких випадках контроллер безпосередньо малює вигляд, що є шаблоном, який перетворюється на HTML, та відсилається назад в браузер. Більше загально, для динамічних сайтів, контролер спілкується з моделлю, що є об’єктом Ruby, що представляє елемент цього сайту (такий як користувач), та відповідає за комунікацію з базою даних. Після виклику моделі, контроллер малює вигляд, та повертає повну веб сторінку в браузер як HTML.

Малюнок 1.11: Схематична репрезентація архітектури model-view-controller (MVC).

Не хвилюйтесь, якщо поки ця дискусія виглядає трохи абстрактною. Ми будемо часто посилатись часто на цю сторінку. Розділ 1.3.4 показує перше застосування MVC, тоді як  Розділ 2.2.2 включає більш детальовану дискуссію по MVC в контексті іграшкового застосування. Нарешті, застосування-приклад буде використовувати всі аспекти MVC; ми покриємо контроллери та вигляди, починаючи з Розділу 3.2, моделі починаючи з  Розділу 6.1, та ми побачимо всі три, що роблять разом в Розділі 7.1.2.

1.3.4 Hello, world!

В якості першого застосування фреймворку MVC, ми зробимо мінімальні зміни до першого застосування, додаючи акцію контроллера для малювання рядка “hello, world!”. (Ми вивчимо більше про акції контроллера, починаючи з Розділу 2.2.2). Результатом буде заміщення сторінки по замовчанню з Малюнка 1.9 на сторінку “hello, world”, що є ціллю цього розділу.

Як підказує ім’я, акції контроллера визначені в контролерах. Ми назовемо нашу акцію  hello та розмістимо її в контроллері Application. Насправді на часі контроллер Application є єдиним контролером, що є у нас, що ми можемо перевірити, виконуючи

$ ls app/controllers/*_controller.rb

щоб побачити наявні контроллери. (Ми будемо створювати наші власні коонтроллери  Главі 2.) Лістинг 1.8 показує результуюче визначення hello, що використовує функцію render для повертання тексту “hello, world!”. (Не турбуйтесь щодо синтаксису Ruby прямо зараз; він буде пояснений більш детально в Главі 4.)

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

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

Маючи визначеною якцію, що повертає бажаний рядок, нам треба сповістити Rails використовувати цю акцію, замість сторінки по замовчанню Малюнок 1.10. Щоб робити це, ми редактуємо маршрутникRails, що сидить попереду контроллера на Малюнку 1.11 та визначає, куди відіслати запити, що надходять з браузера. (Я пропустив маршрутник  на Малюнку 1.11 для спрощення, але ми обсудимо його більш детально починаючи з Розділу 2.2.2). Зокрема, ми бажаємо змінити сторінку по замовчанню, кореневий маршрут, який визначає сторінку, що обслуговує кореневий URL. Оскільки це URL для адрес типу http://www.example.com/ (де нічого не слідує після фінальної косої), для скорочення на кореневий URL часто посилаються як на  /  (“слеш”).

Як видно в Лістингу 1.9, файл маршрутів Rails (config/routes.rb) включає закоментований рядок, що показує, як структуровати кореневий маршрут. Тут “welcome” є контроллером, та “index” є акцією в контролері. Щоб активувати кореневий маршрут, розкоментуйте цей рядок, видаливши символ решітки, та потім замістити його на код в Лістингу 1.10, що наказує Rails надсилати кореневий маршрут в акцію hello контроллера Application. (Як зазначено в Розділі 1.1.2, вертикальні крапки вказують на випущений код, та не мають копіюватись буквально).

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

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

З кодом з Лістингу 1.8 та Лістингу 1.10, кореневий маршрут повертає “hello, world!”, як ми і сподівались (Малюнок 1.12).

Малюнок 1.12: Перегляд “hello, world!” в браузері.

1.4.1 Встановлення та налаштування

Хмарне IDE, рекомендоване в Розділі 1.2.1, включає Git по замовчанню, так що в цьому випадку ви не потребуєте встановлення. В іншому випадку InstallRails.com (Розділ 1.2) включає інструкції для встановлення Git на вашій системі.

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

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

$ git add -A

$ git status
On branch master

Initial commit

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

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

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

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

    Initialize repository

1.4.2 Що гарного робить Git для вас?

Якщо ви ніколи не використовували контроль версій до цього, зараз може бути не дуже зрозумілим, що це все робить гарного для вас, так що дозвольте мені навести лише один приклад. Допустімо, що ви зробили якусь випадкову зміну, таку як, (жах!) видалили критичний каталог 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 означає “примусово і рекурсивно”, що рекурсивно видаляє всі файли, каталоги, підкаталоги, і таке інше, без запитання явного підтвердження кожного видалення.

Давайте перевіримо статус, щоб побачити що змінилось:

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

      deleted:    app/controllers/application_controller.rb

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

Ми бачимо, що файли були видалені, але зміни тільки на "робочому дереві"; вони ще не були закріплені. Це означає, що що ми можемо відмінити зміни, використовуючи команду checkout з флагом -f, щоб примусити перезапис поточних змін:

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

Втрачені файли та каталоги повернулись. Це чудово!

1.4.3 Bitbucket

Почати з Bitbucket нескладно:

1. Зареєструйтесь на Bitbucket , якщо ви ще це не зробили. 
2. Скопіюйте ваш публічний ключ в кліпборд. Як вказано в Лістингу 1.11, користувачі хмарного IDE можуть побачити свій публічний ключ за допомогою команди cat, що може бути потім виділений та скопійований. Якщо ви використовуєте вашу власну систему, та не бачите результату команди Лістингу 1.11, слідуйте інструкціям як встановити публічний ключ в вашому рахунку Bitbucket.
3. Додайте ваш публічний ключ до Bitbucket, клацнувши на зображенні аватара зправа, та оберіть “Manage account”, та потім “SSH keys” (Малюнок 1.13).

$ cat ~/.ssh/id_rsa.pub
                      

Малюнок 1.13: Додавання публічного ключа SSH.

Коли ви додасте ваш публічний ключ, клацніть на “Create” для створення нового репозитарія, як показано на Малюнку 1.14. Коли заповнюватимете інформацію про проект, попілкуйтесь про то, щоб залишити відміченим “This is a private repository”. Після клацніть на “Create repository”, слідуйте інструкціям під “Command line > I have an existing project”, що має виглядати подібно до Лістингу 1.12. (Якщо це не виглядає як Лістинг 1.12, це може бути через те, що публічний ключ не був доданий. В цьому разі я пропоную спробувати цей крок ще раз). Коли будете підіймати репозитарій, відповідайте yes, якщо побачите питання “Are you sure you want to continue connecting (yes/no)?”

Малюнок 1.14: Створення першого репозитарію застосування на Bitbucket.

$ git remote add origin git@bitbucket.org:<username>/hello_app.git
$ git push -u origin --all # pushes up the repo and its refs for the first time

Команди в Лістингу 1.12 спочатку наказують Git, щоб він додав Bitbucket в якості походження для вашого репозитарію, та тоді проштовхуємо ваш репозитарій на віддалене походження. (Не тербуйтесь про те, що робить флаг -u; якщо ви зацікавлені, зробіть пошук на предмет “git set upstream”). Звісно, вам треба замінити <username> на ваше дійсне ім’я. Наприклад, команда для мене виглядає так

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

Це в результаті дає сторінку на Bitbucket для репозитарію hello_app, з переглядом файлів, повною історією підтверджень, та безліччю інших корисностей (Малюнок 1.15).

Малюнок 1.15: Сторінка репозитарію на Bitbucket.

1.4.4 Branch, edit, commit, merge

Якщо ви слідували крокам в Розділі 1.4.3, ви можете помітити, що Bitbucket автоматично не розпізнав файл README.rdoc з нашого репозитарію, і замість цього скаржиться на головній сторінці репозитарію, що немає README (Малюнок 1.16). Це вказує на те, що формат rdoc не є досить загальним для того, щоб Bitbucket підтримував його автоматично, чому я, та майже кожний інший розробник, якого я знаю, замість обирає використовувати  Markdown. В цьому розділі ми змінимо файл README.rdoc на README.md, в спробі додати деякий особливий вміст Rails Tutorial до файлу README. В процесі цього ми побачимо перший приклад процесу branch-edit-commit-merge, що я рекомендую використовувати разом з Git.¹³

Малюнок 1.16:  повідомленняBitbucket про відсутній README.

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

$ git mv README.rdoc README.md

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

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

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

  renamed:    README.rdoc -> README.md

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

  modified:   README.md

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

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

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

# For illustration only; don't do this unless you mess up a branch
$ git checkout -b topic-branch
$ <really screw up the branch>
$ git add -A
$ git commit -a -m "Major screw up"
$ git checkout master
$ git branch -D topic-branch

Push

Тепер, коли ми оновили README, ми можемо проштовхнути зміни на Bitbucket, щоб подивитись на результат. Оскількі ми вже робили одне просування (Розділ 1.4.3), на більшості систем ми можемо оминути origin master, та виконати тільки git push:

$ git push

Як ми обіцяли в Розділі 1.4.4.2, Bitbucket гарно форматує новий файл з використанням  Markdown (Малюнок 1.17).

Малюнок 1.17: Покращений формат файлу README, форматований за допомогою Markdown.

1.5.1 Налаштування Heroku

Heroku використовує базу даних PostgreSQL  (вимовляється “пост-грес-кю-ель”, та часто називається скорочено, “Postgres”), що означає, що що нам треба додати  pg gem в промислое оточення, щоб дозволити Rails розмоіляти Postgres:¹⁷

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

Зауважте додавання rails_12factor gem, що використовується Heroku для обслуговування статичних активів, таких, як зображення або сторінки стилів. Результуючий Gemfile виглядає як в Лістингу 1.14.

source 'https://rubygems.org'

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

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

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

Щоб підготувати систему до розгортання в промисловому оточенні, ми виконуємо bundle install з особливим флагом, щоб запобігти локального встановлення любих промислових gems (що в нашому випадку складає pg та rails_12factor):

$ bundle install --without production

Оскільки додані нами gems в Лістингу 1.14 обмежені тільки промисловим оточенням, прямо зараз це команда насправді не встановлює жодних додаткових локальних gems, але це треба для оновлення Gemfile.lock з pg та rails_12factor gems. Ми можемо затвердити зміну наступним чином:

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

Далі ми маємо створити та сконфігурувати новий рахунок Heroku. Перший крок - зареєструватися на Heroku. Далі перевірте, чи ваша система вже має кліент командного рядка Heroku:

$ heroku version

Під хмарним IDE ви побачите номер версії Heroku, що вказує на те, що heroku CLI доступний, але на інших системах може бути потрібним встановити його, використовуючи Heroku Toolbelt.¹⁸

Коли ви перевірили, що інтерфейс Heroku командного рядка встановлений, використовуйте команду heroku для входу та додавання вашого SSH ключа:

$ heroku login
$ heroku keys:add

Нарешті, використовуйте команду heroku create для створення місця на серверах Heroku, де буде жити наше застосування (Лістинг 1.15).

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

Команда heroku створює новий субдомен для нашого застосування, доступного для безпосереднього перегляду. Зараз там нічого немає, так що почнемо розгортання.

1.5.2 Розгортання Heroku, крок один

Щоб розгорнути застосування першим кроком є застосування Git для просування головної гілки до Heroku:

$ git push heroku master

(Ви можете бачити деякі застережливі повідомлення, що ви поки можете ігнорувати. Ми обговоримо їх пізніше в Розділі 7.5.)

1.5.3 Розгортання Heroku, крок два

Нема кроку два! Він вже виконаний. Щоб побачити тільки що розгорнуте застосування, зайдіть за адресою, що ви бачили, коли виконували heroku create (Лістинг 1.15). (Якщо ви робите на локальній машині, замість хмарного IDE, ви також можете використовувати  heroku open). Результат виглядатиме, як на Малюнку 1.18. Сторінка, подібна до Малюнка 1.12, але вона виконується в промисловому оточенні на справжньому веб.

Малюнок 1.18: Перше застосування Rails Tutorial виконується на Heroku.

1.5.4 Команди Heroku

Є багато команд Heroku, але ми тільки доторкнулись до них в цій книжці. Давайте витратимо хвилину, щоб переіменувати застосування, як показано нижче:

$ heroku rename rails-tutorial-hello

Не використовуйте це ім’я, бо я вже зайняв його! Фактично, вам не треба перейматися цім прямо зараз; використання імені по замовчанню від Heroku є гарним. Але якщо ви бажаєте переіменувати ваше застосування, ви можете зробити його досить безпечним, використовуючи випадковий або прихований субдомен, як нижче:

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

З випадковим субдоменом хтось може відвідати ваш сайт, тільки якщо ви надасте йому адресу. (До речі, як попередній перегляд неймовірної компактності Ruby, ось код, що я використовую для генерації випадкових субдоменів:

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

Дуже мило .)

На додаток до підтримки субдоменів, Heroku також підтримує власні домени. (Фактично, сайт Ruby on Rails Tutorial розташований на Heroku; якщо ви читаєте цю книжку онлайн, ви прямо зараз дивитесь на Heroku сайт!). Дивіться документацію Heroku для додаткової інформації щодо власних доменів та інших можливостей Heroku.

1.6.1 Що ми вивчили в цій главі

• Ruby on Rails є фреймворком для веб розробки, написаним на мові програмування Ruby.
• Встановлення Rails, генерація застосування та редагування результуючих файлів є простими за допомогою зазадалегідь сконфігурованого хмарного оточення.
• Rails іде з командою командного рядка rails, що може генерувати нові застосування (rails new) та виконувати локальний сервер (rails server).
• Ми додали акцію контроллера та модифікували кореневий маршрут для створення застосування “hello, world”.
• Ми захистились від втради даних, та при цьому забезпечили можливість співпраці, розмістивши код нашого застосування під контроль версій Git та проштовхнули результуючй код в приватний репозитарій на Bitbucket.
• Ми розгорнули наше застосування в промислове оточення, використовуючи Heroku.

2.1.1 Іграшкова модель для користувачів

Є багато виборів для моделі даних користувача, так, як і є багато реєстраційних форм в веб; ми почнемо з вкрай мінімалістичного підходу. Користувачі нашого іграшкового застосування будуть мати унікальний цілий ідентифікатор id, публічне ім'я name (з типом string), та адресу email (також як string), що також буде і ім'ям користувача. Підсумовуючи, модель даних для користувачів показана на Малюнку 2.2.

Малюнок 2.2:  Модель даних для користувачів.

Як ми побачимо починаючи з Розділу 6.1.1, мітка users на Малюнку 2.2 відповідає до таблиці в базі даних, та атрибути id, name та email є ствпчиками в цій таблиці.

2.1.2 Іграшкова модель для мікропостів

Ядро моделі даних для мікропостів є навіт простішим, ніж для користувачів: мікропост має тільки поля id та content для тексту мікропоста (з типом text).² Однак є додаткове ускладнення: ми бажаємо асоціювати кожний мікропост з окремим користувачем. Ми досягнемо цього, записуючи user_id для власника посту. Результат показаний на Малюнку 2.3.

Малюнок 2.3: Модель даних для мікропостів.

Ми побачимо в Розділі 2.3.3 (та ще повніше в Розділі 11), як цей атрибут user_id дозволяє нам успішно відзеркалити той факт, що користувач потенційно має багато асоційованих мікропостів.

2.2.1 Тур по користувачам

Якщо ви зайдете на кореневий URL по / (читається “слеш” або коса лінія, як зазначено в Розділі 1.3.4), ми отримаємо ту ж саму сторінку Rails по замовчанню, показану на Малюнку 1.9, але в генерації підпорок для ресурсу Users ми також створили велику кількість сторінок для маніпулювання користувачами. Наприклад, сторінка для переліку всіх користувачів знаходиться на /users, та сторінка для створення нового користувача на /users/new. Залишок цього розділу присвячений карколомному туру по цім сторінках. По мірі просування може допомогти посилання на Таблицю 2.1, що показує відповідність між сторінками та URL.

Ми почали з сторінки, що відображує всіх користувачів в нашому застосуванні, що називається index; як ми, можливо, очікували, спочатку немає жодних користувачів (Малюнок 2.4).

Малюнок 2.4: Початкова сторінка index для ресурсу Users (/users).

Щоб створити нового користувача, ми заходимо на сторінку new, як показано на Малюнку 2.5. (Оскільки http://0.0.0.0:3000 або частина адреси в хмарній IDE є неявною, коли ми розробляємо локально, відтепер я буду випускати її). В Главі 7, це перетвориться в сторінку реєстрації користувача.

Малюнок 2.5: Нова сторінка користувача (/users/new).

Ми можемо створити користувача, ввівши значення ім'я та електронної пошти, на потім натиснувши на кнопку Create User. Результатом буде сторінка користувача show, як показано на Малюнку 2.6. (Зелене повідомлення привітання зроблене з використанням flash, який ми вивчимо в Розділі 7.4.2.) Зауважте, що URL є /users/1; як ви могли підозрювати, число 1 є просто атрибут id користувача з Малюнка 2.2. В  Розділі 7.1 ця сторінка перетвориться на профіль користувача.

Малюнок 2.6: Сторінка відображує дані про користувача (/users/1).

Щоб змінити інформацію про користувача, ми завітаємо на сторінку edit (Малюнок 2.7). Модифікуючи інформацію про користувача ми натискаємо на кнопку Update User, та так змінюємо інформацію щодо користувача в іграшковому застосуванні (Малюнок 2.8). (Як ми побачимо в деталях в Розділі 6, Ці дані зберігаються в базі даних). Ми додамо функціонал редагування/оновлення до простого застосування в Розділі 9.1.

Малюнок 2.7: Сторінка редагування користувача (/users/1/edit).

Малюнок 2.8: Користувач з оновленою інформацією.

Тепер ми створими другого користувача, знову навідавшись на сторінку new, та ввівши другий набір інформації користувача; утворена сторінка користувача index показана на Малюнку 2.9. Розділ 7.1 присвячений розробці списку користувачів в більш відполірованому стилі, де відображатимуться всі користувачі.

Малюнок 2.9: Сторінка списку користувачів (/users) з другим користувачем.

Показавши, як створювати, відображати та редагувати користувачів, ми нарешті дійшли до їх знищення (Малюнок 2.10).Ви повинні перевірити, що клацнувши на посиланні на Малюнку 2.10 знищить другого користувача, залишивши тілько одного в списку. (Якщо це не працює, переконайтесь, що JavaScript ввімкнено в вашому переглядачеві; Rails використовує JavaScript, щоб віддавати запити, потрібні для знищення користувача). Розділ 9.4 додає видалення користувача до простого застосування, пілкуючись про його використання окремим класом адміністративних користувачів.

Малюнок 2.10: Видалення користувача.

2.2.2 MVC в дії

Тепер, коли ми закінчили швидкий огляд ресурсу Users, давайте перевіримо одну окрему його частину в контексті шаблону Model-View-Controller (MVC), що ми розглядали в Розділі 1.3.3. Наша стратегія буде описати результати типового влучання переглядача — візит до списку користувачів на /users—в термінах  MVC (Малюнок 2.11).

Малюнок 2.11: Деталізована діаграма MVC в Rails.

Ось підсумок кроків, показаних на Малюнку 2.11:

1. Переглядач віддає запит для URL /users.
2. Rails маршрутизує /users до акції index в контролері Users.
3. Акція index запитує модель User щоб отримати всіх користувачів (User.all).
4. Модель User підтягує всіх користувачів з бази даних.
5. Модель User повертає список користувачів в контролер.
6. Контролер захоплює користувачів в змінній @users, що передається до перегляду index.
7. Перегляд використовує вбудований Ruby для малювання сторінки як HTML.
8. Контролер передає HTML назад в переглядач.⁵

Тепер давайте поглянемо на перелічені кроки більш детально. Ми починаємо з запиту, що походить від переглядача — тобто, результат набору URL в адресному рядку або клацання по посиланню (Step 1 на Малюнку 2.11). Цей запит потрапляє до маршрутизатора Rails (Step 2), що пересилає його до відповідної дії контролера базуючись на URL (та, як ми побачимо у Врізці 3.2, типі запиту). Код, що створює відображення користувацьких URL на дії контролера для ресурсу Usersпоказано в  Лістингу 2.2; цей код ефективно встановлює таблицю пар URL/дія, що показана в Таблиці 2.1. (Дивна нотація :users є символом, що ми вивчимо в Розділі 4.3.3.)

Rails.application.routes.draw do
  resources :users
  .
  .
  .
end

Покі ми дивимось на файл маршрутів, давайте улучимо момент, та асоціюємо кореневий маршрут зі списком користувачів, так щоб “коса” вела до /users. Дивіться що ми змінюємо відносно Лістингу 1.10

# root 'welcome#index'

на наступне

root 'application#hello'

Таким чином кореневий маршрут приведе до дії hello контролеру Application. В попередньому випадку ми бажаємо використовувати дію index в контролері Users, що ми можемо оброблити з використанням коду з Лістингу 2.3. (На цей момент я також рекомендую видалити дію hello з контрелера Application, якщо ви додали її на початку цього розділу).

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

Сторінки, показані в турі Розділу 2.2.1 відповідають діям в контролері Users, що є набором пов'язаних дій. Контролер, згенерований підпорками, схематично показаний на Лістингу 2.4. Зауважте нотацію class UsersController < ApplicationController, що є прикладом  Ruby класу знаслідуванням. (Ми обсудимо наслідування поверхнево в Розділі 2.3.4 та  накриємо обоє теми більш детально в Розділі 4.4.)

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

  def show
    .
    .
    .
  end

  def new
    .
    .
    .
  end

  def edit
    .
    .
    .
  end

  def create
    .
    .
    .
  end

  def update
    .
    .
    .
  end

  def destroy
    .
    .
    .
  end
end

Ви можете зауважити, що є більше дій, ніж сторінок; дії index, show, new та edit всі відповідають сторінкам з Розділу 2.2.1, але також є додаткові дій create, update та destroy. Ці дії типово не рисують сторінки (хоча вони можуть); замість цього їх головне призначення модифікувати інформацію щодо користувачів в базі даних. Це повний набір дій користувачів, підсумованих в Таблиці 2.2, представляє реалізацію REST архітектури в Rails (Врізка 2.2), що базується на ідеях представницької передачі стану сформульовану та названу ком'ютерним дослідником Roy Fielding.⁶ Зауважте з таблиці Таблиці 2.2 що є деяке перекриття URL; наприклад, обоє дії з користувачами, show та update відповідають до URL /users/1. Різниця між ними є метод запиту HTTP , на який вони відповідають. Ми познайомимось з запитами HTTP починаючи з Розділу 3.3.

Щоб дослідити відношення між контролером Users та моделлю User, давайте сфокусуємось на спрощеній версії дії index, показаній на Лістингу 2.5. (Код підпорок огидний та збентежуючий, так що я не показиватиму його).

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

Ця дія index має рядок @users = User.all (Step 3 на Малюнку 2.11), що змушує модель User отримати перелік всіх користувачів з бази даних (Step 4), т опотім розташувати їх в змінній @users (вимовляється “ет-юзерс”) (Step 5). Модель User сама по собі з'являється у Лістингу 2.6; хоча вона досить пласка, вона іде оздоблена великою кількістю функціональності завдяки наслідуванню (Розділ 2.3.4 та Розділ 4.4). Зокрема, з використанню бібліотеки Rails з назвою Active Record, код в Лістингу 2.6 розуміє User.all для повернення всіх користувачів з бази даних.

class User < ActiveRecord::Base
end

Як тільки змінна @users визначена, контролер викликає view (Step 6), показаний в Лістингу 2.7. Змінні, що починаються зі знаку @, називаються змінними екземпляру, та автоматично доступні для переглядів; в цьому випадку перегляд  index.html.erb в Лістингу 2.7 ітерує по списку @users та виводить рядок HTML для кожного елементу. (Пам'ятайте, ви не маєте розуміти цей код прямо зараз. Він показаний тільки для цілей ілюстрації).

<h1>Listing users</h1>

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

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

<br>

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

Перегляд конвертує свій вміст в HTML (Step 7), що потім повертається контролером в переглядач для відображення (Step 8).

2.2.3 Слабкість ресурсу Users

Хоча гарні для отримання загального огляду Rails, підпорки ресурсу Users  потерпають від декількох слабкостей.

• Немає перевірки даних. Наша модель User сприймає дані, такі як пусті імена та недійсні поштові адреси без заперечень.
• Немає аутентифікації. Немає поняття входу в систему, або виходу, та немає шляху запобігти користувачам від виконання довільних операцій.
• Немає тестів. Технічно це невірно — підпорки включають рудиментарні тести — але згенеровані тести не тестують жодних перевірок, аутентифікації, або жодних специфічних вимог.
• Немає а ні стилю, а ні розташування. Немає узгодженного стилю сайту або навігації.
• Немає дійсного розуміння. Якщо ви розумієте роботу коду підпорок, вам, напевне, не треба читати цю книжку. 

2.3.1 Мікротур в мікропости

Як і з ресурсом Users ми згенеруємо код підпорок для ресурсу Microposts з використанням rails generate scaffold, в цьому випадку реалізуючи модель даних на Малюнку 2.3:⁸

$ rails generate scaffold Micropost content:text user_id:integer
      invoke  active_record
      create    db/migrate/20140821012832_create_microposts.rb
      create    app/models/micropost.rb
      invoke    test_unit
      create      test/models/micropost_test.rb
      create      test/fixtures/microposts.yml
      invoke  resource_route
       route    resources :microposts
      invoke  scaffold_controller
      create    app/controllers/microposts_controller.rb
      invoke    erb
      create      app/views/microposts
      create      app/views/microposts/index.html.erb
      create      app/views/microposts/edit.html.erb
      create      app/views/microposts/show.html.erb
      create      app/views/microposts/new.html.erb
      create      app/views/microposts/_form.html.erb
      invoke    test_unit
      create      test/controllers/microposts_controller_test.rb
      invoke    helper
      create      app/helpers/microposts_helper.rb
      invoke      test_unit
      create        test/helpers/microposts_helper_test.rb
      invoke    jbuilder
      create      app/views/microposts/index.json.jbuilder
      create      app/views/microposts/show.json.jbuilder
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/microposts.js.coffee
      invoke    scss
      create      app/assets/stylesheets/microposts.css.scss
      invoke  scss
   identical    app/assets/stylesheets/scaffolds.css.scss

(Якщо ви отримали помилку, пов'язану зі Spring, просто виконайте команду ще раз). Щоб оновити нашу базу даних новою моделлю даних нам треба виконати міграцію, як в Розділі 2.2:

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

Тепер ми на позиції створення мікропостів в той же спосіб, як ми створювали користувачів в Розділі 2.2.1. Як ви могли здогадатись, генератор підпорок оновив файл маршрутів Rails для ресурсу Microposts, як бачимо у Лістингу 2.8.⁹ Як і з користувачами, правило маршрутизації resources :microposts відзеркалює URL мікропостів на дії в контролері Microposts, як бачимо а Таблиці 2.3.

Rails.application.routes.draw do
  resources :microposts
  resources :users
  .
  .
  .
end

Контролер Microposts сам з'являється в схематичному вигляді в Лістингу 2.9. Зауважте, що окрім маючи MicropostsController замість UsersController, Лістинг 2.9 є ідентичним до коду Лістингу 2.4. Це відображення архітектури REST, загальної для обох ресурсів.

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

  def show
    .
    .
    .
  end

  def new
    .
    .
    .
  end

  def edit
    .
    .
    .
  end

  def create
    .
    .
    .
  end

  def update
    .
    .
    .
  end

  def destroy
    .
    .
    .
  end
end

Щоб створити декілька реальних мікропостів ми введемо інформацію на сторінці нового мікропосту, /microposts/new, як показано на Малюнку 2.12.

Малюнок 2.12: Сторінка створеннямікропостів (/microposts/new).

На цьому місці введіть один або два мікропости, пілкуючись, щоб щонайменьше один мав user_id рівне 1, щоб співпадати з id першого користувача, створеного в Розділі 2.2.1. Результат повинен виглядати дещо схожим на Малюнок 2.13.

Малюнок 2.13: Сторінка списку мікропостів (/microposts).

2.3.2 Додаємо мікро до мікропостів

Кожний мікропост, що вартий свого ім'я, повинен мати деякі механізми для змушення довжини постів. Реалізація цього обмеження в Rails легка, за допомогою валідаторів; щоб сприймати мікропости щонайбільше 140 символів (à la Twitter), ми використовуємо валідатор довжини. В цей момент ви відкриваєте файл app/models/micropost.rb в вашому текстовому редакторі або IDE та вводите туди наступний вміст з Лістингу 2.10.

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

Код в Лістингу 2.10 може виглядати дещо містичним — ми розкажемо про валідацію більш докладно починаючи з Розділу 6.2 — але її ефект вже зрозумілий, якщо ми перейдемо створення нового мікропосту, та введемо більше ніж 140 символів в якості тексту мікропоста. Як бачимо на Малюнку 2.14, Rails відтворює повідомлення про помилку, що вказує, що вміст мікропосту задовгий. (Ми вивчимо більше про повідомлення помилок в  Розділі 7.3.3.)

Малюнок 2.14: Повідомлення про помилку для помилки створення мікропосту.

2.3.3 Користувач has_many мікропостів

Одна з найбільш потужних можливостей Rails є спроможність формувати асоціації між різними можелями даних. В випадку нашої моделі User кожний користувач потенційно має декілька мікропостів. Ми можемо виразити це в коді, оновивши моделі User та Micropost, як у Лістингу 2.11 та Лістингу 2.12.

class User < ActiveRecord::Base
  has_many :microposts
end

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

Ми можемо візуалізувати результат цієї асоціації на Малюнку 2.15. Оскільки стовпчик user_id в таблиці microposts, Rails (з використанням Active Record) може вивести, що мікропости асоційовані з кожним користувачем.

Малюнок 2.15: Асоціація між мікропостами та користувачами.

В Главі 11 та Главі 12 ми будемо використовувати асоціації користувачей та мікропостів обох, щоб відобразити всі з мікропостів користувача, та створити фід мікропостів в стилі Twitter. Поки що ми можемо перевірити вплив асоціації користувач-мікропост з використанням консолі, що є корисним інструментом для взаємодії з застосуваннями Rails. Спочатку ми викличемо консоль за допомогою rails consoleв командному рядку , та потім отримаємо першого користувача з бази данихз використанням User.first (зберігаючи результат в змінній first_user):¹⁰

$ rails console
>> first_user = User.first
=> #<User id: 1, name: "Michael Hartl", email: "michael@example.org",
created_at: "2014-07-21 02:01:31", updated_at: "2014-07-21 02:01:31">
>> first_user.microposts
=> [#<Micropost id: 1, content: "First micropost!", user_id: 1, created_at:
"2014-07-21 02:37:37", updated_at: "2014-07-21 02:37:37">, #<Micropost id: 2,
content: "Second micropost", user_id: 1, created_at: "2014-07-21 02:38:54",
updated_at: "2014-07-21 02:38:54">]
>> micropost = first_user.microposts.first    # Micropost.first would also work.
=> #<Micropost id: 1, content: "First micropost!", user_id: 1, created_at:
"2014-07-21 02:37:37", updated_at: "2014-07-21 02:37:37">
>> micropost.user
=> #<User id: 1, name: "Michael Hartl", email: "michael@example.org",
created_at: "2014-07-21 02:01:31", updated_at: "2014-07-21 02:01:31">
>> exit

(Я включив exit в останній рядок тільки для демонстрації як вийти з консолі. На більшості систем ви також можете використовувати Ctrl-D для тієї ж цілі).¹¹ Тут ми отримали доступ до мікропостів користувача використовуючи код first_user.microposts. Маючи цей код Active Record автоматично повертає всі мікропости з user_id , що дорівнює id з first_user (в цьому випадку 1). Ми навчимось більше щодо можливостей асоціації в Active Record в Главі 11 та Главі 12.

2.3.4 Наслідування наслідувань

Ми завершили наше обговорення іграшкового застосування з короткого опису ієрархій класів контролерів та моделей в Rails. Ця дискуссія набере більше сенсу, якщо ми матимемо деякий досвід з об'єктно-орієнтовним програмуванням; якщо ви не вивчали його, можете вільно пропустити цей розділ. Зокрема, якщо ви не знайомі з класами (що обговорюються в Розділі 4.4), я рекомендую повернутись до цього розділу піздніше.

Ми почнемо з структури наслідування моделей. Порівнюючи Лістинг 2.13 та Лістинг 2.14, ми бачимо, що обоє моделі, User та Micropost наслідують (через ліву кутову дужку <) від ActiveRecord::Base, що є базовим класом для моделей, що провадить ActiveRecord; діаграма, що підсумовує це відношення, зображена на Малюнку 2.16. Це завдячуючи наслідуванню від  ActiveRecord::Base об'єкти нашої моделі отримують можливість взаємодіяти з базою даних, трактувати стовпчики бази даних як атрибути Ruby, і таке інше.

class User < ActiveRecord::Base
  .
  .
  .
end

class Micropost < ActiveRecord::Base
  .
  .
  .
end

Малюнок 2.16: Ієрархія наслідування для моделей User та Micropost.

Структура наслідування для контролерів є тільки трхи складнішою. Порівнюючи Лістинг 2.15 та Лістинг 2.16, ми бачимо, що обоє контролери,  Users та Microposts, походять від контролеру Application. Вивчаючи Лістинг 2.17 ми бачимо, що цей ApplicationController сам походить від  ActionController::Base; це базовий клас для контролерів, що провадяться бібліотекою Rails Action Pack. Відношення між ціма класами проілючтровано на Малюнку 2.17.

class UsersController < ApplicationController
  .
  .
  .
end

class MicropostsController < ApplicationController
  .
  .
  .
end

class ApplicationController < ActionController::Base
  .
  .
  .
end

Малюнок 2.17: Ієрархія наслідування для контролерів Users та Microposts.

Як і з наслідуванням моделей, обоє контролери, Users та Microposts, отримують велику кількість функціональності, наслідуя від базового класу (в цьому випадку від ActionController::Base), включаючи можливість маніпулювати об'єктами моделей, фільтрувати входящі запити HTTP, та малювати перегляди як HTML. Оскільки всі контролери Rails наслідують від ApplicationController, правила, визначені в контролері Application автоматично застосовуються до кожної дії в застосуванні. Наприклад, в Розділі 8.4 ми побачимо, як включити допоміжники для журналювання всіх контролерів в застосуванні-прикладі. 

2.3.5 Розгортання іграшкового застосування

З завершенням ресурсу Microposts тепер є гарна нагода для просування нашого репозитарію на Bitbucket:

$ git status
$ git add -A
$ git commit -m "Finish toy app"
$ git push

Звичайно ви будете мати меньші, більш части коміти, але для цілей цього розділу один великий коміт є достатньо гарним. 

На цьому місці ви можете також розгорнути ваше іграшкове застосування на Heroku як в Розділі 1.5:

$ git push heroku

(Вважається, що ви створили Heroku застосування в Розділі 2.1. Інакше ви маєте виконати heroku create та потім git push heroku master.)

Щоб отримати робочу базу даних вам треба також мігрувати на виробничу базу даних:

$ heroku run rake db:migrate

Це оновить базу даних на Heroku необхідними моделями користувача та мікропоста. Після виконання міграції ви маєте бути в змозі використовувати іграшкове застосування в реальному оточенні, з підтримкою справжньої бази даних PostgreSQL (Малюнок 2.18).

Малюнок 2.18: Виконання іграшкового застосування в виробничому оточенні.

2.4.1 Що ми вивчили в цій главі

• Підпорки автоматично створюють код та модель даних, та взаємодіють з ними через веб.
• Підпорти гарні для швидкого старту, але погані для розуміння.
• Rails використовує шаблон Model-View-Controller (MVC) для структурування веб застосувань.
• Інтерпретована Rails, REST архітектура включає стандартний набір URL та дій контролера для взаємодії з моделями даних.
• Rails підтримує валідацію даних, щоб надавати обмежень на значення атрибутів моделі даних.
• Rails іде з вбудованими функціями для визначення асоціацій між різними моделями даних.
• Ми можемо взаємодіяти з застосуваннями Rails з командного рядка з використанням консолі Rails.

3.2.1 Згенеровані статичні сторінки

Щоб почати зі статичними сторінками, ми зпочатку згенеруємо контролер, використовуючи той же скрипт Rails generate, що ми використовували в Главі 2 для генерації підпорок. Оскільки ми будемо робити для обробки статичних сторінок, ми назвемо його контролером статичних сторінок, що враховуючи домовленіст по іменуванню дасть ім'я StaticPages. Ми також плануємо зробити дії для Головної сторінки та сторінки Допомога та Про нас, тому створимо дії з іменами home, help та about. Скрипт generate приймає опціональний список дій, так що включимо дії для Головної та ДОпомоги прямо в командний рядок, тоді як навмисне залишимо дію для сторінки Про нас, так що ми зможемо побачити, як додавати її (Розділ 3.3). Отримана команда для генерації контролера статичних сторінок показана в Лістингу 3.4.

$ rails generate controller StaticPages home help
      create  app/controllers/static_pages_controller.rb
       route  get 'static_pages/help'
       route  get 'static_pages/home'
      invoke  erb
      create    app/views/static_pages
      create    app/views/static_pages/home.html.erb
      create    app/views/static_pages/help.html.erb
      invoke  test_unit
      create    test/controllers/static_pages_controller_test.rb
      invoke  helper
      create    app/helpers/static_pages_helper.rb
      invoke    test_unit
      create      test/helpers/static_pages_helper_test.rb
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/static_pages.js.coffee
      invoke    scss
      create      app/assets/stylesheets/static_pages.css.scss

By the way, it’s worth noting that rails g is a shortcut for rails generate, which is only one of several shortcuts supported by Rails (Table 3.1). For clarity, this tutorial always uses the full command, but in real life most Rails developers use one or more of the shortcuts shown in Table 3.1.

Before moving on, if you’re using Git it’s a good idea to add the files for the Static Pages controller to the remote repository:

$ git status
$ git add -A
$ git commit -m "Add a Static Pages controller"
$ git push -u origin static-pages

The final command here arranges to push the static-pages topic branch up to Bitbucket. Subsequent pushes can omit the other arguments and write simply

$ git push

The commit and push sequence above represents the kind of pattern I would ordinarily follow in real-life development, but for simplicity I’ll typically omit such intermediate commits from now on.

In Listing 3.4, note that we have passed the controller name as CamelCase, which leads to the creation of a controller file written in snake case, so that a controller called StaticPages yields a file called static_pages_controller.rb. This is merely a convention, and in fact using snake case at the command line also works: the command

$ rails generate controller static_pages ...

also generates a controller called static_pages_controller.rb. Because Ruby uses CamelCase for class names (Section 4.4), my preference is to refer to controllers using their CamelCase names, but this is a matter of taste. (Since Ruby filenames typically use snake case, the Rails generator converts CamelCase to snake case using the underscore method.)

By the way, if you ever make a mistake when generating code, it’s useful to know how to reverse the process. See Box 3.1 for some techniques on how to undo things in Rails.

  $ rails generate controller StaticPages home help
  $ rails destroy  controller StaticPages home help

  $ rails generate model User name:string email:string

  $ rails destroy model User

  $ bundle exec rake db:migrate

  $ bundle exec rake db:rollback

  $ bundle exec rake db:migrate VERSION=0

The Static Pages controller generation in Listing 3.4 automatically updates the routes file (config/routes.rb), which we saw briefly in Section 1.3.4. The routes file is responsible for implementing the router (seen in Figure 2.11) that defines the correspondence between URLs and web pages. The routes file is located in the config directory, where Rails collects files needed for the application configuration (Figure 3.1).

Figure 3.1: Contents of the sample app’s config directory.

Since we included the home and help actions in Listing 3.4, the routes file already has a rule for each one, as seen in Listing 3.5.

Rails.application.routes.draw do
  get 'static_pages/home'
  get 'static_pages/help'
  .
  .
  .
end

Here the rule

get 'static_pages/home'

maps requests for the URL /static_pages/home to the home action in the Static Pages controller. Moreover, by using get we arrange for the route to respond to a GET request, which is one of the fundamental HTTP verbs supported by the hypertext transfer protocol (Box 3.2). In our case, this means that when we generate a home action inside the Static Pages controller we automatically get a page at the address /static_pages/home. To see the result, start a Rails development server as described in Section 1.3.2:

$ rails server -b $IP -p $PORT    # Use only `rails server` if running locally

Then navigate to /static_pages/home (Figure 3.2).

Figure 3.2: The raw home view (/static_pages/home).

To understand where this page comes from, let’s start by taking a look at the Static Pages controller in a text editor, which should look something like Listing 3.6. You may note that, unlike the demo Users and Microposts controllers from Chapter 2, the Static Pages controller does not use the standard REST actions. This is normal for a collection of static pages: the REST architecture isn’t the best solution to every problem.

class StaticPagesController < ApplicationController

  def home
  end

  def help
  end
end

We see from the class keyword in Listing 3.6 that static_pages_controller.rb defines a class, in this case called StaticPagesController. Classes are simply a convenient way to organize functions (also called methods) like the home and help actions, which are defined using the def keyword. As discussed in Section 2.3.4, the angle bracket < indicates that StaticPagesController inherits from the Rails class ApplicationController; as we’ll see momentarily, this means that our pages come equipped with a large amount of Rails-specific functionality. (We’ll learn more about both classes and inheritance in Section 4.4.)

In the case of the Static Pages controller, both of its methods are initially empty:

def home
end

def help
end

In plain Ruby, these methods would simply do nothing. In Rails, the situation is different—StaticPagesController is a Ruby class, but because it inherits from ApplicationController the behavior of its methods is specific to Rails: when visiting the URL /static_pages/home, Rails looks in the Static Pages controller and executes the code in the home action, and then renders the view (the V in MVC from Section 1.3.3) corresponding to the action. In the present case, the home action is empty, so all visiting /static_pages/home does is render the view. So, what does a view look like, and how do we find it?

If you take another look at the output in Listing 3.4, you might be able to guess the correspondence between actions and views: an action like home has a corresponding view called home.html.erb. We’ll learn in Section 3.4 what the .erb part means; from the .html part you probably won’t be surprised that it basically looks like HTML (Listing 3.7).

<h1>StaticPages#home</h1>
<p>Find me in app/views/static_pages/home.html.erb</p>

The view for the help action is analogous (Listing 3.8).

<h1>StaticPages#help</h1>
<p>Find me in app/views/static_pages/help.html.erb</p>

Both of these views are just placeholders: they have a top-level heading (inside the h1 tag) and a paragraph (p tag) with the full path to the corresponding file.

3.2.2 Custom static pages

We’ll add some (very slightly) dynamic content starting in Section 3.4, but as they stand the views in Listing 3.7 and Listing 3.8 underscore an important point: Rails views can simply contain static HTML. This means we can begin customizing the Home and Help pages even with no knowledge of Rails, as shown in Listing 3.9 and Listing 3.10.

<h1>Sample App</h1>
<p>
  This is the home page for the
  <a href="http://www.railstutorial.org/">Ruby on Rails Tutorial</a>
  sample application.
</p>

<h1>Help</h1>
<p>
  Get help on the Ruby on Rails Tutorial at the
  <a href="http://www.railstutorial.org/#help">Rails Tutorial help section</a>.
  To get help on this sample app, see the
  <a href="http://www.railstutorial.org/book"><em>Ruby on Rails Tutorial</em>
  book</a>.
</p>

The results of Listing 3.9 and Listing 3.10 are shown in Figure 3.3 and Figure 3.4.

Figure 3.3: A custom Home page.

Figure 3.4: A custom Help page.

3.3.1 Our first test

Now it’s time to add an About page to our application. As we’ll see, the test is short and simple, so we’ll follow the guidelines from Box 3.3 and write the test first. We’ll then use the failing test to drive the writing of the application code.

Getting started with testing can be challenging, requiring extensive knowledge of both Rails and Ruby. At this early stage, writing tests might thus seem hopelessly intimidating. Luckily, Rails has already done the hardest part for us, because rails generate controller (Listing 3.4) automatically generated a test file to get us started:

$ ls test/controllers/
static_pages_controller_test.rb

Let’s take a look at it (Listing 3.11).

require 'test_helper'

class StaticPagesControllerTest < ActionController::TestCase

  test "should get home" do
    get :home
    assert_response :success
  end

  test "should get help" do
    get :help
    assert_response :success
  end
end

It’s not important at this point to understand the syntax in Listing 3.11 in detail, but we can see that there are two tests, one for each controller action we included on the command line in Listing 3.4. Each test simply gets an action and verifies (via an assertion) that the result is a success. Here the use of get indicates that our tests expect the Home and Help pages to be ordinary web pages, accessed using a GET request (Box 3.2). The response :success is an abstract representation of the underlying HTTP status code (in this case, 200 OK). In other words, a test like

test "should get home" do
  get :home
  assert_response :success
end

says “Let’s test the Home page by issuing a GET request to the home action and then making sure we receive a ‘success’ status code in response.”

To begin our testing cycle, we need to run our test suite to verify that the tests currently pass. We can do this with the rake utility (Box 2.1) as follows:⁷

$ bundle exec rake test
2 tests, 2 assertions, 0 failures, 0 errors, 0 skips

As required, initially our test suite is passing (green). (You won’t actually see the color green unless you add MiniTest reporters in the optional Section 3.7.1.) By the way, the tests take some time to start, which is due to two factors: (1) starting the Spring server to preload parts of the Rails environment, which only happens the first time; and (2) overhead associated with Ruby startup time. (The second factor is ameliorated when using Guard as suggested in Section 3.7.3.)

3.3.2 Red

As noted in Box 3.3, test-driven development involves writing a failing test first, writing the application code needed to get it to pass, and then refactoring the code if necessary. Because many testing tools represent failing tests with the color red and passing tests with the color green, this sequence is sometimes known as the “Red, Green, Refactor” cycle. In this section, we’ll complete the first step in this cycle, getting to red by writing a failing test. Then we’ll get to green in Section 3.3.3, and refactor in Section 3.4.3.⁸

Our first step is to write a failing test for the About page. Following the models from Listing 3.11, you can probably guess the right test, which is shown in Listing 3.13.

require 'test_helper'

class StaticPagesControllerTest < ActionController::TestCase

  test "should get home" do
    get :home
    assert_response :success
  end

  test "should get help" do
    get :help
    assert_response :success
  end

  test "should get about" do
    get :about
    assert_response :success
  end
end

We see from the highlighted lines in Listing 3.13 that the test for the About page is the same as the Home and Help tests with the word “about” in place of “home” or “help”.

As required, the test initially fails:

$ bundle exec rake test
3 tests, 2 assertions, 0 failures, 1 errors, 0 skips

3.3.3 Green

Now that we have a failing test (red), we’ll use the failing test’s error messages to guide us to a passing test (green), thereby implementing a working About page.

We can get started by examining the error message output by the failing test:⁹

$ bundle exec rake test
ActionController::UrlGenerationError:
No route matches {:action=>"about", :controller=>"static_pages"}

The error message here says that no route matches the desired action/controller combination, which is a hint that we need to add a line to the routes file. We can accomplish this by following the pattern in Listing 3.5, as shown in Listing 3.16.

Rails.application.routes.draw do
  get 'static_pages/home'
  get 'static_pages/help'
  get 'static_pages/about'
  .
  .
  .
end

The highlighted line in Listing 3.16 tells Rails to route a GET request for the URL /static_pages/about to the about action in the Static Pages controller.

Running our test suite again, we see that it is still red, but now the error message has changed:

$ bundle exec rake test
AbstractController::ActionNotFound:
The action 'about' could not be found for StaticPagesController

The error message now indicates a missing about action in the Static Pages controller, which we can add by following the model provided by home and help in Listing 3.6, as shown in Listing 3.18.

class StaticPagesController < ApplicationController

  def home
  end

  def help
  end

  def about
  end
end

As before, our test suite is still red, but the error message has changed again:

$ bundle exec rake test
ActionView::MissingTemplate: Missing template static_pages/about

This indicates a missing template, which in the context of Rails is essentially the same thing as a view. As described in Section 3.2.1, an action called home is associated with a view called home.html.erb located in the app/views/static_pages directory, which means that we need to create a new file called about.html.erb in the same directory.

The way to create a file varies by system setup, but most text editors will let you control-click inside the directory where you want to create the file to bring up a menu with a “New File” menu item. Alternately, you can use the File menu to create a new file and then pick the proper directory when saving it. Finally, you can use my favorite trick by applying the Unix touch command as follows:

$ touch app/views/static_pages/about.html.erb

Although touch is designed to update the modification timestamp of a file or directory without otherwise affecting it, as a side-effect it creates a new (blank) file if one doesn’t already exist. (If using the cloud IDE, you may have to refresh the file tree as described in Section 1.3.1.)

Once you’ve created the about.html.erb file in the right directory, you should fill it with the contents shown in Listing 3.19.

<h1>About</h1>
<p>
  The <a href="http://www.railstutorial.org/"><em>Ruby on Rails
  Tutorial</em></a> is a
  <a href="http://www.railstutorial.org/book">book</a> and
  <a href="http://screencasts.railstutorial.org/">screencast series</a>
  to teach web development with
  <a href="http://rubyonrails.org/">Ruby on Rails</a>.
  This is the sample application for the tutorial.
</p>

At this point, running rake test should get us back to green:

$ bundle exec rake test
3 tests, 3 assertions, 0 failures, 0 errors, 0 skips

Of course, it’s never a bad idea to take a look at the page in a browser to make sure our tests aren’t completely crazy (Figure 3.5).

Figure 3.5: The new About page (/static_pages/about).

3.3.4 Refactor

Now that we’ve gotten to green, we are free to refactor our code with confidence. When developing an application, often code will start to “smell”, meaning that it gets ugly, bloated, or filled with repetition. The computer doesn’t care what the code looks like, of course, but humans do, so it is important to keep the code base clean by refactoring frequently. Although our sample app is a little too small to refactor right now, code smell seeps in at every crack, and we’ll get started refactoring in Section 3.4.3.

3.4.1 Testing titles (Red)

To add page titles, we need to learn (or review) the structure of a typical web page, which takes the form shown in Listing 3.21.

<!DOCTYPE html>
<html>
  <head>
    <title>Greeting</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

The structure in Listing 3.21 includes a document type, or doctype, declaration at the top to tell browsers which version of HTML we’re using (in this case, HTML5);¹⁰ a head section, in this case with “Greeting” inside a title tag; and a body section, in this case with “Hello, world!” inside a p (paragraph) tag. (The indentation is optional—HTML is not sensitive to whitespace, and ignores both tabs and spaces—but it makes the document’s structure easier to see.)

We’ll write simple tests for each of the titles in Table 3.2 by combining the tests in Listing 3.13 with the assert_select method, which lets us test for the presence of a particular HTML tag (sometimes called a “selector”, hence the name):¹¹

assert_select "title", "Home | Ruby on Rails Tutorial Sample App"

In particular, the code above checks for the presence of a <title> tag containing the string “Home | Ruby on Rails Tutorial Sample App”. Applying this idea to all three static pages gives the tests shown in Listing 3.22.

require 'test_helper'

class StaticPagesControllerTest < ActionController::TestCase

  test "should get home" do
    get :home
    assert_response :success
    assert_select "title", "Home | Ruby on Rails Tutorial Sample App"
  end

  test "should get help" do
    get :help
    assert_response :success
    assert_select "title", "Help | Ruby on Rails Tutorial Sample App"
  end

  test "should get about" do
    get :about
    assert_response :success
    assert_select "title", "About | Ruby on Rails Tutorial Sample App"
  end
end

(If the repetition of the base title “Ruby on Rails Tutorial Sample App” bothers you, see the Вправи in Section 3.6.)

With the tests from Listing 3.22 in place, you should verify that the test suite is currently red:

$ bundle exec rake test
3 tests, 6 assertions, 3 failures, 0 errors, 0 skips

3.4.2 Adding page titles (Green)

Now we’ll add a title to each page, getting the tests from Section 3.4.1 to pass in the process. Applying the basic HTML structure from Listing 3.21 to the custom Home page from Listing 3.9 yields Listing 3.24.

<!DOCTYPE html>
<html>
  <head>
    <title>Home | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>Sample App</h1>
    <p>
      This is the home page for the
      <a href="http://www.railstutorial.org/">Ruby on Rails Tutorial</a>
      sample application.
    </p>
  </body>
</html>

The corresponding web page appears in Figure 3.6.¹²

Figure 3.6: The Home page with a title.

Following this model for the Help page (Listing 3.10) and the About page (Listing 3.19) yields the code in Listing 3.25 and Listing 3.26.

<!DOCTYPE html>
<html>
  <head>
    <title>Help | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>Help</h1>
    <p>
      Get help on the Ruby on Rails Tutorial at the
      <a href="http://www.railstutorial.org/#help">Rails Tutorial help
      section</a>.
      To get help on this sample app, see the
      <a href="http://www.railstutorial.org/book"><em>Ruby on Rails
      Tutorial</em> book</a>.
    </p>
  </body>
</html>

<!DOCTYPE html>
<html>
  <head>
    <title>About | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>About</h1>
    <p>
      The <a href="http://www.railstutorial.org/"><em>Ruby on Rails
      Tutorial</em></a> is a
      <a href="http://www.railstutorial.org/book">book</a> and
      <a href="http://screencasts.railstutorial.org/">screencast series</a>
      to teach web development with
      <a href="http://rubyonrails.org/">Ruby on Rails</a>.
      This is the sample application for the tutorial.
    </p>
  </body>
</html>

At this point, the test suite should be back to green:

$ bundle exec rake test
3 tests, 6 assertions, 0 failures, 0 errors, 0 skips

3.4.3 Layouts and embedded Ruby (Refactor)

We’ve achieved a lot already in this section, generating three valid pages using Rails controllers and actions, but they are purely static HTML and hence don’t show off the power of Rails. Moreover, they suffer from terrible duplication:

• The page titles are almost (but not quite) exactly the same.
• “Ruby on Rails Tutorial Sample App” is common to all three titles.
• The entire HTML skeleton structure is repeated on each page.

This repeated code is a violation of the important “Don’t Repeat Yourself” (DRY) principle; in this section we’ll “DRY out our code” by removing the repetition. At the end, we’ll re-run the tests from Section 3.4.2 to verify that the titles are still correct.

Paradoxically, we’ll take the first step toward eliminating duplication by first adding some more: we’ll make the titles of the pages, which are currently quite similar, match exactly. This will make it much simpler to remove all the repetition at a stroke.

The technique involves using embedded Ruby in our views. Since the Home, Help, and About page titles have a variable component, we’ll use a special Rails function called provide to set a different title on each page. We can see how this works by replacing the literal title “Home” in the home.html.erb view with the code in Listing 3.28.

<% provide(:title, "Home") %>
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>Sample App</h1>
    <p>
      This is the home page for the
      <a href="http://www.railstutorial.org/">Ruby on Rails Tutorial</a>
      sample application.
    </p>
  </body>
</html>

Listing 3.28 is our first example of embedded Ruby, also called ERb. (Now you know why HTML views have the file extension .html.erb.) ERb is the primary template system for including dynamic content in web pages.¹³ The code

<% provide(:title, "Home") %>

indicates using <% ... %> that Rails should call the provide function and associate the string "Home" with the label :title.¹⁴ Then, in the title, we use the closely related notation <%= ... %> to insert the title into the template using Ruby’s yield function:¹⁵

<title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>

(The distinction between the two types of embedded Ruby is that <% ... %> executes the code inside, while <%= ... %> executes it and inserts the result into the template.) The resulting page is exactly the same as before, only now the variable part of the title is generated dynamically by ERb.

We can verify that all this works by running the tests from Section 3.4.2 and see that they are still green:

$ bundle exec rake test
3 tests, 6 assertions, 0 failures, 0 errors, 0 skips

Then we can make the corresponding replacements for the Help and About pages (Listing 3.30 and Listing 3.31).

<% provide(:title, "Help") %>
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>Help</h1>
    <p>
      Get help on the Ruby on Rails Tutorial at the
      <a href="http://www.railstutorial.org/#help">Rails Tutorial help
      section</a>.
      To get help on this sample app, see the
      <a href="http://www.railstutorial.org/book"><em>Ruby on Rails
      Tutorial</em> book</a>.
    </p>
  </body>
</html>

<% provide(:title, "About") %>
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    <h1>About</h1>
    <p>
      The <a href="http://www.railstutorial.org/"><em>Ruby on Rails
      Tutorial</em></a> is a
      <a href="http://www.railstutorial.org/book">book</a> and
      <a href="http://screencasts.railstutorial.org/">screencast series</a>
      to teach web development with
      <a href="http://rubyonrails.org/">Ruby on Rails</a>.
      This is the sample application for the tutorial.
    </p>
  </body>
</html>

Now that we’ve replaced the variable part of the page titles with ERb, each of our pages looks something like this:

<% provide(:title, "The Title") %>
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    Contents
  </body>
</html>

In other words, all the pages are identical in structure, including the contents of the title tag, with the sole exception of the material inside the body tag.

In order to factor out this common structure, Rails comes with a special layout file called application.html.erb, which we renamed in the beginning of this section (Section 3.4) and which we’ll now restore:

$ mv layout_file app/views/layouts/application.html.erb

To get the layout to work, we have to replace the default title with the embedded Ruby from the examples above:

<title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>

The resulting layout appears in Listing 3.32.

<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
    <%= stylesheet_link_tag    'application', media: 'all',
                                              'data-turbolinks-track' => true %>
    <%= javascript_include_tag 'application', 'data-turbolinks-track' => true %>
    <%= csrf_meta_tags %>
  </head>
  <body>
    <%= yield %>
  </body>
</html>

Note here the special line

<%= yield %>

This code is responsible for inserting the contents of each page into the layout. It’s not important to know exactly how this works; what matters is that using this layout ensures that, for example, visiting the page /static_pages/home converts the contents of home.html.erb to HTML and then inserts it in place of <%= yield %>.

It’s also worth noting that the default Rails layout includes several additional lines:

<%= stylesheet_link_tag ... %>
<%= javascript_include_tag "application", ... %>
<%= csrf_meta_tags %>

This code arranges to include the application stylesheet and JavaScript, which are part of the asset pipeline (Section 5.2.1), together with the Rails method csrf_meta_tags, which prevents cross-site request forgery (CSRF), a type of malicious web attack.

Of course, the views in Listing 3.28, Listing 3.30, and Listing 3.31 are still filled with all the HTML structure included in the layout, so we have to remove it, leaving only the interior contents. The resulting cleaned-up views appear in Listing 3.33, Listing 3.34, and Listing 3.35.

<% provide(:title, "Home") %>
<h1>Sample App</h1>
<p>
  This is the home page for the
  <a href="http://www.railstutorial.org/">Ruby on Rails Tutorial</a>
  sample application.
</p>

<% provide(:title, "Help") %>
<h1>Help</h1>
<p>
  Get help on the Ruby on Rails Tutorial at the
  <a href="http://www.railstutorial.org/#help">Rails Tutorial help section</a>.
  To get help on this sample app, see the
  <a href="http://www.railstutorial.org/book"><em>Ruby on Rails Tutorial</em>
  book</a>.
</p>

<% provide(:title, "About") %>
<h1>About</h1>
<p>
  The <a href="http://www.railstutorial.org/"><em>Ruby on Rails
  Tutorial</em></a> is a
  <a href="http://www.railstutorial.org/book">book</a> and
  <a href="http://screencasts.railstutorial.org/">screencast series</a>
  to teach web development with
  <a href="http://rubyonrails.org/">Ruby on Rails</a>.
  This is the sample application for the tutorial.
</p>

With these views defined, the Home, Help, and About pages are the same as before, but they have much less duplication.

Experience shows that even fairly simple refactoring is error-prone and can easily go awry. This is one reason why having a good test suite is so valuable. Rather than double-checking every page for correctness—a procedure that isn’t too hard early on but rapidly becomes unwieldy as an application grows—we can simply verify that the test suite is still green:

$ bundle exec rake test
3 tests, 6 assertions, 0 failures, 0 errors, 0 skips

This isn’t a proof that our code is still correct, but it greatly increases the probability, thereby providing a safety net to protect us against future bugs.

3.4.4 Setting the root route

Now that we’ve customized our site’s pages and gotten a good start on the test suite, let’s set the application’s root route before moving on. As in Section 1.3.4 and Section 2.2.2, this involves editing the routes.rb file to connect / to a page of our choice, which in this case will be the Home page. (At this point, I also recommend removing the hello action from the Application controller if you added it in Section 3.1.) As shown in Listing 3.37, this means replacing the generated get rule from Listing 3.5 with the following code:

root 'static_pages#home'

This changes the URL static_pages/home to the controller/action pair static_pages#home, which ensures that GET requests for / get routed to the home action in the Static Pages controller. The resulting routes file is shown in Figure 3.7. (Note that, with the code in Listing 3.37, the previous route static_pages/home will no longer work.)

Rails.application.routes.draw do
  root 'static_pages#home'
  get  'static_pages/help'
  get  'static_pages/about'
end

Figure 3.7: The Home page at the root route.

3.5.1 Що ми вивчили в цій главі

• For a third time, we went through the full procedure of creating a new Rails application from scratch, installing the necessary gems, pushing it up to a remote repository, and deploying it to production.
• The rails script generates a new controller with rails generate controller ControllerName <optional action names>.
• New routes are defined in the file config/routes.rb.
• Rails views can contain static HTML or embedded Ruby (ERb).
• Automated testing allows us to write test suites that drive the development of new features, allow for confident refactoring, and catch regressions.
• Test-driven development uses a “Red, Green, Refactor” cycle.
• Rails layouts allow the use of a common template for pages in our application, thereby eliminating duplication.

3.7.1 MiniTest reporters

To get the default Rails tests to show red and green at the appropriate times, I recommend adding the code in Listing 3.40 to your test helper file,¹⁸ thereby making use of the minitest-reporters gem included in Listing 3.2.

ENV['RAILS_ENV'] ||= 'test'
require File.expand_path('../../config/environment', __FILE__)
require 'rails/test_help'
require "minitest/reporters"
Minitest::Reporters.use!

class ActiveSupport::TestCase
  # Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical
  # order.
  fixtures :all

  # Add more helper methods to be used by all tests here...
end

The resulting transition from red to green in the cloud IDE appears as in Figure 3.8.

Figure 3.8: Going from red to green in the cloud IDE.