Собрали в одном месте самые важные ссылки
читайте нас в Telegram
В корпорациях любят всё автоматизировать. Большое количество энтерпрайз-продуктов и внутренних веб-сервисов, которые общаются между собой — все это привычные задачи внутренней и инфраструктурной разработки. Но что, если необходимо автоматизировать выдачу оборудования сотруднику компании? Это возможность выйти за рамки стандартных веб-сервисов и узнать что происходит на уровне железа. Как включить огромную железную коробку, которая умеет только принимать байты на серийный порт, в привычный нам, веб-разработчикам, стек Django, React. js, PostgreSQL, Celery и заставить все это общаться между собой? Посмотрим на консьюмеры Kombu, RabbitMQ. Поучимся управлять пружинами вендинга при помощи Python, читать оптические датчики. Построим всю систему до пользовательского интерфейса «снизу-вверх». И постараемся по пути не отрезать себе палец, когда будем перекидывать питание крутящих серво-приводов между шинами :)
В своем докладе я расскажу о том, что на самом деле может django.contrib.admin, как и зачем преодолевать внутреннее сопротивление при работе с ним. Django Admin Panel — сложный и мало документированный инструмент в Django Framework, который способен значительно повысить скорость разработки, если в нём по-настоящему разобраться. — «A Не проще ли нам написать свой Backend?» Я отвечу: «Нет, не проще!». Семь лет инсайтов и открытий в моем докладе.
Расскажу о том, как экономить время на старте проектов. Посмотрим как тут выручает генерация кода и что есть из готовых решений. Как можно, просто введя 2 команды из DDL схемы базы данных, получить готовый CRUD REST сервис с моделями и endpoint-ами. Зачем мне в 2020 пришлось писать свой ddl парсер и генерацию ORM & Pydantic моделей, и как это облегчило жизнь проекту. Что из чего вообще можно генерировать, чтобы не писать это руками. Бегло посмотрим какие есть готовые библиотеки на сегодняшний день (основные их категории) и кейсы их использования. Обсудим плюсы данного тренда. Лично мне кажется, что это тренд — с каждым годом таких библиотек все больше и больше, и мы стараемся не писать тот код, который можно не писать. Рассмотрим кейсы, когда это удобно/полезно (про быстрые PoC, RnD) и направления, куда двигаться дальше, если тема интереса.
Сегмент данных взрослеет и за этим следует потребность в их валидации. Расскажу как построить процесс тестирования на данных на проекте на основе фреймворка great expecations. Как интегрироваться в дата пайплайн в AWS. Расскажу, как мы решили проблему репортинга и дашбординга + как на результатах Data QA устроить ML QA
Мы много лет используем Sentry (28k звёзд, 3.2k форков на гитхабе) для мониторинга исключений на проектах, а так же мессенджер Telegram для общения. Когда я захотел получать уведомления об инцидентах из Sentry в Telegram, я не нашёл такой возможности, но что самое интересное — ни слова в официальной документации как добавить такой плагин. Пройдя путь от изучения устройства плагинов, поддерживаемых авторами Sentry и работы с ними в самом ядре Sentry, до создания своего плагина, используемого многими компаниями, я вижу, по поступающим вопросам, что интерес к теме не уменьшается со временем, а актуальной информации в сети всё так же нет. Я вижу, что отдельные разработчики регулярно создают свои плагины для Sentry, но каждый из них вынужден проходить этот путь с нуля и самостоятельно, как это делал я. Неплохо разобравшись в процессе с вопросом, я был бы рад поделиться знаниями с участниками PyCon. Вместе со участниками мы пройдём по таким пунктам как: общее устройство плагина для Sentry: от простого к более сложному его место в общей архитектуре Sentry и как он запускается проблема с использованием популярных плагинов в cloud версии Sentry правильный способ установки плагинов в Sentry (грабли, по которым прошёл я, и провёл за собой N пользователей первых версий своего плагина) добавление своих интерфейсов настроек в интерфейс Sentry работа с сетью из вашего плагина: отправка запросов и получение их от внешних систем работа с базой данных и миграциями недокументированные, но вычленённые из исходников, best practice которые следует использовать при создании плагинов, чтобы не поотстреливать ноги себе и своему админу, который поддерживает Sentry
В докладе поделюсь опытом настройки политики кэширования данных в Python-приложениях. Наверное, каждый, кто решал эту проблему, столкнулся с ней в неподходящий момент. Давайте сразу настроим «агрессивное» кэширование, а дальше будем оптимизировать инфраструктуру вокруг. А именно — решим вопросы: — Какой backend использовать: redis, keydb? А, может, in memory? — В каком формате хранить данные? — Как мы можем это мониторить? Нам точно нужен кэш? — Какой инструмент лучше всего подходит?
FastAPI уже не первый год с нами. Последние пару лет фреймворк явно на подъеме: количество звезд на гитхабе уже больше чем 50% от мастодонтов рынка — django, flask. В ds среде и в каждом туториале flask, в каждой второй вакансии суперсовременные горизонтально масштабируемые сервисы на… django. Однако, про fastapi разговоров довольно немного и проникновение как в рынок, так и в публичное пространство у него не велико. И уж тем более, пока ещё про него не говорили с позиции продакшена (как минимум, на конференциях). Так сложилось, что в банке мы сделали на нем несколько десятков сервисов и уже больше года активно эксплуатируем как раз в том самом продакшене, а так же рекомендуем его внутри, как основной, практически всем. За это время мы успели полюбить этот фреймворк, но при этом нашли его «зоны роста». В своем докладе я постараюсь раскрыть три темы: сделаю краткий обзор на сам фреймворк поделюсь тем, чего ему не хватает для полноценной жизни в продакшене (с моей точки зрения) подсвечу довольно очевидные потенциальные проблемы. Ну и, конечно же, займусь неймдроппингом: FastAPI!
На рынке веб-разработки Django, пожалуй, один из самых популярных фреймворков. Но может ли оказаться так, что в документации такого «старичка» есть неточности? В докладе расскажу о том, как оптимизация простого поискового запроса пошла не по плану. Вспомним старые добрые индексы и разберёмся, какие нам действительно нужны, и как соединить их с нашим приложением. В конце обсудим, что же нового случилось в 3 версии и как она упростила нам жизнь.
Временные ряды — это любые данные, у которых есть временная метка. Некоторые ряды нужно прогнозировать — например, сколько глазированных сырков купят на этой неделе, сколько посетителей будет в магазине, сколько наличных останется в банкомате. Для их прогноза нужны разные модели и признаки, но подход к исследованию проблемы будет одинаковый. Сначала мы пробовали решать каждую отдельную задачу усилиями разных ML-специалистов: это было долго, каждый пилил свой собственный «велосипед», не было обмена опытом и не спасало от ошибок. Поэтому мы решили сделать ML-эксперименты с временными рядами простыми и быстрыми — и придумали библиотеку ETNA.
В нашем IT-мире есть только один достоверный источник информации — исходный код. Документация может быть не актуальной, книжка может устареть, статья может осветить только один аспект. А исходный код — честен, доступен и открывает тайны всем, кто достаточно смел, чтобы заглянуть в него. На мой взгляд нет ничего интереснее, чем поковыряться в нем и понять как работает та или иная технология, тот или иной инструмент на самом деле. Я приглашаю Вас в увлекательное приключение по обработке ошибок в Python cо стороны исходного кода — мы заглянем внутрь, увидим как работают основные механизмы обработки ошибок, рассмотрим частные виды исключений и их особенности и еще много чего интересного.
Расскажу, как можно автоматизировать рефакторинг большой кодовой базы на примере перехода с синтаксиса одной библиотеки на синтаксис другой. Покажу, как можно реализовать это двумя способами: с помощью регулярных выражений и с помощью абстрактных синтаксических деревьев. Буду сравнивать оба подхода: что быстрее в реализации, что быстрее работает, какие нюансы стоит учитывать при выборе одного или второго подхода
В гостях у Moscow Python Podcast технический директор компании Geecko Никита Обухов. Поговорили с Никитой о рынке найма разработчиков и о DevRel.
В гостях у Moscow Python Podcast старший владелец продукта компании Сибур Диджитал Вадим Щемелинин. Поговорили с Вадимом о Индустрии 4.0, видеоаналитике в нефтехимии и о многом другом.
В гостях у Moscow Python Podcast руководитель подразделения World of Tanks Game Logic компании Wargaming Левон Авакян. Поговорили с Левоном о правильном развитии разработчика.
В нашем очередном стриме мы встречаемся с Сергеем Васильевым, разработчиком в компании Datafold. 6 лет назад Сергей переехал в Берлин, где работал в компаниях Profitbricks и Zalando, а недавно он начал работать в американском стартапе Datafold на удалёнке. О нюансах трудоустройства и работы за рубежом и о разнице релокации и работы на удалёнке мы с ним и поговорим.
В гостях у Moscow Python Podcast разработчик компании Recall Masters Анатолий Щербаков. Поговорили с Анатолием о документации к вашему коду, почему она нужна и о подходе Docs as Code.
В гостях у Moscow Python Podcast Data Scientist компании Лаборатория Касперского Дмитрий Аникин. Поговорили с Дмитрием о Python в машинном обучении, инфраструктуре моделей и многом другом.
В гостях у Moscow Python Podcast разработчик в Raiffeisen Bank Влад Лоухин. Поговорили с Владом о том, что Python делает в банке, специфике Python в банковской сфере и о многом другом.