- Определение веб-скрапинга и его роль в современном бизнесе, включая этические аспекты и правовые рамки использования данных.
- Обзор успешных бизнес-кейсов применения веб-скрапинга: агрегаторы цен, системы мониторинга конкурентов, маркетинговые исследования.
- Методология предварительного анализа веб-ресурсов: исследование API, изучение структуры сайта, выявление механизмов защиты.
- Стратегии выбора между прямыми HTTP-запросами и эмуляцией браузера в зависимости от уровня защиты целевого ресурса.
- Базовый инструментарий Python для веб-скрапинга: requests, beautifulsoup4 как основа для построения HTTP скраперов.
- Продвинутые инструменты для эмуляции браузера: Selenium, Playwright, undetected-chromedriver для обхода детектирования автоматизации, Camoufox для эмуляции реального браузера.
- Специализированные сервисы для обхода защит: ZenRows для автоматического обхода блокировок, Residential Proxies для обхода IP-ограничений, Capsolver для решения CAPTCHA.
- Построение масштабируемой архитектуры скрапера: управление сессиями, обработка ошибок, механизмы повторных попыток.
- Работа с прокси-серверами: стратегии ротации IP-адресов, управление пулом прокси, обход географических ограничений.
- Оптимизация производительности: управление задержками, параллельная обработка, распределение нагрузки через очереди.
- Соблюдение этических норм при скрапинге: уважение robots.txt, установка разумных ограничений на частоту запросов, минимизация нагрузки на целевые серверы.
- Практические решения для типовых задач: построение сервиса для проверки баланса подарочных карт.
- Обработка и хранение собранных данных: структурирование, очистка, обновление и поддержание актуальности информации.
- Мониторинг работы скрапера: отслеживание ошибок, производительности, качества собираемых данных.
- Интеграция скрапинга в существующие бизнес-процессы: автоматизация принятия решений, обогащение данных, аналитика.

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

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

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

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

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

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

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

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

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

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

Вместе построим роутинг, который работает на ts. Не используя никаких сторонних библиотек, имея в руках только react-router-dom, соберем систему, при которой все параметры и урлы станут строго типизированными. Долой строки!

Введение - Освежим знания по LLM.
Развернем Ollama, узнаем как с ней работать локально
Подготовим RAG, выберем векторную бд и реализуем кейс
Поработаем с инфраструктурой чтобы хостить свои модели
Поговорим про Агентов и сделаем мини- имплементацию на node js + mq

В конце сделаем конкурс чей агент справился лучше с заданием

Требования в вшопу
- с собой взять ноутбук желательно м1 и больше, если нет ничего страшного будут подготовлены облачные машины
- установленный docker десктоп
- установленный node js
- хорошее настроение

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

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

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

Какая была задача. Для чего Директу приложение?
Выбор технологии. Какие варианты? Почему именно WebView?
Как работает приложение
Пуш-уведомления
Другие технические вызовы. Избавляемся от "вебности" в приложении
Как устроен релизный цикл

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

«Плох тот солдат, который не мечтает стать генералом», — гласит народная мудрость.

«Плох тот разработчик, который не мечтает стать СТО», — перефразировал я эту фразу.

Я в своей работе неоднократно встречал убеждение, что техлиды и более высокие технические менеджеры — это бывшие бекендеры, а фронтендерам наверх дорога закрыта.

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

Frontend-приложения могут иметь сотни транзитивных зависимостей, Supply Chain-атаки в NPM происходят все чаще. Js-код минифицируется при сборке, а браузер пользователя всегда является "слепой" зоной с т.з. безопасности. Поговорим об актуальных рисках, угрозах для frontend-приложений, разберем известные инциденты. Рассмотрим, как сделать FrontSecOps в DevSecOps, совместить E2E-тесты с безопасностью и прийти к Secure By Design

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

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

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

В этом докладе я расскажу:

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

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

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

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

Методология DDD(Domain Driven Design) появилась достаточно давно, а в русскоязычном сегменте ИТ начала набирать популярность во второй половине 10х годов. Больше всего, конечно, эту методологию используют в бэкэнде, и даже считают, что в соответствии с этой методологией можно писать код.
Я хочу показать, что методология !== технология, и рассказать, как использовать DDD на фронтэнде, как сделать вашу жизнь в команде лучше, понятнее и дружнее с помощью небольшого изменения ментальных конструкций, которыми вы оперируете.

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

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

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

Сегодня многие компании сталкиваются с задачей параллельной разработки разных модулей и сервисов, которые необходимо интегрировать в единое приложение. Мы поговорим о подходе Module Federation в Webpack 5, который помогает реализовать микрофронтенды и плагинную архитектуру. Доклад покажет, как этот подход позволяет ускорить выпуск новых функций, снизить риски версионных конфликтов, а также обеспечить независимую работу распределённых команд. Мы рассмотрим основные технические детали для успешного внедрения: конфигурацию Webpack, управление зависимостями, изоляцию и совместное использование библиотек. Вы получите план интеграции Module Federation и узнаете, какие сложности могут возникнуть в продакшене.

Как заставить команду писать красивый (поддерживаемый, понятный) код

1. Введение: зачем писать красивый код?
• Почему качество кода важно для команды и компании?
• Примеры проблем, которые возникают из-за разного кода.
• Краткий обзор инструментов и подходов.
• Почему стандартизация полезна для команды и компании?
2. Написание собственных правил для линтера
• Почему стандартных правил может быть недостаточно?
• Как писать собственные правила:
• - Примеры в rules для (ESLint).
• - Использование AST (Abstract Syntax Tree).
• Как внедрить собственные правила в проект.
3. SonarQube: мощный инструмент для анализа кода
• Что такое SonarQube?
• Какие метрики предоставляет SonarQube:
• - Code smells.
• - Уровень покрытия тестами (test coverage).
• - Технический долг.
• - Уязвимости и ошибки.
• Примеры пользы для бизнеса и разработчиков.
• Как подключить SonarQube к проекту:
• - Развертывание на сервере.
• - Интеграция с CI/CD.
• - Подключение к IDE.
4. Границы жесткости стандартов
• Можно ли запретить всё?
• Преимущества и недостатки жестких правил:
• - Упрощение онбординга новых разработчиков.
• Рекомендации: где стоит быть гибким, а где — строгим.
• Почему важно вовлекать команду в обсуждение стандартов.
5. Кейсы и примеры: демонстрация на практике
• Реальный пример линтера с кастомными правилами.
• Анализ реального проекта через SonarQube:
• - Выявление проблем.
• - Рекомендации по их устранению.
• Обсуждение: как это улучшило код и взаимодействие команды.
6. Заключение: путь к красивому коду
• Резюме: инструменты и подходы.
• Советы для внедрения:
• - Начните с небольших изменений.
• - Слушайте команду.
• - Делайте код-ревью частью культуры.

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

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

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

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

Проходили — знаем! Приходите послушать реальный опыт трансформации команды Яндекс Еды: расскажем, как мы прошли путь от монолита к микрофронтам, с какими сложностями столкнулись и какие технические решения помогли их преодолеть.

Хотите узнать, как искусственный интеллект может трансформировать работу фронтенд-разработчика? Этот доклад раскрывает, как ИИ помогает:

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

Я поделюсь реальными примерами использования инструментов вроде Cursor, Codeium и Windsurf, расскажу о внедрении ИИ в повседневные задачи и о том, как это уже меняет фронтенд. Также обсудим, зачем и как разворачивать модели on premise, их преимущества и недостатки.

Исследуем API Picture-in-Picture в Chrome: как выносить за пределы браузера не только видео, но и любой (почти) контент - текст, графики, чаты и даже интерактивные элементы

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

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

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

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

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

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

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

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

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

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

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

Мы привыкли, что JavaScript справляется со всем, но это не всегда так. Как только возникает задача ускорить вычисления, работать с железом или файлами, на сцену выходят нативные расширения. Но как их правильно писать в 2025 году?
В докладе разберем, как устроены нативные модули в Node.js и когда без них не обойтись, посмотрим на реализацию собственного нативного модуля с нуля, и ответим на вопрос, насколько актуален node-gyp в 2025 году и какие у него есть альтернативы.

Год назад мы уже обсуждали внедрение AI в производственный процесс: https://conf.ontico.ru/lectures/5495369/discuss
Поигрались, насмотрелись, сделали выводы. Для чего нужны мы руководители? Правильно, чтобы говорить о рисках.
Вот и теперь хочется поговорить о рисках и ошибках внедрения AI в SDLC.

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

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

Из доклада вы узнаете, как:

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

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

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

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

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

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

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

Иногда интерфейс начинает вести себя неожиданно: компонент обновляется, но получает устаревшие данные, или часть приложения перестаёт рендериться под нагрузкой. С такими эффектами я столкнулся при разработке корпоративного чата.
Оказалось, дело в приоритизации обновлений в React: он может отбрасывать низкоприоритетные изменения, что приводит к tearing (разрывам интерфейса). В докладе проведу разбор реального кейса: обсудим работу React под капотом и рассмотрим, как устроены lanes и concurrent rendering.

Альфа-Онлайн - веб-версия интернет банка с микро-фронтендной архитектурой. Рассмотрим следующие вопросы:
- Почему долгое время не было PWA для iOS и почему мы всё-таки к нему пришли?
- Что такое PWA и что потребуется, чтобы оно завелось?
- Какие основные фишки может дать PWA пользователю и где посмотреть что поддерживается на данный момент?
- Манифест и сплэш-скрины
- Расскажу про Safe-Area, какие возможности и проблемы мы получаем от полноэкранного режима - путь Альфа-Онлайна
- Затронем темы кук, пермишенов, кэширования в PWA, работы с файлами и другие вещи, с которыми неизбежно придётся иметь дело

Поговорим о подходе с использованием инструмента 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, а когда пилить своё. Если делаете своё, то как настроить флоу так, чтобы разработка нового не ломала старое. А если проектов много, но они плюс-минус одинаковые? А если у заказчика строгий брендбук и жёсткие правила? Можно ли брать готовую библиотеку или надо пилить что-то своё?

Пакетные менеджеры являются фундаментальной частью современного фронтенда, но их внутренняя работа часто остается “магией” для многих разработчиков. В этом докладе мы разберемся, как под капотом работают 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) Возможность оптимизировать свой рабочий процесс и повысить эффективность

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

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

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

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

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

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

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

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

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

В докладе мы подробно разберём, как работают динамические AMP-emails с точки зрения пользователя. Погрузимся в особенности HTML-разметки AMP, научимся создавать простые компоненты, отправлять POST и GET-запросы прямо из письма, обрабатывать ответы сервера и работать с состоянием (state). Мы посмотрим, как объединение состояния и сетевых запросов превращает обычное письмо в полноценное мини-приложение. Также обсудим процесс отправки AMP-email'ов, требования к отправителям (whitelist Google), поддержку со стороны почтовых клиентов и существующие ограничения технологии.

Распространено мнение, что CSS придает внешний вид html-элементам. Это не совсем верно. Он оперирует не блоками, которые вы видите в разметке, но боксами, сгенерированными на их основе.

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

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

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

Зачем мы пошли в 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.

Расскажу, как создать и использовать headless primitive используя новые возможность Angular Signal API. Какие есть схожие паттерны между Vue.js & React.
Это современная тенденция в мире Angular, где уже команда Angular/CDK подхватила ее в реализацию.

Принято считать, что исследования нужны, важны, влияют на траекторию развития продукта, а значит на происходящее в разработке. Но будем честны, не всегда очевидно, в чем именно выражается это влияние и точно непонятно как его измерить. Разработчику может казаться, что исследования — это причуда бизнес-команды, не связанная с его задачами напрямую. В рамках доклада я покажу эту связь и расскажу о ценности исследований для команд разработки:
— Как исследования влияют на технические задачи разного типа: от инфраструктурной рутины до инноваций.
— По каким метрикам можно оценить влияние исследования на задачи разработки.
— Как по доле 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

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

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

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

Расскажу о том как сломан найм в IT — от завышенных требований и фальсификации опыта до шаблонных алгоритмических секций и субъективных HR-фильтрах. А в конце мы проговорим про проверенные практики — от оплачиваемых пилотных проектов до blind hiring — чтобы сделать найм честным и результативным.

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

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

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

Что такое вайбкодинг
База промптов и актуальных llm
Принципы работы с аи ассистентом (подход, мышление, структурность)
Как создавать мвп и цикл этапов
Практический пример создания приложения
Окружения и сервисы

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

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

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

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