Для государственных учреждений - вполне себе нормальный перечень требований. Когда я начинал свою карьеру в 2009 году в качестве техника в одном ГосНИИ, это был минимальный набор, который надо было знать и уметь делать. И как студент-отличник третьего курса университета - я вполне себе это все умел делать.
Когда я после ГосНИИ перешел в конце 2012 в коммерческую организацию - очень долго не понимал как это порой берут джунов без этой всей базы, а получают они больше. чем я раньше получал в НИИ. Но, к сожалению вот такая вот у нас практика.
Поэтому многие толковые, талантливые ребята уходят из НИИ так же, как в свое время ушел я - на зарплату x3 и требования / 4 (делить на четыре)
Пошел перепрочел несколько источников по терминологии, во многих упоминается в том числе то, что:
Задача специалиста — создать продукт, который удовлетворит потребности пользователей и принесёт компании прибыль.
То есть не отменяя то, что есть задача принести финансовые результаты своей компании, все же закрыть потребности заказчиков тоже нужно.
В целом мне вообще трудно представить как эти две стороны можно отделить друг от друга - как в прицнипе возможно принести прибыль продуктом, если он не приносит ценности конечным заказчикам? Кто же будет платить деньги за такой продукт. Возможно, в каких-то сферах такое возможно, но, по крайней мере в B2B я о таком не слышал никогда.
А вот прочитав концепцию DM вполне себе вижу применимость на своей же практике - не всегда с точки зрения продукта мне как менеджеру продукта стоит "ломать его" ради удовлетворения одного (пусть очень дорогого) заказчика. Другой вопрос, что его хотелки можно удовлетворить альтернативными методами. Например, в том числе в своем продукте для него сделать кастомный модуль именно для этого заказчика (и тех, кто захочет такой же модуль), но чтобы 100 других заказчиков не почувствовали на себе изменений и продолжили счастливую жизнь без этого кастома.
Во время прочтения всей статьи не мог поверить своим глазам - читаю практически про себя. А я работаю менеджером продукта, но не только в стратегии, а и в том, что перечислено в этой статье (так же забочусь о команде, помогая в этом владельцу продукта).
Добавил:
Почитал быстро статейки в "западных интернетах" и увидел, что в целом роли пересекающиеся, но все же Product Manager - чуть шире (что так же соответствует моей работе).
Грубо говоря, Delivery Manger отвечает за конкретную поставку конкретному заказчику (или пулу похожих заказчиков), а Product Manager отвечает за поставку всему разнообразию заказчиков и решает конфликты приоритетов и пожеланий. Понравилось описание, что Product отвечает за "портфель поставок".
То есть в целом корректно, что я "распознал" себя. Меня можно, получается, и Delivery, и Product менеджером звать.
Спасибо больше за ностальгическую статью. Я один из тех извращенцев, которые одинаково любят и тройку и четверку. В свое время четверка стала действительно глотком свежего воздуха после уже слегка поднадоевшей тройки.
Мне очень нравился этот сказочный стиль - та самая нотка, которую создатели игры потеряли при переходе со второй части на третью (во второй как раз тоже была подобная "сказка" и когда появилась тройка, помню мы с братом долго плевались на то, что она "слишком серьезная"). Ну а музыка - просто наслаждение, до сих пор в плейлисте для расслабления стоит.
И да, эта фишка с отдельно перемещающимися существами - мне очень зашла, тем более что играя еще в двойку и тройку я постоянно задавался вопросом "Почему существа не могут ходить отдельно от героя?". Понятно со всякими орками и нежитью - хорошо, они.неорганизованные, но с представителями Замка и Оплота - казалось, что они должны быть дружными и иметь возможность жить и действовать без лидера.
А еще больше мне зашло то, что в один отряд можно было поставить нескольких героев - вот это вообще была пушка-бомба! Учитывая то, что как раз перед четверкой я играл активно в Might & Magic 8, где ходил тоже отрядом героев, я прям представлял себе схожие истории, только уже в стратегическом режиме от третьего лица. Я тогда очень сильно заботился о каждом персонаже, продумывал его персональное развитие и это мне очень сильно нравилось, выделяя игру перед тройкой.
Ну, раз просите подводные камни, то... Заваривайте чаек, присаживайтесь на топчан и слушайте :-)
Проблема №1 - "Питон программисты" Питон программистов много, это факт... Но в разрезе программирования RPA-решений картина выглядит довольно печально. Прям профи-профи в этой сфере не так то много, а те, кто не супер-профи, с высокой долей вероятности пишут в разных стилях и применяют разные подходы. Как итог - наняв нового программиста вы получите целое приключение с его адаптацией (или через месяц обнаружите, что старые программисты не могут поддерживать робота от новичка)
Проблема №2 - "ОпенСорс" Любимая мантра всех опенсорсников - "Это октрытый код, ты сам как программист можешь исправить ошибку, никакого вендорлока. А еще ты уверен, что нет никаких дыр, так как сообщество ух как старается". По факту эти розовые очки разбиваются о то, что именно те проблемы, которые получите вы - никто другой не встретит (или их это не будет волновать как вас). При попытке залезть в исходный код опенсорса вы потратите кучу времени и сил, и с высокой долей вероятнсти даже если получится устранить баг - можно сгенерировать себе новые.
Как обратная ситуация - злоумышленники могут проанализировать опенсорс решения, которые вы используете, найти в нем дыры и воспользовавшись ими получить несанкционированный доступ к памяти ваших роботов, отправив все самы важные циферки из важных документиков в недружественные страны
Проблема №3 - "Масштабирование эксплуатации" Действительно, на планке примрено до 10 роботов - играться в простенькие решения, которые написаны самостоятельно, это прикольно. Но как только у вас начинается опыт с десятком роботов, которые работают на десятках машин под парой десятков учетных записей... Контролировать этот "Зоопарк" теми же опен сорс средствами становится крайне проблематично. Легко упустить ошибки в работе одного конкретного робота на одной конкретной учетке, легко упустить то, что расписания запуска перестали работать и так далее.
В целом можно еще ворох проблем дать вам, но, по классике остановимся на раз-два-три.
В заключении хочется донести простую мысль - Отдавая деньги вендору за лицензии вы в первую очередь покупаете свое время, которое не потратите на решение очень многих сложных проблем. За вас их уже либо решили, либо помогут решить, когда окажется, что эта проблема касается только вас.
Обычно я и мои партнеры использовали 2-4 ядра и 4-8 гб оперативки, и особых проблем не испытывали.
Здесь в гайде не перечислен один дистрибутив, который мы так же ставили, но он вызвал проблемы - Ubuntu. Судя по всему, с ней что-то не так, потому что ее оболочки (что через установку ubuntu-desktop, что через установку gnome) тормозят и ведут себя именно так, как вы написали.
Если у вас проблемы с дистрибутивами, которые перечислены выше - скорее всего проблема где-то на уровне качества Интернет-соединения. Можно для контроля попробовать подключиться с заниженным разрешением экрана и цветностью, как правило это решает проблему плохой связи.
Цель данной публикации - сделать централизованный единый хороший гайд.
У каждого человека свое представление о прекрасном, и лично в моем представлении хороший гайд должен содержать всю информацию, достаточную для достижения вполне конкретной поставленной цели без отсылания человека на прочтение информации на других ресурсах по ссылкам.
Собственно говоря, точно таким же способом как и вы, я мог ограничить гайд просто ссылками на вики всех дистрибутивов, но... Тогда это был бы не гайд, его нельзя было бы распечатать и идти по нему гарантировано достигнув цели.
И самоцели обеспечить безопасность в создании виртуального рабочего места под короткие задачи - у меня не было. Но если вы составите такой гайд, который будет универсален и без ссылок, я обязательно его присоединю. Если вам это не интересно - честно, мне тоже. Предлагаю дальше не тратить наше общее время на демагогию
Да, про "Tunneling RDP over SSH" не случилось по той причине, что в кейсах, где этот гайд применяли - он был не нужен. Инцидентов взлома зафиксировано не было.
Как указал в самой статье - если у вас есть компетенции и навыки настройки под разные дистрибутивы "с нуля" - поделитесь, обязательно добавлю в статью с упоминанием вашего профиля.
Что касается MATE - тот образ, который используется в Яндекс.Облаке, не дал мне возможности установить эту оболочку "из коробки" без добавления дополнительных репозиториев. А KDE дал. Именно поэтому в статье написал именно так, как вы процитировали.
Не называть это VDI - ваше право, не буду спорить. То, что есть специалисты, которые используют такие стенды на регулярной основе с долговременным хранением там данных - моя реальная практика, в смысле из того что наблюдал "за спиной" у других.
Правильно ли это или вредно и плохо? Отдельный вопрос для хорошего холивара, участвовать в котором не вижу большого смысла.
Что-то странное. У меня ни на винде, ни стандартная сборка для линукса не глючат и работают прекрасно. Можете поделиться историями где что у вас не работало, чтобы я мог подготовиться?
Если что, я использую Криптопро в сочетании с руТокеном в основном для входа и работы с ФНС, реже подписываю файлы.
Где все эти освободившиеся после ухода зарубежных компаний крутые специалисты, про обилие которых тут только самое ленивое эйчар-агентство не тиснуло статью, не особо понятно…
Надо понимать две вещи:
1) Не все специалисты, работавшие в западных компаниях - высококлассные. Порой даже в каких-нибудь "задрипанных" НИИ с ЗП 20к в месяц специалисты сильнее, чем в ушедших компаниях.
2) Действительно сильные специалисты, как правило, мало ищут работу "в открытую". У них есть своя база знакомых в разных других хороших компаниях и их буквально приглашают лично на очень хорошие ставки. То есть вероятность того, что на вашу вакансию сам собой откликнется действительно классный спец из ушедшей из России компании - стремиться к нулю.
В целом статья - это хорошая шпаргалка начинающему управленцу, но вот заголовок и вступление, конечно, слишком кликбейтные и не совсем перекликаются с тем, что оставляет статья после прочтения.
Наверное, статью будет приятно почитать обычным программистам, дизайнерам и прочим ребятам, кто занимается непосредственно "ручной работой" в разработке и не занимал руководящих должностей хотя бы уровня тим-лида продолжительное время.
Если же читать эту статью с точки зрения человека, кто так или иначе руководит командами несколько лет, то она читается примерно так (переводя на язык программистов):
Надо в коде писать комментарии. Если однажды начать их писать не так хорошо, то в результате на них забьют. И будет бардак в коде
Надо пользоваться системами контроля версий с gitflow. Если все вести в одной ветке - это плохо.
Ну и так далее (я конечно утрирую, но все же).
Искренне желаю каждому обычному разработчику побывать в шкуре управленца - это очень сильно меняет мировоззрение и подход к разработке как таковой. Даже если окажется, что "управление - не мое" (среди моих знакомых примерно 90% ушло из управления примерно такой фразой), то вернувшись к бытью обычным разработчиком качественно поменяется подход к задачам, их оценке и ответственность за исполнение. Ну а эта статья, как уже написал выше - довольно неплохо показывает слабые места, с которыми все так или иначе встречаются.
Ничего не могу сказать хорошего или плохого про песочницу, так как сам из нее вышел очень давно, но ограничение (минимальное или максимальное) в 3000 знаков не должно являться сильным препятствием для изложения мыслей.
Опять же, не хочу вас никак оскорбить, просто дать дружеский совет. Для вашего общего понимания - как и в научной литературе, так в целом и на хабре (да и не только) статья - это не просто мысль, выкинутая в цифровой океан безумия. Статья обычно ставит некий вопрос, освещает некую проблему и предлагает либо теоретические, либо практические методы ее решения. Еще прекрасно, если статья содержит хоть какие-то выводы (из разряда - попробовал, вышло хорошо или не очень), но это уже суть каждого дела индивидуальная.
Обращаясь к вашей статье - на самом деле даже без опускания в глубокие дебри вы и правда описываете очень обширную и знакомую, пожалуй, каждому проблему. Проблема команды - когда она собирается в удачной конфигурации, то может горы свернуть, но через какое-то время она распадается.
И вроде бы вы даже пытаетесь указать на причину, но опять же - ничего не предлагаете для ее решения. Ведь самый логичный вопрос после прочтения вашей статьи: "А как можно избавиться от этой проблемы, или хотя бы максимально отсрочить этот момент?" - и вы не даете даже намека на ответ.
Хотя даже я, вообще не специалист в психологии, но человек который участвовал и даже немного руководил разными командами, мог бы дать несколько мыслей и рекомендаций тем, кто ищет ответ на этот вопрос. Хотя бы банальнейшее "Разбавляйте команду новыми людьми, прощайтесь со старыми хотя бы на время отправив в долгий отпуск". Но это я, простофиля в психологии, а вот автора с таким багажом знаний как у вас, все же хочется услышать более интересные и неочевидные ответы.
Совершенно непонятно что хотел сказать автор и какой вывод стоит сделать.
В целом ощущение, что автор прочитал книжку по психологии (или послушал одну лекцию) и просто скопировал сюда материал никак его не переработав и не адаптировав для публики, которая не в контексте изучаемого автором предмета. В итоге получился рассказ из разряда "Утром солнышко встает, днем макушку нам печет, ну а вечером ложится спать пора"
Желаю автору в будущем стараться больше раскрывать материал, разбавлять примерами и познакомиться с хоть какой структурой, чтобы было сразу ясно - зачем эта статья, в чем именно проблема и как с ней бороться. Все что есть сейчас в статье - это только описание проблемы, но не сказано чем она плоха и как с ней бороться.
Как же забавно, ностальгически и одновременно грустно читать было эту статью. Казалось бы, 2022 год на дворе - такие то технологии, модные словечки аля Docker, Load Balancer и все такое... А проблемы все те же самые, что мы с коллегами решали на заре моей карьеры лет 13 назад.
Только тогда бэкграунд проблемы был немного другой. Дано: Множество предприятий по нашей необъятной стране, программные модули весом почти "АЖ В ГИГАБАЙТ", на удаленных концах дай бог диалап кое-как работает 2 часа в день. То есть возможности регулярно обновлять модули на предприятиях не было, и в результате каждое могло работать со своей версией.
А самый прикол был в том, что эти самые предприятия должны были синхронизироваться - получать актуальные данные друг от друга, делалось это через единый центральный сервер. Каждый установленный модуль в удобное для сетевой нагрузки время отправлял свои новые данные и забирал другие с сервера.
И там были точно такие же проблемы - одно предприятие использовало прошлогоднюю версию, где какие-то данные лежали в одном поле одной строчки таблицы, а на другом предприятии стояла самая свежая версия, где эти данные были вынесены в отдельную таблицу построчно.
Для решения таких проблем нам приходилось писать специальные преобразователи. Они получали данные от старых версий и преобразовывали их в формат последней версии. И наоборот - для отправки на старые версии преобразовывали данные из нового формата в старый, определенной версии того предприятия, которое запрашивало обновления.
Можно, через передачу информации по сессии. Точнее схема такая:
1) Делаем авторизацию через скоуп подключения к браузеру
2) Через параметр SessionData получаем информацию о сессии, эта информация передается в виде строки, ее можно сохранить в хранилище, чтобы использовать в последующих тестах
3) В тесте, где нужно использовать эту сессию - загружаем параметр SessionData
Более подробно про методы получения и загрузки данных о сессии можно прочесть в документации:
time.sleep - это из примера Selenium, к дальнейшему рассказу про UiPath никакого отношения он не имеет. Там есть свои методы ожидания реакции, не требующие настройки таймеров. Что касается Selenium - даже если вы знаете как обходиться без time.sleep там, вы большой молодец, что не отменяет проблемы с удобством восприятия кода, где идет указание на элементы, с которыми идет работа в стиле div>div>div>div
Надежность тестов полностью зависит от поддержки их актуальности. Если вы доработаете/переработаете функционал, который проверяет тест, и при этом не заложите в тесты новых ожидаемых результатов - естественно, тест будет выдавать ложные результаты.
В случае, если вы держите тесты в порядке, они всегда содержат корректный порядок действий, содержат согласованный набор входных данных с ожиданием согласованного результата - они никогда вас не подведут.
Естественно, под "никогда" я имею ввиду, что вы не будете умышленно пытаться вмешаться в тестирование роботом. Например, принудительно закрывать приложения, которые тестирует робот, отключать Интернет тогда, когда робот тестирует ресурс в Интернете. В этих случаях робот обязательно сообщит об ошибках во время выполнения тестов.
В прочем, если вы получите в отчете о тестировании результат "Ошибка, нет доступа к ресурсу" - это тоже тот случай, когда нужно обратить внимание на тестируемый ресурс. А если вы понимаете "ну да, пропадал Интернет" - просто перезапускаете тесты (можно сделать выборку по проваленным и запустить только их).
Плюс в том, что вы можете автоматизировать ручное тестирование одинаково для Windows, Web и мобильных приложений. А еще важно то, что вы можете сделать тест бизнес-процесса, где участвует сразу несколько приложений.
Например, вы можете проверить, что после загрузки клиентом документа на сайт - сведения об этом появляются во внутренней CRM (например, в SAP). С помощью инструмента, про который рассказано в этой статье, данный тест можно написать за несколько минут, при этом не нужно быть ни разработчиком веб-решения, ни разработчиком/интегратором CRM. Если вы мне расскажете каким еще способом можно написать такой тест при условии, что автор теста не умеет программировать SAP - я буду вам очень признателен и с удовольствием ознакомлюсь с материалами.
Конечно, если у вас только web, который вы пишете сами - использовать указанный в статье инструмент может быть слегка Overkill. Но здесь статья скорее обращена к тем, кто:
1) Помимо Web делает Windows-приложения (вы будете удивлены, но таких еще очень много)
2) Не обладают компетенциями в selenium и подобных средствах
Нет смысла смешивать разные виды тестирования в одном инструменте..
Приношу свои извинения, если где-то в статье выразился некорректно. Автотесты на программном уровне должны быть написаны в той среде разработки, в которой вы создаете ваши приложения. В статье речь идет именно про ручное тестирование. Это может показаться странным, но я знаю немало компаний, где сидят целые отделы ручных тестировщиков, которые весь день занимаются тем, что просто кликают мышкой по очередным сборкам систем и заносят отчеты в Jira или аналогичное ПО. Можете считать, что целевой аудиторией этой статьи являются именно такие компании и команды. Если вас не затрагивает эта проблема - я искренне рад за вас и даже немножко завидую (без иронии и сарказма).
но поддержка, решение проблем и коммьюнити?
Как и у любого серьезного инструмента (а инструмент, названный в статье - серьезный), существует как общемировое комьюнити (форум), официальная поддержка, так и несколько российских комьюнити. И дабы не быть обвиненным в рекламе - на самом деле есть множество других RPA решений, в том числе отечественных, которые активно развиваются как в плане качества, так и в плане поддержки и комьюнити. Просто инструмент, про который я рассказал в статье - лично мне нравится больше всего и им я пользуюсь уже года два с большим удовольствием.
Возможно, вы немного запутались. Это статья на моей персональной странице хабра про мою частную практику, не относится ни к какому корпоративному блогу. Точно так же, как есть много статей, написанных частными специалистами про многие другие технологии, которыми они пользуются.
Для государственных учреждений - вполне себе нормальный перечень требований. Когда я начинал свою карьеру в 2009 году в качестве техника в одном ГосНИИ, это был минимальный набор, который надо было знать и уметь делать. И как студент-отличник третьего курса университета - я вполне себе это все умел делать.
Когда я после ГосНИИ перешел в конце 2012 в коммерческую организацию - очень долго не понимал как это порой берут джунов без этой всей базы, а получают они больше. чем я раньше получал в НИИ. Но, к сожалению вот такая вот у нас практика.
Поэтому многие толковые, талантливые ребята уходят из НИИ так же, как в свое время ушел я - на зарплату x3 и требования / 4 (делить на четыре)
Пошел перепрочел несколько источников по терминологии, во многих упоминается в том числе то, что:
То есть не отменяя то, что есть задача принести финансовые результаты своей компании, все же закрыть потребности заказчиков тоже нужно.
В целом мне вообще трудно представить как эти две стороны можно отделить друг от друга - как в прицнипе возможно принести прибыль продуктом, если он не приносит ценности конечным заказчикам? Кто же будет платить деньги за такой продукт. Возможно, в каких-то сферах такое возможно, но, по крайней мере в B2B я о таком не слышал никогда.
А вот прочитав концепцию DM вполне себе вижу применимость на своей же практике - не всегда с точки зрения продукта мне как менеджеру продукта стоит "ломать его" ради удовлетворения одного (пусть очень дорогого) заказчика. Другой вопрос, что его хотелки можно удовлетворить альтернативными методами. Например, в том числе в своем продукте для него сделать кастомный модуль именно для этого заказчика (и тех, кто захочет такой же модуль), но чтобы 100 других заказчиков не почувствовали на себе изменений и продолжили счастливую жизнь без этого кастома.
Во время прочтения всей статьи не мог поверить своим глазам - читаю практически про себя. А я работаю менеджером продукта, но не только в стратегии, а и в том, что перечислено в этой статье (так же забочусь о команде, помогая в этом владельцу продукта).
Добавил:
Почитал быстро статейки в "западных интернетах" и увидел, что в целом роли пересекающиеся, но все же Product Manager - чуть шире (что так же соответствует моей работе).
Грубо говоря, Delivery Manger отвечает за конкретную поставку конкретному заказчику (или пулу похожих заказчиков), а Product Manager отвечает за поставку всему разнообразию заказчиков и решает конфликты приоритетов и пожеланий. Понравилось описание, что Product отвечает за "портфель поставок".
То есть в целом корректно, что я "распознал" себя. Меня можно, получается, и Delivery, и Product менеджером звать.
Спасибо больше за ностальгическую статью. Я один из тех извращенцев, которые одинаково любят и тройку и четверку. В свое время четверка стала действительно глотком свежего воздуха после уже слегка поднадоевшей тройки.
Мне очень нравился этот сказочный стиль - та самая нотка, которую создатели игры потеряли при переходе со второй части на третью (во второй как раз тоже была подобная "сказка" и когда появилась тройка, помню мы с братом долго плевались на то, что она "слишком серьезная"). Ну а музыка - просто наслаждение, до сих пор в плейлисте для расслабления стоит.
И да, эта фишка с отдельно перемещающимися существами - мне очень зашла, тем более что играя еще в двойку и тройку я постоянно задавался вопросом "Почему существа не могут ходить отдельно от героя?". Понятно со всякими орками и нежитью - хорошо, они.неорганизованные, но с представителями Замка и Оплота - казалось, что они должны быть дружными и иметь возможность жить и действовать без лидера.
А еще больше мне зашло то, что в один отряд можно было поставить нескольких героев - вот это вообще была пушка-бомба! Учитывая то, что как раз перед четверкой я играл активно в Might & Magic 8, где ходил тоже отрядом героев, я прям представлял себе схожие истории, только уже в стратегическом режиме от третьего лица. Я тогда очень сильно заботился о каждом персонаже, продумывал его персональное развитие и это мне очень сильно нравилось, выделяя игру перед тройкой.
Ну, раз просите подводные камни, то... Заваривайте чаек, присаживайтесь на топчан и слушайте :-)
Проблема №1 - "Питон программисты"
Питон программистов много, это факт... Но в разрезе программирования RPA-решений картина выглядит довольно печально. Прям профи-профи в этой сфере не так то много, а те, кто не супер-профи, с высокой долей вероятности пишут в разных стилях и применяют разные подходы. Как итог - наняв нового программиста вы получите целое приключение с его адаптацией (или через месяц обнаружите, что старые программисты не могут поддерживать робота от новичка)
Проблема №2 - "ОпенСорс"
Любимая мантра всех опенсорсников - "Это октрытый код, ты сам как программист можешь исправить ошибку, никакого вендорлока. А еще ты уверен, что нет никаких дыр, так как сообщество ух как старается". По факту эти розовые очки разбиваются о то, что именно те проблемы, которые получите вы - никто другой не встретит (или их это не будет волновать как вас). При попытке залезть в исходный код опенсорса вы потратите кучу времени и сил, и с высокой долей вероятнсти даже если получится устранить баг - можно сгенерировать себе новые.
Как обратная ситуация - злоумышленники могут проанализировать опенсорс решения, которые вы используете, найти в нем дыры и воспользовавшись ими получить несанкционированный доступ к памяти ваших роботов, отправив все самы важные циферки из важных документиков в недружественные страны
Проблема №3 - "Масштабирование эксплуатации"
Действительно, на планке примрено до 10 роботов - играться в простенькие решения, которые написаны самостоятельно, это прикольно. Но как только у вас начинается опыт с десятком роботов, которые работают на десятках машин под парой десятков учетных записей... Контролировать этот "Зоопарк" теми же опен сорс средствами становится крайне проблематично. Легко упустить ошибки в работе одного конкретного робота на одной конкретной учетке, легко упустить то, что расписания запуска перестали работать и так далее.
В целом можно еще ворох проблем дать вам, но, по классике остановимся на раз-два-три.
В заключении хочется донести простую мысль - Отдавая деньги вендору за лицензии вы в первую очередь покупаете свое время, которое не потратите на решение очень многих сложных проблем. За вас их уже либо решили, либо помогут решить, когда окажется, что эта проблема касается только вас.
Обычно я и мои партнеры использовали 2-4 ядра и 4-8 гб оперативки, и особых проблем не испытывали.
Здесь в гайде не перечислен один дистрибутив, который мы так же ставили, но он вызвал проблемы - Ubuntu. Судя по всему, с ней что-то не так, потому что ее оболочки (что через установку ubuntu-desktop, что через установку gnome) тормозят и ведут себя именно так, как вы написали.
Если у вас проблемы с дистрибутивами, которые перечислены выше - скорее всего проблема где-то на уровне качества Интернет-соединения. Можно для контроля попробовать подключиться с заниженным разрешением экрана и цветностью, как правило это решает проблему плохой связи.
Цель данной публикации - сделать централизованный единый хороший гайд.
У каждого человека свое представление о прекрасном, и лично в моем представлении хороший гайд должен содержать всю информацию, достаточную для достижения вполне конкретной поставленной цели без отсылания человека на прочтение информации на других ресурсах по ссылкам.
Собственно говоря, точно таким же способом как и вы, я мог ограничить гайд просто ссылками на вики всех дистрибутивов, но... Тогда это был бы не гайд, его нельзя было бы распечатать и идти по нему гарантировано достигнув цели.
И самоцели обеспечить безопасность в создании виртуального рабочего места под короткие задачи - у меня не было. Но если вы составите такой гайд, который будет универсален и без ссылок, я обязательно его присоединю. Если вам это не интересно - честно, мне тоже. Предлагаю дальше не тратить наше общее время на демагогию
Да, про "Tunneling RDP over SSH" не случилось по той причине, что в кейсах, где этот гайд применяли - он был не нужен. Инцидентов взлома зафиксировано не было.
Как указал в самой статье - если у вас есть компетенции и навыки настройки под разные дистрибутивы "с нуля" - поделитесь, обязательно добавлю в статью с упоминанием вашего профиля.
Что касается MATE - тот образ, который используется в Яндекс.Облаке, не дал мне возможности установить эту оболочку "из коробки" без добавления дополнительных репозиториев. А KDE дал. Именно поэтому в статье написал именно так, как вы процитировали.
Не называть это VDI - ваше право, не буду спорить. То, что есть специалисты, которые используют такие стенды на регулярной основе с долговременным хранением там данных - моя реальная практика, в смысле из того что наблюдал "за спиной" у других.
Правильно ли это или вредно и плохо? Отдельный вопрос для хорошего холивара, участвовать в котором не вижу большого смысла.
Что-то странное. У меня ни на винде, ни стандартная сборка для линукса не глючат и работают прекрасно. Можете поделиться историями где что у вас не работало, чтобы я мог подготовиться?
Если что, я использую Криптопро в сочетании с руТокеном в основном для входа и работы с ФНС, реже подписываю файлы.
Надо понимать две вещи:
1) Не все специалисты, работавшие в западных компаниях - высококлассные. Порой даже в каких-нибудь "задрипанных" НИИ с ЗП 20к в месяц специалисты сильнее, чем в ушедших компаниях.
2) Действительно сильные специалисты, как правило, мало ищут работу "в открытую". У них есть своя база знакомых в разных других хороших компаниях и их буквально приглашают лично на очень хорошие ставки. То есть вероятность того, что на вашу вакансию сам собой откликнется действительно классный спец из ушедшей из России компании - стремиться к нулю.
В целом статья - это хорошая шпаргалка начинающему управленцу, но вот заголовок и вступление, конечно, слишком кликбейтные и не совсем перекликаются с тем, что оставляет статья после прочтения.
Наверное, статью будет приятно почитать обычным программистам, дизайнерам и прочим ребятам, кто занимается непосредственно "ручной работой" в разработке и не занимал руководящих должностей хотя бы уровня тим-лида продолжительное время.
Если же читать эту статью с точки зрения человека, кто так или иначе руководит командами несколько лет, то она читается примерно так (переводя на язык программистов):
Надо в коде писать комментарии. Если однажды начать их писать не так хорошо, то в результате на них забьют. И будет бардак в коде
Надо пользоваться системами контроля версий с gitflow. Если все вести в одной ветке - это плохо.
Ну и так далее (я конечно утрирую, но все же).
Искренне желаю каждому обычному разработчику побывать в шкуре управленца - это очень сильно меняет мировоззрение и подход к разработке как таковой. Даже если окажется, что "управление - не мое" (среди моих знакомых примерно 90% ушло из управления примерно такой фразой), то вернувшись к бытью обычным разработчиком качественно поменяется подход к задачам, их оценке и ответственность за исполнение. Ну а эта статья, как уже написал выше - довольно неплохо показывает слабые места, с которыми все так или иначе встречаются.
Ничего не могу сказать хорошего или плохого про песочницу, так как сам из нее вышел очень давно, но ограничение (минимальное или максимальное) в 3000 знаков не должно являться сильным препятствием для изложения мыслей.
Опять же, не хочу вас никак оскорбить, просто дать дружеский совет. Для вашего общего понимания - как и в научной литературе, так в целом и на хабре (да и не только) статья - это не просто мысль, выкинутая в цифровой океан безумия. Статья обычно ставит некий вопрос, освещает некую проблему и предлагает либо теоретические, либо практические методы ее решения. Еще прекрасно, если статья содержит хоть какие-то выводы (из разряда - попробовал, вышло хорошо или не очень), но это уже суть каждого дела индивидуальная.
Обращаясь к вашей статье - на самом деле даже без опускания в глубокие дебри вы и правда описываете очень обширную и знакомую, пожалуй, каждому проблему. Проблема команды - когда она собирается в удачной конфигурации, то может горы свернуть, но через какое-то время она распадается.
И вроде бы вы даже пытаетесь указать на причину, но опять же - ничего не предлагаете для ее решения. Ведь самый логичный вопрос после прочтения вашей статьи: "А как можно избавиться от этой проблемы, или хотя бы максимально отсрочить этот момент?" - и вы не даете даже намека на ответ.
Хотя даже я, вообще не специалист в психологии, но человек который участвовал и даже немного руководил разными командами, мог бы дать несколько мыслей и рекомендаций тем, кто ищет ответ на этот вопрос. Хотя бы банальнейшее "Разбавляйте команду новыми людьми, прощайтесь со старыми хотя бы на время отправив в долгий отпуск". Но это я, простофиля в психологии, а вот автора с таким багажом знаний как у вас, все же хочется услышать более интересные и неочевидные ответы.
Совершенно непонятно что хотел сказать автор и какой вывод стоит сделать.
В целом ощущение, что автор прочитал книжку по психологии (или послушал одну лекцию) и просто скопировал сюда материал никак его не переработав и не адаптировав для публики, которая не в контексте изучаемого автором предмета. В итоге получился рассказ из разряда "Утром солнышко встает, днем макушку нам печет, ну а вечером ложится спать пора"
Желаю автору в будущем стараться больше раскрывать материал, разбавлять примерами и познакомиться с хоть какой структурой, чтобы было сразу ясно - зачем эта статья, в чем именно проблема и как с ней бороться. Все что есть сейчас в статье - это только описание проблемы, но не сказано чем она плоха и как с ней бороться.
Как же забавно, ностальгически и одновременно грустно читать было эту статью. Казалось бы, 2022 год на дворе - такие то технологии, модные словечки аля Docker, Load Balancer и все такое... А проблемы все те же самые, что мы с коллегами решали на заре моей карьеры лет 13 назад.
Только тогда бэкграунд проблемы был немного другой. Дано: Множество предприятий по нашей необъятной стране, программные модули весом почти "АЖ В ГИГАБАЙТ", на удаленных концах дай бог диалап кое-как работает 2 часа в день. То есть возможности регулярно обновлять модули на предприятиях не было, и в результате каждое могло работать со своей версией.
А самый прикол был в том, что эти самые предприятия должны были синхронизироваться - получать актуальные данные друг от друга, делалось это через единый центральный сервер. Каждый установленный модуль в удобное для сетевой нагрузки время отправлял свои новые данные и забирал другие с сервера.
И там были точно такие же проблемы - одно предприятие использовало прошлогоднюю версию, где какие-то данные лежали в одном поле одной строчки таблицы, а на другом предприятии стояла самая свежая версия, где эти данные были вынесены в отдельную таблицу построчно.
Для решения таких проблем нам приходилось писать специальные преобразователи. Они получали данные от старых версий и преобразовывали их в формат последней версии. И наоборот - для отправки на старые версии преобразовывали данные из нового формата в старый, определенной версии того предприятия, которое запрашивало обновления.
Можно, через передачу информации по сессии. Точнее схема такая:
1) Делаем авторизацию через скоуп подключения к браузеру
2) Через параметр SessionData получаем информацию о сессии, эта информация передается в виде строки, ее можно сохранить в хранилище, чтобы использовать в последующих тестах
3) В тесте, где нужно использовать эту сессию - загружаем параметр SessionData
Более подробно про методы получения и загрузки данных о сессии можно прочесть в документации:
https://docs.uipath.com/activities/docs/n-get-browser-data
https://docs.uipath.com/activities/docs/n-set-browser-data
Не очень понял вопроса с куками, пожалуйста, раскройте подробнее.
time.sleep - это из примера Selenium, к дальнейшему рассказу про UiPath никакого отношения он не имеет. Там есть свои методы ожидания реакции, не требующие настройки таймеров. Что касается Selenium - даже если вы знаете как обходиться без time.sleep там, вы большой молодец, что не отменяет проблемы с удобством восприятия кода, где идет указание на элементы, с которыми идет работа в стиле div>div>div>div
Надежность тестов полностью зависит от поддержки их актуальности. Если вы доработаете/переработаете функционал, который проверяет тест, и при этом не заложите в тесты новых ожидаемых результатов - естественно, тест будет выдавать ложные результаты.
В случае, если вы держите тесты в порядке, они всегда содержат корректный порядок действий, содержат согласованный набор входных данных с ожиданием согласованного результата - они никогда вас не подведут.
Естественно, под "никогда" я имею ввиду, что вы не будете умышленно пытаться вмешаться в тестирование роботом. Например, принудительно закрывать приложения, которые тестирует робот, отключать Интернет тогда, когда робот тестирует ресурс в Интернете. В этих случаях робот обязательно сообщит об ошибках во время выполнения тестов.
В прочем, если вы получите в отчете о тестировании результат "Ошибка, нет доступа к ресурсу" - это тоже тот случай, когда нужно обратить внимание на тестируемый ресурс. А если вы понимаете "ну да, пропадал Интернет" - просто перезапускаете тесты (можно сделать выборку по проваленным и запустить только их).
Плюс в том, что вы можете автоматизировать ручное тестирование одинаково для Windows, Web и мобильных приложений. А еще важно то, что вы можете сделать тест бизнес-процесса, где участвует сразу несколько приложений.
Например, вы можете проверить, что после загрузки клиентом документа на сайт - сведения об этом появляются во внутренней CRM (например, в SAP). С помощью инструмента, про который рассказано в этой статье, данный тест можно написать за несколько минут, при этом не нужно быть ни разработчиком веб-решения, ни разработчиком/интегратором CRM. Если вы мне расскажете каким еще способом можно написать такой тест при условии, что автор теста не умеет программировать SAP - я буду вам очень признателен и с удовольствием ознакомлюсь с материалами.
Конечно, если у вас только web, который вы пишете сами - использовать указанный в статье инструмент может быть слегка Overkill. Но здесь статья скорее обращена к тем, кто:
1) Помимо Web делает Windows-приложения (вы будете удивлены, но таких еще очень много)
2) Не обладают компетенциями в selenium и подобных средствах
Приношу свои извинения, если где-то в статье выразился некорректно. Автотесты на программном уровне должны быть написаны в той среде разработки, в которой вы создаете ваши приложения. В статье речь идет именно про ручное тестирование. Это может показаться странным, но я знаю немало компаний, где сидят целые отделы ручных тестировщиков, которые весь день занимаются тем, что просто кликают мышкой по очередным сборкам систем и заносят отчеты в Jira или аналогичное ПО. Можете считать, что целевой аудиторией этой статьи являются именно такие компании и команды. Если вас не затрагивает эта проблема - я искренне рад за вас и даже немножко завидую (без иронии и сарказма).
Как и у любого серьезного инструмента (а инструмент, названный в статье - серьезный), существует как общемировое комьюнити (форум), официальная поддержка, так и несколько российских комьюнити. И дабы не быть обвиненным в рекламе - на самом деле есть множество других RPA решений, в том числе отечественных, которые активно развиваются как в плане качества, так и в плане поддержки и комьюнити. Просто инструмент, про который я рассказал в статье - лично мне нравится больше всего и им я пользуюсь уже года два с большим удовольствием.
Возможно, вы немного запутались. Это статья на моей персональной странице хабра про мою частную практику, не относится ни к какому корпоративному блогу. Точно так же, как есть много статей, написанных частными специалистами про многие другие технологии, которыми они пользуются.