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

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

Frontend

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

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

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

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

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

Поговорим, какие тесты следует писать в первую очередь, и как сэкономить свое время, не проверяя 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.

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

«Интерактивное веб-приложение без программирования? Это невозможно!» — скажете вы. Возможно! И это не пустые слова, а научно-обоснованное учёными Массачусетского технологического института (США) утверждение.
Многие люди могут создавать статические веб-страницы с помощью HTML и CSS, но им сложно или подчас просто невозможно самостоятельно запрограммировать интерактивное веб-приложение (например, редактируемый сайт-портфолио, список контактов, карточки для изучения иностранного языка, дневник тренировок, багтрекер, ипотечный калькулятор и др.). Однако, для широкого класса CRUD-приложений этот разрыв может быть преодолен с помощью Mavo — нового подхода к разработке интерактивных веб-приложений, предложенного Лией Веру (Lea Verou).
Mavo расширяет декларативный синтаксис HTML. Используя Mavo, авторы с базовыми знаниями HTML неявно определяют сложные структуры данных при разработке HTML-макета будущего приложения. Им нужно всего лишь добавить несколько специальных атрибутов и выражений к HTML-элементам, чтобы преобразовать статический макет в полноценное управляемое данными веб-приложение. А данные эти, кстати, можно редактировать непосредственно(!) в браузере.
На примере построения небольшого веб-приложения мы убедимся, что даже пользователи без опыта программирования смогут быстро создавать веб-приложения с помощью Mavo.

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

Когда работаешь над библиотекой переиспользуемых компонентов, вопрос 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Познакомимся с пятью популярными Handless CMS с открытым исходным кодом. Рассмотрим, как управлять контентом, формировать API. Интегрируем API с типовым сайтом на React. Сделаем выводы о сильных и слабых сторонах Handless CMS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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