Решили мы добавить Rate Limit заголовки к ошибкам SubscriptionRequiredError, чтобы фронт понимал, какие лимиты превышены. Но внезапно при обработке ошибки пропал request. А значит — нет ни headers, ни current_user. Куда он делся и как это починить?
Обзор Phoenix LiveView и его друзей из других стеков: Rails Hotwire, Laravel Livewire и Go Live/HLive
Все эти фреймворки позволяют создавать динамические страницы без ручного вызова API (и без AJAX :)
В любой компании, рано или поздно встает вопрос контроля сроков реакции и выполнения тех или иных задач. В статье речь пойдет о желании внедрить 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 — не методология, а форма выживания.
В последние месяцы я всё чаще сталкиваюсь с одним и тем же выводом: внедрение 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, который мы использовали для поэтапного выноса бизнес-логики из монолитной системы в отдельный сервис.
Сначала обратимся к первоисточнику, а затем перейдем к практическим моментам, с которыми столкнулись в процессе работы. Поехали!
Добрый вечер, уважаемые читатели Хабра, Хабровчане, а также все спеллчекеры с личным мнением - мое специализированное почтение.
Перед вами пример Первого Инженерного Действия, а именно пример принятия решения в обстоятельствах неопределенности, с ходом обдумывания дальнейших шагов развития в ситуации с обозначенным топиком - пора валить, куда как, кого, опенсорс, самопис, заказ и тд и тп.
Большинство известных мне случаев при принятии решений характеризуются одним общим показателем - отсутствием письменного размышления при принятии решений.
Те кто приходят к этой практике получают много полезного в своей жизни.
Так как Хабр это текстовый портал, привожу текстовый пример, демонстративный, он имеет основания, шаги, таблички, действия и заключения.
Написан в форме условного диалога, как могло бы происходить коллективное размышление в этой ситуации у заинтересованной стороны и возможного выполнителя этого замысла.
В наличии корректное оформление для уважения читателя, Ноушн пишется с прописной и с курсивом.
Желаю приятного прочтения.
Привет, хабровчане!
Давно не писал, потому что для меня Хабр изначально был DIY-тусовкой, в хорошем смысле этого слова, а у меня ничего DIYйного не было.
А сейчас вот появилось -- решил демонстрации ради запилить Notion из рельсов и шпалок.
К постановке вопроса зачем мы вернемся, как это принято тут и у всех айтишников -- в самом конце, а сейчас к конкретике и без воды.
Разрабатываем telegram mini-app используя Ruby on Rails
С недавних пор функциональность телеграм сильно выросла, помимо привычных нам ботов особенно ярко выделяются telegram-mini app. Покопавшись в том как это работает, у авторов данной статьи появилась идея написать небольшое приложение и желание высказать некоторые тезисы, которыми хотелось бы поделиться с сообществом.
Привет, Хабр! Я Александр Непомнящих, QA в СберМаркете. Мы с командой кодим программу лояльности, которая позволяет списывать в заказах бонусы «Спасибо», а также запускать различные акции с повышенным начислением бонусов.
Для безопасного внедрения многие изменения закрывались фича-флагами, разрасталась ролевая модель, становилось больше фичей. Всё это увеличивало количество действий для подготовки тестового стенда, их количество обычно достигало 9. Да, нужно было совершить девять разных операций, чтобы подготовить стенд к работе с бонусами.
Если вы занимаетесь тестированием, заходите под кат — расскажу, как мы в итоге автоматизировали процесс до 1 команды в Rails-консоли.
