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

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

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

Допустим, теперь задача и команда появились, но как узнать что они должны делать? — Специально замедлить сервис.

А как замедлять? А насколько замедлять? А что замедлять? Тот же Web Vitals состоит из нескольких метрик, и целенаправленное ухудшение каждой из них — это отдельная техническая задача. Должно ли это быть смещение всего распределения на константу или новая случайная величина?

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

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

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

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

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

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

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

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

Программист пишет — машина исполняет. Но только ли машина? Что происходит, когда человек читает код? Как он его читает?

Сборщики, препроцессоры, транспиляторы делают код удобным для машин. А что сделает его удобным для людей? Какой код, вообще, удобен для человека? Ответ должны давать SOLID, KISS, DRY, дизайн-паттерны, но их изучение — сплошное непонятное занудство.

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

Но именно такой код приводит инженера к развитию.

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

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

В продуктах Циан нам нужно делать изменения быстро, просто и гибко сразу на трёх платформах — Web, iOS и Android. К сожалению для нас, классический подход с разработкой и релизами на нескольких стеках занимает много времени и требует большой команды под каждую фичу. Все готовые проекты вынуждены проходить через длительный релизный цикл приложений, и это негативно влияет на time to market. Чтобы решить эту проблему, мы выбрали архитектуру Backend-Driven UI. Такой подход позволяет поставлять пользователям любые изменения в приложении намного быстрее, минуя обновления из магазинов приложений, а также создавать более гибкий UX.

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

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

Вот несколько критериев, которым должно было соответствовать решение:
1. Сервер раздаёт только статику, либо он очень «тонкий».
2. Все данные хранятся только на стороне клиента.
3. Использовать приложение можно одновременно с нескольких устройств.
4. Можно взаимодействовать с другими пользователями.

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

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

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

Но на практике всё бывает не так радужно. Нередко рефакторинг ухудшает качество кода. Я тоже делал такие рефакторинги.

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

Дано:
* 100+ микросервисов,
* 21 независимая команда,
* 10к+ зависимостей.
Кто в лес, кто по дрова.

Как за этим следить? Как обеспечить консистентность?

Решение:
Автоматизируем проверку ВСЕГО.

В докладе поговорим про:
* eslint,
* FrontOps / DevOps,
* метаинформацию,
* istio, метрики оркестрации,
* performance-метрики,
* костыли,
* ручные тяги.

С ростом продукта наш фронтенд становился все более сложным и громоздким. Его архитектура постепенно теряла гибкость, в то время как затраты на её поддержку неуклонно возрастали.

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

Когда несколько команд разработки занимаются одним проектом, неизбежно возникает вопрос, как наладить их взаимодействие. Необходимо, чтобы это было безболезненно, прозрачно и занимало как можно меньше времени. Использование Contract First-подхода на основе OpenAPI-схем решило для нас эту проблему.

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

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

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

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

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

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

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

Изначально DOM в браузере задумывался для простого чтения данных из HTML. Так как можно было изменить лишь страницу целиком, данные для отображения готовили заранее или на лету на сервере, DOM не проектировался под возможности динамического изменения на стороне клиента. Но web активно изменяется, растет, и, чтобы как-то нивелировать проблему просадки производительности, разработчики фреймворков стали придумывать свои обвязки.

В докладе расскажу, почему Virtual DOM морально устарел, какие существуют аналоги, например, Glimmer, Incremental DOM, и как фреймворки достигают производительного рендеринга без "anyword DOM".

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

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

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

Расскажу о фреймворке MediaPipe для машинного обучения, рассмотрим, какие модели входят в его состав, и разберем реализацию приложения с применением модели распознавания ключевых точек человеческого лица — напишем игру по мотивам Fruit Ninja, в которой можно управлять клинком движением головы!

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

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

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

Посмотрим, вырос ли API за все это время настолько, чтобы мы могли использовать только Vanilla JS, не потеряв тот комфорт, к которому привыкли?

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

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

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

Я решил на собственном опыте выяснить, как gRPC покажет себя в JavaScript, и разработал прототип веб-приложения для интернет-магазина. Что из этого вышло, расскажу в докладе:
* перечислю основные преимущества gRPC;
* покажу, как создать простой gRPC-сервер и клиента на Next.js и что будет, если применить протоколы, в основе которых лежит стриминг;
* подробно рассмотрю Protocol Buffers 3 и то, как быть с отсутствием полноценной поддержки HTTP/2 в браузере;
* поделюсь рекомендациями по использованию gRPC в Node.js.

Статистика браузера Chrome показывает: каждый десятый переход на компьютере и каждый пятый на мобильном устройстве ведёт на предыдущую или следующую страницу. При переходе необязательно загружать страницу заново, он может быть мгновенным. Для этого в браузере существует нативное решение — BFCache, специальный кэш для перехода назад и вперед.

Из доклада вы узнаете, как включить BFCache на своём сайте на примере Яндекс Маркета. Разберём проблемы и особенности, затронем тему тестов и метрик.

Основные тезисы:
* микрофронтенд: логичное архитектурное развитие индустрии;
* принципиальные различия и сходства двух подходов;
* build time vs runtime в 2023: почему билд тайм все еще актуален.

В React 18 появилось множество интересных изменений и функций. Вероятно, вы уже много слышали об этом, и на то есть веские причины, ведь появился целый спектр увлекательных изменений, которые привнесут свежий ветер в мир фронтенд-разработки. Эти изменения, предоставляют значительные преимущества и новые способы подхода к созданию пользовательских интерфейсов.
И тут я говорю про:
* Streaming SSR,
* Server Components,
* Suspense,
* селективную гидратацию.

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

Представьте, что у вас стоит задача в минимальные сроки сделать приложение на Android практически полностью без знаний оного. Оказывается, что подход Kotlin + Jetpack Сompose очень похож на то, что предлагают React и Typescript для веб-разработки, поэтому освоить его под силу любому фронтенд-разработчику.

В докладе я расскажу, почему подходы так похожи, и приведу примеры, когда выгодно использовать для мобильной разработки Kotlin и Jetpack Compose, а не что-то другое. И наконец с помощью мини-мастер-класса и демонстрации реального написанного за месяц приложения объясню, почему нативные приложения все ещё торт.

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

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

«Здравствуйте, меня зовут Константин, и я кодозависимый».

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

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

В чем отличие технологичной разработки от "давай-давай"-подхода или как перестать кодить и начать программировать.

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

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

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

В жизни каждого разработчика наступает тот самый момент "X"...
... когда его зовут на встречу с клиентом, заказчиком, партнером или просто с соседней командой.

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

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

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


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

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

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

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

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

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

Так прошлым летом появился “Фима” — мой собственный сервис для планирования бюджета. Прошел год, первый грузовик сомнений разгружен, а накопленный опыт создания пет-проекта и гайд для повторения сконцентрированы в 40 минутах доклада.

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

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

Каждый код уникален. Несмотря на работу линтеров, даже спустя несколько лет вы с уверенностью можете сказать, что это писали вы, а вот это — разработчик Иннокентий. Даже если не помните, что это была за задача и как и зачем вы этот код писали.

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

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

* Что такое WASM и как он может помочь обычному разработчику.
* На чем писать и как компилировать WebAssembly.
* Реальные кейсы использования WASM на проекте.
* WASM в жизни, лучшие практики и для чего точно не стоит его использовать.
* Будущее WebAssembly, вектор развития технологии и чего от нее ждать.

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

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

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

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

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

В программе:
* парное непрограммирование,
* GPT in the dark,
* ChatReview.

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

Но если мы хотим сделать действительно сложную и красивую анимацию, нам могут понадобиться более мощные инструменты для motion-дизайна вроде After Effects.

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

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

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

* Сначала поговорим про скролл. Но не простой скролл сверху вниз, а скролл, к которому привязаны движения камеры или движения персонажа или объектов на экране.
* Потом обсудим, как можно сделать динамическое освещение в интерфейсе, не используя никакие источники света в 3D-сцене. А также пара слов про Redshift и Octane Render. Что из них лучше и почему.
* Третьим пунктом покажу один очень простой и дешевый способ сделать из простой фотки трехмерную сцену и поразить непритязательного заказчика. Сами делали так сто раз, и каждый раз срабатывает!
* Дальше разберем рейкастинг. Он нужен для того, чтобы создавать точки интереса в трехмерных сценах на сайте. Когда, например, у вас вместо главной карта города глубиной, и по ней нужно разбросать метки с выпадающим меню. Вот разберем, как это реализовать, сколько объектов, вообще, можно располагать на одной странице и насколько этот прием ресурсоёмкий.
* А на десерт Geometry Instancing — чтобы понять, как прорывная оптимизационная методика из геймдева 2004 года может применяться в сайтах сегодня. Разберем типы шейдеров и попробуем технологию на прочность. Для этого будем добавлять в сцену клонированные объекты до тех пор, пока она не сломается.

Если останется время и будет настрой, поделюсь парой баек о том, как слить дизайн, 3D-продакшн и фронтендеров в один работоспособный юнит и не сойти с ума.

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

Предметно рассмотрим текущие возможности Figma: кастомные hot key, новый функционал в прототипировании, крайне полезные плагины для ускорения работы. Возможно, закроем ваши годовые цели нажатием одной кнопки. Подключим библиотеку иконок через Figma API к вашей ДС в storybook.

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

* Докажу, что доступность нужна не только людям с особыми потребностями.
* Объясню, почему доступность важна для бизнеса и как она влияет на доходы.
* Подсвечу, как всё устроено в Контуре: у нас около 70 продуктов и команд разработки, мы делаем продукты для бизнеса, а наши фронтендеры мало знают про доступность.
* Разберу, как проводить аудит продуктов, использовать библиотеку контролов и объясню роль фронтендеров в развитии доступности.
* Поделюсь историей, как мы столкнулись с овердоступностью и что с этим делали.

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

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

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

Веб быстро развивается, в нём постоянно появляются новые фичи. Container Queries, Cascade Layers, новые цветовые пространства и многое другое меняют наше представление о современной верстке. Это уже не тот CSS, который писали 3, 5 или 10 лет назад.

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

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

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

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

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

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

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

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

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

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

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

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