Я думаю, что не каждый программист на 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.
"Но на них нельзя за пару часов сделать простенький складской учет, с печатными формами, отчетами "
Проблема только что индустрии не нужно делать "простенький складной учет за пару часов".
Индустрия хочет ERP систему уровня транснационального холдинга, хочет систему расчета комунальных услуг для всей страны, систему бронирования билетов, систему управления ЖД перевозками и.т.п.
И продукты на 1С давно уже решают такие проблемы, взять тот же Газпром который хоть и на SAP официально, а не официально в SAP все грузится из систем написанных на 1С и выгружается обратно в другие системы написанные на 1С. Автоматизация на SAP у нас в РФ чем то похожа на сказку "Каша из топора".
Проблема 1С как раз в том что она изначально проектировалась как фреймворк для "простенький складной учет за пару часов", а пришла к автоматизации работы почты РФ.
"Да у 1С есть болячки, а где их нет. "
То что происходит с ЯП на котором работает 1С это не болячки, это инвалидность или дряхлость, выбирайте что ближе.
Если проводить аналогии то есть такой "язык" Scratch, очень низкий порог входа, можно за 5 минут написать код управления машинкой игровой. Но ведь не кто не пишет на Scratch автоматизацию для почты РФ? А на 1С пишут.
90% работы 1С это поддержка и доработка типовых. Вот так что бы с 0 писать продукты уровня типовых на всю страну если наберется 100 компаний уже хорошо.
Франчей же несоизмеримо больше. Вы вот пришли в Java и можете сравнить промышленную разработку и сопровождение УТ на заводе. Сами же писали в статье про отношение к ИТ внутри компаний как к отделу который генерирует затраты.
Я думал мой пример с автосоесарем будет понятен. Каждый инженер в какой то степени автослесарь но далеко не каждый автослесарь это инженер способный спроектировать ДВС и подвеску для него и встроить это все общую систему.
Получение данных из БД и применение бизнес логики это часть разработки но не вся разработка, это в какой то степени рутина разработчика. Задача программиста в том числе и создание абстракций, разработка системы в рамках которых будет выполняться решение прикладных задач. Данные в базу можно положить десятком разных способов (не в 1С) и задача программиста не просто положить данные а сделать так что бы это было масштабируемо, встраивалось в архитектуру, было удобно и понятно другим программистам.
Возможно я как то не удачно сформулировал свою мысль, но я не знаю как по другому объяснить разницу между разработкой на промышленных ООП языках и на бэйсике.
Вот вы уходили на Java, неужели вам не приходилось полностью ломать свой подход и свои привычки к разарботке? Вы же согласны что разработка на бейсике и на любом другом ООП языке это вообще абсолютно разные занятия?
Очень большая статья, с чем то согласен с чем то нет, но если обобщить то:
Многие "программисты 1С" на самом деле не программисты все что они делают это занимаются сопровождением и доработкой типовых. Это примерно как называть инженером автослесаря или работника детейлинга которые ремонтируют/тюнят автомобили или ставит на них допы.
Автор как раз из тех кто как раз не был никогда программистом так как дорабатывал/перепрабатывал типовые решения а потом попал в компанию где работают программисты. Отсюда и хорошие впечателния от Java.
У 1С три ключевые проблемы с точки зрения программиста (т.е. человека который с 0 пишет на 1С большие системы)
Вообще писать про то что в 1С плохо это не благодарное занятие, все что в 1С плохо - отлично описали сами 1С, по ссылке https://its.1c.ru/db/v8std, если интересно можете сходить почитать:
"Система стандартов и методик разработки конфигураций"
По объему это практически книга правил, которых нужно придерживаться что бы проект не превратился в помойку уже через год. Все эти правила нужно помнить, IDE вам никак не поможет, просто потому что при использовании динамической типизации да еще и в процедурном стиле нет возможности реализовать эти правила, их может соблюдать только человек каждый раз обрабатывая их в голове.
Ну и пару примеров для тех кому лень вникать:
Пример №1 "Область видимости, Программный интерфейс"
В современных ЯП есть ограничение области видимости, упрощенно что бы IDE вам не давала в подсказке методы которые в принципе не рассчитаны на использование, есть интерфейсы которые скрывают за собой реализацию и.т.п.
В 1С такого нет, и вместо этого нам предлагают в модуле использовать "коментарий":
#Область ПрограммныйИнтерфейс
// Код процедур и функций
#КонецОбласти
"Комментарий" потому что она не влияет на работу кода, это исключительно оформление внутри модуля, что то типа комментария для других программистов, что можно смело вызывать функции описанные в этой секции. Если завтра из этой секции при обновлении какие то методы будут вынесены иизменены вы об этом узнаете в рантайме.
Конечно трогать такие методы "строго запрещено" методикой, но компилятор и IDE это никак не проверяет. Ну и конечно экспортные процедуры описанные вне этой области все также доступны для вызова откуда угодно и кем угодно, просто под личную ответственность того кто их использует.
Пример №2 "Описание экспортных (интерфейсных) процедур и фцнкций"
Отдельное искуство в 1С это требования к комментариям:
// Параметры:
// Реквизиты - Строка - имена реквизитов, перечисленные через запятую.
// Например, "Код, Наименование, Родитель".
// - Структура, ФиксированнаяСтруктура - в качестве ключа передается
// псевдоним поля для возвращаемой структуры с результатом,
// а в качестве значения (опционально) фактическое имя поля в таблице.
// Если значение не определено, то имя поля берется из ключа.
// - Массив Из Строка, ФиксированныйМассив Из Строка - имена реквизитов.
Так как у нас дин. типизация, а в больших проектах все же желательно описывать параметры функций, вендор нам предлагает описать эти параметры СЛОВАМИ что бы другие программисты (не IDE !!!) смогли это прочитать, запомнить и у себя в голове потом все это развернуть. Причем там важно еще и отступы соблюдать и офоромление, и потом естественно это все поддерживать в ручном режиме при изменении кода.
Естественно это вообще никак не свзяано с кодом и не как не автоматизировано.
Тут можно возразить, что при статической типизации и ООП придется все равно все это описывать и даже намного больше. Вот только разница в том что все что ты описал это твой фундамент, ты один раз описал и облегчил работу себе и тем кто придет после тебя, ты установил правила, соблюдение которых будет проверять за тебя IDE и любое отступление от них вызовет предупреждение.
При всех плюсах платформы, писать монолитные корпоративные а иногда и государственные ИС на бейсике это задача для очень умных и сильных духом людей, которая не каждому по плечу. Это как по мне все что нужно знать новичку про 1С.
Тем кто далек от 1С и кодит на Java все это вообще не особо интересно, разве что из серии не смог осилить C#, пойду в 1С...
Хотел написать именно такой комментарий, смотрел обе игры: Pillars of Eternity, Wasteland2
Обе вроде интересны но техническая реализация ужасна настолько что даже хороший игровой процесс не удержал меня в игре. При этом тоже вспоминал старые игры и fallout 1.
Делаем RO асинхронную реплику (вам же не нужно прям в realtime получать данные, 100-1000 мс задержки вполне норм, при этом не нагружаем прод. базу ожиданиями фиксации транзакций в RO реплике).
В реплике на основании информации о соответствии полей таблиц и объектов метаданных в той же базе генерируем View с названиями таблиц и полей соответствующими именам метаданных.
В итоге имеем отдельный сервер где можно крутить разные аналитики и SQL интеграции не нагружая основной сервер. При этом запросы пишутся почти как в 1С Конечно итоги и срезы последних нужно самим подключать, и какой то навык нужно иметь, лучше конечно первый раз писать в консоли и потом транслировать в SQL и затем уже писать через View что бы меньше ошибок. Основные плюсы потом в сопровождении, проще читать, проще менять запросы и.т.п.
Статья не бесполезная, многие кто занимается переходом с УПП в ERP сталкиваются с решением подобной задачи, но без ссылок на инструменты и расширения, практического смысла не много.
Есть вопрос по разделам:
"4. Автоматизация заполнения объектов"
"5. Гибкие права доступа к объектам"
Как они относятся к теме статьи? Не все получилось сделать ролями и часть делали с помощью "5. Гибкие права доступа к объектам" ? В УПП был аналогичный функционал?
Плюс не понятно как при маппинге пользователей УПП на типовые профили решалась проблема с тем что в типовом профиле есть лишние права.
Т.е. понятна ситуация когда есть типовой профиль и к нему нужно добавить дополнительные права, делаем опциональный профиль и таким образом получаем требуемую функциональность. Но если в типовом профиле есть лишние права то такой вариант не сработает.
Вот тоже посмотрел тесты, хотел написать то же самое. Xeon 2673v3 (12 ядер, 3.3 ГГц) за 6500 рублей + Atermiter 4000р + 32 RAM (4 плашки по 8 гб 2133) за 6500.
Итого 17000р, дают практически тот же результат по задержке: 71,2, и незначительно меньше по скорости: 62850.
При этом с DDR5 только модули памяти стоят 30 000р, что на 460% дороже а быстрее на 30%.
И не особо понятно почему в потребительских сегментах не делать 4 канала. Понятно что больше дорожек и выводов нужно делать, и немного больше кристал процессора получится, но не руками же это делают, а "роботу" не так и принципиально сколько дорожек разводить. Не так дорого это выходит.
Доходит до смешного, нам предлагают 12 ядерные i7 с 25 мб кэша и двумя двумя контроллерами памяти. Даже если есть задачи которые способны нагрузить 12 ядер, то как их прокормить?
Вот Apple молодцы сделелали 4 канала DDR4 (там 2 но 128 битных что как раз равно 4м 64 битных в Intel/AMD) и у них на выходе M1 Pro дает 200 ГБ/с, а M1 Max - 400 ГБ/с.
Что такое 85 ГБ/с на топовой DDR5 памяти в разгоне против даже 200 ГБ/с у M1 Pro и уж темболее 400 ГБ/с у M1 Max?
На мой взгляд ГИС ЖКХ обычная система консолидирующая данные не плохая и не хорошая. А 60% проблем свзяано с требованиями по подписи и шифрованию протоколов если почитать чат разработчиков интеграций, то там основные проблемы с сертификатами, и с тем что временами сервис не работает.
Плюс на мой взгляд очень сильно намудрили с квитированием, бесполезная по сути операция (для абонента) и очень сложная для РСО и УК.
Остальные 30% проблем связаны с тем что у многих РСО и УК просто нет ИТ специалистов что бы решать проблемы работы с ГИС ЖКХ, все идет через несколько посредников, или вообще EXCEL отсюда и проблемы с непрогруженными показаниями.
Хотели бы навести порядок, сделали бы единный билинг для ФЛ на всю страну. Если откинуть различные извращения, стандартизировать и упростить правила расчет то система будет достаточно простая. И многие РСО с удовольствием бы платили за использование такой системы в облаке.
Да, признаю со свалкой погорячился, скажем так у меня есть внутреннее убеждение что 28 нм могут продать, а вот 12 нм просто прийти и купить не получится. Даже за большие деньги.
На мой взгляд доверять нельзя никому и особенно нельзя доверять себе, потому что как показывает мой опыт нет врага страшнее чем ты сам.
Закладкой может воспользоваться тот кто её заложил, это плохо но тем не менее гораздо хуже если в процессоре / архитектуре есть уязвимости которые может найти кто угодно. И такие ошибки и уязвимости есть всегда как и в любой программе, хорошие программы отличаются от плохих в первую очередь степенью тестирования и привлеченных ресурсов. А полноценное тестирование / исследование может потребовать ресурсов больше чем разработка. Это такая же школа как и разработка процессоров.
И по факту имеем пониженную вероятность закладок в процессор (на фабрике) и повышенную вероятность наличия уязвимостей (т.к. просто нет ресурсов на полное тестирование).
все эти танцы - только для того, чтобы выпускать эти процессоры под своим брендом, как сейчас модно.
На мой взгляд это нужно в первую очередь для развития. Можно вспомнить китайский MediaTek они начинали без амбиции на мировое господство с MT6218B в 2003, а сейчас выпускают Dimensity 1200 который по соотношению цена/железо рвет флагманский qualcomm, но по софту конечно отстает т.к. за плечами qualcomm стоит google а вот MediaTek справляется своими силами. Но на потребительском уровне это отставание не заметно вообще а вот по цене выгода заметна.
Ребята из MediaTek сделали правильную ставку на ARM и из откровенно ужасных MT6218B которые стояли во всех телефонах NOKLA (с ТВ и антенной) догнали лидеров (qualcomm) и обогнали конкурентов (Exynos). Еще год два и увидим первые сервера на ARM и у MediaTek уже есть все необходимые компетенции для того что бы предложить свои продукты.
Вот только какое развитие у vliw мне не понятно, intel вложились в него, но потом отказались, где кроме DSP он сейчас используется я и не знаю.
Я вообще не уверен что кто угодно может в ASML прийти и купить такой станок даже если у него будут деньги. Слишком ценный это ресурс что бы его за деньги продавать.
Это для нас деньги это мерило всего, но есть предел после которого деньги уже совсем по другому ценятся, и владельцы ASML уже давно далеко ушли от этого предела.
Как не пиши код но DDR3-1600 с 4х канальным контроллером так и останется DDR3-1600 с 4 каналами.
Да можно потратить ресурсы и оптимизировать узкие места, но точно так же можно потратить те же ресурсы на оптимизацию под x86 и получить такой же а то и больший прирост.
Но есть опасения что остальной мир не бросится переписывать библиотеки и JVM под vliw архитектуру, а доля кода тех же разработчиков сбера в общем коде решения не больше 10%.
Мой опыт и здравый смысл говорит о том что подсистема памяти и интерфейсы доступа к данным на внешних накопителях (кстати что у эльбруса, явно же не SATA3?) катастрофически влияют на скорость работы при реальной рабочей нагрузке на сервер. И даже в CPU с DDR4-2400 и 6ю каналами на серверах всё упирается в память, и особенно в случае с JAVA. И всё что можно делать со стороны программиста это как то работать с кэшем (что делать из Java не так то просто).
А в случае с СУБД еще интерфейсы доступа к внешним хранилищам. (сами хранилища выносим за скобки).
Поэтому даже при идеальном раскладе DDR3-1600 c 4 каналами памяти будет на 50% хуже чем DDR4 - 3000 c 6 каналами. И еще учитывая что везде скромно умалчивается о успехах в реализации межъядерного и межпроцессорного взаимодействия, можно предположить что в Эльбрусе это так же реализовано похуже чем на современных x86 и серверных чипсетах.
Тема тестирования серверных процессоров очень скользкая, так как работа сервера полностью отличается от работы игрового или рабочего ПК и в реальной работе на первый план выходят такие характеристики как Частота системной шины, Кол-во соединений QPI, размер и организация доступа к кэш памяти и.т.п. Это для десктопа где сидит один юзер и работает 5 программ кэш в 30 мб решает 90% доступа к памяти.
А вот сервер который обрабатывает 10 000 запросов в секунду свои 30 Мб выедает очень быстро, и дальше какой бы мощный процессор не был все его ядра стоят и ждут данных из памяти (показывая загрузку в 100% но ничего не делая). Не зря в последних моделях процессоров интел уже идет практически отдельный микроконтроллер который занимается анализом и предсказанием, частично конечно что бы загрузить ядра работой, но главная задача это упреждающее чтение в кэш.
Конечно у эльбруса с его 1.3 ггц не такой большой голод данных, но опять же там и инструкции по жирнее. Конечно было бы круто если бы сбер опубликовал результаты своих тестов.
Сделать процессор сложно, сделать серверный процессор сложно в квадрате, плюс серверный процессор существует не в вакууме ему ещё нужна соответствующая обвязка от которой так же много зависит (особенно в многопроцессорных системах).
Я в новостях часто читаю что наш процессор поможет нам обезопасить страну, от закладок в процессоре, от санкций и.т.п.
Но на мой взгляд:
1. Если дойдет до запрета продажи нам процессоров то наверное запретят продавать и материнские платы и жесткие диски и заказы на изготовление тоже размещать не дадут. Как то слабо вериться в сценарий когда запретят только процессоры.
2. Закладки (в процессорах) это конечно хорошо, но как показала практика meltdown и spectre и без закладок возможно получать доступ к памяти ядра системы. И на мой взгляд ещё не известно что хуже закладки которыми могут пользоваться только те кто их заложил, или подобные уязвимости доступные гораздо более широкому кругу лиц. И если уж Intel с их многолетним опытом допускают такие ошибки то какова вероятность наличия таких ошибок в новых архитектурах?
Вообще интересно было бы почитать мнение экспертов об устойчивости архитектуры эльбрусов к подобным проблемам и вообще к уязвимостям. На уровне моего понимания того как устроены процессоры использование длинных слов открывает больше векторов для атаки, но это скорее догадки чем предположение.
Если честно жаль что наш ЦП не на арм, у меня есть стойкое впечатление что мы сейчас на пороге (а может уже и дальше) революции и переходе всего мира ИТ на ARM, и тут можно было бы выстрелить, а пока всё что я понял и прочитал про архитектуру Эльбруса больше похоже на выстрел в ногу.
Теория заговора
Если погрузиться в теорию заговора, то можно предположить, что специалисты по ARM нужны всему миру, и что если делать ставку на ARM придется конкурировать со всем миром за специалистов, а если специалист заточен на vliw то вероятность что его куда сманят значительно уменьшается. Что то похожее у нас с 1С, ты можешь быть крутым спецом по 1С но за пределами 1С ты не интересен.
Подскажите пожалуйста я же правильно понимаю что в вашем примере тестовый контур не изолирован от основного?
На мой взгляд это основная проблема в безопасности. Если развести по разным контурам то проблему полных прав внешних подрядчиков этот решит.
Внутренние пользователи не должны иметь доступа к внешним обработкам и полного доступа, а так же админских прав.
Выглядит не очень сложно.
Если подрядчику требуется работать в общем контуре то только в рамках обычных прав и под запись видео его сеанса.
Я не просто так думаю я в этом уверен.
Но это как раз и доказывает то что я написал. Есть 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.
"Но на них нельзя за пару часов сделать простенький складской учет, с печатными формами, отчетами "
Проблема только что индустрии не нужно делать "простенький складной учет за пару часов".
Индустрия хочет ERP систему уровня транснационального холдинга, хочет систему расчета комунальных услуг для всей страны, систему бронирования билетов, систему управления ЖД перевозками и.т.п.
И продукты на 1С давно уже решают такие проблемы, взять тот же Газпром который хоть и на SAP официально, а не официально в SAP все грузится из систем написанных на 1С и выгружается обратно в другие системы написанные на 1С. Автоматизация на SAP у нас в РФ чем то похожа на сказку "Каша из топора".
Проблема 1С как раз в том что она изначально проектировалась как фреймворк для "простенький складной учет за пару часов", а пришла к автоматизации работы почты РФ.
"Да у 1С есть болячки, а где их нет. "
То что происходит с ЯП на котором работает 1С это не болячки, это инвалидность или дряхлость, выбирайте что ближе.
Если проводить аналогии то есть такой "язык" Scratch, очень низкий порог входа, можно за 5 минут написать код управления машинкой игровой. Но ведь не кто не пишет на Scratch автоматизацию для почты РФ? А на 1С пишут.
Я вот еще подумал немного. Вы в своей статье часто упоминаете термин "1С ник". Как по мне это отличное отражение.
Есть Java программист, а есть 1С Программист, есть 1С ник.
Это сильно разные специальности. Чистых 1С Программистов очень мало (по моим ощущением 10%) остальные кто работает с 1С это 1С ники.
Наверное так будет точнее.
Вы же поняли о чем я писал? Спор ради спора?
90% работы 1С это поддержка и доработка типовых. Вот так что бы с 0 писать продукты уровня типовых на всю страну если наберется 100 компаний уже хорошо.
Франчей же несоизмеримо больше. Вы вот пришли в Java и можете сравнить промышленную разработку и сопровождение УТ на заводе. Сами же писали в статье про отношение к ИТ внутри компаний как к отделу который генерирует затраты.
Я думал мой пример с автосоесарем будет понятен. Каждый инженер в какой то степени автослесарь но далеко не каждый автослесарь это инженер способный спроектировать ДВС и подвеску для него и встроить это все общую систему.
Получение данных из БД и применение бизнес логики это часть разработки но не вся разработка, это в какой то степени рутина разработчика. Задача программиста в том числе и создание абстракций, разработка системы в рамках которых будет выполняться решение прикладных задач. Данные в базу можно положить десятком разных способов (не в 1С) и задача программиста не просто положить данные а сделать так что бы это было масштабируемо, встраивалось в архитектуру, было удобно и понятно другим программистам.
Возможно я как то не удачно сформулировал свою мысль, но я не знаю как по другому объяснить разницу между разработкой на промышленных ООП языках и на бэйсике.
Вот вы уходили на Java, неужели вам не приходилось полностью ломать свой подход и свои привычки к разарботке? Вы же согласны что разработка на бейсике и на любом другом ООП языке это вообще абсолютно разные занятия?
Очень большая статья, с чем то согласен с чем то нет, но если обобщить то:
Многие "программисты 1С" на самом деле не программисты все что они делают это занимаются сопровождением и доработкой типовых. Это примерно как называть инженером автослесаря или работника детейлинга которые ремонтируют/тюнят автомобили или ставит на них допы.
Автор как раз из тех кто как раз не был никогда программистом так как дорабатывал/перепрабатывал типовые решения а потом попал в компанию где работают программисты. Отсюда и хорошие впечателния от Java.
У 1С три ключевые проблемы с точки зрения программиста (т.е. человека который с 0 пишет на 1С большие системы)
Динамическая типизация;
Процедурное программирование, проще говоря бэйсик;
Жесткий монолит;
Вообще писать про то что в 1С плохо это не благодарное занятие, все что в 1С плохо - отлично описали сами 1С, по ссылке https://its.1c.ru/db/v8std, если интересно можете сходить почитать:
"Система стандартов и методик разработки конфигураций"
По объему это практически книга правил, которых нужно придерживаться что бы проект не превратился в помойку уже через год. Все эти правила нужно помнить, IDE вам никак не поможет, просто потому что при использовании динамической типизации да еще и в процедурном стиле нет возможности реализовать эти правила, их может соблюдать только человек каждый раз обрабатывая их в голове.
Ну и пару примеров для тех кому лень вникать:
Пример №1 "Область видимости, Программный интерфейс"
https://its.1c.ru/db/v8std#content:455:hdoc
В современных ЯП есть ограничение области видимости, упрощенно что бы IDE вам не давала в подсказке методы которые в принципе не рассчитаны на использование, есть интерфейсы которые скрывают за собой реализацию и.т.п.
В 1С такого нет, и вместо этого нам предлагают в модуле использовать "коментарий":
#Область ПрограммныйИнтерфейс// Код процедур и функций#КонецОбласти"Комментарий" потому что она не влияет на работу кода, это исключительно оформление внутри модуля, что то типа комментария для других программистов, что можно смело вызывать функции описанные в этой секции. Если завтра из этой секции при обновлении какие то методы будут вынесены иизменены вы об этом узнаете в рантайме.
Конечно трогать такие методы "строго запрещено" методикой, но компилятор и IDE это никак не проверяет. Ну и конечно экспортные процедуры описанные вне этой области все также доступны для вызова откуда угодно и кем угодно, просто под личную ответственность того кто их использует.
Пример №2 "Описание экспортных (интерфейсных) процедур и фцнкций"
Отдельное искуство в 1С это требования к комментариям:
https://its.1c.ru/db/v8std#content:453:hdoc
Так как у нас дин. типизация, а в больших проектах все же желательно описывать параметры функций, вендор нам предлагает описать эти параметры СЛОВАМИ что бы другие программисты (не IDE !!!) смогли это прочитать, запомнить и у себя в голове потом все это развернуть. Причем там важно еще и отступы соблюдать и офоромление, и потом естественно это все поддерживать в ручном режиме при изменении кода.
Естественно это вообще никак не свзяано с кодом и не как не автоматизировано.
Тут можно возразить, что при статической типизации и ООП придется все равно все это описывать и даже намного больше. Вот только разница в том что все что ты описал это твой фундамент, ты один раз описал и облегчил работу себе и тем кто придет после тебя, ты установил правила, соблюдение которых будет проверять за тебя IDE и любое отступление от них вызовет предупреждение.
При всех плюсах платформы, писать монолитные корпоративные а иногда и государственные ИС на бейсике это задача для очень умных и сильных духом людей, которая не каждому по плечу. Это как по мне все что нужно знать новичку про 1С.
Тем кто далек от 1С и кодит на Java все это вообще не особо интересно, разве что из серии не смог осилить C#, пойду в 1С...
Обе вроде интересны но техническая реализация ужасна настолько что даже хороший игровой процесс не удержал меня в игре. При этом тоже вспоминал старые игры и fallout 1.
Согласен с @yukon39
Делаем RO асинхронную реплику (вам же не нужно прям в realtime получать данные, 100-1000 мс задержки вполне норм, при этом не нагружаем прод. базу ожиданиями фиксации транзакций в RO реплике).
В реплике на основании информации о соответствии полей таблиц и объектов метаданных в той же базе генерируем View с названиями таблиц и полей соответствующими именам метаданных.
В итоге имеем отдельный сервер где можно крутить разные аналитики и SQL интеграции не нагружая основной сервер. При этом запросы пишутся почти как в 1С Конечно итоги и срезы последних нужно самим подключать, и какой то навык нужно иметь, лучше конечно первый раз писать в консоли и потом транслировать в SQL и затем уже писать через View что бы меньше ошибок. Основные плюсы потом в сопровождении, проще читать, проще менять запросы и.т.п.
Статья не бесполезная, многие кто занимается переходом с УПП в ERP сталкиваются с решением подобной задачи, но без ссылок на инструменты и расширения, практического смысла не много.
Есть вопрос по разделам:
"4. Автоматизация заполнения объектов"
"5. Гибкие права доступа к объектам"
Как они относятся к теме статьи? Не все получилось сделать ролями и часть делали с помощью "5. Гибкие права доступа к объектам" ? В УПП был аналогичный функционал?
Плюс не понятно как при маппинге пользователей УПП на типовые профили решалась проблема с тем что в типовом профиле есть лишние права.
Т.е. понятна ситуация когда есть типовой профиль и к нему нужно добавить дополнительные права, делаем опциональный профиль и таким образом получаем требуемую функциональность. Но если в типовом профиле есть лишние права то такой вариант не сработает.
Неужели у вас не было таких вариантов?
Вот тоже посмотрел тесты, хотел написать то же самое. Xeon 2673v3 (12 ядер, 3.3 ГГц) за 6500 рублей + Atermiter 4000р + 32 RAM (4 плашки по 8 гб 2133) за 6500.
Итого 17000р, дают практически тот же результат по задержке: 71,2, и незначительно меньше по скорости: 62850.
При этом с DDR5 только модули памяти стоят 30 000р, что на 460% дороже а быстрее на 30%.
И не особо понятно почему в потребительских сегментах не делать 4 канала. Понятно что больше дорожек и выводов нужно делать, и немного больше кристал процессора получится, но не руками же это делают, а "роботу" не так и принципиально сколько дорожек разводить. Не так дорого это выходит.
Доходит до смешного, нам предлагают 12 ядерные i7 с 25 мб кэша и двумя двумя контроллерами памяти. Даже если есть задачи которые способны нагрузить 12 ядер, то как их прокормить?
Вот Apple молодцы сделелали 4 канала DDR4 (там 2 но 128 битных что как раз равно 4м 64 битных в Intel/AMD) и у них на выходе M1 Pro дает 200 ГБ/с, а M1 Max - 400 ГБ/с.
Что такое 85 ГБ/с на топовой DDR5 памяти в разгоне против даже 200 ГБ/с у M1 Pro и уж темболее 400 ГБ/с у M1 Max?
Да и 30Мб кэша на 8 ядер выглядит куда лучше.
Почему вручную? У Ланита есть API для этого.
На мой взгляд ГИС ЖКХ обычная система консолидирующая данные не плохая и не хорошая. А 60% проблем свзяано с требованиями по подписи и шифрованию протоколов если почитать чат разработчиков интеграций, то там основные проблемы с сертификатами, и с тем что временами сервис не работает.
Плюс на мой взгляд очень сильно намудрили с квитированием, бесполезная по сути операция (для абонента) и очень сложная для РСО и УК.
Остальные 30% проблем связаны с тем что у многих РСО и УК просто нет ИТ специалистов что бы решать проблемы работы с ГИС ЖКХ, все идет через несколько посредников, или вообще EXCEL отсюда и проблемы с непрогруженными показаниями.
Хотели бы навести порядок, сделали бы единный билинг для ФЛ на всю страну. Если откинуть различные извращения, стандартизировать и упростить правила расчет то система будет достаточно простая. И многие РСО с удовольствием бы платили за использование такой системы в облаке.
Это хороший вопрос. Такой же как про лес и нефть.
Это вопросы к нашим (нашим?) людям из правительства. У меня на такие вопросы ответов нет
Да, признаю со свалкой погорячился, скажем так у меня есть внутреннее убеждение что 28 нм могут продать, а вот 12 нм просто прийти и купить не получится. Даже за большие деньги.
На мой взгляд доверять нельзя никому и особенно нельзя доверять себе, потому что как показывает мой опыт нет врага страшнее чем ты сам.
Закладкой может воспользоваться тот кто её заложил, это плохо но тем не менее гораздо хуже если в процессоре / архитектуре есть уязвимости которые может найти кто угодно. И такие ошибки и уязвимости есть всегда как и в любой программе, хорошие программы отличаются от плохих в первую очередь степенью тестирования и привлеченных ресурсов. А полноценное тестирование / исследование может потребовать ресурсов больше чем разработка. Это такая же школа как и разработка процессоров.
И по факту имеем пониженную вероятность закладок в процессор (на фабрике) и повышенную вероятность наличия уязвимостей (т.к. просто нет ресурсов на полное тестирование).
На мой взгляд это нужно в первую очередь для развития. Можно вспомнить китайский MediaTek они начинали без амбиции на мировое господство с MT6218B в 2003, а сейчас выпускают Dimensity 1200 который по соотношению цена/железо рвет флагманский qualcomm, но по софту конечно отстает т.к. за плечами qualcomm стоит google а вот MediaTek справляется своими силами. Но на потребительском уровне это отставание не заметно вообще а вот по цене выгода заметна.
Ребята из MediaTek сделали правильную ставку на ARM и из откровенно ужасных MT6218B которые стояли во всех телефонах NOKLA (с ТВ и антенной) догнали лидеров (qualcomm) и обогнали конкурентов (Exynos). Еще год два и увидим первые сервера на ARM и у MediaTek уже есть все необходимые компетенции для того что бы предложить свои продукты.
Вот только какое развитие у vliw мне не понятно, intel вложились в него, но потом отказались, где кроме DSP он сейчас используется я и не знаю.
Я вообще не уверен что кто угодно может в ASML прийти и купить такой станок даже если у него будут деньги. Слишком ценный это ресурс что бы его за деньги продавать.
Это для нас деньги это мерило всего, но есть предел после которого деньги уже совсем по другому ценятся, и владельцы ASML уже давно далеко ушли от этого предела.
Как не пиши код но DDR3-1600 с 4х канальным контроллером так и останется DDR3-1600 с 4 каналами.
Да можно потратить ресурсы и оптимизировать узкие места, но точно так же можно потратить те же ресурсы на оптимизацию под x86 и получить такой же а то и больший прирост.
Но есть опасения что остальной мир не бросится переписывать библиотеки и JVM под vliw архитектуру, а доля кода тех же разработчиков сбера в общем коде решения не больше 10%.
Мой опыт и здравый смысл говорит о том что подсистема памяти и интерфейсы доступа к данным на внешних накопителях (кстати что у эльбруса, явно же не SATA3?) катастрофически влияют на скорость работы при реальной рабочей нагрузке на сервер. И даже в CPU с DDR4-2400 и 6ю каналами на серверах всё упирается в память, и особенно в случае с JAVA. И всё что можно делать со стороны программиста это как то работать с кэшем (что делать из Java не так то просто).
А в случае с СУБД еще интерфейсы доступа к внешним хранилищам. (сами хранилища выносим за скобки).
Поэтому даже при идеальном раскладе DDR3-1600 c 4 каналами памяти будет на 50% хуже чем DDR4 - 3000 c 6 каналами. И еще учитывая что везде скромно умалчивается о успехах в реализации межъядерного и межпроцессорного взаимодействия, можно предположить что в Эльбрусе это так же реализовано похуже чем на современных x86 и серверных чипсетах.
Тема тестирования серверных процессоров очень скользкая, так как работа сервера полностью отличается от работы игрового или рабочего ПК и в реальной работе на первый план выходят такие характеристики как Частота системной шины, Кол-во соединений QPI, размер и организация доступа к кэш памяти и.т.п. Это для десктопа где сидит один юзер и работает 5 программ кэш в 30 мб решает 90% доступа к памяти.
А вот сервер который обрабатывает 10 000 запросов в секунду свои 30 Мб выедает очень быстро, и дальше какой бы мощный процессор не был все его ядра стоят и ждут данных из памяти (показывая загрузку в 100% но ничего не делая). Не зря в последних моделях процессоров интел уже идет практически отдельный микроконтроллер который занимается анализом и предсказанием, частично конечно что бы загрузить ядра работой, но главная задача это упреждающее чтение в кэш.
Конечно у эльбруса с его 1.3 ггц не такой большой голод данных, но опять же там и инструкции по жирнее. Конечно было бы круто если бы сбер опубликовал результаты своих тестов.
Сделать процессор сложно, сделать серверный процессор сложно в квадрате, плюс серверный процессор существует не в вакууме ему ещё нужна соответствующая обвязка от которой так же много зависит (особенно в многопроцессорных системах).
Я в новостях часто читаю что наш процессор поможет нам обезопасить страну, от закладок в процессоре, от санкций и.т.п.
Но на мой взгляд:
1. Если дойдет до запрета продажи нам процессоров то наверное запретят продавать и материнские платы и жесткие диски и заказы на изготовление тоже размещать не дадут. Как то слабо вериться в сценарий когда запретят только процессоры.
2. Закладки (в процессорах) это конечно хорошо, но как показала практика meltdown и spectre и без закладок возможно получать доступ к памяти ядра системы. И на мой взгляд ещё не известно что хуже закладки которыми могут пользоваться только те кто их заложил, или подобные уязвимости доступные гораздо более широкому кругу лиц. И если уж Intel с их многолетним опытом допускают такие ошибки то какова вероятность наличия таких ошибок в новых архитектурах?
Вообще интересно было бы почитать мнение экспертов об устойчивости архитектуры эльбрусов к подобным проблемам и вообще к уязвимостям.
На уровне моего понимания того как устроены процессоры использование длинных слов открывает больше векторов для атаки, но это скорее догадки чем предположение.
Если честно жаль что наш ЦП не на арм, у меня есть стойкое впечатление что мы сейчас на пороге (а может уже и дальше) революции и переходе всего мира ИТ на ARM, и тут можно было бы выстрелить, а пока всё что я понял и прочитал про архитектуру Эльбруса больше похоже на выстрел в ногу.
Теория заговора
Если погрузиться в теорию заговора, то можно предположить, что специалисты по ARM нужны всему миру, и что если делать ставку на ARM придется конкурировать со всем миром за специалистов, а если специалист заточен на vliw то вероятность что его куда сманят значительно уменьшается. Что то похожее у нас с 1С, ты можешь быть крутым спецом по 1С но за пределами 1С ты не интересен.