Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

Публикация № 1203840

Администрирование - Производительность и оптимизация (HighLoad)

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

 

Несколько слов о себе. Все меня знают, как автора множества статей для Инфостарта. Сейчас этих статей 42. Это волшебное число. Недавно 42, наконец, смогли разложить на три куба – оно было последним среди чисел от 1 до 100. Следующее интересное число – 73, поэтому я надеюсь достичь и этой цифры.

Статьи все разные. Многие были приняты с большим интересом, хотелось бы, чтобы так же стало с докладом.

 

 

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

На слайде в центре – наши программисты. Остальные фотографии – это наши заказчики. Они тут представлены с высоты птичьего полета. Видно, что это – большие, крупные фирмы. Наши заказчики подкидывают нам интересные задачи.

 

Интересные задачи 

 

 

Интересные задачи не появляются просто так. Их нужно искать и уметь находить. У нас глаз уже пристреленный, и мы видим эти задачи. В основном, потому что у нас сотрудники – это люди с научным прошлым. В том числе, и я. И мы стараемся находить задачи, которые соответствуют нашему профессиональному опыту. 

Частью этих задач я делился – например, задача про трехмерную упаковку, двумерный раскрой, поиск маршрутов, оптимизацию производственной программы, планирование перевозок… Это все, что мы запрограммировали, все, что работает у наших клиентов.

 

 

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

 

История разработки системы оптимизации расписания производства

 

 

Мы участвовали в большом проекте на крупном машиностроительном предприятии, с интенсивным многопередельным производством и с большим количеством заказов, в каждом из которых было большое количество операций. Внедрялось 1С:ERP, но производственное планирование в нем «не тянуло» тот объем данных, который требовался заказчику. 

Тогда заказчик приобрел систему Preactor и стал планировать уже в ней. Это импортная система составления расписания, ее, возможно, многие знают. Тем не менее, те критерии, которые требовались заказчику, система Preactor тоже не отрабатывала.

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

 

 

Теперь наша система позволяет составлять производственное расписание напрямую в ERP.

 

Планирование в ERP

 

 

Как в ERP устроено планирование? 

Надо сказать, что по сравнению с УПП планирование в ERP сделало очень большой шаг вперед. Если изучить мировой опыт построения систем планирования, то наиболее развиты APS-системы, которые осуществляют планирование в масштабе предприятия, планируют по-крупному. А планирование в деталях, с привязкой к минутам и секундам в масштабе всего предприятия сделать невозможно из-за большого количества возмущений. И 1С очень точно угадала с тем, что сделала двухуровневую систему:

  • На верхнем уровне работает глобальный диспетчер – согласно теории ограничений систем по методу «Буфер-Барабан-Веревка» разбрасывает задания по цехам. 

  • А дальше на нижнем уровне эти задания исполняются как хотят – там уже все конкретно, задания уже более детализированные, и интервал меньше, и задания меньше, и зависят они от меньшего количества факторов. Уже вступает цеховой уровень планирования, на котором отдельные операции уже можно привязать ко времени. И мы на этом уровне для MES-планирования сделали свою разработку. 

Возможно, вы обратили внимание, что во всех обучающих роликах или лекциях по MES, когда преподаватель показывает построение расписания в ERP (даже на небольшом примере, в котором 10-20 операций), он нажимает на кнопку и довольно долго ждет, когда это расписание построится, хотя это всего лишь учебный пример. Естественно, ждать никто не любит, поэтому стандартной возможностью построения расписания в ERP заказчики вряд ли интенсивно пользуются. Хотя, может быть, у вас другое мнение.

Исходя из этого, складывается ощущение, что система MES в ERP была написана «для галочки» просто для того, чтобы она там была. И в реальных приложениях она, скорее всего, не работает, потому что осуществлять планирование можно десятком других способов, в том числе и вручную. Но если действительно хочется это автоматизировать, то нужно что-то думать. Поэтому мы сделали такой шаг вперед, чтобы появилась возможность построить расписание производства для практических случаев.

 

Что такое расписание производства

 

 

Проблема построения производственного расписания возникла давно, и был человек – Гантт Генри Лоуренс, который занимался организацией производства (вы все его хорошо знаете по фамилии, потому что так называется диаграмма), он описал вот такие требования к расписанию – где оно должно составляться, кем выполняться. Эти требования так и называются, «Принципы Гантта». 

И, если посмотреть в Википедии, как расшифровывается термин «Расписание», то там тоже написано, что это разновидность календаря, где указано, в какой момент, где и что должно делаться. 

Получается, что расписание производства – это производственные операции, привязанные ко времени и месту их выполнения. 

  • Если расписание большое, операций много (в нашей системе обрабатываются десятки тысяч операций), то удержать их в голове, нанести на один лист и просмотреть бывает сложно. Нужна автоматизация.

  • Во-вторых, получается, когда мы строим расписание, мы обязательно должны учитывать ограничения – например, у нас один станок в одно и то же время не может выполнять две отдельные операции. И производственный персонал тоже не может быть в 10 местах одновременно, как Фигаро. То есть, расписание – это не просто набор операций, этот набор должен удовлетворять весьма большому количеству ограничений.

  • В-третьих, расписание можно построить множеством способов, и разные расписания будут отличаться друг от друга – одно будет хорошим, второе – плохим, или вообще не будет укладываться ни в какие рамки. То есть, кроме того, что расписание должно удовлетворять системе ограничений, оно должно еще и отличаться качеством, которое также должно иметь какое-то числовое выражение.

 

Учитываемые при построении производственного расписания ограничения

 

 

Какие ограничения должна учитывать наша система:

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

  • Также должно учитываться, что каждая операция потребляет какие-то ресурсы, материалы, эти материалы должны к моменту начала операции быть уже подвезены или с самого начала иметься на складе – тут сумма остатков плюс накопленный итог – это запросом можно посчитать. 

  • Должны быть доступны рабочие центры. 

  • Должны быть доступны вспомогательные рабочие центры. Кто пытался разбираться в НСИ ERP, тот все эти названия и термины знает, мы здесь просто немного строже их описали. 

  • Рабочие центры обычно работают не круглосуточно, а по какому-то определенному графику – он тоже должен учитываться. 

  • А вообще мы очень часто сталкиваемся с тем, что в наши замыслы вносятся возмущения, и для того, чтобы с ними бороться, нужен запас прочности и запас по времени. Поэтому должны учитываться резервы доступности – если что-то сломалось или что-то не довезли, нужно время, чтобы это можно было исправить.

  • Также у нас должны учитываться различные вторичные ограничения, наподобие площади покрасочной камеры, объема гальванической ванны, в зависимости от которых мы сможем параллельно загружать операции.

 

Критерии оценки расписания

 

 

Какие критерии влияют на качество построенного расписания:

  • Чаще всего обращают внимание на то, что все должно быть сделано вовремя. То есть, коммерческие предприятия должны выполнять заказы в срок. А если вдруг мы их в срок выполнить не можем, то это отставание должно быть минимальным. Время просроченности заказов – это один из критериев. 

  • Кроме этого мы учитываем количество просроченных заказов.

  • Также нужно учитывать, что время рабочих центров может использоваться не целенаправленно – например, на переналадку, когда нужно прекратить одну операцию и начать следующую, а за это время поменять настройки и инструменты. Например, если бы мы хотели послушать все доклады, нам пришлось бы бегать, «переналаживаться» от одного доклада к другому, а если бы все, что нас интересует, шло бы подряд и в одном месте, мы тратили бы меньше времени на «переналадку».

  • Также на качество расписания влияет равномерность загрузки рабочих центров. Иногда удивляешься, что рабочие при планировании расписания обижаются: «Почему меня забыли, почему меня никто ничего не просит делать?» Это удивительный факт, когда приходится сталкиваться с буквальными обидами, человек думает, что его сократят, он хочет, чтобы ему тоже попадали задачи. И если под рабочим центром понимать производственный персонал, то равномерная загрузка рабочих центров тоже является критерием. 

  • Также влияет стоимость выполнения производственной программы. Понятно, что на одном и том же станке разные операции можно делать быстро/дорого или медленно/дешево. 

  • Кроме стоимости влияет общее время выполнения –  здесь приведены формулы, можете их посмотреть. 

  • А чаще всего используется комплексный критерий, когда мы не можем выбрать ни один из этих критериев, их всех смешиваем, чтобы получить какую-то их взвешенную сумму, и все они участвуют в формировании общей оценки – как средний балл у человека. 

 

Сложность задачи

 

 

Вообще задача сложная. 

  • Помните мою статью про трехмерную упаковку? Попробуйте сами сложить все эти коробочки так, чтобы между ними осталось меньше места. Есть огромное количество разных способов, и все время оказывается, что туда больше ничего нельзя запихнуть. Но, поскольку в трехмерной упаковке ограничений только три – по высоте, ширине и глубине, а в задаче построения производственного расписания ограничений больше – поэтому она сложнее. 

  • В ERP используется однопроходной алгоритм – когда мы выложили на доску какую-то операцию, зафиксировали это решение и поменять его уже не можем. Хотя, может быть, в самом конце мы увидим, что определенный шаг решения у нас был неудачным. Просто не хватает времени, чтобы принятое решение пересмотреть. Так оптимальное расписание не построить. 

  • Нет общей модели и общего метода решения. Многие люди думают, что мы сейчас возьмем задачу, полистаем книжки, посмотрим, найдем соответствующий нашему названию метод, разберемся и решим его. Но общий метод решения зависит от того, как сформулировано ограничение: если целевая функция линейная, то это один метод, если целевая функция квадратичная – то второй метод. Если ограничения целочисленные – третий метод и т.д. А клиент хочет все и сразу. И получается, что общего метода и общей модели нет. Это – очень сложно. И поэтому академические, высокоэффективные суперсложные решения здесь плохо работают.

  • Большинство методов в условиях сформулированных ограничений – NP-полные. Это означает, что мы, не перебрав все возможные расписания, самого лучшего решения не получим. А когда мы выстроим все операции в цепочку, у нас количество возможных расписаний станет равным факториалу (n!) – это очень много. Если операций три – это шесть, если пять – 120, если их сто – это уже больше, чем атомов во вселенной. 

  • Любое небольшое изменение условий переводит задачу в другой класс, требуя от нас других методов решения. 

  • Требуется большой объем вычислений. И хотя раньше мне казалось, что 1С может решить все, если исхитриться и что-то изобрести – в данном случае это не срабатывает. На стороне 1С такой большой объем вычислений производить нецелесообразно.

 

Метод решения – эволюционный генетический алгоритм

 

 

Тем не менее, мы выбрали метод решения. В его основе – эволюционный генетический алгоритм. Его достоинства:

  • он легко перестраивается на решение других задач;

  • легко добавить или изменить систему и форму ограничений;

  • легко добавить или изменить критерии;

  • он хорошо распараллеливается.

Есть и недостатки – это нестабильность, когда, запустив алгоритм на выполнение второй и третий раз можно получить разные расписания. С этим нужно как-то технологически, организационно бороться.

Время показало правильность нашего выбора, потому что ТЗ, с которого мы начинали, многократно уточнялось. И если бы та модель, которую мы выбрали, была строгая, то предлагаемый нами метод давно бы перестал работать. А так мы с задачей все-таки справились.

 

 

Если говорить о сущности нашего метода, то как он устроен:

  • У нас есть вариант расписания – это как индивидуум (какой-то зверек, животное в длинной цепи эволюции). 

  • Совокупность этих расписаний у нас соответствует популяции. 

  • Индивидуумы в ходе эволюции друг друга воспроизводят, в процессе этого они меняются под воздействием мутаций, скрещиваются, лучшие черты родителей переходят потомкам, отбираются – получается все, как в жизни. 

  • Собственно говоря, в некотором смысле наши занятия математикой, или прикладной математикой, или просто программированием подтверждают наши общие жизненные установки, общие представления. Нашей работой как будто подтверждается теория эволюции.

  • И что касается небольших подробностей – в эволюционных алгоритмах есть понятие генотипа и фенотипа. Генотип – это последовательность операций. Привязываем каждую операцию к рабочему центру. И на одном рабочем центре выстраиваем последовательность операций, не фиксируя времени выполнения конкретной операции, которое дали в фенотипе (после интерпретации мы получаем фенотип). 

  • А фенотип – это расписание с привязкой операции по времени. Оно определяется уже в процессе интерпретации, когда мы применяем ограничения. 

 

Общая схема эволюционного алгоритма

 

 

Общая схема эволюционного алгоритма выглядит таким образом:

  • У нас имеется популяция – генерируется набор случайных или предварительно сформированных ручным способом расписаний. 

  • Каждое расписание получает оценку по соответствующему критерию, и помещается в популяцию с этой оценкой. 

  • Далее может производиться мутация – берется расписание, в него вносятся небольшие изменения, после чего оно оценивается и снова помещается в популяцию. 

  • Или расписание подвергается скрещиванию – берется два родителя, их операции каким-то образом смешивается, и также получается потомок. 

  • Плохие расписания отбраковываются – производится контроль популяции.

 

 

Вот так у нас это изображено на блок-схеме. Получение данных, генерация начальной популяции, выбор расписаний, преобразование, интерпретация, оценка – все в соответствии с блок-схемой. 

 

Применяемые методы мутаций и скрещиваний

 

 

Надо сказать, что мы жалеем вычислительные ресурсы и не стали идти как в природе и делать случайные мутации. В нашей системе мутации – это эвристики. Пример этих эвристик приведен. Например: 

  • мы переносим на ранние сроки операции запаздывающих заказов;

  • группируем операции с минимизацией переналадок;

  • переносим операции на другой РЦ с усреднением загрузки группы РЦ и т.д.

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

По мере необходимости эвристики дополняются или исключаются. Используется статистика их результативности, нерезультативные мы не используем.

 

 

И скрещивания – их набор чуть победнее. Тем не менее, тоже не одно. 

 

Реализация многопоточности

 

 

Кроме того, уже после окончания проекта мы этот алгоритм распараллелили по ядрам процессора. У нас имеется общая память, где хранится популяция, и каждая веточка алгоритма выполняется параллельно, отдельным ядром. 

В результате мы получили практически линейное ускорение в 8 раз (у нас было 8 ядер). Если бы ядер было 16, было бы ускорение в 16 раз – мы пока не ощутили достижения предела на наших мощностях.

 

Сложности, возникшие при реализации

 

 

Какие у нас сложности возникали, как мы их преодолевали?

Когда у нас получается генотип, то фенотип образуется не всегда, потому что эта сгенерированная последовательность может не выжить – может получиться нежизнеспособный мутант. Это происходит за счет дедлоков (типа блокировок в СУБД). Чтобы их развязать, достаточно отбросить какую-то транзакцию, а здесь этого сделать нельзя, поскольку мы очень бережно относимся к сгенерированным нами последовательностям. Развязывание дедлоков – это довольно сложный математический алгоритм. Он тоже NP-полный. Нам пришлось изобретать свой, легкий алгоритм. Но, тем не менее, мы с этим справились, и получилось достаточно интересное решение.

И вот еще интересный момент, который мы здесь отметили – когда я давно занимался 3D-упаковкой, у меня было ощущение, что мы возьмем и распределим задачи по одному серверу кластера, второму, третьему, четвертому, и получим пропорциональный рост. То есть, после достижения этой полочки (количества ядер, по которому мы распараллелили алгоритм) мы таким же образом распределим между серверами. 

Но оказалось, что мы здесь ошиблись и получили отрицательный результат. Но отрицательный результат для науки – это тоже результат, поэтому я хочу им с вами поделиться.

Мы, получается, очень долго не могли понять. Провели работу, у нас были SOAP-сервисы запущены для того, чтобы обмениваться между серверами. И не получаем мы ускорение. Оставляем на ночь, на воскресенье, на компьютерах всех разработчиков запускаем. И получается, наоборот, хуже. Почему? Оказывается, есть объяснение. Мы модель построили, чтобы это объяснить. Вкратце, дело в том, что для некоторых разновидностей вычислений обязательно требуется общая оперативная память и быстрый доступ к ней. Иначе передача промежуточных результатов с сервера на сервер съедает весь возможный выигрыш. Для борьбы с этим на суперкомпьютерах есть особые шины. А так просто, как в 1С, добавить сервер в кластер и ускорить вычисления не получиться. Вообще нужно следить за прогрессом в этой области. Когда появятся 128-ядерные процессоры, их нужно покупать. Нужно сказать, что это не только в нашей области решения задач оптимизации, но и в области нейросетевых технологий точно такой же эффект отмечается. Возможно, там другие объяснения. Но это – та вещь, которую мы почувствовали своими руками и поэтому этим хотелось бы поделиться.

 

Подробности реализации

 

 

Что представляет собой наше решение:

  • Оно сделано на C#. Платформа .NET Core. 

  • Размер кодовой базы примерно 15 тысяч строк. 

  • Обрабатываемые расписания состоят из десятков тысяч операций – у нас встречалось 13-15 тысяч. 

  • В результате построения одного расписания мы получаем десятки тысяч вариантов. Бывает 5 тысяч, бывает 15 тысяч. Когда мы запускали пример на неделю, там могли быть и миллионы.

  • Конечно, наше решение показывает гораздо более высокую скорость, чем встроенные методы в ERP. На несколько порядков (на три, наверное). 

  • И показывает лучшие результаты при том же самом времени. 

  • Также оптимизирует переналадки – наш метод работает в гораздо более широком диапазоне условий.

 

 

Мы оформили наше решение как расширение, которое добавляет кнопку в окно расчета расписания производства продукции.

Сам расчет может запускаться на отдельном сервере, а обмен идет через общую папку или через FTP. 

 

 

Вот пример вызова. Тот, кто работал с MES, это окно знает. Сюда добавлена возможность расчета внешними средствами. 

Вы видите, что в качестве ограничений используются те же самые модели планирования. За небольшими исключениями мы поддержали фактически всю функциональность, которая есть в ERP.

 

 

Есть окно настроек. 

 

 

Окно с результатами работы – это то же самое окно.

 

 

И вот статистика. Здесь можно посмотреть, как все у нас происходит. 

Линия рейтинга здесь – это антирейтинг, потому что она показывает, как сокращаются издержки. Этой линией изображен комплексный аддитивный критерий, полученный суммированием с весовыми коэффициентами. 

А ниже у нас изображены частные критерии. 

Видно, что иногда какие-то из критериев растут навстречу рейтингу. Например, когда стали минимизировать переналадки, критерий OverdueTime, изображенный красной линией, у нас все-таки подрос – мы чуть-чуть пожертвовали просроченностью. 

Итого, у нас здесь всего лишь 3000 вариантов, но мы для них, судя по всему, уже вышли на самое оптимальное значение.

 

 

А здесь – другой вариант, когда встречных движений нет, все более-менее гладко. 

 

Общие выводы

 

 

  • Я довольно давно занимаюсь 1С и вижу, что, несмотря на надежды сообщества, 1С в области методов оптимизации работать не будет. Это – интересная ниша, пожалуйста, занимайте ее.

  • Выбирая метод решения задачи, связанной с оптимизацией, следует выбирать метод более общий, даже в ущерб каким-то маленьким достижениям. Условия задач меняются гораздо быстрее, чем программируется специализированный метод. Только так мы можем экономить. Это вообще тенденция сегодняшнего дня, что мы экономим свое время, а не компьютерное. 

  • Нужно иметь в виду, что есть фундаментальные ограничения при распределении оптимизационных задач между серверами кластера. Десять маленьких силачей не заменят одного большого. Не надейтесь распределить решение. Выбирайте многоядерный сервер.

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

 

Вопросы

  • Preactor в итоге совсем убрали?

  • Да, наша обработка работает без Preactor. Preactor очень многое может, мы можем работать вместе с ним. Но Preactor стоит полтора миллиона, это гораздо больше, чем стоимость ERP. А сейчас мы уже вышли на более широкий рынок – увидели потребность, что классическая ERP-шная обработка пооперационного планирования не работает в реальных применениях, и сделали так, чтобы она могла работать. Мне кажется, что это здорово. 

  • А на этом конкретном проекте Preactor был внедрен?

  • Да.

  • Вы сказали, что заказчика не устроила функциональность Preactor. Не скорость, а функциональность. 

  • Если говорить про тот конкретный проект, то мы на нем работали в качестве подрядчиков, за спиной исполнителя. Там Preactor выполнял очень много задач. Клиенту Preactor подошел, клиент с ним продолжает работать. Просто в некоторых случаях при некоторых настройках Preactor не минимизировал переналадки так, как хотелось клиенту. Они хотели иметь эту кнопочку, и мы эту кнопочку им сделали. 

  • А сколько по времени занимал ваш пересчет?

  • У нас много критериев остановки. В той исходящей задаче у нас было ограничение по времени 10 минут. За эти 10 минут мы отрабатывали 9000 расписаний. Кроме этого, у нас есть критерий остановки, когда график стабилизируется (выходит на «полочку»), расписание уже не меняется. В принципе, обычно мы старались уложиться на том объеме, который нам давали, в десятки минут. Когда мы проводили тестирование – на сложных задачах на большом количестве данных, то запускали расчет на сутки, и решение обычно находилось за 5-6 часов. А вообще критерий остановки в задачах оптимизации – это сложный вопрос.

  • А можно ли для составления расписаний использовать специальные математические пакеты – тот же самый MatLab или Python с библиотеками?

  • Я – большой любитель MatLab, напрограммировался на нем. Многие люди думают, что мы купим известный IBM-овский пакет и решим все задачи. Нет, потому что получается, как дерево – у корня его можно охватить, а у кроны задачи очень быстро расползаются и специальные математические пакеты в области построения расписаний не работают, потому что они работают тогда, когда задача поставлена совершенно конкретно и у нее есть строгие четкие ограничения. Такой узкий класс задач встречается очень редко. Поэтому мы эти специальные пакеты не использовали. Не потому, что мы про них не знаем, а потому, что не нашли такой возможности.

  • Но вы писали практически с нуля, и вам приходилось часть функциональности, которая есть в этих математических пакетах, в том числе ограничения по операциям с плавающей точкой, чтобы не набегала ошибка, делать все в ручном режиме. Потому что идеальный алгоритм (простейшее решение системы матриц 20*20, если его написать «в лоб»), не решится – это ограничение жестких систем.

  • Здесь таких проблем нет. В генетическом алгоритме для построения расписания при ограничении операций ошибки не набегают. Это не расчет себестоимости. Мы сейчас работаем на очень широком поле задач, поэтому я здесь убежден и готов отвечать, что специальные математические пакеты в этой области не работают. Можно привлечь к нашему разговору Евгения Борисовича Фролова – человека, который ведет школу оптимизации расписаний. В этом случае работают только практически ориентированные методы.

  • Два вопроса в сторону конкретики – какая в ваших кейсах была стандартная глубина прогноза этого расписания – насколько вперед они смотрели? И как часто приходилось уже просчитанное, казалось бы, расписание пересчитывать в случае каких-то отклонений по факту от него. 

  • На том проекте, с которого все началось – там глубина прогноза расписания была полтора месяца (7 недель). Не знаю, что это за волшебное число, но у меня довольно часто это число выскакивает в практике. Пересчитывать приходится часто, даже очень часто. Недавно мы решали задачу по производственной логистике, где применялись очень похожие методы. Там мы вообще отказались от долговременного прогноза – и просто перешли на часовой интервал пересчета.

  • Вы упомянули, что эвристический метод не дает одинаковый результат два раза. Получается, что вся глубина прогноза может очень сильно измениться?

  • У нас есть операции, которые начаты – они зафиксированы. У нас есть возможность закрепить операции в расписании и их не пересчитывать – это и в ERP есть. Конечно, иногда мы не можем за выделенное время составить оптимальное расписание – тут уже нужно чем-то жертвовать. Но бывают важные заказчики, важные заказы и т.д. Это все учитывается.

  • В вашем итоговом расписании соблюдается ли условие, что на рабочий центр запланировано не больше работы, чем его мощность? Эти алгоритмы учитывают, что мощность рабочих центров ограничена?

  • Да, они учитываются. В нашем сегодняшнем алгоритме это учитывается как ограничение, причем, с резервом доступности – не больше. Оно проигрывается и если сюда не вписывается, то оно переносится и расписание удлиняется или  появляются задержки. Иногда бывает (мы с этого начинали) – это можно перенести в разряд критериев – разрешить это, но оценить это каким-то штрафом. Например, если мы это перегрузили, то мы штрафуем это расписание чуть больше. В текущей реализации у нас доступность рабочих центров – это ограничение. Но можно поменять. И я говорил, что это – выбранный нами подход. Он позволяет гибко перестроить условия. Еще я просто не успел сказать, что мы сделали простую обработку для 3D-упаковки, где используется тот же самый алгоритм – просто немного поменяв несколько библиотек. А код в большинстве своем остался тем же самым. Сейчас мы боремся за результаты – и лучшие алгоритмы у нас показывают 80-90% плотности упаковки. К сожалению, пока ближе к 80%.

  • Как себя ведет ваш алгоритм при радикальном увеличении числа операций? Вы сказали, что у вас 13-15 тысяч операций. А если будет 100-500 тысяч операций?

  • У нас 10 тысяч операций – это предел, который не нужно превышать просто исходя из наших жизненных установок. Это общее понимание у всех методологов, кто занимается оптимизацией расписания, что большего количества операций в расписании никому не нужно, иначе оно за счет теории вероятности просто окажется неисполнимым. Поэтому это не нужно. Но наш алгоритм по затратам времени растет линейно, здесь нет квадратичных зависимостей. Получается, если операций у нас в расписании стало 100 тысяч, и мы влезаем в оперативную память, то оно просто будет выполняться в 10 раз дольше. Например, если мы в расписании за 10 минут считаем 10 тысяч операций, то при расчете 100 тысяч операций за 10 минут мы посчитаем только тысячу, соответственно, нужного качества не получим. Обратная линейная зависимость.

  • Все-таки качество итогового получившегося расписания зависит от количества операций?

  • Конечно. Это же поиск – если у нас скорость поиска медленнее, то мы и рыбы поймаем меньше.

  • А как вы оцениваете, на российском рынке, среди российских разработок у вас есть конкуренты в сегменте APS?

  • Мы с ними не сталкивались. Во-первых, у нас это не коробочное решение. Это у нас проекты – с конкретными заказчиками. Это проекты с небольшой стоимостью. Поэтому мне кажется, что мы не должны с ними пересечься. Мы позиционируем свое решение как плагин для ERP. Вы купили ERP, ERP не планирует. Доплатите нам немного, мы вам довнедрим, настроим, оттестируем. Есть фирма ИТРП – они для УПП реализовывали оптимизацию планирования с помощью отдельного сервера. Не знаю, повторили ли они этот опыт для ERP или нет. Во всяком случае, мы сами себе задачу поставили и решили ее. Наверное, я знаю только одну фирму, которая делала такую попытку – именно в этой области. Не в области столкновения с Preactor, где более высокие цены и другой интерфейс, а в области «навесок» к ERP.

  • В принципе, вы не считаете себя конкурентом для Preactor?

  • Нет, конечно. 

  • По вашей презентации выходит, что «пришли мы и уделали Siemens».

  • Я извиняюсь, если такое впечатление сформировалось. Тема доклада у меня обозначена скромно. Я хотел бы пояснить, что на том проекте Preactor остался, и работает все вместе. А мы предлагаем другие проекты, где Preactor можно не покупать. 

  • Я к чему говорю, у нас же сейчас импортозамещение – вроде хотелось бы импортозаместиться. Если люди привыкли к Preactor, они могут импортозаместиться с вашей помощью?

  • Мы пока себе такой цели не ставим. Если вы купили ERP и хотите использовать MES, приходите к нам, MES у вас заработает. А сделать «отечественный Preactor» мы себе цели не ставим. Мы идем по другому пути.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Vladimir Litvinenko 2235 03.03.20 11:04 Сейчас в теме
Очень интересная тема. Но не хватает хотя бы одного слайда для практиков. Например со списком объектов 1С, данные из которых экспортировались и куда они после расчёта импортировались. Если даже код на C# настолько секретный, то хоть немного технических деталей для 1С-ников не помешало бы. Чтобы прочитавший публикацию не только вспомнил о существовании генетических алгоритмов и посмотрел на котиков картинки, но и хоть немного в знаниях прокачался. Так ведь опять реклама на слайдах, хотя возможно и достигающая целевой аудитории (заказчиков).

Пока что из всех материалов только доклад от Никиты Грызлова запомнился как ценный и в закладки попал: вот теория, а вот практика. Решение не на блюдечке, но если захотите, то можете за это зацепиться и научиться чему-то полезному. Хотелось бы чуть больше такого.

Замечание не столько к автору доклада - у него много интересного (хотя и тяжело читаемого ;)) кода на Инфостарте. Скорее к тому, что большинство докладов скорее развлекательные, чем поучительные ))

сделать «отечественный Preactor» мы себе цели не ставим. Мы идем по другому пути.

Интересно, а почему не ставите такой цели? Ведь выше было написано, что
В общем-то, сделали мини-Preactor – задублировали все объекты, которые в нем есть, всю систему ограничений. Кодовая база разрослась

Почему решили не работать в этом направлении дальше, и не развивать решение в сторону отечественного аналога? Да ещё и с интеграцией с 1С, которая уже есть.
4. ildarovich 6943 04.03.20 14:48 Сейчас в теме
(1) Понял замечания насчет неудовлетворенного желания "прокачаться в знаниях" и "тяжело читаемого кода". Учту на будущее. Действительно, у этого доклада была другая задача.

Не ставим такую цель (разработать отечественный Preactor) потому что для нас это слишком масштабный проект с неопределенными коммерческими перспективами. Плагин к ERP (или Preactor) - другое дело.
2. pm74 165 03.03.20 15:33 Сейчас в теме
интересно . так вы планировали расписания сразу для всех РЦ или по ограничениям (РЦ) ?
6. ildarovich 6943 04.03.20 15:04 Сейчас в теме
(2) Сразу для всех РЦ одного подразделения. В соответствии с концепцией MES, реализованной в ERP.
3. veri123 04.03.20 10:29 Сейчас в теме
Интересно рассматривали ли вы другой подход. Кода задача на цех планируется по классике (ббв), а вот задача на конкретный рц ищется как оптимальная на текущее состояние из ходя из задач на день. То есть аналог цепи Маркова каждая задача рассчитывается как лок экстремум но мы не анализируем не прошлые не последующие задачи которые должен выполнять рц. Да красивого графика мы не построим но и вычислений в разы меньше.
5. ildarovich 6943 04.03.20 15:01 Сейчас в теме
(3) В принципе, применению этого подхода при использованию нашей разработки ничего не мешает. Она как раз так и работает. Оптимизирует на уровне цеха распределение операций по рабочим центрам и их последовательность. Тогда как состав операций на день уже определен запланированными на верхнем уровне этапами. Другое дело, что при интервале планирования "день" просроченность нет большого смысла включать в критерии.
Ну и исходить лучше не из минимизации объема вычислений (мы с ним справляемся), а из требований заказчика, который часто ждет более точных данных по срокам выполнения заказа и хочет учесть в расчетах передачу полуфабрикатов между цехами в любой момент интервала планирования, а не только в его конце.
7. veri123 04.03.20 17:48 Сейчас в теме
(5) можно по поподробнее что физически значит "хочет учесть в расчетах передачу полуфабрикатов между цехами в любой момент интервала планирования".
Просто исходя из того что постоянно происходят авралы(поломка оборудования/брак производства/обнаружение- недостача материалов) перебалансировка нагрузки на рц должна происходить постоянно(ли с каким-то мин промежутком). Плюс генетический алгоритм по своей сути хаотичен, то есть нет точной временной оценки выполнения, есть только эмпирические замеры. То есть сегодня задача расчета заняла 10 мин, а завтра 1 минуту, а после завтра пол часа в зависимости от того какую популяцию мы выбрали и как сложилось скрещивание. Хотя эти минусы наверное более надуманы чем практические.
Оставьте свое сообщение

См. также

DevOps для 1С. Онлайн-курс проходит с 16 апреля по 11 июня 2020 года. Промо

Данный онлайн-курс предусматривает изучение процессов DevOps, их применение при разработке на платформе 1С. В результате прохождения онлайн-курса вы сможете: настроить ПО необходимое для проведения проверок и тестирования, создавать сценарии тестирования и объединять их в комплексные процессы, создавать скрипты для автоматизации процессов DevOps.

12000 рублей

Делаем быстрее POSTGRESQL COUNT (*)

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    990    w.r.    1       

Простое обнаружение проблем производительности в PostgreSQL

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    2303    w.r.    4       

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    5782    a.doroshkevich    16       

Атака сервера кнопонажималкой

Статья Программист Нет файла Бесплатно (free) Нагрузочное тестирование Инструментарий разработчика

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    3622    nixel    16       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

История роста и работы команд 1С в условиях HighLoad и BigData

Статья Программист Руководитель проекта Нет файла Бесплатно (free) Автоматизация ИТ-компании Производительность и оптимизация (HighLoad)

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    5567    user826155    11       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

Набор скриптов для знакомства с SQL Server

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование СУБД

Поговорим о скриптах, которые помогут быстро ознакомиться с состоянием SQL Server, в том числе с вопросами производительности.

30.09.2019    17121    YPermitin    14       

Подбор оборудования для информационных систем на платформе 1С

Статья Системный администратор Программист Руководитель проекта Нет файла Бесплатно (free) Интеграция Производительность и оптимизация (HighLoad)

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    7229    jf2000    8       

Онлайн-интенсив "1C:Предприятие для программистов: Бухгалтерские задачи" с 22 июня по 8 июля 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, которые предназначены для решения задач бухгалтерского учета. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей прикладного решения “1С:Бухгалтерия” и прочих прикладных решений, в которых реализованы соответствующие механизмы для автоматизации бухгалтерских задач.

4900 рублей

Руководство по SQL: Как лучше писать запросы (Часть 2)

Статья Системный администратор Программист Нет файла СУБД Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    5982    w.r.    2       

Онлайн-курс «Автоматизация процессов управления МТО: методика сбора и формализации требований» с 1 апреля по 13 мая 2020 года. Промо

Цель курса - повысить полноту и качество сбора и формализации требований к автоматизации процессов управления материально-техническим обеспечением. Курс основан на процессном подходе, позволяет в полном объеме выявить и учесть все факторы, влияющие на специфику процессов управления МТО. Участники курса получают теоретические знания в области организации процессов управления МТО и готовый инструментарий для сбора и формализации требований по автоматизации этих процессов (шаблоны, опросники, модели).

40000 рублей

Руководство по SQL: Как лучше писать запросы (Часть 1)

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    8619    w.r.    19       

Иерархия без "В ИЕРАРХИИ"

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

Говорится о том, как эффективно представлять иерархию в СУБД, как получать и использовать эти представления при решении задач в запросной технике. Уточняются и дополняются запросы из статьи "Уровни, глубина, прародители, циклы и аналоги запросом" [https://infostart.ru/public/160707/].

22.08.2019    9509    ildarovich    19       

Базовый курс по обмену данными в системе 1С:Предприятие. Онлайн-интенсив с 12 по 28 мая 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, обеспечивающих обмен данными между различными прикладными 1С-решениями и взаимодействие с другими информационными системами. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”.

5500 рублей

Использование Union вместо OR

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    3018    w.r.    35       

Тюнинг производительности запросов в PostgreSQL

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    5739    w.r.    5       

Лучшие программы за прошедший месяц Промо

Инфостарт подготовил ТОП-25 самых продаваемых и популярных на текущий момент программ. При формировании списка учитывается аналитика продаж и запросы клиентов за последний месяц.

Обработчики событий при записи объектов. Зачем и что за чем?

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

Программисту, имеющему немного опыта на платформе 1С 8.3, бывает сложно разобраться: ПередЗаписью, ПриЗаписи, ПослеЗаписи, на сервере, на клиенте, в модуле формы, в модуле объекта.... Эта шпаргалка была создана в процессе обучения и реального опыта с целью разложить всё по полочкам, чтобы было четкое понимание в каком случае какой обработчик нужно использовать и в какой последовательности они запускаются при записи и проведении документов. Данная статья будет полезна в большей степени начинающим разработчикам. Но и опытным позволит освежить информацию, упорядочить её.

25.07.2019    29215    4    AlbinaAAA    25       

Как проводятся документы в типовых конфигурациях от 1С

Статья Программист Нет файла v8::ОУ ERP2 УТ11 Россия УУ Windows Бесплатно (free) Математика и алгоритмы Практика программирования Разработка

В свое время, когда только начинал шаги в 1С и изучал, как проводятся документы в конфигурациях на платформе 1С по книге "Разработка управляемого интерфейса" (Хрусталева Е.Ю.), и там были представлены примеры совсем далекие от того, как сейчас проводятся документы в современных конфигурациях от 1С.

24.07.2019    22743    skv_79    35       

Онлайн-курс «Практические аспекты внедрения регламентированного учета и расчета себестоимости в 1С:ERP на крупных промышленных предприятиях» с 20 апреля по 15 мая 2020 года. Промо

Курс рассчитан для подготовки экспертов по регламентированному учету и учету затрат для внедрения на крупных промышленных предприятиях с «исторически сложившимся» учетом

9000 рублей

Управление качеством кода

Статья Программист Руководитель проекта Нет файла v8 Бесплатно (free) Математика и алгоритмы Рефакторинг и качество кода

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019    13270    Stepa86    33       

Настройка параметров PostgreSQL для оптимизации производительности

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    5523    w.r.    13       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Сравнительное тестирование работы PostgreSQL с большими страницами Linux

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    3559    w.r.    6       

Настройка параметров ядра Linux для оптимизации PostgreSQL

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    4298    w.r.    1       

Екатеринбург.Online: Голосование продолжается Промо

Продолжается голосование за доклады на INFOSTART MEETUP Екатеринбург.Online! Лучшие из них попадут в окончательную программу онлайн-митапа! Присоединяйтесь к голосованию и покупайте билеты - 3 000 рублей за 8 часов продуктивной пятницы!

3000

Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная статья является переводом оригинальной статьи Martin Kováčik "PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE" https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

30.06.2019    5078    w.r.    2       

Создание отчетов с помощью СКД - основные понятия и элементы

Статья Программист Нет файла v8 v8::СКД Бесплатно (free) Практика программирования Математика и алгоритмы

Основные принципы работы СКД. Понятия схемы компоновки и макета компоновки. Описание основных элементов схемы компоновки: наборы данных, поля, вычисляемые поля, ресурсы, параметры.

25.06.2019    36838    ids79    17       

Базовый курс для начинающих 1С-программистов. Онлайн-интенсив со 2 июня по 2 июля 2020 г. Промо

Данный онлайн-курс является начальной ступенью по изучению базовых принципов программирования в системе “1С:Предприятие” и предназначен для обучения 1С-программированию “с нуля”.

4500-9500 рублей

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Статья Программист Нет файла v8 v8::Запросы Бесплатно (free) Практика программирования Производительность и оптимизация (HighLoad)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    19168    dmurk    144       

Выдержки из книги Чистый код

Статья Программист Нет файла Бесплатно (free) Математика и алгоритмы

Недавно я прочитал книгу "Чистый код" Роберта Мартина (Robert Cecil Martin). В ней описываются принципы организации и форматирование исходного кода программы так, чтобы в дальнейшем было легко поддерживать такой код. Эта книга является библией для многих программистов, но вот в среде программистов 1С, к сожалению, не очень распространено чтение подобной фундаментальной литературы. Книга более 400 страниц и так много порой лениво читать, да и времени всегда не хватает. По этому я решил выделить в виде цитирования по разделам самые важные моменты. А также снабдил текст своими примерами кода.

16.05.2019    8127    FreeArcher    105