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

Выбор модели отдали планировщику: HydraFusion в Copilot CLI

GitHub открыл research preview HydraFusion: вы выбираете его как обычную модель, а он собирает под задачу план выполнения из моделей разных провайдеров. Схем пока три:
• single: задачу решает одна модель;
• cascade: экономная модель пишет черновик, а гейт качества решает, принять его или передать задачу более сильной;
• critique: черновик одной модели читает критик из другого семейства, без прав на правку, и автор черновика один раз его переписывает.

Токены считаются по обычной ставке каждой модели, которую HydraFusion задействовал, так что цена запроса заранее не видна: cascade с эскалацией выйдет дороже одиночного вызова. Включается на любом плане Copilot через /update, /experimental on и /model.

Посмотрите, если собираете такую оркестрацию руками: три паттерна тут разграничены по цене и качеству.

Стоит ли расширять Go ценой его минимализма?

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

Статья на DEV Community показывает конфликт на двух уровнях. Новые конструкции решают реальные задачи, но добавляют правила, которые нужно помнить. Старые пробелы тоже усложняют код: без отдельного типа для необязательных значений разработчики используют указатели и собственные обёртки, а единообразия становится меньше.

Это концептуальная колонка, а не сравнение языков или разбор кода. Её полезно читать как повод проверить критерии развития языка: какие возможности окупают новую сложность, а какие размывают исходную модель.

Где для вас проходит эта граница в Go?

Что ломается в приёме платежей, когда сервис из одной страны выходит на весь мир

Доклад с QCon London о коммерческой платформе Netflix: как оплата подписки на DVD в США доросла до инфраструктуры, которая принимает деньги по всему миру. Рассказывает Kasia Trapszo, архитектор этой платформы с банковским опытом.

Карта доклада:
• платёжные реалии других стран и что с ними делать системе, выросшей на одном рынке;
• требования регуляторов, под которые архитектуру переделывают, а не обходят;
• разделение монолита по доменным границам;
• перестройка систем под всплеск нагрузки вокруг прямых трансляций.

Это запись выступления со слайдами, а не лонгрид с кодом: готовый приём отсюда не скопируешь, здесь видно, какие решения принимали и почему.

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

Почему нельзя пересчитывать ликвидацию всех счетов на каждом тике

На бирже с кредитным плечом задержка оставляет убыток площадке, а раннее срабатывание закрывает обеспеченную позицию. Инженерный разбор показывает, почему проверка счёта требует работы в реальном времени.

При изменении цены или позиции движок сопоставляет средства счёта и текущую прибыль или убыток с минимальным обеспечением. Полный перебор отстаёт во время волатильности. Поэтому цены ликвидации вычисляют заранее и пересчитывают только счета, которым эта цена угрожает. Проверку запускают сделка, пополнение, вывод или выплата финансирования, а не таймер.

Компромисс: медленно значит убыточно для площадки, слишком агрессивно значит потерять клиента. Материал для разработчиков торговых систем и систем обработки событий: дальше источник объясняет, почему расчётная цена становится критическим входом безопасности.

Почему Cloudflare пересжимает кэш в zstd, а не хранит байты как есть

Диски и память за год подорожали, а объём кэша упирается в закупленное железо. Cloudflare разбирает прототип Cache Transcoding: ответ на входе в кэш кодируется zstd в прокси Pingora, лежит сжатым на диске, в таком же виде едет между дата-центрами через Tiered Cache и раскодируется перед отдачей клиенту.

Что в разборе:
— почему хранение ответа в кодировке, которую прислал сервер-источник, тратит диск впустую;
— почему zstd, а не Brotli: на прошлых тестах Cloudflare он сжимал на 42% быстрее при том же размере;
— где проходит граница по CPU и почему остановились на третьем уровне zstd.

На первых замерах подходящие ответы ужимались до ⅓ размера на диске. Но это прототип со стажировки: рост нагрузки на процессор пока оценочный.

Сохраните, если считаете стоимость хранилища или выбираете, чем сжимать холодные данные.

Почему P99 вырос до 3 секунд, хотя модель была ни при чём

Разбор production-кейса на The New Stack (плюс видео): ML-приложение для биржевой торговли держало нагрузку в тестах и посыпалось под реальной конкурентной нагрузкой. Виноватой считали модель, а тормозило чтение признаков.

Около 740 000 операций в секунду — и P99 (худший ответ из сотни) подскакивает до 3 секунд, притом что средние задержки выглядят здоровыми. Каждый вызов модели делал всего несколько чтений признаков, но они вставали в очередь за записями. На высокой конкурентной записи начинается борьба за блокировки, и ретраи, раздутые кэши и тюнинг пула соединений уже не спасают.

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

Гонять нагрузочные тесты стоит по хвосту, а не по среднему: если P99 растёт вместе с конкурентной записью, смотреть надо на слой хранения признаков, а не на модель.

Перевод HSL в RGB укладывается в четыре строки без единого if

Классическая реализация hslToRgb разбирает шесть секторов цветового круга ветвлениями и отдельно обрабатывает серый. В заметке о самодельном конвертере цветов приводится компактная запись: k(n) = (n + h/30) % 12, амплитуда a = s * min(l, 1-l) и функция f, которую зовут трижды: с 0, 8 и 4. Все три канала считаются одним выражением, а серый выпадает сам: при нулевой насыщенности a = 0, и f возвращает светлоту.

Формула не авторская: то же преобразование приводит образцом спецификация CSS Color 4, так что за краевые значения можно не волноваться. Заметка короткая, остального в ней немного: почему для браузерного инструмента без сборки автор отказался от npm-пакета color и как признаёт, что писал код с плотной помощью ИИ.

Сохраните, если держите свои утилиты для цвета и не хотите тянуть зависимость ради одной математики.

ThreadSanitizer перестаёт находить гонки после 255 потоков

Фил Итон разбирает на The Consensus, что такое гонка данных, как устроен детектор гонок и какие баги есть у самого детектора. Внутри: идеализированный интерпретатор многопоточного C на Python и векторные часы в стиле FastTrack, на которых видно, как детектор сопоставляет обращения к памяти из разных потоков.

Рамка: TSan встроен почти во все тулчейны (Clang, GCC, Go, Swift, OCaml), но документации у него нет. Опубликован алгоритм второй версии (2012), а про третью (2021) автор предлагает читать исходники.

Дальше показано, как перегрузить внутренние структуры TSan, чтобы он молча пропустил очевидную гонку. Одна из границ: процесс, создавший за свою жизнь больше 255 потоков. Для Go-сервиса с горутиной на запрос это обычный день.

Сохраните, если полагаетесь на go test -race в CI: зелёный прогон не доказывает, что гонок нет.

Сколько платформы достаточно: когда внутренняя платформа становится вторым продуктом

DevOps ускорил путь изменений до продакшена, но тестирование, безопасность и поддержку каждая команда тянет сама. Внутренняя платформа забирает это на себя и легко разрастается в отдельный продукт с бэклогом. Статья на 15 минут в InfoQ разворачивает доклад с KubeCon EU 2026 и опирается на опыт Wehkamp, крупного онлайн-универмага Нидерландов.

Рамка Джона Китса:
— начинать с узких мест доставки, а не со сборки полной платформы;
— один рекомендованный маршрут выката и явный выход для тех, кому он не подходит, вместо поддержки всех случаев;
— вкладываться туда, где снимается дублирование между командами;
— вести платформу как продукт, по обратной связи пользователей.

Успех автор меряет скоростью доставки и снятой нагрузкой, а не числом возможностей.

Сохраните, если спорите, что добавить в платформу.

Что на самом деле обещает wait-free-очередь на Rust

Обстоятельный разбор на dev.to ведёт от вопроса «что вообще значит wait-free» до рабочей очереди на Rust. Атомарные операции убирают мьютекс, но не обещают, что поток закончит операцию за конечное число шагов, если соседний поток застрял у планировщика. Wait-free означает именно верхнюю границу шагов.

Что разбирают по дороге:
• чем wait-free отличается от lock-free и obstruction-free;
• почему очередь даётся сложнее, чем кажется;
• как кольцевой буфер фиксированного размера и номера последовательности решают, чья сейчас ячейка;
• где реализация остаётся тонкой даже после того, как код заработал.

Rust отсекает часть ошибок работы с памятью, но гарантию прогресса даёт алгоритм, а не компилятор.

Сохраните, если строите событийный пайплайн, где продюсеры быстрее консьюмеров: выбор между Mutex и атомиками перестаёт быть вопросом вкуса.

Дэн Лу: стоимость работы над производительностью упала на порядки, и оправданий у медленного софта не осталось

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

Дальше идут возражения практиков, и они интереснее самого тезиса. Марк Брукер соглашается и добавляет, что вероятный итог это динамический софт, подогнанный под конкретную нагрузку, а не под класс нагрузок, со своими рисками; он же вспоминает FFTW и приёмы демосцены вплоть до демки, переиспользовавшей собственный код как текстуры ради попадания в кеш.

Майкл Малис возражает мему «код никогда не был сложной частью»: для JIT-компиляторов написание кода как раз и было барьером, и их редкость это доказывает. Читать стоит целиком, вместе с ветками ответов.

Восемь дыр в семи консольных ИИ-агентах: репозиторий сам называет команду для запуска

Manifold Security раскрыла класс уязвимостей, где конфигурация Git внутри репозитория указывает команду, а агент её выполняет: от вашего пользователя, вне песочницы и без запроса подтверждения. Четыре из восьми на момент публикации не закрыты.

🔘 срабатывает, только если репозиторий приехал файлами с целой директорией .git: архив, общий диск, папка синхронизации, флешка. Обычный clone не воспроизводит;
🔘 пофикшено в goose, Claude Code и Cursor; на 1 сентября Hermes Agent, Qwen Code, Grok Build и второй путь в Claude Code всё ещё выполняли команды из репозитория;
🔘 в Claude Code и Hermes нагрузка срабатывает до подтверждения доверия к папке, в Qwen Code до аутентификации, в Grok Build на первом нажатии клавиши;
🔘 OpenAI в тот же день выпустила три своих CVE на тот же класс в Codex.

#инструменты

Многостадийная модель дала Meta* 6% конверсий в Instagram* и предсказуемые законы масштабирования

Система ранжирования обязана достать и отсортировать тысячи объявлений за миллисекунды, перебирая миллионы кандидатов в секунду. Раньше это решалось гибридной схемой, где последовательности пользовательских событий обрабатывает одна модель, а разреженные признаки другая, со всеми вытекающими компромиссами.

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

Совокупный результат: плюс 6% конверсий в Instagram*, плюс 3% конверсий в Facebook* и плюс 3,5% кликов по рекламе в Facebook*. Всё это часть Generative Ads Recommendation Model.

*Компания Meta и её продукты признаны экстремистскими, их деятельность запрещена на территории РФ.

Meta переписала транспорт RDMA с нуля под Ethernet и кластеры в миллион ускорителей

Коллективные операции вроде all-reduce синхронизируют тысячи ускорителей во время обучения, и темп всей задачи задаёт самая медленная передача. В инференсе задержка между шардами модели напрямую бьёт по времени ответа для сотен миллионов пользователей. Даже небольшое трение в сети замораживает заметные вычислительные мощности.

Проблема со стандартным RoCE в том, что он ожидает доставку каждого кадра по порядку, опирается на PFC и мешает распылению пакетов, которое как раз и даёт производительность в больших многоплоскостных сетях. MetaRoCE спроектирован с чистого листа под высокую пропускную способность, низкий хвост задержек и простоту эксплуатации по мере роста числа ускорителей и расстояний между ними.

Спецификацию, эталонную реализацию и набор тестов на соответствие выкладывают через Open Compute Project. Масштаб, на который это рассчитано: кластеры в сотни тысяч ускорителей, разнесённые по нескольким дата-центрам и регионам.

Биргитта Бёкелер разбирает, превращается ли TDD в руках агента в ритуал без содержания

Материал входит в серию Exploring Gen AI, где технологи Thoughtworks публикуют результаты собственных экспериментов, а не обзоры чужих мнений. Автор — Distinguished Engineer с двадцатью с лишним годами в разработке и архитектуре.

Вопрос поставлен честно прямо в заголовке: театр или реальная польза. Разбирается в том числе вариант, что цикл красный-зелёный-рефакторинг в руках агента становится обрядом, который ничего не проверяет.

Стоит времени, если вы сейчас решаете, встраивать ли тесты в промпт или писать их после, и не хотите принимать это решение по ощущению.

Вторая глава Logic for Programmers выложена целиком: предикаты, импликация и кванторы

Хиллель Уэйн писал книгу, потому что хороших материалов по логике именно для программистов не было. Книга вышла, и появилась обратная проблема: нет хороших бесплатных. Автор выложил вторую главу целиком в виде поста.

Глава называется ускоренным курсом и вводит понятия с нуля: предикаты, оператор импликации, множества и кванторы над ними. Автор подчёркивает, что многое читателю знакомо по опыту программирования, просто называется иначе.

Все сноски в посте это редакторские комментарии, которых в книге нет. Удобный способ понять, нужна ли вам книга, потратив вечер вместо покупки.

Горутины против потоков и событийных циклов: восьмая часть разбора конкурентных серверов

Эли Бендерски много лет ведёт серию, где один и тот же сетевой сервер переписывается разными средствами: последовательно, на потоках, через событийный цикл, на обратных вызовах, на корутинах. Каждая часть решает уже описанные задачи новым способом и меряет результат.

Восьмая часть переключается на Go. Ценность именно в позиции внутри серии: горутины разбираются не как отдельная фича языка, а как очередной ответ на проблемы, которые в предыдущих семи частях уже разложены и измерены.

Читать можно подряд с первой части или точечно, если предмет знаком и нужно сравнение подходов. Ссылки на все части стоят в начале текста.

Асинхронный Rust в одном ряду с потоками и событийными циклами, а не сам по себе

Та же серия Эли Бендерски, часть седьмая: тот же набор задач конкурентного сетевого сервера решается средствами Rust.

Отдельная ценность в том, что асинхронный Rust обычно объясняют изнутри, через футуры и исполнители, и он выглядит вещью в себе. Здесь он попадает в общий ряд с потоками, событийными циклами и корутинами из предыдущих частей, и становится видно, чем именно он платит за свои гарантии.

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

Агентам дали писать стратегии, но не дали решать, что считать удачным результатом

Агент для торговых исследований умеет написать код стратегии, прогнать бэктест, посмотреть результат и переписать стратегию заново. Сложность не в этом цикле, а в том, чтобы он не превратился в неуправляемый поиск красивого бэктеста.

В справочнике систему строят так: исторические данные даёт EODHD, а детерминированный слой на Python держит в своих руках разбиение выборок, логику бэктеста, бенчмарки, историю экспериментов и правила отбора. Внутри этих границ работают три агента: координатор, инженер стратегий и критик исследования, которые проходят три версии стратегии.

Цель проговорена прямо: доказывать, что агенты надёжно находят прибыльные стратегии, автор не собирается. Он строит процесс, где агенты генерируют и оспаривают идеи, но не контролируют доказательства. Приём переносится на любую агентную задачу с измеримым результатом.

Четыре джойна в SQL против одного запроса в графе: справочник по Neo4j и Python

Рамка задана вопросом, который легко произнести и тяжело написать: у каких инженеров есть свежий контекст по сервисам, задетым ночным инцидентом. В SQL это четыре или пять джойнов, каждый строит промежуточный результат шире нужного ответа и тут же выбрасывает большую часть. Запрос замедляется по мере роста таблиц и хуже читается с каждым возвращением к нему.

Справочник ведёт от пустой базы до работающего графа знаний: загрузка настоящих данных из Python и запросы, на которых идея становится понятной.

Разобраны части, которые туториалы пропускают: как решить, что становится узлом, почему первая модель данных почти наверняка неверна, как ускорить загрузку и как читать план запроса, когда что-то тормозит.