На мой взгляд как раз умеренным гуманитариям в 1с будет сильно комфортнее чем технарям, особенно с хорошей подготовкой.
Так как в 1с сложно быть чистым разработчиком, нужно вникать в предметную область. А из за отсутствия ООП и как следствие примитивной ide для работы в 1с требуется повышенное внимание, отличная память, развитое воображение, умение читать модули по 10-20 000 строк, держать в голове прочитанное так как логика начинается а форме, потом уходит в модуль с вызовом сервера, потом в модуль сервера, затем вызывает процедуры из модуля повт.исп которые в свою очередь вызывают функции ещё из нескольких модулей и все это для одной функции одной сущности.
Это в java/c# ide подскажет тебе какие методы можно применять к данному типу, где он используется. Плюс сам подход ООП снизит сложность ограничив видимость кода и его количество.
К примеру, в других языках программирования вам придётся вручную описывать все атрибуты классов (то есть их поля), писать скрипты для создания таблиц в базе данных, а потом эту базу данных и обновлять (это называется миграцией). Всё это абсолютно рутинная работа, которая вряд ли принесёт большое удовольствие
Для всех enterprise языков есть фреймворки с ORM которые делают эту работу.
От разработчика требуется только описать классы.
Что касается рутины, а порой и отчаянья то это попытка доработать что то в типовой конфигурации, где вся логика размазана по 10 общим модулям в каждом из которых по 15000 строк.
Разработка/сопровождение крупной системы на языке без ООП в т.ч. 1С (особенно 1с с их подходом к общим модулям где нет иерархии) это как постройка дома из пеноплекса. (На Ютубе есть ребята которые это практикуют и других учат как правильно делать).
Зачем производители роутеров делают возможность отключить OFDMA и MU MIMO если это такие хорошие технологии?
И еще вопрос, если у меня к 2х диапазонному роутеру на 2.4 ГГц подключен десяток устройств (пылесос, алиса и.т.п), а на 5 Ггц гарантированно подключено только одно устройство VR Шлем 132 DFS канал + 80Мгц полоса, при этом рядом стоит еще один роутер в котором включен только 5 ГГц на 48 канале с шириной полосы в 40 Мгц к которому подключены еще ~15 устройств, которые генерят трафик (ТВ, Телефоны).
Проблема это все сопровождать, развивать, масштабировать. У меня есть опыт построения систем федерального уровня с базами в несколько терабайт, и огромными нагрузками, и работа с этими системами это в 90% случаев борьба с платформой, и СУБД. В общем все прелести монолита + отношение 1С к СУБД как набору DBF.
Мы покупаем промышленные СУБД за десятки миллионов что бы использовать их на уровне SELECT + максимально примитивный INSERT весь остальной функционал этих СУБД можно использовать только вопреки и с огромными костылями и сложностями.
Ну вот запросами в "бесшовной интеграции" и реализовано, т.е. часть форм из ДО просто скопировано визуально.
А дальше через WEB сервис запрашивается струкутра данных и полученными данными заполняется копия формы.
В то же время если бы это были системы построенные на современных подходах к разработке, мы бы нативно открывали форму из другой системы в едином интерфейсе, т.е. при изменении на стороне ДО нам не приходилось бы дорабатывать копии форм и структуры данных в библиоткеке бесшовной интеграции, да и сама библиотека была бы не нужна.
Ваш пример с "системой" из нескольких конигураций приводит к тому что пользователь должен переключаться между разными интерфейсами если работает с несколькими решниями. Т.е. в нашем примере:
Работаем в ERP, согласовываем в ДО приводит к тому что нужно переходить в разные приложения. Ну или использовать очень ограниченные костыли в виде копий форм из ДО.
Только через COM и с кучей ограничений и условий. Плюс открытие окна одного приложения в другом это только самая вершина, тут хотя бы аналогию можно провести.
Вы действительно не понимаете разницу между РИБ и микросервисной/сервисной архитектурой?
Вот представьте что у вас в компании развернут сервис по работе с контрагентами, все части вашей системы (договора, документооборот и.т.п) при попытке подбора контрагента обращаются к нему, он хранит в своей собсвтенной базе списки контрагентов, отдает отрендеренную форму контрагента и.т.п.
Если у вас стало так много контрагентов что 1 серверне справляется вы разворачиваете еще один сервер и ставите между ними фасад который определяет на какой сервер отправить запрос (например по коду контрагента).
Т.е. вы вот когда в интернете переходите по ссылкам, вы же понимаете что за каждой ссылкой может стоят своя инфраструктура которая вообще в другой стране расположена, это для вас это цельное приложение.
Самый хороший пример того насколько ущербна 1С это библиотека "бесшовной" интеграции с документооборотом. Суть в том что вы можете процессы согласования отдавать в ДО, а результаты и ход процесса отслеживать в своей конфигурации... Вот только на 1С нельзя сделать ничего лучше чем просто продублировать все формы из ДО в эту библиотеку.
Как бы это работало в нормальном виде?
Просто iframe в который подтягиваются данные из системы согласования с офролемением через css. В 1С это могло бы выглядеть как открытие окна одного приложения в окне другого при том что пользователь не понимал бы что сейчас он видит данные из другной базы.
Я как то был на инфостарт и задавал вопрос Олегу Бартунову, можно ли где то ознакомиться с best practices по эксплуатции крупных монолитных баз от 1 Tb и выше.
На что получил ответ:
" best practices по эксплуатции крупных монолитных баз от 1 Tb заключается в том что бы не создавать крупные монолитные базы от 1 Tb"
И что примерно с 2002 года индустрия уходит от монолитов в сторону сервисов, так как объемы автоматизации а так же данных растут, и держать это все в одной базе бессмысленно, так как разные категории данных имеют разную критичность, разные объемы, разную нагрузку. Не просто так придумали разделение OLAP/OLTP.
Любая система на 1С это жесточайший монлит на всех уровнях от кода до субд.
"Готовы на C# и WinForms написать за неделю простую учетную систему? "
Из пластилина легко слепить детскую игрушку. Но самолет из пластилина сделать тяжело.
Никто не спорит что на 1С низкий порог и быстрая разработка ларьков. Но стране нужно не это, стране нужна автоматизация мега корпораций таких как газпром, почта россии, огромных заводов которые являются городами.
Многие 1С специалисты, и вы в том числе мыслите категориями ИП, когда нужно быстро и дешево. Я вот на ютубе смотрю канал одного человека, он там из Пеноплекса дом строит.
Тоже говорит смотрите как быстро получается, и дешево, и даже тепло.
Я за свою карьеру в 1С (18 лет разработки) построил не мало таких вот "домов" из пеноплекса, и пока ты его строишь всё супер, проблемы начинаются ближе к концу, когда нужно возводить перекрытия, крышу, сантехнику, вешать шкафы и полки и много чего другого...
Но база размером в 30 ГБ еле работала у одного, не говоря уж о 10.
В этом и суть многоядерных серверных процессоров. Они оптимизированы под большую нагрузку, а с маленькой работают плохо.
Не важно 1 пользователь у вас или 40, на многоядерном сервере скорость работы будет для них +/- одинаковая.
В случае с малоядерными десктопными ПК скорость работы 80 пользоватеелй будет значительно медленее чем скорость работы 1 пользователя. Но скорость работы 1 пользователя будет значительно выше чем скорость работы 1 пользователя на многоядерном сервере.
(Ну и конечно напомню что мы говорим имеено о севере 1С а не о севере СУБД, потому что для СУБД ситуация более сложная, а если СБУД это PG на Windows то и вообще безвыходная).
Сервер 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) всю эту кухню знают, и так же по себе знают насколько важна однопоточная производительность для приложений которые не умеют в многопоток.
Все что вы описали phyton специалист сделает быстрее и лучше за счёт отличных библиотек по работе с xml и паркингу html. Код будет понятнее.
У меня есть опыт написания html парсера и генератора на 1c и это по уровню где то 99й год, собираем текст из строк и шаблонов, и так же парсер, да что говорить даже регулярок нет.
И у тебя удобные структуры данных для работы, и главное простой и понятный код.
В итоге как показала практика, на долгой дистанции выгоднее сделать на питоне парсер и отдавать результаты в 1с через мни http сервер чем реализовывать и что намного более важно сопровождать и развивать парсер на 1с.
Питон как язык можно выучить за 3 дня. Дальше уже библиотеки и ООП, и этому можно учиться всю жизнь.
Я думаю, что не каждый программист на java сможет то, что вы написали
Я не просто так думаю я в этом уверен.
Но это как раз и доказывает то что я написал. Есть Java программисты, есть 1С Программисты, есть 1С ники. У каждого из них своя работа. Которая частично пересекается но в общем и целом сильно отличается.
Я вот например 1С Программист, т.е. занимался разработкой гос. систем которые работают в масштабах страны и миллионов пользователей.
Я пару раз касался УХ и УПП и я там как первокласник себя ощущаю, а задачи типа "Внедрение ERP 2.5 На этапе моделирования бюджетной модели, штатному консультанту требуется помощь. Вопросы по формированию Плана закупок. Также необходимо проверить ход моделирования -убедиться в том, что штатный консультант правильно моделирует. Позадавать наводящие вопросы, оценить компетенцию шт..."
Для меня звучат как "бла бла бла".
"Там где всё решается прямо, в 1с идем "зигзагом" ) Но такова платформа, могли бы, шли прямо, но увы, выкручиваемся как можем. "
Я не вижу ничего плохого в том что бы выкручиваться. Почитайте как работает Maincraft там хак на хаке и хаком погоняет. И 1С тут вообще не в первых рядах.
Бейсик или ООП не имеет значения пока у вас 5 модулей по 15 процедур в каждом и вся система умещается в голове.
Когда вы пишите систему и в ней уже под 300 общих модулей в каждом из которых по 5000-40 000 строк сразу приходит понимание зачем нужен ООП.
И когда размер СУБД выростает до 1,5 Tb вы начинаете понимать зачем нужны микросервисы.
Ахахаха, очередной экстрасенс подъехал. Ну да, я ведь только на 1С писал код, и только типовые дорабатывал. Даже, когда мне был подростком.
Из статьи я узнал только про то что написал. Там в начале жизненный путь автора описан.
Программисты 1С не пишут код? По-моему, у них связаны руки и они работают в одной парадигме, но при этом делают fullstack по факту.
Это вопрос ближе к философскому, я свое мнение высказал вы свое, на этом предлагаю закончить.
Согласен.
Собственно это основное что я хотел сказать, рад что тут есть взаимопонимание.
Говнокодить это не мешает, и не только на 1С.
Вы немного не так поняли смысл размещения ссылки на стандарты. Попробую еще раз объяснить. 90% стандартов которые там описаны, дискредитируют язык BSL, потому что всё это должно быть не на уровне отдельной книге и в голове у программиста а заложено в дизайн языка и IDE.
Вопрос говнокода это вообще отдельный вопрос и его я не касаюсь так как это тоже сильно спорная тема.
Попробую провести аналогию, вот представьте что IDE в 1С не могла бы проверять синтаксические ошибки, и как решение проблемы в методику добавили бы пункт: "Программист обязан перед запуском проверить код на отсутствие синтаксических ошибок путем выполнения кода в голове".
Вроде все по уму, есть стандарт, нужно соблюдать, словил ошибки, ну значит плохой программист не соблюдаешь стандарты.
"крутые и с помощью этой платформы можно написать, что угодно "
Кстати тут автор прав, при желании НАПИСАТЬ можно что угодно, все базовое там есть, процедуры / циклы / условия / работа с СУБД. Так что формально так и есть, при должной мотивации на 1С можно выполнить любую учетную задачу, ну максимум с привлечением сторонних разработок в каких то системных вещах.
Я в разработке 18 лет, и не скажу что прям все понял, но одну вещь я понял достаточно на глубоком уровне: Написать программу это первые 90% работы. Вторые 200% это её сопровождать, развивать, масштабировать, интегрировать.
А вот это крайне тяжело делать на бэйсике с вкраплениями SQL.
На мой взгляд как раз умеренным гуманитариям в 1с будет сильно комфортнее чем технарям, особенно с хорошей подготовкой.
Так как в 1с сложно быть чистым разработчиком, нужно вникать в предметную область. А из за отсутствия ООП и как следствие примитивной ide для работы в 1с требуется повышенное внимание, отличная память, развитое воображение, умение читать модули по 10-20 000 строк, держать в голове прочитанное так как логика начинается а форме, потом уходит в модуль с вызовом сервера, потом в модуль сервера, затем вызывает процедуры из модуля повт.исп которые в свою очередь вызывают функции ещё из нескольких модулей и все это для одной функции одной сущности.
Это в java/c# ide подскажет тебе какие методы можно применять к данному типу, где он используется. Плюс сам подход ООП снизит сложность ограничив видимость кода и его количество.
Для всех enterprise языков есть фреймворки с ORM которые делают эту работу.
От разработчика требуется только описать классы.
Что касается рутины, а порой и отчаянья то это попытка доработать что то в типовой конфигурации, где вся логика размазана по 10 общим модулям в каждом из которых по 15000 строк.
Разработка/сопровождение крупной системы на языке без ООП в т.ч. 1С (особенно 1с с их подходом к общим модулям где нет иерархии) это как постройка дома из пеноплекса. (На Ютубе есть ребята которые это практикуют и других учат как правильно делать).
Понимаю что прошло уже много лет...
Но все же вдруг удастся получить ответ :)
Зачем производители роутеров делают возможность отключить OFDMA и MU MIMO если это такие хорошие технологии?
И еще вопрос, если у меня к 2х диапазонному роутеру на 2.4 ГГц подключен десяток устройств (пылесос, алиса и.т.п), а на 5 Ггц гарантированно подключено только одно устройство VR Шлем 132 DFS канал + 80Мгц полоса, при этом рядом стоит еще один роутер в котором включен только 5 ГГц на 48 канале с шириной полосы в 40 Мгц к которому подключены еще ~15 устройств, которые генерят трафик (ТВ, Телефоны).
Нужно ли в этом включать OFDMA и/или MU MIMO ?
Построить можно что угодно из чего угодно.
Проблема это все сопровождать, развивать, масштабировать. У меня есть опыт построения систем федерального уровня с базами в несколько терабайт, и огромными нагрузками, и работа с этими системами это в 90% случаев борьба с платформой, и СУБД. В общем все прелести монолита + отношение 1С к СУБД как набору DBF.
Мы покупаем промышленные СУБД за десятки миллионов что бы использовать их на уровне SELECT + максимально примитивный INSERT весь остальной функционал этих СУБД можно использовать только вопреки и с огромными костылями и сложностями.
Ну вот запросами в "бесшовной интеграции" и реализовано, т.е. часть форм из ДО просто скопировано визуально.
А дальше через WEB сервис запрашивается струкутра данных и полученными данными заполняется копия формы.
В то же время если бы это были системы построенные на современных подходах к разработке, мы бы нативно открывали форму из другой системы в едином интерфейсе, т.е. при изменении на стороне ДО нам не приходилось бы дорабатывать копии форм и структуры данных в библиоткеке бесшовной интеграции, да и сама библиотека была бы не нужна.
Ваш пример с "системой" из нескольких конигураций приводит к тому что пользователь должен переключаться между разными интерфейсами если работает с несколькими решниями. Т.е. в нашем примере:
Работаем в ERP, согласовываем в ДО приводит к тому что нужно переходить в разные приложения. Ну или использовать очень ограниченные костыли в виде копий форм из ДО.
Только через COM и с кучей ограничений и условий. Плюс открытие окна одного приложения в другом это только самая вершина, тут хотя бы аналогию можно провести.
Вы действительно не понимаете разницу между РИБ и микросервисной/сервисной архитектурой?
Вот представьте что у вас в компании развернут сервис по работе с контрагентами, все части вашей системы (договора, документооборот и.т.п) при попытке подбора контрагента обращаются к нему, он хранит в своей собсвтенной базе списки контрагентов, отдает отрендеренную форму контрагента и.т.п.
Если у вас стало так много контрагентов что 1 серверне справляется вы разворачиваете еще один сервер и ставите между ними фасад который определяет на какой сервер отправить запрос (например по коду контрагента).
Т.е. вы вот когда в интернете переходите по ссылкам, вы же понимаете что за каждой ссылкой может стоят своя инфраструктура которая вообще в другой стране расположена, это для вас это цельное приложение.
Самый хороший пример того насколько ущербна 1С это библиотека "бесшовной" интеграции с документооборотом. Суть в том что вы можете процессы согласования отдавать в ДО, а результаты и ход процесса отслеживать в своей конфигурации... Вот только на 1С нельзя сделать ничего лучше чем просто продублировать все формы из ДО в эту библиотеку.
Как бы это работало в нормальном виде?
Просто iframe в который подтягиваются данные из системы согласования с офролемением через css. В 1С это могло бы выглядеть как открытие окна одного приложения в окне другого при том что пользователь не понимал бы что сейчас он видит данные из другной базы.
Я как то был на инфостарт и задавал вопрос Олегу Бартунову, можно ли где то ознакомиться с best practices по эксплуатции крупных монолитных баз от 1 Tb и выше.
На что получил ответ:
" best practices по эксплуатции крупных монолитных баз от 1 Tb заключается в том что бы не создавать крупные монолитные базы от 1 Tb"
И что примерно с 2002 года индустрия уходит от монолитов в сторону сервисов, так как объемы автоматизации а так же данных растут, и держать это все в одной базе бессмысленно, так как разные категории данных имеют разную критичность, разные объемы, разную нагрузку. Не просто так придумали разделение OLAP/OLTP.
Любая система на 1С это жесточайший монлит на всех уровнях от кода до субд.
"Готовы на C# и WinForms написать за неделю простую учетную систему? "
Из пластилина легко слепить детскую игрушку. Но самолет из пластилина сделать тяжело.
Никто не спорит что на 1С низкий порог и быстрая разработка ларьков. Но стране нужно не это, стране нужна автоматизация мега корпораций таких как газпром, почта россии, огромных заводов которые являются городами.
Многие 1С специалисты, и вы в том числе мыслите категориями ИП, когда нужно быстро и дешево. Я вот на ютубе смотрю канал одного человека, он там из Пеноплекса дом строит.
Тоже говорит смотрите как быстро получается, и дешево, и даже тепло.
Я за свою карьеру в 1С (18 лет разработки) построил не мало таких вот "домов" из пеноплекса, и пока ты его строишь всё супер, проблемы начинаются ближе к концу, когда нужно возводить перекрытия, крышу, сантехнику, вешать шкафы и полки и много чего другого...
Вы вообще не понимаете о чем пишите.
У всех процесоров х86 отдельные кэши на каждое ядро, называются они L2.
У интел (в отличии от ZEN2) как раз L3 общий для всех ядер
Остальное даже комментировать не буду, так как вы все равно не поймете.
Спасибо за инфу, привык что MS SQL использует все до чего дотянется, а с PG только недавно...
Если вы ставите PG под Windows (а по косвенным признкам видно что дело было под Windows) то там может быть вообще что угодно.
В этом и суть многоядерных серверных процессоров. Они оптимизированы под большую нагрузку, а с маленькой работают плохо.
Не важно 1 пользователь у вас или 40, на многоядерном сервере скорость работы будет для них +/- одинаковая.
В случае с малоядерными десктопными ПК скорость работы 80 пользоватеелй будет значительно медленее чем скорость работы 1 пользователя. Но скорость работы 1 пользователя будет значительно выше чем скорость работы 1 пользователя на многоядерном сервере.
(Ну и конечно напомню что мы говорим имеено о севере 1С а не о севере СУБД, потому что для СУБД ситуация более сложная, а если СБУД это PG на Windows то и вообще безвыходная).
Сервер 1С однопоточный, в том плане что один сеанс пользователя / фонового задания - один поток. Самих потоков конечно может быть много так как пользователей у вас много, каждый из них генерирует много задач, но каждая такая задача выполняется исключительно одним ядром (одним потоком в случаее с HT).
Соответственно важна для него производительность на одно ядро (а не частота процессора, так как для разной архитектуры IPC разное).
Самый простой способ сравнить процессоры по этому показателю это CPU-Z
Intel Xeon Silver 4216 - 370/8400 (https://valid.x86.fr/bench/lf3a0q)
Intel Core i9-12900K - 800/11400 (https://valid.x86.fr/bench/9ar1d6)
Intel Core i7-12700K - 850/9800 (https://valid.x86.fr/bench/f8003w)
В случае пока количество сеансов <= количеству потоков (с учетом 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) всю эту кухню знают, и так же по себе знают насколько важна однопоточная производительность для приложений которые не умеют в многопоток.
Все что вы описали phyton специалист сделает быстрее и лучше за счёт отличных библиотек по работе с xml и паркингу html. Код будет понятнее.
У меня есть опыт написания html парсера и генератора на 1c и это по уровню где то 99й год, собираем текст из строк и шаблонов, и так же парсер, да что говорить даже регулярок нет.
С питоном: pip install beautifulsoup, pip install requests, pip install pandas
И у тебя удобные структуры данных для работы, и главное простой и понятный код.
В итоге как показала практика, на долгой дистанции выгоднее сделать на питоне парсер и отдавать результаты в 1с через мни http сервер чем реализовывать и что намного более важно сопровождать и развивать парсер на 1с.
Питон как язык можно выучить за 3 дня. Дальше уже библиотеки и ООП, и этому можно учиться всю жизнь.
Подскажите пожалуйста я же правильно понимаю что в вашем примере тестовый контур не изолирован от основного?
На мой взгляд это основная проблема в безопасности. Если развести по разным контурам то проблему полных прав внешних подрядчиков этот решит.
Внутренние пользователи не должны иметь доступа к внешним обработкам и полного доступа, а так же админских прав.
Выглядит не очень сложно.
Если подрядчику требуется работать в общем контуре то только в рамках обычных прав и под запись видео его сеанса.
Я не просто так думаю я в этом уверен.
Но это как раз и доказывает то что я написал. Есть Java программисты, есть 1С Программисты, есть 1С ники. У каждого из них своя работа. Которая частично пересекается но в общем и целом сильно отличается.
Я вот например 1С Программист, т.е. занимался разработкой гос. систем которые работают в масштабах страны и миллионов пользователей.
Я пару раз касался УХ и УПП и я там как первокласник себя ощущаю, а задачи типа "Внедрение ERP 2.5 На этапе моделирования бюджетной модели, штатному консультанту требуется помощь. Вопросы по формированию Плана закупок. Также необходимо проверить ход моделирования -убедиться в том, что штатный консультант правильно моделирует. Позадавать наводящие вопросы, оценить компетенцию шт..."
Для меня звучат как "бла бла бла".
"Там где всё решается прямо, в 1с идем "зигзагом" ) Но такова платформа, могли бы, шли прямо, но увы, выкручиваемся как можем. "
Я не вижу ничего плохого в том что бы выкручиваться. Почитайте как работает Maincraft там хак на хаке и хаком погоняет. И 1С тут вообще не в первых рядах.
Бейсик или ООП не имеет значения пока у вас 5 модулей по 15 процедур в каждом и вся система умещается в голове.
Когда вы пишите систему и в ней уже под 300 общих модулей в каждом из которых по 5000-40 000 строк сразу приходит понимание зачем нужен ООП.
И когда размер СУБД выростает до 1,5 Tb вы начинаете понимать зачем нужны микросервисы.
Почему вы решили что я унижаю программистов 1С?
Например директор компании это не программист. Значит ли что я унижаю директоров компаний?
Ну или если я напишу что backen и frontend разработчики это разные по сути специальности то кого я тут унжаю Back или Front?
Из статьи я узнал только про то что написал. Там в начале жизненный путь автора описан.
Это вопрос ближе к философскому, я свое мнение высказал вы свое, на этом предлагаю закончить.
Собственно это основное что я хотел сказать, рад что тут есть взаимопонимание.
Вы немного не так поняли смысл размещения ссылки на стандарты. Попробую еще раз объяснить. 90% стандартов которые там описаны, дискредитируют язык BSL, потому что всё это должно быть не на уровне отдельной книге и в голове у программиста а заложено в дизайн языка и IDE.
Вопрос говнокода это вообще отдельный вопрос и его я не касаюсь так как это тоже сильно спорная тема.
Попробую провести аналогию, вот представьте что IDE в 1С не могла бы проверять синтаксические ошибки, и как решение проблемы в методику добавили бы пункт: "Программист обязан перед запуском проверить код на отсутствие синтаксических ошибок путем выполнения кода в голове".
Вроде все по уму, есть стандарт, нужно соблюдать, словил ошибки, ну значит плохой программист не соблюдаешь стандарты.
"крутые и с помощью этой платформы можно написать, что угодно "
Кстати тут автор прав, при желании НАПИСАТЬ можно что угодно, все базовое там есть, процедуры / циклы / условия / работа с СУБД. Так что формально так и есть, при должной мотивации на 1С можно выполнить любую учетную задачу, ну максимум с привлечением сторонних разработок в каких то системных вещах.
Я в разработке 18 лет, и не скажу что прям все понял, но одну вещь я понял достаточно на глубоком уровне: Написать программу это первые 90% работы. Вторые 200% это её сопровождать, развивать, масштабировать, интегрировать.
А вот это крайне тяжело делать на бэйсике с вкраплениями SQL.