Для нашего проекта основным минусом стала производительность и отстутвие многопоточности (и работа в UI-потоке). В частности, приходится загружать с бэка довольно большие и сложные объекты, так вот десериализация занимает очень ощутимое время. На сложных вычислениях UI подтормаживает. Но несмотря на это впечатление от технологии скорее положительное.
Да, закрывать попапы и контекстные меню по-другому, видимо, не получится, мы тоже не нашли и в своем проекте сделали примерно также. Но кажется, что это не проблема. В большинстве слочаев эвентов в Блзор достаточно, а доя некторых случаев, типа этого можно один раз написать нужную обвязку.
У нас довольно сложный проект, сейчас на .NET размер бандла - 3 Мб без AOT. Близкое по объему функционала и сложности приложение на Angular - в сумме бандл и фреймворк - 3,5 Мб. Так что в объеме не всегда выигрышь чувствуется.
Да, удобная вещь. Тоже использую ее постоянно, но как тут уже написали подъедает процессор, когда долго остается запущенной и после выхода из спящего режима. Помогает перезапуск. Про расширения не знал, интересно. У Resource Map идея хорошая, но хотелось бы еще возможность скрывать там определенные типы ресурсов. Еще полезное расширение: Certificate info — Просмотр данных сертификатов в секретах.
Мы тоже пробовали использовать IMPORTXML для загрузки данных в таблицы. Но у Google есть ограничение на использование этой функции и мы в него упирались. Вы как-то обходите это или для ваших задач хватает лимита?
Разграничение доступа конечно же есть. У нас реализована ролевая модель и существует «подсистема» управления правами. В статье я этого не касался, т.к. предмет был немного другой.
В некотором смысле так и есть — с помощью этого инструмента пользователи создают и поддерживают свои модели привычным им способом. Вопросы версионности моделей мы не решаем (это не задача нашего инструмента). Версионность и контроль целостности самих данных, которые они загружают реализуется в нашей системе, но это таже несколько выходит за рамки статьи.
Хранение готовых моделей и их дальнейшее использование не является областью применения нашей системы. Клиенты реализуют их по-разному. Некоторые могут хранить, например Excel-файлы в Sharepoint, где есть какое-никакое управление версиями. А для некоторых эта модель промежуточная, как вы упоминали — способ получения входных данных для других аналитических инструментов. И то что они сделали при помощи нашей системы, они выгружают куда-то еще.
Наверное, со стороны решаемая задача, для которой пришлось все это сделать, выглядит несколько непонятной. Но у нас взгляд замылен, мы в ней давно варимся :) Задача достаточно «отраслевая» и связана с повышением удобства переноса числовых данных из неструктурированых документов с сохранением привязки к источнику. Т.е. надо:
быстро перенести данные в Excel
иметь возможность увидеть число из ячейки в исходном документе (например, финасовом отчете)
прeдоставить некоторые инструменты по работе с данными в виде функций Excel
Да, JS API для Excel мы тоже смотрели. Для многих задач он намного удобнее старого нативного API для addin'ов. Но некоторые вещи через него мы бы не смогли сделать, например перехват вставок. И полтора года назад, когда мы принимали решение каким путем пойти, JS API было беднее, чем сейчас. Если я е ошибаюсь, тогда там нельзя было сделать асинхронные UDF. При этом ExcelDNA очень помогает и облегчает разработку. Установка и обновление у нас сделаны через MSI, проблем с этим нет.
Похоже, сама постановка задачи вызывает много вопросов. Поясню немного. Задача состояла в том, чтобы сохранить Excel, как инструмент, в котором работает пользователь. При этом дать возможность удобно заполнять таблицы числовыми данными из исходны документов. Для этого Пользователю надо видеть одновмеменно свою таблицуи размеченный нашей системой исходный документ. Также необходимо поддерживать связанность между ячейкой, в которую пользователь вставил «число» и исходным документом. Для этого при перемещении по ячейкам ему надо показывать исходный документ и подсвечивать числа в нем. И все это должно работать быстро.
Мы ерепробовали разные варианты решения этой задачи: и «чистый» RTD, и JS API. Но результат, удобный для пользователя предстказуемо работающий без сайд-эффектов, связанных с особенностями выполенения кода в Excel, у нас получился именно в том виде, который описан в статье.
Почему мы не делали это в Google-таблицах — есть несколько причин:
1. Клиентам в основном нужно работать с Excel.
2. Для некоторых клиентов решение должно работать в сети, изолированной от Интернета или с сильно ограниченным доступом в Интренет.
3. Как уже упоминали тут в комментах, на больших таблицах Google-таблицы тормозят сильнее, чем Excel.
4. Возможностей по подключению к внешним источникам и загрузки данных в Google-таблицы меньше, чем предоставляет Microsoft.
К сожалению, не спасут. Из источника данные можно загрузить, но реализовать, например, просмотр исходного документа без дополнительных инструментов тут уже нельзя. Поддержание и визуализация связей с исходным документом, было одной из основных задач.
Если вопрос про
kubeseal, то он может читать из файла, пожет из stdin. В данном случаеkubesealиспользуется в raw mode, подробности тут: https://github.com/bitnami-labs/sealed-secrets?tab=readme-ov-file#raw-mode-experimentalДля нашего проекта основным минусом стала производительность и отстутвие многопоточности (и работа в UI-потоке). В частности, приходится загружать с бэка довольно большие и сложные объекты, так вот десериализация занимает очень ощутимое время. На сложных вычислениях UI подтормаживает. Но несмотря на это впечатление от технологии скорее положительное.
Да, закрывать попапы и контекстные меню по-другому, видимо, не получится, мы тоже не нашли и в своем проекте сделали примерно также. Но кажется, что это не проблема. В большинстве слочаев эвентов в Блзор достаточно, а доя некторых случаев, типа этого можно один раз написать нужную обвязку.
У нас довольно сложный проект, сейчас на .NET размер бандла - 3 Мб без AOT. Близкое по объему функционала и сложности приложение на Angular - в сумме бандл и фреймворк - 3,5 Мб. Так что в объеме не всегда выигрышь чувствуется.
Сейчас вроде все сам подхватывает. По крайней мере и с helm-чартом prometheus и c prometheus-operator работал "из коробки".
Да, удобная вещь. Тоже использую ее постоянно, но как тут уже написали подъедает процессор, когда долго остается запущенной и после выхода из спящего режима. Помогает перезапуск. Про расширения не знал, интересно. У Resource Map идея хорошая, но хотелось бы еще возможность скрывать там определенные типы ресурсов. Еще полезное расширение: Certificate info — Просмотр данных сертификатов в секретах.
Наверное, со стороны решаемая задача, для которой пришлось все это сделать, выглядит несколько непонятной. Но у нас взгляд замылен, мы в ней давно варимся :) Задача достаточно «отраслевая» и связана с повышением удобства переноса числовых данных из неструктурированых документов с сохранением привязки к источнику. Т.е. надо:
Мы ерепробовали разные варианты решения этой задачи: и «чистый» RTD, и JS API. Но результат, удобный для пользователя предстказуемо работающий без сайд-эффектов, связанных с особенностями выполенения кода в Excel, у нас получился именно в том виде, который описан в статье.
1. Клиентам в основном нужно работать с Excel.
2. Для некоторых клиентов решение должно работать в сети, изолированной от Интернета или с сильно ограниченным доступом в Интренет.
3. Как уже упоминали тут в комментах, на больших таблицах Google-таблицы тормозят сильнее, чем Excel.
4. Возможностей по подключению к внешним источникам и загрузки данных в Google-таблицы меньше, чем предоставляет Microsoft.