Автор этой статьи прогнал JOIN на таблице из миллиарда строк и проверил, насколько оправдан страх перед этой операцией.

Главный вывод: JOIN сам по себе не дорогой. Дорогими его делают конкретные вещи: отсутствие индексов на join-колонках, выбор SELECT * с широкими строками и неправильный порядок фильтрации.

Тезисы из бенчмарка:

— Правильно проиндексированный JOIN на миллиарде строк отрабатывает быстрее, чем денормализованная «One Big Table» при выборке нескольких колонок.

— OBT начинает выигрывать только когда нужно вытащить почти все колонки широкой строки, но это редкий паттерн.

— Главные виновники медленных JOIN-запросов: отсутствие индексов → full scan, CAST() в условии join → план не использует индекс, агрегация после join вместо до него.

Полезно перечитать, если у вас есть коллега, который денормализует всё подряд «ради производительности».

@prog_stuff

USB устроен как сетевое программирование — только это мало кто объясняет именно так

Endpoint — это порт. Дескриптор устройства — аналог DNS-записи. Хост всегда инициирует соединение, устройство только отвечает. Если вы работали с сокетами, модель USB окажется неожиданно знакомой.

Перевод на Tproger разбирает USB с разработческой точки зрения: четыре типа передачи данных, как читать дескрипторы, и главное — как написать полноценный драйвер в userspace через libusb, без единой строки кода ядра.

В качестве практического примера — Fastboot-клиент на C++ примерно в 50 строк.

Материал стоит отложить: он даёт концептуальную рамку, после которой USB перестаёт быть чёрным ящиком.

9 нативных API браузера, ради которых обычно зря ставят npm-пакет

Справочник-пособие на случай, когда в следующий раз рука потянется к npm install: разбор девяти вещей, которые браузер уже умеет сам. requestIdleCallback для фоновых задач, :focus-within вместо сорока строк JS на focus и blur, navigator.onLine и события offline/online для PWA, requestAnimationFrame вместо setInterval на 16 мс, container queries для самодостаточных компонентов.

Дальше интереснее: crypto.randomUUID() вместо самописных «достаточно случайных» ID, нативный <dialog> с фокус-трапом и доступностью из коробки, Web Speech API для распознавания речи и @supports для CSS feature detection.

Полезно сохранить и перечитать, когда в следующий раз захочется тянуть в проект uuid, focus-trap или очередной модал.

Устали от уймы API-ключей и танцев с бубном вокруг OpenAI, Claude и Gemini?

Снять эту головную боль может один API-роутер.
Разбираемся на Tproger, почему три разных API могут тормозить ваш проект и как подключить GPT-5.4, Claude Sonnet 4.6 и Gemini 3.1 Pro через единую точку входа без переписывания кода.

Кратко о содержании:
— Что умеет хороший роутер: fallback, балансировка, кеш, единый биллинг.
— Пошаговый гайд подключения через одни API на Python и Node.js.
— Реальный кейс: мультимодельный бот с авто-переключением за 30 минут.
— Подводные камни: контекстные окна, latency, rate limits (и как их обойти).

Читать материал: https://tprg.ru/YWhU

TanStack тихо съедает экосистему React — история про то, как реально меняются экосистемы

Два года назад TanStack означал одно — React Query. Сегодня это восемь взаимосвязанных библиотек: Query, Router, Table, Form, Start, Store, DB и AI. Они постепенно вытесняют Next.js, React Router, Redux, React Hook Form и Zustand — не анонсами и не виральными твитами, а по одной зависимости за раз.

Цифры из State of React 2026 показательны: у TanStack Query 68% использования и 1% негатива, у Next.js — тот же охват, но негатива в 17 раз больше. Причина структурная: библиотеки headless, сквозная типизация идёт от URL до server functions, и вы владеете кодом, а не воюете с фреймворком.

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

Постоянный доступ в Kubernetes: как атакующие закрепляются в кластере и остаются незамеченными

Вы думаете, что если злоумышленник получил доступ к ноутбуку администратора на пять минут — это не страшно? А зря.

Чтобы изменить мнение, советуем почитать перевод статьи Рори Маккьюна «Beyond the Surface» — детальный разбор одного реального вектора атаки на Kubernetes. Автор показывает, как с помощью встроенных механизмов (kubectl debug, containerd, статические манифесты, CSR API, Token Request API) можно:
— получить root-доступ к узлу;
— запустить скрытый контейнер в обход API;
— организовать удалённое управление через Tailscale;
— создать вечные учётные данные, которые невозможно отозвать без ротации корневого сертификата.

В статье — не только техники атак, но и чёткие признаки обнаружения, а главное — меры защиты: изоляция API-сервера от интернета, минимальные привилегии RBAC, централизованные логи узлов.

Полный текст: https://tprg.ru/gfJ6

Три ИТ-события, которые вы могли пропустить (а зря)

Пока все гонятся за хайповыми новостями, мы вместе с коллегой Андреем Дмитриевым из JUG.ru собрали события, которые уже повлияли на мир разработки.

В пилотном выпуске нового подкаста:
— Хакеры стерли десятки тысяч ПК через Microsoft Intune
— Дефицит оперативной памяти до 2030 года
— Оптимизация glibc под x86_64

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

Особое внимание предлагаем уделить рефлексии. В выпуске мы подсветили, почему те или иные истории важны для ИТ-сообщества. А теперь призываем вас в комменты под видео: что уже вошло в вашу жизнь из этих кейсов? И как думаете, что из этого не производит резонанса?

Смотрите подкаст и присоединяйтесь к дискуссии: https://tprg.ru/S7jD

А вот и продолжение истории про то, как ИИ-агент Kiro от Amazon снёс всё продакшен-окружение из-за мелкого бага.

Помните, Amazon заявил, что это была «ошибка пользователя», и просто ввёл обязательное код-ревью человеком для любых изменений в проде? Как выяснилось, это была только часть решения.

Внутри компании проблему решили устранить радикально — добавить ещё больше ИИ. Вместо того чтобы забрать у агента расширенные права или ограничить его песочницей, Amazon внедрил систему, где один ИИ следит за другим.

Теперь рядом с Kiro работает агент-надзиратель. Его задача:

— Выступать в роли «архитектурного критика» (circuit breaker), который в реальном времени оценивает план действий первого агента.

— Проверять, не нарушают ли действия базовые правила (anomaly thresholds) вроде «не удалять ресурсы без бэкапа».

— Блокировать выполнение скрипта (kill switch), если первый ИИ внезапно отклонился от изначального плана.

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

Интересно, когда агент-надзиратель решит, что для максимальной безопасности проще всего отключить дата-центр от интернета?

@prog_stuff

Как Shazam узнаёт песню за секунды — разбор от Perthirtysix

Микрофон ловит звук и превращает его в waveform, по сути последовательность чисел, давление воздуха во времени. Сырые волны бесполезны: та же песня громче даёт другой waveform.

Поэтому телефон прогоняет звук через Fast Fourier Transform. Каждые 23 миллисекунды FFT раскладывает кусок волны на частоты — какие чистые тона нужно сложить, чтобы получить этот фрагмент. Складываем срезы рядом, получаем spectrogram: время по X, частота по Y, яркость = громкость.

Но хранить весь spectrogram невозможно. Алгоритм выкидывает почти всё и оставляет только самые громкие пики — sparse constellation map. Это делает систему устойчивой к шуму: фон добавляет низкий уровень энергии, но редко создаёт самый громкий пик в регионе.

Понятно, что один пик ничего не значит, 1200 Hz встречается в тысячах песен. Но пара пиков: 1200 Hz и 2400 Hz с разницей в 0,3 секунды уже специфична. Алгоритм берёт каждый пик как anchor, определяет target zone справа от него и создаёт hash из двух частот и временного интервала.

Поиск работает через inverted index: вместо «какая песня совпадает?» система спрашивает «для каждого звука из клипа, в каких песнях он есть?». O(1) lookup, независимо от размера базы. Финальная проверка по timing: если хэши в клипе разделены 1,2 секунды, в песне тоже должны быть на том же расстоянии.

В полной статье, конечно, понятнее и с интерактивными демо, рекомендую: https://perthirtysix.com/how-the-heck-does-shazam-work

Интерактивы типа как на видео в этом посте.

@prog_stuff

Откуда в России взялись программисты — история, которую вам не рассказывали

Если вы думаете, что российский IT начался с нулевых — нет. Всё началось на несколько десятилетий раньше, в закрытых НИИ и институтских подвалах.

В конце 1940-х Советскому Союзу понадобились вычислительные машины — моделировать ядерные реакции и считать ракетные траектории вручную было нереально. Учёный Сергей Лебедев построил первую советскую ЭВМ, а потом серию БЭСМ. Пиковая модель, БЭСМ-6, выпускалась почти 20 лет — именно на ней учили программированию в лучших технических вузах.

Культура, сложившаяся в условиях жёстких ограничений, никуда не исчезла. Она и стала фундаментом для Яндекса, Контура и всего остального российского бигтеха.

Читайте все 7 фактов на Tproger

@tproger
Читайте также в VK, Max и Дзен

Современные CPU ненавидят непредсказуемые условные переходы. Если данные случайные, branch predictor постоянно ошибается, и процессор сбрасывает pipeline снова и снова.

Пример из статьи: фильтруем массив, оставляя элементы меньше 500.

Классический подход с if:

if (numbers[i] < 500) {
    small_numbers[j] = numbers[i];
    j += 1;
}

Результат на Apple M1: 0,329 сек за 1000 итераций.

Branchless версия — без ветвления, unconditional store + conditional increment:

small_numbers[j] = numbers[i];
j += (numbers[i] < 500);

Результат: 0.036 сек. Разница в 9 раз.

На ассемблере вместо условного b.gt (branch if greater) используется cinc на ARM или setle на x86 — инкрементируем индекс, только если условие выполнено. Никаких прыжков, pipeline работает на полную.

Почему компилятор не делает это сам? Он не знает природу данных. Если почти все элементы проходят фильтр, branch predictor почти всегда прав, и if версия быстрее. А unconditional write может быть небезопасен — например, если за границей буфера лежит чужая память.

Интересный нюанс: branch predictor имеет ограниченную «память». На массиве из 10K элементов gap исчезает, потому что CPU запоминает паттерн. На 100K — predictior переполняется, и branchless выигрывает снова.

Quicksort, кстати, идеально ложится на branchless: партиционирование вокруг pivot — это ровно та задача, где ветвление убивает производительность.

Полная статья: https://easylang.online/blog/branchless

@prog_stuff

Microsoft выложила в open source самый ранний известный исходный код DOS — ядро 86-DOS 1.00, несколько development-снапшотов PC-DOS 1.00 и классические утилиты вроде CHKDSK.

Исторический контекст: Tim Paterson написал 86-DOS (тогда ещё QDOS — «quick and dirty operating system») для Intel 8086-компьютера от Seattle Computer Products. Microsoft лицензировала его для IBM PC 5150, выкупила права, переименовала в MS-DOS — и запустила эпоху PC.

Релиз позволяет посмотреть, как выглядела самая ранняя версия системы, которая стала фундаментом для десятилетий доминирования Microsoft на рынке персональных компьютеров.

Полная статья: https://arstechnica.com/gadgets/2026/04/microsoft-open-sources-the-earliest-dos-source-code-discovered-to-date

@prog_stuff

Как именно контейнеры создают иллюзию полноценной Linux-системы внутри, используя только базовые инструменты Linux: unshare, mount и pivot_root.

Что разбирается в статье:

— Mount namespace — почему это фундамент изоляции, а PID, cgroup, UTS и network играют второстепенные роли.

—Mount propagation — как mount-события распространяются между namespaces и почему просто unshare недостаточно.

— pivot_root — как меняем корневую файловую систему процесса, чтобы он видел только то, что ему положено.

— Собираем вручную Docker-подобный контейнер, который запускается стандартными командами Linux.

Полная статья:
https://labs.iximiuz.com/tutorials/container-filesystem-from-scratch

@prog_stuff

C3 — системный язык в традициях C — пять лет использовал unsigned типы для размеров и индексов, как C, C++, Rust и Zig. Казалось логичным: размер не может быть отрицательным. Но на практике это порождало классические баги: бесконечные циклы при декременте, сломанные сравнения при смешивании signed и unsigned, неявные конвертации, которые превращали -1 в огромное положительное число.

Точкой перелома стал невинный пример (foo + a) % 2. В C3 операция int + uint продвигалась в signed, что чаще работало правильно. Но если foo оказывался больше INT_MAX, результат становился непредсказуемым. Проблема не в сложности исправления, а в том, что это неожиданно: везде «просто работало», а тут вдруг ломается.

Ещё один показательный случай — кольцевой буфер. С signed типами ((start + offset) % length + length) % length корректно обрабатывает отрицательный offset. С unsigned та же формула молча даёт неправильный результат, и компилятор не подскажет, что offset_back обработан неверно.

Автор языка отмечает, что Java в 90-х полностью отказалась от unsigned типов, а Go — язык низкого уровня от разработчиков, прекрасно знавших цену unsigned, — изначально выбрал signed размеры. Границы unsigned (0 и 4 млрд для 32-бит) лежат критически близко к рабочему диапазону, тогда как у signed опасная зона — где-то в районе ±2 млрд. Переполнение unsigned не бросается в глаза: оно даёт вполне правдоподобное число, просто неправильное.

После перехода на signed тип sz (вместо usz) код оказался проще и очевиднее. Неявные конвертации между signed и unsigned убраны полностью. Автор признаётся, что привычка использовать unsigned была настолько глубоко внутренней, что переход казался «запрещённым» — но данные оказались неумолимыми.

Полная статья: https://c3-lang.org/blog/unsigned-sizes-a-five-year-mistake/

@prog_stuff