Pour ma quatrième participation, Devoxx est toujours une conférence incontournable en Europe de part la qualité des présentations et des speakers, du nombre de participants (3000 cette année), de l'organisation bien rodée.

Cette année, le nombre de participants semble plus important que l'année dernière pour les universités mais surtout il y a beaucoup plus de francophones, ce qui est très sympa.

 

Productive programmer

Neal Ford est un très bon orateur qui nous a proposé une présentation inspirée de son livre "Productive programmer".

La première partie "Mechanics" est composée de quatre thèmes :

_ acceleration : pour réaliser ses tâches plus vite en utilisant les raccourcis clavier, utiliser un presse papier multiple, utiliser les commandes pushd et popd pour revenir dans un répertoire, utiliser le clavier plutôt que la souris, rechercher plutôt que naviguer, utiliser des macros et des templates, ...

_ focus : il faut éliminer les distractions pour se concentrer sur sa tâche. Cela passe par des choses simples mais toujours faciles à mettre oeuvre : avoir une chaise ergonomique et confortable, avoir deux écrans et un bon clavier, avoir les droits administrateurs sur son poste, supprimer les distractions (les notifications, les messageries (fermer ses emails et la messagerie instantanée) car un changement de contexte est coûteux), utiliser des bureaux virtuels, ...

_ canonicality : il faut appliquer le principe DRY (Don'r Repeat Yourself). L'ORM est un des pires contre exemple du principe DRY (database schema + xml configuration + pojo > 1) : il est préférable de partir du DDL est de générer le fichier de mapping XML et le code des POJO

_ automation : il faut faire réaliser certaines tâches répétitives par la machine en utilisant par exemple une commande unique pour faire un build, utiliser l'intégration continue avec un gestionnaire de sources, utiliser selenium ide (remarque perso : lorsque cela est possible car c’est difficile avec certains frameworks) pour reproduire un bug (par les utilisateurs ou les développeurs : l'idée est simple mais je n'y avais jamais pensé), développer sa propre boite à outils de préférence avec des langages de développement (support des IDE, test unitaires, refactoring). Il faut automatiser dès que le ROI se justifie.

 

Dans la seconde partie (Pratices), Neal Force nous propose 10 moyens d'améliorer notre productivité

1. Composed Methods

Les méthodes d'une application doivent uniquement réaliser une tâche bien identifiée et contenir le moins de ligne possible. Cela facilite la réutilisabilité et la testabilité du code. Neal Ford nous propose un exemple de refactoring d'une méthode qui se connecter à une base de données pour retourner des données.

2. TDD (Test Driven Development / Test Driven Design)

Le TDD permet notamment de réfléchir à la façon sont les classes vont être utilisées. Ceci implique de mocker les dépendances, de mettre en oeuvre le principe des composed methods, ...

3. Static analysis

Utiliser des outils d'analyse de code (PMD/CPD) et de byte code (findbugs)

4. Good citizenship

Neal Ford nous rappel qu'il ne faut pas générer automatiquement les getters et les setters : getters + setters != encapsulation !

Il faut éviter les singletons puisque qu'il mixte les responsabilités et sont difficilement testables. Ils sont une version objet des variables globales décriées dans d'autres technologies. Il est préférable de créer un pojo qui contient les traitements et une fabrique pour créer l'unique instance du pojo en utilisant l'introspection pour invoquer le constructeur privé du pojo.

Neal nous fournit un exemple de la pire classe du JDK : la classe java.util.Calendar qui est connue pour sa mauvaise conception. Il est préférable d'utiliser d'autres implémentations comme JodaTime.

5. YAGNI (you ain’t gonna need it)

L'idée est de n'utiliser que ce que l'on a besoin.

Les meilleurs frameworks sont ceux qui sont extraits d'une application et pas ceux qui sont développés from scratch.

Comme exemples, Neal Ford nous propose le « Ten top corporate code smells » (dont certains m'ont bien fait rigoler)

  • 1. There is a reason that WSAD isn’t called WHAPPY.
  • 2. The initial estimate must be within 15% of the final cost, the post-analysis estimate must be within 10%, and the post-design estimate must be with 5%
  • 3. We don’t have time to write unit tests (we’re spending too much time debugging)
  • 4. We keep all of our business logic in stored procedures...for performance reasons.
  • 5. The only JavaDoc is the Eclipse message explaining how to change your default JavaDoc template.
  • 6. We have an Architect who reviews all code precheckin and decides whether or not to allow it into version control.
  • 7. We can’t use any open source code because our lawyers say we can’t.
  • 8. We use WebSphere because...(I always stop listening at this point)
  • 9. We bought the entire tool suite (even though we only needed about 10% of it) because it was cheaper than buying the individual tools.
  • 10. We invented our own web/persistence/messaging/caching framework because none of the existing ones was good enough.

6. Question authority

Il faut être capable de remettre en cause certaines choses établies, par exemple :

_ les conventions de nommages des méthodes de tests unitaires (qui sont plus lisibles avec des underscores plutôt qu'avec le Camel Case)

_ mettre en oeuvre le pair programming : cela prend plus de temps mais le code produit contient moins de bugs

_ le chaînage des méthodes plutôt que d'utiliser les setters imposées par la convention JavaBeans : il est préférable d'utiliser les fluent interfaces

7. Slap (Single Level of Abstraction Principle)

8. Polyglot programming

Utiliser le langage le mieux adapté à la tâche à réaliser, par exemple Scala ou jaskell pour les traitements fortement multithreadés, grails ou jruby on rails pour la productivité sur des applications web

9. Every nuance

Il ne faut pas obligatoirement maintenir certaines idées diffusées historiquement, par exemple le fait que l'API Reflection soit lente (vrai dans les années 90 mais plus vrai et vraiment pratique dans certaines circonstances).

10. Anti-objets

Ce sont des objets qui sont à l'opposé de ce qu'ils devraient faire par exemple parce qu'ils sont trop inspirés de la vie réelle.

Je n'ai pas encore lu son livre mais sa présentation m'a vraiment donné envie de l'acheter

Il est possible de télécharger les slides de ces présentations dans différents événements (dont celles de Devoxx cette année) à l'url http://nealford.com/mypastconferences.htm

 

Extreme Productivity with Spring Roo

Ben Alex et Stefan Schmidt nous ont proposé un tour d'horizon de Spring Roo.

Récemment la version 1.1 de Spring Roo a été publiée et elle apporte de nombreuses fonctionnalités par rapport à la version 1.0.

De nombreuses démos nous ont permi de se rendre compte de la productivité de Roo pour développer des applications web soit en utilisant le shell fournit par Roo ou en utilisant l'outil STS de SpringSource qui est téléchargeable gratuitement et offre un support pour Roo.

L'extensibilité est assuré par un système de add-on qui enrichit Roo de fonctionnalités.

 

Tools in action : Mylyn

Oliver Gierke de SpringSource nous propose une rapide présentation du plug-in Mylyn d'Eclipse et des avantages apporté par ce plug-in pour améliorer notre productivité de codeur (focus, productivity, traceability).

Il permet de gérer des tâches fournies par un gestionnaire de sources (généralement un gestionnaire de bug tel que BugZilla, RedMine, Jira, ... )

L'utilisation du plug-in commence par la configuration de ce gestionnaire de sources.

Une fois une tâche activé, celui ci se charge de maintenir un contexte de travail dans Eclipse.

Oliver termine sa présentation en nous parlant de SpringSource Code2Cloud.