Devoxxfr – Software heritage foundation

Pourquoi cette fondation ?

Autour de nous, le logiciel est partout. Et il contient une partie significative de notre connaissance et de notre héritage culturel.

Roberto nous rappelle ensuite cette fameuse citation sur l’importance de la lisibilité du code : « source code is made to be read by other human beings, and only incidentally by computers ».

Par exemple, la fonction de racine carrée écrite par John Carmak dans Doom est un code source qui est précieux et doit rester accessible. Et ça nous ouvre une fenêtre sur l’esprit du développeur.

Par ailleurs, en 50 ans, on est passé d’un code de pilotage d’Apollo 11 en 60.000 lignes au code du kernel Linux qui dépasse déja le million de lignes ! Et si le logiciel est partout, le code source lui, est hébergé chez de multiples fournisseurs (Google Code, Sourceforge, Gitorious, …​). Ce qui rend sa conservation assez complexe (surtout quand les plateformes de stockage de code source ferme). Enfin, si le logiciel est partout, il n’existe pas de plateforme de recherche pour analyser globalement le code source.

Pour combatttre ça, la software heritage fundation a été créée avec comme objectif de collecter, préserver tout le code source accessible. Actuellement, il y a déja 4 milliards de fichiers sources stockés pour 83 millions de projets.

Comment ça marche ?

Pour chaque plateforme, la SHF a créé un adaptateur permettant de collecter les codes sources utilisés. Ensuite, il faut récupérer le code source proprement dit. Actuellement, le code de GitHub et de Debian est stocké. le code de Google Code et Gitorious a été sauvé (avec l’aide de l’internet archive).

Construire pour le long terme

LA SHF a le support de l’Inria, et de l’Unesco. Cette vision est partagée avec un paquet d’organisations. Et un certain nombre d’entreprises sponsorisent l’initiative.

Comment aider ?

La SHF est du code, et peut donc avoir besoin de l’aide de développeurs (forge.softwareheritage.org). Elle a évidement besoin d’argent et de communication.

Conclusion

Il faut imaginer la SHF comme une bibliothèque d’Alexandrie du code (pour tout avoir) et un CERN du code.

Mon avis

C’est sacrément chouette ! Bravo !

Publicités

Devoxxfr – Architecture hexagonale

Pourquoi ? Parce qu’à priori, les présentations sur DDD et l’architecture hexagonale ne parlent pas de framework, alors que les développeurs utilisent pas mal les frameworks.

Chez Saagie, le code s’exécute sur les bonnes machines, grâce à un container manager. Et celui-ci se trompe parfois. Ce container manager est développé avec un ensemble de couches classique. Et le code qui permettait au container manager de choisir où exécuter du code était éclaté dans plusieurs ensembles de service/DAO. Youen a donc refactoré ça dans une méthode à trois ifs.

Comment éviter ça ?

Théoriquement, l’architecture hexagonale permet d’éviter ça.

Domaine

Dans le domaine, il ne faut pas de framework. Des librairies simples peuvent en revanche être utiles.

Le domaine ne doit jamais contenir de code d’infrastructure.

Ports

Les ports sont les moyens d’appeler le domaine. Les ports primaires sont des méthodes du domaine appelables depuis l’extérieur. Et les ports secondaires sont des interfaces définies dans le domaine lui permettant d’appeler des éléments extérieurs.

Adapteurs

Les adapteurs permettent au monde extérieur d’appeler les ports.

Mise en oeuvre

Ensuite, Youen se lance dans une session de live-refactoring pour mettre en place ce type d’archiecture avec une application Spring Boot. Je vous ferai le diagramme de classe plus tard, mais globalement, en deux astuces, il arrive à écrire une application dont les règles métier sont totalement indépendantes des outils techniques utilisés pour communiquer avec le monde extérieur.

Conclusion

Avec ça, Spring est dans son cas nominal, tout comme le domaine. L’architecture hexagonale est donc parfaitement respectée, en utilisant les techniques classiques du monde Java. Le domaine est donc propre, les tests faciles et le code s’adapte beaucoup plus facilement aux échelles. En revanche, les DTO sont un peu lourds, les développeurs doivent être formés et il n’y a pas forcément de starters pour les frameworks.

Mon avis

En fait, l’architecture hexagonale, ça n’a rien de nouveau ni rien de vraiment sexy. Ca consiste surtout à séparer le code réseau du code métier et du code de stockage « d’une façon ou d’une autre ». Et si la méthode choisie par Youen est présentée comme astucieuse, elle est en fait uniquement un bon découpage en classes. Autrement dit ça n’est pas bien compliqué, c’est facilement adaptable et ça me parle puissamment.

Devoxxfr – DDD & Event sourcing avec la GDPR

La GDPR keskecé

La GDPR régit la manière dont les organisations travaillent avec les données des citoyens européens à partir du 25 mai 2018. C’est bientôt. Pour une entreprise qui ne respecte pas cette GDPR, l’amende est de 4% du chiffre d’affaire du groupe plafonné (peut-être) à 20 millions d’euros. Et ce sans compter les poursuites pénales et l’information des utilisateurs.

Les données des citoyens, c’est quoi ?

  • Nom
  • Adresse
  • Adresse IP
  • Les ensembles d’information permettant d’identifier un individu

Evidement, ça donne du travail …​

Et le DDD là-dedans ?

Saagie fournit une application de data governance. Cette appli, développée à l’arrache, est basé sur un paquet de CRUD qui manipulent les données en prod. Malheureusement, les problèmes liés à la GDPR ne sont pas adressables dans ce contexte.

Donc, il ne faut pas écrire du code contraint par la technique, mais plus par le domaine métier.

Et pour ça, il y a plusieurs éléments

  • Avoir un langage commun avec des termes qui sont utilisables par chacun et compris par tous.
  • Ne pas avoir un modèle unique : ça mène d’une part à des classes énormes, et d’autre part à des problèmes de compréhension
  • Les différents contextes dans lesquels s’expriment les modèles doivent être bornés

Pour obtenir ça, la méthode de design en couche avec des DAO, et de la base de donnée qui apparaît un peu partout est peu appropriée. Mettre le domaine au centre permet en revanche de rester « propre ».

Et pour ça, se baser sur les événements peut être utile, parce que la plupart des modes sont d’une façon ou d’une autre événementiels.

Et pour construire le domaine et identifier les événements, la technique de l’event storming est assez utile.

Une fois ces événements identifiés, mettre le domaine au centre revient à mettre en place une architecture hexagonale.

Event sourcing

L’event sourcing, c’est le fait de définir les événements comme source unique de vérité. Avec ça, on peut reconstruire l’état des objets.

Ca apporte en plus

  • La testabilité
  • La gestion de version des données
  • Le debug et la reproductibilité
  • Le rollback (mais pas en supprimant le dernier événement)
  • La tracabilité
  • La recomposition des projections

En revanche, ça n’est qu’un pattern local, qui apporte évidement des inconvénients (comme par exemple le fait qu’il y aura toujours plus de données).

Questions

Comment gère-t-on les données personnelles dans un event store immuable ?

Les données personnelles ne doivent pas s’y trouver, sinon c’est foutu. Ou alors, on stocke une clé de chiffrage par utilisateur (en dehors de l’event store) et toutes les données de l’utilisateur sont chiffrées dans l’event store.

Mon avis

Les deux sujet sont intéressants, mais quel était le rapport ? En fait, il est dans les questions en fin de conférence, qui ont construit le lien.

Devoxxfr – From a french monolith to a worldwide platform

Avant, Dailymotion, c’était un gros monolithe LAMP hosté sur de vraies machines, dans un seul datacenter. L’objectif, c’était d’avoir du code qui s’exécute près du client, avec des applications go/python dans des conteneurs orchestrés par Kubernetes, et des apis GraphQL.

Pour ça, Dailymotion s’est réorganisé autour de tribus, d’escouades et de chapitres (façon Spotify). Ca permet d’aligner l’architecture et l’organisation, ce qui est toujours pratique.

Revenons à l’application. Comme le front-end communique via GraphQL, la migration se fait en douceur : c’est GraphQL qui expose les anciennes API comme les nouvelles, ce qui permet d’ajouter facilement les microservices à côté de l’application historique. Ca permet la migration facile, mais aussi l’appropriation des différents composants du code.

Déploiement de GraphQL

La mise en place de GraphQL, et des fondations de l’application, vient d’une équipe de deux personnes, qui ont mis en place un K8s déployé dans 3 régions AWS. Ca marchait assez bien, mais les infrastructures étaient peu monitorées. L’équipe a ensuite fortement grossi pour atteindre 50 personnes, ce qui a permis de déployer plus de services plus rapidement. Il y a maintenant une dizaine de déploiements par jour (sur une quinzaine de services déployés par cette équipe).

Evidement, cette croissance du personnel a dû être anticipée. Il y avait donc des sessions de formation régulières, sur K8s, la conteneurisation, GraphQL, …​ Mais aussi des modifications des différents outils de RH de la boîte.

Outillage

Pour un nouveau développeur chez Dailymotion, il y a pas mal de switch entre projets (avec des dépendances différentes, dans des versions différentes, …​). Donc la machine du développeur n’a que Docker. Et pour facilement passer d’un projet à un autre, ils ont conçu la spécification de gazr, qui permet de lancer les outils de build ou de test des différentes stacks. Grâce à cet outil, les commandes sont toujours identiques.

Orchestration

Pour facilement créer et maintenir les clusters de prod, Dailymotion utilise un K8s managé chez Google Cloud Platform. Ca permet l’autoscaling. Par ailleurs, le code est déployé sur 3 régions GCP (Europe, Afrique, Asie). Par ailleurs, le code va être migré sur un cloud hybride utilisant les datacenters existant (ceux qui fournissent le CDN utilisé par Dailymotion pour les vidéos).

Continuous deployment

L’équipe qui s’occupait des releases a été remplacé par les équipes de développement elles-mêmes grâce aux Jenkinsfile. Ce sont ces équipes qui déploient jusqu’en prod (automatiquement, sauf lorsqu’une approbation humaine est nécessaire).

Evolution du déploiement

Initialement, les applications étaient déployées par des scripts bash. Ca a été remplacé par une tentative d’application déployant sur tout le cluster via les API K8s. C’était assez complexe, et certaines étapes restaient manuelles. Actuellement, les applications sont déployées par région via Helm.

Celui-ci gère les dépendances, fournit des templates pour séparer les déploiements par environnement, et permet le rollback.

Gestion de la plateforme

L’API GraphQL est supervisée grâce à Open Tracing. Evidement, il y a du monitoring, de la supervision, des logs gérés par Elastic/FluentD/Kibana, et du feature flipping.

Rôles

Avant, il y avait trois types d’ingénieurs

  • Le software engineer écrit le code (pas forcément facile à opérer)
  • Le release engineer package et déploie l’application
  • Le system engineer opère l’application, mais ne peut pas corriger celle-ci.

Ces rôles ont été remplacés par le production engineer, qui tient chacun des rôles. Ca implique des changements organisationnels (les anciens développeurs peut se retrouver d’astreinte, il faut changer leur contrat de travail).

Ca veut aussi dire que les développeurs peuvent mettre en prod. Et par exemple, Stan, lors d’une manipulation hasardeuse, à détruit tous les conteneurs faisant tourner Dailymotion dans le monde entier. Mais grâce aux outils de rollback préparés, le retour à la normale a pu avoir lieu très rapidement. Et surtout, ils ont pu apprendre de leurs erreurs et mettre en place des outils évitant ces manipulations.

Mon avis

Un bon retour d’expérience avec quelques bonnes idées. Malheureusement, j’ai eu l’impression que la présentation restait un peu trop à la surface des choses.

Devoxxfr – Litterate programming, le roman de votre programme

Le litterature programming a été inventé par Donald Knuth …​ pas n’importe qui, en fait.

A l’époque où il conçoit ce concept, il n’est pas absurde d’écrire un programme et de le faire imprimer. C’est préciséement l’objectif de la programmation lettrée.

Donc pour ça, Knuth conçoit un outil (web) qui permet d’écrire le code et sa description dans le même fichier.

Avantages et inconvénients

Ca permet d’expliciter sa pensée. La documentation est forcément présente et à jour. On s’éloigne par ailleurs de la programmation traditionnelle pour s’approcher du langage naturel. En revanche, l’outil est verbeux. Il faut également maîtriser à la fois le code et la langue le décrivant. Le refactoring est spécialement difficile. Et actuellement, faire de la programmation lettrée est à peu près impossible, aprce qu’on écrit dans l’ordre de la pensée.

Appliquer aujourd’hui

Raphaël a tenté de le faire dans du code Java, à travers des commentaires beaucoup plus verbeux. C’est possible, mais assez peu approprié

Qu’est-ce qui s’en rapproche aujourd’hui

D’abord, il y a les commentaires du code, qui vont pouvoir expliquer pourquoi le code fonctionne de cette façon. Il y a également les commentaires de commit, mais qui sont rarement explicites. La documentation traditionnelle peut aussi aider, même si elle n’est pas écrite simultanément. La javadoc documente correctement l’API, mais n’explique pas le fonctionnement du programme.

Les tests unitaires (en TDD) peuvent expliquer correctement le fonctionnement du code, à travers la documentation associée. Mais ils sont séparés du code principal, n’expliquent pas le fonctionnement. Par ailleurs, les documenter ne documentera que les cas lister. Enfin, le formalisme est loin d’être souple.

Qu’est-ce qui pourrait fonctionner ?

Des outils graphiques, avec l’inclusion d’image. Par exemple, Jupyter ressemble pas mal conceptuellement.

Questions

En coffeescript ?

A priori, il est possible d’intégrer du coffeescript dans les pages == Est-ce que ça n’est pas impossible de lier le code et sa documentation ? C’est certes compliqué, mais ça peut approcher des choses (typiquement, Asciidoc peut intégrer du code comme dans la doc Groovy).

Mon avis

Malheureusement, j’en savais autant que le speaker sur la programmation lettrée. Et pire encore, j’ai eu l’impression d’avoir une meilleure vision de la manière « moderne » d’utiliser ces idées. Cela dit, c’est un concept qui m’a toujours paru méconnu.

#devoxxfr – Rideau !

Devoxx est fini, et je suis dans le train.

Ce que j’en retire conceptuellement

Globalement

En montant dans le train, j’ai croisé l’un des GO du chtijug qui n’a pas eu la chance de venir à Devoxx, qui m’a demandé quels étaient mes trois talks préférés. Sans hésiter, j’ai répondu « la troisième matinée de keynotes sur l’impact social du développeur ». Et, vraiment, je le pense. Ces quatre talks m’ont, chacun à leur façon, soigneusement mis en face de mes contradictions, et des contradictions de mon métier face au monde actuel. Ca me fait bien comprendre certains engagements citoyens que je vois émerger. Et clairement, ma vision du monde est changée. Ca, c’est ce qu’on pourrait appeler un point de vue stratégique.

Localement

D’un point de vue plus tactique, pour filer la métaphore, j’ai vu un très chouette talk d’architecture de Simon Brown qui m’a enfin permis de comprendre un point clé sur l’opposition monolithe/micro-services. Je vous explique : d’habitude, on les oppose soigneusement, comme si il n’y avait pas d’intermédiaire. Or, Simon démontre dans sa présentation que l’opposition est idiote, et qu’il existe un continuum entre les deux, ce continuum reposant sur une espèce de curseur d’isolation des composants : si votre application est un plat de spaghettis, vous êtes évidement dans la merde pour passer aux micro-services. Mais, si vous l’organisez proprement, est-ce que vous êtes sûrs que vous aurez besoin des micro-services ? Est-ce que vous ne pourrez pas développer des composants d’un niveau d’isolation équivalent sans passer par le plat de spaghetti réseau des micro-services ? L’organisation en composants étant, évidement, très proche de la vision de DDD proposée par Cyril Martraire dans son talk-surprise. Et cette vision d’une application correcte va évidement faciliter pas seulement le développement, mais aussi l’exploitation et la sécurisation. Un tout bien propre sur lui, donc.

Et dans ce tout, comment vient s’intégrer la blockchain ? Parce que bon, je me suis tapé en tout au moins 4 heures sur le sujet. Eh bien, je dirais que c’est le chaînon manquant. Je vous explique … Actuellement, les applications que nous écrivons sont opaques, et aussi dignes de confiance que, par exemple, le fameux système de paye des militaires qui ne marche pas. En effet, l’exécution du code se passe dans un silo bien protégé, quand bien même votre code n’a pas grande chose de plus confidentiel que, disons, un hébergement de blogs, un hosting d’applications façon clever cloud, ou autres. Avec la blockchain, et en particulier avec ethereum/embark, l’exécution de votre code devient une chose publique (inarrêtable, mais c’est un autre sujet), aussi bien dans son exécution que dans ses résultats.

Par exemple, si le calcul de vos impôts était rendu public, qu’est-ce qu’il se passerait ? D’abord, instantanément, votre situation fiscale (donc financière), deviendrait publique. Vous imaginez le choc dans notre pays de l’argent tabou ? Si on met ce point révolutionnairement épineux de côté, vous auriez aussi la garantie de la justesse de son exécution, parce que cette exécution serait reproductible, et reproduite sur tous les noeuds du réseau l’hébergeant. En bonus, cette information serait infalsifiable. D’autres informations pourraient également bénéficier de ces propriétés de façon moins polémique. Par exemple, à mon sens, la prochaine machine à voter infalsifiable et légalement correcte s’appuiera sur une blockchain (ça posera juste le problème de la disponibilité des votes avant la fin du scrutin, mais j’ai à dire vrai de plus en plus de mal à comprendre le sens de ce secret).

Ce que j’en retire humainement

Il y a un côté un peu … déstabilisant … à se retrouver d’un coup plongé au milieu de plusieurs milliers de développeurs parlant tous de Java, d’exception, de déploiement, de l’impact du ClassLoader sur les performances, de frameworks plus ou moins connus, et de toutes ces choses sur lesquelles j’ai quelques connaissances, mais finalement beaucoup moins que ce dont je peux avoir l’impression hors de cette fête. Mais une fois que ce sentiment est dépassé, il ne reste que le plaisir.

Ou plutôt les plaisirs.

Il y a d’abord le plaisir évidement d’entendre des gens intelligents détailler avec talent des idées qui font rêver.

Il y a ensuite le plaisir humain de pouvoir avoir des discussions intéressantes, intelligentes avec tout un tas de personnes : Clément, Julien, tous les castcodeurs (et en particulier une discussion vraiment chouete avec Vincent Massol sur XWiki, mon usage, son avenir).

Et, même sans forcément leur parler, le plaisir de voir les orgas réussir un bon sang de truc génial, avec une banane incroyable malgré la charge évidente de faire tenir cet édifice sur leurs épaules. J’ai croisé cinq ou six fois Nicolas Martignole, à chaque fois j’ai été de lui lancer un « welcome to the jungle », mais il courrait tellement dans tous les sens qu’il n’aurait probablement rien entendu.

Bon, évidement, tout n’est pas parfait : un talk franchement moins bon (de mon point de vue), deux sessions annulées (mais une remplacée avec talent), un village des exposants qui m’a franchement laissé froid (à part les stands Zenika & Murex – longuement squattés Jeudi soir – et la bière Sonar – abondamment bue le même soir). Et puis surtout, le pire : la terrasse du palais des congrès fermée malgré un temps qui, franchement, s’y prêtait.

Ouais, Nicolas Martignole écrira sans doute un bel article la semaine prochaine sur le blues des orgas, mais je ressens, moi, malgré le retour à la maison, le blues du spectateur qui retourne à son vieux projet après avoir vu, et eu, des idées géniales. Enfin, géniales, à mon niveau :

  • Implémenter browserWatch dans Wisdom framework – après avoir vu les boucles de feedback pour développeurs
  • Ecrire une application de nomic sur la blockchain (dans un ethereum de test pour commencer) – ça impliquera des programmes auto-modifiables
  • Ajouter une sortie graphml/archi au plugin maven de structurizer
  • Peut-être commencer à faire des prez publiques, genre au chtijug, justement sur Wisdom pour commencer, avant de tenter un « développeur à 40 ans, so what ? »
  • Trouver un moyen de manger un jour avec autour de la table quelques personnes à Lille qui devraient se rencontrer
  • Me créer un autre job ? Devenir politicien-développeur ?
  • Et surtout, surtout, commencer à militer dès Lundi pour revenir à Devoxx du 5 au 7 avril 2017 … et avec quelques collègues de plus.

Et, si jamais certains membres de l’organisation tombent sur ce post, merci à eux pour tout (sauf pour la selfie durant la keynote, ça, c’était too much :-)).

#devoxxfr – Infra as Code, choisissez vous la pilule rouge ou la pilule bleue ?

Après cette blockchain en délire, revenons à du concret avec l’infra as code.

Mais qu’est-ce que l’infra as code ? c’est surtout le moyen de sortir une copie complète de l’infra sans péter la prod actuelle.
En théorie, ça doit permettre d’aller plus vite. En pratique, c’est plus de code, donc il faut le maintenir sinon il ne fait pas gagner de temps.

Donc on peut très bien tenter de faire vivre l’existant avec des bouts de ficelle et des scripts bash, ou on peut tenter de prendre conscience que l’infra as code, ça reste du code, et il faut s’en occuper comme du code.

Donc pour réduire la boucle de feedback lorsqu’on monte une infra, on isole pour débugger plus vite. Avec des outils comme

  • Vagrant
  • Docker

Et on va faire du feature filpping pour éviter les besoins de prod en dév.

Evidement, avec ces outils, on essaye toujours de se contenter de déclarer l’état désiré plutôt que le mode de transition. Donc pas d’ajout manuel dans le /etc/hosts, par exemple. Et pas non plus à grands coups de grep qui ne seront jamais suffisants.

Vient ensuite la super analogie de l’ascenseur : ne déclarer que l’état désiré. C’est ce qui permet l’idempotence. Idempotence qui est vraiment bien pratique pour rendre des configurations reproductibles.

Pour chaque profil de dév, il y a des outils qui vont permettre de les faire bosser mieux et plus vite. Je vous laisse regarder les détails et la vidéo, mais ça met bien face à chaque profil l’outil approprié.

L’un des meilleurs outils pour la prod est Gitlab/Github, parce que si on y met l’infra as code, ça permet aux développeurs de le lire et de comprendre comment marche la prod.

La dette technique peut également apparaître dans l’infra as code comme dans le code, et doit être gérée comme dans le code, c’est-à-dire comme à Tetris : si on ne veut pas s’y noyer, il faut éliminer les blocs dès qu’on peut.

Et l’un des endroits clé, c’est le bash, pour lequel il y a aussi des bonnes pratiques : interdire les unset, arrêter le script quand une commande échoue. Et comme dans le code, les caractères sont gratuits, donc priviliégiez les flags avec des noms longs.

Pour aller en prod sereinement

D’abord il faut savoir ce qu’il y a en prod … en loggant les résultats de chaque install en prod. Parce que la prod est faite du code de déploiement ET de l’état actuel de la prod … qui ne sera visible que dans les logs.

Ensuite, pour garantir la prédictibilité du déploiement, il vaut mieux enlever tous les sleeps du script de déploiement et les remplacer (quelque soit l’outil) par des tests de démarrage des services.

Et puis ne mettez pas tous vos scripts directement dans Jenkins, testez-les d’abord en ligne de commande avant de les mettre dans Jenkins, pour pouvoir versionner ce script d’une part, et pouvoir l’utiliser même quand jenkins est down ensuite.

Pour tester son environnement, on utilise les mêmes méthodes que les dévs (oui oui, on parle bien de pyramide des tests et de TDD). Malheureusement, il n’y a de l’outillage de test unitaire que dans chef et puppet. Là, il s’agira vraiment de tester le script chef/puppet et pas le code applicatif. Pour le test d’intégration, on peut très bien tout piloter dans Jenkins en quatre étapes d’un build.

#devoxxfr – blockchain as a trust machine

Donc après la découverte de la blockchain, et développer une appli ethereum/embark sur la blockchain, dernière conf sur le sujet : blockchain as a trust machine. La différence ? Maintenant, c’est Murex (la cheville ouvrière du trading en France) qui présente. On verra ce que ça change …

« l’homme est un animal social » ou plutôt un animal économique, d’où le troc, puis le système économique. D’ailleurs, depuis le XVIème siècle, le système monétaire n’a pas fondamentalement changé.

The linux foundation a lancé le projet hyperledger qui est un projet proche de la blockchain … en partenariat avec tout un tas de banques et de gros acteurs technologiques.

Mais pour un fonctionnel, la banque, avant tout, c’est un tiers de confiance (au passage, ça reprend la keynote de Fabrice Epelboin sur la crise de la confiance). Alors, est-ce qu’on peut la remplacer ? A priori, avec la blockchain, oui. Du coup, la confiance est-elle plus du côté de bitcoin, ou du côté de ma banque ?

Donc, faisons d’abord un retour sur les bitcoins : ce sont des transactions qui sont timestampées par des blocs. Clair ou pas ? Carrément clair, je trouve. Tout le reste est, en quelque sorte, un détail d’implémentation.

Pour éviter les double-dépenses, les transactions sont timestampées. Et, grâce aux hashes qui sont associés aux transactions, la blockchain est considérée comme inaltérable.

Bon, pour continuer, la blockchain nécessite régulièrement de nouveaux … blocs. Et les mineurs vont créer ces blocs en calculant des nonces. Et comme les mineurs sont intéressés, ils n’ont pas forcément confiance. Pour tenir compte de ce manque de confiance, c’est un réseau totalement décentralisé. Et chaque noeud revalide toutes les données dès qu’il reçoit un nouveau message.

Et il y a un langage de script caché dans la blockchain. Et ça, pour un développeur, évidement, c’est du pain béni. Grâce à ça, on peut par exemple authentifier un objet, grâce à un script d’unlock n’autorisant pas la consommation de la transaction. On peut également faire de la mise en gage en demandant le déverrouillage de la transaction par deux personnes.

S’ensuit une démo incroyable sur un réseau de raspberrys de test. Et c’est franchement bluffant. Même si ça n’est évidement pas représentatif de la vraie blockchain.

Ce qui fait de cette présentation la meilleure de devoxx pour comprendre la blockchain.

#devoxxfr – CDI 2

Injectons donc un peu de nouveauté maintenant … avec CDI 2. Et à mon avis, avec José et Antoine, ça devrait être très intéressant (sans doute aussi parce que CDI me fascine comme le serpent fascine la souris).

Comme d’habitude, comme c’est une discussion sur la spec, le premier point important, c’est : vous pouvez contribuer à CDI 2. Alors si vous avez envie d’aider l’expert group, n’hésitez pas.

CDI, pour l’instant, a 3 version

  1. CDI 1.0 (2009)
  2. CDI 1.1 (2013)
  3. CDI 1.2 (2014)

Et CDI 2 devrait sortir avant Janvier 2017.

Je vous passe les détails sur CDI ? Oui, je passe, parce que vous les connaissez évidement.

Bon, le suivi de CDI 2 est assuré par un meeting IRC par semaine, et ça avance bien. Il y a un cdi-spec.org pour participer plus facilement.

Je vous laisserai regarder la liste des nouvelles features, mais c’est vraiment vraiment chouette. La sécurité va être externalisée de la spec CDI pour être placée dans sa propre spec.

Donc on pourra démarrer de façon standard CDI en JavaSE (on peut le faire actuellement, mais c’est dépendant de l’implémentation). Ce qui est mieux que de dépendre d’un conteneur JavaEE. A noter que la spec CDI a des liens vers le TCK, d onc on peut facilement regarder le code de test correspondant à une feature. Très pratique pour vérifier qu’on a bien compris un point.

Il y a des discussions sur les scopes qui seront supportés en JavaSE. Typiquement, on pourrait ajouter un MehtodScope … Si il est utilisable pour, par exemple, l’utiliser lors d’un MouseEvent, ça vaudrait le coup.

Et passons aux événements !

La grosse feature est l’utilisation d’événements asynchrones. Parce qu’en CDI 1, le mode de transport n’est pas spécifié, mais tout le monde fait du transfert synchrone. Du coup, certains utilisateurs ont abusé cette fonctionnalité pour en faire un visiteur (et vu la tête des speakers, Antoine l’aurait plus volontiers fait que José). Du coup, comme ça a été fait, et comme on fait du Java, et comme ça respecte la spec, il faut le garder, sinon tout le code historique va mourir. Evidement, on ne veut pas vraiment de ça.
En bonus, les contextes CDI sont confondus avec les threads. Du coup, passer les événements en assynchrone va être compliqué.
Donc, ce sera l’appelant de la méthode Event.fire() qui pourra décider si l’événement est synchrone ou pas. Et l’observer doit pouvoir être sûr d’être dans le bon contexte. Et là, mais je sais qu’ils me diront que c’est pas terrible, ils vont ajouter Event.fireAsync() et @ObservesAsync … J’ai bien l’impression que j’aurais préféré Event.async().fire() et Observes(async=true) … Mais je ne suis pas dans la spec.

En revanche, là où il faut être attentif, c’est qu’un envoi incompatible ne donnera lieu à aucun déclenchement de méthode. C’est dommage qu’il n’y ait pas moyen de savoir qu’on fait une erreur dans ce cas.

Bon, par contre, pour les événements mutables, ben là, ne le faites pas. RELLEMENT, NE LE FAITES PAS.

Pour en revenir aux bonnes nouvelles, quand on fait fireAsync, on peut passer un ExecutorService pour définir le thread d’exécution de l’observer.

Par contre, pour récupérer l’état après un appel asynchrone, le fireAsync va retourner un CompletionStage … ce qui explique pourquoi il y a une méthode fireAsync() plutôt qu’un async().fire() …

Passons aux améliorations du support d’AOP.

Bon, on va pouvoir injecter des contextes dans des @Produces. mais ce qui est intéressant là-dedans, c’est la classe UnManaged, qui permet de faire de l’injection sur des objets non créés par CDI. Parce que pour le reste, CDI 2 va « juste » simplifier énormément la transformation d’une annotation.

Ca donne pas envie de faire du CDI 2 ? Eh ben si, vraiment.

#devoxxfr – Microservices IRL: ça fonctionne chez un client, on vous dit comment!

Et donc, des microservices … en prod !

Curieusement, comme d’habitude, ils nous expliquent que les microservices viennent des mouvements agiles, devops, et permettent au SI de s’adapter aux architectures web, cloud grâce aux conteneurs. Et enfin, un microservice, conceptuellement, c’est juste un environement d’exécution d’un bounded context DDD.
Chaque microservice a son propre modèle de persistance et ses propres tables. Du coup, un antipattern est d’avoir des tables partagées entre microservices, comme c’est le cas pour DDD.
Et évidement, dans les microservices, il y a de la répétition.

Donc il y a comme lors de la présentation d’orchestration docker tout un tas d’outils aux noms bizarres : zookeeper, hystrix, … qui permettent toutefois d’assembler « facilement » une application à base de microservices.

Le déploiement se fait par Ansible, mais manuellement.
Heureusement, un outil comme Spinnaker permet de faciliter ça, comme Jenkins 2.

D’une façon amusante, pour le transfert des données, ils utilisent JSON, qui malheureusement ne contient pas de schéma. Ils auraient pu utiliser XML, mais c’est jugé trop verbeux … Ou alors c’est que c’est trop old-school, j’en sais rien.

En tout cas un bel exemple, et le dashboard hystrix est quand même un truc bien agréable à regarder (pour un dév comme pour un ops, en fait).