J'ai décidé de commencer une série de billets pour expliquer comment j'ai réalisé ce site.
Je vais définir mes besoins, mes attentes et tenter de justifier les choix technologiques.

Les besoins

Ce site s'articule autour de quelques besoins classiques et est semblable à un site vitrine :

• Pas plus d'une dizaine de pages.
• Chaque page à son propre style/structuration.
• Une partie Blog où j'écris des billets comme celui-ci.
• Un rendu adaptatif.

J'ai prévu d'écrire directement en HTML tous mes contenus sans passer par un éditeur wysiywg, je ne me sens jamais vraiment confort avec ce genre d'outils qui ne produit pas toujours du super code.
Je ne souhaite pas non plus utiliser de base de données pour sauvegarder les contenus, mais de me baser sur des fichiers et sur un système de gestion de version pour enregistrer et historiser mes contenus.
Cela veux dire que chaque correction ou ajout de contenus revient à modifier un fichier.

Bien entendu pour rendre tout ça fluide et simple, je pense mettre un place un processus de déploiement continu, ce qui peut paraître lourd, mais peut aller vite bien outillé.

Ensuite, je réfléchis à ce dont j'ai besoin pour développer et maintenir le tout :

• Un système de gestion de version pour le projet.
• Un système de templating pour gérer mes pages et structurer le projet.
• Une mécanique de routing pour gérer élégamment les URLs et le chargement des pages.
• Un Toolkit CSS pour gérer le responsive.
• Un système de deploiement pour mettre en production.

Le choix des technos

Côté rendu

Je vais partir sur un classique Bootstrap comme Toolkit CSS pour gérer la partie adaptative et me fournir des classes pour la disposition flex qui sont très pratiques. J'ai voulu tenter la version 5 qui est sans dépendance à JQuery, mais le projet est clairement trop jeune à l'heure ou j'écris ces mots.

Du coup, je dois charger une dépendance à JQuery pour bénéficier des comportements Javascript de Bootstrap, j'utilise toutefois la version Slim qui est un peu plus light et qui semble suffisante.
J'ai également déjà en tête de faire un bandeau animé basé sur un document SVG animé par du CSS et la librarie Javascript d3.js mais sans JQuery.

Côté serveur

J'ai comme première impression que je vais devoir me servir d'un Framework, mais ce qui m'embête est de sortir l'artillerie lourde pour un petit projet, surtout que je n'ai ni besoin d'utiliser de base de données, ni la plupart des composants. J'ai toutefois besoin d'un système de templating et d'une mécanique de routing.

Après quelques tests et lectures sur le Web, mon choix s'est porté sur Plates PHP développé par la célèbre team thephpleague. C'est un micro Framework PHP qui propose des fonctionnalités intéressantes :

• Système de templating en PHP natif : pas besoin de passer par un language intermédiaire pour la production de ses vues, c'est du PHP (HTML) natif.
• Réutilisation d'éléments graphiques : concept de page, layout, "element" et partages de données entre composants.
• Modules et Helper : possibilité d'augmenter les fonctionnalités de base.
• Philosophie Agnostique : pas d'architecture "type" pour l'organisation du projet, ni de système de route/dispatching.

Justement, c'est ce dernier point qui est un peu déroutant, le micro-Framework est extrêmement ouvert, il n'y a pas de base de "controller" branché sur un système de route. Il est possible de l'implémenter, mais ne fait pas vraiment partie de mon objectif de refaire ce qu'un autre framework fait déjà. En effet, la mécanique principale se résume à simplement charger des fichiers de vues PHP à partir d'URL attendues.

Sans trop rentrer dans les détails technique car cela fera partie d'un prochain billet, voici le fonctionnement classique que j'imagine pour gérer une requête type :

• Initialisation de Plates : on déclare à Plates de la structure du projet (assets, vues, layout...).
• Analyse de la requête : on détermine une route à partir des paramètres de l'URL (accueil, services, réalisation, 404...).
• Chargement du fichier PHP : on charge la page qui correspond à la route reconnue.
• Rendu de la vue : on mixe le layout, la vue et on retourne l'ensemble.

Comme j'ai envie d'avoir une section Billets avec des sous-pages sur le site, il faut que je prenne en compte dès la conception cette caractéristique à la fois au niveau du système de routing et du choix de la structuration des fichiers.

Gestion de version, déploiement et hébergement.

J'ai comme à mon habitude décidé d'utiliser Git et d'héberger le dépôt sur mon Gitlab. J'utilise Docker en local pour le développement mais l'hébergement est quant à lui plus classique et se trouve sur un serveur Debian avec de vrais services non conteneurisés (apache, vhosts, php-fpm).

Ma stratégie de déploiement est basée sur l'outil Deployer qui à l'aide de recettes s'occupe de toutes les phases d'une mise en déploiement. Cela se résume principalement à :

• Récupérer le code
• Installer les dépendances (via composer)
• Lier les ressources statiques et dynamiques
• Basculer la version fraichement installée en production

J'en parlerai là aussi dans un autre billet spécifique.

Et le contenu dans tout ça!

Au final, je n'ai pas abordé le côté éditorial des pages, ce qui n'est pas le but de ce billet. Cependant, c'était clairement l'objectif principal du site, à savoir : décrire mon activité et mes services. Le choix des mots et la cohérence du discours ont donc été le travail le plus difficle pour moi. Toutefois, lier tout cela au développement d'un mini-système a rendu cette création bien plus sympathique.