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

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

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

Я являюсь новичком в Ruby, тем не менее я имею достаточный опыт программирования на PHP. От того, чтобы я стал php-гуру меня спас один мой друг — опытный программист на php, Python, Ruby, который и посоветовал мне Ruby. Я долго сомневался, а стоит ли браться за изучение чего-то нового, отправлять те знания и опыт, которые у меня уже имеются в топку и заниматься изучением нового языка программирования. Тем не менее аргументы в пользу Ruby и Rails были очень убедительными и вот я стал Рубистом. В помощь себе и другим людям желающим изучить Ruby и Rails я создал блог , надеюсь он сослужит добрую службу всем новичкам.Кстати, для желающих изучить работу в Rails я начал готовить , пока что на основе переводных статей.

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

Что такое Ruby on rails и почему его так любят.

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

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

7 китов совершенства ruby on rails

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

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

Второй, Ruby on Rails использует MVC

MVC - это архитектурный шаблон (паттерн) который предусматривает разделение кода приложения на три части: Model (модель), View (представление) и Controller (контроллер).

Модель содержит математическую логику приложения, здесь указываются ассоциативные связи между моделями, различные callback"и и основной код приложения.
Представления используются для отображения информации пользователю, представлением является, графический интерфейс приложения или веб-интерфейс веб-приложения. Здесь различные html формы, css стили и javascript.
Контроллер занимается связыванием модели с представлением и обработкой запроса пользователя приложения. Здесь вы с помощью раутов(routes) настраиваете маршрутизацию вашего приложения.
Использование MVC позволяет писать более чистый и структурированный код, что значительно ускоряет разработку и при этом облегчает поддержку приложения.

Третий, Ruby on Rails использует CoC
CoC - Convention over Configuration (Соглашение превыше настройки) - вся идея состоит в том, что по умолчанию фреймворк уже отлично настроен. Ruby on Rails поставляется с набором крайне удобных соглашений, которые позволяют начинать разработку приложения сразу же после установки Ruby on Rails и создания нового проекта. При необходимости можно изменить настройки по умолчанию (они то и называются соглашением) и использовать свои, однако это, как правило, не только является лишним, но и зачастую вредным.

Четвертый кит, DRY
DRY - Don’t Repeat Yourself (Не повторяйся!) - еще один принцип разработки положенный в основу веб-фреймворка Ruby on Rails и самого языка ruby. Этот принцип предписывает разработчику выявлять в коде повторяющиеся фрагменты и выносить их в отдельные методы, классы или модули в зависимости от ситуации. В Ruby on Rails этот принцип проявляется во многих местах, что позволяет писать меньше кода, меньше тестов и легче поддерживать разработанный код. Например в представлении доступны к использованию различные partial"ы - это шаблоны для повторения кода, которые просто вызываются в коде например для Форм. Это не только улучшает читаемость кода, но и добавляет гибкость к изменению или добавлению новой информации.

Пятый кит это CRUD

CRUD - create, read, update, delete - «создание, чтение, обновление, удаление») методология используемая для создания контроллеров. Использование стандарта, с помощью которого вы можете четко определить экшены контроллеру для полной манипуляции с любым объектом. Также вы можете без проблем дополнить своими экшенами.
Также в rails используются не только POST и GET запрос, а такие как PUT и DELETE. Давая вам больше возможности манипулирования данными

Шестой кит ORM

ORM (object-relational mapping) - технология программирования, которая помогает работать с базой данных на языке программирования, не используя различный sql языки для манипуляции с базой данных. Здесь использует объектно-ориентированное программирование на языке ruby.
Вся идея в том, что таблица является классом, ее строки это объекты, столбцы - свойства объектов.
Методы классов выполняют операции над таблицами.
Методы объектов выполняют операции над отдельными строками.

Седьмой кит haml sass/less
Идея использовать упрощенные и более функциональные языки такие как haml и sass/less. Которые увеличивают читаемость кода, делая разработку наиболее удобной и автоматически интерпретируются в своих родителей html и css.

А также существует еще множество плюсов, например установка различных дополнительных библиотек (gem"ов) в одну команду. Отличный бесплатный Heroku, дающий вам наблюдать за работоспособностью вашего локального приложения в продакшене на удаленном облаке. Различные готовые решения, из документации Ruby on Rails. И возможность генерации кода, для более быстрой развертывания веб-приложения.

Целью было представить основные возможности фреймворка Ruby on Rails. Надеюсь вас заинтересовало, и в веб мире скоро появиться еще один крутой рубист!

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

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

Разработчики

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

Основные преимущества Ruby / Ruby on Rails

Скорость разработки

Основным преимуществом языка программирования Ruby и фреймворка Ruby on Rails считается скорость разработки. Практика показывает, что скорость разработки проектов на RoR увеличивается на 30–40 процентов по отношению к любому другому языку программирования или фреймворку. В первую очередь прирост скорости разработки определяется обширным набором готовых к работе штатных инструментов RoR, колоссальным набором готовых решений в сообществе, языку Ruby и простоте программирования на нем.

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

Культура и стандарты

Ruby on Rails - это фреймворк. Зачастую фреймворк не позволяет вам самодеятельность. Конечно же, в Ruby on Rails можно «изобрести свой велосипед» и программировать в любых направлениях, не опираясь на стандарты; но зачастую этого не требуется. Стандарты размещения файлов в проекте, стандарты написания кода в проекте, общие правила программирования в Ruby on Rails сильно структурируют любой проект. За счет этого проект становится читаемым. Вхождение в проект новичков происходит очень быстро. Опыт показывает, что любой новичок в проекте в первый же день работы делает свои первые полезные правки. За счет этого не считается большой проблемой, если разработку проекта изначально вела одна команда программистов, а поддержку проекта или доработку - совершенно другая. Проект на RoR априори понятен любому разработчику.

Некоторые приятные инструменты разработки

Тестирование

При разработке любого крупного проекта встает резонный вопрос. Как и кто будет тестировать проект? Не всегда есть средства и желание создавать целые отделы тестирования, к тому же хочется автоматизировать этот процесс. В отличие от других фреймворков, в составе RoR есть отличные средства автоматизированного тестирования. В других языках программирования и фреймворках штатных средств тестирования нет. Конечно, есть сторонние разработки, позволяющие организовать автоматическое тестирование проекта на PHP, но они не ставятся “из коробки” и об их использовании программисты чаще не задумываются. В проекте на Ruby on Rails, в идеале, код проекта не пишется до тех пор, пока под этот код не написаны тесты. RoR идеология предполагает изначальное использование методов BDD (Behavior Driven Development) или TDD (Test Driven Development).

Кеширование

Кеширование проектов - один из важнейших этапов разработки крупного интернет–проекта. В PHP имеются различные варианты кеширования данных. Эти варианты и инструменты прикручиваются, пристраиваются, приделываются, прикрепляются сбоку. До сих пор в сообществе PHP нет единого мнения: что лучше использовать, как лучше кешировать данные, какими инструментами пользоваться.

Ruby on Rails в его базовой комплектации имеет штатные средства кеширования данных. На старте предоставляются инструменты, позволяющие реализовать кеширование данных на проекте. Вы можете кешировать целые страницы или же блоки кода. Можете кешировать результаты запросов и ActiveRecord–модели. Кешировать можно как при помощи memcached или redis, так и другими средствами. Для реализации кеширования на Ruby on Rails проекте вам в 95 процентах случаев не потребуется ничего кроме уже готовых и штатных решений.

Локализация

Часто встречается ситуация, когда кто-то сделал проект, а потом неожиданно понимает, что для продолжения развития проекта необходима английская версия. Разработчики на PHP при этом начинают заводить разговоры о том, что это не было предусмотрено заранее, что это долго и крайне трудоемко. Давайте, дескать, откроем параллельный проект, который будет полной копией этого, и переведем его.

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

Роутинг (красивые урлы или ЧПУ)

Зачастую во многих PHP проектах мы можем видеть картину, когда адрес определенной страницы огромен и непонятен. В Ruby on Rails есть штатная возможность гибко настроить ваш роутинг, вид адресов, названия основных разделов. Есть возможность быстро изменить адреса в одном месте без необходимости изменения этого адреса во всем проекте. В сообществе RoR–разработчиков активно используются идеология REST. Адреса страниц в проектах на Ruby on Rails всегда понятны, красивы, прекрасно понимаются поисковиками, просты.

Валидации

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

Миграции и работа с базой данных

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

Безопасность

Ruby on Rails по умолчанию сильно заточены под безопасность проекта. При использовании инструментов RoR исключены SQL инъекции и XSS атаки. Все входные параметры экранируется по умолчанию. Выводимые переменные в шаблонах также экранируются, только если вы не указали обратной опции. У разработчика нет шансов допустить ошибки безопасности (не без исключений, разумеется).

Деплой

В среде Ruby on Rails существует много удобных и приятных инструментов. В том числе инструменты, которые применяются в процессе деплоя. Например, используя Capistrano, выкатка новой версии приложения на боевой сервер (или несколько серверов) потребует одной команды в консоли: cap deploy.

Дополнительные принципы разработки на Ruby / Ruby On Rails

Системы контроля версий

При разработке любого Ruby on Rails проекта подразумевается использование известных систем контроля версий. Использование git, как говорится, «добровольно–принудительно», так как многие системы автоматического развертывания проекта на «боевых» серверах не работают без них. Программисты на RoR изначально, при изучении платформы, вынуждены осваивать git, так как многочисленные примеры кода в документации подразумевают использования данных систем контроля версий. Во многом из за этого неопытным новичкам проще начать изучать PHP и не трогать Rails до достижения определенного уровня понимания веб–разработки как таковой и ее принципов.

Системы управления проектами/таск менеджеры

Ruby on Rails был изначально разработан для того, чтобы реализовать систему управления проектом - Basecamp. Также на RoR был создан Redmine (популярная и бесплатная система управления проектом). Поэтому при работе над Rails проектами «добровольно–принудительно» использование таких систем. Все системы интегрируются с системами контроля версий, что позволяет более гибко регулировать процессы разработки проекта.

Мифы и предрассудки

Разработчиков на Ruby on Rails нет

Начнем с того, что разработчики есть, но они менее многочисленны, нежели разработчики на PHP. Это связано с разным порогом входа в освоение технологии (обычно в Ruby попадают люди после нескольких лет PHP), что говорит о качестве разработчиков. Хороших разработчиков одинаково мало во всех технологиях.

Разработчики на Ruby on Rails стоят очень дорого

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

«Рельсы» не масштабируются

Это самое главное заблуждение тех людей, которые не пробовали писать на RoR серьезных проектов. Ruby on Rails прекрасно масштабируются. Посмотрите на GitHub, Groupon, Basecamp и др. Все эти проекты написаны на Rails и все эти проекты имеют любые другие проблемы, но только не проблемы масштабирования (чаще всего проблемы с производительностью баз данных).

Ruby медленнее чем PHP

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

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

Несколько цитат известных в Ruby-сообществе людей

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

« Ruby on Rails и PHP  - это как Apple Macintosh и PC. Нас мало, но мы элита. Ruby on Rails и PHP - это культура против хаоса. PHP позволяет вам построить свой велосипед из частей других велосипедов, не ориентируясь при этом ни на какую «велосипедную библию». RoR–разработчики более продвинуты, чем любой школьник, которому достаточно прочитать одну книжку и говорить, что он знает PHP. Наш плюс в том, что при всем бардаке PHP, мы более организованны».

«Мой опыт показывает, что в программах, написанных на Ruby, меньше строк, чем в аналогичных программах на языках Java и C#. А чем меньше кода, тем проще его сопровождать, что немаловажно, так как затраты на долгосрочное сопровождение считаются самой крупной стоимостной составляющей успешных программных проектов. Отладка небольших программ занимает меньше времени даже без “навороченных” инструментов отладки».

«Почему опытные разработчики корпоративных приложений вроде меня влюбляются в Ruby и Rails? Для удовлетворения предъявленных требований сложность решений, создаваемых с применением технологий Java и Microsoft, просто неприемлема. Излишняя сложность не позволяет отдельному человеку понять проект в целом и сильно усложняет коммуникацию внутри команды. Из–за упора на следование паттернам проектирования и зацикленности на производительности на этих платформах пропадает удовольствие от работы над приложением».

« Ruby on Rails , не прибегая к насилию, принуждает программистов писать более структурированный код. Код на «рельсах» даже без документации можно прочитать и осознать. Проект при этом проще поддерживать различным командам разработчиков. Проект не привязывается к определенному разработчику или команде. У следующих разработчиков проекта не возникает такое знакомое всем желание как “Ничего не понятно! Давайте все перепишем и переделаем по-нашему”».

« Ruby  - красивый язык. Кодировать на Ruby приятно. Все мои знакомые, перешедшие на Ruby и Rails, говорят, что стали счастливее. Главным образом, по этой причине Ruby и Rails изменяют статус кво, особенно в области разработки корпоративных приложений. Прежде чем стать приверженцем Rails, я привык работать над проектом с нечеткими требованиями, не имеющими отношения к реальным потребностям. Я устал выбирать между конкурирующими платформами и интегрировать их между собой, устал писать уродливый код. А Ruby - динамический, высокоуровневый язык. Код на Ruby проще читать и писать, поскольку он более естественно отображается на конкретную предметную область и по стилю ближе к естественному человеческому языку. Удобство восприятия имеет массу преимуществ не только в краткосрочной, но и в долгосрочной перспективе, поскольку программа передается в промышленную эксплуатацию и должна быть понятна программистам сопровождения».

« В сообществе Rails нет места принуждению. David Heinemeier Hansson выбрал язык, который доставлял ему радость. Платформа Rails родилась из кода, который представлялся ему красивым. Это и задало тон общения в сообществе Rails. Все в мире Rails субъективно. Человек либо приемлет что–то, либо нет. Но между теми, кто приемлет, и теми, кто не приемлет, нет злобы, а лишь кроткая попытка убедить».

«В начале своей карьеры веб–разработчика, я долго программировал на PHP. Как и любой программист, я дошел до того, что стал писать собственную CMS. Меня постоянно не устраивали те средства, которые предоставляет мне PHP и я придумал свой собственный небольшой фреймворк. В собственном фреймворке я реализовал все так, как мне было удобно. Какого же было мое удивление, когда я увидел Rails. Я понял, что Ruby on Rails очень похож на мой фреймворк, следовательно, в нем реализовали и допилили все то, чего мне так не хватало в PHP. Прибавим к этому огромное сообщество, которое постоянно обновляет рельсы - получаем инструмент, в котором просто удобно и хорошо делать любые веб–проекты. Свой фреймворк я бросил и с радостью перешел на RoR. Считаю, что Ruby on Rails делает программиста счастливее».

Алексей Дмитриев: Здравствуйте. Меня зовут Алексей Дмитриев, и я занимаюсь веб-разработкой последние лет 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 не поможет. Кроме того, данный язык удобно использовать если важен такой фактор, как скорость разработки.