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

Новые технологии без лишнего шума: что будем разбирать на вебинарах на этой неделе

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

На бесплатных демо-уроках этой недели разберём современные подходы на практике: посмотрим, как работают ИИ‑агенты, ML‑модели, базы данных, архитектурные решения, инструменты разработки и подходы к управлению командами. Выбирайте нужную тему и присоединяйтесь:

ИИ и машинное обучение

• 14 сентября, 20:00. «AI‑агенты против Junior‑разработчиков: кто кого заменит к концу 2026 года». Записаться.

• 15 сентября, 20:00. «Настройка виртуального окружения — уверенный старт в мире Python и ML». Записаться.

• 16 сентября, 18:00. «Задача классификации от 0 до 9». Записаться.

• 17 сентября, 18:00. «Создаём ИИ‑ассистента для системного аналитика за 1 час». Записаться.

• 17 сентября, 20:00. «Обзор ИИ‑технологий для разработчиков. От идей до рабочих решений». Записаться.

Разработка и архитектура

• 17 сентября, 20:00. «RabbitMQ в Production: Transactional Outbox, идемпотентность и DLQ в ASP.NET Core». Записаться.

• 17 сентября, 20:00. «Создаём первое приложение на Vue 3 с Composition API». Записаться.

Данные и базы данных

• 15 сентября, 20:00. «Моделирование данных для DWH». Записаться.

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

Аналитика и бизнес‑процессы

• 15 сентября, 20:00. «Как аналитик 1С ведет задачу от интервью до приемки: сквозной кейс интеграции с мобильным рабочим местом». Записаться.

• 17 сентября, 20:00. «Событийные подпроцессы в BPMN 2.0: как моделировать процессы, реагирующие на события». Записаться.

• 17 сентября, 20:00. «Управление релизами в 1С: GitFlow, code review и CI/CD на практике». Записаться.

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

• 14 сентября, 19:00. «Анти‑паттерны управления: Почему "помощь" заказчиков убивает проекты и как вернуть контроль». Записаться.

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

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

Инфраструктура

• 17 сентября, 20:00. «Где Linux хранит настройки и логи: разбираем файловую структуру на практике». Записаться.

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

А полный список бесплатных уроков сентября можно посмотреть в дайджесте.

Все видеозаписи конференции EuroPython 2026, проходившей в Кракове (Польша) с 13 по 19 июля 2026 года, теперь доступны онлайн для всех пользователей (включая фото). Также опубликован краткий обзор мероприятия от организаторов.

Летний ТехФест 2026: главные итоги

Мы объехали офисы партнёров, встретились с коллегами и обсудили самое актуальное: AI в разработке, продуктовые циклы, управление изменениями и не только. На практических сессиях разбирали реальные кейсы, а на дискуссиях искали ответы на сложные вопросы.

Собрали цифры нашего фестиваля, чтобы показать масштаб:

• 5 площадок

• 5 компаний организаторов

• Более 600 участников

• 10 докладов от экспертов отрасли

• 3 активности — мастермайнд, круглый стол и практикум с живыми кейсами

• 12 экспертов и спикеров

• 5 кейсов решено на практикуме по инженерной оптимизации.

Отдельное спасибо организаторам — вы сделали эту неделю незабываемой. Увидимся в следующем году!

Финальный день: как это было.

Ещё больше о мероприятиях — в нашем TG-канале.

Зачем мы интегрируем свой анализатор в такое количество инструментов?

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

За не самым красивым оборотом “тому подобное” мы обычно скрываем наши многочисленные интеграции со сторонними продуктами (плагины, расширения, сценарии работы). Вы можете спросить: “А зачем скрывать?” Смотрите сами: первой нашей интеграцией был плагин для Visual Studio 2005, вышедший 18 лет назад. Сегодня же анализатор интегрируется с более чем тремя десятками других инструментов для разработки: плагины для IDE, игровые движки, платформы контроля качества кода, сборочные системы, платформы CI/CD и т. п.

Поддерживать всё это в актуальном и рабочем состоянии — большая работа, и в новой статье расскажем, зачем мы вообще этим занимаемся.

18 открытых уроков недели: изучаем ML, LLM, PostgreSQL, Go и DevOps на практике

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

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

На этой неделе разбираем машинное обучение, искусственный интеллект, PostgreSQL, Linux, Go, Rust, DevOps, разработку под iOS и управленческие задачи технических специалистов.

AI и машинное обучение

• 7 сентября, 18:00. «Учимся готовить данные для ML‑моделей». Записаться
  _{Разберём подготовку данных перед обучением моделей.}

• 7 сентября, 20:00. «Почему 90% ML‑проектов не доходят до продакшена? Разбираем архитектуру настоящей ML‑системы». Записаться
  _{Поговорим о компонентах и рисках ML‑систем в production.}

• 8 сентября, 20:00. «Что надо знать про работу LLM моделей». Записаться
  _{Разберём принципы работы больших языковых моделей.}

• 8 сентября, 20:00. «ИИ против бага: как разобрать инцидент в Python‑проекте от логов до исправления». Записаться
  _{Посмотрим, как применять ИИ при поиске и исправлении ошибок.}

• 9 сентября, 18:00. «Оптимизируем построение модели через Pipeline». Записаться
  _{Разберём сборку и настройку ML Pipeline.}

• 10 сентября, 18:00. «Подготовка данных в Pandas». Записаться
  _{Поработаем с обработкой данных для ML‑задач.}

Базы данных и разработка

• 8 сентября, 20:00. «Борьба с блокировками в PostgreSQL: как достичь высокой параллельности при большой нагрузке». Записаться
  _{Разберём проблемы блокировок и способы повышения производительности.}

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

• 9 сентября, 20:00. «Go‑профилирование: как найти и исправить „тормоза“ в продакшене». Записаться
  _{Найдём причины проблем с производительностью Go‑приложений.}

• 9 сентября, 20:00. «Владение, заимствование и ссылки в Rust: как компилятор делает ваш код безопасным». Записаться
  _{Разберём ключевые механизмы безопасности Rust.}

• 9 сентября, 20:00. «Что надеть сегодня? Создаём погодного помощника для iPhone на SwiftUI». Записаться
  _{Создадим приложение с погодным помощником на SwiftUI.}

Linux, DevOps и инфраструктура

• 7 сентября, 20:00. «Linux для Windows‑администратора за 60 минут». Записаться
  _{Познакомимся с основными возможностями Linux для администраторов.}

• 8 сентября, 20:00. «LVM без простоя: расширение тома, перенос данных и аварийный откат через snapshot». Записаться
  _{Разберём управление хранилищем без остановки системы.}

• 10 сентября, 20:00. «Настройка GitLab Runners». Записаться
  _{Настроим инструменты для автоматизации CI/CD.}

Аналитика и управление

• 8 сентября, 20:00. «Системный аналитик и его ценность глазами компании». Записаться
  _{Разберём роль аналитика в бизнес‑процессах.}

• 8 сентября, 20:00. «От технического лидера к CTO: как начать принимать решения на уровне бизнеса». Записаться
  _{Поговорим о переходе от инженерных задач к управлению.}

• 9 сентября, 20:00. «Как тимлиду распределять ответственность и не становиться узким местом команды». Записаться
  _{Разберём управление ответственностью внутри команды.}

1С и автоматизация тестирования

• 8 сентября, 19:00. «Автотесты 1С через ИИ: от запуска до контроля результата». Записаться
  Посмотрим, как использовать ИИ в автоматизации тестирования 1С.

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

До встречи на занятиях!

Еще больше бесплатных уроков сентября смотрите в дайджесте.

Статья “Почему разработчики продолжают писать код руками?” была плохо воспринята аудиторией. На всех площадках были только отрицательные комментарии. Все были убеждены, что весь код нужно писать руками. Каждую строчку кода.

Я удивлён этому, потому что я действительно считал, что многие разработчики используют ИИ агентов для написания кода. Реальность оказалась другой.

Программисты не готовы потерять свою идентичность. Написание кода для них это в какой-то степени искусство.

AI-агенты уже пишут код. Какие навыки разработчика останутся ценными через 3 года?

Согласно исследованию Stack Overflow Developer Survey, 84% разработчиков уже используют или планируют использовать ИИ-инструменты в процессе работы. При этом доверие к результатам работы искусственного интеллекта остается неоднозначным: многие инженеры отмечают, что готовы использовать такие инструменты, но всё равно проверяют их решения.

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

Поэтому вопрос «заменят ли AI-агенты программистов» постепенно меняется на другой: какие навыки будут отличать инженера, который эффективно работает с агентами, от инженера, который конкурирует с ними в тех задачах, где автоматизация уже становится реальностью?

На бесплатном уроке 14 сентября в 20:00 разберём, что современные AI-агенты уже умеют делать в разработке, где они пока ошибаются и как использовать их как инструмент для усиления своей работы. Присоединяйтесь.

Занятие проведёт преподаватель-практик курса «ИИ-агенты: продвинутое внедрение и использование» Анастасия Третьякова.

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

Если вы знакомы с ISA-L, Jerasure, Leopard-RS, klauspost/reed-solomon, то полагаю пояснений к картинке выше не нужно, вот ссылка -- забирайте.

Ну а теперь некоторые пояснения: выше перечислены известные библиотеки, реализующие коды Рида-Соломона под CPU для задачи стирания, т.е. у вас есть блоков, вы к ним добавляете еще блоков и получаете право потерять любые блоков из, РС код позволит восстановить потерянное. РС код состоит из нескольких рутин с многочленами, реализация за -- уровень сложного практического задания на курсе по вычислительной алгебре. В теории еще с 80-х годов было подозрение, что эти рутины можно полностью сделать на основе FFT, получить вычислительную сложность хотя бы и быстрый алгоритм на его основе. На практике с этим было много проблем, первая и по большому счету единственная практическая реализация со сложностью появилась в 2016 году в Leopard-RS на основе работы Лина-Чуна-Хана и соответствующего FFT-подобного преобразования (LCH transform). В этом году вышел обновленный алгоритм от авторов исходного подхода с улучшенным декодером, реализация доступна тут. Моя роль тут инженерная: я скрестил Leopard с XDRS, добавил GFNI, отполировал интерфейс и получил

• Совместимый с Leopard РС код с произвольными параметрами (Leopard только поддерживает только , у XDRS параметры должны быть степенями двойки)

• Выделенные интерфейсы для LCH преобразования и затьюненные вычислительные ядра под AVX2 и GFNI

• Ускорение по сравнению и с Leopard, и с XDRS

• Единый воспроизводимый бенчмарк

Спасибо за внимание

Четвёртый день Летнего ТехФеста — в нашем влоге

Мы встретились в пространстве Garage Eight, чтобы поговорить об AI для работы. Доклады, живые дискуссии и тёплая атмосфера — всё это мы засняли для тебя.

Смотри видео, чтобы погрузиться в событие!

Ещё больше о мероприятиях — в нашем TG-канале.

Насколько хорошо вы знаете свой основной стек?

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

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

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

Можно оценить знания по направлениям:

— Java: язык, JVM, коллекции, многопоточность и практики разработки;
— Go: особенности языка, конкурентность, работа с памятью и создание сервисов;
— C# и ASP.NET: платформа .NET, веб-разработка и ключевые инструменты экосистемы;
— Rust: владение памятью, система типов и особенности безопасной разработки.

Пройдите вступительный тест и получите ориентир, какие темы стоит изучить дальше.

Java Professional •• Go Developer Professional •• ASP.NET •• Rust Developer

>> тесты по другим направлениям

15 бесплатных уроков для тех, кто работает с искусственным интеллектом

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

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

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

LLM и генеративный ИИ

• 3 сентября, 20:00. «Локальные LLM модели для разработки». Записаться

• 8 сентября, 20:00. «Что надо знать про работу LLM моделей». Записаться

• 23 сентября, 18:00. «Structured Outputs: как заставить LLM всегда возвращать то, что вам нужно». Записаться

ИИ‑агенты и искусственный интеллект в разработке

• 14 сентября, 20:00. «ИИ‑агенты против Junior‑разработчиков: кто кого заменит к концу 2026 года». Записаться

• 17 сентября, 20:00. «Обзор ИИ‑технологий для разработчиков. От идей до рабочих решений». Записаться

• 1 октября, 20:00. «Продуктивность разработчика и Agent Skills». Записаться

ML и работа с данными

• 7 сентября, 18:00. «Учимся готовить данные для ML‑моделей». Записаться

• 9 сентября, 18:00. «Оптимизируем построение модели через Pipeline». Записаться

• 10 сентября, 18:00. «Подготовка данных в Pandas». Записаться

• 16 сентября, 18:00. «Задача классификации от 0 до 9». Записаться

• 23 сентября, 18:00. «Дерево решений — простой и интерпретируемый ML‑алгоритм». Записаться

Практическое применение ИИ

• 7 сентября, 20:00. «Почему 90% ML‑проектов не доходят до продакшена? Разбираем архитектуру настоящей ML‑системы». Записаться

• 8 сентября, 20:00. «ИИ против бага: как разобрать инцидент в Python‑проекте от логов до исправления». Записаться

• 21 сентября, 20:00. «Как руководителю внедрить ИИ в работу команды: от выбора процесса до рабочего сценария». Записаться

• 22 сентября, 20:00. «Можно ли доверять ИИ‑коду: как находить галлюцинации, уязвимости и устаревшие решения». Записаться

📚 Что почитать по теме

1. «Промпт, RAG или дообучение: что реально выучит вашу LLM»

2. «Автоматизация процессов на open source — n8n и Ollama»

3. «Как запустить LLM на 2,8 трлн параметров на ноутбуке»

4. «Три месяца с Claude: хороший ассистент, плохой программист»

5. «Как создать своего первого ИИ‑агента за 30 минут»

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

Все бесплатные уроки сентября собрали в дайджесте.

PostgreSQL 18, локальные LLM, ClickHouse и Playwright: что разобрать на этой неделе

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

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

В посте собрали бесплатные уроки этой недели по PostgreSQL 18, ClickHouse, локальным LLM, Playwright, Linux, ML‑системам и другим темам. Можно выбрать направление под текущую задачу и посмотреть, как с ним работают на практике.

AI, ML и автоматизация

• 31 августа, 20:00. «Построение программ без кода: создание умного помощника и автоматизаций в n8n». Записаться
  _{Соберём AI‑помощника и автоматизации без кода.}

• 1 сентября, 20:00. «Практическое применение нейросетей для моделирования процессов». Записаться
  _{Разберём нейросети для работы с бизнес‑процессами.}

• 3 сентября, 20:00. «Как руководителю внедрить ИИ в работу команды: от выбора процесса до рабочего сценария». Записаться
  _{Пройдём путь от идеи до рабочего AI‑сценария.}

• 3 сентября, 20:00. «Локальные LLM‑модели для разработки». Записаться
  _{Разберём запуск и применение локальных LLM.}

• 7 сентября, 18:00. «Учимся готовить данные для ML‑моделей». Записаться
  _{Подготовим данные к обучению ML‑моделей.}

• 7 сентября, 20:00. «Почему 90% ML‑проектов не доходят до продакшена? Разбираем архитектуру настоящей ML‑системы». Записаться
  _{Разберём архитектуру production‑ready ML‑системы.}

Базы данных и бэкенд

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

• 3 сентября, 20:00. «Векторный поиск в ClickHouse». Записаться
  _{Разберём возможности векторного поиска в ClickHouse.}

• 3 сентября, 20:00. «ASP.NET Core API под нагрузкой: как сделать сервис устойчивым к сбоям и росту трафика». Записаться
  _{Поговорим об устойчивости API под нагрузкой.}

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

• 2 сентября, 20:00. «ИИ для тестировщика: инструменты, которые уже меняют профессию». Записаться
  _{Посмотрим на AI‑инструменты для задач тестирования.}

• 3 сентября, 20:00. «UI и API‑тестирование с Java и Playwright». Записаться
  _{Разберём автоматизацию UI‑ и API‑тестов.}

Linux и системное программирование

• 3 сентября, 19:00. «Первый веб‑сервер на Linux: Nginx, Apache и проверка доступности». Записаться
  _{Поднимем и проверим первый веб‑сервер на Linux.}

• 7 сентября, 20:00. «Linux для Windows‑администратора за 60 минут». Записаться
  _{Разберём базовые инструменты Linux через знакомые аналогии.}

• 7 сентября, 20:00. «Работа с памятью на языке C». Записаться
  _{Поговорим об указателях и управлении памятью.}

1С и бизнес‑анализ

• 2 сентября, 20:00. «Как аналитику выбрать решение 1С для автоматизации казначейства: сравниваем 1С:ERP, 1С:УХ и 1С:ERP.УХ». Записаться
  _{Сравним решения 1С для автоматизации казначейства.}

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

Все ближайшие открытые уроки собраны на одной странице в дайджесте.

Вайбкодинг — довольно популярное в наше время занятие, которое пагубно сказывается на все программистическое комьюнити. Мало того, что всё наполняется нейрослопом от новоиспеченных «программистов» с подпиской Claude за 20$, так еще и старички разучиваются писать код без использования ИИ ввиду его использования.

Масло в огонь подливает ЛИНУС ТОРВАЛЬДС (создатель линукса) который недавно ляпнул что «ИИ — хороший инструмент»; эту фразу теперь используют вайбкодеры чтобы оправдать то, что они пишут код с использованием ИИ.

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

Некоторые говорят что они «используют ИИ иногда, когда проблемы возникают»... Программирование — это РЕШЕНИЕ ПРОБЛЕМ, когда нейросеть за вас эти самые проблемы решает, вы уже не программист, а обычный вайбкодер.

Вообщем, вы видите к чему все идет: у людей навыки программирования атрофируются от использования ИИ, новые разработчики — вайбкодеры; нормальных людей, что способны писать код самостоятельно — скоро совсем не останется. Это прискорбно.

1. Неопытный вайбкодер может создать приложение, где все пароли пользователей хранятся в открытом виде.

2. Неопытный пользователь может использовать один и тот же пароль на всех сервисах и не использовать двухфакторную авторизацию.

3. Неопытный хакер с помощью ИИ находит уязвимость в приложении и получает доступ к базе данных.

4. Пароль из базы даёт ему доступ ко всем сервисам, на которых зарегистрирован пользователь.

Эта проблема существовала всегда.

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

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

Хороший код: как понять, что его будет удобно менять

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

Вместе с Ринатом, iOS-разработчиком в Naumen, разбираемся, почему хороший код проверяется следующей задачей, как проявляется сложность изменений и на что стоит смотреть при оценке кода.

Код проверяется следующей задачей

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

Так что даже не самое удачное решение какое‑то время не доставляет особых проблем.

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

Именно в этот момент становится понятно, насколько код вообще рассчитан на изменения.

Простая задача может оказаться дорогой

Одна из задач у нас на планировании звучала безобидно:

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

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

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

Смотреть нужно на изменение, а не на файл

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

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

Файл может выглядеть вполне нормально, а изменение при этом оказывается дорогим.

Мне в этом контексте близко описание сложности изменений у Джона Оустерхаута. Он выделяет три характерных проявления.

• Маленькая правка расползается по системе

Добавили поле в модель и приходится менять сетевой слой, хранилище, аналитику, несколько экранов и тестовые данные.

Иногда это естественная цена изменения контракта, а иногда — признак того, что одно знание размазано по проекту.

• Для локальной работы нужно слишком много контекста

Чтобы поправить один обработчик, нужно знать устройство навигации, жизненный цикл экрана, особенности кэша и два исторических обхода старых ошибок.

• Есть зависимости, о которых разработчик даже не знает

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

Эти признаки полезнее многих разговоров о «чистом коде»: о длине метода можно спорить, а вот с последствиями изменения — сложнее.

Обычно я смотрю на три вещи

1. Сколько мест потребуется затронуть?

2. Сколько информации нужно восстановить перед работой?

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

Чем меньше ответ зависит от памяти конкретного человека, тем спокойнее живется проекту.

Мы кое-что спрятали 👀

В честь выхода PVS-Studio 8.0 — а это поддержка новых языков и серьёзные улучшения анализатора — мы решили устроить небольшую охоту.

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

Первые 10 человек, которые найдут спрятанные нами пасхалки и напишут нам, получат две бумажные книги по C++ в подарок. Не забудьте указать в сообщении, где вы отыскали нашу пасхалку.

Как искать? Просто! Скачивайте PVS-Studio, анализируйте свой код — и, возможно, найдёте кое-что интересное по дороге.

👉 Подробные условия и как забрать приз — здесь

В Bot API 10.3 появилась остановка генерации. Но LLM-запрос придётся отменять самому

24 августа вышел Telegram Bot API 10.3. В нём появилась полезная функция для AI-ботов: пользователь может остановить генерацию ответа штатной кнопкой Telegram.

В методы sendMessageDraft и sendRichMessageDraft, которые позволяют показывать черновик ответа в личном чате, добавили два параметра:

• can_stop=True — показывает кнопку остановки;

• keep_on_stop=True — временно оставляет уже сгенерированную часть ответа в чате.

Когда пользователь нажимает кнопку, бот получает обновление stopped_message_generation. В нём есть chat, message_thread_id и draft_id, поэтому событие можно связать с конкретной генерацией.

Если вы явно задаёте allowed_updates, новый тип обновления нужно добавить туда. Иначе нажатие кнопки просто не попадёт в обработчик.

Но Telegram останавливает только показ черновика. Запрос к LLM на стороне бота продолжит выполняться, пока разработчик сам его не отменит.

Например, можно хранить задачи по ключу из идентификаторов чата, темы и черновика:

key = (chat_id, message_thread_id, draft_id)

active_generations[key] = asyncio.create_task(
    generate_answer()
)

При получении stopped_message_generation находим задачу и отменяем её:

event = update.stopped_message_generation
key = (event.chat.id, event.message_thread_id, event.draft_id)

task = active_generations.pop(key, None)

if task is not None:
    task.cancel()

    try:
        await task
    except asyncio.CancelledError:
        pass

Это упрощённый пример: конкретный обработчик зависит от используемого фреймворка.

Одного task.cancel() тоже не всегда достаточно. Отмена в asyncio кооперативная: задача остановится только тогда, когда управление вернётся в event loop. Если внутри работает синхронный код или отдельный поток, он может продолжить работу.

Нужно также закрыть потоковое HTTP-соединение с провайдером модели. А если провайдер поддерживает отдельный API отмены, вызвать и его. Иначе модель может продолжить генерацию — вместе с расходом токенов — даже после закрытия соединения.

По сути, здесь есть три независимых действия:

• Telegram прекращает показывать черновик;

• бэкенд отменяет локальную задачу и закрывает соединение;

• провайдер модели останавливает генерацию, если умеет это делать.

Ещё один нюанс касается keep_on_stop=True. Остановленный черновик не превращается в обычное сообщение. Он исчезнет после следующего сообщения в чате или примерно через 30 секунд.

Если частичный ответ нужно сохранить, его придётся отдельно отправить через sendMessage или sendRichMessage.

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

Telegram добавил удобный интерфейс, но жизненный цикл генерации всё равно остаётся на стороне разработчика.

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

Я создала красивый GUI для Qemu для запуска древних MacOS начиная с версии 9.0 до 10.5 Leopard. Для удобной эмуляции для простых пользователей ПК. Доступен для всех Linux, в том числе Raspberry Pi, chromeOS, SteamDeck и Steam Machine. Программа создана на Qt6 и C++, из-за чего программа потребляет максимум полтора килобайта ОЗУ.

Я не просто создала программу и выложила на GitHub и всё, я настроила автоматическую сборку бинарного файла на сервере, поэтому вам не нужно компилировать. Бинарная сборка в одном файле AppImage доступна для всех. Работает как минимум на Debian 13 (я проверяла), так что программа будет работать и на Ubuntu, и на Fedora, и на ArchLinux

Что подтянуть бэкендеру для продакшена: 12 практических открытых уроков

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

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

Очереди и надёжная доставка

• 26 августа, 20:00. «Работа с Kafka через библиотеку Kafka Clients». Записаться

• 17 сентября, 20:00. «RabbitMQ в Production: Transactional Outbox, идемпотентность и DLQ в ASP.NET Core». Записаться

Базы данных и конкурентный доступ

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

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

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

Нагрузка и производительность

• 3 сентября, 20:00. «ASP.NET Core API под нагрузкой: как сделать сервис устойчивым к сбоям и росту трафика». Записаться

• 9 сентября, 20:00. «Go‑профилирование: как найти и исправить „тормоза“ в продакшене». Записаться

• 22 сентября, 20:00. «Горутины и каналы: под капотом (under the hood) и нюансы в продакшене». Записаться

HTTP и серверная разработка

• 21 сентября, 20:00. «HTTP‑сервер на чистой Java за 30 минут». Записаться

• 20 октября, 19:00. «Балансировка HTTP и L4 сервисов в Angie». Записаться

Продакшен и наблюдаемость

• 23 сентября, 20:00. «eBPF: рентгеновское зрение для production». Записаться

• 23 сентября, 20:00. «Узнайте, как использовать Patroni для управления высокодоступными кластерами PostgreSQL». Записаться

ЧТО ПОЧИТАТЬ БЭКЕНД‑РАЗРАБОТЧИКУ

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

• «Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт»

• «Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод»

• «std::expected в C++23: гайд по миграции с исключений на функциональный error handling»

• «Move‑семантика в C++: пять задач, в которых легко ошибиться»

Type-driven development в Rust, часть 2/5: как доверить компилятору проверку контрактов между компонентами

Продолжаем серию о type-driven development в Rust — подходе, при котором правила предметной области выражаются в типах, а код, нарушающий эти правила, не компилируется. Рассказывает Никита Тимофеенко, разработчик команды MXDR компании F6.

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

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

Во второй статье представлены три механизма, каждый разобран по той же схеме «проблема -> решение -> хорошие практики -> как это используют известные крейты или std библиотека»:

• traits — контракт вместо конкретной реализации: код-потребитель требует поведение, а не тип, и работает с любым, кто его реализовал; новая реализация — это новый impl, а не правка общего кода;

• associated types — типы, которые выбирает реализация, а не вызывающий: у каждой реализации свои типы результата и ошибки, и в один общий тип они не сводятся. Разница между параметром трейта и ассоциированным типом — это разница между входом и выходом;

• const generics — значение как параметр типа: размер известен компилятору, а не хранится в рантайме, и структуры разного размера — разные типы. Что можно и чего нельзя в const-параметрах на стабильном Rust.

Отдельно рассмотрим CGP (Context-Generic Programming): что делать, когда одному типу нужно несколько реализаций одного трейта, а правило когерентности разрешает одну — и как одна и та же логика собирается под разные контексты без dyn и без match.

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

Вторая статья «Type-driven development в Rust. Часть 2/5: задаём контракты между компонентами» уже на GitHub. Там же — компилируемые примеры ко всем приёмам, включая compile_fail-тесты на каждое «это не скомпилируется» из текста.