J’ai enfin eu l’occasion de participer à mon premier Devoxx cette semaine, encore un peu à chaud voici ce qui m’a marqué :

Keynote de S.Janssen

La Keynote a lieu dans une des (la ?) plus grandes salles et elle est retransmise en live dans les autres salles.
Tout l’esprit de Devoxx est représenté par Stephan : fun et sérieux.
Il introduit les trois jours de conférence et termine sur l’annonce de DevoxxFrance via un “One more thing” et une vidéo bien menée.
Un grand moment pour les Français qui attendaient enfin une belle conférence de ce type en France.

Oracle vs Google

Assurément compétents, les speakers de Oracle m’ont appris beaucoup de choses sur l’intégration des closures et sur Jigsaw pour Java 8 … mais que c’est dur de rester accroché, des slides chargés, pas de live coding, des speakers un peu monocordes.
D’un autre coté, que ce soit sur Android ou HTML5, Google a sorti l’artillerie lourde avec beaucoup de conférences par des speakers de grande qualité.
Des bons speakers, du code et/ou des démos, c’est ce que les gens attendent. Même en restant sur le thème Java SE, Josh Bloch arrive à avoir une présentation sympa et accrocheuse .

BOF Java EE

J’ai participé au BOF animé par Alexis Moussine-Pouchkine sur les JSR relatives à Java EE 7.
C’était assez interessant de voir de nombreux “specs leaders” répondre à des questions très pointues et débattre entre eux.
Devoxx est une énorme conférence mais les intervenants sont très accessibles.

BOF JUG

Je crois que j’ai oublié de vous le dire mais j’ai intégré l’équipe d’organisation du Ch’ti JUG il y a quelques mois.
J’ai donc participé avec plaisir à cette rencontre des JUG Leaders. Des représentants d’Oracle étaient présents ainsi que de nombreux JUG Leaders des capitales européennes et d’autres continents (Maroc, Egypte, Brésil, USA, ..)
Oracle semble apprendre vite et faire beaucoup d’efforts en direction des JUGs, bonne nouvelle.
Une large partie de la session a été consacrée au programme “Adopt a JSR“, le JCP est preneur de retour d’information de la part de développeurs et encourage la communauté à s’investir dans les JSR.

Matt Raible

Matt Raible est un spécialiste des frameworks Web et nous a présenté la session la plus hallucinante de ces trois jours, .
Il a aimé venir à Devoxx l’année dernière et c’est imposé un challenge de taille : apprendre Scala pour en faire une session à Devoxx 2011 !
Comme le garçon n’a pas froid aux yeux, il empile de nombreuses technologies dans sa R&D : Play!, CoffeeScript, Scalate, Jade et pour finir PhoneGap car tout ca tourne dans Safari Mobile.
Le tout est présenté avec beaucoup d’humour, à la fin de la session il présente une vidéo qui retrace toute cette aventure avec trois sessions de test en extérieur.

Ceylon

Dernière session de la conférence : présentation du langage Ceylon par Emmanuel Bernard et Stephane Epardaud.
Ceylon est un langage statique pour la JVM qui vient apporter des solutions à certains problèmes rencontrés avec Java.
Par rapport à Java, la syntaxe n’est vraiment pas chocante, le développeur Java ne sera pas chamboullé.
Parmis les fonctionnalités proposées, j’ai retenu :

• Une protection contre les NullPointerException par le compilateur.
• L’utilisation naturelle d’objects immuables.
• Le type Union qui permet de combiner plusieurs interfaces.
• Les propriétés : les accesseurs sont présents par défaut
• … et plein d’autres choses sympas.

Pendant la session, Emmanuel annonce que le projet a maintenant un site web et a puplié son code sur Github.
Je n’ai pas encore regardé attentivement les autres langages (Kotlin et Fantom) mais celui ci me plait bien.

Un dernier mot : Harcelez votre manager, prenez des congés, changez de boite  ou devenez indépendant mais allez à ces conférences

Ce matin lors de la Keynote d’ouverture de Devoxx, nous avons eu le droit à un “One more thing” : la projection d’une vidéo annonçant l’organisation d’une édition Française de la conférence Devoxx.

C’est une excellente nouvelle, car aucune conférence de ce gabarit n’existe pour les développeurs Java francophones.

Grand bravo et bon courage à l’équipe du Paris JUG qui prend en charge cette organisation.

Rendez vous sur le site de DevooxFrance pour plus d’infos.

J’ai également rencontré le même système de mise à jour pour le portail projet Redmine. Le point commun entre ces deux outils : ils sont basés sur Ruby On Rails, le fameux framework intégré de développement web basé sur le langage Ruby.

Ruby On Rail intègre un outil nommé Migrations qui permet en effet de spécifier des migrations unitaires de base de données, le framework permettant de les appliquer de manière incrémentale.

En Java, les outils de mapping objet/relationnel disposent de fonctions similaires. Par exemple Hibernate sait générer le modèle de base de donnée (DDL) qui correspond à vos entités JPA . Il sait également mettre à jour une base de données pour lui ajouter des éléments (propriété hibernate.hbm2ddl.auto). Dans de nombreux cas c’est suffisant. Cependant certains cas ne sont pas gérés, par exemple le changement de type d’une colonne ou la suppression de colonnes.

J’ai récemment rencontré un cas ou nous avions besoin d’aller plus loin, en effet les applications traversent de nombreux environnements de qualification avant d’arriver en production. Dans ce cas les opérations manuelles sont à éviter le plus possible. J’ai donc recherché un outil équivalent à Migrations mais en Java.

J’ai trouvé mon bonheur avec Flyway, une librairie OpenSource (License Apache 2.0) qui permet d’automatiser les changements de schéma. L’idée est simple :

• Flyway stocke dans une table (SCHEMA_VERSION) un journal des scripts déja executés sur cette base de données
• L’application embarque les scripts SQL suivant une convention de nommage
• Au démarrage de l’application, Flyway calcule l’écart entre la table SCHEMA_VERSION et les scripts présents dans votre application et applique les nouveaux scripts

<!-- Migrations de schémas SQL -->
<dependency>
  <groupId>com.googlecode.flyway</groupId>
  <artifactId>flyway-core</artifactId>
  <version>1.4</version>
</dependency>

Les fichiers SQL doivent se trouver dans le classpath de l’application à l’exécution, dans un package db.migration. Les utilisateurs de maven les placeront donc dans src/main/resources/db/migration . Les fichiers doivent être nommés sur le pattern suivant : VX_yyy_zzz.sql, X représentant le numéro de version et yyy_zzz étant un libellé de version. Par exemple : V1_initialize.sql ou V6_parameter_table.sql .

Pour lancer la migration, une API est disponible. Toutes les opérations sont disponibles dans la classe Flyway, voici un exemple d’utilisation :

Flyway flyway = new Flyway();
flyway.setDataSource(dataSource);
flyway.migrate();

L’intégration avec Spring est soignée, il suffit de déclarer le bean avec une méthode d’initialisation

<bean id="flyway" class="com.googlecode.flyway.core.Flyway" init-method="migrate">
  <property name="dataSource" ref="dataSource"/>
</bean>

package db.migration;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.jdbc.core.JdbcTemplate;

import com.googlecode.flyway.core.migration.java.JavaMigration;

public class V54_sample_migration implements JavaMigration {

	private Logger logger = LoggerFactory.getLogger(this.getClass());

	@Override
	public void migrate(JdbcTemplate jdbcTemplate) throws Exception {
		logger.info("V54_sample_migration STARTING");
		int countOfActorsNamedJoe = jdbcTemplate.queryForInt("select count(0) from actors where first_name = ?", "Joe");
		jdbcTemplate.update("update stats set count = ? where first_name = ?", countOfActorsNamedJoe, "Joe");
		logger.info("V54_sample_migration ENDED");
	}
}

Toutes les conventions de nommage sont configurables (package de base, préfixe et suffixe des scripts, …) . Pour assurer les évolutions d’un modèle de données existant, il est nécessaire d’ajuster la propriété disableInitCheck à true dans le cas contraire Flyway déclenche une exception.

Bref un outil simple et extrêmement pratique pour rendre le déploiement de vos applications un peu plus fluide.

J’ai écrit cette présentation avec mon collègue Guillaume, nous y revenons sur les principes basiques de HTTP, à quoi sert une session coté serveur et comment s’en passer.

La méthode la plus répandue pour exposer des WebServices en Java est la méthode dite “Code First” : on développe un composant Java et on s’appuie ensuite sur un outil pour exposer ce composant sous forme de WebService. Cet outil va analyser les signatures des méthodes de votre composant et va générer un descripteur de WebService : le WSDL. Le développeur jette ensuite un oeil (ou pas) à ce descripteur et se félicite de ne pas avoir eu à écrire ce fichier très verbeux.

Un autre développeur récupère le fameux descripteur WSDL et utilise un autre langage ou un autre outil pour générer le code client et c’est la que les choses se compliquent souvent.

Je vais prendre comme exemple un service de recherche dans un annuaire, ce service permet de rechercher des personnes à partir de leur nom, prénom et ville de résidence. Deux critères sont obligatoires : le nom et la ville de résidence.

Voici l’interface Java qui correspond au service :

@WebService
public interface AnnuaireService {
	List<Personne> rechercher(String nom, String prenom, String ville);
}

Une fois ce service déployé à l’aide de la pile de WebService CXF, le WSDL généré déclare le type suivant pour représenter le message de recherche :

<xs:complexType name="rechercher">
	<xs:sequence>
		<xs:element minOccurs="0" name="arg0" type="xs:string" />
		<xs:element minOccurs="0" name="arg1" type="xs:string" />
		<xs:element minOccurs="0" name="arg2" type="xs:string" />
	</xs:sequence>
</xs:complexType>

Cette déclaration n’est pas utilisable dans l’état, les critères de recherche ne sont pas nommés et tous les critères sont marqués comme optionnels (minOccurs=0).
Il est donc necessaire d’annoter l’interface Java pour permettre à CXF de générer un WSDL plus significatif.

@WebService
public interface AnnuaireService {
	List<Personne> rechercher(
		@WebParam(name="nom") String nom,
		@WebParam(name="prenom") String prenom,
		@WebParam(name="ville") String ville);
}

Les critères de recherche sont maintenant nommés dans le WSDL :

<xs:complexType name="rechercher">
	<xs:sequence>
		<xs:element minOccurs="0" name="nom" type="xs:string" />
		<xs:element minOccurs="0" name="prenom" type="xs:string" />
		<xs:element minOccurs="0" name="ville" type="xs:string" />
	</xs:sequence>
</xs:complexType>

La spécification JAX-WS ne permet pas de rendre les paramètres obligatoires.

Il existe bien sur des solutions de contournement pour que le WSDL soit plus conforme au contrat du service, mais cet exemple trivial nous montre que la génération du WSDL à partir du code Java necessite d’enrichir le code avec des méta données et que le résultat ne permet pas d’utiliser le WSDL généré comme contrat solide entre le producteur et les consommateurs.

Pour que le WSDL reprenne son rôle de contrat, il est important qu’il spécifie le plus précisément possible les messages d’entrée et de sortie du WebService. La démarche “Contract First” met justement l’accent sur la contractualisation des messages échangés.

Contract First avec Spring WS

Le descripteur WSDL reste très verbeux et la perspective de gérer ces fichiers à la main est assez effrayante. Rassurez vous, nous allons nous contenter de décrire les messages en entrée et sortie à l’aide de XML Schema (XSD).
Une fois ces messages décrits, nous allons nous appuyer sur JAXB et Spring-WS pour implémenter le contrat.

Voici le schéma décrivant le message de recherche dans l’annuaire :

<element name="rechercherRequest">
	<complexType>
		<annotation>
			<documentation>
				Message d'entrée pour la recherche dans l'annuaire
   		</documentation>
		</annotation>
		<sequence>
			<element name="nom" type="string" />
			<element name="prenom" type="string" minOccurs="0" />
			<element name="ville" type="string" />
		</sequence>
	</complexType>
</element>

Une configuration rapide de la génération des objets Java à partir du XML Schema à l’aide de maven 2 :

<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>jaxb2-maven-plugin</artifactId>
	<version>1.3</version>
	<executions>
		<execution>
			<goals>
				<goal>xjc</goal>
			</goals>
		</execution>
	</executions>
</plugin>

Et voici l’objet qui correspond à la requête :

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "nom",
    "prenom",
    "ville"
})
@XmlRootElement(name = "rechercherRequest")
public class RechercherRequest {

    @XmlElement(required = true)
    protected String nom;
    protected String prenom;
    @XmlElement(required = true)
    protected String ville;
 ....
 

Certes c’est verbeux mais c’est du codé généré donc pas de couts d’intégration ou de maintenance.

Voici maintenant la signature du composant Java qui prend en charge la requête :

@Endpoint
public class AnnuaireEndpoint {
	@PayloadRoot(localPart = "rechercherRequest", namespace = "http://yellowpages.tartachuc.org")
	public RechercherResponse rechercher(RechercherRequest request) {

....

Une première annotation @Endpoint marque la classe et la rend detectable par le “component-scan” de spring. La seconde annotation @PayloadRoot indique quel message est traité par la méthode.

Cette mise en oeuvre de Spring-WS permet d’assurer un contrat WSDL soigné tout en ne pénalisant pas la productivité des développements. Dernier avantage, cette démarche impose de concevoir les messages échangés ce qui favorisera des messages plus expressifs et simples  qui facilitent l’utilisation des services tout en évitant d’exposer directement les objets “privés”.

Voici une liste des nouveautés :

• Paramétrages des règles au sein de profils, ces profils contiennent tous les paramètres et sont entièrement exportables.
• Possibilité de définir des seuils d’alerte, au sein des profils. Cela permet de matérialiser le respect des objectifs de qualité du projet par une icône en fonction de son état.
  Pour chaque alerte, on peut définir un seuil de “orange” et un seuil “rouge”. Un flux Atom permet de s’abonner à ces alertes.
• Et enfin, la grosse nouveauté de mon point de vue, la possibilité d’affecter un profil différent à chaque projet et donc d’adapter les règles au contexte et aux choix de chaque équipe.

A noter que la mise à jour se fait sans difficulté.

J’ai mis en place cet outil sur un de mes projets et je le trouve très pratique, la configuration est très simple et cela permet à toute l’équipe d’avoir une vue à la fois synthétique et précise des marqueurs qualité.

La version 1.5 amène des changements sympatiques au niveau de l’interface graphique et surtout une ouverture vers d’autres outils de mesure via un système de plugins.

Cet article du blog Sonar détaille les principaux changements

Voici un graphique de suivi qualité que l’on peut, par exemple, afficher dans la war room ou sur le site projet.

Sonar est une solution beaucoup plus utilisable que le plugin dashboard maven qui est moins mur.

Dans tous les cas, il faut au minimum que l’équipe adhère aux règles qualité et il est préférable que l’équipe définisse elle même les règles de développement.

Appspy offre une solution pour le suivi de vos applications Java coté serveur en production, vous pourrez ainsi consolider toutes sortes de données issues des différentes instances de vos applications et par exemple savoir quelles URLs sont sollicitées, quelles URLs sont lentes ou encore comparer les temps de réponse entre deux versions.

Les applications intègrent un module client qui collecte les données et les fournit au serveur qui permet de les visualiser sous formes de rapports paramétrables. Le tout est disponible sous la licence Apache 2.0 qui est “business friendly”.

Je ne vais pas tarder à essayer cet outil sur un de mes projets, je vous en dirai plus à ce moment la. Ayant eu l’occasion d’utiliser un ancien produit de la même gamme écrit par Olivier, je suis assez impatient

La lecture de cet article m’a rappelé son nom et j’ai donc installé le plugin MouseFeed.

Depuis, à chaque fois que j’utilise la souris alors qu’un raccourci clavier existe, un marqueur m’indique le raccourci correspondant.

Exemple :

Je pense que ce plugin peut nous faire gagner en productivité car bien que fan des raccourcis clavier, j’ai pu constater lors des dojo que d’autres en tiraient bien plus avantage.

A noter que par défaut le plugin s’attribue la combinaison de touches Ctrl + Shift + 1 qui sur les claviers azerty est aussi utilisée pour effectuer la combinaison Ctrl + 1 qui correspond à l’action “Quick Fix” qui permet de lister les correctifs proposés par eclipse. Il faut donc changer l’un des deux.