15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Те же AI-модели, но до 90% дешевле: как это работает в OdiRouter.ai?
Например, GPT-5.6 Sol: официальная цена — $5/M за input и $30/M за output.
В OdiRouter текущая цена со скидкой — $0.49/M за input и $2.94/M за output.
Или Claude Fable 5: официальная цена — $10/M за input и $50/M за output.
В OdiRouter текущая цена со скидкой — $2.5/M за input и $12.5/M за output.
Разница заметная. Вопрос: как они это делают?
OdiRouter — это не один отдельный AI-сервис, а единый API-вход к 200+ моделям: GPT, Claude, Gemini, Grok, Kimi, генерация изображений, видео и мультимодальные модели.
Самое интересное, что бесплатно сейчас можно запустить не только LLM, но и такие image-модели, как GPT Image 2 и Nano Banana 2, а также Kimi K3, Grok 4.5, GPT-5.5, Claude Opus 4.8, Gemini 3.5 Flash и другие популярные модели. Всё работает напрямую, без VPN.
Такой инструмент лучше не просто сохранять “на потом”, а сразу прогнать на своих prompt’ах.
Если делаете bot, agent, SaaS, небольшой AI-инструмент или генерацию изображений/видео, разница быстро становится видна: одна и та же задача, но стоимость моделей может привести к совсем разным счетам.
👉бесплатный доступ к API: https://odirouter.ai/?utm_source=devman&channel=telegram
👉По техническим вопросам: @OdiRouter
Планировщик запросов PostgreSQL использует динамическое программирование, чтобы подобрать наиболее дешёвый порядок JOIN при объединении нескольких таблиц.
Пожалуй, один из тех редких моментов, когда dynamic programming встречается не в задачке с LeetCode, а внутри системы, которой разработчики пользуются каждый день.
https://internals-for-interns.com/posts/postgres-query-planner/
👉 @BackendPortal
Postgres 19 исправляет AUTOVACUUM
Autovacuum удаляет мёртвые строки и поддерживает таблицы в нормальном состоянии. Теперь PostgreSQL умеет:
→ Запускать несколько autovacuum-воркеров
→ Оценивать таблицы по уровню риска
→ В первую очередь обрабатывать таблицы, которым очистка нужна срочно
→ Выполнять VACUUM для нескольких таблиц параллельно
👉 @BackendPortal
PostgreSQL 19 теперь умеет показывать активность асинхронного ввода-вывода прямо в EXPLAIN.
Это упрощает понимание:
→ где именно используется асинхронный I/O;
→ какие части плана обращаются к хранилищу;
→ получает ли запрос преимущество от асинхронного чтения.
Меньше догадок и больше прозрачности в том, что PostgreSQL делает под капотом плана выполнения запроса.
В PostgreSQL 18 появился асинхронный I/O.
А в PostgreSQL 19 стало проще увидеть, как он работает.
👉 @BackendPortal
PostgreSQL 19 сможет динамически подстраиваться под всплески нагрузки.
Вместо фиксированного пула I/O-воркеров, рассчитанного на условный «средний день», система будет масштабировать его по ситуации:
нагрузка растёт → очередь I/O увеличивается → PostgreSQL это замечает → запускает дополнительных воркеров → очередь разгружается → после снижения нагрузки лишние воркеры завершают работу.
Без ручного вмешательства и постоянного выделения ресурсов с запасом.
То есть небольшой пул больше не должен захлёбываться под продакшен-нагрузкой, а PostgreSQL постепенно превращается в инфраструктуру, которая сама адаптируется к трафику, а не требует постоянного присмотра.
👉 @BackendPortal
CPU, GPU, TPU, NPU и LPU: в чём разница
Сегодня для AI-нагрузок используются пять основных аппаратных архитектур. Каждая по-своему балансирует между универсальностью, параллелизмом и доступом к памяти.
CPU — универсальный процессор с небольшим количеством мощных ядер. Он хорошо справляется со сложной логикой, ветвлениями, операционными системами и базами данных, но менее эффективен в повторяющихся матричных вычислениях.
GPU использует тысячи более простых ядер, которые параллельно выполняют одинаковые операции над разными данными. Именно поэтому GPU стали основной платформой для обучения нейросетей.
TPU ещё сильнее специализированы под AI. Их основа — массивы MAC-блоков, через которые веса, активации и промежуточные результаты передаются без постоянного обращения к памяти. Выполнением управляет компилятор, а сама архитектура изначально создавалась Google для нейросетевых задач.
NPU оптимизированы для энергоэффективного инференса на устройствах. Они используют MAC-массивы и встроенную SRAM, но работают с низкопотребляющей системной памятью вместо HBM. Такие процессоры устанавливают в смартфоны, ноутбуки, носимые устройства и IoT-системы. К этому типу относятся Apple Neural Engine и NPU от Intel.
LPU — архитектура Groq, созданная для обработки языковых моделей. Она исключает внешнюю память из критического пути: веса хранятся во встроенной SRAM, а выполнение полностью планируется компилятором. Это устраняет промахи кеша и накладные расходы на планирование во время работы.
Главный недостаток LPU — ограниченный объём памяти на одном чипе, поэтому для запуска крупной модели приходится объединять сотни процессоров. Однако это позволяет заметно снизить задержку.
Эволюция AI-железа движется от универсальных CPU к всё более специализированным архитектурам. На каждом этапе часть гибкости обменивается на производительность и энергоэффективность.
Общая задача всех этих архитектур — сократить перемещение данных. Сами вычисления не являются главным ограничением: сложнее обеспечить вычислительные блоки данными с достаточной скоростью.
Та же проблема возникает и на программном уровне. Во время инференса LLM один GPU может ежедневно создавать терабайты KV-кеша, большая часть которого затем удаляется и пересчитывается. Это одна из причин высокой стоимости агентных нагрузок.
👉 @BackendPortal
Один из самых умных трюков для защиты данных, которые я видел в продакшене?
—> Временной RLS (Temporal RLS)
Row-Level Security — это функция PostgreSQL, позволяющая управлять тем, какие строки может видеть пользователь, прямо на уровне базы данных.
Вместо того чтобы фильтровать данные в коде приложения, RLS переносит контроль доступа в саму БД
Представь себе WHERE, который всегда включён — и индивидуален для каждого пользователя или роли.
Пример использования:
Финтех-компании нужно было дать аналитикам доступ к транзакциям, но с задержкой в 24 часа, чтобы снизить риск мошенничества и инсайдерской торговли
Вместо написания логики в приложении или BI-инструменте, они полностью реализовали это на уровне базы данных.
Как?
1. Включили RLS на таблице
2. Определили политику фильтрации строк
3. Включили принудительное применение RLS для всех обращений (необязательно, но рекомендуется)
Даже если кто-то подключится к базе напрямую через psql, BI-инструмент или SQL-клиент — он увидит только строки, старше 24 часов. Без исключений.
⏩Безопасность обеспечивается у источника
⏩Политики версионируются вместе со схемой
⏩Код приложения не участвует
Вывод:
RLS — это не только про фильтрацию арендаторов. С его помощью можно строить умные правила: задержка по времени, доступ по пользователям, мягкое удаление — и всё это реализуется самой БД
👉 @BackendPortal
Даже в классическом SDLC инфраструктура форматов данных эволюционирует. Мы привыкли воспринимать Protobuf как монолит: proto-схема, wire format и парсинг — всё едино. Об этом был пост у руководителя разработки Яндекс Лавки Димы Александрова, в котором он поделился инструментом, разделяющим эти слои — YaFF (Yet another Flat Format).
Яндекс выложил его в опенсорс как альтернативный wire-формат для Protobuf с поддержкой zero-copy чтения. Основная идея в том, чтобы оставить привычные .proto-файлы и API, а способ хранения данных менять под задачу. В YaFF есть несколько стратегий упаковки: flat layout для плотных структур, sparse для разреженных, и dynamic, который сам выбирает оптимальный вариант.
Авторы сознательно не пошли по пути FlatBuffers, где нужно поддерживать отдельную схему и синхронизировать изменения. Здесь источником истины остаётся один protobuf-контракт, что делает внедрение относительно дешёвым. Сериализованное представление становится отдельным бэкендом, который можно подбирать под конкретную нагрузку.
Если захотите копнуть глубже, рекомендую статью на Хабре — там подробно разбирают и внутреннее устройство YaFF и примеры использования.
Сегодня разработка ПО уже не ограничивается только классическим жизненным циклом SDLC. Инженерам всё чаще приходится работать сразу с двумя подходами: SDLC и ADLC.
SDLC описывает привычный процесс создания программного продукта: от требований и проектирования до разработки, тестирования, деплоя и дальнейшей поддержки. Его задача — помочь команде выпускать надёжное и поддерживаемое ПО.
ADLC относится уже к разработке ИИ-агентов. Здесь недостаточно просто написать код и развернуть приложение. Нужно определить цель агента, продумать его архитектуру, промпты и сценарии работы, подключить инструменты и память, настроить оценку качества, ограничения безопасности, мониторинг и наблюдаемость.
SDLC при этом никуда не исчезает. На нём по-прежнему строятся обычные программные продукты вроде GitHub, Stripe, Notion и Slack.
Но с появлением Devin, Claude Code, Manus, OpenAI Operator и других агентных систем ADLC становится отдельной важной частью разработки.
Поэтому современному инженеру всё полезнее понимать оба подхода: как создавать традиционное ПО и как проектировать надёжных, безопасных и предсказуемых ИИ-агентов.
👉 @BackendPortal
Паттерн Outbox решает только половину проблемы.
Но что происходит на стороне consumer?
Outbox гарантирует, что событие будет опубликовано после коммита бизнес-транзакции.
Сервис может обработать событие, упасть до отправки подтверждения и затем получить то же самое событие повторно.
В результате появляются повторные списания, письма или обновления остатков.
Здесь помогает паттерн Inbox.
Consumer сохраняет ID сообщения и выполняет бизнес-операцию в рамках одной транзакции базы данных.
Если сообщение приходит повторно, consumer распознаёт его и пропускает дублирующую обработку.
Outbox защищает отправителя.
Inbox защищает получателя.
Вместе они дают практическую модель надёжности, которая нужна большинству распределённых систем:
Доставка как минимум один раз + идемпотентная обработка.
Exactly-once delivery — чаще всего лишь обещание.
Поведение, эквивалентное exactly-once, — это уже архитектура.
👉 @BackendPortal
Как Netflix справляется с резкими скачками трафика
Миллионы пользователей могут одновременно начать смотреть видео.
Вот как Netflix сохраняет надёжность:
● CDN кэширует видео ближе к пользователям, чтобы снизить задержку.
● Балансировщик нагрузки распределяет трафик между несколькими серверами.
● Микросервисы независимо обрабатывают аутентификацию, рекомендации, воспроизведение и биллинг.
● Redis кэширует часто запрашиваемые данные, чтобы снизить нагрузку на базу данных.
● Kafka асинхронно обрабатывает события для аналитики и системы рекомендаций.
● Автомасштабирование добавляет или удаляет серверы в зависимости от объёма трафика.
● Проверки состояния автоматически исключают неработоспособные экземпляры из балансировки.
● Развёртывание в нескольких регионах позволяет сервису оставаться доступным, даже если целый регион выходит из строя.
Хороший системный дизайн — это не только работа при обычной нагрузке. Главное — сохранять надёжность, когда всё идёт не по плану.
👉 @BackendPortal
Представили OpenShip.
Open-source-платформа для создания, развёртывания, эксплуатации и масштабирования приложений на вашей собственной инфраструктуре.
Замените инструменты деплоя, управляемые сервисы и инфраструктурные процессы одной open-source-платформой.
Доступно уже сегодня:
— Почтовый сервер (встроен, запускается в один клик)
• Работает на вашем собственном VPS
• Неограниченное количество доменов
• Неограниченное количество почтовых ящиков
• Современный веб-интерфейс для почты в комплекте
• Подключение через Gmail, Outlook, Apple Mail, Thunderbird или любой IMAP/SMTP-клиент
• Отправка писем напрямую из ваших приложений по SMTP
• Без подписок на почтовые ящики и платы за API
• Высокая доставляемость писем
— Деплой:
• Деплой любого стека
• Деплой на основе Git
• Деплой без простоев
• Откат в один клик
• Окружения Development, Staging и Production
• Деплой нескольких веток с изолированными окружениями
• Деплой на VPS, выделенные серверы, облачные виртуальные машины или домашнюю инфраструктуру
— Сервисы:
Разворачивайте необходимые вашим приложениям сервисы в один клик.
Замените несколько провайдеров управляемых сервисов решениями, работающими на вашей собственной инфраструктуре.
• Supabase
• PostgreSQL
• MySQL
• MariaDB
• MongoDB
• Redis
• MinIO
• Meilisearch
• Qdrant
• RabbitMQ
• Kafka
• ClickHouse
• Elasticsearch
...а также разворачивайте любые другие сервисы рядом со своими приложениями.
— Эксплуатация:
• Логи деплоя в реальном времени
• Логи запросов в реальном времени
• Аналитика трафика в реальном времени
• Автоматическое резервное копирование
• Мониторинг
• Управление секретами
• Домены
• Автоматический SSL
• Переменные окружения
• Задачи по расписанию
• Проверки состояния
— Несколько окружений:
• Отдельные окружения Development, Staging и Production
• Независимый деплой каждой ветки
• Тестирование изменений перед выходом в Production
• Изолированные сервисы, секреты и конфигурация для каждого окружения
— Безопасность и команды:
• Управление командами
• Ролевое управление доступом
• Правила разрешения и блокировки IP-адресов
• Ограничение частоты запросов
• Правила безопасности
— Удобство для разработчиков:
• Веб-панель управления
• Нативное десктопное приложение
• CLI
• REST API
• Поддержка MCP для ИИ-агентов: просто добавьте MCP, и ваш агент сможет выполнять работу за вас
• Управляйте своей инфраструктурой, не проводя всё время в SSH
— Скоро:
• Мультисерверная кластеризация приложений и баз данных
• Балансировка нагрузки в один клик
• Горизонтальное масштабирование на нескольких серверах
• Встроенная высокая доступность и автоматическое переключение при сбоях
• Масштабирование от одного VPS до кластера в рамках одного и того же рабочего процесса
• Просто добавляйте серверы. OpenShip сделает всё остальное.
Open source.
👉 @BackendPortal
На Stepik вышла программа «DevOps с нуля: от Linux до Kubernetes»
Это комплексная программа из 5 практических курсов по ключевым технологиям DevOps: Linux, Git, Docker, GitLab CI/CD, Kubernetes
Вы последовательно пройдёте путь от работы в Linux и управления кодом через Git до контейнеризации приложений, настройки CI/CD-пайплайнов и развёртывания в Kubernetes.
Что вы изучите:
• работу с Linux и командной строкой
• Git и контроль версий в реальных проектах
• создание Docker-образов и запуск контейнеров
• автоматизацию сборки, тестирования и деплоя в GitLab CI/CD
• развёртывание и управление приложениями в Kubernetes
• сети, хранилища, конфигурации и секреты
• диагностику инфраструктуры и автоматизацию рутинных задач
... и многое другое
DEVOPS20 стоимость всей программы составит 10 392 ₽.
Запустить локальную базу данных PostgreSQL с помощью Docker проще простого
Нужно протестировать или разработать приложение? Просто:
→ Создайте изолированную среду без конфликтов с другими сервисами
→ Используйте официальный образ PostgreSQL — стабильность и совместимость гарантированы
→ Настройте пароль суперпользователя через переменные окружения (-e)
→ Пробросьте порт (-p), чтобы подключаться с вашей машины или других контейнеров
→ Всё запускается одной командой — Docker сам подтянет образ, если его ещё нет
👉 @BackendPortal
То, что контейнер запущен, ещё не значит, что приложение работает корректно
Добавь полноценную проверку состояния (healthcheck). Пусть Docker сам разбирается, когда что-то ломается
👉 @BackendPortal
Rust заменяет C внутри ядра Linux.
Так говорит человек, который поддерживает Linux с 90-х.
Его зовут Грег Кроа-Хартман. Фактически второй человек после Линуса Торвальдса.
Он лично проверял почти все CVE ядра Linux, выпущенные за последнее десятилетие.
Когда-то он не любил Rust.
Однажды друг предложил ему попробовать. Его ответ был: «Что? Нет, C отличный». Друг возразил: «С ним программировать снова становится весело». Грега это не убедило.
Он ошибался.
На Rust Week 2026 в Нидерландах Грег представил предложение, разработанное вместе с контрибьютором ядра Бенно Лоссином, которое потенциально может устранить около 80% CVE, возникающих в ядре каждый год.
Новый тип Rust под названием Untrusted помечает на этапе компиляции любые данные, поступающие из user space или от железа. Работать с такими данными нельзя, пока вы явно их не провалидируете.
Linux генерирует примерно 13 CVE в день. Почти ни одна из них не связана со сложными атаками. В большинстве случаев это одни и те же ошибки C, которые повторяются десятилетиями: непроверенные указатели, забытые unlock, use-after-free — ошибки, которые Rust делает структурно невозможными.
На Open Source Summit India в этом году Грег сказал прямо:
«Ядро движется в сторону Rust. Git движется в сторону Rust. Многие проекты начинают переходить на Rust».
Человек, который когда-то говорил, что C отличный, теперь называет Rust «более приятным для мейнтейнеров» и способом сделать «Linux безопаснее для пользователей».
Rust больше не эксперимент внутри ядра.
Он становится одним из крупнейших изменений в Linux за последние десятилетия.
👉 @BackendPortal
Morning Banger: новый выпуск PING от APNIC про загадочное поведение DNS-запросов.
Почти каждый DNS-запрос, который видят APNIC Labs, появляется дважды, а иногда и больше. В обычный день система фиксирует около 150 млн уникальных DNS-меток, но получает примерно 270 млн запросов.
Почему DNS постоянно повторяет одни и те же запросы?
В новом выпуске PING George Michaelson и главный научный сотрудник APNIC Geoff Huston разбирают, что происходит внутри DNS-инфраструктуры и почему дублирование запросов — это не просто лишний трафик, а часть поведения самой системы.
Причины могут быть разными: кэши, прокси, повторные обращения браузеров, особенности DNSSEC и работа recursive resolver’ов. Повторный запрос может показывать, сколько резолверов стоит за пользователем и какие механизмы участвуют в разрешении домена.
Интересный разбор того, как на самом деле работает один из фундаментальных слоёв интернета.
https://blog.apnic.net/2026/07/23/podcast-dns-query-duplication/
👉 @BackendPortal
Один из лучших инструментов для создания диаграмм в разработке — и при этом бесплатный и совместимый с GitHub.
Подходит для UML-диаграмм, блок-схем и описания процессов.
Готовые схемы можно экспортировать в изображения, PDF, HTML и другие форматы.
→ http://app.diagrams.net
👉 @BackendPortal
Вышла новая статья о сборщике мусора Green Tea в Go.
Пейволл уже сняли, так что материал теперь можно прочитать бесплатно.
https://theconsensus.dev/p/2026/07/19/observing-gos-garbage-collector-old-and-new.html
👉 @BackendPortal
Лето — неплохое время, чтобы навести порядок в базе данных. Например, проверить, не накопились ли в PostgreSQL бесполезные индексы.pg_stat_user_indexes — системное представление PostgreSQL со статистикой использования индексов.
Со временем приложение меняется, вместе с ним меняются запросы, а старые индексы продолжают оставаться в базе. Некоторые из них больше не используются, другие срабатывают крайне редко. При этом каждый индекс создаёт дополнительную нагрузку при INSERT, UPDATE и DELETE.
В системах с большим количеством операций записи иногда выгодно удалить даже редко используемый индекс, если затраты на его обслуживание превышают пользу.
Посмотреть статистику можно так:
SELECT * FROM pg_stat_user_indexes;
idx_scan — количество сканирований индекса с момента последнего сброса статистики. 0 означает, что индекс не использовался.last_idx_scan — время последнего сканирования. NULL означает, что индекс ни разу не использовался после сброса статистики.idx_tup_read — общее количество записей индекса, возвращённых при сканировании.idx_tup_fetch — количество актуальных строк таблицы, реально полученных через индекс.idx_scan = 0: они создают нагрузку при записи, но не приносят пользы запросам.pg_stat_reset(), статистика может охватывать слишком короткий период. Лучше дождаться полного типичного цикла нагрузки.DROP INDEX CONCURRENTLY index_name;
ACCESS EXCLUSIVE.
😒 Подборка каналов по информационной безопасности
Проверенные каналы по безопасности, которые реально помогают расти.
👍 ZeroDay — Уроки, эксплуатация уязвимостей с нуля
👍 Белый Хакер — Свежие новости из мира ИБ
😎 Бункер Хакера — Статьи, книги, шпаргалки и хакинг
👨💻 Серверная Админа — Настройка и уроки по компьютерным сетям
📂 Подписывайся
При работе с JSONB знали ли вы, что следующие запросы функционально эквивалентны, но используют разные индексы?
Оба проверяют, что по пути user.city находится значение "Denver", но первый использует извлечение значения по пути и оператор сравнения, а второй — оператор вхождения.
B-tree индекс по выражению, использует операторы сравнения:
data->'user'->>'city' = 'Denver'
data @> '{"user": {"city": "Denver"}}'
Наткнулся в интернете на интересную мысль:
Первое правило программирования - не делай хуже, чем есть сейчас.
Есть принцип забора Честертона: если ты видишь забор посреди поля, может показаться, что он лишний, и захочется его убрать. Но если ты не знаешь, зачем он там, ты рискуешь ошибиться и дорого за это заплатить.
В софте этот принцип означает: не стоит менять код, архитектуру или процессы, пока не поймёшь, зачем они сделаны именно так.
Любое изменение, будь то рефакторинг, апдейт или удаление — должно иметь чёткое обоснование - измеримый прирост в производительности, удобстве поддержки или опыте пользователей. Иначе легко внести лишние баги и сломать проект.
Очень просто сделать хуже, даже будучи опытным и с хорошими намерениями. Это не вопрос субъективного мнения, я постоянно вижу «оптимизации», которые работают во вред.
Да, кодовая база может казаться старой и грязной. И да, возможно, её действительно стоит организовать по-другому. Но с той же вероятностью ты можешь ошибаться.
Тут важно смирение. Всегда помни, что ты знаешь меньше, чем думаешь, кем бы ни был. Мы склонны переоценивать своё понимание системы.
Поэтому слушай других, кто помогает держать тебя в тонусе. Учись сомневаться в себе, особенно, когда работаешь с зрелым, хорошо протестированным кодом.
👉 @BackendPortal
Небольшой факт: компилятор Go добавляет скрытую проверку каждый раз, когда вы обращаетесь к элементу слайса по индексу, и у этой проверки есть реальная цена. Возьмём простую функцию:
func get(s []int, i int) int { return s[i] }s[i] компилятор внутренне добавляет сравнение индекса с len(s) и переход к panic, если индекс выходит за границы. Это две дополнительные инструкции при каждом вызове, которые нужны только для защиты от чтения за пределами слайса.unsafe.Add(unsafe.Pointer(unsafe.SliceData(s)), i)
panic. В итоге функция сводится буквально к нескольким ассемблерным инструкциям.unsafe. По умолчанию компилятор защищает вас, но как только вы переходите к unsafe, эта защита исчезает. Одна ошибка — и вы получаете повреждение памяти.
Дата-центры
На схеме показаны два дата-центра. В штатном режиме пользователи направляются через geoDNS, также называемый географической маршрутизацией, в ближайший дата-центр. При этом x% трафика приходится на US-East, а оставшиеся (100 − x)% — на US-West.
geoDNS — это DNS-сервис, который позволяет разрешать доменные имена в IP-адреса с учётом местоположения пользователя.
В случае серьёзного сбоя одного из дата-центров весь трафик перенаправляется в исправный дата-центр.
Технические сложности
> Перенаправление трафика
geoDNS можно использовать для перенаправления трафика в зависимости от местоположения пользователя.
> Синхронизация данных
Пользователи из разных регионов могут обращаться к разным базам данных и кэшам. При failover трафик может быть направлен в дата-центр, где нужные данные недоступны. Распространённая стратегия — реплицировать данные между несколькими дата-центрами.
> Тестирование и развёртывание
При конфигурации с несколькими дата-центрами важно тестировать сайт или приложение из разных географических локаций.
👉 @BackendPortal
Этот бесплатный инструмент превращает любую браузерную сессию в общий стрим, который можно смотреть вместе.
Он называется neko.
Он транслирует полноценный браузер с рабочим столом из Docker-контейнера через WebRTC, поэтому несколько пользователей могут одновременно наблюдать за одной сессией и управлять ею в реальном времени — вместо обычного шаринга экрана.
→ Совместное управление несколькими пользователями, а не только просмотр
→ Встроенная передача аудио, в отличие от Guacamole или noVNC
→ Подходит для совместных просмотров, удалённого тестирования и общих демо
Можно бесплатно развернуть на собственной инфраструктуре.
https://github.com/m1k1o/neko
👉 @BackendPortal
SCREENPIPE ВОШЁЛ В ЧИСЛО САМЫХ ПОПУЛЯРНЫХ RUST-РЕПОЗИТОРИЕВ НА GITHUB
• Записывает активность на устройстве, чтобы дать ИИ доступ к долгосрочной памяти с возможностью поиска
• Работает локально, ориентирован на конфиденциальность и уже набрал более 20 000 звёзд на GitHub
Репозиторий: https://github.com/screenpipe/screenpipe
👉 @BackendPortal
ЭТОТ ИНСТРУМЕНТ ПОМОГАЕТ ИИ ОРИЕНТИРОВАТЬСЯ ВО ВСЕЙ ВАШЕЙ КОДОВОЙ БАЗЕ
• Строит граф знаний, благодаря которому ИИ отслеживает связи между компонентами, а не перечитывает файлы заново
• Работает локально с Claude Code, Cursor и более чем 20 другими ИИ-агентами для программирования
Репозиторий: https://github.com/Graphify-Labs/graphify
👉 @BackendPortal
Back to Back — бэкенд-конференция Яндекса от инженеров для инженеров
1 августа | Москва, Белград, Ереван
Эксперты из Яндекса, Авито, Positive Technologies и других компаний выступят с докладами и поделятся практическими кейсами. В Москве пройдут сразу два трека: C++ Zero Cost и Architecture & Performance.
Антон Пионтковский (Yandex Cloud) расскажет, как считать range-предикаты с помощью битовых масок и как комбинировать их между колонками, Антон Полухин (Яндекс) поделится новостями со встречи международного комитета C++, а Савва Лебедев (Positive Technologies) покажет, как команда добавляет поддержку языка программирования LuaJIT в eBPF-профилировщик Perforator.
Темы остальных докладов по городам можно посмотреть здесь: Москва, Белград и Ереван.
Если планируете посетить конференцию в Москве, вас ждут экспертные сессии с разбором карьерных и личных запросов и выступление питерской группы «Научно-технический рэп».
Подробности и регистрация
Собеседования по системному дизайну — это на 80% вопросы и на 20% диаграммы.
Чем лучше вы уточняете требования, тем лучше получается архитектура.
Слабый кандидат слышит:
«Спроектируйте систему уведомлений».
И сразу рисует:
API → очередь → воркер → база данных
Сильный кандидат сначала задаёт вопросы:
1. Сколько пользователей?
2. Какие типы уведомлений нужны?
3. Email, SMS, push-уведомления или всё сразу?
4. Доставка должна быть в реальном времени или с задержкой?
5. Допустима ли повторная доставка одного уведомления?
6. Нужно ли сохранять порядок доставки?
7. Что происходит при сбое провайдера?
8. Могут ли пользователи настраивать свои предпочтения?
9. Как долго нужно хранить историю доставки?
Эти вопросы и есть проектирование.
Всё остальное — лишь визуализация того, что вы выяснили.
Каждый ответ меняет архитектуру:
* высокая нагрузка может потребовать партиционирования;
* строгий порядок влияет на устройство очередей, обычно на уровне пользователя или ключа;
* повторные попытки требуют идемпотентности;
* несколько провайдеров требуют механизма failover;
* пользовательские настройки добавляют фильтрацию;
* история доставки требует решений по хранению данных и срокам их ретеншена.
Диаграмма не должна строиться по памяти.
Она должна вытекать из выявленных ограничений.
На собеседовании по системному дизайну хорошие вопросы дают три преимущества:
→ уменьшают неопределённость;
→ выявляют компромиссы;
→ показывают ход вашего мышления.
Сначала требования.
Потом архитектура.
👉 @BackendPortal