Проблема в том, что ваш перевод сделан в лоб и не скорректирован под русский. Пример.
Потому что это невероятно сложно.
Это сложно сделать.
У вас в 2 абзацах повторяется одна и та же мысль, что странно выглядит. В оригинале так же, но фраза "Это сложно сделать" - ссылка на другую статью, поэтому повторение имеет смысл. Ну и куча других мест, где формально перевод верный, но с точки зрения языка - криво. Прогоняйте хотя бы через редактор Яндекса (а лучше корректора)
Хотелось бы больше технических деталей, сейчас много вопросов.
Miner, Cleaner, Validator - какие-то самописные решения или готовые продукты? Почему решили именно так?
Так и не понял архитектуру DWH. Сначала пишите что у вас MS SQL и Clickhouse, потом внезапно PostgreSQL с расширением Citus (почему не Clickhouse например), а потом отдельно Postgres? Почему так сильно разнесли данные, а не храните в одном DWH?
Что используете для ETL/ELT? Как выбирали?
Какое BI решение как интерфейс для пользователя? Судя по слову DAX предполагаю что PowerBI?
Даже если человек использовал нейронки, то он всё равно должен понимать код, который они выдают.
То есть надо проверять именно понимание логики и делается это просто - даете тестовое задание, его выполняют. Дальше вы созваниваетесь на 10 минут и спрашиваете, как надо доработать код, чтобы он выполнял какой-то новый функционал. Даже не нужно просить его кодить, просто словами описать решение.
Если человек понимает, то он сможет сразу ответить, если нет - то нет.
Self-service — палка о двух концах. С одной стороны да, пользователи начинают делать дашборды вручную, это быстро и удобно. С другой — как только эти отчеты выходят за пределы подразделения у них перестают сходится цифры. У отдела продаж одна сумма продаж, у финансов вторая, у маркетинга — третья.
У Яндекса есть хорошее видео о том, что идеи продукта стоят минус один миллион рублей. Потому что мало придумать идею, надо её реализовать. А для it продукта это где-то 10 итераций, по 100 тыс. каждая.
Коллега говорит вам о том, что у Excel много примеров использования, которая ваша программа не закрывает. Например, как универсальный инструмент обмена данными/моделями/отчетами и т.д. как внутри организации, так и за её пределами. А вы позиционируете его именно как замену Excel и прочих электронных таблиц.
Возможно вам стоит подумать над тем, чтобы продвигать продукт именно как инструмент расчетов/моделирования данных, который применим в таких-то ситуациях. И в этих ситуациях он круче Excel потому что А, Б, В.
Очень интересная тема, но у вас в одной статье смешались конелюди — сначала про process mining вообще, потом (внезапно!) про арбузы и обработку данных, про действия учеников и только в последней части 3 строчки кода из библиотеки.
Лучше разберите один пример process mining с начала и до конца, от постановки задачи до выводов. Так будет понятнее и полезнее.
Пожалуйста, никогда не используйте логарифмические шкалы в сравнениях, они очень плохо считываются. Например в первом графике из-за этого кажется, будто разница всего в 2 раза, хотя по тексту видно, что результаты отличаются на порядки.
Работаю с Tableau 9 лет, с выводами согласен и нет )
п.1 Сильно зависит от сложности вычислений, там много факторов влияет. Для экстракта можно достичь нормальной скорости на объемах до 300 млн. строк, если вычисления оптимизированы, дальше уже нужно с внешними БД работать.
По п.2 — на самом деле фильтры передавать можно. 3 варианта навскидку
1. Использовать blending — тогда можно одно поле для фильтрации нескольких источников, на каждом строить свой дашборд, можно даже в рамках одной книги.
2. С помощью Filter Action в лашборде можно передавать значения из одного источника в другой
3. Можно фильтровать дашборды в другой с помощью URL Action
п.3 Не знаю, в какой версии вы работаете, но с версии 2019.2 можно динамические передавать в параметр значения из любого графика с помощью Parameter action.
п.4 С кубами у Табло вообще сложные отношения ) В идеале надо строить звезду с нужным набором показателей, она лучше всего работает с т.з. скорости.
Речь идёт про все антивирусные компании в мире. В основном червь был распространён в Иране (58% хостов), но при этом так или иначе встречался во многих странах. В конце текста есть ссылка на отчет Symantec с подробным описанием.
P.S. Не знаю наверняка, на едва ли у Ирана есть свои компании — разработчики антивирусов. Скорее всего они использовали ПО известных компаний.
Как минимум то, что программа делала всё вышеперечисленное (а ещё захватывала компьютеры и размножалась по сети и через USB) в течение года и за всё это время никто её деятельность не обнаружил. Ни одна антивирусная компания.
Универсальной теории разработки всего, к сожалению не придумали. Как минимум, потому что теория основывается на уже существующих наработках, а надо писать новые приложения, в новых условиях и с новыми требованиями.
Если синтезировать мысль автором на тему разработки (как я её понимаю) у разработки ПО должно быть 2 фазы — фаза набора функционала и фаза рефакторинга. Во время фазы набора функционала мы исполняем новые хотелки заказчика. Они всегда новые, неожиданные и даются с минимальным пониманием того, как устроена конкретно ваша программа. Поэтому их реализация почти всегда ломает структуру и логику нашего ПО и вставляем костыли и хаки, чтобы оно заработало. Какое-то время ПО выдержит такое издевательство, потому что оно soft. Однако хорошие разработчики (и их менеджеры) выделяют время на рефакторинг, чтобы привести текущую архитектуру приложения в более-менее нормальный вид, сохранив при этом текущий требуемый функционал. С приходом новых требований цикл повторяется заново, и мы пишем новые костыли.
Что касается света — во-первых в самой статье есть ссылки, на множество паттернов, а во-вторых на эту тему выпущено достаточно много книг, многие переведены на русский. В качестве примера можно назвать
Working Effectively with Legacy Code, Michael Feathers
Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma и другие
Refactoring: Improving the Design of Existing Code и Patterns of Enterprise Application Architecture, Martin Fowler
Code Complete: A Practical Handbook of Software Construction, Steve McConnell
Проблема в том, что ваш перевод сделан в лоб и не скорректирован под русский. Пример.
Потому что это невероятно сложно.
Это сложно сделать.
У вас в 2 абзацах повторяется одна и та же мысль, что странно выглядит. В оригинале так же, но фраза "Это сложно сделать" - ссылка на другую статью, поэтому повторение имеет смысл. Ну и куча других мест, где формально перевод верный, но с точки зрения языка - криво. Прогоняйте хотя бы через редактор Яндекса (а лучше корректора)
Хотелось бы больше технических деталей, сейчас много вопросов.
Miner, Cleaner, Validator - какие-то самописные решения или готовые продукты? Почему решили именно так?
Так и не понял архитектуру DWH. Сначала пишите что у вас MS SQL и Clickhouse, потом внезапно PostgreSQL с расширением Citus (почему не Clickhouse например), а потом отдельно Postgres? Почему так сильно разнесли данные, а не храните в одном DWH?
Что используете для ETL/ELT? Как выбирали?
Какое BI решение как интерфейс для пользователя? Судя по слову DAX предполагаю что PowerBI?
Даже если человек использовал нейронки, то он всё равно должен понимать код, который они выдают.
То есть надо проверять именно понимание логики и делается это просто - даете тестовое задание, его выполняют. Дальше вы созваниваетесь на 10 минут и спрашиваете, как надо доработать код, чтобы он выполнял какой-то новый функционал. Даже не нужно просить его кодить, просто словами описать решение.
Если человек понимает, то он сможет сразу ответить, если нет - то нет.
Было бы интересно про такой обзор тоже прочитать
Смотрели ли открытые решения? Типа Datahub?
А можно взять n8n и развернуть всё у себя...
По сути хорошая вводная статья, но глаз очень сильно режет слово "джобы" в каждом втором предложении ) Может всё таки назвать их задачами?
Возможно вам стоит подумать над тем, чтобы продвигать продукт именно как инструмент расчетов/моделирования данных, который применим в таких-то ситуациях. И в этих ситуациях он круче Excel потому что А, Б, В.
Лучше разберите один пример process mining с начала и до конца, от постановки задачи до выводов. Так будет понятнее и полезнее.
п.1 Сильно зависит от сложности вычислений, там много факторов влияет. Для экстракта можно достичь нормальной скорости на объемах до 300 млн. строк, если вычисления оптимизированы, дальше уже нужно с внешними БД работать.
По п.2 — на самом деле фильтры передавать можно. 3 варианта навскидку
1. Использовать blending — тогда можно одно поле для фильтрации нескольких источников, на каждом строить свой дашборд, можно даже в рамках одной книги.
2. С помощью Filter Action в лашборде можно передавать значения из одного источника в другой
3. Можно фильтровать дашборды в другой с помощью URL Action
п.3 Не знаю, в какой версии вы работаете, но с версии 2019.2 можно динамические передавать в параметр значения из любого графика с помощью Parameter action.
п.4 С кубами у Табло вообще сложные отношения ) В идеале надо строить звезду с нужным набором показателей, она лучше всего работает с т.з. скорости.
P.S. Не знаю наверняка, на едва ли у Ирана есть свои компании — разработчики антивирусов. Скорее всего они использовали ПО известных компаний.
Если синтезировать мысль автором на тему разработки (как я её понимаю) у разработки ПО должно быть 2 фазы — фаза набора функционала и фаза рефакторинга. Во время фазы набора функционала мы исполняем новые хотелки заказчика. Они всегда новые, неожиданные и даются с минимальным пониманием того, как устроена конкретно ваша программа. Поэтому их реализация почти всегда ломает структуру и логику нашего ПО и вставляем костыли и хаки, чтобы оно заработало. Какое-то время ПО выдержит такое издевательство, потому что оно soft. Однако хорошие разработчики (и их менеджеры) выделяют время на рефакторинг, чтобы привести текущую архитектуру приложения в более-менее нормальный вид, сохранив при этом текущий требуемый функционал. С приходом новых требований цикл повторяется заново, и мы пишем новые костыли.
Что касается света — во-первых в самой статье есть ссылки, на множество паттернов, а во-вторых на эту тему выпущено достаточно много книг, многие переведены на русский. В качестве примера можно назвать