Для того, чтобы хоть как-то отнестись к тому или иному решению — нужен бекграунд и детали.
Если у нас есть реальная потребность (включенная в план разработки) обмениваться информацией с веб-сайтом, у этого веб-сайта имеется открытое (в идеале документированное) API — естественно, такой коллега «получит по шапке».
Но есть другая ситуация, которых очень много по разным компаниям:
«Наша система» разработана полностью в соответствии с исходным планом/потребностями компании, но у нас есть один отдел, где у сотрудников появилась потребность (которой раньше не было) выгружать данные из «нашей системы», проводить с ними какую-то манипуляцию, загружать в другую систему/веб-сайт (или наоборот).
Казалось бы — есть опытные разработчики, которые могут автоматизировать данную работу для наших сотрудников, вот только есть нюансы:
У внешнего веб-сайта нет открытого API (или есть/можно получить по партнерке, но недокументированный)
Отдел разработки перегружен задачами, свободное «окно» для данной автоматизации — через 2-3 месяца
Нужны компетенции не только в обмене данными с внешним веб-сайтом, но и в обработке данных, прямо как это делают сотрудники
Каждый из перечисленных пунктов замедляет/откладывает процесс автоматизации. Отдельным пунктом стоит то, что на разработку с тестированием, приемкой — уйдет примерно 2-4 недели работы программиста в лучшем случае.
А если мы воспользуемся роботами? Разработчик может прийти к сотруднику, включить средство записи действий UiPath, сотрудник выполнит свой порядок действий за несколько минут, расскажет про нестандартных ситуации… Разработчик возьмет записанный процесс, воспроизведет на своем компьютере, отладит его с учетом нестандартных ситуаций и уже к вечеру того же дня сможет показать сотруднику как робот делает его работу. Само собой, может понадобиться дополнительная отладка с учетом «я еще вспомнил» от сотрудника, но она пройдет довольно быстро, за еще 1-2 дня.
Вот тут мы уже включаем инженера, который не только «гайки крутит», но и экономику считает. И когда мы уже сравниваем условные 3 человеко-дня разработки робота против 10-20 человеко-дней разработки программного кода, то вывод напрашивается сам собой — наш коллега большой молодец. Вместо того, чтобы заниматься этой не очень то критичной проблемой месяц, он сделал ее за 3 дня и теперь может решить еще штук 5 таких же проблем до конца месяца.
Тут, к слову, важно понимание, что роботы — это не затычка для 1-2 задач, это полноценный инструмент для решения вот таких вот проблем с рутиной у сотрудников. Там, где разработка программного кода выходит дороже, чем выгода от этой разработки — спасают именно роботы, так как настраиваются они быстрее, и возврат инвестиций происходит так же в более короткие сроки.
Это бесспорно очень хороший инструмент для экосистемы 1С. Вот только вопрос — насколько он хорошо работает за рамками 1С? Когда надо роботизировать множество других приложений/систем, каждое из которых написано по своему (одно на Java, другое web, третье WPF, четвертое winapi, и вдобавок 1С). Ведь в этом, в общем-то, и сила RPA — возможность связать несвязуемое (или то, на связывание чего через программный код уйдет в лучшем случае половина года).
Спасибо за такой комментарий, было интересно прочитать ваши сомнения по поводу RPA. На самом деле, с такими сомнениями приходится периодически сталкиваться, так что постараюсь помочь вам избавиться от них:
а вот иметь компетенции в скриптовании GUI — тоже надо и это тоже не бесплатно, и не понятно где их искать.
…
По факту, учитывание контекста для UI скриптов, занимает столько сил и требует неординарного ума, что гораздо проще написать всё это в коде напрямую, либо постоянно скрипт находится в нерабочем состоянии, потому что-то ещё не учли.
Действительно, технологий и решений, которые предоставляют возможность именно скрпитования GUI очень много и они, как правило, требуют определенных компетенций — не могу с вами не согласиться. Однако, обращу ваше внимание еще раз на то, что в статье идет речь про RPA, а это уже гораздо больше, чем «скриптование/кликер GUI». И особенно когда речь идет про UiPath.
Тут стоит отметить, что вся настройка робота осуществляется в графическом виде. При чем есть два режима:
Профессиональный, где интерфейс чуть посложнее и более удобен проф. разработчикам;
Для бизнес-пользователей (в статье это «citizen developers»), в котором все максимально упрощено на столько, что даже далекие от айти люди могут делать своих роботов.
И второй режим позволяет взять вашего специалиста, который прекрасно знает свою работу, обучить его (1-2 дня) и дать ему самому настроить робота, который будет делать за него его работу. Конечно, в особо сложных процессах нужна поддержка профессионального разработчика, но вовсе не обязательно, чтобы это был дорогой специалист с огромным опытом. Помимо прочего, если в компании есть IT-специалист, он может пройти бесплатно 1-недельный онлайн курс и стать полноценным RPA-разработчиком (имеются дополнительные углубленные курсы, но это уже по желанию, при необходимости).
основной недостаток этих вещей, это отсутствие чёткой обратной связи, соответственно, такая программа может продолжить работать, хотя какой-то этап был пропущен или сглючил, в этом случае обычная программа остановится с ошибкой, а
Данное замечание нерелевантно для UiPath, о котором идет речь. Если робот не может найти нужную кнопку или не получил отклика от кнопки (не смог нажать), не нашел поля, надписи, или вообще не может определить нужное окно — возникнет ошибка. Эту ошибку можно обработать соответствующим try/catch блоком (да, в графическом режиме он тоже имеется), или же сделать глобальный обработчик ошибок. В общем это уже детали, но главное — дальше робот (сам) не пойдет и вбивать данные «в молоко» не будет.
То есть, лезет — трогает, требует контроля, имея теже админские права, что и человек, которому доверили делать комплексные дела в программе.
Важно понимание, что робот — это не программа, которую написали на каком-то языке программирования, а эмулятор человека. Само собой, если у сотрудника, которого он эмулирует, имеется доступ к разным особо чувствительным функциям систем — теоретически робот тоже сможет ими пользоваться. Вот только как робота настроили — так он и работает, никаких шагов влево-вправо. Как указал выше — любое несоответствие ожидания-реальности ведет к возникновению ошибки и остановке выполнения процесса (с уведомлением админов).
Когда же мы программно работаем с API или пишем напрямую в базу данных — сохраняется вероятность того, что мы что-то упустим или недоделаем (если у нас нет высоких компетенций именно в данном API). В случае с роботами — мы не можем случайно пропустить работу с каким-то окном или полем, так как мы просто повторяем все операции за человеком, который делает это каждый день. Единственное, что может пойти не так — это когда этот человек забывает о «редком документе, который приходит раз в месяц, вот его надо еще через другое окошко регистрировать». Но такие случаи и при классической разработке встречаются довольно часто, так что это в целом проблема аналитики, а не разработки.
Например, такая задача: создаём документ, сохраняем, переоткрываем переносим в него данные по полям из старого (без функционала «скопировать»), старый документ удаляем.
Странный кейс, если он происходит внутри одной системы. Предположу, что мы говорим о том случае, когда у вас есть документ в одной системе (допустим, клиент оставил заявку на вашем сайте) и на его основании надо сделать аналогичный документ в другой системе (или сразу нескольких системах), в нашем случае — в 1С.
Если такие действия обычно производятся человеком и результат его работы является корректным, то робот, который будет выполнять те же самые действия, что и человек — даст вам 100%-ый результат.
Если же это совсем новая задача/процесс, в котором у вас нет эксперта и у вас имеются прекрасные компетенции в программировании, вы прекрасно знаете API целевой системы — однозначно вы справитесь быстрее, чем если будете применять роботизацию. Но если вы не знаете API, не знаете как все внутри устроено, не уверены, что разные типы документов структурированы одинаково… Как показывает моя практика — изучение всей внутренней кухни какой-либо системы занимает в самом лучшем случае пару дней, но обычно это неделя, а в особых случаях — можно и месяц (суммарно) «убить» на изучение всех тонкостей. А еще надо написать код, отладить, желательно автотесты еще написать и прогнать их.
Настроить робота для такой задачи займет не больше дня (если считать именно разработку с авто-тестами, отладкой, прогоном на тестовом контуре; без них будет быстрей).
Однако, программистов 1С очень много и они не сильно дороги, что бы это было каким-то существенным препятствием
Здесь скорее речь о тех случаях, когда у вас все же нет такого человека в штате, брать человека в штат ради одной задачи странно, а нанимать фрилансера — небезопасно (кто будет поддерживать?), а иногда взаимодействие с фрилансерами может быть заблокировано договорными отношениями с интегратором (обращаться к нему по этой задаче будет дольше и дороже, чем роботизировать).
PS: Предлагаю вам зайти на сайт UiPath и скачать бесплатно комьюнити-версию полноценного продукта. Пройдите стартовый курс (займет не больше 4-х часов) и зацените сами на сколько это более удобное решение, чем «скриптинг GUI», с которым, как я понял, вам приходилось сталкиваться.
Обратите внимание на то, что речь идет про роботизацию, а не программирование. Постараюсь объяснить детальнее, чтобы вам было понятней:
Когда у вас есть компетенции 1С-программиста (или есть такой человек в штате), у вас есть доступ к конфигуратору (не закрытый интегратором), и все, что вам нужно автоматизировать — это только 1С, тогда действительно — вам легче будет написать код в 1С, который будет делать все, что вам нужно.
Когда у вас нет экспертизы в разработке на 1С, нету доступа к редактированию кода, а процесс, который вы хотите автоматизировать, включает в себя не только работу с 1С, но и с другими системами (у которых может не быть внятного API) — возникает вопрос «как мне это сделать?». Ответ прост — использовать роботов (RPA). Вам не нужно быть экспертом в программировании, все что вам нужно — это просто показать роботу как делает свою работу человек: «Открыть 1С, Нажать сюда, потом сюда, ввести данные в эти поля, забрать значение отсюда, открыть другую систему, нажать туда, ввести сюда, итд».
И робот будет делать тоже самое. Робот не лезет ни в какие API, не трогает ваши базы данных, не требует от вас создания и контроля за техническими учетными записями — он просто работает с теми же программами, что и человек.
И вроде все прекрасно, но есть один нюанс — если роботы отлично справляются с большинством приложений/систем/сайтов, то вот с 1С возникают нюансы. И как учитывать эти нюансы — рассказано в данной статье. Надеюсь, теперь для вас более понятен смысл и посыл статьи.
Полезная статья для новичков, кто, возможно, будет иметь такие проблемы. Как уже отметили другие «старички» — действительно, странно использовать оператор .? в foreach
Единственное, что я бы исправил — это как записан блок
if (collection != null)
{
foreach (var item in collection.Where(predicate))
Console.WriteLine(item);
}
А точнее применение фигурных скобок. Отталкиваясь от стиля, заданного изначально, если внутри цикла одно действие — мы не ставим фигурных скобок, я бы опустил этот момент и в условии, в результате получилось бы:
if (collection != null)
foreach (var item in collection.Where(predicate))
Console.WriteLine(item);
Получилось бы визуально более коротко, и еще проще, чем в варианте с ?? Enumerable.Empty()
там работает какой-то хитрый алгоритм (вот, кстати, его описание было бы круто увидеть на хабре), который умеет более-менее различать корпоративную работу и нет.
Во-первых, если запускать его с серверной винды — он почти сразу детектирует коммерческое использование. Так же у меня есть подозрение, что он может «видеть», что в подключении к «клиентской» винде есть доп подключение (по RDP) к серверной.
Еще, судя по всему, идет проверка по Pro-версии винды (но тут только догадки).
Ну и по крайней мере раньше отслеживалась интенсивность использования. Если работать несколько часов подряд, но редко — это «норм». Но если ты по чуть чуть подключаешься часто (в день по несколько раз и так всю неделю) — это уже явный сигнал, что ты коммерческий пользователь.
И вот когда детектируется, что пользователь коммерческий — врубается та самая блокировка «5 минут на использование»
Действительно, раньше такая проблема была, но она же уже решена. Не скажу за другие платформы, но у UiPath есть как минимум возможность сделать тесты в Pro-версии студии. А как максимум — полноценный продукт Test Suite, который позволяет автоматизировать тестирование при изменении роботизируемых программ/систем/сайтов. Вы же не выкатываете на продуктив сразу новые версии своих ПО? Наверняка сначала прогоняете их на тестовом контуре. Вот натравите на тот же тестовый контур Test Suite, и получите сразу результат — где именно ломаются роботы. Дальше поправить — дело техники (если, конечно, у вас адекватная структура проектов и используете git/svn/tfs)
Похоже, у вас устаревшие понимания того «что такое RPA». Конечно, если вы познакомились с RPA лет 5 назад (или ограничились отечественными разработками) — я могу понять ваше мнение.
Действительно, раньше RPA можно было сравнить с чем-то вроде Windows 1: «Вроде прикольная красивая штука, но бесполезная». Но не сегодня. Особенно если мы говорим про лидеров рынка, в частности про UiPath.
Потому что, наверное, речь идет про программных роботов/ботов (RPA)? Если впервые слышите про такую технологию — рекомендую прочитать остальные статьи с аккаунта RPAconsultant
Я еще года с 2008 начал покупать только лицензионные игры. И тогда уже было четко на каждом диске написано — может вызывать эпилептические припадки.
Думаю, что в киберпанке это тоже где-нибудь в сведениях об игре есть.
что вы понимаете под «обменом сообщениями»? В C#, например, можно «кидать» события. Один объект подписывается на другой и получает как раз сообщения от него. То есть объект класса А просто сообщает «Произошло событие Х!», а уже все кто подписался на это — получают «сообщение» об этом и при необходимости обрабатывают.
давайте-ка дернем тот перегруженный в производном классе сеттер
У вас очень извращенное наизнанку понятие ООП-разработки. Всё ровно наоборот. Методы/функции перегружаются в наследуемых классах как раз для того, чтобы их автоматом вызывались в методах классов, которые и знать не знают про нашу новую реализацию в виде унаследованного класса.
вы сами же себе противоречите. Берете для сравнения книгу по одной технологии и пытаетесь ее сравнить с некой абстрактной книгой сразу по четырем технологиям (добавляя еще разные технологии).
Рост количества технологий и их сложность прямиком зависит от пользовательского спроса. Когда-то были времена, когда компьютерами пользовались преимущественно ученые — тогда было достаточно расчетов, производимых с помощью ассемблера. Но когда-то это было? Потом же это все начало трансформироваться в Аду, Б, СИ, и множество-множество других языков, каждый из которых уже посложнее ассемблера. Но не просто так ради забавы, а для того, чтобы зная технологию можно было сравнительно просто и быстро реализовать то, что было тяжело на Ассемблере (не исключая возможность этого).
Все познается в сравнении. Я, будучи студентом, делал на ассемблере крестики-нолики в графическом режиме. И они работали прекрасно. Но есть одно НО — я их писал примерно неделю по вечерам + убил один выходной день, чтобы отладить все глюки.
Точно такие же крестики нолики в то же время я мог написать на Borland C++ 3.1 меньше, чем за один час.
Дополняя примеры — на своей первой работе я писал одну программу на чистом С + WinAPI. Полностью на разработку я потратил 1.5 месяца. Программа до сих пор работает, справляется с большим массивом информации — всё, вроде бы, круто. За исключением одного НО. Когда я установил в первый раз Visual C# 2010 и поковырялся в нем с недельку, чтобы изучить как что работает — я написал ту же самую программу на C# за два дня. Она имела тот же самый функционал. Да, она потребляет теперь чуть больше ресурсов, но в конечном итоге «не-бизнес» кода меньше, скорость разработки — выше. Так что это палка о двух концах всегда.
Тоже самое по вебу — я в конце 00-х делал простые сайтики, которые в целом даже могли котироваться. Сегодня — это курам на смех. За полдня современными технологиями можно сделать гораздо круче, чище и надежнее, чем то, что я делал месяц тогда. И оно того стоит.
А раньше, чтобы писать программы — вам надо было обязательно знать внутреннее устройство процессора, как идет взаимодействие с кэшами, оперативной памятью, дисками. Поверьте — это все гораздо сложнее (если вы этого не застали сами).
Ну и кто вам сказал, что сегодня нет «простых» языков? Прости господи, да тот же Visual Basic до сих пор жив — вы можете на нем писать «без всех этих классов» до сих пор (а можете с классами). Хотите — можете использовать VBS.
Ладно, это шутка в целом, но есть же, в конце концов, JavaScript, Python и всякие другие языки, в которых вовсе не обязательно думать о классах, абстракции и всем таком, что вы называете сложностью
Ого-го. Вот это заявления. Какую именно культуру портит ООП?
Конечно, если стоит задача «по быстрому накидать код, чтобы получить результат здесь и сейчас, но нам не надо, чтобы это работало годами» — да, ООП в целом избытычен.
Но когда речь идет про энтерпрайз, где написанное должно отрабатывать ну хотя бы лет пять, и чтобы можно было легко подменять модули без необходимости вычитывать всё — ООП прекрасная концепция. Как говориться — к каждой задаче нужен свой инструмент. И если вы работаете в сфере, где ООП действительно избыточен — это не значит, что за соседней стенкой не может быть задачи, которую без ООП решить проблематично.
Автор поста слишком однобоко судит. Я вот считаю, что тот человек, который хотя бы не мечтает во снах стать знаменитым, великим — не имеет какой-либо цели в жизни.
Любовь к программированию мне привил отец с детства совершенно случайно показав как делать программы в MS Access (мне было тогда лет 12, на дворе был 2002 год, у нас даже Интернета не было). Я сам начал делать программки разные, более игровые. И тогда моим кумиром был Билл Гейтс — человек, благодаря которому я работал в Windows и пользовался таким замечательным инструментом, как MS Access.
Сказать, что я не мечтал о его богатстве — будет наглой ложью. Но помимо этого я так же мечтал сделать что-то великое и прекрасное, что будет НУЖНО человечеству, полезно людям вокруг. И уже именно благодаря этому стать богатым. Так что ставить здесь четкую границу между желанием сделать что-то крутое и стать богатым — минимум недальновидно.
Далее — что касается «продажников». Как я уже написал — айти я занимаюсь со школьных лет, с 12. Профессионально работаю с 2010-го. И вот я уже встретил моральную усталость от этого всего — меняются языки, фреймворки, компании вокруг… А по сути, глобально, мы (программисты) делаем одни и те же программы с циклом 3-5 лет. Просто берем и замещаем «уже устаревшие системы на старых фреймворках» новыми системами, которые по сути и делают тоже самое (само собой чуть лучше, но все же).
И вот благодаря этой усталости я сам стал больше смещаться к менеджерству + продажничеству в частности. Вот в настоящий момент я являюсь пре-сейлом. То есть и на продажи гоняю, и программированием занимаюсь. Но чисто психологически я понимаю, что продажи — это очень большая наука, которая интересна и еще неизведана лично для меня. И думаю, что в ближайшей перспективе продолжу перекатываться именно туда.
А теперь представим, что лет через 5 я вообще перестану программировать. Будет ли это значит, что я перестану быть совсем программистом? С учетом 20+ летнего опыта «за спиной»?..
Вот примерно тоже самое, в частности, касается многих ребят из видео Дудя (да и не только). Это люди, которые съели вагон собак на программировании и теперь представляют об этой области даже больше, чем мы с вами, как бы нам это не казалось странным. Так что я бы не стал их судить…
Вы это знаете сегодня в 2019-ом… Ну дай бог «тремя курсами юридического» — может быть где-то из конца 2000-х/начала 10-х в лучшем случае.
Я прекрасно помню и застал ту эпоху, когда в целом подобный опенсорс поощрялся разными работодателями (даже далекими от уровня тогдашнего Рамблера). И так же помню, как постепенно начали закручивать гайки по этой теме, было несколько знакомых, которых засудили за то, что они разработали уникальное решение в рамках одного проекта и выложили его на GitHub. Решение в целом не касалось разработки самого проекта, а скорее было плюсом, облегчающим жизнь всем другим программистам. Было это где-то в 2011-2013, уже точно не помню. Но точно помню, что тогда (по крайней мере для моего тогдашнего айти-окружения) это было чем-то диким и сродни абсурду.
Так что, думаю, Игорь в начале 2000-х и подумать такого не мог, что кто-то его через 20 лет нагнет…
слепая вера в то, что «все другие дураки, а вот я белый пушистый и смогу поднять айти в родной стране!».
К сожалению, сам был окутан таким мышлением, с большой радостью даже пошел в одну около-гос компанию, где нам навешали лапши про то, что мы будем менять мир… В итоге по три месяца без зарплаты сидели там )))
К сожалению, отрезвляющий душ иногда нужен. Очень надеюсь, что ребят не «закроют», а то совсем это всё грустно и печально…
Интересно узнать у автора (или у тех, кто как и он переезжал) — по поводу именно поиска работодателя. В частности момент с Языки: английский и немецкий (последний дает кучу бонусов на месте, но при поиске работы в ИТ не важен.). Я про это читал не только в этой статье, но и много где, в том числе и всякие блогеры об этом вещают…
Вот только сейчас я сам в процессе подготовки трактора в Германию, перебираю кучу вакансий — и, грубо говоря, в 95% знание немецкого стоит как обязательное требование. Конечно, я наверное мало еще ищу (2-3 недели)… Кстати, тоже вопрос по временным рамкам — кто как долго искал?
*Те, кого лично приглашали знакомые — не в счет.
А вы почитали статью УК РФ, на комментарий со ссылкой на которую ответили? Там же все четко написано. Вот, специально выделил самый сок:
"Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации"
То есть — да, является. Программа из одной команды — тоже программа. Программа, содержащая команду «del C:\Windows», которая будет выполнена с повышенными правами без ведома пользователя — заведомо предназначена для несанкционированного уничтожения компьютерной информации
Если у нас есть реальная потребность (включенная в план разработки) обмениваться информацией с веб-сайтом, у этого веб-сайта имеется открытое (в идеале документированное) API — естественно, такой коллега «получит по шапке».
Но есть другая ситуация, которых очень много по разным компаниям:
«Наша система» разработана полностью в соответствии с исходным планом/потребностями компании, но у нас есть один отдел, где у сотрудников появилась потребность (которой раньше не было) выгружать данные из «нашей системы», проводить с ними какую-то манипуляцию, загружать в другую систему/веб-сайт (или наоборот).
Казалось бы — есть опытные разработчики, которые могут автоматизировать данную работу для наших сотрудников, вот только есть нюансы:
Каждый из перечисленных пунктов замедляет/откладывает процесс автоматизации. Отдельным пунктом стоит то, что на разработку с тестированием, приемкой — уйдет примерно 2-4 недели работы программиста в лучшем случае.
А если мы воспользуемся роботами? Разработчик может прийти к сотруднику, включить средство записи действий UiPath, сотрудник выполнит свой порядок действий за несколько минут, расскажет про нестандартных ситуации… Разработчик возьмет записанный процесс, воспроизведет на своем компьютере, отладит его с учетом нестандартных ситуаций и уже к вечеру того же дня сможет показать сотруднику как робот делает его работу. Само собой, может понадобиться дополнительная отладка с учетом «я еще вспомнил» от сотрудника, но она пройдет довольно быстро, за еще 1-2 дня.
Вот тут мы уже включаем инженера, который не только «гайки крутит», но и экономику считает. И когда мы уже сравниваем условные 3 человеко-дня разработки робота против 10-20 человеко-дней разработки программного кода, то вывод напрашивается сам собой — наш коллега большой молодец. Вместо того, чтобы заниматься этой не очень то критичной проблемой месяц, он сделал ее за 3 дня и теперь может решить еще штук 5 таких же проблем до конца месяца.
Тут, к слову, важно понимание, что роботы — это не затычка для 1-2 задач, это полноценный инструмент для решения вот таких вот проблем с рутиной у сотрудников. Там, где разработка программного кода выходит дороже, чем выгода от этой разработки — спасают именно роботы, так как настраиваются они быстрее, и возврат инвестиций происходит так же в более короткие сроки.
Действительно, технологий и решений, которые предоставляют возможность именно скрпитования GUI очень много и они, как правило, требуют определенных компетенций — не могу с вами не согласиться. Однако, обращу ваше внимание еще раз на то, что в статье идет речь про RPA, а это уже гораздо больше, чем «скриптование/кликер GUI». И особенно когда речь идет про UiPath.
Тут стоит отметить, что вся настройка робота осуществляется в графическом виде. При чем есть два режима:
И второй режим позволяет взять вашего специалиста, который прекрасно знает свою работу, обучить его (1-2 дня) и дать ему самому настроить робота, который будет делать за него его работу. Конечно, в особо сложных процессах нужна поддержка профессионального разработчика, но вовсе не обязательно, чтобы это был дорогой специалист с огромным опытом. Помимо прочего, если в компании есть IT-специалист, он может пройти бесплатно 1-недельный онлайн курс и стать полноценным RPA-разработчиком (имеются дополнительные углубленные курсы, но это уже по желанию, при необходимости).
Данное замечание нерелевантно для UiPath, о котором идет речь. Если робот не может найти нужную кнопку или не получил отклика от кнопки (не смог нажать), не нашел поля, надписи, или вообще не может определить нужное окно — возникнет ошибка. Эту ошибку можно обработать соответствующим try/catch блоком (да, в графическом режиме он тоже имеется), или же сделать глобальный обработчик ошибок. В общем это уже детали, но главное — дальше робот (сам) не пойдет и вбивать данные «в молоко» не будет.
Важно понимание, что робот — это не программа, которую написали на каком-то языке программирования, а эмулятор человека. Само собой, если у сотрудника, которого он эмулирует, имеется доступ к разным особо чувствительным функциям систем — теоретически робот тоже сможет ими пользоваться. Вот только как робота настроили — так он и работает, никаких шагов влево-вправо. Как указал выше — любое несоответствие ожидания-реальности ведет к возникновению ошибки и остановке выполнения процесса (с уведомлением админов).
Когда же мы программно работаем с API или пишем напрямую в базу данных — сохраняется вероятность того, что мы что-то упустим или недоделаем (если у нас нет высоких компетенций именно в данном API). В случае с роботами — мы не можем случайно пропустить работу с каким-то окном или полем, так как мы просто повторяем все операции за человеком, который делает это каждый день. Единственное, что может пойти не так — это когда этот человек забывает о «редком документе, который приходит раз в месяц, вот его надо еще через другое окошко регистрировать». Но такие случаи и при классической разработке встречаются довольно часто, так что это в целом проблема аналитики, а не разработки.
Странный кейс, если он происходит внутри одной системы. Предположу, что мы говорим о том случае, когда у вас есть документ в одной системе (допустим, клиент оставил заявку на вашем сайте) и на его основании надо сделать аналогичный документ в другой системе (или сразу нескольких системах), в нашем случае — в 1С.
Если такие действия обычно производятся человеком и результат его работы является корректным, то робот, который будет выполнять те же самые действия, что и человек — даст вам 100%-ый результат.
Если же это совсем новая задача/процесс, в котором у вас нет эксперта и у вас имеются прекрасные компетенции в программировании, вы прекрасно знаете API целевой системы — однозначно вы справитесь быстрее, чем если будете применять роботизацию. Но если вы не знаете API, не знаете как все внутри устроено, не уверены, что разные типы документов структурированы одинаково… Как показывает моя практика — изучение всей внутренней кухни какой-либо системы занимает в самом лучшем случае пару дней, но обычно это неделя, а в особых случаях — можно и месяц (суммарно) «убить» на изучение всех тонкостей. А еще надо написать код, отладить, желательно автотесты еще написать и прогнать их.
Настроить робота для такой задачи займет не больше дня (если считать именно разработку с авто-тестами, отладкой, прогоном на тестовом контуре; без них будет быстрей).
Здесь скорее речь о тех случаях, когда у вас все же нет такого человека в штате, брать человека в штат ради одной задачи странно, а нанимать фрилансера — небезопасно (кто будет поддерживать?), а иногда взаимодействие с фрилансерами может быть заблокировано договорными отношениями с интегратором (обращаться к нему по этой задаче будет дольше и дороже, чем роботизировать).
PS: Предлагаю вам зайти на сайт UiPath и скачать бесплатно комьюнити-версию полноценного продукта. Пройдите стартовый курс (займет не больше 4-х часов) и зацените сами на сколько это более удобное решение, чем «скриптинг GUI», с которым, как я понял, вам приходилось сталкиваться.
Когда у вас есть компетенции 1С-программиста (или есть такой человек в штате), у вас есть доступ к конфигуратору (не закрытый интегратором), и все, что вам нужно автоматизировать — это только 1С, тогда действительно — вам легче будет написать код в 1С, который будет делать все, что вам нужно.
Когда у вас нет экспертизы в разработке на 1С, нету доступа к редактированию кода, а процесс, который вы хотите автоматизировать, включает в себя не только работу с 1С, но и с другими системами (у которых может не быть внятного API) — возникает вопрос «как мне это сделать?». Ответ прост — использовать роботов (RPA). Вам не нужно быть экспертом в программировании, все что вам нужно — это просто показать роботу как делает свою работу человек: «Открыть 1С, Нажать сюда, потом сюда, ввести данные в эти поля, забрать значение отсюда, открыть другую систему, нажать туда, ввести сюда, итд».
И робот будет делать тоже самое. Робот не лезет ни в какие API, не трогает ваши базы данных, не требует от вас создания и контроля за техническими учетными записями — он просто работает с теми же программами, что и человек.
И вроде все прекрасно, но есть один нюанс — если роботы отлично справляются с большинством приложений/систем/сайтов, то вот с 1С возникают нюансы. И как учитывать эти нюансы — рассказано в данной статье. Надеюсь, теперь для вас более понятен смысл и посыл статьи.
Единственное, что я бы исправил — это как записан блок
А точнее применение фигурных скобок. Отталкиваясь от стиля, заданного изначально, если внутри цикла одно действие — мы не ставим фигурных скобок, я бы опустил этот момент и в условии, в результате получилось бы:
Получилось бы визуально более коротко, и еще проще, чем в варианте с ?? Enumerable.Empty()
Вот, сделал трудную работу за вас, нашел вам для примера применение данного термина у Gartner: www.gartner.com/en/information-technology/glossary/citizen-developer
Или для вас Gartner — это не ориентир? Если так — все-таки зайдите в гугл и убедитесь, что это вполне себе устоявшийся термин.
Во-первых, если запускать его с серверной винды — он почти сразу детектирует коммерческое использование. Так же у меня есть подозрение, что он может «видеть», что в подключении к «клиентской» винде есть доп подключение (по RDP) к серверной.
Еще, судя по всему, идет проверка по Pro-версии винды (но тут только догадки).
Ну и по крайней мере раньше отслеживалась интенсивность использования. Если работать несколько часов подряд, но редко — это «норм». Но если ты по чуть чуть подключаешься часто (в день по несколько раз и так всю неделю) — это уже явный сигнал, что ты коммерческий пользователь.
И вот когда детектируется, что пользователь коммерческий — врубается та самая блокировка «5 минут на использование»
Похоже, у вас устаревшие понимания того «что такое RPA». Конечно, если вы познакомились с RPA лет 5 назад (или ограничились отечественными разработками) — я могу понять ваше мнение.
Действительно, раньше RPA можно было сравнить с чем-то вроде Windows 1: «Вроде прикольная красивая штука, но бесполезная». Но не сегодня. Особенно если мы говорим про лидеров рынка, в частности про UiPath.
Думаю, что в киберпанке это тоже где-нибудь в сведениях об игре есть.
Так что очень странно читать содержимое статьи.
У вас очень извращенное наизнанку понятие ООП-разработки. Всё ровно наоборот. Методы/функции перегружаются в наследуемых классах как раз для того, чтобы их автоматом вызывались в методах классов, которые и знать не знают про нашу новую реализацию в виде унаследованного класса.
Рост количества технологий и их сложность прямиком зависит от пользовательского спроса. Когда-то были времена, когда компьютерами пользовались преимущественно ученые — тогда было достаточно расчетов, производимых с помощью ассемблера. Но когда-то это было? Потом же это все начало трансформироваться в Аду, Б, СИ, и множество-множество других языков, каждый из которых уже посложнее ассемблера. Но не просто так ради забавы, а для того, чтобы зная технологию можно было сравнительно просто и быстро реализовать то, что было тяжело на Ассемблере (не исключая возможность этого).
Все познается в сравнении. Я, будучи студентом, делал на ассемблере крестики-нолики в графическом режиме. И они работали прекрасно. Но есть одно НО — я их писал примерно неделю по вечерам + убил один выходной день, чтобы отладить все глюки.
Точно такие же крестики нолики в то же время я мог написать на Borland C++ 3.1 меньше, чем за один час.
Дополняя примеры — на своей первой работе я писал одну программу на чистом С + WinAPI. Полностью на разработку я потратил 1.5 месяца. Программа до сих пор работает, справляется с большим массивом информации — всё, вроде бы, круто. За исключением одного НО. Когда я установил в первый раз Visual C# 2010 и поковырялся в нем с недельку, чтобы изучить как что работает — я написал ту же самую программу на C# за два дня. Она имела тот же самый функционал. Да, она потребляет теперь чуть больше ресурсов, но в конечном итоге «не-бизнес» кода меньше, скорость разработки — выше. Так что это палка о двух концах всегда.
Тоже самое по вебу — я в конце 00-х делал простые сайтики, которые в целом даже могли котироваться. Сегодня — это курам на смех. За полдня современными технологиями можно сделать гораздо круче, чище и надежнее, чем то, что я делал месяц тогда. И оно того стоит.
Ну и кто вам сказал, что сегодня нет «простых» языков? Прости господи, да тот же Visual Basic до сих пор жив — вы можете на нем писать «без всех этих классов» до сих пор (а можете с классами). Хотите — можете использовать VBS.
Ладно, это шутка в целом, но есть же, в конце концов, JavaScript, Python и всякие другие языки, в которых вовсе не обязательно думать о классах, абстракции и всем таком, что вы называете сложностью
Конечно, если стоит задача «по быстрому накидать код, чтобы получить результат здесь и сейчас, но нам не надо, чтобы это работало годами» — да, ООП в целом избытычен.
Но когда речь идет про энтерпрайз, где написанное должно отрабатывать ну хотя бы лет пять, и чтобы можно было легко подменять модули без необходимости вычитывать всё — ООП прекрасная концепция. Как говориться — к каждой задаче нужен свой инструмент. И если вы работаете в сфере, где ООП действительно избыточен — это не значит, что за соседней стенкой не может быть задачи, которую без ООП решить проблематично.
Любовь к программированию мне привил отец с детства совершенно случайно показав как делать программы в MS Access (мне было тогда лет 12, на дворе был 2002 год, у нас даже Интернета не было). Я сам начал делать программки разные, более игровые. И тогда моим кумиром был Билл Гейтс — человек, благодаря которому я работал в Windows и пользовался таким замечательным инструментом, как MS Access.
Сказать, что я не мечтал о его богатстве — будет наглой ложью. Но помимо этого я так же мечтал сделать что-то великое и прекрасное, что будет НУЖНО человечеству, полезно людям вокруг. И уже именно благодаря этому стать богатым. Так что ставить здесь четкую границу между желанием сделать что-то крутое и стать богатым — минимум недальновидно.
Далее — что касается «продажников». Как я уже написал — айти я занимаюсь со школьных лет, с 12. Профессионально работаю с 2010-го. И вот я уже встретил моральную усталость от этого всего — меняются языки, фреймворки, компании вокруг… А по сути, глобально, мы (программисты) делаем одни и те же программы с циклом 3-5 лет. Просто берем и замещаем «уже устаревшие системы на старых фреймворках» новыми системами, которые по сути и делают тоже самое (само собой чуть лучше, но все же).
И вот благодаря этой усталости я сам стал больше смещаться к менеджерству + продажничеству в частности. Вот в настоящий момент я являюсь пре-сейлом. То есть и на продажи гоняю, и программированием занимаюсь. Но чисто психологически я понимаю, что продажи — это очень большая наука, которая интересна и еще неизведана лично для меня. И думаю, что в ближайшей перспективе продолжу перекатываться именно туда.
А теперь представим, что лет через 5 я вообще перестану программировать. Будет ли это значит, что я перестану быть совсем программистом? С учетом 20+ летнего опыта «за спиной»?..
Вот примерно тоже самое, в частности, касается многих ребят из видео Дудя (да и не только). Это люди, которые съели вагон собак на программировании и теперь представляют об этой области даже больше, чем мы с вами, как бы нам это не казалось странным. Так что я бы не стал их судить…
Я прекрасно помню и застал ту эпоху, когда в целом подобный опенсорс поощрялся разными работодателями (даже далекими от уровня тогдашнего Рамблера). И так же помню, как постепенно начали закручивать гайки по этой теме, было несколько знакомых, которых засудили за то, что они разработали уникальное решение в рамках одного проекта и выложили его на GitHub. Решение в целом не касалось разработки самого проекта, а скорее было плюсом, облегчающим жизнь всем другим программистам. Было это где-то в 2011-2013, уже точно не помню. Но точно помню, что тогда (по крайней мере для моего тогдашнего айти-окружения) это было чем-то диким и сродни абсурду.
Так что, думаю, Игорь в начале 2000-х и подумать такого не мог, что кто-то его через 20 лет нагнет…
К сожалению, сам был окутан таким мышлением, с большой радостью даже пошел в одну около-гос компанию, где нам навешали лапши про то, что мы будем менять мир… В итоге по три месяца без зарплаты сидели там )))
К сожалению, отрезвляющий душ иногда нужен. Очень надеюсь, что ребят не «закроют», а то совсем это всё грустно и печально…
Вот только сейчас я сам в процессе подготовки трактора в Германию, перебираю кучу вакансий — и, грубо говоря, в 95% знание немецкого стоит как обязательное требование. Конечно, я наверное мало еще ищу (2-3 недели)… Кстати, тоже вопрос по временным рамкам — кто как долго искал?
*Те, кого лично приглашали знакомые — не в счет.
"Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации"
То есть — да, является. Программа из одной команды — тоже программа. Программа, содержащая команду «del C:\Windows», которая будет выполнена с повышенными правами без ведома пользователя — заведомо предназначена для несанкционированного уничтожения компьютерной информации