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

Как перейти от хаотичной генерации кода к детерминированному конвейеру? Узнаете на GoCloud Tech 2026

Когда речь заходит о внедрении ИИ в разработку крупного монолита, все становится сложнее, чем просто «нажал кнопку — получил код». Авторегрессионный сдвиг, потеря контекста в середине промпта, инвалидация KV-кеша — лишь часть проблем, на которой спотыкаются трансформеры, когда имеют дело с масштабной кодовой базой.

На докладе команда стриминга КИОН поделится своим опытом по переходу к Spec-Driven Development в условиях кроссплатформенного монолита. Разберут, как ограничения ИИ-моделей влияют на автоматизацию рефакторинга, и покажут механизмы slice-изоляции контекста монорепозитория. Отдельное внимание уделят управлению дельтой изменений через неизменяемые спецификации и RFC-патчи, решению дедлоков ИИ-агентов при параллельной работе и организации конкурентного доступа к Gradle-процессам. Продемонстрируют практические результаты миграции DI-слоя Kotlin Multiplatform-приложения и метрики снижения затрат на API-запросы к LLM.

Спикер:
Сергей Лодинев — старший разработчик, МТС Web Services КИОН.

Трек: Разработка

📅 Когда: 15 октября в 13:00–13:40 мск

Rhun: что даёт редактор кода на ассемблере

Rhun — open-source редактор кода, написанный на ассемблере. Уже этого достаточно, чтобы посмотреть на проект не как на ещё одну замену привычной IDE, а как на инженерный эксперимент: что происходит с повседневным инструментом, если собрать его на максимально низком уровне?

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

Что обычно скрывает редактор

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

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

• как хранить текст и положение курсора;

• как обрабатывать ввод и навигацию;

• как связать изменения документа с перерисовкой;

• как работать с памятью и ресурсами;

• какие части зависят от конкретной платформы.

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

Почему это интересно разработчику

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

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

1. Где заканчивается логика редактирования и начинается интерфейс?

2. Что даёт контроль над памятью и ресурсами?

3. В каких местах низкий уровень увеличивает сложность?

4. Что произойдёт при переносе на другую платформу?

Ответы на них помогают лучше понимать любой developer tool — даже если в итоге вы продолжите работать в привычной IDE.

Цена контроля

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

Это особенно заметно в трёх местах:

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

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

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

Кому стоит посмотреть Rhun

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

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

Вывод

Rhun не обязательно оценивать по вопросу «заменит ли он привычный редактор». Важнее то, что проект показывает редактор без привычной магии готовых слоёв. За вкладками, курсором и перерисовкой видны конкретные инженерные решения — и их цена.

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

Ссылки

• Rhun — open-source редактор кода на ассемблере

Подборка материалов: что почитать разработчику

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

➡️ Разбираем фичи по кусочкам: атомарные коммиты как внутренняя дисциплина

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

➡️ Автоматическая генерация UI-настроек

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

➡️ Инструменты, которые упрощают iOS-разработку

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

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

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

➡️ Как ломался пиннинг в Java 21 и что починили в Java 24

Как менялась работа виртуальных потоков от Java 21 к более новым версиям: от проблемы с пиннингом до изменений в JDK 24 и дальнейшего развития Project Loom.

Сохраняйте пост, чтобы материалы были под рукой 🧡

Прикручивал свой diff к git и прошелся по граблям

Я пишу небольшую утилиту datadiff на Rust. Она разбирает два файла JSON, YAML, CSV, TOML или XML и сравнивает получившиеся деревья, поэтому переставленные ключи и переформатирование ее не волнуют. Изменения она печатает путями вроде spec.replicas: 3 → 5. Долго это была отдельная команда, про которую надо было вспомнить, так что я решил встроить ее прямо в git diff. Первой версией была строчка в README: шелл-функция, которая из семи аргументов, передаваемых git внешнему драйверу, брала второй и пятый (там лежат старая и новая версии файла). Работало, пока не попался первый кривой файл.

Оказалось, git считает любой ненулевой код выхода падением драйвера. Пишет fatal: external diff died и дальше ничего не показывает, все файлы после сломавшегося просто пропадают из вывода. А datadiff как нормальный CLI возвращал 1, если нашел различия, и 2 на невалидном файле. Хуже всего, что невалидный конфиг это обычное состояние: открыл YAML, начал править, запустил git diff глянуть что наделал, и получил fatal. Теперь в режиме драйвера datadiff всегда выходит с нулем, а про файл, который не смог разобрать, печатает короткую заметку и подсказку про git diff --no-ext-diff.

Внешний драйвер git вызывает только для самого git diff. git log -p, git show и git blame его игнорируют, туда можно попасть только через textconv, это фильтр, который превращает файл в текст перед обычным построчным сравнением. Я сделал для него режим normalize, он печатает файл в каноническом виде с отсортированными ключами. Если файл не разбирается, normalize отдает его как есть, и тут я накосячил: читал его через read_to_string(...).unwrap_or_default(). Файл не в UTF-8 превращался в пустую строку с обеих сторон, git видел две одинаковые пустоты и молча выкидывал файл из git log -p. Сейчас там чтение байтов и тест на это.

Самые обидные грабли нашлись не в git, а в CSV. В статье на Хабре про самодельный формат конфигов автор объяснял, зачем ему маркер «бери как есть»: чтобы 00544 не превратилось в 544. Я пошел проверять datadiff, и он делал ровно это. CSV типов не хранит, поэтому каждая ячейка, которая разбиралась как число, становилась числом, и замена 00544 на 544 считалась отсутствием изменений. Пока чинил, вылезло еще два случая. Слова, которые f64 честно принимает за число, вроде Nan и inf: человек по имени Nan превращался в NaN, а NaN не равен сам себе, так что неизменившаяся ячейка показывалась как измененная. И целые длиннее i64: они уходили во float и теряли цифры, так что два 20-значных номера счета, отличавшиеся последней цифрой, сравнивались как равные. Правило в итоге такое: ячейка становится числом, только если при этом ничего не теряется. Ведущий ноль перед цифрой, слова вроде nan и inf и слишком длинные целые оставляют ее строкой, а 100 и 100.0 по-прежнему равны. Это вошло в релиз 0.4.1.

Еще запомнился CI. После одного коммита на Windows падал actions/checkout, даже до сборки не доходило. Виноват был файл Icon\r, в нем macOS хранит кастомную иконку папки, в конце имени у него возврат каретки, и он случайно уехал в репозиторий. Windows создать такое имя не может вообще. Тесты при этом падали через раз на всех трех ОС, потому что дочерний процесс успевал завершиться раньше, чем тест дописывал ему stdin, и unwrap ловил EPIPE. Сам проект тут: https://github.com/dimanovikov/datadiff настройка для git в README занимает три строки.

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

Подошли, я ее качаю осторожно, вдруг слышу знакомое слово, прислушиваюсь, оглядываюсь. Сидят на скамейке два челика, обсуждают разработку. С помощью «бота». Видимо, оба этим занимаются. Видимо, в свободное время — вечерами. Делятся успехами и проблемами. По виду обычные 30-летние посоны с раёна — тайпикал вайбкодерз!

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

Дочь, к сожалению, качели недолюбливает, трусиха, быстро расхотела качаться, пожелала лазить по забору, тут уж я трусиха, пришлось идти подстраховывать, а эти кореша продолжили свой бэкенд толкс, аж завидно, я б послушал!!!

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

Мм, лепота!

Open-Spec вместо Open-Source

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

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

Отсюда другая мысль: мы теперь системные аналитики или технические писатели? Ведь по сути анализ (до какой-то границы) можно так же скинуть на агента

Агенты под наблюдением #1. Как я собрал свой велосипед

Всем привет 😎

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

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

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

И тут я обратил внимание на современную разработку через агентов. Как это сейчас называют - вайб-кодинг 😄

Но по натуре я больше технарь и практик. Для меня было дикостью, что кто-то что-то делает, а я это не контролирую.

Вот так и началось моё знакомство с AI-агентами. Сначала через недоверие.

Сейчас могу сказать, что у меня появилось понимание того, как программировать с их помощью. Но для меня это всё равно контролируемая AI-разработка.

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

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

Иначе я бы просто не доверил им разрабатывать продукт и реализовывать хоть какую-то логику. Хорошо, что ещё Git помогает за ними наблюдать, смотреть изменения и при необходимости всё откатывать.

Так начинается рубрика «Агенты под наблюдением». Буду иногда писать здесь просто и по факту о том, что происходит. Когда будет что рассказать.

***

А первая новость такая. У меня глюкнул DeepSeek 4.1 Flash.

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

Думаю. Размышляю.

Потом извинялся за происходящее в чате и продолжал делать то же самое. Таких циклов было около трёх.

Я сильно удивился, мягко говоря. Такого ещё ни разу не видел: чтобы агент зациклился, сам это понял и ещё за это извинился.

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

Часа два, наверное, работали. Хорошая штука эта новая версия DeepSeek: быстрая, как Muse 1.3, умная, как 5.6 Sol, очень вежливая, не то что Muse, и с хорошей логикой работы.

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

А потом её заело. Как икота началась…

Не знаю, что это было. Я пока оставил её в покое. Пусть отдохнёт.

И да - команда /compact не помогала в OpenCode. Думаю, это какой-то баг из-за длинной сессии.

Изолируем зависимости: как создать виртуальное окружение в Python

Когда пишешь код на Python, рано или поздно наступает момент, что один проект начнет ломать другой. Установили новую библиотеку, и вдруг скрипт, который вчера работал, падает с ошибкой. Знакомо? Причина обычно одна — конфликт зависимостей. Все пакеты свалены в один системный Python, версии пересекаются, и что-то обязательно отваливается.

Решение — виртуальное окружение. Это отдельная песочница для проекта: свои библиотеки, свой Python, никакого пересечения с соседями.

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

• Виртуальное окружение vs виртуальная машина. Первое — это просто отдельная папка с пакетами, второе — целая ОС. Хотя некоторые новички часто путают, и потом удивляются, почему venv весит пару мегабайт.

• venv, virtualenv, pipenv, poetry, conda. Это пять инструментов, которые решают похожие задачи, но по-разному. Для большинства проектов хватает встроенного venv — он уже есть в Python с версии 3.3, и ничего ставить не надо.

• Активация. А это самая частая точка спотыкания. Команды различаются для Windows, Linux и macOS, а PowerShell вообще блокирует скрипты по умолчанию. source .venv/bin/activate против .venv\Scripts\activate — и это только начало.

• requirements.txt. Важно помнить, что папку окружения нельзя копировать между машинами, так как она привязана к ОС и архитектуре. Вместо этого фиксируем список пакетов и разворачиваем его одной командой pip install -r requirements.txt.

• Git и .gitignore. Виртуальное окружение в репозиторий не кладут — только код и список зависимостей.

Чтобы пройти весь путь по шагам — от создания первой папки до деплоя на сервере через systemd и Gunicorn — читайте подробный гайд на сайте Рег.облака.

Drizzle ORM: типобезопасный SQL без магии тяжёлых ORM

Привет, я Сергей Маркизов, бэкенд-разработчик в веб-продакшне Далее. В своих проектах я часто использую Drizzle ORM — инструмент для TypeScript-разработчиков, которым нужны строгие типы, но не хочется прятать SQL за несколькими слоями абстракций.

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

Drizzle предлагает компромисс: запросы остаются похожими на SQL, а TypeScript проверяет их на основе схемы базы данных.

Схема — это TypeScript-код

Например, так можно описать таблицу пользователей:

const activeUsers = await db

  .select({

    id: users.id,

    email: users.email,

  })

  .from(users)

  .where(eq(users.isActive, true))

  .orderBy(desc(users.createdAt))

  .limit(10);

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

type NewUser = typeof users.$inferInsert;

const user: NewUser = {

  email: 'user@example.com',

};

Если передать поле неправильного типа или пропустить обязательное значение, TypeScript сообщит об ошибке ещё до запуска приложения.

Запросы остаются похожими на SQL

Для простых операций можно использовать ORM API, а более сложные запросы собирать через типизированный конструктор:

const activeUsers = await db

  .select({

    id: users.id,

    email: users.email,

  })

  .from(users)

  .where(eq(users.isActive, true))

  .orderBy(desc(users.createdAt))

  .limit(10);

Здесь нет отдельного языка запросов, который нужно мысленно переводить в SQL. select, from, where и orderBy остаются на своих местах, при этом поля и результат запроса типизированы.

Если возможностей конструктора недостаточно, можно перейти к SQL-фрагментам:

const result = await db

  .select({

    total: sql<number>`count(*)`.mapWith(Number),

  })

  .from(users) 

Это удобно для агрегатов, CTE, специфичных для конкретной СУБД функций и других случаев, когда бороться с абстракцией сложнее, чем явно описать запрос.

Когда Drizzle особенно полезен

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

• пишут на TypeScript и работают с PostgreSQL, MySQL или SQLite;

• знают SQL и хотят контролировать реальные запросы;

• сталкиваются с ограничениями Prisma или TypeORM;

• не хотят дублировать описание таблиц и TypeScript-типы;

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

Drizzle не привязан к конкретному фреймворку. Его можно использовать с Next.js, NestJS, Remix и другими TypeScript-решениями.

Но «магии» здесь действительно меньше

Это одновременно преимущество и ограничение Drizzle. ORM не скрывает работу с базой и не берёт на себя всю инфраструктуру.

Миграции нужно отдельно встроить в CI/CD, read/write split для реплик — реализовать на уровне приложения. Drizzle работает только с SQL-базами, а его экосистема пока меньше, чем у более зрелых ORM. Проект активно развивается, поэтому документация иногда не успевает за изменениями API.

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

Drizzle — это не ORM для тех, кто хочет забыть об SQL

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

В полной версии статьи я подробнее разобрал описание связей, миграции, CRUD-операции, CTE, транзакции, оператор sql, расширения и ограничения Drizzle ORM.

Буду рад почитать о вашем опыте работы с Drizzle в комментариях. 

От разработки в конфигураторе до архитектуры: 4 материала для 1С‑разработчиков

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

Собрали подборку статей, которые помогут посмотреть на разработку 1С с разных сторон: от организации процесса в команде до оптимизации работы системы.

🔹 «Командная разработка на 1С через EDT и Git: пошаговая настройка проекта»

Статья о том, как перейти от индивидуальной разработки к полноценному командному процессу. Разбираем настройку проекта в EDT, работу с Git и подходы, которые помогают разработчикам эффективно взаимодействовать при изменении конфигурации.

🔹 «Готов ли ты стать функциональным архитектором 1С?»

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

🔹 «Система компоновки данных в 1С»

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

🔹 «Управляемые блокировки в 1С»

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

Бонус: бесплатные уроки по 1С‑разработке

• 28 сентября, 20:00. «Валидация требований с ИИ в техническом проекте». Записаться.
  _{Разберем, как использовать ИИ при работе с требованиями и проверять технические решения на этапе проектирования.}

• 29 сентября, 20:00. «Модульные тесты YaxUnit в связке с EDT». Записаться.
  _{Познакомим с подходом к автоматизированному тестированию 1С‑проектов и разберете работу с YaxUnit в современной среде разработки.}

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

Python в VS Code не работает? Разбираем настройку по шагам

Если вы пишете код на Python, рано или поздно встает вопрос: в чем его писать? Вариантов масса: от блокнота до тяжелых IDE вроде PyCharm. Visual Studio Code — отличный компромисс — он легкий, но при этом умеет почти всё, что нужно для комфортной работы. Но сложность в том, что из коробки он бесполезен, пока не настроишь интерпретатор, расширения и окружение. И вот тут начинается самое интересное.

Вот с чего стоит начать и что стоит разобрать, если вы только садитесь за настройку:

• Интерпретатор. VS Code хранит и редактирует файлы, но код выполняет отдельная программа. Пока вы явно не укажете, какой Python использовать, редактор будет гадать и часто ошибаться.

• Виртуальное окружение. Без него все библиотеки ставятся в общую систему, и рано или поздно два проекта потребуют разные версии одной и той же библиотеки. Что-то одно сломается.

• Расширения. Pylance отвечает за автодополнение, Python Debugger — за отладку по шагам, Ruff — за линтинг и форматирование. Но если поставить всё сразу, инструменты начнут конфликтовать между собой.

• Отладка вместо print(). Точки остановки и панель переменных позволяют увидеть, что реально происходит в коде, вместо того чтобы гадать, где закралась ошибка.

Каждый из этих пунктов — отдельная история с нюансами под Windows, macOS и Linux. Где-то команда называется python, где-то python3. Где-то нужно вручную добавить PATH, где-то переустановить Python из официального пакета.

Если хотите пройти весь путь по шагам: от установки редактора до запуска первого скрипта с отладкой, читайте полное руководство на сайте Рег.облака.

Имхо самая недооценённая деталь Claude Code и Codex — не промпт и не модель. А файл, который агент автоматически читает при старте новой сессии

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

Если в этом файле свалка, то вы каждый раз отправляете модели один и тот же нерелевантный контекст

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

--------------

1. Проверьте системный файл в каждом проекте

Claude Code — CLAUDE. md + недавно Agents. md
Codex — AGENTS. md
Gemini — GEMINI. md

Проверяйте не только наличие этого файла, но и его актуальность
Потому что неактуальный файл даже хуже его отсутсвия

Эти файлы бывают глобальными и локальными

Глобальный файл попадает во все сессии
Локальный — только когда harness запускается из конкретного проекта или репозитория

В системном файле держите минимальное количество high-signal контекста: цель проекта, структуру, важные ограничения, команды запуска и проверки

Не превращайте его в свалку!!1 

Остальное выносите в отдельные файлы и ссылайтесь на них из основного

— меняете дизайн — прочитайте design-system. md — меняете архитектуру — architecture. md — работаете с продуктом — prd. md

Так агент получает контекст по задаче, а не весь проект целиком на каждый запрос

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

Отдельно проверьте память проекта

В Claude Code и Codex есть механизм памяти, который накапливает контекст о проекте, который живет в MEMORY. md

Добавьте в глобальный CLAUDE. md или AGENTS. md правило:

Перед любой записью в memory спрашивай у меня разрешение

Иначе память постепенно превращается в склад случайных фактов, на которые агент продолжает опираться

После этого закройте текущую сессию и откройте новую из папки проекта

Попросите агента рассказать:

— что это за проект
— какие у него правила
— какие файлы он будет читать для дизайна, архитектуры и продукта

Так вы проверите, что системный файл реально подхватился, а не просто лежит в репозитории

Важно не забывать его актуализировать после каждого изменения !!

--------------

2. Сделайте 3–5 собственных skills под регулярные задачи

Не ставьте всё подряд из интернета

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

Хотя бы один skill прогоните на реальном или тестовом примере

Помимо skills есть hooks, subagents, MCP и CLI

Skills — передать агенту повторяемый навык Subagents — вынести шумную задачу из основного контекста Hooks — добавить детерминированное действие на событие

MCP и CLI — подключить модель к внешним сервисам

Понимать всё сразу не нужно

--------------

3. Настройте Scheduler

Пусть он раз в 5 часов запускает простую команду echo 1

Это не задача для агента и не попытка автоматизировать весь проект

Цель — научиться будить сессию и планировать старт пятичасового окна  

--------------

4. Научитесь работать с телефона

Сделайте небольшую правку в проекте одним из двух способов:

— через GitHub: подключите репозиторий к используемому инструменту и внесите изменение через мобильное приложение или облачную сессию, лучше через PR — через Remote Control: подключитесь к локальной сессии Claude Code или Codex с телефона

Remote Control — это когда сессия продолжает работать на вашем компьютере, а телефон становится пультом управления

С телефона можно отправлять инструкции, подтверждать действия и смотреть результат

Файлы и окружение остаются на компьютере, поэтому он должен быть включён и подключён к интернету

В Claude Code используйте /remote-control В Codex подключение настраивается через Settings → Connections

--------------

Не нужно за выходные собирать сложную агентную систему

Смысл этого всего — увидеть, что агентное окружение состоит не только промпта и модели

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

Онлайн-показ AI-driven Digital Q: как мы построили ИИ-экосистему для команд разработки

7 октября в 18:00 в прямом эфире топ-менеджеры компании «Диасофт» покажут новую ИИ-версию экосистемы для разработчиков – AI-driven Digital Q. Она обеспечивает создание ПО от бизнес-требования до промышленной эксплуатации.  

За последние годы ИИ заметно ускорил написание кода. Но для enterprise-разработки одной генерации кода недостаточно. Нужно учитывать архитектуру, требования, существующие компоненты, безопасность, тестирование, CI/CD, документацию и особенности промышленного контура.

Мы пошли дальше отдельных ИИ-ассистентов и построили единую среду для разработки с ИИ – AI-driven Digital Q.

Что такое AI-driven Digital Q

AI-driven Digital Q — промышленная IDP-платформа с двухконтурной моделью разработки. В новой версии искусственный интеллект встроен непосредственно в процесс создания решения и работает на всем жизненном цикле проекта.

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

Использование платформы позволяет:

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

• до 70% сократить расход токенов за счет интеллектуального управления моделями;

• организовать единый end-to-end процесс — от бизнес-требования до промышленной эксплуатации;

• встроить требования к качеству, безопасности и документации непосредственно в конвейер разработки.

В основе платформы — 5 лет практики enterprise AI-разработки, сотни проектов и опыт построения решений в двух контурах разработки.

Что покажем 7 октября

На мероприятии разберем AI-driven Digital Q на практике.

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

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

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

• библиотеку переиспользуемых компонентов;

• интегрированный CI/CD-конвейер;

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

Кому будет полезно

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

7 октября в 18:00 покажем Digital Q в работе и поговорим о том, как меняется разработка, когда ИИ становится не отдельным помощником разработчика, а частью всей платформы.

Для получения ссылки на трансляцию пройдите регистрацию.

Что происходит за пределами вашего стека: 15 открытых уроков недели

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

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

Разработка

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

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

• 23 сентября в 20:00. «Создание кроссплатформенного приложения с GUI на Rust: От идеи до реальности». Записаться.

• 24 сентября в 20:00. «Указатели в Си — от адреса к управлению памятью». Записаться.

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

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

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

• 23 сентября в 18:00. «Ландшафт современного NLP: от эмбеддингов и классических ML‑методов до современных LLM». Записаться.

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

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

• 21 сентября в 20:00. «Типовые задачи с RAID‑массивами: создание, эксплуатация, перенос данных и восстановление». Записаться.

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

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

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

• 22 сентября в 20:00. «Автоматизация управления трафиком с mitmproxy». Записаться.

• 22 сентября в 20:00. «Playwright JS: как быстро начать писать автотесты?». Записаться.

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

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

• 23 сентября в 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться.

• 24 сентября в 20:00. «PM + ИИ: собираем статус‑отчёт, реестр рисков и прогноз сроков за 40 минут». Записаться.

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

Модульный фреймворк для гибкого тестирования на Go — Testo

Если у вас десятки тысяч тестов, сложные сценарии, а тестам не хватает наглядных отчетов – наше опенсорс-решение может вам помочь

Testo — это слой над testing.T внутри экосистемы Go. Мы наполнили его плагинами, чтобы гибко адаптироваться под потребности и быстро создавать тесты под любую задачу.

Что ещё может Testo

1. Параметризировать тесты.

2. Параллелить тесты.

3. Собирать тесты в Suite'ы.

4. Формировать Allure-отчёты.

5. Перезапускать упавшие тесты.

И многое другое, благодаря плагинам.

Больше информации о функционале и ссылка на GitHub — на страничке фреймворка.

Backend без сюрпризов: 15 уроков недели от кода до production

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

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

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

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

• 6 октября в 20:00. «Практические подходы к переходу от монолита на микросервисы». Записаться

• 6 октября в 20:00. «Apache Kafka в микросервисной архитектуре – лучшие практики асинхронного обмена». Записаться

• 22 октября в 19:00. «Основы проектирования бизнес-логики в микросервисной архитектуре». Записаться

Java и Spring

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

• 30 сентября в 20:00. «Spring AI 2.0 на практике: добавляем AI в Spring Boot и доводим до production». Записаться

• 22 октября в 20:00. «Spring Boot под нагрузкой: почему сервис работает локально и падает в production». Записаться

Backend на Go и C++

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

• 1 октября в 20:00. «Паттерн многопоточного программирования Producer–Consumer». Записаться

.NET и ASP.NET Core

• 1 октября в 20:00. «JIT и AOT в .NET: ReadyToRun и NativeAOT на практике». Записаться

• 20 октября в 20:00. «OpenTelemetry в .NET: от чёрного ящика к наблюдаемой системе». Записаться

Базы данных и SQL

• 30 сентября в 20:00. «Подзапросы или CTE – как сделать сложный запрос понятным». Записаться

• 5 октября в 20:00. «Как SQL Server ищет данные – Scan, Seek и Lookup в плане запроса». Записаться

• 15 октября в 20:00. «SQL против бардака в данных: поиск по шаблону и регулярные выражения». Записаться

• 19 октября в 20:00. «Анализируем длинные и сложные запросы в SQL Server». Записаться

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

Тест для AGI

AGI (Artificial General Intelligence), искусственный общий интеллект, способный решать интеллектуальные задачи на уровне человека.

Вводные для теста

1) Изображение

2) Описание

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

Задача

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

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

Upd. Об этой «игрушке разума» для искусственного и человеческого интеллекта можно почитать здесь, на Хабре.

Вот вам еще одна из самых полезных команд в Claude Code для продвинутых
И одна из причин, почему я не фанат Codex Harness -- там такого нет

Это команда /rewind или esc + esc в Claude Code CLI

Эту команду можно воспринимать ее как Ctrl+Z для агента

Сначала вот вам короткое описание из документации Claude Code

Что делает /rewind в Claude Code

Claude Code автоматически создаёт checkpoint перед каждым новым ходом и сохраняет снимки файлов перед своими правками. Команда /rewind или двойное нажатие Esc открывает меню, где можно выбрать прошлое сообщение и:

• восстановить только разговор;

• восстановить только изменённые файлы;

• восстановить и разговор, и файлы;

• свернуть выбранную часть истории в summary.

Checkpoints сохраняются вместе с сессией, поэтому вернуться к ним можно даже после перезапуска Claude Code. Но если в гит намусорили уже другие сессии, то при измении файлов могут вылезать конфликты

Теперь про юзкейсы и объяснение уже от меня

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

1. Состояние git файлов в вашем репозитории

2. и Conversation — история текущего диалога в context window

При вызове команды /rewind вам предложат выбрать конкретное сообщение и затем выбор из 3-5 вариантов

1. Restore code and conversation
   Возвращает и файлы, и диалог к выбранной точке Полезно, когда агент долго шёл не туда и оставил после себя плохие изменения. Продолжать поверх такого состояния смысла нет: контекст и файлы уже заполнены ошибочными попытками

2. Restore conversation
   Диалог откатывается, но код при этом остаётся Сценарий: баг уже исправлен за несколько шагов, но обсуждение бага больше не нужно. Возвращаем разговор до него — следующая итерация видит чистую историю и при этом сохраняет исправленные файлы Полезно и при параллельной работе над одним main

3. Restore code
   Откатываются только файлы, а разговор остаётся Так можно признать решение неудачным, стереть его из репозитория и продолжить обсуждение в том же контексте Это чище, чем заставлять агента по памяти выискивать и удалять свои изменения

4. Summarize

   1. Summarize from here
      Сжать сообщения после выбранной точки

   2. Summarize up to here — сжать всё до точки, оставив последние сообщения дословно /compact подводит итог всей сессии В этих сценариях Claude Code делает форк диалога

5. И ещё есть просто Fork
   Как и в случаях с саммари — старая ветка не стирается: restore code and conversation и restore conversation создают форк

У моего Hermes агента произошел апдейт по коннекторам. Теперь он умеет работать с Meta ADs, Threads и Instagram 💌

Я тут выпускал серию из 4 постов о том, как оно все работает и что нужно сделать, чтобы заработало у вас. Это уже 5 пост из этой серии про новые коннекторы

Я давно хотел научить его работать с Meta ADs, Threads и Instagram

Но там был нужен Facebook Developer аккаунт, который я не мог получить по техническим причинам (meta ux bruh)

И вот спустя 3 месяца мы все порешали и обзавелись большим апдейтом и теперь умеем

🟢 Threads

» Публиковать контент в Threads

» Анализировать собственный Threads аккаунт
история постов, ветки, реплаи, упоминания и метрики. Чтобы видеть, какие темы и форматы реально работают. Сохранять их и переиспользовать

» Исследовать чужие Threads
Разные публичные профили, посты и ветки конкурентов или залетевшие форматы

🟢 Meta Ads — рекламный кабинет меты

» Собирать рекламные эксперименты в Meta Ads
Клови теперь умеет собирать кампании, адсеты, таргетинг, ставить бюджеты и креативы
Только с этим есть проблемка — у Meta Ads CLI баг блокирует запуск и обновление активных РК. Т.е. создать можно, а запустить только через интерфейс или с помощью Meta Ads MCP сервера дома на компе

» Следить за рекламными результатами
Докладывает мне расходы, показы, клики, CTR, CPC, охват и результаты по плейсментам. Классно умеет это сводить с Google Analytics и приносить мне выводы

» Управлять рекламной инфраструктурой
Я пока еще не тестил, но вроде умеет в datasets, пиксели, каталоги, product feeds и product sets
Чтобы строить нормальную связку «объявление → действие → измеримый результат»

» Исследовать рекламу конкурентов
Сейчас в процессе финального подключения, но он сможет искать объявления в Meta Ad Library по ключевым словам, страницам, странам и платформам.

Чтобы собирать тексты, креативы, CTA, даты запуска и ссылки конкурентов и выдвигать гипотезы по рабочим офферам и форматам перед запуском своей рекламы

А ЕЩЕ самый класс в том, что Hermes, залогиненный через Codex теперь сам может генерировать картиночки под креативы. Сам сгенерировал — сам опубликовал

🟢 Instagram Graph API
Теперь мы можем публиковать посты, Reels и Stories. Отвечать на комментарии и собирать статистику аккаунта. Я не особо веду инстаграмм, поэтому просто за компанию его подключил

P.S
Да, подобные коннекты можно сделать и через Claude Code / Codex. Просто у меня личный контур сделан через Hermes. Так удобнее

P. P. S.
А если вы вдруг хотите получше разобраться, как сделать подобного агента для себя или для своего бизнеса, то я завтра в 17 по МСК буду открытую онлайн-лекцию читать

Приходите послушать

Ссылка на событие в календарь вот тут https://calendar.app.google/KcwJv8taqryKmrhj8

Что ИИ меняет в работе с кодовой базой

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

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

Ринат, iOS‑разработчик в Naumen, рассказывает, почему так происходит и что это меняет в работе команды.

🔸 ИИ продолжает то, что уже есть

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

ИИ видит, как принято делать, но не всегда понимает, почему именно так.

🔸 Правила нельзя оставлять только в голове

Важно заранее договориться:

• где живет конкретное бизнес‑правило;

• какие состояния допустимы;

• что должно остаться неизменным;

• как проверить, что новая реализация не сломала соседний сценарий.

Это касается не только разработчиков: аналитик задает ожидаемое поведение, разработчик превращает его в код, ИИ ускоряет работу. Для каждого ориентир — понятные правила и способ проверить результат.

🔸 ИИ не отменяет архитектуру и тесты

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

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

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

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

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

На бесплатных демо-уроках этой недели разберём современные подходы на практике: посмотрим, как работают ИИ‑агенты, 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-тесты на каждое «это не скомпилируется» из текста.