Разработка

В докладе рассматривается процесс работы с подходом API First. Описывается создание проекта с документацией, работа с OpenAPI и AsyncAPI, CI/CD и кодогенерация сервера и клиента на Java

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

О чем поговорим:

- Что такое ADR и почему эта методика/инструмент набирает популярность

- Что является архитектурно "значимым" решением, а что нет

- Кто участвует в принятии архитектурных решений

- Кому и в каких случая формат ADR будет удобен и полезен

- Достаточно ли ADR для старта процесса разработки или нужна детализация

- ADR - киллер девелоперской документации или же дополнительный инструмент?

- Как с помощью ADR следить за эволюцией архитектуры ваших продуктов

- Как внедрить ADR у себя в команде, поделюсь практическим опытом

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

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

Зачем нужна, какая бывает.

Задизайним и шаг за шагом построим реалтайм систему дедубликации данных на сотни RPS, 40+ миллионов событий в сутки. Использовать будем PHP swoole, kafka, redis, scilla.

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

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

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

⁃ Стоимость генерации к конверсии в покупку

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

⁃ Психология пользователя перехода со старых паттернов на новые

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

⁃ Умный поиск

⁃ Персонализированные каталожные категории и фильтры

⁃ Небесячие пользователя способы узнать о его целях больше в явном виде

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

Жизненный цикл сервиса в Kubernetes не такой простой, как может показаться. Особенно, если он высоконагруженный. В своем докладе я расскажу, особенности старта, смерти, и жизненного пути при работе сервиса. Расскажу о проблемах, с которыми мы сталкиваемся каждый день и некоторых best practice при написании хорошего микросервиса.

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

Что сейчас можно считать настоящим опенсорсом, а что паразитирует на его идеях?

Экономика современного опенсорса. Жить на пожертвования, строить бизнес модель или договориться с корпорацией?

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

Лицензирование, этические аспекты, конкуренция и другие вызовы.

На примере PostgreSQL, рассмотрим, как может функционировать сообщество.

Сказ о том, как я расчехлил свой пет проектик 2014 года, чтобы обновить дизайн, а в итоге все вылилось в обновление на современные рельсы. Начнем со сборки, пройдемся по стилям, и закончим переездом в облака.

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

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

Доклад будет полезен как тем, кто занимается наймом и адаптацией, так и тем, кто обладает небольшим опытом и собирается менять работу

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

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

Если у вас тесты занимают дни или недели - вы понимаете боль "выкатить хотфикс сейчас же"

Кто важнее: ci/cd или все-таки релиз-менеджер?

Как в процессе решения одной задачи мы пришли к созданию своей платформы, и почему мы не прыгнули в готовые решения?

1. Какую систему Observability мы строим.

2. Бизнесовый процесс команды девопсов. Девопс команда как 3 и 4 линия поддержки. Как выстроили процесс работы с 1 линией поддержки.

3. Шаблоны: что мы делаем, чтобы ускорить процесс.

4. Какой алгоритм нужно выстроить, чтобы ускорить время решения инцидента.

5. Рекомендации по построению команды девопс против работы 1 специалиста на 1 продуктовую команду

В МТС Диджитал мы успешно используем веб компоненты для создания интерфейсов. Моя команда создает ui-блоки для управления разной бизнес-логикой, которые представлены в виде виджетов и написаны на разных фреймворках (в основном на Angular и Vue). В рамках своего выступления я поделюсь опытом, который будет полезен фронтенд-разработчикам крупных компаний, где не определен четкий стек технологий для работы с веб интерфейсами.

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

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

Расскажу про современное состояние GenAI в задачах работы с разными типами данных: текст, изображения, видео. Посмотрим, где и как современные модели применяются в контексте AI агентов, ассистентов и прикладных направлений, например робототехника. Обсудим нашумевший подход к созданию «размышляющих» моделей а-ля DeepSeek R1, проанализируем перспективы применения RL.

Тезисы уточняются

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

- бесплатные и платные;

- встроенные и внешние;

- CLI и GUI.

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

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

Будет полезно разработчикам, ответственным не только за написание кода, но и за его производительность «в бою», а также инженерам по мониторингу и работе с инцидентами на production.

В докладе разберемся, почему же Stories сложны в разработке, хотя со стороны все кажется простым.

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

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

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

Зачем вообще обычного тестировщику понимать, как работает бизнес и кто у нас клиент.

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

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

Как мы кодили no code - рецепты сервисов со свежим Редисом.

Опыт разработки продукта с масштабируемой архитектурой на примере Платформы ботов общения с клиентами с no-code конструктором сценариев и средой их исполнения.

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

Краткий рассказ о получившейся Платформе - иллюстрация с точки зрения UX.

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

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

В том числе обосновывается выбор различных способов коммуникации между сервисами, от классики REST до асинхронной коммуникации без API через общее хранилище, а так же применение элементов паттернов API Gateway, canary deployment и других.

В результате последовательных шагов получится архитектурная схема с адаптерами внешних сервисов, Event driven воркерами, in-memory хранилищем состояний и Event sourcing сохранением результатов для мониторинга и аналитики. Небольшое количество примеров на Python, но сам рассказ от языков и фреймворков не зависит.

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

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