Маленько увлекаюсь микроконтроллерами по вечерам. Вот здесь habr.com/ru/company/directum/blog/526838 писал, как можно совместить программирование на ассемблере + Драконовский подход к визуализации, используя Excel. В комментах там выложил ссылку на прототип.
В настоящей работе иногда приходится рисовать блок-схемы, и я всегда придерживаюсь Дракон-правил: сверху вниз, слева направо, запрет пересечений, главное по центру, второстепенное — сбоку. Редактор при этом не важен, в любой среде придерживаюсь этих правил.
согласен с замечанием частично. Прошу учесть, что эти фрагменты кода приведены как концепция самой возможности выхода из цикла (в том числе из вложенных циклов), без привязки к определенному языку. Так, например, В VBA нет команды Break — используется Exit Do, Exit For или Exit Sub. А в Pascal есть команды и Exit, и Break, но они немного о разном.
Про первое замечание. Брать по одной записи — это путь действительно не быстрый. Тут я отметил такие моменты (поделюсь собственными впечатлениями):
Начинающему разработчику RPA с отдельными ячейками Excel работать проще, чем со строчками Datatable. Сами данные и обращение к ним нагляднее: книга — лист — адрес ячейки. Медленно, но визуально и контролируемо. Datatable — это мощно и быстро в работе, но с ним надо немного поглубже познакомиться.
В данном кейсе «бутылочное горлышко» в другом месте. Медленным является графический интерфейс конечной системы: открытие карточки, сохранение, закрытие карточки. Тормозит не робот, а MS Access. Данные из Excel робот читает фоном, без графического интерфейса. Последовательно прочитать 1000 ячеек занимает меньше минуты. В общем процессе это по времени почти незаметно.
Про второе замечание. Исходники и тестовые базы вышлю — будет интересно обсудить.
Позиция «программируй всё что шевелится» не работает в сферах интеллектуального труда.
Есть две причины, почему иногда нужно «программировать все, что шевелится»:
программируй все, что шевелится — и по обратной связи найдешь 1 реально хороший кейс. И да — это будет 1 кейс из 100 вариантов/гипотез. «Программирование» здесь не столько прям прикладное и полезное, сколько исследовательское. Успешный кейс передаем в настоящую разработку и доводим его до нового работающего средства автоматизации. Неуспешные кейсы анализируем. Исследования виток за витком помогают прояснить принципы успешного кейса — так постепенно инновация превратится в технологию. Или наоборот, ляжет в стол до лучших времен.
программируй все, что в интеллектуальном труде является рутиной. Наша как ИТ-аналитиков задача — находить рутинные элементы даже в самых творческих процессах. Пример — обход электронных библиотек и выгрузка референтных источников. И снова обратная связь подскажет, правильно ли мы (ИТ) понимаем нужды пользователей.
Настоящая статья — это плод такого микроисследования. А ваше мнение, ваш комментарий — это та самая обратная связь.
Реальный обобщённый сферический научный сотрудник тратит не так много времени на снятие экспериментальных данных как описывает топикстартер, очень много времени уходит на анализ литературы, откидывание мусорных статей и книг, проработку текстов и продумывание смысла работы вообще. То же самое относится к инженерам — не поверите, но инженер большую часть времени а) чертит и обсуждает задачи и возникающие проблемы с другими инженерами б) пишет много-много отчётов и заполняет тонны бюрократических бумажек.
Так сложилось, что в проектах я всегда был частью команды, с распределением ролей. И на своем опыте бюрократии я действительно не хлебнул. Занимался как раз моделированием и расчетами, их было много.
Про анализ литературы/очистку мусора/проработку текстов — это очень интересный кейс, который пересекается с «анализом конкурентов» в бизнесе. Тема активно развивается: там можно встретить и про ИИ, и про роботов, и про статистику. И здесь мы должны разделить функции. Роботам и ИИ — обход сайтов и изданий, сбор и упорядочение информации в файловой системе, группировка, классификация, грубая сортировка. Человеку — интерпретация, анализ, обобщения, гипотезы, выводы.
Программирование очень сильно упростило жизнь в той же расчётной сфере, это я про кады-сапры-кае и прочий софт. Но программы так и не смогли заменить человеческие мозги. Руки частично заменили роботами, это да. Но, извините, никаким кадом и кае за один пресест и за время на выпить чашку кофе авиадвижок не обсчитать. Это фантазия сродни киберпанку.
Где подписаться? ))) Согласен с каждым словом! Именно так мы и понимаем круг «обязанностей» роботов, ИИ и прочих средств автоматизации. Да, ИИ и RPA — маркетингом позиционируется как некий «новый уровень». Но это новый уровень «рук», а не «мозгов».
Повторяю, я знаю людей которые считают реальное железо и сам вхожу в их число и поэтому имею право на подобную критику =)
Кости растут правильно, если есть нагрузка. Мышцы без нагрузки атрофируются. Критика со стороны профессионалов — это как нагрузка для костей и мышц. Без нее мы не сможем правильно развивать свои продукты. Критика нужна.
Я правильно понял, что в посте речь про софтину (или класс софта), которая позволяет работать в одной среде, не выгружая результаты в эксель?
RPA — это действительно класс ПО, этакое следующее поколение кликера, макроса или скрипта.
Много статей о применении в бизнесе можно найти в интернете. Еще лучше — посмотреть демонстрации на ютубе. В роликах очень наглядно на живых примерах разъясняются возможности этого рода программ.
Тогда почему бы не воспользоваться макроязыком, который по моей памяти есть и в инвенторе. Это ведь будет бесплатно и решит задачу, причем решение может юыть индивидуальным, а значит максимально автоматизированным, чего не добиться с помощью готового софта
Согласен, если речь идет об автоматизации внутри одной среды, например, Inventor. Разработчик среды заложил в нее VBA для автоматизации внутренних потребностей. По COM можем взаимодействовать из VBA и с Excel, и с другими приложениями. Во многих других средах поставщики закладывают такие возможности автоматизации.
Одна тонкость: чтобы работать в том же VBА, специалист должен знать объектную модель своей среды и объектную модель той среды, с которой завязывает взаимодействие.
C RPA переносить данные из одной среды в другую легче. Для этого используется запись действий пользователя в графическом интерфейсе. Обычно пользователь хорошо знает и графический интерфейс своих инструментов, и порядок работы.
Встроенный в Inventor и Autocad макрорекодер не записывает действия в стороннем приложении. RPA же базируется на собственной платформе, поэтому автоматизировать можно работу в любых приложениях. А на данные робот будет смотреть через GUI целевого приложения.
Не забываем и об ограничениях RPA.
Конечно, робот не построит пресс-форму по сложной детали. Также средствами RPA не получится достать данные, которые на низком уровне вычисляет геометрическое ядро.
Но он может последовательно обойти все дерево построения с целью, например, переименовать элементы в соответствии с какой-то логикой. Или затянуть в библиотеку инструментов HSM-модуля каталог фрез и резцов с рекомендуемыми режимами прямо с сайта производителя. Это рутина, и именно для рутины RPA и рассчитан.
В настоящей работе иногда приходится рисовать блок-схемы, и я всегда придерживаюсь Дракон-правил: сверху вниз, слева направо, запрет пересечений, главное по центру, второстепенное — сбоку. Редактор при этом не важен, в любой среде придерживаюсь этих правил.
Лишнее почистил. Если по коду нужны комментарии, то пишите.
Лист1 — программа на асм.
Лист3 — итоговый листинг для передачи в студию.
Про второе замечание. Исходники и тестовые базы вышлю — будет интересно обсудить.
Есть две причины, почему иногда нужно «программировать все, что шевелится»:
Настоящая статья — это плод такого микроисследования. А ваше мнение, ваш комментарий — это та самая обратная связь.
Так сложилось, что в проектах я всегда был частью команды, с распределением ролей. И на своем опыте бюрократии я действительно не хлебнул. Занимался как раз моделированием и расчетами, их было много.
Про анализ литературы/очистку мусора/проработку текстов — это очень интересный кейс, который пересекается с «анализом конкурентов» в бизнесе. Тема активно развивается: там можно встретить и про ИИ, и про роботов, и про статистику. И здесь мы должны разделить функции. Роботам и ИИ — обход сайтов и изданий, сбор и упорядочение информации в файловой системе, группировка, классификация, грубая сортировка. Человеку — интерпретация, анализ, обобщения, гипотезы, выводы.
Где подписаться? ))) Согласен с каждым словом! Именно так мы и понимаем круг «обязанностей» роботов, ИИ и прочих средств автоматизации. Да, ИИ и RPA — маркетингом позиционируется как некий «новый уровень». Но это новый уровень «рук», а не «мозгов».
Кости растут правильно, если есть нагрузка. Мышцы без нагрузки атрофируются. Критика со стороны профессионалов — это как нагрузка для костей и мышц. Без нее мы не сможем правильно развивать свои продукты. Критика нужна.
RPA — это действительно класс ПО, этакое следующее поколение кликера, макроса или скрипта.
Много статей о применении в бизнесе можно найти в интернете. Еще лучше — посмотреть демонстрации на ютубе. В роликах очень наглядно на живых примерах разъясняются возможности этого рода программ.
Согласен, если речь идет об автоматизации внутри одной среды, например, Inventor. Разработчик среды заложил в нее VBA для автоматизации внутренних потребностей. По COM можем взаимодействовать из VBA и с Excel, и с другими приложениями. Во многих других средах поставщики закладывают такие возможности автоматизации.
Одна тонкость: чтобы работать в том же VBА, специалист должен знать объектную модель своей среды и объектную модель той среды, с которой завязывает взаимодействие.
C RPA переносить данные из одной среды в другую легче. Для этого используется запись действий пользователя в графическом интерфейсе. Обычно пользователь хорошо знает и графический интерфейс своих инструментов, и порядок работы.
Встроенный в Inventor и Autocad макрорекодер не записывает действия в стороннем приложении. RPA же базируется на собственной платформе, поэтому автоматизировать можно работу в любых приложениях. А на данные робот будет смотреть через GUI целевого приложения.
Не забываем и об ограничениях RPA.
Конечно, робот не построит пресс-форму по сложной детали. Также средствами RPA не получится достать данные, которые на низком уровне вычисляет геометрическое ядро.
Но он может последовательно обойти все дерево построения с целью, например, переименовать элементы в соответствии с какой-то логикой. Или затянуть в библиотеку инструментов HSM-модуля каталог фрез и резцов с рекомендуемыми режимами прямо с сайта производителя. Это рутина, и именно для рутины RPA и рассчитан.