Encore une pépite à diffuser largement, au sujet du nucléaire, du double discours gouvernemental, et des légendes sur les énergies dites renouvelables qui circulent largement et qui menacent notre avenir collectif.

1) Taper services dans le menu démarrer.
2) Cliquer sur Exécuter en tant qu'administrateur. Entrer l'identifiant/mdp admin local. La fenêtre des services s'ouvre.
3) Choisir le service à démarrer, faire un clic-droit dessus puis Propriétés.
4) Dans l'onglet Général, dans le menu déroulant Type de démarrage, choisir Automatique.
5) Toujours dans le même onglet, dans la partie Etat du service, cliquer sur Démarrer.
6) Cliquer sur OK

Et sinon sous linux : sudo systemctl start nomDuService.

Pour la troisième solution qui consiste à passer des options à la JVM :

java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=file_or_dir_path Main.java

Note : Si c'est un répertoire qui est spécifié, alors le fichier sera nommé avec le numéro du pid. Par exemple java_pid22540.hprof .

Et pour tester ces options, cette main simple génère une OutOfMemoryError :

public static void main(String[] args) throws Exception {

        int dummyArraySize = 15;
        System.out.println("Max JVM memory: " + Runtime.getRuntime().maxMemory());
        long memoryConsumed = 0;
        try {
            long[] memoryAllocated = null;  
            for (int loop = 0; loop < Integer.MAX_VALUE; loop++) {
                memoryAllocated = new long[dummyArraySize];
                memoryAllocated[0] = 0;
                memoryConsumed += dummyArraySize * Long.SIZE;
                System.out.println("Memory Consumed till now: " + memoryConsumed);
                dummyArraySize *= dummyArraySize * 2;
                Thread.sleep(500);
            }
        } catch (OutOfMemoryError outofMemory) {
            System.out.println("Catching out of memory error");
            //Log the information,so that we can generate the statistics (latter on).
            throw outofMemory;
        }
    }

Ca fait du bien d'entendre des hypothèses autres que "ils sont venus, mais comme ils nous ont trouvés trop cons, ils sont repartis".

Très pertinent, encore une fois.

Et maintenant, le plat de résistance.

Pour mémoire.

La loi qui permet aux agents de l'ordre par la force de voir sans être vu. La comparaison avec Big Brother en Chine est savoureuse ...

J'utilise gitlab-ci chez mon client. Or quelque chose m'a profondément agacé ces derniers jours.

Voilà le contexte : le fichier .gitlab-ci.yml du projet sur lequel je travaille prévoit qu'un seul pipeline peut être lancé à la fois sur une même branche. Rien de très étonnant jusque là. Du coup, lorsqu'un pipeline est lancé alors qu'un autre est déjà en cours d'exécution, le second tombe en erreur.

Quel est le problème : quand on est tout seul à faire des merge-request, on peut toujours relancer manuellement un pipeline tombé en erreur. Mais quand on est 10 à en faire, je vous laisse deviner ce qui se passe :

• pendant que le pipeline A tourne, les merge-request affluent et créent des pipelines B, C, D etc qui tombent tous en erreur;
• et une fois que le pipeline A se termine, c'est une énorme course au drapeau qui se déclenche pour savoir qui cliquera le premier sur le bouton permettant de relancer son pipeline (qui dure près de deux heures et demi).
• le perdant ultime gagne potentiellement le droit de se taper le merge de tous les autres, même si sa merge-request est la première à avoir échoué.

Bref. Une bonne âme m'a filé l'astuce, il s'agit d'utiliser la propriété resource_group.

Comme on peut le voir dans l'exemple en lien, il faut simplement :

• ajouter cette propriété dans chacun des jobs qu'on ne veut pas voir s'exécuter en parallèle;
• donner la même valeur à la propriété partout (on peut changer de valeur pour créer des sous-groupes évidemment).

Il s'agit en fait de créer une "ressource" partagée, qui ne pourra être utilisée que par un seul job à la fois (et donc ici, par un seul pipeline à la fois). Les pipelines qui arriveront ensuite seront mis en file d'attente au lieu d'être mis en échec. Quand le premier job/pipeline se termine, il libère la ressource qui est passée au pipeline suivant, etc.

Pour savoir dans quel jar se trouve une classe particulière.

Des données intéressantes qui appuient le choix d'une plus grande taxation, sinon d'un suppression, de l'héritage.

Bon, par contre, je trouve qu'il insiste trop sur le côté égalité des chances, qui, je le rappelle, est une expression de la langue de bois. Car comme le dit Franck Lepage, l'égalité des chances ça revient à dire : quand vous êtes au départ d'une course, que vous soyez un lapin ou une tortue, la ligne de départ est la même.

En effet, résumer l'égalité des chances d'avoir la vie qu'on aura choisi à la quantité d'argent dont on dispose, c'est oublier tout ce qui touche à l'éducation, au cadre de vie, aux fréquentations (et aux réseaux de contacts qui viennent avec), etc. Le patrimoine ne se compte pas qu'en euros.

Et puis avec un âge moyen d'héritage aux alentours de 50 ans, la stratégie qui consiste à attendre que Tata Fernande casse sa pipe est quand même un peu risquée ...

Je ne me souviens jamais de la commande, du coup j'en mets deux ici :

[alias]
lg1 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all
lg2 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all
lg = !"git lg1"

A mettre dans le ~/.gitconfig, ou dans le ~/.bashrc.

Un système décimal utilisé par les moines cisterciens au bas moyen-age. Parfait pour noter les dates.

Confinement V2 : les attestations.

Astuce : Pour l'attestation numérique, dans le champ Heure de sortie, il faut mettre la date au format américain (logique hein), c'est à dire entre 00:00 et 12:00. Et quand vous aurez essayé de taper sur toutes les touches de votre clavier, vous vous rendrez compte que les deux derniers caractères sont ... AM ou PM.

Pour afficher l'arbre des dépendances d'un projet maven, il y a le plugin suivant :

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>3.1.2</version>
</plugin>

Avec la commande suivante :

mvn dependency:tree

Mais il est aussi possible d'afficher un équivalent pour les plugins (ce n'est pas vraiment un arbre, mais à défaut de mieux ...) :

mvn dependency:resolve-plugins

Edit: le gars dit que it is a bad habit to specify plugin versions. C'est évidemment une bêtise.

C'est aussi grâce à eux que #TheDonald sera réélu.

#EfficacitéSur20

Mon problème est le suivant : je veux savoir quels plugins sont utilisés sans déclarer explicitement leur version. Oui, c'est possible, et les devs ne se gènent pas pour le faire.

Du coup, quand je veux réunir la déclaration d'un plugin (et de sa version) dans le pluginManagement du pom parent, le build échoue à répétition car, sans version déclarée explicitement :

• dans la théorie, maven est supposé prendre la toute dernière version disponible d'un plugin;
• dans la pratique, maven prend une version parmi celles disponibles, et parfois des versions très anciennes (de plusieurs années).

Du coup on croit utiliser la dernière version du maven-assembly-plugin (par exemple), et on se retrouve avec une version vieille de 7 ans. Il faut donc dans un premier temps figer les versions utilisées des plugins. Mais pour ça, je ne vois que deux solutions :

• passer en revue à la main tous les POM du projet;
• trouver un moyen d'automatiser la recherche.

J'ai donc trouvé le plugin versions-maven-plugin :

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>versions-maven-plugin</artifactId>
    <version>2.8.1</version>
</plugin>

Et je vais utiliser le goal display-plugin-updates ainsi :

mvn versions:display-plugin-updates

Ca va me sortir (entre autres choses) des warnings pour tous les plugins qui ne sont pas déclarés avec une version.

Le CDC de Colombie Britannique recommande d'intégrer le gloryhole aux pratiques sexuelles sûres afin de se protéger du coronavirus.

L'info date du mois de juillet, mais le site web de l'organisme le mentionne toujours :

Fallait oser.

Comment utiliser un data provider avec JUnit 5.

Dépendance maven :

        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-params</artifactId>
            <version>${junit.jupiter.version}</version>
            <scope>test</scope>
        </dependency>

Pour le reste, le data provider s'écrit comme pour TestNG, mais sans l'annotation @Dataprovider. Exemple :

public static Object[][] sumTestData() {
        return new Object[][]{
            {2, 2, 4},
            {10, 1, 11},
            {1000000, -1000000, 0}
        };
}

Et on utilise le data provider ainsi :

@ParameterizedTest
@MethodSource("sumTestData")
public void dataProviderTest(int a, int b, int expectedSum) {
    Assertions.assertEquals(expectedSum, a + b);
}