Tout est dans le titre
Conclusion de l'article : éviter le plus possible d'employer des mots comme facile, simple, rapide, ... quand on décrit une fonctionnalité à implémenter
Sutie de https://blog.microlinux.fr/imac-03-carte-reseau/ - installation de la carte graphique, avec quelques astuces en cas d'écran noir
Suite de https://blog.microlinux.fr/imac-02-installation/ - installation du pilote de la carte réseau... et où l'on peut découvrir que tout ne se passe pas forcément comme prévu. L'auteur montre la démarche pour rechercher les pilotes à partir du code constructeur.
L'auteur explique en quoi un modèle de données riche est bien plus intéressant qu'un modèle pauvre, notamment en ce qui concerne la cohérence métier des entités.
Un excellent guide pour l'animation de SVG, avec quelques bonnes pratiques d'optimisation
Un résumé d'une conférence à propos de la duplication de code - généralement à éviter mais avec quelques exceptions
Tout est dans le titre, sauf le mot "log" :)
Il y a pas mal de bizarreries qui peuvent arriver lorsqu'un document yaml est interprété - l'auteur recommande d'utiliser plutôt toml ou de s'imposer de toujours mettre les chaînes de caractères entre quotes
Tout est dans le titre
Uncle Bob explique sa prise de conscience qu'il ne faut pas hésiter à utiliser des structures de classe dans la programmation fonctionnelle, même quand le langage (ici le clojure) ne dispose pas de mot clef spécifique pour ça. L'idée est de bien classer les données / méthodes qui vont bien ensemble.
Une place pour toute chose, chaque chose à sa place
L'auteur détaille les outils qu'il utilise et ses méthodes - voici le résumé :
- Noter ses idées dans Google Keep
- Définir les objectifs de son projet : objectifs généraux et objectifs "temporels" (court, moyen et long terme)
- Demander des retours au bon moment, aux bonnes personnes (définir son audience)
- 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.
- 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
- Prendre des habitudes - méthode "ne pas briser la chaîne" pour s'assurer de consacrer un minimum de temps chaque jour.
- Ne pas se mettre de pression inutile
- É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.