Посты канала Сохранёнки программиста

Go 1.27 сохраняет HTTP-соединение после закрытия непрочитанного ответа Клиенту нужен только статус ответа, поэтому он вызывает resp.Body.Close() и идёт дальше. В Go до версии 1.27 непрочитанное тело HTTP/1-ответа мешало повторно использовать соединение. Следующий запрос мог снова тратить время на TCP и TLS. В Go 1.27 транспорт дочитывает остаток в фоне: на это выделено до 50 мс и 256 КБ. Если тело удалось прочитать до конца, соединение можно вернуть в пул. При заголовке Connection: close эта работа пропускается. В примере команды Go сто последовательных HTTP/1-запросов заняли около 150 мс вместо 710 мс на прежней версии. Проверьте код, где тело ответа закрывается сразу после получения статуса или чтения JSON. На Go 1.27 обычного Close() достаточно, чтобы транспорт сам попробовал сохранить соединение.

SQL-запросы и ход расследования можно хранить рядом с кодом Нашли причину сбоя, отправили вывод в чат, закрыли вкладки. Через месяц похожая проблема возникает снова, и запросы приходится собирать заново. В Supabase появились Explorer и Notebooks: в одном документе можно сохранить запросы к базе и логам, графики и заметки о проверках. Файл хранится в папке supabase, попадает в Git и проходит обычное ревью. При повторном запуске запросы получают актуальные данные. Так удобно оформлять проверки после деплоя: какие ошибки появились, какие запросы замедлились, что изменилось в нагрузке. Explorer пока доступен в режиме предварительного просмотра. Начните с одного повторяющегося расследования и сохраните шаги, по которым коллега сможет его воспроизвести.

WAF может проверить ответ сервера перед отправкой клиенту Запрос пытается открыть служебную страницу без авторизации. Приложение возвращает HTML административной панели. Проверка ответа помогает увидеть, что сервер действительно отдал закрытое содержимое. В Cloudflare WAF добавили сопоставление запроса с ответом. Правило может учитывать путь, состояние авторизации, код ответа и другие доступные признаки. При совпадении WAF подменяет ответ страницей блокировки до отправки клиенту. Начать можно с узкого сценария: проверить обращения к административным адресам и посмотреть, какие ответы получает неавторизованный посетитель. Сначала соберите события в журнал, затем настройте блокировку. Пользовательские правила по содержимому тела ответа пока недоступны. Блокировка ответа также не отменяет действия, которые приложение уже успело выполнить на сервере.

Два распаковщика могут увидеть разные файлы в одном tar-архиве Сервис проверяет архив и видит безопасный файл. Установщик открывает тот же архив — и находит дополнительный файл с другим содержимым. Такое возможно, когда программы по-разному трактуют записи tar. В разборе tar-codec есть примеры расхождений, из-за которых проверка и последующая распаковка получают разные наборы файлов. Команда Astral столкнулась с этим при работе над uv и написала более строгий парсер. Начиная с uv 0.13 он используется для обработки исходных пакетов Python. Если ваш сервис принимает архивы, проверьте всю цепочку: чем проверяете содержимое, чем распаковываете и какие варианты формата разрешаете. Добавьте в тесты архивы с повторяющимися именами и неоднозначными заголовками. Проверяющая и использующая файл части системы должны одинаково понимать его содержимое.

GitHub автоматизировал пересмотр доступов внешних участников Подрядчик закончил работу, тестовый проект закрыли, а права на репозиторий остались. Когда таких проектов десятки, ручную проверку легко отложить. В GitHub для общей организации создали приложение Evergreen. Раз в квартал оно открывает задачу со списком внешних участников. Владелец подтверждает тех, кому доступ ещё нужен. По истечении срока неподтверждённые права отзываются. Отдельный процесс ищет репозитории без недавней активности людей: сначала предупреждает владельца, затем архивирует проект. Решения и изменения сохраняются в задачах и JSON-файлах управляющего репозитория. Для своей команды можно начать с одного действия: назначить владельца каждому репозиторию и дату следующего пересмотра доступов. Затем автоматизировать напоминания и журнал решений.

Общий ключ шардирования помогает оставить JOIN внутри одной базы Таблицы клиентов и заказов распределили по разным серверам: клиентов — по id, заказы — по собственному id. Теперь запросу «клиент и его заказы» приходится собирать данные с нескольких шардов. В разборе групп шардирования показан другой подход: размещать заказы по customer_id, используя то же правило распределения, что и для клиентов. Связанные строки окажутся на одном шарде, где можно выполнить JOIN и транзакцию локально. Перед выбором ключа выпишите основные запросы приложения. Какие таблицы они соединяют? Какие строки меняются вместе? Какой идентификатор известен в начале запроса? Эти ответы помогут выбрать размещение данных. Особенно полезно проверить запросы, в которых будущего ключа шардирования вообще нет: для них может потребоваться обращение к нескольким шардам.

git add --resolved добавляет исправленные конфликты отдельно от остальных правок Во время слияния исправили конфликт в одном файле. В другом осталась локальная правка, которую пока рано включать в коммит. В Git 2.56 появилась команда для этого случая: git add --resolved git status --short Она рассматривает только пути с неразрешёнными конфликтами в индексе. Перед добавлением проверяет обычные файлы на оставшиеся маркеры конфликта. Если находит их, сообщает о проблеме и оставляет индекс без изменений. Можно передать путь, чтобы ограничить проверку отдельными файлами. После команды посмотрите git status и подготовленный diff: маркеры будут проверены, а правильность объединённого кода нужно оценить отдельно.

Каскадное удаление может поставить запись в базу в очередь Удаляете организацию одной командой. Через ON DELETE CASCADE PostgreSQL удаляет её пользователей, заказы и связанные записи дальше по цепочке. Вся работа выполняется в одной транзакции. В разборе PlanetScale показан сценарий: долгое удаление удерживает блокировки таблиц, миграция ждёт эксклюзивную блокировку, а новые запросы выстраиваются за миграцией. Запись в приложение начинает зависать. Перед массовым удалением проверьте объём связанных данных и индексы на столбцах внешних ключей. Для крупных операций предусмотрите удаление ограниченными порциями с короткими транзакциями. У миграций настройте lock_timeout, чтобы они быстро завершались ошибкой при занятой таблице и могли быть повторены позже.

GitHub CLI научился автоматически обновлять короткоживущие токены GitHub CLI получил режим авторизации с токенами, которые истекают через несколько часов. CLI сам обновляет их с помощью отдельного обновляемого токена. Режим доступен в публичной предварительной версии начиная с gh 2.103.0. Для подключения выполните gh auth login --expiring. Проверить авторизацию можно через gh auth status, настроить помощник для Git по HTTPS — через gh auth setup-git. Рекомендуется Git 2.46 или новее. Подробности работы режима есть в инструкции по авторизации. Если скрипт использует токен из CLI, запрашивайте его через gh auth token перед каждым использованием. Однажды сохранённое значение перестанет работать после истечения срока. Существующая авторизация переключается на новый режим отдельно.

Зависимые изменения можно отправить на ревью цепочкой pull request Новая функция иногда требует сначала изменить модель данных, затем API и только потом интерфейс. Работу удобно разбить на связанные pull request: каждый содержит отдельный шаг и опирается на предыдущий. В GitHub стали общедоступны цепочки pull request. Интерфейс показывает связи, поддерживает перебазирование цепочки и совместное слияние готовых частей. При перебазировании одобрения сохраняются для кода, который остался прежним. Попробуйте подход на следующей большой задаче: выделите шаги, которые ревьюер сможет понять и проверить отдельно. В описании каждого PR укажите его место в цепочке и зависимости.

Обновление устройства нужно проверять с обрывом связи посередине Устройство скачало половину прошивки и потеряло связь. После перезапуска оно должно понимать, на каком этапе остановилось и как продолжить работу. Для батарейного датчика важна ещё и энергия: потраченный заряд восстановлением старой версии не вернуть. В разборе проекта с 800 тысячами датчиков в 3000 магазинов описаны безопасная загрузка обновлений, проверка образа, переключение разделов и сохранение состояния установки. Развёртывание нужно отслеживать вплоть до отдельных устройств и групп. Составьте сценарии прерывания: потеря сети при скачивании, перезапуск после проверки образа, отключение питания при установке. Для каждого зафиксируйте, с какой версией устройство запустится и как оператор узнает о результате.

Как Cloudflare освободил 100 ТБ памяти за счёт хеширования В маршрутизаторе Cloudflare таблицы согласованного хеширования занимали до 6 ГБ на процесс. Они помогали направлять запросы к нужным кеширующим серверам. Запись с хешем и индексом сервера упаковали из восьми байтов в шесть. Затем пересчитали необходимое число хешей и сократили его на 90% без существенного ухудшения распределения. Вместе изменения освободили более 100 ТБ памяти по всей инфраструктуре. В разборе есть полезная деталь про Rust: замена поля u32 на u16 оставила размер структуры прежним из-за выравнивания. Если храните миллионы небольших записей, проверьте их фактический размер через size_of и посчитайте общий расход памяти.

Roaring хранит редкие идентификаторы без огромного битового массива Обычный битовый массив занимает память вплоть до самого большого индекса. Один установленный бит с индексом около четырёх миллиардов потребует примерно 500 МБ. Roaring хранит разреженные участки списками чисел, плотные — битовыми массивами, последовательности — диапазонами. Структура выбирает представление для каждого участка и поддерживает объединение и пересечение множеств. Это полезно для аудиторий пользователей, прав доступа и фильтров по идентификаторам. Поддержка появилась в предварительной версии Redis 8.12 RC. Для эксперимента возьмите реальные наборы ID и сравните память и скорость пересечений с текущим решением.

Как GitHub прокручивает миллион строк кода с сотнями комментариев В GitHub Copilot app проверили pull request с 2200 файлами, миллионом изменённых строк и более чем 400 комментариями. Для плавной прокрутки интерфейс одновременно держит около сотни строк, переиспользуя элементы по мере движения. Основная сложность — комментарии: их высота меняется из-за переноса текста и картинок. В разборе интерфейса показано, как геометрию кода отделили от геометрии комментариев. Динамические блоки измеряют рядом с видимой областью, а при пересчёте сохраняют положение строки, которую читает пользователь. Приём пригодится для чатов, журналов событий и больших таблиц. Проверьте свой список на длинных сообщениях, загрузке изображений и изменении ширины окна: там часто появляются скачки прокрутки.

Линковщик mold сократил линковку Node.js с 2,52 до 0,13 секунды После компиляции линковщик собирает объектные файлы в исполняемый файл. Этот этап тоже стоит измерить: на большой кодовой базе он может удлинять каждую сборку. В сравнении на Node.js GNU ld потратил 2,52 секунды, а mold с восемью потоками — 0,13 секунды. Измеряли финальную линковку 160-мегабайтного файла на Linux-сервере с 64 ядрами, взяв медиану шести запусков. В GCC и Clang линковщик выбирается флагом -fuse-ld=mold. Попробуйте его на своей сборке и отдельно замерьте время линковки.

Как не скачивать 128 МБ ради небольшого фрагмента файла Видеоплеер может запросить небольшой фрагмент файла через HTTP Range. Кеш иногда скачивает гораздо больше: у Cloudflare R2 запрос на границе двух блоков по 64 МиБ мог привести к загрузке 128 МиБ. В разборе Origin Range Requests показано, как новая обработка диапазонов объединяет данные из кеша с ответом исходного сервера. На трафике R2 время до первого байта на 99-м перцентиле сократилось примерно вдвое. Если раздаёте большие файлы, сравните объём запрошенных и фактически скачанных данных. Функция включается через Cache Rules → Origin Range Requests. Исходный сервер должен поддерживать запросы диапазонов.

В первых тестах Rust-порт TypeScript оказался до восьми раз быстрее TypeScript 7.0 Cloudflare и VoidZero работают над tsrs — переносом компилятора TypeScript на Rust. В ранних замерах команды он работал до восьми раз быстрее TypeScript 7.0 и использовал примерно на 70% меньше памяти при одинаковом числе рабочих потоков проверки типов. Сравнение важно читать вместе с условиями. TypeScript 7.1 beta уже сама показывает ускорение до 2,5 раза относительно 7.0, поэтому «в восемь раз быстрее TypeScript» без указания версии было бы неточно. Авторы намерены сохранять поведение языка в соответствии с оригинальной реализацией и работают совместно с командой TypeScript. За проектом стоит следить тем, у кого проверка типов заметно задерживает сборку. Пока это ранние результаты на выбранных нагрузках, а не обещание такого же ускорения для любого репозитория. #typescript #компиляторы #rust

MicroVM может начать работу, не загружая весь снимок памяти DigitalOcean восстанавливает подготовленные виртуальные машины из снимков. Страницы памяти и блоки диска загружаются по мере обращения, поэтому запуск не ждёт полного скачивания состояния. Сеть тоже готовят заранее: на хосте поддерживают запас настроенных сетевых окружений. При запуске машине выделяют одно из них, а запас пополняют в фоне. Во внутренних тестах путь от запроса на выполнение до обслуживания трафика занимал менее 200 мс по медиане. Условия: готовый шаблон, свободные ресурсы хоста и прогретые кеши. Первичная загрузка образа в это время не входит. Подход переносит часть подготовки за пределы запуска, а часть откладывает. Цена остаётся: обращение к ещё не загруженной странице может приостановить выполнение. #виртуализация #производительность

Cloudflare сократила стоимость ИИ-ревью с $2,43 до $0,77 Команда проверила, на что ревьюер расходует токены, и обнаружила, что общий системный контекст плохо переиспользуется между репозиториями: рядом с ним в одном блоке находились меняющиеся дата и рабочая директория. Общую часть отделили для кеширования. Затем убрали недоступные инструменты, лишние повторные проверки и заключительный вызов модели после публикации результата. Меняли также модели и глубину рассуждений. Средняя стоимость упала на 68%, медианное время — с 4 минут 9 секунд до 1 минуты 32 секунд. Но экономия требовала проверки качества: некоторые конфигурации стали пропускать реальные замечания. Поэтому измерять стоит и расходы, и находки ревьюера. В статье эти проверки разобраны отдельно; общее сравнение затрат до и после изменений не было полностью контролируемым экспериментом. #ии #кодревью #оптимизация

GitHub снижает давление на общие базы и ограничивает распространение сбоев В сентябре GitHub зафиксировал два инцидента, ухудшивших работу сервисов. В отчёте доступности инженеры описали изменения: снижение нагрузки на общие базы, защиту от перегрузки и более строгую изоляцию сбоев при работе с pull request. Параллельно продолжался перенос инфраструктуры в Azure. К 7 октября в Central US работали 120 из 160 производственных сервисов, но туда перенесли только 13 из 51 основной базы MySQL. Миграция ещё не завершена. Разбор стоит читать как список конкретных ограничений: где нагрузка нескольких сервисов сходится на общей базе, как система отсекает лишнюю работу и какие операции могут повлиять на соседние. Для своей архитектуры можно начать с общего ресурса, от которого зависит больше всего пользовательских сценариев, и проверить его поведение при перегрузке. #надёжность #базыданных

Байесовский A/B-тест тоже требует правил остановки «Будем смотреть результаты каждый день и остановимся, когда вероятность победы достигнет 95%». Байесовский подход сам по себе не гарантирует, что такая процедура удержит долю ложных срабатываний на нужном уровне. Spotify разбирает, от чего зависят эти гарантии. Значение имеют исходные предположения о возможном эффекте, модель данных и правило остановки. Разные настройки дают разные свойства, хотя все называются байесовскими. Компания сохраняет частотный подход: поддержка второго режима усложнила бы планирование и чтение результатов, а достаточной пользы команда пока не видит. Перед выбором инструмента определите, какие ошибки вы хотите контролировать и когда будете завершать эксперимент. Потом проверьте, обеспечивает ли выбранная настройка именно эти гарантии. #статистика #abтесты

Два Kubernetes-контроллера могут рассогласовать состояние одного приложения Uber вынес управление масштабированием в отдельный контроллер. Основной продолжил заниматься развёртыванием, а новый стал учитывать, сколько экземпляров требуется при переключении после отказа. Но оба обновляли один Kubernetes-ресурс. В сочетании с задержками кеша это приводило к расхождению метаданных и конфигурации ReplicaSet. Иногда приложение застревало до ручного вмешательства. Команда добавила обнаружение таких расхождений и автоматическое исправление. Для передачи статуса между контроллерами использовала номер поколения: прежде чем сообщить об успехе, контроллер проверяет, что видит достаточно свежую версию данных. Весь переход занял год. В статье есть разбор гонок и интеграционных тестов через kind — пригодится, если несколько контроллеров меняют связанные ресурсы. #kubernetes #распределённыесистемы

Настройки фронтенда можно менять без пересборки JavaScript Если адрес API зашит в сборку, при переносе приложения из тестовой среды в рабочую приходится собирать его заново. Хотя в коде ничего не изменилось. Heroku описала другой способ: при запуске веб-сервер читает переменные с префиксом PUBLIC_WEB_ и записывает их в data-атрибуты элемента <head>. Приложение получает значения через document.head.dataset. Одна проверенная сборка подходит для разных окружений. Чтобы изменить настройку, потребуется перезапустить сервер, но пересобирать JavaScript не нужно. При переходе на такую схему придётся проверить, где приложение читает параметры: они не должны сохраняться в коде на этапе сборки. И передавать через HTML можно только публичные значения — посетитель сможет их прочитать. #фронтенд #конфигурация

Отказ соседнего сервиса не всегда должен ломать весь запрос Сервис оформления заказа обращается к нескольким системам. Без одной заказ не создать, а без другой можно обойтись. На схеме обе зависимости выглядят одинаково, но последствия отказа у них разные. Uber разбирает такие зависимости по деревьям вызовов. Если ошибка нижестоящего сервиса регулярно приводит к ошибке вызывающего, зависимость считают жёсткой. Если запрос продолжает выполняться — мягкой. Когда наблюдений недостаточно, вывод оставляют открытым. Так можно найти цепочки, по которым сбой доходит до пользователя, и точнее настроить оповещения. Для своего сервиса начните с одного важного сценария. Какие внешние вызовы обязательны для его завершения? Где предусмотрен запасной вариант? Затем проверьте по трассировкам, действительно ли приложение ведёт себя так, как задумано. #микросервисы #надёжность

Quick Tunnels ограничивает доступ к локальному приложению по адресам почты Показать приложение коллеге можно через временный адрес Cloudflare. Чтобы ссылка открывалась только нужному человеку, добавьте --allowed-mail: cloudflared tunnel --url http://localhost:8080 \ --allowed-mail [email protected] Посетитель вводит адрес и одноразовый код из письма. Cloudflare подтверждает владение почтой, а запущенный на вашей машине cloudflared сверяет адрес со списком разрешённых. В руководстве по защищённым Quick Tunnels показаны несколько адресов и маска домена. Возможность появилась в cloudflared 2026.9.3; аккаунт Cloudflare для этого сценария не нужен. Без --allowed-mail туннель остаётся публичным: приложение доступно любому, у кого есть ссылка. Чтобы изменить список, нужно остановить процесс и запустить новый туннель. Для постоянного имени и более сложных правил доступа авторы предлагают обычный Cloudflare Tunnel вместе с Cloudflare Access.

Удаление дублей из потока требует ограничить срок хранения уже встреченных ключей Чтобы распознать повторный заказ, обработчик должен помнить, что уже видел его идентификатор. Если помнить все ключи бесконечно, состояние будет расти вместе с потоком. В разборе Flink SQL David Anderson сравнивает DISTINCT, варианты ROW_NUMBER и собственную функцию обработки таблицы. Критерии шире, чем «дубли исчезли»: важны задержка, поздние события и наличие обновлений в выходном потоке. TTL ограничивает срок хранения состояния. После его истечения повторный ключ может снова пройти как новый. Значит, срок должен опираться на допустимый интервал повторной доставки. Есть и ловушка настройки: SQL-подсказка STATE_TTL не применяется к операторам Rank и Deduplicate. Для них автор указывает настройку TTL на уровне сессии. Перед выбором короткого SQL-запроса полезно проверить план выполнения и формат результата: поток только новых строк и поток изменений подходят разным потребителям.

Tachyon помогает найти дорогие вызовы в работающем Python-процессе В Python 3.15 появился статистический профилировщик Tachyon в модуле profiling.sampling. Он периодически снимает стек вызовов и умеет подключаться к уже запущенному приложению без изменения его кода. В примере Astral заметную долю времени занимало объединение вложенных списков перед подсчётом элементов: Counter(sum(symbols, [])) Сложение списков создаёт новые списки и повторно копирует уже накопленные элементы. По мере роста входа такая конструкция может стать дорогой. Авторы нашли её на диаграмме вызовов и заменили объединением через новый синтаксис включения списков Python 3.15. В локальном замере время снизилось примерно с 0,45 до 0,22 секунды. Это результат конкретного примера. Ценность профилировщика — в возможности сначала увидеть горячий участок своей программы, затем изменить его и повторить измерение. Доступность подключения к процессу нужно проверить для своей ОС и прав.

GitHub ускорил страницы, убрав генерацию стилей во время выполнения CSS-in-JS создавал работу и в браузере, и при серверном рендеринге. По мере роста числа компонентов дороже становились подготовка стилей и их обновление. Команда Primer перевела компоненты на CSS Modules: стили лежат рядом с кодом, имена классов локальны, а результат сборки отправляется обычными CSS-файлами. Выполнять JavaScript ради генерации этих стилей больше не нужно. Главной сложностью оказался переход. Старые и новые компоненты должны были работать одновременно. Пришлось разбирать динамические свойства, заменять стилизационные обёртки и отдельно переносить поддержку тем. Изменения выкатывали постепенно, под флагами. Миграция завершилась в июне 2026 года; сентябрьская статья описывает накопленный опыт. Полезный ориентир для профилирования интерфейса: учитывать не только объём загруженного кода, но и работу, которую он выполняет при каждом рендере.

Инвертированный индекс ищет документы по словам, а не просматривает каждую строку Запрос с несколькими LIKE '%слово%' может заставить базу проверять длинные тексты строка за строкой. Для поиска по словам используется другая структура. Инвертированный индекс хранит словарь терминов и списки документов, в которых они встречаются. Для условия AND списки пересекаются, для OR — объединяются. Позиции слов позволяют искать фразы, частоты помогают оценивать релевантность. В разборе устройства поискового движка есть интерактивные примеры этих операций, а также объяснение BM25 и выбора лучших результатов. При этом найти совпадения и вернуть наиболее подходящие документы — разные этапы. Быстрый отбор кандидатов ещё не решает задачу ранжирования. И заменять LIKE на полнотекстовый поиск механически нельзя: поиск произвольной подстроки и поиск нормализованных слов имеют разную семантику.

Uber сократил память кеша переводов с 800 до 80–120 МБ Большинство переводов в сервисе редко запрашивали, но все они постоянно занимали память. При обновлении рядом со старым кешем появлялась новая копия — в приведённом примере ещё 800 МБ. В разборе Uber описана гибридная схема: востребованные значения остаются в памяти, остальные лежат на локальном диске. В памяти хранятся компактные метаданные, позволяющие быстро найти запись. Хранилище разделили на 256 частей с отдельными блокировками. Политику вытеснения тоже пришлось адаптировать: обновлять общую структуру при каждом чтении оказалось слишком дорого. При очередной загрузке кеш заранее наполняют переводами, которые использовали за последние 15 минут. Это уменьшает волну обращений к диску после обновления. В примере расход памяти составил 80–120 МБ, а для обновления понадобилось около 40 МБ дополнительных метаданных. При оптимизации кеша стоит измерять и обычное потребление, и пик во время его замены.