eikan

serveurapplicatif

#SobriétéTechnologique #Yunohost #Bludit #ServeurApplicatif

Sobriété technologique, suite

Je cherchais une solution plus sobre que Wordpress depuis quelques temps pour remplacer le moteur de CMS affichant mon site CV. Ce site ne comporte que 3 pages, dont une page d'erreur 404. Wordpress fonctionne en accédant à une base de données. Une base de données tourne en permanence sur un serveur. C'est ce dont j'ai décidé de m'affranchir. J'ai donc regardé du côté des CMS fonctionnant sans base de données, sur des fichiers plats.

Critères de choix

J'ai repris ma recherche sur le catalogue d'applications de #Yunohost. Je cherchais un CMS fonctionnant de préférence avec un éditeur reconnaissant la syntaxe Markdown, sans base de données donc, et proposant un ou plusieurs thèmes sombres. Il devait aussi gérer des pages statiques comme des articles, au cas où je déciderais d'ajouter des textes temporels à ce site CV. Je n'ai pas besoin de moteur de recherche sur le site cible.

Sur la base d'un site à fichiers plats, je supposais que les fichiers CSS seraient accessibles et permettraient d'apporter des modifications mineures à l'aspect des pages sans grande difficulté.

Passage par le catalogue d'applications de #Yunohost

Après logo Bludit quelques essais, j'ai installé #Bludit. J'ai trouvé plusieurs thèmes sombres. J'ai fini par choisir le thème Popeye.

Le CMS dispose de 2 modules d'édition mutuellement exclusifs, l'un en WYSIWYG et l'autre en Markdown. L'éditeur Markdown propose 2 fonctionnalités utiles : l'édition en plein écran, qui supprime les cadres de l'interface d'administration et une vue de prévisualisation à côté de la zone d'édition. La zone de prévisualisation est synchronisée avec la zone d'édition. J'ai créé la page principale en page statique et déposé les mentions légales dans la deuxième page statique du site.

La troisième et dernière page est celle qui affiche un message d'erreur lorsque l'utilisateur demande une URL du domaine qui n'existe pas, la fameuse page d'erreur 404. J'ai créé cette page d'erreur 404 en tant que page standard, compatible avec les formats d'articles selon le mode de fonctionnement de Bludit, plutôt qu'en page statique. En effet, les pages statiques sont affichées en haut à droite de la barre de navigation. Et je n'avais pas envie d'afficher cette page dans ce menu. Bludit permet de réaliser deux redirections internes. Il permet de sélectionner la page d'accueil parmi les pages existantes et de rediriger les utilisateurs vers la page de son choix en cas d'erreur 404. La page de mes expériences est affichée à l'accueil du site.

Des modules mais pas trop

Bludit fournit une quantité raisonnable et suffisante de modules pour répondre à mes besoins primaires. Je n'ai pas installé le module de recherche. Je n'ai pas non plus installé de formulaire de contact. L'expérience m'a montré que je recevais plus de sollicitation de prestataires que d'offres utiles pour mon activité professionnelle.

Bludit dispose également d'un module qui permet d'éditer les fichiers d'un thème. En théorie, parce qu'en pratique, je n'ai pas vu les modifications s'afficher pour le public. J'utilise le gestionnaire du système Webmin installé sur le serveur Yunohost. Celui embarque un explorateur de fichiers et un éditeur de fichiers plats, à coloration syntaxique, tout à fait suffisant pour mes besoins.

Un autre module a retenu mon attention au début : celui qui permet de rédiger ses contenus au format Markdown dans une arborescence d'un dépôt logiciel de technologie GIT. Les fichiers plats sont ensuite récupérés par le CMS hébergé à la poussée depuis le dépôt GIT. Intéressante sur le papier, cette solution reviendrait à faire stocker des fichiers dans une base documentaire gérée par une base de données pour les envoyer vers un CMS hébergé ailleurs qui n'a pas besoin de base de données. Je vous laisse revoir mes critères initiaux de recherche, pour comprendre que cette solution ne pouvait pas m'intéresser.

La migration des contenus

Mes expériences s'affichent avec des mises en forme d'accordéons. La codification en HTML est simple, basée seulement sur les balises <details> et <summary>. J'ai intégré l'ensemble des accordéons dans une balise <div> au sein du texte Markdown. La balise <div> permet de séparer le code HTML du code strictement Markdown et ne pas perturber l'interpréteur Markdown.

J'en ai profité pour transformer l'affichage des postes occupés dans chacune de mes expériences. J'ai commencé par utiliser un système de badge disponible gratuitement sur Internet. Mais j'ai décidé de ne pas dépendre d'un site extérieur et de ne pas prendre le risque d'installation de cookies traceurs sur les navigateurs des visiteurs du site. J'ai donc habillé les balises <code> avec un fond de couleur et du texte blanc pour améliorer le contraste sur les écrans à fond sombre, comme dans cet exemple POSTE OCCUPE. Comme pour le reste du code HTML, j'ai inclus les balises <code> dans des balises <div>.

La gestion des images et des fichiers à télécharger par les visiteurs

Le CMS gère les images et les dimensionne selon les paramètres généraux du site. Les fichiers doivent être stockés sur un autre hébergement. Je stocke mes 2 CV PDF et DOCX sur mon espace Nextcloud.

La migration du site en conservant le même nom de domaine

Elle a consisté à déclarer le nom de domaine enregistré chez OVH sur l'installation Yunohost pour le récupérer par le CMS auto-hébergé. Yunohost dispose d'une gestion par API avec OVH très performante.

Conclusion

Mon portefeuille de technos se complète d'une solution simple de CMS qui permet de construire un site Web simple et sobre, capable d'afficher des pages d'articles comme statiques, en les stockant sous forme de fichiers plats. Ce type de CMS gère simplement les images et les fichiers à télécharger. Il répond à des besoins primaires.

Par @eikan@newan.net

#SobriétéTechnologique #définition #complexité #ressources #ServeurApplicatif #Yunohost #Writefreely #HedgeDoc #low-tech

Je suis et je lis LOW<-TECH MAGAZINE, et ploum.net, qui précise qu'il écrit son journal personnel sur une machine à écrire.

J'ai installé un serveur applicatif sur #Yunohost et j'ai exploré les applications à mettre à disposition des utilisateurs du serveur.

Au fil du temps, je suis demandé comment je pouvais contribuer à la sobriété technologique, tout en offrant des applications en ligne apportant de la valeur ajoutée aux utilisateurs.

Pour illustrer mon propos, je vais vous présenter 2 exemples de confrontation, pour vous donner le point de vue de l'utilisateur mais aussi celui de l'administrateur d'applications hébergées par un serveur public ou un intranet.

Wordpress contre Writefreely

#Wordpress logo Wordpressest la plateforme de blog la plus connue au monde et sûrement la plus utilisée. Elle se complète facilement de multiples extensions qui permettent de personnaliser l'interface publique et fournissent une immense variété de fonctionnalités complèmentaires à la plateforme nue.

Mais c'est là que réside le problème : elle incite l'administrateur ou l'utilisateur à installer un nombre élevé d'extensions qui fournissent une qualité graphique et la couverture fonctionnelle que peuvent atteindre le niveau de service de plateformes professionnelles.

En contrepartie, l'ensemble ainsi constitué augmente la charge du serveur, en production mais aussi en mises à jour chaque semaine. De plus, les conflits potentiels entre extensions et l'apprentissage nécessaire de toutes les extensions représente un besoin en ressources et/ou de temps élevé in fine.

Si #Writefreely logo Writefreely semble très limité en comparaison d'une installation Wordpress peaufinée, il apporte les fonctionnalités de base et des compléments très intéressants, comme : * Une interface d'administration simple mais suffisante de la plateforme et de chaque blog * La connectivité ActivityPub qui permet la publication des contenus sur le fédivers

Construit de manière non-modulaire, il ne surcharge pas le serveur en production et ses mises à jour ne se font pas à haute fréquence comme les extensions de Wordpress, en mode mise à jour automatique. Il fournit les stats de charge à l'administrateur, par défaut.

En résumé, les deux plateformes opposent agrément et extensibilité pour Wordpress à connectivité et ouverture par défaut pour Writefreely.

Joplin contre HedgeDoc

Des solutions comparables

Le logo Joplin magasin d'applications de Yunohost mentionne que #Joplin nécessite au moins 4 Go de mémoire vive pour fonctionner (Application Joplin en version 3.2.11~ynh1 dans le magasin Yunohost).

Compte tenu de cette mise en garde, je n'ai pas testé l'installation de Joplin sur mon serveur applicatifs. Joplin est un clone fonctionnel de OneNote.

En revanche,logo HedgeDoc j'ai installé et commencé à utiliser #Hedgedoc sur mon serveur et c'est sur cette application que j'écris ces lignes en langage Markdown avant de le transférer sur mon blog sur Writefreely.

Pratique, il fournit une interface de saisie simple ou à double panneau, l'un pour la saisie à coloration syntaxique et l'autre pour prévisualiser le code, y compris les images.

Il permet de conserver ses brouillons sans les publier, et de passer d'un statut de message publié à brouillon en 1 clic. Les multiples niveaux de permissions autorisent les auteurs à garder leurs textes privés ou bien les ouvrir à contribution.

Compatibilité contre légèreté

Ce que n'offre pas HedgeDoc, c'est la compatibilité avec OneNote de Microsoft. En revanche sa légèreté est ce qui représente aujourd'hui la solution idéale.

Évolution des habitudes des utilisateurs

Les administrateurs (ou décideurs informatiques) choisissent les solutions libres les moins susceptibles de perturber les utilisateurs bureautiques.

La plupart des utilisateurs qui acceptent les logiciels libres le font en cherchant à conserver le niveau de service voire les fonctionnalités des solutions propriétaires d'origine, dans les premiers temps.

Les utilisateurs éprouvent des difficultés tant qu'ils n'ont pas acquis la maîtrisé des solutions libres. Il leur faut prendre conscience que leurs habitudes limitent leur capacité d'évolution.

Après plusieurs mois passés sur les solutions libres, les utilisateurs peuvent accepter de basculer sur des solutions dépassant leurs habitudes et leur formation bureautique initiale. La formation des utilisateurs doit alors faire partie intégrante de la conduite du changement pour dépasser les blocages et retrouver la productivité associée aux habitudes antérieures.

L'évolution est une question de temps, qui doit être accordé aux administrateurs comme aux utilisateurs pour passer de leurs anciens systèmes propriétaires aux logiciels libres et sobres.

Par @eikan@newan.net