Конференция завершена. Ждем вас на Moscow Python Conf++ в следующий раз!

Доклады

DevOps, контейнеры и развертывание (2)

Сказ о том, как мы Python-микросервисы для облака шаблонизировали

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

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

Доклад принят в программу конференции

Мастер-класс "Docker internals"

Технологии виртуализации и контейнеризации

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

Доклад принят в программу конференции

Базы данных и ORM (1)

Python-клиент распределенной базы данных Apache Ignite

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

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

Доклад принят в программу конференции

AI/ML и визуализация данных (11)

Автоматизируем саморефлексию ботами и дашбордами

API
Python
Метрики
Лайфхаки
Инструменты

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

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

Доклад принят в программу конференции

Jupyter-расширения. Как сделать жизнь проще и ярче

Python
Базы данных / другое
Аналитика / другое

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

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

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

Доклад принят в программу конференции

Towards Knowledge as Code

Базы данных / другое
Базы знаний / wiki
СУЗ / системы управления знаниями
Документация

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

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

Доклад принят в программу конференции

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

API
Python
Прочие языки
GO
Юрий Букаткин

Программный регион

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

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

Доклад принят в программу конференции

О хороших практиках построения инфраструктуры ML-моделей

Логирование и мониторинг
Технологии виртуализации и контейнеризации
Непрерывное развертывание и деплой
Непрерывная интеграция
Внедрение и поддержка
Поддерживаемый код
Логи, метрики, ошибки
Дмитрий Аникин

Лаборатория Касперского

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

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

Доклад принят в программу конференции

Работа с МЛ-сервисами под нагрузкой

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

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

Доклад принят в программу конференции

Мастер-класс "ML Space как платформа для быстрого прототипирования моделей машинного обучения"

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

Доклад принят в программу конференции

От 0 до 1, Рython для Data Scientist

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

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

Доклад принят в программу конференции

Реализация С++-интеграции в Python на примере NeoML

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

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

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

Доклад принят в программу конференции

Почему вам нужен JupyterHub: для команды, студентов и домохозяек

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

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

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

Доклад принят в программу конференции

Ускорение инференса Tensorflow и PyTorch-моделей на процессорах Intel с помощью NNCF и OpenVINO

Machine Learning

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

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

Доклад принят в программу конференции

Тестирование и автоматизация (2)

Организация тестирования распределенных систем на примере реального Java-проекта

Java
Python
Интеграционное тестирование
QA / другое
Автоматизация разработки, доставки, эксплуатации
Автотесты

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

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

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

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

Доклад принят в программу конференции

Тесты, которые мы заслужили...

Организация доступа к базам данных, ORM, собственные драйвера
Архитектурные паттерны
Рефакторинг
Непрерывная интеграция
Поддерживаемый код
Автотесты

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

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

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

Доклад принят в программу конференции

Язык Python, его эволюция и использование (17)

Legacy и бизнес: как "продавать" борьбу с тяжелым наследием

Методологии и процессы разработки ПО; Сроки и приоритеты
Антикризисный менеджмент

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

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

Доклад принят в программу конференции

Зачем нам subinterpreters?

Python
Оптимизация производительности
Павел Филонов

Независимый эксперт

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

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

Доклад принят в программу конференции

Ревью кода участников конференции. Кто побил рекорд по цикломатической сложности?

Совместно с компанией Profiscope (https://profiscope.io/) и их решением композиционного анализа программного обеспечения CodeScoring мы организуем активность по ревью исходного кода тех участников, которые покажут самые сложные авторские решения.

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

Передать свой репозиторий на автоматический анализ на предмет цикломатической сложности вы можете по ссылке https://mpccomplexity.codescoring.com/ до 20-го сентября. Ревью кода рекордсменов сложности будет проведено 27 сентября в лайв-режиме. Участник ПК конференции и сооснователь MoscowPython Михаил Корнеев разберет самые веселые кейсы, и покажет, как делать не нужно совсем, или как делать не нужно, если на то нет острой необходимости ;).

Доклад принят в программу конференции

"Простой Python": ложь, большая ложь и метаклассы

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

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

Доклад принят в программу конференции

Лицензирование Питон-приложений: тренды и проблематика

Непрерывная интеграция
Devops / другое
Теории и техники анализа
Техдолг
Управление изменениями
Аудит
Типовые ошибки

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

Доклад принят в программу конференции

Почему вам не нужен асинхронный ORM

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

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

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

Доклад принят в программу конференции

Как вызвать C++ из Python и не стать медленнее

C/C++
Python

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

Доклад принят в программу конференции

Тени прошлого: разбираемся, как бороться с legacy

Python
Управление изменениями, управление требованиями

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

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

Доклад принят в программу конференции

Объединяем экипаж танка вокруг линтера

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

Доклад принят в программу конференции

RPA как основа IT-автоматизации

Микросервисы, SOA
Распределенные системы
Разработка библиотек, включая open source библиотеки
Автоматизация разработки и тестирования
Методологии и процессы разработки ПО; Сроки и приоритеты
Лайфхаки
Методологии
Иван Маслов

ООО ОПЕН РПА

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

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

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

Доклад принят в программу конференции

Митап "Что происходит на рынке труда?"

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

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

Доклад принят в программу конференции

Мастер-класс "Ускорение создания веб-приложений Django с батарейками от Garpix"

Фреймворки
API
Python

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

Доклад принят в программу конференции

Круглый стол "Women in Python"

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

Доклад принят в программу конференции

Весёлая консоль. Яркий TUI для автоматизации повседневных задач

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

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

Доклад принят в программу конференции

Рефакторинг в удовольствие: миф или реальность?

Python
Рефакторинг
Методы и техника разработки ПО

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

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

Доклад принят в программу конференции

Ревью резюме

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

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

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

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

Доклад принят в программу конференции

Сообщества Data Science и Python — сходства, различия, скандалы, интриги, расследования

Существует вот такой парадокс — комьюнити Data Science и Python существуют относительно обособленно, несмотря на то, что Python — один из основных языков в мире DS на текущий момент. Мы решили разобраться в ситуации и пригласить людей из этих самых разных сообществ, чтобы поговорить и о людях, и о коде.

Доклад принят в программу конференции

Сеть, бэкенд и web-разработка (8)

Двусторонний websocket-роутинг

Денис Аникин

Райффайзен Банк

Владислав Лаухин

Райффайзенбанк

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

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

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

Доклад принят в программу конференции

Мастер-класс "Скрытая супер-сила Django Admin Panel в масштабируемом Backend-приложении"

Фреймворки
Системы прав доступа
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.
Ответы на вопросы.



Доклад принят в программу конференции

Не highload: почему наш стартап переехал с Flask на FastAPI?

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

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

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

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

Доклад принят в программу конференции

Я знаю, что вы логируете неправильно

Защита информации
Логи, метрики, ошибки

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

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

Доклад принят в программу конференции

Как и зачем начинать проекты на Django в 2021 году

Фёдор Борщёв

Федя и Самат

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

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

Доклад принят в программу конференции

Как мы ищем утечки памяти в сервисах на Питоне в Яндекс Go

Python
Профилирование
Надёжность продакшена

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

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

Доклад принят в программу конференции

Мастер-класс "Проектирование сверху вниз на примере реализации конкретной фичи"

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

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

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

Доклад принят в программу конференции

ДДДокументируй это!

Методы и техника разработки ПО
Фиксация знаний
Инструменты

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

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

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

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

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

Доклад принят в программу конференции