«You Only Live Twice», (1967)

Развитие микроэлектроники, ИТ технологий и широкого спектра программных продуктов открыло новые возможности по контролю всего. Датчики, камеры, цифровые следы… Магнитофон в чемодане уже неактуален.

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

Все предыдущие публикации.

«How I Met Your Mother», season 6, ep. 7

Коля любит циклы. 
Толя любит циклы. 
Оля любит циклы. 
Все любят циклы. 

И Сережа тоже.

Один Мамба их не любит. И вот почему.

Если опустить философские рассуждения, что все на уровне процессора является циклом или goto, то можно выделить три причины:

1. При работе с индексами цикла можно легко проглядеть и допустить ошибку. Но тут помощь приходят итераторы.
2. Очень часто циклы вручную пишутся очень неэффективно с точки зрения манипуляций с памятью — сильная просадка по производительности. А у вложенных циклов еще и накладные на старт цикла.
3. Нелинейная структура цикла (break, continue) не позволяют сделать хорошую оптимизацию на уровне процессора или компилятора. А это дополнительно означает, что распараллелить цикл по вычислителям будет очень трудно. В решении этого вопроса помогает функциональный подход и итераторы. Если известно о независимости вычислений значений каждого отдельного шага — надо сообщать об этом компилятору явно.

Все предыдущие публикации.

Пока идут разговоры про отъезд ИТ специалистов, про их возврат, про поддержку ИТ компаний, а неофиты pandas восторженно разбирают json, есть предложение посмотреть на роль data science инструментов в современной ИТ инфраструктуре немного с другой точки зрения. DS — это ведь не только подсчет пельменей, накликивание мышкой графиков-пирожков или создание N+1 системы по рекомендации фильмов из вселенной Марвел.

Является продолжением серии предыдущих публикаций.

— Для некоторых людей одиночество и оторванность от мира могут стать проблемой.
— Только не для меня.
Кадр из фильма «The Shining», 1980 г.

В рядах аналитиков началась тихая паника. Заплатить в Google BigQuery в облачном варианте сейчас невозможно без иностранной банковской карты, Tableau и Microsoft «приостанавливают» свою активность в РФ, многие вендоры ушли, многие в низком старте.
Появляются материалы с вопросами «Пора менять Tableau, Power BI, Qlik? Как выбрать российский BI? Или не российский? Или не BI?» которые даже неприлично было задавать пару месяцев назад.

Но это прекрасный момент остановить ковейерное тиражирование шаблонов, выдохнуть и подумать «А что нам реально надо то?». И тут все становится не совсем очевидно.

Дальше картинок мало (0), по большей части текст и ссылки.

Анекдот

Буквально за неделю ИТ ландшафт изменился до неузнаваемости. Каждый день появляются новости об уходе или «приостановке работы» той или иной международной ИТ компании. Одномоментно кончились серверные мощности. И если кто-то прикупил с запасом (что делали достаточно редко), то тот оказался молодцом. Стиль работы надо экстренно и радикально менять. Если раньше можно было полгода играть в RFI, потом полгода в RFP, потом полгода бюджетировать, то теперь все схлопнулось до «одного дня» и не на кого возложить ответственность, вендоры исчезли.

Ситуация стабилизируется, но время стабилизации и новая конфигурация пока неизвестны. Очевидно, что новая конфигурация будет отличаться от той, что была последние лет 10-20.

«Неравный брак», В. Пукирев, 1862 г.

Задача объединения табличных представлений очень часто встречается как в аналитике, так и в разработке (БД). Существует несколько различных типов слияний, фактически, это операции над множествами. Не будем погружаться в детали, на эту тему написано множество книг, семинаров, публикаций. Посмотрим на эти механизмы в преломлении практических задач. Будем смотреть по нарастающей сложности и пытаться решить их на «офисном» ноутбуке, не привлекая бесконечные мощности больших данных или реляционные БД.

Является продолжением серии предыдущих публикаций.

Кадр из мультфильма «Раз горох, два горох», 1981, Союзмультфильм

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

Ниже три непридуманные истории, объединенные одной целью — достать информацию из открытого источника. Весь код написан «на салфетке», имеет сугубо иллюстративный и развлекательный характер.

Является продолжением серии предыдущих публикаций.

Кадр из фильма «Формула любви», 1984

В жизненном цикле любого эксплуатируемого ПО наступает фаза, когда накопившийся набор изменений (CR) ложится неподъемным грузом на первичную архитектуру и вот тут наступает пора рефакторинга. Много книг понаписано на эту тему, есть специфика для различных языков. Ниже затронем только отдельные аспекты, которые могут оказаться полезным применительно к RStudio Shiny приложениям. Это ряд практических методов, трюков и нюансов, накопившихся при рефакторинге, как правило, чужого Shiny кода.

«Aliena nobis, nostra aliis» — Ежели один человек построил, другой завсегда разобрать сможет.

Это было в фильме, в первоисточнике несколько по-другому. Фраза Публилия Сира «Aliena nobis, nostra plus aliis placent» переводится как «Чужое нам, наше же в основном другим нравится».
Но кузнец Степан все равно дело говорит.

Является продолжением серии предыдущих публикаций.

Н. Кобринский, В. Пекелис «Быстрее мысли» — Молодая гвардия, 1959

Когда все вокруг измеряют Гигабайтами, Петабайтами, Зетабайтами и т.д., все компании гордятся своей БигДатой, вспоминать о битах в приличном обществе воспринимается как моветон. Однако и биты иногда бывают полезны. Темой для разговора послужила одна типовая классическая задачка, лежащая в области опросов.

Является продолжением серии предыдущих публикаций.

Кадр из мультфильма «Смешарики: 132 серия (Пылесос)»

При проведении различной ad-hoc аналитики или же создания интеграций между DS решением и внешними системами очень часто приходится использовать REST API для получения данных. Ситуация, когда все помещается в один запрос — идеальна, но редка как единорог. Как правило, приходится тянуть большие объемы, тянуть по частям и в режиме многоходовок, возможно, с использованием курсоров. Внешняя система может лечь при большой нагрузке или же там включатся механизмы пропуска запросов (троттлинг). Вопросы «почему у меня не работает» и «как мне сделать, чтобы работало» возникают с завидной регулярностью.

Ниже приведен блочный разбор типового скрипта для получению данных из внешней системы через REST API. Его можно рассматривать как первое приближение решения задачи подобного класса.

Является продолжением серии предыдущих публикаций.

Кадр из мультфильма «Over the Garden Wall» (2014)

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

Однако, изначально просто счёт относился к computer science, а data science было более широким и междисциплинарным понятием. В классическом понимании data scientist — «T-shape» специалист, который оцифровывает и увязывает административные и предметные вертикали/горизонтали компаний через математические модели.

Далее немного иллюстрирующих примеров.

Является продолжением серии предыдущих публикаций.

Продакт-менеджерам посвящается...

Заступая на территорию proccess mining, каждый участник рано или поздно будет нуждаться в наборе логов событий, отражающих те или иные специфические моменты в процессах. Эти логи нужны как на этапе демонстрации решения, подсвечивания определенных вопросов, так и для отработки алгоритмов или же тестов на производительность. Оба рекомендуемых сценария «взять с продуктивных систем» или «взять из интернета» терпят фиаско. Как правило, это очень
малые датасеты, слабо удовлетворяющие потребностям как по наполнению, так и по объему.

Остается вариант — написать генератор правдоподобных логов самостоятельно. Тут тоже есть два варианта.

• Вариант первый — превратить эту задачу в универсальный монстроподобный продукт, содержащий визуальный конструктор в нотации BPMN 2.0, всевозможные визуальные конструкторы формул и атрибутов, полноценную имитационную машину под капотом. Годы работы, миллионы на ветер, на выходе — файл с логами. КПД близок к нулю.
• Вариант второй — отнестись к этой задаче как к вспомогательной и создать инструментами data science стека упрощенный генератор в 100 строк кода.

Остановимся далее на втором варианте.

Является продолжением серии предыдущих публикаций.

Кадр из фильма «Индиана Джонс: В поисках утраченного ковчега» (1981)

Наблюдаемая все чаще и чаще картина в задаче анализа данных вызывает удручающее впечатление. Intel, AMD и другие производители непрерывно наращивают вычислительную мощность. Гениальные математики-программисты пишут суперэффективные библиотеки и алгоритмы. И вся эта мощь гасится и распыляется рядовыми аналитиками и разработчиками. Причем начинается это все с нулевого этапа — этап подготовки и загрузки данных для анализа. Многочисленные вопросы и диалоги показывают, что в нынешних программах обучения зияют огромные дыры. Людям просто незнакомы многие концепции и инструменты, уже давно придуманные для этих задач. Для тех, кто хочет увеличить свою продуктивность, далее тезисно будут рассмотрены ряд таких подходов и инструментов в частичной привязке к реальным задачам.

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

Является продолжением серии предыдущих публикаций.

Кадр из фильма «Красный шар». Режиссер Альбер Ламорис. 1956 год

Так уж случилось, что у меня остался ряд репозиториев на Mercurial, которые захостил на Bitbucket много лет назад. Проекты перешли в полуархивное состояние, поэтому заглядывал в них не так уж и часто. И тут я решил обратиться к материалам, надо было внести правку. С удивлением обнаружил, что репозиториев на битбакете нет, но есть публикация «Sunsetting Mercurial support in Bitbucket».

Не критично, локальные репозитории сохранились же (а там коммитов за 10+ лет). Попробуем переехать на github/gitlab по инструкции из статьи. И, конечно же, эти инструкции работают только с latin-1, русские буквы либо не дают переехать, либо заменяются на ?. Извечная проблема кодировок. Можно ли что-то сделать?

UPDATE по результатам комментариев.
Для «приземления» задачи рассмотрите контекст коммерческой поддержки большой инсталляции ПО, созданного в компании где вы сейчас работаете, которое n лет уже не развивается (выпустили совсем новую ветку), но обязательства по поддержке остались по проданным ранее контрактам. И периодически всплывают баги.

Является продолжением серии предыдущих публикаций.

В подавляющем большинстве случаев, когда речь заходит о «настоящей» разработке продукта или решения enterprise уровня, сразу появляются корпоративные архитекторы и глобальные архитектуры и шаблоны, высокоуровневые модели данных и концепты, попытки охватить всё и вся. Формируется шорт лист из языков и фреймворков, в рамках которых идет вся последующая разработка. Все «только на Java» или «только на C#» или… (впишите на свое усмотрение).
Несомненно, это является отражением предыдущего проектного опыта, лучших мировых практик, готовности подхватить новые запросы бизнеса и в общем случае такой подход оправдан. Но в каждом частном случае подобный глобализм на этапе взлета продукта, в тот момент, когда многое еще находится в состоянии неопределенности, может просто погрести под собой начинание и превратить проект в очередную неудачу. Можно ли что-то изменить, упростить и улучшить не теряя при этом в качестве?
Оказывается что это вполне возможно за счет объединения классической разработки ПО с инструментами и подходами data science (далее просто DS). Как этого можно достичь — разберем по шагам.

Материал является продолжением серии предыдущих публикаций.

Можно выделить ряд алгоритмов, которые являются базовыми и лежат в основе практически каждой строчки программ, написанных на языках высокого уровня. Хорошо иметь под руками классический многотомный труд Дональда Кнута "The Art of Computer Programming", там детально разобраны многие базовые алгоритмы. Но прочесть и усвоить все — задача, требующая много усилий и времени, которая должна как-то быть мотивирована.

Многие могут предположить, что нюансы необходимо было знать 50 лет назад, а сейчас можно пользоваться готовыми пакетами и функциями и не погружаться в детали. Однако, это далеко не так. Равно как никто не отменял важность понимания представления методов хранения данных в памяти и их обработки в процессоре.

Далее разберем нюансы на примере функций сортировки. Сортировка и поиск используются максимально часто во всех манипуляциях с данными. Экономия нескольких миллисекунд на операции может приводить к суммарному сокращению часов расчета на значительных данных.

Является продолжением серии предыдущих публикаций.

В ходе обсуждений возникла «маленькая» задачка — построить динамику структуры кредитного портфеля (динамика кредитной карты, например). Есть важная специфика — необходимо применять метод FIFO для погашения займов. Т.е. при погашении первыми должны гаситься самые ранние займы. Это накладывает определенные требования на расчет статуса каждого отдельного займа и определения его даты погашения. Задачу решаем честно.

Рассматриваем как олимпиадную задачу. Никаких «кровавых энерпрайзов с корпоративными архитекторами» и педалинга кода, подход исключительно «сначала подумать». Не более одного экрана кода на прототип и никаких циклов (закладные для производительности и читаемости). Ниже приведен код на R с прототипом подхода.

Является продолжением серии предыдущих публикаций.

Проблематика

Когда говорят про отчеты к данным (неважно, какая тема) все хотят гибкие дашборды, МНОГО дашбордов, играют конкурсы про BI, выдумывают разные сложные требования и кейсы, отсматривают массу вендоров и решений, разбиваются на непримиримые лагеря и на 100% уверены, что это то, без чего жизнь на работе тяжела, уныла и печальна.

Так ли это? По описанию очень сомнительно (похоже на серебряную пулю), а практика дает подтверждение «отнюдь не так».

Является продолжением серии предыдущих публикаций.

В маркетинге очень популярен когортный анализ. Его популярность вызвана, скорее всего, легкостью алгоритма и вычислений. Никаких серьезных математических концепций в основе нет, элементарная математика, выполняемая в excel. С точки зрения получения инсайтов гораздо интереснее анализ дожития.

Тем не менее, считаем, что есть такая задача и ее надо решить. Искать какие-либо пакеты и готовые функции неинтересно — математика проста, параметров настройки масса. Ниже возможный пример реализации (без особой фиксации на скорость исполнения), всего кода на пару десятков строк.

Является продолжением серии предыдущих публикаций.

Даты и время являются весьма непростыми объектами:

• месяцы содержат различное число дней;
• года бывают високосными и нет;
• существуют различные временнЫе зоны;
• часы, минуты, дни используют различные системы счисления;
• и многие другие нюансы.

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

Совсем краткое резюме для смартфоночиталей: на больших объемах данных используем только POSIXct с дробными долями секунд. Будет хорошо, понятно, быстро.

Является продолжением серии предыдущих публикаций.