BodySplash.fr

Je vais peut être enfoncer une porte ouverte pour certains, mais j'ai envi de parler du secret si bien gardé par les grands professionnels pour être productif avec un IDE : les raccourcis clavier! Oui, c'est ironique, mais l'année dernière lors de la session TDD, et plus récemment suite à d'autres retours, j'ai été assez étonné des remarques du genre "ah je ne savais pas qu'on pouvait faire tout ça avec Eclipse". Un des intérêts premiers d'un IDE est tout de même de nous aider à faire les tâches de base du développement :

• autocomplétion
• refactoring
• exécution des tests
• navigation facile dans les sources
• assistance contextuelle

Oui, je ne met pas sciemment tout ce qui est éditeurs WYSISYG, car leur utilité est finalement assez anecdotique et bien souvent alourdissent les IDE pour rien tout en étant pas si productif que ça. Ils sont d'ailleurs peut être la cause majeure qui fait que pas mal de gens n'aiment pas les IDE. Ceci dit étant dit, même si la plupart des fonctionnalités citées plus haut sont accessibles par la souris, leur usage ne devient systématique et efficace à mon avis que si on les associe à des raccourcis claviers.

Prenons un petit cas d'exemple. Imaginons que j'ai écrit un test ressemblant à ça (désolé, je ne me suis toujours pas motivé pour mettre en place une coloration syntaxique sur ce blog):

@test
public void peutRécupérerNomComplet() {
    Client client = new Client();

    assertThat(client.nomComplet(), is("prenom nom");
}

au plus simple, le code pour faire passer ce test est le suivant :

public String nomComplet() {
   return "prenom nom";
}

Cette méthode est un appel au refactoring, car il y a duplication entre la méthode de test et la méthode de production (la constante est répétée). Je vais peut être vite en besogne, mais nous devons alors faire apparaître du coup le nom et le prénom. Pour éviter d'être verbeux plus longtemps, voici une petite vidéo pour montrer comment je m'y prend en m'appuyant sur les capacités d'Eclipse:

(Si jamais la vidéo ne s'affiche pas, vous pouvez toujours allez directement ici)

Il y a bien sûr plusieurs chemins pour arriver au même résultat, mais j'espère que si vous n'utilisez pas souvent les raccourcis clavier, les refactorings ou les aides à la génération alors cette vidéo vous aura convaincu d'essayer de vous y mettre un peu plus. Beaucoup de développeurs reprochent aussi aux IDE leur lourdeur. C'est parfois justifié (je ne citerai personne), mais dans cette vidéo, avez-vous vous eu l'impression qu'Eclipse était lent et se mettait sur mon chemin?

Voilà un titre de billet accrocheur! En fait, je vais me contenter de réagir à cet article d'Ayende Si vous écoutez un peu les voix alternatives du monde .NET, vous devez surement avoir déjà entendu parler de lui, sinon sachez juste qu'il est contributeur sur NHibernate, qu'il a initié l'implémentation de Linq2NHibernate, et qu'il a fait pas mal d'autres projets open source dans le monde de .Net, ainsi qu'un profiler propriétaire mais excellent pour NHibernate et Hibernate. Bref, ce bonhomme est très bon techniquement, et je suis toujours avec attention ses avis (notamment sur la mutualisation, désolé pour la private joke, mais les initiés comprendront ).

Bref, dans l'article que je donnais en début de billet, il donne donc son avis sur JEE vs .NET. Je suis globalement très d'accord avec lui sur son jugement sur JEE, et sur certains manques du langage Java. Cela fait maintenant un peu plus d'un an que je fais du Java 100% du temps, et que je ne touche plus à .NET, et pourtant je passe encore pas mal de temps à regretter certains fonctionnalités de C#. Ceci dit, cela fait également plus d'un an que je m'efforce le plus possible à ne PAS utiliser JEE. Et je pense que c'est un peu ça la force de Java vs .NET : une communauté réactive qui passe le plus clair de son temps à essayer de ne pas appliquer la philosophie "main stream" et à développer des alternatives . Mieux encore, il est tout à fait possible en entreprise d'utiliser ces projets open source sans rencontrer trop de résistances. Lorsque que je bossais en .NET, convaincre un client d'utiliser NHibernate (à une époque ou Entity Framework n'existait pas) relevait du défis, à tel point que j'ai été contraint dans une mission d'écrire mon propre mapper O/R. A ça ajouter une communauté, si on peut l'appeler ainsi, provenant majoritairement d'un monde VB6 sans bonnes pratiques, et vous obtenez une mini catastrophe. Des mouvements comme Alt.NET sont bien sûr à saluer et regroupent de très bon praticiens, mais je pense qu'ils représentent toujours hélas une minorité dans l'ensemble des développeurs .NET. Biens sûr tout n'est pas rose côté communauté Java, et elle comprend son lot de boulets et de mauvaises idées. Mais le simple fait qu'il soit tout simplement possible d'avoir le choix rend cette technologie plus attractive maintenant à mes yeux. Nous utilisons principalement Restlet dans Le Projet, et à ma connaissance, il ne connait pas d'équivalent en .NET aussi simple d'utilisation et de configuration. Le monde Java est un monde où les idées peuvent plus facilement s'épanouir j'ai l'impression, et où le réflexe "alternative open source" est bien plus ancré.

Voilà un titre bien obscure. Alors de quoi allons parler aujourd'hui? De la manière la plus simple que je vois actuellement de commencer une application web en java. Il y a quelques semaines effectivement un ami me demandait finalement quoi utiliser pour démarrer un projet de 0 e, avec comme postulat de base que finalement, tout était bien compliqué. Je vais donc décrire ici mes environnements/outils/frameworks favoris qui à mon sens, permettent de s'en sortir dans la grand majorité des cas, et tout en fournissant une base à la fois solide et extensible.

L'environnement

Avant même de commencer à développer, mieux vaut savoir comment nous allons développer. Je pense maintenant qu'il y a une base indispensable à tout projet avant même de penser conception et développement.

Build

Avec quoi construire notre appli? Ca a l'air bête comme question, mais ce n'est en fait pas si simple dans le monde de java, ou tout n'est pas aussi intégré et monolithique que dans le monde .NET.

Par défaut, à peu prêt tout le monde utilisait Ant. Personnellement, je n'en peux plus: xml au kilomètre, dépendances gérées à la main, pas user friendly, bref, une horreur à mes yeux. Si vous lisez de temps en temps ce blog, vous devez vous douter que je vais proposer Maven. Avec maven, il va être possible en 2 lignes de xml d'avoir un projet entièrement compilé, testé, packagé. Les dépendances sont téléchargées depuis un entrepôt central, et il les gère en cascade, donc on ne passe plus des heures à linker ou mettre à jour les libs externes, c'est géré. Si on suit ses conventions, c'est bien simple maven permet de faire oublier une grande partie des tâches techniques de base d'un projet.

Une question qui peut venir et savoir comment organiser son projet dans maven: Multi module ou mono module? l'avantage du multi module est qu'il va garantir une séparation entre les couches, là ou le mono module si on ne fait pas attention peut entraîner un certain mélange. Ceci dit, la complexité du multi module au début ne compense pas ce risque hypothétique, et mieux vaut de toute manière enseigner qu'interdire. Donc, jusqu'à le projet atteigne une complexité trop importante, je préfère la simplicité du mono module tout en faisant attention à ne pas mélanger les couches.

SCM

Même si vous êtes seuls, il vous faut quelque chose pour conserver et versionner votre source, ne serait-ce que par sécurité et pour avoir la possibilité de revenir en arrière. Git a beau être une star montant, je ne le connais pas, et je vais donc me contenter de conseiller subversion: simple, efficace, et non intrusif (pas de lock par défaut sur les fichiers).

IDE

Certains puristes vont certainement dire qu'un éditeur de texte suffit pour développer, mais à mon avis, on est loin d'une productivité optimale. Voilà à mes yeux ce que doit ABSOLUMENT faire un IDE:

• intégrer les test unitaires : pouvoir les lancer facilement, et naviguer rapidement dans le code incriminé par un test rouge,
• refactoring : c'est à mon sens l'outil ultime de productivité et de qualité. Sans aides au refacto il est trop facile, par manque de courage ou de temps, de ne pas faire des changements pour clarifier le code. Pourquoi renommer une classe si ça nous prend 10mn de faire le tour de l'appli pour trouver ceux qui l'utilise? Pourquoi extraire une super classe et centraliser du comportement si c'est un long travail fastidieux de copier/coller? Voilà pourquoi je pense qu'il est juste indispensable qu'un IDE intègre un certain nombre de refactorings assistés
• auto-complétion, coloration, indentation: c'est la base, mais il est bon de le rappeler
• navigation rapide dans le code: il doit être possible d'ouvrir rapidement des types ou des fichiers, mais aussi depuis une classe par exemple d'aller directement dans le code d'un objet qu'elle inclue.

Il y aurait être d'autres choses à ajouter, mais c'est déjà pas mal. Les trois IDE les plus connus du monde java (Eclipse, NetBeans, Intellij Idea) assurent tous ces fonctionnalités en plus d'une intégration à Maven indispensable dans notre cas. Je ne vais pas rentrer dans des débats religieux sur lequel est le mieux, mais personnellement j'utilise Eclipse.

Intégration continue

Je pense que l'intégration continue doit être en place dans le premier jour du projet, il ne faut pas attendre de commencer à avoir des soucis pour la mettre en place. Le minimum est bien sur de compiler l'application et de faire tourner les tests.

Il existe maintenant pas mal de solutions gratuites, mais je dois avouer ma nette préférence pour Hudson, grâce à son esprit "on déploie et ça marche". C'est très simple à mettre en place, il marche très bien avec Maven, et il peut être étendu à souhait avec pas mal de plugins. Que demander de plus?

Les technos

Bien, nous avons la base pour commencer à développer, c'est bien, mais ça ne nous dit pas quels frameworks utiliser pour bâtir notre application web. Au risque de spoiler un petit peu, je vous annonce tout de suite que je ne vais pas conseiller JEE, même en version "simple" en n'utilisant que servlet/jsp.

Restlet

Voici un framework qui mériterait un billet à part entière, mais je vais essayer de faire un résumé. Le but de restlet est de servir de base pour produire et consommer des ressources conformément à l'approche Rest. Ce qui est bien avec ça, c'est que l'on peut commencer très simplement, en faisant une application "à l'ancienne" avec des pages html entièrement générées côté serveur, puis commencer à si on veut à faire plus du RIA, avec GWT, Flex, Dojo, peu importe, les ressources restent les mêmes, on négocie juste une représentation différente.

Comme je le disais, Restlet est très simple à mettre en place, pas besoin de conteneur de Servlet ou autre, il peut démarrer son propre serveur web en une seule ligne de code. Les ressources et la configuration se fait également entièrement dans le code, avec quelques recours très discret aux annotations. Bref, Restlet est une base idéale pour toute application web: il est multi-paradigme, peut grossir en même temps que votre application sans vous forcer une grande complexité dès le début, bref, je suis fan. Ah vous de choisir au début si vous voulez faire une application à l'ancienne, du GWT, du flex etc etc, Restlet supporte tout le monde de toute manière. Suivant ce que vous avez décidé, vous pouvez ensuite par exemple utiliser Freemarker ou Velocity pour générer la représentation html de vos ressource selon une approche MVC bien connue.

Hibernate

Ah voilà un choix plus discutable n'est-ce pas quand on cherche à définir les frameworks les plus simples pour démarrer n'est-ce pas? Le plus simple pourrait-on me dire, serait de directement se connecter à la base, et de faire nos requêtes. Le soucis avec cette approche, c'est que jamais elle ne sera capable de gérer correctement une grande complexité. On se retrouvera nécessairement avec du code mort, de la duplication et une très faible réutilisabilité du code. Ceci dit, il doit y avoir plus simple qu'Hibernate non pour accéder à nos données? Sûrement, mais là je vais devoir avouer que je suis complètement perverti par DDD, et je ne conçois pas de ne pas d'abord penser objet, tester, puis seulement ensuite de faire apparaître la base. Seul un mapper O/R par metadata mapping permet d'utiliser cette approche à 100% , et hibernate est la meilleure solution open source gratuite que je connaisse pour atteindre ce but. Ah mes yeux, et pour une fois, l'effort d'écrire et maintenir tout ce XML me semble complètement être compensé par la valeur: pouvoir écrire un modèle du domaine testable et indépendant de toute considération technique. Le point discutable est sans doute, dans le cadre d'une application juste CRUD, est-ce que ça vaut le coup de sortir l'artillerie lourde? Ma réponse habituelle est que je n'ai jamais connu en 7 ans d'applications qui faisaient simplement du CRUD, donc j'ai le sentiment que ce n'est pas la règle mais le cas particulier. De plus, comment savoir à l'avance que l'application ne fera QUE du CRUD quand on la commence?

Quelques remarques

Il y a bien entendu des critiques à émettre sur le choix des technologies de base, notamment sur la productivité. Il y a peu voir pas du tout de travail prémaché dans ce que j'ai proposé, pas de composants déjà utilisables rapidement, ou de scripts pour générer rapidement les "échafaudages", sans doute parce que je ne suis fan d'aucunes des technologies proposant ces options, car trop de choix me déplaisent dedans (Ruby on Rails et Grails sont très contraignants sur pas mal de points, tant ils font de choix pour nous, Wicket, JSF and co sont orientés composants et modèle par page et ne tirent pas partie à mon avis des avantages du web; Spring MVC est déjà plus sympa, surtout en version 3, mais c'est déjà beaucoup plus lourd que Restlet...)

Voilà quelques temps déjà, en parlant du projet, un des membres de l'équipe ne venant pas vraiment du monde objet avait fait la remarque que ce qui l'étonnait le plus dans notre code, c'était le très faible nombre de if. Remarque intéressante, mais que j'oublie un peu et voilà qu'hier, j'entends la remarque de la part de quelqu'un d'autre, et concernant un autre projet. Cet après-midi, j'ouvre un projet que je suis censé faire évoluer, et je tombe sur bien peu de classes, mais avec beaucoup de méthodes un peu trop grosses et surtout bourrées de if. Non content d'induire une certaine difficulté à la relecture, la plupart de ces if en fait étaient la pour palier l'absence de concept. C'est à dire qu'ils servent essentiellement à tester la valeur de string et faire un traitement adéquat. Je ne sais pas à quoi cela vous fait penser, mais très personnellement ça m'a amené à l'esprit le refactoring d'école : "un switch est un polymorphisme manqué". Et c'est vrai qu'en essayant de faire apparaître de nouvelles classes avec les bonnes responsabilités, les if ont fondu, le design est devenu plus évolutif et "ouvert à l'extension", et le code beaucoup plus facile à relire.

Du coup, pour revenir au titre de billet, c'est presque à se demander si le nombre de if ne serait pas une métrique intéressante à mettre en oeuvre pour donner un indicateur de plus sur la qualité d'un projet. Le chiffre est bien sûr à mettre en perspective en fonction de la taille du projet, mais je pense qu'un faible nombre de if du coup aurait tendance à démontrer un design pensé en terme de responsabilités plutôt qu'en séquentiel.

Bon aujourd'hui, je ne vais pas vous infliger un grand discours philosophique. Je voulais juste partager ma petite découverte de la semaine: perf4j, dont la philosophie se résume à cette phrase:

Perf4J is to System.currentTimeMillis() as log4j is to System.out.println()

L'idée est donc qu'il doit être aussi facile d'introduire du code de profiling que du code de logging. Donc à la manière que Logger.getLogger, nous allons récupérer un StopWatch dont l'implémentation dépend de votre framework de logging favoris. L'idée est de générer des traces de performances enregistrées par votre système de log habituel. Du coup le système est entièrement configurable au même endroit que le logging. Si jamais vous trouvez ce code trop envahissant, nativement il est possible d'utiliser aspectJ ou SpringAOP pour le tisser à votre place.

Perf4j est ensuite livré avec un outil en ligne de commande capable d'analyer ces traces, et de proposer des aggregats et des graphes. En poussant la configuration un peu plus loin, on peut même du coup avoir des informations de performances en temps réel via jmx/servlet/etc etc.

Perf4j a mon sens ne remplace pas complètement un bon vieux profiler quand il s'agit d'identifier les problèmes de performance d'une application, mais son extrême simplicité et sa capacité à fournir des statistiques sur le code même en production m'ont assez plu.

J'avais un petit besoin de profiling, et j'ai été heureux de trouver un outil simple pour ça.

Bon avec un titre pareil, je pense que vous m'avez déjà compris.

Ca va faire un mois que je travaille sur un projet s'appuyant lourdement sur la norme JEE 5. J'étais pourtant parti d'un bon pied, en me disant qu'il était de toute manière possible de faire de bonnes choses avec. Le soucis, c'est que je vais de frustration en frustration, et notamment au niveau mapping O/R. Même si JBoss est le serveur d'application utilisé, et que donc, le persistence est assurée par Hibernate, la directive d'architecture est de ne se baser que sur la spécificaiton EJB 3 pour pouvoir déployer sur n'importe quel serveur. Le soucis de cette spec, c'est qu'elle est incroyablement limitée comparée aux possibilités d'hibernate.

Je ne vais pas tenter une liste exhaustive, mais voici quelques une de mes plus grandes frustration:

• Pas d'API de requête, tout doit passer par EJB QL. Tant pis pour la génération de requête générique et l'intégration aux outils de refactoring.
• Par défaut, utilise les annotations pour définir le mapping, cassant à mon sens le concept de Persistence ignorance,
• Ces fameuses annotations sont beaucoup moins intuitives qu'Hibernate
• Si jamais on veut se passer des annotations, par défaut il faut mettre le mapping dans un seul gros fichier xml bien boulimique. Très surprenant quand on sait que JBoss supporte tout à fait la détection à la volé de tout ce qui est *.hbm.xml
• La norme ne supporte pas les collections de types primitifs ou de composants, et là, c'est juste inadmissible. Oui, pas de collection de String par exemple dans vos objets, interdit ça.

En me documentant sur Sping MVC, je suis bien entendu tombé sur le tutorial "official", contenant entre autre ça.

C'est tellement une illustration de ce que je disais il y a quelques temps que ça en est presque risible.

Alors pour résumer, je trouve assez fantastique qu'en un seul petit exemple simpliste on réussisse à voir apparaitre

• un modèle du domaine anémique
• des DTO portés au rang d'objet métier servant de cœur au système
• une conception procédurale: le service héberge les traitements de A jusqu'à Z
• de la surcomplexification: utilisation d'une interface implémentée une seule fois, couche de service inutile dans le contexte.

Je sais, ces éléments sont plus ou moins liés, mais laissez-moi être un peu théâtrale.

Bref, je le répète, une magnifique démonstration de ce que je n'aime pas voir dans un projet et que pourtant, je croise à chaque coin de rue.

Voilà quelque temps, j'ai promis à quelqu'un je ne nommerai pas (mais il se reconnaîtra j'en suis sur) de faire un billet/article sur entity framewok.

Je fais juste rapidement un petit lien vers un billet de Fabien pour faire passer l'info que nous avons découverte hier: la différence colossale de perf entre le driver Microsoft pour Oracle et le driver fourni par Oracle sur les requêtes paramétrées.

Peut-être que nous avons manqué quelque chose en route qui expliquerait cette différence, mais en tout cas je n'en ai pas l'impression.

Voilà un petit moment que j'ai pas eu l'occasion d'écrire un peu ici. Ce n'est pas qu'il ne se passe rien, c'est que mon temps est un un peu accaparé par pas mal de projets dont j'espère bientôt pouvoir parler ici.