3 года назад мы полностью пересобирали всю техническую команду RUTUBE, а вместе с ней все ключевые сервисы и перепридумывали архитектуру систем под задачи бизнеса. Мы выросли с 60 тысяч ежедневных пользователей в 2021-м до 17,7 млн пользователей в сутки на сегодняшний день. И когда нам нужна агрегация данных, любой клиент сейчас может получить новую ручку с API и быть уверенным, что данное решение точно будет работать стабильно и держать нагрузку. Но так было не всегда.

В этом докладе я расскажу:
* в каком виде мы получили сервисы от старой команды и как 3 месяца не могли выкатить А/В-тест;
* какой была архитектура легаси-решения, и почему мы выбрали Nest.js;
* почему решили отказаться от идеи переписать все на GraphQL;
* как продали свое решение и почему именно наше решение теперь является единым BFF;
* какая архитектура в итоге получилась в результате интеграций с Web-, Mobile- и SmartTV-приложениями;
* как выстраивать процессы и обеспечивать SLA для большого количества клиентов в высоконагруженных сервисах.

Сложно найти того, кому ни разу не приходилось обвешивать страницу событиями веб-аналитики. Этот процесс, выполняемый по четко выверенному ТЗ олицетворяет из себя рутину — 20+ пунктов, каждый описывает конкретное событие и payload.

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

Берем углубленные знания веб-технологий, добавляем щепотку react internals и заворачиваем в системный подход. И вот эта адская смесь уже готова отправлять все нужные события самостоятельно!

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

Методология DDD (Domain Driven Design) появилась достаточно давно, а в русскоязычном сегменте IТ начала набирать популярность во второй половине 2010-х годов. Больше всего, конечно, эту методологию используют в бэкенде и даже считают, что в соответствии с этой методологией можно писать код. Сегодня мы не будем рассматривать код, а сосредоточимся на образе мышления и том, как DDD может привести нас к успеху.

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

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

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

В этом докладе я расскажу:
* зачем нужна сложная архитектура для плеера, а не просто тег video;
* как старая реализация на redux и суперкомпоненте тормозила разработку, убивала возможности развития и масштабирования;
* какие задачи окончательно заставили выделить ресурсы на тотальный рефакторинг;
* каким образом мы переписали плеер на Mobx, распилили его на модули, внедрили DI и интегрировали плеер в другие проекты холдинга.

При объединении нескольких независимо разрабатываемых SPA перед нами стоят вызовы по сохранению стабильности и совместимости.

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

Код можно сделать читаемым, поддерживаемым и безопасным, но не через волю к искусству. Красота кода должна быть системной. На примерах покажу, как настраиваются кастомные линтеры, как SonarQube помогает находить «плохой» код и как стандарты превращаются в культуру. Расскажу, где нужна строгость, а где лучше довериться здравому смыслу команды.

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

Доклад о том, как управлять состоянием в распределенной микрофронтенд-архитектуре на примере реального опыта разработки плагинной системы в Kaspersky Security Center (KSC). Расскажем про использование runtime как глобальной среды исполнения, event-driven-подход к взаимодействию модулей, строгие контракты для обмена данными, а также подходы к управлению состоянием.

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

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

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

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

Пользователь вводит свое имя, номера карт, адреса, логин и пароль в формы, которые мы пишем. Имея эти данные можно узнать о человеке все: от того, где он покупает утренний кофе, до того, какие у него планы на вечер через 2 недели.

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

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

В своем докладе я расскажу, каким образом EventBus может эволюционировать в EventBroker — более мощный инструмент для оркестрации событий между микрофронтами. Мы разберем, как EventBroker позволяет реализовать как peer-to-peer, так и broadcast-коммуникации, синхронизировать события между вкладками, а также легко внедрять дополнительную логику через хуки (логирование, ACL и др.).

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

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

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

Отдельно поговорим о том, какие есть способы защиты и детекции ботов на фронтенде — от простых приемов до готовых тулов, которые можно интегрировать в ваши проекты.

И, конечно, коснемся границ допустимого и этики: почему важно понимать, где заканчивается «нормальное» взаимодействие с вашим сервисом и начинается атака.

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

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

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

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

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

В докладе расскажу о подходах к работе с микрофронтами. Рассмотрим специально спроектированное dev-окружение для экосистемы микрофронтов и разберем сложные сценарии использования микрофронтов:
* подключение микрофронтов из разных окружений с (локального и dev) учетом автоматизации;
* разработка микрофронтов неограниченной вложенности для разных бизнес-сценариев;
* запуск микрофронтов в режиме работы с моками и реальными данными из api;
* мокирование микрофронтов при e2e-тестировании.

Frontend-приложения могут иметь тысячи зависимостей, Supply Chain-атаки в NPM происходят все чаще. О краже данных мы узнаем только из жалоб пользователей через дни и недели после релиза. Разберем известные инциденты и актуальные риски для frontend-приложений.

Рассмотрим, как сделать FrontSecOps из FrontOps, совместить E2E-тесты с безопасностью и обнаруживать вредоносное поведение JS-кода до релиза с концепцией Frontend Application Security Testing (FAST).

Каждый месяц в реестре NPM публикуется 30-40 тысяч новых пакетов и огромное количество обновлений существующих библиотек. Что там лежит — очередное обновление React, полезная доработка axios или «небольшие правки», нацеленные на кражу данных ваших криптокошельков, — никто не знает.

При этом, работа с реестром NPM — неотъемлемая часть нашей жизни, и доля опенсорса в современных проектах иногда достигает 80-90%.

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

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

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

Альфа-Онлайн — веб-версия интернет-банка с микрофронтендной архитектурой. Сегодня он работает как PWA и на Android, и на iOS, но именно iOS долгое время оставалась главной преградой на пути к полноценному веб-приложению.

В докладе я расскажу:
* почему мы пришли к PWA на iOS и с какими ограничениями столкнулись;
* что нужно для запуска PWA и как проверить поддержку функций;
* какие возможности получает пользователь: установка приложения, полноэкранный режим, сплэш-скрины, push-уведомления, вход через WebAuthn, работа с файлами и кеширование;
* какие ограничения остаются: работа с куками, управление пермишнами и особенности Safe Area;
* какие практические решения помогли нам превратить набор ограничений в рабочее приложение.

Фокус — реальный опыт внедрения: от технических деталей до бизнес-ценности PWA.

Устали от рутины: дублирования кода, рассинхрона типов между фронтом и бэком, сложностей типизации REST API и обновлений?

Мы разберем, как tRPC решает эти проблемы. Вы узнаете, что такое end-to-end typesafe API, как создать единую кодовую базу для логики с автоматической типизацией, принудительной валидацией и упрощением тестов.

Углубимся в создание собственного универсального API-пакета на основе tRPC, который можно использовать в проекте. Рассмотрим продвинутые темы: абстракцию над данными, базовую авторизацию с middleware и работу с клиентом. Не забудем и про REST-совместимость для отдельных маршрутов, а также обсудим ограничения подхода (кэширование, публичные API, привязка к TS/Zod).

Уйдете с пониманием, как tRPC уменьшает boilerplate и ускоряет разработку, не заменяя REST полностью.

Поговорим о пути создания интерфейса от момента MVP до запуска полноценного проекта. О том, когда нужно использовать библиотеку стилей и компонентов из open source, а когда — пилить свое. Если делаете свое, то как настроить флоу так, чтобы разработка нового не ломала старое. А если проектов много, но они плюс-минус одинаковые? А если у заказчика строгий брендбук и жесткие правила? Можно ли брать готовую библиотеку или надо пилить что-то свое?

Время сопровождает нас на протяжении всей жизни. Что может быть привычней и понятнее? Однако даты и время — один из частых источников ошибок в разработке.

Сообщество неоднократно пыталось улучшить ситуацию с помощью библиотек, но теперь за дело берется стандарт — Temporal API. Мы используем Temporal в продакшне со времен stage 2.

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

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

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

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

Вы узнаете:
* почему даже у опытных разработчиков возникают сложности;
* что тестировать, а что не надо;
* как тестировать, а как не надо;
* лайфхаки, основанные на практическом опыте.

AMP-emails, разработанные Google, превращают электронные письма в интерактивные мини-приложения. Они поддерживают вычисления, управление состоянием, выполнение GET и POST запросов к серверу и динамический рендеринг данных из JSON-ответов.

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

В экосистемах React и Vue уже давно сформировалась культура Headless-компонентов.

С появлением в Angular Signals и Directive Composition API у разработчиков появились инструменты для создания мощных Headless-компонентов с уникальной Angular-спецификой.

В докладе мы рассмотрим:
* как разрабатывать Headless-компоненты в Angular;
* какую ценность добавляет Selectorless-подход;
* практические примеры и сравнение с решениями в React и Vue.

Зачем мы пошли в PWA
1. Единый UX для всех платформ: web, mobile, WebView.
2. Обход ограничений стора: быстрые релизы, A/B-тесты, отсутствие модерации.
3. Низкий порог входа: не требует установки, доступен по ссылке.

Как мы это построили
4. Микрофронтенды + SystemJS: каждая команда — владелец экрана.
5. Платформа как продукт: единые сборки, дизайн-система, CI/CD, релизы.

UX и ощущение «нативности»
6. Анимации, свайпы, skeleton-экран — поведение как у мобильного приложения.
7. Поддержка WebView: плавность, адаптивность, совместимость с навигацией.
8. Работаем над нулевым временем загрузки: инкрементальная отрисовка, lazy loading.

С чем столкнулись
9. Производительность на слабых устройствах и в WebView — JS-оптимизации критичны.
10. Компоненты не учитывают мобильный UX: дорабатываем UI-kit.
11. Дублирование логики между mobile и web — работаем над переиспользованием. Шаг в WebView.

Document Picture in Picture — экспериментальный API, позволяющий выносить часть интерфейса в отдельное плавающее окно.

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

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

Обычно для реализации подобного поведения нам необходимо использовать JavaScript. Однако теперь это необязательно благодаря новой фиче в CSS.

В докладе расскажу про CSS Anchor Positioning и как с его помощью упростить разработку связанных друг с другом элементов.

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

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

Поговорим про:
* процесс миграции большого проекта на веб-компоненты;
* нюансы работы с ShadowDOM;
* ограничения технологии.

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

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

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

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

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

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

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

Как руководитель, я часто встречался с проблемой, когда ребята из команды пытались равняться на самого «быстрого и производительного» senior-разработчика и тем самым загоняли себя в капкан расстройства.

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

Не справляетесь с безграничным потреблением ресурсов в NextJS при использовании картинок? Надежда на сообщество Open Source-разработчиков фреймворка угасла? После этого доклада вы избавитесь от всех страданий!

Я расскажу, как мы столкнулись с утечками памяти в NextJS из-за модуля оптимизации изображений и первыми решили проблему, вызванную модулем оптимизации изображений. Мы прошли весь путь от локализации проблемы до разработки Open Source-решения и разработали утилиту next-image-cache-cleaner, которую вы можете переиспользовать у себя.

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

Node.js умеет многое, но не все. Когда нужно выжать максимум из вычислений или достучаться до «железа», на сцену выходят нативные модули. Node-gyp — не самая популярная технология, но именно она позволяет быстро подключить мощь C++ к Node.js и заметно ускорить приложение.

В этом докладе соберем модуль на C++ с нуля, замерим производительность, разберем альтернативы и честно обсудим, когда node-gyp — суперсила, а когда — лишняя сложность.

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

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

Из доклада вы узнаете, как:
* работают под капотом технологии аппаратно-ускоренной графики;
* подобрать нужную технологию рендеринга (Canvas/WebGL/WebGPU API) в зависимости от условий вашего проекта;
* графика, работающая «на чтение», становится интерактивной и как это влияет на производительность;
* рендерить графику с частотой от 30 FPS и выше на real-time-примерах;

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

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

Web Vitals — это только начало: пришлось внедрять собственные метрики, отслеживать поведение отдельных компонентов и делать замеры не на синтетике, а в реальном продакшне.

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

HTTP-кеширование — мощный, но ограниченный фундамент для современных SPA. Мы разберем его правильную настройку, а также подключение Service Workers для обхода ограничений и библиотек вроде TanStack Query для интеллектуального управления состоянием приложения.

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

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

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

Оказалось, дело в приоритизации обновлений в React: он может отбрасывать низкоприоритетные изменения, что приводит к tearing (разрывам интерфейса).

В докладе проведу разбор реального кейса: обсудим работу React под капотом и рассмотрим, как устроены lanes и concurrent rendering.

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

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

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

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

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

Один из современных «сложных» паттернов — это инвертированный угол или «обратный радиус скругления». На него уходят тонны кода.

Во время доклада мы напишем мини-утилиту для реализации этого паттерна на чистом CSS. В процессе погрузимся в тонкости свежайших или незаслуженно непопулярных фич CSS: линейных и радиальных градиентов, масок, переменных и в магию calc().

I. Помусолим эвристики и их применение на примерах интерфейса разработчика, часть из них точно отложится в голове.
II. Перенесем эвристики на примеры UI конечного пользователя.
III. Затронем тему балансов между некоторыми эвристиками (увеличение одной метрики может ухудшать другую).

А также разберем некоторые экзистенциальные UI-решения:
* Disable vs Hide элементов интерфейса;
* дублировать или нет действия;
* свобода выбора vs предотвращение ошибок;
* догадается vs не догадается (если можно ошибиться, то кто-то обязательно это сделает).

Полный список эвристик от Nielsen Norman Group: https://www.nngroup.com/articles/ten-usability-heuristics/

P. S. Хотя современные IDE, все больше похожи на UI для написания кода, который ускоряет работу и помогает предотвратить ошибки, автор любит сравнивать их с написанием текста в блокноте.

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

Также разберем конкретные кейсы. Figma MCP: извлекаем дизайн-данные и получаем кодовые заготовки. Jira MCP: из текста задачи получаем план работы и список проверок. GitLab MCP: ускоряем ревью, автоматически подсвечиваем проблемы и предлагаем точечные правки. Расскажу как обкатать на локальном агенте, затем соберём в n8n для команды.

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

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

Доклад раскрывает текущее состояние разработки с использованием нейросетей, представляя вайбкодинг как новый подход, ускоряющий создание продуктов при наличии продуктового мышления и опыта. Обсуждаются: примеры эффективного вайбкодинга (Replit, Gemini, Bolt, Build, Claude CLI), роль нейросетей как нового уровня абстракции в программировании, а также изменения в SDLC, навыки разработчиков, как изменится разработка, и качества, необходимые для работы с ИИ-агентами.

Атаки на цепочку поставок становятся причиной проникновения в компанию, которая занимается разработкой продукта. Манипулирование зависимостями в SDLC позволяет злоумышленникам массово получать доступ к рабочим станциям разработчиков, интеллектуальной собственности и дальше распространять вредоносный код. Использование LLM усиливает этот тренд и открывает новые возможности для атак.

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

Представьте: больше никаких опечаток в урлах, никакого хаотичного пробрасывания query-параметров и головной боли при рефакторинге маршрутов. На этом мастер-классе вы научитесь собирать строго типизированный роутинг на TypeScript — без лишних библиотек и магии.

Мы разберем:
✅ как заставить урлы, параметры и маршруты работать на уровне типов — с автодополнением и проверкой ошибок на этапе компиляции;
✅ как превратить ваши роуты в предсказуемый и переиспользуемый API, который не сломается от переименования параметра;
✅ реальные кейсы и динамические трюки для сложных сценариев (например, валидация параметров или вложенные маршруты).

Это не просто теория — будет много кода, интерактива и ответов на ваши вопросы. После мастер-класса вы сможете сразу применить эти практики в своих проектах и забыть про stringly-typed-костыли.

🔥Для кого: фронтенд-разработчики на TypeScript, которые хотят вывести роутинг на уровень enterprise-качества.

Приходите — и пусть ваш код станет не только работающим, но и элегантным! 💻✨

P.S. Возьмите ноутбук, если хотите повторить примеры. Но можно и просто вдохновляться!

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

За один воркшоп мы с нуля создадим реального ИИ-агента для бизнеса. ИИ-агент будет не просто болтать, а решать задачи: консультировать, искать по базе, создавать встречи в календаре.

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

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

Для участия нужен лишь ноутбук с Node.js и Docker. Остальному научишься на месте!

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

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

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

Решали ли вы задачи Type Challenges? Вызывает ли тревогу мысль о рекурсии и выведении типов внутри дженериков? Давайте же пройдем по теории и практике сложных моментов в TypeScript и перестанем их бояться.

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

Чаты, трейдинг-платформы, редакторы — в разработке всех этих продуктов реактивный подход и RxJS дают ряд несомненных преимуществ. Традиционные варианты (redux-saga, effector), увы, часто не справляются в таких системах, усложняя и запутывая исходный код.

Но всегда ли игра стоит «реактивных» свеч? И когда работа с такими решениями может перетечь в карго?..

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

Объективности ради, покажу и «подводные камни» библиотеки: проблемы с производительностью и отладкой, интеграцией с React и другие нюансы. Разберем конкретные ситуации, когда решение действительно полезно и важно -– а когда может быть излишним.

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

Маркетплейсы активно развиваются за счет привлечения партнеров, которые открывают ПВЗ. Локация ПВЗ — один из решающих факторов его окупаемости. Для выбора локации партнеры используют специальные веб-карты. Такие веб-карты есть у Озона, Яндекс Маркета и WB.

Около года назад мы небольшой командой начали активную работу по переосмыслению и переустройству карты WB для открытия ПВЗ (map.wb.ru). Доклад повествует о том, как мы превратили карту, по которой можно было только узнать тариф в выбранной точке и сделать это только с компьютера, в удобный инструмент для осознанного выбора точки открытия ПВЗ.

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

Пакетные менеджеры являются фундаментальной частью современного фронтенда, но их внутренняя работа часто остается «магией» для многих разработчиков. В этом докладе мы разберемся, как под капотом работают NPM, Yarn и PNPM, а также покажем, как их архитектура влияет на ваш проект, CI/CD и на память на жестком диске.

В докладе я детально разберу ответы на следующие вопросы:
1) жизненный цикл пакетного менеджера: как работают пакетные менеджеры под капотом;
2) как эволюционировал NPM и какие проблемы он решает;
3) Yarn: революция с lock-файлами и PnP: что нового принес Yarn и как он оптимизирует установку пакетов;
4) PNPM: хардлинки, симлинки и экономия до 70% места: как PNPM экономит место и повышает эффективность;
5) сравнение: что выбрать, как выбрать оптимальный пакетный менеджер для вашего проекта.

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

Ценность доклада:
1) понять жизненный цикл установки пакетов и внутренние механизмы работы NPM, Yarn и PNPM;
2) узнать, как избежать «dependency hell» и ускорить CI/CD;
3) выбрать оптимальный пакетный менеджер для вашего проекта, исходя из его потребностей и ограничений.

Какие смыслы будут переданы аудитории в ходе доклада?
1) Понимание внутреннего устройства пакетных менеджеров.
2) Знания о преимуществах и недостатках NPM, Yarn и PNPM.
3) Практические рекомендации по выбору и использованию пакетных менеджеров.
4) Возможность оптимизировать свой рабочий процесс и повысить эффективность.