Комментарии 11
Первый пост на Reddit
в каком сабреддите?
к 5 тысячам звёзд на гитхабе
Поздравляю с признательностью IT-сообщества, видно, что звезды у проекта не накручены.
Скрытый текст
Сейчас распознать "признательность" vs "плутовство" по GitHub-звездам просто. Прочитать исследование про накрутку фейковых звезд можно, например, на Хабре. Вычислить, разоблачить голых королей/свиту поможет Open Source (мой инструмент) — Shotstars.
Судя по статье, мне не светит ни одной звезды ни на одном репозитории. И причина этому одна - я пишу код, а не статьи.
И конечно же не считаю свой код каким-то особенным. Навыка такого не имею.
Читал статью в надежде увидеть какой-то особенный опыт работы типичного инженера-программиста. Но эта статья человека другого типа и более широких качеств.
Вот и вся идея.
ПС: просто описал послевкусие от прочитанного.
Фишка опенсорса в том, что общаться необходимо. Код - это база, но кто-то как-то должен его найти и увидеть. У меня даже мини-репозиторий к прошлогоднему докладу набрал 6 звёзд только потому, что я отпостил ссылку на него на форуме LLVM в релевантном треде. Без этого было бы 1-2 звезды максимум. Это проблема начального трафика. Только потом начинается естественный рост. И удержание юзеров через багфиксы и техподдержку. Больше никакой волшебной таблетки, увы. Если глянуть на рейтинг, тот же pyautogui более популярен, потому что автор Ал Швейгарт - ещё и автор нескольких книжек про питон, где есть примеры использования его библиотек. И, конечно же, он активен на конференциях. Мне тоже всегда подспудно казалось немного нечестным, что у pyautogui меньше фич, чем у pywinauto, а звёзд - больше. Но такова суровая реальность: только медийка, только хардкор.
Кстати, если самому трудно или не хочется в медийку, можно пользоваться помощью уже готовых сообществ, хотя бы локальных. Скинь ссылки на свои проекты в ответном комменте или в личку. Может поможем чем.
Интересны алгоритмы, которые применяли для автоматического прокликивания ui. Что-нибудь на графах?
Если точнее, то на дереве. Ведь в любом приложении UI элементы собраны в иерархию. Если говорить о вызове .child_window(<какие-то критерии>).wait('ready'), то поиск элемента в дереве требует полного обхода, т.к. в случае возврата 2+ элементов выбрасывается исключение ElementAmbiguousError. Поэтому обход в ширину (BFS) по принципу "find first" не достаточен. Фактически происходит вызов BFS по части критериев, возвращается линейный список (как правило, очень маленький), и он дополнительно фильтруется по оставшимся критериям. По части критериев, потому что внутри этот BFS ре-юзает Сишный код из UIAutomationCore.dll, который умеет искать только по этим критериям.
Для рекордера скриптов - всё то же самое, только там добавляется копирование дерева: ведь во время клика оно начнёт меняться, а нам для генерации скрипта нужно состояние "до клика". Конкретно в MS UI Automation API есть встроенная функциональность по кэшированию дерева, но с ней ещё нужно разобраться, подойдёт ли она к данной задаче. Для других технологий ни о чём таком мне не известно.
Особняком стоит поиск по приблизительному имени ("best_match" поиск), так по всему дереву строится словарь возможных имён (имя: элемент), затем происходит поиск с ранжированием по расстоянию между текстами, которое вычисляется стандантным модулем difflib. За счёт этого расстояния и происходит поиск с точностью до небольших опечаток. Детально этот код я не модифицировал, поэтому глубже не расскажу формулу для расстояния и почему она именно такая.
Привет, это команда GitVerse! Рады видеть тебя в числе участников сезона open source! Ставим лайк твоей статье :)
Через тернии к 5 тысячам звёзд на гитхабе – мой путь опенсорсера