Эти плюшки хороши, когда Вам надо сделать блог за 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.
Автор использует несколько драматичный слог, когда вспоминает о Merb и DataMapper, но по большому счёту так и было. Более полное понимание можно получить прочитав статью по ссылке из статьи «Rails and Merb Merge». Если вкратце, то Rails Core Team обещала реализовать модульность и низкую связность, в частности легкость отказа от ActiveRecord в пользу DataMapper или Sequel. По факту всё оказалось не так радужно, как в обещаниях.
А чтобы форкаться и продолжать пилить нужны команда и ресурсы, а команда Merb как раз распалась в результате того «объединения».
где User.changeset — это обычная функция, определенная в модуле User
def changeset(struct, params \\ %{}) do
struct
|> cast(params, @allowed_fields)
|> validate_required(@required_fields)
end
И всё, никаких скрытых колбеков и никакой магии. Если данные пользователя редактируются через несколько форм с разными требованиями по обязательным полям, то можно создать changeset-функцию для каждой формы. Другими словами валидация полностью отвязана от модели и работа с БД тоже полностью отвязана от модели.
Основной вопрос — а куда?
Пётр явно называет Clojure и Elixir, а также Hanami для тех, кто не готов изучать новые языки.
По внутреннему устройству Phoenix совсем не похож на RoR. Он гораздо проще и по сути является набором plugs, которые можно использовать и комбинировать по своему усмотрению, + Ecto для работы с базами данных + Channels для веб-сокетов.
Собственно, Plug — и есть центральная концепция, чем-то сродни middleware в Ruby, только используется единообразно на всю глубину стека: роутер — это plug, контролер — тоже plug и т.д.
Каждый второй пишет какую-нибудь библиотеку для какой-нибудь задачи (csv, orm etc), которые находятся в разных состояниях готовности.
Как по мне, это жирный минус экосистемы Go. У меня есть опыт написания микросервисов на Go, но даже в рамках микросервиса этот буриданов выбор из кучи библиотек, которые делают одно и то же, начинает раздражать. Причём большинство из них напрочь лишены версионности и приходится линковать их к проекту по ревизии в master-ветке o_O
Кстати, для управления зависимостями в Go тоже 100500 альтернатив и ни одной, которая по удобству была бы близка к bundler или hex.
Для себя решил отказом от Go в пользу Elixir. Да, по памяти Go экономнее, но не критично. А по производительности для веб-сервера они одинаковы с точностью до погрешности. При этом код на Elixir получается проще, лаконичнее и понятнее. Хоть и требует, чтобы программист был в курсе функциональной парадигмы и потратил недельку на знакомство с OTP.
А зачем бороться с тем, что Go ругают? Многим не нравятся языки, которые вводят искусственные ограничения. И это вполне нормально, особенно с учётом того, что есть отличные альтернативы, например: Elixir и Nim.
пока сумма налога не превысила сумму взносов — всех-всех налогов по 4 тысячи в квартал (на УСН 6 %)
А откуда взялась цифра 4 тыс. в квартал? Минимальные страховые взносы в этом году чуть больше 23 тыс. рублей, ну или 5788 за квартал. Или это о чём-то другом?
Любопытнее, что 72% (а особенно первые 16%) велосипедят для разработки несложных проектов. Готовые движки вполне позволяют подстраивание под конкретный проект. Они для этого и написаны и в их разработку вложены тысячи человеко-часов. И тут Вы либо собираете команду и вкладываете эти тысячи часов (что недопустимо для несложных проектов), либо кое-как кодите на коленке нечто одному Вам понятное…
Очень рекомендую всем, кто имеет дело с Rails, книгу «Rails Anti-Patterns». В ней описаны многие анти-паттерны, на которые в какой-то мере провоцирует сам Rails.
Однако, основная мысль статьи в том, что не стоит идеализировать Rails. Он симпатично выглядит снаружи, но внутри никогда особо не блистал понятностью или удобством. К тому же фреймворк оброс кучей функционала, часть из которого весьма спорна, и стал медленно развиваться в плане действительно важных вещей… В чём-то он уже пытается догнать конкурентов, к примеру, наконец-то добавляя поддержку веб-сокетов.
На тему самого Ruby тоже спохватились и пытаются угнаться за языками, на которые идёт массовый переход: Ruby 3x3, Concurrent Ruby
В Rails долгим и мучительным путём пришли к тому, что вызывающий код должен преобразовать параметры самостоятельно:
Но куда подобные методы помещать не придумали и пихают пока прямо в контролеры, что в нетривиальных случаях приводит к реализациям user_params, разбросанным по разным файлам.
А вот для создания разных правил валидации одной модели в Rails пока из коробки ничего нет.
Просто у Rails есть свои границы применимости, за которыми вся его магия оборачивается против программиста. С накоплением опыта участвуешь во всё более сложных проектах и всё чаще натыкаешься на эти границы. Поэтому со временем эта борьба с фреймворком утомляет и хочется иметь инструмент простой и предсказуемый.
Но Rails в ближайшие годы никуда не денется. И на простых проектах Вы вполне можете оставаться в рамках Rails Way и не испытывать никаких неудобств. А для сложных — посмотрите сразу в сторону trailblazer.
Насколько далеко они разошлись сейчас я не в курсе, но в 2008-2010 годах был настоящий бум — фреймворк аля Rails писали на всех популярных языках :-)
А чтобы форкаться и продолжать пилить нужны команда и ресурсы, а команда Merb как раз распалась в результате того «объединения».
где User.changeset — это обычная функция, определенная в модуле User
И всё, никаких скрытых колбеков и никакой магии. Если данные пользователя редактируются через несколько форм с разными требованиями по обязательным полям, то можно создать changeset-функцию для каждой формы. Другими словами валидация полностью отвязана от модели и работа с БД тоже полностью отвязана от модели.
Пётр явно называет Clojure и Elixir, а также Hanami для тех, кто не готов изучать новые языки.
Собственно, Plug — и есть центральная концепция, чем-то сродни middleware в Ruby, только используется единообразно на всю глубину стека: роутер — это plug, контролер — тоже plug и т.д.
Кстати, для управления зависимостями в Go тоже 100500 альтернатив и ни одной, которая по удобству была бы близка к bundler или hex.
Для себя решил отказом от Go в пользу Elixir. Да, по памяти Go экономнее, но не критично. А по производительности для веб-сервера они одинаковы с точностью до погрешности. При этом код на Elixir получается проще, лаконичнее и понятнее. Хоть и требует, чтобы программист был в курсе функциональной парадигмы и потратил недельку на знакомство с OTP.
А пока из консоли браузера выполните
дабы не видеть это безобразие xD