46 liens privés
L'auteur explique que les deadlines ne fonctionnent pas, même en tenant compte de la loi de Parkinson :
- Le temps nécessaire pour faire quelque chose ne dépend généralement pas de la pression que l'on met à l'exécutant.
- Les deadlines favorisent la vision court termiste, plutôt que l'amélioration continue et consistante.
- Les deadlines ne permettent pas l'adaptation, si on en rate une, c'est trop tard pour faire quelque chose d'utile.
L'auteur suggère aux managers deux actions :
- Un contrôle quotidien, ou point de préemption (via le daily meeting) afin de vérifier qu'on ne s'écarte pas trop de la ligne que l'on s'est fixée et de s'adapter le cas échéant.
- Être impitoyable sur la priorisation des tâches - l'approche FIFO n'étant pas la bonne (Note: voir la matrice d'Eisenhower ?)
L'auteur montre une approche pour donner du sens aux valeurs manipulées par un programme, en les encapsulant dans un objet immutable. Par exemple, si on doit s'occuper d'une note entre 0 et 5, on crée un objet avec la propriété "rating" (dont on s'assure de la cohérence métier). Ensuite, en créant dans cet objet les méthodes toString() et valueOf(), on permet de réaliser des opérations - comme un affichage direct (toString) ou une addition (valueOf)
Tout est dans le titre
De bons conseils pour l'écriture de README
L'auteur partage quelques conseils sur l'utilisation des chans en Go (taille, etc.) pour ne pas tuer les performances
Tout est dans le titre - cette fois, ça concerne les performances
Tout est dans le titre
Des infos et conseils sur SQL
Tout est dans le titre
Tout est dans le titre
9 conseils / principes utiles – l’article explique pourquoi
1. un niveau d’indentation par méthode
2. ne pas utiliser le mot clef « else »
3. encapsuler toutes les primitives dans des classes
4. créer des collections / ensembles dédiés
5. respecter la loi de Demeter
6. ne pas abréger les noms des variables
7. garder les entités les plus petites possibles
8. pas de classes avec plus de 2 variables d’instance
9. pas de getters / settersL'auteur décrit une manière de gérer les menaces potentielles sur une application, en les explicitant dans un document. Il prend l'application web JSONDiff comme exemple
Un article passionnant sur l'héritage vs la composition en POO. J'en retiens sa conclusion : il ne sert à rien de se forcer à utiliser des grands principes (DRY, héritage, composition, etc.) tant que l'on n'a pas une compréhension claire du problème que l'on essaye de résoudre... par contre, ces grands principes sont très utiles pour le refactoring.
L'auteur montre comment configurer un workflow Symfony via l'utilisation d'une interface PHP et des constantes - cela permet d'utiliser ensuite ces constantes un peu partout (dans workflow.yml, dans les classes PHP, dans les templates, etc.) Astucieux !
Plein de bons conseils sur la typographie (accessibilité et design responsive)
L'auteur montre l'installation de Debian sur un Kimsufi - il aborde pas mal de thèmes intéressants comme le réseau, la connexion par SSH, etc.
Avec quelques astuces et conseils en prime (certification Kubernetes)
L'auteur explique l'importance de choisir ses priorités et comment il fait
Tout est dans le titre