Entry tags:
Параллели…
…между программированием и эволюцией. :)
Нашёл тут своё старое письмо, кусочком которого хочется поделиться. Писал своему смежнику. О чём речь: есть две системы, в каждой из которых орудует по взаимодействующему друг с другом роботу. Интерфейс между роботами специфицирован, а что и как каждый делает в своей системе — это их личное дело. Тамошнему проще — ему нужно из своей базы забрать наряды, сформировать пакет согласно спецификации и предоставить второму роботу. Тому немного сложнее, так как получить наряды, зарегистрировать, отметить выполнение и вернуть обратно ответ — самое простое дело. Хитрее — выполнить эти наряды в станции. Хитрость заключается в том, что система открытая и может возникнуть множество непредвиденных ситуаций. Станция — штука достаточно сложная. И софт под неё писали очень много людей. А я один и пишу робота, который должен (в идеале) делать свою работу, оставаясь в области предсказуемости станции, а в случае выхода станции из этой зоны, попытаться вернуть диалог обратно. Система эта работает не первый год, а если быть точным, то лет эдак 12-13 и за это время несколько раз кардинально менялась и совершенствовалась. Сейчас, кстати, снова назрела необходимость всё переделывать. Но до тех пор пока не появился новый робот, старого нужно сопровождать. :)
Итак: ответ смежнику по поводу трабла, который заключался в том, что небольшое количество нарядов выполнялось "в час по чайной ложке". Спровоцировала проблему пачка некорректных нарядов, когда абоненту дважды подключали услугу. Станция ругалась: "а она уже активна!" (на своём языке), а робот её не понимал. Ну не может робот (написанный одним человеком) знать в совершенстве язык станции (софт которой писала не одна сотня человек), который рассчитан в первую очередь на восприятие живого гуманоида.
Нашёл тут своё старое письмо, кусочком которого хочется поделиться. Писал своему смежнику. О чём речь: есть две системы, в каждой из которых орудует по взаимодействующему друг с другом роботу. Интерфейс между роботами специфицирован, а что и как каждый делает в своей системе — это их личное дело. Тамошнему проще — ему нужно из своей базы забрать наряды, сформировать пакет согласно спецификации и предоставить второму роботу. Тому немного сложнее, так как получить наряды, зарегистрировать, отметить выполнение и вернуть обратно ответ — самое простое дело. Хитрее — выполнить эти наряды в станции. Хитрость заключается в том, что система открытая и может возникнуть множество непредвиденных ситуаций. Станция — штука достаточно сложная. И софт под неё писали очень много людей. А я один и пишу робота, который должен (в идеале) делать свою работу, оставаясь в области предсказуемости станции, а в случае выхода станции из этой зоны, попытаться вернуть диалог обратно. Система эта работает не первый год, а если быть точным, то лет эдак 12-13 и за это время несколько раз кардинально менялась и совершенствовалась. Сейчас, кстати, снова назрела необходимость всё переделывать. Но до тех пор пока не появился новый робот, старого нужно сопровождать. :)
Итак: ответ смежнику по поводу трабла, который заключался в том, что небольшое количество нарядов выполнялось "в час по чайной ложке". Спровоцировала проблему пачка некорректных нарядов, когда абоненту дважды подключали услугу. Станция ругалась: "а она уже активна!" (на своём языке), а робот её не понимал. Ну не может робот (написанный одним человеком) знать в совершенстве язык станции (софт которой писала не одна сотня человек), который рассчитан в первую очередь на восприятие живого гуманоида.
Полечил робота. Раньше, если он от станции получал нестандарный ответ, то пытался
исполнить команду несколько раз и если они тоже были неудачными, то плевал на наряд.
Но при этом на наряде оказывалась отметка о закрытии с неуспешным выполнением, а
в причине кривое описание. Когда дошли руки, я научил его распознавать и эти
нестандартные ответы. А заодно научил оформлять отметку как положено, с настоящей
причиной — той, которую даёт станция. Но вместе с новым умением роботу была привита
новая особенность... ну, собственно, потому что новая возможность была получена
методом "горизонтального переноса генов". При не успешном выполнении команды робот
прекращал выполнение следующей команды (для данного наряда, если такая имелась). В
алгоритме просто выходил из цикла. Но вот, блин, "ген" в новом месте оказался в
"другом окружении" и выходить из цикла стал уже другого — цикла перебора
невыполненных нарядов. Как итог - при встрече с неуспешным нарядом роботпадал напросто завершал работу. Вот так
пол, впадал в истерику и отказывался работать
робот-холерик превратился в робота-меланхолика. :)
Раньше это не обнаружилось, потому что проверялся изменённый алгоритм на
выполнение наряда с неуспешным результатом. Проверял — работало корректно. А то, что
после него могут быть ещё наряды, которые он "забыл" выполнить, мне и в голову не
приходило. Не обнаруживалось это, естественно, потому что такие наряды до сих пор
попадались очень редко. А если попадались, то следующий запуск робота работает как
лоботомия — робот спокойненько выполняет остальные наряды. Сейчас засада случилась
из-за того что таких нардяв с неуспешным закрытием пришло сразу много. 1 неуспешный
— 5 минут задержка, 12 — час, 167 (select count(*)*5/60 from orders where
operation='код плохого наряда' and result='NO') — почти 14 часов.