Vivant et travaillant en Allemagne, utilisant les langues anglaise et allemande de manière professionnelle, le français et l’allemand dans la sphère privée, je suis un utilisateur pas très modéré des outils de traduction en ligne.

Aussi l’annonce d’un outil de traduction hors ligne basé sur des travaux universitaires par Mozilla m’a enchanté. La description technique de la conception de l’outil est intéressante à lire.

Malheureusement l’outil n’est distribué que sous la forme d’une extension Firefox, et le dépôt git et les explications pour obtenir une application indépendante est indigeste. «Hillariously difficult to use» pour rependre le titre d’un rapport un bogue, dont une réponse pointe vers Kotki, un projet dérivé qui promet de simplifier l’utilisation de l’outil.

L’installation de Kotki se déroule en deux partie. Au niveau système, en tant que root:

apt install -y cmake ccache build-essential git pkg-config \
    rapidjson-dev pybind11-dev libyaml-cpp-dev python3-dev \
    python3-virtualenv libopenblas-dev libpcre2-dev \
    libprotobuf-dev protobuf-compiler libsqlite3-dev
pip3 install kotki -v

En tant qu’utilisateur, il faut ensuite télécharger les «modèles» permettant de traduire d’une langue à l’autre:

mkdir -p ~/.config/kotki/models/
cd /tmp/
# Voir https://github.com/kroketio/kotki/releases
wget https://github.com/kroketio/kotki/releases/download/0.6.0/kotki_models_0.3.3-tiny.zip
unzip kotki_models_0.3.3-tiny.zip -d ~/.config/kotki/models

Personnellement je télécharge la version tiny du fichier, parce que le fichier contient les modèles de traduction dont j’ai besoin. Si vous êtes intéressé par le russe ou l’ukrainien, la version complète sera nécessaire:

wget https://github.com/kroketio/kotki/releases/download/0.6.0/kotki_models_0.3.3-tiny.zip
unzip kotki_models_0.3.3.zip -d ~/.config/kotki/models

Ça marche plutôt pas mal:

kotki-cli -i "Longtemps je me suis couché de bonne heure."
# For a long time I went to bed early.

kotki-cli -m enfr -i "For a long time I went to bed early."
# Pendant longtemps, je suis allé me coucher tôt.

kotki-cli  -i \
"Als Gregor Samsa eines Morgens aus unruhigen Träumen erwachte, \
fand er sich in seinem Bett zu einem ungeheueren Ungeziefer \
verwandelt."
# One morning, when Gregor Samsa awoke from troubled dreams,
# he found himself in his bed turning into a monstrous vermin.

kotki-cli -m ende -i \
"One morning, when Gregor Samsa awoke from troubled dreams,\
 he found himself in his bed turning into a monstrous vermin."
# Eines Morgens, als Gregor Samsa aus unruhigen Träumen erwachte,
# fand er sich in seinem Bett wieder, das sich in ein
# ungesäuertes Ungeziefer verwandelte.

Mais l’allemand, n’est pas encore très au point.

Une autre critique: l’anglais est pivot. Il n’existe pas (encore?) de modèle permettant de traduire de l’allemand vers le français ou du français vers l’allemand.

Bash propose des raccourcis bien utiles pour relancer des commandes, ou des bouts de commandes, précédemment exécutées. Cette page va recenser ceux que j’ai trouvés les plus utiles jusqu’à présent.

Voici quelques exemples d’usage:

# Relance la dernière commande en la faisant précéder par sudo
sudo !!
# Opération inverse: relancer la dernière commande sudo sans sudo
!*
# Pour modifier le dernier fichier visualisé avec less
!less:s/less/vi/

Et voici un tableau à garder sous la main en cas de besoin

Ça y est. Après des mois de travail appliqué, le projet est achevé: toutes les fonctionalités ont été implementées, la couverture de tests est satisfaisante, les scripts de déploiement vers les différents environnements fonctionnent.

Bref le client est satisfait et l’heure est venue de transmettre le projet. Cet fois-ci le client souhaite être autonome et continuer seul à exploiter et faire évoluer le logiciel. C’est son choix, c’est son droit, pas de problème.

Une dernière vérification sur le dépôt dévoile une petit souci: le script de déploiement, lors de la phase de construction du paquet, utilise un fichier auth.json utilisé par composer afin d’accéder à des composants php sous licence. Et ce fichier est enregistré dans le dépôt. Donc si le projet est livré en l’état au client, celui-ci continuera à avoir accès aux dépôts privés.

Après consultation du département des ventes, nous apprenons que nous devons distinguer plusieurs cas:

• il y a des composants pour lesquels le client a acquis les droits sur les mises à jour futures;
• pour d’autres logiciels, seule la version disponible au moment de la livraison devra rester accessible;

Pour les premiers composants, les identifiants peuvent rester dans le fichier auth.json sans problème. Lorsque les futurs développeurs du projet lanceront la commande composer update les dernières versions seront alors téléchargées. En revanche pour les autres composants (un seul en fait) il va falloir faire autrement.

La méthode va être la suivante:

1. retirer les clefs d’accès au dépôt du composant en question du fichier auth.json
2. insérer «/en dur/» dans le dépôt git les sources du composant, et mettre à jour les fichiers composer.json et composer.lock en conséquent.

Nous allons nous simplifier la tâche: la deuxième partie (copie du composant dans le dépôt) sera mise en œuvre dans un nouveau commit. C’est un peu de la triche parce que cela signifie que le projet livré ne tournera pas ou ne pourra pas être construit avec les commits précédents le dernier. Néanmoins:

1. c’est contractuellement Ok;
2. cela fera à peine un peu plus de travail pour les nouveaux développeurs lorsqu’ils voudront utiliser un git bisect.

Quant à la première partie du nettoyage de notre dépôt git, nous allons devoir utiliser un outil diabolique: git filter-branch.

Cet outil est tellement diabolique que la documentation officielle vous suggère d’utiliser une alternative plus sûre comme filter-repo. Après avoir attentivement lu la documentation des deux outils, j’ai préféré utiliser le plus dangereux des deux, filter-branch. Pas par amour du risque, mais par besoin de simplicité.

Les deux outils permettent de re-écrire l’historique d’un dépôt git. Modifier l’historique d’un dépôt git n’est pas anodin. Une fois le serveur de référence mis à jour avec le nouvel historique, tous les développeurs devront re-cloner leur dépôt avant de pouvoir pousser à nouveau leurs modifications. Bien sûre, dans le cas décrit ici, cela n’est pas problématique, puisqu’il n’y aura que des nouveaux développeurs.

Alors que filter-repo permet essentiellement de modifier l’historique d’un dépôt git en supprimant, ajoutant ou modifiant des fichiers dans chaque commit, filter-branch permet d’exécuter une commande avant chaque commit. Dans notre cas, nous allons écraser le fichier auth.json avec la version contenant les clefs permises.

git filter-branch --tree-filter 'cp /tmp/auth.json src/auth.json' HEAD

Et voilà!

À noter:

1. tous vos commits ont maintenant des identifiants différents;
2. le fichier src/auth.json a été automatiquement ajouté au premier commit, même si cela n’était pas le cas avant.

Mon projet comportait quelques centaines de commits. La commande n’a pas mis plus de quelques minutes pour s’exécuter sur un ordinateur type desktop.

Encore une fois, la commande git filter-branch est à utiliser avec parcimonie, et uniquement en dernier recours.

D’après le calendrier c‘est le printemps. Il est temps de publier une nouvelle liste de petits trucs. Dorénavant j’appellerai ces articles «p'titstips».

À cause d’un bug dans une librairie utilisée dans un projet, toutes les images avec un fond transparent apparaissaient avec un fond noir. En attendant une version corrigée de la librairie, il a été décidé de mettre un fond blanc aux images avec transparence. Voici la commande qui réalise cette transformation:

convert -resize 200 -background white -alpha remove pic-with-apha.png pic-with-white-bg.png

Lorsque l’hébergeur de votre site vous a mis à disposition une base de donnée dans un container, mais que le container n’est pas démarré automatiquement lorsque le serveur redémarre, il faut changer la configuration du container comme ci-dessous.

docker update --restart always mysql-server-container

Imaginons une application web dans un container, dont le port externe au container 8092 est redirigé vers le port interne 80. Notre application est configurée pour être appelée sur l’adresse 127.0.0.1:8092. Mais lorsque l’application s’appelle elle-même depuis l’intérieur du container, le port 8092 n’est pas atteignable. Il faut donc créer une redirection en utilisant socat par exemple:

socat tcp-l:8092,fork,reuseaddr tcp:127.0.0.1:80

Comme souvent une image veut mieux qu’un long discours, et en description de bug, une vidéo vaut mieux qu’une image. Vokoscreen est donc votre ami pour les déclarations de bug, cet outil vous permettant d’enregistrer ce que vous faites à l’écran. Et lorsque vous avez enregistré votre bug mais que le formulaire du service client pour ouvrir un ticket n’accepte que le format gif, alors ffmpeg vient à la rescousse.

ffmpeg \
  -i vokoscreenNG-2021-04-18_12-25-57.mp4 \
  -r 15 \
  -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" \
  bug-live-test-credit-card.gif

Vous n’arrivez pas à choisir votre fond d’écran? Ne choisissez pas, et changer le fond d’écran toutes les cinq minutes.

while true ; do  for f in `ls *|sort -R` ; do feh --bg-max $f ; sleep 300  ; done; done

(n’a pas été testé avec autre chose qu’Awesome)

Je suis en train de migrer progressivement toutes les mes mini-machines de mon réseau local de Raspberry 2 et 3 vers le Raspberry 4. J’utilise ces machines comme:

• Firewall
• NAS
• Pihole

Le passage de l’USB 2 des anciennes versions à l’USB 3 de la version du Raspberry 4, m’a poussé à chercher le bottelneck de mon infrastructure.

D’une page wikipedia, j’ai extrait les valeurs suivantes:

Conclusion: Pour profiter réellement de l’USB 3 du NAS il va falloir investir dans un switch 10 Gigabits.