Разработка

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

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

Ждём ваш отзыв

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

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

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

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

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

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

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

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

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

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

Ждём ваш отзыв

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

Ждём ваш отзыв

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

Ждем ваш отзыв

Выступает ОНЛАЙН

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

Ждём ваш отзыв

Поделюсь опытом интеграции крупных языковых моделей (LLM) в портал Rambler, а также проведением сравнительных испытаний и тестированием различных моделей. На примере взаимодействия с GigaChat рассмотрим процесс формирования запросов для LLM (prompt engineering), а также этапы выбора наиболее подходящей модели и её настройки. Обсудим критерии оценки качества генерации и суммаризации, включая метрики Meteor и BERTScore, а также настройку систем мониторинга и контроля. Затронем потенциальные риски, связанные с созданием контента, и вопросы соблюдения нормативных требований. Расскажу, как мы обеспечиваем контроль над результатами работы модели и какие гарантии предоставляем.

Постараюсь ответить на следующие вопросы:

1. Как выбрать подходящую модель LLM для решения конкретной бизнес-задачи?

2. Какие метрики использовать для оценки качества работы модели?

3. Как обеспечить стабильность и надежность функционирования модели в продакшене?

4. Какие риски связаны с внедрением LLM, и как их можно минимизировать?

5. Как организовать мониторинг и обновление модели без ущерба для бизнеса?

Ждём ваш отзыв

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

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

Ждем ваш отзыв

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

Ждем ваш отзыв

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

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

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

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

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

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

⁃ Умный поиск

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

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

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

Ждём ваш отзыв

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

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

Ждем ваш отзыв

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

1. От быта к профессии:

— Как идентифицировать риски через простые примеры (ремонт квартиры, поездка на автомобиле) и применять эти навыки в ИТ.

— Классификация рисков: Люди, Процессы, Технологии, Внешние условия — как эта структура охватывает ключевые аспекты ИТ-проектов.

2. Инструменты для анализа:

— Матрица рисков: как оценить вероятность и влияние, чтобы не тратить ресурсы на «шум».

— Почему позитивные риски (например, неожиданная помощь эксперта) могут быть важнее угроз.

3. Стратегии управления:

— Планируем действия: от предотвращения проблем до передачи ответственности.

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

4. Практика:

— Интерактивная работа в командах: расстановка приоритетов, создание «дорожной карты» действий.

— Как избежать типичных ошибок: игнорирование «зеленых» рисков, переоценка маловероятных угроз.

Итог:

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

Для кого:

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

Ждем ваш отзыв

⁃ Блиц-обзор основных DevOps-практик в небольшой ИТ-компании: поверх чего наворачиваем ИИ

⁃ Какие ревьюшницы мы попробовали и почему в итоге написали свою

⁃ Код-ревью до ИИ и после: реальные кейсы из боевых проектов

• Трудности внедрения или как продать ИИ своей команде разработки

Ждём ваш отзыв

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

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

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

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

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

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

Ждём ваш отзыв

В мире высоких скоростей и необходимости решить задач ASAP здесь и сейчас мы часто делаем разработку на скорую руку лишь бы работало, а переписать правильно планируем "когда-нибудь потом". На примере Сервиса Покупки Билетов Buy-Pie-Tickets поговорим о том, к чему приведет долгая жизнь на этапе MVP и "быстрые решения" в долгосрочной перспективе. Рассмотрим типовые ситуации и поговорим сколько будет стоить их исправление в дальнейшем.

Ждём ваш отзыв

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

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

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

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

Ждем ваш отзыв

Как объединение BPMN и DFD позволяет создать более полное представление о бизнес-процессах: примеры успешного применения комбинированной нотации в реальных проектах.

Участники МК получат пошаговую инструкцию по интеграции BPMN и DFD в свою повседневную практику и смогут попробовать самостоятельно попрактиковаться в применении нотации

Ждем ваш отзыв

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

В чем суть локальных LLM, и правда ли, что Open Source >= ChatGPT

Как выбрать модель опенсорса под свои задачи

Промпты для open source LLM = промпты для GPT?

Попробуем использовать опенсорс модели для написания nginx конфига и Docker файлов

Отыщем DDoS атаки в логах с помощью LLM

RAG, Fine-Tuning, QLoRa — вот они слева направо. Как увеличить точность выбранной модели

Ждём ваш отзыв

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

Довольно часто backend-разработчикам приходится проектировать микросервисную архитектуру. Тут много непонятного: непонятно, где проходит грань между «как организовать файлы» и «как сервис А и Б взаимодействуют друг с другом»; не ясно, какие паттерны стоит использовать, а какие нет; неизвестно, кто источник основных знаний по проектированию; не ясно, какие протоколы стоит брать и какие есть с ними сложности; не всегда ясно, как проектировать микросервисы.

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

Ждем ваш отзыв

Наш корпоративный чат-бот построен на микросервисной архитектуре и активно взаимодействует с клиентами через чат. В ходе разработки мы столкнулись с нетривиальной задачей: нам нужно было не только получать входящие сообщения, отправляя их в MQ (RabbitMQ) для обработки DS-ядром, но и правильно маршрутизировать ответы обратно в нужный процесс.

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

— От клиента — для корректной обработки фраз, составленных из нескольких сообщений («привет», «как», «дела»).

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

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

Ранее наши коллеги рассказывали, как маршрутизация устроена в чат-системах (https://speakerdeck.com/xfenix/dvustoronnii-websocket-routingh). В этом докладе мы поделимся нашим опытом:

— Как мы решали проблему обратного роутинга в микросервисной среде.

— Как эволюционировали наши архитектурные решения и какие ошибки мы допустили.

— Какие существуют методы решения проблемы обратной маршрутизации (название придумали сами, так как тема ранее не была освещена).

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

Ждем ваш отзыв

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

Ждем ваш отзыв

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

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

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

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

Ждем ваш отзыв