4 главных аналога Ruby on Rails


Содержание

Почему стоит учить Ruby On Rails в 2020 году

David Heinemeier Hansson на quora ответил на вопрос, почему стоит изучать Ruby on Rails в 2020 году. Тема бесспорно актуальна, поэтому решил сделать перевод. Далее, вольный перевод, со слов Дэвида.

По тем же причинам, что и в 2004 году. Много всего изменилось, но большинство осталось все тем же. Пока мы наблюдаем за значительным прогрессом в мире Javascript, мы также видим уменьшение сложности, которую Rails предлагает с самых первых дней. Раньше сложность была выбором мира Java, но жалобы уж сильно аналогичны тем, которые выдвинуты против Javascript сегодня. Эти люди тратят часы, если не дни, просто набрасывая каркас приложения. Настраивая базовую конфигурацию. Собирая и cherry-пикая код из множества библиотек и фреймворков создавая свою собственную архитектуру.

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

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

Я думаю, дело в том, что основополагающая идея Rails чужда естеству большинства программистов. Избегая большого количества вариантов и принимая соглашения и опыт сообщества в большинстве вопросов web разработки вы в конечном итоге становитесь лучше.

В любом случае, это большая идеологическая привлекательность Rails. Я расписал принцип convention over configuration шире, показал the a la carte/omakase конфликт, показал привлекательность целостных систем и другие не менее важные вещи в доктрине Rails

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

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

Как я уже говорил выше, Rails преследует невероятно амбициозную цель. Главной задачей full-stack разработки лежит в соединении каждого куска, необходимого для работы с базой данных или NoSQL хранилищем с бизнес логикой, написанной на Ruby. Через набор контроллеров, которые предоставляют доступ к этой логике с помощью REST, заканчивая генераций HTML, который в конечном итоге предоставляется пользователю. Но, этот самый последний шаг (генерация HTML) не является тем, на чем фокусируется Rails.

По этому, если вы считаете, что будущее за фронтенд разработкой, React, Angular или что-то еще, то вам все равно все еще нужен Rails. Фронтенд всего лишь основанный на HTML/Javascript интерфейс пользователя, который все равно нужно соединить с реальной логикой. Сохранение данных в базу, расчет разных штук, выполнение производительных задач, отправка емейлов или пуш нотификаций — все это задачи бекенда, которые нужно решать в реальных приложениях.

И это то, в чем действительно хорош Rails. Важно то, что происходит после POST или PUT или GET запроса. Как я уже сказал, Rails является full-stack фреймворком и конечно у него есть инструменты для генерации HTML. Более того, у нас есть невероятно продуктивные решения в этой области, например Turbolinks или SJR. Но, если Вам кажется что эти решения Вам не подходят, Rails также имеет мощные решения для генерации JSON из коробки.

В любом случае, это очень длинная речь для двух основных вещей, которые делают Rails привлекательным в 2020году:

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

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

Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit.

Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit.

Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit.

Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit.

Ruby on Rails за 4 месяца

Изучение ruby для новичков. С полного нуля до собственных готовых сайтов на ruby on rails. Пошаговое изучение с самых основ.

пятница, 14 сентября 2012 г.

Ассоциации в Ruby on Rails: полиморфные ассоциации

Разбираем следующий скринкаст Полиморфные ассоциации
Полиморфные ассоциации это специальный тип ассоциаций когда несколько разных таблиц связаны через одну. Допустим у нас есть таблица комментарии. Комментарии могут быть как к товарам, так и к записям блога. Т.е. две таблицы товары и записи блога, связаны с таблицей комментарии через полиморфную ассоциацию. Связь достигается путем того, что в поле id хранится либо id записи блога, к которой оставлен комментарий, либо id товара. Реализуем это на практике. Создадим модель комментарии

Создадим модель для блога

Пропишем связь в моделях

И в модели blogpost

В модели comment пропишем
Протестируем в консоли

В этом примере мы

    Находим товар с >

Ruby on Rails / Часть 1

Вы, наверное, часто слышали о том, насколько Ruby on Rails повышает производительность и качество труда веб-программиста. Честно говоря, чтобы полностью понять из-за чего вся эта шумиха нужно прочитать «Agile Web Development with Rails». Однако, в небольшой серии статей я всё таки попытаюсь дать общее представление о том, что же такое эти «рельсы» и чем они так хороши.

Очень краткая история Ruby и RoR

Ruby — открытый объектно-ориентированный и интерпретируемый язык программирования — был впервые выпущен в 1995 году японским программистом Юкихиро Матцумото (Yukihiro Matsumoto). Матцумото начал работу над этим языком 24 февраля 1993 года после того, как Perl и Python не оправдали его ожиданий.

Мне был нужен «скриптовый» язык, который был бы мощнее, чем Perl и более объектно-ориентированнее, чем Python. Поэтому я решил создать свой собственный язык программирования.

Из интервью для O’Reilly LinuxDevCenter

Ruby — полностью объектно-ориентированный язык, т.е. абсолютно всё там является объектом, без каких-либо исключений. Несмотря на это, он позволяет использовать несколько парадигм, т.е. вы можете программировать процедурно, объектно-ориентированно или же функционально. Однако, стоит заметить, что все «внешние» функции являются методами объекта self, а переменные — его членами и, таким образом, ОО принципы не нарушаются. Также язык поддерживает мета-программирование, что сыграло существенную роль в успехе Ruby on Rails. Вообще, это очень богатый и интересный язык, поэтому полностью описывать все его возможности и преимущества здесь я не буду. Подробнее об этом языке программирования вы можете почитать на официальном сайте. А попробовать его в действии, не устанавливая себе на компьютер, можно с помощью этого интерактивного онлайн интерпретатора.

Ruby on Rails (RoR или же просто Rails) — открытый фреймворк для построения веб-приложений, который написан на Ruby и следует архитектуре MVC (Model-View-Controller). Он был выделен из Basecamp — программы для управления проектами и первый его релиз состоялся в июле 2004 года. И хотя версия 1.0 появилась очень недавно — в декабре 2005 — RoR стремительно набирает популярность. Создателем фреймворка является сотрудник компании 37signals — Дэвид Хэйнемеер Ханссон (David Heinemeier Hansson).


Фото с его официального блога

Но это всё были голые и скучные факты.

Кратко о шумихе и преимуществах

Если вы будете искать информацию о RoR, то наткнетесь на громкие заявления о том, что с помощью этого фреймворка можно разрабатывать веб-приложения в 10 раз быстрее, чем на Java (с её фреймворками, разумеется) и т.п. Так вот не верьте всему этому. Сначала попробуйте сами, а потом вам уже не надо будет ничего говорить. Вы и так поймёте, что это действительно правда.

Так чем же так хороши эти рельсы? Самое главное, по моему мнению, это то, что фреймворк рождён не в искусственных условиях, а «выдран» из работающего и приносящего прибыль программного продукта. Таким образом, ещё до первых упоминаний, он прошёл обкатку в реальных условиях, с реальными пользователями и рисками. Если же смотреть на архитектурно-технические аспекты, то

— во-первых, архитектура MVC позволяет легко отделить уровни данных, представления и бизнес логики друг от друга;
— во-вторых, RoR строго следует принципу DRY (Don’t Repeat Yourself — не повторяйся), что позволяет писать гибкие и легкосопровождаемые приложения;
— в-третьих, Rails позволяет сосредоточиться на задаче, а не на изобретении колеса. Если вам нужно проверить заполненно ли поле name, вы просто напишите validates_presence_of :name и перейдёте к реализации более важных вещей (или пойдёте пить чай);
— и наконец, это фреймворк от практикующих веб-программистов практикующим веб-программистам, а не плод больного сознания — помешанных на теории — «разработчиков», маркетинговая заглушка или же курсовая работа по информатике.

Здесь и в следующих статьях я хочу повторить структуру книги «Agile Web Development with Rails», потому что считаю её оптимальной для описания сий чудной вещи. Начнём, пожалуй.

Уровень данных (Model) — ActiveRecord

ActiveRecord это реализация ORM, поставляемая с Rails. Но что же такое ORM? ORM (Object-Relational Mapping) — это техника представления базы данных с помощью объектов. Т.е. класс представляет таблицу, объект строку, а его поля, соответственно, колонки. Т.к. большинству читателей знаком «C-like» синтаксис, приведу пример на Java.

Возьмём некоторую таблицу books:
id int(10)
name varchar(100)

Эта таблицу можно представить, как класс Book:

Т.е. Book thinkinginjava = new Book(1); возвратит нам строку в таблице books с >

ActiveRecord предлагает нам очень богатую реализацию ORM, которая сама строит иерархию классов, основываясь на структуре таблицы. К тому же, здесь (как, впрочем, и повсюду в RoR) поддерживается принцип «соглашения вместо конфигураций». Но текст текстом, а код скажет всё сам за себя. Если взять вышеприведенную таблицу, то нам нужно всего-лишь запустить скрипт генерации модели:

И вуаля! В папке /app/models/ появился файл book.rb, открыв который мы увидим примерно следующий код:

Итак, что же произошло? У нас появилась готовая для работы модель таблицы books. При инициализации Rails подразумевает, что название таблицы это название класса в множественном числе, где слова разделены нижним подчёркиванием. Т.е. таблице orders соответствует класс Order, line_items — LineItem, people — Person и т. д. Таким образом мы уже сейчас можем его использовать:

Как мы видим, по умолчанию реализованы аттрибуты класса, которые соответствуют колонкам в таблице и методы CRUD (Create, Retreive, Update, Delete). Я не буду описывать здесь эти методы, дабы не превращать эту статью в некое подобие мануала. Их много и они весьма удобны.

Итак, с помощью некоторой «магии» за нас было сделано огромное количество рутинной работы. Но, многие могут подумать, что за пределы этой магии вылезти никак нельзя. Это не так, потому что все «соглашения» могут быть легко проигнорированы. К примеру, если у вас уже есть готовая база данных, которую менять никак нельзя и таблица для книг в ней называется knigi, то вам всего лишь нужно указать на это:

Тоже самое и с другими вещами, такими как, к примеру, первичные ключи. По умолчанию, RoR подразумевает, что поле с первичным ключом называется id (что, кстати, очень логично), однако вы можете это исправить, написав set_primary_key «kitob_cifra».

Одно из немногих мест, где нужны настройки это файл /config/database.yml, в котором вы указываете тип и название базы. Стоит заметить, что при разработке рекомендуется использовать три одинаковые базы данных для трёх состояний системы: production, development и test. Как видно из названий, production это база для стабильных версий системы, development — для разработки, а test предназначается для автоматических тестов.

Пример файла database.yml:

На сегодняшний день, Ruby on Rails поддерживает такие СУБД, как MySQL, DB2, PostgreSQL, Oracle, SQLite, MS SQL Server.

Про автоматические тестирование и поддержку TDD (Test-driven Development) мы поговорим уже в следующих статьях.

Это далеко не всё, что относится к ActiveRecord и я не сказал про связи между таблицами, транзакции, аггрегации, обратные вызовы и многое другое. Это просто не входит в формат данной статьи. Замечу только, что практически всё в RoR реализуется восхитительно просто. Вам нужно представить таблицу в виде дерева объектов, отсортированного по полю name? Нет ничего проще!

Итак, мы увидели, что уровень данных в RoR реализован в простом и, в то же время, очень мощном инструменте — ActiveRecord, который берёт на себя подавляющее большинство рутинных операций и позволяет сосредоточиться на самой задаче. В следующий раз я расскажу об уровне бизнес логики «на рельсах», т.е. о контроллерах.

10 наиболее частых ошибок на Ruby on Rails: лучший практический туториал

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

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

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

Ошибка 1. Слишком много логики в контроллере

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

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

  • Обработка сессии и cookies. Также может включать аутентификацию/авторизацию или любую другую операцию с куками, которая вам нужна.
  • Выбор модели. Логика для поиска оптимального объекта модели задается параметрами, переданными из запроса. В идеале, они должны вызывать единственный метод find, который будет устанавливать переменную, используемую в будущем для получения ответа.
  • Управление параметрами запроса. Сбор параметров запроса и вызов соответствующего метода модели.
  • Рендеринг/редирект. Рендеринг результата (html, xml, json и т.д.) или редирект, если это необходимо.

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

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

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

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

Welcome,

Guest


Лучший способ справиться с подобным: убедиться, что объект возвращаемый 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,

Пара дополнительных рекомендаций по Rails:

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

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

Учитывая рекомендации, говорящие минимизировать логику в представлениях и контроллерах, последнее место в MVC, куда нам осталось положить всю логику — это модель, так?

Цукерберг рекомендует:  Битовые - Битовые операции

Многие 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-запросы в ваших логах.

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

def comments_for_top_three_posts
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
Processing by PostsController#some_comments as HTML
Post Load (0.4ms) SELECT «posts».* FROM «posts» LIMIT 3
Comment Load (5.6ms) ELECT «comments».* FROM «comments» WHERE «comments».»post_ > Comment Load (0.4ms) SELECT «comments».* FROM «comments» WHERE «comments».»post_ > Comment Load (1.5ms) SELECT «comments».* FROM «comments» WHERE «comments».»post_ > 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-приложения намного быстрее, разработчики должны обратить внимание на потенциальные ошибки в коде и проектировании, чтобы убедиться, что их приложение легко расширяемое и его легко поддерживать.

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

4 главных аналога Ruby on Rails

Posted by dhh , December 19, 2014 @ 9:00 pm in Releases

We come bearing gifts! It’s Rails 4.2, and the final version is ready just in time for Christmas. It’s full of great toys, useful gizmos, and polished edges, courtesy of a fantastic community of merry elves who’ve been coding away with jolly glee for months.

This is probably also the most well-tested new major release of Rails in a long time. Through four betas and three release candidates, tons of people have helped ensure that regressions and bugs have been caught. Since the first beta, we have some 1600+ commits of spit and polish applied. So you have good reason to be excited!

To recap, here’s a walkthrough of the major new goodies:

Active Job, ActionMailer #deliver_later

The headline feature for Rails 4.2 is the brand new Active Job framework, and its integrations. Active Job is an adapter layer on top of queuing systems like Resque, Delayed Job, Sidekiq, and more. You can write your jobs to Active Job, and they’ll run on all these queues with no changes.

With an always-configured queue in place (though the default is just an inline runner), we can build on top of that where it makes sense. And the first place it makes sense is to send Action Mailer emails asynchronously. So we’re introducing the #deliver_later method, which will do just that: Add your email to be sent as a job to a queue, so you don’t bog down the controller or model. Voila!

The cherry on top is our new GlobalID library. It makes it easy to pass Active Record objects to jobs by serializing them in a generic form. This means you no longer have to manually pack and unpack your Active Records by passing ids. Just give the job the straight AR object, and it’ll serialize it using GlobalID, and deserialize it at run time. So much easier!

Special thanks go out to Cristian Bica and Abdelkader Boudih for their outstanding work bringing this trinity of improvements to Rails!

Adequate Record

Aaron Patterson is always hunting for performance bounties in Rails, and with an improvement project called Adequate Record for Active Record, he’s come up good. A lot of common queries are now no less than twice as fast in Rails 4.2! This is a great step forward for performance. While computers are constantly getting cheaper and performance is improving, nobody ever said “hey, get that free speed out of my framework”. So there you go: Some free speed, buddy!

Web Console

Out of the wonderful Google Summer of Code for Rails campaign comes Web Console, which gives you a development console to inspect the state of affairs on all exception pages! It even allows you to jump between the different points in the backtrace, and you’ll be able to inspect things right at that point.

It’s a wonderful improvement to the debugging workflow. Thanks to Genadi Samokovarov and Ryan Dao for their work on this project.


Foreign Keys

Rails has long had a tumultuous relationship with foreign keys, but the drama days are now over. If you want to have foreign keys, you can have foreign keys, and Rails will still smile as it takes your order. The migration DSL gets add_foreign_key and remove_foreign_key and the standard schema.rb dumper will support maintaing these declarations. Foreign key support starts out as an exclusive to the MySQL and PostgreSQL adapters.

And so much more…

The above are just the highlights. We have many more goodies packed into this release than that. You can read a great summary in the release notes.

Maintenance consequences and Rails 5.0!

As per our maintenance policy, the release of Rails 4.2 means bug fixes will only apply to 4-2-stable, regular security issues to 4.2.x, 4.1.x, and severe security issues to 4.2.x, 4.1.x, and 3.2.x. In addition to these already stated commitments, the honorable Rafael França has agreed to also apply bug fixes to 4-1-stable. So everyone still on 4.1 and unable to move quickly can thank Rafael!

Rails 4.2 also marks the last big release in the 4.x series. With this release out, we’re now working towards the big Rails 5.0! This means rails/master is now targeting 5.0.

Rails 5.0 will target Ruby 2.2+ exclusively. There are a bunch of optimizations coming in Ruby 2.2 that are going to be very nice, but most importantly for Rails, symbols are going to be garbage collected. This means we can shed a lot of weight related to juggling strings when we accept input from the outside world. It also means that we can convert fully to keyword arguments and all the other good stuff from the latest Ruby.

The release target for Rails 5.0 is currently Fall of 2015. So there’s a while yet, but we’re putting this out there for people to know, so gem maintainers and other Ruby implementations can know where we’re going. We’ll be working on putting out somewhat of a road map for the features when that’s become a bit clearer.

Thanks to all and happy holidays!

It continues to be a pleasure and an honor to be involved with the amazing Ruby on Rails community – both contributors and users. The collaboration and resulting quality has never been better. Have a great holiday season and New Year’s, and we’ll see you all with more delicious releases in 2015!

Ruby on Rails/Введение

Содержание

Что входит в Rails? Править

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

Кто пользуется Rails? Править

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

Что еще нужно? Править

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

Цукерберг рекомендует:  Php - PHP и чекбоксы,- помогите.

Инструменты Править

Наверно существует столько вариантов разработки Rails приложений, сколько и Rails программистов. Но все они сводятся к двум вариантам: текстовый редактор/командная строка и интегрированная среда разработки (IDE).

Интегрированная среда разработки Править

Дефицита в Rails IDE нет. Основные это: RadRails, RubyMine, 3rd Rail и NetBeans. Все кросс-платформенные, и некоторые из них очень хорошие, но в этом учебнике мы будем использовать связку текстовый редактор/командная строка.

Текстовые редакторы и командная строка Править

Что мы используем для разработки Rails приложений, если нет шикарной IDE? Большинство Rails разработчиков выбирают по следующим критериям: использовать текстовый редактор для редактирования текста, а командную строку для выполнения команд. Комбинация зависит от ваших предпочтений и платформы:

Macintosh OS X: Многие разработчики на Rails предпочитают TextMate. Другие варианты — Emacs и MacVim (запускаемый командой macvim), великолепная мак-версия Vim. Также используют iTerm для терминала командной строки; другие превосходно довольствуются встроенным приложением Terminal.

Linux: Ваш выбор редактора основывается на описанном выше для OS X, за исключением TextMate. Мы рекомендуем графический Vim (gVim), gedit (с плагином GMate) или Kate. Что касается командной строки: каждый дистрибутив Линукс имеет по крайней мере одно заявленное приложение терминала командной строки (часто несколько).

Браузеры Править

Хотя существует множество веб-браузеров, подавляющее большинство Rails разрабочиков используют Firefox, Safari или Chrome. Скриншоты в этом учебнике, как правило, будут в браузере Chrome. Если вы используете Firefox, предлагаем использовать Firebug, он позволяет динамическую проверку (и даже редактирование) структуры HTML и CSS правил на любой странице. Для тех, кто не использует Firefox, Firebug Lite работает с большинством других браузеров, таких как Safari и Chrome, и имеет встроенную «Проверку элемента». Независимо от того, какой браузер вы используете, опыт показывает, что время, потраченное на обучения подобным инструментам будет щедро вознаграждено.

По поводу инструментов Править

В процессе приобщения ваше рабочее окружение будет установлено и запущено, вы возможно найдете что тратить много времени на приобщение ко всему будет правильно. Процесс обучения текстовым редакторам и IDE особенно долог; вы можете потратить неделю только на чтение руководства TextMate или Vim. Если Вы плохо знакомы с этим делом, я хочу уверить Вас, что расход времени на изучение инструментов нормален. Все проходят это. Иногда это печально и вызывает легкое беспокойство, когда у вас в голове уже есть веб-приложение и вы хотите только изучить Rails, но тратите неделю изучая некоторый таинственный древний редактор Unix только чтобы начать. Но мастер должен знать свои инструменты — в конце награда окупит усилия.

Ruby, RubyGems, Rails, and Git Править

Классический способ установки из исходных текстов со страницы загрузки Ruby on Rails. Я предположу, что Вы можете перейти туда теперь; часть этой книги могут быть прочитаны с пользой без Сети, но не эта часть. Я только вставлю некоторые собственные комментарии к процедуре установки.

Установка Git Править

Многое в экосистеме Rails зависит так или иначе от системы контроля версий называемой Git (описана в деталях в Разделе 1.3). Поскольку она повсеместно используется вы должны установить Git на этой ранней стадии; я предлагаю следовать инструкциям по установке Git для вашей системы в разделе Installing Git из Pro Git.

Установка Ruby Править

Следующий шаг – установка Ruby. Возможно что он уже стоит в вашей системе, попробуем запустить:

Видим номер версии. Rails 3 требует Ruby 1.8.7 и выше, и отлично работает с Ruby 1.9.2. Этот учебник предполагает, что вы используете последную версию Ruby 1.9.2, известную как Ruby 1.9.2-head, но и с Ruby 1.8.7 должно быть всё хорошо.


Ветка Ruby 1.9 находится в интенсивной разработке, поэтому, к сожалению установка последней версии может быть нетривиальной задачей. Вам придётся полагаться на самые современные инструкции. Ниже приводится ряд шагов, после которых я привёл всё в рабочее состояние на моей системе (Macintosh OS X), но вам, возможно, придётся повозиться.

Как часть процедуры установки Ruby, если вы используете OS X или Linux, я настоятельно рекомендую устанавливать Ruby используя Ruby Version Manager (RVM), который позволяет устанавливать и управлять различными версиями Ruby на одной машине. (Проект Pik позволяет подобное при использовании Windows.) Это особенно важно, если вы хотите запускать Rails 3 и Rails 2.3 на одной машине. Если вы решили пойти этим путем, я рекомендую использовать RVM для установки двух комбинаций Ruby/Rails: Ruby 1.8.7/Rails 2.3.8 и Ruby 1.9.2/Rails 3.1.0. Если Вы сталкнётесь с какими-нибудь проблемами при использовании RVM, вы всегда можете найти его автора, Wayne Seguin, на канале IRC RVM (#rvm on freenode.net).8

После установки RVM Вы можете установить Руби следующим образом:

Затем сделайте gemset для Rails 3, который позволит нам управлять отдельными пакетами gems если мы хотим (например) запускать Rails 2.3 на одной системе:

Вы можете сделать эту версию и gemset версией по умолчанию следующим образом:

Установка RubyGems Править

RubyGems – это пакетный менеджер Ruby projects, и существуют тонны больших библиотек (включая Rails), доступных через пакеты Ruby или gems. Установка RubyGems должна быть лёгкой, так как Вы установили Ruby. Фактически, если Вы установили RVM, у Вас уже есть RubyGems, так как RVM включает его автоматически:

Если у Вас ещё нет этого, Вы должны загрузить RubyGems, распаковать его, и затем пойти в каталог rubygems и запустить программу установки:

Здесь sudo выполняет команду ruby setup.rb как администратор, который имеет доступ к файлам и каталогам, не доступным обычным пользователям; я поместил команду в скобках, чтобы указать, что использование sudo возможно не требуется для Вашей конкретной системы. Большинство Unix/Linux/OS X систем требуют sudo по умолчанию, если Вы не используете RVM как предложено в Разделе 1.2.2.2. Заметьте, что Вы не должны фактически печатать скобки; Вы должны запустить также

в зависимости от вашей системы.

Если вы уже установили RubyGems ранее, то возможно вы захотите обновить вашу систему на последную версию:

Установка Rails Править

Установка Rails 3.0 может быть мудрёна, так как еще нет релиза и появляется много изменений. Вот команды, которые работали у меня:

Флаг «–pre» гарантирует, что вы получите пре-релиз версию Rails, которая на момент написания статьи стала релиз-кандидатом (rc)

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

Первое приложение Править

Почти все приложения Rails генерируются с помощью команды rails . Это команда создает «скелет» будущего приложения в выбранном вами каталоге. Для начала создадим каталог для ваших Rails проектов, а затем запустим команду rails для генерации первого приложения:

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

Файл/Директория Описание
app/ Основные приложения (app) кода, включая модели, представления, контроллеры и помощники
config/ Конфигурация приложения
db/ Файлы для управления базой данных: схема базы данных и миграции
doc/ Документация приложения
lib/ Модули библиотек
log/ log файлы приложения
public/ Общедоступные файлы (например для веб-браузера)- изображения и каскадные таблицы стилей (CSS) и т.д.
script/rails/ Скрипт Rails для генерации кода, открытия консоли сессий, или запуск локального веб-сервера
test/ Юнит-тесты и прочий аппарат тестирования
tmp/ Временные файлы
vendor/ Сторонний код, например плагины и гемы
README/ Краткое описание приложения
Rakefile Утилиты задач, доступных через команду rake
Gemfile Gem требования для приложения
config.ru Файл конфигурации для Rack middleware
.gitignore Шаблоны для файлов, которые должны быть проигнорированы Git

Bundler Править

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

Должно выйти что-то похожее:

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

Если вы укажете номер версии для gem команды, Bundler автоматически установит последнюю версию. К сожалению, gem обновления может привести к путанице и поломке, так что в этом уроке мы обычно включаем номер рабочей версии. Например, последняя версия sqlite3-ruby gem не будет установлен на OS X Leopard, в то время как предыдущая версия работает отлично. Просто для безопасности сделайте следующие исключения:

Что заставит Bundler установить версию 1.2.5 от sqlite3-ruby gem. (Также мы удалили ненужные строки комментариев). Обратите внимание что если версия 1.2.5 от sqlite3-ruby gem у вас не работает, попробуйте версию 1.3.1.

Если вы работаете в Ubuntu Linux, вам может потребоваться установить несколько других пакетов на данный момент:

Как только вы собрали надлежащий Gemfile, установите gems используя Bundle

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

rails server Править

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

Это говорит о том, что приложение работает на порту номер 3000 по адресу 0.0.0.0. Это специальный адрес означает, что с любого компьютера в локальной сети можно просматривать наше приложения, в частности, машина запускает сервер разработки, т. е. локальную машину разработки — можете просматривать приложения, используя адрес localhost:3000. Мы можем увидеть результат посетив http://localhost:3000/

Чтобы просмотреть информацию о вашем приложении, нажмите на ссылку “About your application’s environment

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

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

На ранней стадии, полезно получить общие знания о работе Rails приложений. Вы уже заметили, что по умолчанию структура Rails приложения имеет app/ каталог с тремя подкатегориями: models, views, и controllers. Это намек на то,что Rails следует шаблону модель-представление-контроллер (MVC), который разделяет «domain logic» (или «business logic») от входной и представленной логикой, связанной с графическим пользовательским интерфейсом (GUI). В случае веб-приложений «domain logic» обычно состоит из data models для пользователей,статей, и продуктов, и GUI это только веб-страница в браузере.

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

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

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


Есть много вариантов для управления версиями, но Rails сообщество в значительной степени ориентировано на Git, систему управления версиями разработанной Линусом Торвальдсом для размещения ядра Linux.

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

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

Также используем более подробную команду проверки:

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

Последним этапом установки можно дополнительно задать текстовый редактор, который Git будет использовать для комментирования сообщений. При использовании графического редактора, например TextMate, gVim, или MacVim, вам необходимо убедиться в том что редактор прикреплен правильно:

Замените » mate -w » на » gvim -f » для gVim или » mvim -f » для MacVim.

Установка первого репозитория Править

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

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

Rails по умолчанию создает в корневой директорию .gitignore файл следующего содержания:

В этом листинге прописаны файлы которые Git будет игнорировать, это — log файлы, временные Rails (tmp) файлы и SQLite база данных. Большинство из этих файлов часто автоматически изменяются, поэтому их неудобно включать в систему управления версиями.

Данных игнорируемых файлов в .gitignore файле вполне достаточно для этого учебника, но в зависимости от вашей системы вы можете использовать следующий листинг. Он также игнорирует файлы документации Rails, Vim и Emacs файлы подкачки, и (для OS X пользователей) .DS_Store каталоги созданные mac Finder приложением. Если вы хотите использовать этот листинг, то просто откройте .gitignore файл в вашем любимом текстовом редакторе и заполните его следующим содержанием:

Добавление и фиксирование Править

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

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

Результат на самом деле длинный, и здесь вертикальные точки это пропущенные строки.

Чтобы сообщить Git, что вы хотите сохранить изменения, используете следующую фиксирующую команду:

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

Важно запомнить что Git фиксация локальна, записывается только на ваш компьютер. Это в отличие от другой системы управления, под названием Subversion, в которой обязательно вносятся изменения на удаленном хранилище. Git в отличие от стиля Subversion, делает это двумя логическими частями: локальная запись изменений (git commit), и отправка изменения на удаленное хранилище (git push). В дальнейшем мы увидим пример отправки.

Тем временем вы можете увидеть ваши зафиксированные записи используя log команду:

Для того, чтобы выйти из Git журнала нажмите q.

Так чем, все-таки, так хорош Git? Править

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

Мы применяем Unix ls команды для листинга каталога app/controllers/ и команду rm для того чтобы удалить его. -rf означает «рекурсивную силу», которая рекурсивно удаляет все файлы, каталоги, подкаталоги и так далее, не требуя подтверждения на каждое удаление.

Посмотрим, что получилось:

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

Удаленные файлы и папки восстановлены!

GitHub Править

Теперь, когда мы включили наш проект в систему контроля версиями Git, пришло время отправить ваш код до GitHub, специальный ресурс для кода, оптимизированный для размещения и обмена Git репозиториями. Копируя ваш репозиторий на GitHub мы преследуем две цели: полное резервное копирование кода (включая полную историю фиксаций), и упор на последующее более легкое сотрудничество. Этот шаг не является обязательным, но будучи членом GitHub вам открыты двери к участию разнообразных Ruby and Rails проектов. (GitHub очень хорошо принимает Ruby and Rails, в самом деле он написан на нём).

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

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

Результат должен незамедлительно отобразиться на вашей странице в GitHub.

Отделение, редактирование, фиксация, слияние Править

Отделение Править

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

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

Вторая команда, git branch , просто список всех локальных ответвлений, а звездочка * определяет, какая ветвь в данное время активна. Обратите внимание, что git checkout -b modify-README вместе создают новую ветвь и переключаются на неё, как указано звёздочкой перед ответвление modify-README.


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

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

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

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

,а затем заполним его следующим содержанием:

# Ruby on Rails Tutorial: first application This is the first application for [*Ruby on Rails Tutorial*]

Фиксирование Править

В связи с изменениями, мы можем взглянуть на состояние нашей ветви:

Цукерберг рекомендует:  Верификация email-а после регистрации

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

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

Слияние Править

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

Заметим, что Git вывод включает часто в себя такие вещи как 34f06b7, которые связаны с внутренним представлении о Git репозитории. Ваши результаты будут отличаться в подробностях, но в целом должны соответствовать примеру выше.

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

Этот шаг является необязательным, и на самом деле довольно часто можно оставить topic branch нетронутым. Таким образом вы сможете переключаться между topic и master branches до тех пор пока вам это нужно.

Как уже отмечалось выше можно отказатьс от изменений в topic branches, в данном случае используя git bransh -D:

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

Push Править

Теперь, когда мы обновили файл README, мы можем загрузить изменения на GitHub, чтобы увидеть результат:

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

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

Средства развертывания Ruby кода появились в течении нескольких прошедших лет, и сейчас для этого есть несколько замечательных функций. Они включают приложения для хостов или виртуальных частных серверов Phusion Passenger (модуль для Apache и Nginx), полный комплекс услуг развертывания таких компаний, как Engine Yard и Rails Machine, и облако развертывания услуг, таких как Engine Yard Cloud и Heroku.

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

Установка Heroku Править

После регистрации на Heroku, установите Heroku gem:

Как и с GitHub, при использовании Heroku вам необходимо создать SSH ключи, если вы до сих пор это не сделали, и затем указать Heroku ваш public key, чтобы вы смогли использовать Git для загрузки ваших приложений на их сервера:

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

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

Развертывание. Шаг первый. Править

Для развертывания на Heroku, первый шаг заключается в использовании Git для загрузки приложении на Heroku:

Развертывание. Шаг второй. Править

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

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

Команды Heroku Править

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

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

Все, что осталось, это, знаете, на самом деле начать обучение Rails. Давайте начнем!

4 главных аналога Ruby on Rails


Это зависит от ваших целей и ситуации. Если все ваши друзья программируют на Питоне, учите Джанго: будет кому ревьюить ваш код, быстрее освоите. Если в компании вашей мечты используют Node.js, учите Node.js и Express.js: будет проще устроиться. Но если факторов, склоняющих вас в пользу других фреймворков, нет, я советую начинать с Руби‑на‑рельсах. И у меня на это пять причин.

Рельсы научат базовым вещам

У Руби‑на‑рельсах отличная официальная документация, которая за руку проводит по основным компонентам фреймворка. Разобравшись с нею, вы получите базовые знания об устройстве веб‑фреймворков: как устроен роутинг, как работает веб, зачем фреймворку база данных и как менять её устройство, как использовать шаблоны, как интернационализировать и локализовывать приложения. Если придётся сменить фреймворк, знания пригодятся: и в Рельсах, и в Джанго роутинг — та же функция для сопоставления запроса и кода, который его должен обработать.

Кроме того, из базовой документации вы получите знания о смежных с веб‑разработкой областях: о тестировании, отладке и безопасности. Научитесь правильно и безопасно конфигурировать приложения, отправлять и принимать почту, загружать и хранить файлы в облачные хранилища.

Рельсы научат писать хороший код

В Руби и Рельсах есть всё, чтобы научиться писать аккуратный, поддерживаемый и последовательный код. Начните со стайлгайдов:

Чтобы научиться определять, какой код плох, почему и как это исправлять, изучите Ruby Science и POODR :

Правила, принципы и методы, описанные в этих книгах, фундаментальны. Разберётесь с ними в Руби и Рельсах, будете применять и в других языках программирования.

В Рельсах всё есть

В Рельсах есть всё, что нужно, чтобы быстро собрать и запустить любое веб‑приложение: ОРМ , миграции, кеширование, отправка и получение почты, вебсокеты, интернационализация, отложенные задачи, АПИ для работы с облачными хранилищами. Если чего‑то нет, для этого есть гемы: нужна аутентификация через почту и соцсети с восстановлением пароля, берите Devise; нужен деплой и откат версий одной кнопкой, берите Capistrano; нужна админка, берите ActiveAdmin.

Какую бы задачу вы не выбрали для первого проекта на Рельсах, вы быстро получите работающий прототип. Будет, что показать на собеседовании.

Современный фронтенд

Рельсы дружат с современной экосистемой фронтенда и поддерживают все модные фреймворки. Если решите заодно попробовать и фронтенд, берите React, Vue или Svelte — всё отлично работает в Рельсах. Не придётся держать фронтенд и бэкенд отдельно. А если решите переписать бэкенд на Го, без проблем извлечёте фронтенд из проекта.

Программистское счастье

Это самая субъективная причина начинать программировать на Руби и Рельсах.

Я верю, что программирование ближе к литературе и редактуре, чем к точным наукам. Чем лаконичнее и понятнее код, чем он ближе к естественному, а не формальному языку, тем легче и приятнее с ним работать: люди пишут код для людей.

Руби очень лаконичный и выразительный язык. Ясно выражать на нём собственные мысли мне проще, чем на других языках программирования. Например, чтобы вывести на экран 5 раз «Ура» в Яваскрипте придётся использовать цикл for или forEach :

А в Руби — написать, как думаю, 5 times print «Ура»:

Когда я начинал изучать Руби и Рельсы, они настолько понравились мне, что я, как в детстве, не мог дождаться утра, чтобы поскорее запрограммировать на Рельсах что‑нибудь ещё. И до сих пор, просыпаясь по утрам, я счастлив, что сегодня попрограммирую на Руби.

Надеюсь, и вас Руби и Рельсы сделают счастливым.

Почему стоит учить Ruby On Rails в 2020 году

David Heinemeier Hansson на quora ответил на вопрос, почему стоит изучать Ruby on Rails в 2020 году. Тема бесспорно актуальна, поэтому решил сделать перевод. Далее, вольный перевод, со слов Дэвида.

По тем же причинам, что и в 2004 году. Много всего изменилось, но большинство осталось все тем же. Пока мы наблюдаем за значительным прогрессом в мире Javascript, мы также видим уменьшение сложности, которую Rails предлагает с самых первых дней. Раньше сложность была выбором мира Java, но жалобы уж сильно аналогичны тем, которые выдвинуты против Javascript сегодня. Эти люди тратят часы, если не дни, просто набрасывая каркас приложения. Настраивая базовую конфигурацию. Собирая и cherry-пикая код из множества библиотек и фреймворков создавая свою собственную архитектуру.

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

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

Я думаю, дело в том, что основополагающая идея Rails чужда естеству большинства программистов. Избегая большого количества вариантов и принимая соглашения и опыт сообщества в большинстве вопросов web разработки вы в конечном итоге становитесь лучше.

В любом случае, это большая идеологическая привлекательность Rails. Я расписал принцип convention over configuration шире, показал the a la carte/omakase конфликт, показал привлекательность целостных систем и другие не менее важные вещи в доктрине Rails

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

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

Как я уже говорил выше, Rails преследует невероятно амбициозную цель. Главной задачей full-stack разработки лежит в соединении каждого куска, необходимого для работы с базой данных или NoSQL хранилищем с бизнес логикой, написанной на Ruby. Через набор контроллеров, которые предоставляют доступ к этой логике с помощью REST, заканчивая генераций HTML, который в конечном итоге предоставляется пользователю. Но, этот самый последний шаг (генерация HTML) не является тем, на чем фокусируется Rails.

По этому, если вы считаете, что будущее за фронтенд разработкой, React, Angular или что-то еще, то вам все равно все еще нужен Rails. Фронтенд всего лишь основанный на HTML/Javascript интерфейс пользователя, который все равно нужно соединить с реальной логикой. Сохранение данных в базу, расчет разных штук, выполнение производительных задач, отправка емейлов или пуш нотификаций — все это задачи бекенда, которые нужно решать в реальных приложениях.

И это то, в чем действительно хорош Rails. Важно то, что происходит после POST или PUT или GET запроса. Как я уже сказал, Rails является full-stack фреймворком и конечно у него есть инструменты для генерации HTML. Более того, у нас есть невероятно продуктивные решения в этой области, например Turbolinks или SJR. Но, если Вам кажется что эти решения Вам не подходят, Rails также имеет мощные решения для генерации JSON из коробки.

В любом случае, это очень длинная речь для двух основных вещей, которые делают Rails привлекательным в 2020году:

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

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

Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit.

Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit.


Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit.

Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit.

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

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

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

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

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

Basecamp: Управление проектами.
Rails начался с этого приложения 37signals.

Campfire: Групповой чат для бизнеса.
Pushing the limits of Ajax in Rails.

43things: Поставь себе цели в жизни и добейся их.

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 is dead?

Если вам посчастливилось быть RoR разработчиком, то последние лет десять вы слышите один и тот же вопрос. Ruby on Rails is dead? Мы подумали, что 2020 год — самое время, чтобы дать на него обстоятельный ответ.

Итак, слухи о зарождающейся (неизбежной, неизменной, необратимой) гибели Ruby блуждают по курилкам и песочницам не первый год. И все же Ruby on Rails по-прежнему приводит в действие сотни тысяч веб-сайтов. Достаточно таких примеров, как Github, AirBnB и Hulu. Неплохо для фреймворка, пребывающего на последнем вздохе, правда?

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

2020 год: полет нормальный

Рейтинг TIOBE (индекс, использующий результаты поиска) помещает Ruby в ТОП-20 технологий. В опросе Stack overflow 2020 Ruby входит в ТОП-10 самых популярных языков программирования. Кстати, мы не советуем воспринимать слово “популярность” буквально. Оставьте его старшеклассницам и любителям Стаса Михайлова.

Разработчики и заказчики веб-приложений такими категориями вообще не мыслят. Для адекватных пользователей (а мы верим, что их — большинство) важен лишь быстрый, безопасный и интуитивно понятный продукт. А меньше всего их волнует то, что находится под капотом.

Польза продукта связана с технологическим стеком очень и очень опосредованно. Какая нафиг разница, чем вы напичкали свое приложение, если оно работает, монетизируется и нравится пользователям? Так вот, Ruby on Rails позволяет достичь этих целей. Вот он тупо работает, и вы не можете этого отрицать. Более того, Ruby объективно позволяет писать чистый код быстрее большинства языков программирования. Он реально, а не теоретически удобен для стартапов и MVP.

Что делает Ruby on Rails привлекательным?

Ruby on Rails учит нас некоторым отличным привычкам кодирования. Таким как подход TDD, шаблон MVC, отдельные базы данных, сухой код и маршруты restful. Все это в конечном итоге приводит к чистому коду и сокращает тестирование. А еще сообщество поддержки Ruby/Rails обширно и надежно. Технологии с таким бэкграундом, как правило, чувствуют себя довольно неплохо и не собираются никуда исчезать.

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

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

Представьте себе лимузин класса люкс. Или супернавороченный спорткар. Все это не Ruby on Rails. Rails — это, например, семейный автомобиль. Без суперизысков и суперцены, но со всем необходимым. Его можно использовать ежедневно, не боясь, что в пути отвалится колесо или полетит коробка передач. Ruby — не для понтов. Ruby — для работы. Но единственная ли это технология, которая вам понадобится? Однозначно — нет.

Что в итоге?

Вы можете поступить, как Twitter: запуститься с Ruby, получить дополнительные инвестиции и перейти на другую технологию. Или пойти по пути AirBnB и других стартапов — остаться с Ruby. Это зависит исключительно от вас. Но правда в том, что при создании веб или корпоративного приложения, Ruby on Rails поможет вам писать код лучшего качества, тратить меньше времени на тестирование и запуск своего продукта. Вы получите преимущество перед своими конкурентами и начнете получать доход быстрее. Ну а после уже можно подумать о дальнейшем развитии, как финансовом, так и технологическом.

Например, наша команда постоянно экспериментирует с технологиями. Почему? Потому что нам нравится все новое. Потому что мы не хотим стоять на месте. Потому что мы стремимся к развитию и постоянно совершенствуемся. Вот вам примеры об опыте работы с Node.js, React, GraphQL и Webpack. А еще мы недавно инвестировали в развитие Elixir — языка программирования с Ruby подобным синтаксисом.

Так что вопросы типа: Ruby on Rails is dead — это вообще не наш уровень дискуссии. Поверьте, вы до сих пор можете найти людей, которые знают Fortran или COBOL. И они вам с удовольствием расскажут все, что думают о ваших родственниках, если вы употребите слово “мертвый”.

Если же говорить по существу, то надежная технология является а) работающей б) проверенной с) пользующейся поддержкой сообщества. Относительно Ruby on Rails вы можете уверенно ставить галочки напротив всех трех пунктов.

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

И последнее. Мы обещаем: когда появится реальная альтернатива Ruby on Rails, то есть технология, которая будет более быстрой, более безопасной и более гибкой, вы узнаете о ней от нас.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих