Ce référentiel contient à la fois le générateur de site statique et le contenu de https://qubyte.codes.
Le générateur est principalement contenu dans index.js. La majeure partie du travail est effectuée par un système de création de graphiques personnalisé et marqué, qui prend les fichiers de démarque et les traite en contenu HTML. Ce n’est cependant pas parfait et quelques correctifs de singe étaient nécessaires. Le module lib/render.js effectue ce correctif et ajoute la coloration syntaxique et le formatage des formules mathématiques.
serve.js est un serveur de développement. Lorsque les fichiers changent, des parties du graphique de construction sont réexécutées pour obtenir une sortie mise à jour.
Les fichiers sources sont contenus dans les répertoires src et content. Lors de la construction, un répertoire public est créé et certains de ces fichiers sources sont copiés (ceux qui ne nécessitent aucune compilation, comme le service worker). D'autres fichiers doivent être générés et sont placés dans le répertoire public au fur et à mesure de leur création.
netlify.toml est une configuration pour Netlify, qui héberge mon blog (je le recommande vivement). Au moment de la rédaction, ce fichier contient uniquement la configuration des en-têtes. Ceux-ci sont optimisés pour la sécurité et pour la mise en cache CSS du navigateur. À l'origine, j'hébergais ce blog sur un droplet DigitalOcean utilisant NGINX. Une configuration pour cela fait toujours partie de ce dépôt, nginx.conf.
J'utilise postcss pour compiler CSS. En principe, le CSS peut être utilisé sans lui. La plupart du temps, postcss est utilisé pour concaténer et réduire le CSS. Le CSS de sortie est haché et le hachage devient partie intégrante du nom du fichier CSS. Il s'agit de supprimer le cache, car CSS dispose d'une durée de cache longue ou indéfinie pour éviter qu'il ne bloque le chargement de la page après son chargement une fois.
À l'exception de la coloration syntaxique, ce site évite largement d'utiliser des classes HTML comme points d'ancrage pour CSS, affirmant plutôt que le balisage sémantique fournit un contexte suffisant auquel CSS peut s'en tenir.
Le blog est une application Web progressive (PWA) et comporte des icônes de différentes tailles en conséquence. L’un d’eux est également le favicon.
Ce répertoire contient les sources de démarques des articles publiés. Chaque article comporte un préambule JSON contenant diverses métadonnées :
nom | description |
---|---|
dateheure | L'horodatage de publication de la publication. Si cela se produit dans le futur, le message ne sera pas rendu. |
titre | Le titre du message. |
description | La description du poste. Ceci est ajouté à l’en-tête HTML en tant que méta-description et méta-description Twitter. Ce dernier est utilisé par Twitter pour remplir les cartes Twitter. |
brouillon | Si c'est vrai, le message ne sera pas affiché. |
balises | Une liste de balises. Ceux-ci sont affichés en haut de chaque entrée et sont également utilisés lors du partage sur Twitter et Mastodon via les liens en bas de chaque publication. |
mentions Web | Une liste de mentions Web provenant d'autres blogs. |
scripts | Une liste d'objets avec un champ href . Ceux-ci seront ajoutés sous forme de scripts de type module en tête du message. |
J'utilise des modèles de guidon pour restituer le contenu en pages. Certains d'entre eux contiennent des pages et d'autres sont des composants communs de pages. Ils sont plutôt old school, mais font du bon travail.
Le service worker et le manifeste sont des fichiers qui permettent à ce blog de se comporter comme une PWA. Pour la plupart, cela fournit une mise en cache personnalisée. Cela permet également d'"installer" ce blog sur Android (même si cette fonctionnalité ne m'intéresse pas vraiment).