Доклады

Очень многие рассказывают, как они шаблонизировали создание своих микросервисов, но немногие показывают сам шаблон. В своем выступлении я расскажу, как выглядит шаблон наших Python-микросервисов и какие изменения в него пришлось внести, чтобы без проблем переехать в Google Cloud и получить PCI DSS-сертификат.

Покажу идеальную конфигурацию uwsgi и poetry, расскажу, как мы храним конфигурацию сервисов и секреты. Обсудим полезные фичи docker и docker-compose. И в завершении я дам пару советов по конфигурациям сервисов для kubernetes.

Обсудим, чем контейнеризация отличается от виртуализации, откуда она пошла и зачем нам нужна. Остановимся на трёх китах в Linux: cgroups, namespaces, layerfs; поработаем с ними сначала вне привязки к Docker, а потом проведём эксперименты и над запущенным контейнером; выберем, что же использовать для Python-проектов и какие могут быть подводные камни.

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

В докладе я, как мейнтейнер python-адаптера к Apache Ignite из первых рук, расскажу о том, как собрать такой адаптер. Новая версия использует asyncio transport/protocols. Я считаю, в нашем случае такой подход лучше, чем asyncio streams, и покажу вам, почему это так.

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

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

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

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

Из этого доклада ты узнаешь:
* как устроено простейшее расширение;
* как добавлять новые %magic-команды;
* делать отображение объектов в Jupyter более красивым и информативным;
* показывать интерактивные формы и реагировать на действия пользователя;
* делать своё "ядро" с предустановленным набором расширений.

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

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

Во многих компаниях Python не является основным языком программирования. С появлением машинного обучения на проекте возникает проблема, как внедрить модели, написанные на Python, с использованием Tensorflow, Keras и прочих библиотек с backend, написанным, например, на Golang?

В докладе расскажу:
- как мы дружили Python-модели ML c backend, написанном на Golang;
- почему нам не подошли стандартные средства tensorflow и ml-flow;
- как мы пришли к написанию своего решения;
- покажу подробный путь модели от jupyter playbook до procduction;
- какие дополнительные возможности в сервисе мы реализовали;
- что выиграли, а где набили шишки.

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

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

Я расскажу о пути нашей модели от простого артефакта до самостоятельного сервиса. Расскажу, какие практики мы внедрили и как они нам помогли. CI/CD, мониторинг, алертинг на конкретном примере. Опишу весь путь деплоя модели от гипотезы до продакшна.

Основная мысль: слушатели смогут увидеть на конкретном примере практики MLOps и их полезность.

В ходе workshop участники познакомятся с платформой ML Space от SberCloud. Мы обучим простую hello-world CV-модель, но сделаем это в стиле real-world. Познакомимся с распределенным машинным обучением, которое позволит обучить модель гораздо быстрее, используем инструменты ML Ops и в конце выведем модель в инференс с автоскейлингом.

Мы разрабатываем open source-библиотеку для машинного обучения NeoML. Ядро нашей библиотеки написано на С++. Но для расширения области применения и упрощения использования мы сделали для нее Python-интерфейс. О том, как можно сделать интеграцию С++ в Python, при этом получить удобный и функциональный интерфейс, а также не потерять в производительности, я расскажу в своем докладе.

Вас ждет обзор доступных средств интеграции С++-кода в Python: ctypes, CFFI, Cython, CPython API. На примере нашего проекта обсудим их плюсы и минусы и выберем подходящее. Обсудим проблемы, возникающие при реализации интеграции: многопоточность и GIL, аллокация памяти, владение объектами, реализация сложной иерархии классов, сериализация, производительность и т. д.

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

ЯП Python является одним из ключевых навыков в сфере Data Science, но как облегчить себе путь в начале развития в новой сфере/профессии и не учить все и сразу?

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

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

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

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

Intel заинтересован в том, чтобы «железо», купленное его клиентами, полностью раскрывало свой потенциал; разумеется, это касается и DL-приложений. Подавляющее число DL-моделей производится с помощью фреймворков, основанных на Python (PyTorch, TensorFlow) — такие модели могут быть напрямую исполнены с помощью инструмента Intel OpenVINO на процессорах Intel с полным использованием аппаратных оптимизаций и ускорений.

Однако, ещё большего ускорения на железе Intel возможно добиться за счет перехода от вычислений в числах с плавающей точкой к целочисленным, или за счет отбрасывания «незначимых» параметров модели. Подобный переход обычно сопряжен с некоторой потерей качества предсказания модели. Для того чтобы уменьшить потери, используется метод симуляции целочисленных вычислений с дотренировкой, применяемый поверх методов «обрезки» моделей. Мы рассмотрим Python-пакет NNCF (Neural Network Compression Framework), который позволяет проводить подобного рода оптимизации, не выходя из исходного фреймворка, с дальнейшим экспортом оптимизированной модели и инференсом ее c помощью инструмента OpenVINO.

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

Хотя платформа написана на Java, но инструменты автоматизированного тестирования наша команда делает на Python.

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

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

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

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

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

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

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

В рамках PEP 554 уже несколько лет идет работа над добавлением в Python возможности запускать несколько экземпляров интерпретаторов в рамках одного процесса. В докладе рассмотрим, кому и зачем это может быть нужно (привет от GIL и shared memory). Как этот инструмент будет соотноситься с многопоточными и мультипроцессными подходами, и чем это может помочь в задачах, которые работают с большими объемами данных в памяти.

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

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

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

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

У питонистов есть простое правило: хочешь сделать быстро — пиши нативный код. Это действительно так, когда нативный код пишут опытные разработчики. А вот те, кто только начал погружаться в волшебный мир C/C++ кода могут столкнуться с тем, что их код стал не быстрее, а медленнее. Почему? Потому что неявные накладные расходы при вызове нативного кода из Python. Подробнее — в моем докладе.

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

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

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

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

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

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

Разочарованы в IT? RPA как основа IT-архитектуры, которая победит микросервисы.

- IT-задача реализуется долго/дорого?
- По итогу реализации нет ожидаемого бизнес-эффекта?
- Содержание штата IT-персонала обходится дорого?

Если что-то из вышеперечисленного оказалось знакомым, то вам будет интересно послушать доклад Ивана Маслова — автора резонансных статей (на Habr и VC), которые продемонстрировали дикий разрыв между IT и бизнес-сообществом.

1. Почему быстро? Обзор батареек для Django от GARPIX.
2. Основные принципы при работе с батарейками GARPIX.
3. Реализация проекта с батарейками на Django Templates.
4. Реализация проекта с батарейками на DRF и React.
5. Обзор дополнительных батареек.

Нужно автоматизировать рутинные задачи и сделать так, чтобы пользоваться решением мог даже "младший научный сотрудник", но время на разработку GUI нет. Решение — TUI! БыстрО, эффективнО, ретрО.

- Оформление вывода консольного приложения в виде TUI — терминального пользовательского интерфейса с псевдографикой с помощью встроенного модуля Curses;
- drypen — 16-цветный ретро-paint в консоли;
- drydock — простой конфигурируемый лаунчер для запуска программ на системах без рабочего стола и WSL2;
- Pilot-TUI — пример консольного приложения для автоматизации серверных задач с TUI-интерфейсом.

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

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

Вам кажется, что ваше резюме не идеально? И правильно кажется!

Вам не у кого спросить совета, карьерные консультанты не разбираются в разработке, а диванные эксперты — в HR? Спросите тех, кто разбирается.

HR и техлиды, которые на подборе собаку съели, соберутся вместе, чтобы честно разобрать ваши резюме и рассказать, как их улучшить. Фидбэк, который обычно не получить.

Чтобы поучаствовать, присылайте ваши анонимные резюме на julia.kuzmicheva@ontico.ru.
Нам не нужны ваши ФИО, контакты или названия компаний!

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

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

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

На выбор Django-Framework для проекта могут повлиять фразы из документации в стиле "киллер-фича Django Admin Panel", или "гибкая в настройке панель Django Admin".

Однако спустя несколько лет, большинство проектов упрется в сложность дальнейшего расширения возможностей Admin Panel. Основным препятствием для продолжения разработки Dachboard на базе Admin Panel является недостаток информации, но именно из-за этого команды спешно переезжают на самописные решения в стиле vue-backend или начинают использовать Django-батарейки в стиле django-grapelli.

Я расскажу о возможностях Django Admin Panel, которые стоит использовать при разработке собственной версии backend/dashboard или при настройке с нуля Django Admin Panel "из коробки".

Части доклада:
1. Django Admin Panel, какой она могла бы быть.
2. Django Admin Sites. Мультиплицирование Django Admin Panel.
2. ModelAdmin, ModelAdminForm. Функциональное наследие старых версий Django.
3. ModelAdminInline, ModelAdminFormset. Ошибки в реализации Inlines текущей версии Django.
4. AdminAction на базе Generic-CBV, простота и удобство
5. Малодокументированные возможности Django.contrib.
6. Тестирование Admin Panel.
7. Использование возможностей Django Admin Panel для сторонних реализаций Backend.
Ответы на вопросы.

Привет, это Datafold!
Наш продукт — это платформа для мониторинга аналитических данных. Мы подключаемся к хранилищам данных и ETL и BI-системам и помогаем дата-сайентистам и инженерам отслеживать потоки данных, их качество и аномалии.

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

Наш изначальный стек: Python3/Flask-RESTful, PostgreSQL, Redis, Neo4j на бэкенде, Typescript/React на фронте.

Наши впечатления от переезда:
* FastAPI полностью оправдывает ожидания;
* Mypy здорово помогает при рефакторинге;
* класс багов, связанных с расхождением типов на бэкенде и фронтенде, исчез.

Начинающие разработчики редко используют "серьезное" логирование, ограничиваясь принтами в консоль или файл. А потом: ба-бах, и на большом проекте их встречают structlog, sentry, санитайзинг, kibana — все то, о чем мы обычно читаем в статьях про работу с логами.

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

В 2021 году Джанге исполняется 15 лет. Не пора ли ей на пенсию? Может, пора, но не всей?

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

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

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

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

И... что дальше? Как вы будете, собственно, писать код? Наговнокодите, потом причешете? Сверху-вниз? Снизу-вверх? С юнит-тестами? Перед кодом или после? А что с е2е? А когда вы будете думать про универсальность вот этого вот utils-метода, который вам надо написать? А как вы заметите, что в utils.py уже 5к строк и хорошо бы его зарефакторить? А что с аннотациями-то, пишете? А документация?

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

Даже если вы практикуете общение с экспертами, походы в гембу и стараетесь использовать единый язык (ubiquitous language), все равно со временем код и ментальная модель начинают расходиться. Почему так происходит? Мы автоматизируем живые бизнес-системы, они развиваются и до этапа выявления требований, и пока мы пишем код, и даже (сюрприз-сюрприз) после запуска на проде.

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

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

Мы предлагаем использовать самодокументируемый код с использованием аннотаций и утилиту, которая генерирует человекочитаемую документацию на основе статического анализа исходного программного кода приложения. Документ представляет собой бизнес-описание программной модели. Мы предлагаем не просто использовать javadoc/sphinx-doc, а специальный формат, который вместе с генератором документации является полноценным инструментом поддержки DDD-практик и паттернов.

Как результат мы получаем:
– высокую читаемость кода;
– богатую доменную модель;
– стандартизацию доменной разработки;
– контроль соответствия ментальной и программной моделей;
– контроль использования Единого языка;
– возможность анализировать “протекание” контекстов или модели;
– карту контекстов и их отношения и т.д.