Вышел 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

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

Это та тема, про которую большинство молится, лишь бы не попалась на собесе.

Единственная разница между деревом и графом это цикл. всё. если ты умеешь решать на деревьях, то на графах это то же самое: просто добавь массив visited.

Я разобрал 350+ задач по графам и они все укладываются в 7 шаблонов

1. BFS (поиск в ширину)

алгоритм “кратчайшего пути”. если спрашивают shortest path в невзвешенном графе (лабиринт, соцсеть) это он.

хак: очередь. волной, слой за слоем.

2. DFS (поиск в глубину)

алгоритм “исследователь”. когда надо перебрать все варианты или проверить связность.

хак: рекурсия (или стек) + visited, чтобы не зациклиться.

3. Union Find (Disjoint Set)

самый приятный паттерн. для “группировок” и проверки, связаны ли две вершины.

хак: идеально для “number of provinces” и “redundant connection”. path compression делает почти O(1) на операцию.

4. Топологическая сортировка (алгоритм Кана)

звучит сложно, но это просто “упорядочить зависимости”.

как узнать: “course schedule”, “build order”. если A должно быть раньше B, это сюда.

5. Алгоритм Дейкстры

паттерн “google maps”. кратчайший путь во взвешенном графе (у ребер разные веса).

хак: это BFS, только вместо обычной очереди Priority Queue (min-heap).

6. Bellman-Ford

редко, но важно. если есть “отрицательные веса”.

хак: медленнее Дейкстры, зато умеет ловить отрицательные циклы.

7. Floyd-Warshall

паттерн “для ленивых”. находит кратчайшие пути между всеми парами вершин.

хак: просто 3 вложенных цикла. O(N³). юзать только на маленьких графах (N < 500).

👉 @BackendPortal

Хочешь хранить текст? Не используй char(n) или varchar(n).

В других базах это встречается постоянно, но для Postgres — не лучшая идея.

• фиксированная ширина работает медленнее
• TEXT — переменной длины и без лимита
• если нужен размер, ставь constraint и ограничивай полем, а не типом

В итоге TEXT почти всегда выигрывает по практичности и производительности.

👉 @BackendPortal

Весь Docker в одной шпаргалке : забираем

👉 @BackendPortal

Компилируем Go в TypeScript 😂

Этот тул работает на уровне AST-дерева, позволяя переиспользовать бизнес-логику, алгоритмы и структуры данных между бэкендом и фронтом без переписывания руками

Исходный код этого чуда

👉 @BackendPortal

Минималистичный клиент для SQL-баз данных

Называется Outerbase Studio:

✓ Совместим с MySQL, Postgres, SQLite и MongoDB
✓ Поддерживает сервисы вроде Turso и Cloudflare D1
✓ Доступен для Web, macOS и Windows
✓ Бесплатный и open source

→ [http://github.com/outerbase/studio]

👉 @BackendPortal

7 обязательных сложностей по времени для собесов:

1. O(1) - константное время

* Время не меняется независимо от размера входа.
* Пример: доступ к элементу массива по индексу.

2. O(log n) - логарифмическое время

* Растет медленно по мере увеличения входа. Обычно в алгоритмах, которые на каждом шаге делят задачу пополам.
* Пример: бинарный поиск в отсортированном массиве.

3. O(n) - линейное время

* Растет линейно вместе с размером входа.
* Пример: поиск элемента в массиве перебором.

4. O(n log n) - линеарифмическое время

* Растет чуть быстрее, чем линейное. Для каждого элемента входа делается логарифмическое число операций.
* Пример: сортировка массива quick sort или merge sort.

5. O(n^2) - квадратичное время

* Растет пропорционально квадрату размера входа.
* Пример: bubble sort, который сравнивает и при необходимости меняет местами каждую пару элементов.

6. O(2^n) - экспоненциальное время

* Время удваивается при добавлении каждого элемента во вход. Для больших n становится непрактично.
* Пример: генерация всех подмножеств множества.

7. O(n!) - факториальное время

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

👉 @BackendPortal

Все надоело и пропал интерес, чувствуешь себя амебой и хочется только залипать в телефоне. Бывает?

Homo Manifestans — канал для айтишников, у которых периодически опускаются руки и отключается мозг, ибо переработки и постоянная тревожность не приводят к другим исходам 🤗

✓ Как научиться отвлекаться от работы и отдыхать?
✓ Как совместить кучу рабочих задач и время с семьей?
✓ Как справиться с прокрастинацией?
✓ Как не растерять запал, даже если начальник и коллеги 💩 и кажется, что ничего не выходит?

Подписывайтесь на канал @vadimpetrovpsi и научитесь работать без упахивания, выгорания и ущерба для личной жизни!

Псс. Заходите в закреп — там много полезного, и даже бесплатный мини-курс по выходу из апатии:
👉 https://t.me/+LEEr5GHeBHFlMWZi

Если protobuf уже компактный бинарный формат, есть ли вообще смысл дополнительно жать его Snappy? Вот что на самом деле делает Uber M3...

Uber M3 принимает больше миллиарда датапоинтов в секунду (масштаб реально дикий) и при этом принимает данные по HTTP/1.1 в виде Snappy-сжатого protobuf.

Protobuf сам по себе эффективный, да. Но у телеметрии есть особенность: она очень повторяющаяся. Одни и те же имена метрик, похожие наборы тегов, повторяющиеся hostnames, одинаковая структура полей в тысячах точек. Из-за этой избыточности такие данные отлично сжимаются даже быстрым алгоритмом вроде Snappy.

M3 использует Snappy-сжатый protobuf поверх HTTP для своего Prometheus remote write endpoint. Причина простая: на огромном масштабе тебе нужна компрессия, которая не станет узким местом.

* Snappy очень быстро сжимает и разжимает
* он ставит скорость выше коэффициента сжатия
* CPU-оверхед и на клиенте, и на коллекторе остается минимальным
* клиентам телеметрии не стоит жечь CPU на компрессию, когда они должны заниматься реальной работой

Забавный факт: на масштабе бутылочным горлышком становится вообще все. Ты пытаешься экономить каждый бит и каждый CPU-цикл. Нужно просто хорошо понимать кейс, замечать паттерны и выбирать то, что подходит именно тебе.

👉 @BackendPortal

Алгоритм ленты рекомендаций X/Twitter теперь опенсорс

👉 @BackendPortal