Собрали в одном месте самые важные ссылкичитайте нас в Telegram
Иногда проект перерастает Django ORM, и в игру входит SQLAlchemy. Расскажу, как каждый из них справляется (или нет) с нашей сложной бизнес-логикой. Ещё немного о том, почему мы выбрали SQLAlchemy, а что всё-таки можно было сделать, не выходя из Django. Слайды: https://moscowpython.ru/meetup/77/django-alchemy/
В гостях у Moscow Python Podcast Lead of HR Community Skolkovo Алиса Цапкова. Обсудили с Алисой зачем нужны хакатоны, советы и лайфхаки участникам хакатонов.
В гостях у Moscow Python Podcast Python CTO проекта Speechki Павел Мальцев. Поговорили с Павлом о том, как и когда использовать Redis, какие там есть структуры данных и когда они будут полезны.
В гостях у Moscow Python Podcast Python ML и DataOps lead компании Gett Семён Осипов. Поговорили с Семёном о его пути в разработке и что такое ML и DataOps и зачем он нужен.
В гостях у Moscow Python Podcast Python Team lead компании VK Group Юрий Орлов. Обсудили с Юрием его путь в программировании от джуна до тимлида
В гостях у Moscow Python Podcast Python руководитель группы разработки компании MTS AI Сурен Хоренян. Поговорили с Суреном о том, как быть техлидом и не мешать разработчикам.
В гостях у Moscow Python Podcast Python специалист по решению сложных технологических задач Александр Боргардт. Обсудили с Александром зачем устраивают конференции и как получить от них максимум пользы.
В гостях у Moscow Python Podcast Python руководитель разработки компании МЕДСИ Digital Николай Фоминых. Обсудили с Николаем, что такое DDD, зачем оно нужно и как применяют в МЕДСИ.
В гостях у Moscow Python Podcast Python руководитель разработки компании Магнит Антон Огородников. Обсудили с Антоном, как в Магните используют генерацию кода из OpenAPI спецификации, сбор метрик и как обстоят дела с генерацией кода в Python и Go.
В гостях у Moscow Python Podcast Python QA-инженер компании Genesys Юрий Польников. Обсудили с Юрием его путь из инженера в сфере строительства и преподавателя в разработчики.
Как разработать систему распознавания рыб на конвейерной ленте, имея на руках только видеозаписи рыб с ленты, raspberry pi и python. При этом хотим близкое к real-time быстродействие системы на rpi и не сойти с ума. Требования к модели: уметь отличать рыбу от остальных предметов, определять вид рыбы, положение рыбы на ленте (головой в сторону движения или хвостом, хребтом вправо или влево), брак. В данном докладе хотелось бы рассказать слушателям про путь в данной задаче: Поиск похожих решений: их достоинства и недостатки, Как формировали собственное решение: Детекция - Сегментация - Выбор моделей, Разметка, Обучение, Первые попытки и интеграции, Попытки обучить «легкие» модели и переразметка имеющихся данных.
Все мы привыкли, что Redis простой инструмент, который прекрасно подходит для кеширования в формате Key-Value. Однако в нём есть более весёлые структуры данных, которые могут сделать нашу жизнь веселее и приятнее. Залезем в кроличью нору и найдём в документации списки, хеши, множества и другие структуры. Покажу несколько кейсов из реального продакшена, где эти структуры полезны и как использовать их особенности себе на пользу. Строим свой велосипед на двух колёсах.
Вы уверены, что приходящие к вам данные соответствуют вашим ожиданиям? Добавим немного определённости в нашу жизнь с помощью Pydantic. В своём докладе я расскажу о том, как сериализовать и валидировать данные и почему это важно. Поделюсь тем, как мы значительно упростили процесс поддержки и парсинг параметров production приложения. И как использование Pydantic помогло нам: улучшить структурированность параметров, настроить версионирование и проверку в CI текущей схемы на наличие изменений, получить автоматическое построение документации параметров минимальными усилиями. И в целом расскажу о преимуществах, недостатках и полезных особенностях Pydantic. Как уйти от работы со словарями к классам. А также затрону нетривиальные возможности и случаи использования.
Доклад поможет раскрыть несколько важных моментов, которые помогут написать тесты дешево, быстро и правильно: Общая архитектура приложения, при которой удобно использовать интеграционные тесты Общая архитектура тестов Использование pytest и mocker На реальном примере покроем приложение сначала юнит-тестами и убедимся, что такой подход к тестированию не совсем корректный и в итоге пропускает ошибки в функционале. Параллельно посмотрим, что наличие исключительно интеграционных тестов тоже несет не всегда позитивные последствия. На примере доклада рассмотрим подход к разработке, который находится между TDD и "разработал и после покрыл тестами". Помимо всего прочего, сможем посмотреть, как можно тестировать код на максимальную глубину, даже захватывая базовые классы Слушатели смогут убедиться, что высокий процент покрытия тестами — это не всегда хорошо. А так же смогут понять, что разработка и параллельное тестирование собственного кода — это сбалансированный подход в плане качества кода, стоимости разработки. Мы сможем посмотреть на реальном примере, что писать тесты с хорошей архитектурой не так сложно и долго.
На питоне можно писать так и эдак, но когда ты в команде, кто-то "старший" решает, как лучше это делать. Вы могли слышать, что "этот код не питонячий", "так на питоне не пишут". Стоит разобраться почему. Я совсем недавно открыл для себя функциональное программирование, и мне понравился этот стиль. В основном композиция функций на языке Хаскель. Так как мой основной стек это Python, я предполагал, что такое можно сделать и на нем. Но почему все используют императивный подход в разработке и внедрить в свой рабочий проект новые идеи очень сложно. Если все таки захотим использовать функциональный стиль, с какими проблемами можем столкнуться? Если честно, в питоне мало фичей для ФП, но можно использовать диалекты, с помощью которых ваш код будет декларативным и более читаемым для людей. Но есть свои недостатки, которые нельзя игнорировать. В своем докладе я предлагаю познакомиться с этой темой и, возможно, вы отметите для себя что-то интересное.
Для работы HFT необходимы очень маленькие задержки. Поэтому при внедрении ML модели нужно учитывать ограничения на время расчёта признаков. Есть много докладов и статей на тему ускорения расчётов на pandas. Сюда можно отнести и pandarallel, и dask, и polars. Ребята из Intel даже рассказывали на прошлом PyCon-е про modin. Все эти инструменты работают при больших объемах данных. Но что делать, если количество строк меньше 1000 или даже 100? В данном докладе хочу осветить несколько тем: Почему так важна низкая задержка при hft Какие возможны оптимизации для снижения количества расчетов Numpy Structured arrays как замена Pandas DataFrame Вспоминаем математику и ещё немного сокращаем количество операций.
Рекомендации Авито — это первое, что видит пользователь, когда попадает на главную страницу. Нагрузка на наш основной сервис — порядка 200 тысяч запросов в минуту. За последние два года мы сильно улучшили качество рекомендаций, но сильно проиграли в latency. Главным врагом производительности и latency стало добавление ML модели второго уровня на основе CatBoost для ранжирования объявлений от базовых ML моделей первого уровня в реалтайм. В докладе я расскажу: Как мы приняли решение переписать все на Go, перед этим мы выжали из Python все, что смогли; Как подружили CatBoost с Go и стали использовать ML модель на основе CatBoost в Go; Что получили по latency и потреблению memory/cpu.
В гостях у Moscow Python Podcast Python Data Scientists компании Кухня на районе Кирилл Малев и Сергей Макарин.
В гостях у Moscow Python Podcast Python ведущий разработчик компании Monite Богдан Евстратенко. Обсудили с Богданом CI/CD, Kubernetes и нужно ли сейчас знать это разработчику, собеседования в IT и бизнес подход к решению задач.
Поговорили о идеальном возрасте разработчика и существует ли он и о том, почему происходит утечка мозгов и возможно ли с этим что-то сделать.