Un groupe dynamique de développeurs collabore à la 7ème édition du CloudFest Hackathon 2024, qui se déroulera du 16 au 18 mars 2024 à Europa Park,

CloudFest Hackathon 2024 : the recap

This year, I was lucky to be invited to the CloudFest Hackathon 2024, thanks to Carole Olinger, Alain Schlesser and Lucas Radke.

CloudFest Hackathon

11 projects competed this year and it was pretty hard to choose only one as there were loads of exciting challenges to overcome. We only have 2 full days (and nights) to code for the project we are part of and make history.

The projects were:

  1. Managing Multilingual Content with WP Multisite
  2. Public Sector Website Funding Transparency
  3. JSON Schema Field/Form Renderer
  4. CMS Health Checks
  5. Securing more infrastructure by easing OS upgrades
  6. Integrating MariaDB Catalogs with PHP Platforms
  7. Can everyone use _______?
  8. WordPress Tools for Hosting Providers
  9. Enable Mastodon Apps for WordPress and its Plugins
  10. Inclusive Language Checker for Open-Source Contributors
  11. Hack the Hackathon

I was on the fence for a while as I’m interested in Multilingual and Multisite, Inclusivity, JSON Schema, and MariaDB. Eventually, I took a chair at the JSON Schema table but quickly found it was too crowded already so I joined Integrating MariaDB Catalogs with PHP Platforms.

Integrating MariaDB Catalogs with PHP Platforms

The Team

We were very fortunate to work with Andrew Hutchings (aka Linux Jedi), who works for the MariaDB Foundation. The project this year revolves around the integration of a new feature called MariaDB Catalogs with PHP frameworks such as WordPress, Drupal, and others.

The team was therefore composed of:

The project: MariaDB catalogs

The general idea of catalogs is containerization inside MariaDB itself: you have one MariaDB instance running and every customer has their own catalog inside that instance. The memory is shared so you are saving a lot of RAM that way. You don’t have to have 50,000 different read DB instances running, each using a GB of RAM. You simply have one read DB instance running, but you still have each customer siloed.

The hackathon project is to make it easier to administer this, create and remove catalogs.

Lire CloudFest Hackathon 2024 : the recap

Personne tapant sur une machine à écrire et créant des scénarios orthographiques.

Question d’orthographe : écrit-on des « scénarios » ou des « scénari » ?

Ah, la question éternelle des amateurs de la langue française : « Doit-on écrire « scénarios » ou « scénari » ? » Cet article plonge au cœur de cette interrogation, démêlant les règles de grammaire, les exceptions et les préférences d’usage pour éclairer votre chemin à travers les méandres de l’orthographe française. Préparez-vous à une exploration linguistique !

Un peu d’histoire

Le terme « scénario », emprunté à l’italien « scenario », a fait son entrée dans la langue française au XVIIe siècle. Originellement, il désignait le plan détaillé d’une pièce de théâtre, avant d’élargir son sens aux domaines du cinéma, de la télévision, et même de la planification événementielle. En italien, le pluriel de « scenario » est « scenari », sans accent. Mais alors, comment ce mot voyage-t-il dans le paysage grammatical français ?

La règle de base en français

En français, la formation du pluriel suit généralement une règle simple : on ajoute un « s » au singulier. Donc, logiquement, le pluriel de « scénario » est « scénarios ». Cette règle de base soutient l’usage de « scénarios » dans la majorité des écrits français, des documents officiels aux œuvres littéraires.

L’exception italienne ?

La langue française est connue pour ses exceptions, et certains pourraient se demander si « scénario » en fait partie, du fait de son origine italienne. En effet, pour des mots empruntés à d’autres langues, le français a parfois conservé les formes plurielles originales (comme pour les mots « graffiti/graffitis » ou « spaghetti »). Pourtant, « scénari », bien qu’utilisé par certains sous l’influence de l’italien, n’est pas reconnu comme le pluriel standard en français.

Lire Question d’orthographe : écrit-on des « scénarios » ou des « scénari » ?

Plausible Analytics, une alternative respectueuse de la confidentialité à l'installation de Google Analytics pour Ubuntu Server.

Plausible Analytics au lieu de Google Analytics

Plausible Analytics peut être hébergé sur votre propre serveur avec Community Edition. Pour une nouvelle installation, utilisez le dépôt officiel de cette édition et les instructions de la version retenue. L’ancienne procédure basée sur le dépôt hosting et ses fichiers ne doit pas être appliquée telle quelle.

Préparer le serveur et la sauvegarde

Vérifiez les prérequis de la version : Docker, Docker Compose, architecture du processeur et ressources nécessaires aux services. Prévoyez un domaine, HTTPS, de l’espace pour les statistiques et une politique de sauvegarde.

L’auto-hébergement vous confie aussi les mises à jour, la disponibilité et la restauration. Pour dimensionner la machine, voir le rôle et les limites du swap sur un VPS.

Partir d’une version identifiée de Community Edition

Dans le dépôt officiel Plausible Community Edition, choisissez une version publiée et suivez son README. Téléchargez les fichiers de cette même version : ne mélangez pas le fichier Compose d’une édition avec l’image d’une autre.

Configurez localement BASE_URL et générez une valeur unique pour SECRET_KEY_BASE selon les instructions du projet. Conservez les secrets dans la configuration privée du serveur, avec des accès restreints. Ne publiez ni leur valeur ni le contenu complet des fichiers d’environnement.

Exposition directe ou reverse proxy existant

Le guide officiel propose une exposition HTTP/HTTPS et décrit aussi les adaptations nécessaires derrière un reverse proxy. Choisissez une seule stratégie cohérente : un serveur Nginx déjà en écoute sur les ports publics peut entrer en conflit avec un autre service qui tente de les occuper.

Si Nginx termine HTTPS, vérifiez les ports du service interne, les noms d’hôte et les en-têtes transmis. N’exposez pas les bases de données au public pour permettre l’accès au tableau de bord.

Démarrer et contrôler les services

Après configuration conforme aux fichiers de votre version, lancez les services depuis le dossier du projet :

docker compose up -d
docker compose ps

Examinez les journaux en cas d’échec. Ouvrez ensuite votre instance, créez le compte initial et ajoutez un site. Le code de mesure doit provenir de cette instance : une ancienne URL de script peut ne plus correspondre à votre déploiement.

Vérifier la collecte

  • Ouvrir une page de test portant le script prévu.
  • Vérifier la requête de collecte et sa réponse.
  • Confirmer l’apparition de la visite dans les statistiques.
  • Contrôler les règles de cache, de proxy et les bloqueurs éventuels.
  • Tester les événements dont le site a réellement besoin.

Si vous utilisez SRI, un hash doit correspondre exactement au script servi. Lors d’une mise à jour du script, vérifiez l’intégrité et son chargement plutôt que de conserver un hash obsolète.

Mettre à niveau une installation existante

Avant toute modification, identifiez les versions installées et lisez les notes de migration. Sauvegardez la configuration, PostgreSQL et ClickHouse, puis testez la restauration. Une montée de version peut imposer des étapes intermédiaires.

La sauvegarde doit rester indépendante du serveur. Consultez la stratégie 3-2-1 et surveillez l’espace occupé sur le disque.

Désinstaller sans toucher aux autres applications

Inventoriez les services et volumes appartenant à cette instance avant toute suppression. Ne supprimez pas les répertoires globaux de Docker ou de containerd : ils peuvent contenir les données d’autres applications. Conservez une sauvegarde vérifiée avant de retirer les seules ressources devenues inutiles.

Documentation

Plausible Community Edition : installation et versions ; wiki officiel pour l’exploitation et les mises à niveau.