Une de mes résolutions du Nouvel An cette année était de bloguer davantage. J’ai reconstruit le blog à partir de zéro. Voici un avant/après :
Il y avait beaucoup d’objectifs dans cette reconstruction, mais le principal était de me donner une plate-forme que je pourrais utiliser de manière plus sérieuse. Même s’il s’agit toujours d’un blog personnel, je voulais qu’il ressemble davantage à une ressource communautaire, quelque chose que les gens considèrent comme une bonne source de tutoriels et d’articles de qualité.
Une grande partie de cet objectif est de publier régulièrement ! Je me suis fixé un objectif d’au moins 1 publication par semaine. Depuis le lancement, j’ai réussi à tenir cet objectif et j’espère que la tendance se poursuivra.
Alors que la plupart des changements ont été adoptés par mes lecteurs, il y a eu un changement qui a surpris quelques personnes : mon nouveau blog n’est pas open-source. J’ai reçu beaucoup de questions à ce sujet et j’ai pensé qu’il serait bon d’y répondre et de partager une partie de mon raisonnement 🙂
Une grande partie est liée à la friction. Afin de maintenir la vitesse de mes nouveaux messages à un niveau élevé, j’ai besoin que la publication soit aussi simple et sans friction que possible. Avoir un blog open source ajouterait des frictions de plusieurs manières.
Mon blog utilise MDX, une version sophistiquée de Markdown qui me permet d’intégrer des composants React. Les publications sont archivées dans le référentiel Git plutôt que stockées dans un CMS.
Chaque poste a un isPublished booléen dans son frontmatter. À tout moment, j’ai entre 1 et 5 brouillons. Parfois, un brouillon dure des semaines avant que je ne me mette à le terminer et à le publier !
Si ce blog était open source, tous ces brouillons seraient publics. Je n’aime pas cette idée 😅 Je veux contrôler quand une publication est publiquement disponible !
Il existe des solutions pour cela; Je pourrais conserver les messages dans un référentiel séparé ou utiliser des sous-modules Git. Cela compliquerait mon processus cependant. Et plus le processus est compliqué, moins je serai motivé pour y travailler.
Pour un prochain post, j’ai construit un peu VennDiagram composant:
Ce composant n’est pas particulièrement bien construit ; d’une part, ce n’est pas très flexible. Cela ne prend que 2 cercles, et je ne peux pas contrôler le rapport entre eux. Je ne l’ai pas testé avec des cordes longues ou courtes.
Puisqu’il s’agit d’une source fermée, rien de tout cela n’a d’importance pour moi. Mais s’il était ouvert, les gens voudraient le saisir pour l’utiliser dans leurs propres projets. Je me sentirais une certaine responsabilité de m’assurer qu’il fonctionne bien, ou du moins de m’assurer que ses lacunes sont bien documentées. Et je ne veux pas de cette responsabilité maintenant.
Il y a quelque temps, je proposé de revoir sites Web de portefeuille de développeurs pour les personnes en début de carrière sur Twitter. J’ai reçu plusieurs centaines de demandes 😬
J’ai découvert une tendance : certains développeurs copiaient de manière flagrante des portefeuilles populaires. Par exemple, consultez ce magnifique portfolio de Brittany Chiang :
j’ai eu trois soumissions de développeurs qui ont été identique pour ça. Je ne veux pas dire qu’ils étaient fortement inspirés, je veux dire qu’ils ont bifurqué le repo, échangé le nom et les projets, et l’ont appelé fait.
Le référentiel a une licence MIT, donc ces imitateurs de portefeuille ne violaient aucune règle ou loi ou quoi que ce soit… Mais cela me rend triste de voir quelqu’un d’autre essayer de s’attribuer le mérite du travail incroyable que Brittany a fait (même si vous ajoutez une attribution sur Github ou dans le pied de page du site ou quelque chose comme ça, la plupart des gens ne verront jamais ça).
Le problème avec le dumping d’un projet entier sur Github est qu’il est donc facile de le bifurquer, de changer quelques choses et de l’expédier. Je pourrais utiliser une licence restrictive, mais est-ce que je veux vraiment essayer de suivre/appliquer les violations de licence ?
C’est ironique, parce que j’aime vraiment l’idée que les gens prennent et utilisent les pièces de ce site ; par exemple, j’écris actuellement un article sur , et j’espère que les gens auront cette idée pour leurs propres projets. Mais c’est différent quand c’est littéralement le tout le site.
Il y a aussi le fait qu’un référentiel open source forké est toujours hors de votre contrôle, ce qui peut être problématique. Blogueur Tania Rascia a écrit:
Je me rends compte qu’avoir l’intégralité de mon site Web, y compris tous mes écrits publics et open source, dans un seul référentiel que vous pouvez bifurquer était une mauvaise idée, en fonction du nombre de personnes qui bifurquent sur le site et y laissent simplement tous mes messages et informations personnelles.
Les gens peuvent toujours créer des copies des pages de mon blog, mais le bifurcation le rend beaucoup plus facile / plus probable (et ces bifurcations sont publiques par défaut).
Lorsque j’ai relancé mon blog, il était accompagné d’une fonctionnalité astucieuse : la possibilité d'”aimer” des articles :
Comme les applaudissements moyens, vous pouvez “aimer” un article plusieurs fois, jusqu’à 16 fois.
J’ai ajouté cette fonctionnalité parce que je pensais que ce serait mignon ; ce n’est pas vraiment faire n’importe quoi. Contrairement à une plate-forme comme Medium, je suis le seul auteur ici, donc il n’y a pas d’algorithme que j’essaie de jouer pour donner un coup de pouce à mes publications. Je suppose que cela m’aide à savoir quels messages sont précieux pour vous, même si je soupçonne que le rapport signal sur bruit est très faible (si mon message commence à avoir une tendance sur les agrégateurs de liens, par exemple, le rapport similaire chute).
Quelques jours après le lancement, je me suis réveillé avec quelque chose d’assez surprenant :
Le poste n’avait reçu que quelques centaines de visiteurs, ce nombre n’avait donc aucun sens. J’ai creusé dans les données, seulement pour trouver que J’avais été piraté !
Remarquablement, le coupable était Jane Manchun Wong, découvreuse de fonctionnalités prolifique, hacker voyou et badass polyvalente!
C’était une délicieuse surprise, mais c’était un peu révélateur; J’utilise des fonctions sans serveur pour tout le code backend et je paie par invocation (à la fois en termes de fonctions et d’appels de base de données). Quelqu’un pourrait me coûter pas mal d’argent s’il décidait de DDOS mes terminaux !
J’ai fait quelques recherches et ajouté quelques gardes, mais ce n’est pas mon domaine ; si j’ouvrais la base de code en source ouverte, il serait plus facile pour les mauvais acteurs de trouver des failles dans mes sauvegardes.
Vous serez peut-être surpris d’apprendre que ce site et sa newsletter coûtent environ 130 USD par mois pour fonctionner ; Je ne gagne pas d’argent sur le site, donc cela vient de ma poche. J’aimerais vraiment garder ce coût aussi bas que possible 😅
Pour ces raisons, je vais garder mon blog en source fermée pour le moment.
Je reconnais que c’est une déception pour les gens qui voient quelque chose de cool et qui veulent savoir comment je l’ai fait. Mais j’ai un plan pour cette situation !
Plutôt que d’ouvrir une base de code volumineuse et désordonnée, je préférerais écrire des tutoriels détaillés pour des fonctionnalités spécifiques. Cela a déjà commencé – consultez les messages suivants :
J’aime cette stratégie parce qu’elle est tellement explicite. Avec la plupart du code de ce blog, une grande partie du contexte n’existe que dans ma tête ; si vous deviez parcourir le code, vous devriez remplir ce contexte, et cela pourrait entraîner des problèmes. De cette façon, je peux vous guider à travers le fonctionnement d’une chose, quels sont les compromis, quelles sont les limites. Le contexte est inclus.
j’ai un énorme liste de choses sur lesquelles je veux écrire. Le VennDiagram le composant précédent est sur cette liste ! Nous y arriverons en temps voulu 😄
Si vous êtes curieux de connaître la structure générale de la base de code, mon ancien blog est toujours open source et, en termes de structure, il n’a pas radicalement changé. Si vous êtes curieux de savoir comment créer un blog de développeur MDX, cela pourrait valoir le coup d’œil !
Enfin : j’ai activé les cartes source pour ce site ! N’hésitez pas à spéléo dans le code source côté client via le navigateur. Sachez simplement que toutes les mises en garde concernant le contexte mentionnées précédemment s’appliquent toujours ; il est livré sans garantie et je ne suis pas responsable des problèmes qu’il cause dans votre base de code.
Je sais que c’est frustrant, mais j’espère que cela vous aidera à comprendre d’où je viens. Si vous êtes curieux de savoir comment quelque chose fonctionne, n’hésitez pas à demandez-moi sur Twitter! Cela pourrait me pousser à écrire un tutoriel à ce sujet.