От нуля к развертыванию

Первое приложение

Практически все приложения Rails начинают одинаково - с команды rails new. Эта удобная команда создает скелет приложения Rails в любом каталоге на ваш вкус. Для начала создайте каталог для своих Rails-проектов, а затем выполните команду rails new, чтобы создать первое приложение (Листинг 1.3):

$ mkdir rails_projects
$ cd rails_projects
$ rails new first_app
      create
      create  README.rdoc
      create  Rakefile
      create  config.ru
      create  .gitignore
      create  Gemfile
      create  app
      create  app/assets/javascripts/application.js
      create  app/assets/stylesheets/application.css
      create  app/controllers/application_controller.rb
      .
      .
      .
      create  test/test_helper.rb
      create  tmp/cache
      create  tmp/cache/assets
      create  vendor/assets/javascripts
      create  vendor/assets/javascripts/.keep
      create  vendor/assets/stylesheets
      create  vendor/assets/stylesheets/.keep
         run  bundle install
.
.
.
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled
gem is installed.

Как видно в конце Листинга 1.3, запуск rails new автоматически выполняет команду bundle install после завершения создания файлов. Если этот шаг сейчас не сработал, не переживайте; следуйте шагам в Разделе 1.2.4 и у вас почти наверняка все получится.

Отметьте, сколько файлов и каталогов создает команда rails new. Эта стандартная структура файлов и каталогов (Рис. 1.2) является одним из многих преимуществ Rails; это немедленно переносит вас от нуля к действующему (минимально) приложению. Кроме того, так как эта структура является общей для всех приложений Rails, можно сразу сориентироваться, глядя на чей-либо код. Обзор дефолтных Rails файлов представлен в Таблице 1.1; мы узнаем о большинстве этих файлов и каталогов в остальной части этой книги. В частности в Разделе 5.2.1 мы обсудим директорию app/assets, являющуюся частью asset pipeline(# далее по тексту - "файлопровод") который значительно упрощает организацию и разворачивание активно используемых файлов (assets), таких как каскадные таблицы стилей и JavaScript файлы.

Bundler

После создания нового Rails приложения следующий шаг – использование Bundler для установки и включения гемов, необходимых приложению. Как было вкратце отмечено в Разделе 1.2.3, Bundler запускается автоматически (через bundle install) командой rails, но в этом разделе мы немного изменим дефолтные гемы приложения и вновь запустим Bundler. Что подразумевает открытие Gemfile в вашем любимом текстовом редакторе:

$ cd first_app/
$ subl Gemfile

Результат должен выглядеть примерно как Листинг 1.4. Код в этом файле это Ruby, но не обращайте сейчас внимания на синтаксис; Глава 4 расскажет о Ruby более подробно.

source 'https://rubygems.org'

# Use sqlite3 as the database for Active Record
gem 'sqlite3'

# Use SCSS for stylesheets
gem 'sass-rails', '~> 4.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', '~> 1.0.1'

group :doc do
  # bundle exec rake doc:rails generates the API under doc/api.
  gem 'sdoc', require: false
end

# Use ActiveModel has_secure_password
# gem 'bcrypt-ruby', '~> 3.1.2'

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

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

# Use debugger
# gem 'debugger', group: [:development, :test]

Большинство этих строк закомментированы хеш символом #; они здесь для того, чтобы показать вам некоторые обычно необходимые гемы и дать примеры синтаксиса Bundler. Сейчас нам не понадобятся никакие гемы кроме дефолтных.

Если вы не укажете номер версии gem-команде, Bundler автоматически установит самую последнюю версию. К сожалению, обновления гемов часто вызывают незначительные, но сбивающие с толку поломки, так что в этом учебнике мы будем явно прописывать номер версии известной как работавшей, как это показано в Листинге 1.5 (в котором также пропущены закомментированные строки из Листинга 1.4).

source 'https://rubygems.org'
ruby '2.0.0'
#ruby-gemset=railstutorial_rails_4_0

gem 'rails', '4.0.2'

group :development do
  gem 'sqlite3', '1.3.8'
end

gem 'sass-rails', '4.0.1'
gem 'uglifier', '2.1.1'
gem 'coffee-rails', '4.0.1'
gem 'jquery-rails', '3.0.4'
gem 'turbolinks', '1.1.1'
gem 'jbuilder', '1.0.2'

group :doc do
  gem 'sdoc', '0.3.20', require: false
end

Листинг 1.5 добавляет строки

ruby '2.0.0'
#ruby-gemset=railstutorial_rails_4_0

указывающие версию Ruby ожидаемую приложением (особенно полезно при развертывании приложения (Раздел 1.4)), наряду с гемсетом RVM (Раздел 1.2.2.3). Поскольку строка гемсета начинается с #, который является комментирующим символом в Ruby, она будет проигнорирована если вы не используете RVM, в противном случае RVM будет использовать правильную комбинацию Ruby/гемсета при переходе в директорию приложения. (Если вы используете версию Ruby отличную от 2.0.0, вам следует соответствующим образом изменить строку с версией Ruby.)

Обновленный Gemfile также меняет строку для jQuery, дефолтной JavaScript библиотеки используемой Рельсами, с

gem 'jquery-rails'

на

gem 'jquery-rails', '3.0.4'

Мы также заменили

gem 'sqlite3'

на

group :development do
  gem 'sqlite3', '1.3.8'
end

что вынуждает Bundler установить 1.3.8 версию гема sqlite3. Отметьте что мы также, пользуясь случаем, предписали использовать этот гем только в среде разработки (Раздел 7.1.1), что предотвратит потенциальные конфликты с базой данных используемой Heroku (Раздел 1.4).

Листинг 1.5 также изменяет несколько других строк, преобразуя

# Use SCSS for stylesheets
gem 'sass-rails', '~> 4.0.0'

# Use Uglifier as compressor for JavaScript assets
gem 'uglifier', '>= 1.3.0'

# Use CoffeeScript for .js.coffee assets and views
gem 'coffee-rails', '~> 4.0.0'

в

gem 'sass-rails',   '4.0.1'
gem 'uglifier', '2.1.1'
gem 'coffee-rails', '4.0.1'

Синтаксис

gem 'uglifier', '>= 1.3.0'

устанавливает последнюю версию гема uglifier (который занимается сжатием файлов для файлопровода) даже если его последняя версия значительно отличается от 1.3.0 — даже если это, скажем, версия 7.2. Тем временем, код

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

устанавливает гем coffee-rails (также необходимый для файлопровода) с версией не старее чем 4.0.0, но не новее чем 4.1. Другими словами, >= нотация всегда позволяет обновления, в то время как нотация ~> позволяет лишь незначительные обновления (например, с 4.0.0 до 4.0.1), но не позволяет значительных обновлений (например, с 4.0 до 4.1). К сожалению, практика показывает, что даже минорные релизы гемов могут привести к поломкам, так что для Rails Tutorial мы будем ошибаться в пользу осторожности, явно прописывая конкретную версию для, практически, всех гемов. Вы можете использовать самую последнюю версию любого гема, что подразумевает использование конструкции ~> в Gemfile (что я рекомендую в основном более продвинутым пользователям), но предупреждаю что это может привести к совершенно непредсказуемому поведению кода учебника.

После того как вы составили надлежащий Gemfile, установите гемы с помощью Этот шаг необходим только в случае если вы меняли версию гема Rails (например из-за использования Rails Installer), во всех остальных случаях этот шаг необязателен, но и не опасен. и bundle install:

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

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

rails server

Благодаря запуску rails new в Разделе 1.2.3 и bundle install в Разделе 1.2.4, у нас уже есть приложение, которое мы можем запустить — но как? К счастью, Rails поставляется с программой командной строки, или скриптом, который запускает локальный веб-сервер, видимый только на вашей рабочей машине:

$ rails server
=> Booting WEBrick
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server

(Если ваша система жалуется на отсутствие JavaScript runtime, посетите https://github.com/sstephenson/execjs по адресу на Рис. 1.3 .

Чтобы увидеть информацию о нашем первом приложении, кликните по ссылке "About your application’s environment". Результат показан на Рис. 1.4 (Рис. 1.4 представляет рабочее окружение на моей машине когда я делал скриншот; ваши результаты могут отличаться.)

Очевидно, что, в конечном итоге, дефолтная страница Rails нам не нужна, но сейчас приятно видеть ее работающей. Мы удалим эту дефолтную страницу (и заменим ее собственной домашней страницей) в Разделе 5.3.2.

Модель-представление-контроллер (MVC)

Даже на этой ранней стадии, полезно получить общее представление о том, как работают Rails-приложения (Рис. 1.5). Вы, возможно, заметили, что в стандартной структуре Rails приложения (Рис. 1.2) есть папка с названием app/ содержащая в себе три подкаталога: models, views, и controllers. Это намек на то, что Rails следует архитектурной схеме модель-представление-контроллер (MVC), которая осуществляет разделение между "логикой предметной области" (также называемой "бизнес-логикой") от логики ввода и логики представления, связанной с графическим интерфейсом пользователя (GUI). В случае веб-приложений, "логика предметной области" обычно состоит из модели данных для таких вещей как пользователи, статьи, продукты, а GUI это просто веб-страница в браузере.

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

Если это обсуждение сейчас кажется вам немного абстрактным, не беспокойтесь; мы будем часто возвращаться к этому разделу. В дополнение, в Разделе 2.2.2 есть более детальное обсуждение MVC в контексте демонстрационного приложения. Наконец, пример приложения будет использовать все аспекты MVC; мы осветим контроллеры и представления, в Разделе 3.1, модели начнутся в Разделе 6.1 и мы увидим, совместную работу триады в Разделе 7.1.2.

Управление версиями с Git

Теперь, когда у нас есть новое и рабочее приложение Rails, мы займем одну минуту для шага, который, хотя технически необязателен, видится многим разработчиками Rails как фактически обязательный, а именно, помещение исходного кода нашего приложения в систему управление версиями. Системы управления версиями позволяют нам отслеживать изменения кода нашего проекта, облегчают совместную работу, и могут откатывать любые непреднамеренные погрешности (такие как случайное удаление файлов). Грамотное использование системы управления версиями - необходимый навык для каждого разработчика программного обеспечения.

Есть много возможностей для управления версиями, но сообщество Rails в значительной степени стандартизировано под Git, распределенную систему управления версиями, первоначально разработанную Линусом Торвальдсом (Linus Torvalds), для размещения ядра Linux. Git – большая тема, и мы лишь слегка коснемся ее в этой книге, но есть много хороших бесплатных онлайн ресурсов; я особенно рекомендую Pro Git автора Scott Chacon (Apress, 2009). Помещение вашего исходного кода в систему управления версиями с Git строго рекомендуется, не только потому, что это почти универсальная практика в мире Rails, но также и потому что это позволит вам легко открыть доступ к вашему коду (Раздел 1.3.4) и развернуть ваше приложение прямо здесь в первой главе (Раздел 1.4).

Установка и настройка

Первый шаг это установка Git, если вы еще не выполнили шаги в Разделе 1.2.2.2. (Как отмечено в том разделе, это подразумевает следование инструкциям в Installing Git разделе Pro Git.)

Первоначальная настройка системы

После установки Git следует выполнить ряд разовых настроек. Это системные настройки, что означает, что их необходимо сделать лишь единожды:

$ git config --global user.name "Your Name"
$ git config --global user.email your.email@example.com

Мне также нравится использовать co вместо более громоздкой checkout команды, мы можем сделать это следующим образом:

$ git config --global alias.co checkout

Этот учебник будет обычно использовать полную checkout команду, которая работает на системах не имеющих co конфигурации, но в реальной жизни я почти всегда использую git co.

В качестве финального шага установки, можно дополнительно установить редактор который Git будет использовать для сообщений о фиксации (коммите). Если вы используете графический, такой как Sublime Text, TextMate, gVim, или MacVim, вы должны использовать флаг, чтобы быть уверенным, что редактор остается присоединенным к оболочке вместо того, чтобы отсоединиться сразу:Обычно это настройка, позволяющая вам продолжать использовать командную строку после запуска вашего редактора, но Git интерпретирует отсоединение как закрытие файла с пустым сообщением о фиксации, которое препятствует тому, чтобы фиксация произошла. Я упоминаю этот момент, только потому что это может серьезно сбить с толку, если вы пытаетесь настроить свой редактор subl или gvim без флага. Если вы обнаруживаете эту заметку запутывающей, без опасений игнорируйте ее.

$ git config --global core.editor "subl -w"

Замените "subl -w" на "mate -w" для TextMate, "gvim -f" для gVim, или "mvim -f" для MacVim.

Первоначальная настройка репозитория

Теперь мы подошли к нескольким шагам, которые будут необходимы каждый раз, когда вы создаете новый репозиторий. Сначала перейдите в корневой каталог первого приложения и инициализируйте новый репозиторий:

$ git init
Initialized empty Git repository in /Users/mhartl/rails_projects/first_app/.git/

Следующий шаг добавит файлы проекта в репозиторий. Есть незначительная сложность: Git по умолчанию отслеживает изменения всех файлов, но есть несколько файлов, которые мы не хотели бы отслеживать. Например, Rails создает log файлы, для записи поведения приложения; эти файлы часто изменяются, и мы не хотим, чтобы наша система управления версиями постоянно обновляла их. у Git есть простой механизм, чтобы игнорировать такие файлы: просто включите файл, названный Если вы не видите файла .gitignore в вашей директории, возможно вам нужно сконфигурировать ваш просмотрщик директорий для отображения скрытых файлов..

Посмотрев снова в Таблицу 1.1, мы увидим, что команда rails создает дефолтный .gitignore файл в корневом каталоге Rails, как показано в Листинге 1.6.

# See http://help.github.com/ignore-files/ for more about ignoring files.
#
# Если вам часто приходится игнорировать временные файлы
# генерирумые вашим текстовым редактором
# или операционной системой, то вам, возможно, захочется
# добавить правило для глобального игнорирования:
#   git config --global core.excludesfile '~/.gitignore_global'

# Игнорирование конфигурации bundler.
/.bundle

# Игнорирование дефолтной базы данных SQLite.
/db/*.sqlite3
/db/*.sqlite3-journal

# Игнорирование всех логов и временных файлов.
/log/*.log
/tmp

Листинг 1.6 заставляет Git игнорировать такие файлы как файлы логов, временные Rails (tmp) файлы, и файлы базы данных SQLite. (Например, чтобы игнорировать файлы логов, которые живут в log/ каталоге, мы используем log/*.log чтобы игнорировать все файлы, заканчивающиеся на .log.) Большинство этих игнорируемых файлов изменяются часто и автоматически, так что включать их в управление версиями нет необходимости; кроме того, при совместной разработке такие малозначимые изменения могут вызвать конфликты.

Файл .gitignore в Листинге 1.6 вполне хорош для начала, но для бОльшего удобства и безопасности (Листинг 3.2 лекции 3), я рекомендую использовать вместо него Листинг 1.7. Этот увеличенный .gitignore обеспечивает игнорирование файлов документации Rails, файлов подкачки Vim и Emacs, и (для пользователей OS X) странные .DS_Store каталоги, создаваемые приложением Mac Finder. Если вы хотите использовать этот более широкий набор игнорируемых файлов, откройте .gitignore в вашем любимом текстовом редакторе и наполните его содержимым Листинга 1.7.

# Игнорирование конфига bundler
/.bundle

# Игнорирование дефолтной базы данных SQLite.
/db/*.sqlite3
/db/*.sqlite3-journal

# Игнорирование всех логов и временных файлов.
/log/*.log
/tmp

# Игнорирование прочих ненужных файлов.
database.yml
doc/
*.swp
*~
.project
.DS_Store
.idea
.secret

Добавление и фиксация

Наконец, мы добавим файлы вашего нового проекта Rails к Git, а затем зафиксируем (закоммитим) результаты. Можно добавить все файлы (кроме тех, которые соответствуют правилам игнорирования в .gitignore) следующим образом:

$ git add .

Здесь точка ‘.’ представляет текущий каталог, и Git достаточно умен, чтобы добавить файлы рекурсивно, таким образом, это автоматически включает все подкаталоги. Эта команда добавляет файлы проекта в зону ожидания, которая содержит незавершенные изменения вашего проекта; можно видеть, какие файлы находятся в зоне ожидания, используя команду Если в будущем какие-либо нежелательные файлы начинают показываться после выполнения команды git status, просто добавьте их в свой .gitignore файл из Листинга 1.7.

$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   README.rdoc
#       new file:   Rakefile
.
.
.

(Результат длинный, и я применил вертикальные точки, чтобы обозначить пропущенный вывод.)

Для того, чтобы сказать Git, что вы хотите сохранить изменения, используйте команду commit:

$ git commit -m "Initialize repository"
[master (root-commit) df0a62f] Initialize repository
42 files changed, 8461 insertions(+), 0 deletions(-)
create mode 100644 README.rdoc
create mode 100644 Rakefile
.
.
.

Метка -m позволяет вам добавлять сообщение для фиксации; если вы пропустите -m, то Git откроет редактор, который вы установили в Разделе 1.3.1 и предложит ввести сообщение в нем.

Важно отметить, что коммиты Git локальны, и записываются только на машине, на которой происходят коммиты. Что отличает его от популярной open-source системы управления версиями под названием Subversion, в которой коммит обязательно приводит к изменениям в удаленном репозитарии. Git делит коммит в стиле Subversion на два логических куска: локальная запись изменений (git commit) и отправка изменений в удаленный репозиторий (git push). Мы увидим пример отправки в Разделе 1.3.5.

Между прочим, вы можете увидеть список своих сообщений о коммитах, используя команду log:

$ git log
commit df0a62f3f091e53ffa799309b3e32c27b0b38eb4
Author: Michael Hartl <michael@michaelhartl.com>
Date:   Thu Oct 15 11:36:21 2009 -0700

  Initial commit

Чтобы выйти из git log, нажмите q.

Что хорошего Git делает для вас?

В этой точке, вероятно не совсем понятно, почему помещение вашего исходного кода в систему управления версиями полезно для вас, позвольте мне привести лишь один пример. (Мы увидим множество других в последующих главах.) Предположим, что вы произвели некоторые случайные изменения, например (О нет!) удалили критичный каталог app/controllers/:

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

Здесь мы используем Unix команду ls , чтобы увидеть содержимое каталога app/controllers/ и команду rm, чтобы удалить его. Флаг -rf (сокращение от "recursive force"), рекурсивно удаляет все файлы, каталоги, подкаталоги, и так далее, не запрашивая явного подтверждения для каждого стирания.

Давайте проверим состояние(статус), чтобы увидеть что произошло:

$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    app/controllers/application_controller.rb
#
no changes added to commit (use "git add" and/or "git commit -a")

Мы видим здесь, что файл был удален, но изменения находятся только на "рабочем дереве"; они еще не зафиксировались. Это означает, что мы все еще можем легко отменить изменения, получив из Git предыдущую фиксацию командой checkout (и -f флагом, чтобы инициировать перезапись текущих изменений):

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

Пропавшие каталог и файл вернулись. Какое облегчение!

GitHub

Теперь, когда ваш проект помещен в систему управления версиями, пришло время отправить ваш код на GitHub - веб-сервис для хостинга исходного кода проектов и их совместной разработки основанный на системе контроля версий Git. Отправка копии вашего git-репозитория на GitHub служит двум целям: полное резервное копирование вашего кода (включая полную историю коммитов) и он делает любое будущее сотрудничество намного более легким. Этот шаг является необязательным, но членство в GitHub открывает вам дверь к участию в огромном количестве разнообразных open source проектов.

У GitHub есть множество платных тарифных планов, но для открытого исходного кода их сервисы являются бесплатными, так что зарегистрируйтесь и создайте https://github.com/signup/free#. Щелкните создать репозиторий и заполните форму как на рис 1.7. (Не инициализируйте репозиторий с файлом README, так как rails new создает один из них автоматически.) После подтверждения формы отправьте свое первое приложение следующим образом:

$ git remote add origin https://github.com/<username>/first_app.git
$ git push -u origin master

Эти команды говорят Git, что вы хотите добавить GitHub как начальный адрес для вашей основной (master) ветки, а затем отправить ваш репозиторий на GitHub. (Не беспокойтесь о значении флага -u; если вам любопытно, поищите в сети "git set upstream".) Конечно, следует заменить <username> вашим фактическим именем пользователя. Например, команда которую запустил я:

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

Результатом является страница на GitHub для репозитория первого приложения (first application), с браузером файлов, полной историей коммитов, и большим количеством прочих няшек (рис 1.7).

У GitHub также есть нативные приложения для расширения интерфейса командной строки, так что если вы более комфортно себя чувствуете с GUI приложениями, то вам, возможно, понравится GitHub для Windows или GitHub для Mac. (похоже что GitHub для Linux это по-прежнему просто Git.)

Ветвление, редактирование, фиксация, объединение

Если вы следовали за шагами в Разделе 1.3.4, вы могли заметить, что GitHub автоматически показывает содержание файла README на основной странице репозитория. В нашем случае, так как проект сгенерирован с использованием команды ). Благодаря расширению файла .rdoc, GitHub знает что он имеет правильный формат, но его содержимое совершенно бесполезно, так что в этом разделе мы сделаем наше первое редактирование, изменив README с тем чтобы он описывал наш проект, а не фреймворк на котором он написан. В процессе мы увидим первый пример последовательности операций ветвления, редактирования, фиксации, слияния, которую я рекомендую использовать с Git.

Git невероятно хорош в создании веток, которые фактически являются копиями репозитория, где мы можем произвести (возможно экспериментальные) изменения, не модифицируя родительские файлы. В большинстве случаев родительский репозиторий – master ветка, и мы можем создать новую рабочую ветку используя checkout с флагом -b:

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

Здесь вторая команда, git branch, только перечисляет все локальные ветки, а звездочка * указывает, какая ветка в настоящий момент включена. Отметьте, что git checkout -b modify-README одновременно и создает новую ветку и переключает на нее, на что указывает звездочка перед modify-README веткой. (Если вы настроили алиас co в Разделе 1.3, можете использовать git co -b modify-README вместо этого.)

Полностью оценить достоинства ветвления можно только работая над проектом совместно с множеством разработчиков,См. главу Git Branching в Pro Git для получения более подробной информации. но ветки полезны даже для учебника единственного разработчика, такого как этот. В частности ветка master изолируется от любых изменений, которые мы производим в ветке посвященной определенной теме, так что даже если мы действительно наворотили лишнего, мы можем всегда отказаться от изменений, вернувшись в master ветку и удалив ветку в которой мы работали до этого. Мы увидим, как сделать это в конце раздела.

Между прочим, для изменений столь малых как это, обычно я бы не стал заморачиваться новой веткой, но никогда не бывает слишком рано, чтобы начать практиковать хорошие привычки.

Редактирование

После создания локальной ветки мы отредактируем его (файл readme), чтобы сделать немного более наглядным. Мне нравится использовать язык разметки Markdown для этих целей и если вы будете использовать расширение файла .markdown тогда GitHub будет автоматически форматировать его в приятный для вас вид. Итак, сначала мы будем использовать Git версию Unix команды mv ("move"), чтобы изменить название, а затем заполним его содержимым Листинга 1.8:

$ git mv README.rdoc README.md
$ subl README.md

# Ruby on Rails Tutorial: первое приложение

Это первое приложение для
[*Ruby on Rails Tutorial*](http://railstutorial.org/)
 [Майкл Хартл](http://michaelhartl.com/).

Фиксация

С произведенными изменениями мы можем посмотреть статус нашей ветки:

$ git status
# On branch modify-README
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       renamed:    README.rdoc -> README.md
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   README.md

В этой точке мы могли бы использовать git add . как в Разделе 1.3.2, но Git предусматривает флаг -a как сокращение для (очень частого) случая фиксации всех изменений к существующим файлам (или файлов, созданных с использованием git mv, которые не считаются новыми для Git):

$ 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

Будьте осторожны с использованием флага -a; если вы добавили какие-либо новые файлы в проект после последней фиксации, вы должны сообщить Git о них используя сначала git add.

Обратите внимание, что мы написали сообщение коммита в настоящем времени. Git моделирует коммиты как серии правок существующего кода и в этом контексте имеет смысл описать что каждый коммит делает, нежели что он делал. Кроме того, такое использование соответствует сообщениям о коммитах генерируемых самой командой Git. Более подробно об этом можно почитать из GitHub поста Shiny new commit styles.

Объединение

Теперь, когда мы закончили производить наши изменения, мы готовы объединить результаты с нашей master веткой:

$ 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 часто включает такие вещи как 34f06b7, которые связаны с внутренним представлением Git репозиториев. Ваши конкретные результаты будут отличаться в этих деталях, но остальное по своей сути должно соответствовать выводу, показанному выше.

После того, как вы объединили изменения, вы можете почистить свои ветки, стерев локальную ветку, используя git branch -d если вы с ней (веткой) закончили:

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

Этот шаг не является обязательным, и, фактически, это довольно распространено - оставлять рабочие ветки нетронутыми. Это позволяет переключаться между рабочей и master ветками, объединяя изменения каждый раз, когда вы достигаете естественной точки остановки.

Как упомянуто выше, вы также можете отказаться от изменений, относящихся к рабочей ветке, в таком случае используйте git branch -D:

# Только для иллюстрации; не делайте этого,
  если планируете в дальнейшем пользоваться веткой
$ git checkout -b topic-branch
$ <really screw up the branch>
$ git add .
$ git commit -a -m "Major screw up"
$ git checkout master
$ git branch -D topic-branch

В отличие от флага -d, флаг -D сотрет ветку даже если мы не объединили изменения.

Отправка

Теперь, когда мы обновили README, мы можем отправить изменения в GitHub чтобы увидеть результат. Так как мы уже сделали одну отправку (Раздел 1.3.4), на большинстве систем, мы теперь можем опустить origin master, и просто выполнить git push:

$ git push

Как и обещалось, GitHub приятно форматирует новый файл, используя Markdown (рис 1.9).

Развертывание

Даже на этой ранней стадии, мы уже собираемся развернуть наше (все еще пустое) приложение Rails в production (# -окружение используемое когда вы разворачиваете ваше приложение для всеобщего использования). Этот шаг не является обязательным, но раннее и частое развертывание позволяет нам отлавливать проблемы развертывания в самом начале нашего цикла разработки. Альтернативный вариант - развертывание только после напряженных усилий изолированных в окружении разработки (development environment) - часто приводит к ужасным головным болям при интегрировании, когда приходит время запуска. Хотя это и не должно иметь значения для примеров приложений в Учебнике Rails, если вы волнуетесь по поводу случайного и/или преждевременного обнародования вашего приложения, есть несколько способов, которые могут помочь вам избежать этого; Один из них описан в Разделе 1.4.4.

Раньше развертывание Rails-приложений было довольно болезненной процедурой, но экосистема развертывания Rails, стремительно развивалась в течение нескольких последних лет и теперь имеет различные замечательные опции. Они включают общедоступные хосты или виртуальные выделенные серверы, использующие http://www.modrails.com/Произносится "Engine X". , компании предоставляющие полный комплекс услуг развертывания, такие как Engine Yard и Rails Machine, и облачные сервисы развертывания, такие как Engine Yard Cloud и Heroku.

Моим любимым сервисом для развертывания Rails является Heroku, который является хостинговой платформой, созданной специально для того, чтобы разворачивать Rails и другие Ruby веб-приложения. Heroku делает развертывание Rails приложений смехотворно легким - пока ваш исходный код находится в системе управления версиями Git. (Это - еще одна причина выполнить шаги установки Git из Раздела 1.3 если вы этого еще не сделали.) Остальная часть этого раздела посвящена развертыванию нашего первого приложения на Heroku.

Установка Heroku

Heroku использует базу данных PostgreSQL (произносится "post-gres-cue-ell", и часто называется "Postgres"), это означает что нам нужно добавить гем pg в production окружение для того чтобы позволить Рельсам общаться с Postgres

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

Обратите внимание на добавившийся гем rails_12factor, который Heroku использует для работы со статическими ассетами, такими как изображения и таблицы стилей.

Как было отмечено в Разделе 1.2.4, хорошей идеей является явное указание ожидаемой нашим приложением версии Ruby:

ruby '2.0.0'
#ruby-gemset=railstutorial_rails_4_0

(Здесь я для удобства также добавил необязательную строку с RVM гемсетом. Вам следует заменить ’2.0.0’ на ’1.9.3’ если вы используете Ruby 1.9.3.) Применение этих изменений к Gemfile из Листинга 1.5 приводит к Листингу 1.9.

source 'https://rubygems.org'
ruby '2.0.0'
#ruby-gemset=railstutorial_rails_4_0

gem 'rails', '4.0.2'

group :development do
  gem 'sqlite3', '1.3.8'
end

gem 'sass-rails', '4.0.1'
gem 'uglifier', '2.1.1'
gem 'coffee-rails', '4.0.1'
gem 'jquery-rails', '3.0.4'
gem 'turbolinks', '1.1.1'
gem 'jbuilder', '1.0.2'

group :doc do
  gem 'sdoc', '0.3.20', require: false
end

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

Для того чтобы установить его, мы запускаем bundle install со специальным флагом:

$ bundle install --without production

Опция --without production предотвращает локальную установку любых продакшен-гемов, в данном случае это pg и rails_12factor. (Если Bundler выдает ошибку связанную с readline, попробуйте добавить gem 'rb-read\-line', '~> 0.4.2' в ваш Gemfile.) Поскольку мы добавили только гемы для продакшен окружения, прямо сейчас эта команда не приведет к установке каких-нибудь локальных гемов, но это необходимо для добавления гемов pg и rails_12factor в Gemfile.lock. Мы можем закоммитить получившиеся изменения следующим образом:

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

Некоторые читатели сообщили что для успешного развертывания на Heroku в этой точке им пришлось запустить локальную прекомпиляцию ассетов:

# Это должно быть использовано только если вы не можете задеплоить на Heroku.
$ rake assets:precompile
$ git add .
$ git commit -m "Add precompiled assets for Heroku"

(Здесь используется команда rake, о которую мы более подробно обсудим в Разделе 2.2.) Шаг прекомпиляции ассетов по идее не нужен и я не смог воспроизвести ситуацию в которой он был бы необходим, но количество получаемых сообщений об ошибках таково что я вынужден упомянуть здесь о решении.)

Затем мы должны создать и сконфигурировать новый Heroku аккаунт. Первый шаг это http://api.heroku.com/signuphttps://toolbelt.heroku.com/ Затем используйте команду heroku для входа в командную строку (для этого вам может понадобиться выйти и перезапустить ваш терминал):

$ heroku login

Наконец, перейдите в директорию вашего Rails проекта и используйте команду heroku для создания на Heroku серверах места под пример приложения (Листинг 1.10).

$ cd ~/rails_projects/first_app
$ heroku create
Created http://stormy-cloud-5881.herokuapp.com/ |
git@heroku.com:stormy-cloud-5881.herokuapp.com
Git remote heroku added

Команда heroku создает новый поддомен для нашего приложения, который незамедлительно доступен для просмотра. Однако там пока ничего нет, так что давайте займемся развертыванием.

Развертывание на Heroku, шаг первый

Развертывание на Heroku, шаг первый

$ git push heroku master

Развертывание на Heroku, шаг второй

Нет никакого шага два! Все готово (рис 1.10). Чтобы увидеть ваше свежеразвернутое приложение, нужно посетить адрес, который вы видели, когда выполняли, heroku create (то есть Листинг 1.10, но с адресом для вашего приложения). Вы также можете использовать аргумент heroku команды который автоматически откроет ваш браузер с правильным адресом:

$ heroku open

К сожалению, в результате мы видим только страницу ошибки; по техническим причинам дефолтная Rails 4.0-страница не работает на Heroku. Хорошая новость в том что ошибка уйдет (в контексте нашего примера приложения) когда мы добавим корневой маршрут в Разделе 5.3.2.

После успешного разверывания, Heroku предоставляет красивый интерфейс для администрирования и конфигурирования вашего приложения (рис 1.11).

Команды Heroku

Есть тонны команд Heroku, и мы только слегка коснемся их в этой книге. Уделю минуту, чтобы показать только одну из них, переименовав приложение следующим образом:

$ heroku rename railstutorial

Не используйте сами это имя; я его уже занял! Фактически, вам вероятно, не стоит заморачиваться этим шагом прямо сейчас; использование адреса по умолчанию, предоставленного 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.

Заключение

Мы проделали длинный путь в этой главе: установка, настройка среды разработки, управление версиями, и развертывание. Если вы хотите поделиться с общественностью своим прогрессом в этой точке, не стесняйтесь твитнуть или изменить свой статус в Facebook (Вконтакте) на что-то вроде этого:

Я изучаю Ruby on Rails с @railstutorial! http://railstutorial.org/

Единственное что осталось сделать - действительно начать изучать Rails. Приступим!