Вход | Регистрация
    1  2  3  4  5  6  7  8   

Фузина как платформа разработки учётных систем

Ø [Волшебник, 26.03.21 - 15:14]
Фузина как платформа разработки учётных систем
Я
   Светлый путь
 
22.03.21 - 04:22
Совершенно случайно наткнулся на многокилометровое обсуждение Фузины. Появилось желание посмотреть, что же это такое на самом деле. Собственно, хотелось бы высказать свои соображения для тех, кто точно так же "наткнётся" на эти ветки.

Платформа Фузины и среда разработки установились на Убунту 20.04 без каких-либо проблем. Предварительно потребовалось установить только Постгре.
В разделе помощи на странице Фузины можно найти примеры реализации простых информационных систем: «Турнирная таблица» и «Управление материальными потоками». Собственно, эти примеры были реализованы, после чего была разработана простейшая база по учёту текущих задач (с двумя таблицами: «основная» таблица Задачи — наименование задачи, описание, приоритет, срок, процент выполнения, дата выполнения, — и «вспомогательная» таблица Приоритеты).

Какие выводы можно сделать?

Начнём с сильных сторон. Платформа интересная, ни с чем подобным работать до этого не приходилось. Разработка, в рамках задач, на решение которых направлена платформа, действительно быстрая. Сама концепция разработки ("декларативная") сильно отличается от привычных "императивных" языков (в первую очередь — встроенного языка 1С:Предприятия), и больше похожа на написание запросов с указанием неких дополнительных параметров. Проверка исходного кода на ошибки происходит до выполнения «сборки», сразу подсвечиваются ошибки.

Теперь о проблемах и трудностях касательно разработки приложений для автоматизации учёта и управления.
Первое. Уровень абстракции Фузины гораздо ниже, чем в 1С:Предприятии. Код описывает классы, таблицы, формы и т. п., но не справочники, документы, журналы документов и пр. То есть это абстракция, понятная для программистов (да и то при условии прохождения соответствующей подготовки — следствие "декларативного подхода" в используемом языке), но не для конечных пользователей информационной системы, когда взаимосвязи и основные механизмы понятны "по логике".
Второе, и это просто проклятие! Всё по-нерусски. И ключевые слова самого языка, и среда разработки. Всё, за исключением документации. Это катастрофа. Необходимость писать prioritetZadachi, procentVypolneniya вместо ПриоритетЗадачи, ПроцентВыполнения вводит в глубочайшую тоску.  Этот пункт, вкупе с первым, означает, что конечные пользователи Фузины не смогут разговаривать с разработчиками «на одном языке» даже теоретически. То есть составление технического задания конечным пользователем в принципе невозможно без участия методолога, "посвящённого" в процесс разработки.
Третье, это тот самый декларативный подход. По сути, программист описывает, как должна работать информационная система, а не последовательный алгоритм действий, который приведёт к требуемому результату. То есть сама логика написания кода больше напоминает составление запросов с указанием дополнительных параметров. Нельзя сказать, что это недостаток системы, но отличие от «классических» языков для программиста разительное.
Ну и четвёртое — это документация. Она неплохая, написана очень толково и достаточно подробно. Но не хватает поиска и индекса по ключевым словам (то, к чему мы так привыкли в 1С:Предприятии — синтаксис-помощник). Например, я хочу добавить условное оформление для строки таблицы на в форме. Скажем, если значение поля ПроцентВыполнения (в фузиновском коде procentVypolneniya, чтоб его!) равно 100, подсвечивать строку каким-либо цветом. Как мне найти в справочной системе информацию о том, как это сделать (такая возможность в платформе есть)?

Что в итоге? Может ли Фузина, хотя бы чисто теоретически, занять место 1С:Предприятия на фронте инструментов разработки учётных систем? Нет, конечно. Если пункты 3 и 4 — "дело наживное", то пункты 1 и 2 подтверждают это абсолютно точно. Сила платформы 1С:Предприятие как раз в том, что она предоставляет, с одной стороны, высокий уровень абстракции — вплоть до категорий предметной области, —  а с другой — понятна конечным пользователям, прошедшим минимальную подготовку.

А любая критика конфигуратора как среды разработки и встроенного языка платформы невозможна и неприемлема до тех пор, пока не появится другая среда и другой язык, где, по крайней мере, ключевые слова и названия переменных можно будет писать по-человечески — ОписаниеЗадачи, а не opisaniyeZadachi. И затем в меню Сборка выбрать пункт Собрать…

Пока же Фузина — это экспериментальный прототип для программистов. Прототип интересный, на основании которого можно было бы сделать реальное решение... Но на текущий момент — именно прототип, заготовка, «научный эксперимент», а никак не конечный продукт.
   Конструктор1С
 
301 - 23.03.21 - 11:08
(299) везде есть. Только они нее на уровне платформы, а в виде общепринятых соглашений. Слышал про MVC, MVVM и иже с ними? Наверняка не слышал, фузину современные практики программирования обошли стороной. Так вот, шаблоны проектирования MVC, MVVM хоть и не разделяют на клиент и сервер, но отделяют реализацию интерфейса от бизнес-логики
   fisher
 
302 - 23.03.21 - 11:10
(297) Будет точно так же, как и в фузине. В 1С забыли в нужном месте сделать явную блокировку, в фузине забыли в нужном месте подстелить материализацию (пока не понимаю, как это решает, но пусть) - результат будет одинаков. Суть в том, что разработчик в узком месте все равно должен подумать и принять решение.
(299) И САП и дайнамикс отдыхают в части программирования интерфейса. А подход 1С, в частности, позволил сделать тонкого клиента нативно-кроссплатформенным.
   Конструктор1С
 
303 - 23.03.21 - 11:14
(300) а где в фузине "пользователи в АРМах работают, а документы это уже производные штуки"? Вы талантливейше скидали всё в одну кучу, тем самым выстреливая в ногу себе и будущему системы
   Bro
 
304 - 23.03.21 - 11:37
(301) > Так вот, шаблоны проектирования MVC, MVVM хоть и не разделяют на клиент и сервер, но отделяют реализацию интерфейса от бизнес-логики

И? В lsFusion тоже отделена бизнес-логика и логика представлений

https://ru-documentation.lsfusion.org/pages/viewpage.action?pageId=688137

Только какое это отношение к разделению клиента и сервера имеет?
   Вафель
 
305 - 23.03.21 - 11:39
во всех "взрослых" языках клиент-сервер отдельно ибо это 2 разные программы обычно
   Вафель
 
306 - 23.03.21 - 11:40
и даже более того на разных языках
   Bro
 
307 - 23.03.21 - 11:44
(302) > Будет точно так же, как и в фузине. В 1С забыли в нужном месте сделать явную блокировку, в фузине забыли в нужном месте подстелить материализацию (пока не понимаю, как это решает, но пусть) - результат будет одинаков

Нет, не так. Насколько я понимаю в 1С даже при наличии материализации (а скажем материализация остатков в регистре это частный случай материализации) целостность нарушится (ну судя по примерам для чего нужна управляемая блокировка). То есть если вы считаете остаток добавите к нему число и запишете, и кто-то другой это сделает параллельно, то в версионнике (и в том числе в фузине) одна из транзакций получит UPDATE CONFLICT и перепроведется. А что в 1С будет? И это как раз 95 процентов случаев про которые я говорил.

> А подход 1С, в частности, позволил сделать тонкого клиента нативно-кроссплатформенным.

Вот этого не совсем понял. В фузине тоже десктоп-клиент по сути нативно-кроссплатформенный. Разделение клиента и сервера для этого же совсем не обязательно.
   Bro
 
308 - 23.03.21 - 11:44
(305) Именно поэтому на них сложные бизнес-приложения достаточно редко пишут.
   Конструктор1С
 
309 - 23.03.21 - 11:49
(304) в каком месте отделена? Вы же интерфейс рисуете и с данными работаете в одном классе
   Bro
 
310 - 23.03.21 - 11:49
(303) Так в lsFusion как раз нет как такого разделения "форм", на ввод первичных данных и вывод агрегированных. По сути любую форму можно (да и нужно) сделать АРМ (то есть содержащую и те и другие данные).
   Bro
 
311 - 23.03.21 - 11:52
(309) Не совсем понял, есть отдельно логика представлений (формы - view, события на формах - controller) и логика предметной области (классы, первичные свойства - model, остальные свойства - view (хотя могут быть model), события - controller). В принципе на MVVM это все тоже очень легко натянуть.

Опять таки какое отношение это к разделению клиент / сервер имеет?
   Конструктор1С
 
312 - 23.03.21 - 11:52
(310) во-во-во. Про то и пишу, что нет у вас разделения. Подходы 20+ летней давности
   Bro
 
313 - 23.03.21 - 11:54
(312) Вы мне кажется что-то путаете, это разделение форм на ввод первичных данных и отчеты - подход 20+ летней давности. Сейчас как раз в моде АРМы, реактивные интерфейсы вот это вот все.
   acht
 
314 - 23.03.21 - 11:54
(310) Представь себе, что форма документа в 1С - это микро АРМ, объединяющий прикладные данные нескольких областей и успокойся.
   Конструктор1С
 
315 - 23.03.21 - 11:54
(311) так MVVM это не механизм, это скорее соглашение. И вы его не используете
   Bro
 
316 - 23.03.21 - 11:56
(314) Так спор же и начался с того, что фишер на эту форму документа хотел вытянуть данные для принятия решения вытянуть (то есть сделать АРМ) и наоборот в форму принятия решения - отчет ввод добавить (то есть опять таки сделать АРМ). И все его извращенцем начали называть.
   _DAle_
 
317 - 23.03.21 - 12:00
(309) >Вы же интерфейс рисуете и с данными работаете в одном классе

В одном файле (модуле) вы имели ввиду? Во-первых, это необязательно так, можно делать и в двух, и в десяти. И необязательно именно потому, что логика представления отделена от логики предметной области.
   fisher
 
318 - 23.03.21 - 12:01
(307) > То есть если вы считаете остаток добавите к нему число и запишете, и кто-то другой это сделает параллельно, то в версионнике (и в том числе в фузине) одна из транзакций получит UPDATE CONFLICT и перепроведется
Речь о сложных вариантах, когда чтение одних данных влияет на результат записи других данных в этой же транзакции. И соответственно нужно не дать параллельной транзакции прочитать уже прочитанные в первой транзакции данные, пока не завершится первая транзакция. Ясен пень, что таких неудобных случаев можно избегать разными путями. И 1С тоже старается это делать.
(308) > В фузине тоже десктоп-клиент по сути нативно-кроссплатформенный
Даже на мобильных? ;)
Ну и ты же не будешь спорить, что программирование клиентской части открывает широкие возможности? Иначе почему веб-разработка так ломанулась в SPA (ну, по сути периодически маятником качается туды-сюды).
   acht
 
319 - 23.03.21 - 12:03
(316) > данные для принятия решения
Текущие остатки товаров на складе - вполне себе данные для принятия решения.
И документ - форма для принятия решения.  И обработка, показывающая печатную форму с полями ввода - форма для принятия решения. Вот только решения разные.

Единственное отличие, они прикладное - объект документа имеет отметку на временной оси, поэтому используется с соответвтвующих сценариях

Вы своей терминологической казуистикой уже сами себе глаза зассали.
   Bro
 
320 - 23.03.21 - 12:03
(315) Ну да, это ближе все же к классическому MVC.

Потому как ИМХО ViewModel текущая абстракция по определению (так как не может абстракция называться как две другие абстракция) и вообще вся эта MVVM модель сугубо техническая (реально непонятно куда они controller в ней дели, видимо в V запихнули). Хотя если сильно постараться наверное можно на нее натянуть абстракции lsFusion, но непонятно зачем.
   Bro
 
321 - 23.03.21 - 12:07
(318) > Речь о сложных вариантах, когда чтение одних данных влияет на результат записи других данных в этой же транзакции. И соответственно нужно не дать параллельной транзакции прочитать уже прочитанные в первой транзакции данные, пока не завершится первая транзакция. Ясен пень, что таких неудобных случаев можно избегать разными путями. И 1С тоже старается это делать.

Так я же как раз самый простой вариант привел. Проще некуда - пришло, ушло, осталось. И он в 95 процентов случаев будет возникать. Что в таком случае предполагается в 1С надо делать? Потому как в модели с версионниками и перепроведением транзакции ничего делать не надо.

> Даже на мобильных? ;)
Ну кстати можно было бы нативный и мобильный реализовать (благо все на Java и на тот же андроид не сильно сложно было бы портировать).

> Ну и ты же не будешь спорить, что программирование клиентской части открывает широкие возможности?

Не спорю. Безусловно. Но вопрос именно для чего используется платформа. И про это чуть выше писал:

> В любом случае я понимаю существенные плюсы для разработки информационных систем с простыми процессами и в том числе пользователями не из числа сотрудников (там можно делать тонкий тюнинг по эргономике, производительности), но для сложных бизнес-приложений с ограниченным числом пользователей (из числа сотрудников)? А это вроде как основная ниша 1С.
   Mikeware
 
322 - 23.03.21 - 12:09
(318) "программирование клиентской части" есть по сути "возврат к толстому клиенту". ну этот вечный маятник 1с: "ура, мы избавились от общих реквизитов" - "ура, мы ввели общие реквизиты"
   Bro
 
323 - 23.03.21 - 12:15
(319) Ничего не понял, как это соотносится с:

Так спор же и начался с того, что в контексте разговора про текущие абстракции, фишер на форму документа хотел вытянуть данные для принятия решения вытянуть (те же остатки, то есть сделать АРМ) и наоборот в форму принятия решения - отчет ввод добавить (то есть опять таки сделать АРМ). И вроде не сильно возражал, что в 1С это мягко говоря не сильно удобно. И все его извращенцем начали называть, и говорить что это на самом деле не нужно.
   fisher
 
324 - 23.03.21 - 12:16
(321) > Так я же как раз самый простой вариант привел. Проще некуда - пришло, ушло, осталось. И он в 95 процентов случаев будет возникать. Что в таком случае предполагается в 1С надо делать? Потому как в модели с версионниками и перепроведением транзакции ничего делать не надо.
Я не очень понял этого случая. Если нужен контроль остатков - то как же это ничего делать не надо? А контроль остатков? Если он не нужен - то и в 1С ничего делать не надо. Да и контроль остатков в этом случае принято делать оптимистический (т.е. без явных блокировок).
> Но вопрос именно для чего используется платформа.
О! А это очень тонкий вопрос. Вы выбрали более простой, но менее гибкий вариант и теперь убеждаете себя и окружающих, что это оптимальный выбор. И естественно, за аргументами в карман не полезете. Но тем не менее - это trade-off. В вашем случае - абсолютно оправданный. Потому что минимум усилий - максимум эффекта. А вот в 1С заморочились. И получилось, как по мне - отлично.
   fisher
 
325 - 23.03.21 - 12:23
(323) > И вроде не сильно возражал, что в 1С это мягко говоря не сильно удобно.
Отчет в документ - вполне удобно. Просто не принято особо.
Использовать отчет для внесения данных - да, менее удобно. В том смысле, что "обвязки" требуется больше, чем обычно принято в 1С для решения рядовых ситуаций, скриптуемых в пол-пинка.
   fisher
 
326 - 23.03.21 - 12:33
Ведь возможность размещения отчета в документе - можно сказать родная и предусмотренная разработчиками платформы. Просто отдельный объект "Отчет" содержит дополнительно много сахара и за его рамки редко выходят. А вот для внесения данных через отчет - с сахаром сложнее по понятным причинам. Слишком много точек неопределенности возникает. Про формы фиксированных размеров и простой структуры я не говорю - там все понятно и 1С в этом режиме юзает табличные документы в том числе и в типовых конфигурациях. Но с точки зрения бизнес-логики это и не отчеты, а скорее фиксированные формы внесения данных.
   Bro
 
327 - 23.03.21 - 12:35
(324) Я не очень понял этого случая. Если нужен контроль остатков - то как же это ничего делать не надо? А контроль остатков? Если он не нужен - то и в 1С ничего делать не надо. Да и контроль остатков в этом случае принято делать оптимистический (т.е. без явных блокировок).

Так в этом же и смысл. Обе транзакции проверят на 0, обе пройдут, но одна транзакция откатится из-за UPDATE CONFLICT'а, перепроведется, сработает еще раз контроль остатков и выдаст ошибку. В итоге в минус списать будет невозможно. Я понимаю, что 1С скорее всего неповторяющееся чтение при обновлении решает, тем что остатки обновляет одним запросом UPDATE количество = остатки.количество + изменение.количество FROM остатки JOIN изменение. И в READ COMMITED этот запрос будет выполнять с блокировкой, и тем самым решится проблема целостности без сильной проблемы с масштабируемостью. Но, тут вопрос а) что будет в версионниках (я честно не помню блокируют они или нет), б) но главное в чуть более сложных случаях (том же контроле остатков, или каких то чуть более сложных вычислениях) это не поможет.

> Вы выбрали более простой

Давайте определимся простой для кого? Для реализации или для разработчиков. Потому как для реализации это далеко не простой вариант, а скорее наоборот более сложный (архитектурно, а не технически). Но сложность реализации это не так важно для разработчика. Разработчику же вариант где один flow имхо проще. Да это менее гибко, но мы для этого поддержали custom java / javascript расширения. И в итоге у разработчика есть выбор - использовать в 95 процентах более простой вариант (без разделения), а в 5 более сложный (с разделением). А 1С по сути оставили только более сложный вариант. То есть по сути заставили разработчика заморачиваться вещами которые ему в абсолютном случае не нужны (и являются чистой premature оптимизации). Вам не кажется что это очень странный trade-off на рынке бизнес-приложений? Это все равно что в телефоне убрать одну кнопку с автоматическими фильтрами, а оставить только тонкую профессиональную настройку из десяти параметров.
   Bro
 
328 - 23.03.21 - 12:38
(327) Для реализации имел ввиду легкий / тяжелый, а не простой / сложный. После фильма Престиж все стараюсь заставить себя разделять эти понятия :)
   ta_da
 
329 - 23.03.21 - 12:58
(223) до тех пор пока вы будете рассказывать, как "с прототипом пришли на занятый рынок и отжали там все, за счет мощной платформы" - буду.
Потому что
1) Вы на рынке больше 20 лет.
2) Вашу систему преподают в государственных ПТУ, ее используют в государственной сети магазинов (ух, эти продажные псы режима).
3) Вашу систему активно продвигают (продвигали?) продавцы фискального оборудования.
4) Даже название текущей системы делали похожим на название предыдущей. Интерфейс и логика работы - тоже повторены.

Это все не плохо, но смешно читать про "вот какой у нас рост за последние N лет с нуля".
Это как если бы 1С на платформе 8.x переписали ТиС, без особенного расширения функций, внедрили его всем старым клиентам и нашли несколько новых. А потом на форумах рассказывали, что они "молодой стартап, вот только что отжали оптовый рыной РФ".
   fisher
 
330 - 23.03.21 - 13:08
(327) Да. В 1С неповторяемое чтение. Де факто сейчас используется READ_COMMITTED при MVCC (в режиме управляемых блокировок). И произойдет следующее - если для регистра остатков не включен режим разделения итогов (о нем ниже), то будет точно так же конфликт записи и ожидание на блокировке. Если ожидание будет в пределах тайм-аута - то после завершения первой транзакции автоматом пойдет дальше вторая, уменьшит остаток и откатится после проверки остатков и выявления факта ухода в минус. Если ожидание превысит таймаут - будет соответствующий эксепшн. Поэтому есть также специальный режим разделения итогов для регистров накопления. Если он активирован - то в таблице итогов заюзывается дополнительное служебное поле и конфликта записей не произойдет. То есть не будет ВООБЩЕ никаких конфликтов на уровне СУБД и проблем с этим связанных. В этом случае просто "опоздавшая" транзакция выявит факт ухода в минус и откатится. ИМХО, это получше вашего варианта.
> Давайте определимся простой для кого? Для реализации или для разработчиков.
Да для всех. На старте. Или вы думаете, что прозрачное разнесение на два слоя - это как два пальца? У вас заведомо ограниченный по гибкости вариант. Но да, чем больше разработчик платформы хочет добавить гибкости разработчику решения - тем сложнее это будет для разработчика платформы. Ваш барьер непрозрачный и плохо преодолимый при низком пороге вхождения. Для вас - это был оптимальный выбор. Я бы делал точно так же на вашем месте. Но в решении 1С есть своя красота и мне она нравится. При высокой квалификации разработчиков она позволяет создавать более интересные решения. Разработчики с низкой квалификацией заучили набор шаблонов и плюясь тоже вполне успешно клепают формочки, несмертельно при этом напрягаясь.
 
 
   YUN1
 
331 - 23.03.21 - 13:19
(329) Косвенно эту теорию подтверждает то, что в России у фузины 0 (ноль) внедрений в компаниях, не являющихся дочками компаний из РБ.
   H A D G E H O G s
 
332 - 23.03.21 - 13:20
(330) Вы пишите ересь.
   H A D G E H O G s
 
333 - 23.03.21 - 13:23
(330) Режим разделения итогов при контроле остатков как раз не используется. При контроле остатков (например при отгрузке) читаются (и блокируются) все эти "разделенные" остатки.
Режим разделения итогов используется там, где контроля остатков нет (например, при приемке).
   polosov
 
334 - 23.03.21 - 13:23
(330) (332) Начинайте, господа. Люблю холивары про блокировки.
   YUN1
 
335 - 23.03.21 - 13:23
(330) Вот не текущий момент у 1С как платформы две серьёзных проблемы - фиговая модульность и невозможность нормально управлять индексами СУБД. Остальное всё совсем неплохо.
   kolts23381
 
336 - 23.03.21 - 13:26
В 1с проблема большого количества кода решается наработками. В УНФ(в УТ скорей всего тоже) при проведении разных документов есть много повторяющегося кода, который можно определить в одну функцию, что собственно я и сделал. У меня вообще документ проводится по ссылке - после изучения типового кода я понял, что объект по большому счету не нужен. Главное чтоб проведение документа и запись регистров были в одной транзакции. Также для каждого регистра есть своя функция записи - ОтразитьЗапасы,ОтразитьЗакупки и т.д. - я сделал одну функцию с параметром. Контроль остатков также сделан для каждого регистра отдельно - и его можно сделать одной функцией с параметром.
   fisher
 
337 - 23.03.21 - 13:27
(333) Я написал, что режим разделения итогов позволит двум параллельным транзакциям изменить один и тот же итог без возникновения блокировок СУБД. В чем я ошибся?
   H A D G E H O G s
 
338 - 23.03.21 - 13:27
(330) Вот хорошая статья по этому вопросу
https://infostart.ru/1c/articles/196565/
   H A D G E H O G s
 
339 - 23.03.21 - 13:28
(337) В том, что употребили это в контексте контроля остатков, либо отдельно не обособили, обратили внимание, что это не работает при контроле остатков.
   YUN1
 
340 - 23.03.21 - 13:29
(336) Для фузиновцев это не считается, так как в типовых по-другому :)
   ta_da
 
341 - 23.03.21 - 13:29
(331) а в чем теория-то? Ну вот их собственные рекламные статьи от 2013 года: https://produkt.by/story/ls-fusion-set-retail-polnaya-avtomatizaciya

1) "...компания «ЛюксСофт» представила свое инновационное программное решение LS Fusion. Продукт, на разработку которого ушло четыре года, на данный момент не имеет аналогов на рынке.."
2013 год, напоминаю, это та же платформа, которая "вот только вчера появилась" ? Или ЛюксСофт каждые 4 года выпускает "уникальный продукт, у которого нет аналогов на рынке" ?

2) "Это собственная разработка специалистов компании «Люкс­Софт», которая является резидентом Парка высоких технологий. Решение пришло на смену торговой системе LS-Trade первого десятилетия 2000-х и еще более ранней торговой системе «Ветразь». Над ее разработкой несколько лет трудилась команда программистов и специалистов с экономическим образованием. Среди них немало победителей республиканских и международных олимпиад по программированию и математике, чемпионатов мира."
Тут про предыдущие решения компании и команду программистов-олимпиадников (CrushBY), которые похоже начали писать инновационную систему как раз во время дипломного года.

3) "Разработка LS Fusion в первую очередь осуществлялась компанией на основе богатого опыта собственных разработок и их внедрения, а также ориентировались на программные продукты Navision и разработки на базе1С. В новом продукте также учтены западные стандарты ведения торгового бизнеса, что удобно для компаний, планирующих выход на рынки за пределы Беларуси."
Тут вообще глупость страшная написана - ориентировались на разработки на базе 1С. В 2013 году. Не может такого быть. Это ж либо ориентировались на 1С, либо в рекламных целях примазывались к 1С, которой на рынке нет и клиенты ее не любят, что глупо.

Но каждый раз Bro с пеной у рта доказывает, что я все вру и просто им завидую.
   H A D G E H O G s
 
342 - 23.03.21 - 13:31
(337) Это называется "ввод в заблуждение". Предлагаю не уподобляться разработчикам lsFusion, как они это делают в своих статьях на Хабре.
   Вафель
 
343 - 23.03.21 - 13:33
по идее никакого разделения итогов не нужно.
ибо сама субд нормально отработает 2 транзакции update set остаток = остаток + приход.
   _DAle_
 
344 - 23.03.21 - 13:49
(341) Мы уже с вами столько раз это обсуждали, но давайте еще раз.

>2013 год, напоминаю, это та же платформа, которая "вот только вчера появилась" ? Или ЛюксСофт каждые 4 года выпускает "уникальный продукт, у которого нет аналогов на рынке" ?

Платформа, на которой делались и делаются решения, появилась давно. Но как продукт она оформилась только в последние годы. В открытый доступ платформа была выложена, наверное, не более двух лет назад. Рассказывать про нее тоже начали не так уж давно, первая статья на хабре, я сейчас посмотрел, появилась 2 июля 2019 года. Поэтому когда речь поднимается о каком-то коммьюнити, количестве проектов на платформе, сделанных не ЛюксСофтом, то нет смысла оперировать сроками в десять лет, потому что до позапрошлого года не было возможности использовать платформу кому-то извне.

> Тут про предыдущие решения компании и команду программистов-олимпиадников (CrushBY), которые похоже начали писать инновационную систему как раз во время дипломного года.
   mistеr
 
345 - 23.03.21 - 13:52
(341) Так вот откуда "ls", Люкс-Софт, значит. :)
Знатный бодишоп был в свое время.
   _DAle_
 
346 - 23.03.21 - 13:54
(341) Извиняюсь, случайно отправил сообщение раньше времени

> Тут про предыдущие решения компании и команду программистов-олимпиадников (CrushBY), которые похоже начали писать инновационную систему как раз во время дипломного года.

Первые коммиты в платформу были сделаны в 2008 году, в этом вы можете сами убедиться на гитхабе, это были еще коммиты в svn. Более-менее серьезная разработка началась в 2010 году (если я не прав, Bro меня поправит). Дипломный проект CrushBY был до всего этого :)

> Но каждый раз Bro с пеной у рта доказывает, что я все вру и просто им завидую.

Но вы на самом деле уже не раз проговаривали вещи, которые, мягко говоря, не соотвествуют действительности.
   _DAle_
 
347 - 23.03.21 - 13:55
(345) Не, тот называется Luxoft.
   YUN1
 
348 - 23.03.21 - 13:58
(346) Так вы постоянно врёте, так что, вам (разработчикам фузины) веры нет, по определению.
   mistеr
 
349 - 23.03.21 - 14:01
(347) А это не один хрен? Их что, несколько было?
   fisher
 
350 - 23.03.21 - 14:03
(339) Да. Согласен. Ввел в заблуждение. По методике 1С оптимистического контроля остатков при записи полагается налагать эксклюзивную управляемую блокировку без учета разделителя. Чтобы исключить параллельную запись и гарантировать не уход "в минус" при любых условиях.
Тогда контроль остатков в фузине таки получается более "автоматический" в части использования блокировок, чем в 1С.
   ta_da
 
351 - 23.03.21 - 14:04
(344)
> "Поэтому когда речь поднимается о каком-то коммьюнити, количестве проектов на платформе, сделанных не ЛюксСофтом, то нет смысла оперировать сроками в десять лет, потому что до позапрошлого года не было возможности использовать платформу кому-то извне."

Я ни слова не говорил про коммьюнити и количество проектов. Это Bro каждый раз рассказывает сказку про "инновационное решение, которому всего пара лет", и как вы с ним из-ниоткуда на рынок вышли и всех оттуда вытеснили.

> В открытый доступ платформа была выложена, наверное, не более двух лет назад
в году этак 12-13 точно был сайт с документацией и платформой, на ней предлагалось делать тестовое задание при устройстве на работу. Или что вы подразумеваете под "в открытый доступ" ?

> Дипломный проект CrushBY был до всего этого
ок, тут был не прав. смутно помню, в каком там году вы олимпиады выигрывали.

> Но вы на самом деле уже не раз проговаривали вещи, которые, мягко говоря, не соотвествуют действительности
Так какие, конкретно? Про диплом - был не прав. Постараюсь больше не упоминать, но если пропадете опять на пару лет - могу и забыть, да.
По "отжиманию рынка с нуля, за счет инновационного продукта" возражения по существу будут?
   Bro
 
352 - 23.03.21 - 14:04
(329) > Вы на рынке больше 20 лет.

И? Ну больше и больше, но до lsFusion у нас из крупных сетей клиентами были только Соседи.

> 2) Вашу систему преподают в государственных ПТУ, ее используют в государственной сети магазинов (ух, эти продажные псы режима).

Ее начали централизованно использовать уже когда lsFusion кучу где было внедрено. До этого было в паре РАЙПО, но основным поставщиком был Сервис-Плюс Супермаг, так что не знаете не надо говорить.

> 3) Вашу систему активно продвигают (продвигали?) продавцы фискального оборудования.

Нет, если вы не в курсе, основной игрок в плане оборудования на рынке крупных сетей - СервисПлюс у которого конкурирующий продукт Супермаг и который его очень агрессивно продвигает.

> 4) Даже название текущей системы делали похожим на название предыдущей. Интерфейс и логика работы - тоже повторены.

Издеваетесь? Вы по ходу LS Trade в глаза не видели, это диаметрально противоположные продукты. LS Trade куда больше на классические системы похож.

> Это все не плохо, но смешно читать про "вот какой у нас рост за последние N лет с нуля".

Ну так сами посчитайте. 2-6 крупнейших сети это:
Гиппо+Белмаркет
Санта
Виталюр
Соседи
Белкоопсоюз

Из них только Соседи были нашими клиентами до 2014 года. Остальные перешли именно на lsFusion и именно с других программ (предыдущие решения тут вообще не при чем они были совершенно другого класса и никак ту же Аксапту не заменили).

(341) Там маркетологом маркетинг буллшит написан. Только к чему это? Да lsFusion мы начали активно внедрять как внутренний продукт уже тогда, а год назад начали делать из него публичный.
   _DAle_
 
353 - 23.03.21 - 14:06
(349) Luxoft - это огромная московская (изначально) компания, Luxsoft.by (ЛюксСофт) - довольно небольшая белорусская. Они никак не связаны.
   Bro
 
354 - 23.03.21 - 14:08
(350) Ну строго говоря это подход не столько фузины, сколько вообще всех версионников. И одна из важных причин почему Оракл так распространился на рынке и почему даже MS SQL сделал такой режим у себя.

Фузина дополнила эту схему прозрачными материализациями и динамической физической моделью, что сделало ее использование еще более прозрачной / удобной.
   Bro
 
355 - 23.03.21 - 14:09
(343) Кстати вроде почитал, и похоже у версионников (того же Postgres) даже в таком случае при READ COMMITED изоляции "поплывут" остатки. Не говоря уже о контроле остатков.
   Bro
 
356 - 23.03.21 - 14:10
(340) Не ну если человек рефакторит типовую, то конечно респект ему. Только звучит как-то дико.
   H A D G E H O G s
 
357 - 23.03.21 - 14:13
(350) Никаких блокировок налагать не нужно, достаточно установить свойство БлокироватьДляИзменения=Истина набора записей РН, которое само все заблокирует.
   YUN1
 
358 - 23.03.21 - 14:17
(356) Почему сразу рефакторит? Он, может,свою нетленку пишет.
   fisher
 
359 - 23.03.21 - 14:18
(354) Я просто с диалектами DML не очень знаком. А как именно отрабатывает ON CONFLICT DO UPDATE?
Если конфликт таким образом разруливается только на уровне строки, то это же ничего не решает. Будет эффект аналогичный 1С, если записывать без блокировки.
А ты вроде упоминал полный откат и повторение транзакции?
   fisher
 
360 - 23.03.21 - 14:20
Тьфу. Про DML это я не в тему ляпнул :) Но вопрос остался.
 
 
   _DAle_
 
361 - 23.03.21 - 14:23
(351) >в году этак 12-13 точно был сайт с документацией и платформой, на ней предлагалось делать тестовое задание при устройстве на работу. Или что вы подразумеваете под "в открытый доступ" ?

Да, документацию действительно начали писать где-то году в 2012 и она была доступна. Насчет доступности платформы я что-то не уверен, разве что просто jar-файлом, чтобы на ней можно было что-то запустить, но тут я не помню точно. Про открытый доступ, я имею ввиду момент, когда появилась возможность легально использовать платформу. LGPL лицензия, судя по гитхабу, появилась в середине 2018, но какая-то информационная поддержка началась в 2019 после выпуска релиза.

>Так какие, конкретно?

Например, заявления о том, что все или почти все наши крупные клиенты - это просто переход с LS Trade / Ветразь на LS Fusion. Это не так, и это уже не раз тут звучало.
   fisher
 
362 - 23.03.21 - 14:29
(357) Я про суть происходящего, а не про синтаксис.
   ta_da
 
363 - 23.03.21 - 14:35
(361) я не заявлял что все или почти все клиенты это переход. Почитайте внимательно. Мои претензии к рассказам о том, как вы пришли с прототипом на занятый рынок и только из-за его совершенства и инновационности завоевали клиентов. Это не так.
   Злопчинский
 
364 - 23.03.21 - 14:40
жду WMS от фузиновцев. интересно будет пощупать.
   Bro
 
365 - 23.03.21 - 14:41
(357) https://xn----1-bedvffifm4g.xn--p1ai/news/2017-03-09-how-attribute-lock-to-change-works/

Что-то я прочитал про это БлокироватьДляИзменения (сразу скажу, что это же жесть какая-то, мозг вскипает, но на вкус и цвет фломастеры разные). С другой стороны это же по сути и есть ручная управляемая блокировка. То есть хрен редьки не слаще.

(359) > А как именно отрабатывает ON CONFLICT DO UPDATE?

Смотри как это работает. СУБД на момент старта транзакции запоминает некоторый счетчик транзакций (версии БД). Далее если в режиме REPEATABLE READ и выше при UPDATE оказывается что версия записи выше версии старта транзакции, кидается ошибка UPDATE CONFLICT, после чего транзакция откатывается и предполагается, что разработчик ее запускает заново. Естественно разработчик повесится писать везде эти перепроведения, поэтому в идеале этим должна заниматься платформа / фреймворк посередине.

На самом деле в таком случае гарантируется целостность только для материализованных данных. Но если материализованных данных много, то косвенно гарантируется и целостность остальных (то есть вероятность нарушения становится 0.000001%). Соответственно критичные данные материализуются (со 100% вероятность), а остальные могут возникать один раз в 15 лет. Ну и Postgres с его TRUE SERIALIZABLE утверждает что они даже эти раз в 15 лет убирает, но пока проверить не удалось, 15 лет не прошло.
   Bro
 
366 - 23.03.21 - 14:42
(363) А как? Мы действительно пришли с прототипом на занятый рынок и первые продажи были очень тяжелые из-за "где это работает?" (и хоть ты 120 лет на рынке). Зато потом все пошло как по накатанной, можно было возить к первым клиентам и все были просто в шоке от глубины и технологичности автоматизации.
   YUN1
 
367 - 23.03.21 - 14:45
(364) Вот тут соглашусь, их подход очень неплохо на эту задачу ложится. Но, вероятность того, что им задачи будут ставить грамотные в части складского учёта методологи, стремится к нулю, Имхо.
   fisher
 
368 - 23.03.21 - 14:46
(365) То есть де факто транзакции выполняются последовательно. И где тут параллельность?
   fisher
 
369 - 23.03.21 - 14:53
(365) А! Или такая проверка на уровне каждой записи? То есть конфликт возникает только если с момента начала транзакции кто-то поменял строку, которую хотим поменять мы. И в этом случае мы на уровне платформы запускаем автоматическую попытку перепроведения. Ну, звучит вроде неплохо в качестве общего дефолта.
   Bro
 
370 - 23.03.21 - 14:58
(369) Да естественно для каждой записи.

И транзакции как раз выполняются параллельно. До тех пор пока не возникнет race condition. Который возникает в условном 3% случаев. Да, в отличии от блокировочника, в этом случае будет выполняться лишняя работа по откату и повторению транзакции, но во первых нет необходимости а) выполнять дополнительную работу по накладыванию блокировок в остальных 97 процентах случаев б) исключить их эскалацию в) и что важнее deadlock'и (s/x) практически не возникают в таких случаях. А это все сильно влияет на производительность и масштабируемость решений. Из-за чего от автоматических блокировок скорее всего в 1С и отказались. Хотя по идее с отчетами в READ_COMMITTED_SNAPSHOT наверное и можно было бы жить:
  a) но тут конечно хз, как MS SQL работал бы с блокировочным SERIALIZABLE и READ_COMMITED_SNAPSHOT одновременно.
  b) Postgres нельзя было бы использовать.
   shuhard
 
371 - 23.03.21 - 15:06
(364) ты пропустил 1 серию холивара годичной давности
ERP и WMS предлагается разработать 1С-никам в свободное от работы время
своими силами фузинщики не потянули,
   Bro
 
372 - 23.03.21 - 15:13
(371) Не, вроде уже полгода как начали разработку, но я если честно не в курсе про ее статус. Вроде даже кому-то внедрять собирались, но опять таки это слухи :)
   fisher
 
373 - 23.03.21 - 15:15
(370) Не, мне такой дефолт нравится. Хороший компромисс. Практически идеальный для простых кейсов.
Не. Нельзя было в 1С жить на автоматических блокировках. Грязное чтение в отчетах как раз почти никого не смущало :)
А вот с SERIALIZABLE оказалась не жизнь а каторга.
   Малыш Джон
 
374 - 23.03.21 - 15:17
(0) Что-то каждая следующая ветка на эту тему всё унылее и унылее... Тоска...
   fisher
 
375 - 23.03.21 - 15:19
(374) Что поделать. Пропал эффект новизны. Подтягиваются только слоупоки вроде меня.
   fisher
 
376 - 23.03.21 - 15:25
(370) Управляемые блокировки в 1С тоже решили проблему эскалаций. И вообще фактически все проблемы уровня СУБД. Как разруливаются дедлоки на управляемых блокировках - вживую не видел. Может еще и потому, что в 1С предприняли ряд методологических шагов в сторону уменьшения их вероятности. Для простых кейсов в 1С получается чуток сложнее, это да. Но не ужас. В минус можно записать, но в небольшой. Зато для сложных кейсов - готовый простой инструмент (сложный в грамотном применении, но сам инструмент простой).
   Bro
 
377 - 23.03.21 - 15:39
(373) > Грязное чтение в отчетах как раз почти никого не смущало :)

А точно, забыл отчеты же в READ UNCOMMITED запускались до 8.2 ЕМНИП.

> А вот с SERIALIZABLE оказалась не жизнь а каторга.

Больше из-за дедлоков или эскалаций? Или из-за того и другого? Хотя в принципе я понимаю, перепроводишь инвентаризацию целиком и вся база в клинч входит. В версионниках то при этом просто одно ядро сжирается, но все продолжает работать.

Хотя справедливости ради в блокировочнике сильно конкурентная операция в конечном итоге пройдет, если повезет конечно с дедлоками (хоть и все курить будут все это время), а версионник будет перепроводить пока конкурентность не упадет. Но это все же меньшее из зол.

(376) > Управляемые блокировки в 1С тоже решили проблему эскалаций

Ну это кстати интересный вопрос, потому как блокировки MS SQL эскалировал не для развлечения, а когда их много становилось и содержать их становилось слишком дорого. Что в этом случае делает 1С (если в блокировку 10к записей из 500к попадает) я так и не понял.

> Может еще и потому, что в 1С предприняли ряд методологических шагов в сторону уменьшения их вероятности

Ну это и называется переложить ответственность на разработчика.

> сложный в грамотном применении, но сам инструмент простой

Ну здесь простота сомнительный плюс. Потому как везде (в той же Java) блокировки тоже теоретически простой механизм, но когда начинаешь моделировать все возможные race condition иногда хочется голову себе прострелить :)
   fisher
 
378 - 23.03.21 - 15:52
(377) В одинэсных кейсах эскалация при SERIALIZABLE работала очень жадно. Параллельность не обеспечивалась в большинстве случаев. По ряду причин.
В случае управляемых блокировок просто нет необходимости в "ковровых бомбардировках". Это же банально флаги с признаками. Их гранулярность изначально высока и полностью определяется бизнес-логикой. Необходимости в эскалациях нет как таковой.
> Ну это и называется переложить ответственность на разработчика.
Неточно выразился. На уровне платформы тоже были предприняты шаги. Например, чтобы регистры записывались документами всегда в одинаковой последовательности.
> Ну здесь простота сомнительный плюс.
Ну, какой есть. Мне идея управляемых блокировок очень нравится, так как дает с одной стороны простую, а с другой стороны универсальную сущность для решения любых проблем конкурентности. Да, это низкоуровневый примитив, зато универсальный, простой и максимально аккуратно укладываемый в бизнес-логику независимо от прихотей СУБД.
   mistеr
 
379 - 23.03.21 - 16:41
(378) Не будем забывать о том, что и платить за эту универсальность и простоту приходится цену немалую.
Например, отсутствием многострочного DML. То есть плохой масштабируемостью во многих сценариях.

Кстати, как с этим в Фузине? Использовать всю мощь СУБД в виде рпоизвольного SQL можно?
   fisher
 
380 - 23.03.21 - 16:53
(379) В Фузине с этим все хорошо :) Это же просто java-фреймворк без четких границ продукта.
Поэтому когда они говорят, что вот это и это делается проще чем в 1С, они всегда держат дулю в кармане. Потому что у них всегда есть пути отступления на более низкий уровень и поэтому краевыми случаями они могут пренебречь. Это по-своему прекрасно, но доля лукавства в этом есть. Ведь 1С отступать некуда (кроме как на ВК).
   Четвертинкин
 
381 - 23.03.21 - 17:03
(380) Эх, если бы разработчики фузины не были таким чудаками, и не стали пиарится на 1С, неплохая система в своей нише была бы.
   fisher
 
382 - 23.03.21 - 17:08
(367) Это ж надо! Волшебник всего на месяц забанил. Раньше он в эскалациях не стеснялся и гранулярность блокировок была куда выше :) Не иначе как либералы покусали. Хотя за ЗОЖ вроде по-прежнему рука не дрожит :)
(381) Ты так говоришь, как будто пиар на 1С принес им какой-то вред кроме пользы. Все они правильно делают.
   Четвертинкин
 
383 - 23.03.21 - 17:15
(382) Им, может, вред и не принёс, но карму они себе подпортили серьёзно. Поэтому, работать с ними если и будут, то маргиналы, вроде фиксина.
   rsv
 
384 - 23.03.21 - 17:20
Ветка об уровнях изоляции транзакций и способах
достижения оных .
Так что предпочтительнее  база на фузине обьемом с десяток террабайт  или 1с ?
Свертку базы не предлагать :)
   fisher
 
385 - 23.03.21 - 17:24
(383) Чушь. Где они себе испортили карму? У разрабов 1С? Смешно. Для тех полутора одинэсников, кто потенциально может заинтересоваться этими галерами, это никак не повлияет на принятие решения. А без своего маркетинга они бы и этих полутора не получили.
   fisher
 
386 - 23.03.21 - 17:25
Но одинэсники - это ведь вообще не целевая группа для их маркетинга. Одинэсники просто бесплатные хомячки для нагнетания хайпа.
   lmike
 
387 - 23.03.21 - 18:13
(256)  "сеньор 1сник не боится смерти платформы ибо выучит другой язык за полгода"
слово "сеньор" подразумевает человека с обширными знаниями, ему не надо учить языки, обычно они знает их несколько (из популярных) вместе с достоинствами и недостатками платформ на них представленных
но у него есть специализация, да
так же как и право выбора платформ (не одной, единственной) для решения задач, и представление о том как всё вместе должно жить
если только у 1Сников понятие "сеньор" какое-то своё... ;)
   Вафель
 
388 - 23.03.21 - 18:15
(387) чтобы выбирать другие платформы в штате должны быть специалисты по ней, а таких обычно нет
   Вафель
 
389 - 23.03.21 - 18:18
ну и у 1сников обычно один класс задач: гуй для доступа к бд
   polosov
 
390 - 23.03.21 - 18:37
(387) Вот не надо только чесать про "сеньоров знающих несколько языков". Это все равно такие у который один мэйн и пару "я немного ковырял и по аналогии могу с гуглом и стэковерфлоу сделать". Или максимум когда с жабы на котлин перешел и обоже стал сеньором.
   Четвертинкин
 
391 - 23.03.21 - 19:03
(385) Хм... А кто ещё есть на Мисте, кроме 1С-ников? Владельцы заводов, газет, пароходов? Среди кого тут реклама-то, кроме 1С-ников?
   Гений 1С
 
392 - 23.03.21 - 21:36
(382) мудреет человек, не мешай мудреть. ;-)
   NorthWind
 
393 - 23.03.21 - 22:04
(382) так после того как забаненных в 14-17 годах амнистировали, вернулась на форум хорошо если четвертая-пятая часть. Вспомните, что тут было лет 7 назад и сравните с тем что сейчас. Ну можно дропнуть оставшихся, че. И просто похоронить мисту.
   Злопчинский
 
394 - 24.03.21 - 00:01
(393) эээ, не надо! где еще будут пастись мохнатые клюшечники?
   fisher
 
395 - 24.03.21 - 10:11
(391) Основная площадка для пиара среди спецов - это хабр, как я понимаю. Ну а так как они с 1С сравниваются, надо же и в это болото палочкой потыкать. Им в плюс любая движуха.
   Vovan1975
 
396 - 24.03.21 - 10:23
(394) оживите форум дуба
   Четвертинкин
 
397 - 24.03.21 - 10:32
(395) Да чего-то на Хабре их статьи без упоминания 1С не особо популярны. Вот и лезут на Мисту, от безысходности, так как больше нигде и никто с ними разговаривать не хочет.
   Vovan1975
 
398 - 24.03.21 - 11:35
(395) хабр это вообще отличный пример отрицательного отбора. Сомневаюсь что там специалисты остались.
   Said_We
 
399 - 24.03.21 - 12:05
(14) "(13) а зачем ещё несколько тысяч костылей лепить? Может правильнее взять и переписать с нуля," - да назрела уже 9-ка с нуля. Всё равно конфигурации в рамках того же ЗиУП 3.1 уже не обновлениями иногда проходит, а переносом данных. Параллельные конфигурации ЗиУП и прочий бардак. 80% кода в 8.3 это переливание из пустого в порожнее. 20% полезного кода. На лицо что уже во что-то уперлись или не туда идут.
Сейчас что перейти на новую редакцию конфигурации в 8.3, что на 9-ку разницы по сложности практически не будет.

Сесть и писать что-то концептуально новое.

+Отказаться от файловой версии совсем - снять кучу технических ограничений. Маркетологи пусть придумывают как заменить файловую версию. Например, два или более видов ключей. Вместо файловой, какое-то ограничение по пользователям и если есть такой ключ вместо файловой. Соответственно менеджер лицензий должен различать разные ключи и разводить их использование разыми конфигурациями.
А то получается вместо, того что бы маркетологи 1С подумали мы имеем технический геморой.

Вообще 1С в последнее время как-то всё больше расстраивает. Нет стратегии развития. Метание в разные стороны и нигде до конца не продумано и всё это паралельно...

Нуралиевы уже не молоды. Все процессы наверняка замыкаются на них. Необходимо как-то делегировать управление процессами. Управлять процессами в 70 и 80 лет невозможно. А до этого возраста необходимо все процессы ещё и выстроить. Наследники, если они есть, в теме технических вопросов?
   polosov
 
400 - 24.03.21 - 12:16
(399) Платформа с нуля? ЗУП с нуля?
Это нереально. Даже если фузиновцев завалить деньгами, они что-то вменяемое по типу ЗУП будут несколько лет пилить. А потом еще несколько лет приводить в порядок и переписывать.
  1  2  3  4  5  6  7  8   

Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.