Отладка *

Приветствую, хабраюзер! Эта история началась со странного падения Python приложения. Сначала я не придал внимания данной проблеме: приложение запущено в Openshift и периодически падает. К такому поведению может приводить всякое, например, иногда ноды обновляют, а иногда случаются аварии и тогда одну или несколько нод выводят из эксплуатации. Однако со временем проблема стала регулярной и начала проявляться некоторая закономерность. При этом в Sentry не было каких-либо ошибок. Я был полностью уверен, что это какая-то типовая проблема и ее можно быстро решить, но как же я ошибался.

Привет, Хабр. Хочу поделиться своим решением одной из проблем использования корутин в Kotlin.

Корутины в Kotlin - одна из значимых фич языка, которая позволяет писать асинхронных код в синхронном стиле. Корутины прекрасны во всём, до тех пор пока не возникает необходимость их дебажить.

Правильный процесс ревью кода — это процесс итеративного улучшения продукты и контроля.
Контроля того, что:
1) Cоблюдены общие правила и договорённости
2) Решение не избыточное и масштабируемое.
3) Решение покрывает все критерии приемки указанные в описании к задаче

Для начала будет хорошо задать в своей команды такие вопросы:
1) Сколько времени занимает ревью кода для средней (сферической в вакууме) задачи
2) Как вы минимизируете время ревью?
3) Как вы определяете, что ревью конкретной задачи сделано правильно?

Привет! Я Антон Антонов, Full Stack Developer. Расскажу, что помогает мне исправлять ошибки в коде.

Прошло уже достаточно времени с момента релиза Python версии 3.10. Самым главным и самым ожидаемым было введение оператора match/case (он же pattern matching). 

Однако далеко не всем разработчикам из комьюнити зашел данный оператор. Свидетельствуют этому даже комментарии под статьями на хабре (статья 1, статья 2), которые были посвящены match/case.

На мой взгляд, новый оператор упрощает жизнь разработчикам, принимая на себя работу с проверкой типов данных или принадлежность определенному классу. Но, как мы все знаем, зачастую за крутые фичи, введенные в язык, программисту приходится платить. В данной статье я хотел бы осветить тему производительности оператора match/case и сравнить его с обычным if/else.

Привет, Хабр!

В октябре мы провели онлайн-митап по тестированию, в котором спикеры из Badoo, Skillbox, Почтатех и SuperJob поговорили о своем опыте перехода от ручного тестирования к автоматизации, рассказали о подходах к стабилизации тестов для мобильных приложений и многом другом. Встречу посетили более 600 участников, а QA Lead SuperJob Антон Шкредов получил столько интересных вопросов, что мы решили сделать отдельный пост в блоге. Итогами разбора делимся под катом.

Запись митапа доступна по ссылке, а если смотреть неудобно, то главные тезисы доклада Антона можно почитать на Хабре.

В жизни каждого инженера может произойти ситуация, когда процесс его приложения «завис» и не выполняет ту работу, которую должен. Причины могут быть разные и чтобы узнать их, нужно заглянуть во внутренности процесса и расследовать, что же там происходит. Для этого, можно снять дамп и проанализировать его. Каждый такой случай уникальный, но подходы к анализу дампов — общие. В этой статье я покажу, как расследовал одну из подобных ситуаций и пришёл к неожиданным выводам.

В сети полно обзоров 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

Недавно я проходил собеседование и одним из вопросов, стал такой загадочный экземпляр:
"А какое главное преимущество системы типов 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 сообщество активно развивается, и я предлагаю вам почитать о том, как отлаживать Си для проекта, который вышел за уровень демки.

В процессе переделки игрушки-осциллографа 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 и попробовал.

О том, что получилось в результате, и написана эта статья.