#advice #libraries
Как оказалось, японцы весьма специфично записывают год.
Если для нас это просто n-й год н.э., то у представителей страны восходящего солнца это n-й год эры такого-то императора. К примеру, сейчас идет эра Рейва, так что 2021 год будет Reiwa 3 (то есть 3й год эры Рейва).
Что с этим делать?
Я нашел библиотечку для парсинга года по японскому исчислению. Там возможен перевод с достаточно бородатых годов по нынешнее время. Если вдруг понадобится работать с данными в японском формате - используйте ее.
Как оказалось, японцы весьма специфично записывают год.
Если для нас это просто n-й год н.э., то у представителей страны восходящего солнца это n-й год эры такого-то императора. К примеру, сейчас идет эра Рейва, так что 2021 год будет Reiwa 3 (то есть 3й год эры Рейва).
Что с этим делать?
Я нашел библиотечку для парсинга года по японскому исчислению. Там возможен перевод с достаточно бородатых годов по нынешнее время. Если вдруг понадобится работать с данными в японском формате - используйте ее.
#management
Почему в data science командах плохо приживается scrum?
Провокационный заголовок, но я правда считаю, что в чистом виде scrum плохо приживается в data science командах. Какие-то смеси и вариации запустить можно, но все равно придется учитывать специфику.
А какая тут, собственно, специфика?
1. Очень сложно оценить заранее, сколько займет та или иная задача. Да, даже в майках/картах и т.п. Да, даже при неплохой декомпозиции задач. Т.к. достаточная часть задач являются исследовательскими, неопределенность в них зашкаливает. А при высокой неопределенности и оценки будут скакать;
2. Некоторые задачи могут перестать быть актуальными в середине спринта. К примеру, вы исследовали данные и поняли, что данных вам не хватает (и не хватит в ближайшее время). Сделали тикеты на доработку, успокоились. Но вот еще половина спринта осталась. То ли всегда брать больше задач (и часто проваливать спринт), то ли часто получать ситуацию, что команда отдыхает половину спринта. Нехорошо;
3. Тяжелый хвост для некоторых задач. Бывают случаи, когда задача вроде бы начинает решаться, работы идут. Но тут оказывается, что нужно исправлять разметку, править библиотечную реализацию, дорабатывать гипотезу и т.д. И такое случается гораздо чаще и с гораздо большей задержке, чем в разработке. Тогда задача начинает кочевать из спринта в спринт с переносами.
Учитывая особенности выше, частенько скрам об них разбивается. И тогда либо на что-то забивают и делают, как выйдет, либо колются дальше, народ негодует и потихоньку разбегается.
Как адаптироваться?
В принципе, неплохо подходят смешанные подходы, вроде скрамбана (https://ru.qaz.wiki/wiki/Scrumban). Может подойти использование канбана, но с учетом того, что у нас есть какой-то план релизов или предоставления артефактов. Но результат все равно придется под себя адаптировать.
Еще вариант - это помимо “сложности” задачи учитывать степень ее неопределенности. В таком случае, можно попробовать вставлять в спринт задачи не только на основе стори-поинтов, но и на основе уровня неопределенности задач. К примеру, если у нас есть задачи, плотно упаковывающиеся в спринт, но с высокой неопределенностью, то лучше понизить неопределенность за счет возможной недозагрузки спринта. Либо тасовать задачки таким образом, чтобы там точно набирался нужный процент “безрисковых” задач. Ну и абсолютно точно придется часто заново калибровать наши шкалы задач и степени неопределенности.
Почему в data science командах плохо приживается scrum?
Провокационный заголовок, но я правда считаю, что в чистом виде scrum плохо приживается в data science командах. Какие-то смеси и вариации запустить можно, но все равно придется учитывать специфику.
А какая тут, собственно, специфика?
1. Очень сложно оценить заранее, сколько займет та или иная задача. Да, даже в майках/картах и т.п. Да, даже при неплохой декомпозиции задач. Т.к. достаточная часть задач являются исследовательскими, неопределенность в них зашкаливает. А при высокой неопределенности и оценки будут скакать;
2. Некоторые задачи могут перестать быть актуальными в середине спринта. К примеру, вы исследовали данные и поняли, что данных вам не хватает (и не хватит в ближайшее время). Сделали тикеты на доработку, успокоились. Но вот еще половина спринта осталась. То ли всегда брать больше задач (и часто проваливать спринт), то ли часто получать ситуацию, что команда отдыхает половину спринта. Нехорошо;
3. Тяжелый хвост для некоторых задач. Бывают случаи, когда задача вроде бы начинает решаться, работы идут. Но тут оказывается, что нужно исправлять разметку, править библиотечную реализацию, дорабатывать гипотезу и т.д. И такое случается гораздо чаще и с гораздо большей задержке, чем в разработке. Тогда задача начинает кочевать из спринта в спринт с переносами.
Учитывая особенности выше, частенько скрам об них разбивается. И тогда либо на что-то забивают и делают, как выйдет, либо колются дальше, народ негодует и потихоньку разбегается.
Как адаптироваться?
В принципе, неплохо подходят смешанные подходы, вроде скрамбана (https://ru.qaz.wiki/wiki/Scrumban). Может подойти использование канбана, но с учетом того, что у нас есть какой-то план релизов или предоставления артефактов. Но результат все равно придется под себя адаптировать.
Еще вариант - это помимо “сложности” задачи учитывать степень ее неопределенности. В таком случае, можно попробовать вставлять в спринт задачи не только на основе стори-поинтов, но и на основе уровня неопределенности задач. К примеру, если у нас есть задачи, плотно упаковывающиеся в спринт, но с высокой неопределенностью, то лучше понизить неопределенность за счет возможной недозагрузки спринта. Либо тасовать задачки таким образом, чтобы там точно набирался нужный процент “безрисковых” задач. Ну и абсолютно точно придется часто заново калибровать наши шкалы задач и степени неопределенности.
#libraries
OSMNX - библиотека для получения данных о дорожных сетях из OSM. Можно указывать, какой город или полигон вас интересуют и получить дорожную сеть в виде графа и географической информации.
По полученным данным можно строить статистики на графе, искать кратчайший путь (не очень быстро из-за реализации), строить путь на карте.
В общем, очень удобный инструмент для работы с данными графов дорог. А главное - открытый.
OSMNX - библиотека для получения данных о дорожных сетях из OSM. Можно указывать, какой город или полигон вас интересуют и получить дорожную сеть в виде графа и географической информации.
По полученным данным можно строить статистики на графе, искать кратчайший путь (не очень быстро из-за реализации), строить путь на карте.
В общем, очень удобный инструмент для работы с данными графов дорог. А главное - открытый.
#competition
Почему участвовать в соревнованиях лучше командой?
На самом деле, ответ простой - распределение рисков. Если вы участвуете в одиночку, то призов получите больше, но и рисков будет пропорционально больше. Все оттого, что не всякий сможет тащить много активности в одно лицо.
Какие плюсы команды:
1. Больше мотивация. Если кто-то застопорился, то нежелание подвести товарищей может помочь продолжить “пилить”;
2. Перенос знаний. Каждый из нас лучше знает те или иные области. Чем больше людей - тем больше разных точек зрения, подходов, фишек. Особенно, если подобралась опытная компания;
3. Больше идей. В одиночку сложно штормить, а командой можно собираться каждую неделю и устраивать новый штурм по итогам недели;
4. Больше работы в единицу времени. Чем больше людей - тем больше можно сделать работы, тем больше проверить гипотез. Верно и обратное - чем больше людей, тем меньше работы для каждого из них. Соответственно, вероятность выгореть меньше (ну если вы только не тянете лямку за всю остальную команду, тогда шансы подгореть выше);
Какие минусы:
1. Выигрыш (при наличии такового) делится на всех. То есть денег на человека будет меньше;
2. Кому-то нужно организовывать команду и тратить время на коммуникацию. Если все суровые интроверты, то команде будет туго;
3. Если команда не сыграна, то могут быть конфликты. Кто-то решил отдохнуть вместо своей части, кто-то не согласен с “линией партии”, кто-то считает, что наработал на половину приза, а не на четверть. Все это ведет к конфликтам и может потопить команду.
В общем, я бы рекомендовал иметь на примете товарищей. Особенно, если хочется “зайти” сразу в несколько разных соревнований. В таком случае, у вас будет меньше шансов выгореть, а работа получится более дисциплинированной.
Почему участвовать в соревнованиях лучше командой?
На самом деле, ответ простой - распределение рисков. Если вы участвуете в одиночку, то призов получите больше, но и рисков будет пропорционально больше. Все оттого, что не всякий сможет тащить много активности в одно лицо.
Какие плюсы команды:
1. Больше мотивация. Если кто-то застопорился, то нежелание подвести товарищей может помочь продолжить “пилить”;
2. Перенос знаний. Каждый из нас лучше знает те или иные области. Чем больше людей - тем больше разных точек зрения, подходов, фишек. Особенно, если подобралась опытная компания;
3. Больше идей. В одиночку сложно штормить, а командой можно собираться каждую неделю и устраивать новый штурм по итогам недели;
4. Больше работы в единицу времени. Чем больше людей - тем больше можно сделать работы, тем больше проверить гипотез. Верно и обратное - чем больше людей, тем меньше работы для каждого из них. Соответственно, вероятность выгореть меньше (ну если вы только не тянете лямку за всю остальную команду, тогда шансы подгореть выше);
Какие минусы:
1. Выигрыш (при наличии такового) делится на всех. То есть денег на человека будет меньше;
2. Кому-то нужно организовывать команду и тратить время на коммуникацию. Если все суровые интроверты, то команде будет туго;
3. Если команда не сыграна, то могут быть конфликты. Кто-то решил отдохнуть вместо своей части, кто-то не согласен с “линией партии”, кто-то считает, что наработал на половину приза, а не на четверть. Все это ведет к конфликтам и может потопить команду.
В общем, я бы рекомендовал иметь на примете товарищей. Особенно, если хочется “зайти” сразу в несколько разных соревнований. В таком случае, у вас будет меньше шансов выгореть, а работа получится более дисциплинированной.
#interview #AB
Задача со страницы вакансий одной компании, название которой начинается на Y.
На прошедшей неделе в рекламной сети параллельно размещались два баннера. Оба баннера были показаны один миллион раз. Первый получил 10 000 кликов и 500 установок, а второй — 10 500 кликов и 440 установок. Маркетолог просит у вас совета: какой баннер оставить, а какой отключить. Что вы ему ответите? Обоснуйте свой ответ.
Тут идет первый вопрос - а что нам важнее? Установки или клики? Вопрос с подвохом, т.к. рекламной сети могут быть важный как первый, так и второй показатель. Все сильно зависит от того, по какому критерию производится оплата. Соответственно с этим, нам нужно считать результат.
Получаем, что нужно проверить два результата и выдать рекомендации:
1. Нужны установки;
2. Нужны клики.
Сделаем две оценки - посредством критерия хи-квадрат. Вторую оценку сделаем посредством бутстрепа.
В итоге получим, что для:
1. Важности кликов лучше взять первый баннер (где 10000 кликов и 500 установок);
2. Важности установок лучше взять второй баннер (где 10500 показов и 440 установок).
Расчеты в ноутбуке.
Задача со страницы вакансий одной компании, название которой начинается на Y.
На прошедшей неделе в рекламной сети параллельно размещались два баннера. Оба баннера были показаны один миллион раз. Первый получил 10 000 кликов и 500 установок, а второй — 10 500 кликов и 440 установок. Маркетолог просит у вас совета: какой баннер оставить, а какой отключить. Что вы ему ответите? Обоснуйте свой ответ.
Тут идет первый вопрос - а что нам важнее? Установки или клики? Вопрос с подвохом, т.к. рекламной сети могут быть важный как первый, так и второй показатель. Все сильно зависит от того, по какому критерию производится оплата. Соответственно с этим, нам нужно считать результат.
Получаем, что нужно проверить два результата и выдать рекомендации:
1. Нужны установки;
2. Нужны клики.
Сделаем две оценки - посредством критерия хи-квадрат. Вторую оценку сделаем посредством бутстрепа.
В итоге получим, что для:
1. Важности кликов лучше взять первый баннер (где 10000 кликов и 500 установок);
2. Важности установок лучше взять второй баннер (где 10500 показов и 440 установок).
Расчеты в ноутбуке.
#libraries
Pandas-profiling - библиотека для просмотра описательных статистик набора данных. Очень удобна для первичного EDA, если нужно быстро просмотреть набор данных и сформулировать первичное мнение и гипотезы.
Встроены: наиболее частые значения, гистограммы, корреляционные графики, графики попарных связей. Все в одном интерактивном окне.
Из минусов стоит отметить, что может долго раскочегариваться при запуске на объемных наборах данных.
Pandas-profiling - библиотека для просмотра описательных статистик набора данных. Очень удобна для первичного EDA, если нужно быстро просмотреть набор данных и сформулировать первичное мнение и гипотезы.
Встроены: наиболее частые значения, гистограммы, корреляционные графики, графики попарных связей. Все в одном интерактивном окне.
Из минусов стоит отметить, что может долго раскочегариваться при запуске на объемных наборах данных.
#competition
У меня есть некоторая эвристика - на соревнование стоит закладывать не меньше 50 часов.
Почему так?
На EDA, первый baseline, его допил до второго baseline закладываем 8 часов. Умножаем сроки на 2 (весьма щадящий коэффициент для переоценки сроков). Получаем около 50 часов.
Конечно, это скорее шуточное замечание, но примерно так обычно и выходит. Редко когда удается что-то приличное сделать за малое число часов, если нет уже готовых частей pipeline по задаче с каких-то предыдущих соревнований.
У меня есть некоторая эвристика - на соревнование стоит закладывать не меньше 50 часов.
Почему так?
На EDA, первый baseline, его допил до второго baseline закладываем 8 часов. Умножаем сроки на 2 (весьма щадящий коэффициент для переоценки сроков). Получаем около 50 часов.
Конечно, это скорее шуточное замечание, но примерно так обычно и выходит. Редко когда удается что-то приличное сделать за малое число часов, если нет уже готовых частей pipeline по задаче с каких-то предыдущих соревнований.
#interview #gnomiki
Два друга договорились встретиться в определенном месте между 12 и 13 часами. Пришедший первым ждет другого в течении 20 минут, после чего уходит. Чему равна вероятность встречи друзей, если приход каждого из них может произойти наудачу в течении указанного часа и моменты прихода независимы?
Ок, тут у нас задача на геометрическую интерпретацию вероятности. Нужно просто визуализировать указанные условия.
Пусть оси x и y - моменты прихода первого и второго друга соответственно. Оба значения находятся между 0 и 60 включительно. Отделяем участок, на котором разница модуля x - y будет не больше 20 минут. Далее считаем площадь полученного участка и сравниваем ее с общей площадью.
1. 60 * 60 (площадь квадрата) - 2 * 0.5 * 40 * 40 (площадь двух треугольников) = 2000
2. 2000 / (60 * 60) = 2000 / 3600 = 5 / 9
Итоговый результат: 5 / 9
Два друга договорились встретиться в определенном месте между 12 и 13 часами. Пришедший первым ждет другого в течении 20 минут, после чего уходит. Чему равна вероятность встречи друзей, если приход каждого из них может произойти наудачу в течении указанного часа и моменты прихода независимы?
Ок, тут у нас задача на геометрическую интерпретацию вероятности. Нужно просто визуализировать указанные условия.
Пусть оси x и y - моменты прихода первого и второго друга соответственно. Оба значения находятся между 0 и 60 включительно. Отделяем участок, на котором разница модуля x - y будет не больше 20 минут. Далее считаем площадь полученного участка и сравниваем ее с общей площадью.
1. 60 * 60 (площадь квадрата) - 2 * 0.5 * 40 * 40 (площадь двух треугольников) = 2000
2. 2000 / (60 * 60) = 2000 / 3600 = 5 / 9
Итоговый результат: 5 / 9
#libraries
Pre-commit - мультиязыковой фреймворк для использования precommit хуков.
Что такое precommit хук? Это некоторый набор команд/операций, которые хотелось бы проделать до того, как делать коммит. К примеру, нам хочется проверять код на соответствие pep8 перед тем, как закоммитить его.
Пример по ссылке выше:
Здесь мы указываем проверку yaml, фиксы для оформления кода, а так же применение форматирования посредством black.
Pre-commit - мультиязыковой фреймворк для использования precommit хуков.
Что такое precommit хук? Это некоторый набор команд/операций, которые хотелось бы проделать до того, как делать коммит. К примеру, нам хочется проверять код на соответствие pep8 перед тем, как закоммитить его.
Пример по ссылке выше:
repos:- repo: https://github.com/pre-commit/pre-commit-hooks rev: v2.3.0 hooks: - id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace- repo: https://github.com/psf/black rev: 19.3b0 hooks: - id: blackЗдесь мы указываем проверку yaml, фиксы для оформления кода, а так же применение форматирования посредством black.
#books
ДОВЕРИТЕЛЬНОЕ А/В-ТЕСТИРОВАНИЕ
Отличная книга про A/B тесты. Покрыто много тем и вопросов про внедрение культуры проведения A/B тестов. Можно давать менеджерам и новичкам, т.к. написано достаточно понятным языком
Очень рекомендую к прочтению.
ДОВЕРИТЕЛЬНОЕ А/В-ТЕСТИРОВАНИЕ
Отличная книга про A/B тесты. Покрыто много тем и вопросов про внедрение культуры проведения A/B тестов. Можно давать менеджерам и новичкам, т.к. написано достаточно понятным языком
Очень рекомендую к прочтению.