Je résume la conférence (qui est incroyablement drôle pour une TED) :

• Montrer de la gratitude (3 fois / jour)
• Écrire, tenir un blog (journaling)
• Faire de l'exercice
• Pratiquer la méditation
• Prodiguer des actes aléatoires de gentillesse

En contrepartie : vous sera plus intelligent, plus vif d'esprit et d'une manière général vous vous sentirez heureux.

Ok je suis convaincue. Je passe sous la police de caractère JetBrains Mono dans la journée.

En test rapide, la lecture est incroyablement plus rapide et agréable.

Au début il ont dit "En Marche" mais après ils ont crié "Chargé"

Tout est vrai, mais la plupart des gens refusent d'admettre que la police française soit l'une des plus violente au monde ! Je vous invite à lire le texte de Frédéric Lordon que je link dans ce post.

Assez simple en fait, il suffit de réunir ces facteurs :

• Câble réseau court.
• Pas de routeur (connexion ad hoc par câble).
• L'option TCP_NODELAY activée.

Et dans l'ensemble, puisqu'en loopback le même CPU calculera les checksums et les handshakes que font deux machines en temps normal, alors la boucle locale sera plus lente.

Chaque citoyen trouvera un intérêt personnel à lire ce texte de Frédéric Lordon (dont j'apprécie toujours autant le style). Il y décrit à merveille ce qu'est devenue la police chinoise française...

Je vous invite à lire ce post visant à expliquer comment programmer en orienté objet une partie de tennis...

Eh bien sachez que rien de ce qu'à écrit le monsieur n'est orienté objet ! Quasiment tout le code est procédurale et impératif, ses objets (Joueur, Partie, etc) sont en réalité des structures de données comme en C dans lesquelles n'importe quelle valeur peut être modifiée depuis une classe extérieure via un setter.

Je rappelle que le concept fon-da-men-tale de la POO c'est l'encapsulation. Si vous n'encapsulez rien, alors vous faites du procédural et vous vous échinez à mettre en place des getters et des setters certainement pour avoir bonne conscience bien qu'en réalité, un attribut public fasse la même chose.

Wouah !!! Ce poste du Gorafi résume tellement bien le principe de négociation de la réforme des retraites.

Je cite :

De son côté la CDFT s’est félicitée du retrait de l’homicide, soulignant que rien ne s’oppose désormais à l’arrachage des dents sans anesthésie qui avait été proposé. #Retraites

Je rappelle qu'il ne faut pas supprimer que l'âge pivot (qui est un leurre), mais aussi la retraite par points qui reviendrait à supprimer totalement la répartition.

Merci à Neko pour le lien.

Lisez cet article si vous le pouvez.

En voici un résumé des idées que je partage totalement tant sur leur fond que sur leur forme :

• Travailler moins longtemps c'est travailler moins tout court. En ce sens, augmenter le nombre d'annuités revient strictement au même que revenir à la semaine de 44 heures. Qui souhaite ça ?

• Augmenter l'âge de départ à la retraite revient à augmenter le nombre d'actifs dans un pays déjà saturé et dont la conséquence est déjà ~9 millions de chômeurs toutes catégories confondues (en général les TF1 like ne parlent que de la première catégorie autour des 3,5 millions). Qui souhaite augmenter le chômage dans le pays ?

• Inciter les plus riches à ne plus cotiser dans le système par répartition (avec la réforme cotiser au-dessus de 10K€ / mois ne sera plus comptabilisé pour votre retraite) implique que ce dernier sera déficitaire et donc incapable de subvenir au besoin, imposant de facto la retraite par capitalisation. Qui souhaite que sa retraite soit jouée sur les marchés financiers avec toutes les incertitudes que cela comprends ?

Bon, je suis en plein débat avec @Philou et @CCous pour savoir si oui ou non il faut commiter les changements de version de la balise <version> de nos pom.xml.

En quoi y a-t-il débat ?

C'est assez simple, je suis partisane du fait qu'il soit nécessaire de commiter le numéro de version des pom.xml et de tagger le commit qui contient cet incrément. Je ne crois pas qu'il faille le faire pour tout, mais la chose est indispensable a minima pour les libs.

Mon argument est que Maven doit être indépendant du gestionnaire de version qui dans l'histoire a changé de nombreuses fois. Pour info, j'ai eu la "chance" de coder sur un projet qui est passé dans cet ordre de Synergy à SVN puis à Git en moins de deux ans ! #TropBien

Bref, le script pour la conf de build sont des sources et il est normal de les tagger avec le code d'autant qu'il s'agit du comportement de base de l'outil.

L'argument que m'oppose @Philou (en dehors du el famoso c'est le progrès faut faire avec son temps), c'est qu'une release consomme énormément de temps de build au niveau des serveurs d'intégration continue, d'autant plus qu'une release exécutée avec le maven-release-plugin impose de rebuilder deux fois la même chose.

Et mon problème c'est que je suis à la fois d'accord avec @Philou mais je suis aussi d'accord avec moi-même ! #SaletéDeSchizophrénie

Donc j'ai décidé de creuser la question afin d'avoir le meilleur des deux mondes qui consisterait :

• À préserver un numéro de version unique, commun à tous les outils et parfaitement tenu à jour.
• À ne pas augmenter inutilement la charge des serveurs d'intégration continue qui sont souvent à la limite de la rupture. (Pour info, les jobs de build de @Philou durent plus de 6h... Juste un job oui... Donc l'argument du "faut pas rebuilder" est indiscutable)

Solutions possibles

La solution de @Philou et @CCous consiste à ne plus toucher aux versions des POM, mais qu'au moment de la publication dans Nexus ou Artifactory, le haché du commit soit récupéré ainsi que la date du jour et le nom de la branche pour construire un numéro de version unique à base d'une grosse concaténation afin d'estampiller ce dernier dans le répo d’artefacts.

J'oppose à cette bidouille une toute autre bidouille : lors de la release on incrémente le numéro de version mais on ne rebuild pas le code, à ce moment on se contente de récupérer le jar du commit précédent pour le republier sous un nouveau nom. De cette façon le numéro de version de Maven est bien incrémenté et les temps de build du CI restent courts y compris pendant la release (j'en ai déjà parlé avec @Kysofer et il va peut-être nous pondre un plugin Maven).

NDR : soyons clairs, tout cela relève de la grande bidouille mais quand il faut y aller il faut y aller.

En quoi consiste le lien ?

Simplement pour notifier tout le monde que nous ne sommes pas les seuls faisant face à cette problématique et que depuis Maven 3.5.0 trois properties ont été ajoutées afin de faciliter le travail :

• ${revision}
• ${sha1}
• ${changelist}

Ce qui va nous intéresser c'est la property ${revision}, en effet un POM et son enfant ressembleront à ceci mais en contrepartie il faut alimenter le numéro de version dans la ligne de commande en écrivant :

mvn -Drevision=1.0.0-SNAPSHOT clean install

De cette façon, un pom.xml ayant le bon numéro de version sera bien généré par Maven, en parallèle le numéro de version ne requiert plus une procédure de commit redondante qui rallongerait les temps de build, le numéro de version peut devenir dynamique et injectable via le C ; et puisque l'on s'inscrit dans ce que propose Maven alors si un développeur voit ${revision}, il saura que le numéro de version est dorénavant injecté au build et donc qu'on ne tord plus le coup à l'outil pour produire des révisions fictives dans un référentiel de binaires au détriment de la cohérence.

Je dirais que la contrepartie c'est de systématiquement publier le jar des sources avec le jar exécutable afin de préserver la corrélation entre version des sources et version du pom.

Je conclurais en affirmant que les problématiques de build sont pénibles et s'apparentent à de la botanique ! (c) @Chlouchloutte

Pour @Lenny, une liste des frameworks Java / Kotlin permettant de générer des PDF.

Dont celui-ci qui propose quelques exemples assez simples pour bien commencer.