Pull to refresh

Comments 1789

Не моя тема, но все равно встряну. Знаете, что самое забавное. Я на хабре долгое время был с неполноценным аккаунтом (то есть read only). Но в принципе меня это не смущало, я оставлял комменты — разные критические и наоборот. И их всегда одобряли. Всегда кроме одного случая. Когда я в статье самого 1С спросил, а зачем они разделяли сервер и клиент (ну с пояснениями в стиле этой статьи). Его просто завернули. Видимо их такие мелкие проблемы не волнуют, ну или не барское это дело отвечать на такие вопросы.

У платформы 1С действительно есть недостатки, но есть и преимущества, которые перевешивают недостатки.
ИМХО 1С-ный ОРМ покрывает около 95-97% типичных учетных задач, автоматизацией которых занимаются "автоматизаторы"! финансового и управленческого учета.


С 1С ковыряюсь с 2002 года и мне очень редко было необходимо работать в обход 1С-ного ОРМ, непосредственно с SQL-сервером. Создать 3-4 вьюва исключительно для ускорения работы или заполнить прямыми запросами новый регистр.
А достаточно мощный механизм внешних компонент и работа с OLE/COM объектами из встроенного языка способны покрыть все остальные нетипичные задачи.
Ну а огромнейший каталог готовых решений — очень экономит время. Ну, вы и сами знаете. :)
ПС. полезно смотреть на продукт глазами стороннего от 1С человека, можно понять, что ты пропустил.
ПС2. Время — один из ценнейших ресурсов разработчика сейчас. И с его экономией 1С справляется на твердую четверку с плюсом.

Кстати, с тех пор как 1С отвергла идею внедрить в 1С конфигуратор наработки Орефкова по снегопату/openconf-у(1), я к 1С-у отношусь как к типичным барыгам, не более того.


(1) Это что-то наподобие визуал-асиста для MS VS студии.

Да понимаю тебя, сам не могу понять как сообщество терпит, видно вместо того чтобы сказать об этом — сообщесто прогресивных решило так — «а давайте мы сделаем работу 1с и назовём это опен соуросом», смешно получается.
но снегопаду отдельный респект — никогда не сдаваться.
Ох да, автор прекрасен. Забайтил на регу на хурбербере.
Такой некомпетентности в подобных вбросах я ещё не всетрчал.
Например про «Неэффективное получение данных объектов» или про «Отсутствие ограничений и событий для значений регистров» — это прекрасно, автор.
А ещё это: «В параметрах виртуальных таблиц можно использовать только константы».
Господи, я понимаю почему 1С заминает подобные темы, потому что за такое количество времени людей просто достало отвечать вот на подобные «гав».
Ну это правда смешно)
И если бы в других статьях хотелось бы ещё поспорить или указать на неточность в понимании ПРОБЛЕМЫ автором, то тут просто эпик. Это реферат, видимо) Просто уникальное НЕПОНИМАНИЕ матчасти вами же так глубоко ненавистной 1С)
Поднял настроение с утра, спасибо, знающий человек))
Очень конструктивный комментарий. Спасибо.

Если вы уж говорите о некомпетентности, так напишите что конкретно не так. А так на истерику больше похоже.
Знаете, автор, ваше творение просто не выдерживает критики. Я понимаю, что на вашем сайте ваше решение содержит одни + в зеленых квадратиках, на фоне других платформ, но просто из интереса, пообщались бы с 1С разработчиком, прежде чем вбрасывать ЭТО и сидеть тут и жать Ф5, в поисках одобрения людей, которые видя что либо плохое в сторону 1С сразу ляпнут лукас)
Вы наверное на мисте 6 частей (по 1000 сообщений) обсуждений пропустили. Конечно на мисте называть что-то обсуждениями — очень сильно ей льстить. Хотя определенный шарм в таких срачах все же есть (как с семечками или черешней, тяжело остановиться когда уже начал). Собственно много пунктов из обсуждений на мисте и пришло.
Странное ощущение — что именно то не выдерживает критики? Я опытный разработчик 1С и могу подтвердить что всё что тут перечисленно большая боль для меня — и самое больное что 1С совсем не собирается что то сделать полезное, всё что она может это изолироваться и поддерживать клуб любителей такой изоляции.
Я со всем согласен кроме части про блокировки и СКД.

На самом деле управляемые блокировки достаточно удобны и в друхе времени.
СКД тоже не имеет аналогов. Возможно позиционирование у него и правда не до конца выверено, но продвинутым пользователям очень нравится.

У меня есть опыт работы с BI (особенно с MS BI) и могу сказать что пользователи вообще не могут работать с BI системами, они слишком сложны для них.
Если я им дашборды создам то да, они могут, где то могут поля перетянуть, но на этом все.

В то же время совсем нулевые девочки из ЗУП которые даже компьютер сами выключить не могут, активно используют отчеты на СКД (конечно обернутые в более дружественный интерфейс).
На самом деле управляемые блокировки достаточно удобны и в друхе времени.

А что в них удобного? По сути нужно в голове все race condition держать, что очень сложная задача. Repeatable read с прозрачными материализациями и / или FOR UPDATE в ограничениях куда проще и удобнее.

А СКД — да, как такой «BI для бедных» может и имеет смысл. Но а) настройки в ним такие же примитивные как в BI — то есть группировка по полям, поля по прямым ссылкам (никаких регистров) и формулы, б) они нагружают оперативную базу, в) визуализация (например цветовая) там гораздо хуже чем в большинстве BI Tools.

Да и с точки зрения UX Еще->Изменить Вариант на порядок уступает тому же Imply.

Но это если мы говорим про пользовательские настройки. Как конструктор отчетов он не сильно лучше и не сильно хуже стандартных Crystal/Fast/Jasper и т.п. Собственно неудивительно что его аналога в мире никто и не делал, потому как непонятно зачем.
UFO just landed and posted this here
Приведите пример где конкретно нужно «учить матчасть».
UFO just landed and posted this here
One to many это когда вы можете любую таблицу по полю замаппить в коллекцию любого объекта по полю. В 1с это можно сделать в очень частных случаях.

Про чтение, если вы обратитесь к объекту по ссылке (как это принято в orm) он считается целиком (с табличными частями). Я ссылку в статье давал.

Убогость заключается в том что нет инструментов борьбы с проблемой N+1.

Голый sql это все эти ВЫБРАТЬ ИЗ СОЕДИНЕНИЕ, которые по сути тот же самый SQL но на русском.

Возвращается к ORM — то есть считывают объекты и обращаются к ним по ссылкам, в циклах и т.п.

ЗЫ: с телефона не очень удобно отвечать, чуть позже отвечу подробнее.
One to many это когда вы можете любую таблицу по полю замаппить в коллекцию любого объекта по полю. В 1с это можно сделать в очень частных случаях.

Критерии отбора не подойдут?
Какое отношение они к ORM имеют?
UFO just landed and posted this here
А можно прикладной неабстрактный пример такой потребности в терминах бизнес-логики, для понимания? Чтобы не обсуждать сферического коня в вакууме.


Вообще, если вы заметили это не в проблемах было, а именно в описании как это в 1С сделано. Я сам, если честно против классического ORM, но раз в 1С его решили поддерживать, то делали бы это нормально. А так ни рыба, ни мясо получилось.
Что мешает дёрнуть все нужные реквизиты в первом же запросе, не формируя по одному запросу для каждой ссылки? Обойдемся ровно одним запросом.

Потому как это уже не ORM по сути.
Это вкусовщина. А вот приведите хороший, годный ORM с более простым синтаксисом, чем этот? Работал я на SQLAlchemy — вот где ад и израиль, для не очень примитивных запросов приходилось перерывать их документацию чуть менее, чем полностью (и иногда в итоге скатываясь к конструкциям, которые поддерживаются только конкретным движком). А тут пиши себе на SQL-like языке, который платформа сама транслирует в нужный диалект. По мне так это удобно и колоссально снижает порог вхождения. Но если у вас есть примеры более удобных подходов — с удовольствием ознакомлюсь.

Не понимаю, чем свой диалект снижает порог вхождения. Скорее наоборот.

Про более удобные подходы позабавило. Тут нас одна половина обвиняет в ангажированности, а вторые искренне удивляются, что мы предлагаем взамен. Более удобный подход — оставить объекты и сделать более декларативный и высокоуровневый язык чем SQL без инкапсуляции (не на таблицах а на функциях). И с кучей других возможностей.
Я сам, если честно против классического ORM, но раз в 1С его решили поддерживать, то делали бы это нормально. А так ни рыба, ни мясо получилось

Ну… 1С вообще-то и не говорят что у них ORM (https://habr.com/ru/company/1c/blog/334050/)
Да это эпичная статья, наглядно показывающая, какая каша в голове у них творится, и собственно почему у них такое количество текущих и избыточных абстракций.

Хотя на самом деле, у них просто обе парадигмы поддерживаются и обе убого. О чем собственно и написано в обсуждаемой статье.
Ну, это ваше мнение, спорить с ним смысла не вижу.
Удобство, убогость и т.п. это все-таки вкусовщина.

Желаю вам найти заинтересованных в вашей платформе клиентов и разработчиков.
UFO just landed and posted this here
воспринимается намного менее прозрачно, чем

Ну вы тут немного лукавите, взяли разные по сложности запросы, переводы строк добавили, ну и т.п. Вы с HQL hibernate'ским лучше сравните.
А можно на уровне идеи как это должно работать? (или rbymnt ссылкой). Вот честно интересно. Сабжевый ORM'ный «более высокоуровневый язык на функциях» всё равно движку придется в конечном итоге превращать в конечные запросы MSSQL, Postgre и Ко, иначе как без этого дёрнуть данные из базы. Как процедурный язык с произвольным кодом превратить в эффективный SQL-запрос? (а не в соответствующую неэффективную лапшу на каком-нибудь T-SQL под капотом с курсорами и подзапросами в циклах).

Ну вот так например. Но вообще можете в блоге посмотреть статьи. Что касается эффективности запросов, то можете статью «Почему не SQL?» почитать, чтобы понимать какого класса оптимизации делаются в том же lsFusion.
У 1Сников то всё просто: отрезали все расширения разных диалектах, и почти один-в-один транслируют свой суррогатный язык запросов в запросы движков, местами добавляя постобработки в виде СКД. Далеко не супер гибко, зато достаточно эффективно (в рамках ограничений, налагаемых «кроссдвижковостью» конечно).

Ну в 1С как раз все по старинке императивно. Такой ПХП с парой высокоуровневых абстракций и визуальным программированием.
А можно прикладной неабстрактный пример такой потребности в терминах бизнес-логики, для понимания? Чтобы не обсуждать сферического коня в вакууме.

Могу привести реальный пример.

Конфигурация «Деньги» — очень маленькая и простая конфигурация для домашней бухгалтерии. Есть документ Расход, куда построчно можно вводить данные чека, например. Данные вводятся в табличную часть. Конфа позволяет для каждой строки табличной части задать произвольное количество аналитик. То есть, в строке табличной части может быть просто «статья расхода, сумма, количество», а может быть «статья расхода, сумма, количество, проект, финансовая цель, важность,…, на что хватит фантазии». То есть в строке табличной части произвольное количество столбцов.

Как это реализовано. В строке хранится ссылка на справочник «Пакеты аналитик статей». В справочнике нет реквизитов, только табличная часть с ссылками на аналитику и их значениями. При сохранении документа Расход система ищет в этом справочнике элемент с таким же набором аналитик и значений как в табличной части, и если не находит, создаёт новый элемент справочника.

Оно работает, но реализацию вряд ли можно назвать красивой. Вместо того, чтобы сделать «табличную часть строки табличной части», пришлось создавать избыточный объект-справочник, который в интерфейс не выводится и содержит кучу ненужного для такой задачи функционала. Плюс хранится как отдельный объект и программисту нужно отдельно продумывать создание, поиск и удаление, разворачивание данных в столбцы и сворачивание обратно.

Это костыль, но по другому сделать не получается. Хранение каких-то сложных параметров в справочниках, чтобы ссылку на элемент справочника записать в регистр или табличную часть — вполне обычное явление.
UFO just landed and posted this here
Ну да, можно и по другому. Ещё можно сделать регистр и хранить данные в нём. Кстати, несколько табличных частей не получится создать в регистрах. Но всё это не отменяет факта того, что тривиальная задача для СУБД выливается в «изобретательство».

Вышеописанное — не моё изобретение. «Деньги» — конфа, которая пишется «разработчиками 1с».

Я бы не отказался от возможности создавать «табличную часть» для любого реквизита. Ещё очень не хватает возможности создавать функции в записях структуры (хотя бы записывать ссылки на функции) — можно было бы накостылить аналог ООП.

Но вообще, вы просили пример, я его привёл. Нерешаемых задач нет — в крайнем случае можно всё хранить в xml в хранилище значения (кстати так поступают/ли с контактными данными в типовых конфигурациях, если мне не изменяет память). Но, имхо, ограничения платформы зачастую мешают, и часто спотыкаешься, если не пилишь стандартную систему количественного учёта чего-нибудь.
Про чтение, если вы обратитесь к объекту по ссылке (как это принято в orm) он считается целиком (с табличными частями). Я ссылку в статье давал.

Предвзято лукавите. А как на счёт этого
Однако запрос будет выполнять считывание из базы данных при каждом вызове. Соответственно, при многократном обращении к одним и тем же данным будет выполняться многократное считывание. Этого можно избежать, обращаясь к свойствам ссылки. В этом случае используется кэширование объектов и в определенном интервале времени при повторном обращении к данным объекта не будет выполняться повторное считывание

its.1c.ru/db/metod8dev/content/2717/hdoc
И как кэширование меняет факт того, что он считается целиком с табличными частями? И главное вы же понимаете, что кэширование помогает только при повторном обращении в одном вызове к одним и тем же данным (что далеко не главная проблема).
Если большинство данных нужно будет использовать несколько раз за вызов, то логично получить все объект через ссылку и чтобы он закэшировался. Если нужно всего несколько реквизитов объектов (объекта), то можно воспользоваться запросом. Но обычно через ссылку данные получают только для изменения, для чтения пользуются запросом
Вы же понимаете насколько более неудобным и многословным код делает использование такого подхода с чтением через запросы? Да, в 1с по другому никак, но это не значит что это хорошо и удобно.
UFO just landed and posted this here
Я ниже с ходу предложил костыльное решение https://habr.com/ru/company/lsfusion/blog/468415/#comment_20703549
А если хорошенько подумать можно и гораздо менее костыльное придумать используя анализ кода для оптимизаций. Просто то что я предложил — не должно быть сложно реализуемым в платформе, другие решения, более удобные и красивые, могут оказаться гораздо сложнее а то и нереализуемыми если оставить язык 1с.
Нет, не так. lsFusion все сама соберет в один запрос и одним запросом все считает. Но даже если не получится, кэширование в виде всяких shared buffers уже есть в самой СУБД. То есть по факту, если вы два раза считаете одни и те же данные ничего страшного. Если конечно вам при этом все равно надо считывать другие данные, и количество запросов будет минимальным.

И вообще, работа с данными на сервере приложений, это в принципе зло и убийство производительности (он для этого не предназначен).
чуть позже отвечу подробнее


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

А те кто начинают с этим спорить, не смогут вас понять все равно.
И, естественно, настоящие 1С-программисты не будут снисходить до уровня простого Java/SQL-разработчика, чтобы пояснить, какую именно матчасть учить, и в чем он ошибается. Ах да — у 1С же документация платная, и бесплатно никто ничего пояснять не будет. Это же не в стиле 1С экосистемы.

Вас обманули. "1С: Предприятие 8.3. Версия для обучения программированию" можно получить бесплатно по первой ссылке в гугле указав е-mail и какие-то регистрационные данные. В комплекте кроме документации еще и книжки какие-то были. Ну и бухгалтерия типовая вроде бы в качестве решения.

Это не та документация, увы. Тоже в свое время будучи 1сником разочаровался что с доступом к документации беда без ИТС.
UFO just landed and posted this here
Эээ. У MS Dynamics как раз вроде как бесплатная документация. Я там много чего находил.

Microsoft в последнее время вообще радует своей открытостью во всем.
Потому что это практически единственный их шанс выжить. Иначе никому не нужна будет их документация и проще будет забыть про майкрософт, чем покупать документацию. Были бы они на коне как раньше, была бы такая же платная документация и прочее. А сейчас для них это вопрос жизни, потому и открыты.
Майкрософт еще не скоро умрет — это не вопрос жизни и смерти для них. И речь идет не только об открытости документации, а также об их недавнем повороте в сторону линукса и сообщества в целом.
Если бы не повернулись, это было бы началом ихнего конца.
Замечу: Желтые книжки про синтаксис — по сути «распечатанный» синтакс-помощник, который поставляется вместе с платформой.
Для «личного самообучения» есть Версия для обучения программированию, которую можно вообще скачать бесплатно.
UFO just landed and posted this here

В смысле не та? Там руководство разработчика, руководство администратора, книжка про начало программирования в 1с. Что вы еще желаете там увидеть? У ИТС-техно объем документации в точности такой. Но за деньги. )

Ну человека в начале этой ветки послали матчасть учить, т.е. правильные 1сные практики (вроде тех что на спеце по платформе проверяются), работу с БСП и какими то стандартными решениями и прочее. Ну и кстати, если заказывать коробку — это не бесплатно (там все эти руководства и Радченко). Если заказывать в электронном виде — там этого нет (не было когда я это делал по крайней мере).
А почему у меня вот по этой ссылке дает только демо-доступ на 7 дней?

Назовите мне еще хоть одну вменяемую технологию, где документация за деньги (причем еще и по подписке)?

Вы все-таки скачайте версию для обучения. Вам дадут пожизненный доступ на сайт ИТС для обновления и к документации для разработчиков.


За деньги и по подписке обновления конфигураций на том же сайте. Выше же указано, что 1с собрав со всех денег за обновление бухгалтерии может писать хоть на ассемблере ))

Разве уже дают? У меня этого доступа нет, хотя версию для обучения даже коробку покупал, только к обновлениям платформы и совсем базовой документации. Может что покупал 5 лет назад а не сейчас…
Вы все-таки скачайте версию для обучения. Вам дадут пожизненный доступ на сайт ИТС для обновления и к документации для разработчиков.

Я скачал. Мне не дали. Что я сделал не так?

Я не знаю. Мне когда-то дали. Документацию-то в поставку положили?

Потому что в ИТС документация это очень малая часть того что там есть, основное назначение итс — обзор изменения законодательства и как это поддерживается в 1с, т.е. по сути некий аналог консультант+
UFO just landed and posted this here
Ах да — у 1С же документация платная, и бесплатно никто ничего пояснять не будет. Это же не в стиле 1С экосистемы.

You're welcome:
https://toster.ru/tag/1с/questions — 1310 вопросов, 59% решено
https://toster.ru/tag/1с-предприятие/questions — 503 вопроса, 57% решено.
Но это для тех, кто случайно сталкивается с 1С. Более глубокие вопросы бесплатно прорабатываются на инфостарте.
В том, что у 1C есть большое коммьюнити и Q&A ресурсы, никто не сомневается. (1310 вопросов — это, правда, как-то мелковато для того количества программистов и того времени, которое существует платформа). На ru.stackoverflow, например, есть еще 3-4 сотни вопросов. Вот только это ни разу не документация. По Q&A вряд ли получится что-то с нуля изучить.
DAleby претензия же была к тому, что никто не помогает? Помогают!

Согласен, что глупо изучать работу с платформой 1С по форумам и чатам. Для этого есть документация! Можно бесплатно и официально скачать учебную платформу, общую документацию, популярные конфигурации и книги Радченка с Хрусталевой — online.1c.ru/catalog/free/18610119

Знания автора об 1с поверхностные. И устарели.

Я когда-нибудь устану такие комменты одобрять. Но потом же будут говорить цензура.

Слушаю и ваши комментарии. Что, где, по какому пункту не так?
А так, у меня два вопроса к авторам, просьба ответить честно:
1. Для кого написана эта статья?
2. Для чего написана эта статья?
Для того же для чего пишут все статьи на хабре. Рассказать про проблемы технологий (в данном случае конкретной технологии) и способы их решения. Как для 1С разработчиков, так и для других разработчиков бизнес-приложений и вообще бэкендов (чтобы они знали «как там у них», да и проблемы у них во многом могут быть схожие).
И, совершенно случайно, в корпоративном блоге компании, не имеющей никакого отношения к критикуемой технологии? Спасибо за честный ответ.
А Вы видели как Ауди с БМВ троллили друг друга в рекламе? Было достаточно забавно и никакого особо негатива. Сторонним наблюдателям было интересно.
Ну как бы весовые категории в данном случае несколько, скажем так, различные. Я как раз и пытался узнать, для кого они эту рекламу написали, но не судьба, видимо.
Например, когда у кого-то, кто конкурирует с 1С, будут спрашивать, а чем плох 1С, то ему смогут давать ссылку на эту статью.
Если только конкурируют платформы для разработки, а не готовые решения. Я, правда, слабо представляю подобную конкуренцию между 1С и lsfusion, ниши практически не пересекающиеся.
Тут речь не только про lsFusion идет. Если у меня написано на .Net, а у кого-то на 1С, то можно говорить, что там хуже, так как строится на слабой платформе (по крайней мере, с точки зрения маркетинга). Все же понимают, что дом построенный на плохом фундаменте будет хуже, чем тот, который построен на хорошем.
Сравнивать будут решения по функциональности и качеству решения проблем бизнеса, в первую очередь, стоимости доработки и сопровождения во вторую.
Если же брать разработку с нуля — lsfusion надо тогда сравнивать с .Net, CUBA, odoo. 1С больше про готовые решения, а не про платформу.
Вы не поверите, на 1С много отраслевых и самописок с нуля пишут. О чем собственно и сказано в статье.
Так отраслёвки пишут обычно франчи 1С, часто как нашлёпки на типовые от 1С, на чём же ещё их писать франчам? С нуля от независимых разработчиков знаю только про WMS системы, и отдельные редкие случаи, вроде Деловых линий.
А я очень много знаю. Более того в Беларуси основной игрок на рынке бухгалтерии (!) свою конфигурацию с нуля писал. Ну или на рынке FMCG розницы (где Астор например тоже с нуля свою конфу делает).

И вообще у чуть более крупных клиентов самописок на 1С более чем достаточно.
Не знаю как у вас там, в Беларуси, а в России самописки на 1С у крупняка обычно получаются в результате многолетней доработки изначально типовой 1С, которая происходила параллельно с ростом бизнеса. Чтобы так осмысленно взять, и в крупной компании абсолютно с нуля писать своё на 1С — это очень большая редкость. Астор, опять же, тоже скорее всего из франчей/отдела 1С-ников вышел, так что ниразу не показатель.
Вы видимо в обсуждении на мисте не учавствовали. Вы же понимаете, что к примеру УТ или ERP для FMCG розницы (да и не FMCG) не подходит никак (там половины нужных модулей нет). И допилить УТ до нужного состояния это все равно что из танка самолет сделать. Особенно с учетом убогости возможностей рефакторинга в платформе. И Астор с нуля писал, не понимаю почему не показатель.
Писал Астор с нуля на 1С потому, что уже имел штат специалистов по 1С, а не потому, что осознанно выбрал эту платформу. То, что типовые от 1С — далеко не идеал, спорить не буду, это мне вполне очевидно.
Астор — образовывался как 1с-ный франч :)
Ну, что и требовалось доказать :)
Помню ту конфу для розничной торговли (Модный магазин), их первая попытка перейти на 8-ю платформу. Долго они пытались нам её внедрить, всё время хотели, чтобы мы переделали свои бизнес-процессы под их алгоритмы. В результате год потерянного времени и куча денег в никуда. Потом перешли на самописку на основе типовой Розницы.
UFO just landed and posted this here
Нравится <> Идеал. То, что могло быть намного хуже — согласен. Но могло быть и намного лучше :)
UFO just landed and posted this here
Как платформа 1С проигрывает всем на рынке. Даже SAP. Причем практически по всем пунктам. Но раз ей нет равных в мире, посмотрим как ей удастся выйти на англоязычный рынок без существующих разработчиков, и поддержки перемудреного местного законодательства. Шляпу готовы съесть, если в течении 5 лет они даже 0.01% мирового рынка не займут?
Как платформа 1С проигрывает всем на рынке. Даже SAP. Причем практически по всем пунктам.


Рынок считает иначе и голосует рублем сами знаете за кого — в 1С несут денежки и сторонним программистам, занимющимся 1С.
SAP, кстати, тоже та еще шляпа со своими проблемами. Напрасно вы ее как пример лучшего решения приводите.

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

а по поводу мирового рынка, на родине SAP не так давно дойчебанк С ГОРДОСТЬЮ ХВАСТАЛСЯ о том что у них появился андроидпэй… эпл пей пока нет но вот андроидпэй появился…

так что заливать про мировой рынок не надо…

Вы так говорите, как будто функционирование androidpay и applepay это заслуга 1С.

я так говорю в пример того что «мировой опыт» зачастую где то там далеко отстает от российского… как например в сфере распространения бесконтактных платежей…

вроде — родина SAP — а телефоном расплатиться в метро или где-нибудь там в палатке покупая мороженку — нельзя… технологии то не позволяют…
я так говорю в пример того что «мировой опыт» зачастую где то там далеко отстает от российского…

Особенно в разработке ПО, да.

мой пример был приведен в качестве того что безапелляционно и закрыв глаза повторять что «мировой опыт всегда на шаг впереди российского» — по крайней мере не верно…

а по поводу разработки отраслевого ПО — ну вот пример 1С… есть аналогичные системы с подобным сбалансированным функционалом, стоимостью, порогом вхождения, поддержкой нац/законодательств на западе?
безапелляционно и закрыв глаза повторять что «мировой опыт всегда на шаг впереди российского»

А кто это говорил?


есть аналогичные системы с подобным сбалансированным функционалом, стоимостью, порогом вхождения, поддержкой нац/законодательств на западе?

На западе есть системы автоматизации учета на предприятиях, которые удовлетворяют тамошних заказчиков. С поддержкой национальных законодательств, конечно же. Не могу сравнить их функциональность и порог вхождения с 1С, конечно же, но кого это волнует, если их функциональность достаточна для заказчика, а стоимость разработки достаточно низка, чтобы заказчик мог себе это позволить?


И как минимум в США как минимум для SMB на этом рынке весьма жесткая драка.

А кто это говорил?


таков контекст беседы…

Не могу сравнить их функциональность и порог вхождения с 1С, конечно же, но кого это волнует


однако то что 1С ну просто никак не может быть более продвинутым и качественным продуктом чем некие западные решения вы не сомневаетесь…
таков контекст беседы…

Это вы его себе таким придумали. Если хочется сражаться с пугалом — сколько угодно, но без меня.


однако то что 1С ну просто никак не может быть более продвинутым и качественным продуктом чем некие западные решения вы не сомневаетесь…

Скорее наоборот: я пока не вижу оснований считать, что 1С — это более продвинутый и качественный продукт, чем (нужное вписать).

Это вы его себе таким придумали. Если хочется сражаться с пугалом — сколько угодно, но без меня.


а я и не вам отвечал…

Скорее наоборот: я пока не вижу оснований считать, что 1С — это более продвинутый и качественный продукт, чем (нужное вписать).


не видите — не считайте.
не видите — не считайте

Тогда в чем смысл вопроса "есть аналогичные системы [...] на западе?"

У них это по другой причине сложилось. Там где прежде не было вообще никаких технологий, новые технологии ложатся как масло на хлеб. А там где работают старые технологии, новые часто конфликтуют и поэтому их внедрение затормаживается и требует серьёзного пинка чтобы пропихнуть. В конце концов, другие страны можно использовать как полигон для масштабной натурной обкатки технологий и выявление её слабых мест.
UFO just landed and posted this here
Он никак не считает. Он ест, что дают.

И 1С не лучше всего остального, просто остальное, что существовало на рынке, не сильно лучше, того что предлагал / предлагает 1С. Поэтому не смогло его подвинуть, равно как и наоборот.
Он никак не считает. Он ест, что дают.

И почему же тогда приходится напрягаться, что-то выдумывать? А чё попало рынок почему-то не хавает.

Рынок всегда ест то, что первое успело заскочить на рынок с MVP и/или попав в массовую нишу (бухгалтерию например). А дальше на этом рынке его в состоянии подвинуть, только что-то фундаментально лучше (чем альтернативы 1С не являются, явно как и 1С не лучше своих текущих альтернатив).
ну как бы 1С не первая заскочила на рынок… она выдавила с него многих и многих… и продолжает выдавливать…
UFO just landed and posted this here
UFO just landed and posted this here
… это все равно что из танка самолет сделать

Ох, как всё это знакомо.
1. Если знаете много и пишут с нуля значит есть смысл.
2. Если разговор про конфигурацию от Хьюменсистем. То это не пример нормальной/качественной разработки, а пример «впаривания» продукта. В которой ресурсов на защиту потрачено больше чем на бизнес функционал.
У меня сложилось впечатление что автор многие вещи пересказывает «со слов»
Но в конце автор и задается вопросом почему платформу 1с выбирают для разработки новых решений, вместо выбора более удобных вещей. У меня честно говоря только одно предположение — бренд и сеть франчайзи которая допилит в любой деревне за копейки новую колонку в отчет.
Так кто выбирает то, приведите примеры?
Например компания в которой я работал пишут «Итилиум», «1С: ТОИР», «1С:RCM». Но то ладно, то уже черт знает сколько лет франч (хотя для мобильных приложений их никто не заставлял 1с выбирать, наверно, отношения с вендором не очень хорошо знаю).
А так, сколько на инфостарте статей про новые «нетленки»? Иногда даже от частных лиц. Внутренние проекты иногда начинают на 1с, хотя даже не планируют во вне выпускать, но тут наверно по наличию ресурсов выбирают, какие программисты есть под рукой, те и пишут.
Ну вы же понимаете, что код как в статье допиливать — это мягко говоря не каждому под силу. Тем более в деревне. Мне стремно в него лезть, боясь что где-то что-то упадет, а уж франчу…

Собственно на том же рынке FMCG розницы в Астор даже компании со своим штатом 1С программистов боятся лезть (не то что франчи).
Ну вы же понимаете, что код как в статье допиливать — это мягко говоря не каждому под силу. Тем более в деревне. Мне стремно в него лезть, боясь что где-то что-то упадет, а уж франчу…

Именно по этому качеству ваша система сливает 1С вчистую.
Уж что-что, а программисты по 1С как раз сыщатся влегкую.
Но не те, кто станет разбераться в вашей системе.

Собственно на том же рынке FMCG розницы в Астор даже компании со своим штатом 1С программистов боятся лезть (не то что франчи).


Да ладно, боятся.
Может, просто потому что нужно работать на том рынке, что ты хорошо знаешь и который тебе и приносит хорошее бабло?

Это как Боинг стал бы автомобили строить. Тоже интересный рынок. Но не его. Они на самолетах специализируются.

UFO just landed and posted this here
Ну вы еще бы в машинных кодах писали вместо того чтобы взять java, .net, python и подобное.
UFO just landed and posted this here
C# лучше потому что язык статически типизированный с ООП и нотками функциональщины. А не потому что кто то более выскоуровневый кто то менее. Да и что это за параметр «крутость»? Важно удобство, скорость решения задач, сложность поддержки и развития и прочее.
C# лучше потому что язык статически типизированный с ООП и нотками функциональщины.


Лучше вообще?
Или, все же, лучше для задач, в которых используется 1С?

Понимаете в чем дело:

Если вы возьметесь реализовывать учетную систему для бизнеса с C# прямо сейчас, то, конечно, кода будет значительно больше на тех же задачах, для которых предназначена 1С.

Ведь язык 1С управляет объектами, предоставленными ему платформой.

То есть выразительность для написания сложных алгоритмов — это не то, что является необходостью/крутостью в данном случае.

Понимаете, в чем дело:

Если язык обладает крутостью как C#, он усложнен. Но эта сложность не востребована на алгоритмически простых задачах.

Наложите любой современный язык на 1с — и увидите как резко растет производительность (можно с опциональной типизацией вроде typescript, python). Плюсы ООП и статической типизации не в выразительности для написания сложных алгоритмов (что бы под этим не подразумевалось), а в возможности повышать уровень абстракции (ооп) и делать это относительно безопасно и с минимумом ошибок (статическая типизация, контракты, интерфейсы). Плюс поддержка такого кода легче так как снижается количество ошибок и не нужно в голове держать нижележащие слои при реализации бизнес логики.
И что за крутость? Что это за параметр такой?
Плюсы ООП и статической типизации не в выразительности для написания сложных алгоритмов (что бы под этим не подразумевалось), а в возможности повышать уровень абстракции (ооп)


Это одно и то же.

Вот только значительная часть абстракций в 1С вынесена за пределы самого языка, реализована в платформе.

и делать это относительно безопасно и с минимумом ошибок (статическая типизация, контракты, интерфейсы). Плюс поддержка такого кода легче так как снижается количество ошибок и не нужно в голове держать нижележащие слои при реализации бизнес логики.


Да, все правильно.

Видимо, и плюсы динамической типизации вам известны тоже?

Ну а теперь назовите плюсы динамической типизации и наложите их на задачи в 1С — и вам все станет ясно.

Вот только значительная часть абстракций в 1С вынесена за пределы самого языка, реализована в платформе.

Вот в этом пункте у нас нестыковка основная. Вы считаете что вынесена в платформу, я считаю что даже БСП довольно низкоуровневая штука, а уж о своих абстракциях для работы с предметной областью — и говорить нечего.
Вот только значительная часть абстракций в 1С вынесена за пределы самого языка, реализована в платформе.


Вот в этом пункте у нас нестыковка основная. Вы считаете что вынесена в платформу, я считаю что даже БСП довольно низкоуровневая штука, а уж о своих абстракциях для работы с предметной областью — и говорить нечего.


«Значительная часть в платформе» != «Все подряд в платформе».

Функционал того, что вы называете БСП, не такой уж и навороченный, что только за ради его следовало бы вводить дополнительные механизмы работы с абстракциями.

Ведь это не бесплатно. Платой будет усложнения языка программирования для решения более типичных задач.

Ну а те, кто разрабатывают типовые конфигурации — переживут. Основные деньги делаются не благодаря им.

А только потому, что 1С легко под себя подправить на месте — потому бизнес ставит себе 1С и уверен, что если что понадобится он легко и просто под себя подгонит. Этим занимаются программиста «на местах». Вот для этой основой массы программистов и не нужно усложнять работу.
Еще раз, не ради БСП, а ради того что мы строим над своими данными и логикой а так же бсп. Ну и какой нибудь пайтон не сильно сложнее 1с (если в дебри не лезть).
Ну и какой нибудь пайтон не сильно сложнее 1с (если в дебри не лезть).


Об этом и речь.
Сложнее всего осваиваются новичками базовые абстрации языков программирования.

А затем уже идут сравнительно легко усваиваемые различия. Исключений среди распространенных языков программирования, что основаны на совсем другой парадигме — немного.

Поэтому изучение другого языка для сложившегося программиста даже рядом не похоже на эту проблему для начинающего.
Вот не сказал бы. Можно ли назвать начинающими программистами людей которые по 5-7 лет на 1с пишут? А для них даже java или пайтон освоить гораздо сложнее чем программисту на C# например. Знаю немало примеров. Просто другие концепции часто применяются в современных промышленных языках которые к 1с неприменимы из за отсутствия ООП того же.
А вот писать на питоне в стиле 1с, но с добавлением типов в аргументы — мне кажется любой 1сник за пару дней осилит.
UFO just landed and posted this here
делает код круче

Да нет такого понятия в коммерческой разработке. Есть лишь критерии для оценки эффективности. ООП, особенно если добавить элементы ФП — позволяет писать код более эффективно, с меньшим количеством ошибок. Да, на 1с быстрее наваять поделие из за довольно широкой стандартной библиотеки — но развивать и поддерживать его — та еще боль. Это вам кажется что все дураки и выбирают инструменты рабочие по их крутости, да, такое тоже бывает когда выбирают чисто из личных предпочтений, но это исключение из правил. Инструменты выбирают исходя из их эффективности для решения задач.

З.Ы. А если отходить от коммерческой разработки — я бы тыкал c/c++, rust, haskell — но в коммерческую разработку я даже не думаю их тащить, потому что с коммерческой точки зрения на тех задачах которые я решаю они не эффективны. Эффективны языки вроде js (ух как я его ненавижу), dart (эффективность пониженная из за малой распространенности разработчиков и потому трудной заменяемости одного разработчика другим), c#, java, kotlin, python, даже php современный насколько слышал сейчас сделали более по человечески и подходящим для разработки крупных проектов.
UFO just landed and posted this here
Их код поддерживать проще на словах, а на деле на их платформе невозможно вообще ничего создать такого, что будет интересно бизнесу. Абсолютно ничего.

А вы насколько хорошо знаете lsFusion чтобы делать такие выводы? По своему опыту скажу что мы например ведем постоянную доработку (по 25 задач в день) / поддержку порядка 40 различных клиентов со 30к пользователей в сумме силами 7-8 разработчиков lsFusion. А я знаю компании у которых больше 1с разработчиков на одну компанию из этих 40. Ну и про одного 1с разработчика работает только в очень простых случаях.


Я же им официально писал с просьбой предоставить простейший модуль, на что получил

Честно говоря не в курсе что и кому вы писали. Но предоставить это что значит? Разработать? Ну вы же понимаете что это процесс требующий хотя бы контурное описание что надо разработать? Вы это предоставили? Если нет то причем тут платформа.

UFO just landed and posted this here

Там не работающее решение было, а уровня демки на сайте lsFusion. Фузиновцы как я понял сейчас делают клон одного из самых популярных решений на мировом рынке. На 1с его не один год делать, даже в текущей постановке.


В любом случае спорить с вами дело неблагодарное, у вас редкая каша в голове, вы путаете платформу и решения на ней. По вашей логики qualcomm и intel вообще пустышки и не должны существовать так как ничего конечным потребителям предложить не могут. И эту разницу судя по реакции на ваши комментарии тут понимают все кроме вас. Поэтому дальше отвечать вам это переливать из пустого в порожнее. Так что я тоже пас. Может у lair ещё терпения хватит с вами общаться.

Смысл приводить примеры личного опыта как оправдание?

Так это ж ровно то, что вы делаете.

UFO just landed and posted this here
Скажем так — 1 одинэсник запросто сопровождает все виды учёта предприятия, на котором учёт ну очень сложный

Любого предприятия, или одного конкретного предприятия?


Их код поддерживать проще на словах, а на деле на их платформе невозможно вообще ничего создать такого, что будет интересно бизнесу.

Вы про конкретного "убийцу 1С", или про все конкурирующие платформы?

UFO just landed and posted this here
Про всех убивцев 1С.

А, эти мне не интересны. Я даже не уверен, что я сходу назову больше одной претендующей на это системы.

UFO just landed and posted this here
Т.е. вы уверенно знаете, что плохо и не правильно

В определенных контекстах, да. Именно поэтому и уточняю каждый раз, о чем идет речь.


но при этом не знаете как правильно

Да нет, почему же. Я часто знаю, как лучше. Опять-таки в области своей специализации.


Тема то про очередного убивца 1С.

Нет, "тема" про то, чем 1С плох. Это не одно и то же.


Впрочем, последнее время она уже давно про то, как вы пытаетесь доказать, что 1С лучше всех (по крайней мере, так ваша позиция воспринимается).

— а почему никогда никому неудалось поймать Джо?
— потому что его никто никогда не ловил
А в командах какого размера вы работали и над какими задачами? Я вот одно время почти пару лет в разработке коробочных продуктов с нуля на 1с учавствовал, пусть даже команда небольшая была, 10 программистов 1с всего в максимуме. Ну еще аналитики, но они с кодом не работали. А потом еще 2 с копейками года эти коробочные продукты в командах на предприятиях внедряли. В т.ч. например одним из заказчиков был Магнит. И что такое поддержка, развитие, проектирование и рефакторинг проектов из сотен тысяч строк кода на 1с (думаю к миллиону ближе, точно не считали) — я представляю. Вы же, по моим ощущениям, скорее не роль программиста играете в рабочих процессах, а роль интегратора. И вам не важны те сложности с которыми сталкиваются разработчики продуктов.
UFO just landed and posted this here
Поймите, на 1С из готовых кубиков собираешь нужное тебе приложение


Я что-то пропустил? Все готовые решения это огромные медленные монолиты. А с нуля разрабатывать на ТАКОЙ платформе (со всеми вышеобозначенными проблемами) это самоубийство.
UFO just landed and posted this here
1С, это платформа, готовые решения, которые максимально подходят для большинства

Для большинства в какой выборке?

UFO just landed and posted this here
В Красноярске (это такой городок в России) из всех предприятий, где я был (а это штук 20), всегда либо стоит 1С, либо переходят на неё

Я правильно понимаю, что выборка, на основании которой вы говорите, что 1С подходит для "большинства" — это 20 предприятий в Красноярске?


Я даже не вижу смысла с этим спорить, вполне возможно, что решения 1С действительно подходят для большинства из этих 20 предприятий.

UFO just landed and posted this here
не приводя НИ ОДНОГО аргумента в свою пользу.

У меня нет мнения о том, какая платформа лучше всего подходит для предприятий в Красноярске, откуда у меня какие-то аргументы по этому поводу?


Интересно было бы послушать про весь цивилизованный мир

О, так это легко.


Открываем, значит, StackOverflow jobs и пытаемся там найти хотя бы одну вакансию по 1С.


Ну или если вам технический сайт не интересен, то откроем Gartner, ERP-рынок, и попробуем найти 1С в списке "Top 5 ERP Software Worldwide".


Я достаточно регулярно слышу про SMB ERP-рынок в Америке и западной Европе, и 1С там не упоминается. NetSuite — да. Sage — да. QuickBooks. Dynamics. Иногда — SAP. 1С — никогда.


PS


Почему же так?

… например, потому что далеко не каждому предприятию нужен разработчик по платформе, на которой у него написано ПО.

а по мск ХХ мне выкидывает:
«Программист 1С» — 850 шт
«Java developer» — 2500 шт
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Так в том-то и дело, что 1С, это не платформа, на которой разрабатывают решения с нуля.

Опровергаю своим примером. Или вы думаете конфигурации 1с из воздуха берутся?
UFO just landed and posted this here
UFO just landed and posted this here
А что это за тысяча событий?
UFO just landed and posted this here
Но в целом, если поступает хотелка от предприятия, то сначала ищется что-то готовое и допиливается

А это готовое откуда берется? Вот как раз есть люди что это «готовое» пишут и поддерживают. Типовые и отраслевые конфигурации всякие там, и прочее.
Сравнение сложных IT-систем (в частности, ERP) очень больная тема. Все описанные в статье проблемы имеют прямое отношение к стоимости доработки и сопровождения. Или Вы считаете, что все современные подходы к разработке направлены не на это, а просто на то, чтобы потешить эго разработчиков?
Имеют, конечно, в общем. Но если есть готовое решение для производства от 1С, и нет такого от lsfusion, например, — не имеют, в частности :))
Это статья не про lsFusion, а про 1С. Возможно будет еще и про то, как это сделано в lsFusion. И выше я писал, что если речь идет о производстве на 1С и другой технологии, то эта статья помогает понять, как минимум, что плохо в фундаменте той, что на 1С.
Так ведь нет ничего другого в РФ за такие деньги, вот в чём проблема. Я и пытаюсь объяснить, что не конкурируете вы с 1С никак на уровне платформы.
Как минимум, lsFusion — это альтернатива для разработки так называемых «нетиповых» решений. О чем, например, указано в статье.
Ну да, альтернатива. Только не для 1С. Вы сильно преувеличиваете значение нетиповой разработки с нуля на платформе 1С в настоящее время.
Вся суть статьи в том, что у платформы 1С много проблем. Давайте не будем скатываться в обсуждение рынка бизнес-приложений и типовых конфигураций. То, что в США на COBOL'е работает куча крупных компаний, автоматически не делает COBOL классной платформой для разработки приложений.
Да, у 1С много проблем. Но почему это так волнует lsfusion?
Даю подсказку. Открываем список статей в блоге компании lsfusion. Смотрим количество плюсов и комментариев в статьях с критикой 1С и SQL, сравниваем с количеством авторов публикаций в блоге. Потом смотрим количество комментариев и плюсов в статьях без критики 1С и SQL (последние штуки 3-4), тоже сравниваем с числом авторов статей в блоге. Делаем выводы.
«Возможности ничего не стоят, без проблем которые они решают.» © будем считать мой.
«Совпадение, не думаю».

Давайте так, это Хабр. Если с каким то пунктом вы не согласны, отлично, дайте развернутый комментарий, покажите что автор не прав (вы же понимаете что многие на Хабр ради комментариев заходят). И тогда все поймут что это просто «маркетинговый бред», «автор просто не разбирается» и все в таком духе.
Нет, я получил честные ответы ответы на все свои вопросы, дальнейшая дискуссия смысла не имеет.
UFO just landed and posted this here
В статье рассказывается система со стороны кодера и совсем никаким боком не затрагивается область бизнес-приложений. В том-то и проблема, что это трындец какие разные вещи. С одной стороны бизнесмену всё равно какой крутой или кривой код, ему то всё видится только в виде бизнес-объектов, тогда как с другой стороны, идёт измерение крутости кода


Все правильно пишите.

И если бы речь шла о сугубо технической вещи, которую рядовой пользователь не видит, с чем непосредственно не взаимодействует — выбор бы делали технические специалисты, ориентируясь на чисто технический аспект.

Но здесь это не так.

Авторы ссылаются на опыт глубоко подкапотачный вещей типа PostgreSQL vs Oracle.
Но там действуют другие правила.
В статье рассказывается система со стороны кодера и совсем никаким боком не затрагивается область бизнес-приложений.

Издеваетесь? Как раз основной посыл статьи, что вместо того, чтобы фокусироваться на бизнес-задачах разработчику 1С приходится заниматься всякой ерундой, вроде ручных блокировок, директив компиляции, callback'ов, ЗначениеВРеквизитФормы, связыванием списков и реквизитов и т.п.
в 1С больше инструментарий, а вы это преподносите как минус…
Да — в вашем мире и в вашей области автоматизации эти инструменты избыточны и ненужны… но ваше решение с 1С практически нигде не пересекается, по этому по сути вы еще не очень доросли до этих инструментов.

Ну не нужна вам асинхронность и управление серверными вызовами — да… вы просто не сталкивались с такими бизнес-задачами… а 1С сталкивался в полный рост…

это не делает 1С хуже — это делает 1С универсальнее и сложнее.

а с точки зрения разработчика — ну давайте реализовывать функционал фильтрации результатов поиска при вводе по строке по вхождению в наименование товарной позиции… у кого будет проще решение?

monosnap.com/file/ORhXPM24Lg4tmcFPob8Qs92cTY12XJ

сколько вы времени потратите и вообще сможете эту бизнес-задачу реализовать?
UFO just landed and posted this here
Как раз основной посыл статьи, что вместо того, чтобы фокусироваться на бизнес-задачах разработчику 1С приходится заниматься всякой ерундой, вроде ручных блокировок, директив компиляции, callback'ов, ЗначениеВРеквизитФормы, связыванием списков и реквизитов и т.п.

Совсем не так много этой работы как вам кажется.
Скажем, мне ручные блокировки понадобились прошлый раз, дай вспомню, года два назад. Да и директивы компилятора — пожалуй что уже как с полгода не писал.

И, у 1С все это было автоматом — 2/3 того, что вы перечислили — это сравнительно поздние нововведения. Раньше и без них было — да прям как у вас.

Однако, оказлось, что чем более разноплановых задач ставят перед 1С — тем более разнообразные инструменты полезнее.

Ваше восприятие таковым кажется, потому как вы не имеете достаточно опыта с той системой, что критикуете.

Это нормальное восприятие любой новой системы. Ваша система — тоже не исключением будет, ежели кто соберется на нее перейти — людей ждет такой же батхерт при входе в новую для себя технологию, что и у вас возник с 1С.
Раньше и без них было — да прям как у вас.

Нет не как у нас. Раньше все (а точнее большинство) на клиенте было и автоматически блокировалось кучу лишних данных. Что не масштабируемо. А в lsFusion все масштабируемо — все на сервере приложений, прозрачные материализации и update conflict'ы из коробки и т.п.
Однако, оказлось, что чем более разноплановых задач ставят перед 1С — тем более разнообразные инструменты полезнее.

Нет, у них возникли проблемы с масштабируемостью, а не разноплановые задачи.
Нет, у них возникли проблемы с масштабируемостью, а не разноплановые задачи.


Зачем делать функционал, пока в нем не возникло потребности?

Это одно и то же:

  1. Ранее использовалось с небольшими базами данных и для них и создавалось. К чему там лишние сложности для разработчиков, когда автоматика платформы справлялась.
  2. Возникала задача использовать с большими базами данных — она же проблема масштабирования.


Вы о чем вообще спорите?
О том, что есть 2 способа блокировок на выбор прикладного программиста (автоматический и ручной) и это плохо?

О том, что получилось два механизма. Один простой, но не работающий. Второй сложный но работающий. Почему не сделать один простой и работающий (то есть чтобы «автоматика платформы справлялась»).
Один простой, но не работающий

Кто вам сказал-то что он неработающий? Те, кто не умеют их готовить? Гы.

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

Кто вам сказал-то что он неработающий? Те, кто не умеют их готовить? Гы.

Речь шла не только про блокировки, а и про ОФ, про ОткрытьФормуМодально и т.п. Но даже касательно автоматических / ручных блокировок. Вы в курсе что в 1С автоматические блокировки ВСЮ таблицу в PostgreSQL блокируют, а в MS SQL на сложной логике и большом количестве пользователей у вас эскалации через раз будут, после чего база тоже в клинч начнет входить.
UFO just landed and posted this here
А у вас есть свои интеграторы/внедренцы?
Ну просто демо-продукт на сайте он совсем… Ущербный…
Что-то более похожее на реальную жизнь увидеть бы.
Вы про эту демку? (но там только часть функционала, можете кликнуть на модули посмотреть, что именно там сделано)

Это рыба, на которой впрочем работает большое количество предприятий >= 4к сотрудников, причем все модули от производства, до автозаказов (кроме бухгалтерии, HR и фронта).
логика объектов напоминает обычный ORM, правда, со своими особенностями:

Никаких one-to-many, many-to-many отображений нет, их функцию выполняют так называемые табличные части — коллекции внутренних объектов, фактически агрегированных в основной объект.

Подчиненный справочник с владельцем и есть классическое one-to-many
Ну это все равно не совсем классический one-to-many, потому как, как я понимаю, работает между двумя одинаковыми типами (справочник-справочник), скажем справочник с регистром или документом вы так не свяжете. Но да про них, я что-то забыл, точнее про подчиненные справочники у меня был отдельный пункт, но потом исчез, а в другие не дописал. Сейчас попробую немного изменить статью.

Почему один объект справочника, на который ссылаются 1000000 записей регистра остатков и 1000000 записей документа, который породил эти записи регистра, это не one-to-many?

Потому, что это many-to-one :))
Вы из справочника через точку можете написать что-то вроде: Товар.ДокументыПрихода[10].Дата?
А где так можно писать, и какой документ нужно считать 10-м?
Ну почти во всех ORM. Например в Java указываете OneToMany и @JoinColumn для List и у вас будет коллекция с документами. В данном случае будет рандомный документ, хотя вроде можно порядок указывать в таком маппинге. Но 10 это я для примера написал. Пусть будет «FOR Товар.ДокументыПрихода».
Так цикл по выборке и в 1С можно и список выведет без проблем. Если конечно товар это реквизит документа прихода (а не его табличной части), что я только один раз в реальной конфе видел

Ну маппинг у 1с не такой богатый, как у хибернейта. Смогу написать Товар.ДокументыПрихода[10].Документ.Дата

Запросы по старинке пишутся в строках (смотри примеры выше). Это создает как минимум две проблемы


Никто не пишет вручную запросы, 98% разработчиков используют СКД (которую вы не поняли и решили что оно не нужно) в том числе в качестве редактора запросов.
Вы таки не забывайте что даже среди обычных разработчиков довольно немного народа знают SQL больше чем select/insert/update/join а через СКД можно создавать очень мозголомные конструкции в текстовом представлении которых даже имея большой опыт в 1С без бутылки водки не разобраться (и то потом в дурку увезут)

Учитывая это вы просто переносите свой опыт из других систем на 1С в стиле «ой тут не как в pl/sql всё плохо»… ага… будет у нас программист 1С, программист pl/sql ещё dba и веб программер… а потом мы вспомним что пишем конфигу для заводика со штатом 100 человек.

на 1С можно наваять сложную систему учета, и она будет работать, за то время пока для обычных 'фреймворков и sql' будут только писать ТЗ и набирать народ с вилкой 180-250

И это при том что если взять SAP или какойнить AX, то оказывается что 1С не сильно и хуже, а в некотором смысле гораздо более дружелюбнее к разработчику
Я нигде не писал что вручную. Внимательно почитайте. Я писал что в строках.

И в том же УТ, там 95% запросов это и есть примитивные select join (причем с промежуточными результатами во времянках). И я написал почему. Хотите вот сейчас пять случайных мест открою и вставлю сюда запросы. Ну или вы тоже самое сделаете.

Учитывая это вы просто переносите свой опыт из других систем на 1С в стиле «ой тут не как в pl/sql всё плохо»… ага… будет у нас программист 1С, программист pl/sql ещё dba и веб программер… а потом мы вспомним что пишем конфигу для заводика со штатом 100 человек.

Так в этом наоборот и проблема. Что 1С должен и в вебе и в SQL и в ORM разбираться и в запросы руками предикаты проталкивать. И потом у относительно небольших компаний штат 1С программистов — 15 человек. А у нас есть отдел из 10 человек, который дорабатывает нон-стоп и поддерживает 40 клиентов (в основном крупных), в которых в сумме 60к человек работает.
И потом у относительно небольших компаний штат 1С программистов — 15 человек

проклятие 1С в том что основные их клиенты это малый-средний бизнес, и им не надо штат в 15 человек

Я работал в одной средней конторе (500чел штат, офисы по всей стране) где 1С была ядром всего фин.блока и частью бекофиса основной (финансовой, это фин-контора) ИТ системы… у нас было два человека 1С-ника… и был отдел который поддерживал эту ИТ систему… как раз 15 человек java-программеров которые по 2-3 недели пилили задачи которые мы в 1С рисовали за 1-2 дня… и в итоге часть некритичного функционала начали сгружать в 1С из-за того что это быстрее, дешевле и эффективнее получалось
500 человек штат и целых 2 1С программиста? У нас я говорил выше есть ИТ отдел на 10 человек, который дорабатывает custom made решения для 40 клиентов с 60к человек штатом в сумме (у многих по 3-5 достаточно непростых задач в день закрывается).

Я просто не до конца понимаю, что именно быстрее там так сильно получалось. Особенно с учетом, когда запросы надо вот так писать.
Запрос
ВЫБРАТЬ
    РасходнаяНакладнаяСостав.Номенклатура,
    УчетНоменклатурыОстатки.КоличествоОстаток
ИЗ
    Документ.РасходнаяНакладная.Состав КАК РасходнаяНакладнаяСостав
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.УчетНоменклатуры.Остатки(,
                             Номенклатура В (
                                   ВЫБРАТЬ Номенклатура
                                   ИЗ Документ.РасходнаяНакладная.Состав
                                   ГДЕ Ссылка = &Документ)) КАК УчетНоменклатурыОстатки
        ПО УчетНоменклатурыОстатки.Номенклатура = РасходнаяНакладнаяСостав.Номенклатура
ГДЕ
    РасходнаяНакладнаяСостав.Ссылка = &Документ И
    (УчетНоменклатурыОстатки.КоличествоОстаток < РасходнаяНакладнаяСостав.Количество ИЛИ
        УчетНоменклатурыОстатки.КоличествоОстаток ЕСТЬ NULL)


Если тому же lsFusion разработчику сказать так писать, он на тебя как на идиота посмотрит. Типа делать мне больше нечего.

То есть с точки зрения декларативности современный 1С от той же Java не сильно отличается, о чем я собственно и писал в статье.
Ну, современная Java все же получше чем 6-7. А уж если задействовать другие JVM языки вроде котлина, груви, кложи, скалы и прочих — можно вообще чудеса декларативности показывать.
Угу, сравнили — ваш отдел не поддерживает бухгалтерию, зарплату и производство, и при этом все клиенты из одной отрасли.
Из вот этого списка:

Human Resource.
Inventory.
Sales & Marketing.
Purchase.
Finance & Accounting.
Customer Relationship Management(CRM)
Engineering/ Production.
Supply Chain Management (SCM)

Поддерживается все кроме Accounting (у многих Finance мы тоже закрываем) и HR. Хотя да производство там простое (общепитовское). Есть клиенты из разных отраслей, в том числе даже BPM (некоторые очень публичные, которых по этой причине пока не можем называть). Хотя да, не спорю, есть перекос в FMCG розницу, где 1С не вытягивает по производительности и эргономике (также как и в банках) Но это временно.
есть ИТ отдел на 10 человек, который дорабатывает custom made решения для 40 клиентов

ну вы интегратор-франч, вам конечно проще делать типовые простые вещи в потоке и драть деньнги как какбудто вы с нуля каждый раз пишите

в моем примере этим занимается внутренний отдел разработки без привлечения оутсорса (вообще я не люблю оутсорс, который высасывает килотонны денег со слабым выхлопом и многомесячными препирательствами в согласовании ТЗ...)… а до этого нам 1С внедрял интегратор со штатом в десяток 1Сников, да… меня тогда взяли чтобы 'понять чё вообще происходит, каждый месяц по 3 ляма платится, результатов почти нет' — в итоге все свелось к 2м человекам в штате и повышением результативности разработки в сотни раз.

тут уже разговор превращается борьбу менеджерскими скиллами по поводу отъема денег у контрагентов прикрываясь правильными словами.
ну вы интегратор-франч, вам конечно проще делать типовые простые вещи в потоке и драть деньнги как какбудто вы с нуля каждый раз пишите

Вы думаете что на нашем рынке 1С нет? Но мы за счет эффективности все равно существенно дешевле чем свои ИТ-отделы и другие решения на 1С. И там далеко не простые типовые вещи (почитайте хотя бы задачи какие там решаются, а в FMCG рознице с ассортиментом в 100к взаимозаменяемых товаров требования к эргономике и производительности огромные)
а до этого нам 1С внедрял интегратор со штатом в десяток 1Сников, да… меня тогда взяли чтобы 'понять чё вообще происходит, каждый месяц по 3 ляма платится, результатов почти нет' — в итоге все свелось к 2м человекам в штате и повышением результативности разработки в сотни раз.

Где вы таких клиентов берете? 2 человека в штате, это с налогами и остальными затратами уже под полляма рублей. И это для компании со штатом 500 человек. Щедрый там финдир.
Щедрый там финдир.

Затраты на франча были в разы больше
Также контора полуайтишная, и ИТ отдел в целом это самая большая статья затрат в принципе. и 'два человека в штате на 1С' — это цветочки по сравнению 15 java-программеров, четверо плюсовиков и два отдела эксплуатации с обычными админами… одинесники по сравнению с основным отделом разработки это бедные родственники… (я в итоге и сбежал оттуда к явистам… геморроя на 50% меньше, а зарплата на 100% больше, отпад)
==
и вообще, эта контора дочка огромной международной корпорации с забугорными акционерами, не испорченная 'российскими финдирами'
геморроя на 50% меньше

А вы точно за 1с? А то как бы тут все в основном и утверждают что уж сильно много геморроя при работе с 1с.
немного не так,
за ту зарплату сколько платят при работе с 1С — слишком много геморроя причем не борьбы с платформой, а просто много задач и обязанностей вообще, которые подразумеваются под программистом 1С.

тоесть, я сейчас гораздо меньше всего делаю на питоне и эти вещи проще (занесло меня в эту сферу после явы), а получаю гораздо больше чем когда я работал с 1С
И это дело не в квалификации, со мной работал сеньор 1Сник (которого переманили из интегратора) имеющий огромный опыт в ERP, УПП и кучу одинесовских «специалистов»… и он получал меньше меня сейчас.
Это при том что мой коммерческий опыт программинга в 'обычных языках' у меня всего 5 лет. (я до этого был админом, а одинесил с 2005 года)
p.s. это всё в мерках Московских зарплат миддл-сеньорского уровня обоих сфер
Так может потому что
огромный опыт в ERP, УПП и кучу одинесовских «специалистов»

нигде толком не применим кроме 1с? Тогда как например C# разработчик спокойно переквалифицируется на Java или C++ при необходимости и ему не нужно будет в подробностях изучать кучу готовых «конфигураций» чисто прикладных. Да и знание прикладной области гораздо менее важно чем для 1сника. А для 1С сперва стоят знания конфигураций и предметной области, а только потом знания собственно приемов и практик программирования, работы ОС, сетей и прочего.
я не спорю. в итоге я и переквалифицировался на java/python
Какие задачи на питоне решаете что гемора меньше? А то может тоже из 1С свалить ) Питон и JS я знаю и смотрю по сторонам с прищуром ))
UFO just landed and posted this here
так это же хорошо, когда можешь решить реальную задачу бизнеса, понимая его проблемы и методику, а не тупо кодить по готовому ТЗ, в котором за тебя подумали как делать и ты не можешь шагнуть в сторону
А за тарелку супа или за масло с икрой — щас выбора много где от 150-180 предлагают на руки.
Просто если хочется за границу укатить, тогда 1С мешает
Специализация это вещь. Невозможно хорошо разбираться и в программировании и в бизнесе как предметной области. Что то будет отставать. Кому то нравится ковыряться в законодательстве, бух учете и прочей скукоте — пожалуйста. Но это не мое (хотя даже когда я работал в 1с франче этим не программисты а аналитики занимались). Мне же интереснее развиваться как программисту.
UFO just landed and posted this here
Поэтому в 1С специально сделали примитивный язык, чтоб для решения задач не требовались годы опыта в Java или C# и можно было аналитику программировать (хотя сейчас уже вряд ли на 8.3, это в 7.7 простота была)
С ростом сложности проектов в 1С сейчас тоже больше специализации, внедрения одним человеком остались в прошлом или только в маленьких городах на обновлении/допиливании бухгалтерии и УТ.
Сейчас например только на внедрении одного модуля из «Управления Холдингом» может быть команда из человек 5-10 и задачи нифига не скучные ) И хайлоад и многопоточность и веб-сервисы и RabbitMQ встречается
А язык по прежнему в одном месте. И почти хайлоадом занимался на 1с, и на веб/http сервисах собаку съел, и с шиной сообщений работал (правда какой то древней от ibm). Язык перестал соответствовать решаемым задачам. Вы верно подметили что даже на среднего размера проектах (от 1кк до 5кк) программист уже не играет в одно рыло и аналитика и программиста и админа. Тем не менее ему по прежнему приходится страдать.
Поэтому в 1С специально сделали примитивный язык, чтоб для решения задач не требовались годы опыта в Java или C#


Вы как-то преувеличивайте значение знания конкретного языка программирования.

Какие годы? Сам язык учится легко и просто.

Сложно учатся концепии, принципы, паттерны и алгоритмы. Библиотеки? Ну какое-то время уходит. Но небольшое, все равно их никто целиком не помнит, все справочниками пользуются.

Доводилось принимать программистов на работу (разговаривал с ними на техническом собеседовании). Неоднорактно убеждатся: можно брать и с чужим стеком, если толковый. Если специалист толковый, то он впоследствие довольно быстро осваивает новый для себя стек. И полноценно эффективно начинает работать через 1-2 месяцаа.
UFO just landed and posted this here
Так наоборот. Вместо того чтобы решать бизнес-задачи, разработчику приходится думать над директивами компиляции, оптимизацией запросов, где и когда проверять ограничения, связывать списки с реквизитами, строить механизмы инкрементальных обновлений и т.д и т.п. Даже C# разработчику не все из этих вещей надо делать.
Запросы прям любые фигачить можно, неужто? Надо конечно же делать те же проверки и заполнения. Только на более низком уровне — реализуя разные громоздкие ООП-паттерны и зависимости между таблицами, классами, ORM знать надо. То что парой кликов в 1С делается надо самому придумать и заложить в архитектуре.
В 1С ты оперируешь сразу бизнес-данными, списки сразу готовые получаешь, директивы компиляции — это вообще не затратно, автоматически ставятся в 95% случаев, механизм обновления платформа уже имеет.
В итоге миниимально работающий продукт (MVP) под бизнес-задачу можно выкатить на 1С через неделю, накидав мышкой, а потом развивать и оптимизировать хоть под холдинг.
А на Java/C# что? Они дают максимум какой-то фреймворк и ООП-паттерны для разработки с нуля, это даже не скелет, а указания «Как правильно рисовать скелет и куда прилеплять мясо».
Сеньор по Java просто умеет технически правильно лепить скелеты и навешивать на него спущенные ему аналитиком требования.
Сеньор по 1С умеет по хотелкам клиента построить целое приложение, правильное как на техническом уровне, так и на уровне бизнес-логики (настройки, отчеты, гибкие формы)
Сеньор по Java просто умеет технически правильно лепить скелеты и навешивать на него спущенные ему аналитиком требования.

Просто, ага.

Ну с точки зрения бизнеса он узкий специалист который «всего лишь» хорошо знает «движок» системы. Но без аналитика и консультанта он ничего не может реализовать.
А 1Сник выслушает бизнес-задачу заказчика на его языке и уже понимает какие объекты будут затронуты для решения, как оптимизировать на будущее, предложит варианты как удобно интегрировать решение со смежными подсистемами например и т.д.
Это как хороший водитель-механик по ремонту BMW, который переберет машину шефа и помощник руководителя, который его понимает с полуслова и решает/делегирует любые вопросы, в том числе и с машиной
А 1Сник выслушает бизнес-задачу заказчика на его языке и уже понимает какие объекты будут затронуты для решения, как оптимизировать на будущее, предложит варианты как удобно интегрировать решение со смежными подсистемами например и т.д.

… то есть 1С-ник — это одновременно хороший бизнес-аналитик и хороший специалист по интеграции? И, наверное, еще и хороший специалист по тестированию?

Конечно, особенно если он на предприятии в штате и не стажер-кодер. CI и автоматическое тестирование по BDD уже вовсю пришло в 1С.
Если в интеграторе, то там обычно проекты большие и есть выделение методологов или функциональных архитекторов, которые пишут ТЗ и ФТ, но не до уровня классов и таблиц, а в терминах предметной области.
Технический архитектор может рулить на уровне концепций и подсистем, но обычный разработчик все равно понимает свой участок методологически
Конечно, особенно если он на предприятии в штате и не стажер-кодер.

Тут немедленно возникает два вопроса.


  1. Как так получается, что 1С-ник умудряется совмещать в себе как минимум три квалификации, которые обычно принадлежат разным людям?


  2. Почему вы думаете, что разработчики на других платформах не могут так же?


Получается, потому что 1С более высокоуровневая система, программист оперирует сразу объектами бизнеса, а не абстрактными ООП-концепциями, интерфейсами, синглтонами, отражением СУБД через ORM и пр.
Т.е. когда ты пообщался с заказчиком и накидал на бумажке нужные сущности и реквизиты, структуру отчетиков набросал — ты уже подготовил драфт бизнес-системы, который можно за день перенести в конфигуратор и прописать второстепенные детали. И вся дальнейшая разработка это интерфейсные рюшечки, отчеты, интеграции.
Надо добавить новый документ с 50 реквизитами — 20 минут и он в интерфейсе со всеми экранными формами, сиди прописывай чистую бизнес-логику, думай над UI/UX, а не над созданием классов, генераторов/конструкторов, get/set, дата-адаптетов, фабрик и т.д.
Интересно посмотреть бы на человека, который и с бизнесом общается и в javaЕЕ шарит и крутой фронт может написать на реакте например.
На западе такое не приветствуется точно, там рулит узкая специализация, нанимают по человеку на 1 функцию и пишут годами системы за миллионы евро.
А в итоге получается что команда из 10 джавистов делает за год меньше чем 3 одинесника и европейцы выпадают в шок когда показываешь им 1С.
Получается, потому что 1С более высокоуровневая система, программист оперирует сразу объектами бизнеса, а не абстрактными ООП-концепциями, интерфейсами, синглтонами, отражением СУБД через ORM и пр.

Тут, понимаете ли, есть (как минимум) две загвоздки.


Во-первых, хороший бизнес-аналитик и хороший специалист по тестированию — это уже две профессии, которые в одной голове плохо помещаются (и конфликтуют). Не важно, какая там разработка — для разработки места давно не осталось.


Т.е. когда ты пообщался с заказчиком и накидал на бумажке нужные сущности и реквизиты, структуру отчетиков набросал — ты уже подготовил драфт бизнес-системы, который можно за день перенести в конфигуратор и прописать второстепенные детали.

А во-вторых, я не зря написал "хороший специалист по интеграции". Понимаете, интеграция — это такое дело, где объектами бизнеса оперировать можно очень недолго. А потом начинается… pull-модель, push-модель, REST, SOAP, вебсокеты, комет, OAuth, OAuth 2, OIDC, OIDC identity provider, пропьетарная авторизация просто потому что мы так можем, очереди сообщений, вебхуки, подписание — и все, погребен.


Надо добавить новый документ с 50 реквизитами — 20 минут и он в интерфейсе со всеми экранными формами, сиди прописывай чистую бизнес-логику, думай над UI/UX, а не над созданием классов, генераторов/конструкторов, get/set, дата-адаптетов, фабрик и т.д.

У меня создается ощущение, что вы считаете, что не-1С-программисты каждый раз пишут системы с нуля. Это может показаться удивительным, но нет, это не так. Есть платформы быстрой разработки бизнес-приложений, есть платформы разработки учетных систем, и люди, работающие в этой отрасли, ими пользуются.


А в итоге получается что команда из 10 джавистов делает за год меньше чем 3 одинесника

Я долго думал, вестись ли на это, но не удержался. Лет десять, кажется, назад, я работал над одной учетной системой, использовавшейся в одном федеральном ведомстве. И в какой-то момент понадобилось ведомству, чтобы его подотчетные организации рапортовали ему некую информацию не вручную, а выгрузкой из своих систем; а поскольку почти у всех подотчетных был 1С, было решено доработать 1С, чтобы он интегрировался с федеральной системой. Если я ничего не путаю, там даже было больше одного подрядчика со стороны 1С, которые решили делать конкурирующие решения (ну, почему бы и нет, в конце концов). Так вот, эта интеграция затянулась на месяцы просто потому, что регулярно выяснялось, что на стороне 1С случилась какая-нибудь еще ошибка в реализации нашего (стандартного!) протокола взаимодействия, и надо править с нашей стороны, потому что с их стороны — нельзя или слишком сложно, а сроки поджимают.

Во-первых, хороший бизнес-аналитик и хороший специалист по тестированию — это уже две профессии, которые в одной голове плохо помещаются (и конфликтуют).

Помнится слоган 1С — "доступно и всерьез". Следствием этого является то, что разработка с использованием 1С считается недорогой, а следствием этого — вынужденное совмещение ролей. В результате имеем в одном лице посредственного бизнес-аналитика, разработчика и тестировщика (ха-ха). Есть, безусловно, исключения — но это именно исключения, а не правило.
Хотя ради справедливости в последнее время стало больше попыток внедрения нормальных подходов к разработке (а не фигак-фигак и в продакшн), а соответственно появляется и разделение ролей. Что делает результат более качественным — но, в то же время, и более дорогим.


регулярно выяснялось, что на стороне 1С случилась какая-нибудь еще ошибка в реализации нашего (стандартного!) протокола взаимодействия, и надо править с нашей стороны, потому что с их стороны — нельзя или слишком сложно, а сроки поджимают.

SOAP? :) По крайней мере именно с ним наблюдал такую ситуацию.

Хотя ради справедливости в последнее время стало больше попыток внедрения нормальных подходов к разработке (а не фигак-фигак и в продакшн), а соответственно появляется и разделение ролей.

Ну а где разделение ролей, там и аргументация выше теряет всякий смысл.


SOAP?

Он. Насколько я помню, на тот момент для работы с SOAP в 1С приходилось чуть ли не руками разбирать и собирать XML, со всеми вытекающими.

Ну а где разделение ролей, там и аргументация выше теряет всякий смысл.

В том-то и дело, что это только на более-менее серьезных проектах. А там где мелкие, или берется готовая коробка и немного допиливается — пока (по крайней мере по моим наблюдениям) наиболее распространен подход "фигак-фигак и в продакшн".
Причем бизнес такому подходу радуется — решение получается быстро. Да, потом проблемы наверняка вылезут — но то будет потом.


на тот момент для работы с SOAP в 1С приходилось чуть ли не руками разбирать и собирать XML, со всеми вытекающими.

Если это была 8-ка, то нет, там оно всё легко и просто — платформа сама всё делает. Только вот стандарт они прочитали как-то по-своему, в итоге 1С <=> 1С работает отлично, а вот попытка работы с чем-то другим — это поход по граблям. Может быть и разбирали/собирали чтобы превратить XML в что-то понятное парсеру платформы.

А там где мелкие, или берется готовая коробка и немного допиливается

… а в этом случае не будет действовать обещанное "1Сник выслушает бизнес-задачу заказчика на его языке и уже понимает какие объекты будут затронуты для решения, как оптимизировать на будущее, предложит варианты как удобно интегрировать решение со смежными подсистемами например и т.д."


Если это была 8-ка

Честное слово, не помню. Давно было.

… а в этом случае не будет действовать обещанное "1Сник выслушает бизнес-задачу заказчика на его языке и уже понимает какие объекты будут затронуты для решения, как оптимизировать на будущее, предложит варианты как удобно интегрировать решение со смежными подсистемами например и т.д."

Почему же не будет? Аналитика-то отдельного нет, а задачу выполнить надо.
Так что как раз будет, т.к. нужно задачу клиента сопоставить с уже существующими объектами, подумать какие из них чуть доработать или нужно добавить новые ("какие объекты"), что клиент может захотеть дальше и как построить логику/структуру доработки чтобы это не было проблемой. Возможно предложить немного изменить задачу — чтобы меньше менять типовые объекты и таким образом уменьшить объем дальнейших работ при установке обновлений типовой конфигурации ("как оптимизировать на будущее").


Кстати, ещё видел такой вариант — задачи аналитика пытаются переложить на заказчика. Заканчивается это, правда, обычно плохо — заказчик просто ищет другого 1Сника. Хотя бывают и исключения.

Почему же не будет? Аналитика-то отдельного нет, а задачу выполнить надо.

Потому что квалификации не хватит (если верить вашему же "в результате имеем в одном лице посредственного бизнес-аналитика, разработчика и тестировщика").

Потому что квалификации не хватит

Знаю я одного 1Сника. Как раз по мелким доработкам в основном занимался обычно. Сам себе и аналитик, и программист, и "тестировщик" — всё сам.
Заказчики были очень довольны — всё быстро, всё как просят. Ну подумаешь, от малейшего шага в сторону всё ломалось — он опять исправлял, и все счастливы. Кроме других разработчиков, которым приходилось что-то править в его коде.

Был случай кстати когда приходилось тоже руками xml собирать для внешней системы, 1с не поддерживает soap заголовки.
У меня на прошлой работе даже на небольших проектах, до 1млн стоимостью обязательно был аналитик (часто им на совсем уж крошечных проектах дело и заканчивалось). Про более крупные и не говорю, там обычно команда из аналитиков и программистов. Вот с тестировщиками беда была, да, их только на коробки выделяли, поскольку критические баги в релизе какие то там рейтинги франча в списках 1с снижали.
объектами бизнеса

&НаСервереБезКонтекста, РеквизитФормыВЗначение, ОбработкаОповещения, условия в ВиртуальнойТаблице, МенеджерВременныхТаблиц, ВременноеХранилище вот прям бизнес-объекты.

Вы статью вообще читали? Она как раз о том, что в последних версиях 1С разработчику приходится не бизнес-задачами, а какой-то ерундой заниматься.

Или вы про Справочник, Документ? Прямо мега абстракции, аж пару предопределенных полей и нумератор. Или вы про регистр — представление SQL в самом примитивном случае?
ну я не отрицаю и даже приветствую что 8.3 усложняется и возможностей все больше, тонкостей оптимизации. Потому и проекты на 1С делаются все крупнее — холдинги, госкорпорации, распределенные сетевые организации.
Главное что все эти технические объекты вписаны в структуру бизнес-объектов и можно лепить как быстро на коленке мышкой, так и супероптимально профессионально под тысячи одновременных пользователей.
Условия и Менеджер это обычный SQL, куда без них?
Внеконтекстные вызовы тоже нужная вещь.
Увы на Java почему то не придумали подобный фреймворк чтоб и UI и ORM и бизнес-модели было удобно реализовывать. Почему то все отдельно и надо уметь либо что то одно, либо скрещивать все это со спрингом
Еще раз смысл статьи в том, что добавляя все эти тонкости, они убирают автоматические возможности. И крупные проекты состоят из множества мелких, где все равно больше нужна быстрота и простота разработки, а не тонкие настройки.
Условия и Менеджер это обычный SQL, куда без них? Внеконтекстные вызовы тоже нужная вещь.

Нет, без них можно было обойтись. И в тех же САП и Axapta таких абстракций гораздо меньше. А в lsFusion вообще нет (то есть например пиши условие в ГДЕ или где хочешь, оптимизатор сам разберется).
Полагаться на автоматические возможности это дилетантский подход. Зачем тогда делают зеркалки за 200к для проф. фотографов, снимали бы на телефон и всё.
1С потому и внедрила все эти тонкости, потому что на больших проектах ничего на автомате не внедришь.
Если у вас система не дает рулить вр.таблицами и выполнением на клиенте/сервере, мне вас жаль, у вас продукт уровня 1С 7.7 времен 1995 года.
Там можно было прикрутить dll прямого доступа к sql и работало намного быстрее чем 1С 8, большие магазины легко автоматизировались, но «почему-то» 7.7 безнадежно устарела, на одной скорости далеко не уедешь в современном мире.
Ссылаться на САП и Аксапту глупо, первая внедряется для галочки годами и за миллиарды за счет откатов, выглядит как говно и требует серверов от 10000 евро, вторая имеет долю рынка на уровне плинтуса. Они подходят для запада где разработаны, где стабильность и порядок в законах, другой менталитет и зарплаты.
1С родилась в РФ и лучше всего подходит для наших реалий, попытки это оспорить, имея на руках сомнительный софт для автоматизации в самой примитивной сфере (торговля) — выставление себя на посмешище
Полагаться на автоматические возможности это дилетантский подход.

… а все ваши "набросал в конструкторе" — это не автоматические возможности?


Зачем тогда делают зеркалки за 200к для проф. фотографов

… с автофокусом, например. На него полагаться — тоже дилетантский подход? Да и автомат экспозиции тоже, в общем-то, вполне используется профессионалами.

… а все ваши «набросал в конструкторе» — это не автоматические возможности?
ну видите, 1С не убирает базовые автоматические возможности, не противоречьте себе же.
с автофокусом, например. На него полагаться — тоже дилетантский подход?
А про ручной фокус в курсе? Иногда автофокус только мешает, так же и с ручными блокировками и ручным клиент-серверным управлением: надо в 5% случаев, но как раз когда это влияет на оптимизацию и требуется для масштабируемости.
Зачем в Hibernate можно на чистом SQL делать запросы? Подумайте над этим.
ну видите, 1С не убирает базовые автоматические возможности, не противоречьте себе же.

А я себе и не противоречу. Я вроде нигде не говорил, что 1С что-то убирает.


А про ручной фокус в курсе?

В курсе и никогда не пользуюсь.


надо в 5% случаев, но как раз когда это влияет на оптимизацию и требуется для масштабируемости.

А в остальных 95% вы полагаетесь на ту самую автоматику, которую вы называете дилетантским подходом.

1С потому и внедрила все эти тонкости, потому что на больших проектах ничего на автомате не внедришь.

Вообще вопрос был в том, что на средних проектах (до 1к одновременных пользователей) еще как внедришь. А с подходом 1С страдают все (когда нужно разбираться с тонкостями, которые не нужны)
у вас продукт уровня 1С 7.7 времен 1995 года.

Много у вас было на 1С 7.7 баз с 1к одновременных пользователей, террабайтных баз и вот таким функционалом?
1С родилась в РФ и лучше всего подходит для наших реалий, попытки это оспорить, имея на руках сомнительный софт для автоматизации в самой примитивной сфере (торговля) — выставление себя на посмешище

Пока вы себя выставляете на посмешище, не понимая очевидных вещей.
террабайтных баз и вот таким функционалом?


Объемы данных при наличие индексов значения не имеют — это забота СУБД. Там что 50 гигабайт, что пара терабайт уже неважно. Большая часть данных с этого терабайта — «холодные» данные, к которым редко обращаются.

Но да, я с вами согласен, какого-нибудь нетехнического специалиста ваши доводы могут убедить.

и вот таким функционалом?

90% того, что вы указали — есть в типовой.
Остальное допиливается под конкретного заказчика.

с 1к одновременных пользователей

Это единственный довод по сути.
90% того, что вы указали — есть в типовой.
Остальное допиливается под конкретного заказчика.

Вы же понимаете, что даже если это так (то есть 90% есть, хотя это не так). То 10% на таких сложных проектах (с учетом описанных в статье проблем) — это почти бесконечность. И никакого смысла это делать у заказчика нет, лучше взять специализированное решение.
То 10% на таких сложных проектах (с учетом описанных в статье проблем) — это почти бесконечность. И никакого смысла это делать у заказчика нет, лучше взять специализированное решение.


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

Во первых. И снова вы безаппеляционны категоричны. Это же от задач зависит.
Во вторых — если вы разрешили в это разговоре брать специализированое решение, то на этом месте ваша система начинает катастрофически сливать системе 1С, для которой есть куча специализированных решений.
Или вы про регистр — представление SQL в самом примитивном случае?


Вы про автоматический предварительный подсчет итогов по периодам — говорите «голый SQL»?

Или вы про Справочник, Документ? Прямо мега абстракции, аж пару предопределенных полей и нумератор.


Вы «забыли» про привязанные к данным формы
Про автоматическую очистку регистров при отмене проведения.
И др. мелочи, но реально экономящие время.

Вы про автоматический предварительный подсчет итогов по периодам — говорите «голый SQL»?

Про это тоже было в статье. В OLAP это преподсчет из коробки и ГОРАЗДО эффективнее, а в OLTP особо и не нужен.
Вы «забыли» про привязанные к данным формы

Привязка к данным формы есть практически везде. Без этих крышесносящих классах в скобочках и РеквизитыФормыВЗначение. Более того в том же lsFusion этого разделения вообще нет, и форма сразу данные базы (ну или временные данные) отображает.
Про автоматическую очистку регистров при отмене проведения.

Вы же в курсе, что в типовых так не делают? И знаете почему?
В OLAP это преподсчет из коробки и ГОРАЗДО эффективнее, а в OLTP особо и не нужен.


В OLAP можно в корне по другому подходить.
Но OLTP каждый раз нагружать сервер расчетами, когда вам понадобятся остатки???

Серьезно?

Нет, в кассовых модулях супермаркетов подсчет остатков даже и не всегда нужен, тут да. Человек взял товар с полки, принес к кассе — его нужно продать независимо от того есть он на остатках или нет, главное, чтобы цена была и штрихкод.

Но есть еще и бэкофис розницы и опт и пр. вещи, где 1С применяется — там остатки актуальные нужны каждую минуту в сколько-нибудь нагруженной среде.

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

Я про остатки по периодам. Текущий остаток это обычное материализованное представление (в Oracle и MSSQL одной строкой делается). А на дату просто отсчитываете назад. Вот цитата из статьи:
Справедливости ради, ограничение, что параметром момента времени должна быть константа, 1С умеет достаточно эффективно использовать, если в регистре материализованы итоги для промежуточных дат. В этом случае 1С в подзапросе виртуальной таблицы может бежать по записям регистра, начиная не от текущей даты, а от ближайшей даты, для которой материализованы итоги. С другой стороны, учитывая что в оперативной базе (OLTP) древность данных обычно обратно пропорциональна вероятности их использования, а на поддержание промежуточных итогов нужны дополнительные ресурсы (в частности место на диске), практическая польза от такой оптимизации весьма сомнительна (если, конечно, оперативную базу одновременно активно не используют как аналитическую, но об этом позже).
Текущий остаток это обычное материализованное представление (в Oracle и MSSQL одной строкой делается)


Что там с производительносью и акуальностью (ведь нельзя продать то, чего нет, актуальность должна быть сиюминутной) при постоянно появляющихся новых данных в OLTP?
В случае:
CREATE MATERIALIZED VIEW balance
SELECT SUM(x) FROM ledger GROUP BY a,b,c;
?
Все хорошо. Есть грабли, что только в конце транзакции обновляется, но это детали (в 1С по факту в таком же стиле используется)
ну… про 1Снка который в одном лице сразу и качественный методист и знает типовую и кодит как бог — было более менее справедливо много лет назад… когда типовые были простыми и их было немного…

по современным продуктам если глобально подходить к методикам — все же чаще появляются отдельные специалисты-консультанты… равно как и все больше и больше кодеров появляется которые владеют методиками разработки на 1С но в бизнес-процессы не лезут… оно им не интересно и не нужно…
вы рассуждаете на уровне «чтобы ходить человеку приходится думать какую ногу сначала ставить — левую или правую»

да не задумывается разработчик… он просто знает как надо и делает как надо… а там где спорные моменты может этими директивами сделать более оптимально — например не отправлять лишний контекстный запрос на сервер тогда когда он там не нужен…
UFO just landed and posted this here
Просто если хочется за границу укатить, тогда 1С мешает


1) Ваше высказывание в контексте рекламируемой lsFusion — выглядит странно. Хотя, если за границу — это в Белоруссию, то, конечно.

2) Почему мешает-то? Программисткие навыки куда денутся? Автор этих строк легко и свободно начал использовать Go после многих лет с 1С. Если вы хотите уехать за границу, то вам больше мешает незнание языка человеческого.

Го кстати тот еще язык. Гугл тоже попытался принцип «чем проще тем лучше» реализовать, в итоге вышла фигня, и вот уже планируют дженерики добавлять)) А вы его только для себя используете, или на коммерческом проекте в составе команды нескольких го программистов? Я конечно ваш бекграунд не знаю, но мне например чтобы свалить с 1с (не просто что то для себя написать или несколько сотен строк в рамках 1сного проекта, а писать код в команде других, фуллтайм, за деньги) потребовалась пара лет изучения разных концепций, и я пока еще даже на мидл разработчика не претендую, хотя во франче не самом мелком, пусть региональном, старшим программистом был.
А вы его только для себя используете, или на коммерческом проекте в составе команды нескольких го программистов?


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

Я конечно ваш бекграунд не знаю

30 лет и 15 языков программирования.
Уверяю вас — трудно выучить только первый.
Непросто — второй.
Дальше уже элементарно. Ведь распространенные языки программирования — они же все похожи друг на друга. Ну это если не брать Хаскель какой нибудь, однако это экзотика.

но мне например чтобы свалить с 1с потребовалась пара лет изучения разных концепций, и я пока еще даже на мидл разработчика не претендую, хотя во франче не самом мелком, пусть региональном, старшим программистом был.


Ну а в Гугле вы были бы вообще джуном, независимо от языка программирования.

Ерунда вся эта классификация. Объективно можно сравнивать только в пределах одного предприятия.

Но на разных предприятиях — уже не корректно. Не существует единого стандарта даже в пределах одной области.

Плюс названия должностей часто используют чтобы манипулировать:

  • Назовем должность солиднее. Поддержим ЧСВ. Но денег не добавим.
  • Или напротив — у нас жесткая тарифная сетка. Поэтому если тебя назвать senior, то платит придется больше. Не вариант. Сиди миддлом до скончания века.


Все это не добавляет объективности всем этим названиям.
30 лет и 15 языков программирования.
Уверяю вас — трудно выучить только первый.
Непросто — второй.

Ну тогда понятно, даже спорить не буду. Но если речь идет о человеке у которого 1с первый и единственный — ему так просто соскочить не получится.
Насчет того насколько просто языки учатся — в целом согласен (хотя библиотеки, фреймворки, системы сборки, SDK и прочее уже не так просто изучаются как сам язык), но вот какой нибудь хаскель я не возьмусь утверждать что легко освою, несмотря на хорошие знания 1с и котлин, неплохие джавы и поверхностные python.

По второй части комментария тоже соглашусь, я скорее по своей внутренней классификации определяю.
Но если речь идет о человеке у которого 1с первый и единственный — ему так просто соскочить не получится.


Сейчас же в школе, вроде, уже учат что-то?
В любом случае — это проблема того человека. Мне его вот нисколько не жаль. Мы сами определяем свою жизнь. Я знаю точно, что после первого языка — тебе гораздо легче. Все остальное это оправдание лени.

но вот какой нибудь хаскель я не возьмусь утверждать что легко освою, несмотря на хорошие знания 1с и котлин, неплохие джавы и поверхностные python.


Ну дык Хаскель я и не считаю.
А 98% распространенных языков — это потомки Алгола-68 или его ближайших родственников.
причем тут программистские навыки, в вакансиях видели когда нибудь требования типа «3 года коммерческой разработки на Java»?
Язык программирования давно роли не играет, нужны знания фреймворков, их подводных камней, ORM, библиотек тестирования, паттернов проектирования и реализации.
В 1С они совсем другие чем в низкоуровневых платформах где все с нуля пишется на голом ООП. И надо учиться заново, пару лет погружаться в такой подход
причем тут программистские навыки, в вакансиях видели когда нибудь требования типа «3 года коммерческой разработки на Java»?

Эээ… да, а что?

3 года коммерческой разработки на %LangName%

Обычно с этого 99% вакансий начинается. Плюс обычно перечисляется набор желательных применявшихся принципов, подходов, технологий и библиотек. Часто именно в таком порядке. Про переквалификацию из стека в стек тоже постоянно слышу. Это только приходя из 1с нужно кучу всего с нуля изучать.
Обычно с этого 99% вакансий начинается.

Это мечты работодателей там описаны.
Они вообще хотели бы чтобы за копейки и супер-специалист. Реальность немного инача. Она отрезвляет и работодателей.

Это только приходя из 1с нужно кучу всего с нуля изучать.


Да и из веба в смартфонные приложения или из веба в 1С или… — да при любой смене направления.

И что вас удивляет? Разумеется, что-то вам доизучить придется. Я про то, что если вы именно программист, а не обновляльщик 1С, то изучение концепций — это часть вашей профессии.

Решите сменить направление — какое то время придется поизучать, да.

Еще раз о своем опыте:

Программируя много лет 1С — довольно свободно (за 1-2 дня) перешел на новый язык Go. Где-то за пару недель мои познания в нем уже сравнились с типовыми джунскими, что имеет 1 летний джун на Go. Ну а за пару месяцев — ко мне уже не подкопаешься в знаниях нового стека, где на уровне 4-х летнего миддла. При том, что всё это время я уже мог активно программировать на новом стеке (все оценки времени даны с высоты сегодняшнего 7 летнего опыта на Go и 30 летнего опыта в программировании вообще, 18 из них 1С).

Сложность перехода преувеличена.
Да и из веба в смартфонные приложения

Вот ни разу. Очень много общего. Архитектуры приложений вообще постоянно друг у друга воруют. Разве что фронт на бек чуть сложнее сменить, и то общего все равно больше чем переходя с 1с. Ну и мы повторяем наш спор, вы судите со своей колокольни, имея опыт на нескольких языках, я же вспоминаю своих бывших коллег, действительно хороших 1сников (пара экспертов среди них была) — все они живут в совершенно другом мире где важно знание предметной области, а практики и приемы программирования постольку поскольку, за пределы процедурного программирования они не выходили ни разу в жизни. (А освоить новую парадигму заметно сложнее чем просто новый язык выучить и писать на нем в старом стиле).
действительно хороших 1сников (пара экспертов среди них была) — все они живут в совершенно другом мире где важно знание предметной области


Я вас уверяю — они будут невероятно сильны в программировании сайтов для бизнеса, где нужна бизнес-логика внутри. Например, логистика онлайн-продаж у них очень хорошо пойдет.

А то, что писать ее придется не на 1С, а на PHP/Go/Python — уже не важно.

а практики и приемы программирования постольку поскольку, за пределы процедурного программирования они не выходили ни разу в жизни


Еще раз:

Это важно только новичкам.
Мы же говорим о сложившихся специалистов в области программирования.

Где-то при 7 лет опыта (это крепкий миддл) — вам вообще никакие концепции не страшны, кроме Хаскеля.

(А освоить новую парадигму заметно сложнее чем просто новый язык выучить и писать на нем в старом стиле).


Вы преувеличивайте непохожесть парадигм в большинстве распространенных языков программирования.
Я знаю бывших коллег, они очень хорошие, сложившиеся 1сники, проекты выполняют с бюджетами в миллионы и десятки миллионов, но никто из них не читал ни Роберта Мартина, ни Макконела, ни Фаулера, ни банду четырех, ни (подставьте любого другого автора не из мира 1с) никто не интересуется практиками написания хорошего кода (распространение их шло за счет нескольких энтузиастов). Почти никто не слышал об О нотации. Даже протокол http для многих темный лес. О тестах даже думают единицы, не пишет практически никто. Методологиями разработки тоже особо не интересуются. Вообще кругозор за пределами 1с как по технологиям так и по практикам нулевой, все вбухано в знание платформы и прикладных конфигураций, больше ни на что у них времени не остается.

З.Ы. Не без исключений конечно, но на 90% именно так все и обстоит. А ведь это франч входящий в относительно небольшое число «центров разработки».
но никто из них не читал ни Роберта Мартина, ни Макконела, ни Фаулера, ни банду четырех, ни (подставьте любого другого автора не из мира 1с) никто не интересуется практиками написания хорошего кода (распространение их шло за счет нескольких энтузиастов). Почти никто не слышал об О нотации. Даже протокол http для многих темный лес.


Я вас уверяю — подавляющее большинство программистов ничего этого и не делала и пишет не по практикам хорошего кода. Не зависимо от языка программирования.

Впрочем, можно не читать Фаулера и быть успешным. О-нотация хоть и полезна, но не обязательна, если своя голова на плечах есть. http-протокол просто — и 1С и не 1С разберется с ним за день.

Ох что то сомневаюсь я в ваших словах. Если не брать мелкие студии где день за днем одно и то же делают — картина я думаю все же другая.
Ох что то сомневаюсь я в ваших словах. Если не брать мелкие студии где день за днем одно и то же делают — картина я думаю все же другая.


Люди — всегда люди.
Единицы — круты, да.

Но основная масса… Не идеализируйте их.

И в других профессиях — ровно так же: нас окружают плохие врачи (попасть к действительно хорошему врачу — это удача), посредственные журналисты, водители которые постоянно создают аварийные сутиации.

Но это не значит, что наш мир не может существовать и с плохими специалистами — мир же существует уже много лет.

Конечно нужно стремиться стать выскоклассным профи. Но и обычные люди, совсем не высококлассные спецы — тоже не совсем уж голодают. И таких большинство.

А при смене специализации (даже при смене предприятия в пределах специализации) на какое то время ваша производительность труда, разумеется, падает. Пока вы адаптируйтесь.

Если что я как раз сейчас в процессе смены специализации, после 4 лет 1с. И 1с был первым серьезным языком для меня, как и для коллег с моей прошлой работы. По меркам 1сников я был весьма посредственным спецом, пусть и с широким кругозором в остальном ИТ. По меркам разработки на java/котлин (под андроид, но не суть важно) я тяну максимум на junior+ несмотря на уже почти год работы с этим стеком. Причем по большому счету потому что приходится ломать себя и встраивать в свою работу те принципы которые в 1с не применяются либо по историческим причинам, либо по причине технической невозможности. IoC, DI контейнеры, clean architecture, solid, паттерны — я до сих пор в этих и подобных темах плаваю как топор. Тесты вон до сих пор писать еще не начал, нужно будет Бека перечитать еще разок…
Если что я как раз сейчас в процессе смены специализации, после 4 лет 1с. И 1с был первым серьезным языком для меня, как и для коллег с моей прошлой работы. По меркам 1сников я был весьма посредственным спецом, пусть и с широким кругозором в остальном ИТ. По меркам разработки на java/котлин (под андроид, но не суть важно) я тяну максимум на junior+ несмотря на уже почти год работы с этим стеком. Причем по большому счету потому что приходится ломать себя и встраивать в свою работу те принципы которые в 1с не применяются либо по историческим причинам, либо по причине технической невозможности. IoC, DI контейнеры, clean architecture, solid, паттерны — я до сих пор в этих и подобных темах плаваю как топор. Тесты вон до сих пор писать еще не начал, нужно будет Бека перечитать еще разок…


Люди — разные.
Вот тот же путь из 1С в Java:

Мой опыт работы в Фирме 1С

Не жалуется на сложность перехода. Не так у него все непросто как у вас.
С тем что люди разные я согласен. Но во первых я говорил про медианного 1сника не знакомого больше ни с чем (а таких наверно даже больше чем половина), во вторых мы не знаем бекграунда автора, чем он до 1с занимался.
Ну и меня как бы тоже как и автора взяли после 1с писать на java/kotlin, автор нигде не говорит что ему это далось сложно, но так же нигде и не говорит что это ему далось просто.

Да и то что получаю я как мидл в своем регионе по новой специализации, как и то что я смогу устроиться мидлом куда то еще вообще ничего не значит. Это тупо девальвация лычек. Мидлами уже считают всех кто хоть как то может самостоятельно решать задачи.

Я вижу какие у меня гигантские пробелы в знаниях. Я вижу как мне далеко до топовых разработчиков. То что куча народа с теми же пробелами живет и работает — не делает такую ситуацию нормальной.

К чему я это? Если бы я переходил из C#, например, или из крестов — у меня было бы намного больше релевантного опыта, я бы гораздо раньше начал изучать технологии разные и программирование, вместо всяких учетов и бухгалтерии и этих пробелов было бы гораздо меньше. Аналогично меньше было бы потрачено бесценного времени.
Если бы я переходил из C#, например, или из крестов — у меня было бы намного больше релевантного опыта, я бы гораздо раньше начал изучать технологии разные и программирование, вместо всяких учетов и бухгалтерии и этих пробелов было бы гораздо меньше. Аналогично меньше было бы потрачено бесценного времени.


Еще раз не согласен: «релевантные» технологии и не сложны и не критичны. Их мало кто знает, не будьте с собой столько строги.

А понимание потребностей конечных клиентов (а 1С-ец куда как ближе к конечному клиенту) — этого вы из книжек не узнаете. Тот опыт тоже полезен.
Для конечных задач клиентов есть бизнес аналитики и дизайнеры. Не говоря уж о случаях когда конечные клиенты другие программисты. Ну и нет, не так уж и просты.
Впрочем немного поправлюсь, я ситуацию оцениваю с точки зрения регионов в основном. Что там в столицах — знаю только по слухам. Может там для каждого 1сника как нефиг делать стек сменить не теряя грейда и опыта.
UPD. Я конечно в оплате при переходе не потерял, но это тупо из за везения произошло, у компании особых вариантов не было, да и бюджеты заметно больше чем у 1сных франчей.
А понимание потребностей конечных клиентов (а 1С-ец куда как ближе к конечному клиенту) — этого вы из книжек не узнаете. Тот опыт тоже полезен.

… пока вы не выясните, что, внезапно, у выделенного аналитика это понимание лучше, чем у вас, и вы ему мешаете.

А понимание потребностей конечных клиентов (а 1С-ец куда как ближе к конечному клиенту) — этого вы из книжек не узнаете. Тот опыт тоже полезен.


… пока вы не выясните, что, внезапно, у выделенного аналитика это понимание лучше, чем у вас, и вы ему мешаете.


Если у вас не было опыта непосредственной работы с клиентами — то да.

Впрочем, если был — то тоже вполне возможно, что да.

Язык программирования давно роли не играет, нужны знания фреймворков, их подводных камней, ORM, библиотек тестирования, паттернов проектирования и реализации.


Кому нужны?
Джуну? Да, потому что ему больше и показать себя нечем.

Мне доводилось принимать решения после технического собеседования, которые вам покажутся странными:

И брал умных ребят на совсем другой стек, совсем другой язык. И знаете — ни разу не прогадал, новый стек осваивали действительно быстро, как я это и предполагал.

Это пишется в 10 кликов мышью и "есть null" можно мышой перетянуть или руками набрать. Минут пять работы, если структуру базы данных знаешь. Видео записать? )


И я бы еще вместо вложенного запроса породил временную таблицу с именем типа ТоварыДокумента, чтобы лет через 5 проще править было — запрос стал бы еще больше.


Расскажите как быстро пишется запрос по трем таблицам в вашей системе. И как выглядит. Я вот не зная откуда вы это скопировали догадываюсь, что этот запрос выбирает строки расходной накладной, для которых не хватает остатков.

Я скопировал из методических рекомендаций самой 1С.

Как это делается в lsFusion — тут. Вообще никаких запросов писать не надо.

Суммируем все строки приходной накладной и вычитаем все строки расходной накладной? Я все правильно понимаю? При появлении еще 5 новых типов документов начинаем суммировать строки в них и вычитать/складывать? Или за GROUP SUM что-то более интересное, чем select sum()?


receivedQuantity 'Суммарный приход' = GROUP SUM quantity(ReceiptDetail d) BY item(d), stock(receipt(d));
shippedQuantity 'Суммарный расход' = GROUP SUM quantity(ShipmentDetail d) BY item(d), stock(shipment(d));
currentBalance 'Текущий остаток' (Item i, Stock s) = receivedQuantity (i, s) (-) shippedQuantity (i, s);


В 1с в модуле регистра при записи подобное поведение тоже можно реализовать. Выглядеть будет примерно так.


Если Не ОбщийМодульПроверка.ПроверитьПоложительностьКоличества(ЭтотОбъект) Тогда 
   Отказ = Истина;
КонецЕсли;
Только в lsFusion это весь код. А вот ПроверитьПоложительностьКоличества покажете? Ну и заодно куда вы приведенный вами код будете помещать. Вообще было бы очень интересно посмотреть аналог примера из моей ссылки на 1С (но только весь код, а не додумайте сами)
При появлении еще 5 новых типов документов начинаем суммировать строки в них и вычитать/складывать?

Обычно при появлении 5 новых типов документов наследование и полиморфизм используются. То есть новые типы документов наследуют просто ReceiptDetail, и если надо перегружают реализацию / реализуют quantity. Больше ничего не меняется. Все декларативно и само автоматически работает.

Помещать в процедуру ПередЗаписью в модуле набора записей регистра.


Вы же не показываете код парсера вашего языка. Может быть чтобы превратить GROUP SUM в SELECT у вас миллион строчек ушло? Я с таким же успехом могу написать внешнюю компоненту и поместить метод ПроверитьПоложительностьКоличества туда.


Документ инвентаризация склада, который и приход и расход может от кого наследовать будете?

Помещать в процедуру ПередЗаписью в модуле набора записей регистра.


Я не 1С программист и у меня нету 1С головного мозга. Мне все эти ваши «ПередЗаписью в модуле набора регистра» ни о чем не говорят.

Вы же не показываете код парсера вашего языка. Может быть чтобы превратить GROUP SUM в SELECT у вас миллион строчек ушло? Я с таким же успехом могу написать внешнюю компоненту и поместить метод ПроверитьПоложительностьКоличества туда.


Какая разница сколько строчек кода ушло на это? Мы сравниваем платформы. Можете писать внешние компоненты и складывать туда что угодно. Возможно 1С вам выпишет еще одну премию за новую и бессмысленную абстракцию.

Документ инвентаризация склада, который и приход и расход может от кого наследовать будете?

Делается интерфейс SkuLedger, и инвентаризация делает агрегированные объекты от классов, которые от него наследуются.

Не уходите от темы. Есть конкретная задача — давайте весь код, как ее реализовать. А то 1Совцы любят просто потрепаться, что вот я это сделаю супер быстро, а когда доходит до дела — сливаются.
Процедура ПриЗаписи(Отказ, Замещение)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   ОстаткиТоваровОстатки.Товар КАК Товар,
        |   ОстаткиТоваровОстатки.КоличествоОстаток КАК КоличествоОстаток
        |ИЗ
        |   РегистрНакопления.ОстаткиТоваров.Остатки(
        |           ,
        |           Товар В (&Товары)
        |               И Склад В (&Склады)) КАК ОстаткиТоваровОстатки
        |ГДЕ
        |   ОстаткиТоваровОстатки.КоличествоОстаток < 0";

    Запрос.УстановитьПараметр("Склады", ЭтотОбъект.ВыгрузитьКолонку("Склад"));
    Запрос.УстановитьПараметр("Товары", ЭтотОбъект.ВыгрузитьКолонку("Товар"));

    Если Не Запрос.Выполнить().Пустой() Тогда
        Отказ = Истина;
    КонецЕсли;
КонецПроцедуры

Будет работать при любой записи в регистр остатков. Строчек больше, но их без последнего если сгенерировал конструктор запроса.

Помещать в процедуру ПередЗаписью в модуле набора записей регистра.

Ну так они так и делают, и что из этого получается (3 запроса на огромное количество строк) я написал в статье.
Может быть чтобы превратить GROUP SUM в SELECT у вас миллион строчек ушло?

Так это не ваши проблемы. Это проблемы платформы. Вы как разработчик этот код не пишете.
Документ инвентаризация склада, который и приход и расход может от кого наследовать будете?

От обоих. В lsFusion множественное наследование есть.
Ну так они так и делают, и что из этого получается (3 запроса на огромное количество строк) я написал в статье.

https://habr.com/ru/company/lsfusion/blog/468415/?reply_to=20700475#comment_20700763 один запрос по регистру остатков вместо двух по всем строкам расходных и приходных. 20 строк, из которых половина текст запроса сгенерированный конструктором, супротив 5 строк скрытых запросов сгенерированных ORM.


Вы сравниваете удобный пример, с системой которая вынуждена реализовывать плохо структурированные требования налогового кодекса. Когда вы сможете сделать расчет НДФЛ, с учетом ликвидаторов, летчиков, владельцев одного, двух и более детей, материальной помощи студенту до 4000 рублей, тогда можно будет оценивать сложность и поддерживаемость.


От обоих. В lsFusion множественное наследование есть.

Два склада в одном документе? Как это отобразится в таблицу?

UFO just landed and posted this here
> Никто не пишет вручную запросы
Я пишу.

> через СКД можно создавать очень мозголомные конструкции
По моему глубокому убеждению, если вам требуется для решения учетных задач создавать «мозголомные конструкции», у вас что-то не так спроектировано, или инструмент имеет серьезные проблемы.
Я пишу.

я же не сказал что «все», конечно есть исключения

если вам требуется для решения учетных задач создавать «мозголомные конструкции», у вас что-то не так спроектировано, или инструмент имеет серьезные проблемы.


иногда чтобы выцепить десяток цифр раз в месяц, проще сделать пятиэтажный запрос, чем городить десяток регистров и индексов ради сокращения этого запроса до одного селекта.

Сейчас работаю с человеком с такой точкой зрения, такие решения часто имеют под собой контекст в виде неограниченного бюджета на сроки разработки и на оборудование… никак не могу такое поддержать (эффективный менеджер у меня в голове плачет)
А зачем для запросов, которые я приводил в статье СКД? Вот реально, там же один JOIN максимум.
А зачем вручную писать запросы? Я понимаю, что в разговорах это звучит офигительно и прям «Тру», но смысл писать запрос руками, если есть удобный конструктор, ускоряющий и упрощающий жизнь? на написание маленького запроса с 2-3 Временными таблицами руками можно пол жизни убить + искать ошибку в опечатке «Субкотно»…
ИМХО это какой-то особый сорт мазохизма, все же…

Вы может еще Ctrl+C/Ctrl+V не пользуетесь?
И я пишу. Но не всегда прямо только руками, иногда сделаю заготовку конструктором и правлю руками, а иногда и наоборот. Как быстрее. Зачем писать руками:
1. Конструктор не позволяет писать комментарии, и убивает уже написанные — одного этого достаточно, что бы не пользоваться им редактирования уже написанных запросов.
2. Для меня текст запроса гораздо более нагляден, чем бесконечное число закладок в закладочке в конструкторе. Так проще изучать запрос, и сразу вносить комментарии. Еще было бы проще с нормальной синтаксической подсветкой по запросу :(
3. Скажу тайну — в других средах разработки нет конструктора, а есть подсказка по именам таблиц. Поэтому там не может быть ошибки в «Субконто...». И, оказывается, что написать запрос с клавиатуры часто проще и быстрее, чем щелкать мышкой по закладкам и прокручивать списки с именами таблиц и полей. Так что еще вопрос, где особый сорт мазохизма…
4. Конструктор может не все.
Я не против, пишите, но все ваши 4 пункта просто придирки:
1) Ну не позволяет, это вообще не проблема, для начала — необходимо писать понятные запросы, к которым максимум можно оставить комментарий до текста запроса — комментарии в тексте запроса 1С имхо — моветон.
2) Это вкусовщина и привычка, есть подозрение, что вы не особо владеете конструктором, либо очень сильно привыкли к ручному текстингу.
3) Спасибо за тайну, но речь идет про 1С, в других средах пускай хоть «кофа с чаем» будет, ну и написать запрос в 1С часто проще и быстрее сделать в конструкторе, если это не запрос выбора из одной таблицы + форматирование запроса будет корректным и читаемым и на него вы не потратите кучу времени.
4) Конструктор может не всё — никто не может всё, а конструктор — облегчает жизнь разработчика.

Поймите, я не против, чтоб вы или кто-то другой писал запросы без конструктора, это ваше дело и ваша жизнь, но нельзя отвергать прогресс. Конструктор не совершенен, но он облегчает разработку и экономит время программиста 1С, как и другие фишки типа Ctrl+Space, F12, Alt+Shift+F. Это все просто экономит жизнь и нервы.
А уж если брать другие языки, так в Java — можно программировать и в обычном блокноте, и есть такие люди, но тот же Notepad++ удобнее и практичнее…
Конструктор помогает как раз только с простыми запросами. Как только нужно что то поправить в сложном запросе где нужно на экране видеть сразу все данные по нескольким таблицам — конструктор ничем помочь не может, он даже по одной таблице не может всю инфу отобразить.
Как только нужно что то поправить в сложном запросе где нужно на экране видеть сразу все данные по нескольким таблицам


В сложном запросе, без конструктора, у вас все данные не влезут на экран.
Вы устанете руками дописывать и разбирать запрос с 10-15 временными таблицами, кучей соединений, вычислений, переименований, куда вам надо добавить выборку из не типовых регистров и обособленной выборкой данных (при крупной выборке это больше 500 строк запроса, клесиком листать устанешь).

он даже по одной таблице не может всю инфу отобразить


Как это не может? Что вы под этим понимаете?

Я, очень давно, считал, что СКД — отстой, Универсальный отчет на 8.2 — это божественно, а обычный интерфейс по сравнению с управляемым — божественен, но это только потому, что я не умел правильно работать с данными механизмами, сейчас же, при возвращении в обычный интерфейс и платформы 8.2 и старше — я ужасаюсь как сложно работать без удобных и современных механизмов.
8.2 я и сам терпеть не могу. А под полным отображением инфы об одной таблице я собственно и понимаю отображение на экране одновременно информации о составе выбираемых полей, источниках таблицы, группировках, условиях и отборах и прочему. Чтобы это в конструкторе увидеть — приходится как зайцу по вкладкам прыгать. При этом часто желательно видеть как данные по текущей таблице, так и данные по прошлой.
Так придирка в основном в малом?
Бог с ним, я не буду переубеждать и ругаться. Если вас это устраивает и вы не теряете на этом свое время и нервы, то пожалуйста :)

Индивидуально все, я вообще работаю на темно-синем фоне редактирования кода, коллеги кривятся, а мне красота)
Меня в общем то и это не сильно устраивало (отсутствие автокомплита и компайл тайм проверок), потому ни с 8.2 ни с 8.3 больше не работаю.
UFO just landed and posted this here
Ну, я обычно конструктором редактировал простые запросы до 5 пакетов, запросы на десятки пакетов мне уже удобней было править руками. Именно править правда. Набрасывать скелет все же конструктором удобнее было из за отсутствия автокомплита.
>комментарии в тексте запроса 1С имхо — моветон
??? Комментировать код — моветон ???!!!
Комментарии В ТЕКСТЕ ЗАПРОСА, типа такого:
Запрос = Новый Запрос(
"|ВЫБРАТЬ
|* //Комментарий о моей офигенской дописке
|ИЗ
|Справочник.ВариантыОтчетов КАК ВариантыОтчетов");

Это моветон.
Либо до, либо после текста запроса необходимо ставить комментарий, патамушта если запрос будет большой или разработчик слепой, то твой коммент не увидят, а при правке запроса консолью твой коммент канет в лету
Код SQL ничем принципиально не отличается от обычно программного кода, и точно так же, там есть необходимость писать комментарии. 1С приучила пользоваться конструктором, и не писать комментарии в запросах, потому что это не позволяет конструктор. Но это не значит, что это правильно. Это, на самом деле, проблема.
Посмотрите код ERP. Там уже есть комментарии в запросах, некоторые из них мне с экономили часы разборок с кодом. Вот, копирую пример из типовой ERP:
|ВЫБРАТЬ // Оплата поставщикам через подотчетное лицо (Дт 60.01 :: Кт 71)
Вообще, я не говорю — что конструктор плохо. Или что писать руками — плохо. Надо уметь все и применять то, что эффективнее. Руками писать — это однозначно гибче. Но конструктором бывает быстрее. Но не всегда.
Простой пример. В запросе есть выборка во временную таблицу. Потом она обрабатывается еще в десятке запросов. Вдруг выясняется, что данные надо в этой выборке взять из другой таблицы, с другими названиями полей. Остальное не меняется. Если в конструкторе начать менять выборку в эту таблицу, конструктор безнадежно портит всю обработку, что следует далее.
В тексте это делается элементарно — просто исправляешь название таблицы и имена полей.

Причем здесь прогресс — не понимаю. Есть язык запросов (диалект SQL). Что бы на нем писать, надо его знать и понимать. Знать и понимать — это значит уметь читать его текст, и уметь писать на нем. Это главное. Все остальное — это всего лишь вспомогательные инструменты.
Конструктор безнадёжно устарел, это факт. Но уж в EDT то всё-всё будет :))
Я не нахожу этот конструктор удобным. Куча вкладок, кнопок, галочек, часто с невразумительными, интуитивно непонятными подписями. Как там у Радченко, главного 1с-писателя в одном из описаний создания отчета: у вас получился не тот результат, это потому что на пред-предыдущем шаге вы забыли на вкладке… поставить третью сверху галочку на дополнительной панели… — что-то вроде этого.
И мелкий шрифт, который нельзя (!!!) изменить.
Нет, спасибо. Конфигуратором (даже не скд) я обычно пользуюсь в последний момент, когда надо уже написанный и отлаженный фрагмент кода скопипастить в модуль и сохранить. А до того предпочитаю пользоваться текстовым редактором, отлаживаюсь через веб-сервис с помощью своей утилиты. Конфигуратор по мне — слишком тормозной и неудобный инструмент.
UFO just landed and posted this here
UFO just landed and posted this here
98% разработчиков используют СКД

Результатом работы которого является тот же запрос в виде строки, и который запросто накроется в рантайме если переименовать реквизит/справочник ибо проверку корректности всех запросов после изменения структуры конфигурации в 1с возложили на разработчика.
Да и иногда запросы формируются динамически, от условий каких то, через конкатенацию строк.

UPD. Я под конец моей работы с 1с (на 3-4 год) конструктором запросов конечно пользовался, но внутри него открывал текстовое редактирование, ибо так удобнее. И да, при чем тут СКД, когда мы про запросы в коде говорим, а не в отчетах?
на 1С можно наваять сложную систему учета, и она будет работать, за то время пока для обычных 'фреймворков и sql' будут только писать ТЗ и набирать народ с вилкой 180-250

В 8.3? Я собственно статью и написал, что наваять на ней систему, которая будет нормально работать на >10к записей, не сильно проще чем на том же .Net. А если с lsFusion сравнить, где ни одной из верхних 21 проблем нет (а это еще далеко не все проблемы), то это разница будет как между лошадью и автомобилем. Причем lsFusion под LGPL лицензией, то есть открытыми исходниками, бесплатно и т.п.
Не любят в наше время честно вести бизнес. Вместо того, чтоб делать свой продукт качественным и конкурентоспособным (оно может так и есть на самом деле), начинают черный маркетинг на крупных ресурсах.
Сравнение лошади и автомобиля в комментарии выглядит как популистическая байка.
1С — известные крупняки, у которых огромный выбор решений, бекграунда, комьюнити, специалистов, франчей и тд. У них хотя бы разъемы подходят к местному бизнесу
IsFusion — платформа, которая только пытается выйти на рынок, предлагая подобный 1С функционал.

Я бы хотел почитать аналогичную этой статью о 21 минусе IsFusion.
Я бы хотел почитать аналогичную этой статью о 21 минусе IsFusion.

Так разберитесь в lsFusion и напишите. Мы даже ее заплюсуем, насколько сможем. Мы никогда не были против открытого обсуждения любых проблем.
UFO just landed and posted this here
Вот надоели уже люди с такими комментами. Ну так ответьте по пунктам, если считаете, что автор где-то не разобрался.
управление серверными вызовами — полный провал…
UFO just landed and posted this here
1С — известные крупняки, у которых огромный выбор решений, бекграунда, комьюнити, специалистов, франчей и тд. У них хотя бы разъемы подходят к местному бизнесу

Когда Форд сделал автомобиль, тоже было много стойл, сена, конюхов, известные крупняки и т.п. И по вашему он проблемы лошадей не должен был упоминать?
А вообще я уже писал:
«Возможности ничего не стоят, без проблем которые они решают.»
Когда Форд сделал автомобиль, тоже было много стойл, сена, конюхов, известные крупняки и т.п. И по вашему он проблемы лошадей не должен был упоминать?


Дык Форд то выиграл по итогу как мы знаем.
А вы еще нет.
И не факт что выиграете.
Как не выиграли еще 5 подобных же перспективных «убийц 1С» в этом веке.

Вам пишут, что у 1С есть неоспаримые преимущества помимо технологического совершенства (хотя и в этом плане 1С на весьма хорошем уровне).

А вы в ответ — «зато мы более технически совершенны» (что кстати не очевидно из ваших статей).

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

Об этом ваш оппонент вам и пишет.
Как не выиграли еще 5 подобных же перспективных «убийц 1С» в этом веке.

Таких убийц еще не было.
хотя и в этом плане 1С на весьма хорошем уровне

И статья это очень хорошо показывает.
незначительным техническим преимуществом

Ничего себе незначительным. Тут все проблемы максимально фундаментальны.
Как не выиграли еще 5 подобных же перспективных «убийц 1С» в этом веке.

Таких убийц еще не было.


То есть вы не изучили опыт предшественников?

Вы же говорите о ком-то конкретном? Можете озвучить их («убийц»)? Мне действительно интересно.
CUBA Platform :)) Но они вовремя поняли, что пиариться на 1С — не очень хорошая идея.
Это очередной классический ORM с огромным порогом вхождения (ничем не отличающийся от остальных 100). Все равно, что трактор с автомобилем сравнивать.
Уважаемый, вы не поняли мой ответ. Я не сравнивал ваши с Кубой технические достоинства, а сравнивал желание попиарится за счёт более известного конкурента.
UFO just landed and posted this here
Причем lsFusion под LGPL лицензией, то есть открытыми исходниками, бесплатно и т.п.


Это имеет значение только для небольшой части потенциальных клиентов вашей системы.
Вы не забывайте, что ваш продукт вовсе не OpenOffce для дома — а это продукт для бизнеса.

Стоимость платформы 1С — это копейки.
По сравнению со стоимостью работ по ее обслуживанию и доработе.

Ну а ковырять ваши исходники и улучшать ваш продукт, будет вообще мизер. Это нормально.
Известно же, что большинство людей, даже активно ратующих за Open Source и принипиально будущих сидеть на неудобном свободном открытом ПО вместо удобного пропритетарного — на деле всего лишь потребители. Вносящих вклад в Open Source — крайне незначительное число.
Ну а уж бизнесу, который и принимает окончательное решение — это вообще предпоследний аргумент.

Согласен, в каких то случаях это будет приципиально. Например, когда есть свой большой штат квалифицированных разработчиков, те могут и поковырять исходники вашего продукта. Но что то мне подсказывает, что если такие люди есть — то они уже свое и написали.

Если вы посмотрите на то, как это происходит в мире — как продукты автоматизации бизнеса все больше платные. Бесплатных мало.

Доминируют только те бесплатные — что базовые кирпичики типа nginx, OpenOffice. Как что сложное и очень ответственное — а система автоматизации это сердце бизнеса — так бизнес уже не ведется на халяву и предпочитает платить разработчикам.

Безусловно исключения есть. Но их скорее мало, чем много.
Стоимость платформы 1С — это копейки.
По сравнению со стоимостью работ по ее обслуживанию и доработе.

Вы уж определитесь как-то. То дорабатывать ничего не надо. То это основная стоимость.
Стоимость платформы 1С — это копейки.
По сравнению со стоимостью работ по ее обслуживанию и доработе.


Вы уж определитесь как-то. То дорабатывать ничего не надо. То это основная стоимость.


Одно другому не противоречит:

Если делать с нуля, а не брать за основу 1С — то стоимость работы программиста вообще устремляется в небеса. Не так это будет только для мелких задач.

Речь-то о том, что когда речь идет об серьезной адаптации под хотелки заказчика, то стоимость самой 1С это копейки в общих затратах из-за того, что работы это всегда дорого, это не дешевое тиражируемое решение.

Да, в ряде случаев — когда достаточно типовых решений — это не так. Работы по доработке мало, стоимость самой 1С сравнительно велика относительно работ. Но тут ваш вариант с open source не может реализовать приимущество своей бесплатности, так как спектра типовых решений у вас нет.

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

Так в этом и смысл. И в этом случае качество платформы выходит на первый план. Чем оно выше, тем стоимость доработки ниже.

Плюс в таких случаях выгоднее взять решение попроще и его доделать, чем сложнее и его переделывать. То есть проще построить новый дом из крупных панелей, чем перестраивать старый.
И в этом случае качество платформы выходит на первый план. Чем оно выше, тем стоимость доработки ниже.


Это если платформа предлагает более высокую производительность программиста.

Вы же принципиально отказываетесь от методик, ускоряющих разработу, таких как элементы визульного программирования.

Гипотетически ваш путь дает больше гибкости, больше удобства, но — разработка без визуального программирования получается дороже.

А производительность самой платформы в наш век быстрых и дешевых серверов и дорогих программистов значения имеет мало.

Плюс в таких случаях выгоднее взять решение попроще и его доделать, чем сложнее и его переделывать. То есть проще построить новый дом из крупных панелей, чем перестраивать старый.


Вы это серьезно?
У меня теща к своему частному дому просто пристроила 2 комнаты. Ей это обошлось в 50 000 рублей (ну и плюс внутрення отделка за отдельные деньги потом).

Вы серьезно считаете, что снести весь дом целиком и построить его из панелей — было бы дешевле? Да как бы не в 50 раз она сэкономила относительно предлагаемого вами варианта.
Вы же принципиально отказываетесь от методик, ускоряющих разработу, таких как элементы визульного программирования.

Визуальное программирование не ускоряет программирование. Текстом писать гораздо быстрее, в статье на эту тему все расписано по пунктам. Производительность повышается путем повышения уровня абстрагирования, с чем в 1С — беда.
У меня теща к своему частному дому просто пристроила 2 комнаты. Ей это обошлось в 50 000 рублей (ну и плюс внутрення отделка за отдельные деньги потом).

А если теще комната маленькой покажется и она захочет расширить ее на 10 см, а на кухне окна в пол и высокие потолки сделать, расскажете потом как в 50к уложились.
Вы серьезно считаете, что снести весь дом целиком и построить его из панелей — было бы дешевле?

Не видели видео как дома разрушают и строят почти такие же? Казалось бы зачем.
Кроме всех прочих минусов у 1с есть два огромных, на мой взгляд:

1. Интерфейс, да он универсален, но в итоге он жрет просто невероятное количество времени. Многие, кому я делал интерфейсы, работающие с данными 1с, потом просили все больше и больше таких вещей. Потому что, когда время заполнения, например, ПКО сокращается в несколько раз, а иногда — в несколько десятков раз, то это имеет осязаемые экономический эффект.
Если работаем с характеристиками (напр одеждой) то расход времени уже за гранью добра и зла.

2. Интеграторы. Почти все: лень, наплевательское отношение, некомпетентность. Простой пример: разослал запрос на 50 лицензий + сервер, разброс сумм был впечатляющим, в половине случаев лицензия на сервер отсутствовала. Далее 9 из 10 начали рассказывать о том что нужно обязательно winserv, обязательно mssql, о сложностях поддержки итд. Если спросить про linux то 9,8 из 10 начинает жалобно завывать. Это вообще единственная сфера, где я размахиваю перед людьми существенными деньгами а они в ответ хамят и бросают трубки.
1. Да, с тем же вебом они явно что-то намудрили. Я не понимаю как при таком простом DOM у них demo-ma.1c.ru так тормозит. Вообще эта тема просто не влезла в статью. Куда логичнее кстати было бы сделать просто вход для custom frontend'а, скажем генерить тот же код на реакт, и чтобы при необходимости разработчик мог его изменять. Типа как тут. Но 1с походу принципиально ни с кем не интегрируются.

2. Ну это следствие определенной консолидации рынка с одной стороны и низкой IT-грамотности с другой стороны.
Дело не только в тормозах, сам интерфейс это ужас и ад.
UFO just landed and posted this here
в 1С не как в той крутой системе

Она была создана после того как я несколько лет работал с 1с.

В общем уверен, что у Вас простое дело привычки

Создайте в базе 5 футболок с размерной сеткой xs-xl и 5 цветами, потом выставьте счет на эти футболки. Если у вас не было такого опыта раньше, скажите, с какой итерации вы это сделаете)

Сейчас же, когда всё направлено на минимизацию элементов формы

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

Кстати за перемещение элементов интерфейса в непредсказуемом направлении вообще разработчики должны гореть в аду.
UFO just landed and posted this here
Статей с критикой 1С на Хабре достаточно (например, один, два, три), но, на мой взгляд, они либо слишком много внимания уделяют всяким мелочам, вроде неправильной организации меню, либо рассуждают о слишком абстрактных вещах, в которых 1С, возможно, и не виноват.
Потому что, например, некая компания Тринион — консалтинговая, и об 1С рассуждает далеко не айтишник, а походу вообще заказной копирайтер, потому что при личном общении их «лицо» с трудом ровно на русском выражается. У вас же классный, айтишный взгляд, не ссылайтесь на гуманитариев :-)
такой объемной попытки «объять» эту тему я еще не видел. ))
есть еще как минимум две проблемы:
— общий контекст для разных тредов. т.е. в платформе реализовать синглтон невозможно по определению. весь контекст существует в рамках одного треда.
— сами разработчики. они просто не хоят по-другому. я делал решения для как минимум двух перечисленных вами проблем: запросов на изменение и функционального стиля кода — меня закидали тухлыми помидорами за то, что я тут со своими улучшайзингами лезу в их прекрасный 1С
Это да. Про проблемы с многопоточностью я действительно забыл. Но справедливости ради в бизнес-приложениях она нужна не так часто.

PS: Кстати в процессе обсуждения похоже набирается материал для второй части :).
Спасибо за наводку, почитаю.

P.S.: Не думал, что инфостарт статьи с критикой 1С пропускает.
UFO just landed and posted this here
Не поверите, но в этой статье даже ссылка на ту статью есть. Но там всего один маленький кейс — Отсутствие наследования и полиморфизма рассматривался. А это более глобальный разбор полетов так сказать.
Та статья, имхо, гораздо более спорная, и только про один аспект. Эта статья гораздо лучше аргументирована на мой взгляд.
Автор обучается, еще несколько статей и все однозначно поймут мысль, которую он хочет донести
*сорказьмы
Поверьте те кто может, уже давно поняли мысль, которую пытался донести автор. Ну а «горбатого, могила исправит».
Дежавю не дежавю, но текущая статья просто шикарна. 1С говно — и вы с вашим 1Script и прочими костылями тому подтвержение.
О, и мне помидорчик достался, прям даже с переходом на личности. Ну не воспитали вас мама с папой, чтож, горевать не буду, мало ли мудаков на свете
Нет в данном случае не хотел Вас оскорбить, я об общем выводе из ситуации — 1С не достаточно развита поэтому Вам в лице сообщества приходится делать их работу, а Вы с 1Script и прочими BSL лишь больше развращаете этого монополиста. Не обижайтесь на критику, но Вы как разработчик 1С разве не испытываете боли от перечисленных в статье фактов? Самое забавное что на рациональную критику всегда логично предоставлять какое решение или ответ — а тут никто ответить не может так как ничего не может сделать с монополией, а как известно монополия без конкуренции — не ведет к развитию, собственно это я и наблюдаю.
Не полностью согласен с частью пунктов, но перечислено многое из того что сподвигло меня уйти из разработки на 1с спустя 4 года, о чем не жалею (пусть ушел не в разработку бизнес систем на других языках и платформах, а в андроид разработку).
А еще 1С совершила один подвиг: благодаря ей тысячи и тысячи российских программистов не могут мечтать о том, чтобы завести трактор!
Кто из них этого реально хочет — свободно перейдёт на другие языки и таки заведёт :))
ну… зависит от того что вы вкладываете в понятие «свободно»… 1С это всеже довольно изолированный мир и, условно, будучи синьером «там» — вы не сможете претендовать на мидла «тут» по умолчанию.
даже джуном влезть не просто, а учитывая еще что все-таки привыкаешь к определенному уровню достатка, обрастаешь семьей и ипотекой — почти невозможно
UFO just landed and posted this here
Но есть и положительные моменты, хуки жизненного цикла документа(ПередЗаписью, ПриЗаписи, ПослеЗаписи — они очень необходимы. И если мне в другом ПО говорят что этого нет. Значит продукт очень молодой, и не дошел до задач которые решаются такими вызовами.

Такие события это детский сад. Хуки на вычисляемые данные вот это вещь. С ней такие вещи можно делать, что 1С и не снилось.
UFO just landed and posted this here
Не знаю ни одного человека (в т.ч. 1С-ника) который бы очень хотел завести трактор, но не мог. Вот прям хотел, но не мог, 1С проклятый мешает. Все кто хотел — уехал, подучился, прокачался, а некоторые и прямо со скиллами 1С-ника уехали 1С-ить — никаких проблем.
(без необходимости гадания, что же это за поля и таблицы — _Fld16719 и _Document5759)
. Зачем гадать, можно без проблем расшифровать значение любой таблицы или поля.
Ключевое слово тут — расшифровать. Очень удобно, когда в SQL Profiler'е анализируешь запрос.
не очень корректное сравнение, расшифровать поле/таблицу в 1с, минута времени, ноль интеллектуальных затрат.
Серьезно? А потом держать в памяти или выписывать куда то и постоянно проверять все расшифрованные названия? Вы издеваетесь?
Для чего читать планы запросов и смотреть профайлером «дорогие» запросы? Лучше же там видеть нормальные названия полей и таблиц, а не белиберду. Разве нет?

Или настоящий 1С программист на любой вопрос «А чего это у меня все тормозит ?» должен отвечать — «Купите более мощный сервер»? Или может в 1С запросы супер оптимизируются, что там никогда их профайлить не надо?
Да, в профайлере не посмотришь, небольшое неудобство есть. Но я думаю вряд ли даже 1/2 процента 1с программистов сталкивается с этой задачей хотя бы раз в неделю. И как написано в заголовке статьи это уж точно не тянет глобальную фундраментальную проблему.
UFO just landed and posted this here
Сколько у вас было максимум пользователей в одной базе?
Кстати, не совсем корректный вопрос. Мы у одного клиента предоставляли доступ из внешнего личного кабинета через JSON Api по заполнению профиля пользователя (у нас в базе хранится и получается эта информация). Зарегистрировалось за неделю что-то около 100К пользователей. Можно сказать, что у нас в системе было 100К пользователей?
Да, поправлюсь. Одновременных пользователей (кстати, вы описали немного нелегальное использование, 1с на каждого пользователя использующего веб или хттп сервисы требует отдельную лицензию, пусть технически это и не так).
UFO just landed and posted this here
Ну вообще согласен с тем что нагрузка не совсем прямо связана с количеством пользователей одновременных, но корреляция тем не менее есть.
Нам помню приходилось разбирать планы запросов когда запускали ТОИР в магните, 1000+ обычных одновременных пользователей и пара тысяч мобильных (которые в целом работают оффлайн ибо часто находятся вне сети, но создают нагрузку когда предварительно загружают все нужные им данные для использования локально, а так же изменения из ассоциированных узлов планов обмена). В общем когда пользователей начали массово запускать в базу, параллельно вести паспортизацию оборудования (миллионы элементов довольно тяжелого справочника), запускать обмен с мобилками — бегали в мыле и искали и оптимизировали запросы, бизнес логику, с блокировками разбирались и еще много чем заниматься приходилось. Хотя мне, признаю, планы запросов разбирать не приходилось. Коллега готовился к эксперту и все такие задачи себе загребал для наработки практики.
UFO just landed and posted this here
ну а мой дружбан как раз всё сделал по семиуровневой модели разработки


Можно поподробнее, пожалуйста?
UFO just landed and posted this here
Куда вписывать, зачем держать в памяти, в 1с открыл обработку которая показывает соотв. объектов метаданных таблицам и нашел. Дело минуты.
Для полного счастья не хватает ещё пары камней в огород 1С.
1) Низкий порог вхождения разработчика, когда «по образцу» без понимания механизмов можно писать совершенно раздолбайский код, типа перебор всех строк и сравнение, вместо запроса, и он будет работать! Из первого камня следует второй:
2) Очень жестокая ловушка «роста масштаба». До определенного размера всё это «раздолбайство» реально «летает», а потом «вдруг» при достижении некоторого предела начинает резко и конкретно тормозить. И вот чтобы разгрести этот накопившийся чудо-код, нужны уже совершенно другие затраты на разработчиков. Откуда и мощный негатив и зачастую презрительное отношение уже ко всем 1С-кодерам.
Низкий порог вхождения в 1С — это иллюзия, которая уже давно далека от реальности. Собственно наличие SQL внутри 1С (то есть JOIN'ов с типами) задирает уже задирает порог вхождения достаточно высоко. Хотя если забить на масштабируемость, то да не предельно высоко, но все равно высоко.

А с масштабируемостью — даже .Net будет проще. lair не даст соврать.

lair с 1С не работает. К счастью.

Ну я про то, что в .Net то все просто. Там и работа с запросами в языке, и явная типизация, и много чего еще, про что не раз говорилось в предыдущих темах. Ну и я куски 1С кода в статье приводил. В .Net же явно красивее. Нет?

Я, если честно, не горю желанием читать статью. По моим субъективным ощущениям, в .net — красивее, да.

Проходил мимо и не смог не вмешаться.

Мне интересно каким образом вы смешали и по каким критериям сравниваете язык программирования общего назначения C#, платформу .NET, технологическую платформу и фреймворк 1С: Предприятие и ее мягкий слой в виде предметно-ориентированного скриптового языка BSL?
Все очень просто берем абстрактную сложную информационную систему. И представляем, что мы ее разрабатываем / или нам нужно ее доработать, и она написана на .Net / 1C / / Python / lsFusion и т.п.
Не могу себе представить сложную информационную систему написанную на .net или python.

Могу представить систему, где бэкенд написан на c# версии 7 (или на vb.net) на фреймворках asp.net core и ef core и работает под .net core, или python + flask + еще куча всего, а фронтенд — на typescript и react, например.

Так что с чем сравниваем?
Странно мне казалось, что в .net что-то и для фронтенда есть. Призывается lair во второй раз. На чем фронт обычно делают при использовании .Net.

Но ок, пусть фронтенд на реакте будет, хотя да конечно это порог вхождения увеличит, тут я действительно немного преувеличил. Но подождем lair'а.

Вот зачем вы меня в эксперты всея .net записываете? У меня там вполне узкий ограниченный круг интересов.


И таки да, по моим представлениям, если вообще нужен интерактивный фронт (потому что обычный HTML-то можно на чем угодно сгенерить), берут фронт-енд фреймворк. Есть контролы, есть хелперы, есть интеграции — каждый сам для себя выбирает, как ему удобно делать.

На чем фронт обычно делают при использовании .Net

На чем угодно и в зависимости от того какой фронт.
Призывается lair во второй раз.

Если для вас это так важно, то я, в общем-то, почти уверен, что lair подтвердит мою правомочность разговаривать и про дотнет и про 1С.

Это вообще забавно, конечно, что вообще призодит в голову идея, что такие вещи должен кто-то третий подтверждать.

Argumentum ad verecundiam же. Он тебе доверяет :))))
Ну просто в свое время, lair так усиленно рассказывал как в .net все круто (в том числе в споре про логику форм емнип), что у меня сложилось впечатление, что в .net логика представлений (фронтенд) из коробки. Тока правда я так и не понял, а что .net предлагает для форм использовать? Богомерзкий javaScript?
.net не предлагает использовать для форм ничего. Есть множество фреймворков, каждый из которых предлагает что-то свое. И в .net первичен рантайм.

1С в первую очередь предлагает один единственный «фреймворк-платформу» (в которую входят изоморфные «управляемые формы»), а рантайм и язык являются производными от этого фреймворка и жестко заточены под конкретные задачи.

Я не понимаю как можно сравнивать полноценный язык общего назначения с DSL, который проектируется под очень узкий и конкретный набор задач и конкретный узкий рынок. С какой-то натяжкой можно еще сравнить какой-нибудь фреймворк или набор фреймворков (как технологический стек) для .NET с 1С и… на конкретных задачах, под которые затачивалась 1С, этот конкретный стек будет проигрывать по критериям скорости и стоимости разработки и поддержки. Пока вы не наткнетесь на задачу, которая в рамках 1С нереализуема.
Ну если под узким рынком иметь ввиду бизнес-приложения, то их вполне можно писать и на 1С, и на .NET, и на Java, и на Delphi (вполне успешно). И потому можно сравнивать и по удобству для программера, по поддержке платформ (ОС, mobile, БД — Java рулит, в т.ч. lsFusion), по скорости работы решения и требовательности к ресурсам (тут Delphi на коне), по наличию готовых решений (в России 1С вне конкуренции) и т.п.

В данной статье автор затронул только технический аспект: удобство для разрабов, язык разработки, простота поддержки и доработки, управление версиями и т.п.
если под узким рынком иметь ввиду бизнес-приложения


Конечно, и тогда по совокупности факторов 1С в России вне конкуренции в small и medium business и потихоньку начинает подпирать SAP в больших энтерпрайзах.

В данной статье автор затронул только технический аспект: удобство для разрабов, язык разработки, простота поддержки и доработки, управление версиями и т.п.


Здесь надо все-таки различать легаси, которое существует по историческим причинам и с наличием которых никто не спорит, включая саму 1С, и сознательные решения, которые делают платформу удобной на узких задачах, но отвратительной на задачах на которых ее сравнивают с языками общего назначения.
В статье приведены технические проблемы самой платформы 1С, вне зависимости от решаемых задач.

Что касается продажи готовых решений, то тут зарабатывает в основном сама 1С или франчайзи. Поэтому большинству посетителей Хабра или даже той же Мисты такой бизнес карман не наполнит.

А если потребуются доработки готового решения, где уже смогут заработать тысячи программистов по всей стране, то для них (нас) технические удобства платформы уже играют немалую роль. И писать на Basic-подобном языке, без новомодных фич, без полноценного функционального IDE становится уже не так интересно на фоне Visual Studio, IDEA или даже Delphi.
без новомодных фич


Без каких?

без полноценного функционального IDE


А что не так с EDT?

Я серьезно спрашиваю, потому что возможно смогу объяснить почему введение каких-то фич из языков общего назначения в DSL может быть не лучшей идеей.
Ну, например, что касается языка: интеграция языка доступа к БД в язык платформы, с автодополнением, подсказками и т.п. (как раз по теме разработки бизнес-приложений). Свёртывание блоков кода. Замыкания. Типизирование переменных и проверка на типы во время компиляции (мне как Дельфисту это особенно не нравится в 1С). Полноценное ООП с наследованием и полиморфизмом. Параллелизм. Ну и т.д. и т.п. Просто сравните язык 1С с С#, Java, Python или Delphi, и всё вылезет.

Дальше IDE: рефакторинг, синхронное редактирование идентификаторов (в Delphi очень удобно), графическое выделение структуры (вертикальные полоски в Delphi), переход на определение функции/переменной по Ctrl-Click, возможность отредактировать код во внешнем редакторе, про системы контроля версий писал автор, ну и т.д. — открыть описание фич любой современной IDE и пройти по списку. Насчёт EDT я не знаю, сравниваю со встроенным IDE которое идет с 1С 8.2 (Конфигуратор).

Дальше Debugger: тоже самое… Ну я думаю вы и так прекрасно знаете, насколько современные IDE ушли вперёд за последние скажем 5 лет. А основная функциональность IDE 1C застыла на уровне наверное 1С 7.7 — это аналог первых версий Delphi и Visual Basic.
Просто сравните язык 1С с С#, Java, Python или Delphi, и всё вылезет.


Так нельзя же их сравнивать, это разные вещи.

Давайте по порядку:

интеграция языка доступа к БД в язык платформы, с автодополнением, подсказками и т.п. (как раз по теме разработки бизнес-приложений).


Да вот только linq query syntax в C# получился достаточно сомнительным и его не так много людей используют.

Замыкания.


Соглашусь.

Типизирование переменных и проверка на типы во время компиляции


Я с вами в целом соглашусь, а вот любители языков с динамической типизацией — нет, и далеко не факт, что здесь нужна статическая.

Полноценное ООП с наследованием и полиморфизмом.


Зачем?

Параллелизм.


Он в 1С есть, сознательно урезанный.

Свёртывание блоков кода.


Дальше IDE: рефакторинг, синхронное редактирование идентификаторов (в Delphi очень удобно), графическое выделение структуры (вертикальные полоски в Delphi), переход на определение функции/переменной по Ctrl-Click, возможность отредактировать код во внешнем редакторе, про системы контроля версий писал автор


Почти все есть в EDT.

Типизирование переменных и проверка на типы во время компиляции


Я с вами в целом соглашусь, а вот любители языков с динамической типизацией — нет, и далеко не факт, что здесь нужна статическая.


Как любитель статической типизации и при это хорошо знакомый с 1С — совершенно не понимаю статическая типизация в 1С.

Это же узкозаточенный язык, манипулирующий готовыми типами объектов.

Не нужно тут проводить аналогий с языками программирования общего назначения. На тех языках вы будете писать все алгоритмы, да. Но в 1С значительная часть алгоритмов реализована движком платформы и скрыта от вас, находится вне языка программирования 1С, вы получаете в использование просто готовые объекты.

Так что сложность алгоритмов кода 1С не столь велика. Там больше манипуляций с готовыми объектами, что движком поставляются.

И использование статической типизации в данном случае — только усложение кода и работы с ним.

Опять таки, это позволяет куда как проще производитель организацию слабосвязанных модулей.

Когда изучаешь чужую разработку в 1С, в процедуру приходит параметр Нечто, без указания типа, как быстро определить что это? Как получить доступ к его свойствам, методам? По контексту? Искать вызовы этой процедуры и уже там выяснять (и запоминать) тип? А если процедуры вложенные, бежать по лесенке до верха стека вызовов?

Допустим выяснили, что Нечто — это ссылка на НекийДокумент. Чтобы обращаться к членам класса всё равно придётся держать открытым окно конфигуратора с описанием этого документа. И вручную печатать нужные члены в код…

Ну да это всё и так известно. И что язык 1С давно и безнадёжно устарел всем понятно. Но налаженная инфраструктура, тонны разработок, десятки тысяч специалистов их спасает. Однако если платформа будет дорожать, то бесплатные опенсурсные проекты, созданные на десятилетия позже 1С с учётом всех новинок в программировании, могут составить ей мощную конкуренцию. Даже без всех неоспоримых плюсов 1С.
Как получить доступ к его свойствам, методам? По контексту? Искать вызовы этой процедуры и уже там выяснять (и запоминать) тип? А если процедуры вложенные, бежать по лесенке до верха стека вызовов?

Прямо вьетнамские флешбеки словил… Это конечно немного решается комментариями — но так себе((
Когда изучаешь чужую разработку в 1С, в процедуру приходит параметр Нечто, без указания типа, как быстро определить что это?


Это понятно.

Не неразрешимая проблема. Говорящие названия переменных используют для подобного случая. И/или комментарии.

Согласен, что в языках со статической типизацией можно использовать и другие методы. Но это не неразрешимая в языках с динамической типизацией проблема. И кстати, а чем вам поможет, если переменная в чужой разработке типа «МойСуперПуперТипНеСкажуЗачем»?

А теперь посмотрите доводы тех, кто написал серьезные вещи на PHP (та еще древняя версия была без всей этой новомодности; Facebook), Python (Google, Dropbox первой версии) и пр. — почему они в свое время выбрали именно языки без статической типизации.

Допустим выяснили, что Нечто — это ссылка на НекийДокумент. Чтобы обращаться к членам класса всё равно придётся держать открытым окно конфигуратора с описанием этого документа. И вручную печатать нужные члены в код…


Зачем?
Просто типизируйте явно эту переменную.

Нечто = Документы.НекийДокумент.СоздатьДокумент();


Я всегда так делаю.
После этого IDE подсказывает.
Потом типизацию убираю.

Понятно что это не совсем идеальный вариант. Но рабочий.

Вы же предлагаете вводить коренные изменения в языке ради решения проблемы, что решается просто.
Ну да, это не новый спор. Основной довод — меньше печатать. Можно ещё комментарии в SQL-код не вставлять, для ускорения процесса так сказать.
Ну да, это не новый спор. Основной довод — меньше печатать.


Да нет, не он.
Вы рассуждаете о примитивных типах — когда просто тип в переменной, которая пришла в параметрах функции.
Тут действительно — чего сложного тип прописать в параметрах.

А ежели туда передается не число и не строка, а аж целая структура? Его же объявить нужно.

И это будет уже не просто одно слово на каждую переменную.

В языках со статической типизаций нааааааааамного больше кода.

Правда для компенсации — языки с динамической типизацией требуют больше кода для тестов. Вот только, положа руку на сердце, уж чем-чем а текстами часто пренебрегают.

А кто мешает
type TMyType = TSomeClass<Integer, TIterator>(TParent1);
и потом использовать тип TMyType?
И печатать немного, и переменная типизированная.
А кто мешает
type TMyType = TSomeClass<Integer, TIterator>(TParent1);
и потом использовать тип TMyType?
И печатать немного, и переменная типизированная.


То, что мешает вашему гипотетическому программисту из вашего примера давать говорящие названия переменным или комментарии писать к параметрам.

Полагаю, ровно тоже будет и мешать делать то, что вы предлагаете.
UFO just landed and posted this here
Типизация просто отвлекает когда человек занимается бизнес-процессами, а система требует определиться с типами переменных. Но в результате возникает другая проблема: какой результат должен быть у выражения 1+1? «2» или может «11» или вовсе «11.0» это беда многих языков с универсальным типом данных. Причем в бизнес-задачах уже заранее известно с какими данными мы работаем — строка, целое число или вещественное. Второй менее важный вопрос как организовано хранение массивов этих чисел, массив чисел типа VARIANT объёмом в миллион значений может запросто откусить кусок памяти в 100Мб и все операции с таким массивом будут происходить с постоянным перевыделением памяти и тасканием десятков мегабайт туда-сюда. Хотя наверно для 1С это не очень актуально, но кто знает… копейка рубль бережёт.
Типизация спасает от многих неочевидных ошибок, на этапе компиляции. И позволяет быстро разобраться с чужим кодом. Но сейчас даже в Delphi — строго типизированном языке — появился вывод типов, т.е. когда тип переменной очевидно и однозначно выводится из присваиваемого значение, тип можно не указывать. Это здоровый компромисс.
UFO just landed and posted this here
Изначально типизация появилась из-за технических ограничений

Гы, вы это скажите С или асму где типизация не строгая. Да и лисп появился очень давно, там типизация динамическая.
UFO just landed and posted this here
Потому что и там и там с типизацией все плохо. В одном случае типизация динамическая, в другом можно сказать что она практически никакая. Кстати с типизацией и в сях плохо, к сожалению моему, она хоть и статическая но слабая. Статическая типизация лишь отчасти появилась из за технических ограничений, лисп тому примером, бейсик вспомните (64 год). По факту сейчас все мейнстримные коммерческие языки типизацию только усиливают. В web фронтенде все больше пишут на тайпскрипте, в новых языках вроде котлина, свифта и дарта даже возможность присвоить null переменной какого либо типа нужно специально объявлять.
Свёртывание блоков кода.

А давно этого нет у 1С?

Дальше IDE: рефакторинг, синхронное редактирование идентификаторов (в Delphi очень удобно), графическое выделение структуры (вертикальные полоски в Delphi), переход на определение функции/переменной по Ctrl-Click, возможность отредактировать код во внешнем редакторе, про системы контроля версий писал автор, ну и т.д. — открыть описание фич любой современной IDE и пройти по списку.


Полноценно работает только для языков программирования со статической типизацией.
Дальше Debugger: тоже самое… Ну я думаю вы и так прекрасно знаете, насколько современные IDE ушли вперёд за последние скажем 5 лет. А основная функциональность IDE 1C застыла на уровне наверное 1С 7.7 — это аналог первых версий Delphi и Visual Basic.


Да ладно, «застыла»…
Удаленная отладка — это свежее так навскидку — то чего не было 7.7.

И кстати, что там такого революционного произошло в отладчиках?

Насколько вижу — большая часть отладачных механизмов в современных IDE для всех языков — еще времен Turbo Pascal, он это все умел с версии 5, выпущенной в 1988.
Что касается продажи готовых решений, то тут зарабатывает в основном сама 1С или франчайзи. Поэтому большинству посетителей Хабра или даже той же Мисты такой бизнес карман не наполнит.

Очень хорошо зарабатываю на 1С как программист.
Ну просто в свое время, lair так усиленно рассказывал как в .net все круто (в том числе в споре про логику форм емнип)

А можно ссылку? А то я уже детали забыл.


у меня сложилось впечатление, что в .net логика представлений (фронтенд) из коробки

Когда-то, во времена Windows Forms, была. Для веба никогда не было, asp.net — отдельный фреймворк.


Но неоднократно же говорили, что нельзя сравнивать .net, который платформа общего назначения, с платформой разработки бизнес-приложений. И кажется мне, что я о подобных платформах и говорил.


Тока правда я так и не понял, а что .net предлагает для форм использовать?

Что хочешь, то и используешь. На базовом уровне — HTTP in, HTTP (HTML) out, но даже это не в ядре.

Эти ваши демо-приложения lsFusion сыпят в браузер джавовыми исключениями, поэтому я еще больше не понимаю что с чем мы сравниваем? Java и .NET?
Много чего в куче: и платформа, и примеры из типовых конфигураций. Но есть вещи, с которыми не поспоришь:
Как следствие, в последних версиях 1С постепенно приобретает «болезнь SAP» — на любое пожелание заказчика, ему говорится: «вы просто неправильно работаете, есть best practice, вы тоже должны работать именно так»

К сожалению, это так. 1С пошла по пути безумного усложнения типовых конфигураций, которые иногда не могут сделать то, что умели прежние, а доработка — в разы сложнее. Теряется гибкость решений, сопровождение 1С становится или дороже, или менее эффективным. Очень плохой путь выбрала 1С.
Много чего в куче: и платформа, и примеры из типовых конфигураций

Типовые приведены для иллюстрации практик использования.
К сожалению, это так. 1С пошла по пути безумного усложнения типовых конфигураций, которые иногда не могут сделать то, что умели прежние, а доработка — в разы сложнее.

А них выбора не было по двум причинам:
1. Малый бизнес они окучили, надо было переходить к среднему (тем более что совсем малый начал переходить на SaaS)
2. Рынок из greenfield превратился в brownfield, где «пришло-ушло-осталось» уже у всех есть, а значит нужно продавать «лучшее враг хорошего».
Был у них выбор. Средний бизнес прекрасно жил на обычных формах и толстом клиенте. Переход на УФ принес кучу затрат, а многие средние и крупные остались на ОФ. 1С плюнула в лицо всем предприятиям, внедрившим конфигурации на обычных формах, перестав поддерживать старые типовые конфигурации. Отдельный привет внедрившим УПП — сложные проекты (а УПП не для ларьков предназначалась) предлагается просто выкинуть в мусорку и внедрять ERP.
Перед глазами пример: фирма работала на 7.7, пытаются есть кактус разрекламированной УТ 11, и каждый день всё больше задаются вопросом: «а не перейти ли на УТ 10»?
Почему нельзя было УФ сделать удобной отдельной опцией, не выбрасывая десятилетний труд всех программистов в помойное ведро?
Беда рынка в том, что конкурента пока нет, но он обязательно появится, если 1С не повернется лицом к пользователям.
Сама платформа — очень удобна, позволяет вести быструю и эффективную разработку. (хотя в последнее время 1С слишком увлеклась добавлением в неё смайликов(!), при отсутствии таких элементарных вещей, как оператор паузы или воспроизведения звука)
Не путайте поддержку отраслевых решений и типового решения.
А 1с писала отраслевые решения на УПП?
В письме приведён список решений со ссылками на solutions. Там по идее должны быть указаны разработчики этих решений (я, к сожалению, с большинством из них даже не работал). В большинстве своём отраслевые решения пишут партнеры фирмы 1С и продают их. В данном случае, в инфописьме говорится о конфигурациях, которые разработаны на базе 1С: УПП (взята типовая поставка 1С: УПП (которую разработала фирма 1С) и добавлены определенные модули для удобства или специализированного учета). Т.е. снимаются с поддержки конфигурации партнеров, но не сама базовая поставка 1С: УПП (для неё пока только увеличилась стоимость сопровождения ИТС)
Да, немного был неправ. Речь про отраслевые. Есть письмо про прекращение продаж УПП, но пока нет информации о прекращении поддержки.
Но даже в этом раскладе — об окончании поддержки предупредили за 3 года, дали список конф, на которые можно перейти. Скорее всего, в этих конфигурациях есть механизм перехода с предыдущих версий.
Т.е. это в любом случае не предложение выкинуть в мусорку текущий продукт.
Насколько я знаю, механизма перехода с УПП на другие конфигурации нет.
1С плюнула в лицо всем предприятиям, внедрившим конфигурации на обычных формах, перестав поддерживать старые типовые конфигурации


До недавних пор еще версия 6 поддерживалась (та, что потеряла актуальность еще в начале века).
Версии 7.7, что уже более 10 лет как неактуальны — еще поддерживают.
Ну а уже 8-ка с обычными формами — вполне себе обновляются.

Вы имеете ввиду что их перестали развивать?
Дык ресурсы то не бесконечны.
Лучше пусть сосредоточатся.
Зик 7.7 — снята с поддержки
ЗУП 2.5 — сняли (мы приняли решение сидеть на 2.5 КОРП, но сколько это счастье будет длиться — неизвестно).
УТ 10 и УПП — поддерживаются по остаточному принципу, а поддержка УПП — платная и цена будет расти (1С так обещает).
При этом, никаких особых преимуществ в новых конфигурациях нет, кроме чудовищного интерфейса, абсолютно не годного для быстрой работы юзера.
Зик 7.7 — снята с поддержки

Да? Вы про технологию 20-ти летней давности? Дык они долгонько поддерживали.
А правда, что снята с поддержки?
Я вот вижу, что последниее обновление — еще от этого года.

а поддержка УПП — платная

Это ОС Windows, что постоянно продается для новых пользователей и новых устройств поддерживается вам бесплатно за счет других людей.

В продуктах с ограниченным числом пользователей вечная бесплатная поддержка невозможна.
Да и никогда не была поддержка у 1С бесплатной (кроме какого-то там небольшого количества месяцев сразу после покупки).
А был-ли другой путь? Последние лет 25 типовые конфигурация постоянно усложняются. Ну не нужна будет в сегодняшнем мире никому конфа для торговли, которая по возможностям соответствует, например, 5-му ТиСу :)
Модульность? О которой кстати автор писал.
Какая модульность?! Нет здесь серебряной пули. Красивых слов много, и проблем при использовании столько же (если не больше).
Ну как сказать. Очень многие программные продукты вполне себе живут с системами плагинов/модулей. Иногда эти плагины довольно сильно так расширяют функциональность в нужную сторону в нужном виде. Но да, в текущем виде это у 1с бы не вышло сделать по причине сильно упрощенного языка и ограничений платформы.
Да и некоторые вещи можно было бы поставлять как SDK и библиотеки.
Много экономических продуктов живут с системами плагинов? Плагин для ФАРа относительно легко сделать. А вот когда есть система с развесистой логикой использования данных и кто-то к этим данным внезапно что-то добавляет — как оно делать-то будет? Когда все вместе?
К сожалению судить трудно, на практике только с 1с работал из разных учетных платформ. Но даже на 1с во многом можно было бы предусмотреть точки расширения и интерфейсы для взаимодействия. А после доработки языка и платформы это можно было бы сделать еще проще и в большем количестве мест.
Ну и, естественно, от разработчиков типовых тоже бы потребовались затраты времени на адаптацию кода к такому.
Стоп. Так «трудно судить» или «многие живут с плагинами»?
Возьмите обычную, примитивную учетную задачу (например, остатки и продажа товаров в количественно-суммовом выражении) и прикрутите к ней «систему плагинов». А потом начните это разнообразно изменять со всех сторон. А потом подключите еще один плагин, потом еще один, а потом оторвите первый.
А потом представьте, что будет, если третий плагин использовал данные первого. И как со всем этим должна жить базовая функциональность.
Понятно, что в лозунгах все будет просто и тривиально, ибо изоляция, разделение и т.д. Но тогда почему система, построенная на таких принципах, еще не завоевала весь учетный мир и не свергла никого из текущих жильцов этого мира?
Интерфейсы, контракты, фасады над модулями и прочее — как раз для таких целей. По крайней мере мой 4-летний опыт с 1с и пусть пока всего 1 летний с ООП, статической типизацией, хорошими билд системами и IDE — подсказывают что это вполне возможно. К сожалению без строгих доказательств(
Но тогда почему система, построенная на таких принципах, еще не завоевала весь учетный мир и не свергла никого из текущих жильцов этого мира?

Ну как бы в Java и C# вполне себе рулят в учетных системах по миру насколько знаю. Да и SAP вроде штука довольно модульная в последнее время становится (хотя я его не трогал и не собираюсь).
Да и, имхо, 1с на подобном принципе и построена, только уровень абстракции ниже, а на уровне абстракции доступном разработчикам из за ограничений такое реализовать гораздо сложнее.
Как я и говорили — в лозунгах все прелестно :)
Вы попробуйте спроектировать систему с плагинами, которые имеют свои данные. И сыграйте на этой системе тот пример, который я привел.
Ну как бы в Java и C# вполне себе рулят в учетных системах по миру насколько знаю

И что? У С++ тоже с модульностью относительно хорошо.
И что? У С++ тоже с модульностью относительно хорошо.

Вот только он имеет слишком много проблем как ЯП. Пусть даже мне чем то симпатичен.
ЯП здесь вообще не причем. Вы его сами включили. Я вам про модульность учетной системы, а вы мне про модульность ЯП для платформы.
Я к тому что имея нормальный язык на руках модульность в учетной (и не только, естественно) организовать намного проще.
Понятно что java нельзя платформой назвать. А вот JVM со всеми библиотеками для нее написанными, фреймворками, и прочим — уже тянет на платформу.
Например, мы смогли нормально реализовать сложную систему с нормальной модульностью. Можете почитать вот тут как это делается.
И что?
«Если в исходном коде продукта произойдут какие-либо изменения, которые будут противоречить коду в зависимом модуле, то при запуске сервера будет выдана ошибка»
Привет, обновление продакшена :) В проде срочно нужны изменения базовой функциональности, текущую систему расширили с конфликтом и все радостно встало. Надо лезть руками и расшивать конфликт.
Нормально? Ну так берите в 1с расширения и делайте тоже самое.
Так почему весь ERP или УТ не сделали на 1С расширениях, а? Может, потому что этот функционал сделали, мягко говоря, криво, и модульность делать с ним тяжело? Или как это объясните?
Ну, например, потому, что расширения (по мерках платформы) сделан относительно недавно (по мерках самой платформы).
Ну например, потому, что не существует серебряной пули для нормального(!) расширения базовой функциональности множеством модулей (что вы и подтверждаете сами). Особенно, если эти модули а) взаимодополняют, б) разрабатываются разными разработчиками и в) могут произвольно подключаться/отключаться.
Почему ваша суперсистема микромодулей не может сама разрешить конфликт при обновлении? Может потому, что вы «этот функционал сделали, мягко говоря, криво и» нормальную «модульность с ним делать тяжело»? :)
Почему ваша суперсистема микромодулей не может сама разрешить конфликт при обновлении


А как она должна сама разрешить конфликт, если вы добавляете на форму элемент, а формы уже нет?

что вы и подтверждаете сами

Это где я подтверждал? Серебряной пули не существует, но бывает «лучше и хуже». Так вот в 1С с модульность хуже, чем много где. В lsFusion, например, модульность сделана гораздо лучше.
Вы же сказали, что
смогли нормально реализовать сложную систему с нормальной модульностью
. Вы сами привели простой(!) пример, с которым ваша система не справилась. Согласитесь, это странно. Такие уверенные заявления и нельзя в примитивном случае автоматически проблему решить.
И пока ваша декларативная модульность ничем от 1с-ской не отличается.
Вы сами привели простой(!) пример, с которым ваша система не справилась

Это был не пример того, как система не справилась, а пример того, как система подскажет программисту, что он что-то забыл при изменении базовой функциональности.
А будет пример того, как она хоть с чем-то справится? Или эта «сложная система с нормальной модульностью» умеет только в git'e исходники хранить и бесконфликтное двустороннее слияние делать? Если последнее, то это не плохо само по себе, но не тянет (ИМХО) на столь пафосное название
Издеваетесь? Что значит не справилась? Это искусственный интеллект что-ли по-вашему? Если в Java или любом другом языке вы используете библиотеку, а там поменялись классы и интерфейсы, то перестанет собираться проект. При этом, там везде нормально реализована модульность. Не подменяйте, пожалуйста, понятия.
Что значит — издеваюсь? Вы же сами написали, что сделали сложную систему с нормальной модульностью.
Сейчас ваша модульность (как и 1с-ская) при любом несогласованном шаге парализует работу прода и надо вручную собирать рассыпавшееся. Разницы нет. Значит и у 1с-а есть сложная система с нормальной модульностью?
ЗЫ: Мы не про Java (и остальное прочее) говорим, а про платформу для автоматизации экономической деятельности.
Сейчас ваша модульность (как и 1с-ская) при любом несогласованном шаге парализует работу прода и надо вручную собирать рассыпавшееся. Разницы нет. Значит и у 1с-а есть сложная система с нормальной модульностью?


Перевожу. На Java и SQL надо писать на английском языке. Разницы нет. Значит SQL = Java.

То, что система не работает, если в зависимом модуле что-то поменялось — это нормально и везде так.

А то, что расширения в 1С сделаны криво доказывает то, что УТ и ERP их не используют в коробке. Более того, наличие отдельных конфигураций Бухгалтерия, ЗУП, УТ, ERP (а не одного продукта с подключаемыми модулями) говорит о том, что все плохо с модульностью в 1С (ну или 1С-разработчики не дружат с разработчиками самой платформы).
А то, что расширения в 1С сделаны криво доказывает то, что УТ и ERP их не используют в коробке

Расширения предназначались для настройки решения при внедрении, поэтому в коробке ими и не пользуются.

УТ — это составная часть ERP, по сути — ERP это УТ + модули. Кодовая база одна.

То что у вас «модульность, когда мы клиенту подключаем за денежку то что ему нужно и ничего лишнего», в 1С — механизм функциональных опций, когда все уже внутри коробки, но появляется в интерфейсе/используется в коде только после установки галочки в настройках.
Я вижу, что вы плохо понимаете, что такое модульность. На всякий случай, галочки в интерфейсе — это не оно.
Я хорошо понимаю что такое модульность. Но раз уж вы сравниваете ужей с ежами, считаю себя в праве заниматься тем же.
С точки зрения заказчика, ваша модульность от «поставим галку и теперь у вас есть скидки» не отличается ничем.
С точки зрения разработчика различие не более чем вопрос удобства.
С точки зрения разработчика различие не более чем вопрос удобства.

А еще скорости и качества его работы. Что собственно и является основным критерием качества платформы.
Перевожу

Не. Вы язык не понимаете, чтобы переводить :)
Более того, наличие отдельных

Приведите пример нормального расширения данных (включая алгоритмику, использующую эти данные) — поговорим. Пока у fusion нет нормальной модульности по данным — говорить особо не о чем.
А Вы статью читали, что я кидал? Что значит «модульность по данным»? Там прекрасно добавлялись новые поля к строкам заказа, например.
У вас приведен тривиальный, не интересный пример. Но даже в этом примере не показано то, каким образом базовые алгоритмы будут учитывать расширенные данные и что будет происходить, когда расширение демонтируют из базы.
Есть понятие — абстрактные свойства. Это аналог интерфейсов в классическом программировании. Через них и реализуются «расширение» алгоритмов. Собственно регистры — это и есть одно из их применений.
Т.е. простого примера не будет? Без конкретного языка, простыми и понятными русскими словами? С описание разрешения конфликтов и т.д.
Ну нет, так нет.
А регистры — это и есть простой пример реализации интерфейсов. А глобально можно еще вот что: в базовом модуле делаете formula = ABSTRACT NUMERIC[14,2] (X, Y, Z). Затем используете ее в модуле как formula(x, y, z). А в других модулях можете делать реализацию этой формулы как угодно. То есть, например, так параметризуете формулу расчета автозаказа, а затем делаете 5 модулей с разничным способом подсчета (которые могут зависеть от совершенно разных показателей).
UFO just landed and posted this here
А никто так не делает потому, что сам вендор так не делает, только и всего.
UFO just landed and posted this here
Есть те, кто просто не видит смысла делать по-другому, не имея в виду никаких далеко идущих целей, так как тупо проще, да и вендор часто так-же поступает, жестоко ломая совместимость БСП, например.
UFO just landed and posted this here
Много экономических продуктов живут с системами плагинов?

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


Это существует.
Но далеко не заходят в этом.

Проблема в том, что эти точки взаимодействия или передают какие-то стандартизованные данные, которые должны быть на все случаи жизни.

Или передают совершенно абстрактные структуры, что снижает и понимание и повышает вероятность ошибок и не дает возможности автоматический контроль осуществлять.

Та модульность, о которой вы говорите — хороша для задач, где ядро обозримо — его можно сразу сделать на все случаи жизни.

В этом смысле — ядро у 1С есть.

Ну не нужна будет в сегодняшнем мире никому конфа для торговли, которая по возможностям соответствует, например, 5-му ТиСу :)

Модульность?

Красивых слов много, и проблем при использовании столько же (если не больше).

Очень многие программные продукты вполне себе живут с системами плагинов/модулей


Ну как они там живут — довольно плохо.

Речь или о простейшем функционале — там конечно можно сделать успешно.

Или о регулярных проблемах интеграции модулей и их взаимодействия — один модуль обновили/добавили — 2 других заглючили.

Не стоит конечно совсем ее списывать со счетов, но возможности модульности ограничены.

Действительно. Я тоже считаю, что все эти ООП, модульности и прочая ерунда — просто вселенский заговор и красивые слова. Надо только по старинке: процедурное программирование в блокноте.
Кстати, а у вас есть аналог 1С-ной БСП?
БСП — это винегрет из кучи несвязанного функционала, разработчиков которого настолько презирали в 1С, что не включили этот функционал в саму платформу?
Ну или это была специальная команда спасения, которая доделывала то, что не смогли реализовать в платформе.

Например, Групповое изменение объектов. В lsFusion это есть, по умолчанию, из коробки в любой форме (и сразу же в динамическом списке).

Даты запрета изменения — для этого есть CONSTRAINT. Зачем под это отдельные абстракции заводить? Видимо точно премии за это получают. Ну и т.д.
Не, ну нафиг БСП в платформу включать, абсолютно лишнее это. Общался кстати немного с разрабом БСП в сети — показался из всего 1сного контингента самым адекватным.
У БСП конечно есть проблемы, но они во многом из ограниченности языка вытекают.
Даты запрета изменения — для этого есть CONSTRAINT. Зачем под это отдельные абстракции заводить? Видимо точно премии за это получают. Ну и т.д.


потому что дата запрета для Васи и Коли — это разные даты, а еще их часто употребляют в сочетании различных аналитик (организация, склад, раздел учета, ...)
Так ради бога. В lsFusion пишите любые выражения в CONSTRAINT, где можете смотреть на что угодно. Зачем для этого дополнительные абстракции?
UFO just landed and posted this here
Если не считать всяких странных вещей вроде анкетирования пользователя есть. Это если вы про планировщики, политики безопасности, профилировщики, настройки таблиц и т.д. и т.п.
Да, это было бы верным решением. Но, похоже, время уже упущено.

Сразу скажу, что не являюсь профессиональным 1с программистом, хотя в свое время приобрел версию 8.х (не помню точно индекс) для обучения программированию. И еще скажу сразу, что я с большим уважением отношусь к системе 1с. И обращу внимание что разработчики 1с и разработчики на 1с это разные категории, точно так же как разработчики .Net и разработчики на .Net это тоже совсем не одно и то же.


По поводу недостатков 1с у меня есть свое мнение и оно такое: основных глобальных недостатка 2
1) 1с пока что не повернулось лицом к проблеме перехода на мобильные устройства. Да есть и уже давно версия для доступа через веб-браузер. Есть возможность работать с клиентами по технологии SOAP. Однако все упирается в механизм стыка сервера 1с с удаленными клиентами через серверы Apache или ISS с глючными и низкопроизводительными полключаемыми к этми серверам модулями.
2) 1с пока что не имеет в своем арсенале оптимальных модулей календарного планирования для сложных изделий и многооперационных техпроцессов.


Теперь о "критике" (не Автора статьи) 1с.


Критика эта зачастую носит характер какого-то неприятия на подсознательном уровне. При этом часто "критики" судя по их аргументам работали с версиями 1с 5.х максимум 6.х. Отчасти эта критика подогревается конкурирующими группами разработчиков или посредников. С одной стороны критикуют внедренцы зарубежных ERP систем или разработчики отечественных ERP систем. С другой стороны — ИВЦ промышленных предприятий, которые разрабатывают самописные корпоративные системы и видят в 1с аналог Excel который будет мешать внедрению самописных.


Почему я очень уважаю 1с еще начиная с версии 7.0


1) К обычным для работы с базами данных визуальными компонентами было добавлено еще несколько очень удобных:


  • Документ = заголовок+табличная часть в одном флаконе — экономит массу времени на разработку
  • Табличная часть — может выводиться в несколько строк — также не встречается в стандартных палитрах других разработчиков
  • Справочник — при задание поля типа справочник сразу становятся доступными все действия, включая редактирвоание, доабвление новых эеоементов ну и конечно посик, яильтры и т.п.

2) Была решена задача с оптимизацией итогов. Идея очень простая: В регистрах хранятся итоги за год, месяц и последнему документу. За другие периоды (не начало/конец месяца) просчитываются разностью от ближайшей точки времени.


3) Распределенная база данных из коробки (в том числе синхронизхация модет быть достаточно экзотичесокй например по email)


Чуть позже дам комментарий по тексту статьи. С Автором я не во всем согласен.

1с пока что не имеет в своем арсенале оптимальных модулей календарного планирования для сложных изделий и многооперационных техпроцессов
Занимаюсь данной темой, сомневаюсь, что возможно типовое решение, а тем более, что оно должно быть в платформе.

Большинство ТОП-овых ERP как раз на этом делают свою ставку.
Например SAP — имеют что-то для планирования встроенное закрытое от конечных пользователей и даже от партнеров.
MS Dynamix — собственно перекупили два как бы сейчас сказали стартапа — Axapta и Navision как раз ради этой функциональности.
JD Edvards — тоже говорили на презентации что имеют такие модули.


За исключением наличие этих модулей они все явно уступают 1с, т.к. являются закрытыми, не имеют и близко ничего подобного как предметно-ориентирвоанный язык 1с.


Конечно не может быть нечто подходящее для всех типов производств. Однако все производства сводятся к разным типам (массовое, крупносерийное, среднесерийное, мелкосерийное, единичное, дискретное, неипрерывное, однопередельное, многопередельное, сборочное, механообрабатывающее и т.п.) — от которых существенно зависит система планирования.

не имеют и близко ничего подобного как предметно-ориентирвоанный язык 1с.

Ну вот не надо. У Axapta и SAP есть свои DSL причем ABAP даже более предметно-ориентирован. Хотя конечно им обоим как и 1С далеко до идеала.
Так, например, если вы будете проверять, что сумма значений полей из двух разных таблиц должна быть больше некоторого значения, то при одновременном редактировании значений этих полей в обеих таблицах в блокировочнике все будет хорошо (точнее возникнет дедлок, в результате которого одна из транзакций откатится), версионник же благополучно запишет оба этих изменения в базу, нарушив тем самым ваше ограничение. Что же тогда поддерживает версионник в плане целостности?

wut? При чём здесь а) deadlock и b) целостность из ACID? Насколько я понял, о чём вы говорите, возможно, нарушена будет некая «целостность» с т.з. приложения, но логическая целостность (C в ACID) нарушена не будет.
Речь шла просто о целостности, «с т.з. приложения» или «логическая» не важно. Может правильнее было написать согласованность (из русской википедии про ACID):
Согласованность является более широким понятием. Например, в банковской системе может существовать требование равенства суммы, списываемой с одного счёта, сумме, зачисляемой на другой.

Но тут это чисто игра терминами.

DeadLock притом, что если две транзакции делают:
SELECT x FROM A, SELECT y FROM B, потом делают проверку на x+y > 5, а потом записывают одна в A, другая в B, то будет dead lock. Версионник запишет и ничего не скажет.
Но тут это чисто игра терминами

ну так не играйте ими, зачем вы ACID приплели, если у Consistency чёткое определение есть?
upd: Что касается «суммы» — разве она должна проверяться по остаткам на счетах? Должно быть две операции на одинаковую сумму — к описываемому вами примеру это отношения не имеет.
DeadLock притом

зависит от isolation level, не так ли?
ну так не играйте ими, зачем вы ACID приплели, если у Consistency там чёткое определение есть?

Цитата из википедии:
Consistency ensures that a transaction can only bring the database from one valid state to another, maintaining database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This prevents database corruption by an illegal transaction, but does not guarantee that a transaction is correct. Referential integrity guarantees the primary key – foreign key relationship. [6]

Более того в этой же статье consistency failure описано, ровно так, как я описал.
зависит от isolation level, не так ли?

Ну как бы нормальные уровни целостности по умолчанию подразумеваются. Не ручные же блокировки делать.
Ого, в версионниках constraint'ы могут нарушаться? Вот это новость.

Read Committed — не нормальный уровень?
Ого, в версионниках constraint'ы могут нарушаться? Вот это новость.

Consistency is a very general term, which demands that the data must meet all validation rules.

Это не обязательно constraint на значение полей в одной таблице.
Read Committed — не нормальный уровень?

Нет, именно по причине проблем с согласованностью.

Вы почему-то берёте устоявшиеся термины, присваиваете им иное значение, удобное вам, и строите на этом цепочку рассуждений. Какие constraints могут нарушаться в Oracle или postgre, из-за того, что они версионники? Validation rules кто задаёт? Как может СУБД из выполнять, если они только в голове программиста?
Read committed же вполне нормальный уровень изоляции — обеспечивает то, что обещает — зафиксированные в момент чтения данные и в нём не будет дедлока в вашей ситуации. Вы же не оговариваете условия — вы пишете — в блокирочниках дедлоки, в версиоониках согласованность по бороде идёт. А это совсем не так.

Я то термины из Википедии беру. А вы почему то термины конкретных реализаций конкретных СУБД используете.
чувак прав. учи уровни изолированности. если используешь RC то чего ты вдруг от него требуешь согласованности? на IL serializable будет ошибка сериализации. блокировочник же на RC в принципе ничего не гарантирует, нет даже гарантии того что остаток счета не считается несколько раз.
От RC я вообще ничего не требую. Serializable подразумевается по умолчанию.
на IL serializable будет ошибка сериализации.

UPDATE CONFLICT будет? В версионнике? Вы уверены?
в теоретическом версионнике конечно. но не апдейт конфликт, а ошибка сеариализации. в оракле честного serializable нет, зато у постгреса вроде есть честный serializable, который обязан рубить все, что попробует выдать результат отличный от того что должен был бы получится от сериализованных транзакций.
но это все не столь важно. толку от честного и блокировочного serializable ноль, в реально жизни это просто не взлетает, а реально весь фин сектор сидит на оракле с его не совсем честным но полноценно работающим serializable, где нужно выставлять select for update на подобные чтения. практика показала, что это работает.
Собственно про это и написано в статье. Что в версионниках жертвуется согласованностью и надо либо материализовать данные для которых важна целостность (то есть ограничения) или for update'ы вставлять.
ну так и неверно написано. все версионники кинут ошибку сериализации. исключение оракл, который не стал приносить в жертву здравый смысл и реализовал свой serializable, который не совсем честный, но подходит для того что бы считать деньги.
PostgreSQL тоже не кинет update conflict (хотя что-то уже начал сомневаться, но там же логика update conflict элементарная, просто сверяется что версия транзакции равна версии записи). Про какие версионники речь вообще?
To guarantee true serializability PostgreSQL uses predicate locking, which means that it keeps locks which allow it to determine when a write would have had an impact on the result of a previous read from a concurrent transaction, had it run first. In PostgreSQL these locks do not cause any blocking and therefore can not play any part in causing a deadlock. They are used to identify and flag dependencies among concurrent Serializable transactions which in certain combinations can lead to serialization anomalies.
Вспоминается…
Давайте рассуждать о крахе и подъеме Голливуда, не видя ни одного фильма. Давайте сталкивать философов, не читая их работ. Давайте спорить о вкусе устриц и кокосовых орехов с теми, кто их ел, до хрипоты, до драки, воспринимая вкус еды на слух, цвет на зуб, вонь на глаз, представляя себе фильм по названию, живопись по фамилии, страну по «Клубу кинопутешествий», остроту мнений по хрестоматии.

Хотелось ответить автору по существу… а существа то и нет.
Обычно я отвечаю по пунктам которые некорректны.
Но тут статья это просто чистый поток сознания и набор некоторых шаблонных фраз.
Взятых теперь понятно откуда — из описания своего могучего языка пятого (!) поколения.
Автор просто имеет обыкновение хаять то о чем он понятия не имеет.
На других форумах это называется
синдром ТП в поле
image

Как и базового понимания зачем вообще нужна трехзвенная архитектура программ.
Обычно от людей перешедших с иксела такое слышишь
С тем же успехом можно предавать анафеме компьютеры и далее до адептов плоской Земли.
Кстати вы же с калькулятора сюда пишете?
P/S Понял откуда растут ножки.
Эх, моська…
Это же изобретатели велосипеда с картинки — создатели могучего языка пятого (!) поколения. И все их тридцать два адепта )
Вы ребята похвалитесь когда у вас будет хотя бы тысячный пользователь.
Попробуйте статьи писать о своем могучем языке, а не хулить то в чем не разбираетесь.
У 1С два десятка миллионов только лицензионных пользователей.
Тут даже не слон и моська, а слон и мушка.
О, профессионалы появились в комментариях. Просветите же наконец меня дремучего.

Вот лень повторяться в третий раз, поэтому процитирую себя же.
Давайте так, это Хабр. Если с каким то пунктом вы не согласны, отлично, дайте развернутый комментарий, покажите что автор не прав (вы же понимаете что многие на Хабр ради комментариев заходят). И тогда все поймут что это просто «маркетинговый бред», «автор просто не разбирается» и все в таком духе.

У 1С два десятка миллионов только лицензионных пользователей.
Тут даже не слон и моська, а слон и мушка.

Давид и Голиаф — скорее. Но поживем увидим. Мы всего два месяца назад вышли и несколько десятков тысяч лицензионных пользователей у нас уже есть.

Хотя по вашей логике 1С по сравнению с SAP и Microsoft это тоже детский сад. Ну и как испытываете свою никчемность по сравнению с ними? Nokia тоже думала, что будет жить вечно…
Нет, друг. До Давида и Голиафа ещё очень и очень далеко. Давидов было очень много, но пока ни один них положения 1С на рынке не поколебал. В лучшем случае, занял какую-то свою, крохотную нишу. Говорить про это можно будет, когда вы приблизитесь к охвату хотя бы 1% рынка. Пока речь идёт наверное про десятитысячные, если не меньше, доли процента. На уровне статистической погрешности. :(
Nokia тоже так говорила.
Элоп слегка сознательно утаптывал Нокию под МС :)
В пользу мобильной винды Элоп закрыл все новые разработки Нокии в области мобильных ОС. Так что Нокия слегка не сама сдохла.
Как по мне, Нокия сознательно тупила и выпускала довольно странные решения, не говоря уже про то, что они легли под MS. 1С же на месте не стоит и продолжает развиваться.
1С же на месте не стоит и продолжает развиваться.

Да, придумывая все новые и новые костыли (ой, то есть абстракции). Но, как я понимаю, Вы за монополию? Чтобы был только 1С со своими ключами, платной документацией и т.д.
Я за объективность.
Автор топит против 1С и говорит, что его система лучше. Причём не приводя в пример достоинства своей системы, а выпячивая недостатки первой и ничего не говоря про её достоинства. Мне кажется это достаточно «грязная игра».
Я не спорю — может быть его система лучше. Но заявлять это можно будет только тогда, когда она займёт хотя бы какую-то долю рынка. До тех пор это беспредметный спор о технических «плюшках», которые конечному пользователю абсолютно фиолетовы — ему нужно свои ежедневные задачи решать. Доля рынка 1С показывает, что она с этим справляется. Как с этим справится система топикстартера — увидим.
Аргументация в стиле: «У меня тут >80% голосов, а вы все идите в… Когда победите на выборах, тогда и приходите».

До тех пор это беспредметный спор о технических «плюшках»

Habr — технический ресурс, и тут идет обсуждение технических аспектов, а не маркетингового bullshit.

Причём не приводя в пример достоинства своей системы

А Вы все наши статьи прочитали? Там только достоинства и описываются.
Причём не приводя в пример достоинства своей системы
В блоге, в котором размещена эта статья, есть набор статей, где рассказывается о достоинствах.
Но заявлять это можно будет только тогда, когда она займёт хотя бы какую-то долю рынка.
Это называется «сперва добейся». Так себе позиция. Да, эта статья в основном о «технических плюшках» и написана она не для конечных пользователей (если речь о пользователях решений).
А теперь слово автору. Статья и так получилась на 36 страниц, и в ней есть много намеков как надо было делать (и как сделано в lsfusion(. И если бы я ещё начал подробно про lsfusion писать она бы еще в два раза больше получилась, а я уверен и эту многие даже до половины не дочитали.

Впрочем статья «почему lsfusion а не 1с?» будет. Хотя уже сейчас очевидно, что надо было их вместе выпускать :(

Ну и про заявлять что лучше — это курица, яйцо. Чтобы занять долю рынка нужно заявлять и объяснять, что мы и делаем этими статьями.
Давидов было очень много, но пока ни один них положения 1С на рынке не поколебал

Ну назовите хоть один, у которого не было хотя бы половины из 21 проблем в статье. Ну или хотя бы треть возможностей из этого списка. Ничего близко похожего на самом деле до еще не было. Так что взлетит или не взлетит можно пока только гадать.
Взлететь может и взлетит, но не в качестве конкурента 1С.
Тогда в категорию «Давидов» не попадает.
Iscra Framework, например. Тоже себя позиционировали, как «низвергатель 1С». А сейчас у них сайт продаётся.
И сколько у них из перечисленных 33 достаточно фундаментальных возможностей было? Ну или хотя бы каких из проблем 1с не было?
Извините, это в 2007 году было, я уж так не вспомню. Но «топили» они знатно. С пеной у рта. А сайт, как я уже сказал, умер и продаётся, сейчас не посмотреть.
Одного топления недостаточно. Нужно ещё фундаментальные преимущества иметь. Как например эпл перед Нокиа.
а почему список должен быть именно «этот»? вы уверены, что именно это нужно рынку?
Ну потому что эти возможности — это отражение описанных в статье проблем. И практически все они выстраданы в результате разработок, доработок и внедрения больше чем сотни различных проектов.
То есть, субъективное, никакими серьёзными данными не подтверждённое, личное мнение.
А вы хотите по данным «Независимой Ассоциации Разработчиков Бизнес-Приложений»? Но вообще тот список достаточно всеобъемлющий, касается практически все NFR (нефункциональных требований к системе).
Я хочу, чтобы вы задумались, когда даёте самохвалебные безапелляционные ответы на серьёзные вопросы.
UFO just landed and posted this here
UFO just landed and posted this here
Как только Давидику исполнится 4 и если он не умрет от голода, 1С купит его и Давидик вольется в дружную семью 1С: Предприятия!
С голода он уже не умрет точно, вы хотя бы список клиентов гляньте. А когда 1С очухается (с их то глобальным видением) будет уже поздно.
Поглядим еще лет 5. Впереди глобальные кризисы, рецессии и пр. радости. Будет здорово, если появится еще один крупный игрок на рынке ЕРП систем и систем автоматизации бизнеса. Это заставит остальных двигаться шустрее.
UFO just landed and posted this here
Бухгалтерия это одна из небольших задач причем на предприятии. Те же САП и Аксапта туда не лезут и отлично себя чувствуют.
сделайте ввод по строке с программным анализом изменения значения без выхода из строки… и народ к вам потянется… но вы не можете :(
По СКД, вообще какой то сумбур написан, вообще не разобрались. Он нужен для быстрого создания легко настраиваемых отчетов. Настройки у все отчетов в одном стиле, так что пользователям легче привыкать/настраивать новые отчеты. Как интерфейс для доступа к данным он практически не используется, заменой форм не является точно, а эргономика у него вполне достойная, дело привычки. СКД это очень большой + 1с. Вот до его появления была дичь.
Ну просто в статье про подбор многие реально предлагали WYSIWYG реализовывать при помощи отчетов (то есть СКД).

Хотя я то как раз хорошо понимаю, что основное применение СКД — настраиваемые отчеты. Но, я про это в статье тоже написал, непонятно зачем их настраивать. Для печатных форм это бесполезно, а для аналитики есть куда более удобные и быстрые BI инструменты (позволяющие при этом не нагружать оперативную базу).
UFO just landed and posted this here
Когда собственный продукт на столько гавно, что описывать его даже не хочется :))
Не влезло в одну статью. Следующая скорее всего будет: Почему lsFusion, а не 1С? Ровно с тем же оглавлением и как эти проблемы решаются в lsFusion.
Лучше бы вы рассказали, как решаете проблемы бизнеса, а не проблемы 1С :))
У них нет проблем с бизнесом :) Это еще из первой статьи было понятно.
Вот смотрю я их демо, и думаю, странно как-то это всё.
Извините, статья показалось заказной «джинсой», которая в конце ненавязчиво рекламирует ваш продукт.

Вы сознательно умалчиваете (или не знаете, что ставит под вопрос вашу компетентность и ценность статьи вообще) наличие в 1С механизмов, которые описываете как отсутствующие.
Например, вы пишете:
Например, запретить ситуацию, когда количество к отгрузке становится меньше 0, или послать какое-нибудь уведомление в этом случае.

Платформа 1С для любого реквизита позволяет задать минимальное или максимальное значение. При записи можно выполнить так называемую «проверку заполнения», откуда совершенно элементарно можно
послать какое-нибудь уведомление


Отношения один-к-одному и один-ко-многим присутствуют. Например, подчинённый справочник или регистратор регистра.

Ну и так далее.
Платформа 1С для любого реквизита позволяет задать минимальное или максимальное значение. При записи можно выполнить так называемую «проверку заполнения», откуда совершенно элементарно можно

Для ресурса регистра позволяет? Кол-во к отгрузке как вы понимаете не реквизит справочника. И насколько элементарно это делается приведено в статье. Всего под 1к строк кода. Тем более что никакого события на изменения кол-ва к отгрузке нет.
Отношения один-к-одному и один-ко-многим присутствуют. Например, подчинённый справочник или регистратор регистра.

Это два частных случая. А как отображение справочника на документы как в ORM сделать? Но я дополню статью уже писал, руки просто не дошли.
Ну и так далее

С удовольствием послушаю и подкорректирую статью.
А как отображение справочника на документы как в ORM сделать?

Т.к. я не настоящий сварщик — подскажите на примере, какую задачу (в терминах бизнеса или техническую/интерфейсную) вы хотите решить?
Для ресурса регистра позволяет? Кол-во к отгрузке как вы понимаете не реквизит справочника.

Конечно. А количество чего-нибудь к отгрузке в 1С обычно делается через реквизит табличной части. Там тоже можно.

Не нужно писать про недостатки 1С, этого навалом. Напишите нам как ваша система решает потребности пользователей.
Конечно

Мы наверное недопоняли друг друга. Речь шла о событиях и ограничениях на остаток ресурса регистра.

Будет еще статья: Почему lsFusion, а не SQL?
Платформа 1С для любого реквизита позволяет задать минимальное или максимальное значение. При записи можно выполнить так называемую «проверку заполнения», откуда совершенно элементарно можно

Автор говорит про контроль отрицательных остатков. Он во всех темах этот пример приводит, мол «у нас контроль отрицательных остатков на уровне платформы, а в 1С обязательно надо писать килобайты кода размазанного по сотне процедур».
Хотя
а) этот код можно было бы написать проще, но в типовых придерживаются определенных стандартов (пусть и не идеальных) и универсальности (т.е. есть ряд других проверок и условий выполнения данной проверки);
б) сравнивая 1С и lsfusion показывает огромные запросы для 1С и вызовы процедур на lsfusion. Тот факт, что эти запросы в 1С можно тоже «спрятать» в процедуре автора не смущает. При этом, когда задается вопрос вида «если не нужно контролировать остатки для склада N, как это сделать?», отвечает в стиле «всего-лишь вызвать процедуру isWarehouseN(Warehouse)» не описывая что происходит внутри этой процедуры.
и т.д.
Нет в lsFusion нигде ничего не спрятано.

CONSTRAINT quantityAvailable(Stock st, Sku sk) > 0;

И все.

В 1С же логика обновления товар к отгрузке пишется отдельно, в статье ее нет (плюс часто по много раз, плюс часть сценариев запрещается, плюс она сложнее декларативной), а проверка ограничений пишется дополнительно (и именно она приведена в статье).
И если всё-же нам таки надо будет отгрузить «в минус» — то всё, приехали?
Уже сто раз в предыдущих темах обсуждали. Добавьте в constraint любое условие например AND NOT godMode, или отключите ограничение для соответствующей роли.
Это костыль, если что :))
А правильно как в 1С, сделать неоперативное проведение, которое будет работать по принципу, если очень хочется, то можно? Вот это реально бред…
Да при чём тут 1С, не бывает идеальных систем, и ваша- не исключение, как бы вам этого не хотелось.
Что значит костыль? Платформа же не сможет угадать условие какое вы хотите. Но вы пишете его ровно в одном месте, а дальше все платформа все делает за вас. И так как я приводил в статье извращаться не надо.
godMode — не костыль? Ну ок…
Это я для примера привел. А вы по какой логике собственно хотите разрешить нарушать ограничение? По ролям добавьте к условию AND NOT currentRole = admin.
Например, если сегодня последний день месяца и Луна в Юпитере. Дело не в условии, а в том, как вы предлагаете решать проблему.
Ну мы предлагаем решать проблему декларативно, задав условие и забыв. А 1с все на разработчика перекладывает, то есть предлагает решать проблему императивно — самому определять точки проверок и писать запросы этих проверок (хотя нормальные платформы это делают сами)
А партионный учёт у вас есть?
Или весь товар на складе — это одна большая «партия»?
Если есть — на каких принципах работает и как закрывает партии?

И не говорите, что партионный учёт не нужен.
Fifo, lifo точно есть, остальные не знаю, не по моей части. Но точно знаю что расписывание по партиям идёт сразу причем даже при приеме реализации в крупных сетях супермаркетов. А она принимается с актуальностью минута, и именно с такой актуальностью люди видят остатки по партиям. Представляете нагрузку?
Ок. Есть партионка.
Тогда как происходит корректировка задним числом, которая «затрагивает только те данные, которые требуется»? Что будет если я месяц назад в документе спишу товар, который через неделю активной деятельности по этой товарной позиции вдруг окажется в минусе? Когда об этом узнает пользователь? Как это повлияет на движения документов, которые двигали эту позицию в эту неделю? Тот документ, которой я ввёл утром вдруг «откатится» и скажет, что «я не могу, товара нет»? а если за него уже деньги получили?
Хороший вопрос, жаль на него не дали ответа :(
Смотрите, в текущем типовом решении остаток в динамике не проверяется. Но текущий проверяется (то есть CONSTRAINT стоит на currentBalance), то есть если текущий остаток по какой-нибудь из партий уйдет в минус пользователь сразу узнает. Можно добавить CONSTRAINT и на balance на дату, но это уже оверхед. Для этого удобнее использовать отдельные процедуры перерасчета / до расчета. Правда если в конкретных логиках есть ограничения зависящие от партий какие-нибудь (например запрет продажи ниже себестоимости) могут быть вопросы. То есть в простых случаях система разрешит поменять задним числом, а если что-то пойдет не так начнет ругаться и требовать администратора.

Про «откатится» и «товара нет», не понял. Ограничения на новые изменения, старые тут причем?
Еще раз, поправьте меня, если я буду в чем-то не прав.
1) Есть таблица БД с тремя колонками:
Stock и SKU — в терминах 1С это «измерения регистра»
? некоторая колонка «количество» — в терминах 1С это «ресурс регистра».
Для данного ресурса вы задаете красивое и простое ограничение «quantityAvailable(Stock st, Sku sk) > 0;», что подразумевает, что по любой комбинации Stock и SKU не должно быть отрицательного остатка (ну и в контексте описанной).
Ок. Отлично.
В 1С такая проверка также делается 1 простым запросом, который вам приводился на стороннем форуме.
Но после этого начинаются интересные вопросы:
1) Как будет выглядеть проверка, если нужно контролировать остатки только по части складов/SKU? В 1С — добавляем условие в запрос, у вас — добавляем внешние функции с проверками, которые будут порождать дополнительный запрос (ну ок, у вас волшебный оптимизатор, который автоматически склеивает все в один запрос к БД).
2) Как будет выглядеть это ограничение, если нужно проверять не только «остаток не стал нулевым», а «остаток с учетом резервов не стал нулевым»? Опять же — в 1С мы редактируем все тот же запрос. А у вас?
Любопытно увидеть для вариантов «резерв это еще одна колонка таблицы» и «резерв, это колонка в другой таблице БД»?

И т.д. и т.п.
В 1С такая проверка также делается 1 простым запросом, который вам приводился на стороннем форуме.

В 1С это делается минимум 3 запросами на 1к строк. В статье это описано. Именно проверка что quantityAvailable >0, логика расчета (а точнее императивного обновления) quantityAvailable в 1С отдельно, ее в статье нет.
Как будет выглядеть проверка, если нужно контролировать остатки только по части складов/SKU? В 1С — добавляем условие в запрос, у вас — добавляем внешние функции с проверками, которые будут порождать дополнительный запрос (ну ок, у вас волшебный оптимизатор, который автоматически склеивает все в один запрос к БД).

Нет, добавляем в условие ограничения. Никаких внешних функций, о чем вы?
Как будет выглядеть это ограничение, если нужно проверять не только «остаток не стал нулевым», а «остаток с учетом резервов не стал нулевым»? Опять же — в 1С мы редактируем все тот же запрос. А у вас?

Редактируем условие ограничения:
CONSTRAINT quantityAvailable(Stock st, Sku sk) — quantityReversed(st, sk) > 0;
Вы реально не понимаете как это делается в lsFusion?
В 1С это делается минимум 3 запросами на 1к строк

Еще раз. В 1с это делается 1(!) запросом строчек на 10. Пример на Мисте лично я вам приводил. Это если мы говорим о простой табличке SKU|Stock|Quantity и таком же простом документе, без дополнительной логики.

Вы реально не понимаете как это делается в lsFusion?

Нет, это вы меня не понимаете, как мне кажется.
Как ваша платформа понимает, что делать когда вы пишете «quantityReserved(st,sk)»?
Как много таких «предопределенных» действий определено и как будет выглядеть условие, если мы выходим за рамки простой захардкоженной проверки по 1-2 реквизитам, а условие накладывается в зависимости от данных в других таблицах?

Если колонка Reserved находится в другой таблице, как платформа понимает, что quantityReserved нужно считать именно по ней?
Как ваша платформа понимает, что делать когда вы пишете «quantityReserved(st,sk)»?
Давайте попробуем еще раз на пальцах (насколько смогу). quantityReserved в данном случае в терминологии lsfusion называется «свойство». Свойство — это, грубо говоря, некоторая вычисляемая функция (как в математике), То есть какая-то штука, которая принимает на вход параметры, и возвращает значение, являющееся результатом некоторого вычисления. Только кроме логических, арифметических и т.п. операторов в lsfusion для вычисления есть еще операторы композиции, группировки, рекурсии и т.д.

Теперь вы хотите повесить ограничение на какое-то сложное вычисляемое значение. В lsfusion для этого значения вам нужно создать свойство (оно может быть создано и прямо в инструкции CONSTRAINT). То есть его нужно создать в любом случае, если хотите его вычислить, это и есть описание логики. Создаваться оно будет, как описывалось выше, в коде с помощью существующих операторов. quantityReserved в данном примере — это просто ранее объявленное свойство с соотвествующей логикой, вычисляющей то, что она должна по примеру вычислять.
quantityReserved в данном примере — это просто ранее объявленное свойство с соотвествующей логикой, вычисляющей то, что она должна по примеру вычислять.

Отлично. Мы вышли на финишную прямую.
Теперь повторю первоначальный вопрос: чем отличается «ранее объявленное свойство с соответствующей логикой», которое вы загоняете в CONSTRAINT от «объявленной ранее функции 1С ПроверитьОтрицательныеОстатки(Документ)», обращение к которой будет загнано в событие «ОбработкаПроведения»?

И там и там нужно заранее написать код. И там и там в нужном месте указать его вызов (да, я понимаю что у вас это не совсем «вызов метода», но с точки зрения трудозатрат программиста по нажиманию кнопок клавиатуры разница небольшая).
И там и там нужно заранее написать код

В lsFusion одну строку. А в 1С три запроса на тысячу строк. Если нет, приведите здесь, как должны были сделать разработчики типовых, чтобы это был один запрос.
Если нет, приведите здесь, как должны были сделать разработчики типовых, чтобы это был один запрос

Вас не смущает сравнение ограничения для таблички из 3 колонок в вашем примере и таблички в 10+ колонок (в силу добавления партий, характеристик и т.д.) в типовой УТ?

Еще раз привожу пример запроса, который проверяет наличие остатков в аналогичном вашему примеру (имена объектов метаданных специально сократил):
ВЫБРАТЬ *
ИЗ РегистрНакопления.ОстаткиТоваров.Остатки КАК Остатки((Склад, Товар) В (
Выбрать Товары.Ссылка.Склад, Товары.Товар
ИЗ Накладная.Товары КАК Товары
ГДЕ Товары.Ссылка = &Накладная))
ГДЕ РегистрОстатков.Остаток < 0;

Устраивает? Да, ваши quantityReserv будут (наверное) проще в написании в случае простых примеров (и совершенно не очевидно, что будут настолько же просты и немногословны, в случае более сложных условий), но и у 1С это не «3 запроса по тысяче строк кода».

Опять же, никто не мешает, для проверки простых условий, написать на 1С функцию isEqual(Объект, Поле, Значение) или isLess(Регистр, СтруктураИзмерений, Ресурс, ЗначениеРесурса) и использовать при проверках ее, а не писать руками запрос, повторив при этом то, что у вас на уровне ядра (подобные функции активно использовались разработчиками TDD и BDD движков для 1С).
Да, вероятно, при этом производительность будет ниже вашей системы, но уж точно решение не будет многословнее (а мы ведь тут топим за количество строк?).
Я не знаю, сколько раз можно писать одно и то же. В примерах 1С все делается красиво, а в УТ — через 1К строк кода. Есть конечно вероятность, что УТ разрабатывали идиоты. Но мне как-то кажется более вероятным, что просто решение из примеров дико тормозит, поэтому приходится так делать.

В lsFusion проверяется такое ограничение одной строкой как в примерах, так и в production системах с 1К+ одновременных пользователей.
Есть конечно вероятность, что УТ разрабатывали идиоты. Но мне как-то кажется более вероятным, что просто решение из примеров дико тормозит, поэтому приходится так делать.

Конечно, это ведь логично. Проверка с помощью одного запроса тормозит гораздо больше, чем проверка с помощью выполнения трех запросов. И нет, многословность не связана с дополнительной логикой, более сложной структурой таблиц (тоже возникшей не просто так) и другими нюансами, о которых точно могут сказать только разработчики типовых решений.

В примерах 1С все делается красиво, а в УТ — через 1К строк кода

Хотите сравнивать типовые решения — выкладывайте в свободный доступ свое ERP решение в полной обвязке из всех модулей. Тогда будем сравнивать функции/код решений.
Хотите использовать свои примитивные демо примеры с таблицами в 2 колонки — сравнивайте их с примитивными примерами на 1С.

В lsFusion проверяется такое ограничение одной строкой как в примерах, так и в production системах с 1К+ одновременных пользователей.

Я рад за LSFusion. Только надо понимать что такое эти ваши «1К+ пользователей» (что конкретно они делают), что из себя представляет железо и конкретное решение используемые у заказчика. Тогда и сравнивать.
Конечно, это ведь логично. Проверка с помощью одного запроса тормозит гораздо больше, чем проверка с помощью выполнения трех запросов. И нет, многословность не связана с дополнительной логикой, более сложной структурой таблиц (тоже возникшей не просто так) и другими нюансами, о которых точно могут сказать только разработчики типовых решений.

Ну вот, а в lsFusion один раз пишешь — и все оптимизируется само.

Хотите сравнивать типовые решения — выкладывайте в свободный доступ свое ERP решение в полной обвязке из всех модулей.

Любое сложное решение состоит из множества мелких. Это называется модульностью. Вот мы и обсуждаем эти маленькие кусочки.

Я рад за LSFusion. Только надо понимать что такое эти ваши «1К+ пользователей» (что конкретно они делают), что из себя представляет железо и конкретное решение используемые у заказчика. Тогда и сравнивать.

Все, что делают в розничных магазинах. Заказывают товар, списывают, формируют отчеты и выполняют все остальные процессы. Сервер один (но разбит на 2 виртуальные машины). 2 процессора Intel (за 5К каждый), 256ГБ памяти, SSD в RAID-10. В сумме с дисками сервер стоит около 15-20К.
Ну вот, а в lsFusion один раз пишешь — и все оптимизируется само.

Это сарказм? Оптимизируется само… слов нет… Оно само налоговую отчетность сдает? Или может фуру разгружает само?

Еще раз привожу пример запроса, который проверяет наличие остатков в аналогичном вашему примеру (имена объектов метаданных специально сократил):
ВЫБРАТЬ *
ИЗ РегистрНакопления.ОстаткиТоваров.Остатки КАК Остатки((Склад, Товар) В (
Выбрать Товары.Ссылка.Склад, Товары.Товар
ИЗ Накладная.Товары КАК Товары
ГДЕ Товары.Ссылка = &Накладная))
ГДЕ РегистрОстатков.Остаток < 0;

Еще раз, вы похоже не понимаете почему они так делают. Регистр которые они проверяют, может изменяться в куче разных мест, кучей разных способов, например там может изменяться только одна запись (при изменении одной записи в документе, они там руками дифф для этого строят). То есть к никакой Накладная.Товары нельзя обращаться, так как а) там этих видов документов изменяющих регистр могут быть сотни б) тогда ограничение будет проверяться для всей накладной, а не одной измененной записи. Поэтому делают вот так извращенно как написано в статье.

В lsFusion все вышесказанное делается автоматически. Платформа сама следит что изменилось, и запросы делает только для измененных строк и т.п.
То есть к никакой Накладная.Товары нельзя обращаться, так как а) там этих видов документов изменяющих регистр могут быть сотни б) тогда ограничение будет проверяться для всей накладной, а не одной измененной записи. Поэтому делают вот так извращенно как написано в статье.

Это вы похоже не понимаете.
1) У 1С контроль остатков реализуется на уровне прикладного объекта, который меняет остатки, а не на уровне таблицы остатков. В том числе, логика проверки для разных документов может быть различной, а для каких-то документов вообще отсутствовать. Поэтому вообще не важно сколько таких видов документов, это никак на сложность запроса не влияет.
2) Никто не мешает в качестве параметра в запрос передавать список товаров/складов для проверки, тогда можно один и тот же запрос использовать для разных документов.
3) Еще раз, не путайте сложную логику конкретного типового решения и принятые в нем стандарты кодирования и «в 1С нельзя сделать по-другому». Вы задали вопрос «как можно было бы написать на 1С аналог нашего quantityAvailable(st,sk)>0.

В lsFusion все вышесказанное делается автоматически. Платформа сама следит что изменилось, и запросы делает только для измененных строк и т.п.

Нет, не так. Платформа автоматически вешает проверки. Но логику проверок нужно писать разработчику. Как только логика проверок становится сложнее — разработчику приходится писать много кода.
Вы опять уходите от ответа. Я специально нашел изолированный пример в УТ (именно чтобы нельзя было сказать, что так делается для других целей). Вы сказали, что это можно сделать одним запросом, привели пример, но этот запрос не заработает, так как упадет потому что «Накладная» не найдена (а что вместо ее писать надо не понятно), плюс будет тормозить, так как будет ограничение для всех строк вычислять.
Как только логика проверок становится сложнее — разработчику приходится писать много кода.

Не надо будет. Это ваши додумки. Нужно просто чуть чуть изменить условие. Дописать +f(a) или AND NOT g(a).
Еще раз. В 1с это делается 1(!) запросом строчек на 10. Пример на Мисте лично я вам приводил. Это если мы говорим о простой табличке SKU|Stock|Quantity и таком же простом документе, без дополнительной логики.

А зачем разработчики типовых это делают 3-мя запросами. В lsFusion тоже самое делается одной строкой.
Как ваша платформа понимает, что делать когда вы пишете «quantityReserved(st,sk)»?

Еще раз, не путайте задание логики вычисления показателя (хотя и она в lsFusion гораздо проще) и логики ограничения на этот показатель. Я в статье сравнивал вторую часть.
Если колонка Reserved находится в другой таблице, как платформа понимает, что quantityReserved нужно считать именно по ней?

Что вы прицепились к этим таблицам. В lsFusion это все прозрачно, можете одной строкой переложить все в одну таблицу, а можете разложить каждый показатель в свою таблицу. Логика ограничений никак не поменяется.
А зачем разработчики типовых это делают 3-мя запросами. В lsFusion тоже самое делается одной строкой.


1) возможно, внутренние стандарты команды или 1С;
2) возможно, неотрефакторенная кодовая база от ERP (т.е. в ERP используется аналогичный запрос, но делаются дополнительные проверки);
3) возможно, legacy или говнокод;
4) еще масса причин, которую точно смогут сказать только авторы конкретной типовой.

Нет, исходя из ответов на другие мои комментарии не одной строкой. Само свойство quantityAvailable(st,sk) «описывается ранее».
Я уже устал повторять, что мы сравниваем не задание логики quantityAvailable (хотя и это сравнение далеко не в пользу 1С), а логику проверки, что этот показатель больше 0. И вы так и не написали, как должны были это делать разработчики типовых. Что где и когда проверять.
Я уже устал повторять

А я устал повторять, что вы сравниваете ужа и ежа.
Вы берете свой демо пример, который с точки зрения бизнес-логики соответствует местами решению из книжки «1С за полчаса для самых маленьких» и сравниваете количество кода в нем с одним из наиболее «навороченных» решений от 1С, которое на рынке уже много лет (т.е. обросло функциями и legacy).
Ну возьмите ERP в части оптовой и розничной торговли (а не производства БУХ и ЗУП) и сравните. В lsFusion ERP есть многие вещи которых у УТ нет даже близко (впрочем обратное тоже верно). Но вы сложность сравните и посмотрите реальный живой код и коммиты (они на гитхабе есть). И там реально все делается CONSTRAINT'ами и событиями.
Ну так и сравните, с удовольствием почитал бы.
На примере сопоставимых по сложности бизнес-задач. С учетом тех проблем и задач, которые решает 1С, а вы вывели на внешние системы (безотносительно того, правильный у вас подход или нет, но часть задач вы со своей платформы просто сняли и это очевидно повлияло на сложность прикладного кода и платформы).

Пока что же, происходит подмена понятий.
Я же не пишу статью «зачем в XLS добавили макросы, вон у 1С есть маханизм табличных документов, макросов нет и пользователям не нужно».
Так вы же скажете, что мы неправильно на 1С решаем задачу. Напишите все-таки решение задачи на 1С из вот этой статьи. Вот и сравним.
Данную задачу разработчикам 1С не нужно решать с переходом на платформу 8.3.11, там появился встроенный механизм истории данных, который можно крутить программно как хочешь. И вроде даже еще в БСП второй редакции была самописная подсистема версионирования, но ее сейчас актуализировали под платформенный механизм.
Там механизм версионирования — это по сути логирование только первичных данных и только целиком как в Confluence. То есть к приведенной статье никакого отношения не имеет.
В различных приложениях регулярно возникает задача по поддержке логики изменения во времени некоторого атрибута объекта относительно некоторого субъекта (или субъектов). Например, это может быть изменение розничной цены товара в магазинах или показателей KPI для сотрудников.

Тогда не понимаю, в чем предмет гордости механизмом вашего продукта? Вы сами в статье упоминали регистры сведений, периодические изменения именно там и реализовываются.
Так покажите, как это делается. Только именно с группами складов как в статье. И чтобы при изменении группы склада все менялось автоматически. Будет проще чем в lsFusion с 150 строками кода?
Не понимаю вашу страсть к количеству строк кода =) Я сам разработчик 1С, и прочитав статью уже примерно вижу решения и совсем не вижу проблемы. Ну будет у меня 5 запросов и 500 строк кода, в чем проблема то? В 1С я сделаю необходимую задачу бизнесу быстро и в срок, а за синтаксическим сахаром или красивым кодом вечером сяду в питоне покодить. Или уже написанный код в 1С отрефакторю, что бы в 300 строк уложиться.
А зачем разработчики типовых это делают 3-мя запросами. В lsFusion тоже самое делается одной строкой.

Потому что:
1) В случае изменения документа остатки проверяются только по тем товарам, по которым есть изменение.
2) Там контроллируется в том числе ситуация вида "убрали товар из прихода и после этого по нему появился отрицательный остаток" (контроль в приходных документах).

Я то это знаю. Вы это Ta_Da обьясните.

Т.е. я правильно понял, что в lsFusion аналогичный описанному мной контроль делается одной строкой?

Да, только Ta_Da то ли понять, то ли признать этого не хочет.

Т.е. контроллируются только те строки документа, в которых изменилось количество, верно? А если нужно контроллировать все?
Собственно вопрос к чему: в случае 1С можно написать абсолютно любой алгоритм — пусть местами и монструозно, но можно. А как у вас?
Всё равно ведь эта логика где-то должна быть описана, чтобы потом проверять её одной строчкой — и не факт что это описание будет проще. Хотя, повторюсь, lsFusion я не знаю от слова "совсем", возможно и ошибаюсь.

Не совсем понял. Вы пишете CONSTRAINT любой сложности. Платформа сама все контролирует, изменилась одна запись, проверит для одной. Изменились все для всех. Изменились любые данные, проверит только для этих данных. Вы его не обойдете. То есть такой CONSTRAINT как в СУБД только без ограничений, что одна запись одной таблицы. И вообще без каких либо ограничений.
и не факт что это описание будет проще.

Оно по определению проще, так как вы просто условие задаете. Декларативное правило. Не знаю как еще объяснить. А дальше не ваши проблемы.
Не знаю как еще объяснить.

На примере может быть? Допустим, возьмем тот же склад. Учет ведется в разрезах: Организация, Склад, Партия. Нужно контроллировать, что по сочетанию "Организация-Партия" мы не уходим в минус. Т.е. при контроле остатков — склад не учитывать.

Как-то так:
balance(Organization o, Stock s, Batch b) = GROUP SUM ...; (ну или income(o,s,b) — outcome(o,s,b))

balance(Organization o, Batch b) = GROUP SUM balance(o, Stock s, b);
CONSTRAINT balance(Organization o, Batch b) < 0 MESSAGE 'Остаток должен быть положительным';

Вот тут пример простого склада если интересно, чтобы понимать как это приблизительно выглядит.

Ну или вот как это выглядит в продакшне.

Ага, примерно понял. Выглядит интересно.
Ещё два вопроса:
1) Я правильно понимаю, что при вводе, например, расходной накладой — строки записываются сразу, и сразу списывают товар со склада? Или все-таки записываются потом, по условной кнопке "Провести"? Если второй вариант — то описанная проверка остатков получается по факту выполняет запросы в цикле?
2) Прочитал ещё другую статью где описывали про "движения по регистрам" если брать терминологию 1С. Не совсем понял как при этом реализовать, например, "сворачивание" строк — т.е. если в накладной несколько позиций с идентичным товаром, то как получить в регистре только одну запись?

Я правильно понимаю, что при вводе, например, расходной накладой — строки записываются сразу, и сразу списывают товар со склада? Или все-таки записываются потом, по условной кнопке «Провести»? Если второй вариант — то описанная проверка остатков получается по факту выполняет запросы в цикле?

Сразу в той же транзакции. Но никто не мешает писать:

isPosted = DATA BOOLEAN (Document);
income = GROUP SUM quantity(InvoiceDetail i) IF isPosted(invoice(i)) BY stock(invoice(i)), sku(i);

И тогда income и balance будут обновляться когда например будет isPosted установлено в true. Ну или сразу если документ вводится проведенным.

Запросы в цикле никогда не выполняются, все компилируется в минимальное число запросов, независимое от количества записей.
Прочитал ещё другую статью где описывали про «движения по регистрам» если брать терминологию 1С. Не совсем понял как при этом реализовать, например, «сворачивание» строк — т.е. если в накладной несколько позиций с идентичным товаром, то как получить в регистре только одну запись?

Можно взять сделать
quantity = GROUP SUM quantity(InvoiceDetail i) BY invoice(i), sku(i); // свойство (функция) получится с двумя параметрами Invoice, Sku

А дальше генерим SkuLedger.
// для всех quantity не NULL генерим объекты класса InvoiceSkuLedger
CLASS InvoiceSkuLedger: SkuLedger;
invoiceLedger(Invoce invoice, Sku sku) = AGGR InvoiceSkuLedger WHERE quantity(i, s);
// прописываем реализации абстрактных свойств
sku(InvoiceSkuLedger i) += sku(i);
stock(InvoiceSkuLedger i) += stock(invoice(i));
Запросы в цикле никогда не выполняются, все компилируется в минимальное число запросов, независимое от количества записей.

Т.е. в данном примере при установке флага isPosted у Invoice система "увидит" что он влияет на InvoiceSkuLedger, и сгенерирует на все строки один запрос UPDATE который обновит остатки?


Если так то выглядит необычно — это вы по факту определяете граф зависимости данных и пересчитываете его?

Т.е. в данном примере при установке флага isPosted у Invoice система «увидит» что он влияет на InvoiceSkuLedger, и сгенерирует на все строки один запрос UPDATE который обновит остатки?

Грубо говоря да. Там скажем два запроса может быть, но смысл в этом.
Если так то выглядит необычно — это вы по факту определяете граф зависимости данных и пересчитываете его?

Очень упрощенно, но да. Строится граф событий / материализаций, которые при изменении записи запускаются / обновляются. С кучей оптимизаций естественно.

Ага, отлично.
Ещё вопрос — в документации вижу возможность писать обычный Java-код, но не совсем понял область применения.
Например, есть ли возможность сделать записи "из ничего", в смысле обычным императивным кодом. Пользователь нажал кнопку "Сделай мне хорошо", система выбрала через SQL что-то, дальше посчитала как-то, выдала пользователю таблицу, он руками исправил как считает нужным, нажал "Записать" и система записала их ещё куда-то. Ну или без отображения пользователю — просто посчитать и записать.


Вобщем, есть ли обычное императивное программирование? Можно ли "мешать" код lsFusion и Java в одной форме, например?

Смотрите, за императивный код отвечают действия. Там есть операторы изменения, показа форм и т.п. Java код подключается как:
myAction INTERNAL 'my.MyAction';
И дальше используется как обычное действие на lsFusion. То есть да можно мешать, строго говоря при выполнении между ними нет разницы, они все в одной JVM.

Область применения — нестандартные задачи, как например симплекс метод или какие-то супер сложные интеграции, которые не решаются обычными HTTP запросами с JSON'ами и XML'ами (это все можно на lsFusion делать).

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

Хочу добавить к предыдущему ответу, что в любом случае в lsfusion никто не отбирает возможность создавать руками события и добавлять обработчики на эти события.

А не надо в регистр пихать бизнес-логику. Мало того, что контроль при списании — штука для сугубо простых случаев, а в том же классическом партионном учете, например, все делается наоборот — сначала формируется дерево остатков по партиям, а потом уже по нему мы списываем по фифо, лифо, фефо и как ещё нужно в целом от бизнес-потребности. Так ещё и в 1с нет аудиторского следа, поэтому проведение задним числом — норма жизни, и только регистратор "знает", где контроли нужны, а где совсем нет.

А самое главное — совершенно непонятно, зачем в небутиковой рознице нужен контроль остатков :) А уж если этот контроль реализован во фронте — это просто очень здорово :)
А… речь про это… Извините, из слога автора сразу не понял, так как предыдущие его посты не читал.

Что-то не думаю, что внутри его процедура isWarehouseN менее монструозна, чем в 1С, если речь идёт хоть о какой-то минимально сложной проверке.
Что-то не думаю, что внутри его процедура isWarehouseN менее монструозна, чем в 1С, если речь идёт хоть о какой-то минимально сложной проверке.

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

Ну т.е. идет сравнение ужа с ежом:
— простые встроенные в платформу проверки из lsfusion, которые быстро превращаются в цепочку вызовов неизвестных внешних процедур, как только проверка становится сложнее чем «проверить чтобы не ноль».
— сложные проверки с кучей условий, написанные в одном из типовых решений на 1С.

Да, если бы такие ограничения были встроенными в платформу, наверное было бы полезно. Но на практике, я могу вспомнить буквально пару-тройку случаев, когда такой простой проверки бы хватило для решений, которые я разрабатывал/поддерживал.
Вероятно, той же логики придерживались и разработчики платформы.

Можно считать это синдромом утенка или чем угодно, но если абстрагироваться от «круто было бы, если бы в платформе было все что только можно придумать», примерной аналогией будет карандаш с ластиком на конце. Да, удобно, но на практике все равно в комплект к нему нужно покупать нормальный.
А давайте вы на 1С сделаете пример вот отсюда. Там всего 150 строк кода и у нас ушло на это час где-то. Давайте такой же на 1С и сравним. Чтобы не быть голословными. Там всего одна форма.

Ушло где-то 10 минут. Вот весь код, который написал.


Процедура ОбработкаПроведения(Отказ, РежимПроведения)
    Движения.ЦеныСкладов.Записывать = Истина;

    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   ПрайсСклады.Ссылка.ДатаНачала КАК ДатаНачала,
        |   ПрайсСклады.Ссылка.ДатаОкончания КАК ДатаОкончания,
        |   ПрайсСклады.Склад КАК Склад,
        |   ПрайсТовары.Товар КАК Товар,
        |   ПрайсТовары.Цена КАК Цена
        |ИЗ
        |   Документ.Прайс.Товары КАК ПрайсТовары,
        |   Документ.Прайс.Склады КАК ПрайсСклады
        |ГДЕ
        |   ПрайсСклады.Ссылка = &Ссылка
        |   И ПрайсТовары.Ссылка = &Ссылка";

    Запрос.УстановитьПараметр("Ссылка", Ссылка);

    РезультатЗапроса = Запрос.Выполнить();

    ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
    Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
        ЗаполнитьЗначенияСвойств(Движения.ЦеныСкладов.Добавить(), ВыборкаДетальныеЗаписи);
    КонецЦикла;
КонецПроцедуры

Еще минут за 10 прикручу отчет на скд, который будет для конкретного склада, на конкретную дату делать прайс. Сколько времени это займет у вас?

Дайте код всего приложения, пожалуйста. И где здесь группы складов? И как обрабатывается, когда склад переходит в другую группу? И мне нужен не отчет, а форма, где можно добавлять прайсы и смотреть текущие значения. Давайте уходить от «1С головного мозга» и делить все на отчеты/документы/проведение.

И что значит:
Сколько времени это займет у вас?

Там в статье весь код. Абсолютно. Просто вставляете в try online и наслаждаетесь.
Мы вам уже на это не один раз отвечали, что логика в CONSTRAINT может быть абсолютно любая, то есть вы можете повесить ограничение на любое вычисляемое свойство. Мне, например, непонятно, что именно вам непонятно в слове «любая»? Вот все, что сможете на нашем языке (полном по Тьюрингу) изобразить, на все и можно будет повесить одной строкой кода.
простые встроенные в платформу проверки из lsfusion, которые быстро превращаются в цепочку вызовов неизвестных внешних процедур
Вы столько уже написали в обсуждениях нашей платформы, но до сих пор не поняли, что никаких «процедур» в обсуждаемом контексте у нас нет.
Вы столько уже написали в обсуждениях нашей платформы, но до сих пор не поняли, что никаких «процедур» в обсуждаемом контексте у нас нет.

Детский сад, штаны на лямках.
Что скрывается за «quantityAvailable(Stock st, Sku sk) > 0»?
Что такое «quantityAvailable»? Функция? Процедура? Оператор?

Для любого существующего во вселенной условия у вас уже есть встроенный оператор(процедура, функция) вида «Condition42()» или для сложной бизнес-логики придется писать свой оператор(процедуру, функцию)?
Вы понимаете разницу между декларативной и императивной логикой? Процедура — это последовательность выполнения команд. Так вот в lsFusion нету никакой последовательности команд при задании, например, остатка.
Вы так и будете уходить от конкретных ответов съезжая на вопросы терминологии?
Так, а какой вопрос то? В lsFusion ограничение на остаток делается одной строкой (см. статью про регистры). В УТ это делается через мозгодробильный приведенный выше код (да, я понимаю, что УТ писали идиоты, которые не следует рекомендациям платформы, и у них есть какая-то тайная причина так делать).
Так, а какой вопрос то?

Перечитайте мои комментарии в этой ветке. Участки текста, которые начинаются с большой буквы и заканчиваются знаком "?" — называются вопросами. Пожалуйста, ответьте на все или часть из них.

Для простоты добавлю ссылки на комментарии:
habr.com/ru/company/lsfusion/blog/468415/#comment_20698057
habr.com/ru/company/lsfusion/blog/468415/#comment_20698375

Мне казалось, что мы тему с регистрами и остатком обсосали уже в предыдущей статье про регистры. Не увидел ни одного нового вопроса по сравнению с теми обсуждениями.

Когда вы задаете вопросы «Что скрывается», то Вы сами переходите на обсуждение терминологии.

Это не детский сад. Термин «процедура» подразумевает императивное выполнение, которого там нет. И это просто маркер недопонимания.

А давайте просто скажем, что есть 1С, продукт, который закрыл большой рынок и реализовал многие потребности и простоту для клиентов в свое время и никто до сих пор этого не повторил.
Давайте сделаем хоть минимального конкурента и тогда скажем что 1С не торт.
Я сам в прошлом программист 1С и мне многое не нравится, то блин, крутых программистов куча вокруг, но никто не решил сделать хорошего конкурента.
и никто до сих пор этого не повторил.


lsFusion не только повторил, а и перегнал на целое поколение. Да решения пока сейчас с фокусом на FMCG розницу и оптовую торговлю, но это вопрос времени.
UFO just landed and posted this here
В 1С отчеты еще зачем-то пытаются выполнять функции обычных форм (то есть обладают интерактивностью)
Если вы про отчеты обычные, то интерактивность в виде расшифровок очень полезная штука. А если про регламентированные отчеты, (которые и заполняются по данным бух. учета и имеют возможность ручного ввода) так это просто находка для бухгалтера! Это я вам как бухгалтер говорю.
Это я к тому, что отчеты в 1С зачем-то пытаются использовать для задач, для которых они не предназначены. Расшифровку куда проще сделать на формах, зачем тянуть этот функционал в печатные формы?

Бухгалтерия и прикладные абстракции бухгалтерии (!) в платформе это отдельная тема.
Это я к тому, что отчеты в 1С зачем-то пытаются использовать для задач, для которых они не предназначены.

А как же ваше непоколебимое заверение «пользователи хотят как в excel»?
Ну и пример можно — «задач для которых они не предназначены»?
И кстати, исходя из какой логики вы считаете что «не предназначены»?

Расшифровку куда проще сделать на формах, зачем тянуть этот функционал в печатные формы?

Вот вы опять. Не «печатная форма», а «табличный документ». Который действительно может быть «печатной формой» («бланк договора», «бланк накладной», «этикетка») — и в таких случаях расшифровка не используется и никакой интерактивности (больше чем «разрешить внести изменения/изменить параметры печати») обычно не добавляется, и «выходная форма отчета», в которой в качестве «расшифровки» и «интерактивности» предполагается переходы к более детальным отчетам, открытия форм документов/справочников, упомянутых в отчетах и т.д. И, внезапно, добавляется это обычно по просьбе пользователей.
А как же ваше непоколебимое заверение «пользователи хотят как в excel»?

Ну так для этого формы надо использовать.
Ну и пример можно — «задач для которых они не предназначены»?

В теме про подбор люди предлагали отчеты использовать для реализации WYSIWYG интерфейсов ввода.
И кстати, исходя из какой логики вы считаете что «не предназначены»?

Потому что для работы с информацией, которую не надо печатать, есть формы.
«табличный документ», «выходная форма отчета»

Это опять таки какие то странные очередные дырявые абстракции 1С. Непонятно зачем нужные, когда есть формы. И ни в одной другой технологии их нет.
Ну так для этого формы надо использовать.

*ирония* Получается, что когда 1С не дает редактировать данные в динамических списках, то это минус 1С. Когда у вас нет возможности (при необходимости!) использовать для интерактивной работы табличный документ — это все равно недостаток 1С?

В теме про подбор люди предлагали отчеты использовать для реализации WYSIWYG интерфейсов ввода.

Потому что для работы с информацией, которую не надо печатать, есть формы


В теме про подбор, вами (возможно, не лично, а кем-то из коллег), утверждалось, что подбор «как в excel» реализовать невозможно. Вариант с табличным документом приводился как один из возможных вариантов реализации, причем в номинации «ну если хотите, можно и так извратиться».

Непонятно зачем нужные, когда есть формы. И ни в одной другой технологии их нет.

Не совсем понимаю вас. Есть возможность использовать табличный документ как простую неинтерактивную форму.
Есть возможность, навешивать на табличный документ события и работать с ним интерактивно.
В чем проблема-то у вас? Не нравится — не используйте. У меня пользователи просили реализовать им интерактивность в печатных формах. Не вижу в этом проблемы.
*ирония* Получается, что когда 1С не дает редактировать данные в динамических списках, то это минус 1С. Когда у вас нет возможности (при необходимости!) использовать для интерактивной работы табличный документ — это все равно недостаток 1С?

Я не знаю, что такое табличный документ. Это какой-то плод больной фантазии одного из разработчиков 1С. Есть формы. Зачем нужна вторая абстракция?
Я не знаю, что такое табличный документ. Это какой-то плод больной фантазии одного из разработчиков 1С. Есть формы. Зачем нужна вторая абстракция?

Табличный документ — это свой велосипед 1С, который они написали для того чтобы не привязываться к Excel. Так же как и файловая база у них появилась, когда использование SQL не планировалось.
Вы поступили проще — взяли готовые решения.
Надо будет кстати про табличный документ в избыточные абстракции дописать. Не лень будет, сделаю, спасибо :)
Надо будет кстати про табличный документ в избыточные абстракции дописать

Непонятно только, что вы этим докажете. Ну т.е. у вас большая часть статей идет с позиции «в 1С вот этого нет, а у нас есть».
А тут, внезапно, что-то есть у 1С и нет у вас. Но это опять оказывается недостатком 1С.

Еще раз: там где 1С исторически позволяла не использовать сторонние продукты (т.е. платить только за лицензии 1С), с помощью своего движка табличных документов и своей файловой СУБД, вы предлагали заказчику купить EXCEL и SQL (ну или не предлагали купить, но подразумевали что у него эти продукты уже установлены).
Называть это недостатком 1С и преимуществом LSFusion, по моему мнению, странно.
UFO just landed and posted this here
Я согласен, что расшифровку проще делать на форме, но форму не распечатаешь. А труд бухгалтера включает в себя подготовку неких отчетов. Подготовка эта состоит из следующих шагов, формируем к примеру, «оборотку», глаз цепляется за некую незнакомую цифру. Кликаем в неё (прямо в цифру), формируем «карточку счета», пробежав по карточке глазами понимаем что все в порядке, закрываем карточку, печатаем «обротку». Здесь нет места дополнительным формам, настройкам и кликам, механизм расшифровок именно так и должен работать.
Сталкиваюсь с 1с только как админ, win+mssql, linux+postgres, только серверная часть.
По моему скромному опыту, 70% проблем (тормоза, зависания и т.д.) решаются регулярным перезапуском сервисов. Что как бы намекает нам на не самый лучший код этих самых сервисов.
Остальные 30% — надо просто потерпеть и дождаться не кривого релиза.
Сорри, если кого обидел.
UFO just landed and posted this here
Черт с ним с lsFusion, он только пару месяцев назад на рынок вышел, но любая из связок .Net+MSSQL или Python+PostgreSQL будет уж точно не хуже.


Сколько программистов, времени и денег нужно, чтобы написать аналог УТ на .net + mssql? Со всеми документами, отчетами, печатными формами?
Может ли небольшое торговое предприятие позволить себе такие затраты? И главное, зачем?
Подумайте лучше, почему САП покупают. Он дороже 1с во много раз, монструознее на порядок, а язык еще более убог.
Вот народ. Вы статью читали? Я писал про специализированные решения и самописки.
Любая ут постепенно превращается в самописку, никто ее не обновляет, как бухгалтерию. Но взять ее за основу гораздо быстрее, чем писать с нуля на дотнет.
UFO just landed and posted this here

Продолжаю свой коммент https://habr.com/ru/company/lsfusion/blog/468415/#comment_20697189 теперь по существу сказанного Автором статьи


По пунктам


Объекты: Справочники, Документы и т.д.

"Отображением на таблицы разработчик никак не управляет, и вообще оно скрыто от него (хотя ничего особенного в нем нет)" — ну то есть и претензий нет и спорить не о чем


"Никаких one-to-many, many-to-many отображений нет" — ну это же не SQL база данных. Почему они должны там быть?


Неэффективное получение данных объектов


Автор рассматривает насколько я понял выборку в стиле ранних версий 1с Пока Выборка.Следующий() Цикл. В то время как еще с версий 7.7 можно все выбирать запросами аналогичными SQL.


Таблицы / Представления: Регистры


Регистры представляют движок для получения итогов без необходимости пересчета всех записей. По логике рассчитанный раннее итог + итог за расчитанный период. При этом выборка итогов за последний год и за последние 20 лет будет примерно одинакова.


"Регистры поддерживаются в очень частных случаях"


Они для этого и предназначены (итоги)


"Отсутствие ограничений и событий для значений регистров"


В чем недостаток? Их там просто нет. Почему это фатально? Регистр чекается при проведении документа. Если условие нарушается документ не проводится.


"В параметрах виртуальных таблиц можно использовать только константы"
В этом разделе есть замечание: "Ну или находить минимум / максимум дат и высчитывать остатки и обороты. В любом случае оба этих способа как неудобны, так и не производительны одновременно." — для остатков и оборотов есть регистры.


Запросы
    Запросы в строках
    Отсутствие оптимизатора запросов

"1С также поддерживает свою файловую СУБД и PostgreSQL, которые работают по принципу «что вижу, то и выполняю»." Файловую практически систему не используют. Против отсутствия оптимизации в PostgreSQL думаю будут возражать те кто с ним работает.


    Отсутствие расширенных SQL возможностей

Ну и что?


    Отсутствие запросов на изменение

Нужно сначала поверить что запросы на изменение это добро а их отсутствие это зло. Я бы сказал, что наоборот.


    Отказ от автоматических блокировок

Ну и что? Вы считаете что при открытии документа он должен сразу блокирвоаться? Так было в версиях 7.х когда не было большого количества квалифицированных разработчиков. Сейчас это нужно делать явно.


Формы
    "Отказ от единого потока выполнения: разделение логики на сервер и клиент"

Я бы переформулировал. Это возможность разделить логику на клиентскую и серверную. Решение об отказе от одного или другого вариант решает разработчик.


    Отказ от синхронности

"Поэтому, чтобы, например, показать диалог, 1С приходилось создавать новое окно (вкладку) браузера, что, в свою очередь" — не уверен что в браузерном расширением работают большинство пользователей.


    Отказ от WYSIWYG: разделение интерфейса на запись и чтение

— Невозможность обращаться в списках к реквизитам форм / текущим значениям других списков
Избыточные уровни абстракций

-


Закрытая физическая модель

Я бы переформулировал. Разработчику 1с даны все необходимые для разрвботки средства без необходимости обращаться к физической модели базы данных. Параллельно даны широкие возможности для интеграции своих модулей


Отсутствие наследования и полиморфизма

-


Отсутствие явной типизации в коде

-


Отсутствие модульности

-


Ставка на визуальное программирование
Спорно. Я бы переформулировал. Используя визуальное программирование можно сделать очень много. Практически все что нужно в обычном случае. Для нестандартных случае есть интерфейсы для разработки кастомных модулей.


По бизнес-части комментирвоать не буду. Действительно если бы не было 1с у отечественных разработчиков был бы дополительный плюс для автоматизации бизнеса.

Спорно. Я бы переформулировал. Используя визуальное программирование можно сделать очень много. Практически все что нужно в обычном случае


А вас не смущает, что в самых популярных фронтенд технологиях для разработки GUI(!!!) React и Angular все делается кодом, а не визуальным программированием? Визуальное программирование — это для настроек максимум. Для промышленной разработки с ним больше проблем, чем преимуществ. Опять же напоминаю про gitflow.

Не смущает. Потому что благодаря визуальному интерфейсу я мог бы на 1с сделать автоматизацию работы подразделения на предприятии на котором работал 20 лет назад за два дня. А на React, если бы он тогда был — делал бы пару месяцев.

Кроме разработки есть еще и поддержка. А она в визуальном программировании та еще боль часто. Особенно на командах больше 10-20 человек. Особенно спустя время.
Так я же не отрицаю, что для примитивных случаев визуальное программирование подходит. Но не для промышленного с большим количеством функционала и разработчиков.

Экономические данные на предприятиях в большинстве случаев имеют алфавитно-цифровой формат. То есть в известном смысле являются примитивными.


Единственная нетривиальная задача, которая может решаться в рамках экономических данных — это вот та самая задача Джонсона (или как сейчас говорят MES, ASP) о которой я уже упомянул выше и которую 1с не решает и это ее действительный недостаток.
Но если бы она решалась, то ее решение было бы преимущественно не рисованное в интерфейсе а написанное текстом, возможно отдельным нативным модулем.


И в этом случае 1с (или не 1с) можно было бы продавать за миллиарды вне зависимости от прочих достоинств и недостатков.

Такое ощущение, что то, что вы написали — просто сгенерированный псевдонаучный текст. К сожалению, даже не знаю, что на него ответить, и какое это имеет отношение к промышленной разработке бизнес-приложений.
Ну а мы бы кодом сделали за полдня. Я не пойму, вы статью читали? Там все по пунктам. Почему вдруг мышкой должно быть быстрее чем клавиатурой?
В 1С можно и кодом сделать, в чем проблема?
Честно говоря не знаю, как это комментировать. Вы либо не читали статью, либо совсем ее не поняли.
UFO just landed and posted this here
Для меня 1С остался чем-то из давно забытого, что я не трогал более 20 лет… Сейчас вот опять пришлось и получается, что найти исполнителя очень сложно. Кто-то может подсказать почему?
Так, вроде, очевидно, почему — задача нетиповая за 1000р/час. Одинесники такого не любят :))
Для меня 1С остался чем-то из давно забытого, что я не трогал более 20 лет… Сейчас вот опять пришлось и получается, что найти исполнителя очень сложно. Кто-то может подсказать почему?


Так, вроде, очевидно, почему — задача нетиповая за 1000р/час. Одинесники такого не любят :))


Этого никто не любит за копейки.
То же самое можно сказать про веб — CMS вам поднимут за дешево, но если вы хотите по ставкам оплаты как за CMS создать настоящее полноценное веб-приложение с нуля — то за ту ставку что CMS не найдете вменяемого специалиста.

По мне так — там рядовая работа.
Просто на не том сайте ищут.

Но, должен отметить, что это, действительно слишком дешево.
Так как работа на стыке технологий.

И те, кто освоили этот стык — зарабатывают уже больше, чем обозначанная сумма.

Если бы я был заказчиком в этом проекте и хотел бы сэкономить — я бы нашел разных людей на разные части проекта.

Платить же «регулярно за поддержку и обслуживание» человеку, которые может это все корректно настроить — слишком расточительно, если у фирмы такие бюжеты.
Рядовая для того, кто это уже хотя-бы один раз делал. Но есть подозрение, что тот, кто что-то такое уже делал, за 1000 в час работать не будет.
Написал я тут одинокий коммент из отпуска, а тут целая дискуссия ;) Отвечу в Вашем комментарии как-то в общем… На самом деле ценник 1000 руб/час был совершенно взят «с потолка». Такой предложил первый исполнитель нам сам еще в первой итерации «цена договорная». И мы готовы были двигаться в любом направлении. Никакого фидбека на тему «слишком мало платите» или «согласен, но хочу столько-то» — не последовало. ОК. Сделал заказ с договорной ценой. Сомневаюсь, правда, что проблема была в этом.

Что касается демагогии на тему того, что «стык стеков» и т.п. Прочитайте, пожалуйста, сами задание. Мы сами достаточно немаленькая IT-структура. У нас свой кастомный кластер на базе Proxmox (нам не нужна помощь в его настройке), свой AD-сетап и т.п. Мы выдаем готовые виртуалки и просим на них поставить и настроить 1С. Все, что касается остальных стеков мы делаем сами.
Если вопрос не в деньгах, зачем вы ищете удалёнщика, а не обратитесь к организации с соответствующими компетенциями? Вот, например, ребята что-то похожее делали cloud.yandex.ru/blog/posts/2019/09/1c-proton
По организационным и географическим особенностям.

Организационное: 1С для нас лишь капля в море — 1% от тех услуг, которые мы предоставляем материнскому холдингу. Нам не нужен корпоративный субподрядчик. Текущий сетап (после основной настройки) успешно поддерживается вообще местным московским сисадмином. Если не разводить ню-ню и не надувать пузыри, то я не вижу в чем проблема обслуживать тоже самое удаленно, по необходимости, уже в рамках предложенной нами модели. Мы сами успешно деплоим весь корпоративный софт, в т.ч. сложные ERP типа SAP/DATEV из Германии хоть даже в Гонконг. Все работает через Application Delivery. И поддерживаем, удаленно, да.

Географическое: мы вообще сидим в Германии. Тут со специалистами 1С как-то так себе ;)
Это всё понятно, непонятно, почему вы считаете, что организация точно так-же, как фрилансер, по удалёнке не сможет решить вашу задачу?
Тем, что наш опыт показывает, что это банально неэффективно и чревато проблемами. Особенно и очень особенно в этом секторе. На практике задачу выполняет все равно один человек, в лучшем случае два человека. Над ним ставится Х «менеджеров» (Х выбрать по вкусу жирности конторы).

Коммуникация с конечным исполнителем, в итоге, усложняется и искажается пропорционально Х. Обрастает ненужными нам услугами, сложными юридическими нюансами и бесконечными конференц-коллами. Это энтерпрайз в том месте, где мы его не хотим.

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

Вставать на обслуживание кому-то в контору на полный стек — да. Мы сами такое предоставляем, фактически. Просто поставить и настроить 1С на готовый кластер, который обслуживает уже своя квалифицированная команда, а потом решать проблемы по необходимости — нет, спасибо. Мы хотим законтрактить непосредственно исполнителя, платить ему справедливо, но иметь «доступ к телу».
Странные вы, по ссылке, которую я приводил выше, именно такая работа — получили задачу от клиента, решили её, получили оговорённую оплату и ждут следующих задач. Далеко не во всех компаниях такая бюрократия, как вы описываете. Подозреваю, что всё-таки денег сэкономить хотите.
Не настаиваю, конечно. Увидел непонятное для себя, пытаюсь разъяснить.
UFO just landed and posted this here
Это не уровень 1С эксперта по технологическим вопросам. Данная задача решается тремя специалистами:
1. Системный администратор — настройка авторизации, запуск сервера приложений на linux, запуск web-сервера для сервисов 1С на чем-нибудь (как вариант linux), установка сервера баз данных. С учётом количества баз, сервер приложений и, скорее всего, веб-сервер должен быть не одинок, т.е. имеем кластер. Также возможно потребуется разносить базы по серверам БД, ибо иопсы и утилизацию ЦПУ и net никто не отменял. Т.к. все это хозяйство будет искрить и переливаться всеми цветами радуги, требуется система мониторинга, хотя бы по основным параметрам.
2. Dba для PostreSQL. Ну или хотя бы человек, который представляет, какие ручки там крутить, с учетом, что 200 баз, некоторый бардак и резервное копирование никто не отменял.
3. И, наконец, программер 1С, который должен будет переписать функционал COM на веб-сервисы; совместно с системным администратором придумать, как обеспечить работу Астрал, не вывалившись в него; совместно с DBA добиться приемлемой производительности ( минус 20% от MS SQL) и разгрести некоторый бардак, попутно создав новый. Причем работа всех этих специалистов будет проходить в режиме «давай-давай».
Поэтому вхождение в предлагаемую задачу без предварительного обследования и проектирования конечной системы можно характеризовать классическим «Слабоумие и отвага». Стремление посадить на эту задачу удаленщика — не менее классическим :" не гонялся бы ты поп за дешевизною".
UFO just landed and posted this here
Хм. Т.е. если жадный и некомпетентный заказчик будет искать себе java разработчика за тарелку супа, то это признак того что java — говно?
Примечательно, что в описанном случае заказчик себе исполнителя так и не нашел.
UFO just landed and posted this here
Когда заказчики массово начнут искать java разработчиков за тарелку супа, значит да, это будет значить, что джава превратилась в говно, и никто не собирается вкладывать в нее деньги


Зайдите на Upwork, посмотрите, какие Android-приложения (на Java) хотят себе заказчики за 3 копейки. Массово.

Это время уже настало лет 5 назад.
UFO just landed and posted this here
Не java, но продукт на ней.
Интересно, почему мальчика за еду ищет кто-то, а гавно — 1с?
Т.е. если ищется персональный водитель на Мерса, который (заодно) будет обслуживать машину и охранять хозяина, на 20 000 рублей в месяц — виноват Мерседес, так что-ли?
А когда ищут админа Винды, который должен тянуть сеть, разбираться в Офисах, вебе и принтерах, приходящий на 1 час в месяц и на 15 штук — гавном будет Винда?
Интересная логика :)
Тут заказчику данных работ стоит слегка оглядеться и понять, что он хочет и сколько это сейчас стоит.
UFO just landed and posted this here
Интересно, почему мальчика за еду ищет кто-то, а гавно — 1с?
Т.е. если ищется персональный водитель на Мерса, который (заодно) будет обслуживать машину и охранять хозяина, на 20 000 рублей в месяц — виноват Мерседес, так что-ли?

Проблема в том, что данный пример он не такой уж фантастический
Проблема на рынке 1С такая есть, заказчик жмет как может, а это просто очередной наглядный пример


Пффф.
Потусуйтесь на форуме веб-программистов, потусуйтесь на форуме Андроид-программистов — вы ровно те же самые жалобы прочитаете.

Прочитайте исторические книги про извозчиков, к примеру — и 200 лет назад люди все так же жаловались на жизнь.

Это не проблема платформы.
Это проблема экономики и человеческой психики — все заказчики хотят дешевле, все исполнители хотят дороже.
UFO just landed and posted this here
Выше уже писал, тут надо понимать, о каком мы рынке говорим
Мобильные приложения/сайтики и энтерпрайз
Это очень важно, так как спрос там формируется совершенно по разному


Энтерпрайз бывает тоже разный.
Вашими же словами:

Там явно найдётся масса мелких заказчиков, которые для своей кафешки за углом хотят сделать крутое приложение за 3 копейки (больше у них нет)


От того, что совпадают ключевые слова «1С, программисты» не следует делать вывод, что все едино.

Бывают и такие предприятия как вы написали — «киоск и два прилавка». А бывают и серьезно вкладывающиеся в свою автоматизацию предприятия.

И пусть и там и там люди называются программистами 1С — но это люди сильно разной квалификации и с сильно разными зарплатами.

Только совершенно непонятно, как жлобство (или непонимание ситуации) заказчика относится к продукту, который он использует.
Если назвать «типовой» ситуацию, когда заказчик хочет за 3 копейки сделать космический корабль — то этой ситуации 100500 миллионов лет. Оно было всегда, с того момента, как появилось платное оказание услуг.
Но причем здесь 1с — решительно не понятно.
UFO just landed and posted this here
UFO just landed and posted this here
И что? Я не понимаю, куда вы клоните. Достаточно часто САП — это профанация и освоение бюджета. Когда годами внедряют САП, а учет ведут по-прежнему (например) в 1с. Потом или деньги кончаются или власть меняется и САП забывается или остается для материнской компании.
Изначально мы начали с того, что качество продукта никак не определяется количеством денег, который какой-то клиент хочет заплатить за услуги по продукту.
UFO just landed and posted this here
В результате мы получаем озвученные выше проблемы, что 1Совские системы не масштабируются, деградируют и тп.


И минусы в карму 1С, что дает путь другим игрокам. Так как потом бизнес начинает считать, что 1С — плохо и рассказывать своим товарищам.
Но самое печальное в этом, то что находятся подрядчики, который за эту условную тарелку супа, без проработки методологии или технической архитектуры берутся внедрять 1С.

В результате мы получаем озвученные выше проблемы, что 1Совские системы не масштабируются, деградируют и тп.


Редко когда это бывают неразрешимые проблемы.
Разве что когда данных много, а на спецов денег вообще жаль.

Так то на сегодня проще купить более мощный сервер. Это и дешевле и быстрее.

Есть и решения «через 1С». Очистка данных старых (выведение старых данных из базы в отдельную). Есть доработка прозводительности уже сделанного решения.

Это все делается постепенно, по мере возникновения проблем. Поэтому бизнесу выгодно. Есть же простое правило «деньги сегодня это лучше, чем те же самые деньги завтра» (из-за инфляции и потери бизнеса из-за выведения денег из оборота сразу большими кусками).

Тут все довольны — и бизнес, потому что сэкономил. И разработчики — потому что разработали, а потом еще раз доработали.

Еще раз общаю ваше внимание:

У бизнеса более другой подход, более прагматичный. Там немного другая логика работает.

Ваш технарский подход про идеальную систему про необходимое совершенство — не прокатывает.

Проиллюстрирую ситуацию из своего прежнего еще админского опыта:
Про прагматичность бизнеса
Много лет назад работал я на фирме. И они каждую неделю покупали новый принтер, просто выкидывая старый. Потому что нагрузку не выдерживал. Всего на фирме принтеров было много.

Почему не выдерживал? Потому что покупали самый дешевый лазерный принтер, «типа для домашнего применения»

И вот при очередной покупке принтеров директор подмахнул мне не глядя счет на очередной принтер. Я в тот раз выбрал высокопроизводительную дорогую модель.

Когда этот принтер приехал, естественно руководитель заметил его в офисе. Удивился. Проверил стоимость.

Потом вызвал мне к себе и с цифрами детально показал, что дешевые принтера фирме выгоднее. Вкратце: более надежные хоть и имеют больший ресурс, но этот ресурс непропорционально выше, чем выше их цена.

В конечном итоге новый принтер понравился скоростью печати — при печати толстенных прайсов это было важно. Таким образом по одному высокопроизводительному принтеру в каждом филиале мы закупили.

Но основную массу принтеров все так же брали дешвые малопроизвоидительные. Это выгоднее.

А бизнес — прагматичен.
UFO just landed and posted this here
Раньше тоже этого мнения был, что вот технари они не понимают бизнес, что лучше сегодня внедрить сырую систему, чем ждать ещё уловных пол года год пока архитекторы уже разродятся стабильным решением.

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


Это же о разном:

Есть долговременные стратегические разработки, а есть те, что оперативно должны быть внедрены — и это разные вещи.

И оперативно требующих внедрения — подавляющее большинство.

UFO just landed and posted this here
но в результате получается «ласкутная» автоматизация, что в долгосрочной перспективе приведет к тому, что вы все равно захотите покрыть бизнес-процессы одной ЕРП


И что?

Вот например, на сегодня у меня задача подключить ПО интернет магазина (там внутри в бэкофисе 1С) к очередной курьерской службе.

Параллельно пилится новый интернет-магазин.
По вашей логике — нужно дождаться его? И сразу скопом впилить туда универсальные механизмы курьерских служб?

Дык за это время (а это еще год наверно) куча заказчиков будут менее удовлетворены, а магазин переплатит за доставку.

Для бизнеса «лоскутные» вещи (а это на самом деле тоже большие деньги в прибыли — по прикидкам эта курьерская служба сэкономит им за полгода после ввода в экслуатацию столько, что магазин сможет меня месяц содержать; но это же разовая затрата на меня — а потом у них чистая экономия) бывает что даже более важны, чем стратегические — ибо на стратегические можно денег не заработать ежели оперативными вещами не заниматься.
И почему в результате гавном становится 1с, а не заказчик, жмущий бюджет? Почему вы переворачиваете ситуацию с ног на голову?
Замените «1С» на «lsFusion», «SAP», «Axapta» — что-то изменится? ИМХО — ничего. Только виноват все равно будет заказчик, жмущий бюджет, а не система на нормальное внедрение которой бюджет жмется.
UFO just landed and posted this here
Потому что компания 1С уже сделал репутацию своему продукту, как «дешевому». В результате потенциальный покупатель не считает, что нужно в бюджет закладывать ресурсы на хорошее проектирование и проработку методологии например.


Да ладно.
Вполне себе успешно работаю с бюджетами и под миллион.

Просто внедрения бывают разные.
Требовать от ларька с двумя прилавками больших денег — бесполезно.

Хотите больше денег — работайте на другом рынке, не у ларечника. А на рынке крупных внедрений.
1С это или не 1С — разницы не имеет.
Даже на 7.7 делали большое количество разных (в том числе и тяжелых) внедрений. Понятно, что понятие о «тяжести» 20 лет назад и сейчас слегка разнятся, но тем не менее. А очень много народу «осталось» в начале 00-х, и оттуда вещает о дешевизне и непригодности 1С: Предприятия. Просто рынок базовой версии и проекта для какого-нибудь Камаза — они разные. И исполнители у этих проектов НИКОГДА не пересекутся.
Покажите мне пример когда SAP или Oracle ищут за копейки


Разброс зарплат с 1С очень большой по причине внедрения как на малых так и на больших предприятиях.

Покажите мне пример, где SAP или Oracle внедряют на небольшом предприятии.

SAP/Oracle в среднем предприятия покрупнее, чем те, с которыми работают 1С. А вот если взять пересечения — вот тут и сравнивайте заплаты.
В данном случае следует заметить, что при всех недостатках платформы 1С, причина — дао заказчика, а не качество инструмента. Считаю, что каждый должен отвечать за себя.
Проблема 1С, как платформы, в том, что она не сделала качественный рывок — не стала фреймворком. Поэтому приходится тащить на себе поддержку ide, поддержку репортера, поддержку файловой СУБД ( хотя это в принципе уже могли вырезать), поддержку скриптового нетипизированного языка (если память мне не изменяет, в девичестве vbscript, вроде даже лицезировался у МС), странную модель работы с данными (о чем и пишет ТС). Все это съедает ресурсы, которые могли бы быть направлены на развитие. Но это -дао разработчика системы.
Как связан 1С-Фрилансер с тем, что написано в задании? Вы кого ищете то?
имхо — много гимороя… как бы и что бы 1с не говорила — работать полноценно она может только в экосистеме windows. авторизация 1с в ad и так проблематична если доменов несколько (fqdn передает горячий привет), астрал + интеграции с зупом — это тоже все заточено под win/com. в пингвине надо будет вероятно извращаться, искать инфу которой по сути нет — основная масса коммюнити 1с-ников сидит на windows. а тем кто «шарят» ваш заказ «за 1000» не интересен
Это уже не так, последние типовые от 1C встают на PG без малейших проблем.
только патченные же 1с. Если у вас есть сведения о работе 1с с ванильным postgresql опишите подробнее
Ну да, патченные. Зачем ставить на ванильный, если есть с бесплатными патчами от вендора?
Это уже не так, последние типовые от 1C встают на PG без малейших проблем.

только патченные же 1с. Если у вас есть сведения о работе 1с с ванильным postgresql опишите подробнее


вы хотели сказать «на пропатченые PostgreSQL»?
да 1С и не скрывала, что изменила под себя часть PostgreSQL, чтобы сделать его более похожим по поведению на MS-SQL, так как изначально под MS-SQL и затачивали 1C.
Очень интересно, но ничего не понятно.
Знал бы 1С — смог бы сравнить с сапом.
Мое знакомство с 1С было лишь, как пользователь и эникей. Еще с 7.7 я заметил то, что многое следовало бы доработать. А с выходом 8ой версии было красиво, но расплачивались долгим откликом интерфейса на разные действия. Блокировки были первое время очень доставучие. База росла, как на дрожжах и за год переваливала за террабайт. Её 1Сники «обрезали», а старую базу архивировали. С 7.7 помню, что начинали каждый год новую базу с нуля и переносили карточки клиентов для работы.
Сейчас это выглядит, как каменный век.

Как я считаю: взять подход реализаци решений в крупных зарубежных компаниях и использовать это в внедрении 1С, то она была бы лидером по очень многим параметрам.
Очень часто попадались проектанты, которые ломали зубы при внедрении алкогольки в готовой конфе 1С, мечтая о новенькой панамере. Из-за низкого порога вхождения — кого только не берут в консалтинг.

Да и хочется знать, есть ли у 1С похожие продукты:
— Solution manager — централизованное управление решениями, учет и техподдержка, репликация пользовательских настроек,
— Process Integration(PI) — шина данных для интеграции с другими удаленными PI или сторонними системами,
— Business Warehouse(BW) — хранение огромного количества данных предприятия, BI — анализ и агрегация данных BW.
Список на самом деле огромный, но эта та часть, о которой имею представление.

На счет обновлений 1С — это печально. У немецкого продукта обновления выходят хоть и не так часто, но любой найденный баг правится кодерами из сап и на основе такого фикса выпускается нота, которая публикуется и описывается для тех, кто может столкнуться с такой бедой. Тот находит её по симптомам и именам объектов и может себе скачать в систему и пофиксить проблему.

Как ни странно, но abap развивается и получает очень удобные конструкции.
Ну, а интерфейс — помимо GUI клиента имеется очень неплохой web, с таким же функционалом.
UFO just landed and posted this here
Главная проблема 1С лежит не в платформе, а в весьма посредственном прикладном функционале.
Они его не вылизывают.
Я работаю с MS NAV. Там большая часть основных таблиц за 15 лет поменялась слабо. Есть недостатки, но они исправляются и вылизываются. А у 1С куча конфигураций с сильно перекрывающимся функционалом. И при этом ни одна из них не доведена до нормального уровня.
UFO just landed and posted this here
Но почему в репозиториях на github нет ни одного readme?
Где есть документация по особенностям «языка» IsFusion? Или java это и есть основной язык?
Потому что там (на github) предполагается все вести только на английском. А пока материала на английском нету: в процессе перевода.

Можете посмотреть другие статьи в этом блоге — там много примеров.
Плюс можно посмотреть примеры (в частности, How-To).
Благодарю за ответ, однако не понимаю связи readme и «предполагается все вести только на английском». В чем сложности написать небольшой readme в markdown? На любом языке. И в чем сложность разместить два readme? Особенно если есть на русском?
С отсутствием readme — это просто, скорее, недосмотр. Сделаем.
Мне кажется, некоторые читатели прохладно восприняли этот обзор, потому что в России 1С особенно глубоко пустила свои корни. Много фирм и много разработчиков изучили эту платформу и язык, со всеми её + и -. И люди в любой альтернативной платформе, способной потенциально поколебать эту громадину, видят угрозу для себя. Никому не охота терять работу, разоряться или выбрасывать из головы огромный опыт 1С-разработки. А бесплатная и открытая платформа особенно опасна в этой связи, в отличии от дорогущих западных ERP.

А вам бы лучше перетягивать 1С-разработчиков на свою сторону. Расскажите, как реализовать разные сущности 1С в вашей системе. Вот те же 1С-овские регистры накопления и сведений, как они реализованы в lsFusion, есть ли для них специальные абстракции, проще ли их сделать? Или как сделать справочник с периодическими значениями полей, например, список сотрудников, из которого можно извлечь данные о директоре и главном бухгалтере на указанную дату? Как прочитать данные их файла Excel? Как сделать простейшее мобильное приложение, работающее с вашей ERP (например, формирование заказа на смартфоне и отправка в ERP)? И т.д. и т.п.
Не без этого — обидно же когда хают свое родное. С другой стороны, Вы правильно подметили, много разработчиков изучили и пользовались. А вот автор(ы) изучили 1С довольно таки поверхностно (например, в СКД явно не разобрались, а это очень важная технология в мире 1С), поэтому местами статья вызывает резко негативную реакцию.

Ну проведем параллели: допустим, разработчик на Cobol, который никогда профессионально не писал на C#, напишет критическую (можно даже сказать разгромную) статью о недостатках этого языка. Как думаете, что у него выйдет? А ведь платформа разработки бизнес-приложений — это гораздо более сложная система, чем язык программирования, вообще-то.
Сто раз уже отвечали. Ну так ответьте конструктивно по пунктам. И СКД тут уже тоже много раз обсудили.
Мне не очень интересно обсуждать качество самой статьи, потому что его уже выше обсудили, меня больше заинтересовала тема: почему эту статью именно так восприняли, а не по-другому.
UFO just landed and posted this here

Безотносительно 1С, а так, к словам прицепиться:


Обычно бизнес-приложения принято разделять на два контура: OLTP и OLAP.
В OLTP люди обычно принимают оперативные решения и отражают уже произошедшие события, OLAP же используется для принятия стратегических решений.

Смотря что за бизнес, где и чей… Вот Gartner всем предсказывает операционализацию аналитики и аналитизацию операционной деятельности; сontinuous intelligence взамен business intelligence.
Там, где это счастье уже наступило, хотят не отдельных OLTP и OLAP, а того, что называют HTAP и «translytical».


С этой точки зрения верным путем идут товарищи. Только пару терабайт какой-нибудь NVRAM этому СКД добавить, конечно, бы.

Фундаментальный труд! Феноменальный! С нетерпением жду продолжений «Почему не SAP?» и «Почему не DAX?»
Автор анонсировал тут выше
Будет еще статья: Почему lsFusion, а не SQL?

Иногда мне кажется, что автор работает на конкурентов этого lsFusion и провоцирует людей задавать неудобные вопросы и пишет ответы, которые вызывают еще большие вопросы.
Asmody, тогда советую подписаться на наш блог, а то можете пропустить :) На мисте то уже поняли всю опасность фузины и сразу же трут все ветки про нее.
Читаю вас с воодушевлением! Я вообще люблю юмористические произведения.
Там сложнее, у SAP вся информация за семью печатями. А у DAX проблемы в общем-то схожие (хотя и у SAP тоже). Но еще раз, русскоязычный рынок это все же промежуточный этап, пока переводы готовятся.
Так сложилось, что на хабре многие 1С не любят, но порой складывается впечатление, что немногие из этих людей хорошо понимают, за что они его не любят.

Я знаю, почему не люблю именно я: допустим есть небольшой коллектив, 2-3-4 человека работают в 1с. Железо не серверное конечно, но работает всё хорошо.
А спустя год — не вывозит уже. Тупит неЩадно :)
1сники разводят руками, мол докупайте оперативку, меняйте диски, купите другой сервер :(
UFO just landed and posted this here
По поводу технических вещей срач уже начался, поэтому добавлять не буду. Я только попытаюсь прокомментировать фразу:
А вот зачем 1С в качестве платформы разработки выбирают разработчики отраслевых решений, а также ИТ-директора для создания решений внутренней автоматизации (так называемые «самописки») — это, конечно, загадка. Черт с ним с lsFusion, он только пару месяцев назад на рынок вышел, но любая из связок .Net+MSSQL или Python+PostgreSQL будет уж точно не хуже. При этом не надо будет мучаться с ключами защиты, и платить лицензии за платформу, которая местами не то что не помогает, а наоборот мешает. Все ради одной реально полезной абстракции — регистры (которая легко реализуется как средствами СУБД, так и средствами того же .Net) и сомнительной пользы визуального программирования? Причем с конечными клиентами все более-менее понятно: на постсоветском пространстве для многих из них покупка программы — это приблизительно тоже самое, что и покупка мебели в офис. Но решение о создании отраслевых решений и самописок принимают люди с большим опытом в IT. Они-то чем думают?


На этот счет можно написать не одну статью, но все это все равно сведется к трем постулатам:
— нет идеальной системы / платформы, это всегда компромисс, выбор завит от целей и ресурсов;
— несмотря на определенные недостатки платформа 1С позволяет довольно таки оперативно автоматизировать много бизнес-процессов, многим возможностей платформы достаточно;
— у других решений свои недостатки, и зачастую они перекрывают теоретические преимущества над 1С (как простой пример: в моем регионе найти хорошего разработчика на 1с в разы легче чем разработчика на ".Net+MSSQL или Python+PostgreSQL"), опять же «и платить лицензии за платформу» — надо будет платить за разработку и долго ждать результата, ну и много других приколов.

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

И повторюсь, выбор платформ идет от задач и ресурсов, ИТ-директора именно этими понятиями и оперируют. Так что полегче с выводами.
и приводят либо к существенному росту порога вхождения, либо к серьезному падению производительности, либо к значительным трудозатратам со стороны разработчика.

Гы-гы. А ведь и не придерешься — ведь любой функционал можно обкакать, используя эти 3 критерия.

Хотя всем трем критериям одновременно ничто удовлетворить не может.

Хотя всем трем критериям одновременно ничто удовлетворить не может.

lsFusion может, но это уже откровенной рекламой звучит.
UFO just landed and posted this here
Я вам в личку скинул пример вакансии.
Хотя всем трем критериям одновременно ничто удовлетворить не может.


lsFusion может, но это уже откровенной рекламой звучит.


Для несложных система такое может быть, конечно.

Но как только вы выстроите сколько-нибудь развитый продукт — всё меняется.
Давайте сравниваться с тем, что взаимозаменяемо, а не в частных случаях.

В частном случае бывает эффективнее свою маленькую программку с нуля реализовать, что способен сделать любой программист средней руки. Но утверждать при этом что его программа лучше 1С… гм… некорректно. На этой конкретно задаче — да, лучше. Но при этом не покрывает еще 99% задач, что покрывает 1С — так что это некорректное сравнение.

Вот тут ссылка на один из продуктов. Там можете покликать на модули и посмотреть функционал. Вот тут список клиентов в Беларуси с описанием проектов (пример).
Вот тут ссылка на один из продуктов. Там можете покликать на модули и посмотреть функционал. Вот тут список клиентов в Беларуси с описанием проектов (пример).


Понимаете — успех lsFusion — это если бизнес заинтересуется.
Ориентация на бизнес, судя и по этой статье и по комментариям и по сайту — так себе.
Вы на все смотрите с точки зрения технарей.

Простите, но без набора доступных типовых решений — платформа не особо интересна для бизнеса.

А для технарей…
Тот функционал я и сам могу написать. И не хуже чем вы — так как это будет узкозаточенное решение, это будет проще.

Если мне понадобится что-то написать с нуля — я это и на Go/С#/Kotlin сделаю, но никак не на lsFusion.

Вот если бы на lsFusion были бы доступны полнофункциональные реализации того, что в 1С называется типовые прикладные решения (конфигурации) на большинство случаев жизни, то да, другое дело.

Там много-то и не надо: торговля/производство/бухгалтерия/кадры-зарплата розница/опт мелкий/средний бизнес — полагаю около 5 конфигурацию достаточно; под розницу нужна возможность использовать торговое оборудование.

P.S.:
С прикладными решениями под учет зарплаты-бухгалтерии — все еще грустнее.
Если прочие базируются на простом здравом смысле, то эти — на законодательстве, под изменения которого нужно подставиваться регулярно.
Если 1С это обеспечивает, а lsFusion нет — то у lsFusion ниша только «автоматизация для собственного учета, не для учета с взаимодействием с государством».
Давайте так, лезть в бухгалтерию и ЗУП особого смысла нет (даже SAP в них не лезет). В текущем ERP надо конечно докрутить производство и финучет, но это вопрос времени. Сейчас фокус на FMCG розницу и custom made у нас (последнего кстати тоже предостаточно).
UFO just landed and posted this here
А вот зачем 1С в качестве платформы разработки выбирают разработчики отраслевых решений, а также ИТ-директора для создания решений внутренней автоматизации (так называемые «самописки») — это, конечно, загадка.


Потому как это эффективно.

Бизнесу нужно не идеальное решение задач бизнеса.
Бизнесу нужно решение задач, чтобы уже работать начало уже завтра, а не через 2 года. А через 2 года — будет нужно уже другое решение, а вы еще первое не закончили пилить — это не эффективный путь.

Плюс не каждый можете себе позволить потратить миллионы на разработку.
Ну а не потратив миллионы — эдак вы наколенными поделками только простые вещи закрыть сможете. Тут не спорю, средней руки разработчик очень простые вещи легко может и с нуля сделать, без 1С.

Вот и получается, что взять отлично подходящий под задачу уже существующий продукт и допились его под себя — выгоднее.

Ну и не забывайте — что всем этим кому-то нужно заниматься.
Даже если у вас и есть миллионы, то супер-специалистов, способных не просто их «освоить», а выдать качественный результат — кот наплакал.

И положиться на методу разработки с 1С, положиться на большое число знающих её людей — вполне себе рациональное решение.

Это классический уход от ответа. Никто не спорит, что 1С захватил под себя рынок с крайне кривой технологией. Здесь же предлагается бесплатная и открытая альтернатива. Я понимаю, что 1Совцы боятся этого, так как потеряют преимущество в том, что они научились разбираться в этом велосипеде с картинки. На мисте, когда кто-то пытается поднять обсуждение этого тут же не просто закрывают тему, а грохают ее. Видно, что 1Совцы очень любят диктатуру вместо демократии.
На мисте, когда кто-то пытается поднять обсуждение этого тут же не просто закрывают тему, а грохают ее. Видно, что 1Совцы очень любят диктатуру вместо демократии

Ну самим-то не стыдно врать?
Неделя обсуждения, 6 или 7 тем (новую вы сами создали недавно). Ни одна не удалена.
Тему закрыли причем когда стало понятно что оно скатилось в оскорбления и уходы от ответов с вашей стороны.

Я понимаю, что 1Совцы боятся этого

Я лично готов прийти на Хабр и написать о своей горькой судьбе, как только потеряю работу из-за LSFusion. Благо, я даже в одной стране с вами нахожусь и часть клиентов у нас с вами общие.
Но пока что этого почему-то не произошло.
За последний день там создавали 3 темы со ссылкой на эту статью. И их не просто закрывали, а грохали. Но вы пытаетесь доказывать что там все хорошо, и 1Совцы конечно приемлют критику и свободу слова. Что-то мне это напоминает…

Создайте сами тему и посмотрите через сколько ее грохнут. Миста — квинтэссенция всей экосистемы 1С.
Что-то мне это напоминает

Неужели вы намекаете на Хабр, где можно потерять возможность писать комментарии, если мнение не совпадет с мнением большинства или нарушает правила ресурса?
Вы надеюсь понимаете, чем демократия от диктатуры отличается? В демократии тоже большинством многое решается, но мнение меньшинства также учитывается. Возможность писать комментарии можно потерять, только если начать оскорблять всех подряд.
В демократии тоже большинством многое решается, но мнение меньшинства также учитывается.


Вы неверно трактуете термины. Это как классификация — на балконе стояла Маша, мешок с картошкой и пустое ведро.

Диктатура отличается тем, что это очень жесткое мнение.
Как пример, ситуация с НСДРП в фашисткой Германии. Это была обычная партия, изначально пришедшая к власти путем демократических выборов, в соответствии с пожеланиями народа.

Да и демократию вы идеализируйте:

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

Но все кандидаты — всё же ставленники большиства. Или около-большинства (типа с поддержкой от 45% выборщиков — за счет избирательных технологий могущие прийти к власти)

Так там же причину написали — юмористические ветки на Мисте по пятницам разрешено заводить.
Юмористические? Хмм.
«Сначала они тебя не замечают, потом смеются над тобой, затем борются с тобой. А потом ты побеждаешь.»
Хотя в последнем я лично пока не убеждён.
Так каков вопрос, таков и ответ. На данный момент это похоже на «Вокруг смеха».
Если будет по-другому — будет и другое воприятие
Никто не спорит, что 1С захватил под себя рынок с крайне кривой технологией.


Успех 1С вполне объективен.
Рассудил свободный коммерческий рынок — куда уж демократичнее процедура.

Бизнес не интересует идеальная технология. Сферическая в ваккууме идеально — не дает экономических преимуществ.

Бизнес интересует эффективная в использовании технологиях, от которой можно получать реальную экономическую пользу здесь и сейчас.

Здесь же предлагается бесплатная и открытая альтернатива.


Таких только в этом веке уже предлагалось на моей памяти штук пять.

Все они малофункциональные и посему заменить 1С не способны.
Малофунциональны они закономерно: только такую — простую систему — и можно по-быстрому написать и получить все плюшки типа скорости работы.

Как только ваша система начинает решать все больши и больше задач бизнеса, как только она становится более универсальной и более функциональной — она усложняется и в ней вылазят косяки, нельзя все предусмотреть идеально.

В каких то случая lsFusion внеднять целесообразнее 1С.
Но сравнивать тачку для груза и грузовик — некорректно. У каждого своя ниша.

UFO just landed and posted this here
Понятно, что самому 1С на качество платформы в общем-то наплевать. У них такие бюджеты на разработку типовых решений, что они могут их хоть на ассемблере писать. Конечно, дорабатывать такие решения — занятие не самое простое и приятное, но, как говорится, «проблемы индейцев шерифа не волнуют».


А вот это — неправда.

Что там внутри ядра 1С — можно только гадать.
Но типовые прикладные решения поставляются с исходными текстами. И по ним хорошо видно как продумано подошли к проектированию.
Человек, дорабатывающий 1С — очень быстро на типовых учится правильному подходу — там есть чего посмотреть.

Недостатки, разумеется, тоже есть как и положено в больших продуктах.
Опыт подсказывает, что недостатки есть так же и у вас.
Не ошибается только тот, кто вообще ничего не делает.

С поправкой на масштабность, где ошибки все равно будут — спроектированны нынешние типовые на заглядение хорошо.
Опыт подсказывает, что недостатки есть так же и у вас.

Вы невнимательно читаете. У LsFusion нет недостатков (или их тщательно скрывают).

Я для себя из статей вынес следующие факты:
1) Если сравнивать 1С,SQL,SAP… и LSFusion по критериям «быстро, дешево, качественно» — LSFusion выигрывает по всем трем показателям.
2) 1С,SQL,SAP… примитивнее, но изучить LSFusion проще и быстрее.
3) 1С,SQL,SAP… это дорого, но разработчики на LSFusion зарабатывают больше и условия труда лучше.
4) Если чего-то в LsFusion нет, то только по одной из причин:
а) это неправильно;
б) это не нужно пользователям;
в) это не нужно программистам;
г) слишком просто и не интересно делать;

и т.д.
У LsFusion нет недостатков (или их тщательно скрывают).


Из того, что я успел понять, взглянув поверхностно — LsFusion довольно простая система.
У таких вполне может и не быть явных косяков.
Unix Way — не дураки придумали: «выполняя очень маленькие задачи, мы можем делать их очень хорошо»
А заведомо сложным-то является создание большого продукта.
Из того, что я успел понять, взглянув поверхностно — LsFusion довольно простая система.


В том то и дело, что в 1С — десятки (если не сотни) различных дырявых бессмысленных абстракций, а в lsFusion все строится на 5 основных (классы, свойства, формы, события, ограничения). И на них можно сделать гораздо более сложные вещи, чем на 1С (см статьи хотя бы).

Я понимаю, что 1Совцы научились копаться в этом велосипеде и теперь это их ценность (и высокие зарплаты). А в lsFusion — любой дурак разберется. И это для них угроза.
И на них можно сделать гораздо более сложные вещи, чем на 1С (см статьи хотя бы)

Делайте, кто ж мешает. Пока, почему-то, только разговоры и решение для узкой ниши рынка в одной небольшой стране.

Я понимаю, что 1Совцы научились копаться в этом велосипеде и теперь это их ценность (и высокие зарплаты). А в lsFusion — любой дурак разберется. И это для них угроза.

Так все-таки разработчики на 1С получают больше чем разработчики на lsFusion или меньше? У вас путаются показания. Получается, что 1С это сложно и хорошо оплачивается, а lsFusion — «любой дурак разберется и заплатят не очень много, меньше чем в 1С»?
Вам уже говорили — низкий порог входа в технологию, это не всегда плюс. Пример 1С как раз-таки это показывает.
В том то и дело, что в 1С — десятки (если не сотни) различных дырявых бессмысленных абстракций, а в lsFusion все строится на 5 основных (классы, свойства, формы, события, ограничения). И на них можно сделать гораздо более сложные вещи, чем на 1С (см статьи хотя бы).


Браво!

Я вам больше скажу — на языке универсальном языке программирования типа C# или Java можно написать куда как более крутые вещи, чем на 1С или lsFusion.

Да безусловно.

Вопрос только каких это будет стоить усилий/денег, если стоит задача написать что то объемное.

В том то и дело, что в 1С — десятки (если не сотни) различных дырявых бессмысленных абстракций


1С хорошая тем, что заточенная на вполне определенные задачи.

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

Быстрее — это намного быстрее. Это, даже может статься, что и в десятки раз меньше времени уходит у программиста, чем на более универсальных инструментах.

Если ваша задача не ложится на принципы на 1С, то, конечно, смысла использовать 1С нет.
Вопрос только каких это будет стоить усилий/денег, если стоит задача написать что то объемное.

Гораздо меньше, чем на 1С.

Вы сейчас рассуждаете о высоких материях, даже не изучив предмет (lsFusion). Давайте, вы для начала потратите столько времени на изучение lsFusion, сколько автор потратил на изучение 1С, и тогда можно будет обсуждать более предметно.
UFO just landed and posted this here
UFO just landed and posted this here
Автор в 1С ни в зуб ногой… открыл демку УТ11 методом научного тыка потыркался там, нарезал скриншотов и пошел статью писать…

иначе бы бы не сравнивал платформу с конфигурацией…

Но типовые прикладные решения поставляются с исходными текстами. И по ним хорошо видно как продумано подошли к проектированию.

Вы вообще код видели? Я специально его отрывки в статье приводил. Понятия не имею как можно его дорабатывать. Там просто квинтэссенция сильно связного низкоуровневого кода. Кровь из глаз идет. Я когда его lsFusion разработчикам показал, первая реакция «ЧТО ЭТО?».
Вы вообще код видели? Я специально его отрывки в статье приводил. Понятия не имею как можно его дорабатывать.


Судить по небольшому участку кода?
«Хорошо спроектированное» — это хорошо спроектированное в объеме всего проекта.
Грамотно разложенные абстракции прикладной области.
Которые вы в масштабах статьи просто невозможно привести.

Ну или нужно посвятить всю статью целиком разбору одной абстракции.

Там просто квинтэссенция сильно связного низкоуровневого кода. Кровь из глаз идет. Я когда его lsFusion разработчикам показал, первая реакция «ЧТО ЭТО?».


Какую реакцию вы ожидаете от незнакомой системы?
При условии, что она не примитивные задачи решает — там понятно можно просто и красиво.

Есть такое наблюдение:

Чем универсальнее система, чем более сложные вещи она позволяет делать — тем более специализированные люди с ней могут работать.

Пример из веба:

Отличная вещь CMS. Низкий порог входа. Владелец сайта даже сам может её поставить и эксплутатировать. Программисты не нужны.

Но как только хотелки владельца сайта заходят слишком далеко — все, приехали. Опять ему нужен квалифицированный программист. Для начала — специалист глубоко разбирающийся в этой CMS.
Это нормально.
При условии, что она не примитивные задачи решает — там понятно можно просто и красиво.

У нас она тоже очень сложные вещи решает в достаточно большом сегменте (FMCG розница). До которых 1Ским решениям как до луны. И там такого треша как в УТ — нет.
У нас она тоже очень сложные вещи решает в достаточно большом сегменте (FMCG розница). До которых 1Ским решениям как до луны. И там такого треша как в УТ — нет.


Так уж сложилось что с данным сегментом знаком не понаслышке.
Не стану утверждать, что это простая-примитивная задача на большой сети.
Но там нет никакого особого треша, вызванного 1С, сверх обычного рабочего треша. Конечно если вы не за копейки исполнителей нанимаете.
Ну и использовать одну только чистую УТ в сети FMCG это некомпетенция исполнителя.

Треша как в УТ, я имею ввиду в коде (то есть там, где вы видели, код лучше чем в УТ? решение на базе УТ дорабатывалось?). Вы то утверждаете, что когда задача сложная он неизбежно появляется. Так вот нет. Код даже при этом можно оставлять модульным и слабосвязным.
Треша как в УТ, я имею ввиду в коде (то есть там, где вы видели, код лучше чем в УТ? решение на базе УТ дорабатывалось?). Вы то утверждаете, что когда задача сложная он неизбежно появляется. Так вот нет. Код даже при этом можно оставлять модульным и слабосвязным.


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

Если еще в ранних версиях типовых конфигураций 7.5, тех, что разрабатывались на границе веков — еще можно предъявить претензии по кривой архитектуре.

То уже начиная с 7.7, с которой шла конфигурация Торговля и Склад 9 — видно как они тщательно концепции перед тем как начать собственно написание кода.

Еще раз:

Некая программа решает задачи. И всё. Что там внутри — даже не вторично для бизнеса а где то на 100 месте.

Код внутри 1С не мешает (в том числе и мне как программисту) решать задачи для бизнеса, а помогает.

Да, он не идеальный.
Но такового не существует.

Если взять вашу концецию про полуфабрикат — так вот ни мне не бизнесу он задачи не решает. Его нужно сначала взять и собрать. А это — совсем другой сегмент заказчиков — тех, что не торопятся, пока работают на чем то другом, тех, что делают стратегические разработки, тех, где есть большие бюджеты.

То есть ваш конкурент это как бы SAP, а не 1С.
Но с другой стороны у SAP куда как больше готовых решений и опыта на все случаи жизни, чем у вас.
Гм…

Получается ваш рынок это нечто среднее — между 1С и SAP?

Ну с учетом их планов захватить мир — 1С им точно не конкурент :))
Ну с учетом их планов захватить мир — 1С им точно не конкурент :))


Это сложно.

В мире свободная конкуренция началась гораздо раньше чем в Белоруссии и РФ.

И компьютеры для целей коммерческого использования — на Западе раньше начались.

Так что там все уже поделено и переделено. Написано и вылизано.

Внедриться, конечно, можно. Но это ой как тяжело на зрелом-то рынке. Да и основное большое лавэ уже подняли конкуренты.

Не мне конечно решать, а руководству lsFusion. Однако целесообразность не видится. Разве что какая-то из белорусских сетей, использующих lsFusion пойдет в РФ или Польшу и принесет lsFusion с собой.
Такой инновационной платформы, как lsFusion ещё не было, как только CIO компаний всего мира оценят всю её мощь — выкинут то старьё, на котором сидят, и прибегут к ним с деньгами. Дело за малым — перевести документацию на английский язык.
Получается ваш рынок это нечто среднее — между 1С и SAP?

Вот тут с вами соглашусь. Но на самом деле рынка коробок уже нет лет как 5-10. Все новые проекты — это сложные проектные решения с глубокой кастомизацией (потому как у большинства уже лет 10 все как-то уже автоматизировано).

Вы какую-то статистику собирали, чтобы делать выводы вроде "рынка коробок уже нет 5-10 лет".
Я думаю всякие мелкие бизнесы появляются постоянно, а значит потребность в коробках все равно остается.

Вы какую-то статистику собирали, чтобы делать выводы вроде «рынка коробок уже нет 5-10 лет».

Я на этом рынке 21 год. И наблюдаю его очень давно.
Я думаю всякие мелкие бизнесы появляются постоянно, а значит потребность в коробках все равно остается.

Мелкие может и появляются. А вот малые и средние очень мало. Экономика стагнирует, если вы помните. То есть потребность в коробках то остается, но очень маленькая по сравнению со сложными проектными решениями.
Не экономика стагнирует, а происходит процесс укрупнения и консолидации бизнеса. Т.е. среднего бизнеса, основного потребителя услуг по доработке типового 1С, становится всё меньше. А у крупняка уже совсем другие запросы, им одной коробки мало 100%
Но на самом деле рынка коробок уже нет лет как 5-10. Все новые проекты — это сложные проектные решения с глубокой кастомизацией (потому как у большинства уже лет 10 все как-то уже автоматизировано).


Ваши высказывания фантастичны, действительность я наблюдаю своими глазами иную в течение последних 20 лет:

Если мы говорим о мелочи — коробки там были и остаются.
Если мы говорим о крупняке — то так никогда и не было коробок.

Где-то лет 15 назад было немного иначе — даже мелкие пытались пилить свой софт. Но потом у них стали только коробки в основном.

А где-то 15 лет назад крупняк пытался использовать готовые вещи типа Галактики.

Но уже 15 лет как все четко и ничего не меняется.
Разве что коробки немного заменяются в SaaS.
UFO just landed and posted this here
Могу помочь показать/рассказать о том что вы называете Axapta. Но такого продукта больше нет, есть Dynamics AX2012(старая версия на оригинальной платформе — клиент Windows приложение) и Microsoft Dynamics 365 for Finance and Operations(новая версия, которую выпустили несколько лет назад, платформа полностью переписана под клауд применение — клиент — браузер). Функциональность обоих(то что вы называете конфигурацией) более или менее совпадает
Нас больше интересует Dynamics AX. Заранее спасибо.
Начнем с базовых:
1. Как у них с ORM, как в Hibernate (с настройками fetch'инга и маппинга) или как в 1C.
2. Запросы в строках или в язык интегрировано?
3. БОльшая часть логики в ORM или в запросах?

C SQL как правило нет прямой работы. В среде разработки вы определяете объект-таблицу, у нее есть поля(у каждого поля метка, хелп текст и прочее), методы, индексы, связи и прочее. Есть системная процедура которая синхронизирует это определение с SQL.
В сам язык X++ встроенно подмножество SQL(с поддержкой на этапе компиляции)
Соответсвенно вы пишете на этом языке.
Пример вот отсюда
docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-ref/xpp-data-query

LedgerJournalTrans ledgerJournalTrans;
LedgerJournalTable ledgerJournalTable;
LedgerJournalId jnJournalNum;
Voucher vVoucher;
Counter counter = 0;
jnJournalNum = «999999_999»; //«000012_003»;
vVoucher = «88888_888»; //«00001_IRG»;
ledgerJournalTable =
ledgerJournalTable::find(jnJournalNum);
ttsBegin;
while select forUpdate ledgerJournalTrans
where ledgerJournalTrans.journalNum == jnJournalNum
&& ledgerJournalTrans.voucher == vVoucher
{
ledgerJournalTrans.Delete();
counter++;
}
Строго разделения логики нет: можете все писать на формах(что конечно не рекомендуется), можете делать классы которые потом вызывать с форм, или наоборот классы которые будут запускать формы. Все это будет объектами
Сила системы что для большинства типовых вещей не надо писать код, достаточно определить таблицу, форму к ней, и пользователь может вносить данные
Интересно, спасибо. Я правильно понимаю:

1. Они также как и в linq, select'ы интегрировали в язык?
2. Как связываются классы (объекты) и таблицы? Потому как по документации у них это два отдельных раздела.

Ну и 3-й вопрос, чаще императивно или select'ами задачи решаются?

Ну и чуть глубже. У них один flow или тоже есть отдельно клиентский код и серверный? И как реализуется тогда сценарий как в статье? Считал что-то из базы, спросил, дальше еще что-то считал из базы и так далее.
1. ну да, только Аксапта была разработа в 1998, а linq поновее. В новой версии вроде бы можно использовать linq, но примеров я не встречал, код получается более громоздкий чем встроенный язык
2. Никак. Т.е. классы использовать желательно, но необязательно. Есть даже такая шутка, «сделал решение без единого класса» = «сделал говнорешение». Но как правило классы используют, соответственно стараются логику в них запихать, чтобы было удобно поддерживать
3. код разделяется условно, в новой версии вообще не разделяется, весь код — серверный. Хотя если очень хочется можно разработать и свой контрол(в старой версии ActiveX, в новой Javascript), но это нетипичная задача.
А какой конкретно сценарий в статье?
То есть в Axapta вообще ORM не делали? Красавцы если так.
А какой конкретно сценарий в статье?

Тут
Считал что-то из базы, спросил, дальше еще что-то считал из базы и так далее.

Ну и заодно, если можно вкратце по пунктам:
1. Представления. В частности на дату?
2. Материализованные представления?
3. Триггеры per statement (то есть не по записям)?
4. оконные функции, LATERAL JOIN, рекурсивные CTE?
5. С какими СУБД работают? Оптимизируют запросы или транслируют как есть?
6. DML (есть понятно при таком подходе, но на всякий случай)
7. Блокировки? Я так понял forupdate и просто serializable? То есть никаких ручных блокировок как в 1С нет?
8. Источники данных для списков? Произвольный запрос как в 1С? А как тогда редактирование списков реализуется?
9. Наследование таблиц?
10. С типизацией и модульностью ЕМНИП там все более менее нормально (так называемые модели для модульности), но на всякий случай.
11. Everything-as-a-code? Таблицы и формы кодом задаются? В XML или на X++?
12. Лицензируют платформу или решения?
ну да. по вопросам
1. Представления. В частности на дату?
Надо кодить
2. Материализованные представления?
нет
3. Триггеры per statement (то есть не по записям)?
стандартно
4. оконные функции, LATERAL JOIN, рекурсивные CTE?
нет

5. С какими СУБД работают? Оптимизируют запросы или транслируют как есть? как есть, добавляя системную информацию(код компании), только SQL Server

6. DML (есть понятно при таком подходе, но на всякий случай)
да
7. Блокировки? Я так понял forupdate и просто serializable? То есть никаких ручных блокировок как в 1С нет?
блокировок нет для большинства таблиц т.к. используется readcommited stapshot, если 2 пользователя меняют одну и туже запись, будет ошибка.
можно сделать чтобы была блокировка

8. Источники данных для списков? Произвольный запрос как в 1С? А как тогда редактирование списков реализуется?
да, если запись видна на форме, ее в общем случае можно редактировать

9. Наследование таблиц?
есть, но не особо работающая технология, скорее мешает

10. С типизацией и модульностью ЕМНИП там все более менее нормально (так называемые модели для модульности), но на всякий случай.
модели есть в новой версии, в старой из любого места можно вызывать любой объект

11. Everything-as-a-code? Таблицы и формы кодом задаются? В XML или на X++?
В новой версии хранится в хмл, в старой в бинарном виде. для редактирования используется визуальный редактор, хмл используется для сравнения

12. Лицензируют платформу или решения?
в новой клауд версии 200$ пользователь с полными правами\месяц, минимально 20 пользователей. Только платформу купить нельзя(это я считаю недостаток большой), т.е. отсекает кучу вариантов использований
Спасибо большое за ответ. Еще несколько уточнений тогда, если можно:
3. Триггеры per statement (то есть не по записям)?
стандартно

А обращение к таблице изменений (:new, :old в MS SQL, и transition tables в Postgres)
2 пользователя меняют одну и туже запись, будет ошибка.

Так, а обычно в БД уровень изоляции не serializable используют? И в версионном режиме MS SQL или блокировочном?
да, если запись видна на форме, ее в общем случае можно редактировать

То есть если я делаю в качестве источника списка select from x join y on x.f=y.f и начинаю вводить в поле из y, она реально в y будет изменять? И если я напишу select y.x, y.x + y.z from y, и буду изменять первую колонку (то есть x), вторая будет автоматически обновляться?
А обращение к таблице изменений (:new, :old в MS SQL, и transition tables в Postgres)

Только для одной записи

Так, а обычно в БД уровень изоляции не serializable используют? И в версионном режиме MS SQL или блокировочном?
В версионном — readcommited stapshot


То есть если я делаю в качестве источника списка select from x join y on x.f=y.f и начинаю вводить в поле из y, она реально в y будет изменять?

Будет изменять то поле которое вы поместити на форму, да. Т.е. если поместите все поля и в грид на форме, можно будет менять любое поле из x и y. Условия связи можно не прописывать для формы, будет взято из определения таблиц, т.е. в простом случае помещаем на форму как источник данных х, потом у, говорим что они связаны по inner join

И если я напишу select y.x, y.x + y.z from y, и буду изменять первую колонку (то есть x), вторая будет автоматически обновляться?

да, это называется display метод, y.x + y.z — это любой код из X++ возвращающий одно значение которому будет передан текущая запись, плюс можно получить ссылку на форму
Есть еще также edit метод, когда вы можете разрешить изменять y.x + y.z, соответсвенно вам надо будет закодировать куда сохранять введенное значение
Супер. Но все равно часть вещей непонятно:
В версионном — readcommited stapshot

А как тогда проблему одновременного редактирования остатка решают?
Будет изменять то поле которое вы поместити на форму, да. Т.е. если поместите все поля и в грид на форме, можно будет менять любое поле из x и y. Условия связи можно не прописывать для формы, будет взято из определения таблиц, т.е. в простом случае помещаем на форму как источник данных х, потом у, говорим что они связаны по inner join

А если связь не 1-к-1. Или скажем left join? Изменит для всех записей и добавит недостающие записи?
да, это называется display метод, y.x + y.z — это любой код из X++ возвращающий одно значение которому будет передан текущая запись, плюс можно получить ссылку на форму

Ок, а если допустим идет так:
select detail.skuId, sku.name from detail join sku и я меняю detail.skuId, sku.name обновится?
Ну если я скажем в верхнем списке делаю:
select sum.q from document join (select sum(quantity) as q from detail by documentId) sum on sum.documentId = document.id
а в нижнем
select quantity from detail
и в нижней таблице изменяю quantity, в верхнем списке сумма обновится сама?
А как тогда проблему одновременного редактирования остатка решают?

Для таблицы остатков стоит сво-во блокировка при обновлении. Но сам механизм довольно сложен, но это уже детали
А если связь не 1-к-1. Или скажем left join? Изменит для всех записей и добавит недостающие записи?

left join нет. есть inner и outer. но записи в любом случае добавляться не будут
select detail.skuId, sku.name from detail join sku и я меняю detail.skuId, sku.name обновится?

Надо смотреть конкретный пример, но по системе да. т.е. пользователь может вводить или skuId или sku.name, соответсвенно система сама разрешит и обновит нужное поле
Ну если я скажем в верхнем списке делаю:
select sum.q from document join (select sum(quantity) as q from detail by documentId) sum on sum.documentId = document.id
а в нижнем
select quantity from detail
и в нижней таблице изменяю quantity, в верхнем списке сумма обновится сама?

Sum на формах не работает. т.е. если вам нужно отобразить 2 списка — заказ и строки заказа и у шапки нужно отобразить сумму по строкам. то вы кидаете на верхний список таблицу заказов, на нижний строки, также на верхний добавляете display метод для таблицы заказов который что-нибудь считает. Он будет обновляться автоматически

Для таблицы остатков стоит сво-во блокировка при обновлении. Но сам механизм довольно сложен, но это уже детали

Блокировка на чтение или на запись?

Потому как если на запись это же не поможет. Кто-то влезет в середине транзакции (пока блокировка еще не стоит) поменяет остаток, и с RC изоляцией ерунда получится.

А если блокировка на чтение, это будет уже блокировочник с соответствующей проблемой с масштабируемостью.

Ну и в какой момент и на какие записи накладываются блокировки. Автоматически платформой или вручную разработчиком?
left join нет. есть inner и outer. но записи в любом случае добавляться не будут

left это и есть outer как я понимаю. Но тут вопрос вот в чем, я вывожу:
select sku.name from balance join sku on balance.skuId=sku.id
В balance 2 ключа склад и товар, то есть будет для одного sku много записей.
Я меняю name, сразу в списке это name для всех записей поменяется?
Надо смотреть конкретный пример

Ну он вроде более менее конкретный. То есть я меняю skuId, она видит что это влияет на поле sku.name, и что? Перевыполняет весь запрос, или строит новый запрос для его обновления.
также на верхний добавляете display метод для таблицы заказов который что-нибудь считает. Он будет обновляться автоматически

А проблемы N+1 не будет? если я там напишу select sum(quantity) from detail where detail.document = x, она не будет для каждого инвойса сверху (если там список инвойсов) выполнять этот запрос?

Ну и есть где-то учебная версия Axapta как у 1С?
Тема с визуальным программированием, а точнее low-code / no-code платформами то и дело всплывает то тут, то там с завидной регулярностью. Позиционируют себя эти платформы, как средства ускоряющие / упрощающие разработку. При этом почему программирование мышкой по их мнению должно быть априори эффективнее программирования клавиатурой — непонятно. Разработку действительно можно ускорить / упростить повышением уровня абстракций, но никак не способом ввода этих абстракций в систему. Одна строка кода в этом смысле лучше, чем пять кликов / перетаскиваний мышкой, не говоря уже о том, что скорость работы с клавиатурой у опытного разработчика как правило выше, чем скорость работы с мышкой.


1) Потому что заметная доля работы прикладного программиста — это реализация взаимодействия с пользователем. Визуально интерфейс создавать удобно. Тем более, что в 1С он не произвольный, а стандартизированный.

2) Кроме интерфейсов с пользователем визуальными средствами в 1С выполняется прежде всего этап проектирования структуры БД.

3) А собственно программирование в 1С — уже программирование как и всегда, текстом. Вы точно не просто 1 разик поглядели на 1С? Визуальной составляющей там не так уж и много, чтобы «вообще не нужно было писать код»
Повторю то, что писал в комментариях выше:

А вас не смущает, что в самых популярных фронтенд технологиях для разработки GUI(!!!) React и Angular все делается кодом, а не визуальным программированием? Визуальное программирование — это для настроек максимум. Для промышленной разработки с ним больше проблем, чем преимуществ. Опять же напоминаю про gitflow.
До «управляемого интерфейса» формы рисовать на 1С было весьма неприятно. Да и сейчас — удовольствие ниже среднего. Стандартизация интерфейсов, однако, создание уютного мирка, где пользователи и программисты, переходя с одного предприятия на другое видят привычный интерфейс и не напрягают мозговых извилин :))
А вас не смущает, что в самых популярных фронтенд технологиях для разработки GUI(!!!) React и Angular все делается кодом, а не визуальным программированием?


Вы немного о другом. Слишком уж в лоб сравниваете разные вещи. React и Angular — предназначены для формирования произвольного интерфейса пользователя. Интерфейс пользователя 1С — стандартизирован.

Да и то, что предлагают в React/Angular — это не единственный путь. Есть же другой, куда как более заслуженный продукт — QTCreator.

Для промышленной разработки с ним больше проблем, чем преимуществ.

Авторам lsFusion?
Безусловно. Визуальное средство создать сложнее.
В языке — это дешево и сердито. То есть небольшими усилиями получаем с помощью языка вполне функциональные вещи.
Да и то, что предлагают в React/Angular — это не единственный путь. Есть же другой, куда как более заслуженный продукт — QTCreator.


Так сравните количество разработчиков React/Angular и QTCreator? У кого больше? Значит что удобнее? Или думаете, что разработчики на React и Angular тоже были с 90х, как у 1С?
Так сравните количество разработчиков React/Angular и QTCreator? У кого больше?


А ничё, что это совсем разные прикладные ниши? Где совсем разное количество заказчиков.
Разные. Но почему, по вашему, нету визуального конструктора для React, если это так круто?
Разные. Но почему, по вашему, нету визуального конструктора для React, если это так круто?


Интерфейс не стандартизированный, в отличие от 1С.

  • Ведь весь смысл React/Angular — как раз и есть рисование интерфейсов.
  • А смысл 1С другой — автоматизация бизнеса.


В 1С программисту легкое изготовление интерфейса визуальными средствами дает экономию времени и дает возможность сосредоточится на решении собственно основной прикладной задачи (работа с данными).

Пользователям 1С же предлагаются стандартизация ради упрощения изучения. Изучил в одном месте — ожидаешь что по всей программе будет аналогично.

Иначе программисты не будут делать единообразно. Ну хоть чисто для поразвлечь себя на работе: дай я так попробую, дай я эдак попробую. Собственно и сейчас такая проблема имеется, однако хоть и не в такой крайней форме, как это было бы с произвольными интерфейсами.

Подытожу — задачи React и 1С — разные. Поэтому и подходы разные.
В 1С программисту легкое изготовление интерфейса визуальными средствами дает экономию времени и дает возможность сосредоточится на решении собственно основной прикладной задачи (работа с данными).

Возможно. Но проблема в том, что в 1С это совсем нетривиально, так как приходится извращаться с этими &НаСервере и &НаКлиенте. Сравните с тем, как это сделано, например, в lsFusion, где разработчику не надо всей этой фигней страдать.
Еще раз, я в самой статье описал плюсы и минусы визуального программирования. Про тонны кода в 1С поверьте я в курсе, просто реально многие 1С разработчики и не только, все еще живут иллюзией, что они только мышкой программируют и это круто и быстро.
Потому что заметная доля работы прикладного программиста — это реализация взаимодействия с пользователем. Визуально интерфейс создавать удобно.

По этому пункту как андроид разработчик(куда уж ближе к UI и пользователям) не соглашусь, предпочитаю пользоваться редактированием через текст при наличии визуального конструктора. Да и кастомные вьюшки по другому вообще не сделать. Максимум иногда в режим предпросмотра переключаюсь, но только под самый конец, оценить что налепил.

Ну и да, визуальной составляющей в 1с реально дофига и больше, в сравнении с той же андроид разработкой, например.
По этому пункту как андроид разработчик(куда уж ближе к UI и пользователям) не соглашусь, предпочитаю пользоваться редактированием через текст.


Давайте оставаться в контексте темы про 1С.
В 1С интерфейс — стандартизованный. Узкозаточенный.

Если уж про крайние случаи говорить, про изображение произвольного интерфейса пользователя, то там совсем другие правила начинают работать.
Понимаете в чем дело, обычно первое что я делаю — как раз собираю примерно похожее на то что должно получиться из стандартных блоков. Которые прекрасно можно было бы накидывать на экран из палитры компонентов и выставлять нужные свойства. Если не нужны кастомные вью (которые вообще на котлине или джаве пишутся) — визуального конструктора достаточно для формирования интерфейсов. Вся нестандартность получается из вложенности одних вью в другие и настройке свойств, прямо как в 1с с управляемыми формами, очень похоже работа выглядит. Но все равно удобнее, быстрее и комфортнее работать с текстом напрямую. Это даже если забыть про всякое вроде конфликтов при мерже где текст вообще безальтернативен.
Странно. ЯП — это всего лишь инструмент. Как можно ненавидеть молоток за то, что им нельзя открутить саморезы?
Единственное, что можно поставить в особенность языка — это изолированную платформу. Т.е. Вы не сможете, поставив некую dll, использовать вставку 1С. И, соответственно, в 1С вставить код на другом ЯП. Но это компенсируется тем, что вместе с ПО идёт IDE. И Вы всегда можете посмотреть, в чём затык и самостоятельно принять меры для его устранения, не ожидая реакции ТП.
Т.е. Вы не сможете, поставив некую dll, использовать вставку 1С. И, соответственно, в 1С вставить код на другом ЯП. Но это компенсируется тем, что вместе с ПО идёт IDE


Чтобы вставить код на другом языке в 1С:

Есть технология внешних компонент в 1С. Еще с прошлой версии 1С она есть, очень давно.

Наоборот — вставить код 1С в другой язык — только вместе с платформой.
У платформы для этого имеются несколько различных механизмов на выбор для вызова функций 1С извне платформы. Часть этих методов еще с прошлой версии 1С есть, то есть очень давно.
Да, с внешними компонентами — это я поторопился. Действительно, защищённые компоненты используются ещё с 7.7.
Мне понятен смысл размещения данной публикации тут. Мне не понятно, почему авторы решили «измерять» мнение сообщества 1С, кинув ссылку на мисту? Инфостарт более объективен в этом плане, разместите вашу статью там. Я уверен, вы получите так желаемую конструктивную критику и мнение сообщества 1С.
Ссылку на мисте кинули не мы, как и все предыдущие ссылки на мисте.
Тогда извиняюсь, сам на мисте не сижу, но после кучи комментариев тут зашел на нее и действительно увидел кучу тем о вашем продукте. Но все таки очень рекомендую выложить все тут описанное на инфостарт. Представителей бизнеса, думаю, там побольше будет.
Кстати согласен, на инфостарте вряд ли зарежут статью, да и коммьюнити там поадекватнее.
В комментариях к прошлой статье я уже писал о том, что автор имеет явно недостаточно компетенций в 1С, чтобы всерьёз обсуждать эту платформу.
Однако он с упорством, достойным лучшего применения, идёт дальше. Причем местами даже не особо напрягается в вопросе придания достоверности тому бреду, который несёт. Ляпы начинаются с самого начала — про якобы неэффективное считывание данных объектов и про регистры.
Квалифицированные специалисты, знающие 1С, сразу видят целый ворох грубых ошибок, которые могут лишь указывать на полнейшее непонимание автором предмета, о котором он пишет.
Неквалифицированные — напитаются очередными мифами об 1С.
Статья — чистой воды черный пиар и попытка раскрутить свой продукт (lsFusion) за счет недостатков другого (1С). И автору совершенно наплевать — о реальных недостатках (которые безусловно тоже есть) идёт речь или о выдуманных и высосанных из пальца.

PS Никогда ни один нормальный специалист не станет обсуждать и уж тем более критиковать ту технология в которой он плохо разбирается. Во-первых, это самого себя не уважать. А, во-вторых, грош — цена такой критики.
PS Никогда ни один нормальный специалист не станет обсуждать и уж тем более критиковать ту технология в которой он плохо разбирается. Во-первых, это самого себя не уважать. А, во-вторых, грош — цена такой критики.


Да, я уже писал выше про ЧСВ некоторых 1С-программистов. Не хотите обсуждать по существу — не обсуждайте. Зачем писать бессмысленные комментарии?
А как можно конструктивно обсуждать бред типа «в 1С объект читается всегда целиком… Как следствие, данных читается… слишком много — если надо получить только одно поле (реквизит)»???

Это ведь классическое передёргивание. Когда смешивается правда (что объект считывается целиком) с откровенной ложью (когда надо получить лишь один реквизит).

Ведь, когда надо получить один реквизит, никто не считывает объект целиком (а если где-то в самописках и встречается подобный *авнокод, то вопросы надо задавать никак не авторам платформы, что какой-то идиот микроскопом гвозди заколачивает). Вообще сама необходимость получения объекта может быть связана только с его модификацией или отображением на форме (форма документа, элемента справочника и т.п.), но никак не для чтения его реквизита(ов).

И такие примеры буквально в каждом третьем абзаце.
Пишем немножко правды и полуправды, добавляем чуть-чуть вымысла, приправляем откровенной ложью с передёргиванием и выдаём всё это за «конструктивную» критику.

Браво! Отличная осмысленная статья!

А что касается ЧСВ программистов 1С, так я им не страдаю.
Я прекрасно знаю огромное количество недостатков платформы 1С и прикладных решений. В том числе в сравнении с другими средами и платформами. Только претензии эти имеют мало общего с тем, что Вы тут накропали. Это во-первых.
А во-вторых, я никогда не стану писать что-либо о технологии, в которой недостаточно глубоко разбираюсь. У Вас же рука даже не дрогнула. И у кого из нас раздутое ЧСВ?..
Давайте так, если вы не поняли, о чем статья, не переживайте. Значит статья не для вас. Тот кто мог или хотел, тот понял.
Ведь, когда надо получить один реквизит, никто не считывает объект целиком (а если где-то в самописках и встречается подобный *авнокод, то вопросы надо задавать никак не авторам платформы, что какой-то идиот микроскопом гвозди заколачивает). Вообще сама необходимость получения объекта может быть связана только с его модификацией или отображением на форме (форма документа, элемента справочника и т.п.), но никак не для чтения его реквизита(ов).

В том и беда что это является говнокодом в 1с. Могли хотя бы костыль зафигачить вроде объявления считываемых данных для объектов для блоков кода (например аннотировать процедуру или модуль что любые обращения через точку считывают только указанные в аннотации реквизиты/ТЧ). Потому что нередко это бывает необходимо для бизнес логики, а не только для записи/отображения. Для массового чтения можно было бы сделать костыль вроде передачи объектов списком в специальную процедуру встроенную, и тогда бы за один запрос были прочитаны только нужные поля с последующим кешированием для обращения «через точку», но можно было бы работать с объектами, а не структурами, как сейчас нам предлагают сделанные для этих целей функции бсп. Наверняка можно и по человечески сделать, а не костылями как я описал, просто это что первое в голову пришло. Вот честно, ОбщегоНазначения.ПрочитатьРеквизит(СсылкаНаОбъект, «Наименование») и ей подобные выглядят ужасно и пользоваться ими неудобно, не говоря уж что кешировать приходится вручную если нужно, хотя можно было бы еще и этим управлять.
Предположу такой сценарий, что надо сделать групповое изменение определённого атрибута у группы документов, отобранных по определённым критериям. Как это будет происходить в 1С? Загружаем к себе весь документ, меняем атрибут, пихаем обратно в базу?
Ну вот у меня спец по платформе (2 с копейками года назад примерно получен), опыт работы с 1с 4 года, участие в разработке отраслевой конфы (1С: ТОИР), внедрение ее на проектах (в т.ч. последний проект длился 2 года, и используется более чем 1к обычных пользователей и 2к мобильных), и я с автором согласен во многом, пусть местами не полностью. Я не компетентен в 1с?
Ну местные 1С-программисты потратив на изучение lsFusion на порядок меньше времени, чем я на 1С, почему-то не смущаются заявлять, что да тут те же проблемы и «очередной убийца 1С».

Плюс, посмотрите на самый заплюсованный комментарий, не согласны — напишите по пунктам с чем, как комментатор веткой ниже.
Ну местные 1С-программисты потратив на изучение lsFusion на порядок меньше времени, чем я на 1С, почему-то не смущаются заявлять, что да тут те же проблемы и «очередной убийца 1С».


Мало ли чего пишут технари.

За последние 20 лет я таких «убийц 1С» видел 5 штук.

Есть два подхода — чисто технический. Технарям нравится, это уже хорошо.

Но есть еще и подход бизнеса и экономики.
А бизнесу ваше решение — это все равно что на голом С им бы писали систему — специалисты далеки от прикладных задач, разработка более трудоемкая.

1С сильна тем, что предлагает типовые решения, которые уже большей частью устраивают народ.

Без этого — я не очень понимаю смысла вашей системы.
Ведь простейшие вещи я и на голом универсальном языке программирования напишу, не на lsFusion (разумеется буду использовать доп. инструменты для интерфейсов и т.п.).

А сложные — это дорого очень, мало кто оплатит. Так что если вещь не узкоспециальные требования имеет, которые с 1С плохо уживаются — то проще взять решение на базе 1С. И заказчик это тоже понимает, хотя бы по доступности решений/специалистов.
Ведь простейшие вещи я и на голом универсальном языке программирования напишу, не на lsFusion (разумеется буду использовать доп. инструменты для интерфейсов и т.п.).


Ну напишите вот эти: раз, два, три.

Посмотрим сколько у вас на это времени уйдет и сколько будет строк кода.
Ведь простейшие вещи я и на голом универсальном языке программирования напишу, не на lsFusion (разумеется буду использовать доп. инструменты для интерфейсов и т.п.).


Ну напишите вот эти: раз, два, три.

Посмотрим сколько у вас на это времени уйдет и сколько будет строк кода.


Утрируйте. То, что вы привели — это как раз целесообразнее именно на 1С сделать.

P.S.:
Интересно, а у вас эти три приведенных вами вещи — сколько заняли?
За последние 20 лет я таких «убийц 1С» видел 5 штук.

Ну вот вы тоже самое делаете.
Ну назовите хоть один, у которого не было хотя бы половины из 21 проблем в статье. Ну или хотя бы треть возможностей из этого списка. Ничего близко похожего на самом деле до еще не было. Так что взлетит или не взлетит можно пока только гадать.
Чтобы расковырять ваши недостатки — вами нужно сначала занитересоваться и глубоко вникнуть. Однако пока не зачем это делать, извините.

Вы не показали в чем ваши существенные премущества по совокупности. Какие-то отдельные косячки — несерьезно. Они и у вас есть, конечно же.

А вот с более существенными вещами — с прикладными решениями и поддержкой российского законодательства — все грустно у вас.

Предлагаете потратить на вас кучу времени просто потому что вы написали какие вы крутые? Гм. Да тут каждые 10 из 10 фирм на Хабре так пишут о себе.

Тут замнутный круг, я понимаю. Но ничем помочь не могу. Статья воспринимается не убедительно, черезчур ангажировано. Только часть доводов правдива.

Вы можете взять в штат высококвалифицированного 1С-ка, если уж решили делать «убийцу 1С». Тогда и ваши статьи и ваше развитие будет против реальных, а не мнимых недостатков 1С.
www.ultimatebusinessware.ru/2c/vs
Один из «убийц».
Но, как я понимаю, 1С господствует именно из за модели франчайзи.
И, как мы знаем, выживают не самые идеальные, а самые приспособленные :)
Просили же LGPL, а не коммерческую платформу.
Ну и как у них с вышеописанными 21 проблемами? Те же яйца только в профиль?
Автор путает мягкое с теплым, к тому же знания автора об 1С всеобъемлющие но не доскональные, а в некоторых местах автор сам признается, что некоторую идеологию 1С он трактует неправильно:
Фактически ключевое отличие этих двух понятий заключается в том, что объекты используются для записи и чтения, а ссылки — только для чтения

Объекты используются только для записи! в тоже время ссылки никогда не должны использоваться для чтения данных. Ссылка — в терминах sql это первичный ключ таблицы плюс сама таблица. Таким образом если метаобъект в конфигурации является ссылочным типом, то по ссылке мы можем получить указатель на таблицу базы данных плюс конкретную запись в этой таблице. Если же нужен доступ к данным, то как и в классическом SQL нужно использовать запрос. И в высоко нагруженных системах так и должно происходить. Обращение к реквизиту по ссылке допустимо, но скорее всего оставлено как пережиток прошлого из 7.7, где самого понятия ссылочного типа не было в явной форме.

В принципе этого уже достаточно, чтобы скептически относится к рассуждениям автора, на тему «почему 1с плохая и даже убогая». Но тем не менее позвольте пройтись по некоторым пунктам…
В 1С объект читается всегда целиком, в том числе с табличными частями, но не более того (без каких либо связанных данных). Как следствие, данных читается:

либо слишком много — если надо получить только одно поле (реквизит)
либо слишком мало — если в цикле надо обращаться к другим объектам по ссылке, мы получаем классическую проблему N+1 (один запрос для получения N объектов и по одному запросу для каждой ссылки).

Зачем создавать объект, чтобы прочитать только один реквизит? Для каких целей понадобилось обращаться к другим объектам в цикле? Что это за конструкция такая, в которой данные объекта зависят от других объектов? Автор тут конкретно не догоняет, что такое объекты и для чего они нужны. Но тем не менее делает вполне конкретный вывод
Такая убогость механизма ORM в 1С на самом деле обусловлена тем, что...

далее про регистры
Являясь по сути не более чем представлениями в SQL, усовершенствованными для работы со временем, представления в 1С наследуют (а иногда даже и усугубляют) все проблемы представлений в SQL.

тут автор совсем не понимает, что такое регистр. По его мнению регистр это одна таблица плюс его представление (СрезПоследних, ОстаткиИОбороты и т.д.). На самом деле все гораздо сложнее: регистр в 1с это агрегирующий объект и связан он не с представлениями (aka View), а с промежуточными итогами, которые на самом деле представлениями никак не являются. Не знаком с lsFusion чуть менее чем совсем, но в одном из how-to там увидел механизм контроля остатков (Управление материальными запасами)
receivedQuantity 'Суммарный приход' = GROUP SUM quantity(ReceiptDetail d) BY item(d), stock(receipt(d));
shippedQuantity 'Суммарный расход' = GROUP SUM quantity(ShipmentDetail d) BY item(d), stock(shipment(d));
currentBalance 'Текущий остаток' (Item i, Stock s) = receivedQuantity (i, s) (-) shippedQuantity (i, s);

т.е. чтобы посчитать остаток запаса на складе, нужно взять приход и вычесть из него расход. Только хочется посмотреть, как это будет работать если записей в таблице овер дофига и нужно внести изменения «задним» числом. Тут конечно можно порассуждать, а давайте отделим оперативную базу от аналитической и вместо одного решения у нас будет два, а потому будем объяснять главному бухгалтеру, почему вчера эта циферка была такой, а сегодня она другая.
Фактически, регистры в 1С поддерживают всего две операции: сумма и последнее по дате, сгруппированные по ключам таблицы

промежуточные итоги они еще поддерживают. Сумму можно узнать за любой промежуток времени и последнее по дате можно узнать на любую дату. Представления конечно было бы круто иметь, только отсутствие оного особого неудобства это не создает. Если для каких-то особых задач оно все-таки понадобиться, то представления можно сделать средствами SQL, ведь доступ к физической модели ЕСТЬ, хоть автор и утверждает обратное. Но представлений в 1С нету не изза того что 1С не может их сделать. Они просто не нужны для выполнения тех задач, под которые 1С заточена.
В параметрах виртуальных таблиц можно использовать только константы

Автор имеет представление что такое виртуальная таблица, но как ей пользоваться — нет, к тому же сравнение ее с представлением неправильно. Виртуальная таблица — это не представление, а результат запроса к таблице регистра (движения плюс промежуточные итоги). Соответственно если параметры виртуальной таблицы меняются, то меняется и сама таблица. Как пример автор приводит абсолютно неоптимальный запрос, рабочий но не оптимальный. Скорее всего это изза того, что автор про пакетное исполнение запроса ничего не слышал.
Но так как, в отличии от SQL, в запросах 1С отсутствует механизм изменения данных (так называемый DML), использование запросов никак не может помочь в вопросах записи большого количества данных. То есть, если вам понадобится создать сто тысяч дисконтных карт, вам придется вернуться назад в ORM

было бы круто в 1с писать чтото «ОБНОВИТЬ РасходнаяНакладная КАК рн УСТАНОВИТЬ рн.Статус=ЗНАЧЕНИЕ(Перечисление.СтатусыРасходныхНакладных.Отгружена) ГДЕ рн.Ссылка = &Ссылка)». Порой этого действительно не хватает, если рассматривать данные когда они отделены от алгоритмов их обработки. К примеру выше если накладная закрыта, то нужно увеличить задолженность контрагента. Но на практике это редко применимо, в основном это требуется, когда нужно срочно чтото исправить, потому что ктото накосячил или при первоначальном заполнении (как часто требуется создание ста тысяч дисконтных карт?).
Верхом садизма при этом является отсутствие в 1С замыканий и передачи функций в качестве параметров. То есть переменные контекста нужно самому сохранять, например, в какую-нибудь структуру, после чего передавать эту структуру параметром явно созданной и именованной процедуре обработке результата. В итоге получается что-то зубодробительное вроде

Тут вообще ничего не понятно. Тот же самый питон движется в сторону отказа от синхронного многопоточного программирования в сторону корутин и асинхронных вызовов. Что не так с асинхронностью в 1С? А я скажу что не так: его там мало! Оно там используется только в тот момент, когда требуется прервать поток для ожидания действий пользователя. У разработчика нет возможности созданиях асинхронных вызовов и когда оно действительно нужно, приходится уже изголяться.
Соответственно для этого в 1С и отделили данные формы от просто данных, но при этом в попытках сделать это разделение менее явным создали ряд очень странных абстракций. Например, класс в скобочках. Который выглядит как класс, крякает как класс, но не класс (например методы этого класса вызывать нельзя)

Данные формы не являются данными объекта. Данные формы это отображение данных объекта. Т.е. открыть форму не подразумевает под собой открыть объект. Объект создается в момент записи данных формы, а не в процессе открытия формы. Если понимать как это работает, то на самом деле можно создавать довольно универсальные вещи. Обобщенно в большинстве случаев данные формы должны равняться данными объекта, но в ряде случаев 1С позволяет создавать универсальные формы, для различных объектов (см. конфигурацию Документооборот, как там реализован механизм вызова формы задачи бизнес процесса). Если понимать как это работает — можно создавать достаточно интересные вещи.
И если с данными формы такое разделение было во многом вынужденным, то зачем понадобилось разделять команды формы и действия, я, если честно, не совсем понял. Может в комментариях кто-нибудь сможет это объяснить

Какие действия?
В общем получился какой-то франкенштейн, который при этом по функционалу пересекается с половиной других абстракций в 1С. В которые (например, формы) они еще и попытались интегрировать этот СКД. В результате понять что, где, когда и как нужно использовать — задача весьма неочевидная

Рядовому пользователю нет необходимости понимать как работает СКД, в 99% случаев ему нужно настроить вариант отчета, с которым он потом и будет работать. Другой аспект — это СКД с точки зрения разработчика. Механизм достаточно сложный, но если его освоить, то скорость разработки отчетов и интерактивной выборки данных (а именно для этого используется СКД), повышается в разы и там нет никакой громоздкости.
Как интерактивный интерфейс, то есть замена формам, СКД также плохо подходит, так как не умеет и половину того, что умеют формы

Автор опять путает теплое с мягким. Зачем сравнивать СКД с формой? Это как? СКД не умеет многое того что умеет форма? Это тоже самое что лошадь не умеет много того, что умеет кофеварка. На самом деле открывая СКД автор, открывает форму, если СКД в отчете, то открывается форма отчета указанная в настройках, и она может быть универсальная, одна на всех. А может быть своя собственная, конкретно для данного случая. Гибко и просто.
Про фатальные недостатки хочется спросить только одно? ЗАЧЕМ???
Фатально — это значит обреченно. 1С обречена из-за того не умеет GIT и Eclipse? Зачем нужен PIP в 1С?
Зачем нужные открытые репозитории в 1С когда весь девелопемент в 1С сводится к настройке типового решения, и этот девелопемент в 100% сугубо индивидуален для каждого заказчика. В большинстве случаев растиражировать готовое решение для конкретного заказчика на массовый сегмент — это не что иное, как пердеть в океане. Я понимаю в питоне форкнуть чужой проект, внести в него корректировки, установить зависимости и выложить обратно на GIT, как-то оправдно с точки зрения того, что это потом кому-то будет нужно. Но в 1С это зачем? Думаете кому-то поднадобится шлак, который Вы внедрили в ООО «Рога и Копыта»? Внедрений в 1С сделаны сотни тысяч, до отраслевых решений дошли всего десятки, и все эти решения получили статус «1С совместимо» и лежат в официальном репозитории 1С. И там есть контроль версий!!!
весь девелопемент в 1С сводится к настройке типового решения

Аж подгорает. А о тех кто свои решения пишет вы думали? Ну и не путайте гит и гитхаб.
Что о них нужно думать? Я не отрицаю что существуют конфигурации написанные «с нуля» и они где-то используются. Но в основной своей массе, именно так как я и говорил. Внедрение = настройка типового решения. И чем дальше, тем процесс более очевидный.
Ну во первых эти типовые решения пишут в самом 1с, во вторых всякие 1с совместно и совместимо пишутся кучей разработчиков по стране. И им хочется комфорта и эффективности.
Я это знаю, меня интересует из-за чего у Вас подгорает? Вам хочется комфорта и эффективности, но эска к Вам несправедливо сурова? Вам что-то мешает создать решение, выложить его в открытый доступ, чтобы люди пользовались и радовались? Как взаимосвязаны процессы внедрения 1С с критикой качества платформы в этой статье?
При чем здесь внедрение? Лично я эту статью вижу в первую очередь как критику платформы для разработчиков решений, либо для долговременной поддержки и развития готовых решений. А мешает сделать своё несравнимый объем ресурсов меня и 1с. Я просто предпочел с 1с свалить, как довольно простой выход.
А подгорает из за того что вы почему то рассматриваете «весь девелопемент в 1С» как «настройку типового решения», а другого почти не существует по вашему.
Эта статья — в первую очередь реклама своего решения за счёт известности 1С. Всё остальное — вторично.
Ну это понятно, но тем не менее статья вполне качественная на мой взгляд.
Обычная рекламная статья, где недостатки платформы, которую lsfusion непонятно почему записали в свои конкуренты, преувеличены, а достоинства не упомянуты совсем.
Ну не сильно они и преувеличены, хотя я и не по всем пунктам согласен. Часть из них могут послужить причиной разработчику уйти, как в моем случае.
Так в том и дело, что те, кто работают с 1С, прекрасно о большинстве этих проблем осведомлены, а бизнесу эти проблемы не интересны. Для кого же эта статья тогда написана? Чтобы те, кто и так считали, что 1с — это шлак, остались при своём мнении?
Для чего статья написана — вы и так написали раньше, для рекламы lsFusion среди разработчиков. Возможно для тех 1сников что не пробовали другие технологии и потому могут не замечать минусов 1с отсутствующих у других (или имеющихся в меньшем объеме).
Тем не менее обсуждать верны ли или нет перечисленные недостатки не мешает, кому бы статья ни была предназначена.
Хмм… 1С-ники, не замечающие проблем 1С, смогут работать на lsfusion? Не думаю… И опять же, вы, например, перешли бы с 1С на lsfusion?
Я lsFusion не изучал пока, потому трудно сказать, интерес по крайней мере появился, может и посмотрю в очередном отпуске, но с 1с я ушел именно из за части перечисленных проблем. Правда я вообще ушел не в разработку бизнес приложений.
Я имел в виду девелопмент у конечного заказчика. В 90 % случаев он сводится к настройке типового решения. Увы это так. Все остальное это узкоспециализировано и малопригодно для «решения из коробки». Не типовые решения существуют, но их очень мало. Но это не особенность платформы, а особенность российского бизнеса. Если на западе «best practices» что-то значит и твоя карьера действительно зависит от того, насколько ты хорошо эти практики знаешь, то в России все несколько по другому. Зачастую ход процесса внедрения зависит от компетенции топ-менеджмента. Зачастую многие топы сами не понимаю чего они хотят, но твердо уверены, что если поставить 1С то все у них будет в шоколаде. Качество платформы 1С тут обсолютно не причем.
Тем не менее это не все случаи. Да и внедрение может заключаться в переписывании огромного куска функциональности и выкидывании трети существующего кода. И проект по внедрению может идти несколько лет силами нескольких разработчиков.
Кто же спорит что все это возможно? Другое дело кому это нужно и насколько востребовано повсеместно.
Я так понимаю разрабы lsFusion на повсеместность и не сильно претендуют (по крайней мере из того что я понял).
Объекты используются только для записи! в тоже время ссылки никогда не должны использоваться для чтения данных. Ссылка — в терминах sql это первичный ключ таблицы плюс сама таблица. Таким образом если метаобъект в конфигурации является ссылочным типом, то по ссылке мы можем получить указатель на таблицу базы данных плюс конкретную запись в этой таблице. Если же нужен доступ к данным, то как и в классическом SQL нужно использовать запрос. И в высоко нагруженных системах так и должно происходить. Обращение к реквизиту по ссылке допустимо, но скорее всего оставлено как пережиток прошлого из 7.7, где самого понятия ссылочного типа не было в явной форме.

В принципе этого уже достаточно, чтобы скептически относится к рассуждениям автора, на тему «почему 1с плохая и даже убогая». Но тем не менее позвольте пройтись по некоторым пунктам…

В 150 раз. Тезис простой — ORM в 1С есть (пережиток 7.7 или нет не важно). Он убогий, и 1С решили от него отказаться и правильно сделали (тут конечно ORM'ки не согласятся, но имеют право). Вы же просто подтвердили, что я написал.
Зачем создавать объект, чтобы прочитать только один реквизит? Для каких целей понадобилось обращаться к другим объектам в цикле? Что это за конструкция такая, в которой данные объекта зависят от других объектов? Автор тут конкретно не догоняет, что такое объекты и для чего они нужны. Но тем не менее делает вполне конкретный вывод

Вы похоже не знаете, что такое ORM, проехали, не читайте этот пункт (он для тех кто знает что это такое, и как это реализуется в других технологиях).
регистр в 1с это агрегирующий объект и связан он не с представлениями (aka View), а с промежуточными итогами, которые на самом деле представлениями никак не являются

Это называются материализованные представления это тоже упомянуто в статье. И в пункте про константу в качестве параметров промежуточные итоги тоже упомянуты.
Только хочется посмотреть, как это будет работать если записей в таблице овер дофига и нужно внести изменения «задним» числом.

В lsFusion есть материализация показателей. Читать тут (ссылка в статье тоже есть).
промежуточные итоги они еще поддерживают. Сумму можно узнать за любой промежуток времени и последнее по дате можно узнать на любую дату. Представления конечно было бы круто иметь, только отсутствие оного особого неудобства это не создает. Если для каких-то особых задач оно все-таки понадобиться, то представления можно сделать средствами SQL, ведь доступ к физической модели ЕСТЬ, хоть автор и утверждает обратное. Но представлений в 1С нету не изза того что 1С не может их сделать. Они просто не нужны для выполнения тех задач, под которые 1С заточена.

Представления это механизм декомпозиции и повторного использования (смотрите статью про SQL). И он очень важен с учетом перехода 1С на голый SQL. Без них получают миллионы строк не самого качественного кода, что мы и наблюдаем в типовых.
Соответственно если параметры виртуальной таблицы меняются, то меняется и сама таблица.

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

Да прям-таки. Автор такие вещи знает про SQL, о которых вы и не задумывались (почитайте хотя бы про SQL статью).
Тут вообще ничего не понятно. Тот же самый питон движется в сторону отказа от синхронного многопоточного программирования в сторону корутин и асинхронных вызовов. Что не так с асинхронностью в 1С? А я скажу что не так: его там мало! Оно там используется только в тот момент, когда требуется прервать поток для ожидания действий пользователя. У разработчика нет возможности созданиях асинхронных вызовов и когда оно действительно нужно, приходится уже изголяться.

Вы вообще в курсе что такое замыкания и передача функций в качестве параметров? На JavaScript посмотрите и как там эти вещи решаются.
Если понимать как это работает — можно создавать достаточно интересные вещи.

А можно не городить огород и тоже создавать достаточно интересные вещи. Особенно с учетом того, что задача 1С разработчика решать бизнес-задачи, а не создавать интересные вещи.
Рядовому пользователю нет необходимости понимать как работает СКД, в 99% случаев ему нужно настроить вариант отчета, с которым он потом и будет работать.

Где вы таких пользователей берете. Они с отбором с трудом разбираются, а вы про настройку отчета.
Автор опять путает теплое с мягким. Зачем сравнивать СКД с формой? Это как? СКД не умеет многое того что умеет форма?

Сто раз уже обсуждалось почему. Например почитайте комментарии в статье про подбор.
Про фатальные недостатки хочется спросить только одно? ЗАЧЕМ???

Вы шутку про фатальный недостаток знаете?
Фатально — это значит обреченно. 1С обречена из-за того не умеет GIT и Eclipse? Зачем нужен PIP в 1С?
Зачем нужные открытые репозитории в 1С когда весь девелопемент в 1С сводится к настройке типового решения

Про это все рассказано в разделе про модульность.
В 150 раз. Тезис простой — ORM в 1С есть (пережиток 7.7 или нет не важно). Он убогий, и 1С решили от него отказаться и правильно сделали (тут конечно ORM'ки не согласятся, но имеют право). Вы же просто подтвердили, что я написал.


Тут разговор был о том, что автор не до конца понимает различие между объектом и ссылкой 1С а не ОРМ. Цитата В 1С объект читается всегда целиком, в том числе с табличными частями, но не более того (без каких либо связанных данных). Как следствие, данных читается… либо слишком много — если надо получить только одно поле (реквизит). Зачем создавать объект в 1С когда требуется прочитать один реквизит? Объясните мне что тут хотел донести до читателя автор, ведь с точки зрения 1С это абсолютная тупость. Этот момент у меня не укладывается в голове, хотя опыт использования SQLAlchemy у меня есть.
Зачем создавать объект в 1С когда требуется прочитать один реквизит?

Подозреваю что автор больше акцентировал на том, что нельзя прочитать часть объекта в переменную типа "ДокументОбъект". Ну вот не нужна мне табличная часть в данный момент, например.
На самом деле прочитать можно — запросом в структуру/соответствие/таблицу например. Только это уже не ДокументОбъект, а просто набор переменных.


Хотя, ради справедливости, в применении к 1С необходимость такого сомнительна.

На прошлой работе сильно страдали, был один «божественный» справочник, для оптимизаций чтения и записи приходилось кучу данных хранить в регистрах вместо табличных частей или реквизитов. Плюс с этим справочником нередко была нужна массовая работа с элементами, и запись пары десятков тысяч элементов при работе пользователей в базе была тем еще «удовольствием».

Массовая работа — это да, отдельная история. Не зря вон разные удаления помеченных напрямую запросами SQL люди пишут.
В вашей ситуации наверняка помогли бы "UPDATE xxx SET yyy=zzz", но этого в 1С нету )

Увы, не помогло бы. Все таки нередко нужно чтобы триггеры срабатывали и при массовых апдейтах (хотя в 90% все равно Объект.ДополнительныеСвойства.Вставить(«ОтключитьПроверки») или подобное писали).
Адекватный механизм тут построить сложно, но можно, просто это от 1с много работы потребовало бы.
Вот тут и идет самая главная путаница:
Объект.ДополнительныеСвойства.Вставить(«ОтключитьПроверки»)

это вопрос не к платформе, а к разработчикам прикладного решения, а еще раньше к консультантам, которые данное прикладное решение выбрали. Если на 1С написать хрень собачью, то будет хрень собачья написанная на 1С. Если хрень собачью написать на C#, то будет хрень собачья написанная на си шарп. Что будет если написать хрень собачью на lsFusion никто не знает, возможно это будет радуга с розовыми единорогами… ведь никто никогда этого не делал
Начал было писать что вы неверно поняли посыл в контексте обсуждения (частичного vs полного чтения объекта aka частичного vs полного срабатывания триггеров), но потом стало лениво слишком, да и не уверен что друг друга понять сможем.
Если сравнивать 8.3 с той же самой 8.0 — то разница глобальная. Возможно в 8.4 будут те же самые представления и передача функций в качестве параметров. Другой вопрос — зачем это нужно? Есть задачи с которыми 1С справляется на УРА оставляя позади конкурентов (в России Бухгалтерия Предприятия 3.0 это отраслевой стандарт де факто), есть задачи где эску лучше не использовать (как-то видел интернет магазин на http сервисе). В конкретно каждом случае нужны конкретные решения.

П. С. согласен что замыканий на самом деле не хватает, но я в принципе изначально об этом написал — асинхронности в 1С мало. Автор статьи же заявляет что отказ от синхронности как один из недостатков
Я так понимаю скорее не отказ от синхронности как недостаток, а невозможность написания асинхронного кода как синхронного.
async/await какие нибудь или как корутины в котлине. Впрочем уверенности что автор тут имел в виду у меня нет, так что настаивать не буду.

Вы, похоже, хорошо знаете 1С, но не так хорошо другие технологии.
Пара замечаний:
1) Представления не помешали бы, хотя без них тоже, конечно, можно. Как можно было в одной из первых УПП на 8.0 когда все модули глобальные (если память не подводит), или в 7.7 с только одним глобальным модулем :) Ну или без модулей менеджеров объектов — тоже можно было ведь;
2) Замыканий на самом деле очень не хватает. Без них приходится делать портянки из функций, в итоге если использование веб-клиента не требуется, то многие просто забивают на асинхронность.

Странная и длинная статья. Часть критики абсолютно верная и имеет место быть. Однако… Рассматривать качества системы направленной на пользователя с точки зрения инженера это неверно. Ну например с технической точки зрения ГАЗ-66 это шедевр. Если случится ядерный апокалипсис, то ездить будут только такие машины. Надежные и абсолютно ремонтопригодные. Для того чтоб разобрать и собрать такую нужен только стандартный набор инструментов, который идет в комплекте с автомобилем. Однако с точки зрения пользователя это «адова тарантайка». Так вот с точки зрения пользователя 1С это лучшее решение на рынке. Почему?
1. Дешево. Я б даже сказал очень дёшево. Базовую версию любой типовой конфигурации можно купить за копейки и сразу начать вести учет в программе. УНФ в этом плане просто великолепна. И не нужно ничего программировать. И даже лицензии уровня ПРОФ и КОРП стоят по сравнению с MS Dynamics и SAP очень дёшево.
2. Программирование нужно только когда владелец бизнеса развивает свой бизнес. И даже в этом случае это не всегда нужно. Спектр уже предлагаемых готовых решений перекрывает практически все отрасли. И это основное преимущество 1С и даже на крупных проектах редко пишется что то с нуля.
3. Конечный клиент никогда не выберет учетную систему по принципу «Чтоб было удобно программисту работать». А выбор бизнес системы всегда за конечным клиентом. Поэтому доводы данной статьи они ничтожны.
4. И даже если рассматривать критику по существу, то собственно часть доводов статьи у меня как у действующего программиста 1С вызывает закономерный вопрос. Да это так, но нафига это вообще нужно в 1С? Часть… Ну да, это недостаток, но в общем то не мешает работать. А часть это откровенная чушь. Ну например то, что 1С не умеет работать с git. Ну во первых если есть прямые руки и прям такая необходимость, то можно заставить работать его даже с конфигуратором. EDT работает с git из коробки.
Не очень понимаю, зачем Вы сравниваете конфигурацию с платформой? Да, у 1С — плюс, что есть много готовых решений. Но это не отменяет недостатков платформы, описанных в статье.

EDT работает с git из коробки.

А подскажите, как Вы собираетесь мерджить сгенерированные при помощи визуального программирования XML файлы?
А подскажите, как Вы собираетесь мерджить сгенерированные при помощи визуального программирования XML файлы?


это вообще вопрос вопросов…

ибо декларация управляемой формы в 1с это мягко говоря не xaml

но тут 1С — как обычно «доступно и всерьез»

сделала нечто похожее на настоящее, но не работающее. главное задекларировать что «у нас тоже»
Так в том и проблема, что 1С многие вещи делает по принципу, чтобы было как у всех. Но на практике получается велосипед как на картинке.
это проблема потребителя — ему эти тонкости не интересны. ему главное обеспечить себе прикрытие от фискальных органов

это проблема разработчика — но ему не привыкать. а которым скд последний мозг отбила еще и радостно хавают то, что им в корыто выливают
Люди когда-то и на ассемблере писали. Но все меняется и используемые платформы тоже. Основной посыл, что не стоит начинать нетленки писать на 1С, а лучше брать что-то лучше.
лучше/хуже познается в сравнении

а кто в среде 1с имеет опыт выходящий за ее пределы? по большому счету единицы

кому вы там будете рассказывать про паттерны? про концепции типа solid?
Мы — никому. Как раз в lsFusion сейчас порог вхождения гораздо ниже, чем в 1С и там ничего не надо знать. Разработка на 8.3 с диким набором абстракций по сложности уже сопоставима с JS разработкой. Видели на мисте темы типа «Буду использовать только ОФ». Это не спроста.
Мы — никому. Как раз в lsFusion сейчас порог вхождения гораздо ниже, чем в 1С и там ничего не надо знать. Разработка на 8.3 с диким набором абстракций по сложности уже сопоставима с JS разработкой.


Вы это серьезно?
1С одна из платформ с низким порогом входа, с которыми мне довелось поработать за последние 30 лет. Её же не нужно всю досканально изучить прежде чем начать работать. Базовых используемых в 95% случаев абстракций очень мало.

Если у вас еще проще — то тут уже начинают действовать закономерности: чем гибче и универсальнее платформа — тем больше нужно знаний, тем более специализированный специалист нужен. Если у вас специалист не нужен, то, есть существенные ограничения по функционалу, по универсальности применения.

А о каком тогда сравнении с 1С может идти речь?
Вы на разных сегментах рынка работаете.

Так и я могу сказать, что моя написанная на коленке за 2 дня утилита работает быстрее, чем 1С и lsFusion на этой задаче. Но то, что кроме этой задачи она больше ничего у меня выполнять не умеет — скромно промолчу. А написать подобную утилиту может любой программист средней руки.

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

Попробуйте lsFusion и удивитесь. Возьмите хотя бы примеры из статей и увидите насколько проще.
Видели на мисте темы типа «Буду использовать только ОФ»

видел. автора макнули в коричневое

причем люди настолько некомпетентные в 1с что только диву даешься — им видите ли привязки жить не дают… ну и сама 1с — вместо допилки ОФ — до вменяемого уровня сделали какую-то пародию на xaml. особенно доставляли первые версии — где надо было для построения формы сложнее «2+2» натыкивать в группы невидимые надписи, сплиттеры и прочие костыли

Разработка на 8.3 с диким набором абстракций


это особо никого не парит. что концепцию надо «чистить»… убрать независимые регистры сведений — слить его со справочником, а зависимые от регистратора регистры сведений и накоплений свести в одну сущность… выпиливать объекты которые никому не нужны типа «анализ данных»… что-то сделать с регистром бухгалтерии — чтобы он не был таким тормозным… linq ввести чтобы убрать простыни кода по выборкам из коллекций. и еще кучу всего

но проще на базе этого франкинштейна с родовыми травмами еще из 7.7 пытаться лепить «корпоративные продукты» и пихать их всем
Если все это сделать, то и получится lsFusion.
Да не пишет никто нетленки под 1С, если это изначально не контора, связанная с 1С/имеющая штат программистов 1С.
UFO just landed and posted this here
Не очень понимаю, зачем Вы сравниваете конфигурацию с платформой? Да, у 1С — плюс, что есть много готовых решений. Но это не отменяет недостатков платформы, описанных в статье.

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

Только то же самое можно на лучшей платформе можно делать быстрее, дешевле и качественнее. Но если у вас почасовая оплата, то вам конечно все равно. А это проблемы заказчика.

вот именно на это заточена платформа 1С и с этой задачей она прекрасно справляется и перечисленные «недостатки» никак на это не влияют

Мы живем в самой лучше стране в мире. И все остальные страны нам завидуют.
Только то же самое можно на лучшей платформе можно делать быстрее, дешевле и качественнее. Но если у вас почасовая оплата, то вам конечно все равно. А это проблемы заказчика.

С чего Вы взяли что будет быстрей и качественней? Нет не будет или будет, но несущественно. Дешевизна, качество и скорость проекта по внедрению системы учёта очень слабо зависят выбранной платформы. Проблематика внедрения ERP систем гораздо шире чем техническая составляющая отдельно взятой платформы.
Мы живем в самой лучше стране в мире. И все остальные страны нам завидуют.

А это вы зачем написали? Вам не нравится так не живите. Вас никто не заставляет.
С чего Вы взяли что будет быстрей и качественней? Нет не будет или будет, но несущественно. Дешевизна, качество и скорость проекта по внедрению системы учёта очень слабо зависят выбранной платформы.

Это все равно что говорить, что скорость прохождения трассы не зависит от автомобиля. На тракторе вы никогда гонку не выиграете.

lsFusion фундаментально отличается от всего что есть на рынке. Это грубо говоря как сравнивать эпоху до SQL, и после SQL (а по уровню новых идей lsFusion возможно даже превосходит SQL). Хотя уверен, что даже когда появился SQL говорили:
Проблематика внедрения ERP систем гораздо шире чем техническая составляющая отдельно взятой платформы.
Это все равно что говорить, что скорость прохождения трассы не зависит от автомобиля. На тракторе вы никогда гонку не выиграете.

Не удачное сравнение. Скорость внедрения решения не зависит от скорости разработки. Чем меньше объем разработки тем лучше это решение. И тут не будет разницы на сколько быстро ведется разработка. 1С при внедрении на начальном этапе позволяет вообще обходится без разработки или с минимальным объёмом.
lsFusion фундаментально отличается от всего что есть на рынке. Это грубо говоря как сравнивать эпоху до SQL, и после SQL (а по уровню новых идей lsFusion возможно даже превосходит SQL). Хотя уверен, что даже когда появился SQL говорили:

Я с этим и не спорю. Вполне себе возможно. 1С это не самая лучшая с технической точки зрения платформа. Однако… Еще раз повторяю конечного клиента очень слабо интересует технические подробности системы учёта. Гораздо важней правильность ведения учёта. А учёт можно вести и в бумажных журналах.
Не удачное сравнение. Скорость внедрения решения не зависит от скорости разработки. Чем меньше объем разработки тем лучше это решение. И тут не будет разницы на сколько быстро ведется разработка. 1С при внедрении на начальном этапе позволяет вообще обходится без разработки или с минимальным объёмом.

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

Скажем вспоминая последние 5 проектов, в том же УТ нужно было бы очень много чего допиливать. То есть как-то их процессы может и можно было бы закрыть, но именно что как-то (через одно место), на что клиенты были просто категорически несогласны и просто разорвали бы договора.
Я с этим и не спорю. Вполне себе возможно. 1С это не самая лучшая с технической точки зрения платформа. Однако… Еще раз повторяю конечного клиента очень слабо интересует технические подробности системы учёта. Гораздо важней правильность ведения учёта. А учёт можно вести и в бумажных журналах.

Нет никакой правильности, если мы не про бух и налоговый учет говорим. Клиент всегда прав. А если не прав смотри пункт 1.
1. Дешево. Я б даже сказал очень дёшево. Базовую версию любой типовой конфигурации можно купить за копейки и сразу начать вести учет в программе. УНФ в этом плане просто великолепна. И не нужно ничего программировать. И даже лицензии уровня ПРОФ и КОРП стоят по сравнению с MS Dynamics и SAP очень дёшево.

Вы же понимаете, что лицензии это малая часть стоимости владения. Самое дорогое это доработки и внедрение под специфику. А «пришло-ушло-осталось» и так уже у всех есть.
2. Программирование нужно только когда владелец бизнеса развивает свой бизнес. И даже в этом случае это не всегда нужно. Спектр уже предлагаемых готовых решений перекрывает практически все отрасли. И это основное преимущество 1С и даже на крупных проектах редко пишется что то с нуля.

А то что вы пишете важно только в условиях развивающегося рынка. А он сейчас стагнирует и консолидируется. Коробки уже никому не нужны.
3. Конечный клиент никогда не выберет учетную систему по принципу «Чтоб было удобно программисту работать». А выбор бизнес системы всегда за конечным клиентом. Поэтому доводы данной статьи они ничтожны.

Клиент будет выбирать по стоимости и эффективности внедрения. То есть сколько ему владение будет стоить и насколько эффективно он сможет вести в ней бизнес и впоследствии менять это решение вместе с изменением процессов своего бизнеса.
Ну например то, что 1С не умеет работать с git. Ну во первых если есть прямые руки и прям такая необходимость, то можно заставить работать его даже с конфигуратором. EDT работает с git из коробки.

Пробовали хоть раз?
Вы же понимаете, что лицензии это малая часть стоимости владения. Самое дорогое это доработки и внедрение под специфику. А «пришло-ушло-осталось» и так уже у всех есть.

Да это малая часть стоимости владения, но и всё остальное будет вполне сопоставимо по цене. По моей уже достаточно обширной практике 9 из 10 клиентам, желающим доработать 1С, на самом деле не нужна никакая доработка. Он просто не умеет пользоваться штатным функционалом системы. А бывает и так, что слабо представляет что такое учёт и зачем он нужен. И по итогам в своей деятельности мы сталкиваемся с монструозными системами, в которые вложили миллионы просто из за того что клиент просто не желает менять свои сложившиеся техпроцессы даже если ему на пальцах доказываешь, что так не правильно и только по этому начинается цикл разработки 1С.
А то что вы пишете важно только в условиях развивающегося рынка. А он сейчас стагнирует и консолидируется. Коробки уже никому не нужны.

Вот тут я соглашусь полностью. И дополню. Просто программирование в 1С тоже на*** никому не упало. Клиенту сейчас ненужен программист 1С. Ему не нужна коробка. И тем более не нужен Ваш «изящный код» или «широкий функционал платформы». Клиенту нужно решение вопросов по учёту. Клиент хочет по итогам видеть прибыль и себестоимость. Клиент хочет видеть снижение налоговой нагрузки и повышение эффективности производства. А это уже прикладные задачи на стыке программирования и консалтинга.
Клиент будет выбирать по стоимости и эффективности внедрения. То есть сколько ему владение будет стоить и насколько эффективно он сможет вести в ней бизнес и впоследствии менять это решение вместе с изменением процессов своего бизнеса.

Несомненно. 1С — решение более чем конкурентоспособное в этом отношении. Вопрос только в правильности подхода к данному вопросу самого клиента и стоимость владения тут будет зависеть больше даже от принятых управленческих решений. Учет можно вести и в бумажных журналах. И в определенных «запущенных» случаях это будет дешевле и эффективней чем в 1С или SAP.
Пробовали хоть раз?

Пробовал, эксперимент прошел успешно, но пока EDT не использую. Конфигуратор + сетевое хранилище конфигураций. Будет время буду дальше функционал EDT изучать.
. Клиенту нужно решение вопросов по учёту. Клиент хочет по итогам видеть прибыль и себестоимость. Клиент хочет видеть снижение налоговой нагрузки и повышение эффективности производства. А это уже прикладные задачи на стыке программирования и консалтинга.

А еще клиент хочет гибкость и умение системы изменятся вместе с ним. Любой бизнес это всегда пробы и ошибки, а также свои ноу хау. Поэтому сейчас лучше всего продается, мы сделаем все что вы хотите, быстро и дешево. А потом доработки вам будут стоить 100к рублей в месяц, а задачи будут решаться как из пулемета.
Несомненно. 1С — решение более чем конкурентоспособное в этом отношении.

Ну сейчас на рынке FMCG розницы в Беларуси 1С нам не конкурент от слова вообще. Посмотрим что будет в России. Типовых для этого сегмента у 1С нет.
А еще клиент хочет гибкость и умение системы изменятся вместе с ним. Любой бизнес это всегда пробы и ошибки, а также свои ноу хау. Поэтому сейчас лучше всего продается, мы сделаем все что вы хотите, быстро и дешево. А потом доработки вам будут стоить 100к рублей в месяц, а задачи будут решаться как из пулемета.

Неблагодарное это дело угадывать желания других людей. По своему опыту скажу, что чаще всего клиент вообще не хочет никаких изменений в учётной системе, все изменения в нормальной ситуации они вынужденные. Например изменилось законодательство. Или появился крупный оптовик со своей системой и выдвинул требования к учёту. А ошибки и пробы они клиенту всегда денег стоят.
Ну сейчас на рынке FMCG розницы в Беларуси 1С нам не конкурент от слова вообще. Посмотрим что будет в России. Типовых для этого сегмента у 1С нет.

Вы плохо знаете конфигурации 1С. Уже давно всё есть. Есть 1С: Розница. Вторая версия правда мало пригодна для касс супермаркетов, однако есть например решение от партнёра 1С «Далион». Фишка 1С как раз таки в том, что всё придумано до нас. Догнать 1С в этом отношении будет очень тяжело любой новой платформе.
По своему опыту скажу, что чаще всего клиент вообще не хочет никаких изменений в учётной системе, все изменения в нормальной ситуации они вынужденные

А я по своему опыту скажу, что наоборот каждый относительно крупный клиент (>=1000 сотрудников) выдвигает свои требования, часто противоречивые другим клиентам и это нормально. Потому как каждый бизнес работает по своим бизнес-процессам, и когда приходишь и говоришь заказчику, что он неправильно работает, он всегда отвечает: я построил этот бизнес сам с нуля методом проб и ошибок, и мне лучше знать как он должен работать. И кстати по факту оказывается прав.
Вы плохо знаете конфигурации 1С. Уже давно всё есть. Есть 1С: Розница. Вторая версия правда мало пригодна для касс супермаркетов, однако есть например решение от партнёра 1С «Далион». Фишка 1С как раз таки в том, что всё придумано до нас. Догнать 1С в этом отношении будет очень тяжело любой новой платформе.

Это вы мне кажется их плохо знаете. Там нету огромного количества модулей для FMCG сетей, скажем всякие ассортиментные матрицы, планограммы и т.п. И вообще плохо подходит под работу с ассортиментами в 100 тысяч товаров.

1С Розница это для фирменной торговли в лучшем случае. Я во всяком случае не знаю ни одной сети супермаркетов на 1С Розница, а я знаю весь местный рынок к примеру.
Там нету огромного количества модулей для FMCG сетей, скажем всякие ассортиментные матрицы, планограммы и т.п.


Вы преувеличивайте значимость наличия подобных модулей.
Эти вещи делаются в 1С на заказ под конкретного клиента недолго и вполне за разумные деньги.

Более того — готовые модуля не спасут вам ситуацию, ведь вы сами чуть выше говорите, что нормально подстраивать ПО под конкретного клиента:

А я по своему опыту скажу, что наоборот каждый относительно крупный клиент (>=1000 сотрудников) выдвигает свои требования, часто противоречивые другим клиентам и это нормально. Потому как каждый бизнес работает по своим бизнес-процессам, и когда приходишь и говоришь заказчику, что он неправильно работает, он всегда отвечает: я построил этот бизнес сам с нуля методом проб и ошибок, и мне лучше знать как он должен работать. И кстати по факту оказывается прав.


Но когда ровно то же самое говорится про 1С — это плохо.
Когда ровно то же самое про вашу систему — это хорошо?

Я во всяком случае не знаю ни одной сети супермаркетов на 1С Розница, а я знаю весь местный рынок к примеру.


Потому что это вовсе не так делается, а примерно так:

Вся сложная логика аналитика и первичные документы ведутся в 1С: Управление Торговлей.
А в зале на кассе стоит узкоспециализированное ПО, довольно простое, функциональная 1С там не нужна.

А 1С: Розница — это для небольших предприятий.
Вы преувеличивайте значимость наличия подобных модулей.
Эти вещи делаются в 1С на заказ под конкретного клиента недолго и вполне за разумные деньги.

Более того — готовые модуля не спасут вам ситуацию, ведь вы сами чуть выше говорите, что нормально подстраивать ПО под конкретного клиента:

1С как платформа для разработки / доработок очень неудобна (смотрите верхние 21 проблему и это еще далеко не все). Поэтому 1С спасают только готовые решения, и при отсутствии готовых модулей внедрять что-то на 1С тот еще мазохизм. Во всяком случае по сравнению с lsFusion.
Но когда ровно то же самое говорится про 1С — это плохо.
Когда ровно то же самое про вашу систему — это хорошо?

Я то как раз утверждаю, что решение — это полуфабрикат. Небольшая часть проекта. Главное это доработка / внедрение и вот тут на первый план выходит платформа, с которой как видно из статьи у 1С все очень плохо.
1С как платформа для разработки / доработок очень неудобна (смотрите верхние 21 проблему и это еще далеко не все). Поэтому 1С спасают только готовые решения, и при отсутствии готовых модулей внедрять что-то на 1С тот еще мазохизм. Во всяком случае по сравнению с lsFusion.

Удобно это понятие исключительно субъективное, для кого то Linux это не удобно. А для меня всё вполне удобно. Кто то тоже считает что Linux это мазохизм. А мне норм.
Я то как раз утверждаю, что решение — это полуфабрикат. Небольшая часть проекта. Главное это доработка / внедрение и вот тут на первый план выходит платформа, с которой как видно из статьи у 1С все очень плохо.

Вот именно, что для 1С доработка это не главное. Установил и с первой минуты можно вести учет, а доработку под специфику можно оставить на потом.
А мне норм

Ручной труд тоже многим норм. Но он медленнее и неэффективнее конвеера.
Установил и с первой минуты можно вести учет, а доработку под специфику можно оставить на потом

Странные у вас клиенты. Обычно «вы пока так поработайте, а потом доработаем» не прокатывает. Потому что все знают «нет ничего более постоянного чем временное». И все до внедрения ждут пока будет сделано именно так как они хотят (сейчас как правило все проекты выполняются поверх существующих, сейчас все же не 2000 год, поэтому они могут подождать)
Установил и с первой минуты можно вести учет, а доработку под специфику можно оставить на потом


Странные у вас клиенты. Обычно «вы пока так поработайте, а потом доработаем» не прокатывает.


Потому что они не так говорят, как вы думаете.

Типично: заказчик перед внедрением смотрят типовую 1С и дает более-менее чёткие пожелания — а что бы хотели еще добавить.

Имея перед глазами уже имеющийся продукт ему проще сформулировать пожелания — их же куда как меньше этих пожеланий получается. Имеющаяся часть-то (большая) заказчика устраивает.
Я вообще на это отвечал:
Установил и с первой минуты можно вести учет, а доработку под специфику можно оставить на потом.
Я вообще на это отвечал:
Установил и с первой минуты можно вести учет, а доработку под специфику можно оставить на потом.


А я вам отвечаю, что можно и так и так. Законченность решения 1С позволяет внедрять сразу.

Зависит от конкретной ситуации.

И те и те клиенты — отнюдь не странные.
1С как платформа для разработки / доработок очень неудобна


Вот только не неудобна.
Понятно, что вам, как привыкшему к другой платформе так кажется.
Но удобство — как раз огромный жирный плюс 1С.
Я с 1с начинал и проработал 4 года (в основном с 8.3) и да, считаю что неудобна.
1С как платформа для разработки / доработок очень неудобна (смотрите верхние 21 проблему и это еще далеко не все). Поэтому 1С спасают только готовые решения, и при отсутствии готовых модулей внедрять что-то на 1С тот еще мазохизм. Во всяком случае по сравнению с lsFusion.


С одной стороны вы пишете статью, ориентируясь на технический аспект, что может убедить технических специалистов.

С другой стороны упираете на числовыми показателями — как это делают маркетологи в процессе облапошывания обычных пользователей, что далеки от технической составляющей.

21 — это просто число.
Реальная значимость конкретных разных недостатков — разная, вплоть до никакого.

Вы же сами и пишете про ваш 1 как минимум недостаток — отсутствие типовых решений, вы полуфабрикат предлагаете, вашими же словами.

А это — решение из 1990-х годов, модное тогда на заре массовой автоматизации. Таких тогда было много.

Не спорю, что кому-то оно и сейчас подойдет. Но таких заказчиков мизер.

При этом пытаетесь противопоставлять себя 1С, ориентированную на массовый рынок.

В массовом же рынке сейчас можно наблюдать тенденции прямо противоположенные тем концепциям, на которые вы упираете в своем решении — массовый рынок это типовые решния. И даже уже не только и не просто типовые — мир идет в SaaS, еще более унифицированный (и это не только с 1С и не только в РФ).

Так что, если поглядеть под этим углом, то получается, что один ваш недостаток по уровню вредности в продажах продукта перевешивает все недостатки конкурента.

Исключения, когда ваш продукт целесообразнее, есть — но их крайне мало. Самый большой рынок, подходящий под ваш продукт остался там, позади в 1990-годы. Выйдя ваш продукт тогда, — да, вы захватили бы все крупные и средние предприятия РФ.

Но сейчас требования к прикладному ИТ для автоматизации бизнеса уже изменились. Чисто технические аспекты стали менее важными. Вперед вышли аспекты более близкие к бизнесу. А на рынке, что держит 1С, вы явно не конкурент им даже по базовым концепциям.

Я так понимаю, что ваше противопоставление 1С — все то же маркетинговый ход, что и про 21 недостаток? Пользуемся популярностью мнимого конкурента, чтобы попиариться?

А это — решение из 1990-х годов, модное тогда на заре массовой автоматизации. Таких тогда было много.

В массовом же рынке сейчас можно наблюдать тенденции прямо противоположенные тем концепциям, на которые вы упираете в своем решении — массовый рынок это типовые решния. И даже уже не только и не просто типовые — мир идет в SaaS, еще более унифицированный (и это не только с 1С и не только в РФ).


Это вы видимо плохо понимаете текущий рынок. У всех уже все как-то автоматизировано. И когда вы к ним придете, вам придется делать, а) так как у них уже сделано, б) то что они хотят чтобы у них сделано в) то про что они еще не знают, но должно быть сделано. И тут платформа это самое главное.

Исключения, когда ваш продукт целесообразнее, есть — но их крайне мало. Самый большой рынок, подходящий под ваш продукт остался там, позади в 1990-годы. Выйдя ваш продукт тогда, — да, вы захватили бы все крупные и средние предприятия РФ.

Как раз тогда был рынок коробок. Никого не интересовала кастомизация, так как ни у кого ничего не было автоматизировано, и можно было продавать/внедрять что угодно. Сейчас рынок сложных проектных решений. Даже САП заявляет что 60% проекта это его доработка. И здесь опять-таки как раз нужна платформа.
Исключения, когда ваш продукт целесообразнее, есть — но их крайне мало. Самый большой рынок, подходящий под ваш продукт остался там, позади в 1990-годы. Выйдя ваш продукт тогда, — да, вы захватили бы все крупные и средние предприятия РФ.


Как раз тогда был рынок коробок. Никого не интересовала кастомизация, так как ни у кого ничего не было автоматизировано, и можно было продавать/внедрять что угодно. Сейчас рынок сложных проектных решений. Даже САП заявляет что 60% проекта это его доработка. И здесь опять-таки как раз нужна платформа.


Коробки в 1990-е годы?
Вы серьезно?


Иностранные коробки были только для крупняка. Дорогие.
Наших еще не было.

Тогда на рынке занимаемом 1С вообще ничего не было.
Тогда коробки для этого рынка только-только зарождались.

И писать под себя предприятию которое можете себе это позволить было нормальным (а зарплаты тогда были никакие — позволить нанять программиста могли многие)

Я потому и говорю, что тогда, выйдя со своим полуфабрикатом, вы были бы в рынке. Сейчас уже не так всё.

Именно что выбранная вами область и сужается в количестве требуемых внедрений. Из плюсов — требуемая сложность внедрений растет, значит, денег не меньше из-за уменьшения количества требуемых внедрений.

В финале всё равно всё упирается в деньги. Допустим я — технический специалист, изучивший 1С и lsFusion и одинаково владеющий этими инструментами (это не так, но допустим!). И есть заказчик, которому что-то надо автоматизировать в своём бизнесе (оставим пока бухгалтерию и налоговый учёт в стороне, других задач в бизнесе — вагон и маленькая тележка). И у него есть определённая сумма на эту задачу.

Я могу написать решение на 1С, взяв готовую конфигурацию и допилив её с учётом требований. Либо возьму lsFusion + готовые модули на GitHub, и тоже допилив их с учётом требований. Клиенту всё равно, что под капотом, главное чтобы работало. Правильно?

А теперь считаем деньги. В случае 1) клиент должен купить платформу 1С, конфигурацию на N рабочих мест, возможно MS SQL. Всё что останется от бюджета, выделенного на разработку — моё. И 2) клиент не должен ничего покупать. Я поставлю ему PostgreSQL, JVM, и свою разработку. Все деньги — мои. Внимание вопрос: какого хрена я должен делиться с 1С своими деньгами?
одна из самых раздражающий ошибок «технарей» — это когда они считают хозяйские деньги… хотя у них задача не деньги считать а бизнес-кейсы реализовывать по возможности с прицелом на потенциальное развитие.

есть такая поговорка «кроилово — ведет к попадалову»

и да, схема «все что останется от бюджета -мое» не работает…
Почему вы считаете что решение, основанное не на 1С, не позволяет в последствии развиваться? У lsFusion есть какие-то скрытые проблемы, о которых мы не знаем?
Разработчики lsFusion в статье например настаивают что асинхронность ненужна и 1С плохо сделала отказавшись от модальности и синхронности…

гугль например с 2014 от этого этой модальности отказался…

понятно что когда разработчики lsFusion разовьются до того что у них появится кейс с требованием асихнронности — они напишут стать о том как же хорошо в асинхроннсти смотрите какая у нас классная платформа… но 1С это проходила 6 лет назад…
Посмотрите как хорошо сделана асинхронность в дарте (кстати, однопоточность ограничена как в 1с, поток один, но есть изоляты (ака фоновые задания)), прям любо дорого посмотреть в отличии от 1с. Или на корутины посмотрите в котлине том же — вообще асинхронный код от синхронного не отличить.
И насчёт денег… OK допустим эту задачу на lsFusion я сделаю за 2 месяца, а на 1С — за месяц, в 2 раза быстрее срока который клиент готов был ждать, за счёт более развитой платформы, готовых решений. Но при этом в 1-м случае я заработаю 100% денег, а во 2-м — 20%. Ну, может клиент даст ещё 5% сверху за скорость, но Нуралиев же даже руку не пожмёт! Он вообще не знает, что я существую, и приношу ему монеты в кубышку. И за что мне потом 3 месяца кормить детей, которые в 1-м случае были бы оплачены?
Но при этом в 1-м случае я заработаю 100% денег, а во 2-м — 20%.


а вы заработайте в первом случает 100% денег а во втором 300% где будет 100% за этот проект, еще 100% за следующий проект который вы в следующий месяц успеете сделать и еще 100% надбавка за скорость, качество и предоставляемые функциональные возможности платформой…
Если бы всё было так просто. Клиенты с многочисленными задачами валяются прямо на дороге, идёшь и подбираешь самых жирных. И рядом никто локтями не толкается… :)
Вам никто не мешает сроки свои устанавливать же — ну делайте задачу на 1С не 1 месяц а те же 2 месяца…
просто больше гуляйте, больше на хабре сидите и больше пива пейте… заказчик же за 2 месяца платит :)

просто 1С вам дает варианты: сделать за 1 месяц быстрее лучше качественнее и с большим количеством дополнительных плюшек и уйти на другой проект/уехать в отпуск, или делать те же два месяца без дедлайнов не парясь забивая на все болт…
Но ведь денег то я заработаю всё равно меньше в разы. Бюджет то у клиента один при любом варианте. Тут надо понять 1 важную вещь: если у тебя (у твоего бизнеса) хватает компетенции сделать всё одному, никому не откатывая, то зачем терять деньги? Закончились золотые времена, когда всем нужен был учёт, желательно вчера, желательно 1С. И сзади ещё очередь таких же бизнесменов с записями в тетрадках стоит. Теперь нет ни очереди, ни тетрадок. Каждого клиента нужно обхаживать, угождать и лелеять.
Если у клиента бюджет один и сроки одни и те же то вам какая разница?

320 рабочих часов пилить lsFusion а можете за те же деньги 160 рабочих часов пилить 1С

на выходе клиент получает решение своих задач за свой бюджет, а в случае 1С еще 100500 дополнительных плюшек…

вы на выходе получаете одинаковую сумму при вдвое меньших трудозатратах фактических…
Одинаковый бюджет <> одинаковый заработок, если программист из своего фактически кармана должен купить клиенту платформу 1С, клиентские ключи и вот это всё. Хотя уже купил у 1С и так и платформу, и типовые конфигурации, используемые в разработке. Если мы говорим про честный бизнес. Т.е. платим сначала за себя, платим за обновления, и потом ещё из денег бюджета платим для покупки 1С клиенту. И потом ещё за сопровождение клиент будет отстёгивать 1С (обновление платформы, типовой конфигурации), ну и вам немножко что останется.

А ещё надо отстегнуть за сертификаты 1С (а то что ты за контора, у тебя даже сертификатов нет). И потом их подтверждать — тоже платить?
Одинаковый бюджет <> одинаковый заработок, если программист из своего фактически кармана должен купить клиенту платформу 1С, клиентские ключи и вот это всё.


хм… бред же.

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

Ну, смотрите, бюджет задачи $10000. Если есть достаточно компетенции и решаем с помощью opensource ERP, все $10000 — ваши. Если не хватает компетенции — покупаем из этих денег 1С (платформу, конфу, сервер SQL если надо), дорабатываем, оставшиеся $2000 — ваши (все цифры условные).

Потом допустим бюджет поддержки будет $100 ежемесячно. Если вы делали проект самостоятельно — все деньги ваши. Если же использовали 1С, вам придётся делится с франчем или 1С этими деньгами, чтобы обновлять использованную типовую конфу, платформу, купленные платные модули. Иначе она через год устареет, выпадет из законодательства, перестанет работать с оборудованием клиента, и проч. Это — цена использования чужого труда.

Да, когда-то быстро закрывался 1 проект, и шли на следующий, и зарабатывали на них оставшиеся $8000. А где сейчас брать, эти проекты?
хм… если честно не понимаю вашей логики… разве где то такое бывает в реальной жизни а не при автоматизации ларька с пивом?

ну ведь бред же: у меня на машину генерального есть 10 млн. рублей, если я ему куплю подержанную вазовскую за копейку за 50 000 р. то 9,95 млн я положу СЕБЕ в карман… а директора буду на копейке возить… и на бензине фирма сэкномит и запчасти дешевые…

Вы сравниваете OpenSource ERP с подержанной копейкой, а 1С — с Mercedes. По факту немного не так. У этой копейки может оказаться суперсовременный движок под капотом, а у Mercedes — старый дымный двигатель разработки конца 90-х.
директор покупает плавность хода, мягкий диван и тишину в салоне…

это технарь смотрит «ба… так тут в копейке тыща кобыл ща мы на треке как ее разгоним»

а директору надо на мягком диване под спокойную музыку доехать от дома до офиса да еще максимально безопасно…

почему то айтишники которые очень любят считать директорские деньги до этой простой мысли не доходят :)
Директору нужно выжимать максимум прибыли при минимуме затрат. Либо потратиться очень сильно 1 раз, но с перспективой выжать еще больше через какое то время. Мягкие диваны и прочее его интересует разве что до тех пор пока это на его деловую репутацию влияет (кто будет дела иметь с ним если директор на копейке ездит? Наверно у него с деньгами совсем плохо и сотрудничать может быть опасно).
вы же понимаете то мы образно…
мягкие диваны это в контексте статьи которая УТ11 критикует например обмен с битриксом из коробки, мобильное приложение из коробки, срм из коробки, единая среда для всех учетных систем (а значит упрощение сопровождения и поддержки), море литературы курсов и прочих инструментов обучения и консультаци и тд и тп…

это все — «мягкие диваны»
И чтобы посидеть иногда на хозяйском кожаном диванчике, 1С-ники платят заработанные кровью и потом деньги. Нет вопросов, каждому своё. Иногда и это приятно.
из какого кармана? вы чего?

вы пример приводите уровня: заказчик сказал выкопать канаву 3х50 метров глубиной 5 метров… и вы собираетесь ее копать руками так как бюджет выделенный на покупку трактора вы планируете себе в карман класть…

какой вменяемый заказчик на это купится?
в каком серьезном бизнесе такой подход?
Опять сравниваете своё решение с лопатой, а 1С — с трактором…
Вы не в 1С работаете? )
P.S. Ладно, всё. Очень далеко ушли от темы…
я пишу в контексте системы предлагаемой авторами статьи — в контексте платформ lsFusion — а это действительно детский совочек по сравнению с «трактором» 1С… как в плане платформы так и в плане «коробочных» решений…
ИМХО, заказчиков способных понять что в такой ситуации что-то не так на пальцах одной руки можно сосчитать. В основном заказы ведь кто делает? Управленцы, которые могут видеть только внешнюю оболочку и покупаются на красивые презентации, они не специалисты и не могут распознать картонный макет трактора за которым на самом деле стоит человек с лопатой. Это приходит только с опытом неудачных внедрений, и то не с первого раза. Причем, судя по ситуации таких неопытных заказчиков масса.
если программист из своего фактически кармана должен купить клиенту платформу 1С


С какой радости?

1) Весь банкет всегда за счет клиента. И он с радостью отдаст деньги за известный продукт 1С. Не заморачивайтесь этим.

2) Стоимость разработки для серьезного проекта несопоставимо больше стоимости 1С. Для мелкого клиента, согласен, бесплатность lsFusion будет иметь значение. Но такой несерьезный клиент не потянет стоимость разработки на lsFusion.
И насчёт денег… OK допустим эту задачу на lsFusion я сделаю за 2 месяца, а на 1С — за месяц, в 2 раза быстрее срока который клиент готов был ждать, за счёт более развитой платформы, готовых решений. Но при этом в 1-м случае я заработаю 100% денег, а во 2-м — 20%.


А вот это вы уже слишком много допускаете.
С чего это вы решили, что вам кто-то даст лишние деньги или что кто то их отнимет?

Напомню ваше первоначальное утверждение:

Я могу написать решение на 1С, взяв готовую конфигурацию и допилив её с учётом требований. Либо возьму lsFusion + готовые модули на GitHub, и тоже допилив их с учётом требований. Клиенту всё равно, что под капотом, главное чтобы работало. Правильно?


Так вот если клиенту все равно — то его интересует определенный результат за который он готов заплатить.

Если вы сделайте быстрее — сэкономленное время ваше.
И только.

Только скорей всего это будет за счет накопления технического долга, за который потом надо будет расплачиваться увеличением времени и сложностью последующей доработки, без которых ни одна система не живёт.
Только скорей всего это будет за счет накопления технического долга, за который потом надо будет расплачиваться увеличением времени и сложностью последующей доработки, без которых ни одна система не живёт.


В том то и дело, что нет!

Ведь мы говорим о готовой заточенной на обсуждаемый вид задач 1С.

Посему часть вопросов по обслуживанию технического долга взяли на себя разработчики из 1С.

А я по своему опыту скажу, что наоборот каждый относительно крупный клиент (>=1000 сотрудников) выдвигает свои требования, часто противоречивые другим клиентам и это нормально. Потому как каждый бизнес работает по своим бизнес-процессам, и когда приходишь и говоришь заказчику, что он неправильно работает, он всегда отвечает: я построил этот бизнес сам с нуля методом проб и ошибок, и мне лучше знать как он должен работать. И кстати по факту оказывается прав.

Бывает прав, а бывает нет… То что он построил с нуля ничего вообще не значит. Но кто я такой чтоб спорить с клиентом? Если это нам выгодно мы делаем так как хочет клиент, предупредив о последствиях. Если клиент адекватный, то мы получаем от него деньги 2 раза. В первый раз за неправильное решение, а второй раз за правильное. Если нет, то расстаёмся, т.к. работать с неадекватами тяжело.
С Розница это для фирменной торговли в лучшем случае. Я во всяком случае не знаю ни одной сети супермаркетов на 1С Розница, а я знаю весь местный рынок к примеру.
Я ж сказал для супермаркетов на кассах 1С: Розница очень плохо подходит. Но был опыт и такой эксплуатации. Для товароведа 1С норм. У крупных сетей в России везде вообще свой самописный софт. Написанный и поддерживаемый собственными программистами. Часть из которого в т.ч. на платформе 1С. Например у сети Магнит. Туда в принципе со стороны не зайдёшь. Им никто не нужен.
Если это нам выгодно мы делаем так как хочет клиент, предупредив о последствиях. Если клиент адекватный, то мы получаем от него деньги 2 раза. В первый раз за неправильное решение, а второй раз за правильное.

И вот тут на первый план выходит платформа.
У крупных сетей в России везде вообще свой самописный софт. Написанный и поддерживаемый собственными программистами. Часть из которого в т.ч. на платформе 1С. Например у сети Магнит.

Не совсем так, там есть и ряд коробок (если мы про ТОП-500 говорим). И Магнит не на 1С. Посмотрите их вакансии:
hh.ru/vacancy/32394490
У них классика 1С — Документооборот, Бухгалтерия, ЗУП, СППР.
Остальное на всем подряд, от Java и C++ до Oracle и PostgreSQL.
И Магнит не на 1С

Магнит на 1С. Помимо перечисленных
Документооборот, Бухгалтерия, ЗУП, СППР
. Там есть еще и система ERP на 1С. Но ни одна из стандартных конфигураций «там не стояло». Всё написано с нуля. Как называется не помню. Они только платформу голую берут (да так тоже можно). Про это рассказывал преподаватель на курсе эксперта по тех. вопросам. В России все на 1С. Пройти мимо этой системы невозможно. Да. Недостатки есть. Багов навалом. Но практически все недостатки это продолжение тех преимуществ, которые есть. Есть ли платформы с технической точки зрения лучше. Конечно есть. Но клиент любит 1С. И есть за что… Всё. Уехал на Кубу…
В FMCG-сетях достаточно мало 1С. Там Супермаг, GESTORI, SAP, Axapta и куча самописок в стиле Delphi+Oracle/MS SQL. И в Магните ни одной вакансии по 1С для бэка (а я периодически мониторил их для интереса). И представляя их схему управления они бы удавились платить деньги за лицензии платформы, от который, как мы видим из статьи, толку мало. Тем более что масштабируемость там начали добавлять, когда Магнит уже был достаточно большой, чтобы работать на 1С. Ваш преподаватель явно что-то перепутал.
В FMCG-сетях достаточно мало 1С. Там Супермаг, GESTORI, SAP, Axapta и куча самописок в стиле Delphi+Oracle/MS SQL.


А давайте просто прочитаем у тех, кто действительно знает:

habr.com/en/company/croc/blog/470453
Вообще, конечно, в те годы SAP был редкостью. Наличие его говорило о том, что розничная сеть смотрит очень далеко в будущее. Все делали 1С, допиливали его на коленке и ещё раз допиливали. Среди кассовых решений боролись несколько десятков (!) крупных офлайн-решений, причём наших и западных, проприетарных и свободных. Предлагали кучу всего, и каждое решение всё равно надо было допиливать. Из кадровых систем боролись SAP, Босс-Кадровик и 1С


Это слова директора по розничному подразделению интегратора КРОК, как раз крупняком и занимаюегося.

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

Да прям-таки нашли спеца. Крок это крупный системный интегратор, откуда ему знать, что там в каких сетях стояло. Если речь идет про 2002 год, то на рынке уже куча кого было:

www.cnews.ru/articles/avtomatizatsiya_torgovyh_setej_na_rossijskom

Основные игроки тогда, ЕМНИП: Gestori, Супермаг(тогда 2000 по году выпуска), Астор (1С), Axapta, Домино, IBS Trade House. Axapta и IBS TradeHouse на покрупнее. Первые три держали процентов 70 рынка.

Gestori в свое время заявлял, что у них каждая 4-я сеть, видел исследования где у Супермага была каждая 3-я региональная сеть. Так что не надо тут про 1С. У вас обычная ошибка выжившего: так как вы связаны с 1С, знаете только сети на 1С. Притом что у 1С нет решения для розницы. Не УТ же с Розницей на FMCG сеть ставить, почитайте комменты повыше.
Да прям-таки нашли спеца. Крок это крупный системный интегратор, откуда ему знать, что там в каких сетях стояло.


Разумеется, речь идет о тех сетях, с которыми они лично работали и что лично внедряли.

Основные игроки тогда, ЕМНИП: Gestori, Супермаг(тогда 2000 по году выпуска), Астор (1С), Axapta, Домино, IBS Trade House. Axapta и IBS TradeHouse на покрупнее.


Ну наконец то вы начинаете говорить правду — когда вас припёрли фактами к стенке. Давайте сравним с первоначальным вашим утверждением:

В FMCG-сетях достаточно мало 1С. Там Супермаг, GESTORI, SAP, Axapta и куча самописок в стиле Delphi+Oracle/MS SQL.


Честно говоря, вы довольно прилично опустили свою систему в моих глазах откровенным передергиванием фактов. Такое впечатление складывается, что обманываете и в технических вопросах тоже. Впрочем, тут в комментариях ребята уже нашли кучу несоответствий в ваших словах и по техническим вопросам.

Плохой пиар вы делаете для своей системы откровенный враньём.

Всё, пишите теперь что хотите — но веры вашим словам вообще никакой нет. Заслужили.
Разумеется, речь идет о тех сетях, с которыми они лично работали и что лично внедряли.

Ну то есть пару клиентов. Очень репрезентативная выборка.
Давайте сравним с первоначальным вашим утверждением

Давайте.
В FMCG-сетях достаточно мало

А 15-20% это по вашему много (у нас к примеру на рынке вообще меньше 10%)? Так что это вы передергиваете. Про Астор / 1С и в этой и предыдущих статьях в комментариях упоминалось не один раз.
Такое впечатление складывается, что обманываете и в технических вопросах тоже. Впрочем, тут в комментариях ребята уже нашли кучу несоответствий в ваших словах и по техническим вопросам.

Пока здесь были только истерики. Было всего два косяка, с predicate locking в PostgreSQL (хотя формально я не говорил что речь о SERIALIZABLE, речь шла о REPEATABLE READ, потому как в true SERIALIZABLE версионник от блокировочника не сильно отличается). Ну и в one-to-many про подчиненные справочники и объект регистратор забыл упомянуть, хотя это мелкая придирка.
Всё, пишите теперь что хотите — но веры вашим словам вообще никакой нет. Заслужили.

Вообще вы IT-специалист. Вам и не надо верить. Вера вообще плохая штука, всегда (подчеркиваю еще раз всегда) нужно думать своей головой. И если вы не поняли, о чем статья, не переживайте, значит она не для вас.
Разумеется, речь идет о тех сетях, с которыми они лично работали и что лично внедряли.

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

Если про белое сказать чёрное — то все поведутся?

Что-то мне подсказывает, что лично ваша выборка не репрезент… тьфу. Что у вас опыта никак не больше, чем у сотрудника крупного интегратора (на слова которого я выше сослался), сотрудник тот уже больше 10 лет занимается розницей у крупного интегратора.

Собственно подобные несерьезные аргументы с вашей стороны, которыми полны ваши тесты, и вызывают недоверие ко всем вашим словам.

У крупного интегратора-то? Пара клиентов, гы-гы.

КРОК работает в основном только с ТОП-30. Где поголовно SAP For Retail кстати. Полагаться на их мнение, все равно что спрашивать на Рублевке, как живется людям в Мытищино.
Полагаться на их мнение, все равно что спрашивать на Рублевке, как живется людям в Мытищино


Да я на свое мнение прежде всего полагаюсь.

И то, что пишете вы — ничуть не соответствует тому, что вижу я в реальности.

А вот то, что пишет КРОК — подтверждается и моим опытом работы с сетями.

КРОК работает в основном только с ТОП-30


А теперь подумайте — а каковы размеры тех, кто не топ-30 в наше время огромных сетей. Тех, что остался.

Да я на свое мнение прежде всего полагаюсь.
И то, что пишете вы — ничуть не соответствует тому, что вижу я в реальности.

Ну а я на свое. А мы работаем на этом рынке «массово». А вы (если вы не сотрудник Астор) — нет.
А теперь подумайте — а каковы размеры тех, кто не топ-30 в наше время огромных сетей. Тех, что остался.

По различным оценкам — около 40-60% всего рынка. А то и больше. В любом случае речь в вашей ссылке шла про 2002 год.

И кстати в том же X5 SAP только «наверху» в офисе работает (у 10%) пользователей. На чем работают остальные 90% они пока не колятся.
По различным оценкам — около 40-60% всего рынка.


Именно. Но ресурсов у них намного меньше — их много, но они уже сравнительно мелкие.
И эти ребята лет 15 назад уже как закончили пилить свои велосипеды — так как появлись развитые готовые решения. И теперь они предпочитают готовую основу для бизнеса (допиливать конечно под себя).
Угадайте, какая самая массовая готовая основа для учета в бизнесе в РФ?
Угадайте, какая самая массовая готовая основа для учета в бизнесе в РФ?

Просветите. Никак не могу угадать. Не УТ же с розницей вы собираетесь допиливать. Это, как я уже писал выше, все равно что из танка самолет сделать.
Не УТ же с розницей вы собираетесь допиливать


УТ и не нужно особо пилить под бэкофис розницы.

Что до Розницы — вам уже неоднократно говорили, что Розница только для мелких предприятий. Вы видимо из-за названия, не вникнув в суть, считаете, что супермаркеты нужно делать на Рознице?

В крупных и средних сетях — там простые специализированные модуля на кассах.
УТ и не нужно особо пилить под бэкофис розницы.

Да ладно. Ассортиментные матрицы, планограммы, мониторинг загрузки в оборудование, онлайн прием данных из касс и т.п. там есть? Да и вообще, вы представляете как УТ будет с 300к SKU работать и соответствующими объемами реализации и закупок? Вы видимо плохо себе представляете, что такое FMCG розница. Во всяком случае взрослая.
Ассортиментные матрицы, планограммы

Делал подобные вещи несколько раз.
Не всем нужны, оказывается. А кому нужны — пилиться за 2-3 дня. Там больше времени уходит на обсуждение проблемы — технически решается на раз-два в 1С.

онлайн прием данных из касс и т.п. там есть?

Вау! Вы беретесь рассуждать глобально, но даже не знаете, что это есть?

Да и вообще, вы представляете как УТ будет с 300к SKU работать и соответствующими объемами реализации и закупок?


Это же БД, ей все равно.
Про 300К пугалки можете рассказывать не техническим специалистам.

Для 1С скорее количество документов, чем количество товаров сильнее влияет на производительность.

Вы видимо плохо себе представляете, что такое FMCG розница. Во всяком случае взрослая.

Та, что топ-30 и не имеет отношения к теме нашего разговора?

Я прекрасно себе представляю, к примеру, как работает сеть с 1200 магазинами. Да, бэкофис там на 1С.

мониторинг загрузки в оборудование


Вы уверены, что эту сугубо админскую задачу следует решать в то же самой учетной системе, где деньги/товары считают?
Делал подобные вещи несколько раз.
Не всем нужны, оказывается. А кому нужны — пилиться за 2-3 дня. Там больше времени уходит на обсуждение проблемы — технически решается на раз-два в 1С.

Да-да. За 2-3 дня. Вы хотя бы представляете, что это основные данные, которые надо во все процессы интегрировать. В УТ из тонн спагетти кода.

Или супербазовый процесс с установкой прайсов на период:
forum.infostart.ru/forum81/topic182481
1.создаем новый Вид цены (я назвал Акция счастливые часы)
2. делаем документом Установка цен номенклатуры новую цену на интересующий нас товар (Кальян Dumok Hookah SS-D06 Antares, Black Hose) такую как нам надо (2542), она же у нас фиксированная
3. делаем скидку с помощю записей справочника Скидки/наценки, тип нашей скидки Специальная цена и проставляем наш новый вид цены (в нашем случае Акция счастливые часы), сохраняем запись
4. в списке всех скидок находи нашу новую скидку и используем функционал с шапки формы, устанавливаем статус скидке, как Действует и период действия (20.09.2018 по 21.09.2018)

Представляете что будет если новый вид цены на каждую акцию создавать?

Ну и откройте luxsoft.by/produkty/lsfusion-erp управление торговым оборудованием. Много из этого в УТ из коробки есть?
Это же БД, ей все равно.
Про 300К пугалки можете рассказывать не техническим специалистам.

Запустите УТ хотя бы с 500 одновременных пользователей и объемами как я написал, потом увидите какое «Это же БД, ей все равно.».
Да-да. За 2-3 дня. Вы хотя бы представляете, что это основные данные, которые надо во все процессы интегрировать. В УТ из тонн спагетти кода.


Для вас — да, сложно.
Просто потому что вы специалист в другой какой то сфере, но не в этой.

Представляете что будет если новый вид цены на каждую акцию создавать?

Зачем? Вы сослались на какой-то дилетанский совет.

Запустите УТ хотя бы с 500 одновременных пользователей и объемами как я написал, потом увидите какое «Это же БД, ей все равно.».


В крупных сетях — другие решения, только таких сетей раз-два и обчелся. Ну а в моей знакомой сети с 1200 магазинами — всю сеть обслуживают около 120 менеджеров, что постоянно сидят в 1С и что-то там с товаром делают.
Бухгалтерия и кадры, еще 40 человек — отдельно работает.

Зачем все руками-то бить, зачем много народа? Автоматические загрузки данных от поставщиков.
Нет, не слыхали?

Сошлюсь на habr.com/en/company/lsfusion/blog/468415/#comment_20711965
400. Круглые сутки. Только вот реальная нагрузка была, когда нашёл контору всего со 100+ пользователями. Вот там всё ложилось нафиг.
Для вас — да, сложно.
Просто потому что вы специалист в другой какой то сфере, но не в этой.

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

Ну так расскажите как во всех магазинах данного формата акцию -30% в УТ сделать с пятницы по понедельник, раз человек не разобрался. Вы же понимаете что это базовый процесс розницы? И сколько у вас нажатий это потребует.
В крупных сетях — другие решения, только таких сетей раз-два и обчелся

То что я написал, это около 100 супермаркетов. Очень небольшая сеть.
Ну а в моей знакомой сети с 1200 магазинами — всю сеть обслуживают около 120 менеджеров, что постоянно сидят в 1С и что-то там с товаром делают.

1200 магазинов это под 5к одновременных пользователей. Какие 120? Или у вас там все в разных базах как в 90-х сидят?
Для вас — да, сложно.
Просто потому что вы специалист в другой какой то сфере, но не в этой.


Нет как раз именно в этой. И знаю когда ассортиментные матрицы нужно не для галочки сделать, а через них управлять сетью магазинов.


Я имею ввиду вы не специалист по 1С и вам кажется, что для 1С это сложная задача. А она околорядовая.

И сколько у вас нажатий это потребует.

2 документа создать: включить акцию и выключить акцию. Можно их создать заранее.

1200 магазинов это под 5к одновременных пользователей. Какие 120? Или у вас там все в разных базах как в 90-х сидят?


Распределенка — тоже кстати хорошее решение, когда нужна гарантия автономной работы. Но речь не об этом.

Какие 5к? Вы кассы что ли тоже считаете?
Зачем кассы в БД 1С запускать? Уж чему-чему, а кассам нужна полная 100% гарантированная работы при любях авариях интернета.

Там кассы работают автономно — 1С выгружает данные для касс (после поступления товара, после изменения цен) и загружает их назад (в конце дня полная загрузка, а в течение дня — частичная загрузка, т.н. «текущие продажи», для построении аналитики в течение дня) — по запросам пользователей (в том числе, неявным запросам, когда пользователь строит отчет, где нужно видеть остатки/продажи на сегодня, при построении отчета подгружаются данные с касс, это минутное дело, так как данные уже лежат на диске в готовом виде).

И да — на кассах стоит простейшее решение — не 1С Розница. Это решение умеет только бить товар, работать с торговым оборудованием и выполнять обмены данными. Обладая при этом собственной БД, не зависящей от внешнего интернета.
Я имею ввиду вы не специалист по 1С и вам кажется, что для 1С это сложная задача. А она околорядовая.

Я потратил на изучение 1С огромное количество времени (при том что у меня большой опыт в разработке бизнес-приложений). Да каких-то деталей я не знаю, но непонятно, как они в целом могут влиять на общую картину разработки. Ничего волшебного в 1С нет, не преувеличивайте.
2 документа создать: включить акцию и выключить акцию. Можно их создать заранее.

Ну тогда есть еще проще способ. Делаете кнопку: Сделать хорошо. Можно создать ее заранее.
Распределенка — тоже кстати хорошее решение, когда нужна гарантия автономной работы. Но речь не об этом.

В 21 веке? И вы реально плохо представляете, что такое FMCG в распределенных базах. Ну или никогда просто не работали в единой.
Какие 5к? Вы кассы что ли тоже считаете?

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

В современных системах лояльности вам интернет все равно нужен. Его пропадание это ЧП куда больше, чем остановка бэкофисных процессов.
В 21 веке?

Это довольно больная тема, на самом деле. Внезапно, в 21 веке, в одном из офисов компании, в которой я работал, прорвало трубу канализации. Все сетевое оборудование (и половина офиса) по итогу плавало в нечистотах примерно дня 2. Офис расположен в БЦ в Москве.
Если ближе к нашей территории, то не раз сталкивался с проблемами доступа в интернет, когда «экскаватор перерубил провод».
В обоих случаях, могут возникнуть проблемы с доступом к единой базе. Дальше уже ЛПР оценивают риски и решают — единая база или распределенная.

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

Вижу во фразе противоречие =)
Это довольно больная тема, на самом деле. Внезапно, в 21 веке, в одном из офисов компании, в которой я работал, прорвало трубу канализации. Все сетевое оборудование (и половина офиса) по итогу плавало в нечистотах примерно дня 2. Офис расположен в БЦ в Москве.

Так у вас весь офис будет не работать. А базу все равно обычно в ДЦ помещают.
Если ближе к нашей территории, то не раз сталкивался с проблемами доступа в интернет, когда «экскаватор перерубил провод».

Сейчас почти все модемы поддерживают резервный 3G канал. Все решается на раз.
Вижу во фразе противоречие =)

Я имел ввиду, что может у него там половину пользователей на бумажках работает и / или их процессы никак не автоматизированы, и поэтому они в систему не заходят (где они хотя бы подтверждать выполнение своих действий должны, не говоря уже о другом общении с системой).
А базу все равно обычно в ДЦ помещают.

Зависит от (от паранойи владельца бизнеса в том числе). Я скорее о том, что распределенная база тоже имеет свои преимущества (в т.ч. потому что позволяет иметь разные версии или настройки приложений, если такое необходимо).
Утверждать что «А лучше B», не уточняя в какой ситуации — всегда риск начать холивар.

Я имел ввиду, что может у него там половину пользователей на бумажках работает

Я понял о чем вы. Просто это не проверяемый момент. С тем же успехом, может оказаться, что у него процессы автоматизированы лучше, поэтому нужно меньше людей, чем у вас.
Зависит от (от паранойи владельца бизнеса в том числе). Я скорее о том, что распределенная база тоже имеет свои преимущества (в т.ч. потому что позволяет иметь разные версии или настройки приложений, если такое необходимо).
Утверждать что «А лучше B», не уточняя в какой ситуации — всегда риск начать холивар.

Лет 10 назад я бы с вами согласился. Но сейчас с 4Г, с датацентрами за копейки (тот же хетцнер), с резервированием из коробки.
Я понял о чем вы. Просто это не проверяемый момент. С тем же успехом, может оказаться, что у него процессы автоматизированы лучше, поэтому нужно меньше людей, чем у вас.

Это FMCG розница (с минимальной рентабельностью), если бы кто-то нашел способ сократить количество людей даже в два раза, он бы смял рынок практически мгновенно.
Я потратил на изучение 1С огромное количество времени

Сколько лет у вас опыта работы с 1С?
В 21 веке? И вы реально плохо представляете, что такое FMCG в распределенных базах.

Вот кстати у одного из лидеров розницы в Украине (продукты питания) на кассах можно наблюдать обратный отсчет времени до синхронизации базы (это у них как заставка когда касса заблокирована). То есть похоже на то, что, каждая касса сама по себе, со своей локальной базой.


В современных системах лояльности вам интернет все равно нужен.

В таком случае у них не работает часть скидок, а в остальном всё хорошо. Скидки потом вроде бы доначисляют на личный счет, когда синхронизация пройдет.

В таком случае у них не работает часть скидок, а в остальном всё хорошо. Скидки потом вроде бы доначисляют на личный счет, когда синхронизация пройдет.

Смотря что за скидки. Я помню в Беларуси одна сеть проводила очень щедрую акцию, которая была завязана на какую-то информацию о клиенте. Было очень эпично, когда система лояльности начала жутко тормозить, и люди в очередях часами стояли.

Ну и учитывая, что сейчас основная схема лояльности — получаешь скидку в следующий раз (когда покупатель вернется, чтобы он собственно вернулся), падение системы лояльности это реальное ЧП (потому что покупатель вернулся — а скидку ему не дали и это скандал).

Ну в любом случае это лучше, чем простой магазина.


Ну и учитывая, что сейчас основная схема лояльности — получаешь скидку в следующий раз (когда покупатель вернется, чтобы он собственно вернулся), падение системы лояльности это реальное ЧП

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


Кстати, посмотрел ещё раз вашу демо — по скидкам как-то печально всё, по сравнению с той же УТ11 (раз мы тут её вспоминаем). Например условия вида "купите 3 пары носков и получите 5% скидку на трусы" не увидел. Как и ограничения типа "не уйти ниже определенного типа цен", да много ещё чего. Есть просто одна небольшая сеть которые думают про замену ПО на кассах, но для них того что у вас в демо никак не хватит.


P.S. справедливости ради скидки в УТ тормозят ой-ой-ой как на объемах :)

Ну вот нету связи — значит баллы и начисления персональных бонусов пока не используешь. Не так чтобы это сильно распугивало покупателей.

Зависит от акции, у некоторых акция например получи единоразовую скидку 7% в следующем месяце. И представляете покупатель набрал целую тележку, приходит к кассе. А там — извините, приходите в следующий раз.
Например условия вида «купите 3 пары носков и получите 5% скидку на трусы» не увидел. Как и ограничения типа «не уйти ниже определенного типа цен», да много ещё чего.

Тут не подскажу. Призывается CrushBy для ответа на этот вопрос.
P.S. справедливости ради скидки в УТ тормозят ой-ой-ой как на объемах :)

Да, я видел как там они реализованы (интересовал функционал Черной пятницы, с которым у них как оказалось засада, что очень странно). Так там такой жесткий императивный код с рекурсиями и N+1 проблемами, что для меня загадка как эти скидки даже на маленьких объемах работают.
Да, я видел как там они реализованы

Ну а я допиливал. Не припомню там N+1, честно говоря — там выполняется один большой пакетный запрос, дальше строится ещё более огромный пакетный запрос (по результатам первого), выполняется — и дальше без обращения к базе обрабатывается дерево скидок.
После вдумчивой оптимизации удалось довести до 2-3 секунд на расчет чека, почти всё время из этого — выполнение этих двух мегазапросов. А, ну и около 0,5 секунды на обмен данными с сервером (как минимум результирующее расчитанное дерево передается на клиента) и отрисовку формы идет.

Ну а я допиливал. Не припомню там N+1, честно говоря — там выполняется один большой пакетный запрос

Вы же понимаете, что пакетный запрос не решает проблему N+1. Проблема N+1 это выполнение однотипных запросов в цикле, вместо выполнения в одном запросе, неважно передаются при этом они на сервер приложений или нет. Но 2,5-3,5 секунды все равно многовато, а сколько у вас объемы там были?
Вы же понимаете, что пакетный запрос не решает проблему N+1.

Конечно понимаю. О чем и пишу — нет там выполнения запросов в цикле. В цикле собирается текст запроса, который потом выполняется за один раз.


Но 2,5-3,5 секунды все равно многовато, а сколько у вас объемы там были?

0,5 это было "в том числе". Посмотрел сейчас цифры — около 1,2 секунды расчет именно скидок, 2-2,5 всего чека (от нажатия кнопки "Расчет" и до завершения серверного вызова — там не только расчет скидок, ещё есть мелочи).
Объемы — в базе > 3 млн справочник клиентов (соответственно и дисконтные карты примерно в том же количестве, пусть большая часть и "мертвые" или дубли), ~300 000 SKU (активны далеко не все), ~4,5 млн строк в таблице регистра продаж (к нему идут запросы при расчете — для определения скидок за накопленный объем продаж). 306 активных скидок (сгруппированных в дерево, с условиями применения типа максимум/минимум/сумма/...).

Конечно понимаю. О чем и пишу — нет там выполнения запросов в цикле. В цикле собирается текст запроса, который потом выполняется за один раз.

Заранее извиняюсь за нубский вопрос. Но вот смотрите, открыл УТ процедуру РассчитатьСкидку.
Код
Там делается:
Товары = СтрокиТоваровДляРаспределения(СтрокаДерева, ПараметрыРасчета);

После чего (например одна из веток):

Для Каждого Товар Из Товары Цикл
	
	ЦенаЗаУпаковку = ПолучитьЦенуНоменклатурыПоВидуЦен(Товар, ПараметрыРасчета, СтрокаДерева.ВидЦены);
	Если ЦенаЗаУпаковку <> 0 Тогда
		СуммаСкидки = Товар.Сумма - Товар.КоличествоУпаковок * ЦенаЗаУпаковку;
	Иначе
		СуммаСкидки = 0;
	КонецЕсли;
	
	ПрименитьЗначениеСкидкиКТовару(СтрокаДерева, СуммаСкидки, Товар, РезультатРасчета, ПараметрыРасчета);
	
КонецЦикла;

А в ПолучитьЦенуНоменклатуры:

Функция ПолучитьЦенуНоменклатурыПоВидуЦен(Товар, Параметры, ВидЦены)
	
	Цена = 0;
	
	Отбор = Новый Структура(
		"Номенклатура,
		|Характеристика,
		|ВидЦены",
		Товар.Номенклатура,
		Товар.Характеристика,
		ВидЦены);
	
	МассивСтрокЦены = Параметры.ЦеныНоменклатуры.НайтиСтроки(Отбор);
	Для Каждого СтрокаЦена Из МассивСтрокЦены Цикл
		
		Если СтрокаЦена.Упаковка = Товар.Упаковка Тогда
			Цена = СтрокаЦена.Цена;
		Иначе
			
			// Приведем цену к цене за упаковку сегмента.
			// Цена не округляется для повышения точности...
			Если СтрокаЦена.Упаковка = Справочники.УпаковкиЕдиницыИзмерения.ПустаяСсылка() Тогда
				Цена = СтрокаЦена.Цена * (Товар.Количество / Товар.КоличествоУпаковок);
			Иначе
				Цена = (СтрокаЦена.Цена / СтрокаЦена.УпаковкаКоэффициент) * (Товар.Количество / Товар.КоличествоУпаковок);
			КонецЕсли;
			
		КонецЕсли;
		
		Прервать;
		
	КонецЦикла;
	
	Возврат Цена;
	
КонецФункции

Или я куда-то не туда смотрю?

А хотя понял, в параметрах расчета там уже отфильтрованные данные и это пробег по временной таблице / коллекции по сути (то есть все равно N+1, но «локальный»)
А хотя понял, в параметрах расчета там уже отфильтрованные данные и это пробег по временной таблице по сути (то все равно N+1, но «локальный»)

Это пробег по таблице в памяти (полученной ранее из большого пакетного запроса), обращения к SQL или к диску здесь нет. Т.е. формально наверное можно считать N+1, но каких-то измеримых задержек при условии обычных для документа количества строк тут не будет.
А вот если где-то неосторожно доработать код, написав к примеру:


Если Товар.Номенклатура.допИсключитьИзАкции Тогда
....
КонецЕсли;

то получим N+1 — т.к. будет обращение через точку, соответственно запрос к справочнику Номенклатуры.
Собственно в процессе оптимизации исправлял несколько таких моментов, сделанных ранее другими программистами (в типовой было всё ок).

Зависит от акции, у некоторых акция например получи единоразовую скидку 7% в следующем месяце. И представляете покупатель набрал целую тележку, приходит к кассе. А там — извините, приходите в следующий раз.


1) В данном конкретном описанном вами случае — проблемы нет.

И в очередной раз можно отметить сколько вам еще предстоит сделать для себя открытий в том, как на самом деле работает розница.

При неработающей связи можно прекрасно накапливать бонусы. Передать их в центр при восстановлении связи.

Вот другое дело, что тратить бонусы нельзя, однако:

2) Это бывает сплошь и рядом. Тележки у кассы при этом мало кто оставляет. Ну не сейчас потратишь бонусы — потратишь их попозже.

Я не спорю — лучше чтобы все работало конечно.

Но давайте вернемся в начало разговора. Там речь была о том, что магазин должен уметь работать автономно:

Ибо потери от полной неработоспособности магазина куда как выше, чем от какой-то там неработающей в данный момент акции.
И в очередной раз можно отметить сколько вам еще предстоит сделать для себя открытий в том, как на самом деле работает розница.

Вам не надоело это повторять? Еще раз у меня опыт в рознице скорее всего гораздо больше чем у вас (хотя про свой вы ничего не сказали, сколько вы проектов лично выполнили и каких масштабов?)
Это бывает сплошь и рядом. Тележки у кассы при этом мало кто оставляет. Ну не сейчас потратишь бонусы — потратишь их попозже.

Вы вообще читали про акцию которую я писал. Ее смысл в том, что ты 7% получаешь один раз в течении месяца. И люди именно в этот день поэтому закупаются на месяц. И второй раз они не придут в этот месяц и скидка сгорит. И вы не представляете какие при этом скандалы бывают.
Но давайте вернемся в начало разговора. Там речь была о том, что магазин должен уметь работать автономно:
Ибо потери от полной неработоспособности магазина куда как выше, чем от какой-то там неработающей в данный момент акции.

Ровно 1 минута чтобы поднять 3G. Еще раз у нас много клиентов у кого кассы в онлайн в единой базе с сервером в германии (не то что бэки). И за последние 5 лет, я не помню ни одного инцидента, из-за которого у кого-нибудь возникла идея, а давайте сделаем автономно. А вот преимущества единой базы просто огромные.
Например условия вида «купите 3 пары носков и получите 5% скидку на трусы» не увидел. Как и ограничения типа «не уйти ниже определенного типа цен», да много ещё чего

Это настраивается на фронт-системе. У нас есть также свой фронт и там есть возможность проводить такие акции и сложнее, но мы его не используем в FMCG (так как наш фронт работает в онлайне с центральной базой). Обычно мы его используем только в аптеках, магазинах одежды и т.д.
Это настраивается на фронт-системе. У нас есть также свой фронт и там есть возможность проводить такие акции и сложнее

А посмотреть его можно где-то? Или хотя бы почитать?

Почти все из перечисленного можно с успехом сделать на 7.7 (смотрите на тот же Астор со старыми Торговыми Сетями).
Онлайн прием данных из касс вам нафиг не уперся, кроме некоторых чисто презентационных фишечек. Для бизнеса он не нужен. С точки зрения автоматизации и решаемых задач: кэш-лайн и его управление — значительно более интересная область.
Если уж вы так прошарены в рознице — как вы решаете проблему изменения цен в магазине?
Астор очень тормознутая система, если ее в одну базу запускать. Я вживую видел. И насчет не нужен, мы помню переводили одну сеть. У нас через час после задержек приема реализации звонили и ругались, почему остатки не актуальны. На аргумент, раньше у вас вообще в конце дня все принималось, ответ был: ну так к хорошему быстро привыкаешь.
Если уж вы так прошарены в рознице — как вы решаете проблему изменения цен в магазине?

Если вы про актуальность цен в кассе / на ценнике, то для этого есть отдельный процесс, который синхронизирует вынос ценника с успешной загрузкой в оборудование.
И насчет не нужен, мы помню переводили одну сеть. У нас через час после задержек приема реализации звонили и ругались, почему остатки не актуальны. На аргумент, раньше у вас вообще в конце дня все принималось, ответ был: ну так к хорошему быстро привыкаешь.

Понятно :) А крупнее, чем ларьки, есть кто-то?
Т.е. осмысленного ответа, зачем изменение остатков в он-лайне в рознице — не будет?
Если вы про актуальность цен в кассе / на ценнике, то для этого есть отдельный процесс, который синхронизирует вынос ценника с успешной загрузкой в оборудование.

А что вперед? Вынос или выгрузка?
Понятно :) А крупнее, чем ларьки, есть кто-то?
Т.е. осмысленного ответа, зачем изменение остатков в он-лайне в рознице — не будет?

Сети гиперов и супермаркетов. С 1к одновременных пользователей и автоматизацией всего что только можно.

Остатки онлайн сокращают время принятия решения на 1 день (начиная от сроков годности и выноса товаров в зал и заканчивая заказами, например скоропорта, который очень часто делается на магазине).
А что вперед? Вынос или выгрузка?

Зависит от настроек. Как правило, если я правильно помню, в соответствующем АРМ, нажал распечатать, как только распечаталось (эта информация тоже сохраняется и анализируется) идет задание на загрузку в кассы.
С 1к одновременных пользователей и автоматизацией всего что только можно.

Это на качество системы автоматизации практически не влияет. Хоть 30 тысяч, хоть 1 пользователь.
Остатки онлайн сокращают время принятия решения на 1 день

Каких решений? Каким образом?
Скоропорт анализируется в магазине. Там выгрузить продажи в бек — не составляет никаких проблем (но и это не надо). Для принятия решений по скоропорту — достаточно текущего оборота в открытой кассовой смене и статистики продаж. Повторюсь — зачем остатки в онлайне?
Как правило, если я правильно помню, в соответствующем АРМ, нажал распечатать, как только распечаталось (эта информация тоже сохраняется и анализируется) идет задание на загрузку в кассы.

ууу… просто для информации: в РФ (куда вы так стремитесь) есть только одно место для определения цены товара — это ценник в торговом зале. И цена во фронте никого не парит от слова «совсем» :)
Это на качество системы автоматизации практически не влияет. Хоть 30 тысяч, хоть 1 пользователь.

Это говорит о глубине автоматизации.
Там выгрузить продажи в бек — не составляет никаких проблем (но и это не надо). Для принятия решений по скоропорту — достаточно текущего оборота в открытой кассовой смене и статистики продаж. Повторюсь — зачем остатки в онлайне?

Вам для заказа остатки не нужны? Ну-ну.
ууу… просто для информации: в РФ (куда вы так стремитесь) есть только одно место для определения цены товара — это ценник в торговом зале. И цена во фронте никого не парит от слова «совсем» :)

Именно. И когда она не совпадает с ценой на ценнике — это ЧП, с разборками, ущербом для репутации и много чего еще.
Это говорит о глубине автоматизации.

Это говорит только о том, что в бэке сидит 100500 человек в системе (отдельный вопрос — что они там делают). Больше ни о чем :)
Вам для заказа остатки не нужны? Ну-ну.

А какое отношение остатки в он-лайн (подчеркиваю — в он-лайн!) имеют к заказам? Или у вас смены не закрываются? Или вы не знаете, что такое статистика продаж (ну хотя-бы за пару лет)?
И когда она не совпадает с ценой на ценнике — это ЧП, с разборками, ущербом для репутации и много чего еще.

Если у вас нет электронных ценников — это будет ВСЕГДА. И никакого ЧП, разбора и все прочего :) Это рядовая ситуация.
отдельный вопрос — что они там делают

Ну уборщику и охраннику (и то не факт) там понятно что нечего делать. Но всем остальным. Например подтверждение выноса ценника, где по вашему должно делаться? Ну и прочие контроли по срокам годности и т.п.
А какое отношение остатки в он-лайн (подчеркиваю — в он-лайн!) имеют к заказам

К тому чтобы заказать скоропорт в системе желательно видеть сколько там его сейчас на остатках (понятно что и на зал сходить, но это двойной контроль). Причем тут смены?
И никакого ЧП, разбора и все прочего :) Это рядовая ситуация.

Не, ну если для вас это рядовая ситуация, то сочувствую таким сетям и их покупателям.
Но всем остальным.

Переоценку утверждает уполномоченное лицо.
чтобы заказать скоропорт

Т.е. все, что используется у вас для заказа — это текущий остаток?
Причем тут смены?

Как только закрыли смену — появился Z-отчет. Как только появился Z-отчет — у вас есть продажи смены и изменились остатки. Зачем остатки в он-лайне? Неужели в ответ будут только лозунги?
Не, ну если для вас это рядовая ситуация

Судя по вашим ответам — вас в рознице ждет еще масса «открытий» :)
Переоценку утверждает уполномоченное лицо.

Это вы к чему? Ему в системе работать не надо?
Т.е. все, что используется у вас для заказа — это текущий остаток?

Где я сказал что все. Я сказал что он тоже очень нужен для заказа.
Как только закрыли смену — появился Z-отчет. Как только появился Z-отчет — у вас есть продажи смены и изменились остатки. Зачем остатки в он-лайне? Неужели в ответ будут только лозунги?

Ну это может в 90-х. Или в 1С. В современных системах «черновой» Z-отчет создается сразу и заполняется онлайн. И в этот же момент списываются остатки в том числе по партиям. Я уже сто раз повторил зачем, для повышения принятия оперативности решений минимум на день (в том числе по срокам годности, выносу товаров в зал, заказами скоропорта). В общем если сможете — сделайте и увидите как пользователи без этого жить потом не смогут.
Судя по вашим ответам — вас в рознице ждет еще масса «открытий» :)

Действительно, всего пара сотен проектов в рознице выполнена (причем не в мелкой, а большая часть в сетях от 20 до 600 магазинов / гиперов). Прям жду не дождусь.
И насчет не нужен, мы помню переводили одну сеть. У нас через час после задержек приема реализации звонили и ругались, почему остатки не актуальны. На аргумент, раньше у вас вообще в конце дня все принималось, ответ был: ну так к хорошему быстро привыкаешь.


Остатки только в конце дня и постоянно актуальные остатки — ну а между ними-то что?

Для оперативного дозаказа товара в рознице достаточно остатков с небольшим запазданием получаемых. Да даже и большим запаздыванием, главное до того, как начинается анализ остатков актуализировать остатки.

Так как ситуация в магазине ежесекундно меняется. И вы все равно не знаете — дошел ли тот человек, что взял товар с полки, до кассы или еще нет или он вообще передумал/денег не хватило.
подобные несерьезные аргументы с вашей стороны, которыми полны ваши тесты, и вызывают недоверие

Если тезис выделить жирным шрифтом, он не станет "серьезным аргументом". Он просто будет более заметным.
Меня, как стороннего наблюдателя, ваши выпады никак не убеждают.

То есть если из 6 наименований 1 раз встречается 1С, то это уже не "достаточно мало"?

Если брать категории:
очень много, много, достаточно много, достаточно мало, мало, очень мало.

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

Ну вот это вот полная чушь. Если внедрено через одно место и персонал клиента не обучен, то тогда да. В этом случае я видел и хуже ситуацию. УТ 11 не нужна никакая доработка. И резервирование там прекрасно работает и взаиморасчеты там великолепно сделаны. Себестоимость да… копейка в копейку онлайн невозможно посчитать, но предварительная считается вполне себе сносно, но если б вы понимали что такое себестоимость, то вам было бы очевидно почему так. На начальном этапе доработка учетной системы это вообще зло. Самое правильное это сначала научить клиента правильно использовать типовые механизмы, а потом после того как он научится ее использовать, после этого он банально сможет правильно сформулировать ТЗ на разработку. А иначе получается полная фигня. Ни учета ни прибыли ни себестоимости… Всё как Вы сказали.
Я не специалист по 1C и по lsFusion, поэтому не берусь сравнивать технические их преимущества и недостатки. Только хочу обратить внимание автора, что конечная цель — это автоматизация бизнеса и решение задач бизнеса.

Для бизнеса важно:
1) Цена вопроса в комплексе, учитывая все
2) Время поставки готового решения (не голой платформы)
3) Умение и желание персонала с этим работать
Подумайте и сравните свой продукт и решения 1С с этих позиций.

1С ориентирована на бизнес, а ваш продукт на разработчиков. Это видно сразу по вашему сайту, для бизнеса там ничего, все только про технологии.
1С предлагает готовые решения с возможностью их доработки за короткое время до нужд заказчика. Т.е. поставили и 80% задач уже сразу можно обрабатывать, а оставшиеся 20% постепенно допишут в обозримые сроки.
Вы предлагаете голую платформу, где чтобы что-то начать, надо сначала поставить разработчикам задачу и разработать Техническое Задание. Это нужно напрягать мозг владельцам бизнеса и топ-менеджерам, это неопределенность по времени и соответственно неопределенность по деньгам и результатам. Потом аналогично разработка и приемка. А бизнесу нужно деньги зарабатывать уже сейчас. Ждать никто не хочет, неопределенность никто не любит. По второму пункту 1С рвет вас как тузик грелку.

По третьему пункту — 1С на рынке уже 27 лет и откусила уже более 30%. Т.е. приблизительно можно сказать, что каждый третий сотрудник умеет работать с 1С. На вновь созданной с помощью вашей платформе автоматизированной системе работать никто не умеет. Обучать нужно всех.

И, наконец, бизнес не интересует особо, что там и как под капотом — работает, и ладно.

Вы, скорее всего, не понимаете своей ниши. Ваш продукт для разработчиков, поэтому вам надо идти к разработчикам и продавать его разработчикам. Или, если вы хотите продавать бизнесу, то вам нужно сначала разработать типовые отраслевые решения, как это сделано у 1С или Галактики. Без них бизнесу вы не нужны.
Так они и продают его разработчикам, вот, на хабре пишут))
На хабре да, согласен. Но на сайте у них: для бизнеса, для пользователей, для разработчиков — т.е. для всех.
1) Цена вопроса в комплексе, учитывая все
2) Время поставки готового решения (не голой платформы)
3) Умение и желание персонала с этим работать

Забыли самое главное, возможность адаптироваться под конкретные бизнес-процессы заказчика и меняться вместе с изменением этих процессов.
Подумайте и сравните свой продукт и решения 1С с этих позиций.

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

Так собственно и статья о том, что не допишут (потому как платформа ну очень неудобна для этого). Точнее может даже и допишут, но силами своего ИТ-отдела из 5 человек. И самое смешное, потом будут думать, что дешево (хотя по факту выкидывать полтора миллиона рублей в месяц).
Вы предлагаете голую платформу

Нет у нас еще есть набор из 1300 модулей, из которых мы как из кубиков собираем ровно то, что нужно заказчику. Вы же реально не думаете, что мы с нуля все пишем. И сроки внедрения у нас куда ниже чем 1С (мы местный рынок просто разрываем, а 1С у пары самых упертых только стоит).
Т.е. приблизительно можно сказать, что каждый третий сотрудник умеет работать с 1С

Ну по такой логике каждый первый умеет пользоваться C++. На нем браузер написан, через который мы с вами общаемся.
И, наконец, бизнес не интересует особо, что там и как под капотом — работает, и ладно.

До момента, когда бизнес хочет что-то изменить в системе. Потом его очень сильно начинает это волновать по опыту.
Кстати, вспомнил тут еще один минус. Сборка мусора в 1с как я понимаю на основе подсчета ссылок сделана, что ведет к утечкам из за циклических ссылок. Да, из за отсутствия ООП, замыканий, колбеков нормальных и прочего такое случается редко, но случается.
Сборка мусора в 1с как я понимаю на основе подсчета ссылок сделана, что ведет к утечкам из за циклических ссылок.

Там разве модуль не переинициализируется при каждом открытии, к примеру, документа?
В одном документе целый день не сидят (как правило) так что это не критично.
А причем тут модуль? Создали структуру, в нее вложили массив, в него несколько структур, в одном из свойств которой случайно закинули ссылку на корневую структуру. Все, утечка готова. Ни к какому модулю никоим образом не привязана так как вещь в себе.
А причем тут модуль? Создали структуру, в нее вложили массив, в него несколько структур, в одном из свойств которой случайно закинули ссылку на корневую структуру. Все, утечка готова. Ни к какому модулю никоим образом не привязана так как вещь в себе.


Все переменные модуля убиваются без разбора при его закрытии. Ничего там при закрытии уже не считается. Закрытие поэтому мгновенное (если нет записи в БД, конечно) — сколько бы «змей, кусающих себя за хвост» вы бы не создали в переменных в модуле.

Попробуйте смоделировать — легко убедитесь.
А 1с то глупые, свой инструмент делали для поиска циклических ссылок и выбрасывании исключения при создании таковой. А достаточно лишь модуль закрыть. (кстати что это означает?)

https://its.1c.ru/db/metod8dev#content:5859:hdoc
А 1с то глупые, свой инструмент делали для поиска циклических ссылок и выбрасывании исключения при создании таковой.


Это нормально.

А вдруг да вы какой то модуль не закроете долгое время. Или обрабатываете особо сложным алгоритмом особо много данных.

Лично я сталкивался с ростом потребления памяти на очень и очень нетривиальных многоступенчаттых отчетах, где далеко не один запрос, а друг за дружкой идут, готовя друг другу данные.

Но на типовых задачах подобной проблемы даже рядом нет.

И несмотря на то, что отчет съедал всю доступную память — при этом закрывался он довольно быстро. При закрытии модуля — все переменные убиваются сразу, одним махом.
Я там выше ссылку кинул где утечка останется даже после завершения сеанса пользователем (судя по описанному утечка до завершения процесса сервера жить будет)
Например, в форме описана переменная (или реквизит). При вызове процедуры, было установлено значение этой переменной. При выходе из процедуры значение этой переменной не сбросилось. Оно сбросится потом (когда будет закрыта форма), но событие LEAKS будем записано в технологически журнал.

Однако, если в качестве значения этой переменной установить саму форму, то переменная не будет уничтожена и останется в памяти все время работы процесса.
у людей которые в 1с достаточно давно, но мозги еще не атрофировались окончательно статья вызывает «противоречивые» чувства — они во многом согласны с автором, но кое в чем против или уточняют

у «святых воинов СКД» какой-то батхерт. добро бы еще по делу. спорить по вкусу устриц надо с теми кто их ел
У меня к платформе немного по-другому сформулированные претензии.
1. Абсолютное отсутствие структуры метаданных. Под 2000 общих модулей, дерево подсистем, на ветках которого пусто, код серверной части в том же модуле, где код клиентской части + костыли препроцессора. Ни малейшей связи между понятиями «подсистема» и «расширение». Структура «исторически сложилась» и, похоже, теперь все уже.
2. Ебенейший объем костыльного кода для типовых действий. Реализация типовой бизнес-логики через код на 99%. Хорошо работать может только красивый код. Увы.
3. Постоянное улучшение типовых конфигураций путем переименования объектов, перехода на новые версии БСП, изменения порядка следования параметров общих процедур.
4. Искусственные и ручные ограничения в разделении контекстов сервера и клиента. Реализация таблицы значений через массив структур, например. Попробуйте на клиенте заполнить excel через COM по данным с сервера. Хотели, конечно, как лучше. В итоге руками «программист» фигачит обращения к серверу в цикле на клиенте. Взаимодействие серверного контекста и клиентского должно быть полностью автоматическим и прозрачным, как в 8.0. Сложно? Точно проще, чем потом в конфигурациях руками каждый раз одно и то же делать.
5. Хорошие прикладные программисты вымирают. Сложность типовых конфигураций такая, что выживают только консалтеры и говнокодеры, способные сляпать внешнюю обработку за пару часов. Для сильных программистов просто нет должного объема ценных, но решаемых задач. Локально это, конечно, хорошо. На перспективу — плохо.
6. Плоская структура модулей. Ну вот что не дает добавить функционал подмодулей? Тупо закладки с названием и текстом? Ну ведь логично же, и сильно жизнь бы облегчило. Нет, мы будем отбивками с комментариями структуру рисовать. Как пещерные люди.
7. Выпуск принципиально разных платформ и конфигураций под одним названием. Но это уже про бизнес.

Но в контексте заголовка все это мелочи. «Почему 1С?» — потому, что бизнесу важна эффективность затрат, и при выборе платформы 1С эта эффективность в разы выше, чем у альтернатив. Спорить со мной по этому вопросу не нужно, это просто многократно подтвержденный и очевидный факт. А решение о выборе платформы принимает бизнес, а не ИТ.
«В итоге руками «программист» фигачит обращения к серверу в цикле на клиенте.»


Что мешает заполнить excel на сервере?
Например, его там вообще нету. Или он интерактивный и эта интерактивность на клиенте происходит. Или он собирается из частей, в том числе с клиента, и его полный объем — под 300Мб. Как бы сначала тянуть картинки на сервер, а потом через базу на клиент — совсем плохой вариант.
xls уже давно получается сохранением табличного документа без требования самого Excel. Если формируется прайс-лист с картинками, то картинки, наверняка, нужны еще для чего-то и живут там, где сервер до них может дотянуться. Рисуем обычный прайс в конфе и сохраняем в xls/xlsx/ods — это чем-то не устраивает?
Если это не прайс — зачем нужен такой огромный XLS?
В таком случае не понятно, чем не устраивает pdf. Чем это таким xls лучше, чем pdf? Может тем, что xls может содержать формулы, поля для ввода, скрипты? Что защищенный xls можно распарсить и обратно в 1С загрузить? Ну да. Поэтому-то и не получится сохранить табличный документ, а приходится заполнять через COM болванку на клиенте.
Чем это таким xls лучше, чем pdf?

Например тем, что XLS используется как входной формат для кого-то/чего-то другого.
И это все равно не отвечает на вопрос — зачем такой огромный XLS и почему «формулы» нельзя в 1С сделать, а отдать только результат. Тут вопрос в том, что в данный момент мне не ясна задача, а в текущем понимании Excel не очень нужен. Если там есть какие-то реальные ограничения — ок. Но пока ограничения не видны.
Да просто все, в данном конкретном случае на клиенте формируется защищенный прайс-заявка, с картинками, скриптами и формулами. Картинки тащатся с хранилки в домене, остатки и прочее с сервера. Клиент (в бизнес-смысле) его заполняет и отдает обратно, он загружается в 1С. Ну то есть часть логики зашита в xls в виде формул и VBS и выполняется изолировано, грузится обратно уже результат.
Не для поспорить, а просто вопрос: а веб-доступ не пробовали таким клиентам давать?
Нельзя, не того уровня клиенты (базарные бабы), и больно много их. Веб-доступ в ЛК мы сделали для клиентов, у которых нормальные (в целом) клиенты, производственники.
Даже если очень ограниченный интерфейс (и визуально и по правам)?
Хм… Интересно…
«Почему 1С?» — потому, что бизнесу важна эффективность затрат, и при выборе платформы 1С эта эффективность в разы выше, чем у альтернатив. Спорить со мной по этому вопросу не нужно, это просто многократно подтвержденный и очевидный факт.

Подтверждена чем или кем? А я считаю, что 1С — велосипед как на картинке. Спорить со мной по этому вопросу не нужно, это просто многократно подтвержденный и очевидный факт (и судя по плюсам в статье, не я один так думаю). То, что у каждого человека есть свое мнение, и он может его высказывать — это очень хорошо.
Кто бы чего не думал, а деньги — величина измеримая, от думания зависит слабо. Финансовый успех заметных альтернатив на уровне средней паршивости регионального франча 1С — это даже не смешно, это грустно.
Причем здесь финансовый успех? Какой финансовый успех у PostgreSQL? Ораклисты тоже все время над ним издевались, что вот у нас тут сертификаты, реселлеры и прочие. И сколько людей сейчас пользуются PostgreSQL, а сколько Oracle?
Ну можно еще сравнить количество рабочих мест. Будет то же самое, только в два раза хуже — за счет пиратских установок. Еще раз, вопрос в заголовке статьи «Почему 1С», а вот почему.

А степень велосипедности величина субъективная и неизмеримая, и вторичная в этом разрезе.
Извините, но ничего не понял. Причем все-таки здесь финансовый успех? PostgreSQL — успешен как продукт? А он во многом вырос на недостатках Oracle, противопоставляя себя ему.
Попробую объяснить. PostgreSQL — удачный продукт для IT. Поэтому, в частности, его использует фирма 1С (ИТшная контора в первую очередь) в своих продуктах.

Но это вовсе не продукт для бизнеса. Это продукт для ИТ. А вот 1С и аналоги — это продукты для бизнеса, и бизнес голосует кошельком. Почему он это так делает и как сделать, чтобы голосовал за другое, у меня мнение наработалось. Но это мое мнение, во-первых, никого не интересует, а во-вторых стоит огромных денег 8о)
Так и lsFusion — это продукт не для бизнеса, а для ИТ. То есть любая компания может взять lsFusion и делать на нем прикладное решение (точно также как и PostgreSQL), а затем его продавать. И это может быть как ИТ-компания (типа 1С), так и собственный ИТ-отдел не ИТ-компании.
Если «может», то почему не «берет»? Хотелось бы мне живьем увидеть ИТ-директора завода по производству, скажем, детских горшков, который приходит к собственнику и говорит, «yes, мы можем!», нахер 1С, давайте делать свою систему на IsFusion, или на FoxPro, или на C++, или на Ruby. Ну то есть я таких видел, но давно уже и мельком. Впрочем, я искренне жду появления заметного конкурента платформе 1С, потому что мне не очень нравится, как и куда развивается эта платформа.
Если «может», то почему не «берет»?

Потому что не знает про lsFusion и ее преимущества. Для этого и пишем статьи.
Да никто не говорит делать с нуля. Берем базовые модули отсюда github.com/lsfusion-solutions/erp (а тут функционала куда больше чем том же odoo) и вперед дорабатывать.
Причем здесь финансовый успех? Какой финансовый успех у PostgreSQL? Ораклисты тоже все время над ним издевались, что вот у нас тут сертификаты, реселлеры и прочие. И сколько людей сейчас пользуются PostgreSQL, а сколько Oracle?


Аналогия не та.

PostgreSQL — не конечного пользователя продукт.
Там действуют другие правила.
PostgreSQL выбор технарей изначально.

Бизнесу все равно что там глубоко под капотам — MySQL, PostgreSQL, Tarantool (гы, какие глаза были у одного любящего технические детали заказчика, когда я ему рассказывал что буду использовать Tarantool — я тогда тащился от его производительности, всем и всякому рассказывал — но у заказчика было такое лицо, что будто бы я использую технически термины чтобы его надуть на больше денег)

Имеют значения те вещи, что непосредственно взаимодействуют с теми, кто занимается бизнесом.
Вы как раз такую вещь и пилите.

Чисто технически отсылы помогли бы вам продвниуть вещи уровня PostgreSQL, nginx.

Но вы работает уже в другой области, где решают не одни только технари.
Так что отсылка к успеху PosgreSQL некорректна.
Бизнесу все равно что там глубоко под капотам — MySQL, PostgreSQL, Tarantool (гы, какие глаза были у одного любящего технические детали заказчика, когда я ему рассказывал что буду использовать Tarantool — я тогда тащился от его производительности, всем и всякому рассказывал — но у заказчика было такое лицо, что будто бы я использую технически термины чтобы его надуть на больше денег)


Бизнесу все равно, что под капотом — 1С или lsFusion. Не вижу принципиальной разницы между выбором платформы и СУБД. И точно также есть проблема и по специалистам, которые будут поддерживать PostgreSQL и Oracle. И заблуждения про производительность и все прочее.
Бизнесу все равно, что под капотом — 1С или lsFusion.


Э… Вот как раз нет.
Тут вы ошибаетсь.

Когда руководитель предприятия сам привык работать в 1С, когда он знает как легко найти программиста на 1С, а про вас и не слышал, когда владелец химчистки/кафешки/заправки/авторемонта может сразу купить готовое решение под свою специализацию бизнеса (даже если это решение и придется потом подточить под себя) — это принципиально влияет на принимаемое руководством предприятия решение.

Не вижу принципиальной разницы между выбором платформы и СУБД

Вы подходите с чисто технической точки зрения.
Но у бизнеса подход основан на чисто прагматических соображениях.

Ваш подход сработал бы, будь недостатки 1С действительно существенными.
А они незначительны, таковы, что технические недостатки нивелируются другими вещами — распространенность специалистов (и пользователей со знанием 1С и ИТ-шников), наличием готовых решений.

Такого чтобы «1С дико тормозит давай уходить на lsFusion» не ожидайте. Скорее просто пригласят квалифицированного специалиста по 1С, чтобы он отпрофилировал 1С, выяснил где именно узкие места и пофисил это. Ну или просто сменят прикладное решение на более свежую его версию, от 1С же. Или просто новый сервер купят. Или обрежут базу данных, оставят только информацию за последние полгода.

Мне вот интересно. А как по Вашему живет остальный мир без 1С? Страдает наверное сильно…
Мне вот интересно. А как по Вашему живет остальный мир без 1С? Страдает наверное сильно…


Рынок одним только техническим совершенством не взять — вы же это видите по своему продукту. Утверждаете что он совершеннее 1С, но массового перехода не наблюдается на ваш продукт с 1С.

Вообще какой смысл говорить про весь мир в обсуждении локального продукта?

Впрочем, можно от обратного: на фоне 1С всяческие SAP/Dynamics в РФ котируются плохо. Свою нишу конечно и SAP в РФ имеет, но 1С написал хорошую систему, которую потеснить на рынке не просто.

Недостатки конечно есть у всех, как и у вашей системы — ибо не ошибается лишь тот, кто ничего не делает.
Хех, я так понял люди выпустили в свет свою систему пару месяцев как) Я бы, честно, очень удивился бы если бы на нее сразу, в первый день народ пошел писать. А те кто пошли — вряд ли раньше чем через пол года-год что то покажут (если покажут).
Как я понял система была внутренней разработкой, просто ее решили «в массы» пустить.
Хех, я так понял люди выпустили в свет свою систему пару месяцев как) Я бы, честно, очень удивился бы если бы на нее сразу, в первый день народ пошел писать. А те кто пошли — вряд ли раньше чем через пол года-год что то покажут (если покажут).
Как я понял система была внутренней разработкой, просто ее решили «в массы» пустить.


Тогда вообще всё грустно.

Из опыта известно, что системы такого масштаба доводятся годами до состояния, когда ими можно уверенно-безопасно пользоваться.

Плюс внутренняя система, не сразу ориентированная на внешний рынок там тоже свои особенности типа «часть документации только в голове разработчика».
Из опыта известно, что системы такого масштаба доводятся годами до состояния, когда ими можно уверенно-безопасно пользоваться.


Мы в продакшене используем ее уже 7 лет где-то. Просто пару месяцев назад лишь начали писать статьи и рассказывать о ней.
Мы в продакшене используем ее уже 7 лет где-то. Просто пару месяцев назад лишь начали писать статьи и рассказывать о ней.


И че?
У меня вот есть мегакрутая интеграция веб-сайта с 1С. На рынке предложений, подобных по степени автоматизации — не имеется.

Тоже лет 8 как в экслуатации.

Но я отдаю себе отчет, что там все очень сильно завязано на бизнес требования конкретной фирмы.

И реализовать как отдельное универсальное решение будет крайне непросто. После отвязки от бизнеса — придется еще дебужить и дебужить заново. Хотя в нынешнем состоянии там давно уже все вылизано.

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


Имею и подобный опыт перепродажи уже созданный решений одного заказчика другому заказчику.

Все же склонен считать, решение изначально изготавливаемое как отчуждаемое и решения для конкретного бизнеса — это разные вещи.

Делать как универсальное отчуждаемое хотя ты делаешь под конкретные проекты — дорого очень. Поэтому с этим не заморачиваются.

Имхо разница в себестоимости аж в 2-3 раза. Так что что «делали для себя, использовали сами на сторонних проектах — и сделали идеальное решение универсальное» — не верится.
UFO just landed and posted this here
Нисколько. А сколько автор работал с lsFusion? Я просто хотел показать, что утверждения без аргументации «просто многократно подтвержденный и очевидный факт» не несут никакого смысла.
5. Хорошие прикладные программисты вымирают. Сложность типовых конфигураций такая, что выживают только консалтеры и говнокодеры, способные сляпать внешнюю обработку за пару часов. Для сильных программистов просто нет должного объема ценных, но решаемых задач. Локально это, конечно, хорошо. На перспективу — плохо.


так это уже во всю идет… опытные уходят

иначе 1с не затевала постоянно какие-то конкурсы и курсы то для ясельников, то для пенсионеров
Ну да, франч всегда был «работой для начинающих», но чем дальше, тем грустнее. Экосистема выталкивает больших рыбин, выживают и плодятся шустрые кильки.
экосистема 1с — это малые и средние предприятия

малые скоро окончательно загонят пинками в облака и будут просто продавать SaaS за подписку (Battle Pass ИТС улыбается и машет)

средние — их не так много чтобы «поглотить» всех кто 1с знает и владеет

крупные — тут уже у самой 1с шансы не велики, чтобы там про «даешь всемирный внедреж» не трындели. ей выходить «туда» банально не с чем
крупные — тут уже у самой 1с шансы не велики


Ну не совсем так, та же ERP на 1000-2000 рм вполне теоретически (по функционалу и платформенным ограничениям) имеет право на жизнь. Только вот беда, с таким количеством рм это будет не совсем «1С:ERP», это будет очень сильно перепаханая конфа, а скорее 2-3 конфы, связанные шиной. И вот чтобы такое реализовать, нужны спецы по глубокой доработке ERP, а откуда бы им взяться в товарных количествах? Для больших конфигураций нужна модульность, структурность, устойчивость стандартных библиотек, предсказуемость развития, разделение регл. учета и опер. учета, масштабируемость (привет реализации RLS в ERP), другими словами кастомизируемость без потери управляемости. Чего вообще совсем нет. Почти каждая УПП, работающая сегодня, это жуткий кадавр, слепленный из разных релизов той же УПП, говнокода в виде затычек для «обходных маневров», нашлепок поверх (внутри, поперек, понизу) типового функционала, кучи разномастных интерфейсов к другим системам. Но то УПП, на ERP такое просто большинство команд не вывезет, она сложнее на порядок.
самое «смишное» — что такой кадавр на УПП у меня вполне работает. потому что 1с бросила УПП и не занимается переписыванием ради переписывания
Для больших конфигураций нужна модульность, структурность, устойчивость стандартных библиотек, предсказуемость развития, разделение регл. учета и опер. учета, масштабируемость (привет реализации RLS в ERP), другими словами кастомизируемость без потери управляемости.


а как это сделать в условиях современной платформы и языка в 1С?

рефлексии нет — куча кода мусорного в БСП занимается выяснением в какой конфигурации оно сейчас работает, если ли в ней такая-то подсистема, есть ли в подсистеме такой-то общий модуль и т.п.

> устойчивость стандартных библиотек

подразумевает под собой имхо интерфейсы для оперирования абстракциями и ооп в виде инкапсуляций и перегрузки методов

и чтобы БСП не загромождало собой весь проект, а висело сбоку в виде присоединенной библиотеки

RLS в текущем виде — это вообще ад и израиль какой-то

но пипл схавает и так
Все так. То, что показалось на горизонте — то-ли крышка гроба, то-ли очередное дно. Но пробовать пробивать это придется уже очень скоро, песчинки в часиках УПП уже посчитать можно.
Конструктивная критика — это хорошо. Автор молодец и проделал отличную работу.
Сам занимаюсь 1С-ом уже 12 лет и у многих наверное возникает законный вопрос: «При стольких недостатках, почему 1С лидирует на постсоветском рынке ПО?».
Постараюсь дать ответ (а они же плюсы), не хочу никого защищать, просто аргументирую некоторые моменты и станет понятно почему так сделано:

1. Вы забывайте о постоянно меняющихся законах в РФ. Кассы, маркировка, ЕГАИС, новые постановления и правила и т.д. 1С очень оперативно внедряет в свои типовые решения все изменения в законодательстве. Пример, звонит клиент и говорит: «У меня стоит программа „Фирма“ я торгую в розницу. Программа меня устраивает, но вот вводятся в обязаловку кассы, автор этой программы „Фирма“ пока не известно добавит это или нет, но мне то нужно работать сейчас. Слышал, что работа с кассами есть в 1С. Это правда?» и вот вам пример, когда человек с программы, которая его полностью устраивает переходит на 1С. Вот автор работает в lsfusion, они сделали классное решение, но реально ребят, вы сможете поддерживать оперативно ВСЕ изменения в законодательстве и сделать аналог 1С: Бухгалтерии, например? Какой у Вас будет штат при этом? А сколько вам за это надо будет платить? Вот тут и приходит понимание, зачем нужен ИТС. Деньги от него идут как раз на актуализацию и развитие уже существующих решений.

2. Так же 1С выбирают потому, что есть большое количество специалистов 1С по всей стране. Если у вас что-то сломалось всегда найдете человека, который может починить/посмотреть/доработать. Специалистов по SAP и тем более lsfusion гораздо меньше (возможно пока), а если они есть, то стоят других денег.

3. Деньги на покупку решений, сервера 1С и клиентских лицензий. Если посчитать, то общая стоимость владения будет меньше чем у того же SAP. А для мелких фирмочек, где достаточно одного пользователя как раз и не нужно ничего серверного. Купил лицензию на решение и работай. ИТС да — это нужно, но и без ИТС торговля будет работать, но обновления использовать не сможете.

4. Скорость работы. Да это проблема, надо включать технологический журнал, делать замеры, использовать профилировщик (скажите где этого не нужно делать?), но все не так критично, когда к этому привыкаешь. Есть проблема с массовым изменением или удалением данных, в 1С этого нет. Все обрабатывается поштучно. В запросах нет UPDATE, DELETE, есть только SELECT. К тому, что нет ООП привыкаешь быстро. Но здесь есть другая сторона — скорость разработки. Связь с СУБД на уровне ORM появляется сразу. Не нужно думать, как работать с подключениями к СУБД на самом низком уровне, с балансировкой нагрузки, распределением памяти, очисткой памяти, кэшированием данных и т.д. За тебя подумает платформа. Создал объект, записал, прочитал и т.д. Добавил новую сущность и она сразу работает, оформи красиво формы ручками и вуаля — готовая форма для пользователей и можно приступать к работе. Скорость разработки приложений очень высокая и это огромный плюс.

Хочу подчеркнуть — я никак и никого не выгораживаю, просто попытка дать ответ на некоторые вопросы по ту сторону. Хотя свежий и не замыленный взгляд со стороны нужен обязательно и работать действительно есть над чем.
Спасибо за развернутое мнение. Но вы опять сравниваете конфигурации и платформу.

Это все не отменяет тех недостатков, которые описаны в статье. На PHP тоже пишут миллионы, но это не делает PHP автоматически лучшей платформой для разработки на свете.
Спасибо за развернутое мнение. Но вы опять сравниваете конфигурации и платформу.


Для выбора бизнеса — а такие вещи как инструмент для сердца бизнеса, учетная система — уже точно не пройдут мельком мимо глаз топ-менеджеров — именно типовые решения и важны.

Платформа и ее технически возможности бизнесу постольку-поскольку. Главное, чтобы типовые решения были.

Если бы 1С было полное говно, а ваше решение вкусная конфетка, то технические аспекты этих двух платформ бы сыграли важную роль.

Но это не так. Платформа 1С вполне себе рабочее решение. Недостатки есть везде. И у вас тоже.

Поэтому ваш оппонент и обращает внимание на то, что действительно важно для бизнеса — на конфигурации, на типовые прикладные решения.

Голое же техническое совершенство платформы в данном случае не дает конкурентого преимущества для бизнеса — поэтому с точки зрения бизнеса ваше решение не очень целесообразно.

Вы забывайте о постоянно меняющихся законах в РФ. Кассы, маркировка, ЕГАИС, новые постановления и правила и т.д. 1С очень оперативно внедряет в свои типовые решения все изменения в законодательстве.


ломая то что сама делала в прошлой версии. меня реально за… ли бесконечные дурацкие изменения. в той же БСП. постоянные изменения имен и сигнатур функций, шаблонов RLS и прочего. мы вынуждены(!!!) вытаскивать всё потребное и изолировать вызовы стандартных функций чтобы при очередном апдейте всё это не сломалось. Понятно дело что починим, но накладные расходы на внесение правок в хранилище БП 3.0, создание апдейта и пролив его на прод-сервер крайне велик

Да это проблема, надо включать технологический журнал, делать замеры, использовать профилировщик (скажите где этого не нужно делать?)


в нормальных средах под это есть инструменты. и они вменяемые!

а содержимое тех. журнала надо еще переводить(!!) с инопланетного на русский с помощью стороннего(!!!) сервиса. потому что 1с всем втюхивает совершенно бесполезный цуп
Я бы уточнил. Просто сказать — «много специалистов 1с» не достаточно. Специалистов PHP тоже очень много, но программной системы на PHP подобной 1С никто не создал.
ИМХО, главная причина популярности 1С в том что они навязали удачный паттерн структуры метаданных — Константы, Справочники, Документы, Регистры… Все программисты 1С даже на незнакомых конфигурациях имеют начальное представление о структуре системы, что сильно облегчает быстрый старт. Хотя бывают исключения. Мне пришлось разбираться с конфигурацией в которой почти не было «Документов» и все было сделано на «Бизнес процессах». Очень хотелось набить морду тому кто это сделал.
А главный недостаок 1С в его языке программирования. Вместо современного и прогрессивного ЯП 1С подсунул какую то самодеятельность кружка «умелые руки». Именно свой ЯП тормозит развитие и расширение 1С за пределы РФ.
Если бы 1С при переходе на 1С 8 внедрили в ней, например, язык Java то развитие платформы 1С не отставало бы от всего остального мирового ИТ так катастрофично.
Откройте конфигурацию любой реляционной БД, и там вы увидите её структуру с таблицами и зависимостями между ними. А дальше — всё равно надо читать код прикладного решения в IDE.
В любой реляционной БД на фантазию разработчика при создании структуры БД нет никаких ограничений кроме его совести. В конфигураторе 1С конечно тоже можно извратится, но там это просто не принято.
Мне пришлось разбираться с конфигурацией в которой почти не было «Документов» и все было сделано на «Бизнес процессах»
— Интересная тема для меня. Это было тиражное решение (название не помните)? Какая предметная область? Проблемы только в том, что трудно въехать или еще что-то?
Меня это интересует с той стороны, что все известные мне «убийцы 1С» эксплуатируют один и тот же набор «справочник-документ-регистр», не пытаясь выйти за его рамки. И я вот думаю: почему?
Точно помню что разработка 1С Бит. Конфигурация вроде «Автоматизация транспортной логистики». Хотя возможно путаю. Уже больше 5 лет прошло. От них требовалось доработать конфу чтобы можно было проложить оптимальный маршрут по заданным точкам. В 1С Бит потратили на это целый год, но они так и не справились и вернули деньги. Когда понадобилось настроить обмен с торговой базой с ужасом обнаружил, что почти вся логика сделана на на бизнес процессах. Мне кажется это у них обфускация такая — чтобы никто не украл, но в результате сами не смогли разобраться что они там наконфигурировали.

Меня это интересует с той стороны, что все известные мне «убийцы 1С» эксплуатируют один и тот же набор «справочник-документ-регистр», не пытаясь выйти за его рамки. И я вот думаю: почему?

Мне кажется просто по тому, что довольно удачное решение. По крайней мере для логистики и бухгалтерии.
Вы же понимаете что в пункте номер 1 вашего интересного тезиса и скрыта основная идея 1С — это система «подрядчик», это не для людей-разработчиков а для кого-то ещё, поэтому развитие этой платформы зависит на прямую от подряда, есть подряд будет работа — подряда нет работы не будет. Повторю свои тезисы до этого — всё прогресивное сообщесто 1С — тестирование, СБ, и прочие «сливки» этого не понимают, в итоге система есть система и не нужно имитировать свободное сообщесто тут — эта идея не для закрытой системы обреченной на вымирание из-за выше перечисленых особенностей.
кстати можете объяснить почему на западе используют много разных систем и затем интегрируют их, а в СНГ — пихают везде монстра 1С.
Например на западе многие используют Workday для учета кадров, SAP/Oracle FI для ведения главной книги, прочие нишевые ERP для ведения операций в определенной сфере (учет ТМЦ, торговля и т.д.) — не легче ли использовать несколько независимых систем, которые делают свое дело лучше всех в одной узкой нише, а потом сшить их вместе, чем пытаться городить монстра на глиняных ногах на платформе 1С?
на западе гораздо проще учёт
если сделать 50 разных независимых систем, и вместе их сшить, то через пару обновлений методики учета НДС или налога на прибыль, которые потянут за собой переписывание половины этих независимых систем, потому что они необходимые данные не предоставляют… очень быстро придет понимание почему у нас именно так сделано и 1С популярна в монолитном виде.

Я даже с 1С с таким сталкивался, потому что есть например 1СТорговля и 1С бухгалтерия, вроде как две независимые системы… сейчас появились всякие корректировочные счетафактуры и мне пришлось их вживлять в торговлю (7.7, которая не обновлялась больше 10 лет) тупо для того чтобы правильно работало формирование книги продаж в бухгалтерии. и это две части относительно совместимых систем одного вендора.
А теперь представьте что их больше.
на западе гораздо проще учёт

Бухгалтерский — да, проще.
Но производственный или учет торговли — как минимум не проще.
не проще, но он не зависит так плотно от налогового и бухгалтерского законодательства

вот у нас взмахом руки приказали внедрить маркировку кучи видов товаров и сдачу отчетности по реализации. что по цепочке потащило за собой обновление учетных систем продажи и учетных систем бухгалтерии (из которых и сдается отчетность)
У нас уже привыкли что государство махнет рукой, и какойнить X5 без вопросов шарахнет пару десятков миллионов рублей на внедрение новой строчки в в чеке или счете-фактуре, что влечет за собой переписывание кучи систем которые собирают данные для этой строчки.
Интересно, а на западе также разве? решит налоговая США видеть сколько продается помидоров причем чтобы была видна цепочка от поля до кармана покупателя и wallmart побежит обновлять свои учетные системы?
Да ладно, не преувеличивайте. Много франшиз всяких Zara и других ритейлеров сидят в своих системах, общих для всего мира.

Ну и если добавить строку в чек или послать пару запросов в какой-нибудь сервис это для 1С проблема, то сочувствую.
Сидят, но вы знаете как они сдают отчётность? там зачастую есть нашлепка которая делает выгрузку в 1С из их системы, а также есть отдел который собирает данные чутьли не в ручную в экселе и тоже вбивает (вгружает) их в 1С для этих целей
Я например видел фирму (забугорную по производству упаковки (один из конкурентов тетрапака)) у которой в екселе был написан монстроподобный скрипт на vba который подключался к какойто штуке по типу MS AX выгружал оттуда данные, потом гдето полчаса их обрабатывал и порождал xml весом под 400 мегабайт который вгружался в 1С и из неё уже они сдавали отчётность. тупо потому что это было проще и дешевле чем адаптировать их систему где тоже можно вести бухучет но делать это нереально

Ну и если добавить строку в чек или послать пару запросов в какой-нибудь сервис это для 1С проблема, то сочувствую.

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

Я вот не понимаю, у нас есть и ЭСЧФ и EDI и туча других сервисов. Это всего лишь одна из многих задач доработок, которых по 5 в день решается.

Вы сейчас про бух и налоговую отчетность. Да все равно, где ее сдают. И нам, и Zara, и Макдональдс. Это проблемы бухгалтерии.
получается вся сила 1С только в том, что «отчетность» перед регулирующими органами у них работает из коробки. Если это так, то 1С стоит использовать только для этих же целей — выгружать аггрегированные данные в 1Ску и нажимать кнопку составить отчет и отправлять налоговым и прочим регуляторам.
А нормальный учет по каждой области вести в специализированной системе
Если это так, то 1С стоит использовать только для этих же целей — выгружать аггрегированные данные в 1Ску и нажимать кнопку составить отчет и отправлять налоговым и прочим регуляторам.


Вы не поверите, но эта мысль пришла в голову очень многим людям за много лет до вас. Есть подобные практики.

Правда там отказ от 1С не обязателен.
Бывает что учет для себя ведут в одной системе 1С, выгружают в бухгалтерскую 1С для отчетности.

мне интересно, где точка безубыточности — когда выгоднее пилить самописку на 1С как первичную систему и городить там огород против использование спец.системы, 1С использовать по минимуму как побочную систему для отчетности налоговоикам и прочим.
Как бы так и есть много где. Напр. в Беларуси есть Хьюман Систем с «1С: Бухгалтерия» — без управляемых форм, зато с оперативным внедрением хотелок государства по учёту. Его использует бухгалтерия. А весь остальной учёт можно вести в чём угодно, выгружая первичные документы в 1С.
Такое бурное обсуждение…
Я — программист 1С. Стало любопытно, что же вы предлагаете, сравнивая свою программу именно с нашей платформой.
Поставил среду разработки и клиент. Сделал первый пример из мануала (MODULE Order). В принципе по коду понятно, что к чему.
Мне не понравился интерфейс — он ужасен. Правда, что открывать созданные документы можно только кнопкой Редактировать? Почему в списке документов не работает двойное нажатие левой кнопкой мыши. Почему не работает правая кнопка мыши? Почему на уровне платформы нет автонумерации документов и заполнения даты? (Как это есть у нас).
Можно ли из строки документа перейти к форме элемента справочника, минуя общий список справочника?
Возможно, программирование бизнес-логики будет удобно, но интерфейсом же нельзя пользоваться, особенно тем людям, которые привыкли к 1С.
Fusion
Простите, что пишу не по теме (не отвечаю на критику нашей программы), но очень интересно стало.
Правда, что открывать созданные документы можно только кнопкой Редактировать? Почему в списке документов не работает двойное нажатие левой кнопкой мыши.

Это мы в версию 3 добавили (текущий мастер), и на demo.lsfusion.org установлена (именно после долгого общения с 1Сками). Там же и дизайн изменен. Выпустим через пару недель.
Почему не работает правая кнопка мыши?

А что вы там увидеть хотите. Там сейчас по умолчанию настройки политики безопасности и логирование, можете подключать свои действия.
Почему на уровне платформы нет автонумерации документов и заполнения даты? (Как это есть у нас).

А зачем ее прямо в платформу тянуть? Для этого есть готовые модули в пакете Utils, нажмите CTRL+SHIFT+N (или CTRL+N) и напишите Document, там есть готовые классы с готовыми событиями, в частности на заполнение даты. То есть можете сделать REQUIRE Document; и наследоваться от Document.

А вообще это одной строкой делается:
date(Order o) < — currentDate() WHEN SET(o IS Order); // установить текущую дату при добавлении заказа
Можно ли из строки документа перейти к форме элемента справочника, минуя общий список справочника?

Backspace, емнип. Не очень очевидно, может на control или dblclick повесим. Мы специально не плодили лишних кнопок на экране, чтобы людям привыкшим с тачскрином работать было бы привычнее.
Вот тут написано, как делать автонумерацию.

Почему в списке документов не работает двойное нажатие левой кнопкой мыши

На самом деле, это дело привычки. Все таки в вебе это не является базовым поведением (двойной щелчок как редактирование в списке). Когда мы переводили некоторых клиентов на новую версию платформы, то они умоляли отключить это поведение (так как для них это непривычно и часто случайно открывают редактирование).
Вот тут 1С вас уделывает. Пока на lsFusion программист будет прописывать и тестировать автонумератор, в 1С он создаст новый документ с номером, датой, пометками проведения и удаления (см. «Стандартные реквизиты»). Причём номер будет уникальным в пределах квартала, иметь длину ровно 10 знаков, и обладать префиксом подразделения компании в котором создан документ (к примеру).

А если аналогичный автонумератор должен быть у группы документов, его можно будет использовать повторно, или нужно будет использовать древний программистский приём Ctrl-C Ctrl-V?
Нет. Не совсем так. Автонумерации нету в самой платформе, но она легко делается (и мы так делаем в ERP) через метапрограммирование. Это достаточно мощный механизм, которого нету в 1С. Можно посмотреть примеры вот в этой статье (там в начале) и про IDE(там есть GIF как это работает в IDE). Суть в том, что можно объявить метакод, который потом будет генерировать нужный код в зависимости от параметров. В частности, если подключить модуль Numerator (можно считать эти модули, что-то типа БСП в 1С), то нумерация добавляется одной строкой:
@defineNumeratedDefault(order, 'Заказы', 'ЗК');

Вообще метакоды мощная штука, которая позволяет строить модули, которые будут автоматически генерировать сложный функционал (хотя конечно его надо использовать с оглядкой, как и макросы в C++).

Шаблоны конечно не самая удачная концепция в программировании, и в С++ в частности. Но ладно, по крайней мере это реализуемо в lsFusion, и поддерживается IDE. Хорошо, а в ООП-стиле возможно такое сделать: создать документ со стандартными реквизитами (номером, датой, пометками проведения и удаления), и от него наследовать свои документы (Реализация, Поступление, Счёт и т.п.)?

Ещё я не нашёл в документации, есть ли в lsFusion аналоги стандартных функций 1С и проч. языков для работы с числами, строками и датами? Ну там целочисленное деление, взять по модулю, сдвиги разрядов влево-вправо. Для строк — Trim, сконвертировать число в строку, дополнить нулями слева до указанного числа разрядов. Для дат — день недели, месяц, число дней в месяце, работа с периодами и т.п.
Да можно. Создаете абстрактный класс Document добавляете туда свойства DATA и наследуете класс, например, SaleInvoice. У всех наследуемых классов будут эти же свойства доступны. Второй вариант — когда свойства у Document тоже абстрактные (ABSTRACT), а у конкретных классов DATA свойства, которые в явную имплементятся через abstract += concrete. Вот тут примеры.
Тут тот же нюанс, как и в классической разработке. Делать класс и интерфейс или абстрактный класс. lsFusion поддерживает оба варианта, но разработчик сам решает что использовать, так как у каждого варианта есть свои преимущества и недостатки.

По второму абзацу: так как lsFusion использует PostgreSQL по сути как «виртуальную машину», то такие штуки просто транслируются на PostgreSQL через FORMULA. Суть в том, что вы можете написать в литерале любое выражение на PL/SQL (в том числе обратиться и к пользовательским функциям в базе данных), и оно транслируется в запрос. Именно таким образом мы решаем все описанные выше проблемы в решениях.
Больше выбора для разработчика это прекрасно.

Что касается функций. Да, это круто, что при крайней необходимости можно обратиться к нижележащей БД или Java и реализовать необходимое. Но, должен заметить, что элементарные функции по работе с числами, строками и датами, их преобразования, всё же должны реализовываться на уровне платформы. Они есть во всех языках программирования, в 1С, да даже в Access, Excel. Т.е. в платформе уже должны быть готовые модули с библиотечными функциями. А иначе:
  • Мне как потенциальному разработчику на lsFusion придётся глубоко изучать SQL-диалекты MS SQL, PostgreSQL и др. СУБД, с которыми будет работать ваша платформа, чтобы реализовать и отладить эти функции на всех диалектах.
  • Кто-то тоже будет делать такие же функции, но немного с другими именами и параметрами. И если я, допустим, решу использовать чей-то модуль lsFusion в своём приложении, то он потянет все эти модули. С которыми тоже придётся разбираться

А когда есть стандартная библиотека, в которой, например, для извлечения подстроки используется функция Mid с параметрами Строка, Начальный символ, Длина подстроки (так в Excel), и все разработчики будут её использовать, то мне не придётся постоянно вспоминать что это. И я буду уверен, что эта библиотечная функция точно отлажена, и точно работает на любой СУБД, которую поддерживает платформа.

Ещё лучше, если вы реализуете такие функции как методы классов (или в вашей терминологии свойства классов) строковых, числовых и проч. Чтобы к ним можно было обращаться через точку (Str.ToInteger). Тогда будет работать автодополнение кода в IDE.

Но это, конечно, элементарные вещи, и вы скорее всего это и так прекрасно понимаете. А так пока получается довольно пустой фреймворк, хотя и с большим потенциалом. Буду следить за развитием.
На самом деле, в платформе уже есть куча готовых функций по работе с примитивами:
github.com/lsfusion/platform/tree/master/server/src/main/lsfusion
Например тут:
github.com/lsfusion/platform/blob/master/server/src/main/lsfusion/system/Time.lsf
И тут:
github.com/lsfusion/platform/blob/master/server/src/main/lsfusion/system/Utils.lsf
Но если их не хватает, можно дописать еще. А еще лучше дописать и сделать сделать pull request.

Ну и преобразования типов поддерживаются:
f(INTEGER i) = STRING(i);

Да, именно такое имел ввиду. Но искал в документации. Ок, спасибо, посмотрим...

Так!..
А у isFusion есть недостатки? или они есть только у 1С?
Вот тут человек частично описывал.
главный недостаток — по уровню развития isFusion лет на 10 отстает от 1С проталкиваят пассажи типа «асинхронность это плохо» и «никому не надо управлять серверными вызовами»
Как я понял концепцию, lsFusion — это 3-звенка. Есть 1) СУБД, в которой хранятся данные, и на уровне которой осуществляется контроль физической и в некоторой степени логической целостности информации (это уже огромный плюс). Дальше 2) Сервер приложений, где исполняется большая часть бизнес-кода. И есть 3) клиентские приложения на разных платформах (десктоп, тонкий клиент, смартфон и т.п.), на котором работает пользователь.

Платформа позволяет в случае чего перенести часть бизнес-логики в клиент, подключить торговое оборудование и проч., даже написать часть клиентского приложения в Java. Но тогда теряется скорость разработки. Т.е. платформа всё же заточена на трёхзвенную работу, где каждое звено решает свои задачи.
платформа 8.0 тоже была трехзвенкой :)
Нет. Она код на клиенте в основном выполняла, постоянно бегая за данными на сервер. lsFusion только информацию о действиях пользователя передает, назад забирает изменения state, и применяет их. Прикладной логики на клиенте никакой не выполняется, вообще. (ну кроме клиентских действий но это для стыков)
Прикладной логики на клиенте никакой не выполняется, вообще. (ну кроме клиентских действий но это для стыков)


это как раз плохо…
понятно что рано или поздно в до этого дорастете как 1С доросла -но выдавать то что вы еще не используете ровно потому что немного не ваш уровень автоматизации за недостаток — не очень корректно
Специально зарегистрировался что бы прокомментировать.

Почитал статью, почитал комментарии на хабре, почитал уже 2 ветки обсуждения этой статьи на мисте.

Вывод: lsFusion отстает примерно лет на 10 от современной платформы 1с8 и соответственно все ограничения, костыли и «это не нужно» обусловлено именно этим состоянием развития платформы lsFusion.

— серверными вызовами управлять нельзя (чтобы бы не писали в статье авторы после долгой дискуссии они это признали и это весьма печально)
— стремление писать не запросы а функции платформенные думая что «чем меньше кода тем лучше»
— любовь к отображению отдельно дерева иерархии отдельно содержимого папки
— даже электронные счета-фактуры преподносятся как что то революционное (они в Белоруссии только появились)
— если чего то в платформе нет — это не нужно (контекстные обсуждения, видеоконференции, голосовые звонки и тд)

+ так называемая ERP не содержит ни управления персоналом ни бухучета — по сути она автоматизирует узкую задачу — FMCG, нет того же WMS…

Причем УТ11 как бы не является специализированной конфигурацией для автоматизации FMCG, но авторы там где им удобно критикуют как УТ11 не очень подходит для FMCG, а там где им не удобно (синхронизация с битриксом, CRM, СКД и отчеты) переходят к сравнению платформ и пытаются преподнести то от чего 1С отказалась много лет назад методологически и эволюционно как преимущество lsFusion над 1С

в общем — неубедительная статья… для тех кто действительно знаком с 1С платформой и современными решениями на 1С статья весьма смешна…
Это статья вообще не про lsFusion.
Вывод: lsFusion отстает примерно лет на 10 от современной платформы 1с8 и соответственно все ограничения, костыли и «это не нужно» обусловлено именно этим состоянием развития платформы lsFusion.

Еще раз. Смотрите, основной тезис статьи какой. У 1С была относительно быстрая и простая разработка, но не масштабируемая. Они сделали шаг назад, и теперь у них медленная и сложная разработка, но масштабируемая. А могли бы сделать быструю, простую и масштабируемую. То есть с точки зрения разработки сделали шаг назад (а точнее вниз). И при этом сделав шаг вниз грубо говоря в сторону .Net, при этом не взяли ничего хорошо, что как раз у .Net есть.
+ так называемая ERP не содержит ни управления персоналом ни бухучета — по сути она автоматизирует узкую задачу — FMCG, нет того же WMS…

Причем УТ11 как бы не является специализированной конфигурацией для автоматизации FMCG, но авторы там где им удобно критикуют как УТ11 не очень подходит для FMCG, а там где им не удобно (синхронизация с битриксом, CRM, СКД и отчеты) переходят к сравнению платформ и пытаются преподнести то от чего 1С отказалась много лет назад методологически и эволюционно как преимущество lsFusion над 1С

В статье про решения ни слова. Там речь идет, чисто о платформе. А код из УТ приводится чисто как практика использования платформы. И многое от чего они отказались с большой вероятностью является просто следствием ограничений платформы. И то что вы говорите очень похоже на «все беды от мяса» из двенадцати стульев.
— серверными вызовами управлять нельзя (чтобы бы не писали в статье авторы после долгой дискуссии они это признали и это весьма печально)

Ими не то что нельзя (клиентские действия тоже есть), ими просто не надо управлять. Тут постоянно повторяют, что 1С платформа для решения бизнес-задач, а не для технарей, которые хотят управлять всем. Про ЭСЧФ и остальное вы из контекста вырвали. Ну и вы с УТ 11 про «это не нужно» тот же прием используете, в УТ11 сделали не так потому что «так не нужно».
в общем — неубедительная статья… для тех кто действительно знаком с 1С платформой и современными решениями на 1С статья весьма смешна…

Повторюсь в стопятьдесятый раз. Почитайте самый заплюсованный комментарий. Это Хабр. С чем то не согласны в статье напишите по пунктам.
«Отказ от единого потока выполнения: разделение логики на сервер и клиент»

на мисте подробно с вашими коллегами прошлись по этой теме.

В вашей концепции: разделение не нужно и платформа сама всем рулит.
По факту оказывается что когда у меня сложная форма расчета, у вас на каждое событие в элементах формы делается серверный вызов с неуправляемым возвратом данных с сервера.

Для систем уровня «выбрали товар, ввели цену и распечатали накладную» — это не критично.
Но, это логика платформы 1С десятилетней давности — которую платформа 1С переросла давно как раз в связи с развитием мобильных облачных и прочих клиентсерверных технологий с тонкими и веб клиентами.

Вы же пытаетесть то что 1С переросла давно преподнести как ваш плюс и недостаток 1С.

Пример: форма с сотней-другой элементов. Пока я заполню нужные для рассчета данные мне серверные вызовы не нужны… особенно контекстные. Вы же этим не управляете потому что платформа не может. Явный минус своей платформы вы преподносите как плюс а явный плюс платформы 1С преподносите как минус…
По факту оказывается что когда у меня сложная форма расчета, у вас на каждое событие в элементах формы делается серверный вызов с неуправляемым возвратом данных с сервера.

Уже ответили. И если элементы не от чего не зависят, то и вызовов не будет. Плюс асинхронный вызов с парой байт при выходе пользователя из поля с точки зрения масштабируемости это ничто.
которую платформа 1С переросла давно как раз в связи с развитием мобильных облачных и прочих клиентсерверных технологий с тонкими и веб клиентами.

Переделала, потому что не смогла нормально реализовать. И в статье про это есть.
Уже ответили. И если элементы не от чего не зависят, то и вызовов не будет. Плюс асинхронный вызов с парой байт при выходе пользователя из поля с точки зрения масштабируемости это ничто.


по факту с конкретное примером уже ответили что каждое изменение — будет вызов и обратка и я не могу этим управлять.

пример еще раз:

20 элементов на форме, я последовательно их заполняю.
все 20 участвуют в расчете и результаты расчета должны отобразиться на форме и должны обновлять расчет при каждом изменении элемента.

сколько у вас будет серверных вызовов?
а если мне не надо делать расчет пока не будут ВСЕ элементы заполнены — серверные вызовы все равно пройдут… и вернутся…
я не могу на клиенте не делать серверный вызов…

Переделала, потому что не смогла нормально реализовать. И в статье про это есть.


В статье не про это.
Вы бизнес-кейс напишите для начала -а потом сравните с тем как это сделано в 1С и оцените «решена задача для пользователя или нет»
а если мне не надо делать расчет пока не будут ВСЕ элементы заполнены — серверные вызовы все равно пройдут… и вернутся…

Сделайте действие и пусть пользователь жмет это действие.
серверные вызовы все равно пройдут… и вернутся…

Ну даже если пройдут и вернутся. Еще раз, вы представляете, что такое даже если 10000 пользователей будут слать по одному асинхронному хттп запросу при выходе из поля. Вы видели что в гугле, когда в поисковике набираете, постоянно шлются асинхронные хттп-запросы, чтобы подсветить вам результаты. На масштабируемость это никак не влияет (более того вы также предлагаете с вводом в список делать), а вы представляете сколько у них таких запросов.
Вы бизнес-кейс напишите для начала

А смысл? Вы все равно скажете, что это не нужно.
Еще раз, вы представляете, что такое даже если 10000 пользователей будут слать по одному асинхронному хттп запросу при выходе из поля.

Ну я вот представляю.


На масштабируемость это никак не влияет

Напомните, пожалуйста, lsFusion умеет конфигурации "один сервер БД — сто серверов приложений"?

Ну я вот представляю.

И как? По вашему какой сервак, нужен чтобы просто послать http запрос без body и сразу получить пустой ответ с нагрузкой, где-то 100 запросов в секунду?
Напомните, пожалуйста, lsFusion умеет конфигурации «один сервер БД — сто серверов приложений»?

Естественно.
По вашему какой сервак, нужен чтобы просто послать http запрос без body и сразу получить пустой ответ с нагрузкой, где-то 10 запросов в секунду?

Любой разумный. Я не удивлюсь, если t2.micro такое выдержит.


Естественно.

Если не секрет, как в этой ситуации работает реактивность вида "один пользователь изменил значение в форме, другой пользователь это немедленно увидел"?

Любой разумный. Я не удивлюсь, если t2.micro такое выдержит.

Видите, а тут человек, активно доказывает, что это самая главная проблема масштабируемости и производительности.
Если не секрет, как в этой ситуации работает реактивность вида «один пользователь изменил значение в форме, другой пользователь это немедленно увидел»?

Через базу. Речь все-таки о бизнес-приложениях. Есть еще всякие уведомления, но они domain-specific. То есть игрушку написать сложно будет. :)
ну как я и писал: так как вы не сталкивались с задачей — вы отметаете инструменты разработанные другими для решения задач с которыми вы не сталкивались…

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

А я не понимаю, как одно другому противоречит. Вы спросили, сколько стоит получить запрос и послать пустой ответ, а не сколько стоит сделать полезную работу на сервере.


Через базу.

То есть у вас база умеет слать уведомления апп-серверу?

То есть у вас база умеет слать уведомления апп-серверу?

Не начинайте :) Тут и так уже под тысячу комментариев. Я написал, что онлайн игру не напишите. Тут .Net выиграл.

Да онлайн-игры-то не при чем. У меня просто где-то в подсознании брезжит заявление одного из ваших коллег о том, что все формы в lsFusion — реактивные, и мне еще тогда было интересно, как это масштабируется. Но, похоже, я все-таки что-то не так понял.

Они реактивные вот в каком плане (пример снизу чтобы лучше понять внутрянку):
codesandbox.io/s/1y0o894rx4

Вы шлете изменение (change x на 5), а сервер сам определяет, что надо поменять, присылает изменение state'а и дорендеривает это изменение. Такой React только и со стороны бэка.

Проблема маркетинговых терминов (в том числе и "реактивный") в том, что каждый понимает их по-своему. А потом спрашивает у оппонента: "а у вас все формы по умолчанию реактивные"? И тот такой "блин, из коробки нет, никогда не было надо, блабла", а потом выясняется, что первый под реактивностью понимает то, что для второго является само собой разумеющейся оптимизацией отрисовки.

В этом то и дело — недостатки платформы компенсируются дополнительными серваками и дополнительной нагрузкой на сервера…

1С позволяет при необходимости решать это средствами разработчика не нагружая сервер.

Причем работать по схеме «пофиг — сервер докупим» так же никто не запрещает…

но почему то возможность 1С управлять серверными вызовами — авторы статьи ставят в МИНУС платформе…
В минус никто не ставит. В минус ставят то, что она не умеет это автоматически делать. Это тоже самое, что сейчас говорить, что файловые СУБД значительно лучше SQL серверов. Там же вручную можно по файликам бегать значительно эффективнее. А планировщик запросов ошибаться может. Так?

Поэтому 1С сделал просто шаг на 10 лет назад. Как если бы сейчас перешли с SQL серверов на файловые СУБД.
вы теплое с мягким путаете…
я могу рисуя форму 1С на все контролы вешать серверный вызов по умолчанию и у меня форма будет как у вас делать при каждом событии серверный вызов…

а могу в зависимости от логики прописать через концепции на сервере, на клиенте и тд — схему обмена данным клиента с сервером для оптимизации нагрузки и ускорения работы формы…

я как разработчик САМ решаю как мне делать исходя из бизнес-задачи.

вы же говорите что нет, то что у меня ЕСТЬ ВОЗМОЖНОСТЬ управлять этим — это плохо…
Нет, просто lsFusion не экономит на спичках. А экономит, на том чем надо экономить — оптимизаторах запросов, посылке правильных диффграм, кэшировании и т.п. А параметры серверов тут уже где-то приводили.
я не увидел у вас ни одной сложной формы с сколь бы то ни было сложным расчетом.

у вас весь учет — автоматизация сети ларьков с соответствующими потребностями… где действительно все возможности 1С 8.3.16 не нужны и достаточно возможностей 1С 7.7

то есть ваши задачи — это задачи реализуемые на платформе 1С десятилетней давности…
у вас весь учет — автоматизация сети ларьков с соответствующими потребностями…

Сети гипермаркетов и супермаркетов с 10к сотрудников и тысячами бизнес-процессов.
Тут и тут читать.
не увидел ни одной сложной формы… ни одного сложного расчета…
всякие бухгалтерские балансы и зарплатные расчеты/отчеты вы обошли в своей ЕРП, производства и каких либо расчетов у вас нет…
Пример плохой. У приведенного вами клиента 17 магазинов указно на сайте. Вы хотите сказать, что у него в каждом из 17 магазинов по 500+ пользователей вашей системы? И это при том что у указанного клиента есть еще 1С, BI, фронт и «интеграция с другими системами»?

Про «тысячи бизнес-процессов» тоже давайте определимся. Пример хотя бы одного бизнес-процесса подробно приведите, чтобы был понятен масштаб и сложность и не было недопонимания и передергиваний с обеих сторон.
Этой сети, если вы не в курсе, другая сеть еще принадлежит. И я написал 10к сотрудников, а не одновременных пользователей. Одновременных пользователей у них в сумме около тысячи.

Вы по ссылкам пройдите. Там небольшая часть бизнес-процессов контурно описано.
И я написал 10к сотрудников, а не одновременных пользователей.

А какая разница, сколько в сети сотрудников, если они в вашей программе не работают, а расчет зарплаты в 1С, не совсем понимаю?
Показывает что это не «ларек»? Так под ларьком, не обязательно подразумевается буквально палатка с овощами. Это скорее вопрос сложности бизнеса/уровень автоматизации/сложность процессов.

Вы по ссылкам пройдите. Там небольшая часть бизнес-процессов контурно описано.

Проблема именно в том что «контурно». Т.е. сложно оценить и понять о чем конкретно речь.
То что упомянуто (например, автоподпитка зала товарами с собственного склада по мере продажи и формирование ЭЦП) на «сложный бизнес-процесс» не тянет.
ну… у 1С по сумме рабочих мест больше миллиона :) :)
Сети гипермаркетов и супермаркетов с 10к сотрудников и тысячами бизнес-процессов.

Сколько % из этих сотрудников не продавцы и не грузчики?
А менеджеры-товароведы и т.п.? Это те, кто собственно и дает нагрузку на подобные системы.
Сделайте действие и пусть пользователь жмет это действие.


ну то есть видите — вы начинаете придумывать костыли в виде кнопок там где они не нужны…
а придумываете потому что по другому не можете сделать.

но самое что вы критикуете платформу которая:
1. может без вашего костыля решать подобные задачи.
2. может так же как и у вас через кнопки решать подобные задачи.

Там же у них есть т.н. локальные свойства: объявляете свойство как DATA LOCAL, и работаете с ним локально, без пересылок на сервер.

Disclaimer: я только начал смотреть lsFusion, могу ошибаться.
интересен комментарий авторов статьи тогда в двойне… :)

они тогда противоречат своей же платформе которая тоже умеет управлять серверными вызовами, хотя текущие персоналии автоматизирующие бизнес этой возможностью не пользуются и пишут статьи что это не нужно :) :) :)
Еще раз. Смотрите, основной тезис статьи какой. У 1С была относительно быстрая и простая разработка, но не масштабируемая. Они сделали шаг назад, и теперь у них медленная и сложная разработка, но масштабируемая. А могли бы сделать быструю, простую и масштабируемую. То есть с точки зрения разработки сделали шаг назад (а точнее вниз). И при этом сделав шаг вниз грубо говоря в сторону .Net, при этом не взяли ничего хорошо, что как раз у .Net есть.


вы тут просто заблуждаетесь: 1С как раз сделала шаг вперед и система от этого не перестала быть менее удобной для разработки и для быстрых решений.
Вы сейчас повторяете то что 10 (десять) лет назад повторяли все те кто доказывал что платформа 8 не нужна и все можно делать на 7.7… особо горячие головы пытались на 7.7+1С++ ваять аналоги СКД и конструкторов запроса…

это рассуждения уровня «автомобили — шаг назад по сравнению с гужевым транспортом… раньше как было, утром покормил коня сеном и поехал в город… дорога не нужна, бензин не нужен… конь проголодался- пощипал травку и дальше поехал» :)
это рассуждения уровня «автомобили — шаг назад по сравнению с гужевым транспортом… раньше как было, утром покормил коня сеном и поехал в город… дорога не нужна, бензин не нужен… конь проголодался- пощипал травку и дальше поехал» :)

Вы реально не понимаете о чем речь. Платформа могла бы все описанные вещи делать сама. То что вы пишете, чистой воды луддизм. Конвеер это плохо — так как он не гибкий, давайте использовать ручной труд.
еще раз аналогия которую приводил на мисте:

есть айфон с автоматическим режимом съемки — и он идеален для…
а есть профессиональный фотоаппарат зеркалка с ручным режимом…

вы пытаетесь меня убедить что профессиональный фотоаппарат хуже айфона потому что… в мире селфи ручные настройки не нужны…

я же вам объясняю что у меня есть и авто режим и ручные. и в зависимости от задачи я работаю с авто режимом а когда надо — руками настраиваю параметры съемки.
Нет, у вас есть камера уровня кнопочного телефона (ОФ и автоматические блокировки, которые под нагрузкой будут очень неэффективно работать) и профессионального аппарата.

А идеальный вариант, это аппарат, который сможем максимальные настройки вытянуть одной кнопкой (ну и плюс базовые настройки). И такие аппараты это масс-маркет, а профессиональный аппарат, оставьте профессионалам (и тогда это не 1С, а скорее .Net с React будет).
Если вы сравните просто возможности платформы 1С и платформы lsFusion — вы увидите что ваше сравнение мягко говоря некорректно… платформа lsFusion по функциональности лет на 10 отстает…

Если вы сравните «коробочные решения» и будите сравнивать вашу ERP но даже не с 1С:ERP2 а с простой торговой конфигурацией УТ11 — вы даже тут увидите что по функциональным возможностям ваша конфигурация отстает на те же 10 лет… и даже близко ваша ERP не подошла к функциональностям УТ11…

по этому аналогия «фотоаппаратов» — весьма корректна.
у вас узкое решение для автоматизации продаж с лотка… сети лотков…
и на мир вы смотрите со стороны торгового лотка не понимая потребности другх аспектов автоматизаций бизнеса…

и соответственно статья написана с учетом этого и по этому столь наивна…
Тем что вам не надо думать. А работать все равно будет очень быстро.


8.X это не шаг вперед

это шаг в сторону по сути

решили сделать «по взрослому», но одновременно оставить базовый девиз «каждая кухарка должна залезть в конфигуратор». а так не бывает

в итоге продолжаем уже 10 лет из кубиков «ж» «0» «п» «а» выкладывать слово «вечность»

ОФ бросили, сделали УФ (но до ума до сих пор не довели — нагруженный gui в нем не сделать), присобачили клиент/сервер и асинхронность сбоку — жизнь заставляет, но нормальную реализацию мы делать не будем по тому что не хотим и не можем. в 7.7 человек занимался ананизмом в выборках, теперь во взаимодействиях между серверной и клиентской стороной формы. причем в бОльших количествах

вещи триумфально выпиленные из gui типа «показать в списке» вернули на место когда поняли что в очередной раз обделались

основные сущности которыми оперирует программист давно переросли понятие «одиночный справочник». сущность «Основное средство» или «Сотрудник» это по сути уже 2..3 справочника и целый ворох регистров сведений. Защиты логики по сути никакой нет, каждый отчет интепретирует состояние объекта по своему в дербях текста запроса из пары тысяч строк кода, концы с концами вообще никак не сходятся

и еще ворох всего
1С развивается…
да… какие то вещи выпиливаются потому что с ходу в новые парадигмы не влезают… но постепенно возвращаются в другом исполнении но вписанные в новые парадигмы…

простейший пример: управление видимостью элементов с серверным вызовом…
как только развили платформу — сразу эту ересь отключили и теперь изменение видимости не делает серверный вызов…

дада

еще лет 15 и вернут назад просмотр состояния наложенных программных отборов на список… уберут эту порнографию из «фиксированные настройки», «пользовательские настройки». Пользователи перестанут биться башкой от стол от заклинаний типа «Невозможно применить фиксированные настройки. Пересекаются элементы отбора»…

верю-верю
Где-то читал, почему так получилось с настройками, но не помню, что и как. А вообще, изначально СКД, вроде как, придумал один человек, и чем он руководствовался, когда сделал такой дизайн — неизвестно :))
ок.

а разработчики зупа что употребляют?

почему отчет о выявлении проблем между состоянием сотрудников и штатным расписанием после внесения изменений пишет «Требуется проверка...»

КАКАЯ?? ЧЕГО?? КАК ЕЕ ЗАПУСТИТЬ?? или она уже была запущена и ошибки остались?

оказывается надо зайти в настройки администрирования и либо изменить шедуллер по задаче которая этот отчет запускает (стоит 1 раз в день!) либо просто запустить руками

рукалицо просто…

вот как пользователь саппортер должен про это узнать?! КАК?!

ни надписи поясняющей, ни гиперссылки на переход в настройки, ничего…

ну я понимаю что 1с не аппле, но головой то надо хоть чуть-чуть думать?!

и вот так практически ВЕЗДЕ
А ЗУП вообще рептилоиды пишут, судя по всему, большинство 1С-ников предпочитают ЗУП издалека палочкой переворачивать :))
Ими не то что нельзя (клиентские действия тоже есть), ими просто не надо управлять. Тут постоянно повторяют, что 1С платформа для решения бизнес-задач, а не для технарей, которые хотят управлять всем. Про ЭСЧФ и остальное вы из контекста вырвали. Ну и вы с УТ 11 про «это не нужно» тот же прием используете, в УТ11 сделали не так потому что «так не нужно».


ниже есть пример.
Поясню еще раз: бизнес -задачи не сводятся к заполнению товарной накладной или пробитию чека — с этим фронт справляется на ура…
та же УТ11 она не для автоматизации FMCG предназначена — сравнивать ее с вашим решением как минимум не умно… разные весовые категории (не в пользу вашего решения) и разное назначение.

по поводу бизнес-задач: когда задача бизнеса сводится не к продажи товара со склада а например к расчету изделия через специализированную форму и в этой форме более двух реквизитов, а предполагается работа в облаке, на тонких клиентах и вебе — то управление серверными вызовами весьма востребованно… и это платформа это обеспечивает — как раз эволюционно дойдя до этого посредством постепенного развития и приобщаясь к современным потребностям…

по поводу «УТ11 сделали не так потому что «так не нужно».» — будьте последовательными и честным, речь шла про организацию подбора номенклатуры деревом с двойной компановкой формы — дерево слева содержимое справа. Вам, или вашим коллегам, показали скриншоты как это было ШТАТНОЙ формой в старых конфигурациях и объяснили почему от такой формы организации сознательно отказались в УТ11. причем не потому что «платформа не позволяет» а потому что методологически в концепции работы в тонких и прочие веб клиентах удобнее делать несколько по-другому…
Поясню еще раз: бизнес -задачи не сводятся к заполнению товарной накладной или пробитию чека — с этим фронт справляется на ура…

Основные бизнес-задачи, это работа с данными, ограничениями, событиями и формами. Все эти «тонкие настройки» бизнесу нужны даже не во вторую очередь.
работы в тонких и прочие веб клиентах удобнее делать

Эта вещь которая разработчика должна волновать в последнюю очередь. Это проблемы платформы.
Эта вещь которая разработчика должна волновать в последнюю очередь. Это проблемы платформы.


ну если у разработчика не будет инструментария — как платформа догадается каким образом фильтровать справочник товаров и материалов?

monosnap.com/file/ORhXPM24Lg4tmcFPob8Qs92cTY12XJ

вы же наличие инструментария ставите как МИНУС платформы одновременно соглашаясь что подобный кейс реализовать не способны на своей платформе…
как платформа догадается каким образом фильтровать справочник товаров и материалов?

Магия например (читайте CONSTRAINT CHECKED BY). Ну или можете форму любую задать, которую хотите:
ON CHANGE
DIALOG myForm OBJECTS myObject = stock(i) CHANGE;
И в форме любой фильтр.
я предоставил видеоролик как это я реализовал в 1С…
можете подобный пример предоставить в lsFusion?

ввод по строке, автоподбор по вхождению с фильтром на варианты автоподбора по заданным параметрам?

UFO just landed and posted this here
isFusion не позволяет на уровне разработчика определять контекст вызова — клиентский, серверный, контекстный или неконтекстный.

на мисте было долгое обсуждение с примерами и представители isFusion это признали

кратко: при реализации логики чуть сложнее торговли в розницу штучным товаром, если у вас есть форма где много реквизитов, элементов и реализован некий расчет — например форма-калькулятор изделия, у вас платформа isFusion будет делать серверный вызов при каждом изменении каждого реквизита и автоматически решать что слать обратно на клиента — может 1 реквизит и тогда накладные расходы невелики а может и все реквизиты формы. Разработчик не управляет тем что просчитывается на клиенте а для чего нужен серверный вызов.

ну и по мелочи — например нет события изменения части текста в поле ввода — простейшая задача контекстного подбора при вводе данных с фильтром результатов поиска — нереализуема и требует костылей в виде открытия форм с наложением фильтров на столбцы… и так куда не ткнись…

Коллеги из lsFusion пишут про избыточность событий в платформе 1С, но эти «события» родились там не просто так — это востребованные события и под каждый есть свой кейс.

Пример: событие автопобора в строке которое можно перехватить при изменении в форме элемента без окончания редактирования элемента.
Коллеги из lsFusion объявили что этого нет и это не нужно.
Но для бизнеса это нужно, если у вас бизнес чуть сложнее чем подбор из формы товаров для продажи.
Пример:

monosnap.com/file/ORhXPM24Lg4tmcFPob8Qs92cTY12XJ

Ввод по строке — срабатывает во первых поиск по справочнику из 100500 элементов номенклатуры, а затем на него откладывается отбор по трем параметрам отображая только те материалы которые можно использовать в данном расчете и соответственно.

Как данная задача решается в lsFusion?
В текущих конфигурациях этой ERP такой задачи не стоит — потому что это не ERP а автоматизация торговых точек… но если бы такая задача стояла, коллеги предлагают открывать форму с оборами по маске…

И таких мелочей, повторюсь — куда не ткни.

И это не обсуждая такие платформенные сущности как взаимодействие — когда средствами платформы с нулем строчек кода у вас есть видеочат с конференцией на 9 человек, аудио звонки, текстовый КОНТЕКСТНЫЙ чат с привязкой к объектам системы и вложенными файлами.
ps: коллеги из lsFusion ничего умнее не предложили чем вайбер или телеграмм…
обратно на клиента — может 1 реквизит и тогда накладные расходы невелики а может и все реквизиты формы

Нет. Она будет слать ровно то что изменилось.
Ввод по строке — срабатывает во первых поиск по справочнику из 100500 элементов номенклатуры, а затем на него откладывается отбор по трем параметрам отображая только те материалы которые можно использовать в данном расчете и соответственно.

Ну в lsFusion для этого отдельная форма открывается, где можно например дополнительно фильтровать. И это часто эргономичнее выпадающего списка.

Но вообще еще раз, статья не про lsFusion. Статья про 1С. Про lsFusion будет отдельная статья.
Нет. Она будет слать ровно то что изменилось.

а если мне НЕ НАДО изменять?
грубо говоря: у меня есть 20 реквизитов на форме и я последовательно меняю кажды из них — сколько будет запросов на сервер а сколько обратно?

Ну в lsFusion для этого отдельная форма открывается, где можно например дополнительно фильтровать. И это часто эргономичнее выпадающего списка.


так и про то что вы пишете про избыточные события не понимая что они на бизнес-процессы завязаны и реализованы не просто так. разработчики платформы все эти, по вашему избыточные, события не просто так придумали от того что им делать не чего было — платформа более 10 лет развивается и с оглядкой на миллионы пользователей…

простейший пример с формой выбора материала я вам привел.
и это всяко эргономичнее, быстрее, проще и удобнее чем открывать форм с деревом номенклатуры и в ней через маски/отборы искать…
так кстат было раньше в старых версиях платформы, в решения на 7.7 например.
но время не стоит на месте и при работе в веб-браузере на планшете открывать лишние формы с деревьями — очень неудобно, долго и неэргономично…
а если мне НЕ НАДО изменять?
грубо говоря: у меня есть 20 реквизитов на форме и я последовательно меняю кажды из них — сколько будет запросов на сервер а сколько обратно?

Еще раз, если на форме есть реквизиты зависящие от изменяемого реквизита, то запрос в любом случае надо делать. Так как если вы остановите ввод на 15 реквизите и форма не обновится это будет воспринято как баг. И еще раз, в данном случае, это чистая экономия на спичках.
но время не стоит на месте и при работе в веб-браузере на планшете открывать лишние формы с деревьями — очень неудобно, долго и неэргономично…

И это говорят люди, у которых в списке нельзя редактировать, и они говорят что для изменений надо открывать форму (почитайте обсуждения в статье про подбор).
Еще раз, если на форме есть реквизиты зависящие от изменяемого реквизита, то запрос в любом случае надо делать. Так как если вы остановите ввод на 15 реквизите и форма не обновится это будет воспринято как баг. И еще раз, в данном случае, это чистая экономия на спичках.


признайте, вы ничего кроме торговли не автоматизировали?

ну еще раз, вот пример расчета стоимости изделия:

image

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

в вашей концепции при изменении каждого параметра — ширина, длина и тд (они же влияют на расчет) будет идти каждый раз серверный вызов…

и где тут «преимущество»?

причем заметьте — я могу так же не парясь все фигачить каждый раз с серверным вызовом как у вас (что я и делаю в простых ненагруженных формах и сценариях) — но в данном примере я явно управляю оными…

зачем мне при изменении каждого параметра пересчитывать стоимость на сервере если я могу это посчитать во первых на клиенте

А почему не посчитать на сервере. А главное непонятно зачем. Вы бизнес-задачу решаете.
в вашей концепции при изменении каждого параметра — ширина, длина и тд (они же влияют на расчет) будет идти каждый раз серверный вызов…
и где тут «преимущество»?

Тем что вам не надо думать. А работать все равно будет очень быстро.
причем заметьте — я могу так же не парясь все фигачить каждый раз с серверным вызовом как у вас

Нет у вас ВСЕГДА надо напрягаться и делить все на сервер и клиент. А в lsFusion не надо. Как и в SAP.
Тем что вам не надо думать. А работать все равно будет очень быстро.


вы модель не понимаете…

1с сначала создает проблемув том, что отвратительно работает сериализация гоняющая данные между клиентом и сервером или общей масштабируемостью решений — когда общая кривая это не логарифм (как все мечтают), а экспонента — т.е. чтобы вы не делали всё встает колом

а потом дает «инструмент»… «для решения». сами проблему создали, сами принесли миру избавление — не забыв сшибить за это денежку…

и вновь продолжается бой! и люди контуженные скд на оба полушария с радостным воем устремляются вновь на баррикады
логику включите:

рассмотрим не 1С а некую клиент-серверну систему в вакууме на тонком канале между клиентом и сервером:

1. вариант — каждое изменение формы из 100 реквизитов вызывает изменение и серверный вызов… пока заполнили 100 реквизитов сделали 100 серверных вызовов

2. вариант — изменения каждого из 100 реквизитов обрабатываются на клиенте и только по достижении минимально необходимого количества данных для расчета отправляются на сервер — делается 1 серверный вызов.

где нагрузка будет на канал и сервер выше?
Я думаю так, надо сделать эти 2 решения на 1С (с ручным управлением распределением задачи: что на клиенте делать, что на сервере), и на lsFusion (где будет решаться только бизнес-задача, а не ломать голову что и когда куда послать, чтобы ничего не поломалось). И тогда замерить объёмы передаваемых между уровнями системы данных, время затраченное на написание, объём написанного вручную кода — вот тогда можно будет судить кто лучше. Хотя даже тогда наверное стороны не придут к согласию, но по крайней мере нейтральной стороне можно будет сделать какой-то вывод…
я просил примеров сложных форм с сложными расчетами — их нет пока в lsFusion по этому все дискуссии сугубо теоретические…

а в теории в любом случае 1 серверный вызов лучше чем 100 серверных вызовов…
А почему не посчитать на сервере. А главное непонятно зачем. Вы бизнес-задачу решаете.


потому что 1 серверный вызов всегда проще легче чем 100 серверных вызовов…
а когда у вас 100 клиентов сидит и считает то 100 вызовов всяко менее нагружают систему чем 10000 вызовов…
зачем мне при изменении каждого параметра пересчитывать стоимость на сервере если я могу это посчитать во первых на клиенте


А почему не посчитать на сервере. А главное непонятно зачем. Вы бизнес-задачу решаете.


Это и удобнее пользователям — быстрее отклик в удаленных системах.
И ниже нагрузка на сервер в нагруженных системах — простым и естественным путем достигается.

ну и последнее:

разработчики lsFusion — будьте последовательными.
Сравниваете платформы -сравнивайте платформы.
Сравниваете отраслевые решения — сравнивайте отраслевые решения.

Ваша статья реально выглядит весьма убогой и смешной, наивной даже — для любого разработчика 1С…
Ну так ответьте по пунктам, что не так. И тут в комментариях, если вы не заметили, много опытных разработчиков 1С отметилось, которые в целом согласились со всеми пунктами.
неужели все эти опытные разработчики не в курсе что весь мир уходит от модальных вызовов?

вы же отказ от модальности, асинхронность преподносите как НЕДОСТАТОК… серьезно??

на минутку, 2014 год… 5 лет назад:

blog.chromium.org/2014/07/disabling-showmodaldialog.html
bugzilla.mozilla.org/show_bug.cgi?id=981796

реализация асинхронности «от 1с» — это нечто выдающееся? рыыыыли?

это настолько убогое изложение устаревшей модели APM из C#, помноженное на традиционное «доступно и всерьез» — а тут люди им как флагом размахивают…

мдя
вы статью топикстартера почитайте.
там речь идет о том что АСИНХРОННОСТЬ ВООБЩЕ НЕНУЖНА И АСИНХРОННОСТЬ ЭТО ПЛОХО

как ее реализует 1С это другой вопрос, речь про концепт статьи — типа 1С сделала плохо отказавшись от синхронности…

налицо полное непонимание автором статьи трендов развития технологий… куда мир и прочие гугли катятся…
У вас все нормально с логикой? В статье нигде не говорится, что асинхронность плохо, а что синхронность тоже нужна. То есть чтобы был выбор и синхронно и асинхронно. 1С сейчас позволяет только асинхронно открыть (речь ессно про тонкий и веб клиенты).
в статье под названием «почему не 1С» и вводной «мы щас поясним почему 1С плохая» — глава называется «отказ от синхронности».

И? Отказ от синхронности плохо != асинхронность — плохо. То есть нужно и то и то.
Посмотрите на дарт или котлин и как там асинхронность реализуется. Подозреваю в других современных языках вроде похоже, просто эти два из тех про которые точно знаю, а не примерно.
вопрос не в том КАК а вопрос в самом принципе наличия асинхронности…

вы статью автора читали?
он же загоняет как раз на то что «1с ушла от синхронности это плохо это минус а у нас синхроность и нет асинхронности это хорошо по этому мы лучше 1С»
Даже перечитал, думаю вдруг неправильно запомнил, нет, в статье написано ровно то что я выше написал. Вместо того чтобы сделать по человечески как в разных современных платформах и языках — мучаться с асинхронностью заставили разработчика.
Что же они сделали? Думаете, попытались сохранить состояние потока выполнения, передать выполнение новому потоку, а по его завершению автоматически восстановить старое состояние? Как бы не так, делать что-то автоматически это, похоже, не их стиль. В 1С опять-таки решили все переложить на разработчика.

З.Ы. Как это сделано у них я честно говоря вообще не нашел (да и не искал, мы здесь все таки 1с обсуждаем, а не lsFusion)
Автор прямо пишет в качестве минусов «почему не 1С» заголовок «отказ от синхронности»

То есть автор солгал в статье?
Нет, потому что 1с отказались от синхронности с т.з. программиста. В котлине и дарте с т.з. программиста асинхронный код может выглядеть точно так же как синхронный. В 1с же это, увы, не так.
в 1с не бояре. переживут без async/await

кто вам сказал что нет аналогов async/await?
ну порадуйте…

НачатьВызов(ОписаниеОповещения, Параметры) и т.п. это не полноценный аналог
какая практическая задача не решается средствами 1С а решается каноничными async/await?
Удобство написания и чтения кода?
Удобство написания и чтения кода?


не боярам 1С этого не надо…

они жрут все что им валят в корыто
вопрос привычки…
для меня например JS неудобен и непонятен…
Для меня тоже, но по причине того что я его не изучал и из за динамической типизации. Даже с прототипным наследованием в принципе готов смириться.
Тем не менее если бы вам в 1с добавили. Результат = ОткрытьФорму(...).ЖдатьАсинхронно() — и это было бы асинхронно с т.з. пользователей и браузера вам бы тоже было неудобно?
у меня есть в 1С допустим есть конструкция

&НаКлиенте
Процедура ОбработкаОповещения(ИмяСобытия, Параметр, Источник)


и мне это кажется удобным…
и я решаю все задачи но таким образом.

и с точки зрения конечного заказчика — бизнеса — какая разница?
Потому что я не бизнес, я программист. И мне нужно удобство. А какое это удобство когда куски бизнес логики отделены друг от друга не по причине разных уровней абстракции или разных задач, а по причине технических ограничений?

Это вот типичный пример подмены. Сначала говорите, что есть аналоги, а потом спрашиваете, какая задача не решается. Так вот, для решения задачи аналоги не нужны, задачу можно и так решить. Просто если бы они были, было бы намного проще.


Собственно, и C#-то без async/await жил долгое время, и все равно имел асинхронию, просто когда ты на эти самые async/await переходишь, становится понятно, насколько же неудобно было писать код до этого.

сие 1с-никам с отбитым мозгом увы не объяснить…
Собственно, вы правы. Асинхронность в текущем языке… так себе (мягко говоря).
так мало того… есть гибкая типизация и наличие отсутствия делегатов. п.э. что передается в качестве «указателя»? текстовое название функции куда должен вернуться результат события

а потом еще чпокаться с со словарями параметров и результатом — что там внутри, что туда положили…

тут зрители аплодируют, аплодируют… кончили аплодировать (с)
Вы что сказать-то этим хотели?
Я думаю то, что передача идентификаторов в виде строк не есть хорошо. И вообще исходный код в любом виде в виде строк (будь то SQL или др.), вшитый в код программы, это плохо. Он не проверяется компилятором, для него не работает автодополнение, нельзя подвести мышку и посмотреть определение (в Design time) или значение (в Run time), если идентификатор в коде в виде строки.
А я разве это отрицаю? Изначально (двумя постами выше) я вполне осмысленно и осознанно написал, что асинхронность в 1с сделана не очень хорошо.
Собственно все. Если 1с исправит положение вещей — все порадуются. Не исправит — будем пользовать то, что есть.
никакой подмены. не выдумывайте.

1С умеет то что умеет async/await и спрашиваю — может будет какой пример который я не могу решить своими методами? Может я просто не в курсе а сообщество труъкодеров мне раскроет глаза?

чисто спортивный интерес — понять что я не могу сделать в платформе 1С того что вы делаете async/await…
1С умеет то что умеет async/await

Умеет? Ну то есть можно написать вот так:


результат = магическое-слово асинхронная-задача(параметры)
обработать(результат)

И платформа отпустит этот поток до тех пор, пока работает асинхронная задача, а потом вернется, полностью восстановит контекст выполнения и пойдет дальше?


Ну и заодно:


результаты = магическое-слово выполнить-параллельно(список-десяти-задач)

А так?

конечно…
другие магические слова но конечно 1С это может…

+ никто не мешает запустить процесс из одного контекста а результат получить в другой… или в третий и четвертый одновременно…

собственно это и «ваялось» как инструменты для решения бизнес-задач…
Сохраняя стек вызовов и контекст? Возвращаясь в ту же процедуру в точку вызова? Я конечно последний год не сильно за 1с слежу, но думаю такое изменение встроенного языка я бы не пропустил.
как я как разработчик решу так и будет:

можно вернутся в тот же контекст, а можно например в другую форму и в другой контекст результаты отправить.

в общем то никто не запрещает.
клиентская процедура получающая результат:

&НаКлиенте
Процедура ОбработкаОповещения(ИмяСобытия, Параметр, Источник)


возврат в ту же точку вызова?
а в чем практический пример возврата в точку вызова если у вас дительный расчет?

ну вот у вас идет код:

результат = магическоесловокоторосчитаетцифру();
результат2=результат+1;

магическоесловокоторосчитаетцифру() возвращает допустим 3, как у вас сработает эта процедура?

клиент нажал кнопочку… процедура дошла до первой строки и далее она ждет ответа?
или она сразу переходит на вторую строку и что тогда пишет в результат2?

а когда возвращается событие оно снова пишет в первую строку значение 3 а затем считает строку 2 и значение результат2?

поясните практическую суть возврата «в ту же точку»

как у вас сработает эта процедура?

Я боюсь, что если вы этого не понимаете, вы не понимаете и как/зачем работает async/await. А, следовательно, вряд ли можете говорить, что 1С такое может.

я же именно по этому просил практический пример…
чтобы на практическом примере понять — может или нет.

из того что у меня тут спросили и из того что я бегло почитал про async/await — я не вижу сценариев которые не может 1С…

но и справедливо же обратное утверждение — вы почему то решили что раз в 1С нет напрямую async/await — то значит 1С не может покрыть функциональность этих самых async/await своими методами… но вы же не знаете методов 1С и ее возможностей, так же как авторы статьи — по этому мы тут и ведем диалог…

был бы конкретный пример типа как я выше написал с расчетом — было бы понятнее и мне и вам.
Я с 1с работал 4 года. Уже почти год работаю с котлином, и месяц игрался с дартом по вечерам. Прекрасно могу смотреть на это все с обоих сторон.
я же именно по этому просил практический пример…
чтобы на практическом примере понять — может или нет.

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


try
{
  using(TraceSegment())
 {
    var files = await paths.ForEach(DownloadFileAsync)
    await SendMailAsync(to, files);
  }
}
catch(Exception e)
{
  //some handling
}

Вот вам очень простой пример. На входе есть несколько путей, дальше по этим путям — асинхронно и в параллель — скачиваются файлы, когда все файлы успешно скачались, отправляется емейл. Обработка ошибок общая, контекст выполнения (из которого делается, например, трассировка) — общий.

ээээ

обычная вполне задача…
я так к макетам картинки прикрепляю у себя.
фоном файл скачивается, сжимается, делается превьюха, загружается в 1С (причем понимая где ему на сервер качать и на сервере конвертировать а где на клиенте конвертировать) и затем уже форма из которой пользователь это запустил оповещается что хоба — а у вас превью макета появилось, извольте полюбоваться…

причем могу так несколько обработок в параллель пустить… одной кнопкой… а затем обработать все сразу или по очереди или по определенной нужной мне логике…

обычная вполне задача…

Прекрасно. Код покажите.

Я так понимаю, кода не будет. Показательно.

ну вы же программист и понимаете что если у меня есть сборщик событий вида:

&НаКлиенте
Процедура ОбработкаОповещения(ИмяСобытия, Параметр, Источник)


то я в нем могу идентифицировать событие по имени, источнику и получить входящие параметры в которые фоновое задание может мне положить что угодно — от ссылки на прикрепленный файл до двоичных данных картинки файла…

и далее я в коде делают то что мне нужно по бизнеспроцессу…

в этом то и тонкость что для реализации подобных задач не нужно вообще ничего сверх типового функционала платформы 1С8…
ну вы же программист и понимаете

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

код БСП по работе с вложенными файлами присылать?
все процедуры интересуют и все модули?

Нет, показать тот код, который функционально эквивалентен приведенному мной.

Если не пользовать стандартную БСП и ее длительные операции то параллельный запуск в фоновые задания в параллель любого количества вызовов — ну вот например так можно сделать:

&НаКлиенте
Процедура КачнутьНесколькоФайлов(Команда)
запуститьНаСервере();
	
ПодключитьОбработчикОжидания("ПроверитьЗадания",2,Истина);	
	
	
КонецПроцедуры

&НаСервере
Процедура ЗапуститьНаСервере()
		
	Для сч=1 по 4 Цикл //просто генерю для обработки -тут можно читатьс содержимое каталога, список ссылок и тд.. 
		имяф= "файл_нумер_"+сч;
		уид = "Загрузка_" + имяф;
		
		ПараметрыВызова = Новый Массив;
		ПараметрыВызова.Добавить(имяф);
		ЗаданиеВыгрузки = ФоновыеЗадания.Выполнить("МодулиФоновыхЗаданий.ПроизвестиДлительноеВычисление", ПараметрыВызова, Уид, "кач кач");
		массивУид.Добавить(ЗаданиеВыгрузки);
	КонеццИКла;
КонецПроцедуры

&НаКлиенте
Функция ПроверитьЗадания() Экспорт
	Если ЗаданияЗавершены() Тогда
ПодключитьОбработчикОжидания("ПроверитьЗадания",2,Истина);	
	иначе
		//отправим емейл
	КонецЕсли;
	
КонецФункции

&НаСервере
Функция ЗаданияЗавершены()
	
	шлеммыл =истина;
	для каждого текУИД из массивУид цикл
	Зад=		ФоновыеЗадания.НайтиПоУникальномуИдентификатору(текУИД);
	если  Зад.Состояние = СостояниеФоновогоЗадания.Активно  тогда
		шлеммыл = ложь;
		прервать;
	КонецЕсли;
	 КонецЦикла;
	 
	 Возврат шлеммыл;
	 
 КонецФункции



по сути код из обработки которая кнопкой отправляте в фон 4 процесса каждый из которых обрабатывает ссылку а по результатам выполняется функция в которой можно емейл отправить например.

не очень лаконично и красиво если визуально сравнивать с вашим кодом — но работает…

т.к. платформа ПРИКЛАДНАЯ — то для решения типовых для учетных систем задач есть более удобные инструменты — всякие начатьпомещениефайла или начатьпомещениефайлов и прочие асинхронные готовые конструкции…

Вы понимаете что что то не так «в датском королевстве» когда в прикладной выскоуровневой платформе для банальных задач нужно писать гору не самого удобного кода?
И нет, этот код не эквивалентен так как стек вызовов к сожалению теряется (зачем нужно его сохранение я уже даже не вижу смысла дергаться пояснять, у вас опять все сведется к тому что это не нужно и можно написать гору другого кода чтобы пользователь в итоге видел ровно то же).

UPD
Ах да, перечитал код — в нем еще больше проблем. Нет возврата результата выполнения фоновых заданий (успеха или ошибки, ссылок на файлы).
Ну и лучше под спойлер такой объем спрятать.
я просто не стал анализ ошибок результатов и прочее -выводить… платформа то может — я в примере не стал.

по поводу громодкости кода… ну в этом участке да — 1С просит написать кучу строк…

а давайте будем организовывать видео и аудио чат, контекстные чаты внутри системы, неконтекстные чаты, обмен файлами и видеоконференции на 9 человек?

в 1С платформе 0 (ноль) строчек кода:

wonderland.v8.1c.ru/blog/sistema-vzaimodeystviya

а сколько строчек кода вы у себя напишите для реализации всего этого и интеграции в свою ERP?
Вы понимаете что мы говорим не о разработке конечной пользовательской функциональности а об удобстве разработчика? async/await можно использовать в тысячах случаев в рамках одной конфигурации для упрощения написания и чтения кода. И ни в какое сравнение с пользовательской функциональностью это не идет. Ну и да, вы немного пропустили — все равно у вас стек не сохраняется, что достаточно важно бывает для удобной разработки. Ну и глупо сравнивать возможности фреймворка и языка. Мы говорим именно о языке в данном случае. Вы снова скатываетесь в «это не нужно», «зато в 1с можно другое двумя кликами», вместо того чтобы признать что у языка есть проблема которую 1с могли бы решить но не решают.
удобство разработчика это же вкусовщина чистой воды…

мне например удобно на русском языке программировать — ни один ваш «серьезный» язык в этом плане мне не предоставит того удобства которое предоставляет 1С…

вообще никак… никакими костылями и внешними сервисами…

но мы же эту сторону удобства разработчика не обсуждаем?

ps: в 1С платформе полно проблем которые не решают или решают медленно… какие то вещи решают «по своему» или не до конца — как например асинхронные вызовы — вроде есть а можно было бы удобнее… а какие то не решают со всем…
но платформа развивается — уже сейчас она может почти все в той сфере для которой ее создали… и она становится лучше с каждым разом… глядишь и сделают асинхронность в одну строку как во взрослых языках :)
но мы же эту сторону удобства разработчика не обсуждаем?

Очевидно потому что мы в этой статье и комментариях обсуждаем минусы а не плюсы 1с? Двуязычный синтаксис минусом можно назвать только с той точки зрения что это мешает экспансии за бугор, в остальном для СНГ скорее плюс. Ну вот «когда сделают — тогда и приходите». Но не сделают, я за все 4 года работы с 1с ни разу не помню чтобы развивали язык а не платформу или бсп.
вода камень точит — постепенно что то меняют…
но опять же — большинство, подавляющее большинство учетных задач решается 1Сом из коробки… как бы вы не сравнивали 1С с более универсальными системами/языками, но финтифлюшка в виде видеочата в платформе пользователям конечным много востребованнее чем возможность программисту написать что то не в 20 строк кода а в одну…
Да пожалуйста. Я для себя выбор сделал, в темах затрагивающих 1с спорю больше по привычке и чтобы раскрыть глаза другим людям.
финтифлюшка в виде видеочата в платформе пользователям конечным много востребованнее

Или нет, если у них ERP прозрачно интегрирована с Office 365, в котором они уже пользуются видеочатами безо всякой ERP.

или да если им нельзя по требованиям безопасности данные контекстных обсуждений и прочие аудио и видео переговоры отправлять на внешний сервер где офис 365 крутится…

Всякое бывает, чего уж там. Но у таких пользователей обычно, опять же, часто есть своя внутренняя система.

взаимодействия которые в платформе 1С — это как раз эта самая внутренняя система тесно интегрированная с объектами учета ERP — то есть это не внешний чатик а контекстная привязка — отдельная подсистема в любой учетной системе 1С… сравнивать ее с телеграммом, вайбером и прочими офисами 365 — не очень корректно…
сравнивать ее с телеграммом, вайбером и прочими офисами 365 — не очень корректно…

А надо, потому что это конкурирующая функциональность.

ну… вы свой сервер для телеги не поставите дабы вопросы безопасности закрыть и контекстно не свяжите каналы телеграмма с объектами базы в интерфейсе своей ERP…

Для телеги — нет. А вот для некоторых других мессенджеров — и поставлю, и свяжу.

но вам придется программировать и писать строчки кода…
и все равно будут ограничения — мало на рынке есть свободных систем позволяющих прозрачно интегрировать чат с видеозвонками, обменом файлами, видео и аудиоконференциями и привязкой каналов к объетам ERP да еще и «забесплатно»…

ну или миллион строк кода и своя вундервафля…
но вам придется программировать и писать строчки кода

Ну да, это моя любимая работа — программировать и писать строчки кода. Точно так же, как, я надеюсь, у тех людей, которые написали эту функциональность в 1С.

ну… с одной стороны вы против лишних строчек кода для не очень востребованной в учетных системах async/await — и лишняя строчка кода прям плохоплохо…

а с другой стороны вы готовы писать миллион строк кода для реализации задач которые в той же 1С идут тупо из коробки…

:)
для не очень востребованной в учетных системах async/await

Это оно у вас не востребовано.


лишняя строчка кода прям плохоплохо…

Плохо не лишняя строчка кода. Плохо непонимание, что в этом коде не так.


а с другой стороны вы готовы писать миллион строк кода для реализации задач которые в той же 1С идут тупо из коробки

Ну, если есть клиент, который готов мне за это платить — то почему нет? Я не вижу смысла выбирать 1С только за то, что в ней есть не очень востребованная в учетной системе видеоконференцсвязь, когда у меня есть разумные альтернативы.

Это оно у вас не востребовано.


опять возвращаемся к задачам которые НЕЛЬЗЯ решить средствами 1С?

Плохо не лишняя строчка кода. Плохо непонимание, что в этом коде не так.


не очень понятная фраза — вы как разработчик не понимаете что в вашем коде не так?

Ну, если есть клиент, который готов мне за это платить — то почему нет? Я не вижу смысла выбирать 1С только за то, что в ней есть не очень востребованная в учетной системе видеоконференцсвязь, когда у меня есть разумные альтернативы


это пример того что в одном месте вы сэкономите 10, 20, 30 строчек кода на реализации асинхронности через async/await -а в другом месте того же самого проекта напишите на миллион строк кода больше т.к. вам надо с нуля писать существующие в 1С готовые инструменты…

а так да — если мне заказчик платит за асинхронность и ему пофиг на async/await — то какая разница то?
опять возвращаемся к задачам

Нет, опять возвращаемся к тому, что у систем вообще разные задачи бывают.


вы как разработчик не понимаете что в вашем коде не так?

Конечно, не всегда понимаю, иначе бы в коде не было ошибок, а они там есть. Но в данном случае — вы не понимаете, что не так в вашем коде по сравнению с моим.


а в другом месте того же самого проекта напишите на миллион строк кода больше т.к. вам надо с нуля писать существующие в 1С готовые инструменты…

Или не надо. Вы же не знаете, какие инструменты есть в прикладной платформе, которую я возьму для решения нужной задачи. Я ведь не зря написал про разумные альтернативы.


какая разница то?

Вам, видимо, никакой. А я предпочитаю элегантный код.

удобство разработчика это же вкусовщина чистой воды

Не совсем. Это, в итоге, влияет на скорость (и качество) разработки — а это уже важный для покупателя фактор.


но мы же эту сторону удобства разработчика не обсуждаем?

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


А теперь давайте сравним долю систем с требованиями "на английском" и "на русском", и задумаемся.

EDT от 1С (не конфигуратор а та, что ваяют внешнюю разработчики платформы, там где гит и прочие эклипсы ) — свободно переводит код — там плагин есть который тебе код переведет на английский или на китайский или на чем ты там кодишь…

там плагин есть который тебе код переведет на английский или на китайский

Верится с большим трудом. Ну то есть, как, "переведет", да. Но читаемость этого будет отвратительной.

переведет не промтом… в языке все процедуры и функции имеют двойной синтаксис… я могу половину кода на русском писать половину на английском в одном и том же модуле…
плагин соответственно гоняет туда/сюда способ отражение кода…

Вы забыли про все названия, которые пишет сам программист. Их кто и как переведет?

а это уже от программиста зависит и от того придерживается он стандартов или нет…

вы с задачей определитесь… «кодить на английском чтобы делать портируемые интернациональны решения» — это одна задача… «перевести весь код самописки чисто поржать» — другая…

например разработчики БСП 100% выпустят национальные англоязычные библиотеки — и будьте уверены процедур как в моих примерах «отправитьнамыло» у них не будет в названиях :)

а это уже от программиста зависит и от того придерживается он стандартов или нет…

Так переводить-то кто будет?


«кодить на английском чтобы делать портируемые интернациональны решения» — это одна задача…

И это именно та задача, которая передо мной стоит.

Так переводить-то кто будет?


плагин к ЕДТ

И это именно та задача, которая передо мной стоит.


Вы это можете делать прямо сейчас без всяких плагинов — пишите на 1С полностью на английском… никто вам не мешает — и у вас будет вся та же функциональность что и у меня…
плагин к ЕДТ

И как же он это будет делать? Не компьютерным переводчиком?


пишите на 1С полностью на английском…

Я, однако, могу писать на английском и на других языках программирования. Я потому и говорю, что мне русскоязычность 1С побоку.

И как же он это будет делать? Не компьютерным переводчиком?


процедуры функции и всякие языковые конструкции — через замену т.к. в платформе мультиязычность есть как таковая… переменные пользователей — не знаю… мне не интересно было я не уточнял у разработчиков — посмотрел что анонсировали и болт забил… скорее всего предложат ручками переименовывать процедуры с названиями типа «пыщь» и «сделайбухгалтеруприятно»

корее всего предложат ручками переименовывать процедуры с названиями типа

Ну вот об этом и речь. Нету никакой двуязычной разработки, все равно выбирать надо.


Впрочем, повторюсь, мне не актуально, я изначально с интернациональным кодом работаю.

елки палки.

что в вашем понимание «двуязычность» — сразу именовать одну и туже процедуру на двух языках?

именуйте

Процедура СделатьХорошоMakeGood()

и переменные так же именуйте…

системные термины плагин переведет и будет у вас либо Функция либо Function
что в вашем понимание «двуязычность» — сразу именовать одну и туже процедуру на двух языках?

В моем понимании двуязычность — это когда один и тот же код может без потерь читать и (чисто) русскоязычный, и (чисто) англоязычный разработчики.

а можно пример такого кода?

Я такого кода никогда не видел.

ну так если считать двуязычностью ВОЗМОЖНОСТЬ на одной платформе ПИСАТЬ на двух разных языках, причем одновременно а так же иметь инструменты для перевода КОДА со одног языка на другой — то в 1С как раз и есть эта самая двуязычность…

а уж если программист умеет читать на русском и умеет читать на английском то он одинаково прочтет код в 1С что на русском что на английском…
то в 1С как раз и есть эта самая двуязычность

Выше уже выяснили, что нет.

стоп, вы же сами написали что двуязычность это когда можно прочитать на одном языке и можно прочитать на другом:

и оно полностью ложится в концепцию 1С

вы зная английский и русский можете легко читать модули 1С которые пишутся на английском и на русском — а системе без разницы на каком языке они написаны… причем для удобства и дополнительно появились инструменты для перевода кода…
стоп, вы же сами написали что двуязычность это когда можно прочитать на одном языке и можно прочитать на другом:

Ну вот давайте, чтобы далеко не ходить, возьмем ваш код.


&НаКлиенте
Процедура КачнутьНесколькоФайлов(Команда)
запуститьНаСервере();
    ПодключитьОбработчикОжидания("ПроверитьЗадания",2,Истина);

Как его прочитать человеку, который не знает русского?

Как его прочитать человеку, который не знает русского?


переведите этот код для него на английский… пишите и программируйте на английском сразу или пользуйтесь переводчиком из ЕДТ…
переведите этот код для него на английский…

Это, очевидно, можно сделать для любого кода, и потому бессмысленно.


пишите и программируйте на английском сразу

Тогда это не сможет прочитать человек, который не знает английского.


или пользуйтесь переводчиком из ЕДТ…

Вот мне очень любопытно посмотреть, как он это переведет.

ПодключитьОбработчикОжидания("ПроверитьЗадания",2,Истина);

Вот прежде, чем что-либо другое обсуждать, я одну вещь спрошу: эта инструкция — она когда завершается? Когда обработчик подключен, или когда ожидание завершено? Иными словами, процедура КачнутьНесколькоФайлов завершится когда? Тогда же, когда и мой код, то есть после успешной отправки емейлов, или тогда, когда подразумевает название, после успешной закачки файлов, или когда-то еще?

Могу за автора комментария ответить КачнутьНесколькоФайлов, завершится сразу после запуска загрузки, задолго до ее завершения. ПодключитьОбработчикОжидания все что делает — говорит платформе запустить через 2 секунды ПроверитьЗадания однократно. Все.

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

выше все верно написали…

Ну тогда давайте разбираться.


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


Во-вторых, у вас нет ни общей (а это важно) обработки ошибок, причем не платформенного уровня, а уровня "в этом методе написали используя данные из этого метода", ни того самого трассирующего сегмента, который откроется там, где написано, а закроется, когда код внутри него будет полностью выполнен (либо завершится аварийно), что позволяет, например, легко посчитать время выполнения каждой задачи (и привязать все их логи к одному контексту).


В-третьих, посмотрим на сам код.


ПодключитьОбработчикОжидания("ПроверитьЗадания",2,Истина);

Строковый параметр вместо явного обращения к объекту. 1С это валидирует?


ФоновыеЗадания.Выполнить("МодулиФоновыхЗаданий.ПроизвестиДлительноеВычисление", ПараметрыВызова, Уид, "кач кач")

Опять строковый параметр, и теперь еще и передача параметров в виде массива. Это 1С валидирует?


массивУид.Добавить

А как массивУид передается между ЗапуститьНаСервере и ЗаданияЗавершены?


Если ЗаданияЗавершены() Тогда
ПодключитьОбработчикОжидания("ПроверитьЗадания",2,Истина)

Ну то есть обычный поллинг раз в две секунды. Вместо того, чтобы повеситься на IOCP и ждать, ничего не потребляя.


для каждого текУИД из массивУид цикл
Зад=ФоновыеЗадания.НайтиПоУникальномуИдентификатору(текУИД);

… и раз в две секунды ходим по всем заданиям, проверяя их статус. То есть у вас не то что continuations, у вас даже APM/EAP нет.


И да, у вас нет ни проверки состояний, ни возврата результатов.


В-четвертых, да, неизбежно, сравните количество кода и порожденных объектов. Вам понадобилось четыре процедуры и массив там, где я обошелся одной — и вы все равно не предоставляете ту же функциональность.


Так что нет, 1С не может async/await, даже близко. Фоновые задачи — умеет, только .net их умел с версии не позже 1.1, и даже тогда там уже были честные делегаты. Это 2003 год, если что.

допустим вы правы, хотя есть обработки оповещений которые как раз слушают внешние события и можно извернутся и через них пускать какие то задачи — они как раз этот ваш await, но вопрос: задача то решена?
4 файла в 4 параллельных потока загрузились и по итогу отправился емейл…

вам как конечному пользователю какая разница 4 функции я написал или одну строчку кода?

ведь когда мы будем другую задачу решать, ну например реализовывать контекстные чаты с привязкой к объектам системы ERP — я не напишу ни одной строчки кода я просто их включу — и мне платформа это автоматом зацепит к каждому объекту… а вам придется полгода разрабатывать механизм видеоконференций или прикручивать костыли внешних сервисов… платных скорее всего…

вам как конечному пользователю какая разница 4 функции я написал или одну строчку кода?

Я — не конечный пользователь, я разработчик. И мне есть разница, сколько кода написано.


Да и конечному пользователю — тоже, потому что меньше кода при прочих равных обычно лучше.


задача то решена?

Нет.


ведь когда мы будем другую задачу решать

Когда будем другую задачу решать — о другой задаче поговорим. Пока что вы написали "1С умеет то что умеет async/await", и именно это меня заинтересовало. Как выяснилось, все-таки не умеет.


А другие задачи — ну да, можно сравнивать прикладные платформы по решенным типовым задачам. Где-то 1С выиграет. Где-то проиграет. Но претензий к языку это все равно не отменит.

Когда будем другую задачу решать — о другой задаче поговорим. Пока что вы написали «1С умеет то что умеет async/await», и именно это меня заинтересовало. Как выяснилось, все-таки не умеет.


в чистом виде умеет для произвольного события через обходные пути:
в подситему взаимодействия можно слать программно с сервера любые события, а обработчик сидит и слушает эти события и выполняет код…

то есть можно через механизм платформы организовать «канал чата» с названием типа «события фоновых процессов» и слать туда результаты загрузки, и соответственно онлайн реагировать на появление оных чат-ботом…

это все встроенные возможности платформы…
изначально они конечно делались для как раз чат-бота встроенного :) но их можно пользовать именно для реализации этого вашего async/await в ситуациях когда опрос состояния события раз в секунду «недостаточно онлайн»

Все, что вы описываете — это не async/await. Это обходные пути реализации какой-нибудь асинхронии, но не async/await.


А вы, повторюсь, просто не понимаете, о какой функциональности вообще идет речь, но продолжаете утверждать, что она есть.

если я в нужном мне месте кода вызываю нужное количество асинхронных потоков выполнения нужных мне задач а по результату сразу по получению продолжаю с момента запуска выполнять обработку данных и при этом у меня интерфейс не зависает а пользователь спокойно работает как в этом объекте так и в других — это не оно? какие признаки упустил?

или наличие одной строчки кода — обязательное условие?
какие признаки упустил?

Полное сохранение контекста, обработку ошибок и передачу данных (как параметров, так и результатов), не отличающиеся от вызова синхронного кода.


Проще говоря, правильный async/await — это когда было var file = ReadFile(path), его заменили на var file = await ReadFileAsync(path), больше ничего не меняли (при условии, что внешний метод уже был асинхронным), и все работает как и раньше, с той же логикой и поведением, кроме того, что там, где написано await, поток может быть отпущен на свободу.

Полное сохранение контекста, обработку ошибок и передачу данных (как параметров, так и результатов), не отличающиеся от вызова синхронного кода.


из всего этого конечно «не отличающиеся от вызова синхронного кода» — совсем плохо… остальное да и можно и нетпроблем, но вот именно чтобы код не отличался — нет такого…

то есть в 1С все как всегда: есть ряд методов где асинхронность «из коробки» и код не отличается
это всевозможные диалоги выбора файлов, ввода текста, ответы на вопросы — то есть интерактивщина…

а вот если в целом поставить задачу «хочу произвольную процедуру пустить в асинхрон» — то тут либо всегда ВСЕ расчеты пускать через подсистему «длительныеоперации» и там в вызовах где надо ставить признак «в фоне» а где не надо не ставтиь — и тогда будет код одинаковый, либо жить в мире где вызов асинхрона отличается с точки зрения кода…

я вот подумал — в принципе я могу писать на 1С решения полностью всё пускающие через обертку длительных операций — и тогда у меня будет async/await — но мне это как разработчику неудобно будет… т.к. без обертки проще быстрее и понятнее…
остальное да и можно и нетпроблем

Ну, в вашем коде и остального перечисленного нет. Что, как бы, показывает, насколько "нет проблем".


но мне это как разработчику неудобно будет… т.к. без обертки проще быстрее и понятнее…

Это именно потому, что вам надо делать какие-то обертки, которые делают непонятнее. А в мире async/await таких оберток просто нет, вызов — он и есть вызов, ничего непонятного в нем нету.

Ну, в вашем коде и остального перечисленного нет. Что, как бы, показывает, насколько «нет проблем».


в том коде я просто не обращался и не проверял ни результаты ни читал ошибки — методы и функции позволяют и там для этого конечно же все есть — просто я поленился писать…

Это именно потому, что вам надо делать какие-то обертки, которые делают непонятнее. А в мире async/await таких оберток просто нет, вызов — он и есть вызов, ничего непонятного в нем нету.


ну, вы в своем мире async/await то же поменяли что то в тексте кода что бы система поняла что можно в свободное плавание…

а если бы я вам сразу все примеры 1С писал через обертку подсистемы длительных операций то у вас небыло бы вопроса «зачем вы по другому пишите для асинхрона» :)

в общем вы меня убедили и я признаю: в чистом виде async/await как его ожидают программисты других платформ в 1С нет.

НО

программно реализуется и если очень хочется то можно себе организовать мирок async/await и спокойненько в нем жить, но т.к. учетные задачи не требуют этого async/await никто не запарывается — мне кажется разработчики платформы еще очень не скоро снизойдут до реализации этой красоты в виде «одна строчка кода»… опять же — потому что подавляющее большинство учетных задач решается существующими механизмами… а разработчикам платформы прикольнее пилить плюшки типа автономных мобильных клиентов и прочие демонстрации удаленного рабочего стола средствами платформы через подсистему взаимодействия…

просто я поленился писать…

Вот об этом и речь. Когда что-то писать сложно, это писать не будут (обработка ошибок и логирование — хорошие примеры). А в правильной асинхронной модели обработка ошибок происходит автоматически (в том смысле, что если ты явно не сделал обратного, ошибку ты получишь).


программно реализуется и если очень хочется то можно себе организовать мирок async/await и спокойненько в нем жить

Ну, я посмотрю, сколько вам для этого кода понадобится.


учетные задачи не требуют этого async/await никто не запарывается

Возвращаемся к "просто нам это не надо".

Вот об этом и речь. Когда что-то писать сложно, это писать не будут (обработка ошибок и логирование — хорошие примеры). А в правильной асинхронной модели обработка ошибок происходит автоматически (в том смысле, что если ты явно не сделал обратного, ошибку ты получишь).


задачи такой не стояло… да и у вас я не увидел в коде обработку различных событий незагрузки, отсутствия доступа к файлам и тд…

Возвращаемся к «просто нам это не надо».


там где надо есть подсистема для управления длительными процессами и фоновыми заданиями.

но таки да -в учетных системах многие вещи «нам это не надо» — например прямой доступ в железо подключаемого оборудования — нам это тоже «не надо» — мы драйверами атола пользуемся…
да и у вас я не увидел в коде обработку различных событий незагрузки, отсутствия доступа к файлам и тд…

Это не оно? Вся обработка заключается в паре строк. Причем при желании ее можно делать выше по стеку вызовов, а не непосредственно в месте вызова.
catch(Exception e)
{
  //some handling
}
у фоновых заданий есть состояния — там тоже все прозрачно отслеживается… в коде я просто признак завершенности проверял…
еще раз- просто мне лень было для форумного спора сидеть выводить код обработкой и анализом исключений
но там так же можно написать условие проверяющее что ошибка и далее обработку ошибки…

Об этом и речь: вам надо написать дополнительные условия, вам было лень, и вы их не написали. Я ниже спросил (поторопившись), тут спрошу еще раз: что случится в вашем коде (как он сейчас написан), если при скачивании отдельного файла произойдет ошибка?


Сколько строчек кода надо добавить (и где), чтобы тот код, который вызвал первую процедуру (точку входа), узнал, что процесс не был завершен успешно?

фоновое задание завершится с ошибкой и я смогу прочитать подробную информацию об этой ошибке и соответственно обработать ее…

причем увижу как в модуле программными средствами так и интерактивно в журнале фоновых заданий…

В вашем коде (как он сейчас написан) это есть?

я же уже выше написал — нет.
мне лень было прописывать обработку исключений.

но это не косяк платформы или инструментов а просто моя лень…

Тогда возвращаемся к предыдущим вопросам:


  • что случится в вашем коде (как он сейчас написан), если при скачивании отдельного файла произойдет ошибка?
  • Сколько строчек кода надо добавить (и где), чтобы тот код, который вызвал первую процедуру (точку входа), узнал, что процесс не был завершен успешно?
что случится в вашем коде (как он сейчас написан), если при скачивании отдельного файла произойдет ошибка?


отправится емейл т.к. там идет проверка на активность задание а не на то успешно оно завершилось или нет.

Сколько строчек кода надо добавить (и где), чтобы тот код, который вызвал первую процедуру (точку входа), узнал, что процесс не был завершен успешно?


прверять не активность задания а его завершение

СостояниеФоновогоЗадания.завершено — признак успешного завершения задания (не аварийного и не отмененного)

можно просто как у вас условие добавить

если  Зад.Состояние = СостояниеФоновогоЗадания.ЗавершеноАварийно тогда
		
//понеслась обработка ошибки загрузки файла

	КонецЕсли;


отправится емейл

Ну вот видите. Вам было лень, и у вас (иногда, непредсказуемо) отправляется неправильный емейл, и определить, почему он такой — счастливой отладки. Мне было лень, и у меня вместо красивого сообщения об ошибке будет системное. Чувствуете разницу?


И это именно то, чем плохо 20+ строк кода вместо пяти — тем, что лень писать хорошо. И это именно то, что я имею в виду, когда я говорю, что вы не видите, что в вашем коде плохо.


можно просто как у вас условие добавить

А у меня нет никакого условия. И, что важнее, вам это не поможет — код, вызвавший первую функцию, никак не узнает, что что-то пошло не так.

когда мне лень — у меня тоже системное сообщение вываливается об ошибке…

Вы выше написали, что отправится емейл. А сейчас пишете, что будет системное сообщение об ошибке. И какому из двух вариантов верить?

если напишу код отправляющий емейл — отправится емейл
если напишу код выводящий системное сообщение об ошибке — выведется системное сообщение об ошибке -

Мы говори о коде, который вы уже написали. В нем нет вывода системного сообщения об ошибке. И вообще нет обработки ошибок.

естественно — я его и не писал.
задачи такой не было.

Задача была — сохранить такое же поведение, как у моего кода. А у вас поведение отличается, причем радикально.

сделайте скидку на то что я тупой одинесник и мне ваш код со всеми его тонкостями не очень понятен…
предпринимать усилия и разбирать его досконально я не хочу — ровно потому что мне лень на это тратить время которое мне никто не оплатит — как вы задачу описали и как я «понял» ваш код — так аналог и написал…

Ну вот в том-то и дело, что поняли вы неправильно. А чтобы написать так, как этот код работает, вам понадобится еще больше кода. Что, собственно, и демонстрирует достоинства async/await.

async/await — штука красивая… но в задачах реализуемых на платформе 1С крайне редко востребованная…

в тех местах где именно немодальность и асинхронность вот прям постоянно нужна (диалоги вопросов, предупреждений, работы с файлам и тд) — из коробки сделаны соответствующие методы которые полностью покрывают задачу…

еще раз: 1С прикладная платформа для реализации определенного круга задач… если очень надо — реализую async/await не так красиво как «по классике» и большим количеством кода — но пользователю один фиг — у него работает как надо…

мне же, как разработчику вообще параллельно — у меня более интересные задачи есть чем уменьшать количество строк кода чисто для того чтобы уменьшить количество строк кода… я кодом не любуюсь, мне за любование кодом не платят :)
но в задачах реализуемых на платформе 1С крайне редко востребованная…

Ну, про "задачи реализуемые на платформе 1С" — ничего не знаю. В задачах современных ERP — весьма востребованная.


в тех местах где именно немодальность и асинхронность вот прям постоянно нужна (диалоги вопросов, предупреждений, работы с файлам и тд)

Судя по этому списку, вы продолжаете не понимать, для чего нужен async/await.


из коробки сделаны соответствующие методы которые полностью покрывают задачу…

Ну вот допустим. Если мне надо из кода в 1С записать файла на диск — ну вот тупо и банально, я сформировал какой-то там текст или что-то, и мне его надо на диск записать — это как будет в коде выглядеть?


если очень надо — реализую async/await не так красиво как «по классике» и большим количеством кода

Нет, не реализуете. Вы реализуете асинхронию в каком-то ее виде.

Ну, про «задачи реализуемые на платформе 1С» — ничего не знаю. В задачах современных ERP — весьма востребованная.


из всех примеров вы пока смогли за двое суток только пример параллельной записи файлов придумать да и тот — работе в ERP системе отношения не имеет… сценариев нет… если есть — приведите пример кейса… желательно реального а не как у вас обычно «а многим нужно лонг-пулинг для обмена с CRM»

Если мне надо из кода в 1С записать файла на диск — ну вот тупо и банально, я сформировал какой-то там текст или что-то, и мне его надо на диск записать


Файл = Новый ЗаписьТекста(ИмяФайла);
Файл.ЗаписатьСтроку(мойтекст);
Файл.Закрыть();

из всех примеров вы пока смогли за двое суток только пример

Да нет, просто вы все остальные проигнорировали.


если есть — приведите пример кейса… желательно реального а не как у вас

Совершенно реальный кейс — экспорт данных в другую систему.


Если мне надо из кода в 1С записать файла на диск

Угу. А теперь скажите мне, пока идет вот эта вот строчка: Файл.ЗаписатьСтроку(мойтекст), что происходит с потоком, в котором это выполняется? Запись на диск (или на сетевое устройство) — она того, процессорного времени не требует, выплюнул в буфер и забыл.

Да нет, просто вы все остальные проигнорировали.


может не обратил внимание — на хабре очень неудобная одностраничная схема комментариев… если не сложно напомните где остальные кейсы…

Совершенно реальный кейс — экспорт данных в другую систему.


реализовано в 1С без каких либо проблем в любую систему… те же фоновые и регламентные задания…

А теперь скажите мне, пока идет вот эта вот строчка: Файл.ЗаписатьСтроку(мойтекст), что происходит с потоком, в котором это выполняется


я без понятия что там происходит.
файл записался на диск и я получил деньги за проделанную работу.
если нужно в фоне писать — я запущу это в фоновое задание и оно будет в фоновом задании не трогая мой интерфейс писать файлы на диск…

как разработчик — я реализую ровно ту задачу которую поставят в ТЗ…
если не сложно напомните где остальные кейсы…

Не сложно. Весь I/O, то есть вся интеграция.


реализовано в 1С без каких либо проблем в любую систему…

Если вы не видите проблем, это не значит, что их нет.


я без понятия что там происходит.

Это означает, что вы не можете говорить "там, где асинхрония нужна — она есть из коробки". Вы без понятия.


И это очень грустно, на самом деле.

у фоновых заданий есть состояния — там тоже все прозрачно отслеживается…

Для чего нужно сначала получить эти фоновые задания, проверить, а потом уже разбираться. А если нужно поймать ошибку выше по стеку — задача превращается в нереализуемую. Хватит уже. Мы здесь обсуждаем конкретный минус платформы и языка 1с, и вы сами признаете что это было бы плюсом для решения части задач. Вы не забыли с чего ветка началась? С того что попытались опровергнуть минус «отказ от модальности», который по сути отказ от модальности в пользу грустного механизма вместо нормальных корутин или async/await, если абзац почитать, а не только заголовок. А еще точнее, ветка разрослась с того что вы утверждали что точно так же можно делать в 1с. Выяснили уже, нет, не так же.
мы начали с того что авторы статьи утверждают отказ от модальности это плохо…
в то время как это хорошо…

а дальше вы уже углубились во вкусовщину придумывая невостребованные задачи и требуя их реализации в 1С да еще так чтобы количество строк кода было таким же как на других языках более низкого уровня…

причем при предоставлении вам примеров их реализации вы начинаете придираться к ПРОЦЕССУ решения, тому что то строк кода много то ошибка выше по стеку (вы задачу ставили в параллель пускать процессы — я по каждому процессу отдельно поймаю ошибку и обработаю в контексте индивидуального разбора ошибки процесса или в контексте всей задачи с четырмя файлами — сам решу как разработчик)

но на выходе -я задачу решил… ошибки могу легко поймать…

в чем претензия? в том что поставленную задачу 1С решает не так как ожидаете вы, люди не работающие в 1С?

ну так условный субару двигатил строит не так как это ожидает условный ауди… от этого субару хуже не становится… и от этого субару не теряет возможности доехать из точки А в точку Б… хоть у него и бензин вместо дизеля льется…

а пока — ваши придирки это придирки на уровне «фу фу фу они пишут на русском» — какая разница если пользовательская задача решается…

мы начали с того что авторы статьи утверждают отказ от модальности это плохо…
в то время как это хорошо…

Если вы читали статью целиком, а не только по оглавлению, вы могли прочитать что проблема именно в том способе которым 1с от этого отказалась. В том что она переложила это на плечи разработчиков. Хотя могли бы добавить async/await — и от разработчиков бы потребовалось только «волшебные слова» в нужные места добавить, код остался бы тем же.
И повторюсь, если вы забыли, лично я 1с отдал 4 года и работал на достаточно крупных проектах, участвовал в написании коробки, так что претензии у меня не из разряда «фу-фу-фу они пишут на русском».
так мы всю дорогу спорим что авторы статьи «21 проблема 1С высосанная из пальца и не имеющая отношения к жизни» пишут в заголовке одно, в тексте главы совершенно другое и это совершенно другое никак не влияет на качество платформы перед которой стоит весьма узкий круг задач с которыми она, кстати, справляется весьма и весьма хорошо, а всего лишь не так удобно как в языках более низкого уровня даже не смотря на то что поставленные прикладные задачи решаются.
это совершенно другое никак не влияет на качество платформы

Вот тут вы ошибаетесь, это напрямую влияет на удобство и сложность создания, развития и поддержки ИС.
Кстати, я так и не понял, а с чего вы взяли что 1с язык более высокого уровня чем мейнстримные языки общего назначения (без негативных коннотаций, просто исходя из возможностей языка). Ведь как раз в 1с приходится часто больше кода писать, меньше кода выходи только на частных задачах, и не благодаря языку, а благодаря фреймворку.
задачи такой не стояло…

Стояло. У меня в коде это все было (я неплохо подумал, когда его писал).


да и у вас я не увидел в коде обработку различных событий незагрузки, отсутствия доступа к файлам и тд…

Потому что вы не понимаете, как работают ошибки в этом языке.


Все эти нюансы спрятаны в DownloadFileAsync, которая просто бросит exception, если ей не удастся успешно загрузить файл — и тем самым она остановит как минимум последующие действия, а при удачном стечении обстоятельств — и параллельные загрузки.


И при этом этот exception будет выше пойман блоком catch, который позволит его корректно обработать.

Давайте просто сравним, что ли.


Что случится в вашем коде, если внутри процедуры, отвечающей за скачивание отдельного файла, произойдет невосстановимая ошибка?

фоновый процесс вернет информацию об ошибке подробную

В каком конкретно месте вашего кода это произойдет? Что случится дальше?

в фоновом задание это случится мы же в параллель пустили 4 скачивания файла…
фоновое задание завершится с ошибкой, я его получу по идентификатору когда мне это будет нужно см. пример выше — прочитаю подробную информацию об ошибке и обработаю ее…

Уже выяснили, что ни в каком месте вашего кода это не случится, потому что вы этого не написали.

я не учел того что вы не поверите в то что в 1С можно писать условия «если чтото тогда делаем так то»
думал это очевидная возможность для платформы уровня 1С… вот и заленился писать очевидную ерунду…

Ровно наоборот: я понимаю, что можно писать условия, и необходимость писать условия для таких вещей меня и расстраивает.

программно реализуется и если очень хочется то можно себе организовать мирок async/await и спокойненько в нем жить

Да не async/await это, сколько можно повторять. Да, в 1с можно реализовать асинхронное выполнение какой то процедуры (но не всегда, UI из фонового задания не модифицируешь), но это не async/await, это просто асинхронщина.
И да, это полезно и удобно при решении любых задач, в т.ч. и учетных.
ну то есть весь спор свелся к спору двух таксистов:

-вы на своем бмв не можете доехать из точки А вточку Б потому что у вас бмв а не ауди
— стоп но вот я сяду и доед
— нет вы не так приедете, смотрите вы больше времени потратите и бензин у вас больше
— но у меня бензин дешевле и по цене так же и время в целом такое же т.к. я поеду дольше но пробки объеду
— но подождите, у вас посадка за рулем другая… как вы можете говорить что вы так же как я на у ауди когда у вас не ауди и все по другому и до точки Б вы не доехали как на ауди если у вас вообще не ауди а бмв…

а пассажир стоит это слушает и охреневает думая… поеду ка я на киа… уже б приехал давно

ну ок, чо… :)

есть ряд методов где асинхронность «из коробки» и код не отличается
это всевозможные диалоги выбора файлов, ввода текста, ответы на вопросы — то есть интерактивщина…

Асинхронность из коробки, но не в виде async/await, а через обработчики оповещения.

я вот подумал — в принципе я могу писать на 1С решения полностью всё пускающие через обертку длительных операций — и тогда у меня будет async/await — но мне это как разработчику неудобно будет… т.к. без обертки проще быстрее и понятнее…

Вы так и не поняли что async/await это не просто запуск процедуры в фоне с последующим отслеживанием выполнения и продолжением в другой процедуре…
Вы так и не поняли что async/await это не просто запуск процедуры в фоне с последующим отслеживанием выполнения и продолжением в другой процедуре…


да понял я уже это…

но я все же свое мнение на эту тему имею:
программирование ради программирования — это не есть цель разработки учетной системы.

я поставленную задачу выполню с прерыванием фунции и продолжением задачи в другой функции — пользователю вообще фиолетово… задача решена… моих трудозатрат — никаких

то что у меня на 10 строк кода больше — ну так в другом участке у меня будет на миллион строк кода меньше…
То что у вас на банальной операции на 10 (на самом деле чаще на сотню минимум) строк больше — повышает вероятность ошибки, усложняет чтение и поддержку кода, склоняет к упрощению логики и заставляет изо дня в день писать однообразный код, когда можно было бы потратить время на решение новых задач и написание новой функциональности.
ну опять же бессмысленная придирка…
в этом месте у меня на 10 строк больше… а например при разработке отчетов у меня будет на 100 000 строк кода меньше…

где вероятнее ошибок больше схватить? в этих 10 или в тех 100 000?

а еще учтите частоту когда по ТЗ требуется чистый классический async/await и частоту когда нужно ваять хитрые отчеты…
например при разработке отчетов у меня будет на 100 000 строк кода меньше…

А вот это совершенно не факт.

ну по сравнению с платформой авторов статьи — факт.
они формы интерфейса кодом пишут… про богатство уровня СКД — еще даже мечтать не начинали…
ну по сравнению с платформой авторов статьи — факт.

Ну, с ними меня сравнения мало интересуют.

Во первых не факт, да, во вторых это не прикладная функциональность и к тз не относится, в третьих мы не говорим про другую функциональность, мы говорим только об асинхронности, в четвертых мы говорим не о прикладной функциональности (которую можно самим написать, пусть это даже займет долгое время), а о фундаментальных возможностях языка которые не заменить простым повышением уровней абстракции через создание функций, общих модулей и т.п.
два простых вопроса:

1. фундаментально, асинхронность нужна?

2. фундаментально, в 1С асинхронность можно реализовать?

прошу отечать честно, кратко и без передергиваний…
1) Да.
2) На уровне пользователя. Асинхронный код по факту писать нельзя (то что есть — практически синхронный код реализующий асинхронность с т.з. пользователя). Хотя ее можно было бы реализовывать по человечески написанным кодом.
2) На уровне пользователя. Асинхронный код по факту писать нельзя (то что есть — практически синхронный код реализующий асинхронность с т.з. пользователя). Хотя ее можно было бы реализовывать по человечески написанным кодом.


я вас не об этом спрашивал.

еще раз спрошу, внимательно почитайте вопрос:

2. фундаментально, в 1С асинхронность можно реализовать?
Да. Но вопрос который поднимает автор статьи не в том что асинхронность не нужна, я уже цитировал что авторами имелась в виду именно убогость текущей реализации этого механизма, когда вместо того чтобы делать это прозрачно, кучу работы возложили на программиста.

Вот я очень не люблю прибегать к этому аргументу и почти никогда этого не делаю, но в данном случае не вижу другого выхода.
У вас не хватает опыта работы с другими системами, языками и платформами чтобы видеть недостатки 1с. Неудобства и костыли вы принимаете за норму и правильный подход, как и излишние ограничения. Вы просто не видите что в любой конфигурации тысячи и десятки тысяч мест где было бы удобно применить async/await паттерн, что способствовало бы заметному упрощению. Вы не видите что платформа выступает как фреймворк с кучей функций стандартной библиотеки, но по факту язык более низкоуровневый ибо требует для реализации того чего нет в стандартной библиотеке опускаться на более низкий уровень абстракции чем, например, C# или котлин. Сколько времени несколько человек вам толкует что после доработки языка 1с вы бы могли еще больше упростить и ускорить работу — но вы все время приводите монструозные блоки кода которые делают почти то же самое, просто заметно неудобнее и вы утверждаете что это не недостаток.
но я не автор статьи и я вам задал простой вопрос.
разве нет?

+

Я как раз не скрываю что у меня нет опыта в других языках и именно по этому я долго и упорно выяснял что именно вам не нравится в реализции асинхронности платформой 1С и почему оно async/await…

и таки да — я согласен что в чистом виде async/await в 1С нет, в то время как ВСЕ задачи которые вы решаете чистой async/await в 1С решаются другими методами — с большим количеством строк кода но принципиально решаются.

+ смотрю на эту ситуацию с другой стороны: авторы статьи не работают в 1С и не решают задачи учета в 1С, они с ней конкурируют — по этому то что по сути не является проблемой — ими преподносится как проблема… например глава «отказ от синхронности» или претензия к визуальной разработке интерфейса — где авторы просто не знают про управляемые формы что это почему это и для чего и пишут откровенную ересь про веб приложения и тд и тп…
по этому то что по сути не является проблемой — ими преподносится как проблема

Я работал с 1с 4 года, участвовал в реализации крупных проектов и двух коробок (в которых в т.ч. и сами 1с были задействованы как консультанты и третейский судья). И то что авторами данной статьи преподносится как проблема — я тоже считаю проблемой.

Впрочем такими темпами это уже на третий круг пойдет. Разойдемся при своих, друг друга мы не переубедим, а для стороннего наблюдателя аргументов с обоих сторон достаточно чтобы он принял для себя какое то решение или сделал выводы.
вы под конец беседы просто на вопрос ответьте:

Есть ли в 1С асинхронность, да или нет?

:)
https://habr.com/ru/company/lsfusion/blog/468415/#comment_20715257
Дам еще раз ссылку на комментарий. Если что — первое слово в нем и было ответом. А далее шло пояснение что мы обсуждаем не наличие/отсутствие возможности реализовать асинхронность для пользователя или части кода (с этим с самого начала никто не спорил если что), а обсуждаем попытку опровержения пункта из статьи почему это сделано плохо.
ох как вам не хочется просто и прямо ответить «Да, в 1С есть асинхронность»

:)

ок… мы уже пошли по четвертому кругу.
Еще раз, я давно уже ответил. Просто вы сдвигаете диалог от изначального вопроса к другому (с которым я и не спорил). Это как классический пример из области манипуляции: «Вы уже перестали пить коньяк по утрам?» Ответы да и нет на этот вопрос просто не подходят поскольку с самого начала вопрос не имеет смысла.
А вы упорный. Даже с lair, который куда больше разбирается в вопросе, я так долго не продержался.
Есть. Но сделана криво. А вот синхронности нет и ее приходится эмулировать руками.
Ну да, все задачи, которые решаются современными языками и IDE, можно было бы решить на С++ конца 90-х гг. (год рождения языка 1С — 1996. Списан с Visual Basic 4.0 1995 г.в.). Однако уже 20+ лет прошло, и программистская отрасль на месте не сидела.
Вы просто не видите что в любой конфигурации тысячи и десятки тысяч мест где было бы удобно применить async/await паттерн,


а когда я у нескольких человек просил пример задачи где async/await реально востребован — мы выдали сомнительную задачу параллельно скачивать файлы — применение метода ради применения…
Ну вы даёте. Вы же сами писали, что использовали фоновые задания для асинхронной подкачки файлов. Ну так такие вещи и делаются через async/await, в одной процедуре, в одном контексте, с обработкой любого типа исключений, отмена пользователя, обрыв соединения, отображения процесса на экране. Никакого спагетти-кода, всё просто и понятно даже первокурснику.
вопрос в практических сценариях — у меня именно за передачу файла отвечает платформенная реализованная именно для диалогов вопроса/ответа/предупреждения/работысфайлами нахлобучка которая в 3 строчки кода все делает… правда прерывая процедуру и ожидая внешнего события — удобно быстро и просто…

я в целом концептуально спрашивал про примеры когда в учетной системе нужно параллелить произвольные функции/процедуры — в каких массовых сценариях например это востребовано?
я в целом концептуально спрашивал про примеры когда в учетной системе нужно параллелить произвольные функции/процедуры — в каких массовых сценариях например это востребовано?

Вы даже не поняли, что async/await — это не про параллелизм, а про асинхронию. А она востребована, например, там, где нас начинают волновать ресурсы при большом числе одновременных подключений.


А типичный массовый случай — это все общение с внешними системами, где есть I/O (включая даже работу с диском).

а в ЕРП пример?

диски, драйвера, это все хорошо — в этих самых ERP можно примеры где без async/await ну прям не обойтись?

А это в ERP и происходит. Каждое обращение к БД, каждый вызов веб-сервиса, каждая запись или чтение файла.


Обойтись-то можно, очень много без чего можно обойтись. Просто "обходясь" вы будете терять.

ну до сих пор 1С без этого жила и весьма неплохо…
посмотрим как дальше будет.
будет async/await востребованна бизнесом — 100% появится… пока видимо она нахрен никому не нужна кроме труъ-программистов…
ну до сих пор 1С без этого жила и весьма неплохо…

Понятие "неплохо" — оно относительно.

все в мире относительно…
всякие .net платформы где есть настоящий async/await почему то не спользуются для автоматизации бизнеса а та же 1С в каждой российской конторе стоит…
всякие .net платформы где есть настоящий async/await почему то не спользуются для автоматизации бизнеса

Если вы о чем-то не знаете, то это еще не значит, что этого не существует. Даже в России как минимум в "одном федеральном агенстве" основная учетная система на .net (включая интерфейс с внешним миром). А уж за пределами России все еще более интересно.

ну вы же понимаете что я пишу в контексте «мира 1С»?

или мы тут обсуждаем не платформу для разработки учетных систем а язык программирования на котором игры пишутся, операционки и прочие системы управления ядреными реакторами?
ну вы же понимаете что я пишу в контексте «мира 1С»?

Нет, не понимаю. Бессмысленно обсуждать, какая платформа лучше подходит для решения задач "в мире 1С" — очевидно, что 1С. Но я не живу в мире 1С, и никто из моих заказчиков в нем не живет.


или мы тут обсуждаем не платформу для разработки учетных систем

Да нет, мы именно разработку учетных систем обсуждаем. И я вам пример учетной системы и привел, в общем-то. Вот, скажем, в Скандинавии есть такая компания Visma с продуктом Visma.net ERP. Он, вы не поверите, на .net. И он в этой самой Скандинавии весьма распространен, потому что хорошо интегрирован с госухой. Или вот в Австралии/Новой Зеландии есть MYOB Advanced, который, внезапно, тоже на .net, и тоже вполне себе используется.


Так что ваше заявление "всякие .net платформы где есть настоящий async/await почему то не спользуются для автоматизации бизнеса" — оно от незнания.

Вот, скажем, в Скандинавии


рассуждения уровня «а вот в америке негров вешают»

авторы статьи — из Белоруссии.
критикуют платформу — у которой целевой рынок Россия и страны СНГ (и то не особо)
критикуют в контексте выхода на рынок со СВОЕЙ ПЛАТФОРМОЙ хотя бы Белоруссии дабы подвинуть 1С которая туда свои щупальца запустила через 1С: Минск и прочих франчей…
Идея статьи — накопление фона «1С плохая. а вот наша платформа хорошая» — хотя по факту они на уровне 1С десятилетней давности…

а вы тут начинаете «зато в новой зеландии и астралии..»

еще раз поясню: я не навязываю вам что 1С лучшая платформа в мире (хотя он так и есть) — нравится .net — разрабатывайте в .net, у 1С есть минусы которые обусловлены просто отсутствие кейсов где бы эти возможности были бы незаменимы и востребованы — тот же async/await не нужен для учетных задач в полном объеме… а там где появляется потребность (например для сохранения совместимости) закрывается локальными процедурами и функциями платформы…

зато 1С в других аспектах уделывает другие учетные системы…
рассуждения уровня «а вот в америке негров вешают»

Да нет, рассуждение уровня "смотрите шире".


я не навязываю вам что 1С лучшая платформа в мире (хотя он так и есть)

Да нет, вы именно это и навязываете. И утверждаете, что .net не используется в учетных системах, хотя это банально неправда.


Просто если 1С так хороша в рамках одного рынка — может, стоит задуматься, чем ее "хорошесть" обусловлена?

Да нет, вы именно это и навязываете. И утверждаете, что .net не используется в учетных системах, хотя это банально неправда


я автоматически писал в контексте
1. массово
2. в России

Просто если 1С так хороша в рамках одного рынка — может, стоит задуматься, чем ее «хорошесть» обусловлена?


тем что она заточена под узкий круг задач и справляется с ними отлично…
а то что ее нет на других рынках — причин множество… и технические причины типа отсутствия услоных асинк/авейк — далеко не в первых рядах…
я автоматически писал в контексте
  1. массово
  2. в России

… и не подумали, что у людей может быть другой контекст. Впрочем, вы уже написали "в мире".


тем что она заточена под узкий круг задач и справляется с ними отлично…

… и как только надо за пределы этого круга выйти, может внезапно оказаться, что она совсем не лучшая. О чем, собственно, и речь.

… и не подумали, что у людей может быть другой контекст.


мы же тут 1С обсуждаем а не .net
а в 1с по умолчанию целевая аудитория СНГ…

и как только надо за пределы этого круга выйти, может внезапно оказаться, что она совсем не лучшая. О чем, собственно, и речь.


выход за пределы круга решается например посредством внешних компонент…
либо оптимизацией ТЗ например…

заказчики они же такие — они думаю что им надо оно а бизнеспрактиа может например показать совершенно друге… — спросите у саповцев как они бизнесы корежат для того чтобы бизнес в рамки их учетных систем влез :)

есть такая поговорка «автоматизируя хаос- вы получаете автоматизированный хаос»…
мы же тут 1С обсуждаем а не .net

… и поэтому вы пишете, что .net не используется.


заказчики они же такие — они думаю что им надо оно

О, давайте я вам кое-что напомню теперь.


если я нанимаю уборщицу — ее дело убираться в офисе а не указывать мне как я столы и стульяв офисе ставлю и как я бизнес веду…

если я нанимаю разработчика — его дело по ТЗ реализовывать, требования к интерфейсу и юзабилити в котором я прописываю как заказчик…

Узнаете? Если вас, как разработчика, наняли — ваше дело по ТЗ реализовать, а не указывать, что там где надо оптимизировать. Нет?

Узнаете? Если вас, как разработчика, наняли — ваше дело по ТЗ реализовать, а не указывать, что там где надо оптимизировать. Нет?


вы мыслите категориями кодера… которому дали ТЗ и он кодит — «заказ — разработка»

в 1С «разрабатывают с нуля на голой платформе» крайне редко
там скорее схема «заказ — интеграция готового инструмента — оптимизация под клиента»
и вот как раз на интеграции, с интегратором обсуждаются все моменты этой самой интеграции и особенности… и если на этом этапе будет противоречивое ТЗ, неоптимальное решение, невозможное с точки зрения 1С требование — то опытный интегратор предложит несколько альтернативных решений узкого момента и как правило завсегда находится альтернативное решение…

простой пример:

заказчик говорит: хочу реалтайм обмен с сейлсфорс
трукодер: ок… пошел на .net писать систему… 1000 часов разработки.

интегратор от 1С: а точно реалтайм, а для чего? для того чтобы менеджер оперативно видел лиды? а… он их уже в сейлсфорс обработал и это надо отделу закупок? а как он увас работает вот так то и так то… ну так вам не кажется что раз в 5-10 минут будет достаточно при подобной схеме организации труда? Ок. делаем на REST API — 100 часов.
вы мыслите категориями кодера…

О нет, я всего лишь вам вас цитирую. Так что если вам кажется, что я мыслю категориями кодера, то это… ваши мысли.


простой пример:
заказчик говорит: хочу реалтайм обмен с сейлсфорс
трукодер: ок… пошел на .net писать систему… 1000 часов разработки.

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

Вообще-то, я вам этот пример показал не как пример того, где async/await востребован, а как пример того, как он выглядит и работает.

пользователю вообще фиолетово…

Ну да, да. Правда, у него работает медленнее, чем могло бы, иногда отправляются не все файлы непонятно, почему, и на разработку ушло в три раза больше времени — а так да, фиолетово.

Простите, а вы точно смотрели реализации в других языках? Хотя бы на дарт посмотрите, он чем то близок 1с (один основной поток + изоляты как фоновые задания + возможность коммуницировать через platform channels с потоками на других языках (и их инициировать), но без shared данных, чисто на событиях (асинхронных)). И посмотрите как и для чего там async/await/future используются. Уж простите — но одним каментом этого не объяснить.
И да, если совсем коротко — в точке вызова вашей магическоесловокоторосчитаетцифру() процедура будет ждать ее завершения и только потом продолжится, но это никак не блокирует интерфейс или исполнение другого кода. А как это работает — повторюсь, объяснить в одном каменте не выйдет.
И да, если совсем коротко — в точке вызова вашей магическоесловокоторосчитаетцифру() процедура будет ждать ее завершения и только потом продолжится, но это никак не блокирует интерфейс или исполнение другого кода.


то есть я правильно понимаю что в моем примере в поле «Результат2» попытается записаться «неопределено+1» и будет выдана ошибка?

и если результат2 зависит от результат1 то я должен значит не продолжать код далее а прервать код и использовать расчеты из результат1 только после того как явно получу их в контекст?

Нет. Процедура будет ждать. Т.е. буквально. В момент вызова магическоесловокоторосчитаетцифру() замрет (не блокируя тем не менее интерфейс и другие вычисления), затем продолжится после завершения магическоесловокоторосчитаетцифру() ровно с того же места и положит в ваш результат2 3+1, ну и дальше спокойно побежит.
Нет. Процедура будет ждать. Т.е. буквально. В момент вызова магическоесловокоторосчитаетцифру() замрет (не блокируя тем не менее интерфейс и другие вычисления), затем продолжится после завершения магическоесловокоторосчитаетцифру() ровно с того же места и положит в ваш результат2 3+1, ну и дальше спокойно побежит.


весьма неплохое решение.

1С просто чуть дальше пошла и сразу реализовала возможность получить результат в другое окно/контекст…

то есть сохранив вашу функциональность посредством введения собственной логики работы с событиями — 1С реализовала возможность запускать события в одном контексте а обрабатывать в другом…

а на выходе — 100% покрытие вашей функциональности + дополнительные возможности
Понимаете в чем дело, в нормальных языках оно работает в обоих вариантах. Колбеки, замыкания и async/await — позволяют писать код по человечески. Хотите передать результат другому объекту — да пожалуйста, никто не мешает.
так он и в 1С работает так же в обоих вариантах -чем 1С в этом плане не нормален?

тем что по другому синтаксис построен?
ну так опять же — вкусовщина и субъективизм, плюс рефлекторное непринятия 1Са со стороны сообщества…

а по факту то задачи те же решаются, возможности те же…
Да не так же, в том и беда. Вот есть у вас цепочка вопросов, часть вопросов в зависимости от ответов на предыдущие вопросы выкидывается, часть добавляется, иногда нужно выбрать значение из справочника или перечисления. А по результатам какое то действие совершить. Сколько дико костыльного кода на 1с вам потребуется написать для реализации такого сценария?
они все сразу открываются а потом должны закрываться по мере отсутствия необходимости или там просто идут проверки и постоение дерева вопросов исходя из результатов предыдущих ответов и все это последовательно открывается?

пока вы просто озвучили задачу простейшего помошника настройки когда из ответов на очередном этапе настройки следующий открывается с учетом данных предыдущих вариантов… типа «осно — настройки пбцу18 — настройки прямых затрат» и пошли ветки дерева вариантов настроек…

это же по сути тупокодинг под конкретную задачу и логику описанную в ТЗ

ни в одном языке программирования нет голосового ввода ТЗ и сразу интерпретации этих человеческих хотелок в готовое решение…
там просто идут проверки и постоение дерева вопросов исходя из результатов предыдущих ответов и все это последовательно открывается?

Каждый раз при вызове «ПоказатьВопрос» вам нужно будет прерываться, класть все нужные данные (которые на каждом шаге отличаются) в структуру, которую класть в этот обработчик которому задавать имя процедуру продолжения в которой все повторять. Есть вариант чуть лучше когда метод обработчик указывает сам себя как получатель и получаем конечный автомат почти — но это также гораздо менее удобно чем банальное
Результат = Вопрос("А", варианты,...).ЖдатьРезультата()
Если (Результат = а) тогда
// выбор из списка и завершение
ИначеЕсли (Результат = б) тогда
// завершение
ИначеЕсли (Результат = в) Тогда
// еще два вопроса и в зависимости от ответов либо на сервер идем за инфой и задаем новый вопрос либо завершение
Иначе
// Еще вопрос
КонецЕсли;

Если (ЧтоТоПодсчитанноеРанее И Вопрос("Б"...).ЖдатьРезультата() = Да) Тогда
// Сохраняем изменения
Иначе
// Закрываем форму
КонецЕсли;
Каждый раз при вызове «ПоказатьВопрос»


я и не собирался пользоваться «ПоказатьВопрос» — я форму сделаю с нормальными элементами на форме…

делать подобный опросник через «показатьвопрос» глупо, вы еще через ввод строки сделайте… пуляя в заголовок вопрос на который ответ надо ввести…

описанная вами задача вообще без фоновых событий решается…

Вы так и не поняли что это был лишь абстрактный пример лишь иллюстрирующий проблему… Или вам тут полноценную конфигурацию накидать нужно? Ну и да, проще задать пять вопросов в одной процедуре чем городить форму где в зависимости от проставленных флагов или выбранных значений нужно будет управлять видимостью и изменением значений других элементов.
Вопросы были лишь как демонстрация. Вместо них могут быть 5 разных форм подбора каждая со своей функциональностью (тоже будете склеивать в одну мегаформу или влезать в код каждой формы и прописывать новую логику в зависимости от переданных параметров при открытии?)

Я уже наверно скоро скачусь в банальный аргумент 1сников которые часто отметают претензии тем что оппонент не знает 1с…
ну вы у себя тоже будете писать вызов и анализ результата?
конечно будете

ну я положу проверку результата в обработку оповещения и так же напишу все нужные проверки и логики… и будет так же открываться этот показатьвопрос и так же будет обрабатываться…

искренне не понимаю выдуманной проблемы из обычной в общем то задачи которая зачастую еще и красивее решается не тупым «показатьвопрос» а созданием нормального визарда…

Засим закругляюсь. Вижу что вы не то чтобы не можете понять проблемы, вы ее не хотите понять.
И бессмысленно сваливаться в частности при обсуждении принципов. Принципы намеренно иллюстрируются упрощенными примерами.
ну так в этом то и проблема — все ваши проиллюстрированные принципе через упрощенные примеры легко и непринужденно решаются на платформе 1С…

то есть е не нехочу понять проблему — я ее просто не вижу т.к. исходя из того что я почерпнул из нашей переписки- проблемы для 1С и разработки на 1С — нет.
Да пожалуйста, ваше решение. Я в свое время эти проблемы увидел, что помогло принять решение с 1с уйти.
ну помошник начального заполнения типовых же — например УНФ или ЗУП…
дерево настроек зависимое от предыдущих ответов ведет пользователя с нуля до окончания настроек…

это прям первое что приходит в голову…
опять же — закрытие месяца в той же БП… да там куча подобных помошников — тривиальная же задача…
Вы все таки не понимаете…
Ну и да, это не 100% покрытие этой функциональности. Нет возможности сохранить стек вызовов. Ну никакой нет. Т.е. в цикле например не получится в таком виде работать (ну ладно, через костыли и сотни строк кода можно сделать чтобы результат для пользователя выглядел так же, но… Вы серьезно?)
1С просто чуть дальше пошла и сразу реализовала возможность получить результат в другое окно/контекст…

Это то "дальше", которое в .net было до TPL и async/await?


Вопрос-то в том, как легко и просто попасть в тот же контекст, где вы были.

Вопрос-то в том, как легко и просто попасть в тот же контекст, где вы были.


собственно ловить результаты в том контексте в котором вы были и далее продолжить его выполнение…

у вас там как выше коллеги писали обработка останавливается и ждет результат1 чтобы посчитать результат2, в 1С отпралвяется событие и затем по факту завершения запускается процедура с входящим параметром «результат1» в которой далее читается то что нужно- в нашем примере результат2

те же яйца только сбоку…
те же яйца только сбоку…

В том-то и дело, что нет. То, что вы описываете — это APM (ну либо EAP, что еще хуже). Он известен, понятен, и у него есть недостатки.


async/await — это другой паттерн, со своими достоинствами (и недостатками, я подозреваю). И скомпенсировать эти достоинства в APM просто нельзя.


Все это, впрочем, станет очевидно, когда вы приведете код.

и если результат2 зависит от результат1 то я должен значит не продолжать код далее а прервать код и использовать расчеты из результат1 только после того как явно получу их в контекст?

В том-то и дело, что не вы должны, а платформа за вас все делает. А вы пишете код так, как если бы все операции были синхронными.

если мне надо закрыть форму результат1 поймать в другую форму?

А это другая задача с другим решением.

Пример кода покажите, пожалуйста.

Миллион раз у них это спрашивал. Отвечают, что они мышкой все программирует, и кода не нужно вообще.
Не будет у них примера, в 1С сейчас нет stackless корутин ни в каком виде. Асинхронность есть, аналогичная APM (BeginInvoke/EndInvoke).
1С умеет то что умеет async/await


глубокая мысль…

ну всё же было сверху написано — что реализовано в 1с, а что является нормальной практикой сейчас в иных ЯП

но кто-то не понимая сути вопроса сначала лезет на абордаж, а потом съезжает «я же могу тоже самое»

и глаза на что раскрыть надо? вы не понимаете вообще что вам пишут
«Ассемблер умеет то что умеет 1с. Может будет какой пример который я не могу решить своими методами?»
Аналогия понятна?
а в контексте готовых платформ для автоматизации бизнеса и написания ERP?

сроки, стоимость, трудозатраты и возможности?
мы же общаемся не в целом «язык программирования 1С лучше/хуже чем сишарп» а в контексте решения бизнес-задач, стоимости этих решений, удобстве и скорости их реализации и сопровождении… разве нет?
А про бизнес задачи я вам выше написал. Когда
куски бизнес логики отделены друг от друга не по причине разных уровней абстракции или разных задач, а по причине технических ограничений
бизнес задачи решать, внезапно, сложнее и медленнее.
1С умеет то что умеет async/await


Нет, не умеет, совсем. И это одна из реальных проблем, да.
я просто тупой 1Сник, вы не могли бы практический пример привести который нельзя реализовать?

не терминами сыпать безапелляционными а простой пример который наглядно покажет что это нельзя сделать в 1С?

потому что исходя из того что я бегло почитал — никаких невыполнимых функция я не увидел ни в async/await ни в
stackless — а мне действительно хотелось бы понять что можно а что нельзя…

спасибо.
Проблема в удобстве. В 1с конечно можно через всякие обработчики оповещения накостылять, но выглядит и пишется это ужасно. Даже если отбросить многопоточку коей в 1с нет, и наверно правильно, зная квалификацию многих 1сников которые попутно еще и обязанности эникея выполняют а 1с занимаются 1 день в месяц. И то есть пример без многопоточки но нормально это реализующий, дарт.
ну это же субъективизм и вкусовщина… особенно в контексте того что у обработчиков оповещения возможностей больше и они решают в том числе и другие задачи, такие как получение оповещений из других контекстов…

Есть простая задача. Открыть в цикле N форм, результат возвращенный из каждой формы обработать ( с возможностью по условию прервать этот цикл если например значение вышло за рамки какие то), полученное сгруппировать и посчитать в исходной форме, и вернуть процедуре вызвавшей текущую процедуру. Ваше решение на 1с?
все формы обрабатываются параллельно? то есть я открыл 10 форм в каждой что то внес и по факту общих расчетов в какой то момент понимаю что остальные формы не нужны и они закрываются и открывается 11ая форма с результатом?

Чуть выше дал пример с цепочкой вопросов и форм.
Предположим, что есть внешнее API отдающее поток событий через long polling. Реализовать обработку потока событий на 1С таким образом, чтобы минимизировать занятие потока фоновым заданием (потому что пока мы висим на long polling хотелось бы и другие задания повыполнять), без холостых оборотов процессора (потому что Thread.Sleep() у вас нет) и без пересоздания фоновых заданий(потому что в 1с создание фонового задания — это очень дорого и медленно).

Это очень большой класс задач, если что, которые реально пытаются решать на 1С — от телеграм-ботов до торговых терминалов.
http сервис например и далее реакция на входящее событие?

или именно нужно получать событие а не ждать его от внешней системы пока мы чем то другим занимается?
— тогда фоновый процесс… пусть сидит себе на сервере и чем угодно занимается оповещая нас о результатах…

не очень понятно почему вы не хотите использовать инструментарий который для этого и разрабатывался…
«нам надо забить гвоздь но мы будем его забивать клещами» — странная логи
Ждать его от внешней системы удерживая http-соединение и параллельно занимаясь другими делами, не занимая фоновым заданием рабочий поток, который мог бы делать что-то полезное.

не очень понятно почему вы не хотите использовать инструментарий который для этого и разрабатывался…


Потому что существующий инструментарий разрабатывался не для этого и не решает проблему.
http сервис не удерживает соединение — в него внешние источники долбятся… и он реагирует например на вебхуки облачных телефоний… и
http сервис не удерживает соединение


Я еще раз повторю — long polling.
фоновые процессы тогда — запускаешь и он там что угодно делает независимо от тебя…

не очень тогда понимаю сути проблемы- недостаточно быстро? ну так учетная система 1С делалась не для автоматизации космических кораблей — у нее свои утилитарные задачи… умеет? умеет — отлично… кто то может быстрее — молодцы… зато 1С в чем то другом много сильнее того кто long polling держит красивее чем 1С…
фоновые процессы тогда — запускаешь и он там что угодно делает независимо от тебя…

И занимает ресурсы. А этого хочется избежать.

хм… а бывают системы где например что то работает и не занимает ресурсов вообще? вот прям вообще вообще?

или речь про оптимизацию — типа «в нашем языке программирования данная задача решается на 10% меньше используя ресурсов чем в 1С»?

Про оптимизацию, конечно.

тут спорить не буду… 1С заточенная под другое будет явно менее оптимальна чем спициально заточенные под это библиотеки и/или языки…

но тут есть подводный камень — автоматизация бизнеса в целом…
зачастую бывает так что не являясь оптимальной в чем то узком — 1С как платформа наиболее оптимальна для автоматизации всего бизнеса в целом и небольшую неоптимальность в не титульном процессе 1Су простить вполне можно… :)
спициально заточенные под это библиотеки и/или языки…

.NET — платформа общего назначения, а C# — язык общего назначения.


1С как платформа наиболее оптимальна для автоматизации всего бизнеса в целом

Это утверждение, скажем так, не доказано.

ну вы для примера привели:

.NET — платформа общего назначения, а C# — язык общего назначения.


1С по сравнению с ними — наиболее заточена для автоматизации бизнеса…

Это некорректное сравнение, потому что вы сравниваете платформу общего назначения с прикладной платформой.


Сравнивайте уж тогда с прикладными платформами, написанными на .NET.

это вы привели данные языки в контексте обсуждения неоптимальности решения на платформе 1С задач которые не являются целевыми для прикладной платформы…
задач которые не являются целевыми для прикладной платформы

Ну то есть "если 1С этого не умеет — это не целевая задача", да?


Понимаете ли, в чем дело, я много лет (последние два места работы) занимаюсь разработкой ERP-решений. И я очень хорошо понимаю, почему описанные задачи являются типовыми для современной ERP.

И я очень хорошо понимаю, почему описанные задачи являются типовыми для современной ERP.


Оказывается, что я на прошлой работе полгода занимался нецелевой проблемой :(

Всего полгода?..

Занимался, а не полностью решил.

Не, я в том смысле, что многим людям удается годами и даже при везении десятилетиями нецелевыми проблемами заниматься.

задач которые не являются целевыми для прикладной платформы


Они не являлись целевыми в 2002 году, надо понимать, что мир изменился, а платформа уже несколько устарела.
1С как платформа наиболее оптимальна для автоматизации всего бизнеса в целом


Это утверждение, скажем так, не доказано.


Оптимально — это несколько перебор у вашего оппонента.

Но одна из лучших — это верно.
Рынок доказал же. Какие еще могут быть доказательства? Ну разработал я мегакрутую платформу лучше — если по ней специалистов нет, то для автоматизации бизнеса она будет не лучшим выбором.

В сегодняшней ситуации — это так, 1С хороший выбор для автоматизации бизнеса. Что в будущем будет, можно следать лучше — это другой вопрос.

Рынок доказал же.

Что доказал, как доказал, и что самое важное, какой рынок?


(я не издеваюсь, я очень серьезно спрашиваю)


Что в будущем будет, можно следать лучше — это другой вопрос.

Вы же понимаете да, что это очень плохо сочетается с аргументом "если специалистов нет"?

Что в будущем будет, можно следать лучше — это другой вопрос.

Вы же понимаете да, что это очень плохо сочетается с аргументом «если специалистов нет»?


Почему?
Нет желания за свой счет тестировать.

А у разработчиков — мотивация есть, как вижу.
Пусть развивают, рекламируют, обучают…

Глядишь, пройдут тот критический барьер, когда сообщество само растет.

Почему?

Потому что неоткуда взяться специалистам.


(Занятно, впрочем, что вы не ответили на предыдущие вопросы)

Проблема в том что в 1с «работает» а не работает. Т.е. крутит в холостую цикл «Пока Истина Цикл… КонецЦикла;»
А бывает что не работает вообще никак, даже так.
без конкретной задачи — бессмысленный спор…
может это просто лично вы в бытность 1Сником ничего кроме цикла не знали и реализовывали все без фоновых процессов тупо в цикле в клиентских формах…

Я как раз имею в виду цикл в фоновом задании. Ну не умеет 1с держать открытое соединение. Народ городит отдельные потоки во внешних компонентах которые держат соединение открытым, сигналят 1с, а фоновое задание в бесконечном цикле проверяет результаты.
Я как раз имею в виду цикл в фоновом задании. Ну не умеет 1с держать открытое соединение. Народ городит отдельные потоки во внешних компонентах которые держат соединение открытым, сигналят 1с, а фоновое задание в бесконечном цикле проверяет результаты.


Именно так, при этом работает все плохо, потому что фоновые задания архитектурно не рассчитаны на то, чтобы жить долго и тем более крутить бесконечный цикл.
Поэтому, сейчас актуальная тема — интегрировать 1С с Кроликом :))
практическую задачу из сферы автоматизации бизнеса можно? ну для которой у вас фоновое задание ПОСТОЯННО должно крутиться?

ps: в 1С есть такая сущность как регламентное задание — и не надо никаких циклов крутить…
А каким боком регламентное задание позволит работать с постоянно открытым HTTP соединением?
А бизнес задача простая, оптимизация работы. Установка соединения, между прочим, довольно тяжелый процесс.
для киосков по торговле носками (обычное место обитание 1с за пределами бухгалтерии) это не тяжелый процесс. и «бизнес всегда доволен» — пусть месяц закрывается по 2-е суток. то не страшно

вы адептов еще спросите почему пустая база бухгалтерии столько весит и тормозит. причем тормозит «сама по себе» — основные счетчики в win «пустые»
А каким боком регламентное задание позволит работать с постоянно открытым HTTP соединением?

long-polling в http сам по себе костыль.
websocket нужно использовать.
Например, как здесь:
wonderland.v8.1c.ru/blog/sistema-vzaimodeystviya

Поллинг сервиса биржевых котировок ровно раз в секунду, например. Регламентные задания без внешних костылей не справляются.


А конкретная задача про биржевые котировки, что тут приводилась, может быть решена и вообще иначе в 1С
infostart.ru/public/819178

Или вот можно с внешней компонентой решить ту же задачу infostart.ru/public/434771

wonderland.v8.1c.ru/blog/sistema-vzaimodeystviya


Во-первых, это не вебсокеты, а во-вторых, удачи в использовании api, которое не поддерживает вебсокеты, а таковых много.

UPD Точнее это не те вебсокеты, с помощью которых вы можете проинтегрироваться с внешними апи.

А конкретная задача про биржевые котировки, что тут приводилась, может быть решена и вообще иначе в 1С
infostart.ru/public/819178


Это джаваскрипт, а не 1с. На сервере тоже будете фейковую страничку открывать… где?

Или вот можно с внешней компонентой решить ту же задачу infostart.ru/public/434771


Это не эта задача. Ну и внешняя компонента — это не 1С и не переносимо.
Ну и внешняя компонента — это не 1С

Внешние компоненты должны реализовывать API 1С — иначе это не будет внешней компонентой. Так что это вполне полноценный компонент расширения 1С.
Считает, что платформа должна реализовывать на все случаи жизни ситуации?
Воспринимайте её как библиотеку, вы же в прочих языках не только стандартную библиотеку используете?

То есть мы имеем вроде бы переносимую платформу, но я не могу решить проблему на компьютере с Windows, так чтобы решение из коробки заработало на компьютере с Linux или MacOS.

Считает, что платформа должна реализовывать на все случаи жизни ситуации?


Нет, но описанные выше сценарии — они не экзотические, они совершенно обычные и болит от у них у многих.
а зачем постоянно открытым держать HTTP соединение?

практический смысл из мира учетных задач можете привести?

ради чего нужна нагрузка, постоянный канал и это вот все?

мы же не забываем что 1С это не убийца С++ и не замена питону — это прикладная среда для решения определенного круга специфических задач…

Интеграции например.
а вам сказал что для интеграции постоянное открытое соединение — правильное решение?

Поставщик с другой стороны.

ну то есть вы заложник чужого архитектурного косяка?
а поставщик с той стороны API предоставил какое то для подключения? описание протоколов, методов и прочее — что обычно предоставляют в таких случаях? есть пример где посмотреть подобные требования?
ну то есть вы заложник чужого архитектурного косяка?

Да. Типично для интеграции.


а поставщик с той стороны API предоставил какое то для подключения?

Да. HTTP.


есть пример где посмотреть подобные требования?

Я уже давал ссылку.

если вы про salesforce.com — то они на своей стороне говорят про REST API…

Уже обсуждалось, повторяться не буду.

Иногда бывает что нет выхода. Система какая нибудь проприетарная там. Но вообще конкретно это — довольно частный случай применения подобного подохода. Так то есть тысячи мест в коде которые почти каждой конфигурации где это пригодилось бы.
ну тут дело то такое — мы же живем не в мире монополий, тот же сейлсфорс по идее заинтересован в максимальном охвате рынка — и как раз он имеет и соап и рест апи для интеграции… прямо из коробки несколько вариантов — на хабре на эту тему статьи даже есть…

нет в 1С одной технологии с постоянным соединением — ну вот две другие… бери и синхронизируйся соапом…

понятно что можно найти 100500 ситуаций которые не умеет 1С — типа работы с драйверами напрямую с железом и прочие низкоуровневые штуки… но 1С то не для этого делалась… она делалалсь чтобы учетные системы строить, чтобы контекстные чаты и видеоконференции, которые вы в других системах год писать будете — в 1С работали без строчки кода из коробки с привязкой к добавленным и измененным объектам…
нет в 1С одной технологии с постоянным соединением — ну вот две другие… бери и синхронизируйся соапом…

И не получите real-time.

а в CRM точно нужен real-time или задержка в 3 секунды допустима на загрузку и обработку лида?
а в CRM точно нужен real-time

Иногда нужен.


или задержка в 3 секунды допустима на загрузку и обработку лида?

Это если вы можете в pull-модели обеспечить задержку в три секунды (спойлер: не всегда).

сферическая CRM в вакууме где задержка на загрузку лида из ВНЕШНЕЙ системы в 3 секунды критична…

мне кажется тут с постановкой задач и организацией бизнеспроцессов что то не очень в порядке…

А мне кажется, что тут что-то не так с пониманием. Потому что я не написал, что задержка в три секунды критична, я написал, что обеспечить три секунды часто сложно.

Поллинг сервиса биржевых котировок ровно раз в секунду, например. Регламентные задания без внешних костылей не справляются.

… или вот интеграция с Salesforce (куда уж бизнесовее-то) по Streaming API.

… или вот интеграция с Salesforce (куда уж бизнесовее-то) по Streaming API.


Где не хватает 1С — всегда можно написать небольшой адаптер-конвертер на другом языке.
Прицепить его к 1С легко. 1С имеет средства интеграции с внешним ПО кучей способов, среди них есть и с поддержкой асинхронности явной (внешние компоненты) или неявной (COM, http-сервисы)

Ну, задачей-то было показать, что 1С не хватает. То, что изворотливый программист это может решить — понятно.

Два раза ответил, отвечу и третий: по REST вы не получите уведомлений.

я реально не догоняю: если есть внешний сервис выдающий мне список уведомлений которые я должен показать в своей системе и я каждые 10 секунд собираю эти уведомления и показываю в своей системе… то почему я не могу получать уведомления?

или 10 секунд это много?
точно мы про ERP говорим в которую загружаются обработанные данные из внешней CRM а не про управление промышленными роботами на сборке подводных лодок?
я каждые 10 секунд собираю эти уведомления и показываю в своей системе… то почему я не могу получать уведомления?

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

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


дешевле держать открытым канал постоянно?
не встречал такого требования до сих пор ни разу…

Какого требования?

держать канал постоянным…

У бизнеса есть требование получать обновления в near-real-time. А у поставщика данных нет исходящих веб-вызовов, только long polling или websockets — вот и все, придется держать открытое соединение.

подключу внешнюю компоненту к платформе 1С и буду держать это открытое соединение.

задача решена.
небольшой адаптер-конвертер на другом языке


Кроссплатформенно и переносимо?
В общем да. Компоненты поддерживают работу на всех платформах, в вебе и на мобиле. В том смысле, что внешняя компонента может работать везде, где перечислил. Разработчик компоненты должен, естественно, про это помнить.
… и должен собрать компоненту под каждую платформу и упаковать все собранное в бандл.

Это очень далеко от «написал на встроенном языке один раз и заработало везде одинаково».
«написал на встроенном языке один раз и заработало везде одинаково»

А кто это анонсировал? Есть возможность написать компоненту, которая под одним интерфейсом «спрячет» работу с нативным API нужной ОС. При этом на тех осях, где компонента есть — будет работать одинаково, с точностью до реализации компоненты.
Очевидно, что автору компоненты надо будет приложить некоторый набор усилий. Если полная кроссплатформенность не нужна — ситуация пропорционально упрощается.
За чудеса кто-то обязательно должен заплатить, бесплатные чудеса — это фантастика :)
Здесь нет работы с нативом, здесь в чистом виде костыль для компенсации архитектурного недостатка рантайма.

Я в очередной раз напомню, что речь о очень банальной задаче.
Т.е. если (например) .NET «из коробки»(!) не имеет объекта для плана видов характеристик (выражаясь 1с-ской терминологией) — то это будет архитектурный недостаток рантайма и реализация аналога на #-языке или любом другом — будет костыль, я правильно понял? А речь идет о банальной задаче (для 1с-ской платформы).

Нет, неправильно. Для реализации любого из объектов конфигурации на .net мне не нужно писать внешний компонент и подключать его через com, хотя это и возможно.

Здесь нет работы с нативом, здесь в чистом виде костыль для компенсации архитектурного недостатка рантайма.

Я в очередной раз напомню, что речь о очень банальной задаче.


При чем тут native? Это же платформа а не голый язык.

Вы сравниваете теплое с мягким.

Это не язык универсального назначения, а узкозаточеная среда.

Вас же не смущает отсутствие в тех языках встроенных СУБД, которая есть в 1С?

Я перестал понимать чего вы от меня хотите.

Моя позиция по поводу сравнения теплого с мягким есть вот тут — habr.com/en/company/lsfusion/blog/468415/#comment_20703735 и ниже по ветке.

Если вы меня хотите убедить, что 1С — это хорошо, так я с этим не спорю, 1С все еще лучше большей части ERP-платформ с которыми я сталкивался.

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


… и должен собрать компоненту под каждую платформу и упаковать все собранное в бандл.

Это очень далеко от «написал на встроенном языке один раз и заработало везде одинаково».


Это задача автора внешней компоненты. Рассматривайте ее как библиотеку в других языках. И забота о переносимости библиотеки — это забота автора той библиотеки.

На 1С-то код будет один и то же.

P.S.:

А что? В каком то другом языке это не так? Ну скажем, если вы пишете код на каком нибудь Flutter (кросс-платформенное решение для Android/iOS, использует язык Dart), то адаптеры для iOS и Android для вас кто то написал 2 раза. А уже сверху обертка под Flutter одинаковая, ага.

Стоп, но ведь это я — автор внешней компоненты, потому что мне приходится ее писать для решения именно моей задачи.
Это да, поэтому и имеем — YellowRabbit и PinkRabbit :)
И в дарте есть нормальные async/await, которые мы и обсуждаем. А уж что в асинхронный код запихивать, работу с ОС, окружением, библиотекой, своим кодом — пофиг. Что угодно можно закинуть. А был бы подход как в 1с было бы все равно что для каждого вызова к API бека пришлось бы платформенные библиотеки писать для обеспечения асинхронности, вместо использования встроенного механизма.
опять же — вопрос в практических задачах.
вы на мобильном устройстве планируете в ERP поддерживать непрерывное соединение с биржей?

вы точно ERP разрабатываете?
а кроссплатформенность есть везде кроме 1С в современном мире?
.net одинаково работает под мак, линус, виндос, андроид и нокию3310?

прям вот кросплатформеннокросплатформенно?

извините за вопрос, я просто 1Сник и мне интересно — если 1С есть под все платформы то наверное более серьезные языки тоже под все платформы есть? как мне js запустить на маке? я должен какие то костыли типа вебсерверов ставить или что?
1с под мобилками работает ровно через одно место. Уж поверьте мне, человеку который мобильным приложением на 1с год занимался почти фуллтайм. Это не назвать кроссплатформой.
З.Ы. для js достаточно node.js где угодно, ровно так же как и 1с ставить нужно, или java, если мы про «интерпретируемые языки». Веб сервера вообще ни при чем (js вообще изначально клиентский язык и с веб сервером дело имел только как клиент).
ну так и я про то говорю — нет такого языка программирования который содержал бы в себе только лучшее из всех остальных языков программирования и мог бы решать все все все возможные практические и теоретические задачи :)

на 1С я могу вот прямо сейчас к своему маку подключить айфончик и на него выгрузить простейшее приложение прямо из платформы а затем его же на андроид выгрузить и отправить с этим андроидом кладовщика инвентаризацию проводить на складе или выдать его водителю чтобы он доставку отмечал и фоткал получателя…

понятно что я на 1С не напишу пубг… — но 1С то не для этого делалась…
Мы здесь говорим про конкретную функциональность, а не про все возможности разных языков/платформ.
ну так я у вас и спрашиваю:

Можно ли в платформе 1С реализовать асинхронное выполнение задач?

а вы увиливаете от ответа и начинаете рассказывать про количество строк кода, неудобство разработчика (словно мне как заказчику не насрать на удобство разработчика) и прочее прочее прочее…
Выше ответил. И да, вы не заказчик, вы разработчик. Но даже заказчику не пофиг если вы можете ускорить свою работу и повысить ее качество благодаря более высокоуровневому языку.
вы не отвечаете упорно на простой вопрос:

Есть ли в платформе 1С асинхронность или нет?

ну простой вопрос, имейте смелость на него ответить прямо без увиливания…
потому что во первых меня интересует ваш и лично ваш ответ на поставленный вопрос.

а во вторых (это мое субъективное мнение), авторы настолько некомпетентны и предвзяты что у них заголовок главы противоречит содержимому этой самой главы и в целом вся статья переполнена непониманием целей и задач платформы 1С или прямой ложью.
словно мне как заказчику не насрать на удобство разработчика

Если вам насрать на удобство разработчика, то и ему насрать на ваше удобство в пользовании системой. Справедливо?

конечно справедливо.
только деньги плачу я и этот разрабочик которому насрать на мое удобство как заказчика — идет в долгое пешее и приходит другой разрабочтик который понимает что тот кто платит тот и заказывает музыку… а если очень хочется труъкодинга — то можно и дома ковырять ассемблер, бейсик, паскаль и ласкать прочих питонов сколько его программистской душе угодно…
приходит другой разрабочтик который понимает что тот кто платит тот и заказывает музыку…

Это очень, очень нездоровое отношение к работе. И, пока это в пределах моих возможностей, я с такими заказчиками дела не имею.

это как раз здоровое отноешние.
если я нанимаю уборщицу — ее дело убираться в офисе а не указывать мне как я столы и стульяв офисе ставлю и как я бизнес веду…

если я нанимаю разработчика — его дело по ТЗ реализовывать, требования к интерфейсу и юзабилити в котором я прописываю как заказчик… если разработчик НЕ СПОСОБЕН мне это обеспечить — он значит не выполняет требования ТЗ… ну и далее идет лесом и нанимается более профессиональный и смышленый разработчик…
если я нанимаю уборщицу — ее дело убираться в офисе

Кстати. Если вы уборщике скажете "ничем, кроме веника, никогда не пользоваться" — возможно, вам придется искать себе другую уборщицу.


его дело по ТЗ реализовывать, требования к интерфейсу и юзабилити в котором я прописываю как заказчик…

Вот и получите сделанное строго по ТЗ. В ТЗ же обработка ошибок не прописана? Не будет обработки ошибок. Вот такая, такая и такая исключительные ситуации не прописаны? Не будут обработаны.


нанимается более профессиональный и смышленый разработчик

Я подозреваю, что у нас с вами разное понимание профессионализма применительно к разработчикам.

интеграции с внешними CRM пишут те у кого нет своей собственной CRM :) :) :)

… или те, кто готов продать ERP тем, у кого уже есть поставленная CRM, вместо того, чтобы потерять сделку из-за неспособности синтегрироваться.

так у них же есть и REST API и SOAP API…

в чем проблема их использовать?
и на 1С наработки есть — садятся 1Сники и пишут обмен…

в чем проблема их использовать?

В том, что это pull-модель, а заказчик хочет push.

push уведомления у меня из коробки в типовой бухгалтерии 3.0 реализованы :)
в принципе работа с пушами…

Salesforce — если надо через вебсокеты подключу если вдруг реста или соапа будет не хватать.

платформа позволяет.
примеры выше были

платформа позволяет.
примеры выше были


salesforce streaming api не поддерживает вебсокеты.
Salesforce — если надо через вебсокеты подключу

Это если вы найдете у Salesforce публичный интеграционный API на вебсокетах. Я лично его не видел.


если вдруг реста или соапа будет не хватать.

А на ресте или соапе нельзя сделать push-модель.


платформа позволяет.

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

ну значит будет внешний компонент. один из плюсов платформы что если в ней чего то нет — можно пользоваться внешними компонентами…

не понимаю почему вас это печалит…
вы хотите чтобы например драйвера всех видов торгового оборудования были внутри платформы прям из коробки? зачем?

salesforce streaming api — пример явно нетипичный и сворее как раз являющийся исключением… чтобы в тз было строго streaming api и нельзя было рест сервис юзать — еще раз… 1С весьма практично подходит к добавлению «плюшек» в систему. Если бизнесом не востребовано — оно не появится в платформе… а редкие исключения — внешние компоненты.
один из плюсов платформы что если в ней чего то нет — можно пользоваться внешними компонентами…

А я-то привык это данностью считать, а для вас это "плюс" оказывается.


не понимаю почему вас это печалит…

Меня печалит, что язык в самой платформе недостаточно мощный.


вы хотите чтобы например драйвера всех видов торгового оборудования были внутри платформы прям из коробки?

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

А я-то привык это данностью считать, а для вас это «плюс» оказывается.


для нас это данность…

Меня печалит, что язык в самой платформе недостаточно мощный.


язык достаточно мощный для решения тех задач которые ставят перед платформой.

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


возьмите внешний компонент и пользуйте…
а «написать его платформе» — сразу вспоминается картинка про троллейбус из буханки… «но зачем?»
для нас это данность…

… сказал человек, который комментарием выше написал "один из плюсов платформы".


язык достаточно мощный для решения тех задач которые ставят перед платформой.

… вот например сделать real-time интеграцию с Salesforce.


возьмите внешний компонент и пользуйте…

А если его нет?

… сказал человек, который комментарием выше написал «один из плюсов платформы».


я же не для себя писал про «один из плюсов платформы» а для вас… откуда я знаю данность для вас или нет то что в 1С еще со времен 7.7 можно было цеплять внешние компоненты и в техдокументации к платформе методики разработки оных прописаны отдельной главой?

вот например сделать real-time интеграцию с Salesforce.


будет реальная задача сделать — сделаю… подключу внешнюю компоненту и сделаю…

А если его нет?


напишу сам или напишет подрядчик…
в 1С еще со времен 7.7 можно было цеплять внешние компоненты

(невинно) а до 7.7 было нельзя?


подключу внешнюю компоненту и сделаю…

Подождите, мы же только что сказали про язык и платформу, никаких внешних компонентов.


напишу сам

Вот это меня и расстраивает: вместо того, чтобы писать на одной платформе все, я должен что-то писать на платформе, а что-то — во внешних компонентах. Эм… но зачем?

(невинно) а до 7.7 было нельзя?


не вникал. я с 1с лет 15-20 работаю, с 7.7 начинал и что там было до 7.7 не особо мне интересно — если вам интересно, то гугль вам в помощь…

Подождите, мы же только что сказали про язык и платформу, никаких внешних компонентов.


это вы так сказали… а у меня в платформе есть специальные методы для подключения компонент и документация на эту тему… т.к. разрабочики платформы вменяемые люди и понимают что когда потребуется экзотическая задача — ее можно будет решить в частном порядке через внешние компоненты и усложнять платформу ненужными сущностями «на всякий случай» нет смысла…

платформе все, я должен что-то писать на платформе, а что-то — во внешних компонентах. Эм… но зачем?


потому что вы приходите на работу кодить и красивый код писать а я прихожу деньги зарабатывать и учетные пробемы решать посредством внедрения и адаптации учетных систем…

ps: а драйвера к принтерам вы сами пишите?
операционка у вас надеюсь лично и самостоятельно написана? браузером небось не стыдно чужим пользоваться, не печалит чужой плагин в браузере который рекламу режет?

ну глупо же… ЗАЧЕМ мне тратить мое время на написание условного драйвера подключения к станку если во первых его пишет производитель станка а во вторых мне за это не платят… а заплатят — я найму подрядчика который сделает это лучше и быстрее меня в соответствии с требованиями к внешним компонентам и я выполню требования ТЗ не смотря на то что «не умеет» своим встроенным языком управлять станком…
а у меня в платформе есть специальные методы для подключения компонент и документация на эту тему…

Еще раз. Меня расстраивает, что есть вещи, которые на платформе написать нельзя. Не то, что их нет в базовой поставке, а то, что их принципиально нельзя написать, и надо идти в другое место.


ЗАЧЕМ мне тратить мое время на написание условного драйвера подключения к станку

Потому что вам заказали написать систему, которая к этому станку подключается. Вы посмотрите на комментарий выше: вы пишете, что если компоненты нет — вы напишете ее сам, и именно об этом я спрашиваю "зачем".

Меня расстраивает, что есть вещи, которые на платформе написать нельзя


а никто никогда не утверждал что на платформе 1С можно написать ВСЁ… если вы вообразили это сами себе — ну так это лично ваши фантазии…

вам наоборот всю дорогу говорят что 1С это узкоспециализированное решение для определенного круга задач…

вы пишете, что если компоненты нет — вы напишете ее сам, и именно об этом я спрашиваю «зачем».


я же там писал что либо сам (если мне это выгодно финансово) либо напишут подрядчики…

извините, когда мне надо зуб полечить я сам себе зуб не лечу — я доверяю профессионалам… даже если я сам врач и опытный хирург… это называется «специализация»
а никто никогда не утверждал что на платформе 1С можно написать ВСЁ…

Это как-то меняет то, что меня это расстраивает?


я же там писал что либо сам (если мне это выгодно финансово)

Вот именно это меня и расстраивает: для решения пришедшей от заказчика задачи нужно писать в двух разных местах.


извините, когда мне надо зуб полечить я сам себе зуб не лечу — я доверяю профессионалам…

У меня создается ощущение, что вы не считаете себя профессиональным разработчиком. Это… любопытно.

это точно задача из мира ERP?
может еще что-нибудь типа управления ядерным реактором на 1С повесим?

ps: почему вы считаете что регламентные задания не справляются без костылей?
я не очень понял вашу мысль.

есть отказ от модальных окон и переход на асинхронные вызовы в том же хромиуме…
1С эти все возможности ради сохранения совместимостей и универсальности поддерживает и реализует — то есть как платформа предоставляет методики и инструменты для реализации асинхронности…

авторы загоняют что «отказ от синхронности это плохо»

авторы не пишут что «нам не нравится программировать на бейсике переведенным промто и вообще можно было сделать проще и слишком сложно» — они пишут прямым текстом что одна из 21 причи почему не 1С — это ОТКАЗ ОТ СИНХРОННОСТИ

то есть тут авторы либо намеренно лгут либо пытаются за минус выдать то что минусом не может являться по определению…
Я там ниже писал, как я понял авторы пишут что отказ от синхронности с т.з. программиста — вот это плохо. Т.е. как раз вместо того чтобы ввести асинк/авейт, корутины или что то подобное что позволило бы писать в прежнем стиле асинхронный код как синхронный — 1с решили не заморачиваться и сделать уныло.
ну то есть вся претензия не в том что ОТКАЗ ОТ СИНХРОННОСТИ ЭТО ПЛОХО а в том что 1С как всегда пошла своим путем вместо копирования других языков?

В том что 1с это сделали через одно место и разработчику добавили проблем, вместо того чтобы их снять.
Посмотрите на дарт или котлин и как там асинхронность реализуется.


ага… вы их еще заставьте посмотреть реализацию работы с коллекциями через linq+лямбда

это же можно на 1с просто в суд подавать — пусть компенсируют разработчикам бесцельно потраченные годы на работу с выборками
ну то есть вы называете некий метод который для решения задачи которую в 1С решают другим методом и говорите что в 1С что то там плохо потому что нет именно вашего метода из другого языка другого уровня программирования?

где логика?

+ а где то сравнение есть чтобы посмотрел и сказал что да, так и есть и 1С в отстое?

а то вот авторы статьи пишут что 1С вообще плохая так как ОТКАЗАЛАСЬ ОТ СИНХРОННОСТИ… и у них вообще нет управления серверными вызовами… а вы мне тут про async/await и прочие лямбды заливаете…
Что им мешает дать возможность разработчику самому задавать имена таблиц и полей, я до сих пор не понимаю.

Незачем усложнять, потому что вы можете решить штатными средствами эту проблему:

без необходимости гадания, что же это за поля и таблицы — _Fld16719 и _Document5759

Вы можете штатными средствами языка 1С узнать названия таблиц СУБД, в которых лежат эти объекты.

Если уж вы собрались это все выгружать в OLAP, то скормить загрузчику таблицу со списком соответствий — это меньшая из проблем, что вас ожидают.
Ознакомился со статьей. Фьюженовцы давно грозились её написать, и я со страхом ждал этого дня, ибо механизмы 1С сейчас настолько универсальны (а всем, как известно, на сто процентов не угодишь; чем-то да приходилось жертвовать), что при желании можно напридираться страниц на сто, а не прочитать очередные вирши коллег из братской Беларуси я не мог — все-таки уровень компетенции в теории бизнес-приложений они демонстрируют приличный, и насколько бы корректным ни было их мнение о платформе конкурентов (а для формирования даже поверхностного взгляда надо потратить немало времени и энергии), в любом случае мне лично любопытно, что видит профессионал со стороны, когда заглядывает за блестящую ширму, которую 1С'ники показывают заказчикам и рядовым пользователям.

А тут очень даже лаконичная статья. Строго структурированная и сжатая. Так что спасибо.

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

Да, мы знаем свои слабости, в частности отсутствие готовых многофункциональных решений для производства и финансов, ну и некоторые вещи в плане «последней мили» в разработке можно было докрутить. Но и сильные стороны тоже знаем.

В любом случае хотелось поделиться свои мыслями и видением, а некоторые восприняли эту статью чуть ли не как личное оскорбление.

Ну и да, никто не считает, что 1С (и другие) разработчики все бросят и завтра перейдут на lsFusion. Это всегда долгий и нудный процесс, занимающий порой десятилетия (как было с SQL в свое время). Нам на самом деле важнее фидбек по упомянутым в статье проблемам перед выходом на мировой рынок и понимания того, на что там делать акценты. Возможно, конечно, этот фидбек будет не настолько релевантным, но наличие такой информации все равно лучше ее отсутствия.
если с 1С что-то случится, они пойдут на улицу милостыню просить.


ну что-то в этом есть, да… идти им будет особо некуда. ибо за пределами языка и фреймворка 20-ти летней давности вообще IT не знают. но с самомнением… часть народу еще твердо уверено, что бухгалтерский самолетик или fifo — это какое-то сокровенное знание, доступное только им. эту песню гагарин лично пел в космосе упр. формы это невероятное достижение 1с, текущая реализация асинхронности — даст ист фантастиш, мы тоже «можем в git»…

когда на пальцах объясняешь, что «всё не так ребята» и «вас уже 20 лет водят по пустыне» — начинаются наскоки, самое веселое — от людей по сути некомпетентных, не владеющих ничем кроме «конструктора запросов» и слаще брюквы ничего не евших

На мой взляд написать подобную статью имеет право только человек, который плотно работает с 1С не один десяток лет. Я написал в 2014 году заметку habr.com/ru/post/244885 (которая является ответом на одну из перечисленных вами статей). Могу сказать что из указанного в моей статье перечня — п. 5.5, 5.6 и 5.8 более не актуальны.
Я зашел на ваш сайт и посмотрел демо веб-приложения ERP на базе isFusion. Начать можно с того, что 1С очень много логики работы с формой выполняет на стороне клиента. В вашем решении нажатие на любую кнопку приводит к вызову сервера.
Знаете почему 1С так популярна — потому что за небольшие деньги она предоставляет невероятный объем функциональности. Это касается как платформы, так и флагманской конфигурации — ERP.
Ваша статья понравится хейтерам 1С, коих на данном ресурсе предостаточно. Специалистам по 1С она вряд ли будет интересна, так как многие из вещей которые вы пишите для них проблемой не является.
В вашем решении нажатие на любую кнопку приводит к вызову сервера.

Ну, во-первых, далеко не любую. Только при потере фокуса или начале ввода. И в обоих этих случаях все равно скорее всего придется обратиться к серверу за какими-нибудь данными (получить цены скажем и т.п., конечно если форма не максимально примитивная). К слову вы когда в гугле или браузере набираете любой текст, браузер тоже постоянно обращается к серверу. И тут важен второй момент — этот вызов асинхронен. То есть пользователь его все равно не видит. Поэтому оптимизация клиентских операций это во многом экономия на спичках, на масштабируемость и производительность это влияет очень слабо (хотя и на lsFusion это можно сделать). А вот проблем в разработке создает очень много о чем и сказано в статье.
потому что за небольшие деньги она предоставляет невероятный объем функциональности. Это касается как платформы, так и флагманской конфигурации — ERP.

Про ERP ничего не скажу, но что касается платформы. 3600 рублей за рабочее место это небольшие деньги? Причем разработчику по факту все приходится делать руками (от управления данными формы до оптимизации запросов), да и еще и разбираться с тучей текущих дырявых абстракций?
так как многие из вещей которые вы пишите для них проблемой не является.

Ну это потому что они с нормальными технологиями не работали, о чем правильно написал pauls0 в комментарии выше.
но что касается платформы. 3600 рублей за рабочее место это небольшие деньги?

удивительно, но да, это реально небольшие деньги. Или вы рассматриваете как ЦА — ларёчников?
Ну, во-первых, далеко не любую. Только при потере фокуса или начале ввода

Давайте на конкретном примере. Укажите документ вашей ERP, где я могу сделать значимое действие без обращения к серверу. Пока я вижу, что после открытия формы документа «Заказ клиента» — клиентское приложение каждую секунду обращается к серверу вообще без какой либо активности.
А вот проблем в разработке создает очень много о чем и сказано в статье.

Нет никаких проблем, разработчик на встроенном языке сам управляет что выполняется на сервере, а что на клиенте и соответственно может управлять объемом передаваемых данных. То есть код на языке 1С для веб-клиента транслируется в javascript, а в остальных случаях выполняется транслированный из встроенного языка p-code.
Про ERP ничего не скажу, но что касается платформы. 3600 рублей за рабочее место это небольшие деньги

Полнофункциональная пользовательская лицензия Navision стоит 3000$, аксапта еще выше
Ну это потому что они с нормальными технологиями не работали

Приведите пример ERP-системы построенной по вашему мнению на нормальной технологии? Неужели isFusion? Разрабатывать формы кодом это простите — анахронизм. Да мне на django веб-приложения проще разрабатывать — там есть хотя бы html шаблон.
Разрабатывать формы кодом это простите — анахронизм

Мне искренне жаль всех frontend разработчиков, которые пишут на React и Angular. Оказывается, они занимаются анахронизмом.
Остальное спорно и в длинные холивары вступать не хочу, но по поводу вот этого
Разрабатывать формы кодом это простите — анахронизм.

просто не могу в стороне остаться. Описание UI кодом наиболее удобный для поддержки (анализ изменений, выяснение авторства правок, объединение и т.п.) а так же для выделения общих UI абстракций способ. А еще лучше комбинированный подход с возможностью иметь рядом с описанием UI кодом так же превью и/или визуальный редактор свойств UI элементов.
Не нужно путать разработку и кастомизацию. Если я разрабатываю с 0 некоторый документ — мне это разумеется удобней делать с помощью визуального редактора. Если речь идет о кастомизации документа, сделанного поставщиком — с помощью кода или например с помощью макета изменений, как например предлагается тут infostart.ru/public/1085508
Я и для разработки чаще предпочитаю текст, но тем не менее лучше всего когда из коробки хорошо поддерживаются оба режима. Кстати, в 1с программное изменение форм эти сами формы дольше грузится заставляет, что большой минус и ограничение.
Попробуйте кодом разработать форму в которой несколько сотен элементов, у каждого куча свойств. Сможете ли вы это поддерживать?
Корректировка формы делается только первом открытии. Разумеется это займет некоторое время, но опять-же не критично. Не понял в чем ограничение? Хотите максимальной скорости и проблемы при обновлении — редактируйте форму поставщика, хотите обычной скорости и без проблем при обновлении — вносите изменения кодом или макетом.
Попробуйте кодом разработать форму в которой несколько сотен элементов, у каждого куча свойств. Сможете ли вы это поддерживать?

Последнее время на постоянной основе этим занимаюсь, подсказка: выделение абстракций и декомпозиция. К тому же указываются не все свойства каждого элемента, а только те что отличаются от стандартных значений, а таких обычно не больше нескольких штук.
Причем даже на 1с видел удобные абстракции для верстки очень больших форм через код, другое дело что из за ограничений языка не всегда ими было удобно пользоваться.

Ну а чтобы получить обычную скорость и без проблем с обновлениями — можно было бы сделать нормальную поддержку редактирования разметкой/кодом.
Попробуйте кодом разработать форму в которой несколько сотен элементов, у каждого куча свойств. Сможете ли вы это поддерживать?

Да.


Еще и потому, что "разработка кодом" совместима с произвольным хранилищем версий, что поддержку упрощает.

Если разработку приложения для 1С вести на EDT — формы выгружаются в XML и прекрасно работают с тем же Git. Кроме того платформа позволяет формировать интерфейс кодом, но это при наличие визуального редактора извращение. В том же Django есть поддержка шаблонов и у меня никогда не возникало идеи формировать HTML программно.
Видел я тот xml, лучше не нужно. Тем более что править его руками без поддержки IDE не выйдет нормально. Вы так говорите как будто кто то предлагает вам в блокноте формы писать. Текстом — не значит без поддержки IDE.
Если разработку приложения для 1С вести на EDT — формы выгружаются в XML и прекрасно работают с тем же Git.

… главное, не забывать это постоянно синхронизировать туда-обратно.


Я, собственно, несколько лет работал с подобной системой (не с 1С), и это было весьма неудобно.


Кроме того платформа позволяет формировать интерфейс кодом, но это при наличие визуального редактора извращение.

Не все, что вам неудобно и непривычно — извращение.


у меня никогда не возникало идеи формировать HTML программно.

А у меня тут неподалеку сидит некоторое количество фронт-энд разработчиков, и они именно так его и формируют… удивительное дело.

Пока я вижу, что после открытия формы документа «Заказ клиента» — клиентское приложение каждую секунду обращается к серверу вообще без какой либо активности.

Каждую секунду она обращается чтобы проверить связь с сервером (и заранее сообщить что оно потеряно), и получить возможно асинхронные события от него (скажем сообщение с уведомлением). Если захотеть то можно отключить эти обращения, если вы мне ответите зачем?
Нет никаких проблем, разработчик на встроенном языке сам управляет что выполняется на сервере, а что на клиенте и соответственно может управлять объемом передаваемых данных. То есть код на языке 1С для веб-клиента транслируется в javascript, а в остальных случаях выполняется транслированный из встроенного языка p-code.

Так в этом и проблема, что вместо того чтобы решать бизнес-задачу, ему приходится заниматься какими-то техническими вещами, что на сервере, что на клиенте должно выполняться, с контекстами / без контекста? Зачем? Ради экономии на спичках? Ни в SAP ни в Axapta ни в lsFusion этого нет, а они отлично работают и на огромных объемах / количестве пользователей.
Полнофункциональная пользовательская лицензия Navision стоит 3000$, аксапта еще выше

А .Net, Python, lsFusion — 0$. И 60$ за пользователя по сути ни за что, мягко говоря дороговато.
Приведите пример ERP-системы построенной по вашему мнению на нормальной технологии? Неужели isFusion? Разрабатывать формы кодом это простите — анахронизм. Да мне на django веб-приложения проще разрабатывать — там есть хотя html шаблон.

HTML — шаблон это тоже код. И вы же понимаете, что разработка УФ это тоже по сути код. Там только структура контейнеров мышкой задается (снизу форма readonly, если что), и это как раз анахронизм (все эти конструкторы это привет 2000). Сейчас все современные фронтенды (например React) кодом задаются.
Если захотеть то можно отключить эти обращения, если вы мне ответите зачем?

В платформе 1С клиент хранит все редактируемые данные, поэтому отключение сервера для него вообще не проблема. Вы можете выключить компьютер, потом включить и запостить документ в систему. Во время работы с формой может произойти переподключение вообще к другому серверу.
Ни в SAP ни в Axapta

А разве в них есть веб-интерфейс? Эти решения предназначены для локальной сети, в которой разницы с местом выполнения клиентской логики вы не заметите. Если вам не нравится это разделение — можете каждое клиентское событие (с некоторыми исключениями) передавать на сервер и не думать об этом.
В платформе 1С клиент хранит все редактируемые данные, поэтому отключение сервера для него вообще не проблема. Вы можете выключить компьютер, потом включить и запостить документ в систему. Во время работы с формой может произойти переподключение вообще к другому серверу

А что с серверными вызовами будет происходить во время отключения сервера? Например при нажатии выбрать из списка? И вы же понимаете что хранение всех редактируемых данных создает дикий оверхед, так как их надо гонять туда сюда при большинстве серверных вызовов? И это гораздо хуже чем любой маленький асинхронный вызов.
Вы можете выключить компьютер, потом включить и запостить документ в систему. Во время работы с формой может произойти переподключение вообще к другому серверу.

Можете попробовать сделать тоже самое в lsFusion, например выключите сеть (или переведите в спящий режим), подождите полчаса и увидите связь восстановится.
Если вам не нравится это разделение — можете каждое клиентское событие (с некоторыми исключениями) передавать на сервер и не думать об этом.

Это как? Мне надо считать данные на сервере, вызвать диалог, потом обработать данные и в зависимости от условий вызвать другой диалог. В статье есть пример, в нормальном языке это 5 строк кода, как это в 1С сделать.

И да у них обоих есть web-интерфейс.
А что с серверными вызовами будет происходить во время отключения сервера? Например при нажатии выбрать из списка?

Клиент ругнется, и выведет окошко с таймером и кнопками повторить и завершить. После восстановления соединения с сервером (вроде так же и при перекидывании сессии на другой сервер кластера) — работа пользователя продолжится.
И вы же понимаете что хранение всех редактируемых данных создает дикий оверхед, так как их надо гонять туда сюда при большинстве серверных вызовов? И это гораздо хуже чем любой маленький асинхронный вызов.

Гоняются между сервером и клиентом только диффы состояний.
Ну так lsFusion делает все тоже самое.

Тока я тогда не понимаю зачем нужен НаСервереБезКонтекста? Ведь какая разница каким вызовом придет дифф? Это важно, только если идет массовое изменение клиентских данных с постоянными серверными вызовами по идее. Но это по определению криво, поэтому непонятно зачем это поощрять.
НаСервереБезКонтекста нужен когда точно известно что нет необходимости дифф гнать на сервер. Допустим на клиенте изменили часть данных формы (как пример добавили в таблицу 200 строк объемных), но для дозаполнения или дорасчета нужно что то дополнительно с сервера запросить. Вот чтобы не гнать заранее 200 строк на сервер, а только в конце работы с формой — и нужен НаСервереБезКонтекста, запрашиваем данные с сервера, на клиенте обрабатываем, дозаполняем строки, выполняем проверки, а дальше форма может как закрыться (и тогда гнать 200..0 строк на сервер вообще не нужно), либо потребоваться контекстный вызов (запись например) — тогда произойдет синхронизация данных через дифф. На самом деле кейсов много, это только кажется что оно не очень нужно, позволяет здорово траффик и количество вызовов экономить (особенно это важно на каком нибудь EDGE соединении, но не только).
То есть они в принципе поощряют лишние серверные вызовы? И зачем вообще добавлять 200 строк на клиенте? Почему это не сделать на сервере, дозаполнить / дорасчитать и наоборот прислать все данные на клиента одним вызовом. Тогда один round trip нужен. А так у вас несколько вызовов.
То есть они в принципе поощряют лишние серверные вызовы?

Наоборот, до тех пор пока возможно обойтись данными на клиенте — все делается на клиенте, и на сервер лезем только в случае крайней необходимости (по возможности экономя траффик использованием НаСервереБезКонтекста).

И зачем вообще добавлять 200 строк на клиенте

Банальный пример — загрузка данных из xls, csv, json, xml и прочих файлов лежащих у пользователя. Там и тысячи и десятки тысяч строк могут быть. Или например добавление нескольких строк в таблицу где все данные повторяются, меняются только даты/текст.

Почему это не сделать на сервере, дозаполнить / дорасчитать и наоборот прислать все данные на клиента одним вызовом.

Как пользователь введет данные на сервере? Он их вводит у себя на локальной машине, там же выполняются проверки и прочее (часто на клиенте реализуется кеш с данными для этого необходимыми который при необходимости пополняется через внеконтекстный вызов). Итого — просто гигантская экономия трафика и вызовов. Пользователь получает проверки и дорасчеты в реалтайме, вдобавок форма может последний раз с сервером связываться 10-20 минут назад, пользователь при этом постоянно работал с формой и никаких задержек даже на время пинга.
Банальный пример — загрузка данных из xls, csv, json, xml и прочих файлов лежащих у пользователя. Там и тысячи и десятки тысяч строк могут быть. Или например добавление нескольких строк в таблицу где все данные повторяются, меняются только даты/текст.

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

Ну то есть здесь и будут лишние серверные вызовы.
вдобавок форма может последний раз с сервером связываться 10-20 минут назад, пользователь при этом постоянно работал с формой и никаких задержек даже на время пинга.

Для этого достаточно, чтобы вызов был асинхронным. Как например в lsFusion подборе пользователь может ходить вводить значения, а цены, количества в упаковки, добавление в документ и т.п. идет асинхронно на фоне. Связь потеряется они просто в очередь выстроятся и как только связь появится — дойдут. И это все может делать платформа.
Так а почему просто не переслать в заархивированном виде эти файлы на сервер и там разобрать

А потом передавать на клиент для отображения/редактирования пользователем. Двойные накладные расходы даже если пользователь в итоге передаст эти данные на сервер, а ведь он может 80% загруженных данных в итоге вовсе удалить (даже если забыть о том что данные могут быть изначально избыточными). В итоге имеем либо десятки мегабайт траффика, либо несколько килобайт — разница есть?
Ну то есть здесь и будут лишние серверные вызовы.

Серверных вызовов тут не будет вообще. Все данные загружены в кеш на клиенте, и в реалтайме все проверки и расчеты выполняются на этих данных.
Для этого достаточно, чтобы вызов был асинхронным. Как например в lsFusion подборе пользователь может ходить вводить значения, а цены, количества в упаковки, добавление в документ и т.п. идет асинхронно на фоне. Связь потеряется они просто в очередь выстроятся и как только связь появится — дойдут. И это все может делать платформа.

Вы все таки не поняли о чем я говорю. Пользователь вообще не потеряет в функциональности. Вот вообще. Все проверки будут выполняться, все расчеты дорассчитываться, и не когда то там через пару-десяток секунд (при плохой связи), а моментально, прямо в момент ввода.
Вообще мы рассматриваем частный случай и кейсов сильно больше чем загрузка данных и дозаполнение с проверками.
Я в целом с вашей критикой 1с согласен, как вы могли уже понять наверно из всех моих комментариев к этому посту (коих подозреваю уже сильно за 50 штук тут), но вот в данном вопросе по моему мнению вы сильно промахиваетесь.
Да, этот механизм 1с был бы удобнее не в виде обязательных требований а в виде опциональной функциональности — но она довольно полезна и нужна.
А потом передавать на клиент для отображения/редактирования пользователем. Двойные накладные расходы даже если пользователь в итоге передаст эти данные на сервер, а ведь он может 80% загруженных данных в итоге вовсе удалить (даже если забыть о том что данные могут быть изначально избыточными). В итоге имеем либо десятки мегабайт траффика, либо несколько килобайт — разница есть?

Так а что с серверными данными? Допустим вы импортируете xml, там в любом случае только примитивные данные. По ним надо будет так или иначе найти «живые» данные. То есть например все импортированные штрих-коды передать на сервер, там найти товары, и передать их наименования назад на клиента. Точно также после импорта скорее всего надо подставить цены и т.п. Просто мы много писали импортов и там ВСЕГДА от сервера что-то нужно (не физически, а логически). То есть
моментально, прямо в момент ввода.

В любом случае потребует серверный вызов.

Плюс вы так и не ответили на:
Плюс полагаться на клиента неизвестной конфигурации в принципе (может там очень слабый процессор или памяти мало) очень странно.

То есть выполняя тяжелые операции на клиенте вы обречены на шквал звонков: а чего у меня так медленно, ой все упало (памяти не хватило) и т.п.
Допустим мы загрузили кучу примитивной инфы. Допустим (не всегда это нужно, и не всегда нужно сразу) затем мы эту инфу одним вызовом отправляем на сервер (только то что нужно, без лишних данных) и получаем результат обработки (в этом же вызове получаем для клиента данные которые кладем в локальный кеш).
Дальше пользователь например вносит какие то правки, код с бизнес логикой на клиенте лезет в этот локальный кеш на клиенте же, делает проверки/обновляет данные в соответствии с действиями пользователя. Ни одного запроса на сервер для этого не нужно, но форма с пользователем вполне интерактивно взаимодействует (проверки на граничные условия данных в текущей строке, проверка на соответствие данным в других строках/полях формы, проверка данных по кешу (и дозаполнение из кеша) — в очень многих случаях можно обойтись 0 обращений к серверу.)
Плюс не забывайте что это один кейс из кучи разных, это как в той ветке с асинхронностью, человек говорил что может кейс реализовать в 1с, абсолютно забивая на то что это общий концепт.
У нас на моей прошлой работе благодаря таким возможностям платформы как то на полном серьезе рассматривалась возможность реализовать онлайн работу клиентов на кораблях в море с бекендом на суше при скорости соединения меньше килобита и пингом несколько секунд. В итоге все таки прикинули что хоть часть форм под такое и можно будет оптимизировать скорее всего, но далеко не все, стоить будет очень дорого, и долго делаться, проще иметь на каждом корабле локальный бекенд и периодически базы с сушей синхронизировать (возможно вообще по прибытию в порт).
То есть выполняя тяжелые операции на клиенте вы обречены на шквал звонков: а чего у меня так медленно, ой все упало (памяти не хватило) и т.п.

Всегда есть ТЗ в случае реализации в рамках проекта (а для коробки тех. документация) где прописываются минимальные требования к клиенту. И нет, обработать пару десятков тысяч строк в ТЧ или получить данные из кеша еще на десяток тысяч элементов — не настолько тяжелые операции). Ну и обычно такие вещи вроде загрузок делаются выделенными лицами, для них требования к АРМ можно и повыше выставить.
Это как разница между нормальными SPA, умеющими в работу с локальными данными, и теми которые на каждое действие по запросу к беку отправляют. Даже учитывая то что запросы асинхронные — пользователи будут дико раздражаться тем что обработка их действий происходит с задержкой (или вообще не происходит, навводили 20 новых строк, а только начали приходить ответы с бека и отображаться пользователю что данные в первой строке некорректные).
Ну ок, допустим он вносит правки, меняет штрихкод, опять-таки нужно сходить на сервер за наименованием и ценами. То есть, да какие-то проверки можно оставить на клиенте, но самые примитивные. Шаг влево, шаг вправо (например проверка в зависимости от того что это за товар) все равно придется лезть на сервер.

То есть да можно придумать какой-то вырожденный случай, как «работу клиентов на кораблях в море с бекендом на суше», но это хорошо если 1% всех случаев. В остальных же это настоящая экономия на спичках.
Всегда есть ТЗ в случае реализации в рамках проекта (а для коробки тех. документация) где прописываются минимальные требования к клиенту.

И всегда есть жизнь, где у клиентов могут быть непонятно откуда взятые рабочие станции, всякие нетбуки, планшеты и т.п. Вещи на которые вам как подрядчику влиять очень тяжело, и если даже заказчик прописал что-то в ТЗ (а это еще надо сильно постараться чтобы его убедить в этом, он скорее от проекта откажется), это не значит, что при том же внедрении он будет по щелчку пальцев будет заменять пользователям рабочие станции (а весь негатив будете получать вы как подрядчик)
Даже учитывая то что запросы асинхронные — пользователи будут дико раздражаться тем что обработка их действий происходит с задержкой (или вообще не происходит, навводили 20 новых строк, а только начали приходить ответы с бека и отображаться пользователю что данные в первой строке некорректные).

Смотрите, если эта задержка двести миллисекунд или даже одна секунда (а даже на edge она вряд ли будет больше), это вряд ли будет так сильно кого то раздражать. Не говоря уже о том, что в 99% при нормальной работе сети затраты на передачу данных уложатся в 50 мс (что неразличимо для человеческого взгляда). 21 век все-таки и дальше с этим все лучше и лучше.
Ну ок, допустим он вносит правки, меняет штрихкод, опять-таки нужно сходить на сервер за наименованием и ценами. То есть, да какие-то проверки можно оставить на клиенте, но самые примитивные. Шаг влево, шаг вправо (например проверка в зависимости от того что это за товар) все равно придется лезть на сервер.

То есть да можно придумать какой-то вырожденный случай, как «работу клиентов на кораблях в море с бекендом на суше», но это хорошо если 1% всех случаев. В остальных же это настоящая экономия на спичках.

Вы сейчас приводите ровно те же аргументы что и ваши противники из лагеря 1с. У нас этого нет — значит не нужно. А то что оно позволяет там 30% траффика сэкономить, там количество вызовов в 2 раза при работе с формой уменьшить при абсолютно повседневной работе в остальных случаях — не замечаете (для такого вообще любая машинка сойдет, это не вырожденный случай с АРМ для загрузки данных выделенным). Прямо как 1сники с непониманием async/await.

Смотрите, если эта задержка двести миллисекунд или даже одна секунда (а даже на edge она вряд ли будет больше), это вряд ли будет так сильно кого то раздражать

Вы очень сильно ошибаетесь. Это очень раздражает. По крайней мере об этом говорит мне мой опыт и опыт моей работы. Я потому и пошел с 1с не в веб фронтенд а в мобайл что в мобайле больше работы на клиенте делается и отзывчивость приложения гораздо выше, мне даже разрабатывать такое приятнее, не то что пользоваться.
У нас этого нет — значит не нужно.

Нет, вы не поняли тезис. Лучше конечно иметь такую возможность. Но именно возможность, а не обязанность. И если выбирать между 97% сделать все автоматически (а зачастую даже гораздо лучше так как исключается человеческий фактор), и в 3% потерять 30% трафика. Или в 100% все делать вручную, я думаю не надо объяснять что лучше.

То есть претензия не то, что они сделали разделение сервера и клиент, а то что они сделали его обязательным, то есть с водой выплеснули ребенка. А 1С все-таки платформа для бизнес-приложений, а не для «техногиков».
Вы очень сильно ошибаетесь. Это очень раздражает. По крайней мере об этом говорит мне мой опыт и опыт моей работы. Я потому и пошел с 1с не в веб фронтенд а в мобайл что в мобайле больше работы на клиенте делается и отзывчивость приложения гораздо выше, мне даже разрабатывать такое приятнее, не то что пользоваться.

Еще раз, я уточнил что в крайних случаях (обычно 50 мс, если вы не в метро работаете). Во вторых асинхронно. И в современных мобильных приложениях, на сервер обращения идут тоже очень и очень часто. В любом случае мы уже ушли от темы.
И в современных мобильных приложениях, на сервер обращения идут тоже очень и очень часто. В любом случае мы уже ушли от темы.

Тем не менее также много бизнес логики остается на клиенте, и это хорошо.

Я кстати выше писал что да, было бы неплохо будь возможность такого разграничения опциональной а не обязательной, но, как бывший 1сник говорю, конкретно к этой части 1с привыкаешь быстро, а экономит траффик и количество вызовов она на 95% задач, другое дело что на большей части этих 95% экономия от 20 до 50%. Если что — я будучи 1сником довольно часто занимался как раз оптимизацией этого дела, и бывало некоторые действия ускорялись в десятки раз за счет таких оптимизаций. Было 2 секунды на действие раздражающее пользователя, стало 0.05 секунд, например. А от того что это были бы 2 секунды действия выполняемого асинхронно и просто выдающего результат (в виде подсветки неправильного значения например) с задержкой — пользователю бы погоду не сделало. А вот 0.05 секунд сильно пользовательский опыт делает бодрее.
> много бизнес логики остается на клиенте, и это хорошо.
Это плохо хотя бы с точки зрения безопасности. Если данные пихаемые в базу, проверяются на клиенте.

> Было 2 секунды на действие раздражающее пользователя, стало 0.05 секунд
Возможно, это из-за проблем с самой 1С, как она пересылает данные, как их обрабатывает, а не каналов связи?
Скажите это компьютерным играм или веб приложениям где валидация проходит как на клиенте, так и на беке. На клиенте для отзывчивости, на беке для безопасности и консистентности.
И потом игровые сервисы банят пользователей, которые немножко подправили код приложения. А тут бизнес-приложения, это не игры. Да и в играх очень важно время отклика, иначе она становится неиграбельной. Бизнес-приложения в этом плане менее требовательные.

И кстати, вы слышали о игровых сервисах, которые сейчас появляются, где игра исполняется на сервере, а клиенту передаётся только видео?
Слышал. А также слышал о тенденции веб приложений уходить в работу на клиенте. Каждой задаче свой инструмент, и иногда бизнес приложению или его части нужно работать в условиях плохой связи. Да и раздражать пользователей лишний раз задержкой реакции приложения — тоже нежелательно.

Я немного застал разработку на 1с без этого разделения на клиент и сервер (правда там многое вообще на клиенте выполнялось из того что должно выполняться на сервере, что вообще ужас), но с точки зрения удобства написания кода — и тот и тот вариант после некоторой адаптации практически равнозначны. Накладные расходы на разработку от силы несколько процентов от этого разделения добавляются.
и тот и тот вариант после некоторой адаптации практически равнозначны

Танцы с ВременнымХранилищем не видели в типовых? Или требований ТаблицыЗначений на клиенте?
Видел и даже сам реализовывал механизмы где это нужно. Согласен что заметное неудобство и накладные расходы конкретно на этот вариант больше чем просто код поделить, но тем не менее после того как в паттерн применения въезжаешь — танцы с ним реализуются в считаные минуты. При том что использование редкое вполне, на конфигурацию несколько мест обычно всего и в них влезать не приходится практически. Хотя да, конкретно тут неудобства добавляется. Кстати я вдруг вспомнил что это в 1с как раз способ шарить объекты между потоками)) Что иногда источник ошибок)
Если пинг пол секунды то хоть убейтесь — не будет у вас моментальной отзывчивости. Пользователю придется секунду ждать окончания работы валидации на сервере.
Вообще на синтетических примерах это обсуждать сложно, всегда можно сказать что «здесь можно было по другому» или «это пользователю не нужно». Та же фигня когда 1сники говорят что async/await не нужно, можно писать синхронно, все равно в 99% случаев пользователю нужно дождаться результата операции прежде чем идти дальше, а 1% можно и руками повозиться с неудобным механизмом.
Было 2 секунды на действие раздражающее пользователя, стало 0.05 секунд, например

А какое отношение это имеет к тому, что при завершении / начале ввода идет «лишний» асинхронный вызов? И причем тут разделение логики на сервер и клиент? Может проблема как раз и появилась, потому что это разделение есть, и неопытный разработчик его неправильно использовал?
Там проблема была в том что использовался автоматически сгенерированный код и проверка выполнялась на сервере для каждой ячейки таблицы при каждом изменении строки (бизнес логика такая). Но также проблема могла появиться, например, потому что пинг одна секунда, и никак не придет на клиент результат валидации раньше чем данные туда сбегают и вернутся.
Если пользователь решит заменить какую-то номенклатуру, отсутствующую на складе, на аналог, тоже на сервер не будет вызова? Вы что весь каталог номенклатуры клиенту скачаете? А если какой-то другой пользователь внёс изменения в данные, которые в кэше, придётся качать всё по-новой.

В 1С есть тонкий клиент, и он отлично работает. Есть классическая схема 3-звенки: 1) база данных для хранения и поиска, 2) сервер приложений для бизнес-логики, 3) клиент — для показа пользователю и получения от него команд. Всё остальное от лукавого.
Я вообще очень редко работал со справочником номенклатуры работая с 1с. А вот например список тех. карт ремонтов с некоторыми данными по ним — запросто, очень во многих случаях их количество не превышает нескольких тысяч. Еще раз, это же просто демонстрация, естественно на практике в чистом виде никто в лоб так не делает.
То в чём экономия трафика? Если качать весь каталог или какой-то завязанный к данным справочник.
В том что качаем небольшую часть данных (которые скорее все равно потребуется показать пользователю на форме в итоге), а не бегаем при каждом изменении на сервер. Экономия на накладных расходах.
Как угадать, какие понадобятся, какие нет? Вон современные процессоры, в которых реализована мощнейшая логика предсказания потока выполнения, и то бывает промахиваются мимо кэша и тормозят. Да, грамотный специалист, изучив данные, связи между ними, посидев с пользователем и изучив процесс ввода, может серьёзно оптимизировать работу за счёт кэширования нужных справочников. Внеся требуемые исправления в бизнес-приложение. Раздув и без того спагетти-код. Но может, это проблема платформы, что она изначально неоптимально работает с данными, что это дело требуется потом оптимизировать?
Как показывает практика — «угадывать»(на самом деле нет) удается.
При «загрузке данных из xls, csv, json, xml и прочих файлов лежащих у пользователя», эти данные рано или поздно и так окажутся на сервере. То почему сразу их не отправить на сервер, и потом там же на сервере отпарсить и добавить в базу?
Я так понимаю в случае если пользователь отменит ввод. Только тут вопрос как часто статистически он отменяет этот ввод. И если это 10%, то вы в самом лучшем случае достигнете экономии трафика в 10%, что и есть классическая premature оптимизация.
Не факт что окажутся (пользователь может посмотреть и отказаться), не факт что все (пользователь может посмотреть и часть данных удалить), не факт что в том виде (пользователь может посмотреть и отредактировать). А в базе этим данным до поры до времени делать нечего. Но вообще я выше написал что это скорее пример иллюстрирующий использование такого режима работы на примере где это наиболее показательно и эффективно, обычно решаются менее глобальные задачи и экономится количество вызовов сервера на мелких задачах (3 вместо 10 например) и объем трафика (от 10 до 80 процентов экономия в сравнении если бы все было полностью автоматическим и на сервере, от задачи зависит).
Ну если там половина ненужного, с тем же успехом пользователь может открыть xls у себя в Экселе, удалить лишнее, и потом отправить на обработку.

А трафик (у нас по крайней мере) обычно не оплачивается. Только абонентка. За исключением мобильных пользователей. Ну там по-любому не толстый клиент на смартфоне будет.
Оно может показать что не нужно только после обработки бизнес логикой загрузки. Может хватить уже обсуждать вырожденный случай приведенный чисто для демонстрации? Трафик может и дешевый, но бывает медленный. Вы же не забывайте что 1с часто применяется там где все совсем плохо и дешево.
Я к тому, что если там импортируемые данные действительно очень тяжёлые, и из них по итогу в базу попадает лишь малая часть, то эту оптимизацию можно сделать, пропустив их предварительно через какую-то утилиту на компьютере пользователя. Это тоже оптимизация, но она не усложняет основную программу.

Если же со связью совсем плохо, в 1С есть механизм распределённой БД и планы обмена. Мы когда-то такое использовали, когда сидели на аналоговых модемах. Потом появился ADSL и от этого отказались.

Получается, толстый клиент он болтается где-то посередине между тонким клиентом и распределённой БД. Но требует для себя много внимания со стороны программистов платформы и конфигураций. И усложняет и без того запутанный код.
Я к тому, что это была демонстрация применения механизмов, и иногда (не во всех случаях) иначе не сделать. Например продавая коробку через саму 1с — сторонние утилиты в поставку закидывать ну такое.

А распределенка — дикая дичь, никогда ее не любил, как и вообще 1сные обмены.
Стороннюю утилиту можно подвязать к кнопке на панели 1С. Пользователь даже не будет знать, что это не 1С.
Пользователь знать не будет а 1с будет. Наверно единственный вариант сделать в виде внешней компоненты под все поддерживаемые 1с платформы (разве что для мобилок можно не писать), но это несколько более сложнее чем скрипт на питоне набросать или на встроенном языке 1с накалякать.
Гоняются между сервером и клиентом только диффы состояний.

Откуда информация? Просто в таком случае разницы между контекстным и безконтекстным вызовом, в случае если ничего не поменялось на форме, быть не должно. Но когда последний раз смотрел (давно), она была и заметная.

Контекстная и внеконтекстная передача управления на сервер
При внеконтекстной передаче управления на сервер передаются только те данные, которые явно специфицированы разработчиком в параметрах процедуры (функции) с директивой компиляции &НаСервереБезКонтекста.

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

при этом затраты ресурсов сервера на инициализацию контекста формы оправдываются

Что тут непонятно. Если они шлют дифграммы, то контекст по определению должен хранится на сервере, и соответственно после применения дифграммы новый контекст уже должен быть доступен для использования (то есть ничего инициализировать не надо). Единственное объяснение если они сериализуют этот контекст с оперативной памяти на диск (или куда-то еще) между вызовами, удаляя его из оперативной памяти, но это от такой оптимизации вреда будет больше чем пользы.
На самом деле объяснений придумать немало можно будет и это не единственное вероятное объяснение. У меня есть разные предположения (например переменные с директивой НаСервере каждый раз инициализируются и выполняется код модуля формы, может какие служебные вещи). Кто их знает что они там накрутили.
Контекст формы если что не только данные полей формы и UI часть.

Берем из вашей ссылки:


значения реквизитов формы типа ДанныеФормыСтуктура передается целиком, в случае если изменился хотя бы один из его реквизитов;

и отсюда https://its.1c.ru/db/pubdevguide83#content:550:hdoc :


ДанныеФормыСтруктура – содержит набор свойств произвольного типа. Свойствами могут быть другие структуры, коллекции или структуры с коллекциями. Таким типом представляется, например, в форме СправочникОбъект.

Получаем что при любом контекстном вызове передается весь объект (если хоть что-то в нем поменялось).
И это печально.

А вот тут спорить не буду. Это действительно печально. Другое дело что практически во всех сложных формах объекты такие это лишь малая часть контекста. Остальной контекст касается других реквизитов и тч форм а так же UI элементов.
А что с серверными вызовами будет происходить во время отключения сервера? Например при нажатии выбрать из списка? И вы же понимаете что хранение всех редактируемых данных создает дикий оверхед, так как их надо гонять туда сюда при большинстве серверных вызовов? И это гораздо хуже чем любой маленький асинхронный вызов.

Просто прервется текущий вызов — выведется сообщение об ошибке и все. Между клиентом и сервером передаются только измененые строки и реквизиты. Если изменений нет ничего кроме параметров для вызываемой функции передаваться не будет.
Это как? Мне надо считать данные на сервере, вызвать диалог, потом обработать данные и в зависимости от условий вызвать другой диалог

В платформе 1С исторически есть поддержка модальных окон, но сейчас это bad practice.
И да у них обоих есть web-интерфейс

Пруфы в студию. В SAP веб приложения создаются на NetWeaver, а Axapta с помощью ASP.NET. С основной функциональностью это не имеет ничего общего.
Про вызовы уже ответил выше.
В платформе 1С исторически есть поддержка модальных окон, но сейчас это bad practice.

В 1С и сейчас куча модальных окон. Возьмите например выбор из списка, нижнее окно заблокируется. Но реализовывать это приходится руками. Как разбивать все на клиентские / серверные процедуры с рандомными именами, так и реализовывать через одно место async/await (почитайте верхний спор с IamAlexy). Собственно про это два раздела в статье.
Пруфы в студию.

Тяжело, у того же SAP community еще более закрытое чем в 1С. Но вот например в lsFusion есть web-интерфейс, а разделения на сервер и клиент нет.
Возьмите например выбор из списка, нижнее окно заблокируется. Но реализовывать это приходится руками

Не нужно путать окна, блокирующих окно владельца (это нормально и достаточно передать в процедуру открытия формы параметр или в самой форме установить флаг) и вызов метода ОткрытьФормуМодально. 1С отказалась от использования последнего, т.к. он не корректно поддерживается браузерами. Чем вам не нравится реализация async/await в 1С? Как это реализовано у вас?
А вы не читали гигантскую ветку выше? Там комментариев 150 теме асинхронности посвящено.
У нас как реализовано описано в статье (неявно). Основной посыл, что если все выполнять на сервере, там большое пространство для маневра с потоками / контекстами (соответственно за клиентом остается чистый рендер / события / мелкие оптимизации).
Если под асинхронностью понимать возможность одновременного выполнения нескольких потоков кода на клиенте — то такой возможности нет. Но это ограничение браузеров. Но возможность отвязать момент вызова от момента выполнения есть. А на сервере есть фоновые задания — пожалуйста можете создавать сколько угодно.
Вообще речь шла ровно о классическом кейсе в статье:
Спросить, что-то сделать с данными (серверными в том числе), Спросить, что-то сделать и т.п. И способах реализации:
1) Как в SAP/Axapta/lsFusion (где «основной» flow на сервере)
2) Как в 1С (где «основной» flow на клиенте)
Перечитайте еще раз тот раздел.
Вы так часто употребляете в тексте уничижительные обороты, что не сразу понятно в чем заключается ваша претензия. Если вам не нравится подход с асинхронными вызовами — используйте синхронные, платформа это не запрещает при установленном режиме совместимости. У вас претензия к самому workflow на клиенте? Это ваше мнение. Почему вы считаете его единственно правильным? Нет указателя на функцию — и что? Какие задачи это не позволяет решать? Есть функции Выполнить() и Вычислить(), через которые вы можете вызвать все что угодно? Можно создать структуру с параметрами СтрВызов, в качестве одного из параметров определить имя процедуры и затем Вычислить(«СтрВызов.Функция(СтрВызов)»).
Чем вам не нравится реализация async/await в 1С?

Как может не нравиться то, чего просто нет?

только не это…

сейчас опять начнется — «чем вам BeginEnvokeИменемБорисаНуралиева() не async/await» и еще 150 постов в попытках объяснить, а потом еще 150 постов «докажите мне что без этого жить невозможно»
Механизм фоновых заданий существует в платформе с версии 8.1 (2006 год). Вы можете запустить фоновое задание, можете ожидать выполнение одного/нескольких, с таймаутом. В платформе 8.2 (2009 год) появилась возможность работы с временным хранилищем. С помощью него обмениваться информацией как между фоновыми заданиями, так и между клиентом и сервером. Чуть более сложно сделать, чтобы фоновое задание запустилось после окончания транзакции, которая его создала. Чего вам не хватает?
Растянули резину на кучу сообщений. Вы написали, что async/await в платформе 1С нет. Это неправда и вам по ссылке это доказали (те же фоновые задания). Вы начали писать про то, что это не удобно и не наглядно. Это уже вопрос привычки.
Это неправда и вам по ссылке это доказали (те же фоновые задания).

Не доказали. Фоновые задания — это не async/await, это просто какая-то форма асинхронии. Я не говорил, что в 1С нет асинхронии, я говорил, что нет специфично async/await, и дискуссия это подтвердила.


Вы начали писать про то, что это не удобно и не наглядно.

Это уже о том, чем async/await лучше. То, что его нет, не зависит от наглядности или удобства.


Хотите поспорить? В той дискуссии есть пример кода, характерного для async/await, можете прямо там ответить, могу здесь повторить. Мой оппонент так и не смог полностью воспроизвести функциональность этого кода даже без учета читабельности.

Напишите, какую именно функциональность async/await нельзя воспроизвести в 1С
async Task DownloadAndSendAsync(Uri[] filePaths, string to)
{
  using(TracingScope.Create())
  {
    File[] files = await filePaths.ForEachAsync(DownloadFile);
    await SendEmailAsync(to, attachments: files)
  }
}

Обязательное условие — в одном методе.

Напишите словами что требуется. Не все тут знатоки C# и тем более особенностей передачи файлов в .NET. И что за ограничение на один метод? Вы написали, что на читабельность внимания не обращать
Напишите словами что требуется.

Скачать асинхронно k файлов, когда все докачаются — асинхронно отправить емейл с этими файлами. Вызывающий код асинхронно же получает результат выполнения (успешно или ошибка). Все это обернуто в контекст трассировки, который позволяет (а) отследить время выполнения отмеченного сегмента и (б) присвоить корреляционный идентификатор всем дочерним сегментам и всем записям в лог внутри сегмента.


И что за ограничение на один метод?

Потому что это отличительная особенность async/await — линейный код.


Вы написали, что на читабельность внимания не обращать

Я этого не писал. Я написал, что мой оппонент не справился даже не обращая внимания.

Да, я надеюсь, то, что "асинхронно" — это не "заблокировали поток на все время ожидания", уточнять не надо?

Вот набросал как это может выглядеть:
Функция ЗагрузитьИОтправитьФайлы(Файлы, Адрес, ЗапускЗадания = Ложь) Экспорт
	Если НЕ ЗапускЗадания Тогда
		ПараметрыЗадания = Новый Массив;
		ПараметрыЗадания.Добавить(Файлы);
		ПараметрыЗадания.Добавить(Адрес);
		ПараметрыЗадания.Добавить(Истина);
		
		Возврат ФоновыеЗадания.Выполнить("РаботаСФайлами.ЗагрузитьИОтправитьФайлы", ПараметрыЗадания);
	КонецЕсли;
	
	КлючЗадания = Новый УникальныйИдентификатор;
	
	Задания = Новый СписокЗначений;
	Для Каждого ПутьКФайлу Из Файлы Цикл
		АдресХранилища = ПоместитьВоВременноеХранилище(Неопределено);
		
		ПараметрыЗадания = Новый Массив;
		ПараметрыЗадания.Добавить(ПутьКФайлу);
		ПараметрыЗадания.Добавить(АдресХранилища);
		
		Задание = ФоновыеЗадания.Выполнить("РаботаСФайлами.ЗагрузитьФайл", ПараметрыЗадания);
		Задания.Добавить(Задание, АдресХранилища);
	КонецЦикла;
	
	ВыполненныеЗадания = Новый СписокЗначений;
	Пока Задания.Количество() > 0 Цикл
		Попытка
			ФоновыеЗадания.ОжидатьЗавершения(Задания.ВыгрузитьЗначения(), 15);
		Исключение
		КонецПопытки;
		
		МаксИнд = Задания.Количество();
		Для Инд = 1 По МаксИнд Цикл
			Отбор = Новый Структура("УникальныйИдентификатор", Задания[МаксИнд - Инд].Значение.УникальныйИдентификатор);
			Задание = ФоновыеЗадания.ПолучитьФоновыеЗадания(Отбор)[0];
			Если Задание.Состояние <> СостояниеФоновогоЗадания.Активно Тогда
				ВыполненныеЗадания.Добавить(Задание, Задания[МаксИнд - Инд].Представление);
				Задания.Удалить(МаксИнд - Инд);
			КонецЕсли;
		КонецЦикла;
	КонецЦикла;
	
	Для Каждого ЭлементСписка Из ВыполненныеЗадания Цикл
		ЗаписьЖурналаРегистрации("ВложениеФайла", , , , "" + ЭлементСписка.Значение.Состояние + ";" + ПолучитьИзВременногоХранилища(ЭлементСписка.Представление));
	КонецЦикла;
	
	ЗаписьЖурналаРегистрации("ОтправкаФайлов", , , , Адрес);
КонецФункции


Объясните только, что значит «вызывающий код асинхронно получает результат выполнения»?
Объясните только, что значит «вызывающий код асинхронно получает результат выполнения»?

Это значит, что вызывающий код точно так же пишет await DownloadAndSendAsync(), и получает асинхронную операцию.


Что вернет ваша функция ЗагрузитьИОтправитьФайлы?


Что происходит с потоком выполнения во время вызова ФоновыеЗадания.ОжидатьЗавершения?


Что происходит с ошибками, случившимся во время РаботаСФайлами.ЗагрузитьФайл?


Где отправка емейла?


Где контекст трассировки?


Пока что вы идете ровно по тем же самым граблям, что предыдущий оппонент.


PS Очень поучительно, кстати, что поиск в яндексе не дает ответа на вопрос про ФоновыеЗадания.ОжидатьЗавершения, и даже не выводит на документацию. Или я не умею искать?

Что вернет ваша функция ЗагрузитьИОтправитьФайлы?

Она вернет объект ФоновоеЗадание, у которого при необходимости можно вызвать метод ОжидатьЗавершения()
Что происходит с ошибками, случившимся во время РаботаСФайлами.ЗагрузитьФайл

Их можно получить из в цикле ВыполненныеЗадания через поле ИнформацияОбОшибке, там будет и описание и строка модуля
Где отправка емейла?

Вам реально нужен пример работы с объектом ИнтернетПочта? Я пишу событие в журнал регистрации ОтправкаФайлов когда я готов отправить письмо
Где контекст трассировки?

Что вы имеете ввиду? Для чего он вам?
Или я не умею искать?

Не умеете. Первый в поиске гугла по строке «ФоновыеЗадания.ОжидатьЗавершения „forum.mista.ru/topic.php?id=699578
Их можно получить из в цикле ВыполненныеЗадания через поле ИнформацияОбОшибке

Судя по фразе "можно получить", у вас этого не происходит, и код, вызывающий ЗагрузитьИОтправитьФайлы не получит этих ошибок. Или получит?


Вам реально нужен пример работы с объектом ИнтернетПочта?

Мне нужно видеть, что письмо отправляется или не отправляется в зависимости от успешности скачивания файлов, а результат общего выполнения зависит от успешности отправки письма.


Что вы имеете ввиду?

Вот это:


using(TracingScope.Create())
{
}

Автоматическое отслеживание времени выполнения, автоматическая корреляция всех дочерних записей в лог.


Для чего он вам?

Чтобы знать, что и когда происходит в коде.


Первый в поиске гугла по строке

Это документация? Не похоже.


Я повторю вопрос, поскольку вы на него не ответили, а он первый по важности, на самом деле:


Что происходит с потоком выполнения во время вызова ФоновыеЗадания.ОжидатьЗавершения?

Судя по фразе «можно получить», у вас этого не происходит, и код, вызывающий ЗагрузитьИОтправитьФайлы не получит этих ошибок. Или получит?

Вы можете сделать вызов:
	ФоновоеЗадание = РаботаСФайлами.ЗагрузитьИОтправитьФайлы(Файлы, "test@test.ru");
Попытка
	ФоновоеЗадание.ОжидатьЗавершения();
Исключение
	// обработка ошибок	
КонецПопытки;

и выполнение остановится до завершения этого вызова.
Можете просто сделать вызов:
	ФоновоеЗадание = РаботаСФайлами.ЗагрузитьИОтправитьФайлы(Файлы, "test@test.ru");

и выполнение программы продолжится
Мне нужно видеть, что письмо отправляется или не отправляется в зависимости от успешности скачивания файлов

Вы в это место попадете, когда все задания на скачивания файлов завершатся (успешно или с ошибкой)
В цикле по заданиям в ЭлементСписка.Значение.Состояние вы получаете статус завершения, а в ПолучитьИзВременногоХранилища(ЭлементСписка.Представление) то что передало подчиненное задание в основное
Автоматическое отслеживание времени выполнения, автоматическая корреляция всех дочерних записей в лог.

Делать замеры придется самостоятельно с помощью вызова ПолучитьУниверсальнуюДатуВМиллисекундах(), так же как и передавать содержимое ошибки из подчиненных фоновых заданий в основное чтобы записывать их как единое целое. Опять же это все можно реализовать при необходимости
Чтобы знать, что и когда происходит в коде.

Вы можете всю трассировочную информацию писать в журнал регистрации
Я повторю вопрос, поскольку вы на него не ответили, а он первый по важности, на самом деле

1С не выкладывает документацию по платформе в общий доступ. Можете зарегистрироваться на its.1c.ru бесплатно на 7 дней. Описание этой процедуры:
Ожидает завершения всех фоновых заданий из списка. Если хотя бы одно задание завершено аварийно, ожидание прерывается и выдается ошибка выполнения задания. Если наступил таймаут, выдается ошибка ожидания задания. Ожидать завершения заданий может только администратор или пользователь, запустивший задания на выполнение.
То есть вы ее вызываете если хотите ожидать выполнения. Если ждать не хотите не вызываете, но и тогда никакой информации о результате выполнения задания вы не получите
Вы можете сделать вызов [...] и выполнение остановится до завершения этого вызова.

Получу ли я в этом случае ошибки скачивания файлов?


Вы в это место попадете, когда все задания на скачивания файлов завершатся (успешно или с ошибкой)

Просто покажите код.


Опять же это все можно реализовать при необходимости

То есть в вашем коде этого нет? Опять повторяется та же самая история, что и раньше. Покажите мне код, который делает то же самое, что и мой.


Вы можете всю трассировочную информацию писать в журнал регистрации

Да понятно, что могу. Вопрос в том, как ее коррелировать.


Описание этой процедуры:

Там опять нет ответа на мой вопрос: что происходит с потоком выполнения, пока эта процедура не завершится?

Получу ли я в этом случае ошибки скачивания файлов?

Это зависит от того, как вы реализуете обработку ошибок в ЗагрузитьИОтправитьФайлы. Вы можете в том случае, если хотя бы один файл загрузился с ошибкой вызвать исключение со списком ошибочных файлов
Просто покажите код.

Вот кусок который нужно вставить вместо
	Сообщение = Новый ИнтернетПочтовоеСообщение;
	Сообщение.Получатели.Добавить(Адрес);
	
	Для Каждого ЭлементСписка Из ВыполненныеЗадания Цикл
		Если ЭлементСписка.Значение.Состояние = СостояниеФоновогоЗадания.Завершено Тогда
			Сообщение.Вложения.Добавить(ПолучитьИзВременногоХранилища(ЭлементСписка.Представление));
		Иначе
			Сообщение.Тексты.Добавить(ЭлементСписка.Значение.ИнформацияОбОшибке.Описание());
		КонецЕсли;
	КонецЦикла;
	
    Профиль = Новый ИнтернетПочтовыйПрофиль;
	
	ИнтернетПочта = Новый ИнтернетПочта;
	ИнтернетПочта.Подключиться(Профиль);
	ИнтернетПочта.Послать(Сообщение);
	ИнтернетПочта.Отключиться();

Покажите мне код, который делает то же самое, что и мой.

Мы обсуждает async/await, а не способы сбора информации об ошибке и записи их в лог. Все это тоже можно сделать
Там опять нет ответа на мой вопрос: что происходит с потоком выполнения, пока эта процедура не завершится?

Я вам привел фрагмент описания из встроенно документации, там явно написано — Ожидает завершения всех фоновых заданий из списка. Что тут не понятного, останавливается выполнение и все.
Вы можете реализовать процедуру, которая сама будет отслеживать выполнение фонового задания, замерять время выполнения, формировать дерево ошибок и вызывать ее:
ОбщегоНазначения.ОбработатьРезультатВФоне(РаботаСФайлами.ЗагрузитьИОтправитьФайлы(Файлы, "test@test.ru"));

Если у вас есть базовый механизм ожидания выполнения группы заданий и возможность передачи информации между ними вы можете реализовать любую логику.
Это зависит от того, как вы реализуете обработку ошибок в ЗагрузитьИОтправитьФайлы.

Ну то есть я должен руками написать всю функциональность.


Вот кусок который нужно вставить вместо

И где "емейл не будет послан, если ошибка"? Где асинхрония в отправке емейла?


Мы обсуждает async/await, а не способы сбора информации об ошибке

Вы ошибаетесь, противопоставляя эти две вещи. async/await (по крайней мере, в C#) ценен в том числе и тем, что полностью сохраняет контекст вызова, которым можно пользоваться для трассировки.


Ожидает завершения всех фоновых заданий из списка. Что тут не понятного

Не понятно, что происходит с потоком. Вот был поток (в смысле, thread), в нем вызвали ОжидатьЗавершения — он в этот момент освободится для других задач, или нет?

Ну то есть я должен руками написать всю функциональность.

У нас вопрос не в том, чья библиотека больше подходит под асинхронное выполнение, а о том, что базовая функциональность для этого есть.
И где «емейл не будет послан, если ошибка»?

Вы можете обойти все задания, и если хотя бы в одном статус отличается от Выполнено емейл не отправлять. Разве это не очевидно?
Где асинхрония в отправке емейла?

Вы можете сделать отдельную процедуру для асинхронной отправки и вызывать ее. Все библиотечные функции 1С синхронные, кому нужна асинхронность — пишет сам
то полностью сохраняет контекст вызова, которым можно пользоваться для трассировки.

Объект ФоновоеЗадание вместе с данными во временном хранилище — тот же контекст вызова
Вот был поток (в смысле, thread), в нем вызвали ОжидатьЗавершения — он в этот момент освободится для других задач, или нет

Откуда мне знать, как в закрытой платформе реализовано ожидание. Разумеется цикл не гоняет, вероятнее всего переходит в спящий режим.
У нас вопрос не в том, чья библиотека больше подходит под асинхронное выполнение

А это не библиотека, это функциональность ключевого слова await.


Разве это не очевидно?

Очевидно, но у вас не сделано.


Вы можете сделать отдельную процедуру для асинхронной отправки и вызывать ее.

Ну так покажите код, который будет это делать. Процедуру не надо, вызывающий код покажите.


Объект ФоновоеЗадание вместе с данными во временном хранилище — тот же контекст вызова

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


Откуда мне знать, как в закрытой платформе реализовано ожидание.

А если не знаете, то и сказать, эквивалентно ли async/await — не можете. Потому что, как я уже говорил, это ключевой вопрос.

Ну так покажите код, который будет это делать

Например мы сделали процедуру, которая отправляет почту в отдельном фоновом задании — РаботаСПочтой.ПослатьАсинхронно(Профиль, Сообщение). Теперь вы хотите, чтобы некое другое задание обрабатывала результат этой отправки:
ОбщегоНазначения.ОбработатьРезультатВФоне(РаботаСПочтой.ПослатьАсинхронно(Профиль, Сообщение))
Ну так покажите, как эти данные передаются без знания об этом вызываемого кода

Каких именно данных вам не хватает для обработки ошибок в моем примере?
Потому что, как я уже говорил, это ключевой вопрос

Это для вас ключевой вопрос. Если на платформе 1С возникает потребность асинхронного выполнения — она используется, при необходимости пишутся необходимые библиотеки или обертки. Это достаточно глупо сравнивать предметно-ориентированную платформу с языком общего назначения. Вам написать чего нет в .NET, что есть в платформе 1С?
Я например считаю, что генерики C# гораздо примитивнее шаблонов в C++. Но не кричу на каждом углу, что шаблонов в C# нет.
ОбщегоНазначения.ОбработатьРезультатВФоне

… и снова: что будет с контекстом, что будет с ошибками?


Каких именно данных вам не хватает для обработки ошибок в моем примере?

Мне нужно, чтобы коррелятор, задаваемый внутри TracingScope, был доступен любому коду логирования внутри любого метода, вызванного внутри этого сегмента.


Это для вас ключевой вопрос.

Ну да, потому что именно от него зависит, есть ли в платформе await.


Если на платформе 1С возникает потребность асинхронного выполнения

Так я же сразу сказал: асинхрония в 1C есть, с этим я спорить не собираюсь. Нет конкретного async/await.


Это достаточно глупо сравнивать предметно-ориентированную платформу с языком общего назначения.

А я, вроде, и не сравниваю (мне надоело уже). Я просто говорю, что в 1С нет async/await.


Но не кричу на каждом углу, что шаблонов в C# нет.

… хотя их в C# действительно нет.

Нет конкретного async/await.

Так вы и пишите тогда, что async/await не такой как в C#, а не «Как может не нравиться то, чего просто нет?» Потому что согласно википедии — это возможность задания зависимостей одних задач от других en.wikipedia.org/wiki/Async%2Fawait.
ак вы и пишите тогда, что async/await не такой как в C#, а не «Как может не нравиться то, чего просто нет?»

Ну так и нет такого, какой я ожидаю.


Потому что согласно википедии — это возможность задания зависимостей одних задач от других

Нет. Цитирую:


is a syntactic feature [...] that allows an asynchronous, non-blocking function to be structured in a way similar to an ordinary synchronous function

Non-blocking — это ровно то требование, которое я озвучивал выше, просто другими словами.


Ну и да:


in particular, being close to blocking code, readability and the minimal amount of boilerplate code were cited as await benefits.
Non-blocking — это ровно то требование, которое я озвучивал выше, просто другими словами

Нигде в статье не написано, что превращение обычного вызова в асинхронный должно делаться ключевым словом async. Я могу определить глобальную функцию await(ВызываемыяФункция, Параметр1… Параметр2), в ней делать вызов переданной функции через фоновое задание и затем использовать ее с помощью
await("РаботаСФайлами.ЗагрузитьИОтправитьФайлы", Файлы, "test@test.ru")

В текущей реализации C++ нет ключевого слова await, а вместо ключевого слова async используется функция — по вашему там тоже нет поддержки async/await?
Я могу определить глобальную функцию await(ВызываемыяФункция, Параметр1… Параметр2),

И ее вызов снова не будет non-blocking: на время ее выполнения вызывающий поток будет занят.


В текущей реализации C++

Ничего не знаю про текущую реализацию C++.

на время ее выполнения вызывающий поток будет занят.

Вот вам пример реализации await, управление сразу вернется в вызываемый поток
Функция await(ВызываемаяФункция, Параметр1 = Неопределено, Параметр2 = Неопределено)
	ПараметрыЗадания = Новый Массив;
	Если Параметр1 <> Неопределено Тогда
		ПараметрыЗадания.Добавить(Параметр1);
	КонецЕсли;
	Если Параметр1 <> Неопределено Тогда
		ПараметрыЗадания.Добавить(Параметр2);
	КонецЕсли;
	
	Возврат ФоновыеЗадания.Выполнить(ВызываемаяФункция, ПараметрыЗадания);
КонецФункции
Но при этом не будет ожидать завершения фонового задания. Ну серьезно, вы почитайте сначала в чем суть async/await.
Но при этом не будет ожидать завершения фонового задания

Я неправильно написал, вот правильный варинат:
Функция await(ВызываемаяФункция, Параметр1 = Неопределено, Параметр2 = Неопределено)
	ПараметрыЗадания = Новый Массив;
	Если Параметр1 <> Неопределено Тогда
		ПараметрыЗадания.Добавить(Параметр1);
	КонецЕсли;
	Если Параметр1 <> Неопределено Тогда
		ПараметрыЗадания.Добавить(Параметр2);
	КонецЕсли;
	
	Задание = ФоновыеЗадания.Выполнить(ВызываемаяФункция, ПараметрыЗадания);
	Отбор = Новый Структура("УникальныйИдентификатор", Задание.УникальныйИдентификатор);
	Пока Задание.Состояние = СостояниеФоновогоЗадания.Активно
		Попытка
			Задание.ОжидатьЗавершения(15);
		Исключение
		КонецПопытки;
		
		Задание = ФоновыеЗадания.ПолучитьФоновыеЗадания(Отбор)[0];
	Исключение
	КонецПопытки;
	
	Возврат Задание;
КонецФункции
А в таком варианте возвращаемся к тому что вызывающий ОжидатьЗавершения поток блокируется
В вашем await тоже выполнение останавливается, иначе как вы результат получите?
Выполнение приостанавливается но поток в это время освобождается. Например в случае ui потока пользователь сможет работать с интерфейсом и код будет выполняться. А к прерванному async/await коду поток вернётся когда снова освободится и продолжит с той же точки.
А почему вы сразу на UI скатываетесь, я нигде не утверждал что там используется async/await
Ну в частности потому что в 1с оно очень было бы полезно как раз для UI. Ну и мне UI ближе так как после 1с ушел в андроид разработку а не в бекенд. Но можно и без UI, на сервере у вас аналогично не выйдет ибо у вас нет точки как можно на поток тот же кинуть другое задание.

Останавливается выполнение, но поток не блокируется. Планировщик может выполнить на этом потоке другую задачу.


Я, в принципе, согласен с Neikist: вы, похоже, не знаете, что такое async/await, но при этом утверждаете, что оно в 1С есть.

Не соответствует условию non-blocking (и, похоже, опять нет обработки ошибок).


На мой взгляд, этот конкретный код не просто бесполезен — он вреден, потому что он потребляет больше ресурсов, чем если бы вы просто запустили процедуру напрямую.

Ну обработку ошибок там можно дописать, но да, это все равно не non-blocking.

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

ОжидатьЗавершеня это конечно хорошо, но у вас есть несколько проблем. А именно — это по прежнему блокирует поток основной, мы всего лишь получаем возможность задачу распараллелить и дождаться завершения. Это синхронный подход, но с многопоточкой, хотя да, стек мы сохраняем. Ну и применимо это только на сервере, только с функциями общих модулей и требует кучи бойлерплейта. Со всем этим смириться можно, но это не асинхронность. У предыдущего оппонента из 1с было наоборот, была асинхронность но не было сохранения стека))
стек мы сохраняем

Неа, вызванные фоновые задачи находятся вне стека.

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

Я писал выше, что вы можете сделать отдельную процедуру, которая будет на вход получать ФоновоеЗадание — при этом сама инициировать новое фоновое задание, ожидать в нем завершения переданного и при необходимости писать необходимую информацию об ошибке.
Вот только поток все равно будет заблокирован. Если мы допустим нажмём на кнопку которая вызовет этот код — UI будет полностью заблокирован до завершения выполнения фоновых заданий.
Почему? На клиенте вы делаете обработчик ожидания, который периодически проверяет статус фонового задания и если оно завершилось возвращает результат. Такой подход повсеместно используется в той же 1С:ERP
Тогда мы теряем стек. Либо одно, либо другое условие не выполняется.
Условие чего? Какой информации о фоновом задании вам недостаточно на клиенте?
С планшета писать не очень удобно, поэтому просто скину ссылку на вики async/await
Я же выше написал условие что стек должен сохраняться
Где в вики написано про стек? Вы опять начинаете приплетать особенности реализации. Я вообще не вижу смысла что-то вам доказывать. Функциональности платформы 1С достаточно для написания многопоточных приложений с удобным механизмом синхронизации между потоками.
В первом же предложении
to be structured in a way similar to an ordinary synchronous function
Функциональности платформы 1С достаточно для написания многопоточных приложений с удобным механизмом синхронизации между потоками.

Во-первых, ФоновоеЗадание это не поток, это несколько более сложная конструкция, которая может выполниться вообще на другой машине. И попробуйте легко и удобно передать в нее, например, файл более 1ГБ.

Во-вторых, какая связь между многопоточностью и async/await? Асинхронность и многопоточность это разные вещи.

В-третьих, из вашей же ссылки на wiki
a syntactic feature of many programming languages — т.е. на уровне синтаксиса языка, а не давайте сами реализуем машину состояний
asynchronous, non-blocking function — заметьте ни слова про многопоточность ибо это совсем про другое.
to be structured in a way similar to an ordinary synchronous function. — код сохраняет линейность, т.е. буквально можно добавить await. И где там это в 1С то можно сделать?
Во-вторых, какая связь между многопоточностью и async/await? Асинхронность и многопоточность это разные вещи.

Вам удалось донести до меня ключевую особенность async/await — возможность работы в одном потоке выполнения. Данной возможности в 1С нет, поэтому я признаю что async/await в платформе 1С нет
Поразжигаю. Расскажите, пожалуйста, как решить такую задачу:
1. Создаем фоновое задание, которое запускает еще 1000 фоновых заданий, которые что-то считают. Родительское задание должно дождаться всех дочерних и, скажем, сложить результаты всех и отдать вызвавшему.
2. Запускаем 1000 таких фоновых заданий, дожидаемся выполнения, складываем результаты.

Ага, должны выполниться 1001000 фоновых заданий :)

На .net или java эта задача, строго говоря, решается вообще без async/await и корутин, но с ними гораздо проще и красивее.

cc: lair Neikist
Ну это уже на самом деле для чисто прикладной платформы и прикладного языка редкая необходимость которую вовне можно отдать. А вот для UI, например, или для небольших оптимизаций прикладных задач это можно было бы использовать и было бы нередко полезно и удобно.
Функциональности платформы 1С достаточно для написания многопоточных приложений

А никто и не спорил с тем, что в 1С есть многопоточность. Лично я спорю только с утверждением про async/await.


с удобным механизмом

… хотя, конечно, не могу не отметить, что приводимые примеры лично для меня выглядят хуже, чем ThreadPool.QueueUserWorkItem, который был доступен в .net еще в 2003 году.

А никто и не спорил с тем, что в 1С есть многопоточность.


Я поспорю. С точки зрения прикладного разработчика многопоточности там нет, там есть многозадачность и некоторый параллелизм.

UPD Примерно в том же смысле, в котором наличие web workers не делает многопоточным javascript.
В платформе 1С исторически есть поддержка модальных окон, но сейчас это bad practice.


ага. а это значицо best practice:

Присвоение cсылочного параметра: Отказ
Этот пример по своему «диагностическому сообщению» очень похож на предыдущий, но решение его уже не такое простое. Например, исходный код выглядит так:

Процедура ПередЗакрытием(Отказ, СтандартнаяОбработка)

Ответ = Вопрос(«Закрыть форму?»)

Если Ответ = ВариантыОтветов.Нет Тогда
Отказ = Истина; //форма не закроется
КонецЕсли;

КонецПроцедуры

Суть проблемы здесь та же, что и в предыдущем примере. После выполнения модального метода нужно присвоить значение переменной «Отказ». Но сделать это в контексте обработчика оповещения невозможно.

Дополнительная сложность заключается в том, что просто переставить местами строки кода, как в предыдущем примере, тоже нельзя. Отказ выполняется только при одном из условий.

Поэтому тут нужно применять решение, которое описано в разделе Вопрос в обработчике формы ПередЗакрытием. Выполнять закрытие формы «в два прохода». Первый раз безусловно отказываться от действия и только задавать вопрос. А второй раз уже закрывать форму. А чтобы не зациклиться, использовать переменную модуля для того, чтобы отличить первый проход от второго.

гениально!

Я сразу вспоминаю молодость на 7.7… Где чтобы вызвать действие на форме надо было вызывать «фальшивое» закрытие этой самой формы… тот же принцип был — взводится флаг, вызывается закрытие с «Отказ = Истина», нужное действие срабатывает, ура товарищи…

молодцы! новое поколение костылестроителей тчут заветы «предков»!

там просто если читать its.1c.ru/docs/v8nonmodal такие конструкции выплывают роскошные…
ну накой хрен реализовывали работу в браузере… ну не пользуются нормальные люди этим. вообще

это же очередное произведение отдела карго-культа. неработоспособное

но «партия сказала надо» и теперь codebehind формы выглядит еще более угандошенным, чем ранее

больше асинхронности богу асинхронности
ну накой хрен реализовывали работу в браузере… ну не пользуются нормальные люди этим. вообще

Чем конкретно "нормальные люди" вообще не пользуются?

работой 1с в браузере… ну убогая она. тут «не работает», тут какие-то нюансы

в итоге — очередной мертворожденный функционал. который работает только в PowerPoint

Не, если "работой в браузере", то сколько угодно.

Нужно смотреть на это с другой стороны. Есть некое видение развития платформы со стороны главного разработчика. Оно включает в себя в том числе работу в браузере любого прикладного решения. По поводу неработоспособности я с вами не соглашусь, служба поддержки по платформе работает очень оперативно (не раз в этом убеждался), а вот то что сложность разработки по сравнению с модальным режим — сомнения не вызывает. Но это дело привычки.
Но это дело привычки


ну давайте уже «привыкать к хорошему», а?

я вот нихера не понимаю зачем всех «заставили привыкнуть» к тому, что таблицу значений на сервер надо передавать в виде массива массивов

Оно включает в себя в том числе работу в браузере любого прикладного решения.


зачем? есть же тонкий клиент — ну доведите его до ума. или реально тогда все перекидываем в web и начинаем все делать «по взрослому»

двум богам служить нельзя, «запуск в любой кофеварке» все будет состоять из компромиссов, «не держите его так» и костылей… чем это оправдано кроме рекламных проспектов «а мы вот как можем»?
потому что стоит задача — запускать на каждой кофеварке…
на любом устройстве.

самое простое решение: вебпубликация приложения из коробки.
я вот нихера не понимаю зачем всех «заставили привыкнуть» к тому, что таблицу значений на сервер надо передавать в виде массива массивов

Откуда у вас возникает потребность формировать на клиенте большие объемы данных, чтобы потом гнать их на сервер?
есть же тонкий клиент — ну доведите его до ума

В чем проблема с тонким клиентом? Я разрабатываю всю новую функциональность на управляемых формах с 2011 года, и у меня не разу не возникало неразрешимых проблем.
Мне некоторые вещи в платформе кажутся избыточными, про качество некоторых типовых решений я вообще молчу. Но в целом количество плюсов в платформе и типовых решениях перевешивает все минусы. Какая альтернатива то? Вот автор поста предлагает isFusion. Но мне разработка интерфейса кодом нафиг не нужна, особенно когда я знаю какие по сложности бывают формы. Даже копать дальше желания нет.
Откуда у вас возникает потребность формировать на клиенте большие объемы данных, чтобы потом гнать их на сервер?


вы разработчиков типовых спрашивать не пробовали — зачем вам функция которая этот фокус-покус делает?

все это лишнее парни, гоняйте каждую запись отдельно. желательно в фоновом задании
Подход о котором вы пишите точно не является повсеместно используемым. Напишите конфигурацию в которой вы такое видели, желательно с именем функции.
Откуда у вас возникает потребность формировать на клиенте большие объемы данных, чтобы потом гнать их на сервер?

Мне тут Neikist выше доказывал, что это чуть ли не самый главный кейс.
Но мне разработка интерфейса кодом нафиг не нужна, особенно когда я знаю какие по сложности бывают формы.

Как раз кодом сложные формы гораздо проще разрабатывать. Так как можно легко декомпозировать задачу. То есть
EXTEND FORM A
// несколько объектов свойств
;

EXTEND FORM A
// несколько объектов свойств
;
Как раз сложные формы одно из слабых мест в 1С (в частности из-за этого и этого). Поэтому в том же УТ найти форму сложнее одного двух readonly списков не так то просто. Покажите что-нибудь хотя бы уровня Розничная торговля -> Ассортимент магазинов. Или даже просто Склад -> Текущие остатки.
Мне тут Neikist выше доказывал, что это чуть ли не самый главный кейс.

Не совсем так. Я лишь доказывал что это реальный и не очень редкий кейс (раз в месяц на кого нибудь в отделе подобные задачи сваливались).
Вы ссылаетесь на некие «слабые» места 1С, которые таковыми не являются. Вот например показать в форме список договоров поставщика: Сама по себе задача идиотская, зачем отображать в форме документа список договоров, когда договор выбырается из подчиненного списка, в который можно передалть с помощью связей параметров выбора текущего контрагента. Далее написан какой-то бред про отображение на форме документа списка других документов и еще поставщика меняет какой-то другой пользователь. Это как? 2 пользователя работают с одним документом? В любом случае параметр добавлять не обязательно, достаточно управлять отобором.
Далее вы пишите, что в ранних версиях 1С не было WYSIWYG. Был, как минимум с 1997 года (версия платформы 7.5).
Далее идет странный опус про привязку к спискам (так и не понял что вы имели ввиду). Вы можете добавить к таблице на форме (которая привязана к данным объекта) добавить дополнительные колонки и заполнять их из запроса, теми же остатками. Динамические списки используются в формах списков, в формах отдельных записей используются крайне редко.
Что значит отсутствует оптимизатор — платформа как минимум оптимизирует запрос, чтобы он не выбирал колонки которые не используются, далее есть оптимизатор самой СУБД
Вы пишите о том что остатки будут «рассчитываться» при каждом открытии. Подбор товаров делается по текущим остаткам, а данные по ним берутся из отдельной таблицы итогов. Также для регистра цен можно использовать таблицу итогов для среза последних.
Что касается непоследственно вопроса про расширение форм — 1С его использует для отдельных элементов отдельных форм (например механизм дополнительных реквизитов и сведений), но вы забываете, что для бизнес-приложения практически невозможно построить красивые диаграммы классов, которые будут всех устраивать. Поэтому в той же Axapta (в которой есть наследование) никаких предметных диаграмм классов для типов документов вы не встретите.
Кроме того вы забываете, что это чаще всего приложения на платформе 1С находятся на поддержке поставщика, то есть периодически ее приходится обновлять. И количество конфликтов при таких наследованиях будет очень большое.
Что касается — посмотрите на форму и покажите такую же — а зачем? Вывести на форму кучу информации из таблиц и навесить на них отборы больших усилий не требует. Но приложения на платформе 1С разрабатываются от документа или АРМ и каждый из них содержит всю необходимую информацию для принятия решения (особенно уклон в эту сторону начался с появлением интерфейса Такси). Сложность приложения оценивается по количество и качеству автоматизируемых бизнес-процессов. Вот например в ERP есть расчет себестоимости с помощью СЛАУ, сейчас в платформе появился объект, который быстро решает СЛАУ. В isFusion такое есть?
Вы тут писали о том, что сообщество 1С очень закрытое — это не так. Мы можете посетить семинар 1С как частное лицо в рамках «Открытого воскресенья» и пообщаться с разработчиками как платформы так и типовых решений. Там вы точно сможете получить ответы на все вопросы из первых уст, а не пытаться найти поддержку на непрофильном форуме.
Раскрыть бы вам глаза на примеры открытых сообществ…
Вот например в ERP есть расчет себестоимости с помощью СЛАУ, сейчас в платформе появился объект, который быстро решает СЛАУ. В isFusion такое есть?


нашли чем хвалиться… решать слау 1с начала еще в лохматом году в рамках УПП. Потом когда стало понятно, что на уровне языка делать это невозможно из-за адской тормознутости — утопили этот функционал в платформу. и снова выдаем это за очередной технологический прорыв
Кроме того вы забываете, что это чаще всего приложения на платформе 1С находятся на поддержке поставщика, то есть периодически ее приходится обновлять. И количество конфликтов при таких наследованиях будет очень большое.


а сейчас у нас гигантское количество конфликтов если пользоваться стандартными функциями БСП

поменяли версию — опять надо перепроверять всё. от проведения и печати до отчетов
Я разрабатываю всю новую функциональность на управляемых формах с 2011 года, и у меня не разу не возникало неразрешимых проблем.


нуда… помним, знаем, любим… пихаем невидимых надписей и сплиттеров побольше чтобы масштабирование и центровка работала…

что? вам нужна форме сложнее чем два реквизита и кнопка «закрыть»? у меня для вас плохие новости — вы ее даже сверстать вменяемо не сможете — она просто будет виснуть

Какая альтернатива то? Но мне разработка интерфейса кодом нафиг не нужна, особенно когда я знаю какие по сложности бывают формы.


разработка интерфейса кодом (как в 1с принято) и верстка интерфейса «кодом» — это «четыре разных человека»
нуда… помним, знаем, любим… пихаем невидимых надписей и сплиттеров побольше чтобы масштабирование и центровка работала…

Ваши знания о формах ограничиваются 2010 годом. В управляемых формах ни того ни другого не нужно
да шта выговорите… сейчас это стало «не нужно». а так пихали надписи в группы только в путь

такова «селяви» в 1С — декларируют в 10 году, а работать начинает в 17-18-ом…
Я вам больше скажу, таблицы значений как типа на клиенте и вовсе нет. Ну, по крайней мере если меня память не подводит.
Здравствуйте.
У вас интересный проект, но пока не поработаешь на прикладных задачах, оценить нельзя.

У меня появился вопрос, но т.к. я новичок, не могу оставить комментарий в ветке habr.com/ru/company/lsfusion/blog/468553 (управление параметрами — на примере сохранения истории цен).

Предлагаю обсудить его здесь.
Ваши коллеги говорят, что решить эту задачу на lsFusion получается за 150 значащих строк кода, и это значительно проще чем на других платформах.
В исходной задаче более сложная постановка, но — зато в примитивной постановке 1С позволяет создать историю цен вообще без кода (есть справочники Товары, Склады, создаем периодический регистр «ИсторияЦен» с измерениями: Товар, Склад, Время, Цена).

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

Каким образом это реализуется в lsFusion?
Скажем, на той же 1С качественная разработка такой формы может занять от десятка часов (до нескольких десятков, в зависимости от сложности задачи).
Есть такая штука как объекты-в-колонки (а точнее группы-в-колонки):

habr.com/ru/company/lsfusion/blog/460141/#objectcolumn

Фактически любые два списка можно опцией COLUMNS превратить в шахматку. Причем она будет интерактивной в нее можно вводить, сортировать, фильтровать и т.п… Ну и естественно сам список все равно будет динамическим, то есть будут читаться только видимые записи.

Чтобы посмотреть как это работает, можете зайти в демо ERP и там Розничная торговля -> Управление ассортиментом, и там все форматы магазинов вытянуты в колонки.

зато в примитивной постановке 1С позволяет создать историю цен вообще без кода

Ну как без кода, вы же понимаете что это все равно код, только который мышкой задается. Понятно что мы тоже можем сделать набор кода мышкой, только смысла в этом мало. Так как большинство разработчиков все же привыкли к коду и работать с ним в принципе куда удобнее. Собственно этому вопросу посвящен специальный раздел этой статьи.
Спасибо.
Постараюсь воспроизвести у себя и разобраться.

Ну как без кода, вы же понимаете что это все равно код, только который мышкой задается. Понятно что мы тоже можем сделать набор кода мышкой, только смысла в этом мало.

Да, это отдельная тема. Но вообще, имхо, чем больше вы будете ориентироваться «на чайников» — тем больше у вас шансов занять рынок. Рынок бизнес-ПО именно так работает.

Можно сразу еще один вопрос: где-то есть пример реализации расчета себестоимости на lF?
UFO just landed and posted this here
Убогость, это представлять объект в виде кучи реквизитов и потом поддерживать между ними целостность. Это настоящая убогость, с которой страдают все разработчики на других языках.

Целостность в других ORM поддерживается, также как и в 1С. Никакой разницы. Но разработчик если хочет может добавить дополнительные маппинги на коллекции. Вы вообще с другими ORM работали когда-нибудь?
Но при необходимость его можно вытягивать и пореквизитно, не затрагивая остальную часть

И как это сделать не используя запросы (то есть по сути не используя ORM)?
А ну покажите эту самую другую платформу, которая поддерживает Postgree, MS SQL и свой внутренний формат? На словах все горазды, а на деле полный пшик с запашком. Фишка именно в том, что бы разработчик думал бизнес-логикой, а не типом СУБД. Т.е. опять откровенная ложь про примитивный уровень. Ложь или полное незнание потребностей бизнеса.

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

Чего????? В курсе, что олапа создавалась исключительно из-за того, что долбаные кодеры понагенерят таблиц, которые фиг поймёшь и фиг повернёшь, вот и родилось это недоразумение, которое сначала считаешь пол дня (в одном холдинге внедряли), потом вертишь, любуясь. Но это только до тех пор, пока человек не знаком СКД! После знакомства, они забывают про олапы и просят самые обычные отчёты на СКД

OLAP создавался для производительности и эргономичности интерфейсов. СКД до OLAP и другого BI по этим двум параметрам ну очень далеко.
А зачем сишникам запрещают самим выдумывать структуру файла СУБД? Да потому что это бестолковый и абсолютно никому не нужный труд. Зачем именовать таблицы, если надо сделать приложение для бизнеса? Что бы вместо одного студента-1Сника был спец по MS SQL-ю, Postgre и файловому формату? Бред. Или может откроем курсы на универсального прога? Да кому это надо то?

«надо сделать приложение для бизнеса» — какая то универсальная отговорка. А ничего, что во многих случаях бизнесу удобнее интегрироваться напрямую через SQL, чем использовать непонятные и тормознутые ODAP (или как там они называются в 1С) интерфейсы. Не верите, спросите у людей, который BI решения поставляют.

Ну и всё в таком духе. Типичный комментарий, состоящий из вранья, на тему «всё плохо, но мы вообще ничего предложить не можем». Скучно и тупо.
UFO just landed and posted this here
Стоимость поддержки целостности считали? Скорее всего нет.

Там в JPA например одна аннотация добавляется, дальше все делают фреймворки / платформы.

Раз вы не работали с другими ORM, и вообще не представляете что это такое, как вы вообще можете говорить убогий в 1С ORM или нет?

Используя запросы.

Ну то есть отказываясь от ORM.

И опять всё упирается в стоимость подсчётов. На 1С дешевле, ибо остатки считает она сама.

Еще раз речь шла о накопленных суммах, то есть:
1 — 100
2 — 400
3 — 200
нужно посчитать:
1 — 100
2 — 500
3 — 700
Вы почитайте сначала что такое оконные функции и для чего они нужны. Они для решения самых базовых задач упорядочивания / разбиения нужны.

И причем тут единый синтаксис. В SQL он тоже единый. Как раз оконную функцию куда проще написать и прочитать чем self-join, который помимо того еще куда менее производительный (опять таки смотрите статью)

Пустые слова — звон. Замеры делать надо. Я конкретно видел как люди отказывались от олапы в сторону СКД

Какие вам замеры нужны? OLAP: a) in-memory б) без ACID в) агрегирует промежуточные итоги.
UFO just landed and posted this here
А я точно знаю, что побайтовое восприятие ещё сложнее, хотя тоже там целостность обеспечивается. Хоть сколько костылей делай, но пару сотен полей контролировать сложнее, нежели один объект. Это особенно хорошо видно на сложных задачах, когда даже в объектах начинаешь захлёбываться. Программист вообще должен абстрагироваться от таких ненужных мелочей, чтобы максимум внимания уделять решаемой задаче. А то так можно и до ассемблера докатиться, там возможности ещё шире будут)))))

Еще раз, вы очень плохо представляете что такое ORM, никакого «побайтного восприятия» там нет. Вся концепция не сложнее той же аннотации &НаСервереБезКонтекста.
Раз вы с 1С не работали от слова совсем, то как можете рассуждать о ней? Мозг свой видели? Нет же его! Пальцы в розетку пихали? Значит там нет опасности! Бред? Вот именно! Именно бред вы и написали, опираясь на тупое «Видел? Нет? А чо тогда?».
И что такое ORM? Это что за зверь такой? Обзываетесь что ли или как?

Под работали, я имел ввиду, что хотя бы разбирались, что это такое и как хотя бы приблизительно работает.
А почему не про влияние хентая на детскую психику или о том, как лучше готовить рис для ролов? Зачем изучать никому не нужную информацию? Это такой способ уводить диалог на своё поле? Хм… Однако. Для решения бизнес-задач они никогда не были нужны. Они нужны только тогда, когда нет нормальной платформы и приходится решать задачи указанными средствами.

Они нужны чтобы посчитать, хотя бы накопленную сумму. Или предыдущее значение. Или что-то сложнее простой суммы или максимума. И нужны именно для решения бизнес-задач. И для таких простых бизнес-задач в 1С приходится тянуть данные на сервер приложений, там писать много императивного кода, после чего заливать эти данные назад на сервер БД.
Считайте. В чём проблема то? Любой студент, устроившись во франч сможет такое подсчитать через месяц. Это не проблема.

А с оконными функциями, любой студент может посчитать это за полчаса. Если вы считаете что время разработчиков ничего не стоит, у меня для вас плохие новости.

И какое отношение это к промежуточным итогам имеет. Это вообще другой механизм. И как раз с ним (а точнее возможностью управлять физмоделью) у 1С все тоже мягко говоря не очень. Но об этом в следующей части статьи.
Фин.дир это поглядела, в ладоши похлопала и попросила сделать обычный отчёт на 1С, потому что не надо долго ждать и вся получаемая информация понятна и его в последствии может доработать местный админ. Представляете? Самые обычные аргументы, самого обычного фин.дира, перечеркнули крутую олапу. А всё почему? Правильно! Они платят из своего кармана!

Да? А у вас финдир аналитическими запросами за год-два, переформируемыми при каждом изменении срезе у вас всю базу не положит часом? Или у вас там 3,5 пользователя.

И доработка в OLAP это изменение выгрузки, которую также любой местный админ может сделать.
потому что не надо долго ждать

Чего ждать? Это все ночью или асинхронно обычно загружается. Или финдиру нужны данные в течении часа? Ну и в OLAP инкрементальная загрузка есть, так что скорее всего у тех кто внедрял просто руки кривые.
UFO just landed and posted this here
Пореквизитный анализ и контроль объекта гораздо сложнее восприятия одной сущности (например, элемент справочника). Зачем держать в голове сотни полей СУБД?

Как вы умудряетесь в разговоре про ORM нести подобную чушь? Вся разница ORM в 1c и ORM в других фреймворках что в 1с вы сущности мышкой накидываете, а в других фреймворках аннотации ставите. Никакого ручного контроля за кучей полей который вы воображаете там не нужно осуществлять.
UFO just landed and posted this here
«А то пишут, пишут… конгресс, немцы какие-то… Голова пухнет. Взять всё, да и поделить...»
Я, как программист, вообще не должен думать, что набор реквизитов как-то там разбросан по БД. Вообще не думать. Даже не вспоминать про это. Именно из таких мелочей и состоит успешная автоматизация сложных предприятий.

Я бы с этим поспорил, но… Вы же сами не понимаете что пишете. ORM это как раз когда программист не думает об отображении объектов на таблицы (ну, не думает больше чем об этом нужно думать в 1с, так то и в 1с приходится индексы проставлять, типы указывать и прочее), а просто пишет класс, навешивает аннотации и работает, про субд и не вспоминает. Сейчас наоборот беда что многие прикладные разработчики вообще субд в глаза не видели так как спокойно обходятся даже без запросов на чтение, про запросы на запись и вовсе все уже давно забыли.
UFO just landed and posted this here
Мда… Вы либо очень жирный тролль, либо очень упертый и ленивый человек. В обоих вариантах спорить с вами бессмысленно.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Я, как программист, вообще не должен думать, что набор реквизитов как-то там разбросан по БД.

Если вы, как программист, не будете думать, результат получится соответствующим — бездумным.

Какой же позор, что фузиновцы используют такие примитивные методы борьбы. Лучше бы делом занялись

Пока что со стороны выглядит так: воинствующий адепт 1С, который ничего не хочет знать об оконных функциях SQL и ORM пытается задавить авторитетом своего оппонента используя демагогические приемы.

Не будите лиха. Тут из-за одного такого адепта статья и так уже с большим скрипом открывается. Видимо в этом их план.
UFO just landed and posted this here

Какой практикой вы подтвердите слова "ORM абсолютно не нужна", "Оконные функции в СУБД не нужны"?

UFO just landed and posted this here
Я это не использую. Никогда.

Я правильно понимаю ваш тезис? "если Вы чего-то не используете, значит это вообще никому никогда не нужно".
Любопытно, что для его опровержения достаточно привести хотя бы один пример. Лично я использую и знаю кучу других людей которые используют. Следовательно вы не правы в том, что ORM и оконные функции не нужны.


где бы это могло пригодиться в работе?

ORM нужна когда вам нужно связаться с базой и преобразовать записи из таблиц в объекты для построения бизнес-логики.
Оконные функции нужны для дедубликации записей, реализации инкрементального обновления больших таблиц и всяких вычислений, для которых требуется значение соседних записей из таблицы.

UFO just landed and posted this here

Речь не о "это должен знать каждый", а о "эту технологию должен знать тот, кто ее критикует".
Для этого диалога, в общем то, не требуется знать зубодробительные ньюансы. Достаточно ознакомления на уровне "понимаю для чего применяется". Хотя бы для того, чтобы избежать странных тезисов вроде "мы отчитались перед ЦБ, прокуратурой и росфинмониторингом без знания ORM".

UFO just landed and posted this here

Обсуждать вашу переписку с представителями IsFusion, полную взаимого обожания, мне не интересно.


Я понял, что вы интегратор и вас детали реализации не интересуют. Но в статье ведь говорится именно о технических недостатках. Вот ссылка на раздел, где критикуется реализация ORM в 1С. В чем конкретно там вранье? Как вы можете это подтвердить?

Я это не использую. Никогда. Совсем не использую эти знания.

Ну если вам что-то не надо, то это не значит, что другим не надо.


Я вот использую ORM с завидной регулярностью, причем еще и в разных его реализациях.


А вот интересно, где бы это могло пригодиться в работе?

В разработке обычных таких бизнес-приложений.

UFO just landed and posted this here
Заказчик заплатит, например, за хорошее знание монетизации лени сотрудников, а на эти окна им всем откровенно плевать.

Вы наверняка очень грамотный и востребованный специалист в своей сфере. Но это не значит, что специалисты из других сфер неграмотные и "забивают голову ненужной ерундой".
Существуют задачи с такими нефункциональными требованиями, которые 1С просто не сможет выполнить. В таких случаях обращаются к узкоспециализированным специалистам, которые знают особенности синтаксиса нескольких баз данных, форматы файлов для хранения и ORM.

UFO just landed and posted this here

Насколько я понял, эти товарищи говорят не про 1С вообще, а про самописные конфигурации. Что самописки на 1С получаются дороже самописок на IsFusion (и на других инструментах).

UFO just landed and posted this here
На lsFusion за две недели уже сейчас один человек первый раз увидевший компьютер сделал то, что на 1С опытному специалисту делать минимум несколько месяцев. Причем это решение нормально работает на больших объемах в отличии от.
Могу смело сказать, что решения на фузине получаются гораздо дороже, чем на 1С и даже чем на САПе.

А насколько хорошо вы знаете lsFusion чтобы делать такие выводы?
Сейчас фузиновцев зову поучаствовать в попытке внедрения своей ERP. Если она дешевле и функциональней 1С, то ребята возьмут именно её.

Вы несравнимые вещи сравниваете. Давайте возьмем проект с глубиной кастомизации процентов так 50. Вот там возможности платформы проявятся во всей красе.
подсчёт бухгалтерских остатков и оборотов

У вас найдется под рукой подробное описание алгоритма?

UFO just landed and posted this here

Вам лично может быть и незачем. Но вы ведь используете сложность этого алгоритма как аргумент в этой дискуссии. Если вы на самом деле не знаете его, тогда у вас не получится объективно сравнить сложность реализации на 1С и на любом другом инструменте.

UFO just landed and posted this here

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

UFO just landed and posted this here
Оценке чего?

Вот с этого и нужно начинать. Я так понимаю, что ваш тезис в том, что 1С "дешевле" при разработке, чем любое другое решение. Допустим вы знаете стоимость решения на 1С. Но как вы определите стоимость любого другого решения, если даже не можете представить алгоритм для его реализации.

UFO just landed and posted this here
Выражаясь вашим языком, тут вы врете. На lsFusion сейчас делается клон одного из текущих лидеров на рынке SME (с более чем 4 миллионами пользователей) — Odoo. Задача скажем так мягко говоря нетривиальная. И простейший CRUD эта задача покрывает в том числе, который строго говоря совсем не показателен, так как практически никак не демонстрирует преимущества или недостатки той или иной технологии.
UFO just landed and posted this here
Ну я также могу сказать, что сейчас условный Bosch рассматривает ERP и 1С там в списке в принципе нет. Или крупная сеть в России сейчас ищет решение взамен 1С (а это реальный пример). И что дальше? Тезис статьи, что платформа очень кривая, что не отменяет того факта, что вложив кучу денег можно и на очень кривой платформе сделать решение, которое будет продаваться.
Берите пример с виндовс и 1С. Ориентируйтесь на покупателей, а не на программистов

«Покупатели» платформы и есть программисты. Как условный Qualcomm который конечным потребителям вообще ничего не продает, а продают другие компании которые строят решения на базе их технологий.
И прекратите заставлять программистов над вами откровенно смеяться!

Ну пока тут над IamAlexy и вами больше смеются. Потому как заявлять одновременно, что «в 1С убогая ORM» это вранье и «я не знаю что такое ORM и знать не хочу» — это очень смешно.
UFO just landed and posted this here
как вы вообще можете программировать, не зная удивительно прекрасной структуры компилятора?

Почему вы думаете, что я не знаю как устроен компилятор?

UFO just landed and posted this here

Это влияет на мою способность решать проблемы в редких нетривиальных ситуациях.

UFO just landed and posted this here

Мы просто в разных областях работаем. Думаю что при эволюционном развитии тоже потребуется углубляться в оптимизацию, т.к. данных будет накапливаться все больше и больше.
У меня часто спрашивают оптимизационные вещи вроде


  • Как посчитать это не за полтора часа, а за пол часа?
  • Как считать это не периодически, а в реальном времени?
  • Как сделать так, чтобы мы загружали список на миллион позиций, а нам в ответ приходило письмо со ссылкой на google-drive, где будут лежать результаты расчета?
UFO just landed and posted this here
Исключено. Давно уже все отошли от мысли, что любую задачу можно решить в памяти в 640 кб.

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


Как думаете, на чем разрабатывают штуки вроде портала госуслуг, портала ФНС, ЕГАИС, ARM в банках, системы управления аэропортами и железными дорогами? Почему там нет 1С, если она такая классная?


Вы сразу оптимизируете код? Вот тут есть бомба из бомб. По семиуровневой методики оптимизации надо начинать хотя бы с бизнес-процессов предприятия.

Начинать с бизнес-процесса предприятия в случае, когда тормозит одна из сотни его компонентов?
Ну, может быть. Изменение бизнес-процеса тогда будет звучать как "не могли бы вы прийти на работу на пол часа позже, чтобы сразу получить данные?".


В серьезной бизнес-аналитике железа запросто может не хватать. Ну или его не будут покупать просто по первому требованию.

UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Вы именно что кодер, а не программист. Потому как выполняете чисто техническую работу не думая об эффективности. Ну или внедренец в лучшем случае. Только я не понимаю, зачем вы тогда рассуждаете о вещах в которых разбираетесь как свинья в апельсинах. Это техническая статья, то есть не для вас.
UFO just landed and posted this here
Типичные вопросы, за решение которых платят деньги большинство, а может и все, конторы:

Точно не все. И вот когда начинаются вопросы, которые "не все", умение разбираться с нетривиальными ситуациями неожиданно пригождается.

UFO just landed and posted this here
Так вот в одной конторе как раз была работа с MS SQL ем напрямую, а 1С была просто как отображалка информации:

Речь шла конкретно о задачах BI. И у меня тоже большой опыт работы с поставщиками BI, и все они в один голос говорят, только бы не 1С, потому как доставать данные оттуда гораздо сложнее, чем когда структура БД прозрачная.

И у меня опыт автоматизации предприятий уж точно не меньше вашего, так что давайте не меряться пиписьками, а говорить по существу.
Оппачки. Приплыли. А ну ка покажите, где враньё? Где всё плохо? Я так понимаю, что кидаться какахами, это ваше хобби, выросшее из некоторых курсов? Случайно не дядька келин мозг то промывал? Хороший такой, умный. Кстати, когда он устал биться, тогда и стал рассказывать очевидные вещи, которые Вам, к сожалению, пока не доступны.

Вообще это ирония была. Ваш же комментарий, где одно слово изменено. Потому как пока все ваши возражения либо от незнания вопроса, либо конкретные передергивания.
UFO just landed and posted this here
Мы на техническом ресурсе, и обсуждаем вполне конкретные технические недостатки. Имеются другие преимущества с т.з. бизнеса перекрывающие эти недостатки? Прекрасно, но недостатками они от этого быть не перестанут. Все что вы говорите — смириться с техническими недостатками из-за того что есть преимущества вроде кучи дешевых специалистов по стране, готовых коробочных решений и т.п. аргументов. Совсем нетехнических. Это разве как то отменяет кривую объектную модель? Или кривую асинхронность? Или другие технические недостатки?
мы, программисты

вы же вроде 1Сник. или 1Сники теперь тоже считаются?..
UFO just landed and posted this here
А ну покажите эту самую другую платформу, которая поддерживает Postgree, MS SQL и свой внутренний формат?

Навскидку: Excel, R, Pentaho, Tableau, Prognoz Platform

UFO just landed and posted this here
сколько стоит прикрутить ексель, например, к Postgree.

Примерно пол часа, если есть готовые креденшелы для подключения. Нужно сделать примерно следующее:


  1. Скачать ODBC драйвер
  2. Зарегистрировать источник данных ODBC с использование драйвера postgre.
  3. Подключиться к этому источнику данных.

Дело в том, что я вижу постоянно много предприятий и нигде (абсолютно) не встречал такие сложные разработки на екселе.

Вся сложность в том, чтобы вообще узнать об этом способе. Большинство людей в Excel на такой уровень не углублялись. Я однажды пробовал просвещать на эту тему, но в итоге у меня попросили просто SQL доступ и этого хватило.


Сколько специалистов понадбится, что бы перенести екселевскую структуру с Postgree на MS SQL, а потом обратно?

Excel в этом случае просто прокладка между СУБД и пользователем. Данные в итоге все равно в СУБД лежат. Основные трудозатраты тут будут в миграции самих данных с постгреса на MSSQL. А это зависит уже от сложности ваших взаимосвязей, а не от Excel.

UFO just landed and posted this here
Смотрите, 1С использует СУБД неоптимально (с этим даже не спорю) и это цена за то, что я вообще не вспоминаю какая там СУБД. Лет 10 не вспоминаю.

Я не пойму что у вас за проекты что вы не вспоминаете? На более менее крупных проектах и в 1с приходится вникать в то как разные субд планы запросов строят. А уж тем более когда свою коробку пишешь которая должна работать на разных субд плюс/минус одинаково. По моему даже где то на ИТС были рекомендации как писать чтобы на разных субд более оптимально работало.
UFO just landed and posted this here
Если у вас пара тысяч пользователей, и миллионы элементов справочников и документов — то хоть как оптимизируйте бизнес процессы — если база ляжет потому что запросы писались без понимания и учета рекомендаций по оптимизации под субд конкретные — никому хорошо не будет. И рекомендации придется учитывать, и в планы запросов лезть, и профилировать…
Да даже на меньших масштабах все так же.
UFO just landed and posted this here
Доказано и теорией и практикой!

Каким экспериментом? По какой методологии? Кто проводил? На какой выборке?

UFO just landed and posted this here

Удивительно, как вам удалось написать простыню текста, но так и не ответить на (казалось бы, простой) заданный мной вопрос: кем и как доказано сделанное вами утверждение?


PS


Так что не кривите душой, вы то всё равно давите только на пункт №5

Я, как программист и архитектор, отвечаю за пункты с 3 по 5, и слегка, косвенно, 6.

UFO just landed and posted this here
Ни на что не отвечаете или делаете умный вид, что отвечаете.

Вам-то, конечно, виднее, в чем состоит моя работа.


При этом верхние пункты учитываете абсолютно всегда, не заостряя на них внимание

Конечно, учитываю. Это входящие требования, как их можно не учитывать?


Для программистов опыт десятилетий является доказательным.

… для каких? Точно не для меня.


А для вас что?

А для меня — воспроизводимый эксперимент (а лучше — пара, подтверждающий и опровергающий). Или формальное логическое построение в заданной системе терминов. За неимением того или другого — статистическое исследование на репрезентативной выборке, с открытой методикой и проведенное/рецензированное независимыми организациями.

Это нормальная практика, когда инструмент выбирают под задачу, а не наоборот.

Расскажите, пожалуйста, подробнее, из каких соображений вы выбираете СУБД?

UFO just landed and posted this here

Сразу видно опытного специалиста, который умеет выбирать инструменты.

UFO just landed and posted this here
UFO just landed and posted this here

Спасибо вам за пример. Вы тут описали ситуацию с точки зрения бизнеса, а не с точки зрения выбора технического инструмента. СУБД не важно, сколько человек сидит на объекте, пока они не начинают одновременно лезть в базу что-то делать. К вопросу о выборе СУБД тут относится только:


  • 10 объектов с 2-10 раб мест
  • связь с объектами по спутнику (т.е. задержка от 600 мс)
  • есть центральный офис с 100 рабочими местами
    Но при этом в части обмена между объектами и центром непонятно:
  • насколько оперативно нужно обновлять информацию
  • какой объем трафика проходит при одном обновлении

В любом случае, в ИС на 120-200 рабочих мест узкое место это совсем не СУБД. В вашем случае подозреваю проблемы с каналом связи. Но вам наверное даже не нужна оперативность в режиме реального времени. Подойдет почти любая реляционная СУБД. Скорее всего будет выбрана такая, с которой вы знакомы и которая себя хорошо зарекомендовала.


Если вы всю жизнь автоматизируете предприятия путем внедрения типового решения, то вы по сути и задачи выбора инструмента не решаете. За вас все выбрали архитекторы 1С.


Что вы скажете о случае с кардинально другими требованиями? Как, например, выбрать СУБД для Магнита? Судя по википедии, у них 14231 магазинов "у дома", 266 супермаркетов, 5187 магазинов косметики размазаны по всей россии, плюс наверняка есть интеграции с поставщиками, транспортными компаниями и т.п.

UFO just landed and posted this here
Хех, учавствовал в одном проекте на 1с для магнита. Им в целом было все равно, лишь бы работало, но они в начале проекта просили отдельно рассмотреть именно PostgreSQL.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Нафига я буду забивать голову ненужной информацией, когда мне постоянно надо изучать программирование?

Ну так изучение программирования — это и есть забивание головы информации, по какому конкретно критерию вы делите информацию на нужную и ненужную?

UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Для работ только MS SQL, [...] он гораздо дешевле Postgree.

Что такое Postgree, и где увидеть сравнение его цен с MS SQL?

UFO just landed and posted this here
Даже интересно, что вы там такого собрались жесткого настраивать в PostgreSQL, он из коробки почти на дефолтных настройках отлично на террабайтных базах с 1000 одновременных пользователей работает. Shared_buffers поставил от 1/4 до половины RAM, tuple_cost уменьшил (для SSD) и все отлично. Есть вообще штук 5 рекомендуемых настроек, а дальше просто не трогай.
UFO just landed and posted this here
Кстати как раз поднять PostgreSQL после падения по опыту было куда проще чем MS SQL. Был случай, когда у заказчика была какая то глючная виртуалка, которая постоянно падала и были случаи когда в базе появлялись странные артефакты. Так вот так как раз PostgreSQL так как он хранит все отдельными файлами, поднимался нормально, были какие-то битые записи, которые можно было пофиксить руками. MSSQL же просто говорил, cannot attach database, и все крутись как хочешь.

В любом случае у меня был большой опыт и с тем и с тем, и я не вижу ни одной причины почему MS SQL сильно удобнее администрировать, чем PostgreSQL.
UFO just landed and posted this here
Это комплексный показатель

TCO?


Мне, впрочем, все равно интересно посмотреть на конкретный расчет.


А что? К чему вопрос?

Да так, приходится периодически выбирать (или принимать участие в выборе) СУБД для очередного проекта.

Возьмите django. Поддерживает из коробки PostgreSQL, MySQL, Oracle, SQLite, и насколько я знаю разницу вы заметите при использовании их orm только для SQLite.
Ну и от сторонних поставщиков есть поддержка IBM DB2, Microsoft SQL Server, Firebird, ODBC. Все что нужно чтобы заменить одну субд на другую — конфиг поправить, а к единой абстракции для работы с данными все сводит как раз ORM.
UFO just landed and posted this here
Ну тем не менее те же оконные функции django поддерживает (ибо их по моему любая современная субд умеет). Да и вообще список поддерживаемых возможностей субд шире, при том что и сам список субд тоже шире. И это первый фреймворк с ORM про который я вспомнил. Наверняка можно еще более крутые варианты найти.
UFO just landed and posted this here
UFO just landed and posted this here
>Это конкретная ложь! И нечего её прикрывать ORM-ом.

Вы же поняли, что там речь об объектной модели? Если да, то вы можете словами всем объяснить, в чем конкретно все-таки ложь?
UFO just landed and posted this here
Подождите, давайте сначала по делу, а потом уже лирику про стебарей. Вот смотрите, я практически ничего не знаю про 1С. Предлагаю для простоты разобрать первый случай:
В 1С объект читается всегда целиком, в том числе с табличными частями, но не более того (без каких либо связанных данных). Как следствие, данных читается:

либо слишком много — если надо получить только одно поле (реквизит)...
Как я это понял… Идет речь об объектной модели в 1С, и речь о том, что в случае, когда мы хотим получить значение реквизита объекта, то объект будет получен из базы данных целиком, поэтому и написано «слишком много». То есть в данном конкретном случае это осуществляется не слишком эффективно. В подтверждение этих слов там приведена ссылка на сайт 1С (https://its.1c.ru/db/metod8dev#content:2754:hdoc), где написано:
Однако следует учитывать, что при обращении к ссылке считывается весь объект целиком. То, что он ранее считывался и находится в кеше, здесь не поможет, так как при работе транзакции используется отдельный кеш. Соответственно, затраты на получение одного или двух реквизитов могут оказаться неоправданно большими.
Так в чем кокретно здесь все-таки ложь? По приведенной ссылке что-то написано не так? Автор статьи как-то неправильно интерпретировал то, что там написано? Давайте конкретно, а то
«В 1С получают по одному реквизиту (не полю конечно же) все и постоянно»
Получать то получают по одному реквизиту, а сколько данных при этом из базы достается? Ведь именно это обсуждается в статье.
UFO just landed and posted this here
При обращении к ссылке считывается весь объект целиком, а не при получении, если я правильно интерпретирую информаци по ссылке. Если грамотно комбинировать запросы и объектную модель, никакого избыточного чтения не будет.

Пример: Есть у нас документ поступления на склад. Нам нужно получить его дату, куча других реквизитов нам не нужна.
Можно использовать объектную модель и написать:
Дата = ДокументСсылка.Дата
Но тогда в кэш попадут все реквизиты документа.

А можно использовать запрос:
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
               |	Поступление .Дата КАК Дата
               |ИЗ
               |	Документ.Поступление КАК Поступление 
               |ГДЕ
               |	Поступление .Ссылка = &Ссылка";
Запрос.УстановитьПараметр("Ссылка",ДокументСсылка);
Дата = Запрос.Выполнить().Выгрузить()[0].Дата;
Тогда ничего лишнего читаться не будет.

Знаете, безотносительно сравнения с lsFusion, это очень печальный код. Чтобы вы понимали, с чем я сравниваю: documents.Where(d => d.Id == someId).Select(d => d.Date).

Это примитивный случай — подобные запросы в реальности не пишутся. Обычно читается не один реквизит, а сразу пачка. Плюс используются запросы к виртуальным таблицам, создание временных таблиц, соединения… и куча всего ещё. Не думайте, пожалуйста, что реальный код состоит из таких кусков.

Но в целом, согласен. Язык 1с сложно назвать лаконичным. Хотя, кмк, лаконичность не должна быть в ущерб читаемости.

Я не думаю, что с усложнением кода он станет лучше, только наоборот.

Да вот ни фига, вполне частый случай когда нужны именно один/два реквизита. Для этого конечно есть БСП с функциями общего назначения, но это все равно такое себе. Весь этот геморрой с передачей имен нужных полей в виде строк, функция возвращающая не типизированную структуру…
«Преждевременная оптимизация — корень всех зол» (с) Дональд Кнут
Есть набор инструментов. Каким из них воспользоваться решает программист. Плохой программист использует неправильные инструменты.
Вот только речь не про оптимизацию, а про упрощение написания и понимания кода.
Если речь не про оптимизацию, то для понимания и написания кода абсолютно не важно, считается весь объект целиком или нет. Пусть хоть всю базу на клиент скачивает.
Ну передергивать не нужно. Речь о читабельности при сохранении адекватного уровня производительности.
Использование объектной модели не делает уровень производительности неадекватным. Неправильное её использование — делает.

Давайте поразмышляем, что бы мы сделали чтобы исправить чтение всех реквизитов объекта при чтении одного реквизита. Инструкции препроцессора? Некрасиво. Всегда читать только нужный реквизит? Тогда для того, чтобы прочитать 10 реквизитов, нужно 10 запросов в базу или переписывать механизм форм. Сделать какой-то новый механизм для получения только нужных реквизитов? Что-то типа sql, но без возможности изменять данные. Неплохо бы будет добавить агрегатные функции, соединения, создание временных таблиц… ой… так это в 1с уже есть.

Вы не подумайте, я не фанатик 1с. Многие моменты меня подбешивают. Но когда я вижу что-то странное, я пытаюсь понять, а почему сделано так а не иначе. Что будет, если сделать иначе. Как дорого это будет реализовывать и «стоила бы игра свеч».

Я мечтаю о нормальном ООП в 1с, но в тоже время понимаю, что при подобной гибкости требования к программистам существенно возрастут.
Вот даже инструкции препроцессора для методов аля аннотации ситуацию бы заметно улучшили. Либо тупо у ссылки добавить метод «ПрочитатьРеквизиты()» который бы привязывал к ссылке кэш с выбранными реквизитами — уже бы кучу боли убрало это дело. Проблему N+1 это конечно не решает, но и для нее можно было бы человеческие решения придумать (например добавить тип МассивСсылок с методом ПрочитатьРеквизиты, как вариант).
Причем это все даже не потребовало бы заметных изменений в языке с т.з. программистов и было бы обратно совместимо.
Про более красивые решения с типизированным DSL я даже не говорю(
Данные и так читаются из кэша, если это не транзакция. Функция чтения только нужных реквизитов есть в бсп, да и самому её реализовать не сложно. Также несложно реализовать чтение значений у массива ссылок. Но функции, не методы — менее удобно, это да.

Вроде бы нельзя проверить, в кэше ли значение, но через модули с повторным использованием можно «сделать свой кэш». Хотя, возможно, я неправильно представляю, как работает платформа…

Вряд ли это существенно упростит разработку и увеличит быстродействие.

Кстати неиспользование глобального кэша при транзакциях не лишено смысла. Лучше уж сделать лишний запрос, чем писать в базу неактуальные данные.
Проблему функций БСП я уже называл. Имена реквизитов передаются в виде строки, а возвращаемый тип Структура с ключами соответствующими именам реквизитов. Далеко не самый лучший вариант с т.з. поддержки кода. С функциями повторного использования есть другая проблема. Платформа не будет инвалидировать кэш при изменении значений реквизитов. Таким образом в кэше можем получить не консистентные данные. Тогда как если реализовывать нормальный механизм кешей на уровне платформы — кэш должен именно к конкретному экземпляру ссылки привязываться, чтобы жил лишь до тех пор пока жив конкретный экземпляр ссылки.
Вообще как я и говорил в идеале бы какой типизированный DSL получить, который бы позволял одновременно и не городить мутные схемы с кешами и при этом полноценно поддерживался бы IDE, но, увы, этого не будет.
Проблему функций БСП я уже называл. Имена реквизитов передаются в виде строки
Можно написать функцию с использованием метаданных в качестве параметров. Можно для этого написать прослойку для функции БСП.
а возвращаемый тип Структура с ключами соответствующими именам реквизитов.
А что вы бы возвращали? Что-ти типа «специальной ссылки» только с нужными данными? Так никаких принципиальных отличий от структуры при работе с таким объектом не будет… за исключением методов.
кэш должен именно к конкретному экземпляру ссылки привязываться, чтобы жил лишь до тех пор пока жив конкретный экземпляр ссылки.
С кэшем всё интереснее. С одной стороны, да, можно очищать кэш с уничтожением ссылки. А с другой, если кэш сохранять, можно сэкономить вызовы к БД.
Вообще как я и говорил в идеале бы какой типизированный DSL получить, который бы позволял одновременно и не городить мутные схемы с кешами и при этом полноценно поддерживался бы IDE, но, увы, этого не будет.
Я так понимаю, основная претензия — неработающее дополнение кода для таких структур? Если да, то это не проблема языка, а проблема IDE. Но напрягает, согласен.
Можно написать функцию с использованием метаданных в качестве параметров.

Довольно громоздко выходит по объему кода. Да и возвращаемое значение прежним останется.
А что вы бы возвращали? Что-ти типа «специальной ссылки» только с нужными данными? Так никаких принципиальных отличий от структуры при работе с таким объектом не будет… за исключением методов.

Да обычную ссылку, просто обращение к части реквизитов которой не будет вызывать чтение объекта, ибо закешировано.
С кэшем всё интереснее. С одной стороны, да, можно очищать кэш с уничтожением ссылки. А с другой, если кэш сохранять, можно сэкономить вызовы к БД

Ну, главное чтобы платформа его инвалидировала.
Я так понимаю, основная претензия — неработающее дополнение кода для таких структур? Если да, то это не проблема языка, а проблема IDE. Но напрягает, согласен.

Автокомплит, невозможность рефакторинга.
Давайте поразмышляем, что бы мы сделали чтобы исправить чтение всех реквизитов объекта при чтении одного реквизита.

Декларативный SELECT, показывающий нужные реквизиты. Собственно, как в моем примере.

Однажды мне пришла в голову идея как сделать декларативный select для 1Са, вот прям как в вашем примере, но с русским синтаксисом. Сделал. Запостил на инфостарт. 1Сники были более-менее солидарны в мнении что я им втираю дичь и язык 1С прекрасен.
А у вас там типобезопасность была, или как в БСП, все строками передавалось и структуры гоняло с соответствиями? Проблема 1с что на уровне прикладного кода реализовать такое разве что кодогенерацией возможно. И нужны какие-нибудь плагины для EDT это поддерживающие.
где типобезопасность и где 1С? )))
строками, типа Справочники.Организации.НайтиПо(«ИНН», МойИНН);
В том и проблема. В случае с использованием объектной модели или запросов либо платформа имена реквизитов проверяет, либо можно самому через конструктор запросов проверить, лучше чем ничего, но чисто строки это грусть.
А как будет выглядеть код для получения нескольких реквизитов? Например для пяти. Неужто будет более читабельно, чем запрос?

Но по факту, это же синтаксический сахар. Я могу в 1с сделать нечто подобное.
ПолучитьРеквизит(Документы,"d => d.Ссылка == "+someId,"d => d.Дата")

Самописная функция ПолучитьРеквизит будет формировать из параметров запрос.
А как будет выглядеть код для получения нескольких реквизитов? Например для пяти.

А так же.


documents
.Where(d => d.Id == someId)
.Select(d => new {
  d.Date,
  d.Number,
  d.Amount,
  d.Shipping,
  d.Billing
})

Но по факту, это же синтаксический сахар.

Нет, это достаточно большой кусок функциональности. Ну и синтаксический сахар, да, в том числе.


Я могу в 1с сделать нечто подобное.

Вот только в моем примере нет ни одной строки, работает подсказка, работает типизация, не надо волноваться за безопасность параметров и так далее, далее, далее.


Ну и просто много вам писать придется, очень много.

я вот даже полез в свою статью, посмотреть было ли там такое — оказалось было! вот так получится:
Справочники.Номенклатура
.НайтиПо(«ВидНоменклатуры», МойВид)
.ИПо(«СтавкаНДС», Перечисления.СтавкиНДС.НДС20)
.ПолучитьПараметры(«Ссылка, Наименование, СтавкаНДС»)
вернет массив структур с соответствующими данными
Вот только безопасности и поддержки IDE у вас никакой, в отличие от(
С EDT наверно можно сделать через кодогенерацию и какие то плагины, но не факт.
вообще, я могу путать, давно это было, но если написать что-то типа:
НоменклатрураОбъект.РеквизитКоторогоНет
то конфигаратор вообще это проглотит и проблемы будут только в рантайме, так что с этим не только в моем инструменте проблемы.
а так то с type safe конечно лучше — никто не спорит
Не, конфигуратор на такое ругается. Правда не во всех случаях. Но вот например в формах, модулях объектов — точно ругается. EDT также ругается когда параметры функций типами аннотированы.
UFO just landed and posted this here
Например, потому, что время перехода с клиента на сервер может превышать время самого серверного вызова. Если программист начнет ходить с клиента на сервер «легко и просто» — стоимость накладных расходов превысит полезность реализуемого кода. Ведь не все конфигурации работают в гигабитной+ локальной сети. А веб-клиент и мобильный клиент: типичные представители решений, где переход клиент-сервер совсем не дешевое удовольствие.
UFO just landed and posted this here
По хорошему, надо задуматься — какие действия можно пакетировать и выполнять за один серверный вызов. И по результатам сделать такой код, который а) минимизирует количество серверных вызовов и б) минимизирует объем передаваемых данных.
Мобильная платформа предоставляет возможность оценить качество канала. На большой платформе можно использовать знание о том, что ты в веб-клиенте.
Касаемо внешней компоненты, то надо смотреть о чем она и как ее планируется использовать. Если к АТС-ке подключаемся в какой-то форме, то имеет смысл разнести получение и использование по двум методам (благо переход клиент-сервер-клиент там есть на системном уровне). Если компонента используется при старте клиентского приложения — стоит реализовать все эти действия в каком-то одном стартовом вызове сервера.
А иначе будет как с ПриВыводеСтроки в толстом списке. Фича полезная, но с ее помощью можно список остановить.
Если грамотно комбинировать запросы и объектную модель, никакого избыточного чтения не будет

Ок, спасибо. В том месте статьи, которое мы сейчас обсуждаем, речь идет конкретно об объектной модели, без использования запросов. Поэтому и нет там никакой лжи.
UFO just landed and posted this here
Использование объектной модели для получения одного реквизита (поля) представляет собой неправильное использование инструмента. Это как забивание микроскопом гвоздей. Автор выбрал неправильный инструмент для решения задачи. Язык 1с достаточно гибок, чтобы позволять «стрелять себе в ногу».

Пример более близкий к теме обсуждения. В 1с можно читать текстовые файлы построчно или целиком. При чтении целиком он полностью загружается в память. И можно даже дополнить статью чем-нибудь типа «смотрите, 1с потребляет гигабайт памяти при чтении гигабайтного текстового файла» и умолчать, что для чтения больших файлов есть другой способ.
Ну тут дело в том что объектная модель в других ORM фреймворках часто позволяет читать один реквизит или несколько, вместо того чтобы читать объект целиком.
А в 1с не позволяет. Можно считать это особенностью языка. Есть возможность получать один реквизит другими средствами.

Java не позволяет напрямую управлять памятью, но это не значит, что джава не достойна своей популярности.
Ну, во-первых, есть jni, во-вторых, есть возможность менять сборщики мусора (либо вовсе без сборки мусора работать, слышал тоже применяется), в третьих те же пулы объектов вполне себе разновидность ручного управления памятью почти. И да, отсутствие ручного управления памятью на некоторых задачах действительно недостаток.
Впрочем, мы не java обсуждаем.
И да, особенность языка или платформы доставляющая неудобства — это минус. А в случае с 1С приходится либо городить кучу бойлерплейта, либо рисковать ошибиться в имени реквизита или свойства структуры передавая его строкой, либо смиряться с потерей производительности на пустом месте.
Пример с java я привёл, чтобы показать, что все языки разные. У каждого свои достоинства и недостатки.

Особенности, доставляющие неудобства — это минусы. Особенности, доставляющие удобства — это плюсы.

Отсутствие прямого управления памятью — это минус. Сокращение утечек памяти — это плюс.

Статическая типизация добавляет бойлерплейта. Статическая типизация не нужна? Это риторический вопрос и тема для холивара)

В 1с много других более существенных проблем (часть из них описана в статье), но мешать в кучу «кривую асинхронность» (с которой уже ничего не сделаешь) и ограничения объектной модели (которые вполне можно обойти) неправильно, кмк.

Но в целом, я вас понял. Да, использование запросов вместо объектной модели не всегда делает код лучше. Хотя если не использовать объектную модель в циклах, существенной потери производительности обычно не происходит.
UFO just landed and posted this here
Как давно появилось, не могу сказать, но есть «ЧтениеТекста», позволяющее читать файл построчно.
JSON тоже можно прочитать либо целиком, либо в потоке.
UFO just landed and posted this here
ЧтениеТекста появилось в 8.3.3 (середина 2013 года)
Это как забивание микроскопом гвоздей. Автор выбрал неправильный инструмент для решения задачи. Язык 1с достаточно гибок, чтобы позволять «стрелять себе в ногу».
Речь же не о том. В статье сначала рассматривается объектная модель, говорится о том, что в части случаев ее использование неэффективно и нужно переходить на запросы. А дальше рассказывается о проблемах с запросами в 1С. По-моему, все вполне понятно, если прочитать статью.
По тексту может сложиться впечатление, что и объектная модель хрень, и запросы хрень. А на самом деле объектная модель не предназначена для чтения, а запросы не предназначены для записи. Если использовать всё по назначению, никаких проблем не будет.

Ну и стоит учитывать, что если использовать объектную модель для чтения, ничего особо страшного не произойдёт в большинстве случаев.
UFO just landed and posted this here
Смотрите, сейчас тут делается «клон» Odoo на lsFusion (под Apache 2.0). В частности там закладывается аналогичная логика работы с себестоимостью. Например вот здесь:

github.com/lsfusion-solutions/mycompany/blob/master/src/main/lsfusion/inventory/ledgers/CostLedger.lsf

Правда по ссылке логика усложнена немного на самом деле для того чтобы работать на больших объемах (в частности аналогичные механизмы работают при приеме реализации в сетях гиперов, причем делается это прямо в онлайне).
Вообщем из статьи стало понятно, почему им столько платят. Там молоко за вредность давать надо.
Статья Огонь. Вскрыты все недостатки 1С. ;-)
Насчет аксапты не скажу, но навижн я щупал, вот статья про сравнение с 1С: catalog.mista.ru/public/101933
:)))
Самое любопытное, что все правильно. С точки зрения программиста Навик намного хуже 1С.
Но внедрять все равно в конечном счете удобнее Навик.
Просто напросто прикладной функционал более корректный — раз.
И намного проще пользоваться функционалом хранилищ данных, кубов, отчетов и т.д. Не тем функционалом, что в системы встроен — в Навике вообще все печально по сравнению с 1С. А обычными решениями Microsoft SSAS, Power BI и т.д. Из табличек Навика намного проще информацию вытягивать и нет перепроведения.

Возможно в 1С и есть некая избыточность, но все в коплексе никто не смог повторить, увы. Так бы я бы первый соскочил с 1С из-за ее маркетинговой политики и отношения к программистам.
Но пока нигде в другом месте нет такого кайфа от быстрой разработки.

Открою тайну - на питоне можно разрабатывать с такой же скоростью. Этот язык меня удивил скоростью разработки. У меня есть опыт и на 1С, и на питоне.

Получается, вопрос лишь в наличии фреймворка для питона. Но его нет.

Получается, вопрос лишь в наличии фреймворка для питона. Но его нет.

https://ru.wikipedia.org/wiki/Odoo

Система написана на языке программирования Python, клиент-серверное взаимодействие реализовано посредством протокола XML-RPC. В качестве системы управления базами данных для серверной части используется PostgreSQL.