Archive

Posts Tagged ‘java’

Mon premier Devoxx

19 novembre 2011 2 commentaires

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

Étiquettes : , ,

Devoxx France à Paris en Avril 2012

16 novembre 2011 1 commentaire

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.

 

Étiquettes : ,

Automatiser les changements de schéma de base de données avec Flyway

5 juillet 2011 1 commentaire

J’ai été intrigué par le système de mise à jour de base de données de l’appliation Sonar. Quand vous installez une nouvelle version, l’application vous indique que votre base de données est en version x et qu’il faut la migrer en version y. Un clic et un peu de patience plus tard, la mise à jour de la base de données est effective.

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
De plus il est possible d’écrire les scripts en SQL mais aussi de les écrire en Java pour les opérations plus complexes. Par exemple pour adapter les données au nouveau schéma.
Pour intégrer flyway dans votre application, il est nécessaire d’ajouter la librairie flyway-core qui s’appuie sur spring-jdbc.
Pour les utilisateurs de maven, ajouter cette dépendance dans votre pom :
<!-- 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>
Pour écrire un script de migration en Java, la encore il faut suivre une convention de nommage. Les classes  doivent se trouver dans le package db.migration et suivre le même pattern de nommage que les scripts. Par exemple : V4_settings_migration.java. Les classes doivent également implémenter l’interface JavaMigration.
Par exemple :
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.

Étiquettes : ,

HTTP sans session : pourquoi et comment ?

Voici une présentation rapide sur un sujet assez populaire en ce moment : Les applications Web sans session coté serveur d’application.

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.

Étiquettes : ,

WebService "Contract First" avec Spring-WS

Contract First vs Code First

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 ».

Étiquettes : ,

Sortie de Sonar 1.6

9 février 2009 1 commentaire

Le blog du projet Sonar annonce la sortie de la version 1.6 de ce très bon outil de suivi qualité.

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é.

Étiquettes : ,

Sortie de Sonar 1.5

La version 1.5 de l’outil de suivi qualité Sonar est sortie aujourd’hui.

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.

Indicateurs qualité

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.

Étiquettes : ,