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

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

С момента выхода книги Дяди Боба "Clean Architecture" прошло уже достаточно времени. Кто-то прочитал книгу, а кто-то только смотрел видео докладов на эту тему.
Докладов на youtube тоже хватает. Но все эти доклады идейные — вот как нужно делать и у вас все будет хорошо. При этом у авторов обычно нет практического опыта создания больших проектов по данной архитектуре (а еще запуска этих проектов в production). А все примеры — слишком простые и на практике все равно остается много вопросов.

Больше года назад мы начали 2 новых проекта, в которых применяли принципы, описанные в книге. Я готов поделиться нашим опытом.
Это корпоративные приложения на C# (API, backend). Enterprise который еще не успел стать кровавым :)
Но этого вполне достаточно чтобы получить первые результаты.

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

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

Мы расскажем о том, как переписали API Я.Афиша с REST на GraphQL на node.js + Python. А затем, в рамках оптимизации, избавились от node.js + Python и переписали весь GraphQL на Java.

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

На первый взгляд кажется, что отправить HTTP запрос - это очень просто. Тем не менее, даже HTTP/1.1 достаточно нетривиален - RFC на него содержит более 150 страниц, кроме того - браузеры уже поддерживают HTTP/2 и HTTP/3. Это не оставляет никакого выбора: стандартный клиент в платформе должен быть реализован на высоком уровне.

На пути от .NET Framework 1.0 к .NET 5 клиентские API для работы с HTTP и его реализации претерпели множество изменений. В некоторых версиях они были удачными, в некоторых же — провальными и явно временными.

В докладе я расскажу о истории развития клиентского HTTP API в .NET, его особенностях, о миграции приложений с Framework на Core с их учётом. Также разберу некоторые хаки, полезные при работе с ним. Заглянем в NuGet и рассмотрим представленные в нём обёртки над HTTP API с точки зрения эффективности и кроссплатформенности.

Расскажем про свой опыт построения рекомендательной системы от offline расчетов до online. Отдельно расскажу про то, как обеспечивается актуальность фичей для онлайн расчетов.

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

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

В компании SpectrumData Kotlin используется как основной (и по факту единственный) продуктовый язык разработки на платформе JVM для самого широкого круга задач: работа с данными, реализация микро-сервисной архитектуры, реализация бэкенда.

История успешного применения Kotlin в компании длится уже 4 года с версии языка 1.1.

Для SpectrumData характерно полноценное применение в своей кодобазе всех возможностей и рекомендованных практик по данному языку.

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

Аспектно-ориентированное программирование (АОП) позволяет без дублирования кода добавлять инфраструктурный функционал вроде кеширования и логирования на разные слои вашего приложения. И все это — не меняя уже написанный код! Это очень мощная, удобная… а также редко используемая техника.

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

В своем докладе Денис делится 10-летним опытом использования АОП на C# и .NET. Расскажет о подходах к реализации АОП, а также покажет, как менялись инструменты для разработки аспектов вместе с языком программирования и платформой.

Естественно, он предложит наиболее оптимальный на сегодня вариант реализации аспектов. И вместе подумаем, какими хотелось бы видеть инструменты для разработки аспекты в будущем. Примеры будут на C# и .NET, но идеи доклада будут актуальны для любой платформы.

Современный фронтенд — это сложно. Если легаси проекты ограничены "что есть — то есть", то для новых приложений, кроме настройки Webpack и Babel, у нас есть HMR, SSR, code splitting, routing, кеширование, stream rendering — и это, не считая, собственно, фронтенд фреймворка и бэкенда, CI/CD и деплоя.
HMR "ломается" на приложениях сложнее hello world, настройку SSR в интернетах хором называют "адски сложной", ну, а роутинг, в уважающей себя связке фронт+бэк, можно неправильно организовать десятью конкурирующими способами.
Вся эта сложность породила новое направление "jamstack", и такие решения, как Next.js и Nuxt.js — "opinionated фреймворки", где все настроено за нас.

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

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

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

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

Слышали ли вы про "lifting state up"? Может ли одна из двенадцати ключевых концепций в официальной документации React приводить в плохой производительности? В рамках доклада мы сделаем простейший grid на React. Поэтапно разберем возникающие проблемы производительности. Увидим, что иногда и O(1) - это недостаточно быстро. Будем профилировать и рефакторить до тех пор, пока приложение не станет работать бестрее, чем вы успеете сказать "React".

Отладка приложения занимает 99% нашего времени. Кто-то пользуется Chrome DevTools, кто-то обходится обычным console.log, кто-то использует профайлеры. Зачастую этих инструментов более чем достаточно. Но есть еще один, не особо известный и популярный в JavaScript мире.

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

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

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

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

Мой доклад основан на 4-х летнем опыте создания дизайн-системы для большого числа разработчиков.

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

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

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

В этом докладе будет много концентрированной пользы.

Я расскажу:

• Зачем проводятся глубокие интервью и как это делается обычно
• Какие бывают инсайты: практические примеры и польза от них
• Что будет, если применить мозг для решения 80% задачи
• Как правильно разговаривать с клиентской базой
• Особенности формата, которые увеличивают отклик в 2,5 раза
• Правила обработки результатов
• Создание ядра лояльной аудитории
• Использование результатов интервью дальше

Только самое важное — без bullshit'а.

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

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

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

Я расскажу:

• Как и когда появилась социология на данных веб поиска и почему это переворачивает игру.
• Как описать свой продукт или фичу так, чтобы стало понятно поисковым машинам (и людям).
• Как правильно передать контекст продукта поисковой машине.
• Как выгрузить данные для анализа и что с ними потом делать.
• Как интерпретировать результаты анализа.
• Как совмещать продуктовый контекст поиска с вашей продуктовой аналитикой и BI.
• Как таким образом влиять на продуктовые метрики и предсказывать, сколько денег принесет вам неохваченная аудитория.

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

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

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

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

И вот главная проблема: как определить оптимальный уровень затрат на "сервисность" и их влияние на доход/прибыль от продукта?

Мы поговорим вот о чем:

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

Все это поможет прийти к важному выводу - когда инвестировать в продукт, а когда в его сервисную обёртку.

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

В докладе будет много интересного:

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

А вы умеете правильно рассказывать о продукте? Так, чтобы его полюбили? Так, чтобы он приводил пользователей, которые принесут деньги?

Расскажу, как говорение о продукте влияет на метрики:

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

Поговорим о том, как строить долговременные пользовательские сценарии и возвращать клиентов за ценностью. А еще — об экспертности (пользовательской и внутри продукта) в контексте продуктовых метрик.

У вас есть продукт на национальном рынке, и вы думаете расширить его географию, выйдя в другую страну/страны.

- Какие вопросы стоит себе задать прежде чем вписываться в географический рост;
- Можно ли не менять продукт или изменить его незначительно под страну/культуру;
- Как меняется работа команды и можно ли просто добавить новый фокус существующей команде;
- Что вы заплатите за выход в новую страну (в ресурсах, процессах, команде);
- Какие подводные камни есть, если основной продукт и команда в России.

Поделюсь на кейсах болей и радостей Яндекс.Практикума в США и других.

Что важно для продуктовой команды при выводе продукта на новый рынок

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

Проблема

Как часто к вам на работе прилетают чайка-менеджеры и просят "запилить" что-то в продукте? Каждую неделю? Каждый день? Или каждый час? У вас много "неравнодушных" коллег, которым всегда срочно что-то нужно от продукта, хотя это что-то явно менее приоритетнее ваших текущих активностей? А может даже и вредно для бизнеса? При этом у вас есть стратегия, вы живете по OKR, приоритеты и фокусы (как долгосрочные, так и краткосрочные) расставлены и согласованы?

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

Если описанные ситуации близки вам, то приходите на мое выступление. Поведаю о том, как существовать в этом жестоком продуктовом мире. Ну и держать фокус))

Тезисы

Сначала я расскажу про методы удержания фокуса.

Кодовые названия методов:

• Время лечит
• Полужесткий игнор
• А что важнее?
• 5 почему
• Столкновение лбами
• А как было раньше?
• Детализация до смерти

Все постараюсь разобрать на примерах.

В заключительной части выступления мы поговорим про коммуникацию: Как правильно сказать Нет в том или ином случае? Без риска для жизни.

Ценность для слушателя

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

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

В апреле 2011 года у нас была 1 пиццерия в Сыктывкаре. В 2017 году 160+ пиццерий и 10 стран.

Сейчас в нашей сети 696 пиццерий (а на момент моего выступления уже будет 700+, хорошо, что презентацию можно поменять ???? ) и 2 новых концепции Drinkit и Doner 42. Эти концепции мы запустили в прошлом году. При этом информационная система Dodo IS остаётся одна и для стран, и для новых концепций.

Как при этом не сломать мозг и помочь продакт оунерам развиваться?

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

Про OKR знают все, кто управляет проектами и продуктами.

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

Но умеете ли вы применять OKR максимально эффективно?

В докладе я поделюсь инсайтами и нашим опытом.

Вот часть рецептов:

• Ускорение узких функций через сквозное целеполагание.
• Объединение компаний через общие цели.
• Фокус на кратный рост.
• Балансировка KPI и OKR и тд.

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

Всё это с кучей примеров, глубокомысленными выводами и рекомендациями.

Быстрый рост команды влечет за собой проблемы с оценкой людей.

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

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

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

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

Обилие книг "как стать эффективным и добиться успешного успеха" намекает, что с эффективностью не все хорошо. Мы что-то делаем, а через неделю или месяц понимаем, что никак не приблизились к нашим целям. Читаем книги о прокрастинации, целеполагании, эффективности. Снова что-то делаем и снова недовольны результатом.

О прокрастинации с целеполаганием не рассказывает только ленивый. А я ленивый, и хочу рассказать о первопричинах: нейрофизиологии, концепции "сознания" и о том, почему мы делаем те или иные штуки.

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

А предсказательную силу я проиллюстрирую с помощью прокрастинации и целеполагания, раз уж так заведено. Но доклад все равно не о них, а о том, "как же оно может внутри работать, что вот такая фигня в конце каждого дня получается".

Зачем заботиться о коллегах? Мифы и легенды о концепции благополучия.

Как поддержать лояльность в кризис?

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

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

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

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

Мы поговорим:

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

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

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

Январь 2020. Команда международного развития.

Ренат управляет ожиданиями партнёров в Европе и растит бизнесовую часть команды, Лёша готовится к запуску новой страны, Катя помогает Румынии и Нигерии с маркетинговой стратегией, Аня планирует продуктовые новинки в календаре, Антон готовит обновления в стандартах.

Разработчики пилят технические задачки, изредка узнавая у бизнеса - а как там дела (не, иногда ещё помогают Лёше с запуском новой страны). У каждого свой бэклог задач, все при делах и заняты.

Идиллия?

Как бы не так. Таски мутятся, но прорыва на международных рынках нет.

Как быть?

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

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

В докладе я расскажу, как строили единую команду ИТ+бизнес, на какие грабли наступали, как работали с возражениями, к чему в итоге пришли. Например, поделюсь, как мы пришли к общим квартальным планированиям и обзорам спринта, как теперь ставим общие цели и OKR на 17 человек, приведу пару примеров, показывающих, насколько разработчики глубоко погружены в бизнес и могут самостоятельно предлагать топовые решения.

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

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

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

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

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

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

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

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

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

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

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

Язык Dart для разработки на Flutter выбран не просто так, он играет особенную роль.

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

Причем Dart развивается и меняется очень быстро. Всего пару лет назад он сменил динамическую типизацию на статическую, оброс кучей других фич, таких как extension methods. А не так давно была анонсирована новая фича языка — Null Safety.

В докладе я расскажу о том, что такое Null Safety, чем она может помочь в разработке, какие сложности могут вас ждать при миграции и чем реализация в Dart похожа, а чем отлична от Kotlin и Swift реализаций.

Тесты нужно и важно писать. Сегодня с этим уже мало кто спорит. Если технология обладает развитой инфраструктурой для тестирования кода, это выгодно отличает её на фоне альтернатив. Как с этим обстоят дела у Flutter?


В ходе доклада я расскажу:
- Какие виды тестов можно писать на Flutter и на чём стоит сфокусироваться в первую очередь;
- Что такое виджет-тесты и как можно тестировать UI не запуская приложения;
- Зачем тестировать виджеты в изоляции от окружения;
- Как писать unit-тесты на всё, включая асинхронный Dart-код;
- Что не стоит пытаться покрыть тестами, потому что всё равно не получится;
- Как писать кастомные матчеры и что с ними потом делать;
- Как лучше всего мокировать данные;
- Почему сделать снимок состояния тестового покрытия кодовой базы проекта — нетривиальная задача;
- Как писать код на Flutter так, чтобы его можно было протестировать.

Как часто у вас расползался интерфейс приложения? А как много времени нужно тестировщику, чтобы проверить все состояния экрана?

Решить эти и другие проблемы могут (или нет) snapshot тесты.

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

О важности фокусировки и концентрации знают все. Но как переключать себя в это состояние?
Особенно тогда когда нужно? Расскажу такой рецепт. Простой и понятный алгоритм действий.

Теория решения изобретательских задач (ТРИЗ) на слуху в дизайнерской среде, однако мало кто владеет конкретными практиками. Прочитав две книги по этой теме, я всё ещё сильно «плавал» и не мог применять теорию. Только погружение в практику современной ТРИЗ дало навык решения задач.

В докладе рассмотрю три метода в приложении к дизайнерским задачам. Этими методами будут:

1. причинно-следственный анализ;
2. оператор «идеальный конечный результат»;
3. графическая форма технического противоречия.

Звучит жутко, но инструмент даёт мощнейший.

Основные вопросы, на которые я отвечу по ходу доклада:

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

А еще поговорим о том, какие навыки UX/UI дизайнера помогают создавать игры для детей, а какие мешают. Почему в создании игр для детей дизайнер должен быть сценаристом, режиссёром, исследователем? Можно ли совмещать в себе эти навыки и какой из них самый главный?

Растущее количество интерфейсов требует серьёзной дисциплины. Высокий темп трансформации сервисов невозможен без слаженной работы и быстрой доставки обновлений до пользователей. Мы нашли решение в разработке дизайн-системы и инфраструктуры вокруг неё.

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

Доклад основан на личном опыте работы над цифровыми продуктами Почты России.

Рассмотрим кейс системы учёта международной почты и ответим на вопросы:
1. Как проектировать сложные и специфические B2B-продукты в консервативных сферах, где исследования подменяются требованиями заказчика.
2. Как навести порядок в дизайне продукта, если нет развитых дизайн-процессов.
3. Как сохранить интерес и энтузиазм, когда проект сложный и с долгим циклом разработки.

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

Тренд на голосовые интерфейсы не стихает, но окружен смесью хайпа и скепсиса. Кому и зачем нужен голос? Voice first или voice only? Почему боты такие тупые? И как сделать их лучше?

На докладе я расскажу о:

• дизайне диалогов — процессе на стыке продуктового дизайна и редактуры, который учит голосовых ассистентов решать задачи клиентов;
• молекулах и атомах проектирования процедур для бота;
• клиентских путях и процессе UX-исследований для голоса;
• юзкейсах и ЦА голоса;
• истории и перспективах дизайна VUI.

Доклад будет интересен тем, кто не знаком с ML, и хочет узнать, как работает диалоговый дизайн.

• Какие важные для профессии навыки развиваются в фоновом режиме?
• Можно ли их осознанно масштабировать?
• Как понять свою ценность для компании и презентовать её команде?

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

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

Я расскажу про две стороны применения генеративного дизайна.

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

Поговорим о пяти основных моментах, которые нужно учитывать при дизайне мобильных приложений.
1. Моторные, визуальные и когнитивные нагрузки
2. Контекст использования и способ взаимодействия
3. Привычные паттерны пользователей и платформ
4. Шрифты и трекинг
5. Анимация интерфейса

Понимание этих пяти пунктов поможет создавать по-настоящему крутой и удобный дизайн

Что случилось в сообществе в 2019, что поменялось в 2020.

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

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

Мы работаем на удалёнке более десяти лет, поэтому эти проблемы стали актуальны для нас еще до того, как удалёнка стала пандемийным мейнстримом.

И чтобы не тратить ресурсы на закупку и тестировать качественно, мы создали собственную разработку — мобильную ферму для тестирования IOS.

Доклад будет посвящен работе над скоростью прогона автотестов.

Рассмотрим важные и очень интересные аспекты автоматизации тестирования, а именно:

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

С best practice ваши тесты будут летать со скоростью ракеты!
Приходите, будет интересно, а главное полезно!

Ручное тестирование отнимает слишком много времени и сил? Может вы просто неправильно его готовите?

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

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

Поделюсь про наш главный камень преткновения - инфраструктуру для интеграционных тестов (в частности, БД).

Мы разберем, какие бывают тестовые стенды и - особенно! - окружения special for автотестов, сравним разные варианты.

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

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

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

В условиях гиперроста в Miro в 2020 г. возникла острая потребность в нагрузочном тестировании (НТ), и имеющиеся наработки пришлось оперативно развивать.

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

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

Результатами этих процессов стали:
1) возможность уверенного внедрения новых компонентов и доработки существующих;
2) оптимальный выбор настроек компонентов в соответствии с требованиями;
3) автоматизация, упрощение и ускорение тестирования.

Отдельно стоит отметить участие в наполнении публичной базы знаний по НТ вместе со специализированным сообществом.

Также в ходе рассказа о "внутренней кухне", технических и организационных решениях, даётся краткое введение в НТ.

Использование BDD призвано улучшить процесс автоматизации тестирования в виду документирования пользовательских сценариев в процессе написания кода, а также расслоения структуры тестов.

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

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

Хочу рассказать, как можно построить функцию QA в компании, которая состоит из нескольких сотен разработчиков.

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

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

У нас в ANNA Money более ста различных микросервисов (и их число только растёт), которые мы доставляем сотни раз в неделю на тестовые и промышленную среды на базе Kubernetes. При таком объёме встают вопросы по унификации, стандартизации и упрощении формата описания сервисов и их деплоймента. Одним из способов решения этой проблемы является использование пакетного менеджера Helm (пожалуй, наиболее популярного на текущий момент).

Но что если Helm в вашей вселенной был не всегда? А что произойдёт, если завтра ему на смену придёт другой более хиповый способ описания деплойментов?

Мы начинали унификацию, когда ещё использовали Mesos, пережили переезд всех сред на Kubernetes, и в какой-то момент стали использовать Helm, но не отказались от собственного формата описания сервисов.

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

Ansible в 2021 году может звучать не модно, однако им по прежнему решают огромное количество задач.

Мы в Контуре тоже используем Ansible для раскатки инфраструктуры.

В прошлом году мы задумались о качестве ролей, которые мы используем.

В докладе расскажу:

• как решали проблему с зависимостями Ansible ролей, добавляли тестирование ролей в докере,
• разбирались с линтерами,
• подумали о работе на 6 операционных системах,
• совмещали локальную разработку и CI,
• устанавливали всем единое окружение,

Внутри много технических деталей!

У нас в Provectus множество различных проектов, от типовых до очень необычных.

Зачастую запуск проекта, а тем более стартапа, без знаний бизнеса или без понимания конечной инфраструктуры (а если еще и ТЗ меняют на ходу) - боль. Боль как для Ops команды, так и для Dev. Необходимо быстро реагировать на ситуацию, иметь возможность расширить\сократить\заменить людей на проекте или стек целиком. Но что бы ни случилось, требуется сделать хорошо и соответствовать определённым стандартам.

Ещё один важный фактор – оставить после запуска проекта знания, передать артефакты, чтобы у заказчика была возможность обслуживать инфраструктуру своими силами. Или иметь возможно повторить проект с небольшими изменениями, часто в сжатые сроки!

Взяв за основу наработки одного из наших DevOps инженеров (это был многим знакомый Terraform), мы создали инструмент, который позволял развернуть базовую инфраструктуру в AWS с упором в EKS, и что не мало важно, удалить все созданное без остатка. Мы решили назвать проект Swiss-Army-Kube.

В докладе автор расскажет:
- Что подтолкнуло к разработке подобного инструмента и с какими трудностями пришлось столкнуться
- Как договорится в большой компании инженеров с множеством инструментов
- Как именно мы используем Swiss-Army-Kube и в каком направлении развиваемся
- Что мотивирует на развитие проекта и зачем нужно делится этим со всем миром

Четыре ключевые метрики Accelerate (они же DORA) стали индустриальным стандартом для оценки качества процессов поставки. Их внедряют в GoCD и Gitlab CI.

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

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

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

Нельзя просто взять и начать делать пилот нового проекта на GCP, AWS или даже Yandex.Cloud. Ты связан определенными ограничениями корпоративной сети.

Нельзя просто взять и делать вообще что-то. Это всегда непросто. Потому и возник термин "кровавый энтерпрайз". Так было до недавнего времени.
Корпорации вынуждены меняться и отвечать на запросы продуктовых команд как организации самой разработки (кто еще не поехал в Agile?), так и технологического процесса (весь этот наш DevOps).

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

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

На примере конкретного кейса – рефакторинга монолитной региональной CRM-системы с одновременным переходом с "водопада" на Kanban и перестройкой CI/CD в проекте – мы расскажем, какие боли есть у руководителя проекта и как ему может помочь корпоративная DevOps-платформа.

Мы расскажем о Платформе Цифровых Продуктов (ПЦП) Ростелекома и о том, почему всё больше новых проектов в РТК выбирают её, какие проблемы "кровавого энтерпрайза" она помогает решить и как сделать так, чтобы бизнес поверил в DevOps и дал денег, а эксплуатация не крутила у виска пальцем.

Расскажем, почему ПЦП – это не просто пара-тройка кластеров OpenShift, а нечто большее.

Больше 10 лет прошло с момента первой легендарной конференции DevOps Days в Генте. За это время в мире появилось с несколько дюжин различных коллабораций с Ops-спецами, начиная с класических DevSecOps-ов, заканчивая диковинными HugOps-ами.

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

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

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

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

Это был настоящий вызов и мы с ним справились.

Расскажу о cloud native и self-hosted подходах и поделюсь плюсами и минусами каждого из них, а также критериями для выбора, которые мы определили для себя

Создать и выпустить игру не так просто, как кажется, особенно если вы хотите, чтобы релиз прошел успешно и игра добилась каких-то результатов, окупив при этом вложенные затраты… или нет ;) Т.к. геймдев — высокорисковое мероприятие.

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

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

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

• Где найти вдохновение?
• Как сделать успешный креатив?
• Как и чем привлечь издателя и инвестиции?

Сергей поделится удивительной историей зарождения, развития и эволюции Игры, как важнейшей части нашей цивилизации.

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

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

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

В своем докладе Алексей расскажет о новом стеке технологий Unity DOTS, поделится опытом применения парадигмы ECS для быстрой и комфортной разработки игр.

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

Лао-цзы писал: "путь в тысячу ли начинается с одного шага". Вот и наш сказ будет о том, как один технологический шаг вперед привел Playrix к пути в тысячу ли – созданию Unity-подобной библиотеки.

Поговорим про то, что сделать минималистичный движок не сложно и не дорого, а вот хороший и удобный – совсем наоборот. Про то, как отличаются проблемы в начале пути от проблем на стадии зрелой разработки. А еще про всяких зверей на этом пути: C++ reflection, code generation, refactoring, ImGui, interface user expirience, cross-project game logic и test automation.

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

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