Ruby on Rails *

Интернет полон историй безупречного успеха: «Мы взяли модный фреймворк, переписали систему с нуля, и всё стало летать». Но реальный мир корпоративной разработки – это legacy. Это системы вроде Redmine, которые живут десятилетиями, хранят в себе терабайты критических данных, и чья миграция обойдется бизнесу слишком дорого.

Мы в команде ArcFront решили, что хватит терпеть интерфейсы из 2006 года. Вместо того чтобы убегать на платные облачные трекеры, мы совершили хирургическую инъекцию. Мы внедрили молниеносный React SPA прямо в ядро старого Ruby-монолита. Без микросервисов. Без CORS.

Рассказываем, как мы заставили старого пса выучить новые трюки: от архитектуры инъекции и парсинга Textile до психологии интерфейсов и нашего официального перехода на бизнес-модель Open Core.

Мы в стартапе ArcFront три недели двигались в совершенно неправильном направлении, пытаясь подружить современный React с 20-летним Redmine через сложный BFF-прокси. Рассказываем историю нашего провала, неожиданного архитектурного озарения и того, как мы выкинули две недели работы и заменили их 15 строками кода.

Вечный спор в среде MVC-фреймворков - что лучше? Толстые модели и тонкие контроллеры или наоборот?

Классический подход Rails — “Fat Model, Skinny Controller”. Но что происходит, когда ваша модель User разрастается до 800 строк кода, содержит 15 валидаций, 10 коллбеков и 30 методов бизнес-логики? Тестировать это становится кошмаром, а понять что и когда вызывается — квестом для детектива.

Сегодня мы рассмотрим альтернативный вариант — тонкие контроллеры и… тонкие модели!

Авторизация пользователей в создаваемом нами интернет магазине. Отличный гем Devise поможет вам в вопросах добавления разных пользователей на сайт

Решили мы добавить Rate Limit заголовки к ошибкам SubscriptionRequiredError, чтобы фронт понимал, какие лимиты превышены. Но внезапно при обработке ошибки пропал request. А значит — нет ни headers, ни current_user. Куда он делся и как это починить?

В любой компании, рано или поздно встает вопрос контроля сроков реакции и выполнения тех или иных задач. В статье речь пойдет о желании внедрить SLA (Service Level Agreement) в Redmine, о том как попытка найти и установить готовое решение, обернулось мини исследованием.

У меня было Falcon-приложение на Async, и в нём накопились задачи, которые надо было выполнять где-то рядом: cron-задачи, интервалы, отложенные джобы. Классический ответ — Sidekiq + Redis. Но ради трёх задач в минуту тащить в проект Redis с отдельным контейнером, отдельным процессом и отдельной точкой отказа казалось перебором. А альтернативы либо тянули за собой Postgres (который в большинстве проектов уже занят бизнес-логикой и плохо реагирует, когда на него вешают ещё и очередь задач), либо не дружили с Async event loop.

Так родился async-background — лёгкий планировщик, у которого нет внешних зависимостей кроме SQLite, который живёт в том же event loop что и Falcon, и в котором я смог реализовать ещё одну важную для меня штуку — управляемую утилизацию воркеров: можно явно сказать «эти два воркера только cron, эти два только очередь», или прибить конкретную задачу к конкретному процессу, без переписывания кода.

В статье — история создания гема: какие альтернативы я смотрел и почему они не подошли, какие принципы я зафиксировал на берегу, какие технические находки получились по ходу (min-heap вместо тиков, две шкалы времени, CRC32-шардинг для multi-process safety, UNIX-сокеты для мгновенного wake-up очереди), и какие гочи я нашёл лбом — включая историю про то, как Docker overlay2 ел мою SQLite базу под нагрузкой на staging.

Это адаптация моей англоязычной статьи на Medium

Всем известный Ruby on Rails, как самый яркий пример использования DSL, позволяет разработчикам абстрагироваться от низкоуровневых деталей реализации и сосредоточиться на бизнес-логике. Написание кода выглядит очень лаконично и выразительно, но как это работает? Давайте разберемся на простом примере.

Всем привет! С вами Федор Засечкин, и это моя вторая статья из цикла о том, как мы в Купере распиливали монолит. Если хотите максимально погрузиться в контекст, перед чтением этого текста загляните по ссылке:

Микросервисная трансформация в Купере — как это было. Часть I: Начинаем распил монолитов

А в продолжение темы я хочу поговорить о том, с чего начинается вынос функциональности в сервисы. Будут и вопросы чисто технического характера, и организационные — потому что в нашем случае вынос состоял в основном из проектов с кросс-командным взаимодействием и иннерсорсом. Поехали!

Бывает так, что запускаешь тесты, а они падают там, где вроде бы всё должно работать. В логах — только сухая ошибка, без контекста. Открываешь код, смотришь на участок кода, где произошёл сбой, и начинаешь гадать:

В Ruby‑разработке ActiveRecord давно стал стандартом: он интуитивно понятен, встроен в Rails и позволяет быстро проводить CRUD‑операции. По мере роста проекта его «удобство» нередко начинает оборачиваться скрытыми проблемами.

Привет, Хабр! Уверен, у вас тоже такое бывало: сидишь в проде, сервис падает, а нужного ответа нет ни в Confluence, ни в старых чатах. В итоге бесконечный скролл в «телеге», повторы вопросов в почте и потерянные часы на поиски того, что кто-то уже когда-то решал. Мы уперлись в эту проблему лбом и поняли, что нам нужен инструмент, который аккумулирует знания и делает доступными. 

Меня зовут Денис Селков, я техлид разработки внутреннего Q&A‑портал МТС DevTools Stack. С помощью этого продукта мы упорядочили накопление знаний, и в этом материале я покажу, что дает такая относительно простая механика и как ее можно прокачать с помощью ИИ-инструментов. 

ActionMailbox в рельсах изначально был заточен на использование платных 3rd-party сервисов. Подключить его к обычному имейлу можно было либо поднимая/перенастраивая почтовый сервер, либо через костыли. Костыли так или иначе заключались в поднятии дополнительного сервиса. Статья на Medium предлагает поднять fetchmail, заброшенный гем предлагает запускать почтовый клиент на Rust.

Когда тест проходит с первого раза — это пугает. Стоицизм в TDD — не методология, а форма выживания.

Мне хочется создать простой и понятный скрипт интернет магазина. Который будет полезен людям. И в котором сразу по умолчанию будут имется все базовые вещи. Такие как фильтр, корзина, система оплаты, загрузка из экселя и так далее.

Скрипт будет иметь открытый исходный код. И кроме этого он должен быть легко устанавливаеммым на хостинг. Даже на шаред хостинг тарифах.

В качестве интсрумента мы выбираем Ruby on Rails. Почему? Во-первых он очень функциональный. Во-вторых он относительно простой. В-третьих с ним можно делать сайты быстрее чем на любом другом фреймворке. Раз на раз в этом отношении Рейлсы сделают любого. И еще один плюс состоит в том что этот фреймворк часто выбирают для e-commerce. Например такие гиганты как Shopify, Coinbase, Airnb как раз сделаны на нем.

Сам процесс создания будет изложен как курс. Который может быть полезен начинающим программистам. И так начнем!

В последние месяцы я всё чаще сталкиваюсь с одним и тем же выводом: внедрение LLM-систем (особенно с использованием RAG-подхода) тормозится не из-за самой модели, а из-за отсутствия качественных данных. Самое дорогое в процессе — это не запуск пайплайна, не подбор архитектуры, а подготовка структурированных, очищенных и корректных данных, пригодных для обучения или дообучения моделей. Всё чаще этот подход называют AI-Ready Data.

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

Всем привет, думаю, читатель, нажавший на данный заголовок, уже догадывается, о чем примерно пойдет речь. Данная статья рассчитана на тех, у кого уже есть какое-либо понимания языков программирования (лучше если именно Ruby), а также хотя бы общие сведения о HTML, работе ОС и сети.

Для тех, кто не в курсе в мире веб разработки существует фреймворк Ruby on Rails. Фреймворк горячо любим автором и сообществом и используется для создания полнофункционального сайта или по-другому веб приложения. Но все ли знают и понимают, как оно там вообще работает?

Делюсь лайфхаком по уменьшению размеров Docker-образов. Как-то нам попалась на поддержку и развитие CRM-система, написанная на Ruby...

Обновили Ruby-пакеты и под них код, написали Dockerfile. Первая сборка была удручающей: образ в 2Гб. Это нормальный размер, если ты собираешь образ с Torch и другой ML-штуковиной, но CRM - нет. В результате дальнейших действий, удалось сократить размер образа до 200Мб.

Привет! Меня зовут Дима, я архитектор в Купере. Сегодня расскажу о шаблоне проектирования Strangler, который мы использовали для поэтапного выноса бизнес-логики из монолитной системы в отдельный сервис. 

Сначала обратимся к первоисточнику, а затем перейдем к практическим моментам, с которыми столкнулись в процессе работы. Поехали!