Comments 460
С этим что не так?
Интересная штука
Все вышеперечисленное можно сделать в Java: Vaadin + Spring + Hibernate + MySQL. Круто будет выглядеть, летать по скорости и получите море удовольствия.
Если интересно пишите в личку, покажу расскажу с чего начать и как.
Java слишком сложный типизированный язык для этого. Тут нужен бейсик или питон. В Foxpro и Clipper был очень простой код, без ООП
Вы зря думаете, что питон проще, чем Java.
"В Foxpro и Clipper был очень простой код, без ООП" поделки на том и другом извел 1с. Это ему в плюс.
Пробовали? Не знаю как может программисту с опытом как у вас, повернуться язык назвать Java слишком сложной.
У Java очень большой слой легаси и костылей. Именно они в основном и добавляют сложность самому языку.
мне не нравится, когда формы описывают через классы (ООП)
Во всяких Delphi именно так и делается. Это позволяет писать меньше кода. Как раз формы - это то, куда ООП подходит идеально;) А кодировать дизайн простыней кода - это плохая идея на любом языке.
Удивительным образом, описание форм через классы — это свойство не языка, а конкретного UI-фреймворка в нем.
но язык без UI ни о чем.
но язык без UI ни о чем.
Да, но язык может позволять разные UI-парадигмы (посмотрите на C#, где есть не меньше двух парадигм для толстых клиентов и я уже сбился со счетку сколько разных парадигм для Web).
А UI это свойство языка?
То есть IDE? А если IDE не поддерживает, реализовать GUI нельзя?
Вы точно мне отвечаете? Что вы подразумеваете под поддержкой GUI со стороны IDE? Формошлёпство?
Обращаться к источникам данных по SQL из HTML? Как вы это себе представляете?
Итак, раз вы говорите, что поддержка GUI это свойство среды разработки, то получается если среда не поддерживает, то GUI создать нельзя? Даже если GUI не предполагает использования языка, отличного от языка основной бизнес-логики? А как тогда в вашу парадигму поддержки GUI языками и средами укладываются фреймворки вроде Qt? Я могу получить GUI с его использованием и если я пишу на C++ и если я пишу Python. То есть GUI не привязан к конкретному языку и что тогда является его поддержкой со стороны языка?
И у меня тут закрались подозрения. У вас какой-нибудь опыт промышленной разработки на языках общего назначения есть? Или только генерация форм к БД?
Пробовал. Вот пытался рэндзю написать: https://fixin.livejournal.com/1575100.html
А вы точно уверены, что опытные Java-разработчики напишут то что вы написали, так как вы написали? Может, главная причина того что у вас получилась жесть в том, что вы просто не знаете Java?
Вы комментарии к той заметке читали? Простыня г***кода.
это first steps в java, а вы тут громкими словами бросаетесь. вы бы еще Хелло Ворлд покритиковали, ггг
Судить о языке по first steps — плохая идея.
Вы бы про паттерны почитали, чистый код, чистую архитектуру…
и
это first steps в java
То есть чистый код, чистая архитектура и паттерны применимы только к Java? В тех языках, которыми вы пользуетесь на более постоянной основе всего этого нет?
На самом деле Java из-за строгой типизации очень часто выигрывает питону в простоте. Тут конечно долго можно спорить, но Java гораздо более предсказуема в поведении, чем Python.
Ради интереса посмотрите код фреймворка Django. Это фреймворк старой школы: модели, ORM, представления, шаблоны и прочее. Я бы не назвал его простым.
А разве строгая типизация усложняет язык? Почему вы так думаете? Без строгой типизации так же нужно понимать что такое тип переменной, пусть он и не указан явно. Просто нет проверки на уровне компиляции, из-за чего много ошибок всплывают в процессе исполнения. А так в чем усложнение?
в этом плане мне нравится бейсик и работа с COM-объектами, там не нужно указывать типы объектов, а просто написать, что ты хочешь с ними сделать.
Типизация - лишняя, как бы это сказать культурно, мастурбация.
Типизация — лишняя, как бы это сказать культурно, мастурбация.
Лишняя она ровно до тех пор, пока вы не выясняете, что вы хотите сделать с объектом то, что с ним сделать нельзя. Статическая типизация позволила бы узнать об этом до запуска приложения.
можно писать приложения качественно, тогда об этом думать не нужно
Ну да, писать приложения надо быстро, качественно и без ошибок. И тут как раз хорошо, когда инструмент тебе помогает, автоматизируя часть рутины и убирая часть машинальных ошибок.
А вот когда в языке возможны конструкции
b = f(a) //как должно быть
f(a,b) //неправильный вызов
Причем во втором случае ни компилятор, ни интерпретатор не сообщают об ошибке, то можно попасть на многочасовую отладку.
Знаете, в моем опыте ровно наоборот: чтобы писать приложения качественно, приходиться думать. И чем больше этого "думать" можно переложить на компьютер в виде проверок, тем лучше.
думать всегда надо, но в 1с думать приятно
думать всегда надо, но в 1с думать приятно
Во-первых, то, что в 1С думать приятно, не отменяет того, что в других языках тоже может быть приятно думать — и даже приятнее думать.
А во-вторых, если вам так нравится 1С, то возможно вам просто стоит продолжать платить им деньги.
В 1С приятно то, что язык - русский (хотя можно писать и по-английски, но в российских проектах так делать не надо), и терминология прикладная не требует адаптации. Это огромный плюс, когда речь идет о бухгалтерии или расчете зарплаты. Однако, когда добираемся до технических вещей типа идентификаторов "HTTPЗапрос" или "ОбъектXDTO" напрягает постоянное переключение раскладки.
не усложняет, но на практике она особо не нужна.
Возможно, если она (как и ООП) не нужна вам, это еще не повод считать, что она не нужна никому.
Кстати, каждое такое громкое утверждение ("Х не нужно") несколько уменьшает множество людей, которым интересен ваш потенциальный проект.
стада вредны. Лучше пучок энтузиастов, чем толпа заскорузлых фанатиков классики.
Это троллинг какой-то?
Просто у меня был опыт перехода с верстки сайтиков с использованием JS, jQuery на написание приложения на TS и Angular. И уход с PHP на Java и Kotlin. Т.е. переход от языков с динамической типизацией на языки со статической типизацией. И мне прям норм, прям лучше и легче стало.
Не изобретали бы TS, если JS был бы так хорош. На больших проектах, насколько я знаю, почти всегда выбирают TS вместо JS. PHP сейчас прям уверенно двигается в сторону статической типизации.
Может у вас мало опыта работы с языками со статической типизацией? Или мало приходилось пользоваться средами разработки, типа Intellij IDEA, или VS Code (да, не среда разработки, на плагинами можно обмазать)? Они очень сильно ускоряют работу с языками со статической типизацией, а вот с языками с динамической типизацией уже не настолько.
Все вышеперечисленное можно сделать в С++: Пишете свою СУБД, свою ORM, свой фреймворк. Круто будет выглядеть, летать по скорости и получите море удовольствия.
Все вышеперечисленное можно сделать и на ассемблере: пишете свою ОС, свою СУБД, свой компилятор ЯП общего назначения, свою ORM, свой фреймворк. Круто будет выглядеть, невероятно летать по скорости и получите море удовольствия.
Простите, абсурд. Java - ЯП общего назначения. Вы на ней можете написать что угодно. На счет летать и моря удовольствия - ой, не факт. Глючный и тормозной код можно писать на чем угодно. 1С - это готовый конструктор. Я коммерческую систему на 1С могу написать за пару дней. Она будет выполнять все свои функции и в ней будет нормальный коммерческий обвес со всякми рюшечками и прочей красотой.
На Java вы будете писать кратно дольше и весь обвес нужно программировать (и это с гибером, спрингом и еще 100500 библиотек). И вы гарантированно не дотащите функционал до уровня 1С. И, ой не факт, что будет летать.
Ну так и платформа 1С тоже на сях пишется
1С — это готовый конструктор. Я коммерческую систему на 1С могу написать за пару дней.
Вот только интент поста (и обсуждения в нем) — как написать альтернативу 1С.
да, сугубо из-за проприетарности 1С.
А собака зарыта именно здесь.
Не понял, где "здесь".
с той лишь разницей, что это не рядом с Data Science
Гм, а при чем тут вообще Data Science?
В том виде как написал.
И какое отношение это имеет к обсуждению в посте?
Наука о данных — раздел информатики, изучающий проблемы анализа, обработки и представления данных в цифровой форме.
Ничего не знаю про "науку о данных", а data science — это "an interdisciplinary field that uses scientific methods, processes, algorithms and systems to extract or extrapolate knowledge and insights from noisy, structured and unstructured data". Явно за пределами обсуждения.
разве мы здесь обсуждаем не вопросы состояния рынка на примере 1С
Нет, мы здесь обсуждаем, как сделать "ограниченный" аналог 1С. Ничего про рынок в посте нет.
Неа. Это было бы нужно, если бы была задача составить конкуренцию. А у автора поста задача — "разрабатывать подобные [микро- и пет-] приложения так же быстро и эффективно, как в 1С", только не на 1С (чтобы не платить 1С денег).
Если это личная задача автора без дальнейшей монетизации
Автор говорит про open source.
в остальном это интеллектуальная битва за демонополизацию рынка.
В скобках замечу, что монополия на этом рынке только в России.
Отнюдь, во многих странах есть свои аналогичные монстры, которые в условиях открытого предпринимательства продают свои платформы и сопутствующие сервисы на международные рынки.
Ну я вот регулярно смотрю на рынок SMB ERP в Северной Америке, и никакой монополии тут не вижу.
Их невообразимая тьма.
Если "тьма", то о какой монополии можно говорить?
Что касается монополии, Вы же и сами прекрасно понимаете, что значит для клиента соскочить с одной системы на другую и чем это чревато.
Да, понимаю. Называется "проект по миграции" и в зависимости от клиента может занимать от недель до месяцев (иногда до нескольких лет). Напоминаю, мы про SMB говорим.
Да сегодня рынком разработчиков представлено достаточно продуктов, чтоб у клиента был выбор
Это называется "нет монополии". О чем я и говорю.
>Пишете свою СУБД
Свою СУБД пишут и поддерживают годами целые команды высококлассных спецов, которые получают по 120-500 тыс. долларов в год. Нужно немножко адекватно оценивать свои силы.
Я вот не думаю, что ORM непременно нужна в базах данных. В 1С как-то без нее обходятся.
В 1С как раз ORM
не совсем. Там есть предопределенные типы объектов и все идет от метаданных, а не таблицы базы данных обертываются в объекты
а не таблицы базы данных обертываются в объекты
ORM отображает реляционные структуры (упрощенно -- строки в БД) на объекты. При чем тут обертывание в объекты таблиц? На вскидку не могу вспомнить ORM где бы существовал объект таблицы, как самостоятельная сущность.
По старой памяти, но возможно ошибаюсь, таблицы как таковые это кластеры наполнения и хранения, реляционность обработки обеспечивается функциями запросов, ими же можно создавать новые таблицы, объединять и проделывать с ними любые операции. Таблицы всего лишь источники как неотъемлемая часть всей структурированной БД. Или как?
Мы с вами, очевидно, о разном говорим. Вы мне пересказываете реляционную модель, и то, довольно странно. Реляционность это не свойство механизма обработки, а свойство модели, которой мы представляем предметную область. Мы можем вообще не использовать связи между объектами при их обработке.
Я говорю об ORM, инструменте, который облегчает доступ к данным в ООП-стиле. И мы описываем как раз объекты (то есть строки таблиц) и связи между ними. Таблица как отдельная сущность, то есть существующая параллельно с объектами, представляющими ее строки, обычно не существует.
Чтоб создать по настоящему хорошую многопользовательскую платформу, недостаточно быть просто толковым кодером, надо быть финансистом с охватом всех сфер, которые вы хотите автоматизировать.
… то есть чтобы создать фреймворк общего пользования, нужно вообще все сферы охватывать? Занятно.
Но вообще, если речь идет об автоматизации бизнеса, то обычно этот процесс включает в себя аналитика (и не одного зачастую).
Об этом и говорю, с применением алгоритмов аналитики.
Нет, вы говорите не об этом. Вы говорите, что "чтоб создать по настоящему хорошую многопользовательскую платформу, недостаточно быть просто толковым кодером, надо быть финансистом с охватом всех сфер, которые вы хотите автоматизировать". А я говорю, что это не обязательно.
Небольшой отвлеченный пример из личного проекта:
В том-то и дело, что личного проекта. А я говорю о разработке усилиями разработческой компании (или сообщества), где есть нормальное разделение ролей.
именно нужно достаточно хорошо обкуриться в теме, чтоб постановка задачи не была для кодеров мучительно больна
Хорошо ставить задачи — вообще нетривиальная работа, с этим вроде бы никто особо не спорит. Обкуриваться, правда, не обязательно, достаточно быть хорошим специалистом.
Интересненько, хороший специалист это тот кто ?
Хороший специалист, сюрприз, это хороший специалист. Если мы говорим про архитектора — то хороший архитектор. Если про аналитика — то хороший аналитик.
Если речь идет про разработку финансовой системы, то аналитику, конечно, придется разобраться, что такое дебет и кредит (в частности, хорошего аналитика от плохого отличает (а) то, что он понимает, что придется разобраться, и (б) что он способен разобраться). А вот разработчику достаточно будет прочитать или прослушать коротенькое объяснение от аналитика.
Так ведь в контексте 1С клиенту не олдскульные разрабы нужны
Вот только мы не в контексте 1С и ее клиентов, а в контексте разработчика, который хочет себе платформу. Я не вижу нигде в посте желания отдавать эту платформу клиентам, чтобы они там что-то себе сами делали, вижу только желание, чтобы эта платформа была похожа на 1С, потому что автор поста любит 1С.
Да. Сначала 1С 6.0, где каждый бухгалтер, сможет сам настроить алгоритмы проводок. Потом 7.7, где уже нужен программист, но он же и аналитик и все-все-все. В 8.х планка снова поднята и уже есть отдельно аналитики, архитекторы, разработчики и тестировщики, если конечно не уровень ларька. Скоро в 1С поймут, что бизнес-логику все таки надо совсем отделить от UI (да-да, до сих пор многое завязано на формы, несмотря на клиент-сервер). И вот тогда будут наверное уже отдельные специалисты по бизнес-логике и по представлениям. Так что какой-бы конструктор 1С не создала, но все идет в направлении общего тренда - специализации профессий.
Так что какой-бы конструктор 1С не создала, но все идет в направлении общего тренда — специализации профессий.
И я этот путь уже наблюдал на примере других конструкторов. Потому что конструктор — это все равно программирование, просто другими средствами, и оно требует определенных навыков, которых у бухгалтера обычно нет, а потом растет сложность, и сложностью нужно управлять, и так далее.
Кто по Вашему мнению лучше построит ядро такого инструмента для разработки конструктора, кодер, которому постановщик со слов клиента расписал что требуется или опытный бухгалтер, дружащий с источниками законодательства и динамикой его изменений, который владеет не в худшей степени чем кодер опытом программирования?
Ни тот, ни другой. Оба не справятся.
Для построения "ядра инструмента для разработки конструктора" нужен архитектор и системный аналитик.
ORM по определению это отображение реляционной таблицы в объект. То есть в каком-то смысле строится пара: таблица и объектный тип. Упрощенно конечно. Потому что на самом деле несколько таблиц собираются в один агрегат.
В 1С это именно так: Посмотрите, например любой документ и его табличные части. Как они устроены в СУБД.
Это прямо классический подход ORM.
Потом сложно искать специалистов которые смогут поддерживать весь этот зоопарк
о. там даже в заголовке написано, что не так: "Декларативная". типа Пролога. Такая вещь никогда не станет популярной. Неудобная.
… а вы не задумывались, почему же 1С за свою платформу берет деньги?
Вы про первый взнос за основную поставку или потом в виде подписки, которая все время растет в цене, притом что качество конфигураций падает ну и плюс поборы за доп.сервисы? Наверное потому что монополист и может ...
Наверное потому что монополист и может ...
А если бы не была монополистом, то не брала бы денег?
Не брала бы. Потому, что с таким подходом при существовании конкурентов исчезла бы.
тоже так думаю, как 1сник.
Гм, а на что тогда должна существовать компания, которая не берет денег за свой продукт?
На средства благотворительного фонда, обычно в таком режиме работают не компании, а проекты типа Debian. Но зачем, когда можно зарабатывать? )))
Хотите получить ответ на свой вопрос, не ответив на мой? - для 1С кстати очень типично ... :) Наверное тогда ей пришлось бы напрягаться, и качество продукта братьев за эти деньги было другое ... но ... - "Запомните, джентльмены: эту страну погубит коррупция." © Человек с бульвара Капуцинов
Впрочем, очень много проектов оставляют продукт 1С как необходимое зло по ведению бухучета(ПБУ и штрафы никто не отменял), но все что уходит в оперативный учет начинает писаться на более быстрых и масштабируемых решениях с применением популярных языков, с экспортом необходимых данных в бухгалтерию.
вот я и хочу писать для упр учета на быстрых и масштабируемых решениях и популярных языках, подскажите, на чем.
Наверное тогда ей пришлось бы напрягаться, и качество продукта братьев за эти деньги было другое
Подождите, за какие деньги? Вы же говорите, что она берет деньги, потому что монополист?
из жадности, конечно же.
А разработчики, которые это всё пишут, тоже зарплату из жадности просят?
Да, блин, чё вы прикопались? Она монополист и этим все сказано. Может выкручивать руки всем и играться с ценой. В 2 раза дороже сделает и все равно будут брать. Если бы был конкурент достойный , то пришлось бы улучшать сервисы и снижать цену.
Я просто не пойму к чему вы клоните? Любите монополии что-ли?
Я клоню к тому, что разработка стоит денег. Разработка платформы, инструментария, поддержка обратной совместимости — все это стоит денег. Как разработчик, который всем этим занимается (не в 1С, заметим), я весьма подозрительно отношусь к заявлениям "давайте просто сделаем то же самое, но open-source".
не то же самое, а проще.
Вы оставили достаточное количество сложных требований. В принципе, одно только требование на полную обратную совместимость увеличивает бюджет на порядок.
Я на 7ке веселюсь с маркировкой и 54 ФЗ. На ней же СЗВ-М и прочая отчётность в фонды. Разработка платформы это такая малая часть, того что нужно для бизнеса. Лет 15 назад был и два-с и ещё куча проектов. Но сейчас законодательство меняется так часто, что главное это именно поддержка регламентированной отчётности. А все остальное.....
Понятно, что стоит денег. Кто ж спорит. Но монополия - в целом это плохо, чисто по законам капитализма
все так
вы бы еще Access посоветовали.
Почему нет? Всяк лучше чем Эксель.
А что случилось с Соло? Почему он проиграл 1с ?
Потому что у 1С было много административных рычагов, которые им позволили вынести всех конкурентов.
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с
Сами платформы стоят копейки, по сравнению с доработкой, поддержкой, интеграциями.
Потому что есть некоторые стандартные бизнес-процессы, которые нужно настроить и дописать свои костыли, а не реализовывать с нуля. И аудиторы +- понимают, куда надо смотреть и чему доверять (если, конечно, SAP использовать по назначению, а не как платформу для написания велосипедов своего учёта рядом). Для публичных компаний это не менее важно, чем TCO, и уж тем более, чем комфорт конкретного разработчика.
Вот мы такую штуку в MIT-лицензии делаем: https://habr.com/ru/post/666184/
меня больше интересует приложение на своем сервере. ну и как вырожденный случай - приложение, работающее с этим же кодом, но на локальном компьютере.
Смотрится интересно... Postgresql там по каким-то определяющим причинам или можно ждать адаптации под MySQL ? Просто большинство копеечных хостингов это php + mysql. Поставить попробовать было бы проще и доступнее
Мы используем jsonb для упрощенной типизации внутри приложения а также читаем конкретно постгресовские коды ошибок дедлока и конкретно для постгреса передаем параметр жизни транзакции, что бы пользователь, который ничего не знает про БД не столкнулся с блокировкой таблицы вдруг. Поэтому как основную Бд мы не будем поддерживать MySQL. Про хостинги — как минимум копеечный VPS. Если совсем за 100 р/мес то вот https://ru.docs.totum.online/install_on_net_angels но реально притормаживает в прайм-тайм тк это жесточайший шаред.
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 )))
Там это делается очень просто специализированными инструментами
И что же там за трехзвенка в DELPHI? CORBA?
Должно быть так - МНС готовит формы в открытом формате готовые к подключению ПО, выходят новые изменения в законодательстве, все эти формы уже лежат в репозитории и даже выкачаны конечными пользователями в свои компьютеры.
За скобками остался сам учет. Изменения в законодательстве - это не просто формочки. Это МЕТОДОЛОГИЯ. Сменой формочек вы ничего не добьетесь. Ввели 54-ФЗ? Изменение? Изменение. Какие, на хрен, формы? У вас полностью поменялся процесс печати чеков. Вы теперь ОБЯЗАНЫ печатать наименования. А у вас лично вообще мог быть только суммовой учет. Сквозной учет НДС? Вам теперь во всех проводках правильный ГТД нужно тащить, а для этого - учитывать, что пришло, по какому ГТД и еще остатки этих ГТД считать нужно. Система маркировки? Да там дополнительный полноценный учетный контур добавился. С интеграцией в честный знак и кучу других подсистем. ЕГАИС? Аналогично. Еще и УТМ нужно поставить в локалке.
Дак есть же всё https://format.nalog.ru/
Или я вас не так понял?
Альтернативная платформа может тоже поддерживать различные СУБД, за счет того, что работа с базой данных должна быть максимально стандартизирована и формализована. Чтобы код одинаково работал на разных базах данных.
Для этого ORM'ы используют. SQLAlchemy, например.
Ну как бы... Есть СУБД Firebird, с кроссплатформенностью и возможностью устанавливать на 32bit/64bit и прочими имеющимися плюшками. Есть проприетарный Delphi, позволяющий создавать приложения под что угодно практически из одного проекта и кроссплатформенный Lazarus, позволяющий бесплатно и без лишних заморочек написать несложное приложение хоть под Linux, хоть под MS Windows и даже с простым генератором отчётов, который при необходимости можно заменить на более серьёзный вариант от Fastreport (г.Ростов-на-Дону). На мой взгляд, более чем достаточно для того чтобы реализовать любую несложную БД и прикрутить к ней всё необходимое, для удобного использования в любой организации.
Единственный недостаток - убогий язык Паскаль, прошлый век. Не годится.
Чем же это он убог? Вы точно знакомы с Лазарус и тем же Фастрепорт?
И не слишком ли много допущений в вашей статье в сослагательном наклонении?
Если все так просто - так почему же вы тратите время на болтовню вместо кода? Или все же есть смысл в вопросах комментаторов о причинах монополизации рынка?
да, я изучал паскаль и Дельфи в универе и даже делал подработку на Дельфи, т.е. получил бабки за программу по автозапчастям, написанную на Дельфи. Сам синтаксис языка паскаль убог и чрезмерно перенасыщен сущностями. Для 90х было норм, сейчас рулят легкие синтаксисы типа питона или даже C#
Ещё раз попытайтесь понять что я вам писал выше: БОЛЬШИНСТВО программ, которыми вы пользуетесь, в т.ч. операционные системы, написаны на этих " убогих и перенасыщенным сущностями" языках.
А хайпа я за свою уже 25 летнюю карьеру насмотрелся. Отлично помню как провозглашали королем Delphi, потом - убийцу всех Java и.т.п.
И таких как вы, я тоже насмотрелся. Pascal ему убог. Вы про обратную пользую запись что-нибудь слышали?
Какие ОС написаны на Паскале?
Каждому языку - своя ниша. Есть c/cpp/asm/rust для этих целей и, мб, еще какие. Здесь же разговор идет о том, как можно было бы написать такой же мощный инструмент как 1С. А выбор языка - дело второе. Ну и к слову, паскаль не так плох, как вы о нем отзываетесь. Я в свое время на нем написал дофига графического софта, пока учился программированию. И в том числе на Лазарусе, когда уже прошел знакомство с мс аксесом, пхп и связкой хтмл+джаваскрипт. На тот момент от паскаля ловил кайф, пока ни познакомился с шарпом.
увы, у него слишком громоздкий синтаксис
Я не говорил, что он плох. Я лишь спросил, какие есть ОС на Паскале;)
Есть такое понятие. Системный ЯП. Так вот. Системным он называется в основном потому, что позволяет манипулировать памятью устройства напрямую без оберток в виде интерфейсных доп функций. В Object Pascal в частности легко и непринуждённо можно писать вообще на ассемблере (что я и делал в свое время для написания библиотек плагинов для апача и php аналог bcompiler). Жаба (Toad) написан на паскале, тотал командер, да и вообще дохера чего. И сейчас пишут. Кстати, многие модные ЯП (котлин, го и тд) таки используют синтаксис Паскаля. Так что с вашим мнением не посоветовались. Придется вам и эти языки на свалку истории выкидывать
Кстати, многие модные ЯП (котлин, го и тд) таки используют синтаксис Паскаля.
Разве? Что один что другой C-подобные, вроде как.
мое отвращение к паскалю чисто эстетическое. Слишком уж он громоздкий и некрасивый. Как франкенштейн. Все же за эти годы над синтаксисом языков поработали, особенно питон, где вместо скобок отступы.
Какие ОС написаны на Питоне?
Я вас умоляю. Это же жертвы модных трендов с капотами и фреймворками работающими через мистические api..в облаках. Они именно, что в студенчестве у таких же преаодавателей нахватались кое каких умений. но не больше. У Стругацких есть такое название для них: коекакеры. Вот они, бодрые неучи и задают ныне тренды
А все С - не прошлый век? А Java? Python или Basic?
Подавляющее большинство рабочих и регулярно используемых программ написаны на убогих, по вашему мнению, языках из прошлого века. Многие - на языках старше вас.
Ваш подход и тон не вызывают у меня сомнений в продуктивности идеи.
Си красивее Паскаля. Они в одно время родились, я их в 1992-1997 в универе изучал. От Паскаля тошнить хочется.
Красота - это субъективное понятие. Фактов, конечно, у вас не нашлось.
гармонию можно проверить математикой.
длинные идентификаторы служебных слов begin end.
странный оператор присваивания :=
странная работа с массивами
ужасная работа со строками
постоянная типизация
ну что вам еще добавить? Давно паскаль щупал, это отложилось.
гармонию можно проверить математикой.
Без формализации (общепринятой!) понятий — нельзя.
Я синею, дорогая редакция..
Рассуждать о математическом определении при помощи терминов: длинный, странный и ужасный - это что? Новомодный тренд или долгожданные результаты ЕГЭ?
Пора на пенсию, наверное.
-длинные идентификаторы служебных слов begin end.
зато хорошо видно границы блоков )
- странный оператор присваивания :=
потому что не как везде? зато отличается от знака сравнения, и это правильно. )
- странная работа с массивами
в чем странность?
- ужасная работа со строками
не огонь, но простая и понятная, а потому не ужасная
- постоянная типизация
статическая хотели сказать? Так это первый плюс для любого языка, на котором планируется писать что-нибудь серьезное без боли и сторонних приблуд контроля. Следует отличать полноценное написание приложений, а не дерганье из коротеньких интегрированных в систему скриптов методов готовых объектов, как это принято в 1C или мс-офисных приложениях. Но даже в последнем случае статическая типизация это плюс. )
гармонию можно проверить математикой.
Можно попробовать, но математики не вижу. Вижу вкусовщину.
длинные идентификаторы служебных слов begin end.
Вроде как IDE само раньше помогало ключевые слова вставлять.
странный оператор присваивания :=
Дело вкуса.
странная работа с массивами
Тема не раскрыта. В чем странность?
ужасная работа со строками
В чем именно ужастность?
постоянная типизация
Так это же прекрасно, когда компилятор не позволит даже попытаться умножить строку на обьект.
вставлять то IDE вставляло, но эти бегины ломали взгляд. Да, не люблю напрягать глаза.
Я и говорю что основные проблемы - вкусовые.
Строки там ограниченной длины, к тому же с байт-кодом длины. Жесть.
Строки там ограниченной длины, к тому же с байт-кодом длины. Жесть.
"Currently, most other dialects of Pascal I'm aware of default to either AnsiString (long strings of single byte characters) or UnicodeString (long strings of multi-byte characters). Neither of those are limited to 255 characters." (so, 2013 год).
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С нет типизации? В 1С есть система типов. https://v8.1c.ru/platforma/sistema-tipov/
Имеется ввиду, само собой, строгая типизация. Когда типы определяются на этапе компиляции. Так-то в любом ЯП есть своя система типов
мне не нужно рядом с VAR писать ее тип. Чувствуете разницу?
может быть, может быть. надо попробовать. и все же инструмент для быстрого кодирования трехзвенки был бы неплохо.
Понятно, что для бизнеса 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 прежде всего бренд, определенный набор процессов из коробки, поддержка продукта, наличие на рынке кадров умеющих работать с системой и ещё много разных мелочей. То есть сколько бы хороша ваша система не была конкурировать с уже устоявшимися продуктами весьма сложно так как в большинстве решение о внедрении принимают совсем не технические специалисты
Не статья, а водопад мечтаний.
Почему и как написать убийцу 1С