Histoire d'une Cassandra Lan Party à Devoxx France

Genèse

Tout commença par un coup de fil de Nicolas Romanetti. un soir du début du mois de Mars.  

J'avais appris le mois précédent que mon Tool In Action sur cassandra-unit n'avait pas été retenu. Rien d'étonnant quand on voit la qualité des sujets qui ont été retenus.

Nicolas, lui, avait proposé 2 talks sur Cassandra : 

- le premier au format University : "Introduction à Cassandra". L'idée est de balayer sur 3 heures tous les concepts de Cassandra en prenant bien le temps du question/réponses mais dans un format très théorique basé sur des slides.

- le second au format Labs : "Hands On Cassandra". Ce "Hands On" devait initialement permettre aux participants de manipuler un peu cassandra "dans son coin" sur son poste.

Ces deux talks ont été sélectionnés (et se suivent sur la même journée, 2x3H). C'est ça les rockstars :-).

Histoire d'un coup de Fil :

N : Salut Jérémy, dis moi, je ne sais pas si tu as vu mais mes 2 talks ont été sélectionnés.

moi : oui énorme, c'est cool, les participants qui le souhaitent pourront faire une journée complète sur Cassandra!

N : J'ai besoin d'aide sur le Hands On, ça te dirait de me filer un coup de main?

moi : un coup de main comment?

N : Pour le Hands On, j'ai une idée, j'ai envie de changer légèrement le contenu, c'est ok avec les organisateurs mais il me faut une équipe. J'ai envie de faire une Lan Party.

Moi : Comme celle qui a eu lieu à NYC?

N : Yes

Moi : BANCO! C'est parti pour une Cassandra Lan Party à Devoxx France.

Lui : Tu es où toi?

Moi : sur Lille et toi?

Lui : Ajaccio ;-)

C'est comme ça qu'on se retrouve dans le même bateau, Nicolas, Florent, Sylvain et moi.

Il y aura donc une Cassandra Lan Party à Devoxx France :

- http://www.jaxio.com/2012/03/21/cassandra-party-devoxx-france.html

- http://www.devoxx.com/display/FR12/Hands+on+Cassandra

Préparation

On en maintenant mi-mars. Devoxx, c'est quand même dans un mois. Alerte générale!

On échange pas mal entre nous par mail et sur un petit google doc partagé. Le point noir, c'est le réseau, la seule façon pour que ça se passe sans problème, c'est de ne pas compter sur celui de Devoxx et donc c'est de venir avec à Devoxx. "Qui a des switchs? Heu... Personne... ". Tout le reste n'est que de la préparation et du détail (ou presque ;-)). Pas de switchs, pas de Cassandra Lan party! On lance alors un appel à la population.

Nous n'avons pas eu tant de retour que ça mais des retours gagnants! :

- Euratechnologies répond OK et nous prête 3 switchs professionnel 24 ports en gigabit neuf ainsi qu'une quarantaine de câble RJ45 de différentes longueur!

- Thomas Recloux, un ami un peu geek ;-), me prête aussi son switch personnel (enfin pro ;-)) de 24 ports en gigabit neuf.

Côté matériel, c'est tout bon.

En parallèle nous contactons Jake et Edward, les organisateurs de la Cassandra Lan Party de NYC, pour avoir leur feedback. Pour faire simple : c'était fun mais la génération et l'attribution du token n'a pas fonctionné comme ils le voulaient

Hey mais nous sommes début Avril! Alerte générale!

L'idée émerge alors dans nos esprits de faire une application web pour aider les participants à récupérer leur token et configurer leur noeud cassandra. L'application web de la cassandra-lan-party, vient de naitre, 2 nuits pour coder ça en équipe, un peu de spring-mvc, de twitter bootstrap et hop. Nous mettrons prochainement les sources à disposition.

De mon côté, je récupère le matériel et je fais des tests (je ne vous raconte pas comment madame était contente de voir ça dans le salon :-)) : 

On peaufine aussi les slides.

Tiens si on se faisait un tee-shirt, ça aiderait les participants à nous identifier plus facilement s'ils ont des problèmes :

Répétition

Il n'y a pas de secret, il faut répéter! Ca nous permettra accessoirement de nous rencontrer IRL ;-)

Nicolas organise la semaine précédent Devoxx France, une répétition chez Zenika. 

C'est parti pour Paris, mais tiens, c'est vrai, il faut transporter tout le matériel réseau... : 

Est-ce que la valise va fermer?

Voici le récit de la répétition ainsi que les photos.

Nous avons mis en place 18 noeuds Cassandra sur différent OS sur 3 Datacenters.

Pour la petite anecdote, Tout le monde arrive progressivement pour la répétition, Je dis bonjour à plein de participants. On commence à s'installer et je dis à un moment à Nicolas, "On attend Florent pour commencer?" et là j'entend une voix qui répond derrière moi "ben je suis là". Moment de solitude ;-)

Nous avons pas mal de feedbacks intéressants et avons la confirmation qu'une application web pour aider les participants à récupérer leur token et configurer leur noeud cassandra est une très bonne idée, on nous donne même des idées de feature en plus. Merci Brice. C'est l'heure de recoder un peu dans l'application web et modifier les slides :-).

The D Day

Le matin, Nicolas a fait un super talk sur Cassandra. Simple, clair, précis et efficace. De très bon échange avec le public. Voici les slides.

Mais c'est maintenant déjà l'heure du Hands On!

Dans un premier temps, nous avons eu la chance d'avoir la salle du Hands On en avance. C'était d'ailleurs assez drôle de voir les serveurs préparer la salle avec des petits napperons, des verres et des bouteilles d'eau avec les tables et les chaises bien alignées avant que nous en prenions possession :-). Une fois la salle à disposition, hop, on enlève tout, on bouge tout pour constituer 3 zones avec les tables pour représenter physiquement 3 datacenters avec les chaises dans tous les sens, bref une Lan (merci Thomas pour le coup de main lors de la mise en place!)

La Cassandra Lan party s'est déroulée en 3 étapes :

- installation/configuration du réseau

Tout les participants se branchent par datacenter sur un switch. On note les IPs sur des Post-its. Un slide explique la conf réseau à effectuer ainsi que des tests pour vérifier que tout est ok.

- installation/configuration de Cassandra

Des clés USB sont distribuées. Il est possible d'installer Cassandra soit par les clés USB soit en la téléchargeant depuis notre application web. Les slides expliquent le paramétrage à effectuer... 

L'application Web fournit le token et précise les éléments de configuration à modifier dans Cassandra :

- démarrage et exécution de différents scénarios sur le cluster

Voici les caractéristiques du cluster cassandra :

• 3 datacenters.
• Utilisation du RackInferringSnich
• 3 seeds (un par DC)
• Replication Factor de 9 (3 par DC).

Nous avons démarrer dans un premier temps les 3 seeds (Sylvain, Florent et moi) puis dans un second temps nous avons démarrer progressivement tous les autres noeuds.

Et là, problème, les noeuds cassandra sur les machines windows ne veulent pas rejoindre le cluster, merci windows et à son firewall ;-). Une fois le firewall coupé, tout le monde arrive à rejoindre le cluster.

Notre cluster est constitué de 36 noeuds. D'un point de vue de l'équipe, on sait déjà qu'on a remporté notre   pari. Le reste n'est que formalité ;-).

Nous avons mis en place un cluster Cassandra de 36 noeuds réparti sur 3 datacenters sur tout type d'OS.

La Cassandra Lan party de NYC est battue :-)

C'est maintenant l'heure de jouer avec le cluster.

Par l'intermédiaire de nodetool, les participants interrogent l'état du cluster et par l'intermédiaire de cassandra-cli, ils écrivent et lisent dans le keyspace créé pour l'occasion. Nous faisons d'abord tombé et revenir un DC puis nous faisons tomber et revenir 2 DCs. Les participants constate en live comment le cluster réagit... Bref, facile, c'est Cassandra, c'est fait pour ça :-)

- un peu de théorie pour terminer

Après une petite pause, les questions commencent à arriver en nombre et c'est le moment de repartir sur quelques slides pour pouvoir y répondre : le datamodel, le ring, le partitioner avec le token, le replication factor, le consistency level, tout y passe. Nicolas était bien au point après l'university du matin!

Toutes les photos de la Cassandra Lan Party sont ici

Les slides utilisés sont ici

Le mot de la fin

Les objectifs étaient que les participants :

- mettent les mains dans le cambouis!

- constatent que Cassandra, ça n'est pas compliqué!

- s'amusent!

Je ne suis pas très objectif justement mais je pense que nous ne sommes pas loin de les avoir tous atteints!

Pour ma part :

- ça a été super fun.

- l'ambiance était décontractée et conviviale.

- une valise de 40kg à trimballer, c'est lourd!

Merci à tous les participants de s'être prêté au jeu!

Bref. Je passe freelance

Hello tous!

Voici un post un peu différent de ceux que j'ai l'habitude d'écrire. Il est beaucoup moins technique, beaucoup moins agile et beaucoup plus "moi".

Ce post juste pour vous dire que je me lance bientôt en tant que Freelance IT sur la region Lilloise. Je vais proposer mes services autour de ces domaines #nosql #cassandra #java #spring-* #Play! #web  #openSource #mobilité #agilité #Scrum #XP #coaching #architecture #...

Ce projet fait suite à 2 très belles expériences dans 2 entreprises très différentes, la première dans une SSII chez Norsys et l'autre chez un petit éditeur logiciel Sarbacane Software. Un petite dédicace d'ailleurs à l'équipe de développement que je quitte : Jeremy, Yannick, Antoine, Nico, Marc et Yohan! N'oubliez pas les mecs : K.I.S.S. :-)

Mon backlog de "passage indépendant" est encore bien rempli. Je ferai peut être un post sur la mise en place de cette nouvelle aventure, peut être sous forme de retour d'expérience si le contenu vaut le coup :-)

Bref. Je passe Freelance.

Cassandra Lan Party : We need you!

La nouvelle est tombée hier : il y aura une Cassandra Lan Party à Paris à Devoxx! Elle aura lieu pendant le Hands On Cassandra (la description du Hands On est en cours de mise à jour).

Nicolas, Florent, Sylvain et moi vous aiderons et vous accompagnerons lors de cette session.

Comment??? Vous étiez passé à côté de cette News??? Pourtant la terre a dû s'arrêter de tourner au moins pendant 2 secondes :-).

Une Cassandra Lan Party, c'est quoi?

Vous souvenez-vous des Lan Party Counter Strike ou Quake que vous faisiez dans votre garage ou dans un immense hangar quand vous étiez plus jeunes (ou que vous faites encore ;-))? 

(ok, nous serons beaucoup moins nombreux) 

L'idée de reprendre tous les ingrédients de ce type d'évènement plutôt fun, convivial et participatif et de l'appliquer à Cassandra.

Tous les détails de l'évènement se trouve sur le blog de Jaxio.

We need you!

Nous allons recréer un réseau ethernet pour l'évènement. 

Nous lançons donc un appel général pour que cet évènement puisse se réaliser : 

Nous sommes à la recherche de matériels réseaux à prêter pendant une quinzaine de jours :

- 3 gros switchs ethernet (20 ports mini par switch) en gigabit.

- des cables RJ45 de différentes tailles (3 mètres mini).

Nous faisons donc appel à vous, si vous avez ce type d'équipements et que vous souhaitez nous le mettre à disposition, nous en prendrons grand soin! Nous ne manquerons pas non plus de vous remercier pendant le Hands on!

Si vous n'avez pas ce type d’équipements, n'hésitez pas à en parler autour de vous!

Vous pouvez me contacter par mail à jsevellec at gmail dot com ou sur twitter @jsevellec

A bientôt à Devoxx!

Integration Continue avec Play! et Jenkins

On parle souvent de Play! pour dire que c'est un super framework pour faire du web simple, efficace, génial, fun, wouahou, ...

(Pour infos, si vous n'étiez pas au courant, la version 2 de Play! vient de sortir. Plus d'infos ici)

On peut aussi dire que c'est un framework web qui permet de faire du TDD, de faire des tests unitaires, des tests d'intégrations et des tests selenium. Bref, faire du test avec Play!, ça n'est pas un problème. Je peux d'ailleurs vous le confirmer car j'ai pu tester la mise en oeuvre d'une démarche TDD sur une application play! avec succès.

Il est même possible, en faisant attention à quelques petites choses, de faire de l'intégration continue avec Jenkins et Play!  (1.X) :

Assurer que vos tests fonctionnent en local

Assurez-vous que vos tests sur votre poste de développement soit bien exécutés par Play! lorsque vous faites un :

play auto-test

Si ce n'est pas le cas, ça ne sert à rien d'aller plus loin. Il faut déjà régler ce problème. Ça a été mon cas. Cela peut provenir de là : Vos tests unitaires doivent impérativement hériter de : UnitTest ou BaseTest (une classe abstraite de Play!) sinon vos classes de tests unitaires ne seront pas exécutées : 

https://play.lighthouseapp.com/projects/57987/tickets/1074-feature-request-run-junit-tests-not-extending-basetest

Installer le Jenkins play-plugin
Comment déployer une application Play! dans Jenkins? : "There's a plugin for that"

Il y a en effet un plugin pour ça : jenkins play-plugin.

Vous pouvez suivre la procédure d'installation indiquer dans la documentation du plugin :

- Décompresser le zip de Play! sur le serveur qui héberge Jenkins dans un répertoire de votre choix.

- Installer le plugin Play! dans Jenkins par l'intermédiaire du menu d'administration de Jenkins.

Créer un Job

Il suffit ensuite de :

• créer un job freestyle.
• définir l'url de votre DVCS. (Je n'ai aucun doute, que vous allez saisir une url Git :-)).
• définir ce qui déclenche les build (personnellement, je scrute l'outil de gestion une fois par heure : 5 * * * *).
• Ajouter une étape au build : Play!
• Renseigner les commandes play à exécuter. A la différence de la documentation du plugin et comme le serveur se trouve derrière un proxy d'entreprise voici la liste des commandes que j'ai saisies : 
• clean
• dependencies --sync -Dhttp.proxyHost={your-proxy-host} -Dhttp.proxyPort={your-proxy-port}
• auto-test

(Je n'ai pas réussi à faire fonctionner l'option --deps qui aurait permis de grouper la commande 2 et 3 comme décrit dans la doc du plugin en faisant simplement :  "auto-test --deps").

• cocher : "Play! auto-test reports" pour générer les rapports Play! intégré dans Jenkins.
• notifier par email ceux qui doivent l'être.

et c'est tout : run... et hop ça marche.

Vous pouvez voir les rapports d’exécution dans le détails de l’exécution du job dans le menu latéral "Play! Test Result"

Bref, je fais de l'intégration continue avec Jenkins et Play!.

Maman, j'arrête les couches!

Oui maintenant je suis grand : j'arrête les couches (logicielles :-)).

Derrière ce titre un peu provocateur, il y a une vraie réflexion de fond. Les architectures en couche, est-ce vraiment utile? En tous cas, mes récentes expériences en terme de développement me font réfléchir. Voici où en est ma réflexion :

Les couches c'est "historique"

L'architecture logicielle est un très vaste sujet qui évolue sans cesse. Les technologies évoluent, les informaticiens évoluent. Il y a même des effets de mode mais qui peut répondre à la question universelle  : C'est quoi "La" bonne architecture? (si quelqu'un connait la réponse, je suis curieux qu'il me l'explique ;-))

Si on prend un peu de recul et que l'on regarde un peu dans le rétroviseur, on peut constater que les architectures logicielles n'arrêtent pas d'évoluer. Après les architectures client/serveur, il y a eu les architectures 3 tiers puis les architectures n-tiers puis les architectures infini-tiers. Après les architectures infini-tiers, comme cela devenait vraiment trop un plat de spaghetti, de nouveaux concepts sont apparus comme "l'urbanisation" et les architectures orientées services qui, en plus de découper une application horizontalement, propose un découpage vertical.

L'urbanisation, ça veut tout dire et rien dire. On peut parler d'urbanisation à différents niveaux, cela peut aller de la façon de décrire la manière dont le code d'une application doit être découpé à comment structurer un système d'information, la planète, l'univers... 

Si l'on reste à un niveau applicatif, l'idée derrière l'urbanisation c'est de définir des règles pour contraindre le développement dans le but d'organiser et de rendre réutilisable des services. L'objectif des architectures urbanisées est de pouvoir proposer un ensemble de service métiers réutilisable sans même savoir qui pourra les utiliser. Au final on se rend souvent compte qu'il est très dur de définir un service sans savoir qui va le réutiliser.

Oui j'ai dû développer sur ce type d'application. En tant que développeur, l'avantage (le seul que j'ai trouvé...) c'est de proposer un cadre très stricts de développement qui peut aider sur de très grosses équipes de développement. L'inconvénient, c'est d'oublier de réfléchir (ouch mais c'est dangereux ça! ;-)) à la façon de faire les choses et surtout c'est la lourdeur/lenteur de développement :

Développer un simple service de lecture d'un utilisateur dans un contexte de surarchitecture peut ressembler à ça : 

- développer le code utile dans le Dao.
- développer la méthode dans la couche du dessus en appelant la couche la méthode du DAO...
- développer la méthode dans la couche du dessus en appelant la couche du dessous...
- développer la méthode dans la couche du dessus en appelant la couche du dessous...
- développer la méthode dans la couche du dessus en appelant la couche du dessous...
- développer la méthode dans la couche du dessus en appelant la couche du dessous...
- développer la méthode dans la couche du dessus en appelant la couche du dessous...
- développer la méthode dans la couche du dessus en appelant la couche du dessous...

On est content quand on arrive enfin à l'IHM! Ce qu'on retient en tant que développeur, c'est que ce n'est pas très FUN et que la majorité du temps, toutes les couches intermédiaires sont inutiles...

En général ce type d'approche s'accompagne d'un bon gros dossier d'architecture qui, avant même d'avoir écrit la moindre ligne de code, propose le design global de la solution (à la fois en terme de choix technique mais surtout en terme de découpage logique...).

Oui j'avoue, j'ai aussi déjà fait ce type de dossier...

Le danger de tout ça, c'est la "surarchitecture" : c'est à dire de prévoir des choses qui sont plus complexes que nécessaires, qui entraînent une lourdeur de développement et qui ne serviront à rien.

Et sans couche, comment ça peut marcher?


Ça commence mal, car je vais déjà commencer par vous dire que ce n'est pas vrai, il y en toujours des couches. En revanche je vous propose de n'en garder que 2 : l'IHM et le reste de l'application (mais c'est que ça ressemble au bon vieux client/serveur ça).

Là où je pense qu'on peut faire différemment c'est de, par défaut, ne pas définir de structure ou de règle pour le reste de l'application avant de commencer. Et là certains vont me dire : Mais vous êtes fou! Ho oui :

Mais non, je ne suis pas fou!

Pour ça, je vous propose 2 retours d'expériences de développements applicatifs différents qui vont dans ce sens :

- TDD et KISS.

Le premier retour concerne le développement d'une application basée sur Cassandra (from scratch) que j'ai développé en full TDD (Test Drivent Development) avec un état d'esprit KISS (Keep It Simple and Stupid). C'est une application sur laquelle je n'avais fait que le minimum de choix techniques (mais il en faut un peu quand même) et aucun choix logique (à part un découpage IHM / reste de l'application). Le TDD s'est chargé du reste et a fait émerger le design. C'est très étonnant à vivre. J'avais par exemple refusé initialement de mettre en place le pattern DAO et il est apparu à force de refactoring...

- Play!

Le deuxième retour concerne le développement d'une application que j'ai faite récemment avec Play!. Et là, je me suis pris une belle claque. Play! est un framework web Java fait pour faire du Web, centré sur le design par URL, sur la simplicité et sur l’efficacité. Tout est différent et tout est simple : attribut public, méthode d'accès la BDD dans les entités, un fichier de conf et tout est convention over configuration... J'ai développé l'application en un temps record avec très peu de bug et un code très lisible. Je suis même encore surpris sur le peu de code écrit pour "faire le job". Un dernier point important, c'est le plaisir que l'on prend à développer dans ce type de contexte : C'EST LE PIED. Si l'on se recentre un peu nos fameuses couches, Play! est aussi centré sur le principe du design simple avec grossomodo une couche IHM et le reste de l'application...

Pour Conclure

Je dirais simplement que : 

- Ce n'est pas parce qu'on commence simple et sans couches, qu'on ne pourra pas en créer. Le refactoring est fait pour ça.

- Les architectures simples sans (trop) de couches ne sont pas réservées aux petites applications, bien au contraire.

- Ce n'est pas parce qu'on sait qu'on a à faire à une "grosse" application qu'il faut obligatoirement vouloir tout structurer avant de commencer.

- Il faut être bien outillé pour commencer simple : soit d'un point de vue méthodologique comme de TDD soit par du "framework qui permet de faire simple".

- qu'il ne faut pas non plus mettre les requêtes SQL dans les JSP :-)

Vous aussi, vous êtes grands, vous pouvez arrêter les couches!