Убийца 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С:Бухгалтерии. И будет горько сожалеть об упущенных возможностях.

fixin

Программирую на 1С с 1999 года. В 1С просто Гений. В 2020 году ушел из офиса на вольные хлеба фриланса. Принимаю заказы.

Читайте также:

комментария 32

  1. Павел:

    Бред какой-то… Убивать решение из 90-х надстройкой над решением из 90-х

    • решение из 90х по скорости разработки приложений с базой данных не превзойдено ни одной из сред в 2021-м. прикинь!
      умели делать в 90х!

      • Павел:

        Ты до конца дописывай, не стесняйся… Для задач из 90-х, со скоростью работы из 90-х, с масштабируемостью из 90-х, с лиценизированием из 90-х

        • Для задач из 90-х — НЕ СОГЛАСЕН
          со скоростью работы из 90-х — НЕ СОГЛАСЕН. Скорость, кстати, не всегда важна.
          с масштабируемостью из 90-х — ДА
          с лиценизированием из 90-х — ДА

  2. fajij28770:

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

    кем не найден? такие приложения сейчас пишутся на раз-два в любой популярной среде (шарпы, ява, пайтон, нода).
    да даже на плюсах с qt-ом можно (хотя из-за отсутствия нормального reflection там все довольно топорно сделано по сравнению с вышеперечисленными средами).

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

    зато не лень тратить время на решение проблем, которых больше ни у кого кроме тебя нет.

    • увы, программирование на 1С и «в любой популярной среде» это две большие разницы.
      В 1С программист избавлен от слишком большого количества рутины.
      Вот, ознакомьтесь: https://geniy1s.ru/kakogo-ubijczu-1s-ya-hochu/

      • fajij28770:

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

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

        ну а то, что тебе в 1с быдлокодить проще, легко объясняется — за тебя много всего делают прогеры самого 1с (принимают архитектурные решения, хоть и кривые, фигачат типовые, прикручивают отчеты, связи с внешними средами и т.п.). отсюда создается впечатление «легкости». когда ты открываешь какое-нибудь IDE в Java у тебя наступает прострация, потому что это по сути конструктор, из которого нужно все самому собирать.

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

        • Все это замечательно, но несколько голословно.
          Давай рассмотрим такие моменты на этих замечательных IDE:
          1. Как объявляются элементы формы и привязываются к данным.
          2. Как создаются сущности, более высокого порядка чем таблицы, например, регистр остатков по движениям товаров по складу.
          3. Какой инструмент отчетности используется и как он выгружается в Эксель?
          4. Как выполняется клиент-серверное разделение кода? Хотят тут проще — та же Фузина все делает на сервере, а на клиента только отображает.

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

          • fajij28770:

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

            чтобы не быть голословным, раскрою тебе один пункт (остальное лень расписывать, все это гуглится за пару минут).
            >1. Как объявляются элементы формы и привязываются к данным.
            общераспространенный подход к формам заключается в том, что среда обычно предоставляет какую-то библиотеку стандартных элементов, обычно все это выполнено в виде ООП + имеется какая-нибудь визуальная клепалка форм с сохранением результатов в xml/json подобный формат.

            помимо этого сейчас почти в любом общеязыке есть библиотеки для декларативного способа работы с формами (qml, React, JavaFX, flutter, сотни их). привязка данных осуществляется любым удобным для решения конкретной задачи способом, хочешь пиши запросы прямо в обработчиках формы, хочешь используй классический MVC, хочешь — новомодные MVVM фреймворки с какими-нибудь функциональными стейт менеджерами типа redux-а. опять-таки, почти все библиотеки сейчас предоставляют какие-то разумные дефолты для быстрого старта, приложки уровня TODO-list бутсрапаются скриптами в полуавтоматическом режиме. дальше у тебя условно безграничные возможности по допиливанию.

          • Много общих слов ни о чем. Лучше на примере, чтобы привязка данных была проще чем в 1с.
            ну скажем в том же Аксессе формы тоже рисовались довольно просто. Без ООП-извращений.
            Или вот еще что скажи — удалось в этих «декларативных описаний» уйти от ООП-наследования и горы мусорного кода?

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

          • Павел:

            Регистр сущностью высокого порядка не является. Тем более в 1с. Это mvc, причем крайне примитивное

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

  3. bob32:

    Можешь четко сформулировать область применения «убийцы 1с». Т.е какие именно «карманные приложения с базой данных» ? Т.е здесь очень большая вариативность и , к примеру, какой-нибудь ежедневник или TODO-list гораздо быстрей сгородить на Python/Go + SQLite чем на всяких 1С (в случае с Go у тебя будет вообще 1 exe-шник со всем необходимым — ничего дополнительного не надо)

    • сгородить может и быстрее, а развивать нет. потому что при возрастании сложности «огород» уже не катит.
      Четко сформировать не могу пока что.

      • bob32:

        Проработка требований — основа. Надо четко понимать какие задачи мы хотим решать. Возрастание сложности скачкообразно и для каждого уровня свои решения и архитектуры. В итоге будет получаться та же 1С.
        Поэтому надо фиксировать область применения. И развивать на популярных язык и технологиях проще, т.к спецов больше. Питонистов нычне вообще под любой лавкой найти можно. Python + Django даст из коробки админку для работы с базой, ORM и т.д. Для карманных приложений как раз.
        Чтоб проще было развивать и масштабировать (до какого-то уровня) — выносим логику в отдельные микросервисы с API. При просадке производительности они могут быть переписаны на том же Go

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

        • Вот хочу инструмент для написания небольших приложений с базой данных. Но чтобы не собирать этот инструмент из 100500 библиотек… 😉

    • Павел:

      Ну и заточенность 1с про проводки — да это никто не отменял. Т.е. 1с умрет вместе с регл. учетом в текущем виде

      • 1С давно не «про проводки», регистры там шире проводок используются. В УТ вообще проводок нет.
        Вы отстали от последних новостей про 1С, где-то находитесь в 2004-м году.

        • Павел:

          1с за пределами бухгалтерии никому не нужна в современном мире

          • В мире или в России. Если речь про Россию, то откройте для себя УТ, УПП, ERP. 😉
            А в мире думаю, 1С не взлетит. Из-за равнодушия к разработчикам и тупой политики лицензирования.
            да и вообще не умеет 1С в любовь.

  4. Павел:

    Огород в 1с наступает раньше. Такая вот печалька

    • Павел:

      Вместо dll с парсером этой mxl которая включалась бы в проект по щелчку мышью надо покупать проприетарную программу, неведомую за бургом, ее устанавливать, лицензировать

      • dll стоила бы дороже 600 рублей.
        К тому же парсить MXL (проприетарный формат 1С) — то еще удовольствие.

        • Павел:

          Да рассылки в mxl надо в голову гвоздь забивать

        • bob32:

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

          • у меня страха нет. Недавно клиент обратился с вопросом цены конвертора PDF в MXL. Вот что я ему ответил:

            посмотрел, готовых конверторов нет.
            Есть онлайн-конверторы PDF в XML, из которого скорее всего можно собрать MXL, но объемно.
            Можно напрямую разбирать PDF, это текстовый формат, по сути (типа XML), но это тоже крайне объемно.
            В общем сейчас готовых решений нет, задача разбора PDF в MXL порядка 70.000 рублей стоит.
            Задача разбора XML в MXL порядка 30.000 рублей стоит.

            То есть, все упирается в объем работ. А не в страх.

    • неа. в силу бОльшей формализации предметной области 1с лучше борется со сложностями, чем PURE JAVA.
      Многие вещи, которые в 1С можно написать в одно лицо, в JAVA доступны только команде.
      Сила абстрагирования!

      • bob32:

        Ты не правильно сравниваешь. Java — язык, 1C — платформа.
        Если брать Java с платформами, скажем та же Cuba, Spring со своей экосистемой, Eclipse, JHipster и т.д — то в одно лицо тоже дофига всего делается.

        • Дофига да не дофига. В 1С проще и быстрее бизнес-логику и приложения под бизнес-БД писать. Ибо уровень абстракции ближе к бизнес-процессам.

          • fajij28770:

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

          • А при чем тут ERP? ERP можно и на си написать. Тот же Навижн — это по сути Аксесс.
            Я про скорость разработки.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *