Программирование *

Коннекторы 1С: быстрая интеграция через OData в Digital Q.Integration

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

На вебинаре эксперты компании «Диасофт» расскажут, как организовать обмен данными между 1С и внешними системами с помощью готового коннектора платформы Digital Q.Integration, реализованного на базе протокола OData. Вы узнаете, какие подходы для интеграции с 1С существуют, почему именно OData выбран в качестве технологической основы решения и какие преимущества это дает при построении современных интеграционных процессов.

Во время демонстрации покажем, как:

• настроить подключение к 1С с помощью коннектора Q.Integration;

• получать данные из 1С;

• добавлять/изменять данные в 1С;

• автоматизировать интеграционные процессы средствами платформы Digital Q.Integration.

Программа

13:00 – 13:10 Введение. Почему интеграция с 1С остается актуальной задачей и какие подходы используются для ее реализации.

13:10 – 13:25 Подходы к интеграции с 1С. Рассмотрим основные способы организации обмена данными, сравним интеграцию через OData и использование специализированных конфигураций 1С, разберем преимущества и ограничения каждого подхода.

13:25 – 13:40 Коннектор 1С в Digital Q.Integration. Расскажем, как реализован коннектор, какие процессы автоматизированы, как устроена работа с OData и какие возможности получает пользователь при настройке интеграции.

13:40 – 13:55 Практическая демонстрация. Покажем настройку коннектора, получение данных из 1С и изменение.

13:55 – 14:00 Вопросы и ответы. Ответим на вопросы участников и обсудим практические кейсы использования коннектора.

Кому полезен вебинар:

• ИТ-директорам и техническим руководителям;

• архитекторам интеграционных решений;

• руководителям проектов цифровой трансформации;

• разработчикам и интеграторам;

• специалистам по сопровождению корпоративных информационных систем.

Спикеры:

• Виктор Овчинников, руководитель продукта Digital Q.Integration компании «Диасофт»

• Андрей Даниленко, ведущий разработчик MSA департамента «Цифровые решения» компании «Диасофт»

Зарегистрироваться на мероприятие можно по ссылке

Какие уникальные фичи есть в django-modern-rest?

Иногда, когда я добавляю какие-то фичи в мой https://github.com/wemake-services/django-modern-rest (можно ставить ⭐), то я думаю про себя: почему таких фичей больше нет нигде? 

Давайте сегодня посмотрим на них. А вы мне расскажите свое мнение в комментах.

Семантическая схема 

Допустим, вы навесили на какой-то свой endpoint auth: 

class UserController(Controller[MsgspecSerializer]):
      @modify(auth=[JWTAsyncAuth()])
      async def get(self) -> User: ...

В OpenAPI автоматически появятся все коды ошибок, которые могут случиться в auth (401).
Ничего не надо допом писать. И так происходит со всеми частями фреймворка: добавил throttling=[SyncThrottle(1, Rate.minute)]? Теперь у тебя в ответах автоматом 429. Если нужно, можно отключить любые семантические статусы. 

Не должно ли такое быть дефолтом везде?

Умные типы ошибок

Не уходя далеко: как кастомизировать формат ошибки, например, в FastAPI? Через боль. Как поменять в спеке формат? Руками.

В DMR мы просто добавили везде error_model как параметр. Можно заменять любые ошибки, все автоматом сконвертится и покажет правильную схему. Зачем? Хочешь Problem Details - используешь. Хочешь свой формат - реализуешь. Можно даже content negotiation на ошибки навесить.

Почему никто о таком не думает в других фреймворках?

Нормальный throttling

Фича, которая принесла мне больше всех боли. Я прочитал throttling реализации во всех фреймворках. В Litestar даже фиксы присылал. 

1. Почти нигде из коробки нет поддержки разных алгоритмов, бекендов, иногда даже cache-keys. Очень жаль, есть только обычный counter с бекендом в памяти
2. Нигде (пришлите в комменты контр-пример) нет разделения на throttling до auth и после. Почему такое вообще важно? Чтобы не заддосить auth. И чтобы иметь возможность выдавать per-user правила. Нужны и важны оба варианта
3. Кастомизация заголовков ответа? Ха!

Что? Почему?

Простое переиспользование кода

Когда я смотрю на АПИ разных DRF проектов или FastAPI, мне становится больно. FastAPI строит все на view функциях, которые нельзя нормально кастомизировать. А DRF строит все на импортах строк внутри настроек. А как на счет классов и наследования?

У нас подобное сделано как абстрактные generic классы. Например: получить JWT. Можно выбрать любой сериализатор, можно выбрать любые модели для запроса и ответа:

class RequestPayload(pydantic.BaseModel):
     username: str
     password: str

class ResponsePayload(pydantic.BaseModel):
     access: str
     refresh: str

class ObtainAccessAndRefreshSyncController(
    ObtainTokensSyncController[
        PydanticSerializer,
        RequestPayload,
        ResponsePayload,
    ],
): ...  # надо еще переопределить 2 метода

Все типизировано, документировано, очевидно. 
Как вы думаете, почему так больше никто не делает?

Внешние вьюхи

Интегрировать один фреймворк в другой - крайне сложно. Вот мы недавно даже стрим проводили, потому что не могли использовать dj-rest-auth из DRF. Так быть не должно.

Теперь в DMR можно использовать любые внешние Django View. Хоть DRF, хоть django-ninja, хоть ванильные вьюхи. И отображать любой внешний OpenAPI. Вот настолько просто:

raw_schema = read_openapi_yaml('openapi.yml')
router = Router(
    urls=[
        external_path(
            'number/', number, name='number',
            openapi=load_schema(raw_schema['paths']['/api/number'], PathItem),
        ),
    ],
)

Почему другие фреймворки не стараются вписать существующие решения?

Одной строкой

- Больше подобного у меня в тегеграм канале "Находки в опенсорсе": https://t.me/opensource_findings
- У нас есть еще куча других крутых фичей! Заглядывайте в наш чатик по DMR
- Релизнули django-stubs@6.1 с поддержкой django@6.1
- Сделали папку с крутыми каналами ребят из нашего Python сообщества. Смело можно закидывать коллегам как базовую папку "на кого подписаться в тг по питону". Внутри все мои друзья и коллеги, советую!

МТС True Tech Champ 2026: выбирай свой трек и получи до 10 250 000 ₽ за победу 🔥

Регистрация на четвертый сезон True Tech Champ в самом разгаре. Мероприятие объединяет разработчиков, студентов и школьников со всей страны — все этапы, кроме финала, проходят онлайн.

Участвуй в одном из двух треков: алгоритмическом или программировании роботов, дойди до грандиозного шоу-финала и побеждай!

⚙️ Индивидуальный алгоритмический трек для бэкенд- и фронтенд-разработчиков, фулстек-инженеров, ML-специалистов и всех, кто хочет проверить себя в олимпиадном формате.

• Решай задачи по алгоритмам и структурам данных — это прокачает навыки для технических собеседований и работы в ведущих ИТ-командах.

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

• Призовой фонд — 2 750 000 рублей.

🤖 Групповой трек «Программирование роботов» для разработчиков, архитекторов и всех, кому интересно программировать физические объекты:

• Проходи трассу и выполняй задания по передаче предметов.

• Затем — удалённое управление реальным полигоном с робособакой и роботом-манипулятором.

• В очном финале лучшие команды дорабатывают алгоритмы на глазах у зрителей и борются за победу в МТС Live Холл в Москве.

• Призовой фонд — 7 500 000 рублей.

Участие бесплатное, а лучшие участники получат шанс на стажировку в МТС Web Services (MWS).

➡️ Выбирай свой трек и регистрируйся по ссылке.

Чуть лучше код

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

Что дано:

1. поход в базу (начальные данные)

2. поход по апи за списком (указателей или стримов)

3. для каждого (репорта): поход по апи за данными и сохранение в базу

Легко пишем (неправильный) скрипт, кладем в крон и профит? Почти. Через пару лет в дев базе 2kk записей и селект ну очень долго ждать. Порядочные пацаны (и девушки) пишут тесты на sqlite, и неявно имплeмeнтируют идемпотентность, создавая и дропая базу данных на каждую пачку тестов. Sql insert не является идемпотентной операцией, но с пустой базой прокатывает.

В чем, собственно, проблема? Идемпотентность (от лат. idem — тот же самый и potens — сильный, буквально — равносильность) — свойство объекта или операции при повторном применении операции к объекту давать тот же результат, что и при первом. Так вот, sql insert и app_call(date_now) не обладают идемпотентностью.

Что делать? Как и в примере выше, создаем искусственную идемпотентность (да, этот термин повторится еще много раз), вынося в контекст доступ к базе, апи вызовы и т.д. (трансформация csv). Короче, контекст может быть пустой и код должен корректно работать. Или в контексте будет передан доступ к базе, но без апи вызовов или трансформации csv. И опять код должен работать корректно.

Чем заменить? Дефолтными значениями, как ни странно, дефолтные значения идемпотентны, если это, например, список и словарь. Удачного кодинга :)

P.S.: Хотел приложить примеры кода, но кол-во строк оказалось больше размера статьи :)

Пассажир меняет билет прямо в дороге — а маршрут собран из трёх GDS и ж/д. Что происходит с данными

Сотруднику нужно долететь до одного города, доехать поездом до другого, и обратно тем же путём — одна командировка, билеты из разных систем бронирования. А потом он уже в дороге пишет в телеграм: "планы изменились, летим не туда, перебронируй".

Три системы под самолёты — Amadeus, Sabre, Travelport: исторически несовместимые XML-диалекты одного и того же понятия перелёта, выросшие из мейнфреймов 60-80-х, каждый со своими причудами и полями, которых нет у соседа. Плюс отдельная, никак не связанная с ними система бронирования под железную дорогу — свой формат, своя логика мест и классов, ничего общего по структуре с авиационными GDS. Запросить всё это параллельно, свести разноформатные ответы в одно и собрать из них валидный маршрут по стыковкам — уже само по себе задача не для россыпи if и ручных мапперов.

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

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

Первая — как описать саму логику поверх этого зоопарка источников. И сбор из четырёх систем разом, и ветка "можно менять / нельзя менять" превращаются либо в DSL на языке общепринятых интеграционных паттернов (Scatter-Gather, Content-Based Router — тот же словарь, что у Apache Camel), который прочитает и поймёт человек, ни разу его не писавший, — либо в код, который через полгода не восстановит и автор.

Вторая — куда положить результат. Маршрут — не два поля outbound/return, а последовательность разнотипных плеч (самолёт ≠ поезд), где число элементов и состав не известны заранее и меняются посреди собственной жизни объекта. Стандартный ответ — либо гора nullable-колонок под все виды транспорта разом, либо миграция на каждый новый вид.

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

Скоро.

ссылки: хабр redb.ru

Мой топ бэнчмарков

Какую модель запустить на 2xV100, 2x32 GB VRAM: Gemma-4-26B или Qwen-3.6-35B. Обе современные. Обе от топовых компаний, обе мультимодальные, у обеих качественный маркетинг. Количество параметров и требования к железу - аналогичные. Но Gemma абсолютно неконкурентна и в любом типе задач измеримо хуже. В таких грубых случаях бенчмарки отлично описывают модели. Они и в менее грубых помогают, но там уже есть некоторое отклонение от реальности.

https://artificialanalysis.ai/ - Топ-1 по популярности и взвешенности решения. Состоит из 9 бенчмарков и составляет 3 индекса на их основе: интеллект, кодинг и агентные способности. Содержит все модели и добавляет их в течение 2 дней после выхода. Модели OpenAI добавляет день в день. Поменял свой индекс, чтобы показать, что GPT-5.6 Sol лучше Opus 4.8, но если вы пользуетесь только одним бенчмарком - пусть это будет он.

https://deepswe.datacurve.ai/ - бенчмарк SOTA-моделей на реальных задачах программирования. Основной формат представления - процент решённых задач против цены на одну задачу. То есть даже лучше, чем цена за токен, ведь одни модели используют больше токенов, чем другие. Задачи максимально продуманы и глубоки. На данный момент не переполнен и реально показывает полезность моделей для программирования.

https://arena.ai/leaderboard - так же, как и Artificial Analysis, не один бенчмарк, а целая коллекция. Начинал со сравнения пользовательских предпочтений, но сейчас имеет куда больше разделов. Упал в популярности, но всё ещё полезен для нишевых вопросов вроде сравнения качества поиска или генерации картинок

GitHub превратили в TikTok — теперь новые библиотеки, инструменты и идеи для своих проектов можно находить обычными свайпами. Сервис Roamers показывает бесконечную ленту открытых репозиториев, почти как рилсы. Если войти через GitHub, рекомендации подстроятся под ваши интересы, но листать можно и анонимно.

Эксперт «Диасофт» примет участие в круглом столе IT-World «Почему хорошие системы плохо работают вместе?»

6 августа 2026 года в 16:00 IT-World проведет круглый стол «Почему хорошие системы плохо работают вместе?». В нем примет участие Дмитрий Гаврин, заместитель директора департамента «Цифровые решения» и один из авторов блога компании «Диасофт» (Как 30 лет боли в интеграции привели нас к собственной платформе)

О чем будут говорить спикеры:           

• Почему интеграции остаются одной из самых болезненных зон корпоративного ИТ-ландшафта?

• Что чаще ломает взаимодействие систем - слабые API, разные модели данных, отсутствие владельца процесса или спешка внедрения?

• Как оценивать API-зрелость решения до покупки: документация, версионирование, песочница, ограничения, поддержка изменений?

• Как меняется ответственность поставщика ИТ-решения, если его продукт становится частью большого корпоративного контура?

• Что должно происходить с интеграциями при обновлении продукта, смене версии или доработке соседней системы?

• Почему единые справочники и мастер-данные остаются проблемой даже там, где уже есть MDM, НСИ или корпоративная шина?

• Где проходит граница между быстрой автоматизацией и архитектурным долгом, который потом мешает масштабировать решение?

• Какие требования к интеграциям, API, данным и поддержке стоит включать в ТЗ, договор и критерии выбора поставщика?

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

Регистрация по ссылке

Две недели назад я получил $5 000 кредитов Azure по программе Microsoft for Startups и за четырнадцать дней я сжёг из них $2 100 на одной настройке, которую “забыл” вернуть обратно. В разработке PhotoMentor у меня работают три модели с закреплёнными ролями: GPT как CPO и исполнитель, Kimi K2.7-Code как red team – обе на Azure – и Claude как ревьюер, на моей собственной подписке. Когда я проектировал биллинг для Android, я осознанно выкрутил ризонинг на максимум по всей цепочке. Уверен, что это было правильное решение и с т.з. архитектурной прочности, и собственной психологической уверенности. Биллинг – это деньги, конфликты владения, повторная выдача прав. Тут нужна была щепотка паранойи. Но вот потом я его не вернул. Строго говоря, я не забыл, а попал в ловушку той самой психологической уверенности. Плюс спросил, и модель заверила меня, что такая глубина оправдана. Ну, возможно она в 9 из 10 так и скажет. У модели, оптимизирующей качество вывода, нет строки расходов под мой burn rate и нет представления о том, что подписка ревьюера упирается в лимит через час, и вместо релиза я сижу и жду сброса квоты. Поэтому давай, берсерк, закидывайся стимуляторами и жги. Что максимальный ризонинг купил мне на обычной, обратимой работе: — процедуру maintenance drain на staging-окружении, которым пользуется ровно один человек – я; — retry-механику такой основательности, что в одном тесте кнопку «Повторить» пришлось нажать семь раз, потому что безобидное событие blocked в IndexedDB трактовалось как фатальная ошибка; — итерации усиления runbook, каждая честно лучше предыдущей и ни одна из них не несущая. Правило, которое стоило написать в первый день: Максимальный ризонинг – для необратимого. Production-миграции, удаление данных, подписание релиза, финальный аудит. Всё обратимое – средний уровень и короткий цикл: реализация → тест → проверка. Неограниченные токены не делают мышление бесплатным. Они просто переносят его стоимость туда, куда ты не смотришь: в календарь, в лимиты и в терпение. Девять часов назад я отправил наконец Android-релиз PhotoMentor на проверку в Google Play. Жду.

Бенчмаркая CSE: подстава на uint — деление считается дважды

Уважаемые читатели, в этом посте я хочу разобраться, что компилятор делает с парой / и %, и представить свои выводы.

Возьмём число 47 и делитель 10. Деление даёт 4, остаток — 7. Компилятор деление не выполняет: он умножает 47 на подобранное число и сдвигает, получая 4. Дальше для остатка хватает вычитания: 47 − 4 × 10 = 7. Одно умножение на оба ответа.

Так на int. На uint компилятор получает 4, умножает на 10, вычитает — а потом заново считает те же 4 из 47, вторым умножением.

Ответ верный и там, и там. CSE, common subexpression elimination, находит повторяющиеся вычисления и считает их один раз. Оба умножения в паре считают одно и то же, и на int проход их склеивает. На uint не склеивает — отсюда и обращение в трекер.

int value = ints[i];
total += value / 10 + value % 10;    // одно умножение

uint value = uints[i];
total += value / 10 + value % 10;    // три умножения

Замер на 1 024 значениях, .NET 10, три машины. Значения положительные: у знакового деления отрицательные идут другой веткой.

Из таблицы можно сделать выводы:

• на int пара занимает столько же времени, сколько одно деление, на uint — вдвое больше;

• беззнаковое деление быстрее знакового в 1,54–1,60 раза: знаковому нужна коррекция для отрицательных значений;

• проседает не тип, а пара операций.

Вот как это выглядит в машинном коде, Xeon W-2255. У int одно умножение на всю пару:

mov      edx, 0xD1FFAB1E      ; подобранное число
imul     edx:eax, r9d         ; единственное умножение, вышло 4
sar      edx, 2               ; деление готово
lea      edx, [rax+4*rax]     ; 4 x 5
add      edx, edx             ; ещё x2, вышло 40
sub      r9d, edx             ; 47 - 40 = 7, остаток

У uint то же самое, но в конце деление идёт второй раз:

mov      r10d, 0xD1FFAB1E     ; то же число
imul     r10, r9              ; первое умножение, вышло 4
shr      r10, 35              ; деление готово
imul     r10d, r10d, 10       ; второе: 4 x 10 = 40
sub      r9d, r10d            ; 47 - 40 = 7, остаток
mov      r10d, 0xD1FFAB1E     ; снова оно
imul     r8, r10              ; третье: те же 4 заново
shr      r8, 35               ; и тот же сдвиг

Были проверены ещё три случая, разницы между int и uint в них нет. Делитель 16, степень двойки: деление сводится к сдвигу, остаток берётся из младших битов, умножений ноль у обоих. Делитель в переменной: работает машинная команда деления, она выдаёт оба ответа разом, 2 714 против 2 716 нс. Тип ulong: на .NET 8 и .NET 9 было три умножения, на .NET 10 осталось одно, а у uint три.

Что делать на практике:

• в горячих циклах вроде разбора числа по цифрам, форматирования и хэшей пара идёт на каждом витке, а с ней и лишнее умножение;

• Math.DivRem возвращает к одному умножению: быстрее пары в 1,13–1,76 раза. Внутри для uint то же вычитание:

// dotnet/runtime, Math.cs

public static (uint Quotient, uint Remainder) DivRem(uint left, uint right)
{
    uint quotient = left / right;
    return (quotient, left - (quotient * right));
}

• вычитание, записанное явно, value - value / 10 * 10, быстрее пары в 1,23–1,80 раза — для тех, кому не нужен кортеж из Math.DivRem;

• на int менять нечего: там деление с остатком уже собрано в одно умножение;

• лишнее умножение забирает часть того, что uint даёт на делении, но не всё: на разборе числа по цифрам он остаётся быстрее int — 0,81–0,86.

Проход описан в документации: Common Subexpression Elimination, код в optcse.cpp, реализация Math.DivRem — в Math.cs. Обращение открыто с августа 2025, help wanted: dotnet/runtime#119131. Замеры, отчёты и листинги: DivRemProof.

Всем удачи и до новых встреч!

От ядра Linux до дообучения языковых моделей: открытые вебинары недели

Как устроить обмен сообщениями между сервисами, найти причины сбоев в распределённой системе, превратить бизнес‑требования в понятные задачи или подготовить модель к работе в реальной среде?

С 3 по 6 августа эксперты OTUS проведут 24 бесплатных демо-урока по разработке, инфраструктуре, архитектуре, аналитике, машинному обучению и другим направлениям. Выбирайте интересующую область и присоединяйтесь.

Системное администрирование, сети и безопасность

• 3 августа, 20:00. «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться

• 3 августа, 20:00. «MPLS для корпоративных сетей: мифы, реальность и практика». Записаться

• 3 августа, 20:00. «Какие результаты должен давать DevSecOps‑проект бизнесу и команде». Записаться

• 4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

Разработка и программирование

• 3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

• 3 августа, 20:00. «Оживляем код: первые шаги в ООП на Python». Записаться

• 3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

• 4 августа, 20:00. «Многозадачность в Python: асинхронность, процессы, потоки». Записаться

• 4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться

• 5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться

• 5 августа, 20:00. «Как AI меняет работу C#‑разработчика». Записаться

Архитектура, системный и бизнес‑анализ

• 4 августа, 19:00. «Будущее корпоративного архитектора: навыки, тренды, технологии». Записаться

• 4 августа, 20:00. «Как аналитику работать с рисками». Записаться

• 5 августа, 20:00. «Влияние нефункциональных требований на архитектуру». Записаться

• 5 августа, 20:00. «MVP глазами бизнес‑аналитика: от идеи до первых функций». Записаться

• 6 августа, 20:00. «Пользовательские сценарии на реальном примере: от бизнес‑требования заказчика до формулирования задачи для разработчика». Записаться

Машинное обучение и работа с данными

• 4 августа, 20:00. «PostgreSQL как память ИИ‑агентов: MVCC, очереди и партиции под нагрузкой». Записаться

• 5 августа, 20:00. «Сделайте модель своей: дообучение LLM методом QLoRA без кода». Записаться

• 6 августа, 18:00. «Практика работы с Docker — ввод модели в эксплуатацию». Записаться

• 6 августа, 20:00. «Базовая структура ML: задачи, pipeline, метрики и функции потерь». Записаться

Битрикс24

• 3 августа, 20:00. «Кастомизация компонентов в Битрикс24». Записаться

• 4 августа, 19:00. «Эффективная работа с диском Битрикс24». Записаться

Управление проектами

• 5 августа, 20:00. «Оценка проекта: от интуитивных догадок к системному подходу». Записаться

Тестирование игр

• 4 августа, 20:00. «Как стать тестировщиком игр: первый шаг в GameDev». Записаться

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

Добавил "галерею фишек" и документацию для акбуры, разумеется галерею написал на самом кастомном dsl

• Репозиторий

• Документация

• Галерея

Где бэкенд начинает тормозить: 18 открытых уроков по языкам, данным и архитектуре

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

В августе и сентябре преподаватели OTUS проведут бесплатные уроки для бэкенд‑разработчиков. В программе — Python, Go, C# и JVM, микросервисная архитектура, PostgreSQL, брокеры сообщений, наблюдаемость и контейнеризация. Выбирайте свою тему и присоединяйтесь к практическим разборам.

Архитектура и взаимодействие сервисов

• 3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

• 4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться

• 12 августа, 20:00. «Паттерны отказоустойчивости и масштабируемости микросервисной архитектуры». Записаться

• 13 августа, 20:00. «Управление данными в MSA — дыра в бюджете или актив для ИИ-трансформации?». Записаться

• 19 августа, 20:00. «Монолит или микросервисы? Руководство для архитекторов, которые ценят свои нервы». Записаться

• 24 августа, 20:00. «Основные шаблоны проектирования в системном дизайне». Записаться

Языки, память и конкурентность

• 3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

• 4 августа, 20:00. «Многозадачность в Python. Асинхронность, процессы, потоки». Записаться

• 5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться

• 18 августа, 20:00. «Python asyncio: gather, wait, TaskGroup на практике». Записаться

• 18 августа, 20:00. «Горутины и каналы: базовые принципы параллелизма в Go». Записаться

• 18 августа, 20:00. «Архитектурные ошибки, которые совершают даже опытные C#-разработчики». Записаться

Базы данных и работа с состоянием

• 11 августа, 20:00. «Работа с SQLAlchemy и Alembic в FastAPI». Записаться

• 19 августа, 20:00. «PostgreSQL на стероидах: большие данные, высокие нагрузки и масштабирование без боли». Записаться

• 1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться

• 16 сентября, 20:00. «Темпоральные данные в PostgreSQL 18: история и версии без триггеров». Записаться

Наблюдаемость и контейнеризация

• 4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

• 20 августа, 20:00. «Docker для Python-разработчика». Записаться

Что почитать перед практикой

1. Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт
   _{Путь от чтения RFC и реализации обработчика запросов до запуска сервера в контейнере. Внутри — защита исполняемого файла, ограничения для HTTP/2, работа с облачными площадками и поиск утечки памяти в OpenSSL.}

2. std::expected в C++23: гайд по миграции с исключений на функциональный error handling
   _{Как сделать ошибку явной частью сигнатуры функции, выстраивать цепочки операций и постепенно внедрять std::expected в существующий проект.}

3. Move-семантика в C++: пять задач, в которых легко ошибиться
   _{Разбор ловушек, которые успешно компилируются, но приводят к лишним копированиям, замедлению программы или неопределённому поведению.}

4. Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод
   _{План обновления рабочего сервиса с промежуточными этапами, автоматизированными проверками, канареечным развёртыванием и заранее подготовленным сценарием отката.}

Сначала хотел написать комментарий к этой статье, но потом подумал, что пост лучше.

Наверно, просто каждый язык предназначен для решения своего круга задач. Когда‑то фортран был языком для вычислений. Паскаль — для обучения. Си — для системных разработок. А вот Бейсик (я про компилируемые варианты) был универсален.:) Оттого, наверно, я его и выбрал в начале 90-х. Хотя с тех пор от него ничего не осталось, даже в плане синтаксиса, не говоря про огромные возможности...

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

Раньше я использовал VB3, но он на новых системах не работает. Потом «открыл для себя» SmallBasic и даже написал по нему некое пособие. Язык хороший, реально! Но есть один огромный минус, в силу чего он не годился для искомой роли: не работает с двоичными файлами.

Свой собственный язык («Ellochka») я так и не удосужился до сих пор перевести под Виндовс (остался интерпретатор для ДОС).

Питон, увы, тоже не подходит: язык не очень прост, а главное — среда огромная, с флешки запускать несерьезно (а надо).

Так вот и вопрос: есть сейчас язык, подходящий для описанной задачи? Простой, легкий (в мегабайтах), без лишних наворотов, но «все что нужно есть»? Может, кто подскажет?

Мультиагентность — эффективный подход или просто красивый фантик?

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

Вопрос закономерный: оправдано ли это?

У нас есть приём, обычно зашитый прямо в claude.md: никакого «сам написал — сам и проверил».

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

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

1. Полнота — покрыты все места вызова, а не одно.

2. Нерегрессия — не сломаны ли смежные пути.

3. Тесты — есть ли проверка на изменение и проходит ли.

4. Скрытые баги — edge-кейсы, null, гонки, ошибки внешних сервисов.

5. Слои — не уехала ли логика не туда.

6. Секреты — не утекли ли ключи в код или логи.

Ключевое: аудитору не показывают авторскую версию событий — он судит по коду, а не по рассказу о нём. Нашёл проблему — возвращает автору; чинит автор, аудитор перепроверяет.

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

Аудитом дело не ограничивается. Та же логика — когда нужно независимое мнение на архитектурной развилке или когда объёмную побочную задачу (длинный лог, незнакомая библиотека) уводишь в отдельную сессию, чтоб не сорить в основном контексте. Словом, субагент хорош там, где отдельный контекст или свежий взгляд дают то, чего одна сессия не может.

Даже там, где субагент оправдан, не обязательно брать самую сильную модель. Механические проверки из чек-листа — не утёк ли ключ, есть ли тест, не уехал ли слой — прекрасно закрывает Sonnet: вопрос узкий, ответ проверяемый. А поймать то, чего не заметил автор, — гонку, хитрый edge-кейс, неочевидное архитектурное последствие — лучше попросить Opus: чтобы увидеть то, что упустил умный, нужен как минимум не менее умный. Дешёвой модели при этом ставим планку приёма: уверена — принимаем, сомневается — поднимает флаг и отдаёт выше.

Отсюда и ответ: мультиагентность — не фантик тогда, когда второго агента поднимают не «чтобы было», а там, где его независимость работает на результат. Иначе — красивая обёртка, а под ней, как водится, пусто.

Продолжение постов один и два

Выберите, что прокачать: открытые уроки для IT-специалистов на неделю

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

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

Инфраструктура, DevOps и безопасность

• 27 июля в 20:00 — «K8S + Vault — как получать секреты?». Записаться

• 27 июля в 20:00 — «Использование GitLab CI для работы с Ansible». Записаться

• 30 июля в 20:00 — «Восстанавливаем RAID5 в Linux». Записаться

• 3 августа в 20:00 — «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться

• 3 августа в 20:00 — «MPLS для корпоративных сетей: мифы, реальность и практика». Записаться

• 3 августа в 20:00 — «Какие результаты должен давать DevSecOps-проект бизнесу и команде». Записаться

Разработка

• 27 июля в 20:00 — «Разработка Embedded-устройств для IoT». Записаться

• 28 июля в 20:00 — «Что Golang даёт индустрии и что он может дать вам». Записаться

• 29 июля в 20:00 — «Собери себя сам: пишем трекер привычек на чистом JavaScript». Записаться

• 3 августа в 20:00 — «Оживляем код: первые шаги в ООП на Python». Записаться

• 3 августа в 20:00 — «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

AI и мультимодальные технологии

• 28 июля в 20:00 — «Стирание границ: нативная интеграция ASR, TTS и NLP в эпоху мультимодальных LLM». Записаться

Тестирование и развитие карьеры

• 30 июля в 20:00 — «API- и UI-тестирование с Playwright на Python». Записаться

• 30 июля в 20:00 — «Прохождение собеседования на нагрузочного тестировщика. Что интересует работодателя?». Записаться

Архитектура, корпоративные системы и интеграции

• 30 июля в 20:00 — «Функциональный архитектор 1С: как перестать быть „переводчиком требований“ и начать управлять системой». Записаться

• 3 августа в 20:00 — «Кастомизация компонентов в Битрикс24». Записаться

• 3 августа в 20:00 — «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

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

Это поможет точечно закрыть пробел и увереннее применять новые знания в работе.

Больше открытых уроков июля смотрите в дайджесте.

Slopsquatting: ИИ в тандеме со злоумышленником

Интересно смотреть, как ИИ меняет разные сферы - и кибербезу тоже досталось. Недавно наткнулся на термин slopsquatting и удивился: он живёт уже больше года, просто прошёл мимо меня - придумал его в 2025 Сет Ларсон из Python Software Foundation. Разбираемся, что это и почему это не страшилка ради красивых заголовков.

Начнём издалека - с более старого трюка, typosquatting (опечатка + захват). Атакующий регистрирует в PyPI, npm или другом репозитории пакет с именем, почти неотличимым от популярного - на одну букву, на дефис, на порядок слов. Классика: в декабре 2019 в PyPI нашли jeIlyfish - настоящий jellyfish, только строчная l заменена на заглавную I, визуально похожую в большинстве шрифтов. Пакет воровал SSH- и GPG-ключи. Рядом ехал python3-dateutil под python-dateutil; в npm похожая история - crossenv вместо cross-env (2017).

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

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

Slopsquatting - тот же трюк с апгрейдом под эпоху AI-кодинга. Когда LLM пишет вам код, она время от времени советует import библиотеки или pip install, которой на самом деле не существует - модель её выдумала, потому что название звучит правдоподобно.

Раньше на это смотрели как на безобидный баг: заметишь, попросишь исправить, и всё. Но в 2025-м исследователи UTSA опубликовали работу на USENIX Security: 16 моделей, 576 тыс. сэмплов на Python и JS. Результат - 19,7% рекомендованных пакетов не существовало.

Результаты правда относятся к моделям предыдущего поколения, актуальных метрик пока нет. Но нам интересно другое: 500 галлюцинирующих промптов прогнали по десять раз каждый. 43% выдуманных имён повторялись во всех десяти прогонах, ещё 58% - больше одного раза. Список фейковых имён воспроизводимый, а не случайный.

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

Это не теория. В 2024-м Бар Ланьядо из Lasso Security зарегистрировал пакет-пустышку huggingface-cli, который модели упорно советовали. За три месяца - больше 15 тысяч загрузок, а pip install huggingface-cli заехал в README репозитория Alibaba GraphTranslator. Никакого взлома - люди просто ставили то, что продиктовал ИИ.

Второй случай свежее и неприятнее: в январе 2026-го Чарли Эриксен (Aikido Security) заметил, что LLM склеила jscodeshift и react-codemod в несуществующий react-codeshift. Имя попало в коммит с 47 сгенерированными Agent Skills и через форки разошлось по 237 репозиториям - никто не вычитывал. Эриксен зарегистрировал пакет превентивно и сразу увидел загрузки. По его словам, вектором атаки это не стало только потому, что он успел первым.

Почему это стало проблемой именно сейчас:

• AI-агенты стали привычным способом писать рутинный код, и вопрос «а точно ли существует эта библиотека?» многие перестали задавать в принципе;

• галлюцинации разных моделей пересекаются - есть 127 имён пакетов (109 в PyPI, 18 в npm), которые независимо выдумывают сразу несколько ведущих моделей. Один зарегистрированный пакет ловит пользователей всех сразу;

• репозитории пакетов по-прежнему пускают регистрировать что угодно и от кого угодно, никак не проверяя, зачем вам это имя.

Короче: slopsquatting - история про то, как одна безобидная особенность модели превращается в готовый вектор атаки. Старый как мир supply-chain риск получил новый, куда более дешёвый вход.

Пользуясь случаем, пришлашаю в мой Telegram-канал.

Чудный маразм прислали мне вчера под видом трудового договора...

Речь о заказной разработке/развитии кастомной CRM с замашкой на ERP, но это не суть важно. Оцените, как гритца, масштаб разрушений:

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

Надеюсь, он обязательно найдет себе согласного...

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

С момента написания прошлой статьи про мою самописную товароучетную систему для работы с маркировкой «Честный Знак», я добавил новых фич и поправил существующие ошибки. Основные изменения следующие:

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

2. Добавлен вид документа в продаже: поле «Вид док-та» в шапке заказа (Прочее, УПД, Товарная накладная, Акт приёма-передачи, Кассовый чек).

3. Появилась кнопка «Скачать КМ в CSV» в корзине Продаж для скачивания КМ в формате «для ввода/вывода из оборота» для вставке в ЭДО при передаче УПД.

4. Дропдаун «Статус» теперь показывает статус ЧЗ для проданных товаров.

5. Появилась возможность выделить и произвести массовую проверку статуса ЧЗ для выделенных товаров (чекбоксы + кнопка) на вкладках Остатки, Продано, Вывод из оборота.

6. Появилась колонка «Статус в ЧЗ» в таблицах Остатки и Вывод из оборота

7. Сделано автоподтверждение отчёта о выбытии при статусе ЧЗ равном «Выбыл» (RETIRED/WITHDRAWN/WRITTEN_OFF)

8. Сделано сохранение активной вкладки при перезагрузке страницы

9. Введена новая логика быстрой продажи: в шапку заказа: номер заказа, склад списания, дата продажи, добавление нескольких товаров по КМ/артикулу/EAN-13 с ценой за позицию в корзину с одинаковым номером заказа, КМ для Маркетплейсов отображается в корзине и копируется кликом, сделан Live-поиск при вводе кода с полной информацией о товаре.

ПО я писал для своей товарной группы «Игры и игрушки», но оно должно подходить и для других товарных групп потребительских товаров.

Сразу напишу про API: авторизация по ЭЦП и получение общего статуса по КМ все еще ведется по 3 версии API Честного Знака, как и например работа с МОД, а что-то уже работает только по 4 версии API (например ввод-вывод из оборота).