L'auteur étudie plusieurs cas de figure, ici c'est l'entreprise qui n'a ni intégration continue, ni déploiement continu... Que se passe-t-il en cas de problème ?

En résumé : git branch --move

Utiliser git mv de préférence ^^

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)

Les 2 commandes à connaître :

• git restore --staged monfichier -> si vous avez ajouté monfichier au stage, cela permet de l'enlever de cette étape
• git restore monfichier -> si monfichier n'était pas encore suivi ("stage"), cela annule les modifications

Un article très complet sur l'authentification - l'analogie avec la banque est amusante 😀

L'auteur présente différents points de vue pour définir ce qu'est un système "legacy".

L'auteur montre comment animer un SVG avec l'utilisation de animateMotion

Je me permets de citer l'auteur :p

On résume : cite pour les noms d'oeuvres, blockquote pour les blocs de citations (plus ou moins longs) et q pour les citations courtes en-ligne dans un paragraphe de texte.

L'auteur parle du service UbuntuPro... mais donne aussi de bons conseils concernant l'utilisation de "unattended-upgrades"

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.

L'explication est claire :)

Ça a l'air bien, Blocky

En résumé :

• Le code machine est un ensemble d'instructions bas niveau pour une famille spécifique de processeurs (CPU).
• Le langage assembleur (ASM) est très proche du code machine, mais il est plus facile à comprendre par les humains. Vous avez besoin d'un assembleur pour le convertir en code machine.
• Un compilateur est simplement un convertisseur d'un langage à un autre. Beaucoup de compilateurs convertiront du code source en code machine avant d'exécuteur le programme (compilation AOT, Ahead Of Time)
• D'autres compilateurs convertiront le code source en bytecode, qui est similaire à de l'assembleur. Ce bytecode sera ensuite traduit par un interpréteur (ou machine virtuelle), ou même compilé en code machine tout en exécutant le programme (compilation JIT, Just In Time)

Une explication très claire sur la suppression de fichiers dans git

Tout est dans le titre

Un coup de gueule justifié

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 courte introduction à Babel

Tout est dans le titre

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

Tout est dans le titre