Je cherche à comprendre comment charger le navigateur embarqué de Java FX dans un client lourd. Je ne sais pas si ce projet fonctionne mais ce sera un premier pas vers l'obtention d'un PoC qui marche.

Je suis tombée sur cet autre repo qui a deux avantages :

1. Il va droit au but en affichant un index.html
2. Il s'appuie sur les modules de Java 9+

Merci à Kalvn pour le lien.

Avant ces vacances de Noël, on m'a confié la tâche de déterminer quelle techno utiliser pour coder plusieurs fronts.

J'avais regardé les frameworks SPA via Aurelia et Vue et les pages générées côté serveur via Twig que j'ai toujours adoré 😍.

Ce tuto de Kalvn tombe à point nommé puisqu'il complète très bien l'usage de la balise <template>.

Apprendre à se laver les mains.

Aujourd'hui j'ai relu un cours de @Kysofer qu'il prépare sur la bonne utilisation des monades en programmation fonctionnelle et ça m'a donné envie de le résumer en un cas d'école clair et simple.

Pour la petite histoire et depuis Java 8, je vois apparaître des Optionals partout mais 99% des développeurs n'ont pas compris comment s'en servir (c'est pour cette raison que je dis souvent que la programmation fonctionnelle est un cancer métastasé, car une fois ces mauvaises pratiques installées, le code devient alors incurable). #Sadness

Bref, c'est partie pour une explication claire et courte... Notre cas d'école sera le suivant :

Une Personne possède une Date de Naissance, cette date contient elle-même une Année de Naissance qui contient à son tour une valeur (logée dans un Integer).

L'objectif est d'imprimer l'année de naissance si elle existe sans jamais écrire le moindre 'if' pour l'exécution ci-après déclarée dans la méthode main().

La méthode main() :

class Main {
    public static void main(String[] args) {
        optionalPrintln(Optional.ofNullable(new Person(new BirthDay(new YearOfBirth(2000)))));
        optionalPrintln(Optional.ofNullable(new Person(new BirthDay(null))));
        optionalPrintln(Optional.ofNullable(new Person(null)));
    }
}

La sortie attendue dans la console doit être celle-ci

2000

Étape 1 - Les classes/structures de données Person, BirthDay et YearOfBirth

class Person {
    private final BirthDay birthDay;

    public Person(BirthDay birthDay) {
        this.birthDay = birthDay;
    }

    public Optional<BirthDay> getBirthDay() {
        return Optional.ofNullable(birthDay);
    }
}

class BirthDay {
    private final YearOfBirth year;

    public BirthDay(YearOfBirth year) {
        this.year = year;
    }

    public Optional<YearOfBirth> getYearOfBirth() {
        return Optional.ofNullable(year);
    }
}

class YearOfBirth {
    private final int year;

    public YearOfBirth(int year) {
        this.year = year;
    }

    public Optional<Integer> getValue() {
        return Optional.of(year);
    }
}

Étape 2 - Ce qu'il ne faut pas faire

Les 9-10ième des développeurs Java que je côtoie écriront ce genre de code pour la optionalPrintln(Optional<Person> option) :

class Main {
    // ...

    public static void optionalPrintln(Optional<Person> option) {
        if (option.isPresent()) {
            Person person = option.get();

            Optional<BirthDay> birthDay = person.getBirthDay();
            if (birthDay.isPresent()) {

                Optional<YearOfBirth> yearOfBirth = birthDay.get().getYearOfBirth();
                if (yearOfBirth.isPresent()) {

                    Optional<Integer> year = yearOfBirth.get().getValue();
                    if (year.isPresent()) {
                        System.out.println(year.get());
                    }
                }
            }
        }
    }
}

C'est très moche, c'est très compliqué et ça n'est pas fonctionnel du tout ! Pire encore, certains développeurs écriront ceci :

year.ifPresent(it -> System.out.println(it));

à la place de ce dernier 'if' :

if (year.isPresent()) {
    System.out.println(year.get());
}

tout en croyant coder en fonctionnel, or ça n'est pas le cas du tout non plus ! Croire que l'on fait bien alors que l'on fait mal, c'est en ce sens que la chose est pire AMHA.

Étape 3 - Ce qu'il faut faire

La programmation fonctionnelle ne cherche pas à représenter des instructions, c'est-à-dire une succession d'actions techniques qui s'enchaînent mais a contrario, elle cherche à représenter un flux de conversion, c'est-à-dire le fait de passer d'un type A à un type B.

L'API permettant une telle prouesse réside dans le map de la stream API, or cette fonctionnalité n'est pas applicable à un objet composé comme c'est le cas du Optional puisqu'il s'agit d'un arbre à deux niveaux sur une seule branche.

Dans ce cas, il faut utiliser la méthode flatMap() de la même API pour supprimer le niveau superflue de l'arbre et accéder directement à la donnée si elle n'est pas null.

Ce qui donne le code suivant :

    public static void optionalPrintln(Optional<Person> option) {
        option.flatMap(it -> it.getBirthDay())
              .flatMap(it -> it.getYearOfBirth())
              .flatMap(it -> it.getValue())
              .ifPresent(it -> System.out.println(it));
    }

Explication

A chaque invocation de flatMap(), cette méthode va jouer pour nous un optional.ifPresent(it -> ...) afin de nous en décharger. Si rien n'est présent, alors l'évaluation du flatMap() lui succédant ne se fera tout simplement pas car le flux d'instances à convertir d'un type à un autre type sera dépourvu de toute instance à convertir. #Malin

Et c'est comme cela que l'on code en fonctionnel avec les Optionals ! Le véritable but étant de ne jamais s'en servir explicitement.

Remarque :
La programmation fonctionnelle est extrêmement difficile car elle oblige les développeurs à passer du stade "je dis à la machine comment faire" au stade "je décris à la machine quoi transformer et vers quoi d'autre".

Depuis ces 20 dernières années, j'ai toujours constaté que moins de 5% des développeurs étaient capables de penser dans ce paradigme et parmi ce petit pourcentage, à peine la moitié s'en servira dans sa vie professionnelle.

Mais cet article est excellent !

Merci à @Sebsauvage pour sa doc et @Shikiryu pour le lien.

J'avais déjà expliqué mon désamour pour Kafka ici mais comme toujours, le client est roi et des architectes poussent cet outil même si leurs besoins en terme de charge et de volume ne sont pas suffisamment élevés pour justifier Kafka.

Ici, un bon article expliquant les stratégies de partitionnement des topics Kafka. Merci à son auteur, ça m'aide.

P.S : au regard de ma critique vive de Kafka, cet outil possède un avantage qui est extrêmement intéressant : le découplage temporel, c'est-à-dire qu'en forçant l'asynchronisme des messages, Kafka retire du SI les problèmes d'indisponibilités des services appelés, et ça c'est une très bonne chose (que l'on peut toujours compenser par un cluster de micro-services + Kubernetes mais bon).

Pour @Lenny et @Kysofer qui doivent se servir de Netty.

EDIT 5: un cinquière tuto ici.

EDIT 4 : un quatrième tuto ici.

EDIT 3 : un troisième tuto ici.

EDIT 2 : un deuxième tuto ici.

EDIT : je viens de tomber sur ce tuto et quand je lis ce genre de code :

import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.handler.codec.http.websocketx.BinaryWebSocketFrame;
import io.netty.handler.codec.http.websocketx.CloseWebSocketFrame;
import io.netty.handler.codec.http.websocketx.PingWebSocketFrame;
import io.netty.handler.codec.http.websocketx.PongWebSocketFrame;
import io.netty.handler.codec.http.websocketx.TextWebSocketFrame;
import io.netty.handler.codec.http.websocketx.WebSocketFrame;

public class WebSocketHandler extends ChannelInboundHandlerAdapter {

    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) {

        if (msg instanceof WebSocketFrame) {
            System.out.println("This is a WebSocket frame");
            System.out.println("Client Channel : " + ctx.channel());
            if (msg instanceof BinaryWebSocketFrame) {
                System.out.println("BinaryWebSocketFrame Received : ");
                System.out.println(((BinaryWebSocketFrame) msg).content());
            } else if (msg instanceof TextWebSocketFrame) {
                System.out.println("TextWebSocketFrame Received : ");
                ctx.channel().writeAndFlush(
                        new TextWebSocketFrame("Message recieved : " + ((TextWebSocketFrame) msg).text()));
                System.out.println(((TextWebSocketFrame) msg).text());
            } else if (msg instanceof PingWebSocketFrame) {
                System.out.println("PingWebSocketFrame Received : ");
                System.out.println(((PingWebSocketFrame) msg).content());
            } else if (msg instanceof PongWebSocketFrame) {
                System.out.println("PongWebSocketFrame Received : ");
                System.out.println(((PongWebSocketFrame) msg).content());
            } else if (msg instanceof CloseWebSocketFrame) {
                System.out.println("CloseWebSocketFrame Received : ");
                System.out.println("ReasonText :" + ((CloseWebSocketFrame) msg).reasonText());
                System.out.println("StatusCode : " + ((CloseWebSocketFrame) msg).statusCode());
            } else {
                System.out.println("Unsupported WebSocketFrame");
            }
        }
    }
}

J'ai juste envie de pleurer (et je vais vous expliquer pourquoi). La programmation orientée objets reposent sur trois principes :

1. L'encapsulation.
2. Le polymorphisme.
3. L'héritage (mais il faut l'oublier car c'est un anti-pattern).

Le polymorphisme, c'est le fait qu'une classe fille puisse se faire passer pour sa classe mère. L'idée étant que l'on doit organiser notre code de telle sorte que nous puissions TOUJOURS utiliser les super-types (classe mère abstraite ou interface). Or dès que l'on doit ajouter des conditions du type truc instanceof Class c'est que l'on passe à côté du principale intérêt du polymorphisme : ne jamais avoir besoin de dépendre des implémentations.

Soyons clair, dans un code orienté objet je n'ai jamais eu besoin d'écrire des instanceof et de toute ma vie, ce n'a dû m'arriver qu'une ou deux fois et parce que je dépendais d'un code aussi vieux que Java lui-même !

Bref, si vous codez en Java et que vous avez besoin des implémentations, pis encore des instanceof et des casts, alors c'est que vous pensez en procédural et non en objet. Et pour tout ceux qui souhaitent apprendre à penser en objet, je les renvoie aux formations de Kysofer (car il m'a promis une com' si vous y aller de ma part :D) et il y a la pré-collection automne de Sezane qui me fait grave de l’œil si vous voulez...

J'avais entendu le nom il y a quelques années mais n'ayant pas plus creusé le concept je l'avais oublié. Le hasard du destin me fait retomber dessus aujourd'hui. Bref il s'agit de 9 règles de programmation à appliquer.

En résumé :

1. N'utiliser qu'un seul niveau d'indentation
2. Ne pas utiliser le mot-clef ELSE
3. Encapsuler toutes les primitives et les String dans des objets
4. Encapsuler les collections dans des objets
5. N'enchaîner qu'un seul point (ou flèche) par ligne
6. Ne pas utiliser d’abréviations
7. Garder des classes petites (moins de 50 lignes)
8. Aucune classe ne doit avoir plus de deux instances en guise de variables
9. Ne jamais utiliser de Getter/Setter

Globalement, je le fais sans m'en rendre compte, mes classes sont minuscules (20 lignes en moyennes). Éventuellement le ELSE m'est encore utile mais c'est vrai que programmant en fail-first je lui préfère un throw direct et donc qu'il n'apparaît vraiment pas souvent.

Je me le note, merci à JcFrog pour le lien.

Il y a plusieurs façons de faire, mais lorsqu'il s'agit de remplir un placeholder d'un input text, cette méthode marche plutôt bien :

<input type="text" i18n="[placeholder]my-i18n-key" />

L'attribut qui se fera injecter le i18n doit être mis entre crochet [ ] et s'il y en a plusieurs, alors ils doivent être séparés par des virgules s'ils possèdent la même valeur ; ou par des points-virgules s'ils possèdent chacun une valeur différente.

Par exemple :

<!-- Les deux attributs posséderont la même valeur i18n -->
<input type="text" i18n="[placeholder,aria-placeholder]my-i18n-key" />

<!-- Chaque attribut possédera sa propre valeur i18n -->
<input type="text" i18n="[placeholder]my-i18n-key;[aria-placeholder]my-other-i18n-key" />

Aurelia est un framework à la fois simple et élégant.