Что не так с Ruby on Rails? (1)
Во-первых. Надо начать, почему Rails великолепен! 👑
Много лет назад Rails показал как можно делать web проекты и не страдать. Rails показал как можно навести порядок в хаосе и начать зарабатывать деньги.
Rails был настолько хорош на общем фоне, что стал законодателем мод и подходов.
Но мы растем. Проекты растут. Rails застрял в идеях 2007 года; Так вижу.
Контроллеры не нужны
Rails приучил нас к тому, что наш запрос попадает в контроллер, в котором есть несколько обработчиков — actions.
Мы не задавали вопросов. Это было круто. Роутер ➡️ Контроллер ➡️ Action ➡️ Model ➡️ View и ответ отправляется пользователю.
Через некоторое время мы начали подозревать, что в контроллерах начинается какой-то ад. Они раздуваются, наследуются, их и тестировать и поддреживать становится невозможно.
Сперва придумали тонкие контроллеры. Это было хорошо.
А можно вообще без контроллеров? Можно! И нужно!
Hanami, например, показывает как можно разделить все контроллеры на отдельные экшены.
Во-первых. Надо начать, почему Rails великолепен! 👑
Много лет назад Rails показал как можно делать web проекты и не страдать. Rails показал как можно навести порядок в хаосе и начать зарабатывать деньги.
Rails был настолько хорош на общем фоне, что стал законодателем мод и подходов.
Но мы растем. Проекты растут. Rails застрял в идеях 2007 года; Так вижу.
Контроллеры не нужны
Rails приучил нас к тому, что наш запрос попадает в контроллер, в котором есть несколько обработчиков — actions.
Мы не задавали вопросов. Это было круто. Роутер ➡️ Контроллер ➡️ Action ➡️ Model ➡️ View и ответ отправляется пользователю.
Через некоторое время мы начали подозревать, что в контроллерах начинается какой-то ад. Они раздуваются, наследуются, их и тестировать и поддреживать становится невозможно.
Сперва придумали тонкие контроллеры. Это было хорошо.
А можно вообще без контроллеров? Можно! И нужно!
Hanami, например, показывает как можно разделить все контроллеры на отдельные экшены.
👍1
Что не так с Ruby on Rails? (2)
Полностью отказываясь от контролеров мы изолируем обработчики запросов и делаем их изолированными и атомарными.
Это очень помогает обеспечить тестирование, не страдать от чтения и понимания десятков функций контроллера, которые к конкретному нужному действию не имеют никакого отношения.
Hamami это только пример. Даже на руби есть целая пачка решений, где цепочка вызовов очень простая
Router ➡️ Action
И все. Ты всегда знаешь куда смотреть, ты всегда знаешь, что в коде действия есть все что тебе нужно и ничего лишнего.
Контролировать, улучшать, поддерживать, тестировать в разы проще.
Контроллеры оказались ненужны. Оказалось, что это ненужная прослойка, которая когда-то помогала нам навести порядок, но внезапно стала проблемой.
Ruby on Rails как фреймворк не откажется от контроллеров. Это часть исторического наследия.
В 2025 я ставлю за это Rails минус.
(Иш какой дерзкий) 😅
Полностью отказываясь от контролеров мы изолируем обработчики запросов и делаем их изолированными и атомарными.
Это очень помогает обеспечить тестирование, не страдать от чтения и понимания десятков функций контроллера, которые к конкретному нужному действию не имеют никакого отношения.
Hamami это только пример. Даже на руби есть целая пачка решений, где цепочка вызовов очень простая
Router ➡️ Action
И все. Ты всегда знаешь куда смотреть, ты всегда знаешь, что в коде действия есть все что тебе нужно и ничего лишнего.
Контролировать, улучшать, поддерживать, тестировать в разы проще.
Контроллеры оказались ненужны. Оказалось, что это ненужная прослойка, которая когда-то помогала нам навести порядок, но внезапно стала проблемой.
Ruby on Rails как фреймворк не откажется от контроллеров. Это часть исторического наследия.
В 2025 я ставлю за это Rails минус.
(Иш какой дерзкий) 😅
👍2
Что не так с Ruby on Rails? (3)
Кто-то говорил, что Rails это фреймворк, который построен на соглашениях, и в нем минимум конфигурационных файлов.
Ну. 20 лет назад, в первые месяцы существования Rails так и было.
А потом появились локали, санитайзеры, очереди, задачи по расписанию, поисковые сервисы.
А еще для настройки всего этого потребовались руби файлы, где при загрузке приложения надо подкрутить и все верно настроить. А есть еще ENV переменные. Ой-вей!
И настройки линтеров, и настройки сборщиков ассетов.
Да, в рейлс есть десяток или два соглашений, которые сильно упрощают жизнь и дают душевное успокоение.
Но говорить что рельс в 2025 году живет по правилам Conventions over Configurations — прямо скажем, можно только с большим трудом.
Рельс не может жить без других инструментов, а Conventions over Configurations давно остались только лозунгом.
CoC это давно уже не преимущество Rails.
Но, может быть есть что-то другое?
Кто-то говорил, что Rails это фреймворк, который построен на соглашениях, и в нем минимум конфигурационных файлов.
Ну. 20 лет назад, в первые месяцы существования Rails так и было.
А потом появились локали, санитайзеры, очереди, задачи по расписанию, поисковые сервисы.
А еще для настройки всего этого потребовались руби файлы, где при загрузке приложения надо подкрутить и все верно настроить. А есть еще ENV переменные. Ой-вей!
И настройки линтеров, и настройки сборщиков ассетов.
Да, в рейлс есть десяток или два соглашений, которые сильно упрощают жизнь и дают душевное успокоение.
Но говорить что рельс в 2025 году живет по правилам Conventions over Configurations — прямо скажем, можно только с большим трудом.
Рельс не может жить без других инструментов, а Conventions over Configurations давно остались только лозунгом.
CoC это давно уже не преимущество Rails.
Но, может быть есть что-то другое?
👍2
Что не так с Ruby on Rails? (4)
У rails было несколько мощных инструментов, которые помогли рельсу занять лидирующую позицию в web.
1) Роутер
2) Миграции
3) Генераторы
4) Мощная ORM — Active Record.
Роутер помогал поймать запросы и отправить их в нужный контроллер / action на обработку. Роутер был красивый и удобный.
Миграции помогали поддерживать БД в нужном состоянии. Это было счастье!
Генераторы могли нагенерировать по параметрам настоящие админки. Это еще за 20 лет до появления AI.
Правда писать и поддерживать генераторы было невозможно. Их мало кто использовал.
Все эти идеи лет 15 назад растеклись по другим фреймворкам.
У rails осталось только одно — невероятно мощная и совершенная ORM.
Прослойка между программистом и Базой Данных.
Вы могли писать код на руби, а он превращался в SQL.
За 20 лет никто даже близко не подошел к тому, что бы сделать что-то хотя бы похожее.
Для меня ORM Active Record была всегда сердцем фреймворка. За это рельсу я всегда и любил по большому счету.
У rails было несколько мощных инструментов, которые помогли рельсу занять лидирующую позицию в web.
1) Роутер
2) Миграции
3) Генераторы
4) Мощная ORM — Active Record.
Роутер помогал поймать запросы и отправить их в нужный контроллер / action на обработку. Роутер был красивый и удобный.
Миграции помогали поддерживать БД в нужном состоянии. Это было счастье!
Генераторы могли нагенерировать по параметрам настоящие админки. Это еще за 20 лет до появления AI.
Правда писать и поддерживать генераторы было невозможно. Их мало кто использовал.
Все эти идеи лет 15 назад растеклись по другим фреймворкам.
У rails осталось только одно — невероятно мощная и совершенная ORM.
Прослойка между программистом и Базой Данных.
Вы могли писать код на руби, а он превращался в SQL.
За 20 лет никто даже близко не подошел к тому, что бы сделать что-то хотя бы похожее.
Для меня ORM Active Record была всегда сердцем фреймворка. За это рельсу я всегда и любил по большому счету.
👍2
Что не так с Ruby on Rails (5)
И вот получается, что все классные идеи Rails давно растеклись по интернету.
На любом языке ты можешь найти все что тебе угодно и без рельса.
Если есть понимание как работают сервисы — то интеграция одного в другое — дело несложное. Хотя и трудо и время затратное.
К 2025 году Rails растерял все преимущества. А новые подходы, которые появились у рельсовиков, фреймворк не особо то и хочет.
Но что не так с сердцем рубинового короля? Что не так с Active Record?
AR это решение одной большой проблемы. — Web программисты не любят писать SQL. Он объемный, он мало красивый, с ним трудно. А еще можно параметры вставить так, что пропустишь SQL инъекцию.
Обертка упрощающая жизнь, скрывающая детали.
И хоть AR невероятно крутая — она не может покрыть всех возможных кейсов SQL.
То и дело в проектах AR соседствует с обычным SQL, который если и можно написать на AR то с таким ужасным трудом и синтаксисом — что ну его нафиг.
Удар по сердцу Rails наносит AI.
И вот получается, что все классные идеи Rails давно растеклись по интернету.
На любом языке ты можешь найти все что тебе угодно и без рельса.
Если есть понимание как работают сервисы — то интеграция одного в другое — дело несложное. Хотя и трудо и время затратное.
К 2025 году Rails растерял все преимущества. А новые подходы, которые появились у рельсовиков, фреймворк не особо то и хочет.
Но что не так с сердцем рубинового короля? Что не так с Active Record?
AR это решение одной большой проблемы. — Web программисты не любят писать SQL. Он объемный, он мало красивый, с ним трудно. А еще можно параметры вставить так, что пропустишь SQL инъекцию.
Обертка упрощающая жизнь, скрывающая детали.
И хоть AR невероятно крутая — она не может покрыть всех возможных кейсов SQL.
То и дело в проектах AR соседствует с обычным SQL, который если и можно написать на AR то с таким ужасным трудом и синтаксисом — что ну его нафиг.
Удар по сердцу Rails наносит AI.
👍2
Прощай Active Record. SQL снова король.
Кто теперь будет бояться SQL? Никто!
Кто теперь захочет оборачивать свой SQL, в руби, в JavaScript, в Go?! Никто!
Дайте мне коннекшн к базе — и примите мой SQL обернутый в транзакцию.
AI теперь пишет, отлаживает, объясняет SQL любого объема.
Современные коннекторы MCP подключаются в вашей базе, выбирают оттуда схему данных, знают все связи таблиц и могут сделать любые JOIN через 15 таблиц и дать вам SQL ровно такой какой вам надо.
И все это за 10 секунд, а не за 3 часа отладки AR запроса или 3 дня отладки SQL в PGAdmin.
Все это вы получаете за 4 цента за запрос.
Я смотрю на Rails, фреймворк, который подарил мне столько радости, удовлетворения и денег.
Знаешь, старик, это было круто. Но, кажется, времена изменились.
Меня ждет новое приключение.
Кто теперь будет бояться SQL? Никто!
Кто теперь захочет оборачивать свой SQL, в руби, в JavaScript, в Go?! Никто!
Дайте мне коннекшн к базе — и примите мой SQL обернутый в транзакцию.
AI теперь пишет, отлаживает, объясняет SQL любого объема.
Современные коннекторы MCP подключаются в вашей базе, выбирают оттуда схему данных, знают все связи таблиц и могут сделать любые JOIN через 15 таблиц и дать вам SQL ровно такой какой вам надо.
И все это за 10 секунд, а не за 3 часа отладки AR запроса или 3 дня отладки SQL в PGAdmin.
Все это вы получаете за 4 цента за запрос.
Я смотрю на Rails, фреймворк, который подарил мне столько радости, удовлетворения и денег.
Знаешь, старик, это было круто. Но, кажется, времена изменились.
Меня ждет новое приключение.
👍3
Суббота и Миграции
День был насыщенным. Ходили с ребенком на тренировку, провели много времени в игровом центре. Стреляли с двух рук по инопланетным захватчикам, играли в разные игры, собрали почти 1000 бонусов и получили в награду игрушку, смотрели Бременских Музыкантов, поели в ресторане и день пролетел.
Семья отдыхает, а у папы pet проект. Мигратор сам себя не допишет.
Осталось расставить функции по местам и должно все заработать.
Забавно, но для бекенда сейчас я почти не прошу AI писать тесты.
Все функции которые я пишу последние дни — сервисные. Они не имеют отношения к самому проекту и я могу полагаться просто на их фактическое исполнение.
Кроме того, AI очень много мокает и по факту ценность таких тестов близка к нулю.
Чтобы нормально протестировать — надо делать эмуляцию реального процесса без моков. Но пока не до этого.
Еще AI писал очень много хлама. Проверок и Try/Catch/Finally — которые ценности не имели — я чистил, чистил, чистил.
Немного полировки и мигратор должен быть готов.
День был насыщенным. Ходили с ребенком на тренировку, провели много времени в игровом центре. Стреляли с двух рук по инопланетным захватчикам, играли в разные игры, собрали почти 1000 бонусов и получили в награду игрушку, смотрели Бременских Музыкантов, поели в ресторане и день пролетел.
Семья отдыхает, а у папы pet проект. Мигратор сам себя не допишет.
Осталось расставить функции по местам и должно все заработать.
Забавно, но для бекенда сейчас я почти не прошу AI писать тесты.
Все функции которые я пишу последние дни — сервисные. Они не имеют отношения к самому проекту и я могу полагаться просто на их фактическое исполнение.
Кроме того, AI очень много мокает и по факту ценность таких тестов близка к нулю.
Чтобы нормально протестировать — надо делать эмуляцию реального процесса без моков. Но пока не до этого.
Еще AI писал очень много хлама. Проверок и Try/Catch/Finally — которые ценности не имели — я чистил, чистил, чистил.
Немного полировки и мигратор должен быть готов.
🔥2👍1
Мигратор. Зачем и нафига?
Я почти не знаю тех, кто читает мою личную страницу и почему они все еще здесь, ведь порою я пишу вызывающе много.
Пишу для себя, потому что за работой очень быстро забываешь что вообще происходило. А этот микро-блог для меня рабочий дневник важных мне событий и мыслей.
У читателей, вероятно, может возникнуть вполне резонный вопрос — Зачем он все это делает?
1️⃣ Я делаю pet проект. В какой-то момент мне надо будет делать промо проекта — заметки помогут сформировать контент для статей.
2️⃣ Я изучаю возможности AI. Мне нужно видеть мой прогресс и развитие мыслей.
3️⃣ Я делаю мини фреймворк на JavaScript, который я смогу в нужный момент переписать на любом языке.
4️⃣ Все мои pet проекты чуть позже всегда приносят мне заработок. Полученный опыт в итоге хорошо продается на консультациях.
5️⃣ Мне просто по кайфу что-то создавать. Я делаю то, что люблю.
Мигратор готов.
Я почти не знаю тех, кто читает мою личную страницу и почему они все еще здесь, ведь порою я пишу вызывающе много.
Пишу для себя, потому что за работой очень быстро забываешь что вообще происходило. А этот микро-блог для меня рабочий дневник важных мне событий и мыслей.
У читателей, вероятно, может возникнуть вполне резонный вопрос — Зачем он все это делает?
1️⃣ Я делаю pet проект. В какой-то момент мне надо будет делать промо проекта — заметки помогут сформировать контент для статей.
2️⃣ Я изучаю возможности AI. Мне нужно видеть мой прогресс и развитие мыслей.
3️⃣ Я делаю мини фреймворк на JavaScript, который я смогу в нужный момент переписать на любом языке.
4️⃣ Все мои pet проекты чуть позже всегда приносят мне заработок. Полученный опыт в итоге хорошо продается на консультациях.
5️⃣ Мне просто по кайфу что-то создавать. Я делаю то, что люблю.
Мигратор готов.
👍3
Мигратор. Зачем и нафига? (2)
Но кроме личных личных и развлекательных мотивов есть еще и мотивы исключительно утилитарные.
1) Я выбрал SQlite как базу для проекта.
2) Предполагается, что каждый пользователь будет иметь свою собственную базу со своими данными. У этого много плюсов, но и минусов достаточно.
3) У меня должна быть и база данных на уровне всего проекта — например хранить список зарегистрированных пользователей.
Итого
Много маленьких баз данных с разными типами таблиц в зависимости от назначения.
Мигратор должен
1) Запускаться с указанием разных каталогов из которых будут браться миграции.
2) Уметь контролировать выполенные миграции, уметь откатывать их, уметь строить схему.
3) Уметь запускаться и как скрипт из консоли и как функция при работе самого проекта. — я предполагаю запускать проверку на структуру БД при запуске каждой сессии.
Из доступных вариантов на JavaScript я нашел только sequelize/umzug, но он настолько простой, что было и надежнее и веселее написать свой.
Но кроме личных личных и развлекательных мотивов есть еще и мотивы исключительно утилитарные.
1) Я выбрал SQlite как базу для проекта.
2) Предполагается, что каждый пользователь будет иметь свою собственную базу со своими данными. У этого много плюсов, но и минусов достаточно.
3) У меня должна быть и база данных на уровне всего проекта — например хранить список зарегистрированных пользователей.
Итого
Много маленьких баз данных с разными типами таблиц в зависимости от назначения.
Мигратор должен
1) Запускаться с указанием разных каталогов из которых будут браться миграции.
2) Уметь контролировать выполенные миграции, уметь откатывать их, уметь строить схему.
3) Уметь запускаться и как скрипт из консоли и как функция при работе самого проекта. — я предполагаю запускать проверку на структуру БД при запуске каждой сессии.
Из доступных вариантов на JavaScript я нашел только sequelize/umzug, но он настолько простой, что было и надежнее и веселее написать свой.
👍1