Программа 19 марта 2021
Программный комитет и Юля Герасимович
Антон Патрушев, Саша Букин, Михаил Еловских
Как здорово, что все мы здесь сегодня собрались - и всё такое :)
10:00-10:10
Григорий Петров
Evrone
Почему python медленный
Тезисы
10:10 – 10:50
Михаил Еловских
Яндекс.Облако
Фантастические проверки и где они обитают
Тезисы
11:00-11:40
Илья Беда
beda.software
Python on FHIR®
Тезисы
12:00-12:40
Денис Катаев
Тинькофф
Почему вам не нужен асинхронный ORM
Тезисы
13:00-13:40
Обед
Шведский стол в ресторане
14:00-15:00
Максим Акинин
assi.ai
Опыт интеграции микросервисов на Rust в pipeline микросервисов, написанных на Python
15:00-15:40
Алексей Буров
QuantumSoft
Как без боли использовать Git Precommit Hook
16:00-16:40
Lightning Talks
Все желающие
17:00-18:00
Вечеринка
Шале организаторов (Сулимовка, 19)
Мозгобойня, песни и глинтвейн!
20:00-23:00
Программа 20 марта 2021
Глеб Альшанский
Открытые технологии
Safe Reinforcement Learning: как не дать роботу ничего сломать
Тезисы
10:00-10:40
Никита Дмитриев
Яндекс
Погружаемся в Cython вместе с CatBoost
Тезисы
11:00 – 11:40
Антон Патрушев
Spherical
Автоматизируй это: как использовать invoke для уменьшения хаоса
Тезисы
12:00-12:40
Обед
Шведский стол в ресторане
13:00-13:40
Михаил Корнеев
Best Doctor
Как автоматические проверки помогают нам делать код лучше
Тезисы
14:00-14:40
Николай Марков
Aligned Research Group LLC
Экзотические встроенные модули Python
Тезисы
15:00-15:40
Lightning talks
Все желающие
16:00-16:40
Python Beer Meetup
Место уточняется
18:00-24:00
О чем речь?
Почему Python медленный?
Всего двадцать лет назад мир был простой и понятный. Python, Ruby и PHP были "скриптовыми", "интерпретируемыми" языками. А C++ и Java "компилируемыми, поэтому в сотни раз быстрее". А сейчас, в 2021 году, "задача четырех тел" решается на C++ всего лишь в два раза быстрее, чем на JavaScript. Но все так же в сотни раз быстрее, чем на Python или Ruby. Звучит несправедливо, и есть много хороших докладов, отвечающих на вопрос "что делать" и как обмазать все PyPy, Numba и Cython. Я же расскажу о том, "кто виноват": про компиляторы, байткод, ceval.c, виртуальные машины, JIT, нативные расширения и всё то, из-за чего мы вынуждены слышать обидное "Python медленный".
О чем речь?
Фантастические проверки и где они обитают
Знакома ли вам ситуация «у меня всё работает», когда локально и на CI всё хорошо, а в продакшене страдают пользователи? Мы в виртуальной сети Яндекс.Облака постоянно держим руку на пульсе с помощью активных проверок продовых сценариев на базе python и py.test. Я расскажу, какой "сетап" работает у нас и как этот подход можно использовать в вашем проекте.
О чем речь?
MicroPython в системах умного дома
Хочу рассказать о возможности применения языка MicroPython в построении устройств для систем умного дома, на данный момент у меня есть опыт разработки подобных устройств. Одно из них это умный обогреватель, точнее блок, делающий его таковым, а сам блок построен на базе микроконтроллера ESP32, прошивка под который написана на MicroPython. Принцип работы данного устройства следующий, оно подключается к брокеру MQTT по Wi-Fi и забирает из определенного топика информацию о выбранной температуре пользователем (полученной через REST API с веб сервиса) и текущей (полученной с датчика температуры от компании Xiaomi), после чего вычисляется дельта температур уже на самой ESP32 и формируется управляющий сигнал. На данный момент готовлю статью более подробную по этому блоку, которая будет опубликована на одном из сайтов посвященных системам умного дома.
О чем речь?
Погружаемся в Cython вместе с CatBoost
В первой части доклада (~10 минут) я постараюсь погрузить вас в мир ML. Расскажу, что такое CatBoost, в каких задачах используется, а так же с какими данными работает.

Во второй части (~30 минут) мы погрузимся в Cython. Я расскажу на примере нашей питон-библиотеки, с какими проблемами производительности мы столкнулись и как мы их решали. Если конкретне - поговорим про то, как нам удалось ускорить передачу векторов чисел и строк из питона в плюсы.
О чем речь?
Как заставить вашу рекомендательную систему узнать пользователя лучше
Вы уже устали считать рейтинги в ваших системах рекомендаций и делать на основе рейтингов рекомендации? И я тоже уже устал делать это, поэтому я начал искать другие варианты.
Разработчик рекомендательной системы тратит много времени и сил на расчет рекомендаций относительно рейтингов или лайков с просмотрами, но часто их работа и эксперименты с новыми алгоритмами не приводят к увеличению конверсии. Одна из причин этого – рейтинг не учитывает контекст того, когда было сделано действие и когда надо рекомендовать. Например, вы оценили 3 фильма о путешествиях на 10 баллов, но это ещё не означает, что вас надо завалить теперь фильмами с тематикой «путешествие», возможно из-за особенностей 2020 вы скучаете по путешествиям.

Как же это всё учитывать? Традиционные системы рекомендацией учитывают пользователей и набор рекомендуемого товара, этого явно недостаточно чтобы сделать «горячую рекомендацию». Но есть примеры, где «под капотом» рекомендации используется что-то другое, можно вспомнить успех Netflix, где рекомендация создаётся не только из фильма, а это комплекс созданный «соблазнить вас» посмотреть фильм: персональная обложка и описание фильма, кто из ваших знакомых смотрел или кто из ваших любимых знаменитостей смотрел / рекомендует к просмотру и многое другое.

Вы заметили, что система рекомендаций – это не просто алгоритм user-based, или item-based, или разложения матриц по рейтингу. Как же делать рекомендации «горячими»? «На сцену выходят» рекомендации на основе контекста пользователя (context-aware recommender system).
Такой тип рекомендаций меняет расчет рейтинга из формулы useritem > rating в формулу useritem*context > rating. Это одно дополнительное слово дополняет: явный и неявный контент (время просмотра, место просмотра и тд). Но оно и добавляет дополнительную активность при написании системы рекомендации, а именно, вам придется решить проблемы контекстной фильтрации.

В своем докладе я хочу познакомить участников с методом, который изменит их рекомендации (в моей практике он позволил повысить конверсию с 12,7% до 21,1%) и показать с чего начать, чтобы изменить свои рекомендации и добавить в их расчет контекст.

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

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

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

О чем речь?
Экзотические встроенные модули Python
Есть несколько точек зрения. Одни говорят, что не надо использовать сторонние модули, если для них есть уже готовая реализация в стандартной библиотеке. Другие говорят, что эта самая библиотека - это место, куда модули приходят тихо догнивать, поэтому надо брать свежие и современные сторонние реализации.

Но факт фактом - за долгую и насыщенную историю развития Python в стандартной библиотеке собрался целый паноптикум модулей разной степени нужности и проработанности. Она даже чем-то смахивает на НИИЧаВо из известной повести - чем глубже идешь, тем более таинственные вещи находишь. Давайте заглянем?
О чем речь?
Python on FHIR®
HL7® FHIR® - стандарт передачи медицинских данных. Для современных медицинских информационных систем важно ему следовать. Как для любой Enterprise технологи, вы сможете найти массу её реализаций на Java или .Net. 5 лет назад, когда beda.software начали заниматься разработкой в сфере здравоохранения, существующий python инструментарий нас не устраивал. Поэтому мы занимались и продолжаем заниматься разработкой open source инструментов на Python для FHIR.
В своем докладе я расскажу, что такое FHIR, зачем он нужен и как он помогает делать медицинские приложения проще. Расскажу, какие библиотеки мы разработали и как используем их для решения повседневных задач.
О чем речь?
GraphQL и NoSQL
NoSQL предлагает возможности к слабо структурированному хранению информации и возможность оперативного доступа к ней. Однако это накладывает ряд неудобств при использовании множества вложенных (в том числе рекурсивных) структур совместно с друг другом. В тоже время GraphQL описывает удобную нотацию для предоставления доступа к данным, но большенство ORM предоставляющих данные посредством GraphQ, реализованы для SQL баз данных. При использовании связки GraphQL и MongoDB зачастую возникает желание использовать все возможные структуры данных в связке с GraphQL и иметь в арсенале возможность поиска/фильтров данных которые содержатся в "списках" и "словарях". Однако может возникнуть ряд проблем.
О чем речь?
Safe Reinforcement Learning: как не дать роботу ничего сломать
Обучение с подкреплением - отличная парадигма для создания алгоритмов управления роботами, которая не предполагает написания вручную огромного количества правил, задающих огранчиения на поведение робота, или разметки огромных датасетов для обучения, вместо этого робот может учиться на опыте своего взаимодействия со средой методом проб и ошибок.
Но тут возникает 2 вопроса:
1. Как сделать так, чтобы, совершая ошибки в процессе обучения, робот не сломал себя или что-то/кого-то вокруг себя?
2. Как сделать так, чтобы обучение при этом было эффективно с точки зрения количества попыток, т.е. роботу требовалось на сотни тысяч и миллионы попыток для достижения совершенства, а тысячи, или даже сотни или десятки попыток?
О чем речь?
Автоматизируй это: как использовать invoke для уменьшения хаоса
Я хочу рассказать про то, как мы начали использовать pyinvoke для автоматизации различных операции в нашей команде. Таких операций как: тестирование, проверка стиля, релизы и тд. Благодаря этому нам довольно быстро удалось подвести единую базу под все наши внутренние и внешние пакеты. При этом мы получили возможность изменять наши конвенции по необходимости сразу и везде.
Слушатели смогут понять, что конвенции и соглашения в команде лучше кодифицировать, чтобы переиспользовать их во всех пакетах, а также, что разрабатывать вспомогательные задачи на питоне удобнее и приятнее чем на make.
Доклад рассчитан на middle+ python developer, сталкивающийся с управлением пакетами