Comments 19
Нет, не нашли полезного, все выше перечисленное уже разжовано с десяток раз, вот у людей та же маркетинговая ерунда habr.com/ru/article/507842
- Линк на git, docker где?
- Почему в тексте и в тегах «open-source»? Уберите, пожалуйста, не обманывайте людей и поисковики
Добрый день! Спасибо за Ваше мнение. Open source в тексте и тегах считаем закономерным употреблять потому, что мы используем open source технологии и инструменты. Это не значит, что наш продукт является открытым (поэтому нет линков на git и docker), но и мы не считаем, что указание на open source кого-то должно было обмануть. Еще раз спасибо за комментарий. Возможно для других читателей информация из статьи будет всё же полезной. Хорошего Вам дня!
Весь мир использует open source технологии и инструменты, но весь мир не пишет это в своих тегах.
Пока вы не выложите линк на свой репозиторий с опенсорс проектом, считаю ваш тег «спамом».
В общем вы не учли «позитивный опыт» от публикации ваших конкурентов по линку что я скинул.
Пока вы не выложите линк на свой репозиторий с опенсорс проектом, считаю ваш тег «спамом».
В общем вы не учли «позитивный опыт» от публикации ваших конкурентов по линку что я скинул.
Нет, это не так работает.
По вашей логике и закрытые бинарные драйверы nvidia — тоже opensource. Ведь есть же, помимо прочего, бинарный блоб для открытого linux.
hogstaberg спасибо за уточнение. Аргумент принят. Тег удалим.
Линк на git?
Все больше работая программистом си шарп, сталкиваюсь с одной дискомфорт ной проблемой!
Пишим мы на си шарп!
Вот только используем Elasticsearch, Camunda. Джава стек.
Банально и печально что нет подобного для нет коре! Мы говорим что создаём свою систему, а на практике просто утилизируем опенсорс!
SOLON7, есть уверенность и надежда, что сообщество разработчиков на .NET Core еще наверстает упущенное, если это потребуется. Тем более, что тесты производительности .NET Core выглядят всё более впечатляющими. Говоря о нашем продукте — использованные нами инструменты лишь выполняют свою конкретную задачу. Это лишь малая часть системы. Но это скорее позитивно, что такие замечательные инструменты можно использовать и на других платформах!
norbit Есть ли ихсодники от конструктора обьектов?
С помощью какой орм реализовали DAL слой?
С помощью какой орм реализовали DAL слой?
SOLON7 пока исходников в открытом доступе нет. Видим, что есть интерес в комментариях — обещаем подумать над этим. Но интересующие Вас аспекты и особенности реализации мы с удовольствием можем рассказать здесь. ORM используем EF Core.
Вообще вопрос такой, у вас там потом статическая типизация полей или динамическая?
потомучто что в EF core добавить поля нужно потом сборки перекомпилировать!
Миграции как сделали?
потомучто что в EF core добавить поля нужно потом сборки перекомпилировать!
Миграции как сделали?
SOLON7 отличные вопросы!
Мы храним описание полей объекта — то есть метаданные, необходимые для отображения поля на форме и поиска по нему (если поиск необходим — это тоже настраивается).
Генерацией кода (с последующей перекомпиляцией) и БД мы не занимаемся, хотя знаем, что при разработке некоторых похожих систем пошли именно таким путем.
Отвечая на Ваш вопрос — типизация в результате динамическая.
Миграции сделали настраиваемыми из конфига. Есть фабрика, которая возвращает те или иные Options в зависимости от настроек. Для каждой СУБД мы поддерживаем одновременно свои миграции. Когда исследовали этот вопрос была попытка использовать одни и те же миграции — просто добавляли аннотации для разных провайдеров, но сразу обнаружили, что миграции генерятся разными провайдерами со своими особенностями, которые не очень совпадают (даже для простейших структур).
Мы храним описание полей объекта — то есть метаданные, необходимые для отображения поля на форме и поиска по нему (если поиск необходим — это тоже настраивается).
Генерацией кода (с последующей перекомпиляцией) и БД мы не занимаемся, хотя знаем, что при разработке некоторых похожих систем пошли именно таким путем.
Отвечая на Ваш вопрос — типизация в результате динамическая.
Миграции сделали настраиваемыми из конфига. Есть фабрика, которая возвращает те или иные Options в зависимости от настроек. Для каждой СУБД мы поддерживаем одновременно свои миграции. Когда исследовали этот вопрос была попытка использовать одни и те же миграции — просто добавляли аннотации для разных провайдеров, но сразу обнаружили, что миграции генерятся разными провайдерами со своими особенностями, которые не очень совпадают (даже для простейших структур).
Вопросы:
1. продукт на C#, движок Camunda на Java, и все это ставится у клиента.
Не смущает поддержка зоопарка?
2. если продукт ставится у клиента, насколько оправдана архитектура на микросервисах?
3. работаю немного с Trisotech (SaaS). А чем лучше ваше решение?
Или, например, если решение стоит у клиента, то почему не монолитный Sparx?
Примечания:
1. смена dbms за 2 дня — лихо. Вероятно, dbms используется только как хранилище данных с соблюдением нормальных форм.
2. насчет opens-source, таки да, misleading.
3. насчет dbms для Linux/Win — для инсталяций у клиента можно рассмотреть SQL Server Express 2019 (использю на практике). Он бесплатный и ставится как на Win, так и на Linux. Допускаю, что BPMS/DMN платформы Express будет достаточно.
1. продукт на C#, движок Camunda на Java, и все это ставится у клиента.
Не смущает поддержка зоопарка?
2. если продукт ставится у клиента, насколько оправдана архитектура на микросервисах?
3. работаю немного с Trisotech (SaaS). А чем лучше ваше решение?
Или, например, если решение стоит у клиента, то почему не монолитный Sparx?
Примечания:
1. смена dbms за 2 дня — лихо. Вероятно, dbms используется только как хранилище данных с соблюдением нормальных форм.
2. насчет opens-source, таки да, misleading.
3. насчет dbms для Linux/Win — для инсталяций у клиента можно рассмотреть SQL Server Express 2019 (использю на практике). Он бесплатный и ставится как на Win, так и на Linux. Допускаю, что BPMS/DMN платформы Express будет достаточно.
vagon333 добрый день! Спасибо за отличные вопросы!
Ответим по пунктам:
1. С точки зрения развертывания и поддержки — этот процесс мы автоматизируем. Поднимаются сервисы оркестратором и в последствии система мониторинга отслеживает состояние всех сервисов. Отличные от .NET платформы, на которых сделаны некоторые из используемых нами инструментов, в принципе не смущают, тем более что взаимодействие с ними происходит в основном через Rest Api;
2. Частично ответил в предыдущем пункте и в самой статье. У нас развертывание автоматизировано и мы не хотели ограничивать себя монолитом, так как заранее не знаем нагрузку;
3. Также в первой части статьи постарались обозначить наши мотивы разработки своего продукта. У нас есть свои нерешенные вопросы, которые мы постарались решить этим новым продуктом. Да, это конструктор в первую очередь, но который умеет решать и некоторые специфические задачи.
По примечаниям:
1. Действительно dbms используется только как хранилище данных и это одно из важных требований — никакой логики на стороне БД;
2. Вопрос с тегами решили :);
3. Здесь мы выбрали вариативность. Некоторые клиенты настаивает на использовании конкретных dbms по разным причинам (импортозамещение например). SQL Server Express 2019 хоть и бесплатный, но его нет в реестре отечественного ПО (это бывает важно). Да и в нем есть ограничения, к которым не хочется привязываться. Но как один из вариантов он вполне может подойти.
Ответим по пунктам:
1. С точки зрения развертывания и поддержки — этот процесс мы автоматизируем. Поднимаются сервисы оркестратором и в последствии система мониторинга отслеживает состояние всех сервисов. Отличные от .NET платформы, на которых сделаны некоторые из используемых нами инструментов, в принципе не смущают, тем более что взаимодействие с ними происходит в основном через Rest Api;
2. Частично ответил в предыдущем пункте и в самой статье. У нас развертывание автоматизировано и мы не хотели ограничивать себя монолитом, так как заранее не знаем нагрузку;
3. Также в первой части статьи постарались обозначить наши мотивы разработки своего продукта. У нас есть свои нерешенные вопросы, которые мы постарались решить этим новым продуктом. Да, это конструктор в первую очередь, но который умеет решать и некоторые специфические задачи.
По примечаниям:
1. Действительно dbms используется только как хранилище данных и это одно из важных требований — никакой логики на стороне БД;
2. Вопрос с тегами решили :);
3. Здесь мы выбрали вариативность. Некоторые клиенты настаивает на использовании конкретных dbms по разным причинам (импортозамещение например). SQL Server Express 2019 хоть и бесплатный, но его нет в реестре отечественного ПО (это бывает важно). Да и в нем есть ограничения, к которым не хочется привязываться. Но как один из вариантов он вполне может подойти.
Какой размер команды? Сколько месяцев ушло на проект? Сколько сделали внедрений? И каков в итоге экономический эффект? Сократились ли затраты на внедрение/поддержку или все только ради света в конце тоннеля?
fsukharev спасибо за вопросы! Отвечу по пунктам.
1. Размер команды в данный момент: 20 разработчиков, несколько аналитиков, несколько тестировщиков, Devops-инженер. Но не всегда было так. Начинали гораздо меньшим составом;
2. На данный момент разработка ведется примерно 1.5 года и не останавливается;
3. На сегодняшний день внедрено/внедряется 6 систем на базе нашего решения, и это только начало;
4. Эффект несомненно есть, но не только экономический. Многие вещи, которые делали ранее в рамках других проектов (интеграции, настройка бизнес-процессов, доставка приложения и т.д.), были переосмыслены и усовершенствованы. Появилась возможность настраивать более сложные кейсы. Да и специалисты стали работать с самыми современными технологиями и инструментами, что, как нам кажется, тоже большой плюс.
1. Размер команды в данный момент: 20 разработчиков, несколько аналитиков, несколько тестировщиков, Devops-инженер. Но не всегда было так. Начинали гораздо меньшим составом;
2. На данный момент разработка ведется примерно 1.5 года и не останавливается;
3. На сегодняшний день внедрено/внедряется 6 систем на базе нашего решения, и это только начало;
4. Эффект несомненно есть, но не только экономический. Многие вещи, которые делали ранее в рамках других проектов (интеграции, настройка бизнес-процессов, доставка приложения и т.д.), были переосмыслены и усовершенствованы. Появилась возможность настраивать более сложные кейсы. Да и специалисты стали работать с самыми современными технологиями и инструментами, что, как нам кажется, тоже большой плюс.
Интересно узнать размер команды (команд), примерное время, инвестирование в разработку и число внедрений. Оправдал себя подход?
Eyeadmin спасибо за вопросы! Ответил на похожий комментарий выше.
Правда, пожалуй, стоит уточнить, что у нас действительно несколько команд разработки, но они не изолированы друг от друга и работают как одно целое.
Подход на наш взгляд себя оправдывает, но впереди нам предстоит еще много интересной и увлекательной работы!
Насчет инвестирования — надеюсь вы нас простите — прокомментировать не можем :)
Правда, пожалуй, стоит уточнить, что у нас действительно несколько команд разработки, но они не изолированы друг от друга и работают как одно целое.
Подход на наш взгляд себя оправдывает, но впереди нам предстоит еще много интересной и увлекательной работы!
Насчет инвестирования — надеюсь вы нас простите — прокомментировать не можем :)
Sign up to leave a comment.
Как мы разрабатывали кроссплатформенную BPMS