Запрос счета
Заполните поля ниже, чтобы получить счет на оплату билетов DUMP от юридического лица
Юр.лицо
ИНН
Количество билетов
+
Напишите нам
Задайте вопрос, напишите пожелания или оставьте отзыв
Ваш e-mail
Ваше имя
Напишите здесь то, что хотели:
Заявка на спонсорство
Заявка на выступление
Имя и фамилия
Компания
Должность
Город
Ваш e-mail
Ваш телефон
Тема
Краткое описание
Какую ценность слушатели получат в итоге:
В какой секции хотите выступить
DUMP2019 ➜ 19 апреля 2019 ➜ Екатеринбург-Экспо

Темы и спикеры DUMP

Backend
Николай Сверчков
Evil Martians
Serverless для простых смертных
Тезисы
Денис Катаев
Tinkoff.ru
Стримы в мейнстриме
Тезисы
Виктор Кандоба, Светлана Завьялова
Контур
Робот на линии - автоматизируем поддержку с помощью речевых технологий
Тезисы
Сергей Долганов
Evil Martians
Контрактный подход к построению API зависимых приложений
Тезисы
Григорий Кошелев
Контур
Vostok Hercules - make telemetry great again!
Тезисы
Виталий Семячкин
JetStyle
Чего мы хотим от голосовых ассистентов, чтобы сбылась мечта футуриста
Тезисы
Дмитрий Цепелев
Злые марсиане
Как мыслить графами, или почему GraphQL – это не просто представление структуры БД
Тезисы
Юрий Кербицков
Ак Барс Цифровые Технологии
.NET Core Application Domains ( .NET Core под капотом)
Тезисы
Артемий Рябинков
AVITO
Практики, особенности и нюансы при работе с Postgres в Go
Тезисы
Андрей Бородин,
Владимир Лесков
Яндекс
Проектирование системы резервного копирования PostgreSQL на Go
Тезисы
О чем речь?
Serverless для простых смертных
Когда разработчики слышат про serverless, то чаще всего представляют две вещи:
 — Что-то высоконагруженное, что должно легко и часто автомасштабироваться
— Некая сложная архитектура, которая полностью построена на serverless решении

Но что если мы возьмем бессерверную архитектуру и попробуем использовать ее для задач, которые на первый взгляд совсем не подходят для этого?
Такая мысль посетила меня, когда встал вопрос о переписывания одного небольшого проекта — блога, написанного 7 лет назад на Rails3, который постоянно течет и имеет никогда необновляемые зависимости.

Основные цели:
 — Пройти путь от нуля до готового проекта на основе serverless
 — Оценить\Снизить стоимость содержания проекта
 — Протестировать полученное решение под микроскопом
Ну и собрать все шишки данного подхода, которых было много и знания, которыми я хочу поделиться со слушателями ????

Узнаем о практической стороне работы с serverless:
 — Насколько сложно начать
 — Как много документации и туториалов
 — Есть ли поддержка общепринятых стандартов
 — Как тестировать локально
 — Сколько стоит
 — Какой язык лучше использовать
 — Какой стек задач наиболее релевантен
 — Стоит ли использовать для серьезного production
О чем речь?
Стримы в мэйнстриме
Недавно в Redis 5 появились новый тип данных - streams, это реализация идей из популярного брокера сообщений Kafka.
Обсудим зачем нужны стримы, чем они отличаются от обычных очередей.
Доклад сфокусирован именно на выяснение целей и задач для которых придуманы стримы.
Обсудим разницу между Kafka и Redis streams, а также "подводные камни", которые нас подстерегают.
О чем речь?
Робот на линии - автоматизируем поддержку с помощью речевых технологий
Вопросы, на которые отвечает доклад:
- С чего начать внедрение речевых технологий и как продать это бизнесу?
- Из чего состоит голосовой сервис, какие есть инструменты?
- Что разрабатывать самостоятельно, а что лучше переиспользовать, в каком порядке?
- Как выбрать сценарии и проводить эксперименты?

О чем расскажем:
- ASR и TTS. Облачные и back'end технологии, MRСP и API, подводные камни
- Сценарии диалога. С чего начали, как они выглядят в коде, какие данные собирали
NLU. От ключевых слов к машинному обучению
- Результаты. Что получилось в итоге
О чем речь?
Feature Toggles - безопасная поставка больших фич
В своем докладе я планирую осветить общие идеи, лежащие в основе подхода
  • internal testing - внутреннее тестирование фичи на продакшене
  • dark launching - поэтапная выкатка фичи с предварительным тестированием на малой группе пользователей
  • A/B testing - сравнительное тестирование (например, эффективности и востребованности нового функционала)
  • минимизация рисков
  • большая наглядность разработки и поставки больших фич (за счет маленьких итераций, заканчивающихся поставкой кода в продакшн)
А также технические детали разработки с точки зрения разработчика:
  • виды фича флагов
  • концепция feature-branch в исходном коде
  • отделяем релиза фичи от деплоя кода
  • быстрые итерации
  • blue-green deploy - с быстрым откатом
  • тестирование на продакшене, в т.ч. на живых людях :)
  • best practices & lesson learned
На практическом опыте планирую проиллюстрировать итерации разработки, тестирования и безопасной выкатки большой фичи - новой системы биллинга в Амплифере.
О чем речь?
Vostok Hercules - make telemetry great again!
История о том, как инженеры Контура собирали, собирают и будут собирать телеметрию с тысяч микросервисов.

Телеметрия:
- Логи
- Метрики
- Распределённые трассировки

Ключевые технологии:
- Apache Kafka
- Apache Cassandra
- Apache ZooKeeper
- Graphite
- ELK
О чем речь?
Контрактный подход к построению API зависимых приложений
Долгое время я занимаюсь разработкой систем построенных на интеграции по API с внешними системами (последние 2 года в проекте eBaymag; eBay for Sellers; занимался интеграциями с Почтой России, DHL, UPS и проч).
Основная сложность при разработке таких систем — реактивное управление ошибками и изменениями во внешних системах. Наиболее популярным подходом является использование схем запросов. Однако, в реальности, это работает только с простыми случаями.

На практике схемы API крупных систем часто устаревают (или вообще отсутствуют) и сама работа над схемами только увеличивает скоуп и снижает гибкость разработки.
В нашей работе над интеграциями хорошо себя зарекомендовал альтернативный подход, как мы его назвали — «контрактный».
Я расскажу о библиотеке, которую мы создали и используем для разработки и поддержки интеграций. О прототипе решения на Ruby, а также о работах над кросс-платформенной реализацией на Rust и Go.
О чем речь?
Практики, особенности и нюансы при работе с Postgres в Go
В докладе расскажу о практиках работы с Postgres в сервисах на Go. Поговорим о преимуществах и недостатках основных инструментов, которые принято использовать при работе с Postgres в Go. Конечно, коснёмся нюансов, которые нужно учитывать, когда ваши сервисы работают внутри Kubernetes облака.

Также расскажу об опыте Avito в предоставлении базы данных разработчикам продукта.
Слушатели смогут предупредить проблемы при работе с Postgres в своих сервисах, что позволит им избежать неявного поведения и трудно-находимых ошибок, и даже падений базы. Для разработчиков доклад будет полезен своей прикладной составляющей — как и что менять в коде, чтобы избежать ошибок.
Для DBA доклад может быть интересен благодаря свежему взгляду на нюансы работы с базой с точки зрения разработчика и позволит увидеть, на что обращать внимание при введении в строй новых сервисов.
О чем речь?
Как мыслить графами, или почему GraphQL – это не просто представление структуры БД
Доклад предназначен для тех, кто пока не разрабатывал свои API на GraphQL, а также для тех, кто попробовал и не увидел особой разницы с REST.

Мы определимся с тем, что такое GraphQL, сравним его с REST, а также по пути углубимся в философию GraphQL и ответим на следующие вопросы:
— как правильно описать сущности, поля и запросы?
— как перейти от CRUD операций к мутациям?
— как проводить эволюцию API?
— как обойти популярные уязвимости?

Доклад поможет реже наступать на грабли при разработке схемы своего первого API на GraphQL.
О чем речь?
.NET Core Application Domains
Редкий .NET разработчик задумывается о том, что такое домены приложений, для чего они нужны и как они устроены. А тем временем, с появлением на свет .NET Core, концепция изоляции сборок, загрузки/выгрузки и аспектов безопасности изменилась и теперь приходится использовать новые техники.

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

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

За счёт всего вышесказанного будем лучше понимать как работает .NET Core под капотом.
О чем речь?
Чего мы хотим от голосовых ассистентов, чтобы сбылась мечта футуриста
В JetStyle мы наработали определенный опыт работы с голосовыми помощниками и умными колонками Алексой и Алисой. И я хочу поделиться тем, какие возможности и фичи у них есть, какие грабли могут ждать, как их можно героически преодолевать и вообще, как можно готовить всю эту историю. От простого переходим к сложному: как выглядит обобщенный принцип работы, что вообще такое навык, как их писать, и как этим можно пользоваться в реальной жизни.

На примере нашего экспериментального кейса с "умной офисной переговоркой", расскажу как мы работали с Алисой, как идентифицировали пользователей, привязывали коробку железа к конкретной яндекс-станции, и что еще хочется получить от платформы Яндекс.Диалоги, чтобы она стала полноценным IoT-центром, вроде Алексы.
О чем речь?
Проектирование системы резервного копирования PostgreSQL на Go
Большие данные - это большая головная боль, когда они много меняются, и нельзя потерять ни единого байта. На Го. В докладе мы расскажем о развитии WAL-G - системы резервного копирования РСУБД PostgreSQL. На Го. Поговорим про особенности платформы при взаимодействии с большой базой открытого кода, про сообщество, про то как пареллелить и нераспараллеливаемое. На Го.
Frontend
Вадим Макеев
HTML Academy
Делайте из слона муху
Тезисы
Александр Коротаев
Tinkoff.ru
WebGL и 2D: простой как Web
Тезисы
Александр Хлебников
2ГИС
Рассылай и властвуй: верстка рассылки без боли
Тезисы
Александра Шинкевич
LOVATA
Как внедрить стандарты разработки, чтобы никто не пострадал
Тезисы
Виталий Дмитриев
404 Group
Реактивное программирование. Как мыслить реактивно, а не проактивно
Тезисы
Максим Соснов
n1.ru
Эффективное тестирование FE проектов
Тезисы
Сергей Цветков
SKB LAB
Angular Elements
Тезисы
Артём Кузвесов
индивидуальный предприниматель
React Native vs Cordova. Альтернативный взгляд на мобильную разработку
Тезисы
О чем речь?
Делайте из слона муху
У разметки, стилей и скриптов есть всё: спецификации, документация, множество конкурирующих решений, понятные лучшие практики. 25 лет спустя после появления тега <img> графика для веба — всё ещё чёртова магия, которая передаётся в устной традиции. «Мой дед всю жизнь джипеги из Фотошопа сохранял, и ничего — дожил до ста».

15 лет опыта в одном докладе: от создания и экспорта графики до оптимизации и вставки.
О чем речь?
WebGL и 2D: простой как Web
Все знают, что WebGL это очень быстро. Хочется сразу все на него переписать, но технология выглядит так, будто она прилетела в веб с другой планеты. Стандарту уже почти 9 лет, а специалистов в нем крайне мало.

Разберемся как рисовать 2D быстро, но просто, на примере написания игр, не забивая голову матрицами и сложным API. В докладе рассматриваются концепции пререндеринга, шейдеров и использования React-дерева для быстрого рисования на плоскости.
Доклад будет полезен тем, кто знает, что WebGL это быстро, но не знает с какой стороны к нему подойти.
О чем речь?
Рассылай и властвуй: верстка рассылки без боли
Кто из нас не верстал html-рассылку? Наверняка вы помните тот средневековый код, переполненный жуткими таблицами и инлайновыми стилями.
По прошествии лет письма стали краше, начали прилично отображаться на мобильных устройствах, в них даже появился интерактив.

Расскажу, как готовить рассылки в 2019 году, победить Outlook и не завязнуть в вечном багфиксе.
О чем речь?
Как внедрить стандарты разработки, чтобы никто не пострадал
В мире разработки годами не утихают споры на злободневные темы: «Табы или пробелы?», «Нужно ли делать отступы между скобками?», «Одинарные или двойные кавычки?», «Ставить ли точки с запятой в конце строк?». И это только начало списка. Но так ли уж необходимо обсуждать это каждый раз, когда начинается новый проект, делается код-ревью или в команду приходит новый разработчик? Мне кажется, что нет.

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

Многие школы и туториалы учат нас создавать сущности, которые несут прямую ответственность за управление теми или иными компонентами. В сложных больших проектах, через пару лет, это превращается в запутанный кошмар и ни один современный инструмент не способен решить данную проблему, пока разработчики пишут проактивный код.
В докладе будут раскрыты основные принципы реактивного подхода, перечислены полезные инструменты, и, самое главное, как они могут помочь в создании легко расширяемых приложений, если перестроить своё мышление при разработке на реактивное.
О чем речь?
Эффективное тестирование FE проектов
В книжках, статьях и докладах от крутых разработчиков часто идёт разговор про автотесты. "Это легко, это круто" - говорят они. Кажется, стоит только начать писать автотесты, и все проблемы сразу решатся. Какого же было мое разочарование, когда я, будучи молодым разработчиком, написал свои первые автотесты! Я не ощутил ни легкости, ни крутости, только боль. Сейчас я сам учу других людей писать *правильные* тесты. Приходите на мой доклад и мы разберемся, как же писать тесты *правильно*!
О чем речь?
Angular Elements
Декомпозиция монолитного web-приложения с помощью HTML5 Web Components, на примере фреймворка Angular.
О чем речь?
React Native vs Cordova. Альтернативный взгляд на мобильную разработку
В наше время люди с помощью смартфонов общаются в мессенджерах, сидят в социальных сетях, смотрят фильмы, делают покупки, слушают музыку, занимаются спортом, сидят в интернете и многое другое. Сейчас ещё больше сервисов уходит на мобильные устройства. В связи с этим всё больше становится востребована разработка мобильных приложений. Для их создания существует множество технологий. Чаще всего, когда заходит речь о разработке мобильных приложений силами frontend'а, имеют ввиду React Native. Но помимо этой технологии существуют и другие.

В докладе рассмотрим, какие сейчас есть технологии для мобильной разработки и наглядно сравним, как выглядят и работают идентичные приложения, одно из которых написано на React Native, а другое на Cordova. Определим сильные и слабые стороны каждого из решений.
Тестирование и QA
Антон Семенченко
COMAQA.by
Накладывает ли BDD подход Архитектурные ограничения на решения Автоматизации тестирования Front-End и Back-End?
Тезисы
Лидия Сошкина
2GIS
Приоритизация тест-кейсов
Тезисы
Антон Нечеухин
Realtimeboard
Достоверный нагрузочный тест c учетом непредвиденных нюансов
Тезисы
Алексей Лапаев
Tinkoff.ru
Инженерия качества во времена DevOps
Тезисы
Анна Боголюбова
Точка
Как отдать технический долг, не работая по выходным
Тезисы
Иван Шеломенцев
Контур
Параллелизм тестов. Основные моменты, которые стоит учитывать
Тезисы
О чем речь?
Накладывает ли BDD подход Архитектурные ограничения на решения Автоматизации тестирования Front-End и Back-End?
Внедрение BDD регулярно вызывает или неоправданный энтузиазм либо глухое упорное сопротивление технических специалистов. Возникают даже терминологические диспуты: подразумеваем BDT, говорим BDD; формулируем требования для разработчиков на Gherkin-е, не внедряя «поддерживающие» практики и называем этот, как минимум, спорный – однобокий подход «true BDD»; утверждаем что BDD и Waterfall не совместимы ...
Так что же такое BDDT на самом деле?

-Границы применимости и не применимости.
-Что может дать подход и что он дать гарантированно не может?
-Можно ли \ нужно ли использовать BDDT при работе с backend?
-Правы ли технические специалисты, рассуждая о технических ограничениях и «несвободном полете dev фантазии».
-Какие технические ограничения на Архитектуру решений Автоматизации накладывают современные BDD Engine-ы …?

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

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

Покажу, как работает наша система, на примере мобильного приложения 2ГИС. Не претендую на абсолютную истину и всеобщую универсальность, но верю, что мой доклад будет полезен всем, кто ещё не автоматизировал всё на свете и пока вынужден справляться с большим объёмом ручного регрессионного тестирования.
Слушатель получит практический гайд по приоритизации тест-кейсов
О чем речь?
Достоверный нагрузочный тест c учетом непредвиденных нюансов
Расскажу о том, как можно подойти к созданию нагрузочного теста, когда в короткие сроки необходимо выяснить лимит нашего сервиса, в момент быстрого роста количества он-лайн пользователей.


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

Во времена DevOps роли тестировщиков и QA-специалистов становятся не совсем ясны. Давайте посмотрим в будущее профессии и подумаем о том, как стоит подходить к вопросу качества, чтобы не выпадать из ритма развития сферы разработки.

Докопаемся до сути идей "shift left" и "shift right" на простых примерах. Посмотрим на агрегированную информацию по практикам и инструментарию уменьшения времени и стоимости проверок. Спроецируем пирамиду тестирования на DevOps движение и переосмыслим стратегии. Цель - понять, куда эволюционировать из условного тестировщика.
О чем речь?
Как отдать технический долг, не работая по выходным
Бэклог всегда является какой-то мусорной свалкой на "авось когда-нибудь руки дойдут". Баги и мелкие доработки копятся, на техдолг время не выделяется - всегда есть приоритетные задачи на сейчас, техдолг потом, "когда спокойней будет". А ещё бывает так, что вот есть проект, есть MVP, уже выкатили первый релиз и радуемся, а про всякие остальные доработки, которые могут обрадовать клиента, забываем, бежим дальше к следующему проекту. И все вот такие мелкие задачки копятся и остаются где-то на дне бэклога, на потом, на авось. Клиенты страдают, разрабы страдают поддерживать говнокод и мечтают о выделенном дне рефакторинга, тестеры страдают больше всех. Но что делать: постоянно появляются новые проекты, новые идеи, которые несут большие деньги, статус компании, престиж и т.д., и конечно же, приоритет уходит на выполнение этих действий.

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

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

Но запуская тесты, мы столкнулись с тем, что на тестовых машинах нагрузка ЦП не достигает даже 20%. А это значит, что неэффективно расходуется машинное время и обратная связь до разработчика доходит дольше, чем могла бы.

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

А так же отвечу на вопросы правда ли, что:
Assert.IsTrue в NUnit -- это сладкий if-esle?
Assert.Throws -- это сладкий try-catch-finally?
При использовании атрибута Parallelizable(ParallelScope. All) создаётся несколько экземпляров [TestFixture] класса?
Какие типы данных можно использовать в аттрибуте [TestCase]
Как можно добиться параллелизма, не используя атрибут Parallelizable?
Как можно сравнивать объекты со сложной структурой?

Если вы знаете ответы на все эти вопросы, то приходите и помогите рассказать остальным.
Management
Анастасия Калашникова
Психолог в IT, создатель школы SoftSkills для разработчиков
Этика и правила собеседований. Как вести собеседование и получать результат для себя, команды и компании
Тезисы
Иван Сухов
самозанятый
Делегирование - отстой!
Тезисы
Булкина Наталья
bulkina.tech
Беспроблемные "проблемные" интервью: как качественно пообщаться с клиентом, чтобы проверить жизнеспособность вашей бизнес-идеи
Тезисы
Алексей Жуков
Контур
Как мы в Контуре тестируем гипотезы перед выпуском продуктов и фич
Тезисы
Алексей Долгушев
Долгушев и Старожилов
Этот модный DevRel и как это поможет людям узнать о вашей компании так, чтобы им хотелось работать у вас
Тезисы
Алексей Катаев
SkyEng
Как я всё успеваю: тайм менеджмент для тимлида
Тезисы
Светлана Аюпова
SkyEng
Продуктовый цикл проверки гипотез от продуктовой команды №1 в России
Тезисы
О чем речь?
Делегирование - отстой!
Есть масса обучающих материалов, которые рассказывают как делегировать, и что случится, если этого не делать. Однако, оглянувшись, можно увидеть, как даже самые опытные менеджеры пренебрегают делегированием. Почему так происходит? Как выбрать между "сделать самому" и отдать исполнителю?

Делегирование - это не освобождение от задачи, а контроль вместо исполнения. Контроль - неестественная задача для мозга, которому проще реагировать на среду, чем регулярно на неё влиять.
Постановка задачи - половина решения. Постановка задачи по SMART и перенос всего контекста исполнителю может оказаться сложнее решения.
Компетенции. Целесообразнее дать рыбу или удочку?
Мотивация. Уверены ли мы, что исполнитель так же стремится решить задачу, как и мы? Стремится ли решить оптимальным путём? (Спойлер: обычно нет.)
Политика. Кто последним попадёт под сокращения в тяжёлые времена?
О чем речь?
Этика и правила собеседований. Как вести собеседование и получать результат для себя, команды и компании
Большинство ИТ-компаний постоянно находится в поиске ценных кадров. И если почти все разработчики знают, как оценить hard skills кандидата, то с оценкой soft skills на собеседовании всё сложнее.

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

Расскажу, как практикующий психолог в настоящем и IT HR в прошлом.
О чем речь?
Беспроблемные "проблемные" интервью: как качественно пообщаться с клиентом, чтобы проверить жизнеспособность вашей бизнес-идеи
Проблемные интервью позволяют проверить гипотезу еще до того, как вы начинаете дорогостоящую разработку продукта. Этот (на первый взгляд) простой инструмент позволяет сэкономить основателям миллионы за счет того, что на раннем этапе проекта максимально четко определяется истинная боль клиента. Основная цель проведения интервью - перестать делать продукты для себя и начать делать их для своего клиента. Ведь только довольные клиенты платят нам деньги и только довольные клиенты к нам возвращаются.

Мы поговорим о том как делать эффективные интервью, а также разберем основные ошибки, которые могут привести к неверным результатам.
О чем речь?
Как мы в Контуре тестируем гипотезы перед выпуском продуктов и фич
5 шагов от идеи до отлаженного бизнеса:
- customer development как модель для построения growth-команды
- жизненные примеры о создании и развитии продуктов для рынка b2b
- что должен уметь корпоративный предприниматель (и не корпоративный, но это не точно)
О чем речь?
Этот модный DevRel и как это поможет людям узнать о вашей компании так, чтобы им хотелось работать у вас
В компаниях А и Б придумали одну и ту же мысль: "Давайте станем более заметными в профессиональном сообществе". Для заметности обе компании сделали один и тот же трюк: отправили своих сотрудников выступать на конференциях.

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

Почему так? Чем меньше стараешься, тем лучше выходит? Иногда ничего не поделать — тебе просто не везёт? Некоторым компаниям лучше и не пробовать даже?
Отличие вот в чём: А и Б находятся на разных стадиях DevRel-зрелости. По-разному используют потенциал своего DevRel-положения.

Что такое DevRel. Как определить и правильно использовать стадию DevRel-зрелости вашей компании. Долго ли радоваться А. Как исправлять ситуацию в Б. И главное: как сделать так, чтобы люди не просто знали о вас, но хотели у вас работать. Расскажу об этом в докладе.

История по мотивам опыта ведения DevRel-проектов в 10 компаниях и 10 лет наблюдений за IT-индустрией.
О чем речь?
Как я всё успеваю: тайм менеджмент для тимлида
Пару лет назад я работал по 12 часов в день, ненавидел утро понедельника и откладывал задачи на выходные, когда никто не беспокоит. Но всё равно ничего не успевал.

Два года ушло на то, чтобы "привести дела в порядок". Это скилл №1, который помог мне: 1) Получать больше удовлетворения от работы 2) Больше времени отдыхать с семьей 3) Делать свою работу ещё круче. Теперь я евангелист тайм-менеджмента.

Я поделюсь опытом борьбы с прокрастинацией, приёмами автоматизации, делегирования, кучей чеклистов и лайфхаков - всем, что выстрадано и что применяю я сам. После доклада твоя жизнь не улучшится. Как и после прочтения книги или скачивания нового таск-трекера. Придётся регулярно работать, как в тренажёрке. Но потраченное время начнёт окупаться практически сразу!
О чем речь?
Продуктовый цикл проверки гипотез от продуктовой команды №1 в России
1. С чего начинается продуктовый цикл проверки гипотезы
- HADI-циклы
- От дешевой неизвестности к дорогой точности
- Убить гипотезу
- Коммон сенс и аналитика, аналитика и коммон сенс

2. Гипотеза
- Ищем основу: чтобы что? Какая метрика важна?
- Проблемные интервью (кастдев, да-да!), качественное, потом количественное исследования
- Пички и странности в аналитике
- Обращения клиентов и обращения в поддержку
- Логика и опыт – смотрим на рынок

3. Решение
- Решенческое интвервью
- недоMVP
- коридорные тесты

4. Подтверждаем ценность и сводим экономику
- Упрощенная схема: кейс с расшариванием в фб
- Mvp и sales first

5. Тест на бою
- Продуктовый дизайнер – не просто дизайнер.
- Разработка – искать баланс скорости и качества
- Тестирование – не фичу, а флоу
- Сплит-тесты: всегда считаем до запуска и до самого конца
- Опережающие и ограничивающие метрики

6. Выводы
- Если вы стартап, то продажа – проверка любой гипотезы.
- Если вы Дофига Крупная Компания – стройте команду и процессы, а не продукт
- Если вы продукт, живите продуктами, ваше главное достоинство – умение действовать и принимать решения, когда данных мало.
DevOps
Руслан Серкин
DataArt
Особенности разработки на Serverless
Тезисы
Евгений Фоменко
Мегафон
Опыт изменения подхода внедрения: от релизов до фасттрека
Тезисы
Михаил Радионов
Веб-студия Флаг
CI для бедных, или стоит ли писать свой CI для веб-студии
Тезисы
Владимир Лила
Контур
Эластик весом в петабайт
Тезисы
Виктор Еремченко
Miro (formerly Realtimeboard)
Как мы уменьшили количество откатов серверных релизов на 99%
Тезисы
О чем речь?
Особенности разработки на Serverless
Я помогу избежать основных ошибок при старте разработки с применением serverless технологий
О чем речь?
Опыт изменения подхода внедрения: от релизов до фасттрека
О чем будем говорить?
- Внедрение в условиях масштабной архитектурной трансформации.
- Высокоскоростное внедрение изменений в распределенной инфраструктуре компании.
- Способы достижения быстрого цикла внедрения.
- Объединенные кросс-функциональные команды как целевая схема взаимодействия с производством вендора.
- Качество и автоматизация тестирования в условиях непрерывного внедрения.
- Влияние непрерывного развертывания на эксплуатационные показатели.
О чем речь?
Стоит ли писать свой CI для веб-студии
История о том, как и зачем мы написали свой CI в экосистеме Laravel для работы с множеством разных небольших проектов
О чем речь?
Эластик весом в петабайт
В компании СКБ Контур Elasticsearch развернут очень давно, мы пережили с ним многое: миграцию 200tb данных из Elasticsearch2 в Elasticsearch6, нехватку места и производительности, мы написали несколько собственных инструментов для работы с эластиком и пользуемся большим количеством готовых.

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

В докладе поговорим как про организацию процесса, транспорт логов, так и про технические детали построения подобного кластера, частые ошибки и про пользу от всего этого!
О чем речь?
Как мы уменьшили количество откатов серверных релизов на 99%
Я расскажу о том, как мы подошли к процессу непрерывной доставки, и как эти подходы помогли сократить количество откатов серверного релиза; о том как это помогает командам быстро и удобно доставлять свой функционал до production.

Доклад содержит в том числе реальные примеры использования различных инструментов и технические детали CI/CD процесса.
Mobile
Александр Денисов
EPAM
Flutter: Реактивная архитектура
Тезисы
Павел Стрельченко
HeadHunter
Фантастические плагины и где они обитают
Тезисы
Евгений Кривобоков
AVITO
Ускорение сборки многомодульного Android-приложения
Тезисы
Никита Русин
KODE
Базовый проект - решение проблем разработки нескольких продуктов
Тезисы
Игорь Таланкин
Tinkoff.ru
Пишем свои правила для Android lint
Тезисы
Денис Малых
Яндекс
Рефакторинг: быть или не быть?
Тезисы
Владимир Теблоев
Сбербанк
Инструменты для решения проблем в большой команде
Тезисы
Николай Волосатов
Яндекс
Private API: темная сторона iOS разработки
Тезисы
О чем речь?
Flutter: Реактивная архитектура
Обзор Flutter.
Асинхронное программирование в Dart.
Выбор архитектуры для приложения на Flutter. Плюсы и минусы.
BloC архитектура в деталях и примерах.
Вечный вопрос - кроссплатформа или натив?
Что изменилось с появлением Flutter
О чем речь?
Фантастические плагины и где они обитают
В докладе я докажу, что разработать плагин - подъёмная задача для любого разработчика.

Расскажу, как в HH.ru сделали плагин для создания feature-модулей: почему решили написать именно плагин и почему не подошли существующие решения генерации кода; с какими проблемами сталкивались и как их решали.

Раскрою несколько секретов плагиностроения: что такое PSI, как создавать собственные wizard-диалоги и как использовать встроенный DI; а также покажу исходники и расскажу, что в них поменять для решения ваших задач.
О чем речь?
Ускорение сборки многомодульного Android-приложения
Расскажу как мы прокачали сборку в монорепозитории с несколькими приложениями. В основном, будем говорить про gradle, оптимизации, метрики и про наши грабли. Также будут практические советы по ускорению сборки и IDE, разной сложности; настройка и оптимизация gradle remote cache и как самостоятельно собрать метрики без покупки Gradle Enterprise
О чем речь?
Базовый проект - решение проблем разработки нескольких продуктов
Использование разного стека технологий на нескольких проектах приводит к проблемам: потеря времени на погружение при переходе разработчиков между проектами, а решения сложно переносить.

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

Расскажу про то, зачем и как можно создать базовый проект в компании, что он в себя включает, какие преимущества даёт, как компенсировать недостатки и куда можно двигаться после этого.
О чем речь?
Пишем свои правила для Android lint
Написание собственных правил для Lint'а сопряжено с болью: в основном потому, что в свободном доступе почти нет информации о том, как это делать. Документация о многом не говорит, статей по теме очень мало.

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

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

Я расскажу о том, как справиться с тем, что в какой-то момент времени над одним приложением начинает работать большое количество людей, и что делать для того, чтобы всё не рассыпалось как карточный домик.
О чем речь?
Private API: темная сторона iOS разработки
Доклад про вещи, о которых принято говорить шепотом, - про приватный API iOS.

Рассмотрим способы изучить скрытый системный API , а также поговорим о последствиях его использования. Вы узнаете историю "преступления и наказания", случившуюся в команде AppMetrica. Также поднимем вопросы защиты со стороны системы и прикладного кода.
Design
Алёна Кирдина
Evil Martians
Error driven design
Тезисы
Константин Остроухов
JetStyle
Магия Generative design — как освоить дизайнеру?
Тезисы
Анастасия Шаповалова
Naumen
Простые способы узнать своего пользователя и не облажаться
Тезисы
Александра Руденко
Бюро сервисного дизайна
Сервисный дизайн и Customer Experience Management: что-то новое или все то же, но другими словами?
Тезисы
Дарья Прокуда
BeaversBrothers
Хочу быть арт-директором, а можно прям из дома? Ищу наставника, а где их выдают?
Тезисы
Григорий Савенок
Мегафон
Как презентовать дизайн не дизайнерам
Тезисы
Алексей Кулаков
Ridero
Как дизайнеру давать и принимать фидбэк
Тезисы
Сергей Кривой
SEMrush
Воркшоп: Problem Engineering – Дизайн Проблем
Тезисы
О чем речь?
Error driven design
Итак, вы пришли работать дизайнером в давно существующий продукт.
Как за ним ухаживать, какие проблемы решать в первую очередь и всегда ли лучшие решения лежат в плоскости интерфейса?

Расскажу, как мы за год поставили на ноги eBay для бизнеса, руководствуясь не интервью, аналитикой и внезапными инсайтами… А списком ошибок в сценарии его использования.
О чем речь?
Магия Generative design — как освоить дизайнеру?
В рамках доклада я расскажу:
— Про генеративный дизайн и то, с помощью каких инструментов он создается;
— На основе примеров из своего instagram-проекта про генеративный дизайн объясню приемы, которые использую.
Например, как с помощью кода сделать кинетическую типографику, интерактивные анимации и генеративную графику от системы частиц до создания паттернов;

Покажу как интерактивная реалтайм-графика и анимация реализуются в браузере;
а также покажу некоторые заметные проекты со всего мира, которые используют генеративный дизайн.
О чем речь?
Как презентовать дизайн не дизайнерам
Как защищать решения с первого раза и не получать комментариев про шрифты, цвета и кнопки.
Тема будет актуальна как для дизайнеров, так и для менеджеров.
О чем речь?
Сервисный дизайн и Customer Experience Management: что-то новое или все то же, но другими словами?
Узнаем, с помощью каких исследований построить Customer Experience Map и какие задачи дизайнеров она решает.
Увидим, как можно охватить весь путь клиента и переходы между онлайном и офлайном на одной карте, чтобы учитывать контекст клиента при разработке продуктов.
Познакомимся с деталями опыта применения CX-исследований в управляющей компании Лига ЖКХ, системе doma. ai и сети винотек МАВТ-Винотека
О чем речь?
Хочу быть арт-директором, а можно прям из дома? Ищу наставника, а где их выдают?
Какой дизайнер не хочет стать арт-директором? Арт-директора крутые. Все дизайнеры хоть раз хотели стать арт-директором или тайно мечтали об этом. Расскажу на своем опыте, как оно быть этим зверем и как понять, твое ли это.

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

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

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

Из доклада вы узнаете:
1) Что должен знать дизайнер о команде разработки.
2) Что должна знать команда о UX/UI дизайнере.
3) Проблемы взаимодействия дизайнера и команды разработки и причины их возникновения.
4) О чем обязательно нужно договариваться дизайнеру и команде.

Доклад работает лучше, чем сеанс психотерапевта для обеих сторон: дизайнеров и разработчиков. Приглашаем вторую сторону прийти на доклад и задать свои вопросы :)
О чем речь?
Воркшоп: Problem Engineering – Дизайн Проблем
Когда смотришь на некоторые продукты, возникает вопрос: «У создателей стояла задача сделать действительно плохой продукт? Если да, то они великолепно справились». Лучше всего люди замечают проблемы, поэтому предлагаю попробовать их создавать.

Попробуем на практике способ проектирования новых продуктов основанный на том, чтобы заставить всех заинтересованных лиц думать не о фичах, а о проблемах, которые они могут решить. Будем генерировать самые плохие решения для различный цифровых продуктов. Затем, в ходе инверсии проблем в решение, получать хороший продукт с акцентом на проблемы пользователей. И все это всего в две итерации: создание проблем — инверсия.

Участники воркшопа поймут, как можно концентрироваться на проблемах пользователя и решать их боли. Так же у них в руках будет метод вовлечения своей команды разработки или заказчика в фокусировку над проблемами при решении задач. И это будет нескучно :)
О чем речь?
Простые способы узнать своего пользователя и не облажаться
Что делать, когда нужно понять, кто твой клиент и чего он хочет, а ресурсов для поиска ответов нет?

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

А так же расскажу, как затеять редизайн без дизайнера, немного облажаться, но в итоге остаться на коне и вернуть к жизни забытую фичу.
О чем речь?
Как дизайнеру давать и принимать фидбэк
Я считаю что фидбек – царь навык. Я имею в виду, что это главное, чему нужно учиться. Всегда. Его нельзя перестать вкачивать, с ним все становится лучше.

Смотрите: берем стажера, учим его принимать фидбек, БАЦ, у нас есть джун. Берем дизайнера, учим его давать фидбек БАЦ, у нас есть арт-директор. Берем артдиректора, учим его давать фидбек самому себе – и он становится тем, кем он хочет быть и идет к этому.

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

Кстати, один из главных приемов фидбека – не думать, что вы знаете истину (от таких никто не принимает фидбек). Поэтому не думайте, что я знаю истину. Я такой же неуклюжий гоблин, как и вы, сэр, и просто расскажу вам о костылях, которыми я поддерживаю свой слабый разум.
Science
Игорь Мамай
Контур
Та самая база для понимания квантовых алгоритмов
Тезисы
Владислав Блинов,Валерия Баранова
Tinkoff.ru
Deep Learning vs common sense: разрабатываем чатбота с умом
Тезисы
Николай Куклин
Ceramic 3D
Адаптивный антиалиасинг на GPU
Тезисы
Геннадий Штех
Naumen
Настоящее и будущее алгоритмов на текстах: NLP и production
Тезисы
Татьяна Зобнина
Naumen
Анализ взаимосвязей между переменными в эпоху машинного обучения
Тезисы
О чем речь?
Та самая база для понимания квантовых алгоритмов
Многие из нас с интересом открывали статью про новый язык программирования для квантовых компьютеров, ожидая найти в ней что-то интересное. Но не дочитав и до середины, закрывали ее с мыслью «Ничего не понятно» или «Слишком сложно».

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

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

Для чего нужен алгоритм?
Одна из проблем в компьютерной графике — алиасинг, так называется эффект ступенчатости на границах поверхностей. У этой проблемы есть очень дорогое решение — получение изображения гораздо большего размера с последующим его уменьшением. При этом 75% расчётов являются лишними, они не влияют на итоговое изображение.
Мы придумали и реализовали свой алгоритм сглаживания изображений, существенно уменьшающий количество дополнительных вычислений без ущерба качеству картинки. Т. е. если сравнить изображение, сглаженное по нашему алгоритму и изображение после полноэкранного сглаживания, то они зрительно не отличаются, а время рендера сокращается в 4 раза.
Сначала в докладе обсудим как эффективно программировать для видеокарт: шейдеры и параллельные вычисления. Затем расскажем о проблеме алиасинга и своём работающем решении этой проблемы.

3 причины прийти на доклад:
1. Вы узнаете новые концепции программирования, так как программирование на шейдерах сильно отличается от классического — оно распараллеливает мозг!
2. Получите представление о способах получения смоделированных фотореалистичных изображений
3. Узнаете, как справиться с проблемой алиасинга без больших затрат
О чем речь?
Deep Learning vs common sense: разрабатываем чатбота с умом
Для чего действительно нужны нейронные сети? Разбираемся на примере чатбота, когда нужно реализовывать state-of-the-art научную статью, в каких случаях можно обойтись логистической регрессией, а когда лучше вспомнить про старое-доброе префиксное дерево.
О чем речь?
Анализ взаимосвязей между переменными в эпоху машинного обучения
Зачем и как анализировать данные в эпоху «больших данных» и машинного обучения?
Можно ли обойтись анализом «черных ящиков»? И в каких задачах анализа взаимосвязей между переменными не избежать?
Разберемся, почему не стоит прогнозировать финансовые рынки, но как прогнозировать личные доходы и расходы.
Рассмотрим графы и модифицированный алгоритм Демпстера как инструмент для наглядного и интерпретируемого анализа взаимосвязей между переменными.
О чем речь?
Настоящее и будущее алгоритмов на текстах: NLP и production
Доклад для разработчиков и бизнеса.

Начнем с эволюции NLP: как произошел переход от Natural Language Processing к Natural Language Understanding, чему научились нейросети за 2018 год и какие задачи над текстами ученые теперь могут решать автоматически.

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

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