Comments 13
Наверное, на этот вопрос тут ответ искать бесполезно.
Тем не менее
- https://ria.ru/economy/20161206/1482988837.html. Вектор задан.
- Расточительное использование имеющихся ресурсов оправданий особых не имеет. Если в окна дует зимой — надо окна менять, а не батареи добавлять.
- Стратегия эффективного управления — своевременно использовать актуальную информацию из всех доступных источников. При этом нет необходимости покупать калькуляторы из чистого золота. Многие задачи решаются гораздо проще и быстрее, а с сэкономленными средствами можно своих сотрудников поддержать, а не кормить ватагу вендоров.
Кроме того, как я не раз смог убедиться, у многих компаний эволюция документооборота происходит от некой учетной системы. У многих это 1С. Например, я несколько лет имел дело с крупных холдингом, где все началось именно с 1С Предприятие и автоматизации бухучета. Потом «прикрутили» адаптированные модули, связанные с управленческим учетом. С ростом компания обзавелась телеметрией (тысячи датчиков: уровень топлива, GPS, датчики на агрегатах) и решили делать бюджет больше не в Экселе. В результате, добавились сервера от Microsoft. Одним из «бонусов» шел Power BI, который позволяет создавать довольно неплохие отчеты уже после двух дней обучения обычного экономиста/бухгалтера.
И вот у меня возник вопрос: «экосистема R» — как я понимаю, в приведенном мной примере лишь замена Power BI. Как это превратит бизнес в «цифровой бизнес»?
Кстати, в этом холдинге уже больше года внедряется система под заголовком Digital Business. Если в двух словах, то это ИИ, который на основании данных с датчиков, плановых экономических показателей, занесенных алгоритмов, исторических данных и еще нескольких параметров будет сам готовить технологические карты и производственные планы. По ним уже будет формироваться производственный буджет. Контроль за выполнением бюджета будет осуществляться по данным 1С. Все это будет в «одной коробке» (конечно, не буквально). Таким образом, будет минимизирован человеческий фактор. С точки зрения этой компании именно так выглядит цифровой бизнес.
Евгений, спасибо за такой развернутый комментарий.
Отвечаю по позициям.
- Понятие "цифровая экономика" сейчас находится в состоянии осмысления. Применительно к России с его содержанием можно ознакомиться здесь: Цифровая экономика — Правительство России, а в картинках — здесь
- Публикация является "бизнес-надстройкой" над предыдущими технологическими публикациями. "Экосистема R" это не PowerBI, а весь цифровой блок + АРМ + визуализация:
- частичный сбор (подхват всяких legacy, кустарщины, web-scrapping и прочий слаботипизированный сбор) и процессинг данных;
- выверка и чистка;
- исполнение различных вычислительных алгоритмов;
- реализация интерфейсов машина-человек, как в форме стационарных отчетов, так и в форме аналитических АРМ (тут и есть некоторое пересечение с PowerBI);
- опциональное управление внешними системами.
Можно провести аналогию с "бытовой" робототехникой, где все тупое железо работает под управлением Android + периферийные Arduino. R выполняет роль Android-а
- Насчет описания Digital Business — у нас на текущий момент ровно такое же понимание. В одной из инициатив как раз стоит задача контроля всех параметров технологического конвейера на предмет
- анализа отклонений,
- прогнозирования брака (конвейер каждый раз перестраивается под параметры выходной продукции, требуемой конкретному заказчику)
- оптимизации физико-технических параметров (например, температура нагрева, давление, скорость валков и пр..) с тем, чтобы снизить расход электроэнергии и снизить износ оборудования без ухудшения качества выходной продукции.
1. Невозможность полноценной реализации monopoly access
2. Невозможность реализации расширенной логики авторизации и поддержки ролевых моделей по RBAC
3. Проверка ролевой модели доступа должна быть явно реализована в каждой точке доступа
4. Невозможность реализации горизонтальной масштабируемости
5. Невозможность частичного апдейта back-front end, только через полный апдейт с операционной блокировкой сервера.
6. Однонаправленная транспортировка клиент/сервер по HTTP (невозможность реализации SingnalR или COMMET)
7. Невозможность разделения back|fromt end разработки
8. Тяжелая ресурсная стоимость UI-render Shiny пакета
9. Высокая сложность отладки, зависимость базовых механизмов (логирование, access management, управление представлениями и т.д.)
Реализация R+Shiny идеально подходит для систем, которые разработаны «под одного пользователя». Как только возникает необходимость обеспечить параллельную работу нескольких пользователей на одними и теми же данными — начинается хаос :(
ИМХО — R необходимо использовать для тех вещей, для которых он создан: статистическая backend логика, аналитика и big data; прочая бизнес-логика, UI и тд. должны быть реализованы на других платформах. Благо Micrisoft подарил свет в конце тоннеля внедрив поддержку R в .NET и MS SQL.
Еще 2 комментария.
Пакет Shiny генерирует стандартный HTML, в базисном варианте на базе библиотеки bootstrap. Накладных расходов очень мало. И даже оставаясь в рамках пакетов R базовый интерфейс может быть расширен огромным количеством элементов не говоря о возможности добавления своих JS скриптов и CSS стилей. Если это в новинку, могу ссылок дать.
- Насчет обмена данными между сервером и клиентом.
Приложения обеспечивают двусторонний обмен, методы реактивного программирования скрывают из app.R весь механизм обработки событий.
Достаточно удобно строятся динамические интерактивные web приложения.
Примеры: Plot interaction, Adding and removing UI objects, Table interaction
Shiny Server, который представляет собой NodeJS + R в бэкенде + пакет shiny для связки веба с R поддерживает широкий спектр протоколов обмена:
Shiny Server provides a wide variety of techniques to keep the data in the web browser synchronized. The preferred technique, and the one most widely used, is the use of WebSockets. However, if WebSockets are not supported — either by some intermediate network between Shiny Server and your client, or by your client's web browser — then a fallback protocol will be used. In total, Shiny Server provides nine different methods of connecting to the server in real-time. In order of preference, they are:
- WebSocket
- XDR Streaming
- XHR Streaming
- iframe Eventsource
- iframe HTML File
- XDR Pollilng
- XHR Polling
- iframe XHR Polling
- JSONP Polling
Также не совсем понятно, зачем в shiny так сильно порезали функционал AdminLTE. Теоретически, конечно, добраться к нему можно, но через ненужные костыли. Например, попробуйте добавить header right sidebar, который по-умолчанию есть в AdminLTE.
О том, что можно подключать js, css никто не спорит, но это уже не реализация самого shiny.
Я не говорю, что это все не возможно, но реализовано или приходится решать через столько костылей, что возникает вопрос — а стоит ли? Особенно когда система уходит на прод и нужно обеспечить удаленный bug-fixing, распределенную разработку и т.д.
2. Поддержка протокола как таковая и реализация — две большие разницы, имхо. Реактивность shiny обеспечивает односторонний обзервер только ui. Вы видите возможность реализации стандартного паттерна Наблюдатель серверной части в shiny? Например, обновление счетчика и вызов пуш-уведомления при отправке сообщения другим пользователем? Т.е. сам объект, ивент и обсервер за ним полностью на стороне серверной части, а не в ui. Такая задача потребует инициализации нескольких промежуточных reactivalues контейнеров, и нескольких обзерверов для связки, но это костыль, который очень далек от паттерна.
На всякий случай повторюсь, я не говорю, что shiny плох, или его не нужно использовать вообще (у меня самого сейчас на поддержке несколько реализаций с shiny, которые поддерживаются go-live у внешних клиентов). Но с усложнением задачи и архитектуры приложения, все минусы shiny вылазят очень больно и возникает необходимость реализации других вариантов.
Наличие компьютера на рабочем месте никак не означает, что его возможности используют хотя бы на 5%.
Поэтому основная задача — еще раз напомнить в приземлении на конкретику, что есть набор апробированных бесплатных инструментов (экосистема мне нравится больше, поскольку это именно слаженная совокупность), которые позволяют решать т.н. "головоломные" задачи бизнеса в части манипуляции почти произвольными данными и любыми масштабами. А про R & Shiny слышали очень немногие.
- Задачу кросс-взаимодействия мы иногда решаем посредством реактивных внешних источников, в частности, db backend + reactivePoll. Вполне шустро и просто. Как раз и получается паттерн Наблюдатель в 3 строчки в голом его проявлении. А элементы UI используют данные из реактивного источника и автоматически актуализируются при его обновлении.
В целом, во многом согласен. Серебряную пулю пока не изобрели. Спасает несколько моментов.
На полноценную OLTP систему комплекс даже и не позиционируется, больше акцент именно на аналитическую работу в разорванном информационном пространстве со множеством кривых и неполных источников данных. Но вытащить это из области абстрактной стат. обработки на задачи реального сектора.
Коммерческие версии продуктов RStudio (или ветка Microsoft) во многом закрывают вопросы AAA, масштабирования, логирования, публикации и пр.
Пользователи бывают разные. Писателей (разработчиков\аналитиков) на порядки меньше Читателей (которым нужен результат в виде комиксов). Пока конфликтов не возникает. Ну а для больших проектов могут использоваться полноценные бэкенды. Например, для time-series статических данных (а это события, транзакции, измерения,...) решение Yandex Clickhouse оказалось очень конкурентноспособным по отношению к дорогим западным продуктам.
- Приведенный подход не только не противоречит разработке специализированного UI на других языках\фреймворках, но даже поддерживает. Как только собран полнофункциональный комплекс, для элементов UI, плохо ложащихся на Shiny, можно и нужно разрабатывать специализированный интерфейс. При этом можно использовать все сделанные на R наработки, например, через REST API. В последней версии RStudio Connect этот функционал включен сразу в поставку. Однако ситуация такова, что в разработку можно будет пускать не 100%, а 20-40%.
Цифровая экономика и экосистема R