Nouvel outil de traduction hors ligne
Le besoin
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’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
Utilisation
Ç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.
Utiliser l’historique Bash
Apperçu rapide
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/
Tableau récapitulatif
Et voici un tableau à garder sous la main en cas de besoin
!! | dernière commande |
!rm | dernière commande qui commence par rm
|
!?force? | dernière commande qui contient force
|
!$ | dernier argument de la dernière commande executée |
!^ | premier argument de la dernière commande executée |
!* | tous les arguments de la dernière commande executée (synonymes: !!:1* !!:1-$ !!:* ) |
!scp$ | dernier argument de la dernière commande qui commence par scp
|
!scp^ | premier argument de la dernière commence qui commence par scp
|
:p | affichage au lieu d’exécuter |
:h | dirname (head) |
:t | filename (tail) |
:r | enlève l’extension (peut être utilisé deux fois pour des fichiers tar.gz ) |
:e | retourne l’extension seulement |
^search^replace | remplace search par replace dans la dernière commande |
!rm:s/search/replace/ | remplace search par replace dans la dernière commande commençant par rm
|
!rm:sg/search/replace/ | remplace partout … |
sudo !! | relance la commande précédente avec sudo
|
chmod +x !$ | un exemple parmi mille de l’utilisation du racourci !$
|
!scp^:h | le chemin du fichier copié par scp (si le fichier était le premier argument à scp ie il n’y avait pas d’options) |
!grunt:2-$:p | affichage tous les arguments sauf le premier de la dernière commande commençant par grunt
|
Re-écrire un historique git
Contexte
Ç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.
Le problème
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:
- retirer les clefs d’accès au dépôt du composant en question du fichier
auth.json
- insérer «/en dur/» dans le dépôt git les sources du composant, et mettre à jour les fichiers
composer.json
etcomposer.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:
- c’est contractuellement Ok;
- 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.
La solution
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:
- tous vos commits ont maintenant des identifiants différents;
- 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.
Astuces de printemps
Astuces de printemps / aka nouvelle fournée de Petits Tips
Supprimer le canal alpha des images
À 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
Docker
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
Redirection de port à l’intérieur d’un 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
Convert mp4 into gif
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
Background dynamique
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)
Tableau récapitulatif des bandes passantes
Contexte
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.
Le tableau magique
D’une page wikipedia, j’ai extrait les valeurs suivantes:
Connection | bit/s | MB/s |
---|---|---|
Fast Ethernet (100BASE-X) | 100 Mbit/s | 12.5 MB/s |
Gigabit Ethernet (1000BASE-X) | 1 Gbit/s | 125 MB/s |
2.5 Gigabit Ethernet (2.5GBASE-T) | 2.5 Gbit/s | 312.5 MB/s |
5 Gigabit Ethernet (5GBASE-T) | 5 Gbit/s | 625 MB/s |
10 Gigabit Ethernet (10GBASE-X) | 10 Gbit/s | 1.25 GB/s |
USB 2.0 | 480 Mbit/s | 60 MB/s |
USB 3.0 (aka USB 3.1 Gen 1) | 5 Gbit/s | 500 MB/s |
USB 3.1 (aka USB 3.1 Gen 2) | 10 Gbit/s | 1.212 GB/s |
USB 3.2 (aka USB 3.2 Gen 2×2) | 20 Gbit/s | 2.424 GB/s |
Conclusion: Pour profiter réellement de l’USB 3 du NAS il va falloir investir dans un switch 10 Gigabits.