Mais alors les interfaces fluentes, c’est mal ?

J’ai lu cette semaine un article intéressant de Yegor.

Vous ne connaissez pas Yegor ? vous devriez. C’est LE défenseur ultime de la programmation orientée objet jusqu’au-boutiste. En fait, il est à peu près aussi fanatique que les fonctionnalistes les plus atteints. Donc, Yegor a écrit cette semaine un article assez chouette sur les interfaces fluentes et leur intérêt … ou pas … pour la programmation. Plus particulièrement, il critique leur maintenabilité dans cet article : Fluent Interfaces Are Bad for Maintainability. Lisez-le, c’est très chouette.

Et ensuite, laissez-moi vous parler d’un sujet apparemment décorrélé. Est-ce que vous avez déja entendu parler des Norman Doors ? Il y a plein de vidéos qui en parlent. Mais j’ai découvert ce sujet grâce à cette vidéo

Dans cette vidéo, un passage m’a éclairé. Lorsque Don Norman noçus parle du bon design comme étant découvrable, ça m’a frappé.

La première fois que j’ai conçu une interface fluente, c’était dans gaedo (enfin, dans ses prédécesseurs, mais ça ne compte pas vraiment). L’objectif, c’était d’avoir une API de persistance dans laquelle tous les éléments puissent être découverts grâce à la complétion de l’IDE. En particulier, les paramètres de recherche décrits dans l’article compilable queries, a senseless concept sont tous découvrables dans l’IDE, ce qui revient à dire qu’à partir du moment où vous tapez le nom de votre service, toutes les opérations subséquentes peuvent être découvertes à partir de la complétion de l’IDE. Et c’est vraiment cool. Mais est-ce que c’est vraiment mauvais pour la maintenabilité ?

Dans gaedo, un peu, parce que je n’avais alors pas réfléchi à ça.

En revanche, dans les APIs fluentes que j’ai écrit ensuite, j’ai utilisé une méthode un peu plus structurée qui évite le phénomène dont il parle. Cette méthode est assez simple : la méthode de départ de l’API fluente doit retourner des éléments qui sont décrits par des classes internes – voire même des classes spécifiques. Mais surtout, surtout, ne polluez pas vos classes importantes avec le code de votre API fluente. Parce qu’effectivement, l’API peut changer (honnêtement, ça ne devrait pas être le cas, mais l’évolution n’est pas non plus un mal), mais son changement ne doit pas corrompre votre code « important ».

En quoi est-ce que ça contrarie la réflexion de Yegor ?

Eh bien, Yegor, lui, jette comme toujours le bébé avec l’eau du bain et dit que, si les API fluentes sont mauvaises, elles doivent donc être remplacées par des enchaînement de création d’objet. Ca donne un résultat aussi laid que les API fonctionnelles dégueulasses. Et surtout, ça montre une chose claire : faire quelque chose de pur (en termes objets comme fonctionnels) donne souvent un résultat peu utilisable. Autrement dit, l’orthodoxie la plus pure donne rarement un résultat agréable.

Publicités

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.

Je ne suis pas hypersonic sur CodinGame

Depuis deux ou trois semaines, avec quelques collègues, nous avons créé des comptes CodinGame et nous nous sommes lancé dans les jeux pour programmeurs qui y sont disponibles.

Au début, c’était simple …

Et puis, il y a deux semaines, ils ont lancé Hypersonic. Bon, hypersonic, c’est pas bien compliqué, c’est faire jouer un bot que vous programmez. Donc j’en ai codé un.

Et j’ai fini quasi-dernier en bronze.

Vous pouvez lire le post-mortem que j’ai écrit pour y voir les leçons techniques.

J’en tire quelques autres leçons, plus humaines.

La première est assez logique, pour un jeu : c’est la chose la plus amusante, la plus prenante, et la plus crispante que j’ai codé au moins cette année, et facilement ces cinq dernières années. Imaginer un algorithme, le développer, et le voir se comporter, même mal, a ce côté démiurgique qui est la raison pour laquelle je suis développeur. Le corollaire évident, c’est que je ne comprend toujours pas pourquoi mon métier est aussi chiant actuellement : j’ai utilisé des méthodes professionnelles pour développer ce bot : tests, profiling, … Et c’était vraiment amusant. J’en tire la conclusion que notre métier est chiant parce que les demandes des clients sont, la plupart du temps, d’un ennui mortel.

La seconde est assez logique, mais moins drôle : j’ai fini 1675ème ! C’est médiocre, évidement. Et c’est vrai que mon bot était médiocre : des timeouts partout, et des décisions suicidaires encore plus souvent. J’ai pris une vraie leçon d’humilité, ce qui est toujours bien.

La dernière est plus intéressante : on est certes loin du fameux « meilleur programmeur de France », mais il y a beaucoup de monde, et qui semble prêt à y passer beaucoup de temps. Autrement dit, les développeurs sont des gens passionnés, prêts à se confronter les uns aux autres, et à communiquer autour de leurs succès ou de leurs échecs.

#devoxxfr – DDD

Comme le speaker du talk « the quest for infrastructure management » n’est pas là, il y a à la place un talk sur le DDD … Donc allons-y pour le DDD.

Pour s’échauffer, Cyrille Martraire nous parle de son dinsoaure fait avec … un peu de dinosaure.

Donc, c’est parti.
En 2001, avec JavaEE, on nous sort les patterns JavaEE. Et en 2003, c’est le début de DDD.

Beaucoup de monde découvre DDD avec des frameworks, comme CQRS … alors qu’en fait ça ne sert à rien.

Et donc, en DDD, un des trucs importants, c’est d’utiliser un langage commun entre métier et dév … Et évidement, il faut utiliser le langage du métier. Donc, choisissez bien vos mots, sachez précisément ce qu’il veut dire. et n’hésitez pas à utiliser un dictionnaire des synonymes. Du coup, un expert métier serait même capable de reconnaître tous les termes dans les classes. Et pour ça, faire un nuage de mots à partir du code est une bonne idée. Si les mots sont des mots de développeurs, c’est loupé.

Quand est-ce que le DDD est utile ? Quand le métier est riche, quand le métier est complexe, quand c’est important. Parce que ça a un coût, évidement.
Pour avancer dans le DDD, il faut avant tout être curieux du domaine métier.
Ensuite, il faut comprendre vraiment ce domaine, typiquement grâce au BDD.

Voir @carlopescio pour des concepts de physique du code : typiquement, la code gravity où les grosses classes attirent le code.

Pour éviter ça, le DDD recommande vraiment de mettre le code là où c’est utile. Ca veut dire qu’on refactore en fonction du métier, et pas en fonction de Sonar.
Et donc, modéliser un modèle métier en UML, c’est souvent une erreur parce que c’est bien facilement bien trop compliqué.

Il n’y a rien à télécharger pour faire du DDD, mais seulement une boîte à outils méthodologiques. C’est surtout important en java, parce qu’en F# ou Clojure, c’est bien plus facile.

Dans cette boîte à outils, il y a des value objects (égaux par champs), les entités (qui ont un cycle de vie), et les services, qui font des trucs.
Entités et value objects sont newables, et les services sont injectables.

L’un des intérêts des services, c’est que comme ils sont injectables, ils peuvent, dans leurs implémentations, fournir des services techniques (persistance, typiquement). Et c’est bien comme ça qu’on va passer du domaine métier aux services techniques : grâce à la « persistence ignorance ».

On passe ensuite aux bounded contexts, qui permettent d’exposer différents aspects de la même donnée. Leur but, c’est de diminuer le couplage, au prix toutefois d’une duplication de code … au début. Parce que dès que le code évolue, cette duplication n’est plus réelle.

L’avantage, c’est évidement de permettre de séparer les services selon les contextes pour prendre ceux qui sont le plus adaptés.

Très intéressant, même si la plupart des idées, excepté le bounded context, vient en fait du vieux monde de la POO traditionelle (façon C++).

Le code de porc, ça me fend le coeur

1

C’est pas tous les jours que l’actualité me permet un jeu de mot foireux, donc j’en profite.

Cette semaine, une énomre, monstrueuse, terrifiante faille a été découverte dans openSSL, une faille tellement énorme qu’on lui a donné un nom qui fait peur (ou pas) : Heartbleed.

Une faille à priori compliquée, mais que XSKCD explique fort bien :

 

 

Dit comme ça, ça paraît bien

Une faille tellement énorme que la liste des sites que j’utilise et qui sont impactés (livrée par Mashable), me fait frémir :*

  • Twitter (indirectement, apparement)
  • Dropbox
  • Google (j’ai ebncore mon vieux compte GMail, même s’il est voué à la destruction)
  • GitHub (et là c’est la totale : il faut changer de mot de passe et recréer les paires de clés permettant de connecter des machines à GitHub en SSH).
  • IFTTT
  • WordPress
  • Wargaming (c’est-à-dire Woprld of Tanks/Warplanes/Battleships)

Bref, c’est l’apocalypse du mot de passe … heureusement que j’utilise Keepass 🙂

Mais ça n’est pas vraiment là où je voulais en venir.

Dans un de ces hasards facétieux qu’affectionne l’esprit humain, j’ai découvert également cette semaine un Tumblr assez marrant, Code de porc. Ce site, un peu à l’image du DailyWTF, recense des exemples de code pourri.

Et j’aime bien rire. Je suis donc allé y jeter un oeil, et effectivement, j’ai ri. Et puis, comme quand je découvre les IgNobels, j’ai réfléchi. Qu’est-ce qui peut rendre un code pourri (comme par exemple dans le cas d’OpenSSL permettre cette faille monstrueuse) ?

Bon, pour Heartbleed, c’est facile : pas de tests unitaires, un commit fait le 1er janvier très tôt le matin, et pas de peer review stricte avant de livrer.

Mais sur Code de Porc, il y a aussi un autre cas, plus sournois : le refactoring de trop.

Vous savez, celui où vous remplacez toutes les occurences d’un booléen (qui vaut true) par sa valeur, ce qui fait apparaître des bon viex

if(true) {
///
}

Ceux-là, comment les éviter ?

Est-ce que checkstyle a des règles pour détecter les if(boolean) ? J’en sais rien. j’en sais tellement rien que je vais poser la question à StackOverflow

Comment on fait sudo dans un EJB ?

Question curieuse, que mon chef m’a posé pas longtemps après que j’explique à @bmathus que

https://twitter.com/riduidel/status/258176811693907968

Ou, dans une réponse plus longue, que JAAS était une bonne idée :

Cela dit, plusieurs choses sont à retenir
– l’authentification/autorisation est gérée dans toutes nos couches
de manière homogène ET en utilisant toute la plomberie
JavaEE/Glassfish. C’est-à-dire que, en dehors des développeurs de la
partie royaume, la plupart des développeurs ne voient de la sécurité
que les annotations @RolesAllowed/@RunAs. C’est incroyablement
pratique au quotidien de ne pas avoir à se palucher d’envoi
d’exception ou quoi que ce soit d’autre.
– l’appli web et les web services utilisent une BASIC AUTH HTTP qui
passe elle aussi par ce royaume. Donc on est sûr de l’utilisateur d’un
bout à ‘lautre de l’application. Et, bonus, c’est pas moi qui ait
écrit le code de sécurité mais (j’espère) des mecs bien plus
paranoïaques que moi (pas dur, vu que j’oublie parfois de fermer ma
bagnole/ma maison à clé).
– l’API à implémenter est raisonnablement simple – du moins dans
Glassfish : dans l’ensemble, il faut juste être capable, étant donné
un login/password, de retourner une liste de noms de rôles
d’autorisation JAAS. Et, comme notre base est accédée via un
connecteur JCA, ce connecteur est disponible via JNDI (mouaip, pas une
goutte de CDI là-dedans) et donc dans le royaume, ce qui est
indispensable. Autrement dit, Glassfish gère bien mieux que moi
l’ordre de démarrage du bazar.

Dans les inconvénients, j’aurais tendance à dire que
– la doc peut être spartiate (en particulier ce qui concerne les
différentes choses à faire pour que le serveur d’application utilise
correctement le domaine)
– les logs sont soit trop peu nombreux soit trop verbeux (pas assez
nombreux si tu les enlève, mais trop verbeux dès que tu les active,
parce que chaque méthode d’EJB nécessite une authentification).

Hélas, je me suis retrouvé à poser la question fatidique : How can I change user principal during an EJB/MDB invocation?

Et je vous encourage vivement à aller voir la réponse que j’ai moi-même écrite pour cette question, puisqu’elle montre précisément comment, tout en n’étant pas un élément de la spec JavaEE, il est possible d’implémenter « proprement » ce sudo.