Как я упрощал процесс работы над опенсорс проектами


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


    Зачем это вообще нужно?


    Обычно разработчики хотят поучаствовать в жизни опенсорс сообщества по нескольким причинам. Вот некоторые(и, вероятно, не все) из них:


    • в благодарность за возможность пользоваться этой и другими программами бесплатно
    • получение нового опыта
    • чтобы прокачать своё резюме

    Меня всегда в первую очередь привлекала возможность узнать что-то новое, впитать лучшие практики по разработке ПО, но все остальное не менее приятный довесок в этом процессе.


    Хорошо, я в деле, с чего мне начать?


    Первое, что надо сделать — найти задачу, над которой поработать. Вы настоящий везунчик, если вам по рабочим нуждам понадобилось доработать какую-то библиотеку — заводите задачу, обсуждайте с владельцами и приступайте к реализации! В ином случае можно обратиться к списку открытых задач на странице проекта и подобрать себе что-нибудь. Найти подходящую — не менее важная часть, чем ее реализация, и здесь не все так просто. Даже если вы опытный инженер, то может быть полезным начать с задач попроще, ознакомиться с кодовой базой, принятыми процессами разработки и лишь потом браться за фичу побольше.


    Как находить задачи для начинающих?


    Некоторое время тому назад, github начал показывать подходящие задачи для новичков.


    Увидеть их можно перейдя с объявления в шапке страницы issues


    А вот так выглядит наша заветная страничка


    Остановившись на этих "инструментах", мой обычный день стал выглядеть так — я открывал список проектов, над которыми хотел поработать (чтобы держать их под рукой, я пометил их всех зведочками), заходил на вышеуказанную секцию или через поиск перебирал нужные метки, попутно разыскивая те, что используются именно в этом проекте. Стоит ли говорить, что обход 40-60 репозиториев стоил огромной кучи сил и быстро наскучивал мне. В процессе я становился раздражительным, терял терпение и забрасывал это дело. В один из таких дней я понял, что могу автоматизировать процесс перебора и приступил к составлению ТЗ.


    Требования


    • Задача должна быть открытой
    • Задача ни на кого не назначена
    • Задача должна быть помечена меткой, обозначающей простоту и открытость для сообщества
    • Задача не должна быть слишком старой

    После этого я начал анализировать разные репозитории на предмет используемых меток. Оказалось, что есть огромная куча самых разных меток, часть из которых уникальна для конкретных репозиториев/организаций. С учетом регистронезависимости я составил список из ~60 меток


    Разработка решения


    В качестве инструмента я решил использовать уже знакомый мне Kotlin и реализовал следующий алгоритм: пройтись по всем репозиториям, помеченным звездочкой, достать оттуда все задачи, подходящие под требования, отсортировать по дате изменения, отбросить слишком старые и отобразить. Результирующий список разделен временными метками — за сегодня, за вчера, за прошедшую неделю, за месяц и все остальное — благодаря этому стало сильно удобнее пользоваться программой на регулярной основе. Я решил, что на первом этапе приложение будет консольной утилитой, поэтому вывод идет просто в stdout.


    Результат я обернул в docker образ, ожидая, что у человека с большей вероятностью будет установлен docker нежели чем JRE. Утилита не хранит никакого состояния, поэтому каждый запуск будет выполнять весь алгоритм целиком, а отработавший контейнер можно спокойно удалять из системы.


    Вот как выглядит процесс работы программы:


    image


    Ограничение количества запросов


    Обращение к API стороннего сервиса является классическим примером io-intensive задачи, поэтому естественным образом было решено начать грузить данные в несколько потоков. Методом проб и ошибок я познакомился с ограничениями Github API. Во-первых, при большом количестве потоков срабатывала anti-abuse проверка на стороне Github и мне пришлось остановиться на 10 потоках по умолчанию, с возможностью конфигурации через входные аргументы.


    Во-вторых, существует ограничение на количество запросов — их можно сделать не больше 5000 в час. С этим ограничением все намного сложнее, так как при передаче нескольких меток в поисковой запрос Github ставит между ними логическое 'И' и, учитывая количество меток в списке, с почти 100% вероятностью ничего не найдет. Столкнувшись с большими тратами обращений к API, я стал делать дополнительный запрос за всеми метками, которые есть в проекте, брать пересечение с моим списком и поштучно запрашивать задачи только по этим меткам. Добавив 1 запрос на каждый репозиторий, я избавился от 50-55 лишних запросов(чем больше меток поддерживает программа, тем больше лишних запросов) за задачами по несуществующим для репозитория меткам.


    Тем не менее, для некоторых юзеров и этой оптимизации может быть недостаточно. По поверхностной оценке текущее решение позволяет обойти 1000 репозиториев (в коде также есть жесткое ограничение), ожидая, что в среднем в каждом репозитории встречается 4 простые метки. С таким ограничением пока никто не столкнулся, но идея решения есть в бэклоге. Тут все просто — хранение стейта, кэширование ответов, в особо тяжеловесных случаях медленно обходить в фоне.


    Как найти репозитории?


    Если вы еще не такой активный пользователь Github или не используете функционал звезд, то вот несколько советов, как найти подходящие репозитории:


    • Пройдитесь по технологиям, которые вы используете на своих проектах, возможно часть из них представлена на Github
    • Воспользуйтесь разделом популярных трендов
    • Воспользуйтесь репозиторием awesome-lists по интересующим вас темам

    Запуск


    Для запуска потребуется:


    • иметь установленный Docker на компьютере
    • выписать API токен, можно сделать на соответствующей странице настроек Github
    • запустить контейнер, передав через параметры свой токен доступа

      docker pull igorperikov/mighty-watcher:latest
      docker run -e TOKEN={} --rm igorperikov/mighty-watcher:latest

    С остальными настройками (фильтр по языку, уровень параллелизма, черный список репозиториев) можно ознакомиться на странице проекта. Ссылка на проект.


    Если вам не хватает каких-то меток в проекте — создавайте PR или пишите мне в личку, добавлю.

    • +11
    • 2,4k
    • 8
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      0
      Обязательно попробую, должно намного облегчить поиск
        0
        Я же правильно прочитал, что тулза ищет только то, что помечено звездочками в GH-аккаунте пользователя?
        Не было мыслей в сторону поиска «по всему гитхабу»? Я в общем-то понимаю, что это, наверное, не очень просто, так как как-то смотрел на Github API с похожей целью и беглым просмотром не нашел способа найти подходящие issue, не задавая списка конкретных проектов.
          0
          Да, все верно, в сторону глобального поиска не было мыслей, потому что для меня звездочки это дополнительный критерий, обозначающий мою заинтересованность в репозитории. Хоть это и требует дополнительной работы по поиску и разметке репозиториев, выборка становится намного более репрезентативной. Например, на гитхабе есть огромная куча java проектов, связанных с андроидом, которые мне неинтересны и, соответственно, не хотелось бы их видеть.
            0
            У меня, на самом деле, тоже куча звездочек на гитхабе и сохраненных ссылок в блокнотах, до которых руки не доходят.
            Но как-то подумывал над идеей решить задачу in: «Хочу Python, начальный уровень, web-framework» -> «Список issue, над которыми можно поработать». Потом понял, что мне самому такую задачу решать не нужно и забил
              0

              Я думал о чем-то похожем, но все сводится к тому, насколько достоверно люди будут расставлять теги у проекта. Как следствие — менее надёжная схема.

          +2

          Вам не кажется что использование докера для такой задачи — немного оверкилл?

            +1

            Докер здесь хорошо помогает как средство дистрибуции. Мне не нужно думать о кроссплатформенных билдах и о том, каким осям в какие репозитории их класть. Благодаря этому утилита легко работает на всех системах, где работает докер.

            0
            > Результат я обернул в docker образ, ожидая, что у человека с большей вероятностью будет установлен docker нежели чем JRE

            Вся суть докера

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

            Самое читаемое