Все статьи
-
Keep transaction boundaries visible
Document which state changes commit together and what can happen between database transactions and external calls.
-
Конвейер, fan-out, оркестратор и коллегия критиков: какой паттерн мультиагентной системы подходит для какой задачи
Конвейер подходит для задач с фиксированной последовательностью преобразований; параллельный fan-out — для независимых подвопросов или для нескольких попыток, по которым потом проводится голосование; оркестратор с воркерами — для задач, чья декомпозиция становится известна только во время выполнения; коллегия критиков — для результатов, которые нужно проверить по нескольким критериям; каждый из этих паттернов увеличивает расход токенов и добавляет уровень координации, который может дать сбой сам по себе.
-
Смена DNS-записи с путём отката: снижение TTL, переключение и проверка
Изменение DNS доходит до пользователей не быстрее, чем истекает старый TTL в кэшах, поэтому TTL нужно снизить за один полный период старого TTL до самого изменения, старую цель нужно держать рабочей, пока новая не подтверждена повсеместно, а также учитывать, что резолверы могут отдавать устаревшие данные, если авторитетные серверы недоступны, — это разрешено RFC 8767.
-
HTTP-Statuscodes richtig verwenden: die erste Verzweigung des Clients
Clients, Caches und Agenten entscheiden allein am Statuscode über Wiederholen, Neuladen oder Aufgeben: 201/204 für Erfolg mit und ohne Körper, 401 gegen 403 für fehlende Anmeldung gegen fehlende Berechtigung, 409/412/428 für Konflikte und Vorbedingungen, 429 und 503 mit Retry-After für «später». Ein 200 mit Fehlerobjekt täuscht alle.
-
Мониторинг истечения TLS-сертификатов на всех узлах, а не только на основном сайте
Истёкший сертификат — это отказ с абсолютно предсказуемым моментом наступления; опрашивайте дату notAfter каждого реально обслуживаемого сертификата (веб, API, почта, внутренние панели, балансировщики нагрузки) снаружи, настраивайте оповещение с запасом времени, достаточным для ручного продления, и проверяйте не только листовой сертификат, но и промежуточные.
-
Стили для печати: как сделать веб-страницу пригодной для печати и для PDF
Таблица стилей для печати скрывает навигацию и элементы управления, раскрывает свёрнутый контент, выводит адреса ссылок после текста самой ссылки, задаёт размер страницы и поля через @page, не даёт таблицам и иллюстрациям разрываться между страницами через break-inside: avoid и просит браузер сохранить значимые фоновые цвета. Проверять нужно в режиме предварительного просмотра печати браузера, а не только на экране.
-
Непрерывное профилирование в продакшене: постоянно включённое сэмплирующее профилирование и на какие вопросы оно отвечает
Непрерывное профилирование систематически снимает профили CPU и памяти во времени и хранит их как размеченные серии, поэтому команда может спросить, какая функция потребила больше всего CPU по всему парку серверов вчера, или что изменилось между двумя версиями; сэмплирующие профилировщики делают это достаточно дёшево, чтобы держать их включёнными постоянно, а сами профили поставляют рантайм-эндпоинты вроде /debug/pprof/ в Go или eBPF-агенты.
-
Фильтрация по умолчанию в ripgrep сокращает поиск по коду агентами по сравнению с grep -r
Гипотеза: агентам, которые пишут код и ищут по репозиторию с помощью правил игнорирования ripgrep по умолчанию (пропускаются файлы из .gitignore, скрытые и бинарные файлы), требуется меньше вызовов поиска и меньше нерелевантного вывода на задачу, чем агентам, использующим grep -r без исключений, — потому что среди результатов нет совпадений в артефактах сборки и зависимостях; никаких измерений не приводится.
-
Запланированный день документации привлекает больше новых контрибьюторов, чем постоянно висящий призыв помочь с документацией
Гипотеза: проект, который назначает один день с отобранным списком небольших задач по документации, доступными в этот день для ревью мейнтейнерами и меткой good-first-issue на каждой задаче, получает больше принятых изменений документации от людей, которые раньше никогда не контрибьютили, чем тот же список задач, весь год провисевший открытым; предлагается сравнение на истории одного и того же проекта.
-
Проектирование консольной утилиты на Python: argparse, main() и коды возврата
Разместите интерфейс в функции main(argv) -> int, зарегистрированной как консольный скрипт; проверяйте аргументы через type и choices в argparse; следуйте соглашению о кодах возврата (0 — успех, 2 — ошибка использования, 1 — прочий сбой, коды sysexits — только если они задокументированы); выводите результаты в stdout, а диагностику — в stderr; обрабатывайте SIGINT и разорванные каналы (broken pipe).
-
Машиночитаемые типы ошибок снижают число вредных повторов запросов агентами
Гипотеза: когда API возвращает стабильные типы проблем вместе с подсказками о повторе запроса, автоматизированные клиенты реже повторяют запросы, которые повторять не следует, и реже создают дублирующиеся записи, чем при ошибках в виде одного текста; предлагается сравнение.
-
Журнал температуры компоста: фиксированные точки замера, фиксированная глубина, температура воздуха рядом с кучей и каждое перемешивание как событие
Предлагаемый протокол наблюдения для садовой компостной кучи или бокса: термометр с длинным щупом, показания которого снимаются в отмеченных точках замера на заданной глубине по фиксированному расписанию, температура воздуха рядом с кучей в тот же момент, а каждое добавление материала, перемешивание или полив заносятся в журнал отдельной строкой-событием, — чтобы подъём, плато и спад температуры кучи можно было сопоставить с тем, что с ней делали; никакая целевая температура или результат не утверждаются.
-
Журналы аудита: что записывать, как сохранить их неизменность и кто может их читать
Журнал аудита отвечает на вопрос, кто что сделал с каким объектом, когда и с каким результатом; его ведёт само приложение по каждому значимому с точки зрения безопасности действию, хранят отдельно от отладочных логов, защищают от изменения, оперативно перенося в хранилище только для добавления или однократной записи, и читают только при протоколируемом, ограниченном доступе.
-
DACI и RACI для технических решений: один утверждающий, поимённые участники
DACI называет драйвера, который ведёт процесс принятия решения, единственного утверждающего (approver), который его принимает, участников (contributors), у которых есть голос, но нет права вето, и информируемых (informed), которые узнают об итоге. RACI распределяет по задачам роли ответственного за исполнение (responsible), подотчётного (accountable), консультируемого (consulted) и информируемого (informed). Обе модели работают для технических решений, если роли зафиксированы письменно до начала обсуждения.
-
Соглашения внедрения зависимостей в .NET: время жизни, области видимости и ловушка captive dependency
Microsoft.Extensions.DependencyInjection регистрирует сервисы в IServiceCollection со временем жизни transient, scoped или singleton и внедряет их через публичные конструкторы; задокументированные правила гласят: никогда не внедрять scoped-сервис в singleton, позволять контейнеру самому освобождать то, что он создал, избегать вызовов в стиле service locator и включать валидацию областей видимости, чтобы captive dependency обнаруживалась ошибкой при старте, а не утечкой состояния между запросами.
-
Построение доверительного интервала для медианы, перцентиля или отношения методом bootstrap
Многократно ресэмплируйте исходные наблюдения с возвращением, вычисляйте статистику на каждой ресэмплированной выборке и считывайте интервал из полученного распределения; это даёт оценку неопределённости для медиан, перцентилей, отношений и разностей — там, где не работает ни одна учебниковая формула. Указывайте метод, число ресэмплов и размер выборки и не доверяйте методу для крайних перцентилей на маленьких выборках.
-
Honor Retry-After as a lower bound
Schedule retries from either form of Retry-After while preserving the task deadline and avoiding premature repeated requests.
-
Запись показаний бытового термометра в ледяной бане: журнал смещения показаний для каждого прибора
Предлагаемый протокол, ограниченный только записью показаний и следующий описанию точки таяния льда по NIST (дроблёный лёд из дистиллированной воды, смесь лёд-вода сверху донизу, заданная глубина погружения), чтобы фиксировать, что показывает каждый бытовой термометр при номинальных 0 °C, вместе с датой, деталями подготовки и временем, за которое показание стабилизировалось; протокол ведёт историю смещений по каждому прибору и не даёт никаких рекомендаций по калибровке или по применению для пищевых продуктов.
-
Бенчмаркинг изменения: прогрев, повторы, разброс и что указывать в отчёте
Сравнение по времени выполнения — это результат только тогда, когда он устойчив к шуму: зафиксируйте нагрузку, отбросьте прогревочные прогоны, чередуйте много повторов каждого варианта, выбирайте статистику до того, как посмотрите на данные, и указывайте разброс и окружение рядом с каждым числом. Разница меньше разброса между прогонами — это не находка.
-
Как нужно ставить домашнее сравнение всхожести семян, чтобы результаты двух разных домохозяйств можно было сопоставить?
Открытый вопрос: лаборатории проверяют семена по Международным правилам испытания семян ISTA, но у домохозяйств, сравнивающих две партии семян или два подоконника, нет общего протокола; какие размеры выборки, правила подсчёта, длительность и записи об условиях делают такие домашние сравнения информативными и сопоставимыми между разными домохозяйствами?
Машиночитаемо: JSON