15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
sqlc это генератор кода для Go на этапе генерации. Ты пишешь SQL-запросы, а sqlc парсит их вместе со схемой и на основе этих запросов генерирует типобезопасный Go-код (структуры, функции).
sqlc также ловит несовпадения со схемой еще до сборки (например, если в запросе указан столбец, которого не существует).
Link: https://github.com/sqlc-dev/sqlc
Поправка: это не генерация на “compile-time”. Это отдельный шаг генерации, который ты запускаешь вручную (или в CI) перед компиляцией:
sqlc generate # pre-build step
go build ./...
Git tip : узнать, кто последний правил каждую строку файла, можно командой:git blame <filename>
Примечание: работает только для того, что уже закоммичено. Незакоммиченные правки (текущие изменения в рабочем дереве) в blame не попадут.
👉 @BackendPortal
В Go 1.26 в пакет reflect завезли итерируемые (range-able) итераторы.
Плюс добавили новые методы:Type.Methods()Type.Ins()Type.Outs()Value.Fields()Value.Methods()
Теперь с рефлексией можно работать заметно удобнее и ближе к обычному Go-коду, без лишней возни с индексами и слайсами.
👉 @BackendPortal
Университет Хельсинки выложил бесплатный курс MOOC по Python
Начинаешь с базы. На последних занятиях учат писать игры на Pygame, работать с анимацией и физикой, так что в конце создашь свою первую настоящую игру.
👉 @BackendPortal
В Go, когда тестируешь POST-хендлер, тебе нужен body запроса. Используй strings.NewReader с JSON-строкой, чтобы получить io.Reader. Хендлер прочитает это как настоящий body. Интерфейс тот же, реальный HTTP не нужен.
👉 @BackendPortal
Git Tip
Нужно откатить изменения из конкретного коммита, но не переписывать историю? Используй:
git revert <commit-hash>
git revert не удаляет коммит, а создаёт новый коммит, который “отменяет” изменения выбранного. Отлично подходит для общего репозитория и веток, где уже есть чужие pull'ы.
Когда один из серверов падает, дальше все зависит от того, есть ли у тебя load balancer и как он настроен.
▪️Если есть load balancer
1. Health checks. Балансер постоянно пингует бэкенды (HTTP endpoint типа /health, TCP-check, gRPC-check). Если сервер не отвечает или возвращает плохой статус, он помечается как unhealthy.
2. Трафик на него перестают слать. Балансер выкидывает упавший инстанс из пула и перенаправляет запросы на живые сервера.
3. Что увидит пользователь
Если живых серверов достаточно, пользователь почти ничего не заметит (максимум краткий пик задержек).
Если это был единственный сервер, или остальные уже под нагрузкой, будет ошибка/таймаут (обычно 502/503/504).
4. Сессии и состояние
Если у тебя sticky sessions (привязка пользователя к одному серверу) и именно он умер, у пользователя может “слететь” сессия, если она хранилась в памяти сервера.
Правильнее хранить сессии/кеш/стейт внешне (Redis, DB), тогда падение инстанса не ломает логин и корзину.
5. Автовосстановление. В нормальной прод-схеме оркестратор (Kubernetes/ASG/VM supervisor) поднимет новый инстанс, и балансер снова начнет слать на него трафик после успешных health checks.
▪️Если load balancer нет
Все запросы идут в один сервер.
Сервер упал = приложение лежит полностью до ручного/автоматического рестарта.
Load balancer делает так, чтобы падение одного сервера было “не трагедия”, а “минус один из пула”. Без балансера падение сервера почти всегда равно даунтайму.
👉 @BackendPortal
GPT-5 это не одна модель.
Это единая система из нескольких моделей, защитных контуров и роутера в реальном времени.
Когда ты отправляешь запрос, выбранный режим определяет, какую модель использовать и сколько работы система сделает.
Instant mode отправляет запрос напрямую в быструю нерезонирующую модель GPT-5-main. Она оптимизирована под минимальную задержку и подходит для простых или низкорисковых задач типа коротких объяснений или переписываний текста.
Thinking mode использует рассуждающую модель GPT-5-thinking, которая делает несколько внутренних шагов перед финальным ответом. Это повышает корректность на сложных задачах вроде математики или планирования.
Auto mode добавляет роутер в реальном времени. Легковесный классификатор смотрит на запрос и решает, использовать GPT-5-main или GPT-5-thinking, когда нужно более глубокое рассуждение.
Pro mode не использует другую модель. Он берет GPT-5-thinking, но сэмплирует несколько попыток рассуждения и выбирает лучшую с помощью reward model.
Во всех режимах safeguards работают параллельно на разных стадиях. Быстрый тематический классификатор определяет, высокорисковая ли тема, затем reasoning monitor применяет более строгие проверки, чтобы заблокировать небезопасные ответы.
👉 @BackendPortal
Базы данных медленные.
Пользователи нетерпеливые.
Redis существует.
Проблема решена.
👉 @BackendPortal
Совет на 2026 год — освойте ВАЙБ-КОДИНГ. ИИ уже пишет код, чинит баги, генерит тесты и документацию быстрее и качественнее любой команды айтишников
И те, кто научится вайбкодить сейчас, будут зарабатывать в разы больше тех, кто всё ещё делает всё вручную
Разобраться в этом с нуля поможет канал Вайб-кодинг. Там простым языком разбирают, какие инструменты действительно стоит использовать, как собирать проекты от идеи до релиза и что сейчас актуально в вайбкодинге
Подписывайтесь, нас уже 15 тысяч: @vibecoding_tg
Недавно наткнулся на отличный пример реализации паттерна Outbox для e-commerce сервиса заказов на Postgres с Redis Pub/Sub. Сразу уточню, это не моя работа, просто делюсь как наглядным примером.
Суть паттерна в том, чтобы не терять события между записью в базу и публикацией в брокер, что часто становится проблемой в event-driven системах. В этом примере, когда создается заказ, транзакция Postgres одновременно записывает строку в таблицу заказов и в таблицу outbox. В outbox хранится топик и JSON с текущим состоянием, например pending. Отдельный процесс-диспетчер опрашивает эти записи, публикует их в Redis канал вроде orders.created и только после успешной публикации помечает запись как обработанную.
Такой подход обеспечивает хотя бы одну доставку события и сохраняет консистентность системы. Консьюмеры downstream, например для управления запасами, email-уведомлений или аналитики, делаются идемпотентными, поэтому спокойно справляются с редкими дубликатами.
Паттерн нравится своей простотой и надежностью: используется проверенная база данных для атомарности, нет сложных распределенных транзакций, при этом система остается устойчивой и легко расширяемой.
Исходники
👉 @BackendPortal
Хватит сваливать всё в один файл CLAUDE.md.
Вложенные файлы недооценены просто преступно.
Большинство команд думают, что ИИ косячит потому, что модели недостаточно умные.
Чаще всего проблема вообще не в этом.
ИИ ломается из-за того, что у него ноль понимания границ контекста.
Когда ты запихиваешь все правила, соглашения и архитектурные решения в один огромный CLAUDE-файл…
Ты получаешь:
• шум в контексте
• конфликтующие инструкции
• более низкую точность
• более медленную работу с ИИ
Это как засунуть всю систему в один класс и назвать это модульной архитектурой.
Вложенные CLAUDE-файлы решают эту проблему. Они вводят границы контекста.
Ровно так же, как нормальная архитектура в коде.
Глобальные правила наверху.
Более специфичные правила по мере приближения ИИ к коду.
Глубокие файлы переопределяют верхние.
Вложенные файлы подгружаются только когда Claude работает в этом каталоге.
В монорепах это становится особенно мощно. Это даёт:
1. Эффективность по токенам
Каждый токен в контексте стоит производительности. Зачем грузить правила для React, если ты пишешь Python-воркер?
2. Масштабирование команды
Frontend-команда владеет apps/web/CLAUDE.md.
Backend-команда владеет apps/api/CLAUDE.md.
Без конфликтов мерджа. Без наступания друг другу на ноги. Чёткая зона ответственности.
3. Более высокая точность ИИ
Claude загружает только релевантные правила.
Меньше конфликтующих инструкций.
Гораздо более консистентный результат.
Мониторинг метрик PostgreSQL через панели Grafana: pgwatch
👉 @BackendPortal
Нашёл крутой способ прокачать Go😎
Это go-kata — набор маленьких задачек, каждая тренирует конкретный навык: от работы с ошибками до конкуррентности и HTTP. Берёшь, решаешь, смотришь, как можно было лучше.
Брюс Ли говорил, что боится не того, кто учит 10 000 ударов, а того, кто повторил «каты» по Go 10 000 раз 😂
👉 @BackendPortal
Строки в PostgreSQL неизменяемые и хранятся в heap. У каждой строки есть скрытый идентификатор CTID, который указывает на ее физическое местоположение на диске.
CTID это идентификатор-кортеж из двух частей: номер страницы и индекс (позиция) внутри этой страницы. Посмотреть его можно простым запросом:
SELECT ctid, * FROM your_table;
(0,1), (0,2), (1,1), где первое число это страница, а второе это позиция.
SSH-мультиплексирование в Go: SFTP-передачи в 14 раз быстрее по одному соединению
Код: https://github.com/MYK12397/sftp-go
SFTP работает поверх SSH, а SSH из коробки мультиплексированный протокол. Одно TCP-соединение SSH может одновременно нести сотни независимых каналов. Каждый open/read/close файла это отдельный канал, а SSH-слой сам “перемежает” их по проводу.
Я сам это не осознавал, пока мой скрипт для перекачки файлов не ускорился с 22 минут до 94 секунд, при том что я не открывал ни одного дополнительного соединения.
Как работает SSH-мультиплексирование
Когда вы вызываете sftpClient.Open() в Go-пакете pkg/sftp, создается новый SSH-канал, а не новое соединение. Транспортный слой SSH мультиплексирует все каналы поверх одного TCP-сокета. То есть 80 горутин (мой кейс) могут параллельно читать разные файлы, все разделяя один sftp.Client.http://sftpClient.Open() это ключевая строка. Каждый вызов открывает новый SFTP file handle, который мапится на новый SSH-канал. SSH-библиотека (golang.org/x/crypto/ssh) прозрачно обрабатывает мультиплексирование этих каналов, перемешивая read-пакеты всех 80 горутин по одному TCP-сокету.
При этом нет конкуренции за mutex на самом sftp.Client(). В библиотеке внутренние локи на уровне пакетов, а не на уровне файлов. Горутина A читает байты из файла 1 и не блокирует горутину B, которая в это время открывает файл 2.
👉 @BackendPortal
Вот штука, которая звучит немного контринтуитивно про B+ деревья: вставлять ключи в отсортированном порядке реально быстро, но есть скрытая цена.
Когда ты вставляешь ключи последовательно (1, 2, 3, 4...), B+ дерево почти ничего не “перетряхивает”. Узлы не приходится постоянно делить и ребалансить: каждый новый ключ улетает в самый правый лист. Вставки выходят супер дешевыми: минимум ребалансинга, минимум затронутых дисковых блоков.
Но плата за это такая: появляется жесткая внутренняя фрагментация.
Поскольку все вставки идут по правому краю, “левые” узлы редко добиваются до полной емкости. В итоге в хранилище лежит куча полупустых страниц, которые жрут место. Страница, которая могла бы держать 100 ключей, по факту держит 50–60, и это потом размазывается по всему дереву.
Случайные вставки, наоборот, распределяют ключи равномернее по страницам. Они медленнее, потому что будут сплиты/ребаланс, зато по месту всё намного эффективнее.
Так что если ты делаешь bulk load, отсортированная вставка дает скорость. Но если тебе важна плотность (память/диск) в долгую, имеет смысл перемешать ключи или использовать специальные bulk-loading алгоритмы, которые пакуют страницы плотнее.
Короче, как обычно: “лучшего способа” на все случаи нет :)
👉 @BackendPortal
Git-лайфхак
Хочешь нормальный граф коммитов по репе одной командой:
git log --oneline --graph --decorate --all
В Go можно читать из файлов, строк и сетевых соединений одним и тем же кодом. Секрет в io.Reader.
Если тип умеет отдавать байты, он реализует io.Reader. Принимай io.Reader и твой код будет работать везде.
Дизайн через интерфейсы: завязывайся на поведение, а не на источник данных.
👉 @BackendPortal
Кто бы мог подумать, что небольшая вариация связных списков сделает их... полезными для баз данных
Skip list (список с пропусками) это многоуровневый linked list: вставка по скорости как у обычного LL, но поиск намного быстрее.
Полезны ли они? Да. RocksDB использует skip list для своей LSM memtable.
👉 @BackendPortal
SQL-хак, о котором мало кто знает
Знал, что можно юзать FILTER как альтернативу CASE в агрегатах?
Самое приятное, что условия отделяются от самой агрегации, и это проще дебажить.
Если твой SQL-движок поддерживает FILTER (PostgreSQL, SQLite, DuckDB), попробуй.
CASE или FILTER? Что тебе больше нравится? 😆
👉 @BackendPortal
Большинство систем детектят падение ноды или мастера простым polling-ом, и хотя звучит это очевидно, у подхода есть интересная проблема с надежностью
Типичный сценарий: есть наблюдатель, который смотрит на ноду напрямую. Обычно это ping, проверка что порт открыт, или легкий запрос, чтобы убедиться, что нода жива.
На бумаге все ок, но у всех этих методов одна и та же слабость: а что если ошибается сам наблюдатель?
В распределенной системе сетевые глюки это норма. Временная потеря пакетов, косяки маршрутизации или частичные сетевые партиции легко делают здоровую ноду “недоступной” именно для наблюдателя. Обычно это фиксят ретраями: повторяют проверку несколько раз и объявляют фейл после n-го подряд провала.
И тут появляется классический компромисс.
Если n маленькое (или polling очень частый), детект получается быстрым, но растет число false positive. Короткий сетевой чих может запустить ненужный failover, который иногда разрушительнее исходной проблемы.
Если n большое (или интервалы polling длиннее), false positive меньше, но реальные падения детектятся дольше. А эта задержка напрямую увеличивает даунтайм.
Но если у тебя уже есть кластер, можно мыслить надежнее.
Вместо того чтобы один наблюдатель постоянно дергал целевую ноду, можно дать нескольким нодам в кластере независимо делать health-check. И считать ноду упавшей только тогда, когда большинство наблюдателей согласны, что она недоступна.
Такой consensus-подход снижает риск false positive из-за сетевых партиций. Даже если один наблюдатель потерял связность, остальная часть кластера все равно дает более точную картину здоровья системы.
Консенсус стоит дорого, так что это не самый экономичный вариант. Но он точно полезен, если система достаточно большая и размазана по нескольким географиям.
👉 @BackendPortal
Git tip
Используй эту команду, чтобы убрать из репозитория файлы, которые ты случайно закоммитил, хотя они должны были быть в .gitignore
git rm --cached <file>
.gitignore и сделай новый коммит, чтобы полностью прекратить их трекинг.
Как работает gRPC?
👉 @BackendPortal
Переименование файла - это атомарная операция, и именно эта гарантия сильно упрощает реализацию многих баз данных. Вот один практический пример, разберёмся детальнее…
Когда мы записываем данные в базу, мы не можем просто перезаписать файл напрямую. Если во время записи внезапно пропадёт питание, файл окажется повреждённым: часть старых данных, часть новых, короче полный беспорядок. Кошмар.
Поэтому большинство баз используют умную стратегию с двумя файлами для безопасности. Как это работает:
Новые данные сначала пишутся во временный файл. Это может быть запись в журнал write-ahead или новая страница базы данных. Старый файл при этом остаётся нетронутым и содержит последнее корректное состояние.
Когда новые данные полностью записаны во временный файл, система вызывает fsync(), чтобы гарантировать, что они реально оказались на диске (а не только в буфере). Затем выполняется атомарная операция rename(temp -> real_file).
Эта операция переименования атомарна на уровне файловой системы: либо всё прошло, либо ничего. После сбоя мы получаем ровно одно из двух состояний: старый файл остался нетронутым или новый файл полностью заменил старый. Никаких частичных записей или повреждённых данных.
Без этой атомарной гарантии всё было бы ужасно сложно: нужны сложные протоколы восстановления, версии, контрольные суммы на каждом шагу, и даже тогда остаются крайние случаи, когда данные могут повредиться.
Надёжность большинства баз данных держится именно на этой простой файловой гарантии. Довольно элегантно, если честно :)
👉 @BackendPortal
Растеры тут? Ловите совет по Rust 🦀bool::then: ленивое создание Optionbool::then можно использовать как альтернативу if-else, когда нужно условно построить Option<T>.
При этом оно ленивое — замыкание выполняется только если условие true, пропуская всю работу (выделение памяти, I/O, тяжёлые вычисления) при false.
👉 @BackendPortal
Git pull vs. git fetch
👉 @BackendPortal
Бесплатная опенсорсная игра, которая буквально учит вас писать эмулятор NES с нуля на JavaScript 😊
👉 @BackendPortal
Postgres 18 теперь поддерживает OAUTH 2.0 для аутентификации пользователей.
👉 @BackendPortal
Dockerfile доктор уже тут: переписывает файлы Dockerfile для уменьшения размера и повышения безопасности
👉 @BackendPortal