Chiron (1/11) : introduction

[Laurent Caillette]

Chiron est un socle technique en Java pour écrire des applications connectées.

Chiron promeut un style architectural basé sur le sourçage d'événements, la programmation réactive, les actualisations impromptues poussées par le serveur ("push") avec le protocole WebSocket. Cela implique certains idiomes pour structurer le code applicatif.

Chiron a validé mes idées pour mettre au placard les SGBDR ainsi que plein d'autres trucs dont l'utilité n'a jamais été remise en cause depuis au moins 20 ans. L'objectif restant d'écrire plus vite du code plus clair et plus performant avec plus de tests qui passent plus rapidement.

Les sources de Chiron sont disponibles sur "GitHub"

https://github.com/OTCdLink/Chiron-framework

sous license `Apache 2`. OTCdLink est une entreprise dont je suis cofondateur, et qui développe une plateforme de négociation de produits dérivés. Chiron a été développé au sein d'OTCdLink pour cette plateforme.

Chiron est rendu public à des fins de promotion auprès des développeurs, une fois qu'on aura des sous pour recruter. 

Chiron est livré en l'état. Tout ce que je peux jurer c'est que la plupart du temps les tests passent sur ma machine. Le reste, et notamment la stabilité de l'interface programmatique, c'est sans garantie. Il n'y a pas de livraison versionnée, pas de construction continue, pas de joli site avec des couleurs à la mode, et la seule documentation hormis la Javadoc tu es en train de la lire. 

=== Quelques données techniques

Les principales dépendances de Chiron sont `Java 8`, Netty et Guava. (On peut compter Project Reactor comme dépendance annexe.)

Chiron compte environ `55.000` lignes de code Java, tests compris. (Ce chiffre correspond à l'indicateur SLOC de l'excellent SLOCCount de David A. Wheeler.)

La construction s'effectue avec Maven et implique environ 400 tests unitaires à ce jour.

Je n'ai pas calculé la couverture ; il y a quelques bouts de code qui ont bénéficié de "PiTest"

http://pitest.org

, un outil de test par mutation qui s'assure que les tests détectent des altérations du code testé. 

=== Chiron: mais il sort d'où ce nom ?

Allez, un peu d'histoire. L'article de "Wikipedia"

https://fr.wikipedia.org/wiki/(2060)_Chiron

nous dit :

<<

`(2060) Chiron`, aussi désigné comme `95P/Chiron`, est un astéroïde cométaire de type centaure, un corps glacé de 166 kilomètres de diamètre orbitant autour du Soleil entre Saturne et Uranus.

>>

À l'origine on a un jeu de mot obscur autour de COMET. Le projet s'appelait tout d'abord Shoemaker, et utilisait CometD, une bibliothèque pour faire du COMET. COMET est plus ou moins l'ancêtre l'ancêtre de WebSocket. Shoemaker est le nom d'un astronome ayant découvert une famille de comètes. Plusieurs facteurs ont justifié l'abandon du nom de Shoemaker :

- Le remplacement de CometD par Netty (et de ce fait, `(2060) Chiron` n'est pas une comète).

- La lecture d'un article de Wikipédia relatant la fin tragique de la comète `Shoemaker-Levy 9`, qui s'est engloutie dans Jupiter en 1994 (je n'ose pas dire écrasée car Jupiter est une planète gazeuse). 

- La nécessité de casser plein de trucs parce qu'on ne sait pas tout dès le début.

Donc Shoemaker est devenu Chiron, qu'il faut prononcer "kaï-ronne". 

Du fait de la signification astrologique de Chiron, il existe un caractère Unicode éponyme `U+26B7`, ce qui résoud d'emblée la question compliquée du logo. Le caractère CHIRON est un K majuscule dont la jambe verticale vient s'ancrer dans un cercle. 

Si tu as de la chance ton client de messagerie l'affiche correctement : ⚷

Tiens je n'ai pas essayé le caractère CHIRON dans les noms de package Java.

=== Pourquoi écrire quelque chose de nouveau ?

Écrire quelque chose de nouveau c'est compliqué et on n'est jamais trop sûr du résultat. Le plaisir de l'aventure c'est bien beau mais quand on est confondateur de la boîte, l'aventure on la finance de sa propre poche et c'est tout de suite moins excitant. 

Pour ne citer que les socles techniques basés sur Netty, on a déjà Ratpack et `Vert.x` qui sont utilisés par plein de gens pour faire plein de choses bien. Alors, pourquoi ne pas s'en contenter ?

Ces deux produits sont conçus pour ne //pas// orienter la modélisation applicative. C'est marqué en gros dans la doc. Ils trient les patates sans dire comment les ranger ; ils se branchent sur divers protocoles et appellent du code applicatif en fonction des critères de sélection fournis, mais après c'est chacun pour soi. `Vert.x` intègre Hazelcast et fournit des connecteurs avec des trucs ébouriffants comme Kubernetes, OpenShift2 ou Hawkular (attention à pas se faire hawkul... pardon). C'est trop génial mais c'est quoi la formule pour transformer ça en application qui sert à quelque chose ? Ah, "On me laisse le choix." Ça veut dire que les mecs ne savent pas, ou qu'ils ne veulent pas me le dire ?

Je ne vais pas entamer le procès de `Java EE` et des conteneurs de Servlets, mais question modélisation applicative c'est pas la fête non plus. Par nature ils fonctionnent avec le modèle requête-réponse qui correspond à la dépendance implicite vers un SGBDR. Si on veut faire entrer des comportements asynchrones là dedans ça passe par une plomberie d'envoi de messages conçue pour rendre les choses encore plus compliquées donc on oublie.

Ce que je voulais c'est un machin contre lequel je n'aie pas à lutter pour dire "balance telle donnée vers la session de l'utilisateur X" ou "pète-moi la session de l'utilisateur Y." Je voulais aussi :

- Du typage statique.

- Des données immuables.

- Du code applicatif séquentiel.

- Des actualisations impromptues ("push"). Ça change beaucoup de chose et nécessite un contrôle fin de la plomberie réseau.

- Un effort de déploiement minimal. 

- Ne pas multiplier les langages pour raconter la même chose (XML et SQL au revoir), autrement dit tout faire en pur Java. 

- Ne pas payer pour un système distribué quand tout tient largement sur un seul serveur.

Eh ben maintenant j'ai tout ça et c'est trop bien pour ne pas en faire profiter les copains.

Faut juste qu'ils aient envie de réapprendre comment concevoir des applications.

[Dominique Jocal]

Salut laurent, bonne année 2018 et bravo pour ta publi,

quels types de Frontend et de Backend pour une chiron-app?

Pas de bdd sql si je comprends bien... quoi à la place?

A+

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "techos".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse techos+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse tec...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/techos.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Laurent Caillette]

Salut Doj, bonne année à toi aussi.

Je détaillerai le front-end dans l'épisode 5. Pour répondre à ta question, dans l'immédiat Chiron implique une JVM aux deux extrémités. 

Pour le back-end ça sera dévoilé à partir de l'épisode 3. Les plus impatients peuvent me niquer l'effet de surprise devant tout le monde ("spoiler") grâce à une lecture attentive du code source, qui est là pour ça.