Посты канала Типичный программист

Redis жив, соединение есть, ответа нет Выключить Redis в тесте полезно. Но неприятность бывает хитрее: соединение установилось и просто висит. Обработчик ошибки подключения при этом может и не сработать. Toxiproxy от Shopify ставят между приложением и зависимостью. Это TCP-прокси, условия в котором тест меняет через HTTP API. Можно задержать ответ, ограничить полосу или перестать передавать данные. При timeout = 0 данные не передаются, а соединение остаётся открытым до снятия ограничения. В Rails-примере проекта unit-тест проверяет, что при недоступном Redis метод tags возвращает пустой массив вместо исключения. Для проверки всей страницы авторы отдельно предлагают интеграционный тест. Задержка направленная. По умолчанию она действует от сервера к клиенту, для обратного направления нужна отдельная настройка.

Защитный парсер тоже читает опасный файл Медиафайл ещё не открыли, а защитный парсер уже разбирает его содержимое. Чтобы проверить файл до системной библиотеки, ему самому приходится читать недоверенные данные. После Stagefright в 2015 году WhatsApp добавил в библиотеку wamedia проверку структуры MP4. Исправить уязвимость в самой ОС команда не могла, зато могла отсеять опасный файл до системной библиотеки. В январском разборе миграции на Rust WhatsApp описывает, как проверяли совместимость: новую реализацию делали параллельно C++, затем кормили обе одинаковыми входами через differential fuzzing и сравнивали поведение. Плюс обычные unit- и интеграционные тесты. Rust здесь нужен, чтобы снизить риск ошибок памяти в самом защитном парсере. Проверка формата при этом не остановит все файловые атаки.

Карту можно достраивать, вычёркивая невозможное На анимации из проекта WaveFunctionCollapse часть карты уже нарисована человеком. Генератор достраивает окружение. Участок с надписью Fixed он сохраняет. В основе — ограничения на соседство. В перекрывающейся модели программа берёт маленькие узоры из образца, обычно 3×3. Затем выбирает область с наименьшей ненулевой энтропией, фиксирует вариант и вычёркивает несовместимые у соседей. Один выбор сужает следующие, и постепенно проступает картинка. Если для одной области вычеркнуть все варианты, получится противоречие. А локально согласованные тайлы ещё не гарантируют проходимый уровень. Для проходимости нужны отдельные правила. Название квантовое, но квантового компьютера тут нет. Видео — исходная демонстрация автора Максима Гумина.

Картинка с котом может положить сервер В учебном примере из разбора Cloudflare картинку с котом запрашивают 10 раз в секунду. Сервер картинок выдерживает только один запрос в секунду. Пока ответ есть в кеше, нагрузка до сервера не доходит. Через сутки TTL истекает, и все запросы идут к серверу. Начать обновление на пять минут раньше? Тогда толпа придёт на пять минут раньше. Без объединения запросов это только переносит перегрузку. Автор разбирает другой ход: каждый запрос локально бросает «кубик» и решает, пора ли идти за свежей картинкой. Ближе к истечению кеша вероятность растёт. Отдельный сервис блокировок не нужен, но и гарантии одного запроса нет: случайность может пропустить несколько или долго не пропускать ни одного.

Лог проще читать, когда важное видно цветом IP, UUID, время, уровень ошибки и ещё несколько чисел в одной строке. После сотой такой строки взгляд начинает пропускать всё сразу. tailspin подсвечивает узнаваемые фрагменты, не требуя отдельного описания формата для каждого сервиса. Он идёт по строкам и ищет даты, адреса, URL, числа и уровни сообщений независимо от позиции поля. Можно передать поток через stdin, например kubectl logs -f pod | tspin. Для просмотра файла инструмент использует pager less. На скриншоте проекта демонстрационные логи, не свежий инцидент. И сам инструмент не превращает текст в структурированные события, не хранит их централизованно и не ищет причину сбоя. Иногда достаточно более скромного улучшения: глазами легче зацепиться за нужную часть строки.

Свободного региона может не оказаться Перенести нагрузку туда, где сейчас спокойнее, выглядит хорошим аварийным планом. До события, которое весь мир обсуждает одновременно. В разборе чемпионата мира Meta пишет, что на финале исходящий трафик вырос на 46% примерно за четыре минуты в конце основного времени. Для WhatsApp привычный межрегиональный перенос не помогал: все регионы выходили на пик в один момент. Занять запас у соседа было негде. Поэтому региональные пики прогнозировали отдельно. Более 100 внутренних сервисов заранее нагрузочно проверили и подобрали им мощности. Это данные и опыт самой команды, но инженерный вопрос отсюда вполне общий: есть ли у вашего резервного ресурса причина стать занятым ровно тогда же, когда у основного?

В ядре Linux закрыли критическую уязвимость CVE-2026-98432 (CVSS 9,8), обновите ядро на серверах и перезагрузитесь. Anthropic рассказала, что эксплойт для неё написал сам Claude: он удалённо получает выполнение команд от root без учётных данных примерно за 53 минуты попыток. Код не публиковали. Ошибка сидит в обработке TCP-рукопожатия по IPv4 с ядра 4.4 и срабатывает до того, как подключение дойдёт до приложения. Эксплойт бьёт через порты Multipath TCP: в Linux их по умолчанию открывают программы на Go с версии 1.24. Сама ошибка от MPTCP не зависит. Исправления уже есть у Debian, Amazon Linux, Oracle Linux и частично у SUSE, у Ubuntu и RHEL пока нет. До патча Red Hat советует правило nftables, которое отбрасывает TCP-пакеты с опциями IPv4: оно снижает риск, но полностью не защищает. Ненужный MPTCP можно выключить через sysctl net.mptcp.enabled=0 с перезапуском сервисов. Команды и статус по дистрибутивам собрали на сайте. @neuro_channel

Весь Git перед глазами Самое утомительное в маленьком коммите порой не сам коммит, а переключение между status, diff и логом. В lazygit эти состояния видны в соседних панелях терминала: файлы, ветки, история и изменения выбранного объекта. На видео из проекта весь короткий путь помещается в один экран. Файлы попадают в индекс, рядом появляется diff, затем открывается ввод сообщения коммита. Не нужно держать предыдущий вывод команды в голове, чтобы понять, что именно сейчас подготовлено. Кроме файлов целиком можно добавлять отдельные строки и фрагменты. Но удобный интерфейс не отменяет смысл операций Git: rebase и cherry-pick остаются теми же действиями со своими последствиями. Выигрыш здесь в видимости состояния, а не в защите от любого неудачного решения.

Запустить программу не всегда значит создать процесс Успешный execve заменяет текущую программу другой внутри уже существующего процесса. Старый код после такого вызова продолжать работу не будет. Поэтому история «оболочка запустила команду» интереснее, чем просто ещё одна строка в списке процессов. В иллюстрированной главе CPU Land показан путь от пользовательского кода в ядро: передаются путь, аргументы и окружение, ядро распознаёт формат файла и загружает программу. Картинка помогает не смешать создание процесса с заменой того, что он исполняет. Материал разбирает Linux на x86-64 и вышел в 2023 году. Хороший повод разобраться в механизме, но не обещание, что детали загрузки и обработки скриптов одинаковы во всех ОС и версиях ядра.

Авария может начаться раньше, чем поднимутся новые инстансы Одна зона доступности легла. Остальные приняли её нагрузку, и теперь надо срочно добавить серверов. Но что, если API управления инфраструктурой тоже работает с перебоями? В разборе static stability AWS предлагает заранее убрать эту зависимость из пути восстановления. В примере сервис работает в трёх зонах и держит 50% запаса мощности. Тогда две оставшиеся зоны способны выдержать всю нагрузку без ожидания новых инстансов. Запас оплачивается и в спокойный день. Переключение трафика и проверки здоровья тоже остаются нужны. Но в момент аварии системе требуется меньше новых успешных действий. Это давний принцип из Builders Library, а не новая функция AWS. И 50% здесь следуют из конкретного примера с тремя зонами, универсальной нормой их считать нельзя.

Код, который можно распечатать на 3D-принтере Если двигать вершины мышкой не хочется, у CAD есть вариант для любителей параметров и функций. В OpenSCAD модель описывается текстом: соединить объёмы, вычесть отверстие, вытянуть плоский контур. Меняете радиус или расстояние в скрипте, пересобираете и получаете другой вариант детали. Для семейства похожих креплений такой способ может оказаться понятнее ручного повторения одних и тех же действий. На официальном скриншоте код и результат стоят рядом, связь видна сразу. Это прежде всего инструмент для инженерных форм. Художественную лепку и анимацию он не заменяет, а пригодность детали к печати всё равно нужно проверять. Сам скриншот исторический, по нему не стоит судить о свежем интерфейсе. 📎 Что умеет OpenSCAD

Что нужно знать для старта в кибербезопасности? Сейчас разберемся 23 ноября Positive Education впервые запускает онлайн-интенсив «Основы практической кибербезопасности». За три месяца участники разберут четыре фундаментальные области ИБ и применят знания в более чем 40 практических кейсах Интенсив подойдет начинающим специалистам по ИБ, сотрудникам ИТ и тем, кто переходит в новое направление кибербезопасности Что внутри • UNIX- и Linux-системы: устройство ОС, процессы, права пользователей и базовая защита • Сети: настройка окружения, анализ трафика, типовые атаки и защита • Windows и Active Directory: компоненты ОС, домен, учетные записи и уязвимости конфигурации • Веб-приложения: архитектура, анализ уязвимостей и безопасная разработка Как пройдет интенсив Из 80 академических часов 60 отведены практике. Участники будут настраивать системы и сети, исследовать атаки, работать с Active Directory и искать уязвимости. Пошаговые кейсы помогут разобраться в новых темах, самостоятельные позволят проверить себя 📄 Кстати, Positive Education получил государственную лицензию на образовательную деятельность. Это значит, что все выпускники программ получат не только цельную техническую базу для развития в SOC, AppSec, пентесте и инфраструктурной безопасности, а также документы установленного образца, а при самостоятельной оплате можно оформить налоговый вычет. Когда 📅 Старт: 23 ноября 2026 ⏳ Длительность: 3 месяца 💻 Формат: онлайн 📚 Объем: 80 академических часов 👉 Подробности и регистрация

Дерево проекта без тысячи строк в терминале Чужой репозиторий, несколько уровней вложенности, нужный файл где-то там. Обычный tree честно печатает всё, а читать это предлагается человеку. У broot другой подход: часть веток сворачивается в unlisted, и на экране остаётся обзор каталога. Начинаете вводить имя, fuzzy-поиск сужает дерево, но сохраняет вокруг найденного файла контекст. Есть и поиск по содержимому, когда название вообще не вспоминается. На скриншоте из проекта хорошо видна эта разница: не бесконечная простыня, а карта, по которой можно двигаться. Для перехода в выбранную папку в своей оболочке нужна shell-функция br. Самостоятельный процесс не может просто взять и поменять рабочий каталог родительского shell.

Дефицит ускорителей не отменяет простой В одном регионе свободен GPU, в другом нужен именно он. Или ускоритель есть, а CPU для подготовки данных уже занят. Поэтому «мощностей не хватает» и «часть железа простаивает» вполне могут быть правдой одновременно. Meta собирает временно свободные мощности для рекламных рекомендаций в общий пул. Если свободны и CPU, и ускорители, можно оценить больше кандидатов. Если в основном ускорители, часть запросов направляют более сильной модели без сопоставимого роста работы на CPU. Самая важная часть тут не раздача бонусов, а их быстрый отзыв. Базовую нагрузку защищают отдельно, дополнительную работу сбрасывают за миллисекунды, пока центральные регуляторы ещё догоняют ситуацию. Такая схема требует работы, которую можно безболезненно сократить. Произвольная LLM-задача этому условию не обязана соответствовать.

VK Видео в два раза ускорил запуск роликов. Инженеры разработали собственный пресет для сжатия видео, потому что стандартные плохо подходят под запрос платформы. Что получилось: файлы стали меньше в среднем на 20%, у некоторых роликов почти на треть, а картинка осталась прежней. Плюс другие технические улучшения. В итоге видео стартует вдвое быстрее в вебе, на телефонах и планшетах. Интереснее всего то, как это раскатывали. Сначала новый пресет применяли только к популярным видео. Теперь же он сам подстраивается под нагрузку: когда сервис свободен, через новый пресет идут все загрузки, а при пиках часть роликов уходит на старые настройки, чтобы публикация не залипала в очереди.

Пробел в имени файла ломает слишком уверенный скрипт На report.txt всё работало, на annual report.txt внезапно поехало. В shell незакавыченное раскрытие переменной может превратить одно имя в несколько аргументов. А символы шаблона добавят ещё и разворачивание по файлам. ShellCheck замечает такие ловушки до запуска. Он статически проверяет sh/bash-скрипты, объясняет подозрительные места и показывает диагностику прямо в редакторе или CI. На скриншоте из проекта есть и другие примеры: bash не умеет обычную арифметику с дробями, а правая часть сравнения в [[ ]] без кавычек считается шаблоном. Удобно, что для первой проверки достаточно shellcheck yourscript. Только зелёный результат не доказывает, что скрипт делает нужное: тест с неудобным именем файла всё ещё очень кстати.

GitHub Issues показывает данные, пока сервер ещё отвечает На записи переходы между issue выглядят почти мгновенными. Секрет не в том, что запросы вдруг перестали занимать время: часть данных уже лежит в браузере. Команда GitHub разобрала свою схему с IndexedDB и stale-while-revalidate. Сначала интерфейс показывает локальную версию, затем сверяется с сервером. Предварительное наполнение кеша запускают там, где пригодных данных ещё нет, с ограничениями частоты и защитой от перегрузки. По замерам команды, после этого около 70% React-навигаций укладывались в 200 мс. Это не время полной загрузки любого GitHub-экрана. И бесплатного чуда нет: локальная версия может устареть, а при первом заходе без кеша ждать всё равно придётся.

Один удачный запуск ещё не бенчмарк Команда отработала быстрее. Или просто данные уже оказались в кеше? hyperfine повторяет запуски и показывает среднее время, разброс и выбросы. На фоне красивого единственного замера это полезное занудство. Параметр --warmup позволяет отдельно прогреть программу перед измерениями, а --prepare выполняет подготовку перед каждым запуском. Важно заранее решить, какой сценарий сравнивается: первый холодный старт или обычная повторная работа. Это разные вопросы, и ответы тоже могут различаться. В ролике из README авторы сравнивают mypy и ty. Числа на экране относятся к их конкретному тесту и окружению, а не обещают такое же соотношение в любом проекте. Смысл инструмента в том, чтобы получить собственное воспроизводимое сравнение.

Путь к репозиторию тоже умеет портить кеш У Cloudflare ревьюер кода каждый раз получал почти один и тот же промпт, но общий кеш между репозиториями не работал. В переиспользуемую часть затесались путь к проекту и дата. Маленькая деталь, за которую платили на каждом ревью. Команда вынесла меняющиеся данные за границу общего префикса. Заодно убрала недоступные инструменты, повторное чтение данных и лишний финальный вызов, поменяла модели и уровень рассуждений. Средняя цена ревью снизилась с $2,43 до $0,77, медиана времени с 4:09 до 1:32. Но в разборе оптимизации есть и неудобный результат: performance-ревьюер на medium стал пропускать часть важных проблем. Это серия изменений, а не контролируемый эксперимент и не победа одного кеша. Смотреть нужно и на счёт, и на то, что агент перестал замечать.

У NASA есть фреймворк для полётного софта Очереди сообщений, потоки, компоненты с явными интерфейсами. Звучит знакомо, пока не выясняется, что всё это нужно роверу или вертолёту. F´, он же F Prime, разработали в JPL для полётных и других embedded-приложений. Компоненты общаются через порты, C++-фреймворк предоставляет базовую инфраструктуру и абстракцию ОС. Отдельные инструменты описывают соединения, генерируют код и помогают с unit- и integration-тестами. Интересно посмотреть, как здесь устроена повторная сборка системы из проверяемых частей. Сам фреймворк, конечно, не гарантирует успех миссии: конкретные железо, ограничения и проверки никуда не исчезают. На фото наземные испытательные модели роверов CADRE. Фото: NASA/JPL-Caltech.

Кто забрал всю сеть? Общий график показывает, что канал занят. Отлично, осталось понять кем. bandwhich раскладывает трафик сразу по процессам, соединениям и удалённым адресам. На видео из проекта видно, как вместо одного числа появляются конкретные потребители. Под капотом он захватывает пакеты и сопоставляет их с данными ОС: /proc в Linux, lsof в macOS, WinApi в Windows. Имена хостов пытается получить в фоне через reverse DNS. Так можно отличить фоновую загрузку от процесса, который вообще не должен был активно ходить в сеть. Для захвата нужны соответствующие права. А содержимое зашифрованных запросов от такой раскладки видимым не станет. Ещё нюанс: проект в режиме passive maintenance, критические ошибки исправляют, новые функции активно не разрабатывают.

Голое железо и root-доступ, ВМ со снапшотами по расписанию, Kubernetes с GitOps в проде или всё сразу. В фановом тесте от команды Deckhouse из таких ответов складывается один из 10 типов инфраструктуры. Укротитель давно научился жить с ВМ и Kubernetes рядом, но устал от двух центров управления. Соковыжималка запускает базы и ML прямо на железе, чтобы гипервизор не съедал производительность. Антиквар не трогает систему, которая работает с нулевых. А Повелителю облаков уютно до первого кругленького счёта. Грузчик и Коллекционер выпадают реже всех. Если достался один из них, ссылкой на результат точно стоит поделиться с командой. → Пройти тест и узнать свой тип

Git умеет запоминать ваши решения конфликтов Долгоживущая ветка, очередной rebase и знакомый конфликт в том же участке файла. Кажется, это решение уже набирали. Git умеет его запомнить: механизм rerere сохраняет исходный конфликт и результат ручной правки, если включён rerere.enabled. При следующем подходящем конфликте он пытается применить прежнее решение через трёхстороннее слияние. Это полезно, когда ветку приходится несколько раз сверять с изменяющейся основной веткой. Записывать решение вручную отдельной командой при каждом шаге обычно не нужно: merge, commit и rebase сами вызывают rerere в нужных местах. Но память Git не заменяет проверку смысла. Старый ответ может чисто примениться к коду и всё равно оказаться неверным. В базовом режиме без autoupdate результат остаётся в рабочем дереве, а индекс не меняется. Перед git add остаются просмотр diff и тесты. Экономится повторное редактирование, а ответственность за решение остаётся у разработчика.

SQLite может завершить коммит удалением файла Транзакция меняет несколько страниц базы, а питание может пропасть между двумя записями. Как после перезапуска получить «всё или ничего»? В разборе атомарного коммита SQLite важнейший момент выглядит буднично: удаляется файл журнала. Речь о rollback journal в режиме DELETE. Сначала SQLite сохраняет исходные страницы в журнал и сбрасывает его на устойчивый носитель. Затем записывает изменённые страницы базы и тоже синхронизирует их. Только после этого удаляет журнал. Пока он пригоден для восстановления, прерванные изменения можно откатить. После удаления транзакция считается завершённой. При открытии базы SQLite проверяет не просто наличие файла, а признаки «горячего» журнала, включая заголовок и блокировки. Всё это опирается на корректную работу синхронизации и хранилища. У WAL другой протокол. Здесь же эффект «всё или ничего» получается из строгого порядка действий и чёткой границы завершения.

Option в Rust не обязательно занимает дополнительное место У значения есть два состояния: оно присутствует или его нет. Кажется, для Option<T> к самому значению придётся добавить отдельный флаг. Но тип NonZeroU32 уже оставляет свободное состояние: число ноль в нём запрещено. Именно ноль можно использовать для None, а остальные значения остаются для Some. Поэтому Option<NonZeroU32> имеет тот же размер и выравнивание, что и NonZeroU32. Это гарантия документации Rust, а не удачное совпадение в одном эксперименте с компилятором. Такой приём называют null pointer optimization, хотя работает он и с числами NonZero. Гарантия распространяется на конкретный список типов, в том числе ссылки и некоторые указатели. Переносить её на любой Option<T> нельзя. Здесь ограничение типа даёт полезный бонус: отсутствие значения помещается в уже свободную комбинацию битов.

Кто испортил это поле? В объекте уже лежит неправильное значение. Где его записали, неизвестно, а при следующем запуске ошибка может исчезнуть. Отладчик rr предлагает сначала поймать сбой под записью, а потом сколько угодно раз разбирать один и тот же запуск в gdb. В примере проекта у объекта Firefox неверная ширина. Разработчик ставит watch -l mRect.width и выполняет reverse-cont. Отладчик идёт назад и останавливается на присваивании, которое изменило поле. Адреса объектов и порядок событий при повторном воспроизведении сохраняются, поэтому найденные зацепки не теряются после перезапуска отладки. Это работа с сохранённым исполнением. Для rr нужны Linux и совместимый процессор, в виртуальной машине ещё и доступ к аппаратным счётчикам. Есть ощутимая цена для параллельного кода: rr эмулирует одноядерную машину. Зато пойманный редкий баг больше не приходится ловить заново.

Один зашифрованный архив, несколько получателей и никакого общего пароля Нужно передать архив нескольким коллегам. Можно завести общий пароль и потом разбираться, кому его уже переслали. У утилиты age есть другой вариант: один файл шифруется на несколько публичных ключей, и каждый получатель открывает его своим секретным ключом. Список адресатов задаётся повторением -r или файлом с ключами через -R recipients.txt. Сами секретные ключи друг другу передавать не нужно. А благодаря обычным потокам Unix вывод tar можно сразу направить в age, без промежуточного незашифрованного архива на диске. Есть важная граница: шифрование само по себе не подтверждает личность отправителя. Принадлежность публичных ключей тоже нужно проверить отдельно. Удобство здесь вполне конкретное: несколько человек читают один архив, а передавать друг другу личные секретные ключи не приходится.

Как поймать причину торможения, которое уже закончилось Запрос иногда зависает, но к моменту включения трассировки всё снова работает. Тут полезен flight recorder из Go 1.25: он заранее собирает недавние события runtime в буфер в памяти. Когда программа замечает проблему, из буфера можно сохранить предшествующий ей фрагмент. В примере команды Go снимок запускается после первого ответа дольше 100 мс. Трасса приводит к неожиданному виновнику: defer b.mu.Unlock() внутри цикла. Блокировки снимаются только при выходе из функции, а та ещё успевает отправить HTTP-запрос. Всё это время другие горутины ждут. Самописец здесь помогает сохранить именно момент ожидания, который иначе легко пропустить. Порог в 100 мс относится к примеру, а буфер и сбор событий расходуют ресурсы. Зато не нужно копить трассу за несколько дней работы сервера ради одного редкого сбоя.

Сколько ключей придётся помнить ради дедупликации потока? Найти повторное событие по ключу легко, пока можно помнить все ключи за всё время. В непрерывном потоке такое состояние растёт без конца. В разборе дедупликации через Flink SQL автор сравнивает варианты с разными ограничениями. Срок хранения состояния, TTL, ограничивает память, но меняет поведение: после удаления ключа старый дубль снова может пройти как новое событие. Важен и результат запроса. Один вариант сразу выдаёт строку, а позже присылает её обновление. Другой ждёт, чтобы учесть запоздавшие события. Получатель должен уметь работать с выбранным режимом. Даже настройка TTL требует проверки: в рассмотренной версии подсказка STATE_TTL не применяется к оператору дедупликации. До запуска стоит прогнать поздний дубль, истечение срока хранения и обновление результата — именно на них короткий SQL начинает вести себя неожиданно.

Проверенный бот тоже может перегрузить сайт Известный поисковый робот может ходить только по разрешённым страницам и всё равно создавать слишком большую нагрузку. Проверка владельца бота сама по себе этого не предотвращает. Cloudflare описала подход к постоянной оценке проверенных ботов. Среди сигналов — соблюдение robots.txt и реакция на HTTP 429: снижает ли робот частоту запросов, учитывает ли указание подождать. Так доверие к боту должно зависеть от наблюдаемого поведения после проверки его личности. Владельцу сайта нужна возможность понять, за что робот получил определённую оценку. Публичные оценки в Cloudflare Radar пока заявлены как следующий шаг. Уже сейчас при разборе нагрузки полезно смотреть, что происходит после ответа «слишком много запросов»: клиент действительно отступает или немедленно приходит снова.