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.
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 :
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 :
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);
}
Une nouvelle histoire de l'Odieux Connard !
J'ai lu il y a quelques jours que si les élections devaient avoir lieu maintenant, on retrouverait Macron et LePen au second tour (et sûrement Mélenchon et un mec de droite en troisième et quatrième places). Je trouve ça réconfortant, car ça confirme le choix des Français pour une politique à l'américaine où chacun s'occupe de son petit nombril.
Remarquez, ça fait 50 ans que ça dure. A un moment donné il faut se rendre à l'évidence. Les Français ne veulent pas d'un système par répartition, où les richesses du pays sont mises à contribution pour soulager la population. Les grands services publics mis en place après la guerre n'ont finalement été qu'une anomalie de parcours, et tout est fait pour les faire disparaître.
Si les Français ne veulent pas se battre pour conserver leurs conquis sociaux, pourquoi faudrait-il le faire à leur place ?
Quand on apprend qu'il faut acheter un timbre à 25 euros pour pouvoir faire une déclaration de perte de carte d'identité (sans quoi la nouvelle ne peut pas être créée) ...
Objectif : extraire un fichier de sous-titres d'un fichier mkv et le convertir en srt.
ffmpeg -i mon_fichier.mkv
Stream [#0:XX](https://animal.cakeozolives.com/./add-tag/0:XX).... Par exemple :Stream #0:9(fre): Subtitle: hdmv_pgs_subtitle
C'est le flux de sous-titres que je veux extraire. C'est le 9ème, et c'est un flux de sous-titres au format image.
Note :
Subtitle: subrip signifie que le flux de sous-titres est au format texte;Subtitle: hdmv_pgs_subtitle signifie que le flux de sous-titres est au format image.Comme mon flux contient des sous-titres au format image, je dois demander à ffmpeg de simplement extraire (copy) le flux de sous-titres numéro 9 (-map 0:9) dans un fichier nommé sub.sup :
ffmpeg -i mon_fichier.mkv -c copy -map 0:9 sub.sup
Note : pour extraire un flux de sous-titres au format texte, la commande est identique à ceci près qu'il faut indiquer un format de sortie adéquat (ex: sub.ass ou sub.srt). En effet, le format de sortie est déterminé par ffmpeg selon l'extension du fichier de sortie.
Dernière étape, je dois convertir ce fichier de sous-titres au format image (sub.sup), en sous-titres au format texte (sub.srt). Pour cela, je peux m'amuser avec mkvtoolnix, ou bien je peux aller sur ce site :
Convert;Edit : la conversion du fichier de sous-titres au format image en sous-titres au format texte implique le traitement du premier par un outil de reconnaissance de caractères (OCR). C'est pour ça que le choix du site web m'a paru le plus rapide à utiliser. Sinon il faut choisir le bon outil de OCR pour mkvtoolnix et faire des tests...
Ajouter dans la balise build le plugin spring-boot-maven-plugin ainsi :
<build>
...
<plugins>
...
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.3.3.RELEASE</version> // or your version
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Tous les mots-clefs utilisables pour créer les méthodes findByXXX de JPA.
@Antichesse Oui il était tard, bien vu. Bien sûr qu'il faut pousser sur maBranche sur le remote. C'est corrigé.
Pour squash et rebase :
1) Se placer sur la branche master (ou main si ça vous chante) et la mettre à jour :
git checkout master
git pull origin master
2) Se placer ensuite sur la branche à rebaser :
git checkout maBranche
3) Décider du nombre de commits à squasher (ici 5) :
git rebase -i HEAD~5
Ou trouver le hash du commit précédant le premier commit à squasher :
git rebase -i b0ce09a46ae1e130141f11841cd66db000a4712b
4) Pousser le code sur le remote :
git push --force origin maBranche
5) Ne pas hésiter à remettre à jour la branche master. Puis revenir sur la branche maBranche et rebaser sur master :
git checkout master
git pull origin master
git checkout maBranche
git rebase master
6) Résoudre les conflits de merge avec l'éditeur de texte qui va bien, puis pousser vers le remote :
git push --force origin master
7) Finalement, retourner sur la branche master, merger la branche maBranche et pousser les commits vers le remote :
git checkout master
git merge maBranch
git push origin master
Voilou !
Un aide-mémoire sur les caractéristiques et les attendus des différentes requêtes sur une api RESTful.
La simple mention de Georges Soros a immédiatement valu à Newt Gingrich d'être censuré par les intervenants de l'émission. Pour info, il souhaitait parler du financement par Soros des campagnes de procureurs à travers tout le pays, dans le but avoué de "remodeler le système de justice Américain". Lesquels procureurs "progressistes" sont encouragés à réduire les peines de prisons voire même à les supprimer. Gingrich allait évoquer les conséquences des mesures prises par les procureurs Soros-compatibles sur la criminalité en hausse actuellement, et sur l'impunité qui règne en ces temps de BLM, quand il s'est fait sèchement coupé la parole.
Un exemple de mise en place de relation many-to-many.
Sources disponibles ici
Encore une surprise fumante de JPA.
Dans mon cas il s'agissait d'une relation many-to-many. Et l'erreur rencontrée était en effet une récursion infinie, qui concrètement se matérialisait par l'envoi d'un JSON dans lequel une ressource A contient une ressource B, qui est contenue par ressource A, qui contient une ressource B ...
Le plugin RESTED m'indiquait gentiment que du fait de la taille excessive (>20ko) du JSON, il devait enlever la coloration syntaxique.
Bref.
Pour résoudre le problème, il faut ajouter une annotation @JsonIgnore au dessus de l'attribut annoté @ManyToMany de l'une des deux entités de la relation l'entité owner de la relation (Edit: merci @Antichesse).
Plus d'explications ici