Pull to refresh

Comments 152

Хаб «1С-Битрикс», по-моему, лишний для данной статьи. Желательно сделать отдельный хаб по данной теме, учитывая количество статей на хабре по тегу «1С».
есть хаб «ERP-системы». Мне кажется, имеет смысл добавить его.
С одной стороны да, с другой стороны 1С — это, в общем случае, совсем не ERP
Тогда так. Вот было бы здорово, если бы функция «ПланыОбмена.ВыбратьИзменения» принимала максимальный размер выбираемой пачки. Не сразу всё, что там накопилось, а например пачичку в 100 штук. На следующей итерации – ещё 100 штук. И так далее. Она и отрабатывать будет быстрее, если изменений много образовалось. И блокировать будет недолго.

Мы у себя реализовывали подобный механизм для обмена с мобилкой (тоже на 1с через планы обмена). Методу ВыбратьИзменения можно передать массив содержащий только часть данных, а массив можно получить из таблиц изменений. Выглядит в результате это так себе, но работает.
Можно. Делаю так же.

а запрос по изменениям с "первые н" не получается?

А как потом выбрать с N+1?
Снять с регистрации
— возможна проблема, если выгрузка прервётся, а вся регистрация уже снята…
Снятие надо делать после выгрузки файла.
Да, поэтому вариант
а запрос по изменениям с «первые н»
не подходит
Почему?
Я выгружаю в ТЗ «первые н».
Выгружаю это все в файл.
После закрытия прохожу и удалитьрегистрациюизменений.
При таком подходе встаёт вопрос — будет ли корректно воспринята такая частичная загрузка в целевую систему
Ну ок, выгрузили в файл (впрочем с мобилкой файлы использовать очень странно, логично когда обмен напрямую через http), а файл кто то повредил или удалил. И что делать с потерянными данными?
Верно. Для надёжности регистрацию надо снимать только после получения от второй стороны подтверждения о загрузке выгруженных данных.
Вот мы и вернулись к тому что все равно где то нужно фиксировать какие данные мы выгрузили и как то получать информацию что загрузка прошла успешно. И тут можно прикрутить что то свое, но лучше для упрощения все же платформенные методы использовать.

удалитьрегистрациюизменений по обработанным в предыдущей пачке

Для этого нужно получить подтверждение от мобилки что предыдущая пачка загружена, к тому же это может произойти не скоро, нужно хранить где то (либо ключи с мобилки возвращать) какие данные с регистрации снять. Да еще и убедиться что с прошлой выгрузки эти данные снова не менялись… В общем механизм тех же планов обмена с нумерацией сообщений и т.п. переизобретать. Зачем?

а не надо лениться, риб избаловал

А разве он чем-то глобально плох?
UFO just landed and posted this here
Что сказать. В основном с Вами согласен. Единственно только, там где я говорю о блокировках, обратите внимание — нигде не сообщаю что это как-то зависит от 1С. Наверное много текста в статье.
В данный момент моему заказчику блокировки не мешают и он не готов на это потратить даже 8 часов, не говоря уже про 40.
Вы для анализа блокировок чем пользуетесь?
Как правило, головой и жизненным опытом. Косяки, вызывающие избыточные блокировки, в-основном типичные и вызваны одним и тем же набором причин. Набив на них руку, вы уже беглым взглядом на код можете их выискивать.

Да Вы гений. Наверное проверка синиаксиса тоже не нужна.
Вот прибегает к Вам человек, мол вот такая ошибка появляется при записи документа.
И на что Вы собрались беглый взгляд бросать? Обработчики записи формы документа? Модуля объекта? А если и там всё "чисто"?

Я не сказал что что-то не нужно. Я сказал что посмотреть код, КАК ПРАВИЛО достаточно, для выявления подозреваемого куска кода. Инструмент — технологический журнал с настроенным фильтром, затем анализ движений по регистру, кто пишет, кто читает, как именно…
не надо грузить обмены данных за квартал: снижается гранулярность до минут и секунд

Было бы неплохо. А ещё было бы неплохо, если бы обмен работал побыстрее.
А что не так с обменом, точнее где проблема которую нельзя решить?
Выборка изменений тормозит — выбирайте изменения по таблицам изменений.
С записью изменений проблем не видел.
С транспортом проблема? Есть отдельные системы для обеспечения гарантированного транспорта.

Так речь шла из одной типовой в другую. Это как бы уже готовое решение. Почему пользователь должен ещё что-то решать?

При обмене между типовыми через XML за большой период времени объём выгружаемых данных действительно получается достаточно большой.
Тут можно только чаще делать обмен…
Вы преподносите это как проблемы платформы, хотя это всего лишь проблемы конкретных прикладных решений.
Так ведь типовые конфигурации используют механизмы платформы («бест практикс»).
С обменом полный порядок. Но можно улучшить. Даже если ничего особенного не менять, можно повысить скорость обмена в n-раз. Просто разбив на n потоков.

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

Также, для высоконагруженных систем или если производительность работы объектов платформы недостаточна для нужного процесса, всегда можно спуститься до уровня базы данных и решить задачу прямой записью в СУБД — это позволяет решить все возникающие проблемы с производительностью обмена.
Для меня, средств программного комплекса 1С-SQL, достаточно для решения любых вопросов с обменом.
всегда можно спуститься до уровня базы
правда лицензионное соглашение прямо запрещает это
Спорное ограничение, которое противоречит действующему законодательству. Также есть коммерческие инструменты которые используют в своей основе прямой доступ к базе 1С ( 1С QlikView connector например), если у фирмы 1С не возникает к ним вопросов, то про остальных и речи нет.
Он только читает данные.
1С, мне кажется, больше заботит попытка прямой записи в базу.

Компания софтпоинт использует решения с прямой записью в базу — также коммерческое решение давно присутствует на рынке.

Я не спорю — технически это непросто, но возможно.
Просто противоречит лицензионному соглашению 1С.
Нет. В России реверс инжиниринг уже купленных тобой вещей не запрещен. В отличие от США
Т.е. вы считаете, что их лицензионное соглашение незаконно?
Почему? Согласно законодательству РФ вы можете использовать то за что заплатили. Любым способом.
Но только то за что платили.
Крякать можно. Добавлять количество подключений — нельзя
Тому номеру который требуется исходя из логики конкретного решения

Это Вы в уме прикинули. Как нибудь, всё-таки попробуйте написать код параллельной передачи данных.
Если хотите, можно здесь в комментах попробовать.
Я за конструктив. Вполне может быть, что я где-то ошибаюсь. Пока нового ничего не услышал. А было бы здорово получить какое-то новое понимание того, как правильно делать.
У меня есть реализованный обмен где выгрузка была распаралелена через выполнение фоновых заданий. Алгоритм в кратце:
Разбиваем обмен по сущностям — xml строка по выгрузке каждого объекта метаданных формируется отдельно.
Выборку изменений используем только для присвоения номера сообщений текущим записям в таблицах изменений.
Выгрузку проводим по каждому объекту метаданных запуском отдельного фонового задания с указанием номера сообщений для выборки.
Возвращенные строки XML склеиваем в результирующий файл обмена.

Какой объём файла обмена обычно получается?
Перечни изменений в какой момент очищаются?

Чем чаще обмен, тем меньше порции — обычно несколько КБ при ежеминутном обмене.
Очистка стандартная после подтверждения от источника об успешной загрузке.

Хорошо работает?
Смотрите: вот в поток 1 выбрал 100 изменений. Им допустим был присвоен номер сообщения 51.
Вот поток 2 выбрал ещё 100 изменений. Им бы присвоен номер сообщения… какой? 52?
Ок. Допустим 52. Поток 2 закончил работу. Вызвана функция УдалитьИзменения(52), которая благополучно удалит и изменения с номером 51.
Поэтому я и спросил ранее про номер сообщения.

И первый и второй поток выбирают изменения для сообщения 51 — в моем случае распаралеливалась выборка данных. Удаление регистрации в данном случае никаких конфликтов не вызывало.

Так а в чём плюс такого подхода? Почти всё время передачи занимает непосредственно формирование сообщения и его чтение. Это и нужно параллелить.

Я понял. Вы получаете выборку, запускаете потоки на формирование нескольких сообщений, потом ждёте окончания завершения каждого, потом склеиваете и передаёте на ту сторону. А там наверное снова делите на части, запускаете потоки на чтение частей сообщения, ждёте окончания и так далее.
Я делаю проще: каждый поток на передачу делает выборку и формирует сообщение. Просто в теле сообщения есть информация по своей нумерации.
Получается, что у вас загрузка полученного файла нестандартная?
А что поделать? Загрузка процентов 65-70 времени занимает от всей передачи.
Но это только там, где стояла задача по скорости. В основном стараюсь классические схемы применять, строго по букве руководства, второй том.
Я в таком случае регистрировал на фэйковые узлы через раунд робин и выгружал/загружал параллельно. А «основной» узел только для передачи конфигурации был.
Просто поставлю две цитаты рядом:
порционность изменений в ПланахОбмена — это насколько я помню уже имеющаяся давно функциональность

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

Мне кажется Вы не очень внимательно прочитали просто.
Просто он дилер 1С.
А еще, для меня фразы типа «Все тормоза 1С связаны только с одной вещью — дефектами прикладного кода допускаемыми программистами. НУ и еще с неумением проектировать „нормальные“ метаданные.» пахнут маркетингом. 2й свежести.

Уберите из предложения буквы 1С и фраза не потеряет актуальности :)

UFO just landed and posted this here
И отдельное решение для интеграции и трансформации и это не КонвертацияДанных

Про это было бы интересно по подробнее. Что за решение?
UFO just landed and posted this here
С точки зрения блокировок: Есть системы с ~5000 одновременных пользователей(25к в целом)
и они работают и проблем с блокировками не испытывают. но там каждый запрос, и каждая процедура проходит ревью на предмет избыточных блокировок.
Так что я пришел к выводу, что в большинстве случаев «специалисты 1с» не особо заморачиваются и дергают данные довольно бездумно, а это порождает те самые пресловутые «Блокировки».
В 1С запросы бывают только на чтение. Запросы на запись изолированы от разработчика.
каждый запрос, и каждая процедура проходит ревью

«специалисты 1с» не особо заморачиваются и дергают данные довольно бездумно

Я бы так не сказал. Давайте напишем:
ДокументОбъект.Записать();

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

Я же пишу про то, что инструмент нужен, простой и доступный, для поиска и анализа блокировок.
UFO just landed and posted this here
нужен, простой и доступный, для поиска и анализа блокировок
Как Вы себе представляете работу такого инструмента, как в Вашем скрине?
В простом случае, например, у меня есть блокировки, а у Вас на тех же данных нет, что даст такой инструмент? Что он покажет?
Есть вот замер производительности. Он пишет происходящее в отлаживаемом сеансе. Просто нажал, поработал, отпустил, изучаешь результат.

Есть технологический журнал — он пишет то, что происходит во всех сеансах.
Собственно, ничего нового я не ожидаю. Должно показать, что Вы или кто-то ещё ожидали там-то на блокировке столько-то, в другом месте — столько то. Может быть также — нажал, подождал, отпустил, изучаешь. Тыкаешь в строку и видишь причину (или список причин), из-за которого происходило удержание на блокировке.
Что-то такое.
ИМХО, анализ блокировок не является функцией среды разработки.
Скорее относится к СУБД и сильно от этого зависит.

Вы большой молодец. Еслиб мог поделиться шоколадкой, угостил бы. Поставлю плюсик тогда.
Вот вам инструмент БД показал, что запрос, что-нибудь вроде "INSERT INTO ##T436(_Fld0298, _Fld0292)… и так далее блокируется такого же вида запросом. Я знаю MS SQL вам даже визуальную схему нарисует. И чего дальше?
А управляемые блокировки?
Да и почему не иметь всё в одном месте? Особенно если взаимодействие с кодом не помешает.

Конфигуратор — это комплексный продукт, который предназначен не только для разработки, но и для отладки (это в 7.7 были разные программы). Я тоже не вижу особых проблем с настройкой технологического журнала напрямую из конфигуратора с последующим анализом накопленной информации. Обеими руками за такую фичу!
Да, так, безусловно, было бы гораздо удобнее настраивать отборы для ТЖ.

Этот сервис хорош. Поэтому и привёл его как пример стороннего решения на эту тему.
Но в нём результаты не сразу отображаются. Иногда на следующий день только можно что-то увидеть. Плюс установка двух конфигураций. Плюс их настройка.
Хотелось бы типа такого же прямо в среде разработки. И чтоб взаимодействовало с кодом в модулях и с объектами.
Если даже стажёр начнёт находить источники блокировок, я уверен, выиграют от этого многие.

Но эта проблема не стоит у подавляющего большинства клиентов 1с, у которых до нескольких десятков человек в базе.
Я согласен, что инструмент был бы полезен, но надо понимать, что у 1с другие приоритеты.
Тут затраты для 1с не велики. А профит может быть существенен.
Ваш комментарий весьма кстати. Меня уже почти убедили, что цвета формочек важнее.
UFO just landed and posted this here
Спасибо за конкретику. Про инструменты «Vanessa Behavior» и «BrentOzar» не знал.
За ваш (кто это мы?) подход голосую двумя руками.
Алексей, судя по количеству и длине твоих комментариев тебе (вам?) пора запланировать цикл статей на хабре о зарекомендовавших себя практиках применительно к разработкам на 1С. Давай делитесь тем, что накопили ).
А на автора зря вы тут набросились. Одна из немногих статей по 1С-ной тематике на хорошем языке от адекватного автора. Я прочитал с интересом.
ДокументОбъект.Записать()
как минимум тянет за собой все процедуры и подписки которые срабатывают при записи этого документа… и если там все нормально, и написано не криво, то все будет проходить довольно быстро просто и даже таблица документов не будет блокироваться исключительно… так что тут никаких проблем не будет, блокировкам взяться неоткуда.(еще раз, это при условии что при записи документа ничего не происходит.)
Если там все быстро и ничего не происходит, значит у Вас точно не флагманское решение 1С и Вы точно накостылили ненужный пустой документ. Верх профессионализма для элитных решений нынче считается копировать типовые документы вместе со всеми сопутствующими регистрами сведений, дублирующими итоги в регистрах накопления, а так же подписки к ним. Копировать потому, что написать это с нуля уже никто не в силах.

)) если…
Если заниматься разработкой нофой конфы с нуля, есть такая роскошная возможность, как проведение ревью с самого начала. Я так и понял, что Вы под таким углом зрения проблему рассматриваете, когда написали про "окинуть взглядом".
А представьте, что конфа уже написана и такая, какая есть.
Нет автотестов. Нет никакой уверенности, что там всё хорошо.
Вот на такой случай было бы неплохо иметь простенький инструмент по поиску источника блокировок, если они таки случились.
А можно и без, обходились без него всё это время, и дальше обойдёмся.

попробуйте создать и записать большой набор записи в регистр сведений без вообще каких либо индексов и посмотрите в скуль аналайзер. и для хохмы замерьте время исполнения пустого цикла от 1 до 100000000. дефекты внутри платформы — есть, и каким бы ни был семи пядей во лбу 1сник, ничего он с этим не сделает. а на 5000 пользователей системы разбиты на базы и с помощью сторонних технологий.

для хохмы замерьте время исполнения пустого цикла от 1 до 100000000
— а в чём смысл этого?
1С это не универсальный ЯП, а предметно-ориентированный.

а смысл, что в даже самых примитивных интерпретаторах примитивных языков типа бейсика это было поправлено еще в 90-е, но программистам ядра 1с этот опыт не пригодился

Потому что в 1С кода, который бы вращал циклы от 1 до 1000000000, практически не бывает в реальной жизни. А жечь человеко-часы, чтобы ускорить синтетические тесты… Ну я бы, например, не стал, будь я 1С.
Для прикола засёк — у меня такой цикл выполнялся 22 сек.
Но, действительно, в практике я ни разу не встречал потребности крутить такие циклы.
Как я уже писал, 1С это не универсальный ЯП, а предметно-ориентированный.
Работа ведётся большей частью с бизнес-объектами.
Да любая примитивная расчетная задача от этого страдает. Пустой цикл — это лишь один пример. Все конструкции языка такие. А все потому, что внутри используются COM-объекты. А на клиенте еще и 32 бита! Потому и клиент до сих пор 32-битный (Карл!). Тут половина комментариев на тему, что «мы особенные — предметный язык». Прекрасно распиаренная идея самой фирмой 1С в головы программеров и внедренцев, лишь бы не исправлять ядро. И никому не пришло в голову, что у 1сников отбили желание и возможность кодить на языке именно потому, что интерпретатор неэффективен, и кроме как запросами (на чтение) к СУБД дело не исправить. Но это не заслуга «предметного» языка, это беда интерпретатора. Python, Javascript и Lua — такие же предметно-ориентированные скриптовые языки (python реализует это, а js и lua непосредственно работают со своими объектами, как и 1С).
Клиент давно 64 битный.
А сом объекты давно не используются. В качестве доказательства клиент под линукс.
Многолетний опыт показывает, что куда более существенное время тратится именно на работу с данными.
Скорость выполнения именно операторов языка при этом роли не играет.
Был как то случай, из ком объекта массив байтов получали в кривой кодировке, так что в цикле их крутили, немного меняли значения. Бывало цикл со сложением внутри выполнялся несколько часов на 20-30кк операций.
Точного примера кода не осталось?
К сожалению нет, давно было, к тому же потом выяснилось что необходимость перекодирования — из за настроек шины возникла, соответственно код этот выкинули после изменения настроек.
Ком-объект сам по себе медленный, возможно, это из-за него было
Был как то случай, из ком объекта массив байтов получали в кривой кодировке, так что в цикле их крутили, немного меняли значения. Бывало цикл со сложением внутри выполнялся несколько часов на 20-30кк операций.

Я бы просто написал бы мааааааленькую утилитку конвертации на C/Go/Rust/Python/по вкусу. А будучи скомпилированной с безконсольными ключиками она даже на экране не мелькает.


Или 1С не умеет вызывать внешние процессы?

Сейчас я бы тоже так сделал, или ВК написал бы, а скорее всего изначально бы упорнее пинал тех кто за шину отвечает, что они неправы когда говорят про присылают utf-8. Но когда ты джун который и года не проработал и тебе дают готовое решение генподрядчика которое у них где то уже работает — меньше всего будешь заниматься такими вещами.
А вы запишите этот цикл от 1 до 100000000 в одну строчку.
ПС. В режиме отладки платформа 1С выполняет много всего на каждый перевод строки.
UFO just landed and posted this here
Да хоть те же неблокирующие выгрузки. Теоретически этим же можно решать проблемы передачи объектов в разные конфигурации. Но это сильно абстрактные прикидки.
Можно поподробнее пояснить, чем именно это могло бы помочь?
Снижение нагрузки, резервирование, увеличение количества пользователей после которых 1С начинает поскрипывать, уменьшение/избавление от блокировок благодаря консенсусам. Правда неисследованных нюансов огромное количество. Та же сложность развертывания новых конфигураций или взаимодействие ролей.
UFO just landed and posted this here
Ну, вот, да, так что остается дальше ждать полетов на Марс
Из собственного опыта.
1С хороша тогда, когда используются проверенные временем типовые конфы вроде УТ10, БП2, БП3, УПП1.3 и т.д. То есть когда, надо вести бизнес и не париться — все хорошо. Но настает момент когда компания «вырастает». И тут начинается самое интересное.
Если стоит задача идти в ногу со временем, BigData, ИИ, HighLoad и прочее, то тут начинаются проблемы, и проблемы настолько серьезные, что проше написать с нуля на привычном для вас языке (Java, Python, C#).
Возможно у меня руки кривые, но всегда когда дело имел с переработанными конфигурациями, то все «хотелки» заказчика, только запутывали «паутину» все хуже. И латание одной дыры непременно создавала одну, а то и две новые.
В таком случае приходится держать штат собственных квалифированных программистов, а что если их нет?
В общем не так все просто с 1с, хотя и стоит признать, что ситуация налаживается. Платформа 8.3 так это вообще глоток свежего воздуха, для любителя «нативных» интеграций.
Ну это вообще характерно для кровавого энтырпрайза. Тут не в 1С дело, а вообще, специфика жизни.
1С хороша тогда, когда используются проверенные временем типовые конфы вроде УТ10, БП2, БП3, УПП1.3 и т.д. То есть когда, надо вести бизнес и не париться — все хорошо. Но настает момент когда компания «вырастает». И тут начинается самое интересное.

Это проблема квалификации. Только и всего.
Обновлятор типовой конфигурации на следующую типовую вообще не программист. Это и бухгалтера умеют делать.


Если стоит задача идти в ногу со временем, BigData, ИИ, HighLoad и прочее, то тут начинаются проблемы, и проблемы настолько серьезные, что проше написать с нуля на привычном для вас языке (Java, Python, C#)

А при чем здесь вообще язык?
BigData — это проблема не в языке а в архитектуре.


И, минуточку, как это так у вас в мгновение ока случился переход с типовой конфы на БигДату, что вы не успели даже понять что тут нужны совсем другой специализации ИТшники?

Это проблема квалификации. Только и всего.
Обновлятор типовой конфигурации на следующую типовую вообще не программист. Это и бухгалтера умеют делать.

Собственно я о том же.

BigData — это проблема не в языке а в архитектуре.

А она у 1с идеальная?

И, минуточку, как это так у вас в мгновение ока случился переход с типовой конфы на БигДату, что вы не успели даже понять что тут нужны совсем другой специализации ИТшники?


Я разве говорил, что у нас случился переход с типовой конфы на БигДату? Хотя думаю, таких компаний хватает.

Это проблема квалификации. Только и всего

Кстати это какой квалификацией надо обладать чтоб правильно готовить 1с?
Я на пальцах могу пересчитать из своего окружения ребят, которые правильно «готовят» 1с. Не бегут править типовые модули, и добавлять свои реквизиты в регистры, а используют это в крайних случаях, а в большинстве своем используют либо внешние обработки, расширения, либо подстраиваются под типовой бизнес процесс.
Это я к тому, что если все сводится к наличию хороших прогеров, то все тоже самое сделать практически на любом стеке, благо хороших программистов c#, python, java не развелось, только еще не надо будет платить за 1с. В общем баян…
масса пользователей переваливает за некий порог, после которого уже ничего не помогает, даже корпоративный инструментальный пакет

дальше правильный путь — Центр поддержки крупных внедрений. Да и вообще без него видел внедрения на 700-1000 онлайн пользователей. А то, что написано в варианте 1 и 2 — дорого и без гарантированного результата. Да еще и с резким удорожанием поддержки.
А без ЦПКВ можно часто сделать базу распределенной (причем на платформе 1с это сделано очень хорошо) и получить вместо одной большой базы на одного килопользователя 4 базы по 250 пользователей на разных серверах с актуальностью данных от «фуллонлайн» для части данных до 10-15 минут для данных, к которым нет таких требований. Делить можно как функционально (склад отдельно, финансы отдельно), так и территориально (питер отдельно, москва отдельно).

Плюсую. Единственно, по двум вариантам я имел ввиду, что это пример свершившегося выбора в разных компаниях. Насчёт попытки применения ЦПКВ в них ничего не знаю. Может быть и не пытались.

Асинхронность в 1с это боль и кошмар.
В той же Рознице в обработке РМК только для того, что бы избавиться от модальности сделали кучу «ассинхронных» вызовов (например это вызов который совершается после закрытия формы когда никаких других действий не осуществляется) после каждого происходит блокировка интерфейса.
Спрашивается зачем?
Ассинхронность при работе с ККМ или ПК это вообще идиотизм порождающий периодически глюки.

Но в целом 1с — Хороша. Без кавычек. Хотелобы конечно создавать массив вот так
a=[1,2,5,4]

а не так
а= новый Массив;
а.Добавить(1);
а.Добавить(2);
а.Добавить(5);
а.Добавить(4);


Хотелось бы в запросах делать накопительные поля
Выбрать Т.Измерение, НакопительнаяСумма(Т.ресурс)
из Справочник как Т
Упорядочить по Т.Измерение

И
Выбрать Т.Измерение, НакопительнаяСумма(1) как ТутПорядокНомеровПоВозростанию
из Справочник как Т
Упорядочить по Т.Измерение
Асинхронность в 1с это боль и кошмар
— совершенно верно.
Мне кажется не по верному пути 1С пошла
Не нужно путать открыть страничку сайта или получить алгоритм с изменениями данных в документах.
то проше написать с нуля на привычном для вас языке (Java, Python, C#)

О да, вы серьезно? Прямо вот все-все взять и переписать? И UI и Reporting и ORM… Ну т.е. надо конечно взять все готовое из опенсорса, а потом долго все это сопрягать. И постойте… бизнес-логику с 1С тоже надо портировать. И все сущности базы, и алгоритмы… Это точно «проще», чем отпрофилировать тормозные запросы, починить и все же оставить 1С?
Все кто надо уже в комментах, накину еще своего мнения:
— тормозной интерпретатор, ну правда и не говорите что это не важно. Кроме прочитать — вставить в 1С еще куча вычислений, переборов и прочего и порой эти тормоза очень даже заметны;
— отсутствие кастомных индексовю Нет я конечно могу поставить «индексировать» на атрибут, но а если мне надо сразу по двум полям или сделать inсlude? Легко вводится дополнительным метаданным к документам и справочникам;
— ну и стабильности
Некоторое время назад администрировал 7.7, жутко тормозила. В целях сомообразования установил ODBC+Firebird и нарисовал простейший интерфейс для работы с БД sql-запросами. После этого всё стало понятно.
Ну так, поэтому 1С и развивается дальше: 8.1, 8.2, 8.3 и т.д.

Разумеется любой программист средней руки может написать УЗКОспециализированное решение которое даже летать будет.


Но так делают не часто. Наверное это просто не выгодно по сравнению с типовыми универсальными пусть и не быстрыми решениями от 1С?


Иначе бы балом правила не 1С а множество программистов с очень шустрыми наколенными УЗКОспециализированными решениями.

Спасибо. Поправил.

Предыдущая статья — ворчание привыкшего к обычному приложению специалиста. 7 лет работаю исключительно с управляемым — прелесть, а не концепция. Асинхронность тоже хороша, если её осознать, а не пытаться использовать со старой меркой...

А лепить свои кнопки вместо платформенных, если хотим задать вопрос перед записью, это нормально?
Асинхронность тоже хороша, если её осознать, а не пытаться использовать со старой меркой...
Это вы про ее наличие вообще или про реализацию в 1С в частности?
В 1с она не засахарена.
Это ее минус.
Прочитал обе статьи и понял, что у меня просто не хватит желания тратить кучу времени на расписывание проблем 1С, которые не были озвучены в этих публикациях.

Переписывать все нужно с нуля, причем с открытым исходным кодом и без всякого русского языка в синтаксисе, а на общедоступных скриптовых языках. Это я говорю как программист 1С с 5 летним стажем знающим ассемблер, С++, C#, JavaScript.
Переписывать все нужно с нуля, причем с открытым исходным кодом и без всякого русского языка в синтаксисе, а на общедоступных скриптовых языках. Это я говорю как программист 1С с 5 летним стажем знающим ассемблер, С++, C#, JavaScript.

То есть вы не знаете что у языка 1С есть английский синтаксис уже больше 20 лет?

Переписывать все нужно с нуля, причем с открытым исходным кодом и без всякого русского языка в синтаксисе, а на общедоступных скриптовых языках.
И что это даст?
И главное — почему уже не сделано.
Сделаны то только примитивные вещи для склада.

За бухгалтерию опенсоурсному сообществу взяться слабо.
А бухгалтерам сесть на опенсоурс для сдачи отчетов — стремно. Штраф за неправильные или не вовремя сданные налоги…

Но это не мешает очередному шапкозакидателю.
nclockworker покажите нам пример. Сделайте уже.
Это же так просто…
Переписывать все нужно с нуля, причем с открытым исходным кодом и без всякого русского языка в синтаксисе, а на общедоступных скриптовых языках. Это я говорю как программист 1С с 5 летним стажем знающим ассемблер, С++, C#, JavaScript.

Судя по качеству комментариев, то тут все со значительным 1С-стажем и знанием линейки «ассемблер, С++, C#, JavaScript», но только вы хотите избавится от платформы и перейти на что-то другое. Так в чем же дело, что вас останавливает? Ваш выбор Odoo (бывшая OpenERP), которая и опенсурс, и на популярном питончике, и на котором уже много бухгалтерских и прочих конфигураций создано — все как вы и хотели. Их типовые решения даже на русский язык локализированы, но никто не мешает вам писать «с нуля» и продавать свою поделку.

Вот только тут полная аналогия айфонов и андроидофонов. С одной стороны закрытая аппаратная платформа и ОС, которые контролируются вендором; а с другой стороны зоопарк тысяч кастомизаций различных версий операционки под сотни различных девайсов — тонны аппаратных и программных глюков, в которых даже никто не пытается разбираться. Причины популярности среди покупателей «закрытых» решений очевидны.
Очередная бесполезная статья на хабре… Мне кажется перед тем как критиковать, необходимо знать что ты собрался критиковать;) Пройдите курс специалиста 1С, научитесь основам программирования в 1С, пройдите курс конвертации данных получите ответы на обмен между базами 1С. Пройдите курс эксперта 1С, получите ответы на причины появления блокировок и как с ними бороться, кстати в версии 8.3 было много сделано для устранения блокировок. Посмотрите на рейтинг экспертов и какие проекты они вели Про SAP JDE и т.д. как сказал недавно один мой товарищ работающий руководителем отдела логистики одной крупной компании SAP это те же лютики только в профиль. Важно не какая система выбрана, важна ровность рук ее внедренцев, щедрость заказчика внедрения и хорошее знание системы которую они внедряют и поддерживают! лично нахожусь рядом с системой JDE… скажу так фин. директор компании и еще н-ое количество менеджеров сотрудников склада и т.д. были бы рады поменять JDE на 1С, только это стоит денег…
Чего разбушевался? Дружище, всё нормально.
Прежде чем писать очередной бесполезный комментарий, прочитай пожалуйста внимательно статью.

Я тоже согласен с вашим оппонентом: считаю что грабли как правило находятся в безграмотности конкретного внедренца/админа/программиста 1С там где эксплуатируется ПО 1С.


Не спорю — любому сложному ПО всегда есть куда развиваться.
Но проблема низкой квалификации людей подавляющего большинства занимающихся этим ПО на местах — имеет место быть. И не только с 1С

Ок вот вам полезный комментарий: Вместо того чтобы тратить свое ценное время на написание подобных статей, разберитесь с блокировками. Для этого настройте ТЖ, научитесь использовать регулярные выражения perl и парсите ТЖ. Сервис Гилева построен именно на парсинге ТЖ именно поэтому IT отдел крупных компаний не очень заинтересован его использовать, а именно налево сливать какую то инфу. Научитесь использовать SQL profiler, научитесь использовать APDEX, настройте сбор логов Perfomance monitor, пройдите курс оптимизации запросов, научитесь использовать трассировку запросов и т.д… еще много чего. Вот после всего этого прочитайте свою статью и статью на которую вы сослались вначале.
Спасибо, научился. Я то про другое хочу донести — Вам не кажется, что это должно быть немного проще?
А оно и есть проще.

Большинству инсталляции 1С и программист то вовсе не нужен — типовое обновление на типовую конфигурацию 1С может и бухгалтер накатить сам.

Ппри этом есть и другие, более навороченные инсталляции.
Именно они и нуждаются в присмотре КВАЛИФИЦИРОВАННЫХ спецов.

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

Квалифицированному специалисту платят хорошо за то что он решает проблемы.

Если же вы ожидаете что фирма 1С обязана сделат волшебную кнопку для программистов «решить все проблемы» — то возникает вопрос: а за что вам как профессионалу платить будут? Эту волшебную кнопку бухгалтера и сами нажать смогут.

Запомните: профессионалов нанимают и хорошо им платят только потому что наниматель сам не может решить проблему, и не может решить ее силами неспециализирующихся сотрудников.
Противоречите себе в пределах одного сообщения.
Если проще — то даже стажёр должен уметь с проблемой справиться. И это не то, что вы предлагаете.
1С ни мне, ни вам ничего не обязана.
Статья претендует на конструктивную критику.
По поводу того, чем должен заниматься высокооплачиваемый специалист: ловлей блох или бизнес-анализом — вопрос спорный.
Противоречите себе в пределах одного сообщения.
Если проще — то даже стажёр должен уметь с проблемой справиться. И это не то, что вы предлагаете.

Стажер должен мочь справится легко и непринужденно с ЛЮБОЙ проблемой?

Вы видите в выпадающем списке с именами процедур и функций 3 процедуры с одинаковым началом названия «РаспределитьКорректировкуП...» так вот это поле не растягивается.
На скриншоте пример с 3мя процедурами, но есть типовые общие модули где таких процедур 20 и работа превращается в ад.
Что собственно мешало разработчикам сделать этот список растягивающимся?
Думаю, что тоже приоритеты.
Трудности работы разработчиков не приносит дохода 1С, в отличие от добавления «котиков» в Бухгалтерию 3.0, к примеру )
Котики тоже не приносят денег.

Приносят деньги постоянная адаптация под изменения в законодательстве. И только. За это заказчики готовы платить регулярно фирме 1С регулярно.

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

И все
Котики тоже не приносят денег.
Ну почему же. Можно же начать продавать футболочки там всякие и т.п.)
Ваш совет запоздал лет на 15.
Подобные ништяки со своей символикой 1С уже очень давно раздает.
Совершенно бесплатно.
Там куда не ткни, сплошная критика. Но — используем, потому что более-менее стандарт, «в узких кругах».
Вот похвалить 1с — это был бы подвиг. Ну, чтобы обоснованно, и чтобы с обоснованием, почему они выбрали тот или иной путь (и с ним — некое не всем поначалу видимое, но в результате материализовавшееся, положительное будущее)!
Sign up to leave a comment.

Articles