Sprint
La liste et les horaires des sprints sont définies. Pour les derniers détails d'organisation, consultez les personnes à l'accueil ou l'affichage proche.
Modoboa end-user tools v2
Antoine Nguyen,
Adrien Precigout
Jeudi et vendredi de 10 h 00 à 17 h 00
Now that all admin related features are available in the new interface of Modoboa, it's time to say goodbye to the old one and to start the end-user part: webmail, calendars and contacts.
Faire un benchmark de performance DRF/DSG/FastAPI/Flask
Jeudi et vendredi de 10 h 00 à 17 h 00
L'objectif est de coder et déployer une application dans votre framework préféré avec des uses cases simple et définit à l'avance (beaucoup de requetes, gros volume de données, stream) afin de comparer différentes solutions du marchés.
Les framework proposé ne sont qu'une liste non exhausitve. Venez comparé votre framework préféré avec les autres et essayer de l'optimiser avec des pairs.
Atelier trad' de la doc de Python
Jeudi et vendredi de 10 h 00 à 17 h 00
Contribuer à https://docs.python.org/fr/, comme tous les ans :)
LeBureau.coop
Jeudi et vendredi de 10 h 00 à 17 h 00
Nous allons travailler sur l'amélioration du code, de l'infrastructure, de la communication et de l'organisation de LeBureau.coop
LeBureau.coop est une coopérative d'intérêt collectif proposant d'accompagner ses clients dans la gestions des noms de domaine. C'est un bureau d'enregistrement et hébergeur DNS
Hack-a-thon HARP Proxy, un mandataire de transfert d'APIs
Romain Dorgueil,
Arthur Degonde
Jeudi et vendredi de 10 h 00 à 17 h 00
Le but du sprint est de faire avancer le développement et la documentation de HARP Proxy : https://harp-proxy.net/ (documentation : https://docs.harp-proxy.net/).
Toutes les bonnes volontés sont les bienvenues : du néophyte au pythonista confirmé en passant par les amoureux de rust, les artistes peintres du pixel et les alchimistes du frontend, nous ferons de notre mieux pour que tout le monde trouve chaussure à son pied.
Découvrez comment, en quelques minutes, ajouter une interface graphique à vos programmes et les mettre en ligne
Jeudi et vendredi de 10 h 00 à 17 h 00
Le toolkit Atlas est destiné à ceux qui voudraient développer une application pour un usage personnel ou professionnel, mais sans être des professionnels du développement. D'une part, il est très léger (sans doute le plus léger de son genre) et sans dépendance, ce qui facilite son installation. D'autre part, l'interface graphique s’appuie sur les technologies web et sa manipulation ainsi que le traitement des actions associées s'effectuent au sein d'un seul et unique programme développé dans le langage de son choix, dont Python (et sans JavaScript !). Et le toolkit Atlas vous réserve bien d'autres surprises !
Que vous soyez simplement curieux ou que vous projetiez de développer une application, n'hésitez pas à participer à ce sprint.
Débutants Python, votre avis sera précieux pour rendre le toolkit Atlas encore plus accessible aux nouveaux-venus.
Développeurs chevronnés, votre expertise sera plus que bienvenue pour améliorer et enrichir le toolkit Atlas.
Si vous avez développé une application avec une interface texte, profitez de ce sprint pour la doter rapidement et facilement d'une interface graphique grâce au toolkit Atlas.
Si vous enseignez la programmation, découvrez comment rendre vos cours encore plus captivant grâce des exercices que votre auditoire pourra tester avec leur smartphone.
Enfin, si vous avez un microcontrôleur avec MicroPython et Wi-Fi (Raspberry Pi Pico W/WH, ESP32…), n'hésitez pas à le ramener et découvrir comment le piloter à distance en Python grâce au toolkit Atlas (première mondiale).
Matériel requis : un ordinateur portable connecté équipé d'un environnement de développement Python, mais un smartphone ou une tablette suffisent pour expérimenter avec le toolkit Atlas.
Make Open Data : Modern Data Stack Open Source pour données publiques
Jeudi et vendredi de 10 h 00 à 17 h 00
Utilisateurs potentiels par commune, Transactions immobilières par département, Nombre de logements vacants, etc
En voila des données à saupoudrer dans de la BI, des analyses ou des modèles de machine learning pour donner plus de goût aux produits et aux décisions.
Et pourtant... Combien de tickets d'analyse ou d'exploration impliquant ces données ont fini dans le cimetière du Backlog en raison de leur difficile exploitation ?
Make Open Data a pour ambition de rendre les données publiques comestibles en centralisant la logique d'ingestion, stockage, transformation, documentation, tests, etc.
L'objectif de ce sprint est de contribuer l'ingestion, c'est à dire à la partie Extract (de la données source au système) et Load (du système à l'entrepôt de données). Comme par exemple :
Implémentation d'outils : Make Open Data utilise des approches Vanille pour l'Extract (curl) et Load (postgres copy). Certains outils Open Sources (dlt, airbyte, etc) peuvent être utilisées à ces fins, au prix d'abstractions à évaluer.
Réusinage : Actuellement l'ingestion s'execute sur toutes les données, même si elles sont toutes en base. L'objectif est de donner la possibilité à l'utilisateur d'ingérer certaines données (en fonction de la finalité) et/ou la possibilité de ne pas les rafraichir.
Tests : mettre en place les bonnes pratiques de tests unitaires, d'intégration, de gestion d'erreurs et d'automatisation pour rendre l'ingestion plus robuste.
Nouvelle données : si vous avez un besoin particulier, nous serons ravis de l'examiner ensemble.
Optionnel : vous pouvez vous familiariser avec le repo en le déployant en local ou dans le Cloud.
Même si Make Open Data peut être deployé sur une instance Postgre en local, une instance Postgres, avec des données ingérés, dans le cloud peut-être fournie pour faciliter les développements.
Que vous soyez un pro de data ou pas, il s'agit d'une bonne opportunité de se faire la main avec des données en production, volumineuses et ambigues.
Resources
- https://make-open-data.fr/
- https://github.com/make-open-data/make-open-data
- https://docs.getdbt.com/faqs/Project/example-projects
- https://www.data.gouv.fr/fr/organizations/make-open-data/#/datasets
Développements de correctifs et tests des modules Ansible
Jeudi et vendredi de 10 h 00 à 17 h 00
Ansible est un outil libre de configuration et d'orchestration écrit en Python.
Au cours de cet atelier de codage participatif, nous - (@pilou-) et (@mscherer) - vous proposons de contribuer à Ansible et plus particulièrement aux modules Ansible existants:
- corrections de bug existants
- reviews de pull-requests existantes
- nettoyage de code, par exemple:
- suppression des exceptions listées dans 'ansible/test/sanity/*/ignore.txt'
- vérifications module par module que la documentation et le module sont cohérents
- correction des tests instables
- ajout de tests unitaires (tox/mock) et d'intégration (docker/lxc)
- amélioration de la documentation
Ce sprint sera l'occasion pour vous:
- d'échanger à propos du fonctionnement d'Ansible
- de corriger des bugs éventuellement rencontrés
- de contribuer à un logiciel libre utilisant Git et GitHub
Prérequis et configuration nécessaire
Les personnes débutant avec Python et Ansible sont les bienvenues.
Pour participer, sont requis:
- un compte GitHub
- un ordinateur portable supportant l'environnement de développement suivant et permettant de lancer Ansible: * Python (3.8+) * une installation Git fonctionnelle ** un système d'exploitation Linux, *BSD ou Mac. Le nœud de contrôle Ansible ne peut pas être sous Windows, mais une version récente de WSL fonctionne, ainsi qu'une machine virtuelle Linux.
Nous vous accompagnerons si nécessaire dans la mise en place de cet environnement de développement (si votre système d'exploitation n'est pas Windows).
Il est recommandé:
- d'avoir forké le projet GitHub Ansible (ou la collection requise)
- d'avoir parcouru le guide utilisateur (https://docs.ansible.com/ansible/devel/user_guide/index.html), plus particulièrement les sections "Ansible Quickstart Guide", "Getting Started", "Introduction To Ad-Hoc Commands", "Working with Inventory" et "Working With Playbooks".
- d'avoir parcouru le guide du développeur (http://docs.ansible.com/ansible/devel/dev_guide ), notamment les sections "Debugging modules", "Conventions, tips, and pitfalls" et "Module format and documentation".
La documentation est en anglais, si nécessaire, nous accompagnerons les participants pour qui cela est un problème.