L'auteur détaille les outils qu'il utilise et ses méthodes - voici le résumé :

1. Noter ses idées dans Google Keep
2. Définir les objectifs de son projet : objectifs généraux et objectifs "temporels" (court, moyen et long terme)
3. Demander des retours au bon moment, aux bonnes personnes (définir son audience)
4. Apprécier le temps de développement (choix des technos, frameworks, etc.) - utilisation de la méthode Pomodoro. S'il ne se sent pas motivé, l'auteur tente pendant 10 min de coder... Souvent ça suffit, mais sinon il s'arrête.
5. Moins on s'éparpulle, mieux c'est - utilisation de Kanban avec Trello, une seule tâche "en cours" à la fois - pas d'évaluation précise du temps mais un macro sizing
6. Prendre des habitudes - méthode "ne pas briser la chaîne" pour s'assurer de consacrer un minimum de temps chaque jour.
7. Ne pas se mettre de pression inutile
8. Éviter le perfectionnisme en se donnant des limites

L'auteur donne de bons conseils pour gérer ses side projets

Dans ce vieil article, l'auteur montre les dangers de nouveautés introduites par PHP 7.2, notamment le possible mauvais usage du type "object". D'une manière générale, il insiste sur le fait de préciser au maximum la classe / interface des objets plutôt qu'un type générique ne donnant aucune information sur les champs / méthodes possibles.

L'auteur décrit les 7 étapes dans son apprentissage du TDD

Étape 1. Le lâcher prise : barrière psychologique
Étape 2. Petit à petit, on est moins petit : la vraie valeur de TDD
Étape 3. Abuser de son IDE
Étape 4. La liberté du refacto : la confiance en notre code
Étape 5. Ne pas refacto trop tôt
Étape 6. Tests techniques versus tests métier
Étape 7. Double loop BDD TDD <3

L'auteur évalue les avantages et inconvénients du principe DRY - don't repeat yourself - tel qu'énoncé dans le Pragmatic Programmer. Ce principe explique surtout qu'il y a un gros avantage à avoir une seule source de vérité pour la connaissance métier. Cela n'implique pas que le code ne soit jamais dupliqué - "la duplication est bien moins coûteuse qu'une mauvaise abstraction"

L'auteur présente le data binding dans React, et donne quelques bons conseils pour éviter les quelques pièges.

L'auteur développe l'idée que le code lisible est infiniment supérieur au code "intelligent". Pour juger de la lisibilité, il se demande si un junior pourrait comprendre le code sans souci...

L'auteur explique certaines particularités / problèmes des types en PHP7.
Il préconise l'utilisation du mode strict et de ne jamais avoir besoin de typage faible. On devrait toujours connaître le type précis de nos variables. Enfin il faut éviter au maximum le type nullable.

L'auteur montre comment utiliser les formulaires Symfony, tout en gardant des entités représentant réellement des concepts du domaine métier. Le point principal est la possibilité de vérifier des contraintes sur la partie "setter" et de donner un nom métier au setter.

L'auteur présente ses principes en tant qu'auteur et développeur :

• l'état d'esprit (mindset) précède les outils
• la qualité est au dessus de la quantité
• se concentrer sur les fondamentaux
• écrire des articles qui resteront vrais dans le futurs et cohérents
• l'expérimentation est la clef

Tout est dans le titre

L'auteur présente les formats utilisables tels que les noms de couleur, rgb et hsl, mais aussi des formats à venir / en cours d'implémentation comme lch.
Il termine en préconisant hsl car ce format est bien plus intuitif (couleur devinable) et manipulable (facile d'éclaircir / assombrir)

L'auteur présente un guide pour choisir le bon type de visualisation de données.

Le taux de couverture de code (code coverage) est un indicateur très incomplet, dont l'auteur montre bien les limites. Il propose d'utiliser, en plus, le taux de couverture des chemins d'exécution (branch coverage) qui pallie certains défauts du code coverage.

Sebsauvage partage ses astuces pour faire des sauvegardes efficaces, en vérifiant l'intégrité des données.

L'auteur présente, dans cet excellent article, plusieurs manières de produire du contenu textuel plus profitable et intelligible pour les lecteurs.

Il rappelle aussi les nombreux avantages de ce format, ainsi que quelques mauvaises pratiques qui le rendent plus difficiles à lire ou comprendre.

L'auteur explique l'importance d'avoir une organisation spatiale cohérente, notamment quand on crée un "design system" : marges, dimensions, taille des composants... Il poursuit en décrivant ce qu'est une grille et en donnant quelques exemples.

Pour résumer et paraphraser l'auteur : la sécurité, c'est du temps

L'idée principale de cet article est d'éviter de sérialiser directement des résultats de requêtes Doctrine, mais plutôt de les transformer pour ne renvoyer que le strict nécessaire.

Liste des 8 idées erronées à propos du temps :

1) Toutes les façons de dépenser son temps ont la même valeur pour soi (loisirs, travail, etc.)
2) Le temps est intangible et ne peut pas être mesuré / évalué.
3) Plus de temps équivaut à plus de productivité.
4) La gestion du temps concerne le fait d'en faire plus.
5) Pour être productif, vous devez tout faire par vous même.
6) Vous ne pouvez pas contrôler votre calendrier sauf si vous êtes le patron.
7) Il est bon d'être constamment occupé.
8) La gestion du temps se règle en une seule fois.