План примерно такй:
- Какие есть способы деплоить фронтенд - базовый пример
- Переходим на микрофронтнеды, но не меняем подход - примеры нашего деплоя в с3, где все катилось разом
- Переводим деплой на независимые пайплайны
- Ускоряем загрузку shell-app микрофронтенднового приложения за счет сбора мета-информации на сервере (На примере формирования меню приложения)
- Как мигрировать с легаси монолита на микрофронтенды
- Сложности, с которыми мы столкнулись после перехода: сложность с локальной отладкой нескольких МКФ, управление ресурсами

Я расскажу о такой частично забытой технологии как SSI (Server Side Includes). Она может помочь компаниям, у которых много легаси, но есть желание попробовать себя в «микрофронтах».
SSI - подход далеко не новый, но открывающий интересные возможности для реализации подобия микросервисной архитектуры. С его помощью можно делать инъекции сервисов на этапе обработки запроса Nginx.
То есть, мы можем сделать сервис на новом стеке со своим деплоем независимо от старого кода.
А в месте, куда сервис должен встать, указать, откуда можно скачать html для инъекции. И так точечно подменять блок за блоком, пока не будем готовы полностью обновить сервис.
В итоге мы получаем ряд преимуществ микрофронтов, при этом не переписывая все, что у нас было до этого.

На старте у нас был монорепозиторий, 6 команд в нем, попытки релизов раз в 2 недели и постоянные блокеры.

Расскажу как мы начали релизить эту монорепу минимум 1 раз в день, какие пути решения пытались использовать, с какими проблемами мы столкнулись при внедрении TBD и как масштабировали этот подход на остальные команды.

Расскажу о том, с помощью каких инструментов профилирования Node.js разработчики в Яндекс Практикуме "положили" графики времени ответа сервера, когда нашли код, который ничего не делал и исполнялся сотни миллисекунд на каждый запрос. На какие грабли наступили и как стали лучше.

Из этого доклада вы узнаете:
- насколько удалось ускорить загрузку страниц и время ответа API в Практикуме
- какие проблемы наблюдались в производительности BFF Практикума
- как профилировать неочевидные проблемы с производительностью в Node.js
- какие результаты профайлинга мы получили и на какую строчку кода вышли
- почему мы не получили весь желаемый результат и как профилировать так, чтобы сразу получить честные данные
- к каким выводам пришли, чтобы не допускать деградации производительности BFF

- что такое селективность?
- зачем она нужна каждому большому проекту?
- какая она бывает?
- как строить селективность в монолите и монорепозиториях?
- с какими проблемами вы непременно столкнётесь?

Из года в год на конференциях рассказывают, интересные доклады на тему blue&green. Но проблема в том, что в небольших компаниях нет отдельного ресурса devOps(frontOps), который сделает front-end разработчика счастливым. К тому же, не всегда понятно, что мы хотим. Предлагаю начать с малого и сделать «всё» самим. Пошагово посмотрим, один из вариантов запуска blue&green на базе nginx+docker и разберем нужно ли оно маленьким проектам.

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

Разберёмся, кто такой FrontOps. Проследим за изменением стека инструментов для деплоя, по мере усложнения проекта. Посмотрим несколько примеров. Обсудим преимущества и недостатки FrontOps.

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

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

Из этого доклада вы узнаете:
* как раньше у нас была устроена разработка и доставка;
* какие возникли риски, как мы все отрубали, как и на что переезжали;
* как мы закрыли Nexus от интернета и придумали способ обновлять пакеты. Какие тулзы пришлось написать для этого;
* как встраивали в CI-процесс автообновления с проверкой безопасности;
* какие смотрели варианты для целевого решения;
* почему выбрали Dependency Track;
* как внедряли Dependency Track, какие были трудности;
* какие получили итоговые результаты.

«Я вам говорю, что каждый раз делаю форму проверки логина и пароля заново! Или не делаю, но никогда не слышал про OAuth. Или слышал, но ничего не понял и предпочёл бы никогда больше об этом не слышать!»

Если что-то из вышеперечисленного — про вас, то именно ваши мучения мы попробуем облегчить. Мы покажем туманную и запутанную спецификацию OAuth 2.0 в виде наглядных и простых историй, чтобы теперь даже в три часа ночи, проснувшись, вы без запинки рассказали, как работает Single Sign-On и как можно сэкономить усилия на реализации функций входа в систему и проверки полномочий. Коварный взломщик в ходе выступления будет несколько раз пытаться проникнуть в наше приложение, а мы будем последовательно применять лучшие практики, чтобы сорвать его планы, повысить защищенность, а также ускорить разработку.

Поговорим про ускользающий Access Token и освежающий Refresh Token, про таинственно закодированный JWT. И про полные сценарии аутентификации и авторизации! Акцент сделаем на том, что близко именно вам, дорогие фронтенд-разработчики.

Защищай и властвуй!

Я часто слышу рассуждения разных компаний на тему «А нужен ли нам архитектор?». В докладе я предлагаю разобраться с этим вопросом и рассказать, какие бывают роли и задачи у архитекторов, как на позицию повлияло появление agile, каким продуктам архитектор необходим, а где можно обойтись без него.

За 7 лет коммерческой разработки приложений, я успел поработать с множеством разных фреймворков и даже без оных. Knockout, Ember, Angular, React, Vue, Web Components - у каждого из этого списка, есть свое представление о том, как должно выглядеть архитектура фронтенд приложения. Мне очень нравится как к архитектуре подходит Ember и Angular, но популярнее всего у нас React. И мне категорически не нравятся те предложения, что предлагает React комьюнити.
Поэтому для своего очередного проекта, я взял и привнес подходы Angular в построении приложений, в React. Спойлер: получилось очень удобно, просто и масштабируемо.
В докладе покажу как это выглядит на реальном проекте, и проведу примеры сравнения с другими подходами.

Мы поговорим об основных подходах к аутентификации в SPA приложениях, рассмотрим популярные ошибки безопасности при использовании JWT токенов, затронем рекомендации OWASP и проблему библиотек которые пытаются дать готовый инструмент.

Берем большой проект и нещадно его рефакторим, с заботой о DX.
Не боимся обновлять по 4 мажорные версии пакета за раз, я покажу, как это делать
Поделимся нашим опытом, проблемами, которые решили и которые не решили.

* Рефакторинг как поход в спортзал: тяжело и мучительно, но результат того стоит

Система, которую мы разрабатываем, является business critical системой. Любой сбой в работе нашей системы приводит к прерыванию бизнеса. Соответственно, бизнес несет финансовые потери. Поэтому команде разработчиков необходимо максимально оперативно откликаться на сбой в системе и иметь возможность быстро вносить правки в код и поставлять их на продуктив.
Микрофронтовая архитектура приложения очень привлекла нас, так как подходила под наши требования. Продукт, который мы разрабатываем, на продуктиве уже более 3х лет.
В докладе расскажу о нашем опыте построения архитектуры приложения. Покажу, как делили монолит на микрофронты, используя SPA-композицию, как интегрировали веб-компоненты в сторонние системы.
Также будет рассмотрена технология Shadow DOM. Покажу, как она нам помогла и какие ограничения внесла.
Рассмотрим тему сборки, вынос общих зависимостей, а также с какими проблемами столкнулись и их преодолевали.

Backend driven UI

Зачем?
- Снижение Time to Market (обновляем страницу без пулл реквестов и деплоев)
- Инверсия зависимостей (пусть бизнес сам решает свои задачи)

Как?
Представление страниц в виде абстрактной структуры данных
- Почему не HTML? (сложно редактировать, много лишнего и не хватает бизнес-логики)
- Кроссплатформенность (создаём платформо-независимый формат и рендерим во что захотим)
- Простота редактирования (как спроектировать структуру данных под свои задачи)

Документация
- jsdoc
- автогенерация документации
- json schema

Эксперты сферы EdTech редко рассказывают о том, как устроена образовательная платформа, как в ней работают процессы. Нам в Нетологии есть что рассказать, мы — старейший edtech на рынке, у нас накопился большой опыт.

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

Около года назад вся разработка компании больно и быстро перешла из аутсорса в инхаус. Я пришел на все это frontend-тимлидом. Как быть с легаси-проектом? Как его стабилизировать? Как привести в порядок? Как удешевить его обслуживание и разработку? И все это без какой-либо документации.

План доклада:

- Предыстория. Как все диджитал-продукты компании были в аутсорсе (и я был его частью - поэтому расскажу как там все было устроено), а потом произошел резкий переход в инхаус (и я стал его частью). Как пишутся проекты в аутсорсе, поток задач, стандарты, структура проекта.
- Из-за чего были выбраны в аутсорсе определенные стандарты и почему? Почему шаблоны проектов на старой версии node js и nextjs? Как с этим бороться.
- Переход в инхаус. Почему возникли проблемы? Нехватка компетенций и отсутствие команды, которая умеет с этими технологиями работать.
- Что предпринималось для улучшения ситуации. Внедрение новых стандартов, проверок, глобальный мониторинг и вследствие рефакторинг “самописных” альфа версий библиотек 1812 года. Разделение монорепы lerna + yarn workspaces.
- Планы. Параллельная разработка фич на новых репах совместно с новыми проектами с обновленными библиотеками.

Нужны ли алгоритмы во frontend?
Конечно нужны, их спрашивают на собеседованиях. А еще?
Многие уверены в том, что на этом всё и заканчивается.
Алгоритмы для computer science, или backend, но для frontend они не пригодятся.
Но так ли это на самом деле?
Я решил во что бы то ни стало найти применение своим знаниям в повседневной работе.
Я приведу примеры, где стоит, а где всё-таки не стоит, использовать алгоритмы и как это повлияет на ваши проекты.
Покажу что именно фронтендеру важно заботится как о производительности, так и о потреблении памяти.
Покажу что разобраться в алгоритмах не так уж сложно, а полученный навык поднимет вас на новый уровень.

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

Сегодня хочется рассказать о нашем опыте в разработке крупной, высоконагруженной, работающей по всей стране CRM-системе с использованием технологии микрофронтов. Мы использовали микрофронты не как независимые блоки, а как небольшие строительные кирпичики. В ходе разработки мы искали баланс между принципами слабой связанности и необходимостью организовать множественные взаимодействия между микрофронтами, выработали правила, чтобы эти взаимодействия не приводили к утечкам памяти, научились тестировать отдельные «кусочки» приложения, и сборку в целом.

Итоговая архитектура выдержала «проверку продуктивом», успешно запущена, функционирует и продолжает активно развиваться.

Frontend приложение как DLL:
* библиотека несвязанных рендер методов и компонентов: только бизнес функционал
* оркестратор приложения - обработчик метаданных: один раз написал и пользуйся
* перемешивание данных и метаданных: как обогнать аналитику и тестирование
* feature toggles на лету: стабильность и динамика одновременно

Если в проекте более 1го человека, скорее всего они по-разному понимают хороший практики и у них разное видение целевой архитектуры приложения. Для решения этой проблемы существуют разные практики для создания единого видения целевой архитектуры.

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

Настраиваем общее рабочее пространство для нескольких независимых команд,
которая разрабатывает одно веб-приложение, с заботой о DX.
Поделимся нашим опытом, проблемами, которые решили.

* Даже если знаешь про микрофронты, их больно внедрять, приходи, дам обезболивающее

В докладе рассказано об опыте разработки браузерной игры со стороны Frontend. Рассматриваются вопросы по построению архитектуры для такого приложения, особенности реализации игровой части (визуальная кастомизация элементов, анимации, переходы). Также в докладе будут затронуты вопросы, которые касаются реализации таких требований, как удобный интерфейс пользователя, гибкая и расширяемая слоистая архитектура FrontEnd приложения, кэширование данных, загрузка и обновление данных из различных источников (HTTP/LocalStorage/Sockets). Также приводится большое количество практических примеров, которые дают понимание о том, как именно реализована архитектура и каким образом поддерживается выполнение указанных требований.

1. Что следует понимать под архитектурой фронтенд-приложения
2. Почему нами была выбрана именно Чистая архитектура для фронтенда. Рассмотрим ее преимущества и недостатками
3. Рассмотрим проблемы модуля рабочего проекта, в котором отсутствует архитектура на примере кода и схемы взаимодействия между слоями приложения
4. Внедрение Чистой архитектуры на примере рабочего проекта. Примеры кода "до/после" и с обновленной схемой взаимодействия между слоями приложения
5. Демонстрация примера с добавлением новой фичи в существующую архитектуру в сравнении "было/стало" на примере рабочего проекта и написание тестов
6. Преимущества, которые получил бизнес и разработчики после внедрения Чистой архитектуры в проект

Пройдёмся от зарождения идеи отказа от стандартного монолита, до построения и организации микрофронтендной архитектуры. Настоящий, живой опыт, где было совершено в кратчайшие сроки плавное исправление ошибки при работе со Stencil.js, переход от основного инструмента Vue и его окружения в пользу React, сборка собственных пакетных решений начиная от своего uikit, заканчивая единой точкой общения клиентской части с сервером.

Основные части доклада включают:
"Возможность работать на production зоне, не покидая локальную разработку",
"Построение микрофронтендной архитектуры, которая позволяет избежать зависимости от инструмента разработки",
"Организация собственных пакетных решений для упрощения существования продукта"

TBD

Многие вещи на JS можно запрограммировать 100 и 1 способом. Некоторые варианты лучше по производительности, некоторые удобнее в поддержке, некоторые просто красивые. Что выбрать? Говорить про это можно бесконечно и часто нет однозначного ответа. В докладе разберём несколько интересных примеров и вариантов их переписать.

Недавно я делал доклад на тему микрофронтовой архитектуры с использованием Single SPA. Как вы думаете, какой вопрос был самым популярным?

Их было два!
Первый - «Почему не Module Federation»?
Второй - «Чем Single SPA отличается от MF»?

Признаюсь, на тот момент я знал о MF крайне мало. Поэтому ответил, что когда мы выстраивали архитектуру, MF еще не было, да и в целом Single SPA нас полностью устраивает.

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

В докладе мы разберем ключевые моменты при работе с микрофронтами:

- Использование разных фреймворков в одном приложении;
- Расшаривание данных между приложениями;
- Дублирование зависимостей
- Обработка крайних случаев

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

После двух лет использования подходов предметно-ориентированного проектирования во фронтенде, поделимся опытом и расскажем
1. Какие могут быть сложности с использованием DDD
2. Обязательно ли применять все практики DDD
3. Как развивать архитектуру дальше и что будет, если этого не делать
4. Какие альтернативы у нас были
5. Как мы собираемся развивать и поддерживать это направление дальше

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

- Разберемся какие метрики производительности существуют
- Как их правильно собирать чтобы видеть реальную картину
- Как мы можем влиять на эти метрики
- Посмотрим как браузер отрисовывает страницу и что может ему в этом мешать
- На примере мобильной версии ВКонтакте пройдем путь от 8 секунд на отрисовку страницы до 2.5 секунд
- Разберем все техники которые мы применяли и увидим их влияние на реальных графиках
- Разберем принципальную схему улучшения производительности сатйа, которая применима абсолютно к любому проекту независимо от его сложности
- Посмотрим как влияют оптимизации произовительности на бизнес метрики

Профиты Backend-Driven UI и его ограничения
Сложные для реализации места: типизация в контракте, валидация, экшны, встраивание микрофронтендов
Что нужно было учесть на начальном этапе работы над проектом, чтобы не сойти с ума

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

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

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

Взаимодополнений двух устройств, которые есть всегда под рукой – телефона и компьютера.

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

WebGL — это невероятный инструмент для создания интерактивных 3D-графических приложений в браузере. Хочу поделиться опытом внедрения и изучения новой технологии, от того, где мы были в начале пути, до готового решения, от рисовки сцены силами frontend разработчиков, до перехода на использование glTF - как JPEG от мира 3D.

Any developer tool's success and adoption depend on its ability to deliver an exceptional developer experience. This talk will concentrate on methods for enhancing the developer experience when developing developer tools, making sure that your solution not only properly addresses the goal issue but also thrills users with its simplicity and seamless integration.

We'll look at crucial components of a great developer experience, such as transparent documentation, user-friendly APIs, and effective error handling methods. We'll also talk about how important it is to interact with the developer community to get input, iterate, enhance your tool, and build trust. 

By the end of this talk, you should be able to build developer tools that stands out and can easily be used by developers.

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

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

Отдельно рассмотрим внедрение микросервисов и дизайн-системы. Расскажу, как эти решения помогли нам на поздних этапах — при изменении архитектуры и внедрении API-gateway.

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

В каждой более-менее крупной IT-компании существует своя культура кода, видение и стайлгайды. Всё это в долгосрочной перспективе можно формализовать в виде внутренних NPM-пакетов, чтобы ускорить старт новых проектов и упростить поддержку существующих. Но, если с недостаточной ответственностью отнестись к DX, то общий пакет может создать дополнительные проблемы и ещё сильнее усложнить жизнь коллегам выяснением, почему же именно в их проекте всё сломалось. Чтобы не наступать на грабли, можно обратиться к опенсорсным проектам и позаимствовать инфраструктурные решения у них.

Расширение границ фронтенд-разработчиков: от создания сайтов и интерфейсов до интеграции с CLI других программ и разработки десктоп приложений.

Фронтендер может создавать полноценные настольные приложения.

Современный кроссплатформенный софт делают на JS: VS Code, Figma и пр.

Фронтендер - это Software Engineer.

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

Когда вы последний раз гуглили топ? Например лучших фильмов последних лет, самые красивые города для путешествий, топ IT компаний?

Кажется вроде бы элементарно, что такие проекты как react или angular должны занимать топ github js star, но это совсем не так

Что самое популярное, что самое комментируемое, что поддерживаемое?

Поговорим о важном и рассмотрим PWA как бизнес фичу:
- Как продать бизнесу PWA?
- А если продали, то как грамотно внедрять?

Система удаленного вызова процедур gRPC — новый виток технологии RPC, который считается альтернативой REST API. Но если с REST API все понятно — этот подход уже давно применяют, а его встроенная поддержка есть в большинстве сторонних инструментов, — то с gRPC все не так однозначно. Несмотря на все преимущества, у gRPC есть свои подводные камни, из-за которых многие разработчики не спешат к ней обращаться.

Я решил на собственном опыте выяснить, как gRPC покажет себя в JavaScript, и разработал прототип веб-приложения для интернет-магазина. Что из этого вышло, расскажу в докладе.

Начнем с введения в gRPC и поговорим про ее основные преимущества, а затем перейдем к прототипу. Покажу, как создать простой gRPC-сервер и клиент на Next.js и что будет, если применить протоколы, в основе которых лежит стриминг. Подробно рассмотрим Protocol Buffers 3 и то, как быть с отсутствием полноценной поддержки HTTP/2 в браузере. Также поделюсь рекомендациями по использованию gRPC в Node.js.

Изначально, DOM в браузере задумывался для объектного отображения HTML. При этом, так как можно было лишь сменить страницу целиком, DOM не проектировался под возможности динамического изменения. Однако веб активно изменяется, растет, и чтобы как-то нивелировать проблему просадки производительности, разработчики фреймворков стали придумывать свои обвязки, кто во что горазд.
В своем докладе я расскажу про VirtualDom и почему он морально устарел, про его аналоги Glimmer, Incremental Dom и про то, как фреймворки достигают производительного рендеринга вообще без "anywordDom".

- обзор техник композиции приложений
- композиция на стороне клиента
- Паттерны коммуникации
- Проблемы маршрутизации на стороне клиента и как их решить
- Методики оптимизации
- Наш опыт применения технологий микрофронтенда в UZUM

Фронтенд - это не только про пользовательские интерфейсы. Современные технологии и Web API позволяют использовать 2D- и 3D-графику, VR / AR, а также заниматься машинным обучением, компьютерным зрением и решать другие сложные инженерные задачи. Расскажу о фреймворке MediaPipe для машинного обучения, рассмотрим какие модели входят в его состав, и разберем реализацию приложения с применением модели распознавания ключевых точек человеческого лица – напишем игру по мотивам Fruit Ninja, в которой можно управлять клинком движением головы!

1. Знакомство, пару слов о себе
2. Введение для тех, кто не знаком с flutter
3. Некоторые приколы flutter и dart
4. Архитектура flutter приложений
5. Сопровождение и мониторинг кода

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

Коротко о главном:
• Streaming SSR
• Server Components
• Suspense
• Селективная гидратация

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

В своем докладе я расскажу о нашем опыте разработки транспортных продуктов в компании Островок. Я объясню, почему мы выбрали Git-сабмодули вместо монорепозитория и как мы переиспользуем общие компоненты и модули транспортных продуктов в разных проектах и командах с их помощью.

Мы также рассмотрим технические детали работы Git-сабмодулей, их плюсы и минусы, и, кроме того, попробуем сравнить этот подход с его альтернативами.

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

Да, совсем без сервера. Да, мгновенное внесение изменений. Да, с оффлайн авторизацией. Да, с синхронизацией в реальном времени. Да, слияние без конфликтов. Да, криптосеть. Нет, не блокчейн.
Небольшой тизер: https://www.youtube.com/watch?v=0WaqDPzwd48

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

С тех пор, как одному DOM-элементу стало возможно добавить несколько CSS-классов, веб-разработчики ищут способы изолировать стили, избавиться от наследования, закрыть CSS-свойства в закрытую коробочку. БЭМ, Atomic CSS, OOCSS, Shadow DOM, CSS-in-JS, Styled Components — скорее всего на вашем сайте есть что-то из этого списка. Почему до сих пор проблему не решили на уровне самого CSS? Или всё-таки решили?

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

В своем докладе я расскажу о том, как микрофронты решают бизнес проблемы и как повышают time to market бизнес фич, что все остаются в плюсе.

Сотни зависимостей в package.json стали для нас обыденной нормой, они важны и необходимы для нас в разработке, без них не мыслимы продуктовые проекты, качественная кодовая база и удобная командная работа. Но так ли это на самом деле, не стали ли мы рабами этих зависимостей, ведь когда-то наши проекты состояли из 1-2 подключенных скриптовых фалов? Посмотрим вырос ли API за все это время на столько, что бы мы могли использовать только Vanilla JS, не потеряв тот комфорт к которому привыкли?

best practices при использовании опциональных полей (?:) и optional chaining (?.) в TypeScript

Представьте, что у вас стоит задача в минимальные сроки сделать приложение на Android практически полностью без знаний Android.

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

Что интересного в докладе:
— Kotlin и Jetpack Compose очень похожи на Typescript и React. Вместе сравним, когда выгодно использовать для мобильной разработки именно их, а не Dart и Flutter или Typescript и React Native.
— Поговорим про нативность кода, которая открывает доступ ко всему Android API.
— В рамках мини мастер-класса поделюсь опытом и покажу основные моменты — как сделать приложение на Android.

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

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

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

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

- Что такое wireframing, и когда можно работать без дизайнера, а также подводные камни и рецепты по их обходу
- Everything-as-code, когда полезно (infrastructure-as-code, diagrams-as-code, docs-as-code)
- Конкретно, как ImagineUI решает задачу сбора и передачи требований в разработку, сочетая мощь двух подходов выше
- Кейсы с генерацией макетов из OpenAPI 3, набросков через ChatGPT и т.д.
- Как интегрировать ImagineUI в свой процесс (с любым стеком, от Foliant до Confluence, в любой конфигурации команды)

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

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

Практика парного программирования появилась более 20 лет назад в рамках Extreme Programming. Считается, что работа в паре более эффективна, чем обособленная работа двух разработчиков. Но если это так, почему про парное программирование очень много разговоров и очень мало примеров применения?

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

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

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

Личностное развитие
Развитие хард скилов
Как круг общения влияет на наше развитие

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

Современные SPA приложения и cпецифичность маркетинга для них
SEO для SPA
тесное взаимодействие с дизайнерами и копирайтерами
чек-лист на структуру отображения для разработчика
Кейс "Смешаем SSR + SPA"
Антикейс
Воронки продаж в приложениях

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

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

Основываясь на этих инсайтах, мы перевернули систему собеседований и найма в JS стриме Kaspersky. Теперь найм может занимать всего 3-5 дней, а кандидат посмотреть все понравившиеся нанимающие проекты.

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

* Повторяем очевидное: зачем нужны ТЗ и можно ли без них
* «Хорошее» и «плохое» ТЗ. Основные виды ТЗ и их отличия
* Макеты, мокапы и прототипы. Figma, Pixso и другие инструменты
* Проектирование API. Принцип «API first». Стандарт REST
* Описание логики работы. UML и BPMN
* Оценка сроков и планирование на основе ТЗ

Принцип T-shape становится все популярнее, но не все до сих пор видят его плюсы. В докладе я поделюсь, как T-shape помогает мне успешно разрабатывать и выпускать продукты. Расскажу, что же именно дает T-shape и вовлеченность в свою команду и продукт. Также обсудим, какие качества важны для T-shape и как их развивать.

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

Когда есть несколько команд разработки, несколько связанных друг с другом проектов, то неизбежно возникает вопрос их взаимодействия. Необходимо, чтобы это было безболезненно, прозрачно и занимало как можно меньше времени. Использование API First подхода и контракта на основе OpenAPI схем решило для нас эту проблему. В этом докладе мы ответим на вопросы: как построить процесс взаимодействия между командами? Как пилить фичи в 2 раза быстрее? Как программировать фронтенду при отсутствии бекенда? Как приготовить E2E тесты, когда бекенда ещё нет? Как организовать работу с deprecated полями?

Вот бы сделать своё собственное приложение! Для меня это как размышления про первый бизнес у начинающего предпринимателя. Какое направление выбрать? Как найти время? А вдруг ничего не получится? Сомнений в голове больше, чем посылок в грузовике почты России. Выход, как и в бизнесе, только один – бери и делай! Так прошлым летом появился “Фима” – мой собственный сервис для планирования бюджета. Прошёл год, первый грузовик сомнений разгружен, а накопленный опыт создания пет-проекта и гайд для повторения сконцентрированы в 40 минутах доклада.

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

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

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

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

Если вы хотите подступиться к микрофронтам и самостоятельно спроектировать архитектуру приложения с полным пониманием дела — вам нужна не просто инструкция "как", но и ответ на вопрос "а почему так и можно ли по-другому?".

В основе микрофронтов так или иначе всегда лежат одинаковые принципы, которых совсем немного.

На мастер-классе я в первую очередь покажу, какими вопросами к ядру стоит озадачиться и как на них можно ответить, какие базовые задачи ставятся перед микрофронтовой архитектурой и как решаются, а после мы в реальном времени соберем микрофронтовое приложение с нуля, имея на руках только ванильный JS без всяких Module Federation (ну, для удобства возьмем еще webpack и react, но только для удобства).

Задача простая - как можно дешевле проверить бизнес идею, которую не стыдно будет показать потенциальным пользователям. При этом это должен быть не колхоз на коленке, а проект на самом острие технологий, готовый к быстрому масштабированию. В качестве идеи возьмём что-нибудь амбициозное. Например, сделаем свой offline-first optimistic-ui decentralized localized crypto Twitter with theming support.

1. Weak Reference and Finalization Registry in real life.
2. Increase the speed of applications by reducing unnecessary calculations and network requests.
3. Weak cache in JavaScript.

Я работаю фронтенд-разработчиком в Почтатехе — ИТ-дочке Почты России. У нас больше 120 команд, которые создают различные сервисы и приложения для Почты, и несколько дизайн-систем — для веба и мобилки. В качестве основного графического редактора мы, как и многие, используем Figma и постоянно стремимся оптимизировать свою работу с этим инструментом. В докладе я поделюсь нашими наработками и лайфхаками.

Для дизайнеров расскажу про кастомные hot key, новый функционал в прототипировании, крайне полезные, но не очень известные плагины для ускорения работы. С разработчиками рассмотрим, как эффективнее работать с API, токенами цветов, отступами и шрифтами. А еще расскажу, как мы подружили библиотеку иконок в Figma с дизайн-системой на React.

Фронтендеры как и любые другие разрабы любят делать пет-проекты - попробывать новые технолог, которые выбиваются из основного рабочего стека… А сколько ваших пет-проектов доехало до прода?

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

Я расскажу о своих инсайтах, которые кажутся очевидными, но мы не всегда им следуем, и именно по этому большинству наших пет-проектов уготована судьба остаться папкой на рабочем столе с настроенным линтером.

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

В жизни каждого разработчика наступает тот самый момент "X"...
... Когда его зовут на встречу с клиентом, заказчиком, партнером или просто с соседней командой.
Я помню эти первые звонки – ты сидишь и боишься, что угодно сказать. Нет понимания, что говорить можно, а что нельзя, и зачем я тут, тимлид же сам все знает. Так зачем я тут?

Доклад – это вагон и маленькая тележка советов, фишек и историй о том:
- как вести переговоры,
- как лучше защищать интересы компании,
- как добиваться более комфортных сроков у задач;

Расскажу о том, как в Контуре развивается цифровая доступность — от маленького комьюнити до внедрения доступности в процесс разработки некоторых продуктов:
— как мы начали делать робкие шаги в доступность и создали «кружок» из нескольких человек

— как мы мотивируем заниматься доступностью себя и других. Расскажу про самые распространенные сомнения: доступность только для людей с инвалидностью, а в бизнесе их вообще нет, а еще денег на доступности не заработать. Учтём нюансы Контура: у нас около 70 продуктов и команд разработки, мы делаем продукты для бизнеса, а еще у нас фронтендеры, которые мало знают про доступность

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

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

Почему выбираем работу а не любимое дело?
Что мешает сменить род деятельности?
Как получить шанс и не потерять его?
Как стать middle и расти дальше?
Почему если нет code revie надо бежать?

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

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

Откуда берется амбициозность и бывает ли у нее здоровая природа?

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

Найм джуниор-разработчиков зачастую болезненный: откликов много, а толковых из них – считанные проценты.
Из-за малого опыта многому приходится учить, при этом высоки риски расставания еще на испытательном сроке – и все надо начинать сначала.
Мы достигли конверсии 60% из нанятого джуна в прошедшего ИС, а из всех нанятых джунов за это время от нас ушли 7%.
В докладе поделюсь, как мы собеседуем, на что обращаем внимание и, самое важное – как строим онбординг и зачем в него вкладываться мидл-разработчику.

Помимо разработки веб-приложений Javascript активно используется в моушен-дизайне.

Статичная анимация:
- After Effects
- Как знания школьной геометрии помогают при программировании анимации
- Lottie
- Data-driven видео

Интерактивная анимация:
- Конечные автоматы
- Генеративная графика
- Математический подход к решению задач

Рассмотрим следующие вопросы:
- Когда нужно уделять внимание текстам в интерфейсе, а когда и так сойдет.
- Кто может писать интерфейсные тексты, а кто должен.
- В какой момент лучше подключаться к написанию текстов.

Поделюсь опытом реализации и внедрения своей дизайн-системы. Расскажу как мы выстроили эффективную коммуникацию между командами разработки и дизайна.

— С чего начать создание дизайн-системы для 30+ услуг и продуктов;
— Как убедить руководство выделить ресурсы на реализацию дизайн-системы;
— Синхронизация работы команды проектировщиков и команды разработчиков;
— Поддержка духа команды в трудные времена (просроченные дедлайны и ковид).

Расскажу, как синхронизировать дизайн и код в проекте, над которым одновременно работает много дизайнеров и разработчиков. На примере VKUI — дизайн-системы и библиотеки React-компонентов ВКонтакте — рассмотрим типичные проблемы взаимодействия дизайна и разработки, пути их решения и влияние эффективной синхронизации на продуктовые результаты.

Часто макеты просто вводят в заблуждение и кажется, что сверстать интерфейс идеально просто невозможно. Нужно ли строго следовать макету или постараться улучшить сайт в дальнейшей поддержке. Ищем баланс и повышаем качество.

— Почему шутки в дизайне — это полезно
— Как юмор влияет на пользовательский опыт
— Правильно подбираем дозировку
— Как мы встраиваем шутки в дизайн
— Что делать, если получилось не смешно

Последние пару лет веб-платформа стремительно развивается. То, что еще совсем недавно казалось нереализуемым или реализуемым только при помощи JavaScript, сегодня становится реальностью в HTML и CSS.

В докладе рассмотрим нововведения в HTML и CSS, позволяющие сделать веб-интерфейсы гибче, DX приятней, а размер бандлов меньше.

Раньше в нашей компании на создание лендингов тратилась неделя работы дизайнеров и неделя разработки, а на последующие правки - 3–4 часа разработки и тестирования в неделю. Не было единого стиля оформления, всё делалось вручную, а фронтенд-разработчики были постоянно в аврале.
Однажды я вместе с дизайнером, с которым мы в паре делали лендинги, за 3 недели создал MVP конструктора страниц, который мы развиваем больше 6 лет и который позволяет собирать страницы продуктов без участия разработчиков за считанные часы.

1. Скроллим не только лишь вниз
Привязываем прокрутку к движению камеры в 3D-сценах, движениям персонажей и другие нестандартные варианты скроллинга

2. Свет: запечь и смешать
Динамическое освещение без освещения. Делаем эффект смены времени суток

3. Параллакс недорого, быстро, надёжно
Учимся делать 3D-эффекты из обычной фотографии по детским книжкам

4. Интерактивные точки интереса для трехмерных сцен
Учим курсор не теряться в 3D-сценах

5. Клоны, оптимизация и Geometry Instancing
Получаем КМС по оптимизации 3D в вебе и разбираемся с типами шейдеров.

Микро-Фронтенды? Уже заезженно. Метапрограммирование? О да!!!

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

В высокий сезон ежедневно через Почту России проходит 1,5 млн посылок. Чтобы доставлять такой объем в срок, логистика, сортировка и обмен данными между внешними и внутренними системами должны работать как часы.

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

Я работаю фронтенд-разработчиком в Почтатехе — ИТ-дочке Почты России. В докладе на примерах из практики моей команды разберем, какие проблемы возникают при подключении физических сканеров к React. Рассмотрим нативное подключение, использование API: Encoding API, Web Bluetooth API. Посмотрим на расшифровку данных при сканировании штрихкодов Datamatrix, UPC Code. Разберем, какие проблемы возникают при сканировании Datamatrix — например, с кодировкой или добавлением новых символов при физическом сканировании. Выясним, что такое ВПС / IPC / UPU / IATA и какую роль играет в доставке.

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

Мы расскажем вам историю про то, как мы не только добавили несколько тем в приложение, но и разработали универсальную библиотеку темизации, которую будем переиспользовать в будущих проектах.

Что российские ГОСТы говорят про темизацию? Как сделать тему переиспользуемым продуктом, который можно передавать другим командам? Какие тайные знания о CSS-переменных следует освоить, чтобы превратить темизацию из мучения в приятное занятие? Какие сценарии появления тем могут встретиться вам на практике?

Все мы хотим сделать классный и красивый продукт, который будет удобен для пользователя. Но иногда наступает время, когда действующий продукт может визуально устареть. Я хочу рассказать о своем опыте перевода действующего продукта ГПБ на новую дизайн-систему и как не скатиться от "просто переходим на новую дизайн-систему" до полной переписи приложения.

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

Что делать, если хочется использовать красивый селект?

Правильно - пилить кастомный.

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

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

In the presentation, we will look at real-world examples of how AI-driven design has been used to create more effective and efficient user interfaces. We will discuss the challenges and opportunities of using AI in design, and provide practical tips and best practices for incorporating AI into your own workflow.

Быстрые тесты хочется запускать.
Лучшие практики по тестированию асинхронных операций.
Перематываем время и подменяем дату.

- Как мы пришли к функ тестам, боли с юнитами и их бесполезностью в компонентах
- Почему Enzyme - это больно и плохо (блокирование перехода на React 18)
- Муки выбора фреймворка или Cypress, как дорога в никуда
- Playwright и его скорость
- Мокинг данных для бэка
- Юзер стори и взаимодействие c QA
- Полученные выгоды и снижение нагрузки на DEV и QA (как мы друг другу помогли)
- Allure, как сквозной инструмент для DEV и QA