Часто людская молва годами приговаривает тот или иной IT-продукт к «смерти». Если этого не происходит, молва продолжает терпеливо ждать. А если когда-нибудь тот или иной проект закрывается, кто-нибудь обязательно выждет момент и скажет: «А мы ведь говорили, что это случится».
Сколько лет подряд языку PHP пророчат «смерть»? Но ему, кажется, хоть бы что. А в последнее время он даже стал развиваться активнее. Язык программирования Ruby развивается медленно, с неспешностью, свойственной восточному, а точнее, азиатскому мировосприятию. Естественно нашлись те, кто и ему предвещает скорый закат.
Однако сообщество Ruby живее всех живых, а некоторые исследования показывают, что его популярность вновь растет. Как бы там ни было, Ruby сумел занять особое место в сфере веб-разработки. Как его создателям удалось этого добиться? Что происходит с ним сейчас? Какое будущее ждет Ruby?
Создатель Ruby Юкихиро Мацумото (он же «Matz») попытался взять лучшее из своих любимых языков программирования (Perl, Smalltalk, Eiffel, Ada и Lisp) и соединить в рамках нового языка функциональную и императивную парадигмы программирования. Он часто повторял философскую мысль о том, что пытается сделать Ruby естественным, но не простым языком, который отражает жизнь.
Осенью 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 году. В это время значительно усилился интерес к использованию языка для серьёзных коммерческих проектов.
«Итак, 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)
Для клиента:(iliyaisd)
1. Нет Wordpress. Да! Как только Wordpress перепишут на Ruby, его сразу начнут использовать все, кому не лень.
2. А можно мне сайт на Joomla? Просто у нас контент-менеджер уже привыкла к её админке.
3. А почему хостинг стоит 200 рублей? У меня сосед по офису вон за 40 купил.
Для программиста:
1. А где фигурные скобочки?
2. Магия. Очень много магии. Оно всё делает «само», вплоть до квази-версионирования базы данных по датам. К этому надо привыкнуть, что не все готовы делать.
3. У меня заняло два дня, чтобы смочь подключиться к mysql. Возможно, я не самый опытный программист, но обилие вопросов на stackoverflow, и не только, наводит на мысль, что половина желающих отсеялась на этом этапе и пошла ставить Wordpress.
Аргументы в защиту Ruby
Благодаря детально описанному стандарту, которому должны соответствовать все пакеты и библиотеки на Ruby, разработка дополнений не составляет особого труда. Поэтому среди так называемых Ruby Gems (от англ. — драгоценный камень) можно найти модули для решения практически любых задач — от интеграции с социальными сетями и сторонними сервисами до готовых платформ для электронной коммерции.
Все, что нужно для использования сторонней библиотеки — это описать зависимость своего проекта от какой-то библиотеки, находящейся в удаленном или локальном репозитории, и при следующей сборке эта библиотека автоматически загрузится в приложение. Это также упрощает миграцию проекта между разработчиками, так как нет необходимости вручную делиться зависимостями для сборки проекта, пишут в одном из обзоров Ruby.
По поводу преимуществ этого языка программирования пользователь «Хабра» под ником urvalla в своей статье пишет следующее:
Язык программирования — это не только синтаксис, сборщик мусора, не только парадигма языка, и даже не столько его философия, в первую очередь — это коммьюнити и та кодовая база, которую это коммьюнити создало. Особенно сейчас, в эпоху OpenSource. И тут у Ruby первый жирный плюс в карму.
Известно утверждение о том, что Ruby медленный. И поспорить сложно, ведь Ruby интерпретируемый язык. И что характерно, чаще всего я это слышу от тех, кто пишет (исключительно) на PHP, который тоже интерпретируем, и по скорости в синтетических тестах находится примерно на том же уровне. Скорее всего, это отголоски дурной славы старых версий.
По факту, мне приходилось работать и с Rails и с Symfony2 — на реальных приложениях Rails быстрее при одинаковом уровне оптимизации.
И не нужно забывать, что и главная нагрузка, и бутылочные горлышки, зачастую — это базы данных, а веб-приложение – это всего-лишь прослойка бизнес-логики. А такая прослойка неплохо масштабируется.
Настоящее и будущее
Конференция разработчиков на 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)
saggid
09.06.2016 19:34+7Объясните мне кто-нибудь пожалуйста, зачем авторы Руби так сильно пропагандируют идею монки патчинга? Как-бы, в остальных языках это считают смертным грехом, а здесь всё наоборот.
Ещё среди минусов я бы лично записал то, что RoR не умеет соединяться более чем с одной базой данных. Столько хвалёных отзывов — а такой простой штуки, которая есть, наверное, на любом PHP фреймворке — не сделали.
Ещё документация к Laravel, например, — намного более качественная, чем для рельс… У рельс и документации-то в общем-то и нет толком, есть лишь набор "инструкций", которые объясняют, как сделать то или иное дело на рельсах. Но это всё-таки немного другое, не документация.
Ещё я бы записал в минусы Ruby любовь к "размазыванию" классов на кучу файлов. Ну, это тоже частично на тему монки патчинга.
В общем, по итогам своей работы в последние пару лет, я всё также использую Laravel в своих проектах, и в общем-то более чем доволен им.
potapuff
09.06.2016 21:01Ещё среди минусов я бы лично записал то, что RoR не умеет соединяться более чем с одной базой данных.
Для этих целей есть не очень живой db-charmer (До Rails 3 включительно) и воплне живой octopus (есть поддержка Rails 4)
Tonkonozhenko
09.06.2016 21:33+1Ещё среди минусов я бы лично записал то, что RoR не умеет соединяться более чем с одной базой данных. Столько хвалёных отзывов — а такой простой штуки, которая есть, наверное, на любом PHP фреймворке — не сделали.
ActiveRecord по дефолту умеет подключаться к нескольким БД (docs).
Ещё документация к Laravel, например, — намного более качественная, чем для рельс… У рельс и документации-то в общем-то и нет толком, есть лишь набор "инструкций", которые объясняют, как сделать то или иное дело на рельсах. Но это всё-таки немного другое, не документация.
Документация тоже вполне ок, "набор инструкций" это в гайдах.
Ещё я бы записал в минусы Ruby любовь к "размазыванию" классов на кучу файлов. Ну, это тоже частично на тему монки патчинга.
Ни разу не видел чтобы в нормальном приложении класс "размазывался" на несколько файлов.saggid
09.06.2016 23:55Да, насчёт ActiveRecord я ошибся, прошу прощения.
По документации уже написал чуть ниже.
Насчёт последнего — в общем-то, всё дело в монки патчах, которые накладываются друг на друга разными библиотеками, что, в целом, вообще неправильно. Эта тема подробно была описана одним из руби-разработчиков, перевод статьи есть на хабре. Хотя, из комментов к этой же статье, я так понял, что для руби уже реализовали механизм Refinements. В этом свете, хотелось бы узнать, насколько активно его стали применять на практике в разработе рельсов и других библиотек, и действительно ли этот механизм полностью решает проблему конфликтов при монки патчах.
Source
10.06.2016 16:43Ни разу не видел чтобы в нормальном приложении класс "размазывался" на несколько файлов.
A Вы код самого Rails смотрели? Тот же ActiveRecord::Base — просто гигантский класс, размазанный на десятки файлов внутри самого фреймворка и ещё сотни файлов из сторонних гемов расширяют его же.Tonkonozhenko
10.06.2016 16:46Я изначально подумал про N файлов вида:
class A ... end
ActiveRecord::Base — просто гигантский класс, размазанный на десятки файлов
Да, но он состоит из более-менее логичных модулей.
сотни файлов из сторонних гемов расширяют его же.
это другой вопрос.
Но для обоих этих случаев есть документация, в самом приложении такого быть не должно.Source
10.06.2016 20:44Что Вы имеете в виду?
В самом приложении не должно быть Rails или гемов, расширяющих существующие классы?
Или если Вы выносите такие случаи в гемы — то это ok, а вот если в коде самого приложения — то это фу? Это ж двоемыслие какое-то...Tonkonozhenko
12.06.2016 11:14Расширять существующие классы вообще не ок. Ни в своем прилжении, ни в гемах. Но, к сожалению, это есть.
По поводу того, что сам класс разбит на много файлов — он разбит с помощью модулей. Я изначально подумал что в 10 файлах переоткрыт класс и дописаны методы. Да, модули в принципе то же самое, но они хотя бы могут иметь логику разбиения.
sl_bug
10.06.2016 22:59+1А знаете зачем так сделано конкретно в ActiveRecord::Base?
А чтобы у вас была возможность подключить любой из этих десятков файлов отдельно в свой «Plain Old Object». ActiveRecord::Base всего лишь делает это за вас подключая всё.
Также никто вас так же не заставляет использовать всякий DSL который накинет вам модулей в классы (те же вызовы rolify, devise еще чего-нибудь) все можно подключать отдельно. Заинклюдте все руками. Невозможного нет ничего.
P.S. Да иногда есть гемы которые написаны криво, ну так помогите сообществу, сделайте pull request.Source
11.06.2016 16:56Так я ж не говорю, что это всегда плохо, для базовых классов при желании можно найти плюсы. Но это не только в базовых классах, это в принципе по коду всего фреймворка встречается.
А человек был в неведении, что в любом Rails-приложении есть десятки классов, размазанных на несколько файлов.
По другому можно делать, но это грести против сообщества. Поэтому 'любовь к «размазыванию» классов на кучу файлов' — это факт, имеющий место в Ruby-сообществе. Поэтому странно видеть утверждения, что приложение, в котором это встречается, априори ненормальное.
ertaquo
09.06.2016 21:31Про monkey patching ничего сказать не могу, но…
Справедливости ради, в рельсах можно работать более чем с одной базой данных. К примеру, если модель SomeModel лежит в другой БД, достаточно написать:
и добавить соответствующие записи вclass SomeModel < ActiveRecord::Base establish_connection "another_db_#{Rails.env}" ... endconfig/database.yml. Ну или можно использовать concern — что универсальнее. Примерно так же можно использовать прямые запросы к разным базам.
Документация к рельсам — вам мало guides.rubyonrails.org, api.rubyonrails.org, apidock.com? Куда уж больше-то?
С классами тоже имхо все в порядке — если не размазывать их специально, а соблюдать структуру. Каждый класс, каждый модуль выполняют определенную функцию. Или это плевок в сторону MVC в целом?
В-общем, по итогам своей работы за последние пару лет, я практически полностью перешел на Rails в своих проектах, и более чем доволен им :)saggid
09.06.2016 21:35Нет, вовсе не плевок. По большей части, я задал вопрос чтобы увидеть адекватные ответы. Спасибо за ссылки и разъяснения, посмотрю на досуге.
Fesor
10.06.2016 01:10+1Или это плевок в сторону MVC в целом?
Меня тут больше расстраивает использование этой триады в контексте рельсов. Ну то есть еще до рельсов существовал MVC, и еще до рельсов был придуман mediating controller MVC. И вот MVC в рельсах совсем не то значит.
И на волне популярности рельсов вот это "немного не то" насктолько распространилось, что сейчас проще просто отказаться от использования этой аббривиатуры целиком и полностью ибо она потеряла свой смысл…
Сейчас львиная доля бэкэнд разработчиков считают что MVC это когда логика манипуляции сущностями в контроллерах. Это примерно тот же уровень урона для начинающих как UML концентрирующий внимание разработчиков на классы а не на взаимодействие объектов.mpetrunin
11.06.2016 11:57Опишите, пожалуйста, правильное с вашей точки зрения понимание MVC, и, если можно, ключевые различия с рельсовским пониманием MVC.
Fesor
11.06.2016 13:57+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.
RightWay
10.06.2016 16:09Да решений таких много. Можно создать класс OtherActiveRecord < ActiveRecord::Base, там указать другую базу для коннекта и потом наследоваться от него. Тогда получим возможность создавать модели с автоматическим подключением к другой базе. Это топорный метод, есть и более интересные, но иногда это сделать проще.
printercu
11.06.2016 22:02Пропаганды не видел, скорее про это пишут в смысле "даже так вот можно". Сам же манки патчинг довольно удобен, особенно сейчас, когда очень много OSS. Часто либа может иметь баг или просто не иметь поддержки нужного функционала, которая решается добавлением пары строчек. Часто такие штуки фичи не нужны всем, только в одном приложении. В этой ситуации есть несколько решений:
- сделать PR, и ждать когда примут и зарелизят,
- форкнуть либу, и потом периодически рибэйзить на апстрим,
- сделать манки патч, и пользоваться оригиналом.
Конечно, в зависимости от количества изменений 1й и 2й варианты могут быть предпочтительны. Но по мне 3й варинат лучше, если правок действительно немного. И манки патчинг в руби удобен (в жс вон что люди придумывают: https://github.com/jhnns/rewire).
Ну и плюс во время разработки. Можно проверить локально, переопределив сначала методы, проверить. А затем вернуться к 1му/2му варианту.
saggid
12.06.2016 21:53+2Вы всё-таки не правы, честно. К сожалению, как я вижу, на деле манки патчи используют повсеместно в Ruby-сообществе, и это именно считается нормальной практикой, которая в том числе и пропагандируется.
Почитайте хотя-бы этот комментарий ниже, почитайте эту статью о монки патчах, ссылку на которую я уже давал здесь же. В ней достаточно хорошо рассказано о том, как обстоят дела с этой техникой.
По сути, меня подобное довольно странное отношение к коду и остановило от перехода с всеми унижаемого PHP на Ruby в своё время. Вы меня извините, но в PHP вообще такое невозможно, чтобы два разных модуля вдруг каким-то образом вызвали конфликт друг у друга. Мне просто приятнее и спокойнее использовать тот инструмент, поведение которого я могу контролировать в большей степени.
И ваш пример со ссылкой на JS-библиотеку для изменения кода для тестов тоже не очень-то годится в качестве довода. Одно дело в тестах создавать заглушки — и совсем другое дело писать основной код приложения подобным образом.
thousandsofthem
09.06.2016 20:21+3Будущее ruby, по личным ощущениям:
* Ruby/Rails никуда не уходят, до сих пор адекватный инструмент решения многих задач. Конкурентов особо нет. Впрочем, пик развития недавно прошел.
Цитата из статьи:
> Ruby перестает быть модным, но продолжает быть эффективным инструментом для построения стартапов
* Go никаким боком не конкурент хотя часто используется совместно — для нагруженных участков
* Многие опытные разработчики сейчас переходят с рельс на Elixir/Phoenix (сюрприз, написанные людьми из команды рельс — с исправлением накопленных за годы развития косяков).
pilipenok
09.06.2016 20:21+1RoR умеет соединяться более чем с одной базой, причем из коробки и довольно удобно: либо указал в модели, куда лезть за данными, либо явно в запросах.
Например, www.safaribooksonline.com/library/view/advanced-rails/9780596510329/ch04s04.html
Документация отличная, с учетом версий, например: apidock.com/rails/ActiveRecord/Basesaggid
09.06.2016 23:46Спасибо за первую ссылку. Да, мои знания устарели, прошу прощения, тут видимо я явно ошибся.
Но насчёт второго. Ну, неплохо, да. Но всё-таки, посмотрите как удобно сделали документацию к Laravel. Я ожидал увидеть для рельсов что-то подобное, но когда изучал их, то из официальных данных нашёл только гайды (про них я уже писал — это не совсем документация, эти гайды объясняют основы, но не объясняют тонкости).
ufadiz
10.06.2016 16:09Ну 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, таки одними рельсами руби комьюнити не заканчивается.
mpetrunin
11.06.2016 12:02Ещё есть совершенно прекрасные документации на 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 тоже родился в недрах рубишного сообщества.
faost
10.06.2016 00:03Рельсы нравятся всем, но для меня сильно портит картину отсутствие такой же удобной IDE как для фреймворков из мира java/php/python. Из-за метапрограммирования тот же работающий в 100% случаев автокомплит сделать просто нереально. В основном по работе имею дело с Symfony и в документацию/stackoverflow лезу раз в неделю максимум: go to definition + автокомплит работают почти идеально (я говорю про PhpStorm + плагин Symfony), в запутанных случаях выручит xdebug. Я всегда смогу найти, почему этот код работает именно так.
При работе с рельсами go to definition и автокомплит уже далеки от совершенства и читать доки и SO приходится в разы чаще. Помогает, но частично:
* Использование аннотаций
* Дебаг
* Rails console
Подскажите, как кто решает проблему поддержки Rails в IDE?
eugzol
10.06.2016 00:20+1Пользуюсь текстовыми редакторами, а не IDE. Автокомплит не требуется. Go to definition, если я правильно понял назначение, — приходится лезть в гугл и искать документацию, в которой как правило можно нажать [show source] для рассматриваемого метода. После осваивания текстового редактора у меня непереносимость IDE.
Вон, разработчики RubyMotion (http://www.rubymotion.com/) выставляют как ДОСТОИНСТВО возможность не использовать IDE! Пользуясь привычными текстовыми редакторами. Ну, может тут дело и в конкретном софте, конечно, может просто XCode особенно изрядное г… среди всех IDE, хотя я что-то сомневаюсь — думаю, вполне себе середнячок.
Fedcomp
10.06.2016 11:11+2Не понимаю за что минусуют. Юзаю Atom + подобие TDD + binding.pry
Хочешь узнать где находишься? в дебаггере show-method, хочешь узнать что хранится в сущности? ls ApplicationController и так далее. Это просто другой подход, скорее всего непривычный для тех кто сидел на IDE и особенно на языках со строгой типизацией. Магия дебажится, вот хорошая статья на эту тему: http://www.schneems.com/2016/01/25/ruby-debugging-magic-cheat-sheet.html
Зато многие неявные вещи зачастую страхуют от косяков. Для обратных случаев есть тесты на все вокруг. Как можно писать проект без нормального тестового покрытия мне например уже не понятно.
Fesor
10.06.2016 11:16Справедливости ради разработчики той же Symfony фигачат все в textmate и довольны. На самом деле и без автокомлита можно с этим фреймворком работать эффективно (то есть нет дурацких AbstractFactoryFactory), просто с ним удобнее.
eugzol
10.06.2016 16:42Да я вообще ни одной презентации от core member фреймворка или языка из своего круга интереса не вспомню, где бы использовалась IDE. Минимум в половине случаев вообще Vim и Emacs.
Houston
10.06.2016 00:57+4RubyMine не пробовали? https://www.jetbrains.com/ruby/
estum
10.06.2016 06:00Заставляю себя пробовать каждую новую версию RubyMine, пока ни в одной из них я не смог работать дольше чем 15 минут. В последний раз причина была в том, что какая-то стандартная для OSX комбинация клавиш, которой я часто пользуюсь, в RubyMine имела совсем неожиданное поведение. А еще — почему-то для комментариев в коде используется уродский oblique вместо italic, хотя это мелочь, конечно, но глаз режет (псст, разработчики RubyMine, WHY?!). Еще много чего не понравилось, но я уже забыл.
Поэтому я до сих пор приверженец старого доброго TextMate 2 (для ruby у меня набралось много сниппетов и команд) в связке с постоянно запущенным pry в консоли и не парюсь по этому поводу.Nepherhotep
10.06.2016 11:33Я не пробовал конкретно RubyMine, но активно использую другие продукты от JetBrains — PyCharm и Idea IDE. Эти студии разработки можно очень хитро конфигурировать, вплоть до смены горячих клавиш на vim и emacs.
Кстати на счет последнего, подозреваю, что для Руби там тоже все ок.
xo8bit
10.06.2016 12:50Я одно время писал и на RubyMine и на Atom, остановился на emacs. Конфигурируй не хочу. А вообще особого смысла в IDE не вижу
Tonkonozhenko
10.06.2016 12:57В vim, emacs или где-то еще можно перейти к определению метода в геме? Я пока видел только в рубимайне. Когда-то думали перейти в что-то другое, но без этой фичи это не вариант.
xo8bit
10.06.2016 13:02Я пробовал настраивать go to definition еще в Атоме, но толком ничего не получилось. В emacs даже не пробовал. Но вообще это конечно удобно
grossws
10.06.2016 19:39В случае других языков можно с ycmd (для rust, js, ts, python, c, c++), но ruby в нём пока не поддерживается. Для ruby может заработать eclim.
Tonkonozhenko
12.06.2016 11:18Это автодополнение. Я имею ввиду что когда есть написанный код, можно клацнуть по методу и перейти к его объявлению. Да, это не всегда показывает правильный метод или показывает 10 вариантов, но это невероятно удобно.
grossws
12.06.2016 19:56Не беспокойтесь, я знаю что такое 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.
Nepherhotep
10.06.2016 13:30Я несколько лет работал в емаксе, а потом у меня начался туннельный синдром. После этого я переехал на PyCharm и стал больше кликать мышкой, стало заметно легче, хотя и скорость работы снизилась :)
tmn4jq
10.06.2016 12:03+1Ну вообще RubyMine предоставляет несколько предуставноленных keymaps, в том числе и TextMate-подобную. По поводу шрифтов – мне никогда не мозолило глаза, дело вкуса, наверное. Да и в целом, RubyMine предоставляет множество настроек. Если вас не устраивают дефолтные (меня они сразу устроили, особенно радует тема Darkula), то можно потратить какое-то время на кастомизацию среды под себя.
estum
10.06.2016 12:28В настройках стилей как я помню стоял именно italic, шрифт InputMono, но отображался он как перегнутый oblique, хотя в TM с тем же шрифтом италик отображался как надо.
И, да, я пробовал TextMate-подобную, там что-то не все работало как хотелось, возможно это были кеймапы 1-ой версии. Я было начал исправлять под себя, но потом понял, что у меня нету столько времени с ним ковыряться.
develop7
10.06.2016 13:34+1какая-то стандартная для OSX комбинация клавиш, которой я часто пользуюсь, в RubyMine имела совсем неожиданное поведение
workaround — поправить в настройках, proper fix — file a bug
почему-то для комментариев в коде используется уродский oblique вместо italic
см. выше
faost
10.06.2016 14:47+1Про RubyMine и говорил, в других Ruby-IDE все в этом плане совсем плохо. Но по сравнению с работой с PHP/Java все как-то печально:
Автокомплит не работает уже в таком простом случае
mpetrunin
11.06.2016 12:25Я использую VIM вместо IDE. Автодополнение там не супер, но кое-как работает. Go to definition работает отлично. Но VIM настолько хорош во всём остальном, исключая автодополнение для Ruby, что я ему эту слабость прощаю.
printercu
11.06.2016 22:07Гем pry (debbie — тот же при, только с набором расширений), может очень помочь. Я без show-method, show-doc теперь как без рук.
divanikus
10.06.2016 01:05+1Я вот использую ruby в качестве языка общего назначения для автоматизации всяких вещей aka shell scripting. В его пользу говорит удобство, выразительность, скорость разработки. Например, сделать какую-нибудь cli тулзу дело одного вечера с помощью rake и thor. Магия и сахар в принципе не раздражают, после перла даже нравятся — в перле магии больше, но и запутаться легче.
От Python, извините, воротит. Мне он кажется неудобным и даже в какой-то мере некрасивым.
Что не очень нравится в Ruby, похоже он все-таки относительно медленный. Делал конвертер больших json файлов в csv, написался он быстро, а вот выполнялся чуть ли не часы. После опыта написания подобных вещей на перле такого не ожидаешь.
estum
10.06.2016 05:32+1Что я понял за последнее время, так это то, что проблему прожорливости памяти в ruby-приложениях создали сами разработчики гемов, по умолчанию расширяя суперклассы при загрузке библиотеки. Как-будто я не в состоянии самостоятельно включить нужный мне модуль в класс, где реально нужен функционал этого модуля! В итоге, приложение содержит кучу неиспользуемых методов, объектов, мета-конскрукций, макросов и хуков. ActiveRecord и ActiveModel — одни из таких гемов, на мой взгляд благодаря довольно п****стическому принятию коммитов, лишь бы тесты проходили.
Просто отказаться от гемов сложно, удобство ruby во многом в том, что почти всегда можно найти гем, решающий тот или иной кейс, но многие из них имеют эту дурную привычку — без спроса расширить что-нибудь глобальное.
Я считаю, что эту проблему мог бы решить некий манифест, пропагандирующий разработчикам гемов использовать меньше магии на момент загрузки зависимостей, а их пользователям — не лениться вручную включать нужные модули в свои классы.
А так, хоть я и наблюдаю у ruby кучу недостатков, некоторые из которых реально раздражают, но все равно пытаю к этому языку нежные чувства. Сам использую его не только в web-приложениях, но и в различных консольных утилит как для автоматизации рабочих моментов, так и просто для фана (как-то раз ну очень захотелось консольный генератор гитарных аккордов — накодил его за полдня).
Но без фанатизма: если что-то вырастает из ruby или изначально не подходит для разработки на нем, тогда уже используются другие языки. Например, я бы не стал писать на ruby WebSocket-сервис, обрабатывающий множество долгих запросов (в теории можно JRuby). Поэтому не понимаю нахеракозе баянв Rails 5 включили ActionCable, он же на продакшене будет работать как надо в очень ограниченных случаях. Пользуясь случаем кинусь какашкой в DHH, он хоть и внес в свое время хороший вклад, но мне его влияние на язык и сообщество кажется скорее негативным.
svyatogor
10.06.2016 10:37+5Моя главная претензия к экосистеме ruby и RoR в сложившейся традиции mokey patching и неявного внедрения в чужие классы. Вот только на днях потратил кучу времени чтобы понять, что гемы rollify (для ролей) и geocode не дружат т.к. оба пытаются заинжектить в базовый класс метод adapter. Да, *иногда* иметь такую возможность круто, но когда это становится нормой то начинает мне напоминать спагети php код эпохи до фреймворков. Это не значит, что я в ближайшее время откажусь от RoR, он позволяет мне решать поставленные задачи быстро и конечный результат всех устраивает, да и спрос на рынке труда падать не собирается. Но проблема есть, и вылечить ее просто так не получится.
jakshi
10.06.2016 10:50+1Любопытный язык написанный под влиянием Ruby: crystal-lang.org
Еще молодой.
Слежу за ним с интересом.
Если будет развиваться/расти — можно будет программировать с привычным синтаксисом Ruby и использовать быстрый компилируемый язык программирования.
uniqm
10.06.2016 11:08+1Все следят с интересом ^^
С виду развивается в нужном направлении. Все менее смахивает на Ruby, но не вызывает отторжение.
При грамотном пиаре ждет светлое будущее.
Поигравшись с Kemal-ом (по образу синатры), несложный API или простенькие сайтики уже можно городить. При запуске не ест ни память, ни процессор. Деплой тоже «несколько проще» рельсового.
К предыдущему посту про ActionCable в пятых рельсах — те же мысли возникли. Веб-сокеты на Kemal-е выглядят аккуратнее.
Sega100500
10.06.2016 13:05+1Занимаюсь программированием более 20 лет. Изучил Ruby 5 лет назад, использую Ruby on Rails 4 года — пишу сайты различной сложности — от простых сайтов-визиток (за 1-2 дня) до интернет-порталов (без команды, самостоятельно). Только позитивные и положительные эмоции от программирования на Ruby. За всю свою карьеру, изучив и использовав множество языков программирования, могу с уверенностью сказать: Ruby — наиболее изящный, удобный и внятный из языков программирования (конечно из тех, которые я знаю).
Не испытываю никаких проблем с сопровождением проектов на Ruby on Rails. Все достаточно логично и удобно.
Проекты предпочитаю писать «с нуля» и по возможности самостоятельно реализовывать механизмы, по минимуму используя сторонние библиотеки — мне интересно программировать, и доставляет удовольствие разработка (кстати, именно программирование на Ruby с удовольствием). При этом все получается легко, быстро и качественно.
Тем, кто прочит закат и «смерть» Ruby, могу посоветовать только одно — не нравится вам (а, скорее, не получается) — ну и не обращайте внимания — для вас Ruby даже и не появлялся на свет. И не надо пинять на зеркало, коли… ну отойди ты от зеркала — не мучай изображение! )))
raidhon
10.06.2016 14:05Если учесть что сейчас я снова пишу проект на Rails теперь уже 5, мой комментарий тогда был слишком категоричен!
Бессонная ночь, проведенная за поиском заковыристого бага сделала свое дело.
Так что я вас поддержу.
У Rails много минусов, но плюсов гораздо больше. Он был и остается самым удобным фреймворком с классическим MVC.
Иногда конечно он подкидывает граблей, но выбрасывать такой инструмент было бы преступлением!
По поводу самого Ruby.
Он живет в своем тихом омуте, но так можно и выпасть из реальности.
Нужно ускоряться!
Например как PHP, который с переходом на 7 версию дает прирост производительности под 100%, а то и больше.
Так что не всегда проблема в бутылочном горлышке или базе данных.
Надеюсь Ruby пойдет в правильном направление и увеличит производительность с тем же удобством разработки.
А пока бенчмарки удручают benchmarksgame.alioth.debian.org/u64q/compare.php?lang=php&lang2=yarvbromzh
10.06.2016 15:38+2Ну вот, уже MVC из Rails называют классическим.
raidhon
11.06.2016 00:37Давайте так чтобы долго не спорить:
Классической реализацией концепции MVC принято считать версию именно с активной моделью.
В объектно-ориентированном программировании используется активная модель MVC, где модель — это не только совокупность кода доступа к данным и СУБД, но и вся бизнес-логика; также, модели могут инкапсулировать в себе другие модели.
Выкладка из Wiki Rails:
Модель предоставляет остальным компонентам приложения объектно-ориентированное отображение данных (таких как каталог продуктов или список заказов). Объекты модели могут осуществлять загрузку и сохранение данных в реляционной базе данных, а также реализуют бизнес-логику.
И даже класс для работы с моделями называется Active Model.
Тогда назревает вопрос, если в Rails не классическое MVC то какое по вашему?Source
11.06.2016 17:03Чуть выше уже написали про классическое MVC: https://habrahabr.ru/post/303024/#comment_9652556
Fesor
11.06.2016 19:03И в целом с точки зрения модели все хорошо:
- СУБД — деталь реализации модели и мы о них можем вообще не говорить.
- модели могут инкапсулировать в себе другие модели (то есть в качестве модели может выступать любой объект, который в своб очередь работает с другими моделями).
- модели активны. То есть управление состоянием это задача модели, а контроллеры могут только просить что-то сделать. Точно так же представление может подписываться на события и обновлять само себя но вот тут я не уверен...
Насколько я помню в rails таки использует пассивные вьюшки, что превращает "классический MVC" в mediating-controller MVC. Что уже как бы не "классическое". Но это даже хорошо. Хотя если я тут не прав — буду рад если меня кто-нибудь подправит.
raidhon
11.06.2016 21:17Никто вам не запрещает сделать так <%= User.first.name %>
И вызвать модель прямо из View.
И mediating-controller это уже скорее MVA ( Model–view–adapter ) где модель полностью обособлена и общается с View только через адаптер( контроллер ).Source
11.06.2016 22:43Насколько я понимаю, в классической реализации View был больше похож на то, как это сделано в AngularJS. А возможность вызывать модель из View — это совсем о другом, и скорее это как раз нежелательная возможность.
raidhon
11.06.2016 23:01Понятно что это плохой тон, как вообще идея писать логику во View!
Это было написано лишь для примера показать что с mediating-controller тут нет сходства.
Ничего не понял в вашей фразе «в классической реализации View был больше похож на то, как это сделано в AngularJS ».
View в большинстве реализаций MVC ( включая классическую ) отвечает за простое отображение данных.
Ничего нового тут не придумали.Fesor
12.06.2016 01:56
Fesor
12.06.2016 01:54В Angular вьюшки пассивны, это декларативные шаблоны + биндинги + viewmodel компонента.
Fesor
12.06.2016 01:53Никто вам не запрещает сделать так <%= User.first.name %>
Никто не запрещает но это не ок. Это как лесть в шаблонах в базу данных. Отсутствие разделения ответственности.
где модель полностью обособлена и общается с View только через адаптер( контроллер ).
так так оно по сути чаще всего и происходит. Адаптер забирает данные и заполняет данными пассивное view. Можно сделать view активной но это не приветствуется насколько я понимаю.raidhon
12.06.2016 13:50+1View изначально пассивно оно предназначено только для отображения данных.
Это везде описано в том числе и в MVC с пассивной моделью.
Как я уже говорил пример был написан, чтобы показать отличие от MVA.
Тут не может быть MVA потому что View имеет ссылку на Model.
И может принимать сообщения от модели.
По сути вообще куча программистов пишет логику в контроллерах в Rails, а модели использует только как средство получения данных из СУБД.
Тут логика проста если вы едите на мерседесе со скоростью 30 км/час это не означает что он не может по другому и не превращает его от этого в запорожец.
На момент создание фреймворка не было технологии позволяющей оповещать реалтайм со стороны бекенда фронтенд и активно перерисовывать View.
Сейчас эта технология есть — WebSocket.
Например это реализовано во фреймворке Sails.js ( Node.js ), который при создании ориентировался на Rails.
Даже название созвучно))
Где модель при изменении или создании создает события, так называемые Resourceful PubSub, на которые можно подписываться со стороны фронтенд и активно перерисовывать View.
На данный момент WebSocket присутствует и в Rails в пятой версии, но технологию оповещения придется писать ручками.
Так что мы пришли практически к десктопной версии MVC.
В MVC Rails исполнено главное для активной модели.
Модель — это не только совокупность кода доступа к данным и СУБД, но и вся бизнес-логика; также, модели могут инкапсулировать в себе другие модели.
Это и позволяет мне назвать данное MVC классическим.
Fesor
12.06.2016 16:13Итого, давайте обобщим. "классическое MVC" для меня в случае RoR будет:
- активная вьюшка, то есть какой-то объект который выделяется на соединение по WebSocket и предоставляет какое-то представление данных клиенту.
- Контроллер ничего не знает о view. То есть он максимум может подписаться на события из объекта вьюшки и обрабатывать асинхронные действия пользователей конвертируя их в синхронные сообщения моделям.
- Модель активна и предоставляет события для view
Вот в таком ключе соглашусь что можно использовать smalltalk MVC 1979-ого года выпуска. Но мы в таком случае сильно усложняем все так как взаимодействие между клиентом и сервером становится нифига не stateless.
Тут не может быть MVA потому что View имеет ссылку на Model.
View именно имеет ссылку на Model или ее дает контроллер? В классическом MVC да, модель является зависимостью View (причем обязательной зависимостью) и ничего не знает о контролере. А если мы передаем во view модель (как это сделано в большинстве фреймворков которые называют себя MVC) то там вместо модели может быть любой другой объект предоставляющий состояние. И тогда как бы… все взаимодействие так или иначе проходит через адаптер (контроллер).raidhon
12.06.2016 19:08Я так понимаю вы вообще Rails в глаза не видели если задаете такие вопросы?
Модель можно вызвать без участия контроллера, ничего никуда не нужно передавать, просто вызываете прямо во View.
Вызвав модель во View вы уже подписались на цикл событий модели WebSocket тут не обязателен.
Достаточно обновить страницу.
Модель независима как от контроллера так и от View.
Да подобное поведение не рекомендуется но возможность реализации присутствует.
Судить об оригинальной smalltalk MVC 1979 можно лишь относительно, как и притянуть её реалии к современному веб приложению.
И на этом закончим наше обсуждения, до момента как вы испробуете Rails в реальном разработке.Fesor
12.06.2016 19:58Я так понимаю вы вообще 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 использовать я не хочу, во всяком случае сейчас.raidhon
12.06.2016 20:38+1Иногда поражаешься с людей не использовали инструмент в работе, и судят что там и как.
И после этого ты получаешь минус скорее всего от самого судьи комментатора.
Это тоже самое что я зайду на тему с Laravel не зная Laravel ( хотя я знаю и PHP и Laravel ) и начну рассказывать людям что там и как.
С каждым разом убеждаюсь в топку комментирование, читай статьи молча или на тебя найдется всезнающий троль!Fesor
12.06.2016 20:48+1И после этого ты получаешь минус скорее всего от самого судьи комментатора.
Я вас не минусовал если вы переживаете. И причин минусовать тоже не вижу.
Иногда поражаешься с людей не использовали инструмент в работе, и судят что там и как.
Я достаточно работал с RoR что бы понимать как там что. И я не говорил о том что там что-то плохо, для своих задач там все весьма грамотно. Я просто придрался к словам "классический MVC".
p.s. Laravel я тоже не использую в коммерческой разработке.
bromzh
14.06.2016 04:19На момент создание фреймворка не было технологии позволяющей оповещать реалтайм со стороны бекенда фронтенд и активно перерисовывать View.
Long Polling уже давно был. Задолго до вебсокетов.
Ну и опять же, был, например, JSF, и в нём можно было сделать MVC очень похожий на классический.
Рельсы просто перепутали понятия, а народ подхватил.
bromzh
14.06.2016 04:14+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 куда более приближенное к классическому.
guai
10.06.2016 14:28+5Смерть языка можно констатировать с появлением статей про то, что он не мёртв :)
Source
10.06.2016 20:57Ruby перестает быть модным
По-моему наоборот, Ruby сейчас на пике моды… Появляются курсы типа «Врубиться в Ruby. Научим кодить с нуля». Люди далёкие от программирования начинают интересоваться как освоить Rails. В общем, настолько моден, что невольно вспоминается байка про банкира и чистильщика обуви.
ArXen42
Извиняюсь за минус, мискликнул в Vimium.