Комментарии 104
Вспоминаю 1С-ку с нежностью. Гениальная штука, кроме шуток. Фуллстэк-фреймворк, на котором обычный мидл между двумя чашечками чая делает то, на что во "взрослой" веб-разработке будет задача на целый спринт с сабтасками для дизайнеров, бэкендеров и фронтендеров.
1С до сих пор замечательно работает, когда не нужно ничего "сверх":
Сверхпроизводительности, сверхкастомизации, сверхмасштабов, и т.д.
Пока остаёмся в рамках типовых задач, скорость прототипирования и разработки действительно высокая.
Плюс у мелких организаций есть возможность, например, сделать небольшое мобильное приложение - и это сделает тот же самый миддл, дообучившись неделю, не надо нанимать отдельного человека, или переплачивать подрядчику
Крупные конторы сидят на 1С, потому что долго и дорого переписывать кучу легаси. Новые проекты "импортозамещения" стартуют на 1С, потому что практически нет альтернатив, подпадающих под условия "импортозамещения". Так что у 1С в России всё будет хорошо
у них и до импорта замещения было всё хорошо. условия как раз попаданием под отечественное либеральные у нас очень. взял опен сорс, дописал модуль- уже ответсвенное.
Или система с котороя я работал несколько лет- там вся бизнес логика реализована в хранилках на tsql. то есть жесткая привязка к mssql. но в реестре отечесвеного ПО. мы покупали через 223 фз. Аналогичные системы две были на oracle.
А вы попробуйте с этими системами зайти в транснефть или роснефть :)
Подтверждаю. Работал на проекте для одной из дочек Газпрома. Собственно, в общих чертах архитектура была понятна до меня, поскольку специфические требования (геоданные и прочее). Допиливал архитектуру на стеке, под который меня и других людей приглашали: C# и React (поскольку именно под React заточены практически все библиотеки работы с геоданными). Передали заказчику на утверждение список ПО. Получаем ответ: C# американский, React вообще написан Meta, которая в РФ считается экстремистской организацией. Ну и там что-то еще по мелочи.
я работал в одной из дочек газпрома. c# был. . собственно можете посмотреть вакансии разработчиков в компаниях группы.
Предполагаю, что от легаси никуда не деться. Невозможно то, что нарабатывалось десятилетиями взять и переписать на чем-то другом. Кроме того, попробуй это другое найти: куда не копнешь, везде Пентагон свои щупальца сунул, даже в open source, везде, если не террористы, так экстремисты злобные, закладывающие бомбы замедленного действия прям в публичные репозитории.
Ну и, видимо, требования к новым проектам были такие: все импортозаместить и не пущать! К тому же, дочка абсолютно зависимая, по сути прослойка, своего мнения принципиально не имеет, на все возражения отвечала либо шаблонно, либо, в лучшем случае, все отправляла в "голову", ответа от которой можно было ждать неделями по самому ничтожному вопросу. Имя дочки называть не буду, но у них слово "газ" в названии аж два раза, я сам чуть не газанул со смеху, как его услышал.
Короче, чем там все закончилось (или не закончилось), я не знаю. Лично для меня проект на этом этапе завершился.
смотря когда зайти. Я систему о которой говорю внедрял задолго до СВО. Лет 10 назад. Но тренд на импортозамещения для гос организаций уже был. Унитарка была. Не АО с мажоритарием гос-вом. И ПО закупали в т ч и как отечественное. А в Роснефти думайте нет, например SAP ?)) Сейчас понятно- mssql банально не купить легально.
Они давно там есть, часть пришла в довесок с покупкой новых компаний, а часть реализована уже в действующих. Всё есть и "малое" и "большое"
подпадающих под условия "импортозамещения"
Помнится, SAP тогда шикарно людям подгадил. Продал своего овнища на миллиарды и свалил, оставив всех без поддержки, новых форм отчётности и т.д.
Крупные конторы редко сидят на 1с
Одинэсничал с 2005 по 2017. Полностью согласен с автором. Это отличный продукт для своей ниши. Единственное что могу сказать плохого, из практики, - были трудности с масштабированием. Но сейчас, по слухам, это вроде как решено.
насколько понимаю они и шли от малого бизнеса к энтерпрайду. на 1С 7.7 помню были нарекания большие на sql версию. и люди использовали терминалку на которой и работали пользователи- пи их сколько либо существенном количестве. На восьмерке появился сервер приложений (кластер 1С)- уже можно и без терминального сервера использовать. сейчас может ещё что то придумали
1С довольно качественная платформа, но самое важное это большое количество специалистов на любой вкус и размер кошелька
С неприязнью вспоминаю 7-ю 1С-ку. Ради которой приходилось городить костыли с терминал-сервером. Но это моё отношение как админа сети в те времена.
Хотя сами 1С-ники ничего особо плохого про неё не говорили, благо куча однокурсников ушла по тем стопам.
Ну а с выходом 8-ки как понимаю и проблем таких не осталось.
А вот про SAP как раз читал всякое и понял, что ну очень недружелюбная система.
Мой опыт говорит, что 1С 7.7 как платформа была вполне себе ничего. И можно было найти сторонние конфигурации, которые снимали большинство проблем в функционале базовых решений от 1С. Проблемы с терминалами у нас тоже были, но, по моим ощущениям, они были вызваны нашим неумением нормально настроить термальную инфраструктуру и проблемами на каналах связи.
Если говорить прямо, то собирали из экологически чистых отечественных материалов, ломаных Windows, самосборных серверов на базе дешевой комплектухи для офисных ПК. программную часть настраивали по советам похмельных 1С-консультантов и по своему разумению. А физическими каналами были, по выражению наших телефонистов, «гнилые веревки». (Вот как ты думаешь, почему оно в дождь лучше работает? - Веревки-то намокают, гниют и лучше проводят сигнал). *DSL модемы и проблемы с электропитанием на складах добавляли еще перца в этот "локальный технологический суп".
А к моменту перехода на 1С v8* уже накопился опыт, гнилые веревки заменили на оптику и нормальную медь, закупили нормальные терминальные сервера.
1C умеет в многопоточность?
загуглил. в современных версиях -да
ФоновоеЗадание = ФоновыеЗадания.Выполнить("МойМетод", Параметры)
ПулПотоков = Новый ПулПотоков(4); // Создаем пул из 4 потоков ПулПотоков.ДобавитьМетод("МойМодуль.МойМетод");
Хотя мне году ещё в 16 том разработчики конфигурации реализовывали что то типа многопоточности. Может через win 32 api реализовывали
Интересно, почему тогда пишут что 1с любит "горячий" процессор, а не многоядерность? А фоновые задания это часом не порождения отдельного процесса?
Потому что практически нет задач в учете которые можно сделать в несколько потоков. Разве что запустить где-то формирования длительного отчета. А все основные действия обязаны проводиться атомарно.
А распаралелливание в большей части берет на себя сервер БД. Когда разбивает большие запросы на потоки. Клиент в итоге получает единый набор данных который выводится уже в UI потоке, который и так везде, в любых системах, один.
в UI потоке, который и так везде, в любых системах, один
Это не совсем так.
Я не знаю многопоточных UI тулкитов. Может быть имеется ввиду что-то типа SurfaceView из andoid или текстур directx или что-то еще. Но во всех известных мне вариантах другие процессы формируют кадр и отдают его в очередь основному потоку для компоновки в общий макет.
Я не про графические тулкиты. Это лишь обертки поверх системных библиотек типа GDI/GDI+/DirectX, которые тоже обертки, так как предоставляют HAL поверх драйвера видеокарты. И UI - это, прямо скажем, не отрисовка на экране. UI - это обмен сообщениями от пользователя системе и от системы пользователю. Разработчик UI может вообще не вызывать какие-либо функции отрисовки в явном виде, он работает с событиями и свойствами окон/контролов/виджетов.
И что именно здесь многопоточное? Я не знаю ни одного стека где функции отрисовки, вызываемые явно или не явно, работали бы в несколько потоков. Какие-то части UI могут создаваться отдельными потоками/процессами но результат они отдают одному компоновщику а не напрямую дергают железо для обновления области видеопамяти. Так же и обмены сообщениями между системой и пользователем. Все системы имеют очередь куда попадают сообщения от системы и обрабатываются последовательно.
Знаете в чем между нами разница? Вы категоричны, я нет.
Вот я написал "это не совсем так". Но вы начинаете яростно доказывать, что в UI все однопоточное, при этом упирая почему-то на отрисовку, которая только небольшая часть UI, которая, кстати, с точки зрения прикладного программиста вполне себе многопоточная, если ему это понадобится. Вообще, мне кажется, что вы не очень понимаете разницу между UI и графической подсистемой.
Я не буду говорить за системы на базе Unix я там не настолько компетентен, тем более, что там свой зоопарк в каждой семейке огромного клана: Quartz/QuickDraw GX в macOS, DRM/Wayland/Mesa в Linux, X11 в базе Unix и т.п. Но я неплохо разбираюсь в Windows. Так вот, если взять всю цепочку от настоящего UI до рендеринга, то там на каждом слое свои пляски с бубном по поводу параллелизма.
Самый верхний уровень, включая объектные врапперы типа .NET WinForms, MFC или Qt, является вполне себе многопоточным. Можно Можно создать дополнительный поток UI, для него будет создана отдельная очередь сообщений. Да, там понадобится организовывать отдельное взаимодействие между потоками, да там будут ограничения и окно из одного потока не сможет владеть окном другого потока, да многопоточнось на этом уровне закончится на единственной очереди сообщений приложения (хотя обычно прикладник с ней дело имеет крайне редко). Но при всем при этом UI будет с точки зрения пользователя вполне себе многопоточным (в рамках отдельных окон верхнего уровня) и если "подвиснет" окно из одного потока из-за того, что этот поток занят работой или находится в состоянии ожидания, то окна из других потоков вполне себе останутся интерактивны.
Идем глубже, в слой отрисовки. Опять же, с точки зрения прикладного программиста здесь все вполне себе многопоточное: если я создал несколько UI потоков, то я не должен беспокоиться о том, что отрисовка должна происходить в один момент в одном единственном потоке и что-то там вручную блокировать. Все это происходит на уровне системных библиотек. Кстати, забавно, что виндовые GDI и GDI+ устроены ну очень по-разному и GDI+ действительно однопоточный начиная с уровня своего публичного API, т.е. если одно приложение начинает рисовать, получая контекст, то этот контекст исключительный и все остальные GDI+ приложения ждут, пока он не освободится. Так же GDI+, в отличии от GDI, не может корректно работать в службах Windows, так что если вам надо написать сервис, к примеру, выводящий что-либо на печать, то добро пожаловать в GDI. Так вот, на уровне отрисовки в рамках системных библиотек (за исключением мьютексного GDI+) все еще работает мультипоточность.
Тут мы спускаемся еще на уровень ниже - на WDDM пользовательского режима. И драйверы пользовательского режима все еще многопоточны https://learn.microsoft.com/en-us/windows-hardware/drivers/display/threading-model-of-user-mode-display-driver с единственным ограничением, что если поток создал устройство, то им может пользоваться только он, совсем как с окном на уровне оконного UI.
Если пойдем еще глубже, на уровень ядра, то выясняется, что ядерные miniport-драйверы (тадааам!) тоже могут быть вполне себе многопоточными, но тут уж от вендора все зависит https://learn.microsoft.com/en-us/windows-hardware/drivers/display/threading-and-synchronization-model-of-display-miniport-driver.
До эпохи WDDM действительно на переходе от системных библиотек пользовательского режима к режиму ядра все функции отрисовки укладывались в очередь (не простую, конечно, а очень хитрую, с приоритетами и другими плюшками, типа выбрасывания "протухших" по времени команд отрисовки), но эти времена давно прошли, вся отрисовка теперь передается сверхумным драйверам акселераторов, которые и тайловую структуру, и шейдерные вычислители и бог знает что еще задействуют для реальной распараллеленной оптимизированной отрисовки.
Спасибо за ретроспективу. Только к чему она. Единственное относящееся к вопросу - " врапперы типа .NET WinForms, MFC или Qt, является вполне себе многопоточным", просто ложь. Все эти технологии используют Single UI Thread. Вы можете запустить какие-то потоки но обновлять UI можно только из основного. Если вы запустите новый Application.Run то это будет уже другой процесс, физически другое окно в системе. Ничем в общем то не отличающееся от запуска двух экземпляров приложения.
Еще раз повторюсь я не знаю ни одного тулкита (это такой набор, предоставляющий разработчику готовые наборы элементов) работающих в не Single Thread модели.
познавательно. Не знаю правда любой ли мидл умеет разрабатывать решения с такой синхронизацией потоков.
Как же нет многопоточных задач - а параллельно подтянуть данные из разных апишек, очерпдность вызова которых не важна?
Какое кол-во конфигураций это используют? Особенно те, которые разрабатывались по появления этой функции
Мы про кластер 1С? там насколько помню порождается столько рабочих процессов сколько в настройках задашь.
А рекомендацию- да. Встречал. Насколько актуальна на сегодняшний день и для каких конфигураций -не скажу. Можно потестить. Тест Гилева в помощь. Не знаю, правда умеет ли он сам многопоточность
То есть уже в платформе 8.3.XXXX это можно было реализовать в обработке например выполняющей запись PLU торговое оборудование по списку (речь о РРО и весах с принтерами и панелями самообслуживания?) А то что-то я что в интерактивных обработках что в т.н. "регламетных заданиях" не вижу никаких изменений годами. По сути повторяется один и тот же код, тупо в цикле склеивающий реквизиты в строку и запихивающий её на вход драйверу. Тот же самый подход я вижу и более в чувствительном расчёте который вместо параллельного запуска на выполнение нескольких запросов опять таки линейно их выполняет, что растягивает проведение итогового документа до полутора часов. Так что похоже с применением многопоточности всё сложно.
Не загуглили, а спросили у chatgpt. И кроме первой строки (и то с ошибкой) он вам сгаллюцинировал чушь
Умеет.
Да, на стороне сервера можно запускать фоновые задания отдельным потоком
Да здесь все правильно написано, 1С решает. Но когда в той статье чел написал, что 1С попахивает сектой, он выразил мое ощущение, которое я не мог сформулировать. Купи ознакомительный курс, купи обучающий курс, доступ к великим скрижалям только для своих помеченных)
Во, кстати да, с этой точки зрения 1С похожа на секту 😁
На самом деле почти вся информация есть в открытом доступе, большинство толковых книг по 1С тоже в сети болтаются. Сама 1С предоставляет бесплатно много материала.
Курсы - необязательны, но в среде 1С много крайне качественных курсов, с тонной полезного материала и поддержкой экспертов. Даже мелкие франчайзи периодически покупают курсы, один на несколько сотрудников. Но, повторюсь - в большинстве случаев необязательны.
Лично сам потратил на своё обучение и проф. развитие 1000 рублей на одну книжку. Сертификации - платные, 1000 рублей стоит прийти сдать тест "джун уровня", и порядка 5000 сертификация уровня "миддл". Но их оплачивал за меня работодатель.
таблички в SQL нормализованные до третьей формы? какие то справочники и регистры
Самое весёлое в этом то, что "справочники и регистры" это и есть те самые "таблички, нормализованные до третьей формы" :)
Доступные с самого начала программирования на платформе. Не, можно, конечно, лихим наскоком с методом Тыка наперевес соорудить вообще что угодно (платформа и это позволяет), но в целом, если изучить хоть что-то, прежде чем начинать разработку, то получается, что даже самому новичковскому новичку сразу доступны инструменты, позволяющие разрабатывать плюс-минус правильно.
я понимаю что регистр конкретный в базе БД в виде таблицы явлен. Тут личное- я не с ORM привык работать а более низким уровнем. Понятно, что здесь немного другой понятийный аппарат. и это имеет свои плюсы. Не задумывается разработчик о каком ни будь odbc и обработки ошибки подключений к СУБД. Берёт это на себе платформа
у нас реально идиотское щаконодательство, поэтому лезть туда никто не хочет. туда идут криворукие любители ради ленег, поэтому все бух программы коивое говно из костылей. база 1с родная это такой калл что за него должны платить, а не ты платить за мускуль вместо нее
Вам автора той статьи не переубедить, он же "программист с 40 лет стажа".
Во всем согласен с автором. Но. Все таки платформа 1С - это МСП, к сожалению. Крупняк с количеством одновременно работающих пользователей от 1000, плюс за несколько лет работы появляющиеся узкие места - большие таблицы от нескольких сотен миллионов записей - начинают доставлять головные боли, убогую скорость записи, блокировки, и чисто "платформой" решить такое бывает невозможно.
поднимали выше вопрос. Да- изначально были большие проблемы. Сейчас полегче. я не 1Сник. Но в хозяйстве у меня была терминальная ферма где 1800 пользователей в ERP работали. База не маленькая. Компания огромная. Думаю там не чисто платформой- были и кастомные регламентные на сервере СУБД. И отдельный отдел который кластера 1С сопровождал. Какие настройки они на кластерах прописывали- не знаю. Причем там были ребята которые и в sql умели. И отдельно разработчики конфигураций (несколько отделов для разных конфигураций).
Собственно при количестве пользователей от тысячи многие системы требуют "доводки". Банально - один компонент обновляет данные на текущий лень (update+ insert). а другой формирует отчёт (за завершённый период. Но разрабы не озаботились тем что бы использовать select nolock (разрешить грязное чтение). и ко мне приходили коллеги которые никак не дождутся отчёта.
Тут или с уровнями изоляции работать. Но чревато- контроль тогда должен быть полностью на бизнес логике- либо восстановление из бэкапа копии во вторую базу и отчёты на основе неё. Пошел по второму варианту- время отчётов в 3 раза уменьшилось. Возможно ещё как то можно- я не профессиональный DBA. они думаю могут и ещё пару вариантов предложить.
Не суть. Идея в том что в энтерпрайзе так или иначе уже приходится с узкими местами работать. и next-next-next с параметрами по умолчанию не продут. и те же dba траблшутят планы выполнения выдавая рекомендации разрабам. Собственно за это нам и платят. было бы просто как в малом бизнесе- платили бы медианную ЗП. ну или чуть больше. Что в общем то в малом бизнесе и происходит.
Смысл в том, что даже если твоя команда разрабов в рамках разумного исполняет "систему стандартов и методик".
А архитекторы более менее не делают грубых ошибок в проектировании, умеют договариваться с бизнесом и убеждать его не плодить костыли.
То все равно рано или поздно большая вероятность возникнуть потребности в опытной, штучной и очень дорогой команде эксплуататоров-экспертов, шаманстве со скулем (прямая запись, неплатформенные индексы, всякие дата-акселераторы, о чем вы упомянули, ну и прочие штуки, нарушающие политику лицензирования платформы). И кстати шаманстве с неочевидным результатом.
И проблему вижу как раз таки в концепции самого фреймворка (платформы)-прокладки, максимально упростить разработку, но потерять в гибкости в плане положить/достать из sql.
Сам если что в 1Се около 15 лет, изначально и целенаправленно туда заходил еще в университете и до сих пор не сворачиваю.
Но считаю внедрение современной ERP/ERPУХ для "очень крупных" - профанацией и путем большой боли, в случае с "импортозамещением" - откровенной заявкой на распил.
До 1К пользователей это МСП??? Серьëзно?
А недавний тест на 30K одновременных сеансов под нагрузкой это тоже про МСП?
Очень часто в статьях (как в хвалебных, так и в гневных) упускают аспект стоимости владения системой с точки зрения поддержки законодательства. Если взять условный сектор СМБ, который использует 1С для ведения регламентированного учета + кадровый учёт и расчет зарплаты на "коробочных" решениях, поддержка требований законодательства (плохого или хорошего можно долго разглагольствовать, есть реалии) обойдется около 50 тыс. руб./год на момент написания комментария. При этом ещё и куча сервисов-плюшек в эту стоимость будет входить, включая пресловутый ИТС (1С: КП), который даёт ещё и вагон методологической поддержки для "учётных" подразделений бизнеса, при условии если хотят и умеют пользоваться.
Это я все к лейтмотиву статьи: есть реальные ежедневные задачи бизнеса, которые 1С решает очень дёшево, но иногда и сердито.
P.S. сам из той самой пресловутой секты, но не занимаюсь слепой экспансией, прекрасно понимаю и плюсы и минусы
У автора не снобизм, а карма фарминг с рэйдж байтом, он же написал в комментариях, что 1С много лет в глаза не видел, а пишет для развлечения
Последний раз 1с я видел в декабре. На прошлой работе. На новой у меня задачи совсем иные пока. В конфигуратор заходил. прошлым летом- траблшутили с разработчиком блок кода выдающий ошибку который на стороне клиента выполняется или на сервере кластера 1С.
А написал я, что не являюсь 1С разработчиком, но во внедрениях участвовал активно.
[речь об авторе исходной статьи с "критикой"]
Я правильно понимаю, что вся основная информация по языку и разработке у 1с закрытая? Хочешь знакомиться - проходи курсы, верно?
Нет, не правильно. Есть совершенно бесплатная версия для обучения. В которой есть огромнейшая Справка. Эта справка содержит всю информацию которая раньше была в толстых книгах комплекта 1С. Там есть абсолютно все описание от параметров запуска до описания языка и всей объектной модели.
С 2024г. также есть бесплатная комьюнити лицензия, в которой меньше ограничений и можно поднять базу в режиме клиент-сервера.
Есть бесплатные учебные конфигурации типа "бухгалтерия", "зарплата".
Есть книги и статьи из раздела ИТС которые при большом желании можно локально выкачать за период бесплатного использования.
Да, но чтобы получить эту комьюнити лицензию вам нужно иметь сертификат 1С. А чтобы получить сертификат нужно изучить ее для подготовки к экзамену. Так что для начального ознакомления остается только версия для обучения.
Нет, для комьюнити лицензии не нужен сертификат. Нужно просто на портале зарегистрироваться.
На сайте https://developer.1c.ru нужно зарегистрироваться, получить комьюнити лицензию и откроется раздел для скачивания платформы и постгри для всех ОС. При первом заходе в конфигуратор он попросит залогиниться комьюнити учеткой и всё, можно разрабатывать.
По поводу курсов уже много написали, но можно на канал Учебный Центр 1С на Ютубе зайти и там на любой вкус курсы есть, сгруппированные по плейлистам.
Они скучные )) книжки, кстати, думаю в букинисте подошвке можно взять. У меня на одной из прошлых работ была их куча т к закупали коробочные версии для кучи филиалов и с каждой по две шли. Когда то мне помог mista.ru. Есть на инфостарте много полезного
Я правильно понимаю, что вся основная информация по языку и разработке у 1с закрытая?
~1000 рублей считается "закрытой информацией"?
Если нет, то коробка с учебной версией включает в себя два (если не ошибаюсь) учебника-самоучителя в твёрдой копии. На сайте 1С можно купить электрические версии по отдельности ещё дешевле.
На официальном its.1c.ru есть руководство разработчика, но это справочник, а не учебник.
На всяких видеохостингах полно разных видеоуроков/курсов.
Не знаю как сейчас, но в мои времена в 1С заходили в основном со стажерства во франчайзи, а там уж и реальные задачи, и книжки дадут, и на курсы отправят. Хоп и через полгодика ты уже понимаешь с чем связался и куда дальше развиваться.
Это продажа бизнесу. Но совершенно ни слова нет зачем разработчику. Потому что экспириенс для программиста у 1с ужасный. Хабр это все же ресурс не для бизнесменов, а для айтишников (ну, в основном). Ни единой причины не вижу разработчику изучать 1с. Разве что первую работу в айти получить, а затем свичнуться на что то комфортное и приятное спустя несколько лет, как я сделал.
Ну а куда ещë податься не особо хватающему звезд с неба выпускнику колледжа, чтобы войти в айти?
или в связи с засилием ИИ вокруг:-)
ищите небольшую компанию небольшим ай ти отделом Человек в 5. Там обычно нет жесткого разделения труда. Идите аникеем. Будите справляться и будет желание развиваться- сможете и задачи админа на серверах брать. И в 1С пользователя завести и права назначить разрешат. Админу самому это может быть интересно, если часть его задач сможете Вы выполнять и у него свободного времени на сидении на хабре больше будет, да и рутинные задачи заели его. Попробуйте разные ниши. К примеру BI. там уже определистесь.
Это как вариант. Хотя это и не модная ай ти компаний. Н
Какого экспириенса разработчику 1с по-вашему не хватает? Разработчик прежде всего выбирает предметную область и затем фреймворк для наиболее эффективного решения задач. Мне нравится предметная область - системы учета и 1С вполне справляется с ролью наиболее эффективного фреймворка.
В более менее крупном франче разработчик никогда не будет общаться с бизнесом, только с аналитиками (как франча, так и клиента) и разработчиками клиента, которые часто общаются с бизнесом. Что касается используемых технологий, то помимо 1С приходится использовать:
C++ для написания библиотек для работы с отсутствующей в 1С функциональностью, причем мультиплатформенный, как минимум для Windows и Linux, но иногда требуется включать и MacOS
Python - обработка текстов, парсинг сайтов, несложные сайты на Django и HTTP сервисы
bash - анализ файлов технологического журнала, скрипты devops
WinCMD - локальные скрипты автоматизации
T-SQL и PL/pgSQL - оптимизация запросов к СУБД
COM - манипуляция с документами Microsoft Office
Web/HTTP-сервисы, брокеры сообщений и мессенджеры, работа с XML и JSON
https://habr.com/ru/companies/trinion/articles/892272/#comment_28064164 - Вот тут можно почитать мой камент на эту тему.
https://habr.com/ru/articles/905440/comments/#comment_28250220 И еще вот тут ветка.
Отсутствие системы управления зависимостями
Можно организовать с помощью конфигураций поставщика. Можно скрипт сделать, чтобы она обновлялась автоматически, но обычно этого не делают. Не понятно какое к этому имеет отношение "обновление чужого кода"
Отсюда же идет отсутствие модульности
Открываете регистр сведений "Версии подсистем" и обнаруживаете что модули все-таки есть, как и их версии.
Отсутствие ООП / Отсутствие лямбд/замыканий
Отчасти соглашусь, причина почему до сих пор не сделали функцию объектом непонятна. Это могло бы более эффективно решить многие задачи
Динамическая типизация
Это вкусовщина. На мой взгляд ЯП со статический типизацией были сделаны во времена недостаточной производительности компьютеров и популярность Python это доказывает. А популярность Rust показывает, что C++ не решил всех недостатков C.
Печальная поддержка плагинов
Скорее печальная поддержка EDT. Первоклассной средой разработки он так и не стал. Количество ошибок и скорость их исправления вызывает недоумение.
Необходимо учитывать следующие моменты разработки платформы и типовых решений:
В платформу добавляется только то, что жизненно необходимо, т.к. реализовывать это приходится для нескольких ОС/СУБД/клиентов
Типовые решения содержат огромное количество функциональности, каждую часть которой разрабатывают разные команды разработчиков. При таком подходе создание сложных многоуровневых иерархий классов если и возможно, то будет скорее вредить. Так как на любом более крупном проекте внедрения эта функциональность обрастет дополнительными требованиями от клиентов. А требования конечного пользователя могут погубить самую лучшую архитектуру.
Ориентированность на язык запросов. Началось это с момента разработки ERP, а когда у вас большая часть функциональности связана с построением запросов иерархия классов тоже не пригодится
Можно организовать с помощью конфигураций поставщика. Можно скрипт сделать, чтобы она обновлялась автоматически, но обычно этого не делают. Не понятно какое к этому имеет отношение "обновление чужого кода"
В теории да, на практике не делают этого. Причин много, какие-то я возможно себе надумываю, какие-то реальные, но важно то что выходит на практике. Это есть во всех современных языках (pip, npm, gradle с его dependencies, cargo, etc), а в 1с отсутствует. Везде авторы свои библиотеки делают в готовом к такому распространению виде. В итоге для пользователя добавление/обновление библиотеки выглядит как поменять одну строчку в проекте (иногда несколько, если например с библиотекой еще и плагин для кодогенерации поставляется), но только не в 1с. В 1с либо сравнение/объединение, либо внешние обработки с примерами, которые еще скопипастить надо. Кстати, отсутствие кодогенерации автоматической еще один минус. Часть проблем 1с можно было бы подобным механизмом решить.
Открываете регистр сведений "Версии подсистем" и обнаруживаете что модули все-таки есть, как и их версии.
Не соглашусь, эта не та модульность которую я имею в виду. То о чем я говорю - это что-то в духе gradle модулей. Пространство имен в случае 1с общее, в случае модулей же - дерево зависимостей выстраивается отдельно, и модуль может быть подключен для использования в других модулях и попадать в их пространство имен, а может быть не подключен, и тогда не засоряет его. Плюс в 1с нет аналога package private. Потому внутренности модуля на все пространство имен торчат.
Это вкусовщина. На мой взгляд ЯП со статический типизацией были сделаны во времена недостаточной производительности компьютеров и популярность Python это доказывает. А популярность Rust показывает, что C++ не решил всех недостатков C.
При этом даже в python завезли type hinting. А в случае веба на крупных проектах переходят на typescript с js. По сути в python два режима сейчас, полностью динамическая типизация, которая подходит для скриптов и мелких проектов, и режим статической типизации, который подходит для крупных проектов. Система типов в первую очередь это снижение когнитивной нагрузки на программиста. Например, переименование поля или метода в языке с динамической типизацией штука не самая удобная, нужно руками искать все места вызова и менять автозаменой, и еще не напутать, ведь у двух разных классов (или в двух разных модулях) может быть метод с одинаковым именем, а переименовываем мы только для одного. Таким образом нужно смотреть откуда что приходит, убеждаться что только для правильного меняем и т.п. Плюс статическая типизация дает удобное автодополнение и служит автоматической документацией. Это все не критично если проект максимум несколько тысяч строк. Если же он за 10к строк переваливает - динамическая типизация превращается в кошмар.
Скорее печальная поддержка EDT. Первоклассной средой разработки он так и не стал. Количество ошибок и скорость их исправления вызывает недоумение.
Это в том числе, да. EDT это движение в правильную сторону, конечно, но недостаточное.
Отсутствие ООП / Отсутствие лямбд/замыканийОтчасти соглашусь, причина почему до сих пор не сделали функцию объектом непонятна. Это могло бы более эффективно решить многие задачи
Это пожалуй было одной из наибольших болей для меня. В упор не понимаю почему замыканий или просто хотя бы ссылок на функции не добавить. Язык не сильно усложнило бы, а возможностей дало бы много.
В теории да, на практике не делают этого. Причин много, какие-то я возможно себе надумываю, какие-то реальные, но важно то что выходит на практике
Поставщик конфигурации распространяет ее в виде файла поставки и вы не видите, сколько конфигураций поставщика используется при ее разработке. Так сделано в том числе для упрощения обновления. Но то что они используются это факт.
Конфигурация 1С строится не библиотеками, а слоями. То есть разработчики БП, УТ, ЗУП создали функциональность на базе БСП, затем на уровне ERP их интегрировали, затем разработчики ERP:УХ интегрировали УХ в ERP и затем у клиента развернули ERP:УХ + CRM. В результате клиенту достаточно обновлять 2 конфигурации вместо 5. При этом никто не запрещает добавить клиенту новую версию функциональности из новой версии конфигурации на любом из уровней. При очередном обновлении версия поставщика догонит или перегонит добавленную. Механизм обновления конфигураций поставщика вполне справляется с этой задачей.
Пространство имен в случае 1с общее
Если разработчик поставляет отдельный модуль для добавления в другие конфигурации он добавляет префикс
модуль может быть подключен для использования в других модулях и попадать в их пространство имен, а может быть не подключен, и тогда не засоряет его
Вы можете включить в конфигурацию не все объекты конфигурации поставщика, как собственно делают при внедрении БСП
Плюс в 1с нет аналога package private. Потому внутренности модуля на все пространство имен торчат.
В Python тоже нет, только условное. В 1С есть условное разделение на модули - Обычные, Служебные, Перепределяемые, Локальные. При этом в отличие от Python, есть настроящие private функции
При этом даже в python завезли type hinting. А в случае веба на крупных проектах переходят на typescript с js.
И по этому механизму Python до сих пор идут споры, пока договорились до того, что использовать их следует только в публично распространяемых библиотеках. В EDT тоже есть плагин для этого, есть даже директива для strict модуля. Насколько я знаю с TypeScript та же история
По сути в python два режима сейчас, полностью динамическая типизация, которая подходит для скриптов и мелких проектов, и режим статической типизации, который подходит для крупных проектов
Впервые слышу об этом. Вижу кучу популярных публичных библиотек без всяких типов и возбуждаются от отсутствия типов только адепты языков со статической типизацией
Это пожалуй было одной из наибольших болей для меня. В упор не понимаю почему замыканий или просто хотя бы ссылок на функции не добавить
На данным момент разработчики платформы считают, что механизма передачи полного имени функции и последующего Выполнить достаточно для решения текущих потребностей. Было несколько сообщений на партнерском форуме по этому поводу, но ни одно из них не набрало такого количества лайков, чтобы разработчики платформы обратили на это внимание. Они вообще считают, что в платформе все есть для того чтобы разрабатывать бизнес-приложения любой сложности и в основном занимаются добавлением функциональности, а не развитием языка. Сейчас хоть планы свои публикуют на https://wonderland.v8.1c.ru, гораздо понятней стало в каком направлении развивается платформа
Нельзя рассматривать платформу 1С:Предприятие только как язык, это все-таки огромный фреймворк, поэтому сравивать его нужно не с условным Python, Java или Javascript, а с Axapta, Odoo, iDempiere. И я могу сказать, что по многим возможностям этим системах до 1С очень далеко, хотя там есть и ООП, и пакеты, и модули.
Поставщик конфигурации распространяет ее в виде файла поставки и вы не видите, сколько конфигураций поставщика используется при ее разработке. Так сделано в том числе для упрощения обновления. Но то что они используются это факт.Конфигурация 1С строится не библиотеками, а слоями. То есть разработчики БП, УТ, ЗУП создали функциональность на базе БСП, затем на уровне ERP их интегрировали, затем разработчики ERP:УХ интегрировали УХ в ERP и затем у клиента развернули ERP:УХ + CRM. В результате клиенту достаточно обновлять 2 конфигурации вместо 5. При этом никто не запрещает добавить клиенту новую версию функциональности из новой версии конфигурации на любом из уровней. При очередном обновлении версия поставщика догонит или перегонит добавленную. Механизм обновления конфигураций поставщика вполне справляется с этой задачей.
Ну и где десятки тысяч библиотек со всякими служебными функциями для 1с вроде аналогов gson, кастомных логгеров, какой нибудь кастомной работы с датами и временем, парсингом html/xml нестандартным? Может есть такие вот библиотечки для работы с нестандартными структурами данных и алгоритмами? Которые вот так же как в gradle, добавлялись бы просто одной строчкой конфигурации в программу? Нету их.
Если разработчик поставляет отдельный модуль для добавления в другие конфигурации он добавляет префикс
Ну т.е. вопрос решается костылями (которые еще и не работают, поскольку все равно замусоривают поиск и автодополнение).
Вы можете включить в конфигурацию не все объекты конфигурации поставщика, как собственно делают при внедрении БСП
Так оно нужно. Но оно не должно торчать в тот код который этим будет пользоваться. А предоставляться только через абстракции. Пример см. в моем комментарии тут https://habr.com/ru/articles/897564/#comment_28134226
В Python тоже нет, только условное. В 1С есть условное разделение на модули - Обычные, Служебные, Перепределяемые, Локальные. При этом в отличие от Python, есть настроящие private функции
Одна из причин почему python тоже так себе, да. Там это через костыли надо делать, типа создания библиотек (хотя и gradle модули это по сути те же библиотеки, просто в один проект объединенные).
И по этому механизму Python до сих пор идут споры, пока договорились до того, что использовать их следует только в публично распространяемых библиотеках. В EDT тоже есть плагин для этого, есть даже директива для strict модуля. Насколько я знаю с TypeScript та же история
Насчет python тут точно не скажу как там в коммьюнити к этому относятся, на мой взгляд это язык либо для датасатанистов, у них вариантов тупо нет других толком, либо для того чтобы наколеночные поделия клепать, если писать без типов. Но вот с typescript вы точно ошибаетесь, там без типов никто не пишет насколько мне известно (потому что по сути это тот же js, но с типами, смысла нет typescript использовать если не используешь типы).
На данным момент разработчики платформы считают, что механизма передачи полного имени функции и последующего Выполнить достаточно для решения текущих потребностей. Было несколько сообщений на партнерском форуме по этому поводу, но ни одно из них не набрало такого количества лайков, чтобы разработчики платформы обратили на это внимание. Они вообще считают, что в платформе все есть для того чтобы разрабатывать бизнес-приложения любой сложности и в основном занимаются добавлением функциональности, а не развитием языка. Сейчас хоть планы свои публикуют на https://wonderland.v8.1c.ru, гораздо понятней стало в каком направлении развивается платформа
Нельзя рассматривать платформу 1С:Предприятие только как язык, это все-таки огромный фреймворк, поэтому сравивать его нужно не с условным Python, Java или Javascript, а с Axapta, Odoo, iDempiere. И я могу сказать, что по многим возможностям этим системах до 1С очень далеко, хотя там есть и ООП, и пакеты, и модули.
А мне как программисту какое дело до того достаточно ли всего чтобы бизнес-приложения разрабатывать или не достаточно? В теории и на брейнфаке можно код писать. Мне как программисту важно чтобы на языке было писать просто и приятно. Если от этого еще и бизнес получает плюшки (вроде снижения количества ошибок от статической типизации) то вообще отлично, win-win. А если мне нужно страдать от неудобства работы с языком - значит язык уг.
Ну и где десятки тысяч библиотек со всякими служебными функциями для 1с вроде аналогов gson, кастомных логгеров, какой нибудь кастомной работы с датами и временем, парсингом html/xml нестандартным?
При таком объеме кодовой базы как в 1С:ERP (даже без УХ или CRM) идет унификация всего и вся. Для этих целей в свое время была создана БСП. Если производительности встроенного языка недостаточно, при достаточном количестве обратной связи это появится в платформе. И всегда есть возможность реализовать ваши хотелки с помощью внешних компонент или вызовом внешних программ.
Так оно нужно. Но оно не должно торчать в тот код который этим будет пользоваться. А предоставляться только через абстракции
Я уже писал ранее, что на проекте внедрения все ваши идеально построенные абстракции могут накрыться медным тазом из-за специфических требований клиента. Система изначально создана для внесения изменений в любую часть функциональности и лишние уровни абстракции тут только вредят. Хотя, например, я бы полностью поддержал появление в платформе интерфейсов для модулей.
Насчет python тут точно не скажу как там в коммьюнити к этому относятся, на мой взгляд это язык либо для датасатанистов, у них вариантов тупо нет других толком, либо для того чтобы наколеночные поделия клепать, если писать без типов
То есть по вашему мнению такие продукты как Odoo или Django (в которых нет type hinting) это "наколеночные поделия"? Не нужно забывать, что есть языки вообще без типов, что не мешает писать на них огромные проекты.
Но вот с typescript вы точно ошибаетесь, там без типов никто не пишет насколько мне известно
Под typescript я разумеется подразумевал javascript с типами и популярным он стал во многом из-за популярности node.js, в том числе из-за того что сам javascript весьма специфичный язык. Но что-то не припомню, чтобы кто-то из знакомых frontend-разработчиков его использовал.
В теории и на брейнфаке можно код писать. Мне как программисту важно чтобы на языке было писать просто и приятно. ... А если мне нужно страдать от неудобства работы с языком - значит язык уг.
Не нужно абсолютизировать. Для каждой каждой предметной области используется свой инструментарий. Вы написали, что не считаете платформу 1С:Предприятие достойной внимания разработчиков, но при этом так и не написали, с помощью какого инструментария в вашем понимании должны быть написаны учетные системы.
В то же время многие разработчики, которым нравится эта предметная область и которые работали с множеством из них в последнюю очередь обращают внимание на современность языка.
При таком объеме кодовой базы как в 1С:ERP (даже без УХ или CRM) идет унификация всего и вся. Для этих целей в свое время была создана БСП. Если производительности встроенного языка недостаточно, при достаточном количестве обратной связи это появится в платформе. И всегда есть возможность реализовать ваши хотелки с помощью внешних компонент или вызовом внешних программ.
И вот опять, какие то костыли вместо нормальных решений. Вы мне сейчас пытаетесь доказать что то что я при работе с 1с ненавидел и от чего ощущал дискомфорт - это плюсы, а не минусы. Если это такие вот плюсы, чего же во всех современных языках перешли на нормальное управление зависимостями вместо прямого включения и прочих вариантов?
То есть по вашему мнению такие продукты как Odoo или Django (в которых нет type hinting) это "наколеночные поделия"? Не нужно забывать, что есть языки вообще без типов, что не мешает писать на них огромные проекты.
На 1с тоже пишут, но страдают. Есть у меня опыт участия в разработке коробочных решений, писать и поддерживать сотни тысяч строк кода коробки 1сной это боль без типов.
Под typescript я разумеется подразумевал javascript с типами и популярным он стал во многом из-за популярности node.js, в том числе из-за того что сам javascript весьма специфичный язык. Что-то не припомню, чтобы кто-то из знакомых frontend-разработчиков его использовал.
Не знаю что вы там подразумевали. typescript это вполне себе отдельный язык от microsoft которой в js транспилируется.
Не нужно абсолютизировать. Для каждой каждой предметной области используется свой инструментарий. Вы написали, что не считаете платформу 1С:Предприятие достойной внимания разработчиков, но при этом так и не написали, с помощью какого инструментария в вашем понимании должны быть написаны учетные системы.В то же время многие разработчики, которым нравится эта предметная область и которые работали с множеством из них в последнюю очередь обращают внимание на современность языка.
Вы не путайте платформу и язык. Платформа и фреймворк в целом неплохи, пусть и не без недостатков. УГ именно язык на котором нужно для них писать.
Вы мне сейчас пытаетесь доказать что то что я при работе с 1с ненавидел и от чего ощущал дискомфорт - это плюсы, а не минусы
Повторюсь, дискомфорт у вас скорее был от предметной области, иначе бы вы ее не поменяли
Если это такие вот плюсы, чего же во всех современных языках перешли на нормальное управление зависимостями вместо прямого включения и прочих вариантов?
Я не говорил что это плюс, это особенность и чтобы понять хорошо это или плохо нужна для сравнения другая система с сопоставимой по размеру кодовой базой и построенная на других архитектурных принципах. Но такой нет, есть либо явно недотягивающие по функциональности, типа Odoo или iDempiere, либо явно недотягивающие по удобству SAP, OEBS. Отдельным особняком всегда стояла Axapta, но там уже много лет такой застой, что она ко второй группе присоединилась
На 1с тоже пишут, но страдают. Есть у меня опыт участия в разработке коробочных решений, писать и поддерживать сотни тысяч строк кода коробки 1сной это боль без типов.
Не смотря на то, что для ряда проектов (в том числе коробочного решения) использую EDT никогда не обращал внимание на типы. И судя по количеству упоминаний об этом в telegram-канале по EDT это точно не является причиной, по которой люди ее используют
Не знаю что вы там подразумевали. typescript это вполне себе отдельный язык от microsoft которой в js транспилируется.
В js много чего транслируется, в том числе 1С. Но я никогда не воспринимал TypeScript как отдельный язык, скорее как надстройна над JavaScript. Но не буду утверждать, т.к. ни строчки кода на нем никогда не написал.
УГ именно язык на котором нужно для них писать.
Нельзя встроенный язык 1С рассматривать отдельно от платформы 1С:Предприятие. Более того, нельзя отдельно рассматривать платформу 1С:Предприятие от типовой конфигурации 1C. По-отдельности они никому не интересны. Кроме того, 1С генерирует байт-код обычной стековой машины, что теоретически позволяет скомпилировать в него код "более современного" языка программирования. Но я о таких попытках не слышал, возможно из-за того что никому это особо не интересно.
Повторюсь, дискомфорт у вас скорее был от предметной области, иначе бы вы ее не поменяли
А какая разница какая предметная область? Мне неважно для какой предметной области писать код. Важно чтобы это было делать комфортно и приятно.
И судя по количеству упоминаний об этом в telegram-канале по EDT это точно не является причиной, по которой люди ее используют
Так там типов и нет толком. Я вот как раз немало людей встречал кто, как и я, ушел из-за языка.
Нельзя встроенный язык 1С рассматривать отдельно от платформы 1С:Предприятие.
Можно и нужно. Ведь в работе с кодом на этом языке и заключается основная часть работы.
Более того, нельзя отдельно рассматривать платформу 1С:Предприятие от типовой конфигурации 1C.
А это вообще странное заявление. Может для тех кто только внедрением типовых занимается и их доработкой оно и оправдано, но я большую часть времени когда был в сфере 1с как раз разработкой типовой конфы и занимался, пусть не от самой 1с, но от франча (1с тоир).
Можно и нужно. Ведь в работе с кодом на этом языке и заключается основная часть работы.
Вы не сможете использовать платформу 1С:Предприятие без ее встроенного языка, каким бы ужасным он вам не казался. Но вы ругаете платформу без предложения разумной альтернативы для данной предметной области, из которой в итоге вообще ушли. Достаточно странно при таких вводных давать советы о том какие технологии для этой предметной области необходимо использовать.
Так там типов и нет толком. Я вот как раз немало людей встречал кто, как и я, ушел из-за языка.
И куда ушли в итоге? Когда я начинал работать с платформой 1С:Предприятие 7.7 в ней не было вообще ничего, ни функциональности платформы, ни функциональности типовых решений. Было огромное количество неофициальных библиотек, которые позволяли заставить все это как-то работать. Рядом была Axapta 3.0, которая была лишена большинства из этих недостатков и многие переходили на нее. Но потом вышла платформа 1С:Предприятие 8 и после выхода 1С:УПП поток желающих перейти резко остановился, а после выходя 1С:ERP пошел обратный процесс.
А это вообще странное заявление. Может для тех кто только внедрением типовых занимается и их доработкой оно и оправдано
Это оправдано прежде всего с точки зрения клиента. Ему вообще без разницы какой там язык и какая платформа. Ему нужно получить определенную функциональность за определенную стоимость с определенной стоимостью владения.
Вы не сможете использовать платформу 1С:Предприятие без ее встроенного языка, каким бы ужасным он вам не казался.
Именно поэтому мой выбор не использовать платформу 1с, да. Поскольку язык первичен, в работе именно с языком проходит большая часть времени.
Но вы ругаете платформу
Платформу я ругаю разве что за отсутствие нормальной системы управления зависимостями. Что мелочь на фоне того за что я ругаю язык 1с.
И куда ушли в итоге?
Сейчас под мобилки пишу (в основном android, но и ios немного). Возможно позже переключиться попробую на бекэнд или десктоп. А именно предметная область, повторюсь, мне все равно какая будет. Хоть что-то учетно-экономическое, хоть b2c решения, хоть чисто пользовательские приложения.
Это оправдано прежде всего с точки зрения клиента.
А какое мне дело как разработчику до клиента? Работа должна в первую очередь удовольствие мне доставлять. Одно дело если бы в сфере программирования в принципе бы не было вариантов на каком языке писать, пришлось бы давиться языком 1с. Но ведь это не так. Крепостное право отменили, можно выбирать работу по своему вкусу, а не по вкусу работодателя.
я думаю идеальный эксприенс это на кубинском пляже рядом с красоткой и попивая коктель. А на работе, я лично, работаю. И там критерий- помочь компании достичь бизнес целей. А не получить удовольствие от процесса. Удовольствие- это на заработанные деньги на пляже ))
Вычитай, что написал: море ошибок, читать невозможно.
Полностью соглашусь с автором статьи, просто кому то нужны шашечки, а кому то ехать…
PS
Если кто то может сделать лучше - почему до сих пор не сделали? Монополии тут нет: любая программа ведения учета или формирования отчетов, а так же накладных или инвентаризации, движения товара по складу и прочие бизнес процессы - может выйти на рынок с данным функционалом и занять свою нишу, НО почему то вот уже сколько воды утекло, а воз и ныне там! Все только ругают за корявость продукта (как буд то есть программы, которые не имеют ошибок)))), но при этом ничего нового так и не создали, ни за бугром ни локально! А по итогу эти ВСЕ - это люди далекие не только от IT, но и от бизнеса (кстати обычно это или бухгалтер любящий гонять чаи, а не работать или чувак, который умеет на «си» или «питоне» и считает почему то, что и «эксель» должен «программироваться», а еще всякие pm, которые больше втиратели очков, чем дела ну и бездельники на местах, хотя про буха гоняющего чаи с подругами я уже упомянул)
Где в этой "открытой" штуке взять метрики человеческие? Чтобы понять, что тормозит, СХД, база, платформа или конфигурация. Ибо разработчики обычно кроме технологического журнала ничего предложить не могут. А он тормозящую систему добьёт. И всё время жалуются на сеть, СХД и базы :)
Появление тезиса про отсутствие git и CI/CD в экосистеме 1С это уже само по себе проявление беспричинного хейта и демонстрация уровня полной неосведомлённости автора оного об этой самой экосистеме.
И то и другое есть. И тесты, и наборы готовых пайплайнов, и замеры покрытия, и инструменты сборки. И в Windows, и в Linux, и в Docker. Часть инструментария реализована вендором, часть сообществом.
Приходиться работать в 1С:PDM, 1С:Документнаоборот и 1С:УПП. У меня нет нормальных слов, чтобы описать испытываемые ощущения от взаимодействия с этими программными недоразумениями, особенно с этим как бы пдм и ублюдочным документнаоборот. От работы с ними получаешь ощущение, что их делали исключительно для того, чтобы кратно увеличить количество выполняемой работы.
Соглашусь по поводу 1С:PDM, то что это решение получило сертификат 1С:Совместимо является дискредитацией самой системы сертификации. Но тут дело наверное в том, что отсутствуют аналоги, а они отсутствуют в том числе потому, что все толковые специалисты заняты на проектах внедрения, выхлоп от которых гораздо больше. А тут нужно заморозить огромное количество денег с непонятной перспективой окупить вложения.
1С:УПП хороший продукт для своего времени, единственным недостатком которого являются обычные формы
Искренне не понимаю, какие могут быть претензии к 1С:Документооборот, т.к. продукт изначально разрабатывался на управляемых формах
И, как обычно, плач Ярославны без конкретики. С высокой вероятностью проблема в "прокладке между рулем и сиденьем" (я и про ответственного за эксплуатацию систем в том числе)
Если 1С - это ERP, то каким образом она решает основную задачу ERP - непрерывную балансировку и оптимизацию ресурсов предприятия?
Какой солвер используется для непрерывной оптимизации? Gurobi? Или самописный SIMPLEX метод?
Ну вы так то не гоните. Каким способом мотолок решает задачу постройки моста? 1С ERP это система учета в которой так же есть система планирования. Со своей механикой. Если вы говорите об оперативном контуре планирования это RPS или MES системы, если о стратегии - в бизнесе все сильно проще - драйверная модель. Не нужно рассказывать что хоть одна из существующих ERP умеют в simplex без шаманизма и с ясными результатами. По факту покажите где это используется в мировой практике в хотя бы среднем бизнесе. Стартапы и так понятно - они пока на не заработали на финансиста, который pl и cf не путают.
Я говорю о ERP по определению. Не об MRP или MRP II, а именно о ERP. Вы хоть в курсе, что это расшифровывается как Enterprise Resource Planning?
SAP в качестве солвера для оптимизации использует Gurobi, OEBS еще несколько лет назад - IBM CPLEX. Возможно, тоже ушли на Gurobi.
В SAP им кто-то пользуется кроме транскорпораций со штатом математиков которые могут корректно настроить этот солвер? И это при статичной финансовой модели. Давайте честно ERP не обязан иметь солвер как таковой. Если вам им удобно пользоваться я рад за вас, но бизнес обычно решает совершенно другие учетные задачи в быту. И поверьте, когда бизнес дойдет до потребности "солвера" в 1С:ERP то совершенно без проблем он прикручивается снаружи. Только вот в реальности порванные цепочки документов поставки, нестабильность финансовых моделей и особенности "учетной политики" доставляют больше проблем и требуют больше решений. Вы как и гики из разработки носитесь с солвером, как они с гитхабом и кубернатисом. Сходите в ретеил или производство крупное с взаимозаменяемостью а потом расскажите там про солвер. Я посмотрю как вас будут ссаной тряпкой гонять по складу или торговому залу.
У нас одна из самых крупных опербаз 1С в РФ. 10 тб. И что яхочу сказать - автор вообще прав во всем. Истина проста и неказиста - разработка на языке для бизнеса на посути смеси ооп, скрипта и бсл это нормально. Вы же не учите английский по Шекспиру для того чтобы спросить сколько стоит чашка кофе? И даже в 1С есть свой стек сеньоров и экспертов которые могут и умеют в производительность языка запросов (а в крупных или сложных 1С решениях это 80% разработки). Но тут даже дело не в этом. Сча в меня полетят камни. 1Сник это не ит гик в классическом прохабровском исполнении. Это в первую очередь человек который на листочке может написать схему данных для партионного и серийного учета товаров на складе даже не задумываясь ни на минуту. Для айти специалиста это очерзадача, в которой нужно тз, архитектор, датаархитектор, продакт, бизнес-аналитик, системный аналитик и бригада пояснения.
Как вы оцениваете стоимость владения такой базой 1С? Оно точно того стоит?
P. S. Работал с базой 25 ТБ.
Поднять свой продукт с товарным оперучетом будет на порядки дороже как инвестиционно, так и операционной так и рисково
Обычно рассказы про многотерабайтные базы сводятся к тому, что весь объем и соответствующие проблемы дают 1-3 таблицы, с которыми команда эксплуатации и носится как с писаной торбой, безуспешно мечтая хоть что-то с этим сделать.
25Тб - ДНС?
1С — архаика или рабочий инструмент? Разбор горячего анти-хайпа