Доклады

Классическая история: пытаетесь распилить бэк на микросервисы, а на выходе получается все тот же монолит, только распределенный, который все так же сложно поддерживать. ИЛИ. Начали рефакторинг, и только на середине стало понятно, что надо было делать по-другому.

Можно ли снизить риск переделок или хотя бы уменьшить затраты сил и времени на них? Можно.

Доклад — небольшая часть масштабного исследования, которое я веду с 2017 года. Разобрал за это время более 500 проектов и решений, около 20 из которых — мой личный опыт как full time-программиста и проектировщика.

Из доклада вы узнаете:
* как подходить к масштабному рефакторингу бэкенда, чтобы не запроектировать себя в угол;
* с какими трудностями вы столкнетесь в процессе;
* упростить внедрение новых фич, когда новая архитектура доедет до прода.

Ни одна система не может иметь 100%-ную доступность. Поэтому, реализуя межсистемные и, в особенности, синхронные интеграции, мы задумываемся об использовании различных паттернов устойчивости, таких как cirquit breaker, rate limiter, retry и другие.

Перед внедрением Envoy мы изучали имеющиеся библиотеки, реализующие паттерны устойчивости для разных языков программирования. Как пример — Hystrix, resilience4j для Java, но зрелых решений для Python не нашли. Поэтому мы рассмотрели использование отдельной системы, применение которой не зависит от языка программирования.

В текущем докладе я предлагаю ознакомиться с готовым OpenSource-решением, которое позволит использовать паттерны устойчивости вне зависимости от используемых языков программирования.

В Positive Technologies мы разрабатываем много крутых продуктов! Два из них — PT Sandbox и PT Multiscanner.

Хотим поделиться опытом разработки продуктов Enterprise-уровня на Python с использованием асинхронности, K8s и микросервисов. С какими проблемами мы столкнулись, как их решали.

Доклад будет про Python, Asyncio и немного затронем тему интеграции с другими языками.

Вы узнаете о Trunk-Base Development (TBD) и его инструментах.

Trunk — ствол или магистраль — легкочитаемая модель ветвления в GIT за счет прозрачной истории коммитов в одной ветке. Достижение такой простоты рассмотрим на двух примерах: при добавлении новой функциональности и изменении старой.

Также на примере продуктовой команды X5 Tech расскажу о том, какие инструменты TBD использовали мы, а от каких отказались. Надеюсь, это поможет вам при работе с legacy-кодом найти решения проблем: codefreeze, merge-hell и редкие релизы.

Среди нововведений 3.12 можно заметить поддержку в интерпретаторе профилировщика perf. Последний хорошо известен среди разработчиков на компилируемых языках, поскольку является одним из самых популярных инструментов поиска бутылочных горлышек в производительности под Linux.

Его применение для Python ранее было возможно технически, но не имело практической пользы, поскольку могло показать только внутренности интерпретатора без привязки к функциям в самом Python. Теперь ситуация поменялась, и мы можем полноценно сравнить возможности perf с такими популярными инструментами как cProfile и line-profiler.

Привет всем! Меня зовут Денис и мой доклад на суперострую тему. Шучу! Я просто хочу поговорить о найме программистов. Эту тему обсуждали уже тысячу раз и, кажется, едва ли тут можно сказать что-то новое. И вот теперь, когда все закрыли страницу, поговорим о важных вещах.

Если ты нанимающий, задавай алгоритмические задачи, и всё будет хорошо. Или нет? Хорошо. Возьмем задачи с литдкода! Тоже плохо? Попробуем заставить программистов писать стандартные сортировки? Это уже не тренд?! Chat gpt считает иначе! Ладно, может быть, будем давать программистам простые задачки, которые любой решит за «пять минут» (наши специальные фирменные пять минут)? Вот это огонь! И добавим ещё system design interview? Прошел — значит сеньор. Просто суперотбор!

А если ты нанимающийся? Да тут тоже нечего думать: всего какая-то 1000 задач на литкоде устроит каждого нанимающего. И на закуску стоит почитать system design primer, как раз на один вечер. Кто из нас не сможет на ходу спроектировать наколеночный аналог twitter! Это же совсем просто, немного round-robin и балансировщиков, cqrs, пару кэшей, немного размышлений на тему CAP, Paxos и RAFT — и мы в дамках!

Крабовые палочки! Узнали? Согласны? Подписыва... Давайте серьезно. Я давно в IT, видел много «поколений» найма, участвовал урывками в собеседованиях, ещё начиная с 2008 года, а сейчас практикую без остановки технические собеседования как минимум последние 4 года, а также подготавливаю технических интервьюеров. И мне, наконец, есть что сказать — я не согласен с текущими практиками отбора. Кроме того, я хочу стать адвокатом тех людей, которые не любят алгоритмические задачи, литкод, вайтбординг, лайвкодинг, переворот деревьев, O(N), домашние задания и, простите меня за это, возможно, даже священный system design interview. Этих людей никто никогда не защищает и консенсус всегда на «другой» стороне. Даже chat gpt — тот ещё любитель алгоритмов, хотя и все его ответы идеально складываются в собес-буллшит-бинго. Будет субъективно, возможно, загорится пару стульев в зале, но я постараюсь представить общий вид текущей ситуации, мои мысли, почему мы к этому пришли, рассказать пару баек из жизни и изложить мое видение и подход.

А ещё я очень постараюсь избегать летучих выражений вроде «наём сломан».

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

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

Доклад про LALR, PEG, LR(1) и другие аббревиатуры, а также практическое использование парсеров в Python — посмотрим на lark, parsimonious, antlr и другие и, конечно же, не забудем ply.

Интроспекция 80-ый левел: как из исходного Python-кода получить байт-код и затем обратно исходный код. Как JIT-компиляторы вроде Numba, Taichi или TorchJIT компилируют Python-код на лету. И, конечно, посмотрим на побочные применения всех этих компиляторных штук и далеко не только с целью ускорить выполнение кода.

Have you really thought about what types are? The different ways we can use them?

This presentation is going to show an approach of how to develop code thinking more about types and how them can work with the type checkers to catch problems before possible runtime issues! Let's talk about type wrappers, phantom types, algebraic data types.

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

В докладе рассмотрим:
* как следует использовать pandas и как при необходимости его ускорить;
* почему стоит использовать Feature-engine, a также как не стоит использовать streamlit;
* другое.

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

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

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

Как мы можем использовать Python для извлечения значимых выводов из сложных и разнородных источников данных? Как убедиться, что они логически непротиворечивы?

Из данного доклада вы узнаете про базы знаний, будут представлены некоторые инструменты и подходы для извлечения знаний с использованием Python, сосредоточившись на использовании SparQL, RDF, OWL, онтологий, графов знаний, ризонеров и библиотек Python для работы с этими инструментами.

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

В докладе будут рассмотрены следующие вопросы:
* Что такое базы знаний, как они хранят информацию и чем отличаются от баз данных?
* Что такое извлечение знаний из данных и зачем оно нужно?
* Как использовать SparQL для выполнения сложных запросов базам знаний?
* Как использовать RDF и OWL для описания семантики и логики данных?
* Как создавать и использовать графы для структурирования и классификации данных?
* Как использовать ризонеры для получения новых знаний?
* Какие инструменты существуют для работы с SparQL, RDF, OWL, графами знаний и ризонерами?

Есть такая задача — анализировать новости, связанные с инцидентами в ИБ. Специалисты, которые этим занимаются, собирают списки новостей и выделяют метрики из текста. Например, кто злоумышленник, когда произошел инцидент, какие последствия или сумма ущерба и др.

Сейчас 1 аналитик тратит 5-6 недель на обработку 700 новостей в квартал. Некоторые метрики явно есть в тексте, а некоторые можно определить только по контексту.

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

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

В наше время появляется возможность заменить ручное тестирование автоматизированным с целью предупредить как можно большее количество проблем, а также для увеличения стабильности приложения.
Автоматизация тестирования помогает решить такие вопросы, как: "А весь ли код покрыт тестами?”, “Что еще могло быть не учтено в процессе тестирования?”, “Как понять, что код полностью рабочий, качественный?”.

Для решения этих проблем был разработан инструмент тестирования EQATOR, описанию возможностей которого и будет посвящен доклад.

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

В докладе обсудим:
* какие библиотеки чаще всего используют для настройки логов;
* почему стоит выкинуть loguru из вашего проекта и чем его можно заменить;
* на примере sentry-sdk посмотрим, как другие библиотеки могут использовать ваши логи;
* какие есть хорошие и не очень практики по написанию логов.

Злоумышленники в своем стремлении протроянить разработчиков могут использовать разные методы, такие как создание пакетов с ошибками в названиях (rquests, request) в надежде, что человек опечатается при установке, копирование описания оригинального пакета, а также подкрутка репутации добавлением нескольких десятков тысяч звёзд на страницу своего проекта буквально в пару кликов ---без регистрации и смс---.

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

MapReduce 2023: обзор сценариев, когда релевантно использование фреймворка.

Оптимизация MapReduce вычислений при обработке больших объёмов данных:
* управление Shuffle & Sort с помощью компонентов Partitioner and Comparator;
* оптимизация вычислений с помощью Combiner;
* настройка JVM под Hadoop Streaming tasks;
* управление упаковкой и доступностью данных в период вычислений;
* минимизация data serialization при работе с текстовыми данными;
* эффективные join'ы между большими datasets без использования reduce-фазы.
(сравнительный анализ стратегий выполнения SQL-запросов поверх HDFS и поверх структурированных баз данных).

Роль выбора методологии проектирования DWH в построении эффективной платформы BI.

Все мы знаем, что существует множество способов преобразования данных — от простых скриптов на коленке и длинных SQL-запросов до сложных платформ, таких как Airflow. Однако часто эти методы имеют свои недостатки и не удовлетворяют нашим потребностям.

В этом докладе мы рассмотрим, как dbt и Python могут решить многие проблемы в области преобразования и подготовки данных для аналитики. Разберем, как сделать пайплайн для обработки наших данных с тестированием и версионированием. Добавим в скучный SQL шаблонизатор Jinja и функции на Python.