Comments 26
ой нагородили…
Вообще-то это называется отделение от среды логической модели во внешние скрипты.
Собственно на этом принципе построены современные игры, где вся логика вынесена в Луа-скрипты.
Разница с вашей средой лишь в том, что игры как среды отделены от языка Луа, а у вас lsfusion-язык и lsfusion-среда связаны.
Поэтому обновления среды и обратно-совместимые изменения в язык не затрагивают логику и могут быть обновлены отдельно и безопасно. Это же позволяет отделять программистов на работающих над средой и на работающих над клиентским кодом.
Вообще-то это называется отделение от среды логической модели во внешние скрипты.
Собственно на этом принципе построены современные игры, где вся логика вынесена в Луа-скрипты.
Разница с вашей средой лишь в том, что игры как среды отделены от языка Луа, а у вас lsfusion-язык и lsfusion-среда связаны.
Поэтому обновления среды и обратно-совместимые изменения в язык не затрагивают логику и могут быть обновлены отдельно и безопасно. Это же позволяет отделять программистов на работающих над средой и на работающих над клиентским кодом.
Да, по такой схеме работают практически все ERP-платформы: 1С, SAP, Microsoft Dynamics. Они в основном написаны на C/C++, но у них есть, соответственно, свои встроенные языки 1С, ABAP и X++.
В играх язык действительно используется язык Луа, но лишь синтаксис и базовое поведение. При этом нельзя просто взять и перенести скрипты из одной игры в другую (там другая логическая модель), так что они тоже можно сказать, что связаны со средой.
В играх язык действительно используется язык Луа, но лишь синтаксис и базовое поведение. При этом нельзя просто взять и перенести скрипты из одной игры в другую (там другая логическая модель), так что они тоже можно сказать, что связаны со средой.
Интересно. Это вроде конфигураций 1С, верно? При данном подходе каждая конфигурация клиента хранится в репозитории.
Как происходит обновление конфигураций при обновлении платформы? Или совместимость никогда не ломается? Вы хостите «конфигурации» у себя. Есть ли гарантии для заказчиков?
Как происходит обновление конфигураций при обновлении платформы? Или совместимость никогда не ломается? Вы хостите «конфигурации» у себя. Есть ли гарантии для заказчиков?
Это вроде конфигураций 1С, верно? При данном подходе каждая конфигурация клиента хранится в репозитории.
Да, что-то вроде этого. Но я не знаю, насколько в 1С можно делать несколько отдельных конфигураций как модули и подключать друг к другу. Если конфигурация просто копируется и правится исходный код, то тут немного другая схема именно сделанная по модульному принципу.
Как происходит обновление конфигураций при обновлении платформы? Или совместимость никогда не ломается?
Да, начиная с версии 2.0 мы держим и будем держать обратную совместимость. Можно обновлять абсолютно независимо. Обновление платформы можно делать через apt-get/yum upgrade. «Конфигурация» собирается в один jar-файл (через jenkins или в IDEA) и просто складывается в определенный каталог. Когда сервер с платформой стартует, то он считывает модули из всех jar-файлов, которые там есть и подключает их. Внутри jar-файлов (а это zip архив) в открытом виде хранятся исходный код всех модулей. Пока обфускацией исходников не занимаемся.
Вы хостите «конфигурации» у себя. Есть ли гарантии для заказчиков?
Извините, но не понял, о каких гарантиях идет речь.
Спасибо за ответ. По последнему пункту, поправьте меня, если я неправильно понял. Ваша платформа предоставляет API и свой язык для разработки модулей. Плюс у вас есть набор готовых модулей, условно CRM. Заказчик покупает продукт Платформа + CRM, но ему нужны доработки. Вы делаете CRM ver. 2 и размещаете в своем репозитории.
Заказчик при использовании CRM ver.2 загружает ее себе и использует локально? В чем отличие от доработок других продуктов. Компания «A» тоже может выпустить доработку для своего софта «ERP A» в виде патча и передать заказчику.
Мне казалось, что идея в том, что CRM ver.2 находится в облаке. Фактически заказчик использует Платформу в облаке и модуль / модули в облаке. Вам так будет удобнее дорабатывать и сопровождать. В этом случае ему нужны гарантии по доступу (SLA).
Еще вопрос по модульности и доработкам. Если взять к примеру демо ERP. В качестве требования заказчик хочет добавлять распознанные накладные со сканера. Т.е. некий сервис распознавания возвращает извлеченные данные + картинку. Платформа позволяет делать такие доработки?
Заказчик при использовании CRM ver.2 загружает ее себе и использует локально? В чем отличие от доработок других продуктов. Компания «A» тоже может выпустить доработку для своего софта «ERP A» в виде патча и передать заказчику.
Мне казалось, что идея в том, что CRM ver.2 находится в облаке. Фактически заказчик использует Платформу в облаке и модуль / модули в облаке. Вам так будет удобнее дорабатывать и сопровождать. В этом случае ему нужны гарантии по доступу (SLA).
Еще вопрос по модульности и доработкам. Если взять к примеру демо ERP. В качестве требования заказчик хочет добавлять распознанные накладные со сканера. Т.е. некий сервис распознавания возвращает извлеченные данные + картинку. Платформа позволяет делать такие доработки?
Вы делаете CRM ver. 2 и размещаете в своем репозитории
Не совсем — у заказчика абсолютно свои модули в своем репозитории, которые просто используют модули из CRM. То есть, грубо говоря, на выходе получается два jar-файла: один содержит модули CRM, другой содержит модули заказчика. При запуске сервера используются оба файла.
Компания «A» тоже может выпустить доработку для своего софта «ERP A» в виде патча и передать заказчику.
Смотря, что рассматривать под патчем. Если просто правки в исходном коде (то есть, например, .patch файл subversion'а) CRM, то это не тоже самое, что модульность. Это именно то, что я писал в блоке Слияние, со всеми проблемами, что там есть.
Мне казалось, что идея в том, что CRM ver.2 находится в облаке. Фактически заказчик использует Платформу в облаке и модуль / модули в облаке. Вам так будет удобнее дорабатывать и сопровождать. В этом случае ему нужны гарантии по доступу (SLA).
На практике мы не используем такую схему. Только on-premise установка продукт + доработки для заказчика. Хотя местами, конечно, ставим на облачную инфраструктуру.
В качестве требования заказчик хочет добавлять распознанные накладные со сканера. Т.е. некий сервис распознавания возвращает извлеченные данные + картинку. Платформа позволяет делать такие доработки?
Да, конечно позволяет. Нам доводилось туда вставлять взаимодействие практически со всеми типами устройств (COM-сканера, весы, фискальные регистраторы, платежные терминалы), так и с кучей различных сервисов (электронные накладные, отправка SMS и прочее). Файлы мы храним прямо в базе данных (в виде byte array). Соответственно, с ними удобная и прозрачная работа.
Посмотрел онлайн демо.
Наймите дизайнера, возможно, у вас гениальная система, но выглядит она ужасно.
Наймите дизайнера, возможно, у вас гениальная система, но выглядит она ужасно.
В первых версиях мы сделали все достаточно красиво. Но потом от всего пришлось отказаться в пользу самого минимального DOM'а по двум причинам:
Но в целом посмотрите на GUI основных игроков бизнес-приложений. Поймете, что дизайн там не главное, так как решения о выборе системы, как правило, принимают люди, которые не будут в ней работать. Им главное эффективность работы сотрудников.
- Все работало достаточно медленно. Нагруженный DOM с кучей дополнительных элементов для дизайна очень сильно сказывался на отклике системы. Когда мы начали делать формы, в которых много таблиц с 30 колонками в каждой и кучей рядов, то все становилось совсем печально. Посмотрите, например, демо 1С. Да, там относительно красиво, но я бы в такой системе работал с трудом, так как там бывают секунды отклика системы на простые действия. И это на простых формах, если там построить формы с десятком таблиц, то это вообще будет работать очень плохо. У нас есть клиенты, которые одновременно работают с веб-мордой 1С и нашей, и по их отзывам у нас работать гораздо удобнее именно из-за скорости. Не забывайте, что мы делаем B2B приложения, где пользователями являются сотрудники. Для бизнеса важно, чтобы они быстро выполняли свои процессы, а не любовались дизайном.
- На формы помещалось мало информации. Если взять классический material design, то 90% форм нарисованных в том же ERP-приложении просто не поместятся на стандартный монитор. Да, их можно прятать за всякими tab'ами, dialog'ами и прочими элементами. Но на практике пользователю для принятия решения часто нужно видеть всю информацию сразу, а не судорожно работать мышкой. В итоге, мы сознательно максимально скрутили все отступы на минимум и убрали все ненужные элементы, чтобы как можно было как можно больше впихнуть на одну форму. Кроме того, у нас и десктоп-клиент, который может отображать те же самые формы. Так вот выглядеть они должны более менее одинаково, что также накладывает свои ограничения на дизайн.
Но в целом посмотрите на GUI основных игроков бизнес-приложений. Поймете, что дизайн там не главное, так как решения о выборе системы, как правило, принимают люди, которые не будут в ней работать. Им главное эффективность работы сотрудников.
Честно говоря не понимаю, как может замедлить, если вы перерисуете иконки, ну и новые добавите. На 1С не смотрите, смотрите на, ну например, Навижин. Таблицы с 30 колонками — это само по себе плохо, это нечитабельно, просто само по себе, слишком много информации.
2. Я понял почему вы так сделали, вашу логику, но мне кажется она не верной.
Чисто мое мнение.
Для бизнеса важно, чтобы они быстро выполняли свои процессы, а не любовались дизайном.Вот с таким подходом совсем все плохо, софт вы делаете для Людей, а не роботов, вы обязаны думать об эстетике.
2. Я понял почему вы так сделали, вашу логику, но мне кажется она не верной.
Чисто мое мнение.
Честно говоря не понимаю, как может замедлить, если вы перерисуете иконки, ну и новые добавите. На 1С не смотрите, смотрите на, ну например, Навижин. Таблицы с 30 колонками — это само по себе плохо, это нечитабельно, просто само по себе, слишком много информации.
Вы видели когда-нибудь рабочее место торгового брокера или диспетчера в аэропорту? У них все на одном экране (более того, у них много мониторов). И все это нужно, чтобы оперативно принимать решения.
Возьмите, например, форму ручного заказа на закупку (Закупка / Заказы / Редактировать заказ и там вкладка Подбор). Вся эта информация была добавлена по просьбам пользователей, так как им нужно видеть и динамику, остатки, продажу и резервы без каких-либо дополнительных нажатий. Может покажете в Navision как выглядит эта форма?
Вот с таким подходом совсем все плохо, софт вы делаете для Людей, а не роботов, вы обязаны думать об эстетике.
2. Я понял почему вы так сделали, вашу логику, но мне кажется она не верной.
Чисто мое мнение.
Just business. Ничего личного. Люди в любом случае привыкают и затем уже не замечают особо дизайн. А вот скорость работы остается прежней. Лично меня гораздо больше бесят тормознутые системы, чем некрасивые.
Да, конечно.
вот
Как-то не похоже на идеальный интерфейс. И даже на просто хороший — тоже не похоже...
Дизайн конечно получше, но если честно тоже не супер. Но на вкус и цвет, как известно, все фломастеры разные.
Но это не веб-интерфейс. А можете скинуть, как он в браузере выглядит?
Что сразу мы получили бы от пользователей с таким интерфейсом, что все «слишком мелко и у меня глаза болят». Можете сделать, что-то вроде CTRL+ (как в браузере), чтобы посмотреть как будет выглядеть, если шрифты побольше?
Второй момент: у вас видно на скрине только 2 записи. При ручном заказе процесс немного другой. У вас есть, допустим, 50 позиций, которые можно заказать. По каждой из них я должен видеть продажи, остатки и прочее в колонки, чтобы не приходилось переходить на каждую запись и смотреть, нужно ли делать заказ. Как в этом интерфейсе это сделать, если видны только 2 записи? И собственно как посмотреть «доступные для заказа» 50 записей, чтобы потом набрать в него 10 строк, которые я буду заказывать?
Вот пример подбора из доступных «50 записей»:
Вот пример подобранных 3х записей:
Но это не веб-интерфейс. А можете скинуть, как он в браузере выглядит?
Что сразу мы получили бы от пользователей с таким интерфейсом, что все «слишком мелко и у меня глаза болят». Можете сделать, что-то вроде CTRL+ (как в браузере), чтобы посмотреть как будет выглядеть, если шрифты побольше?
Второй момент: у вас видно на скрине только 2 записи. При ручном заказе процесс немного другой. У вас есть, допустим, 50 позиций, которые можно заказать. По каждой из них я должен видеть продажи, остатки и прочее в колонки, чтобы не приходилось переходить на каждую запись и смотреть, нужно ли делать заказ. Как в этом интерфейсе это сделать, если видны только 2 записи? И собственно как посмотреть «доступные для заказа» 50 записей, чтобы потом набрать в него 10 строк, которые я буду заказывать?
Вот пример подбора из доступных «50 записей»:
Подбор
Вот пример подобранных 3х записей:
Строки
Сейчас сделать из веба не могу, может чуть позже.Что касается позиций — тут вы отчасти правы, я бы этой форме выделил больше места, но записи естественно скролятся. Представление столбцов настраивается прям из клиента, можно убирать ненужные и добавлять нужные столбцы. Работа с большим-кол-вом (я для себя) представляю как выгрузку из Эксель. Откуда то мы знаем что хотим добавить или выгрузить, обычно это эксель, и тут все очень просто с этим.
Представление столбцов настраивается прям из клиента, можно убирать ненужные и добавлять нужные столбцы
К слову, такая возможность есть во всех современных ERP-платформах.
Работа с большим-кол-вом (я для себя) представляю как выгрузку из Эксель. Откуда то мы знаем что хотим добавить или выгрузить, обычно это эксель, и тут все очень просто с этим.
Не очень понимаю, причем здесь Excel. Конечно, можно использовать Excel как GUI-клиент все время выгружая/загружая в/из него. Но это криво. Смотрите, вот например use case:
Звонит менеджеру по продажам клиент и просит оформить заказ на продажу. У вас есть набор товаров, сформированных по какому-то принципу, который менеджер по продажам может ему продать. Клиент постоянно спрашивает, что есть в наличии и цены и просит сразу же зарезервировать ему этот товар (то есть создать строки в заказе на продажу). Как это делать в Navision?
В нашем случае все просто: есть вкладка Подбор с доступным товаром, и там есть колонка, куда можно вводить то, что просит клиент. На основании этой колонки тут же создаются строки заказа. В обратную сторону также работает (если меняются строки, то и колонка в подборе изменяется).
что есть в наличии и цены и просит сразу же зарезервировать ему этот товар (то есть создать строки в заказе на продажу). Как это делать в Navision?
Я правильно понимаю что клиенту все равно что, лишь бы было?
Как то странно.
Если клиент что то конкретно хочет, вы начинаете вводить это название, навижин подтягивает каталог, вы выбираете — сразу показывается какой остаток на складе.
Наша специфика другая, клиенту нужно 100 различных товаров, артикулы и кол-во известно. Как он это сообщит, естественно пришлет список в экселе, который очень удобно сразу загнать в заказ.
Я правильно понимаю что клиенту все равно что, лишь бы было?
Как то странно.
Если клиент что то конкретно хочет, вы начинаете вводить это название, навижин подтягивает каталог, вы выбираете — сразу показывается какой остаток на складе.
Это не странно, если клиенту важно получить что-то и точно знать, что он это получит. В многих индустриях есть большое количество аналогичных товаров и клиенту, в принципе, все равно какой из них получить (точнее лучше получить хоть что-то, чем конкретные позиции). Кроме того, часто клиент не знает весь ассортимент и ему требуется помощь менеджера, чтобы он подсказал ему.
Наша специфика другая, клиенту нужно 100 различных товаров, артикулы и кол-во известно. Как он это сообщит, естественно пришлет список в экселе, который очень удобно сразу загнать в заказ.
Это совершенно другой use case, и он часто бывает если поставки регулярные, а один и тот же товар практически всегда есть в наличии.
Вообще логика подбора реализована в том же 1С (если зайти в их демо, там редактировать документ, а потом Заполнить и Подбор товара). Так что она востребована судя по всему. Но реализована она как-то криво. Ввести кол-во в колонку нельзя, нужно сначала добавить вниз, а потом там уже менять количество. Если закрыть подбор и открыть, то уже введенные позиции не показываются (то есть редактировать неудобно).
молодцы, изобрели разделение утилит низкого уровня и обьектной модели, что должно быть в любом нормальном проэкте. А вы задумывались что обьекнтая модель может задаваться графически или вообще выводиться методами машинного обучения из обратной связи клиетнов?
молодцы, изобрели разделение утилит низкого уровня и обьектной модели, что должно быть в любом нормальном проэкте
Мы ничего не изобретали, а реализовали наиболее логичным образом.
А вы задумывались что обьекнтая модель может задаваться графически
Холивару на тему графического программирования много лет. Не стоит устраивать битву снова. С графическим программированием подумайте сначала про систему контроля версий и merge коммитов.
вообще выводиться методами машинного обучения из обратной связи клиетнов
В идеальном мире, вообще программисты не нужны, и все должен делать AI. Но мы, к сожалению, живем в другом мире.
del
… объявляем новые свойства, под которые будут созданы дополнительные поля в таблицах, и добавляем их на форму:
discount 'Скидка, %' = DATA NUMERIC[5,2] (OrderDetail); discountPrice 'Цена со скидкой' = DATA NUMERIC[14,2] (OrderDetail);
EXTEND FORM order PROPERTIES(d) AFTER price(d) discount, discountPrice READONLY ;
Цену со скидкой делаем недоступной для записи. Она будет рассчитываться отдельным событием при изменении либо исходной цены, либо процента скидки:
WHEN LOCAL CHANGED(price(OrderDetail d)) OR CHANGED(discount(d)) DO discountPrice(d) <- price(d) * (100 (-) discount(d)) / 100;
Мне вот что непонятно. Если "цена со скидкой" недоступна для записи, то почему это вообще хранящееся в БД поле, которое потом сделали "только для чтения" на форме (что позволяет любому коду туда записать, минуя бизнес-правила) и поверх навесили еще и событие, которое это поле обновляет? Почему нельзя просто сделать это поле вычислимым, минуя все эти прыжки?
Хороший вопрос. Мне его задал один из разработчиков платформы, который непосредственно логику не пишет. Кстати, READONLY оно именно на этой форме. На другой оно может быть редактируемой.
Мы так обычно делаем, когда может измениться формула расчета со временем. Если сделать, его вычислимым, а потом потребуется изменить формулу, то нужно, чтобы старые заказы считали по старому. А новые, соответственно, по новому. В этом случае, мы просто изменим событие, и все будет работать. Если же делать через вычисляемое свойство, то нужно будет менять формулу типа IF date >… THEN expr1 ELSE expr2. А если изменений будет очень много, то все это превратится в огромный CASE WHEN THEN, что будет не очень удобно. Ну и опять же, заказчик может захотеть вводить цену со скидкой вручную.
Мы так обычно делаем, когда может измениться формула расчета со временем. Если сделать, его вычислимым, а потом потребуется изменить формулу, то нужно, чтобы старые заказы считали по старому. А новые, соответственно, по новому. В этом случае, мы просто изменим событие, и все будет работать. Если же делать через вычисляемое свойство, то нужно будет менять формулу типа IF date >… THEN expr1 ELSE expr2. А если изменений будет очень много, то все это превратится в огромный CASE WHEN THEN, что будет не очень удобно. Ну и опять же, заказчик может захотеть вводить цену со скидкой вручную.
Можно ли сделать поле, которое невозможно присвоить напрямую, минуя бизнес-правила?
Не очень понятно с логической точки зрения, как отличить присвоение напрямую от присвоения не напрямую.
Как вариант, можно просто добавить CONSTRAINT, что discountPrice не равен формуле. Тогда при применении в базу всегда будет ошибка, если значение не соответствует.
Как вариант, можно просто добавить CONSTRAINT, что discountPrice не равен формуле. Тогда при применении в базу всегда будет ошибка, если значение не соответствует.
Не очень понятно с логической точки зрения, как отличить присвоение напрямую от присвоения не напрямую.
Обычно для этого используют области видимости или что-то подобное, когда "право на присвоение" есть только у кода, который является бизнес-логикой.
Интересно, кстати, а можно сделать WHEN CHANGED поверх вычисляемого поля?
Sign up to leave a comment.
Как мы дорабатываем продукт под конкретного клиента