Привет, Хабр!

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

Сразу скажу, зачем я вообще полез в эту тему. В колледже была лаба, где нужно было поднять процесс, дождаться его и снять код возврата. Я неделю не понимал, почему fork() в одном случае возвращает ноль, а в другом — PID, и почему после exec ребёнок «исчезает». Препод объяснил это минут за десять — и я понял, что половину объяснений всё равно не понял. С тех пор я пишу такие вещи с расстановкой: не «fork() создаёт процесс», а что именно он возвращает, что происходит в коде после вызова и что будет, если забыть закрыть дескрипторы. Поэтому статей будет много, а примеров в каждой — ещё больше.

Что дальше в цикле, чтобы было понятно, куда мы движемся:

Страница документации размером всего 100 КБ обходится языковой модели примерно в 25 000 токенов. Такую оценку Anthropic приводит в описании своего инструмента web fetch, а для обычной страницы на 10 КБ — около 2 500 токенов. Если агент без ограничений загружает пять таких страниц подряд, он за один шаг съедает заметную часть контекстного окна и бюджета. Добавьте к этому то, Cloudflare по умолчанию блокирует ИИ-краулеры и может отвечать им кодом 402 Payment Required.

Помните Size of Life от Нила Агарвала? Листаешь вправо, и рядом с каждым существом появляется следующее, побольше. Мне захотелось такого же, но про космос: начать с крошечного астероида и пролистать всё до самой границы того, что мы вообще можем увидеть.

Получилось 79 объектов и 24 порядка величины, от астероида Бенну диаметром 490 метров до наблюдаемой Вселенной в 93 миллиарда световых лет. Всё рисуется в реальном времени прямо в браузере, а под капотом есть трассировка лучей, ray marching, реальные карты поверхностей от NASA и генеративная музыка. Ниже расскажу, как это устроено и на какие грабли я наступил.

Развернуть кластер Kubernetes вручную — задача не столько сложная, сколько продолжительная: поднять виртуальные машины, установить компоненты Control Plane, настроить CNI, CSI, DNS, разложить сертификаты. Понять, что надо было иначе, удалить, сделать заново, и так раза три.

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

Самая дорогая строчка в микросервисе с LLM — model="gpt-4o". За ней тянутся свой ключ вендора, свои ретраи и счёт, который потом некому разобрать.

Расскажу об одной идее, которая это убирает: сервис не должен знать, какая модель ему отвечает. Вокруг неё четыре механизма: правила маршрутизации, автоматический выбор сложности, поведение при сбоях вендоров и контроль денег. Примеры — из нашего open-source шлюза Keystone (KTMS) на Go, но схему можно повторить в любом шлюзе.

Привет, Хабр! В этом материале сделаем сервис, который разгрузит диспетчера сервисного центра по ремонту бытовой техники. Голосовой робот будет принимать входящий звонок и собирать детали обращения. На каждое обращение в Битрикс24 будет создаваться карточка с назначенным мастером.

Стек проекта: Python 3.10+, FastAPI, Pydantic, SQLite, HTTPX, Битрикс24, Яндекс Геокодер, голосовой робот и SMS API от МТС Exolve.

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

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

Я делаю сайт, который считает статистику переписки прямо в браузере. Обычно для этого нужен экспорт чата Telegram из Desktop, а с телефона его не сделать. Поэтому у меня есть второй путь, без компьютера и без файла. Человек входит со своего телефона, а страница сама выкачивает историю выбранного чата через Telegram API, то есть MTProto, как настоящий клиент. Работает это на mtcute поверх WebSocket к серверам веб-клиента Telegram, со своими api_id и api_hash с my.telegram.org.

Три недели всё работало, но медленно. Я посмотрел в свою аналитику. Чат на 100–250 тысяч сообщений выгружался в среднем 33 минуты, а самый долгий занял 100. Всё это время человек должен держать вкладку открытой с горящим экраном, потому что в фоне телефон останавливает загрузку. Почти три четверти всего ожидания приходилось на большие чаты, хотя их всего пятая часть.

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

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