Два часа потерял из-за того, что не написал один хендлер
Делал платежи в Telegram-боте. Нативные, через sendInvoice и ЮKassa.
Всё настроил: токен от BotFather получил, инвойс отправляется, кнопка оплаты появляется. Пользователь нажимает - и платёж падает с ошибкой. Молча. Без подробностей.
Payment failed
И всё. Telegram не говорит что именно не так.
Полез гуглить. Первая мысль - provider_token неверный. Проверил три раза, скопировал заново. Нет, токен правильный.
Потом решил что проблема в суммах - они передаются в копейках, не в рублях. 500 рублей = 50000. Перепроверил, у меня было правильно.
Потом подумал на webhook - может HTTPS не настроен как надо. Потратил минут сорок на проверку сертификата, перенастройку ngrok. Всё работает, но платежи всё равно падают.
Уже хотел идти спать, случайно наткнулся на строчку в документации:
Your bot must reply to this query in 10 seconds
Это про pre_checkout_query. Когда пользователь нажимает «Оплатить» - Telegram сначала отправляет боту запрос на подтверждение. Бот должен ответить в течение 10 секунд. Если не ответил - платёж автоматически отклоняется.
У меня хендлера для этого не было вообще. Бот просто молчал.
Вы пробовали ChatGPT и Cursor. Но система из нескольких AI-агентов — это другой уровень: агенты конфликтуют, теряют контекст, зацикливаются, а отладка напоминает расследование без улик.
🎻 Один AI = музыкант. Несколько AI = оркестр. А кто дирижёр?
19 июля, 10:00-14:00 МСК — лабораторная работа с Андреем Чуяном, создателем ROLES-экосистемы (3 экосистемы, 15+ ролей). За 4 часа: проектирование AI-ролей с YAML-контрактами, 5 хаос-сценариев, MCP-сервер на личной VM, самодиагностика экосистемы.
📐 Проверенная методология FPF + TDD в основе каждого блока.
Теперь есть официальный integration guide, где показано, как ты можешь подключить MCP-сервер к AI-assistant’у и использовать его для нормального HITL workflow вокруг CV-аугментаций: подобрать pipeline, провалидировать его, отрендерить локальные previews, сравнить baseline и candidate, дать feedback вроде too_noisy:high и экспортировать финальный pipeline.
Приятно видеть, что проект стал частью экосистемной документации Albumentations. 🙂
AlbumentationsX MCP это конечно же не замена Python API, а assistant-facing review layer для тех случаев, когда ты хочешь быстрее и безопаснее работать с augmentation pipelines.
Тамагочи, но вместо котика – команда разработчиков. И она выгорает, пока вы читаете этот пост
Помните тамагочи? Пищащий брелок, который тихо умирал, если про него забыть на выходных.
Мы сделали такой же. Только вместо котика у вас разработчик и команда. Вместо «покормить» – 1-on-1, код-ревью, менторство и релизы. Забьете на пару дней – вернетесь к просевшему доверию и зреющему конфликту.
И живет это все прямо в терминале на сайте. Без установки, без регистрации, без «оставьте почту».
Тамагочи в терминале
Что это
team – симулятор тимлида в консольном режиме нашего сообщества. Не модалка с кнопками: вы открываете фейковый (но честно рабочий) терминал и печатаете команды.
team new – и у вас есть напарник-стажер и живая команда.
Дальше вы его растите от стажера до CTO.
Цель проста на словах: дорастить человека до уровня «тимлид» и выкатить пять релизов, не развалив команду по дороге.
Почему это тамагочи, а не просто игра
Вот тут начинается интересное. Состояние живет в localStorage и распадается в реальном времени.
Пропали на день – доверие просело, конфликт подрос, напарник задремал. Пропали надолго – рискуете вернуться к game over: команда либо выгорела, либо развалилась от конфликтов.
Это питомец, который ждет. И портится без вас.
Дилеммы из реальных споров
Периодически прилетает инцидент. Звезда принесла оффер +40% и мнется. Прод упал в пятницу в 18:00. Двое неделю спорят: монолит против микросервисов. Выбираете вариант – получаете последствия в метриках и в журнале команды.
И часть инцидентов подтягивается из живого бэклога вопросов нашего сообщества. То есть в игру попадают дилеммы, которые реально обсуждали практикующие тимлиды, а не выдуманные кейсы из учебника.
Как сыграть
Никакой установки. Открываете терминал и печатаете team:
Во время обучения многим удобно иметь материал не только в формате уроков, но и в виде единого пособия, к которому можно быстро вернуться в любой момент.
Поэтому я решил подготовить книгу, полностью основанную на материалах курса. Она повторяет структуру уроков и позволяет легко закреплять пройденный материал.
Что представляет собой книга
Книга полностью соответствует программе курса и может использоваться параллельно с его прохождением.
Её можно использовать как:
офлайн-версию курса для повторения материала;
удобный конспект при выполнении практических заданий;
справочник для быстрого повторения основных конструкций SQL.
Если вы уже проходите курс, книга поможет быстрее находить нужную информацию и возвращаться к темам, которые хочется повторить.
Для кого она будет полезна
Так же, как и сам курс, книга ориентирована на тех, кто только начинает знакомство с SQL:
студентов IT-специальностей;
начинающих разработчиков;
будущих аналитиков данных;
тестировщиков;
всех, кто хочет разобраться в основах работы с реляционными базами данных.
Бесплатный доступ
Книга распространяется бесплатно.
Если вы проходите курс «SQL Введение», она уже доступна внутри курса в качестве дополнительного учебного материала.
Кроме того, книга опубликована на GitHub, где всегда можно скачать последнюю актуальную версию.
Буду рад вашим отзывам, предложениям и замечаниям как по курсу, так и по книге. Надеюсь, этот дополнительный материал сделает изучение SQL ещё более удобным и понятным.
На Бирже заказов Инфостарта опубликована новая подборка задач по 1С. В списке за неделю - внедрение «1С:Управление торговлей», обмены с бухгалтерией, настройка УПД и ЭДО, интеграция с Битрикс, подготовка технического задания на драйвер связи и другие работы.
В этой подборке — заказы, размещенные с 24 июня по 1 июля. На этой неделе в подборку вошли задачи для специалистов по «1С:Управление торговлей», «1С:Комплексной автоматизации», ЭДО, УПД, обменам с бухгалтерией, интеграциям с Битрикс и разработке решений на платформе 1С.
Биржа заказов Инфостарта помогает быстро найти исполнителя под задачу по 1С - от консультации и небольшой доработки до внедрения, настройки обменов, интеграции с внешними сервисами или сопровождения системы.
Формат подходит и заказчикам, которым нужен специалист под конкретную задачу, и исполнителям, которые хотят выбирать проекты по стеку, объему работ и срокам.
На площадке доступны:
0% комиссии — расчеты напрямую с подрядчиком;
исполнители разного масштаба — от одного разработчика до ИТ-команды;
Как не пропустить опасные участки кода при ревью? Можно воспользоваться инструментами статического анализа. Возьмём для примера OrcaSlicer — популярную программу, которая подготавливает 3D-модель к печати. Заглянем внутрь и посмотрим, какие сюрпризы нас ждут.
Посмотрим на одно из предупреждений статического анализатора PVS-Studio:
V1047 Lifetime of the lambda is greater than lifetime of the local variable ‘do_stop’ captured by reference. FillBedJob.cpp 250
Лямбда-выражение захватывает локальную переменную do_stop по ссылке, а затем сохраняется в params.on_packed. При этом do_stop уничтожается при выходе из метода process, так как заканчивается время жизни локального объекта. Если лямбда будет вызвана после выхода из этой функции-члена, произойдёт обращение к разрушенному объекту, и поведение в этой ситуации не определено.
Можно было бы сделать захват по значению, но в этой лямбде происходит перезапись переменной do_stop, а значит такой вариант не подходит. Поэтому можно сделать do_stop членом класса FillBedJob.
Это лишь один фрагмент, показывающий, что даже в работающем продукте могут быть ошибки. А другие опасные места в коде OrcaSlicer разобрали в новой статье.
Если вы тоже хотите минимизировать ошибки в своих проектах, сделайте статический анализ частью регулярного процесса, а поможет с этим PVS-Studio.
🤖 🤖 🤖 К счастью или сожалению, ИИ-инструменты стали нормой в сфере разработки софта. И если раньше ещё был некоторый скепсис, что «стрельнет» эта штука или нет, то теперь очевидно — либо вы освоите ИИ-инструменты, либо вы пойдёте на мороз.
Фишка ИИ заключается в том, что с ним достаточно легко получить какой-то результат, который в ряде случаев будет уместным. Однако добиться нужного результата нужного качества — достаточно сложно.
И тут у нас есть три пути:
1) Двигаться маленькими шагами, задавая ожидаемый результат ИИ-агенту. В данном случае агент полностью полагается на ваше руководство и вашу постановку и выполняет исключительно работу руками. До текущего момента я использовал именно эту технику и был вполне доволен.
2) Полагаться на итерации и самопроверку. Этот подход рекламируют разработчики ИИ-сервисов, когда вы задаёте финальную точку, а дальше ИИ-агент генерит много кода, выполняет самопроверку, удаляет большую часть, генерит её снова и так по кругу, пока не получится нужный результат. На демках это в целом работает, в реальных проектах — большие сомнения. Ну и те самые мемчики, когда разработчик тратит на токены больше, чем он зарабатывает в месяц.
3) Идеологом третьего подхода является Мэтт Покок (Matt Pocock), который предлагает технику разработки, основанную на скилах, которые сначала опрашивают тебя обо всех нюансах проекта, потом готовят документ, содержащий доменное знание. После этого разбивает задачу на маленькие таски и выполняет их, основываясь на доменное знание. Т.е. что-то из мира TDD, DDD и прочих техник.
Мне в своё время не очень зашло TDD в силу инверсии принципа разработки, которым я всегда работал. Но после ознакомления с тем, как предлагает работать Мэтт, кажется, эта штука может работать.
Cобственно, на этой неделе разбирал, как он предполагает работать, знакомился с его репозиторием скилов и дальше буду пробовать — https://github.com/mattpocock/skills
Листая на C++ Reference список принятых в C++29 фичей, увидел в нем пропозал с знакомым названием, «Thread attributes» (P2019R9). И, оказалось, действительно, я уже читал этот пропозал 4 года назад, но не в 9-й его редакции, а в самой первой. 4 года понадобилось комитету по стандартизации, чтобы принять пустячный пропозал, позволяющий задать имя и размер стека потока при его создании — востребованную фичу, реализованную в куче библиотек C++.
void f();
int main() {
// Такой вид задания атрибутов предлагался в первой ревизии
std::jthread P2019R1(
f, std::thread_name("Worker"),
std::thread_stack_size(512*1024));
// А такой приняли 8 ревизий спустя
std::jthread P2019R9(
std::thread::name_hint("Worker"),
std::thread::stack_size_hint(512*1024), f);
}
Не безумие ли это? И сколько действительно правильных пропозалов не вошло в C++ лишь по той причине, что их автор не был готов 4 года подряд защищать свое предложение, отвечая на все мелкие придирки различных подкомитетов?
Облачный сервис с безграничными возможностями: Бот или не бот - вот в чем вопрос.
Друзьям и коллегам, привет!
Недавно опубликовал на Хабр новую статью с разбором моего Web3-мессенджера. В ней описал личный кейс: как внедрить децентрализованные Web3 технологии и монетизировать внутренние функции приложения без подключения классических платежных систем. Почитать можно здесь: https://habr.com/ru/articles/1052088/
Дополняя тему мессенджера, хочу поделиться нововведением, которое значительно расширило возможности моего приложения. Надеюсь это будет полезно и другим разработчикам.
Создав так называемых "юзер-ботов" (user-bots), я снабдил платформу дополнительными функциями. В моей реализации такой "Бот" - это полноценный внешний сервис, который имеет точку входа - Endpoint на стороннем облаке и строгий протокол взаимодействия через его API.
В таких популярных приложениях как Telegram или WhatsApp, боты представляют собой отдельные сущности, которые привязываются к основному аккаунту пользователя. Кстати, вопреки расхожему мнению, один аккаунт в Telegram может создать через BotFather не безграничное число ботов, а строго до 20 штук (до 40 для Premium-пользователей).
В своей архитектуре я пошел совершенно другим путем. В моей схеме "Бот" по своей сути - это тот же самый пользователь, только виртуальный. Такой подход позволяет в любой момент переключить обычного юзера в бота и наоборот одним кликом.
пример бота реализующего сервис загрузки музыкального контента артиста на радио
Хотя при таком методе не получится создать «армию ботов» на один аккаунт. На каждого бота придется заводить новый. Но с точки зрения безопасности и чистоты архитектуры плюсы очевидны:
Полный контроль и безопасность окружения: бот изолирован и работает строго в рамках правил реального пользователя.
Защита от фишинга: это минимизирует риски мошенничества, делая бота реальным, полноценным аккаунтом, а не простой сервисной записью в базе данных.
Готовая монетизация: в профиле каждого пользователя уже прописаны платежные данные в виде Web3-кошелька. Соответственно, они автоматически доступны и боту, если тот реализует платные услуги.
РЕАЛИЗАЦИЯ НА БЭКЕНДЕ
Ниже упрощенный код класса реализующий передачу сообщений на Endpoint:
public async Task<string> ExecuteCommand(string cmd, string uid, string token, string url)
{
using var client = new HttpClient();
client.DefaultRequestHeaders.Authorization = new ("Bearer", token);
var body = new StringContent(JsonConvert.SerializeObject(new { data = cmd, user_id = uid }), Encoding.UTF8, "application/json");
var res = await client.PostAsync(url, body);
var json = JObject.Parse(await res.Content.ReadAsStringAsync());
return json["success"]?.Value<bool>() == true
? json["data"]?.ToString()
: $"Error: {json["error"]}";
}
Используя описанную концепцию, можно в теории реализовать любой сервис не изменяя при этом основное приложение. Всё что нужно сделать, построить бот!
Очевидно, что для практического применения такого подхода необходимо обеспечить высокий уровень безопасности: внедрить защиту от SSRF (через валидацию URL и фильтрацию локальных хостов), настроить лимиты для предотвращения DoS-атак (проверяя размер заголовков и длину полученной строки), и так далее.
В этом докладе Илья Виссарионов рассказывает о практическом опыте компании «Диасофт» по импортозамещению крупной автоматизированной банковской системы, которая десятилетиями работала на Microsoft SQL Server.
Главной особенностью проекта стало то, что значительная часть бизнес-логики была реализована в виде хранимых процедур. Полное переписывание миллионов строк SQL-кода оказалось бы слишком дорогим и длительным, поэтому был выбран другой путь — развитие Digital Q.DataBase с максимальной совместимостью с Microsoft SQL Server и сохранением существующих приложений.
В докладе подробно рассматриваются реальные технические проблемы, с которыми столкнулась команда при переносе банковской системы на PostgreSQL-совместимую платформу: различия в типах данных, работе процедур, оптимизаторе запросов, производительности, временных таблицах, пользовательских типах данных и других механизмах СУБД.
Отдельное внимание уделено нагрузочному тестированию. Автор показывает, как поэтапная оптимизация Digital Q.DataBase позволила добиться производительности, сравнимой с Microsoft SQL Server, а по ряду операций — превзойти её, при этом сохранив существующую бизнес-логику без масштабного переписывания.
В этом видео вы узнаете:
🔹 почему импортозамещение крупных банковских систем требует особого подхода; 🔹 с какими проблемами столкнулась команда при переносе АБС с Microsoft SQL Server; 🔹 почему стандартного PostgreSQL оказалось недостаточно; 🔹 какие механизмы совместимости были реализованы в Digital Q.DataBase; 🔹 как удалось сохранить существующий T-SQL-код без его переписывания; 🔹 какие доработки были выполнены для повышения производительности; 🔹 как проводилось нагрузочное тестирование на реальных банковских сценариях; 🔹 каких результатов удалось добиться по сравнению с Microsoft SQL Server.
Если вас интересуют вопросы импортозамещения СУБД, миграции корпоративных систем или построения PostgreSQL-совместимых платформ корпоративного уровня — этот доклад будет полезен разработчикам, архитекторам, администраторам баз данных и техническим руководителям.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений. Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Как мы воспроизводим функциональность Oracle и создаем аналоги DBMS-пакетов.
В предыдущем посте я рассказывал о технологии «Полиглот» в Digital Q.DataBase — возможности исполнять T-SQL "на лету" наряду с родным PL/pgSQL, что позволяет мигрировать приложения с Microsoft SQL Server.
Но полиглотность Digital Q.DataBase этим не ограничивается.
Сегодня хочу поделиться выступлением моего коллеги Ильи Лебедева, посвящённым Oracle-направлению. В докладе он подробно рассказывает о поддержке PL/SQL и о том, как Digital Q.DataBase помогает переносить системы с Oracle, сохраняя серверную бизнес-логику и клиентские приложения без дорогостоящей переработки.
В этом выступлении обсуждаются:
🔹 Как Digital Q.DataBase реализует полноценную поддержку Oracle-диалекта, включая пакеты, DBMS-пакеты и PL/SQL-код. 🔹 Почему SQL- и PL/SQL-код может выполняться без изменений. 🔹 Как работает мастер переноса баз данных и какие скорости миграции можно получить на практике. 🔹 Каким образом обеспечивается бесшовное подключение существующих приложений через OCI и JDBC. 🔹 Почему переход с Oracle на Digital Q.DataBase может занять месяцы вместо лет. 🔹 Как накопленный опыт миграций позволяет ускорять последующие проекты и снижать объем доработок.
В докладе также показаны реальные сценарии переноса корпоративных систем, демонстрация работы клиентских приложений после замены СУБД и подход компании к развитию совместимости с Oracle на основе запросов заказчиков.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений. Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Создадим один и тот же REST-сервис на Spring Boot и на Quarkus, сравним время старта и затраты ресурсов.
Разберём настоящий случай из промышленной разработки. Вебинар будет полезен специалистам, которые хотят ускорить свои приложения и снизить счета за облако.
Содержание:
✅ Проблема долгого запуска и высокого потребления памяти в Spring Boot.
✅ Что такое Quarkus? Окружающая среда расширений, родная сборка.
✅ Живой код: создание REST-сервиса на Spring Boot и на Quarkus.
✅ Измерение времени запуска и потребления памяти.
✅ Как родная сборка ускоряет размещение в Kubernetes и снижает затраты.
✅ Настоящий случай из практики автора.
✅ Как продолжить изучение Quarkus.
🧑🎓 Спикер: Чвилёв Константин, эксперт в области разработки ПО
В этом докладе я (Жуйков Андрей, амбассадор компании «Диасофт») рассказываю о подходе Digital Q.DataBase к импортозамещению зарубежных СУБД и миграции корпоративных систем без переписывания прикладного кода.
В видео рассмотрены:
🔹 архитектура и возможности Digital Q.DataBase; 🔹 технология Polyglot и поддержка нескольких SQL-диалектов в одной СУБД; 🔹 совместимость с Microsoft SQL Server и Oracle; 🔹 исполнение T-SQL и PL/SQL без изменения бизнес-логики приложений; 🔹 поддержка протокола TDS и работа со стандартными драйверами Microsoft; 🔹 миграция 1С с Microsoft SQL Server на Digital Q.DataBase; 🔹 демонстрация работы через DBeaver, SQL Server Management Studio и Python; 🔹 поддержка Service Broker, Reporting Services и CLR-сборок; 🔹 примеры реальных проектов и опыт внедрения у заказчиков.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений.
Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Переход с 1С:УПП: как сохранить контроль над учетом и данными
«Слона-то я и не приметил»: скрытые риски перехода с УПП, которые важно увидеть до старта проекта
В 2027 году поддержка 1С:УПП завершится. Без обновлений под изменения законодательства регламентированный учет в этой системе станет зоной риска.
Как перейти на новое решение без потери контроля над учетом, данными и сроками?
2 июля в 11:00 (мск) на вебинаре в формате проектных «притч» разберем самые частые проблемы миграции:
👉 разрозненные ожидания ИТ, финансовой службы и бизнеса 👉 критичные и спорные доработки 👉 рост объема работ после старта 👉 качество НСИ и разрыв в терминологии
Расскажем, как заранее увидеть эти риски и превратить переход с УПП в управляемый проект.
За время преподавания SQL я заметил одну проблему: многие начинающие сталкиваются со слишком сложными объяснениями уже на первых этапах обучения. Вместо понимания базовых принципов работы с данными люди сразу погружаются в большое количество терминов, теории и особенностей конкретных СУБД.
Поэтому я решил создать курс, который поможет сделать самый первый шаг в изучении SQL максимально простым и понятным.
Курс ориентирован на тех, кто:
никогда раньше не работал с базами данных;
не писал SQL-запросы;
хочет понять основы SQL перед дальнейшим обучением;
учится на IT-специальности;
рассматривает карьеру разработчика, аналитика данных, тестировщика или бизнес-аналитика.
Специальных знаний для прохождения не требуется. Достаточно базовой компьютерной грамотности и желания разобраться в теме.
Что изучается в курсе
В рамках курса рассматриваются базовые принципы работы реляционных баз данных и основные конструкции SQL.
В процессе обучения вы разберётесь с основами SQL и научитесь:
• понимать, как устроены таблицы и данные
• писать первые SQL-запросы
• выбирать столбцы из таблицы
• фильтровать данные
• использовать операторы сравнения
• формировать простые выборки
Материал построен по принципу «от простого к сложному». Каждый новый урок опирается на предыдущий, поэтому курс подходит даже тем, кто начинает изучение SQL с нуля.
Курс включает:
теоретические уроки;
тестовые задания для проверки понимания материала;
практические упражнения с SQL-запросами.
Главная цель курса — помочь новичку разобраться в фундаментальных принципах работы с данными и научиться уверенно писать свои первые SQL-запросы.
Почему курс бесплатный
Я хотел создать качественную точку входа в SQL, доступную каждому. Многие люди только начинают свой путь в IT и ещё не готовы покупать большие программы обучения. Бесплатный вводный курс позволяет понять основы и решить, интересно ли двигаться дальше в этом направлении.
Буду рад обратной связи, замечаниям и предложениям по улучшению курса.
Порядок сообщений, DLQ, graceful shutdown, spike нагрузки — на каждый вопрос есть минимум два рабочих ответа
Витя Михайлов, Backend Lead Garage Eight, и Женя Янченко, руководитель разработки и автор тг-канала @jane_yanchenko, разобрали 5 вопросов про брокеры со стороны RabbitMQ и Kafka соответственно.
Вопрос 1. Как вы обеспечиваете порядок сообщений, когда это критично для бизнес-логики? Например, событие «покупка товара» не должно обработаться раньше события «счет пополнен».
RabbitMQ:
Только один консьюмер на очередь.
Ack( ) только после завершения бизнес-логики.
Если используешь nack — убедись, что тип очереди не quorum: он меняет логику requeue.
Publish только строго с confirmation mode, и обработчиком connection.blocked, чтобы FlowControl не испортил нам порядок (выключить его нельзя).
— Витя
Kafka:
Kafka обеспечивает порядок в рамках одной партиции. Партиция определяется по ключу: все сообщения с одинаковым ключом попадут в одну партицию.
Например, если выбрать ключом ID заказа, все события по нему попадут в одну партицию.
Нюансы:
определенные настройки ретраев продюсера могут привести к нарушению порядка
изменение числа партиций может сломать прежнее распределение
— Женя
Вопрос 2. Что делать с сообщением, которое консьюмер не может обработать уже 10 раз подряд? Стратегии retry, DLQ, алертинг — как это устроено на практике.
RabbitMQ:
Сначала понять: можно ли вообще обработать сообщение? Битый JSON или некорректные данные — повторные попытки бессмысленны. Отправляем в DLX или дропаем с записью в лог.
Если обработать можно — два варианта:
1) Ретраить бесконечно (осторожно: poison message handling). Нужен мониторинг и rate limit на повторы. 2) Отбросить в DLQ, но тогда теряем порядок обработки.
— Витя
Kafka:
Заводим отдельный топик — Dead Letter Queue (DLQ).
1) Пробуем обработать сообщение. Успех — коммитим оффсет. 2) Ошибка — ретраим N раз. Помогает при временных сбоях (БД не ответила), но не при битом сообщении. 3) Попытки исчерпаны — отправляем в DLQ в исходном виде + пишем в лог. 4) Сообщения в DLQ анализируются вручную.
Вопрос 3. Как обеспечить обратную совместимость схемы сообщений при обновлении сервиса? Продюсер и консьюмер деплоятся независимо — как не сломать друг друга.
RabbitMQ:
Нельзя. Ломать. Обратную совместимость.
Миграция работает так: в какой-то момент поддерживаешь обе схемы параллельно, затем выключаешь старую. Хороший пример с тремя реальными сценариями миграции — официальный гайд RabbitMQ по переходу с classic на quorum queues.
— Витя
Kafka:
Схема сообщений в топике — публичный контракт, как в REST API. Изменения проектируем так, чтобы обе версии какое-то время работали параллельно.
Безопасно: Добавить необязательное поле, добавить поле с дефолтом, перестать использовать поле (но не удалять).
Опасно: Переименовать, изменить тип, удалить обязательное поле, поменять смысл.Для валидации схем — Schema Registry (особенно при Avro или Protobuf).
Зачем ИТ-специалисту магистратура: открытый эфир онлайн-программы МФТИ «Разработка ИТ-продукта»
2 июля в 18:00 МФТИ проведет открытый эфир, посвященный онлайн-магистратуре «Разработка ИТ-продукта».
На встрече расскажут, как устроено обучение, какая предполагается нагрузка и как студенты работают над проектными задачами.
Эфир будет полезен разработчикам, аналитикам и ИТ-специалистам, которые хотят развиваться в backend- или fullstack-разработке, глубже разбираться в архитектуре ПО, системном проектировании и работе над технологическими продуктами.
В программе эфира:
— Как устроена программа магистратуры: дисциплины, расписание занятий и формат командной работы.
— Проектная работа: какие задачи студенты решают во время обучения.
— Поступление в 2026 году: документы, вступительные испытания и подготовка.
🗣 Гость эфира: академический директор программы Антон Устинов — директор по технологиям и информационным технологиям (CTO/CIO) с более чем 15-летним опытом в разработке и проектировании архитектуры финтех- и EdTech-продуктов (Сбер, Exante, Click, SmartBank), кандидат экономических наук и сертифицированный архитектор Сбера.
Биржа работает: новые заказы недели с 17 по 24 июня
В новой подборке Биржи заказов - актуальные задачи для специалистов по 1С и смежным системам: доработки готовых решений, технологический аудит и поиск причин зависаний, интеграции между конфигурациями, настройка кассового оборудования, оптимизация медленных обработок, проверка расчетов по зарплате, налогам и УСН, автоматизация мотивации сотрудников, подключение мессенджеров и чат-ботов, а также доработки для банковских и логистических процессов.
Посмотрите список - возможно, среди этих заказов есть проект под ваш опыт:
Биржа заказов: найдется исполнитель под любую задачу
Инфостарт Биржа заказов помогает быстро найти специалиста под задачу по 1С: для консультации, доработки конфигурации, настройки обмена, интеграции с внешними сервисами или сопровождения проекта.
Размещайте заказ, выбирайте исполнителя по опыту, рейтингу и откликам и договаривайтесь напрямую.
