AJA qu’il existait une alternative pour tester les exceptions en C#. Depuis toujours j’utilisais la syntaxe suivante :

1
2
3
4
5
6
7
8

[TestMethod]
[ExpectedException(typeof(DivideByZeroException))]
public void Division_ShouldThrowIfDividedByZero()
{
    var a = 1;
    var b = 0;
    var c = a / b;
}

Cette syntaxe est assez limitée car elle ne permet pas d’effectuer d’assertions sur l’exception levée pendant l’exécution du test.

Certes, on peut insérer un bloc try/catch et effectuer des assertions comme ceci:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[TestMethod]
[ExpectedException(typeof(DivideByZeroException))]
public void Division_ShouldThrowIfDividedByZero()
{
    try
    {
        var a = 1;
        var b = 0;
        var c = a / b;
    }
    catch(Exception e)
    {
        Assert.AreEqual("Attempted to divide by zero.", e.Message);
        throw; // throw nécéssaire pour que le décorateur Expected soit honoré
    }
}

Mais ce n’est pas très élégant 😢.

Or il existe une autre syntaxe bien plus pratique :

1
2
3
4
5
6
7
8
9
10
11

[TestMethod]
public void Division_ShouldThrowIfDividedByZero()
{
    var ex = Assert.ThrowsException<DivideByZeroException>(() =>
    {
        var a = 1;
        var b = 0;
        var c = a / b;
    });
    Assert.AreEqual("Attempted to divide by zero.", ex.Message);
}

La lisibilité des tests est améliorée, les code reviews sont plus sereines et le monde se porte mieux. 🌈

AJA la distinction entre un composant VueJs et un web component.

Quand on démarre un projet en VueJs (ou React ou Angular), les composants que l’on crée sont écrits dans la syntaxe propre à ce framework. C’est efficace si l’on travaille toujours dans ce framework, on peut par exemple réutiliser notre module VueSwitch entre plusieurs projets VueJs. Mais ces composants ne sont pas directement réutilisables dans d’autres projets n’utilisant pas VueJs. C’est un problème que les web components natifs peuvent résoudre.

En effet, les web components constituent une technologie native des navigateurs web et ne dépendent pas d’un framework javascript particulier pour fonctionner. Ils peuvent encapsuler leur code HTML, JS, CSS propres, en isolation (c’est à dire qu’il n’y aura par exemple pas de conflit entre le CSS défini dans ce web component et le CSS de la page qui l’héberge).

Il n’est pas forcément très pratique de définir un web component à partir de rien : toute la logique doit être développée sur place et cela peut s’avérer fastidieux en mode “Vanilla JS”, a fortiori sans l’assistance d’un framework tel que VueJs embarquant des utilitaires pour la réactivité et le concept de cycle de vie, par exemple .

Enfin, le CLI de VueJs embarque la possibilité d’extraire un web component à partir d’un composant VueJs mais ce composant aura toujours une dépendance sur le framework VueJs, ce qui perd beaucoup de son intérêt.

Chez Github, ils ont fait le choix de développer directement en natif, ce qui ne les enferme pas trop dans un paradigme de programmation Front-end, mais à quel prix ?

AJA que je pouvais économiser 4 secondes à chaque fois que je veux push une branche à distance !

En effet, dans le cadre profesionnel, je suis souvent amené à créer des noms de branches du genre :

1

$ git checkout -d JIRA-14523-nom-de-nouvelle-branche-tres-tres-long

Pour créer la branche, je n’ai pas le choix, je dois tout écrire au moins une fois.

Mais à la fin de la journée, je trouve pénible de devoir le retaper, typiquement lorsque je dois push ma branche pour faire la pull-request :

1

$ git push -u origin nom-de-nouvelle-branche-tres-tres-long

Dans git bash, le nom de la branche courante est affiché dans le prompt donc je peux toujours la copier/coller, mais je préfère garder les mains sur le clavier quand j’utilise le terminal.

Pour régler ce grave problème 😏, on peut créer un alias dans le fichier .bashrc du compte de la machine :

1

alias cb='git symbolic-ref HEAD --short'

Ce qui permet de récupérer le nom de la branche courante sans le retaper :

1
2

$ cb
JIRA-14523-nom-de-nouvelle-branche-tres-tres-long

En revanche, il n’est pas possible d’injecter tel quel cet alias dans une commande git car git penserait qu’il s’agit d’un nom de branche et va remonter une erreur. Pour palier à cela, il suffit d’entourer l’alias avec des `backquotes` :

1

$ git push -u origin `cb`

Et voilà, plus besoin de prendre la souris pour copier le nom de la branche !

AJA que l’on pouvait appliquer les changements d’une série de commits sans les enregistrer, pour faire un genre de squash à la volée.

Le scénario typique pour faire cette manip est le suivant. Vous avez une série de commits sur votre branche main, et vous voulez appliquer l’ensemble des patchs sur une branche de prod pour un hotfix avec un unique commit qui réunit tous les changements.

Sur la branche main :

1
2

commit 1 -> commit 2 -> commit 3
316e63c     ab0f801     3ae6aa6

Mais vous voulez obtenir sur la branche HF :

1
2

commits 1 + 2 + 3
xxxxxxxx

La commande git cherry-pick permet d’appliquer les changements d’un set de commits sans les enregistrer, avec le flag -n :

1

$ git cherry-pick -n 316e63c ab0f801 3ae6aa6

Les changements sont dans le stage de git, il ne reste plus qu’à faire le commit avec un nouveau message probablement plus approprié pour une branche de hotfix.

AJA que l’on pouvait écrire des constructeurs typescript qui automatisaient la creation de variables locales, cela s’appelle “Parameter properties”.

Plutôt que d’écrire :

1
2
3
4
5
6
7

class Car {
  private brand: string;

  constructor(brand: string) {
    this.brand = brand;
  }
}

on peut écrire

1
2
3

class Car {
  constructor(private brand: string) {}
}

Plus d’informations sur les parameter properties ici.

AJA comment prendre en main l’outil de blog que j’ai utilisé pour écrire ce premier billet : Hexo. Il a l’air très developer-friendly.

J’apprécie le coté open-source et la rapidité avec laquelle on peut écrire des billets, en markdown, qui est un format que je trouve très pratique.

Maintenant, il ne me reste plus qu’à trouver comment déployer tout ça quelque part ! 😏

Edit: c’était vraiment très simple, avec la page d’aide dédiée pour les pages Github !

J’en ai profité pour comprendre un peu mieux comment fonctionnent les github actions.