Nouvelle journée à la Devoxx, toujours aussi chargée !
Objects and functions, conflict without a cause ?
Durant cette keynote, Martin Odersky (le concepteur des génériques Java et du langage Scala, excusez du peu !) nous a fait un tour d’horizon des différences entre programmation objet et programmation fonctionnelle.
La programmation objet est apparue car on a souhaité concevoir des applications basées sur une API figée, mais avec des implémentations inconnues (cas typique des interfaces graphiques). Ceci est réalisable en C classique, mais conduit vite à une complexité trop importante. La programmation objet va permettre de travailler à un niveau d’abstraction plus élevé.
Aujourd’hui, la programmation fonctionnelle commence à percer car elle se met à répondre à un besoin apparu récemment : la scalabilité horizontale et la programmation parallèle. En POO, pour avoir plus de capacité de calcul, il faut augmenter la taille de la machine qui fait tourner le code (scalabilité verticale). Avec l’arrivée de la virtualisation et du cloud, on souhaite au contraire augmenter notre capacité par une augmentation du nombre de machines (scalabilité horizontale).
Pour Martin Odersky, les 2 paradigmes peuvent très bien coexister. Il faut juste parfois changer ses pratiques de développement (bannir les mutables à jamais) et considérer l’objet pour la structuration des données et le fonctionnel pour tout le traitement.
Elastifiez votre application : du SQL au NoSQL en moins d’une heure
David Pilato et Tugdual Grall nous ont proposé en moins d’une heure de migrer une application classique JEE (JPA + JSP) en une application NoSQL (NoSQL + Rest). Pour les personnes qui ne le saura pas encore, NoSQL est un mouvement qui vise à remplacer les bases de données relationnelles classiques par des bases de données structurées autrement, par exemple orientées documents ou colonnes.
Une telle transition peut se justifier par la non-scalabilité de l’application initiale. Si l’entreprise connaît un grand succès, les limitations du monde des SGBDR empèchent la scalabilité horizontale. Sauf à augmenter (à très forts coûts) la taille des machines d’hébergement, impossible d’obtenir la capacité de calcul nécessaire. En prime, on va pouvoir avoir accès à moindres coûts à de nouvelles fonctionnalités, comme la recherche full text.
1ère étape de la transition : introduire une API REST-JSON. On est aidé (encore une fois) par Spring Web MVC et par Jackson. En 2 ou 3 refactorings, on remet en place toute la partie CRUD de l’application, en passant par la nouvelle API REST. Les nouveaux frameworks web comme AngularJS sont nativement orientés REST et JSON, donc on a finalement besoin de très peu de code pour arriver à une application totalement fonctionnelle.
2ème étape : on enlève la vieille base de données SQL HyperSQL et on la remplace par CouchBase. Encore une fois, CouchBase parle nativement REST et JSON, en 2 coups de cuillère à pot, l’application refonctionne. L’application est dorénavant scalable horizontalement. En live, une démo est faite avec des millions d’utilisateurs chargés en base de données. Aucun problème de latence, l’application répond en quelques centaines de millisecondes sans problème. Étant passé en NoSQL, on est aussi capable de modifier la structure des données à chaud, comme ajouter un attribut (l’équivalent d’une colonne en SGBDR) voire un attribut complexe (une association en SGBDR). Tout ceci sans interruption de service ni redéploiement de la base comme ça serait le cas en SGBDR.
On finit par mettre en place un système de recherche full-text, ici ElasticSearch. Totalement compatible CouchBase, en 2 minutes le nouveau système est prêt, et propose dorénavant une recherche « Google like », qui n’a plus rien à voir avec les possibilités (et les performances) de la recherche dans un SGBDR. Et le plugin Kibana pour ElasticSearch va nous permettre pour un coût quasiment nul de mettre en place du reporting sur la nouvelle base NoSQL !
Le Space-Mountain du développement Java d’entreprise
Florent Ramière a tenu une petite conférence où on a du s’accrocher ! TOUS les outils nécessaires au développement en JEE vont être abordés. Je vous les restitue ici rapidement.
- Maven : plus personne ne présente l’outil de build incontournable
- Pour le mapping relationnel, JPA, avec en prime l’utilisation des méta-modèles pour rester type-safe
- Vu qu’on passe par JPA, on est indépendant de la base, donc autant en prendre une qui soit légère et portable : H2
- Pour l’interface web, bienvenue à JSF2 et à PrimeFaces
- On ajoute les Apache Commons et Guava pour tous pleins de helpers et de class-utils
- Un peu de Lombok pour éviter tout le code inutile et répétitif (getter/setter, toString, equals, hashCode, logger…)
On respire un grand coup et on repart !
- Côté tests unitaires, JUnit
- Bouchonnons un peu l’application pour les tests avec Mockito
- Encore des utils et helpers, mais pour les tests unitaires, avec Fest Assert
- Débuggons nos pages web avec Firebug
- Faisons nos tests d’intégration et fonctionnels avec Selenium
- Et on accélère ces derniers tests avec un navigateur headless basé sur Webkit et v8 : PhamtomJS
Aller courage, c’est presque fini !
- Testons les performances de notre application avec JMeter
- Profilons le code à la recherche des hotspots via JProfiler
- Direction l’intégration continue avec le bien connu Jenkins
- On vérifie la qualité de code avec Checkstyle, Findbugs et PMD
- On monitore les tendances de la qualité avec Sonar
Ça y est, on est arrivé au bout !
Ah non, pas tout à fait ! Comment mesurer la vitesse de la lumière avec un Mars dans sa cuisine et à 2% près
Les tests: pourquoi et comment ?
Une conférence sous forme de retour d’expérience dans le domaine du test, par Axel Haustant, Xavier Renaudin et Grégory Paul.
Ils commencent par faire tomber les gros préjugés qu’on rencontre quand on parle tests :
- « Les IHM, c’est pas testable ! »
- « Pourquoi je devrais passer du temps à penser au test alors que mon code est déjà écrit ? »
- « On a arrêté de tester, vu que tout était rouge et que personne ne corrigeait ! »
Tout ça, c’est du bla-bla juste bon pour ceux qui ne veulent réellement pas faire de tests. Mais effectivement, on en arrive là très vite si on ne met pas en place une bonne méthodologie de test.
Déjà, les tests ne doivent pas être vus comme une plaie, mais comme un bienfait pour le projet. Ils vont permettre de poser le « definition of done » : une fonctionnalité n’est pas terminée tant que tous ses tests ne sont pas verts. Corollaire, les tests permettent de connaître l’état d’avancement de l’application.
En prime, on tient un moyen de détecter les régressions dans l’application. Après une modification, tout doit repasser au vert. Si des tests échouent, on a régressé, et on peut fixer. Sans test, la régression se révèle… en production !
Pour maintenir une bonne qualité de test, il faut y accorder des moyens. On peut par exemple mettre en place des codings review ou du pair programming. Pour encore plus de motivation dans les équipes, y introduire de la gamification (Pair Hero, TdGotchi ou Pulse)
Bonne pratique obligatoire : un test passe au rouge, on arrête tout et on fix ! Les seuls commits autorisés doivent être des commits de correctif, et aucun de nouvelles fonctionnalités. Désigner aussi un binôme de responsable de build, qui fixeront les régressions de test non liés à un bug mais plutôt à des changements d’architecture ou de refactoring trop importants.
Les résultats de tests doivent être publiés, via l’intégration continue par exemple. Et les notifications doivent être systématiques en cas d’erreur, si possible par des canaux multiples (mail, messagerie instantanée…).
Au niveau du développement des tests en eux-même, ne pas les considérer comme du code de 2nde zone, mais avec le même niveau de qualité que pour le reste de l’application. Définir ses propres helpers et asserts, éviter la duplication et définir des conventions de nommage lisibles. Penser aussi à sortir des messages utiles et significatifs pour faciliter la recherche de l’erreur en cas d’échec.
Et enfin, prendre du temps pour essayer de diminuer au maximum la durée des tests. Des tests trop long risquent en effet de ne plus être lancés par les développeurs, ou plus assez régulièrement.
7 idées pour transformer une bonne équipe en équipe exceptionnelle.
Conférence très intéressante de Samuel Le Berrigaud, qui nous donne 7 idées pour encore plus sublimer nos équipes.
- Respecter la Zone
Les développeurs connaissent bien ce moment où on est réellement imprégné de l’application et où on est extrèmement efficace, dans le sujet. Et là, boom, interruption… Et la pratique montre qu’on met plus de 10min à revenir à notre état productif après une interruption.
Il faut donc arriver à se fixer des plages horaires « do not disturb », l’équipe isolée, clients mails et IM coupés. On peut aussi désigner une personne bien identifiée comme telle (t-shirt…) qui sera la seule personne interruptible. Cela impose aussi d’avoir un code totalement partagé dans l’équipe, avec des développeurs quasiment interchangeables.
- Alimenter le cerveau
Organiser des sessions de développement pour maintenir un niveau correct malgré l’évolution rapide des technologies. On peut par exemple faire ça chaque semaine un soir donné. Si les contraintes ou la motivation personnelles rendent ça difficile, tenter un passage en « brown bags », un déjeuner-formation sous forme de présentation ou de diffusion de podcast.
- Dites « bon travail »
Syndrôme purement franco-français, peu ou pas de gratification personnelle et publique. Essayer de mettre en place des micro-récompenses (Kudos chez Atlassian), y compris pour de petites choses. Faire ça de manière publique, et pour tout le monde.
- Report robot
Un seul mot d’ordre : sortir des données, des données, encore des données. État du backlog, temps passé par bug et feature, nombre et taille des commits, état et durée du build, vélocité de l’équipe… Publier les données fréquemment, si possible directement près des postes de travail (écran TV), ce qui permet à chacun de savoir où l’autre en est (et donc son niveau de charge).
- Eat your own dog food
Utiliser les applications développées en alpha-testing en interne. Ça permet à la fois de se mettre plus rapidement à la place du client, donc d’anticiper ses besoins, mais aussi de détecter les problèmes. S’attendre par contre à avoir beaucoup de retour, aussi bien niveau évolution que bug.
- Faire une journée spéciale
Tout le monde met de côté certaines taches jugées rébarbatives. Rédaction de documentation, développement des tests unitaires, upgrade de versions des librairies… Définir une journée par mois où le sprint est totalement laissé de côté pour réaliser ces taches. On peut faciliter le travail en rendant la journée agréable (resto avec l’équipe…) S’engager à livrer quelque chose, sinon cette journée sera totalement inutile.
- Le temps des expériences
Laisser parler l’innovation des développeurs. Cela ne peut qu’améliorer la motivation de l’équipe. On peut par exemple mettre en place des « Ship It Days » : 24h pour laisser les développeurs implémenter une de leur idée, on débrief avec les lightning talks, un gagnant est désigné. Par contre, attention à la qualité du code obtenu, généralement peu maintenable, hardcodé et sans test. Le concept peut être étendu avec des « Innovation weeks ». Pour encore aller plus loin, mettre en place le « 20% time » (dans la pratique ~5% à cause des contraintes projet)
Voilà pour cette 2ème journée, rendez-vous demain pour la clotûre de cette DevoxxFR 2013 !
Comments !