Void объединяет Vite-приложение и его инфраструктуру

Уже есть фронтенд. Теперь нужны серверные маршруты, база, авторизация и место, куда всё это выложить. Void от Cloudflare собирает эти части в общий рабочий процесс.

В проект входят SDK, CLI и открытая платформа развёртывания. SDK работает как плагин Vite, CLI выделяет необходимые ресурсы, а платформу можно развернуть в аккаунте компании.

Администратор задаёт доступ и ограничения ресурсов; разработчики выкладывают приложения через общий сервис. В SDK есть маршруты API и передача типов от запроса к базе до интерфейса, а также интеграции с существующими фреймворками.

Для собственной платформы нужны Workers for Platforms, R2, PostgreSQL, провайдер входа и домен. Открытый код позволяет адаптировать её, но готовый сценарий развёртывания построен вокруг Cloudflare.

Конкурентные записи разрешили. Все всё равно стояли в очереди на диск

В Turso 0.7 несколько транзакций уже могли работать параллельно. Но при фиксации каждая отдельно ждала fsync: подтверждения, что изменения записаны на диск.

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

Group commit позволяет нескольким транзакциям разделить одну синхронизацию. Подтверждение приходит после сохранения нужной части журнала; требование надёжности записи остаётся.

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

Байесовский A/B-тест тоже можно остановить неправильно

Проверять эксперимент каждый час и выключать, как только новая кнопка «побеждает», заманчиво. Но переключатель Bayesian в интерфейсе сам по себе не гарантирует контроль ложных находок.

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

Есть байесовские методы, которые контролируют ошибки при такой проверке, например остановка по Bayes factor. А информативный prior может улучшить оценку эффекта — если он действительно подходит новым экспериментам.

Spotify пока не видит необходимости добавлять Bayesian-режим к своим инструментам. Выбор метода здесь начинается с требуемых гарантий и цены ошибок.

SIMD в Go: сложные инструкции спрятали за обычными методами

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

В экспериментальном `simd/archsimd` Go 1.27 к amd64 добавились arm64 и wasm. API включается через GOEXPERIMENT=simd и позволяет обращаться к возможностям конкретной архитектуры из Go.

Названия не копируют длинные имена инструкций. Сложение выглядит как x.Add(y), а операция с маской — как x.Add(y).Masked(m). Компилятор может свести такое выражение к подходящей машинной инструкции.

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

Секрет не попал в лог. Зато сохранился в кеше CI

Miri, инструмент проверки Rust-кода, сохранял переменные окружения в target/. Если запуск имел доступ к токенам, они тоже могли оказаться на диске.

Дальше срабатывала обычная оптимизация GitHub Actions: каталог кешировали, чтобы ускорить следующий запуск. Pull request мог прочитать этот кеш и извлечь секреты, хотя напрямую переменные ему не передавали.

В сообщении команды Rust перечислены условия: запуск Miri с секретами, кеширование target и доступ PR к кешу. Исправление ограничивает сохраняемые переменные; выпуск с ним указан как nightly от 22 сентября.

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

Миллионы баз данных не должны ходить в один центр за каждым запросом

В Cloudflare D1 каждая база опирается на отдельный SQLite Durable Object. Баз можно создать миллионы — но центральный каталог их расположения легко превратить в узкое место.

В разборе архитектуры D1 показано разделение работы. Создание, удаление и другие управляющие операции используют центральный PostgreSQL. Для выполнения SQL маршрутизационные метаданные читаются через распределённый Workers KV и кеши.

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

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

Два ядра CPU на одном сервере могут стоить трёх на другом

В платформе Odin у Uber есть разные поколения x86 и ARM. Производительность одного ядра между крайними вариантами отличается почти вдвое. Одинаковый лимит CPU даёт разный запас мощности.

Для сервисов с данными это особенно неприятно: при смене лидера нагрузка может переехать на более медленный сервер.

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

Одних синтетических тестов не хватило. Коэффициенты уточняют по продакшену отдельно для разных технологий: Cassandra и Kafka по-разному используют одно железо. Универсальная оценка «этот сервер быстрее на 30%» здесь теряет точность.

Старый токен Docker Hub получал права нового владельца

При превращении личного аккаунта в организацию Docker Hub переносил его PAT-токены указанному владельцу. Сам секрет токена оставался прежним, а согласия нового владельца не требовалось.

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

Docker опубликовал разбор CVE-2026-105445. Ошибку исправили 30 сентября: перенос PAT убрали. Проверка примерно 304 тысяч публикаций образов с перенесёнными токенами не выявила признаков эксплуатации.

Доступ к веб-интерфейсу и смене пароля ошибка не давала. Урок для проектирования доступа: смена владельца объекта требует отдельной проверки того, что происходит с уже выданными учётными данными.

Больше реплик Git — медленнее push. GitHub меняет эту связку

В нынешней архитектуре GitHub репозиторий обычно хранится на пяти файловых серверах. Дополнительные копии помогают обслуживать чтение, но каждая участвует и в записи.

Поэтому масштабирование чтения увеличивает работу при push. Когда тысячи агентов и CI-задач обращаются к одному репозиторию, эта связь становится ограничением.

В плане новой Git-инфраструктуры GitHub разделяет надёжное хранение и масштабирование обслуживания. Согласование хотят сосредоточить на обновлении ссылки на коммит; работу с объектами, проверки и обслуживание распараллеливать там, где это допускает корректность.

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

Изменений стало вдвое больше. Проверки не успели за разработкой

В августе Spotify влил около 17 тысяч изменений против 8100 годом ранее. Компания рассказала, что меняет в контроле качества на фоне роста автоматизации и работы с ИИ.

Один автоматический апдейт зависимости прошёл проверки, но сломался в продакшене. Теперь компания усиливает защитные проверки и откат, а такие обновления планирует на рабочие часы команд-владельцев.

В обработке контента были другие пробелы: ошибки могли долго оставаться незамеченными, а пакетные задания конкурировали с новыми загрузками. Добавили сквозной мониторинг, изменили приоритеты и расширили мощности.

В рассмотренных инцидентах Spotify не нашла существенного прямого вклада кода, написанного ИИ. Зато увидела, что объём изменений рос быстрее возможностей их проверки. Вывод относится к данным и разбору самой компании.

Всем привет, админ на связи!

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

То же самое с digital направлением, где агенты позволяют как нарастить темпы работы, так и предлагают новые форматы.

Я 22 октября иду на конференцию AI BOOST’26. Хочу там познакомиться с владельцами таких агентств и бизнеса, а ещё узнать что вообще в индустрии происходит.

Программа рассчитана на 2 дня. Приглашаю вас с собой! Можем даже там пересечься между докладами или на афтепати.

Кеш занимал 800 МБ. Большая часть переводов просто лежала без дела

Uber обслуживает миллионы переводов в секунду. Держать всё в памяти удобно, пока очередное обновление не создаёт рядом вторую копию кеша и не заканчивается память.

Команда перенесла редко используемые переводы на диск. В RAM оставили индекс ключей и кеш востребованных значений. Хранилище разделили на 256 частей, чтобы запросы меньше мешали друг другу при блокировках.

В приведённом примере расход памяти снизился с 800 до 80–120 МБ. При обновлении нужны ещё около 40 МБ метаданных вместо второй копии на 800 МБ.

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

Больше CSS — меньше работы при открытии страницы

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

GitHub описал переход от CSS-in-JS к CSS Modules. Стили готовят заранее, а компоненты получают имена классов. В браузер отправляется больше обычного CSS, зато исчезает часть работы JavaScript.

После миграции компонентов Primer время серверного рендеринга страницы сократилось на 55%, инициализации компонентов — на 25%. Это результат конкретного этапа, а не обещание такого ускорения любому проекту.

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

Почему remove не удаляет число из Set<Short>

В цикле добавляем short в Set<Short>, затем вызываем remove(i - 1). Кажется, предыдущий элемент должен исчезнуть.

Но результат i - 1 имеет тип int и упаковывается в Integer. В коллекции лежат Short, поэтому ничего не удаляется. Компилятор доволен: метод remove(Object) принимает такой аргумент.

В разборе Error Prone показано, как поймать эту ошибку ещё при сборке. Инструмент встраивается в javac и проверяет подозрительные конструкции с учётом типов.

Другой пример — YYYY в формате даты. Это год по нумерации недель, поэтому на границе декабря и января имя отчёта может получить неожиданный год.

К встроенным проверкам можно добавить свои правила через BugChecker. Например, запрещать характерные для проекта ошибки, пока они ещё не попали на ревью.

С LZ4 PostgreSQL прочитал весь текст ради первых 200 символов

Нужны первые 200 символов большого текста. Кажется, для этого достаточно прочитать небольшой кусок. Но способ сжатия меняет объём работы.

В эксперименте PlanetScale сравнили pglz и LZ4 на PostgreSQL 18. Для pglz база умеет оценить, сколько сжатых данных нужно для начала строки. Для LZ4 такой оценки нет: сначала приходится забирать значение целиком.

На ста значениях примерно по 1 МБ получение начала текста заняло около 1 мс с pglz и 16 мс с LZ4. Обращений к страницам получилось 301 против 6234. Данные уже находились в памяти.

LZ4 при этом быстрее загружал другой набор данных — JSON-документы. Выбирать сжатие только по скорости записи рискованно: для списка превью, полного документа и чтения диапазона байтов база выполняет разную работу.

GitHub автоматизировал проверку доступов и репозиториев

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

GitHub собрал для этого приложение Evergreen. Раз в квартал оно просит подтвердить доступ внешних участников. Неактивные репозитории проходят отдельную проверку перед архивированием.

Обсуждение идёт в issues, задачи запускаются через GitHub Actions, состояние хранится в JSON в Git. У решения остаётся история: кто получил предупреждение, что подтвердили и почему доступ отозвали.

Молчание тоже имеет последствия, но после срока на ответ. Неподтверждённый доступ снимают, заброшенный репозиторий архивируют. Архивирование сохраняет код и историю — это не удаление проекта.

Профилировщик Python 3.15 подключается к живому процессу

В Python 3.15 появился Tachyon — статистический профилировщик из profiling.sampling. Он снимает образцы стеков и помогает увидеть, где программа проводит время. Подключиться можно без изменения её кода.

В разборе Astral профилируют обработку молекул через RDKit. Заметная доля образцов стека приходится на функцию, которая объединяет вложенные списки через sum(symbols, []).

Такая запись многократно создаёт и копирует промежуточные списки. По мере роста входа работа становится квадратичной. В статье её заменяют разворачиванием списков с новым синтаксисом Python 3.15.

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

Маршрутизатору базы не обязательно понимать каждую колонку

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

В маршрутизаторе Neki PlanetScale сохраняет ответы PostgreSQL в исходном формате протокола. Если результат можно передать дальше, значения колонок остаются байтами.

Появился LIMIT — нужно найти границы строк и выбрать нужные. Появилась общая сортировка результатов с нескольких шардов — понадобится разобрать ключ сортировки. Остальные колонки можно по-прежнему не преобразовывать в типизированные значения.

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

Проверенный бот тоже может перегрузить сайт

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

Cloudflare описала подход к постоянной оценке проверенных ботов. Среди сигналов — соблюдение robots.txt и реакция на HTTP 429: снижает ли робот частоту запросов, учитывает ли указание подождать.

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

Публичные оценки в Cloudflare Radar пока заявлены как следующий шаг. Уже сейчас при разборе нагрузки полезно смотреть, что происходит после ответа «слишком много запросов»: клиент действительно отступает или немедленно приходит снова.

Сколько ключей придётся помнить ради дедупликации потока?

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

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

Важен и результат запроса. Один вариант сразу выдаёт строку, а позже присылает её обновление. Другой ждёт, чтобы учесть запоздавшие события. Получатель должен уметь работать с выбранным режимом.

Даже настройка TTL требует проверки: в рассмотренной версии подсказка STATE_TTL не применяется к оператору дедупликации. До запуска стоит прогнать поздний дубль, истечение срока хранения и обновление результата — именно на них короткий SQL начинает вести себя неожиданно.