Astuce sur Olivier DOSSMANN

Publier son blog Hugo sur Gitlab Pages

Tue, 28 Apr 2026 18:18:10 +0200

Introduction

Il y a plus d’un an je travaillais en équipe dans le cadre du passage d’un titre professionnel d’Administrateur Système DevOps. Pour étayer nos travaux nous avions choisi, entre autre, de publier un site à l’aide du très célèbre moteur de blog statique Hugo. Nous utilisions la plateforme Gitlab CI dont je vous parlais déjà pour automatiser le déploiement du site sur Gitlab Pages. C’est une plateforme pour publier gratuitement ses sites webs statiques.

Aujourd’hui nous allons voir comment publier son blog/site fabriqué avec Hugo sur Gitlab Pages, ce qui ressemblera beaucoup au tutoriel officiel de Gitlab pour construire et déployer un site Hugo. Le présent tutoriel s’appuie sur l’article précédent concernant les premiers pas avec Hugo, moteur de blog statique, je vous invite à en prendre connaissance - excepté si vous savez déjà utiliser Hugo.

Dans un premier temps nous listerons les pré-requis à l’usage de ce tutoriel, puis nous aborderons le nommage du dépôt Gitlab lors de sa création. Après quoi nous agrémenterons ce dernier avec un site Hugo (avec une configuration minime). Et nous attaquerons l’automatisation de la compilation du site sur Gitlab CI pour finalement terminer sur la publication du blog/site.

Photo trouvée sur Wikimedia Commons concernant le Tanuki du Japon sous Licence CC BY-SA 4.0.

Pré-requis

savoir utiliser Git,
avoir un compte Gitlab et avoir déposé une clé SSH sur son profil Gitlab pour y accéder,
installer Hugo sur sa machine et savoir l’utiliser (cas échéant je vous invite à lire mon article nommé « Premiers pas avec Hugo, moteur de blog statique »).

Ce « tutoriel » peut sembler long la première fois, mais il vaut la peine d’être accompli jusqu’au bout. Les fois d’après sont plus rapides, plus faciles et ne durent que quelques minutes seulement ! Je l’ai déjà fait en moins de 10 minutes - si je devais être une référence 🤣.

Création du dépôt et règles de nommage

Dans le principe, c’est très simple :

vous créez un nouveau dépôt à l’aide de « Nouveau projet/dépôt » puis « Créer un projet vide »,
vous renseignez les champs demandés, par exemple pour l’URL de projet on choisit son pseudo dans le menu déroulant,
puis il s’agit de donner un nom spécifique au dépôt et un slug correspondant.

Parlons du nom du dépôt (et du champ « identifiant slug » hérité de ce nom).

Imaginons que vous ayez comme pseudo blankoworld, pour ne viser personne 🤣 . À défaut dans Gitlab Pages votre accès est : blankoworld.gitlab.io. Essayez : il n’y a rien pour l’instant à cette URL.

Pour faciliter les choses et bénéfier d’une adresse URL permettant d’accéder à votre blog/site statique, je vous suggère fortement de créer un dépôt nommé blankoworld.gitlab.io (oui oui, avec le domaine dans le titre du dépôt). C’est la méthode la plus simple. Bien évidemment, changez blankoworld par votre pseudo choisi sur Gitlab.

Si au contraire vous créez un dépôt nommé veille par exemple, il sera finalement disponible à l’adresse blankoworld.gitlab.io/veille. C’est ce qui permet de bénéficier de plusieurs blog/sites statiques sans être limité par Gitlab.

Il est aussi possible d’utiliser un groupe Gitlab, en ce cas cela fonctionne avec le nom du groupe, par exemple odtre.gitlab.io pour le groupe nommé odtre.

Et si vous êtes intéressés par l’usage d’un nom de domaine en lieu et place de celui fourni par Gitlab pour votre blog/site statique généré ; je vous invite à lire la documentation Gitlab au sujet des noms de domaines personnalisés.

Autre point important : le niveau de visibilité de votre dépôt Git. Si le dépôt est public, ça facilitera possiblement les actions pour afficher le site final au reste du monde. Nous verrons cela en détail plus tard.

Laissez « Initialiser le dépôt avec un README » coché, comme ça nous aurons déjà un dépôt Git prêt à être récupéré.

Récupération initiale du dépôt et préparation

En bref, ça pourrait faire quelque chose comme les lignes suivantes dans une invite de commande :

PSEUDO_GITLAB=VOTRE_PSEUDO # par exemple blankoworld
DEPOT=VOTRE_DEPOT          # par exemple blankoworld.gitlab.io
git clone git@gitlab.com:${PSEUDO_GITLAB}/${DEPOT}
cd "${DEPOT}"
hugo new site . --force    # le point définit le dossier courant
git submodule add https://github.com/zhaohuabing/hugo-theme-cleanwhite themes/cleanwhite
echo "theme = 'cleanwhite'" >> hugo.toml
echo "public/" >> .gitignore
sed -i "s#baseURL = \(.*\)#baseURL = 'https://${DEPOT}/'#" hugo.toml
git add . # on ajoute les fichiers au prochain commit git
git commit -m "chore: Hugo initialized" # création du prochain commit
git push

Procédons étape par étape avec des explications.

On va récupérer notre dépôt Gitlab à l’aide de la commande suivante :

git clone git@gitlab.com:blankoworld/blankoworld.gitlab.io

blankoworld (le premier qui apparaît) est notre pseudo sur Gitlab, mais ça peut aussi être le “groupe” Gitlab sur lequel nous avons créé le dépôt (rappelez-vous le menu déroulant qui demandait l’URL du projet),
blankoworld.gitlab.io est le mot clé que je vous avais demandé de fabriquer en fonction de votre pseudo/groupe pour faciliter l’accès. Je dis mot-clé car il sera repéré par Gitlab pour mettre à disposition le site contenu dans le dépôt directement à la racine de l’adresse URL blankoworld.gitlab.io.

Ensuite on se rend dans ce répertoire pour préparer un site Hugo. D’après mon tutoriel sur la fabrication initiale d’un site Hugo, en choisissant le thème CleanWhite pour Hugo, cela ressemblerait à quelque chose comme :

cd blankoworld.gitlab.io  # pour se rendre dans le répertoire qu'on vient de récupérer avec Git
hugo new site . --force   # `--force` prend en compte les fichiers existant du dépôt Git
git submodule add https://github.com/zhaohuabing/hugo-theme-cleanwhite themes/cleanwhite
echo "theme = 'cleanwhite'" >> hugo.toml

Pour éviter d’augmenter la taille du dépôt Gitlab distant, on va ignorer - seulement sous Git - les fichiers contenus dans le répertoire public/. Ce qui revient à le rajouter dans le fichier .gitignore comme ceci :

echo "public/" >> .gitignore

Nous devons également adapter l’URL du site dans la configuration afin qu’il corresponde à l’URL fournie par Gitlab Pages pour servir votre - futur - site statique. Dans le cas où vous auriez suivi mes conseils et utilisé quelque chose comme mon_pseudo.gitlab.io, alors l’URL sera https://mon_pseudo.gitlab.io/. Dans mon cas c’est https://blankoworld.gitlab.io/ .

Éditons le fichier hugo.toml pour adapter l’URL du site comme il se doit :

baseURL = 'https://blankoworld.gitlab.io/'
locale = 'en-us'
title = 'My New Hugo Project'
theme = 'cleanwhite'

Il ne reste plus qu’à enregistrer les changements dans le dépôt Git et l’envoyer sur Gitlab :

git add .                               # on ajoute les fichiers au prochain commit git
git commit -m "chore: Hugo initialized" # création du prochain commit
git push                                # on pousse le résultat sur Gitlab

À ce stade, nous avons un site Hugo - très sommaire - avec un thème et l’URL de Gitlab enregistrée dans la configuration. Ce sont les seuls besoins vitaux pour compiler et publier le site. Rédiger un article est une étape qui peut attendre.

Voyons désormais comment permettre la publication de notre travail.

Automatisation avec compilation d’Hugo

La documentation de Gitlab sur l’intégration continue parle d’un fichier .gitlab-ci.yml à fournir à la base du répertoire principal.

Ce fichier .gitlab-ci.yml - oui, oui, avec un point devant le nom du fichier - va décrire les actions à effectuer pour construire, ou plutôt compiler, votre site Hugo et le publier sur Gitlab Pages.

Créons donc le fichier .gitlab-ci.yml à la base de notre répertoire principal - dans mon cas dans le dossier blankoworld.gitlab.io - avec le contenu suivant :

 1default:
 2  image: "hugomods/hugo:exts"
 3
 4variables:
 5  GIT_SUBMODULE_STRATEGY: recursive
 6  HUGO_ENV: production
 7
 8create-pages:
 9  script:
10    - hugo
11  pages: true
12  artifacts:
13    paths:
14      - public
15  rules:
16    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

C’est une version allégée de celle trouvée sur la documentation Gitlab à propos de la publication d’un site Hugo en utilisant Gitlab CI.

Inutile d’être un as de l’écriture de fichiers .gitlab-ci.yml pour en comprendre le détail :

Les lignes 1 à 2 renseignent l’image Docker à utiliser pour compiler votre site. Ici nous utilisons les excellentes images Docker fournies par Hugomods. Attention cependant à trouver une image qui contient aussi l’outil Git pour récupérer le thème du site,
ligne 4 à 6, nous avons respectivement une variable GIT_SUBMODULE_STRATEGY pour définir la statégie de récupération Git (utile pour récupérer notre thème) et HUGO_ENV pour définir l’environnement cible pour la compilation Hugo,
ligne 8 à 17 sont les lignes où tout va se jouer. C’est là qu’on décrit la commande à lancer - ici c’est juste hugo. Le fait qu’on souhaite utiliser Gitlab Pages et qu’on va utiliser le contenu résultant du dossier public pour l’envoyer sur Gitlab Pages.
ligne 15 et 16 définissent dans quel cas exécuter cette étape nommée create-pages. En l’occurrence cela ne sera que si la branche attachée au commit est la branche par défaut dans Gitlab. Si vous m’avez suivi dès le départ, nous n’avons qu’une seule branche dans Gitlab nommée master.

Une fois le fichier dûment complété, n’oubliez pas de l’ajouter au dépôt Git et de pousser le tout sur Gitlab :

git add .gitlab-ci.yml
git commit -m "feat(CI): Add .gitlab-ci.yml file to compile Hugo"
git push

Vous devriez retrouver rapidement les détails de la compilation dans le menu Gitlab (à gauche) nommé “Compilation > Pipelines”. Les pipelines de Gitlab CI représentent une suite automatisée d’étapes justement fournies dans le fichier .gitlab-ci.yml. Donc chaque fois que vous ferez un commit sur votre dépôt et que vous poussez le résultat sur Gitlab, une pipeline s’exécutera si et seulement si le fichier .gitlab-ci.yml est présent dans votre dépôt (et qu’il soit bien bien formé comme Gitlab CI l’attend).

Mais ne crions pas victoire trop tôt, nous avons encore quelques détails à régler.

Publication de son blog

Bien entendu, suite à notre dernier commit Git, une pipeline s’est exécutée. Elle est sûrement arrivée au bout de son exécution et le site est envoyé vers Gitlab Pages.

Cependant même en ayant l’URL il se pourrait que vos visiteurs n’accèdent pas au site : nous devons vérifier la « visibilité du site ». Et où cela se trouve ? Dans les paramètres de votre dépôt.

Sur Gitlab, une fois sur votre dépôt :

allez dans le menu latéral gauche et choisissez cette fois “Paramètres > Général”,
puis cliquez sur le titre “Visibilité, fonctionnalités du projet, autorisations”. Vous devriez avoir une loooooongue liste de boutons à cocher/décocher,
parmi eux, sous un titre “Pages”, doit se trouver un bouton activé. Et un menu déroulant pour choisir qui peut voir le site,
si vous souhaitez que tout le monde puisse accéder au site, choisissez “Toute personne ayant accès”,
ET n’oubliez pas d’aller plus bas de la page pour cliquer sur le bouton “Enregistrer les modifications”. Cas échéant vos modifications n’auront aucun effet.

Le menu “Paramètres > Général” en image :

et son petit copain l’encart “Pages” également en image :

C’est tout bon ! Vous devriez avoir un site accessible sur mon_depot.gitlab.io, dans mon cas c’est blankoworld.gitlab.io. Allez vérifier tout de même 😉.

Conclusion

À travers quelques étapes comme la création du dépôt, celle du site Hugo, la configuration de ce dernier, l’ajout d’un fichier .gitlab-ci.yml et finalement une configuration Gitlab, nous avons vu que quelques minutes suffisent à démarrer un nouveau blog/site statique, ce qui est très pratique !

Loin d’être un modèle de beauté, nous avons pourtant un site prêt à l’usage sur Gitlab Pages, à l’adresse blankoworld.gitlab.io. Chaque nouvelle modification enregistrée par Git (via un commit) puis poussée sur Gitlab génèrera une pipeline Gitlab CI qui publiera le site Hugo sur l’adresse fournie ci-avant.

Si d’aventures vous voudriez voir ce qui a été fait, je vous invite à lire le dépôt Gitlab utilisé pour ce tutoriel sur la publication d’un site Hugo sur Gitlab Pages.

Vous pourriez aller plus loin en ajoutant un domaine personnalisé sur votre dépôt Gitlab en lisant la documentation Gitlab. Vous allez devoir cependant apprendre comment avoir un nom de domaine et comment en modifier ce qu’on appelle la zone DNS. Mais ceci est une autre histoire que nous n’aborderons pas aujourd’hui.

Amusez-vous bien et n’hésitez pas à tester votre site Hugo en local avant de pousser le résultat sur le dépôt Gitlab 😉 .

Liens utiles

Voici les liens de l’article par ordre d’apparition :

RustFS, alternative au service de stockage objet MinIO

Sun, 15 Feb 2026 17:27:26 +0100

Quand on étudie Kubernetes, on arrive tôt ou tard sur la question de la gestion des sauvegardes. Et avec elles le sujet du stockage de ces dernières. La référence en matière de sauvegarde - dont je parlerais sûrement dans un prochain article - est Velero. Cet outil supporte plusieurs fournisseurs de stockage pour ses opérations de sauvegarde comme Amazon Web Services, Google Cloud, Microsoft Azure ou VMware Sphere. Principalement des fournisseurs liés à une entreprise. Que faire dans la situation où nous souhaitons auto-héberger une solution de stockage chez soi ?

C’est ce dont je voudrais parler aujourd’hui : une solution spécifique que j’ai - presque - choisie. Surtout pourquoi cette solution ? Je décrirais son installation sous Docker Compose derrière un proxy nommé Traefik, dont je vous ai déjà parlé. Et j’ajouterais quelques mots sur les ports réseau à ouvrir, l’initialisation des premiers « buckets » (nous y reviendrons) et l’usage de noms de domaines.

Pourquoi cette solution ?

Si vous n’êtes pas fan de l’histoire de « pourquoi choisir cette solution », vous pouvez passer au chapitre suivant, je ne vous en voudrais pas 😉.

En étudiant la documentation de Velero on découvre parmi les fournisseurs de solutions de stockage le célèbre Amazon Web Services. Et avec lui le service Amazon S3. Ce service est une solution de stockage objet qui a développé un protocole ouvert du même nom : S3. Grâce à cela, de nombreux outils compatibles avec ce protocole ont vu le jour ; que ce soit des clients comme des serveurs. Top, c’est ce que je recherche !

Ayant beaucoup entendu parler de MinIO, je m’enquiers de l’installer fin novembre 2025. En Docker Compose, derrière Traefik comme je l’explique dans un précédent article sur le sujet. Mais quelques problèmes se posent successivement :

en août 2025 les dépôts de Bitnami, qui fournissaient jusqu’alors d’excellentes images, chartes Helm et outils en tous genres sont chamboulés par une décision drastique prise par Bitnami. L’impact est énorme sur la communauté,
faute de cette image pratique, je me tourne vers l’image officielle qui demande des ajustements pour avoir des « buckets » à l’initialisation,
finalement le 13 février 2026, l’entreprise qui gérait MinIO décide d’abandonner la maintenance de la version communautaire.

Coup dur. Je recherche des alternatives. Je tombe sur le message de loverustfs qui compare les solutions alternatives à RustFS, dont MinIO, Garage, Ceph, Seaweeedfs, etc..

Edit (24 fév. 2026) : Un fork de MinIO est apparu il y a quelques jours. Si le cœur vous en dit 🤷.

RustFS n’est probablement pas la solution la plus performante (Seaweedfs semble plus performant), mais il se défend bien. Et il semble proche de MinIO en terme d’interface et d’utilisation. Allons donc, ne le faisons pas attendre, installons-le !

RustFS sous Docker Compose

L’idée est d’installer/utiliser RustFS avec Docker Compose. Derrière Træfik. Avec des domaines.

Installation minimale

On commence par une installation de base. On a besoin de :

une image Docker. Ça tombe bien, il y a des images officielles de RustFS sur le Hub Docker,
ouvrir 2 ports :
- 9000,
- 9001,
un volume local pour stocker les données et pouvoir les réutiliser entre 2 redémarrages de conteneurs,
un identifiant et un mot de passe initial.

ATTENTION : le projet RustFS est encore jeune, il est en développement actif et les versions ne sont pas toutes utilisables telles quelles. Par exemple dans ma situation, la version 1.0.0-alpha.83 était inutilisable. Ceci dû à un bug sur l’architecture de ma machine comme le montre ce ticket Github.

Une première ébauche d’un fichier docker-compose.yaml pourrait s’écrire de la manière suivante :

services:
  rustfs:
    image: rustfs/rustfs:1.0.0-alpha.82
    restart: always
    ports:
      - 9000
      - 9001
    volumes:
      - ./storage_data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      - RUSTFS_ACCESS_KEY=olivier
      - RUSTFS_SECRET_KEY=mot2passe
      - RUSTFS_OBS_LOGGER_LEVEL=info
    healthcheck:
      test:
        [
          "CMD",
          "sh", "-c",
          "curl -f http://127.0.0.1:9000/health && curl -f http://127.0.0.1:9001/rustfs/console/health"
        ]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Veillez à changer les éléments suivants - au minimum :

./storage_data dans la section volumes. Renseigner par un dossier dans lequel vous voulez stocker les données,
RUSTFS_ACCESS_KEY dans la section environment. Changez olivier par un identifiant que vous souhaitez utiliser,
RUSTFS_SECRET_KEY dans la section environment. Changez la valeur mot2passe par quelque chose de bien plus long et bien plus compliqué que cela (une clé secrète en somme).

De cette façon, le service va se lancer avec des ports choisis par Docker Compose. Vous pouvez les connaître en tapant les commandes suivantes :

docker compose port rustfs 9000
docker compose port rustfs 9001

On constate sur l’interface (port initial 9001), après s’être authentifié avec l’identifiant et la clé secrète, qu’il n’y aucun bucket.

Initialisation des buckets

Qu’est un bucket ?

C’est un espace qui regroupe plusieurs objets qu’on aurait déposé à cet endroit. Cela permet de se repérer plus facilement dans un espace de stockage objet.

Afin de créer un bucket, soit on utilise l’interface (méthode manuelle), soit on créé un conteneur d’initialisation qui fera le job à notre place (automatique).

J’opte pour le conteneur d’initialisation pour créer 3 buckets. Dans notre fichier docker-compose.yaml on ajoute les lignes suivantes :

  init_buckets:
    image: minio/mc:RELEASE.2025-08-13T08-35-41Z
    depends_on:
      - rustfs
    restart: on-failure
    entrypoint: >
      /bin/sh -c "
      sleep 5;
      /usr/bin/mc alias set s3server http://rustfs:9000 \"olivier\" \"mot2passe\";
      /usr/bin/mc mb s3server/default;
      /usr/bin/mc mb s3server/bucket1;
      /usr/bin/mc mb s3server/bucket2;
      exit 0;
      "

Pensez à changer olivier et mot2passe par les mêmes identifiants/mot de passe que renseignés dans le service rustfs du docker-compose.yaml précédent.

L’astuce est donc d’utiliser le client mc de MinIO pour ajouter les buckets qu’on souhaiterait. Dans l’exemple présenté ci-avant, le conteneur d’initialisation permet de créer 3 buckets :

default,
bucket1,
bucket2.

Libre à vous d’adapter ce conteneur pour répondre à vos besoins en matière de création initiale de bucket.

Il ne reste alors plus que la mise à disposition sur Internet via l’usage de sous-domaines et de Træfik.

Configurer les labels pour Træfik

Træfik est un proxy souvent utilisé avec Docker Compose pour se charger des routes. L’idée de Træfik est d’utiliser le champ labels pour récupérer des instructions utiles à la création des routes en lien avec les domaines.

Pour RustFS sous Docker Compose, et avec Træfik en frontal, je suggère les labels suivants :

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api-rustfs.rule=Host(`api.mondomaine.tld`)"
      - "traefik.http.routers.api-rustfs.entrypoints=websecure"
      - "traefik.http.routers.api-rustfs.service=api-rustfs"
      - "traefik.http.services.api-rustfs.loadbalancer.server.port=9000"
      - "traefik.http.routers.rustfs.rule=Host(`mondomaine.tld`)"
      - "traefik.http.routers.rustfs.entrypoints=websecure"
      - "traefik.http.routers.rustfs.service=rustfs"
      - "traefik.http.services.rustfs.loadbalancer.server.port=9001"

Prenez soin de changer les éléments suivants :

websecure par le nom de votre routeur permettant d’avoir du HTTPS,
api.mondomaine.tld par le domaine de votre choix pour accéder à l’API de RustFS,
mondomaine.tld par le domaine utilisé pour accéder à l’interface Web de RustFS.

Évidemment tout un tas d’autres options sont possibles, il suffit de lire la documentation de Træfik pour cela.

Résultat final complet

Ce qui nous donne :

services:
  rustfs:
    image: rustfs/rustfs:1.0.0-alpha.82
    restart: always
    ports:
      - 9000
      - 9001
    volumes:
      - ./storage_data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      - RUSTFS_ACCESS_KEY=olivier
      - RUSTFS_SECRET_KEY=mot2passe
      - RUSTFS_OBS_LOGGER_LEVEL=info
    healthcheck:
      test:
        [
          "CMD",
          "sh", "-c",
          "curl -f http://127.0.0.1:9000/health && curl -f http://127.0.0.1:9001/rustfs/console/health"
        ]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api-rustfs.rule=Host(`api.mondomaine.tld`)"
      - "traefik.http.routers.api-rustfs.entrypoints=websecure"
      - "traefik.http.routers.api-rustfs.service=api-rustfs"
      - "traefik.http.services.api-rustfs.loadbalancer.server.port=9000"
      - "traefik.http.routers.rustfs.rule=Host(`mondomaine.tld`)"
      - "traefik.http.routers.rustfs.entrypoints=websecure"
      - "traefik.http.routers.rustfs.service=rustfs"
      - "traefik.http.services.rustfs.loadbalancer.server.port=9001"

  init_buckets:
    image: minio/mc:RELEASE.2025-08-13T08-35-41Z
    depends_on:
      - rustfs
    restart: on-failure
    entrypoint: >
      /bin/sh -c "
      sleep 5;
      /usr/bin/mc alias set s3server http://rustfs:9000 \"olivier\" \"mot2passe\";
      /usr/bin/mc mb s3server/default;
      /usr/bin/mc mb s3server/bucket1;
      /usr/bin/mc mb s3server/bucket2;
      exit 0;
      "

Avec ce contenu vous devriez pouvoir démarrer une instance RustFS sans problème 😉.

Quelle aventure !

Au bout du compte, avoir cherché à lancer un service de stockage objet a été une sacrée odyssée pour moi. Beaucoup d’aléas liés au changement de politique de Bitnami (pour les images MinIO), à l’arrêt de maintenance du code du serveur MinIO par AIStor et aux effets de bord de RustFS en plein développement.

Mes besoins spécifiques en terme d’infrastructure (Docker Compose et Træfik) m’ont amené à devoir retravailler plusieurs fois le fichier docker-compose.yaml. Et j’ai essuyé quelques plâtres avant d’avoir une instance fonctionnelle.

Je suis ainsi content de partager ce fichier docker-compose.yaml. Bien qu’il y a matière à faire évoluer ce fichier. On peut imaginer améliorer ce fichier en utilisant des variables pour le dossier où seront stockées les données, le nom du service, le domaine et bien évidemment l’identifiant et le mot de passe du service RustFS. Et déposer les valeurs dans un fichier .env.

On pourrait également trouver un autre client que mc pour initialiser les buckets au départ. Voire trouver un autre outil permettant de créer les buckets plus facilement. Imaginons une nouvelle image Docker ayant un script d’initialisation avec des variables d’environnement le permettant.

Je laisse votre imagination faire le reste 😊.

Sources utilisées pour la mise en place de RustFS

Liens utiles

Mon Labo K8S pour essayer des applications

Sun, 09 Nov 2025 06:25:39 +0100

Introduction

Quand on commence à étudier Kubernetes (k8s), on a besoin d’un environnement où tester ce qu’on apprend. Les environnements possibles sont nombreux : Minikube, Kubernetes (k8s) officiel, k0s, k3s, etc. Cela ne s’arrête plus !

Entre les difficultés à installer l’environnement et celles à appliquer ce qu’on apprend, on ne s’en sort plus. Cela devient vite compliqué au point de vouloir tout arrêter ; c’était mon cas.

De plus je souhaitais avoir un environnement reproductible et spécifique à chacun de mes projets, de quoi travailler unitairement sur un service particulier.

Avant de décrocher complètement, j’ai fait une pause, pris du recul et étudié la question. Je vous relate ici le résultat de cette petite aventure dans le monde de Kubernetes et des outils envisagés pour créer un labo de développement d’applications tournant sous Kubernetes.

Dans un premier temps nous poserons le problème, après quoi nous étudierons quelques solutions pour finalement détailler le produit de cette pérégrination.

Photo trouvée sur publicdomainpictures.net sous Licence CC0 Public Domain.

Le contexte

Venant du monde de Docker et Docker Compose, il me semblait aller de soi d’étudier ensuite le monde de Kubernetes - qui utilise la conteneurisation. Seulement je ne pensais pas que l’installation même de Kubernetes était un cap à franchir.

Je souhaite en profiter pour migrer petit à petit mes services sur Kubernetes. Chacun d’eux devient donc un projet en soi. Et comme souvent, j’aime avoir un environnement spécifique de développement pour créer les fichiers nécessaires à Kubernetes et permettre a posteriori d’améliorer le service. Je cherche donc à avoir un simili de docker-compose.yml pour chaque service et permettant de développer l’application dans un environnement Kubernetes propre.

Au début on découvre Minikube. Du moins c’est un outil très souvent conseillé. Pratique sur une machine bureautique pour triturer rapidement quelques fichiers Kubernetes (des fichiers au format YAML). Il est bien documenté et possède plusieurs plugins pour faciliter l’étude du Kubernetes en place ; par exemple un plugin Dashboard permet de visualiser les métriques du serveur et les objets instanciés. J’ai la sensation que cet outil reste « trop spécifique ». Il ne représente pas totalement un « vrai » Kubernetes. Ça peut parfois causer des torts au moment de déployer sur un autre serveur Kubernetes. L’outil est également lourd et relativement lent pour instancier un nouvel environnement.

Pourquoi ne pas tester un Kubernetes connu pour sa légèreté ? Par exemple k3s. D’autant qu’il s’installe rapidement à l’aide de k3sup (qui fonctionne à merveille). Sur le papier c’est une bonne idée : léger, facile à installer. En revanche il ne permet pas d’instancier un nouvel environnement ; il faut donc jouer avec les namespaces Kubernetes. Rebelote : ce n’est pas un outil adapté à l’apprentissage de Kubernetes. Au départ on fait forcément des erreurs dues à l’incompréhension ou l’ignorance ; ce qui peut rendre l’environnement rapidement inutilisable.

Après ces deux premières tentatives, je sais désormais ce que je veux :

possibilité de créer un environnement « propre »,
encore mieux s’il peut créer plusieurs environnements,
si possible léger (petit) - ce qui exclue les machines virtuelles,
facile à installer,
et rapide.

Nous avons nos critères, il ne reste plus qu’à chercher le(s) outil(s) permettant de créer rapidement un environnement de développement autour de Kubernetes.

Solutions étudiées

À la recherche des mots clés « lightweight » (similaire au mot léger) et « kubernetes » dans un moteur de recherche, on trouve plusieurs outils comme :

MicroK8S,
k0s,
k3s,
et kind.

k3s a déjà été cité dans cet article. Il ne me convient pas pour un environnement de développement/d’étude concernant k8s. Il est sûrement très redoutable à l’installation rapide sur une quantité importante de machines à l’aide de k3sup. Mais ce n’est pas le sujet de cet article.

La liste mentionne également MicroK8S, le petit rejeton de la famille Ubuntu, qui semble être une alternative à Minikube avec des plugins (Dashboard, DNS, registry, istio, etc.). Je pense qu’il est effectivement intéressant pour un usage complet entre des développeurs, une intégration continue (CI) / déploiement continue (CD) et plusieurs environnements allant jusqu’à des environnements dit « de production ». Je sens cependant que la similitude avec Minikube ne puisse me convenir. Je le laisse de côté pour l’instant.

k0s, quant à lui, semble être la solution idéale pour une installation sur une machine physique. À usage privé. Bien qu’il semble léger, facile à installer et utiliser, je comprends rapidement qu’il est fait pour avoir une installation unique sur une machine physique précise. Il ne répond pas à mon critère de création multiple d’environnements.

Et un de plus en moins !

Il reste le dernier de cette liste : kind. A priori il semble léger, prévu pour un usage spécifique au développement ou de l’intégration continue (CI) et utilise Docker pour créer un cluster complet à chaque fois. Waouh, rien que ça ! Sur le papier, cet outil est très prometteur car il répond aux critères précédemment listés :

créer des environnements « propres » grâce à l’usage de Docker,
ainsi il permet l’usage de plusieurs environnements,
il est léger, petit,
facile à installer puisque kind est disponible dans les dépôts AUR d’ArchLinux,
et pour la rapidité nous verrons.

À l’usage, kind (qui veut dire Kubernetes IN Docker) semble facile à prendre en main :

# Créer un cluster nommé olivier
kind create cluster --name olivier
# Supprime le cluster nommé olivier
kind delete cluster --name olivier

Une fois le cluster créé, il s’agit simplement de jouer avec la commande kubectl habituelle pour contacter le cluster. Et la commande étant à taper, je peux tout à fait scripter la création du cluster et sa destruction.

Il serait plus pratique de l’utiliser avec d’autres outils pour en faciliter l’usage. J’ai donc cherché au fur et à mesure de nouveaux outils dont voici la liste :

kubectx va permettre de commuter d’un contexte Kubernetes à un autre. Autrement dit passer d’un cluster à un autre facilement,
kubeconform pour valider nos fichiers YAML,
kube-linter pour pousser à l’usage des bonnes pratiques en matière de rédaction de fichiers YAML,
skaffold pour surveiller la moindre modification (équivalent d’un « watcher ») sur nos fichiers YAML et les déployer directement sur le cluster,
et make (avec un fichier Makefile) pour mélanger tout ça.

Mon idée est d’utiliser un fichier Makefile pour fournir plusieurs commandes permettant de créer le cluster, le détruire, vérifier les fichiers YAML ou encore lancer un déploiement automatique s’il y a des changements dans les fichiers en cours de développement.

J’imagine quelque chose comme :

make cluster pour créer un cluster,
make dev pour lancer skaffold et écouter le moindre changement sur le dossier de développement de l’application,
make kubeconform pour vérifier les fichiers une fois écrits,
make lint pour vérifier les bonnes pratiques avec kube-linter,
et make clean pour détruire le cluster.

Tentons l’aventure et voyons le résultat !

Ce que j’ai finalement produit

En bref

Le fichier Makefile :

CLUSTER_NAME := k8s-dev-example
KUBECTL := kubectl
SKAFFOLD := skaffold
KIND := kind
KUBECONFORM := kubeconform
KUSTOMIZE := kustomize

NAMESPACES := dev

.PHONY: help
help:
	@echo "Commandes disponibles :"
	@echo "  make cluster       - Crée un cluster Kind"
	@echo "  make namespaces    - Crée les namespaces Kubernetes (dev/staging/prod)"
	@echo "  make dev           - Lance Skaffold pour l'env dev"
	@echo "  make kubeconform   - Lance kubeconform sur l'env de DEV"
	@echo "  make clean         - Supprime le cluster Kind"

cluster:
	$(KIND) create cluster --name $(CLUSTER_NAME) ||:

namespaces:
	@for ns in $(NAMESPACES); do \
		$(KUBECTL) get ns $$ns >/dev/null 2>&1 || $(KUBECTL) create ns $$ns; \
	done

dev: cluster namespaces
	$(SKAFFOLD) dev

kubeconform: kubeconform-dev

kubeconform-dev:
	$(KUSTOMIZE) build overlays/dev | $(KUBECONFORM) -strict -summary -ignore-missing-schemas

clean:
	$(KIND) delete cluster --name $(CLUSTER_NAME)

Ce fichier Makefile est disponible sur le dépôt Gitlab d’ODTRE.

Il va utiliser deux dossiers principaux :

base qui contient les fichiers YAML de l’application qu’on souhaite implémenter sur Kubernetes,
overlays/dev qui contient un fichier kustomization.yaml pour surcharger le dossier base.

Et 2 fichiers de configuration :

kube-linter.yaml avec votre configuration de l’outil,
skaffold.yaml avec le contenu suivant :

apiVersion: skaffold/v4beta13
kind: Config
metadata:
  name: k8s-demo-app
manifests:
  kustomize:
    paths:
      - ./overlays/dev
# Exemple de redirection de port sur le service nommé dev-nginx (car l'overlay ajoute dev- devant tout)
portForward:
  - resourceType: service
    resourceName: dev-nginx
    namespace: dev
    port: 80
    localPort: 4000

Cela permet de surveiller le dossier ./overlays/dev avec kustomize pour interpréter les fichiers. Et il va ouvrir le port 4000 sur la machine locale pour rediriger sur le port 80 du service Nginx d’exemple (fourni dans le dépôt Gitlab mentionné précédemment).

À l’usage

Tout n’est pas parfait. Cependant ce fichier Makefile permet de lancer quelques commandes make utiles :

# Lance l'environnement de DEV. Si le cluster n'existe pas : il le créé. Sinon il ignore.
make dev
# Vérifie la conformité des fichiers YAML en utilisant le dossier overlays/dev
make kubeconform
# Détruit le cluster de DEV
make clean
# Pousse à l'usage des bonnes pratiques sur les fichiers contenus dans le dossier ./base
kube-linter lint --config kube-linter.yaml ./base

Pour toute aide supplémentaire, faites : make help.

Ainsi il devient facile de travailler sur un nouvel environnement :

je copie les fichiers disponible sur un dépôt template sur Gitlab,
j’ouvre le fichier Makefile en écriture,
j’édite la ligne suivante pour adapter le nom du cluster de travail :

CLUSTER_NAME := k8s-dev-example

Et le tour est joué !

Je suis assez satisfait de cet environnement. Il répond aux critères édictés plusieurs fois dans cet article. Et je me sens plus à l’aise de pouvoir modifier comme bon me semble cet environnement de développement/travail.

Les outils utilisés me font penser à une boîte à outil de base pour le travail sur Kubernetes. Même sans utiliser le fichier Makefile je suis amené à pratiquer les outils comme kubeconform, kubectl, kube-linter et kustomize.

C’est donc une très bonne chose d’avoir regroupé ces outils autour de Makefile et de les utiliser régulièrement sur mes projets Kubernetes.

Conclusion

Nous avons posé le contexte d’une recherche d’outil simple, rapide et léger pour créer de nombreux environnements Kubernetes afin de travailler sur ces environnements dans le cadre d’un développement de fichiers YAML.

Après quelques essais sur Minikube et k3s, mes recherches se sont portées sur l’utilisation de kind. Puis j’ai utilisé make pour le manipuler et regrouper aussi les différents outils utiles.

La boîte à outil se compose de :

kind,
skaffold,
kubectl,
kubeconform,
kube-linter,
et make.

J’aborde désormais de manière plus sereine le développement d’une application qui sera hébergée par un Kubernetes. J’ai un template à ma disposition pour ces fichiers. Template que je peux faire évoluer au gré des obstacles rencontrés. Il utilise tous les outils que j’ai appréciés. J’en suis pleinement satisfait 😎 .

Et vous, quel environnement Kubernetes utilisez-vous pour vos développements de fichiers YAML ?

Liens utiles

Ce que j'aurais voulu savoir sur Gitlab CI

Sun, 18 May 2025 13:55:39 +0200

Introduction

Il y a quelques mois je parlais de ma formation Bootcamp pour devenir Ingénieur DevOps. J’y ai utilisé - à nouveau - Gitlab CI (Continuous Integration). Vous savez, cet outil permettant d’exécuter des actions après avoir envoyé votre code/dépôt sur la plateforme Gitlab ?

C’est très utile, par exemple pour lancer les tests sur votre code, vérifier que le code s’exécute dans un environnement précis ou tout simplement vérifier que le code compile. Et si votre dépôt n’est pas du code, par exemple un site web, vous pouvez tester les liens morts ; voire publier votre site ! Les possibilités sont - finalement - nombreuses !

En revanche, un tel outil est parfois déstabilisant. Et des cheveux, j’en ai arrachés ! J’aurais apprécié tomber sur un article explicatif. Avec des astuces. Peut-être que le présent article m’aurait convenu, qui sait !

J’aurai par exemple aimé savoir comment publier facilement un site web, tester localement le fichier .gitlab-ci.yml avant de l’envoyer sur Gitlab, connaître plus d’astuces pour les mots clés Gitlab, savoir utiliser Docker dans Gitlab CI et ce que sont les composants réutilisables.

Ce sont ainsi tous les sujets que nous allons aborder aujourd’hui.

Photo trouvée sur le profil de didier.camus sur Flickr sous Licence Œuvre du domaine public.

Publier rapidement un site statique

Gitlab met à disposition des utilisateurs un espace permettant d’héberger des sites webs statiques. Incroyable n’est-ce pas ? Cet espace est Gitlab Pages.

Comment cela fonctionne ? Il suffit de créer un dépôt Gitlab, d’ajouter un fichier .gitlab-ci.yml contenant la section suivante :

image: busybox

pages:
  stage: deploy
  script:
    - echo "The site will be deployed to $CI_PAGES_URL"
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Code récupéré du projet https://gitlab.com/pages/plain-html.

Cela signifie qu’au terme de la CI/CD (dans l’étape nommée deploy), le contenu du dossier public sera publié sur Gitlab Pages. À quelle adresse ? Imaginons que vous partez d’un dépôt dont l’adresse est : https://gitlab.com/blankoworld/monprojet/, l’adresse URL d’accès à votre site publié sera : https://blankoworld.gitlab.io/monprojet/. Pratique non ?

Astuce : Si votre dépôt est privé, vous pouvez quand même rendre votre site public. Il suffit d’aller dans Settings > General, Section « Visibility, project features, permissions » et dans le sous-titre « Pages », activez la fonctionnalité. Et dans le menu déroulant à côté, choisissez « Everyone ». N’oubliez pas de sauvegarder cette configuration. Le code sera privé, le site web statique public !

Pour plus d’exemple, veuillez vous rendre sur la page Gitlab présentant la liste de projets utilisant Gitlab Pages.

Tester avant d’envoyer sur le dépôt ?

Le truc vraiment embêtant avec les fichiers .gitlab-ci.yml, c’est qu’on ne peut pas les tester sur notre machine (localement). Pour avancer il faut :

modifier le fichier .gitlab-ci.yml,
le valider (faire un commit),
l’envoyer sur Gitlab,
patienter que la pipeline se lance (et parfois se termine),
bénéficier du résultat ou, dans la plupart des cas, recommencer à l’étape 1…

À une époque on pouvait utiliser une commande gitlab-runner exec en local. Mais celle-ci a été supprimée : https://gitlab.com/gitlab-org/gitlab-runner/-/commit/f8508c924f80b104ec7353353e6ad0edb5daae66 .

Suivant ce que nous faisons dans la CI/CD de Gitlab, il est possible d’utiliser un outil bien pratique nommé gitlab-ci-local : gitlab-ci-local.

Vous trouverez quelques détails de gitlab-ci-local sur mon recueil d’astuces.

Généralités

Voici quelques pistes intéressantes sur le sujet Gitlab :

Une documentation de départ est : https://docs.gitlab.com/topics/build_your_application/. Elle permet d’en savoir plus sur la syntaxe de gitlab-ci.yaml, les variables pré-définies ou encore le fonctionnement d’un pipeline dans Gitlab CI,
Toujours utiles : les actions que je nomme comme « globales ». Par exemple les mots clés image, variables ou before_script peuvent être utilisés en début du fichier pour définir des actions ou des valeurs qui seront utilisées dans toutes les étapes du pipeline. Ce qui peut être un avantage, ou un inconvénient. Exemple : image: ubuntu:latest va définir que toutes les étapes se lanceront dans un docker partant de l’image Ubuntu,
Entrées/sorties : un artefact = une sortie. C’est à dire des fichiers utilisables/disponibles pour les étapes suivantes (donc en entrée pour les autres étapes) en utilisant le mot clé dependencies (Cf. https://docs.gitlab.com/ci/jobs/job_artifacts/#fetching-artifacts). Sauf si dependencies = [] est utilisé.
Utiliser des variables globales en début du fichier (par exemple pour les numéros de versions) fait gagner du temps sur le long terme. Exemple :

variables:
  DOCKER_VERSION: "27.3.1"
  UBUNTU_VERSION: "24.04"

Concernant le mot clé script :
- si on veut écrire plusieurs lignes, utiliser la syntaxe suivante :
```
script:
  - echo "première étape des scripts"
  - |
    echo "première ligne"
    echo "seconde ligne"
    echo "etc."
```
- limiter à 10 lignes maximum,
- si on utilise la syntaxe pour écrire plusieurs lignes, le debug est plus difficile
Pour organiser les étapes, on peut donner à chacune d’elle une étape pré-requise en utilisant le mot clé « needs », cela permet de chaîner les étapes dans un certain ordre. Exemple : si on veut que l’étape « deploy » se fasse après « compile », alors à la fin de l’étape « deploy » on met needs: [compile].

Le Cas Docker

Création d’une image Docker… dans un conteneur Docker

Dans la situation où vous voudriez fabriquer des images Docker, vous allez être confrontés à plusieurs problématiques :

il faut utiliser des commandes docker pour créer des images,
mais la plupart des Gitlab Runner exécutent les étapes de Gitlab CI dans un Docker,
donc on se retrouve à vouloir exécuter des commandes docker dans un environnement Docker.

Vous voyez le problème ?

Pour contourner cette situation il suffit d’utiliser Docker-in-Docker.

En somme le début du fichier .gitlab-ci.yml ressemblera à :

variables:
  DOCKER_VERSION: "27.4.1"

image: docker:$DOCKER_VERSION

services:
  - docker:$DOCKER_VERSION-dind

S’identifier

Pour utiliser les dépôts de conteneurs de Gitlab, rien de plus simple il suffit d’écrire le code suivant dans le fichier .gitlab-ci.yml :

before_script:
  - docker info
  - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin

Nul besoin de renseigner les variables. Elles sont renseignées par Gitlab CI.

Construire l’image

Pour construire l’image cela va ressembler à :

variables:
  CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

build-image:
  stage: build
  script:
    - docker pull "$CONTAINER_TEST_IMAGE" || true
    - docker build --build-arg BUILDKIT_INLINE_CACHE=1 -t $CONTAINER_TEST_IMAGE .
    - docker push $CONTAINER_TEST_IMAGE

On part du principe que le fichier Dockerfile est situé à la racine de votre projet Gitlab.

CONTAINER_TEST_IMAGE est une variable globale construite à partir des variables pré-définies de Gitlab CI.

Pousser l’image sur le dépôt

Dans cette situation nous sommes contents d’avoir déjà ajouté l’authentification aux dépôts de conteneurs Gitlab.

Cette fois on fait une étape pour récupérer l’image précédente et lui donner un nouveau nom :

push-image:
  stage: push
  script:
    - export IMAGE_TAG="$(date +'%Y%m%d')-${CI_COMMIT_SHORT_SHA}"
    - docker pull $CONTAINER_TEST_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $CI_REGISTRY_IMAGE:$IMAGE_TAG
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

L’idée est :

de créer un nom de tag pour l’image (variable IMAGE_TAG),
récupérer l’image précédente - puisque les étapes d’un fichier .gitlab-ci.yml s’exécutent dans des conteneurs isolés les uns des autres,
apposer un nouveau tag sur l’image récupérée,
publier le résultat en poussant l’image ainsi étiquetée.

Ceci ne s’exécute que si la branche est nommée main. Donc chaque commit sur cette branche générera une image Docker et un tag.

Ordre d’exécution des étapes

Afin que les deux étapes précédentes s’exécutent dans un certain ordre, ne pas oublier les lignes suivantes dans le fichier .gitlab-ci.yml :

stages:
  - build
  - push

Comme si ça ne suffisait pas…

En outre, voici d’autres éléments à rajouter dans son fichier .gitlab-ci.yml :

variables:
  # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
  DOCKER_HOST: tcp://docker:2376
  DOCKER_TLS_CERTDIR: "/certs"

Ces lignes permettent de renseigner un autre accès à l’API Docker pour lancer les commandes docker.

Les composants réutilisables

Gitlab CI offre la possibilité d’utiliser des composants réutilisables pour agrémenter les étapes de son fichier .gitlab-ci.yml. Ceci évite de réinventer la roue (en codant soi-même).

Plusieurs composants sont disponibles sur la page Gitlab components.

Exemple d’utilisation d’un composant :

include:
  - component: gitlab.com/components/container-scanning/container-scanning@5.1.0

C’est très utile dans certaines situations comme pour tester des fichiers Terraform (avec le composant OpenTofu), le composant Go, le composant Rust ou même utiliser les fonctionnalités Autodevops de Gitlab.

Conclusion

Au premier abord Gitlab CI paraît complexe et maigre en fonctionnalités. Cependant la lecture de la documentation (très fournie !) donne rapidement un aperçu bien plus avantageux de cet outil. On y découvre les composants réutilisables, les mots clés image, variables, before_script, les artefacts (sorties), les variables globales, le déploiement de sites statiques et j’en passe !

Certaines difficultés telles que Docker viennent s’immiscer dans nos essais. Mais une fois les obstacles franchis c’est un outil très satisfaisant. Je l’apprécie.

Je serais ravi de tomber plus souvent sur des articles décrivant ses fonctionnalités. J’espère participer à une diffusion plus grande de la connaissance Gitlab CI et, qui sait, peut-être partagerais-je prochainement d’autres astuces ?

Mes conseils pour réussir une formation Bootcamp

Sun, 13 Oct 2024 10:14:59 +0200

Introduction

Il y a peu je commençais une formation chez DataScientest. En Bootcamp. Ce format est l’équivalent d’un temps complet (lundi à vendredi de 8h à 18h) passé sur le contenu du programme pédagogique. Durée prévue dans ma situation : 3 mois.

Ce temps est nécessaire pour apprendre les différentes notions. C’est à la fois long et court : c’est dense et le temps accordé est parfois « tout juste » pour lire. Alors comment tenir ce Marathon de 3 mois ?

J’aborderais dans un premier temps les éléments qui m’ont permis d’organiser mon plan de la semaine. Après quoi j’aborderais des sujets proches du contenu des cours comme les exercices et les examens. Finalement je donnerais des astuces diverses que j’ai listées au fur et à mesure de mon avancée dans l’aventure. Cette liste risque donc de s’allonger avec le temps !

À noter que ces conseils sont forcément emprunts de mon expérience de vie, mes compétences et mes particularités (la folie, ça compte ? 🤔)

Photo trouvée sur le profil de Aurélien Adoue sur Flickr sous Licence Attribution 2.0 Generic.

Organisation

1 mois que j’ai commencé la formation. Une durée prévue de 3 mois. Une vie à mener à côté. Des objectifs professionnels en lien avec le résultat de ce Bootcamp. Vous ne pouvez pas vous pointer les mains dans les poches.

Il est évident qu’il faut un plan. Tous les conseils pointent sur la même chose : il faut compartimenter son temps. Et s’y tenir ; oui s’y tenir. Faites-le suivant votre vie et vos possibilités. Mais tenez-y vous ! Et mettez au courant votre entourage de votre planning.

Mon planning

Dans mon cas, j’ai opté pour le planning suivant :

les matins du lundi au jeudi : lecture des nouveaux cours. Apprentissage et exercices, voire examens ;
les après-midi du lundi au jeudi : révision des cours lus les jours précédents (parfois semaines précédentes), sinon faire des exercices ;
le vendredi : mise en pratique des outils/notions appri(e)s(es) sur des projets personnels.

De cette manière la nouveauté arrive quand je suis frais, c’est à dire le matin.

Viens ensuite l’après-midi, après le repas, où je suis moins attentif que le matin. Idéal pour des révisions sur des sujets déjà abordés les jours précédents. Et cela fait une fin de journée plus tranquille que le matin.

Une révision passe par la rédaction de « fiches » de synthèse pour créer des récapitulatifs de ce qui a été vu. Parfois je dessine des cartes heuristiques : plus parlantes pour moi.

Pendant la lecture des cours je note des idées d’utilisation des outils découverts (en somme des projets qui germent dans ma tête). Ce qui me permet d’aborder le vendredi un projet réfléchi pendant la semaine. Exemple : à la lecture du contenu, j’ai noté qu’il y avait beaucoup d’abréviations. Par ailleurs, un des modules du cours apprend à utiliser un outil de création d’API. Quoi de mieux que de créer une API pour lister les abréviations ? Et hop!, un projet à faire le vendredi.

Autre exemple : on apprend le scripting Bash ? Quoi de mieux que de faire un outil pour automatiser l’installation de nos logiciels habituels sur les machines virtuelles fournies par le centre de formation ? Ou bien simplifier la vie en ajoutant des raccourcis (alias) Bash pour les commandes usuelles pendant les cours ?

On apprend la méthode ETL (Extract, Transform, Load) sur des API ? Utilisons notre API des abréviations pour extraire les données !

Que faire une fois les données extraites ? On a appris à utiliser - en bonus - SQLAlchemy (bibliothèque pour faire des requêtes sur une base de données), pourquoi ne pas l’utiliser pour insérer les données extraites de l’API pour les charger dans une base de données à nous ?

Mais en dehors de ces moments, que fais-tu Olivier ?

Hors planning

Si le planning existe, c’est pour une raison : il est nécessaire d’avoir une vie à côté ! Il faut du temps pour :

la famille (conjoint(e), enfants, parents, etc.),
des pauses,
avoir du temps à soi,
dormir,
manger,
etc.

Réellement, il FAUT ce temps pour votre famille et vous !

La famille apporte un entourage (indirectement ça peut être de la confiance en soi), les pauses un souffle pour votre cerveau, le temps à soi pour se retrouver, dormir pour ranger les informations dans votre cerveau et manger pour redonner de l’énergie à votre corps !

Chacun de ces éléments va permettre de franchir plus facilement les obstacles de votre parcours en Bootcamp. D’où le côté strict des horaires que vous vous donnez.

Ainsi après une matinée de lecture de nouveaux cours, vers midi, je m’arrête. Et je passe à autre chose : le repas, une pause et un repos allongé sur le dos pendant 10 mn environ. Avant de recommencer sur l’après-midi avec les révisions de la veille.

Après 17h ? Je m’arrête également. Je passe aux tâches quotidiennes, de la famille et du repas du soir. Un peu de détente. Un bon gros sommeil de plus de 8h.

Et la journée recommence.

Le week-end ? Pas de formation. La famille, les amis, du temps pour notre conjoint, pour soi, etc. On fait toutes ces choses qui donnent de l’énergie et remplissent notre cœur, notre corps et notre moral.

La partie organisation est très importante, elle va définir si vous aurez la tête sous l’eau ou pas. Prenez donc le temps de définir tout ça. Respectez votre planning et les personnes qui vous entourent. Par ailleurs, ce n’est qu’une seule clé parmi d’autres : pour que cela fonctionne il est nécessaire d’être efficace lors de sa période de travail. C’est ce que nous allons voir dans le prochain chapitre.

Travail efficace

Il n’y a pas de secrets selon moi, un travail efficace est déterminé par :

un environnement spécifique de travail,
une technique d’assimilation particulière,
et une façon d’agir durant les examens chronométrés.

Je vais donc vous parler de chacun des ces points en donnant quelques astuces issues d’études faites sur la question.

Point 1 : l’environnement de travail

À la lecture du livre Deep work, retrouver la concentration dans un monde de distractions écrit par Cal NEWPORT (un professeur dans les sciences informatiques du MIT - rien que ça!), j’ai bien compris qu’il fallait un environnement sans distractions.

Exit les téléphones mobiles : on le met sur mode avion. On s’enferme dans une pièce, à clé. On mobilise toutes nos ressources pour se concentrer sur la tâche à accomplir : apprendre les cours.

Toute perturbation est à proscrire et malheureusement pour certains : la musique en fait partie. Il semble que des études ont déterminé que cela activait des zones du cerveau qui empêchent une concentration complète.

L’idée du livre « Deep work » est que si vous êtes concentrés vous prendrez moins de temps à travailler. Ce qui me semble tout à fait adapté pour une formation en Bootcamp, n’est-ce pas ?

Point 2 : assimiler les cours

Là encore, les scientifiques ont étudié la question. Et c’est au travers d’une vidéo de Science étonnante concernant les (vraies) techniques pour mieux apprendre et étudier que j’ai pu améliorer mon apprentissage.

Je vous conseille de regarder la vidéo - YouTube - et d’imaginer une nouvelle façon d’étudier, de réviser et de travailler.

De mon côté j’ai opté pour la relecture régulière, la lecture de plusieurs cours qui font souvent des liens sur le domaine étudié et la mise en pratique par des cas concrets de la vie courante pour s’entraîner avec les outils étudiés. J’en parlais tout à l’heure : la création d’une API, l’extraction des données de cette dernière pour les introduire ensuite dans une autre base de données sous un autre format.

À noter que plus loin dans cet article je vous demanderais de ne pas suivre de vidéos YouTube pendant vos études Bootcamp, je ne suis pas schizophrène : considérez cette vidéo comme l’exception qui confirme la règle 😃 .

Point 3 : les examens

Certains examens sont chronométrés. Ce qui peut très vite être déstabilisant !

Je propose plusieurs choses pour s’en sortir :

Rien de mieux que la préparation : si vous avez fait les cours régulièrement et que vous avez révisé 1 jour après, 2 jours après, 1 semaine après, vous retiendrez bien mieux les cours ;
Faites des exercices avant et sentez-vous un minimum à l’aise, travaillez les points sensibles ;
Lors des examens : ouvrez en avance les documentations qui vous aident ;
Dans les examens, optez pour des noms de variables courts : plus vous rallongez le nom des fonctions et des variables, plus vous aurez à taper du code. Indirectement vous prenez un temps fou pour rédiger au lieu de réfléchir !
Pour les examens, préparez déjà à côté vos codes sur le sujet : c’est votre code, celui qui vous ressemble. Rien n’interdit un copier-coller de votre propre travail !

Avec ces 3 points, vous devriez déjà avoir de bonnes bases pour aborder la formation. Il y a d’autres astuces diverses que nous allons découvrir maintenant.

Diverses astuces

Ne sachant dans quelles catégories mettre ces astuces, mais considérant ces dernières comme tout aussi importantes, je vous les dépose là. Piochez selon vos envies ;)

Revoyez chaque semaine le planning que vous allez suivre : quel cours étudier chaque jour. Prenez en compte les sujets sur lesquels vous avez déjà des connaissances pour passer plus de temps sur ceux que vous ne connaissez pas ;
Ne prenez des notes qu’à une seconde lecture (lors de révisions par exemple) : sinon vous allez passer trop de temps sur un cours ;
Si vous avez un souci logiciel qui empêche de travailler : passez à autre chose !
Quand vous revenez sur un souci logiciel - plus tard - si vous ne réussisez pas mieux, utilisez ChatGPT pour décrire votre problème. Cet outil est plutôt efficace pour donner des pistes. Rappelez vous, ChatGPT est un assistant, vous le dirigez. Ce n’est pas lui qui doit vous diriger. ;
N’utilisez pas de vidéos pour apprendre - YouTube ou autre - c’est une perte de temps considérable. Pourquoi ? Tout simplement car vous ne pourrez pas voir rapidement si la vidéo vous apporte quelque chose de concret ou non. Et parfois ce qu’ils disent est tout bonnement faux ! Cela vous apporte plus de confusion qu’autre chose. En revanche chez DataScientest ils ont des vidéos de cours. Cela apporte généralement quelque chose de concret et de vrai ;
Lisez de la documentation des outils utilisés : elles ne mentent pas. Elles décrivent. Et peut-être retiendrez-vous des options qui vous feront gagner plus tard un temps fou !
Restez humbles : même si vous maîtrisez un sujet, vous trouverez souvent des nouveautés et des détails que vous ne connaissiez pas dans les cours ;
Si vous avez la possibilité, apprenez à utiliser des dépôts Git rapidement pour enregistrer votre travail sur les machines virtuelles distantes proposées par la formation. Cela vous évitera de mauvaises surprises quand les machines se réinitialisent…

Si jamais je trouve d’autres astuces je les rajouterai ici.

Conclusion

Cette formation m’a permis de travailler mon environnement, mes méthodes de travail et découvrir des astuces pour être plus efficace en journée. Et cela sans mettre de côté la famille et la maison. Ce qui donne de l’énergie pour continuer chaque semaine de travailler.

C’est un cercle vertueux que je conseille à chacun pour améliorer son quotidien et être plus productif.

Je souhaite de tout cœur que chacun trouve son équilibre dans sa vie et réussisse sa formation en Bootcamp. Bonne chance à vous et bon travail !

Cron sous Docker avec Alpine

Wed, 12 Oct 2022 21:41:39 +0200

Introduction

Chose promie, chose due ! J’écris un article sur mes pérégrinations en informatique.

Cette fois, je fais suite à l’état des lieux 2022 de mon espace numérique. Certains de mes services/sites nécessitent régulièrement d’être mis à jour. Pour cela je souhaite utiliser Cron, un service sous GNU/Linux qui permet de planifier le lancement de script(s) à des fréquences définies.

Comme je souhaite utiliser Docker, je me suis demandé s’il était possible de créer un service dédié avec Cron, Docker et Alpine.

Cet article explique quelques règles que j’ai dû suivre pour y parvenir. Il vous faudra a minima connaître Docker, voire Docker Compose pour comprendre quelque chose. À la rigueur vous connaissez déjà Cron et souhaitez l’utiliser sous Docker.

Nous allons d’abord réflechir sur le sujet. Puis nous utiliserons l’exemple d’un site pour expliquer la solution choisie avant de conclure sur cette histoire.

Pour les pressés, j’ai fais un chapitre « En bref » à la fin de cet article.

Photo trouvée sur le profil de Duc Ly sur Flickr sous licence CC BY-SA 2.0.

Réflexion sur le sujet

Ce que nous souhaitons faire, c’est lancer un service, par exemple almanax, et le mettre à jour régulièrement avec une tâche dans le service cron. Je vais expliquer un peu ma réflexion, si vous voulez entrer plus rapidement dans le vif du sujet, rendez-vous au chapitre suivant.

Tout d’abord il faut savoir que l’environnement choisi est Docker. Un système qui permet, à partir d’une image de générer plusieurs conteneurs ayant des points de montage différents pour changer les données qui s’y trouvent.

Docker propose plusieurs bonnes pratiques, parmi lesquelles :

ne lancer qu’un seul processus/service dans chaque conteneur
réutiliser les images ou les parties d’images au maximum pour réduire à la fois la maintenance des images/conteneurs, le travail effectué et la place système utilisée pour les images de base

Sachant que nous ne lançons qu’un seul processus par conteneur Docker, et que je souhaite utiliser Cron, je vais devoir lancer cron dans un autre service. Concrètement, Docker propose Docker Compose qui est un outil permettant de lancer plusieurs services à la fois, avec des dépendances entre eux (si besoin), une description des points de montage, des commandes à lancer sur chaque service, les ports ouverts, etc.

On peut également choisir l’image qu’on souhaite utiliser pour chaque service.

Certes nous allons lancer Cron dans un service à part, pour lancer les scripts que notre autre service a besoin pour mettre à jour ce dernier - je pense notamment à un script qui recompile et reconstitue mes pages webs statiques -, mais nous allons devoir avoir accès à notre service almanax qui contient la logique principale du site.

Pour cela, l’idée est de modifier l’image de almanax pour qu’elle contienne elle aussi cron. Ainsi on pourra lancer la même image sous Docker Compose, avec une commande de lancement différente.

On utilise des services Docker. Chacun ayant déjà leur propre image sous Alpine. Ainsi, chaque image possède déjà Cron inclut dans Alpine.

J’allais dire qu’une image vaut mieux que 1 000 mots, mais là nous allons donner un exemple avec Docker Compose pour comprendre de quoi il s’agit.

Mise en place, exemple avec l’Almanax

Peut-être le savez-vous déjà : j’ai crée une page statique qui liste une quinzaine de quêtes de l’Almanax dans un jeu nommé Dofus.

Cet outil est un de mes services fourni aux utilisateurs, mais également un projet Open Source, dofus-almanax que je fournis via Github. C’est dans ce dépôt Github que vous trouverez la plupart des fichiers nécessaires au bon lancement d’un service Cron que nous allons décrire.

On va étudier le fichier docker-compose.yml suivant :

version: '3'
services:
  generator:
    build: .
    image: dofus-almanax:0.2
    volumes:
      - almanax_public:/opt/almanax/public:rw
      - almanax_data:/opt/almanax/dl:rw
  web:
    image: caddy:2-alpine
    restart: always
    depends_on:
      - generator
    volumes:
      - almanax_public:/usr/share/caddy:ro
      - ${PWD}/Caddyfile:/etc/caddy/Caddyfile
    ports:
      - 8888:80
  cron:
    image: dofus-almanax:0.2
    restart: always
    entrypoint: /usr/sbin/crond
    command: ["-f", "-l", "2", "-L", "/dev/stdout"]
    volumes:
      - almanax_public:/opt/almanax/public:rw
      - almanax_data:/opt/almanax/dl:rw

volumes:
  almanax_public:
  almanax_data:

Nous avons 3 services :

generator : qui génère le site web au lancement, suite à quoi il s’éteint,
web : un service pour mettre à disposition les fichiers statiques générés par generator,
cron : un service pour mettre à jour régulièrement les fichiers statiques.

La particularité de la solution :

generator et cron utilisent la même image : dofus-almanax:0.2
ces deux services n’ont cependant pas la même commande au lancement : l’un prend la commande par défaut de l’image dofus-almanax:0.2, l’autre lance spécifiquement cron
pour le service cron, il spécifie avec le mot clé entrypoint d’utiliser /usr/sbin/crond (chemin absolu du binaire sous Alpine) et donne les paramètres -f -l 2 -L /dev/stdout

Que font les paramètres ?

-f définit de lancer le service en foreground, nécessaire sous Docker, sinon cela ne fonctionne pas
-l 2 définit un niveau de journalisation, habituellement c’est 8 (Cf. une explication des niveaux crond sous Stackoverflow
-L /dev/stdout permet d’avoir une sortie à l’écran dans Docker Compose

Ça, c’est les éléments de base. Cependant comment fonctionne la mise à jour, la configuration de cette dernière, etc.?

Fonctionnement de Cron dans l’image dofus-almanax:0.2

Nous l’avions dit, l’idée est de tout mettre dans l’image dofus-almanax:0.2 (à la fois nos scripts, nos fichiers et crond). Mais comment configurer le service Cron pour lui indiquer la fréquence à laquelle mettre à jour et comment mettre à jour nos fichiers ?

Regardons l’image Docker, écrite sous le fichier Dockerfile suivant :

FROM alpine:3.16

RUN apk update && \
    apk add --no-cache \
        py3-lxml \
	py3-mechanize \
	tzdata && \
    rm -rf /var/cache/apk/*

ENV TZ=Europe/Paris

WORKDIR /opt/almanax

VOLUME /opt/almanax/public
VOLUME /opt/almanax/dl

ENTRYPOINT ["python3", "almanax_next_week.py"]
CMD ["/opt/almanax/public/index.html"]

COPY ./src /opt/almanax
COPY ./crontabs /etc/crontabs/root

RUN chown root:root /etc/crontabs/root && \
    chmod 600 /etc/crontabs/root

COPY ./cron_scripts/generate.sh /opt/generate

Étudions ce fichier dans les grandes lignes concernant le service Cron notamment.

Nous partons d’une image Alpine 3.16 qui contient déjà crond (le service Cron)
Nous installons tzdata qui nous permettra de choisir correctement un fuseau horaire
ENV TZ=Europe/Paris définit notre fuseau horaire, histoire de lancer le script au moment où nous nous y attendons
Le fichier le plus important, cronbtabs est copié vers /etc/crontabs/root, la ligne COPY ./crontabs /etc/crontabs/root est déterminante pour remplacer le fichier du service crond d’Alpine Linux
On copie aussi un script generate.sh dont nous parlerons après
Ce même fichier nécessite des permissions spécifiques, notifiée vers la fin du fichier Dockerfile :

RUN chown root:root /etc/crontabs/root && \
    chmod 600 /etc/crontabs/root

Que contient le fichier crontabs et generate.sh ?

La configuration du service crond

Sous Alpine, le fichier utilisé pour configurer les éléments à lancer par crond est /etc/crontabs/root. Dans le chapitre précédent nous parlions de comment le remplacer, voici désormais son contenu :

5       0       *       *       *       /bin/sh /opt/generate

Nous voyons que nous utilisons effectivement le script generate.sh - qui a d’ailleurs été renommé generate.
Nous utilisons /bin/sh devant notre script :
- c’est un chemin absolu vers le binaire sh
- et nous utilisons sh, pas bash (car bash n’est, à défaut, pas délivré sous Alpine Linux)
Nous utilisons des caractères spécifique, formatés spécifiquement pour dire que nous lançons le service à 00h05 du matin

Pour générer un fichier compatible avec crond, je vous suggère Crontab Generator.

Il va falloir appliquer quelques règles pour être sûr que tout cela fonctionne évidemment.

En bref, les règles à appliquer pour crond

Voici les règles à retenir pour rédiger le fichier que le service crond va étudier :

7 espaces entre chaque élément défini dans le crontab (le fichier se nomme ainsi)
utiliser /bin/sh sous Alpine pour lancer un script, puis le nom de votre script
ne pas mettre de point dans le script qu’on lance (mettre par exemple generate au lieu de generate.sh)
le fichier /etc/crontabs/root doit appartenir à root (root:root) et avoir les permissions 600 (chmod 600)
utilisez -L /dev/stdout sous votre Docker Compose pour avoir une sortie lisible et -l 2 pour plus de logs, mais -l 8 suffit

Ce qui fait déjà pas mal de choses à savoir !

Conclusion

Bien que la réflexion ait été longue (et croyez moi j’ai pris plusieurs jours pour tester au fur et à mesure ce que je souhaitais), nous avons réuni les seules règles à appliquer pour que cela fonctionne, tout en trouvant une solution sympathique qui a plusieurs avantages :

le service Cron accède à tous les fichiers communs de notre service initial
le service Cron accède également à tous les scripts utiles de notre service initial
il suffit de changer le script d’entrée de l’image initiale pour lancer Cron
on a peu de changement à faire pour utiliser Cron finalement !

L’inconvénient reste cependant qu’il faut pouvoir modifier l’image initiale. Si nous n’avions pas la possibilité de faire ça, j’imagine qu’on devrait créer un point de montage commun entre le service initial et le service cron pour accéder à la fois aux fichiers mais aussi aux binaires… ce qui est bien plus complexe/casse-tête !

Liens utiles

Je me suis grandement inspiré, pour mes pérégrinations sur Cron dans Alpine sous Docker par :

Mise à jour des DNS Gandi (v5) avec la bbox de Bougues

Mon, 06 May 2019 20:18:29 +0200

Figurez-vous qu’après mes pérégrinations dans le monde de l’Internet nomade, j’ai eu l’occasion de passer à la Fibre. Et avec elle son lot de « malheurs » : une IP dynamique.

En quoi est-ce problématique ?

Une IP fixe permet de bénéficier d’une adresse constante, c’est à dire qu’elle permet, par exemple, d’avoir un nom de domaine qui redirige vers une à plusieurs machines de la maison. Par exemple avec bogossdu69.fr je pourrais éventuellement arriver sur mon partage de fichiers.

Photo trouvée sur le profil de sattygalle sur Flickr sous licence CC BY-SA 2.0.

La situation

Mon but est donc de mettre à jour régulièrement mes noms de domaine lorsque mon IP change.

Je dispose de :

une box Bouygues nommée bbox
une ip dynamique
un nom de domaine chez Gandi.net
une machine allumée en permanence sur la box

L’objectif

Mettre à jour régulièrement le nom de domaine pour qu’il pointe vers ma box en permanence.

Ma solution en 1 commande

En une commande :

curl -s https://mabbox.bytel.fr/api/v1/wan/ip |jq '.[0].wan.ip.address'| xargs -I{} curl -X PUT -H "X-Api-key: LaSuperCleAPIdeGandiV5" -H "Content-Type: application/json" -d '{"rrset_ttl":"1800","rrset_values":["{}"]}' https://dns.api.gandi.net/api/v5/domains/domain.tld/records/bogossdu69/A

En remplaçant :

LaSuperCleAPIdeGandiV5 par la clé de sécurité dans votre interface Gandi sur Tableau de Bord > Paramètres > Sécurité > (Re)Générer la clé d’API
domain.tld par votre domaine, par exemple dossmann.net
bogossdu69 par votre sous-domaine, par exemple olivier (ce qui donnera olivier.dossmann.net)

Le détail

L’idée est de lancer un script régulièrement (par exemple toutes les 5 minutes) sur la machine branchée à la Box.

Pour cela on va utiliser les outils suivants :

l’IP donnée par l’API de votre bbox et dont la documentation est sur le site officiel de l’API de Bouygues
curl fourni dans la plupart des distributions GNU/Linux (et plus encore !)
jq
l’outil timerctl fourni dans le système pour planifier l’exécution de tâches régulières
et la commande précédente aménagée dans un script

L’API de notre box va fournir l’IP publique dynamique de notre connexion internet. jq va permettre la récupération de la bonne information parmi l’ensemble fourni par notre box. Après quoi curl mettra à jour les DNS dynamiques de Gandi (notre fournisseur de nom de domaine).

Il ne nous reste plus qu’à taper la commande entière dans le fichier /etc/systemd/system/maj_domaine.service sous la forme suivante :

[Unit]
Description=Mise a jour du domaine Gandi

[Service]
Environment="API_KEY=oefijzoifjzeoifjzeoifjeo"
ExecStart=/usr/bin/bash /home/user/maj_domaine.sh
Type=simple

N’oubliez pas d’adapter API_KEY avec votre clé d’API et /home/user/ par l’adresse où se trouve le script !

Puis de renseigner le fichier /etc/systemd/system/maj_domaine.timer avec :

[Unit]
Description=Lance maj du domaine toutes les 8 min

[Timer]
OnBootSec=8min
OnUnitActiveSec=8min
Persistent=True
Unit=maj_domaine.service

[Install]
WantedBy=multi-user.target

Il ne nous reste plus qu’à prévenir systemd via les commandes suivantes :

sudo systemctl daemon-reload
sudo systemctl enable maj_domaine.timer
sudo systemctl start maj_domaine.timer
sudo systemctl start maj_domaine.service

Et le tour est joué !

Conclusion

À l’aide des outils listés dans ce billet on peut sans problème survivre à une IP dynamique à la maison chez Bouygues Telecom. Je n’ai eu jusqu’à ce jour aucun problème et espère que cela continuera ainsi.

Concept et utilisation du Bullet Journal ou bujo

Tue, 05 Jun 2018 09:39:43 +0200

Introduction

Vous le constaterez au gré de ce blog : je suis en constante recherche d’une méthode pour m’organiser.

S’il y a quelques années je découvrais la méthode GTD, elle n’a eu d’effet que de nourrir mon bureau de post-it. Certes j’ai agrémenté la méthode de divers outils numériques pour m’épauler dans l’organisation du planning. Si la méthode Lessy fonctionne pour mes jeux vidéos/projets à accomplir, elle n’est pas du tout adaptée à mon organisation journalière. Même Wekan, dont je partageais récemment mon expérience, n’a pas su résoudre l’achèvement régulier de mes tâches.

Je m’attache donc cette fois à l’utilisation sur plusieurs semaines/mois d’une nouvelle méthode : la méthode du Bullet Journal®. Je remercie d’ailleurs Dorian - qui se reconnaîtra - de m’avoir appris l’existence de cette méthode.

Après une brève présentation de la méthode je vous montrerai mon bujo et vous expliquerait ensuite en quoi j’ai apprécié cette méthode.

Présentation

Le Bullet Journal® a été crée par Ryder Caroll pour rassembler les informations contenues dans la plupart des bouts de papier qu’on utilise :

la liste des courses
les post-its
le planning mensuel, hebdomadaire et journalier
les évènements de l’année (anniversaires, fêtes, sorties, etc.)
les prises de notes
etc.

Il désigne à la fois la méthode et le livre utilisé pour l’appliquer. Les fans l’appellent aussi le bujo (deux premières lettre de chaque mot).

Vous retrouverez une explication en anglais de la méthode sur le site officiel (sur WebArchive).

Si je devais résumer en quelques points la méthode je dirais :

utiliser un livre facile à emporter avec soi
utiliser un livre à pages numérotées ou numéroter soi-même les pages
utiliser un index dans ce livre pour définir à quelle page commence quelle section
utiliser une légende pour les sigles du livre - au moins pour le premier bujo, le temps de s’habituer
utiliser 2 pages au début pour un planning semestriel des 6 prochains mois et y rassembler les gros évènements. Par exemple les anniversaires.
utiliser ensuite 2 pages pour un planning mensuel du mois en cours. 1 ligne par jour devrait aller. Y placer des événements clés du mois. Sur la page de droite placer les tâches que vous souhaitez effectuer dans le courant du mois
utiliser après ça autant de page que nécessaires pour écrire, chaque jour, les tâches à faire
faire le point régulièrement sur les tâches journalières
ne pas se tracasser si on a manqué plusieurs jours, pas besoin d’écrire quoique ce soit

Vous trouverez énormément d’exemples sur le Web, notamment sur Youtube et Instagram. Au bas de cet article sont exposés quelques liens intéressants pour vous documenter et créer votre bujo ultime !

La communauté propose des exemples pour le suivi de l’humeur, la météo, les livres à lire, les séries TV en cours, les films à voir, les anniversaires à venir, le sommeil, les finances, les screencasts, etc.

Mon bujo

Étant donné qu’un bujo est un support physique, je vous propose de mettre les images et commenter ensuite.

Pour la petite histoire, ne sachant pas si je persisterais avec le bujo j’ai commencé par en fabriquer un avec les moyens du bord.

La page de garde me semble importante pour 2 choses :

dire à qui appartient le livre
donner une adresse où renvoyer le livre s’il est trouvé

Pratique si on l’oublie dans les transports en commun ou qu’il tombe de notre sac/poche.

L’index sert à ce qu’il annonce : trouver une page parmi notre livre. Il fait partie intégrante de la méthode puisque grâce à cela nous pouvons rendre notre bujo modulaire et ajouter les sections que l’on souhaite.

Ma page de légende ajoute quelques éléments supplémentaire à celle fournie par Ryder Caroll :

je décris un sigle particulier qui permet de désigner 3 tâches prioritaires à faire dans la journée
j’ai mis en place un système de récompense pour ces 3 tâches lorsqu’elles sont effectuées
je fais le suivi de mon humeur et de la météo que vous découvrirez sur mon planning mensuel

Adaptez suivant vos besoins, vos envies et vos émotions du moment.

Si une section « Films/Séries » et une section « Livres » existe c’est parce que j’ai besoin d’en faire le suivi. Tout d’abord car je prends note des films/séries et livres qu’on me conseille. Ensuite je ne regarde pas toujours les séries en une fois, il est bon de savoir où nous en sommes dans la série. Et finalement j’ai besoin de suivre les sorties des films pour ne pas les louper.

Une autre partie importante du bujo : le planning semestriel. Utile pour les anniversaires par exemple. Comme en juin ici.

Le planning mensuel apporte une vision rapide du mois en cours. Dans mon cas il permet aussi de noter la température maximale chaque jour, la météo du moment et l’humeur du moment. J’utilise ensuite un système de graphe pour voir l’évolution de l’humeur. Je ne sais pas si ça me servira, mais je trouve ça fun à faire !

Ci-dessus un exemple de tâches du jour. Avec des tâches prioritaires et une récompense à la clé quand elles sont effectuées : du chocolat ! On ajoute donc à la suite les jours suivants. Jusqu’au mois prochain. Pourquoi le mois prochain ? Car une fois le mois terminé, on refait un planning mensuel du mois qui arrive. Comme celui que j’ai fais pour Mai.

Edit: Voici quelques images de ma nouvelle version.

Plus le bujo est chaleureux plus l’utilisation de ce dernier est fréquente. N’hésitez donc pas à rajouter des autocollants en tous genres, ça ravive le journal !

Ce que j’aime dans cette méthode

Le bujo est un concept intéressant qui allie finalement l’ensemble des caractéristiques des livres qu’il ingère. En effet c’est un savant mélange d’agenda, d’organiseur, de journal intime et de post-it. Il s’adapte en fonction des besoins et des priorités de chacun. Vous avez besoin de suivre l’évolution de vos repas, pourquoi ne pas faire une page ou deux dans le bujo ?

La méthode étant modulaire, de nombreuses personnes partagent leurs expériences et leurs idées sur le bujo. C’est cet esprit de partage qui rassure : nous trouverons toujours quelqu’un qui montre une solution à un problème donné. Comme par exemple le « mood tracker » ou suivi des humeurs.

Je m’attendais à ce que l’utilisation d’un livre et d’un stylo soit perturbant, voire inefficace dans un monde où l’informatique est partout. Mais finalement le livre ne tombe jamais en panne quand on en a besoin et il n’y a pas de bug de synchronisation. Je l’ai toujours avec moi et il ne me fait pas défaut ! Il est également complémentaire de mon agenda numérique sur téléphone mobile.

Pouvoir personnaliser son livre est une expérience magique que vous ne retrouverez pas dans un logiciel. Et l’esprit est plus libre quand on utilise quelque chose qu’on apprécie !

Conclusion

Après plusieurs semaines d’utilisation cette méthode m’a convaincu : elle réunit plusieurs types de notes qui autrefois s’éparpillaient joyeusement dans la maison. Je ne m’y retrouvais plus ! L’outil s’adapte à mes besoins et ne rencontre aucun problème. Je peux laisser libre cours à mon imagination et ma créativité - s’il en est.

En voyant les conseils des utilisateurs du bujo, j’ai amélioré la qualité de mon carnet de note en achetant un Leuchtturm1917. Les 3 marques-pages, les pages numérotées et les points tous les 0,5 cm m’ont conquis !

Cet outil permet donc de résoudre les problèmes au fur et à mesure tout en voyant venir. Il permet également d’archiver le passé et de le consulter. Je suis étonné de m’entendre dire qu’un carnet de note est plus efficace que les applications que j’ai pu trouver sur le téléphone mobile. Je vous conseille plus que vivement de tester la méthode, qu’importe le temps que ça vous prendra au début, franchissez le pas !

Liens utiles

En fouinant sur le Web, j’ai déniché plusieurs pistes dont je me suis inspiré pour créer mon bujo.

Et n’hésitez pas à parcourir le Web pour des exemples de Bullet Journal®, comme sur le tag #bulletjournal sur Instagram qui donne énormément d’exemples.

Avis personnel sur ces différents liens : Au début je trouvais que la communauté en faisait des pataquès au niveau coloriage, dessins et décorations en tous genre. Mais après avoir essayé d’égayer mon bujo je peux vous assurer que ça apporte joie et gaieté chaque jour à utiliser votre « chef-d’œuvre ».

Suivre la progression de ses jeux vidéos

Sat, 12 Aug 2017 19:32:37 +0100

Introduction

Précédemment je parlais de mon application de la méthode de Project Zero sur ma liste de jeux vidéos. Je réduis en effet ma liste de jeux en cours à 3 maximum par console. Ce qui me permet d’achever plus rapidement les jeux vidéos l’un après l’autre sans me disperser.

Seulement voilà, la collection s’aggrandissant, il a fallu trouver un outil pour suivre facilement l’ensemble de mes jeux vidéos, triés par console, savoir lequel a été terminé, ceux qu’il me reste à finir, les jeux en cours, etc.

Je vais donc vous faire part de mon expérience sur 2 outils qui permettent de gérer sa collection de jeux vidéos :

Backloggery (site web)
My Game Collection (Android)

Backloggery.com

Après quelques recherches sur le Web je suis tombé sur un site intéressant : Backloggery.com.

Il permet à un utilisateur de créer une liste de titres (jeux vidéos). Pour chacun d’eux, vous pouvez renseigner (liste non exhaustive) :

le titre du jeu
la console/système sur lequel il tourne
votre progression parmi :
- unfinished : jeu non terminé
- unplayed : pas encore joué
- beaten : jeu terminé
- completed : jeu terminé totalement
- mastered : jeu terminé avec un défi personnel fixé
votre avis de 1 à 5 (ou pas d’avis)
si vous jouez actuellement à ce jeu ou non

Ce site permet également de créer sa liste de jeux vidéos souhaités. Il propose de noter le jeu comme détenu, à la maison, souscris par abonnement, des commentaires, des notes de progression, le nombre de succès accomplis, etc.

Puis, une fois le détail de vos jeux enregistrés, le site fait une page de statistiques de vos jeux, comme par exemple le profil de MetalMan1230 sur Backloggery.

Ce que j’aime :

un thème un peu rétro qui tient la route
ses règles d’utilisation qui stipulent qu’aucune donnée à caractère personnel ne sera collectée. Au pire anonymisée.
le côté simple pour la saisie des jeux, pas de chi-chi, tu entres le titre, la console et ton pourcentage d’accomplissement du jeu
la page de statistiques est une très bonne idée car elle permet de visuellement comprendre notre état d’avancement

Ce que j’aime moins :

le site n’est pas du tout mobile-friendly, c’est à dire qu’il ne s’adapte pas bien aux petits écran, c’est une galère.
il n’y a pas d’API pour récupérer des infos de son compte (pour éventuellement créer une page web statique récapitulative)

Il n’en reste pas moins que c’est un site que je conseille vivement !

My Game Collection

Sur Android, il en est tout autrement : le Play Store propose tout un tas d’application, mais une d’entre elle semble se démarquer par sa richesse de fonctionnalités : my-game-collection.

L’idée de l’application : récupérer sa liste de jeux sur un nombre important de services comme Steam, Backloggery, HowLongToBeat, Collectorz, Desura, Itch.io, vgcollect, etc. afin d’en créer une liste à suivre.

L’outil propose ensuite d’ajouter des tags à vos jeux pour les filtrer par la suite. Il gère aussi la collection d’amiibo, de Skylanders, de personnages Disney Infinity, etc.

Voici les éléments que j’apprécie particulièrement :

import de jeux parmi une liste bien fournie de site web
pendant la synchronisation de notre liste avec une plateforme distante, on peut choisir au cas par cas de modifier les données du jeu vidéo tel qu’il apparaît dans notre liste (image de présentation, titre du jeu, tags utilisés pour l’œuvre, etc.). Si vous avez la flemme, il y a la synchronisation automatique
avoir pensé aux figurines des jeux vidéos, comme pour Lego Dimensions
gère aussi sa liste de consoles et d’accessoires
le côté mobile est intéressant car on peut saisir à côté de sa collection sans déplacer le PC
affichage - en utilisant le site HowLongToBeat - du nombre d’heure pour accomplir le jeu en totalité

En revanche, je peux lister bon nombre de soucis :

l’interface n’est pas simple à utiliser. C’est trop fourni donc on se retrouve avec de petits boutons, voire même avec des choses qui se chevauchent sans qu’on puisse appuyer sur le bouton situé derrière
l’outil propose un compte premium afin de pouvoir bénéficier de toutes les possibilités, c’est compréhensible mais assez dommage
la synchronisation des données ne fonctionne que dans un sens (on récupère, on envoie pas). Du coup ça reste moyen pour gérer ses jeux Backloggery…
quand la base de données igdb.com n’est pas suffisante pour les informations d’un jeu, il faut utiliser GiantBomb.com, mais ça demande une clé API. Quand on y connaît pas grand chose, c’est juste impossible

Je dois l’avouer, ce dernier outil ne correspond pas du tout à mes attentes, bien qu’il contienne la liste des Skylanders (qui me serait utile) mais aussi une récupération sur HowLongToBeat du temps approximatif pour terminer le jeu.

Si vous avez la flemme d’utiliser un ordinateur pour gérer votre collection, utilisez cet outil, sinon ravisez-vous et continuez sur d’autres services prévus à cet effet.

Conclusion

Après avoir eu du mal à trouver une application qui permette de suivre la progression pour chaque jeu vidéo détenu, je m’attendais à trouver quelque chose de plus basique que les outils présentés. Je reste donc étonné de ces derniers. Mais quelque peu déçu du manque de finition de ces applications.

Dans l’idéal, et comme souvent, il faudrait que je crée mon propre outil pour correspondre à mes attentes. Mais qui a du temps pour ça ?

Je vais donc rester sur une approche temporaire et double : utiliser Backloggery, exporter chaque fois vers My Game Collection pendant que je développerai un outil similaire ralliant le meilleur des deux dans un seul outil :)

30 consoles de salon pour 80 euros

Wed, 30 Dec 2015 14:47:45 +0200

Introduction

Les vacances de Noël approchaient et je me demandais comment les occuper. Je ne suis pas très famille - ça c’est dit - et je voulais donc profiter pleinement du temps libre pour m’amuser un peu - en dehors des séances de jambe-en-l’air avec des inconnues.

Sachant que je recevrai prochainement un vidéoprojecteur, je me disais que pour le tester on pourrait y brancher quelques consoles de jeu rétro.

Mais voilà, toutes ces consoles :

prennent de la place
ont des systèmes de branchements variés
ne sont pas compatibles avec la prise HDMI du vidéoprojecteur

Ce qui fait à la fois du bazar et beaucoup d’ennuis à brancher/débrancher.

J’ai donc pensé à autre chose : utiliser un RaspberryPi 2 pour une soixantaine d’euros et mettre des émulateurs dessus.

Je vais donc vous présenter ma nouvelle console rétrogaming de salon !

Le matériel

Afin de composer cette console j’ai eu besoin :

du RaspberryPi 2 Type B (40 euros)
une alimentation compatible (10 euros)
un boitier pour mettre le RPi 2 à l’intérieur (10 euros)
une clé USB bluetooth compatible (15 euros environ)
une carte micro SD de 8 Go (10 euros)
une manette de PS3 d’un ami (ou une manette de XBOX)

EDIT au 1er août 2016 : Il est possible désormais d’acheter directement un RaspberryPi 3 qui contient le bluetooth et le wifi intégré. Ce qui évite l’achat d’une clé USB Bluetooth supplémentaire mais ne réduit pas le coût puisque le RPi 3 vaut 10 euros de plus que le RPi 2.

Le logiciel

Quelle chance d’avoir trouvé le système suivant : EmulationStation !

Ce système fait quasiment le café ! Car :

vous le téléchargez
vous le copiez sur votre clé comme indiqué sur la documentation
vous mettez la carte dans la RPi
vous allumez les TV
vous allumez le RPi (avec un clavier branché)
vous configurez
vous branchez une manette de PS3 ou de XBOX en USB sur le RPi (pour la configurer)
vous enlevez ce câble USB et le clavier une fois tout configuré
vous relancez le RPi pour vérifier
vous profitez !

Certes il faut installer et configurer, mais ce n’est qu’une petite heure ou deux de préparation puis vous faites de sacrés soirées chez vous ou chez les amis (puisque la console est petite, elle est mobile).

Les jeux

Étant donné que j’ai quelques jeux PlayStation 1, je me suis dis que c’était l’occasion d’y rejouer.

J’ai trouvé le lien suivant pour copier, depuis Linux, un CD PlayStation 1 afin de l’utiliser sur notre nouvelle console rétrogaming.

Voici donc comment utiliser la ligne de commande Linux pour copier un CD de PlayStation en un fichier .toc.

Conclusion

Donner vie à nouveau à ses anciens jeux comme Crash Bandicoot 3 fût un réel plaisir ! J’ai pu également lister l’ensemble de mes jeux afin de les stocker à la cave et les remplacer par leur version numérique sur le RaspberryPi 2. C’est un gain de place de 3 bons gros cartons !

Je souhaite que vous puissiez faire la même expérience positive de cette console rétrogaming et que vous pourrez ainsi cultivez nos jeunes têtes blondes avec les jeux d’antan ;)

Développer pour Arduino en ligne de commande

Sun, 18 Oct 2015 11:12:18 +0100

Introduction

L’Arduino est une carte électronique assez connue permettant grossomodo de transformer n’importe quel objet en objet intelligent puisque vous allez pouvoir programmer ce dernier afin d’avoir des comportements spécifiques suivant les données reçues par un certain nombre de capteurs.

Arduino permet de réunir le monde de l’informatique à celui de l’électronique et favorise le DIY (Do It Yourself = fait le toi-même).

Le site officiel d’Arduino propose de nombreuses documentations et surtout un logiciel pour développer, compiler et envoyer sur l’Arduino votre programme. C’est une interface simple, claire, compatible Windows, MacOSX et GNU/Linux car développée en Java. Cependant, je préfère très - ou trop ? - souvent développer des programmes sous VIM en mode console et faire les compilations et l’envoi en ligne de commande. Et je ne suis pas le seul. Voilà pourquoi j’ai décidé de vous partager mon environnement de travail pour Arduino.

Sommaire

Programmer pour Arduino se résume finalement comme beaucoup d’autres projets aux 3 actions suivantes :

développer un programme sur son éditeur préféré
compiler le programme (parfois sur le même éditeur)
envoyer le résultat en production. Dans notre cas ce sera dans l’Arduino

Si la première étape est facile pour tout le monde, puisque chacun a probablement déjà son éditeur préféré, les 2 dernières étapes sont moins simples.

Sous GNU/Linux, et plus particulièrement sous une distribution dérivée Debian, cela se résume quasiment à :

installer les paquets arduino-core et arduino-mk
initialiser des variables dans son .bashrc, .zshrc ou tout autre invite de commande
savoir créer pour chacun de ses projets Arduino un fichier Makefile
savoir quelle commande utiliser pour compiler et pour envoyer le résultat sur l’arduino

Passons donc à la préparation de l’environnement

Installation et configuration

Comme vous l’avez vu, nous commençons par l’installation des paquets arduino-core et arduino-mk :

apt-get install arduino-core arduino-mk

Ceci devrait, entre autre, installer avrdude qui nous facilitera l’envoi sur l’Arduino.

Ensuite nous éditons le fichier de configuration de notre shell préféré, ici .bashrc afin d’y initialiser les variables suivantes :

ARDUINO_DIR : le dossier dans lequel a été installé arduino-core qui contient, entre autres les bibliothèques nécessaires à la programmation d’un Arduino
ARDMK_DIR : le dossier dans lequel a été installé arduino-mk
AVR_TOOLS_DIR : le dossier dans lequel chercher l’outil avrdude

Chez moi cela donne quelque chose comme :

export ARDUINO_DIR="/usr/share/arduino"
export ARDMK_DIR="/usr/share/arduino"
export AVR_TOOLS_DIR="/usr"
export ISP_PORT="/dev/ttyACM0"

À noter que j’ai rajouté la variable ISP_PORT pour définir d’emblée le port de communication avec mon Arduino. Ce n’est donc pas obligatoire dans votre cas (comme nous le verrons par la suite).

Passons à l’utilisation de tout cela.

Utilisation

Si nous devions résumer une utilisation simple de cet environnement, voici les étapes que nous ferions :

créer un dossier pour notre projet
créer un fichier avec l’extension .ino et remplir ledit fichier avec un programme
créer un fichier Makefile dans le dossier du projet
y ajouter quelques variables
lancer la commande make
brancher l’Arduino et faire un make upload

Et le tour est joué !

Je pense que le point à éclaircir ici est celui du fichier Makefile à remplir. Rien ne vaut un bon vieil exemple de mon fichier Makefile pour le projet Blink qui fait clignoter la LED 13 de mon Arduino MEGA 2560 :

BOARD_TAG = mega2560
ARDUINO_LIBS = 
ARDUINO_PORT = /dev/ttyACM0

include /usr/share/arduino/Arduino.mk

Rien de plus, rien de moins. Avec ça, un simple make && make upload devrait faire l’affaire 😃

Les commandes disponibles

Le fichier Makefile inclut celui fournit par le paquet arduino-mk. Et ce dernier est rempli de commandes en tous genre. Le mieux pour s’en rendre compte est de lancer la commande suivante dans votre projet :

make help

Vous aurez tout un tas de commandes possibles. Par exemple je souhaitais connaître les valeurs possibles de la variable BOARD_TAG, ayant un modèle spécial d’Arduino. J’ai donc fait :

make show_boards

ce qui m’a permis de savoir que le modèle mega2560 était disponible.

Conclusion

Je trouve ce fichier Makefile parfait pour développer en toute sérénité sans avoir à installer l’environnement Java nécessaire au programme conseillé par Arduino et tout en gardant son outil de développement favori.

Petit bonus pour ceux qui aiment s’amuser avec la sortie série d’un Arduino : si votre programme ajoute des Serial.print(), vous pouvez voir la sortie de votre Arduino en utilisant le logiciel minicom de la manière suivante :

minicom -b 9600 -o -D /dev/ttyACM0

Ça me rappelle mes débuts sous la carte Efika tiens !

Serveur de machines virtuelles avec VirtualBox

Mon, 31 Mar 2014 13:26:10 +0100

Introduction

Connaissez-vous les machines virtuelles ? Ces espèces de boîtes dans lesquelles on peut faire tourner un système d’exploitation entier et qui permettent - quasiment - de faire fonctionner des services de la même manière sous différentes plateformes ?

Si vous lisez l’article, je suis sûr que oui ! La virtualisation est un outil formidable, plus encore avec VirtualBox.

Le problème, quand on a un serveur distant, c’est que nous n’avons pas d’interface graphique pour créer et gérer ses machines virtuelles.

Description du problème

En effet, quand on installe VirtualBox sur un serveur sans interface graphique, on ne sait pas trop comment créer une machine virtuelle ni comment la lancer. Certes on pourrait créer la machine virtuelle sur notre ordinateur, puis l’envoyer sur notre serveur. Mais comment la lancer ensuite ?

Il existe bien un VBoxManage (commande console) pour gérer les machines virtuelles, mais c’est très fastidieux.

L’idée serait d’avoir une interface qui se connecte au serveur distant afin de pouvoir créer et gérer nos machines virtuelles.

L’interface qui va se connecter au serveur distant

Cette interface existe, elle se nomme RemoteBox.

Cela permet de se connecter à notre VirtualBox distant et de voir quelles machines virtuelles existent, en créer de nouvelles et les gérer.

Et le mieux dans tout ça : l’interface ressemble très fortement à VirtualBox, ce qui ne nous dépayse pas ;)

En bref, comment procédons-nous ?

Pour résumer la manière de procéder, en quelques étapes (que je détaille sur mon recueil d’astuces dans un tutoriel):

On installe VirtualBox sur le serveur distant
On installe le pack d’extension qui permet de lancer le Web Service sur le serveur distant
On enlève la vérification identifiant/mot de passe du Web Service (sachant que nos ports sont fermés)
On lance le service web sur le serveur distant
On installe RemoteBox sur notre machine locale
On ouvre les ports 18083 et 3389 en SSH (tunnel)
On utilise RemoteBox pour s’y connecter

Il y a plus de détails sur mon wiki au sujet de l’installation et configuration de VirtualBox en mode serveur et utilisation de RemoteBox pour s’y connecter.

Conclusion

Avec RemoteBox, l’utilisation de VirtualBox sur nos machines distantes est facile et sécurisée (puisqu’on utilise des tunnels SSH). Je n’ai plus peur de créer une machine virtuelle et d’en suivre son installation mais aussi de gérer l’allumage et l’extinction de ces dernières.

À noter qu’il existe aussi une interface nommée phpvirtualbox qui permet d’avoir l’interface via un navigateur Web.

En revanche les machines virtuelles demandent d’allouer un espace mémoire vive à ces dernières et bloquent donc une partie de la mémoire. Si on veut utiliser 5 machines à 1Go de mémoire vive, on bloque 5Go.

Des solutions plus efficace existent pour ne lancer que quelques services dans des genres de machines virtuelles : les conteneurs. Par exemple Docker qui est une solution qui se fait connaitre de plus en plus et qui sera probablement le sujet d’un prochain article !

Traduction de ses scripts Lua avec gettext

Mon, 02 Sep 2013 18:32:01 +0100

Introduction

En ce moment j’avance sur un projet informatique écrit dans le language Lua. Je m’essaie ainsi à ce langage et en profite de sa puissance pour mes scripts de création de sites web comme PorteAil ou encore Makefly.

Ainsi, pour l’un ou l’autre raison j’ai besoin de traduire les messages d’erreurs de l’application en la langue de l’utilisateur. Il y a probablement plusieurs méthodes, mais voici celle que j’utilise.

Notez que je donne le détail complet du code dans mon tutoriel sur Gettext pour Lua.

Image sous Licence Creative Commons CC-BY 2.0 trouvée sur une galerie photo de gsfc.

Gettext

L’outil le plus utilisé selon Internet est Gettext. Il permet de parcourir notre code afin d’en extraire les chaînes à traduire. Puis divers outils permettent de procéder à la traduction des chaînes, soit automatiquement, soit manuellement.

Enfin l’outil va générer des fichiers binaires pour une rapidité accrue de traitement/lecture/rendu.

Implémentation

Il n’y a pas d’implémentation à part entière pour Lua, il faut donc créer sa propre implémentation.

En premier lieu on doit créer une fonction qui va lire nos chaînes et donner la traduction (en lisant le fichier binaire spécifique à la langue de l’utilisateur. Généralement c’est une fonction _ (espace souligné) qu’on utilise. Elle va lire le fameux fichier binaire (extension *.mo) de Gettext et donner le résultat.

Sachant que nous voulons retourner les erreurs du programme/script en plusieurs langues, il va falloire initialiser la fonction avant le début de nos traitements.

Vous pouvez voir tout ceci dans le tutoriel sur Gettext pour Lua que je vous ai concocté.

Résumé

Si on devait synthétiser, voici ce qu’il faut faire :

faire une fonction _ qui lit une chaîne et donne sa traduction
faire une fonction qui lit un fichier *.mo et cherche une chaîne donnée pour en sortir son résultat
initialiser le chargement du fichier *.mo et la fonction de traduction en début de script
ajouter les chaînes à traduire dans des fonctions _()
parcourir notre code avec gettext pour récupérer les chaînes à traduire
traduire
convertir en fichier binaire
joindre le binaire à notre programme et enlever les fichiers temporaire (*.po, *.pot, etc.)

Conclusion

En dehors de la lecture du fichier binaire de gettext qui se résoud facilement en cherchant sur Internet, l’implémentation fût facile et le résultat est au-delà de mes espérances.

L’avantage d’avoir des fichiers à traduire au format *.po, c’est que des interfaces graphiques simples telles que gTranslator ou poedit permettent à des non-initiés au code de programmation de traduire votre application sans avoir à lire du code.

Des interfaces web permettent également de traduire en ligne sans installer quoique ce soit. C’est donc très utile pour des projets !

Liens utiles

Un seul outil pour les dernières versions de nos applications

Thu, 25 Jul 2013 11:24:18 +0100

Introduction

Quand on maintient un serveur web et qu’on utilise quelques applications chez soi librement téléchargées sur le net, on a besoin de connaître les dernières versions de chacune desdites applications.

À cet effet on utilise très fréquemment les flux RSS. Le souci c’est qu’on a un flux RSS par projet. Cela fait très vite un joyeux bordèle dans notre lecteur de flux du fait des trop nombreuses applications.

Certaines catégorisent, mettent dans des dossiers à part, voire un compte RSS à part dans leur lecteur.

Je vais vous présenter ici quelques outils que j’ai utilisé pour me faciliter la tâche de veille technologique.

Étape 1 : trouver les flux RSS

Ce n’est pas toujours simple de trouver un flux RSS contenant les dernières versions d’un outil. Dans ma liste, le seul outil que j’ai vu proposer directement les dernières version est ikiwiki. Exemple : http://ikiwiki.info/news/index.rss

D’autres ne se tracassent pas avec ça. À la place, on dispose au mieux du flux RSS de leur blog. Ce qui n’est pas plaisant car les blogs donnent d’autres articles que simplement les dernières versions.

Une idée serait de suivre soit le flux RSS des blogs en ne filtrant que les dernières versions : quasi impossible car il n’y a pas de règles prédéfinies pour une sortie de version, soit tout simplement de suivre le flux RSS du dépôt du code source en ne filtrant que les tags. Par exemple avec les dépôts si connus de Github. Exemple : https://github.com/splitbrain/dokuwiki

Plusieurs outils existent pour cela, on nomme ça plus ou moins un github-tags. D’ailleurs celui que j’utilise est : github-tags de Mic92.

Une démonstration de l’outil github-tags est disponible sur le web.

Étape 2 : FUUUUUU… SION !

Image sous Licence Creative Commons CC-BY 2.0 trouvée sur une galerie photo de gsfc.

Une fois l’ensemble des flux récupérés, il serait intéressant de n’en faire qu’un. C’est le travail de l’outil moonmoon qui se charge de prendre l’adresse de plusieurs flux et affiche le résultat.

Le tout est consultable par le web ou via un flux ATOM. On peut également récupérer le fichier OPML permettant d’importer tout les flux dans son propre lecteur de flux.

Avouez que c’est génial comme outil, non ?

Conclusion

Grâce à github-tags et moonmoon, plus d’excuses d’avoir des applications à la ramasse ! Vous serez toujours au goût du jour.

Contraste du bureau avec Redshift

Fri, 01 Mar 2013 12:30:00 +0100

Introduction

Il y a bientôt 2 ans, je vous parlais de l’ergonomie à son poste informatique. Ne vous inquiétez pas, c’est toujours à jour, simplement nous allons le compléter avec un logiciel supplémentaire : un outil qui permet d’adapter le contraste/température de votre écran en fonction de votre géolocalisation, de l’heure de la journée et de la température du soleil.

Redshift

C’est bien de cela que nous parlons : Redshift.

Cet outil permet d’adapter la couleur/contraste/température de votre écran pour économiser vos yeux.

Comment s’y prend-t-il ?

C’est très simple, il s’occupe d’adapter cette température en fonction de :

l’heure de votre ordinateur
la longitude et latitude que vous lui donnez

En somme il va calculer le degré d’ensoleillement que vous subissez afin d’adapter l’écran à cette lumière théorique.

Il vous faudra donc jouer le jeu en donnant votre positionnement GPS au logiciel afin qu’il puisse se lancer.

Pour plus d’information je vous invite à lire le tutoriel de Redshift sur mon recueil d’astuces.

Conclusion

Après plusieurs jours d’utilisation, je vous garantie qu’on sent la différence :

moins de fatigue en fin de journée
moins de picotements aux yeux
moins d’éblouissements de la lumière

En somme, ce n’est que du bonheur !

Note : attention, je pense qu’il peut devenir désagréable de ne pas avoir ce logiciel quand on utilise d’autres ordinateurs.