История языков программирования: о прошлом, настоящем и будущем Ruby

    image
    Часто людская молва годами приговаривает тот или иной IT-продукт к «смерти». Если этого не происходит, молва продолжает терпеливо ждать. А если когда-нибудь тот или иной проект закрывается, кто-нибудь обязательно выждет момент и скажет: «А мы ведь говорили, что это случится».

    Сколько лет подряд языку PHP пророчат «смерть»? Но ему, кажется, хоть бы что. А в последнее время он даже стал развиваться активнее. Язык программирования Ruby развивается медленно, с неспешностью, свойственной восточному, а точнее, азиатскому мировосприятию. Естественно нашлись те, кто и ему предвещает скорый закат.

    Однако сообщество Ruby живее всех живых, а некоторые исследования показывают, что его популярность вновь растет. Как бы там ни было, Ruby сумел занять особое место в сфере веб-разработки. Как его создателям удалось этого добиться? Что происходит с ним сейчас? Какое будущее ждет Ruby?

    Создатель Ruby Юкихиро Мацумото (он же «Matz») попытался взять лучшее из своих любимых языков программирования (Perl, Smalltalk, Eiffel, Ada и Lisp) и соединить в рамках нового языка функциональную и императивную парадигмы программирования. Он часто повторял философскую мысль о том, что пытается сделать Ruby естественным, но не простым языком, который отражает жизнь.

    imageОсенью Matz планирует посетить Россию. Его визит будет приурочен к очередной конференции, посвященной Ruby on Rails.

    24 февраля 1993 года считается днём рождения языка Ruby. Но в тот день было придумано только название для этого языка, и никакого кода еще не существовало. Мацумото выбирал между двумя вариантами названия – «Ruby (рубин)» и «Koral (корал)». Был выбран первый вариант, потому что это был камень по гороскопу одного из сотрудников Мацумото.

    Первый публичный релиз Ruby 0.95 был представлен на японской внутренней телеконференции 21 декабря 1995 года.

    Впоследствии ещё три версии Ruby были опубликованы в течение двух дней. Даже в ранних версиях Ruby уже были заложены возможности, которым Мацумото придавал особенное значение: объектно-ориентированное проектирование, классы с наследованием, итераторы, замыкание, обработка исключений и сборка мусора.

    За период с 1995 по 2002 год вышло около двадцати книг о Ruby. В Японии он стал более популярным языком, чем Python.

    Знакомство же международного сообщества началось после перевода его документации на английский язык и создания первых списков рассылки в 1998-м году. После 2000-го года началось распространение Ruby по всему миру, чему способствовало появление англоязычных книг, в первую очередь, «Programming Ruby: The Pragmatic Programmers' Guide» и «Why's (Poignant) Guide to Ruby».

    После релиза Ruby 1.3 в 1999 году заработал первый список рассылок ruby-talk на английском языке, который свидетельствовал о росте интереса к языку за пределами Японии.

    Однако до 2004 года Ruby не был широко известен в Европе и США. Благодаря своим возможностям и большому количеству поддерживаемых платформ Ruby постепенно завоевывал аудиторию.

    В 2004 году появился фреймворк Ruby on Rails. Он был создан Давидом Хейнемейером Ханссоном совместно с 37signals, расширен и усовершенствован усилиями команды разработчиков ядра Rails и сотнями open source разработчиков.

    Переломные моменты


    Ключевыми событиями в истории Ruby стали выход Ruby 1.8.0 в 2003-м и новой версии framework'а Ruby on Rails 2.0 в 2007 году. В это время значительно усилился интерес к использованию языка для серьёзных коммерческих проектов.

    image

    «Итак, Rails сделал Ruby популярным. Это факт. Я стал Ruby-разработчиком, что в свою очередь изменило мою карьеру и дало мне много удивительных возможностей, именно благодаря Rails. Многие рубисты тех дней прошли по тому же пути. Мы все здесь благодаря Rails. Во многих случаях, Rails на самом деле оказал огромное влияние на людей, и буквально улучшил им жизнь. Люди получили лучшие рабочие места, лучшие возможности и хорошие деньги. Это было радикальной сменой условий «игры» для многих из нас», писал Piotr Solnica.

    Если до версии 1.8 язык развивался, сохраняя совместимость с предыдущими версиями, то позже разработчики Ruby, во главе с Якихиро Мацумото, отказались от полной совместимости. Поэтому разработка Ruby разделилась на две ветви: поддержка версий 1.8.* и создание новых версий 1.9.*, которые являются предтечей следующей версии языка, Ruby 2.

    Серьёзные изменения к лучшему произошли с выходом Ruby 1.9.1 в 2009-м и Rails 3.0 в 2010-м году, когда большинство замечаний были учтены и исправлены.

    Достижения


    К 2011 году в Ruby/Rails были реализованы практически все наиболее перспективные технологии и подходы к программированию, таких как разработка через тестирование (TDD), полноценная модель реализации концепции MVC, работа с базами данных через ORM (ActiveRecord), шаблоны проектирования (Design Patterns), использование удобного JavaScript-framework'а Prototype (для простой работы с AJAX), работа с распределённой системой контроля версий Git (Github.com).

    Фреймворк нашел применение в разработке SaaS (Cloud computing).

    Ruby on Rails использовался при создании таких популярных сайтов, как Твиттер, SoundCloud, Airbnb, Diaspora, Groupon, Basecamp, GitHub, Hulu,Scribd, Kickstarter, Change.org.

    31 марта 2012 года по результатам голосования был принят стандарт ISO/IEC 30170 на язык Ruby.

    В ноябре 2015 года вышла версия Ruby 2.3.0-preview1. Уже несколько месяцев сообщество следит за релизом Ruby on Rails 5.0.

    Согласно данным на июнь 2016 года, индекс TIOBE, который измеряет рост популярности языков программирования, показал, что Ruby занимает 10 место. Однако, это на 6 позиций выше по сравнению с прошлым годом.



    Разные Ruby


    Существует несколько реализаций Ruby: официальный интерпретатор, написанный на Си, JRuby — реализация для Java, интерпретатор для платформы .NET IronRuby, Rubinius — написанная в основном на Ruby и базирующаяся на идеях Smalltalk-80 VM, MagLev — другая базирующаяся на Smalltalk разработка от компании Gemstone, Blue Ruby — реализация Ruby для виртуальной машины ABAP, MacRuby — реализация для Mac OS с фокусом на максимальную интеграцию с возможностями операционной системы, mruby — реализация для встраивания в программы.

    За годы существования официального интерпретатора его успели портировать под большинство платформ, включая Unix, Microsoft Windows (в том числе Windows CE), DOS, Mac OS X, OS/2, Amiga, BeOS, Syllable, Acorn RISC OS и другие. Для Windows существует специализированный установщик RubyInstaller и есть возможность запуска под Cygwin для большей совместимости с Unix.

    Со временем Ruby и Ruby on Rails стали практически синонимами – особенно среди непосвященных. Дело в том, что фреймворк Ruby on Rails стал выбором программистов по умолчанию. Он продолжает развиваться и остается по-прежнему бесплатным. Этот фреймворк описывает компоненты веб-приложения в рамках шаблона MVC (Model-View-Controller), а также предоставляет готовую интеграцию с сервером приложения и интерфейс для доступа к базе данных. Указанного инструментария достаточно, чтобы в считанные часы создать и запустить простой блог или частную веб-страницу.

    Существуют и другие Ruby-фреймворки.

    «Merb — проект, созданный Ezra Zygmuntowicz. Он начался как хак, чтобы сделать загрузку файлов быстрой и потокобезопасной. И он прошёл интересный путь от этого хака до модульного, потокобезопасного, быстрого full-stack фреймворка для разработки веб-приложений. Merb имел 3 режима: режим полного стека, режим API и микро-режим, в котором он был урезан до минимума. Это было самой быстрой вещью, когда-либо существовавшей в Ruby-мире. Это было более 7 лет назад», – рассказывает Piotr Solnica.

    В 2008 году команда Merb вошла в состав Ruby on Rails.

    Sinatra — для микросайтов и микросервисов до 50 строк кода. EventMachine — для асинхронных долгоиграющих задач. Если нужно разработать небольшое веб-приложение, то можно использовать Padrino.

    «Padrino — более «сахарный» Sinatra. Достаточно удобен для небольших сайтов. И создания api. Альтернатива, к более избыточному и тяжелому Rails», пишет пользователь «Тостера» под ником frolin.

    Критика


    Что думают пользователи «Тостера» по поводу недостатков Ruby on Rails?

    «Недостаток, который для меня поставил крест на руби и рельсах — отсутсвие вменяемого DataMapping (чуть более сложный и действенный аналог ActiveRecord) со всеми его замечательными DAO\Repository, Registry и так далее». (Кирилл Саксин, PHP-developer, Backend)

    1. Рельса кушает много памяти. Рельса вообще избыточна для мелких проектов. Там лучше идут всякие Синатры, Падрино и так далее.
    2. Трудности долговременной поддержки больших проектов.
    3. Проблемы для хостеров. Создать и обслуживать PHP-хостинг гораздо проще. Есть, конечно locum.ru и heroku, да и всё, пожалуй.
    4. Кадровая проблема. Найти [разработчика] на PHP или Java проще.
    (Дмитрий)

    «После написания пары тройки сайтов понял, что в принципе Rails и Ruby не имеют для меня смысла, и вернулся на Django и Python. По мне, из скриптовых языков Python – наше все. И под Desktop можно писать уже и под мобильные можно с Kivy. Да и тут Node.js уже есть со своей асинхронностью и возможностями в реалтайм-приложениях. Если рубисты не придумают чего-нибудь в ближайшие годы сверх ординарного для популяризации Ruby, он просто умрет, так как он просто станет никому не нужен». (Raidhon)

    Для клиента:

    1. Нет Wordpress. Да! Как только Wordpress перепишут на Ruby, его сразу начнут использовать все, кому не лень.

    2. А можно мне сайт на Joomla? Просто у нас контент-менеджер уже привыкла к её админке.

    3. А почему хостинг стоит 200 рублей? У меня сосед по офису вон за 40 купил.

    Для программиста:

    1. А где фигурные скобочки?

    2. Магия. Очень много магии. Оно всё делает «само», вплоть до квази-версионирования базы данных по датам. К этому надо привыкнуть, что не все готовы делать.

    3. У меня заняло два дня, чтобы смочь подключиться к mysql. Возможно, я не самый опытный программист, но обилие вопросов на stackoverflow, и не только, наводит на мысль, что половина желающих отсеялась на этом этапе и пошла ставить Wordpress.
    (iliyaisd)

    Аргументы в защиту Ruby


    Благодаря детально описанному стандарту, которому должны соответствовать все пакеты и библиотеки на Ruby, разработка дополнений не составляет особого труда. Поэтому среди так называемых Ruby Gems (от англ. — драгоценный камень) можно найти модули для решения практически любых задач — от интеграции с социальными сетями и сторонними сервисами до готовых платформ для электронной коммерции.

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

    По поводу преимуществ этого языка программирования пользователь «Хабра» под ником urvalla в своей статье пишет следующее:
    Язык программирования — это не только синтаксис, сборщик мусора, не только парадигма языка, и даже не столько его философия, в первую очередь — это коммьюнити и та кодовая база, которую это коммьюнити создало. Особенно сейчас, в эпоху OpenSource. И тут у Ruby первый жирный плюс в карму.

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

    По факту, мне приходилось работать и с Rails и с Symfony2 — на реальных приложениях Rails быстрее при одинаковом уровне оптимизации.

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

    Настоящее и будущее


    image
    Конференция разработчиков на Ruby и Rails

    Мы пообщались с некоторыми Ruby-разработчиками по поводу того, что происходит с Ruby сейчас, а также узнали их мнение о перспективах проекта.

    Где востребован Ruby и фреймворки на его основе в наши дни?

    — Ruby своей популярностью во многом обязан фреймворку Ruby On Rails, поэтому основная его сфера применения сейчас — это веб-разработка и всё, что с ней связано.

    Какие у него перспективы?

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

    Какой-то язык или технологию можно считать возможным «убийцей» Ruby?

    — Ничего конкретного на ум не приходит. Есть Elixir и Crystal, но они, на мой взгляд, еще довольно молоды, и использовать их можно только на свой страх и риск. Лично я сейчас смотрю в сторону Go, но не в качестве альтернативы, а скорее дополнения, для решения специфических задач.

    (Александр Типугин. Ruby-разработчик компании «ТМ»)

    Где востребован Ruby и фреймворки на его основе в наши дни?

    — Основная специализация языка программирования Ruby и фреймвока Ruby on Rails – разработка стартапов. На Ruby on Rails очень просто и быстро создавать уникальные и технически сложные проекты, которые вышли за рамки стандартных движков. Нужен сайт визитка — бери Wordpress. Нужен интернет магазин — купи «Битрикс».

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

    Какие у него перспективы?

    — Язык и фреймворк продолжают развиваться, а комьюнити – расти. В этом году в Москву на http://railsclub.ru приезжает создатель языка Юкихиро Мацумото. Все ждут пятой версии Rails, которая должна быть готова в самое ближайшее время.

    Какой-то язык или технологию можно считать возможным «убийцей» Ruby?

    — Хайп вокруг Ruby, который был в прошлые годы, спадает. Ruby перестает быть модным, но продолжает быть эффективным инструментом для построения стартапов. Убийц нет.

    (Олег Балбеков, CEO Evrone)

    И в конце вновь предоставим слово пользователю «Хабра» под ником urvalla:

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

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

    Подробнее
    Реклама
    Комментарии 76
    • –5

      Извиняюсь за минус, мискликнул в Vimium.

      • +7

        Объясните мне кто-нибудь пожалуйста, зачем авторы Руби так сильно пропагандируют идею монки патчинга? Как-бы, в остальных языках это считают смертным грехом, а здесь всё наоборот.


        Ещё среди минусов я бы лично записал то, что RoR не умеет соединяться более чем с одной базой данных. Столько хвалёных отзывов — а такой простой штуки, которая есть, наверное, на любом PHP фреймворке — не сделали.


        Ещё документация к Laravel, например, — намного более качественная, чем для рельс… У рельс и документации-то в общем-то и нет толком, есть лишь набор "инструкций", которые объясняют, как сделать то или иное дело на рельсах. Но это всё-таки немного другое, не документация.


        Ещё я бы записал в минусы Ruby любовь к "размазыванию" классов на кучу файлов. Ну, это тоже частично на тему монки патчинга.


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

        • 0
          Ещё среди минусов я бы лично записал то, что RoR не умеет соединяться более чем с одной базой данных.


          Для этих целей есть не очень живой db-charmer (До Rails 3 включительно) и воплне живой octopus (есть поддержка Rails 4)
          • +1
            Ещё среди минусов я бы лично записал то, что RoR не умеет соединяться более чем с одной базой данных. Столько хвалёных отзывов — а такой простой штуки, которая есть, наверное, на любом PHP фреймворке — не сделали.


            ActiveRecord по дефолту умеет подключаться к нескольким БД (docs).
            Ещё документация к Laravel, например, — намного более качественная, чем для рельс… У рельс и документации-то в общем-то и нет толком, есть лишь набор "инструкций", которые объясняют, как сделать то или иное дело на рельсах. Но это всё-таки немного другое, не документация.


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


            Ни разу не видел чтобы в нормальном приложении класс "размазывался" на несколько файлов.
            • 0

              Да, насчёт ActiveRecord я ошибся, прошу прощения.


              По документации уже написал чуть ниже.


              Насчёт последнего — в общем-то, всё дело в монки патчах, которые накладываются друг на друга разными библиотеками, что, в целом, вообще неправильно. Эта тема подробно была описана одним из руби-разработчиков, перевод статьи есть на хабре. Хотя, из комментов к этой же статье, я так понял, что для руби уже реализовали механизм Refinements. В этом свете, хотелось бы узнать, насколько активно его стали применять на практике в разработе рельсов и других библиотек, и действительно ли этот механизм полностью решает проблему конфликтов при монки патчах.

              • 0
                Ни разу не видел чтобы в нормальном приложении класс "размазывался" на несколько файлов.


                A Вы код самого Rails смотрели? Тот же ActiveRecord::Base — просто гигантский класс, размазанный на десятки файлов внутри самого фреймворка и ещё сотни файлов из сторонних гемов расширяют его же.
                • 0
                  Я изначально подумал про N файлов вида:
                  class A
                    ...
                  end

                  ActiveRecord::Base — просто гигантский класс, размазанный на десятки файлов
                  Да, но он состоит из более-менее логичных модулей.

                  сотни файлов из сторонних гемов расширяют его же.
                  это другой вопрос.


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

                    Что Вы имеете в виду?
                    В самом приложении не должно быть Rails или гемов, расширяющих существующие классы?
                    Или если Вы выносите такие случаи в гемы — то это ok, а вот если в коде самого приложения — то это фу? Это ж двоемыслие какое-то...

                    • 0

                      Расширять существующие классы вообще не ок. Ни в своем прилжении, ни в гемах. Но, к сожалению, это есть.


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

                  • +1
                    А знаете зачем так сделано конкретно в ActiveRecord::Base?
                    А чтобы у вас была возможность подключить любой из этих десятков файлов отдельно в свой «Plain Old Object». ActiveRecord::Base всего лишь делает это за вас подключая всё.

                    Также никто вас так же не заставляет использовать всякий DSL который накинет вам модулей в классы (те же вызовы rolify, devise еще чего-нибудь) все можно подключать отдельно. Заинклюдте все руками. Невозможного нет ничего.

                    P.S. Да иногда есть гемы которые написаны криво, ну так помогите сообществу, сделайте pull request.
                    • 0
                      Так я ж не говорю, что это всегда плохо, для базовых классов при желании можно найти плюсы. Но это не только в базовых классах, это в принципе по коду всего фреймворка встречается.
                      А человек был в неведении, что в любом Rails-приложении есть десятки классов, размазанных на несколько файлов.
                      По другому можно делать, но это грести против сообщества. Поэтому 'любовь к «размазыванию» классов на кучу файлов' — это факт, имеющий место в Ruby-сообществе. Поэтому странно видеть утверждения, что приложение, в котором это встречается, априори ненормальное.
              • 0
                Про monkey patching ничего сказать не могу, но…
                Справедливости ради, в рельсах можно работать более чем с одной базой данных. К примеру, если модель SomeModel лежит в другой БД, достаточно написать:
                class SomeModel < ActiveRecord::Base
                  establish_connection "another_db_#{Rails.env}"
                  ...
                end
                
                и добавить соответствующие записи в config/database.yml. Ну или можно использовать concern — что универсальнее. Примерно так же можно использовать прямые запросы к разным базам.
                Документация к рельсам — вам мало guides.rubyonrails.org, api.rubyonrails.org, apidock.com? Куда уж больше-то?
                С классами тоже имхо все в порядке — если не размазывать их специально, а соблюдать структуру. Каждый класс, каждый модуль выполняют определенную функцию. Или это плевок в сторону MVC в целом?
                В-общем, по итогам своей работы за последние пару лет, я практически полностью перешел на Rails в своих проектах, и более чем доволен им :)
                • 0

                  Нет, вовсе не плевок. По большей части, я задал вопрос чтобы увидеть адекватные ответы. Спасибо за ссылки и разъяснения, посмотрю на досуге.

                  • +1
                    Или это плевок в сторону MVC в целом?


                    Меня тут больше расстраивает использование этой триады в контексте рельсов. Ну то есть еще до рельсов существовал MVC, и еще до рельсов был придуман mediating controller MVC. И вот MVC в рельсах совсем не то значит.

                    И на волне популярности рельсов вот это "немного не то" насктолько распространилось, что сейчас проще просто отказаться от использования этой аббривиатуры целиком и полностью ибо она потеряла свой смысл…

                    Сейчас львиная доля бэкэнд разработчиков считают что MVC это когда логика манипуляции сущностями в контроллерах. Это примерно тот же уровень урона для начинающих как UML концентрирующий внимание разработчиков на классы а не на взаимодействие объектов.
                    • 0
                      Опишите, пожалуйста, правильное с вашей точки зрения понимание MVC, и, если можно, ключевые различия с рельсовским пониманием MVC.
                      • +3
                        правильное с вашей точки зрения понимание MVC


                        И вот тут сложность. Проблема в том что все они правильны, просто они разные и для разных задач. Различия заключаются в том как эти M, V и C взаимодействуют друг с другом. Аббривиатура из названий элементов никак не может это показать.

                        Например в smalltalk MVC (оригинальное MVC если хотите) подразумевалось что View представляет собой полноценный объект реализующий активное представление. Оно подписывается на события модели и обновляет само себя, полностью отвечая за реализацию GUI. Ну и в те времена это все же подразумевало много кода для работы с GUI.

                        Контроллеры же подписывались на события контролов UI (например клик по кнопке, ввод данных в текстовое поле) и вызывали методы приложения. Поток данных шел ровно по кругу, никаких двусторонних взаимодействий. Ну и опять же View могло быть несколько на скрин, можно было делать композицию элементов и т.д. То есть это не "архитектура" а просто "шаблон проектирования", который описывает кусочек системы в очень маленьком масштабе.

                        Со временем появились полноценные UI фреймворки, сегодня вон вообще декларативное представление в моде и необходимость в активных вьюшках пропала. Да и тот факт что и view и controller зависили от модели слегка повышали связанность. В итоге перешли к использованию MVP и подобных подходов, где вся вьюшка стала пассивной и логика из нее вытекла в контроллер, который начал называться презентер. Теперь за управление и взаимодействие с UI стал отвечать один компонент. Это существенно упростило дело. Схожую проблему в мелкософте решили при помощи MVVM, которая ввела концепцию биндингов. Ну и куча разных вариантов еще появилась.

                        В RoR же MVC намного ближе к Model-View-Adapter по схеме взаимодействия. Однако разделение ответственности не такое явное, но для решения задач этого достаточно.

                        То есть проблема не в самом MVC или не в том как RoR интерпритирует эти три буквы, а в людях, которые начинают думать что в принципе есть единственное правильное MVC.
                    • 0
                      Да решений таких много. Можно создать класс OtherActiveRecord < ActiveRecord::Base, там указать другую базу для коннекта и потом наследоваться от него. Тогда получим возможность создавать модели с автоматическим подключением к другой базе. Это топорный метод, есть и более интересные, но иногда это сделать проще.
                    • 0

                      Пропаганды не видел, скорее про это пишут в смысле "даже так вот можно". Сам же манки патчинг довольно удобен, особенно сейчас, когда очень много OSS. Часто либа может иметь баг или просто не иметь поддержки нужного функционала, которая решается добавлением пары строчек. Часто такие штуки фичи не нужны всем, только в одном приложении. В этой ситуации есть несколько решений:


                      • сделать PR, и ждать когда примут и зарелизят,
                      • форкнуть либу, и потом периодически рибэйзить на апстрим,
                      • сделать манки патч, и пользоваться оригиналом.

                      Конечно, в зависимости от количества изменений 1й и 2й варианты могут быть предпочтительны. Но по мне 3й варинат лучше, если правок действительно немного. И манки патчинг в руби удобен (в жс вон что люди придумывают: https://github.com/jhnns/rewire).


                      Ну и плюс во время разработки. Можно проверить локально, переопределив сначала методы, проверить. А затем вернуться к 1му/2му варианту.

                      • +2

                        Вы всё-таки не правы, честно. К сожалению, как я вижу, на деле манки патчи используют повсеместно в Ruby-сообществе, и это именно считается нормальной практикой, которая в том числе и пропагандируется.


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


                        По сути, меня подобное довольно странное отношение к коду и остановило от перехода с всеми унижаемого PHP на Ruby в своё время. Вы меня извините, но в PHP вообще такое невозможно, чтобы два разных модуля вдруг каким-то образом вызвали конфликт друг у друга. Мне просто приятнее и спокойнее использовать тот инструмент, поведение которого я могу контролировать в большей степени.


                        И ваш пример со ссылкой на JS-библиотеку для изменения кода для тестов тоже не очень-то годится в качестве довода. Одно дело в тестах создавать заглушки — и совсем другое дело писать основной код приложения подобным образом.

                    • +3
                      Будущее ruby, по личным ощущениям:

                      * Ruby/Rails никуда не уходят, до сих пор адекватный инструмент решения многих задач. Конкурентов особо нет. Впрочем, пик развития недавно прошел.
                      Цитата из статьи:
                      > Ruby перестает быть модным, но продолжает быть эффективным инструментом для построения стартапов

                      * Go никаким боком не конкурент хотя часто используется совместно — для нагруженных участков

                      * Многие опытные разработчики сейчас переходят с рельс на Elixir/Phoenix (сюрприз, написанные людьми из команды рельс — с исправлением накопленных за годы развития косяков).
                      • +1
                        RoR умеет соединяться более чем с одной базой, причем из коробки и довольно удобно: либо указал в модели, куда лезть за данными, либо явно в запросах.
                        Например, www.safaribooksonline.com/library/view/advanced-rails/9780596510329/ch04s04.html

                        Документация отличная, с учетом версий, например: apidock.com/rails/ActiveRecord/Base
                        • 0

                          Спасибо за первую ссылку. Да, мои знания устарели, прошу прощения, тут видимо я явно ошибся.


                          Но насчёт второго. Ну, неплохо, да. Но всё-таки, посмотрите как удобно сделали документацию к Laravel. Я ожидал увидеть для рельсов что-то подобное, но когда изучал их, то из официальных данных нашёл только гайды (про них я уже писал — это не совсем документация, эти гайды объясняют основы, но не объясняют тонкости).

                          • +1
                            Вот это чем хуже?
                            • –2

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


                              Да, согласен, эта моя претензия тоже теперь может считаться необоснованной.

                            • 0
                              Ну Laravel так то вообще еще одна попытка перенести Rails на PHP. В частности много вещей, вплоть до хелперов link_to и методов в Eloquent, было взято из рельс.
                              Насчет документации, я считаю, в рельсах она лучше по удобству, например можно сравнить 1 в 1 laravel.com/api/5.2/Illuminate/Database.html и apidock.com/rails/ActiveRecord/Base.
                              А если охота доку как в Ларе, то можно глянуть и на hanamirb.org/guides/getting-started, таки одними рельсами руби комьюнити не заканчивается.
                            • 0
                              Ещё есть совершенно прекрасные документации на Relish, например, для Rspec. Главная прелесть в том, что на самом деле — это фичи cucumber'а (или, другигими словами, поведенческие тесты). Т.е. разработчик пишет поведенческие тесты, а на выходе получается актуальная (за счёт того, что это всё-таки тесты) и подробная документация с кучей примеров (ещё раз: это тесты).

                              Цитата:

                              This is the official documentation site for RSpec. Much of the documentation you see here is
                              written with Cucumber, which, like RSpec, provides executable documentation. The
                              Cucumber features you see here have all been run against RSpec's codebase, serving as
                              specification, documentation and regression tests of the behavior.


                              P.S. Напомню, что Cucumber тоже родился в недрах рубишного сообщества.
                            • 0
                              Рельсы нравятся всем, но для меня сильно портит картину отсутствие такой же удобной IDE как для фреймворков из мира java/php/python. Из-за метапрограммирования тот же работающий в 100% случаев автокомплит сделать просто нереально. В основном по работе имею дело с Symfony и в документацию/stackoverflow лезу раз в неделю максимум: go to definition + автокомплит работают почти идеально (я говорю про PhpStorm + плагин Symfony), в запутанных случаях выручит xdebug. Я всегда смогу найти, почему этот код работает именно так.

                              При работе с рельсами go to definition и автокомплит уже далеки от совершенства и читать доки и SO приходится в разы чаще. Помогает, но частично:
                              * Использование аннотаций
                              * Дебаг
                              * Rails console

                              Подскажите, как кто решает проблему поддержки Rails в IDE?
                              • НЛО прилетело и опубликовало эту надпись здесь
                                • +2
                                  Не понимаю за что минусуют. Юзаю Atom + подобие TDD + binding.pry
                                  Хочешь узнать где находишься? в дебаггере show-method, хочешь узнать что хранится в сущности? ls ApplicationController и так далее. Это просто другой подход, скорее всего непривычный для тех кто сидел на IDE и особенно на языках со строгой типизацией. Магия дебажится, вот хорошая статья на эту тему: http://www.schneems.com/2016/01/25/ruby-debugging-magic-cheat-sheet.html
                                  Зато многие неявные вещи зачастую страхуют от косяков. Для обратных случаев есть тесты на все вокруг. Как можно писать проект без нормального тестового покрытия мне например уже не понятно.
                                  • 0

                                    Справедливости ради разработчики той же Symfony фигачат все в textmate и довольны. На самом деле и без автокомлита можно с этим фреймворком работать эффективно (то есть нет дурацких AbstractFactoryFactory), просто с ним удобнее.

                                    • НЛО прилетело и опубликовало эту надпись здесь
                                  • +4
                                    RubyMine не пробовали? https://www.jetbrains.com/ruby/
                                    • 0
                                      Заставляю себя пробовать каждую новую версию RubyMine, пока ни в одной из них я не смог работать дольше чем 15 минут. В последний раз причина была в том, что какая-то стандартная для OSX комбинация клавиш, которой я часто пользуюсь, в RubyMine имела совсем неожиданное поведение. А еще — почему-то для комментариев в коде используется уродский oblique вместо italic, хотя это мелочь, конечно, но глаз режет (псст, разработчики RubyMine, WHY?!). Еще много чего не понравилось, но я уже забыл.

                                      Поэтому я до сих пор приверженец старого доброго TextMate 2 (для ruby у меня набралось много сниппетов и команд) в связке с постоянно запущенным pry в консоли и не парюсь по этому поводу.
                                      • 0
                                        Я не пробовал конкретно RubyMine, но активно использую другие продукты от JetBrains — PyCharm и Idea IDE. Эти студии разработки можно очень хитро конфигурировать, вплоть до смены горячих клавиш на vim и emacs.
                                        Кстати на счет последнего, подозреваю, что для Руби там тоже все ок.
                                        • 0
                                          Я одно время писал и на RubyMine и на Atom, остановился на emacs. Конфигурируй не хочу. А вообще особого смысла в IDE не вижу
                                          • 0

                                            В vim, emacs или где-то еще можно перейти к определению метода в геме? Я пока видел только в рубимайне. Когда-то думали перейти в что-то другое, но без этой фичи это не вариант.

                                            • 0
                                              Я пробовал настраивать go to definition еще в Атоме, но толком ничего не получилось. В emacs даже не пробовал. Но вообще это конечно удобно
                                              • 0

                                                В случае других языков можно с ycmd (для rust, js, ts, python, c, c++), но ruby в нём пока не поддерживается. Для ruby может заработать eclim.

                                                • 0

                                                  Это автодополнение. Я имею ввиду что когда есть написанный код, можно клацнуть по методу и перейти к его объявлению. Да, это не всегда показывает правильный метод или показывает 10 вариантов, но это невероятно удобно.

                                                  • 0

                                                    Не беспокойтесь, я знаю что такое go to definition.


                                                    Тот же ycmd для rust у меня даёт и автодополнение (полноценное, в автодополнении доступны методы соответствующих типажей, реализуемых объектом), так и go to definition (в том числе и в исходники самого rust'а). Вообще go to definition для динамических языков или при использовании AOP — крайне сложная вещь (учитывая, например, monkey patches, использование method_missing, define_method и прочее метапрограммирование). IDE для тех же RoR часто анализируют описанную в коде схему базы, чтобы дать автодополнение для findby, select и прочих.


                                                    Что умеет eclim для динамических языков — не знаю, не использовал. Просто предположил что ядро эклипса может давать результат, сравнимый с тем, что дают продукты jetbrains.

                                              • 0
                                                Я несколько лет работал в емаксе, а потом у меня начался туннельный синдром. После этого я переехал на PyCharm и стал больше кликать мышкой, стало заметно легче, хотя и скорость работы снизилась :)
                                            • +1
                                              Ну вообще RubyMine предоставляет несколько предуставноленных keymaps, в том числе и TextMate-подобную. По поводу шрифтов – мне никогда не мозолило глаза, дело вкуса, наверное. Да и в целом, RubyMine предоставляет множество настроек. Если вас не устраивают дефолтные (меня они сразу устроили, особенно радует тема Darkula), то можно потратить какое-то время на кастомизацию среды под себя.
                                              • 0
                                                В настройках стилей как я помню стоял именно italic, шрифт InputMono, но отображался он как перегнутый oblique, хотя в TM с тем же шрифтом италик отображался как надо.
                                                И, да, я пробовал TextMate-подобную, там что-то не все работало как хотелось, возможно это были кеймапы 1-ой версии. Я было начал исправлять под себя, но потом понял, что у меня нету столько времени с ним ковыряться.
                                              • +1
                                                какая-то стандартная для OSX комбинация клавиш, которой я часто пользуюсь, в RubyMine имела совсем неожиданное поведение


                                                workaround — поправить в настройках, proper fix — file a bug
                                                почему-то для комментариев в коде используется уродский oblique вместо italic


                                                см. выше
                                              • +1
                                                Про RubyMine и говорил, в других Ruby-IDE все в этом плане совсем плохо. Но по сравнению с работой с PHP/Java все как-то печально:

                                                Автокомплит не работает уже в таком простом случае


                                                Помогают частично аннотации


                                              • 0
                                                Я использую VIM вместо IDE. Автодополнение там не супер, но кое-как работает. Go to definition работает отлично. Но VIM настолько хорош во всём остальном, исключая автодополнение для Ruby, что я ему эту слабость прощаю.
                                                • 0

                                                  Гем pry (debbie — тот же при, только с набором расширений), может очень помочь. Я без show-method, show-doc теперь как без рук.

                                                • +1
                                                  Я вот использую ruby в качестве языка общего назначения для автоматизации всяких вещей aka shell scripting. В его пользу говорит удобство, выразительность, скорость разработки. Например, сделать какую-нибудь cli тулзу дело одного вечера с помощью rake и thor. Магия и сахар в принципе не раздражают, после перла даже нравятся — в перле магии больше, но и запутаться легче.

                                                  От Python, извините, воротит. Мне он кажется неудобным и даже в какой-то мере некрасивым.

                                                  Что не очень нравится в Ruby, похоже он все-таки относительно медленный. Делал конвертер больших json файлов в csv, написался он быстро, а вот выполнялся чуть ли не часы. После опыта написания подобных вещей на перле такого не ожидаешь.
                                                  • +1
                                                    Что я понял за последнее время, так это то, что проблему прожорливости памяти в ruby-приложениях создали сами разработчики гемов, по умолчанию расширяя суперклассы при загрузке библиотеки. Как-будто я не в состоянии самостоятельно включить нужный мне модуль в класс, где реально нужен функционал этого модуля! В итоге, приложение содержит кучу неиспользуемых методов, объектов, мета-конскрукций, макросов и хуков. ActiveRecord и ActiveModel — одни из таких гемов, на мой взгляд благодаря довольно п****стическому принятию коммитов, лишь бы тесты проходили.

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

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

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

                                                    Но без фанатизма: если что-то вырастает из ruby или изначально не подходит для разработки на нем, тогда уже используются другие языки. Например, я бы не стал писать на ruby WebSocket-сервис, обрабатывающий множество долгих запросов (в теории можно JRuby). Поэтому не понимаю нахера козе баян в Rails 5 включили ActionCable, он же на продакшене будет работать как надо в очень ограниченных случаях. Пользуясь случаем кинусь какашкой в DHH, он хоть и внес в свое время хороший вклад, но мне его влияние на язык и сообщество кажется скорее негативным.
                                                    • +5
                                                      Моя главная претензия к экосистеме ruby и RoR в сложившейся традиции mokey patching и неявного внедрения в чужие классы. Вот только на днях потратил кучу времени чтобы понять, что гемы rollify (для ролей) и geocode не дружат т.к. оба пытаются заинжектить в базовый класс метод adapter. Да, *иногда* иметь такую возможность круто, но когда это становится нормой то начинает мне напоминать спагети php код эпохи до фреймворков. Это не значит, что я в ближайшее время откажусь от RoR, он позволяет мне решать поставленные задачи быстро и конечный результат всех устраивает, да и спрос на рынке труда падать не собирается. Но проблема есть, и вылечить ее просто так не получится.
                                                      • +1
                                                        Любопытный язык написанный под влиянием Ruby: crystal-lang.org
                                                        Еще молодой.
                                                        Слежу за ним с интересом.

                                                        Если будет развиваться/расти — можно будет программировать с привычным синтаксисом Ruby и использовать быстрый компилируемый язык программирования.
                                                        • +1
                                                          Все следят с интересом ^^
                                                          С виду развивается в нужном направлении. Все менее смахивает на Ruby, но не вызывает отторжение.
                                                          При грамотном пиаре ждет светлое будущее.
                                                          Поигравшись с Kemal-ом (по образу синатры), несложный API или простенькие сайтики уже можно городить. При запуске не ест ни память, ни процессор. Деплой тоже «несколько проще» рельсового.
                                                          К предыдущему посту про ActionCable в пятых рельсах — те же мысли возникли. Веб-сокеты на Kemal-е выглядят аккуратнее.
                                                        • +1
                                                          Занимаюсь программированием более 20 лет. Изучил Ruby 5 лет назад, использую Ruby on Rails 4 года — пишу сайты различной сложности — от простых сайтов-визиток (за 1-2 дня) до интернет-порталов (без команды, самостоятельно). Только позитивные и положительные эмоции от программирования на Ruby. За всю свою карьеру, изучив и использовав множество языков программирования, могу с уверенностью сказать: Ruby — наиболее изящный, удобный и внятный из языков программирования (конечно из тех, которые я знаю).
                                                          Не испытываю никаких проблем с сопровождением проектов на Ruby on Rails. Все достаточно логично и удобно.
                                                          Проекты предпочитаю писать «с нуля» и по возможности самостоятельно реализовывать механизмы, по минимуму используя сторонние библиотеки — мне интересно программировать, и доставляет удовольствие разработка (кстати, именно программирование на Ruby с удовольствием). При этом все получается легко, быстро и качественно.
                                                          Тем, кто прочит закат и «смерть» Ruby, могу посоветовать только одно — не нравится вам (а, скорее, не получается) — ну и не обращайте внимания — для вас Ruby даже и не появлялся на свет. И не надо пинять на зеркало, коли… ну отойди ты от зеркала — не мучай изображение! )))
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                            • +2

                                                              Ну вот, уже MVC из Rails называют классическим.

                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                • 0
                                                                  Чуть выше уже написали про классическое MVC: https://habrahabr.ru/post/303024/#comment_9652556
                                                                  • 0

                                                                    И в целом с точки зрения модели все хорошо:


                                                                    • СУБД — деталь реализации модели и мы о них можем вообще не говорить.
                                                                    • модели могут инкапсулировать в себе другие модели (то есть в качестве модели может выступать любой объект, который в своб очередь работает с другими моделями).
                                                                    • модели активны. То есть управление состоянием это задача модели, а контроллеры могут только просить что-то сделать. Точно так же представление может подписываться на события и обновлять само себя но вот тут я не уверен...

                                                                    Насколько я помню в rails таки использует пассивные вьюшки, что превращает "классический MVC" в mediating-controller MVC. Что уже как бы не "классическое". Но это даже хорошо. Хотя если я тут не прав — буду рад если меня кто-нибудь подправит.

                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                      • 0
                                                                        Насколько я понимаю, в классической реализации View был больше похож на то, как это сделано в AngularJS. А возможность вызывать модель из View — это совсем о другом, и скорее это как раз нежелательная возможность.
                                                                      • 0
                                                                        Никто вам не запрещает сделать так <%= User.first.name %>


                                                                        Никто не запрещает но это не ок. Это как лесть в шаблонах в базу данных. Отсутствие разделения ответственности.
                                                                        где модель полностью обособлена и общается с View только через адаптер( контроллер ).


                                                                        так так оно по сути чаще всего и происходит. Адаптер забирает данные и заполняет данными пассивное view. Можно сделать view активной но это не приветствуется насколько я понимаю.
                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                          • 0
                                                                            Итого, давайте обобщим. "классическое MVC" для меня в случае RoR будет:
                                                                            • активная вьюшка, то есть какой-то объект который выделяется на соединение по WebSocket и предоставляет какое-то представление данных клиенту.
                                                                            • Контроллер ничего не знает о view. То есть он максимум может подписаться на события из объекта вьюшки и обрабатывать асинхронные действия пользователей конвертируя их в синхронные сообщения моделям.
                                                                            • Модель активна и предоставляет события для view


                                                                            Вот в таком ключе соглашусь что можно использовать smalltalk MVC 1979-ого года выпуска. Но мы в таком случае сильно усложняем все так как взаимодействие между клиентом и сервером становится нифига не stateless.
                                                                            Тут не может быть MVA потому что View имеет ссылку на Model.


                                                                            View именно имеет ссылку на Model или ее дает контроллер? В классическом MVC да, модель является зависимостью View (причем обязательной зависимостью) и ничего не знает о контролере. А если мы передаем во view модель (как это сделано в большинстве фреймворков которые называют себя MVC) то там вместо модели может быть любой другой объект предоставляющий состояние. И тогда как бы… все взаимодействие так или иначе проходит через адаптер (контроллер).
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                              • 0
                                                                                Я так понимаю вы вообще Rails в глаза не видели если задаете такие вопросы?


                                                                                Я пытаюсь добиться полного взаимопонимания. В коммерческой разработке RoR не использовал (я же похапэшник), только для самообразования. А вопросы я задаю просто для того что бы понять, об одном и том же мы говорим или нет.
                                                                                Модель можно вызвать без участия контроллера, ничего никуда не нужно передавать, просто вызываете прямо во View.


                                                                                Это просто глобальный доступ к состоянию. Разница не большая. Это не делает вьюшку активной, это просто слегка ломает разделение ответственности. Вьюшка может даже не докадываться что это модель, это может быть что угодно. Так что прямого взаимодействия view и модели не закладывалось.
                                                                                Вызвав модель во View вы уже подписались на цикл событий модели WebSocket тут не обязателен.


                                                                                В рамках request/response модели выполнения (stateless апишки) не должно быть цикла событий модели, вьюшка тупо забирает текущее состояние и на этом все.
                                                                                Модель независима как от контроллера так и от View.


                                                                                Именно так, но только вот контроллер знает о View. Вот в чем соль. Именно контроллер решает какое view использовать. А стало быть мы можем говорить о том что мы имеем дело именно с Model-View-Adapter.
                                                                                Судить об оригинальной smalltalk MVC 1979 можно лишь относительно, как и притянуть её реалии к современному веб приложению.


                                                                                Нет, весь спор разгорелся только из-за того что вы назвали "архитектуру MVC" в RoR классической. И это вводит в заблуждение так как есть "более классическая" версия. Я бы согласился если бы вы сказали что RoR реализует классическую MVC Model2, но по факту все это лишь MVA которую используют почти все бэкэнд фреймворки вне зависимости от языка.
                                                                                И на этом закончим наше обсуждения, до момента как вы испробуете Rails в реальном разработке.


                                                                                Спор на самом деле пустой. Он всего-лишь подтверждает что лучше вообще не использовать MVC как название подхода, просто потому что оно сильно привязано к контексту. А Rails использовать я не хочу, во всяком случае сейчас.
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                  • +1
                                                                                    И после этого ты получаешь минус скорее всего от самого судьи комментатора.


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


                                                                                    Я достаточно работал с RoR что бы понимать как там что. И я не говорил о том что там что-то плохо, для своих задач там все весьма грамотно. Я просто придрался к словам "классический MVC".

                                                                                    p.s. Laravel я тоже не использую в коммерческой разработке.
                                                                            • 0
                                                                              На момент создание фреймворка не было технологии позволяющей оповещать реалтайм со стороны бекенда фронтенд и активно перерисовывать View.


                                                                              Long Polling уже давно был. Задолго до вебсокетов.

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

                                                                              Рельсы просто перепутали понятия, а народ подхватил.
                                                                    • +2
                                                                      Классической реализацией концепции MVC принято считать версию именно с активной моделью.


                                                                      Да. И это прежде всего такая модель, которая оповещает о своих изменениях всех подписчиков. View сами подписываются на нужные observable события модели и при изменении сами обновляются. Обычно используется паттерн Observer.
                                                                      Тогда назревает вопрос, если в Rails не классическое MVC то какое по вашему?


                                                                      1) Модели по-настоящему активны: они содержат бизнес-логику, позволяют подписываться на их изменения и оповещают всех подписчиков, когда эти изменения происходят.
                                                                      2) View тоже более активны: содержат логику представления, сами знают, как себя отрисовать, подписываются на нужные модели и отображают их данные. Когда модель оповещает об изменениях, вьюхи сами перерисовывают себя.
                                                                      3) Controller обрабатывает действия пользователя, которые он совершает во View (обычно, это нажатие кнопочек) и вызывает соответствующие методы модели. Это просто клей, связывающий события из View с методами моделей.

                                                                      В итоге получается, что-то вроде модного нынче Flux. Поток данных преимущественно идёт в одном направлении: пользователь что-то жмёт, контроллер вызывает метод модели, модель "пересчитывается" и оповещает о своём новом состоянии всех подписчиков (т.е. View), представления обновляются в соответствии с новыми данными из модели и пользователь видит эти изменения. Схема такая:
                                                                      User -> Controller
                                                                       ^        |
                                                                       |        v
                                                                      View <- Model


                                                                      Разумеется, в рамках серверного рендера HTML и протокола HTTP реализовать подобное без Long Polling трудно.

                                                                      В рельсах же используется MVP, эдакая адаптация MVC под мир веба. Тут всё проходит через контроллер: контроллер реагирует на действие пользователя, обращается к модели, получает из неё данные для отображения, получает нужное представление и рендерит это представление с данными из модели. Тут схема несколько другая:
                                                                      User <-> Controller <-> View
                                                                                  ^
                                                                                  v
                                                                                Model


                                                                      И непонятно по какой причине, авторы рельс назвали это MVC. Вот с тех пор все и путаются.

                                                                      К слову, в JSF можно было легко организовать MVC куда более приближенное к классическому.
                                                                • +5
                                                                  Смерть языка можно констатировать с появлением статей про то, что он не мёртв :)
                                                                  • 0
                                                                    Я бы еще упомянул такую вещь как Chef.
                                                                    • 0

                                                                      Почему? Почему COBOL?

                                                                      • 0
                                                                        Ruby перестает быть модным
                                                                        По-моему наоборот, Ruby сейчас на пике моды… Появляются курсы типа «Врубиться в Ruby. Научим кодить с нуля». Люди далёкие от программирования начинают интересоваться как освоить Rails. В общем, настолько моден, что невольно вспоминается байка про банкира и чистильщика обуви.

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