bikebuddy

BikeBuddy est une application web personnelle de journalisation de trajets. Son objectif déclaré est simple : votre trajet, vos itinéraires, vos souvenirs. Les utilisateurs téléchargent des traces GPX exportées de n'importe quelle sortie, qu'il s'agisse de cyclisme ou de moto, et l'application les restitue sous forme d'itinéraires sur une carte. Des photos peuvent être jointes aux tours, transformant des données de trace brutes en un récit illustré. Ce que fournit le dépôt Le README décrit un front-end servi comme contenu statique depuis GitHub Pages, associé à un back-end serverless sur Azure Functions v4. La persistance utilise Cosmos DB, et les médias tels que les photos sont destinés à résider dans Blob Storage, d'après les badges technologiques affichés. Node.js 24 ou une version ultérieure est requis. Une capture d'écran dans la documentation montre une vue cartographique avec des itinéraires de trajet à côté d'une barre latérale de tour. Les cartes sont dessinées avec Leaflet, et la validation est gérée par Zod. La pile technologique est entièrement composée de JavaScript et TypeScript. Prise en main Tous les scripts d'aide s'exécutent via un point d'entrée unique : lancez le script shell buddy.sh suivi d'un groupe et d'une commande. Le flag d'aide liste tout ce qui est disponible. Deux commandes documentées couvrent le parcours courant : une commande de configuration de développement qui installe les outils et les modèles de configuration, et une commande de démarrage global (start-all) qui lance la pile locale complète sur le port localhost 4280. Docker doit être en cours d'exécution pour la configuration. Documentation La documentation complète se trouve dans le dossier docs, organisée selon le framework Diátaxis : - Tutoriel : un guide de démarrage pas à pas. - Guides pratiques (How-to) : un guide utilisateur et un guide développeur couvrant le développement local, l'authentification et les jetons, ainsi que le déploiement, plus un guide pratique distinct sur l'infrastructure. - Référence : pages d'architecture et de configuration. - Explication : décisions de conception et rapport de coûts. Un guide de contribution documente les conventions pour les contributeurs et est référencé depuis le README. Infrastructure et outillage L'infrastructure est décrite comme du code géré avec OpenTofu, et le projet cible Azure comme fournisseur de cloud. Le déploiement de la partie statique passe par GitHub Pages, avec des workflows s'exécutant sur GitHub Actions. Les outils de qualité et de sécurité sont visibles dans les badges du README : - ESLint et Prettier pour le linting et le formatage. - Vitest pour les tests unitaires, avec une couverture rapportée via Codecov. - Playwright pour les tests de bout en bout, selon la carte technologique. - Stryker pour les tests de mutation, avec un rapport sur tableau de bord public. - OpenGrep pour les tests de sécurité statiques des applications, zizmor pour le durcissement de GitHub Actions, et le scan de code CodeQL. - Des hooks pre-commit pour les vérifications locales. - Un badge de workflow de passerelle indiquant une porte de qualité CI. Licence et état du projet Le projet est publié sous licence MIT. Le README renvoie vers un badge de dernier commit indiquant une activité récente, mais aucune affirmation n'est faite ici concernant la maturité de la version, les exigences d'hébergement au-delà de celles documentées, ou les caractéristiques de performance. À qui cela peut convenir À quelqu'un qui souhaite un registre autogéré de ses trajets, avec visualisation cartographique et ajout de photos, et qui est à l'aise avec le déploiement d'une pile basée sur Azure ou l'exécution de l'environnement de développement local basé sur Docker. Les développeurs recherchant un exemple concret de front-end statique associé à Azure Functions et Cosmos DB, avec une chaîne d'outils de test et de sécurité étendue, pourront également trouver ce dépôt utile comme référence.