Доклады

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

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

Jupyter и JupyterHub — популярный инструмент для работы с данными.
Я расскажу, почему я его люблю и почему ненавижу, секреты и опыт.

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

Но что, если вы не один? Как ужиться на одной машине 20 студентам, изучающим ML, или R&D-команде из 15? Готовые рецепты, рекомендации и собранные грабли.

ЯП Python является одним из ключевых навыков в сфере Data Science, но как облегчить себе путь в начале развития в новой сфере/профессии и не учить все и сразу?
Data Science включает несколько специализаций, каждая из которых использует Python в своей работе, а так же внутри одной специальности, например Data scientist, для решения разных задач используются различные библиотеки ЯП Python. C чего же все-таки начать, чтобы как можно быстрее войти в профессию Data Scientist? Об это я и буду говорить в своем докладе.

У нас в Авито созданы десятки сервисов, в которых используется модели машинного обучения. Модели встречаются большие и маленькие. Суммарная нагрузка на сервисы около 1млн RPM.
В этом докладе я расскажу, как мы используем инфраструктуру для удобной эксплуатации МЛ-моделей и продемонстрирую разработанную нами библиотеку, для запуска МЛ-моделей в продакшне и под нагрузкой.

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

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

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

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

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

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

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

Этот доклад — выжимка из последних пятнадцати лет спасения и похорон различных проектов. Он включает в себя пошаговые инструкции, страшные байки из жизни и ключевые штуки, которые надо проверять заранее: до того, как вы ввязались в очередную авантюру. Это теоретическая часть двухсерийного выступления, в которой я расскажу, что вытаскиваю из заказчиков, на что смотрю в проектах, как оцениваю сроки. А если интересно, как я разгребаю неизвестный код на практике — приходите на воркшоп “Как разобраться в legacy-коде, который вы видите первый раз в жизни”.

Рассмотрим общую картину применения Open Source лицензий в PyPI: общие практики, нисходящие и восходящие тренды выбора новой лицензии, а также случаи её смены. Ответим на частные вопросы о том, какие лицензии наиболее часто применяются для проектов в разных областях и почему: от веб-приложений и фреймворков до библиотек и утилит в областях машинного обучения (ML) и обработки естественного языка (NLP). C применением CodeScoring изучим, какие сюрпризы несовместимости лицензий можно поймать если относится к задаче лицензирования собственного кода халатно. И в конце концов, поймем как всего этого избежать и корректно настроить CI/CD в части отслеживания лицензионной чистоты.

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

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

С веб-сокетами на бэкенде работать не очень просто. Относительно понятно, как обрабатывать сообщения, поступающие в одном направлении, т.е. от клиента к серверу или от сервера к клиенту. Но когда возникает потребность полнодуплексного общения, еще и с асинхронным бэкендом и микросервисной архитектурой, то появляются сложности не только с роутингом во внутренние системы, но и, что важно, обратно от них к клиенту. К тому же стоит учесть, что сообщения к клиенту могут поступать не в режиме «запрос-ответ», а произвольно, т.е. в разном объеме и в разное время.

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

Таким образом, мы разработали свой сервис, который устраняет проблему полнодуплексного общения клиента с сервером через веб-сокет. Полагались на то, что наше решение должно быть горизонтально масштабируемое, cloud-native и написано на современном асинхронном python. О сложностях роутинга и о том, как «прицелиться» и «попасть» в нужного пользователя сообщением, и есть наш доклад.