Как стать автором
Обновить

Комментарии 36

Я бы сделал без UI, какой-нибудь простенький workflow manager (хоть gnu make) и библиотеку requests для сервисных вызовов.

Автоматизировать нужно, да.

Если бы было чуть больше времени. Надо было очень быстро. Настя уже закапывалась с этими промокодами. Накодил за несколько часов. В юпитере сразу по месту и тестил.

Я все равно не понимаю зачем Юпитер? Что мешает запускать скрипт через python scriptname.py?

И зачем селениум, в подобном случае было бы куда проще либо писать напрямую в базу либо постить в специальный эндпоинт целевой системы, а то и в тот же, что используется админкой.

API это сложна...

Долго. В крупной компании с ИС в пром эксплуатации это целая не очень прямая история. Месяца два, если в роадмап влезу конечно.

Можно. Но я не был уверен, что всё работает так как я думаю. Поэтому сразу и изучал/вспоминал синтаксис и нужные модули и писал алгоритм. Я же менеджер) Отладка в IDE заняла бы больше времени.

Какой грамотный нынче менеджер пошёл, однако. Нет, кроме шуток, все бы так подкованы были по технической части.

Согласен. А главное, задача решена, время сэкономлено и в результате все довольны!

О! Вы придумали RPA!)

Спасибо) Бесплатно и из подручных материалов.

Вот это да! Спасибо, покажу своим)

Мы примерно также делаем. Но когда алгоритм готов, то перекладываем из jupyter в streamlit. Так можно давать юзеру простой интерфейс с кнопкой и не пугать его видом блоков кода. И кладем почти всё на сервер, чтобы питон не ставить юзеру.

А как переводите в streamlit? Это же модуль питоновский? Расскажите пожалуйста чуть подробнее. Очень интересно.

Тут можно целую статью писать про streamlit. В jupyter удобно итеративно управлять селениумом пока пишешь последовательность действий. Потом весь код кладем в обычный .py файл и в нем же импортируем стримлит и рисует интерфейс. Он запускается в браузере как и jupyter, если на локали.

Только нужно внимательно смотреть чтобы selenium ждал подгружения страницы. У Вас кстати это сделано через sleep. Лучше использовать webdriverwait. Селениум так умеет - если страница загрузится быстрее, то и скрипт быстрее отработает.

Вообще у нас напилен целый “app store” с парой десятков приложений в стримлите и аутентификация юзера через корпоративный ldap.

Звучит очень круто! А можете написать об этом? Было бы полезно многим, я уверен. Сам после вашего комментария уже копаю streamlit.

Буквально сегодня возился с Selenium для автоматизации конфигурирования локального дев-стенда с чужим (черный ящик) беком/фронтом через веб-интерфейс. Инструмент очень крутой.

Повозиться пришлось только с установкой Selenium и его драйвера для Google Chrome.

Меня смутило, что нужно прихранивать драйвер для браузера, да еще и следить, чтобы его версия не конфликтовала с установленной сборкой хрома. Но есть элегантное решение!

pip install webdriver-manager

from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager

options = webdriver.ChromeOptions()
driver = webdriver.Chrome(service=Service(ChromeDriverManager().install())) 

Шикарная идея! Спасибо!

Зачем локальный Selenium, если есть Selenoid? Хочешь, Chrome, хочешь Firefox. Любой версии и без проблем с веб-драйверами. Один раз настроил и запустил в Докере и дальше хоть в n потоков эти ваши RPA пускай. :)

Похоже на промышленное решение) посмотрим, спасибо за наводку!

Видел два комментария сверху, видел ответы на них - долго, нет времени. Но, всё-таки задам тот же вопрос - зачем здесь селениум? Без селениума как раз все будет быстрее проще и надёжнее. Почему нельзя дергать те же api, но без посредников в виде драйвера и браузера?

а с чего Вы взяли что апи там вообще есть?

Т.е. бэка вообще нет, форма с фронта инсертит прямо в БД?)) Даже если и так - все может быть, я действительно могу не знать - все-равно проще сделать реализацию на более низком уровне, т.е. инсертить в БД без посредничества драйвера и фронта.

Это большой enterprise-продукт в промышленной эксплуатации. Никаких инсертов в БД быть не может по определению. А по поводу API я написал чуть ниже.

Согласен. Инсертов в БД не может быть по определению. По определению у вас там есть API))

Ответил чуть ниже. Вопрос сложнее, чем видится на первый взгляд.

Всё в теории можно, но на практике делаешь как проще быстрее и с минимальными затратами. На нагрузку на машины вообще всё равно, так как главное это человеко часы. Самое ценное это человек и его время. У нас это пока не сильно воспринимают, более так сказать рабское отношение. Но пора учиться.

Там же написано, человек менеджер, что умел, то и сделал.

API именно к этому функционалу не было. Цикл его разработки таков, что проще было (но мы так не делали и не будем!) ушатать бедную Настю и нанять ещё пару-тройку ассистентов. Ну вот прям совсем не наш вариант.

Мне стало очень интересно, что такое API в вашем понимании? Запросы из браузера - с фронта - уходят на бэк. Уходят через какой-то... хм... интерфейс)) Значит этот интерфейс можно использовать без браузера

То же, что и в вашем - программный интерфейс для взаимодействия с приложением. Я понимаю, что фронт дёргает ручки на бэке. Но не только лишь все эти ручки можно без риска для психического благополучия окружающих выложить. И сам процесс выкладывания в такой крупной ИТ-компании как МТС сопряжён с многоуровневыми оборачиваниями связанными с ИБ. Плюс к этому вопросы документирования всех этих ручек. Плюс поддержка при попытках во всём этом разобраться. Это недели и месяцы работы. Они не заложены в бэклог данной конкретной команды. Следовательно, с точки зрения менеджера это равносильно тому, что у нас нет API.

Все-таки, кажется, что у нас разное понимаение API)) Те апи, при помощи которых фронт общается с бэком - по умолчанию доступны тому самому пользователю, который делает манипуляции в браузере. Да, content-type может быть не application/json, а какой-нибудь application/x-www-form-urlencoded . Да, авторизация точно будет не базовой, а, скорее всего, по куке. Да, вы можете не увидеть этот запрос в консоли разработчика в браузере. Но, все это решается - и решается точно быстрее чем через селениум. И работать точно будет быстрее и стабильнее

Вы пишете правильно. Для опытного разраба бэк, у которого полно времени. Мне нужно решить задачу здесь и сейчас. Некрасиво, но быстро. А так, да. Теоретически можно было бы недельки за 2-3 разобраться сначала с авторизацией, затем с их ручками. А может быть и нет. Мне нужен был гарантированный результат. Селениум его дал.

Куча одинаковых советов от прогеров - почему этот набор костылей,когда можно красиво. Зачем красиво, если это здесь не нужно? Вот так программисты и не хотят видеть рациональность - затраты на решение/результат. Результат будет одинаков - задача решена, но затраты очевидно совсем не одинаковые.

Я бы разбил задачу на 2 этапа:

1) автоматизация заведение промокодов в базу - лучше через какое-нибудь API, но если получилось через Selenium, то пусть будет так.

2) автоматизация подготовки данных-промокодов - для менеджера было бы удобно составить Excel-файл со списком промокодов, который бы и скармливать скрипту, где бы в новом столбце и статус выполнения проставлялся.

 Не знаю, как для разработчиков, а для менеджеров ничего лучше не придумано

Excel нравится большинству менеджеров. Хотя.... если у вас все менеджеры владеют Jupiter'ом....

Добрый день. Спасибо за статью. Кто-нибудь сталкивался с проблемой активации расширения (не своего) в браузере? Можно ли это сделать через селениум или как-то по-другому?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий