Пользователь
30,2
рейтинг
25 июля 2014 в 23:26

Разработка → Ruby on Rails исполнилось 10 лет

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

Хотя датский программист Давид Хейнемейер Ханссон (dhh), автор популярного фреймворка, считает, что официально отпраздновать его можно и на конференции RailsConf.

Ханссон за создание Rails был назван в OSCON в 2005 году «хакером года», а в 2006 году по версии журнала Business 2.0 вошёл в список 50 самых значимых людей в сфере Веб 2.0. И это вполне заслуженно. За 10 лет на Rails сделано более 600 000 сайтов, в том числе такие популярные проекты как Twitter, GitHub, Scribd, Basecamp, Groupon, Hulu, Shopify, Yammer и др.

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

Интересно, что по трендам поисковых запросов Rails наиболее популярен в следующих странах: 1) Индия; 2) Беларусь; 3) США; 4) Россия. Немного печально, что пик популярности пришёлся на 2006-07 годы, с тех пор она снижается. Но повод отметить всё равно есть!
Анатолий Ализар @alizar
карма
749,5
рейтинг 30,2
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

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

  • +5
    Ну, что сказать, отличный инструмент. :)
    Многие технологии попадают в тренд, у многих есть пик популярности, но факт, что у Rails своя ниша будет всегда.
    Активно пользуюсь пол года, сообщество и сейчас очень большое.
  • +1
    Кто что думает про спад? Точнее, про его вероятные причины и вытекающие из них последствия.
    • +6
      Мода ушла, хороший инструмент остался. Это нормально, одна технология не может вечно быть в фокусе внимания. Для классических (не реалтаймовых) сайтов рельсы все равно остаются одной из лучших доступных платформ.
      • 0
        Если ушла мода на одно, то значит пришла на другое. Например, как вы верно упомянули, в разрезе риалтайм сайтов nodejs / meteor и подобные вещи активно набирают обороты. Но это специфическая ниша Интересно, что еще может конкурировать с реальсами на «их» поле.
        • +3
          EventMachine, Twisted и т.п. Под рельсы есть удобный Faye, который решает часть задач реалтайма (какие-нибудь уведомления пользователям отправлять — самое то).

          Но конкурировать им не обязательно, лучше просто применять наиболее подходящий для конкретной задачи инструмент. Ведь никто не запрещает использовать и рельсы и ноду в рамках одного проекта.
          • 0
            Faye так же прекрасно работает под ноду, только в этом случае JS и на клиенте и на сервере. Про EM и Twisted я в курсе, имел в виду конкуренцию с Rails.
            • +1
              Если брать только ноду, то есть, например, SailsJS, выглядит очень интересно. Тут уже смотря что нужно от платформы. Для чего-то простого и Sinatra/Flask/Express неплохо сгодятся, а вот если хочется много проверенных временем плагинов и админку, то тут уже Rails/Django могут оказаться лучшим выбором.
        • +5
          django? =)
          • +3
            Пожалуй =)
        • +1
          Из похожих MVC есть еще phoenix, это elixir MVC фреймворк. Но ему еще ой как далеко до монструозной рельсы, но я надеюсь, что проект дорастет до чего-то боле менее адекватного.
          • 0
            Спасибо, elixir прикольный)
            • 0
              только не забывайте, у elixir-a единственное что от руби, это синтаксис ;)
              • 0
                И за предупреждение также спасибо! :) Мне он интересен как раз тем, что сделан на фундаменте от Erlang, но с более дружественным (лично для меня) синтаксисом, люблю такие штуки.
        • +2
          Сейчас в моде минимализм, поэтому часто гораздо проще уговорить человека взять маленькую библиотечку, даже если потом он накачает ворох других библиотек и модулей, чтобы решать сопутствующие задачи, чем убедить его в том, что будет лучше взять готовый комбайн.

          В мире Руби это случается сплошь и рядом: люди думают «я сделаю проект гораздо проще, если возьму вместо Рельс Синатру», а потом их gemfile начинает расти, и расти, и расти, — пока суммарно приложение не сравняется по объему зависимостей с аналогичным на Ruby on Rails.

          В мире Питона та же история: люди часто скачут между Django и Flask (или аналогами). Так же модно взяться за Node или Go, а потом наплодить микросервисов, каждый из которых концептуально прост, а вот все вместе — каша.

          Бывают, конечно, и удачные примеры минимализма в мире разработки, но не так часто, как это может показаться.
          • 0
            Верно. И кстати причину Вы тоже верно указали — «мода». Жаль, что разработчики ведутся на модные тренды, вместо того, чтобы думать головой и выбирать инструмент под задачу, а не ломиться пробовать новую технологию потому что про нее написали великие 37 signals или кто-то там еще.
    • +3
      Интернет поменялся, логика плавно перебирается с серверной стороны на клиентскую. Фокус смещается в сторону клиент-сторонних фреймворков, таких как Angular, Ember, Backbone. И рельсы по прежнему прекрасно работают, но уже больше как просто как API, удобный и знакомый рендерер шаблонов для клиентской стороны и сборщик ассетов для неё же. Кстати, уже создано много библиотек для того, чтобы дружить Angular и Rails.
      • +1
        Вы правы, API-centric приложения с REST API набирают обороты.
        • +1
          И это ужасно. Были у нас одни клиенты, которые делали пагинацию на фронтенде, выкачивая десятки страниц с бэкенда. А еще они лепили вотермарк на картинки динамически, на фронтенде. Впрочем, не хочется о грустном.
          • +1
            Вы же наверняка понимаете, что можно нормальную пагинацию сделать и при такой архитектуре, всего лишь добавив немного метаинформации об общем числе записей в ответы? Тут наверное дело в кривых руках а не в подходе все-таки.
          • 0
            Это верный путь развития ввиду все большего разнообразия точек входа для доступа к информации. Пишем одно API (можно на Rails), а дальше можно делать абсолютно разные фронтенды для десктопов, мобильных устройств, различных умных железяк.
            И если API написано и задокументировано правильно, то выкачивать десятки страниц не придется. В случае с пагинацией достаточно передать параметр, ограничивающий вывод элементов на страницу и номер страницы.
      • +1
        Angular — потрясающий инструмент, я просто был реально ошеломлен, когда увидел в действии как работает databinding в нем.

        Но в тоже время, мне нравится подход DHH, который звучит примерно так: сервер всегда мощнее даже самого мощного десктопа, потому что он под это заточен.
        Поэтому логичнее на клиент отправлять уже готовый HTML, отрендеренный на сервере, а на клиенте только замещать элементы.

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

        Хотя это и увеличивает трафик, но на клиенте сохраняется достаточно простая логика и это будет работать везде без тормозов и отклик сайта получается очень быстрый.
        • 0
          Такой подход хорошо работает тогда, когда канал широк (и всегда есть). Тем более, в Rails 4 с турболинками так оно из коробки и работает. И пока канал широк — всё замечательно. Но стоит ему стать хреновым — и приложение с turbolinks начинает откровенно бесить, потому что ты нажимаешь на ссылку и ничего не происходит, пока отрендеренная формочка не приползёт и javascript её не вставит. В качестве времянки вкорячивается яваскриптовый же прогресс-бар, чтобы снять неопределённость, и так и остаётся.

          Когда же канал узок и нестабилен по определению (даже 3g, знаете ли, не везде есть), то уже начинаешь думать и о логике в клиенте и о том, как бы по сети лишний раз данные без острой нужды не переслать, и что все формочки лучше держать поближе. И Angular тут начинает сиять.

          Так что всё снова сводится в подбору инструмента под задачу (а не наоборот).
  • +1
    Очень люблю эту технологию, хотя часто она бывает магической, но стоит немного понять как работает сам Ruby — все становится на свои места.
    Это лично мое мнение, но я считаю, что самый главный минус Ruby on Rails (и Ruby) — это прожорливость памяти.

    Или взять тот же самый форум Discourse — отличная вещь, но минимальные требования 2 GB, хотя я смог запустить его на 512 MB при помощи сервера puma, но работал он как-то нестабильно.
    Но на 512 MB он не смог выполнить команду assets:precompile, только на 1 GB :) 1 гигабайт памяти на склеивание пару десятков файлов? Кхм…

    Многие могут сказать, что сейчас память стоит значительно дешевле, но чтобы сделать небольшой сайт — иногда думаешь влезет он на 512 MB или раздуется даже под небольшой нагрузкой :)
    Просто платить 20 долларов за тот же изначально пустой форум — это небольшая лишняя трата, по-моему.

    Поэтому сейчас частично перешли на Golang (много разных маленьких пакетов типа Gorilla Mux): 2-5 MB при запуске вместо 50-100 MB и под нагрузкой вырастало максимум до 17 MB вместо около 700 MB в Rails. Скорость ответов тоже радует.

    Хотя вот в Golang нехватает быстрой разработки (Revel не совсем подошел под задачу), иногда приходится переизобретать что-то или писать много больше кода, чем в том же Rails.
    • 0
      Уважаемый, я думаю, что Вы сравнивайте мягкое с теплым. Поясню, RoR это огромный фреймворк с кучей библиотек, которые действительно требуют много памяти + сам руби это интерпретируемый язык. Я считаю, что в Вашем случае уместно было бы сравнивать sinatra или с rake.
      Так же не забывайте, что в discourse только в css 89 файлов + js (которого там действительно очень много) так что это далеко не пара десятков файлов ;) Плюс discourse это не просто пустой форум, там довольно серьезный клиенсткий код на ембере.
      • 0
        Я не спорю, потому что я тут сравниваю интерпретируемый и компилируемый языки.

        Но я сравнил ROR с проектом Golang не просто так — фунционал получился точно таким же. Те же самые «кучи библиотек», только на Golang теперь.
        То есть мы переписали достаточно сложный проект с ROR (больше 30 таблиц со сложными зависимостями, больше 80 view, про assets pipeline — мы остались на Sprockets) на Golang и действительно сократили конфигурацию серверов и стоимость, сами worker'ы потребляет не больше 20 MB памяти в пике, процессор вообще на 1-3%, сервер как-будто на отдыхе :)
        Большой плюс — убрали Sidekiq, заменив их на goroutines и заменили Faye (опять же средствами самого языка сделали).

        Хотя, как я уже сказал, не всегда было так удобно, как на ROR — приходилось писать больше кода, иногда изобретать и переизобретать, написали много библиотек своих (частично выложили их на github).

        Просто часто удивляет, что на достаточно простые задачи тратится столько памяти.
        Возможно я чего-то не понимаю, но по-моему склеить даже 300 файлов в 1 или несколько маленьких не должно занимать много минут и около 1 GB памяти :)
        • +1
          Маленький коммент про склейку… имхо, rails assets pipeline сильно сдал позиции с развитием Grunt/Gulp. И если вы хотите быстро, точно так как вам нужно и удобно работать с assets и делать всякие сборки, вполне можно освоить gulpjs и радоваться жизни.
      • +1
        При всем (не очень большом, если честно) уважении к RoR, есть множество других фреймворков с кучей библиотек, написанных на других интерпретируемых языках, которые съедают намного меньше памяти. Вышупомянутый Django, например.
    • +2
      > Но на 512 MB он не смог выполнить команду assets:precompile, только на 1 GB :) 1 гигабайт памяти на склеивание пару десятков файлов? Кхм…

      Это uglifier выжирает память. К ruby он отношения не имеет, так как написан на javascript. И его можно отключить, тогда компиляция assets будет проходить значительно быстрее.
    • –1
      Я решил не пользоваться метро. Просто платить 20$ за обычное перемещение в пространстве — это небольшая лишняя трата, по-моему. Поэтому сейчас перешел на самокат или велосипед. Хотя вот на самокате не хватает скорости чтобы вовремя на работу приехать, иногда приходится пользоваться маршрутным такси. Это во первых.
      Во вторых, 20$ в месяц, это 1/60 — 1/80 зп среднего разработчика.
  • +1
    Все плюсы рельсовой экосистемы становятся не такими уж и вкусными, когда посмотришь, как оно реализовано внутри, и как используется. Буэээ.
    И конечно же жаль, что умер сайт www.didrailshaveamajorsecurityflawtoday.com/
    • 0
      Пруфы? Что и где именно реализовано и используется плохо? На моём счету уже с десяток pull request'ов в различные гемы (включая rails) и я пока ещё нигде не видел плохого кода, наоборот, самому приходится «подтягиваться», чтоб патч приняли :-)
      • +2
        Дело не в плохом коде, а в архитектурных косяках и болезнях роста. Нет человеческих масштабируемости и многопоточности. Железобетонный MVC-каркас, который проще выкинуть и забыть, чем согнуть и допилить. Даже моей закаленной годами реверсинга и низкоуровневой отладки психике тяжело далось впервые наблюдать dependency hell из-за гемов с нативным кодом.
        Ну и никто вообще не думал о безопасности года эдак до 2012, что удручает, мягко говоря.
        • 0
          >> Железобетонный MVC-каркас
          Вот кстати очень оценили его железобетонность, когда фронтенд стали делать на backbone, и ввиду его вседозволенности каждый разработчик стал пилить так, как ему нравится, в результате нет единого стиля кода по умолчанию, нужны доп ресурсы на надзор/контроль/разработку guidestyles.
    • +1
      С таким отношением в нашей профессии нельзя. Если заглянуть под капот таких продуктов как Apache Hadoop, Hibernate, исходники Java, V8, .NET, ядра Linux или Windows, то там все также печально (в разной степени печальности).

      Что поделать? Жизнь — тлен.

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

      Rails хорош, если с одной стороны, вам недостаточно возможностей CMS, но с другой — у вас нет задачи заниматься real-time вебом и нет заоблачных требований по производительности. Если вы делаете HTTP API или традиционный сайт с элементами интерактива, то Рельсам в этой нише равных нет. Во-первых, сам фреймворк из коробки кучу всего умеет. А во-вторых, для него есть огромное множество библиотек для расширения базового функционала. Часто проекты достигают стадии «готово на 80%» уже в первые дни только за счет того, что инжинеры быстро находят и подключают готовые библиотеки и.

      И пусть оно внутри страшное. Оно работает и часто у него отлично спроектированный публичный API, и значит, каким бы плохим не был код самого фреймворка или плагинов, это никак не портит вашего кода. А ваш код — это как раз то, что волнует вас больше всего.

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