Ссылку на вчерашнюю статью я нашёл у Марка Эриксона в статье "Blogged Answers: Debugging Tips".

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

В статье Марк ещё рассказывает про три случая из его реальной работы, которые потребовали долгого дебага. В первой истории проблема заключалась в неправильном регистре файла, во второй и третьей — в проблемном коде, который забивал главный поток Twisted, из-за чего зависала вся система.

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

#debug #programming

https://blog.isquaredsoftware.com/2019/01/blogged-answers-debugging-tips/

Михай Парпарита из Quip написал статью про то, как они отлаживают своё приложение — "How Quip Builds In-Product Debugging Tools".

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

Quip использует много подобных инструментов. Например, для визуализации взаимосвязи уровня данных и представления у них есть "Overlay Id", который для каждого компонента показывает соответствующие данные модели. Есть инструмент для отладки редактора, который в инлайн-режиме отображает отладочную информацию об отображаемых сущностях. Такой подход исключает затраты времени на открытие инструментов разработчика и потерю фокуса из редактора. Есть небольшой инструмент, который показывает в оверлее количество ререндеров компонента. Реализуется он так: в каждый компонент инжектится componentDidUpdate, который увеличивает счётчик и записывает его в data-атрибут. Значение атрибута отображается поверх компонента с помощью CSS:

.debug-react-rerender-count:after {
    content: attr(data-debug-react-rerender-count);
    // other styles for positioning and color
}

Мне статья понравилась. В ней есть интересные идеи, которые можно применить в своём проекте.

#dx #debug

https://quip.com/blog/how-quip-builds-inproduct-debugging-tools

Лоит Бэллад из Cloudflare написал статью про то, как они тестируют разрабатываемые протоколы — "How to develop a practical transport protocol".

На данный момент Cloudflare участвует в разработке QUIC и HTTP/3. Отладка сетевого стека — нетривиальная задача, особенно, если речь идёт об отладке на реальных мобильных устройствах. В самом простом случае разрабатывать протокол можно на одном компьютере, используя сеть из docker-контейнеров. Но такой подход не может выявить проблемы, которые могут возникнуть в реальном мире. Поэтому для полноценного тестирования создаются специальные "лаборатории" — выделенные машины, соединённые между собой в сеть. Для эмуляции edge, 3g, lte используется netem (на Linux) и ipfw + dummynet (на FreeBSD). Меня немного позабавило, что ребята взламывают девайсы на iOS, для того, чтобы понять, как будут работать новые протоколы на реальном железе от Apple.

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

#http #debug #net

https://calendar.perfplanet.com/2019/how-to-develop-a-practical-transport-protocol/

Кристофер Хиллер из IBM рассказал как эффективно работать с Diagnostic Repots в Node.js — "Debugging NodeJS in Production with Diagnostic Reports".

Diagnostic Reports был добавлен в Node.js 11.8. С помощью этой фичи можно получить много полезной информации, которая может помочь при поиске проблем. Diagnostic Reports генерирует большой отчёт — JSON-файл, в котором есть данные про окружение, используемые разделяемые библиотеки, текущее состояние event loop и т.п. Кристофер представил утилиту report-toolkit, которая облегчает работу с отчётом. Эта утилита может быть полезна при поиск причин зависаний, анализ моргающих процессов (работает в одном окружении, падает в другом).

Полезный доклад. Рекомендую посмотреть, если работаете с нодой.

#talk #nodejs #debug

https://www.youtube.com/watch?v=PLiar_Aj9gs

Крейг Баклер написал неплохой пост про отладку Node.js-приложений — "How to Debug a Node.js Application: Tips, Tricks and Tools".

В статье рассказывается про разные способы отладки: от методов объекта console ( console.log(), console.dir(), console.count() ) до использования сторонних npm-пакетов. Довольно много инфы про VS Code. Например, он поддерживает логпойнты (логирование состояния приложения без изменения исходного кода программы). В отличие от инструментов разработчика Crhome и Firefox, где логпойнт это js-код, VS Code использует формат some description {variable}.

Cтатью можно почитать, если хотите узнать больше про возможности отладки Node.js.

#debug #nodejs

https://www.sitepoint.com/debug-node-app-tips-tricks-tools/

Генрик Уорн написал статью про хорошее логирование — "Good Logging".

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

Логирование не должно быть слишком подробным или скупым. Хорошие сообщения в логах должны говорить не про абстрактные серверы и файлы, а про конкретные ip-адреса и имена файлов. Сообщения должны быть таким, чтобы по ним можно было удобно grep'ать. При логировании сложной логики все шаги можно поместить в список, и вывести его в лог как одну большую строку. В хороших сообщениях не должно быть специальных символов, чтобы подчеркнуть важность, лучше для этого использовать разные уровни логирования (DEBUR, ERROR, INFO etc.) Очень трудно с первого раза придумать хорошие сообщения, поэтому их нужно постепенно улучшать. Также нужно не забывать добавлять новые сообщения, если при отладке ошибки в логах нет всей нужной информации.

Очень толковая статья. Рекомендую почитать всем.

#debug #programming

https://henrikwarne.com/2020/07/23/good-logging/

Михай Парпарита из Quip написал пост о том, как нестрогое сравнение в JS привело к повышенному потреблению CPU — "The Case of the Missing Equals Sign".

Михай столкнулся с проблемой высокого потребления CPU в production-сборке macOS приложения Quip. Quip построен на базе web-технологий и работает вунтри WebView.

С помощью профилировщика XCode был найден проблемный код — метод toString() у функции. JavaScriptCore — JS-движок, использующийся WebView, — при вызове этого метода вырезает подстроку с текстом функции из исходного кода и возвращает её как результат. Это объяснило, почему проблема не воспроизводилась до конкатенации всех файл в большой бандл. Если функция определена в очень большом файле, то выполнение этого метода приводит к повышенному потреблению CPU. Метод toString в свою очередь вызывался неявно при нестрогом сравнении. Проблема была решена заменой нестрогого сравнения на строгое сравнение.

#js #debug

http://blog.persistent.info/2020/11/the-case-of-missing-equals-sign.html

Ещё один пост про прошедший Chrome Dev Summit. Ингвар Степанян выступил на нём с небольшим докладом про улучшения отладки скомпилированного в WebAssembly C/C++ кода в инструментах разработчика — "Debugging WebAssembly with modern tools".

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

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

Новый отладчик пока доступен в экспериментальном режиме в Chrome Canary, но он уже используется разработчиками Google Earth.

#debug #webassembly #chromium

https://developers.google.com/web/updates/2020/12/webassembly

Нашёл статью Джона Регера, в которой он рассказывает о том, почему мы не замечаем баги в своих программах, в то время как пользователи находят их очень быстро — "Operant Conditioning by Software Bugs".

В психологии есть понятие "оперантное обусловливание" (operant conditioning) — адаптация поведения человека как ответ на последствия, возникающие в результате этого поведения. Этот эффект можно объяснить на примере. У автора статьи был ноутбук, который постоянно крэшился из-за быстрой прокрутки страницы в браузере (проблема была в видеодрайвере). Чтобы система постоянно не ломалась, Джон подсознательно выработал привычку прокручивать страницу по чуть-чуть. У всех опытных пользователей компьютера есть много похожих привычек: не прерывать процесс установки, терпеливо ждать ответа от операционной системы, если она подвисла, не использовать эзотерические опции конфигурации и т.п.

Этим эффектом также можно объяснить, почему при тестировании своих собственных программ разработчики находят меньше ошибок, чем тестировщики.

Очень интересная статья. Рекомендую почитать.

#debug #psychology

https://blog.regehr.org/archives/861
https://news.ycombinator.com/item?id=16863233 (обсуждение на HN)

В блоге sqreen была опубликована статья про эксперименты с удалённой отладкой Node.js — "Experimenting with remote debugging: Node.js runtime code injection".

Любой Node.js-процесс, работающий на Linux или macOS, можно перевести в режим отладки с помощью сигнала SIGUSR1: kill -USR1 <PID>. Затем к этому процессу можно подключиться с помощью Chrome DevTools, поставить брекпойнты, проинспектировать код и сделать всё, что можно сделать в отладчике.

В статье разбирается другой подход — внедрение кода в работающий процесс. Для этого используется библиотека chrome-remote-interface, которая реализует протокол Chrome DevTools, но предоставляет больше возможностей, чем стандартный JS-отладчик в браузере.

Автор статьи пишет, что нигде не встречал подобный подход, но он может использоваться для создания мощных инструментов отладки Node.js.

#nodejs #debug

https://blog.sqreen.com/remote-debugging-nodejs-runtime-code-injection/

В блоге DebugBear была опубликована статья, посвящённая отладке проблем производительности сайта с помощью Chrome DevTools, — "Profiling site speed with the Chrome DevTools Performance tab".

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

Совет из статьи. Часто возникает ситуация, когда сложно понять взаимосвязи между активностями во время загрузки страницы, так как они происходят почти одновременно. Для упрощения отладки можно "растянуть" по времени эти активности с помощью троттлинга сети и CPU.

Полезная статья. Рекомендую заглянуть.

#performance #debug

https://www.debugbear.com/blog/devtools-performance

Минко Гечев из Google представил Angular DevTools — "Introducing Angular DevTools".

Angular DevTools — это расширение для Chrome, облегчающее отладку и профилирование Angular-приложений. Оно было разработано с нуля с участием разработчиков Augury — популярного расширения для отладки Angular.

С помощью Angular DevTools можно инспектировать и редактировать дерево компонентов, профилировать исполнение цикла отслеживания изменений (change detection cycle). Также в рамках этого проекта был улучшен опыт отладки Angular-приложений: был добавлен новый API и улучшены сообщения об ошибках. В следующих релизах разработчики планируют добавить наиболее полезные фичи Augury.

Angular DevTools поддерживает приложения, разработанные с помощью Angular v9 и выше на базе Ivy.

#angular #debug #announcement

https://blog.angular.io/introducing-angular-devtools-2d59ff4cf62f

Брайан Люиз Рамирез рассказал об использовании Local Overrides для анализа производительности сайта — "Using Chrome Local Overrides To Optimize Page Speed".

Local Overrides — это фича Chrome DevTools, с помощью которой можно временно подменить любой ресурс сайта. Например, в инструментах разработчика можно поправить index.html, добавить исправленный HTML в Local Overrides, и при повторном переходе на сайт вместо оригинального index.html будет браться его изменённая версия.

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

Рекомендую почитать статью и поэкспериментировать с Local Overrides. Эта фича может быть полезна для любых быстрых экспериментов.

#performance #debug

https://blr.design/blog/local-overrides/

Руководство по отладке CSS

Стефани Эклз написала статью про отладку CSS — "A Guide To CSS Debugging".

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

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

#css #debug

https://www.smashingmagazine.com/2021/10/guide-debugging-css/

Космические лучи и ошибки в программах

В университете у меня был предмет по теории управления. Там преподаватель рассказывал про альфа-частицы и протоны из космоса, переключающие биты в процессоре и ломающие программы. На эту тему на youtube-канале Veritasium было опубликовано видео — "The Universe is Hostile to Computers".

Ошибки, вызванные подобными явлениями, называются нарушениями в результате единичного события (single-event upset, SEU). Их учитывают при проектировании микроэлектроники и при разработке программного обеспечения, которое должно надёжно работать в условиях высокой радиации и повышенного влияния космических лучей. По этой причине в космосе вычисления дублируют на независимых компьютерах, а NASA во многих космических миссиях использует специальную версию процессора PowerPC — RAD750. По сравнению с обычными процессорами RAD750 в 30 раз более устойчив к возникновению SEU.

Если вы столкнулись с невоспроизводимым багом, то, возможно, проблема не в программе, а в частице, прилетевшей из соседней галактики.

#programming #debug #video

https://www.youtube.com/watch?v=AaZ_RSt0KP8
https://www.youtube.com/watch?v=jOTM9T59IX4 (на русском языке)

Отладка утечек памяти с помощью "Detached Elements" в Edge DevTools

Патрик Броссет из Microsoft рассказал о новом инструменте для упрощения поиска утечек памяти в клиентских JavaScript-приложениях — "Debug memory leaks with the Microsoft Edge Detached Elements tool".

В DevTools Edge была добавлена новая вкладка "Detached Elements". С её помощью можно получить список всех DOM-элементов, откреплённых от документа, и быстро найти участок кода, в котором были сохранены ссылки на эти элементы. Для поиска утечек также можно использовать вкладку "Memory" со снятием снапшотов памяти (доступно во всех Chromium-based браузерах), но по сравнению с "Detached Elements" это не так удобно.

"Detached Elements" будет доступен в Edge 97.

#edge #devtools #debug

https://blogs.windows.com/msedgedev/2021/12/09/debug-memory-leaks-detached-elements-tool-devtools/

Fuite — инструмент для поиска утечек памяти в SPA

Нолан Лоусон представил утилиту для автоматизированного поиска утечек памяти в SPA — "Introducing fuite: a tool for finding memory leaks in web apps".

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

Fuite не интегрируется в DevTools, как недавно представленный инструмент Edge, но помогает в поиске более широкого спектра утечек памяти.

#debug #tool #spa

https://nolanlawson.com/2021/12/17/introducing-fuite-a-tool-for-finding-memory-leaks-in-web-apps/

Встроенный браузер Facebook

Томас Штайнер проанализировал работу встроенного браузера Facebook (In-App Browser — IAB), чтобы разобраться, чем он отличается от обычных браузеров — "Inspecting Facebook's WebView".

Некоторые приложения открывают ссылки во встроенном браузере на базе WebView, потому что это даёт им больше возможностей для работы со страницей. На сайтах, открытых с помощью IAB Facebook, встраивается код сбора метрик производительности и информации о доступных возможностях WebView, в window добавляются свойства TEMPORARY и PERSISTENT, модифицируется отправляемый HTTP-заголовок User-Agent.

WebView не поддерживает все возможности браузеров, поэтому некоторые страницы в нём могут быть сломаны или отображаться неправильно. Так как пользователей Facebook несколько миллиардов, вероятность встречи с подобными ошибками довольно высока. Для упрощения решения проблем в IAB включён режим отладки, чтобы разработчики могли подключиться к WebView удалённо с помощью DevTools браузера.

#facebook #debug #mobile

https://blog.tomayac.com/2019/12/09/inspecting-facebooks-webview/

Новое дерево доступности в Chrome DevTools

Йохан Бей из команды разработки Chrome DevTools рассказал про новое дерево доступности, которое появится в будущих версиях Chrome — "Full accessibility tree in Chrome DevTools".

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

Новое дерево доступности пока доступно только в Chrome Canary.

#debug #a11y #internals #devtools

https://developer.chrome.com/blog/full-accessibility-tree/

Time-travel debugging в Svelte

Сэм Ван Тассел рассказал про DeLorian — новый инструмент для упрощения отладки Svelte-приложений — "Time Travel Debugging in Svelte with DeLorean".

DeLorian — это расширение Chrome DevTools для отслеживания изменений состояния приложения во времени (time-travel debugging). При изменении состояния создаётся снапшот, к которому можно вернуться в любое время. Перемещение по истории работает также как в Redux DevTools. Также DeLorian отображает дерево компонентов и связанные с ними переменные.

На данный момент есть ограничения: корень приложения должен находится в DOM-элементе с id="root", приложение должно быть собрано в dev-режиме и работать локально.

#svelte #debug #tool

https://medium.com/@vantassel.sam/time-travel-debugging-in-svelte-with-delorean-26e04efe9474