наконец-то собрался и сделал обзор UiPath с чуть более технической стороны, чем в этой статье. Вдруг кому интересно — прошу
alpaev.com/uipath-overview
UiPath и используем. У нас не было выбора, выбор сделали до нас :)
ой, забыл ещё пару пунктов написать:
— на мой взгляд разработка этих процессов происходит медленнее, чем разработка/поддержка аналогичного кода на любом языке/инструменте. Таскание вот этих прямоугольников, работа с их настройками занимают больше времени, чем написать аналогичный код
— сейчас мне надо написать довольно большой кусок кода чисто на Visual Basic, чтобы вызывать его потом из UiPath, для этого я не могу использовать сам UiPath, приходится пользоваться студией. Так что не могу назвать UiPath Studio полноценной IDE
работаю сейчас с этим UiPath. Более неудобного инструмента не видел. Да, разработчики приложили максимум усилий, чтобы облегчить жизнь пользователям, однако в целом он остается весьма неудобным. Вот несколько примеров:
— нерациональное использование рабочего пространства. Одна инструкция типа вывода строки в лог (Log Message) по высоте занимает места как
— к этому же можно отнести способ представления информации. Если в том же Log Message выводишь длинную строку, её всю просто не увидишь на экране, так как её длина ограничена небольшим прямоугольничком
— закомментированная инструкция помещается внутрь другого прямоугольника, в результате занимая в 2 раза больше места; закомментировать несколько инструцкий одновременно невозможно
— слабые возможности отладки (нет аналога watch list\evaluate, невозможно увидеть текущие значения аргументов (не переменных, а именно аргументов))
— в случае исключения невозможно быстро перейти на то место, где исключение возникло (например, кликнув по сообщению в логе), приходится искать вручную
— организация доступа к общему «коду» в виде пакетов тоже неудобна, особенно если возникает ошибка где-то внутри, отлаживать просто нереально (я пробовал включать опцию Include Sources при создании пакета, никакого эффекта)
— невозможность переименовать скриншоты, дать им осмысленные имена
— формат файлов XAML. Ну, тут понятно, что лучше бы это был код (пусть даже на том же Visual Basic), но есть и другие нюансы. Например, git считает эти файлы бинарями
— отсутствие Application Map, селекторы прописываются для каждой инструкции отдельно
— не совсем пока понятно, как работать с кастомными элементами управления. Например, у нас есть .NET Desktop приложение, там кастомный комбобокс, UiPath не может применить для него Select Item. Наверное, можно как-то дернуть нативный метод, но я пока не знаю, как
— ещё с десяток мелочей, которые сейчас просто не вспомню
Есть и плюсы, конечно, но как по мне, их маловато по сравнению с минусами:
— много готовых Activity, которые хорошо работают «из коробки» (например, работа с Excel порадовала, поддержка нескольких способов для OCR)
— много Activity, которые создают участники сообщества
— с изображениями UiPath работает быстро, тоже радует
Если кто знает, как решить какие-то из проблем, которые я описал выше, буду рад услышать
да, приходилось. Негативных не было, обычно позитивные + просьба какая-то. Но это редко происходит, может раз в год примерно
Ааа, ну да, так и есть. Но тут нуж ничего не поделаешь. Думаю, авторы типа Мартина Фаулера могут диктовать свои условия (например, прописывать в контракте обязательный доступ к статистике магазинов наравне с издательством), но про это я ничего не знаю
Тиража нет, конечно. Что значит «как обстоят дела»? Люди покупают, издательство раз в квартал присылает отчет: сколько куплено бумажных копий, сколько электронных, сколько итого отчислений автору. Или в чём вопрос?
Меня в почте попросили дать ссылки на хабрахабр и аин, в которых описываются истории написания книг. Оставлю тут
habrahabr.ru/post/212719
ain.ua/...dlya-krupnogo-izdatelstva
Тю, конечно помню, мы ж недавно тут в комментах ещё общались :)
Так у Мартина Фаулера консалтинг — основная работа в ThoughtWorks, отсюда и такой богатый и разносторонний опыт. Выступления и книги — сторонняя деятельность, да
А мне вот очень не нравится, как некоторые HRы стучатся в скайп. Они просто присылают запрос на добавление в контакты. Для меня это выглядит так: неизвестный человек пишет «Добрый день, я бы хотел(а) добавить вас в список контактов». И всё. Зачем? Почему? Кто вы? Неплохо, если в Contact Info указано, что рекрутер из такой-то компании.
Я в таких случаях пишу в ответ только «?».
Однажды вообще клиника была. Постучалась вот так одна гражданочка в пятницу вечером. Привычно написал в ответ знак вопроса, немного поработал, потом домой пора. Прихожу в понедельник, вижу неизвестный контакт, смотрю — так и не ответила за выходные, ну, думаю, спамбот какой-нить. И только собирался сделать Block — Report Spam, как пишет: «Ой, я вас в пятницу добавила НА БУДУЩЕЕ и ушла домой». Ну, класс.
Но в целом должен сказать, что в большинстве случаев я доволен работой HRов. За 14 лет работы в АйТи я не помню ни одного случая, после которого мне бы захотелось написать подобную статью :)
людям всегда хочется чего-то большего...
Например, после работы в SoftServe (где мы с тобой в одной команде работали), я ушел в проект, где до этого была жуткая текучка (дольше полугода большинство не задерживались). Но я там проработал 5 лет, и ещё несколько человек тоже проработали несколько лет.
Думаю, что любой заказчик хочет видеть свою контору такой неотразимой, где люди захотят работать всю свою жизнь. Наверное, это какой-то психологический эффект
да, но заказчику продать проще так, как я написал, по-моему :)
исходя из чего?
Исходя из того, что
человек знаком с менеджерами только по рассказам с печальным концомэто то же самое, фактически, что и
либо им не повезло
А такие вбросы — удел тупых людей или ботов, которые тоже по сути тупы.
В общем, вернулись снова на Дерибасовскую :)
Люди, которые так говорят, либо очень тупые, либо им не повезло.
За 13 лет работы работал со многими менеджерами, ни одного бесполезного, только положительные впечатления.
Вот вы тут смеётесь...
А в Днепре есть такая контора PFSoft. Там такие гороскопы директор составляет и на основании этих гороскопов решения принимает.
Ну, джуниор вакансий вообще не так уж много всегда, я говорил в целом про разработчиков, не только про джуниоров
А, и ещё. Тестер — это же не конечный пункт назначения. Один мой знакомый из тестера стал QA лидом, а со временем ПМом, такие дела.
Отличная ссылка, спасибо!