В третьей части ищем ошибку при удалении задачи из списка дел, и попутно путешествуем во времени разбираемся со стеком вызовов в отладчике.
В жизни каждого инженера может произойти ситуация, когда процесс его приложения «завис» и не выполняет ту работу, которую должен. Причины могут быть разные и чтобы узнать их, нужно заглянуть во внутренности процесса и расследовать, что же там происходит. Для этого, можно снять дамп и проанализировать его. Каждый такой случай уникальный, но подходы к анализу дампов — общие. В этой статье я покажу, как расследовал одну из подобных ситуаций и пришёл к неожиданным выводам.
main.
Продолжаем погружаться в отладку с Firefox DevTools. Во второй части разбираем, что такое точки останова в отладчике, как ими пользоваться и почему они — замена console.log.
В сети полно обзоров Chrome DevTools, которые демонстрируют многочисленные возможности этого прекрасного инструмента. DevTools настолько большие, что познать их полностью, как мне кажется, уже почти невозможно.
В этой заметке я бы хотел остановиться на различных нюансах, полезных при отладке. Какие-то из них я почерпнул в сети (например в комментариях на Хабре), до каких-то додумался сам. Надеюсь вы найдёте для себя что-нибудь полезное.
Под катом:
— Как отладить popup-ы, которые исчезают при потере фокуса
— Как убить повисший JS-цикл, не убивая вкладку
— Различные нюансы работы с breakpoint-ми
— Методы ведения войны с sourceMaps
— Перехват network-запросов
— Как отладить race-condition
— Почему стоит опасаться галочки "disable cache"
— Что делать если у вас не Hi-DPI экран?
Понедельник, 9 утра, сообщение в рабочем чате: "Всё сломалось, почините". Согласитесь, неприятная ситуация, особенно когда это ваш первый месяц работы, а сломалось что-то в функционале, с которым вы ещё ни разу не контактировали, да и не трогал его уже никто месяцами.
Используете для отладки JavaScript-кода только console.log? Есть способ получше! Отладчик в Firefox DevTools помогает быстро находить ошибки в коде и бережёт ваши нервы и время.
Думаю, что каждый из embeded-разработчиков хотя бы раз в жизни пользовался терминалом для работы с COM-портом ПК - простой программой, позволяющей персональному компьютеру через встроенный интерфейс RS-232 (или USB-переходник) общаться с внешними устройствами, например такими, как GSM-модем или просто обмениваться данными с микроконтроллером в процессе разработки и отладки прошивки.
Таких терминалов на данный момент создано довольно много, как говорится "на любой вкус". Однако, как часто бывает, когда начинаешь более-менее длительно работать в какой-либо программе, начинает постоянно не хватать то одной функции, то другой, то одно кажется сделано неудобно, то другое. Всё время ловишь себя на мысли: "это лучше сделать было бы так, а это - вот эдак" :)
Подобные мысли и определённые требования к функционалу в конечном счёте привели к созданию "своего" терминала, который создавался не один год, наращивая свою функциональность и удобство. Он создавался в процессе разработки прошивок для микроконтроллеров, разбора многих протоколов опроса оборудования и возможно придётся "по душе" многим разработчикам ПО и электроники в целом.
Поделюсь с вами кейсом ускорения работы одного сайта на WP + WooCommerce. Статья будет полезна джунам и миддлам кто разрабатывает сайты, кто занимается оптимизацией сайтов и кто хочет посмотреть на работу php кода "с высоты". Для себя из полезного можно узнать как связать вместе OpenServer, PhpStorm и xDebug
Существует много проекты в которых нужно сразу видеть результат переменных в момент выполнения программы. Например обработка нажатий клавиш от пользователя, навигация между страницами в GUI приложениях, обработка данных из форм на веб проектах.
В общем во всех проектах где есть цикл событий, хорошо бы видеть значения переменных, когда идет процесс отладки.
Для этого используют обычный print() но по стандарту ограничен одной консолью, или loggin() но его нужно относительно дольше настраивать, чем проект console-debugger, по причине того что нужно указывать файл, стиль вывода даны в файл, рейтинг обработки, в ручную запускать слежение за файлом, в ручную закрывать слежение за файлом, когда вам больше не нужен обработчик.
Я понимаю плюсы лорнирования но они не подходят для дебаггинга ...
Недавно я проходил собеседование и одним из вопросов, стал такой загадочный экземпляр:
"А какое главное преимущество системы типов Kotlin перед Java"?
Честно говоря, выделить какое преимущество считалось главным, оказалось неразрешимой для меня задачей: Nothing, отсутсвие Wildcard и First-Class Functions вместо Java-костыля с Functional Interface (имеется ввиду 8я версия Java) не заняли первых мест в личном топе интервьюера, который мне предложили угадать.
Оказалось что главное в Kotlin - возможность обьявить Nullable Type и Null Safety подход (Замечу, что по моему опыту собственные или библиотечные Optional или Maybe решают эту проблему, и пишутся за 10 минут на Java 7. А еще есть аннотации Nullable, позволяющие проверять поля в сompile-time. Короче, есть много способов заставить делать Null проверки в plain Java. Ну да ладно).
Но речь пойдет не о странных вопросах, связанных со вкусовыми предпочтениями интервьюеров относительно синтаксического сахара.
Дело в том, что Null Safety в Kotlin можно сломать, притом не выходя из под его безопасного купола в суровый дикий мир Java и Null-Referrences.
Как?
Long story short: ClassLoader ведет себя интересным образом при попытке загрузить статические поля классов рекурсивно ссылающиеся на классы друг-друга.
Под катом примеры кода и подробное объяснение того, как он обманывает проверки на Nullable. Я искренне надеюсь что специфические знания Java/Kotlin для статьи не нужны - я объясню все детали на ходу, и уложу расследование в 10 минут.
Привет, Хабр! Меня зовут Антон Шкредов, я QA Lead в SuperJob. В День тестировщика хочу поделиться историей о том, как около четырех лет назад мы с командой перешли от ручного тестирования к автоматизации UI и какой профит в итоге получили. Внутри подробности про усталость от ручных тестов, с чего начали автоматизацию, какие инструменты использовали, а также про сложности и бонусы от внедрения.
Если ваш Спектрум пылится на полке, эта статья подскажет, как дать ему вторую жизнь, а вам — новое хобби. Возможно, вы хотели бы встретить вызов: всего лишь ~40кб памяти, включая код программы. Реализовать хорошее приложение крайне затруднительно, так как вы столкнетесь не только с нехваткой памяти, медленным процессором, но и отсутствием нормальной отладки на уровне исходного кода.
С выходом интернет-адаптера Spectranet сообщество активно развивается, и я предлагаю вам почитать о том, как отлаживать Си для проекта, который вышел за уровень демки.
Вам когда-нибудь приходилось отлаживать и работать с кодом зависимых библиотек NuGet или .NET, которые не являются частью вашего решения? Сегодня отладка через них не так проста, как отладка ваших проектов, которые являются частью вашего решения. Начиная с Visual Studio 2022 Preview 3, мы добавляем новый узел «Внешние источники» в обозреватель решений, который значительно упростит отладку файлов внешних источников. Этот узел появляется во время отладки и отображает источники для управляемых модулей с загруженными символами, содержащими информацию о Source Link или Source Server. Вы можете легко просматривать эти исходные файлы и отлаживать их, при необходимости устанавливая точки останова.
Команда Visual Studio 2022 работает над тем, чтобы обеспечить личную и командную продуктивность. Отладка внешних источников - это возможность инструментов диагностики, которая является лишь одной из интересных функций, над которыми мы работаем.
Помехи, слишком большое количество SSID, трафик управления с ограниченным доступом и небольшая ширина канала могут замедлить работу Wi-Fi сетей. Покажем, как устранить эти проблемы.
В процессе переделки игрушки-осциллографа DSO138, как уже описывалось в предыдущей статье, возникла идея в DSO303 попробовать фокус с удвоением частоты дискретизации. В самом деле для STM32F303 теоретически максимально достижимая скорость дискретизации с точки зрения входа АЦП, а это определяется минимальным временем открытия УВХ, которое в нашем случае 1,5 такта х (1 / 72 МГц), или примерно 20,8 наносекунд, что дает 48 MSPS (миллионов отсчетов в секунду). Однако при параллельной работе 4-х АЦП на 6 МГц получается достичь только 24 MSPS из-за ограниченного быстродействия АЦП.
Представим себе, что мы рассматриваем правильно-периодический сигнал, который при этом еще и постоянен, т.е. не испытывает флуктуаций по частоте и амплитуде во времени. Возможно ли как-то оцифровывать его не в один, а в несколько проходов, тем самым увеличив эффективную частоту выборки?
На Али продается за очень недорого интересная игрушка – осциллограф под названием DSO138. Он снискал уже довольно большую популярность среди любителей электроники, но параметры этого приборчика, увы, позволяют его более-менее полноценно использовать только для отладки очень низкочастотных схем. Собственно, он и не позиционируется как инструмент, а скорее, как DIY-kit для начинающих электронщиков.
Собран этот «игрушечный» осциллограф на микроконтроллере STM32F103, и при достаточно грамотном схемотехническом решении цифровой части, наличии довольно приличного цветного дисплея 320Х240 точек, и не самом поганом аналоговом тракте, все, увы, гробится очень слабыми АЦП на борту 32F103. Заявленная полоса в 200 кГц может быть признана таковой только с очень большой натяжкой. Да, наличие или отсутствие сигнала с такой частотой он покажет, но вот реально посмотреть что-то сверх этого не получиться.
При этом есть у 103-й серии чуть более старший брат – STM32F303, по ножкам совместим практически полностью, но по интересующим нас параметрам существенно лучше, на борту 4 АЦП с частотой преобразования 5 МГц (6 МГц с 10-ти битным разрешением). При таком раскладе, если использовать все 4 АЦП параллельно с 10-ти битным разрешением, можно получить временное разрешение до честных 24 MSPS (миллионов отсчетов в секунду). Стоит микроконтроллер тоже недорого, на том же Али можно легко найти за опять же весьма умеренные деньги. Понятно, что идея поменять микроконтроллер возникла практически сразу после того, как я этот самый DSO138 и попробовал.
О том, что получилось в результате, и написана эта статья.
Зачастую разработчику, или даже пользователю, требуется посмотреть, что происходит внутри устройства. Обычно в таких ситуациях используют либо текстовой вывод в терминал (через голый UART или самописный протокол гарантированной доставки), либо пишут свои собственные системы логирования. Однако, всегда ли оправдан такой подход? Есть ли решение проще и производительнее? В данной статье мы рассмотрим одно из таких - библиотеку логирования uP7.