Avec l’arrivée de UV, l’écosystème Python entre dans une phase de transformation. Ultra-rapide, moderne et pensé pour simplifier la vie des développeurs, ce nouveau gestionnaire de packages est en train de redéfinir nos habitudes de travail et s’imposer comme la référence incontournable.

Dans ce court article, je voulais revenir brièvement sur UV. La première fois que j’ai entendu parler de cet outil, c’était sur la chaîne ArjanCodes, qui regorge de bonnes pratiques de programmation, de présentations de librairies et d’outils.

Créé par la société Astral, UV est un gestionnaire de packages pour Python écrit en Rust, inspiré par la toolchain de ce dernier.

Des environnements virtuels en un éclair

Je me souviens, il n’y a pas si longtemps, on partageait encore les dépendances des projets dans de simples fichiers requirements.txt. Et quand ce fichier manquait… on était un peu coincés.

Depuis, la PEP 621 a changé la donne. Par défaut, lorsque vous initialisez un projet avec uv init, ce fichier est désormais présent.

Comme tout bon projet Python, il faut ensuite mettre en place un environnement virtuel. Rien de plus simple avec UV : une simple commande uv venv suffit. Pas besoin d’installer un module supplémentaire, c’est aussi direct que ça.

Pour ajouter des dépendances, uv add <package> et préparez-vous, c’est très rapide. La première fois, je me suis même demandé s’il n’y avait pas eu un bug tant l’installation a été instantanée.

Et pour charger toutes les dépendances, rien de plus simple : uv sync.

Un code toujours impeccable

Côté formatage et linting, vous connaissez sans doute Black ou Flake8. Mais Astral propose aussi sa propre solution : Ruff.

Les performances sont impressionnantes, et surtout, vous n’avez besoin que d’un seul outil.

Vous disposez d’une multitude de règles pour adapter votre codebase à vos besoins.

Cerise sur le gâteau : Astral pense à vous et donne plusieurs tutoriels pour intégrer Ruff à votre éditeur préférer.

Le packaging, sans prise de tête

Pendant longtemps, créer une librairie Python pouvait sembler complexe et un peu fastidieux.

Avec UV, ce temps est révolu : uv build et uv publish rendent le packaging et la publication simples et rapides.

Et pour aller encore plus loin, Astral fournit son propre backend de packaging, lui aussi blazingly fast.

Conclusion

Bien que certaines critiques puissent être formulées du fait de sa jeunesse, uv reste pour moi un incontournable pour mes futurs projets Python.

J’ai également conçu un template pour mes futurs projets Python, disponible sur mon GitHub. Il inclut notamment :

• Ruff pour assurer la qualité du code
• Une structure de tests prête à l’emploi
• Pre-commit pour garantir la qualité de chaque commit
• Une intégration continue fonctionnelle avec GitHub Actions

GitHub - CharlyGin/say_hello: Template Python Package using UV

Template Python Package using UV. Contribute to CharlyGin/say_hello development by creating an account on GitHub.

GitHubCharlyGin

Sources

• Astral.sh
• uv - documentation
• ruff - documentation
• ArjanCodes

Si vous utilisez GitHub et que vous vous intéressez un peu au monde du DevOps, vous avez forcément croisé GitHub Actions. Et parfois… on se dit qu’on aurait préféré que nos chemins ne se soient jamais rencontrés.

Sur internet, les avis sont très partagés : certains adorent, d’autres jurent que c’est l’enfer. La vérité, c’est que beaucoup des critiques viennent surtout d’une mauvaise utilisation de l’outil.

Dans cet article, je vous raconte mon parcours avec GitHub Actions, présenté sous la forme d’une “semaine fictive” inspirée de la Genèse : mes débuts chaotiques, mes erreurs, mes découvertes… et comment j’ai fini par passer de l’enfer au paradis.

Jour 1 : La rencontre

Ma première rencontre avec le monde du CI/CD s’est faite avec GitHub Actions. Et, de manière totalement illogique, ma première idée a été de lancer… des tests automatisés. Sauf qu’à l’époque, je n’écrivais quasiment pas de tests. Allez comprendre.

Après une lecture en diagonale de la documentation et quelques essais maladroits, j’ai réussi à obtenir un workflow fonctionnel :

name: CI

on:
  push:
    branches: [ "master", "dev" ]
  pull_request:
    branches: [ "master", "dev" ]

# ...

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x, 18.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npx prisma migrate dev --name init
    - run: npm run build --if-present
    - run: npm test

Tous les voyants étaient au vert. J’étais fier de moi, au sommet de la fameuse “montagne de la stupidité”. J’étais donc encore bien loin d’imaginer la suite.

Avec le recul, je vois bien les problèmes :

• Un seul job fourre-tout : tout était dans “build”, alors que ça faisait plein d’autres choses. Pas très clair.
• Des étapes sans vraie logique : pourquoi lancer une migration Prisma dans un job de CI ?
• Nom trompeur : “build” laissait penser qu’on faisait uniquement de la compilation, alors que c’était un joyeux mélange de build, tests et scripts divers.

Bref, un workflow petit mais déjà bancal. Et comme souvent, quand on commence mal, ça finit rarement bien…

Jour 2 : Les choses sérieuses

Dans GitHub Actions, il y a le mot “action”. Et ça peut vouloir dire deux choses :

1. L’action au sens événement → réaction : un push, un pull request, et hop, ça déclenche un workflow.
2. L’action au sens GitHub : comme le dit la doc, “une extension réutilisable qui peut simplifier votre workflow”.

L’idée est simple : des éditeurs (ou la communauté) créent et testent ces actions, et nous, développeurs, on peut les intégrer directement dans nos workflows sans réinventer la roue. Tout est disponible sur la Marketplace GitHub.

La philosophie est séduisante : un assemblage de “boîtes noires”, chacune spécialisée dans une tâche bien précise.

Mon cas concret : Docker

Pour l’un de mes projets, je voulais automatiser la construction et le déploiement d’images Docker. Objectif : faire ça dans les règles de l’art. Après une petite exploration de la marketplace… bingo ! Docker fournit ses propres actions officielles. Résultat, j’ai rapidement obtenu ce workflow :

name: Build docker image & deploy

# ...

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: # ...
          password: # ...
      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          platforms: linux/amd64,linux/arm64
          push: true
          tags: # ...

Sur le papier, c’est nickel. Mais dans les faits… comment je teste que ce workflow fonctionne ?

Le vrai problème : tester

À ce stade, il n’y a qu’une seule solution : commit et push sur le dépôt. Et si ça ne marche pas ? On lit les logs, on change et on recommence.

Imaginez : on vous demande de développer une feature et la seule façon de la tester, c’est de la déployer en production à chaque essai. Vous voyez le souci ?

Alors oui, ce n’est pas dramatique pour un projet perso on s'en fiche sinon avec un peu de stratégie de branches, ça limite la casse. Mais ça reste franchement frustrant.

Et le pire, c’est qu’il n’existe pas de solution native pour tester ses workflows en local (on parlera d’act un peu plus tard 👀). Résultat : des commits en série, des allers-retours chronophages… et quelques heures de cris et de larmes dans le processus.

Jour 3 : Un peu de clarté

Comme je l’ai mentionné plus tôt, l’une des erreurs les plus courantes avec GitHub Actions, c’est de vouloir tout entasser dans un seul job d’un seul workflow.

Résultat ? On se prive d’une vision claire de ce qui se passe, et le debug devient vite un enfer.

Le problème du “fourre-tout”

Reprenons mon premier exemple : si le job s’appelle build et qu’il échoue, que s’est-il passé exactement ?

• Est-ce une dépendance qui a cassé ?
• Un problème réseau ?
• Une erreur dans la compilation ?
• Ou bien un test qui a planté ?

Impossible de le savoir sans plonger dans les logs. Et plus votre workflow grossit, plus ça devient pénible.

La bonne pratique : découper

La solution est simple : découper le workflow en plusieurs jobs clairs et indépendants.

Un schéma générique :

• test → exécuter la suite de tests
• build → compiler / packager l’application
• deploy → livrer le produit

⚠️ Attention aux parallèles

Par défaut, GitHub Actions exécute les jobs en parallèle. Ce qui est souvent très bien pour gagner du temps… sauf quand on veut imposer un ordre logique (ex. : déployer uniquement si les tests et le build sont passés).

Pour gérer ça, il suffit d’utiliser l’attribut needs pour indiquer les dépendances entre jobs. Exemple :

name: CI

on:
	...

jobs:
  test:
	# ...
  build:
    needs: [test]
	# ...
  deploy:
	needs: [build]
	# ...

Avec ça, vos workflows deviennent beaucoup plus lisibles, et vos futurs “vous” (ou vos collègues) vous remercieront le jour où il faudra comprendre pourquoi “ça marche pas”.

Jour 4 : Act, la fausse bonne idée ?

Un jour, au milieu de mes errances, je suis tombé sur ce qui semblait être l’outil qui allait me sauver de mes commits compulsifs et de mes logs interminables.

Son nom : act.
Sa promesse : exécuter vos workflows GitHub Actions directement en local.

Sur les forums et ur YouTube, tout le monde en parlait. Je me suis dit : “ok, c’est peut-être la lumière au bout du tunnel”.

Mes premiers pas avec act

Au début, j’étais sceptique : encore un outil à installer, encore un truc à apprendre. Mais à force de pleurer sur mes workflows cassés, j’ai fini par céder.

Et je dois avouer : la prise en main est agréable. L’outil est bien conçu, avec un affichage clair et lisible. On sent qu’il y a eu du travail derrière.

… et les ennuis commencent

Mais très vite, les premiers bugs sont apparus.

Un de mes workflows échouait en local alors qu’il passait parfaitement sur GitHub. Après quelques recherches, je suis tombé sur cette issue qui nous explique que certaines images utilisées par act n’ont pas les mêmes dépendances que les runners GitHub officiels.

Et là, on comprend le problème :

• act n’est pas un outil officiel de GitHub.
• Il simule un runner en utilisant des images Docker gigantesques (plusieurs Go).
• Résultat : votre machine locale se transforme en centrale nucléaire juste pour lancer quelques scripts.
• Et pour couronner le tout, certaines actions… ne fonctionnent tout simplement pas.

Mon ressenti

À mon niveau, act s’est révélé être une fausse bonne idée : une belle machine à gaz, qui promet beaucoup mais qui ne tient pas toujours ses promesses.

Jour 5 : Les actions, deuxième fausse bonne idée ?

Bon… on ne va pas se mentir : jusque-là, c’était pas gagné.

Toujours pas moyen de tester facilement mes workflows, donc commits en rafale, temps perdu, et nerfs mis à rude épreuve.

C’est donc ça la vie, Manny ?

Le vrai problème : les actions elles-mêmes

En prenant du recul, j’ai réalisé que la racine du problème n’était pas GitHub Actions en soi… mais les actions.

Celles qu’on nous vend comme la solution miracle sont en réalité parfois des pièges qui nous enferment et rendent le travail encore plus compliqué.

Attention, je ne dis pas qu’elles sont toutes mauvaises !

• Certaines sont incroyables : par exemple celles qui gèrent les artifacts, super pratiques pour partager des fichiers entre jobs (voire entre workflows).
• Mais d’autres… franchement, leur valeur ajoutée est faible par rapport aux galères qu’elles amènent. Exemple typique : les actions pour builder et pousser une image Docker. Ça peut paraître sexy, mais en pratique, quelques commandes shell suffisent largement.

Ma solution : reprendre la main

À partir de là, j’ai décidé de réduire au maximum ma dépendance aux actions.

J’ai créé un dépôt dédié où je centralise mes scripts Python pour effectuer des tâches génériques (tag, release, docker, etc.), peu importe la techno du projet.

Ça me donne une base testable, réutilisable et indépendante.

Pour lancer un process, il me suffit de cloner le repo, installer les dépendances… et c’est parti !

Mon dépôt est disponible ici :

GitHub - CharlyGin/pipelines

Contribute to CharlyGin/pipelines development by creating an account on GitHub.

GitHubCharlyGin

Exemple d’utilisation dans un workflow :

on:
	# ...
	
jobs:
	# ...
	release:
    runs-on: ubuntu-latest
    needs: [test, build, check-version]
    if: needs.check-version.outputs.should-release == 'true'
    permissions:
      contents: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: ${{ github.sha }}
      - name: Install uv
        run: |
          sudo apt update
          sudo apt install -y curl
          sudo curl -LsSf https://astral.sh/uv/install.sh | sh
        shell: bash
      - name: Clone pipelines
        run: |
          cd ~
          git clone https://github.com/CharlyGin/pipelines.git
        shell: bash
      - name: Install dependencies
        run: |
          cd ~/pipelines
          uv sync
        shell: bash
      - name: Run Tag & Release
        run: |
          VERSION=$(jq -r '.version' package.json)
          uv run ~/pipelines/scripts/tag_and_release.py --pre-release --tag $VERSION --app $GITHUB_WORKSPACE --build-dir /dist
        env:
          GH_TOKEN: ${{ secrets.GH_TOKEN }}
        shell: bash

Clarifier les workflows

Autre souci : les petits bouts de scripts shell éparpillés dans les steps.

Ça pollue la lecture des workflows et c’est une nouvelle source de bugs (puisqu’impossible à tester directement).

Ma solution : les déplacer dans des scripts dédiés, par exemple dans un dossier .github/scripts.

Par conséquent, mes workflows ne contiennent plus de logique. Ils se contentent de déclencher des scripts clairs, testables et versionnés. La lisibilité est bien meilleure, et le debug devient plus simple.

Jour 6 : Un peu (beaucoup) d'organisation

Arrivé à ce stade, j’avais fait du ménage dans mes workflows en externalisant mes scripts. Pourtant, un nouveau problème est apparu. Je me retrouvais avec les mêmes scripts appelés plusieurs fois.

Par exemple :

• une fois pour tester les PRs,
• une fois pour faire une pré-release,
• et encore une autre pour la release finale.

Bref, beaucoup de répétition, et une forte envie de factoriser tout ça.

La solution : workflow_call

Heureusement, GitHub Actions propose une fonctionnalité taillée pour ça : l’événement workflow_call.

L’idée est simple :

• créer un workflow par fonction (ex. : test.yml, build.yml, deploy.yml),
• leur passer des paramètres (par exemple is_pre-release),
• et les appeler depuis d’autres workflows.

C’est propre, c’est réutilisable et ça réduit énormément la duplication.

Plus de flexibilité : workflow_dispatch

J’ai ajouté en bonus l’événement workflow_dispatch.

Pourquoi ? Pour pouvoir lancer un workflow manuellement en cas de besoin (ex. : un bug qui bloque la release automatique).

Autre avantage, les workflows s’exécutent dans l’environnement GitHub et donc avec accès aux secrets définis dans le repo, sans que les autres développeurs aient besoin de les stocker (ni d’y avoir accès, d’ailleurs 😅).

Jour 7 : Conclusion

Beaucoup de rage, quelques larmes et un certain nombre de commits inutiles ont été sacrifiés au cours de cette semaine fictive. Mais comme on dit : après la pluie vient le beau temps.

En chemin, j’ai appris :

• à éviter les jobs fourre-tout,
• à me méfier des fausses bonnes idées (act ou certaines actions),
• à privilégier mes propres scripts pour garder la main,
• et à organiser mes workflows avec workflow_call et workflow_dispatch pour plus de clarté et de souplesse.

GitHub Actions vaut clairement le coup. Cet outil peut sembler compliqué au début, mais il est puissant et flexible. Les actions intégrées sont souvent pratiques, mais il ne faut pas hésiter à reprendre la main quand elles deviennent trop contraignantes. Avec de l’organisation et de la patience, on passe vite de l’enfer au paradis.

Vous pouvez trouver un exemple concret de cette structure dans un template de package Python que j’ai créé :

GitHub - CharlyGin/say_hello: Template Python Package using UV

Template Python Package using UV. Contribute to CharlyGin/say_hello development by creating an account on GitHub.

GitHubCharlyGin

Sources

• GitHub Actions Documentation
• Unpopular opinion: why do you hate GitHub actions ? - Reddit
• how do you test github actions - Reddit
• I'll think twice before using GitHub Actions again - Hacker News

La gestion des fichiers statiques (images, scripts, feuilles de styles) dans mes applications a longtemps été un vrai sujet pour moi. À plusieurs reprises on m'a déconseillé de les déposer dans le gestionnaire de version. C'est pourtant ce que j'ai fait par simplicité. Mais aujourd’hui, j’ai franchi une étape : je suis passé à une solution plus propre et plus performante… un CDN maison.

Le livre qui tout déclenché

Récemment, je suis tombé sur Écoconception web – Les 115 bonnes pratiques de Frédéric Bordage. Dans cet ouvrage, l’auteur, ancien développeur et architecte logiciel, explique comment réduire l’impact environnemental d’un site web en prenant en compte l’ensemble de son cycle de vie : de la conception jusqu’à sa fin de vie, en passant par le développement, la maintenance et l’exploitation.

Couverture du livre Écoconception web - Les 115 bonnes pratiques

L'éco-conception, levier de performance

Au premier abord, on pourrait s’attendre à un discours moralisateur, ou à une invitation à revenir à des sites ultra-sobres dignes du web des années 90. Mais ce n’est pas le cas.

L’approche défendue par Frédéric Bordage repose sur un principe simple : consommer moins de ressources, c’est aussi améliorer les performances... et réduire les coûts. Cela passe par l’optimisation du code, une infrastructure mieux calibrée, et des choix techniques plus pertinents.

Loin d’un discours alarmiste, cette démarche repose sur une réelle expertise technique. L’éco-conception, bien appliquée, n’est pas une contrainte mais dénote d'une qualité supérieure.

Rester critique et adapter

Même si je recommande vivement ce livre, il est important de garder un esprit critique et de contextualiser les recommandations proposées.

Toutes les bonnes pratiques évoquées ne sont pas nécessairement applicables telles quelles. Certaines peuvent même être contre-productives selon votre projet.

Par exemple, l’ouvrage cite G-WAN, un serveur web aux performances impressionnantes, bien supérieures à celles de Nginx. Mais ce qu’il ne précise pas, c’est que G-WAN n’est plus maintenu depuis 2016. Ce genre de détail peut induire en erreur si l’on ne creuse pas un peu.

Mon serveur CDN

Revenons nos moutons. Après la lecture du livre de Frédéric Bordage, j’ai pu établir une liste claire de ce qui me semblait indispensable pour construire un CDN adapté à mes besoins.

Maximiser la mise en cache

Pour éviter que le navigateur du client ne redemande à chaque fois les fichiers statiques (styles, scripts, images…), il est crucial de configurer un cache efficace. Cela permet non seulement de gagner en bande passante, mais aussi d’alléger la charge serveur.

En production, ces fichiers changent rarement. Le principal inconvénient serait qu’un utilisateur doive vider manuellement son cache… ce qui reste gérable (quoique ?).

Pensez donc à ajouter expires max; dans vos directives Nginx pour indiquer une durée de cache très longue.

Compresser les fichiers textes

Toujours dans une optique de réduction du poids des échanges, la compression des fichiers texte (HTML, CSS, JS, JSON, etc.) à la volée est un incontournable.

Deux méthodes sont couramment utilisées : Brotli, plus performante, et Gzip, à défaut.

Voici un exemple de configuration :

# gzip
gzip              on;
gzip_vary         on;
gzip_proxied      any;
gzip_comp_level   6;
gzip_types        text/plain text/css text/xml application/json application/javascript application/rss+xml application/atom+xml image/svg+xml;

# brotli
brotli            on;
brotli_comp_level 6;
brotli_types      text/plain text/css text/xml application/json application/javascript application/rss+xml application/atom+xml image/svg+xml;

Si vous avez accès à une version payante de Nginx, l’activation de Brotli est simple. Elle peut se faire via un gestionnaire de paquet classique. Sinon, il faudra le compiler depuis les sources. Le README du dépôt GitHub de Brotli vous guidera, et en cas de doute mon Dockerfile pourra aussi vous servir d'exemple.

💡 Cette compression est encore plus efficace si vous minifiez les fichiers en amont (suppression des commentaires, espaces inutiles…).

Utiliser HTTP/2

La version 2 du protocole HTTP apporte de nombreuses améliorations en matière de performance, notamment grâce au multiplexage.

Pour en savoir plus, je vous recommande cet excellent article sur Zeste de Savoir. Il explique très bien les principes et l’implémentation derrière un reverse proxy.

Dans votre configuration Nginx, vous pouvez l'activer avec la directive http2 on;.

Réduire les logs en production

Les logs sont précieux en développement ou pour diagnostiquer un incident. Mais en production, ils peuvent vite devenir verbeux, peu utiles et consommer des ressources.

L’idée ici est de ne garder que l’essentiel, à savoir les avertissements et erreurs. Exemple de configuration :

access_log off;
error_log /var/log/nginx/error.log warn;

location = /favicon.ico {
    log_not_found off;
}

location = /robots.txt {
    log_not_found off;
}

Supprimer les cookies inutiles

Dans le contexte d’un CDN, les cookies n’ont souvent aucune utilité. Les inclure dans les réponses ne fait qu’augmenter inutilement le poids des requêtes.

Voici comment les supprimer proprement :

proxy_hide_header Set-Cookie;
fastcgi_hide_header Set-Cookie;
add_header Set-Cookie "" always;

Conclusion

Vous pouvez retrouver l’intégralité du projet sur GitHub :

GitHub - CharlyGin/Content-Delivery-Server: Content delivery server

Content delivery server . Contribute to CharlyGin/Content-Delivery-Server development by creating an account on GitHub.

GitHubCharlyGin

Et l’image Docker associée est disponible sur Docker Hub, prête à être utilisée.

Ce projet a été l’occasion idéale pour me replonger dans la configuration Nginx et concevoir une solution adaptée à mes besoins en termes de distribution de contenu.

La lecture des 115 bonnes pratiques m’a ouvert de nouvelles perspectives, et j’ai hâte de continuer à les explorer dans mes prochains projets.

Bien sûr, il reste des pistes d’amélioration, notamment en intégrant des outils comme la minification automatique ou la suppression des métadonnées. Une version 2 plus complète, orientée performance et automatisation, pourrait voir le jour ?

Sources

• Les 115 bonnes pratiques 5ème édition - Livre de Frédéric Bordage
• NGINXConfig - Digital Ocean - Générateur de configuration Nginx en ligne
• Nginx Cookbook - F5 - Recueil de bonnes pratiques pour Nginx
• ngx_brotli - Github - Module Brotli pour Nginx

Pratiquant de musculation depuis plusieurs années, je me suis récemment intéressé au monde des kettlebells, un univers fascinant qui fera sûrement l'objet de mon prochain projet.

Au fil de mes recherches, j’ai découvert l’excellent livre du chercheur Martin Gibala, The One Minute Workout. Dans ce dernier, le professeur nous explique son parcours et comment lui et son équipe en sont venus à la conclusion qu'un activité physique courte mais intense avait plus d'effets bénéfiques qu'une activité longue à faible intensité.

Dans son livre, l'auteur propose plusieurs exemples d'entraînements et incite les lecteurs à concevoir leurs propres séances. C'est dans cette optique-là que m'est venue l'idée de créer une application pour faciliter cette opération, Chrono-Sport.

Un peu de théorie

Avant de commencer le développement, il m’a fallu réfléchir à une manière de généraliser un entraînement dit "à haute intensité".

Dans la majorité des cas, ce type d’entraînement se structure autour de trois phases :

1. L’échauffement : il permet d’augmenter la température corporelle et de lubrifier les articulations.
2. La phase de travail : elle se compose de cycles comprenant un ou plusieurs exercices réalisés à différentes intensités, pendant un temps donné.
3. Le retour au calme : il vise à faire redescendre le rythme cardiaque et retrouver une respiration normale.

Un cycle de la phase de travail peut être vu comme un round dans lequel un ou plusieurs chronomètres se succèdent.

Cette observation m’a permis de modéliser un entraînement de manière abstraite, comme une succession de blocs chronométrés.

Voici un schéma illustrant le déroulé théorique d’une séance de cardio :

Schéma théorique du déroulé d'une séance de cardio

Si on applique ce modèle au format Tabata, on obtient la structure suivante :

Schéma déroulé d'une séance de tabata

Grâce à sa simplicité et à sa flexibilité, ce modèle m’a semblé suffisamment robuste pour servir de base à l’application.

Un peu de technique

Jusqu’à présent, j’ai toujours développé mes projets web avec le framework VueJS. Pour cette nouvelle expérience, j’ai voulu explorer une alternative moins courante. Plutôt que de se tourner vers les géants comme React ou Angular, j'ai choisi SolidJS. Sa simplicité d’apprentissage et ses excellentes performances m’ont rapidement convaincu.

J'ai également décidé de le combiner avec la puissance de TypeSript pour le typage, ainsi qu'avec Sass pour mieux organiser et isoler le style de mes composants.

Côté qualité de code, j’ai intégré Prettier, qui formate automatiquement le code à chaque sauvegarde. Toutefois, je n'ai pas mis en place de linter comme ESlint ou ni d'outils de pré-commit tels que Husky. Étant donné qu’il s’agit d’un projet personnel, j’ai jugé leur valeur ajoutée trop faible par rapport à leur mise en place.

Pour écrire le code, j'ai utilisé Cursor, une première pour moi. Et je dois dire que j’ai été agréablement surpris. Bien que les suggestions ne soient pas toujours parfaites, l’éditeur m’a permis de gagner un temps considérable sur certaines tâches.

Enfin, côté CI/CD, je n’ai pas voulu mettre en place une pipeline complexe avec Github Actions. Par souci de simplicité, je me suis tourné vers Vercel , qui me permet de déployer gratuitement deux environnements :

• la branche dev pour l’environnement de développement
• la branche main pour la production

Grâce à une redirection, l’application est accessible via mon nom de domaine personnalisé : chrono-sport.charly-ginevra.fr

Voici un schéma qui résume cette architecture :

Un peu de pratique

Maintenant, il est temps de mettre les mains dans le cambouis et d'utiliser l'application.

Vous pouvez y accéder via ce lien : https://chrono-sport.charly-ginevra.fr

Menu principal

Voici une capture d’écran du menu principal de l’application. On y trouve trois sections distinctes :

• Classic : contient une horloge ainsi qu’un chronomètre simple.
• Workouts : propose des entraînements inspirés du livre The One Minute Workout.
• Customs : permet (pour l’instant) d’accéder à un entraînement vierge, idéal pour créer un programme sur-mesure à partir de zéro.

Paramétrer son entra​nement

Pour illustrer les fonctionnalités, prenons l’exemple de l’entraînement Tabata.

Après avoir sélectionné l’entraînement, vous arrivez sur la page de démarrage.
Un chronomètre peut se trouver dans trois états : initial, en cours, ou en pause.
Ces états peuvent être modifiés grâce aux boutons start, stop et reset.

Voici un automate illustrant ce comportement :

En faisant défiler la page, vous accédez aux paramètres de l’entraînement (voir capture ci-dessous).

C’est ici que vous pouvez modifier la structure de la séance. Voici un récapitulatif des actions associées aux boutons de cette interface :

Et maintenant ?

À l’heure actuelle, le résultat me satisfait dans la mesure où l’application répond aux besoins fonctionnels que je m’étais fixés. Cela dit, il reste encore beaucoup de travail avant d’arriver à un produit vraiment abouti. On pourrait qualifier l’état actuel de proof of concept : une base fonctionnelle, mais encore loin d’être polie.

Sur le plan fonctionnel

Soyons honnêtes : l’interface est encore assez brute (mention spéciale à la page About 😭).
Plusieurs pistes d’amélioration pourraient grandement enrichir l’expérience utilisateur, comme :

• La possibilité de sauvegarder ses entraînements personnalisés
• Un outil pour générer des séances en temps réel
• Un système de statistiques pour suivre et comparer ses performances

Sur le plan technique

Comme mentionné dans la section précédente, certains outils de développement manquent encore à l’appel.
Intégrer un linter, des hooks de commit ou une configuration CI plus robuste permettrait :

• d’améliorer la qualité du code
• de mieux structurer les futurs développements

En conclusion

Ce projet m’a déjà beaucoup apporté, tant sur le plan technique que pratique. Et au vu du travail qu’il reste à faire, je suis convaincu qu’il a encore beaucoup à m’apprendre. 😁💪

Avec pour objectif de réaliser des tests sur une machine Debian, je me suis retrouvé dans le besoin de passer par une machine virtuelle.
Utilisant un MacBook Pro M1 et après quelques échecs avec VirtualBox 🤮, mon choix s'est porté sur le logiciel de virtualisation UTM 👼:.

GitHub - utmapp/UTM: Virtual machines for iOS and macOS

Virtual machines for iOS and macOS. Contribute to utmapp/UTM development by creating an account on GitHub.

GitHubutmapp

Après la création de la VM et l'installation du système d'exploitation, j'ai été confronté à un gros problème de résolution d'écran.

Cela s'explique du fait que la machine hôte n'arrive pas à communiquer avec la VM, ce qui l'empêche de s'adapter.

Pour résoudre le problème, depuis la VM, ouvrez un terminal et exécutez la commande suivante :

sudo apt install spice-vdagent

ou celle-ci si vous êtes sur une machine Red Hat :

sudo yum install spice-vdagent

Redémarrez la VM et le problème aura disparu. 😁

Source

• Documentation UTM
• Documentation Red Hat

Récemment, j'ai voulu mettre en place un homelab pour mes futurs projets.

Problème n°1 : Je n'en ai pas besoin tout le temps (surtout des environnements de tests)
Solution : Éteindre la ou les machines quand on ne s'en sert pas. Merci captain Obvious.

Problème n°2 : Si je ne suis pas chez, comment je fais pour allumer mes appareils à distance ?
Solution : Le Wake-On-Lan !

C'est donc comme ça que m'est venu l'idée de Wake-Up!

GitHub - TheBaronMc/wake-up

Contribute to TheBaronMc/wake-up development by creating an account on GitHub.

GitHubTheBaronMc

Plutôt que d'ouvrir un port SSH en DNAT sur la box et de lancer un script à distance, Wake-Up! permet de réveiller les machines de sont réseau depuis une interface web sécurisée par un mot de passe.

Toute la mise en place est décrite dans le README mais je vais la reprendre ici.

Vous devez d'abord créer un fichier de configuration dans lequel vous allez renseigner le mot de passe pour accéder à l'interface, le port, les machines et d'autres paramètres. Vous trouverez un exemple ci-dessous :

password: wake-up!
api_enabled: false
web_enabled: true
port: 12345
groups:
  DHCP:
    Server1:
      address: 9D:2B:4F:7A:12
    Server2:
      port: 6
      address: A0:8C:3D:5E:9F:76
hosts:
  RaspberryPi:
    address: F1:6A:4B:3C:9D:21
  NAS:
    port: 6
    address: B3:11:8E:9F:4A:5D

Lancez la commande suivante :

$ docker run -v ./configuration.yml:/app/configuration.yml -p 8080:<port> baronmc/wake-up:1.0.0 

Pour terminer, depuis un navigateur, connectez-vous à l'adresse localhost:8080 et voilà le résultat :

Si jamais vous souhaitez intégrer ce fonctionnement dans vos process, Wake-Up! dispose d'une API REST. Vous trouverez la liste des routes dans le README.

Depuis quelques temps, je cherchais une façon originale de présenter mon cv dans un portfolio.

Voulant mettre en avant l'aspect développeur informatique, l'idée d'un site web qui serait une simulation d'un terminal m'est apparue.

Avant de penser à la conception et la réalisation du projet, je voulais une idée plus précise de à quoi je voulais que mon portfolio ressemble. J'ai donc réalisé des planches avec l'outil Figma. Simple et puissant, cet outil est devenu un incontournable pour la phase de réflexion de mes projets.

Cliquer ici dans le cas où la page Figma ne se chargerais pas

Au niveau des technologies, pour du développement web, il n'y a pas beaucoup de solutions. Javascript est un incontournable. Cependant, afin de réaliser un projet assez conséquent et de manière propre, Typescript apporte un vrai plus en termes de structure et de lisibilité du code.

Pour ne pas partir de zéro, j'ai aussi choisi d'utiliser le Framework Vue. Je l'ai déjà utilisé par le passé sur d'autres projets avec toujours une bonne expérience et un résultat au rendez-vous.

Ce projet m'a permis d'utiliser deux outils que je voulais découvrir depuis un certain temps déjà : Bun, un environnement d'exécution Javascript réputé pour sa rapidité, et Github Actions, pour gérer la CI/CD.

Au moment où j'écris ces lignes, le projet dispose d'un système de fichier basique, et de quelques commandes de base (ls, cd, echo, mkdir, ...). Pour visualiser les informations relatives à mon CV, ce qui était l'objectif du projet, il faut lancer la commande help qui nous dit toutes les informations à récupérer et comment le faire.

A l'avenir, l'objectif est d'ajouter les droits d'accès aux fichiers, un moyen de faire des petits scripts et un peu de styles pour donner un look plus rétro.

Retrouvez le résultat à l'adresse portfolio.charly-ginevra.fr et le code du projet sur Github. :-)

GitHub - TheBaronMc/portfolio-terminal: Shell Simulation

Shell Simulation. Contribute to TheBaronMc/portfolio-terminal development by creating an account on GitHub.

GitHubTheBaronMc