Бэкенд

Почему API переписывают через полгода и как этого избежать

Жесткие дедлайны заставляют жертвовать проектированием API ради скорости запуска. Через полгода структура данных не соответствует реальным потребностям, а каждое изменение вызывает регрессию. Разбираем, что идет не так и как закладывать гибкость на старте.

Запуск нового сервиса обычно проходит в условиях жестких дедлайнов и давления бизнеса. Приоритет — скорость, архитектура API откладывается на потом. Результат предсказуем: через полгода структура эндпоинтов не вписывается в логику продукта, интеграции становятся хрупкими, документация расходится с кодом.

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

Что ломается первым

Отсутствие контракта между клиентом и сервером — главная причина хрупкости. Когда API проектируется по принципу «сделаем быстро, потом поправим», возникают системные проблемы:

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

• Структура данных меняется без версионирования — клиенты ломаются на продакшене после деплоя.

• Нет единого источника истины для схемы — документация устаревает, разработчики полагаются на догадки.

• Безопасность добавляется постфактум — авторизация, валидация и rate limiting наслаиваются хаотично, создавая дыры.

По данным исследования Postman State of the API 2023, 40% команд тратят больше времени на исправление проблем интеграции, чем на разработку новых функций. Основная причина — отсутствие контракта на этапе проектирования.

Как закладывать гибкость на старте

Системное проектирование API не означает месяцы планирования. Речь о базовых принципах, которые экономят время в будущем:

1. Определите схему данных до первой строки кода. OpenAPI, JSON Schema или Protocol Buffers — инструмент вторичен, важен контракт между клиентом и сервером. Схема становится единым источником истины и основой для автогенерации кода.

2. Версионируйте с первого дня. Даже если изменения пока не нужны, структура для версий (через URL, заголовки или content negotiation) должна быть заложена сразу. Переход на версионирование постфактум болезненен.

3. Проектируйте эндпоинты под бизнес-операции, а не под таблицы базы. CRUD удобен для прототипа, но быстро показывает ограничения. Операции вроде «подтвердить заказ» или «пересчитать баланс» должны быть явными методами, а не набором UPDATE-запросов.

4. Закладывайте безопасность в архитектуру. Авторизация, валидация входных данных, rate limiting и логирование — не опциональные доработки, а часть контракта. Добавление их потом ломает обратную совместимость и усложняет интеграции.

Trade-offs, о которых молчат

Системное проектирование API требует времени на старте. Это замедляет первый релиз — вместо недели уходит две. Но уже через квартал экономия становится очевидной: меньше правок, стабильные интеграции, отсутствие срочных патчей из-за несовместимых изменений.

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

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

TG @ciologia

На Бирже заказов появились новые задачи для разработчиков и консультантов 1С. В подборке — заказы, размещенные с 20 по 27 мая: доработки обработок, настройка обменов, интеграция с «Честным Знаком», задачи по маркировке, ЗУП, УТ, ERP, КА и даже 1С 7.7.

Заказы недели:

• Доработка «Печать договора поставки из справочника Договоры с контрагентами (ERP 2, КА 2, УТ 11)».

• Задача 1-Необходимо создать функционал зависимых СИЗ при расчете потребности выдачи которых, на основании норм выдачи, будет учитываться количество по формуле. Задача 2-По умолчанию в заказ на выдачу должен выводится (раздельный комплект).

• Доработка «Загрузка из Гранд-Смета».

• Интеграция УТ 11.3.218 к Честному Знаку.

• 1с розница 2.3. Продажа остатков новый рмк. Ошибка «Штрихкод не соответствует товару».

• Свернуть или перенести остатки и документы на указанную дату.

• Настройка и доработка синхронизации УТ 11.4 и БП 3.0 с нуля через EnterpriseData (сворачивание номенклатуры, фильтры)

• Консультации по 1с ут 11.5.22.134.

• Доработка «Расчет накопленных дней отпуска за работу с ядохимикатами за фактически оплаченные/отработанные часы во вредных условиях труда».

• Доработка «Реестр документов для 1С:ERP 2, КА 2, УТ 11».

Биржа заказов Инфостарта помогает быстро найти исполнителя под задачи по 1С: от разовой консультации до доработки конфигурации, настройки обмена, интеграции с внешними сервисами или сопровождения проекта.

Для заказчиков доступны прямой обмен контактами, работа без комиссии, рейтинги исполнителей и безопасная сделка по желанию.

Привет, коллеги! 👋 Уже в это воскресенье, 31 мая в 10:00, устроим мощный заряд знаний! ⚡️ За 4 часа своими руками поднимем стек мониторинга, настроим дашборды и оповещения! 📊🔔

Для кого это будет полезно:
- разработчики 💻
- аналитики 📈
- системные инженеры 🔧

Все подробности здесь: https://debugskills.ru/articles/labs/prometheus-grafana/

Вебинар уже завтра: как 1С-специалисту получать больше заказов через Инфостарт

Завтра, 28 мая в 11:00 мск, проведем вебинар для 1С-специалистов, которые хотят получать больше заказов через Биржу заказов Инфостарт и выстроить стабильный поток клиентов.

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

Поговорим о том:

— как искать перспективные заказы;
— как оформлять профиль и повышать конверсию откликов;
— как оценивать стоимость работ;
— как получать обращения напрямую через профиль;
— как использовать публикации и форум для привлечения клиентов.

Также обсудим безопасную сделку, бесплатные отклики, стартмани, подписку PRO и экономику работы на площадке.

Спикеры:

Алена Солохина — руководитель отдела маркетинга Инфостарт,
Антон Репин — руководитель группы аналитиков 1С Инфостарт.

В конце — Q&A-сессия с ответами на вопросы участников. Вопросы можно оставить заранее при регистрации.

📅 28 мая, 11:00 мск
⏱ Длительность: 1 час

1С как центр бизнес-экосистемы: зачем разработчику разбираться в обмене данными

В проектах на 1С все реже встречается одна база, в которой живет весь учет. Вокруг нее обычно есть сайт, CRM, маркетплейсы, BI-система, внешние базы данных, складские сервисы и другие конфигурации. Все эти системы должны обмениваться данными: товарами, заказами, остатками, ценами, документами и контрагентами.

На курсе «Обмен данными в системе 1С:Предприятие» мы разбираем, как проектировать и реализовывать такие интеграции на практике: от обменов между конфигурациями до API, JSON, XML, HTTP- и WEB-сервисов.

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

Обмен данными — не просто техническая настройка. Это способ связать отдельные участки бизнеса в единый процесс.

Один из частых сценариев — обмен между конфигурациями 1С: «Управлением торговлей», ЗУП, «Бухгалтерией» и другими решениями. Если конфигурации типовые, часть обменов можно настроить стандартными средствами. Но в реальных проектах базы часто дорабатываются: появляются новые реквизиты, меняются документы, добавляются справочники и нестандартная логика учета.

После этого обмен перестает быть простой синхронизацией. Разработчику нужно понимать, какие данные передавать, какая база является источником истины, как сопоставлять объекты и что делать, если данные не совпали. Если в одной базе номенклатура ведется по артикулу, а в другой — по внутреннему коду, без правил сопоставления быстро появятся дубли.

Другой сценарий — интеграция 1С с внешними системами: сайтом, маркетплейсом, CRM, BI-сервисом или сторонней базой данных. На схеме все выглядит просто: 1С выгружает товары, цены и остатки, а обратно получает заказы и статусы оплат. На практике сразу появляются нюансы: API недоступен, данные пришли в неожиданном формате, заказ изменился после загрузки, внешний идентификатор не нашелся в базе.

Интеграция должна быть рассчитана не только на успешный сценарий. Важно заранее продумать обработку ошибок, повторную отправку, логирование и контроль состояния обмена. Иначе решение будет работать только в демонстрационном примере, но начнет ломаться в реальной эксплуатации.

Для обменов в 1С используются файлы, XML, JSON, XDTO, HTTP- и WEB-сервисы, внешние источники данных, COM- и OLE-технологии, планы обмена. Но выбор технологии — только часть задачи. Гораздо важнее понять логику процесса: откуда берутся данные, куда они должны попасть, кто отвечает за их актуальность и как система ведет себя при сбое.

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

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

Для пользователя важен не сам факт передачи JSON или XML, а результат: заказ попал в учет, остатки обновились, документы сформировались, отчетность не разъехалась. Поэтому разработчик 1С все чаще работает не только внутри конфигурации. Он связывает 1С с внешними сервисами, настраивает двусторонний обмен, проектирует API и помогает бизнесу избавиться от ручных операций.

Старт курса «Обмен данными в системе 1С:Предприятие» — 5 июня 2026 года.

🐍 Python Roadmap 2026: наконец-то актуальная карта изучения Python.

На GitHub выложили большой русскоязычный роадмап по Python на 2026 год - от первых скриптов до уровня Middle+/Senior.

 Маршрут собран под современный Python:

- Python 3.13+

- free-threaded mode без GIL

- JIT

- uv вместо боли с pip/venv/poetry

- ruff, pyright, pytest, hypothesis

- async-first подход

- типизация

- CPython внутри

- web, базы, ML/AI, DevOps и архитектура

В роадмапе есть нормальная последовательность: сначала окружение и база, потом идиомы, ООП, типы, стандартная библиотека, асинхронность, тестирование, внутренности CPython, web, базы данных, AI-направление, продакшн и архитектура.

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

Для джунов хороший роадмап закрыть дыры.

• Github

#junior #python

Всем привет! Предлагаю челлендж. :)

В двух словах — нужно:

1. Собрать проект DevilutionX — это кроссплатформенный порт Diablo 1 + Hellfire — и научиться запускать его, (вам для этого потребуется оригинал игры).

2. Создать в мультиплеере Hellfire персонажа и познакомиться с игрой.

3. Засекайте время с момента открытия исходников: нужно суметь получить несколько колец под названием Obsidian Ring of the Zodiac.

4. Убедиться, что эти кольца в ванильной сборке валидны, не мутируют, не исчезают и не приводят к крэшу клиента.

5. Пользоваться AI нельзя.

Эта задача по формату была бы близка финалу Challenge24. Но я её считаю лучшей из известных мне задач для собеседования инженера-программиста 10 лет назад: она проверяет способность быстро разобраться в незнакомом коде, придумать оптимальное решение и написать его.

Полная версия условия, аргументы в пользу этой задачи как “идеальной”, мой опыт собеседований, подробный анализ решений и мысли по поводу — всё здесь: kouprin.com/notes/obzod.

Я благодарен Михаилу Колупаеву, Ивану Казменко и Борису Минаеву за идеи, решения и бета-тестирование. Спасибо парням, делающим DevilutionX, — но я никого не знаю из них и не смогу ответить на вопросы о проекте.

Поскольку это не профессионально заготовленная задача, а фан, которым я делюсь с вами, то вполне могут быть следующие спецэффекты:

1. Мастер может не сбилдиться. Несмотря на то, что ребята официально поддерживают около 20 платформ, бывают необъяснимые проблемы даже на убунту.

2. Ребята в любой момент могут скрыть репозиторий или что-нибудь сделать ещё. По большому счёту, челлендж актуален только к сегодняшнему коммиту — и может протухнуть со временем из-за изменений в кодовой базе и возможных расхождениях в зависимостях. Спешите. :)

3. Я мог что-то не учесть и драматически облажаться. В таком случае — извините. :)

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

Удачи!

[Комментарий для Хабра. Это мой первый пост здесь. Изначально этот пост я опубликовал на кодфорсе, но всё-таки там чуть другой формат задач — без ковыряния в уже готовых проектах. Я изучил правила Хабра и вроде ничего не нарушаю. Я не аффилирован ни с разработчиками DevilutionX, ни с какими-либо другими компаниями, ни продаю Диаблу. Если этот текст неуместен по каким-либо причинам — дайте мне знать, я его удалю. Спасибо.]

Как перестать надеяться на бэкап и автоматизировать Disaster Recovery

В одном из материалов я уже проводил границу между бэкапом и DR, которые решают принципиально разные задачи. Если бэкап — это архивный «огнетушитель», то DR — это система пожаротушения и план эвакуации. По реакции сообщества стало понятно: разницу осознают многие, но главный вопрос остается открытым — как обеспечить предсказуемый подъем сервисов, когда инфраструктура отказала?

Наличие резервных копий гарантирует, что данные не пропадут бесследно. Но бэкап не обеспечивает непрерывность бизнеса. При масштабном сбое восстановление из архивов вручную превращается в многочасовой (а иногда и многодневный) квест, который в условиях стресса часто ведет к человеческим ошибкам и увеличению простоя.

Чтобы перевести обсуждение из теории в плоскость работающих сценариев, мы с командой решили провести технический вебинар. 27 мая в 13:00 МСК в прямом эфире представим практические кейсы по восстановлению инфраструктуры после сбоя.

В программе:

• Разберем почему бэкап не всегда спасает, и в какой момент нужен полноценный DR. Поговорим о том, как реалистично оценивать RTO и RPO.

• Покажем сценарии восстановления инфраструктуры и посмотрим, какой подход работает лучше в каждой ситуации.

• Покажем на практике:

  • восстановление данных через подключение дисков;

  • как это используется в реальных сценариях;

  • на что обратить внимание при восстановлении.

Вебинар будет полезен архитекторам, системным администраторам и всем, кто отвечает за доступность критичных систем. Приходите с вопросами по вашей инфраструктуре — разберем их в конце эфира во время сессии вопросов и ответов.

В финале встречи каждый участник получит актуализированный чек-лист для аудита плана аварийного восстановления.

👉 Зарегистрироваться на вебинар

От задач к решениям: что помогает разработчику расти в грейде

Разработчик может хорошо знать свой стек, закрывать задачи в срок и уверенно чувствовать себя в команде — и все равно в какой-то момент упереться в потолок.

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

Об этом мы поговорили с Владом Дижениным — выпускником магистратуры МФТИ, продуктовым аналитиком и разработчиком.

Если коротко разложить рост по этапам, он выглядит так:

◼️ Junior формирует фундамент: учится писать код, работать с инструментами, разбираться в задачах и командных процессах.

◼️ Middle получает больше самостоятельности. Ему уже нужно понимать не только свой участок кода, но и то, как решение связано с остальной системой, какие есть ограничения у текущей архитектуры и как изменение повлияет на соседние компоненты.

◼️ Senior работает с более широким контекстом: понимает бизнес-задачи продукта, оценивает последствия технических решений и умеет объяснять их команде.

Влад Диженин: «Если говорить кратко, то сегодня больше всего ценятся разработчики, которые сочетают сильную техническую базу с адаптивностью, ответственностью и развитыми коммуникативными навыками».

✅ По его словам, разработчику важно не застревать в привычном стеке: технологии, инструменты и подходы быстро меняются, поэтому приходится постоянно учиться, осваивать новое и браться за задачи, в которых сначала не все понятно.

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

✅ Есть и внутренние барьеры. Влад отмечает, что разработчики часто сталкиваются с синдромом самозванца: начинают сомневаться не в конкретном решении, а в собственной компетентности. Из-за этого специалисты могут избегать сложных задач, не брать ответственность и не предлагать идеи. При этом сомневаться в решениях — нормально.

Влад Диженин: «Любое хорошее техническое решение начинается с вопросов и проверки гипотез. Намного опаснее быть абсолютно уверенным в своей правоте и перестать критически оценивать собственную работу».

✅ Если говорить о профессиональных пробелах, чаще всего не хватает архитектурных знаний и продуктового мышления. Продуктовое мышление помогает понимать, какой код нужно написать и зачем он нужен продукту. Архитектурное — проектировать решения так, чтобы они оставались понятными, поддерживаемыми и масштабируемыми.

Влад Диженин: «Сочетание продуктового и архитектурного мышления чаще всего отличает сильного инженера от просто хорошего разработчика».

Расти в одиночку сложно. Можно читать документацию, проходить курсы и делать pet-проекты, но в какой-то момент очень помогает среда: команда, реальные кейсы, проектная работа, хакатоны и люди, с которыми можно обсуждать решения.

28 мая в 18:00 (Мск) пройдет День открытых дверей онлайн-магистратуры МФТИ «Разработка ИТ-продукта».

На эфире обсудим, как устроена программа, какие дисциплины и командные задачи ждут студентов, какие карьерные возможности есть у выпускников и как поступить в 2026 году.

Эфир будет полезен, если вы рассматриваете карьеру в разработке, уже пишете код, но чувствуете, что для роста не хватает системы, хотите перейти от отдельных задач к проектированию решений или думаете о росте до fullstack-разработчика, архитектора, техлида либо запуске собственного ИТ-продукта.

Регистрация: https://t.me/mipt_events_bot?start=c1777547907195-ds&utm_source=habr

⚙️ ASMLings - подробный гайд на русском

ASMLings - это набор из ~32 коротких упражнений на ассемблере Intel 8086, выстроенных по возрастанию сложности: от mov ax, 0x1337 до 32-битного сложения через carry flag, циклов, подпрограмм, работы с памятью и стеком.

Полный русскоязычный гайд по asmlings - интерактивной песочнице для изучения ассемблера Intel 8086, в которой 16-битный x86-эмулятор написан на Rust. 

Внутри: что это, как устроено под капотом, как установить, как читать и решать упражнения, разборы реальных задач из репозитория, готовые примеры в examples/ и шпаргалки.

Думаю, может быть интересно многим.

Microsoft выложила в open source AI Engineer Coach - плагин, который оценивает, насколько адекватно вы работаете с агентами и не сливаете токены в пустоту.

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

Отдельно плагин проверяет 45 анти-паттернов. Например, если вы не используете plan mode, гоняете мощные модели на мелкие задачи, повторяете одни и те же действия руками или плохо готовите проект под работу агентов - он это подсветит.

Есть и практичная часть: AI Engineer Coach анализирует, готов ли проект к агентному кодингу, есть ли нужные файлы и инструкции, находит повторяющиеся промпты и помогает превращать их в скиллы. Плюс внутри есть роадмап по вайбкодингу и ачивки, чтобы было понятно, куда расти дальше.

Всё работает локально и бесплатно. Microsoft отдельно подчёркивает, что данные никуда не отправляются.

Выглядит как полезная штука для тех, кто уже живёт в Claude Code, Codex, Cursor и похожих инструментах, но хочет понять, где реально ускоряется, а где просто красиво сжигает контекст.

https://github.com/microsoft/AI-Engineering-Coach

С 13 по 22 мая на Инфостарт Бирже заказов появились новые задачи для 1С-специалистов: доработки типовых конфигураций, внешние печатные формы, автоматизация скидок, работа с документами и проекты с использованием ИИ.

Собрали часть актуальных заказов, которые можно взять в работу.

Новые задачи недели

• Шаблоны претензий и писем-уведомлений в 1С Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.195.40);

• Доработка «Счет на оплату покупателю с QR кодом для Управление торговлей, редакция 11 (11.5.17.201);

• Доработка «Стоимость материалов и работ по ресурсной спецификации»;

• Реализовать накопительную систему скидок от общей суммы всех покупок клиента за все время, а также поддержку льготных и партнерских скидок с автоматическим расчетом на Рабочем месте кассира (РМК).

Заказы, которые еще доступны

• Заказ по статье «Векторный поиск в 1С без облаков: локальный AI-сервис для прайсов поставщиков»;

• Апгрейд 1С УТ 11.5 до 1С: Управление торговлей и взаимоотношениями с клиентами (блок CRM)»;

• Обработка 1С УНФ – зачет авансов;

• УНФ 3.0 создать внешнюю печатную форму спецификации.

Инфостарт Биржа заказов — площадка для поиска исполнителей под задачи по 1С: от небольших доработок до проектной разработки и внедрений.

Для заказчиков доступны прямой обмен контактами, работа без комиссии, рейтинги исполнителей и безопасная сделка по желанию.

OpenAI показала редкий для ИИ результат: внутренняя модель самостоятельно нашла контрпример к известной задаче из дискретной геометрии, которую Пал Эрдёш сформулировал ещё в 1946 году.

Суть задачи простая: есть n точек на плоскости. Нужно понять, сколько пар точек могут находиться ровно на расстоянии 1 друг от друга.

Долгое время считалось, что почти оптимальный ответ дают конструкции, похожие на квадратную решётку. Модель OpenAI показала, что это неверно.

Она построила бесконечное семейство конфигураций, где таких пар получается заметно больше, чем ожидалось. То есть была опровергнута не мелкая техническая деталь, а известная гипотеза, вокруг которой десятилетиями строились оценки.

 Модель связала задачу о точках на плоскости с алгебраической теорией чисел. 

В доказательстве используются решётки Минковского (способ превратить числа из алгебраической теории чисел в точки в обычном евклидовом пространстве), элементы нормы один и pro-3 башни числовых полей. Это инструменты из другой части математики, и именно их перенос в геометрию дал результат.

Нога Алон из Принстона отметил, что ответ оказался неожиданным, а применённые методы выглядят элегантно и нетривиально. 

При этом доказательство не даёт нового «чисто геометрического» метода, на который многие надеялись. Гипотеза опровергнута, но сама структура задачи стала ещё интереснее.

Задачу сформулировал ИИ, решение сгенерировала внутренняя модель OpenAI, первичная проверка тоже прошла через автоматический ИИ-пайплайн. После этого люди проверили детали, улучшили изложение и довели работу до публикации.

Модель сама нашла неочевидную связь между разными областями математики и получила результат по открытой задаче высокого уровня.

Оригинал: https://openai.com/index/model-disproves-discrete-geometry-conjecture/

В субботу 23 мая лабораторная — Docker для системных аналитиков! 🐳📊

Присоединиться и получить виртуальную машину со всеми настройками можно через Boosty! 🚀 Скидка для тех, кто хочет попробовать! 💸

Boosty - https://boosty.to/polnyistek

Подробнее - https://debugskills.ru/articles/labs/docker-basics/ 📖✨

Понял кое-что про CLAUDE.md после полугода в продакшене.

Пока файл маленький, всё работает. Потом он вырастает до 30-40 правил, и начинается: агент читает всё разом и выбирает интерпретацию которая ему удобнее. Три правила про тесты противоречат друг другу. «Никогда не делай X» конкурирует с «всегда делай X для случаев Y».

Решение которое у нас заработало: корневой CLAUDE.md только для жёстких инвариантов (что никогда нельзя, архитектурные решения). Всё остальное переехало в slash-команды и вложенные CLAUDE.md. Правило грузится только когда нужно, не конкурирует с соседями.

Плоский файл на 50 правил, это не инфраструктура, это эссе. Эссе никто не исполняет буквально.

Как вы с этим справляетесь в своих проектах?

Начинаем вебинар «Как развернуть катастрофоустойчивые сервисы в облаке Selectel»

Уже рассказываем, как построить IТ-инфраструктуру, которая продолжит работать, даже если целый дата-центр откажет. Подключайтесь к прямой трансляции.

О чем расскажем

✔ Отказоустойчивость как основа продакшена

✔ Архитектура геораспределенного облака Selectel

✔ Практика: как развернуть катастрофоустойчивые сервисы и приложения в облаке Selectel

Вы поймете, как спроектировать надежную инфраструктуру не только в теории, но и на практике.

Смотрите трансляцию:

👉 на YouTube,

👉 во ВКонтакте.

Artemis или Kafka? Как перестать выбирать и начать использовать

Архитекторы и ИТ-директора стоят перед сложным выбором: «сверхбыстрый» ActiveMQ Artemis для транзакционных сценариев с низкими задержками или горизонтально-масштабируемая Apache Kafka для потоковой аналитики и долгосрочного хранения событий. Это была ложная дилемма.

На вебинаре 22 мая в 14:00 (мск) разберем, почему Artemis и Kafka – не конкуренты, а идеальные партнеры, и покажем, как платформа Digital Q. Integration решает задачу маршрутизации «одним окном».

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

Программа вебинара:

14:00 – 14:05 Ложная дилемма выбора: почему Artemis и Kafka – не конкуренты, а партнеры

14:05 – 14:15 Две философии: почта vs лента событий. Как понять, какой инструмент под вашу задачу

14:15 – 14:25 Живые сценарии. Где критична скорость, а где – история данных

14:25 – 14:40 Решение: маршрутизация через Digital Q.Integration. Как один параметр brokerType заменяет две инфраструктуры

14:40 – 14:45 Чек-лист для принятия решения при выборе интеграционной платформы

14:45 – 15:00 Вопросы и ответы

Вебинар будет интересен:

• техническим директорам, СТО, архитекторам;

• руководителям разработки, тим-лидам, владельцам цифровых продуктов;

• тем, кто проектирует и поддерживает асинхронные системы обмена данными.   ·       

 Зарегистрироваться на мероприятие

🖥 Создатель C++ разнёс вайбкодинг: “сеньоры не хотят разгребать этот мусор”

Бьёрн Страуструп, легендарный создатель C++, в новом двухчасовом интервью резко прошёлся по вайбкодингу.

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

Особенно больно это бьёт по опытным разработчикам. Им потом приходится не “магически ускоряться с ИИ”, а читать, чинить и переписывать слоп, который кто-то нагенерировал за пять минут.

Похожая история уже достала и Линуса Торвальдса. Его буквально завалили кривыми AI-отчётами по ядру Linux: вроде бы люди “помогают”, а на практике создают шум, который мешает настоящей разработке.

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

Сеньоры не боятся ИИ.

Они просто не хотят провести остаток карьеры, разгребая чужой промптованный мусор.

Полное интервью нашел в тг тут: https://t.me/cpluspluc/1451

Большой русскоязычный roadmap по машинному обучению: от первого import numpy до LLM, RAG, fine-tuning, AI-агентов и MLOps и лучших примеров вабкодинга.

Внутри нормальная структура: что учить, в каком порядке, зачем это нужно и что должно получиться на практике после каждого этапа.

Roadmap разбит на 7 треков:

1. Фундамент: Python, математика, статистика, инструменты

2. Классический ML: scikit-learn, табличные данные, метрики, валидация

3. Deep Learning: PyTorch, CNN, RNN, training loop

4. LLM и трансформеры: attention, KV-cache, RAG, LoRA, агенты

5. Generative AI: изображения, видео, аудио, мультимодальность

6. MLOps и прод: Docker, Kubernetes, CI/CD, monitoring, serving

7. Специализация: CV, NLP, RecSys, RL, Safety

Roadmap не продаёт иллюзию “обучил модель - стал ML-инженером”.

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

Хорошая мысль из roadmap: LLM не делает джуна сеньором. Она ускоряет того, кто уже понимает базу. Без базы человек просто становится оператором Copilot, который не может объяснить, почему всё сломалось.

По времени тоже без сказок:

1. 0-3 месяца: Python, математика, классический ML

2. 3-6 месяцев: Deep Learning и PyTorch

3. 6-12 месяцев: LLM, RAG, fine-tuning, AI-агенты

4. 12+ месяцев: MLOps, прод, масштабирование, специализация

Тут же собрано 7 болших бесплатных курсов по машинному обучению, математике и вайбкодингу!

Если давно хотели зайти в ML системно, а не прыгать между роликами про ChatGPT, Stable Diffusion и “топ-10 библиотек”, это хороший ориентир.

https://github.com/justxor/MachineLearningRoadmap

Когда у ИИ не выходит каменная чаша.

Когда архитектору нечего делать, а гибкость у спины уже не та, что раньше - он начинает разговаривать сам с собой или с ИИ. Проблема, которую хотелось решить достаточно редко встречается - как бы сохранить преимущественно пустые массивы данных для аудита и не разориться при этом спустя несколько месяцев. Чтобы обуздать неуёмные галлюцинации - ИИ сразу был ограничен широко распространёнными архиваторами, результат работы которых желательно открывается из под win систем также как и из под *nix .

С позволения читателей я не буду пересказывать процесс, и перейду к тому, до чего ИИ дошёл - до 7z с рядом флажков. В прилагаемом ниже архиве вместо реальных данных - тестовые и совсем-совсем пустые. Но что ИИ пока не сумел придумать, и что внушает надежду на будущее людей в программировании и вокруг - полученный архив логично было архивировать ещё раз, тем-же 7z . Результат лично мне кажется интересным. Все желающие могут попробовать скачать почти 2 килобайта архива и предположить - какова же ёмкость исходных данных? А потом проверить себя, думаю результат вас удивит.

Архив можно Скачать с SendSpace повторюсь - в нём внутри лежит ещё один 7z архив, а уже в том - тестовые файлы числом менее 20.

Чтобы случайное разархивирование не испортило сюрприз - внешний архив закрыт паролем

Galantereyshik_i_Kardinal_eto_sila

Логически, при ещё большем количестве данных - рекурсию можно будет повторить, но в ближайшем будущем мне кажется и так неплохо вышло. Во всяком случае совсем не каждый ssd сумеет в себя вместить разархивированные из этих 1841 байтов исходные данные.

Предполагаю, что с теорией предмета знакомы все, попробуйте сами получить небольшой архив любым из широко распространённых архиваторов из скажем sparse файла в 5 гигабайт. Спорим он у вас получится больше прилагаемого к посту архива, в котором лежат терабайты.