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

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

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

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

Рис. 1.5. Схематичное изображение модель-представление-контроллер (MVC) архитектуры.

Если это обсуждение сейчас кажется вам немного абстрактным, не беспокойтесь; мы будем часто возвращаться к этому разделу. В дополнение, в Разделе 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, вы должны использовать флаг, чтобы быть уверенным, что редактор остается присоединенным к оболочке вместо того, чтобы отсоединиться сразу:^{15Обычно это настройка, позволяющая вам продолжать использовать командную строку после запуска вашего редактора, но 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 в корневой каталог Rails с небольшим количеством правил, которые говорят Git какие файлы следует игнорировать^{16Если вы не видите файла .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