Сборник документации множества языков программирования, библиотек и фреймворков в одном интерфейсе

Экономим время ✌️

👉 @BackendPortal

Бэкапит базы на несколько хранилищ сразу, плюс умеет присылать нотификации.

https://github.com/RostislavDugin/postgresus

👉 @BackendPortal

Эта open-source система для управления проектами реально впечатляет

Работает через веб, бесплатная и закрывает весь базовый набор: планирование, задачи, таймлайны, прогресс команды.

Если нужен мощный PM-инструмент без дорогих SaaS — стоит глянуть :)

👉 @BackendPortal

R-trees это мощная структура для индексации геометрических данных.

Их используют в MySQL, а Postgres применяет похожий на R-tree подход через GiST в PostGIS.

По сути они работают похоже на B-tree: это древовидная структура, где на каждом узле страницы хранится несколько записей. Такой дизайн держит дерево неглубоким и позволяет эффективно искать миллионы элементов на диске. Данные обычно лежат только в листьях, как у B+tree.

Записи в R-tree это ограничивающие прямоугольники. Сами геометрические фигуры обычно сложнее прямоугольников, поэтому на уровне листьев хранят минимальный ограничивающий прямоугольник (MBR) для каждой фигуры, плюс ссылку на полную геометрию, которая лежит отдельно на диске. Родительский узел для листового MBR хранит прямоугольник, который полностью покрывает все дочерние.

Чем выше по дереву, тем больше становятся bounding-прямоугольники. В корне обычно остаётся несколько больших bounding-боксов.

Ключевое отличие от B-tree: поиск одного прямоугольника может потребовать обхода нескольких путей в дереве. В идеале B-tree даёт O(log n) на поиск, но из-за перекрытий у R-tree худший случай может быть O(n).

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

👉 @BackendPortal

Автоматизация рабочих процессов с мониторингом серверов: xyops

👉 @BackendPortal

PostgreSQL позволяет клонировать базу на 6 ГБ за 212 миллисекунд вместо 67 секунд. Вот как это работает.

Клонирование баз данных полезно в нескольких сценариях:

* тестирование миграций без трогания продакшн-данных
* поднятие свежих копий под каждый прогон тестов
* сброс sandbox-окружения между сессиями
* воспроизводимые снапшоты для отладки

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

В PostgreSQL система шаблонов была всегда. Каждый CREATE DATABASE тихо клонирует template1 под капотом, и вместо template1 можно использовать любую базу.

В версии 15 появился параметр STRATEGY, и по умолчанию включили WAL_LOG — поблочное копирование через журнал предзаписи (WAL). I/O становится ровнее, но для больших баз это медленнее.

В PostgreSQL 18 появилась опция file_copy_method = clone. На современных файловых системах вроде XFS, ZFS или APFS она использует операцию FICLONE. Вместо копирования байтов файловая система создаёт новые метаданные, которые указывают на те же физические блоки. Обе базы используют одно и то же хранилище, пока вы ничего не меняете.

Всю магию здесь делает файловая система, создавая copy-on-write (CoW) клон файлов.

Когда вы обновляете строку, файловая система запускает copy-on-write только для затронутых страниц. Всё остальное остаётся общим. Клон на 6 ГБ изначально не занимает дополнительного места и растёт только по мере расхождения данных.

Важно помнить один момент: у исходной базы не должно быть активных подключений во время клонирования. Это ограничение PostgreSQL, а не файловой системы.

Довольно круто.

👉 @BackendPortal

Совет по Postgres: используй filter вместо case when для условных агрегатов. Читается проще, выглядит более идиоматично для SQL и часто работает быстрее.

--  не делай так: громоздко и хуже читается
select
  count(case when status = 'active' then 1 end) as active_count,
  count(case when status = 'archived' then 1 end) as archived_count
from projects;

--  лучше так: чище и оптимизируется Postgres
select
  count(*) filter (where status = 'active') as active_count,
  count(*) filter (where status = 'archived') as archived_count
from projects;

👉 @BackendPortal

Я всегда хотел понять, как SQL-базы реально исполняют JOIN'ы. Теорию я знал, но какое-то время назад потратил пару часов на исходники MySQL, чтобы разобраться в деталях.

Оказалось, что MySQL строит join-планы инкрементально, чтобы найти оптимальный порядок соединений. Он идёт от однотабличных access paths к join'ам на 2 таблицы, затем на 3, и так далее. В качестве оптимизации он отбрасывает поддеревья, которые гарантированно дадут более высокий cost.

Интересно, что там заметны следы динамического программирования. MySQL кеширует промежуточные результаты, чтобы не считать cost заново при расширении join-плана.

Именно за это я люблю open source: если есть вопрос, можно просто зайти в код и найти ответ самому.

Если любопытно, начни с файла sql_optimizer, а в нём — с функции get_best_combination. И да, спокойно используй LLM, чтобы разбирать исходники; я делал так же.

Вот код, который находит оптимальный порядок соединения

👉 @BackendPortal

9 принципов софт-дизайна, которые стоит знать каждому разработчику:

1. DRY (Don’t Repeat Yourself). Избегай дублирования кода. Логику лучше держать в одном месте, так кодовая база намного проще в обслуживании.

2. KISS (Keep It Simple, Stupid). Тянись к простоте. Не городи архитектуру без реальной необходимости и не добавляй лишние уровни.

3. YAGNI (You Aren’t Gonna Need It). Реализуй только то, что нужно сейчас. Не трать время на потенциальные фичи, до которых может так и не дойти.

4. LOD (Law of Demeter). Общайся только с ближайшими соседями. Избегай бесконечных цепочек вызовов.

SOLID принципы:

5. SRP (Single Responsibility Principle). Класс должен отвечать только за одну вещь. Компоненты должны быть узкими и целостными.

6. OCP (Open/Closed Principle). Код должен быть открыт для расширения, но закрыт для модификации. Новое добавляем через расширение, а не переписывание старого.

7. LSP (Liskov Substitution Principle). Подклассы должны нормально подменять родительские без поломок в поведении.

8. ISP (Interface Segregation Principle). Разделяй интерфейсы на небольшие и сфокусированные, вместо огромных интерфейсов на все случаи.

9. DIP (Dependency Inversion Principle). Высокоуровневые модули не должны зависеть от низкоуровневых. Оба должны зависеть от абстракций.

👉 @BackendPortal

Подборка учебных материалов для изучения программирования на примере проектов: чекаем

👉 @BackendPortal

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

Сделали интерактивный гайд про то как это работает

👉 @BackendPortal

Когда ты используешь ORDER BY, SQL должен решить, куда девать значения NULL.

NULL часто означает:
✅отсутствующие данные
✅неполные записи
✅значение неприменимо

По умолчанию:
✅ одни СУБД ставят NULL в начале
✅другие ставят NULL в конце

Из-за этого один и тот же запрос может выглядеть по-разному в результатах, в зависимости от того, где он выполняется.

Но ты можешь явно указать, как сортировать NULL.

Например:

➡️ORDER BY score ASC NULLS FIRST
Значит: сортировать по score по возрастанию и показывать NULL первыми.

➡️ORDER BY score DESC NULLS LAST
Значит: сортировать по score по убыванию и показывать NULL последними.

👉 @BackendPortal

Вышел Go 1.26 Release Candidate 2!

Включает фиксы по безопасности для archive/zip (CVE-2025-61728), net/http (CVE-2025-61726), crypto/tls (CVE-2025-68121, CVE-2025-61730), cmd/go (CVE-2025-61731, CVE-2025-68119).

Скачать: https://go.dev/dl/#go1.26rc2

👉 @BackendPortal

Ты открываешь репу, видишь сотни папок, пару src, пару packages, и вопрос: кто дергает этот модуль?, куда утекает эта функция?, почему тут вообще есть эта зависимость? 😁

Лови костыль который решает это: расширение для VS Code, которое рисует кодовую базу как интерактивный граф прямо в редакторе. То есть вместо бесконечного кликанья по дереву проекта ты видишь карту: файлы, функции и зависимости, и как они между собой связаны.

👉 @BackendPortal

Если готовишься к system design / backend-интервью, можно прогнать этот чек-лист

👉 @BackendPortal

Загружает ресурсы веб-сайта с исходной структурой каталогов: https://github.com/timf34/pagesource

👉 @BackendPortal

Деревья это точка, где 90% людей сдаются на DSA
Рекурсия ломает мозг, и на собесе ты просто виснешь
Но как и с массивами, ты просто усложняешь себе жизнь

Я разобрал больше 400 задач по деревьям
И там реально крутятся одни и те же 6 паттернов

1. Level Order Traversal (BFS)

Если задача просит пройти дерево по уровням или найти кратчайший путь в невзвешенном дереве — это оно

Хак: не пытайся всё решать рекурсией, тут нужна очередь

2. Depth First Search (DFS)

Базовая штука. Если надо идти в глубину перед тем как обходить соседей (например проверка пути от корня до листа) — бери это

Хак: выучи Pre-order, In-order и Post-order. Это покрывает процентов 70 задач

3. Path Sum

"найти путь который даёт сумму k". Выглядит страшно, но это просто DFS с накопленной суммой

Хак: вычитай значение узла из цели пока спускаешься вниз. Если на листе цель стала 0 — задача решена

4. Tree Construction

"построить дерево из двух массивов". По сути проверка логики

Хак: ищешь корень (обычно первый или последний элемент обхода), режешь массивы и рекурсишь

5. Lowest Common Ancestor (LCA)

Самый частый вопрос на собесах

Хак: если оба узла меньше текущего — иди влево. Если оба больше — вправо. Если расходятся — вот ответ

6. Serialize & Deserialize

Как сохранить дерево в файл и восстановить обратно

Хак: выбираешь любой обход (например Pre-order) и вставляешь null для пустых детей

400+ страшных задач превращаются в 6 блоков логики
Хватит гриндить 100 рандомных вопросов
Выучи эти 6 и закроешь всю категорию

👉 @BackendPortal

В Postgres есть функция age() чтобы быстро посчитать возраст (разницу) между timestamp или датами

👉 @BackendPortal