Arq est compatible macOS et Windows mais pas Linux. Or l'arrivée d'un serveur à la maison change la donne, car je tiens également à le sauvegarder. Donc la question du logiciel de sauvegarde. Donc la question du stockage.

J'aurais pu partager l'espace entre toutes les machines ? Probablement que ça aurait pu continuer ainsi.

Sur ma machine, j'aimerais :

• un truc qui tourne tout seul en tâche de fond — une fois configuré, y'a rien à penser ;
• de la sauvegarde sur stockage compatible S3 ou Backblaze B2 ;
• soit une interface graphique qui fait le job ;
• soit un fichier de configuration qui décrit tout (destinations, conditions, fichiers à inclure/exclure).

Idéalement, j'aimerais appliquer la même chose sur un deuxième ordinateur à la maison, sous Windows.

Le paysage a changé depuis cette dernière exploration — concomitante à celle d'Éric. Alors je me suis relancé dans recherches et comparaisons.

Restic(profile)

Le serveur auto-hébergé utilise déjà restic. C'était très facile à configurer avec Yunohost. Donc ça doit bien être la même chose ?

Sauf que par défaut, restic sauvegarde mais ne tourne pas en arrière-plan. Et il faut arriver à tout exprimer en une ligne de commande.

resticprofile ajoute la dimension "configurer avec un fichier". Ça aurait pu me plaire mais j'ai eu du mal à rentrer dans les concepts. Au final, j'ai crains de faire des erreurs, et donc à créer une sauvegarde qui fonctionne mais marche mal.

Borg(matic)

C'est surtout que j'avais testé Borgmatic juste avant. J'avais adoré sa syntaxe de configuration et la clarté de la documentation.

Mais pas encore de destination S3/B2 dans le logiciel bas-niveau, Borg v1. Dommage dommage !

Kopia ou Duplicity ?

Sans avoir à payer d'abonnement annuel ni triturer les entrailles, il ne me restait plus que Kopia et [Duplicity]. Le gagnant a été le … premier onglet d'ouvert. Donc Kopia.

La configuration des règles a été un peu laborieuse au début — à 2 heures du matin je n'y voyais plus très clair :

• puis j'ai compris que les Policies correspondaient aux règles de sauvegarde
• et que les snapshots correspondaient aux artéfacts de sauvegarde de chaque règle.

Ainsi en sauvegardant tous les jours à 13h00, je n'ai pas une sauvegarde mais autant que de règles.

Quand il a fallu recréer les règles pour paramétrer la sauvegarde sur un disque dur USB, frustration : il fallait tout recréer. S'il n'y avait rien dans l'interface, il y avait en revanche deux utilitaires (kopia export et kopia import) qui permettaient de dupliquer les règles d'une destination de sauvegarde à une autre.

Au passage, ça m'a permis d'apprendre à combiner le trousseau de sécurité macOS (via le programme security) et KeypassXC. Et que par exemple, on peut utiliser un mot de passe rattaché à sa session macOS pour obtenir une valeur contenue dans un autre gestionnaire de mots de passe :

security find-generic-password -a 'restic' -w | keepassxc-cli show -sqa password  ~/Library/CloudStorage/MountainDuck-nextcloud.maison.lan/keypass-sync/restic.kdbx sauvegarde

Cette commande aide à extraire l'attribut password ^[2] de l'entrée sauvegarde dans la base de données Keepass restic.kdbx. La base est déverrouillée avec un mot de passe stockée dans le trousseau natif de macOS.

• pas de bon logiciel d'appareil photo
• pas de logiciel de galerie photo (historisation, annotation, synchronisation partage, retouche légère type recadrage)

Immich sort du lot avec exactement ça : synchronisation, interface mobile, interface sur ordinateur.

L'utilisation combinée de Immich Go avec Google Takeout et iCloud Takeout m'a permis de récupérer photos et albums hébergés chez Apple et Google.

Je gère la sauvegarde chez Backblaze B2 Cloud Storage. D'ici la fin de l'année, j'aimerais plutôt payer une fois le montant annuel (67€) dans un disque dur et offrir un nœud de stockage Garage. Comme ça on se fait du backup redondant en pair à pair.

Volte face sur ma configuration : plutôt qu'un appareil 2G, un vieux smartphone déconnecté et un routeur 4G, j'ai voulu tout réunir en un.

Je me sens confronté à un choix de soit favoriser du matériel éthique (type Fairphone) ^[1] soit favoriser du logiciel sans espion.

J'aurais aimé choisir les deux mais j'ai opté pour le logiciel sans espion avec GrapheneOS. Je me suis dit que la puissance des GAFAM dans le monde était plus terrible encore.

Alors pour le fun, je veux que ce téléphone dure 10 ans.
Rendez-vous en 2036.

C'est une lente remontée de rivière avec quelques colines, quelques traversées de villages et quelques passages plus sauvages.
La section entre Saint-Gervais et Grenoble circulait davantage : on se salue peu, on se croise beaucoup … et c'est tout.

Est-ce qu'ajouter un attribut target="_blank" sur des liens hypertextes absolus suffit ? Non, l'exemple du module markdown-it-for-inline ne suffit pas.

J'aimerais :

• gérer la sécurité avec l'onglet ouvert. Il pourrait être utilisé par des pisteurs, sur la page nouvellement ouverte, par des extensions web verrolées ;
• informer de la destination aux lecteurs d'écran. La destination étant "un nouvel onglet". Ça correspond au critère 6.1.1 du RGAA ;
• distinguer visuellement les liens qui ouvrent un nouvel onglet. Même intention, visuelle cette fois.

La sécurité se gère à l'aide des valeurs noopener et noreferrer de l'attribut rel.

Elles préviennent, respectivement, l'accès à la propriété window.opener et à la diffusion de la provenance via l'entête HTTP Referrer.

Ça aide à préserver notre vie privée numérique.

On peut donner du contexte aux lecteurs d'écran dans un label ARIA :

1. qui repend l'intitulé du lien ;
2. et qui spécifie l'ouverture dans un nouvel onglet.

L'utilisation du rotor VoiceOver est un bon exemple de cette visibilisation :

L'antépénultième lien de cette capture d'écran rend explicite l'ouverture dans un nouvel onglet. Ça correspondrait au code HTML suivant :

<a href="..." aria-label="critère 6.1.1 du RGAA (ouvre une nouvelle fenêtre)">
  critère 6.1.1 du RGAA
</a>

Quelques lignes de CSS suffisent à ajouter un symbole visuel à la suite du lien :

a[target="_blank"]::after {
  content: "";
  display: inline-block;
  inline-size: .8em;
  block-size: .8em;
  /* ... */
  background-color: currentColor;
  mask-image: url("data:image/svg+xml;base64, …");
  mask-repeat: no-repeat;
  mask-size: contain;
}

L'utilisation combinée des propriétés background-color et mask-* aident à respecter les proportions de l'image vectorielle et à la détourer aux couleurs du texte du lien.

L'image est encodée directement dans la feuille CSS pour éviter un temps de latence à l'affichage.

C'est bon, nos liens externes sont désormais accessibles. Le code source des liens externes accessibles pour markdown-it (intégré à Build Awesome) est consultable dans le dépôt de ce carnet.

C'est une ascension de onze kilomètres sur une route empruntée par des voitures mais sans trop. On a opté pour des chemins de traverses entre Bourdeaux et Saoû : en passant par les très beau villages du Poët-Célard et de Francillon-sur-Roubion. Ça rallongeait et rajoutait du dénivelé (presque quatre-cent mètres) mais ça vallait le détour en cette saison.

On craignait le trafic important entre Saoû et Crest après 17h. On a alors opté pour un autre chemin de traverse, par la Répara-Auriple.

C'était la balade avec le plus de dénivelé en une journée. Je suis content de voir que j'avais encore de l'énergie en fin de journée. Et surtout, quel régal visuel tout au long du périple.

La lecture de l'article making emojis and icons screen reader accessible m'a fait agir dessus sur ce blog avec l'extension markdown-it-emoji.

J'ai suivi la documentation pour rendre l'affichage accessible.

Ainsi, le raccourci textuel :pray: est converti en :

<span class="emoji emoji--pray" aria-hidden="true">🙏</span>

Il a fallu plonger dans les entrailles du fonctionnement de markdown-it pour que chaque émoji existante soit elle aussi, convertie dans un code similaire.

J'ai créé une règle qui est insérée avant l'extension émojis pour convertir chaque émoji (unicode) en raccourci textuel d'émoji :

1. on parcourt chaque jeton markdown ;\

{
  type: 'inline',
  content: 'Coucou 👋🏻'
}

2. on vérifie la présence d'une émoji (via leur classe Unicode d'expression régulière) ;
3. on remplace chaque occurence par son raccourci textuel.\

{
  type: 'inline',
  content: 'Coucou :wave:'
}

4. qui a son tour rentre dans la moulinette expliquée précédemment\

  <p>Coucou <span class="emoji emoji--wave" aria-hidden="true">👋🏻</span></p>

Le code complet est disponible sur GitHub.

Tout autre émoji décoratif (comme dans cette entrée de journal par exemple) est masquée aux lecteurs d'écran avec aria-hidden="true" :

<h1 id="post-title">
  <span aria-hidden="true">☕️</span>
  Journal : Émojis accessibles
</h1>

Je n'ai pas eu à reprendre les vingt années de contenus pour y arriver. La lecture d'une issue GitHub, d'une proposition de code et le code d'autres extensions markdown m'ont aidé à mettre en place les mécanismes ci-dessus.

Un lieu m'intrigait depuis plusieurs années : le col Jérôme Cavalli. Je ne savais pas à quoi ressemblait le paysage d'un endroit dont je voyais la signalétique mais rien de plus.

Alors, c'est l'occasion d'un détour… et d'un bon et long dénivelé.

Le trajet était pastoral et fleuri depuis la sortie de Chabeuil par les petites routes. Avec des senteurs de glycines près des maisons et de bruyères dans la lente ascension.

La route était tranquille et peu fréquentée : j'y ai croisé davantage de cyclistes que de voitures.

Et c'est une chose que j'adore avec cet apprentissage ouvert : on sait à peu près par où on commence, on a une petite idée d'où on veut aller mais le chemin est imprévisible.

Je tente un audit d'accessibilité après l'ajout d'une carte basée sur MapLibreGL et :

1. le titre par défaut du composant est en anglais : je souhaite le personnaliser en français ;
2. mais il manque un rôle au composant (image, région ou application par exemple) ;
3. et je découvre un audit d'accessibilité daté de 2021 qui révèle d'autres points d'amélioration (structure hiérarchique, alternative textuelle à des symboles, taille minimale des zones de clic).

Je me suis proposé pour prendre en charge ces corrections.
De manière égoïste parce que j'aimerais que les cartes de mon carnet web soient accessibles (une des intentions de la refonte 3.0).
Et aussi pour que les cartes interactives basées sur MapLibreGL le deviennent, accessibles, sans grand effort supplémentaire.

J'envisage une amélioration progressive de ce composant en expérimentant avec le composant <is-land> :

• utilisation d'une image légère, statique pour représenter la carte ;
• un bouton d'activation d'interactivité qui charge deux à trois cent kilo-octets d'interactivité.

J'envisage aussi de donner accès au téléchargement des tracés, pour le récupérer sur un autre appareil. C'est un des bénéfices des données interopérables. Et de leur attribuer une licence, pour rendre explicite leur source/origine/conditions de réutilisations.

J'en avais envie et besoin.
Envie car ça faisait longtemps que je n'avais pas fait de vélo à la journée, sur une longue distance (cent kilomètres ça commence à faire long pour mon niveau).
Besoin car il y a un genou à remuscler après une entorse en février.

J'aime bien les différents segments paysagers de ce parcours : des tunnels forestiers, de la loooooongue ligne droite en bord de Rhône (avec toutes ses infrastructures hydroélectriques — barrages et centrales nucléaires), des zones maraichères, des vis à vis industriels (pétrochimie, usines à papier, etc.).

Dans les deux sacoches :

• quelques vivres sucrées pour tenir la route ;
• une poche à eau (vide) de trois litres ;
• une gourde à eau de un litre ;
• du rechange pour 4 jours (dans des cubes de rangement, comme ça c'est facile à sortir/ranger) ;
• serviette de bain et trousse de toilette ;
• un sac à dos léger de travail (ordinateur, pochettes à câbles, carnet, trousse) ;
• de la place pour peut-être revenir avec quelques affaires en plus.