Самое время поставить точку
#frontend #debug #react #nodejs

Каждый современный браузер, даже IE, имеет встроенные средства отладки клиентского JavaScript. У Chrome, например, есть инструменты разработчика, которые позволяют расставлять точки останова, выводить отладочную информацию и в режиме реального времени работать с некоторыми объектами js.

У такой отладки есть минусы — вы отлаживаете уже скомпилированный js, например из EcmaScript или TypeScript. Получается, что код пишется на одном языке, а отлаживается — на другом. Иногда удобно сразу исправлять код в момент отладки.

Наши frontend-разработчики используют IDE Visual Studio Code, в которой есть удобные встроенные средства отладки кода 🐞

VS Code позволяет настраивать различные сценарии отладки — можно отлаживать и серверный, и клиентский js.

Для настройки дебагера в VS Code используется файл ./vscode/launch.json. Чтобы мы могли отлаживать браузерный js, понадобится расширение, сопрягающее работу отладчика с браузерами движка Chrome. Для отладки nodejs-кода будем использовать вот это расширение.

Microsoft создала даже сборник рецептов настройки отладчика для различного типа приложений и языков разработки.
Например, для отладки кода на Next.js можно взять за основу вот эту инструкцию (https://github.com/Microsoft/vscode-recipes/tree/master/Next-js) и отлаживать как клиентскую, так и серверную часть вашего приложения. Не забудьте включить source-maps в настройках сборщиков для Dev-режима, чтобы отладчик показывал исходный, а не транспилированный код.

Старайтесь минимизировать использование механизмов псевдоотладки, типа console.log. Отладка в режиме runtime дает вам полностью объективную, живую картину состояния ваших переменных, объектов и текущего хода выполнения. Вы производите отладку внешними средствами, не изменяя свой код, и спите спокойно, не думая о том, что ваши console.log() проявят себя на промышленном сервере или в браузере у конечного пользователя 🙃

Жучки в моей голове 🐛🐞🐜
#backend #debug #php

Мы не раз писали о способах отладки и профилирования frontend-приложений посредством браузера.

А как же отлаживается backend?🤔 Начинающий php-разработчик предпочитает использовать простые конструкции вывода для отладки данных и структур. Например, такое сочетание крайне часто можно встретить в коде джуниор-разработчика:

    ...
    var_dump($someVar); // print_r($someVar);
    die();
    ...

Лишь бы такая отладка не дошла до прода 😩

Для полноценной отладки и профилирования кода мы используем Xdebug, который поставляется как php-расширение. Современные IDE, например JB PhpStorm, с легкостью интегрируются с этой библиотекой отладки, как в случае с локальным php-интерпретатором, так и в случае если Xdebug установлен в Docker-контейнере. Наши разработчики применяют специально подготовленное Docker-окружение, и поэтому мы используем второй вариант.

Современные php-фреймворки также предоставляют отладочные инструменты уровня приложения. Например, для профилирования SQL-запросов, которые генерирует ORM.

Удобные отладочные панели есть у фреймворков Yii и Laravel. Если вы не используете каркасы, а разрабатываете приложение на разнородных composer-пакетах или на микрофреймворках, то можно применять, например, PHP Debug Bar.

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

Отправка почты кабанчику
#backend #debug #php

При разработке и внедрении веб-сервисов мы постоянно используем нотификацию пользователей посредством email-уведомлений. Регистрация, восстановление забытого пароля, маркетинговые акции — все эти события влекут за собой доставку контента пользователю через почту в виде текстовых или html-писем.

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

Современные фреймворки в debug-режиме позволяют конфигурировать свои компоненты-мейлеры для мнимой отправки писем в файлы. Так, Yii Mailer имеет параметр конфигурации useFileTransport, а Laravel позволяет указывать драйвер отправки.

Для себя мы нашли более удобный способ эмуляции отправки и просмотра email-уведомлений — MailHog. Причем для фреймворка такой сервис настраивается и представляется абсолютно так же, как и реальный внешний SMTP-сервер, правда, без шифрования.

Этот сервис состоит из двух основных частей — SMTP-сервера и HTTP-приложения для просмотра и управления полученными от клиентов письмами. При этом реализовано несколько режимов хранения писем — в оперативной памяти и в файловой системе. Приятным дополнением ко всему является возможность поставки сервиса в окружение Docker и Docker Compose, а значит, интеграция и внедрение в окружение наших разработчиков.