Все потоки

Монитор CAN из Отладочной Платы JZ-F407VET6 и TFT экрана.

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

Экран подлючается по SPI, а на плате единственный порт выведенный на разъём SPI2. Также на разъёме платы P3 присуствует питание 3.3В, а кроме SCK и MOSI выведено еще 4 сигнала, задействуем их для CS, DC, RST экрана и на оставшийся сенсорную кнопку для отправки управляющей команды.

Проверяемое ЭБУ передаёт значения напряжения и тока АКБ, следовательно расшифровав их, можно вывести на экран значения в виде стрелочных приборов. Остальные параметры выводятся в окне статуса. В нижней части экрана выводятся принятые пакеты в шестнадцатиричном виде и общий счетчик пакетов.

В качестве основы проекта использовался pcan_pro_x, упомянутый в одной из публикаций Александра посвящённых этой плате, код инициализации и отрисовки экрана любезно предоставил Google Gemini.

Ссылки на матерьялы:

Обзор учебно-тренировочной платы JZ-F407VET6 (или электронная парта)

Переходник с USB на CAN из Отладочной Платы JZ-F407VET6

T-shaped снова в моде?

Подняли тут вопрос, о том что мы снова движемся от специализации в T-shaped специалистов. Компании планируют сокращать персонал и одновременно с тем надеятся на усиление текущих специалистов за счет ИИ. В некоторых случаях это потребует замены текущих команд или как минимум отдельных людей, на агентно-ориентированных.

В обиход входит слово tiny teams. По представлениям сбера (это их инициатива), это компактные команды в несколько человек с большой степенью автономности находящиеся внутри ai sdlc, где все процессы изменены, где все знания доступны агентам и так далее. В общем ai native организации, вместо (зачеркни ненужное) бирюзовых, agile и других слов.

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

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

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

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

Как связать контейнеры Nginx и PHP в Docker Compose, чтобы Nginx мог проксировать запросы?

Допустим, вы пытаетесь развернуть связку из веб-сервера и PHP. Контейнеры поднимаются, но веб-сервер выдает ошибку сети и не может достучаться до PHP-бэкенда. Разберемся, что нужно прописать в конфиге Nginx, чтобы они увидели друг друга.

Чаще всего подобная проблема возникает из-за того, что контейнеры изолированы друг от друга на сетевом уровне, либо в конфигурационном файле веб-сервера некорректно указан адрес целевого хоста. В экосистеме Docker Compose встроенный DNS-сервер автоматически сопоставляет имена сервисов с их внутренними IP-адресами. Поэтому не нужно прописывать статические IP — достаточно правильно использовать имена, заданные в манифесте. 

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

Чтобы Nginx мог передавать запросы PHP-FPM, необходимо:

• убедиться, что оба контейнера находятся в одной сети (app_network),

• указать в конфигурации Nginx правильный адрес PHP-контейнера (в нашем примере это php:9000, где php — имя сервиса в docker-compose.yml).

Шаг 1: Проверка манифеста docker-compose.yml

Убедитесь, что для обоих сервисов явно выделена одна общая сеть. Пример корректной структуры:

version: '3.8'
services:
  nginx:
    image: nginx:latest
    container_name: nginx
    ports:
      - "80:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./nginx/html:/var/www/html
    depends_on:
      - php
    networks:
      - app_network

  php:
    image: php:8.2-fpm
    container_name: php
    volumes:
      - ./php:/var/www/html
    networks:
      - app_network

networks:
  app_network:
    driver: bridge

Шаг 2: Настройка конфигурации Nginx

В блоке location, отвечающем за обработку PHP-скриптов, в директиве fastcgi_pass вместо 127.0.0.1 или localhost необходимо подставить имя сервиса PHP из файла конфигурации:

server {
    listen 80;
    server_name localhost;

    root /var/www/html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass php:9000;  # Связь с PHP-контейнером
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Директива depends_on в блоке Nginx гарантирует, что веб-сервер не начнет стартовать раньше, чем поднимется контейнер с PHP. Это предотвратит падение Nginx при первичном запуске окружения, если он не сможет сразу разрешить DNS-имя php.

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

Поступить в магистратуру, чтобы запустить стартап: как это работает

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

28 июля проведем эфир «Запуск корпоративного стартапа во время обучения: как совместить работу и учебу с максимальной пользой».

На открытой встрече выпускники онлайн-магистратур Центра «Пуск» МФТИ и представители компаний расскажут, как развивали корпоративные стартапы во время обучения.

За три года наши студенты разработали и защитили более 50 проектов для Hoff, Сбера, билайна, НИИАС РЖД, НЛМК, Совкомбанка, МКБ, Zecurion, GreenData и других компаний.

В программе:

🔹 Какие корпоративные стартапы выпускники разрабатывали во время обучения и для каких компаний.

🔹 Какие задачи стояли перед командами и какие решения они предложили.

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

🔹 Как работа над корпоративным стартапом повлияла на карьеру и профессиональное развитие выпускников.

🔹 Как прийти в магистратуру с проектом своей компании или взять задачу от индустриального партнера и развивать во время обучения в магистратуре Центра «Пуск» МФТИ.

📅 28 июля (вторник)

🕖 19:00 (Мск)

💻 Онлайн

Участие бесплатное. Необходима регистрация.

ВКонтакте: https://vk.com/app6379730_-224205661#l=31&auto=1

Telegram: https://t.me/mipt_events_bot?start=dl-17846368420ebf8e1ae9f2

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

На этой неделе заказчикам нужны специалисты для следующих задач:

• Автоматическое определение договора при загрузке банковской выписки в 1С:Бухгалтерии 3.0.

• Настройка отображения остатков Центральной базы при подборе товара в УТ 11.5 РИБ.

• Перенос остатков по заказам из УТ 10 в УТ 11.5.

• Поиск и исправление ошибки закрытия месяца в 1С:Бухгалтерии ПРОФ.

• Разработка внешнего отчета для УПП 1.3.

• Интеграция существующей CRM с 1С:Управлением торговлей 11.

• Заказ по статье «Сверка документов между базами».

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

• Диагностика и устранение ошибок в 1С-Рарус: Учет ЦБ 3, связанных с купонами, РЕПО и загрузкой брокерских отчетов.

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

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

Как мы закрываем задачу: тесты, диптрак, аудит и ещё пара рубежей

Продолжение серии про работу с ИИ-агентом. В прошлый раз разбирали, где живёт задача. Теперь — что с ней происходит, прежде чем она станет done.

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

1. Автоформат — молча и сразу. После каждого Edit/Write срабатывает хук: Pint для PHP, Prettier для JS/TS правят изменённый файл. Не блокирует, ничего не спрашивает. Форматирование просто снято с повестки — про пробелы и переносы мы не спорим никогда.

2. Приёмка «прогнал — работает» (скилл verify-task). Финал задачи — не «по идее работает», а таблица. Перечитываем Definition of Done, по каждому пункту: как проверено → PASS/FAIL. Внутри:

• прогон тестов затронутой области (Pest/PHPUnit) — зелёные, а не «вроде есть»;

• smoke живого сценария через tinker или artisan-команду;

• корнер-кейсы: пусто, граница, null, таймаут внешнего сервиса;

• в diff нет ключей и .env.

Любой FAIL — задача не закрыта. Без «ну это мелочь, потом починим».

3. Deptrac — границы слоёв (Stop-хук). На попытке закрыть ход прогоняется анализатор архитектуры. Уехала логика из сервиса в контроллер, модель полезла напрямую во внешний API — exit 2, ход не закрывается, пока не переложишь код в правильный слой. Тот же гейт стоит в CI, а легаси-долг зафиксирован baseline’ом, чтобы старые грехи не блокировали новую работу. Правило в конфиге кажется неверным? Правь конфиг явно и объясняй — обходить молча нельзя.

4. Секреты не текут (guard-secrets). Отдельный хук стережёт, чтобы содержимое .env, ключей и дампов не улетело в чат: cat/grep по секретному файлу блокируются, Read на него — тоже. Править такие файлы можно (Edit/scp), а вываливать в переписку — нет.

5. Рефлексия — иначе не закрыть (guard-discipline). Код менялся, а записи в task/history за сегодня нет? Снова exit 2. Хук требует короткий разбор: что ставили, как решал, решено да/нет/частично, что можно было лучше. Следующая сессия начнёт с этих заметок и не наступит на те же грабли.

6. Независимый аудит — по коду, а не по рассказу. После нетривиальной доработки запускается отдельный агент, который не видел, как ты решал. Ему дают diff и чек-лист: все ли call-сайты покрыты, нет ли регрессий, есть ли тесты, скрытые баги, не уехали ли слои, не утекли ли секреты. Вердикт — APPROVE или CHANGES NEEDED со списком «файл:строка — почему». Нашёл проблему — не чинит молча, возвращает автору. Без аудита мёрдж не предлагаем.

7. И только теперь — в done и на мёрдж. Задача переезжает в task/done до открытия MR, в той же ветке. Прямой push в main закрыт хуком — только через merge request. А прод-pull делает человек: guard-prod fail-closed не пускает агента мутировать боевой сервер, агент лишь готовит команды.

Тут важно, кто есть кто. Автоформат, Deptrac, защита секретов, рефлексия, запрет пуша в main и защита прода — это хуки. Они срабатывают автоматически на события (после правки файла, при попытке закрыть ход, перед bash-командой) и возвращают exit 2, если что-то не так. Их нельзя «забыть» или уговорить — они не читают промпт, они перехватывают действие. А приёмка и аудит — это скиллы, процедуры, которые агент запускает сам: тут уже нужна голова, а не только стенка. Стенки ловят механику, скиллы — смысл.

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

«Готово» — не когда агент дописал код, а когда код прошёл все рубежи.

Почему «я знаю слова, но не могу говорить» — это не всегда проблема словарного запаса

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

Из этого следуют несколько простых правил для практики:

1. Проверять нужно не только узнавание, но и свободное извлечение: показать ситуацию и попросить сказать фразу без списка вариантов.

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

3. Ошибку полезно разбирать после попытки. Если останавливать человека до того, как он договорил, тренируется избегание, а не речь.

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

Я собираю KeelAI вокруг этой идеи: чтение, повторение слов и переход к спокойным голосовым ответам в Telegram. Сейчас особенно интересны менее популярные языки, где проблема не в отсутствии учебников, а в нехватке регулярной практики.

Текущая версия проекта доступна здесь: KeelAI.

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

Математик Дмитрий Рыбин вместе с GPT-5.6 опроверг известную гипотезу, которую открыли ещё 30 лет назад — он попросил ИИ «совершить прорыв».

Серьёзно, никаких хитрых промптов для научного исследования не понадобилось: математик просто просил ChatGPT продолжить опровержение. После этого ИИ 80 минут выстраивал цепочку аргументов. Автор поделился чатом с моделькой и называет ситуацию «чистым мемом».

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

Вайб‑кодинг довёл: «сайт за ночь», сотый планировщик бюджета и клон Google Диска

Наблюдение за последние месяцы: слово «SaaS» на глазах становится ругательным. Треды забиты историями «создал продукт на миллион за сутки», и почти всегда это реклама аккаунта автора, а не продукт. Планировщиков бюджета, написанных с Клодом, я лично насчитал уже больше сотни. Но недавно встретился экземпляр покрепче: человек с помощью ИИ собрал аналог Google Диска. Всерьёз. Хранение чужих файлов — это юридика (персональные данные, DMCA, 152-ФЗ), это бэкапы, это аптайм, это поддержка на годы. Ничего из этого в промпте не было.

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

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

Конкретика из моей ниши — SEO. Прежде чем подпускать ИИ к семантике, я несколько лет собирал её руками. Поэтому вижу, где модель реально ускоряет, а где уверенно гонит брак:

— ускоряет: рутина по кластеризации, черновики метатегов, шаблоны программатик‑страниц, техничка;

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

Свой первый коммерческий сайт — простой многостраничник под SEO — я писал месяц, с ИИ в руках. Не за ночь. И всё равно наделал кучу ошибок, часть страниц переделывал. А на юзабилити звал живого дизайнера: расположение текстов, шрифты, подача картинок. Потому что сайтом пользуются люди, и насмотренность дизайнера — тысячи отсмотренных работ, натренированный глаз — это пока не сжимается в датасет. Модель может сгенерить лендинг, который «выглядит как лендинг». Дизайнер видит, почему по нему не хочется скроллить.

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

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

Must-read для Python-разработчика: 5 статей от практика с сотнями интервью за плечами 

Делимся подборкой статей от Евгения Бартенева, эксперта курсов Практикума и разработчика с 20-летним опытом. А ещё он активно занимается созданием образовательного контента: является автором и техлидом курса «Python-разработчик», пишет статьи и проводит бесплатные мок-интервью для всех желающих в рамках проекта Boreesych.

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

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

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

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

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

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

Госдолг США в 2026 году достигнет $40,7 трлн. Это станет самым большим объёмом госдолга в мире. При этом самый высокий долг по отношению к размеру своей экономики зафиксирован в Японии: он составляет 204% ВВП. Несколько европейских стран также входят в число наиболее закредитованных по отношению к ВВП, хотя их общий объём государственного долга значительно уступает показателям США или Китая.

Прогнал официальный conformance suite OpenID Foundation против redb.Identity.

Basic OP: 35 модулей, 0 failures. Config OP: 0 failures.

Что нашли и исправили:

• PII утечка: scope-derived claims (phone, email) попадали в id_token — они должны быть только в UserInfo

• UserInfo возвращал внутренности OpenIddict через deny-list

• Отсутствовал Cache-Control: no-store на token endpoint (RFC 6749 §5.1)

• prompt=login / max_age ре-аутентификация была сломана

Одно WARNING осталось намеренно — два приватных claim в id_token с обоснованием.

Полный отчёт

Импортозамещение: «лишь бы российское» уже недостаточно

Наконец посчитали, что российский ИТ-рынок в 2025 году вырос на 13% и превысил 4 трлн рублей. Быстрее всего росли сегменты программного обеспечения и ИТ-услуг, а одним из главных драйверов оставалось импортозамещение.

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

Лицензия – только входной билет

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

• Как решение встроится в существующую инфраструктуру?

• Кто отвечает за сопровождение при сбоях и обновлениях?

• Как система восстанавливается после ошибочного изменения?

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

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

Каталог как проверка зрелости внедрения

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

• создание резервных копий и восстановление отдельных объектов и атрибутов;

• сохранность прав доступа и членства в группах, корректность репликации;

• мониторинг массовых и ошибочных изменений;

• понятный порядок действий администратора после инцидента.

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

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

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

Пройди воркшоп по наблюдаемости ИИ-агентов с Langfuse

Привет! Меня зовут Филипп Бочаров, я CPO в МТС Web Services и член ПК HighLoad++. Мы с командой придумали воркшоп «Смотри, как думает агент: Observability AI-агентов с Langfuse». Его прошли уже более 60 человек на конференциях AIConf 2026 и Saint HighLoad++ 2026, а теперь он стал доступным публично всем желающим!

На примере демонстрационного ИИ-агента на Python вы узнаете:

• сколько могут стоить ошибки агента в рублях;

• как сломать продуктивный агент, не меняя ни строчки кода;

• что может пойти не так с MCP.

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

Что будет на воркшопе

Мы будем работать с демонстрационным ИИ-агентом Cookbook Agent. Он умеет создавать рецепты блюд и рассчитывать стоимость ингредиентов.

На каждом шаге воркшопа сымитируем различные нештатные ситуации, которые вам нужно будет найти и исправить с помощью open-source-инструмента Langfuse.

Демонстрационный ИИ-агент состоит из пяти частей:

• Cookbook-agent — агент на Python. Это основной проект, который мы будем изучать и изменять.

• MCP-server — MCP-сервер, к которому агент обращается за поиском рецептов и их стоимостью. Развернут локально, но вы считаете, что он находится где-то в облаке. MCP-сервер для вас — черный ящик.

• Qdrant — векторная база данных с рецептами.

• RAG-loader — утилита для загрузки рецептов в Qdrant при первом запуске.

• Redis — хранилище памяти для сессии агента. Изначально наш агент память не использует, но она будет добавлена на последнем шаге.

Зачем это нужно…

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

На этом воркшопе мы покажем, как можно диагностировать такие типовые проблемы. Цель — освоить инструмент для диагностики типовых проблем AI-агента.

Что такое Langfuse

Это open-source-платформа для разработки и наблюдения приложений на базе LLM. Ее ключевые функции:

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

• Возможность хранить промпты централизованно с контролем версий.

• Метрики качества: проверка ответа агента на корректность, безопасность и так далее.

Требования к участникам

• ноутбук с доступом в интернет;

• git, Docker v24.x+ и Docker Compose v2.22.x+;

• любой редактор кода, желательно с поддержкой Python;

• 500 рублей для оплаты LLM в сервисе MWS GPT Model Hub; 

• два часа свободного времени.

Как пройти воркшоп

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

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

• Решение — это ответ на задание с подробным разбором причин и способа исправления.

Старайтесь разобраться в задании самостоятельно, не забегайте вперед и не подсматривайте в решение.

Открытый проект PriceGhost позволяет искать самые дешёвые и качественные товары в сети Интернет с помощью ИИ:

• внутри команда ИИ‑агентов, которая проверяет сотни площадок с нужным вам товаром;

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

• выдаётся подробный отчёт с инфографикой. ИИ также выдаст рекомендации, если товара не будет в наличии;

• результат — можно купить вещь выгоднее и не ждать долго доставку, а ещё не навяжут скрытые условия.

Автоматизируем архив правильно и безопасно

Компании, особенно сегмента enterprise, часто сталкиваются с рядом проблем при ведении архивов: бумажный экземпляр и электронный существуют отдельно, система не успевает обрабатывать объемы хранения, подготовка справок и выписок занимает часы. И все это одновременно с необхдимостью организовать архив по приказу Росархива № 77.

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

29 июля 11:00 команда экспертов экосистемы «Авандок» проведет бесплатный вебинар на тему: «Как организовать электронный архив с ИИ и не нарушить правила». (ссылка)

На этом вебинаре вы узнаете:

·        какие бывают архивы

·        об актуальных нормах и требованиях законодательства к хранению

·        ключевые критерии выбора системы электронного архива

·        как оценить эффект от внедрения электронного архива

·        И как ИИ упрощает работу архивариуса

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

Спикеры:

👉 Мария Токарева – Директор по развитию решений, ГК «КОРУС Консалтинг»

Более 20 лет опыта создания и внедрения комплексных решений для крупнейших коммерческих и государственных заказчиков

👉 Мария Лямина – Руководитель группы аналитики, ГК «КОРУС Консалтинг»

Более 12 лет опыта в разработке и внедрении комплексных решений для автоматизации бизнес-процессов в государственных и коммерческих организациях

 Подробнее на сайте | Зарегистрироваться

Участники получат запись и чек-лист «Как привести электронный архив в соответствие 77-му приказу Росархива»

Telegram / MAX

Type-driven development в Rust: делаем недопустимые состояния невыразимыми

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

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

Серия рассчитана на тех, кто уже пишет на Rust и хочет от системы типов большего, чем борьба с borrow checker-ом. Теории типов не будет — только приёмы и шаблоны для рабочего кода, почти всё на стабильном Rust.

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

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

Примеры во всей серии — из биржевой торговли, но сами приёмы работают в любом домене со сложными состояниями и правилами их изменения:

• newtype — свой тип для каждой роли вместо голого примитива: значения разных типов не перепутать местами, а инварианты проверяются один раз — при создании (smart constructor);

• ADT — «одно из» через enum с данными в вариантах вместо булевых флагов и Option-ов, допускающих бессмысленные комбинации;

• uninhabited types — типы без значений: как убрать ветку ошибки, которая «никогда не случится», так, чтобы это гарантировал компилятор, а не unreachable!();

• phantom types — параметры-маркеры без рантайм-представления: одна generic-обёртка с типом-тегом вместо семейства одинаковых newtype-ов;

• typestate — состояние объекта в его типе: у каждого состояния свой набор методов, переход возвращает новый тип, а неверный порядок шагов не компилируется.

Первая статья — «Type-driven development в Rust. Часть 1/5: делаем недопустимые состояния невыразимыми» — уже на GitHub. Там же — компилируемые примеры ко всем приёмам: Cargo workspace, который собирается и проходит тесты.

В Steam анонсирована игра в виде симулятора работы Working95, в которой нужно выполнять все офисные задачи — вести дела с электронными таблицами, сортировать файлы, осуществлять бухгалтерский учёт и многое другое. «Я делаю игру, в которую мои родители хотели, чтобы я играл!», — пояснил авто проекта.

Мировое Anthropic с авторами на $1,5 млрд: не тот прецедент, каким его подают

На днях суд в Сан-Франциско окончательно утвердил мировое Anthropic с авторами на $1,5 млрд. Это крупнейшее известное урегулирование по авторскому праву в США. Дело вёл судья Alsup, но к финалу он вышел в отставку (конец 2025), утвердила мировое судья Araceli Martinez-Olguín.

Новость разошлась под заголовком «суд признал обучение ИИ на книгах добросовестным использованием». Это не совсем верно.

Что решил суд, исходя из информации из открытых источников: судья Alsup ещё в июне 2025 указал: само обучение модели на книгах - это fair use (добросовестное использование по праву США), потому что использование трансформирующее. Нарушение увидели в другом - Anthropic скачали больше 7 млн книг из пиратских библиотек (LibGen, PiLiMi) и держали на их базе «центральную библиотеку», часть которой в обучение, возможно, и не пошла бы. Мировое и $1,5 млрд - именно за это хранение, не за обучение.

И тонкость, которую в пересказах теряют. Класс по делу сертифицировали только по пиратскому эпизоду. Вывод про fair use на обучении формально касается трёх истцов, которые подали иск, а не всего класса. Значит, прецедента «обучать ИИ на книгах законно» тут ровно столько, сколько одно решение одного окружного судьи (к тому же вышедшего в отставку) весит для следующего суда. Пока, скорее, это ориентир для других судей.

Что из этого практического. Источник данных теперь из чисто технического вопроса дополняется его классификацией, как юридического факта - важным становится «откуда взяли», а не на чём обучали. Лицензированный и открытый контент для обучения; правомерные источники для RAG (генерация с опорой на найденные документы - СПС, свой архив, купленные базы); лог того, на чём модель реально училась.

Про РФ. Прямого переноса вывода про fair use у нас нет: в российском праве отсутствует институт добросовестного использования в том формате, как он существует в праве США, но есть закрытый перечень случаев свободного использования (ст. 1274 ГК и рядом). Так что «обучение = fair use» к нашей юрисдикции не прикладывается. А вот риск пиратского происхождения данных прикладывается один в один - суды в разных странах смотрят на одно и то же: откуда контент и не бьёт ли он по правообладателю.

ИМХО, главный итог состоявшегося события не в том, что теперь «ИИ можно учить на книгах», а в том, откуда взяли данные и легально ли их происхождение. Anthropic, к слову, вину так и не признали и всё равно заплатили $1,5 млрд за то, как собирались данные для обучения.

Сегодня произошла интересная штука: я встретил вживую новый вид сотрудника - "Оператор ЛЛМ", это как "Оператор ЭВМ", он "жмакает" кнопки, но не понимает зачем.

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

1 - чувак говорил, что у него есть хоум лаба, но не смог рассказать из чего она состоит (контейнеры/виртуалки/гипервизор).

2 - чувак показал свой пет-проект, но не смог рассказать как он работает под капотом.

Почему? - потому что он "кнопкодав", "оператор ЛЛМ" - называйте как хотите.

Это очень опасная тенденция, все больше людей называют себя "архитекторами" приложений, не понимая основ технологий которые их ЛЛМ пытается применять.