РБПО по ГОСТ Р 56939—2024: вебинар №11 из 30 – Динамический анализ кода программы
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Обнаружение недостатков и уязвимостей в коде ПО в процессе его выполнения.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Дорожная карта Agentic AI. Level 4. Мастер примеров — few-shot и structured output
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 и векторные базы — как передать агенту знания о вашем бизнесе.
Представление каталога. Фильтр каталога заменили на представления — функция вышла из экспериментального режима. Теперь вместе с фильтрацией статей можно задавать переменные: одна статья показывает разный контент без создания копий.
⚠️ Автомиграции нет. Если был настроен фильтр — добавьте его заново через панель представлений.
Gramax Enterprise Server
Настройка LFS на уровне пространства. LFS-паттерны задаются один раз и применяются ко всем репозиториям. В обычных пространствах настройки по-прежнему задаются в каждом каталоге.
Фильтрация метрик по каталогу. На страницах метрик добавили фильтры: в отчете по просмотрам — по каталогу, пользователям и типу, в отчете по поиску — по каталогу.
Улучшения настройки проверок по стайлгайду:
Правила отображаются таблицей, редактор открывается в боковой панели.
При первом запуске загружается готовый набор правил — можно адаптировать под команду.
Правила можно экспортировать — поделиться или сохранить копию.
Запуск тестов правил доступен для каждого правила.
Общие изменения
Свойства вкладок. Можно назначать свойства каталога — управлять видимостью в разных представлениях. Также обновили внешний вид вкладок.
Сортировка и фильтрация таблиц. Сортировка по нескольким столбцам и фильтрация по значениям. Параметры сохраняются со статьей — удобно для больших таблиц.
Фрагменты вместо сниппетов и ссылки с превью. Сниппеты переименованы во фрагменты. Теперь можно ставить ссылки на фрагменты прямо из текста: при наведении — превью, удобно для глоссария.
Скрытие превью при переводе. В редакторе мультиязычных каталогов появился переключатель Предпросмотр статьи — скрывает превью на основном языке, чтобы сосредоточиться на переводе.
Версионирование в редакторе. Теперь можно переключаться между версиями прямо в редакторе, а не только настраивать их.
Управление локальным кэшем. В настройках каталога на вкладке Память отображается размер кэша Git и LFS — можно очистить вручную, если каталог вырос или синхронизация замедлилась.
Навигация по OpenAPI. Для OpenAPI-спецификаций в правой панели доступна навигация по методам API — можно перейти к нужному без прокрутки.
Улучшения поиска:
Поиск внутри папки ограничен ею по умолчанию. При необходимости переключитесь на По всем каталогам.
Поиск учитывает полный путь в навигации: статью Вклады / До востребования найдете по запросу Вклад до востребования.
Результаты из одной диаграммы объединяются в один блок.
Добавлен пункт (пусто) для статей без значения, пункт (выбрать все) сбрасывает фильтр.
Улучшения и стабилизация:
Перетаскивание статей и разделов в левой панели ускорили в 10 раз.
Если Git-сервер недоступен, приложение переходит в офлайн-режим. Вернется автоматически, когда сервер станет доступен.
Обновили тулбар редактора. Элементы сгруппированы по категориям, списки открываются по клику.
Дорожная карта Agentic AI. Level 4. Своя кузница — локальный запуск моделей
Level 4. Своя кузница — локальный запуск моделей
Не всё имеет смысл отдавать в облако. Причин у этого как минимум три:
Приватность. Стоит начать пересылать в чужой API персональные данные клиентов, внутреннюю переписку или код с коммерческой тайной, как логи стороннего провайдера превращаются из абстрактной строчки в SLA во вполне конкретный риск утечки. Локальная модель эту головную боль снимает: данные просто не покидают периметр компании, и обсуждать с безопасниками становится по сути нечего.
Автономность. Когда провайдер прилёг, сети легли или вашему региону внезапно прикрыли доступ, локальный агент этого даже не заметит и продолжит работать, как ни в чём не бывало.
Стоимость. Здесь всё упирается в масштаб. Если вы просто экспериментируете у себя на ноутбуке, локальный запуск получается полностью бесплатным: ни подписок, ни платы за токены, и докупать ничего не придётся, всё поедет на том железе, что уже стоит на столе. Когда же речь идёт про нагруженный прод, картина меняется: нужен сервер с 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 в агенте и погнали…
Всего лишь иллюстрация. Примерно год-полтора назад решил я выбрать - 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. Новые чувства — мультимодальность
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.
"Какой же энтерпрайз проект без пасхалки или просто встроенной игры? — Чем будут заниматься менеджеры, пока агенты делают их работу?" — Вот, держите старый добрый Сапер из Windows в виде адд-она Jmix. И это не просто браузерная игра, вставленная в экран. Причем ни строчки кода не написано руками, только сгенерил проект.
Минное поле — это gridLayout, покрытый кнопками, генерится программно в зависимости от параметров.
Весь look&feel как в оригинальном Minesweeper.
Опубликован на Maven, просто добавляйте зависимость:
РБПО по ГОСТ Р 56939—2024: вебинар №09 из 30 – Экспертиза исходного кода
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Любая система всегда существует в двух основных контекстах: пользовательском и админском. Есть еще контекст ошибки, но сейчас не про него. Контекст – это не домен, наоборот это часть домена.
Речь не только про разработку и ИТ. Канализация, кран, автомобиль, самокат, футбольный мячик - это применимо к любой системе физического мира.
Это применимо к подсистемам: двигатель, коробка передач в автомобиле, каталог или система заказов в e-com.
Админский контекст имеет интерфейсы и контракты, которые недоступны в пользовательском контексте. Задача админского контекста обеспечить целостность, консистентность настроек системы для корректной и непротиворечивой работы в пользовательском контексте.
К чему эта мысль?
Если для вашей системы внутри одного домена/поддомена нужно 2 админских или пользовательских контекста, то скорее всего у вас проблемы в архитектуре системы. 2 варианта:
разделить домены, создав тем самым два слабосвязанных домена со своими контекстами. Это сделает домены проще, их легче поддерживать.
объединить дублирующиеся контексты. Если объединение возможно, то скорее всего ваша система перейдет на качественно новый уровень, станет более универсальной и гибкой.
Оба варианта приведут к уменьшению когнитивной сложности и устранению скрытых связей.
Не дублируйте контексты для домена, это плохо кончится.
Вы заметили, что теперь на leetcode необходимо указать номер телефона для "обеспечения безопасности учётной записи и подтверждения личности":
Add your phone number to secure your account and verify your identity.
А если не укажете, то не сможете: - участвовать в соревнованиях; - создавать комментарии в дискуссиях; - публиковать решения; - даже плюсовать полезные комментарии.
Я поискал, но сходу не нашёл официальной новости с разъяснениями. Однако, судя по комментам, некоторые пользователи довольны, считая, что эта мера поможет уменьшить количество читеров.
Что думаете? Не давать плюсовать комменты -- это, на мой взгляд, перебор.
📝 Анонс бесплатных открытых уроков на неделю: 27–30 апреля
Привет, коллеги! Традиционная подборка открытых онлайн‑мероприятий для тех, кто хочет прокачать скиллы в IT, управлении, аналитике и автоматизации. На этой неделе — фокус на архитектуру, тестирование, Computer Vision и внутреннюю кухню разработки. Всё бесплатно, но нужна регистрация.
Оптимизация контекста для 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. Он представляет собой SDK для построения AI-агентов и оркестрации LLM-сценариев и активно развивается компанией Microsoft.
Однако под капотом даже самых современных решений скрывается вполне обычный C# код со всеми присущими ему проблемами. Поэтому мы проверили проект и написали статью о самых интересных ошибках в коде Semantic Kernel.
Поиграть можно в браузере, ведь Ebitengine имеет неплохой экспорт в wasm. Она мало весит, быстро работает, и экспорт не требовал лишних усилий - это вам не шуточный игровой движок.
С этим шаблоном старт начала работы над игровой логикой и "мясом" игры становится ближе. Это позволяет +/- выйти на удобство какого-нибудь Godot, где не нужно первые несколько часов настраивать как у нас обрабатывается input, звук и сцены. Я этот шаблон буду дорабатывать по мере участия в джемах, за каждую мини-игру у меня копится TODO на то, что еще там можно было бы улучшить.
Если тема разработки игр на Go вам интересна, заходите в наше русскоязычное сообщество в телеграме. Мы там обсуждаем всякие библиотеки для геймдева, свои игры, и всё такое.
Кстати, ребята из чатика тоже сделали свои игры на Ebitengine, вот они:
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 может дать агенту доступ ко всем тем же инструментам и обеспечить одинаковый процент успеха при выполнении задач, при этом будучи куда понятнее для человека и значительно проще в написании и поддержке.
Бэкенд «тормозит», API ломаются, а архитектура трещит: уроки, которые помогают закрыть эти проблемы
У бэкенд-разработки есть неприятная особенность: большинство сложностей проявляется не в момент, когда пишется первый сервис, а позже — когда API начинает обрастать интеграциями, фоновые задачи конкурируют за ресурсы, поиск и хранилище требуют разных подходов к данным, а архитектурные решения внезапно начинают влиять на скорость разработки не меньше, чем качество кода.
В этой подборке — бесплатные демо-уроки от преподавателей-практиков про те части бэкенда, которые обычно и забирают больше всего времени в реальной работе. Это хороший способ посмотреть на чужой инженерный подход, познакомиться с экспертом, задать вопросы по своей ситуации и заодно закрыть конкретные пробелы: в API, тестировании, нагрузке, инфраструктуре, работе с данными и проектировании систем.
Как разработчикам монетизировать свои игры в 2026?
Всем привет! Хотели похвастаться очередным сложным, но очень важным шагом на пути к возрождению российского геймдева и заодно спросить мнения окружающих (да, мы всегда сначала делаем, потом думаем).
Традиционный подход подразумевает, что разработчик заключает договор с площадкой (Steam, VK Play, Itch и т.д.). Игрок покупает игру, и деньги идут на счёт платформы. После этого в определенные даты происходит выплаты на счета разработчиков за вычетом комиссий. Где-то больше, где-то меньше, где-то по-другому. Но смысл тот же. Этот подход позволяет, во-первых, брать комиссии, во-вторых, легче работать с возвратами и в-третьих, быстрее распознавать отмывание денег и мошенничество.
Мы решили использовать схему маркетплейсов, где каждый разработчик приходит со своим статусом (ООО, ИП, смз). Но приходит он в первую очередь не к нам, а к платёжным агрегаторам типа Юкасса, Робокасса, любая …касса. Одним словом, подключает себе интернет-эквайринг, такое делает любой банк. Банк ему даёт API для подключения, ID магазина, ключи для проведения оплат и всё, действуй.
Где здесь мы? Мы предоставляем бесплатный хостинг для игр. Сама площадка + страница игры + страница разработчика. Всё тоже самое что у itch[.]io. Заодно есть консоль разработчика, в которую добавляется всё больше и больше возможностей. Соответственно, в этой консоли разработчик указывает тот самый идентификатор магазина, суперсекретный ключ и дальше надеется на магию.
Если магия происходит, то наш скрипт подставляет его данные в другой скрипт, только уже от платёжного агрегатора. Игрок видит кнопку обычную кнопку оплаты и оплачивает, после чего денюжки магическим образом летят на счёт разработчика. На этом магия заканчивается, начинается то ли математика, то ли бухгалтерия (я в этом не силён, не шарю).
Опережу (почти) все вопросы и сразу отвечу:
Q: На что вы будете существовать если у вас комиссии 0%?
A: При покупке игры рядом есть еще кнопочка “поддержать платформу”, надеемся, что это сработает
Q: Вы делаете очередного убийцу стима?
A: Нет
Q: Это точно не развод?
A: Точно нет, чесслово
На остальные вопросы обязательно ответим. Так как это не реклама, то прямо указывать название площадки не буду, но подскажу, что наш канал https://t.me/dustore_official
Что такое 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. Один код. Тридцать лет компьютерной истории.
