Condensé du jour : mercredi 16 juin 2021

Posté le jeu. 17 juin 2021 dans journal

En résumé :

CHATONS et autres coopératives d’hébergement

Un grand merci à Framalang pour la traduction de l’article Hell Site d’Aral Balkan.

Juste un petit extrait pour vous mettre l’eau à la bouche…

Nous devons construire l’infrastructure technologique alternative qui sera possédée et contrôlée par des individus, pas par des entreprises ou des gouvernements. C’est un prérequis pour un futur qui respecte la personne humaine, les droits humains, la démocratie et la justice sociale.

—Le site de l’enfer, publié le 5 juin 2021, sur le Framablog.

Et pour poursuivre les lectures orientées numérique, encapacitation et vie privée :

Depuis trois ans que je donne des ateliers et des cours sur l'Hygiène Numérique, je finis toujours par partager une liste de ressources permettant d'aller plus loin.

[…]

Ces contenus se complètent, et demandent, comme toujours, aux personnes de les consommer en faisant preuve d'esprit critique. Je ne suis pas d'accord avec absolument tout ce qui est dit dans tous les contenus proposés ici. Il n'empêche que tous sont intéressants et permettent d'affiner son regard sur l'impact du numérique sur nos environnements.

—Hygiène Numérique — Quelles ressources pour creuser le sujet ?, publié le 7 juin 2021 sur dreads-unlock.fr.

Quelques applications Nextcloud repérés pour leur potentiel :

  • Announcement center offre un canal de communication des administrateurs de la plateforme vers tout ou partie des utilisateurs ;
  • Temporary files lock permet de bloquer un document pour travailler dessus sans craindre l’édition par une autre personne (je ne sais pas si cette fonctionnalité apparaît aussi dans le client de bureau, là où elle serait la plus utile…).

Édition collaborative

Depuis plusieurs mois, je propose des services collaboratifs pour associations, collectifs et entreprises.

J’ai cependant un retour personnel mitigé sur l’édition collaborative textuelle, notamment sur l’obligation de passer par une interface web pour bénéficier de la collaboration.

En effet, pour bien juger de l’impact de mes développements et des technologies que je déploie, je travaille sur un matériel limité en ressources (RAM et processeur). Lors de visioconférences avec rédaction collaborative de compte-rendu en direct, deux interfaces web exigeantes en ressources sont chargées en même temps et mettent en difficulté mon matériel…

Je souhaite donc passer au maximum par des applications de bureau pour travailler (gain de ressources et gain d’efficacité en utilisant ses dix doigts).

De plus, le paradigme de dépôt centralisé avec services intégrés choisi par Nextcloud ne me convient pas vraiment et j’aimerais pouvoir connecter un outil de bureau à un dépôt de contenu dédié mais interconnecté et que ce dernier puisse aussi discuter avec une application web, pour les usages ponctuels.

Si je vous parle de tout ça, c’est que j’ai découvert le projet Etebase (brique centrale d’Etesync) qui fourni des fonctionnalités d’échange sécurisé de contenu avec historisation des contributions, édition collaborative…

Etebase supports sharing data, access control, and everything you need for collaborative editing.

—« Why Etebase : Collaborative », sur la page d’Etebase

Je pense donc utiliser cet outil de stockage pour proposer un outil de bureau, assez fonctionnellement identique à Gobby mais avec un fonctionnement privé et sécurisé et une historisation similaires ou supérieurs aux fonctionnalités de Nextcloud.

Pour résumer mes besoins et la future architecture de mes développements :

  • un client de bureau (GTK+ ou compatible) pour l’édition WYSIWYG de documents ReStructuredText et CommonMark ;
  • un client web reprenant la majorité du code (compilée en WebAssembly) avec une interface Web ;
  • des interfaces pour permettre l’écriture dans différents systèmes de stockage : fichier plat, serveur WebDAV, un serveur Etebase…
  • une interface graphique pour associer les deux et notamment pour mimer (ou reprendre de façon amicale) Zim, un wiki de bureau.

Veille technologique

Petite session de veille technologique sur la veille technologique… 😉

Logiciels intéressants :

  • Liferea (FAQ de Liferea, Liferea sur Wikipédia, Liferea sous Debian ; Python 3, GTK+ 3) est un client RSS de bureau avec les fonctionnalités suivantes :
    • lecture de contenus hors-ligne ;
    • complétion contenus quand les flux RSS sont tronqués ;
    • analyse des sites web qui ne disposent pas de flux RSS pour en extraire les articles ;
    • prise en charge des podcasts…
    • plus la possibilité d’étendre les fonctionnalités par des greffons !

Concernant ces deux logiciels, il serait intéressant de tester si le cache peut être sauvegardé et réutilisé.

De plus, pour répondre à mon besoin de recherche internet et de suivi des lectures, il pourrait être envisageable et intéressant de transformer une page de réponse de moteur de recherche en un flux RSS avec ajout du texte de la recherche comme une étiquette…

Ma principale limite avec ces deux logiciels est sur le caractère complètement « intégré » de toutes les fonctionnalités qui peut empêcher de créer un flux de traitement adaptatif selon les sources :

  • complétion ou non des contenus ;
  • récupération de contenus à partir de plusieurs ressources complémentaires ;
  • filtrage et mise au propre (données personnelles…) des contenus et connexions web (il y aurait à priori plus de possibilité de filtrage/protection en passant directement par un navigateur web plutôt que de jouer sur les seuls DNS : détection et blocage adaptatif de JavaScript, AdSense ou autre pubarts servis par exemple par le site web hôte plutôt que par un CDN) ;
  • pas de fonctionnement léger en arrière-plan (sans interface graphique et éventuellement en cron sur un serveur) ;

Parmi les fonctionnalités que je souhaite et qui sont peu évidentes sur ce type de logiciel :

  • ajout de ses propres étiquettes ;
  • déduplication de contenu  : être abonné à un Planet et à un des sites publiés sur le Planet, ou bien être abonné à deux Planet qui se recoupent.

Il me reste à tester les dernières moutures de ces logiciels pour évaluer leurs potentiels et leur extensibilité

Composants intéressants :

  • python3-feedparser pour télécharger et analyser les flux de données syndiqués (utilisé par rawdog dans sa version Python 2) ;
  • feed2exec (Python 3) permet de créer un flux de traitement à partir des nouvelles entrées d’un flux RSS ;
  • rsstail (C) surveille un flux RSS et produit de nouvelles entrées ;

Logiciels à garder sous le coude :

  • RSS Guard (C++, Qt) est un lecture de flux RSS/Atom capable d’interagir avec des services d’agrégation en ligne, qui semble supporter les étiquettes personnalisées et qui s’inspire des fonctionnalités de Liferea ⇒ peut-être top pour les personnes qui sont encore sous Windows… (plus d’informations sur le dépôt Github de RSS Guard) ;
  • Newsboat, lecteur de flux RSS/Atom en console + support podcast avec podboat ;
  • podget, agrégateur simple de baladodiffusions en tâche de fond (implémenté en sh ou autre shell) ;
  • feed2imap (Ruby) télécharge les flux RSS et place les articles dans un répertoire spécifique de serveur courriel ;
  • rss2email (Python 3) envoi un courriel pour chaque nouvel article d’un flux RSS ;

Logiciels écartés :

  • rawdog car restera bloqué en Python 2 ;
  • podracer (Python 2) ;

Idées intéressantes avec les flux RSS :

Blog : contenu et génération

Pour créer le contenu de ce site web, j’utilise la syntaxe ReStructuredText.

Cependant, cette syntaxe, telle qu’utilisée par Pelican, peut comporter quelques écarts par rapport à la syntaxe de référence (Docutils) et aux extensions permises par Sphinx.

Pour capitaliser sur mes bonnes pratiques et conserver une syntaxe au maximum cohérente avec Sphinx, j’utilise le modèle ci-dessous :

==================
Titre de l’article
==================

:date: 2021-06-…
:authors: liste des auteurs de l’article, chacun séparé par une virgule
:category: une et une seule catégorie pour cet article
:tags: liste des étiquettes rattachées au contenu, chacune séparée par une virgule
:slug: titre-de-l-article   (pour contrôler l’adresse de la page sur le site généré ; autrement, on utilise le nom du fichier dans une version « simplifiée »)
:summary: Résumé, tel qu’il sera affiché sur la page d’accueil et dans les listes d’articles (si absent, le début de l’article est utilisé)

..
    :published: date et heure de publication, au format ISO 8601 (2021-06-17T02:22+0200, par exemple)
    :modified: 2020-11-02T14:02+0100
    :status: published      (à activer quand l’article sera prêt à être publié ; la page « Brouillons » n’apparaît que sur le site généré pour développement (make devserver))

Astuce

Pour choisir la catégorie et les étiquettes de l’article, vous pouvez consultez la liste des catégories et la liste des étiquettes actuellement utilisées sur le site, ou en créer une nouvelle / de nouveaux.

Dépendances et commandes pour travailler sur un site propulsé par Pelican.

Installation de Pelican sur le système (Debian) :

# apt install pelican

Générer et servir la version de développement du site :

$ cd "<dossier qui contient le Makefile du site>"
$ make devserver

Résultat

La page d’accueil du blog est disponible en local.

En cas de problème, on peut aussi demander l’affichage des messages de déboguage en adaptant la commande comme suit :

$ make DEBUG=1 devserver

infonuagique veille technologique Pelican