Это именно про генерацию отчетов. Большинство коробочных решений сейчас предлагают какую-то интерактивность и визуальную аналитику, но разговор именно о представлении данных. Не о прогнозировании, не об анализе "а что если..." и т.д. и т.п.. По мнению Соломона Негаша и Пола Грея, бизнес-аналитику (BI) можно определить как системы, сочетающие в себе: Сбор данных, Хранилище данных, Управление знаниями. В публикации речь идет только о предоставлении данных пользователю, а не о чем-то ещё.
Ну и, к слову, один из смыслов статьи был показать, что есть tableau/power bi/ qlik и т.д., а есть язык R и ему подобный. Оба направления анализом данных занимаются, но немного по-разному. Плюс есть переходные вещи типа DevExpress - это и не "tableau/power bi/ qlik и т.д.", но и не R. Однако все эти инстременты рашают задачу отображения и анализа данных на уровне пользователя. ΒΙ тоже разный бывает, на уровне кубов в OLAP можно прогнозированием и анализом заниматься, но это сильно будет отличаться от "tableau/power bi/ qlik и т.д.". Там свой язык и множество проблем с иерархичными струтктурами.
Я же написал выше, что это то, что хотели сотрудники, после того как им поставили систему отчетности. Люди работали в Excel им поставили ΒΙ систему, а они все равно хотят Excel. Тут либо через колено ломать всех, либо дать им возможность дальше работать. Но опять таки, я же пишу - это то, на что они роптали. А вот идти им на встречу или нет, это уже ваш выбор. Я пошел им на встречу, но мог и не идти. Были и те кто ратовал за то, чтобы отучить всех от Excel.
Это все визуализация данных. Между ΒΙ и Reporting четкой границы нет (есть OLAP, но как ответ с отчетных систем - сводные таблицы, разница больше в возможностях). И речь не об условно статических отчетах в публикации. Я даже не могу вспомнить систему с чисто статическими отчетами, разве что простые выгрузки из базы. Сейчас это больше анализ данных, о чем я и написал.
"не приходит в голову красить учётные системы типа 1С и SAP в корпоративные цвета" - это ваш опыт, а мне приходилось и переверстывать тоже приходилось. Более того, системы типа "инструмент" позволяют это сделать с гораздо меньшими усилиями.
Минут 10 искал аналог слову "функционал", не нашёл. Можно заменить "набор различных функций связанных с отображением данных". Под функционалом в приведенном абзаце я понимаю - редакторы отчетов, управление доступом, подсистема взаимодействие с пользователем. Т.е. отчет надо кем-то и где-то создать и кто-то должен иметь возможность его запустить, вот эти вот сущности в "коробочных решениях" уже готовые идут "в корбке". Вам не надо искать и устанавливать что-то ещё, чтобы система работала. Приобрели продукт, установили и запустили, в нём есть все необходимое для создания отчетов.
"С простыми просто, со сложными сложно" - ну так и есть, просто нужно понимать, что если у вас простые требования, то лучше взять что-то попроще, а если сложные, то посложнее. Очень большой разброс в "коробочках", какие-то поставил и интуитивно понятно как с ними работать, а вот с какими-то приходится попотеть. К сожалению, сейчас все больше сложных и меньше простых.
Настроить "под себя" - у вас есть, например, корпоративный портал (сайт для взаимодействия внутри компании) и есть какой-то корпоративный стиль (дизайн страничек, отчетов и т.п.) и вот вы приобретаете "коробочный" продукт. У него свой стиль (дизайн) и у него свой сервер (в некоторых случаях), на котором он развернут и возможности сделать так, чтобы он выглядел и работал в соответствии с корпоративными правилами у "коробочек" ограниченны. Например, у вас есть текст на странице HTML и вы прямо в этот текст хотите встроить отчеты, это не всегда получится сделать красиво, как вариант наделать картинки с отчетов, но это надо делать каждый раз вручную и картинки не интерактивны (это то что мне в голову пришло, как пример). Рабочий пример был такой - был портал на Sharepoint в него можно встроить Power BI, т.к. это продукты Microsoft, но встроить туда SAP BO или QlikView уже не так просто, т.к. это не продукты Microsoft, а некоторые отчеты в Power BI работают медленно, а в QlikView быстро, но у QlikView жесткие требования к оперативной памяти и начинается пазл.
Давно это было. Помню, что вместо RestAPI заказчик захотел использовать нечто свое для ΙοΤ. Мы использовали routing-controllers и её удалось переделать под новые требования, а вот Nest не хотел сдаваться. Вроде бы так же были проблемы с тестами и сообщениями об ошибках. Думаю, скорее проект был болью, а не NestJS.
От NestJS как-то у меня сильно подгорело, в свое время :) . Но не суть, я считаю, что про DI надо отдельно рассказывать, с примерами использования в разных платформах.
Не совсем забыл. Пару намеков есть на первой и 7-ой картинке. Но сам DI это отдельная история, он присутствует в Angular, как и в Spring boot, как и много где ещё.
Выполняются все операции из JavaScript execution stack (https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide). Т.е. все что уже на исполнении должно отработать. Как я это понял (посмотрев исходники libuv) - в момент переключения между таской и микротаской, что-то может начать исполняться и вот это должно закончится. Функции, которые вызывают сallback'и имеют разное время выполнения. И если у вас, например, 2 callback'а один из которых вызовется через 1 секунду, а другой через 10, то Javascript не будет ждать 10 секунд, чтобы выполнить микротаски первого.
Думаю я не совсем корректно выразился, либо был не так понят. Под "ожидаемым поведением" я имел ввиду наличие сообщения об ошибке в тесте. Т.к. тест проверяет - будет ли выброшенно исключение в случае неверных данных. Что выводить в логи а что нет, это я думаю на вкус и цвет. В данном проекте логи выводились, как я написал выше, мне он достался уже в таком виде.
Это unit тест для клиентской части веб приложения. Который проверяет, была ли вызванна та или иная функция. Т.е. он не проверяет внутреннее сосотояние объекта. Другой тест возможно проверяет их там 558, но не этот. Воторой момент - на клиенте, по возможности, все должно работать быстро и асинхронно, т.к. мы имеем дело с событиями, которые не обязательно вызываются последовательно. Отсюда, код клиентской части чаще всего асинхронный, хотя могут быть какие-то зависимости, но конечно же при написании юнит теста это проверяется. Суть текущего теста - просто подача входных значений из массива и проверка что определенные функции внутри кода вызываются или не вызываются при этом. Я не писал этот тест изначально, о чем сказанно в публикации. Но изменение async/await на Promise в юнит тесте точно никак не влияет на логику как самого теста, так и тестируемого кода в данном конкретном случае.
345 секунд против 419 - это было на разных виртуальных машинах. Я просто версию до изменений развернул на одной виртуалке, а версию с изменениями на другой. Одна из виртуалок была довольно слабой, другая наоборот довольно сильной.
Спасибо, он нужен был для routing-controllers. К routing-controllers есть вопросы, как и аналоги. У меня был опыт работы с ними, поэтому я о них и написал. Но это "для более удобной работы", с моей точки зрения. Т.е. лучше наверное было сказать - она не обязательна и на ваше усмотрение. Работать все будет и без нее.
Я именно этот вариант и имел ввиду. Jupyter мы просто на сервере использовали, чтобы проверить как все работает, все вызовы непосредственно из пакетов Python были, т.е. не просто скрипт в Jupiter, а функция в пактете на Python внутри которой дергался R. Я подозреваю что там дергалось все из разных pods, но это чисто мое подозрение, и получалось, что вызовы должны были как-то пробрасываться между ними. Shell скорее всего девопсы настроили на такие пробросы, а библиотеки типа rpy2 они не смогли пробросить. Но это чисто мое предположение, как я и писал выше - я прсто описал то, что у нас работало и даже если у когото, кто решили бы нашим подходом воспользоваться, с этим возникли бы просблемы, я как минимум знаю что и где подкручивать.
Пробовали, я же писал про это. Локально работало, а на окружении нет. Скорее всего проблема с окружением, но я описывал то что у нас работало, чтобы достоверность соблюсти.
Это именно про генерацию отчетов. Большинство коробочных решений сейчас предлагают какую-то интерактивность и визуальную аналитику, но разговор именно о представлении данных. Не о прогнозировании, не об анализе "а что если..." и т.д. и т.п.. По мнению Соломона Негаша и Пола Грея, бизнес-аналитику (BI) можно определить как системы, сочетающие в себе: Сбор данных, Хранилище данных, Управление знаниями. В публикации речь идет только о предоставлении данных пользователю, а не о чем-то ещё.
Подойдет, как и другие "коробочные" решения. В чем смысл вопроса? Он глобально отличается от других "коробочных" продуктов?
Есть видео с картинками. Суть одна: 1С:Аналитика - это ещё одно коробочное решение со своими нюансами, но глобально та же "коробка".
Ну и, к слову, один из смыслов статьи был показать, что есть tableau/power bi/ qlik и т.д., а есть язык R и ему подобный. Оба направления анализом данных занимаются, но немного по-разному. Плюс есть переходные вещи типа DevExpress - это и не "tableau/power bi/ qlik и т.д.", но и не R. Однако все эти инстременты рашают задачу отображения и анализа данных на уровне пользователя. ΒΙ тоже разный бывает, на уровне кубов в OLAP можно прогнозированием и анализом заниматься, но это сильно будет отличаться от "tableau/power bi/ qlik и т.д.". Там свой язык и множество проблем с иерархичными струтктурами.
Я же написал выше, что это то, что хотели сотрудники, после того как им поставили систему отчетности. Люди работали в Excel им поставили ΒΙ систему, а они все равно хотят Excel. Тут либо через колено ломать всех, либо дать им возможность дальше работать. Но опять таки, я же пишу - это то, на что они роптали. А вот идти им на встречу или нет, это уже ваш выбор. Я пошел им на встречу, но мог и не идти. Были и те кто ратовал за то, чтобы отучить всех от Excel.
Это все визуализация данных. Между ΒΙ и Reporting четкой границы нет (есть OLAP, но как ответ с отчетных систем - сводные таблицы, разница больше в возможностях). И речь не об условно статических отчетах в публикации. Я даже не могу вспомнить систему с чисто статическими отчетами, разве что простые выгрузки из базы. Сейчас это больше анализ данных, о чем я и написал.
"не приходит в голову красить учётные системы типа 1С и SAP в корпоративные цвета" - это ваш опыт, а мне приходилось и переверстывать тоже приходилось. Более того, системы типа "инструмент" позволяют это сделать с гораздо меньшими усилиями.
Минут 10 искал аналог слову "функционал", не нашёл. Можно заменить "набор различных функций связанных с отображением данных". Под функционалом в приведенном абзаце я понимаю - редакторы отчетов, управление доступом, подсистема взаимодействие с пользователем. Т.е. отчет надо кем-то и где-то создать и кто-то должен иметь возможность его запустить, вот эти вот сущности в "коробочных решениях" уже готовые идут "в корбке". Вам не надо искать и устанавливать что-то ещё, чтобы система работала. Приобрели продукт, установили и запустили, в нём есть все необходимое для создания отчетов.
"С простыми просто, со сложными сложно" - ну так и есть, просто нужно понимать, что если у вас простые требования, то лучше взять что-то попроще, а если сложные, то посложнее. Очень большой разброс в "коробочках", какие-то поставил и интуитивно понятно как с ними работать, а вот с какими-то приходится попотеть. К сожалению, сейчас все больше сложных и меньше простых.
Настроить "под себя" - у вас есть, например, корпоративный портал (сайт для взаимодействия внутри компании) и есть какой-то корпоративный стиль (дизайн страничек, отчетов и т.п.) и вот вы приобретаете "коробочный" продукт. У него свой стиль (дизайн) и у него свой сервер (в некоторых случаях), на котором он развернут и возможности сделать так, чтобы он выглядел и работал в соответствии с корпоративными правилами у "коробочек" ограниченны. Например, у вас есть текст на странице HTML и вы прямо в этот текст хотите встроить отчеты, это не всегда получится сделать красиво, как вариант наделать картинки с отчетов, но это надо делать каждый раз вручную и картинки не интерактивны (это то что мне в голову пришло, как пример). Рабочий пример был такой - был портал на Sharepoint в него можно встроить Power BI, т.к. это продукты Microsoft, но встроить туда SAP BO или QlikView уже не так просто, т.к. это не продукты Microsoft, а некоторые отчеты в Power BI работают медленно, а в QlikView быстро, но у QlikView жесткие требования к оперативной памяти и начинается пазл.
Давно это было. Помню, что вместо RestAPI заказчик захотел использовать нечто свое для ΙοΤ. Мы использовали routing-controllers и её удалось переделать под новые требования, а вот Nest не хотел сдаваться. Вроде бы так же были проблемы с тестами и сообщениями об ошибках. Думаю, скорее проект был болью, а не NestJS.
От NestJS как-то у меня сильно подгорело, в свое время :) . Но не суть, я считаю, что про DI надо отдельно рассказывать, с примерами использования в разных платформах.
Не совсем забыл. Пару намеков есть на первой и 7-ой картинке. Но сам DI это отдельная история, он присутствует в Angular, как и в Spring boot, как и много где ещё.
Выполняются все операции из JavaScript execution stack (https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide). Т.е. все что уже на исполнении должно отработать. Как я это понял (посмотрев исходники libuv) - в момент переключения между таской и микротаской, что-то может начать исполняться и вот это должно закончится. Функции, которые вызывают сallback'и имеют разное время выполнения. И если у вас, например, 2 callback'а один из которых вызовется через 1 секунду, а другой через 10, то Javascript не будет ждать 10 секунд, чтобы выполнить микротаски первого.
Зависит от того, что понимать под логикой работы. Публиуация правда совсем не об этом.
Думаю я не совсем корректно выразился, либо был не так понят. Под "ожидаемым поведением" я имел ввиду наличие сообщения об ошибке в тесте. Т.к. тест проверяет - будет ли выброшенно исключение в случае неверных данных. Что выводить в логи а что нет, это я думаю на вкус и цвет. В данном проекте логи выводились, как я написал выше, мне он достался уже в таком виде.
Это unit тест для клиентской части веб приложения. Который проверяет, была ли вызванна та или иная функция. Т.е. он не проверяет внутреннее сосотояние объекта. Другой тест возможно проверяет их там 558, но не этот. Воторой момент - на клиенте, по возможности, все должно работать быстро и асинхронно, т.к. мы имеем дело с событиями, которые не обязательно вызываются последовательно. Отсюда, код клиентской части чаще всего асинхронный, хотя могут быть какие-то зависимости, но конечно же при написании юнит теста это проверяется. Суть текущего теста - просто подача входных значений из массива и проверка что определенные функции внутри кода вызываются или не вызываются при этом. Я не писал этот тест изначально, о чем сказанно в публикации. Но изменение async/await на Promise в юнит тесте точно никак не влияет на логику как самого теста, так и тестируемого кода в данном конкретном случае.
345 секунд против 419 - это было на разных виртуальных машинах. Я просто версию до изменений развернул на одной виртуалке, а версию с изменениями на другой. Одна из виртуалок была довольно слабой, другая наоборот довольно сильной.
Добрый вечер. А почему должно быть ошибочным? И в чем нарушение эквивалентности?
Спасибо, он нужен был для routing-controllers. К routing-controllers есть вопросы, как и аналоги. У меня был опыт работы с ними, поэтому я о них и написал. Но это "для более удобной работы", с моей точки зрения. Т.е. лучше наверное было сказать - она не обязательна и на ваше усмотрение. Работать все будет и без нее.
Я именно этот вариант и имел ввиду. Jupyter мы просто на сервере использовали, чтобы проверить как все работает, все вызовы непосредственно из пакетов Python были, т.е. не просто скрипт в Jupiter, а функция в пактете на Python внутри которой дергался R. Я подозреваю что там дергалось все из разных pods, но это чисто мое подозрение, и получалось, что вызовы должны были как-то пробрасываться между ними. Shell скорее всего девопсы настроили на такие пробросы, а библиотеки типа rpy2 они не смогли пробросить. Но это чисто мое предположение, как я и писал выше - я прсто описал то, что у нас работало и даже если у когото, кто решили бы нашим подходом воспользоваться, с этим возникли бы просблемы, я как минимум знаю что и где подкручивать.
Пробовали, я же писал про это. Локально работало, а на окружении нет. Скорее всего проблема с окружением, но я описывал то что у нас работало, чтобы достоверность соблюсти.
Спасибо, поправил.