ПРОГРАММА 2019

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

Недавно в Redis 5 появились новый тип данных - streams, это реализация идей из популярного брокера сообщений Kafka.
Обсудим зачем нужны стримы, чем они отличаются от обычных очередей.
Доклад сфокусирован именно на выяснение целей и задач для которых придуманы стримы.
Обсудим разницу между Kafka и Redis streams, а также "подводные камни", которые нас подстерегают.

Вопросы, на которые отвечает доклад:
- С чего начать внедрение речевых технологий и как продать это бизнесу?
- Из чего состоит голосовой сервис, какие есть инструменты?
- Что разрабатывать самостоятельно, а что лучше переиспользовать, в каком порядке?
- Как выбрать сценарии и проводить эксперименты?

О чем расскажем:
- ASR и TTS. Облачные и back'end технологии, MRСP и API, подводные камни
- Сценарии диалога. С чего начали, как они выглядят в коде, какие данные собирали
NLU. От ключевых слов к машинному обучению
- Результаты. Что получилось в итоге

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

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

Ключевые технологии:
- Apache Kafka
- Apache Cassandra
- Apache ZooKeeper
- Graphite
- ELK

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

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

В докладе расскажу о практиках работы с Postgres в сервисах на Go. Поговорим о преимуществах и недостатках основных инструментов, которые принято использовать при работе с Postgres в Go. Конечно, коснёмся нюансов, которые нужно учитывать, когда ваши сервисы работают внутри Kubernetes облака.

Также расскажу об опыте Avito в предоставлении базы данных разработчикам продукта.
Слушатели смогут предупредить проблемы при работе с Postgres в своих сервисах, что позволит им избежать неявного поведения и трудно-находимых ошибок, и даже падений базы. Для разработчиков доклад будет полезен своей прикладной составляющей — как и что менять в коде, чтобы избежать ошибок.
Для DBA доклад может быть интересен благодаря свежему взгляду на нюансы работы с базой с точки зрения разработчика и позволит увидеть, на что обращать внимание при введении в строй новых сервисов.

Доклад предназначен для тех, кто пока не разрабатывал свои API на GraphQL, а также для тех, кто попробовал и не увидел особой разницы с REST.

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

Доклад поможет реже наступать на грабли при разработке схемы своего первого API на GraphQL.

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

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

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

За счёт всего вышесказанного будем лучше понимать как работает .NET Core под капотом.

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

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

Большие данные - это большая головная боль, когда они много меняются, и нельзя потерять ни единого байта. На Го. В докладе мы расскажем о развитии WAL-G - системы резервного копирования РСУБД PostgreSQL. На Го. Поговорим про особенности платформы при взаимодействии с большой базой открытого кода, про сообщество, про то как пареллелить и нераспараллеливаемое. На Го.

У разметки, стилей и скриптов есть всё: спецификации, документация, множество конкурирующих решений, понятные лучшие практики. 25 лет спустя после появления тега <img> графика для веба — всё ещё чёртова магия, которая передаётся в устной традиции. «Мой дед всю жизнь джипеги из Фотошопа сохранял, и ничего — дожил до ста».

15 лет опыта в одном докладе: от создания и экспорта графики до оптимизации и вставки.

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

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

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

Расскажем, какие реальные грабли мы собрали при переносе нашего большого приложения на C++ в браузер.

Мы обсудим:
- какие есть инструменты и что они могут;
- как пробрасывать объекты между JS и Wasm;
- какие при этом возникают проблемы и как их решить;
- что может Wasm, и чего он не может;
- как увидеть код C++ в отладчике браузера;
- насколько Wasm быстрее JS.

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

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

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

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

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

Декомпозиция монолитного web-приложения с помощью HTML5 Web Components, на примере фреймворка Angular.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать, когда нужно понять, кто твой клиент и чего он хочет, а ресурсов для поиска ответов нет?

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

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

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

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

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

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

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

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

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

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

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

Большинство ИТ-компаний постоянно находится в поиске ценных кадров. И если почти все разработчики знают, как оценить hard skills кандидата, то с оценкой soft skills на собеседовании всё сложнее.

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

Расскажу, как практикующий психолог в настоящем и IT HR в прошлом.

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

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

5 шагов от идеи до отлаженного бизнеса:
- customer development как модель для построения growth-команды
- жизненные примеры о создании и развитии продуктов для рынка b2b
- что должен уметь корпоративный предприниматель (и не корпоративный, но это не точно)

В компаниях А и Б придумали одну и ту же мысль: "Давайте станем более заметными в профессиональном сообществе". Для заметности обе компании сделали один и тот же трюк: отправили своих сотрудников выступать на конференциях.

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

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

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

История по мотивам опыта ведения DevRel-проектов в 10 компаниях и 10 лет наблюдений за IT-индустрией.

Пару лет назад я работал по 12 часов в день, ненавидел утро понедельника и откладывал задачи на выходные, когда никто не беспокоит. Но всё равно ничего не успевал.

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

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

1. С чего начинается продуктовый цикл проверки гипотезы
- HADI-циклы
- От дешевой неизвестности к дорогой точности
- Убить гипотезу
- Коммон сенс и аналитика, аналитика и коммон сенс

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

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

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

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

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

Внедрение BDD регулярно вызывает или неоправданный энтузиазм либо глухое упорное сопротивление технических специалистов. Возникают даже терминологические диспуты: подразумеваем BDT, говорим BDD; формулируем требования для разработчиков на Gherkin-е, не внедряя «поддерживающие» практики и называем этот, как минимум, спорный – однобокий подход «true BDD»; утверждаем что BDD и Waterfall не совместимы ...
Так что же такое BDDT на самом деле?

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

Давайте все вместе попробуем дать ответы на все эти вопросы. Приходите – будет интересно и holywar-но.

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

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

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

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


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

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

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

Докопаемся до сути идей "shift left" и "shift right" на простых примерах. Посмотрим на агрегированную информацию по практикам и инструментарию уменьшения времени и стоимости проверок. Спроецируем пирамиду тестирования на DevOps движение и переосмыслим стратегии. Цель - понять, куда эволюционировать из условного тестировщика.

Бэклог всегда является какой-то мусорной свалкой на "авось когда-нибудь руки дойдут". Баги и мелкие доработки копятся, на техдолг время не выделяется - всегда есть приоритетные задачи на сейчас, техдолг потом, "когда спокойней будет". А ещё бывает так, что вот есть проект, есть MVP, уже выкатили первый релиз и радуемся, а про всякие остальные доработки, которые могут обрадовать клиента, забываем, бежим дальше к следующему проекту. И все вот такие мелкие задачки копятся и остаются где-то на дне бэклога, на потом, на авось. Клиенты страдают, разрабы страдают поддерживать говнокод и мечтают о выделенном дне рефакторинга, тестеры страдают больше всех. Но что делать: постоянно появляются новые проекты, новые идеи, которые несут большие деньги, статус компании, престиж и т.д., и конечно же, приоритет уходит на выполнение этих действий.

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

Как долго вы ждёте результаты выполнения тестов?
Стремитесь ли вы к оптимальной нагрузке на тестовой тачки?

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

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

В докладе расскажу о том, как можно загрузить ЦП на номинальную нагрузку с помощью NUnit 3.10.* (C#) и/или mocha.parallel (JS) вместо покупки дорогостоящего железа.

Сколько экземпляров [TestFixture] класса создаётся при использовании атрибута Parallelizable(ParallelScope. All)?
Как можно добиться параллелизма, не используя атрибут Parallelizable?

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

В команде разработки нет выделенных автотестеров, и мы не хотим их нанимать. Поэтому разработчики пишут тесты всех уровней (включая UI) до передачи задачи в тестирование. А тестеры делают код-ревью и дописывают недостающие автотесты.
При этом у тестеров нет власти. Мы не можем приказать разработчикам: "Все пишите тесты!". Приходится договариваться.

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

Многие из нас прокручивают в голове прошедшие или будущие диалоги. Какими они могли быть, что надо было сказать. «В другой раз я обязательно выйду победителем».

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

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

Ведущий: Дмитрий Якин, программный директор секции Тестирование и QA.

Многие из нас с интересом открывали статью про новый язык программирования для квантовых компьютеров, ожидая найти в ней что-то интересное. Но не дочитав и до середины, закрывали ее с мыслью «Ничего не понятно» или «Слишком сложно».

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

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

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

Я расскажу:

• про изменения происходящие в науке
• что такое научные данные
• почему так важно сохранять «сырые данные»
• про требования к архитектуре научных баз данных.

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

Для чего действительно нужны нейронные сети? Разбираемся на примере чатбота, когда нужно реализовывать state-of-the-art научную статью, в каких случаях можно обойтись логистической регрессией, а когда лучше вспомнить про старое-доброе префиксное дерево.

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

Доклад для разработчиков и бизнеса.

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

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

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

Одна из самых известных причин вероятного конца света, как регулярно намекают средства массовой информации — столкновение Земли с космическим объектом крупных размеров.

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


Насколько велика опасность и реальна ли вообще угроза — узнаем на примере события, произошедшего 15 февраля 2013 года вблизи Челябинска.

Может ли человечество оградить себя от астроидно-кометной опасности?

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

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

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

Можно ли внести изменения в программу старения организма? Сможет ли человек жить 150 — 200 лет?
Посмотрим как исследования последних 10 лет изменили ответы на эти вопросы.

Я помогу избежать основных ошибок при старте разработки с применением serverless технологий

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

История о том, как и зачем мы написали свой CI в экосистеме Laravel для работы с множеством разных небольших проектов

В компании СКБ Контур Elasticsearch развернут очень давно, мы пережили с ним многое: миграцию 200tb данных из Elasticsearch2 в Elasticsearch6, нехватку места и производительности, мы написали несколько собственных инструментов для работы с эластиком и пользуемся большим количеством готовых.

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

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

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

Доклад содержит в том числе реальные примеры использования различных инструментов и технические детали CI/CD процесса.

Обзор Flutter.
Асинхронное программирование в Dart.
Выбор архитектуры для приложения на Flutter. Плюсы и минусы.
BloC архитектура в деталях и примерах.
Вечный вопрос - кроссплатформа или натив?
Что изменилось с появлением Flutter

В докладе я докажу, что разработать плагин - подъёмная задача для любого разработчика.

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

Раскрою несколько секретов плагиностроения: что такое PSI, как создавать собственные wizard-диалоги и как использовать встроенный DI; а также покажу исходники и расскажу, что в них поменять для решения ваших задач.

Расскажу как мы прокачали сборку в монорепозитории с несколькими приложениями. В основном, будем говорить про gradle, оптимизации, метрики и про наши грабли. Также будут практические советы по ускорению сборки и IDE, разной сложности; настройка и оптимизация gradle remote cache и как самостоятельно собрать метрики без покупки Gradle Enterprise

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

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

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

Написание собственных правил для Lint'а сопряжено с болью: в основном потому, что в свободном доступе почти нет информации о том, как это делать. Документация о многом не говорит, статей по теме очень мало.

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

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

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

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

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

Доклад про вещи, о которых принято говорить шепотом, - про приватный API iOS.

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

Квиз - формат командной интеллектуальной игры, где ведущий задаёт вопрос, а команды дают ответы.
Это чем-то похоже на командную "Что? Где? Когда?", только весело и про JavaScript!

Неважно, насколько ты знаешь JavaScript - полный NaN или настоящий JavaScript ninja - ты в любом случае узнаешь много нового и интересного!
А если ты реально адепт магии фронтенда, то у тебя есть шанс доказать это всем!

Команда-победитель получит призы :)

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

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

За 1,5 часа вы научитесь определять реальные проблемы и боли пользователя и делать дизайн, который снимает эти боли.
А еще у вас в руках будет метод вовлечения команды разработки или команды заказчика в решение проблем пользователя.
И это будет нескучно :)

Программа:
- Основы реактивного программирования
- Контроль потоков и подписок
- Решение реальных задач простым и элегантным способом
- Разделение побочных эффектов и бизнес-логики
- Реактивный MVC или новый взгляд на State Management

Приглашаю всех, кто хочет окунуться в мир РФП или закрепить свои знания в этом направлении.

Patroni становится де-факто стандартом для построения отказоустойчивых кластеров Постгрес.
В мастер-классе мы построим простой отказоустойчивый кластер из 3х нод на перечисленном стеке. (На первый взгляд не выглядит простым).

Мы кратко познакомимся с архитектурой patroni, обсудим наиболее интересные параметры конфигураций.

Посмотрим, как работает файловер и какими способами можно проинициализировать кластер.

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

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

Для работы вам понадобится ноутбук с доступом в интернет и websocket-совместимый браузер (Chrome, Firefox).

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

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

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

Вкладываете много ресурсов в техпиар, а результат неочевиден? Что замерять? Где взять необходимые данные? Как определить, сколько усилий стоит вложить в повышение узнаваемости своего HR-бренда?

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

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

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

Если вы не teamlead, берите инициативу в свои руки. Доклад поможет вам сформировать критерии для проверки себя.

- Одежда как способ самовыражения программистов в разные времена: советские инженеры, Силиконовая долина, индийский шик.
- Рассказ о проекте под кодовым названии Гардеробот и аналогов, которые, используя машинное обучение, подбирают индивидуальный стиль в одежде. Как ИИ оденет человека?
- Ревью модных домов, использующих IT-технологии.
- Мода во мне — мешает или помогает вести бизнес синяя борода.