lundi 26 mars 2012

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.

vendredi 23 mars 2012

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!

mercredi 14 mars 2012

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 : 

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!.

vendredi 9 mars 2012

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!