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

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 еще и извинился за необоснованные оценки :)))

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

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

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

Пора научить агента видеть и слышать. Клиент не присылает аккуратный промпт — он кидает фотку накладной, скрин ошибки, голосовое на 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'те!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет, коллеги! Традиционная подборка открытых онлайн‑мероприятий для тех, кто хочет прокачать скиллы в 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 открытых вебинаров на эту неделю. Если вы не нашли в расписании тему, которая нужна именно вам, — загляните в полный календарь

Работаю над большим 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-схемами и таблицами. Я старался не смешивать два разных назначения в одном файле.

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

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

Что такое смарт контракт с точки зрения разработчика.

Я постараюсь уберечь вас от терминологии блокчейна, вместо этого на пальцах показать из чего состоит смарт контракт и как его собрать. Если говорить совсем просто, то смарт контракт - это ячейка в памяти, хранящая в себе:

• Адрес

• Баланс

• Любые данные, которые вы туда запишите

• Код смарт контракта

• Текущий статус смарт контракта

Ну или если перевести вышесказанное в код, то:

class SmartContract{ 
   readonly address: string; 
   readonly balance: number; 
   readonly code: string; 
   readonly status: 'uninitialized' | 'active' | 'frozen'; 

   storage: object; 
   ... 
}

Плавное погружение...

Представьте, вы написали код класса на своем любимом языке программирования, как полагается, с полями и методами, и превратили этот код в строку. Code - это и есть код вашего смарт контракта. Он будет выполняться в блокчейне. Точкой входа в таком коде будет метод onInternalMessage или onExternalMessage. Чтобы состояние полей класса можно было сохранять и перезаписывать, к смарт контракту прилагается объект Storage , в котором хранятся значения ваших полей.

При сохранении смарт контракта в блокчейн вы отправляете { code, data } , где code - это код вашего смарт контракта, data - начальные данные. По этим двум полям вычисляется будущий адрес смарт контракта: address = hash({ code, data }). По этому адресу будет доступен ваш смарт контракт в блокчейне ТОН. На него можно совершать переводы, просматривать историю транзакцию, с него может переводить средства и вызывать другие смарт контракты.

Как происходит деплой смарт контракта.

Каждый смарт контракт платит немного комиссии по факту своего существования, в пример вспоминается налог на недвижимость. Чем больше жилплощадь - тем больше налог. Но в рамках ТОН вы платите за количество данных, которое хранит ваш смарт контракт, включая сам код вашего смарт контракта. Поэтому при создании на нем должно лежать как минимум чуть-чуть ТОН(как правило копейки). Создать смарт контракт можно 2 способами:

1) Другой смарт контракт делает перевод ТОН, прикрепляя код вашего смарт контракта вместе с начальными значениями(data) в поле Init = { code, data }. Блокчейн видит в переводе это поле и автоматически делает деплой. Статус смарт контракта становится "active".

2) Другой смарт контракт так же делает перевод ТОН, но только не прикрепляя ничего. В таком случае средства останутся висеть на адресе пустого смарт контракта, который будет выглядеть примерно так:

{ 
   "address": "401bf...3004", 
   "balance": 3000, 
   "code": "", 
   "storage": {}, 
   "status": "uninitialized" 
}

Он ждет внешнее сообщение, где в него передадут код и начальные данные таким образом, чтобы address = hash({ code, data }), только тогда он сохранит код и сможет выполняться. Для вызова внешнего сообщения используется обычное API, где передается адрес и Init = { code, data } . Запрос сначала попадет в блокчейн, после чего при совпадении адреса address = hash({ code, data }) произойдет деплой, и статус станет "active".

Заключение

В этой статье мы с вами закрепили азы архитектуры блокчейна ТОН, где каждый адрес является адресом смарт контракта. Разобрали структуру и механику создания. Рады вашему фидбеку или вопросам! Следите за нашими анонсами и новостями в Telegram.

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

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

Игра написана на 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

При этом у классических 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, тестировании, нагрузке, инфраструктуре, работе с данными и проектировании систем.

• 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

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

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

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

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

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

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

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

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

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

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

A: Нет

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

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

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

Я полностью пересмотрел концепцию библиотеки 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. Один код. Тридцать лет компьютерной истории.

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

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

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

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

#!/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 — смотрим, радуемся! 😁

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

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