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

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

Skillbox рекомендует: Практический курс «Профессия веб-разработчик».

Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

От Java к Ruby


Для меня работа с Ruby — реальная экономия времени. Я могу сконцентрироваться на методах и логике, а не возиться с большим объемом кода строка за строкой. Раньше я думал, что Java — геймченджер, но после знакомства с Ruby on Rails я был впечатлен еще больше.

Примерно год я пишу на Java и занимаюсь backend-разработкой. Мне кажется, что любой программист, работающий с этим языком, поймет то, о чем я говорю. Предположим, вы хотите написать конечную точку для возврата .zip-файла. Решить эту задачу можно без особых проблем, но для этого необходимы сотни строк кода.

Но что, если я скажу вам, что можно обойтись и несколькими десятками строк?



Это Ruby — объектно-ориентированный, динамический, рефлективный, интерпретируемый высокоуровневый язык программирования. Он обладает независимой от операционной системы реализацией многопоточности, сильной динамической типизацией, сборщиком мусора и многими другими возможностями. На нем написано множество веб-приложений, среди которых GitHub и Twitter.

Ruby позволяет сократить объем кода


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

Например, если у вас есть массив и вы хотите увеличить все элементы на 2, а затем вернуть их в обратном порядке в Java, код будет похож на этот (с использованием интерфейса List):

import java.util.*;
import java.util.stream.Stream;
import static java.util.Collections.reverseOrder;
import static java.util.stream.Collectors.toList;
 
public class MyClass {
    public static void main(String args[]) {
        List<Integer> list = Stream.of(1, 2, 3)
          .map(val -> val + 2)
          .sorted(reverseOrder())
          .collect(toList());
 
        list.forEach(System.out::println);
    }
}

То же самое на Ruby будет выглядеть так:

array = Array.new(5,2)
array.map { |x| x + 2 }.reverse


Разница налицо. И вам не нужно импортировать классы.

Динамическая типизация


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

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

В Ruby также есть множество собственных методов, которые позволяют ускорить кодинг. При написании программ я чаще всего использую преобразование Hash в Array, а затем в JSON. В Ruby я могу выполнить его всего одной строкой!

On Rails


Наиболее популярный фреймворк для Ruby — Rails. Он обеспечивает примерно такую же функциональность для языка, как Spring для Java. Я хотел бы поделиться некоторыми своими находками, которые могут вам пригодиться.

Все endpoints в одном месте

Одна из вещей, которая мне нравится в Rails, — мне нужен лишь один файл для объявления всех своих endpoints. Я всегда могу использовать команду терминала $ rake routes для того, чтобы их увидеть. Это отличный вариант для больших проектов, когда вам необходимо сделать нечто на основе того, что уже написано.

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

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

def user_params
params.require(:user).permit(:name, :surname, :birth_date, :avatar)
end


Базы данных Rails

Все миграции здесь прописаны в приложении, поэтому настройка базы данных на разных устройствах сводится к выполнению одной команды: $ bundle rake db: setup. Таким образом, внешний клиент для настройки или использования базы данных просто не нужен.

И нет, база данных, которую вы создали и перенесли на другое устройство, не будет пустой: в вашем Rails-приложении есть файл с именем seeds.rb, в котором вы можете указать все записи для разных моделей, необходимых для работы приложения. В итоге на модель нужно всего лишь несколько строк кода.

Команда $ bundle rake db:setup выполняет три функции:

  • Создает базу данных, если ее еще нет;
  • Запускает все миграции;
  • Заносит все исходные данные из вашего seed-файла.

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

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

В Rails то же самое занимает одну строку. DB Schema сохраняется в файле schema.rb, который автоматически создается при запуске миграции. И в классе не нужны сеттеры или атрибуты. Когда потребуются последние, достаточно будет написать: Model.attribute — и это все.

Как уже говорилось выше, с Rails вы можете фокусироваться именно на логике и методах вашего проекта, а не на коде.



Заключение


Ruby on Rails дает вам мощные инструменты вроде динамической типизации или byebugging, которые неплохо ускоряют процесс программирования.

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

Комментарии (19)


  1. peresada
    01.11.2018 13:33
    +5

    Иными словами

    Перешел на Ruby, у него динамическая типизация, нужно меньше писать кода, можно писать больше логики, переходите все на Ruby! Я это говорю, как опытный программист, проработавший год с Java


    Неплохо-неплохо


  1. werklop
    01.11.2018 14:28
    +1

    Примерно год я пишу на Java и занимаюсь backend-разработкой
    его путь только начался, не судите строго


  1. nicholas_k
    01.11.2018 14:37

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

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

    А если еще сравнить экосистему, фреймворки и библиотеки, то Java может оказаться более быстрым стартом. Тот же Spring Boot позволяет с минимальными усилиями запускать весьма сложные приложения.


  1. Viacheslav01
    01.11.2018 14:38

    Из общения с высокоуровневыми писателями логики, при разборе инцендента:
    — Так давайте разберемся что идет не так, какие данные у вас пришли, как они были трансформированы?
    — Я не знаю, оно вот отсюда уже готовое вываливается!


    1. alan008
      01.11.2018 16:26

      инцИДента


      1. Viacheslav01
        01.11.2018 18:08

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


        1. alan008
          02.11.2018 09:11

          Ничего обидного в этом нет, просто коробит, когда родной язык коверкают. Мир? :)


          1. Viacheslav01
            02.11.2018 16:52

            И тут бац в оппонент из тех кто не способен выучить родной язык, ну просто нет и все.
            Когда учился знал все правила, но не применял, потому как не вижу их в тексте, нет и все. Сейчас уже и правил не помню особо. Да и забил порядком на это, просто смирился. И это не лень или нежелание, это не способность. Тот же английский я учу перманентно лет 15 и в общем то дальше I speak from my heart не ушел.

            Ну а так мир :)


    1. DRVTiny
      02.11.2018 02:17
      -2

      По теме: бездарный код можно писать на любом ЯП, точно так же как и прекрасный код можно писать на любом. Причём здесь трансформации данных? Вы настолько глупы, что на полном серьёзе считаете, что на Ruby пишут приложения, не приходя в сознание, а на Java — только что-то мега-вдумчивое? Я даже оспаривать это не буду, потому что это не точка зрения, это — маразм.
      Относительно «ошибки»: извините, но если Вы — грамотный человек, то Вы не напишете слово «инцидент» через «е» — как минимум потому что неоднократно встретите его в книгах, периодических изданиях, письмах коллег. Если же Вы — безграмотный человек, не ведающий о существовании правил орфографии и пунктуации, то с какой стати Ваш маразм должен быть кому-то интересен?


      1. Viacheslav01
        02.11.2018 16:57

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

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

        И вот облом не работает этот метод, как и нет универсального рецепта для всех людей.


  1. rummolprod999
    01.11.2018 15:08

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

    Мне казалось, что наоборот — статическая типизация позволяет отсеять часть ошибок еще на этапе компиляции и задавать меньше вопросов вроде «почему же этот чертов метод возвращает слонов вместо жирафов?»


  1. APXEOLOG
    01.11.2018 15:35
    +1

    Но что, если я скажу вам, что можно обойтись и несколькими десятками строк?

    А что если можно обойтись несколькими десятками строк на Java? Шок-контент


  1. maximw
    01.11.2018 19:16

    Такое действительно стоит переводить?


  1. Anshi85
    01.11.2018 19:28

    Каждый кулик хвалит свое болото. А вообще прежде чем прийти к web разработке ( которую я долго не признавал), я тоже изучал разные языки, например учил с переменным успехом Java и C#, на C# даже написал пару программок полезных для себя (блокнот, информер курса валют), на Java генератор текста для отчёта по KPI, но самый большой интерес у меня в конце концов вызвал JS, в частности MEAN стек, считаю ли я JS лучше других языков программирования? Нет. Каждый язык программирования, каждый стек технологий предназначен для решения каких-то своих задач. Насчёт быстрой разработки, тоже такой себе вопрос. У меня уже есть пара проектов, расписаны API, фактически готов весь бэкенд, надо только переписать модель под проект и API запросов под модель и фронтед. Мне остаётся только написать логику на фронтенде и вёрстку прикрутить, так что разработка занимает сравнительно небольшое время.


  1. dimaaan
    01.11.2018 22:21

    Во-первых, мне непонятно чем ruby "ускоряет разработку", по сравнению с JS.
    Все эти якобы преимущества есть во многих фреймворках многих языков, включая JS.
    Многословность?
    Вот пример на JS одной строкой:


    [1,2,3].map(x => x + 2).reverse().

    JS код можно использовать (и переиспользовать) и на фронте и на беке еще сильнее ускоряя разработку.
    Оба языка динамические, опять таки.


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


    Если многословность явы такая непомерная ноша, можно использовать многие другие JMV языки с лаконичным синтаксисом.


    Можно даже:


    using System;
    using System.Linq;
    
    public class Program
    {
        public static void Main()
        {
            var nums = Enumerable.Repeat(2, 5).Select(x => x + 2).Reverse();
            foreach(var x in nums)
                Console.WriteLine(x);
        }
    }

    С С# немного короче и строгая статическая типизация сохраняется (а еще этот пример, в отличие от вышеприведенных, не выделяет память под массив)


    1. peresada
      02.11.2018 07:33
      +1

      Вы из тех самых людей, которые путают Java с JS? Или тогда я не понимаю, почему вы ссылаетесь на JS, когда в статье речь идет о Java и Ruby


      1. dimaaan
        02.11.2018 13:59

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


        1. Если нужно что то небольшое — JS будет лучшем выбором, чем Ruby
        2. Если большое, то Java и другие статически типизированные (и потому более многословные) языки будут не менее продуктивными, чем Ruby


  1. CuamckuyKot
    02.11.2018 11:27

    Ощущение такое, будто статья из 2008 года. Тогда такой материал был бы актуальным.

    Тема рельсов не раскрыта — рассказали бы про современный технологический стек на рельсах: webpacker, actioncable и т.д.


    1. DRVTiny
      02.11.2018 21:03

      Первый комментарий по существу. Браво!
      Все (java-кодеры, если быть более точным) так увлеклись сравнением Java и Ruby, что никто по-моему так саму статью и не прочитал, несмотря на всю её исключительную лаконичность. А она и правда вытащена из какого-то пыльного чулана и весьма бессодержательна, к сожалению.