[Devoxx](http://www.devoxx.com), c'est la plus grosse conférence Java d'Europe. Près de 3500 personnes dans un gros multiplexe de cinéma sont réunies pendant une semaine ou pour les 3 derniers jours à Anvers, en Belgique (flamande) pour parler de Java, Android et HTML5. Et c'est gros !
Keynote : Bienvenue et Annonces par Stephan Janssen
Cette courte introduction par l'un des organisateurs de la conférence a permis de souhaiter la bienvenue aux devoxxians et régler les détails pratiques. L'annonce a concerné nos amis du [ParisJUG](http://www.parisjug.org) qui vont organiser du 18 au 20 avril 2012 une toute nouvelle édition française de la conférence. Sa particularité sera de se tenir à Paris et d'offrir un contenu à 75% en français.
Keynote : Java SE Keynote par Henrik Stahl
Henrik est suédois. Savez-vous qu'il y a autant de développeurs java dans le monde que d'habitants en Suède, soit 9 millions. Cela veut donc dire qu'en tant que speaker à la Keynote Devoxx, il représente plus que le premier ministre suédois. C'est sur cette petite remarque qu'Henrik a débuté sa présentation. Ensuite, il a refait les annonces faites un mois plus tôt à JavaOne.
Ce que je retient de sa présentation est sa formulation de l'avenir du "produit" Java racheté par Oracle en même temps que Sun. A travers un historique, il a résumé ce qu'avait apporté Java : faire que le développeur ne se soucie plus de la dés-allocation mémoire à travers l'abstraction qu'est la Machine Virtuelle et supprimer les dépassements mémoire. A l'heure où certains cherchent des alternatives à Java, son message est donc de continuer à faire avancer la plate-forme Java (avec notamment le support de nouveaux langages et l’extension vers le cloud) afin qu'elle continue à tenir ses promesses. En échange, il souhaite que les développeurs qui vivent grâce à Java participent autant qu'ils peuvent : venir aux conférences, assister à leurs JUG locaux ou contribuer au JCP.
Keynote : Java EE Keynote par Cameron Purdy
Cameron a survolé les dernières nouveautés Java EE et a parlé de la roadmap de certains produits Oracle comme Weblogic. Je suppose que les développeurs qui travaillent avec ces produits on du trouver ça intéressant.
Methodology : The Diabolical Developer - take the power back par Martijin Verburg
Une rhétorique intéressante, interdite au moins de 12 ans. Au delà de l'Agilité, du mouvement Software Craftsmanship, son discours volontairement provocateur était au niveau du manifeste "Programming, Motherfucker". Morceaux choisis:
- Ne faites pas confiance aux géants de notre industrie : les auteurs de livres, les conférenciers (il rentre dans les deux catégories ;) ), leur compétence n'est depuis longtemps plus le développement d'applications.
- L'information, c'est le pouvoir. Le pouvoir de garder son job. Soyez le seul à garder des informations cruciales pour le produit (procédure de mise en production par exemple)
- Ne partagez pas votre code, il pourrait permettre à quelqu'un d'autre de prendre votre job
- Un seul fichier source, c'est bien plus simple
- Pourquoi construire n-tiers ? La meilleure architecture : JSP --> DB
- Compiler, c'est livrer
- Maintenez votre propre framework web, il justifiera votre poste pendant longtemps
- Ne fixez pas les bugs mineurs, les profils juniors sont fait pour ça
- Quand vous formez un junior, un seul message: "Faites ce que je dis et pas ce que je fais"
Pour moi, son but est atteint : par l'humour, nous faire un peu plus réfléchir par nous-même et nous forcer à remettre en cause les dogmes et les "bonnes pratiques" pour ne jamais cesser d'apprendre.
Methodology : Continuous Delivery par David Farley
Il a déjà écrit un livre sur la livraison continue. Avec cette présentation, il a donné du concret sur ce qui a été mis en place dans sa société LMAX qui édite du logiciel pour la finance.
C'est donc un produit complexe pour lequel la livraison en continue a été implémentée. Avec ces principes de livraison, on atteint la DOD parfaite : code en production ! Il formule un cycle avec des boucles de rétro-action:
| idea | > | release | ||||
| executable spec. | > | build | ||||
| unit tests | > | code |
Certaines pratiques sont donc nécessaires:
- Un seul build des binaires pour tous les environnements (test, acceptance, production)
- Utilisez exactement les même mécanismes pour déployer dans chaque environnement
- Testez le déploiement
Ensuite, ce que Dave appelle le pipeline du déploiement continu, autrement dit, le cycle de mise en production s’exécute:
- Commit d'un nouveau développement
- Tests unitaires + Build
- Création d'un artefact qui est stocké dans un référentiel dédié.
- Tag de l'artefact si les tests d'acceptation automatisés (spécification exécutables) passent, sinon, l'artefact est invalidé.
- Tag de l'artefact si les tests par le Product Owner passent, sinon, l'artefact est invalidé.
- Tag de l'artefact si les tests de performance du composant passent, sinon, l'artefact est invalidé.
- Tag de l'artefact si les tests de performance du système passent, sinon, l'artefact est invalidé.
- Tag de l'artefact si les tests de migration sur un système équivalent production passent, sinon, l'artefact est invalidé.
Ce cycle n'est pas exécuté après chaque commit, mais une fois par semaine environ. Pour arriver à un tel niveau d'automatisation, ils ont développé leur propre outil d'automatisation de déploiements. Il leur permet de déployer avec le même outil et les même paramétrages sur des environnements avec des granularités différentes. Par exemple, sur un laptop, tous les composants sont déployés en local. C'est l'inverse d'un déploiement en production dans lequel chauque composant est déployé sur une machine distincte.
C'est donc la démonstration d'une très forte maturité sur le build. On sent qu'ils ont poussé le processus à l'extrême, notamment sur la nécessité de tout automatiser. Sur un projet qui démarre, on va sûrement commencer par faire les choses assez manuellement puis automatiser le plus répétitif ou le plus soumis à l'erreur humaine. Au bout d'un temps suffisamment long, on sera donc sans doute parvenu à ce niveau d'automatisation.
Citation marquante: "I can break your system faster by altering a configuration rather than your source code."
Web : Bleeding Edge HTML5 par Paul Kinlan
Comme d'habitude avec les présentations HTML5, ça impressionne. La prestation de Paul, de Google, n'a pas dérogé à la règle.
Les [slides](http://kinlan-presentations.appspot.com/bleeding/index.html) sont disponibles.
J'ai été particulièrement intéressé par les "intents" qui sont une tentative de Google de porter un concept venu d'Android. Lorsque vous partagez une image depuis un mobile Android, le système présente à l'utilisateur une liste des applications qui implémentent le partage d'image. Pourquoi ne serait-il pas possible pour une application web de réclamer les services web qui implémentent une interface bien définie ?
Architecture : NoSQL for Java developers par Chris Richardson
Une session assez agréable par l'auteur de "POJO in action". Il a repris le use-case de son livre de 2004 (une application e-commerce) en partant du principe que les données ont grossit, il va falloir passer d'une base relationnelle à une base NoSQL pour "scaller" (passer à l'échelle). Il nous montre donc un modèle de donnée assez simple qu'il faut migrer vers redis, cassandra et mongodb. Ses conclusions sont que la modélisation des données en NoSQL sur les bases clé/valeurs (redis et cassandra) est dépendante de la complexité des requêtes à effectuer sur la base. Effectivement, il faut dénormaliser la base pour construire un agrégat de deux champs en clé primaire puisque la requête ne peut se faire que par la clé. En base documentaire (comme mongodb), on a une modélisation plus simple dans son cas et le pouvoir de requêtage est plus fort. Dans ce cas, il suffit de convertir la requête SQL dans le langage de mongo.
Il a utilisé l'API Spring Data pour le code source. Sur mongodb, je ne connaissais que le driver standard et la couche Morphia pour le mapping sur les objets.
Une présentation sérieuse qui a eu le mérite d'être très clair sur ce qu'il est possible d’imaginer faire avec ces 3 bases NoSQL.
Java EE : JAX-RS 2.0: RESTful Java on Steroids par Marek Potociar
C'était un résumé des avancées qui seront inclues dans la nouvelle version de la spécification qui offre à java le moyen de fournir et consommer des ressources REST :
- Client API : on garde l'API fluent et on l'enrichit
- Filters & Handlers : cette partie a été refactorée pour être plus utilisable
- Validation : on intégre la spécification Bean Validation d'Emmanuel Bernard
- Asynchronous Processing : côté client comme côté serveur, on permet de faire un traitement long côté serveur et d'attendre le résultat côté client
- Hypermedia : une API pour créer des liens dans une ressource vers une autre ressource
- Server Side Content Negociation, JSR330, MVC: il n'y aura pas de MVC dans la spec finale
Conclusion
C'était une journée riche. Dans un multiplexe surpeuplé de 3000 geeks, on ne se sent pas seul en Europe à faire du Java. Et la conférence est très bien organisée : des tableaux blanc avec des votes libres, des kinects devant chaque salle pour consulter le détail d'une session, des écrans géants avec les tweets #devoxx avant chaque session, des boissons à volonté, et j'en oublie. A demain !