Ну, за 25 лет Вы явно успели попрограммировать не только на Ruby, не так ли? Т.е. причины со временем менять базис существуют в том числе и лично для Вас.
У любой технологии есть свой цикл развития:
Rails сейчас очевидно находится на этапе «Late Majority». И вполне объяснимо, что Пётр, как один из лидеров Ruby-сообщества, чувствует социальную ответственность и соответственно потребность описать свою точку зрения.
Хороший ответ. Akita справедливо отмечает, что у Rails есть своя сфера применения (Basecamp-like apps) и большинство веб-проектов в эту сферу попадают. Также как есть Wordpress для блогов.
И если вы пытаетесь сделать какой-то проект на инструменте, который для этого проекта не предназначен, например, магазин на Wordpress или веб-приложение, архитектурно не похожее на Basecamp, на Rails, то вы будете страдать. Однако, он забывает, что когда Rails только набирал обороты, многие говорили «Зачем нужен фреймворк, для большинства проектов достаточно CMS», «Зачем нужны Ruby и Python, большинство крупных проектов написаны на PHP». Так что текущая ситуация — просто очередной виток истории.
Также он отмечает, что слишком сильная дефрагментация сообщества, как у PHP и JS, — это ещё хуже, чем монополия. С этим я тоже согласен.
Я чуть выше описал зачем это было нужно. Именно как построитель запросов он и использовался, т.е. по самому прямому назначению.
не стоило тогда даже и рассматривать current_date как функцию?
Как не рассматривай, а как-то надо было её запихнуть в результирующий SQL и обойдясь при этом без raw SQL. Реальнее оказалось запихнуть как функцию )))
Ахах, ну видимо придётся контекст задачи описывать…
Нужно было предоставить пользователю возможность создавать сегменты по определённым моделям. Т.е. пользователь накидывает критерии в интерфейсе, а мы по этим критериям с помощью Arel генерируем SQL-запрос. Естественно давать пользователю вводить raw SQL в планы не входило. Переписывать без Arel было бы долго, потому что для заказчика это выглядило просто «а давайте добавим ещё 1 тип критериев в форму». При этом требования к скорости результирующего запроса были очень высокими, т.е. обернуть current_date в SQL-функцию тоже не прокатывало.
Начали и начали. От ещё одного проекта на Rails никому хуже не станет )))
А на будущее посмотрите ещё и в сторону Elixir+Phoenix. Конфет много не бывает xD
Я так понял, главная проблема автора не столько в самом Rails, сколько в сообществе.
Автор хочет привлечь внимание сообщества к тому, что есть жизнь за пределами Rails. Как на Ruby, так и на других языках. В частности он является автором более чем десятка полезных гемов для Ruby.
Очень бы хотелось обсудить предыдущую статью автора, в которой он осуждает monkey patching: если не ActiveSupport, то как?
Нет ничего плохого в отдельных модулях для подобных методов, не обязательно их добавлять к базовым классам. По началу это даёт определённый вау-эффект, но не даёт реальных преимуществ, а вот весёлый дебаг временами обеспечивает.
Хаха, а я застал «краешком»… серьёзные проекты на WebForms я не делал, но там реально была жесть, он генерировал совершенно дикий HTML, а AJAX работал через UpdatePanel, т.е. тупо обновлял практически всю страницу… Так что да, ASP.NET MVC в сравнении с WebForms был крут уже с первой версии.
Про это ещё Фаулер писал в EAA Patterns писал… Если вкратце, то AR — это одновременно и паттерн и антипаттерн, так как совершенно внаглую нарушает SRP.
Вариант хорош. Но никто и не говорит, что невозможно использовать обычные Ruby-классы совместно с Rails. Автор статьи прекрасно об этом осведомлён, просто устал бороться с тем, что генеральная линия Rails Core Team идёт совсем в другом направлении.
Ох, не напоминайте мне про Arel. Надо было мне как-то раз его подружить с PG-функциями без скобок, типа current_date.
Для тех, кто не знает, у Arel есть возможность вызывать SQL-функции, но только со скобками
Account.where{created_at == :now.func()} # работает
Account.where{created_at == :current_date.func()} # не работает
В общем, пока я воркэраунд писал, достаточно ознакомился с его исходниками. Мягко говоря, там реальный треш. Если не согласны, попробуйте решить вышеописанную задачу. У меня на тот момент была версия arel-4.0.2.
Эти плюшки хороши, когда Вам надо сделать блог за 10 минут. Но чем сложнее становится проект, тем больше сложности они в него добавляют.
Очень рекомендую всем, кто имеет дело с Rails, книгу «Rails Anti-Patterns». В ней описаны многие анти-паттерны, на которые в какой-то мере провоцирует сам Rails.
В качестве хобби и работы на ближайшее время Rails вполне подойдёт. Если говорить о России, то в ближайшие 3-4 года Вы скорее найдёте работу именно c Rails, а не с «летающими машинами», как Вы выразились.
Однако, основная мысль статьи в том, что не стоит идеализировать Rails. Он симпатично выглядит снаружи, но внутри никогда особо не блистал понятностью или удобством. К тому же фреймворк оброс кучей функционала, часть из которого весьма спорна, и стал медленно развиваться в плане действительно важных вещей… В чём-то он уже пытается догнать конкурентов, к примеру, наконец-то добавляя поддержку веб-сокетов.
На тему самого Ruby тоже спохватились и пытаются угнаться за языками, на которые идёт массовый переход: Ruby 3x3, Concurrent Ruby
Проблема не в гемах, а в том, что гемы должны быть написаны с прицелом на Rails. Т.е. по-большому счёту гемы зависят от Rails. Именно это и не нравится автору. Он, как и многие другие программисты, хочет чтобы гемы были независимыми и простыми библиотеками.
Одна дефолтная changeset-функция сгенерируется генератором модели. А остальные по мере необходимости.
В Rails долгим и мучительным путём пришли к тому, что вызывающий код должен преобразовать параметры самостоятельно:
def user_params(params)
params.require(:user).permit(@allowed_fields)
end
Но куда подобные методы помещать не придумали и пихают пока прямо в контролеры, что в нетривиальных случаях приводит к реализациям user_params, разбросанным по разным файлам.
А вот для создания разных правил валидации одной модели в Rails пока из коробки ничего нет.
Я, как человек недавно познавший быстрое прототипирование Rails, в когнитивном диссонансе. Только недавно пришел к мысли о том, что вот оно — будущее (в сравнении с PHP).
Не волнуйтесь. У автора статьи в 2007 году были такие же мысли о Rails, что и у Вас. Да и у меня было такое же ощущение в 2008-м.
Просто у Rails есть свои границы применимости, за которыми вся его магия оборачивается против программиста. С накоплением опыта участвуешь во всё более сложных проектах и всё чаще натыкаешься на эти границы. Поэтому со временем эта борьба с фреймворком утомляет и хочется иметь инструмент простой и предсказуемый.
Но Rails в ближайшие годы никуда не денется. И на простых проектах Вы вполне можете оставаться в рамках Rails Way и не испытывать никаких неудобств. А для сложных — посмотрите сразу в сторону trailblazer.
Да, Asp.Net MVC 1 — это по сути порт Rails 2.x под .NET
Насколько далеко они разошлись сейчас я не в курсе, но в 2008-2010 годах был настоящий бум — фреймворк аля Rails писали на всех популярных языках :-)
Такой подход не плох и безусловно имеет право на существование. Только фишка в том, что Rails разнообразно сопротивляется такому использованию (как запчасть). Поэтому это требует хорошей дисциплины от всей команды разработки и дополнительных усилий. Впрочем, на этом пути помогают такие проекты, как trailblazer.
У любой технологии есть свой цикл развития:
Rails сейчас очевидно находится на этапе «Late Majority». И вполне объяснимо, что Пётр, как один из лидеров Ruby-сообщества, чувствует социальную ответственность и соответственно потребность описать свою точку зрения.
И если вы пытаетесь сделать какой-то проект на инструменте, который для этого проекта не предназначен, например, магазин на Wordpress или веб-приложение, архитектурно не похожее на Basecamp, на Rails, то вы будете страдать. Однако, он забывает, что когда Rails только набирал обороты, многие говорили «Зачем нужен фреймворк, для большинства проектов достаточно CMS», «Зачем нужны Ruby и Python, большинство крупных проектов написаны на PHP». Так что текущая ситуация — просто очередной виток истории.
Также он отмечает, что слишком сильная дефрагментация сообщества, как у PHP и JS, — это ещё хуже, чем монополия. С этим я тоже согласен.
Как не рассматривай, а как-то надо было её запихнуть в результирующий SQL и обойдясь при этом без raw SQL. Реальнее оказалось запихнуть как функцию )))
Нужно было предоставить пользователю возможность создавать сегменты по определённым моделям. Т.е. пользователь накидывает критерии в интерфейсе, а мы по этим критериям с помощью Arel генерируем SQL-запрос. Естественно давать пользователю вводить raw SQL в планы не входило. Переписывать без Arel было бы долго, потому что для заказчика это выглядило просто «а давайте добавим ещё 1 тип критериев в форму». При этом требования к скорости результирующего запроса были очень высокими, т.е. обернуть current_date в SQL-функцию тоже не прокатывало.
А на будущее посмотрите ещё и в сторону Elixir+Phoenix. Конфет много не бывает xD
Автор хочет привлечь внимание сообщества к тому, что есть жизнь за пределами Rails. Как на Ruby, так и на других языках. В частности он является автором более чем десятка полезных гемов для Ruby.
Для тех, кто не знает, у Arel есть возможность вызывать SQL-функции, но только со скобками
В общем, пока я воркэраунд писал, достаточно ознакомился с его исходниками. Мягко говоря, там реальный треш. Если не согласны, попробуйте решить вышеописанную задачу. У меня на тот момент была версия arel-4.0.2.
Очень рекомендую всем, кто имеет дело с Rails, книгу «Rails Anti-Patterns». В ней описаны многие анти-паттерны, на которые в какой-то мере провоцирует сам Rails.
Однако, основная мысль статьи в том, что не стоит идеализировать Rails. Он симпатично выглядит снаружи, но внутри никогда особо не блистал понятностью или удобством. К тому же фреймворк оброс кучей функционала, часть из которого весьма спорна, и стал медленно развиваться в плане действительно важных вещей… В чём-то он уже пытается догнать конкурентов, к примеру, наконец-то добавляя поддержку веб-сокетов.
На тему самого Ruby тоже спохватились и пытаются угнаться за языками, на которые идёт массовый переход: Ruby 3x3, Concurrent Ruby
В Rails долгим и мучительным путём пришли к тому, что вызывающий код должен преобразовать параметры самостоятельно:
Но куда подобные методы помещать не придумали и пихают пока прямо в контролеры, что в нетривиальных случаях приводит к реализациям user_params, разбросанным по разным файлам.
А вот для создания разных правил валидации одной модели в Rails пока из коробки ничего нет.
Просто у Rails есть свои границы применимости, за которыми вся его магия оборачивается против программиста. С накоплением опыта участвуешь во всё более сложных проектах и всё чаще натыкаешься на эти границы. Поэтому со временем эта борьба с фреймворком утомляет и хочется иметь инструмент простой и предсказуемый.
Но Rails в ближайшие годы никуда не денется. И на простых проектах Вы вполне можете оставаться в рамках Rails Way и не испытывать никаких неудобств. А для сложных — посмотрите сразу в сторону trailblazer.
Насколько далеко они разошлись сейчас я не в курсе, но в 2008-2010 годах был настоящий бум — фреймворк аля Rails писали на всех популярных языках :-)