В апреле в Минске прошла большая IT-конференция United Dev Conf, организованная Frontend Dev Conf, Highload Dev Conf и Mobicode.

Нам предложили вдохновится опытом, найти новых друзей и бизнес-партнеров, узнать последние новости и тенденции, и просто насладится общением в кругу единомышленников. Как можно было отказаться от такого предложения? Поэтому мы отправились в столицу нашего северного соседа.

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

Конференция проходила в четыре потока: Frontend, Highload, Mobile и Sales. Её посетили около 700 участников, и 40 докладчиков делились своим опытом. А в перерывах компании-спонсоры разыгрывали квадрокоптеры, куда ж без них на IT-ивенте.

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

День 1

Константин Кривленя, «Непрерывная интеграция для frontend» (слайды)

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

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

Но лучше всего весь процесс сборки и тестирования доверить системам непрерывной интеграции. Это позволить не нагружать рабочую машину и держать все артефакты в одном месте. В докладе были отмечены такие системы, как Travis, Jenkins, Concourse.ci, Circleci и Teamcity. Все они имеют свои достоинства и недостатки. Например, Travis, несмотря на появившуюся матрицу сборок, позволяющую разбить процесс на этапы, всё равно имеет менее читаемые логи, чем Jenkins, но последний имеет куда менее удобный интерфейс.

В заключение Константин отметил достоинства и недостатки использования систем непрерывной интеграции. К положительным аспектам можно отнести:

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

Вместе с тем, CI имеют ряд недостатков:

• Необходимость настройки такой системы, что иногда бывает непростой задачей.
• Не всегда отражает реальную ситуацию; отсутствие ошибок в тестах не гарантирует работоспособность приложения.
• Долгий отклик в больших проектах.
• Нестабильность самой системы; бывают ситуации, когда билд падает по вине билд-агента, а не не пройденного теста.

Денис Радин, «Применяя стандарты кодирования NASA к JavaScript» (слайды)

Доклады Дениса всегда затрагивают интересные темы, и в этот раз он поднял очень интересную, и между тем, важную тему: почему JS-разработчикам не доверяют писать ПО для космических аппаратов и авиации? А также предложил порассуждать, как эту ситуацию исправить.

Докладчик предположил, что в будущем все интерфейсы будут писаться на HTML/CSS/JS, потому что это, на данный момент, лучшая связка для разработки интерфейсов. При этом имеет ряд как преимуществ, так и недостатков. К аргументам «за» можно отнести: доступность по сети, возможность простого обновления и шаринга, надежность и достаточно большой рынок компонентов. Однако существует ряд серьезных недостатков, таких как невысокая производительность, риск утечки памяти и т.д.

Являясь фронтенд-разработчиками, мы бы никогда не захотели летать на самолетах, которые работают под управлением JavaScript. А всё потому, что в нашей работе очень маленькая цена ошибки, что позволяет нам писать менее безопасный и устойчивый код.

Тем не менее, если мы хотим в будущем захватить эту нишу, нам необходимо ввести новые стандарты для написания кода. Денис посмотрел правила, которыми руководствуются в NASA и Jet Propulsion Laboratory, когда программируют свои космические аппараты, и применил их в отношении JS.

1. Одна функция — одно дело. Небольшие функции легче читать, переиспользовать, тестировать и рефакторить.
2. Предсказуемость. «Бросьте писать клевый код, начните писать простой и предсказуемый». Определите стандарты кодирования, используйте анализаторы кода и собирайте метрики.
3. Уважайте ОЗУ. В наши дни SPA-приложения могут работать часами без перезагрузки страницы. Мы должны знать, как работает сборщик мусора, и помогать ему делать свою работу. Также необходимо исследовать приложение на утечки памяти с помощью инструментов разработчика в браузерах.
4. У всех циклов должен быть верхний предел. Это правило сложно интерпретировать для JS-кода, это антипаттерн для нас, мы хотим быть гибкими. Так что скажем, что это плюс в копилку статического анализа.
5. Хорошо тестируйте свое приложение. На одну функцию должно быть минимум 2 теста. Следите и изучайте аномалии в системе, а также меряйте покрытие кода.
6. No shared state. Это может привести к непредсказуемым результатам, что противоречит пункту 2.
7. Проверяйте значение возвращаемых функций. Наиболее пренебрегаемое правило в виду его непрагматичности. Не будем же мы каждый раз проверять, что, например, Math.round вернул действительно целое число.
8. Ограничивайте количество транспилируемого кода. Мы не можем предсказать, какой код генерирует траспилятор, производительность этого кода будет ниже, а также увеличится размер сборки.
9. Уменьшайте связность. Инкапсулируйте логику и состояние, уменьшайте цепочки вызовов.
10. Держите всё зеленым. Тесты, зависимости, сборки. С самого старта проекта.

День 2

James Allardice, «Building a better login with The Credential Management API» (слайды)

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

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

The Credential Management API — это новая ступень в развитии браузерной помощи заполнения форм логина. Он предоставляет две ключевые возможности:

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

Всё это позволяет реализовать на вашем сайте такую последовательность:

• пользователь первый раз успешно логинится на сайте;
• мы сохраняем его данные в хранилище браузера;
• в следующий раз, когда пользователь будет входить в систему, мы проверим, есть ли для него сохраненный пароль и сами его авторизируем, даже не показывая страницы входа.

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

Звучит интересно, но на деле это всё ещё экспериментальный API. Спецификация к нему находится на стадии черновика, что добавляет риск кардинального изменения API, а единственный браузер, который его поддерживает — Google Chrome. Также существует ограничение: работает только с Fetch API.

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