Как стать автором
Обновить
4
Карма
0
Рейтинг

Пользователь

Почему уходят из 1С?

Построить можно что угодно из чего угодно.

Проблема это все сопровождать, развивать, масштабировать. У меня есть опыт построения систем федерального уровня с базами в несколько терабайт, и огромными нагрузками, и работа с этими системами это в 90% случаев борьба с платформой, и СУБД. В общем все прелести монолита + отношение 1С к СУБД как набору DBF.

Мы покупаем промышленные СУБД за десятки миллионов что бы использовать их на уровне SELECT + максимально примитивный INSERT весь остальной функционал этих СУБД можно использовать только вопреки и с огромными костылями и сложностями.

Почему уходят из 1С?

Ну вот запросами в "бесшовной интеграции" и реализовано, т.е. часть форм из ДО просто скопировано визуально.

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

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

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

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

Почему уходят из 1С?

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

Почему уходят из 1С?

Вы действительно не понимаете разницу между РИБ и микросервисной/сервисной архитектурой?

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

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

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

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

Как бы это работало в нормальном виде?

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

Почему уходят из 1С?

Я как то был на инфостарт и задавал вопрос Олегу Бартунову, можно ли где то ознакомиться с best practices по эксплуатции крупных монолитных баз от 1 Tb и выше.

На что получил ответ:

" best practices по эксплуатции крупных монолитных баз от 1 Tb заключается в том что бы не создавать крупные монолитные базы от 1 Tb"

И что примерно с 2002 года индустрия уходит от монолитов в сторону сервисов, так как объемы автоматизации а так же данных растут, и держать это все в одной базе бессмысленно, так как разные категории данных имеют разную критичность, разные объемы, разную нагрузку. Не просто так придумали разделение OLAP/OLTP.

Любая система на 1С это жесточайший монлит на всех уровнях от кода до субд.

Почему уходят из 1С?

"Готовы на C# и WinForms написать за неделю простую учетную систему? "

Из пластилина легко слепить детскую игрушку. Но самолет из пластилина сделать тяжело.

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

Многие 1С специалисты, и вы в том числе мыслите категориями ИП, когда нужно быстро и дешево. Я вот на ютубе смотрю канал одного человека, он там из Пеноплекса дом строит.

Тоже говорит смотрите как быстро получается, и дешево, и даже тепло.

Я за свою карьеру в 1С (18 лет разработки) построил не мало таких вот "домов" из пеноплекса, и пока ты его строишь всё супер, проблемы начинаются ближе к концу, когда нужно возводить перекрытия, крышу, сантехнику, вешать шкафы и полки и много чего другого...

Как ускорить 1С если у вас Масштабируемый процессор Intel Xeon с низкой базовой тактовой частотой

Вы вообще не понимаете о чем пишите.

 У XEON отдельные процессорные кеши на каждое ядро

  1. У всех процесоров х86 отдельные кэши на каждое ядро, называются они L2.

  2. У интел (в отличии от ZEN2) как раз L3 общий для всех ядер

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

Как ускорить 1С если у вас Масштабируемый процессор Intel Xeon с низкой базовой тактовой частотой

Спасибо за инфу, привык что MS SQL использует все до чего дотянется, а с PG только недавно...

Как ускорить 1С если у вас Масштабируемый процессор Intel Xeon с низкой базовой тактовой частотой

Если вы ставите PG под Windows (а по косвенным признкам видно что дело было под Windows) то там может быть вообще что угодно.

Как ускорить 1С если у вас Масштабируемый процессор Intel Xeon с низкой базовой тактовой частотой

Но база размером в 30 ГБ еле работала у одного, не говоря уж о 10.

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

Не важно 1 пользователь у вас или 40, на многоядерном сервере скорость работы будет для них +/- одинаковая.

В случае с малоядерными десктопными ПК скорость работы 80 пользоватеелй будет значительно медленее чем скорость работы 1 пользователя. Но скорость работы 1 пользователя будет значительно выше чем скорость работы 1 пользователя на многоядерном сервере.

(Ну и конечно напомню что мы говорим имеено о севере 1С а не о севере СУБД, потому что для СУБД ситуация более сложная, а если СБУД это PG на Windows то и вообще безвыходная).

Как ускорить 1С если у вас Масштабируемый процессор Intel Xeon с низкой базовой тактовой частотой

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

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

Самый простой способ сравнить процессоры по этому показателю это CPU-Z

В случае пока количество сеансов <= количеству потоков (с учетом HT) ПК с 12900 будет давать результаты в 2,2 раза лучше (см. примечание) чем сервер с 4216.

По мере увеличения количества сеансов 12900 разрыв в производительности будет падать.

Вы не написали сколько пользователей у вас. Если 300 пользователей, то нужно будет или смириться с меделенной работой сервера или подбирать соответсвующие сервера в кластер (5-7 серверов).

Примечание

Тут и дальше под термином "производительность сервера 1С" я имею в виду время выполнения кода.

Очевидно что в реальной работе, например: "формирование отчета СКД, проведение документа, открытие формы списка и.т.п", Прироста в 2 раза не будет, так как там 98% времени работает СУБД и только 2% работает сервер 1С.

Если до 50 человек то под Сервер 1С лучше взять хорошее десктопное железо (12900/12700, старшие ZEN3).

Мало того что сэкономите на серверах, так еще и за счет огромного L2 (1,25МБ на ядро!) и быстрой памяти процессы 1С будут работать очень быстро. В случае ZEN3 там L2 стандартный но зато L3 - 32Mb. (Не знаю что из этого будет лучше но точно знаю что оба покажут себя хорошо)

Из моего опыта если говорить о стандартной бух то сервер 1С на 12900 без проблем будет держать 60-70 пользователей (с учетом того что они работают не равномерно, если у вас работают операторы потокового ввода по всей стране и генерят нагрузку непрерывно то конечно цифры другие будут).

Как убедить заказчика? Если вы +/- крупный франч купите себе один такой системник, и просто показывайте заказчку разницу.

По другому убеждать людей что ПК за 80к будет лучше справляться с сервером 1С, чем сервер за 800к не реально.

Даже под моим сообщением, уверен, будет не один комментарий по этому поводу :).

Приложение "Сервер 1С" в отличии от СУБД не требует серверного оборудования, отлично масшатабируется по количеству ПК, т.е. если у вас 100 пользователей ставьте 2 системника, 150 ставьте 3 и.т.п. требований к диску каких то особых нет, к надежности тоже, особеено если у вас и так кластер из нескольких системников.

Зато с СУБД вам лучше постараться уместить все на одном сервер так как в случае с 1С вам будет ОЧЕНЬ тяжело масштабировать СУБД добавлением еще одного сервера.

Про отключение ядер

Что касается вашего случая, и других случаев работы Turbo boost то все сводится к TDP. У процессоров 4216 TDP 100W и в зависимости от загрузки эти 100W набираются или 8ю ядрами на 3Ггц или 16ю на 2.9 и.т.п. Зеонщики со стажем (сам 2 года дома сидел на 2673v3) всю эту кухню знают, и так же по себе знают насколько важна однопоточная производительность для приложений которые не умеют в многопоток.

Стартуем из 1С в Python

Все что вы описали phyton специалист сделает быстрее и лучше за счёт отличных библиотек по работе с xml и паркингу html. Код будет понятнее.

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

С питоном: pip install beautifulsoup, pip install requests, pip install pandas

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

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

Питон как язык можно выучить за 3 дня. Дальше уже библиотеки и ООП, и этому можно учиться всю жизнь.

История одного взлома 1С или проверьте вашу систему на безопасность

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

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

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

Выглядит не очень сложно.

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

Почему уходят из 1С?

Я думаю, что не каждый программист на java сможет то, что вы написали

Я не просто так думаю я в этом уверен.

Но это как раз и доказывает то что я написал. Есть Java программисты, есть 1С Программисты, есть 1С ники. У каждого из них своя работа. Которая частично пересекается но в общем и целом сильно отличается.

Я вот например 1С Программист, т.е. занимался разработкой гос. систем которые работают в масштабах страны и миллионов пользователей.

Я пару раз касался УХ и УПП и я там как первокласник себя ощущаю, а задачи типа "Внедрение ERP 2.5 На этапе моделирования бюджетной модели, штатному консультанту требуется помощь. Вопросы по формированию Плана закупок. Также необходимо проверить ход моделирования -убедиться в том, что штатный консультант правильно моделирует. Позадавать наводящие вопросы, оценить компетенцию шт..."

Для меня звучат как "бла бла бла".

"Там где всё решается прямо, в 1с идем "зигзагом" ) Но такова платформа, могли бы, шли прямо, но увы, выкручиваемся как можем. "

Я не вижу ничего плохого в том что бы выкручиваться. Почитайте как работает Maincraft там хак на хаке и хаком погоняет. И 1С тут вообще не в первых рядах.

Бейсик или ООП не имеет значения пока у вас 5 модулей по 15 процедур в каждом и вся система умещается в голове.

Когда вы пишите систему и в ней уже под 300 общих модулей в каждом из которых по 5000-40 000 строк сразу приходит понимание зачем нужен ООП.

И когда размер СУБД выростает до 1,5 Tb вы начинаете понимать зачем нужны микросервисы.

Почему уходят из 1С?

Почему вы решили что я унижаю программистов 1С?

Например директор компании это не программист. Значит ли что я унижаю директоров компаний?

Ну или если я напишу что backen и frontend разработчики это разные по сути специальности то кого я тут унжаю Back или Front?

Почему уходят из 1С?

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

Из статьи я узнал только про то что написал. Там в начале жизненный путь автора описан.

Программисты 1С не пишут код? По-моему, у них связаны руки и они работают в одной парадигме, но при этом делают fullstack по факту.

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

Согласен.

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

Говнокодить это не мешает, и не только на 1С.

Вы немного не так поняли смысл размещения ссылки на стандарты. Попробую еще раз объяснить. 90% стандартов которые там описаны, дискредитируют язык BSL, потому что всё это должно быть не на уровне отдельной книге и в голове у программиста а заложено в дизайн языка и IDE.

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

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

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

Почему уходят из 1С?

"крутые и с помощью этой платформы можно написать, что угодно "

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

Я в разработке 18 лет, и не скажу что прям все понял, но одну вещь я понял достаточно на глубоком уровне: Написать программу это первые 90% работы. Вторые 200% это её сопровождать, развивать, масштабировать, интегрировать.

А вот это крайне тяжело делать на бэйсике с вкраплениями SQL.

Почему уходят из 1С?

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

Проблема только что индустрии не нужно делать "простенький складной учет за пару часов".

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

И продукты на 1С давно уже решают такие проблемы, взять тот же Газпром который хоть и на SAP официально, а не официально в SAP все грузится из систем написанных на 1С и выгружается обратно в другие системы написанные на 1С. Автоматизация на SAP у нас в РФ чем то похожа на сказку "Каша из топора".

Проблема 1С как раз в том что она изначально проектировалась как фреймворк для "простенький складной учет за пару часов", а пришла к автоматизации работы почты РФ.

"Да у 1С есть болячки, а где их нет. "

То что происходит с ЯП на котором работает 1С это не болячки, это инвалидность или дряхлость, выбирайте что ближе.

Если проводить аналогии то есть такой "язык" Scratch, очень низкий порог входа, можно за 5 минут написать код управления машинкой игровой. Но ведь не кто не пишет на Scratch автоматизацию для почты РФ? А на 1С пишут.

Почему уходят из 1С?

Я вот еще подумал немного. Вы в своей статье часто упоминаете термин "1С ник". Как по мне это отличное отражение.

Есть Java программист, а есть 1С Программист, есть 1С ник.

Это сильно разные специальности. Чистых 1С Программистов очень мало (по моим ощущением 10%) остальные кто работает с 1С это 1С ники.

Наверное так будет точнее.

Почему уходят из 1С?

Вы же поняли о чем я писал? Спор ради спора?

90% работы 1С это поддержка и доработка типовых. Вот так что бы с 0 писать продукты уровня типовых на всю страну если наберется 100 компаний уже хорошо.

Франчей же несоизмеримо больше. Вы вот пришли в Java и можете сравнить промышленную разработку и сопровождение УТ на заводе. Сами же писали в статье про отношение к ИТ внутри компаний как к отделу который генерирует затраты.

Я думал мой пример с автосоесарем будет понятен. Каждый инженер в какой то степени автослесарь но далеко не каждый автослесарь это инженер способный спроектировать ДВС и подвеску для него и встроить это все общую систему.

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

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

Вот вы уходили на Java, неужели вам не приходилось полностью ломать свой подход и свои привычки к разарботке? Вы же согласны что разработка на бейсике и на любом другом ООП языке это вообще абсолютно разные занятия?

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность