Я в новостях часто читаю что наш процессор поможет нам обезопасить страну, от закладок в процессоре, от санкций и.т.п.
Но на мой взгляд:
1. Если дойдет до запрета продажи нам процессоров то наверное запретят продавать и материнские платы и жесткие диски и заказы на изготовление тоже размещать не дадут. Как то слабо вериться в сценарий когда запретят только процессоры.
2. Закладки (в процессорах) это конечно хорошо, но как показала практика meltdown и spectre и без закладок возможно получать доступ к памяти ядра системы. И на мой взгляд ещё не известно что хуже закладки которыми могут пользоваться только те кто их заложил, или подобные уязвимости доступные гораздо более широкому кругу лиц. И если уж Intel с их многолетним опытом допускают такие ошибки то какова вероятность наличия таких ошибок в новых архитектурах?
Вообще интересно было бы почитать мнение экспертов об устойчивости архитектуры эльбрусов к подобным проблемам и вообще к уязвимостям. На уровне моего понимания того как устроены процессоры использование длинных слов открывает больше векторов для атаки, но это скорее догадки чем предположение.
Если честно жаль что наш ЦП не на арм, у меня есть стойкое впечатление что мы сейчас на пороге (а может уже и дальше) революции и переходе всего мира ИТ на ARM, и тут можно было бы выстрелить, а пока всё что я понял и прочитал про архитектуру Эльбруса больше похоже на выстрел в ногу.
Теория заговора
Если погрузиться в теорию заговора, то можно предположить, что специалисты по ARM нужны всему миру, и что если делать ставку на ARM придется конкурировать со всем миром за специалистов, а если специалист заточен на vliw то вероятность что его куда сманят значительно уменьшается. Что то похожее у нас с 1С, ты можешь быть крутым спецом по 1С но за пределами 1С ты не интересен.
Зачем Китаю продавать нам оборудование и знание, если можно значительно дороже продавать нам микросхемы. Я конечно не эксперт в глобальной экономике, но на мой обывательский взгляд, в таких масштабах деньги это просто бумага, а в наше время уже давно не бумага.
Какая выгода китаю от появления конкурентов на рынке?
Вопрос ещё кто нам продаст эти технологии. На мой взгляд не очень умно продавать станки по производству денег из песка. Да наверное 28нм ещё можно продать, не выкидывать же на свалку. Но более современные... сильно сомневаюсь.
И дело даже не в санкциях, просто в чём смысл плодить конкурентов?
Все так и есть, 1С это действительно доступно и всерьез.
Единственное в чем я с вами не согласен так это в масштабе до 1000 человек. Проблем не будет с типовыми решениям до 200-300 пользователей.
Дальше уже начинаются сложности, нужны эксперты которые за этим будут следить. Но даже для 300 человек сложно найти не допиленную типовую, и вот дальше у платформы появляются проблемы:
Запредельная сложность крупных конфигураций (Отсутствия ООП, Типизации, Какой либо структуры хранения модулей)
Сложность прикладной части (это отдельная боль).
Отвратительная производительность платформы (тут ниже есть мой пример сравнения с java)
Игнорирование прогресса в разработке СУБД начиная с 92 года. (Газпром вынужден тратить миллиард на сервера СУБД под 1С потому что у 1С есть файловый вариант для ларька который дережит Арсен, и все возможности платформы по работе с СУБД ограниченны этим вариантом).
Жесткий монолит (тут без коментариев, достаточно посмотреть как реализована бесшовная интеграция с документооборотом, я когда смотрю всегда восхищаюсь тем сколько сил и труда было вложено в то что в WEB разработке идет бесплатно).
Сжатые сроки + бизнес на первом месте, а отдел автоматизации где то между завхозом и гаражом, прибыли не приносит, сидят там одни дармоеды и вот это все...)
Причем эти пункты нужно не складывать а перемножать. И
Возьмите любой ORM или тем более современный JS framework там 30% разработчиков не то что не задумываются о том как это реализовано а даже не понимают что там вообще что то под капотом), особенно это касается Frontend.
На самом деле то что 1С позволяет такое писать не проблема 1С, любая ORM с ленивым чтением будет делать то же самое.
Писать так или нет тоже зависит от задачи, ну и для справедливости прям так никто не пишет, это большая редкость. Чаще просто получают через 1-2 точки и это нормально если ты дальше что то делаешь с этим объектом и если у тебя не HiLoad блок а что то что выполняется раз в месяц.
И чаще всего в разыменовываемых объектах не лежат огромные хранилища значений.
При этом СУБД нет особой разницы прочитать один реквизит или прочитать всю строку. Поэтому я бы не стал в большинстве случаев на это обращать внимание.
Они не нужны там где ты можешь выделить отдельные классы с методами, разместить их в соответствующих каталогах и.т.п. В 1С когда у тебя в одном модуле размещены 95 процедур и 129 функций при этом все они так или иначе вызывают процедуры и функции из других модулей с таким же названием но с другой инструкцией (ПовтИсп, ВызовСервера и.т.п.) комментарии с описанием что это, какие у него параметры жизненно необходимы.
Такое есть везде. Проблема говнокода в 1С встречается чаще из за более низкого порога и сжатых сроков т.к. 80% разработки 1С это разработка по часам. Это примерно как ожидать от продажной женщины за 1500р в час такого же отношения и внимания как от жены.
Но на самом деле проблема такого говнокода это все же проблема того кто пишет и команды (правда в 1С опять же 70% работает без команды). Но никак не платформы и не языка.
Это не java как минимум потому что нет ООП что делает поддержку крупных проектов практически не возможной, и местами героической.
Вторым важным отличием является отсутствие типизации, компилятор вам редко когда что то может подсказать или как то иначе помочь. Надежда только на себя и свою память.
Представьте java без ООП (У вас есть только процедуры и функции) в котором перемешаны SQL запросы, всё это в 350 модулях в одном каталоге (иерархия хранения модулей не поддерживается) каждый модуль от 1000 до 20 000 строк (иначе модулей было бы не 350), эти модули сильно между собой зависимы и по факту просто содержат процедуры и функции, нет интерфейсов, контрактов, каких либо других описаний, ты просто должен всё это помнить сам.
Есть пара стандартов на бумаге где и что размещать но всё это абсолютно не поддерживается средой разработки и языком, иногда складывается впечатление что платформу разрабатывает не крупнейшая в РФ корпорация а просто open source сообщество.
С другой стороны понятно что бейсик (а по факту 1С это и есть бейсик только с фреймворком в виде платформы) не предназначен для всего того куда сейчас платформу продвигают.
1С отличная система с низким порогом входа пока у вас небольшая конфигурация (что редко) или пока вы правите какие то редкие куски большой конфигурации или делаете отчеты/обработки (чем занимается 90% франчей).
В Java перебравшись через порог новичок идет по ступенькам с перилами (ООП, IDE, Code Review, Патерны, Тесты). В 1С за порогом тебя ждет плато на горизонте которого находится отвесная стена, по которой нужно карабкаться дальше.
На мой взгляд людям которые создали ERP, БСП 3.0 при жизни нужно памятник ставить, настолько титанический труд. Страшно подумать каких бы высот они достигли имея дело с современными промышленными языками.
По факту всё что во всем мире является плохим стилем, в 1С норма по определению. Да у 1С есть стандарты разработки, но они на "бумаге" а не в IDE и следовать им это значит ещё сильнее нагрузить свой мозг борьбой с 1С а не решением проблем.
Да и быстродействие 1С это грусть печаль, если JVM оптимизируют всем миром, то виртуальная машина 1С написана в соответствии с первым постулатом "Главное, чтобы работало".
Для примера: Массив из 33 000 000 машинных номеров.
1С:
Формирование массива: 901 156 мс (Цикл + генератор случайных чисел+массив.Добавить(Значение)).
Поиск в массиве не существующего элемента средствами платформы: 19164мс. (Массив.Найти(Значение))
Занимает 2.7 гб RAM.
Java (такой же код на той же системе):
Формирование массива: 52651.3931 мс
Поиск в массиве не существующего элемента : 190.6821 мс (arr.contains(Value))
В памяти точно не помню, по моему около 300 мб.
Вообще там такой багаж проблем (стоимость и вообще необходимость лицензий, ORM ограниченная только урезанным Select которая мощнейшие СУБД с их возможностями использует как замену DBF файлов).
Отдельная боль это гигантомания и монолитизация всего, базы по 2-3 TB на крупных проектах это норма. Когда спрашиваешь у разработчиков PG совета как бы заставить этого монстра работать, в ответ всегда получаешь:
- "Зачем вам такая база?" Разбейте на 10-20 поменьше, выделите сервисы, какие то данные перекиньте в архив и.т.п).
После упоминания что это 1С обычно разговор заканчивается, потому что говорить тут просто не о чем.
Альтернативы нет, так как в крупном ent нет 1С, в лучшем случае прикладные решения (бух,зуп) делать им конкурентов долго, дорого а выхлоп только за счет массовости, а это своя сеть продаж и.т.п. Плюс с локом на РФ. Кому это счастье нужно?
Посмотрите на современный мир, не кто не хочет продавать коробку, все продают сервисы, в для этого 1С не подходит в принципе. Да фреш прикрутили но это для малых ИП и в целом костыль (так как монолит).
Если речь о платформе на которой можно быстро выдать продукт, так есть масса фреймворков, может чуть сложнее порог входа, но это и к лучшему, плюс за счет ООП фреймворки на порядок гибче.
В общем если коротко то рынок который заняла 1С не интересен т.к. уже устарел там нет перспектив, поэтому и желающих нет.
В том и смысл что frontend не должен знать SQL, но должен в совершенстве знать свою часть, так же и backed и DBA и архитекторы и дизайнеры, каждый занимается своей работой.
И только в 1С ты должен и интерфейсы проектировать и предметную область знать, и в SQL разбираться + чемодан сюрпризов самой платформы + управляемые блокировки.
А ЗП у тебя будет по низу ИТ рынка.
2) 1C как бэкенд — прекрасно заходит infostart.ru/1c/articles/1237578. Боитесь проблем с масштабированием — есть OneScript
Как OneScript помогает решать проблемы с лицензиями и главное извращенной архитектурой БД?
4) Научитесь делать нормальные интерфейсы в т.ч. в 1С решениях event.infostart.ru/2021/agenda/#item1291409
Что бы делать хотя бы часть из описанного в agenda нужно быть не слабым JS разработчиком. Я как то просил знакомого фулстек помочь вытянуть мне данные из WEB клиента (нужно было интегрироваться имея доступ только к WEB клиенту). Он провозился несколько дней что то смог сделать что то нет, и говорил о WEB интерфейсе 1С примерно теми же словами что другой знакомый DBA использует когда говорит о том как 1С с СУБД работает.
5) Освойте уже proxy и injection — меняйте 1С-ные CSS на свой лад github.com/ovcharenko-di/crserver-filter
Может быть освоить просто JS + React (vue) и делать сразу нормальные MVC интерфейсы?
6) Пройдите всю цепочку Дизайн — прототип — user-flow — вёрстка — Бэк — фронт — адаптив — mobile для того чтобы понять как много для вас делает движок 1С.
Все выше перечисленное делается разными людьми. Это разработчики 1С делают все выше описанное за 6х человек, а ЗП получают как 70% от одного из этих 6.
А потом хвалятся какая 1С дешёвая и популярная, конечно дешёвая, за счет вашей ЗП и нагрузки, дешевая.
И нужно определиться у нас тут low code или js + css + one script + faas.
Приложения, возможно.
Но в современном мире нужны не приложения а системы, и продают всё чаще не коробки а сервисы.
Писать что то крупное на 1С больно, даже ели опустить убогость языка и возможности по организации кодовой базы.
1С использует промышленные СУБД стоимостью под 2 млн рублей как замену DBF файлам, используя примерно 15% от доступного функционала СУБД.
Для малого и местами среднего бизнеса возможно и удобно что можно перейти с MS на PG.
Но кто в здравом уме выберет 1С для автоматизации ДБО юр. лиц например в том же банке хотя бы с 100 000 клиентов? И сколько таким смелым парням придется преодолевать трудностей, не имея возможности даже сделать необходимые индексы, да что там индексы, секционирование, сжатие, репликация, разделение данных на холодные и горячие, возможность выполнения update, merge.
Эксперты 1С решают проблемы от которых у матёрых DBA волосы дыбом во всех местах, они просто не понимают как в принципе можно «ТАК» использовать СУБД.
Да, в 2008-2012 годах WEB разработчик (jun back) и 1С Программист(Mid) получали сравнительно одинаково в $ для своей квалификации. По МСК примерно 2000$, что около 70к по курсу 34р.
И сейчас WEB разработчик (mid / back) в РФ в массе может рассчитывать где то на 2000-2500$ не в самой престижной конторе.
А вот 1С нику получать 200 это нужно быть архитектором + сеньором + ПМ + DBA в одном лице что бы 2500$ получать, и то еще место нужно найти и требования там будут именно такие, в стиле мы тебе 200к платим, ты вообще всё должен уметь, а вечером ещё за сторожа подрабатывать, даже близко не сравнимые с mid в web.
Насчет клиентов для 1С, клиенты есть и их много, причем крупные холдинги и корпорации, потому что платить командам не 1С раз в 10 дороже, чем 1С. Там и сами команды значительно больше и специалисты значительно дороже, плюс сроки проектов длиннее.
Вот только плюсы 1С (низкий порог входа, быстрая разработка на бейсике) на больших проектах превращаются в минусы (низкая культура разработки, примитивный язык и подходы к разработке из 2000х делают код не управляемым) в итоге получается так что на крупном проекте 1С работать сложнее чем на крупном с JAVA при этом большинство серьезных специалистов с 1С не связываются и очень много случайных людей которые пришли в разработку через низкий порог.
Я могу сравнить со строительной фирмой, когда есть бригада из таджикистана, и они строят модульные многоэтажки, работа тяжелая, но есть сданные объекты, качество так себе, но в принципе это же бетон, он всё стерпит. Сдали акты подписали, где то что то по гарантии подчинили если отвалилось.
А потом эту успешную бригаду зовут строить небоскреб на 120 этажей.
Тут то где то на 50м этаже и выясняется что бетон то стерпит, но есть определенные правила его заливки, мат. обеспечение расчета фундамента, и что работяги из Таджикистана ребята хорошие, трудолюбивые, опытные, но для строительства небоскреба нужны ребята со строительным образованием умеющие владеть современными инструментами и практиками.
Да и архитектор в этой бригаде конечно не глупый и опытный и даже когда то в институте учился, даже ездил на семинары и там им рассказывали про новые технологии, но в проектировании и постройке модульных однотипных 9 этажек эти технологии излишне и увеличивают стоимость.
Да, для ФИАС есть DBF, но с 2021 налоговая переходит на ГАР, он к сожалению только XML и XML там огромные.
У меня есть решение на MS SQL у него есть компонент SQLXMLBulkLoad, для него достаточно указать особым образом аннотированную XSD схему и XML файл.
Дальше он сам создает таблицы и загружает данные из XML.
В MySql тоже есть подобный функционал.
Но к сожалению обе эти СУБД не включены в реестр отечественного ПО, и единственный вариант для меня это PG SQL. Беглый поиск в интернете показал что ничего подобного для PG нет, всё упирается в загрузку XML целиком и дальше с ним работать, что для ГАР не удобно т.к. много связей между таблицами, плюс нет уверенности что PG нормально загрузит XML на 5-6 ГБ, а всего там 30 гб XML в арихиве и 90 при распаковке.
MS SQL первую загрузку всего ГАР выполняет за 4,5 часа и это меня устраивает.
Ещё сложность в том что нужно не самому это сделать один раз, а сделать инструмент для пользователей которые будут скачивать классификатор (или дельты) и уже сами загружать данные.
Итоговая задержка сильно зависит от воспроизводящего устройства, его чипсета и буфера. Во время тестов я получил разброс от 150 до 250 мс на разных устройствах (с кодеком SBC). Если предположить, что устройства с поддержкой дополнительных кодеков aptX, AAC и LDAC используют качественные компоненты и маленький размер буфера, то получим следующие типичные задержки:
Напоминаю: aptX Low Latency не поддерживается в операционных системах, из-за чего меньшую задержку можно получить только связкой трансмиттер+ресивер или трансмиттер+наушники/колонка, причём все устройства должны поддерживать этот кодек.
В итоге использование BT наушников с ПК это достаточно узкая ниша. Плюс еще будут проблемы с voip, т.к. все наушники при общении по skype переключаются в HSP (HFP) что очень сильно убивает звук.
Собственно для чего я пишу.
У кого то после прочтения статьи может сложиться впечатление что BT наушники можно использовать для ПК (работа/игры) т.к. минусы совсем не раскрыты. Хочу предупредить что это плохая идея.
Качество APTX значительно преувеличено силами маркетологов, если интересно почитайте: habr.com/ru/post/455316, и другие статьи автора.
Но качество это дело во многом субъективное и можно привыкнуть.
Реальная проблема BT это задержка, она есть и на APTX и SBC, и если для музыки/видео мы её не замечаем т.к. ОС/Плееры умеют сдвигать звук относительно видео.
Но в играх на любых BT наушниках будут огромные для игр задержки которые слышат все, и даже APTX LL ситуацию не исправляет, но с APTX LL уже не так много людей могут услышать задержку.
Я в новостях часто читаю что наш процессор поможет нам обезопасить страну, от закладок в процессоре, от санкций и.т.п.
Но на мой взгляд:
1. Если дойдет до запрета продажи нам процессоров то наверное запретят продавать и материнские платы и жесткие диски и заказы на изготовление тоже размещать не дадут. Как то слабо вериться в сценарий когда запретят только процессоры.
2. Закладки (в процессорах) это конечно хорошо, но как показала практика meltdown и spectre и без закладок возможно получать доступ к памяти ядра системы. И на мой взгляд ещё не известно что хуже закладки которыми могут пользоваться только те кто их заложил, или подобные уязвимости доступные гораздо более широкому кругу лиц. И если уж Intel с их многолетним опытом допускают такие ошибки то какова вероятность наличия таких ошибок в новых архитектурах?
Вообще интересно было бы почитать мнение экспертов об устойчивости архитектуры эльбрусов к подобным проблемам и вообще к уязвимостям.
На уровне моего понимания того как устроены процессоры использование длинных слов открывает больше векторов для атаки, но это скорее догадки чем предположение.
Если честно жаль что наш ЦП не на арм, у меня есть стойкое впечатление что мы сейчас на пороге (а может уже и дальше) революции и переходе всего мира ИТ на ARM, и тут можно было бы выстрелить, а пока всё что я понял и прочитал про архитектуру Эльбруса больше похоже на выстрел в ногу.
Теория заговора
Если погрузиться в теорию заговора, то можно предположить, что специалисты по ARM нужны всему миру, и что если делать ставку на ARM придется конкурировать со всем миром за специалистов, а если специалист заточен на vliw то вероятность что его куда сманят значительно уменьшается. Что то похожее у нас с 1С, ты можешь быть крутым спецом по 1С но за пределами 1С ты не интересен.
Зачем Китаю продавать нам оборудование и знание, если можно значительно дороже продавать нам микросхемы. Я конечно не эксперт в глобальной экономике, но на мой обывательский взгляд, в таких масштабах деньги это просто бумага, а в наше время уже давно не бумага.
Какая выгода китаю от появления конкурентов на рынке?
Вопрос ещё кто нам продаст эти технологии. На мой взгляд не очень умно продавать станки по производству денег из песка. Да наверное 28нм ещё можно продать, не выкидывать же на свалку. Но более современные... сильно сомневаюсь.
И дело даже не в санкциях, просто в чём смысл плодить конкурентов?
Все так и есть, 1С это действительно доступно и всерьез.
Единственное в чем я с вами не согласен так это в масштабе до 1000 человек. Проблем не будет с типовыми решениям до 200-300 пользователей.
Дальше уже начинаются сложности, нужны эксперты которые за этим будут следить. Но даже для 300 человек сложно найти не допиленную типовую, и вот дальше у платформы появляются проблемы:
Неквалифицированные кадры (низкий порог входа, низкие ЗП)
Запредельная сложность крупных конфигураций (Отсутствия ООП, Типизации, Какой либо структуры хранения модулей)
Сложность прикладной части (это отдельная боль).
Отвратительная производительность платформы (тут ниже есть мой пример сравнения с java)
Игнорирование прогресса в разработке СУБД начиная с 92 года. (Газпром вынужден тратить миллиард на сервера СУБД под 1С потому что у 1С есть файловый вариант для ларька который дережит Арсен, и все возможности платформы по работе с СУБД ограниченны этим вариантом).
Жесткий монолит (тут без коментариев, достаточно посмотреть как реализована бесшовная интеграция с документооборотом, я когда смотрю всегда восхищаюсь тем сколько сил и труда было вложено в то что в WEB разработке идет бесплатно).
Сжатые сроки + бизнес на первом месте, а отдел автоматизации где то между завхозом и гаражом, прибыли не приносит, сидят там одни дармоеды и вот это все...)
Причем эти пункты нужно не складывать а перемножать. И
Возьмите любой ORM или тем более современный JS framework там 30% разработчиков не то что не задумываются о том как это реализовано а даже не понимают что там вообще что то под капотом), особенно это касается Frontend.
На самом деле то что 1С позволяет такое писать не проблема 1С, любая ORM с ленивым чтением будет делать то же самое.
Писать так или нет тоже зависит от задачи, ну и для справедливости прям так никто не пишет, это большая редкость. Чаще просто получают через 1-2 точки и это нормально если ты дальше что то делаешь с этим объектом и если у тебя не HiLoad блок а что то что выполняется раз в месяц.
И чаще всего в разыменовываемых объектах не лежат огромные хранилища значений.
При этом СУБД нет особой разницы прочитать один реквизит или прочитать всю строку. Поэтому я бы не стал в большинстве случаев на это обращать внимание.
Нужно просто понимать что ты и для чего делаешь.
Они не нужны там где ты можешь выделить отдельные классы с методами, разместить их в соответствующих каталогах и.т.п. В 1С когда у тебя в одном модуле размещены 95 процедур и 129 функций при этом все они так или иначе вызывают процедуры и функции из других модулей с таким же названием но с другой инструкцией (ПовтИсп, ВызовСервера и.т.п.) комментарии с описанием что это, какие у него параметры жизненно необходимы.
Такое есть везде. Проблема говнокода в 1С встречается чаще из за более низкого порога и сжатых сроков т.к. 80% разработки 1С это разработка по часам. Это примерно как ожидать от продажной женщины за 1500р в час такого же отношения и внимания как от жены.
Но на самом деле проблема такого говнокода это все же проблема того кто пишет и команды (правда в 1С опять же 70% работает без команды). Но никак не платформы и не языка.
Это не java как минимум потому что нет ООП что делает поддержку крупных проектов практически не возможной, и местами героической.
Вторым важным отличием является отсутствие типизации, компилятор вам редко когда что то может подсказать или как то иначе помочь. Надежда только на себя и свою память.
Представьте java без ООП (У вас есть только процедуры и функции) в котором перемешаны SQL запросы, всё это в 350 модулях в одном каталоге (иерархия хранения модулей не поддерживается) каждый модуль от 1000 до 20 000 строк (иначе модулей было бы не 350), эти модули сильно между собой зависимы и по факту просто содержат процедуры и функции, нет интерфейсов, контрактов, каких либо других описаний, ты просто должен всё это помнить сам.
Есть пара стандартов на бумаге где и что размещать но всё это абсолютно не поддерживается средой разработки и языком, иногда складывается впечатление что платформу разрабатывает не крупнейшая в РФ корпорация а просто open source сообщество.
С другой стороны понятно что бейсик (а по факту 1С это и есть бейсик только с фреймворком в виде платформы) не предназначен для всего того куда сейчас платформу продвигают.
1С отличная система с низким порогом входа пока у вас небольшая конфигурация (что редко) или пока вы правите какие то редкие куски большой конфигурации или делаете отчеты/обработки (чем занимается 90% франчей).
В Java перебравшись через порог новичок идет по ступенькам с перилами (ООП, IDE, Code Review, Патерны, Тесты). В 1С за порогом тебя ждет плато на горизонте которого находится отвесная стена, по которой нужно карабкаться дальше.
На мой взгляд людям которые создали ERP, БСП 3.0 при жизни нужно памятник ставить, настолько титанический труд. Страшно подумать каких бы высот они достигли имея дело с современными промышленными языками.
По факту всё что во всем мире является плохим стилем, в 1С норма по определению. Да у 1С есть стандарты разработки, но они на "бумаге" а не в IDE и следовать им это значит ещё сильнее нагрузить свой мозг борьбой с 1С а не решением проблем.
Да и быстродействие 1С это грусть печаль, если JVM оптимизируют всем миром, то виртуальная машина 1С написана в соответствии с первым постулатом "Главное, чтобы работало".
Для примера: Массив из 33 000 000 машинных номеров.
1С:
Формирование массива: 901 156 мс (Цикл + генератор случайных чисел+массив.Добавить(Значение)).
Поиск в массиве не существующего элемента средствами платформы: 19164мс. (Массив.Найти(Значение))
Занимает 2.7 гб RAM.
Java (такой же код на той же системе):
Формирование массива: 52651.3931 мс
Поиск в массиве не существующего элемента : 190.6821 мс (arr.contains(Value))
В памяти точно не помню, по моему около 300 мб.
Вообще там такой багаж проблем (стоимость и вообще необходимость лицензий, ORM ограниченная только урезанным Select которая мощнейшие СУБД с их возможностями использует как замену DBF файлов).
Отдельная боль это гигантомания и монолитизация всего, базы по 2-3 TB на крупных проектах это норма. Когда спрашиваешь у разработчиков PG совета как бы заставить этого монстра работать, в ответ всегда получаешь:
- "Зачем вам такая база?" Разбейте на 10-20 поменьше, выделите сервисы, какие то данные перекиньте в архив и.т.п).
После упоминания что это 1С обычно разговор заканчивается, потому что говорить тут просто не о чем.
Альтернативы нет, так как в крупном ent нет 1С, в лучшем случае прикладные решения (бух,зуп) делать им конкурентов долго, дорого а выхлоп только за счет массовости, а это своя сеть продаж и.т.п. Плюс с локом на РФ. Кому это счастье нужно?
Посмотрите на современный мир, не кто не хочет продавать коробку, все продают сервисы, в для этого 1С не подходит в принципе. Да фреш прикрутили но это для малых ИП и в целом костыль (так как монолит).
Если речь о платформе на которой можно быстро выдать продукт, так есть масса фреймворков, может чуть сложнее порог входа, но это и к лучшему, плюс за счет ООП фреймворки на порядок гибче.
В общем если коротко то рынок который заняла 1С не интересен т.к. уже устарел там нет перспектив, поэтому и желающих нет.
И только в 1С ты должен и интерфейсы проектировать и предметную область знать, и в SQL разбираться + чемодан сюрпризов самой платформы + управляемые блокировки.
А ЗП у тебя будет по низу ИТ рынка.
Кто из разработчиков получает меньше 1С ников?
= small project = small money.
Как OneScript помогает решать проблемы с лицензиями и главное извращенной архитектурой БД?
Что бы делать хотя бы часть из описанного в agenda нужно быть не слабым JS разработчиком. Я как то просил знакомого фулстек помочь вытянуть мне данные из WEB клиента (нужно было интегрироваться имея доступ только к WEB клиенту). Он провозился несколько дней что то смог сделать что то нет, и говорил о WEB интерфейсе 1С примерно теми же словами что другой знакомый DBA использует когда говорит о том как 1С с СУБД работает.
Может быть освоить просто JS + React (vue) и делать сразу нормальные MVC интерфейсы?
Все выше перечисленное делается разными людьми. Это разработчики 1С делают все выше описанное за 6х человек, а ЗП получают как 70% от одного из этих 6.
А потом хвалятся какая 1С дешёвая и популярная, конечно дешёвая, за счет вашей ЗП и нагрузки, дешевая.
И нужно определиться у нас тут low code или js + css + one script + faas.
Но в современном мире нужны не приложения а системы, и продают всё чаще не коробки а сервисы.
Писать что то крупное на 1С больно, даже ели опустить убогость языка и возможности по организации кодовой базы.
1С использует промышленные СУБД стоимостью под 2 млн рублей как замену DBF файлам, используя примерно 15% от доступного функционала СУБД.
Для малого и местами среднего бизнеса возможно и удобно что можно перейти с MS на PG.
Но кто в здравом уме выберет 1С для автоматизации ДБО юр. лиц например в том же банке хотя бы с 100 000 клиентов? И сколько таким смелым парням придется преодолевать трудностей, не имея возможности даже сделать необходимые индексы, да что там индексы, секционирование, сжатие, репликация, разделение данных на холодные и горячие, возможность выполнения update, merge.
Эксперты 1С решают проблемы от которых у матёрых DBA волосы дыбом во всех местах, они просто не понимают как в принципе можно «ТАК» использовать СУБД.
2014 — стоимость Hyndai Solaris 17800$
2021 — стоимость Hyndai Solaris 17500$
И сейчас WEB разработчик (mid / back) в РФ в массе может рассчитывать где то на 2000-2500$ не в самой престижной конторе.
А вот 1С нику получать 200 это нужно быть архитектором + сеньором + ПМ + DBA в одном лице что бы 2500$ получать, и то еще место нужно найти и требования там будут именно такие, в стиле мы тебе 200к платим, ты вообще всё должен уметь, а вечером ещё за сторожа подрабатывать, даже близко не сравнимые с mid в web.
Насчет клиентов для 1С, клиенты есть и их много, причем крупные холдинги и корпорации, потому что платить командам не 1С раз в 10 дороже, чем 1С. Там и сами команды значительно больше и специалисты значительно дороже, плюс сроки проектов длиннее.
Вот только плюсы 1С (низкий порог входа, быстрая разработка на бейсике) на больших проектах превращаются в минусы (низкая культура разработки, примитивный язык и подходы к разработке из 2000х делают код не управляемым) в итоге получается так что на крупном проекте 1С работать сложнее чем на крупном с JAVA при этом большинство серьезных специалистов с 1С не связываются и очень много случайных людей которые пришли в разработку через низкий порог.
Я могу сравнить со строительной фирмой, когда есть бригада из таджикистана, и они строят модульные многоэтажки, работа тяжелая, но есть сданные объекты, качество так себе, но в принципе это же бетон, он всё стерпит. Сдали акты подписали, где то что то по гарантии подчинили если отвалилось.
А потом эту успешную бригаду зовут строить небоскреб на 120 этажей.
Тут то где то на 50м этаже и выясняется что бетон то стерпит, но есть определенные правила его заливки, мат. обеспечение расчета фундамента, и что работяги из Таджикистана ребята хорошие, трудолюбивые, опытные, но для строительства небоскреба нужны ребята со строительным образованием умеющие владеть современными инструментами и практиками.
Да и архитектор в этой бригаде конечно не глупый и опытный и даже когда то в институте учился, даже ездил на семинары и там им рассказывали про новые технологии, но в проектировании и постройке модульных однотипных 9 этажек эти технологии излишне и увеличивают стоимость.
У меня есть решение на MS SQL у него есть компонент SQLXMLBulkLoad, для него достаточно указать особым образом аннотированную XSD схему и XML файл.
Дальше он сам создает таблицы и загружает данные из XML.
В MySql тоже есть подобный функционал.
Но к сожалению обе эти СУБД не включены в реестр отечественного ПО, и единственный вариант для меня это PG SQL. Беглый поиск в интернете показал что ничего подобного для PG нет, всё упирается в загрузку XML целиком и дальше с ним работать, что для ГАР не удобно т.к. много связей между таблицами, плюс нет уверенности что PG нормально загрузит XML на 5-6 ГБ, а всего там 30 гб XML в арихиве и 90 при распаковке.
MS SQL первую загрузку всего ГАР выполняет за 4,5 часа и это меня устраивает.
Ещё сложность в том что нужно не самому это сделать один раз, а сделать инструмент для пользователей которые будут скачивать классификатор (или дельты) и уже сами загружать данные.
Преобразовать гигабайтные XML в CSV оказалось не простой задачей.
Вот цитата из статьи: habr.com/ru/post/427997
И по качеству звука есть объективные тесты, всё это ValdikSS великолепно описал в 2х отличных статьях на хабре: habr.com/ru/post/427997, habr.com/ru/post/427997.
В итоге использование BT наушников с ПК это достаточно узкая ниша. Плюс еще будут проблемы с voip, т.к. все наушники при общении по skype переключаются в HSP (HFP) что очень сильно убивает звук.
Собственно для чего я пишу.
У кого то после прочтения статьи может сложиться впечатление что BT наушники можно использовать для ПК (работа/игры) т.к. минусы совсем не раскрыты. Хочу предупредить что это плохая идея.
Но качество это дело во многом субъективное и можно привыкнуть.
Реальная проблема BT это задержка, она есть и на APTX и SBC, и если для музыки/видео мы её не замечаем т.к. ОС/Плееры умеют сдвигать звук относительно видео.
Но в играх на любых BT наушниках будут огромные для игр задержки которые слышат все, и даже APTX LL ситуацию не исправляет, но с APTX LL уже не так много людей могут услышать задержку.