Даже если человек использовал нейронки, то он всё равно должен понимать код, который они выдают.
То есть надо проверять именно понимание логики и делается это просто - даете тестовое задание, его выполняют. Дальше вы созваниваетесь на 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
Даже если человек использовал нейронки, то он всё равно должен понимать код, который они выдают.
То есть надо проверять именно понимание логики и делается это просто - даете тестовое задание, его выполняют. Дальше вы созваниваетесь на 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. Однако хорошие разработчики (и их менеджеры) выделяют время на рефакторинг, чтобы привести текущую архитектуру приложения в более-менее нормальный вид, сохранив при этом текущий требуемый функционал. С приходом новых требований цикл повторяется заново, и мы пишем новые костыли.
Что касается света — во-первых в самой статье есть ссылки, на множество паттернов, а во-вторых на эту тему выпущено достаточно много книг, многие переведены на русский. В качестве примера можно назвать