Vendredi dernier a eu lieu la première édition de NCrafts, une conférence centrée sur les technologies .NET. Indépendant de Microsoft, cet événement regroupait des speakers de la communauté “alternative” qui parlaient de pratiques, de software craftsmanship et d’architectures avancées. Retour sur une conférence à l’opposé des Techdays.
Pour démarrer la journée, Itamar nous propose de remettre en perspective ce qui nous permet de réaliser une recherche : qu’est-ce que la donnée, comment en extraire l’essence et les sens, comprendre la nature de la requête pour mieux répondre à l’utilisateur...
Ce qui était bien
Un sujet encore trop souvent négligé et pourtant au coeur de beaucoup de métiers : la donnée.
L’application des même patterns sur des données totalement différentes et la façon de le faire (documents, images, logs, …).
Une live démo sexy.
Ce qui était moins bien
Ce qu'on en retient
La donnée est plus que ce qu’il y a dans la base de donnée métier : il faut aussi considérer les logs, les données de navigation, les inputs utilisateurs...
L’indexation est l’inversion de la relation contenant-contenu pour permettre la recherche. On passe de “ce document contient cette donnée” à “cette donnée est contenue dans ce document”.
L’indexation de donnée textuelle = extraction de données + tokenisation + normalisation.
Le but d’une bonne recherche n’est pas de trouver LE résultat, mais LES MEILLEURS résultats.
Il n’est pas nécessaire d’avoir des données structurées pour les requêter, il faut en extraire le sens, soit par transformation, soit par agrégation.
La donnée n’est pas importante, c’est son utilisation qui l’est.
La requête est aussi de la donnée, en trouvant un “sens” à la recherche, son analyse permet de se rapprocher de l’intention du chercheur.
Nouvelle méthode de modélisation, l’event storming est un atelier qui consiste à faire émerger le modèle à partir des évènements ayant provoqué un changement d’état (au passé donc), comme par exemple “le client a déclenché le paiement”. On s’arme alors de post-it et de feutres, que l’on colle sur le plus grand espace disponible (une mur par exemple). Cette technique va ensuite permettre de faire émerger les commande, puis de rassembler des sous-ensembles fonctionnels.
Ce qui était bien
Un workshop dynamique avec des gens agréables.
Le format: debout face au mur, armé de crayon et post-it.
Un sujet “real life” autour d’un programme de fidélité pour les commerces de proximités.
La maîtrise du sujet.
Ce qui était moins bien
Le nombre de personnes, et donc de groupes, qui nous a contraint à passer rapidement sur chaque cas.
Une conclusion un peu rapide par manque de temps.
Ce qu'on en retient
Prévoir de la place, beaucoup de place, afin de ne pas être limité par l’espace disponible sur le nombre de post-it.
Intégrer l’ensemble des équipes du projets, y compris le marketing, etc…
Pas de hiérarchie pendant l’atelier, chacun dispose de son crayon (attention a ce qu’il fonctionne bien), ses post-it (tous de la même couleur). Toutes les propositions ont la même valeur.
Éviter de faire des sessions de 4h, mais de plus petites sessions (30-45min), en ciblant des pans fonctionnels.
La mise en avant des conflits / interrogations: un simple post-it rouge avec “!” ou “?”.
Jean-Baptiste nous parle de Roslyn, le compilateur open-source pour les langages C# et VB.NET développé par Microsoft. Au travers de plusieurs APIs, Roslyn nous offre la possibilité de découvrir ce qu’il se cache dans la boite noire du compilateur. L’accès aux arbres syntaxiques et à la sémantique nous permet déjà de réaliser des Diagnostics (détection de la mauvaise utilisation d’une méthode, anti-pattern, etc…), et d’en proposer un Fix (correction du code, refactoring, avec une preview directement dans l’IDE, façon Resharper). De quoi faciliter les upgrades de librairies, le refactoring, l’AOP ou encore de large migration de code.
Ce qui était bien
Une présentation claire faite à la main (Andersons’s style).
Une petite remise à niveau sur le travail du compilateur (Lexer, Parser, ...).
Le patching en live de Roslyn sur la déclaration des IEnumerable : un bon exemple de l’ouverture du compilateur, mais à ne pas refaire à la maison.
Mais aussi des cas plus concrets autour des APIs de UnityVS.
Ce qui était moins bien
Ce qu'on en retient
Roslyn permet de passer d’une boite noire complètement opaque à un compilateur totalement ouvert avec de multiples niveaux d’API.
Un retard sur les autres langages de développement bientôt rattrapé par Microsoft.
De très nombreuses possibilités s’ouvrent à présent pour l’outillage autour de .NET…
… avec déjà la possibilité de réaliser des diagnosctics et des fix.
On est cependant loin de pouvoir se séparer de Resharper, à qui il reste encore pas mal de beaux jours
On espère pourquoi pas une intégration avec Nuget permettant d’embarquer des diagnostic et des fix en même temps qu’on ajoute une librairie à son projet.
Pattern qui conduit généralement à des problèmes pourtant bien connus de maintenabilité, réutilisabilité, interdépendances, lenteur des rythme de déploiements, etc…
La solution proposée ici est un découpage en modules et non en tiers applicatifs. On se concentrera alors sur la communication des modules et leurs interfaces, plutôt que sur du code legacy (pas toujours très propre). On commence donc par se baser sur un protocole de communication (REST, ServiceBus, WebService, …) qu’il faudra alors choisir avec soin selon les points critiques de notre application. Il suffit ensuite d’encapsuler le code Legacy dans des interfaces propres et bien définies, et de rendre le tout accessible via APIs.
Ce qui était bien
Un sujet assez peu abordé et pourtant essentiel.
Pas un simple pattern théorique, mais une réalité en prod actuellement.
Une présentation language agnostic.
Un talk clair et bien mené.
Ce qui était moins bien
Peut-être un passage, même rapide, sur l’infra nécessaire à une telle architecture aurait été le bienvenu.
Voir une peu de code pour concrétiser un peu plus le sujet
Ce qu'on en retient
“Start small”: comme tous les refactos, si on commence trop ambitieux, on finit par tout toucher d’un coup (et on y passe des mois).
Choisir un protocole de communication adapté à l’application.
Définir des interfaces propres, qui se contenteront dans une premier temps d’encapsuler le Legacy code.
Se concentrer sur la communication entre les modules plutôt que les modules eux-mêmes.
Réitérer sur chaque module de la même manière, afin de tous les isoler avant de commencer à passer du temps sur le Legacy d’un module.
Ne pas hésiter à laisser un module peu critique avec du Legacy pas forcément très propre pour se concentrer sur les modules au coeur du système.
Un talk très technique autour du C#: comment réaliser une application low-latency avec du code managé.
Véritable chasse au Garbage Collector et aux allocations, cette présentation a le mérite de nous dire “Oui c’est possible (mais ce sera pas simple) !”.
Ce qui était bien
Un sujet très technique, avec du code et tout !
Une véritable enquête de terrain qui s’est avérée très intéressante.
Des détails pointus sur les patterns appliqués.
Ce qui était moins bien
Ce qu'on en retient
Inutile de courir après la micro-optimisation (i++ ⇒ ++i, foreach() ⇒ for(), ...)
Le GC n’est plus notre ami.
Moins on a d’alloc, mieux c’est.
Et pour ça, les Structs sont nos amis…
… mais attention au boxing lorsqu’on les utilisent avec leurs interfaces !
