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

Эпоха AI. Бюджет выделен, ждём чуда.

Рынок в РФ наконец дозрел до массового внедрения корпоративных AI-подписок. Бюджеты на Claude/Codex становятся чуть ли не обязательными. И почему-то все ждут, что продуктивность резко увеличится.

Главная проблема - никто не знает, как ИИ влияет на продуктивность. А еще никто не знает как это достоверно оценить. К примеру в исследовании METR в июле 2025 получили ухудшение продуктивности. Существует много исследований, все с очень разными результатами.

И правда, как измерять-то? Влияет проект, задача, стек, промпты, даже время суток (не шучу). Модели ведут себя по-разному, спецификации отличаются, контекст меняется. Все используют разные инструменты и по-разному. Насколько сильно влияют скиллы разработчика? Знание проекта? Документация? Язык общения? На одной задаче мы могли ускорится в два раза, на другой - протупить дополнительно 2 дня. В каждом аспекте полная неизвестность, помноженная на неизвестность.

Ну и относительно какого периода считать прирост? Тут тоже вопрос без ответа. Многие используют ИИ инструменты аж с 2022 года. Значит нужно собирать статистику с 2021. Но там и технологии были другие, и разработчики, и подходы, и задачи... Объективно ли? Нет. Но 2024 за baseline тоже взять нельзя, тогда уже многие сидели на личных подписках. Но бизнес всё же приходит и говорит: мы выделили бюджет на AI, ждём от вас взрывного роста продуктивности. В два, в три, в пять раз! Как в Майкрософт! Как в Фейсбуке!

Но ведь у многих производительность реально растёт! Правильно. Если тебе менеджер по десять раз на дню пишет про твой статус, режет оценки и торопит - можно и правда ненадолго ускориться. ИИ тут не при чем. Методология "галеры" однозначно работает. Только ни один адекватный разработчик в таком месте долго не задержится.

Впереди много интересного. Будут и хорошие решения, будут и глупые. Всё это постепенно сформирует новые процессы, подходы и метрики. Когда-то ведь впервые появился Git, доски, нормальные фреймворки. И каждый раз сначала был безумный культ, потом разочарование, только потом взвешенный подход, на котором и держится вся реальная польза. Технологии не остановишь, так что нам с вами придется пройти этот путь. Хотим мы этого или нет 🫢

На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.

Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 10³². Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.

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

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

Логика работы микросервиса была простой: в ответ на запрос генерировался UUID, выполнялась чрезвычайно важная проверка на уникальность в этой базе данных, а затем идентификатор возвращался клиенту. Работу микросервиса поддерживала отдельная команда из трёх инженеров с собственными спринтами и канбан-доской.

РБПО по ГОСТ Р 56939—2024: вебинар №11 из 30 – Динамический анализ кода программы

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.11. – "Динамический анализ кода программы". На YouTube. Слайды.

Цели 11-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Написал большую статью на Habr — От написания промптов к проектированию контекста. Или один очень обширный материал про Context Engineering

Полезно всем, кто работает с агентами Claude Code | Codex 🍦

Что внутри

Context rot и reasoning shift — почему длинный контекст это плохо

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

Из каких 7 слоёв состоит контекст Зачем нужен CLAUDE.md / AGENTS.md / GEMINI.md
Что такое MEMORY.md Секция про Skills, MCP, Subagents

Архитектура AGENTS LOOP

Как работает Prompt caching Как считается стоимость токенов

Что отличает Новичка от Мастера в работе с современными агентами

А какие там иллюстрации, мммм

А завтра онлайн в 18 мск буду читать лекцию по этой статье, залетайте послушать https://calendar.app.google/TDm1ZZusNtX5w394A

Дорожная карта Agentic AI. Level 4. Мастер примеров — few-shot и structured output

Есть один приём, который считаю самым недооценённым в работе с моделями: учить её прямо в промпте. Никакого файнтюна, никакого дообучения, никаких отдельных датасетов. Просто показываете несколько примеров «вход → выход», и модель подхватывает паттерн. Это называется few-shot learning, и на практике работает куда лучше, чем ожидаешь.

Где это реально работает

Лучше всего на задачах, которые повторяются и где у вас есть эталонные примеры. Берёте классификацию обращений клиентов: показали модели пять размеченных примеров, и она начинает раскладывать новые обращения по тем же категориям. Извлечение реквизитов из писем, парсинг характеристик товаров, разметка отзывов по тональности — всё это ложится на few-shot.

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

Три уровня, которые нужно понимать

Чтобы не гадать самим, нужно понимать разницу между режимами. На одном конце zero-shot: только инструкция, без примеров; на мощных моделях для простых задач часто хватает и этого. One-shot добавляет один эталонный образец и полезен, когда важен точный формат ответа. Ну а few-shot это уже от двух до десяти примеров; на практике 3–5 штук оптимум, потому что меньше даёт мало сигнала, а больше добавляет шум и лишние токены. Хорошую базу по технике даёт Prompting Guide, а про подход Claude подробнее в документации: multishot-prompting.

Что класть в примеры

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

Почему без structured output это бесполезно в бизнесе

Но даже с хорошими примерами остаётся вопрос: куда девать результат. В продакшене нужен не текст, а JSON строго по схеме: category: "техподдержка", priority: "высокий", responsible: "техотдел". Чтобы результат сразу ушёл в CRM, в базу, в следующий сервис: не придётся разбирать свободный текст руками. Примеры для few-shot делайте сразу в этом формате: так модель быстрее схватывает нужную структуру. Документация: OpenAI Structured Outputs, Claude Structured Outputs.

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

По опыту, хорошие примеры в паре со structured output закрывают без файнтюна и без ML-команды огромный пласт задач на извлечение, разметку и классификацию.

Разобрали продвинутый few-shot на реальном кейсе: смотрите видео.

🔔 Следующая тема: RAG и векторные базы — как передать агенту знания о вашем бизнесе.

⬅️ Предыдущая тема: Level 4. Своя кузница — локальный запуск моделей

Подписывайтесь, пожалуйста, чтобы не пропустить!

Больше про ИИ — в ТГ-канале и ВК. Каталог наших курсов, услуг и кейсов по ИИ-агентам. По вопросам — пишите в личку.

💥 💥💥 Новое в Gramax 💥💥💥

Breaking change

• Представление каталога. Фильтр каталога заменили на представления — функция вышла из экспериментального режима. Теперь вместе с фильтрацией статей можно задавать переменные: одна статья показывает разный контент без создания копий.

• ⚠️ Автомиграции нет. Если был настроен фильтр — добавьте его заново через панель представлений.

Gramax Enterprise Server

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

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

• Улучшения настройки проверок по стайлгайду:

  • Правила отображаются таблицей, редактор открывается в боковой панели.

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

  • Правила можно экспортировать — поделиться или сохранить копию.

  • Запуск тестов правил доступен для каждого правила.

Общие изменения

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

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

• Фрагменты вместо сниппетов и ссылки с превью. Сниппеты переименованы во фрагменты. Теперь можно ставить ссылки на фрагменты прямо из текста: при наведении — превью, удобно для глоссария.

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

• Версионирование в редакторе. Теперь можно переключаться между версиями прямо в редакторе, а не только настраивать их.

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

• Навигация по OpenAPI. Для OpenAPI-спецификаций в правой панели доступна навигация по методам API — можно перейти к нужному без прокрутки.

• Улучшения поиска:

  • Поиск внутри папки ограничен ею по умолчанию. При необходимости переключитесь на По всем каталогам.

  • Поиск учитывает полный путь в навигации: статью Вклады / До востребования найдете по запросу Вклад до востребования.

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

  • Добавлен пункт (пусто) для статей без значения, пункт (выбрать все) сбрасывает фильтр.

• Улучшения и стабилизация:

  • Перетаскивание статей и разделов в левой панели ускорили в 10 раз.

  • Если Git-сервер недоступен, приложение переходит в офлайн-режим. Вернется автоматически, когда сервер станет доступен.

  • Обновили тулбар редактора. Элементы сгруппированы по категориям, списки открываются по клику.

  • Подсветка текста адаптирована под темную тему.

Подробнее: https://gram.ax/resources/docs/whats-new

Дорожная карта Agentic AI. Level 4. Своя кузница — локальный запуск моделей

Не всё имеет смысл отдавать в облако. Причин у этого как минимум три:

1. Приватность. Стоит начать пересылать в чужой API персональные данные клиентов, внутреннюю переписку или код с коммерческой тайной, как логи стороннего провайдера превращаются из абстрактной строчки в SLA во вполне конкретный риск утечки. Локальная модель эту головную боль снимает: данные просто не покидают периметр компании, и обсуждать с безопасниками становится по сути нечего.

2. Автономность. Когда провайдер прилёг, сети легли или вашему региону внезапно прикрыли доступ, локальный агент этого даже не заметит и продолжит работать, как ни в чём не бывало.

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

Что вообще получится запустить

Проприетарные модели уровня GPT-5, Claude Opus 4.7 или Gemini 3.1 локально вы, конечно, не запустите: они закрытые и слишком огромные. Зато опенсорс быстро подтягивается следом. Qwen3 от Alibaba, DeepSeek R1 и V3.1, Mistral Small и Magistral это вполне рабочие модели, которые в квантизованных версиях помещаются на одну видеокарту. Даже OpenAI в прошлом году выложила свою открытую gpt-oss, сразу в 20B и 120B параметров.

Чем крутить локально

Проще всего начать с Ollama: ставится одной командой, ещё одной скачивается модель, и всё. Никаких плясок с CUDA, Python и зависимостями, из коробки есть и GUI, и REST-API. Если хочется чего-то более «приложенческого», посмотрите в сторону LM Studio или Jan; у LM Studio при этом есть приятная мелочь: она ещё до скачивания подскажет, хватит ли у вас ресурсов на конкретную модель.

Как встроить в свой код

Самое важное даже не в том, как удобно поднять модель у себя, а в том, что интегрировать её в код ваших приложений так же легко, как сменить провайдера. У всех этих инструментов OpenAI-совместимый API, поэтому в клиенте OpenAI достаточно поменять base_url с облака на localhost, и тот же самый код из прошлых постов продолжит работать без единой правки.

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

Эта связка работает, пока вы экспериментируете на ноутбуке. В продакшене ставки выше: опенсорс-модель надо крутить под реальной нагрузкой, и стандарт здесь это vLLM. Он оптимизирован под высокий RPS и параллельный инференс, реально выжимает из GPU всё, что она способна отдать.

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

🔔 Следующая тема: Few-shot learning, как учить модель прямо в промпте.

⬅️ Предыдущая тема: Level 4. Новые чувства — мультимодальность

Подписывайтесь, пожалуйста, чтобы не пропустить!

Больше про ИИ — в ТГ-канале и ВК. Каталог наших курсов, услуг и кейсов по ИИ-агентам. По вопросам — пишите в личку.

ИИ: Гонки на лафетах

Всего лишь иллюстрация. Примерно год-полтора назад решил я выбрать - deepseek или chatgpt. И выбрал deepseek. Однако через некоторое время стал обращать внимание не его лютый подхалимаж, что, кстати, не раз уже обыграли в различных мемах. Не в отношении deepseek, а относительно AI в общем.
Проблему обсудил и с deepseek, и с windows copilot (chatgpt был благополучно забыт). Deepseek стал подхалимски юлить, мол да, copilot хорош и все такое. Copilot же оправдал Deepseek - мол это такая технология поддержки энтузиазма в клиенте. Между прочим тонко намекнув, что сам-то он лучше и глубже. Но это присказка, сказка впереди.
В процессе завершения разработки обертки над EntityFramework попросил оценить проект сразу четверых: deepseek, copilot, chatgpt и grok. Результат ожидаем - сыровато, но в продакшн годно, оценки 4.5/5 и 7/10.
Претензии разные, существенных практически не было, но в одно они уперлись хором - "тяжелые" интерфейсы. Подробности опущу, это было семейство generic-интерфейсов со многими типами. Что-то вроде IInterface(T1), IInterface(T1,T2) и так далее, пока не надоест.
Несколько итераций я эти наезды игнорировал, но AI не унимались. Уже и оценки до 9/10 дошли, но проблема-то осталась.
Вспылил и написал письмо на полстраницы, начинавшееся фразой "Господа AI !". Концептуальное. Гневное. Циркулярное И получил ответы:
- ООО! Мы все поняли. Гениально, единственно верное решение.
Это deepseek 5/5 и copilot 10/10.
- Нуу... Проблема решена, но способ так себе... в общем 9/10 и есть гораздо лучшие альтернативы, рассмотрим?
Это chatcpt и grok. И что характерно, альтернативы предлагают разные, по паре штук каждый. Рассмотрим, конечно.

Это просто зарисовка не о разработке обертки, а о различных системах AI.

UPD: Забыл добавить - deepseek еще и извинился за необоснованные оценки :)))

Я давний пользователь Geeknote - это cli для Evernote. Несколько лет назад проект застрял на втором Питоне - и никто не хотел его портировать на третий. Я ждал что кто-то займётся этим - но пришлось самому - так что я форкнул, починил, и даже связался с Виталием Роденко - одним из создателей Geeknote и администратора на PyPI, чтобы получить право туда пушить. За десяток лет я видел как Geeknote переходил из одни руки в другие - и как он забрасывался, и через несколько лет находился новый мантейнер. Было забавно осознать, что теперь и я стал мантейнером программного продукта, который всегда установлен на все мои машины.

Как и большинство из нас, я стал пробовать LLM - как замену поиску, для анализа кодов, советов, и вот наконец - несколько проектов - даже не читая кода - только давая команды и тестируя результат. Известная шутка - переписать на Rust. Почему бы у нет - Geeknote не велик - около пяти тысяч строк на Питоне, что я и попробовал - через Codex gpt-5.5. Несколько десятков итераций, "добавь это", "добавь то", "пропали теги", "пропала анимация" - и за несколько часов я получил рабочий Geeknote на Rust, назвал его reeknote.

Результат: быстрее работает, раза в два. Теперь буду им пользоваться.

P.S.: CLI хороши для перфоманса, SSH, быстрее разработка без GUI, а ещё похоже и для LLM - можно попросить сохранить ответ в Evernote. Как и прочие интеграции, в том числе в скриптах.

Дорожная карта Agentic AI. Level 4. Новые чувства — мультимодальность

Пора научить агента видеть и слышать. Клиент не присылает аккуратный промпт — он кидает фотку накладной, скрин ошибки, голосовое на 40 секунд.

Картинки

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

Где выбирать модель: artificialanalysis.ai/evaluations/mmmu-pro — 180+ моделей по MMMU-Pro (изображения, документы, диаграммы, схемы). Сейчас лидирует Gemini 3.1 Pro Preview.

Транскрибация

Модель слушает аудио и возвращает текст — с пунктуацией, языком, таймкодами, и если надо — с разделением по спикерам.

Где выбирать: artificialanalysis.ai/speech-to-text — 50+ провайдеров, WER + скорость + цена в одной таблице. Лидер по точности — ElevenLabs Scribe v2 (2.3% WER), из мультимодальных — Gemini (2.9%), gpt-4o-transcribe — 4.1%, Whisper large-v3 — ~5%.

Видео

Модель понимает видео как поток событий во времени — что происходило, в каком порядке, что изменилось. Это не то же самое, что покадровый Vision: там вы нарезаете файл на картинки и отправляете как набор фото — модель не понимает движения и временной связи между ними.

Где выбирать: benchlm.ai/benchmarks/videoMmmu. Нативно видео обрабатывает только Gemini — до часа или ссылка на YouTube. Остальные — только покадровый Vision.

Как вызывать

Картинки — универсальный OpenAI-формат, работает везде. image_url в чат-запросе принимают OpenAI, Anthropic, Gemini, Qwen, Grok. Один и тот же код, разный base_url и api_key.

Транскрибация — многие провайдеры поддерживают OpenAI-формат: напрямую /v1/audio/transcriptions или input_audio через /v1/chat/completions). Но у лидера ElevenLabs Scribe v2: собственный SDK, не совместим с OpenAI-форматом

Видео — тут единого API нет. У OpenAI видеофайл в Chat Completions не принимается. Gemini поддерживает видео-понимание через нативный API.

🔔 Следующая тема: локальный запуск — когда Ollama или LMStudio лучше облачного API.

⬅️ Предыдущая тема: Level 3. Первые артефакты — LLM API и структурированный вывод

Подписывайтесь, пожалуйста, чтобы не пропустить!

Больше про ИИ — в ТГ-канале и ВК. Каталог наших курсов, услуг и кейсов по ИИ-агентам. По вопросам — пишите в личку.

Вайб-кодинг и Jmix

Сидели мы как-то вечером с Курсором и подумали:

"Какой же энтерпрайз проект без пасхалки или просто встроенной игры? — Чем будут заниматься менеджеры, пока агенты делают их работу?" — Вот, держите старый добрый Сапер из Windows в виде адд-она Jmix. И это не просто браузерная игра, вставленная в экран. Причем ни строчки кода не написано руками, только сгенерил проект.

Минное поле — это gridLayout, покрытый кнопками, генерится программно в зависимости от параметров.

Весь look&feel как в оригинальном Minesweeper.

Опубликован на Maven, просто добавляйте зависимость:

implementation 'io.github.digitilius.minesweeper:minesweeper-starter:1.0.3'

Репозиторий здесь:

https://github.com/digitilius/jmix-minesweeper

Enjoy'те!

РБПО по ГОСТ Р 56939—2024: вебинар №09 из 30 – Экспертиза исходного кода

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.9. – "Экспертиза исходного кода". На YouTube. Слайды.

Цели девятого процесса по ГОСТ Р 56939—2024:

Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

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

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

Это применимо к подсистемам: двигатель, коробка передач в автомобиле, каталог или система заказов в e-com.

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

К чему эта мысль?

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

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

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

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

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

И ты, leetcode?

Вы заметили, что теперь на leetcode необходимо указать номер телефона для "обеспечения безопасности учётной записи и подтверждения личности":

Add your phone number to secure your account and verify your identity.

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

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

Что думаете? Не давать плюсовать комменты -- это, на мой взгляд, перебор.

📝 Анонс бесплатных открытых уроков на неделю: 27–30 апреля

Привет, коллеги! Традиционная подборка открытых онлайн‑мероприятий для тех, кто хочет прокачать скиллы в IT, управлении, аналитике и автоматизации. На этой неделе — фокус на архитектуру, тестирование, Computer Vision и внутреннюю кухню разработки. Всё бесплатно, но нужна регистрация.

📅 Расписание по дням

_{Понедельник, 27 апреля}

• 20:00 — «Рисуем в формате онлайн модель процесса BPMN в Camunda Modeler»

• 20:00 — «Настройка кластера Elasticsearch»

_{Вторник, 28 апреля}

• 20:00 — «Коучинговые инструменты для мотивации и повышения продуктивности команды»

• 20:00 — «Архитектура ИИ врагов в играх на Unity»

• 20:00 — «Первый нагрузочный тест в Apache JMeter»

• 20:00 — «Архитектура тестового фреймворка: от хаоса к стабильности»

• 20:00 — «Контрактные тесты в Kotlin: как подружить фронт и бэкэнд»

• 20:00 — «Фоновые задачи в Django: работа с Celery»

• 20:00 — «Как работают современные модели компьютерного зрения „из коробки“ на базе популярных библиотек и фреймворков (Hugging Face, OpenCV, YOLO, Roboflow)»

• 20:00 — «Почему только 5% компаний получили реальную выгоду от ИИ в 2025 году?»

_{Среда, 29 апреля}

• 20:00 — «Деревья решений для задач классификации и регрессии»

• 20:00 — «Свой язык на PHP за 60 минут»

• 20:00 — «Трекинг с подвижной камеры: алгоритмы и механика компьютерного зрения на роботах для индустриальных задач»

• 20:00 — «Разрешите себе карьеру технического директора»

• 20:00 — «Качество C#‑кода: от модульных тестов к системному подходу»

• 20:00 — «Продакт‑менеджер, маркетолог и PMM — в чём разница»

_{Четверг, 30 апреля}

• 19:00 — «МОК‑интервью на позицию Руководитель Проектов»

• 19:00 — «От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения»

• 20:00 — «Yahoo Finance и не только — работа с российскими торговыми площадкам»

• 20:00 — «Поиск в базе знаний: где векторы ошибаются, а графы помогают»

• 20:00 — «Как управлять тимлидами?»

• 20:00 — «Битрикс24 + MAX: разработка чат‑ботов и автоматизация коммуникаций» 

• 20:00 — «Планируем внедрение DevSecOps — что следует учесть?»

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

Оптимизация контекста для Claude Code на большом проекте (иногда и 50% экономия токенов)

Работаю над большим C++ проектом - реализация сетевого протокола. Использую Claude Code как основной инструмент. Со временем заметил: каждый новый чат начинается с того, что агент долго читает README.md, который разросся до 1000+ строк и 60 КБ.

Проблема

В CLAUDE.md была прописана команда читать README.md в начале каждого диалога, агенту нужно дать контекст проекта. Пока проект был небольшим это работало нормально. Но README рос вместе с проектом и в итоге стал содержать всё: архитектуру, логику DTLS, настройки веб-интерфейса, описание протокола, инструкции по сборке.

И как результат:

• Агент тратит тысячи токенов на анализ файла до начала работы

• Если задача касается только фронтенда, модель всё равно загружает детали реализации ядра протокола. Лишний контекст снижает точность ответов.

Решение

Вместо одного большого файла использовать иерархию маленьких, в отдельной папке claude-context/:

claude-context/
├── context-claude.md       # общая архитектура и навигация (~90 строк)
├── context-AC-claude.md    # Access Controller
├── context-WTP-claude.md   # WTP Agent
├── context-WEB-claude.md   # Web Interface
└── context-TESTS-claude.md # тесты

Главный файл context-claude.md содержит краткое описание проекта и таблицу-навигатор: какой файл читать для какой области. В дочерних файлах описана детализация по модулям, каждый 100-130 строк.

Инструкция в CLAUDE.md теперь выглядит так:

“Start each new conversation by reading claude-context/context-claude.md. For deeper context on specific areas, read the relevant file from that directory.”

Агент читает главный файл (90 строк), понимает область задачи, подгружает только нужный дочерний контекст.

Замер

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

“Добавь тесты для WtpConfigController и WtpRadioController, проверь что если WTP address не строка, то возникает исключение std::runtime_error”

| Параметр             | README.md (60 КБ) | Иерархический контекст | Разница  |
| :------------------- | :---------------- | :--------------------- | :------- |
| Токены на сообщения  | 36.8k             | 17.6k                  | -53%     |
| Всего токенов        | 56.7k             | 37.6k                  | -34%     |
| Рост usage за задачу | +11%              | +6%                    | В 2 раза |
| Скорость анализа     | Заметная пауза    | Почти мгновенный старт |          |

Важный момент

README.md остался нетронутым - это документация для людей. Файлы в claude-context/ - отдельный артефакт, написанный под AI: плотно, без лирики, с ASCII-схемами и таблицами. Я старался не смешивать два разных назначения в одном файле.

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

ИИ что? Проверяем Semantic Kernel

Проекты, связанные с интеграцией искусственного интеллекта, всё чаще становятся частью повседневной разработки. Один из таких проектов — Semantic Kernel. Он представляет собой SDK для построения AI-агентов и оркестрации LLM-сценариев и активно развивается компанией Microsoft.

Однако под капотом даже самых современных решений скрывается вполне обычный C# код со всеми присущими ему проблемами. Поэтому мы проверили проект и написали статью о самых интересных ошибках в коде Semantic Kernel.

Сделал необычную RTS на Ludum Dare 59 за пару дней

Игра написана на Go (Ebitengine), исходники на есть гитхабе.

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

Я накидал небольшой шаблон для игр на стеке своих геймдев-библиотек. Его можно посмотреть тут: https://github.com/quasilyte/gscene-game-template.

С этим шаблоном старт начала работы над игровой логикой и "мясом" игры становится ближе. Это позволяет +/- выйти на удобство какого-нибудь Godot, где не нужно первые несколько часов настраивать как у нас обрабатывается input, звук и сцены. Я этот шаблон буду дорабатывать по мере участия в джемах, за каждую мини-игру у меня копится TODO на то, что еще там можно было бы улучшить.

Если тема разработки игр на Go вам интересна, заходите в наше русскоязычное сообщество в телеграме. Мы там обсуждаем всякие библиотеки для геймдева, свои игры, и всё такое.

Кстати, ребята из чатика тоже сделали свои игры на Ebitengine, вот они:

• https://dqso.itch.io/hired-or-homeless

• https://metalim.itch.io/zero-day-lunch

MCP - это было очень модно (где-то год назад). Но многие до сих пор не поняли простую вещь: агент с доступом к командной строке может пользоваться любыми CLI-интерфейсами ничуть не хуже.

При этом у классических CLI есть очевидные преимущества:

- Их банально легче разрабатывать

- Они прозрачнее и понятнее в работе

- Применяться они могут не только агентами, но и людьми

- Их уже существует огромное множество под любые задачи

В Google это тоже осознали и выкатили [свой инструмент](https://github.com/googleworkspace/cli). Сделан он явно для агентов (его выпустили только в этом месяце), но это именно CLI, а не очередной MCP-сервер.

Точных фактов по этой теме пока нет. Кто-то говорит, что [в простых задачах MCP требует больше контекста, а в сложных — меньше, чем CLI, если инструменты грамотно обернуты и хорошо обнаруживаются агентом](https://portofcontext.com/blog/cli-vs-mcp-vs-code-mode). Кто-то, что этой разницей можно пренебречь, да и вызвана она тем, что не все CLI адаптированы под экономию контекста. Но все согласны, что CLI может дать агенту доступ ко всем тем же инструментам и обеспечить одинаковый процент успеха при выполнении задач, при этом будучи куда понятнее для человека и значительно проще в написании и поддержке.

В моих проектах я буду использовать CLI.

Бэкенд «тормозит», API ломаются, а архитектура трещит: уроки, которые помогают закрыть эти проблемы

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

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

• 22 апреля 20:00. Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript

• 22 апреля 20:00. Symfony Workflow: конечный автомат для реализации бизнес-логики

• 23 апреля 20:00. Многопоточность в C++: как писать быстрые и безопасные приложения

• 23 апреля 20:00. Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

• 28 апреля 20:00. Фоновые задачи в Django: работа с Celery

• 30 апреля 20:00. Поиск в базе знаний: где векторы ошибаются, а графы помогают

• 4 мая 20:00. Интерфейсы в Golang изнутри

• 5 мая 20:00. Postgres + JSON: реляционная мощь, документная гибкость

• 5 мая 20:00. Архитектурные решения в бэкенд-разработке

• 6 мая 19:00. Разработка проекта на Kotlin: коллаборация человека, архитектурных шаблонов и ИИ-команды

• 6 мая 20:00. Rust в деле: пишем многопользовательский чат с сервером, клиентом и CLI

• 7 мая 20:00. От кода до Kubernetes за полтора часа

• 7 мая 20:00. Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS

• 13 мая 20:00. Kafka Streams DSL

• 13 мая 20:00. ClickHouse для аналитики больших данных: практические кейсы и связь с NoSQL-экосистемой

• 14 мая 20:00. Взаимодействие с базой данных и миграции на Go

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

Как разработчикам монетизировать свои игры в 2026?

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

Традиционный подход подразумевает, что разработчик заключает договор с площадкой (Steam, VK Play, Itch и т.д.). Игрок покупает игру, и деньги идут на счёт платформы. После этого в определенные даты происходит выплаты на счета разработчиков за вычетом комиссий. Где-то больше, где-то меньше, где-то по-другому. Но смысл тот же. Этот подход позволяет, во-первых, брать комиссии, во-вторых, легче работать с возвратами и в-третьих, быстрее распознавать отмывание денег и мошенничество.

Мы решили использовать схему маркетплейсов, где каждый разработчик приходит со своим статусом (ООО, ИП, смз). Но приходит он в первую очередь не к нам, а к платёжным агрегаторам типа Юкасса, Робокасса, любая …касса. Одним словом, подключает себе интернет-эквайринг, такое делает любой банк. Банк ему даёт API для подключения, ID магазина, ключи для проведения оплат и всё, действуй.

Где здесь мы? Мы предоставляем бесплатный хостинг для игр. Сама площадка + страница игры + страница разработчика. Всё тоже самое что у itch[.]io. Заодно есть консоль разработчика, в которую добавляется всё больше и больше возможностей. Соответственно, в этой консоли разработчик указывает тот самый идентификатор магазина, суперсекретный ключ и дальше надеется на магию.

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

Опережу (почти) все вопросы и сразу отвечу:

Q: На что вы будете существовать если у вас комиссии 0%?

A: При покупке игры рядом есть еще кнопочка “поддержать платформу”, надеемся, что это сработает

Q: Вы делаете очередного убийцу стима?

A: Нет

Q: Это точно не развод?

A: Точно нет, чесслово

На остальные вопросы обязательно ответим. Так как это не реклама, то прямо указывать название площадки не буду, но подскажу, что наш канал https://t.me/dustore_official

Переосмысление библиотеки LDL.

Я полностью пересмотрел концепцию библиотеки LDL.

Что такое LDL?
Это графическая библиотека с единым API для всех систем как старых, так и новых.

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

Новая стратегия

Я решил выпускать релизы без реализации полного функционала (графика, звук, шрифты и т.д.) постепенно, итеративно.

• Перешёл на C89 для максимальной переносимости. Это не только DOS или Windows 3.x, но и старые системы вроде Solaris, PlayStation 1 и другие.

• Для первого релиза реализую минимальный базовый функционал: графику (OpenGL, Vulkan), окна и события. По возможностям аналог GLFW.

• С каждым следующим релизом буду добавлять: 2D-рендер, звук, шрифты и прочее.

Лицензия и целевые платформы

• Лицензия меняется на LGPLv3.

• На старте поддерживаются Windows и Linux.

Качество и инструменты

При разработке использую:

• AddressSanitizer (ASan)

• UndefinedBehaviorSanitizer (UBSan)

• Различные анализаторы кода

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

Примеры и бэкенды

• Добавлю десятки примеров с OpenGL 1.x, OpenGL 3.x и Vulkan.

• Буду добавлять бэкенды для LDL: не только под ОС, но и поверх других графических библиотек — SDL, SFML, GLFW и т.д.

• API остаётся единым для всех бэкендов.

Это позволит сразу добавить поддержку звука и шрифтов (через бэкенды), а в нативных версиях реализовывать их позже.

 2D-рендер без границ

Одной из главных задач LDL я вижу создание единого 2D-интерфейса, который стирает различия между поколениями графики.

Вам не нужно думать о том, что находится в системе: современная видеокарта с Vulkan, старый ускоритель с OpenGL 1.2 или вообще только центральный процессор (Software Rendering).

• Единый интерфейс: Вы используете одни и те же команды для рисования пикселей, линий и спрайтов.

• Адаптивность: LDL сам выберет наиболее эффективный способ вывода изображения. На современной системе это будет аппаратное ускорение, а на «железе» без видеокарты оптимизированный программный растеризатор.

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

Философия: Машина времени в вашем коде

Зачем тратить силы на поддержку систем, которые многие считают «трупами»?

1. Борьба с цифровым забвением

Современный софт живет 3–5 лет. Мы выбрасываем железо не потому, что оно сломалось, а потому, что софт стал слишком тяжелым и ленивым. LDL — это протест против «запланированного устаревания». Я хочу, чтобы код, написанный сегодня, мог дышать в железе любой эпохи.

2. Инженерный аскетизм

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

3. Преемственность поколений

Мы стоим на плечах гигантов, но часто забываем их имена. LDL сохраняет возможность для диалога между эпохами. Это инструмент, который позволяет современному разработчику почувствовать «металл» старых машин, не теряя связи с современными технологиями вроде Vulkan.

Итог

LDL — это Little Directmedia Layer. Он маленький не потому, что слабый, а потому, что в нем нет ничего лишнего. Это попытка создать код, который будет принадлежать не конкретной версии ОС, а истории программирования в целом.

Один API. Один код. Тридцать лет компьютерной истории.

30 беплатных уроков недели: AI, Spark 4.0, C++, REST API, Angular и Linux

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

20 апреля, понедельник:

• 20:00. Unit-тесты для iOS приложений, работаем над качеством изнутри

• 20:00. Качество данных (data quality) на практике: от технических метрик до внедрения в команде

• 20:00. От интерфейса до корзины: создаём мини интернет-магазин на языке JavaScript

• 20:00. Эффекты в Scala

• 20:00. Балансировка и геораспределение: как создать быстрое и надёжное приложение для всего мира

• 20:00. Менеджер в перегрузе: как выжить и не выгореть

21 апреля, вторник:

• 19:00. BPMN для 1С: Как правильно моделировать интеграции? (Разбираем 4 уровня детализации)

• 19:00. Значение корпоративной архитектуры для реализации стратегии цифровой трансформации

• 20:00. Функции в SQL: вычисления и переиспользование кода

• 20:00. Оптимизация запросов 1С

• 20:00. Архитектура мониторинга ИБ инфраструктуры на SIEM

• 20:00. Производительность кода на примере алгоритмов сортировки

• 20:00. Как BPMN помогает видеть узкие места

• 20:00. Архитектура Angular-приложения: как писать масштабируемый frontend

• 20:00. Связанные списки в ядре Linux: от API до реального кода

• 20:00. Использование BGP для маршрутизации IPv6

22 апреля, среда:

• 19:00. Основы балансировки нагрузки в Angie и Nginx

• 20:00. Бизнес-процессы CRM. Стандартные активити CRM

• 20:00. Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript (Bun — современная среда выполнения JavaScript; ИИ — искусственный интеллект)

• 20:00. Symfony Workflow: конечный автомат для реализации бизнес-логики

• 20:00. Делегирование без боли: как перестать быть “главным исполнителем” и не скатиться в микроменеджмент

• 20:00. Программируемые реле в АСУ ТП: гибкий инструмент для решения инженерных задач

• 20:00. Создание нейро-сотрудника на базе Telegram-бота и GPT: от регистрации до рабочего прототипа

23 апреля, четверг:

• 18:00. Cоздаём ИИ-ассистента для системного аналитика за 1 час

• 19:00. Интегрируем EDT в процессы непрерывной интеграции. Подключаем 1С к CI/CD

• 20:00. Что нового в Spark 4.0

• 20:00. Многопоточность в C++: как писать быстрые и безопасные приложения

• 20:00. Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

27 апреля, понедельник:

• 20:00. Рисуем в формате онлайн модель процесса BPMN в Camunda Modeler

• 20:00. Настройка кластера Elasticsearch

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

Пока везут в Zed нативный diff выделенных кусков кода, с подсветкой, преферансом и барышнями, мы будем пить то, что есть 😁

Скрипт намбер ван:

#!/bin/bash

FILE1="/tmp/clp.saved"

# xclip -o -selection primary > "$FILE1"
wl-paste --primary > "$FILE1"
notify-send "Diff" "Первый фрагмент сохранён"

вешаем на одно сочетание клавиш (у меня, например, для удобства, Alt+Shift+1)
(выбираем на вкус для X11 или Wayland)

Скрипт намбер ту:

#!/bin/bash

FILE1="/tmp/clp.saved"
FILE2=$(mktemp /tmp/clp.XXXXXX)

trap 'rm -f "$FILE2"' EXIT

# xclip -o -selection primary > "$FILE2"
wl-paste --primary > "$FILE2"

if [ ! -s "$FILE1" ] || [ ! -s "$FILE2" ]; then
	notify-send "Ошибка" "Нет текста для сравнения"
	exit 1
fi

meld "$FILE1" "$FILE2"

вешаем на другое сочетание клавиш (у меня, например, Alt+Shift+2)

Изолента и реактивный двигатель — вот всё, что нам нужно. Лучше, чем ничего, по крайней мере…
Первый скрипт сохраняет выделенный текст во временный файл /tmp/clp.saved.
Второй скрипт сохраняет выделенный текст в другой временный файл /tmp/clp.XXXXXX, открывает их оба в нашем любимом Meld, мы на всё это дело любуемся, сравниваем, закрываем Meld, после чего скрипт удаляет этот второй временный файл со случайным постфиксом, чтобы не болтался зря. Первый, /tmp/clp.saved пока остаётся, чтобы было удобно с одним и тем же «первовыделенным» сравнивать несколько вариантов, и его всегда можно переопределить первым скриптом.

Итого: Выделили кусок, Alt+Shift+1, выделили другой кусок, Alt+Shift+2 — смотрим, радуемся! 😁

Как устроен компилятор?

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

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

Дорожная карта Agentic AI. Level 3. Первые артефакты — LLM API и структурированный вывод

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

— А куда обращаться? — спросите вы.

Есть несколько вариантов.

1. Первый — на серверы производителей: старым добрым ChatGPT, DeepSeek, Gemini, Qwen.

2. Второй — к хабам опенсорс-моделей, например HuggingFace.

3. Третий — к провайдерам-агрегаторам, которые предоставляют и то и другое: Openrouter, Together, Fireworks.

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

Но, к счастью, OpenAI был впереди планеты всей, и его формат стал стандартом де-факто.

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

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

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

📚 Материалы

• Наш видео-туториал по OpenAI API

• OpenAI Quickstart · Python SDK · Streaming

• HuggingFace Inference API

• Openrouter Quickstart · Together AI · Fireworks AI

🔔 Следующая тема: мультимодальность — голос, изображения, видео.

⬅️ Предыдущая тема: Level 2. AI-driven разработка

Подписывайтесь, пожалуйста, чтобы не пропустить!

Наши курсы по ИИ-агентам. По вопросам — пишите мне.

13 демо-уроков апреля для разработчиков: от REST API и SQL до Bun, C++ и микросервисов

Привет, Хабр. Эти уроки проведут преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Участие бесплатное. Присоединяйтесь!

15 апреля, среда:

• 18:00 — Основы протокола HTTP

• 20:00 — OpenAPI + Spring

• 20:00 — Локализация текстов в Symfony: от статических переводов к динамическим данным из базы

• 20:00 — Основы проектирования бизнес-логики в микросервисной архитектуре

16 апреля, четверг:

• 20:00 — Облегчённые (Slim) примитивы синхронизации

• 20:00 — Архитектура ИИ-сервисов для High-Load и Low-Latency инференса

21 апреля, вторник:

• 20:00 — Функции в SQL: вычисления и переиспользование кода

• 20:00 — Производительность кода на примере алгоритмов сортировки

22 апреля, среда:

• 20:00 — Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript (Bun — современная среда выполнения JavaScript; ИИ — искусственный интеллект)

• 20:00 — Symfony Workflow: конечный автомат для реализации бизнес-логики

23 апреля, четверг:

• 20:00 — Многопоточность в C++: как писать быстрые и безопасные приложения

• 20:00 — Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

29 апреля, среда:

• 20:00 — PHP-разработчик. Продвинутый уровень

Как научиться печатать вслепую за час.

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

Способ обучения состоит из трех шагов.

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

ЙЦУ КЕНГуру ШЩаЗ ХЪ

ФЫВА ПРО ЛоДЖЭя

мЯЧ СМИТ ЬБьЮ,

в которых нужно пропускать строчные буквы.

Для запоминания английской раскладки запомните три последовательности

Q WERTY U I OP!

AS DFGHiJKL

ZXCVBNM,.

Второй шаг. Располагаем кисти так, чтобы указательные пальцы опирались на клавиши с бугорками - А и О. Печатаем на ощупь в течении получаса. Если у вас нет своего текста, можно воспользоваться Гонками на клавиатуре https://www.google.com/search?q=гонки+на+клавиатуре. При этом если расположение буквы уже запомнилось, то нажимаем ее правильным пальцем. Если расположение клавиши не запомнилось, то, не глядя на клавиатуру, ощупываем слева на право клавиши в нужном ряду, пока не найдем искомую букву. Например, для нажатия буквы Т ощупываем мизинцем левой руки букву Я, безымянным - букву Ч, средним - С, указательным левой - М, указательным левой руки - букву И, указательным правой руки - букву Т.

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

По необходимости повторяем предыдущие шаги.

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

Пятничный пост. Рубрика - узнай себя и что было дальше?

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

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

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

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

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

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

— Ну, так… форма же уже работает. Это простое отображение ошибок. Бизнес хочет, чтобы в конце недели это было на проде. Ок…? — закончил вопросом-утверждением Виталий.

— Ок… — зачем-то ответил я. «Б…!!! Зачем я это сказал?!» — тут же промелькнуло у меня в голове, и две половинки моего тела чуть ниже спины нервно сжались в предвкушении нюансов…

Кого узнали и что было дальше?

Дорожная карта Agentic AI. Level 2. Ускорение — AI-driven development

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

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

Для начала ознакомьтесь с разнообразием инструментов:

• Онлайн-прототипирование: V0, Bolt, Lovable, Replit

• Консольные агенты: Claude Code, Codex CLI, Gemini CLI, Warp

• AI-coding IDE: Cursor, Windsurf

• Spec-Driven IDE: Kiro, Qoder

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

Три вещи, которые я настраиваю первым делом:

• Skills — для меня это самый мощный и пока сильно недооценённый инструмент. Скилл — инструкция-специалист: агент читает SKILL.md и получает роль, знания и алгоритм. Аналитик, архитектор, тестировщик, DevOps — можно собрать целую команду специалистов под проект. Формат уже стал кросс-платформенным — один SKILL.md работает в Cursor, Claude Code и Codex.

• Rules — постоянные инструкции: стиль кода, архитектурные решения, запреты.

• MCP — подключение внешних инструментов и актуальной документации. Попробуйте начать с MCP Context7.

Крайне рекомендую изучить Spec-Driven методологию и лучшие практики работы с кодовыми агентами от Anthropic.

На выходе с этого уровня у вас будет персональный кодовый ИИ-агент, который берёт рутину на себя, а вы фокусируетесь на архитектуре.

📚 Наши материалы

• Умный вайб-кодинг

• 300 дней с AI-агентами

• Лучшие практики от Cursor

• Третья эпоха AI-разработки

• Видео: AI-driven разработка · Qoder · Claude Code · Gemini CLI

🔔 Следующая тема: работа с LLM API.

⬅️ Предыдущая тема: Level 1. Основы LLM и промпт-инжиниринг

Подписывайтесь, пожалуйста, чтобы не пропустить!

🎓 Приглашаем на бесплатный мастер-класс
📅 13 апреля, пнд 16:00 МСК — AI-driven практикум «ИИ-агент с нуля за один эфир»
👉 Записывайтесь в наших ботах: Telegram или ВКонтакте

Наши курсы по ИИ-кодингу ИИ-агентов. По вопросам — пишите мне.

Подключайся ко второму онлайн-митапу MWS для Python-разработчиков 🎙️

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

Будет интересно Python-разработчикам, аналитикам и другим ИТ-специалистам, кто интересуется применением ИИ в разработке.

• 📅 Когда: 15 апреля (среда) в 15:00 по мск

• 📍 Где: онлайн 

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

Дорожная карта Agentic AI. Level 1. Основы LLM и промпт-инжиниринг

Начну нашу дорожную карту Agentic AI с языковых моделей.

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

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

• параметры моделей и основные термины (размер, веса, токены, контекстное окно, галлюцинации),

• способы оптимизации (квантизация, прунинг, дистилляция),

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

Главное — практиковаться. Я взял себе за правило: каждую задачу сначала через ИИ. Пишу код? Промпт. Анализирую данные? Промпт. Пишу письмо? Промпт. Делаю презентацию? Промпт.

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

Изучите гайды, пробуйте разные модели, начните с топовых: ChatGPT, Claude, Gemini, DeepSeek, Qwen. Отечественные: YandexGPT, GigaChat.

Прокачайте насмотренность, набейте руку, пройдите по аренам, лидербордам, бенчмаркам — научитесь понимать, в чём одни модели сильнее других.

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

📚 Материалы

• Как работают LLM: Prompting Guide, визуализации — LLM Visualizer и Transformer Explainer, наш плейлист с объяснениями основ.

• Промпт-инжиниринг от вендоров: OpenAI Cookbook, Anthropic Prompt Engineering, Claude 4 best practices.

• Выбор модели: видео-гайд, лидерборды — LM Arena, LLM Arena RU, SWE-bench. Хаб моделей: Hugging Face.

🔔 Следующая тема: AI-driven разработка — как грамотно ускорять разработку в X раз.

⬅️ Предыдущая тема: Дорожная карта Agentic AI. Интро

Подписывайтесь, пожалуйста, чтобы не пропустить!

🎓 Бесплатные мероприятия на этой неделе

• 📅 9 апреля, чт 18:00 — Онлайн-разбор продакшен-кейса «ИИ-агент консультанта 1С»

• 📅 13 апреля, пнд 16:00 — AI-driven практикум «ИИ-агент с нуля за один эфир»

👉 Записывайтесь на мероприятия в наших ботах: Telegram или ВКонтакте

Ознакомьтесь с нашей траекторией роста по AI-driven разработке и ИИ-агентам.

ИИ-код и линтеры: статический анализ проекта на 85 000 строк

ruff (Python) — 73 замечания на 63 000 строк. 1.2 на 1000 строк.

Состав: 39 неиспользуемых импортов, 17 неиспользуемых переменных, 6 forward references, 5 f-строк без подстановок, 5 лямбд вместо def. Ноль ошибок, от которых код падает в рантайме.

ESLint (React/TypeScript) — 0 ошибок, 5 warnings на 21 000 строк. Все пять — рекомендация Next.js использовать <Image> вместо <img>.

Для сравнения:
- Зрелый проект с CI-линтингом — 0–2 замечания на 1000 строк.
- Без линтинга — 5–15.
- Легаси — 20–50.

У нас 1.2 и 0.24, при том что CI-линтинга в проекте нет. Claude и Codex запускают ruff и eslint сами на каждое изменение — я вижу это в логах. Результат соответствующий.

Безопасность

ruff и ESLint проверяют стиль, не безопасность. По совету из комментариев прогнал bandit — security-сканер для Python.

1 432 находки. Реальных уязвимостей: 0.

• 2 HIGH — SHA1 для fingerprint'а шахматных партий. Это не криптография, а генерация коротких ID для внутренней классификации. Подделывать бессмысленно.

• 5 MEDIUM «SQL injection» — bandit видит f-string в SQL-запросе и сигнализирует. Но внутри f-string стоят только ?-плейсхолдеры, данные идут параметрами. Классическая параметризация, инъекция невозможна.

• 4 MEDIUM «url open» — HTTP-клиенты Lichess, Chess.com, OpenRouter. URL из конфига, пользователь не контролирует.

• 1 421 LOW — 1 250 assert'ов (bandit предупреждает, что assert удаляется при запуске с -O, но Django и Celery никто так не запускает), остальное — try/except/pass в опциональных ветках.

Фронтенду отдельный security-сканер не нужен: React экранирует HTML автоматически, dangerouslySetInnerHTML не используется, фронт не работает с БД, файлами и процессами.

85 000 строк, три сканера, ноль реальных уязвимостей. ИИ-код не нуждается в оправданиях — он нуждается в проверке. Проверили. Чисто.

p.s. Проверку проходил код из статьи Вайбкодинг по Chess’ноку. 1. e4

Как за 11 лет разучиться дебажить: когнитивная атрофия от AI-инструментов

На Reddit разработчик с 11-летним стажем описал тревожный момент: он не смог отладить баг в собственном коде без Claude. Не потому что баг сложный, а потому что разучился генерировать гипотезы самостоятельно.

Что произошло

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

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

Баг он в итоге нашёл. Но медленнее, чем три года назад, когда AI ещё не использовал.

Почему это не про «AI плохой»

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

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

Классический пример — GPS-навигация. Исследование в Nature Communications (2017) показало: люди, которые постоянно ездят по навигатору, хуже справляются с задачами пространственной ориентации, чем те, кто периодически строит маршруты сами.

Где это ломается у разработчиков

На практике выделяются три зоны риска:

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

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

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

Контраргумент: а Stack Overflow?

Частое возражение: разработчики годами копировали решения с Stack Overflow и не деградировали.

Разница в модели взаимодействия:

1. Нужно сформулировать проблему

2. Найти релевантный ответ

3. Адаптировать решение под свой контекст

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

Что делать: практические подходы

Правило 5 минут
Перед тем как открыть Claude, потратить 5 минут на самостоятельный анализ stack trace. Это простой способ «включить» мышление.

Unplugged-сессии
Периодически дебажить без AI. Например, один час в неделю. Это не ограничение, а тренировка.

Приходить с гипотезами
Разница между джуном и сеньором в работе с AI: джун ждёт решение, сеньор приносит несколько гипотез и использует AI как инструмент проверки.

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

Честно

Я не демонизирую AI-инструменты. Сам использую ежедневно. Но когнитивная атрофия — реальный риск, который стоит учитывать.

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

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

Если кто-то вдруг использует мой Licensedog для сбора информации о техстеке.

С сегодняшним обновлением, оно успешно разыскало в интернете и проверило все 5546 зависимости одного из наших проектов, кроме 4 мусорных внутренних библиотек.

Научил работать с Java (раньше были только Python, JS и Go). Починил целую пачку багов.

Это такой краулер, который принимает на вход SBOM (в виде CSV или cyclonedx) и потом сомневается в нем: старается обойти интернет, и на самом деле физически найти файлы с лицензиями. Выкачать их репозиториев, распаковать из архивов, или даже открыть в барузере их сайты и распарсить веб-странички. И фактически проверить на соответствие. В отчете описывает, что и откуда взялось, и почему она думает что лицензия на самом деле не MIT а GPL. На выходе получается CSV или JSONL файл, который можно отгружать безопасникам на ревью.

Исходники - как всегда, на GitVerse.

https://gitverse.ru/anarchic/licensedog

Дорожная карта Agentic AI: от основ до production-ready агентных систем

Друзья, я решил в апреле разобрать горящую тему этого года - что надо знать и уметь для разработки production-ready ИИ-агентов.

По сути, это будет своеобразная дорожная карта Agentic AI Engineering — по этапам, от основ до зрелых систем.

Я буду выкладывать небольшие посты с раскрытием важных тем и ссылками на полезные материалы.

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

• Основы языковых моделей и промпт-инжиниринг,

• Работа с LLM API и структурированный вывод,

• AI-driven разработка с ИИ-агентами,

• Мультимодальность — голос, изображения,

• Local inference — локальный запуск моделей,

• RAG — как передать агенту знания о вашем бизнесе,

• Agents — агенты с памятью, инструментами и планированием,

• MCP — стандарт интеграции агентов с внешними системами,

• Observability & Evaluation — мониторинг и оценка качества RAG-систем и агентов,

• Security & Guards — безопасность агентных систем,

• Управление датасетами и промптами,

• Сontext-engineering — работа с большим контекстом,

• Skills — навыки агентов,

• Agent harness — решение сложных задач, субагенты и планирование,

• Multi-agents — мультиагентные системы.

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

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

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

🔔 Следующий пост: основы языковых моделей — с чего всё начинается.

Больше про ИИ-кодинг и ИИ-агентов в ТГ и ВК.
Приглашаю ознакомиться с нашими онлайн-курсами по ИИ-разработке ИИ-агентов.

Разработчик Александр Гомес Гайгалас (Alexandre Gomes Gaigalas), автор библиотеки coral для создания переносимых shell-скриптов, опубликовал проект C89cc.sh. Это компилятор для языка C, написанный целиком на Shell.

Компилятор поддерживает стандарт C89 и может генерировать исполняемые файлы в формате ELF64 для систем x86-64. Исходный код проекта содержит около восьми тысяч строк и открыт под лицензией ISC.

Будет слишком по девчачьи сказать, что я плакала из-за код ревью?

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

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

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

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

Мне захотелось поделиться своими мыслями на тему код-ревью, о том как формулировки влияют на скорость работы и состояния людей:

Ссылка на статью

Если хоть раз сидел и думал: «что от меня тут вообще хотят?» — ты точно поймёшь :)

Как делать бизнес-процессы как в n8n — безопасно и масштабируемо? Узнаете на конференции GoCloud 2026 ☁️

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

Спикер: Владислав Янковский — старший Go-разработчик, Cloud.ru

Трек: Прикладной ИИ

📅 Когда: 9 апреля в 16:40–17:00 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: NoCode инструменты для создания AI-приложений с RAG: быстрый старт

Cursor или Harvi Code: какой ИИ для кодинга в 2026 году реально работает в России без VPN и головной боли с платежами

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

Cursor — это сейчас, пожалуй, самый продвинутый AI-редактор на рынке. По сути, это VS Code, в который встроили настоящий искусственный интеллект на стероидах. Composer позволяет одной командой править сразу десяток файлов, агент понимает весь проект, хорошо справляется с рефакторингом, поиском багов и даже архитектурными решениями. Качество кода от Claude Sonnet 4.5 или свежих GPT часто вызывает искреннее «вау».

Но есть большая ложка дёгтя. Cursor — американский продукт, и российские карты он не принимает. Чтобы купить подписку Pro, приходится либо использовать виртуальные карты через крипту, либо платить посредникам (Oplatym и подобные), либо покупать готовые аккаунты (что рискованно). Сам редактор после оплаты работает без VPN, но первоначальная настройка оплаты — это отдельный квест. Бесплатная версия быстро упирается в лимиты, особенно если активно юзаешь мощные модели.

Harvi Code — Первый в России AI кодинг-агент. Российский ответ на все эти заморочки. Это полноценный AI-агент прямо внутри VS Code. Пишешь задачу в чате — он генерит код, рефакторит, фиксит баги, работает с контекстом всего проекта. Не тормозит, контекст держит хорошо, интерфейс привычный.

Самое приятное — модели на любой бюджет. Есть топовые (Claude Sonnet 4.5, GPT-5.4 и другие). А главное — очень низкая стоимость токенов. Для каждой модели есть свой коэффициент стоимости. Для большинства повседневных задач их хватает с головой, и можно вообще почти не тратить деньги. Оплата — российскими картами или СБП, без всяких посредников и VPN.

Коротко по делу:

• Если тебе нужен мощный multi-file agent и ты готов один раз настроить оплату через проверенного посредника — бери Cursor. Он до сих пор в топе по возможностям.

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

А вы как сейчас кодите с ИИ? Пробовали оба варианта? Что в итоге оставили в основном редакторе? Пишите в комментариях, интересно почитать реальный опыт.