Заявки на доклады

Поиск по тегам:

Frontend

- Пишем собственный плагин для конвертации макета в html-разметку. Кто, как и зачем пишет?
- Какой для этого графический редактор выбрать? Figma, Zeplin, Adobe XD?
- Какие требования предъявляются к работе дизайнера? Верстаем компоненты сразу в макете
- Для какого стека подход реализуем? Реальный опыт на vue проектах.
- Автоматизация тестирования с помощью Storybook и скриншотов компонентов
- Итог: растет качество, повышается скорость разработки, рождаются новые методы frontend-разработки

Программный комитет ещё не принял решения по этому докладу

Рассмотрим что такое BDD тестирование и как оно помогает писать e2e тесты дешевле и быстрее.
Используя Gherkin синтакс в связке с Cypress рассмотрим, как сделать тесты понятными не только для разработчиков, но и для тестировщиков с менеджерами.
Определим место acceptance тестов в ci/cd пайплайне. Обсудим кто должен и может писать такие тесты и когда

Программный комитет ещё не принял решения по этому докладу

Команда реализовывает приходящие идеи продакт менеджера одной компании и делает сайт по таймингу для другой. Для структурирования, приоритизации, распределения, планирования таких задач они подтягиваются в общий Jira-проект с универсальным flow, трекерами и интеграцией с Bitbucket.

Кроме прозрачности процессов мы получили прирост эффективности в среднем на 13 500 рублей в месяц в команде из 9 человек. В докладе расскажу о том, как перестраивались инструменты и люди.

Программный комитет ещё не принял решения по этому докладу

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

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

TestCafe - это бесплатный опенсорсный фреймворк для автоматизации тестирования, который из маленького внутреннего проекта вырос в продукт с миллионами скачиваний и 8000 звездами на GitHub. Он работает со всеми браузерами и платформами и при этом не требует WebDriver или другие плагины.

Из этого доклада вы узнаете о том:
- На какие грабли мы наступали пока разрабатывали TestCafe
- Как нам приходилось выкручиваться в сложных ситуациях
- Что вам нужно чтобы начать писать E2E-тесты без головной боли (спойлер: да почти ничего)

Программный комитет ещё не принял решения по этому докладу

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

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

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

Также поговорим о том, как ускорить написание автотестов на JavaScript и повысить их читаемость с помощью нотации Gherking, библиотки jest-cucumber.

Разберем паттерн PageObject для end-to-end тестов на Puppeteer, который позволяет сильно упростить поддержку UI автотестов.

Программный комитет ещё не принял решения по этому докладу

Миграция проекта с одной технологии на другую — это всегда стресс и боль для бизнеса и разработки.

Наш основной проект, написанный на vanilla + jQuery с серверным XSLT и Python в качестве API Gateway, насчитывает больше 200 уникальных страниц и миллионы строк кода.

Полтора года назад мы приняли решение переезжать на React стек. И кроме обновления кодовой базы, мы решили перевести наш веб-сайт на SPA.

Мы не затормозили бизнес-разработку, и приняли концепцию частичной миграции. В ходе миграции мы решали большое количество вопросов, в том числе: как сделать, чтобы React приложение "знало свои рамки", а старое приложение не сломало новое? Как настроить клиентский роутинг в SPA, если главным "дирижером" выступает Python приложение, которое мы развивали более 5-ти лет?

Мы поговорим о инженерных решениях для перевода большого приложения с одного стека на другой, про UI ToolKit для двух миров и SSR.

Программный комитет ещё не принял решения по этому докладу
Программный комитет ещё не принял решения по этому докладу

– Организация совместной работы разработчиков
– Упрощенный порог вхождения в новый проект
– Самодокументация, архитектура и единый кодстайл

Программный комитет ещё не принял решения по этому докладу

В JS часто игнорируют разного рода паттерны проектирования.

И это не вина JS разработчиков, потому что все примеры применения написаны для ООП,
а почти все статьи отображают только теорию того или иного подхода.
Поэтому идея этого доклада погрузить Вас в 5-ый принцип SOLID, Dependency inversion (Инверсия Зависимостей)

И не просто детально рассказать о нем, а показать какие проблемы он решает, на реальных бытовых проблемах Frontend разработчиков

Программный комитет ещё не принял решения по этому докладу

Stencil - это компилятор, который создает веб-компоненты.
Как заявляют авторы, Stencil объединяет лучшие концепции самых популярных фреймворков в простой инструмент. Stencil использует такие функции, как:
- Виртуальный DOM
- Асинхронный рендеринг (вдохновленный React Fiber)
- Реактивная привязка данных
- TypeScript
- JSX

Программный комитет ещё не принял решения по этому докладу

- Понятие и принципиальная схема работы Relay Modern Environment
- Network Layer: грамотно коннектимся с серверной частью.
- Data Layer: Deep Diving

Программный комитет ещё не принял решения по этому докладу

Мы все примерно понимаем, что такое "Virtual DOM", но мало кто может более детально описать, как даже при огромном количестве обновлений ежесекундно, React все равно выдает 60 fps. Как при самых передовых алгоритмах со скоростью сравнениях деревьев порядка O(n^3), React добился скорости сравнения порядка O(n). И конечно же такое ускорение имеет свои последствия, которые влияют на вашу повседневную разработку, поэтому рассмотрим боевые примеры, того как вы сможете выстрелить себе ногу!

Программный комитет ещё не принял решения по этому докладу

The principles of Atomic Design have transformed (probably forever) the way we look at UI components and code modularization. Pattern Libraries and Design Systems – predominantly built in React – have become widespread across many companies.

No doubts, these are cool tools and approaches, and we have all fallen in love with them. But...
In this talk, I'll share not only the learnings but also all the "buts" that we have found in our exciting journey developing (in React, of course) a Design System for Badoo.

Программный комитет ещё не принял решения по этому докладу

Несмотря на то, что в JavaScript есть некоторые хорошие части, мне, как разработчику, хотелось бы меньше видеть ошибок времени выполнения в консоли браузера. Также было желание вести разработку и клиентского веб-приложения, и бэкенда на одном и том же языке программирования. Поэтому, когда меня попросили поучаствовать в небольшом проекте, в котором уже был код на Ruby, Perl, PHP и JavaScript, я решил проблему радикально. Результаты не заставили себя долго ждать - никаких больше "undefined is not a function!".

Программный комитет ещё не принял решения по этому докладу

Почти всегда клиент не готов платить за обеспечение доступности сайта. Имея некоторые простые знания веб программисты могут сделать разрабатываемые ими сайты более доступным не потратив для этого значимых ресурсов. Этот доклад познакомит вас с этими знаниями.
- мы увидим как настоящие пользователи используют screen reader'ы в повседневной жизни
- подробно узнаем как сделать наши решения более удобными для screen reader'ов
- как сделать сайт удобным для работы с одной лишь клавиатурой, без мыши или тачпада

Программный комитет ещё не принял решения по этому докладу

Баннеры – это те самые маркетинговые «добавки» в UI, которые ты почему-то обязан терпеть у себя на проекте, где и без того горячо от новых фичей и рефакторинга. И, поверьте, гораздо проще устроить беспорядок, закинув на страницу «левый» фрейм или лихую тройку HTML/CSS/JS, чем сесть и продумать грамотную архитектуру для такого, казалось бы, второстепенного функционала.

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

На все эти вопросы не так давно пришлось ответить лично мне как фронтенд техлиду фэшн-ритейлера Lamoda. К счастью, с задачей я справился достойно и спешу поделиться полученным опытом с вами.

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

Программный комитет ещё не принял решения по этому докладу

За годы своего существования (а это почти 30 лет) язык HTML зарекомендовал себя как исключительно дружелюбный язык, легко осваиваемый новичками. А в сочетании с CSS он позволяет достичь каких-то невероятных высот. Взять, к примеру, игру Mario Kart:CSS, написанную на чистом HTML и CSS.

Однако, есть задачи, с которыми HTML, даже в сочетании с CSS, пока справиться не может. Что если бы мы могли писать веб-приложения на языке HTML без привлечения JavaScript? Что если бы у нас был столь же дружелюбный и простой в изучении инструмент, который позволил расширить возможности HTML и при этом не потерять его сильные стороны чрезмерным усложнением?

И такой инструмент есть. Это Mavo — будущее HTML в настоящем!

Mavo разрабатывается в Массачусетском технологическом институте (MIT) под руководством Лии Веру (Lea Verou). В рамках доклада мы познакомимся с Mavo и на нескольких примерах увидим красоту и мощь этого великолепного инструмента.

Программный комитет ещё не принял решения по этому докладу

Недавно мы запустили новый сайт www.delivery-club.ru как Single Page Application. В довесок к нему возникла потребность реализовать Server Side Rendering. В докладе я расскажу о том, как нам удалось сделать SSR максимально быстрым и соответствующим всем критериям качества. При этом не упомяну основные грабли, по которым нам удалось пробежаться и какие проблемы может встретить frontend-разработчик на javascript в серверной среде.

Основные вопросы, которые рассмотрим в докладе:
- Задачи серверного рендеринга
- Метрики и инструменты для оценки качества
- Микрооптимизации
- Специфика серверного JavaScript и как не выстрелить себе в ногу
- Обход слабых мест JavaScript как способ повысить эффективность приложения
- Мониторинг
- Поддержка и кейсы на бою

Программный комитет ещё не принял решения по этому докладу

В консьюмерской разработке пошёл тренд на супераппы: VK, Snapchat, Тинькофф и другие активно эксплуатируют тему, в WeChat только власть критиковать нельзя. А в бизнесе все как-то грустно: единственное веселое за последние несколько лет - это Notion, и то он 40 секунд грузится.

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

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

Программный комитет ещё не принял решения по этому докладу

Расскажу о необычных техниках работы с TypeScript, позволяющих сделать ваш код проще, гибче и надёжней:

* CSS-in-TS с тайпчеком вложенности компонент.
* Поиск классов по сигнатуре.
* Контроль вариантности параметров.
* Нетривиальные типофункции и их типотесты.
* Рекурсивные и брендированные типы.
* Выведение типов статикодинамических валидаторов.
* Авторасширяемый типизированный контекст окружения.

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

Современное фронтенд приложение может быть большим и сложным, что порождает две проблемы: сложность поддержки и скорость доставки на бой. Одним из способов решения первой проблемы является архитектурное разделение на отдельные (простые и независимые) модули. Вторую проблему решает настройка CI/CD. Другим, дополняющим способом решения обеих проблем, является относительно новое направление — так называемые микрофронтенды. В этом подходе отдельные части приложения не только отделены логически и физически, но и имеют свои собственные релизные циклы: то есть доставка на бой не требует релиза других частей приложения.

В своём докладе я расскажу, как мы выделили две сотни компонентов из десятка приложений tinkoff.ru в «микромодули» — обособленные сущности со своим собственным релизным циклом каждая. Как мы сделали этот цикл быстрым, и сквозным по всем приложениям. Как мы решали проблемы межмодульного взаимодействия; проблему взаимодействия модулей с приложением, трекингом и логированием; проблему дублирования кода; проблему с сорсмапами; проблему интеграции с внутренней cms. И немного о том, как rust ускорил нам сборку в 20 раз).

Программный комитет ещё не принял решения по этому докладу

В этом докладе обсудим особенности и подходы к разработке приложений с серверным рендерингом, поговорим о том, как это работает в одном мире с микросервисами и CI/CD, а так же сравним реализации самых популярных фреймворков.
Как разрабатывать SPA на любимом фреймворке не жертвуя SEO? Как сделать так, чтобы каждый занимался своим делом - фронтендеры делали UI, а бэкендеры разрабатывали бизнес-логику и API? Как перевести большое web-приложение с legacy кодом на SPA? Эти и многие другие проблемы можно решить с помощью SSR.

Программный комитет ещё не принял решения по этому докладу

* Это доклад про большой фронтенд.
* Религиозные войны: монорепо, полирепо, микросервисы, монолит.
* Я буду рассказывать со своей колокольни: про работу с кодом и деление его на части. Вопросы CI, CD, тестирования, безопасности, перфоманса мы оставляем для других докладов.
* Боли: релиз цикл, вростающий вендоринг, устаревание кода, оценка зависимостей, дублирование кода и общий код.
* Интересные мелочи.

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

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

Расскажу что от вас хочет компания на каждом этапе Employee Journey и почему происходит то, что происходит:
- почему эйчар не отправляет вас на конференции
- почему ему не нужно знать, чем Java отличается от JavaScript'а
- почему иногда эйчар это просто эйчар

Объясню, во сколько вы на самом деле обходитесь компании, что хантят только дорогих и редких спецов (остальных включают в рассылку), когда нужно высшее образование, и куда надо засунуть вашу токсичность.

Программный комитет ещё не принял решения по этому докладу

- Производительность вашего проекта — в ваших руках.
- Сложности профилирования современного фронтенда имеющимися инструментами.
- Почему имеющиеся инструменты не помогают следить за производительностью.
- Lighthouse, webpack-bundle-analyzer, Chrome DevTools - как совместить всё это в одном инструменте и помочь разработчику.

Программный комитет ещё не принял решения по этому докладу

Вы заходите на сайт с мобильного устройства в трамвайчике. Вы его открыли. Грузите. Еще грузите. И еще грузите. Это связанно с тем, что с каждым годом наши приложения растут в объеме, что нам делать в этом случае? Забить и жить дальше. Нет!
Существует очень много способов оптимизаций, но, к сожалению, некоторые разработчики забывают об этом и пользователи страдают, не надо так. Один из вариантов отслеживания проблем вашего сайта - это Google PageSpeed или его братишка Lighthouse. Просто вбив адрес вашего чудесного сайта вы получите информацию о том, как можно все это дело оптимизировать. Но к сожалению и у таких сервисов бывают погрехи.
Я бы хотел затронуть эту важную тему оптимизации и расписать на примере проекта в продакшене, который имел около 5-8 баллов по Google PageSpeed Mobile. Рассказать какие кейсы нам помогли, какие были грабли и зачем нам на это тратить время вообще.

Программный комитет ещё не принял решения по этому докладу

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

Мне бы хотелось показать на примере своей карьеры и не только, что применительно к frontend-разработке означает пословица "что имеем не храним, потерявши плачем".

Программный комитет ещё не принял решения по этому докладу

– Можно обойтись без табличной верстки,
– Теперь письма верстать проще, прогрессивное улучшение(использовать лучшие технологий, не сделав хуже другим почтовым клиентам).

Программный комитет ещё не принял решения по этому докладу

Рассмотрим принципы работы SSR с загрузкой данных в React, подходы и идеологий различных инструментов - их плюсы и минусы.
Полностью разберем готовое решения изоморфного серверного рендера, собранного годами нашей командой, для подхода загрузки данных на уровне компонентов, с возможностью работы с REST api, кешем, передачей данных на клиент и возможностью кастомизации. Настройка и внедрение на реальных примерах в Create React App.

Программный комитет ещё не принял решения по этому докладу

Расскажем о реальном опыте развития проекта Тинькофф Путешествия в контексте внедрения PWA, разработки под Webview для МБ Тинькофф, публикации TWA (light-приложения, для Play Market). О проблемах разработки native-like компонентов средствами web, о проблемах интеграции, о подводных камнях связанных с различиями платформ, об эффективном тестировании. Поделимся своими практическими наработками.

Программный комитет ещё не принял решения по этому докладу

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

я хочу рассказать как не надо делать. использовать json, например, управлять строками руками и т.д.

и как надо делать. использовать специальные форматы, использовать платформы для перевода и т.д.

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

Программный комитет ещё не принял решения по этому докладу

Web Audio представляет собой API, в котором мы создаём ноды для обработки звукового сигнала, соединяем их между собой в граф и затем пускаем через него звук. Web Audio API подходит для самых разных целей: от обработки голоса в реальном времени для подкаста до проведения всевозможных вычислений, преобразований Фурье. Мы можем сделать виртуальный музыкальный инструмент, задействовав Web MIDI API, можем создать свою платформу для написания музыки в браузере. Но императивная натура этого API мешает созданию удобных переиспользуемых блоков, применению в средах вроде веб компонентов или фреймворков с компонентным подходом (Angular) и в целом работать с ним в чистом виде довольно трудно. Рассмотрим, как легко можно это исправить, изменив подход с императивного на декларативный.

- Введение в Web Audio API
- Сравнение декларативного и императивного подхода
- Создание нативных веб компонентов для обработки звука
- Написание музыки в браузере
- Игра вживую в браузере
- Преимущества использования Web Audio в Angular
- Другие области применения декларативного подхода

Программный комитет ещё не принял решения по этому докладу

Рассмотрим новые интересные тенденции в FrontEnd разработке. С появление WA писать сайты стало возможным не только на JS, но и на других языках программирования, таких как GO, RUST, C#, PHP. Раньше вставки на WA были лишь дополнением, теперь же появляются полноценные фреймворки, позволяющие не прибегать к JS, а писать сайт под ключ на привычном языке,

Программный комитет ещё не принял решения по этому докладу

Работая над личным кабинетом пользователя, наша команда искала альтернативу традиционному REST API. В результате поисков мы остановились на GraphQL и Apollo. Основной причиной выбора было описание взаимодействия с сервером. Однако, неясно было как интегрировать Apollo и Redux и можно ли обойтись вообще без последнего. В своем докладе я расскажу какой в итоге мы сделали выбор и как мы управляем локальным состоянием приложения без reducer’ов.

Программный комитет ещё не принял решения по этому докладу

Интерфейсы Яндекс.Поиска очень вариативные, но должны работать очень быстро. У нас много кода, и все должно быстро собираться, чтобы не замедлять процесс производства. Мы добились нужных нам показателей на стеке своих проприетарных технологий, а потом было принято решение о переезде на стек open-source технологий React и TypeScript, и все оптимизации нужно было делать заново. Расскажу про детали переезда, и как у нас теперь все работает. Будем останавливаться на каждой подзадаче и разбираться, почему сработали те или иные приемы

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

В TypeScript и Flow есть типы, но мы не можем их использовать в рантайме. Скажем, для валидации JSON, генерации рантаймовых проверок, property-based testing? Если очень хочется - то можно! Рассмотрим что такое type-directed emit и как его применить, сравним с другими видами рефлексии и кодогенерации, погрузимся в особенности апи транспиляторов и узнаем какие есть грабли у такого подхода.

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

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

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

Программный комитет ещё не принял решения по этому докладу

Некоторые frontend разработчики полушутливо называют себя «форма-клепатель». Это не так.

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

Программный комитет ещё не принял решения по этому докладу

End-to-end тестирование может быть довольно дорогим. Такие тесты сложно и долго писать, они хрупкие из-за частых изменений в UI. А когда падают, сложно найти причину.

Так может E2E-тесты не стоят того? Ведь для решения многих проблем достаточно unit-тестирования, а E2E только усложняет процесс.

Из этого доклада вы узнаете:
- почему unit-тестов может быть недостаточно для разработки
- почему E2E-тесты - это лучший способ определить, работает система или нет
- почему E2E-тестирование необязательно должно быть таким трудозатратным
- как легко внедрить E2E-тестирование в свой воркфлоу на примере TestCafe - кроссбраузерного опенсорсного фреймворка, который не требует установки WedDriver-а и плагинов

Программный комитет ещё не принял решения по этому докладу

Когда работаешь над библиотекой переиспользуемых компонентов, вопрос API встаёт довольно остро. С одной стороны, нужно сделать надёжное, аккуратное решение, с другой - удовлетворить массу частных случаев, причём не только в плане работы с данными, но и учесть все внешние особенности различных кейсов использования. Из этого доклада вы узнаете, как делать действительно гибкие компоненты на Angular:

- дженерики против интерфейсов
- функции-хэндлеры вместо свойств
- абстракция от внешнего вида
- полиморфные шаблоны

Программный комитет ещё не принял решения по этому докладу

This is the story of a Design System called Cosmos, that started as a small style guide and soon became a core element in the design and development process of a product with 400 million users. Appreciated by both developers and designers, with strong buy-in from managers and leads, today Cosmos has become a complex project of UI unification that involves multiple platforms, multiple brands, and multiple products. A success story — with visible metrics that confirm its impact — with a lot of lessons learned along the way.

Программный комитет ещё не принял решения по этому докладу

ODA - прогрессивный (PWA) ES фреймворк для создания пользовательских интерфейсов любой сложности для web-приложений, сайтов и кросс-платформенных мобильных PWA приложений.
- Особенности ODA Framework позволяет своим пользователям быстро и легко создавать интерактивные пользовательские интерфейсы любой сложности. Код веб-приложения становится настолько простым и понятным, насколько это возможно даже для отладки и дальнейшего распространения. Эффективное обновление и рендеринг интерфейса выполняются автоматически при любых изменениях самих данных или состояния веб-компонентов.
- Технологии Используется компонентно-ориентированный подход, основанный на всех 4 основных элементах технологии веб-компонентов: пользовательских элементах, Shadow DOM, шаблонах HTML и модулях. Он реализует все требования технологий PWA и PWC.
- Преимущества Простота кодирования и обучения, минимизация кода с максимизацией его функциональности, существенное увеличение скорости разработки и расширяемости благодаря повторному использованию готовых веб-компонентов, разработанных как самостоятельно, так и сторонними разработчиками. Высокая эффективность рендеринга для любых изменений, происходящих в интерфейсе. Возможность разработки кроссплатформенных мобильных приложений.

Программный комитет ещё не принял решения по этому докладу

Если вы устали от хаоса при работе с формами и хотите навести порядок в коде, то приходите послушать про JSON Schema. Я расскажу про стандарт и инструменты, которые помогут вам структурировать и формализовать вашу работы с формами. Поделюсь опытом и, конечно, реальные примеры кода на React!

Программный комитет ещё не принял решения по этому докладу

"Ты должен писать код в свободное время" - я слышу эту фразу на протяжении всей моей карьеры. Когда я только начинал свой путь и спустя почти 10 лет разработки - я все еще слышу эту фразу. Некоторые руководители компаний говорят, что не наймут разработчика. который не пишет код в свободное время. Этот популярный вопрос на собеседованиях.

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

Но действительно ли это так важно? Почему все вокруг только и ждут, что я готов тратить свое время на программирование? Могу ли я стать действительно отличным разработчиком, если я предпочитаю тратить свое время на другие интересы, семью и друзей?

Программный комитет ещё не принял решения по этому докладу

Безусловно, одними из важнейших элементов интерфейса любого WEB-приложения являются формы. По сути формы являются «проводником» между приложением и пользователем. Получить сообщение, организовать голосование – без форм это было бы проблематично (хотя и возможно). С того времени, когда WEB-страницы были похожи на стандартные окна Windows 95, многое изменилось. Приложения стали красивые, красочные. Однако элементы формы до сих пор вызывают «боль» у разработчиков. В своем докладе я попытаюсь дать максимум информации о том, как делать красивые формы, не теряя при этом основного – удобства для пользователей.

О чем конкретно будем говорить:

- Разберем, как лучше организовать HTML-структуру формы.
- Как лучше и логичнее стилизовать чекбоксы, радиокнопки.
- Разберем стилизацию более сложных вещей (select, range-слайдер, календарь).
- Рассмотрим ошибки в стилизации форм на примерах крупнейших российских компаний.

Программный комитет ещё не принял решения по этому докладу

Добавить svg иконку на сайт просто. Это можно сделать в виде отдельного ресурса в спрайте. Можно заинлайнить в виде компонента. Можно воспользоваться css-masks или filter.
Спустя некоторое время, к нам приходит дизайнер и просит использовать другой размер или цвет в определенном месте. Мы добавляем какую-то логику, усложняем текущее решение и, возможно, приходим к инлайн варианту.
Этот способ очень удобен, и в современном вебе я встречал его на каждом 3-м сайте на React.
Главная проблема такого варианта: при SSR иконка не кешируется, и мы каждый раз гоняем от сервера к пользователю набор иконок на странице.
Мы сталкиваемся с задачей поддержки вариабельности иконок и их перфоманса.
В этом докладе мы разберем разные способы создания и оптимизации иконок. Окунемся в оверинжиниринг и попробуем ответить на вопрос: Только ли Ситхи возводят все в абсолют?

Программный комитет ещё не принял решения по этому докладу

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

Программный комитет ещё не принял решения по этому докладу

Познакомимся с пятью популярными, бесплатными для использования, Headless CMS, которые можно без проблем развернуть на своем сервере. Рассмотрим, как создавать модели, управлять контентом, формировать и принимать API. Сделаем выводы о сильных и слабых сторонах Headless CMS, в каких случаях её можно и НУЖНО использовать.

Программный комитет ещё не принял решения по этому докладу

Технически-сложные проекты рано или поздно сталкиваются со скоростью сборки. Над нашим проектом в пике работало больше 10 разработчиков, а проект собирался около 25 минут.
Мы решили эту проблему, разложив сборку на слои, и сейчас внедряем эту практику на других проектах. Время сборки сократилось до 7 минут в среднем.
В докладе я расскажу о том, как мы пришли к этому решению, и в качестве бонуса покажу, как у мы научились изящно возвращать предыдущую версию проекта после релиза.

Программный комитет ещё не принял решения по этому докладу

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

Коллега настаивает на использовании табов, когда вся команда использует пробелы. Кто-то постоянно опаздывает на совещания. А кто-то комитит код не проверив что он работает. Вариантов миллион.

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

Программный комитет ещё не принял решения по этому докладу

Локализация — это просто, думаете вы. Нужно только вынести все тексты из кода приложения и перевести их.

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

Я расскажу, как мы организовали локализацию в Яндекс.Директе — проекте с десятками тысяч фрагментов текста и командой 40+ человек.

Программный комитет ещё не принял решения по этому докладу