Собрали в одном месте самые важные ссылкиконсультируем про IT, Python
Улучшаем себе DX при помощи консольных инструментов Многие программисты до сих пор считают, что терминал — это инструмент бородатых админов из 80-х годов. На самом деле это не так — каждый год в сообществе появляются новые консольные инструменты, которые улучшают ежедневную рутину программиста: упрощают работу с гитхабом, поиск файлов, переход между проектами. Есть инструменты с говорящими названиями, к примеру tldr ускоряет чтение документации, а fuck — исправляет ошибку в последней введённой команде. На докладе я сделаю краткий обзор современных консольных инструментов, и расскажу о том, что ещё можно делать в терминале — к примеру редактировать текст быстрее, чем в GUI.
Как установить лицензионную защиту кода на Python и обезопасить данные с помощью HASP? Как подружить C/C++ и Python с помощью Cython? Как передавая ПО на Python не отдавать исходники? Как использовать зашифрованные модели из Python?
Каждый питонщик желает знать, где сидит setup.py. Но в части случаев он может оказаться переусложнённым, или наоборот, слишком простым. Какие ещё системы сборки есть для Python, будет рассказано в этом докладе.
Обсудим опыт жизни за рубежом и адаптацию в зарубежной компании, развитие, поиск наставника и всем ли нужно становиться тимлидами.
На мастер-классе вы будете первыми, кто воспользуется нашей oпенсорсной генеративной моделью. Обсудим, что такое языковая модель и как ее использовать для conversational AI. И на практике: Поборемся с основной проблемой языковых моделей, обученных на корпусе из Интернета — генерация токсичных ответов. Повысим качество ответов болталки с помощью классификаторов. Улучшим качество с помощью промт-тюнинга. Найдем топовый алгоритм декодирования (чтобы ответы были длинные и кайфовые). И в конце обернем нашу модель в сервис и телеграм бота. Так у каждого участника МК останется бот, с которым он сможет поболтать в любой момент. Мастер-класс рассчитан на ML инженеров, которые смогут разобраться с технологиями NLP.
Доклад про выбор компонентов решения MLOps и первые шаги внедрения. Рассчитан на архитекторов, тимлидов и датасаентистов, вовлеченных в построение инфраструктуры для работы моделей машинного обучения. Слушатели смогут понять, зачем нужен MLOps и зачем заниматься его внедрением, узнают, каков был наш путь по выбору компонентов решения и как мы их внедряем.
Летом 2021 Яндекс Погода представила новую модель машинного обучения для прогнозирования дождя — Meteum 2.0. Впервые в истории она опирается не только на данные специализированных приборов наблюдения за погодой, но и на сообщения пользователей об осадках. До Яндекса никто в мире так не делал. Я расскажу, какие данные Яндекс Погода использует для создания карты осадков, как с помощью python и машинного обучения улучшить качество классических методов прогноза. Подробно опишу этапы обучения модели и то, с какими трудностями пришлось при этом столкнуться.
Как подружить 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 сервиса. Мы затронем такие интересные вопросы как масштабирование, бесшовный вывод из и ввод в эксплуатацию, сокращение стоимости разработки и внедрение единого архитектурного стандарта.