Tout est dans le titre

L'auteur parle de la nécessité de faire attention à ses commits publics dans git

Un article très intéressant... et un twist final pas mal ^^

Plein de bons conseils pratiques pour s'améliorer en programmation

L'auteur explique l'intérêt de multiplier les mesures dans le logiciel - aide à la décision, alertes sur des problèmes en cours ou à venir, etc. La mesure est indispensable si on souhaite agir au plus juste.

Dans cet article, l'auteur explique la relation entre cohésion et couplage. Pour paraphraser son résumé final :

• De par les limitations de notre cerveau pour appréhender des systèmes complexes, nous cherchons à modulariser notre base de code en parties indépendantes.
• Un module est un ensemble d'éléments qui devraient être autant liés entre eux (cohésion) que possible, avec une frontière nette entre "l'intérieur" et "l'extérieur".
• Les connexions entre les différentes frontières des modules devraient être réalisées via leurs interfaces, une manière contrôlée de communiquer à travers les frontières.
• La force du couplage de ces connexions dépend du nombre et de la complexité des interfaces des modules, la quantité et la nature des données échangées, et si les composants des modules changent souvent en même temps.
• Il y a plusieurs types de couplage, et de nouveaux sont toujours "découverts".
• Créer des modules cohérents est la meilleure manière d'éviter un couplage fort. Autrement dit, des modules faiblement couplés ont souvent une grande cohésion.
• Une cohésion imprécise ou de haut niveau devrait être évitée - il s'agit d'une cohésion artificielle (des bouts de code rassemblés en un même endroit bien qu'ils n'aient rien à voir). À la place, nous devrions tendre vers des modules dédiés à la résolution de problèmes métiers bien définis.
• Il est plus facile d'arriver à une grande cohésion fonctionnelle avec des modules mécaniques, tels que des modules dédiés à la résolution de problèmes mathématiques (ceux ci ont peu de chance de changer)

Une abstraction a 3 caractéristiques :

• Elle masque les informations inutiles.
• Elle généralise un concept.
• Elle est un point de vue de la réalité (ex: chaque type de carte traite d'un aspect de la géographie, carte routière, carte topographique, carte des monuments, etc.)

On n'oubliera pas qu'une abstraction n'est pas l'objet qu'elle représente !

Comme la programmation concerne les données et le contrôle de leur flux, il y a deux types d'abstractions : les abstractions de données, et les abstractions du contrôle de flux.

Les abstractions de données servent à :

• simplifier en masquant la gestion de la mémoire et les mécanismes de comportement (ex: ne pas faire d'addition sur des chaînes de caractère)
• fournir des comportements génériques réutilisables
• donner aux développeurs le pouvoir de créer de nouvelles abstractions via les "ADT" (Abstract Data Type)

Les abstractions de contrôle sont essentiellement les fonctions car :

• Le nom de la fonction simplifie et masque ses mécanismes internes.
• Une fonction généralise un comportement, qui peut être réutilisé partout.
• Vous devez être conscients que le nom de la fonction peut ne pas correspondre exactement à la réalité (problème du nommage)

En POO, une classe est une abstraction réunissant structure de données et comportement. Il existe aussi les classes abstraites qui permettent de généraliser certains comportements que l'on souhaite masquer. Enfin les interfaces sont aussi des abstractions, même si leur intérêt principal est plutôt la possibilité de changer d'implémentation concrète.

L'avantage principal des abstractions est la simplification en masquant les détails non pertinents. Il y a toutefois des inconvénients à ne pas négliger :

• problème du nommage
• sursimplification -> manque de contrôle par l'utilisateur (interface trop simple), perte de détails (tous les détails ne sont pas à masquer)

Pour pallier ces problèmes, il faut donc rester le plus proche possible du "métier" et ne pas utiliser d'abstraction de prime abord.

Les abstractions masquent les détails inutiles... mais ceux ci peuvent faire surface malgré tout ("fuite") L'endroit où se situe la fuite fera toute la différence dans la résolution du problème : votre code, le code d'un collègue, le code d'une librairie externe, le langage, le matériel !

Ensuite, l'auteur illustre par un exemple le danger de créer une abstraction trop tôt : il avait pensé à plusieurs cas possibles... mais pas suffisamment. Résultat : sa classe a fini par exploser les compteurs de complexité cyclomatique à coup de "if". Il vaut mieux dupliquer du code tant que l'on n'a pas une connaissance raisonnable des abstractions sous jacentes.

L'auteur parle aussi de la confusion entre abstraction et indirection. Une indirection permet de remplacer une partie de l'implémentation par autre chose (ex: les interfaces)

Certaines abstractions créent des indirections (classe abstraite, interfaces)
Créer une indirection ne signifie pas que vous créez une abstraction.
Les indirections facilitent le changement... mais au prix d'une lisibilité moindre.

En résumé de l'article :

• Les états globaux mutables doivent être évités à tout prix.
• On peut réduire le scope d'un état mutable - c'est le but - en passant cet état en tant qu'argument d'une fonction, en utilisant l'injection de dépendances ou des objets de contexte (similaires aux Value Objects).
• Les variables globales ne sont que le sommet de l'iceberg : le plus important est de respecter le principe d'encapsulation, et il y a plusieurs manières de ne pas le faire... Les états globaux mutables ne sont qu'un exemple extrême.
• Les états globaux immutables sont moins pires, mais il est préférable malgré tout de les éviter.

Une critique argumentée du principe ouvert/fermé...

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