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

описание

Заметки и ссылки на будущее, чтобы изучить когда будет время. Разместить рекламу: @tproger_sales_bot Правила общения: https://tprg.ru/rules Другие каналы: @tproger_channels Другие наши проекты: https://tprg.ru/med

← к каналу @prog_stuff

6 558

подписчиков

Охват к подписчикам

7,5%

ERR

Реакции к просмотрам

0,40%

184 на 49 постов

Пересылки к просмотрам

0,96%

444

Постов в день

1,4

всего 177

Где отзываются чаще

доля реакций к просмотрам

15 авг.@prog_stuff2,97%
16 авг.@prog_stuff2,33%
16 авг.Новак Калуджерович писал арифметику больших чисел для криптографической библиотеки и нашёл ошибку в Algorithm D — том самом длинном делении из книги Кнута, которое перепечатано в сотнях реализаций. Суть места, где всё ломается: очередная цифра частного сначала оценивается по старшим разрядам, а потом оценка исправляется. Кнут утверждает, что после коррекции она гарантированно помещается в один разряд. Контрпример нашёлся в системе счисления по основанию 3: делим 45 на 16, правильное частное 2, а пробная оценка 5. После двух коррекций оценка всё ещё двухразрядная, и дальнейшее умножение берёт только младший разряд, вычитая фактически ноль. Ошибка десятилетиями оставалась незаметной, потому что зависит от того, как именно ведёт себя аппаратное деление на конкретной архитектуре. На современных машинах с основанием два в шестьдесят четвёртой она практически не проявляется. Автор написал Кнуту и получил тот самый гексадецимальный доллар — чек за найденную ошибку — с рукописной пометкой, что Algorithm D читают чаще многих других алгоритмов книги. @prog_stuff0,97%
16 авг.Полгода Tailscale ловила порчу баз: 19 случаев, ни одного общего признака — ни шарда, ни клиента, ни времени суток. Воспроизвести не удавалось, оставалось ждать следующего раза с диагностикой наготове. Зацепку дал побочный инструмент. Чтобы восстанавливаться без потери данных, команда стала писать журнал всех изменяющих запросов и проигрывать его поверх копии. Дважды журнал не проигрался: данные, зафиксированные одной транзакцией, оказались невидимы для следующих — без единой ошибки. Виновата гонка в самом SQLite: при совпадении записи с контрольной точкой часть страниц считается перенесённой в основной файл, хотя туда не попала. Багу оказалось не меньше шестнадцати лет, он настолько редкий, что для тестов его приходится вызывать намеренно. Tailscale попадала в него чаще других, потому что берёт контрольные точки под ручное управление и делает их очень часто. Вывод авторов: скучная технология в нестандартном режиме перестаёт быть скучной. Всё было по документации — просто в стороне от протоптанной дороги. Как искали и что нашли @prog_stuff0,94%
07:05Простой запрос — сумма колонки на 500 миллионов чисел. PostgreSQL считает его 20 секунд, тот же цикл на Rust — 358 миллисекунд. Автор проекта pgrust показывает по шагам, из чего складывается разрыв, собирая уменьшенную копию исполнителя запросов PostgreSQL и добавляя к ней оптимизации по одной. Исходная модель отдаёт строки по одной, через метод next() у каждого узла плана — так устроен и настоящий PostgreSQL. Это 1,3 секунды. Дальше: выдавать сразу пачку по 1024 значения в буфер на стеке — 480 мс. Слепить сканирование и суммирование в один узел — 358 мс, то есть ровно обычный цикл. Векторные инструкции — 135 мс. Честная оговорка от автора: слипшийся узел вшит под конкретный запрос, и в общем случае так не выйдет — нужна компиляция плана на лету. А PostgreSQL медленнее ещё и потому, что делает вокруг запроса много другой работы: блокировки, разбор формата хранения. @prog_stuff0,92%
24 дек.YeaHub: база вопросов на русском для подготовки к собесам На ресурсе собраны вопросы по всем популярным направлениям: бэк, фронт, DevOps, ML, мобилка, QA, DS, gamedev. Можно выбирать по языкам, технологиям и уровню сложности. Помимо этого есть разделы по Git, Docker и другим инструментам, а также трекер прогресса и тренажёр для закрепления знаний. #полезности #собеседование0,89%
13 окт. 2025 г.Наезжает босс. Как не просесть, но и не стать ред флагом 🚩 — Сразу снизить темп речи и говорить чуть тише — это автоматически сбивает накал. — Задавать уточняющие вопросы вместо оправданий — переводит разговор в рациональную плоскость. — Не защищаться, а переформулировать упрёк в задачу: «Правильно понимаю, что нужно…?» — Слегка замедлять паузы перед ответом — создаёт ощущение уверенности и контроля. — Если наезжают при других — мягко предложить обсудить лично. Это часто моментально гасит напор. — Уверенно сказать: Стоп, мне не приятно 🤚 #советы #менталка0,78%
4 июн. 2025 г.без подписи0,78%
11 авг.Время до первого ревью выросло с 3,5 часа до 16, хотя кода стали писать больше Джон Ван, технический директор Assembled, разобрал 7 августа, что случилось с их разработкой после перехода на агентов. Инженеры чувствовали, что стали быстрее, а метрики поставки почти не двигались: пул-реквестов заводили больше, а вливали ненамного больше прежнего. В данных нашлось объяснение. Открытых пул-реквестов стало заметно больше, стопки выросли до двадцати штук на одну задачу, размер одной правки увеличился в 2,5 раза, потому что агент пишет более объёмный дифф на то же изменение. Время до первого ревью поднялось с медианных 3,5 часа в декабре 2025 до 16 с лишним часов в мае 2026. Узким местом оказалось человеческое ревью, а число ревьюеров осталось прежним. В ответ собрали автоматического ревьюера для малорисковых правок: 🔘 каждый пул-реквест независимо смотрят два агента в отдельных песочницах, а третий сводит оба отзыва и применяет политику одобрения; 🔘 в политике есть жёсткие правила, например не одобрять правки больше тысячи изменённых строк, и содержательные: не трогать аутентификацию, биллинг, права доступа, работу с секретами и ключами, не вводить новых архитектурных приёмов; 🔘 первая версия политики оказалась слишком строгой: она отклоняла столько, что люди переставали ею пользоваться, а отключённым ревьюером ничего не ускоришь; 🔘 обратная крайность опаснее: слишком мягкая политика превращается в канал, через который сознательно проводят то, что не хочется показывать человеку; 🔘 после полного запуска автоодобрения дали 43 процента всех влитых правок, а медиана такого ревью — восемь минут; 🔘 инженеры начали подгонять пул-реквесты под критерии политики, так что она работает как система стимулов: чего требуешь, того и становится больше. По результатам за три недели влитых правок стало в 2,4 раза больше, чем до агентов, строк кода в 2,8 раза, то есть работу не просто нарезали мельче. Пропускная способность больших правок от 600 строк выросла в 3,5 раза, хотя их автоматический ревьюер обычно не одобряет. Рефакторинг вырос в 7,5 раза, работа над тестами в 3,4. Сообщений о багах стало на 27 процентов меньше, доля откатов держится на 0,8 процента. Автор сам оговаривает, что это наблюдение за раскаткой, а не контролируемый эксперимент, и окно слишком короткое: баги приходят с задержкой, поэтому по долгосрочному качеству выводов пока нет. Полная статья: https://www.assembled.com/blog/code-review-bottlenecks-how-we-hill-climbed-our-way-to-higher-pr-throughput @prog_stuff0,77%
24 окт.без подписи0,76%
17 авг.Что будет, если в одной транзакции PostgreSQL накопится больше 64 вложенных? Просядет весь кластер — включая соединения, которые об этой транзакции ничего не знают и работают с другими таблицами. PlanetScale разобрали механику. У каждого процесса есть кэш идентификаторов вложенных транзакций, обычно на 64 записи. Переполнился — снимок помечается переполненным, и проверка видимости каждой строки идёт через служебную структуру pg_subtrans: блокировка, а при промахе ещё и диск. Вложенные транзакции при этом появляются сами: их создаёт каждый блок PL/pgSQL с секцией EXCEPTION, а не только явный SAVEPOINT. Вторая беда приходит позже: записи о работающих транзакциях уезжают в журнал неполными, и новая реплика не может построить снимок. Она проигрывает журнал, но соединения не принимает — то есть поднятая на пике нагрузки реплика не даёт никакой ёмкости. Следить можно через pg_stat_get_backend_subxact() и счётчики pg_stat_slru. Готового способа предотвратить переполнение в PostgreSQL 18 нет. @prog_stuff0,72%
13 июн. 2025 г.Рабочее место, которое лечит Представьте, что можно потратить 5–10 минут на рабочее место — и больше не тратить ресурс на массажи, «выправление осанки» и прочие компрессы на шею. Минимум движений — максимум отдачи: — Монитор на уровне глаз. Не «примерно», а точно — верхняя треть экрана должна быть на уровне взгляда. Это моментально разгружает шею. — Ноги стоят, не висят. Если стул высоковат — подставка. Иначе — напряжение в пояснице. — Свет сбоку. Не спереди, не сзади — сбоку. Уменьшает нагрузку на глаза. — Один предмет, который радует. Растение, фото, фигурка — звучит странно, но это снижает уровень стресса и делает рабочее место «своим». Звучит мелко, а ощущается как апгрейд. #советы #рабочееместо0,61%