🦀 Почему dbg! всё ещё удобнее отладчика

Команда Rust опубликовала результаты опроса более 2300 участников. Самыми популярными подходами оказались вывод в консоль и dbg!: для небольшого сбоя они часто проще настройки отладчика.

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

Для авторов библиотек есть полезная деталь: атрибут debugger_visualizer позволяет включить визуализаторы в отладочную информацию. Поддерживаются Natvis и GDB pretty printers. Пользователю вашей структуры данных будет проще увидеть её содержимое, чем разбирать внутренние поля.

🐸 Библиотека программиста

🛠 Инструмент деплоя сменили. Что считать успехом?

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

Автор руководства на TypeScript выносит эти условия в отдельную спецификацию. Два исполнителя получают один контракт и возвращают данные для проверки: версию, доступные реплики, долю ошибок и задержку.

Сравнивать можно результат операции, даже если шаги внутри различаются. Примеры учебные, в памяти, но вопрос для своего CI/CD вполне практический: при смене инструмента вы переносите команды или сохраняете условия, при которых деплой считается успешным?

🐸 Библиотека программиста

Почему разработчик планирует отдавать больше задач Claude

Винсент Шмальбах описал план перераспределить расходы на ИИ: больше работы отдавать Claude, а Codex сохранить для части задач.

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

В личном разборе Шмальбах связывает эти эпизоды с условиями подписки и затратами на собственные проекты.

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

🐸 Библиотека ИИ для айтишников

📊 API тормозит. В логах ошибок нет

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

В руководстве по NestJS Observe разбирают наблюдаемость с контекстом фреймворка: контроллеры, провайдеры, guards и interceptors помогают понять, где выполнялась работа и куда ушло время.

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

🐸 Библиотека программиста

🧠 Ответ короче. Задача дороже

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

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

Часть экономии дала уборка лишнего форматирования, которое агент уже не использовал. Если оптимизируете своего агента, считайте стоимость завершённой задачи, число повторных действий и качество результата. Минимальный ответ инструмента может оказаться не самым выгодным.

🐸 Библиотека программиста

📊 Архитектурную схему тоже можно отправить на ревью

Добавили очередь, разделили сервис, поменяли базу — а в документации всё ещё старая картинка. Если схема описана кодом, её изменения можно обсуждать в том же PR.

В руководстве по Python Diagrams показывают, как собрать схему из узлов, связей и кластеров. Graphviz отвечает за отрисовку, а в Python вы задаёте компоненты и направление потока данных.

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

🐸 Библиотека программиста

📊 Индекс есть. Запрос стал медленнее

В архивном треде r/PostgreSQL автор отключил последовательное сканирование, чтобы база использовала индексы. По его замерам, запрос стал выполняться около 80 секунд вместо 18.

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

Сравнивайте планы на своей нагрузке через EXPLAIN (ANALYZE, BUFFERS): оценки и фактические строки, время узлов и чтение страниц. Отключение Seq Scan годится для сравнения планов, но не как универсальная настройка ускорения.

🔗 Разбор запроса и обсуждение

🐸 Библиотека программиста

🖥 Песочница есть. Файлы проекта всё ещё можно удалить

В Docker Sandboxes агент работает внутри отдельной microVM. Но доступ к проекту зависит от режима: direct разрешает сразу менять исходную папку, clone даёт отдельную копию для работы.

Автор эксперимента с Claude Code проверил это на Mac: в direct агент удалил файл и создал Git hook. Удаление попало в обычный diff, а hook в .git/hooks — нет. Его не запускали.

В clone изменения остались в копии. При этом агент мог читать файлы проекта и отправить тестовое значение на разрешённый сервер. Перед запуском проверьте доступные папки и сеть; после работы в direct может понадобиться проверить больше, чем diff.

🐸 Библиотека программиста

💬 Ревьюер сменился. Замечания остались

Разработчица в Threads рассказала о неожиданном продолжении код-ревью. По её словам, после комментариев об ошибках стажёр убрал её из ревьюеров и запросил проверку у другого коллеги.

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

Полезно договориться, как фиксировать блокирующие замечания и кому подтверждать их закрытие. Смена проверяющего и устранение проблемы — разные события. А у вас можно сменить ревьюера, пока его замечания остаются открытыми?

🔗 Исходная история в Threads

🐸 Библиотека программиста

🔎 Где багхантер начинает искать ошибки

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

В интервью GitHub он объясняет этот подход и отдельно напоминает: находку от ИИ нужно подтвердить самому, прежде чем отправлять отчёт.

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

🐸 Библиотека программиста

⌨️ Опечатка в HTML-шаблоне останавливает сборку

Лукаш Лалинский сделал zt — шаблонизатор, который во время zig build превращает HTML-шаблоны в код Zig. Параметры типизированы: ошибку в имени поля или несовместимый тип компилятор замечает до запуска приложения.

Сгенерированный код пишет результат в std.Io.Writer: можно отправлять HTML в сокет или собирать его в буфере. Динамические значения экранируются по умолчанию, а URL в href и src проверяются на опасные схемы. Для сырого HTML нужно явное исключение.

Автор разбирает устройство библиотеки и границы защиты: безопасные значения по умолчанию не закрывают все варианты XSS. Интересный пример того, как перенести часть ошибок шаблона из запроса пользователя в сборку.

🔗 Разбор автора, найденный на Hacker News

🐸 Библиотека программиста

☔️ Планы на выходные снова испортила погода? У нас есть план получше.

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

📍 В Proglib Academy покупаешь один курс, а второй получаешь в подарок. Платишь только за один!

Вот несколько сочетаний:

💥 ⁠Разработка ИИ-агентов + ⁠Python
💥 ⁠Machine Learning + ⁠Математика для Data Science

Можно выбрать и другие курсы — под свои интересы и цели.

⏳ Акция действует до 18 октября.

➡️ ⁠Выбрать курсы и оставить заявку

👀 ИИ оставил двадцать замечаний. Сколько из них полезны?

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

GitHub представил ReviewBench — бенчмарк на 219 публичных PR на 19 языках. Эталонные находки собирали из нескольких источников: человеческого ревью, статического анализа и LLM. Результаты можно смотреть по серьёзности и типу проблем.

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

🐸 Библиотека программиста

🖥 До теста нужно пройти шесть слоёв абстракций

В архивном обсуждении r/ExperiencedDevs участник описал интеграционные тесты, которые коллеги избегали. Чтобы понять путь от написанного сценария до проверки, приходилось разбираться примерно в шести слоях самописной инфраструктуры.

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

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

🔗 Опыт команд в r/ExperiencedDevs

🐸 Библиотека программиста

👀 strtod вернул ноль. Это число или ошибка?

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

Автор разбора сравнивает поведение glibc и musl и требования ISO C и POSIX. Проверка одного errno тоже не переносима: при строке без числа реализации могут сигнализировать по-разному.

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

🔗 Разбор strtod, найденный на Hacker News

🐸 Библиотека программиста