Собрали в одном месте самые важные ссылкичитайте авторский блог
Как подружить OpenAPI и JSON:API. Почему мы решили использовать JSON:API в нашем FastAPI приложении, и какие задачи решает данная спецификация. Для чего применять Compound Documents (included ресурсы). Почему мы не захотели использовать Django с DRF и расширение для JSON:API, а выбрали именно FastAPI. Доклад рассчитан на разработчиков, имеющих опыт с веб-приложениями на Python, а также тех, кто работает с REST API. Слушатели познакомятся со спецификацией JSON:API, узнают, как и зачем её применять, научатся применять готовые решения для быстрого создания ресурсов с поддержкой JSON:API.
В докладе рассматривается текущее состояние PyPI: от статистики по пакетам и отдельным характеристикам хранимых артефактов, до трактовки тенденций в python-сообществе на сегодня. Нельзя обойти стороной и (как никогда!) актуальный вопрос безопасности компонентной базы и цепочки поставки в целом, поговорим про: typosquatting, dependency confusion и malware в пакетах и средствах предотвращения угрозы. Доклад рассчитан на dev, devops, devsecops, (+pm?) Слушатели: -узнают, что происходит с пайтон пакетами сегодня, интересные статистики и картиночки -получат понимание инфраструктуры пакетного индекса и сообщества, его окружающего -подкуются в базовых принципах безопасной разработки (devsecops)
В докладе поговорим о том, как использование стандартных возможностей уже готовых инструментов делает проект проще, как избавиться от лишних зависимостей и не потерять, а иногда и приобрести в функционале. Рассмотрим, как маршрутизация на кролике дает то, что не всегда может дать сторонний инструмент. Заглянем в то, как правильно заданный вопрос "почему и зачем" уменьшает количество проблем на проде. И конечно обсудим, на какие грабли мы наступили сами и какие встретятся, если выкинуть внешние зависимости.
Данные — это актив, они имеют реальную ценность, необходимо уметь ими управлять и защищать их. Мы в Тинькофф строим свою систему типа Data Catalog. Эта система собирает в себе все метаданные о таблицах, отчетах и бог знает чём еще в рамках предприятия и предоставляет инструменты для простого управления метаданными и самостоятельного поиска по ним. Я расскажу о том, как мы наполняем наш Data Catalog метаданными из более чем 25 источников, используя Apache Airflow. Как мы придумали подход, а затем и создали небольшой фреймворк.
В современном мире уже никого не удивить машинным обучением. Наиболее важно обеспечивать высокое качество и надежность моделей и, как следствие, бурно развиваются MLOps инструменты, которые позволяют управлять всем жизненным циклом машинного обучения. Мы в Яндексе, конечно, тоже делаем такой инструмент для внутренних пользователей. Один из его элементов — инструмент для пообъектного сравнения, позволяющий понять на каких объектах разные модели ведут себя лучше, а на каких хуже. Проблема заключается в том, что общий объем данных для сравнения может быть довольно большим. Кроме того, необходимо предоставить пользователю удобные средства сортировки и фильтрации для анализа полученного сравнения. В своем докладе я расскажу, как мы такой инструмент строили, развивали, и к чему в итоге пришли. Доклад будет интересен Data инженерам, разработчикам ETL процессов, специалистам по качеству и анализу данных.
Графы знаний активно применяются для улучшения пользовательских рекомендаций (амазон, нетфликс), для анализа фондового рынка (goldman sachs), поиска (яндекс, гугл) и даже для поиска новых молекул. Также это может быть удобным корпоративным инструментом, который объединяет и связывает данные внутри компании из разных источников. Это помогает исследователям, аналитикам и дата саентистам.
В докладе расскажем о том, как мы разрабатывали инструмент для запуска разнородных тестов на разнородном железе. Доклад рассчитан на разработчиков, тестировщиков, билд-инженеров и менеджеров, которые: планируют построить систему CI/CD, включающую прогон тестов на железе и эмуляторах; хотят иметь единый подход к запуску тестов; хотят, чтобы в их проектах была трассируемость результатов выполнения тестов в требования; имеют большой зоопарк разнородного железа, на котором нужно прогонять тесты.
Поговорим про мониторинг ML-моделей в production: о том, зачем и как это делать, что такое data drift и как его измерить. Также расскажу о том, почему выбор "правильной" метрики для data drift — одно из главных решений в мониторинге, и поделюсь результатами исследования пяти популярных статтестов, которое мы недавно провели в Evidently. На примерах покажу, как ведут себя разные метрики в зависимости от объема данных и размера data drift. Слушатели смогут сформировать интуицию о том, как ведут себя различные статтесты для определения data drift, и подобрать подходящую метрику под свою задачу и "сценарий" использования.
Общая задача обнаружения аномалий во временных рядах часто разделяется на две отдельные задачи: обнаружение выбросов или бинарная классификация (для точечных аномалий) и обнаружение точек изменения состояния (changepoint detection, для коллективных аномалий). В докладе подробно рассмотрена задача changepoint detection, методы для обнаружения точек изменения состояния, библиотеки на python, с помощью которых можно решать эту задачу. Также в докладе продемонстрирована реализация на python одного из самых распространенных подходов к решению задачи (генерация невязки сигнала) без применения специализированных библиотек.
Мультипроцессинг в питоне вещь актуальная, особенно если вы занимаетесь ML сервисами. Но если вы попытаетесь использовать его в ваших сервисах — вы непременно наткнетесь на ряд подводных камней, которые почти нигде не обсуждается. В докладе я бы хотел рассказать про наш опыт использования мультипроцессинга, с какими проблемами можно столкнуться, затаскивая его в реальные продакшн сервисы. Из этого доклада можно будет узнать: В каких случаях нужно использовать shared memory и как корректно и эффективно с ней работать. Расскажу про атомарные счетчики ссылок как альтернативу стандартным методам контроля над шареной памятью в питоне. Скрытые баги в стандартных питоновских очередях. Мультипроцессорные очереди в питоне ведут себя контринтуитивно (например, говорить, что очередь пуста, когда в ней на самом деле лежит куча тасков), плюс они не совсем кроссплатформенные. Эти вещи мало где обсуждаются, а проблемы, связанные с ними, напрямую аффектят сервисы. При этом сходу не понятно, что произошло не так и как можно это исправить.
Во время работы над сложными проектами, например, такими как виртуальные ассистенты, возникают нетиповые задачи, для решения которых нет подходящего инструмента или фреймворка. Иногда такие задачи кажутся маленькими и незначительными, поэтому один разработчик-энтузиаст за два дня пишет на коленке маленький Python сервис и делится им с коллегами. Но как быть, если маленький наколенный проект с 2 RPS, предназначенный для использования несколькими людьми, выстреливает, и его накрывает волна фича реквестов и пользователей из десятков команд? В своём докладе я расскажу, как развивался наш внутренний инструмент UnionPortal, предназначенный для поддержки NLP задач, про его эволюцию, начиная с маленького наколенного проекта и заканчивая большим отказоустойчивым сервисом со всеми правилами хорошего тона enterprise сервиса. Мы затронем такие интересные вопросы как масштабирование, бесшовный вывод из и ввод в эксплуатацию, сокращение стоимости разработки и внедрение единого архитектурного стандарта.
В этом докладе я хочу продемонстрировать вам детали: как именно выглядит сложность в нейронах наших мозгов. Нас ждет огромное дерево когнитома, облака когов с оптическим зумом, зрительная кора, бесчеловечные эксперименты с воображением. И код. Много кода. Простого кода, сложного кода и непонятного кода, который с одной стороны простой, с другой сложный, а с третьей стороны вообще пересечение параллельных линий в форме котика.
Слайды: https://moscowpython.ru/meetup/78/code-complexity-neurophysiology/
Аспекты управления командой разработки одной из лидирующих блокчейн-платформ в России.
Слайды: https://moscowpython.ru/meetup/78/dev-management-in-blockchain/
Похожие товары – это важная часть для любой e-commerce платформы, а особенно для маркетплейсов. Они помогают покупателям найти лучший товар за меньшие деньги. Joom – международная группа e-commerce и финтех компаний, которая работает как с B2B, так и с B2C сегментами с одной основной командой разработки поиска. Мы поговорим про: - построение Модели Похожих Товаров для Joom Marketplace (B2C-продукт); - разработку Модели Похожих Товаров для JoomPro (B2B-продукт), где у нас мало пользовательской истории; - как с помощью такой модели мы улучшили алгоритмы рекомендаций".
Слайды: https://moscowpython.ru/meetup/78/similar-products-search/
В гостях у Moscow Python Podcast руководитель разработки Data Science компании Avito Олег Бугримов.
Спецификация JSON:API позволяет нам строго определить, как ресурсы должны вести себя, что должны и могут делать, а чего им делать нельзя. Спецификация необходима для унификации интерфейса. Благодаря строгим рамкам мы получаем универсальный интерфейс, который можем применять в различных проектах. Различные серверные реализации JSON:API позволяют нам абстрагироваться от слоёв работы с данными, а также сериализации / десериализации. Слайды: https://moscowpython.ru/meetup/77/api-json-python/
Все иногда пишут на Django Rest Framework, я расскажу про наш опыт костылестроения и улучшайзинга
Слайды: https://moscowpython.ru/meetup/77/drf-and-isolenta/
Иногда проект перерастает Django ORM, и в игру входит SQLAlchemy. Расскажу, как каждый из них справляется (или нет) с нашей сложной бизнес-логикой. Ещё немного о том, почему мы выбрали SQLAlchemy, а что всё-таки можно было сделать, не выходя из Django. Слайды: https://moscowpython.ru/meetup/77/django-alchemy/
В гостях у Moscow Python Podcast Lead of HR Community Skolkovo Алиса Цапкова. Обсудили с Алисой зачем нужны хакатоны, советы и лайфхаки участникам хакатонов.