ПРОГРАММА 2019

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

Сетевые коммуникации в современном бэкенде — это множество конкурирующих протоколов, стандартов и подходов. У нас есть «REST», который каждый разработчик реализует по-своему, есть пересекающиеся JSON Schema и Open API, есть JSON API, GraphQL, gRPC, из-за угла выглядывает RAML.

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

DDD предлагает как стратегические инструменты (единый язык и тесное взаимодействие с экспертами предметной области, разделение домена на контексты, подчинение технологий задачам бизнеса), так и тактические (Entity и Value Object, спецификации и агрегаты).

Несмотря на то, что инструменты вроде бы «есть», многие команды сталкиваются с проблемами, пытаясь разрабатывать проект «по DDD». Я думаю, что причина в том, что в оригинальной книге инструменты даны «обзорно», без деталей реализации.

В докладе рассматриваются приемы проектирования домена в DDD-стиле, их сильные и слабые стороны на примере C# и чуть-чуть F#.

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

Рассмотрим особенности использования REST API Elastic:

• Как повысить утилизацию ресурсов кластера Elastic, что и как влияет на производительность
• Особенности хранения логов в Elastic

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

Краткий обзор принципов работы строковых и колоночных баз данных
Краткий обзор реализаций: postgres, postgres-ctore, clickhouse, memsql
Место, занимаемое логами
Сравнение скорости работы строчной и колоночных баз данных для задачи анализа логов.

AWS Lambda от Amazon достаточно новая, но интересная и перспективная технология, впервые увидевшая свет чуть менее 5 лет назад. В своем докладе я расскажу как мы разрабатывали с нуля и докатили до прода в достаточно короткие сроки систему на базе AWS Lambda.
Основная задача системы — запуск ML моделей для генерации предсказаний по заданным гипотезам. Однако архитектура получилась достаточно гибкая и позволяет расширять набор моделей практически «на лету».
Я расскажу о некоторых особенностях работы с AWS Lambda, а также немного ближе познакомлю с облачными сервисами Amazon (SQS, SNS, EC2, S3, etc.)

Чтобы делать хороший код-ревью мало просто смотреть на код и писать свое мнение о нем

• Необходимо определиться с целью: зачем мы вообще ревьим код? Каждый вкладывает в процесс что-то свое: от обучения до дизайн-ревью
• Нужно подготовить кучу всего: размер кода, размер задачи и ее постановку, описание проблемы и ее решения
• Затем очистить код от примесей и ошибок, которые не должен проверять человек: от архитектурных до пропущенных пробелов
• Проверить оформление и следование регламенту: конечно, автоматически
• Правильно выбрать ревьюера: конечно, автоматически
• Затем совершить сам акт общения и ревью: по делу, жестко, но без агрессии
• Собрать обратную связь: ощущения и факты
• И последний шаг: проревьюить ревью!

В современном мире разработки ПО сложно представить проект, в состав которого не входили бы компоненты с открытым исходным кодом или open source.

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

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

Расскажу текущее состояние набирающего популярность компилируемого фреймворка SvelteJS, его экосистемы и сообщества, а также почему это не «yet another JS framework» и вам стоит присмотреться к нему.

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

Графический контент это половина средней web-странички. Чтобы правильно приготовить эту половину надо понимать как устроены картинки и что с ними можно делать.

Я кратко рассмотрю анатомию разных форматов (PNG, JPG, WebP, SVG и других). Расскажу как выбрать подходящий.

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

Те, кто придут на доклад:

• Узнают страшные тайны джипегов :)
• Смогут осознанно выбирать форматы и способы оптимизации изображений
• Узнают про полезные инструменты, которыми можно пользоваться при оптимизации изображений (локально и на сервере)
• Узнают что веселого можно сделать с пикселями (например натравить на них какой-нибудь ml алгоритм)

Расскажу о том, как развивались технологии потокового видео во фронтенд: от Flash до Media Source Extensions, о том, какие API и форматы используют современные видео-хостинги и том, что вам будет нужно знать, если вы захотите сделать свой онлайн-кинотеатр.

Особый упор в докладе будет сделан на современные стриминговые видео-форматы и принципы их работы, а так же на браузерные API, которые необходимы для их поддержки.

Вы уже устали верстать формы в своем фреймворке? Сделали 100+ лендосов и все кажется скучным? В новой CRM нет вызова?
Расскажу сколько интересного и необычного вас может ждать в простой таске «Нам тут еще текст нужно на canvas добавить» и почему эта задача затянулась на почти 5 лет. Будет про Canvas, SVG, дизайнеров, боль и неожиданные повороты и как мы это сделали в Miro.

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

Немного спойлера: поговорим о System tests и Platform tests, о UI тестах в React и UI тестах во Vue, снапшотах и не только

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

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

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

Этот доклад для разработчиков middle и senior уровня, работающих с большой централизованной кодовой базой (и желающих эту кодовую базу распилить).

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

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

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

Тебе повезло: твоя работа — это работа мечты. Ты работаешь в инфраструктурной команде и делаешь инструменты для других разработчиков. Никакой бизнес-лапши в разработке, никакого клепания формочек для заказа в интернет-магазине. Ты мастерски заливаешь chart-ы в Kubernetes и отказоустойчиво перекладываешь трассировки в Jaeger. Твои пользователи — грамотные и профессиональные инженеры, которые читают документацию и оптимально используют ресурсы облака. Звучит как сказка?

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

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

С этим можно жить. И у меня есть пара идей, как. Но будет ли счастливый конец у этой леденящей душу истории Проклятия инфраструктурной команды?

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

К сожалению, с ним знакомы далеко не все программисты, а те, кто знаком — часто вспоминают их как «старые добрые lint'еры».

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

Что мы хотим: Discovery и балансировку между разными k8s кластерами
* Что мы еще хотим: Canary Releases
* Почему kube proxy и существующие сторонние решения тоже не помогают в масштабах Авито
* Navigator: легковесное решение с явным описанием зависимостей
* e2e тестирование -- больно, тяжело, но необходимо
* Инструменты e2e-тестирования. CircleCI + KinD = любовь
* Проблемы тестирования инфраструктурных cloud-native решений с которыми мы столкнулись

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

Секционирование в PostgreSQL.
Краткий обзор. Какие проблемы решает, а какие создает? Что выбрать, реализацию через наследование или декларативный подход? Рассмотрим возможности СУБД в этих направлениях, историю развития и тенденции. Разберем более подробно декларативный подход и реализацию секционирования в своем проекте.
Спойлер: 100 500 строк кода остается между документацией и внедрением в проекте.

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

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

Итак, у вас случился (очередной) инфраструктурный (и не только) фейл!
— Какие предпосылки должны быть к проведению пост-мортемов?
— Как будет выглядеть последовательность действий во время митинга?
— Чего ни в коем случае нельзя допускать!
— И что же такое MTTR, MTTD и другие метрики, на которых надо заострять внимание!

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

Эта история о том, как мы храним документы. О том, как мы прошли путь от кастомного файлового хранилища до объектного хранилища. О том, на какие грабли и вилы мы наступили и какое светлое будущее с объектным хранилищем мы видим и ждём.
А приправлена эта история аспектами эволюции нашей технологической архитектуры, включающей такие технологии как OpenShift, GlusterFS, NFS и другие.

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

Доклад будет о сложностях, благодаря которым задачи в трекере накапливаются, сроки срываются, а прокрастинация поджидает в каждом втором тикете Jira и Trello. А чтобы не исполнять роль Капитана Очевидность, рассказывать о сложностях я буду с инженерной точки зрения: физиология, психика, социология. Будут избранные когнитивные искажения и социальные манипуляции, пять основных эмоций и обезьянья сфера повышенного диаметра. Не будет ответа на вопрос «куда кликнуть, чтобы всех победить», но лично мне нравящимися рецептами поделюсь.

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

За 6 лет у нас появились принципы, подходы, набор тактик и советов.
Я буду рад поделиться всем этим. А ещё расскажу о проблемах, которые мы до сих пор не решили.

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

У нас на слуху масса крутых инструментов для управления проектами: MS Project, Jira, Youtrack, Asana, Trello и еще сотни. Многими мы даже пользуемся, внедряем, допиливаем, строим на них серьезные процессы.

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

Удивительно? Смешно и глупо? Перспективно? Бред сивой кобылы?

Разберемся и ответим на эти вопросы:) А кроме того, покажем как можно использовать мессенджеры максимально эффективно, обходя их «врожденные недостатки». Чтобы оказавшись в следующем чатике на 20 незнакомых человек после слов «знакомьтесь, это наш менеджер проекта», понять как выжить и начать эффективно решать задачи даже в таком инструменте.

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

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

Но какие метрики все же нужно собирать? Есть ли у компаний методика или даже методология работы с производственными метриками? Что мы хотим получить от их сбора?

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

В рамках доклада расскажу опыт Ак Барс Цифровых Технологий по управлению метриками эффективности agile команд, разберем ключевые наборы метрик Current Value (CV), Time to Market (T2M), Ability to Innovate (A2I), Unrealized Value (UV), остановимся поподробнее на метриках T2M.

Внутри вашей софтверной компании уже запущен или планируется к запуску новый продукт? Если так, то, скорее всего, вас так или иначе волнуют вопросы:

• Клёвая же идея продукта, ведь правда?
• Удастся ли заработать на нём столько, сколько планируется?
• Что меня будет замедлять в компании и как с этим бороться?
• Как не превратить инвестицию в продукт в инвестицию в опыт?

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

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

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

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

Что, если в основу роста команды поставить культуру? Не best practice, не процессы и фреймворки, а культуру?

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

Поделюсь, как в нашей компании культура:
[+] помогает каждый день поддерживать быстрый рост команды;
[+] оказывает влияние на принимаемые решения.

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

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

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

Есть ли способ сделать так, чтобы вам помогали сотрудники других команд?
Как сделать так, чтобы другие руководители не ревновали и давали добро на помощь вам?

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

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

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

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

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

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

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

C# продолжает интенсивно развиваться добавляя всё новые и новые фичи.
Мы рассмотрим с вами наиболее интересные нововведения языка, а также научимся применять их на практике.

После мастер-класса вы сможете начать использовать C# 8 в своей работе.

Для работы вам понадобится ноутбук с установленными:

• .NET Core 3.0 (https://dotnet.microsoft.com/download/dotnet-core/3.0)
• IDE на выбор
• Visual Studio 2019 16.3 (https://visualstudio.microsoft.com/downloads/, с установленными компонентами для разработки .NET Core приложений) с плагином ReSharper 2019.3 EAP (https://www.jetbrains.com/resharper/eap/)
• или JetBrains Rider 2019.3 EAP (https://www.jetbrains.com/rider/eap/).

Современный IT-мир становится всё более и более требовательным к softskills его обитателей. Все мы всё чаще общаемся, вовлекаем других в свои проекты и продаём идеи (и проекты). В результате мы всё чаще выступаем перед другими людьми: на конференциях и в ВУЗах, перед коллегами, руководством, клиентами, инвесторами.

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

От организаторов: Обычно выступать нас учат бизнес-тренеры, коучи, менеджеры и прочие менторы. Но это не обычный мастер-класс. В этот раз учить разработчиков выступать будет разработчик! Александр - Senior Software Engineer в EPAM Systems.

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