Телеграм-каналы

Останься в памяти моей

#frontend #backend #reactjs #nodejs

Даже опытный react-разработчик может не до конца осознавать, как используется оперативная память компонентами его приложения. Недавно мы обнаружили memory leak в сервисе — через N дней многопоточное приложение на стороне SSR переставало работать из-за нехватки оперативной памяти.

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

Встречается распространенная проблема, при которой react-компонент был размонтирован, но инициализированные в нем setTimeout или setInterval не были остановлены и продолжают выполняться в фоне. Сборщик мусора не будет выполнять очистку памяти от данных, используемых в этих методах, следовательно, происходит систематическая утечка памяти.

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

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

На серверной стороне также возможно настроить мониторинг используемой памяти. Для этого необходимо запустить nodejs с флагом --inspect и открыть в Chrome специальную страницу chrome://inspect. Здесь настраивается интеграция с серверной частью вашего приложения для работы отладочного механизма. Затем процесс работы со снимками памяти сервера и их анализа происходит в таком же интерфейсе, как и в случае с клиентской частью.

Барабаним сами

#mobile_dev #android #kotlin

Хочу такой барабан, как на iPhone

Спорить о юзабилити стандартных элементов управления мобильных ОС можно вечно. Мы не будем.

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

На «Хабре» есть статья, которая рассказывает, как создавать Picker через Canvas. Такой подход имеет ряд недостатков. Например, сложность реализации анимированной плавной прокрутки с ускорениями и необходимость реализации метода onDraw для однотипных, но разных интерфейсов.

Реализуем вариант бесконечного барабана через SnapHelper. Picker будет оперировать списком строк List<String>, который передается в конструктор адаптера для RecyclerView. Количество элементов в этом RecyclerView будет Integer.MAX_VALUE. За счет этого мы добьемся «бесконечной» прокрутки списка.

Для реализации эффекта барабана при прокрутке определим класс SlideLayoutManager. Метод onScrollStateChanged, помимо вызова суперметода, для каждого элемента вычисляет расстояние до центра RecyclerView и возвращает позицию элемента с минимальным расстоянием. Метод scrollVerticallyBy с помощью функции scaleDownView производит корректировку визуальных составляющих элементов, например размера и цвета.

Пример инициализации Picker можно увидеть здесь.

Реализацию XML-разметки picker_item, а также размещение RecyclerView в разметке Layout оставим за кадром этой заметки.

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

Самое время поставить точку

#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() проявят себя на промышленном сервере или в браузере у конечного пользователя 🙃

Сделано в Лаборатории Студии Чулакова

Студия Олега Чулакова

Дизайн-студия № 1 в России по версии Tagline, лучший usability / UX в стране по версии Золотого Сайта.

Специализируется на создании сложных систем и сервисов для крупных компаний. Среди клиентов Студии Tele2, ИКЕА, МегаФон, БКС Банк, Yota и другие крупнейшие российские бренды.