Evènements

De retour du Breizhcamp

Publié le : Auteur: Anteo Consulting 3 commentaires
Logo Breizhcamp

La semaine dernière se tenait l’édition 2013, la 3ème, du Breizhcamp, la conférence « Mix de Technologies » organisée par le BreizhJug et ses partenaires.

 

Cette conférence est un événement incontournable pour les développeurs de la région ouest, d’abord parce qu’elle est locale ce qui est confortable, d’autre part parce qu’elle est très abordable (40€ pour les 2 jours), et enfin et surtout parce qu’elle est aussi intéressante que sympa.

Et tout cela on le doit au superbe travail de l’équipe de bénévoles qui la prépare avec amour pendant tout l’hiver. Un grand merci à eux !

2 jours à enchainer les présentations et les hands-on, entrecoupés d’échanges avec les autres participants pour rester à l’écoute de ce qui se fait « ailleurs ».

Et en ce qui me concerne, le programme a été le suivant :

    • Extreme Startup, animé par Arnaud Bailly

Le terme désigne la rencontre du Lean Startup et de l’Extreme Programming

      • Volet startup : réagir à des modifications de cibles de marché/produit
      • Volet craftmanship : comment mes pratiques de développement vont m’y aider


Le programme présente la session de la manière suivante :

Extreme Startup est un atelier de programmation qui propose de simuler le développement d’une startup. Chaque binôme est en compétition avec les autres pour des « parts de marché », il doit répondre aux « besoins » des utilisateurs tout en gérant la dette technique du produit. Ce modèle permet de mettre en perspective deux modèles du développement de logiciels: Extreme Programming et Lean Startup, d’où le nom de l’atelier. Les plus agiles seront ils les plus riches ? Vaut-il mieux livrer une fonctionnalité ou rembourser sa dette technique en refactorant ? Les tests servent ils vraiment à quelque chose ? Voici quelques une des questions que cet atelier permet d’effleurer …

Concrètement, le déroulement est le suivant :

      • Chaque participant/binome lance un serveur http sur sa machine et va enregistrer son url sur l’application hébergée par celle de l’animateur
      • Dès l’enregistrement l’application de l’animateur va commencer à poser en boucle une série de questions à votre serveur http
      • Chaque réponse incorrecte, chaque 404 vous coûte des points (beaucoup !)
      • Chaque non-réponse vous coûte des points (quelques-uns)
      • Chaque bonne réponse vous rapporte des points (pas assez …)
      • Votre score est mis à jour continuellement avec le détail de ce qui vous fait gagner et perdre des points

A vous de développer rapidement le code nécessaire pour répondre rapidement aux questions posées. Et entre alors en jeu la stratégie du backlog : toutes les fonctionnalités (questions) n’ont pas le même intérêt business (ne rapportent pas le même nombre de points) et toutes ne demandent pas le même effort de développement !

Passons rapidement sur le résultat déplorable que j’ai pu obtenir pour en venir à l’essentiel : Vivement la prochaine session, car une fois compris le fonctionnement et en abordant la session avec les bons outils, l’exercice est assurement extrèmement ludique !

    • Je proposais sur la pause déjeuner une courte présentation de Datomic, une base de données NoSQL atypique : distribuée, ACID et immutable.

En voici les slides

    • L’après midi a de nouveau été studieux avec l’atelier « Stratégie de testing de code legacy » animé par David Gageot

Parce que dans la vraie vie, y’a du static partout, des frameworks fait-maison, des requêtes sql de 4 pages écrans et c’est là dedans que nous devons évoluer.

Et effectivement, le code qui nous est donné n’est pas beau à voir !
Et compliqué. Alambiqué.
Et ponctué de commentaires fort utiles comme « // t’es con michel » ou encore :

Le retravail de ce code se fait pour une part en binome, pour une part de manière collégiale en discutant les mérites des différentes approches possibles.

Il en ressort quelques enseignements intéressants

      • Il n’y a pas de méthode absolue. La stratégie à adopter dépend du contexte, du code, de l’objectif, de l’intérêt et donc du temps à y consacrer.
      • Il n’y a pas de chemin sûr, il y a des chemins moins risqués.
      • D’une part on ne peut pas nécessairement tester suffisamment un code avant de le modifier, et il faudra quelques fois d’abord l’adapter à minima de manière à pouvoir poser dessus des tests de non-regression pour les futures modifications
      • D’autre part, toute modification, et davantage encore les modifications manuelles, est susceptible d’introduire accidentellement des modifications du comportement. Pour limiter ce risque mon binome du moment faisait sien un conseil de Kent Beck : « make it easy to make and then make it », ce qui se traduit par l’application de quelques modifications bénignes sur une portion de code de manière à permettre l’utilisation d’un refactor proposé de l’IDE, plus fiable que leur équivalent manuel.
      • Il n’y a pas de chemin évident. Les choix se feront souvent au feeling, et le feeling n’est pas une science exacte. Le re-travail de code est un processus d’essai et d’abandon, où un gestionnaire de version est indispensable.

Et quelques techniques vues ou revues à garder en tête :

      • l’utilisation d’infinitest, hautement recommandable (mais qui faisait planter mon eclipse …)
      • mockito, son Runner Junit, et ses annotations @Spy, @Mock, @InjectMocks
      • Les asserts de la suite FEST
      • la suppression de l’appel aux factories par l’injection de dépendances via le constructeur
    • La dernière présentation de la journée concernait Grunt, un outil de build pour la partie web de vos applications (analyse statique de code, tests unitaires et minification du javascript, préprocessing CSS, création d’un sprit d’images, …).

Avec Yeoman et bower, un triptyque à la mode qui semble effectivement bien pratique.

    • Passée la keynote sans trop de saveur du matin, j’attaque la seconde journée par une présentation « Soft et Hard » par Laurent Huet et Nicolas Ledez qui nous montrent ce qu’ils font de leurs jeux de grands enfants (arduino et raspberrypi)

Une batterie à base de boite de cd et de piezo pour l’un, un euh … truc avec un capteur de proximité pour l’autre. Les capteurs émettent des signaux analysés par un nodejs embarqué qui envoie vers une page web (via des websockets) des ordres de sons à jouer en réaction. Le tout finit par un concert (heureusement court !).
Du hype et du fun, bien joué !

    • Web Components par Julien Vey.

Une présentation bien menée sur cette spécification W3C en cours de finalisation sur laquelle seront construites les bibliothèques de composants qui s’imposeront dans les années à venir.

    • Construire un SaaS dans son propre nuage par Yoann Dubreuil.

Un retour d’expérience très intéressant sur la mise en place d’un petit SaaS privé autour d’OpenStack chez un grand acteur des télécoms.

    • Horacio Gonzalez et Sébastien Lambour nous présentent leur travail autour de thrift, mongodb et grails

Leur objectif : composer un backend testable, évolutif, performant et productif. Tout en humour ils expliquent leur démarche et les solutions développées pour l’interconnection de ces trois briques. Je ne m’aventurerais à priori pas à les suivre, mais c’est rafraichissant de voir des alternatives aux sempiternels JEE/Spring/Play.

    • Vert.x ? C’est bon pour ton corps par Aurélien Maury.

Evidemment avec une accroche pareille il y avait du monde dans la salle.
Vert.x est un bus asynchrone sur la JVM pour le développement de système à base de message.
La démonstration était intéressante, avec un client angularJS dans le navigateur, abonné au bus du serveur et échangeant des informations par ce biais avec lui.
Cependant qu’en ressort-il ?
D’une part que Vert.x a l’air encore un peu … vert. Une toute petite communauté, et un modèle de programmation qui ne répond à priori pas à mes besoins du quotidien. Opinion non définitive …
D’autre part qu’Aurélien est un orateur aguerri qui sait inclure des poneys dans ses présentations 🙂

    • Spock, le testing nouvelle génération par Cédric Champeau

Il s’agit d’un DSL groovy facilitant l’écriture de tests, unitaires ou d’intégration, pour vos projets Java.
Un outil visiblement bien intégré aux IDE et aux systèmes de builds existants, à essayer.

    • Et pour conclure ces deux jours, j’ai assisté à la sympathique présentation « Soon in a galaxy not so far away » de Mathieu Ancelin dont le sujet comme son titre ne l’indique pas était les Iteratees, un système de traitement de flux apporté par Play2. Bien illustré, et une démo ludique à nouveau, il est des gens qui savent s’amuser !

Encore merci à l’équipe organisatrice, et en particulier à Nicolas Deloof, ne serait-ce que pour la musique et les quelques pas de danses « Breizhcamp Style » (parodie du mégahit de PSY) esquissés pendant la keynote (à quand la vidéo en ligne ?) !

A l’an prochain !

  • Dave

    Très intéressant en effet, ce compte-rendu est très complet. C’est vrai que le testing de code legacy donne souvent des migraines.

  • « Le tout finit par un concert (heureusement court !). »
    Comment ça !

    Je joue super bien de la batterie et je trouve que Laurent Michel Jarre a plus qu’assuré.

    Promis je m’entraine pour l’année prochaine.

    En tout cas, merci pour ce retour, ça fait super plaisir et à l’année prochaine (pour le concert).

  • harry

    Le BreizhCamp, c’est le coeur qui parle là 😀
    Merci pour tes notes