Commencer à bloguer : un guide essentiel pour les développeurs

Alors, vous êtes un développeur qui cherche à créer un blog ? Dans ce guide, je vais vous guider dans la gestion de votre propre site de blog, des noms de domaine et de la création de sites au référencement et à la syndication.

Table des matières

• Section 0 (facultative) - Commencez à écrire sur les plateformes de blogs
  • Dev.to
  • Hashnode
  • HackerMidi
• Section 1 - Acheter un domaine
  • Quel nom de domaine choisir ?
  • Où acheter un nom de domaine ?
  • Frais de domaine
• Section 2 - Créer un site simple à l'aide d'un générateur de site statique
  • Qu'est-ce qu'un générateur de site statique ?
  • Pourquoi utiliser un SSG ?
  • Créer un site de base avec Hugo
• Section 3 - Faites héberger votre blog
• Section 4 - Analytique
• Section 5 - Référencement de base
  • Faire savoir à Google que vous existez
  • Vérification des problèmes
  • Canonisation et URL canoniques
  • Dépôt GitHub privé
  • Backlinks et autorité de domaine
• Section 6 - Partage de votre travail
  • Utiliser Reddit
  • Publier sur des subreddits spécifiques
  • Vérifiez les règles pour chaque subreddit
  • Faites partie de la communauté
• Section 7 - Republier sur les plateformes de blogs
  • Canonisation pour les articles republiés
    • Canoniques pour dev.to
    • Canoniques sur Hashnode
    • Canonisation sur HackerNoon
    • Vous ne pouvez pas canoniser sur FreeCodeCamp !
  • Publicité faite pour vous
  • Inconvénients de la republication
• annexe
  • Pourquoi bloguer ?
    • Améliore vos compétences en écriture et en communication
    • Vous donne un moyen de prouver que vous savez de quoi vous parlez
    • Vous aide à vous commercialiser et à créer des opportunités
  • Une comparaison rapide des SSG
    • Jekyll
    • soixante-dix
    • Gatsby
    • Hugo

Section 0 (Facultatif) - Commencez à écrire sur les plateformes de blogs

Si vous voulez vous échauffer un peu avant de vous lancer dans la création de votre propre site, la chose la plus simple et la plus simple à faire est simplement de commencer à écrire et de contribuer votre travail aux plateformes de blogs existantes.

En fin de compte, la chose la plus difficile à propos des blogs est l'écriture proprement dite - du moins, c'est généralement le cas pour nous, les développeurs ! Donc, cela ne fait pas de mal de se faire une idée d'abord pour voir si vous l'appréciez. De plus, comme nous le verrons plus tard, ceux-ci sont toujours utiles à utiliser même si/lorsque vous créez votre propre site de blog séparé.

Dev.to

Vous avez probablement déjà entendu parler de dev.to - c'est toujours la plus grande plateforme de blogs de développeurs, et c'est là que je vous recommande de commencer. Vous pouvez facilement commencer à écrire à l'aide de leur simple éditeur de démarquage, et il a un large lectorat, vous aurez donc immédiatement un bon nombre d'yeux sur votre travail.

Il dispose d'excellentes analyses intégrées, qui peuvent vous aider à voir combien de personnes lisent vos publications, et même comment elles les ont trouvées - par exemple, Reddit ou Twitter. Cela vous aide à voir ce qui fonctionne le mieux lorsque vous partagez votre travail.

Sa conception contient de nombreux éléments de style de médias sociaux, avec des goûts et des réactions aux publications, ainsi que des fils de discussion de type babillard. (Cela pourrait être un avantage ou un inconvénient, selon vos goûts.)

En cas de doute, commencez ici !

Hashnode

Hashnode est un site de blog de développement plus récent. À mon avis, il a une sensation beaucoup plus professionnelle que dev.to. Il se sent beaucoup plus orienté blog que dev.to et moins comme un site de médias sociaux ; il vous donne un sous-domaine de blog distinct, donnant à votre blog un peu de sa propre identité distincte au sein du site.

Si vous le souhaitez, vous pouvez même le connecter à votre propre nom de domaine privé si vous le souhaitez.

Malheureusement, il est beaucoup moins populaire que dev.to et, d'après mon expérience, je n'obtiens pratiquement aucun trafic. Si vous aimez son style plus épuré, cela pourrait valoir le coup d'œil, mais attendez-vous à faire plus de démarches pour que vos messages soient remarqués.

HackerMidi

HackerNoon est très différent de dev.to & Hashnode en ce sens que tout article que vous y soumettez doit passer par un éditeur humain qui travaille avec vous pour s'assurer que votre article est à son meilleur avant sa publication. Cependant, ils peuvent choisir de ne pas publier votre article du tout.

Cela a ses compromis; d'une part, c'est une excellente expérience d'apprentissage, mais d'autre part, cela limite votre liberté de simplement publier quand et ce que vous voulez. Par conséquent, je recommanderais de soumettre votre travail à HackerNoon pour l'expérience d'apprentissage qu'il vous procurera, mais envisagez de conserver la résidence principale de votre blog ailleurs.

Section 1 - Acheter un domaine

Malheureusement, la création de votre propre blog implique l'une des tâches les plus redoutées des développeurs : nommer les choses ! Bien que ce ne soit pas très difficile d'un point de vue purement technique, cela vaut la peine d'y réfléchir et d'y réfléchir dès le départ ; réfléchissez-y pendant la configuration de votre site.

Quel nom de domaine choisir ?

Il y a deux choix principaux ici :

1. Donnez votre nom à votre blog

2. Donnez à votre blog sa propre identité avec un nom distinct

   
   

J'ai rencontré des opinions différentes sur chacun; pour mon propre blog, je l'ai simplement nommé d'après moi. Ma pensée est que si vous utilisez un blog pour vous aider à faire connaître votre nom, pourquoi ne pas utiliser votre nom dans votre blog ?

Quoi que vous choisissiez, rappelez-vous que votre domaine est un peu pénible à changer, il vaut donc la peine de prendre le temps d'en trouver un avec lequel vous êtes à l'aise. Cependant, vous devrez peut-être repenser ou adapter votre domaine si celui que vous souhaitez est déjà pris, alors vérifiez s'il est disponible avant de vous y mettre à fond.

Où acheter un nom de domaine ?

Vous avez probablement déjà entendu parler de nombreux registraires de domaine, tels que BlueHost , Hostinger , GoDaddy et Namecheap .

Cependant, un élément clé à vérifier est Google Domains , car c'est le seul registraire qui vend des domaines .dev . Mon conseil est que .com est toujours le meilleur si vous pouvez en obtenir un, donc s'il y en a un que vous aimez, alors allez-y, mais sinon, alors .dev pourrait être une excellente alternative.

Coûts de domaine

Notez que les domaines coûtent des montants variables, et de plus, vous devez payer chaque année pour les conserver. Les domaines peuvent être aussi bon marché que 10 $ par an, donc à moins que vous n'achetiez un domaine à des fins commerciales, réfléchissez bien avant d'en acheter un coûteux.

Section 2 - Créer un site simple à l'aide d'un générateur de site statique

Qu'est-ce qu'un générateur de site statique ?

Un générateur de site statique - ou SSG - modèlera et générera le contenu d'un site Web de sorte qu'il puisse être servi sous forme de fichiers statiques conservés sur un serveur Web.

Après avoir configuré la structure principale du site - comme votre page d'accueil, l'index des publications, la page "à propos", etc. - vous pouvez générer des pages complètes simplement en ajoutant des fichiers de démarquage.

Pourquoi utiliser un SSG ?

En bref, les SSG

• vous donner des sites rapides

• vous permettent de publier à l'aide d'un flux de travail GitOps

• sont sécurisés (pas de base de données à pirater !)

• vous permettent de tirer parti de vos compétences techniques, plutôt que d'être limité à ce que les plates-formes peuvent fournir

  
  

En tant que développeurs, nous utilisons presque tous les jours quelque chose qui fait quelque chose de très similaire : GitHub. Dans nos référentiels de code, nous écrirons des fichiers readme et d'autres documents dans Markdown, et GitHub le formatera joliment pour l'afficher sur une page Web.

Un SSG peut vous permettre de suivre à peu près le même flux de travail GitOps pour votre propre blog. Quand j'ai commencé à écrire sur dev.to, je gérais mes brouillons dans un dépôt Git. C'était bien jusqu'à ce que je veuille publier, à quel point j'avais besoin de transférer le contenu dans leur éditeur Web.

C'était bien, mais quand j'ai découvert que les SSG pouvaient vous permettre d'utiliser le même flux de travail que pour mettre à jour un fichier readme dans GitHub, cela m'a suffi pour vouloir en savoir plus.

Une façon courante de créer un blog consiste à utiliser quelque chose comme WordPress ; cela a bien sûr de nombreux avantages, mais il stocke tout votre contenu dans une base de données. Un site généré statiquement n'en a pas besoin, ce qui signifie d'une part qu'il sera beaucoup plus rapide.

Bien sûr, la vitesse n'est pas tout, mais Google se soucie de la vitesse de chargement de votre site , alors pourquoi ne pas profiter de la vitesse qu'un site généré par SSG peut vous offrir ?

Créer un site de base avec Hugo

Pour créer un site statique, je recommande Hugo . En bref, c'est parce qu'il est populaire, bien pris en charge, rapide et vous permet d'être rapidement opérationnel avec des modèles prédéfinis.

(Pour plus de détails sur les SSG alternatifs, consultez la section Comparaison des SSG dans l'annexe.)

La page de démarrage rapide de la documentation officielle d'Hugo donne une excellente description de la configuration d'un site Hugo de base. Suivez les étapes fournies, mais lorsque vous atteignez ses commandes "créer un site" , je vous recommande de les remplacer par les suivantes :

 hugo new site quickstart cd quickstart git init echo "/public/" >> .gitignore echo "/resources/_gen/" >> .gitignore echo ".hugo_build.lock" >> .gitignore git clone https://github.com/leafee98/hugo-theme-flat themes/flat rm -rf themes/flat/.git/ themes/flat/.github/ echo "theme = flat" >> hugo.toml hugo server

Cela présente les différences suivantes par rapport au guide officiel :

• Configure un fichier .gitignore

• Utilise l'excellent thème 'Flat' au lieu du thème Ananke

• Configure le thème en tant que code dans votre propre dépôt plutôt qu'en tant que sous-module git ; cela rend beaucoup plus facile d'ajuster le thème à votre goût plus tard.

Lors de la création de votre référentiel GitHub, rendez-le privé - c'est pour des raisons de référencement, que nous explorerons plus tard.

Une fois que vous aurez suivi le guide, vous aurez alors un site prêt à héberger ! À ce stade, il y aura très probablement des aspects du site que vous voudrez modifier. Cependant, vous n'avez pas besoin de laisser cela vous empêcher d'être hébergé.

La principale chose que vous voulez éviter de changer plus tard, ce sont vos URL ; tout le reste peut être changé plus tard.

Section 3 - Hébergez votre blog

Comme le décrit la section Hébergement et déploiement de la documentation Hugo, puisque vous avez un site statique, il peut être hébergé pratiquement n'importe où, et presque certainement gratuitement aussi.

Bien sûr, il existe également de nombreux hébergeurs gratuits/bon marché pour les sites basés sur WordPress, mais tout hébergeur particulier ne vous donnera qu'une quantité de bande passante ; en général, un site statique vous donne plus de bande passante pour votre argent, même si vous n'avez pas réellement remis d'argent.

Le guide d'hébergement d'Hugo répertorie de nombreuses possibilités, mais personnellement, je suis d'accord avec la recommandation de Bryce Wray d'utiliser CloudFlare Pages ; son niveau gratuit est probablement le plus rapide du marché et il est facile à utiliser.

Suivez simplement leur guide à partir de la "configuration d'un référentiel GitHub" . A ce stade, votre site sera en ligne ! Mais vous aurez un domaine moche comme my-blog-xyz.pages.dev . Suivez simplement le guide de CloudFlare sur la configuration d'un domaine personnalisé pour mettre votre site en ligne sur le domaine que vous avez acheté précédemment.

Section 4 - Analytique

Vanité des vanités, tout est vanité !

- Ecclésiaste 1: 2

Maintenant, à proprement parler, il s'agit d'une étape facultative, mais à ce stade, cela vaut la peine de configurer des analyses pour votre site. Je suis peut-être juste vain, mais pour moi, une grande partie du plaisir de bloguer est de pouvoir voir que les gens voient réellement et se soucient de ce que vous avez écrit.

L'une des limites de la configuration d'un site statique est que vous ne pouvez pas héberger vous-même des analyses, car cela nécessiterait une sorte de base de données. Mais ce n'est pas trop un problème de toute façon car il existe de nombreux bons fournisseurs d'analyses tiers disponibles.

Le plus important dont vous aurez probablement entendu parler est Google Analytics.

La mise en place d'analyses avec un fournisseur tiers implique généralement

1. Créer un compte

   
   

2. Ajout d'un extrait ou d'un lien javascript à vos pages.

Dans le modèle Hugo que j'ai recommandé, vous ajouteriez simplement quelque chose comme ce qui suit à votre fichier de modèle head.html :

 {{/* Include analytics, but only in production */}} {{- if hugo.IsProduction | or (eq site.Params.env "production") }} <script defer data-domain="yourdomain.com" src="/link/to/script.js"></script> {{- end }}

Si vous souhaitez configurer GA pour votre site, suivez les documents officiels de Google .

Le fournisseur d'analyse avec lequel je suis allé est Plausible . Malheureusement, ce n'est pas gratuit - environ 9 $ par mois - mais c'est facile à utiliser, léger (le script fait moins de 1 Ko) et respecte la vie privée, donc ça vaut le coup d'œil IMO.

Section 5 - Référencement de base

Si vous le construisez, ils viendront

— Champ des Rêves

Il y a du vrai dans la citation ci-dessus; il n'y a pas grand-chose à faire pour que votre blog soit sur Google, et heureusement , l'époque des manigances bourrées de mots-clés est révolue ; ce qui compte en fin de compte, c'est d'écrire un bon contenu , ce qui est une bonne nouvelle pour les blogueurs indépendants comme nous.

Cela dit, vous pouvez faire certaines choses pour vous assurer que votre site est à jour pour les moteurs de recherche.

Faire savoir à Google que vous existez

Les robots d'exploration de Google finiront par trouver votre site, mais cela aide certainement à donner à Google une longueur d'avance et à configurer votre site sur la console de recherche Google . Vous souhaiterez effectuer les opérations suivantes :

• S'inscrire

• Enregistrez votre adresse de domaine (cela sera grandement simplifié si vous avez acheté votre domaine auprès de Google Domains)

• Soumettez l'URL du sitemap.xml de votre site dans l'onglet sitemap. Heureusement, Hugo vous en aura généré un sur https://yourdomain.com/sitemap.xml .

Une fois cela fait, Google commencera (à un moment donné, dans les prochains jours) une exploration de votre site Web. Notez cependant qu'il y a un peu de décalage de quelques jours dans la console de recherche.

Le moyen le plus fiable de voir ce qui est indexé sur votre site est de google en utilisant un site: requête, par exemple, site:yourdomain.dom .

Un autre avantage utile de la configuration sur la console de recherche est que, sous l'onglet "Pages", vous pouvez voir tous les problèmes signalés expliquant pourquoi Google ne peut pas ou ne veut pas indexer vos pages.

Vérification des problèmes

Hugo et le modèle que nous utilisons devraient couvrir la plupart des bases de bonnes pratiques de référencement. Mais cela ne fait pas de mal de vérifier votre site sur l'outil PageSpeed Insights de Google . (Cela deviendra plus important si/quand vous commencerez à rendre votre site plus à votre goût en modifiant les fichiers modèles.)

Cela vous donnera un bon aperçu des performances, de l'accessibilité et de tout problème de référencement (tel que des balises méta manquantes) pour la page.

Canonisation et URL canoniques

Un concept SEO qui est essentiel pour comprendre en tant que blogueur est la canonisation et les URL canoniques . Fondamentalement, l'idée est que le même contenu peut être accessible via différentes URL, mais vous ne voulez pas que Google divise le classement de la page pour une seule page sur plusieurs URL.

Par conséquent, vous pouvez demander à une page de déclarer quelle URL les moteurs de recherche doivent considérer comme étant l' URL de la page.

N'oubliez pas que CloudFlare génère également un domaine « laid » comme my-blog-xyz.pages.dev à côté de votre domaine personnalisé. La plupart (sinon tous) des fournisseurs d'hébergement ne vous permettent pas de désactiver ce domaine de base, mais tant que vous avez des URL canoniques configurées sur vos pages, cela ne posera pas de problème - Google ne listera que sous votre domaine personnalisé, pas le "moche".

L'une des raisons pour lesquelles je recommande le thème Flat pour Hugo est que (contrairement au défaut recommandé d'Ananke) il inclut déjà un lien canonique. Cependant, si vous souhaitez utiliser un thème différent, vous pouvez l'ajouter simplement à votre modèle d'en-tête comme suit :

 <link rel="canonical" href="{{ .Permalink }}" />

Vous pouvez vérifier que cela est correctement configuré pour une page donnée en le vérifiant dans l'outil PageSpeed Insights mentionné ci-dessus. vous verrez si une page a une URL canonique en tant qu'élément de la liste de contrôle dans la section "SEO".

Nous explorerons plus en détail la canonisation dans la section sur la republication , plus loin ci-dessous.

Dépôt GitHub privé

Vous vous souviendrez plus tôt que vous avez rendu votre référentiel GitHub privé. C'est parce que (au moment de la rédaction) vous ne pouvez pas ajouter d'URL canoniques ou de balises noindex aux documents de démarquage, et cela constitue donc un autre problème subtil de duplication de code. Un dépôt privé contourne ce problème.

Backlinks et autorité de domaine

Vous avez probablement entendu dire que l'un des facteurs du classement d'un site par Google est le nombre d'autres sites qui y renvoient ; c'est ce qu'on appelle l'autorité de domaine , et de tels liens d'un site à un autre dans ce contexte sont appelés backlinks .

Je ne vais pas parler de la façon de « farmer » des backlinks pour que votre blog soit mieux classé sur Google ; d'une part, Google est devenu sage face à de tels stratagèmes, et d'autre part, l'un des avantages de la création de votre propre site est que vous pouvez aider à faire du Web un meilleur endroit plutôt que de le remplir davantage avec de tels crétins.

Le principal point à retenir est simplement qu'il vous faudra du temps avant de pouvoir bien vous classer sur Google ; vous n'aurez pas beaucoup d'autorité de domaine pour commencer, mais cela augmentera avec le temps. Comme toujours, vous devez simplement vous concentrer sur la rédaction des meilleurs messages possibles.

Section 6 - Partage de votre travail

La publicité n'est mauvaise que lorsqu'elle annonce des choses mauvaises.

—David Ogilvy

Même si j'aimerais dire que Google peut trouver votre blog est suffisant, de manière réaliste, cela aide vraiment à faire un peu d'auto-publicité et à partager vos publications en ligne.

Utiliser Reddit

La meilleure façon de le faire est de publier des liens vers vos articles sur Reddit. Publier sur les réseaux sociaux ne fait pas de mal, mais le principal avantage de Reddit est que son système de vote signifie que les bons messages (comme je suis sûr que le vôtre le sera) peuvent rester sur les premières pages d'un sous-reddit pendant un certain temps, plutôt que d'être immédiatement balayés. le long de la chronologie.

Publier sur des sous-titres spécifiques

Publiez sur un subreddit spécifique tel que le langage de programmation ou la technologie sur laquelle vous écrivez. Plus le subreddit est grand, plus les gens verront potentiellement votre message, mais le hic, c'est que les gros subreddits comme /r/programming peuvent souvent avoir beaucoup de gens qui votent tactiquement contre les bons messages simplement pour les enterrer, afin d'aider à garder leurs propres messages sur haut.

Au lieu de cela, vous aurez plus de chance en vous en tenant aux Reddits les plus spécifiques qui s'appliquent à votre message ; ces communautés sont plus susceptibles de se soucier et de lire votre message, et elles sont plus réceptives à l'auto-publicité.

Vérifiez les règles pour chaque sous-reddit

Si vous n'êtes pas familier avec un sous-reddit, vérifiez toujours ses règles communautaires avant de publier . Chaque subreddit aura des règles différentes, en particulier des tolérances différentes pour les liens vers vos propres articles.

Cela peut varier entre des interdictions totales de l'auto-publicité, une attente que vous ne publiez pas trop ou aucune restriction.

Une autre règle clé à surveiller est les sujets de publication indésirables avec éventuellement une redirection vers un subreddit plus approprié à la place. Par exemple, les règles de /r/programming vous demandent de rediriger les questions techniques vers r/learnprogramming à la place, et de même les offres d'emploi vers /r/forhire .

Faites partie de la communauté

Quelles que soient les règles du subreddit auquel vous soumettez, c'est toujours une bonne idée de faire partie de la communauté plutôt que d'utiliser Reddit uniquement comme un outil à vos propres fins. Publiez des liens d'autres blogs que vous aimez, engagez des discussions et amusez-vous.

Lisez la « Reddiquette » de temps en temps pour vérifier que vous participez de manière responsable.

Section 7 - Republier sur les plateformes de blogs

Aussi gratifiant qu'il soit d'avoir son propre blog séparé, il est toujours utile de republier des articles sur des plateformes de blogs de développement telles que dev.to. Vous vous demandez peut-être pourquoi nous reviendrions en boucle après avoir pris le temps de créer votre propre blog.

En fin de compte, tout ce qui compte, c'est que vos pensées soient lues et appréciées par d'autres développeurs, et la republication vous aide à le faire simplement en ajoutant une autre façon pour les gens de découvrir votre travail.

Un autre avantage clé est qu'il vous aide à créer une autorité de domaine pour votre propre blog via des backlinks - mais pour que votre site soit crédité de ces backlinks, vous devez republier de la bonne manière.

Canonisation pour les articles republiés

Vous souvenez-vous du concept d'URL canoniques dont nous avons parlé plus tôt ? Lorsque vous republiez vos articles ailleurs, idéalement, vous ne souhaitez publier que sur des sites qui vous permettent d'indiquer que la version canonique de votre article est celle de votre blog.

De cette façon, vous bénéficiez des avantages d'exposition de la republication, mais tous les backlinks qui en résultent constituent l'autorité de domaine de votre propre blog.

Canoniques pour dev.to

Comme détaillé dans le guide de l'éditeur de dev.to , vous pouvez ajouter une URL canonique simplement en ajoutant une propriété canonical_url aux propriétés "avant-propos" d'un article.

Canoniques sur Hashnode

Vous pouvez définir une URL canonique sur un article Hashnode sous la rubrique "Êtes-vous en train de republier ?" section sur la vue "Paramètres de l'article" pour un article. (Voir leurs docs pour plus de détails.)

Canonisation sur HackerNoon

Comme indiqué dans la documentation de HackerNoon , vous pouvez définir une URL canonique dans le "First Seen At" dans les paramètres de votre message.

Vous ne pouvez pas canoniser sur FreeCodeCamp !

Comme indiqué par cet article Hashnode , réfléchissez-y à deux fois avant de republier votre travail sur FreeCodeCamp car ils ne vous permettent pas de définir une URL canonique. En effet, cet article dev.to détaille l'impact négatif que cela a eu sur certains blogueurs à cause de cela.

Publicité faite pour vous

Un autre avantage de la republication est qu'une partie du travail préparatoire pour partager votre travail sur Reddit et d'autres médias sociaux sera souvent effectuée pour vous.

Les robots et les blogueurs qui organisent des articles pour des communautés particulières trouveront souvent votre travail via des balises particulières sur les plateformes de blogs et le partageront sur les réseaux sociaux.

Inconvénients de la republication

Cependant, la republication n'est pas sans coût :

• Republier sur ces sites peut demander un peu de travail, en particulier contrairement au flux GitOps agréable lors de la publication sur votre propre site. (Certaines solutions automatisées et semi-automatisées sont cependant disponibles pour aider les choses ici.)

• Il est possible que le travail republié devance vos originaux sur les moteurs de recherche. Idéalement, les URL canoniques signifieront que le travail republié n'est pas du tout indexé, mais ce n'est pas garanti (en particulier pour Bing, d'après mon expérience)

Par conséquent, cela vaut la peine d'envisager de republier quelque temps après avoir publié l'original (disons, une ou deux semaines, mais c'est à vous de décider). Cela a les avantages suivants :

• Réduction de la duplication du travail en effectuant des corrections et des ajouts dans votre original et vos republications ; inévitablement, malgré vos efforts de relecture, vous ou vos lecteurs repérerez des problèmes ou des choses que vous avez manquées - mieux vaut le faire pendant que l'article n'existe que sur votre propre blog.

• Les moteurs de recherche ont le temps d'indexer votre site en premier.

annexe

Pourquoi Bloguer ?

Améliore vos compétences en écriture et en communication

Bien que, heureusement, Agile signifie que le développement de logiciels implique rarement la production de rames et de rames de documents comme il a pu le faire dans les époques précédentes, je pense que le pendule a basculé un peu trop loin dans l'autre sens, et donc une bonne documentation qui aide à initier les nouveaux arrivants à un système ou un dépôt est malheureusement négligé.

Et au fur et à mesure que vous progresserez dans votre carrière de développeur, vous aurez de plus en plus besoin de distiller votre réflexion et d'expliquer des concepts et des systèmes complexes de manière claire et concise.

Les blogs vous offrent un excellent moyen de mettre en pratique ces compétences. En particulier, avoir un public est un grand facteur de motivation !

Vous donne un moyen de prouver que vous savez de quoi vous parlez

C'est une chose d'avoir une liste de technologies que vous connaissez sur votre CV; c'en est une autre de prouver que vous les comprenez vraiment en étant capable de créer des liens vers des articles que vous avez écrits qui démontrent clairement que vous connaissez votre métier de fond en comble.

Vous aide à vous commercialiser et à créer des opportunités

Jeff Atwood a rencontré Joel Spolsky en partie via son blog, Coding Horror , et ils ont ensuite créé une petite chose appelée Stack Overflow.

Vous ne pouvez pas garantir que de telles choses se produiront simplement en créant un blog, mais cela ne fait certainement pas de mal non plus. Et en particulier dans les domaines technologiques de niche, vous pourriez constater que votre nom peut ressortir de quelqu'un à travers eux ayant lu un de vos articles dans le passé.

Une comparaison rapide des SSG

Voici mes réflexions sur quelques SSG populaires et comment j'en suis venu à m'installer sur Hugo. Voir jamstack.org pour une liste beaucoup plus longue.

Jekyll

Jekyll était autrefois très populaire, mais il l'est moins maintenant. Il alimente les pages GitHub et est très orienté blog. J'y ai d'abord pensé, mais j'ai été rebuté par sa structure d'URL stricte qui insiste sur le fait que les pages de blog ont un composant de date intégré dans l'URL, ce que je voulais éviter pour mon propre blog.

Cela peut être évité en écrivant des articles dans le cadre d'un type de «collection» plus abstrait, mais cela perdrait alors de nombreux avantages de travailler dans sa propre abstraction d'articles de blog.

soixante-dix

Eleventy est un SSG qui a gagné en popularité. Il est alimenté par node.js et est très flexible ; vous pouvez personnaliser le moteur de modèles et le moteur de rendu Markdown, vous permettant même d'utiliser différentes options pour différentes pages d'un même site.

Le principal inconvénient que j'ai trouvé avec ceci est qu'il n'est pas livré avec des modèles intégrés, vous ne pouvez donc pas facilement générer un blog dès la sortie de la boîte. Il convient également de noter qu'il s'exécute sur un nœud, ce qui complique son installation ; pas un deal-breaker par tous les moyens, mais pas aussi pratique que Hugo.

Gatsby

Gatsby est également devenu très populaire ces derniers temps. Cependant, il génère des applications d'une seule page basées sur la réaction plutôt que des sites statiques. Il s'agit d'une option valide ; Je voulais la simplicité du pur HTML & CSS lors de la création de mon blog.

De plus, j'ai vu que cet écrivain avait eu une mauvaise expérience de son utilisation, recommandant Hugo à la place.

Hugo

Enfin, nous arrivons à Hugo, le SSG que j'utilise pour mon propre blog. Il est écrit en Go, ce qui signifie que l'utiliser signifie installer un seul binaire. Cela présente des avantages du point de vue de l'hébergement ; vous pouvez simplement spécifier la version Hugo sur mon fournisseur, et vous pouvez être sûr qu'il se comportera de la même manière qu'il le ferait localement.

C'est ultra rapide. Bien que cela fasse peu de différence lorsque votre blog ne contient que quelques articles, il est bon de savoir que le temps de construction restera fiable à mesure que votre site se développera.

C'est le SSG le plus populaire (à en juger par les étoiles GitHub) , ce qui signifie qu'il est bien utilisé et documenté, et bien pris en charge par à peu près n'importe quelle plate-forme d'hébergement de sites statiques.

Surtout, il a des modèles pour vous aider à démarrer. Bien que vous souhaitiez probablement créer vos propres modèles à un moment donné (ou au moins les modifier à votre goût), cela vous donne au moins quelque chose pour commencer.

Son principal inconvénient est qu'il utilise le langage de template de Go ; ce n'est en aucun cas terrible, mais c'est un peu maladroit par rapport à certains, et si vous aimez un autre langage de modèle, vous n'auriez pas de chance ici. Si c'est un problème pour vous, alors Eleventy vaut peut-être le coup d'œil.