Комментарии 362
Вроде очевидно почему не 1С нет?
1С — устаревшая пародия на ЯП, которая используется 3 странами в мире и которую стоило уничтожить еще при создании.
1С — устаревшая пародия на ЯП, которая используется 3 странами в мире и которую стоило уничтожить еще при создании.
1С — устаревшая пародия на ЯП, которая используется 3 странами в мире и которую стоило уничтожить еще при создании.
Ну я бы не был настолько категоричен, некоторые неплохие идеи у них есть. Другое дело, что на мой взгляд развивалась 1С очень хаотично, как следствие накопился огромный технический долг. Соответственно, сейчас бы им полностью снести и разработать все заново с учетом накопленного опыта и ошибок, но огромное legacy и клиентская база на постсоветском пространстве им явно не даст это сделать.
Четвертьвековая история — это всё-таки не только недостаток, но и мощное конкурентное преимущество. Это огромная пользовательская база, причём бизнес-пользователей, которые не особо любят менять знакомый им софт на незнакомый. Это огромное количество готовых отраслевых решений, которые можно просто взять и использовать. Это налаженная сеть сбыта и поддержки, оперативное отслеживание изменений в законодательствах стран, и соответственно регулярный выход обновлений локализованных конфигураций и т.д.
К слову, последнее — вообще киллер-фича, которая для большинства клиентов намного важнее, чем все преимущества, указанные в вашей статье, вместе взятые.
К слову, последнее — вообще киллер-фича, которая для большинства клиентов намного важнее, чем все преимущества, указанные в вашей статье, вместе взятые.
Четвертьвековая история — это всё-таки не только недостаток, но и мощное конкурентное преимущество. Это огромная пользовательская база, причём бизнес-пользователей, которые не особо любят менять знакомый им софт на незнакомый. Это огромное количество готовых отраслевых решений, которые можно просто взять и использовать. Это налаженная сеть сбыта и поддержки, оперативное отслеживание изменений в законодательствах стран, и соответственно регулярный выход обновлений локализованных конфигураций и т.д.
Для бизнеса 1С — это безусловно преимущества. Для развития — это скорее ограничение. Вспомните Kodak, Nokia, Ford (не знаю кто тогда был лидер на рынке лошадей :) ), автогигантов да и вообще любую инновацию на рынке. Там все тоже самое было, понятно что и сети заправок, продаж, сервиса (ремонтов) везде первоначально были на несколько порядков лучше у текущих игроков. Но в этом и фокус, что если ты фундаментально отстаешь, вопрос времени когда ты проиграешь. Пусть не через год, и не через 10 или 20 лет, но проиграешь. Вон сейчас автогиганты пытаются гнаться за Tesla, понятно что они не умрут совсем, но догонят вряд ли. Собственно в том числе поэтому, сейчас Tesla оценивается как все остальные автопроизводители вместе взятые.
Тесла делает автомобили которые имеют все функции доступные другим автомобилям, плюс свою фишки. Человек при покупке теслы ничего не теряет, а только приобретает. Ваше решение пока такими свойствами не балует.
Предвосхищая ответ, что не все сразу делается, скажу что тесла смогла делать и продавать такие автомобили не благодаря тому что они такие хорошие и в неё поверили. В неё до сих пор просто вкладывают огромные деньги.
Вывод: Свергнуть монополиста можно только получив ресурсы соизмеримые с ним. Потихоньку это не сделать.
Предвосхищая ответ, что не все сразу делается, скажу что тесла смогла делать и продавать такие автомобили не благодаря тому что они такие хорошие и в неё поверили. В неё до сих пор просто вкладывают огромные деньги.
Вывод: Свергнуть монополиста можно только получив ресурсы соизмеримые с ним. Потихоньку это не сделать.
Человек при покупке теслы ничего не теряет, а только приобретает.
Человек владеющий теслой теряет возможность чинить её самостоятельно, даже в стороннем сервисе. Причем во многом из-за 'инновационной' политики самой теслы
Человек владеющий теслой теряет возможность чинить её самостоятельно, даже в стороннем сервисе.
Почему теряет? Теслы вполне себе ремонтируют, даже убитые в хлам:
www.youtube.com/watch?v=xJr5LRNq0fI
1) с полной потерей гарантии, без которой тесла мало кому нужный кусок железа
2) запчасти не продаются простым смертным
понятно что их ремонтируют из бу запчастей… но это такое себе… я на свой 20 летний рыдван без проблем могу купить практически любую новую деталь, причем 'родную', а не китайский клон, а на 5 летнюю теслу?
2) запчасти не продаются простым смертным
понятно что их ремонтируют из бу запчастей… но это такое себе… я на свой 20 летний рыдван без проблем могу купить практически любую новую деталь, причем 'родную', а не китайский клон, а на 5 летнюю теслу?
1) с полной потерей гарантии, без которой тесла мало кому нужный кусок железа
Хм. Вы точно так же потеряете гарантию, если поедете на неофициальную СТО на любом другом автомобиле. Я правда не совсем понимаю, чем потеря гарантии на Теслу отличается от потери гарантии на другие автомобили. Тесла без свежих прошивок хуже ездить станет, что ли?
2) запчасти не продаются простым смертным
Эм… с чего вы взяли? Я погуглил, вполне себе продаются, и новые, и б/у. Другой вопрос, что доступность так себе, но так и автомобиль нифига не распространённый. И «китайских клонов» пока что нет, что может быть даже недостатком, учитывая конские цены на оригиналы.
Эм… с чего вы взяли? Я погуглил, вполне себе продаются, и новые, и б/у
помоему писали что тесла не продает запчасти на авто на сторону, в принципе. это их модель обслуживания или ремонт по гарантии, или гуляй вася
и
чем потеря гарантии на Теслу отличается от потери гарантии на другие автомобили.
тем что вы не сможете её нигде кроме как в гаражном сервисе и с бу запчастями непойми кем чинить, я уж молчу о перепрошивке
сейчас я на своем 20-летнем крайслере могу приехат к официалам и сделать что угодно, заплатив правда адскую стоимость… но всёже. с теслой меня просто пошлют (насколько я понимаю их реалии с гарантией)
учитывая конские цены на оригиналы.
потому что их в черную продают
помоему писали что тесла не продает запчасти на авто на сторону, в принципе
Она продаёт их своим авторизованным партнёрам, а те вольны делать что угодно — использовать у себя, или продавать в розницу. В данном случае не идёт речь о том, что Тесла специально запрещает ремонтировать её автомобили третьим сторонам. У неё банально не хватает ресурсов обеспечить весь спрос :)
(насколько я понимаю их реалии с гарантией)
Что-то вы их как-то криво понимаете, не так как все остальные. По-гарантии сделают забесплатно. Нет гарантии — сделают за деньги.
Тесла делает автомобили которые имеют все функции доступные другим автомобилям, плюс свою фишки. Человек при покупке теслы ничего не теряет, а только приобретает. Ваше решение пока такими свойствами не балует.
Что значит ничего не теряет? Там тоже курица — яйцо было, когда например количество заправок измерялось десятками, против миллиона ДВС'ых, тоже самое касается сервисов / продаж и всего остального. Не говоря уже о том, что вы салон Тесла видели? Минимализм в чистом виде. Да и с надежностью по слухам там ерунда была (двери не закрывались). Но у них была главная вещь, фундаментально другая машина, с фундаментально другими характеристиками (например скорость разгона, шум, управляемость экологичность). Этого как правило достаточно, все остальное вопрос времени.
Предвосхищая ответ, что не все сразу делается, скажу что тесла смогла делать и продавать такие автомобили не благодаря тому что они такие хорошие и в неё поверили. В неё до сих пор просто вкладывают огромные деньги.
Вы причину со следствием путаете. Они смогли продавать такие автомобили, потому как сделали принципиально другой автомобиль, все остальное вторично (точнее следует из этого). Сделали бы они очередной ДВС никакие бы огромные деньги им не помогли. У Apple кстати тоже в свое время ресурсов было гораздо меньше чем у Nokia ЕМНИП. Да и Tesla начала относительно крупные инвестиции начала привлекать через семь лет и это в США (мекке инноваций и стартапов).
Ну и никто не спорит, что в какой то момент действительно практически всегда нужно привлекать ресурсы, но фаза Proof-of-concept и другие также очень важны, так как в это время ты максимально мобилен / пластичен и не «страдаешь» от кризиса роста.
Они смогли продавать такие автомобили, потому как сделали принципиально другой автомобиль
Вот это и есть заблуждение.
Чтобы продать автомобиль его нужно сделать. Если вы можете делать супер автомобили, но только 10 шт. в год, никакого лидерства вам не увидеть, даже если это супер автомобиль. Как пример печальный опыт DeLorean. Если бы денег в теслу не вложили, не было бы достаточного количество «зарядок», не было бы завода про производству нужного количества батарей. У теслы это все получилось только за счет очень активного «владельца». И деньги он вкладывал заработанные на совсем других вещах.
А Proof-of-concept вы уже показали, даже не только концепт, но и работающий бизнес уже есть.
Чтобы продать автомобиль его нужно сделать. Если вы можете делать супер автомобили, но только 10 шт. в год, никакого лидерства вам не увидеть, даже если это супер автомобиль. Как пример печальный опыт DeLorean. Если бы денег в теслу не вложили, не было бы достаточного количество «зарядок», не было бы завода про производству нужного количества батарей.
Немножко запутался. Понятно, что должна быть хотя бы теоретическая возможность производства продукта за ту стоимость, которая будет меньше чем преимущества, которые этот продукт дает. Если это есть, деньги найдутся рано или поздно. Зарядки и заводы это уже вторично.
Я не очень досконально изучал, как тесла удалось сделать автомобиль с пробегом в 400км на одной зарядке и с OPEX'ами в 120к (CAPEX'ы при таком громадном рынке и текущей стоимости денег не так важны) или около того. Но когда это стало осязаемым, дальше успех Тесла на мой взгляд был вопросом времени (но нет, я в них не вложился в свое время, так что это рассуждения в стиле «как моя жена после»).
Ну и работающий бизнес в определенной степени пока «внутренний» (в смысле indoor), сейчас главный вопрос как его (и можно ли) масштабировать «внешне» (outdoor) и это тоже своего рода Proof-of-Concept. Хотя конечно иметь при этом стабильный cash flow (даже с запасом), возможность для обкатки идей и т.п. безусловно приятный бонус, и позволяет не сильно переживать по поводу взлетит или не взлетит.
Вспомните Kodak, Nokia, Ford (не знаю кто тогда был лидер на рынке лошадей :)
Проблемы-то у них возникли не из-за груза накопленного опыта, а из-за грубых управленческих ошибок. Kodak сдохла, ненадолго пережив рынок фотоплёнок, а её прямой конкурент на том же рынке (кто-то помнит про Fujifilm?) с тех пор вырос раза в два, расширив ассортимент своих плёнок и найдя им новые применения. Nokia сдохла, а Самсунг только вырос.
Это как бы ни о чём конкретном не говорит, просто о том, что успех/поражение 1С лежит в другой плоскости, отнюдь не технологической. Покупать бизнес-приложения будут не ИТ-шники, а менеджеры. И смотреть они будут не на то, какая там внутри красивая объектная архитектура, и как эффективно работает внутренний ORM, а на то, насколько система соответствует текущим потребностями бизнеса «из коробки», насколько она понятна пользователям, какие риски внедрения и т.д.
Проблемы-то у них возникли не из-за груза накопленного опыта, а из-за грубых управленческих ошибок.
Это проблема всех корпораций. По факту все инновации идут за их пределами, так как корпорации слишком инертные. Да и им проще потом купить выскочек, чем самим делать (хотя понятно, что с гуглом, фейсбуком, теслой это например не прокатило, а скажем с инстаграммом или ютюбом прокатило).
И смотреть они будут не на то, какая там внутри красивая объектная архитектура, и как эффективно работает внутренний ORM, а на то, насколько система соответствует текущим потребностями бизнеса «из коробки», насколько она понятна пользователям, какие риски внедрения и т.д.
Так и в тесле люди не на двигатель (под капот) смотрят, но именно двигатель дает тесле преимущества, с которыми ни один ДВС не может соревноваться (хотя повторюсь мало кто из пользователей знает что под капотом).
но именно двигатель дает тесле преимущества, с которыми ни один ДВС не может соревноваться
Именно так. Но в случае бизнес-софта, его двигатель — не «программный движок», а функционал, известность, саппорт и доступность специалистов на рынке.
Это с чего вдруг? Функционал, известность, саппорт и доступность специалистов на рынке это кузов / салон авто, бренд, СТО, заправки и наличие механиков. А двигатель это как раз платформа.
То есть с теслой тоже самое было. Где вы ее заправлять будете, где чинить, вы же за город выедете и встанете, она сырая и все такое. Но как обычно инноваторы, early adopter'ы и пошло поехало. Но конечно они это на самой благодатной почве делали — в Калифорнии. В Омске им бы конечно посложнее было :)
То есть с теслой тоже самое было. Где вы ее заправлять будете, где чинить, вы же за город выедете и встанете, она сырая и все такое. Но как обычно инноваторы, early adopter'ы и пошло поехало. Но конечно они это на самой благодатной почве делали — в Калифорнии. В Омске им бы конечно посложнее было :)
Это с чего вдруг? Функционал, известность, саппорт и доступность специалистов на рынке это кузов / салон авто, бренд, СТО, заправки и наличие механиков. А двигатель это как раз платформа.
Это всё образно, конечно, но «двигатель» — то, что решает задачи. У автомобиля задача перевозить пассажиров/грузы. У бизнес-софта задача автоматизировать работу предприятий. Поэтому у автомобиля двигатель вот та штука, которая крутит колёса, у бизнес-софта двигатель — формочки и люди. Красивая внутренняя объектная модель, с которой сталкиваются только программисты, в мире автомобилей — это удобная компоновка подкапотного пространства для быстрого обслуживания. Да, автомеханики такое одобряют, но согласитесь, эта штука крайне слабо влияет на конкурентоспособность той или иной машины на рынке.
Так же и с софтом. Вы вполне успешно продадите такое:
«Наша система позволяет вести партионный учёт, считает себестоимость по FIFO, LIFO, по среднему, умеет вести SKU, интегрируется с… » и так далее.
Но вы никому, кроме небольшой горстки контор, в которых ИТ-директор напрямую лезет в коммерческие вопросы, не продадите: «Наша система имеет эффективный ORM, модульную архитектуру...»
То есть с теслой тоже самое было. Где вы ее заправлять будете, где чинить
С Теслой было не то же самое. Выходя на рынок, они вкинули кучу денег, решив вопросы «где заправлять» и «где чинить».
Так же и с софтом. Вы вполне успешно продадите такое:
«Наша система позволяет вести партионный учёт, считает себестоимость по FIFO, LIFO, по среднему, умеет вести SKU, интегрируется с… » и так далее.
Все зависит от того, что именно считать продуктом на этом рынке. Время «коробок» ушло на постсоветском рынке (и продолжает уходить). Сейчас ИТ-решения это не более чем полуфабрикат (или конструктор), основное в них не то, что есть там изначально (это всего лишь средство, один из факторов), а как это решение можно адаптировать под конкретного заказчика, внедрить в нем все его know how, сделать это бесшовно без рисков остановки бизнеса, а главное чтобы решение постоянно изменялось вместе с бизнесом, адаптируясь под новые идеи и пути развития бизнеса. На западе рынок давно пришел к этому («САП невозможно внедрить, его можно перестать внедрять»), и на постсовестком рынке последние лет 5 тоже (собствено у всех уже как-то что-то автоматизировано, а рынок экстенсивно не растет).
Соответственно в такой парадигме двигатель это именно платформа, то есть то насколько решение будет гибким, модульным и быстро и легко дорабатываться без накопления технического долга.
С Теслой было не то же самое. Выходя на рынок, они вкинули кучу денег, решив вопросы «где заправлять» и «где чинить».
Ну тут мне кажется перепутано причина со следствием, это было одновременно (сначала люди не знали где заправлять и чинить, но все равно покупали из-за инноваций), но постепенно появилось и то и другое. То есть не то что Тесла сначала настроило миллион заправок и обучила миллион техников, а только потом смогла продавать.
Время «коробок» ушло на постсоветском рынке (и продолжает уходить). Сейчас ИТ-решения это не более чем полуфабрикат (или конструктор), основное в них не то, что есть там изначально (это всего лишь средство, один из факторов),
Нет, как раз наоборот. Коробки потеснились (и будут дальше тесниться) онлайн-сервисами, а покупки бессрочных лицензий потеснились подписками. Но спрос на готовые решения только растёт, а спрос на кастомизацию наоборот, падает. Кастомизация — это потребность среднего и крупного бизнеса. 99% остальных заказчиков покрывают все свои потребности типовыми конфигурациями.
То есть не то что Тесла сначала настроило миллион заправок и обучила миллион техников
Они это начали делать одновременно. Ну т.е. первые пользователи Теслы уже имели доступ и к заправкам, и к обслуживанию. Впрочем, с точки зрения маркетинга, действительно первая небольшая волна пользователей-«визионеров» вполне могут потерпеть некоторые недостатки ради общей технологичности продукта. Но съем сливок с продаж происходит отнюдь не от этой волны.
Нет, как раз наоборот. Коробки потеснились (и будут дальше тесниться) онлайн-сервисами, а покупки бессрочных лицензий потеснились подписками. Но спрос на готовые решения только растёт, а спрос на кастомизацию наоборот, падает. Кастомизация — это потребность среднего и крупного бизнеса. 99% остальных заказчиков покрывают все свои потребности типовыми конфигурациями.
Теперь совсем запутался. То что ниша ИТ-решений малого (!) бизнеса постепенно замещается в основном онлайн-сервисами с этим никто не спорит. Но это не про ERP-платформы (и ни про 1С, Dynamics, ни про lsFusion) вообще. В онлайн сервисах не важны ни разработчики (так как нет кастомизации) ни франчи (так как продажи собственно идут онлайн через соотвествующие каналы). Тут важнее интуитивность полученного продукта (material design, документированность причем прямо внутри продукта, то есть всякие подсказки и т.п.), А ИТ-решение для среднего и крупного бизнеса сейчас это именно и только про кастомизацию.
Плюс важный момент- то что во всяком случае на постсоветском пространстве бизнес консолидируется (вертикально — федерально и / или регионально и горизонтально — когда сети например начинают и производством и оптовой и интернет торговлей заниматься) и соответственно все смещается в сторону среднего и крупного бизнеса. А значит спрос на готовые решения наоборот скорее падает, и это очень кстати хорошо видно, если посмотреть по ЕГРЮЛ обороты поставщиков именно коробочного софта в разных нишах.
К слову например если взять белорусский рынок, то скажем в ИТ для банковской сферы есть две компании обороты и количество сотрудников, которых превышает обороты и количество всех 1С франчайзеров вместе взятых. А эти компании только и занимаются что «кастомизацией».
Они это начали делать одновременно. Ну т.е. первые пользователи Теслы уже имели доступ и к заправкам, и к обслуживанию
Ага только по сравнению с ДВС там выбор был ультраограниченный.
Но съем сливок с продаж происходит отнюдь не от этой волны.
Ну это как бы очевидно, но не понятно какое отношение имеет к тому, о чем мы разговариваем.
В онлайн сервисах не важны ни разработчики (так как нет кастомизации) ни франчи (так как продажи собственно идут онлайн через соотвественно).
Ваши представления об онлайн сервисах устарели. Например, QuikBooks Online, Xero, 1С Fresh предлагаю возможность покупки дополнительных модулей и расширений от партнеров и заказную разработку этих модулей.
Ваши представления об онлайн сервисах устарели. Например, QuikBooks Online, Xero, 1С Fresh предлагаю возможность покупки дополнительных модулей и расширений от партнеров и заказную разработку этих модулей.
Я в курсе, но это уже тогда PaaS'ы (то есть по сути хостинг) и к классическим онлайн-сервисам имеют опосредованное отношение. И явно не то что автор того, на что я отвечал, имел ввиду.
Не согласен, это все же именно SaaS. Просто вопрос кастомизации SaaS решений многие ставят в приоритет и для той же 1С это одна из ключевых вещей. Поэтому технология расширений у них развивается очень быстро сейчас.
Подождите, важная часть SaaS это multi-tenancy, а если есть доработки (где с multi-tenancy очень много вопрос), то это чистый PaaS и скорее ближе к хостингу. Ну и собственно весь смысл в SaaS это отсутствии тесного контакта с клиентом (в том числе, например, за счет интуитивности интерфейсов и всяческих подсказок), а доработки это как раз классическая модель рынка бизнес-приложений.
И как бы 1С не развивали технологию расширений, но когда все сделано на SQL запросах, но при этом жестко императивно в строках без оптимизатора, когда нет полиморфизма, эти расширения по определению будут очень ограниченными (собственно такая проблема с модульностью яркий тому пример). Уж точно далеко для подходов используемых в lsFusion.
И как бы 1С не развивали технологию расширений, но когда все сделано на SQL запросах, но при этом жестко императивно в строках без оптимизатора, когда нет полиморфизма, эти расширения по определению будут очень ограниченными (собственно такая проблема с модульностью яркий тому пример). Уж точно далеко для подходов используемых в lsFusion.
Ну, вот тут вам стоит изучить тему расширений в 1С. Ранее это была возможность катамизировать только код и формочки в multi-tenancy, сейчас же уже можно добавлять новые таблицы (справочники, документы, регистры), добавлять реквизиты и табличные части к существующим документам и справочникам. И все это платформа 1С автоматически обрабатывает на уровне СУБД (создает поля, таблицы и т.д.) в зависимости от подключенных расширений. А их может быть десятки.
Так же магазин расширений и аддонов для учетной SaaS системы это по сути must-have. Без этого конкурировать с Intuit и Xero нет шансов на том же рынке США.
А проблема с модульностью — это проблема на уровне методологии самих продуктов (БП, ЗУП, ERP), разработанных на платформе 1С. Компания пытается как-то двигаться в эту сторону, но слишком уж ресурсоемко это.
Так же магазин расширений и аддонов для учетной SaaS системы это по сути must-have. Без этого конкурировать с Intuit и Xero нет шансов на том же рынке США.
А проблема с модульностью — это проблема на уровне методологии самих продуктов (БП, ЗУП, ERP), разработанных на платформе 1С. Компания пытается как-то двигаться в эту сторону, но слишком уж ресурсоемко это.
Я знаю что такое расширения и упоминал несколько раз в своих статьях.
Нужно понимать, что:
а) во-первых, расширения это частный случай модульности, когда у вас основное решение — один модуль, а расширение — еще один модуль зависящий от этого модуля. Поэтому в идеальной системе должна быть не только возможность добавлять свои модули, но и выключать существующие модули и / или выбирать между ними.
б) в императивных языках возможности расширений очень ограничены (тут я писал об этом). Критически важно уметь расширять запросы, иметь событийную архитектуру, полиморфизм и т.п. (вот тут я приводил примеры этой проблематики и человек мне так ничего и не ответил на них)
И если бы вы чуть больше погрузились в lsFusion, то поняли бы что в плане расширений / модульности lsFusion превосходит существующие технологии на порядок. Впрочем, естественно, никто не мешает вам «подождать на берегу», пока время подтвердит или опровергнет этот тезис :)
Нужно понимать, что:
а) во-первых, расширения это частный случай модульности, когда у вас основное решение — один модуль, а расширение — еще один модуль зависящий от этого модуля. Поэтому в идеальной системе должна быть не только возможность добавлять свои модули, но и выключать существующие модули и / или выбирать между ними.
б) в императивных языках возможности расширений очень ограничены (тут я писал об этом). Критически важно уметь расширять запросы, иметь событийную архитектуру, полиморфизм и т.п. (вот тут я приводил примеры этой проблематики и человек мне так ничего и не ответил на них)
И если бы вы чуть больше погрузились в lsFusion, то поняли бы что в плане расширений / модульности lsFusion превосходит существующие технологии на порядок. Впрочем, естественно, никто не мешает вам «подождать на берегу», пока время подтвердит или опровергнет этот тезис :)
Теперь совсем запутался. То что ниша ИТ-решений малого (!) бизнеса постепенно замещается в основном онлайн-сервисами с этим никто не спорит
И среднего. Малый и средний бизнес — это как раз тот рынок, на котором снимает сливки 1С и большая часть продуктов Dynamics, и там же есть шансы проявить себя и вашему продукту, если вы предложите качественные готовые решения, либо создадите хорошую команду продажников, которая будет персонализированно продвигать ваш продукт среднему бизнесу. Крупному же бизнесу вам пока предложить банально нечего.
Что касается онлайна, то да, это тренд, тренд логичный и ожидаемый. Собственно, не зря Dynamics прочно ушёл в облако, и 1С движется туда же.
А средний бизнес это какой? Вот у нас сейчас основные клиенты это компании с 4-10к сотрудников и 200-500 млнов долларов в год оборотами. И основное что мы им продаем это как раз то что я писал в этом комментарии. То есть набор модулей из которых собирается решение, но что главное непрерывную реализацию всех хотелок с космической скоростью без накапливания технического долга (собственно у нас по сути на этом рынке в этом плане непонятно кто вообще конкуренты, потому как вести столько проектов одновременно в agile практически никто не может). Сейчас у нас процентов 70 крупного ритейла Беларуси и я думаю в течении ближайших 5-10 лет мы еще больше увеличим эту долю. И все это на мой взгляд именно благодаря платформе (всем этим 30 пунктам этой статьи). Это достаточно уникальное value который мало кто на рынке может предложить.
А рынок готовых решений судя по оборотам в ЕГРЮЛ соответствующих компаний (и общению с ними) наоборот сильно сужается, так как большинство как-то уже автоматизированы и на самом деле по опыту единственный вариант им что-то внедрить, это: внедрить as is с непрерывной интеграцией, после чего превратить в to be из смеси а) того что есть у тебя, б) то что всегда хотел заказчик, но у него не было, в) оставить то что есть, что себя уже зарекомендовало. Ну а дальше непрерывный цикл доработок по agile в рамках новых идей / изменений бизнеса и т.п.
А рынок готовых решений судя по оборотам в ЕГРЮЛ соответствующих компаний (и общению с ними) наоборот сильно сужается, так как большинство как-то уже автоматизированы и на самом деле по опыту единственный вариант им что-то внедрить, это: внедрить as is с непрерывной интеграцией, после чего превратить в to be из смеси а) того что есть у тебя, б) то что всегда хотел заказчик, но у него не было, в) оставить то что есть, что себя уже зарекомендовало. Ну а дальше непрерывный цикл доработок по agile в рамках новых идей / изменений бизнеса и т.п.
Стоит упомянуть, что у 1С направление розницы развито не столь сильно. В это отрасли у 1С есть крупные внедрения, но вот продукта, который мог бы стать столь же конкурентно способным, как ERP, БР и ЗУП нет. Пока нет.
Так же вам на руку то, что вы начали с Белоруссии и уже имея клиентскую базу и продукт, обкатанный на ней, заходите на другие рынки.
Так же вам на руку то, что вы начали с Белоруссии и уже имея клиентскую базу и продукт, обкатанный на ней, заходите на другие рынки.
Насколько я могу судить по работе с SMB и Eterprise, то бизнес в первую очередь ищет коробку. Желательно с возможностью быстрой и дешевой кастомизации. И только если нет коробок, удовлетворяющих потребностям бизнеса на приемлемом уровне, уже смотрят в сторону разработки кастомных решений либо силами вендоров, либо силами своего ИТ отдела. А для SMB кастомная разработка вообще недоступна в 99% случаев, у них просто нет столько денег.
А я и не говорю про «разработку кастомных решений». Я как раз говорю про ультрамодульные решения (где из модулей как из кубиков собирается каркас), а потом дорабатывается «as is», а потом непрерывно меняется под «to be» / новые направления / идеи. И в том насколько это возможно быстро и дешево делать, платформа играет важнейшую роль.
Ну и вы правильно заметили, что у малого и среднего бизнеса не то что нет потребности работать по такой модели, а именно что нет денег. Но это опять таки вопрос к платформе, насколько дешевой у вас получится доработка / крупноблочная разработка на ней.
Ну и вы правильно заметили, что у малого и среднего бизнеса не то что нет потребности работать по такой модели, а именно что нет денег. Но это опять таки вопрос к платформе, насколько дешевой у вас получится доработка / крупноблочная разработка на ней.
Наличие готовых модулей — это и есть коробочное решение. Не важно, сколько этих модулей — один или тысяча. Дальше стоит вопрос стоимости внедрения, сопровождения и кастомизации.
Ну не знаю, в моем понимании коробочное решение это нажал кнопку установить, потыкал пару галочек и работай. А конструктор это набор некоторых блоков, из которых ты выбираешь часть ( часть которых опять-таки приходится изменять), часть блоков разрабатываешь (ЕМНИП даже САП утверждает, что у них пропорция где-то процентов 60-70 готовых с кастомизацией глубиной процентов 30 + 30-40 абсолютно новых). Но если доработка / добавление подвержены сильному техническому долгу (а это определяется платформой), то даже если у вас и 90 процентов готовых модулей, то в конечном итоге может быть дешевле вообще все с нуля сделать.
Коробочное решение — это именно готовый продукт в части бизнес логики. Модульность, как уже сказал, не особо влияет на это. Можно рассмотреть решение 1С (где с модульностью откровенно беда на уровне типовых решений), SAP (где модульность довольно развита, есть десятки модулей) и ваше (где сотни модулей, по вашим заявлениям). Все это коробки. Т.е. в идеале коробка не требует кастомизация, а только настройки модулей, загрузки НСИ, обучение и в путь.
Разработка своего будет дешевле коробки только в том случае, если подходящей коробки совсем уж нет. Либо собственное решение было ранее и требуется переход на коробку. Разработка любого серьезного решения для учета — это зачастую миллионы человеко-часов.
Разработка своего будет дешевле коробки только в том случае, если подходящей коробки совсем уж нет. Либо собственное решение было ранее и требуется переход на коробку. Разработка любого серьезного решения для учета — это зачастую миллионы человеко-часов.
У вас почему-то две крайности получается. Либо коробка (причем без модульности у вас может быть много лишних данных и проверок, которые придется заполнять или которые просто будут убивать эргономичность), либо разработка с нуля. Хотя очевидно, что идеальное решение это крупноблочное строительство с доработкой отдельных блоков и разработкой недостающих. И модульность с возможностями рефакторинга / быстрой и простой разработки тут выходят на первый план.
Почему же две крайности? Мы обсуждаем, что есть коробочное решение. А кастомизация — это отдельный вопрос. В том или ином виде кастомизация идет, думаю, у 90% пользователей 1С, хотя бы на уровне внешнего отчета или обработки с Инфостарта.
Вы же понимаете, что бизнесу фиолетово коробочное решение или нет. Ему нужно решить свои проблемы (то есть получить ИТ-систему которая будет эффективно автоматизировать именно его процессы, как текущие так и будущие) быстро / дешево / с минимальными рисками. А будет это 100% коробочное решение, 60% коробочное 40% доработки, или 100% разработки, уже дело десятое. Если опять-таки устроит бизнес по срокам и стоимости (так например некоторые бизнесы готовы ждать, некоторые нет и т.п.)
Естественно. Любой бизнес оценивает систему с точки зрения стоимости внедрения, стоимости владения, рисков и возможности удовлетворить потребности бизнеса.
Кстати, именно по этой причине нередко даже очень большие компании используют полностью кастомную разработку именно на 1С, так как: это недорого (лицензии 1С стоят копейки, хоть и не бесплатно), учет автоматизируется очень быстро (может и не как в IsFusion, тут сравнить не могу) и, главное, рынок разработчиков 1С — это более 100 тысяч специалистов. Т.е. нет риска оказать без кадров и возможности сопровождать решение.
Кстати, именно по этой причине нередко даже очень большие компании используют полностью кастомную разработку именно на 1С, так как: это недорого (лицензии 1С стоят копейки, хоть и не бесплатно), учет автоматизируется очень быстро (может и не как в IsFusion, тут сравнить не могу) и, главное, рынок разработчиков 1С — это более 100 тысяч специалистов. Т.е. нет риска оказать без кадров и возможности сопровождать решение.
очень большие компании используют полностью кастомную разработку
Согласен, даже рынок полного custom made никто не отменял.
Т.е. нет риска оказать без кадров и возможности сопровождать решение.
Ну строго говоря для этого 100к разработчиков не надо. Одного десятка компаний сведет риск к минимальному, и на первое место выйдут уже первые два упомянутых вами фактора: качество платформы и TCO (затраты на покупку ОС, СУБД, платформу, оборудования и т.п.). Плюс важный момент — порог входа, если он очень низкий это даже может дать большие преимущества чем наличие большого количества специалистов (где их может быть много но все равно дефицит)
Одного десятка компаний точно не хватит. Если только вы планируете существовать на уровне пары сотен клиентов, из которых будет не более нескольких десятков действительно крупных.
Ну а про порог входа в 1С не шутит разве ленивый, именно поэтому и появилась возможность наращивать такую ораву разработчиков (что может быть несколько странным при довольном низком уровне развития самого языка).
Ну а про порог входа в 1С не шутит разве ленивый, именно поэтому и появилась возможность наращивать такую ораву разработчиков (что может быть несколько странным при довольном низком уровне развития самого языка).
Одного десятка компаний точно не хватит. Если только вы планируете существовать на уровне пары сотен клиентов, из которых будет не более нескольких десятков действительно крупных.
Да ладно. У того же SAP наверное около одного или нескольких десятков компаний в России, которые реально могут его поддерживать (а не просто значатся в списке партнеров), а если взять количество сотрудников в компаниях, которые работают на SAP, то это количество будет соизмеримо с компаниями работающими на 1С. Ну и у самого 1С, насколько я видел топ-5 франчайзеров покрывают наверное минимум 30 процентов рынка (в Беларуси так точно такая ситуация).
Ну а про порог входа в 1С не шутит разве ленивый
Ну так это в 7.7 было. И то она гораздо менее декларативна чем тот же lsFusion была. А в 8.3 с их управляемыми блокировками, РеквизитамиФормыВЗначение, &НаСервереБезКонтекста, сотней всяких избыточных абстракций и т.п., порог входа уже выше чем в .Net или условный Python (Odoo).
А возможность наращивать ораву появилось скорее из-за того что они Бух и ЗУП консолидировали. Ну и да простота и бесплатность (пиратство) 7.7. помогли.
Скажем, у SAP есть большая фишка — интернациональность. На РФ точно могут работать все компании СНГ (ваши земляки из EPAM тому пример), а так же из любой страны Европы. Судить о квалификации всех 40+ партнеров в РФ не могу.
По поводу количества автоматизированных рабочих мест, последнее, что я видел — это 80+% рабочих мест автоматизированы с помощью 1С.
По порогу вхождения надо смотреть больше не написание кода, а на решение типовых учетных задач. Та же 1С позволяет накидать простую рабочую систему практически без написания кода. Так же есть большой рынок обновлений и простых доработок, которые позволяют зайти в профессию с максимально легких задач (сам так начинал).
Думаю, главная причина в создании такого рынка — это инфраструктура франчайзи в купе с тем, что решения 1С стали стандартом де-факто для SMB в РФ.
По поводу количества автоматизированных рабочих мест, последнее, что я видел — это 80+% рабочих мест автоматизированы с помощью 1С.
По порогу вхождения надо смотреть больше не написание кода, а на решение типовых учетных задач. Та же 1С позволяет накидать простую рабочую систему практически без написания кода. Так же есть большой рынок обновлений и простых доработок, которые позволяют зайти в профессию с максимально легких задач (сам так начинал).
Думаю, главная причина в создании такого рынка — это инфраструктура франчайзи в купе с тем, что решения 1С стали стандартом де-факто для SMB в РФ.
Скажем, у SAP есть большая фишка — интернациональность. На РФ точно могут работать все компании СНГ (ваши земляки из EPAM тому пример), а так же из любой страны Европы. Судить о квалификации всех 40+ партнеров в РФ не могу.
Ну по такой логике и Odoo превосходит 1С по числу разработчиков, только в РФ это им не так сильно помогает (хотя и помогает). Собственно SAP хороший пример, что на самом деле даже 40 партнеров (из которых наверное половина бутафорских) более чем достаточно.
По поводу количества автоматизированных рабочих мест, последнее, что я видел — это 80+% рабочих мест автоматизированы с помощью 1С.
В таких случаях обычно эти рабочие места выполняют самые примитивные процессы, а вся сложность и кастомизация все равно в том же SAP. Но например если взять Топ-30 розничных сетей, там большинство все же SAP и местные какие-то самописки.
По порогу вхождения надо смотреть больше не написание кода, а на решение типовых учетных задач. Та же 1С позволяет накидать простую рабочую систему практически без написания кода. Так же есть большой рынок обновлений и простых доработок, которые позволяют зайти в профессию с максимально легких задач (сам так начинал).
Не совсем понял. Все типовые же сейчас на УФ, управляемых блокировках и т.п. Чтобы там что-то дорабатывать нужно понимать «кто все эти люди». Даже если речь о простеньких отчетах, тот же СКД по сложности уже превосходит любую Reporting system, так как туда намешали дикое количество функционала (той же аналитики, которая обычно идет в отдельных контурах).
То есть чтобы ковыряться в том же УТ или БУХ сейчас, нужно иметь очень неслабый уровень интеллекта и опыта, а это как бы основные (самые распространенные) продукты у 1С.
Думаю, главная причина в создании такого рынка — это инфраструктура франчайзи в купе с тем, что решения 1С стали стандартом де-факто для SMB в РФ.
Именно. Причина распространенности такая же как у SAP — «давно тут сидим» ©. Только опять-таки после какого-то уровня (на примере того же SAP) количество разработчиков уже не играет такой роли, а скорее наоборот позволяет дифференцировать себя на рынке (например, не знаю как сейчас, но раньше ABAP разработчики ценились выше 1С, потому как были более редкими).
Хотя как правильно кто-то отмечал ниже, наверное самый простой способ победить 1С, получить распостранение на мировых рынках и сыграть на «чемоданческих настроениях». Во всяком случае по опыту, сейчас так Odoo двигается на российском рынке.
Вы делаете слишком много домыслов. Лучше воздержаться от этого.
А у Odoo, в целом, все нормально в планетарном масштабе. Как понимаю, главная проблема — это отсутствие хорошего продукта для реалий РФ. Найдется партнер и инвестор, будет продукт. Но риски большие не пробиться на оооочень плотный рынок РФ (особенно корпоративный сектор).
По сложности. Если говорить о глобальных доработках, то, действительно, непросто разобраться в первую очередь в самих типовых. Но большая часть кастомизации — это отчетики, печатные формы, АРМ и прочие простые вещи. А СКД в большинстве случаев позволяет за 5 минут накидать очень функциональный отчет, не углубляясь в дебри всех возможностей СКД.
Ну, с распространением на мировых рынках можно только пожелать удачи :) Это будет не сильно проще СНГ и РФ.
На самом деле, у вас есть реально хороший и работающий продукт для розницы, т.е. вы заняли нишу, где у 1С нет сильной линейки продуктов, а тяжеловесы SAP, Oracle и Microsoft хоть и предлагают настоящие best-practices в своих решениях, но делают это за негуманный ценник.
А у Odoo, в целом, все нормально в планетарном масштабе. Как понимаю, главная проблема — это отсутствие хорошего продукта для реалий РФ. Найдется партнер и инвестор, будет продукт. Но риски большие не пробиться на оооочень плотный рынок РФ (особенно корпоративный сектор).
По сложности. Если говорить о глобальных доработках, то, действительно, непросто разобраться в первую очередь в самих типовых. Но большая часть кастомизации — это отчетики, печатные формы, АРМ и прочие простые вещи. А СКД в большинстве случаев позволяет за 5 минут накидать очень функциональный отчет, не углубляясь в дебри всех возможностей СКД.
Ну, с распространением на мировых рынках можно только пожелать удачи :) Это будет не сильно проще СНГ и РФ.
На самом деле, у вас есть реально хороший и работающий продукт для розницы, т.е. вы заняли нишу, где у 1С нет сильной линейки продуктов, а тяжеловесы SAP, Oracle и Microsoft хоть и предлагают настоящие best-practices в своих решениях, но делают это за негуманный ценник.
Вы делаете слишком много домыслов. Лучше воздержаться от этого.
Рынок информационных систем он такой. Ни у кого нет общей картины, все сплошные обобщения личного опыта и гипотезы (просто потому что рынок очень большой и неоднородный)
Но большая часть кастомизации — это отчетики, печатные формы, АРМ и прочие простые вещи.
Давайте не смешивать. Отчетики и печатные формы в любой технологии достаточно несложная вещь. Я видел как люди к коробочным решениям на Oracle сбоку подключались и лепили там отчеты на CrystalReports. Порог входа при этом очень низкий в любой технологии. Плюс не забываем про навернутые BI, где пользователи много отчетов сами могут делать.
АРМам (а они ввод предполагают) как раз надо вот это вот все — управляемые формы, управляемые блокировки, как правильно условия для динамических списков писать и т.д. и т.п.
То есть про порог входа, это не личное мнение, а в том числе мнение многих 1С разработчиков, что та же УТ сейчас настолько сложной стало, что лезть туда уже мало кто хочет (а многие даже с 7.7 по этой причине не хотят уходить, так как она гораздо проще).
но именно двигатель дает тесле преимущества, с которыми ни один ДВС не может соревноваться
Тойота продаёт приус уже почти четверть века. Он не имеет проблемы с зарядками, а по экологичности может с теслой посоревноваться. Делали его конечно не для гонок (за 3 сек. до 100 он не разгоняется). Тойота при этом остаётся крупнейшим производителем автомобилей в мире. Тут кстати становится занятно что её капитализация до теслы не дотягивает. Вокруг теслы есть только хайп который специально раскрутили.
Я может чего-то путаю, но Приус это гибрид и по основном характеристикам не сравнится с Тесла (то есть это что-то среднее, ни рыбо ни мясо).
И собственно Тойота хороший пример, что имей ты хоть бесконечно денег, огромную долю на рынке, опыт, сервисы и все такое, если ты фундаментально отстаешь, в перспективе (пусть и глобальной) ты все равно проиграешь.
Но да многие все сваливают на хайп, не понимая, что путают причину со следствием.
И собственно Тойота хороший пример, что имей ты хоть бесконечно денег, огромную долю на рынке, опыт, сервисы и все такое, если ты фундаментально отстаешь, в перспективе (пусть и глобальной) ты все равно проиграешь.
Но да многие все сваливают на хайп, не понимая, что путают причину со следствием.
по основном характеристикам не сравнится с Тесла
По каким? Задумайтесь что такого сверх нового в тесле? Какую инновацию они привнесли кроме «автопилота»? В чем главное преимущество электромобиля перед бензиновым?
Но да многие все сваливают на хайп, не понимая, что путают причину со следствием.
Текущая цена теслы совершенно не отражает её экономической привлекательности как компании. Она все годы была в убытке, даже прибыль за текущий год больше техническая (т.к. в основном за счет субсидий). Что бы отбить свою стоимость для инвесторов она должна будет годы платить высокие дивиденды, чего не бывает. Весь смысл вложения в неё сейчас это попытка поучаствовать с самой обычной пирамиде (возможность заработать только если кто-то купить чтобы потом опять перепродать дороже). Продолжатся так бесконечно не будет.
И собственно Тойота хороший пример, что имей ты хоть бесконечно денег, огромную долю на рынке, опыт, сервисы и все такое, если ты фундаментально отстаешь, в перспективе (пусть и глобальной) ты все равно проиграешь.
Проиграет в чем? Тойота стала хуже продаваться? Инвесторы от неё отвернулись?
По каким? Задумайтесь что такого сверх нового в тесле? Какую инновацию они привнесли кроме «автопилота»? В чем главное преимущество электромобиля перед бензиновым?
Ну это был по сути первый полноценный седан с возможностью проезжать 450км (а не 150), быстрой зарядки, нормальной динамики и безопасности, оригинальными (пусть и спорными) дизайнерскими решениями в духе минимализма и т.п. То есть именно законченный MVP.
Продолжатся так бесконечно не будет.
Я все тоже самое слышал и про эппл и про убер и особенно про фейсбук в свое время. И? Назовите мне хоть один реально лопнувший такой «пузырь» за последние 10 лет?
Проиграет в чем? Тойота стала хуже продаваться? Инвесторы от неё отвернулись?
Ну то что рост продаж у Теслы в разы превосходит Тойоту, и Тесла уже стоит в 2 раза дороже Тойоты и так с огромной вероятностью будет всегда.
Ну это был по сути первый полноценный седан с возможностью проезжать 450км (а не 150)
Любой седан с ДВС может это.
быстрой зарядки
Это за несколько часов по сравнению с заправкой за 5 мин?
оригинальными (пусть и спорными) дизайнерскими решениями в духе минимализма и т.п
Как будто другие компании не выпускали «спорные» с дизайнерской точки зрения машины.
особенно про фейсбук
Фейсбук делал совершенно новый продукт. Рынок соц. сетей с ним только появлялся. Кто-то думает что сейчас может появится другой фейсбук?
Ну то что рост продаж у Теслы в разы превосходит Тойоту
Вырасти с 10 000 до 20 000 это не тоже самое что с 1 000 000 до 2 00 000.
так с огромной вероятностью будет всегда/blockquote>
С чего вдруг? Какие экономические показатели это объясняют? Инвесторы в итоге захотят превратить свой доход в деньги. Они это либо сделают за счет получения дивидендов, либо продажи акций. Но кто захочет дальше покупать если не увидит перспективы?
Текущие успехи теслы только за счет успехов Маска с ракетами. Все думают что раз он совершил революцию в запусках, то сможет и тут. Но в отличии от ракет, в автомобилях такой революции не свершилось.
Любой седан с ДВС может это.
Я думал мы с другими электромобилями сравниваем. Ок тогда все это плюс разгон за 4 секунды, без передач и вообще трущихся частей (то есть гораздо меньше обслуживания надо), с очень крутой безопасностью (нельзя перевернуть, двигатель в салон не уедет), бесшумность, экологичность, возможность заправлять ночью (пусть и очень долго).
Как будто другие компании не выпускали «спорные» с дизайнерской точки зрения машины.
Кстати именно такие нет. Но опять-таки я тут все вместе сравнивал.
Фейсбук делал совершенно новый продукт. Рынок соц. сетей с ним только появлялся. Кто-то думает что сейчас может появится другой фейсбук?
Я про пирамиду и финпоказатели. Но вообще уже появлялись другие фейсбуки — инстаграмм, твиттер, ютуб, тикток, вот сейчас клабхаус например.
Но в отличии от ракет, в автомобилях такой революции не свершилось.
То есть переход с бензина на электричество (и скажем зарядка автомобилей дома по ночам) — это не революция? Ну ок.
переход с бензина на электричество
Ради чего? чем электрический лучше бензинового? Это как раз то, с чего я начал сравнение с приусом. Экологичность производства и эксплуатации теслы очень сомнительная вещь. Пока её произведут столько «вредного» выкинут. Пока электричество для неё выработают тоже столько СО в атмосферу отправят. Просто не рядом с владельцем теслы. Приус в этом смысле тоже чистый. ДВС работает на самых эффективных режимах, если надо, может проехать на выключенном двигателе. Прототип Ё-мобиля (который в Белоруссии тестировали) тоже достаточно чистый.
Я в тесле из революцинного вижу только автопилот.
Похоже что мы уже слишком далеко ушли от первоначальной темы. Кажется пора закруглятся.
Начнем с того, что это не ЯП, а фреймворк. Ну и далее по тексту ложь про 3 страны, плюс агрессия. У вас там все хорошо?
1с — это новое слово в Rapid Application Development, систем подобного класса в мире нет.
А то бы Украина уже давно на них соскочила, но увы.
А то бы Украина уже давно на них соскочила, но увы.
То что появился достойный конкурент 1С — меня очень радует. Да ещё и открытая платформа. Тут специалисты скажут свое весомое мнение при выборе платформы.
Однако у 1С главное преимущество (как я понимаю) в нескольких аспектах:
1. Законодательство. Они очень быстро вносят необходимые правки и максимально поддерживают текущие требования закона. Есть даже миф что 1С сами проталкивают изменения в законодательстве чтоб чаще менять формы, тем самым заставляя бизнес платить за обновления.
2. Франчайзинг (партнеры 1С). Судя по всему их десятки тысяч. Если бизнесу нужно что-то сделать в 1С, они идут в фирму и получают услугу в виде выездного специалиста. Если бизнес только собирается покупать 1С, то всегда есть специалист готовый приехать и обучить персонал.
3. Сотни готовых решений под любой бизнес. Пиццерия, магазин автозапчастей, швейная мастерская. Под всё есть решения.
lsFusion будет очень сложно конкурировать на этом поле.
Хотя решение в виде MyCompany даёт мелкому и среднему бизнесу качественный и бесплатный инструмент. Которое всё равно нужно обновлять под изменения законодательства. Как с этим обстоят дела?
Однако у 1С главное преимущество (как я понимаю) в нескольких аспектах:
1. Законодательство. Они очень быстро вносят необходимые правки и максимально поддерживают текущие требования закона. Есть даже миф что 1С сами проталкивают изменения в законодательстве чтоб чаще менять формы, тем самым заставляя бизнес платить за обновления.
2. Франчайзинг (партнеры 1С). Судя по всему их десятки тысяч. Если бизнесу нужно что-то сделать в 1С, они идут в фирму и получают услугу в виде выездного специалиста. Если бизнес только собирается покупать 1С, то всегда есть специалист готовый приехать и обучить персонал.
3. Сотни готовых решений под любой бизнес. Пиццерия, магазин автозапчастей, швейная мастерская. Под всё есть решения.
lsFusion будет очень сложно конкурировать на этом поле.
Хотя решение в виде MyCompany даёт мелкому и среднему бизнесу качественный и бесплатный инструмент. Которое всё равно нужно обновлять под изменения законодательства. Как с этим обстоят дела?
Поддерживаю оратора с добавлениями.
п.2. решаем (теоретически) бизнес-моделью. 1С сделало красиво — фиксированные цены для end-user и отваливать половину франчайзи. Отлично работает.
п.3. тоже решаем по правилу Парето — 90% (образно) клиентов удовлетворены тремя стандартными конфигурациями (причем актуальность важна только для двух — БП и ЗУП).
А вот п.1. — это всё. Первое, что говорит бухгалтер на предложение заменить 1С — "я на всё согласная, но один вопрос — как сдавать отчетность?".
Вот об это разбито просто вагон проектов.
То есть пока этот бешеный принтер в налоговой работает альтернатива 1С под большим вопросом.
Так бухгалтеру никто и не предлагает заменять 1С. Пусть сидит там считает свои налоги. Во всем мире бухгалтера работают в отдельном специализированном софте (скажем в США это какой нибудь Intuit) и никто не переживает по этому поводу.
Пусть сидит там считает свои налоги
Вы себе представляете что это такое? Думаете он так вот сел, и решил посчитать налоги и все? Думаете ему ничего из «управленческих» данных ничего для этого не нужно? Ему это как вводить, вручную?
Нет, естественно интеграция с бухсистемами должна быть (выгрузка или уже агрегированных проводок или первичных данных). И в MyCompany и даже в самих 1С решениях она есть (как и везде в мире). Но этого как правило в управленческих решениях более чем достаточно.
Так любая интеграция это большая головная боль. Особенно когда интегрируемые системы развиваются независимо в своих интересах. Кто будет заниматься актуализацией? В результате, какой заказчик захочет жить в условиях постоянной опасности что в один прекрасный день, что-то может не работать?
Вы надеюсь в курсе, что даже у 1С в подавляющем большинстве случаев УНФ/УТ/ERP ставится отдельно от БУХ и ЗУП? Как собственно и то, что во всем остальном мире бухгалтерию чаще всего ведут отдельно?
Ну так там развитием занимается один поставщик, он и занимается актуализацией.
А какая разница один или не один поставщик? Понятно что любой поставщик управленческих решений (коих тысячи) занимается актуализацией интеграции с бухгалтерией. Более того уверен в 1С этим занимается отдельный отдел / люди (то есть по сути «другой» поставщик).
Разница в том, что этот «один» поставщик точно имеет актуальную информацию по планам развития и оперативно актуализирует это самую «интеграцию». Когда поставщика 2, один обязательно «прошляпит» изменения у другого.
Что значит прошляпит? Ничто не мешает второму поставщику просто подстраиваться под изменения первого (первый выпустил новую версию, второй в течении короткого периода времени обновил интеграции). Например в России есть куча провайдеров всяких центральных сервисов аля Честный знак, ЕГАИС, Меркурий, и все как то актуализируют интеграцию с ними. То есть проблема явно надумана. Вон SAP даже как-то живет, а это весьма большая и как следствие не очень поворотливая махина.
Ничто не мешает второму поставщику просто подстраиваться под изменения первого (первый выпустил новую версию, второй в течении короткого периода времени обновил интеграции).
почему это второй должен подстраиваться под первого, а не наоборот? А потом мы имеем "эффективный" код и "ломучие" интеграции...
Что значит почему? Потому как если в данной области распространен этот поставщик, то под него и подстраиваться. Если основной движок интернет магазинов условная Joomla, то все будут подстраиваться под него, если у есть всего один сервис Честный знак все будут подстраиваться под него, если 90% касс это Сервис-плюс и Кристаллсервис, все будут подстраиваться под них, если 90 процентов бухгалтерий 1С: Бухгалтерия, все будут подстраиваться под нее и так далее. Так всегда и везде работает.
в подавляющем большинстве случаев УНФ/УТ/ERP ставится отдельно от БУХ и ЗУП
Тут причина в том что УНФ/УТ/ERP нельзя так часто обновлять как хотелось бы налоговой/1C
Как собственно и то, что во всем остальном мире бухгалтерию чаще всего ведут отдельно?
тут плохо применим опыт других стран. у нас бывает что целый поход нужен чтобы правильно сделать выгрузку в бухгалтерскую программу, чтобы подсчитать налог на прибыль… а если у вас еще валюта фигрурует с авансами… то всё, вы там повеситесь просто…
как вы будете выгружать «просто проводки» по расчетам с клиентом в долларах когда у вас куча авансов и отгрузок? пересчет валютных разниц мозг даже одинесником со стажем и главбухом мозг выносит… когда оказывается что точка зрения налоговой, разработчиков бухгалтерских программ и законов не совпадают друг с другом… точне их все трактуют по разному… типа 10% от общей цифры операций считать или от каждой и результат суммировать?
если логику таких расчетов оставлять в бухгалтерской программе то туда придется тащить кучу бизнеслогике которой там не место, если всё считать в управленческой системе — то опять всё скатится к поддержке законодательства а-ля 1С но своими силами
Это чисто вопрос ценника, и предметной области, но а любом случае бух всегда присутствует для сдачи налоговых отчётов.
не надо задним числом работать. тогда головняка не будет.
а для заднего числа писать регламент
а для заднего числа писать регламент
С чего вы взяли что весь «головняк» из-за работы задним числом?
UPD:
«С чего взяли» догадываюсь. Но опыт показывает, что это не самая большая проблема.
UPD:
«С чего взяли» догадываюсь. Но опыт показывает, что это не самая большая проблема.
из практики.
озвучьте другие проблемы интеграций. большие.
озвучьте другие проблемы интеграций. большие.
Из практики, больше всего проблеме из-за структурных различий в интегрируемых системах. Например неоднозначные связи (один и тот же объект источник может загружаться в разные приемники), архитектурные различия в обработке данных (одна система поддерживает работу «задним числом, а другая нет). Таких проблемы бывают конечно всегда, но при интеграции систем сделанных на одной платформе, или еще лучше одним поставщиком, этих проблему будет существенно меньше.
Ну вообще в США налоги считают в AccountingSuite которая к слову тоже 1С ;)
1. Законодательство. Они очень быстро вносят необходимые правки и максимально поддерживают текущие требования закона. Есть даже миф что 1С сами проталкивают изменения в законодательстве чтоб чаще менять формы, тем самым заставляя бизнес платить за обновления.
Вообще это обычно касается фискального и регламентированного учета. То есть по сути БУХ и ЗУП, которые даже с «управленческими» 1С решениями (то есть с УНФ, УТ, ERP и т.п.) в большинстве случаев ставятся отдельно. Более того 1С пытаясь двигать свой ERP на мировой рынок так и говорит, в качестве бухгалтерии используйте местный софт.
2. Франчайзинг (партнеры 1С). Судя по всему их десятки тысяч. Если бизнесу нужно что-то сделать в 1С, они идут в фирму и получают услугу в виде выездного специалиста.
Ну про это я писал в статье. Сейчас, особенно на фоне пандемии, когда все онлайн, по большому счету нет смысла в десятках тысяч партнеров. Сотни или даже десятка будет достаточно для того, чтобы у заказчика не было проблемы с vendor-lock / поиском подрядчика.
Сотни готовых решений под любой бизнес. Пиццерия, магазин автозапчастей, швейная мастерская. Под всё есть решения.
Тут соглашусь, но это вопрос времени. Тем более, что часто кастомизация превышает «специализацию», то есть «рыбы» в виде MyCompany или lsFusion ERP может быть достаточно для того чтобы на выходе получить даже более качественное решение, чем уже «готовое».
Которое всё равно нужно обновлять под изменения законодательства. Как с этим обстоят дела?
Это если честно не ко мне вопрос (я к MyCompany прямого отношения не имею). Но я полагаю, что в нем естественно поддерживаются / будут поддерживаться изменения законодательства, тем более что если исключить БУХ и ЗУП, этих изменений не так много как принято считать.
НЛО прилетело и опубликовало эту надпись здесь
Потому что бизнес не хочет пол года искать программиста что бы решить мелкую проблему
Работаете на пол ставки в битрикс? Я вам могу сказать совершенно обратную ситуацию, адекватного разраба, который может работать с битрикс днем с огнем не найдешь. Большинство битриксоидов это вчерашние вордпрессеры изучившие тему по паре 5 минутных роликов с ютуба. Система сертификации битрикса, грош цена ей. Так что с утверждением что битриксоида проще все найти я в корне не согласен. Его найти ровно так же сложно как и любого другого под нормальную платформу. Единственный случай когда я могу оправдать применение битрикса, так это при разработке интернет магазина, потому что такого уровня e-commerce решения увы больше не найти, а самому такой аналог можно довольно долго реализовывать
а че не на вордпрессе или джумла? Есть ведь и другие стандарты помимо битрикса
НЛО прилетело и опубликовало эту надпись здесь
не могу судить, из веб-магазинов сталкивался только с Woocomece (на своем сайте) и Битрикс (у 1с-клиентов)
но сдается мне, что вы выпячиваете достоинства Битрикса. Таки тут конкуренция порядочная (в сфере веб-сайтов).
но сдается мне, что вы выпячиваете достоинства Битрикса. Таки тут конкуренция порядочная (в сфере веб-сайтов).
НЛО прилетело и опубликовало эту надпись здесь
В России, ВНЕЗАПНО, фрилансеры не брались совсем (не охота разбираться в чужом говнокоде, ага). На ставку никто не хотел идти по той же причине.
единственное объяснение, которое у меня есть — жадность работодателя
И все. Интернет-магазин обслуживать не получилось.
вот прямо студия взяла и отказалась? или возникли проблемы с оплатой? те же биткоины вроде не вчера придумали
это преимущество 1с для бизнеса.
а есть еще преимущество для программистов — скорость разработки.
есть небольшие базы данных, которые на 1с автоматизируются с нуля за пару дней.
вот тут Фузина очень даже конкурент.
а есть еще преимущество для программистов — скорость разработки.
есть небольшие базы данных, которые на 1с автоматизируются с нуля за пару дней.
вот тут Фузина очень даже конкурент.
Тяжело ли в вашем продукте реализовать расчет/перерасчет зарплаты со всеми нюансами?
Есть ли механизм настройки ограничения прав доступа к отдельным записям?
Предусмотрен ли электронный документооборот и использование ЭЦП, сейчас или в планах?
Есть ли механизм настройки ограничения прав доступа к отдельным записям?
Предусмотрен ли электронный документооборот и использование ЭЦП, сейчас или в планах?
Тяжело ли в вашем продукте реализовать расчет/перерасчет зарплаты со всеми нюансами?Если речь идет о платформе, то точно не тяжелее, чем на 1С. Просто задача расчета зарплаты очень гибкая, и часто лучше делать специализированное решение под конкретный процесс расчета премий и штрафов, чем универсальный, как в ЗУП.
Есть ли механизм настройки ограничения прав доступа к отдельным записям?На уровне платформы — нет. Обычно это делается на уровне конкретной «конфигурации». В той же MyCompany сделана такое ограничение на основе привязки пользователей к местам хранения (и дальнейшей фильтрации заказов, поступлений и т.д.)
Предусмотрен ли электронный документооборот и использование ЭЦП, сейчас или в планах?Это опять же делается на уровне конфигурации. Например, в MyCompany реализована интеграция с CryptoPro путем простого подключения библиотеки JCP. Вот исходный код непосредственно подключения.
На уровне платформы — нет.
Я бы сказал — пока нет. В принципе можно добавить возможность для класса задавать фильтры что-то типа:
CLASS X {
FILTERS hasAccess(X, currentUser());
}
Который будет добавлять блок FILTERS во все формы, где есть объекты этого класса. Это несложно реализуется, а мощный оптимизатор запросов разрулит все проблемы с производительностью.
Но тут проблема, что такой cross-cutting будет давать много нежелательных эффектов, так как формы универсальный механизм использующийся в том числе и для экспортов и для отчетов. Соответственно можно отфильтровать лишние данные и это может быть критично. Впрочем, надо будет посмотреть как это в других платформах решается (тот же RLS в 1C).
и дальнейшей фильтрации заказов, поступлений и т.д.
И эту фильтрацию нужно делать в каждом месте? А если её нужно подкорректировать?
Да, в каждом месте одной строкой добавляется конструкция вида (где hasAccess свойство, построенное ранее по какому угодно фильтру):
Но можно и более сложные фильтры делать при желании. К сожалению, автоматически добавлять ко всем подряд объектам нельзя, так как в некоторых случаях фильтровать не нужно.
FILTERS hasAccess(object, currentUser())Но можно и более сложные фильтры делать при желании. К сожалению, автоматически добавлять ко всем подряд объектам нельзя, так как в некоторых случаях фильтровать не нужно.
Попуститесь пацаны. Вам еще год назад писали, почему ваша поделка отстой. Обстоятельно писали, с примерами и обоснованием.
Насколько я помню год назад писали:
И это были самые заплюсованные комментарии.
Все остальное было лишено конструктива, и сводилось к тому, что «автор не разобрался». На вопрос в чем именно не разобрался, ответов не было.
В любом случае не нравится не читайте. У нас свое видение, у вас свое.
Странное ощущение — что именно то не выдерживает критики? Я опытный разработчик 1С и могу подтвердить что всё что тут перечисленно большая боль для меня — и самое больное что 1С совсем не собирается что то сделать полезное, всё что она может это изолироваться и поддерживать клуб любителей такой изоляции.
И это были самые заплюсованные комментарии.
Все остальное было лишено конструктива, и сводилось к тому, что «автор не разобрался». На вопрос в чем именно не разобрался, ответов не было.
В любом случае не нравится не читайте. У нас свое видение, у вас свое.
И это были самые заплюсованные комментарии.
Ну Вы же понимаете: это хабр; комментарии, где критикуется 1С, плюсуются безоговорочно независимо от смысла.
Есть такое. Но конструктива, где претензии были или необоснованными или незначительными, все равно было очень мало. Хотя с другой стороны человеку ни разу ни использовавшему ни явную типизацию, ни наследования с полиморфизмом, ни нормальные IDE действительно тяжело понять зачем это все нужно.
Есть такое. Но конструктива, где претензии были или необоснованными или незначительными, все равно было очень мало.
Опять-таки, это хабр. Здесь в критике 1С всегда мало конструктива. Больше на эмоциях как-то основываются.
Хотя с другой стороны человеку ни разу ни использовавшему ни явную типизацию, ни наследования с полиморфизмом, ни нормальные IDE действительно тяжело понять зачем это все нужно.
Какое-то, не связанное с предыдущим предложением, утверждение. Но ок. А с чего Вы взяли, что человек с этим никогда не сталкивался и никогда это не использовал?
Опять-таки, это хабр. Здесь в критике 1С всегда мало конструктива. Больше на эмоциях как-то основываются.
Стоп, я не про критику 1С, а про критику критики 1С. Как раз в этих двух статьях я пытался подходить максимально предметно, без абстрактных вещий, аппелируя к общепринятым понятиям / механизмам и т.п. И в общем то поэтому хотелось увидеть более предметную реакцию, а не эмоции как вы говорите. И причины на мой взгляд почему именно так происходит на мой взгляд именно в:
Хотя с другой стороны человеку ни разу ни использовавшему ни явную типизацию, ни наследования с полиморфизмом, ни нормальные IDE действительно тяжело понять зачем это все нужно.
Или у вас есть другое объяснение, почему часто 1С разработчики отвечают строго эмоционально, а не могут предметно сформулировать свои мысли / возражения?
Стоп, я не про критику 1С, а про критику критики 1С.
Тогда я значит Вас не так понял, Вы как-то незаметно с критики 1С на критику критики 1С перескочили.
Или у вас есть другое объяснение, почему часто 1С разработчики отвечают строго эмоционально, а не могут предметно сформулировать свои мысли / возражения?
Часто — это ведь тоже эмоциональное суждение, нес па? По моему опыту, конструктивность диалога зависит строго от вменяемости оппонента, а не от строгой типизации, вменяемого IDE(а где он кстати вменяемый) и уж тем более не от наследования с полиморфизмом.
Тогда почему у статей EvilBeaver не много-много минусов?
Потому что они были в таком стиле:
Такое здесь любят :)
Я опытный разработчик 1С и могу подтвердить что всё что тут перечисленно большая боль для меня — и самое больное что 1С совсем не собирается что то сделать полезное, всё что она может это изолироваться и поддерживать клуб любителей такой изоляции.
Такое здесь любят :)
где писали?
где примеры и обоснования?
я на мисте спрашивал, где это все?
тишина. Как говорится, Фузину не смотрел, но осуждаю.
где примеры и обоснования?
я на мисте спрашивал, где это все?
тишина. Как говорится, Фузину не смотрел, но осуждаю.
Диаграмма в заголовке прикольная.
Вопрос только: а Вас не напрягает, что на ней все альтернативные решения сгруппированы по кластерам (то есть каждый кластер заточен под какой-то срез задач и все решения из этого кластера имеют схожие параметры), а IsFusion расположен в какой-то отдельной области, где больше ничего нет? Может он решает свой срез задачи таким способом, который на рынке не популярен? (не в смысле «не в тренде», а в смысле «не самый экономически эффективный»)
Вопрос только: а Вас не напрягает, что на ней все альтернативные решения сгруппированы по кластерам (то есть каждый кластер заточен под какой-то срез задач и все решения из этого кластера имеют схожие параметры), а IsFusion расположен в какой-то отдельной области, где больше ничего нет? Может он решает свой срез задачи таким способом, который на рынке не популярен? (не в смысле «не в тренде», а в смысле «не самый экономически эффективный»)
Ну, строго говоря, все альтернативные решения используются именно для разработки информационных систем. Скажем решения для банков и крупного ритейла часто пишут на PL/SQL, T-SQL (в смысле всю бизнес-логику) + каком-нибудь чисто UI-фреймворке (скажем дельфи или веб), но бывает, что эти же решения пишут и на 1С и на Java Spring. А например ERP решения для производства чаще всего пишут на ERP-фреймворках, но бывают когда также как для банков на PL/SQL или на .Net. Высоконагруженные корпоративные бизнес-приложения (где простая бизнес-логика, но огромная нагрузка) чаще пишут на каких-нибудь Java EE, но бывает и из PL/SQL (или даже ERP платформ) выжимают все что можно.
Собственно эта диаграмма в заголовке показывает, что потенциально технология аля lsFusion может заменить PL/SQL, ERP-фреймворки и RAD-средства. До ORM она не дотянет в плане гибкости и масштабируемости (ультра высоконагруженности).
Собственно эта диаграмма в заголовке показывает, что потенциально технология аля lsFusion может заменить PL/SQL, ERP-фреймворки и RAD-средства. До ORM она не дотянет в плане гибкости и масштабируемости (ультра высоконагруженности).
1С это для бухгалтера. Если нужна какая-то другая автоматизация нужно отдельное специализированное решение адаптированное под предметную область. По аналогии как Додо делало для своих пиццерий.
Это решение либо покупается, либо пилится внутри компании усилиями 3-4 разработчиков на каком-то мейнстримовом языке вроде java/c#/go
Это решение либо покупается, либо пилится внутри компании усилиями 3-4 разработчиков на каком-то мейнстримовом языке вроде java/c#/go
1С это для бухгалтера. Если нужна какая-то другая автоматизация нужно отдельное специализированное решение адаптированное под предметную область.
Это у вас опыт внедрения и того и того говорит?
на каком-то мейнстримовом языке вроде java/c#/go
Решение делается ведь не на языке. Язык не важен. Важен фреймворк на котором сделано решение. Писать под каждое решение свой фреёмворк точно не в интересах конечного заказчика.
Есть опыт over 10 лет по .NET. Есть опыт взаимодействия с 1С, SAP и ресторанными системами iiko и rKeeper. Есть вещи которые банально не делаются в рамках бухгалтерских программ, бухгалтеры страдают но ничего сами не попросят. Есть вещи которые связаны с передачей данных между системами и их верификаций.
Чем сильнее конфигурация 1С отличается от стандартной — тем больше с ней возни и проблем.
В интересах конечного заказчика чтобы решение работало просто эффективно
Чем сильнее конфигурация 1С отличается от стандартной — тем больше с ней возни и проблем.
В интересах конечного заказчика чтобы решение работало просто эффективно
каком-то мейнстримовом языке вроде java/c#/goЛибо на том же lsFusion. Например, пять из восьми крупнейших розничных сетей Беларуси работают на решении, разработанной на lsFusion. А по оборотам они все входили бы в ТОП-20 розничных сетей РФ. То есть это не ларьки.
Уважаемый, вы назовите «ТОП-20» розничных сетей РФ, ну чисто, чтобы ваши слова не выглядели пустым надуванием щёк.
На счёт Белоруссии — там всё возможно. Если бы мне бы сказали что 1С не подходит и нужно что-то еще, то IsFusion безусловно мной бы рассматривался как один из вариантов.
Почему такая любоффь к 1С? Да нет никакой любви — банально 99% людей, которых вы принимаете на работу с ней умеют работать.
Почему такая любоффь к 1С? Да нет никакой любви — банально 99% людей, которых вы принимаете на работу с ней умеют работать.
не, 1с не для бухгалтера. 1с для бухгалтера было только во времена 6.0 и то, на 6.0 писали уже упр.учет на счетах.
Весна… Фузиновцы обострились.
lsFusion и 1С это платформы для создания прикладных решений. Следовательно важны не они сами по себе, а прикладные решения который создаются с их использованием. Главная цель для них это «нести» пользу конечному пользователю. Потребители по большому счёту не важно на чем он работает. По этому показателю 1С является лидером. Конкуренция с 1С начнется только тогда, когда конечному потребителю будут предоставлены все те же удобства что он имеет сейчас.
Для бухгалтера важно соответствие законодательству. С 1С он может за 10 мин зарегистрироваться на 1cfresh.com и доступ облачному решению которое всегда актуально, и ему не нужно думать ни о чем, он просто пользуется, даже устанавливать ничего не надо.
Для руководителя предприятия при внедрении ERP важно найти максимально подходящее под его требования решение и иметь возможность за минимальные деньги и сроки реализовать все необходимые «доработки».
Для них слова «мы нагружаем СУБД и не сервер приложения» не важны.
Для бухгалтера важно соответствие законодательству. С 1С он может за 10 мин зарегистрироваться на 1cfresh.com и доступ облачному решению которое всегда актуально, и ему не нужно думать ни о чем, он просто пользуется, даже устанавливать ничего не надо.
Для руководителя предприятия при внедрении ERP важно найти максимально подходящее под его требования решение и иметь возможность за минимальные деньги и сроки реализовать все необходимые «доработки».
Для них слова «мы нагружаем СУБД и не сервер приложения» не важны.
А где посмотреть, что новенького появилось в lsFusion 4.1 по сравнению с 3.1?
Можно попробовать здесь
Круто ребята вбрасывают. В статье «Почему не 1С» в качестве примеров берут реальные, так сказать промышленные куски кода, которые будучи вырванными из контекста всегда будут выглядеть неадекватно и монструозно. А в этой статье в качестве решения проблем предлагается метод «Ну допустим, есть товар А с ценой Б и количеством В. Тогда сумму мы вычислим вот таким простым способом в одну строчку. Сравните с 1С.». Это называется по-другому, а именно «нечестный полемический прием».
Ну и, честно говоря, неглубокое понимание архитектуры 1С автором тоже не делает ему чести и доверия. Взять хотя бы ошибочную версию автора, что виртуальные таблицы 1С — всего лишь представления (view). Что заставило автора думать, что в их параметрах можно использовать только константы и не позволило решить такую простую задачу, как вывод в динамическом списке товаров их остатки по складам.
UPD 14:42
Изучаю вашу демку ERP. Ну что сказать… А где блокировка бизнес-объектов от изменения одновременно несколькими пользователями? Или так задумано —
Ну и, честно говоря, неглубокое понимание архитектуры 1С автором тоже не делает ему чести и доверия. Взять хотя бы ошибочную версию автора, что виртуальные таблицы 1С — всего лишь представления (view). Что заставило автора думать, что в их параметрах можно использовать только константы и не позволило решить такую простую задачу, как вывод в динамическом списке товаров их остатки по складам.
UPD 14:42
Изучаю вашу демку ERP. Ну что сказать… А где блокировка бизнес-объектов от изменения одновременно несколькими пользователями? Или так задумано —
Не совсем понял. В этой статье «прямые» сравнения это:
Что значит «всего лишь представления»? Да, в SQL и в других технологиях представления это и есть виртуальные таблицы (просто по определению). Другое дело, что в 1С виртуальные таблицы еще несколько мелких вещей «сверху» умеют делать (например автоматически группировать, когда не все измерения указаны и т.п.), но это просто небольшой синтаксический сахар сверху.
Ну например вот (исходники, если хотите сравнить код), система на которой работают 70% крупных розничных сетей Беларуси (там конечно нет части функционала УТ, зато есть огромное количество функционала которого нет в УТ)
- про отсутствие оптимизатора запросов — там пример один в один
- с ограничениями — там есть небольшая разница(хотя даже в первой статье специально была выбрана именно проверка очень простого ограничения вроде текущего остатка), но, собственно основной смысл, что в lsFusion задаешь как вычисляется показатель, а дальше просто вешаешь ограничение на него одной строкой. А в 1С нужно танцы бубном из триггеров и временных таблиц городить
- с разделением сервера и клиента — но там как раз у 1С и будет жутко монструозно из-за всех этих НаСервере и НаКлиенте
Взять хотя бы ошибочную версию автора, что виртуальные таблицы 1С — всего лишь представления (view).
Что значит «всего лишь представления»? Да, в SQL и в других технологиях представления это и есть виртуальные таблицы (просто по определению). Другое дело, что в 1С виртуальные таблицы еще несколько мелких вещей «сверху» умеют делать (например автоматически группировать, когда не все измерения указаны и т.п.), но это просто небольшой синтаксический сахар сверху.
Вы сначала полноценную конфу уровня УТ хотя бы запилите, а потом на ее примере демонстрируйте успехи…
Ну например вот (исходники, если хотите сравнить код), система на которой работают 70% крупных розничных сетей Беларуси (там конечно нет части функционала УТ, зато есть огромное количество функционала которого нет в УТ)
Изучаю вашу демку ERP. Ну что сказать… А где блокировка бизнес-объектов от изменения одновременно несколькими пользователями? Или так задумано —
А вы статью читали (в том числе заключение)? В этом магия lsFusion, она не читает (а потом и записывает) объект целиком. То есть вполне допускает одновременное редактирование данных (аля google docs или условно git), при этом полностью гарантирует целостность данных, и то что одно изменение пользователя не затрет изменение другого пользователя (если один поменял одни данные, а второй другие).
А если оба пользователя вносят «идентичные» данные в разные строки?
Идея «работать без блокировок» — всегда опасна. Потому что ударить может в любой момент и неизвестно где. И как потом искать неправильные данные.
Идея «работать без блокировок» — всегда опасна. Потому что ударить может в любой момент и неизвестно где. И как потом искать неправильные данные.
Сработает ограничение (если оно есть) на наличие двух «идентичных» данных. То есть целостность данных вы не нарушите никак.
Ну и в любом случае «большая сила влечёт за собой большую ответственность» (с) Человек-Паук.
Ну и в любом случае «большая сила влечёт за собой большую ответственность» (с) Человек-Паук.
То есть предлагаете это переложить на плечи пользователей? Интересное решение…
Как раз такую проблему и решает блокировка объекта. И ситуаций, когда она может пригодиться — не счесть. А если все моменты сбрасывать на пользователей — то зачем вообще программа, когда есть Excel?
Как раз такую проблему и решает блокировка объекта. И ситуаций, когда она может пригодиться — не счесть. А если все моменты сбрасывать на пользователей — то зачем вообще программа, когда есть Excel?
Нет, почему. Пользователи как раз меняют, каждый свои данные спокойно и не мешая друг другу (как в google docs). То есть один изменил цену в одной строке, другой в другой. Вас же не смущает, что в google docs несколько человек могут править один документ? И ситуаций, где это может пригодиться — не счесть.
НЛО прилетело и опубликовало эту надпись здесь
Так тот кто махнет пересчет цен в процентах на все позиции, он по определению не будет смотреть ни на первого ни второго. Даже если он увидит предупреждение он все равно махнет. И изменения первого и второго потеряются в любом случае.
Но это какая то надуманная проблема. И если она для какой-то информации реально существует на практике, ну так включите для этой информации пессимистичные блокировки, делов-то. А для остальных 95 процентов случаев, когда описанная вами ситуация очень маловероятна / некритична оставьте параллельный ввод (что значительно ускорит работу пользователей).
Собственно смотрите, во всем мире в битвах — версионник (оптимистичные блокировки) / блокировочник (пессимистичные), расшаренный excel / google docs, блокировочные VCS / Git победили оптимистичные блокировки (с иногда опциональными пессимистичными).
Но это какая то надуманная проблема. И если она для какой-то информации реально существует на практике, ну так включите для этой информации пессимистичные блокировки, делов-то. А для остальных 95 процентов случаев, когда описанная вами ситуация очень маловероятна / некритична оставьте параллельный ввод (что значительно ускорит работу пользователей).
Собственно смотрите, во всем мире в битвах — версионник (оптимистичные блокировки) / блокировочник (пессимистичные), расшаренный excel / google docs, блокировочные VCS / Git победили оптимистичные блокировки (с иногда опциональными пессимистичными).
НЛО прилетело и опубликовало эту надпись здесь
Хочешь испортить жизнь манагеру? Дождись пока он зайдет в документ перед подписью и поставь на 3 странице цены по 1 рублю. Он не увидит, подпишет и будет все ок. Отвечать будет он)
Хоть убей не понял этого примера. Так человек же и будет смотреть что подписывает и увидит там цены по рублю и не подпишет.
Вы кривите. Сравнение с ГуглДокс некорректно.
В ГуглДокс все видят, кто правит в данный момент какую ячейку. Постоянно. То есть есть информация о том, что кто-то работает в этом документе. В вашей же программе такого не будет.
Так что жду от вас «корректного» примера, где с данными работают без блокировок, как в вашей. Иначе — это «ноу хау» в стиле «пусть сами разгребают».
З.Ы. — безопасность всегда стоит выше эфемерного удобства. Если в системе могут работать десятки человек — без блокировок велик риск, что в один момент они подправят один-другой документ некорректно. И когда это определят и как будут исправлять — песня из матов, сначала в сторону пользователей, ну а как разберутся в чем причина — в вашу сторону.
В ГуглДокс все видят, кто правит в данный момент какую ячейку. Постоянно. То есть есть информация о том, что кто-то работает в этом документе. В вашей же программе такого не будет.
Так что жду от вас «корректного» примера, где с данными работают без блокировок, как в вашей. Иначе — это «ноу хау» в стиле «пусть сами разгребают».
З.Ы. — безопасность всегда стоит выше эфемерного удобства. Если в системе могут работать десятки человек — без блокировок велик риск, что в один момент они подправят один-другой документ некорректно. И когда это определят и как будут исправлять — песня из матов, сначала в сторону пользователей, ну а как разберутся в чем причина — в вашу сторону.
В вашей же программе такого не будет.
Это с чего вдруг? Это как раз технически очень не сложная задача. Закидываешь все изменения в сессиях в какую-нибудь таблицу, и подсвечиваешь эти изменения в интерактивном представлении форм. В принципе можно реализовать, но по опыту проблема реально сильно надуманна.
Кстати в том же ГуглДокс ЕМНИП подсветка того кто правит в данный момент ячейку появилась далеко не в первой версии и работали как-то.
Так что жду от вас «корректного» примера, где с данными работают без блокировок, как в вашей. Иначе — это «ноу хау» в стиле «пусть сами разгребают».
Собственно смотрите, во всем мире в битвах — версионник (оптимистичные блокировки) / блокировочник (пессимистичные), расшаренный excel / google docs, блокировочные VCS / Git победили оптимистичные блокировки (с иногда опциональными пессимистичными).
То что в бизнес-приложениях (не считая SQL, а на верхнем уровне) мало где использовались оптимистичные блокировки, так это потому что реализация их в бизнес-приложениях (как впрочем и везде) ГОРАЗДО сложнее. Но в lsFusion это удалось сделать.
З.Ы. — безопасность всегда стоит выше эфемерного удобства. Если в системе могут работать десятки человек — без блокировок велик риск, что в один момент они подправят один-другой документ некорректно. И когда это определят и как будут исправлять — песня из матов, сначала в сторону пользователей, ну а как разберутся в чем причина — в вашу сторону.
Что значит подправят некорректно? Вот один исправил цену, а второй через пару минут пересчитал все (он то не просматривает старые значения вообще, он записывает новые). Это некорректно?
lsFusion гарантирует, что ни одна проверка целостности не будет нарушена. Если для вас что-то критично, просто добавьте соответствующую проверку, она вам все равно будет нужна даже при однопользовательском вводе. Ну или в крайнем случае включите для КОНКРЕТНОГО процесса пессимистичную блокировку. Зачем мучать пользователей на ВСЕХ процессах?
Дадада, всё у вас удалось. Ни у кого в мире не удавалось, но у вас конечно всё есть.
«В принципе можно реализовать, но по опыту проблема реально сильно надуманна» — а по моему опыту проблема очень даже не надуманная. Хотя, возможно, это результат ошибки выжившего. Вы создаете ПО в текущих реалиях, когда многие пользователи уже «научились» на других программах, что так делать нельзя, поэтому пользовательская грамотность слегка другая. 1С создавалась в других реалиях, когда компьютеры еще были в диковинку, поэтому пользователи намного чаще делали ошибки. Но это не значит, что сейчас надо надеяться на грамотность пользователя. Это ошибка в подходе, которая может больно аукнуться.
«Зачем мучать пользователей на всех процессах» — как вы будете определять, в какой ситуации нужна пессимистичная блокировка, а где оптимистичная?
И вообще, мне надоело, что вы вместо ответов на конкретный вопрос начинаете сами себе задавать вопросы и на них отвечать.
«В принципе можно реализовать, но по опыту проблема реально сильно надуманна» — а по моему опыту проблема очень даже не надуманная. Хотя, возможно, это результат ошибки выжившего. Вы создаете ПО в текущих реалиях, когда многие пользователи уже «научились» на других программах, что так делать нельзя, поэтому пользовательская грамотность слегка другая. 1С создавалась в других реалиях, когда компьютеры еще были в диковинку, поэтому пользователи намного чаще делали ошибки. Но это не значит, что сейчас надо надеяться на грамотность пользователя. Это ошибка в подходе, которая может больно аукнуться.
«Зачем мучать пользователей на всех процессах» — как вы будете определять, в какой ситуации нужна пессимистичная блокировка, а где оптимистичная?
И вообще, мне надоело, что вы вместо ответов на конкретный вопрос начинаете сами себе задавать вопросы и на них отвечать.
Дадада, всё у вас удалось. Ни у кого в мире не удавалось, но у вас конечно всё есть.
А я объясню, потому что реализовать одну такую фишку не возможно. Нужно реализовывать весь lsFusion целиком в том виде что есть сейчас. А это очень сложная архитектурно не масштабируемая деньгами задача.
как вы будете определять, в какой ситуации нужна пессимистичная блокировка, а где оптимистичная?
А как вы определяете где нужна в 1С управляемая блокировка, а где нет? Даю подсказку, аналитически или по факту инцидента.
И вы упорно игнорируете факт про победу версионников над блокировочниками (скажем у Oracle и Postgres так и не появился блокировочный режим, а у MS SQL появился версионный и его даже 1С частично начал использовать), победу git над блокировочными системами контроля версий, победу google docs над расшаренным excel / word и т.п. Может прокомментируете? Или там типа ошибок на миллион нет (хотя везде есть / могут быть).
А если оба дописали примечание в документ, то прав останется последний. При этом первый будет уверен, что записал свои изменения. Вот ровно только что провел такой эксперимент в вашей демо-ERP, и все сработало по данному сценарию. В общем, спорное решение. Могу я предположить, что если кому-то по бизнес-логике понадобится реализовать механизм монопольного редактирования объектов, то он будет выглядеть монструозным и костылеватым, т.к. вы не поддерживаете этого на уровне платформы?
Ну вы вырожденный случай выбрали. Скажем если примечания будут строками, то несколько строк отлично добавятся в документ параллельно.
И нет, пессимистичные блокировки тоже делаются очень легко. Тут есть пример (описание системных действий lock, unlock встроенных в платформу)
То есть можно сделать просто:
Но на практике это используется очень редко. Когда пользователи привыкли к Google Docs, использовать расшаренный по сети Excel-файл уже никто не хочет.
И нет, пессимистичные блокировки тоже делаются очень легко. Тут есть пример (описание системных действий lock, unlock встроенных в платформу)
То есть можно сделать просто:
lock(o);
IF lockResult() THEN
TRY
edit(o);
FINALLY
unlock(o);
ELSE
MESSAGE 'Используется другим пользователем'
Но на практике это используется очень редко. Когда пользователи привыкли к Google Docs, использовать расшаренный по сети Excel-файл уже никто не хочет.
Независимое редактирование «строк документа» можно и в 1С сделать, если что.
Но это, согласитесь, костыль на регистрах. Все-таки парадигма 1С — изменение данных цельными блоками. Другое дело, что автор опять делит мир на олдскул и ньюскул, безапеляционно утверждая, что принцип работы 1С — это расшаренный по сети Excel по сравнению с Google Docs.
Что значит безапеляционно утверждая? А вы сами этой аналогии не видите?
Нет, не вижу. Лично я вижу разные парадигмы обработки данных и поддержания их целостности у 1С и у вашего решения. В обоих случаях есть плюсы, а есть минусы. Если очень надо, то действительно, как сказал gennayo, очень просто сделать табличную часть документа не в виде табличной части, а в виде подчиненного документа или справочника. И даже достаточно конфигураций, которые именно так и работают. В основном WMS-ки, где, к примеру, сразу множество кладовщиков одну приемку делают. И это тоже очень просто, как дважды два — просто «ПКМ->Добавить» в конфигураторе. А еще есть множество ситуаций, когда над заказом работает пара менеджеров, и в текстовом поле Комментарий пишут важные замечания по заказу. В вашей демо-ERP вот прямо сейчас можно открыть два сеанса, в каждом сеансе по окну одного документа «Заказ (закупка)», допустим, номер 9080111, изменить и сохранить в них одно и то же поле, к примеру «Примечание», и сохранится только последняя правка, а правка первого сохранившего молча пойдет лесом. Базовая парадигма 1С — не допустить такого сценария ни при каких раскладах. Ваша — да и пофиг, если надо — сами лок делайте при открытии. И при этом вы утверждаете, что это прогрессивно.
Лично я вижу разные парадигмы обработки данных и поддержания их целостности у 1С и у вашего решения
Нет, в 1С есть только пессимистичные блокировки, а в lsFusion и те и другие. Плюсы и минусы обоих подходов хорошо известны (и встречаются во многих областях), но фактически везде побеждают оптимистичные.
Если очень надо, то действительно, как сказал gennayo, очень просто сделать табличную часть документа не в виде табличной части, а в виде подчиненного документа или справочника. И даже достаточно конфигураций, которые именно так и работают. В основном WMS-ки, где, к примеру, сразу множество кладовщиков одну приемку делают.
Не совсем понял, а как потому эти подчиненные документы «объединяются» в один? А как это потом все редактируется? Это же треш и угар будет. Причем в lsFusion это все из коробки делается.
А еще есть множество ситуаций, когда над заказом работает пара менеджеров, и в текстовом поле Комментарий пишут важные замечания по заказу
Это как раз один вырожденный случай, со строкой, в которую дописывают в конец. Хотя в том же lsFusion, для этого просто делают записи комментариев (так удобнее и с точки логирования например этих изменений), и тогда вводите параллельно без проблем.
Базовая парадигма 1С — не допустить такого сценария ни при каких раскладах. Ваша — да и пофиг, если надо — сами лок делайте при открытии. И при этом вы утверждаете, что это прогрессивно.
Конечно прогрессивно:
Собственно смотрите, во всем мире в битвах — версионник (оптимистичные блокировки) / блокировочник (пессимистичные), расшаренный excel / google docs, блокировочные VCS / Git победили оптимистичные блокировки (с иногда опциональными пессимистичными).
Почему на регистрах? Вполне себе и на документах варианты есть. Но да, с точки зрения «фузиновцев» — это костыль.
Боюсь, это может создать много неявных проблем.
Вот, например, в 1с в документах бывают зависимые реквизиты (например, контрагент и договор контрагента. Договор контрагентам принадлежат контрагенту). Пользовательские формы в 1с построены так, что показывают только договоры контрагента выбранного контрагента, но в 1с то при этом сам документ блокируется. А тут мы получим, что один пользователь изменил контрагент, другой изменил договор — и мы легко потеряли зависимость между ними, потеряв целостность данных.
Вот, например, в 1с в документах бывают зависимые реквизиты (например, контрагент и договор контрагента. Договор контрагентам принадлежат контрагенту). Пользовательские формы в 1с построены так, что показывают только договоры контрагента выбранного контрагента, но в 1с то при этом сам документ блокируется. А тут мы получим, что один пользователь изменил контрагент, другой изменил договор — и мы легко потеряли зависимость между ними, потеряв целостность данных.
Нет, при проведении сработает ограничение, что выбран договор не того контрагента, после того как пользователь нажмет ОК, данные обновятся и он увидит другого контрагента и сможет выбрать другой договор.
Но опять-таки правило Парето и разница между оптимистичными и пессимистичными блокировками. В 99 процентов удобнее работать параллельно, а в 1 проценте случаев главное чтобы поддерживалась целостность и с большего указывалось в чем проблема ее нарушения. Это дает куда лучший баланс, чем просто все запретить, и слушать крики на весь офис «Маша дай отредактировать документ, когда ты его уже отпустишь».
Но опять-таки правило Парето и разница между оптимистичными и пессимистичными блокировками. В 99 процентов удобнее работать параллельно, а в 1 проценте случаев главное чтобы поддерживалась целостность и с большего указывалось в чем проблема ее нарушения. Это дает куда лучший баланс, чем просто все запретить, и слушать крики на весь офис «Маша дай отредактировать документ, когда ты его уже отпустишь».
Да, именно так — надо кричать «Маша дай отредактировать документ, когда ты его уже отпустишь». Ибо не заметив, что кто-то параллельно внес правку в открытый тобой документ, можно и счет клиенту не на ту сумму отправить… А потом ищи концы, какая там Маша что в этот момент делала. Так некоторые учетные системы можно превратить в полную помойку.
А если Маша зашла в документ просто «посмотреть»? Или я хочу зайти посмотреть? А в 95% случаев документ просматривают, а не правят.
Если Маша зашла в документ просто «посмотреть», то он не заблокируется. Блокировка начнет работать только при начале редактирования — то есть при изменении свойства Модифицированность открытого объекта.
а это тоже опасно, она открыла документ, смотрит 50000рублей, уходит, наливает чай, возвращается, тыкает печать и идет к принтеру… а там накладная на 50000рублей но на совсем другого контрагента с похожим названием… пока она глядела не меняя документ, его уже ктото изменил (вот не надо только 'обязана сверять'… я уже наслушался такого, когда поток документов по несколько тысяч на человека в сутки, у Маши крыша поедет)
Дак не запишется документ — напишет про несоответствие версий. Честь Маши не пострадала!
не запишется кем? при печати документа — его не надо записывать? или предлагаете блокировать запись документа если его ктото открыл?
че толку открывать документ если он в любой момент может стать неконсистентным… маша нафигачила туда 100500 строк… а оно ему… ой чёто изменилось, перезагрузить?
че толку открывать документ если он в любой момент может стать неконсистентным… маша нафигачила туда 100500 строк… а оно ему… ой чёто изменилось, перезагрузить?
Печать документа производится не по данным формы, а по данным объекта из БД.
конечно, по этому на печать попадет не то что человек видит перед собой в документе
Да, но уйдет фактическое его состояние.
Так же нет проблем реализовать контроль на изменение версии объекта перед печатью с предложением перечитать его или автоматическим перечитываением.
А вот это уже исключается автоматическим накладыванием объектной блокировки на уровне сервера приложений при начале редактирования объекта.
Так же нет проблем реализовать контроль на изменение версии объекта перед печатью с предложением перечитать его или автоматическим перечитываением.
маша нафигачила туда 100500 строк… а оно ему… ой чёто изменилось, перезагрузить
А вот это уже исключается автоматическим накладыванием объектной блокировки на уровне сервера приложений при начале редактирования объекта.
Не будет так работать. В большинстве случаев если документ посчитается системой «измененным» — то он потребует перезаписи. А если изменен другим пользователем — то он потребует, чтобы его «перечитали». И тогда Маша увидит измененные данные и печатать будет правильный документ. Рассматривать ситуацию, что сначала Маша распечатала, а потом кто-то этот документ изменил не имеет смысла, потому что это уже не техническая ошибка, а организационная и решается на уровне пользователей, а не программы.
Рассматривать ситуацию, что сначала Маша распечатала, а потом кто-то этот документ изменил не имеет смысла, потому что это уже не техническая ошибка, а организационная и решается на уровне пользователей, а не программы.
Ну класс. Причем этот случай ГОРАЗДО более вероятен чем одновременное изменение и печать документа. Собственно в 95% случаев «некорректных» данных будет именно такой сценарий. Так за что тогда борьба если проблема «организационная и решается на уровне пользователей, а не программы».
То есть вы решили проигнорировать половину сообщения, описывающую реальную проблему, а ответить в своём стиле…
Мы говорили про необходимость блокировок, когда пользователи «открыли» данные или одновременно их используют. И в примере про «печать» как раз рассматривали ситуацию, когда пользователь сидит в документе, он был изменен, после чего она его печатает (она его не меняла). В этот момент и срабатывает блокировка.
Обратную ситуацию, когда она сначала распечатала, потом кто-то поменял я просто упомянул, но эта ситуация — не та, ради которой устраивается блокировка. Ту ситуацию ни в одной системе нельзя обойти, только организационно.
Вы же вместо ответа на основное сообщение переводите фокус на «ситуацию-исключение», как будто это и было основным вопросом. И отвечаете в своём стиле «это никому не нужно».
Мы говорили про необходимость блокировок, когда пользователи «открыли» данные или одновременно их используют. И в примере про «печать» как раз рассматривали ситуацию, когда пользователь сидит в документе, он был изменен, после чего она его печатает (она его не меняла). В этот момент и срабатывает блокировка.
Обратную ситуацию, когда она сначала распечатала, потом кто-то поменял я просто упомянул, но эта ситуация — не та, ради которой устраивается блокировка. Ту ситуацию ни в одной системе нельзя обойти, только организационно.
Вы же вместо ответа на основное сообщение переводите фокус на «ситуацию-исключение», как будто это и было основным вопросом. И отвечаете в своём стиле «это никому не нужно».
Ту ситуацию ни в одной системе нельзя обойти, только организационно.
Так, а смысл бороться с ситуацией, если вы в 95 процентов случае все равно получите проблему. Это как если бы вероятность смерти от рака уменьшалась бы на 5 процентов, если вы не будете пить, ложится спать в 9, не есть ничего вредного и т.п. Знаете что большинство пользователей сказало бы? Ну его нафиг. То есть опять-таки баланс рисков / возможностей.
Потому что мы рассматривали ДРУГУЮ ситуацию…
Все, меня уже не хватает. Либо вы тролли, либо действительно не понимаете о чем речь. Но в любом из этих случаев ваш фузион так и закончится на хабре
Ну так вы сами игнорируете все неудобные вопросы и просто по сути подгоняете решение под ответ. Но согласен, спор уже стал малоконструктивным, так как вы явно начали на личности переходить. Давайте каждый останется при своем, а сторонний читатель сам разберется. Мир, дружба, жвачка.
Грубо говоря — вы перекладываете с больной головы на здоровую.
Ну я могу точно также сказать. В любом случае «Убивайте всех, Господь распознает своих» ©. В смысле сторонний читатель сам разберется, какая позиция ему ближе.
Рассматривать ситуацию, что сначала Маша распечатала, а потом кто-то этот документ изменил не имеет смысла, потому что это уже не техническая ошибка, а организационная и решается на уровне пользователей, а не программы.
Вообще-то техническая. Если нельзя вносить изменения в документ после его распечатывания, то печать документа должна отправлять документ в readonly статус «Распечатан».
Да, именно так — надо кричать «Маша дай отредактировать документ, когда ты его уже отпустишь». Ибо не заметив, что кто-то параллельно внес правку в открытый тобой документ, можно и счет клиенту не на ту сумму отправить…
Это вроде проверяется проверкой версии документа при нажатии кнопки (сохранения / печати /отправки). Если данные успели поменяться другим человеком, пишем об этом и пытаемся смержить. Если удалось — смержить (поменялись другие поля) пишем, что за время редактирования обновлены такие-то поля, пожалуйста проверьте. Если были изменены теже поля, что и у пользователя, соответственно их не мержим и либо извиняемся, что перезатерли их серверными, либо спрашиваем у пользователя что выбрать. В особо тяжёлых случаях при частых можно хранить историю изменений.
Проблема может в связанных записях / справочниках. Но это интерфейсная проблема (как показать изменения, не перегружая интерфейс) и аналитическая (какие данные считать связанными, а какие нет). Алгоритмически там ничего сложного нет. Могут быть сложности с одновременным редактирование больших текстов, но и для них есть решения по разбиению редактирования на атомарные команды и объединение их в батч.
На мой взгляд, блокировать документ или какую-то запись намного геморройнее, потому что нельзя точно выяснить, продолжает человек с документом работать, но например в другой программе, или уже ушёл на обед.
Вообще мне кажется это как раз правильно решается, как вы написали, переводом в статус Распечатан, ограничением, что распечатанные документы изменять нельзя (а точнее нельзя изменять данные которые важны для этого документа, скажем сумму документа), и распечатыванием документа уже после того как документ успешно переведен в статус Распечатан (то есть транзакция успешно завершилась). Собственно lsFusion это все может отлично автоматически разрулить в оптимистическом режиме без блокировки. То есть если транзакция изменяющего будет первой, то документ переведется в распечатанный и распечатается с этим изменением, если нет — распечатается без этого изменения, а изменяющему будет сказано «извините, распечатанный документ нельзя изменять». И хоть десять человек могут изменять этот документ одновременно, пока его не распечатают.
Я только не понял из вашего объяснения, а в 1С, кто вот это все мерженье, проверки какие именно поля изменились и т.п. предполагается должен делать? Платформа или разработчик руками?
Я только не понял из вашего объяснения, а в 1С, кто вот это все мерженье, проверки какие именно поля изменились и т.п. предполагается должен делать? Платформа или разработчик руками?
Я только не понял из вашего объяснения, а в 1С, кто вот это все мерженье, проверки какие именно поля изменились и т.п. предполагается должен делать?
Понятия не имею, я с 1С только как с переводчиком игр в начале нулевых дело имел. В абстрактной платформе наверное должны быть какие-то уже готовые стратегии обработки, и плюс к этому возможность написания своих. Я писал по опыту того, что сам разрабатывал.
Вы некорректно интерпретируете правило Парето.
Точнее так — вы используете его как универсальный ответ на вопрос «почему не реализовано это» — «а вот по правилу Парето это нужно будет в 1% случаев». К сожалению, при разработке ПО:
1) использовать его нельзя. ПО должно учитывать все возможные ситуации и минимизировать риски пользовательской ошибки при работе. Всегда нужна «защита от дурака»
2) когда люди, руководствуясь правилом Парето в виде «80% пользователей пользуются только 20% функционала» решают реализовать 20% функционала, чтобы получить 80% продаж, они натыкаются на проблему, что каждый пользователь использует РАЗНЫЕ 20% функционала.
Точнее так — вы используете его как универсальный ответ на вопрос «почему не реализовано это» — «а вот по правилу Парето это нужно будет в 1% случаев». К сожалению, при разработке ПО:
1) использовать его нельзя. ПО должно учитывать все возможные ситуации и минимизировать риски пользовательской ошибки при работе. Всегда нужна «защита от дурака»
2) когда люди, руководствуясь правилом Парето в виде «80% пользователей пользуются только 20% функционала» решают реализовать 20% функционала, чтобы получить 80% продаж, они натыкаются на проблему, что каждый пользователь использует РАЗНЫЕ 20% функционала.
1) использовать его нельзя. ПО должно учитывать все возможные ситуации и минимизировать риски пользовательской ошибки при работе. Всегда нужна «защита от дурака»
Что значит нельзя? Смысл в том, что если у тебя в 5 процентов случаев могут быть проблемы их и нужно решать в 5 процентов случаев. В гололед надо ездить не больше 50 и очень аккуратно, а в нормальную погоду с разрешенной скоростью и гораздо с меньшей аккуратностью. Если все в нормальную погоду будут ездить как в гололед, город вечно в пробках будет стоять.
Как ваша программа будет определять, когда нужно включать «защиту», а когда не надо?
Ваша аналогия некорректна. IT — достаточно уникальная среда, чтобы не сравнивать ее с простыми «житейскими» ситуациями.
Если пользователь может совершить ошибку — однажды он ее совершит. Задача разработчика ПО — как можно сильнее заблокировать пользователю возможности «совершить ошибку».
Вы же пытаетесь вечно выехать на аналогиях, вместо понимания проблемы, которую вы строите
Ваша аналогия некорректна. IT — достаточно уникальная среда, чтобы не сравнивать ее с простыми «житейскими» ситуациями.
Если пользователь может совершить ошибку — однажды он ее совершит. Задача разработчика ПО — как можно сильнее заблокировать пользователю возможности «совершить ошибку».
Вы же пытаетесь вечно выехать на аналогиях, вместо понимания проблемы, которую вы строите
Как ваша программа будет определять, когда нужно включать «защиту», а когда не надо?
Так это администратор по большому счету должен решать, ну и разработчик (естественно максимально декларативно).
Как например должно по вашему определяться где в 1С должны ставиться управляемые блокировки, а где нет. То то же.
Ваша аналогия некорректна. IT — достаточно уникальная среда, чтобы не сравнивать ее с простыми «житейскими» ситуациями.
Точно, законы логики, оптимизации и вероятностей там не работает.
Если пользователь может совершить ошибку — однажды он ее совершит. Задача разработчика ПО — как можно сильнее заблокировать пользователю возможности «совершить ошибку».
Ну тогда можно просто сделать базу однопоточной и все будет ок. Ну или просто заблокировать пользователю все возможности. Еще раз это всегда вопрос баланса возможностей и рисков. Just business.
Ну и в сто первый раз, lsFusion дает выбор (!), а 1С нет. А сейчас все эти споры мне до боли начинают напоминать классическое «все беды от мяса».
Так покажите, как реализовывается этот выбор. Вы же просто выдает перл за перлом вместо конкретного ответа.
И постоянные переходы на гиперболу… хорошее и логичное действие.
Выбор, что хотите, ставите пессимистичную блокировку (я писал выше как), хотите нет. Что вам конкретно непонятно? Если действительно непонятно, ответьте на вопрос:
И все само встанет на свои места.
Как например должно по вашему определяться где в 1С должны ставиться управляемые блокировки, а где нет.
И все само встанет на свои места.
И вот еще один аспект этой же проблемы: это ответственность пользователей за документы. В 1с из-за явной блокировки документа мы получаем гарантию, что пользователь видел актуальное состояние документа, оценил его, внес изменения и записал. И поэтому можем говорить, что он полностью отвечает за свои исправления.
А как быть в фьюжене, когда даже в процессе редактирования дока, в него уже могут быть внесены изменения другими пользователями? Думаю, это приведет к ситуации, когда никто не может нести ответственность ни за документ, ни за исправления.
А как быть в фьюжене, когда даже в процессе редактирования дока, в него уже могут быть внесены изменения другими пользователями? Думаю, это приведет к ситуации, когда никто не может нести ответственность ни за документ, ни за исправления.
В 1с из-за явной блокировки документа мы получаем гарантию, что пользователь видел актуальное состояние документа, оценил его, внес изменения и записал. И поэтому можем говорить, что он полностью отвечает за свои исправления.
Ну так я также могу и про Google docs сказать. Плюс часто за разные данные в одном документе отвечают разные люди, особенно когда документ сложный или содержит много данных.
Еще раз никто не мешает повесить пессимистичную блокировку. Просто в 99 процентов случаев это не нужно и не удобно. Собственно поэтому например блокировочные системы контроля версий умерли под натиском того же git (хотя там тоже можно те же аргументы про актуальное состояние, его оценку и т.д. привести).
Ну и главное. Основной посыл в том, что lsFusion поддерживает и оптимистичные и пессимистичные блокировки (без хитрых вывертов по сути из коробки), а 1С только пессимистичные.
Когда ваш эфемерный «1%» будет стоить вам миллионы — может задумаетесь о том, что при разработке ПО пользоваться правилом «Парето» (который обычно берут на вооружение продаваны для впаривания) — непозволительная роскошь.
Когда ваш эфемерный «1%» будет стоить вам миллионы
Когда будет стоить миллионы, тогда и включите пессимистичную блокировку (ну или лучше ограничениями поработаете). Пример про гололед я уже приводил выше. Ну и про борьбу оптимистичных блокировок с пессимистичными (кстати борьба SQL-серверов версионников с блокировочниками ну вот прямо один-в-один то что вы говорите, напомнить кто там выиграл).
В том и фишка разработки ПО, что там этот 1% должен быть исключен. Иначе цена вашего ПО — 0 копеек.
Тогда бы все СУБД были блокировочниками. И вообще все бизнес-приложения однопоточными.
Еще раз в бизнесе это всегда про соотношение: Затраты на решение проблемы + затраты на преодоление ограничений от ее решений (например менее эффективную работу сотрудников) vs вероятность возникновения проблему * ущерб ее устранения.
Еще раз в бизнесе это всегда про соотношение: Затраты на решение проблемы + затраты на преодоление ограничений от ее решений (например менее эффективную работу сотрудников) vs вероятность возникновения проблему * ущерб ее устранения.
И вместо ответа — гипербола и уход от ответа. Верной дорогой идете.
Какая гипербола? Это вы уходите от ответа.
Вы же в курсе что версионный режим СУБД МЕНЕЕ целостный (то есть вот эта ваша ошибка на миллион), но гораздо более масштабируемый. И все равно абсолютное большинство сложных нагруженных систем используют именно версионные СУБД. Потому что баланс рисков / возможностей. Или вы не согласны с формулой:
Вы же в курсе что версионный режим СУБД МЕНЕЕ целостный (то есть вот эта ваша ошибка на миллион), но гораздо более масштабируемый. И все равно абсолютное большинство сложных нагруженных систем используют именно версионные СУБД. Потому что баланс рисков / возможностей. Или вы не согласны с формулой:
Еще раз в бизнесе это всегда про соотношение: Затраты на решение проблемы + затраты на преодоление ограничений от ее решений (например менее эффективную работу сотрудников) vs вероятность возникновения проблему * ущерб ее устранения.
Так и есть. Привели сборку текста запроса заказов клиентов в прошлой статье. И пишут: "Вот!!!". А я спрашиваю: "А что вот то?".
А они: "Ну как это можно поддерживать?"
А я спрашиваю: «А что вот то?».
То что весь этот код нужен ТОЛЬКО для проверки ОДНОГО ограничения, а в lsFusion для этого одна декларативная строка кода.
Ну нет же. Не может одна строка кода полностью заменить "километровый" запрос SQL.
Если, конечно, этот километр в одну километровую строку...
Имеется ввиду, что если у вас есть уже в программе какая-то вычисляемая величина, например, "Остаток". То, например, установить ограничение на то, что этот остаток должен быть всегда неотрицательный, можно одной строкой. Независимо от того, от чего эта величина зависит. Да, там может быть в результате километровый SQL-запрос, если эта величина сложно вычисляется, но запрос будет сформирован платформой.
Может. Если платформа сама сгенерит такой инкрементальный запрос. Кстати, строго говоря, с материализованными представлениями тот же Oracle ЕМНИП например так и делает.
Запрос таблицы заказов клиентов это не проверка одного ограничения. А накручивать комментарии к статье не хорошо.
Весь тот код, что есть в первой статье только для проверки одного ограничения. Вы думаете я с кодом не умею работать? Если так то откройте исходники УТ и покажите, где он еще используется. Может я действительно что-то пропустил.
Так это вы накручиваете. Мне если честно не доставляет столько удовольствия, объяснять одни и те же вещи по 100 раз.
Так это вы накручиваете. Мне если честно не доставляет столько удовольствия, объяснять одни и те же вещи по 100 раз.
Насчет монструозных кусков кода. В контексте проблемы неэффективного получения данных вы приводили пример наполнения таблиц к проведению документа из, видимо, УТ. В частности, процедуру ИнициализироватьДанныеДокумента. Видимо, как пример избыточного получения данных и сложных танцев с бубном. Правда, свой контрпример вы привели (и здесь это подтвердили) как проверку очень простого ограничения вроде текущего остатка. А в 1С процедура проведения, для которой и собираются все эти таблицы, выполняет гораздо более широкий набор действий с объектами по определенной бизнес-логике. Это и расчет сопутствующих показателей для всех регистров, и контроль остатков, и различные блокировки на время записи документа, и даже проверка необходимости изменять записи в таблицах, если они не изменились с момента предыдущей записи. Вот по этому я и говорю — вы сравниваете выдранные из контекста боевых решений алгоритмы со своими академичными примерами, а это неправильно.
Насчет разделения на контекст клиента и сервера. Это сделано для уменьшения количества обращений к серверу. В вашем же случае как минимум необходимо постоянное получение обновленных данных об объекте с сервера, что не слишком-то оптимально. Ну или хотя бы постоянная проверка состояния. Опять же, по вашим словам — любая манипуляция происходит в едином контексте на сервере, от вашего клиента поступают лишь команды на манипуляцию. В 1С можно заложить множество бизнес-логики на исполнение только на клиенте, что заметно снизит количество обращений к серверу. И да, для написания максимально оптимального решения программисту необходимо понимать потоки данных Клиент-Сервер.
Далее, про представления. Вы сами на примере некорректно написанного запроса пытались показать, что виртуальные таблицы, к примеру, не подходят для решения такой простой задачи, как вывод остатков в динамическом списке номенклатуры, т.к. будут неоптимально обращаться сразу ко всей таблице остатков без фильтрации по номенклатуре… Хотите верьте хотите нет, но запрос для динамического списка
будет работать оптимально, и выбирать остатки только по тем товарам, которые в данный момент видны на экране пользователю. Более того, даже такой, казалось бы неоптимальный, запрос
будет работать оптимально и не вызовет получения лишних данных
Насчет разделения на контекст клиента и сервера. Это сделано для уменьшения количества обращений к серверу. В вашем же случае как минимум необходимо постоянное получение обновленных данных об объекте с сервера, что не слишком-то оптимально. Ну или хотя бы постоянная проверка состояния. Опять же, по вашим словам — любая манипуляция происходит в едином контексте на сервере, от вашего клиента поступают лишь команды на манипуляцию. В 1С можно заложить множество бизнес-логики на исполнение только на клиенте, что заметно снизит количество обращений к серверу. И да, для написания максимально оптимального решения программисту необходимо понимать потоки данных Клиент-Сервер.
Далее, про представления. Вы сами на примере некорректно написанного запроса пытались показать, что виртуальные таблицы, к примеру, не подходят для решения такой простой задачи, как вывод остатков в динамическом списке номенклатуры, т.к. будут неоптимально обращаться сразу ко всей таблице остатков без фильтрации по номенклатуре… Хотите верьте хотите нет, но запрос для динамического списка
ВЫБРАТЬ
Товары.Наименование КАК Наименование,
ЕСТЬNULL(ТоварыНаСкладах.КоличествоОстаток, 0) КАК КоличествоОстаток
ИЗ
Справочник.Номенклатура КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, Склад = &Склад) КАК ТоварыНаСкладахОстатки
ПО (Товары.Ссылка = ТоварыНаСкладахОстатки.Номенклатура)будет работать оптимально, и выбирать остатки только по тем товарам, которые в данный момент видны на экране пользователю. Более того, даже такой, казалось бы неоптимальный, запрос
ВЫБРАТЬ
СпрККТ.Ссылка КАК Ссылка,
ВложенныйЗапрос.Дата КАК ДатаПоследнегоЧека
ИЗ
Справочник.ККТ КАК СпрККТ
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
МАКСИМУМ(ЧекККМ.Дата) КАК Дата,
ЧекККМ.ККТ КАК ККТ
ИЗ
Документ.ЧекККМ КАК ЧекККМ
СГРУППИРОВАТЬ ПО
ЧекККМ.ККТ) КАК ВложенныйЗапрос
ПО СпрККТ.Ссылка = ВложенныйЗапрос.ККТбудет работать оптимально и не вызовет получения лишних данных
Вот по этому я и говорю — вы сравниваете выдранные из контекста боевых решений алгоритмы со своими академичными примерами, а это неправильно.
Стоп. Я когда выдирал алгоритм, специально поиском проверял, что это код нужен ТОЛЬКО для проверки одного ограничения, что количество товара который отгружается не больше количества товара который приходуется / оприходован. Я там даже пометку сделал
PS: Проверено, эти временные таблицы нигде больше не используются, только для проверки одного простого ограничения.
Если вы найдете, где эти временные таблицы еще используются в УТ, то напишите где этот код найти (правда может за год что-то изменилось). И в любом случае вот это все:
и различные блокировки на время записи документа, и даже проверка необходимости изменять записи в таблицах, если они не изменились с момента предыдущей записи
Это чистая accidental complexity которая в 1С есть, а в lsFusion нет.
В 1С можно заложить множество бизнес-логики на исполнение только на клиенте, что заметно снизит количество обращений к серверу. И да, для написания максимально оптимального решения программисту необходимо понимать потоки данных Клиент-Сервер.
Знаете что такое premature оптимизация и правило Парето? Безусловно возможно есть случаи, где такая тонкая оптимизация может понадобиться. И важно чтобы такая возможность была (и в lsFusion скажем она тоже есть). Но в 97 процентов случаев такая оптимизация все-таки не нужна от слова вообще, а разработчику приходится делать всю эту лишнюю работу, по разделению на &НаКлиенте и &НаСервере, создавая тонны запутанного кода. То есть они с водой ребенка выплеснули.
будет работать оптимально и не вызовет получения лишних данных
А зачем тогда весь этот огород с:
Номенклатура В (
ВЫБРАТЬ Номенклатура
ИЗ Документ.РасходнаяНакладная.Состав
ГДЕ Ссылка = &Документ)
Если она сама все протолкнет и не «вызовет получение лишних данных».
Стоп. Я когда выдирал алгоритм, специально поиском проверял, что это код нужен ТОЛЬКО для проверки одного ограничения, что количество товара который отгружается не больше количества товара который приходуется / оприходован. Я там даже пометку сделал
Вообще-то в процедуре ИнициализироватьДанныеДокумента собираются и, где это возможно, вычисляются все данные для проведения документа по регистрам и дальнейшей проверки на ненулевой остаток. В первую очередь для проведения. Кстати, в статье «Почему не 1С» вы в главе «Отсутствие ограничений и событий для значений регистров» не совсем разобрались зачем нужно получать значения из регистров перед записью и что с ними делается при записи. А именно, вычисляется — какие записи были изменены таким образом, что это может вызвать отрицательные остатки. И проверять отрицательный остаток только для тех регистров, в которых такое вообще могло произойти. А в вашей системе, выходит, агрегирование для контроля остатка производится безусловно, даже если этого можно и не делать? А строк, знаете ли, могут быть миллионы…
Знаете что такое premature оптимизация и правило Парето? Безусловно возможно есть случаи, где такая тонкая оптимизация может понадобиться.
Моя многолетняя практика 1С показывает, что если ERP-система выходит из рамок локальной сети в интернет, то разделение контекстов на клиент и сервер уже не является пустым звуком. Взять хотя бы загрузку данных в условный отчет комиссионера из того же экселя. Он может весить туеву хучу. Зачем гонять его на сервер? Вполне достаточно разобрать его полностью на клиенте и отправить минимальный объем данных на сервер, ну и так далее, боевые примеры могу приводить бесконечно.
А зачем тогда весь этот огород с:
Номенклатура В (
ВЫБРАТЬ Номенклатура
ИЗ Документ.РасходнаяНакладная.Состав
ГДЕ Ссылка = &Документ)
Если она сама все протолкнет и не «вызовет получение лишних данных».
Это чей-то мозговой клин. Программисты самой 1С — тоже люди. Можете смело удалить это условие из параметров виртуальной таблицы — план запроса не изменится.
А в вашей системе, выходит, агрегирование для контроля остатка производится безусловно, даже если этого можно и не делать? А строк, знаете ли, могут быть миллионы…
Нет, в этом и фокус. Всю эту тонну кода, который в 1С разработчик делает руками, lsFusion делает АВТОМАТИЧЕСКИ. Она сама определяет какие данные изменились, сама записывает во временные таблицы, сама строит инкрементальные запросы и т.п.
Моя многолетняя практика 1С показывает, что если ERP-система выходит из рамок локальной сети в интернет, то разделение контекстов на клиент и сервер уже не является пустым звуком. Взять хотя бы загрузку данных в условный отчет комиссионера из того же экселя. Он может весить туеву хучу. Зачем гонять его на сервер? Вполне достаточно разобрать его полностью на клиенте и отправить минимальный объем данных на сервер, ну и так далее, боевые примеры могу приводить бесконечно.
Можно, только в 95 процентов нафиг не нужно (да и в вашем случае сомнительно). Ну сэкономите вы 10% на оборудовании (и то не факт), зато очень сильно увеличите стоимость доработок (так как код будет куда более сложным / непонятным), уменьшите надежность (так как при большем количестве кода куда больше ошибок и т.п.). Классическая premature оптимизация. Опять таки многолетний опыт на очень сложных системах крупной розницы с очень большим объемом данных / пользователей.
Это чей-то мозговой клин. Программисты самой 1С — тоже люди. Можете смело удалить это условие из параметров виртуальной таблицы — план запроса не изменится.
Что значит мозговой клин? Это офдокументация. И что значит не изменится план запроса? Запрос к SQL базе не изменится или план не изменится? Потому как в postgres или файловой очень даже изменится (почитайте этот раздел). Да и в MS SQL, если сгенерится какой нибудь COALESCE (например FULL JOIN), план запроса тоже очень даже изменится. Собственно поэтому в типовых эти предикаты и проталкивают руками.
Для того чтобы это все нормально работало под postgres и даже MS SQL, нужен нормальный аля-CBO оптимизатор запросов сверху, а для этого нужна статистика и много чего еще, а 1С даже более простые вещи не реализовал.
Какой клин? Зачем вообще устанавливают параметры виртуальной таблицы?
Прекратите везде пихать «правило Парето», как универсальный аргумент. Вы не понимаете границ его использования, так еще и лихо меняете, то 97%, то 99%. По факту — это просто демагогический приём манипулирования. Так обычно действуют продаваны, когда хотят туфту пихнуть покупателю.
И да, если любите «правило Парето» — полюбите и «закон Мёрфи» — если что-то плохое может произойти — оно обязательно произойдет. Вот этот закон должен быть основой при разработке ПО, в котором крутятся миллионы.
И да, если любите «правило Парето» — полюбите и «закон Мёрфи» — если что-то плохое может произойти — оно обязательно произойдет. Вот этот закон должен быть основой при разработке ПО, в котором крутятся миллионы.
Прекратите везде пихать «правило Парето», как универсальный аргумент. Вы не понимаете границ его использования, так еще и лихо меняете
Это вы не понимаете его суть. То что в 80 (или 95) процентов может делаться просто должно делаться просто. В остальных случаях должна быть ВОЗМОЖНОСТЬ сделать сложно. Заставлять делать лишнюю работу разработчика это в лучшем случае premature оптимизация и одно из самых больших зол в разработке.
Закон Мерфи — это вообще говоря сатирический (несерьезный) закон. Причем тут он не понятно. И крутятся миллионы это демагогический прием, если вы посчитаете затраты на борьбу с проблемой и сравните с вероятностью проблемы умноженной на ущерб все будет совсем не так как вы видите.
То есть вы предлагаете заставлять делать пользователей 100 раз одну и ту же работу? Вместо того, чтобы разработчику 1 раз сделать так, чтобы это не приходилось делать?
Еще раз — ваш принцип «пусть сами разбираются» не должен быть основным при разработке массового ПО
Еще раз — ваш принцип «пусть сами разбираются» не должен быть основным при разработке массового ПО
Причем тут пользователи? У пользователей как раз все зашибись они работают параллельно, система сама следит за целостностью (гарантируя ее). Те же ситуации когда кто-то кого то затер с тем же пересчетом надуманные, так как пересчет с гораздо (!) большей вероятностью пройдет через 5 секунд после изменения первого пользователя и будут те же яйца.
Еще раз у нас десятки достаточно крупных клиентов (многие из которых по российским меркам вошли бы в топ 20 розничных сетей) именно с огромным числом пользователей и большими документами (причем выносят нам мозг по каждой мелочи) и ни один я не припомню чтобы озвучил нам эту проблему (потому как иначе мы бы им давно включили пессимистичные блокировки). Наоборот счастливы как слоны, что инвентаризацию могут вдесятером менять.
Еще раз у нас десятки достаточно крупных клиентов (многие из которых по российским меркам вошли бы в топ 20 розничных сетей) именно с огромным числом пользователей и большими документами (причем выносят нам мозг по каждой мелочи) и ни один я не припомню чтобы озвучил нам эту проблему (потому как иначе мы бы им давно включили пессимистичные блокировки). Наоборот счастливы как слоны, что инвентаризацию могут вдесятером менять.
НЛО прилетело и опубликовало эту надпись здесь
Если у вас постоянно выстреливают события, вероятность которых составляет сотые, значит вы просто неправильно оценили вероятность.
Ну это из разряда, что давайте откажемся от автомобилей в пользу общественного транспорта, так как есть вероятность погибнуть в ДТП. Опять-таки баланс рисков / затрат / возможностей, сверху сто раз уже обсасывалось.
Любая программа должна учитывают ситуация, какая бы малая вероятность возникновения ее не была.
Ну это из разряда, что давайте откажемся от автомобилей в пользу общественного транспорта, так как есть вероятность погибнуть в ДТП. Опять-таки баланс рисков / затрат / возможностей, сверху сто раз уже обсасывалось.
И опять странные аналогии, в которых вы пытаетесь съехать на «ну посмотрите ну». Сфера ПО настолько отличается от «житейских вещей», что построить грамотную аналогию очень тяжело.
Начиная с того, что ПО — такой товар, который можно создать 1 раз, а продать хоть миллион.
И да, вот вам пример даже из «житейского уровня» — автомобильные гиганты зря что ли делают бесплатную «замену» своим покупателям при появлении в НЕКОТОРЫХ дефекта, который «ну очень маловероятен»? Или «это другое»?) Ведь шанс, что во всех машинах эта проблема воспроизведется — «крайне мала». Но замену делают на всю линейку машин, а это десятки или даже сотни тысяч машин.
Начиная с того, что ПО — такой товар, который можно создать 1 раз, а продать хоть миллион.
И да, вот вам пример даже из «житейского уровня» — автомобильные гиганты зря что ли делают бесплатную «замену» своим покупателям при появлении в НЕКОТОРЫХ дефекта, который «ну очень маловероятен»? Или «это другое»?) Ведь шанс, что во всех машинах эта проблема воспроизведется — «крайне мала». Но замену делают на всю линейку машин, а это десятки или даже сотни тысяч машин.
Они просто считают вероятность проблемы, сумму судебного иска, и стоимость отзыва машин. Если вероятность * сумма иска из-за возникновения проблемы > стоимости отзыва — отзывают. Нет, не отзывают. Уверен на один отзыв, существует сотни выявленных «детских» проблем где это сравнение в обратную сторону и никаких машин при этом не отзывают.
Это всё ваши домыслы. Но вы говорите об этом, как о факте. Вы, случайно, не в руководстве у всех этих фирм?)
Хотя вам не впервой свои фантазии выдавать за реальность
Хотя вам не впервой свои фантазии выдавать за реальность
Это всё ваши домыслы. Но вы говорите об этом, как о факте. Вы, случайно, не в руководстве у всех этих фирм?)
Нет, они монетку бросают отзывать или не отзывать. Не, вы серьезно не понимаете как решения, особенно в бизнесе, принимаются? Там простой KPI максимизация матожидания прибыли (естественно с ограничениями по дисперсии).
НЛО прилетело и опубликовало эту надпись здесь
Не совсем понял. Сделать документ однопользовательским / неразделяемым это тоже проблема удобства / комфорта / возможностей. Можно и Excel файл по очереди редактировать только это неудобно. Точно также как и все файлы в системе контроля версий можно менять по очереди, но это неудобно когда есть git.
НЛО прилетело и опубликовало эту надпись здесь
Да, но для безопасности и целостности не обязательно делать базу «однопоточной» (пессимистичными блокировками). Это крайность. Как правило оптимистичные блокировки — это идеальный баланс между целостностью и удобством / масштабируемостью, и собственно поэтому де-факто стали стандартом в мире / во многих областях.
НЛО прилетело и опубликовало эту надпись здесь
Стоп. Я уже писал, что никто не мешает а) сделать пессимистичную блокировку б) и это более правильно, повесить необходимое ограничение на целостность (скажем что не должно быть 2 строк с одинаковым товаром), которое сведет вероятность ситуации к 0. Ведь если такого ограничения не будет, может включиться человеческий фактор и человек допустит ситуацию просто по ошибке. Не говоря уже о том что пользователи могут просто разминутся и никакая пессимистичная блокировка не поможет. Да и просто предупреждение, что кто-то отредактировал запись, пользователь может тупо проигнорировать.
ну 1с ведь не сразу дорос до своего уровня, в 1с тоже был 7.7. Фузина тоже дорастёт
А зачем вы сравниваете свое решение с 1С? Хотите сделать рекламу «нападением» на армию 1С-ников, которых, думаю существенно больше? Пытаться «выехать» за счет «унижения» другого не самый честный способ (хотя думаю унизить будет сложно, все же 1С хорошая платформа для решения задач для которых она предназначена). Многие 1С-ники сами не в восторге от своего инструмента, но им она даёт больше чем другие. И многим будет интересно просто узнать про возможности других систем.
Например 1С на хабре не занимается сравнением себя с другими, а просто пишут (мало) что и почему они делают.
Например 1С на хабре не занимается сравнением себя с другими, а просто пишут (мало) что и почему они делают.
Потому что когда они НЕ сравнивают себя с 1С (или SQL, или еще кем-то), то их статьи игнорируют (никто не пишет комментариев, плюсы только от 20 сотрудников компании на Хабре).
Всё просто — это их маркетинговая основа.
Вместо того, чтобы говорить, что в фузион хорошо — они пишут, что в 1С плохо. Причем плохо именно по их «авторитетному» мнению, а почему — потому что «правило Парето» и «это не нужно в 99% случаев».
Потому что если будут пытаться показать достоинства своей программы без унижения других — рассказывать почти не о чем. Да и тяжелее будет переводить критику в полемику типа «а вот в 1С хуже»
Вместо того, чтобы говорить, что в фузион хорошо — они пишут, что в 1С плохо. Причем плохо именно по их «авторитетному» мнению, а почему — потому что «правило Парето» и «это не нужно в 99% случаев».
Потому что если будут пытаться показать достоинства своей программы без унижения других — рассказывать почти не о чем. Да и тяжелее будет переводить критику в полемику типа «а вот в 1С хуже»
Всё просто — это их маркетинговая основа.
Вместо того, чтобы говорить, что в фузион хорошо — они пишут, что в 1С плохо. Причем плохо именно по их «авторитетному» мнению, а почему — потому что «правило Парето» и «это не нужно в 99% случаев».
Потому что если будут пытаться показать достоинства своей программы без унижения других — рассказывать почти не о чем. Да и тяжелее будет переводить критику в полемику типа «а вот в 1С хуже»
Преимущества обратная сторона недостатков. Большинство реклам начинаются с показов проблем (типа рвется рубашка, что-то липнет и т.п.). Это как бы основа маркетинга. Понятно что многие могут сказать ну липнет и липнет, ну загрязняет окружающую среду и загрязняет, ну нет того-то и нет. Но реклама то как раз расчитана на тех кто понимает проблему, а не тех кого «все устраивает». Тем кого все устраивает и нет смысла ничего объяснять.
В том и дело, что во всех рекламах:
1) что-то липнет, предлагают решение — это же реклама чистящего средства, а не «против грязи». Грязь не обвиняют, грязь — проблема.
2) когда предлагают своё решение, никогда не поливают грязью других (кроме редких «идейных» противостояний типа пепси-кока, айфон-андроид). В 99% (раз вы любите это число) случаев против «правильного» товара противопоставлен «любой другой товар такого типа». То есть «конкурент» — обезличен. Это негласное правило рекламы, но в других сферах за такое могут и засудить.
Вы же вместо озвучивания проблемы говорите «1С делает это плохо, а Фузион — хорошо». При этом вы сравниваете совершенно различные функциональные элементы. Про это вам уже выше писали. Это как показывать калькулятор свой и чужой на примере «2+2=4». И говорить, что ваш калькулятор оптимизирован, а чужой нет, потому что на примере «2+2=4» он работает быстрее и код меньше.
1) что-то липнет, предлагают решение — это же реклама чистящего средства, а не «против грязи». Грязь не обвиняют, грязь — проблема.
2) когда предлагают своё решение, никогда не поливают грязью других (кроме редких «идейных» противостояний типа пепси-кока, айфон-андроид). В 99% (раз вы любите это число) случаев против «правильного» товара противопоставлен «любой другой товар такого типа». То есть «конкурент» — обезличен. Это негласное правило рекламы, но в других сферах за такое могут и засудить.
Вы же вместо озвучивания проблемы говорите «1С делает это плохо, а Фузион — хорошо». При этом вы сравниваете совершенно различные функциональные элементы. Про это вам уже выше писали. Это как показывать калькулятор свой и чужой на примере «2+2=4». И говорить, что ваш калькулятор оптимизирован, а чужой нет, потому что на примере «2+2=4» он работает быстрее и код меньше.
1) что-то липнет, предлагают решение — это же реклама чистящего средства, а не «против грязи». Грязь не обвиняют, грязь — проблема.
Ну я имел ввиду, что при использовании другого чистящего средства что-то липнет.
когда предлагают своё решение, никогда не поливают грязью других (кроме редких «идейных» противостояний типа пепси-кока, айфон-андроид). В 99% (раз вы любите это число) случаев против «правильного» товара противопоставлен «любой другой товар такого типа». То есть «конкурент» — обезличен. Это негласное правило рекламы, но в других сферах за такое могут и засудить.
У обезличивания всегда есть проблема, что человек начинает думать, что это у других чистящих средств проблемы, а у его все хорошо. Ну и про негласное правило рекламы это конечно весело. Пикирование бмв — ауди помните? И кто там кого засудил?
Вы же вместо озвучивания проблемы говорите «1С делает это плохо, а Фузион — хорошо».
Не понял, я озвучил проблемы на мой взгляд (но при этом пытаясь максимально привязаться к общепризнанным проблемам — блокировок, типизации, полиморфизма и т.п.), показал как они решаются в 1С, и показал как решаются в lsFusion. Если кто-то не согласен, не вопрос, жду в комментах. Вон человек выше начал аппелировать к пункту об отсутствии оптимизатора запросов (что предикат не надо проталкивать), я ему задал вопрос, он исчез (видимо ушел разбираться). Я честно очень ждал еще в прошлой статье, чтобы кто-то предметно что-то опроверг (но все свелось к сам дурак, автор ничего не понимает, это все не нужно и т.п.). Ну ок.
Про картинку совсем не понял. Про 4 пункт ответил абзацем выше, с 3 во многих пунктах есть проблема с метрикам, но где мог я их использовал (показывая сколько кода, приблизительно правда, в 1С, а сколько в lsFusion получается, например в ограничениях и разделении сервера и клиента), с 2 мы наоборот делаем продукт максимально не похожим, ну а 1 пункт про детализацию это как раз и есть разбор по 30 конкретным пунктам, куда уж детальнее.
1) это и есть недобросовестное сравнение. И да — «липнет» в вашем примере — существует только в вашем воображении. Это как «не думай о розовом кролике». Проблемы может в принципе не быть, но её придумывают, хотя раньше проблемой это не считалось.
2) пикирование многих известных брендов — это поддерживаемая ими игра. Использовать прямое противопоставление мало кто решается. И в любом случае это далеко не «добросовестная реклама».
3) «показывая сколько кода» — ну да, только в 1С этот кусок кода используется и в других местах, но об этом вы, конечно, «забываете». И не надо заливать, вы сравниваете не возможности платформы, а конкретные РЕШЕНИЯ с вашими выверенными примерами, которые вы сами подбираете. Это как говорится «тут считаем, тут не считаем, тут переворачиваем».
Про разделения на клиент и сервер — вам уже писали. Ранее разделения не было, потом решили добавить… Хм… Может была ПРИЧИНА такого разделения?) Хотя нет, бред. Всё, что сделано в 1С — по определению плохо.
30 «конкретных пункта, которые мы придумали» ) вам неоднократно высказывались про сомнительность вашего выбора и аргументации в пунктах.
2) пикирование многих известных брендов — это поддерживаемая ими игра. Использовать прямое противопоставление мало кто решается. И в любом случае это далеко не «добросовестная реклама».
3) «показывая сколько кода» — ну да, только в 1С этот кусок кода используется и в других местах, но об этом вы, конечно, «забываете». И не надо заливать, вы сравниваете не возможности платформы, а конкретные РЕШЕНИЯ с вашими выверенными примерами, которые вы сами подбираете. Это как говорится «тут считаем, тут не считаем, тут переворачиваем».
Про разделения на клиент и сервер — вам уже писали. Ранее разделения не было, потом решили добавить… Хм… Может была ПРИЧИНА такого разделения?) Хотя нет, бред. Всё, что сделано в 1С — по определению плохо.
30 «конкретных пункта, которые мы придумали» ) вам неоднократно высказывались про сомнительность вашего выбора и аргументации в пунктах.
И да — «липнет» в вашем примере — существует только в вашем воображении. Это как «не думай о розовом кролике». Проблемы может в принципе не быть, но её придумывают, хотя раньше проблемой это не считалось.
Ну или наоборот проблема существует, просто вы ее не видите. Думаю сто лет назад, люди ездящие на лошадях тоже проблем не видели, ну ездят и ездят.
Хотя в данном случае большая часть проблем уже стандарты в других областях.
И в любом случае это далеко не «добросовестная реклама».
Не помню из какого фильма, но осталась в голове фраза: «Тогда тем более нет смысла играть честно».
3) «показывая сколько кода» — ну да, только в 1С этот кусок кода используется и в других местах
Я уже четвертый раз спрашиваю. В каких еще местах используется это кусок кода. Так никто не может УТ открыть и показать мне этот кусок.
И не надо заливать, вы сравниваете не возможности платформы, а конкретные РЕШЕНИЯ с вашими выверенными примерами, которые вы сами подбираете. Это как говорится «тут считаем, тут не считаем, тут переворачиваем».
Честно устал повторять, что я просто взял ПРИМЕРЫ из типовых решений. Не знаю как вам еще это объяснить. Давайте сторонний читатель сам решит.
Может была ПРИЧИНА такого разделения?)
Бритву Хэнлона помните? «Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью». Хотя я называл причину, так было проще, и очень по программерски, просто переложить проблему на других программистов.
вам неоднократно высказывались про сомнительность вашего выбора и аргументации в пунктах.
Да, но никто по существу ничего не написал. Ну не всерьез же воспринимать аргументы, что полиморфизм это все происки империализма, if'ов более чем достаточно.
1) проблема есть, потому что ВЫ так сказали?) А другие проблемы надуманные (с которыми Фузион не справится), потому что ВЫ так сказали?) Мне если честно уже смешно читать ваши ответы, когда одни проблемы существуют по вашей воле, а другие таковыми не признаются по вашей же воле. Удобно.
2) Вот это и вся суть вашего маркетинга. Грязные приёмы для очернения конкурента. Но мы — не в политике. И тут такое не считается нормой. А реальным пользователям и покупателям нужна не грязь других, а плюсы вашего решения.
3) Всем просто лень. ВЫ вытащили этот код, так ПОТРУДИТЕСЬ посмотреть его использование. Бремя доказательства висит на обвинении. Вы обвиняете решение в том, что часть кода используется для решения малой задачи. Так ДОКАЖИТЕ это. А требовать доказательств от защиты — «удобно».
4) В том то и дело. Вы ВЗЯЛИ примеры из типовых РЕШЕНИЙ. УДОБНЫЕ вам примеры. И сравниваете с УДОБНЫМ вам РЕШЕНИЕМ. Это не сравнение двух платформ. Это сравнение решений, где вы сами выбираете «оружие», «арену» и «правила». В итоге всё сравнение оказывается пшиком. Сранений платформы тут очень мало.
5) О да, всё глупость, если связано с 1С. И всё гениально, если сделано мной) ещё одна «удобная» парадигма маркетинга.
6) В том и фишка, что ваши «аргументы» настолько несостоятельны, что пытаться их логически опровергнуть тяжела. Это как доказывать человеку, что Земля не плоская) И любой ваш аргумент он перебьет своей очередной фантазией.
2) Вот это и вся суть вашего маркетинга. Грязные приёмы для очернения конкурента. Но мы — не в политике. И тут такое не считается нормой. А реальным пользователям и покупателям нужна не грязь других, а плюсы вашего решения.
3) Всем просто лень. ВЫ вытащили этот код, так ПОТРУДИТЕСЬ посмотреть его использование. Бремя доказательства висит на обвинении. Вы обвиняете решение в том, что часть кода используется для решения малой задачи. Так ДОКАЖИТЕ это. А требовать доказательств от защиты — «удобно».
4) В том то и дело. Вы ВЗЯЛИ примеры из типовых РЕШЕНИЙ. УДОБНЫЕ вам примеры. И сравниваете с УДОБНЫМ вам РЕШЕНИЕМ. Это не сравнение двух платформ. Это сравнение решений, где вы сами выбираете «оружие», «арену» и «правила». В итоге всё сравнение оказывается пшиком. Сранений платформы тут очень мало.
5) О да, всё глупость, если связано с 1С. И всё гениально, если сделано мной) ещё одна «удобная» парадигма маркетинга.
6) В том и фишка, что ваши «аргументы» настолько несостоятельны, что пытаться их логически опровергнуть тяжела. Это как доказывать человеку, что Земля не плоская) И любой ваш аргумент он перебьет своей очередной фантазией.
1) проблема есть, потому что ВЫ так сказали?) А другие проблемы надуманные (с которыми Фузион не справится), потому что ВЫ так сказали?) Мне если честно уже смешно читать ваши ответы, когда одни проблемы существуют по вашей воле, а другие таковыми не признаются по вашей же воле. Удобно.
Ну я точно тоже самое могу сказать про ВАС. Еще раз, не надо считать читателей за идиотов, тем более что все читатели разные и для кого то что-то проблема, а для кого-то нет. Я уже приводил, что для кого-то кто на лошадях ездит, тоже проблем нет. И?
2) Вот это и вся суть вашего маркетинга. Грязные приёмы для очернения конкурента. Но мы — не в политике. И тут такое не считается нормой. А реальным пользователям и покупателям нужна не грязь других, а плюсы вашего решения.
Не понял где вы нашли грязь? В статье показано как те или иные вещи делаются в 1С, и к каким проблемам на взгляд автора они приводят. Не считаете это проблемами, ок, ваше право. Уверен многие потребители тех же ДВС автомобилей не считают многие преимущества Тесла преимуществами (и соответственно недостатки ДВС недостатками), тоже их право.
3) Всем просто лень. ВЫ вытащили этот код, так ПОТРУДИТЕСЬ посмотреть его использование. Бремя доказательства висит на обвинении. Вы обвиняете решение в том, что часть кода используется для решения малой задачи. Так ДОКАЖИТЕ это. А требовать доказательств от защиты — «удобно».
Ничего себе лень? Я там со всех сторон облазил код, чтобы найти другие использования не нашел. И как мне доказывать, записать видео, где я ищу по названиям временных таблиц или хожу по дереву вызовов и не нахожу других использований? Как раз единственный вариант что-то доказать — это наоборот найти использование, но что-то пока никто не может.
4) В том то и дело. Вы ВЗЯЛИ примеры из типовых РЕШЕНИЙ. УДОБНЫЕ вам примеры. И сравниваете с УДОБНЫМ вам РЕШЕНИЕМ. Это не сравнение двух платформ. Это сравнение решений, где вы сами выбираете «оружие», «арену» и «правила». В итоге всё сравнение оказывается пшиком. Сранений платформы тут очень мало.
Строго говоря, я нашел вообще первый попавшийся пример. Если вы найдете как в УТ ставится ограничение на остаток декларативно одной строкой, без триггеров, построения дельт и т.п. (хотя я понимаю что это теоретически в 1С не возможно), милости прошу.
5) О да, всё глупость, если связано с 1С. И всё гениально, если сделано мной) ещё одна «удобная» парадигма маркетинга.
6) В том и фишка, что ваши «аргументы» настолько несостоятельны, что пытаться их логически опровергнуть тяжела. Это как доказывать человеку, что Земля не плоская) И любой ваш аргумент он перебьет своей очередной фантазией.
Я так и понял. «Ой, все». Серьезно, такой спор реально не имеет смысла, давайте завязывать.
Большинство реклам начинаются с показов проблем (типа рвется рубашка, что-то липнет и т.п.)
Да, но там сравнивают с «Обычным стиральным порошком».
Преимущества обратная сторона недостатков
Тогда опишите свои недостатки.
Ваша реклама на хабре для кого? Кого пытаетесь привлечь? Конечный потребитель суда заходит редко. Переманить на свою сторону «армию» 1С-ников? Многие ваши примеры для большинства 1С-ников не являются проблемой из-за которой они должны менять свой основной инструмент (превращение 1С в почти монополию тому доказательство). В результате те 1С-сники что хорошо знают свой инструмент и более активны чем остальные, становятся скорее вашими противниками чем сторонниками.
1С и lsFusion это инструмент для зарабатывания денег. Люди готовы менять инструмент только если он будет приносить им больший доход. Лучше покажите на примере «абстрактного» внедренца, почему он будет зарабатывать больше.
Да, но там сравнивают с «Обычным стиральным порошком».
Так я бы наоборот гордился, что 1С стал настолько нарицательным, что его считают «обычным стиральным порошком».
Тогда опишите свои недостатки.
Мы когда-то начинали описывать. Но платформа меняется поэтому некоторые недостатки могут появляться / уходить.
Ваша реклама на хабре для кого? Кого пытаетесь привлечь? Конечный потребитель суда заходит редко. Переманить на свою сторону «армию» 1С-ников? Многие ваши примеры для большинства 1С-ников не являются проблемой из-за которой они должны менять свой основной инструмент (превращение 1С в почти монополию тому доказательство). В результате те 1С-сники что хорошо знают свой инструмент и более активны чем остальные, становятся скорее вашими противниками чем сторонниками.
1С и lsFusion это инструмент для зарабатывания денег. Люди готовы менять инструмент только если он будет приносить им больший доход. Лучше покажите на примере «абстрактного» внедренца, почему он будет зарабатывать больше.
Есть такая штука — кривая Роджерса (кривая восприятия инноваций). Ее фишка в том что 85 процентов всегда будет воспринимать любые инновации негативно. Так было с Эппл, теслой, фейсбуком, Биткойнами и с чем угодно. И такие люди пересядут на условную теслу, только когда на ней уже все будут ездить. А пока для этих majority / lagards все новое (что apple'ы, что теслы в свое время) это выскочки глючные и неудобные.
Соответствие негативное восприятие неизбежно. А значит всегда имеет смысл ориентироваться на свое, пусть даже более глубокое и при этом не всегда очевидное, видение, а не на видение большинства. Это не гарантия успеха, но другого пути нет. Никому не нужен второй сап, 1с и т.п., когда есть первый. Более быструю лошадь всегда лучше сделает производитель лошадей, если ты хочешь иметь шанс победить нужно делать автомобиль.
То есть если подытожить, все эти материалы для 2% innovators и частично для 13% early adopters. Пытаться угодить остальным 85% это бесперспективная вещь, и как ни парадоксально хейт от них даже часто работает в плюс (так как лучше отделяет и позиционирует тебя на рынке). Ну и опять-таки написание таких статей занимает не слишком много времени, а в спорах рождается истина (начинаешь гораздо лучше понимать свои сильные и слабые стороны, на что лучше делать акценты и т.п.).
Ну а зарабатывать будет больше, так как сможет предложить более гибкий, технологичный, дешевый в сопровождении и т.д. продукт заказчику. То есть дать заказчику больше, потратив на это меньше времени, тем самым больше заработав. Где-то снизу я уже про это писал.
Не тешьте себя фантазиями. Вы не эппл. и не Тесла, вам США не будут деньги подкидывать из военного бюджета для войны с 1С.
Как можно «зарабатывать больше», если продукт будет «дешевый в сопровождении»?)
Как можно «зарабатывать больше», если продукт будет «дешевый в сопровождении»?)
Не тешьте себя фантазиями. Вы не эппл. и не Тесла, вам США не будут деньги подкидывать из военного бюджета для войны с 1С.
Да, да. Я в курсе что Теслы, SpaceX'ы, Apple'ы и прочие фейсбуки это все пузыри, существуют только благодаря военным бюджетам и обману инвесторов, и скоро лопнут и все такое. Ведь только у одного Маска есть деньги, его же конкуренты бедны как мыши.
Как можно «зарабатывать больше», если продукт будет «дешевый в сопровождении»?)
Так заказчик будет платить в два раза меньше чем остальным, а вы будете тратить времени в 4 раза меньше. Итого в 4 раза больше сделаете и в 2 раза больше заработаете. Win-win.
Итого в 4 раза больше сделаете и в 2 раза больше заработаете
Это при неограниченном спросе. Вы ведь понимаете что спрос по большей части сейчас весь удовлетворён.
А когда вы станете монополистом, половине тех кто сейчас этим занимается нужно будет менять сферу деятельности.
Это при неограниченном спросе. Вы ведь понимаете что спрос по большей части сейчас весь удовлетворён.
Ну не знаю. У нас заказчики постоянно фонтанируют новыми идеями / доработками / изменениями текущих процессов. И многие не наши заказчики понимают, что их текущие решения накопили огромные технические долги, и ищут соответственно чем их заменить (правда чтобы не потерять то что есть, сделать все бесшовно и не очень дорого).
По поводу Теслы — по финансовым отчетам фирма в глубоком минусе по теме с автомобилями. Держится за счёт других проектов.
По поводу «больше продать» — спрос всегда ограничен. Особенно рынок мелких решений, на который нацелен Фузион. А при составлении «сложных» решений без наличия «комплектов» АКА «типовых» — становится не так уж и дёшево по вашим же названным ценам «часа»
По поводу «больше продать» — спрос всегда ограничен. Особенно рынок мелких решений, на который нацелен Фузион. А при составлении «сложных» решений без наличия «комплектов» АКА «типовых» — становится не так уж и дёшево по вашим же названным ценам «часа»
Особенно рынок мелких решений, на который нацелен Фузион.
Да конечно. Нам, например, мелкие решения наоборот не настолько интересны. У нас 70% крупного ритейла Беларуси клиенты (это больше 4к сотрудников и больше 200 млнов долларов в год обороты). И типовые есть, то же lsFusion ERP (хотя это скорее набор из тысяч модулей), из модулей которого как из кубиков составляется решение, которое потом начинает достраиваться под конкретное видение заказчика.
Многие 1С-ники сами не в восторге от своего инструмента, но им она даёт больше чем другие. И многим будет интересно просто узнать про возможности других систем.Так наилучший способ это сделать — показать, как проблемы 1С решаются в других системах. Для этого сначала надо сформулировать проблемы (что было сделано в статье «Почему не 1С»), а затем предложено решение. Что не так?
Ну как говорится «все познается в сравнении». Собственно когда человек выбирает любой инструмент (не только в ИТ), он как правило читает про недостатки одних инструментов и преимущества других (собственно недостатки и преимущества всегда являются зеркальным отражениям друг друга).
Статья — очень странная попытка вылезти в сравнении с 1С. Большая часть перечисленного давным давно реализована на сервере приложений. Такое ощущение, что автор сравнивает свое «Решение» с 7.7. 1С — это не только отлаженная бизнес-модель, но и универсальность и гибкость. Да и 99% рынка в РФ никто не отменял. Так что… Вы для начала СКД хотя бы реализуйте;)
Наоборот как раз. Части проблем этой / предыдущей статьи в 7.7 нет (например из-за ОФ, автоматических блокировок и т.п.).
Ага только скорость / стоимость разработки, надежность, поддерживаемость решений в последних версиях оставляет мягко говоря желать лучшего (я сейчас не про примитивный CRUD, а когда на руках уже сложная система аля УТ, или даже хотя бы УНФ). Собственно в этой статье и заключении я насчитал только под 30 пунктов.
Ну прям таки 99%. Даже в БУХ и ЗУП хорошо если 90%. А скажем в управленческих решениях крупного ритейла или банках того же 1Са очень мало. Ну или если горизонтально смотреть, в WMS они не лидер, в CRM тоже нет, в электронном документообороте тоже мимо, ну и т.п.
но и универсальность и гибкость
Ага только скорость / стоимость разработки, надежность, поддерживаемость решений в последних версиях оставляет мягко говоря желать лучшего (я сейчас не про примитивный CRUD, а когда на руках уже сложная система аля УТ, или даже хотя бы УНФ). Собственно в этой статье и заключении я насчитал только под 30 пунктов.
Да и 99% рынка в РФ никто не отменял
Ну прям таки 99%. Даже в БУХ и ЗУП хорошо если 90%. А скажем в управленческих решениях крупного ритейла или банках того же 1Са очень мало. Ну или если горизонтально смотреть, в WMS они не лидер, в CRM тоже нет, в электронном документообороте тоже мимо, ну и т.п.
Ничего не понятно, но очень интересно! )
Первый вопрос, раз статья на хабра, значит желаете привлечь в первую очередь ИТ специалистов. Дайте ссылку на туториал, как развернуть систему и написать простейшую учетную систему, например «Домашняя бухгалтерия». Посмотрите по аналогии с 1С «Радченко. Практическое пособие разработчика.», ознакомление с платформой в таком ключе было бы максимально понятным.
Вот это страшно! 1С когда-то вместо «пользователь Excel» использовала слово «бухгалтер».
Это наследие до сих пор не дает спокойно спать по ночам многим 1Сникам.
Далее, вы упираете только на бесплатность, простоту разработки(и то пока под вопросом), и скорость? Или еще что-то есть?
Чтобы, например, презентовать систему руководству компании должно быть что-то еще.
И потом, вы пишете что платформа все делает сама, супер круто и супер эффективно. И что разработчику ничто низкоуровневое не нужно.
Блин! Я такое уже слышал про 1С! «Какие ваши доказательства?»(с)
Первый вопрос, раз статья на хабра, значит желаете привлечь в первую очередь ИТ специалистов. Дайте ссылку на туториал, как развернуть систему и написать простейшую учетную систему, например «Домашняя бухгалтерия». Посмотрите по аналогии с 1С «Радченко. Практическое пособие разработчика.», ознакомление с платформой в таком ключе было бы максимально понятным.
Дорабатывать на базе MyCompany сможет любой продвинутый пользователь Excel.
Вот это страшно! 1С когда-то вместо «пользователь Excel» использовала слово «бухгалтер».
Это наследие до сих пор не дает спокойно спать по ночам многим 1Сникам.
Далее, вы упираете только на бесплатность, простоту разработки(и то пока под вопросом), и скорость? Или еще что-то есть?
Чтобы, например, презентовать систему руководству компании должно быть что-то еще.
И потом, вы пишете что платформа все делает сама, супер круто и супер эффективно. И что разработчику ничто низкоуровневое не нужно.
Блин! Я такое уже слышал про 1С! «Какие ваши доказательства?»(с)
В этом блоге есть уже довольно много статей с ответами на, по крайней мере, часть ваших вопросов.
Первый вопрос, раз статья на хабра, значит желаете привлечь в первую очередь ИТ специалистов. Дайте ссылку на туториал, как развернуть систему и написать простейшую учетную систему, например «Домашняя бухгалтерия». Посмотрите по аналогии с 1С «Радченко. Практическое пособие разработчика.», ознакомление с платформой в таком ключе было бы максимально понятным.
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=2228236
ru.lsfusion.org/try
Хотя согласен есть над чем работать.
Вот это страшно! 1С когда-то вместо «пользователь Excel» использовала слово «бухгалтер».
Это наследие до сих пор не дает спокойно спать по ночам многим 1Сникам.
Ну так 1С всегда был чистой императивщиной. Они пытались ее замаскировать визуальным программированием, но это тоже самое в другой обертке.
Далее, вы упираете только на бесплатность, простоту разработки(и то пока под вопросом), и скорость? Или еще что-то есть?
Чтобы, например, презентовать систему руководству компании должно быть что-то еще.
Еще модульность (это один из важных кейсов, причем как вертикальная, так и горизонтальная, то есть поставляются только те модули что нужно, а не зайдите в пятую вкладку, тут не смотрите там не жмите, это на всякий случай заполните, а то не пропустит), технологичность (веб, все дела), производительность (у нас огромные сети с постоянно дорабатываемой логикой тысячами одновременных пользователей, на весьма дешевом железе работают, причем даже во многих случаях без кластеризации), целостность (если есть ограничение оно железобетонное, а не как в остальных системах, дай проведу неоперативно просто), эргономичность (например тот же параллельный ввод, который тут уже полветки обсуждаем) и т.п.
Но на самом деле основное все же скорость / простота разработки, так как это по факту дает три вещи:
1. Бизнес начинает управляться через ИТ-систему (по факту процессы внедряются именно в ИТ-систему, создавая декларативные ограничения, которые пользователи не могут обойти и по факту им приходится работать как надо, «организационное» управление становится вторичным)
2. ИТ-система подстраивается под бизнес, а не наоборот (что позволяет реализовывать именно свои know how, а не универсальный бест-практис, который подходит только какому-то среднему бизнесу и по сути нивелирует конкретно твои конкурентные преимущества)
3. ИТ-система внедряется постепенно бесшовно без риска для бизнеса, сначала as is (причем с полной интеграцией по мастерданным, часто в обе стороны) потом постепенно мигрируя в to be.
И вот эти вещи на самом деле мы как правило продаем.
А вообще тут на первой странице собрано про платформу (про продуктам отдельные сайты есть / делаются и там вот это все сверху есть / будет):
ru.lsfusion.org
Еще модульность (это один из важных кейсов, причем как вертикальная, так и горизонтальная, то есть поставляются только те модули что нужно
Вот это в маркетинге мне всегда нравилось. )))
«Наша система модульная, какой хочешь модуль, тот и подключаешь». Ага, а зависимости между модулями? И их синергия?
«А модуль Бух учета хочу, Модуль казначейства хочу, а модуль номенклатуры нет.» Как кто в этом случае будет все эти связи учитывать? А то что одни модули влияют на интерфейс и функции других модулей?
В lsFusion в принципе разработка модульная. Архитектурно. Посмотрите раздел про модульность. Собственно в модуле вы можете использовать только элементы из зависимых модулей.
На практике это выглядит как. Есть верхний модуль, скажем вот пример по умолчанию:
github.com/lsfusion-solutions/mycompany/blob/master/src/main/lsfusion/MyCompany.lsf
Но вы можете включить / выключить любой узел в графе модулей и получите ровно то, что нужно.
На практике это выглядит как. Есть верхний модуль, скажем вот пример по умолчанию:
github.com/lsfusion-solutions/mycompany/blob/master/src/main/lsfusion/MyCompany.lsf
Но вы можете включить / выключить любой узел в графе модулей и получите ровно то, что нужно.
Ну так со временем верхние модули будут требовать много других. В результате «подключаемыми» по желанию будут только те, на которые никто не ссылается. А это обычно совсем небольшие по функционалу вещи.
Ну и в догонку, в 1С это тоже есть уже несколько лет. Называется «расширение».
Ну и в догонку, в 1С это тоже есть уже несколько лет. Называется «расширение».
Так все модули требуют другие модули (посмотрите тоже lsFusion ERP или MyCompany). А дальше вопрос, не помню точную характеристику, мощности что-ли этого графа. Но важный момент, что граф ацикличный (то есть он всегда разрезаемый), да и по опыту получается весьма разреженный (хотя зависит конечно от разработчика).
Причем тут расширения вообще не понятно (я их кстати упоминал в первой статье), по факту это один маленький частный случай, когда есть один модуль (само монолитное решение) и второй модуль (его кастомизация), а не граф из большого количества слабосвязанных модулей как в lsFusion.
Причем тут расширения вообще не понятно (я их кстати упоминал в первой статье), по факту это один маленький частный случай, когда есть один модуль (само монолитное решение) и второй модуль (его кастомизация), а не граф из большого количества слабосвязанных модулей как в lsFusion.
хотя зависит конечно от разработчика
Тогда это совсем не про платформу.
он всегда разрезаемый
То что его где-то можно разрезать != разрезать можно там где хочешь. Но это всегда умалчивается при продаже «модульности». По факту для конечного пользователя выбор какие модули включать, а какие нет достаточно ограничен. Можно конечно купить машину без тахометра, но не поменяв при этом «торпеду» ездить с «дыркой» на месте тахометра никто не захочет.
Тогда это совсем не про платформу.
И от платформы тоже зависит, причем даже в большей степени.
То что его где-то можно разрезать != разрезать можно там где хочешь.
Ну мир не черно-белый.
По факту для конечного пользователя выбор какие модули включать, а какие нет достаточно ограничен
А вы уже настолько глубоко попробовали lsFusion, что можете делать такие выводы? Или знаете какой-то аналог платформ, хотя бы близко находящийся по возможностям модульности (скажем обладающих настолько декларативными ограничениями и формами, расширениями, открытыми классами, компиляцией всего этого в немодульный SQL и т.п.), чтобы это утверждать? Или это просто в стиле ни у кого не получилось и у вас не получится?
Это называется «Логика» и «опыт».
Ну либо в момент, когда модули будут становиться слишком «зависящими друг от друга» вы будете делать фокус «а тут не 3 модуля, а 1, так что модульность никуда не делась». Но это будет лишь фокус, а не модульность
Ну либо в момент, когда модули будут становиться слишком «зависящими друг от друга» вы будете делать фокус «а тут не 3 модуля, а 1, так что модульность никуда не делась». Но это будет лишь фокус, а не модульность
Вы сейчас в Нострадамуса играете.
Откуда вы знаете? У вас большой опыт в lsFusion или хоть в чем то похожем (хотя даже понятие не имею что может быть хоть близко похоже)? Вот у меня большой опыт.
Вот скажем граф модулей MyCompany (скрин из IDEA, к сожалению не получается сделать, чтобы имена читались).
Это называется «Логика» и «опыт».
вы будете делать фокус
Откуда вы знаете? У вас большой опыт в lsFusion или хоть в чем то похожем (хотя даже понятие не имею что может быть хоть близко похоже)? Вот у меня большой опыт.
Вот скажем граф модулей MyCompany (скрин из IDEA, к сожалению не получается сделать, чтобы имена читались).
А вы уже настолько глубоко попробовали lsFusion, что можете делать такие выводы?
Проблема модульности не в используемой платформе. Проблема в самой идее. Модули это значит зафиксированные связи между модулями, убрать модуль на который кто-то рассчитывает нельзя, нужно делать заглушку или замену и в результате модуль «потребитель» должен всегда быть готов что на «другом» конце нужного нет. В результате реализовывать это все очень накладно, нужно не только логику реализовать, но и все возможные варианты связи.
Тут ведь вопрос обычно в том, насколько язык/платформа позволяют минимизировать количество связей между сущностями из разных модулей. В lsfusion для этого есть набор механизмов (расширения, subtype полиморфизм, открытые классы и т. п.), которые позволяют вам уменьшить количество таких связей.
А так то, понятно, что любая модульность может быть убита ошибками проектирования.
Тут ведь вопрос обычно в том, насколько язык/платформа позволяют минимизировать количество связей между сущностями из разных модулей.
Количество связей ведь определяет бизнес-задача. Модули и объекты это всего лишь способ описания их взаимодействия и интерфейс для манипуляции ими. Модули сами по себе не существуют. И проблема в том, что может платформа и позволяет, но задачи которые с её помощью решаются в большинстве случаев разделению поддаются очень плохо.
Например автомобиль. Вроде все сделано модульно, хочешь стекла не ставь (на юге ездишь). Хочешь сидения назад не ставь (ездишь только в двоём. Вроде много можно «убрать». Но многие вещи типа колёса, двигатель, коробка передач, полный привод или только передний или задний просто так не поменяешь. Программы они конечно более гибкие, но от этого проблема связи легче не становится, т.к. этих самых связей становится еще больше.
Я, честно говоря, в контексте логических зависимостей не вижу большой разницы между задачами, которые решаются с помощью платформы, и произвольными сложными задачами вообще. С зависимостями борются везде. И способов для этого придумали уже довольно много. Одни и те же бизнес-задачи, реализованные в коде, могут иметь совершенно разное количество связей и это зависит в том числе и от того, какой инструмент у вас под рукой.
Более того, я вижу как в наших решениях реализуется довольно много вещей, которые вообще мало от чего зависят: это и интеграции с какими-то внешними системами, интеграции с оборудованием, и какие-то отчеты, и какие-то постоянные дополнительные пожелания клиентов, которые выносятся в отдельные модули. В наших решениях вполне нормально используется модульность, предоставляемая платформой.
По опыту разработки мобильных приложений на котлине могу сказать что модульность вполне реальна. Также, как бывший 1сник могу сказать что на учетные системы это тоже при желании вполне может лечь. Достаточно чтобы инструментарий это нормально поддерживал и разработчики решений научились. Feature модули зависят от core и util модулей, а так же от feature-api других модулей. Объединяется это все через DI в app модуле, либо в DI feature модуля который от других модулей зависит. В свое время мне подобных возможностей при работе с 1с знатно не хватало. Мы свою конфу разрабатывали, и в ней бы очень даже нашлось применение модульности. Особенно для адаптации под заказчиков. Было бы гораздо более удобные переиспользование фичей и их доработка.
Сделайте, пожалуйста, сравнение с Odoo — на первый взгляд именно Odoo является основным конкурентом, а никак не 1С
lsFusion — это универсальная платформа для разработки информационных систем и бизнес-приложений. В ней нет ни одной прикладной сущности.
Odoo (по заголовку их сайта и википедии) — это ERP и CRM система, которая написана на python. Напишите, пожалуйста, где можно почитать именно про платформу Odoo. Тогда можно будет сделать сравнение.
Сравнивать lsFusion с Python — не совсем корректно. Это разного уровня фреймворки.
Odoo (по заголовку их сайта и википедии) — это ERP и CRM система, которая написана на python. Напишите, пожалуйста, где можно почитать именно про платформу Odoo. Тогда можно будет сделать сравнение.
Сравнивать lsFusion с Python — не совсем корректно. Это разного уровня фреймворки.
Ну формально в Odoo есть надстройка на питон, какой то частный случай материализаций. Но у них да, платформа очень сильно слита с решением и поэтому тяжело с ними сравнивать.
А зачем, тогда, вы сравниваете свою «платформу» с типовыми решениями от 1С?
Где вы увидели сравнение с типовыми решениями? Из типовых решений просто примеры кода берутся, чтобы показать наглядность тех или иных проблем / особенностей (а берутся примеры именно из типовых, чтобы исключить аргумент «они просто не правильно держат»).
Вы иллюстрируете превосходство вашей «платформы» по сравнению с кодом «прикладного приложения на платформе», при этом без учета особенностей этого решения, и считаете, что вы сравниваете платформы? Серьёзно?
Серьезно. Они не понимают очень многих вещей, к которым 1С шло не один год. Но слышать они это не хотят
Нет я сравниваю именно абстрактные возможности платформы, как создаются ограничения, как и когда проверяются ошибки (явная типизация), как обеспечивается расширяемость логики (полиморфизм и модульность), как делается оптимизация (оптимизаторы, динамическая физическая модель), как обеспечивается целостность (блокировки), как разработка UI идет. А код прикладного решения приводится в качестве иллюстрации. Ну вроде же очевидные вещи.
А вы какую то демагогию с «учетом особенностей этого решения» приводите. Я вам больше скажу обычно решения подгоняют под платформу, а не наоборот. Просто по определению.
А вы какую то демагогию с «учетом особенностей этого решения» приводите. Я вам больше скажу обычно решения подгоняют под платформу, а не наоборот. Просто по определению.
Наглядность тех или иных «проблем» (которые вы сами придумали и героически превозмогаете).
Многие вещи в 1С можно реализовать намного более «грубыми» и простыми методами. И кода будет намного меньше. Но 1С последние годы идет на «универсальность», что неизбежно увеличивает «техническую» часть кода.
Насколько помню, вам уже предлагали написать «тестовый» функционал совместно с 1С-ником, но так этот функционал и не появился.
Многие вещи в 1С можно реализовать намного более «грубыми» и простыми методами. И кода будет намного меньше. Но 1С последние годы идет на «универсальность», что неизбежно увеличивает «техническую» часть кода.
Насколько помню, вам уже предлагали написать «тестовый» функционал совместно с 1С-ником, но так этот функционал и не появился.
Наглядность тех или иных «проблем» (которые вы сами придумали и героически превозмогаете).
Ну конечно, так и думал, что все эти явные типизации, полиморфизмы, материализованные представления, ограничения, модульность и т.п. в других технологиях это просто люди сами себе проблемы придумали. Ей богу «немцы какие-то, взять все и поделить».
Многие вещи в 1С можно реализовать намного более «грубыми» и простыми методами. И кода будет намного меньше. Но 1С последние годы идет на «универсальность», что неизбежно увеличивает «техническую» часть кода.
Не будет. 1С идет на масштабируемость получаемых решений, а не универсальность (она как раз не сильно изменилась). Но делает это не автоматически как lsFusion, а перекладывает все на плечи разработчика. Про это все хорошо рассказано в первой статье.
В общем, Lsfusion победил. Пора на нее всем переезжать.
Вот совсем не понимаю, на какую целевую аудиторию рассчитана данная статья. Технические подробности реализации самой lsFusion читать интересно, но постоянное сравнение с платформой 1С вызывает только рукалицо. Я сам разработчик 1С и к платформе отношусь как к рабочему инструменту. И получая деньги за свои компетенции в рамках данного инструмента, я бы никогда даже не посмотрел в сторону lsFusion как нового рабочего инструмента, не только за подобный «сравнительный» маркетинг. Судя по комментариям, с вами вообще бесполезно дискутировать, статья полна неточностей и противоречий по приводимым примерам работы платформы 1С, которые воспринимаются как некое несущественное, хотя вы же и используете их в своих тезисах преимущества lsFusion. После такого отношения к своему же конкуренту, сразу возникает вопрос — а какое отношение будет к разработчику, решившим использовать lsFusion?
Вот совсем не понимаю, на какую целевую аудиторию рассчитана данная статья
Я сверху уже вроде отвечал на этот вопрос. Хотя если вкратце, то на тех кто понимает описанную в статьях проблематику (в смысле модульность, типизацию, оптимизацию запросов, блокировки, полиморфизм и т.п.)
Судя по комментариям, с вами вообще бесполезно дискутировать, статья полна неточностей и противоречий по приводимым примерам работы платформы 1С,
Честно говоря с удовольствием бы почитал хоть одну предметную претензию. Неточности возможны (и я бы с удовольствием их исправил), но противоречий пока никто вроде внятно не привел. Понятно, что где-то может быть некоторый субъективизм, но так он везде есть.
Ну и конечно с аргументом «это все не проблемы» тяжело спорить, но я собственно и не пытаюсь.
После такого отношения к своему же конкуренту, сразу возникает вопрос — а какое отношение будет к разработчику, решившим использовать lsFusion?
Странный вопрос. В стиле «если вы так относитесь к своим врагам, как вы относитесь к своим друзьям?». Естественно отношение наилучшее. Как говорил Фрейд (не конкретно в таком виде, но мысль именно такая): «Если вы любите всех, то не любите никого».
Впрочем я не скажу, что 1С это враги или отношение к ним негативное. Нет, наоборот они молодцы, оказались в нужное время в нужном месте, пошли правильным путем (именно сделав бизнес platform-based, а не на закрытых решениях как остальные). Но в данном случае они конкуренты, соответственно противопоставлять себя конкурентам это как бы основа любого выхода на рынок. Ничего личного, просто бизнес.
Самое, что ни на есть открытое (в отличие от фирмы 1С). Чтобы проверить, можете зайти в группу Slack, и попробовать там задать любой вопрос по существу.
Фильтрация — если скажем необходимо отфильтровать все записи с текущим полем > заданного значения (закопана в Еще -> Настроить список, где необходимо найти нужную колонку и сделать еще несколько нажатий).
Это вы alt+F для себя еще не открыли?
А как там найти > заданного значения? Оно же вроде чисто на = ищет. Во всяком случае в демке УТ на trade.demo.1c.ru/trade/ru_RU
А, это «больше», обычно словами пишут… Никак, да, это для случаев «найти все документы этого клиента» или «найти платежку на 12345,67 рублей».
Если нужно сложное условие, то оно однократно настраивается через Еще и выводится на форму списка, а далее может быть распространено на других пользователей копированием настроек, например, при внедрении. Так закрываются любимые вами 99% юзкейсов, а за 1% не грех и в Еще сбегать/консультанту позвонить.
Если нужно сложное условие, то оно однократно настраивается через Еще и выводится на форму списка, а далее может быть распространено на других пользователей копированием настроек, например, при внедрении. Так закрываются любимые вами 99% юзкейсов, а за 1% не грех и в Еще сбегать/консультанту позвонить.
Не совсем понял. Вот зашел я в произвольную форму и мне надо найти платежку не на 12345,67, а на около 10к рублей (я помню, что она от 5к до 20к). Собственно мне это и надо сделать однократно и не надо никуда выводить / сохранять / распространять. Это просто супербазовый кейс, вроде подсчета суммы по колонке или количества записей (которые, например, когда мы помню убрали из быстрого доступа, так нас клиенты чуть не убили, пришлось быстро назад возвращать). Зачем с точки зрения UX его так глубоко закапывать? Хотя как я писал в статье весь этот пункт сугубо субъективный (то есть про вкус и цвет фломастеров).
надо сделать однократно
супербазовый кейс
Какое-то противоречие.
Наш опыт говорит что чаще ищут по контрагенту или дате. Если нужно более сложное условие Еще->Настройка списка. А там уже можно сделать все что хочется и вывести себе эти настройка в «быстрый доступ» если это супербазовый кейс.
Зачем с точки зрения UX его так глубоко закапывать
Борьба за минимизацию «кнопок» на форме. «классический» подход который был до версии 8.2 вызывал ряб в глазах от обилия кнопок.
Нет, вы не поняли, супербазовый кейс, в произвольной форме, по произвольному колонке найти все значения в диапазоне (такой fuzzy поиск по числовым данным). И не надо никуда ни в какой быстрый доступ выносить (а то вся форма будет в быстрых доступах).
Просто странная логика — «искать по строке» почему то вынесено в быстрый доступ, а по числовым данным нет (потому как по числовым данным искать на точное совпадение это глупо никто не помнит суммы наизусть). А поиск по числовым данным уж точно не более редкая штука чем по строковым. Собственно в этом и вопрос к их UX. И так во многих мелочах (например подсчет сумма по колонке или количество записей в отборе).
Просто странная логика — «искать по строке» почему то вынесено в быстрый доступ, а по числовым данным нет (потому как по числовым данным искать на точное совпадение это глупо никто не помнит суммы наизусть). А поиск по числовым данным уж точно не более редкая штука чем по строковым. Собственно в этом и вопрос к их UX. И так во многих мелочах (например подсчет сумма по колонке или количество записей в отборе).
Потыкал ваше решение, то что майкомпани. Не, ну прикольно, Причем по компактности — вы выиграли где то в 3 раза, конечно за счет форм, которые в 1с — представлены в виде кучи хмл.
И подумываем даже может дальше потыкать.
Но ответьте пока на следующее — где получить тесты, которыми вы прогоняете все конфигурации, и платформу в том числе, а также советы, или даже готовые пайплайны для настройки контуров.
Так же интересует — что у вас с мультиязычной поддержкой? Я понял, что вы выносите все в ресурсы, но некоторые вещи меня заставляют окунаться прям в мир типовых. А именно — тут ошибка в ключе? Или это фича.
А тут почему написан текст харкодом? Та и не только тут, а прям по всей системе. Это фича?
Что у вас с курсами? Хотел бы где-то детальней почитать — как сделать конфу уровня Хеллоу ворд! То, что у вас есть на сайте — сходу осилить не смог, как-то опять кидает в стандарты w3org, от которых тошнит просто. Если ваша ЦА — 1Сники, которых вы хотите переманить на свою сторону, то отразите это в документации, проведите аналоги, ибо я сейчас с трудом вникаю в вашу парадигму, она для меня чужая.
Что там с документацией? Где ее почитать? Как она встраивается в систему? Как с ней может работать пользователь? То, что нашел на сайте — не убедительно, от слова — вообще. Вы взяли прям лучшее от 1С, где в документах — «Документ продаж — это документ продаж».
Мне кажется, надо идти больше от кейсов, или хотя бы примеры кейсов привести, чтобы я понял, что для создания продаж — мне надо ткнуть три клика. Потому что, то что я вижу в справке РМК — это 11 скринов, и какие я их них могу пропустить, и как будет выглядеть когда все настроено — не понятно.
На счет интерфейса — он мега убогий (мое субъективное мнение) — можно ли его самостоятельно как то причесать? А то там прям все везде расходится, и меня накрывают флешбеки от дельфей форм, только в вебе. Т.е. на сколько я могу это все кастомизировать?
P.S. Вы вебинары делаете, или типо того, чтобы можно было лично вопросы позадавать, получить ответы и прочее.
И подумываем даже может дальше потыкать.
Но ответьте пока на следующее — где получить тесты, которыми вы прогоняете все конфигурации, и платформу в том числе, а также советы, или даже готовые пайплайны для настройки контуров.
Так же интересует — что у вас с мультиязычной поддержкой? Я понял, что вы выносите все в ресурсы, но некоторые вещи меня заставляют окунаться прям в мир типовых. А именно — тут ошибка в ключе? Или это фича.
А тут почему написан текст харкодом? Та и не только тут, а прям по всей системе. Это фича?
Что у вас с курсами? Хотел бы где-то детальней почитать — как сделать конфу уровня Хеллоу ворд! То, что у вас есть на сайте — сходу осилить не смог, как-то опять кидает в стандарты w3org, от которых тошнит просто. Если ваша ЦА — 1Сники, которых вы хотите переманить на свою сторону, то отразите это в документации, проведите аналоги, ибо я сейчас с трудом вникаю в вашу парадигму, она для меня чужая.
Что там с документацией? Где ее почитать? Как она встраивается в систему? Как с ней может работать пользователь? То, что нашел на сайте — не убедительно, от слова — вообще. Вы взяли прям лучшее от 1С, где в документах — «Документ продаж — это документ продаж».
Мне кажется, надо идти больше от кейсов, или хотя бы примеры кейсов привести, чтобы я понял, что для создания продаж — мне надо ткнуть три клика. Потому что, то что я вижу в справке РМК — это 11 скринов, и какие я их них могу пропустить, и как будет выглядеть когда все настроено — не понятно.
На счет интерфейса — он мега убогий (мое субъективное мнение) — можно ли его самостоятельно как то причесать? А то там прям все везде расходится, и меня накрывают флешбеки от дельфей форм, только в вебе. Т.е. на сколько я могу это все кастомизировать?
P.S. Вы вебинары делаете, или типо того, чтобы можно было лично вопросы позадавать, получить ответы и прочее.
Ниже мой коллега ответил на большинство вопросов.
Единственное, что хотелось добавить, что пока и lsFusion и MyCompany в первую очередь позиционируются как open source проект. То, что Вы описываете — это больше про enterprise. Я про курсы, вебинары и прочее.
UPD:
А что именно Вы хотите кастомизировать? Только выравнивание?
Единственное, что хотелось добавить, что пока и lsFusion и MyCompany в первую очередь позиционируются как open source проект. То, что Вы описываете — это больше про enterprise. Я про курсы, вебинары и прочее.
UPD:
На счет интерфейса — он мега убогий (мое субъективное мнение) — можно ли его самостоятельно как то причесать? А то там прям все везде расходится, и меня накрывают флешбеки от дельфей форм, только в вебе. Т.е. на сколько я могу это все кастомизировать?
А что именно Вы хотите кастомизировать? Только выравнивание?
Это мега огромное заблуждение. Что это ентерпрайз. Посмотрите на опен сорц проекты в том же мире 1с — там общество активно пилит статьи, документации, вебинары и прочее. Без этого всего — только вы будете знать что-то о вашей системе.
Я бы даже подал заявку на Infostart, и выступил там с докладом по этой теме.
Без популяризации — это не опен сорц проект, это просто — пет проект, и никто, кроме вас — на него не будет смотреть серъезно.
Вот вы в своих статьях накидываете на вентилятор, а для таких как я — людей, которые видели уже десяток «убийц 1С», воспринимается нами как «убийца айфона».
Посмотрите в сторону OScript, Vanessa Automation и т.д. — это тоже опен сорц проекты, но им верят. И они зарабатывали эту веру годами, докладами, доказательствами, спорами, а не набрасывали :) И они в таком же положении как и вы — ибо они, хотят конкурировать с 1С и их продуктами, и у них — это получается, и они — вызывают уважение. Поучитесь у них. Я без сарказма, просто — совет.
На счет форм — он просто страшный, вот реально, я без подколов и приколов, такой продукт будет продать сложно. Интерфейс перегружен, слишком сложен и не редко — не интуитивно понятен. Я себя ощущал пилотом самолета. Куча кнопок, переключаетелей, все этих тонах Виндовс 95. Аж мурашки по коже :)
Я бы даже подал заявку на Infostart, и выступил там с докладом по этой теме.
Без популяризации — это не опен сорц проект, это просто — пет проект, и никто, кроме вас — на него не будет смотреть серъезно.
Вот вы в своих статьях накидываете на вентилятор, а для таких как я — людей, которые видели уже десяток «убийц 1С», воспринимается нами как «убийца айфона».
Посмотрите в сторону OScript, Vanessa Automation и т.д. — это тоже опен сорц проекты, но им верят. И они зарабатывали эту веру годами, докладами, доказательствами, спорами, а не набрасывали :) И они в таком же положении как и вы — ибо они, хотят конкурировать с 1С и их продуктами, и у них — это получается, и они — вызывают уважение. Поучитесь у них. Я без сарказма, просто — совет.
На счет форм — он просто страшный, вот реально, я без подколов и приколов, такой продукт будет продать сложно. Интерфейс перегружен, слишком сложен и не редко — не интуитивно понятен. Я себя ощущал пилотом самолета. Куча кнопок, переключаетелей, все этих тонах Виндовс 95. Аж мурашки по коже :)
Я бы даже подал заявку на Infostart, и выступил там с докладом по этой теме.
Безотносительно всего остального. Infostart принадлежит 1С. Я помню какой-то человек разобрался написал статью про lsFusion на инфостарте, ее в течении 3 часов удалили.
Я себя ощущал пилотом самолета. Куча кнопок, переключаетелей, все этих тонах Виндовс 95. Аж мурашки по коже :)
Ну это мир бизнес-приложений. К сожалению или к счастью. SAP, Axapta, 1С, OEBS и т.п. (все что сложнее простенького бизнеса) неизбежно приходят к этому, так как сами пользователи требуют слишком много информации на форме. Хотя мне тоже всегда казалось, что должна быть одна кнопка. Но что-то не получается ни у кого.
Безотносительно всего остального. Infostart принадлежит 1С
Повторюсь — не с теми людьми вы общаетесь значит. Найдите серьезных людей, которые реально могут осветить эту тему, и которых не смогут просто так удалить. Если та статья была написана точно в таком же стиле — то я понимаю, почему ее удалили.
Но будьте готовы, что этих людей — надо будет убеждать, и это те люди, которые понимают проблемы 1С, и ее приимущества, и с ними такой вброс не выйдет. Если надо помощь в поиске таких людей — напишите в личку, я поспрашиваю у некоторых, может кто и согласится.
Плюс, есть независимые площадки, где вот недавно делали сборище программистов 1С и САП, и ребята освещали плюсы и минусы обоих систем, делились знаниями, это было тепло и лампово.
Но что-то не получается ни у кого.
У кого не получается? Как то очень категорично вы говорите. У той же 1с — все значительно лучше, посмотрите в ту же сторону УНФ последней. Ваша же модель напоминает Оракл, САП и голые SQL таблицы, отсюда и ваши «плюшки» — типо редактирования одного документа но разные строки. Что, кстати, в 1С сделать очень просто, и делается, но редко, в силу кучи причин.
Вы посчитайте просто количество кликов, вы на столько отстаете по интерфейсам, что тут можно отдельную статью писать.
Ввод по строке — ужасен, вы заставляете открывать таблицу, прогружать ее и делать в ней поиск — зачем? Я знаю все свои склады, или клиентов, я хочу в поле ввести кусок текста и подставить, мне не надо формы открывать.
У вас таб гуляет по всему окну, зачем? Мне надо идти последовательно, я не хочу три кнопки нажимать на каждое действие.
Зачем справа внизу кнопки ОК и ЗАКРЫТЬ? Какова их функция в списках документов?
Почему кнопка добавить справа внизу — горячая зона — левый верхний квадрат экрана, у меня рука устала, когда я пытался пару документов сделать.
У вас нет контраста элементов, вот та одна — две основные кнопки, которые мне надо нажать для подтверждения и не искать их среди прочего серого фона.
При чем тут никто не смог? Вы просто взяли интерфейс для SQL таблиц, и попытались назвать его юзер френдли, или оправдаться тем что это ЕРП. Не ребят, так это не работает :)
Повторюсь — не с теми людьми вы общаетесь значит. Найдите серьезных людей, которые реально могут осветить эту тему, и которых не смогут просто так удалить. Если та статья была написана точно в таком же стиле — то я понимаю, почему ее удалили.
Да нет, там был человек с рейтингом, со статьями на Инфостарте, и статья была вообще не про 1С и уж точно не с критикой. Было что-то вроде lsFusion глазами 1С-разработчика, скорее наоборот ругательная на lsFusion, что некоторые вещи по другому и непонятно. Но ее все равно удалили. Поэтому не совсем понятно зачем двигаться на сайт конкурента, если в любой момент Инфостарт может тупо все забанить и запретить вообще упоминать там lsFusion.
Но будьте готовы, что этих людей — надо будет убеждать, и это те люди, которые понимают проблемы 1С, и ее приимущества, и с ними такой вброс не выйдет. Если надо помощь в поиске таких людей — напишите в личку, я поспрашиваю у некоторых, может кто и согласится.
Большое спасибо, я думаю мы в свое время воспользуемся вашим предложением. Но естественно, как вы наверное понимаете, русскоязычный сегмент не самая приоритетная цель. Согласитесь странно делать технологию, сложность реализации и инновационность подходов которой превышает скажем современные SQL-сервера, чтобы воевать с ней на очень маленьком да и еще весьма консервативном и консолидированном рынке (мы в свое время делали market research и чем-то похожая ситуация есть только в Бразилии). Русскоязычный сегмент хорош в качестве отличной проверки идей, без публичного выхода на мировой рынок (так как release early это хорошо, но только если ты собираешься fail fast, потому как иначе большинство запомнит тебя по первом впечатлению). А русскоязычный сегмент как уже говорилось консервативен и весьма токсичен (в хорошем смысле) и может указать тебе на твои недостатки, когда на западе тебе просто улыбнутся, но промолчат. Понятно что другие рынки могут отличаться (и скорее всего отличаются) от русскоязычного, но на рынке информационных систем очевидного окна возможностей нет, это уже давно brownfield, поэтому и сильно спешить тоже смысла особого нет. Поэтому если у вас есть знакомые, которые могли бы помочь в продвижении на англоязычный / мировой рынок (например с опытом medium/reddit, естественно после того как мы дообработаем весь фидбек и по сайту и по платформе и по остальному) мы бы были даже больше благодарны (я например знаю alexlash вроде этим занимается).
У той же 1с — все значительно лучше, посмотрите в ту же сторону УНФ последней. Ваша же модель напоминает Оракл, САП и голые SQL таблицы
Смотря о каких решениях речь, и опять таки спорный вопрос насколько отсутствие / наличие лишней информации это хорошо или плохо. Все что вы говорите это не от хорошей жизни, многие пользователи хотят видеть больше информации, даже если она не очень красиво или эргономично расположена. Да можно раскидать по вкладкам как это делает 1С, но это технические моменты. Плюс надо понимать, что lsFusion в отличии от остальных сильно модульна, обычно подключается только часть модулей и соответственно интерфейсы автоматически «разгружаются».
Что, кстати, в 1С сделать очень просто, и делается, но редко, в силу кучи причин.
Интересно как? Кто-то предлагал через подчиненные документы, но не понятно как это все потом сливать / изменять. И опять-таки, как мы спорили выше, оптимистичные блокировки во всех областях победили пессимистичные (и в SQL-серверах и в системе контроля версий и в электронных таблицах). Не вижу причин почему они не победят в бизнес-приложениях, так как это также удобно.
Ввод по строке — ужасен, вы заставляете открывать таблицу, прогружать ее и делать в ней поиск — зачем? Я знаю все свои склады, или клиентов, я хочу в поле ввести кусок текста и подставить, мне не надо формы открывать.
Тут согласен и это уже начали делать. Хотя мне с отдельным окном, если честно даже больше нравится (но может просто привык).
У вас таб гуляет по всему окну, зачем? Мне надо идти последовательно, я не хочу три кнопки нажимать на каждое действие.
Не совсем понял, можете пояснить немного.
Зачем справа внизу кнопки ОК и ЗАКРЫТЬ? Какова их функция в списках документов?
В списках документов ОК нужна и показывается, когда прямо на форме можно что-то изменять. Соответственно это сохранить и закрыть.
Почему кнопка добавить справа внизу — горячая зона — левый верхний квадрат экрана, у меня рука устала, когда я пытался пару документов сделать.
Философский вопрос. Дело в том что в большинстве UI, кнопки ОК и закрыть в правом нижнем углу. Скажем в Windows (например Печать), в Excel, в IDEA. Да даже тут на хабре кнопки отправить и предпросмотр снизу а не сверху (пусть и слева). То есть это дань традициям. Хотя да, я заметил что во многих бизнес-приложениях они начали мигрировать налево вверх, может и мы туда их мигрируем.
У вас нет контраста элементов, вот та одна — две основные кнопки, которые мне надо нажать для подтверждения и не искать их среди прочего серого фона.
Тут согласен, но надо понимать, что lsFusion делался изначально более абстрактным чем 1С и поэтому кноки ОК, Сохранить и Закрыть внутри ничем не отличаются от других добавленных разработчиком. Другое дело, что их действительно наверное стоило бы по умолчанию как-то контрастировать (но это всегда может сделать разработчик как это сделано в MyCompany).
При чем тут никто не смог? Вы просто взяли интерфейс для SQL таблиц, и попытались назвать его юзер френдли, или оправдаться тем что это ЕРП. Не ребят, так это не работает :)
Вот честно не понимаю, что мы имеете ввиду под «интерфейс для SQL таблиц». Мы как раз сделали максимально абстрактный интерфейс, который просто отображает множество объектов с различными их свойствами (естественно предполагая что все эти элементы могут быть связаны друг с другом). Это во многом 1С сделал узкую песочницу из «справочник-документ-отчет» и пытается любую логику подогнать под нее, и убедить всех что так и надо. Что же история рассудит, они как раз двигаются на мировой рынок, посмотрим как у них это получится.
Наша команда занимается тем, что разарбтывает системы на базе 1С под другие рынки, и уже есть внедрения и куча опыта с очень крупными компаниями. И вам там никто ничего не будет говорит, откроют, посмотрят, не понравится — пойдут дальше. Ну и если нет своего представительства на тех рынках — тоже очень сложно.
Русскоязычный хоть и токсичен, а мечтает на запад, и если ваше решение им даст возможсность туда свалить, то будут учить :)
Вы так критичны в своих словах, будьте немного аккуратнее — у нас тоже система полностью модульная, и сделана она на базе 1С. И от модульности есть сложности с интерфейсами, но они вполне решаемые, просто не надо на них забивать.
Регистром сведений по регистратору и регламентные проводки в многопоточном режиме по куче регистров. Используется в очень крупных внедрениях. Где количество строк в одном документе — влегкую превышает 100 000 строк.
Я табом хочу переключатся по элементам в активной форме, зачем мне табпрыгает на подсистемы и выходит за рамки формы?
Следи за белым кроликом — все что вы привели в пример — додумайте до конца. Кнопка не справа внизу, или слева, кнопка там, где стоит курсор после предыдущего действия в ожидании нового. На хабре я пишу комент — у меня кнопка отправить — перед глазами. У вас — я переключаюсь на список документов слева вверху, у меня кнопка создать (т.е. следующее логическое действие) — справа внизу…
Еще раз — меньше пафоса, серъезно. 1С не сделала песочницу, вы вначале поймите — почему они так сделали, и не от «умников», и сделали они это не от глупости. А потому что идеалогия бизнеса такая — справоник — это информация, которая не меняется, документ — это отражение бизнес процесса.
У вас все те же документы и справочники в системе, и что? Ну да, они могут быть гибкими, заменять друг друга? Но, через пару лет, если вы обрастети комьюнити — вы сделаете гайд, где скажите — ребята, для отражения бизнес процесса — создайте/используйте этот класс, мы в нем все предусмотрели. И назовем этот класс — документ. Вот и все — вы стали 1С :)
Мы внедряем 1С после сапа и после оракла, или рядом с ними, и когда мы говорим бизнесу — что ребята, если мы уйдем, вы найдете программиста, который вам разрулит всю систему по винтикам за пару дней. И мы не врем. А в случае когда даже в 1с умудряются быдлокодить — то что уж говорить про вашу систему :)
Ладно, я опять с учениями. Ничего, это проходит, мы тоже такими были, и было прикольно :)
Русскоязычный хоть и токсичен, а мечтает на запад, и если ваше решение им даст возможсность туда свалить, то будут учить :)
Плюс надо понимать, что lsFusion в отличии от остальных сильно модульна, обычно подключается только часть модулей и соответственно интерфейсы автоматически «разгружаются».
Вы так критичны в своих словах, будьте немного аккуратнее — у нас тоже система полностью модульная, и сделана она на базе 1С. И от модульности есть сложности с интерфейсами, но они вполне решаемые, просто не надо на них забивать.
Интересно как? Кто-то предлагал через подчиненные документы, но не понятно как это все потом сливать / изменять
Регистром сведений по регистратору и регламентные проводки в многопоточном режиме по куче регистров. Используется в очень крупных внедрениях. Где количество строк в одном документе — влегкую превышает 100 000 строк.
Не совсем понял, можете пояснить немного.
Я табом хочу переключатся по элементам в активной форме, зачем мне табпрыгает на подсистемы и выходит за рамки формы?
Философский вопрос. Дело в том что в большинстве UI, кнопки ОК и закрыть в правом нижнем углу.
Следи за белым кроликом — все что вы привели в пример — додумайте до конца. Кнопка не справа внизу, или слева, кнопка там, где стоит курсор после предыдущего действия в ожидании нового. На хабре я пишу комент — у меня кнопка отправить — перед глазами. У вас — я переключаюсь на список документов слева вверху, у меня кнопка создать (т.е. следующее логическое действие) — справа внизу…
Это во многом 1С сделал узкую песочницу из «справочник-документ-отчет» и пытается любую логику подогнать под нее, и убедить всех что так и надо.
Еще раз — меньше пафоса, серъезно. 1С не сделала песочницу, вы вначале поймите — почему они так сделали, и не от «умников», и сделали они это не от глупости. А потому что идеалогия бизнеса такая — справоник — это информация, которая не меняется, документ — это отражение бизнес процесса.
У вас все те же документы и справочники в системе, и что? Ну да, они могут быть гибкими, заменять друг друга? Но, через пару лет, если вы обрастети комьюнити — вы сделаете гайд, где скажите — ребята, для отражения бизнес процесса — создайте/используйте этот класс, мы в нем все предусмотрели. И назовем этот класс — документ. Вот и все — вы стали 1С :)
Мы внедряем 1С после сапа и после оракла, или рядом с ними, и когда мы говорим бизнесу — что ребята, если мы уйдем, вы найдете программиста, который вам разрулит всю систему по винтикам за пару дней. И мы не врем. А в случае когда даже в 1с умудряются быдлокодить — то что уж говорить про вашу систему :)
Ладно, я опять с учениями. Ничего, это проходит, мы тоже такими были, и было прикольно :)
Наша команда занимается тем, что разарбтывает системы на базе 1С под другие рынки, и уже есть внедрения и куча опыта с очень крупными компаниями. И вам там никто ничего не будет говорит, откроют, посмотрят, не понравится — пойдут дальше. Ну и если нет своего представительства на тех рынках — тоже очень сложно.
Именно. Поэтому фидбек на русскоязычных рынках очень важен.
Русскоязычный хоть и токсичен, а мечтает на запад, и если ваше решение им даст возможсность туда свалить, то будут учить :)
Тут согласен, и кстати это скорее всего именно ключевой момент в борьбе с местными решениями. То есть «убийца 1С» ИМХО в текущей парадигме может придти только с запада. Даже если он на несколько порядков лучше.
Вы так критичны в своих словах, будьте немного аккуратнее — у нас тоже система полностью модульная, и сделана она на базе 1С. И от модульности есть сложности с интерфейсами, но они вполне решаемые, просто не надо на них забивать.
А как вы решаете проблемы модульности вот какого плана. В lsFusion выключаешь модуль, один показатель исчезает и он автоматически выпиливается из всех запросов (ну то есть, например, если JOIN нужен для другого показателя он остается, если нет выпиливается). Тоже самое вопрос с flow'ом, в lsFusion все состоит из набора небольших событий, из которых платформа сама собирает один большой flow. А как вы процедуры проведения разрезаете? И сколько у вас модулей в итоге получается? Скажем в том же MyCompany ЕМНИП под 530 модулей и достаточно разреженное дерево, я кидал выше скрин, из которого можно собрать любое поддерево).
Регистром сведений по регистратору и регламентные проводки в многопоточном режиме по куче регистров. Используется в очень крупных внедрениях. Где количество строк в одном документе — влегкую превышает 100 000 строк.
Все равно если честно не понял. Регистр сведений это же по сути просто таблица. То есть вы просто в обход базовой парадигмы документа просто в таблицу записываете? А что тогда с распроведением / проведением, удалением документа? Блокировками?
Про остальное чуть позже напишу, мне реально интересно.
А как вы решаете проблемы модульности вот какого плана. В lsFusion выключаешь модуль, один показатель исчезает и он автоматически выпиливается из всех запросов (ну то есть, например, если JOIN нужен для другого показателя он остается, если нет выпиливается).
Если есть такое — значит архитектура не продумана верно. ничего не должно вырезаться в виде середины строки запроса.
Мы это разруливаем тем, что у нас просто к запросу прикрепляется еще один запрос, или прикрепляется он к подзапросу верзней таблицы, и потом оттуда тянуться все данные.
Вобщем это вообще не проблема. Настройка модуля сама позволяет вывести в нужных местах реквизиты и сама подтягивается ко всем нужным модулям.
А как вы процедуры проведения разрезаете?
Вы серъезно? Это проблема решается тупо одной функцией на каждый регистр, где адо добавить движения, или перехват текущих — если надо изменить. Хотя мы этого и не жалуем.
И сколько у вас модулей в итоге получается?
Модули в нашем понимании — это некий законченый функционал, например — подсистема прав модуля — полностью генерирует все права на лету, без захода даже в конфигуратор. Подсистема рассчета себестоимости — рассчитывает все и вся, в независмости от того сколько модулей стоит. Подсистемы производства — полностью производственный цикл, с планирванием, резервами, калькуляциями и прочей чухней. Модули интеграции с интернет магазинами — полностью отдельная подсистема. Сейчас доделываем бух. модуль, и некоторый функционал выносим из ядра в модули, типо доп. реквизиты, мультивалютный учет.
Отдельно подключаются модули для интеграции с банками, рассчетами скидок, налогов и прочего, отдельно модули отчетов, модули работы с оборудованием и прочее. И все могут работать в любом порядке и комбинации.
Вес нашего ядра — 3Мб, количество строк — в 3 раза больше чем у вас (если выкинуть xml форм), но это связано с тем, что у нас нет классов, и некоторые вещи надо дублировать. А так — наверное был бы меньше :)
Я не знаю что вы считаете модулями, но 530? Кто их будет подключать то?
Все равно если честно не понял. Регистр сведений это же по сути просто таблица. То есть вы просто в обход базовой парадигмы документа просто в таблицу записываете? А что тогда с распроведением / проведением, удалением документа? Блокировками?
А что тут понимать? Есть документ, внутри него светит регистр сведений, отменяете проведение — снимается активность строк, проводите — строки обновляются. Идет рассчет МД5 строки, если строка не изменилась, то проводки, даже при проведении не должны меняться. Блокировки — это элементы головняка, но решаются установкой блокировки на объект лока в таблице регистра сведений. Потом висит план обмена, в него падает — что были изменено, и висит регламент, который бежит по нему, распаралелливает и делает 100 поток для отражения движений, часть из которых валится в эластик, часть в стандратные регистры, часть в другие базы, и т.д.
Так что в жестком энтерпрайзе — нет места парадигмам, есть инструмент и вы его крутите. Например, когда в базе сотни миллиов цен — никто не будет в своем уме хранить историю — всю историю гонят в эластик.
Если есть такое — значит архитектура не продумана верно. ничего не должно вырезаться в виде середины строки запроса.
Очень странный тезис. Допустим у вас есть модуль Продаж, там форма клиентов, где показывается их список и какие-то еще поля. И допустим есть модуль Расчеты с клиентами, который расширяет эту форму клиентов добавляя туда задолженность. Соотвественно в Расчетах идет строка
EXTEND FORM clients
PROPERTIES (cl) debt;
где debt расчитывается сложными правилами из разных таблиц регистров. Соответственно если у клиента подключается модуль расчетов, то в запросе читающих список клиентов должно быть в том числе чтение этой задолженности (с соответствующими JOIN'ами подзапросами и т.п.). Если нет, то не должно быть (так как таблиц для расчетов вообще не будет в базе). Соответственно так как lsFusion сама собирает / компилирует / оптимизирует запросы эта проблема решается прозрачно для разработчика. Как такие вещи вы делаете? Или просто «не держите таким образом»?
Вы серъезно? Это проблема решается тупо одной функцией на каждый регистр, где адо добавить движения, или перехват текущих — если надо изменить. Хотя мы этого и не жалуем.
Все равно не понял, как вы решаете проблему сильной связности (без того же полиморфизма например). То есть модуль A у которого есть одна логика расчета, скажем в lsFusion WHEN CHANGED f(a) DO g(a) < — h(a); и в модуле B есть другая логика расчета WHEN CHANGED g(a) DO x(a) < — t(a). lsFusion сама посмотрит какие модули подключены, возьмет все события посмотрит что они используют, изменяют и выстраивает их в правильном порядке. А у вас как? Обработка проведения одна? Тогда вам в ней придется обращаться и к А, и к B и тогда не понятно как отключить модуль (ведь тогда IDE / сервер будут ругаться что функция расчета в A или B не найдена). А если много, то кто и как их в правильном порядке выстраивает?
А что тут понимать? Есть документ, внутри него светит регистр сведений, отменяете проведение — снимается активность строк, проводите — строки обновляются. Идет рассчет МД5 строки, если строка не изменилась, то проводки, даже при проведении не должны меняться. Блокировки — это элементы головняка, но решаются установкой блокировки на объект лока в таблице регистра сведений
Это вы все руками сами делаете? Тогда я понимаю зачем вам столько тестов надо.
Так что в жестком энтерпрайзе — нет места парадигмам, есть инструмент и вы его крутите. Например, когда в базе сотни миллиов цен — никто не будет в своем уме хранить историю — всю историю гонят в эластик.
Не понял к чему вы это. Нет места парадигмам очень странное утверждение. Парадигмы есть всегда, просто для некоторых задач подходят одни под другие другие. И причем тут эластик я не совсем понял (в задаче про объемы ничего сказано не было). Хотя на самом деле мы работаем с базами где есть таблицы с десятками миллиардов записей (причем принимаемых онлайн) и если они просто лежат, то никому не мешают (но в BI естественно инкрементально выгружаются и большая часть обращений к этим данным идет оттуда).
Вес нашего ядра — 3Мб, количество строк — в 3 раза больше чем у вас (если выкинуть xml форм)
Ух ты даже интересно как вы считали у нас количество строк (реально интересно). Но выкинуть xml форм это сильно. Тогда и в lsFusion надо выкинуть все кроме действий (то что в {} обернуто). Потому как в 1С те же формы в xml по сути задаются, а в lsFusion в синтаксисе языка. И тогда у вас разница в 30 раз получится.
Следи за белым кроликом — все что вы привели в пример — додумайте до конца. Кнопка не справа внизу, или слева, кнопка там, где стоит курсор после предыдущего действия в ожидании нового. На хабре я пишу комент — у меня кнопка отправить — перед глазами. У вас — я переключаюсь на список документов слева вверху, у меня кнопка создать (т.е. следующее логическое действие) — справа внизу…
Что значит переключаюсь «на список документов слева вверху»? И почему вдруг следующее логическое действие — создать, почему не найти документ в списке, после чего его удалить / отредактировать и логично что эти кнопки тогда должны быть снизу, а не сверху. Ну и тоже самое с кнопкой ОК, она справа внизу, потому что вы ввели данные сверху-вниз, слева-направо и логично что ОК должно быть справа внизу и в 95% интерфейсов она именно там.
А потому что идеалогия бизнеса такая — справоник — это информация, которая не меняется, документ — это отражение бизнес процесса.
Да, только эти абстракции сильно текут. Скажем партия это что? С одной стороны справочник, так как на него ссылаются другие документы, а с другой стороны это может быть строка документа прихода (скажем в некоторых решениях на sFusion Batch абстрактный класс и InvoiceDetail его наследует). Или в WMS например есть атомарные операции «сборки одной позиции» это должно быть отдельным документом? Или строкой документа? Но тогда она в парадигму проведения / распроведения вообще не ложится. Со статусами тоже весело получается. И таких утечек сотни.
для отражения бизнес процесса — создайте/используйте этот класс, мы в нем все предусмотрели. И назовем этот класс — документ. Вот и все — вы стали 1С :)
Нет, 1С это более узкая песочница. Там справочники и документы куда более ограниченные и конкретные абстракции (на которые они пытаются натянуть потом все что можно, и BPM и WMS). lsFusion гораздо гибче в этом плане.
Мы внедряем 1С после сапа и после оракла, или рядом с ними, и когда мы говорим бизнесу — что ребята, если мы уйдем, вы найдете программиста, который вам разрулит всю систему по винтикам за пару дней. И мы не врем. А в случае когда даже в 1с умудряются быдлокодить — то что уж говорить про вашу систему :)
Вы не врете, но явно лукавите. Очень многие 1С программисты сейчас боятся того же УТ (и тем более ERP), потому как это тонны реального спагетти кода, без типизации, ранних проверок в IDE / на компиляции / старте, на куче if'ов, с запросами в строках склеиваемых в запутанных стеках вызовов. lsFusion просто на порядок декларативнее (а значит модульнее, надежнее и т.п.)
Ничего, это проходит, мы тоже такими были, и было прикольно :)
Что проходит? У меня опыт в этом бизнесе уже лет 20. И благодаря lsFusion мы например за последние 5 лет стали лидером на рынке крупного ритейла Беларуси убрав и 1С и других игроков с рынка. Именно благодаря тому что мы можем делать очень сложные решения, изменять их прямо на лету, внедрять бесшовно и в общем это все благодаря именно платформе. Сейчас соответственно двигаемся на другие рынки.
Это мега огромное заблуждение. Что это ентерпрайз. Посмотрите на опен сорц проекты в том же мире 1с — там общество активно пилит статьи, документации, вебинары и прочееМы тоже не против, чтобы общество активно пилило статьи, документации и прочее :)
Я бы даже подал заявку на Infostart, и выступил там с докладом по этой теме.Я бы тоже подал заявку. Как думаете, много шансов, что, например, такую статью пропустят (даже за деньги)?
Без популяризации — это не опен сорц проект, это просто — пет проект, и никто, кроме вас — на него не будет смотреть серъезно.А мы тут чем по Вашему занимаемся? Сравнение с 1С — один из самых эффективных способов большого охвата.
Вот вы в своих статьях накидываете на вентилятор, а для таких как я — людей, которые видели уже десяток «убийц 1С», воспринимается нами как «убийца айфона».Вы же понимаете, что есть такие как Вы, а есть и другие. Например, любители open source. Им тоже может быть интересно.
Посмотрите в сторону OScript, Vanessa Automation и т.д. — это тоже опен сорц проекты, но им верят. И они зарабатывали эту веру годами, докладами, доказательствами, спорами, а не набрасывали :) И они в таком же положении как и вы — ибо они, хотят конкурировать с 1С и их продуктами, и у них — это получается, и они — вызывают уважение. Поучитесь у них. Я без сарказма, просто — совет.Они не конкурируют, а встраиваются в их экосистему (пусть у 1С и есть аналогичные продукты). Они не могут говорить о проблемах 1С, так как 1С может их просто убить. Так что сравнение не очень корректное.
На счет форм — он просто страшный, вот реально, я без подколов и приколов, такой продукт будет продать сложно. Интерфейс перегружен, слишком сложен и не редко — не интуитивно понятен. Я себя ощущал пилотом самолета. Куча кнопок, переключаетелей, все этих тонах Виндовс 95. Аж мурашки по коже :)На вкус и цвет все фломастеры разные. А меня, например, бесит веб-интерфейс в 1С в демке. Не понимаю, как люди могут работать в таком тормознутом интерфейсе. Я бы давно разбил монитор. Но работают как-то.
Мы тоже не против, чтобы общество активно пилило статьи, документации и прочее :)
Хех :) Это заслужить надо.
Я бы тоже подал заявку. Как думаете, много шансов, что, например, такую статью пропустят (даже за деньги)?
Да, скажите — что гибкая настройка для 1С с динамическим интерфейсом и офлайн базой, которая позволяет работать в местах с плохим доступом в инет. Вы думаете там нет таких докладов?
А мы тут чем по Вашему занимаемся? Сравнение с 1С — один из самых эффективных способов большого охвата.
Вы тут на вентелятор кидаете, вот чем. Вы еще далеко не доросли до 1С как платформы, без обид. Вы бы наоборот, с обществом общались, спрашивали, и слушали, а не кидали статьи в виде, что все кругом ..., а вы Д'Артаньяны.
Вы же понимаете, что есть такие как Вы, а есть и другие. Например, любители open source. Им тоже может быть интересно.
Открою тайну — у меня тоже есть опен сорц проект, над которым работает ни одна команда, и ни из одной страны, поэтому я знаю что говорю, и так как вы тоже опен сорц, вот тут вам и рассказываю, чтобы не шли по нашим граблям.
Они не конкурируют, а встраиваются в их экосистему (пусть у 1С и есть аналогичные продукты). Они не могут говорить о проблемах 1С, так как 1С может их просто убить. Так что сравнение не очень корректное.
Вы это реально серъезно? Вы помоему вообще ничего не знаете о высшем мире 1С, где говорят что думают и отвечают за слова, и гвоорят везде и публично. Купите билет на инфостарт, сходите на конференцию, и вы все поймете.
На вкус и цвет все фломастеры разные. А меня, например, бесит веб-интерфейс в 1С в демке. Не понимаю, как люди могут работать в таком тормознутом интерфейсе. Я бы давно разбил монитор. Но работают как-то.
В демке? Так у вас в демке он больше тупит, но я не делаю вывод что у вас тормознутая система :)
Да, скажите — что гибкая настройка для 1С с динамическим интерфейсом и офлайн базой, которая позволяет работать в местах с плохим доступом в инет. Вы думаете там нет таких докладов?Думаете там дурачки сидят и ничего не знают про lsFusion, и что 1С тут ни при чем? Когда вышла статья «Почему не 1С», я в Google Analytics видел, как минимум 50 пользователей с провайдера «1c llc». Интересно, кто бы это мог быть :)
Вы тут на вентелятор кидаете, вот чем. Вы еще далеко не доросли до 1С как платформы, без обид. Вы бы наоборот, с обществом общались, спрашивали, и слушали, а не кидали статьи в виде, что все кругом ..., а вы Д'Артаньяны.Что именно общались и спрашивали? Мы потратили много времени, чтобы разобраться в 1С. Написали статью с проблемами. Ее сильно заплюсовали и многие 1Совцы подтвердили, что так и есть. Там 100К просмотров. Всем понравилось значит.
Открою тайну — у меня тоже есть опен сорц проект, над которым работает ни одна команда, и ни из одной страны, поэтому я знаю что говорю, и так как вы тоже опен сорц, вот тут вам и рассказываю, чтобы не шли по нашим граблям.Спасибо за ваш интерес. Но мы действуем по-своему. Я не говорю хорошо это, или плохо. Таков путь (с)
Вы это реально серъезно? Вы помоему вообще ничего не знаете о высшем мире 1С, где говорят что думают и отвечают за слова, и гвоорят везде и публично. Купите билет на инфостарт, сходите на конференцию, и вы все поймете.Если честно, то не вижу смысла ходить на конференцию 1С. Вы почему-то решили, что для нас основной рынок — 1Совцы. Это далеко не так.
В демке? Так у вас в демке он больше тупит, но я не делаю вывод что у вас тормознутая система :)
Ну давайте сравним:
Явно же в lsFusion открывается гораздо быстрее.
Явно же в lsFusion открывается гораздо быстрее.
Вы это сейчас серъезно? Я вам щас запушу гифку, где 1с работает быстрее чем ваша система, и что?
Это раз, два — сравнивайте производительность тогда с 1с 8.1, у вас с ней интерфейсы одинаковые, но там вы явно проиграете, причем всухую.
Мы потратили много времени, чтобы разобраться в 1С.
Я не вижу у вас опыта крупных внедрений, где из 1с тянут все соки, отсюда и статьи ваши выглядят очень популистскими. А сравнения — вообще ни в какие ворота. То же сравнение форм — вы ничего не расчитываете на лету, типо размещения элементов, их подгонки, рассчет их положений, вы просто откройте 1С в браузере, нажите F12 и выберите там мобильное устройство, и увидите, что в 1С можно работать, а у вас — нельзя. И дело тут не в мобильной или нет, а в том, сколько вы ресурсов тратите на все эти рассчеты. И когда вы начнете поддерживать тоже самое — врядли у вас будет сильно быстрее. При равном количестве элементов и наполнения — вы проиграете даже в скорости открытия форм. А это опять говорит о вашей некомпетентности, или, о специальном сокрытии фактов. Это раз, а два — сравните в тонком клиенте, веб в 1с — это не основа, а так, примочка.
Если честно, то не вижу смысла ходить на конференцию 1С. Вы почему-то решили, что для нас основной рынок — 1Совцы. Это далеко не так.
Покажите тогда плиз статью, где вы накидываете на оракл, сап и т.д., мне уже аж стало интересно. Или вы думаете что ваши технические статьи способен понять конечный клиент 1С, а не разработчик? Что то вы юлите :)
Вы это сейчас серъезно? Я вам щас запушу гифку, где 1с работает быстрее чем ваша система, и что?Да, серьезно. Проблема не в конкретном действии. В 1С тормозит весь веб-интерфейс в любых формах. Проблема в очень тяжелом DOMе и в том, что огромном количестве JavaScripta. У нас давным давно тоже так было и точно также тормозило. После жалоб пользователей мы вырезали все лишнее к чертовой матери, перешли на flex layout и теперь все летает. А у 1С веб — это пугало, с которым работать, на мой взгляд, очень напряжно. И да, запишите мне гифку (но не проведение, а просто обычную работу — подбор товара, вызов диалогов и т.д.).
Я не вижу у вас опыта крупных внедрений, где из 1с тянут все соки, отсюда и статьи ваши выглядят очень популистскими. А сравнения — вообще ни в какие ворота.А Вы сюда смотрели? У нас клиенты с тысячами сотрудников, терабайтными базами, тысячей одновременно работающих пользователей и полным набором процессов от производства до POS.
вы просто откройте 1С в браузере, нажите F12 и выберите там мобильное устройство, и увидите, что в 1С можно работать, а у вас — нельзя.Вы это серьезно? В 1С веб в десктопе тормозит. В мобиле у меня вообще туда не заходит в веб-интерфейс. А зайдите вот сюда в мобиле. Все прекрасно работает в мобильном браузере (загружать изображения, перемещать товар и т.д.)
При равном количестве элементов и наполнения — вы проиграете даже в скорости открытия формТак зайдите в демо lsFusion ERP. Там в какой-нибудь Подбор заказа на закупку. Там элементов валом — и все летает. А в 1С еле ворочается на 7 колонка и 5 кнопках.
Это раз, а два — сравните в тонком клиенте, веб в 1с — это не основа, а так, примочкаВот с этого надо и было начинать. Все мои знакомые 1Совцы говорят, что веб в 1С — это пугало (и так у них во всем).
Покажите тогда плиз статью, где вы накидываете на оракл, сап и т.д., мне уже аж стало интересно. Или вы думаете что ваши технические статьи способен понять конечный клиент 1С, а не разработчик? Что то вы юлите :)Смотря что вы считаете под накидываем. Вот, например, в этой статье много где накидываем. А плюсов очень много. На SAP нет смысла накидывать — там вообще не про качество продукта. Его по другой причине покупают.
А Вы сюда смотрели?
Я уже вырос из того периода, когда меня такое могло удивить, так что для меня все это не показатель вообще. Компании любят сделать одну обработку для гугла, а потом мне втирать что они там гугл обслуживают (основано на реальных событиях), я смотрю все по тем же вбросам. Взять самую слабую сторону (и самую бесполезную), и двигать ее с фразами — а мы можем вот так. Повторюсь — сравните скорость в тонком, или обычных формах, и ваше решение не выйграет. И вы конечно же скажете — ну это же веб, браузер по умолчанию не может быть быстрее нативного приложение. И будете правы.
А зайдите вот сюда в мобиле.
Заголовок спойлера
Зашел. Не впечатлило. Выглядит также ужасно… ЧЯДНТ?
Вот с этого надо и было начинать. Все мои знакомые 1Совцы говорят, что веб в 1С — это пугало (и так у них во всем).
Опять вы в категоризм уходите. Все знают что 1С запилило веб морду просто потому что могли, и это крутая фича для ERP систем. Но никто в реале работать в браузере не будет. Это же бред. Когда есть тонкий клиент, мобильный клиент, под все платформы и т.д. Поэтому прошу вас повторить замер в тонком клиенте 1С, и тонком клиенте вашей системы.
Или можем проверить качестко и скорость работы в мобильных клиентах вашей системы и 1С. И не стоит рассказывать, что будущее за вебом — нифига, все эти PWA (которые 1С тоже поддерживает) — нифига не спасают никого.
Смотря что вы считаете под накидываем.
Ваше отношение и ваши аргументы. Мне просто скучно щас, поэтому тут с вами бодаюсь. С одной стороны — вроде что то прикольное делаете, но блин, с такой подачей, аж тошнит местами. Та даже наш разговор про веб морды. Сравнивать скорости на веб морде, это как взять самокат и джип, и хвастаться тем, что самокат тоже ездит, но его еще и в руки можно взять, поэтому остальные критерии — в топку :)
Это даже где то веселит меня :)
С незначительностью Web я, пожалуй, не соглашусь. Если посмотреть на рынок учетных SaaS-решений для SMB в США и Европе, то все идут в Web. Но при этом наличии опции в виде тонкого и мобильного клиентов является большим плюсом.
Melex, вот честно, я даже в вашей аргументации про веб запутался, то он плохо работает потому что не нужен, то он медленно работает потому как элементов гораздо больше (хотя при этом утверждаете что интерфейсы текущих решений на lsFusion перегружены и в 1С элементов гораздо меньше, что в свою очередь лучше).
Просто по общению я вижу, что вы даже не пытались разобраться в lsFusion. И это полностью ваше право. Но смущает, что вы также при этом уверенно пытаетесь сравнивать lsFusion с 1С, при этом явно намекая, что например я плохо разбираюсь в 1С. Хотя поверьте я на то чтобы разобраться с 1С потратил гораздо больше времени чем вы чтобы разобраться с lsFusion (при этом многие тут еще утверждают что у 1С низкий порог входа и разобраться с 1С проще простого).
Кстати у нас реально много клиентов в браузере работает. У некоторых даже под 100 процентов.
Просто по общению я вижу, что вы даже не пытались разобраться в lsFusion. И это полностью ваше право. Но смущает, что вы также при этом уверенно пытаетесь сравнивать lsFusion с 1С, при этом явно намекая, что например я плохо разбираюсь в 1С. Хотя поверьте я на то чтобы разобраться с 1С потратил гораздо больше времени чем вы чтобы разобраться с lsFusion (при этом многие тут еще утверждают что у 1С низкий порог входа и разобраться с 1С проще простого).
Но никто в реале работать в браузере не будет
Кстати у нас реально много клиентов в браузере работает. У некоторых даже под 100 процентов.
Я уже вырос из того периода, когда меня такое могло удивить, так что для меня все это не показатель вообще. Компании любят сделать одну обработку для гугла, а потом мне втирать что они там гугл обслуживают (основано на реальных событиях), я смотрю все по тем же вбросам.Но Вы при этом утверждали, что у нас нет опыта крупных внедрений. А меж тем на lsFusion работают все основные бизнес-процессы компаний с оборотами в сотни миллионов долларов. А в некоторых даже POS-терминалы в единой базе в онлайне. Там простой очень дорого стоит. Но хорошо, что мы разобрались, что lsFusion используется для таких же серьезных проектов, как и 1С (просто меньше клиентов).
Зашел. Не впечатлило. Выглядит также ужасно… ЧЯДНТ?Я ничего не говорил про то как выглядит. Это вкусовщина. Я говорил про скорость работы. Если спросить у пользователей, которые работают долго в системе, что им важнее скорость или красота, то 99% процентов выберет скорость. И тут в вебе lsFusion полностью уделывает 1С.
И не стоит рассказывать, что будущее за вебом — нифига, все эти PWA (которые 1С тоже поддерживает) — нифига не спасают никого.Не будущее, а уже настоящее за вебом. И 1С со своим тонким клиентом является анахронизмом, который имеет только одно преимущество — так исторически сложилось.
Это раз, два — сравнивайте производительность тогда с 1с 8.1, у вас с ней интерфейсы одинаковые, но там вы явно проиграете, причем всухую.
Вы что-то явно путаете. По производительности 1С 8.1 проиграет вчистую, так как lsFusion поддерживает все фишки 8.3 из коробки (динамические списки с видимыми окнами, разделение на сервер и клиент с минимизацией общения и максимальной асинхронностью). Зайдите в демку MyCompany и откройте документы на 100к строк или другие формы типа подбора где номенклатуры тоже под 100к. 8.1 там бы уже лег давно. Да и веба там нет непонятно что вообще поэтому сравнивать.
Я не вижу у вас опыта крупных внедрений, где из 1с тянут все соки, отсюда и статьи ваши выглядят очень популистскими.
У нас очень большой опыт внедрений на десятках проектов большинство из которых с 500-1к одновременных пользователей, таблицами под 10 млрдов записей (причем например с онлайн приемом реализации из касс и онлайн расписыванию по партиям), с очень высокой глубиной автоматизации (где чуть ли не каждый поход в туалет автоматизирован и делается по 5 задач в день с ежедневным обновлением), в едином интегрированном контуре (с десятками тысяч связанных событий и сложными формами с кучей агрегированных данных как у брокеров) и т.д. и т.п. Не верите, могу онлайн презентацию провести, если вам интересно.
вы ничего не расчитываете на лету, типо размещения элементов, их подгонки, рассчет их положений
Вот это на мой взгляд самое зло из зол и за это я бы руки отрывал (и частично поэтому веб в 1С так тормозит). Мы наоборот старались делать layout'инг, который на css ложится и рендерится браузером. Благо HTML5 поддерживает достаточно много возможностей. Это как минимум позволяет веб-клиента использовать на мобильных устройствах.
и увидите, что в 1С можно работать, а у вас — нельзя
Если оно так у меня на мощном компе лагает, страшно представить как оно на мобилке работает.
дело тут не в мобильной или нет, а в том, сколько вы ресурсов тратите на все эти рассчеты. И когда вы начнете поддерживать тоже самое — врядли у вас будет сильно быстрее.
Мы то как раз почти все на сервере считаем. На клиенте что-то считать на мой взгляд это глупость в абстолютном большинстве случаев.
При равном количестве элементов и наполнения — вы проиграете даже в скорости открытия форм
Не понял, откройте любую форму в MyCompany или ERP там куда больше элементов и наполнения (вы же сами жаловались, что они перегружены), и там не только первичные данные как в 1С, а и кучу агрегированных данных выводится.
Покажите тогда плиз статью, где вы накидываете на оракл, сап и т.д., мне уже аж стало интересно
Вот.
Вы тут на вентелятор кидаете, вот чем. Вы еще далеко не доросли до 1С как платформы, без обид. Вы бы наоборот, с обществом общались, спрашивали, и слушали, а не кидали статьи в виде, что все кругом ..., а вы Д'Артаньяны.
«Если бы я спросил что людям нужно, они бы сказали, что им нужна более быстрая лошадь» (с) Генри форд.
Я не понял где статьи, что все кругом… Я писал конкретные общеизвестные вещи / проблемы. Вы же понимаете, что явную типизацию, полиморфизм, прозрачные ограничения и материализации (а точнее материализованные представление), событийно-ориентированность, реактивность, непротиворечивость и нетекущесть абстракций, everything as a code, инъекции в язык (аля LINQ или Dynamics), использование нормальных IDE и т.п. не я придумал. Это все выстрадано многолетним опытом и стало стандартом во всем мире. А то что 1С все это игнорирует (и как вы говорите никого не спрашивает и не слушает) и остается в 80-х это собственно их проблемы.
Но ответьте пока на следующее — где получить тесты, которыми вы прогоняете все конфигурации
Вот тут я на это частично отвечал:
habr.com/ru/company/lsfusion/blog/541526/#comment_22662940
Хотя честно говоря тема автотестов (во всяком случае самой платформы) действительно пока не так развита, как наверное хотелось. Другое дело не понятно зачем ее активно автотестировать, кроме достаточно ограниченной группы участников.
У месня сейчас сложилось впечатление, что у вас на проектах не работало более одного программиста.
Сонар, сценарные тесты, юнит тесты, автобилды, вычитки кода, стандарты и практики — без этого всего, вы получите то, что люди писали на 1С 7.7 20 лет назад. Ни одна серъезная компания даже не макнется в эту тему (я как про исполнителей, так и про потребителей), если не будет возможности это все тестировать.
У нас конфигурацция вашего уровня майкомпани, и на ней уже гонится 2500 сценарных тестов, которые покрывают только 85% кода, и нам еще есть куда идти, а если у вас вообще тестов нет, и покрытия нет, то как тогда делать рефакт? Как вообще хоть что то можно делать чуть серъезней, чем внедрение лотков?
Я без наездов, просто весь мир 1С сейчас идет в DevOps, все понимают, что без этого никуда, компании тратят кучу бобла и времени на это, а вы говорите — ну как бы тестировать нечего? :) Та я в жизни не поставлю обноление вашего сервера, если оно не пройдет тесты у меня, на моем окружении.
Сонар, сценарные тесты, юнит тесты, автобилды, вычитки кода, стандарты и практики — без этого всего, вы получите то, что люди писали на 1С 7.7 20 лет назад. Ни одна серъезная компания даже не макнется в эту тему (я как про исполнителей, так и про потребителей), если не будет возможности это все тестировать.
У нас конфигурацция вашего уровня майкомпани, и на ней уже гонится 2500 сценарных тестов, которые покрывают только 85% кода, и нам еще есть куда идти, а если у вас вообще тестов нет, и покрытия нет, то как тогда делать рефакт? Как вообще хоть что то можно делать чуть серъезней, чем внедрение лотков?
Я без наездов, просто весь мир 1С сейчас идет в DevOps, все понимают, что без этого никуда, компании тратят кучу бобла и времени на это, а вы говорите — ну как бы тестировать нечего? :) Та я в жизни не поставлю обноление вашего сервера, если оно не пройдет тесты у меня, на моем окружении.
Я же вроде объяснил в ссылке. Все сводится к уровню декларативности. Что именно предполагается тестировать, если программа сама по себе является своей спецификацией (то есть в ней определяется ЧТО делать, а не КАК). То есть тестами по сути будете платформа, а не решение тестироваться.
И 1С это чистая императивщина и там очень много чего можно и нужно тестировать, поэтому здесь немного странно приводить ее в пример.
И 1С это чистая императивщина и там очень много чего можно и нужно тестировать, поэтому здесь немного странно приводить ее в пример.
Ладно, проехали. Надеюсь вы когда-то поймете, о чем я вас спросил. Так как сейчас, как говорится — «у вас не болит», поэтому ценность и цели вам не понятны. Но лучше задайтесь вопросом сразу — потом будет больнее.
Не, я отлично понимаю, о чем вы спрашиваете. И честно говоря платформе сейчас на мой взгляд действительно не хватает покрытие тестами, но тут вот какая вещь. Когда платформа разрабатывалась совсем не было понятно, что в итоге получится, (в этом фокус всех инновационно революционных вещей). Соответственно наличие автотестов на раннем этапе скорее тормозило бы развитие платформы, так как за радикальными изменениями приходилось бы переделывать все тесты (так как сильно менялся бы результат), а даже без тестов такой рефакторинг был очень сложным (и тесты бы в таком случае скорее мешали). А когда архитектура стала более mature и стабильной тесты было делать уже поздновато (так как их важно делать на момент решения проблемы, но в этот момент совсем не понятно решение окончательное или нет). Плюс еще одна важная проблема — опять таки результат тестирования нечеткий, то есть основные тесты в основном нужны на оптимизатор / компилятор запросов, а тут опять-таки непонятны критерии (план не сравнишь, время не четкий параметр и т.п.). То есть в конечном итоге надежность можно было бы улучшить процентов на 20, а стоимость разработки в раза 3. Еще раз, я знаю что такое тестирование, и сам считаю, что во многих случаях оно очень важно, и мы постоянно думали / думаем как его прикрутить, чтобы в сумме (!) получить выигрыш, но пока не можем придумать.
Поэтому сейчас основной принцип тестирования для платформы такой: а) строго вертикальная архитектура без костылей (то есть жесткий code review, имхо в любом случае это самое эффективное, уделывающее все остальные, тестирование, которое снижает количество ошибок на порядки), б) специфический flow разработки — сначала идет в мастер, на котором работают большое количество разработчиков lsFusion, затем внутренняя альфа, которая идет на все демостенды, заказчикам не в production'е, затем есть пул заказчиков, у которых идут постоянные доработки по agile и с которыми есть соответствующие договоренности, которым подмешиваются новые версии (причем идет от небольших с простыми логиками, к большим со сложными), все версии накатываются в hot standby с откатом в пару минут (и с учетом постоянных изменений логики надежность поставок обновлений падает не больше чем на 10-20 процентов), после этого бета и накатывание большему числу заказчиков (вплоть до 30 из разных областей), потом final релиз, ну и hot fix'ы с автоматическими релизами (на самом деле все сборки, поставки заказчикам, релизы автоматизированы по самое не могу, вот часть инфраструктуры, тут ее исходники). Опять таки строго вертикальная чистая архитектура обеспечивает «полное покрытие» (когда у вас в архитектуре пирамидка и куча разных логик, то все узлы задействуются сами собой).
Что касается решений, то тут вот какой момент. Надо понимать что тот же lsFusion ERP это скорее конструктор из которого собираются первоначальные готовые решения, которые потом начинают сильно адаптироваться под конкретного заказчика и развиваться вместе с ним (по сути, если сейчас взять пяток крупных решений для клиентов даже из одной области, все они будут очень разными, вплоть до неузнаваемости). В этом смысле у нас бизнес-модель именно проектные решения (а не коробки) и ближе скажем к банковской ИТ-сфере, чем к классическим 1С-франчайзерам. Хорошо это или плохо сложный вопрос — для заказчика плюсы я писал тут, для подрядчика плюс в том, что он получает recurring revenue. То есть такой win-win. В любом случае доработка таких решений идет в agile и continious delivery. И теоретически я понимаю, что тут нужны тесты, но в платформе где императивность практически отсутствует (а точнее ее максимум 10%) реально не понятно что тестировать. По факту только что-то вроде «регрессивного» тестирование имеет смысл, да и то оно по сути будет тестировать платформу. Так как если кто-то изменил какое-то вычисление (например расчет какого-то показателя), по сути нужно опять таки менять сам тест.
Просто насколько я видел тестируют в основном императивщину (и чаще всего именно инкрементальность). То есть грубо говоря добавил документ проверил, что остаток пересчитался правильно, изменил строку документа проверил что остаток пересчитался правильно и т.п. А в lsFusion это все платформа делает сама, то есть реально не понятно, что тестировать.
Поэтому сейчас основной принцип тестирования для платформы такой: а) строго вертикальная архитектура без костылей (то есть жесткий code review, имхо в любом случае это самое эффективное, уделывающее все остальные, тестирование, которое снижает количество ошибок на порядки), б) специфический flow разработки — сначала идет в мастер, на котором работают большое количество разработчиков lsFusion, затем внутренняя альфа, которая идет на все демостенды, заказчикам не в production'е, затем есть пул заказчиков, у которых идут постоянные доработки по agile и с которыми есть соответствующие договоренности, которым подмешиваются новые версии (причем идет от небольших с простыми логиками, к большим со сложными), все версии накатываются в hot standby с откатом в пару минут (и с учетом постоянных изменений логики надежность поставок обновлений падает не больше чем на 10-20 процентов), после этого бета и накатывание большему числу заказчиков (вплоть до 30 из разных областей), потом final релиз, ну и hot fix'ы с автоматическими релизами (на самом деле все сборки, поставки заказчикам, релизы автоматизированы по самое не могу, вот часть инфраструктуры, тут ее исходники). Опять таки строго вертикальная чистая архитектура обеспечивает «полное покрытие» (когда у вас в архитектуре пирамидка и куча разных логик, то все узлы задействуются сами собой).
Что касается решений, то тут вот какой момент. Надо понимать что тот же lsFusion ERP это скорее конструктор из которого собираются первоначальные готовые решения, которые потом начинают сильно адаптироваться под конкретного заказчика и развиваться вместе с ним (по сути, если сейчас взять пяток крупных решений для клиентов даже из одной области, все они будут очень разными, вплоть до неузнаваемости). В этом смысле у нас бизнес-модель именно проектные решения (а не коробки) и ближе скажем к банковской ИТ-сфере, чем к классическим 1С-франчайзерам. Хорошо это или плохо сложный вопрос — для заказчика плюсы я писал тут, для подрядчика плюс в том, что он получает recurring revenue. То есть такой win-win. В любом случае доработка таких решений идет в agile и continious delivery. И теоретически я понимаю, что тут нужны тесты, но в платформе где императивность практически отсутствует (а точнее ее максимум 10%) реально не понятно что тестировать. По факту только что-то вроде «регрессивного» тестирование имеет смысл, да и то оно по сути будет тестировать платформу. Так как если кто-то изменил какое-то вычисление (например расчет какого-то показателя), по сути нужно опять таки менять сам тест.
Просто насколько я видел тестируют в основном императивщину (и чаще всего именно инкрементальность). То есть грубо говоря добавил документ проверил, что остаток пересчитался правильно, изменил строку документа проверил что остаток пересчитался правильно и т.п. А в lsFusion это все платформа делает сама, то есть реально не понятно, что тестировать.
Тут главное понять одно — кто контролирует контролера?
Т.е. есть кейс, где надо рассчитать сумму товара, навпример, и программист полез в общий модуль и там что то поменял, и документ работает отлично. Но при этом — другой документ стал рассчитывать не правильно.
Для этого тест и нужен, что есть некий внешний контроллер того, то получилось на выходе. И я, например, даже не приступаю к код ревью, пока не пул не прошел все тесты, и дымовые, и сценарные, и контроли качества и синтаксис. Ибо мое время — сильно дороже обычного разработчика, и тратить его на вычитку не работающего функционала — смысла нет.
Без тестов — далеко не уехать. Увы. И я сам через это проходил, будучи такого же мнения как и вы, пока… не появились клиенты со своими отличиями. И вот там тесты — десятки раз спасали тонну времени.
Но так как у вас нет тестов, вы не видите как их применить, в той же области, когда 5 клиентов из одной сферы, но у каждого свои отличия. И тесты должны вам сказать про это.
Простейший пример — кто то в ядро положил рассчет суммы, и поставил округление до 2 знака, все гут, все работает, все тесты ядра прошли, но, когда залили мерж в форк клиента, стартанули тесты — сразу посыпались ошибки, что типо ребята — что то не то вы считаете.
Т.е. тесты — это сравнение с шаблоном и парадигмой, которую вы заложили в идеали, и считаете, что она не может измениться не контролируемо. Поэтому без тестов — будет грустно
Т.е. есть кейс, где надо рассчитать сумму товара, навпример, и программист полез в общий модуль и там что то поменял, и документ работает отлично. Но при этом — другой документ стал рассчитывать не правильно.
Для этого тест и нужен, что есть некий внешний контроллер того, то получилось на выходе. И я, например, даже не приступаю к код ревью, пока не пул не прошел все тесты, и дымовые, и сценарные, и контроли качества и синтаксис. Ибо мое время — сильно дороже обычного разработчика, и тратить его на вычитку не работающего функционала — смысла нет.
Без тестов — далеко не уехать. Увы. И я сам через это проходил, будучи такого же мнения как и вы, пока… не появились клиенты со своими отличиями. И вот там тесты — десятки раз спасали тонну времени.
Но так как у вас нет тестов, вы не видите как их применить, в той же области, когда 5 клиентов из одной сферы, но у каждого свои отличия. И тесты должны вам сказать про это.
Простейший пример — кто то в ядро положил рассчет суммы, и поставил округление до 2 знака, все гут, все работает, все тесты ядра прошли, но, когда залили мерж в форк клиента, стартанули тесты — сразу посыпались ошибки, что типо ребята — что то не то вы считаете.
Т.е. тесты — это сравнение с шаблоном и парадигмой, которую вы заложили в идеали, и считаете, что она не может измениться не контролируемо. Поэтому без тестов — будет грустно
Т.е. есть кейс, где надо рассчитать сумму товара, навпример, и программист полез в общий модуль и там что то поменял, и документ работает отлично. Но при этом — другой документ стал рассчитывать не правильно.
Опять-таки все очень сильно зависит от уровня декларативности — эффектов последействий, состояний, модульности (а точнее декомпозиции), полиморфизма и т.п.
У меня был в свое время опыт работы вот именно с таким аля 1С кодом, тонной спагетти кода без типизации, полиморфизма, ранних проверок на уровне IDE / старта (динамическим исполнением), тоннами if'ов и да единственный способ это хоть как-то поддерживать это автотесты. Но автотесты это борьба с симптомами, а не болезнью. Серьезно, если бы вы хоть раз пописали бы на чем то хоть близко настолько высокодекларативном и с таким количеством возможностей как lsFusion у вас бы таких вопросов не возникало.
Что именно предполагается тестировать
Функции у вас есть? Если да, то для каждой пишутся тесты проверяющие а делает ли она то, что от нее ожидают, для разных наборов входных параметров ну и прочих свойств. Это называется юнит тестированием.
Ошибки вы допускаете, а затем исправляете? Каждый раз вместе с коммитом на исправление добавляйте юнит тест, или тесты, которые проверяют, что эта ошибка исправлена. Это называется регресс-тестом. Без них одни и те-же ошибки имеют свойство возвращаться опять и их опять приходится исправлять.
Ну и так далее, тестов всяких разных много но с этих двух типов стоило-бы начать. Вообще ввести правило, что нельзя замержить пул-реквест, в котором изменения в коде не покрыты юнит-тестами.
Что именно предполагается тестировать, если программа сама по себе является своей спецификацией
То, что эта спецификация действительно соответствует той, которая описана в бизнес-требованиях. То есть то, что обработка этой спецификации платформой дает тот результат, который действительно требуется получить. Эти результаты и фиксируются в тестах — вход и какой для него должен быть выход.
Так и не понял вы предлагаете тестировать вычисления получается? То есть то что платформа правильно считае? Ну вот давайте собственно возьмем простой пример (чисто для демо):
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=2228636
Что конкретно тут предполагается тестировать? Что currentBalance считается правильно, так он декларативно описан (то есть это его определение). Или нужно посчитать на калькуляторе и вбить тест на проверку? Ну так это все равно что в Excel формулы проверять.
Еще раз я полностью согласен с тем что императивные вещи важно и очень нужно тестировать. Но чем декларативнее логика, чем меньше нужны тесты.
Ну и такой момент. Даже если бы тесты и можно делать в каких-то случаях, как думаете что выберет заказчик увеличение стоимости доработки в 2 раза или уменьшение надежности на 20% при условии hot downgrade'а и потенциального простоя не revenue-критичной части на пару минут (то что требования к revenue-критичной части выше с этим никто не спорит).
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=2228636
Что конкретно тут предполагается тестировать? Что currentBalance считается правильно, так он декларативно описан (то есть это его определение). Или нужно посчитать на калькуляторе и вбить тест на проверку? Ну так это все равно что в Excel формулы проверять.
Еще раз я полностью согласен с тем что императивные вещи важно и очень нужно тестировать. Но чем декларативнее логика, чем меньше нужны тесты.
Ну и такой момент. Даже если бы тесты и можно делать в каких-то случаях, как думаете что выберет заказчик увеличение стоимости доработки в 2 раза или уменьшение надежности на 20% при условии hot downgrade'а и потенциального простоя не revenue-критичной части на пару минут (то что требования к revenue-критичной части выше с этим никто не спорит).
Но чем декларативнее логика, чем меньше нужны тесты.
Нет. Неважно, как у вас записана логика c = a + b, если по требованиям должно быть c = a — b.
Что конкретно тут предполагается тестировать? Что currentBalance считается правильно, так он декларативно описан (то есть это его определение).
Я же написал, что тестировать — что то, что у вас декларативно описано в программе, дает тот результат, который ожидается по бизнес-требованиям.
Что если он у меня вот так декларативно описан:
currentBalance 'Текущий остаток' (Item i, Stock s) = receivedQuantity (i, s) (+) shippedQuantity (i, s); Это правильно? Вот скопипастил я с какого-нибудь totalQuantity и не поменял плюс на минус.
А если вот так:
currentBalance 'Текущий остаток' (Item i, Stock s) = receivedQuantity (i, s) (-) shippedQuantity (i, s); Видите ошибку? Правильно, ее тут нет, потому что она в другом коде. Вот делали недавно рефакторинг, и случайно поменяли receivedQuantity
receivedQuantity 'Суммарный приход' = GROUP SUM quantity(ReceiptDetail d) BY stock(receipt(d));Или намеренно вот так
receivedQuantity 'Суммарный приход' = GROUP SUM quantity(ReceiptDetail d) BY item(d), newField(d), stock(receipt(d));а для shippedQuantity не поменяли.
Все описано декларативно, только работает неправильно.
Или нужно посчитать на калькуляторе и вбить тест на проверку?
Именно так и нужно делать. Хотя можно существующий код использовать, если вы можете проверить без калькулятора, что результат действительно правильный. Хардкодится вход и выход на момент создания теста, чтобы гарантировать, что при дальнейших изменениях кода любое изменение результата для этого входа будет замечено, и программист решит, действительно ли он хотел, чтобы этот результат поменялся, или он чего-то не учел. И соответственно исправит тест либо свой код.
как думаете что выберет заказчик
У заказчика как правило нет компетенций в этой области, чтобы принимать обоснованные решения. Он потеряет пару миллионов потому что сумма полгода неправильно считалась, и скажет, что не предполагал, что уменьшение надежности на 20% означает именно это, а думал, что у пользователей просто ошибок будет больше на экране выскакивать.
Вы говорите, что у вас есть типовые решения и модули, значит в них есть какой-то функционал, вот на него и нужны тесты. Они пишутся один раз для всех заказчиков, код модуля же у всех одинаково работает.
Мир не черно-белый. Вы же согласны, что чем декларативнее логика, чем меньше там эффектов последействия, состояний и другой «нечистоты», тем значительно меньше вероятность ошибок и как следствие тестирование в таких случаях становится «тестированием ради тестирования» (то есть действительно основным кейсом в таком случае будет, изменил логику — сразу перегенерировал тесты под эту новую логику, а это будет являться конкретным monkey job). Возможно в каких-то алгоритмически-сложных вычислениях (но при этом с точным результатом !) тесты действительно могут играть важную роль, но на практике таких вычислений в бизнес-приложениях очень малый процент.
В любом случае, я думаю мы конечно еще будем добавлять возможности тестирования из коробки (в самом верхнем комментарии я писал как уже сейчас это можно делать), но пока все же не очевиден выигрыш именно при использовании настолько высокодекларативной технологии как lsFusion (во всяком случае если взять наш опыт работы с крупными проектами). То что тесты в императивных средах (особенно для ручной инкрементальности) нужны обязательно, тут вопросов нет от слова вообще.
Ну если бы заказчику можно было сказать у вас нет компетенций и автоматически списать с него в 2 раза больше за то же тестирование, то вопросов нет. Но к сожалению в реальном мире это не так, и ему приходится объяснять риски и затраты, после чего он сам принимает решение. И видя что с настолько высокодекларативной платформой никакие ошибок на пару миллионов не случаются, платить за лишнюю работу отказывается. Ну а мы не сильно настаиваем (в конечном итоге заказчик то доволен, что у него доработки идут с космической скоростью и так дешево).
В любом случае, я думаю мы конечно еще будем добавлять возможности тестирования из коробки (в самом верхнем комментарии я писал как уже сейчас это можно делать), но пока все же не очевиден выигрыш именно при использовании настолько высокодекларативной технологии как lsFusion (во всяком случае если взять наш опыт работы с крупными проектами). То что тесты в императивных средах (особенно для ручной инкрементальности) нужны обязательно, тут вопросов нет от слова вообще.
У заказчика как правило нет компетенций в этой области, чтобы принимать обоснованные решения.
Ну если бы заказчику можно было сказать у вас нет компетенций и автоматически списать с него в 2 раза больше за то же тестирование, то вопросов нет. Но к сожалению в реальном мире это не так, и ему приходится объяснять риски и затраты, после чего он сам принимает решение. И видя что с настолько высокодекларативной платформой никакие ошибок на пару миллионов не случаются, платить за лишнюю работу отказывается. Ну а мы не сильно настаиваем (в конечном итоге заказчик то доволен, что у него доработки идут с космической скоростью и так дешево).
Вы же согласны, что чем декларативнее логика, чем меньше там эффектов последействия, состояний и другой «нечистоты», тем значительно меньше вероятность ошибок и как следствие тестирование в таких случаях становится «тестированием ради тестирования»
Не согласен. Я же привел пример ошибок в вашей декларативной логике. Это основной тип ошибок, для предотвращения которых делаются тесты и в императивной логике.
изменил логику — сразу перегенерировал тесты под эту новую логику, а это будет являться конкретным monkey job
Нет. Вы изменили логику, у вас упали тесты в том месте, которое вы вообще не предполагали менять, вы поняли, что изменили неправильно. Это ни разу не monkey job. Это как раз замена monkey job при ручном тестировании изменений, потому что вы не можете проверять вручную всю логику при каждом изменении.
но на практике таких вычислений в бизнес-приложениях очень малый процент.
Таких малый. Но тесты пишутся не для них.
но пока все же не очевиден выигрыш именно при использовании настолько высокодекларативной технологии как lsFusion
Выигрыш я описал в предыдущем комментарии. Без тестов вы где-нибудь можете написать плюс вместо минуса и заметите это далеко не сразу.
Тесты полезны не для первичной разработки, а для контроля при последующих доработках.
Ну если бы заказчику можно было сказать у вас нет компетенций и автоматически списать с него в 2 раза больше за то же тестирование, то вопросов нет.
Простите, а зачем списывать с каждого заказчика в 2 раза больше за тесты на типовую конфигурацию или модуль, которые вы пишете один раз и распространяете вместе с кодом?
Оплату тестов для специализированной логики конечно решает сам заказчик, но для этого хотя бы нужна возможность это сделать. Какой-то инструментарий, код для запуска, готовые тесты, чтобы можно было сделать другие по аналогии.
И видя что с настолько высокодекларативной платформой никакие ошибок на пару миллионов не случаются
Я в предыдущем комментарии описал ошибки на пару миллионов. Может быть вы их найдете при ручном тестировании, и тогда потери пары миллионов не будет, может нет.
Не согласен.
Я не говорю что вероятности ошибок нет, а что она существенно меньше. Собственно это основной кейс функциональщины (не той что про лямбды, а той что про чистоту функций).
Нет. Вы изменили логику, у вас упали тесты в том месте, которое вы вообще не предполагали менять, вы поняли, что изменили неправильно. Это ни разу не monkey job.
Я знаю что такое тестирование. Я к тому что в высоко-декларативных логиках большинство изменений результатов выхода by-design и соответственно требуют изменения тестов. То есть грубо говоря заказчик говорит надо изменить расчет остатка, ок, мы его меняем, соответственно надо и все тесты переделывать. И таких изменений 95%. Строго говоря тесты то в основном для рефакторинга нужны, а когда у вас очень высокодекларативный код потребность в нем значительно снижается.
Простите, а зачем списывать с каждого заказчика в 2 раза больше за тесты на типовую конфигурацию или модуль, которые вы пишете один раз и распространяете вместе с кодом?
Я сейчас не про типовую. Да и опять таки большинство изменений заказчика в типовую, это изменение именно логики ее работы, а значит и тестов которые эту логику тестируют. Получается значительная двойная (а то и тройная) работа с не до конца понятной выгодой. Рефакторить то типовую вы не будете, инкрементальные вычисления в lsFusion из коробки.
Я к тому что в высоко-декларативных логиках большинство изменений результатов выхода by-design и соответственно требуют изменения тестов.
Нет. То, что у вас написано в примере с currentBalance, ничем особенным не отличается от императивных языков, и ошибки там можно допустить точно те же.
То есть грубо говоря заказчик говорит надо изменить расчет остатка, ок, мы его меняем, соответственно надо и все тесты переделывать.
Я уже несколько раз привел пример именно про это. Заказчик говорит надо изменить расчет остатка (например добавить какой-нибудь план производства и не учитывать планируемые количества в расчете текущих остатков), ок, мы его меняем, а вдруг хобана поменялся и расчет премии грузчикам, и рабочий график сторожа, потому что они тем или иным образом зависят от количества товаров, чего мы никак не ожидали и не планировали менять.
Рефакторить то типовую вы не будете, инкрементальные вычисления в lsFusion из коробки
Зачем тогда переделывать тесты, которые эту логику тестируют? Тесты надо будет написать только на новые вычисления.
Нет. То, что у вас написано в примере с currentBalance, ничем особенным не отличается от императивных языков, и ошибки там можно допустить точно те же.
currentBalance обычно материализуется и в императивных языках и обновляется руками (то есть например при проведении строится дельта, отнимаются старые значений, добавляются новым и так далее). Если вычисление сложное, то сложность его алгоритма инкрементальности растет экспоненциально (тут можно подробнее почитать). И там действительно очень много где можно допустить ошибку (и это все надо тестировать). В lsFusion например такой проблемы нет.
а вдруг хобана поменялся и расчет премии грузчикам, и рабочий график сторожа, потому что они тем или иным образом зависят от количества товаров, чего мы никак не ожидали и не планировали менять.
Это если у вас код императивен по уши, с эффектами последействий, состояниями, без полиморфизма (то есть тоннами if'ов) и т.п. На высокоуровневом языке у вас вероятность таких хобана на несколько порядков меньше.
Зачем тогда переделывать тесты, которые эту логику тестируют? Тесты надо будет написать только на новые вычисления.
Так старые же будут падать. То есть захотел заказчик считать показатель как не в типовой и все у вас вечный красный светофор, если вы не поправить этот тест из типовой.
currentBalance обычно материализуется и в императивных языках и обновляется руками (то есть например при проведении строится дельта, отнимаются старые значений, добавляются новым и так далее)
А тесты делаются не на дельту, а на результаты расчетов. Хотя может где-то и на отдельные детали реализации делаются.
И там действительно очень много где можно допустить ошибку (и это все надо тестировать)
Вы упорно игнорируете то, что я говорю. Зачем вы это делаете?
Еще раз, независимо от того, где там можно допустить ошибку и что там надо тестировать, кроме этого тестировать надо и конечный высокоуровневый результат. Тот самый, который считает с = a+b. Именно про эти тесты вам говорят, а не про тесты деталей сложной и запутанной реализации. Почему вы постоянно разговор на них переводите?
Я привел 2 примера с декларативным кодом на lsFusion и показал, что с моей точки зрения там надо тестировать. С чем конкретно вы спорите? Вы не согласны, что при внесении изменений кто-то может случайно написать currentBalance = receivedQuantity (+) shippedQuantity или некорректно поменять реализацию receivedQuantity? У вас как-то гарантируется, что не сможет?
Это если у вас код императивен по уши, с эффектами последействий, состояниями, без полиморфизма (то есть тоннами if'ов) и т.п.
С чего вы так решили?
Я тоже так могу — это если у вас код декларативен по уши, без эффектов последствий, состояний, с полиморфизмом и т.п. Насчет полиморфизма это даже не шутка, запросто может попасть не тот дочерний класс в код, который работает с родительским.
Кстати, откуда вдруг взялось отсутствие полиморфизма и тонны if-ов? В C#, Java, PHP, да даже C++ есть полиморфизм.
Так старые же будут падать. То есть захотел заказчик считать показатель как не в типовой
Ну не захотел и не захотел. Вы же говорите, что изменять код типовой для таких требований не надо. Соответственно, и тесты этого кода не должны измениться. На новый код можно отдельный тест написать.
Вы упорно игнорируете то, что я говорю. Зачем вы это делаете?
Еще раз, независимо от того, где там можно допустить ошибку и что там надо тестировать, кроме этого тестировать надо и конечный высокоуровневый результат. Тот самый, который считает с = a+b. Именно про эти тесты вам говорят, а не про тесты деталей сложной и запутанной реализации. Почему вы постоянно разговор на них переводите?
Потому что тесты не самоцель. Не, если так, то да можно и формулы в excel'е тестировать, но цель тестов увеличение надежности и если в каком-то случае на практике это не происходит, то и тесты в этом случае не нужны.
Вы не согласны, что при внесении изменений кто-то может случайно написать currentBalance = receivedQuantity (+) shippedQuantity или некорректно поменять реализацию receivedQuantity?
Что значит случайно написать? Тесты они против вредителей или против ошибок? Если человек заменяет — на + то значит так и надо (если он конечно не саботажем занимется). Собственно тесты нужны когда например вы пишете сложные сценарии инкрементальности и не учли какую-то ветку. То есть они нужны для борьбы со сложностью, а не с простотой.
Кстати, откуда вдруг взялось отсутствие полиморфизма и тонны if-ов? В C#, Java, PHP, да даже C++ есть полиморфизм.
Подождите, мы вообще о чем разговариваем? Я говорю, что чем выше декларативность, тем менее тесты критичны и наоборот. Полиморфизм одна из фишек, которая повышает декларативность, не более. Использование же только чистых функций например повышает декларативность гораздо больше. А в 1С декларативность на самом минимальном уровне и я понимаю почему тот же Melex так носится с этими автотестами. Без них дорабатывать условное УТ было бы совсем мазохизмом.
Ну не захотел и не захотел. Вы же говорите, что изменять код типовой для таких требований не надо. Соответственно, и тесты этого кода не должны измениться. На новый код можно отдельный тест написать.
Требования бывают разные, для одних надо, для других нет. Если типовые изменять не надо, то тесты для того кто дорабатывают не имеют смысла, а если надо то они вредят.
— Почему вы постоянно переводите разговор на тесты низкоуровневой реализации?
— Потому что тесты не самоцель.
Я разве где-то говорил, что тесты самоцель? Я вообще не очень понимаю, как ваш ответ связан с вопросом.
Не, если так, то да можно и формулы в excel'е тестировать
Я вас уверяю, в Microsoft в проекте с исходниками Excel есть куча тестов, которые тестируют формулы в excel'е.
Вы вообще тут понятия подменяете. Тестировать надо не то, что формула сложения ячеек правильно складывает ячейки (на это есть тесты в исходниках у Microsoft), а то что формула, записанная в ячейке X дает тот результат, который нужен по требованиям, независимо от того, сложение у вас там или трехэтажный интеграл.
Если у вас формула в ячейке не зависит от формул, написанных вами в других ячейках, тогда возможно тестировать и не надо, так как тесты на весь код, работающий при вычислениях, написаны производителем Excel. А если вы из одной своей формулы вызываете другую свою формулу, которая вызывается еще из десятка третьих формул, тогда появляется вероятность, что при изменениях этой второй формулы вы можете не учесть все последствия ее изменения. Вот чтобы это отслеживать, и нужны тесты для этих формул, тут нет никакой разницы с обычными программами.
Что значит случайно написать?
Если человек заменяет — на + то значит так и надо
Я написал это в том же комментарии. Он может скопировать эту строку из определения поля totalQuantity и не поменять плюс на минус, он может для подсчета количества временно заменить минус на плюс и забыть поменять обратно, он может случайно выделить минус и заменить его другим символом, например если работает на ноутбуке с включенным тачпадом.
И основную причину вы почему-то проигнорировали, это пример про изменение receivedQuantity. Основная причина, почему люди придумали тесты, это то что при внесении изменений можно не учесть все особенности использования в местах вызова.
Тесты они против вредителей или против ошибок?
"Случайно сделать ошибку в коде" не называется словом "вредитель". "Вредитель" это когда ошибка делается специально.
То есть они нужны для борьбы со сложностью, а не с простотой.
Для борьбы со сложностью нужны абстракции, инкапсуляция и полиморфизм, а не тесты. Тесты нужны для проверки корректности работы кода. Вы когда изменения внесли и вручную проверяете, правильно ли все работает, вы разве со сложностью боретесь? Нет, вы именно проверяете, правильно ли все работает.
Подождите, мы вообще о чем разговариваем? Я говорю, что чем выше декларативность, тем менее тесты критичны и наоборот.
Мы разговариваем о том, что вы говорите неправильно. Я же уже сказал, вам говорят про тесты логики, которую вы пишете, а не про тесты низкоуровневых компонентов, на которых она реализована. Да, тесты низкоуровневых императивных компонентов менее критичны, если логика декларативна, и это совершенно не отменяет необходимость тестирования этой логики.
И еще раз повторю, если вы написали код один раз и не планируете его больше менять, то да, тесты не нужны. Вы все равно проверяете работу кода вручную, вы написали, проверили, и все. Тесты нужны для поддержки кода, для контроля того, что все работает как раньше, при изменениях.
Тесты менее критичны, если у вас есть развитая система типов с зависимыми типами, там проверки внутри зависимых типов заменяют проверки в тестах. То есть например если у вас можно задать тип ActiveClient, который является Client, у которого is_deleted == 0, и использовать его в аргументах функций. Но тут причина не в декларативности, а именно в типизации. У вас можно так сделать?
А в 1С декларативность на самом минимальном уровне
Я говорю не про 1С, а про тестирование.
то тесты для того кто дорабатывают не имеют смысла
В контексте доработки типовой конфигурации тесты имеют смысл для вас. Вряд ли вы написали типовое решение 2 года назад и ничего в нем не меняете и не планируете. Я говорил про то, наличие тестов в типовом решении не означает, что надо заново писать тесты для каждого заказчика, который им пользуется, и просить за это в 2 раза больше денег.
Я вас уверяю, в Microsoft в проекте с исходниками Excel есть куча тестов, которые тестируют формулы в excel'е.
Не спорю. А много ли людей в Excel тестируют что Excel правильно рассчитал формулу?
Я написал это в том же комментарии. Он может скопировать эту строку из определения поля totalQuantity и не поменять плюс на минус, он может для подсчета количества временно заменить минус на плюс и забыть поменять обратно, он может случайно выделить минус и заменить его другим символом, например если работает на ноутбуке с включенным тачпадом.
Ну такие ошибки обычно просматриваются при коммите (именно случайные изменения которые не планируется делать).
Плюс есть еще важный нюанс, чем проще ошибка, тем быстрее она обнаруживается в результате flow'а разработки (если такая ошибка попадает в мастер, она очень быстро попадает в непрод среду и ее сразу обнаруживают).
Да, тесты низкоуровневых императивных компонентов менее критичны, если логика декларативна, и это совершенно не отменяет необходимость тестирования этой логики.
Не совсем понял эту мысль. Вы можете все же на простой вопрос ответить: вы согласны с тем, что чем декларативнее парадигма, тем меньше вероятность ошибки и тем меньше нужны тесты?
Тесты менее критичны, если у вас есть развитая система типов с зависимыми типами, там проверки внутри зависимых типов заменяют проверки в тестах. То есть например если у вас можно задать тип ActiveClient, который является Client, у которого is_deleted == 0, и использовать его в аргументах функций. Но тут причина не в декларативности, а именно в типизации. У вас можно так сделать?
На самом деле компилятор (а точнее оптимизатор, а еще точнее оптимизатор булевой логики условий) в lsFusion очень многое тестирует сам, в том числе например противоречивость условий. Но суть не в этом. Вы согласны с тем что например та же «чистота функций» (и отсутствие состояния), существенно важнее с точки зрения декларативности, а значит потенциальных ошибок, а значит и тестов? И что важность тестов количественный показатель, который нужно соизмерять со стоимостью их поддержки, и ущербами и вероятностью предполагаемых ошибок?
Я говорю не про 1С, а про тестирование.
Я просто пример привел, и то почему в том же 1С так носятся (и действительно нужно носится) с этими автотестами.
В контексте доработки типовой конфигурации тесты имеют смысл для вас. Вряд ли вы написали типовое решение 2 года назад и ничего в нем не меняете и не планируете. Я говорил про то, наличие тестов в типовом решении не означает, что надо заново писать тесты для каждого заказчика, который им пользуется, и просить за это в 2 раза больше денег.
Ок, а если конкретное решение удается тестировать именно flow'ом разработки (как я писал тут), а тому кто дорабатывает это решение, как мы выяснили, автотесты совсем не нужны, тогда что?
А много ли людей в Excel тестируют что Excel правильно рассчитал формулу?
Немного. А такие тесты и не нужны. И про них вам никто и не говорил.
Плюс есть еще важный нюанс, чем проще ошибка, тем быстрее она обнаруживается в результате flow'а разработки (если такая ошибка попадает в мастер, она очень быстро попадает в непрод среду и ее сразу обнаруживают).
Воот. И бывают такие ошибки, которые не так уж просто обнаружить, которые проявляются только при определенных обстоятельствах, и которые вполне проходят в прод-среду. Для них и придумали тесты, которые должны запускаться при любых изменениях исходного кода.
Вы можете все же на простой вопрос ответить: вы согласны с тем, что чем декларативнее парадигма, тем меньше вероятность ошибки и тем меньше нужны тесты?
Я уже несколько раз ответил — нет.
Вы согласны с тем что например та же «чистота функций» (и отсутствие состояния), существенно важнее с точки зрения декларативности, а значит потенциальных ошибок, а значит и тестов?
Нет. Логика обработки у вас есть независимо от чистоты функций, одна функция может вызываться из другой независимо от чистоты функций, и внесение изменений есть независимо от чистоты функций. Тестирование наиболее важно для контроля поведения кода при внесении изменений.
Я просто пример привел, и то почему в том же 1С так носятся (и действительно нужно носится) с этими автотестами.
С автотестами носятся не только в 1С, а и в Java, C#, PHP, С++, где вполне себе есть полиморфизм.
Ок, а если конкретное решение удается тестировать именно flow'ом разработки (как я писал тут)
Это не тестирование. Тестирование это когда вы запускаете код и проверяете, что он дает тот результат, который нужен. Можно проверять это вручную, можно проверять автоматическим запуском программного кода, который делает те же проверки, которые вы делаете вручную.
Хотя не совсем так. То, что вы там описываете, это тестирование на пользователях, без каких-либо гарантий, что кто-то запустит тот код, который создает ошибку, а если и запустит, то сможет обнаружить, что это действительно ошибка, а не решит, что разработчики лучше знают.
Вам же в ответе на этот комментарий все объяснили.
Воот. И бывают такие ошибки, которые не так уж просто обнаружить, которые проявляются только при определенных обстоятельствах, и которые вполне проходят в прод-среду. Для них и придумали тесты, которые должны запускаться при любых изменениях исходного кода.
Да но эти ошибки как раз и возникают из-за состояний, то есть всяких race condition или сложных алгоритмов / сценариев. На чистых функциях и ограниченном числе операторов таких ошибок ГОРАЗДО меньше.
Я уже несколько раз ответил — нет.
Нет
Ну ок, боюсь это утверждение строго математически я вам вряд ли докажу, поэтому давайте на этом и остановимся.
С автотестами носятся не только в 1С, а и в Java, C#, PHP, С++, где вполне себе есть полиморфизм.
Так они тоже всего немного декларативнее 1С (хотя даже это уже очень важно). Поэтому естественно тоже носятся.
Вам же в ответе на этот комментарий все объяснили.
Ну там строго говоря, там такой же черно-белый комментарий, как и мы с вами спорим. Но давайте тогда последний вопрос: вы согласны, что если для задачи затраты на поддержание тестов > вероятности возникновения ошибки умноженной на ущерб от ее возникновения, то тесты лучше не поддерживать и наоборот?
— И бывают такие ошибки, которые не так уж просто обнаружить, которые проявляются только при определенных обстоятельствах, и которые вполне проходят в прод-среду
— Да но эти ошибки как раз и возникают из-за состояний, то есть всяких race condition или сложных алгоритмов / сценариев.
Эм, нет, они попадают в прод потому что их никто не заметил, а никто их не заметил потому что логика сложная, а не потому что реализация этой логики императивная или декларативная.
— вы согласны с тем, что чем декларативнее парадигма, тем меньше вероятность ошибки и тем меньше нужны тесты?
— Я уже несколько раз ответил — нет.
— Ну ок, боюсь это утверждение строго математически я вам вряд ли докажу, поэтому давайте на этом и остановимся.
Так не сможете вы это математически доказать, потому что это принципиально невозможно. Если у вас есть код, в котором есть функции, которые вы вызываете друг из друга, значит вам для контроля правильности поведения кода при изменениях нужны тесты. Которые делают ровно то же, что вы делаете вручную. Никто еще не придумал способа писать код и проверять соответствие его работы требованиям без проверки его работы.
Так они тоже всего немного декларативнее 1С (хотя даже это уже очень важно). Поэтому естественно тоже носятся.
Ну так тогда ваше утверждение "Это если у вас код императивен по уши, с эффектами последействий, состояниями, без полиморфизма (то есть тоннами if'ов) и т.п." неверно. Дело совсем не в полиморфизме (а также в наличии последствий и состояния), а в наличии логики обработки как таковой.
Ну там строго говоря, там такой же черно-белый комментарий, как и мы с вами спорим.
Эм, нет, там вполне себе нормальный комментарий, который описывает причины, по которым нужны тесты.
вы согласны, что если для задачи затраты на поддержание тестов > вероятности возникновения ошибки умноженной на ущерб от ее возникновения, то тесты лучше не поддерживать и наоборот?
Нет, потому что вы неправильно оцениваете вероятность возникновения ошибки.
Я сам часто работаю с кодом, где нет тестов, и знаю, что разрабатывать без автоматически запускающихся программных тестов проще, чем их писать. Просто я не согласен с вашими доводами о том, почему их не надо писать.
Эм, нет, они попадают в прод потому что их никто не заметил, а никто их не заметил потому что логика сложная, а не потому что реализация этой логики императивная или декларативная.
Давайте так, есть два вида сложности essential и accidental. И способ реализации логики влияет именно на вторую часть сложности. То есть представьте что вы логику реализуете максимально декларативно:
sum(Invoice i) = GROUP SUM quantity(InvoiceDetail id) * price(id) IF invoice(id) = i;
И то же самое реализуете скажем на ассемблере. Где вероятность ошибки выше? А вероятность ошибки напрямую влияет на необходимость тестирования. И все сводится к следующему:
Нет, потому что вы неправильно оцениваете вероятность возникновения ошибки.
Что значит вы неправильно оцениваете? Я привел формулу в которой предполагается, что вероятность оценена правильно в принципе. Или вы предполагаете что эта вероятность 100% всегда. Ну я вас разочарую, скажем часто во многих системах в качестве идентификатора генерят UUID. Вы же в курсе что он может повторяться, но вероятность его повторения 10 в минус очень большой степени (вероятность столкновения земли с астероидом). И ничего используют в продакшн системах с ошибками на миллион.
А если вероятность не 100%, то вы по сути спорите с определением, так как любой бизнес это максимизация матожидания прибыли, и если в моем сравнение левая часть больше, то смысла в тестах нет по определению.
И то же самое реализуете скажем на ассемблере. Где вероятность ошибки выше? А вероятность ошибки напрямую влияет на необходимость тестирования.
Нет. Вероятность ошибки имеет значение только при разработке, сколько раз у вас программа из-за неправильного стека упадет или неправильные значения выведет потому что вы в регистрах ошиблись. Если она запускается и работает как надо, значит на данный момент ошибок в ней нет, независимо от их вероятности. Тесты нужны не для написания кода в первый раз, а для контроля его поведения при дальнейших изменениях.
На ассемблере играет роль не вероятность ошибки, а количество мест, где может произойти ошибка. Это влияет не на необходимость тестирования, а на количество тестов. Чем больше таких мест, тем больше тестов, которые будут тестировать именно эти места. Но одно из таких мест есть всегда, это код верхнего уровня, из которого вызываются остальные, поэтому и тест на его работу нужен всегда. Вы именно это и делаете, когда проверяете вручную. Вы же не отправляете в продакшн код, ни разу его не проверив? Вот тесты это просто автоматизация этой работы.
На ассемблере нужно тестировать и высокоуровневую бизнес-логику, и технические детали реализации, на lsFusion только бизнес-логику. Я же объяснил уже, что разговор идет не о тестах деталей реализации, почему вы снова к этому возвращаетесь? Да, на ассемблере их будет больше, и это не отменяет необходимости тестировать код на других языках. В пределе количество тестов уменьшается до 1, а не до 0. Просто в силу существования кода, который что-то делает. Вот этот 1 тест и будет проверять, правильно ли он это делает.
Что значит вы неправильно оцениваете?
Вы же в курсе что он может повторяться, но вероятность его повторения 10 в минус очень большой степени
Ну то и значит, "10 в минус очень большой степени" это и есть оценка. Вы принимаете решение писать или не писать тесты на основе оценки вероятности, и считаете, что вероятность того, что ваш код при доработках разойдется с ожидаемыми требованиями, это 10 в минус очень большой степени и поэтому тесты писать не надо. А эта оценка неправильная, и от декларативности или императивности это не зависит. А зависит только от того, есть ли у вас функции, которые вызываются из других функций.
Если она запускается и работает как надо, значит на данный момент ошибок в ней нет, независимо от их вероятности.
Ну или вы просто не все сценарии оттестировали.
что вероятность того, что ваш код при доработках разойдется с ожидаемыми требованиями, это 10 в минус очень большой степени и поэтому тесты писать не надо.
Это с чего вы так решили? Может быть так: вероятность в течении цикла жизни ПО (скажем условные 5 лет) возникновения ошибки 5%, ущерб 10к долларов, затраты на поддержкание тестов в течении этого времени 600 долларов, соответственно в этом случае тестировать экономически неэффективно.
. А эта оценка неправильная, и от декларативности или императивности это не зависит.
Ну конечно. Как раз чем меньше у вас эффектов последействий, чем меньше у вас связанности кода, чем больше действий делается автоматически уже отлаженной платформой, тем естественно меньше вероятность получить ошибку в результате какого нибудь изменения (это собственно азы программирования) и тем меньше необходимость в автотестах.
Ну или вы просто не все сценарии оттестировали.
Естественно. Я говорил про работу тех, которые проверены.
Это с чего вы так решили?
Потому что вы говорите. что вам тесты писать не надо, потому что у вас декларативность и поэтому ошибок меньше.
соответственно в этом случае тестировать экономически неэффективно
Я спорю не про эффективность, а про ваши доводы что у вас декларативность предотвращает ошибки, и что декларативный код не надо тестировать.
затраты на поддержание тестов в течении этого времени 600 долларов
А затраты на ручное тестирование, которого без автоматических тестов будет больше, вы почему не учитываете?
Я согласен, что тесты можно не писать по экономическим причинам. Но вы же не только про экономические говорите.
Как раз чем меньше у вас эффектов последействий, чем меньше у вас связанности кода, чем больше действий делается автоматически уже отлаженной платформой, тем естественно меньше вероятность получить ошибку в результате какого нибудь изменения и тем меньше необходимость в автотестах.
Ну одно да потому. Нет. У вас есть бизнес-требования независимо от связанности вашего кода. У вас одна функция вызывает другую независимо от того, какая платформа это выполняет. Да, меньше необходимость в автотестах эффектов последействий, но необходимость в автотестах соответствия работы кода требованиям от этого не уменьшается. Вам говорят про вторые тесты, а не про первые. Первых будет меньше, но вторые все равно нужны.
Это как говорить, что у нас отлаженная платформа, поэтому мы сразу код в продакшн отправляем, без запуска и проверки работы. Вы согласны, что код перед отправкой в продакшн необходимо хотя бы раз запустить и проверить, что он работает как надо? Вот это и есть необходимость в тестах. Вы можете сделать их автотестами, или оставить ручными и тратить на них время каждый раз, необходимость в них не уменьшается от того, насколько декларативная у вас платформа.
Позвольте поинтересоваться, я правильно понимаю, что в ваших системах багов нет вообще? Ни на уровне платформы, ни на уровне реализации бизнес логики? Т.е. ваш багтрэкер чист?
Есть, но абсолютное большинство вычищаются на уровне альф / бет. И совсем немного остается на багфикс релизы.
Хотя баги у нас по определению имеют максимальный приоритет. Важно чтобы фундаментальные вещи были надежны как калашников, а рюшечки всегда вторичны.
Хотя баги у нас по определению имеют максимальный приоритет. Важно чтобы фундаментальные вещи были надежны как калашников, а рюшечки всегда вторичны.
Тогда мне абсолютно непонятно, как вы можете утверждать, что тесты не нужны. Но здесь, думаю, до первого кейса, когда после одного из обновлений модуля скидок на кассе скидка будет считаться не 2%, а 20%.
В этом и фокус, что по опыту в настолько высокодекларативной среде как lsFusion, такие ошибки не возникают. Проверено опытом (при том что у нас у многих клиентов по 5 доработок в день и ежедневные обновления).
У вас есть публичный багтрекер ошибок платформы и продуктов на ней?
У нас вся инфраструктура на гитхабе (точнее сейчас туда документацию переносим, тогда точно будет вся). Но при этом нужно понимать, что, как я уже писал, баги у нас имеют наивысший приоритет, то есть мы их фиксим сразу когда их нам сообщают / мы обнаруживаем, поэтому часто задачи создаются уже постфактум.
Так же интересует — что у вас с мультиязычной поддержкой? Я понял, что вы выносите все в ресурсы, но некоторые вещи меня заставляют окунаться прям в мир типовых. А именно — тут ошибка в ключе? Или это фича.
Это просто github так отображает, там нет ошибки в ключе. Вообще в Intellij будет отображаться нормальная кириллица, если включить опцию в File Encodings
А тут почему написан текст харкодом? Та и не только тут, а прям по всей системе. Это фича?
У нас сейчас реализовано два подхода к интернационализации. Первый — это идентификаторы в строковых литералах. Второй — когда все строковые литералы пишутся на каком-то языке, а механизм обратной интернационализации уже сам находит нужный идентификатор в ресурсных файлах. В модулях MyCompany используется, насколько я знаю, второй вариант сейчас.
Что там с документацией? Где ее почитать?
Я так понимаю, что документацию вы нашли? В основном все там плюс этот блог на хабре.
P.S. Вы вебинары делаете, или типо того, чтобы можно было лично вопросы позадавать, получить ответы и прочее.
Прямо сейчас (и в любое другое время) можно зайти к нам в слэк
P. S. Извиняюсь, не в той ветке ответил
Чем обосновано два подхода? Метите в проблемы, которые сейчас 1С пытается разрулить? Зачем приучивать людей даже смотреть на не правильный формат? И не увидел у вас — как вы подставляете параметры в серидину строки, например, надо вывести сообщение — " На складе ХХХ не хватает товара УУ в количестве ZZZ", как у вас будет выглядить шаблон строки, и как его заполнить кодом?
Ну в 1С например так:
Ну в 1С например так:
СтрШаблон(НСтр("ru='На складе %1 не хватает товара %2 в количестве %3'"), "XXX", "YY", "ZZZ")Чем обосновано два подхода?
Второй появился не так давно, оказался нужен людям (в том числе и каким-то нашим собственным решениям), которые сначала пишут решение с использованием своего родного языка для локального рынка и им видеть "живые" строки удобнее, а потом у них появляется необходимость в мультиязычности. Такой подход может помочь довольно быстро какую-то первичную мультиязычность получить. На самом деле, мы будем, конечно, улучшать весь функционал мультиязычности в недалеком будущем.
И не увидел у вас — как вы подставляете параметры в серидину строки
Если в контексте локализации, то для lsf кода, насколько я знаю, сейчас пока что никак, из java-кода такая возможность есть, но java — это, конечно, редкое явление в решениях. То есть в составном тексте кусочки пока что локализуются по отдельности. Есть функциональность, которая решает совсем другую задачу. Литерал может включать в себя множество идентификаторов: '{id1} = 10 {id2}'.
Если не в контексте локализации, то строчки сейчас в основном формируют с помощью CONCAT. Не помню, есть ли у нас в ближайших задачах появление какого-нибудь условного FORMAT c форматной строкой, но не помешало бы добавить что-нибудь в идеале похожее на f-strings в python.
А скажите пожалуйста, можно ли с помощью вашей системы реализовать чисто backend с REST API?
Можно, но тут какое дело. Основные преимущества lsFusion проявляются на сложных быстро меняющихся логиках (там где нужна модульность, оптимизации сложных запросов, полиморфизм, типизация, все фишки IDE и вот это вот все). То есть чем проще логика тем меньше преимуществ.
Соответственно, если вы в вашем backend будете просто читать данные в JSON и класть в базу без обработок с примитивным UI аля CRUD и / или REST API с получением первичных данных, то использовать lsFusion будет как из пушки по воробьям. Лучше взять что-то лайтовое. Если предполагается, что логика будет наворачиваться, формы и вычисления будут усложняться, сущностей становится больше, появятся задачи аналитики и т.п. то тогда да, имеет смысл смотреть в сторону lsFusion.
Соответственно, если вы в вашем backend будете просто читать данные в JSON и класть в базу без обработок с примитивным UI аля CRUD и / или REST API с получением первичных данных, то использовать lsFusion будет как из пушки по воробьям. Лучше взять что-то лайтовое. Если предполагается, что логика будет наворачиваться, формы и вычисления будут усложняться, сущностей становится больше, появятся задачи аналитики и т.п. то тогда да, имеет смысл смотреть в сторону lsFusion.
А можете, пожалуйста, дать ссылку на пример кода как это сделать?
В документации нашел, но не зная системы довольно сложно набросать тест.
Предполагается не простой CRUD, а с логикой, проверками, интеграциями. Просто интерфейс пользователя — красивая веб-страница.
Вот тут скорее всего можно найти часть нужной вам информации:
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=55935068
Документацию, как я понимаю вы тут нашли:
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=51216539
Есть еще места, например тут:
habr.com/ru/company/lsfusion/blog/460887/#fromext
Но там информация обрывками. Но, если что не понятно, заходите в slack, там могут на конкретные вопросы ответить.
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=55935068
Документацию, как я понимаю вы тут нашли:
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=51216539
Есть еще места, например тут:
habr.com/ru/company/lsfusion/blog/460887/#fromext
Но там информация обрывками. Но, если что не понятно, заходите в slack, там могут на конкретные вопросы ответить.
Не увидел ответа на главный вопрос, волнующий меня с точки зрения моего бизнеса — где можно посмотреть/пощщупать готовые решения (то, что в терминологии ругаемой Вами 1С называлось «конфигурациями»)?
Есть ли аналог УТ, «Проектный офис» и т.д.?
А то красочно описывать" из какого металла сделан мотор у автомобиля" можно долго, но меня в первую очередь интересует как он едет и как выглядит. ;)
Есть ли аналог УТ, «Проектный офис» и т.д.?
А то красочно описывать" из какого металла сделан мотор у автомобиля" можно долго, но меня в первую очередь интересует как он едет и как выглядит. ;)
ru.lsfusion.org/solutions (хотя тут надо понимать, что некоторые решения «не наши», и мы сюда постепенно новые добавляем / будем добавлять)
Еще WMS в разработке, скоро выйдет. Про MyCompany (предполагается будет основой для многих решений) можно почитать тут:
habr.com/ru/company/lsfusion/blog/541526
Ну и custom made'а много (всякие хитрые CRM для IT-бизнеса и BPM'ы для фондов), но это я так понимаю к вашему вопросу имеет мало отношения.
Еще WMS в разработке, скоро выйдет. Про MyCompany (предполагается будет основой для многих решений) можно почитать тут:
habr.com/ru/company/lsfusion/blog/541526
Ну и custom made'а много (всякие хитрые CRM для IT-бизнеса и BPM'ы для фондов), но это я так понимаю к вашему вопросу имеет мало отношения.
Бегло посмотрел MyCompany.
1) Готового обмена с 1С-Бухгалтерией, как я понимаю пока ещё нет? А это ежедневная и критически-важная задача для торговли/проектного офиса. Ибо платежи туда-сюда гонять и видеть надо в управленческой софтине. А платежи в банк-клиент через 1C.Бух идут…
2) Не увидел на вскидку — как можно ли выстраивать цепочку документов по проекту?
Заказ покупателя — заказы поставщикам — оплаты поставщикам — поступления товаров от поставщиков (то, что закупается строго под данный проект) — реализация товаров — реализация услуг — приход денег и т.п…
Или все операции только по отдельности будут виднеться, в единую цепочку не выстроить?
1) Готового обмена с 1С-Бухгалтерией, как я понимаю пока ещё нет? А это ежедневная и критически-важная задача для торговли/проектного офиса. Ибо платежи туда-сюда гонять и видеть надо в управленческой софтине. А платежи в банк-клиент через 1C.Бух идут…
2) Не увидел на вскидку — как можно ли выстраивать цепочку документов по проекту?
Заказ покупателя — заказы поставщикам — оплаты поставщикам — поступления товаров от поставщиков (то, что закупается строго под данный проект) — реализация товаров — реализация услуг — приход денег и т.п…
Или все операции только по отдельности будут виднеться, в единую цепочку не выстроить?
1) Готового обмена с 1С-Бухгалтерией, как я понимаю пока ещё нет? А это ежедневная и критически-важная задача для торговли/проектного офиса. Ибо платежи туда-сюда гонять и видеть надо в управленческой софтине. А платежи в банк-клиент через 1C.Бух идут…Сейчас как раз обмен через EnterpriseData пилим. Пока добавили только для теста передачу документа Поступление, но в ближайшее время и другие докинем. С платежами там все сложнее, так как в их формате разные виды платежей разными документами идут. Но тоже постараемся сделать.
2) Не увидел на вскидку — как можно ли выстраивать цепочку документов по проекту?Сейчас там процессы с большего сделаны под логику хранения на складе (как в базовой Odoo), а не для работы под заказ. То есть есть связь Заказ / Поступление / Приемка / Оплата и Заказ / Отгрузка / Реализация / Оплата. Пока связи заказа покупателя и поставщика нет. Но опять же будем добавлять в будущих версиях.
Заказ покупателя — заказы поставщикам — оплаты поставщикам — поступления товаров от поставщиков (то, что закупается строго под данный проект) — реализация товаров — реализация услуг — приход денег и т.п…
Или все операции только по отдельности будут виднеться, в единую цепочку не выстроить?
Почему lsFusion, а не 1С?