дебажить что это значит

Как дебажить запросы, используя только Spark UI

Егор Матешук (CDO AdTech-компании Квант и преподаватель в OTUS) приглашает Data Engineer’ов принять участие в бесплатном Demo-уроке «Spark 3.0: что нового?». Узнаете, за счет чего Spark 3.0 добивается высокой производительности, а также рассмотрите другие нововведения.

Также приглашаем посмотреть запись трансляции Demo-урока «Написание эффективных пользовательских функций в Spark» и пройти вступительное тестирование по курсу «Экосистема Hadoop, Spark, Hive»!

У вас уже есть все, что вам нужно для дебаггинга запросов

В этой статье я попытаюсь продемонстрировать, как дебажить задачу Spark, используя только Spark UI. Я запущу несколько задач Spark и покажу, как Spark UI отражает выполнение задачи. Также я поделюсь с вами несколькими советами и хитростями.

Вот как выглядит Spark UI.

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

А вот запрос, который запускаю в качестве примера

Перевод разъяснений в правой части:

id = hash(125), count=1000

2. id = hash(124), count=900 …

Я запросил 40 исполнителей для сессии, однако при запуске вы можете увидеть, что он предоставил мне всего 10 активных исполнителей. Это может быть связано с тем, что не работают хосты или Spark не нуждается в таком большом количестве исполнителей. Это также может вызвать задержку в планировании задач, поскольку у вас всего 10 исполнителей, а вам нужно 40, что скажется на параллелизме.

Вкладка Environment

Вкладка Environment содержит подробную информацию обо всех параметрах конфигурации, которые в данный момент использует сессия spark.

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

Вкладка Storage

Но перед этим давайте вернемся немного назад и потратим несколько минут на некоторые основы кэширования.

Есть два способа кэширования Dataframe:

→ df.persist

Для кэширования набора данных требуется несколько свойств.

→ df.cache

Под капотом это вызывает метод «persist». Обратимся к исходному коду

DISK_ONLY: хранить (persist) данные на диске только в сериализованном формате.

MEMORY_ONLY: [хранить данные в памяти только в десериализованном формате.

MEMORY_AND_DISK: хранить данные в памяти, а если памяти недостаточно, вытесненные блоки будут сохранены на диске.

MEMORY_ONLY_SER: этот уровень Spark хранит RDD как сериализованный объект Java (однобайтовый массив на партицию). Это более компактно по сравнению с десериализованными объектами. Но это увеличивает накладные расходы на CPU.

MEMORY_AND_DISK_SER: аналогично MEMORY_ONLY_SER, но с записью на диск, когда данные не помещаются в памяти.

Давайте воспользуемся df.cache в нашем примере и посмотрим, что произойдет

a.cache()

—> На вкладке Storage ничего не видно. Как вы можете догадаться, это из-за ленивого вычисления

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

Так что, когда вы хотите принимаете решение о том, кэшировать или нет, помните об этом.

Далее мы рассмотрим вкладки Jobs и Stages, причины множества проблем можно отдебажить с помощью этих вкладок.

Я вижу, что для указанного выше запроса запускаются 3 задачи. Но 2 из них пропущены. Обычно это означает, что данные были извлечены из кэша и не было необходимости повторно выполнять данный этап. Кроме того, Spark выполняет множество фиктивных задач для оценки данных. Пропуск задач мог быть связан и с этим.

Давайте же глубоко погрузимся в задачу, которая не была пропущена. Это визуализация DAG для задачи

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

Давайте углубимся во вкладку stages.

Вот несколько моментов, которые следует отметить:

→ Продолжительность (duration): В нашем примере минимальная и максимальная продолжительность составляет 0,4 и 4 секунды соответственно. Это может быть связано с несколькими причинами, и мы постараемся отдебажить их в пунктах ниже.

→ Время десериализации задачи (Task deserialization time):

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

→ Задержка планировщика (Scheduler delay): максимальная задержка планировщика составляет 0,4 секунды. Это означает, что одна из задач должна была ждать отправки еще 0,4 секунды. Большое это значение или маленькое, зависит от вашего конкретного юзкейса.

* PROCESSLOCAL → Эта задача будет запущена в том же процессе, что и исходные данные

* NODELOCAL → Эта задача будет запущена на том же компьютере, что и исходные данные

* RACKLOCAL → Эта задача будет запущена в том же блоке, что и исходные данные

* NOPREF (Отображается как ANY) → Эта задача не может быть запущена в том же процессе, что и исходные данные, или это не имеет значения.

Я надеюсь, что эта статья послужит вам в качестве руководства по дебаггингу на Spark UI с целью устранения проблем с производительностью Spark. В Spark 3 есть много дополнительных функций, которые тоже стоит посмотреть.

Вы также можете связаться со мной в Linkedin.

Хотите узнать, как Apache Druid индексирует данные для сверхбыстрых запросов? Узнайте об этом здесь:

Интересно развиваться в данном направлении? Участвуйте в трансляции мастер-класса «Spark 3.0: что нового?» и оцените программу курса «Экосистема Hadoop, Spark, Hive»!

Источник

дебажить

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

Смотреть что такое «дебажить» в других словарях:

Кулхацкер — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия

АПВС — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия

ЕВПОЧЯ — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия

ЕМНИП — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия

ЗОМГ — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия

ЗЫ — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия

Зомг — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия

Интернет-сленг — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия

Компьютерный жаргон — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия

Компьютерный чайник — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия

Источник

«Не баг, а фича» — учимся понимать язык программистов

Понять смысл IT-терминов можно, только узнав, как они употребляются

Программисты говорят на особом языке, в котором полно терминов и сленга. Эта речь не всегда понятна не только обычным людям, далёким от компьютеров, но и начинающим айтишникам — новичкам в разработке.

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

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

Гораздо проще понять, что значит «пичупидо», если знать контекст, в котором употребляются все эти слова. Поэтому попробую объяснить некоторые термины и сленг на примере истории одного программиста (вымышленного).

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

Новая задача

Ваня — обычный джун в веб-студии. Его работа — поддержка бэкенда сайтов старых клиентов студии.

Джуниор ( англ. junior — младший) в данном случае — младший разработчик в веб-студии. Также бывают мидл- ( англ. middle — средний) и сеньор-разработчики ( англ. senior — старший).

Бэкенд или бэк ( англ. back end — задний край) — серверная часть сайта или приложения, которая нужна для обработки и хранения данных. Его противоположность — фронтенд или фронт ( англ. front end — передний край) — видимая часть приложения или сайта. Если же разработчик занимается сразу фронтендом и бэкендом, его называют фуллстек-разработчиком ( англ. full stack — полная куча / полный набор).

Рабочая неделя Вани начинается с митингов, потому что спринт в его компании длится всего неделю.

Митинг — собрание, на котором обсуждается, что успели или не успели сделать сотрудники, а также чем они будут заниматься в новом спринте.

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

Скрам ( англ. scrum) — метод управления проектами. Относится к гибкой методологии разработки эджайл ( англ. agile — гибкий).

На этот раз он получил задачу по добавлению валидации в один из интернет-магазинов. До этого вся валидация была на стороне пользователя.

Валидация — проверка данных, которые вводит пользователь.

До пятницы ещё целая неделя, поэтому с митинга Ваня пошёл сразу в курилку. Достав сигарету, он стал слушать разговор мидла и сеньора:

— Недавно залез в репозиторий, а там одни foobar’ы. Целый час голову ломал, а потом махнул рукой и заново переписал.

— Как наберут новых джунов, так всегда говнокод появляется. Как он вообще код ревью проходит?

— Надо проверить в гитхабе историю коммитов.

Тут Ваня поперхнулся, затушил сигарету и заторопился на рабочее место — от греха подальше.

Репозиторий — хранилище исходных файлов проекта.

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

Говнокод — очень плохой код.

Код ревью — проверка кода.

Гитхаб — сервис для хранения репозиториев IT-проектов и совместной работы над ними.

Коммит — запись изменений в репозиторий. Коммит содержит в себе данные об изменениях, комментарий и имя автора коммита.

У стола его уже ждал тимлид:

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

— Вы уверены, что это из-за меня? Мой код вообще промокодов не касался.

— Уверен. Откати сайт и исправь всё до конца недели — нельзя ждать, пока клиент заметит, что одна из фич пропала.

— Но у меня уже есть задача на эту неделю, я не успею всё исправить.

— Это далеко не первый твой факап, поэтому, если не успеешь, мы поставим новый рекорд — так быстро мы джунов ещё не увольняли.

Тимлид ( англ. team leader — лидер команды) в данном случае — программист, который выполняет роль менеджера. Тимлид редко пишет код, вместо этого он следит, чтобы его команда хорошо справлялась с задачами.

Баг ( англ. bug — жук) — неожиданный результат или неожиданное поведение программы, ошибка.

Откатить ( англ. rollback) — отменить изменения, вернуться к прошлой версии.

Фича ( англ. feature — особенность) — полезная (а иногда забавная) функция / особенность программы.

Исправление багов

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

Дебаг (англ. debug — устранение багов) — исправление ошибок в коде программы.

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

— Прости, но если бы я знал, что не так в твоём коде, я бы твой пул реквест не заапрувил.

— Но ты же написал lgtm в комментарии!

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

— Ладно, разберусь как-нибудь.

Апрув ( англ. approve) — подтвердить что-нибудь.

Пул реквест ( англ. pull request) — запрос на подтверждение коммита.

LGTM ( англ. looks good to me — На мой взгляд, хорошо) — сокращение, которое часто встречается на гитхаб в комментариях к подтверждению коммитов. Обычно его используют, когда не получается сказать ничего конструктивного по поводу кода.

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

Пик Балмера — шуточная теория, что при содержании алкоголя в крови между 0,129 и 0,138% (примерно 2 бутылки пива) программист получает сверхспособности к написанию кода. Теорию выдвинул Стив Балмер, CEO Microsoft с 2000 по 2014 год.

Бессонные ночи и пиво сделали своё дело, поэтому Ваня заснул прямо за компьютером.

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

Ненавидя себя, он поплёлся на работу. Сев за рабочий стол и посмотрев в код, внезапно понял, в чём была ошибка (известно, что многие проблемы в разработке приложений решаются, когда программист спит). Исправив всё за пару минут, он пошёл к тимлиду.

— Я разобрался с багом.

— Отлично, но странно, что у тебя ушло так много времени. Давай протестируем твой код и выгрузим на прод.

Прод или продакшн ( англ. production environment — рабочее окружение) — компьютер (чаще всего сервер), на котором запускается готовое к работе приложение.

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

К счастью, недавно он начал изучать JavaScript, поэтому мог просто скопировать код валидации с фронта и переделать его для бэкенда.

JavaScript — язык фронтенд-разработки.

Помучившись день, он всё-таки закончил. Тимлид оценил усилия:

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

Деплой ( англ. to deploy) — процесс перевода кода в рабочее приложение, чтобы запустить его на каком-нибудь компьютере.

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

По крайней мере на этот спринт.

Заключение

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

Источник

Как дебажить фронтенд и бекенд: пошаговая инструкция

В этом посте мы научимся дебажить JavaScript на фронт- и бекенде с помощью Chrome DevTools и VS Code.

Ловим баги на фронтенде (JavaScript, Angular)

Очень много сервисов сейчас позволяют дебажить код над фронтенде. Chrome DevTools и Firefox Developer Tools среди них самые популярные, но и в других браузерах тоже есть свои тулзы. Мы будем использовать Chrome DevTools для примеров.

Дебажим JavaScript

Откровенно говоря, отладка кода может занимать много времени. Особенно, если использовать такие простые команды как console.log() или window.alert().

Нужно писать, а потом удалять дополнительный код, а иногда эти команды все равно попадают в коммит (даже если вы думали, что все их забрали). А если при этом использовать линты (статические отладчики), то команды console или alert будут подсвечиваться в коде.

И на этом моменте в игру вступает Chrome DevTools, позволяя нам дебажить код без утомительных команд. Среди фишек этой тулзы, редактирование CSS и HTML, тестирование сети и проверка скорости сайта — наши любимые.

Чтобы на практике познакомиться с этой тулзой, давайте создадим простенькую страничку на JavaScript с getData() методом. Этот метод будет просто собирать данные с поля ввода, создавать DOM элемент с dataSpan ID и добавлять значение с поля ввода в этот элемент.

Вот как наша страничка будет выглядеть:

В JavaScript:

Сохраним ее как app.js.

Вот как наша страничка будет выглядеть в браузере:

Чтобы проверить как метод работает до того, как сохранять данные в dataSpan, можно использовать старомодные console.log(data) или window.alert(data). Вот что мы увидим запустив файл в VS Code:

Это самый примитивный подход.

Вместо этого, мы используем брейкпоинты (точки останова) вChrome DevTools чтобы убедиться, что все работает как надо.

Брейкпоинт — это строка кода, на которой мы хотим приостановить прогонку кода, чтобы изучить как он работает (или не работает).

Возвращаясь к примеру, давайте запустим страницу в Google Chrome и сделаем следующее:

Открыв панель инструментов разработчика, давайте приостановим код на брейкпоинте:

Управление интервалами выполнения кода

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

Первая кнопка, Resume script execution () продолжит выполнение кода до конца или до следующего брейкпоинта.

Давайте введем hello world в поле ввода. В строку добавится data = “hello world”. Теперь давайте кликнем на кнопку Step over next function call ().

Выбранная строка с брейкпоинтом будет выполнена и дебаггер выберет следующую. Откройте вкладку Scope чтобы посмотреть значение переменной data. Оно изменилось на “hello world”, которое мы ввели ранее и просто показывает значение нашей переменной на конкретной строке кода. Кликните Step over next function call еще раз чтобы выполнить выбранный метод и перейти на следующую строку.

Если обновить страницу, значение переменной out также обновится в DOM элементе. Чтобы посмотреть значение переменной, можно кликнуть на Expand () слева от нее. Если же еще раз кликнуть Step over next function call, то текст “hello world” еще раз добавится в dataSpan.

Более сложная отладка

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

Для этого мы обновим код app.js как на скриншоте выше. Обновляем страницу и приступаем непосредственно к дебаггингу.

Как еще можно поставить брейкпоинты

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

Для этого в DevTools есть классный инструмент для установки брейкпоинтов на разные типы интеракции с браузером. На панели JavaScript Debugging, кликните Event Listener Breakpoints чтобы посмотреть доступные категории.

Как вы видите, можно поставить брейкпоинт на событие Mouse > click (клик мышкой) в любом месте нашего кода. Это означает, что, если кликнуть Get Input Data, выполнение кода остановится на событии onclick. И не нужно вручную ничего добавлять.

Клик на Step over next function call будет последовательно вести нас через код, используемый чтобы обработать клики.

Используя Event Listener Breakpoints, можно поставить брейкпоинты на кучу разных типов событий, таких как Keyboard, Touch, и XHR.

Ключевое слово “debugger”

Если ввести debugger в любом месте кода, Chrome DevTools приостановит выполнение кода на этой строке и подсветит ее также, как и брейкпоинты. Можно использовать этот инструмент чтобы дебажить JavaScript в Chrome или других браузерах. Только не забудьте удалить его, когда закончите отладку.

Код на скриншоте выше остановится на строке, которая содержит ключевое слово ​debugger и автоматически запустит Chrome DevTools. По сути, это то же самое, что и поставить брейкпоинт на эту строку. Также выполнением кода можно управлять с помощью кнопок ​Step into next function call и Step over next function call.

Выжимка

В начале мы рассмотрели команды console.log() и window.alert() и поняли, что они не слишком удобны. Нужно было их часто использовать по всему коду, что могло сделать код «тяжелее» и медленнее, если бы мы забыли их удалить перед коммитом.

Когда количество строк растет, Chrome Developer Tools намного более эффективен для отлова багов и оценки работы в целом.

Дебажим Angular

Легче всего отладить код Angular — использовать Visual Studio Code (VS Code). Чтобы начать дебаггинг, вам нужно будет установить расширение Debugger для Chrome:

Точно так же, как и в DevTools, кликните на номер строки в app.component.ts. Строка с брейкпоинтом подсветится красным кружком (слева от номера строки).

Настраиваем дебаггер

Для начала, нам нужно будет настроить дебаггер:

1. С File Explorer перейдите на Debug вкладку.
Также можно использовать для этого Ctrl+Shift+D.

2. Кликните на иконку Settings чтобы создать launch.json.
Это файл с настройками, который мы будем использовать.

4. Запустите этот файл.

5. Чтобы использовать этот файл для наших целей, в методе url замените localhost порт с 8080 на 4200.

6. Сохраните изменения.

Вот как должен выглядеть файл:

7. Нажмите F5 или кликните кнопку Start Debugging чтобы запустить Debugger.

8. Запустите Chrome.

9. Чтобы приостановить выполнение кода на брейкпоинте, обновите страницу.

Чтобы последовательно просмотреть выполнение кода и как меняются переменные, используйте клавишу F10.

README

В расширении Debugger для Chrome есть множество дополнительных конфигураций, работа з source maps и устранений всяческих неполадок. Чтобы просмотреть их прямо в VS Code, кликните на расширение и выберите вкладку Details.

Отладка бекенда (Node.js)

Здесь вы узнаете как дебажить код на Node.js. Вот самые распространённые подходы:

• Используя Chrome DevTools
На даный момент, это наш любимый подход.

• Используя IDE-шки типаVisual Studio Code, Visual Studio, WebStorm, и т.д.

Для примеров мы будем использовать VS Code и Chrome DevTools.

Chrome и Node.js используют тот же JavaScript-движок, Google V8, и это значит, что для бекенда мы будем использовать те же инструменты, что и для фронта.

1. Запустите свой проект в VS Code.

2. Перейдите на вкладку Console.

4. Проигнорируйте предлагаемый “chrome-devtools://…” URL (существует метод получше).

5. Запустите Chrome и введите “about:inspect”.

Это перенаправит вас на вкладку Devices на DevTools.

6. Кликните линк Open dedicated DevTools for Node.

Процесс отладки такой же, как и для фронтенда, то есть с использованием брейкпоинтов. На самом деле, очень удобно то, что не нужно переключаться на IDE. Таким образом, можно дебажить и фронт- и бекенд на одном интерфейсе.

Спасибо за чтение и надеемся, что вам понравился этот пост. Подписывайтесь на обновления — у нас в рукавах еще полно полезностей 🙂

Источник