Вспомните, где вы обычно тестируете своё веб-приложение. Скорее всего, у вас есть несколько вьюпортов, в которых вы быстро проверяете верстку и, возможно, пишете автотесты. И багов от пользователей почти нет — значит, все делаете правильно. Но как вашим сайтом пользуются на самом деле? Что нужно предусмотреть, чтобы сайт работал действительно почти везде?

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

gRPC — штука для многих уже привычная и, казалось бы, понятная, когда дело касается простого «один запрос — один ответ». Но если этого становится мало, нужно «асинхронно», «много» или ««постоянно», есть смысл обратить внимание на gRPC-стримы. И тут-то появляются нюансы.

Обзорно поговорим о том, как работают gRPC-стримы, где и как их стоит применять, чтобы не сделать себе и другим больно

1. Что такое трехмерное тело?
2. Проблема распознавания образов в ИИ.
3. Плюсы и минусы фотограмметрии.
4. Выбор алгоритмов и методов

Kubernetes для всех. Простые советы и сложные рецепты. Экосистема Kubernetes

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

Антон подробно расскажет о работе Temporal, начиная с архитектуры кластера и заканчивая внедрением конкретных бизнес-процессов. Особое внимание будет уделено детерминизму, версионированию в Temporal, а также использованию gRPC для взаимодействия. Будет показано, как механизм Event History в Temporal способствует достижению отказоустойчивости, позволяя контролировать каждый аспект процесса и предотвращать потерю заказов.

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

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

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

Спикер расскажет, что необходимо для запуска систем трассировок на базе open-source решений, покажет на простых примерах как настроить сбор трейсов с микросервисов на Python (fastapi, SQLAlchemy, httpx), как потом работать с трейсами и какую полезную информацию можно извлечь.

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

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

Итерация 1: in memory cache.

Итерация 2: удаленный шардированный кэш-кластер (redis vs memmcached).

Итерация 3: N-уровневый кэш.

Итерация 4: шардированно-реплицированный multi-DC кэш-кластер Redis.

В конце выступления спикер подведет итог и поговорит об альтернативах KV.

Стратегии и практики безопасности для Frontend-разработчиков. Рассмотрим основные угрозы в мире frontend, обсудим ключевые аспекты безопасности при разработке web-приложений, включая защиту от XSS, CSRF и других угроз. А так же разберем способы их предотвращения.

1. Какой он — идеальный заказчик сильного агентства?

2. Классификация заказчиков: как устроены, кто принимает решения «на той стороне» и как выходить на нужных вам людей.

3. С какими агентствами работают крупные клиенты?

1. Управление ожиданиями заказчика. Эффективная работа с клиентом: независимо от модели оплаты.
2. Работа с внешними клиентами: Кейс компании АТОЛ.
3. Работа с внутренними клиентами: Кейс Head of Sales BSL

В рамках доклада рассмотрим, как реализуются на практике инструменты портфельного управления во фреймворках SAFe и OKR для ответа на вопросы:

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

1. Управление рисками с точки зрения PMBook-а (теория): реестр рисков, стратегии реагирования на риски.
2. Три основных роли на проекте.
3. Управление рисками на этапе оценки.
4. Управление рисками на этапе контрактации.
5. Управление рисками на этапе исполнения проекта.
6. Управление рисками на этапе исполнении контракта

1. Проблематика.
2. Влияние стратегии и личности лидера.
3. Что конкретно нужно сделать с примерами. Делай раз, делай два, делай три.
4. Как собирать обратную связь, и какие метрики важны?
5. Что в итоге должно получиться?

Сейчас блог KTS на Хабр — это 120+ материалов и 34 сотрудника-писателя. Но еще 2 года назад блога не существовало. В докладе расскажу:

— Зачем ИТ-компании своя редакция, и как материалы от сотрудников компании влияют на привлечение новых кадров, а также на качество этих кадров.

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

— Как мы выстраивали редакцию, кого привлекали амбассадорами на старте и как работали с синдромом самозванца разработчиков

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

1. Наша идеальная формула топ-менеджмента — 80% вырастили и 20% купили. Почему так и как мы к ней пришли?
2. Польза от горизонтальных перемещений руководителей: разбираем кейс «Из руководителя департамента интернет-рекламы в финансового директора».
3. Без «звезд» вам будет сложно. Рассмотрим три ситуации, когда все-таки лучше сходить на рынок, а не искать внутри.
4. Интеграция «звезд» и роль корпоративной ДНК в этом процессе

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

1. История становления менеджмента в моих компанияx.
2. Чем большие компании отличаются от маленьких?
3. Почему в IT-компаниях все плохо с менеджментом?
4. Как это исправить?
5. Менеджмент — главная точка роста IT-компании!

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

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

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

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

Спойлер: в обычном виде в столбик плюсы и минусы выписывать не будем, но попробуем для них кое-что математическое.

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

Существует очень много боли и неудовлетворенности вокруг взаимодействия тимлидов и рекрутеров при найме.

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

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

1. Важность эффективного сотрудничества между разработчиками и тестировщиками для создания качественного ПО.
2. Преимущества совместной работы: как интеграция процессов разработки и тестирования может улучшить качество продукта и ускорить его выпуск.
3. Инструменты для совместной работы: примеры инструментов, которые помогают командам работать вместе над созданием новых функций без ошибок.
4. Роли и ответственности: определение ролей каждого участника команды для эффективной работы над проектом.
5. Культура безопасности: как создать культуру безопасности внутри команды, чтобы предотвратить возникновение ошибок и багов

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

Большинство подходов по управлению изменениями предполагают смену парадигмы работы, выработку новых механизмов работы и организационной структуры и убеждение людей в том, что именно это принесет пользу. Результатом таких действий является сильное сопротивление изменениям, о способах борьбы с которыми написаны целые тома. В докладе я рассмотрю альтернативный подход к управлению изменениями, который называется Управляемая Эволюция, в котором мы минимизируем сопротивление изменениям. Хотите узнать за счет чего? Приходите на доклад!

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

Проблема материалов.
1. Любому новому сотруднику нужно рассказать, как взаимодействовать с коллегами, к кому обращаться с проблемами, какое место он и его команда занимают в организационной структуре компании, какие функции выполняют. Как ничего не забыть? Я с этой задачей не справилась, зато узнала классное решение, когда сама стала новичком.
2. Ты наставник, имеешь много накопленного опыта, знаешь о компании все. Как тратить меньше времени на передачу знаний каждому новичку? Или как совет подруги помог мне собрать все «в кучу».

Проблема общения.
1. Чтобы эффективно обучать новичка и отвечать на все вопросы, а главное, чтобы он эти вопросы не стеснялся задавать, нужно наладить с ним контакт. Лично это сделать несложно, но что делать с удаленщиком? История о том, как я подружилась с «голосом в трубке».
2. Когда новый сотрудник приходит в офис, он ходит с коллегами на обед и общается в кабинете, у удаленного специалиста такой возможности нет. Интересная практика нашего отдела как решение этой проблемы.

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

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

1. Что такое самоорганизованные команды?
2. Принципы/устройство их работы.
3. Как построить самоорганизованную команду?
4. Как контролировать/модифицировать ее под свой продукт и процессы?

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

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

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

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

1. Что такое NUPP и зачем они нужны?
2. А конкретнее? Разбираем NUPP 1−6.
3. Как их внедрить на практике?

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

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

Специальная тема будет раскрыта участникам в день конференции

Секретная тема будет раскрыта участникам в день конференции