Article très intéressant sur comment nommer correctement ses classes CSS. En substance le comportement visuel ne doit jamais fuiter dans le nom de la classe, autrement cela voudrait dire que le HTML connaît une partie de la présentation ce qui viole le principe de séparation des préoccupations.
Par exemple pour un message principale sur page d'accueil il ne faut pas écrire :
.big-text-center {
/* ... */
}
Mais écrire :
.greeting {
/* ... */
}
Les principes du design atomique (pour @Animal) qui va m'aider sur un projet :P #TasPasLeChoix
Article très intéressant que m'a proposé @Chlouchoutte sur comment les individus d'une entreprise se passent la patate chaude, à savoir le TAF ici appelé The Monkey.
Je ne peux que vous recommander sa lecture surtout si vous gérez une ou plusieurs équipes, ce qui est mon cas.
Merci @Philiou qui me ressort cette page que j'ai lu il y a quelques années.
Pour toi @Animal, une explication des méthodologies de gestion des risques.
À proposer en dojo !
Un résumé ultra-condensé :
- Abandonner les PowerPoints.
- Abandonner les séances de "brainstorming" à plusieurs.
- Tout écrire seul sur des mémos de 4 pages maxi.
- Structurer / Imposer un format pour les mémos.
- Accepter la critique écrite des mémos.
- Intégrer les remarques dans le mémos mis à jour.
- Arrêter l'oral et éviter de se répéter.
Pour @Chlouchloutte et @Strawberry.
Méthodologie de calcul de risque (pour tuer les points de fonctions).
A methodology for building modern, scalable, maintainable software-as-a-service apps.
À lire et à relire ! À destination de tous les Ops et DevOps.
Comme je me penche pas mal sur les problématiques de testing je mets cela de côté
Move Fast and Break Things. Je ne connaissais pas cette méthodologie qui vraisemblablement est contre-productive.