Power metal

Comme je l’écrivais hier, j’ai installé un chouette Pi-DigiAMP+ dans mon Raspberry. Et je l’ai testé avec Volumio aujourd’hui. Et bon sang de bois, le son remplit correctement la pièce . Du coup, ça va être bien chouette. La suite ? Connecter les boutons physiques et la télécommande (pour commencer). Bon, par contre, volumio ne […]

MORR POWAH !

Pour ma webradio en cours de rémission, j’avais acheté un petit amplificateur à brancher sur mon Raspberry. Hélas, j’avais oublié que mes haut-parleurs avaient une impédance de 5 ohms … Ce qui faisait que ma carte Pi-DAC+ ne pouvait sortir qu’un son minimal sur ces chouettes haut-parleurs.

Du coup, j’ai dû demander au fournisseur d’échanger la carte (ce qu’il a fait de bon coeur – je dis ça parce qu’il s’agit d’un fournisseur anglais, qui n’est pas à ma connaissance tenu par les lois de la consommation française).

Et j’ai maintenant un amplificateur Pi-DigiAMP+ ! Je ne l’ai pas encore testé, mais je suis déja satisfait du packaging et de la qualité des livraisons. Et demain, je ferais les premiers tests histoire de voir si je peux sortir quelque chose.

Kotlin au chtijug

Première soirée chez Axa, pour découvrir un petit langage qui monte, qui monte.

En introdution

D’abord, si vous voulez comprendre Kotlin, le site du langage est très bien fichu. Et pour aller plus loin, les kotlin koanssont très bien (et c’est vrai, je les ai presque tous fait, et on apprend vite et agréablement les concepts du langage).

Pourquoi Kotlin ?

Plutôt que de nous parler des ses avantages par rapport à Java, Salomon préfère nous indiquer qu’il y a de plus en plus de Kotlin, du coup ça vaut le coup …​ Un argument d’autorité que je rapproche toujours de « 10 millions de mouches à merde en mangent, et toi ? » (la tournure est certes provoquante, mais vous voyez l’idée).

Les avantages de Kotlin sont d’abord qu’il s’agit d’un langage développé par l’industrie, et donc construit selon les besoins de l’industrie. Par exemple, il n’y a pas d’implicites en Kotlin (par opposition au Scala) parce que ça n’est pas vraiment lisible. En revanche, il y a des fonctions d’extension, qui ne valent à mon sens pas beaucoup mieux. Un autre avantage important, c’est l’interopérabilité. Kotlin vise le 100% …​ Comme le Groovy, en fait, mais pas pareil, puisque Kotlin est compilé. Enfin, Kotlin vise la facilité de lecture.

Types

En Kotlin (comme en Pascal) les types sont postfixés. Personnellement, je ne suis pas fan, mais je comprend pourquoi : en Kotlin, les déclarations de type peuvent être inférrées, typiquement dans les instanciations, comme val uri = URI(str). C’est un avantage, tant que votre IDE ne sait pas générer les déclarations de type (ce que fait Eclipse depuis …​ cinq ans, il me semble). En revanche, il n’y a pas de new. Mais du coup, la définition des constructeurs est un peu différente.

Un autre point intéressant est la nécessité de déclarer les types nullables. Par exemple, String ne peut pas être null, mais String? peut l’être. Du coup, l’elvis operator est résolu dès la compilation, ce qui est très chouette. Et le fameux coup de la million dollar mistake du null n’existe plus. A peu près …​

Interopérabilité

L’une des magies de Kotlin est que tous les objets Kotlin, y compris les collections, sont utilisables en Java. L’un décore l’autre. Salomon nous indique d’ailleurs qu’il y a un peu de magie de compilation là-dedans.

Interopérabilité & nullabilité

Comment ça marche quand on crée un type Kotlin non-null (donc sans ?) et qu’on l’utilise depuis du Java, où null est permis dans tous les types. Eh bien tout simplement, la méthode Kotlin est décorée par un code qui vérifie que l’argument n’est pas null, et renverra une KotlinNullException (à peu près) sans qu’on ait à l’écrire dans le code. Du coup, ce qu’il faut retenir, c’est que la nullabilité ne peut être vérifiée qu’en Kotlin. A l’inverse, du code Java appelé depuis Kotlin pourra retourner null. A l’origine, Kotlin utilisait toujours les types nullables, mais ça polluait le code avec des ? partout. Du coup, les concepteurs du langage ont crée le platform type (comme String!) qui ne peuvent pas être créés à la main, et qui peuvent être null. Personnellement, je trouve ça très fâcheux, mais bon, c’est un choix.

A noter qu’il existe un raccourci IntelliJ IDEA permettant de retrouver le type d’une variable …​ Parce qu’on ne l’écrit pas (ce qui en fait démontre que ces types inférrés sont peut-être une idée pas si fameuse que ça …​).

Attention, là, c’est moi qui infère. Pour en revenir à cette histoire de nullabilité avec du Java, il y a quand même un truc louche. Salomon nous explique que Kotlin fait tout pour éviter les NullPointerExcecption, et c’est très cool …​ tant qu’on reste dans le monde Kotlin. Mais manifestement, le monde Java a curieusement bénéficié d’une exception à la null-safety qui vient polluer le monde Kotlin via ces fameux platform types. Et la million dollar error est revenue par là : dès que vous appelez du code Java, vous vous retrouvez, via ces platform types, sensibles à des NullPointerException. Et utiliser du Java depuis du Kotlin, ben ça risque fort de vous arriver …​

Propriétés

Comme dans tous les langages modernes de la JVM, il y a des data class pour écrire plus simplement les Java beans. Même si en Java, on peut aussi écrire un bean sans getter ni setter, parce qu’en fait, si ils ne font rien, autant ne pas les écrire. En tout cas, en Kotlin, si on écrit une variable de classe avec un var, c’est une propriété dont les getter et setter sont générés …​. comme avec Lombok. J’aime beaucoup la justification de Salomon : JetBrains a analysé beaucoup de code Java pour constater que la plupart des attributs sont en fait publics (privés avec getters et setters qui sont, eux, publics). Du coup, le qualificateur par défaut sera public. Donc les getters et les setters sont tous générés, ce qui en fait une forme de taxe …​ A un avantage près : il est toujours possible de surcharger les getters et les setters, avec une syntaxe très proche des properties C#.

Il est également possible de définir les propriétés directement dans la déclaration de classe, ce qui fait de la déclaration de classe un one-liner pour les beans (du moment qu’ils n’ont pas trop de propriétés).

Enfin, il est possible de générer les méthodes hashCode() et toString() en ajoutant le qualifieur data devant le nom de la classe.

Propriétés déléguées

Bon, alors là, c’est un peu tordu. La ligne de code est pourtant simple :

val cm by instance(CredentialsManager::class)

En fait, dans ce cas, les getters/setters implicites de la propriété sont transférés au délégué, qui en fait …​ ce qu’il veut. La doc Kotlin est assez claire, avec quelques exemples communs : lazy, observable, …​

Fonctions

Il est possible d’ajouter une fonction à une classe (ce sont les fonctions d’extension dont je parlais plus haut). Comme par exemple String.toCamelCase(…​.) qui serait une nouvelle méthode de la classe String. En fait, dans ce cas, une méthode statique est générée dans la classe String avec en premier paramètre la chaîne de caractère à transformer. C’est en fait du simple sucre syntaxique.

Ca devient très intéressant quand on utilise ces fonctions avec des types génériques. Très intéressant, ou diabolique. Cela dit, le bon exemple est fun Map.prefixed(prefix: String): List qui retourne les clés d’une map préfixées avec le préfixe fourni en paramètre.

A noter que la fonction doit être importée à part de la classe qu’elle étend …​ si l’IDE la décrit bien.

Lambdas

Kotlin est aussi fonctionnel que Java 9. Bon, ben tout est dit, hein, on a rajouté du fonctionnel sur un langage objet. Comme en Groovy, dans une lambda à un paramètre, on peut ne pas écrire le paramètre et le remplacer par it. Et comme en Groovy également, lorsque la lambda est le dernier paramètre, on ne met pas de parenthèse autour.

DSL

En Kotlin, on ne peut pas déclarer de variables statiques …​ Mais on peut définir des objets spécifiques. Avec ça et les fonctions d’extensions, il est très facile de définir des DSL internes. Si on déclare une fonction infix, elle ne doit avoir qu’un seul argument, mais ça permet de retirer les parenthèses. Encore une fois, Groovy a les mêmes mécanismes.

Surcharge d’opérateur

Comme en Groovy (décidément), si une méthode utilise la signature d’une méthode d’opérateur, on peut utiliser la syntaxe de l’opérateur. Et avec les fonctions d’extension, d’un coup, on peut ajouter des opérateurs à des types (comme par exemple operator fun Date.plus(other: Date): Date {…​}). Ce qui est très chouette (allié à la limitation du nombre d’opérateurs utilisables).

Inline

J’avais dû survoler ça dans la doc : si une fonction a le mot clé inline, son code sera forcément copié dans toutes les fonctions qui l’appellent …​ sauf quand c’est impossible. Par exemple, comme le souligne Logan, une fonction récursive ne devrait pas être inlinable (mais il va vérifier !).

Non-local return

Ca permet par exemple de faire du non-local return …​ Là, honnêtement, j’ai du mal à conceptualiser le truc.

En fait, en Kotlin, les lambdas et les fonctions ne sont pas strictement équivalentes, apparement, et return sort de la fonction englobante. Et il est parfois utile de sortir de la lambda sans sortir de la fonction (même si la dernière instruction d’une lambda est sa valeur de retour).

Types réifiés

En Java, les types génériques ne sont pas réifiés. C’est-à-dire qu’ils sont utilisés lors de la compilation, mais pas lors de l’exécution (Rémi Forax vous expliquerait ça bien mieux que moi). Bon, donc Kotlin permet de déclarer des types réifiés. Par exemple, inline fun typeName() = T::class.simpleName devient typeName() String:::class.simpleName(). Et pour que ça marche, il faut apparement passer par des fonctions inline, sans doute pour que ces fonctions soient appliquées lors de la complation, ce qui semble nous amener dans le domaine de bugs du compilateur C# (je me souviens avoir lu un article qui expliquait qu’à cause de la réification des génériques en C#, il était possible de provoquer des OutOfMemory sur le compilateur C#, mais je ne retrouve pas le lien).

ReactiveX

Si vous connaissez RxJava, c’est plus cool.

Un des trucs marrants, c’est que ReactiveX fournit une gestion du null à travers Maybe

, et non Article?. Alors bon, d’accord, ` null` est une erreur à un million, mais si il y a un million de corrections mutuellement exclusives, je ne suis pas complètement certain que la victoire vaille le combat mené …​

TODO()

En Kotlin, on peut déclarer une fonction sans l’implémenter en écrivant fun my() = TODO(). C’est vraiment très cool !

Retour à ReactiveX

Bon, ben là, c’est de la programmation asynchrone, donc compliquée. Mais simplifiée par les coroutines …​ qui sont simplement des appels à await() après l’appel de fonctions asynchrones.

L’important, c’est que les coroutines transforment du code séquentiel en callbacks …​ grâce au compilateur, qui doit faire quand même pas mal de boulot. Du coup, écrire une librairie qui utilise ces coroutines ne doit pas être simple, mais JetBrains l’a déja fait dans un certain nombre de cas (y compris passer du thread d’affichage Swing à un thread de traitement, ou évidement vert.x).

Plateformes

Kotlin tourne sur

  • La JVM, bien sûr
  • Javascript – on peut même compiler pour du Node, mais franchement, n’en faites pas.
  • WebASM
  • Raspberry, Linux, Mac, Windows, iOS, STM32

L’intérêt de Kotlin dans ce cas est que la cross-compilation est supportée par les concepteurs du langage, ce qui change pas mal des API qui permettent de compiler du code Java pour Javascript, par exemple. C’est un gros argument marketting, clairement. Et c’est aussi assez pratique, même si ça implique quelques changements dans la chaîne de compilation, et du coup, sans doute des adaptations au niveau du code.

La philosophie de Kotlin est de faire le code buisness dans les modules multiplateforme, et de laisser le code système dans les modules plateforme. C’est pas con du tout. Sauf que, par exemple, Date n’est pas multiplateforme, ce qui est vite gênant.

A priori, du code Kotlin natif est vingt fois plus performant que du code compilé pour la JVM …​ Mais ça, je demande à voir (parce que j’ai des convictions assez arrêtées sur les performances de la JVM).

Librairies

Il y en a évidement des tonnes. Salomon choisit de nous parler de Kodein, Kotson, KTOR et autres K* …​ et Spring, hélas. On peut aussi utiliser Spek pour les tests ou Mokito pour mocker (fou, non).

A noter qu’il existe un transpileur Java vers Kotlin dans IntelliJ IDEA …​ mais évidement c’est du code généré.

Conclusion

La présentation était assez riche, mais manquait parfois d’exemples les mains dans le cambouis. Mais surtout, surtout, elle m’a compris de comprendre un truc que je vais essayer d’exprimer clairement (et là, je donne complètement mon opinion sur Kotlin).

Quelles sont les motivations pour créer un langage ?

Pour Martin Odersky et ses amis, clairement, c’était tenter d’injecter dans le monde de la JVM des concepts fonctionnels, et de les marrier proprement avec le monde objet de la JVM.

Pour Groovy, c’était de créer un lanage de scripting pour la JVM qui soit dynamique, extensible, efficace dans l’écriture.

Pour Kotlin, même si j’ai du mal à le reconnaître, l’objectif est avant tout de permettre à JetBrains d’avoir une influence visible sur l’écosystème Java et les écosystèmes natifs. Pour moi, ça apparaît clairement à travers plusieurs éléments : le côté bien trop pragmatique de certaines décisions (typiquement, l’interopérabilité maximale avec la JVM est une bêtise qui fera beaucoup de mal à ce langage). Le pari me semble audacieux, aussi bien pour JetBrains que pour les gens qui miseront sur ce langage : que se passera-t-il quand JetBrains se fera racheter par …​ disons …​ Oracle ?

Les aspects de Kotlin qui sont séduisants peuvent tous être traçés à des langages antérieurs, et en tant que tel kotlin apparaît comme une synthèse. Mais tant qu’à faire dans la synthèse, je pense qu’il vaut mieux miser sur Ceylon, qui est à peu près équivalent conceptuellement, mais qui est, lui, open-source. Alors écidement, Kotlin est soutenu par une entreprise, qui vend un certain nombre de prestations permettant à d’autres entreprises de se sentir en confiance (et franchement, pour Google, le pari sur Kotlin fait figure d’OPA amicale), mais tout ça me met un peu mal à l’aise, e qui paraît évidement curieux pour un vieux développeur Java …​ donc en quelque sorte baigné de force dans le monde Oracle.

Un peu de projets maison

Bon, j’ai craqué. Après des années à tenter de ne pas faire de hacks domestiques, j’ai enfin entamé deux projets auxquels je réfléchis depuis bien longtemps.

Une nouvelle radio

J’ai depuis longtemps une radio web (une Philips NP 3300), qui ne marche plus vraiment depuis des années, et qui traîne dans ma cave. J’en ai déja parlé, je voudrais l’upcycler à grands coups de raspberry. Et pendant longtemps, j’ai procrastiné. Mais en ce mois de janvier (grâce aussi au dynamisme de mes nouveaux collègues), j’ai enfin lancé le projet en achetant une carte son – qui s’est révélé insuffisante – et en commençant à en discuter sérieusement.

C’est assez marrant à réaliser, et même si je n’atteins pas l’objectif final, je vais faire des trucs marrants pour y arriver.

Une souris de présentation

Parce que si tout se passe bien, je risque de faire un peu plus de présentations publiques.

Et quand j’ai vu Hubert Sablonnière présenter avec sa manette de NES, je me suis dit que les souris spéciales Logitech … c’était pas vraiment pour moi. Et comme j’ai quelques Wiimotes chez moi, je me suis lancé dans l’utilisation de wiimote sous Windows (ben quoi ?). Et c’est franchement facile :

  • avec HID Wiimote, mes wiimotes sont reconnues comme des gamepad sous Windows
  • Et avec Antimicro, je mappe mon contrôleur sur le clavier/souris de ma machine.

J’ai déja avec ça de quoi piloter une présentation (j’ai testé). Mais je veux aussi pouvoir déplacer le curseur à l’écran. Et pour ça, encore une fois, il va me falloir un peu d’électronique pour me faire une barre de senseur en USB, que je pourrais coller sur mon écran. Oh, j’ai des instructions, pas de problème. Il me faut juste un peu … de temps.

Bonne année !

Bon, le temps de la trêve des confiseurs est certes passé, et je devrais plutôt me prolonger dans l’avenir. Mais je me dois auparavant de faire un bilan de cette année 2017.

Et si l’année avait plutôt mal commencé, elle a pris un virage sacrément intéressant avec mon arrivée chez Zenika. Et, pour la première fois depuis bien longtemps, je suis dans une boîte où, si il y a des médiocres, je ne les ai pas encore vus. Et ça, c’est spectaculairement intéressant.

Du coup, je me suis retrouvé à apprendre et tenter plein de trucs :

  • Couchbase et OAuth
  • Consul, Traefik, Ansible

Et depuis le début de l’année, j’ai même fait un peu de nginx + lua.

Bref, je me retrouve à faire ce qui fait plaisir à tous les informaticiens du monde : découvrir de nouvelles technologies et tenter de nouveaux trucs. Et qui plus est, je le fais à un âge où, heureusement pour moi, le buzz ne prend plus si facilement que ça. Du coup, j’ai un oeil critique sur tous ces gadgets … critique et parfois même acerbe, c’est vrai. Cela dit, cette critique est parfois fondée quand je vois le buzz qui est fait autour de certains produits quisont loin d’être aussi fameux que ce que la rumeur publique prétend … mais j’y reviendrai peut-être.

Et du coup, 2018 …

2018, ce sera une année … différente.

En 2018, je garantis qu’il y aura enfin des nouvelles de ma radio internet … puisque j’ai acheté un Raspberry et une carte Pi-DAC+.

Il pourrait également y avoir (avec pas mal de chance) une présentation … à DevoxxFr (et si je n’y fait pas de présentation, attendez-vous à voir une bonne grosse rafale d’articles sur toutes les présentations que j’y verrai).

Il pourrait aussi y avoir un retour à Codingame … en Kotlin … ou en Lua, parce que je trouve le langage assez simple et marrant.

Bref, il y aura encore de la vie sur ce blog.

Vavr, tu vas voir !

Merci à Norsys, qui offre le food truck ce soir (!). (par contre, le chauffage semble être mort dans la soirée).

Guillaume nous vient de chez Saagie (où je connais quelqu’un …​ depuis pas mal de temps) dans l’équipe d’outillage. Et quand il parle, j’ai presque l’impression d’entendre parler un collègue tout aussi barbu, mais plus rancheros …​

La programmation fonctionnelle

C’est de la programmation sans effet de bords, et c’est cool. Et pour faciliter ça, les fonctions sont des éléments essentiels du langage, les variables sont immutables (ça n’a pas de rapport avec la programmation fonctionnelle, en vrai, mais ça fait maintenant partie du canon fonctionnel).

Enfin, ce qui est important pour Guillaume, c’est aussi la transparence référentielle (ou referential transparency) qui garantit que deux appels à la même fonction retourneront le même résultat.

Par exemple, Math.random() ne respecte pas cet aspect, mais Math.max(1, 2) oui.

Java 8 est déja fonctionnel ?

Ben oui, avec les lambda, les streams, les Optional<?>, c’est un début. Mais pour Guillaume il manque des trucs.

Vavr …​ anciennement Javaslang

La librairie a été créée par un développeur Scala frustré par Java. Et le nouveau logo retourne joliment Java …​

Les collections Java, c’est pas pratique

Il y en a en java …​ mais c’est loin d’être pratique. Parce qu’à la base les collections sont conçues pour être mutables (et pas parce qu’ils n’ont pas compris l’immutabilité). Autrement dit, elles ne sont pas joliment immuables, ce qui fâche les puristes. Donc vavr redéfinit ses collections (y compris un Vector).

Typiquement, les méthodes Collection.stream() et Stream.collect() n’existent pas en vavr, parce que les collections sont conçues autour de concepts fonctionnels.

Guillaume mentionne ensuite un point intéressant : en programmation fonctionnelle, on n’aime pas trop les exceptions parce qu’elles ne respectent pas trop le flux d’opérations.

Streams inconsistents

Parfois, les streams Java démarrent leurs opérations un peu en avance. Du coup, deux appels successifs à Stream.map`(…​.)` peuvent balancer des exceptions, ce qui est insupportable pour Guillaume …​ Peut-être pas autant pour moi.

Streams de Map

En Java, utiliser un stream sur une map, c’est l’enfer (il faut faire le stream sur l’ entrySet() et reconstruire la Map au moment du collect). Par contre, en vavr, c’est super facile parce que vavr va mapper les couples clé/valeur vers des Tuple.

Value types

Ils arriveront en Java 10, peut-être (il faudrait demander à Rémi Forax). En revanche, il y en a un paquet dans vavr, inspirés de Scala, évidement.

Option

Hey, mais l’ Option de vavr est sérialisable ! C’est très cool !

Try

Qui permet d’encapsuler du code susceptible de lancer une exception. L’exception sera gentiment catchée et conservée. C’est pas bête du tout.

Either

Là, on est en plein dans la scalaterie. Ca permet de retourner deux types différents en disant que le retour est soit l’un soit l’autre. Bon, jusque là, c’ets un tuple. La particularité d’ Either, c’est qu’on prend comme convention que le bon cas est celui de droite …​ autrement dit le deuxième …​ Je trouve ça pénible et un authentique retour en arrière.

Validation

Qui ressemble furieusement à Bean Validation dans l’objectif …​ mais pas du tout dans l’implémentation, puisque c’est encore un Tuple, voire même un Either particulier.

Des fonctions

vavr ajoute aux Function et BiFunction des interfaces permettant d’utiliser jusqu’à 8 paramètres. Ca n’est pas très pur fonctionnellement, mais c’est bien pratique.

Composition

Mais bien sûr qu’on peut composer des fonctions avec vavr !

Lifting

Chez les fonctionnalistes, c’est la transformation d’une fonction impure en fonction pure. Et je dois bien dire que c’est assez propre.

Application partielle de fonctions

Là aussi, ça fait rêver tous les haskelliens, et c’est assez simplement réalisé. Mais mon voisin pose une excellente question : si j’applique ma fonction partielle à 5 paramètres, lequel reste à utiliser ? Le premier ou le dernier ?

Curryfication

A priori, c’est très semblable à l’application partielle, tout en étant subtilement différent.

Mémoisation

Un peu comme un cache, en fait …​ mais sans avoir besoin de réécrire à chaque fois.

Et maintenant, le pattern matching

Alors là ça va être un peu fou …​ Toujours est-il que, vous le savez maintenant, le pattern matching, c’est un switch sous stéroïdes (mais alors beaucoup de stéroïdes). Par contre, comme vavr reste du Java, c’est la syntaxe habituelle qui est utilisée. Et du coup, c’est moins surprenant puisque l’instruction langage est remplacée par des appels de méthode dans tous les sens. Ca n’est pas forcément très lisible à mon sens, mais bon. En revanche, ce qui est vraiment moche, c’est que le cas d’usage typique, c’est pour faire des instanceOf plus propres de la manière suivante :

Number plusOne = Match(obj).of(
    Case($(instanceOf(Integer.class)), i -> i + 1),
    Case($(instanceOf(Double.class)), d -> d + 1),
    Case($(), o -> { throw new NumberFormatException(); })
);

Bon, ben là, franchement, je suis désolé, mais il n’y a aucune espèce de gain par rapport au simple instanceofdans un if (qui est un foutu antipattern).

Par contre, pour filtrer une liste d’adresses entre valides et invalides, c’est pas mal du tout (merci Either).

Property Checking

On parle ici de la génération automatique de cas de tests. Et il y a pour les différents types de variables simples, des générateurs aléatoires inclus. Ca n’est pas inintéressant …​ mais le test est salement pollué par tout le code supplémentaire nécessaire pour gérer ce contenu aléatoire. Il me semble qu’il y a d’autres outils qui fournissent le même genre de services

Conclusion

La présentation était intéressante et Guillaume sacrément motivé pour nous convaincre (et ça, c’est très cool). Néanmoins, je ne peux pas m’ôter de la tête l’idée que vavr est avant tout un exercice de style, une espèce de figure imposée éventuellement utilisable sur un projet, mais dont ça n’est pas le but premier. Pour moi, le but de ce genre de librairie (comme ça a pu l’être quand j’ai écrit gaedo), c’est avant tout de tester la faisabilité d’un concept. Après, pour l’utiliser, il faut quand même avoir des besoins qui sont à mon sens particulier (surtout si quelqu’un veut sortir de Java 8 pour utiliser vavr). L’idée est néanmoins intéressante, et certains aspects m’ont paru particulièrement séduisants.

Keycloak au chtijug

 

 

Thibaut commence par nous présenter KaliCustomer …​ le nouveau nom d’Onyme. Qui fait donc du suivi de la satisfaction client à travers des questionnaires envoyés. Un truc amusant, c’est qu’Onyme est devenu un éditeur de logiciel en 2010, après avoir été longtemps une ESN.

Revenons donc à Keycloak …​

Ca envoie du rêve !

Et commençons donc par une démo. Une démo assez simple, puisque nos speakers vont coder une application Spring Boot …​ depuis start.spring.io (qui fournit un chouette générateur de pom). Donc, après un peu de code, le contrôleur est implémenté avec une vue thymeleaf. Il y a deux ou trois trucs que je trouve un peu moche avec Spring Boot, mais bon …​ pour l’instant ça marche.

On installe ensuite Keycloak, qui est en fait l’outil de sécurité de JBoss Wildfly, et packagé également pour servir des applications externes (heureusement). Du coup, paf, on crée un realm, hop, un utilisateur, boum, on connecte l’application côté Keycloak.

Et ensuite, il faut configurer l’application elle-même. Ce qui est un tout petit peu fastidieux (du moins quand on le présente en conférence). Par contre, d’une façon un peu dommage, la demande d’authentification sur un contrôleur n’est pas dans le contrôleur (sur une annotation, typiquement), mais dans une configuration séparée.

Après un peu de configuration complémentaire, Keycloak intercepte bien les requêtes pour accéder aux pages demandant une authentification.

Du coup, la suite logique, c’est d’avoir un service externe qui fournit une liste de bières à un autre service qui affiche ces bières, les deux utilisant une identité qui est propagée par keycloak.

Et bon, là, on intègre Keycloak dans du nodejs, et c’est à peu près pareil …​ mais plus sale.

Et surtout, ça marche.

Et on passe maintenant au client, en HTML+Javascript (mais sans framework infame). Et pour ça, Keycloak fournit un connecteur Javascript pour les clients directement depuis le serveur, ce qui est assez cool. Et qui permet de garantir que le client utilise la bonne version de l’API de sécurité. Et ça marche …​ simplement (pour du Javascript).

Plus sérieusement

Keycloak est un produit sérieux, avec des connecteurs pour toutes les bases de données, LDAP, Kerberos, …​ Par ailleurs, il supporte OpenID, OpenID Connect, OAuth, et SAML (mais on ne parle pas de SAML). Thomas enchaîne ensuite par une présentation de ces protocoles, que je ne vais pas vous relater ici (parce qu’il y a quand même tout un paquet de sites de qualité sur le sujet). Par contre, je ne connaissais pas JSON Web Keys

Et sous le capot de Keycloak ?

Donc l’interface de saisie est facilement configurable (via des thèmes) et on peut aussi changer la langue de l’interface simplement en activant l’internationalisation. Comme Keycloak est un service d’identité, il est évidement possible de permettre aux utilisateurs de s’enregistrer eux-même (le scénario typique dans un site grand public). Et évidement, la page de création d’utilisateur est fournie par Keycloak …​ Il est évidement possible d’envoyer des mails pour les mots de passe oubliés ou pour vérifier les emails des utilisateurs, mais ça implique d’avoir configuré un serveur SMTP (comme par exemple Fake SMTP Server – bon en fait il y en a plusieurs : en Java (http://nilhcem.com/FakeSMTP/), en .Net (https://fakesmtp.codeplex.com/), très pratique pour le développement). En bonus, lorsque l’utilisateur clique sur le lien de vérification d’email, il est authentifié et connecté à l’application, ce qui fournit une meilleure expérience utilisateur. A part les utilisateurs simples, Keycloak peut aussi utiliser les logins sociaux (GitHub, Google, StackOverflow, …​). Et si votre site préféré n’est pas présent, il est possible de créer une extension Keycloak …​ ou encore d’utiliser les protocoles standard (OAuth, OpenID).

Pour revenir aux cas simples, Keycloak fournit évidement des outils de gestion de qualité de mot de passe. Mais aussi, et surtout, Keycloak met à jour régulièrement sa politique de hashage des mots de passe, et lorsque cette politique change et qu’un utilisateur se logge avec un mot de passe hashé avec un vieil algorithme, il re-hashe le mot de passe avec le nouvel algorithme. Très cool. Un autre truc vraiment très cool, c’est de pouvoir prendre l’identité d’un utilisateur (pour peu qu’on dispose des privilèges suffisants). Et ça, pour les développeurs, c’est quand même super chouette. Et si vous voulez vous compliquer la vie, l’authentification deux facteurs est supportée via FreeOTP ou Google Authenticator.

Conclusion

Certains éléments des démos ont été particulièrement bluffants. Et je l’utiliserai bien …​ si j’avais à développer une solution de gestion de l’identité. Mais ça n’est pas vraiment le genre de projet qui se fait toutes les cinq minutes …​ Sauf dans les petites boîtes.

Scala, c’est l’histoire d’un type

Hier soir, c’était … chtijug !

Et comme je me suis occupé d’aller chercher toutes les bières (et de les servir), je n’ai pas suivi très attentivement la présentation de Valentin Kasas. Pas de panique, j’ai un collègue qui a produit un article de qualité.

Heureusement, elle est là

Et en la lisant, je ne peux m’empêcher d’avoir … certaines opinions.

Et comme je suis généreux, je vais vous les partager, parce que comme le dit l’inspecteur Harry

(je peux pas m’en empêcher)

A travers les différents éléments présentés (pattern matching, destructuring, méthode apply, case class, implicites), on voit bien que les concepteurs du langage ont cherché à mettre en place dans la JVM un langage aux fondations théoriques solides. Mais je crois profondément que l’intérêt d’un langage n’est pas dans ses fondations théoriques. Sinon, ni Python, ni Ruby, ni Java n’auraient percé, et on ferait tous gentiment du LISP, de l’Ada ou du PROLOG. Or ça n’est pas le cas.

Parce que ces langages, théoriquement puissants, manquent d’ergonomie. Et en l’occurrence, le coeur de mon idée, c’est que l’ergonomie de Scala est clairement défaillante. Défaillante, parce qu’il y a des tonnes de choses qui me semblent implicites, et d’autres qui sont vraiment à la limite de l’overengineering. Sans compter tous ces moments douteux où on sent bien la volonté de faire de « l’avant-garde ».

Bref, Scala, ça n’est pas trop ma came. Heureusement, je crois qu’on aura une présentation de Kotlin bientôt, qui m’a nettement plus intéressé pour l’instant.

Le loup de Wall Street

Lundi soir, j’ai regardé le loup de Wall Street. Un film qui a une sacrément bonne réputation.

Et honnêtement, le spectacle est saisissant. Un peu comme dans Wall Street, le personnage de Jordan Belfort y est décrit comme une espèce d’escroc boursicoteur, qui mise sur la stupidité de ses clients pour se faire des tonnes de pognon. Mais là où Gordon Gekko est décrit comme une espèce de reptile parasite, cet escroc-ci essaye de construire des choses : une famille, une entreprise, une culture. Bref, il a des aspirations qui le rendent attirant aux yeux du spectateur, ce qu’amplifie une mise en scène et un ensemble de dispositifs dénotant la maestria de Scorcese.

Mais, il y a aussi la drogue omniprésente et les femmes nues, éventuellement représentées en position de trophées. Bon, la drogue fait partie d’un imaginaire du trader bien connu, je ne m’attarderais pas trop dessus.

Par contre, les femmes nues … Je n’en peux plus.

Dans un film de trois heures, je dirais qu’il y a facilement 1/4 d’heure, voire 1/2 heures montrant des femmes plus que déshabillées. Et, collision intéressante de calendrier, ça arrive au même moment que les terribles histoires d’Harvey Weinstein, et le plus terrible encore #dénoncetonporc de Twitter. Du coup, je ne vais vous dire que ce film est avant tout une galerie permettant à de vieux producteurs dégueulasses de faire leur marché de jeunes actrices … Mais la défense de DiCaprio (que vous trouverez à la fin de ce chapitre de l’article Wikipedia) ne tient simplement pas : Scorcese et DiCaprio sont clairement fascinés par le personnage, et son apparente chute est montrée juste pour servir de « cache-sexe » devant l’obscénité du personnage présenté. Et de la part d’hommes de pouvoir dans le milieu d’Hollywood depuis vingt ans, ça devient particulièrement répugnant.

J’ai même en fait assez honte d’avoir regardé ce film bien filmé, mais idéologiquement pourri jusqu’au coeur. Franchement, le même film, tourné du point de vue de l’agent du FBI, m’aurait sans doute bien plus séduit.

Ah, et au fait, si vous pensez que c’est une montée de féminisme, elle n’est pas si récente, puisque j’ai aussi arrêté de regarder Game Of Thrones après la première saison à cause des femmes nues jetées à l’écran par HBO pour distraire le spectateur. La seule chose qui vaudrait le coup, ce serait une parité dans cette exposition frontale de nus : voir autant d’hommes que de femmes, ça aurait du sens en 2017. Ne montrer que de femmes, c’est se contenter d’une vision rétrograde de la beauté physique, et considérer les femmes comme des objets de concupiscence plutôt que comme une partie du public, c’est idiot, primaire et dépassé.

Hellboy

J’ai revu hier soir Hellboy.

Bon, dit comme ça, ça n’est pas très impressionant.

Mais … J’ai également lu plusieurs fois les comics dont ce film est tiré (j’ai d’ailleurs acheté le premier tome suite à un premier visionage de ce film). Et si j’avais donné mon avis sur Goodreads suite à cette première lecture, je crois que le film mérite deux ou trois mots.

D’abord (et à mon avis ça compte pas mal) visuellement : comment recréer le style incroyable de Mignolia au cinéma ? C’est impossible. Donc le réalisateur n’essaye pas trop (sauf dans un plan nous montrant les neuf qui sont un). Et il a raison, puisque l’ambiance est visuellement très différente, mais pas inintéressante … Pas inintéressante, mais pas suffisante pour rendre le film inoubliable.

Ensuite, il y a le casting. Ron Perlman qui cabotine pour donner un Hellboy peut-être un peu caricatural n’est pas mauvais du tout dans le genre bougon, mais je crains qu’il manque d’une certaine forme de finesse au moment de faire le choix qui va détruire le monde … ou pas. C’est dommage, parce qu’il est correctement massif, mais ne présente peut-être pas la bonne … faille. Dans le reste du casting, l’agent Myers qui n’est pas dans les comics est un ajout sympathique, une espèce de témoin d’humanité au milieu de la folie du BRPD qui nous relie un peu à ces marginaux. Et puis Liz Sherman … est aussi brillante qu’il le faut. Quant aux méchants, je trouve Raspoutine toujours aussi difficilement perceptible (au sens où ses motivations apocalyptiques sont totallement incompréhensibles), mais l’acteur le rend aussi inhumainement méchant qu’il est nécessaire. Et sa comparse Ilsa Haupstein est également bien campée. Bref, tout ça tourne bien … sauf pour la faute d’intelligence qu’est le chef du BRPD : lâche politicard quand Hellboy est une quête philosophique, il ramène des préoccupations bien trop prosaïques pour être utiles.

Parce qu’en vrai, le secret de cette oeuvre aussi bien au cinéma qu’en comics, c’est que c’est une oeuvre sur la réalisation de soi, quand bien même ça va à l’encontre de ce que veut l’univers. Le courage, c’est parfois refuser. Et ça, quel que soit le média, c’est le coeur de cette oeuvre, et il est bien passé hier soir.