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.

Publicités

#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.