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

Redis — хранилище структур данных в памяти: кеш, счётчики, очереди, потоки событий. Версия 8.10 вышла 29 июля.

Что внутри:
🔘 компактные хеши: новое кодирование, при котором имена полей хранятся один раз для ключей с общей схемой, и расход памяти на однотипных объектах падает;
🔘 команда HIMPORT для быстрой массовой загрузки таких хешей;
🔘 команда BACKUP делает резервную копию и восстановление на стороне узла, поверх многочастного AOF, без внешних скриптов;
🔘 LMOVEM и BLMOVEM переносят между списками сразу несколько элементов, а не по одному за вызов;
🔘 SUNIONCARD и SDIFFCARD возвращают размер объединения и разности множеств, не собирая сами множества в ответ;
🔘 у XREAD и XREADGROUP появились MAXCOUNT и MAXSIZE, которые ограничивают суммарное число записей и размер ответа: полезно, когда читатель отстал и рискует получить всё разом;
🔘 аутентификация между серверами по клиентскому сертификату TLS.

Из исправлений после кандидата в релиз стоит знать про клиентов, которые могли остаться заблокированными на BLPOP и BLMOVE, если SORT с STORE подменил целевой ключ списком, и про деление на ноль при равных или перевёрнутых порогах активной дефрагментации.

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

Язык: C. Лицензия: на выбор RSALv2, SSPLv1 или AGPLv3.

@prog_tools

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

Argo CD — инструмент доставки в Kubernetes по модели GitOps: состояние кластера описано в репозитории, а контроллер приводит кластер к описанию и показывает расхождения. Версия 3.5.0 вышла 4 августа.

Что внутри:
🔘 у обновлений, вызванных вебхуком, появился настраиваемый разброс по времени, так что одновременный наплыв размазывается;
🔘 контроллер наборов приложений научился обрабатывать приложения параллельно, а сами наборы теперь показываются в дереве ресурсов;
🔘 в интерфейсе появилась вкладка предпросмотра приложений для набора: видно, что именно сгенерирует шаблон, до применения;
🔘 в путях к файлам значений Helm заработали шаблоны со звёздочкой, вместо перечисления файлов вручную;
🔘 в альфа-режиме появилась проверка целостности источника для сухих ревизий, то есть подтверждение, что развёрнутое пришло из ожидаемого места;
🔘 у команд argocd app добавлен флаг --app-namespace, а у команд наборов приложений — соответствующий флаг пространства имён;
🔘 внутри выполнен переход с Helm 3 на Helm 4 и обновление интерфейса на React 19.

Переход на Helm 4 и React 19 делают релиз ломающим для тех, кто держит собственные расширения интерфейса: для них выпущено отдельное руководство по обновлению. Перед прыжком через минорную версию авторы просят читать документацию по обновлению, там же лежат заметки о переходе с 3.4.

Пригодится тем, кто держит GitOps на десятки приложений и ловит всплески нагрузки после каждого пуша в общий репозиторий манифестов.

23,9 тысячи звёзд на GitHub против примерно 8 тысяч у ближайшего конкурента Flux.

Язык: Go. Лицензия: Apache 2.0.

@prog_tools

Helm — способ ставить приложения в Kubernetes не вручную. Вместо десятка YAML-файлов, которые надо править под каждое окружение, берётся чарт: шаблоны плюс файл значений. Стандарт де-факто, ближайший сосед Kustomize решает более узкую задачу и шаблонов не даёт.

13 августа вышла версия 4.2.4, патч. Изменения касаются отладки:

🔘 helm template --debug --show-only внятнее объясняет, какой шаблон сломался;
🔘 тестовые поды отдают логи всех контейнеров, а не только первого — раньше логи вспомогательных контейнеров просто терялись;
🔘 вернулся повтор при конфликте применения на стороне сервера;
🔘 helm push с аутентификацией по токену перестал падать на правах доступа к реестру;
🔘 в пакетах перестали исчезать пустые строки.

Отдельная причина обновиться: подтянуты зависимости с уязвимостями, gRPC и OpenTelemetry.

@prog_tools

Podman запускает контейнеры без демона: команды вроде podman run делают то же, что Docker, но нет фонового процесса с правами root, и контейнеры можно гонять от обычного пользователя. Docker остаётся популярнее, но там, где демон мешает — на сборочных машинах, в systemd, в закрытых окружениях, — Podman прижился именно поэтому.

12 августа вышла версия 6.1.0. Что стоит знать:

🔘 у podman manifest push появились --retry и --retry-delay: публикация образа больше не валит сборку из-за секундной сетевой ошибки;
🔘 починено зависание удалённого клиента при работе через SSH;
🔘 добавлены podman volume rename и podman machine restart;
🔘 у podman network rm появился --ignore — удобно в скриптах очистки;
🔘 podman generate kube переносит проверки состояния контейнера в livenessProbe;
🔘 для проброса портов из Windows через WSL теперь нужен параметр force_port_listen в containers.conf.

@prog_tools

Старый Kindle можно повесить на стену как дашборд домашнего сервера. Считает сервер: dashink рисует картинку 600x800 в оттенках серого и отдаёт по /dash.png, а читалка раз в 5 минут скачивает её и выводит на экран. На панели — сервисы из Uptime Kuma, заполненность пула, аптайм Proxmox и погода, а с 22:00 до 07:00 — фото из Immich.

Как повторить, автор расписал:
🔘 сервер — docker compose up -d, в .env для полезного экрана хватает широты и долготы;
🔘 Kindle — джейлбрейк (метод сверяют по серийнику и прошивке, у автора подошёл WinterBreak), Hotfix, чтобы .sh из /mnt/us/documents/ открывался из библиотеки как книга, блокировка OTA и SSH через USBNetwork;
🔘 на устройстве — 77 строк на busybox sh: скачать PNG, вывести через eips -g, каждый 12-й цикл — полная перерисовка от следов e-ink.

Код на MIT. Ближайшая альтернатива, kindle-dash, между обновлениями усыпляет устройство в память, поэтому экономнее по батарее, но проверена только на Kindle 4 NT, а код не обновлялся с 2022 года.

@prog_tools

Prometheus — база временных рядов, которая сама ходит по сервисам и собирает метрики, а потом отвечает на запросы вроде «сколько ошибок в секунду было вчера в 15:00». На нём же держатся алерты. Альтернативы есть, но они либо совместимы с ним по протоколу, либо решают другую задачу, так что для метрик это опорная точка индустрии.

11 августа опубликован кандидат в релиз 3.14.0. Самое важное — три починенные тихие поломки:

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

Из нового: выражения длительности в PromQL включены по умолчанию, появилась функция start_timestamp(), добавлено обнаружение целей в облаке OCI.

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

@prog_tools

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

В Node.js 26.7.0 от 5 августа у встроенного запускальщика тестов появился флаг --test-coverage-include-all, который считает все файлы проекта. Отдельный инструмент вроде nyc для этого больше не нужен: свой раннер и покрытие в Node есть с 18-й версии.

Остальное в релизе:

🔘 в sqlite закрыты обращения к освобождённой памяти в Exec() и ApplyChangeset(), добавлен сброс сессий при закрытии базы;
🔘 в crypto появилась загрузка приватных ключей через загрузчики STORE — ключ можно брать из внешнего хранилища, а не только из файла;
🔘 в хуки модулей добавлена поддержка Symbol.dispose;
🔘 обновлены корневые сертификаты и npm до 11.19.0.

Если собираете Node из исходников: теперь нужен компилятор Rust не ниже 1.86.

@prog_tools

yazi — файловый менеджер для терминала: ходишь по каталогам с клавиатуры, видишь превью картинок, PDF, кода и архивов прямо в панели, а действия и подсветку дописываешь на Lua. 15 августа вышла версия 26.8.15, у проекта 41,4 тыс. звёзд на GitHub на 17 августа.

🔘 drag-and-drop файлов из терминала в GUI-приложения и обратно;
🔘 корзина вместо безвозвратного удаления и массовое создание файлов;
🔘 меню помощи стало палитрой команд, у строки ввода появилась история;
🔘 автоматическое переключение светлой и тёмной темы вслед за терминалом;
🔘 собственный VFS-провайдер: плагин может подключить удалённое хранилище как каталог;
🔘 официальный APT-репозиторий для Debian и Ubuntu, превью через kitty-протокол внутри Zellij.

Очевидная альтернатива — mc: две панели, есть на любом сервере, работает без Rust-бинарника и плагинов, и для копирования файлов между двумя каталогами он удобнее. yazi берёт асинхронными превью, скоростью на больших каталогах и расширяемостью; из той же ниши ranger на Python и lf на Go, но у обоих превью и плагины скромнее.

@prog_tools

openleetcode запускает задачи LeetCode локально. Решение выполняется у вас на машине, а тесты лежат в открытом репозитории, а не на сервере сервиса: команда openleetcode submit ./solution.py --id 1 сама находит задачу, собирает обвязку под язык и прогоняет решение через Piston, который поднимается рядом в Docker.

🔘 около 1400 задач;
🔘 Python, C++, Rust, Go, Java, Kotlin, TypeScript и ещё несколько языков;
🔘 в версии 1.0.4 от 17 августа обновили зависимости и починили раннер, в том числе конфликт имён переменных и обработку однобайтных символов.

Сам LeetCode по многим пунктам лучше: каталог больше, тесты скрытые, есть редактор и обсуждения, а отправка решения на сервер всё равно остаётся отдельным шагом. Авторы прямо предупреждают, что локальные наборы тестов поддерживаются вручную и могут пропустить крайние случаи, а system design, SQL и задачи на многопоточность не поддерживаются вовсе.

Смысл в другом: решения и тесты живут в вашем git, работают офлайн, запускаются из вашего редактора и прогоняются в CI перед коммитом. На Linux и macOS установщик сам поднимает Piston через Docker Compose, на Windows ставится только CLI, бэкенд запускается руками.

curl -fsSL https://raw.githubusercontent.com/therepanic/openleetcode/main/install.sh | sh

@prog_tools

OpenTelemetry Collector — прослойка между вашими сервисами и системами наблюдаемости. Сервисы шлют логи, метрики и трейсы в него, а он фильтрует, дописывает атрибуты и раскладывает по адресатам. Смысл в развязке: сменить систему хранения можно правкой конфига, не трогая код приложений. Fluent Bit и Vector делают похожее, но collector — эталонная реализация стандарта, и агенты под него пишут все.

4 августа вышла версия 0.158.0. Главное — новый компонент queuebatch вместо старого batchprocessor: он построен поверх общей обвязки экспортёров и настраивается теми же параметрами, что и очередь отправки, так что двух разных наборов настроек для соседних вещей больше нет.

Остальное:

🔘 в описаниях компонентов появились готовые типы duration, opaque_string, opaque_map и другие;
🔘 расширение memory_limiter доросло до беты;
🔘 исправлено ложное предупреждение, из-за которого молча отключалась старая метрика;
🔘 отладочный экспортёр перестал печатать числовые атрибуты в сыром виде.

Ломающее: убраны проверяющие функции из пакета xconfmap, брать теперь из confmap.

@prog_tools

Jujutsu, или jj, — система контроля версий, которая работает поверх обычного Git-репозитория: коллеги видят привычные ветки и коммиты, а у вас другая модель. Рабочая копия сама по себе коммит, staging area нет, любая операция отменяется через jj undo, конфликты хранятся в истории и не блокируют работу. 6 августа вышла версия 0.44.0, у проекта 31 тыс. звёзд на 17 августа.

🔘 стабилизирована работа с тегами: jj git fetch забирает их как <имя>@<remote>, теги можно отслеживать и не отслеживать как bookmarks, jj git push --all теперь пушит и теги;
🔘 новый revset merge_point() находит точку слияния веток, по аналогии с fork_point;
🔘 jj file search печатает совпавшие строки с именем файла, номер строки добавляет -n, старое поведение — через --name-only;
🔘 jj run идёт по ревизиям от старых к новым, получил --passthrough, --ignore-changes и --ignore-errors;
🔘 повторно переданный аргумент больше не ошибка, побеждает последний.

Альтернатива очевидна: сам Git. У него любой хостинг, submodules, IDE и десять лет чужих скриптов; у jj Git-совместимость объявлена стабильной, а команды и рабочий процесс до 1.0 могут меняться, о чём проект пишет в каждом релизе. Зато переписывание истории и работа с несколькими правками одновременно здесь заметно проще.

@prog_tools

blitcp копирует файлы по карте диска: сначала строит карту, потом читает данные в том порядке, в каком они физически лежат. Задача та же, что у cp и rsync, разница проявляется на множестве мелких файлов и на медленных носителях, то есть на HDD, флешках и NAS.

🔘 склеивает мелкие файлы в один поток чтения;
🔘 пропускает дубликаты по хешу xxHash-128;
🔘 умеет reflink и жёсткие ссылки, понимает разрежённые файлы;
🔘 после копирования сверяет результат с исходником.

Цифры авторы приводят в заметках к версии 4.0.2: 85 ГБ с NVMe на USB скопировались за 44 минуты 47 секунд вместо часа и четырёх минут, а построение карты диска в Windows для 6600 файлов ускорилось с 12 минут 48 секунд до 0,7 секунды, потому что теперь файл открывается только на чтение атрибутов и Windows Defender не сканирует его содержимое. На тесте в Linux с 12 347 мелкими файлами вышло 5,93 секунды против 14,14 у rsync и 14,99 у cp -ar.

Автор сам говорит, где его инструмент не нужен: на быстром SSD без дубликатов обычный cp лучше, потому что хеширование и анализ диска добавляют накладные расходы. Для инкрементальной синхронизации с удалённым сервером rsync тоже остаётся более подходящим, и автор это признаёт.

mkdir -p ~/.local/bin && curl -fsSL https://raw.githubusercontent.com/gekap/blitcp/v4.0.2/blitcp.py -o ~/.local/bin/blitcp && chmod +x ~/.local/bin/blitcp

Для работы по SSH дополнительно нужен paramiko.

@prog_tools

just — запускальщик команд проекта. Ту же роль обычно играет Makefile, но make всё-таки система сборки: он думает про файлы и зависимости, ругается на пробелы вместо табов и норовит не выполнить цель, если рядом лежит одноимённый файл. В justfile пишутся просто именованные команды с аргументами, и это всё, что нужно, когда цель — собрать в одном месте «прогнать тесты», «поднять окружение», «выложить».

3 августа вышла версия 1.58.0, небольшая:

🔘 у рецепта появился атрибут [timestamp], печатающий время выполнения, — удобно для долгих сборок, где раньше приходилось обкладывать команду вызовами date;
🔘 у него же есть аргумент формата;
🔘 --justfile-name теперь принимает несколько имён через запятую;
🔘 при форматировании вокруг выражений подстановки добавляются пробелы.

Ломающих изменений нет.

@prog_tools