Эволюция протокола HTTP

👉 @BackendPortal

Пакет io — это ключевая часть стандартной библиотеки Go. Портировать его на C оказалось довольно интересной задачей.

Автору пришлось разобраться, как в C реализовать срезы (slices), множественные возвращаемые значения, обработку ошибок и интерфейсы. Но в итоге всё получилось довольно неплохо!

Читать фулл статью

👉 @BackendPortal

После тысячи видео "Стань Python-разработчиком с 0 до PRO" нашли видео для джунов, которые уже знают базу и не хотят опять слушать про print("Hello, World!")

Если уже знаешь синтаксис и основные конструкции в питоне, но застрял на уровне джуна, то видео точно будет полезно. Как мы поняли, это первая часть. В ней про Pydantic, ООП и декораторы настолько понятно, насколько это вообще возможно. К концу второй части обещают подтянуть зрителя до миддла — надо будет проверить 👍

👉 @BackendPortal

Microsoft открыла исходники обучающих материалов по Rust для уровней beginner, advanced и expert 🦀

👉 @BackendPortal

🦀 Rust: основы Zero Knowledge.

Этот подробный разбор объясняет, почему полиномы являются ключевой структурой данных в ZK, как используются конечные поля и почему лемма Шварца—Циппеля делает верификацию настолько эффективной — всё это с исполняемыми примерами кода на Rust.

https://rustarians.com/polynomials-in-zk-snarks/

👉 @BackendPortal

А что если бы можно было запускать Postgres как один файл и при этом использовать всё лучшее из SQLite?

Разработчик представил pg-micro — экспериментальный проект, который пытается это реализовать.

pg-micro отличается от других подходов тем, что он полностью локальный и ориентирован на производительность: нет ограничений по конкурентности и отсутствует трансляция SQL-запросов.

Как это работает: используется нативный парсер Postgres для разбора запроса, после чего он компилируется в AST от Turso. Затем этот AST компилируется в байткод, и дальше всё исполняется нативно — так же, как в SQLite. Благодаря этому решение можно запускать практически в любом окружении.

Исторически между Postgres и SQLite есть функциональный разрыв. Но Turso активно его сокращает: такие вещи, как MVCC и строгая развитая система типов, уже реализованы. Также есть PR’ы для lateral join’ов и других возможностей, что в теории позволяет свести разрыв почти к нулю.

Что это даёт на практике?
Можно представить, например, примитив наподобие Durable Objects от Cloudflare, но с интерфейсом Postgres.
Или использовать паттерн локальных баз данных для агентов, как в SQLite — полностью эфемерных и бесплатных, но с интерфейсом Postgres.
Или выполнять удалённый Postgres на платформах вроде Vercel, но с плотностью, которую даёт Turso Cloud.

Пока что многое может не работать — проект экспериментальный. Но он развивается как open source, поэтому PR’ы приветствуются.

Старт: npx pg-micro

👉 @BackendPortal

Кир Шатров, Principal Engineer в Shopify, пишет для The Consensus о технике отслеживания стоимости (MySQL) базы данных для каждого API-вызова.

Пейволл больше не действует, приятного чтения!

https://theconsensus.dev/p/2026/03/20/every-query-gets-a-receipt.html

👉 @BackendPortal

На Stepik вышел первый курс по: Claude Code — вайбкодинг с нуля

Изучаете всё шаг за шагом: CLAUDE.md → rules → commands → sub-agent → Skills → hooks:

🔴Оформите правила проекта через CLAUDE.md, подключение файлов через @ и разнесение логики в .claude/rules, чтобы не раздуло инструкцию.

🔴Сделаете свои slash-команды с frontmatter (description/allowed-tools/model) и аргументами через $ARGUMENTS и $1/$2/$3 для буста воркфлоу.

🔴Освоите саб-агентов: когда их запускать, как писать определения и как делегировать им расследования и проверки без засора основного контекста.

🔴Поднимете Hooks под реальный воркфлоу: /hooks, sh-скрипты, SessionStart/Stop/PreToolUse/PostToolUse, exit codes, matchers и env-переменные.

🔴Настроите Skills (SKILL.md + references), свяжете их с саб-агентами через skills-поле и подключите MCP, Web и headless (-p) для продвинутых случаев

Скидка 25%, действует 48 часов

⬇️ Пройти курс на Stepik

TF-IDF — один из самых распространённых способов оценки релевантности документов в поисковых системах. Многие запоминают формулу, но интуиция, почему это работает, на самом деле довольно простая…

Я читал об этом статью ещё в 2020 году, и она до сих пор остаётся актуальной и базовой — если кто-то хочет разобраться глубже :) А вот кратко суть:

IDF — это Inverse Document Frequency (обратная частота документа). Основная идея проста: слово, которое встречается почти в каждом документе, практически ничего не говорит о том, почему конкретный документ релевантен.

Такие слова, как “a”, “and”, “the”, встречаются везде. Они почти не несут сигнала. IDF автоматически «штрафует» их, присваивая им меньший вес.

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

Например, если терм встречается в 10 из 1000 документов, его IDF:

log(1000 / 10) = log(100)

Чем реже терм, тем выше его IDF — и тем полезнее он для различения документов.

Есть ещё одно интересное следствие, если смотреть на это с вероятностной точки зрения.

Если предположить, что термы встречаются независимо, то IDF для двух термов вместе равен сумме их индивидуальных IDF.

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

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

👉 @BackendPortal

Асинхронные системы масштабируют вашу систему… и ваши проблемы.

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

Асинхронность масштабирует вашу систему.
Она также нарушает порядок.

И вот откуда берутся большинство багов.

Вот статья о том:

- почему это происходит
- как группировка решает проблему
- и где она не работает

Прочитайте здесь

👉 @BackendPortal

MVC-архитектура (Model–View–Controller)

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

MVC-архитектура решает эту проблему, вводя чёткое разделение ответственности (separation of concerns).

Что такое MVC?

MVC (Model–View–Controller) — это шаблон проектирования, который делит приложение на три основных компонента, каждый из которых отвечает за свою часть логики. Такое разделение делает код более организованным, читаемым и поддерживаемым.

MVC — это способ структурировать код.
Он делит приложение на 3 части:

- Model = данные + логика
- View = то, что видит пользователь
- Controller = обрабатывает ввод и связывает Model и View

Можно представить это так:

Пользователь что-то нажимает → Controller обрабатывает
Controller запрашивает данные у Model
Model обрабатывает и возвращает результат
Controller передаёт результат во View
View отображает его пользователю

Чисто. Структурировано. Предсказуемо.

Что делает каждая часть?

- Model — работает с данными
Взаимодействует с базой данных и содержит бизнес-логику

- View — отвечает за UI
Только отображает данные, без логики

- Controller — промежуточный слой
Связывает Model и View

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

Без MVC → хаотичный код
С MVC → структурированный код

Преимущества:

- Простая отладка
- Лёгкие изменения
- Лучшая масштабируемость

Пример

В системе логина:

- Model проверяет учётные данные пользователя в базе
- View отображает форму входа и сообщения (успех/ошибка)
- Controller принимает ввод пользователя, валидирует его через Model и решает, какой View отобразить

👉 @BackendPortal