Комментарии 296
С этим что не так?
Интересная штука
Все вышеперечисленное можно сделать в Java: Vaadin + Spring + Hibernate + MySQL. Круто будет выглядеть, летать по скорости и получите море удовольствия.
Если интересно пишите в личку, покажу расскажу с чего начать и как.
Java слишком сложный типизированный язык для этого. Тут нужен бейсик или питон. В Foxpro и Clipper был очень простой код, без ООП
Вы зря думаете, что питон проще, чем Java.
"В Foxpro и Clipper был очень простой код, без ООП" поделки на том и другом извел 1с. Это ему в плюс.
Пробовали? Не знаю как может программисту с опытом как у вас, повернуться язык назвать Java слишком сложной.
У Java очень большой слой легаси и костылей. Именно они в основном и добавляют сложность самому языку.
мне не нравится, когда формы описывают через классы (ООП)
Во всяких Delphi именно так и делается. Это позволяет писать меньше кода. Как раз формы - это то, куда ООП подходит идеально;) А кодировать дизайн простыней кода - это плохая идея на любом языке.
Удивительным образом, описание форм через классы — это свойство не языка, а конкретного UI-фреймворка в нем.
Пробовал. Вот пытался рэндзю написать: https://fixin.livejournal.com/1575100.html
А вы точно уверены, что опытные Java-разработчики напишут то что вы написали, так как вы написали? Может, главная причина того что у вас получилась жесть в том, что вы просто не знаете Java?
Вы комментарии к той заметке читали? Простыня г***кода.
На самом деле Java из-за строгой типизации очень часто выигрывает питону в простоте. Тут конечно долго можно спорить, но Java гораздо более предсказуема в поведении, чем Python.
Ради интереса посмотрите код фреймворка Django. Это фреймворк старой школы: модели, ORM, представления, шаблоны и прочее. Я бы не назвал его простым.
А разве строгая типизация усложняет язык? Почему вы так думаете? Без строгой типизации так же нужно понимать что такое тип переменной, пусть он и не указан явно. Просто нет проверки на уровне компиляции, из-за чего много ошибок всплывают в процессе исполнения. А так в чем усложнение?
Питон вообще-то тоже строго типизированный. Вы говорите о статической типизации.
в этом плане мне нравится бейсик и работа с COM-объектами, там не нужно указывать типы объектов, а просто написать, что ты хочешь с ними сделать.
Типизация - лишняя, как бы это сказать культурно, мастурбация.
Типизация — лишняя, как бы это сказать культурно, мастурбация.
Лишняя она ровно до тех пор, пока вы не выясняете, что вы хотите сделать с объектом то, что с ним сделать нельзя. Статическая типизация позволила бы узнать об этом до запуска приложения.
можно писать приложения качественно, тогда об этом думать не нужно
Ну да, писать приложения надо быстро, качественно и без ошибок. И тут как раз хорошо, когда инструмент тебе помогает, автоматизируя часть рутины и убирая часть машинальных ошибок.
А вот когда в языке возможны конструкции
b = f(a) //как должно быть
f(a,b) //неправильный вызов
Причем во втором случае ни компилятор, ни интерпретатор не сообщают об ошибке, то можно попасть на многочасовую отладку.
Знаете, в моем опыте ровно наоборот: чтобы писать приложения качественно, приходиться думать. И чем больше этого "думать" можно переложить на компьютер в виде проверок, тем лучше.
Зависит от сложности проекта.
Когда я пишу шелл-скрипт на десяток строк без всякой логики, там мне все эти типы тоже не нужны.
не усложняет, но на практике она особо не нужна.
Все вышеперечисленное можно сделать в С++: Пишете свою СУБД, свою ORM, свой фреймворк. Круто будет выглядеть, летать по скорости и получите море удовольствия.
Все вышеперечисленное можно сделать и на ассемблере: пишете свою ОС, свою СУБД, свой компилятор ЯП общего назначения, свою ORM, свой фреймворк. Круто будет выглядеть, невероятно летать по скорости и получите море удовольствия.
Простите, абсурд. Java - ЯП общего назначения. Вы на ней можете написать что угодно. На счет летать и моря удовольствия - ой, не факт. Глючный и тормозной код можно писать на чем угодно. 1С - это готовый конструктор. Я коммерческую систему на 1С могу написать за пару дней. Она будет выполнять все свои функции и в ней будет нормальный коммерческий обвес со всякми рюшечками и прочей красотой.
На Java вы будете писать кратно дольше и весь обвес нужно программировать (и это с гибером, спрингом и еще 100500 библиотек). И вы гарантированно не дотащите функционал до уровня 1С. И, ой не факт, что будет летать.
Ну так и платформа 1С тоже на сях пишется
1С — это готовый конструктор. Я коммерческую систему на 1С могу написать за пару дней.
Вот только интент поста (и обсуждения в нем) — как написать альтернативу 1С.
>Пишете свою СУБД
Свою СУБД пишут и поддерживают годами целые команды высококлассных спецов, которые получают по 120-500 тыс. долларов в год. Нужно немножко адекватно оценивать свои силы.
Я вот не думаю, что ORM непременно нужна в базах данных. В 1С как-то без нее обходятся.
Потом сложно искать специалистов которые смогут поддерживать весь этот зоопарк
о. там даже в заголовке написано, что не так: "Декларативная". типа Пролога. Такая вещь никогда не станет популярной. Неудобная.
… а вы не задумывались, почему же 1С за свою платформу берет деньги?
Вы про первый взнос за основную поставку или потом в виде подписки, которая все время растет в цене, притом что качество конфигураций падает ну и плюс поборы за доп.сервисы? Наверное потому что монополист и может ...
Наверное потому что монополист и может ...
А если бы не была монополистом, то не брала бы денег?
Не брала бы. Потому, что с таким подходом при существовании конкурентов исчезла бы.
Хотите получить ответ на свой вопрос, не ответив на мой? - для 1С кстати очень типично ... :) Наверное тогда ей пришлось бы напрягаться, и качество продукта братьев за эти деньги было другое ... но ... - "Запомните, джентльмены: эту страну погубит коррупция." © Человек с бульвара Капуцинов
Впрочем, очень много проектов оставляют продукт 1С как необходимое зло по ведению бухучета(ПБУ и штрафы никто не отменял), но все что уходит в оперативный учет начинает писаться на более быстрых и масштабируемых решениях с применением популярных языков, с экспортом необходимых данных в бухгалтерию.
вот я и хочу писать для упр учета на быстрых и масштабируемых решениях и популярных языках, подскажите, на чем.
Наверное тогда ей пришлось бы напрягаться, и качество продукта братьев за эти деньги было другое
Подождите, за какие деньги? Вы же говорите, что она берет деньги, потому что монополист?
из жадности, конечно же.
А разработчики, которые это всё пишут, тоже зарплату из жадности просят?
Да, блин, чё вы прикопались? Она монополист и этим все сказано. Может выкручивать руки всем и играться с ценой. В 2 раза дороже сделает и все равно будут брать. Если бы был конкурент достойный , то пришлось бы улучшать сервисы и снижать цену.
Я просто не пойму к чему вы клоните? Любите монополии что-ли?
Я клоню к тому, что разработка стоит денег. Разработка платформы, инструментария, поддержка обратной совместимости — все это стоит денег. Как разработчик, который всем этим занимается (не в 1С, заметим), я весьма подозрительно отношусь к заявлениям "давайте просто сделаем то же самое, но open-source".
не то же самое, а проще.
Вы оставили достаточное количество сложных требований. В принципе, одно только требование на полную обратную совместимость увеличивает бюджет на порядок.
Я на 7ке веселюсь с маркировкой и 54 ФЗ. На ней же СЗВ-М и прочая отчётность в фонды. Разработка платформы это такая малая часть, того что нужно для бизнеса. Лет 15 назад был и два-с и ещё куча проектов. Но сейчас законодательство меняется так часто, что главное это именно поддержка регламентированной отчётности. А все остальное.....
Понятно, что стоит денег. Кто ж спорит. Но монополия - в целом это плохо, чисто по законам капитализма
все так
вы бы еще Access посоветовали.
Почему нет? Всяк лучше чем Эксель.
За долго до появления 1С существовало достаточно много добротных настраиваемых АРМов, причем как под MC DOS так и под виндой, которые писались на Delphi, Foxpro, тот же Mc Access. Лично у меня в те далекие (90-е) на 386 крутился пакет Соло, который 100% позволял вести баланс с разносом по оборотным ведомостям ис счетам, материальный учет, статистику, аналитику, генерил все формы отчетной и банковской документации. Там же и редактор форм. В общем песня. 1 раз заплатил, настроил под специфику предприятия и всякие напоминалки. По нему же я и постигал азы работы с PC. Помню, когда появился 1С со своей агрессивной интервенцией и курсами, мне было фиолетово. Пакет Соло был настолько комфортен своей парадигмой и интерфейсной абстракцией, что мне захотелось его повторить под Mc Access. И смог бы, т.к. тму бухгалтерского учета на тот момент уже вполне прочувствовал, вполне справлялся самостоятельно с готовыми налоговыми отчетами и был на ТЫ с в.у. СУБД.
Вообще тама Data Science не моя, я больше по железу, но свой фреймворк я все же построил с ощутимой отдачей по окупаемости.
C Access все плохо: а) он дорогой; б) M$ в России самосократился. А так - неплохой вариант для небольших БД.
Главное что неустранимо плохо в Access - не распределенная база данных. Как с ней работать одновременно многим пользователям? По сути это 1 файл и 1 пользователь.
Насколько помню, там спокойно можно работать 10-20 человек одновременно, а если включить опцию работы с ms sql то сами понимаете.
А там разве есть опция с MS SQL?
Была, по крайней мере. Называлось Access Data Project.
А что оно умело? Могло на основе таблиц MS SQL создать формы? С учетом связей?
А что оно умело?
Оно умело использовать уже написанный для Access функционал (формы, скрипты, отчеты) с БД такой же структуры, лежащей в MS SQL.
Могло на основе таблиц MS SQL создать формы? С учетом связей?
Я такого там не помню.
Формы на основе таблиц могло, а что такое "с учетом связей" не до конца понятно.
Раньше это точно было, сейчас не знаю. В 2008-2009 гг. я использовал Access в таком режиме в качестве клиента для генерации отчетов по данным MS SQL базы.
Формы на основе таблиц MS SQL создавать тоже можно было, насколько помню, в т.ч. и "со связями".
Но я в своем приложении в итоге использовал только формы без DataSource и движок отчетов.
А вот SQL-инъекции приходилось писать по-настоящему, а не на JetSQL, который реализован в нативном Access.
Это лего обойти. По ярлыку на командный файл, файл MS Access копируется в каталог %temp% пользователя, и запускается оттуда. Далее подключается к базе MS SQL Server или любой другой. Таким образом, каждый пользователь работает со своей копией базы, которая является оболочкой и читает и пишет данные на сервер.
Не, там есть возможность работать, правда насколько помню с ограничениями до скольки то подключений. Возможно он и файл бд целиком блочит, уже не вспомню
Access кстати может выступать как клиент к той же Ms SQL. , Подключились в внешней бд и вперёд , запрашиваете данные и работаете с ними в SQL или бесике
Вопрос вот в чем - была ли возможность так же легко строить формы на основе таблиц MS SQL? Или же это просто как источник данных, с которым нужно работать из программного кода.
была ли возможность так же легко строить формы на основе таблиц MS SQL
Обычно сначала все делали на MS Access, а потом просто делали в MS SQL БД такой же структуры.
Точно не уверен что там достаточно удобно все это можно делать. Но это не главное. Главное в другом, почему даже тратить время на проверку нет смысла.
Главное - всем пользователям вашей конфигурации/проги нужно купить не копеечную лицензию на MS Access у Microsoft. Иного варианта просто нет. Т.е. полная завязка на вендора. Вы будете работать на его кошелек.
Если бы хотя бы как XAF - DevExpress - заплатил раз 2 штуки баксов, зато потом продаешь своим клиентам хоть по 2 доллара за экземпляр. Т.е. не занимаешься суб-продажами продукта вендора а продвигаешь свой.
Ну так я и не предлагаю делать то, что хочет автор, на MS Access.
"Главное - всем пользователям вашей конфигурации/проги нужно купить не копеечную лицензию на MS Access у Microsoft. Иного варианта просто нет. " Ознакомьтесь например с Википедией перед тем как что-то категорично утверждать:
Microsoft Access является проприетарным программным обеспечением, то есть для его использования необходимо приобрести лицензию. Однако для использования готовых приложений, созданных с помощью Access, лицензия не требуется. Для работы такого приложения необходима runtime-версия Access [2], которая распространяется бесплатно.
Все там нормально и легко было и есть, говорю так как до сих пор вынужден работать например в связке ADP клиент MS Access - сервер MS SQL 2000-2008-2014. Единственный вопрос только в прекращении развития этой технологии со стороны Microsoft.
>Единственный вопрос только в прекращении развития этой технологии со стороны Microsoft.
Этот вопрос неразрешим в принципе - исходники то закрыты. По сути кто завязался на это - попал в ловушку. Не мудро завязываться на подобные системы.
Ну в реальности открытость исходников не гарантирует длительное развитие проекта. Прекрасно загибаются проекты с открытыми исходниками, а с закрытыми существуют десятилетьями, - это не довод. Не мудро не получать удовольствие и доход от работы пока система развивается и какое-то время после, а вечных систем не существует. )
Проект с открытыми исходниками загнется только если он никому не интересен.
Достаточно, чтобы он перестал быть интересен автору/авторам. Грубо говоря интересоваться и пользоваться средой могут многие, а поддерживать и развивать среду разработки способно на порядки меньше специалистов. Еще меньше найдется тех, кто будет готов подменить на поляне потерявших интерес авторов. Иначе бы я сейчас использовал не Access, а допиленный лично до приемлемого состояния Openoffice Base. )
а) Дорогой только для разработчика, рантайм версия бесплатная. б) Купить вполне реально. 3) Для больших, например, юзаем связку с MS SQL, в том числе и потому что в 1С такое количество данных опасаемся пихать, ибо она в популярных конфигурациях (ака ЗУП, БП ) не особо шустро работает даже в такой же связке c MS SQL, а в режиме файл сервера просто тормозит невыносимо даже на нескольких юзерах, чего не скажешь о том же Access.
нет такой базы Postgree в списке поддерживаемых
Хорошая рекламная статья платформы 1С получилась)
на самом деле 1С противна до отвращения своей жадностью и отношением к разработчикам. От хорошего вендора не тошнит.
Что-то не встречал таких вендоров, кто же это? )))
Согласен в целом. Но вроде команда по УНФ вполне адекватная
Поподробнее плиз. Далек от 1с, так интересно просто. Есть на рынке альтернативы, хотя бы с урезанным функционалом. Ещё вопрос: почему юзают SAP некоторые компании?
Имхо 1с это только РФ, ну СНГ. SAP международный стандарт. Тобишь будь ты филиалом или имея иностранные системы тебе проще интегрироваться, чем писать костыли
SAP имеет очень малый % успешных проектов, но они стараются скрывать это, безмерные бюджеты крайне свойственны что SAP что 1с
Сами платформы стоят копейки, по сравнению с доработкой, поддержкой, интеграциями.
Вот мы такую штуку в MIT-лицензии делаем: https://habr.com/ru/post/666184/
меня больше интересует приложение на своем сервере. ну и как вырожденный случай - приложение, работающее с этим же кодом, но на локальном компьютере.
Смотрится интересно... Postgresql там по каким-то определяющим причинам или можно ждать адаптации под MySQL ? Просто большинство копеечных хостингов это php + mysql. Поставить попробовать было бы проще и доступнее
linq2db + blazor
Дьявол, как говорится, в деталях. Слишком лаконично, чтобы быть ценным.
linq2db библиотека для работы с базой данных. Работаем с sql с помощью linq непосредственно в доменных именах без текстов запросов (строковых переменных).
Blazor библиотека для клиентской части в web. Единый язык использования - c#
Опишите как вы сделаете классические формы CRUD на Blazor - придется ли писать все с нуля или же можно просто указать имя таблицы все формы будут созданы автоматически? Как насчет таблиц со связями?
Если в таблицу добавили 1 поле - нужна ли перекомпиляция или же можно сделать так, что прога сама добавит в форму это новое поле?
Это не готовое решение. Это каркасы для разработки платформы с девушками и блекджеком
Ну вот об этом то речь - разрабатывать платформу кому-то нужно. А каркасов всяких - пруд пруди. Вот когда пытаешься эти каркасы применить для реальной платформы - тогда появляются неустранимые проблемы.
К примеру, связка PostgreSQL+Entity Framework - казалось бы в чем может быть проблема, вроде все ОК. А вот первое подключение занимает около 4000 миллисекунд. Да, да - до 4-5 секунд. Попробовал:
1. ReadyToRun
2. Compiled Queries
3. dotnet-ef dbcontext optimize + .UseModel(DataContextModel.Instance)
- и что? И ничего - по прежнему первый запрос - около 4-5 секунд, даже если немного сущностей в DbContext. Похоже что сделать с этим ничего нельзя - только держать подключение горячим, что проблема для некоторых сценариев.
Например, 1С: Бухгалтерия отслеживает многочисленные изменения законодательства РФ и постоянно обновляется. С этим конкурировать нет смысла.
Нужно немного скорректировать процессы.
МНС сейчас создает формы в каком-то формате. Все производители бухгалтерского ПО повторяют эти формы в своих закрытых форматах. Сама МНС, например, выпускает Налогоплательщик ЮЛ, с готовыми формами.
Должно быть так - МНС готовит формы в открытом формате готовые к подключению ПО, выходят новые изменения в законодательстве, все эти формы уже лежат в репозитории и даже выкачаны конечными пользователями в свои компьютеры. Остается подобрать или разработать инструменты для подготовки таких форм, разработать процесс деплоя форм, взаимодействия с разработчиками ПО и т.д.
да, но эта статья не о том. Я не про 1с-бухгалтерию, а про платформу для быстрой разработки трехзвенки.
А мне, вот, об этом захотелось поговорить. Вы не в курсе почему МНС на текущий момент требует отчетность в том числе и в бумажном виде? Кто-нибудь в курсе?
Платформа для быстрой и простой трехзвенки практически из коробки — Delphi )))
Там это делается очень просто специализированными инструментами
Должно быть так - МНС готовит формы в открытом формате готовые к подключению ПО, выходят новые изменения в законодательстве, все эти формы уже лежат в репозитории и даже выкачаны конечными пользователями в свои компьютеры.
За скобками остался сам учет. Изменения в законодательстве - это не просто формочки. Это МЕТОДОЛОГИЯ. Сменой формочек вы ничего не добьетесь. Ввели 54-ФЗ? Изменение? Изменение. Какие, на хрен, формы? У вас полностью поменялся процесс печати чеков. Вы теперь ОБЯЗАНЫ печатать наименования. А у вас лично вообще мог быть только суммовой учет. Сквозной учет НДС? Вам теперь во всех проводках правильный ГТД нужно тащить, а для этого - учитывать, что пришло, по какому ГТД и еще остатки этих ГТД считать нужно. Система маркировки? Да там дополнительный полноценный учетный контур добавился. С интеграцией в честный знак и кучу других подсистем. ЕГАИС? Аналогично. Еще и УТМ нужно поставить в локалке.
Альтернативная платформа может тоже поддерживать различные СУБД, за счет того, что работа с базой данных должна быть максимально стандартизирована и формализована. Чтобы код одинаково работал на разных базах данных.
Для этого ORM'ы используют. SQLAlchemy, например.
Ну как бы... Есть СУБД Firebird, с кроссплатформенностью и возможностью устанавливать на 32bit/64bit и прочими имеющимися плюшками. Есть проприетарный Delphi, позволяющий создавать приложения под что угодно практически из одного проекта и кроссплатформенный Lazarus, позволяющий бесплатно и без лишних заморочек написать несложное приложение хоть под Linux, хоть под MS Windows и даже с простым генератором отчётов, который при необходимости можно заменить на более серьёзный вариант от Fastreport (г.Ростов-на-Дону). На мой взгляд, более чем достаточно для того чтобы реализовать любую несложную БД и прикрутить к ней всё необходимое, для удобного использования в любой организации.
Единственный недостаток - убогий язык Паскаль, прошлый век. Не годится.
Чем же это он убог? Вы точно знакомы с Лазарус и тем же Фастрепорт?
И не слишком ли много допущений в вашей статье в сослагательном наклонении?
Если все так просто - так почему же вы тратите время на болтовню вместо кода? Или все же есть смысл в вопросах комментаторов о причинах монополизации рынка?
да, я изучал паскаль и Дельфи в универе и даже делал подработку на Дельфи, т.е. получил бабки за программу по автозапчастям, написанную на Дельфи. Сам синтаксис языка паскаль убог и чрезмерно перенасыщен сущностями. Для 90х было норм, сейчас рулят легкие синтаксисы типа питона или даже C#
Ещё раз попытайтесь понять что я вам писал выше: БОЛЬШИНСТВО программ, которыми вы пользуетесь, в т.ч. операционные системы, написаны на этих " убогих и перенасыщенным сущностями" языках.
А хайпа я за свою уже 25 летнюю карьеру насмотрелся. Отлично помню как провозглашали королем Delphi, потом - убийцу всех Java и.т.п.
И таких как вы, я тоже насмотрелся. Pascal ему убог. Вы про обратную пользую запись что-нибудь слышали?
Какие ОС написаны на Паскале?
Каждому языку - своя ниша. Есть c/cpp/asm/rust для этих целей и, мб, еще какие. Здесь же разговор идет о том, как можно было бы написать такой же мощный инструмент как 1С. А выбор языка - дело второе. Ну и к слову, паскаль не так плох, как вы о нем отзываетесь. Я в свое время на нем написал дофига графического софта, пока учился программированию. И в том числе на Лазарусе, когда уже прошел знакомство с мс аксесом, пхп и связкой хтмл+джаваскрипт. На тот момент от паскаля ловил кайф, пока ни познакомился с шарпом.
Какие ОС написаны на Питоне?
Я вас умоляю. Это же жертвы модных трендов с капотами и фреймворками работающими через мистические api..в облаках. Они именно, что в студенчестве у таких же преаодавателей нахватались кое каких умений. но не больше. У Стругацких есть такое название для них: коекакеры. Вот они, бодрые неучи и задают ныне тренды
А все С - не прошлый век? А Java? Python или Basic?
Подавляющее большинство рабочих и регулярно используемых программ написаны на убогих, по вашему мнению, языках из прошлого века. Многие - на языках старше вас.
Ваш подход и тон не вызывают у меня сомнений в продуктивности идеи.
Си красивее Паскаля. Они в одно время родились, я их в 1992-1997 в универе изучал. От Паскаля тошнить хочется.
Красота - это субъективное понятие. Фактов, конечно, у вас не нашлось.
гармонию можно проверить математикой.
длинные идентификаторы служебных слов begin end.
странный оператор присваивания :=
странная работа с массивами
ужасная работа со строками
постоянная типизация
ну что вам еще добавить? Давно паскаль щупал, это отложилось.
гармонию можно проверить математикой.
Без формализации (общепринятой!) понятий — нельзя.
Комментарий с отсылкой к математике в положительном ключе и к типизации в отрицательном — это интересно.
Я синею, дорогая редакция..
Рассуждать о математическом определении при помощи терминов: длинный, странный и ужасный - это что? Новомодный тренд или долгожданные результаты ЕГЭ?
Пора на пенсию, наверное.
-длинные идентификаторы служебных слов begin end.
зато хорошо видно границы блоков )
- странный оператор присваивания :=
потому что не как везде? зато отличается от знака сравнения, и это правильно. )
- странная работа с массивами
в чем странность?
- ужасная работа со строками
не огонь, но простая и понятная, а потому не ужасная
- постоянная типизация
статическая хотели сказать? Так это первый плюс для любого языка, на котором планируется писать что-нибудь серьезное без боли и сторонних приблуд контроля. Следует отличать полноценное написание приложений, а не дерганье из коротеньких интегрированных в систему скриптов методов готовых объектов, как это принято в 1C или мс-офисных приложениях. Но даже в последнем случае статическая типизация это плюс. )
гармонию можно проверить математикой.
Можно попробовать, но математики не вижу. Вижу вкусовщину.
длинные идентификаторы служебных слов begin end.
Вроде как IDE само раньше помогало ключевые слова вставлять.
странный оператор присваивания :=
Дело вкуса.
странная работа с массивами
Тема не раскрыта. В чем странность?
ужасная работа со строками
В чем именно ужастность?
постоянная типизация
Так это же прекрасно, когда компилятор не позволит даже попытаться умножить строку на обьект.
Firebird не подойдет т.к. у него DDL (изменение структуры) не транзакционное. Есть конечно обходные пути (костыли), но PGS куда предпочтительней
Firebird слабоват для сложных запросов. А при наличии ORM + виртуальные таблицы с итогами( и прочими предрасчитанными данными) будут гарантированно сложными. Для нашего похожего кейса прекрасно подошел postgres.
Fastreport тоже нервно курит в сторонке по сравнению с функционалом табличного документа от 1С. Но его можно реализовать конечно же своими силами (работы там много).
"...Отсутствие типизации..." учётная система это всегда "про деньги". Так что, чтобы уменьшить вероятность детских ошибок нужна не просто строгая типизация, а желательно с возможностью указания измерений типов ( а-ля F#) , чтобы случайно не сложить литры с рублями.
не сложишь, из опыта 1с говорю. там нет типизации и норм.
У меня так знакомый перегнал из одной 1ски в другую и в итоге на копейках полтора ляма недосчитался. Проблему конечно же починили, но нетипизированый остаточек остался.
Потерял на точности, а осадочек от типизации?
Весь сыр бор не помню, но там то ли из дефолтных типов получилось что int -> float копейки срезал, то ли fixed point -> float point, но да, типизация как раз борется с такого рода проблемами. Те самые не сложенные метры с литрами как раз про такие проблемы.
Литры и метры это же не стандартная типизация - это все float, double или int
А когда у тебя речь идёт про деньги, то крайне желательно иметь не float, double и int, а некоторый currency с некоторой заданной точности, ну или хотя бы decimal, что как понимаете не очень стандартная типизация, не говоря уже про поддержку этих типов в 1C.
Ну и собственно проблема возникла при миграции базы, поэтому иметь типизированные сериализуемые-десериализуемые структуры заметно безопаснее и позволяет исключать такого рода ошибки как класс.
Приведённые типы я понял, но это некий уровень абстракции, где под капотом будет старый добрый int/float/double/decimal. А значит при неправильной настройке базы или окружения - получилось бы тоже самое
где под капотом будет старый добрый int/float/double/decimal
Какая разница, если в 1С эти абстракции строить в лучшем случае неоправданно сложно, если это вообще возможно без работы с байткодом.
Чтоб было несколько понятнее глубину проблемы - многие при миграции данных сериализуют данные из 1С в XML и потом из XML обратно в 1С. Тут хочешь не хочешь а одним конфигом базы/env не обойдется. Так что это ваше "тоже самое" не очень-то тоже самое.
Вот в том-то и дело, что есть языки, где это "стандартная типизация", и просто так перелить литры в метры не выйдет — будет ошибка компиляции.
Конечно! В нормальной системе типов ограничения на точность можно выразить в типах.
Там нет типизации и не норм. Все эти функции - ИнициализироватьМонструознуюСтруктуруИменемБорисаНуралиева(СтруктураДействий, СтруктураПараметров).
И думай-гадай, че он возвращает, че он хорчет на вход. Лезешь в комментарии, И долго ползаешь по ссылкам/коду вида "см. метод ИнициализироватьМонструознуюСтруктуруКлиентСерверПереопределяемыйНаконецДолбанныйСтыд()".
Другое дело, строгое описание типов. Описал - и в контекстной подсказке видишь, что откуда берется и куда ложится.
Но платформа 1С стоит минимум 13.000 рублей, это порядка 200$Триальная версия есть? Если бизнес имеет возможность поиграться и увидит бенефиты, то 13.000 рублей это не проблема.
1С не придумала создать магазин приложений, вроде Play MarketА свой нельзя сделать? Если идея востребованная то всё случится.
Выбрать одно СУБД для начала, например MySQL.Лучше уж тогда какой-нибудь sqlite, если позиционируетесь на микро и pet-приложения.
А так выглядит как одно из low-code/no-code решений.
Если делать максимально похоже к 1С, то конечно потенциально получите базу пользователей которые знают как с этим работать, но специалисту по 1С, было бы полезно попробовать существующие low-code/no-code решения, может оказаться что 1С не такое уж и волшебное.
может быть, может быть. надо попробовать. и все же инструмент для быстрого кодирования трехзвенки был бы неплохо.
Понятно, что для бизнеса 200$ не много, я привел несколько другие мотивы в статье. Ну и потом 1с довольно жадная, для сети из 100 точек это уже 20.000$, сами понимаете.
Если остальные 99 точек приносят вам доход, то почему не должны приносить вендору?
Странно упрекать в жадности 1с, если "сеть из 100 точек" не может потратить по мере роста до этих 100 точек 20 тыс баксов по сумме на платформу учётной системы своей жизнедеятельности.
Но на 20.000$ не соберешь команду разработчиков, для разработки с нуля.
Ну и потом 1с довольно жадная, для сети из 100 точек это уже 20.000$, сами понимаете.
Для сети из 100 точек вы купите:
1) Лицензию на сервер 1500$
2) Клиентские лицензии 100 штук. 6000$
3) Основная поставка 200$
Итого: 7700$.
Т.е. в 2 слишним раза менее страшно, чем вы описали. О какой, простите, жадности речь, если винда на эти 100 лицензий будет стоить как раз около 20 килобаксов + винда серверная 5000$
Это у вас очень интернет хороший.
Для сети из 100 точек вы купите:
1) Лицензию на сервер 1500$ в бэкофис
2) Клиентские лицензии 10 штук. 600$ в бэкофис
3) Основная поставка 20200$ — в каждую точку и офис
Подписка на 1 место полная, на 100 — офисная (не помню сколько точно, кажется 200$+100$*100 в год)
Итого: 22300$ + 10200$ обновления.
Это у вас очень интернет хороший.
21 век на календаре ;)
Для сети из 100 точек вы купите
Если это сеть шаурмячечных - я не уверен, что вот в каждой точке необходимо вотэтовотвсё.
Что все? одна коробка и обновление. Вот и все что я предлагаю на точку. А дальше смотрим, стоит простой из за отвала интернета за год 200 баков или нет.
Ну и/или пишем инструкцию по автономному без 1С использованию кассы и восстановлению всех операций, проведенных без доступа в центральную базу из тетрадки при восстановлении связи.
У любой проблемы может быть несколько решений:
1) 30 килобаксов на 100 точек? Точно необходимо? Платим и радуемся.
2) Делаем хороший инет на 100 точках, даже если это стоит ровно столько же, сколько стоят лицензии. Архитектурно работать в одной сети - сильно правильнее. А распределенка из 100 узлов - беру попкорн. Это мазохизм чистой воды.
3) Берем дешевый фронт/готовые мобильные решения, если действительно без 100 узлов никак.
4) Сворачиваем на хрен бизнес. Не ваше это, если вам жлобливо организовать АРМ, который будет приносить деньги.
5) Отказаться от 1С и получать удовольствие.
Кто и зачем это всё должен делать?
Чтобы раздавать бесплатно?
Внезапно, разработчики тоже хотят кушать..
"Убийца" 1С родится наверно одновременно с убийцей PHP (ха-ха-ха). Купить платформу и какую ни будь типовую конфигурацию от 1С которая покроет 98% нужд автоматизации хозяйственной деятельности типовой конторы можно менее чем 40к, + поднять сайт (с обменом с 1С) на какой ни будь cms можно еще за 10к итого 50к (и пару дней работы одного спеца).
Кто то готов изобретать велосипед что бы влезть в эти 50к??? (кто то вытеснил пыху из бюджетного сегмента?), так же и с 1С. 1С это как пых в web, дешево и сердито.
ps (20 лет стажа и там и там знаю о чем говорю).
я не хочу разрабатывать альтернативы типовым конфигурациям, меня интересует платформа для трехзвенки
поднять сайт (с обменом с 1С) на какой ни будь cms можно еще за 10к
Ну, скорей всего придётся не на какой нибудь, а на той самой от 1С со всеми вытекающими последствиями ))
и пару дней работы одного спеца
Так не бывает, придётся держать постоянно двух спецов хотя бы на полставки для сапорта 1С и Битрикса, т.к. постоянно придётся что-то дорабатывать под хотелки бизнеса плюс обновления накатывать.
Проблема в чем?…
Садись пиши свое или хочешь готовое?… На разработку надо потратится.
Т.ч. Не вижу проблемы найти или создать. Проблема чтоб это было нужно не только тебе и твоей маме))
Ps:
Были примеры, когда такие «убийцы» сушествовали пока был сам разработчик.
Какие примеры были, поделитесь? Если вы про 2С и Ананас, это были не трехзвенки, там обычный DBase-клон использовался.
Для начала нужно понять, на каких языках и технологиях садиться и делать.
Траты там не астрономические, но я бы заплатил даже, да. Мне не в лом делегировать.
Вот к примеру ВизуаДата. Притом лет 5 назад была на подходе новая версия основанная ориетирлванная на веб среду. Но как понимаю разработчик не нашел говоря модным языком «инвесторов». А учитывая его возраст, думаю это заглохло.
Вообще занятная штука и проста в разработке. Разработчик давал по тестить.
Для начала нужно понять, на каких языках и технологиях садиться и делать [...] я бы заплатил даже, да. Мне не в лом делегировать.
Это весьма странный подход. Если вы готовы делегировать, то пусть выбором технологий и языков занимаются те, кому вы делегировали разработку, им явно понятнее. Так-то, то, что вам нужно, можно написать на C#, можно — на JS, можно — на Java. На многих других языках тоже скорее всего можно..
Траты там не астрономические
Мне, конечно, любопытно, откуда у вас оценка затрат на разработку такого продукта. Я вот по своему опыту могу сказать, что на одно только поддержание обратной совместимости будет постоянно утекать столько ресурсов, что вы будете задумываться "нафига я за это плачу, может надо уже выкинуть".
>Траты там не астрономические, но я бы заплатил даже, да. Мне не в лом делегировать.
Вот тут ваша ошибка. Это можно сделать либо бесплатно (включая вариант за еду), положив здоровье, постройку дома и семью на кон. Когда один человек не спит ночами и за год-два реализует данную систему. Либо же за миллионы долларов, когда делаете все по уму с составлением Т.З., аналитиками, командой разработчиков и тестеров.
Для начала нужно понять, на каких языках и технологиях садиться и делать.
Для начала нужно понять, кому это нужно. Кто это будет покупать вместо 1С и почему. Или, если покупать для бизнесов в вашей target group слишком дорого - откуда брать деньги на зарплату разработчикам. А на каком языке писать, и какая у этого будет архитектура.. Можно писать на том языке который знаете. Можно выучить по этому поводу новый ;)
Подобную штуку начал писать на Java, в последствии перешел на Котлин переписав весь предыдущий код. В Котлине много "сахара", что существенно сокращает код и делает его более читабельным. На фронт использую Vue с Quasar. Пишу все по DDD, по этому слой доменов работает вообще без фреймворков. Слой даты позволяет использовать фактически любые БД и фреймворк для работы с БД, тоже самое и со слоем приложений. Пока выбрал spring-r2dbc-data для БД и spring-webflux для REST, БД пока Postgres. Так же в Котлине есть возможность переиспользовать код, например для мобильного приложения с использованием андроид студио, или фронт написать на Jetpack Compose UI.
Ещё можно посмотреть в сторону Jmix (ex. Cuba) на Java + Hybernate, ну и как сказали выше Vaadin
Помимо всего технического, 1С как к примеру как и SAP прежде всего бренд, определенный набор процессов из коробки, поддержка продукта, наличие на рынке кадров умеющих работать с системой и ещё много разных мелочей. То есть сколько бы хороша ваша система не была конкурировать с уже устоявшимися продуктами весьма сложно так как в большинстве решение о внедрении принимают совсем не технические специалисты
Не статья, а водопад мечтаний.
Мечты и лень двигают прогрессом. Я хочу чего-то запредельного? Просто спрашиваю, на чем писать трехзвенку в наше продвинутое в плане IT время
Просто спрашиваю, на чем писать трехзвенку в наше продвинутое в плане IT время
Да в том-то и дело, что в наше продвинутое в плане IT время "трехзвенку" можно написать на чем угодно.
вот это разнообразие и пугает. Слишком большой выбор.
А чего пугаться-то? Надо просто брать то, что разработчики лучше знают.
Мне кажется, что вы не понимаете, чего хотите: то вам "монополия 1с" не по душе, с другой стороны, там где есть "большой выбор" вам страшно. :-)
Да нет особо выбора: QT, C++, RUST (DELPHI на худой конец)
если конечно хочешь чтобы "оно" было производительным.
Либо C#, JAVA но отдельные моменты все равно будешь писать на QT,C++,DELPHI,RUST.
Либо C#, JAVA но отдельные моменты все равно будешь писать на QT,C++,DELPHI,RUST.
Я знаю как минимум две ERP, написанных на C# без какого-либо С++ или Rust.
Не буду врать, что они не тормозят, но основное, где они тормозят — это операции с данными (взаимодействие с БД), а совсем не числодробление.
Красиво и точно сказано!
Вы плохо выразили ключевую идею - что именно нужно.
>Я никогда не сталкивался со средами разработки, где так же эффективно, как в 1С можно разрабатывать тиражирумые приложения баз данных.
Правильно ли я понял, что вам нужна Low-code платформа? Какие варианты вы рассматривали?
Наверное главная загвоздка - этого нет и не будет бесплатно. Слишком большая потребность в подобном решении в хозяйственной деятельности - давая продукт бесплатно вы наступаете на хвост тем, кто на этом кормит семью. Вас проще будет или перекупить или даже устранить физически.
Не надо пугать автора, есть же Linux. Торвальдса никто не устранил, жив и здравствует. Хотя, с другой стороны, с Ианом Мёрдоком вышла какая-то очень мутная история.
мне не нужна Low-Code, мне нужна Middle-Code. Я программист. Я хочу взять и наваять тиражное приложение с БД без плясок с бубнами. Мне нужен инструмент для трехзвенки.
Пусть будет платно, не вопрос, но за разумные деньги.
Чтобы пользователь заплатил 2000 за мой продукт, а не 13000 + 2000 как сейчас на 1С.
Пусть будет платно, не вопрос, но за разумные деньги.
Чтобы пользователь заплатил 2000 за мой продукт
Вот тут возникает интересный вопрос: сколько же должна стоить разработка, чтобы это было выгодно?
Что такое Middle-Code? Вы уверенны в том, что правильно понимаете термин Low-Code? Low-Code позволит вам в режиме конструктора, практически без написания кода, реализовать большую часть функционала - а для специфических случаев уже написать код.
Соберите список требований, систематизируйте их. А потом проведите обзор уже готовых решений, которых пруд пруди и выскажите чем вас не устраивает каждое из них.
Дело в том что готового - пруд пруди, многое о котором вы никогда не слышали. К примеру вот это гляньте http://yukosoft.ru/Img/core8.jpg И таких решений очень много.
+ 2000 - а это что за сумма?
Сначала отвечу на вопрос, на чем писать убийцу 1С? Да на чем угодно, к чему душа лежит. Хотите с нуля, хотите используйте уже готовые наработки. Не помню на память все названия этих фреймворков, но они точно есть. Одно могу назвать - Apache OFBiz.
Но в общем схема такая:
фронтенд - SPA на JS (React, Vue и т.д.), тут альтернатив просто нет для бизнеса, не писать же сейчас десктопный клиент, это тупо. 1С этого не понимает, но им выгодно не понимать, учитывая их лицензионную политику за каждое клиентское место.
бэкенд - выбор широк, можно выбирать, что нравится. Имеет смысл смотреть на языки, где присутствуют продакшен реди ORM решения и функциональные фреймворки. При этом я вижу смысл сделать монолитное ядро, где собрать основной функционал, а не как в 1С, когда в конфигурациях напихано до одного места всего, а по факту используется 10%. Так вот эти 10%, которые используют практически все надо запихнуть в это монолитное ядро. Все остальное - это либо плагины, либо микросервисы. Надо давать пользователям возможность не тащить всегда то, что может им никогда не понадобится. Это то, что я очень не люблю в конфигурациях 1С - 80% функционала просто висит мертвым грузом. Этот функционал никому не нужен, но он есть. Это просто мешает даже просматривать списки документов, отчетов, регистров. Очень много лишнего. И я не встречал еще ни одной компании, которая использовала хотя бы половину.
Ну и собственно БД. И даже не одна, а две, традиционная реляционная БД + noSQL.
Далее прикручиваем логирование, мониторинг, очереди сообщений и прочее. Для всего этого есть готовые хорошие решения. Главное не выбрать экзотический язык, у которого нет возможности легко получить нужную библиотеку для подключения той или иной функциональности.
Простой синтаксис, а-ля Питон или JS
А вот это спорный вопрос. С чего вы взяли, что у Питона или JS синтаксис легче чем у других языков? В том же JS можно такого наворотить, что хрен разберёшься. С Питоном легче, так как там уже на уровне языка есть некоторые правила, которые призваны повысить читаемость. Но в любом языке можно написать доступно и понятно или запутано и нечитаемо. Кстати, любой 1Сник это должен понимать как никто другой. Не видел больше нигде такого низкого качества оформления кода, как в 1С. Это и портянки на тысячи строк, при том это даже не модуль на тысячу строк, а реально одна процедура. Это и идиотские наименования общих модулей, процедур, функций, переменных и т.д., часто понятные лишь тому, кто писал. Строки длинной в несколько экранов, то есть редко когда код помещается в одно окно по горизонтали. Это часто следствие длиннющих наименований, которые иногда даже трудно полностью прочитать. И спасает ли при этом простой синтаксис языка 1С? Нет. Поэтому тут больше зависит от того, как написан код, а не какой синтаксис у языка. Один из самых простых синтаксисов у Си. Значит ли это, что на нем легко писать и легко читать код? Нет, конечно.
Для бизнес приложения я бы выбирал язык не по синтаксису, а по скорости разработки. Это логично, так как в данной сфере сроки всегда горят.
Но в общем, я двумя руками за любых убийц 1С. Самая отвратительная система для разработки чего-либо, с кучей ограничений, костылей, багов, проблемами с производительностью и самой убогой средой разработки. А с командной разработкой, особенно если разработчики сидят на удаленке, вообще беда.
Это из той темы:
"Есть человек который знает как управлять государством, но пока приступить не может, занят надо таксовать".
можно то конечно все. и метеоритом убить человека тоже можно.
однако синтаксис джавы сложнее синтаксиса бейсика или PHP или C#, такова объективная реальность.
однако синтаксис джавы сложнее синтаксиса бейсика или PHP или C#
Во-первых, где конкретно синтаксис джавы сложнее синтаксиса C#.
такова объективная реальность
А во-вторых, как вы объективно меряете сложность синтаксиса?
Простой синтаксис - это не значит что легко будет поддерживать. Выучить - да, быстрее. А вот потом писать серьезный софт, который нужно поддерживать - будет сложнее. Возьмите Brainfuck - очень простой синтаксис, всего 8 команд, выучить можно за 1 день. А вот взялись бы вы на этом простом языке писать ПО?
Чем вам не нравяться десктоп приложения и почему это тупо? Это гроздо удобнее в плане разработке, чем веб (бекенд+апи). И не жрет столько памяти, как какой нибудь завернутый в браузер слек
17 лет назад я хотел написать кросплатформенного убийцу 1С на PyGTK+. Даже название придумал: PyGTK+ Business Forms. Даже начал что-то делать, разобрался в PyGTK+ и Glade, но закрутили дела и ... в общем, сейчас на PyGTK+ уже не хочу :)
Если честно, Нуралиеву нужно очень постараться, чтобы 1С слетела с сегодняшнего пьедестала.
Интересно чем ваши поиски закончатся.
Что-то типа такого ищете?
https://www.youtube.com/watch?v=ONOFC8kjtTU
Трехзвенка
Браузер (JS, JQuery) - Сервер приложений (Apache, PHP) - БД (Mysql)
Ирония в том, что заменить 1С нечем. Это уникальный конструктор приложений, где за вечер можно склепать что-то простое и начать пользоваться. Особенно это касается интерфейса: в одном стартапе мы втроем пилили для браузера то, что в 1С я бы сделал за пару дней.
возможно, но альтернативу для разработки трехзвенных приложений хочется иметь. Причем без этих ужасных ООП-оберток, которые делает JAVA над базой данных. Это лишнее.
>Ирония в том, что заменить 1С нечем
Почему вы думаете что нечем? На западе что вместо него используют? Смотрели ли Microsoft Dynamics, SAP ERP, решения SalesForce?
Это из крупных. Есть тьма более мелких, которые не на слуху.
Это уникальный конструктор приложений, где за вечер можно склепать что-то простое и начать пользоваться.Думаю что конструктор большинству конечных пользователей не интересен. Пусть разработчик и продвинутые пользователи продолжают использовать 1С конструкторы.
Т.е. в первом приближении можно обойтись runtime движком, который берет формы, отчёты сделанные в 1C и исполняет их.
Может быть даже лучше не отдельным десктоп приложением, а как веб приложение.
Очень вероятно, что достаточно большая часть от подобного уже должна где-то существовать. Левши не перевелись ещё.
Не понимаю, чем автору Инфостарт не угодил в плане распространения своих решений/дополнений? Навеяло первыми абзацами статьи.
тем, что у пользователей должна быть платформа за 13.000 рублей. А в остальном все нормально. Если бы 1С имела плеймаркет, она могла бы мелкие поделки продавать за 2000 как сейчас базовые.
ну тринадцать тысяч рублей даже для частника небольшие деньги, особенно если учесть что смартфоны у них часто дороже раз в пять. А для этого решения представьте ещё и компьютер нужно купить. А операционку например, тоже часто (иногда) покупают простые граждане, не поголовно на линуксе. И текстовые редакторы у них часто покупные и цены там сопоставимые с указанными вами тринадцатью тысячами рублей. И подписку на ИТС никто не Заставляет оформлять.
Суть статьи типа в том, что вот есть 1с, лучше нее на свете нет ничего. Это такая полуправда.
Суть же в том что хоть на 1С, хоть на чем другом, но программирование в своей сути мало отличается. Можно писать на 1С плохой неподдерживаемый код, можно писать такой код на чем угодно другом. Справедливо и обрптное - на 1С можно писать хороший поддерживаемый код, как и на всем остальном.
Минус 1С - это забетонированный ОРМ, на который невозможно влиять. А он ограничен примитивными связями таблиц, при этом используются средсива СУБД самые базовые - селект и инсерт, для таблицы остатков абдей, на которые никак нельзя повлиять. А сам язык запросов - чрезвычайно редуцированный селект с соединениями и временными таблицами. Никаких тебе общих табличных выражений, оконных функций, преобразований типов - если только строки в стро4и и числа в числа.
Сам по себе интерпретатор очень медленный - пустой цикл чуть ли не на порядок медленнее, чем в питоне, который вообще считается тормозным языком. Остальные конструкции не сильно лучше.
Система визуадизации тоже весьма примитивна. Для чего-то чуть сложнее примитивного списка уже приходится юзать поле html, в котором отрисовывать все самостоятельно.
В общем если прикинуть, то разработка приличного приложения на 1С бужет быстрее в части прототипа, но если дальше появятся требования пользователя по дищайну, то разраьотка на 1С уступит по времени разработки даже джаве, а уж по скорости работы аналогичный код на джаве будет выполняться на два порядка быстрее.
я думаю, есть что-то среднее.
требования по дизайну не всегда нужны в учетных системах.
Нужна какая-то устоявшаяся подборка инструментов для создания трехзвенки.
Там, где работа с базой данных, код не очень требователен к скорости, все равно SQL будет на порядки меньше, тут не фракталы обсчитывать нужно.
Все относительно. Сейчас 1С висит много где из-за того, что СУБД не справляется - это, в основном, архитектурные просчеты, когда кто-то сильно захотел писать в 1С 4кк движений в день, а про то, что их оттуда читать еще надо, не подумал. Ведь в больших системах есть оперативные данные, есть исторические. Да, 1С тоже имеет оперативные и исторические данные, но они лежат в одной таблице по-сути-то. А механизмов вертикального и горизонтального шардирования нет. При том попытки организовать это средствами СУБД являются нарушением их идиотского лицензионного соглашения. Да, это снимает кучу проблем с ТП, которая отвечает первым делом "обновите платформу", но создает кучу проблем перед отделом разработки.
Да, пока у тебя ларек, у тебя вообще нет проблем в учете - это уже автоматизировали банки частично (или даже полностью, остальное в йокселе) . Если у тебя два ларька, то 1С тебе подойдет. Если количество ларьков начинает увеличиваться, то 1С начинает проседать в части производительности и начинает требовать неплохой такой ренты на свое обслуживание, т.е. становится взрослой системой с некислой стоимостью владения, и при всем том на стоимость владения влияют все эти архитектурные ограничения на масштабирование. И ларьки медленно переезжают с УТ на розницу, потом на фронтол, а 1С становится системой бэкофиса, в которой ни на минуту не перестает кипеть работа по выправлению учетных косяков. А если ты вдруг не торгашь, то у тебя проблемы начнутся даже раньше, т.к. свои кейсы ты в простые приходно-расходные документы вряд ли засунешь, а накликать миллиард кнопок в ЕРП - то еще веселье, т.к. каждый третий клик не туда, да и прилично соображающих в ней не так много, тем более при том количестве изменений, которое сейчас в ней происходит.
В общем стоимость разработки и владения среднего и крупного (в особенности) бизнеса уже не отличается разительно между своим продуктом и продуктами 1С. Да, для своего продукта нужен будет методолог-архитектор, но и для 1С трех консультантов придется где-то найти. И если что-то свое может быть спроектировано с учетом современных требований к масштабированию, мультиплатформенности (чтобы и на Эльбрусах в случае атомной войны завелось)\, то в части 1С ты вынужден запасаться костылями с граблями, сразу же лишиться поддержки 1С из-за шаловливых пальчиков экспертов по тех.вопросам, которые плевали на лицензионное соглашение (правда эта поддержка все-равно тебе бы не помогла - факт). И даже после всех ухищрений твой бэклог будет сопоставим с бэклогом вконтакта, который обрабатывает миллионы взаимодействий в секунды времени, в то время как продукт 1С на просто окулиард денег стоящем железе с трудом осиливает тыщенку.
У меня уже почти готово все как вы и описали. Прямо по вашему ТЗ.
Скоро выложу бесплатно.
Небольшое демо тут https://www.youtube.com/watch?v=ONOFC8kjtTU
Есть вариант Express Application Framework от Devexpress. Там и C#, и толстый и тонкий клиент, и отчетность, и генерация интерфейса на лету, и абстракция от БД.
По сути у 1с из сильного это армия программистов замкнутых на 1с ну и юрисдикция РФ, у платформы из + это конструктор форм и конструктор отчетов, остальное спорно...
Если вы хотите, что то быстрое, интересное программистам (очередной велосипед никому не нужен) то предлагаю смотреть на современные стеки... иначе вы не сможете никого заинтересовать.
Я спрыгнул из 1с в Java, могу сказать, что в экосистеме Java просто набрать стек и написать некий опенсорс вариант вашего типового решения и уже его кастомизировать для конкретного клиента.
С фронтом, можно попробовать Flutter.
Но в любом случае вам будет нужна команда, так как в одно лицо такое не решить.
Java пугает меня своей ООП-ностью. Программисту баз данных ООП не нужен, мне за 20 лет ни разу не понадобился.
На моей первой работе - чувак создал систему на Delphi, аналог 1С, но с привязкой к MS SQL. И все писал на этом самом MS SQL. Без конфигурации, емнип, стоила около 200 долларов тоже. Но платили им как раз за конфигурации и даже больше - за консультации, по сути. Т.е. в итоге это превратилось в контору, которая по большей части учила бизнес как правильно работать с государством ну и предоставляла инструмент.
Уже давно пляшут не от базы данных, а от доменной модели. А база данных это скорее особенность реализации
Программисту баз данных ООП не нужен, мне за 20 лет ни разу не понадобился.
Программисту БД, возможно, не нужен. А вот программисту бизнес-систем либо ООП, либо ФП, но хоть какая-нибудь сильная парадигма нужна, иначе управление сложностью полетит под откос.
В большинстве IDE и языка программирование для разработки форм используется ООП, где над базовым классом формы создается класс новой формы и для каждого элемента формы создается своё поле этого класса. Но такой подход не универсален, т.к. не подходит для динамически создаваемых форм, где можно создавать множество элементов управления в зависимости от потребностей приложения.
1С использует другой подход — у нее есть визуальный конструктор, где на форме можно разместить нужные, выбранные из ограниченного набора типов полей, элементы управления. Свои типы элементов добавлять нельзя. Тем не менее, процесс разработки очень удобный.
Насчёт того, что для форм нельзя добавить рантайм контроля это неправда. Можно хоть в delphi, хоть в c#, например.
У 1с собственно подход тот же самый, только ограничен контролами самой 1с.
>для форм нельзя добавить рантайм контроля это неправда
Для .Net был ASP.NET Dynamic Data Entities, где функционал был из коробки. Потом выпустили чуть более продвинутый Visual Studio LightSwitch - наиболее близко к тому, чего хочет автор. Но сейчас все это объявили устаревшим и предлагают Power Apps уже исключительно по подписке.
Начал знакомиться с Системой компоновки данных от 1С (СКД).
И вот интересно сколько сил уйдет сделать такой же функционал на "убийцах 1С".
При всей моей нелюбви к 1С, которая обусловлена любовью к Python, TypeScript и Open-Source в целом, стоит все же признать 1С, очень сильно постаралась, чтоб быть и оставаться системой учета №1 на российском рынке.
И альтернатива достойная найдется ей не скоро.
В своем время я начал "пыжиться" пробуя автоматизацию на Odoo, но энтузиазм быстро пропал когда начал сравнивать время потраченное на разработку на Odoo и на 1C. Так и живем.
Кажется автору удалось убедительно обосновать, почему одиночки и небольшие компании на 2-3 программиста никогда убийцу 1С не запилят -)
https://wonderland.v8.1c.ru/blog/obnovlyen-plan-zadach-na-versiyu-8-3-23-platformy-1s-predpriyatie-4/
Пункт 22. То что нужно?
мне не нужна Low-Code, мне нужна Middle-Code. Я программист. Я хочу взять и наваять тиражное приложение с БД без плясок с бубнами. Мне нужен инструмент для трехзвенки.
Пусть будет платно, не вопрос, но за разумные деньги.
Не поздновато ли сейчас хотеть сделать платформу для трехзвенки?
Может об этом стоило думать 30 лет назад, когда 1С начала свой путь?
Минимум 10 лет назад.
А сейчас уже это все может решиться с помощью ИИ (искусственный интеллект).
Отовсюду сыпятся заверения, что успехи в развитии ИИ таковы, что результаты этого нас вот-вот накроют и ИИ вот-вот заменит водителей, кассиров, бухгалтеров,.....
И тогда говорим ИИ "хочу чтобы....", на выходе получаем желаемое.
Что-то типа волшебника Ээх из одного мульта или трех мужичков из другого мульта , восксклицающих "Что новый хозяин надо?!"
И возникают вопросы:
А кто будет говорить "хочу...".
А будет ли нужно такое количество людей?
И будет ли тогда кому-то нужна трехзвенка?
Но это уже совсем другая история.... )
Триста тридцать пять....
Уважаемый автор, если не ошибаюсь, ещё с начала нулевых убийцу 1С пишет, ещё с 7.7 :)
Тогда примерно раз в неделю очередной убийца на мисте начинался.
"Многие ждали меня в лесу, возле выкопанной ямы, видишь как всем им теперь к лицу, пиджачок деревянный".
По-моему, надо смотреть в сторону blockchain и DeFi, это же сейчас модно :)
Будет что-то типа трехзвенки: сам блокчейн со смарт-контрактами, сервера которые будут майнить/валидировать, и много разных клиентских приложений.
Клиентские приложения - это и есть ваша часть с интерфейсом пользователя и отчетами для печати. В смарт-контрактах и в блокчейнах будет жить бизнеслогика и хранимые данные. Сервера будут обеспечивать работу всей этой инфраструктуры.
Если хочется чтобы все работало только у себя, то нужно будет все это развернуть в локальной сети.
Понятно что конкуренция хорошо. Что нужно альтернативное решение, но заявленная стоимость в 2000 рублей сильно смущает.
Вопрос. Какая направленность решения? для Бизнеса? для Малого? или для Школьников, детей, Для частного использования?
Ответ на этот вопрос покажет экономику проекта. Массовость продукта. Если для Малого бизнеса, то клиентская база на порядок/два меньше чем для частного личного использования.
Но при этом бюджет решения, заявленный автором статьи в 13 тыс. как критический, слишком дорогой не представляется проблемным, даже в 10 раз больший бюджет не представляется проблемным, по сравнению с другими затратами на создание бизнеса, на оборудование, ремонт помещения и т.п.
У меня за годы внедрения 1С на разные предприятия уже выработался такой подход. Если Центральный сервер стоит больше чем на порядок дешевле личного автомобиля директора/владельца - плохо. Обычно масштаб бизнеса как-то коррелирует с объёмами данных в текущей обработке. Значит оборудование должно соответствовать.
Рабочие машины пользователей тоже не должны быть хламом. т.е. стоимость всего парка офисной техники не должна быть сильно дешевле (опять же на порядки) парка автомобилей администрации.
А тут автор постоянно упоминает пресловутые 13 тыс. На эту сумму можно что купить? Ну то что сопоставимо? Для бизнеса? Терминал сбора данных? Дверь в офис? Пару средних роутеров наверное.
Почему и как написать убийцу 1С