Разработка

В докладе затронем общие аспекты, что в принципе необходимо знать разработчикам крупных систем, и чем на самом деле занимаются инженеры в огромных проектах (спойлер: не пишут код). Заглянем во внутреннюю кухню ВКонтакте и посмотрим, какими инструментами мы пользуемся для разработки и деплоя нашей гигантской кодовой базы: PHPStan, KPHP, noverify, nocolor, Modulite, AdmStorm и ряд других. Пробежимся по бесчисленному множеству мелочей, которые необходимо учитывать в сервисах такого масштаба и о которых либо не думают, либо забивают в обычных стартапах.

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

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

Пытаясь понять причины его существования, вы открываете Pandora’s Box: бесполезных тестов оказывается много, а ваши уверенности в качестве продукта начинают трещать по швам.

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

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

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

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

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

Расскажем о том, как сделать отказоустойчивый кластер MySQL для высоконагруженного проекта, где на каждый сервер можно писать и читать одновременно и безопасно на основе Galera Cluster.

Мы разберем типовое web приложение со стороны backend на компоненты, определим категорию и зону ответственности этих компонентов и посмотрим на их составные части. Основой архитектуры будет использование паттерна Clean Arch, который хорошо себя зарекомендовал. Мы будем предполагать, что работа по выделению доменных областей проведена, стек технологий и сервисы для интеграции выбраны. Если посмотреть на уровни моделью декомпозиции [С4](https://c4model.com/), мы будем проектировать 3 уровень - диаграмму компонентов приложения.

Операционные системы нам кажутся уже устоявшимся миром, но это не так. Требования надежности и безопасности постоянно повышаются, и старые ОС такие как macOS, Windows и Linux здесь безсильны. На сцену выходят ОС на основе микроядра: безопасная операционка KasperskyOS от Лаборатории Касрерского, идущая на смену Андроида Fuchsia от Google и ветеран seL4. Но что такое микроядро и как оно устроено?

Давайте разберем что такое ОС в целом, как работают “монолитные” и новые микро-ядра. Что такое модель MILS. Заглянем под капот и разберемся с базовыми блоками на которых строятся современные микроядра. Разберем на пальцах такие основополагающие механизмы как: capability, message passing и конечно же что делает KasperskyOS более защищенной ОС.

Язык Swift - главный язык разработки мобильных приложений для iOS. Он был представлен 9 лет назад и за это время никогда не останавливался в развитии. Только в его пятой версии за последние годы появились макросы, некопируемые структуры, property wrappers и result builders, инструменты работы с многопоточностью, регулярными выражениями и много что еще. При этом многие новые фишки языка из-за все увеличивающегося темпа работы часто ускользают от программистов и не становятся частью ежедневной рутины.

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

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

Я расскажу о том, как мы в Cloud изменили стандартные подходы к проектированию приложения...

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

* какие боли несет в себе микросервисный подход;

* как не создать микросервисный монолит;

* оптимизации, оптимизации и еще раз оптимизации;

* как работать с консистентностью и Bus-фактором;

* как следить за качеством;

Приходите, скучно не будет.

Доклад основан на реальных событиях.

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

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

Внутри доклада подсветим вопросы:

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

2. Чистый код равно литературный код. Требования к написанию кода сильно изменились. Если раньше программисту было важно разбираться в том, как устроено “железо”, то сегодня во главе угла — умение чётко формулировать: насколько точно разработчик умеет выражать свои мысли, насколько код легко читать и воспринимать.

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

Практика:

— основные ошибки и проблемные моменты, которые часто встречаются на ревью.

— список рекомендаций по неймингу: подбор терминов (с примерами), внедрение политик по единообразному неймингу в компании и др.

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

- надо ли нам думать о надежности нашей системы и от чего это зависит

- как оценить надежность существующей системы

- почему надежность сложно добавить в существующую систему

- какие существуют принципы для проектирования надежных систем

- как выстроить процессы для ее достижения

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

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

Также мы рассмотрим технические детали работы с Git-сабмодулями, их плюсы и минусы, и проведем сравнение данного подхода с альтернативными методами.

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

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

В докладе будут затронуты такие темы как:

- Оптимизация изображений и других медиа файлов

- Оптимизация оптимизаторов картинок

- Виды рендеринга страницы и как их выбирать

- Ленивый паттерн (но не разработчик)

- Алгоритмы сжатия файлов

- Разделение кода

- Виды кэширования для различных задач

- Оптимизация данных для пререндеринга

- Оптимизация мультиязычных сайтов

И многое другое.

Мы знаем термин Web3 уже 9 лет. Мало кто не слышал о блокчейне или криптовалютах. Считается, что это новая эпоха развития Интернета, его третья версия.

Но готовы ли мы, как разработчики, к этой новой эпохе?

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

- Что такое Web3, чем он отличается от Web 2.0?

- Как написать Web3 приложение?

- Примеры Web3 приложений

- Что изменяется во фронтенд-разработке?

- Какие есть готовые решения / библиотеки (wagmi, web3)?

- почему стоит изучать алгоритмы

- как найти проблемы производительности и как они возникают

- какие архитектурные решения помогут нам справится с алгоритмической сложностью

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

Я расскажу, как мы разрабатываем свою библиотеку компонентов на основе хуков React Aria.

Как пишем доступные компоненты: от простых кнопок до монструозных календарей.

Как легко переопределить часть поведения, но оставить остальное нетронутым.

В докладе рассматриваются возможности чат-бота GTP как дополнительного инструмента для тестировщика. Будут приведены результаты исследования работы инструмента с требованиями и анализом текста с учетом предыдущих сообщений. Покажем прикладную составляющую на примерах: создание сценариев тестирования, генерации тестовых данных, работа с SQL запросами. Так же отдельный блок посвятим созданию автоматизированных тестов для UI и API с помощью чат бота. Поделимся своим опытом применения, преимуществами и ограничениями инструмента, с которыми столкнулись в работе.

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

Часть 1.

- Таймеры в HTML5: взгляд изнутри

1. Приветствие и краткий экскурс в тему

2. Что такое Realm

3. Что такое Environment и его связь с Realm

4. Кратко про Event Loop HTML5: как работает Macrotask Queue и как заблокировать Main Thread

5. setTimeout - алгоритм его работы

6. setInterval - алгоритм его работы и почему он плох для работы с анимациями

7. Почему важно использовать clearTimeout и clearInterval

8. Заключение, плавный переход к queueMicrotask

Часть 2.

- Из макро в микро: создаем асинхронный код с помощью queueMicrotask

1. Кратко про queueMicrotask

2. Кратко про Event Loop HTML5: как работает Microtask Queue

3. Как работает queueMicrotask - очень подробно

4. Кратко про requestAnimationFrame

5. Когда лучше использовать requestAnimationFrame вместо queueMicrotask

6. Кратко про requestIdleCallback

7. Когда лучше использовать requestIdleCallback вместо queueMicrotask

8. Заключение

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

Техника Event Storming, направленная на быстрое командное изучение предметной области, позволяет найти ответ и на вопрос декомпозиции решения.

Как - расскажу в докладе и проиллюстрирую примером.

В докладе расскажем об основных подходах и принципах создания полезных BI-аналитических отчетов и шагах по их внедрению в компаниях любого размера в короткие сроки. Поделимся опытом написания BI-коннектора к разным аналитическим системам и хранилищам: PowerBI, Google Looker Studio, Yandex DataLens, Apache Superset, Trino (PrestoSQL). Раскроем секреты обхода подводных камней при создании хранилища данных для аналитики, поговорим о новом подходе в этой области: Data Lakehouses, Parquet, s3, Hudi/Apache Iceberg/Delta Lake.

А что если я скажу, что можно сделать SPA приложение с SSR без помощи Next.js и React или других подобных фреймвоков. При этом в браузер пользователя можно не тащить мегабайты JS. И все будет работать очень быстро и динамично.

В своем докладе я сравню 2 подхода: классический SSR на базе NextJS и подход на основании библиотек типа HTMX или Turbo Hotwire. Разберу плюсы и минусы разных вариантов. Будет интересно.

В выступлении расскажу об основах Kafka и за 45 минут вы поймёте как работает технология, чтобы правильно применить её в своих проектах:

* Расскажем о сценариях использования Kafka.

* Узнаем, что такое консумер, продюсер и брокер.

* Разберём, как связаны топики, партиции и сегменты.

* Поговорим о формате сообщений в Kafka.

* Расскажем о лидере партиций, репликации данных и партицировании.

* Поговорим о гарантиях доставки сообщений и идемпотентности.

* Выясним, что такое консумер-группа и ребалансировка консумеров в ней.

- Мощности современных компьютеров и нагрузка на сервисы растут с каждым днём. Как разработчикам и СУБД поспевать за прогрессом? В докладе рассмотрим, как избежать дефицита транзакций в Postgres.

- Разберём, как устроен счётчик транзакций в PostgreSQL и почему он может иссякнуть.

- Научимся избегать переполнений собственными силами: ищем «навязчивые» транзакции, грамотно настраиваем сервер.

- Вы сделали всё лучшим образом, но наступило будущее и счётчика действительно перестало хватать? Есть решение! Узнаем, как сообщество PostgreSQL работает над увеличением величины счётчика, не теряя в производительности.