Ruby *

Решили мы добавить 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

Представьте себе пятиэтажный дом без лифта, построенный в конце пятидесятых, где-нибудь на отшибе Автозаводской, или еще лучше – в Купчино. Каждый этаж использует свой язык со своей записью. Не в переносном, а в самом прямом смысле: первый этаж общается кириллицей, второй – латиницей, третий – иероглифами, четвертый – клинописью, а пятый, подобно Витгенштейну, принципиально молчит, полагая, что о чем невозможно говорить, о том следует молчать. Почтальон, доставляющий корреспонденцию, вынужден нести пять экземпляров одного и того же письма, переведенного на каждый из этих языков, и каждый раз стучаться в дверь, надеясь, что адресат не переехал на другой этаж.

Именно так устроен мир программирования. Проблема очевидна любому, кто хоть раз пытался написать инструмент для анализа кода. Допустим, вы создали превосходный анализатор цикломатической сложности для Python. Он великолепен: находит вложенные условия, считает точки ветвления, рисует графы потоков управления. Затем к вам приходит коллега и спрашивает: «А для Ruby сделаешь?» И тут выясняется, что весь ваш труд – все эти обходчики деревьев, все эти паттерн-матчинги над питоновским AST – нужно переписать заново. С нуля. Для другого дерева, с другими узлами, другой семантикой и другими подводными камнями. А потом придет третий коллега и попросит то же самое для Haskell.

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

Пара слов о том, как программисты разных конфессий справляются с самой очевидной задачей в Computer Science.

Примеры правильных и неправильных разворотов списка на десяти разных языках.

В последнее время мне довелось много заниматься распараллеливанием однопоточного кода и показалось уместным свести воедино более-менее всё, что нам известно про разные типы многозадачности, с примерами и комментариями.

Примеры на Ruby, Go, Java.

"Loom" означает "ткацкий станок" - так назывался проект по добавлению асинхронности в джаву. Тяжёлые системные потоки заменили легковесными виртуальными потоками. Потоки и нити в английском называются одинаково - thread - отсюда название.

Проект успешно внедрили пару лет назад, и я, к сожалению, это полностью пропустил. Основная причина, конечно - что я в принципе не ожидал от джавы никаких прорывов (и оказался на 100% неправ!) Ну и, как бэкенд-разработчик на питоне, я не очень-то слежу за развитием JVM-языков.

Но исправляюсь: Project Loom - это блестящая идея. Учитывая, что его внедрили совместимым образом, и почти не было ломающих изменений. Я считаю, это оптимальная реализация асинхронности для высокоуровневого серверного языка.

Уже почти все использующие JVM языки переехали на новую версию JVM, и, таким образом, на проект Loom: деваться им некуда. Так что, есть надежда, что это изменение откроет новую главу для некоторых из них. Есть также предположение, как оно может повлиять на скриптовые языки, такие как питон. Гипотеза только.

Также, вы узнаете, почему Гвидо ван Россум не ошибся, когда добавлял async/await в питон, а Мацумото — создатель Ruby — тоже угадал, когда, наоборот, отказался от async/await.

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

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

Привет! Меня зовут Фёдор Засечкин. С 2023 года я руковожу группой разработки операционной платформы в Купере. Наша команда отвечает за стабильность и развитие сервисов, которые обеспечивают сборку и доставку заказов, а также найм и выход партнёров в смены.

Последние два года наша ключевая задача — микросервисная трансформация. Мы постепенно распиливаем монолит, перераспределяя нагрузку по сервисам. На сегодня более 1 000 RPS HTTP-трафика уже ушло с монолита; до полного завершения осталось около 30 RPS и часть межсервисных интеграций.

Я решил написать серию статей о том, как мы проходили этот путь: что сработало, какие ошибки допустили и какие решения реально помогли. Этот текст — первый из серии.

Некоторые считают Java раздутым монстром, а Rust — чемпионом производительности. Но что, если взглянуть на современную Java с Vector API и многопоточностью? 

В новом переводе от команды Spring АйО посмотрим на запуск масштабной симуляции частиц и сравним результаты. Правда ли, что бывалая Java всё ещё умеет удивлять? 

Сравнение performance-а языков всегда было холиварной темой. Рекомендуем расценивать статью как приглашение к конструктивной дискуссиии, а не как призыв к конкретному действию.

Я 10 лет был клиентом AWS и контрибьютором проектов с открытым исходным кодом, а они удалили мой аккаунт и все данные без какого‑либо предупреждения. Ниже — история о том, как «верификация» у AWS превратилась в цифровую казнь и почему нельзя доверять облачным провайдерам, если у вас нет копий данных вне облака.

На 23 июля 2025 года AWS удалил мой аккаунт, которому было 10 лет, и каждый байт данных, который я там хранил. Без предупреждения. Без льготного периода. Без возможности восстановления. Произошла полная цифровая аннигиляция.

Ниже я расскажу историю о катастрофической внутренней ошибке в AWS MENA, 20 днях кошмарного общения с поддержкой, в ходе которого я так и не получил прямого ответа на вопрос «Мои данные ещё существуют?», и о том, что всё это показывает в отношении доверия облачным провайдерам.

Вы когда-нибудь сталкивались с плагинами, которые лезут в чужие папки, перезаписывают файлы ядра и превращают git status в ад?

Я — да. И вместо того чтобы мириться с ручным копированием, гигантскими .gitignore и вечными конфликтами, написал dmp — инструмент, который:
 Отслеживает, откуда взялся каждый файл,
 Автоматически разрешает конфликты (или даёт контроль),
 Не ломает IDE (никаких симлинков!),
 Работает с любыми языками и фреймворками.

Для кого:
— Разработчики плагинов/модулей,
— Те, кто устал от git-submodules и rsync,
— Все, кто хочет чистый workflow без монрепозитория.

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

Что происходит, когда GitHub берётся за собственную безопасность? Они пишут код для защиты кода — и активно используют для этого CodeQL. В этой статье команда Product Security Engineering рассказывает, как настроить масштабный автоматический анализ уязвимостей, зачем создавать свои пакеты запросов и как с помощью CodeQL находить ошибки, которые невозможно поймать обычным поиском по коду.

Есть множество сервисов и программ по сборке программных пакетов: OpenSuse Build Service (OBS), koji. Fedora copr, rpmbuild, mock.

Все они позволяют организовать сборку программных пакетов, релиз пакетов в репозиторий и пр. Большинство систем обладают обширным функционалом, например тот же OBS позволяет собирать как deb пакеты, так и rpm, так и AppImage и т. д. Koji позволяет разбить сборку по разным машинам и управляя билдерами организовать сборку огромного числа тяжелых пакетов, многие комплексы типа OBS и Copr вообще организованы в виде сервисов в сети и позволяют различным пользователям собирать пакеты и публиковать их в публичных репозиториях.

Зачем же еще понадобилось дополнительное средство по организации сборки rpm пакетов и репозиториев?

Объясню - хотелось бы что-то простое в установке и настройке, как например gitea, такое, что можно просто поднять на локальной машине и организовать сборку из проектов, которых не так много и которые не такие монструозные, требующие несколько билдеров.

Один из самых вредоносных принципов в разработке, когда-либо получивших широкую известность — YAGNI. Его озвучил Рон Джеффрис в 1998, а спустя более двадцати лет — еще и Кармак подлил керосин в огонь со своим: «Неопытным разработчикам трудно оценить, как редко разработка архитектуры с учетом будущих требований приводит к успеху».

Вообще говоря, в нашем разнообразном мире ни одна максима не может быть без оговорок применима всегда. Насколько могу судить, будучи сформулированным столь безжалостно афористично, принцип YAGNI привел к тому, что у лентяев появилась отговорка на все случаи жизни.

— Давай предусмотрим передачу конфигурационных параметров в эту функцию? — YAGNI.
— Инъекция зависимости здесь уместнее приколоченной гвоздями реализации хранилища. — YAGNI.
— Черный кофе без сахара, пожалуйста. — YAGNI!

Всем привет! На связи Speach (ex. IT-People). В прошлом году мы сменили имя, но не изменили своей любви к конференциям. И продолжаем организовывать самые душевные и классные мероприятия для айтишников. Приглашаем принять в них участие.

25 апреля, DUMP EKB, Екатеринбург

Крупнейшая конференция разработчиков на Урале, куда приезжают более 2000 человек! Конференция, которая традиционно собирает топовых IT-экспертов со всей страны. В 12 секциях прозвучат десятки докладов ТОЛЬКО на актуальные темы. Впервые в этом году — новая секция: TechLead. А также — Backend (2), Frontend, Testing&QA, Team, Product, ML&DS, BA&SA, DevOps, Design, Science, круглые столы, воркшопы, нетворкинг и афтепати.

С версии 3.0 в руби появились неблокирующие файберы, с помощью которых писать код с асинхронным вводом-выводом стало заметно удобнее. В данной статье мы напишем свой простой планировщик для файберов, чтобы лучше разобраться, как работают более сложные планировщики, типа socketry/async.