Notre parcours vers l’open source pendant le Google Summer of Code


  • FrançaisFrançais



  • Chaque année, Google organise un programme appelé Summer of Code (GSoC). Les étudiants du monde entier peuvent écrire du code open source dans le cadre d’une organisation de mentorat open source et être payés pour le faire ! Vous travaillez sur des projets open source sympas, vous réseautez avec des ingénieurs talentueux et vous êtes payé pendant les vacances d’été. À quel point cela est cool!?

    Dans cet article de blog, nous vous guiderons à travers notre expérience GSoC et vous donnerons des trucs et astuces pour que vous puissiez vivre une expérience fantastique comme nous l’avons fait. Nous partagerons également nos différentes perspectives en fonction de nos différents intérêts et défis.

    À propos de nous

    Rahoul : Je m’appelle Rahul Anand et, au moment d’écrire ces lignes, je suis en dernière année d’université et je me spécialise en génie informatique à l’Université Thapar, à Patiala, en Inde. Mon intérêt est pour l’informatique distribuée car c’est l’un des domaines significatifs permettant l’évolutivité des applications dans le monde entier. La vision par ordinateur est saupoudrée juste parce que l’IA va conquérir le monde.

    Lahiru : Je suis Lahiru Udayanga, actuellement en dernière année de premier cycle au Département d’informatique et d’ingénierie de l’Université de Moratuwa, au Sri Lanka. Mes principaux domaines d’intérêt en informatique sont les systèmes distribués, les passerelles API, les proxys et les technologies natives du cloud.

    Choisir la bonne organisation et le bon projet

    La première et la plus cruciale décision que vous prendrez au cours de ce voyage est de choisir l’organisation la plus appropriée et le projet auquel vous souhaitez contribuer. Cette décision influencera fortement votre expérience, alors soyez très diligent ici. Ne vous inquiétez pas, à la fin de cette section, nous avons répertorié les facteurs que vous devez prendre en compte pour cette étape.

    Nous avons tous les deux décidé de postuler pour le même projet : cache d’autorisation proxy 3scale-envoy. Cependant, nous avons chacun eu un processus de réflexion légèrement différent derrière le choix de ce projet.

    Rahoul : J’ai discuté des options avec un senior qui a participé à GSoC’20 sous l’égide de JBoss et j’ai décrit son expérience comme très enrichissante. C’est ainsi que j’ai décidé avec quelle organisation je voulais participer. Je conseille aux juniors de se concentrer sur une bonne organisation et de commencer à y explorer différents projets. Concernant le choix du projet, un mélange de divers facteurs m’a influencé. Le plus important a été ma première interaction avec mon mentor, Alejandro Martinez Ruiz. Je lui ai posé de nombreuses questions et il était toujours prêt à répondre de manière détaillée à chacune d’entre elles. (Conseil : Soyez concis dans vos questions et respectez le temps de votre mentor.) Je voulais aussi travailler avec des systèmes distribués, apprendre Rust et construire un projet à partir de zéro.

    Lahiru : La principale raison pour laquelle j’ai postulé à ce projet est mon intérêt profond pour les middleware, les passerelles API et les proxys. De plus, j’ai eu une expérience précédente avec un mandataire d’envoyé de mon projet de stage. Je pense que le proxy envoy va révolutionner le domaine des proxys et qu’il y aura beaucoup d’opportunités pour les technologies liées au proxy envoy. Comme Rahul, ma première interaction avec Alex et les conversations que nous avons eues avant la phase de soumission des propositions ont également eu un impact significatif sur ma décision de postuler.

    Conseils pour cette période :

    • Si vous trouvez une technologie intéressante ou si vous souhaitez en savoir plus, recherchez ces projets.
    • Interrogez les personnes âgées sur leurs expériences avec différentes organisations.
    • Considérez l’avenir de ce projet : voyez-vous un avenir pour ce domaine de recherche ?
    • Si vous avez une bonne connexion initiale avec un mentor potentiel, continuez à établir des relations.

    Élaboration de la proposition

    Après avoir décidé sur quel projet nous voulions travailler, nous avons mis nos recherches sur les chapeaux et commencé à creuser pour toute information liée au problème et aux solutions possibles. Au cours de cette phase, nous interagissions constamment avec notre mentor au sujet de toutes les questions, ressources et conceptions de solutions que nous envisagions d’aller de l’avant de manière indépendante. Il est préférable de se rapprocher le plus possible du résultat réel et de tout documenter dans un document séparé pour votre référence, car cela vous aidera énormément pendant la phase de création de votre proposition.

    Après avoir effectué des recherches pendant environ un à deux mois, alors que nous approchions de l’ouverture des soumissions de propositions, notre mentor nous a demandé de commencer à tout mettre dans un document Google distinct à présenter sous forme de proposition devant un comité. Il était temps de se lier d’amitié avec Shakespeare et de saisir un travail acharné dans un document qui allait changer nos vies pour toujours !

    Blague à part, il est impératif que ce document soit présentable, avec d’excellents diagrammes. Nous avons utilisé et recommandé draw.io (maintenant diagrammes.net), un logiciel de création de diagrammes open source. N’oubliez pas que personne ne peut rédiger un document parfait du premier coup et ayez quelques cycles de révision avec votre mentor pour obtenir ses commentaires. Vous pouvez regarder nos propositions pour un exemple.

    La proposition de Rahul

    La proposition de Lahiru

    Nous nous souvenons du jour où nous avons cliqué sur le bouton d’envoi du tableau de bord GSoC : il pleuvait du ciel sur le sous-continent indien. Notre destin étant désormais entre les mains de l’organisation JBoss et de l’équipe 3scale de Red Hat, nous avons attendu jusqu’à ce jour fatidique où nos parents se sont réveillés à 2 heures du matin avec des adultes nouvellement créés criant à pleins poumons, “GSOC BABY !!”

    Apprentissage par la pratique

    Le lendemain, nous avons reçu notre premier e-mail avec des informations d’intégration, la proposition de chacun de se référer et une invitation à un appel entre Alex et nous. Lors du premier appel, nous nous sommes renseignés sur nos cultures respectives et sur l’équipe 3scale, et nous avons été chargés de créer un document partagé avec une chronologie réaliste. Étant donné que ce projet était énorme par rapport à d’autres projets GSoC et que nous avons constaté des obligations contradictoires à l’avenir, nous avons décidé de commencer à travailler avant le début de la période de codage. Nous avons pu finaliser une conception avec des preuves de concept (POC) présentant certaines garanties requises par nos cas d’utilisation et un référentiel GitHub initialisé avant le démarrage officiel.

    Pour progresser plus vite, nous avons séparé nos préoccupations. Rahul a pris la responsabilité du Cache-Filter et Lahiru du Singleton-Service, et avec une interface standard finalisée lors d’une réunion en ligne. Pour s’assurer que nous étions sur la même longueur d’onde et pour trouver des bloqueurs dès le début, Alex a programmé deux réunions : des synchronisations hebdomadaires pour la progression, les bloqueurs, les modifications de conception possibles et les POC, et des synchronisations bihebdomadaires pour parler d’autre chose que du travail. Il nous a également demandé de créer des rapports hebdomadaires dans un document Google distinct à partager avec les autres membres de la communauté. Nous avons utilisé ces rapports pour donner des mises à jour et recevoir des conseils ou des avertissements. Nous avons tous les deux lutté pendant cette étape à différents endroits.

    Rahul: Au début, j’ai eu un peu de mal à suivre un workflow standard et à utiliser des outils (dont Git !) car je voulais aller vite. Avec le recul, cela nous a aidés à éviter des douleurs futures, donc je suis content de les avoir apprises dès le début. Le meilleur conseil que j’ai reçu d’Alex était que c’était notre projet, et nous étions libres de prendre les décisions finales après ses commentaires. Cela m’a donné un sentiment d’appartenance et j’ai commencé à expérimenter davantage, à créer plus de POC et à modifier les spécifications pour travailler avec nous. Ce changement d’attitude m’a permis de mettre en œuvre des fonctionnalités telles que des journaux visibles et des appels uniques qui ont facilité les tests d’intégration et augmenté les performances.

    Lahiru: Pour moi, la chose la plus irritante au début était la courbe d’apprentissage plus raide du langage de programmation Rust. Quand j’ai commencé à programmer en Rust, je criais surtout au compilateur au lieu d’écrire du code. Mais quelques semaines plus tard, nous devenions lentement amis. (Je pense que le compilateur Rust ressemble plus à une nounou surprotectrice. Il n’a aucun intérêt à être votre ami, mais il fera tout son possible pour vous empêcher de vous blesser.) En outre, il existe de grandes différences entre le code Rust écrit par un débutant, intermédiaire et expert. Ces différences existent dans d’autres langages de programmation, comme Java, Golang et C++, mais pas dans la même mesure. Donc, l’un des défis que j’ai eu était de mettre en œuvre non seulement quelque chose qui fonctionne, mais quelque chose qui fonctionne de la manière la plus rustique possible.

    Ce que nous avons appris

    Si vous voulez une liste de choses que nous avons apprises que vous pouvez apprendre aussi si vous participez au Summer of Code, la voici :

    • Collaboration : comment interagir avec la communauté open source, comment donner un contexte à une personne nouvelle dans votre travail
    • Meilleures pratiques pour le développement de logiciels : comment structurer les PR et les commits, comment configurer et rédiger des tests d’intégration ou des tests unitaires
    • Nouvelles technologies : Rust, Golang, Proxy-WASM, Envoy, etc.
    • Soft skills : Comment interagir avec les ingénieurs seniors, comment se présenter
    • Théorie de l’informatique distribuée en action et compétences en résolution de problèmes en général

    Google Summer of Code 2021 a été une expérience enrichissante pour nous deux. Nous avons pu interagir avec de grands ingénieurs comme Piotr Sikora (certains disent que le CPP est un langage infernal, mais il le transforme en une belle prose), Takeshi Yoneda (notre sauveur quand nous en avions le plus besoin), David Ortiz (le mythe, la légende , le co-créateur de Limitador), et (évidemment) Alex Martinez, ainsi que toute l’équipe 3scale. Sans ces personnes, nous ne pensons pas que nous aurions pu atteindre les étapes finales et figurer sur le site Web du GSoC.

    Source

    N'oubliez pas de voter pour cet article !
    1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
    Loading...

    La Rédaction

    L'équipe rédactionnnelle du site

    Pour contacter personnellement le taulier :

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée.