Биоробот
Пришла ко мне соц.сеть под названием "Сетка" и предложила там публиковаться.
Слышал про неё раньше, но не интересовался. Оказалось, это не совсем обычная сеть - профессиональная, для нетворкинга (будь он неладен).
Почему бы и нет, подумал я. Вдруг из этого что-то интересное получится.
Подписывайтесь, если интересно. Я подпишусь на вас в ответ.
Случайно наткнулся в интернете на информацию о OMAD-диете (One Meal A Day — «один прием пищи в день»). Оказывается, популярная штука, особенно среди голливудских звёзд, т.к. сильно упрощает контроль за приёмами пищи, калориями и т.д. при высоконагруженном графике работы.
Кроме, собственно, снижения веса у OMAD есть положительные эффекты, связанные со здоровьем - снижение сахара, улучшение метаболизма. Связывают с явлением аутофагии, которая подключается из-за 23-часового интервала голодания. И вообще, само появление OMAD связывают с открытием и популяризацией аутофагии - Нобелевскую премию её открывателю выдали в 2016 году.
Почему пишу об этом… Я ж тоже раз в день питаюсь, как прям в OMAD-диете :) Начал, правда, сильно раньше 2016 года, когда не было информации ни про OMAD, ни про аутофагию.
Саму эту идею я узнал из двух старых книг. Одна была Галины Шаталовой, советского врача (вот только не помню, какую именно книгу читал). Вторая - Арнольда Эрета, который писал вообще в начале 20 века (название книги, увы, тоже не помню).
Что ж теперь получается? Во-первых, я (и вы) получил независимое подтверждение, верификацию действенности такого метода снижения и контроля веса. Ссылаться на OMAD - проще и авторитетнее, чем на себя несчастного. Во-вторых, могу служить объектом-доказательством, а то и объектом исследований как действенности OMAD, так и долговременного её влияния на здоровье (всё-таки опыт более 10 лет).
Такие вот дела.
Аргумент растущей кучи
Полезные штуки можно встретить в самых неожиданных книгах. Читая очередную из серии «у меня много подписчиков, поэтому я решила книгу написать», наткнулся на прекраснейшую вещь: аргумент растущей кучи, взятый автором из книги Эразма Роттердамского «Похвала глупости».
Звучит аргумент растущей кучи так: «Если десяти монет недостаточно, чтобы сделать человека богатым, что будет, если добавить одну монету? А если добавить еще одну? Наконец, придется сказать, что никто не может быть богатым, поскольку его не может сделать богатым одна монета».
Не правда ли, каждый день подобный вопрос возникает? Что толку писать один пост в блог, если он не взорвёт интернет и не привлечёт массу подписчиков? Зачем мне садиться и делать одну задачу, если проект от этого не завершится? Ну что случится, если я сегодня не схожу на пробежку? Подумаешь, не поговорю сегодня с подчинённым – не убудет от него!
Вот это одно, любое, простое действие – та самая монета. Мозг говорит: от одной монеты куча не изменится, и что толку на неё время тратить. Нужно заниматься чем-то серьёзным! Думать, как сделать сразу 1000 монет! Только это имеет значение!
Увы, фиг там. Куча растёт по одной монете. Это ж какое облегчение-то… Теперь можно сосредоточиться на одной, конкретной монетке. Искренне, с любовью и старанием.
Но уже не потому, что «курочка по зёрнышку клюёт» (никогда, увы, эта фраза не вдохновляла). А потому, что есть аргумент растущей кучи.
Потихоньку расскажу, как сильно ускорять тяжёлые обновления 1С. Сегодня - про ускорение отложенных обработчиков.
Чтобы понять, какие обработчики долго выполняются, достаточно обновить копию и посмотреть. В форме выполнения обработчиков прям время будет написано, в днях/часах, сколько выполнялся обработчик. А сколько ему надо было объектов промурыжить - видно в отчёте “Прогресс отложенного обновления”.
Например, у нас сильно тормозил обработчик регистра сведений “РеестрДокументов” - выполнялся больше суток. Ему надо было перезаписать 9 млн. записей (столько в базе было документов).
Ремарка по поводу того, чего он так медленно работает - распараллеливание типовое плохо работает. При обновлении можно указать количество потоков, на которое распределяются обрабатываемые данные, но предварительное расследование показало, что один обработчик всё равно выполняется в чрезвычайно малом количестве потоков. Возможно, даже в одном потоке. Это очень мало и потому очень долго.
Дальше идём в три процедуры модуля менеджера обновляемого объекта:
ПриДобавленииОбработчиковОбновления - там надо будет через расширение отключить добавление обработчика, чтобы типовое обновление его не выполняло. Там же смотрим, какой процедурой регистрируются данные к обработке (свойство ПроцедураЗаполненияДанныхОбновления, обычно там ЗарегистрироватьДанныеКОбработке). Там же смотрим, какой процедурой выполняется обработчик (свойство Процедура, обычно там ОбработатьДанныеДляПереходаНаНовуюВерсию).
Процедура регистрации (обычно ЗарегистрироватьДанныеКОбработке). В ней надо забрать запрос, который формирует данные к обработке. Обычно там всё несложно - запрос, выборка результата и его складывание в план обмена (ОбновлениеИнформационнойБазы.ОтметитьКОбработке). Нам нужен только запрос и выборка данных, в план обмена ничего писать не нужно.
Процедура выполнения обработчика (обычно ОбработатьДанныеДляПереходаНаНовуюВерсию). Там лежит код обработки. В нём много лишнего (обвес для типовых процедур обновления), но суть обычно понять несложно - читаются данные, сформированные п.2, и что-то с ними делается. Бывает, ещё один-два запроса делаются. Берём вот эту содержательную часть и забираем себе. Не забываем заменить ОбновлениеИнформационнойБазы.ОтметитьВыполнениеОбработки на обычную запись - нам не надо регистрировать обработку в плане обмена.
Дальше нужно написать обработку, которая запустит энное количество ФЗ, каждому скормит массив данных к обработке (из п.2), и ФЗ выполнит адаптированный код из п.3. Мы делали расширение, в него складывали процедуру ФЗ, на входе - массив (обычно это массив ссылок). В процедуре - код из п.3. И обработку внешнюю, в которой мы указываем количество потоков, она выполняет большой запрос из п.2, делит результат на потоки, и запускает кучу ФЗ. И всё.
Контролировать прогресс выполнения можно разными способами. Первый, который я использовал - просто выполнял запрос из п.2. Подавляющее большинство запросов в обработчиках обновления написано так, что возвращают только необработанные данные. Соответственно, их в процессе выполнения становится всё меньше. Но этот запрос может выполняться сильно долго. Потом я сделал несложный регистр сведений, и в каждое ФЗ положил пару строк записи в этот РС - после обработки каждого объекта ФЗ “отчитывалось”, и в регистре было видно общий прогресс.
При наличии нормального объёма ОЗУ запускать такие обработчики можно и в 16, и в 32, и в 48, и даже в 100 потоков (проверено). Это количество ФЗ на один обработчик. А вообще мы в это распараллеливание вывели 22 обработчика из 4 редакций.
Ускорение получается очень существенное - тот, который выполнялся сутки, стал выполняться за 4 часа.
Про типичный паттерн, который помогает решать задачи по производительности в 1С.
Оптимизировали как-то мы обмен (как начало сказки звучит 😁). Вообще, началось не с обмена, а с “иногда 1С внезапно начинает тормозить”. Посмотрели журнал регистрации, выполнение регламентных и фоновых - увидели, что обмен идёт.
Обмен самописанный, под конкретную задачу. В одной базе живут продажи, в другой - номенклатура, цены, штрихкоды и т.д. (некая база с мастер-данными). Когда цены меняют, они должны сразу попасть в базу с продажами (там Розница стоит). Вот этот обмен и тормозил. Провели установку цен - подвисли. Обмен обычный, универсальный, с правилами (на конвертации данных 2).
В таких случаях под подозрение правила попадают - там, при желании, можно настоящий мрак устроить (например, кучей запросов). Посмотрели - ну да, есть запросы, которых можно было избежать. Но вроде не критично.
Второй подозреваемый - количество выгружаемых данных. Здесь важно понимать паттерн - он часто помогает при оптимизации даже типовых 1Сных решений. Паттерн такой: разработчик почти всегда тестирует на ограниченных данных и в идеальной среде (если не было задачи именно оптимизированный алгоритм написать). Если он пишет обмен, то проверяет на 1-2-10 объектах. И на идеальной среде - в которой нет никого, кроме него. Если разрабатывает планирование, то для 2-3 заказов. И там, где он один. И т.д.
Вообще, это всё ежу понятно. Но когда дело доходит до проблем с производительностью, то почему-то паттерн этот часто забывается. Забывание выражается в том, что все исходят из предпосылки “там всё правильно сделано”. А это не всегда так. Оно сделано правильно, но для небольшого объёма данных и для среды, где нет пользователей и другой нагрузки.
Вот и в нашем случае, первые мысли были - переписать весь обмен. Вообще уйти от XML и правил, написать сервис. Потом немного одумались, вспомнили паттерн, и пошли проверять файл с сообщением обмена.
Ну и да, он оказался несколько великоватым. Потом что по умолчанию, вместе с установкой цен, тащил за собой все реквизиты всех номенклатур, упомянутых в документе. А номенклатур там много. И ещё запросом добавлялись штрихкоды.
Дальше понятно. Просто убрали лишние данные из выгрузки (они и правда были лишними, ненужными - номенклатура обменивалась в другом контуре). Файл обмена уменьшился более чем вдвое, в правилах стало меньше запросов, и всё заколосилось.
Конечность силы воли (из серии «математика воли»)
Главное, фундаментальное, что я узнал о силе воли — она конечна, то есть умеет убывать, заканчиваться. Как деньги в кошельке, физические силы, заряд в батарее смартфона.
В любой момент времени — сейчас, например — у вас есть определённый запас силы воли. Которого лично вам хватит на выполнение каких‑то действий — дочитать этот текст, сходить почистить зубы, не съесть на ночь тортика, почитать книгу, сделать уроки. А на какие‑то действия этого запаса не хватит — тогда вы не дочитаете текст, не почистите зубы, съедите тортик (а то и два), отложите книгу, оставите уроки на завтра (или на «вдруг не спросят») и пойдёте в интернет.
Из всех аналогий наиболее близкой мне всегда казалась мана — запас магической энергии в компьютерных играх. Помните? Обычно есть красная колбочка — это здоровье, оно убывает, когда от кого‑то получаешь. И синяя — мана, запас энергии. Он убывает, если колдовать. Потом восстанавливается — или сам (если не тратить), или если зелья восстановления пить.
Сила воли похожа на ману. Делая что‑то, хоть немного трудное, мы расходуем силу воли. Если расходовать быстро, не давая восстановиться — уходим в ноль и идём тупить. Если некоторое время подождать — она восстановится.
Наверное, вы уже поняли мою мысль. Теперь осталось принять.
Съездил на прошлой неделе на конференцию Инфостарта, доклад читать.
Каждый раз, возвращаясь оттуда, думаю — больше не поеду. А через год забываю, почему так решил. Попробую тут записать, может тогда не забуду 😁 Или Инфостарт включит меня в чёрный список.
Всё, что пишу — рациональный взгляд со стороны старого докладчика. Я ездил на конференции Инфостарта с 2015 года.
Первое — я долго ездил туда по инерции, руководствуясь старыми причинами, которые не актуальны уже лет 10. Раньше Инфостарт (и сайт, и конференция) был главным местом тусовки 1Сников. Не единственным, но главным. Не было кучи блогеров, альтернативных каналов и ресурсов, где 1Сники тусуются, онлайн и вживую.
Соответственно, у выступлений на конференциях Инфостарта была высокая конверсия.
Выступить тогда на Инфостарте — всё равно, что попасть на Первый канал в 90-е. Тебя увидят и услышат все. И на выступлении всё не закончится — оно продолжится на сайте Инфостарта, так как сообщество и конференции синергично связаны.
Сейчас Инфостарт перестал быть главной тусовкой, а стал одной из. Возможно, на данный момент — самой крупной. Но точно не единственной. Дальше — простая неумолимая математика. Твой доклад увидит столько же людей, что и 10 лет назад — столько, сколько придёт в зал. Даже при битком набитом зале будет несколько сотен человек.
Если выложить своё выступление в блог или видеоканал — получишь больше просмотров, при несопоставимо более низких затратах.
Инфостарт тоже выкладывает видео выступлений, и раньше это было существенным преимуществом — во времена, когда у 1Сников не было блогов. Но сейчас это преимущество растаяло.
Ну и третья часть конверсии — в узнаваемость в сообществе, то есть на сайте Инфостарта.
Она нивелировалась вслед за развитием других тусовок 1Сников — блогов, сообществ, конференций.
Вот такая математика. Из‑за неё каждый раз и собираюсь больше не ехать.
Но всё равно еду :)
Если смотреть с точки зрения участника, а не докладчика — конференции Инфостарта действительно с каждым годом становятся лучше, удобнее, организованнее, интереснее.
Команда Инфостарта растёт в профессиональном плане, это очевидно. С учётом их опыта, частоты и количества проведённых конференций — они точно лучшие по части их организации (в среде 1С).
Для тех, кто не выступает — конференции Инфостарта очень хороши. Это действительно так.
Для начинающих же докладчиков конференции Инфостарта — по‑прежнему лучшая точка старта, на мой взгляд.
Главным образом — из‑за масштаба конференции, который позволяет набирать в программу довольно много новичков.
Другие конференции вмещают в себя в разы, а то и в десятки раз меньше докладов/активностей, поэтому новичкам туда не пробиться — организаторы стараются пригласить каких‑нибудь мэтров, иначе никто на их конференцию просто не приедет.
А у Инфостарта продуктовая линейка докладчиков сейчас хорошо разделена. Есть хэдлайнеры и конкурсный отбор, через который прогоняют и новичков, и докладчиков с опытом (это некое «среднее звено»). Через конкурсный отбор точно можно пройти. И точно можно не пройти, даже будучи докладчиком с опытом (я однажды не прошёл 😂).
Короче, кто хочет попробовать себя в роли докладчика — вам точно на Инфостарт.
Кто хочет посмотреть/послушать/поучаствовать — вам точно на Инфостарт.
Кто старый прагматик, как я — тому дома на диване сидеть 😊.
Один хороший человек, зовут Руслан, в своём тг‑канале написал небольшой текст про мой «Универсальный механизм планирования» (УМП). Руслану можно верить — он несколько раз внедрял УМП. На практике знает, насколько сложно решать реальные задачи планирования в 1С.
Думаю, опубликовать его текст будет уместным. Тем более, что УМП я распространяю бесплатно (прям здесь). Кстати, Руслан когда‑то тоже скачал УМП бесплатно, внедрил, и только через несколько лет я об этом узнал:)
Итак, текст Руслана.
«Как же долго я тебя искал…»
Знакомьтесь — УМП, универсальный механизм планирования. Когда я впервые про него узнал, радости было ещё больше, чем от автозадач.
Почему? Потому что он умеет делать главное, что должно уметь любое планирование — распределять ограниченные ресурсы (деньги, товары, время работы оборудования и так далее) на потребности (планы оплат, заказы клиентов, планы производства…). И, что важнее всего, делать это гибко, по любым условиям.
Разработал, кстати, всё тот же Иван Белокаменцев (подписывайтесь, если еще не). Не буду подробно рассказывать про техническую часть, это все можно прочитать в описании. Расскажу про свой опыт.
Пример из практики
Производственное предприятие, которое работает в основном под заказ. Главный вопрос от менеджеров:
«Сможем ли сделать и отгрузить к нужной дате?»
В 90% случаев ответ упирается в одно — наличие сырья. А тут всё сложно:
ассортимент продукции большой
сырьё может лежать на складе
а может быть «в пути» от поставщика
Посчитать это в типовой ERP — задачка не из простых. И тут на сцену выходит УМП.
Что мы сделали
Разузловали спецификации готовой продукции до конечных материалов и храним их в специальном регистре — это ускоряет расчёт.
В УМП распределили материалы на складе и «материалы в пути» (с учётом даты поступления и времени, необходимом на изготовление продукции) на заказы покупателей.
Каждый заказ получил статус:
обеспечен
обеспечен частично
не обеспечен
В отчёте видно какого именно сырья не хватает и под какие изделия.
В журнале заказов добавили светофор, чтобы статус был виден сразу.
В АРМ «Формирование заказов по потребностям» диспетчер видит этот же статус и понимает — включать заказ в производство или нет.
В итоге
Диспетчер тратит меньше времени на проверку, менеджеры быстро отвечают клиентам по срокам, а производство получает только те заказы, которые реально можно сделать.
В следующей части расскажу про автоматизацию планирования в производстве.
Про отличия обучения зумеров. Ещё раз акцентирую внимание — текст не содержит оценочных суждений, не ищите тут скрытого смысла «зумеры плохие» или «с зумерами что‑то не так». Каждое поколение отличается от предыдущих. Бэби‑бумеры тоже много написали бы про особенности обучения миллениалов, но у них не было интернета.
Одна из особенностей зумеров — клиповое мышление. Это данность, в которой они не виноваты — среда приучила их к контенту, нарезанному на очень маленькие кусочки.
И кусочки эти становятся всё меньше — это видно по развитию тех же соц.сетей. Например, преобладание коротких видео над длинными в большинстве платформ. Я уже не говорю про тексты — лонгриды уже давно не в чести.
Можно эту особенность игнорировать, учить зумеров с помощью старых добрых длинных курсов, больших видео и огромных сложных текстов.
Но они учиться не будут и ничему не научатся.
Надо нарезать помельче весь контент и все шаги, которые надо в обучении делать.
Видео — короткие. Обучающие задачи — тоже. Предметная или техническая область, которую надо изучить при решении задачи — одна, максимум две.
Тогда норм будет.
Вообще, речь, наверное, про целенаправленное активное обучение, которому зумера в начале карьерного пути подвергают. Первые знания, первые навыки, знакомство с профессией и погружение в неё.
Постепенно зумер сам научится потреблять большой контент, и проблема обучения исчезнет, растворится. Как и клиповое мышление.
Немного про работу с зумерами, если ты — немного постарше. Без каких‑либо оценочных суждений — просто особенности, отличия, которые стоит учитывать.
Их трёх реакций (бей, беги, замри) любимая реакция зумеров — замри.
Вторая по частоте использования — беги.
И крайне, невероятно редко — бей.
Это немного непривычно для руководителя, который раньше с зумерами не работал. Они очень неконфликтные. Настолько неконфликтные, что с ними сложно разговаривать, если тема или тон разговора хоть немного попахивают агрессией, критикой и так далее
Зумер не защищается, не оправдывается, не спорит — он просто замолкает («замри»). И думает лишь о том, чтобы неприятный для него разговор побыстрее закончился («беги»).
С этим надо научиться жить. Если использовать старые методы, давление, критику и так далее — любую агрессию — зумеры будут уходить. Причём, молча, ничего не объясняя ни в процессе, ни после.
Так что, если не можете получить от зумера какой‑то прямой понятный ответ о его работе — это нормально. Ну, для него, по крайней мере.
На одном из проектов перехода с УПП на ЕРП возник неожиданный субподрядчик, который добавил приключений и нам, и заказчику.
Заказчик работает с сетями, а где сети — там какой‑нибудь хитровыдуманный электронный документооборот.
В основе — просто модуль/обработка, написанная какой‑нибудь известной компанией, но обязательно — доработанная на месте под требования сети.
И вроде бы — что может случиться, если мы переходим с УПП на ЕРП, и для обеих конфигураций есть версия модуля ЭДО?
Код модуля — открыт, доработки под сеть — известны. Что может пойти не так?
Первое, что пошло не так — разработчики модуля сказали, что ни нам, ни заказчику нельзя его дорабатывать. А кто там его доработал несколько лет назад для УПП — уже никто и не помнит. Ну, ладно, хозяин‑барин — нельзя так нельзя. Спрашиваем — так, а можете нашему заказчику‑то доработать? Хотя, чего нашему — он и ваш заказчик.
Можем, говорят, только в очередь вставайте. Дело было в ноябре, месяца за полтора до запуска. Ладно, очередь так очередь. Встали, где‑то на декабрь.
В декабре ребята честно что‑то дорабатывали, под конец года отдали результат, и все торжественно ушли Новый Год встречать. В январе, на каникулах, мы запускаем ЕРП, ну и... Доработанные ребятами модули, конечно, не работают. Ну ладно, думаем, ничего страшного = серьёзные штуки никогда с первого раза не работают. Сейчас напишем ребятам, они помогут.
Пишем ребятам, и оказывается... Тех.поддержка не работает (в первые дни каникул).
А заказчику уже отгружать надо — сети, они такие. Там нельзя не отгрузить.
Что делать? Или самим‑таки доработать (но разработчики ЭДО грозили штрафами), или из УПП отгрузки делать. Выбрали второе — сели несчастные люди и вбили реализации в УПП, просто чтобы выгрузить в ЭДО.
Через пару дней начала работать тех.поддержка, но вот незадача... Они ничем не могли помочь с нашим доработанным модулем. Потому что помочь может только разработчик, который с их стороны модули допиливал. А он — на законных каникулах до 12 января. И связаться с ним нельзя никак и ни за какие деньги. А документации он никакой не передал, тех.поддержке ничего не объяснил, поэтому помочь они ничем не могут.
Тут у заказчика вторая волна отгрузок в сеть — ну, что поделать... Пришлось опять из УПП выгружать.
По окончании каникул подрядчик, конечно, всё быстренько починил.
Претензий нет, если что. Просто не знал, что так бывает :)
Теперь знаю. Придётся учитывать этот риск в следующих проектах.
Попалась на глаза статья статья (В чем плюсы использования интервальных регистров) на Инфостарте, про интервальные регистры сведений в ЗУПе. Вспомнил, что недавно использовал эту ЗУПовскую идею для совершенно другой задачи — интервального хранения цен. Но цель использования интервальных РС — та же, оптимизация скорости выполнения запросов и удобства их написания.
Проблема была такая. Есть КА1, в ней — дофигищща чеков. В чеке есть цена продажи, но нет себестоимости. Можно получать какую‑то себестоимость, если включить оценку стоимости списания при проведении документа (фифо, средняя), но это замедлит проведение документов (а их очень много).
К тому же, себестоимость не будет актуальной — документы поступления, как положено, вводятся с опозданием. Соответственно, чтобы актуализировать с/с по чекам, надо или документы перепроводить (а их, напомню, слишком много), или расчёт себестоимости ежедневно или ежечасно делать (не вариант).
У клиента уже было своё технико‑методическое решение — считать себестоимостью цену последнего закупа номенклатуры.
Но тут две проблемы. Если определять цену при проведении чека, то получаем обозначенную выше проблему — поступления вводят с опозданием, поэтому с/с при проведении чека не будет актуальной. Если же брать с/с не при проведении чека, а на лету, отчётом, то тормозит и запрос неприятный получается — кто писал запросы получения среза последних на дату документа, знает, о чём речь.
Ну я и сделал интервальный регистр сведений с ценами. Измерения — номенклатура, дата начала, дата окончания, ресурс — цена. Обращаться запросом к такому регистру — одно удовольствие. И работает сильно быстрее, чем срез последних.
Обновление интервального регистра делается рег.заданием — это быстро, где‑то одна минута на всю номенклатуру. Но всю номенклатуру обновлять надо редко. Я сделал регистр с очередью обновления, туда попадают номенклатуры из поступлений, которые записываются. Провели поступление с сотней номенклатур — сотня записей в очереди появилась. Рег.задание зашло и актуализировано интервальный регистр с ценами по сотне позиций.
Хорошая штука эти интервальные регистры. Рекомендую.
Обновлю статистику по недорогим переходам. Это формат проектов такой, специальный - перейти с одной конфигурации 1С на другую, получить некоторый прирост функциональности, но главное - не потерять того уровня автоматизации, что был в прошлой системе.
В основном такие переходы - вынужденные, вроде отказа от УПП.
Заказчику всё нравится в его УПП, но так уж вышло, что её больше не поддерживают, и придётся переходить.
Поэтому хочется всё сделать с минимальными затратами. Это один из ключевых критериев.
Понятно, что недорогие переходы - не единственный формат проекта, и не всегда лучший.
Но спрос на него есть, вот мы его и придумали.
На данный момент мы сделали 6 таких проектов:
Два перехода УПП - ЕРП;
Два перехода УПП - КА2;
Один переход УНФ - КА2;
Один переход УПП - Аренда (там БП внутри).
Ещё два проекта в процессе, их рано включать в статистику.
Средний чек проекта - 1274 часа.
P.S. Думаю, надо статью написать, предметную - как такие проекты делать, чтобы экономить на переходе.
Перевёл в расширение один из своих старых продуктов - управление задачами. Точнее, это часть некогда большой конфигурации Flowcon. Я выпилил из неё три подсистемы и сложил в расширение.
Перевёл потому, что один потенциальный клиент попросил - хотел посмотреть, что за штука это управление задачами Flowcon.
На момент публикации оно там сыровато всё, конечно, но пользоваться уже можно. Постепенно стабилизирую релиз.
Детальное описание всего Flowcon - https://infostart.ru/marketplace/976048/
В данном расширении - часть "Управление задачами". Ещё включил "Управление компетенциями", но пока не тестировал - сделаю это позже.
А вот на что точно стоит обратить внимание - на часть про регулярный менеджмент. Это штука, которой я сам пользуюсь каждый день. Что это, зачем, и как - описано в отдельной статье - https://infostart.ru/pm/998824/
Расширение можно скачать в тг-канале: t.me/another1C
Интересный кейс обновления у нас тут случился, раньше такого не было.
Обычно основная проблема - доработок много, адаптировать долго или сложно, много кода в расширениях.
А тут проблемой было узкое окно.
В обновлениях больших и нагруженных баз есть такая проблема - пролезть в "окно" (ещё его называют технологическим окном).
Это время, на которое можно остановить базу 1С для обновления, без существенных потерь для бизнеса.
В нашем случае окно было размером в 40 часов.
Вообще, это не так уж и мало, но... Надо было обновить на 4 редакции - с УТ 11.4.14 до 11.5.22.
Кто помнит обновление на 11.5.8, в котором появились распределение запасов и объекты расчетов, понимают - там время обновления измерялось, скорее сутками.
Обращаю внимание - надо было обновить все 4 редакции в одно окно 40 часов.
Так сильно дешевле, чем накатывать по одному релизу и запускать пользователей. Причём, дешевле в разных всех смыслах - не надо адаптировать конфигурацию под каждый релиз (можно это сделать один раз в конце), не надо мучить людей (заставляя переживать 4 обновления, 4 смены некоторых интерфейсов и механизмов).
А наше обновление, если брать в лоб, по-типовому, занимало порядка 2 недель, из которых время полной недоступности базы - суток трое, наверное (это реструктуризация и выполнение обязательных обработчиков в монопольном режиме).
Короче, надо было сжать 300 часов времени обновления в 40, т.е. в 7-8 раз.
Ну и чё... Получилось 😁
Применили нестандартные методы предварительной подготовки конфигурации и данных, оптимизацию обработчиков, обрезку данных - и оно зашуршало сильно быстрее.
Модных режимов, вроде обновления через копию, не применяли. Никакого вмешательства в СУБД не было. ИИ не использовали :)
Как-нибудь соберусь, напишу статью - там есть, что рассказать.
Снял видео про один из способов применения расширения "Рабочий стол" - дашборды рисовать. Лично для меня, как пользователя, это главный способ применения рабочих столов. Эдакий дешманский BI, с очень быстрой настройкой и перенастройкой.
И, кстати, именно с дашбордов "Рабочий стол" когда-то и начинался. Надо было вывести большому руководителю основные показатели работы компании на один экран, чтобы не шарашиться по отчётам.
Правда, дашборды типа "отчёт" (о которых речь в видео) - не самое эффектное представление данных, есть ещё диаграммы. Но про них я отдельное видео сниму.
А пока вот:
https://vkvideo.ru/video-208482299_456239491
https://youtu.be/1rln84eMBwc
Расширение можно скачать тут - https://t.me/another1C/48
Выложил новую версию расширения "Рабочий стол" - подрихтовал интерфейс. Он был старый, т.к. создавался под толстого клиента - см. картинку. Теперь выглядит почти как типовой 1Сный интерфейс.
Также снял видео-знакомство с простейшими функциями рабочего стола (для тех, кто раньше не видел это расширение)
https://youtu.be/-SMc-Q2EOiw
https://vkvideo.ru/video-208482299_456239487
Скачать решение можно в тг-канале https://t.me/another1C
Немного цифр про обновление конфигураций, где основная часть изменений хранится в расширениях.
Именно изменений, т.е. доработанных типовых процедур и функций.
Тут две ветки получается - обновление внутри одной редакции и переход между редакциями.
Если говорить про семейство ЕРП - т.е. ЕРП, ЕРПУХ, КА2 и УТ11 - то переход между редакциями там случается раз в год.
Обновления внутри одной редакции, если изменения в расширениях, обходятся в 1.5-2 раза дороже, чем при хранении изменений в конфигурации.
При большом количестве изменений в расширениях бывает и в 5 раз дороже.
Сам технический процесс обновления с расширениями проходит быстрее, т.к. в этом процессе сравниваются конфигурации (основная, старая и новая от поставщика), а не расширения.
Возня с расширениями начинается, собственно, после привычного процесса обновления. Как в шутку коверкали в нулевые название технологии Plug and Play ("подключи и играй") от Windows - Plug and Pray ("подключи и молись"). Так же и с расширениями.
Если повезёт - всё будет работать без вмешательства. Если чуть меньше, но всё-таки повезёт - вывалятся красные ошибки в расширениях, и их нужно будет исправить. Если не повезёт, красных ошибок не будет, но в процессе эксплуатации выяснится, что доработки расширения молча творят какую-то дичь.
Ну а обновления с переходом между редакциями обходятся в 5-10 раз дороже, если основная часть доработок выполнена через расширения.
Разумеется, речь о большом количестве доработок. А то вдруг в системе 5 доработок, из которых 3 - в расширениях :)
Между редакциями сильно больше изменений архитектуры типового решения. Появляются и исчезают регистры, документы, меняется структура существующих, меняется версия БСП, прыгают и скачут общие модули и названия процедур, меняется режим совместимости.
Ну а все типовые процедуры, изменённые в расширении с инструкциями Вместо и ИзменениеИКонтроль, приходится почти вручную адаптировать под новый релиз. Буквально пересобирать заново - брать новый текст типовой процедуры и вручную помещать туда старые изменения.
Собственно, поэтому и дороже.
Написал небольшую обработку для получения статистики расширения. Использую для предварительной оценки обновления незнакомой конфигурации с большими расширениями.
Обработка подсчитывает:
Количество модулей и строк в них;
Количество модулей с изменениями;
Количество процедур и функций, разбитое по категориям - новые, изменённые с инструкциями ИзменениеИКонтроль, Вместо, Перед/После;
Количество строк в процедурах каждой категории;
Для ИзменениеИКонтроль подсчитывает количество изменений и количество строк в этих изменениях.
Как пользоваться:
Выгружаем расширение в файлы (можно несколько расширений выгрузить и скопировать в одну папку);
Запускаем обработку, указываем папку с выгруженным расширением;
Жмём "Посчитать".
Зачем нужно всё это считать - наверное, понятно. Если много изменений внесено через расширения, то обновление конфигурации становится в разы дороже (хотя, почему-то, многие до сих пор думают, что использование расширений удешевляет обновление).
Но понять, сколько изменений содержится в расширении, крайне затруднительно. В платформе 1С инструменты оценки изменённости есть только для конфигураций.
Обработка тут - https://t.me/another1C/148
Пришлось недавно серьёзно повозиться со сложным обновлением, давно такое интересное не попадалось.
Открытий и интересных решений по дороге получилось несколько, но пока не дошло до обновления рабочей, поэтому всё рассказывать не буду.
Пока про один аспект - ускорение выполнения обработчиков.
В семействе ЕРП регулярно случаются длинные обработчики обновления. Например, при переходе с 17 на 22 в регистр сведений "Реестр документов" добавили измерение с уникальным идентификатором, которое обработчик и заполняет - для всех записей. В моём случае записей было 9 млн, и выполнение обработчика занимало больше суток.
Если нужно сделать 1 шаг обновления, то не страшно - в течение этих суток пользователи могут работать. Но, во-первых, бывают обработчики, которые "отключают" отдельные виды документов или целые контуры учёта, вроде взаиморасчётов или резервов. Во-вторых, мне надо в одно технологическое окно обновить на 4 версии, поэтому ждать было нельзя.
Так вот, попробовал я взять этот обработчик обновления, вынести код в обработку/расширение, самостоятельно распараллелить и запустить. Код там простой, изолированный, никаких зависимостей ни до ни после его выполнения я не нашёл.
И случилось чудо - обработчик выполнился часа за 4-5 (вместо 24+). Попробовал с другими обработчиками, которые столь же изолированные - результат по ускорению тот же.
Я думал, проблема в типовом распараллеливании, которое как-то не очень эффективно распределяет задания между потоками. Пошёл смотреть чужой опыт на партнёрке, нашёл относительно свежую тему (https://partners.v8.1c.ru/forum/t/2259464/m/2259464), где автор нашёл больше меня - дело и в распараллеливании, и в записи статистики. Правда, гарантированного и надёжного решения там найти не получилось - ребята из 1С сказали, что могут быть последствия, если просто отключить статистику. Но обещали что-нибудь придумать со скоростью обновлений.
А пока можете пользоваться тем же способом, что и я, коли возникнет схожая проблема.