Доклады
FrontOps (3)
Лучший SRE - это фронтендер
Все рано или поздно задумывались, а куда мне развиваться дальше? Кто-то дополнительно занимался аналитикой, кто-то бэкендом, но вот мой путь пошел в сторону SRE и в своем докладе я расскажу, что вам удастся развить в себе как разработчику, если вы решите пойти по данному пути. Как научитесь разбираться в инцидентах, искать корневые причины возникновения и пути их исправления. Но и самое главное, как это повлияет на вас как фронтенд разработчика ибо вы станете гуру в проектировании и разработке безопасных и отказоустойчивых систем.
Доклад принят в программу конференции
От make к node: эволюция многопоточности во фронтенд-инфраструктуре.
С ростом проектов и увеличением времени CI всё больше внимания уделяется скорости инструментов. В этом докладе мы поговорим о том, почему время выполнения пайплайнов действительно важно, какую роль в оптимизации играет многопоточность и как можно по-новому взглянуть на организацию инфраструктурных инструментов во фронтенде.
Доклад принят в программу конференции
Безопасность при работе с NPM
Каждый месяц в реестре NPM публикуется 30-40 тысяч новых пакетов и огромное количество обновлений существующих библиотек. Что там лежит - очередное обновление React, полезная доработка axios или "небольшие правки", нацеленные на кражу данных ваших криптокошельков, - никто не знает.
При этом, работа с реестром NPM - неотъемлемая часть нашей жизни, и доля опенсорса в современных проектах иногда достигает 80-90%.
Я расскажу о том, какие существуют типы угроз и проблем, связанных с работой с внешними библиотеками, поговорим про typosquatting, подмену пакетов, распространение вредоносных пакетов через вакансии, получение хакерами доступа к разработке популярных пакетов и многое другое.
Я расскажу о том, как после очередного обновления пакетов падали проекты с мировым именем, как, добавив новый пакет, можно легко поделиться паролем от криптокошелька со злоумышленником, как разработчики давали удаленный доступ к своему компьютеру, установив проект из тестового задания после собеседования.
Поговорим и о том, какие существуют методологии и способы защиты от подобных угроз, а в конце доклада я поделюсь чеклистом по безопасной работе с npm.
Доклад принят в программу конференции
Мастер-класс (1)
Строим строго типизированный роутинг
Вместе построим роутинг, который работает на ts. Не используя никаких сторонних библиотек, имея в руках только react-router-dom, соберем систему, при которой все параметры и урлы станут строго типизированными. Долой строки!
Доклад принят в программу конференции
Другое (6)
Фронтендер – приговор или путь к успешной карьере?
Многие фронтенд-разработчики сталкиваются с ощущением «карьерного потолка», достигнув уровня сеньора. Как выбраться из этого замкнутого круга и открыть для себя новые перспективы? В рамках доклада мы разберем, почему фронтендеры часто застревают на одном уровне, какие компетенции помогут вырасти в роли архитектора, Staff Engineer или даже Technical Fellow, и как сформировать собственную матрицу навыков для устойчивого профессионального роста.
Вы узнаете:
- Какие качества ценятся на высоких технических позициях и как их развивать.
- Как двигаться в сторону бизнес-ориентированности, не теряя экспертности.
- Как определить свои слабые стороны и превратить их в точки роста.
Доклад станет полезным практическим ориентиром для тех, кто хочет строить долгосрочную карьеру во фронтенде и находить новые возможности для профессионального развития.
Доклад принят в программу конференции
Как мы делали мобильное приложение Директа на WebView
Какая была задача. Для чего Директу приложение?
Выбор технологии. Какие варианты? Почему именно WebView?
Как работает приложение
Пуш-уведомления
Другие технические вызовы. Избавляемся от "вебности" в приложении
Как устроен релизный цикл
Доклад принят в программу конференции
Ограничиваем разработчиков во благо UX и DX
Библиотеки компонентов играют важную роль в большинстве проектов.
При самостоятельной разработке компонентов мы стремимся сделать их гибкими и универсальными, чтобы они подходили для различных случаев. Но является ли это оптимальным подходом? Может ли ограниченный компонент быть лучше гибкого? Да, может! В своем докладе я продемонстрирую, каким образом ограничение API UI-компонента способствует более эффективному выполнению его задач и облегчает его использование для разработчика.
Доклад принят в программу конференции
Как фронтендеру стать СТО?
«Плох тот солдат, который не мечтает стать генералом», — гласит народная мудрость.
«Плох тот разработчик, который не мечтает стать СТО», — перефразировал я эту фразу.
Я в своей работе неоднократно встречал убеждение, что техлиды и более высокие технические менеджеры — это бывшие бекендеры, а фронтендерам наверх дорога закрыта.
В своём докладе я бы хотел развеять этот миф: посмотреть, какие шаги есть на пути в управление разработкой команды, группы команд, целой компании. Как стоит поступать на каждом этапе и — самое главное — где у фронтендера есть преимущества в этом пути.
Доклад принят в программу конференции
Supply Chain-атаки и js-снифферы в NPM-зивисимостях. Выпускаем безопасный frontend с концепцией Frontend Application Security Testing (FAST)
Frontend-приложения могут иметь сотни транзитивных зависимостей, Supply Chain-атаки в NPM происходят все чаще. Js-код минифицируется при сборке, а браузер пользователя всегда является "слепой" зоной с т.з. безопасности. Поговорим об актуальных рисках, угрозах для frontend-приложений, разберем известные инциденты. Рассмотрим, как сделать FrontSecOps в DevSecOps, совместить E2E-тесты с безопасностью и прийти к Secure By Design
Доклад принят в программу конференции
Fail-митап
Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе!
В своих коротких, но зажигательных выступлениях спикеры поделятся настоящими историями фейлов. Без записи, без трансляции, без комплексов.
Доклад принят в программу конференции
Архитектура (6)
Системная автометрика или как перестать вешать веб-аналитику
Сложно найти того, кому ни разу не приходилось обвешивать страницу событиями веб-аналитики. Этот процесс, выполняемый по четко-выверенному ТЗ олицетворяет из себя рутину - 20+ пунктов, каждый описывает конкретное событие и payload.
Что если я скажу вам, что можно больше этого не делать, использовав сэкономленное время на ваши любимые задачи?
Берем углубленные знания веб-технологий, добавляем щепотку react internals и заворачиваем в системный подход. И вот эта адская смесь уже готова отправлять все нужные события самостоятельно!
Доклад принят в программу конференции
DDD для фронтэндеров
Методология DDD(Domain Driven Design) появилась достаточно давно, а в русскоязычном сегменте ИТ начала набирать популярность во второй половине 10х годов. Больше всего, конечно, эту методологию используют в бэкэнде, и даже считают, что в соответствии с этой методологией можно писать код.
Я хочу показать, что методология !== технология, и рассказать, как использовать DDD на фронтэнде, как сделать вашу жизнь в команде лучше, понятнее и дружнее с помощью небольшого изменения ментальных конструкций, которыми вы оперируете.
Доклад принят в программу конференции
Эволюция плеера RUTUBE: от монолита к гибким модулям
Когда мы пришли 3 года назад, архитектура плеера RUTUBE оставляла желать лучшего.
Первое время мы пытались приводить в порядок и развивать то что было, но быстро стало понятно, что нам не удастся двигать вперед и реализовать поставленные цели без полной переработки.
В это докладе я расскажу:
- Зачем нужна сложная архитектура для плеера, а не просто тег video.
- Как старая реализация на redux и супер-компоненте тормозила разработку, убивала возможности развития и масштабирования
- Какие задачи окончательно заставили выделить ресурсы на тотальный рефакторинг.
- Каким образом мы переписали плеер на Mobx, распилили на модули, внедрили DI и интегрировали плеер в другие проекты холдинга
Доклад принят в программу конференции
Как заставить команду писать качественный, красивый, понятный код?
Как заставить команду писать красивый (поддерживаемый, понятный) код
1. Введение: зачем писать красивый код?
• Почему качество кода важно для команды и компании?
• Примеры проблем, которые возникают из-за разного кода.
• Краткий обзор инструментов и подходов.
• Почему стандартизация полезна для команды и компании?
2. Написание собственных правил для линтера
• Почему стандартных правил может быть недостаточно?
• Как писать собственные правила:
• - Примеры в rules для (ESLint).
• - Использование AST (Abstract Syntax Tree).
• Как внедрить собственные правила в проект.
3. SonarQube: мощный инструмент для анализа кода
• Что такое SonarQube?
• Какие метрики предоставляет SonarQube:
• - Code smells.
• - Уровень покрытия тестами (test coverage).
• - Технический долг.
• - Уязвимости и ошибки.
• Примеры пользы для бизнеса и разработчиков.
• Как подключить SonarQube к проекту:
• - Развертывание на сервере.
• - Интеграция с CI/CD.
• - Подключение к IDE.
4. Границы жесткости стандартов
• Можно ли запретить всё?
• Преимущества и недостатки жестких правил:
• - Упрощение онбординга новых разработчиков.
• Рекомендации: где стоит быть гибким, а где — строгим.
• Почему важно вовлекать команду в обсуждение стандартов.
5. Кейсы и примеры: демонстрация на практике
• Реальный пример линтера с кастомными правилами.
• Анализ реального проекта через SonarQube:
• - Выявление проблем.
• - Рекомендации по их устранению.
• Обсуждение: как это улучшило код и взаимодействие команды.
6. Заключение: путь к красивому коду
• Резюме: инструменты и подходы.
• Советы для внедрения:
• - Начните с небольших изменений.
• - Слушайте команду.
• - Делайте код-ревью частью культуры.
Доклад принят в программу конференции
Почему FSD не работает и чем его заменить
Обсудим следующие темы:
– Почему FSD так выстрелил
– Какая главная польза от FSD в проекте
– Почему многие критикуют FSD
– Какие архитектурные принципы FSD действительно работают, а какие можно выкинуть
– Evolution design, как FSD без мишуры
Доклад принят в программу конференции
Безопасность кода от разработчика до пользователя
Все мы пишем фронтенд, а как мы знаем фронтенд ближе всего к пользователю с точки зрения разработки. Он вводит свое имя, номера карт, адреса, логины и пароль в формы, которые мы пишем. Имея эти данные можно узнать о человеке все. НО опыт показывает, что не все проекты добросовестно их обрабатывают. Хочу поделиться опытом, как мы в банке следим за безопасностью выкатыаемых фич.
Доклад принят в программу конференции
Перспективы (5)
AI-изируй то и это: DX, фронтенд и все, все, все..
Хотите узнать, как искусственный интеллект может трансформировать работу фронтенд-разработчика? Этот доклад раскрывает, как ИИ помогает:
• генерировать фронтенд код из скриншотов интерфейсов;
• автоматизировать написание юнитов и интеграционных тестов;
• упрощать миграции между версиями фреймворков;
• создавать стор-модули, локализации и даже документацию;
• а еще рефакторить и не только.
Я поделюсь реальными примерами использования инструментов вроде Cursor, Codeium и Windsurf, расскажу о внедрении ИИ в повседневные задачи и о том, как это уже меняет фронтенд. Также обсудим, зачем и как разворачивать модели on premise, их преимущества и недостатки.
Доклад принят в программу конференции
Как с помощью Document PictureInPicture выйти за рамки браузера
Исследуем API Picture-in-Picture в Chrome: как выносить за пределы браузера не только видео, но и любой (почти) контент - текст, графики, чаты и даже интерактивные элементы
Доклад принят в программу конференции
CSS Anchor Positioning: упрощаем разработку связанных друг с другом элементов
При разработке интерфейсов нам требуется уметь создавать элементы, которые будут связаны друг с другом. Например, иконка и текст тултипа или селектбокс и выпадающий список.
При этом нам важно, чтобы связанность и видимость элементов сохранялась при изменении вьюпорта, скролла или взаимодействиях пользователя с интерфейсом.
Обычно для реализации подобного поведения нам необходимо использовать JavaScript.
Однако теперь это необязательно благодаря новой фиче в CSS.
В докладе расскажу про CSS Anchor Positioning и как с его помощью упростить разработку связанных друг с другом элементов.
Доклад принят в программу конференции
Что там с React Compiler
В докладе расскажу о том, что происходит под капотом React Compiler, можно ли полагаться на автомемоизацию компонентов, насколько гибко можно управлять работой этого инструмента и какие нюансы и подводные камни нужно будет учесть, если вы решитесь подключить его в свой проект.
Доклад принят в программу конференции
Веб-компоненты — да это ж круто!
В докладе покажу, как может выглядеть современная разработка фронтенда без VDOM с использованием веб-компонентов и фреймворка lit.dev.
Поговорим про:
- Области применения веб-компонентов: SPA, виджеты, UI-kit'ы. Универсальность веб-компонентов и их совместимость вне зависимости от используемого стека.
- В чем преимущество веб-компонентов перед фреймворками из большой тройки? Как они влияют на mindset разработчика?
- Нюансы работы с ShadowDOM.
- Ограничения технологии: SSR, доступность, использование в формах.
Доклад принят в программу конференции
Производительность (6)
Утечки* NextJS. Расследование на миллион
Не справляетесь с безграничным потреблением ресурсов в NextJS при использовании картинок? Надежда на сообщество Open Source разработчиков фреймворка угасла? После этого доклада вы избавитесь от всех страданий!
Я расскажу, как мы столкнулись с утечками памяти в NextJS из-за модуля оптимизации изображений и первыми решили проблему, вызванную модулем оптимизации изображений. Мы прошли весь путь от локализации проблемы до разработки open source решения и разработали утилиту next-image-cache-cleaner, которую вы можете переиспользовать у себя. В ходе доклада вы научитесь:
- Оптимизировать потребление ресурсов NextJS приложений.
- Оперативно локализировать проблемы, которые не имеют явных и прозрачных решений.
- Сделать показатели мониторинга ресурсов достоверными.
Доклад принят в программу конференции
Нативные расширения в Node.js: когда JavaScript уже не справляется?
Мы привыкли, что JavaScript справляется со всем, но это не всегда так. Как только возникает задача ускорить вычисления, работать с железом или файлами, на сцену выходят нативные расширения. Но как их правильно писать в 2025 году?
В докладе разберем, как устроены нативные модули в Node.js и когда без них не обойтись, посмотрим на реализацию собственного нативного модуля с нуля, и ответим на вопрос, насколько актуален node-gyp в 2025 году и какие у него есть альтернативы.
Доклад принят в программу конференции
Дискуссия не доклад_AI в SDLC риски и ошибки
Год назад мы уже обсуждали внедрение AI в производственный процесс: https://conf.ontico.ru/lectures/5495369/discuss
Поигрались, насмотрелись, сделали выводы. Для чего нужны мы руководители? Правильно, чтобы говорить о рисках.
Вот и теперь хочется поговорить о рисках и ошибках внедрения AI в SDLC.
Доклад принят в программу конференции
Web Vitals не хватило: что мы измеряем, чтобы понимать реальную производительность Сбербанк Онлайн
Что происходит с производительностью, когда у тебя сотни модулей, микрофронты, отдельные команды на каждый крупный блок, и всё это работает в общем приложении, которым ежедневно пользуются миллионы людей?
В этом докладе я расскажу, как мы выстраивали систему измерения производительности в Сбербанк Онлайн, чтобы понимать реальную картину.
Web Vitals — это только начало: пришлось внедрять собственные метрики, отслеживать поведение отдельных компонентов и делать замеры не на синтетике, а в реальном продакшене.
Поделюсь, как мы справлялись с техническими и организационными трудностями: изоляцией микрофронтов, разными уровнями зрелости команд.
Расскажу, какие инструменты оказались действительно полезными, что автоматизировали, и какие ошибки не хотим повторять.
Доклад принят в программу конференции
Compression Dictionary Transport, или как пожать весь фронтенд в 5 раз
Расскажу про новый стандарт сжатия, который только-только начал затягиваться в браузеры. Будет немного теории, чуть-чуть практики на C и конечно же инструкция как внедрить это в ваших проектах
Доклад принят в программу конференции
Рецепт консистентного интерфейса: Lane к приручению Concurrent Mode
Иногда интерфейс начинает вести себя неожиданно: компонент обновляется, но получает устаревшие данные, или часть приложения перестаёт рендериться под нагрузкой. С такими эффектами я столкнулся при разработке корпоративного чата.
Оказалось, дело в приоритизации обновлений в React: он может отбрасывать низкоприоритетные изменения, что приводит к tearing (разрывам интерфейса). В докладе проведу разбор реального кейса: обсудим работу React под капотом и рассмотрим, как устроены lanes и concurrent rendering.
Доклад принят в программу конференции
Технологии (7)
Универсальный API-пакет на основе tRPC: от идеи до реализации
Поговорим о подходе с использованием инструмента TRPC https://trpc.io/, почему данный подход удобен, что такое End-to-end typesafe API. И как сделать свой собственный провайдер который позволит шарить логику в рамках проекта.
Введение в проблему
1. Дублирование кода
2. Сложность типизации REST
3. Интеграция с разными провайдерами БД
Архитектура пакета
1. tRPC-роутеры
2. Абстракция над БД
3. Zod-валидация
Преимущества подхода
1. Единая кодовая база
2. Автоматическая типизация
3. Гибкость (БД провайдеры)
4. Меньше boilerplate-кода
Пример приложения
1. Приложение Express + React SPA
2. Прототипирование
Ограничения и подводные камни
1. Не подходит для публичных API
2. Привязка к TypeScript
3. Сложности с кэшированием
Заключение
1. Упрощаем жизнь разработчикам
2. tRPC — это не замена REST
3. Ссылка на GitHub
Доклад принят в программу конференции
Как пройти в библиотеку (компонентов и стилей)?
Поговорим о пути создания интерфейса от момента MVP до запуска полноценного проекта. О том, когда нужно использовать библиотеку стилей и компонентов из open-source, а когда пилить своё. Если делаете своё, то как настроить флоу так, чтобы разработка нового не ломала старое. А если проектов много, но они плюс-минус одинаковые? А если у заказчика строгий брендбук и жёсткие правила? Можно ли брать готовую библиотеку или надо пилить что-то своё?
Доклад принят в программу конференции
ML starts, front ends: как ИИ атакует и спасает разработку
Атаки на цепочку поставок становятся причиной проникновения в компанию, которая занимается разработкой продукта. Манипулирование зависимостями в SDLC позволяет злоумышленникам массово получать доступ к рабочим станциям разработчиков, интеллектуальной собственности и дальше распространять вредоносный код. Использование LLM усиливает этот тренд и открывает новые возможности для атак.
Мы изучили нетривиальные векторы проникновения в разработку, которые открывают ML-модели. В докладе на примере реальных кейсов мы рассмотрим эффективные тактики и инструменты атакующих. В результате определим практические меры, позволяющие разработчику снизить риски для конвеера разработки. А также рассмотрим, как в этой задаче им помогает и мешает LLM.
Доклад принят в программу конференции
Динамические AMP-emails
В докладе мы подробно разберём, как работают динамические AMP-emails с точки зрения пользователя. Погрузимся в особенности HTML-разметки AMP, научимся создавать простые компоненты, отправлять POST и GET-запросы прямо из письма, обрабатывать ответы сервера и работать с состоянием (state). Мы посмотрим, как объединение состояния и сетевых запросов превращает обычное письмо в полноценное мини-приложение. Также обсудим процесс отправки AMP-email'ов, требования к отправителям (whitelist Google), поддержку со стороны почтовых клиентов и существующие ограничения технологии.
Доклад принят в программу конференции
«Давай поиграем со шрифтами»
По статистике Веб-альманаха за 2024 год 87% сайтов в интернете используют веб-шрифты. При этом загрузить шрифт так, чтобы не съесть весь мобильный трафик пользователя, страничка не прыгала, а идеи дизайнеров не разбивались о суровую реальность рендеринга в браузере, всё ещё не просто.
В докладе я покажу, как готовить и подключать на сайт шрифты, что умеет CSS для работы с типографикой и почему для Core Web Vitals так важно работать со шрифтами правильно.
Доклад принят в программу конференции
Деревья и коробки
Распространено мнение, что CSS придает внешний вид html-элементам. Это не совсем верно. Он оперирует не блоками, которые вы видите в разметке, но боксами, сгенерированными на их основе.
В докладе расскажу, как он их генерирует, какие они бывают и почему про это полезно знать.
Доклад принят в программу конференции
PWA Сбербанк Онлайн
Зачем мы пошли в 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.
Доклад принят в программу конференции
Дизайн (2)
From Discovery to Delivery: Влияют ли исследования на разработку и можно ли это измерить?
Принято считать, что исследования нужны, важны, влияют на траекторию развития продукта, а значит на происходящее в разработке. Но будем честны, не всегда очевидно, в чем именно выражается это влияние и точно непонятно как его измерить. Разработчику может казаться, что исследования — это причуда бизнес-команды, не связанная с его задачами напрямую. В рамках доклада я покажу эту связь и расскажу о ценности исследований для команд разработки:
— Как исследования влияют на технические задачи разного типа: от инфраструктурной рутины до инноваций.
— По каким метрикам можно оценить влияние исследования на задачи разработки.
— Как по доле UX-обоснованных задач в бэклоге определить UX-зрелость вашей команды.
— И наконец в чем польза от исследований не для продукта, а для разработчика.
Доклад принят в программу конференции
Реинкарнация эвристик Якоба Нильсена в интерфейсе разработчика. Жили, живы и будут жить.
Side effects:
1) Несколько раз помусолим эвристики с разных сторон, часть из них точно отложиться в голове
2) Соберу много практических примеров и проваледирую у разработчиков и комитета, посмеемся над типовыми ошибками, чтобы их больше не делать
3) Будет много шуток
Ремарка: Хотя современные IDE, всё больше похожи на UI для написания кода, который стараеться помочь и предотвратить ошибки, автор любит сравнивать их с написанием текста в блокноте.
Также автор достаточно самокритичен страдает простой формой Дислексиии и сложной СДВГ. Никогда не писал идеальный код и достаточно самокритичен. Почти все свободное время тратит на размышления про более интерактивные и визуальные способы программирования и изучение новых frameworks.
Список эвристик от Nielsen Norman Group:
https://www.nngroup.com/articles/ten-usability-heuristics/
Инновационная часть доклада (набросок):
Ниже распишу примеры match эвристик на опыт разработчика (в большей степени Typescript/JS)
1. Понятный статус системы → REPL и realtime time debug, статусы подлючения к серверу и git, minimap для навишации по коду, консоль для отображения статуса не видимых в UI действий и многое другое)
2. Соответвие системы и миру пользователя → использовать названия переменных, свойств и стилей (camelCase, snake-case и прочие правила), термины и подходы принятые в конкретной среде разработки (напримере JS), а не как тебе вздумается
3. Контролиремость и свобода выбора (разработчики всегда хотят больше контроля) → Undo/Redo, Git Versions: Review, Restore и пр.
4. Консистеность и стандарты → Cистемность однотипных решений, DX Patterns, (проектируем одинаковые вещи одинаково). Typescript для описания в одном месте. того что используется в нескольких. Interfaces для как способность классов (Drawable, Iterable и пр.)
5. Предотвращение ошибок системы и пользователя → подсветка гарантированных ошибок перед выполнением кода, Typescript для гарнтирования прафильного ввода текст кода, отображение ошибок вместо выполнения программы, ошибки линтера, debug для поиска ошибок в верстке и коде и пр.
6. Уменьшение ментальной нагрузки →
показывать имена функции/метода в sticky headers чтобы не зопоминать в каком месте кода ты сейчас, уменьшать количество текста кода и дулированные обращения (локаничность), показывать выпадающие списки для типизированных свойсств (чтобы не запоминат и не ошибиться), быстрое условное присвоение c = bool? a : b и пр., JSX для как удобный язык разметки, state chart и пр.
7. Уменьшение механической нагрузки → горячие клавиши по выделениям, поиску, запуску, дебагу, переключению между окнами с кодом и отображением, ускорение code review и написания кода в нескольких местах (мне кстати до сих пор ломает мозг)
8. Приоритезация и систематизация информации, минимализм → расцветка кода для лучшего понимания сущности, табуляция (нужного зразмера :) для иерархии и вложенности, локаничные комментарии в нужном месте, настройки шрифта и стиля текста (для себя любимого :) ,реактивные фреймворки, которые не требуют императивного описания действий для обновления и др. декларативные паттерны чтобы не запутаться в логикеи пр.
9. Понятность при информировании пользователя → текст, ошибки такой, что пожно понять в чем проблема, а не сразу Stack Overflow или Github issues (хотя в разработке как раз с этим плохо всё). Source map для минификации, чтобы понять где это был (а если отломалося source map, чинишь, а надо релизить)?
10. Помощь, onboarding и документация → документацию легко найти, она понятная и простая, есть разделы с чего начать и пр. соответвует стандартам и лучшим практикам, описаны варианты свойств и их типы, песочница для DS c перечнем возможностей и возмодностью применить варианты на лету и пр.
Такая работа ранее не делалась, нужно будет мне еще глубже копать и собрать практические примеры.
Примеры экзистенциальных выборов при проектировании интерфейса:
1) Disbales vs Hide - вечный спор (Disable только когда пользователю понятно как сделать enable. Hide - только когда очевидна смена контекста - новый диалог, явная смена selection).
2) Дублировать действие в двух местах или нет. Например кнопка [Close] и X в модальном диалоге (только когда очень высокое модальное окно. Дублировать плохо).
3) Потеря данных (как blocker баг) - это в т.ч. когда пользователь совершил случайно типовые действия, которые привели к потере (расскажу примеры потери данных при реализации черновиков нашего мессенджеры Squadus)
и др.
О себе:
Опыт выступления (года 3 не выступал, но постоянно делаю это в роли дизайн-директора внутри компании МойОфис):
Data Art Meetup: "Парное review. Управляемая и дружная команда без Bottleneck"
https:/youtu.be/wi7I3D0BMOE?t=2630
Профсо UX : "Кроссплатформенная унификация. На что обратить внимание и как развивать большой и сложный продукт" https:/vimeo.com/267044787 (самы первый доклад)
Обучающие видео про плагин Design System Organizer на английском:
https://www.youtube.com/watch?v=XtRfPe-vEXU
Доклад принят в программу конференции
Коммуникация и процессы (3)
Наставничество в кайф: как учиться самому, обучая джунов
В слове “наставничество” сразу же чувствуется груз ответственности. Обучение молодого специалиста с нуля вызывает страх. Это и не удивительно, особенно если у наставника до этого не было такого опыта.
Однако наставничество не обязательно является скучным, трудным или бесполезным для наставника. При правильном подходе его можно превратить в увлекательный процесс, который помогает обеим сторонам расти и получать удовольствие.
В этом докладе я поделюсь своим опытом работы с джунами. Я расскажу о принципах, которые помогают сделать процесс наставничества приятным и осмысленным, и покажу, как менторство может прокачать не только ученика, но и самого наставника. Обсудим ошибки, страхи и самые частые затыки — с примерами из жизни.
Доклад принят в программу конференции
Сломанный найм: кто виноват и что с этим делать
Расскажу о том как сломан найм в IT — от завышенных требований и фальсификации опыта до шаблонных алгоритмических секций и субъективных HR-фильтрах. А в конце мы проговорим про проверенные практики — от оплачиваемых пилотных проектов до blind hiring — чтобы сделать найм честным и результативным.
Доклад принят в программу конференции
Эффективное прохождение Performance Review
Вы наверняка слышали выражение Performance Review — многие его боятся, другие же считают простой формальностью. Но что если я вам скажу, что, на самом деле, это мощный инструмент развития, если подходить к нему осознанно. Как получить реальные карьерные перспективы, а не набор шаблонных фидбэков? Как структурировать результаты своей работы так, чтобы они были убедительными для менеджеров? В этом докладе мы разберём, как готовиться к перформанс-ревью, какие метрики и примеры стоит приводить, как объективно оценивать свои достижения и презентовать их так, чтобы они работали на вас.
Но успешное ревью — это не только про индивидуальные достижения, но и про вклад в команду. Мы обсудим, как перформанс-ревью пересекается с код-ревью, менторством, процессами онбординга и управления знаниями, и как всё это можно встроить в работу так, чтобы перформанс-ревью не было разовым стрессом, а логичным завершением системной работы. Разберём практические примеры, которые помогут вам лучше оценивать себя и свою команду, а тимлидам — делать ревью полезным инструментом для развития, а не бюрократической нагрузкой.
Доклад принят в программу конференции
AI во фронтенде (2)
ИИ-агенты: новая эра фронтенда и трансформация роли разработчика
Генеративный ИИ переопределяет принципы разработки, смещая фокус с написания кода на проектирование систем. ИИ-агенты становятся ключевым инструментом автоматизации бизнес-процессов, персонализации пользовательского опыта и создания интеллектуальных решений. Доклад посвящен практическому применению ИИ-агентов, их архитектуре, а также адаптации разработчиков к новым реалиям.
Доклад принят в программу конференции
Vibe coding in frontend
Что такое вайбкодинг
База промптов и актуальных llm
Принципы работы с аи ассистентом (подход, мышление, структурность)
Как создавать мвп и цикл этапов
Практический пример создания приложения
Окружения и сервисы
Доклад принят в программу конференции