Причём переписку-то прочитала компания-заказчик решения. И зачем-то передала её компании-разработчику решения, чтобы те могли её вывесить на Хабре. Очень интересно.
2. Важные поля по умолчанию замазываются, поэтому информация о картах и т.п. недоступна даже BurgerKing.
а шифруется и замазывается в какой момент? есть бургеркинги, есть сервисы аналитики, а есть МПС Visa и MC, у которых очень жёсткие требования к тому, как платёжная информация может обрабатываться, храниться и т.п. вплоть до требования получения PCI DSS. и что-то я очень сомневаюсь, что они будут довольны даже самой возможностью того, что какой-то сторонний сервис может собрать данные карт (даже потенциально).
В исходном комментарии вы ставили вопрос о пользе ФП и его изъянах, а не конкретно F#. Я на это и ответил.
В комментариях дальше вы пытаетесь подтвердить своё мнение об «общем» своим опытом работы с «частным» — F#. «ФП — плохо, потому что я работал с F# и мне не понравилось». Как-то это не совсем корректно, не находите?
Давайте я приведу такой же частный пример с Erlang/Elixir'ом, который очень даже фп, и на котором написаны и пишутся тонны софта с высочайшими требованиями как к производительности, так и к надёжности. Но я не говорю, что этот пример доказывает величие и непогрешимость ФП.
И тем не менее:
— Иммутабельность (как и многие другие ФП-штуки) проникает в кучи языков. И прежде всего из-за того, что она позволяет сделать код надёжнее и предупредить ошибки. Их эффективность во многом обусловлена тем, насколько та или иная машина исполнения/компилятор умеет с ними работать.
— Когнитивная нагрузка опять же неоднозначна и на самом деле повторяет lurning curve типичного ФП-языка. Понять, легко читать и применять какие-нибудь «лямбды», «частичное применение», «свёртки и их производные map, filter и прочие», «композиция функций/pipe-оператор» — элементарно. И это, имхо, значительно облагораживает код по сравнению с традиционными альтернативами. Спроcите любого Android-разработчика, что он думает о retrolambda и ФП-фичах Java 8 и Kotlin'а — уверен, он вам скажет, что это глоток свежего воздуха по сравнению с тем boilerplate-ом, который навязывался до этого. Если же переходить на уровень выше, к типичным ФП-абстракциям, типа монад, функторов, стрелок, линз и дальше, то да, нужно потратить время, чтобы научиться распознавать их в типичных задачах программирования. Но это не сложнее, чем научиться распознавать паттерны GoF — просто немного иначе (и прекрасно дополняет друг друга). Более «алгебраично!» чтоли…
— Тут бы более конкретные примеры языков. Ну и не стоит забывать, что чистые функции значительно проще тестировать, а значит и количество ошибок будет меньше. Но да, определённые сложности есть.
Ну, и оглянитесь вокруг. Если даже C++ втягивает в себя концепции ФП, то это что-то но значит. Как минимум посидеть разобраться в этом стоит. Да и проекты, выполненные чисто на ФП-языках и где сработал принцип «наиболее подходящий инструмент под задачу» — есть и их всё больше.
А неужели и правда ни для python'а, ни для других языков, удобных для DS, нет ничего похожего на shiny? Я не копал в эту сторону, но ведь это крайне удобная вещь — странно, что то же сообщество python'а, которое любит перенимать идеи из R, не переняло и это…
а проекты, надо полагать, будут во благо продуктов сбера? ну то есть много бесплатного труда) или всё же продукты будут оторваны от бизнеса того, кто оплачивает банкет?
Интересно получается. Эффективность блокировки Жаров оценил в оттоке рекламы и пользователей, т.е. в финансовом ущербе, нанесённом конкретным каналам пользователей и конкретной компании, представляющей Телеграм. Но при этом ведь целью было якобы «обеспечение безопасности граждан, защита их данных и борьба с терроризмом». Странные метрики для заявленной цели, если подходить чисто формально.
Нет, многие подсети по-прежнему заблокированы. Изначально мой дроплет с впном был во Франкфурте и попал в заблоченную подсеть. Попробовал floating ip, но все выделяемые ip тоже были заблочены. Перенёс дроплет в Нью-Йорк — аналогично. Попробовал Лондон — повезло, до туда щупальца РКН ещё не достали.
«Выпечка это код». Уже одно это сравнение ломает все остальные метафоры) «Выпечка» это «продукт» или «услуга», но никак не код. Если только автор не лабораторные работы студентам делает.
Чтобы что-то советовать, нужно самому хорошо в этом разбираться) Я могу лишь сказать, какие источники мне понравились:
— курс лекций Воронцова по Машинному обучению www.youtube.com/playlist?list=PLJOzdkh8T5kp99tGTEFjH_b9zqEQiiBtC
— канал Основы Анализа Данных www.youtube.com/channel/UCLk-Oih8VlqF-StidijTUnw
— если хороший английский (а я не знаю, как без него можно заниматься ML), то канал Den Lambert с его лекциями по эконометрике www.youtube.com/channel/UC3tFZR3eL1bDY8CqZDOQh-w
— опять же, если хороший английский, то лекции MIT OpenCourseWare по всему тому, что забылось со времён вуза: линал, матан, матстат.
— с книгами сложнее. очень много книг сделаны по принципу «пробежимся по верхам с примерами на R/Python». есть неплохие, они позволяют быстро познакомиться с библиотеками. но если хочется что-то более фундаментальное, то это либо огромные талмуды про один конкретный подход (типа 1000 чтраниц про Deep Learning или 1000 страниц про регрессию), либо очень абстрактные книги (как указанная выше ESL), либо опять же всё по верхам. Мне понравилась книжка Питера Флаха «Machine Learning: The Art and Science of Algorithms That Make Sense of Data». Есть на русском от ДМК-Пресс.
И да, ниже правильно упомянули сообщество ODS, у которого есть слак канал с кучей информации и отзывчивыми пользователями. Туда же сообщество machinelearning.ru.
Вот бич любой хайповой технологии — гигантский разрыв между уровнем знаний от «вводных статей for beginners» и уровнем знаний, необходимых для успешного и эффективного применения технологии в реальных задачах.
Лет 10 назад можно было купить книжку PHP5+MySQL+JQuery, склеить куски плохого и непонятного кода в сайт и даже продавать кому-то эти навыки. А теперь всё то же самое, но про ML, Deep Learning и прочий Data Science. Вот только, когда хочешь уйти от уровня «установили питон, импортнули sklearn, обучили модель, посмотрели точность», то открывается бездна информации. Т.е. сегодня ты в эйфории от точности своего классификатора предложений, а завтра ты по несколько раз перечитываешь каждый абзац какой-нибудь каноничной книжки, типа The Elements of Statistical Learning, изо всех сил вспоминая все прогулянные пары матана, линала и матстата и силясь уложить этот фундамент в своей голове. И разрыв настолько огромен, что писать про простоту ML — это злостное введение в заблуждение.
Что, конечно, не отменяет того факта, что с помощью ML изредка можно с минимумом усилий всё-таки получить ограничено работоспособную функциональность, и она даже может иметь какую-то ценность.
ИМХО, конечно.
Минимальные вещи делаются в минимум шагов — через меню vscode поставить расширение python (которое вам предложится автоматически при написании скрипта на питоне), отдельно поставить lint'ер одной командой (например, sudo apt install pylint или pip install pylint или, в случае с сабжем, conda install -c anaconda pylint), выбрать установленный lint'er в vscode, настроить task'и для сборки/запуска/тестов по вкусу.
Для обычного написания скриптов этого более чем достаточно.
«В условии» сказано, что колпаки могут быть разного цвета (и это известно мудрецам), но конкретно в этом случае были выбраны колпаки одинакового белого цвета. Это никакое не дополнительное ограничение, а часть условия, что и делает задачу решаемой.
Ещё иногда важным отличием оказывается то, что под R больше узкоспециализированных пакетов, которые сложно найти не только под Python, но и под другие языки. Зачастую это просто обвязка вокруг проверенных временем C/C++-библиотек.
Например, однажды надо было придумать алгоритм, завязанный на распределении пользователей по территории, что подразумевало использование равномерного разбиения нашего голубого шарика на ячейки. Нашёлся хороший проект DGGRID, который берёт на себя всю математику. И именно для R тут же нашёлся пакет, который даёт интерфейс к DGGRID + визуализацию через gdal и shapefile'ы. То есть переход между шагами «найти инструмент» и «проверить алгоритм» был максимально плавным и незаметным: 10 минут на чтение сайта DGGRID, 5 минут на поиск пакета для R, ещё 10 минут на чтение доки к нему, и вот я уже гружу тестовый датасет и смотрю на красивую визуализацию карты.
Ну, а про кучи различных статистических узкоспециализированных или малопопулярных методов, реализованных в пакетах к R (например, equipercentile equating), я уж молчу. Тут скорее сказывается то, что R более привычен тем, чей фокус смещен от программирования в науку. Поэтому такие пакеты в CRAN появляются быстрее любого другого языка. Почему так вышло — не знаю.
А вот со всем, что касается собственно программирования и написания не просто скриптов, а реально работающих и поддерживаемых программ, у R дела обстоят гораздо скромнее. Во многом тут сказывается куча legacy и незаточенность под современные нужды. Также есть особенности самого языка, которые могут быть непривычны тем, кто использует более традиционные языки — им просто может быть сложно понимать ваш код. Советую сразу после знакомства с основами идти читать про пакеты от tidyverse, например. Они очень приятно преображают R и делают написание кода на нём гораздо приятнее. И, к сожалению, именно про написание не скриптов, а реальных программ и организации их, про язык R как язык программирования книг я не встречал.
Уже 5+ лет занимаюсь работой аналитика. Поработал с разработчиками от разных «полюсов»: как с теми, которые будут докапываться до каждой фразы, причём не стесняясь в выражениях и зачастую с большой долей высокомерия, так и с теми, которым ТЗ не нужен — достаточно постановки и времени на обсуждение.
Особая острота к работе добавляется, когда у тебя есть определённые компетенции в разработке, особенно в используемом в работе стеке. Как экстремальная форма ситуации — когда разработчики настолько плохи, что даже ты со своими «домашними проектами» их превосходишь в их области (при аутсорсе встречались такие). С одной стороны это огромный плюс — ты способен оценить сложность реализации того, что ты описываешь, ещё до оценки разработчиками, ты знаешь какие вещи реализуемы, какие сложнореализуемы, а какие просто невозможны, ты знаешь, где что-то может пойти не так и где требуется уточнение поведения. С другой стороны, ты «всего лишь» аналитик — большинство разработчиков встретит вторжение в сферу своей ответственности от тебя со скепсисом (осторожностью/враждебностью/возмущением). В итоге приходится постоянно лавировать между «тем, что ты знаешь» и «тем, что от тебя ждут», зарабатывать доверие разработчиков и бороться с внутренним конфликтом «брошу всё уйду в разработчики». К сожалению, это очень распространённая проблема разработчиков — недоверие к опыту не-разработчиков. Впрочем, объяснимая — аналитиков, которые пишут совершенно поверхностные ТЗ очень много.
Для себя я решил, что идеальная работа — это работа с командой, которая прежде всего всегда готова к обсуждению и готова к свободе своих действий в обмен на риск что-то выбросить и переписать. Можно называть это agile, можно lean, можно даже «пиши код бл*ть» — в любом случае нужно принять возникновение ошибок как что-то неотвратимое и постараться сэкономить время на попытках их предотвратить, потратив это время на создание функциональности. Ну, и мотивация всех на конечный результат, а не закрытие тасков в трекере. Пусть даже внутренняя.
Была задача добавить поведенческую аналитику в приложение с больше чем 100к установок в каждом из маркетов и DAU в районе 1700-2200.
Минусы, которые заставили отказаться от идеи использования FA (на момент до IO'17):
— упомянутая кастрированность дашборда и всех дефолтных отчётов в плане работы с кастомными событиями и полями
— более того, никаких других вариантов докопаться до своих кастомных событий и их полей, кроме как через BigQuery просто нет
— но BigQuery платный
— а если не BigQuery, то будь ты хоть трижды гуру питона/R и мастер визуализации данных, всё равно — сырые данные только через BigQuery
— упомянутые воронки только «открытые». То есть ты не сможешь ответить на простой вопрос «вот у меня функция на этом экране, но к нему можно прийти 3-мя разными способами, и интересно, какой из них наиболее популярный и какой максимизирует конверсию», потому что открытые воронки сработают только в случае фиксированного и однозначного пути по экранам. И это очень сильно ограничивает полезность этого инструмента, особенно если использовать его для анализа поведения пользователей в приложении. В том же GA есть выбор между закрытой и открытой воронкой.
Но даже это лучше, чем Fabric с его Answers и полной невозможностью хоть как-то оперировать своими данными за пределами «видения» создателей Fabric. О выгрузке данных и попытках докопаться до конкретного пользователя вообще молчу — весь Fabric (в том числе Crashlytics) этим страдает. Посмотрим, к чему приведёт поглощение Fabric'а гуглом…
И только Flurry удовлетворил всем потребностям. Правда тормознутый и иногда лежит. Но чёрт побери… он позволяет мне выгрузить все события всех пользователей за нужную дату и даже передавать пользовательский идентификатор. То есть я вижу поведение пользователей, начиная с масштаба конкретной сессии конкретного человека и заканчивая срезами по всем событиям и всем моим кастомным параметрам.
Может, конечно, я где-то не прав и не вижу проблем в выбранном инструменте/упускаю из виду плюсы конкурентов или вообще что-то делаю не так)
а шифруется и замазывается в какой момент? есть бургеркинги, есть сервисы аналитики, а есть МПС Visa и MC, у которых очень жёсткие требования к тому, как платёжная информация может обрабатываться, храниться и т.п. вплоть до требования получения PCI DSS. и что-то я очень сомневаюсь, что они будут довольны даже самой возможностью того, что какой-то сторонний сервис может собрать данные карт (даже потенциально).
Посмотрел на календарь… А вы вовремя)
В комментариях дальше вы пытаетесь подтвердить своё мнение об «общем» своим опытом работы с «частным» — F#. «ФП — плохо, потому что я работал с F# и мне не понравилось». Как-то это не совсем корректно, не находите?
Давайте я приведу такой же частный пример с Erlang/Elixir'ом, который очень даже фп, и на котором написаны и пишутся тонны софта с высочайшими требованиями как к производительности, так и к надёжности. Но я не говорю, что этот пример доказывает величие и непогрешимость ФП.
— Иммутабельность (как и многие другие ФП-штуки) проникает в кучи языков. И прежде всего из-за того, что она позволяет сделать код надёжнее и предупредить ошибки. Их эффективность во многом обусловлена тем, насколько та или иная машина исполнения/компилятор умеет с ними работать.
— Когнитивная нагрузка опять же неоднозначна и на самом деле повторяет lurning curve типичного ФП-языка. Понять, легко читать и применять какие-нибудь «лямбды», «частичное применение», «свёртки и их производные map, filter и прочие», «композиция функций/pipe-оператор» — элементарно. И это, имхо, значительно облагораживает код по сравнению с традиционными альтернативами. Спроcите любого Android-разработчика, что он думает о retrolambda и ФП-фичах Java 8 и Kotlin'а — уверен, он вам скажет, что это глоток свежего воздуха по сравнению с тем boilerplate-ом, который навязывался до этого. Если же переходить на уровень выше, к типичным ФП-абстракциям, типа монад, функторов, стрелок, линз и дальше, то да, нужно потратить время, чтобы научиться распознавать их в типичных задачах программирования. Но это не сложнее, чем научиться распознавать паттерны GoF — просто немного иначе (и прекрасно дополняет друг друга). Более «алгебраично!» чтоли…
— Тут бы более конкретные примеры языков. Ну и не стоит забывать, что чистые функции значительно проще тестировать, а значит и количество ошибок будет меньше. Но да, определённые сложности есть.
Ну, и оглянитесь вокруг. Если даже C++ втягивает в себя концепции ФП, то это что-то но значит. Как минимум посидеть разобраться в этом стоит. Да и проекты, выполненные чисто на ФП-языках и где сработал принцип «наиболее подходящий инструмент под задачу» — есть и их всё больше.
— курс лекций Воронцова по Машинному обучению www.youtube.com/playlist?list=PLJOzdkh8T5kp99tGTEFjH_b9zqEQiiBtC
— канал Основы Анализа Данных www.youtube.com/channel/UCLk-Oih8VlqF-StidijTUnw
— если хороший английский (а я не знаю, как без него можно заниматься ML), то канал Den Lambert с его лекциями по эконометрике www.youtube.com/channel/UC3tFZR3eL1bDY8CqZDOQh-w
— опять же, если хороший английский, то лекции MIT OpenCourseWare по всему тому, что забылось со времён вуза: линал, матан, матстат.
— с книгами сложнее. очень много книг сделаны по принципу «пробежимся по верхам с примерами на R/Python». есть неплохие, они позволяют быстро познакомиться с библиотеками. но если хочется что-то более фундаментальное, то это либо огромные талмуды про один конкретный подход (типа 1000 чтраниц про Deep Learning или 1000 страниц про регрессию), либо очень абстрактные книги (как указанная выше ESL), либо опять же всё по верхам. Мне понравилась книжка Питера Флаха «Machine Learning: The Art and Science of Algorithms That Make Sense of Data». Есть на русском от ДМК-Пресс.
И да, ниже правильно упомянули сообщество ODS, у которого есть слак канал с кучей информации и отзывчивыми пользователями. Туда же сообщество machinelearning.ru.
Лет 10 назад можно было купить книжку PHP5+MySQL+JQuery, склеить куски плохого и непонятного кода в сайт и даже продавать кому-то эти навыки. А теперь всё то же самое, но про ML, Deep Learning и прочий Data Science. Вот только, когда хочешь уйти от уровня «установили питон, импортнули sklearn, обучили модель, посмотрели точность», то открывается бездна информации. Т.е. сегодня ты в эйфории от точности своего классификатора предложений, а завтра ты по несколько раз перечитываешь каждый абзац какой-нибудь каноничной книжки, типа The Elements of Statistical Learning, изо всех сил вспоминая все прогулянные пары матана, линала и матстата и силясь уложить этот фундамент в своей голове. И разрыв настолько огромен, что писать про простоту ML — это злостное введение в заблуждение.
Что, конечно, не отменяет того факта, что с помощью ML изредка можно с минимумом усилий всё-таки получить ограничено работоспособную функциональность, и она даже может иметь какую-то ценность.
ИМХО, конечно.
Для обычного написания скриптов этого более чем достаточно.
Например, однажды надо было придумать алгоритм, завязанный на распределении пользователей по территории, что подразумевало использование равномерного разбиения нашего голубого шарика на ячейки. Нашёлся хороший проект DGGRID, который берёт на себя всю математику. И именно для R тут же нашёлся пакет, который даёт интерфейс к DGGRID + визуализацию через gdal и shapefile'ы. То есть переход между шагами «найти инструмент» и «проверить алгоритм» был максимально плавным и незаметным: 10 минут на чтение сайта DGGRID, 5 минут на поиск пакета для R, ещё 10 минут на чтение доки к нему, и вот я уже гружу тестовый датасет и смотрю на красивую визуализацию карты.
Ну, а про кучи различных статистических узкоспециализированных или малопопулярных методов, реализованных в пакетах к R (например, equipercentile equating), я уж молчу. Тут скорее сказывается то, что R более привычен тем, чей фокус смещен от программирования в науку. Поэтому такие пакеты в CRAN появляются быстрее любого другого языка. Почему так вышло — не знаю.
А вот со всем, что касается собственно программирования и написания не просто скриптов, а реально работающих и поддерживаемых программ, у R дела обстоят гораздо скромнее. Во многом тут сказывается куча legacy и незаточенность под современные нужды. Также есть особенности самого языка, которые могут быть непривычны тем, кто использует более традиционные языки — им просто может быть сложно понимать ваш код. Советую сразу после знакомства с основами идти читать про пакеты от tidyverse, например. Они очень приятно преображают R и делают написание кода на нём гораздо приятнее. И, к сожалению, именно про написание не скриптов, а реальных программ и организации их, про язык R как язык программирования книг я не встречал.
Особая острота к работе добавляется, когда у тебя есть определённые компетенции в разработке, особенно в используемом в работе стеке. Как экстремальная форма ситуации — когда разработчики настолько плохи, что даже ты со своими «домашними проектами» их превосходишь в их области (при аутсорсе встречались такие). С одной стороны это огромный плюс — ты способен оценить сложность реализации того, что ты описываешь, ещё до оценки разработчиками, ты знаешь какие вещи реализуемы, какие сложнореализуемы, а какие просто невозможны, ты знаешь, где что-то может пойти не так и где требуется уточнение поведения. С другой стороны, ты «всего лишь» аналитик — большинство разработчиков встретит вторжение в сферу своей ответственности от тебя со скепсисом (осторожностью/враждебностью/возмущением). В итоге приходится постоянно лавировать между «тем, что ты знаешь» и «тем, что от тебя ждут», зарабатывать доверие разработчиков и бороться с внутренним конфликтом «брошу всё уйду в разработчики». К сожалению, это очень распространённая проблема разработчиков — недоверие к опыту не-разработчиков. Впрочем, объяснимая — аналитиков, которые пишут совершенно поверхностные ТЗ очень много.
Для себя я решил, что идеальная работа — это работа с командой, которая прежде всего всегда готова к обсуждению и готова к свободе своих действий в обмен на риск что-то выбросить и переписать. Можно называть это agile, можно lean, можно даже «пиши код бл*ть» — в любом случае нужно принять возникновение ошибок как что-то неотвратимое и постараться сэкономить время на попытках их предотвратить, потратив это время на создание функциональности. Ну, и мотивация всех на конечный результат, а не закрытие тасков в трекере. Пусть даже внутренняя.
Минусы, которые заставили отказаться от идеи использования FA (на момент до IO'17):
— упомянутая кастрированность дашборда и всех дефолтных отчётов в плане работы с кастомными событиями и полями
— более того, никаких других вариантов докопаться до своих кастомных событий и их полей, кроме как через BigQuery просто нет
— но BigQuery платный
— а если не BigQuery, то будь ты хоть трижды гуру питона/R и мастер визуализации данных, всё равно — сырые данные только через BigQuery
— упомянутые воронки только «открытые». То есть ты не сможешь ответить на простой вопрос «вот у меня функция на этом экране, но к нему можно прийти 3-мя разными способами, и интересно, какой из них наиболее популярный и какой максимизирует конверсию», потому что открытые воронки сработают только в случае фиксированного и однозначного пути по экранам. И это очень сильно ограничивает полезность этого инструмента, особенно если использовать его для анализа поведения пользователей в приложении. В том же GA есть выбор между закрытой и открытой воронкой.
Но даже это лучше, чем Fabric с его Answers и полной невозможностью хоть как-то оперировать своими данными за пределами «видения» создателей Fabric. О выгрузке данных и попытках докопаться до конкретного пользователя вообще молчу — весь Fabric (в том числе Crashlytics) этим страдает. Посмотрим, к чему приведёт поглощение Fabric'а гуглом…
И только Flurry удовлетворил всем потребностям. Правда тормознутый и иногда лежит. Но чёрт побери… он позволяет мне выгрузить все события всех пользователей за нужную дату и даже передавать пользовательский идентификатор. То есть я вижу поведение пользователей, начиная с масштаба конкретной сессии конкретного человека и заканчивая срезами по всем событиям и всем моим кастомным параметрам.
Может, конечно, я где-то не прав и не вижу проблем в выбранном инструменте/упускаю из виду плюсы конкурентов или вообще что-то делаю не так)