Créer un site de dev. Pourquoi et comment ?

La tentation est grande pour un développeur web de concevoir une large plateforme web pour répondre au besoin d'un site internet personnel. Ce n'est bien souvent pas pertinent. Je vais vous expliquer mon raisonnement puis détailler l'implémentation de ma solution.

Définir le projet

Les choix initiaux ont une influence importante sur l'évolution d'un projet et le confort de développement. Bien choisir c'est avant tout être honnête concernant son besoin, ses moyens et ses capacités.

‌

Le besoin

La définition des besoins est une étape essentielle à effectuer en amont de tout projet. Dans mon cas, je souhaite un projet web à faire évoluer au fil des mois, voire des années, afin d'exercer mon métier sans les contraintes professionnelles (commandes, délais...). Je souhaite en sus un canal de communication personnel vers la communauté de développeurs afin d'exposer durablement mes réalisations et mes idées.

Établir le besoin c'est aussi identifier certains non-besoins.

Il est également bénéfique de savoir nommer les pièges prévisibles afin d'y placer un drapeau rouge. Mon intention pour ce projet exclut l'identification des utilisateurs. Je ne perdrai donc pas de temps sur les problématiques d'authentification et de RGPD.

La cible

Cette étape est bien souvent mal définie ou trop exhaustive. Quand bien même plusieurs cibles sont pertinentes au regard de l'objectif, il est primordial de les pondérer et définir leurs champs d'application.

Ce sujet fera sûrement l'objet d'une future publication sur ce blog.

En attendant, ma réponse à cette question est simple : je réalise ce projet à 70% pour moi-même et à 30% dans l'espoir d'intéresser les visiteurs. Le site étant un canal d'expression personnelle, il n'est pas surprenant que la cible soit égocentrée.

‌
‌

Le contenu

La partie blog du site évoquera des sujets allant du design au code en passant par des considérations marketing. Je souhaite couvrir la globalité du front-end web.

En complément le site lui-même sera un espace d'expérimentation UI/UX, de démonstration de code et de partage de ressources techniques.

Les langages

Il y a un temps pour l'apprentissage et un temps pour la réalisation. Il est ainsi préférable de s'appuyer sur nos compétences réelles et présentes en phase de production.

L'objectif principal d'un projet est d'être mené à terme.

Je suis spécialiste du front en JavaScript et je travaille presque exclusivement avec React depuis deux ans. Je privilégie donc ce que je maîtrise afin d'utiliser mon temps à la qualité davantage qu'à la résolution de problèmes.

L'investissement

Ce site n'est pas ma source directe de revenus. L'investissement que j'y consacrerai sera essentiellement temporel et pourra s'avérer fluctuant. Cela induit une incompatibilité avec les offres commerciales d'hébergement car on oublie aisément de renouveler les contrats en cas de désintérêt passager.

Je favorise ainsi les solutions pérennes et gratuites à petites échelles. Il sera toujours possible de migrer le site dans le future si nécessaire.

Google, Amazon, Heroku et Github proposent des services appropriés à mon besoin de flexibilité.

Les choix

En raison de sa proximité avec mon workflow quotidien j'ai choisi d'héberger le site sur Github en utilisant les services Github Pages et Github Actions pour automatiser la mise en production.

Les informations du site n'ont pas besoin d'être personnalisées en fonction de l'utilisateur et ne nécessitent donc pas d'échanges avec le serveur après la requête initiale. Cela réduit l'intérêt de la technologie Server Side Rendering (SSR) et dirige le choix vers la simplicité d'usage du Client Side Rendering (CSR). Par chance il existe une solution intermédiaire que l'on peut qualifier de Static Server Side Rendering (SSSR ?).

Une version du site est générée au build-time avec les informations statiques (structure HTML, styles, textes, liens...). Ces pages peuvent charger du JavaScript qui s'exécutera au run-time afin d'hydrater le contenu. J'utilise pour cela sur le framework GatsbyJs qui s'appuie sur Webpack, GraphQL et ReactJs. Il supporte aussi nativement TypeScript.

Ce framework permet de développer sans complexité un site en React et un blog basé sur la syntaxe Markdown. Il serait également possible d'intégrer un CMS dans le flux de data de GatsbyJs mais j'estime que cela rajouterait une complexité inutile. Un développeur aime être au plus près de son code.

Maintenant que le projet est défini, place au développement.
Rendez-vous au prochain article !