Сегодня в интернетах я нашел историю о том, как некто Джеймс Фенд учился Ruby on Rails в течение 12 недель. Ниже вы можете прочитать относительно точный перевод этой истории, и, надеюсь, вдохновиться на изучение этого прекрасного фреймворка (и прекрасного языка).

Прежде чем начать, я хотел бы представить Джоша Криуса (http://joshcrews.com) и поблагодарить его за то, что убедил меня начать изучать Ruby on Rails; без него, его помощи и без часов, которые он потратил на то, чтобы быть моим наставником, я не писал бы это сегодня. Спасибо.

Ровно 12 недель назад я был техническим предпринимателем (tech entrepreneur), который тратил тысячи долларов, чтобы создать приличный MVP (минимально жизнеспособный продукт), потому что мне недоставало знаний. Одной из причин (как я тогда думал) было то, что обучение было для меня слишком сложным или заняло бы чрезмерно много времени. Я думал (как и многие другие), что программисты (и некоторые действительно) рождаются с набором волшебных навыков в решении проблем и математике, которые делают их гениями программирования. И именно 12 недель назад я принял лучшее решение за долгое, по-настоящему долгое время . Больше ни одна из моих идей не останется не более чем идеей. Теперь у меня есть возможность запускать рабочие версии, тратя деньги лишь на хостинг и прилагая некоторые усилия. На сегодняшний день этот набор навыков — это примерно как пригнать кучу тракторов во времена калифорнийской золотой лихорадки, пока все остальные используют простые лопаты. Я предлагаю каждому научиться писать код . Здесь я хотел бы добавить уточнение: ранее, назвал пост “Как я изучил Rails за 8 недель”, однако, если быть точным, то учитывая дату запуска, получается 12 недель. Однако за 8 недель я почувствовал, что знаю достаточно, а следующие четыре недели были потрачены в большей степени на то, чтобы заставить полученные знания работать, а не на обучение.

Я был веб-дизайнером, обладающим познаниями в HTML и CSS, и, в основном, фокусировался на дизайне UI и UX. Самое сложное, что я делал с реальным кодом (не считая HTML) — это возможность настраивать WordPress. Одним словом, я абсолютно не имел представления ни о том, что такое MVC-фреймворк, ни о том, как в целом работают базы данных. Дизайн, макет и HTML для Freelancify были созданы мной за две недели в июне 2011-го.

Почему я принял решение учиться?

Возвращаясь в июнь 2011-го, когда макет был готов, я начал поиски кодера, который сделал бы макет функционирующим. Макет был практически готов: у меня были текстовые поля, выпадающие меню, формы, кнопки, ссылки, ведущие куда необходимо, и так далее. Нашел разработчика, и, если в двух словах, то парень мне не подошел. Я остался с кучей долгов и даже не близким к завершению продуктом. Тогда я связался с Джошем Криусом (с ним я познакомился на встрече, посвященной Ruby on Rails, которую он организовал в Нэшвилле), и встретился с ним, чтобы понять, можно ли сделать хоть что-то из того, что у меня осталось от разработчика. К сожалению, починка и доработка кода заняла бы не меньше времени, чем разработка с нуля грамотным программистом. Я упал духом, понимая, что не смогу позволить себе снова тратить тысячи долларов на разработку с нуля. И тогда Джош сказал… “Почему бы тебе просто не научиться обращаться с Ruby on Rails, этот проект был бы прекрасным способом ” и затем “Я могу даже встречаться с тобой дважды в неделю и помогать тебе в обучении ”. Я потратил целую ночь на раздумья. Моими вариантами было: найти комфортную работу и оплатить счета ИЛИ рискнуть всем, чтобы научиться Rails и, в конце концов, лакомиться лучшим раменом, который только готовят в Италии. Я решил. Позвонил Джошу на следующее утро. Я поставил все. Я выделил деньги из оставшихся сбережений и разделил их на три месяца (для неженатого парня, живущего в одиночестве и без детей одной тысячи долларов на месяц вполне достаточно). Время приниматься за работу, теперь я ученик на полном рабочем дне. Держу в уме: поиск в Google, Stackoverflow, IRC #RubyOnRails и сообщество Rails будут прикрывать меня, когда я застряну, уверен, что их будет достаточно.

Мои следующие три месяца — Миссия : получить MVP, получить достаточно, чтобы работать, но не “отстойно-достаточно”, чтобы оставить ужасное первое впечатление.

Недели 1 — 3

Это была, пожалуй, сложнейшая кривая обучения, но я НЕ сдавался.

Стены созданы для людей, которые, на самом деле, не хотят их покидать.

Установка рабочего окружения Rails для полного новичка может оказаться невероятно раздражающей. Подсказка #1: заимейте Mac. Подсказка #2: используйте Homebrew, RVM, Git и Heroku (на самом деле это все, что вам нужно, чтобы начать). Я потратил пару дней на установку, затем все удалил и снова установил. Достаточно повторить несколько раз, и вы привыкните к использованию командной строки терминала (консоли) и поймете, почему вещи работают так, как они работают.

Затем, первая вещь, которой я занялся, были уроки TryRuby, Rails for Zombies и Rails Tutorial Майкла Хартла. Не беспокойтесь о том, чтобы на 120% понять материал, этого не случится, пока вы не начнете по-настоящему учиться. Я закончил Rails Tutorial и создал это похожее на Twitter приложение примерно за неделю, не совсем понимая, что я сделал. Позднее, по мере продвижения, я стал понимать, что все начинает обретать смысл.

Недели 3 — 6

С Twitter-приложением, созданным при помощи Rails Tutorial, я обрел некоторую уверенность. Руководство не сделало меня разработчиком, но теперь я знаю общие шаги в создании приложений, с создания самого приложения, и до установки его на Heroku. Все, что было между тем временем оставалось размытым. Как мне теперь ПО-НАСТОЯЩЕМУ начать учиться? Работая над реальным проектом, который что-то для меня значит . Джош и я решили, что мне стоит свободно поработать над Freelancify и посмотреть, что я смогу сделать. Первым, что я сделал, был перенос всего HTML с каркаса и организация его в файлы видов(views) и парциалов(partials). Я создал(scaffolded) шаблонные платформы для Пользователей(Users) и Проектов(Projects).

13 фактов о Ruby on Rails – Что вам нужно знать?

Затем я начал изучать мой первый реальный гем Devise. Затем, возможность иметь отношения, например каждый Пользователь будет иметь портфолио. Но пользователи могут иметь множество портфолио, в то время как каждое портфолио может принадлежать лишь одному Пользователю. Когда вы поймете, как работают отношения между моделями и как вызывать/отображать вещи, которые принадлежат чему-то еще, жизнь станет намного проще. Если в какой-то части вы застряли и не можете сдвинуться с места, пропустите её, велика вероятность того, что пока вы разрабатываете другую возможность, вы так же поймете, как реализовать и то, что вы пропустили.

Недели 6 — 9

Шажок за шажком, я продолжал учиться, копируя и повторяя. Я мог заставлять какие-то вещи работать, а затем — бац — и я втыкался в стену и абсолютно не представлял, что же делать дальше. Заходя на Stackoverflow, IRC-чат #RubyOnRails, RailsCasts или дергая Джоша, в конце концов, я понимал, как действовать. Делайте то же самое снова и снова, и вы научитесь всему довольно быстро. Тратить раздражающие часы, тестируя чей-то ответ со Stackoverflow, чтобы понять, что он не работает — это, на самом деле, полезно. Вы понимаете, чего не следует делать. И когда вы найдете ответ, вы начнете понимать, ПОЧЕМУ последнее не работало. Примерно в это время я начал осознавать, насколько велика картина вещей, и по-настоящему понимать, ПОЧЕМУ все работает именно так, как работает. Я чувствовал себя идиотом, возвращался назад и рефакторил код, который написал ранее, делая его более эффективным. И в какой-то момент я достиг стадии, когда все начало становиться на свои места.

Недели 9 — 12

Я был в режиме невероятной энергичности, дорабатывая Freelancify до стадии запуска. На этой стадии я чувствовал себя так, словно лечу, претворяя функции в жизнь. Последняя неделя была потрачена на отладку различных багов и ляпов. В этот понедельник я запустил сайт. Но я по-прежнему далек от завершения обучения… Вот так. Я опустил (во имя краткости поста) мелкие детали и технические моменты. Тем не менее, не стесняйтесь задавать вопросы в комментариях, я определенно постараюсь ответить. Джеймс Фенд.

P.S. — Несмотря на то, что мне сильно помогла помощь наставника, с которым я мог встречаться, вы определенно можете изучить Rails и без него. Или же попробуйте найти себе такого человека, многие Rails-разработчики любят вносить свой вклад в сообщество. Поищите локальные конференции и встречи.

Этой записи уже более двух лет (опубликована 27 января 2012-го года), но она, тем не менее, не утратила своей актуальности. Джеймс Фенд за это время успел продать Freelancify и вложиться в новый стартап, запись об этом он оставил 27 февраля 2013. Я считаю, что эта статья — прекрасный пример того, как человек может идти к поставленной цели. Достаточно лишь начать. 🙂

Ruby on Rails - это веб-фреймворк с открытым кодом, от которого программисты становятся счастливыми, код - красивым, а разработка - устойчивой и быстрой.

На этом сайте выложены переводы официального руководства по Rails. Надеемся, эти руководства позволят вам немедленно приступить к использованию Rails и помогут разобраться, что и как в нем работает.

Переводы постоянно актуализируются и добавляются. Код проекта и тексты переводов открыты и размещены на Гитхабе. Желающим помочь всегда рады! Форкайте, предлагайте изменения, вносите их, отправляйте пул-реквесты!

Это перевод Ruby on Rails Guides для версии Rails 5.2. Переводы для ранних версий доступны в архиве или на гитхабе:

Приступим!

Rails для начинающих Все, что вы должны знать, чтобы установить Rails и создать свое первое приложение. Основы Active Record Это руководство поможет начать работать с моделями, сохранять в базу данных и расскажет о паттернах и библиотеке Active Record. Миграции Active Record Это руководство раскрывает, как вы должны использовать миграции Active Record, чтобы привести свою базу данных к структурированной и организованной форме. Валидации Active Record Это руководство раскрывает, как вы можете применять валидации Active Record. Колбэки Active Record Это руководство раскрывает, как вы можете применять колбэки (методы обратного вызова) Active Record. Связи (ассоциации) Active Record Это руководство раскрывает все связи, предоставленные Active Record. Интерфейс запросов Active Record Это руководство раскрывает интерфейс запросов к базе данных, предоставленный Active Record. Active Record для PostgreSQL Это руководство рассказывает о специфике использования PostgreSQL с Active Record. Основы Active Model Это руководство познакомит вас со всем, что вам надо для начала использования моделей классов Active Model. Обзор Action View Это руководство представляет введение в Action View и знакомит с некоторыми из многих хелперов вьюх. Макеты и рендеринг в Rails Это руководство раскрывает основы возможностей макетов Action Controller и Action View, включая рендеринг и перенаправление, использование содержимого для блоков и работу с частичными шаблонами. Хелперы форм в Action View Руководство по использованию встроенных хелперов форм. Обзор Action Controller Это руководство раскрывает, как работают контроллеры, и как они вписываются в цикл запроса к вашему приложению.

Подборка материалов по Ruby и Ruby On Rails

Оно включает сессии, фильтры, куки, потоковые данные, работу с исключениями, вызванными запросами, и другие статьи. Роутинг в Rails Это руководство раскрывает открытые для пользователя функции роутинга. Если хотите понять, как использовать роутинг в вашем приложении на Rails, начните отсюда. Расширения ядра Active Support Это руководство документирует расширения ядра Ruby, определенные в Active Support. Инструментарий Active Support В этом руководстве, вы научитесь использовать инструменты Active Support API для отслеживания событий внутри Rails или другого кода на Ruby. API интернационализации Rails (I18n) Это руководство раскрывает, как добавить интернационализацию в ваше приложение. Ваше приложение будет способно переводить содержимое на разные языки, изменять правила образования множественного числа, использовать правильные форматы дат для каждой страны и так далее. Основы Action Mailer Это руководство описывает, как использовать Action Mailer для отправки и получения электронной почты. Основы Active Job Это руководство даст вам все, что нужно, чтобы начать создавать, ставить в очередь и запускать фоновые задания. Обзор Active Storage В этом руководстве описывается, как прикреплять файлы к моделям Active Record. Тестирование приложений на Rails Это достаточно полное руководство по осуществлению юнит- и функциональных тестов в Rails. Оно раскрывает все от “Что такое тест?” до тестирования API. Наслаждайтесь. Безопасность приложений на Rails Это руководство описывает общие проблемы безопасности в приложениях веб, и как избежать их в Rails. Отладка приложений на Rails Это руководство описывает, как отлаживать приложения на Rails. Оно раскрывает различные способы достижения этого, и как понять что произошло "за кулисами" вашего кода. Конфигурирование приложений на Rails Это руководство раскрывает основные конфигурационые настройки для приложения на Rails. Командная строка Rails Это руководство раскроет инструменты командной строки, предоставленные Rails. Кэширование с Rails: Обзор Различные техники кэширования, предоставленные Rails. Asset Pipeline Это руководство документирует файлопровод (asset pipeline) Работа с JavaScript в Rails Это руководство раскрывает встроенную в Rails функциональность Ajax/JavaScript. Engine для начинающих Это руководство объясняет, как написать монтируемый engine Процесс инициализации в Rails Это руководство объясняет внутренние процессы инициализации в Rails, начиная с Rails 4. Автозагрузка и перезагрузка констант Это руководство документирует, как работает автозагрузка и перезагрузка констант. Обзор Action Cable Это руководство документирует, как работает Action Cable, и как использовать WebSockets. Основы создания плагинов Rails Это руководство раскрывает, как создать плагин, расширяющий функциональность Rails. Rails on Rack Это руководство раскрывает интеграцию Rails и Rack, и взаимодействие с другими компонентами Rack Создание и настройка генераторов и шаблонов Rails Это руководство раскрывает процесс добавления совершенно нового генератора для вашего расширения или представления альтернативного элемента для встроенного в Rails генератора (такого как представление альтернативных тестовых заглушек для генератора скаффолда). Треды и выполнение кода в Rails В этом руководстве описываются необходимые требования и инструменты, доступные при работе напрямую с конкурентностью в приложении Rails. Использование Rails для API-приложений Это руководство раскрывает создание приложения Rails, отдающего ресурсы JSON клиентам API или клиентскому фреймворку. Шаблоны приложения Rails Это руководство раскрывает создание и использование шаблонов приложений на Rails. Вносим вклад в Ruby on Rails Rails - это не "чей-то там фреймворк". Это руководство раскрывает многообразие способов, которыми вы можете быть вовлечены в продолжающуюся разработку Rails. Рекомендации по документированию API Это руководство документирует рекомендации для документации Ruby on Rails. Рекомендации для руководств по Ruby on Rails Это руководство документирует рекомендации для руководств по Ruby on Rails. Установка зависимостей для разработки Это руководство раскрывает, как настроить среду для разработки ядра Ruby on Rails. Политика поддержки (версий) Какие версии Ruby on Rails поддерживаются в настоящее время и когда ожидать новые версии. Апгрейд Ruby on Rails Это руководство поможет произвести апгрейд приложения до последних версий Ruby on Rails. Заметки о релизе Ruby on Rails 5.2 Заметки о релизе Rails 5.2 Заметки о релизе Ruby on Rails 5.1 Заметки о релизе Rails 5.1 Заметки о релизе Ruby on Rails 5.0 Заметки о релизе Rails 5.0 Заметки о релизе Ruby on Rails 4.2 Заметки о релизе Rails 4.2 Заметки о релизе Ruby on Rails 4.1 Заметки о релизе Rails 4.1 Заметки о релизе Ruby on Rails 4.0 Заметки о релизе Rails 4.0 Заметки о релизе Ruby on Rails 3.2 Заметки о релизе Rails 3.2 Заметки о релизе Ruby on Rails 3.1 Заметки о релизе Rails 3.1 Заметки о релизе Ruby on Rails 3.0 Заметки о релизе Rails 3.0

«Ruby on Rails - это прорыв в снижении входного барьера в программировании.
Мощные веб-приложения, которые раньше разрабатывались за недели или месяцы, теперь могут быть сделаны за считанные дни.»
- Тим О’Рейли, основатель O’Reilly Media

«Rails - наиболее продуманный веб-фреймворк, с которым я когда-либо сталкивался. И это после десятилетия заработков на жизнь разработкой веб-приложений.
Я создавал свои собственные фреймворки, помогал разрабатывать Servlet API и создал с нуля несколько веб-серверов.
Но никто не делал что-либо подобное раньше.»
- Джеймс Дункан Дэвидсон, создатель Tomcat и Ant

«Нельзя не замечать Ruby on Rails. Он произвел огромный эффект как внутри, так и вне сообщества Ruby.
Rails стал стандартом, с которым сравнивают себя даже хорошо устоявшиеся инструменты.»
- Мартин Фаулер, автор Refactoring, PoEAA, XP Explained

«Что выделяет этот фреймворк в сравнении с другими, так это предпочтение соглашений над конфигурацией, что упрощает разработку и понимание приложений.»
- Сэм Руби, совет директоров ASF

«До появления Ruby on Rails, веб-разработка отнимала много пустых слов, шагов и времени.
Сейчас веб-дизайнеры и разработчики могут разрабатывать сайты намного быстрее и проще, что позволяет им работать более эффективно и продуктивно.»
- Брюс Перенс, Open Source Luminary

«Мы исследовали рынок и решили, что Ruby on Rails - лучший выбор. И мы не пожалели об этом решении.
Мы будем продолжать строить приложения на Rails и считаем это ключевым преимуществом бизнеса.»
- Эван Вильямс, создатель сервисов Blogger и ODEO

«Ruby on Rails поразителен. Им пользоваться - все равно что смотреть фильм с восточными единоборствами, где дюжина негодяев готовится пришибить малютку-новичка - как выясняется, чтобы получить от него по полной программе.»
- Натан Торкингтон, O’Reilly Program Chair для OSCON

«Rails - это killer app для Ruby.»
- Юкихиро Матцумото, создатель Ruby

Что входит
в Rails?

Rails —- это полноценный, многоуровневый фреймворк для построения веб-приложений, использующих базы данных, который основан на архитектуре Модель-Представление-Контроллер (Model-View-Controller, MVC).

Динамичный AJAX-интерфейс, обработка запросов и выдача данных в контроллерах, предметная область, отраженная в базе данных, - для всего этого Rails предоставляет однородную среду разработки на Ruby. Все, что необходимо для начала - база данных и веб-сервер.

Кто пользуется
Rails?

Rails используют все - от стартапов и некоммерческих организаций до крупного бизнеса. Rails - это прежде всего инфраструктура, поэтому среда великолепно подходит для любого типа веб-приложений, будь это программы для организации совместной работы, поддержки сообществ, электронного бизнеса, управления содержанием, статистики, управления… Список можете продолжить сами. Примеры:

Basecamp: Управление проектами. Rails начался с этого приложения 37signals.	Campfire: Групповой чат для бизнеса. Pushing the limits of Ajax in Rails.
43things: Поставь себе цели в жизни и добейся их. Расскажите какую нишу занимает Ruby On Rails	ODEO: Записывай и распространяй аудио.
Strongspace: Безопасное хранилище файлов.	Typo: Ваш блог на Rails.

Что еще
нужно?

Rails отлично работает со многими веб-серверами и СУБД. В качестве веб-сервера рекомендуется использовать Apache или nginx с модулем Phusion Passenger. Rails также можно разворачивать используя Unicorn, Thin, Mongrel или FastCGI. В качестве СУБД можно использовать MySQL, PostgreSQL, SQLite, Oracle, SQL Server, DB2 или Firebird. Использовать Rails можно на практически любой операционной системе, однако для развертывания мы рекомендуем системы семейства *nix.

Ruby on Rails был создан David Heinemeier Hansson в партнерстве с 37signals, расширен и усовершенствован усилиями команды разработчиков ядра Rails и сотнями open source разработчиков. Rails распространяется под лицензией MIT. Ruby распространяется под лицензией Ruby License.

«Rails», «Ruby on Rails» и логотип Rails являются зарегистрированными торговыми знаками David Heinemeier Hansson. Все права защищены.

Поддержка сайта - Evil Martians. Вопросы, предложения? Свяжитесь с нами.

Алексей Дмитриев: Здравствуйте. Меня зовут Алексей Дмитриев, и я занимаюсь веб-разработкой последние лет 7. Сначала я писал на PHP и Perl, потом перешел на Ruby, который использую последние 4 года.

Что такое Ruby on Rails? Это фреймворк с открытым исходным кодом. Он существует уже достаточно давно. В штате - 8 активных разработчиков плюс огромное сообщество. В общей сложности в разработке Rails участвует 300-400 человек.

Специалисты создают патчи и пишут плагины. Наработки используются в Rails Core. В конце концов, мировое сообщество испытывает удовольствие от работы с этим фреймворком.

Идеология Rails

Идеология Rails проста. Фреймворк, ориентированный, в первую очередь, на разработчиков, предназначен для разработки веб-проектов. Т.е. серверы, машины, оборудование — это отлично, но фреймворк ориентирован на нужды разработчиков. В этом состоит его принципиальное отличие от Java. В Ruby-сообщество и Rails-сообщество специалисты приходят в основном с Java.

Существует представление, что конфигурация — это не наш выбор. В Rails-среде и Rails-проектах соглашение всегда преобладает над конфигурацией. Конечно, вы можете производить определенную конфигурацию. Но для того чтобы начать разработку, вам не нужно создавать длинные файлы конфигурации. Многое существует уже в готовом виде. Из этого вы сможете выбирать необходимое для дальнейшей работы.

У всех Rails-проектов единая структура. Работая над новым проектом, вы заранее знаете, что и где лежит: модели, шаблоны, библиотеки и плагины. Rails построен на базе схемы MVC ("Модель-представление-контроллер"). Логика проектов разделена на три слоя.

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

Главная сила Ruby on Rails скрыта в языке, на котором он написан. Ruby — это скриптовый язык, который выполняется в момент запроса и не требует компиляции.

Также это объектно-ориентированный язык (как Java или С#). Любая сущность внутри Ruby является объектом, будь то строки, числа, классы или модули.

В Ruby типизация динамическая. Для вызова методов не обязательно задавать типы атрибутов. Все переменные в общем равноправны. Вы сами определяете, с чем вы работаете.

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

Например, в класс «строка» можно добавить новый метод. Аналогично - с классом "книга". Они будут работать одинаково (при прочих равных условиях), поскольку определены одни и те же методы.

Для языка Ruby существует очень большое количество реализаций. Фактически Ruby постепенно адаптируется на всех сколько-нибудь значимых виртуальных машинах. Его сейчас можно поставлять как самостоятельный продукт или диалект в Java-машину. Надеюсь, в скором времени можно будет пользоваться им на платформе DotNet (IronRuby).

Этот язык уже используется по умолчанию в новой версии Mac OS (в виде MacRuby), а также портируется на виртуальную машину Smalltalk и Sub. Надеемся, Rails тоже будет доступным везде и всюду.

Структура Rails — это модель, ее контроллер. Модели представлены фреймворком. Rails — это не единый фреймворк, а их конгломерат. Каждый из них отвечает за определенную часть проекта.

Модель представлена фреймворком ActiveRecord. Его можно использовать и вне Rails (допустим, для работы с базами данных). Это объектно-реляционное отображение (англ. Object-relational mapping, ORM). ActiveRecord поддерживает MySQL, PostgreSQL и SQLite.

ActiveRecord может использоваться высокоранговыми базами данных. Попутно для ActiveRecord были написаны несколько плагинов для поддержки проприетарных баз данных: Oracle, Microsoft SQL Server и DB2.

ActiveRecord предоставляет возможность задавать отношения между различными моделями внутри проекта через определенные связи. Один - ко многим, многие - ко многим и полиморфные связи (когда объекты, связанные друг с другом, "не знают", какого класса у них связи).

Все связи расширяемы. Допустим, внутри первой связи мы можем задавать одни методы, внутри второй — другие. Также возможно использование модулей для расширения функционала.

ActiveRecord используется для выборки данных из базы (в отличие от многих фреймворков, которые доступны на рынке). Чтобы работать с базой данных, знать SQL необязательно.

Вообще в Rails-мире считается, если вы пишете на SQL, то вы либо не знаете, что делаете, либо точно знаете, но тогда вам уже по-другому просто никак. Во всех остальных случаях можно обойтись методами ActiveRecord. Это чаще всего более обоснованно, потому что позволяет создавать различные вещи (например, быстро добавлять фильтры в зависимости от условий, при этом не заботясь о формировании SQL).

ActiveRecord при поиске предоставляет защиту от SQL-инъекций. Если вы в запрос напрямую не "втыкаете" параметры, а пользуетесь, например, conditions => name => ‘Google’ и используете параметры, полученные от пользователя, то по умолчанию защита от SQL-инъекций обеспечена.

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

В зависимости от условий создания объектов можно создавать одни валидации, при обновлении — совершенно другие. Плюс можно использовать как стандартный набор валидаций, так и собственные.

Скоро выйдет третья версия Rails. Мы ее ждем уже больше года. В ней ActiveRecord будет разделен еще на несколько частей, появится ActiveModel — Единый интерфейс программирования приложений для хранилищ. Будет снято ограничение на использование реляционных баз данных.

В качестве хранилищ можно будет использовать не SQL-базы данных (MongoDB, Cassandra), Redis и создавать собственные драйверы для хранилищ.

В частности, на ActiveModel будет построена работа с внешними ресурсами через HTTP.

Появится новый язык выборок.

Такие большие конструкции. И как выглядит сейчас.

Язык Ruby стал более мощным.

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

Причем в Rails уже встроена передача представлений состояний (англ. REST). В зависимости от используемого HTTP-метода внутри контроллера будут применены разные методы.

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

Следующее — это фильтры. В контроллерах предусмотрена возможность пре- и постобработки запроса. Входящий запрос направляется в фильтр, где можно проверить, авторизован ли пользователь и т.д. Полученный результат можно обработать, добавить cookie и ответ. Логику обработки запроса можно разделять.

Контроллер поддерживает ответы в разных форматах. Один и тот же метод на разные запросы может отвечать по-разному. Грубо говоря, если вы создаете запрос на определенный URL из браузера, то получаете HTML. Если вы создаете запрос на AJAX, то получаете JSON.

При этом логика работы контроллера сохраняется. Вам не требуется писать множество контроллеров, чтобы обрабатывать запросы iPhone или iPad. Все можно создавать в одном месте.

Следующее — это View, т.е. шаблоны, представления, вид представляемых данных. В Rails существует возможность использования собственных шаблонов. По умолчанию используется ERB (embedded Ruby). Это обыкновенный HTML, в котором размещаются фрагменты кода.

В целом это неплохо, но находятся любители других шаблонизаторов, например, HAML. Это шаблонизатор в стиле дзен, где не требуется писать закрывающиеся тэги и угловые скобки.

Для Rails существует около двадцати шаблонизаторов на любой вкус. View поддерживает разные шаблоны для разных майнтайпов.

В зависимости от типа запроса, можно дать соответствующий ответ. Если запрос направляется с HTML-страницы — ответ один, если с RSS — другой. Можно даже выдавать разные страницы на разные языки. В зависимости от языка пользователя, допустимо выдавать разные шаблоны.

В Rails присутствует большое количество помощников (англ. helper), т.е. методов, помогающих формировать страницу. Вместо создания кода вручную, можно использовать помощников. В Rails их достаточно много.

Приведем пример создания формы через помощник form_for. Ему передана модель ActiveRecord. Форма автоматически создает поля, куда вставляется имя самого поля и его значение из модели.

Rails формирует набор помощников (в данном случае — new_user_path), которые помогают проставлять формирование URL соответствующих страниц. То есть new_user_path — это, например, URL страницы добавления пользователя.

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

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

В Rails работает встроенная поддержка локализации. Вы можете сделать приложение многоязычным. В зависимости от запроса пользователя возможна выдача ответов на разных языках. Аналогично - в случае с контроллерами. Доступ к этим данным предоставляется практически везде.

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

Эти 12 тысяч расширений позволяют делать многое. Практически для любой задачи, которую решали на Rails хотя бы 3 человека на планете, скорее всего, уже есть или плагин, или gem. Практически все типовые задачи решаются с помощью плагинов или gem, будь то авторизация или регистрация.

Что такое нетиповая задача? Например, это — работа с Excel из UX.

Что касается поиска расширений, то его можно осуществлять всего в двух местах. На GitHub (где располагается большинство плагинов) и RubyGems (где располагается большинство gem).

Не так давно при подготовке к выпуску Rails 3 был разработан Bundler. Это инструмент для формирования зависимости проекта. Если, допустим, ваш проект использует 10-20 различных gem, их можно вручную вставить в систему.

Третья версия Rails максимально адаптирована для расширения. В ней добавлено довольно много возможностей для расшерения Rails.

Каковы типичные ошибки при переходе на Rails?

Первая ошибка. Мы хотим писать на Ruby, как на PHP (или Perl). Это недопустимо, т.к. языки довольно сильно отличаются друг от друга — не синтаксисом, а, скорее, подходом к качеству.

В Ruby более высокий уровень требований к качеству проектов вообще. На сайте Rails приведены примеры того, как надо писать: демонстрации, видеозаписи, руководства и т.д.

Вторая ошибка - изобретение велосипедов. Изобретать нечто новое — очень полезно. Но лучше сначала проверить те 12 тысяч плагинов и gem, о которых я упоминал. Поэтому лучше всего проконсультироваться у специалиста по интересующему вопросу, например, на форуме.

Третья ошибка - ощущение, что Ruby - это панацея от всех бед. Это не так. Перед Ruby стоит вполне конкретная задача — это создание веб-проектов. Обработку видео и графики, создание многопоточных систем на Ruby осуществлять нельзя.

Rails очень хорошо работает в команде с другими сервисами. В частности, в плане поиска (со Sphinx) или обработки изображений (с ImageMagick).

Мифы относительно Ruby on Rails

Существует несколько мифов о Ruby on Rails, которые распространяют люди, никогда на нем не работавшие.

Первый миф - Rails медленнее, чем другой язык

Возможно. Но вопрос в том, как измерять скорость.

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

Rails достаточно быстрый, чтобы решать необходимые задачи. Например, необходимо передать человеку изображение или страницу. Будет она сгенерирована за 50 миллисекунд или за 70 - принципиальной разницы в этом нет.

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

Скорость каравана определяется скоростью самого медленного верблюда. При высоких нагрузках самыми медленными верблюдами становятся хранилища. Это база данных, файловая система — то, во что упираются любые проекты.

Самый простой способ ускорить Rails — ускорить то, с чем работает язык. Необходимо оптимизировать базу данных и запросы по сети, если таковые имеют место.

Также необходимо заниматься кэшированием - когда все "падает". Раньше — не имеет смысла.

Нужно помнить о типичной ошибке №3 (Rails не серебряная пуля, т.е. не панацея). Для особо чувствительных к низкой скорости мест рационально использовать более быстрые языки. Может быть, "C". Благо, на нем можно писать расширения для Ruby. Ruby сам написан на "C".

Плюс можно использовать такие замечательные языки, как Perl, Java, C#. Если у вас посещаемость проекта достигает 10 тысяч, а некий виджет с проекта получает 200 миллионов просмотров в сутки, то лучше его написать на Perl. Но писать весь проект на Perl из-за одного виджета, я не вижу смысла.

Миф №2: Rails не масштабируются

Специалисты производственного сектора, для кого кластер начинается от ста серверов, очень любят говорить такое.

«Рельсы» (англ. rails) замечательно масштабируются элементарным добавлением серверов, но упираются в проблему хранилищ. В конечном счете все сводится к масштабированию базы данных, файловой системы и т.п. Сервисы, которые успешно справлялись с данной задачей, существуют.

Третий миф — дорогой хостинг

Стоимость хостинга — $19,95 в месяц. То есть достаточно заплатить 585 рублей, чтобы "поднять" обычный Rails-проект. Время программистов стоит дороже, чем хостинг. Вы можете экономить столько, что вам хватит средств на три таких хостинга.

В каких случаях уместно применение Ruby?

При разработке прототипов, для внутренних и веб-проектов, требующих уникального функционала, где стандартная CMS или Bitrix не поможет. Кроме того, данный язык удобно использовать если важен такой фактор, как скорость разработки.

В то время, как это все еще нарушает принцип единственной обязанности, это своеобразный минимум, который фреймворк Rails требует от контроллера.

Ошибка 2. Слишком много логики в представлении

ERB, “коробочный” шаблонный движок Rails, открывающий потрясающие возможности по созданию страниц с различным контентом. Однако, если не быть осторожным, то можно в конечном счете получить большой файл, в котором будет перемешан HTML и Ruby-код, которым будет трудно управлять и который будет проблематично поддерживать. Также это может привести к большому количеству повторений, которые вызовут нарушение принципов DRY (don’t repeat yourself).

Это может проявиться множеством способов. Одним из них является чрезмерная условная логика в представлении. В качестве простого примера рассмотрим случай, когда у нас есть доступный метод current_user, который возвращает только что авторизованного в системе пользователя. Часто в логике представления будут появляться, например, такие логические структуры:

Welcome,
<% if current_user %>
<%= current_user.name %>
<% else %>
Guest
<% end %>

Лучший способ справиться с подобным: убедиться, что объект возвращаемый current_user всегда выбран, независимо от того, вошел ли кто-то в систему или нет, и что он отвечает методам, использованным в представлении разумным образом (иногда упоминается как null ). Например, вы можете определить хелпер current_user в app/controllers/application_controller таким образом:

require "ostruct"
helper_method:current_user

def current_user
@current_user ||= User.find session[:user_id] if session[:user_id]
if @current_user
@current_user
else
OpenStruct.new(name: "Guest")
end
end

Это позволило бы заменить предыдущий код представления всего одной строчкой:

Welcome, <%= current_user.name -%>

• Используйте шаблоны представления и разделяемые методы для инкапсуляции вещей, которые повторяются на ваших страницах.
• Используйте декораторы, такие, как Draper gem для инкапсуляции логики представления в Ruby-объект. Затем вы можете добавить методы в этот объект, чтобы представить логические операции, которые в противном случае были бы внутри кода представления.

Ошибка 3. Слишком много логики в модели

Ну, не совсем.

Многие Rails-разработчики на самом деле делают эту ошибку и в конечном счете их классы моделей в ActiveRecord, ведущие к файлам Mongo, — не только нарушают принцип единственной обязанности, но и являются кошмаром для техподдержки.

Такая функциональность, как генерация email-оповещений, обращение ко внешним сервисам, конвертирование данных в другие форматы и тому подобное не стоит делать с помощью ActiveRecord-моделей, назначение которых — делать чуть больше, чем поиск и хранение данных в базе.

Но если такая логика не должна храниться в представлении, в контроллере и модели — то где же тогда?

Давайте поговорим о “простых старых Ruby-объектах” (POROs). С таким всеобъемлющим фреймворком, как у Rails, неопытные разработчики часто не хотят создавать свои собственные классы вне фреймворка. Однако, часто вынесение логики модели внутрь POROs — это то, что доктор прописал во избежание усложнения моделей. С POROs вы можете инкапсулировать такие вещи, как email-уведомления или взаимодействия с API в их собственные классы, а не хранить их внутри ActiveRecord-модели.

Итак, исходя из сказанного, единственная логика, которая может остаться в вашей модели, это:

• Конфигурация ActiveRecord (например, взаимосвязи и валидация).
• Простые методы мутации для инкапсуляции обновления части параметров и сохранения их в базе.
• Врапперы доступа, которые скрывают внутреннюю информацию модели (метод full_name, который сочетает поля first_name и last_name в базе данных).
• Сложные запросы (более сложные, чем find). Вообще говоря, вы не должны использовать этот метод или любой другой метод построения очереди за пределами класса модели как такового.

Ошибка 4. Свалка из общих вспомогательных классов

Эта ошибка — своего рода следствие ошибки 3. Как уже говорилось, структура Rails делает акцент на названных компонентах (таких, как модель, представление и контроллер) в качестве основы MVC. Есть неплохие определения видов сущностей, которые принадлежат классам каждого из этих компонентов, но иногда нам бывают нужны методы, которые не подходят ни одному из трех.

Генераторы в Rail создают директорию хелпера и новые класс хелпера. Становится слишком заманчивым начать создавать функциональность, которая вовсе не понадобится ни модели, ни представлению, ни контроллеру.

Хотя Rails, конечно, и является MVC-центрированным фреймворком, ничто не мешает вам создать свои собственные типы классов и добавить подходящие каталоги для кода этих классов. Если у вас предусмотрена дополнительная функциональность, подумайте, какие методы группируются и найдите хорошие названия для классов, которые содержат эти методы. Используя Rails не повод, чтобы позволить лучшим практикам объектно-ориентированного проектирования отойти на второй план.

Ошибка 5. Использование слишком большого количества гемов

Ruby on Rails поддерживается богатой экосистемой гемов, которые в совокупности обеспечивают практически любую возможность, о которой только разработчик мог подумать. Это очень удобно для быстрого создания сложных приложений, но я также видел много приложений, где число гемов было непропорционально большим по сравнению с предоставляемой функциональностью.

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

Имейте в виду, что каждый гем, который вы подключаете к приложению, в свою очередь зависит от других гемов, а они от других и так далее. Добавление гемов может иметь совместный эффект. Например, добавление гема rails_admin добавит еще более 11 гемов, что на 10% больше, чем базовая конфигурация Rails.

На момент написания статьи дистрибутив свежего Rails 4.1.0 включал 43 гема в файле Gemfile.lock. Это явно больше, чем входит в Gemfile и представляет все гемы, которые набор стандартных гемов Rails добавляет в качестве зависимостей.

Тщательно продумайте все дополнительные расходы каждый раз, когда добавляете новый гем. Например, разработчики часто добавляют гем rails_admin, потому что он обеспечивает симпатичный веб-фронтенд для структуры модели. Но на самом деле он не больше, чем модный инструмент просмотра базы данных. Даже если ваше приложение требует наличия пользователей с админскими правами в качестве привилегии, вы, вероятно не захотите выдавать им прямой доступ к БД, а лучше разработаете свою собственную систему администрирования, чем добавите этот гем.

Ошибка 6. Игнорирование лог-файлов

В то время, как большинство Rails-разработчиков знают о доступности дефолтных лог-файлов во время разработки, они не уделяют много внимания информации в этих файлах. Хотя многие приложения полагаются на инструмента мониторинга логов, такие, как Honeybadger или New Relic на продакшне, также важно следить за своими логами во время процесса разработки и тестирования приложения.

Как уже упоминалось в этом уроке, структура Rails делает много “магии”, особенно внутри моделей. Использование ассоциаций позволяет очень просто построить взаимосвязями между таблицами и вывести все во вьюхах. Весь SQL-код генерируется автоматически. Но как вы узнаете, что сгенерированный SQL эффективен?

Одним из примеров, с которым вы часто будете работать, называется проблема запроса N+1. В то время, как проблема зафиксирована, единственный способ выяснить причину ее возникновения - посмотреть SQL-запросы в ваших логах.

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

posts = Post.limit(3)
posts.flat_map do |post|
post.comments.to_a
end
end

Когда мы смотрим в лог-файл, ища запрос, который вызвал этот метод, мы видим что-то вроде того: один запрос вызвал три поста, после чего еще три запроса вызвали комментарии к каждому:

Started GET "/posts/some_comments" for 127.0.0.1 at 2014-05-20 20:05:13 -0700

Post Load (0.4ms) SELECT "posts".* FROM "posts" LIMIT 3
Comment Load (5.6ms) ELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ?
Comment Load (0.4ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ?
Comment Load (1.5ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ?
Rendered posts/some_comments.html.erb within layouts/application (12.5ms)
Completed 200 OK in 581ms (Views: 225.8ms | ActiveRecord: 10.0ms)

Active Record в Rails позволяет существенно сократить число запросов, позволяя заранее уточнить все связи, которые будут загружены. Это делается путем вызова метода includes (или preload) метода в объекте Arel (ActiveRecord::Relation). C includes — ActiveRecord гарантирует, что все указанные связи будут загружены с минимальным количеством запросов, например:

def comments_for_top_three_posts
posts = Post.includes(:comments).limit(3)
posts.flat_map do |post|
post.comments.to_a
end
end

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

Started GET "/posts/some_comments" for 127.0.0.1 at 2014-05-20 20:05:18 -0700
Processing by PostsController#some_comments as HTML
Post Load (0.5ms) SELECT "posts".* FROM "posts" LIMIT 3
Comment Load (4.4ms) SELECT "comments".* FROM "comments" WHERE"comments "."post_id" IN (1, 2, 3)
Rendered posts/some_comments.html.erb within layouts/application (12.2ms)
Completed 200 OK in 560ms (Views: 219.3ms | ActiveRecord: 5.0ms)

Намного эффективней.

Решение проблемы N+1, которая в действительности может быть только примером того множества неэффективностей, которые живут “под капотом” вашего приложения, если вы не уделяете этому много внимания. Вывод из этого пункта состоит в том, что вам нужно проверять девелоперский и тестерский лог во время разработки — чтобы проверить (и устранить) неэффективности в коде, который занимается построением запросов.

Обзор логов — хороший способ локализовать неэффективный код и исправить его, прежде чем приложение уйдет в продакшн. В противном случае, вы не сможете быть уверенным в производительности вашей системы до тех пор, пока она не начнет “жить” — вероятно, та база данных, с которой вы работали в процессе разработки и тестирования, окажется куда меньше той, что будет на продакшне. Если вы делаете новое приложение, даже если ваша БД на продакшне изначально небольшая и все поначалу работает нормально, потом она вырастет и проблемы, описанные в этом примере будут делать работу системы все медленнее и медленнее.
Если вы обнаружите, что ваши логи забиты кучей ненужной вам информации, вы можете очистить их.

Ошибка 7. Отсутствие автоматических тестов

Ruby on Rails по умолчанию дает широкие возможности для автоматического тестирования. Многие Rails-разработчики пишут очень сложные тесты с использованием TDD и BDD-стилей, а также используют еще более мощные тест-фреймворки, поставляемые в гемах (rspec и cucumber).

Несмотря на то, как легко добавить автоматические тесты в ваше приложение, я был весьма удивлен, когда мне случалось присоединяться к проектам, где буквально не было ни одного написанного теста (или в лучшем случае, очень мало). В то время, как можно спорить насчет того, какими всеохватывающими тесты должны быть, совершенно ясно, что по крайней мере некоторые автоматические тесты должны присутствовать в каждом приложении.

Общее правило: должен быть как минимум один высокоуровневый интеграционный текст для каждого действия ваших контроллеров. В какой-то момент будущего другие разработчики захотят расширить или модифицировать код, или проапгредить версию Ruby on Rails, а тест-фреймворк позволит им убедиться, что базовая функциональность приложения работает. Дополнительным преимуществом будет то, что это дает будущим разработчикам четкое понимание полного набора функционала приложения.

Ошибка 8. Блокирование обращений ко внешним сервисам

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

Чтобы избежать блокировки таких запросов вместо прямого обращения к ним внутри вашего приложения, вам нужно перевести их в фоновый режим, если это возможно. Некоторые популярные гемы:

В случаях, когда невозможно или неосуществимо перевести обработку в фоновый режим, вы должны убедиться, что ваше приложение достаточно хорошо обрабатывает ошибки и сбои — если внешний сервис “лежит” или испытывает проблемы. Вам также нужно протестировать ваше приложение без внешних сервисов (возможно, путем удаления сервера, на котором работает ваше приложение, из сети), чтобы убедиться, что это не приводит к непредвиденным последствиям.

Ошибка 9. Getting married to existing database migrations

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

Хотя это хорошо работает в начале вашего проекта, время идет, процесс создания БД может занять некоторое время, и иногда миграции теряются, вставляются не в том порядке, или берутся из других Rails-приложений, использующих тот же сервер.

Rails создает представление вашей текущей схемы в файле db/schema.rb (по умолчанию), который обычно обновляется, когда запускается миграция. Файл schema.rb даже может быть сгенерирован, когда нет текущих миграций, через выполнение команды rake db:schema:dump. Частая ошибка — проверить новую миграцию в вашем исходном репозитории, но не обновить файл schema.rb.

Когда миграции выполняются слишком долго, разработчики не должны бояться очистить старую директорию миграции, сделать дамп новой схемы и продолжить с ней. Настройка новой среды разработки потребовала бы выполнения rake db:schema:load, а не rake db:migrate, на которую полагается большинство разработчиков.

Некоторые из этих вопросов также рассматриваются в руководстве по Rails.

Ошибка 10. Проверка конфиденциальной информации в репозитории исходного кода

Фреймворк Rails позволяет легко создавать безопасные приложения, защищающие от многих видов атак. Кое-что достигается с помощью секретного токена, который позволяет получить доступ к сессии браузера. Даже если этот токен хранится в config/secrets.yml , и этот файл считывает токен из окружения, отличного от продакшн-серверов — в последние версии Rails токен включен в config/initializers/secret_token.rb . Этот файл часто по ошибке включают в репозиторий вместе с остальной частью вашего приложения. Если это произойдет, тот, кто получит доступ в репозиторий, получит доступ к пользователям вашего приложения.

Таким образом, вы должны убедиться, что ваш файл конфигурации репозитория (например, .gitignore для пользователей git) исключает файл с токеном. Тогда ваши продуктовые сервера смогут забрать свой токен из окружения, отличного от них, или из механизма, как тот, что поставляет dotenv gem .

Итого

Rails — мощный фреймворк, который скрывает много нелицеприятных деталей, необходимых для построения надежного приложения. И хотя Rails-приложения намного быстрее, разработчики должны обратить внимание на потенциальные ошибки в коде и проектировании, чтобы убедиться, что их приложение легко расширяемое и его легко поддерживать.

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

Привет. Я использую Rails уже значительное время - 5 лет (это, по-моему, значительное). В этой статье я попробую подытожить свой опыт и ответить на вопрос: почему я все еще использую Rails и почему его должны (или не должны) использовать вы.

Для начала ответим на вопрос из заголовка. Действительно ли Rails популярен сейчас, в середине 2015 года?

Вот эта забавная таблица сравнений по критериям популярности репозитория на GitHub и количества вопросов на StackOverflow (https://hotframeworks.com/) говорит что Rails всё ещё в топе:

class Customer < ActiveRecord :: Base has_many :orders end class Order < ActiveRecord :: Base belongs_to :customer end

И это все. Это работает без единой строчки конфигурации. По умолчанию предполагается, что в базе у вас есть таблицы orders и customers . В orders есть внешний ключ с именем customer_id . Первичные ключи называются id . На этом все. Вы соблюдаете соглашения именования и все само работает. Теперь вы можете строить и выполнять SQL-запросы совершенно очевидным и естественным способом:

customer . orders #=> order . customer #=> customer

Окей, идем дальше. Маршрутизация запросов (routes). Это поразительно. Вы можете все, и очень многое из этого “всего” бесплатно. Но это если вы руководствуетесь соглашениями. Пример маршрута из документаци

resources :books

Благодаря магии Rails эта одна скромная строчка способна создать пачку маршрутов для CRUD:

$ bundle exec rake routes | grep book books GET /books(.:format) books#index POST /books(.:format) books#create new_book GET /books/new(.:format) books#new edit_book GET /books/:id/edit(.:format) books#edit book GET /books/:id(.:format) books#show PATCH /books/:id(.:format) books#update PUT /books/:id(.:format) books#update DELETE /books/:id(.:format) books#destroy

Опять-таки, по соглашениям именования у вас должен быть класс BooksController и аналогичные методы index/create в нём, т.е. books#index соответствует BooksController#index . Добавьте к этому ограничения (constraints), пространства имен (namespaces), модули (modules).

HTML-формы. Что тут можно улучшить? Нtml есть html, от него никуда не убежишь, но можно попытаться уменьшить боль. Пример создания формы из документации :

<%= form_for @article, url: {action: "create"}, html: {class: "nifty_form"} do |f| %> <%= f.text_field:title %> <%= f.text_area:body, size: "60x12" %> <%= f.submit "Create" %> <% end %>

Предполагается что @article это ActiveRecord модель, но по факту здесь может быть любой произвольный объект. В том числе, если использовать шаблон FormObject, здесь может быть объект абсолютно отвязанный от слоя ORM.

Миграции базы данных. Здесь все стандартно. Можно, просто и быстро.

Аутентификация пользователя и сопутствующий функционал - регистрация, вход, выход, восстановление пароля. Чтобы это все заработало, вам нужно воспользоваться одной из нескольких доступных библиотек: Devise, Authlogic итд. Вам надо добавить всего несколько стандартных строк для подключения.

Развертывание (deploy) приложения на сервер. Есть стандартное решение - capistrano. Пример стандартного скрипта с комментариями: (ссылка на gist).

# config/deploy.rb # config valid only for current version of Capistrano lock "3.4.0" set :application , "aircat" set :repo_url , "[email protected]:applabsservice/aircat.git" set :deploy_to , "/var/www/apps/aircat" set :git_shallow_clone , 1 set :deploy_via , :copy set :branch , "master" set :host , "127.0.0.1" set :user , "deploy" role :app , %w{[email protected]} role :web , %w{[email protected]} role :db , %w{[email protected]} namespace :db do desc "Make symlinks" task :symlink do on roles (:app ) do execute "ln -nfs #{ shared_path } /config/database.yml #{ release_path } /config/database.yml" end end end after "deploy:updating" , "db:symlink" # дальше идут другие callback"и для перезапуска веб-сервера

Что это дает? При каждом развертывании новая версия приложения копируется в отдельный каталог релиза, рядом с предыдущими. Запускаются миграции, идет компиляция/склейка/минификация статичных css/js файлов, и когда всё готово, веб-сервер переключается на каталог с новым релизом. В случае ошибки на любом из шагов можно просто вернуться на предыдущий релиз. Новый код запускается уже на обновленной базе. Есть нюанс, что во время миграций некоторое время с обновленной базой работает старый код. Но это тоже решается.

class Post < ActiveRecord :: Base has_attached_file :image , styles : { standard : "1280x1280>" }, default_url : "/images/:style/missing.png" validates_attachment_content_type :image , content_type : /\Aimage\/.*\Z/ has_attached_file :video end

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

post . image = File . read ("test.jpeg" ) post . save

Все, файл помещен в правильный каталог на диске. Если это картинка, её можно обрезать, cконвертировать, сжать. Сделать несколько вариантов разрешений парой магических строчек.

Локализация - да, есть как у всех, всё просто и стандартно.

Тестирование. В стандартной библиотеке Ruby есть фреймворк для unit-тестирования. В Rails из коробки есть поддержка функциональных и интеграционных тестов, но намного круче воспользоваться связкой RSpec для модульных тестов и Capybara + webdriver для интеграционных. Представьте - вы можете в интеграционных тестах запускать настоящий браузер, установленный в системе (например через Selenium Webdriver), или headless браузер на базе WebKit. Второй вариант пока что надежнее, стабильнее и быстрее.

Из минусов для разработки можно выделить следующее:

• Rails даёт вам соглашения. Вы следуете им. Ваш код лаконичен, красив, покрыт тестами, всё сделано по Rails-way. Но есть и обратная сторона. Вы получаете большую связанность компонентов, толстые контролеры или толстые модели. Rails предлагает шаблон MVC, но ничего сверх этого. Нет никакого стандартного слоя абстракции - это решение ложится на ваши плечи. Если вы заметили, что стандартные компоненты (views, models, controllers) уже перенасыщены несвойственной им логикой, вы должны что-то делать. Какие у вас варианты? Можете начать рефакторить, выносить логику в отдельные слои - об этом уже немало написано. Можно использовать Form-объекты, выносить сложный SQL в независимые объекты, отделить бизнес-логику от ORM/контроллеров.
• Документация для Rails и популярных библиотек отличная, но это всё равно не избавит вас от изучения их исходного кода, чтобы разобраться с упущенными в документации моментами. Иногда код скажет даже больше.
• Скорость развития инструментов и библиотек имеет очевидную обратную сторону - вам периодически придётся обновляться до последних версий. Это относится и к версиям Rails, и к библиотекам. Переход на другую мажорную версию библиотеки для тестирования может занять не один и не два дня. Возможен вариант, когда появляется какой-то удачный аналог используемой вами библиотеки. Ваша библиотека постепенно перестает развиваться и поддерживаться, и внезапно вы обнаруживаете, что она не работает в очередной версии Rails и придётся переходить на аналоги. Ничто из этого не специфично только для Rails, но в долгоживущем проекте вы с этим столкнетесь с большой вероятностью.

Когда вам нужен Rails?

• Вы разрабатываете обычное веб-приложение. Вы ожидаете, что проект будет жить долго. Вам нужно, чтобы инструмент продолжал развиваться и жить, нужна поддержка от сообщества или от какой-нибудь компании, возможность нанять специалиста. В таком случае, Rails - прекрасный выбор. Альтернатив хватает, выбирать есть из чего. Но вы все равно выберете Rails, ведь это по-прежнему модно;-)
• Вы предполагаете постоянное изменение требований и функционала, вектора развития проекта. У вас нет постоянной концепции продукта, она меняется и зависит от обратной связи с пользователями. Rails в этом случае отличный выбор.
• Вам нужно “быстрое прототипирование”. Rails до сих пор хорош для этого. Альтернативы, конечно же, найдутся, но Rails очень хорош и в этом.

Когда вам не нужен Rails?

• Вы отчётливо понимаете требования к проекту и функционалу. Вы не ожидаете быстрых изменений функционала. К примеру, у вас уже есть прототип или вы уже делали что-то очень похожее и можете сразу отливать архитектуру в бронзе.
• Вы ищете то, чего никогда не найдёте в динамически типизированном языке, - высокую (высочайшую) скорость работы и низкое потребление ресурсов сервера.
• У вас уже есть команда профессионалов которые хотят использовать другой фреймворк.

Ну вот и всё. В заключение я добавлю, что получаю большое удовольствие, используя Rails и Ruby. Это очень удобные инструменты, мягкие и податливые, как пластилин. В умелых руках они помогают создавать волшебные вещи.

Прошло около года с момента публичного дебюта Ruby on Rails в 25 июля, 2004. За этот довольно короткий срок, Rails превратилась из уже достаточно впечатляющей версии 0.5 в устрашающе-вдохновляющую, готовящуюся к выходу версию 1.0, которой удалось сохранить свою простоту использования и продуктивность, в то же время добавив будоражащий ум массив новых возможностей. Эта статья познакомит вас с компонентами грядущей версии Ruby on Rails 1.0 и постарается рассказать, о чём же собственно столько разговоров.

In this short time, Rails has progressed from an already impressive version 0.5 to an awe-inspiring, soon-to-be-released version 1.0 that managed to retain its ease of use and high productivity while adding a mind-boggling array of new features. This article introduces the components of the upcoming Ruby on Rails 1.0 and shows you what the fuss is all about.

Я не намереваюсь учить вас как использовать Rails для создания веб приложений. Для этого, вам скорей всего следует начать со статьи Rolling with Ruby on Rails . Эта статья, является введением и картой к огромному количеству возможностей Rails.

I don"t intend to teach you how to use Rails to write web applications. For that, you probably ought to start with Rolling with Ruby on Rails. This is an introduction and road map to the many features of Rails.

Высокая продуктивность и высокая скорость разработки

На уровне возможностей, Ruby on Rails не предлагает ничего нового. Существующие веб фреймворки уже всё это делали. В чём же тогда дело? Различие лежит в том, как это делает Ruby on Rails. Когда вы можете закончить простое веб приложение за дни вместо недель и более сложное за недели вместо месяцев, люди обращают на это внимание!

Это внимание было бы недолгим, если бы получавшиеся приложения были запутаны и их было бы тяжело поддерживать или расширять. К счастью, Ruby on Rails действительно облегчает правильные методы программирования, что приводит к хорошо сформированному и легко поддерживаемому коду.

Внимание также оказалось бы недолгим, если бы Ruby on Rails не имела глубины - то есть, если бы раз попробовав использовать её для чего-то сложнее самого простого веб приложения, вы сразу натыкались бы на стену, не имея возможности продолжить из-за ограничений системы. Опытные разработчики, которые знают толк во всемирной паутине и программировании не перестают повторять, что для Rails это не так. К примеру, автор Tomcat, Ant и Servlet API, James Duncan Davidson недавно написал:

The attention would also be short-lived if Ruby on Rails had no depth--that is, if once you tried to use it for anything beyond the simplest of web applications, you suddenly found yourself hitting a wall, unable to proceed due to inherent limitations. Experienced developers who know their way around the Web have repeatedly reported that this is not the case with Rails. For example, Tomcat, Ant, and the Servlet API author James Duncan Davidson recently wrote:

Rails это самая хорошо продуманная среда веб разработки которую я когда-либо использовал. И это за десять лет моей работы веб разработчиком. Я разрабатывал свои фреймворки, помогал разрабатывать Servlet API, и создал больше пары веб серверов с нуля. До Rails, никто раньше так не делал. Я не хочу сказать что они всё сделали правильно. Ни под каким видом она не совершенна. У меня есть несколько придирок к тому как всё собрано вместе. Но дело не в совершенстве. Дело в том, что Rails позволяет работать очень быстро, при том что есть глубина которая помогает вам двигаться вперёд. И у Rails это очень хорошо получается.

Rails is the most well thought-out web development framework I"ve ever used. And that"s in a decade of doing web applications for a living. I"ve built my own frameworks, helped develop the Servlet API, and have created more than a few web servers from scratch. Nobody has done it like this before. That"s not to say they got it all right. It"s by no means "perfect". I"ve got more than a few nits and picks about how things are put together. But "perfect" isn"t the point. The point is that it gets you up and going fast and has plenty of depth to keep you going. And Rails does that very well.

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

It may be hard to believe that this is possible without a significant downside. Fortunately, you don"t have to take my word for it (or anyone else"s). You can easily prove it to yourself in a day or less by going through a Ruby on Rails tutorial and then developing a modest web application of your own choosing. After all, seeing is believing! If you don"t want see yourself be amazingly productive, you can always watch someone else do it in the new Rails video.

Как Rails это делает?

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

Like a good recipe, Rails helps you achieve this new level of productivity by combining the right ingredients in the right amounts. Here are a few of the most important ingredients that make Rails what it is.

Ruby

Большая часть мощи Rails кроется в языке программирования Ruby. Уникальный дизайн Ruby делает легким создание языков для разных предметных областей и метапрограммирование. Rails пользуется этим на полную катушку.

Much of the power of Rails comes from the Ruby programming language. Ruby"s unique design makes it easy to create domain-specific languages and to do metaprogramming. Rails takes full advantage of this.

Полная реализация MVC

You can find more details in A Guide to Testing Rails.

Active Record

Active Record это часть Rails которая отвечает за автоматическую динамическую привязку таблиц вашей базы данных к объектам моделей. Это буква M в MVC, и это реализация слоя ORM в Rails.

Active Record is the part of Rails that handles the automatic mapping of your database tables to your runtime model objects. It"s the M in MVC, and it is Rails" implementation of an ORM layer.

Для самых распространённых случаев использования (и не таких уж распространённых), вам никогда не придётся видеть или писать SQL код для доступа к или обновления вашей базы. Цель Active Record - работать исключительно с реляционными базами данных; она не пытается абстрагироваться от использования SQL. Когда надо, Active Record облегчает использование ваших собственных SQL запросов, для тех сложных случаев где это необходимо. Но даже в таких случаях, часто можно обойтись без написания SQL кода вручную.

For all the common uses (and some of the not-so-common ones), you"ll never need to see or use SQL when accessing or updating your database. Active Record"s goal is specifically to work with relational databases; it does not try to abstract away its SQL usage. Active Record makes it easy to use your own custom SQL for those complicated cases where it is necessary. Even so, it is rarely needed.

Автоматическая привязка

Active Record автоматически привязывает таблицы к классам, строки к объектам (экземплярам класса модели), и поля к аттрибутам объекта. Например код:

Active Record automatically maps tables to classes, rows to objects (instances of the model classes), and columns to object attributes. For example:

Class Product < ActiveRecord::Base end

автоматически привязывается к таблице с именем products, такой как:

automatically maps to the table named products, such as:

CREATE TABLE products (id int(11) NOT NULL auto_increment, name varchar(255), PRIMARY KEY (id));

а также автоматически создаёт аттрибут name который вы можете использовать так:

which also automatically creates a name attribute that you can use like this:

My_product = Product.find(:first) STDOUT.print my_product.name my_product.name = "Название нового продукта"

Active Record использует правила плюрализации английского языка для привязки классов к таблицам. Имя класса модели состоит в единственном числе и пишется с заглавной буквы, а имя таблицы в множественном и в нижнем регистре. Вот несколько примеров:

Active Record uses English pluralization rules to map classes to tables. The model class name is singular and capitalized, while the table name is plural and lowercased. Examples include:

• Класс модели Invoice привязывается к таблице invoices.
• Класс модели Person привязывается к таблице people.
• Класс модели Country привязывается к таблице countries.
• Класс модели SecurityLevel привязывается к таблице security_levels.

• An Invoice model class maps to an invoices table.
• A Person model class maps to a people table.
• A Country model class maps to a countries table.
• A SecurityLevel model class maps to a security_levels table.

Соглашение о единственных/множественных числах выливается в довольно натурально читаемый код. Заметьте как разумна привязка в своём использовании правил плюрализации английского. Также обратите внимание, что имена классов используют CamelCase (правило Ruby), в отличии от таблиц, имена которых все в нижнем регистре со знаками нижнего подчёркивания между словами.

This singular/plural convention results in code that reads fairly naturally. Notice how this mapping is intelligent in its use of English pluralization rules. Also note that the class names use CamelCase (a Ruby convention), while the table names are all lowercase with underscores between words.

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

In cases where this does not work (such as interfacing with a legacy database with which you have no control over the names), you can also explicitly tell Active Record what name it should use.

There is a lot more to Active Record than I can cover here. To learn more, consult the Active Record API.

Action Pack

Action Pack реализует уровни контроллера и представления в Rails.

Action Pack implements both the view and controller part of Rails.

Шаблоны представления

Шаблоны представления формируют HTML который возвращается в ответе браузеру. Шаблоны являются файлами rhtml (HTML со встроенным Ruby) которые очень похожи на ASP или JSP файлы. Текст внутри <% %> это Ruby код который будет запущен, а текст внутри <%= %> это Ruby код который будет также запущен и результат запуска которого будет подставлен обратно в HTML.

View templates specify the HTML to return in response to a browser request. View templates are rhtml files (HTML with embedded Ruby) that are very similar to ASP or JSP files. Text within <% %> is Ruby code to execute, and text within <%= %> is also Ruby code to execute and substitute the results back into the HTML.

<% render_partial "invoices_by_customer" %>

По умолчанию, Rails попытается найти шаблон чьё имя совпадает с действием которое сейчас выполняется. Если например, Rails выполняет действие edit в вашем InvoiceController, тогда она попытается найти и вывести шаблон представления .../app/views/invoices/edit.rhtml .

By default, Rails will try to find a template whose name matches the currently executing action. If, for example, Rails executes an edit action in your InvoiceController, then it will attempt to find and render the view template .../app/views/invoices/edit.rhtml.

Вы можете также конструировать XML (или HTML) вывод в действии вашего контроллера. Это полезно, к примеру, для построения RSS лент или ответа на XML-RPC запросы. В следующем примере, xm это экземпляр класса XmlMarkup .

You can also build up XML (or HTML) output programmatically in your controller action. This is useful, for example, for building RSS feeds or responding to XML-RPC requests. In the following example, xm is an XmlMarkup object.

Xm.em("подчёркнутый") # => подчёркнутый xm.em { xmm.b("emp & bold") } # => emph & bold xm.a("A Link", "href"=>"http://onestepback.org") # => A Link xm.div { br } # =>

xm.target("name"=>"compile", "option"=>"fast") # => # ВНИМАНИЕ: порядок аттрибутов не сохраняется. xm.instruct! # xm.html { # xm.head { # xm.title("История") # } # xm.body { # xm.comment! "HI" # xm.h1("Заголовок") #

Заголовок

xm.p("параграф") #

параграф

} # } #

Роутинг URL

Запрашиваемый URL всегда привязывается к какому-то действию внутри контроллера. Контроллер это простой класс Ruby и каждое действие реализованное контроллером это публичный метод этого класса. По умолчанию, URL привязан к действию по следующей схеме:

An incoming URL always maps to some action within a controller. A controller is simply a Ruby class, and each action implemented by the controller is a public method within the controller class. The default mapping from URL to action method is (in "Rails-speak"):

/:controller/:action/:id

Это легче всего объяснить на примере. Если Rails получает URL http://myapp.com/invoices/show/37 , то она автоматически привяжет его к классу-контроллеру InvoicesController и к методу этого класса под именем show. Rails также передаст значение 37 в метод как часть хэша параметров под именем id. Хэш параметров содержит в себе значения полей запроса(взятых из URL) и данные элементов форм. Код может выглядеть следующим образом:

This is easiest to explain by an example. If Rails received the URL http://myapp.com/invoices/show/37 , Rails would route this to a controller class named InvoicesController and within that class to a method named show. Rails would also pass the 37 to the method as the id member of the parameter hash that also holds the values of query parameters and form fields. The code might look like this:

Class InvoicesController def show @invoice = Invoice.find(params[:id]) end end

Поскольку действия это методы сгруппированные внутри контроллера (вместо отдельных командных объектов), они могут легко разделять между собой вспомогательные методы.

Because actions are methods grouped within a controller (instead of separate command objects), they can easily share helper methods.

Если стандартный способ привязки URL вас не устраивает, вы можете с лёгкостью указать свои правила роутинга, даже используя регулярные выражения. Поскольку Rails реализует свой механизм URL роутинга, вам не надо связываться с Apache mod_rewrite и ваши правила роутинга будут работать одинаково на всех веб серверах.

If the default URL routing does not meet your needs, you can easily specify your own routing rules, even using regular expressions. Because Rails implements its own URL routing, you don"t need to mess with Apache"s mod_rewrite, and your routing rules will work the same under all web servers.

Правила роутинга URL в Rails это простой Ruby код. Вот пример:

Rails routing rules are Ruby code. Here is an example:

Map.connect "date/:year/:month/:day", :controller => "blog", :action => "by_date", :month => nil, :day => nil, :requirements => {:year => /\d{4}/, :day => /\d{1,2}/, :month => /\d{1,2}/}

С этим правилом роутинга становятся рабочими следующие адреса:

With this routing rule, the following URLs are valid:

Http://myblog.com/date/2005 http://myblog.com/date/2005/08 http://myblog.com/date/2005/08/01

Это правило разбивает URL содержащий дату, которую, блог может использовать для отображения постов за конкретное число. URL который совпадает с правилом будет привязан к классу BlogController и к методу by_date. Хэш параметров будет содержать значения для года из четырёх цифр(/\d{4}/ это регулярное выражение Ruby) и месяц и день из двух. Также, месяц и день не обязательны; если значение не присутствует, в хэше параметров будет сохранено значение по умолчанию - nil.

This rule decomposes a URL containing a date that, perhaps, a blog might use to display the postings for a particular date. A URL that matches this form will map to the BlogController class and the by_date method. The parameter hash will contain values for a four-digit year (/\d{4}/ is a Ruby regular expression), a two-digit month, and a two-digit day. Further, the month and day are optional; if no values are present, the parameter hash will contain the default value of nil.

The ActionController::Filters documentation has more details.

Помошники (helpers)

Помошники это умные методы (функции) которые помогают вашим шаблонам представления генерировать HTML. Они используют ваши объекты модели и классы контроллеров для создания HTML и в дальнейшем, избавят вас от траты лишнего времени и усилий. Конечно, это также значит что вам придётся писать меньше строк кода, но держу пари, об этом вы уже итак догадались.

Helpers are smart methods (functions) that help your view templates generate HTML. They know to use your model objects and controller classes to create just the right HTML and, in the process, save you a lot of time and effort. Of course, this also means you write fewer lines of code, but I bet you already guessed that.

Вы можете создавать своих собственных помошников, но как вы могли догадаться несколько помошников поставляется встроенными в Rails. Помошник link_to, например, генерирует тэги ссылок которые ссылаются на контроллеры и действия. Пример:

You can write your own helpers, but as you might expect, several come built into Rails. The link_to helper, for example, generates anchor tags that create links to controllers and actions. For example:

<%= link_to "Помощь", { :action => "help" } %>

creates a link to the help action (method) in the current controller (whatever controller is handling the current request). The text of the link (what the user sees) is Help.

<%= link_to "Содержание справки", { :controller => "help", :action => "index" } %>

This creates a link to the index method in the HelpController class. The text of the link will be Master Help Index.

<%= link_to "Удалить этот счёт", { :controller => "invoices", :action => "delete", :id => @invoice.id }, :confirm => "Вы действительно хотите это удалить?" %>

Это создаст ссылку на метод delete в классе InvoiceController, и передаст параметр id (в качестве указателя на то, какой счёт нужно удалить). Здесь также используется специальная опция confirm которая создаёт всплывающее окно подтверждения через JavaScript.

This creates a link to the delete method in the InvoicesController class, and passes an id parameter (presumably the ID of the invoice to delete). This also uses a special confirm option that creates JavaScript to pop up a confirmation dialog letting the user continue or abort.

Существует большой набор помощников для создания форм просмотра и обновления значение объектов ваших ActiveRecord моделей, то есть -- для значений в вашей базе данных. Предположим что в вашей базе данных есть таблица people со столбцами для имени, пароля, описания и булева значения определяющего женат человек или холост (ОК, довольно странная табличка вышла:). Вот часть шаблона с примером тэгов формы которые можно было бы использовать. (Допустим что переменная @person содержит объект класса Person, считанный из строки в таблице people.)

There is a substantial set of helpers for creating form fields to display and update values in your Active Record model objects, which effectively means values in your database. Assume that your database has a people table with columns for the name, the password, a description, and a Boolean value to indicate whether the person is single or married (OK, so this is a strange table--just humor me). Here"s a partial view template with a sampling of form tags that could be used. (Assume that the variable @person contains a person object read from a row of the people table.)

Имя: <%= text_field "person", "name", "size" => 20 %> Пароль: <%= password_field "person", "password", "maxsize" => 20 %> Холост?: <%= check_box "person", "single" %> Описание: <%= text_area "person", "description", "cols" => 20 %>

Данный код генерирует следующий HTML ответ:

Имя: Пароль: Холост?: Описание: <%= @person.description %>

Есть помощники для создания тэгов option для списков select из набора строк считанных из базы данных; помощники для работы с датами, числами и валютой; и много других.

There are helpers to create the option tags for a select list from a collection of rows read from the database; helpers for working with dates, numbers, and currency; and much more. There are different categories of built-in helpers, in several actual files. To learn more about them, see:

AJAX и JavaScript помощники

Rails включает в себя JavaScript библиотеку Prototype для реализации своей поддержки AJAX, визуальных эффектов и drag-n-drop возможностей.

Rails integrates the Prototype JavaScript library to implement its browser-side Ajax support, visual effects, and drag-and-drop abilities.

Модель того, как Rails реализует AJAX операции проста и надёжна. Как только браузер обработал и отобразил первоначальную страницу, различные действия пользователя могут вызвать либо отображение новой страницы (как в традиционных веб-приложениях) либо инициировать AJAX действие:

Rails has a simple, consistent model for how it implements Ajax operations. Once the browser has rendered and displayed the initial web page, different user actions cause it to display a new web page (like any traditional web app) or trigger an Ajax operation:

1. Срабатывает триггер. Это может быть кликом пользователя на кнопку или ссылку, изменение данных в форме или поле, или просто временный триггер (на основе таймера).
2. Клиент асинхронно отсылает данные ассоциированные с триггером (поле или целую форму) к действию-обработчику на стороне сервера через XMLHttpRequest.
3. На стороне сервера действие-обработчик выполняет какие-то действия над данными и возвращает HTML фрагмент в качестве ответа.
4. JavaScript на стороне клиента (код генерируется Rails автоматически) принимает этот HTML фрагмент и использует его для обновления конкретной части HTML текущей страницы, часто фрагмент подставляется содержимым в тэг
   .

1. A trigger action occurs. This could be the user clicking on a button or link, the user making changes to the data on a form or in a field, or just a periodic trigger (based on a timer).
2. The client sends data associated with the trigger (a field or an entire form) asynchronously to an action handler on the server via XMLHttpRequest.
3. The server-side action handler takes some action based on the data, and returns an HTML fragment as its response.
4. The client-side JavaScript (created automatically by Rails) receives the HTML fragment and uses it to update a specified part of the current page"s HTML, often the content of a
   tag.

Вся прелесть в том, как просто Rails позволяет реализовать всё это в вашем веб-приложении. Следующий простой пример добавляет новые элементы в список:

The real beauty is how easy Rails makes it to implement all of this in your web application. The following simple example adds new items to a list:

<%= javascript_include_tag "prototype" %>

Добавить к списку с помощью AJAX

<%= form_remote_tag(:update => "my_list", :url => { :action => :add_item }, :position => "top") %> Текст нового элемента: <%= text_field_tag:newitem %> <%= submit_tag "Добавить элемент через AJAX" %> <%= end_form_tag %>

• Начальный элемент... добавьте ещё!

The Prototype library also provides the Rails developer with a wealth of browser-side visual effects. Script.aculo.us provides documentation and live demos of the Prototype library effects. Prototype also lets you easily add drag-and-drop features to your web application. Script.aculo.us also has live demos and documentation for Prototype"s drag-and-drop support.

Макеты (Layouts)

Макеты позволюят вам указать набор основных элементов для отображения на каждой странице выдаваемой контроллером. Это обычно полезно для вывода общей шапки, низа и боковых панелей. По умолчанию, Rails смотрит в свой каталог layouts в поисках rhtml файла чьё имя совпадает с именем контроллера. Шаблон макета может выглядеть вот так:

Layouts let you specify a common set of display elements for every page rendered by a controller. This is typically useful for common headers, footers, and sidebars. By default, Rails looks in its layouts directory for an rhtml file whose name matches the controller"s name. A layout template might look like this:

Шапка для этого макета

<%= @content_for_layout %>

Низ этого макета

Rails подставит HTML который сгенерируется действием в этот макет, в то место где написано @content_for_layout.

Rails will substitute the HTML that an action renders into the above layout where it says @content_for_layout.

Контроллер также может прямо указывать какой макет следует использовать для всех его действий. Это упрощяет задачу использования одного макета для нескольких контроллеров. Вы можете менять шаблон макета даже динамически, в режиме runtime. Например, использовать разные макеты для пользователей вошедших в систему и для анонимных посетителей.

The controller can also directly specify the name of the layout template to use for all its actions. This makes it easy to use the same layout for multiple controllers. You can even dynamically choose a layout template at runtime. For example, you could use one layout for logged-in users and a different one for anonymous users.

To learn more about layouts, see the ActionController::Layout documentation.

Partials и компоненты

Компоненты и partials (части, отрывки. прим.пер.) позволяют вам разделить ваши шаблоны представления на модули.

Components and partials allow you to modularize your view templates.

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

Шаблоны partials всегда имеют знак нижнего подчёркивания (_) перед названием их файла, чтобы было легче отлечить их от полных шаблонов.

The simplest are partials, which allow you to extract a common piece of a template into a separate file and then render it from many other templates (or many times within a single template). Partial templates always have a leading underscore on their filenames to distinguish them from full templates.

Типичный пример использования partials это отображение массива (или другой коллекции) элементов.

A typical use of a partial is for rendering a collections of items.

<% for ad in @advertisements %> <%= render:partial => "adview", :locals => { :item => ad } %> <% end %>

Это отобразит шаблон partial _adview.rhtml несколько раз (по разу на каждый элемент массива @advertisments). Для каждого отображения, Rails будет передавать в _adview.rhtml локальную переменную с именем item которая содержит объект ad.

This renders the partial template _adview.rhtml multiple times (once for each ad in the collection @advertisements). For each rendering, Rails will pass _adview.rhtml a local variable named item that contains the ad object to use.

As with Active Record in the previous section, there is a lot more to Action Pack than I can cover here. To learn more, look at the Action Pack API.

Action Mailer

Action Mailer это простая технология для отправки и приёма email в вашем веб-приложении. Вот метод для отправки email с вложением:

Action Mailer is a simple facility for sending and receiving email in your web application. Here"s a method that sends an email with an attachment:

# отправляем email с вложением def signup_notification(recipient) recipients recipient.email_address_with_name subject "Информация о новом аккаунте" from "[email protected]" attachment:content_type => "image/jpeg", :body => File.read("an-image.jpg") attachment "application/pdf" do |a| a.body = generate_your_pdf_here() end end

To learn more, see the Action Mailer API, and Chapter 19 of the book Agile Web Development with Rails.

Action Web Service

Action Web Service реализует серверную поддержку для протоколов веб-служб SOAP и XML-RPC, позволяет просто создавать свои API и публиковать их через WSDL.

Action Web Service implements server-side support for the SOAP and XML-RPC web service protocols and makes it easy for you to create web service APIs and publish them via WSDL.

This snippet shows only two of the seven API methods defined in this class by Typo. To learn more, see the Action Web Service Manual.

Мысли о разделении

Обычно можно разделить фреймворки для создания веб-приложения и разработчиков которые их используют на две отдельных категории. В одном конце спектра находятся фреймворки-тяжеловесы для "серъёзных" программистов, на другой -- лёгкие, простые для использования фреймфорки для любителей "поиграть." Каждая из этих групп чаще всего относится друг к другу без всякого уважения.

You can usually divide web application frameworks and the developers who use them into two distinct categories. At one end of the spectrum, you have the heavy-duty frameworks for the "serious" developers, and at the other end you have the lightweight, easy-to-use frameworks for the "toy" developers. Each of these groups generally regards the other with disdain.

Одна из самых интересных вещей в том, что Rails привлекает разработчиков из обоих лагерей. Высококлассные разработчики устали от повторяющейся, низкопродуктивной рутины которую они должны терпеть, в то время как разработчики помельче устали сражаться с кашей из неподдерживаемого кода когда их приложение переходит выходит из разряда простых. Обе эти группы считают, что Rails снимает значительное количество их проблем. Я не знаю как вам, но мне это кажется замечательным фактом.

One of the most interesting things is that Rails is attracting developers from both camps. The high-end developers are tired of the repetitive, low-productivity routine that they have been forced to endure, while the low-end developers are tired of battling a mess of unmanageable code when their web apps move beyond the simple. Both of these disparate groups find that Rails provides sustainable relief for their pain. I don"t know about you, but I find this quite remarkable!

На данный момент, Ruby on Rails занимает всего-лишь маленький процент среди проектов веб-разработки. Однако она быстро нагнетает интерес вокруг себя, и многие уважаемые лидеры среди разработчиков ПО уже пробуют использовать Rails и публично восхваляют её.

At the moment, Ruby on Rails barely captures a tiny percentage of web development projects. Yet it is rapidly gaining mind share, and many respected software development leaders have been testing the waters with Rails and publicly singing its praises.

Возможно настало время вам тоже попробовать Rails, чтобы самому убедиться о чём же собственно весь шум.