Comment j'ai simplifié le processus de travail sur des projets open source


Dans cet article, je vais vous dire comment j'ai essayé de participer au développement d'un projet open source majeur, je me suis détesté, puis j'ai automatisé la routine et appris à profiter de la vie. Détails - sous la coupe.


Pourquoi est-ce même nécessaire?


En règle générale, les développeurs souhaitent participer à la communauté open source pour plusieurs raisons. En voici quelques-uns (et probablement pas tous):


  • en reconnaissance de l'opportunité d'utiliser gratuitement ce programme et d'autres programmes
  • acquérir une nouvelle expérience
  • pour pomper votre CV

J'ai toujours été principalement attiré par l'opportunité d'apprendre quelque chose de nouveau, d'absorber les meilleures pratiques en développement logiciel, mais tout le reste n'est pas un appendice moins agréable dans ce processus.


OK, je suis en affaires, par où commencer?


La première chose à faire est de trouver une tâche sur laquelle travailler. Vous êtes vraiment chanceux, si vous aviez besoin de modifier une bibliothèque pour vos besoins de travail - commencez une tâche, discutez avec les propriétaires et lancez la mise en œuvre! Sinon, vous pouvez vous référer à la liste des tâches ouvertes sur la page du projet et choisir quelque chose par vous-même. Trouver le bon n'est pas moins important que sa mise en œuvre, et ici ce n'est pas si simple. Même si vous êtes un ingénieur expérimenté, il peut être utile de commencer par des tâches plus simples, de vous familiariser avec la base de code, les processus de développement acceptés et ensuite de prendre en charge une fonctionnalité plus importante.


Comment trouver des tâches pour les débutants?


Il y a quelque temps, github a commencé à montrer des tâches adaptées aux débutants.


Vous pouvez les voir en allant de l'annonce dans l'en-tête de la page des problèmes


Et voici notre page précieuse


Après avoir réglé ces "outils", ma journée habituelle a commencé à ressembler à cela - j'ai ouvert la liste des projets sur lesquels je voulais travailler (pour les garder à portée de main, je les ai tous marqués avec de petites étoiles), suis allé dans la section ci-dessus ou j'ai parcouru les balises de recherche dont j'avais besoin, en recherchant simultanément ceux qui sont utilisés dans ce projet particulier. Inutile de dire que circuler entre 40 et 60 référentiels a coûté énormément de force et m'a rapidement ennuyé. Dans le processus, je suis devenu irritable, j'ai perdu patience et j'ai abandonné cette chose. Un de ces jours, j'ai réalisé que je pouvais automatiser le processus de recherche et j'ai commencé à compiler un TOR.


Prérequis


  • La tâche doit être ouverte
  • La tâche n'est assignée à personne
  • La tâche doit être étiquetée avec simplicité et ouverture à la communauté.
  • La tâche ne doit pas être trop ancienne

Après cela, j'ai commencé à analyser différents référentiels pour les étiquettes utilisées. Il s'est avéré qu'il existe un grand nombre de labels différents, dont certains sont spécifiques à des référentiels / organisations spécifiques. Respectant la casse, j'ai compilé une liste de ~ 60 balises


Développement de solutions


En tant qu'outil, j'ai décidé d'utiliser Kotlin, que je connaissais déjà, et j'ai implémenté l'algorithme suivant: parcourir tous les référentiels marqués d'un astérisque, obtenir toutes les tâches qui correspondent aux exigences, trier par date de modification, éliminer les trop anciennes et les afficher. La liste résultante est divisée par des horodatages - pour aujourd'hui, pour hier, pour la semaine dernière, pour le mois et tout le reste - grâce à cela, il est devenu beaucoup plus pratique d'utiliser le programme régulièrement. J'ai décidé qu'à la première étape, l'application sera un utilitaire de console, donc la sortie va juste à stdout.


J'ai enveloppé le résultat dans une image de docker, en m'attendant à ce qu'une personne soit plus susceptible d'avoir un docker installé que JRE. L'utilitaire ne stocke aucun état, donc chaque lancement exécutera l'intégralité de l'algorithme et le conteneur usagé peut être retiré en toute sécurité du système.


Voici comment fonctionne le programme:


image


Limite de demande


Un appel à une API tierce est un exemple classique d'une tâche io-intensive, il a donc été naturellement décidé de commencer à charger des données dans plusieurs flux. Par essais et erreurs, j'ai rencontré les limites de l'API Github. Tout d'abord, avec un grand nombre de threads, la vérification anti-abus côté Github a été déclenchée et j'ai dû m'arrêter à 10 threads par défaut, avec possibilité de configuration via des arguments d'entrée.


Deuxièmement, il y a une limite au nombre de demandes - elles ne peuvent pas être faites plus de 5000 par heure. Avec cette limitation, tout est beaucoup plus compliqué, car lors du passage de plusieurs balises à une requête de recherche, Github met un `` Et '' logique entre elles et, étant donné le nombre de balises dans la liste, il ne trouvera rien avec une probabilité de presque 100%. Confronté à un grand gaspillage d'appels à l'API, j'ai commencé à faire une demande supplémentaire pour toutes les balises qui sont dans le projet, prendre l'intersection avec ma liste et les tâches de demande pièce par pièce uniquement pour ces balises. En ajoutant 1 demande à chaque référentiel, je me suis débarrassé de 50 à 55 demandes supplémentaires (plus il y a de balises prises en charge par le programme, plus il y a de demandes supplémentaires) pour des tâches sur des balises qui n'existent pas pour le référentiel.


Cependant, pour certains utilisateurs, cette optimisation peut ne pas être suffisante. Selon une évaluation superficielle, la solution actuelle vous permet de contourner 1000 référentiels (il existe également une restriction stricte dans le code), en s'attendant à ce qu'il y ait en moyenne 4 étiquettes simples dans chaque référentiel. Jusqu'à présent, personne n'a rencontré une telle restriction, mais l'idée d'une solution est en retard. Tout est simple ici - le stockage de l'état, la mise en cache des réponses, dans les cas particulièrement difficiles, contourne lentement en arrière-plan.


Comment trouver des référentiels?


Si vous n'êtes pas encore un utilisateur Github actif ou si vous n'utilisez pas la fonctionnalité étoiles, voici quelques conseils pour trouver les bons référentiels:


  • Parcourez les technologies que vous utilisez sur vos projets, peut-être que certaines d'entre elles sont présentées sur Github
  • Utilisez la section des tendances populaires
  • Utilisez le référentiel awesome-lists pour les sujets qui vous intéressent.

Lancement


Pour commencer, vous aurez besoin de:


  • avoir docker installé sur l'ordinateur
  • écrire un jeton API, vous pouvez le faire sur la page des paramètres Github correspondante
  • démarrer le conteneur en passant son jeton d'accès à travers les paramètres

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

D'autres paramètres (filtrage par langue, niveau de parallélisme, liste noire des référentiels) se trouvent sur la page du projet. Lien vers le projet .


Si vous manquez quelques balises dans le projet - créez un PR ou écrivez-moi de manière personnelle, j'ajouterai.

Source: https://habr.com/ru/post/fr473208/


All Articles