Сегодня в интернетах я нашел историю о том, как некто Джеймс Фенд учился 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. Вопросы, предложения? Свяжитесь с нами.

Что такое 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. Надеюсь вас заинтересовало, и в веб мире скоро появиться еще один крутой рубист!

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

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

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

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

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

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

Важно понимать, что Rails предлагает не только стабильный и зрелый стек технологий и экосистему. Он предлагает постоянное развитие. Rails привносил и популяризировал много удачных решений и подходов. Он повлиял на многие фреймворки, иногда даже очень сильно. Просто вбейте в google "rails like + language". Rails-like фреймворки росли как грибы после дождя для многих популярных платформ - Java, Scala, NodeJs, PHP и даже Erlang. Вообще вся экосистема Ruby/Rails оказала влияние на инструменты разработки на других платформах. Инструменты развертывания приложений, пакетные менеджеры, менеджеры зависимостей, шаблонизаторы и препроцессоры. Если вы хотите быть на острие веб-технологий и не собираетесь ждать, пока это портируют на вашу платформу, тогда Rails - ваш выбор. Постоянное развитие, функциональность и помощь сообщества делают Rails отличным и надежным инструментом.

Что может предложить стек Ruby/Rails разработчику

Одна из особенностей подхода Rails это подход Convention over configuration. На практике это означает, что пока вы следуете соглашениям, вы избавлены от конфигурирования и настройки. Во всех компонентах и слоях абстракций. Если какое-то соглашение вам не подходит - окей! - у вас всегда есть способ настроить всё под себя. Фреймворк скрывает от вас сложность проблем и пока вы следуете соглашениям, все работает как по волшебству. Сложности начинаются когда соглашение вам не подходит.

Rails это удивительно модульный и настраиваемый инструмент. У вас есть штатный (предусмотренный разработчиками) способ расширить/переопределить поведение тех или иных компонентов. Вы можете встроиться в процесс отправки писем и модифицировать письмо. Например, вам нужно изменить тему письма так, чтобы на тестовом сервере все письма приходили с постфиксом "". Вам надо поддерживать визуальные темы для веб-страниц и динамически определять путь, откуда будут браться html-шаблоны? Легко - вам нужно просто переопределить отвечающий за это компонент (path resolver). Вам надо выполнять какой-то служебный код до начала обработки запроса вашим кодом? Встраиваете свой middleware в очередь стандартных.

Каждый, кто сталкивался с выбором фреймворка или стека технологий, в конце концов приходил к какому-то чек-листу возможностей, и выбор делался исходя из того, поддерживает конкретный фреймворк ту или иную возможность. Давайте посмотрим, что вы получаете, выбирая Rails. Вы получаете ORM - ActiveRecord. Как можно догадаться, используется одноименный шаблон доступа к данным. Вашу жизнь сильно облегчат принятые соглашения. Вам не надо ничего конфигурировать. Пока вы руководствуетесь стандартными соглашениями, вы не напишите ни строчки конфигурации (я вру, конечно, вы всё равно должны сконфигурировать доступ к базе данных, указать username, password итд). Пример классов-моделей, они представляют конкретные таблицы базы данных из документации:

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
PUT /books/:id(.:format) books#update
DELETE /books/:id(.:format) books#destroy

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

Продолжение можно найти