Нашёл GitHub-репозиторий, который помогает AI-агентам не сжигать токены впустую.

Называется Headroom.

Его создал Теджас Чопра, инженер из Netflix.

Идея простая: Headroom сжимает всё, что читает AI-агент, ещё до того, как данные попадут в LLM.

Например:

- вывод инструментов;
- логи;
- файлы;
- RAG-чанки;
- результаты поиска по коду;
- историю диалога.

По словам автора, это позволяет сократить расход токенов на 60–95% без потери качества ответов.

Сейчас Headroom можно использовать как:

- библиотеку для Python и TypeScript;
- локальный прокси;
- MCP-сервер;
- обёртку для Claude Code, Codex, Cursor, Aider и Copilot.

Если твой AI-агент становится дорогим, медленным или начинает теряться в огромных логах, на этот проект стоит взглянуть.

GitHub: https://github.com/tejaschopra/headroom

Спасибо за внимание.

👉 @BackendPortal

Как правильно работать с резервным копированием в облаке?

25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками.

⚫️Развеем мифы, разберём лучшие современные подходы и инструменты.

⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов.

⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы.

Зарегистрируйтесь, чтобы не пропустить!

⏰ 25 июня в 14:00 (мск)

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

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

Хороший пример — Array of Structs (AoS) против Struct of Arrays (SoA). Казалось бы, небольшое различие в организации данных в памяти, но оно радикально меняет эффективность использования кэша процессора и частоту cache hit'ов.

В результате разница в производительности может достигать целого порядка.

Похоже на выбор между построчным и колоночным хранением данных в СУБД. Всё упирается в паттерны доступа: OLTP и OLAP требуют разных подходов.

У Farad вышла отличная статья на эту тему — читается быстро и объясняет всё на понятных примерах. Ссылка ниже.

https://fzakaria.com/2026/06/01/every-byte-matters

👉 @BackendPortal

Избегать SQL — значит избегать настоящего бэкенда.

API меняются.
Фреймворки уходят в историю.
Базы данных переживают миграции, переписывания и смену стека.

Большинство проблем с производительностью на бэкенде возникают не из-за медленного кода приложения.

Обычно виноваты:

* плохие запросы;
* отсутствующие индексы;
* неудачная схема БД;
* слабая модель данных;
* неправильные паттерны чтения и записи.

Отсутствующий индекс не лечится микросервисами.

Дублирование данных не исправляется кэшем.

Медленные отчёты не ускоряются переписыванием API.

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

SQL — это не опция.

Хорошее знание SQL делает тебя сильнее в проектировании систем, распределённых системах, производительности и надёжности.

Изучи SQL.

Всё остальное строится поверх него.

👉 @BackendPortal

ИИ не уравнял всех разработчиков.

Он просто разделил рынок на несколько направлений, и многие до сих пор не поняли, в каком из них находятся.

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

Что остаётся после этого?

1. Оркестраторы

Люди, которые проектируют процесс целиком.

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

Они не обязаны писать каждую строчку кода.

Они отвечают за систему в целом.

2. Системные инженеры

ИИ отлично генерирует код.

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

Чем быстрее генерируется код, тем больше потенциальный радиус поражения ошибок.

Поэтому люди, которые понимают производительность, надёжность и устройство систем, стали только ценнее.

3. Переводчики между бизнесом и технологиями

ИИ сильно сократил путь от идеи до реализации.

Но он не умеет определять, какие идеи вообще стоит реализовывать.

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

Обычно они работают тихо.

Их редко замечают, пока они не уходят.

Мне кажется, главный эффект ИИ оказался не в замене разработчиков.

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

👉 @BackendPortal

Блин... оказывается, в VS Code можно встроить таймер Pomodoro прямо в редактор

Это расширение добавляет Pomodoro-таймер непосредственно в VS Code, так что можно сохранять концентрацию, не переключаясь между вкладками и не открывая отдельные приложения.

Что умеет:

→ Таймер Pomodoro прямо внутри редактора
→ Помогает держать фокус во время работы
→ Не нужно переключаться на браузер или сторонние программы
→ Несколько настраиваемых режимов работы и отдыха
→ Гибкая настройка длительности таймеров под свои привычки :)

Удобная штука для тех, кто проводит в VS Code большую часть дня и хочет отслеживать рабочие интервалы, не выходя из редактора.

👉 @BackendPortal

Вы когда-нибудь задумывались, на что база данных на самом деле тратит своё время?

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

Есть классическая статья Майка Стоунбрейкера, в которой производительность традиционной транзакционной СУБД анализировалась вплоть до отдельных инструкций процессора.

Вывод оказался неожиданным: менее 10% инструкций выполняют действительно полезную работу. Остальные 90%+ уходят на накладные расходы, которые почти поровну распределяются между четырьмя задачами:

1. Работа с буферами (перемещение страниц между буферным пулом и диском).

2. Блокировки (row-level locks для координации параллельных транзакций).

3. Защёлки (latches — облегчённые блокировки, обеспечивающие целостность внутренних структур данных).

4. Журналирование (запись операций до их выполнения, чтобы обеспечить возможность восстановления).

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

Если именно эти четыре источника накладных расходов потребляют процессорное время, что будет, если необходимость в них исчезнет?

- нет буферов → база данных полностью хранится в памяти;
- нет блокировок и защёлок → однопоточная архитектура;
- нет журналов → репликация вместо логирования.

Именно на этом строилась идея H-Store, а позже и VoltDB. Вы жертвуете частью гибкости, но взамен получаете производительность, в которую сложно поверить.

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

https://15721.courses.cs.cmu.edu/spring2016/papers/hstore-lookingglass.pdf

👉 @BackendPortal

Вы арендуете собственный код у Microsoft.

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

И никаких ежемесячных платежей. Называется Gitea

Закидываете один файл на сервер — и получаете свой GitHub. Pull Request'ы, Issues, Wiki, реестр пакетов и даже CI-систему, которая умеет запускать ваши существующие GitHub Actions без переписывания конфигурации.
→ Поставляется одним файлом. Никакой боли с настройкой.
→ Работает на 256 МБ ОЗУ. Можно хостить даже на Raspberry Pi.
→ Совместим с GitHub Actions из коробки.
→ Умеет импортировать репозитории, Issues и Pull Request'ы.
→ Поднимается менее чем за 15 минут через Docker.

Более 55 000 звёзд на GitHub.

Полностью открытый исходный код. Лицензия MIT. Бесплатен навсегда.

👉 @BackendPortal

Плейлист по RAG

Что вы изучите:

* Retrieval-Augmented Generation (RAG)
* Document Loaders в LangChain
* Text Splitters в LangChain
* Vector Stores в LangChain
* Retrievers в LangChain
* Создание чат-бота для YouTube с помощью LangChain
* Реализация RAG на базе LangGraph
* Продвинутый RAG: как Corrective RAG (CRAG) решает проблемы классического RAG
* Self-RAG: как заставить ИИ самостоятельно проверять достоверность своих ответов и выполнять фактчекинг своих выводов

👉 @BackendPortal

Подборка бесплатных ресурсов для изучения Go 😢

— Набор интерактивных практических заданий, которые нужно выполнять прямо в браузере: https://tour.golang.org

— Руководство-шпаргалка по основным темам языка. На каждую тему есть полноценная программа, для каждой строчки которой подготовлено подробное пояснение: https://gobyexample.com

— Ресурс, по содержанию похожий на предыдущий. Здесь тоже для каждой из тем языка представлены практические примеры с объяснениями: https://gowebexamples.com

👉 @BackendPortal

FastAPI получил встроенную поддержку фронтенда.

В версии FastAPI 0.138.0 появился метод app.frontend(), который позволяет раздавать готовое фронтенд-приложение напрямую из FastAPI, включая поддержку client-side routing.

Подходит для:
React + TanStack Router
Astro static builds
приложений на Vite
других SPA и статических фронтендов

Теперь вместо отдельной настройки Nginx или дополнительного сервера можно подключить собранную папку одной строкой:

from fastapi import FastAPI

app = FastAPI()

app.frontend("/", directory="dist")

По словам разработчиков, это упрощает деплой full-stack приложений, где FastAPI отвечает и за API, и за раздачу фронтенда. Поддержка client-side routing уже встроена.

Также в релизе появился встроенный skill для AI-агентов. Теперь Claude Code, Codex и другие агенты могут изучить новую функциональность FastAPI через:

uvx library-skills

Это позволяет агентам использовать возможности FastAPI и актуальные паттерны без ручного объяснения через промпты

👉 @BackendPortal

Нашёл интересный инструмент для поиска и устранения дублирующегося кода.

Называется Deslop. Написан на Rust, но работает не только с Rust-проектами — поддерживает Python, Dart и C#.
Инструмент анализирует кодовую базу, находит дубликаты и помогает избавиться от повторяющихся фрагментов. Автор предлагает просто установить его в VS Code или любой другой форк редактора и использовать прямо в процессе разработки.

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

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

👉 @BackendPortal

Репозитории на GitHub, которые научат вас большему, чем многие платные курсы:

30-Days-of-Python
Структурированная программа на 30 дней с ежедневными уроками и практическими заданиями на Python Shell. Помогает пройти путь от полного новичка до написания собственных скриптов.

project-based-learning
Огромная коллекция Python-проектов: веб-приложения, парсеры, небольшие игры и многое другое. Каждый проект сопровождается пошаговым разбором процесса разработки.

Build-your-own-X
Сборник проектов, которые можно реализовать самостоятельно по готовым руководствам. Настоящая находка с более чем 500 тысячами звёзд на GitHub.

ML-for-Beginners
Бесплатный курс по машинному обучению от Microsoft. Включает объяснения теории, тесты и практические задания. Отлично подходит для изучения основ ML.

500 AI/ML/DL Projects
С этим репозиторием идеи для проектов не закончатся. Внутри собрано более 500 проектов по AI, машинному обучению, глубокому обучению, компьютерному зрению и обработке естественного языка.

👉 @BackendPortal

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

HTTP Polling

HTTP Polling основан на периодическом опросе сервера. Клиент через заданные промежутки времени отправляет запросы, чтобы проверить, появились ли новые данные.

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

Например, клиент может каждые пять секунд отправлять запрос:

Клиент → Сервер: «Есть обновления?»

Если новых данных нет, сервер отвечает отрицательно. Через несколько секунд запрос повторяется снова. Когда данные появляются, сервер возвращает их в ответе на очередной запрос клиента.

Преимущество Polling заключается в простоте реализации. Недостатками являются лишняя нагрузка на сервер и менее оперативная доставка обновлений.

WebSocket

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

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

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

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

Области применения

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

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

Простое сравнение

HTTP Polling можно представить как человека, который постоянно спрашивает:

«Появилось что-нибудь новое?»

WebSocket больше похож на подписку на уведомления:

«Когда произойдёт событие, меня сразу об этом сообщат».

Выбор между этими подходами зависит от требований приложения к скорости обмена данными, нагрузке на сервер и объёму передаваемого трафика.

👉 @BackendPortal

Docker-ошибка, которую я вижу почти в каждом junior Dockerfile:

COPY . .
RUN npm install

должно быть:

COPY package*.json ./
RUN npm install
COPY . .

почему это важно?

docker кэширует каждую инструкцию как отдельный слой
исходный код меняется с каждым коммитом
поэтому COPY . . ломает кэш, и всё после него (включая npm install) пересобирается с нуля при каждой сборке
если поменять порядок, слой с установкой зависимостей остаётся в кэше даже при изменении кода, потому что он зависит только от package.json
одна перестановка строк. экономит 40+ секунд на каждой пересборке. кэшируй зависимости, а не код.

👉 @BackendPortal

Компоненты Docker

Dockerfile
Файл-инструкция, который описывает шаги сборки Docker-образа.

Image (Образ)
Шаблон только для чтения, содержащий код приложения, зависимости, библиотеки и конфигурацию среды выполнения.

Container (Контейнер)
Запущенный экземпляр образа, внутри которого фактически выполняется приложение.

Docker Daemon
Фоновая служба, отвечающая за управление объектами Docker: образами, контейнерами, сетями и томами.

Docker Engine
Платформа, которая запускает и управляет контейнерами через Docker Daemon, API и CLI.

Volumes (Тома)
Постоянное хранилище данных, которое сохраняет информацию независимо от жизненного цикла контейнера.

👉 @BackendPortal

3 популярных паттерна для мультимодального RAG.

Главное различие между ними — как система работает с разными типами данных: текстом, изображениями, аудио и видео.

1. Общее векторное пространство (Shared Vector Space)

* Позволяет выполнять поиск между разными модальностями без конвертации форматов.
* Например, можно искать изображения по текстовому запросу.
* Требует больших объёмов мультимодальных данных для обучения.
* При недостаточно разнообразных данных возможен semantic drift — снижение качества соответствия между модальностями.

2. Одна базовая модальность (Single Grounded Modality)

* Все данные сначала переводятся в текст через OCR, captioning или транскрипцию.
* Легко интегрируется в существующие текстовые RAG-системы.
* Теряются пространственные связи и визуальный контекст изображений.
* Качество поиска напрямую зависит от качества распознавания и описания контента.

3. Раздельные пайплайны поиска (Separate Retrieval Pipelines)

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

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

👉 @BackendPortal

Небольшой совет для CI:
На Node.js 22+ используйте node --run <script> вместо pnpm run <script> для запуска простых package-скриптов в GitHub Actions.
Небольшое изменение, которое экономит 200–400 мс на каждом вызове.

👉 @BackendPortal

Исторический момент. Новый HTTP-метод в стандарте.

QUERY. Альтернатива GET и POST.

Как GET — не меняет состояние ресурса. Как POST — можно использовать тело запроса. Шлёшь JSON, кешируешь ответ.

Только что повышен до Proposed Standard.

👉 @BackendPortal