Убийца 1С на 1С!
Среди программистов 1С очень популярна тема «убийцы 1С», в частности и потому что на 1С очень удобно разрабатывать небольшие карманные приложения с базой данных, но лицензия начинается от 13.000 рублей, поэтому такие маленькие приложения никто не купит:
Поэтому есть запрос на такой же инструмент разработки приложений, как 1С, но дешевле. Бесплатно, недорого или за процент от продаж софта.
До сих пор такой убийца не найден, к сожалению.
Но вот, что интересно, он может быть написан на самой 1С. Дело в том, что 1С выпускает множество базовых решений, которые представляют собой практически полноценную платформу, но для одного пользователя и при этом очень дёшевы, например, 1С:Деньги можно купить за 600 рублей:
«Убивающее решение» может заключаться в том, что разворачивается SQL-база, клиенты с которой работают в базовых, дешевых, версиях 1С.
При этом придется, конечно, реализовывать логику отображения данных из базы данных в формах и списках, но подобные технологии уже знакомы программистам 1С.
А помимо этого доступны все привычные инструменты, которые являются преимуществом 1С — таблицы значений в памяти, управляемые собираемые runtime формы, возможность программирования на языке 1С.
При этом код состоит из совокупности внешних обработок, которые хранятся в SQL-базе и при их обновлении кэшируются в базы пользователей.
Технически такая схема вполне реализуема. И ее преимущество не только в 20-кратной экономии затрат на лицензии. Такая реализация — плавный способ перейти с 1С на нормальную SQL-базу, постепенно 1С-функции можно переписать на не проприетарную платформу.
Но вот юридически схема вызывает сомнения. Тут нужно мнение сообщества. В любом случае, если 1С почувствует сильную конкуренцию от подобных решений, она может указать в лицензионном соглашении на те же 1С:Деньги, что запрещается использовать программу для организации доступа в другую базу данных. И на этом вся техническая красота закончится.
Что скажете? Можно ли убить 1С средствами самой 1С?
Идея подобного решения возникла из практики. Сейчас в России широко внедряется маркировка товаров и некоторые отечественные дилеры стали отправлять поставщикам список марок с их штрих-кодами в графическом виде в MXL-файлах. Это файлы 1С, похожие на Excel.
Одному из производителей товаров, расположенным не в России, потребовалось обрабатывать эти MXL-файлы — сортировать, вырезать необходимые участки, нумеровать этикетки.
Естественно, в их стране про 1С ничего не знали. Покупать 1С им тоже не очень хотелось. Предложение взлома было мною отвергнуто. Я уже хотел предложить им облачные решения, вроде Fresh, но потом вдруг вспомнил про 1С:Деньги. И проблема поставщика была решена за 600 рублей! Они просто запускали внешнюю обработку, которая сортировала с необходимыми отборами исходный большой файл марок в MXL или PDF.
Так что, как видно хотя бы на этом примере, базовое решение 1С позволило избавиться от необходимости «стрелять из 13.000 рублевой пушки по воробьям»!
Ну и резюмируя, скажу, что на мой взгляд, своей проприетарной политикой 1С ограничивает возможности распространения своей платформы. В своё время популяризации 1С 7.7 сильно помогло то, что она легко ломалась пачтами вроде «Соболя». А сейчас время проприетарных платформ разработки уходит…
В конечном итоге, рано или поздно, движок 1С перепишут конкуренты и она останется только в нише 1С:Бухгалтерии. И будет горько сожалеть об упущенных возможностях.
Бред какой-то… Убивать решение из 90-х надстройкой над решением из 90-х
решение из 90х по скорости разработки приложений с базой данных не превзойдено ни одной из сред в 2021-м. прикинь!
умели делать в 90х!
Ты до конца дописывай, не стесняйся… Для задач из 90-х, со скоростью работы из 90-х, с масштабируемостью из 90-х, с лиценизированием из 90-х
Для задач из 90-х — НЕ СОГЛАСЕН
со скоростью работы из 90-х — НЕ СОГЛАСЕН. Скорость, кстати, не всегда важна.
с масштабируемостью из 90-х — ДА
с лиценизированием из 90-х — ДА
>небольшие карманные приложения с базой данных
>До сих пор такой убийца не найден, к сожалению.
кем не найден? такие приложения сейчас пишутся на раз-два в любой популярной среде (шарпы, ява, пайтон, нода).
да даже на плюсах с qt-ом можно (хотя из-за отсутствия нормального reflection там все довольно топорно сделано по сравнению с вышеперечисленными средами).
а тебе просто лень потратить полгода, чтобы изучить новую среду, где работа с крудами сделана в сто раз лучше 1с из коробки и без всяких дорогих лицензий.
зато не лень тратить время на решение проблем, которых больше ни у кого кроме тебя нет.
увы, программирование на 1С и «в любой популярной среде» это две большие разницы.
В 1С программист избавлен от слишком большого количества рутины.
Вот, ознакомьтесь: https://geniy1s.ru/kakogo-ubijczu-1s-ya-hochu/
половина из того, что ты там описал и так есть, другая половина — это сомнительные архитектурные решения из 1с, которые за пределами 1с никому не нужны, потому что есть более гибкие. к тому же ты еще кучу аспектов, которые нужны при написании сложных масштабируемых решений, не учитываешь.
еще раз повторю, все, что надо для написания приложений есть в современных средах, и сделано там все в разы лучше, чем в 1с. даже по тем тривиальным, которые ты тут решаешь видно, что в 1с все очень плохо сделано, достаточно глянуть тут комменты .
ну а то, что тебе в 1с быдлокодить проще, легко объясняется — за тебя много всего делают прогеры самого 1с (принимают архитектурные решения, хоть и кривые, фигачат типовые, прикручивают отчеты, связи с внешними средами и т.п.). отсюда создается впечатление «легкости». когда ты открываешь какое-нибудь IDE в Java у тебя наступает прострация, потому что это по сути конструктор, из которого нужно все самому собирать.
и да, надо понимать, чтобы нормально разбираться в той же Java или любой другой платформе, надо потратить несколько лет. наверное, для человека, который всю жизнь на зп сидит и кроме 1с больше ничем не интересуется, это действительно сложно
Все это замечательно, но несколько голословно.
Давай рассмотрим такие моменты на этих замечательных IDE:
1. Как объявляются элементы формы и привязываются к данным.
2. Как создаются сущности, более высокого порядка чем таблицы, например, регистр остатков по движениям товаров по складу.
3. Какой инструмент отчетности используется и как он выгружается в Эксель?
4. Как выполняется клиент-серверное разделение кода? Хотят тут проще — та же Фузина все делает на сервере, а на клиента только отображает.
Насчет «быдлокодить» — это несерьезный термин, попахивает холиваром, рекомендую его избегать. Мы таки говорим аргументированно, а не «понты бросаем».
тебе на все эти вопросы ответили еще год назад, когда ты у себя на фиксинчике писал то ли про убийцу 1с, то ли про формы. вся твоя проблема, от того, что ты совершенно не понимаешь сути общеязыков, ты застрял где-то в 90-х, когда большие технологические компании клепали визуальные среды программирования с расчетом на то, что скоро смогут заменить квалифицированный и высокооплачиваемый штат программистов чуть ли не на уборщиц (кстати, 1с — это именно такая система).
чтобы не быть голословным, раскрою тебе один пункт (остальное лень расписывать, все это гуглится за пару минут).
>1. Как объявляются элементы формы и привязываются к данным.
общераспространенный подход к формам заключается в том, что среда обычно предоставляет какую-то библиотеку стандартных элементов, обычно все это выполнено в виде ООП + имеется какая-нибудь визуальная клепалка форм с сохранением результатов в xml/json подобный формат.
помимо этого сейчас почти в любом общеязыке есть библиотеки для декларативного способа работы с формами (qml, React, JavaFX, flutter, сотни их). привязка данных осуществляется любым удобным для решения конкретной задачи способом, хочешь пиши запросы прямо в обработчиках формы, хочешь используй классический MVC, хочешь — новомодные MVVM фреймворки с какими-нибудь функциональными стейт менеджерами типа redux-а. опять-таки, почти все библиотеки сейчас предоставляют какие-то разумные дефолты для быстрого старта, приложки уровня TODO-list бутсрапаются скриптами в полуавтоматическом режиме. дальше у тебя условно безграничные возможности по допиливанию.
Много общих слов ни о чем. Лучше на примере, чтобы привязка данных была проще чем в 1с.
ну скажем в том же Аксессе формы тоже рисовались довольно просто. Без ООП-извращений.
Или вот еще что скажи — удалось в этих «декларативных описаний» уйти от ООП-наследования и горы мусорного кода?
Быстрый старт — это хорошо. Но где же набор для написания приложений с БД, чтобы взять и начать писать?
Регистр сущностью высокого порядка не является. Тем более в 1с. Это mvc, причем крайне примитивное
не знаю, что вы подразумеваете под сущностью высокого порядка, спорить не буду.
Управляемые формы в 1с — это тоже деклалаттвная разметка. WPF только для бедных и тупых.
ничто не ново под луной. Сила 1С в синнергии. Она собрала классный фреймворк.
Конфигурации на этой платформе, она конечно, пишет кривые.
Но сама платформа конфетка.
Можешь четко сформулировать область применения «убийцы 1с». Т.е какие именно «карманные приложения с базой данных» ? Т.е здесь очень большая вариативность и , к примеру, какой-нибудь ежедневник или TODO-list гораздо быстрей сгородить на Python/Go + SQLite чем на всяких 1С (в случае с Go у тебя будет вообще 1 exe-шник со всем необходимым — ничего дополнительного не надо)
сгородить может и быстрее, а развивать нет. потому что при возрастании сложности «огород» уже не катит.
Четко сформировать не могу пока что.
Проработка требований — основа. Надо четко понимать какие задачи мы хотим решать. Возрастание сложности скачкообразно и для каждого уровня свои решения и архитектуры. В итоге будет получаться та же 1С.
Поэтому надо фиксировать область применения. И развивать на популярных язык и технологиях проще, т.к спецов больше. Питонистов нычне вообще под любой лавкой найти можно. Python + Django даст из коробки админку для работы с базой, ORM и т.д. Для карманных приложений как раз.
Чтоб проще было развивать и масштабировать (до какого-то уровня) — выносим логику в отдельные микросервисы с API. При просадке производительности они могут быть переписаны на том же Go
Но надо помнить, что если начали строить шалаш, то его нельзя будет переделать в небоскреб. Все развития имеют некоторый потолок, определяемый исходной архитектурой.
Вот хочу инструмент для написания небольших приложений с базой данных. Но чтобы не собирать этот инструмент из 100500 библиотек… 😉
Ну и заточенность 1с про проводки — да это никто не отменял. Т.е. 1с умрет вместе с регл. учетом в текущем виде
1С давно не «про проводки», регистры там шире проводок используются. В УТ вообще проводок нет.
Вы отстали от последних новостей про 1С, где-то находитесь в 2004-м году.
1с за пределами бухгалтерии никому не нужна в современном мире
В мире или в России. Если речь про Россию, то откройте для себя УТ, УПП, ERP. 😉
А в мире думаю, 1С не взлетит. Из-за равнодушия к разработчикам и тупой политики лицензирования.
да и вообще не умеет 1С в любовь.
УПП уже закрывают «во всем мире». ERP такая же унылая поделка. Дико переусложненная, как для юзера, так и для разработчика из-за примитивной объектной модели. Одна сущность разбросана на несколько объектов в 1с и согласование их отдано на волю пользователей и кривых скриптов как в предыдущей статье про штрихкоды
Меня всегда удивляло, что 1С, купаясь в деньгах, не платит программистам, а главное архитекторам и методистам, в несколько раз выше рынка.
Отсюда и эти поделки вроде Ужасно Плохой Программы и Едва Разумной Программы.
Огород в 1с наступает раньше. Такая вот печалька
Вместо dll с парсером этой mxl которая включалась бы в проект по щелчку мышью надо покупать проприетарную программу, неведомую за бургом, ее устанавливать, лицензировать
dll стоила бы дороже 600 рублей.
К тому же парсить MXL (проприетарный формат 1С) — то еще удовольствие.
Да рассылки в mxl надо в голову гвоздь забивать
ну а что поделать, такова воля Дилера.
Парсил разные бинарные и текстовые форматы. Страх перед написанием парсера бывает лишь до первого парсера более-менее не тривиального формата. Потом все довольно логично и быстро делается.
у меня страха нет. Недавно клиент обратился с вопросом цены конвертора PDF в MXL. Вот что я ему ответил:
посмотрел, готовых конверторов нет.
Есть онлайн-конверторы PDF в XML, из которого скорее всего можно собрать MXL, но объемно.
Можно напрямую разбирать PDF, это текстовый формат, по сути (типа XML), но это тоже крайне объемно.
В общем сейчас готовых решений нет, задача разбора PDF в MXL порядка 70.000 рублей стоит.
Задача разбора XML в MXL порядка 30.000 рублей стоит.
То есть, все упирается в объем работ. А не в страх.
Страх ты скрываешь под «объемом работ». Да, там костылить как в 1с над типовыми не получиться
Извините, я не склонен к психоанализу. И если у меня есть Си и Ассемблер, я выберу Си, как бы «православно» не смотрелся ассемблер.
неа. в силу бОльшей формализации предметной области 1с лучше борется со сложностями, чем PURE JAVA.
Многие вещи, которые в 1С можно написать в одно лицо, в JAVA доступны только команде.
Сила абстрагирования!
Ты не правильно сравниваешь. Java — язык, 1C — платформа.
Если брать Java с платформами, скажем та же Cuba, Spring со своей экосистемой, Eclipse, JHipster и т.д — то в одно лицо тоже дофига всего делается.
Дофига да не дофига. В 1С проще и быстрее бизнес-логику и приложения под бизнес-БД писать. Ибо уровень абстракции ближе к бизнес-процессам.
ага, оно и видно. открой на вики список ERP систем и посмотри на каких языках сделаны самые популярные. что-то 1с среди них не видно
А при чем тут ERP? ERP можно и на си написать. Тот же Навижн — это по сути Аксесс.
Я про скорость разработки.
Процессы которыеиложатся в 1с выросли из бухгалтерии — регистрация первички, накладная, платежка. Первичка дает проводки, проводки — баланс. Все это в рамках одной организации, одним бухгалтером. Все. Более сложные процессы в 1с — это костыли и головная боль
А можно привести примеры сложных процессов. Ну чтобы я понимал, сталкивался я с ними или нет.
Со своей стороны могу привести тему резервирования товара при продаже, где в отделе продаж десяток менеджеров сидит.
Вполне справляется 1С с такими темами.
Ты сам приводил в прошлой статье пример.
Причем простой. Вместо передачи проблемы на уровень субд, где она решалась бы по сути автоматически надо мучаться скриптами в приложении.
Потому что субд в 1с с времен 7.7 это мусорная куча, точнее отношение к ней.
А так — любой учет за рамками глупого российского рсбу — там 1с показывает крайне унылые результаты.
Оно бестолковое как фронт, бестолковое как бэк-офис…
Оно плохо масштабируется, плохо лицензируется…
Крупняк уже наелся 1с-ом и пилит КИС на чем-то своем, разбивая еще молнолиты на независимые сервисы. 1с там есть — сдавать отчетность надо, самим рисовать 3-ю за год версию 6ндфл никому не интересно. Но это все. За ппеделами регл. учета 1с не нужна, знания по ней не монетизируются, молодежь не идет. По крайней мере пока видит иные возможности. Как вам объявление — разработчик 1с от 150 до 180 — в зависимости от опыта. Ваши условные 5-10-15 лет в этом стеке стоят 430 долларов!! Еще есть вопросы почему молодежи нет?
Вы несколько сгущаете краски.
1С хороша как платформа для абстрагирования бизнес логики, для мелкого, среднего и чуть крупнее чем среднего бизнеса.
Самописки проигрывают по уровню абстракции, к тому же это все велосипеды.
Но согласен, что политика лицензирования дурацкая, параноидальная. Все боятся, что их ограбят. 😉