#courses #math
Самые основы математики и программирования

https://www.youtube.com/@dudvstud9081

📹 В какой-то момент я офигел, что умеет ffmpeg.

Как-то на физтехе мы делали phystech.tv: 24/7 стрим из видосов, которые были сняты в МФТИ. А это бесконечные "посвятские видосы первокурсников”, Тьмовости и треш-контент от Бужанского. И это все работало 1 строчкой в терминале.

Недавно на hackernews нашел волшебный гайд по ffmpeg. Если вам нужно сделать что-нибудь с видео или аудио - я уверен, что для этого уже есть ffmpeg filter.

🔗 https://img.ly/blog/ultimate-guide-to-ffmpeg/

Играющий тренер

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

Кто это
Довольно распространенная вакансия, где руководителя разработки хотят с глубокими экспертными знаниями. Ну, кажется, что всё нормально, и ничего сильно подозрительного нет.
А потом читаешь текст вакансии и там говорится, что подобный тимлид должен:
⁃ проектировать и реализовывать сложные архитектурные решения;
⁃ заниматься наймом команды;
⁃ заниматься людьми, их обучением, ростом, мотивацией;
⁃ заниматься рабочими процессами;
⁃ заниматься проектным менеджментом.
Ну то есть примерно быть разработчиком, тестировщиком, админом/девопсом, эйчаром и ПМом в одном лице.
Это то, что прямо сразу в голову приходит. Напишите в комментариях, чем еще «должен» заниматься играющий тренер.

80 на 80
Отсюда появляется золотое правило для тимлидов подобного рода. В вакансии пишут, что они 80% времени должны писать код, но мы-то понимаем, что менеджерских активностей тут еще на 80%. А уж как вы эти 160% уложите в рабочие дни, да так, чтобы качество у каждого вида деятельности не страдало – это ваши заботы.
Зато вам будут платить аж на 20-25% больше, чем какому-нибудь сеньору, который только задачи из to do забирает в in progress, пишет код и в done их двигает. При этом не теряя своих хард скиллов, свободно конвертируемых в деньги на рынке труда любой страны и любой компании.

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

Если у вас большая команда, расхлябанные рабочие процессы и проблемы с коммуникациями между смежными отделами, ну и нанимайте такого тимлида, который это пофиксит, а не будет сидеть 80% времени просто код педалить.

Если у вас 1-2-3 землекопа и всё уже отлажено в целом, то пусть приходит и правда какую-то серьезную часть времени код пилит, попутно подтюнивая эволюционирующие рабочие процессы, направляя команду и проект к светлому будущему.

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

В этом плане мне очень нравится пример Антона Околелова из подкаста Цинковый прод. Он как-то писал, что ему не хочется расставаться с кодом, но и тимлидить нравится. Поэтому он сознательно идет тимлидом в небольшие команды (2-3 человека), чтобы в комфортном для себя режиме на двух стульях усиживать без вреда для дела.

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

Написал небольшой эпос о библиотеке transformers.
И хотя текста много это все равно только лишь введение. Функционала в библиотеке слишком много.
https://habr.com/ru/post/704592/

Для тех кто не в курсе: библиотека Transformers предоставляет доступ к куче современных предобученных DL-моделей.
И на текущий момент является чуть ли не аналогом скалерна в мире Deep Learning.

​​#statistics

Поговорим о causal trees.

Ранее мы говорили об uplift trees. Causal trees - некоторое обобщение для построения деревьев в causal inference.

Что же там происходит?

Как я ранее говорил, в обычных uplift trees используются некоторые эвристики, которые позволяют посчитать приближение при разбиении и учесть его при построении дерева.

Но что, если мы сделаем иную (и более честную) функцию для того, чтобы разделять дерево на ветви? Про это как раз и следующая работа (Athey, Susan, and Guido Imbens. "Recursive partitioning for heterogeneous causal effects." Proceedings of the National Academy of Sciences 113.27 (2016): 7353-7360).

Почему нам важно иметь иную функцию для разбиения? Все потому, что у нас стоит принципиально иная задача. Это не обычная классификация или регрессия, а оценка причинности влияния и размера эффекта. Соответственно, обычные методы будут привносить смещение (bias). И оценки наши, увы, будут несостоятельны.

Соответственно, наш критерий для сплита должен учитывать (см. пример хорошего и плохого разбиения в изображении к посту):
- Баланс между попавшими в ветвь дерева объектами из target и control;
- Ожидаемую точность оценки CATE (conditional average treatment effect). Если разбиение разбивает на группы неточно, то мы получаем искажение в нашей оценке

Потому, давайте введем новую функцию для получения оптимального разбиения - EMSE (expected mean squared error for treatment effects). Если коротко, то это просто MSE с поправкой и учетом разделения на тест и обучение. Выглядит формула примерно так 1 / N_test * sum_N_test( (Y_i - tau_est)**2 - Y_i**2)

То есть, мы обучаем наше разделение на одном множестве, а потом подставляем в другое. На коем и вычисляем MSE с поправкой на константу. Ну а expected здесь - это мат. ожидание от нашего MSE. При этом, test и estimation у нас независимы.

Доказано, что такая функция позволяет нам иметь нужные статистические свойства.

Итог:
Кажется весьма интересным такой способ оценки. Да и весьма в стиле ML решений с разделением на train/test части. Подробнее можно почитать в статьях + в этом блог-посте. А реализацию на python можно найти в пакете econml.

Зачем нужен code review

Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. В дополнение к статическому анализу в настроенном pre-commit и тестам
— выявить проблемы в архитектуре
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных

В долгосрочной перспективе постоянные code review:
— налаживают обратную связь между участниками
— бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода
— помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде
— дают приток новых идей для улучшений в процессах, подходах и автоматизации
— увеличивают децентрализацию знаний и bus factor

В статье из заголовка даны примеры хорошего и плохого code review, способы прокачки и вообще много разных нюансов.
#skills

#python #courses

Курс: Основы Python с примерами и заданиями

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

Подобнее:👉тут

Решила собрать разные челленджы и проекты, где можно попрактиковать Tableau. На самом деле, никто не мешает брать эти данные и делать визы где угодно.

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

Челленджи:
• #B2VB Back 2 Viz Basics – новые задачки каждую неделю, идут от простых к сложным обычно. Прямо что-то конкретное, сделать такой-то график.
• #WorkoutWednesday – повторить визуализацию из примера.
• #MakeoverMonday – новые данные каждую неделю по созданию своих визуализаций.
• #IronQuest – практика создания визов и подготовка к Iron Viz (крупному датавиз конкурсу).
• #RWFD The Real World Fake Data – создание дэшбордов на настоящий и не очень данных
• #GamesNightViz – челлендж с данными про игры
• #SportsVizSunday – челлендж со спортивными данными

Проекты:
• #EduVizzers – визуализация данных про образование.
• #ProjectHealthViz – визуализация данных по теме здравоохранения
• #PublicPolicyViz – датавиз про политику
• #VizForSocialGood – датавиз про социальные данные и НКО

ps по их хэштегам можно в твиттере найти работы участников

Лекция об эффективных инструментах тестирования в Питоне от Рэя Хеттингера, разработчика ядра.

https://www.youtube.com/watch?v=ARKbfWk4Xyw&ab_channel=SFPython

Резюме:

1) всегда используйте доктесты, это мотивирует писать качественную документацию и учит вас (не говоря о других) использовать ваш же код. это настолько крутой инструмент, что не использовать его просто глупо. (я его теперь стараюсь всегда использовать). А ещё Сфинксом можно создавать красивые онлайн доки прямо из docstring.

2) не используйте модуль unittest, вместо него берите py.test: понятнее синтаксис, на 60% меньше печатания.

3) Рэй предпочитает PyFlakes вместо PyLint по причине излишней предвзятости и болтливости последнего )

4) статическая типизация не всегда улучшает читаемость кода, зачастую с ней приходится бороться дольше, чем писать сам код (чтобы убедить проверяющий инструмент). возможный выход – gradual typing.

5) интересен пример модуля, проходящего доктесты, юниттесты, имеющего 100% покрытие, строгую типизацию (проходящую проверки mypy), и всё же содержащего много критических ошибок, которые ждут своего часа, чтобы всплыть.

6) с подобными логическими ошибками помогает бороться пакет Hypothesis, который позволяет для входов функции с помощью декоратора задать стратегии (например: текст, или список целых чисел), автоматически влекущие синтез разнообразных тестовых значений, в том числе и краевых. Этот инструмент за секунды придумает и набросит вашей функции на вход столько всего самого разного и неожиданного, что сами и за неделю не составите ) В примере из доки пакет Гипотезы для текстового входа быстро находит ошибку для пустой строки, а затем и куда более нетривиальную логическую, возникающую при наличии в строке повторяющихся символов.

Библиотека Xgbfir
Библиотека Xgbfir (сокращение от XGBoost Feature Interactions Reshaped) – это парсер дампа модели XGBoost, который ранжирует признаки, а также взаимодействия признаков по различным метрикам, и записывает результаты в файл Excel. Проект начался с портирования библиотеки xgbfi, написанной Маттиасом Мюллером на C++, на Python. Главной функцией является функция saveXgbFI(). В функцию saveXgbFI() передаем модель XGBoost (бустер) и настраиваем параметры. Разберем параметры функции saveXgbFI():
• SortBy – метрика (по умолчанию 'Gain', возможные значения: 'Gain', 'FScore', 'FScoreWeighted', 'AverageGain', 'ExpectedGain' и др.), по которой ранжируются признаки и взаимодействия признаков, ниже разберем каждую метрику;
• OutputXlsxFile (по умолчанию 'XgbFeatureInteractions.xlsx') – название файла Excel, в который записываются результаты;
• MaxInteractionDepth (по умолчанию 2) – максимальное количество извлекаемых взаимодействий признаков (начиная с 0, например, 3 задает извлечение признаков, 2-факторные взаимодействия, 3-факторные взаимодействия и 4-факторные взаимодействия);
• MaxTrees (по умолчанию 100) – максимальное количество деревьев, используемых для извлечения признаков;
• TopK (по умолчанию 100) – количество извлекаемых наилучших признаков;
• MaxHistograms (по умолчанию 10) – максимальное количество гистограмм.

Для каждого признака выводятся 15 метрик:
• Gain – общий выигрыш каждого признака и взаимодействия;
• FScore – количество возможных разбиений, связанных с признаком или взаимодействием признаков;
• wFScore – количество возможных разбиений по признаку или взаимодействию признаков, взвешенное по вероятности разбиения;
• Average wFScore – значение wFScore, поделенное на значение FScore;
• Average Gain – значение Gain, поделенное на значение FScore;
• Expected Gain – общий выигрыш каждого признака или взаимодействия признаков, взвешенный по вероятности получения выигрыша;
• Gain Rank – ранг признака или взаимодействия признаков на основе значения Gain;
• FScore Rank – ранг признака или взаимодействия признаков на основе значения FScore;
• wFScore Rank – ранг признака или взаимодействия признаков на основе значения wFScore;
• Average wFScore Rank – ранг признака или взаимодействия признаков на основе значения Average wFScore;
• Average Gain Rank – ранг признака или взаимодействия признаков на основе значения Average Gain;
• Expected Gain Rank – ранг признака или взаимодействия признаков на основе значения Expected Gain;
• Average Rank – ранг признака или взаимодействия признаков на основе усреднения значений Gain Rank, FScore Rank, wFScore Rank, Average wFScore Rank, Average Gain Rank и Expected Gain Rank;
• Average Tree Index – усредненный индекс дерева, выполняется усреднение на основе индексов деревьев, в которых был использован данный признак или взаимодействие признаков;
• Average Tree Depth – средняя глубина использования признака, по каждому дереву вычисляем глубину, на которой был впервые использован данный признак, суммируем глубины и полученную сумму делим на количество деревьев.