339 private links
La prouesse technique d'avoir du Wifi à bord des TGV, et pourquoi c'est si compliqué !
Des conseils sur l'usage d'une voiture électrique. Je poses cela ici pour partage ou utilisation ultérieure.
Summarized to:
Fight for Pareto's law, look for the 20% of effort that will give you the 80% of results.
Prioritize, minimalism isn't about not doing things but about focusing first in the important.
Perfect is enemy of good, first do it, then do it right, then do it better.
Kill the baby, don't be afraid of starting all over again. Fail soon, learn fast.
Add value. Think constantly how you can help your team and position yourself in that field/skill.
Basics, first. Follow always a top-down thinking starting by the best-practises of CSS.
Think different. Simple is harder than complex, which means you'll need to use your creativity.
Synthesis is the key of communication. We have to write code for humans not machines.
Keep it plain. Try to keep your designs with few layers of indirection.
Clean kipple and redundancy. Minimalism is all about removing distractions.
A great example!
Some dark/light mode toggles
How to handle spacing between css elements in one line of code?
.flow > * + * {
margin-block-start: var(--flow-space, 1em);
}Vérifier la validité des liens d'une page et y ajouter une classe .status comme .status404
Une étude de l’UFC-Que choisir a montré que les supermarchés faisaient deux fois plus de marge sur les fruits et légumes bio que sur les conventionnels. D’après tous les experts que l’on a interrogés, la pratique est la même pour la viande et les produits laitiers bio et sous Label rouge.
Le TDD est avant tout une méthode de développement permettant de faire émerger son design et donc son code grâce aux tests
“Baby-step”, c’est la clé pour s’amuser, pas au sens d’enfantillage, mais pour prendre plaisir à développer et comprendre que notre métier est vraiment beau quand on supprime toute forme de “hasard”.
Un cycle TDD "Red, Green, Refactor" correspond une une bribe de spécification écrit sous forme de test et sa réponse. On écrit le code minimaliste pour que ce test "Red" fonctionne et passe au "Green".
Pour cela, il est recommandé d'abuser de son IDE. Par sa construction itérative guidée par les tests, TDD apporte par “effet de bord” un taux de couverture de code par les tests à 100%. Ce n’est pas ce que l’on recherche de prime abord, mais ce code coverage est là, et surtout il est pertinent. C’est ce dernier mot qui est important : cette pertinence permet réellement de se plonger dans la troisième phase de TDD.
Ensuite on refactorise pour donner plus de sens: spécifier les erreurs, de passer d'un constructuer à un builder, ... Nous pouvons nous le permettre car les tests nous soutiennent. Ils seront aussi à évoluer, par exemple pour vérifier que le builder pattern fonctionne correctement.
(avec le TDD)
Ainsi, il ne peut pas y avoir la moindre ligne de code écrite sans test. Au-delà d’une technique de développement, cette technique de conception permet de poser la question explicitement : “Qu’est-ce que tu cherches à vérifier ?” Lorsqu’on répond à cette question, en développant le test automatisé qui matérialise la réponse, alors l’implémentation du morceau de fonctionnalité découle naturellement.
Un bug va obligatoirement engendrer plusieurs heures de perte pour l’organisation au global, en plus de créer des frustrations, de la perte d’image de marque, de détérioration de la confiance envers le produit, des mauvaises notes sur les stores et un risque de perte définitive du client.