Les furets sont au chtijug !

Tout ce qui est présenté est disponible sur GitHub, avec d’autres choses …

Donc, les furets font de l’assurance. Et ils ont fait d’abord différents sites au look … discutable.

En terme de code, actuellement, il y a 450K lignes de code, et un déploiement en prod par jour. Ca change pas mal des clients avec un déploiement par semestre …

DomainModel.stream()

A quoi ça sert

La classe Person, chez eux, est … grosse, et riche d’héritage. Normal pour un projet qui a 7 ans. Et évidement, ce modèle circule dans l’entreprise, du client Javascript à la base backoffice qui reprend les données sous des formats différents.

Evidement, comme c’est compliqué, ils ont cherché à simplifier tout ça, en utilisant globalement des domaines orientés colonne :

  • clé/valeur dans le client
  • modèle colonnes dans Cassandra
  • Vecteurs de données dans la base analytics

Du coup, utiliser un dictionnaire de clé partout devrait simplifier les choses.

Pour la suite, on va travailler sur un modèle simplifié.

Premier souci : comment ça se passe quand on a des relations 1-n ? A priori, « ca marche » … personnellement, je n’y crois pas trop, mais admettons.

Il y a aussi le souci des champs accessibles par plusieurs chemin, qui cette fois-ci sont dupliqués dans les données disponibles.

Et passons tout de suite au livecoding.

Manipulation simple du modèle

Donc, on a d’un côté notre modèle objet traditionnel, et de l’autre, grâce à un wrapper généré par l’outil des furets. Dans ce wrapper orienté clé/valeur, écrire des données se fait avec un simple

SampleModelWrapper.set(FieldId, value)

lire des données se fait simplement avec un

SampleModelWrapper.get(FieldId)

Et en terme d’implémentation, ça se fait facilement en générant des lambdas (évidement, avant Java8, ça aurait marché tout aussi bien avec des classes internes, mais bon, les lambdas sont à la mode). Et, en plus, l’inférence de type semble assez faible, puisque le type contenu dans le FieldId ne suffit pas à contraindre suffisament le type de sortie.

Manipulation avec des streams

Donc évidement, faire SampleModelWrapper#stream() retourne toutes les valeurs du modèle. Et on peut transformer les valeurs en map en traversant le même stream. Pratique, mais pas exceptionnel. Même si le speaker n’est pas de cet avis. Et en un sens, je le comprend, puisque le mapping est traditionnellement un problème compliqué : regardez Jackson/JAXB et autres qui galèrent pour bien faire les mêmes choses.

Petit bonus : on peut filtrer les éléments du wrapper selon différents tags, qui sont définis librement dans le wrapper. De cette manière, par exemple, on peut séparer les données du User et de l’Account du modèle d’exemple. Evidement, ça peut aussi servir à affiner l’accès à certaines interfaces selon les droits des utilisateurs.

A noter que le site des furets a environ 1000 clés dans les différents enums défnissant les modèles utilisés.

Introspection

Typiquement, quand on veut mettre les données dans une base Cassandra ou autre, il faut d’abord créer les colonnes typées associées, pour lesquelles on va naviguer le modèle, et pour chaque élément du modèle, on va créer une colonne dont le type sera obtenu grâce au FieldInfo correspondant à chaque champ.

Evidement, pour moi, il est assez curieux de voir des gens réinventer des notions analogues aux BeanInfo / PropertyDescriptor disponible dans le vieux monde des JavaBeans. Mais dans l’ensemble, ça fait le job assez (peut-être trop, en fait) simplement. Trop simplement, parce que par exemple, les annotations portées par le modèle initial ne sont pas transportées à travers le wrapper.

Conclusion partielle

Je comprend tout à fait l’intérêt de mapper un modèle de beans vers des séries de colonnes. En revanche, l’implémentation, certes joliment Java8, manque quand même de certains aspects clés : la gestion des collections fait vraiment peur, l’introspection est fichtrement limitée.

Cela dit, ça doit clairement bien limiter la complexité de la sérialisation, de la création d’interface graphique, ou même de persistence (non relationnelle, évidement, parce que sinon, c’est évidement merdique).

Il y a en fait là-dedans une idée très intéressante qui a sans doute un rapport certain avec le NoSQL. je m’explique. Lorsqu’on codait il y a dix/quinze ans avec une base de données relationnelle, avoir du code proprement décomposé était une bonne idée. Maintenant que la plupart des outils de stockage sont dénormalisés, à typage faible, bref, merdiques en terme de support des liens sémantiques, avoir un modèle riche est presque une gêne. Et c’est dans ce cadre que ce système de wrapper de modèle présente un intérêt.

Continuous delivery

Bon, si vous ne savez pas ce qu’est le continous delivery, c’est assez simple : c’est l’idée de pouvoir envoyer du code en prod au plus tôt. Et actuellement, les furets font plusieurs mises en prod par jour.

Historique

D’une façon amusante, en 2012, ils faisaient une MEP par mois, parce que leurs sprints SCRUM duraient un mois. Les tests étaient joués en fin de sprint et pouvaient entraîner des retards de MEP du fait de tests à corriger. Pas très pratique …

En 2013, ils ont tenté d’accélérer les choses avec des sprints « bonus » d’une semaine. Le premier impact est que le temps de build est passé de 15 mn à 3 mn.

En 2014/15, passage à Kanban avec une release chaque jour : les fonctionnalités sont marquées finies dans Kanban quand elles sont en prod. L’impact, évidement, c’est que la release est passée d’une journée entière à 2/3 heures. L’autre impact, c’est que les tests ont tous été automatisés. Histoire de se rassurer, les fonctionnalités passent quand même dans un environnement de staging pendant une journée pour vérifier que tout va bien.

Pour le futur, l’objectif est de livrer encore plus vite : les fonctionnalités devraient apparaître presque une par une en prod.

Curieusement, les MEP apportent toujours autant de code, voire même plus, parce qu’il y a beaucoup plus de fonctionnalités dedans.

Quelques aspects techniques

En-dehors des classiques environnements, il y a quelques points notables.

Les tests sont joués en parallèle sur un grid selenium, qui tourne sur une machine avec un RAMFS (128 Go de RAM chez OVH pour 300 €/mois).

Ils développé Zeno qui va sur une URL pour faire une capture d’écran. Et qui fait la différence entre la prod et la préprod. De cette façon, on peut vérifier que les différences visibles sont bien liées aux fonctionnalités développées (et pas à des bugs, par exemple). Cet outil pourrait par exemple être utilisé pour faire de la veille concurrentielle.

Evidement, le développement se fait en mode blue/green. Avec un double cluster.

Continuous delivery en détail

Il y a en gros 3 modèles de développement

  • trunk based : tout ce qui est dans le trunk part en prod. Ca implique le feature flipping qui est du code en trop.
  • feature branching : tout les dévs sont fait dans des branches, qui sont réintégrées dans le trunk au moment de la MEP. Ca pose évidement des problèmes d’intégration continue.
  • Et pour finir, le modèle github où le code est développé dans des branches, et réintégré dans le trunk via des pull requests, qui passeront dans l’intégration continue.

La grande astuce des furets pour simplifier tout ça est de tester les merge rapidement. Grâce à ce qu’ils appellent le continuous merge : lorsqu’un développeur a fini un développement, il est poussé sur un repository qui contient toutes les nouvelles features branches, et qui tente de les merger et de déployer le code sur l’environnement de staging.

git octopus

Chez eux, les branches en cours de dev s’appellent studies/ et celles qui sont finies s’appellent features/. Pour merger tout ça, ils ont un script appelé git octopus disponible sur github. Le truc magique, c’est qu’il peut détecter les conflits entre les branches à merger avant le merge final.

Pour résoudre les problèmes qui arrivent … ben là, essentiellement, c’est du git-fu (et vous savez ce que j’en pense). En fait, c’est pas vrai : tout ce qui est dit est également valable avec Subversion … et j’ai bien l’impression que c’est ce que gigomerge (mince, j’aurais bien mis le lien, mais je ne le retrouve plus) permet d’une certaine façon.

Pour faciliter la gestion des conflits, ils ont également créé un outil de gestion des conflits … qui en fait se contente de créer un workflow d’escalade des exceptions.

Conclusion

Deux présentations très intéressantes, faites par des gens qui se soucient manifestement beaucoup de ce qu’ils livrent, et de la façon dont ils le livrent. Il y a là-dedans des choses vraiment très intéressantes (git octopus, conceptuellement, est très bien, et cette histoire de repository définissant le niveau de maturité d’une feature est également très chouette) D’autres sont en revanche plus discutable (la résolution de conflit me paraît plus de l’ordre de l’astuce que de la solution vraiment propre).

Mais surtout, ce qui apparaît, c’est que, contrairement à bien des boîtes, ils ont l’ambition de se voir comme une boîte de développement logiciel, ce qui implique de produire de la qualité et de la visibilité. C’est sans doute ce qui leur permet de recruter des pointures, puisque nos deux intervenants paraissaient particulièrement compétents.

Je déteste encore git

J’ai déja écrit que je détestais git ? OUI.

Mais, en un sens, ce que je déteste au moins autant, c’est de me faire prendre pour un con.

Tiens, par exemple, quand j’écris un peu énervé

C’est quand même un peu vexant de se voir répondre

Me dire ça, à moi … Me dire que la meilleure façon d’utiliser cet outil difficilement compréhensible, c’est passer par nodejs et chromium … mon dieu.

Et puis, surtout, mon problème n’a rien à voir avec git en tant que tel, mais plus avec la façon foireuse de git d’utiliser la configuration système. Regardez un peu la question StackOverflow que j’ai posé à ce sujet … c’est assez merdique.

Cela dit, quelque chose m’a un peu intrigué. Ce tweet, en particulier.

Là, vous voyez, il y a un problème : le bon outil est ergonomique. Et quand je vois le nombre de personnes qui galèrent pour l’utiliser, sans même parler de l’utiliser correctement, je me demande si, réellement, il y a eu un gain si net par rapport à Subversion. Bon, pour le noyau Linux, clairement, ça doit être indispensable.

Mais ai-je besoin du même genre d’outil pour un projet qui ne va être partagé qu’entre quelques machines de développement et un serveur d’entreprise ?

Ai-je besoin d’un outil développé essentiellement pour des gens qui considèrent que l’ergonomie de la ligne de commande de Linux est un must insurpassable ?

Ai-je besoin d’un outil dont la l’intégration avec Linux est tellement poussée que le moindre problème dans la configuration réseau doit se résoudre dans les fichiers de configuration ssh du compte utilisé ?

Bref, encore une fois, je suis perplexe devant la faculté du monde du développement à adopter un outil inergonomique, rempli de fonctionnalités inutiles, et totalement inopérable pour peu que cet outil permette de démontrer une forme tordue de supériorité intellectuelle.

Et là, je me rends compte qu’en un sens, le Python ou plutôt sa communauté a peut-être changé ma perception de ce genre de choses …

FreeFileSync, c’est quand même vachement bien

Vous savez que j’ai de plus en plus de mal avec « les géants du web » et leurs liens avec l’administration de la surveillance d’état américaine … Par exemple, quand Condoleaza Rice s’installe au bureau de la direction de Dropbox, le signal est assez fort pour que je m’inquiète. Mais ça, c’est sans doute une matérialisation de ma paranoïa.

Toujours est-il qu’il n’y a pas bien longtemps, ma femme a remplacé son portable vieillissant par un UltraBook tout neuf, tout léger. Et là s’est posé la question de la synchronisation de ses données … Alors évidement, elle a un compte Dropbox … mais son compte Dropbox ne permet pas forcément de synchroniser une clé USB et un dossier de sa machine, par exemple. De la même manière, synchroniser sa machine avec un serveur SFTP est impossible.

Heureusement, avec FreeFileSync, c’est possible. Bon, évidement, c’est pas plug’n’play : pour que la synchronisation soit instantanée, il faut jouer avec RealFileSync et les tâches planifiées. Mais une fois que c’est configuré, il suffit de créer/modifier/supprimer un fichier sur la clé USB pour qu’il le soit sur le disque dur local, et le disque dur réseau.

Ca marche quand même très bien … et pas que sur Windows, ce qui est encore mieux !

La blockchain … au chtijug !

Avant toute chose, un petit avertissement : j’ai mangé à Devoxx de la blockchain à foison. Et cette session du chtijug avait donc pour moi comme un goût … de trop peu.

Avant donc de lire ce compte-rendu, je vous encourage à jeter un oeil aux articles précédents

Et donc, c’est parti !

 Survolons donc la blockchain

Pour commencer, petit retour classique sur l’argent : le troc, puis la monnaie, la monnaie fiduciaire, et la crise boursière de 2008. Au passage, et là c’est mon avis, il me semble que toutes ces histoires du troc qui s’étend pour devenir la monnaie sont assez remises en cause par les économistes/historiens …
Ce qui nous amène comme d’habitude à Bitcoin et son échange de monnaie en P2P.
Bitcoin permet d’écrire la confiance dans le code (voir à ce sujet blockchain as a trust machine).
Vient ensuite le classique passage sur l’opposition entre les banques traditionnelles et le P2P qui va tout fracasser.
Pour Julien, ça n’est pas intéressant, alors que c’est tout le sel du sujet : décider où placer le curseur de la distribution de données va permettre (ou pas) le succès de l’implémentation.

Revenons à la technique : la blockchain, basée sur un livre de comptes public et distribué, et une méthode de construction de consensus.

Ce livre de comptes est découpé en plusieurs blocs. Pour créer un nouveau bloc, des acteurs de la blockchain sont incités à effectuer les calculs permettant d’initialiser le bloc suivant (ce sont les fameux mineurs). C’est l’un des points importants : tous les concepts de la blockchain se basent sur des incitations ou pénalités « économiques » favorisant ou empêchant des comportements. Ainsi, les mineurs sont récompensés par des transactions dans le livre de compte en leur faveur lorsqu’ils permettent d’initialiser un nouveau bloc.

Julien voit ça comme une base de données distribuée. C’est vrai au sens où les données sont distribuées. En revanche, les capacités d’indexation et de recherche sont … un peu faibles.

Après un aperçu très … vague de l’activité de minage, vient une comparaison entre bitcoin et les banques traditionnelles. Dans ce cas, la principale différence est que le réseau Bitcoin est totallement public. Oui, public : tous les comptes de tous les utilisateurs sont visibles. Il se trouve juste que ces comptes sont des UUID illisibles.

Le cas d’utilisation présenté ensuite est séduisant, avec la borne de paiement acceptant les bitcoins, mais irréaliste au vu des délais de validation des transactions : actuellement, il faut environ 5 blocs pour être sûr de la validation de la transaction, soit presqu’une heure … Difficile d’attendre tout ce temps pour acheter sa baguette.

L’un des intérêts de bitcoin est aussi que le langage de script embarqué dans les transactions permet des opérations plus complexes que le simple échange de bitcoin de gré à gré. On peut par exemple faire valider le paiement par N personnes parmi M, ou attendre le paiement jusqu’à une date donnée.

Vient ensuite le sujet des oracles. Un oracle permet d’injecter dans la blockchain des données externes. Le gros problème est que, comme toutes les transactions sont rejouées sur tous les noeuds, il faut que les valeurs renvoyées par les oracles soient indépendantes de la date à laquelle ces oracles sont appelés.

Ce qui nous amène aux limites

  • le manque de scalabilité
  • la concentration des acteurs
  • les choix technologiques
  • la gouvernance du projet
  • la protection des clés

Heureusement, des blockchains, il y en a plein. Elles ont certes des valorisations inférieures, mais les évolutions sont encore nombreuses. Et elles ont des objectifs différents : certaines ont un objectif monétaire, ou applicatif … comme ethereum.

Dans ethereum, on peut mettre des transactions d’échange de valeurs, mais aussi des transactions définissant de nouveaux programmes (les fameux smart contracts). Evidement, ces programmes ne sont plus arrêtables à partir du moment où ils sont livrés dans un bloc ethereum.

Et encore une fois, etherscript et son quasi-scratch éminement lisible est lancé.

Dans les exemples d’utilisation, la gestion des cartes volées est anecdotique. En revanche, la gestion du carnet d’entretien automobile dans une blockchain est intéressante, au sens où elle entre précisément dans le champ de la confiance faible : les acheteurs automobiles ont peu confiance en les vendeurs, qui peuvent produire de fausses factures. Stocker les informations dans un tiers de confiance distribué dans ce cas est franchement utile.

Stratumn et les workflow de confiance

Passons maintenant à Seb, de Stratumn … qui nous a mis sa présentation sur internet

Stratumn imagine un paradigme de fonctionnement de la donnée, qui permette d’arrêter les workflow débiles type renouvellement de la carte de séjour : un tiers produit des documents pour un autre tiers que je vais transporter en tant que tiers de confiance.

Et là, la meilleure description de la blockchain est donnée : c’est en fait une base de notarialisation ou de timestamping (selon la qualité de votre accent). En effet, les blockchains permettent simplement de s’assurer qu’une donnée est dans un état à un instant grâce à plusieurs propriétés :

  • immuabilité
  • auditabilité
  • inviolabilité

Typiquement, dans Bitcoin, en inscrivant des transactions minimales, on peut ajouter dans la transaction un hash qui indique qu’une donnée était dans un état donné avant que la transaction ne soit inscrite.

Ils ont donc créé chainscript.io qui permet de définir un workflow dans la blockchain. Alors j’ai un doute sur le concept de chainscript. Je m’explique : l’intérêt de la blockchain est de fournir une auditabilité totale. Or avec chainscript, on ne met dans la blockchain que des hashes. Et en fait, des hashes construit à partir d’innombrables transactions chainscript. Du coup, l’auditabilité en prend un sacré coup.

En revanche, je retiens comme un concept aussi fort que le théorème CAP la trinité des preuves établie par Seb :

  1. preuve d’existence
  2. preuve de calcul
  3. preuve de propriété

Avec ces trois éléments, on peut prouver que l’opération a bien été effectuée d’une façon immuable et inviolable. Et ça, c’est la clé de toutes les blockchains, à mon sens, et l’élément qui permettra d’en tirer un modèle économique, qu’il soit basé sur une blockchain privée ou publique.

Finalement, une bonne session, à part le buffet (qui a été le premier buffet à moitié loupé du chtijug).

Et pour finir, un dernier tweet de l’un de nos joyeux organisateurs qui va élargir le débat

Pas de chti jug sur Typescript pour moi

Ce soir, c’est chtijug sur Typescript. Et en plus, le lieu a l’air sympa.

Pas parce que je n’aime pas Cyril et ses amis, bien au contraire, je trouve le boulot du chijug vraiment chouette.

Mais plutôt parce que … comment dire … tout cet écosystème Javascript me fatigue à un point fou.

Je vous explique.

J’ai fait ma première page web avec du Javascript en 1999 … ou 2000. Bon, la wayback machine a une version datant de juillet 2001. Enfin bref. A l’époque, faire du Javascript était un sale boulot.

Heureusement, jQuery a tout changé. Et pendant quelques années, faire du web dynamique était raisonnablement simple conceptuellement et techniquement.

Et puis un jour, l’apocalypse de la sur-architecture s’est pointée sous les traits de nodejs. Je ne vais pas refaire l’article contre nodejs, parce qu’il suffit de regarder quelques twits de Mario Fusco ou Sam&Max pour comprendre

Et c’est quoi le rapport avec Typescript ?

Pour être honnête, Typescript n’est pas une solution, mais un élément du problème.

En effet, de mon point de vue, les langages modernes ont été créés pour permettre aux gens d’être plus productifs que l’assembleur ou le C, par exemple. Seulement, et au risque de choquer mes camarades Javaistes, le Javascript n’est pas ce genre de langage.

Non.

Comme l’écrivait Douglas Crockford il y a … un moment, le javascript n’est pas le langage qu’on croit. Et franchement, une fois qu’on comprend que le Javascript est un langage fonctionnel s’exécutant dans un environnement peu commode, il se passe une certaine épiphanie qui permet de mieux en comprendre la réelle simplicité. Une simplicité qui rend des monstruosités comme Angular, React, ou Typescript, aussi pratiques qu’un 38 tonnes en ville.

C’est aussi pour ça (en plus de ne pas assister à une conf sans doute intéressante sur un langage qui doit sans aucun doute avoir de bons côtés) que j’ai décidé de ne plus me lancer dans des projets front-end en utilisant autre chose que des bibliothèques simples (voire élémentaires) qui remplissent proprement une fonction simple et claire. Des outils comme

  • RequireJS
  • RactiveJS
  • jQuery
  • underscoreJS

Et sorti de là, comme disait il y a bien longtemps mon prof d’info, point-barre. Du coup, forcément, ce talk sur Typescript présentait un problème d’intérêt fondamental : comment diable pouvais-je m’intéresser à un langage dont la finalité actuelle est précisément de faire quelque chose qui me répugne au plus haut point ?

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