La nouvelle est passée presque inaperçue : Java Mission Control est disponible dans le JDK7 u40. Tous ceux qui sont confrontés à des problématiques de performance ou d’optimisation au sein de leur application java vont apprécier

: Ils avaient jusqu’à présent le choix entre le profiler intégré dans leur IDE préféré, ou des outils commerciaux du genre jProfiler, YouKit etc… L’inconvénient majeur ces outils est leur impact sur le programme monitoré, que ce soit sur la rapidité d’exécution et/ou leur taille mémoire.

Java Mission Control est outil qui était déjà disponible depuis longtemps sur JRockit. Comme jvisualvm il permet de suivre les informations classiques de la jvm (cpu, mémoire, gc, mbeans, threads …). La valeur ajoutée est sur les fonctions de profiling  : On y retrouve les toutes les fonctions des profilers classiques (cpu, mémoire), avec un impact beaucoup (!) plus faible (moins de 2% selon oracle) que les profilers classiques. Cerise sur le gâteau, si vous utilisez Java sur solaris, il y a un plugin avec Dtrace ce qui permet d’avoir une vision à la fois applicative  de l’application, mais également de son impact sur le système. Pour profiter de jmc, il faut tout de même ajouter sur la ligne de commande de la jvm

-XX:+UnlockCommercialFeatures -XX:+FlightRecorder

Pour conclure, les développeurs java n’ont plus l’excuse du “je ne peux pas profiler le serveur d’app parceque ça trop sur mon pc” car ils disposent désormais d’un outil pour optimiser une application. Pour ceux qui ont accès à la prod et qui doivent investiguer l’origine des problèmes de performance ou de stabilité, c’est un nouvel outil qui n’a pas d’équivalent : On vient de dépanner un client (site internet 10 frontaux jetty/spring/jsf) qui avait un problème récurrent de memory leak sur son appli. On a observé une instance de son appli (relativement 60% cpu et heap de 2Go avec beaucoup de phases de gc) avec jmc et trouvé le problème rapidement, là ou c’était impossible avec les outils traditionnels à cause de leur impact sur les performances.

A mettre d’urgence entre toutes les mains …

The post Java Mission Control : l’outil qu’il manquait first appeared on In Fine - Le Blog.

Lors de devoxx 2013, Florian nous à fait une présentation dont le succès (la plus grande salle pleine à craquer) montre à quel point javascript  avec lequel tout le monde à “joué”, reste méconnu par une grande majorité de javamen. Pourtant avec l’émergence des derniers frameworks javascript (angular, ember, backbone, knockout …), on ne peut plus faire l’économie de vraiment se mettre à javascript. Même google avec la mise à l’écart de GWT, mise sur le développement natif du côté client, qu’il soit dart ou javascript avec angular …

Florian, javaman qui s’est mis à javascript,  aborde lors de cette présentation les pièges qui nous guettent.

http://parleys.com/play/51572cf7e4b0ffdd7e058b28/chapter0/about

The post infine@Devoxx : Javascript pour les javamen first appeared on In Fine - Le Blog.

Hadoop dans les grandes lignes 

Hadoop est un framework java destiné à faciliter la création d’applications distribuées et scalables. Il permet aux applications de travailler avec des milliers de nœuds et des pétaoctets de données.

Hadoop repose sur son système de fichier (HDFS) ainsi que sur son algorithme de Map/Reduce.

Généralement, tous les tutoriaux ou exemples d’implémentation d’Hadoop concernent un calcul basique de calcul du nombre de différents mots contenu dans des fichiers.

Dans cet article, je vais m’attacher à vous présenter un cas concret d’utilisation d’Hadoop pour le calcul de VWAP.

Qu’est ce qu’une VWAP et pourquoi utiliser Hadoop pour la calculer ?

La VWAP (Volume-weighted average price) est un indice financier correspondant au ratio de la valeur échangée par le volume échangé. Plus d’info ici

Notre but est de calculer la VWAP pour tous les titres, sur tout l’historique disponible à des heures données.

Les fichiers historiques sont de la forme txt. Il y a un fichier par jour, ce fichier pèse en moyenne 1GigaOctet. Donc selon la taille de notre historique, ce calcul peut s’avérer très fastidieux et couteux en ressources.

Voici à quoi ressemble un fichier en entrée (enfin une infime partie) :

C;FR0000130338;09:00:03;3;310;24.6;50;24.5
C;FR0000130338;09:00:03;4;231;24.62;665;24.4
C;FR0000130338;09:00:03;5;686;24.63;309;24.37
C;BE0003796134;09:00:03;1;3360;4.51;5306;4.5
N;FR0000120222;09:00:00;00000042;67.99
N;FR0000120222;09:00:00;00000019;67.99
N;FR0000120222;09:00:00;00000012;67.99
N;FR0000120222;09:00:00;00000002;67.99
N;FR0000120222;09:00:00;00000041;67.99

En séparant par “;”

1. C ou N, C pour carnet d’ordre N pour une transaction
2. Code ISIN du titre
3. Heure de la transaction
4. Volume de titres échangés
5. Prix

Hadoop va donc être utilisé pour ces fonctionnalitées de calcul distribués afin de répartir la charge de parsing et calcul sur différentes machines et tout aggréger pour donner en sortie un fichier avec les vwap demandées.

Voici un extrait du fichier de sortie :

FR0010112524-20100104-09:00:00     25.656256
FR0010112524-20100104-12:00:00     26.125364
FR0010112524-20100104-17:00:00     26.28817
FR0010112524-20100106-09:00:00     26.560003
FR0010112524-20100106-12:00:00     26.684067
FR0010112524-20100106-17:00:00     26.756487
FR0010112524-20100217-09:00:00     25.949999

Implémentation d’Hadoop pour un calcul de VWAP

En entrée, on a donc toute une série de fichiers txt. Chaque fichier correspond aux extractions Euronext des transactions d’un jour donné.

Seules les lignes commençant par «N;» nous intéressent, les autres correspondant aux carnets d’ordre.

Au niveau du Mapper, nous allons extraire toutes les lignes commençant par «N;» pour un ou plusieurs code ISIN donnés.

Dans le Reducer, on va vouloir récupérer toutes les lignes correspondant à notre/nos ISIN triées par jour puis heure afin de calculer la Vwap pour les heures données. Or Hadoop ne permet pas de trier directement la liste de <Values> reçue par le Reducer

Tri des <Values> grâce à une clé composite

Avec Hadoop il est impossible d’effectuer un tri sur les valeurs. Par contre, à la place on peut placer les données qu’on veut trier dans la clé et ainsi utiliser une clé composite. Ensuite on utilise une classe de Partition spécifique ainsi que deux classes RawComparator afin de trier et partitionner notre map en sortie correctement.

La solution est d’utiliser un système de clé composite, dans notre exemple, je la nomme IsinKey.

L’objet IsinKey sera utilisé comme la Clé et contient :

• Une String key qui est la concaténation de l’ISIN puis du jour de l’extraction (par exemple : FR0010112524-20120913)
• Une String hour qui correspond à l’heure d’une transaction

Un objet Tick sera lui utilisé comme Valeur pour stocker le volume et le prix.

Ensuite, il va nous falloir définir 3 réglages dans le JobConf d’Hadoop :

• setPartitionerClass
• setOutputValueGroupingComparator
• setOutputKeyComparatorClass

Le Partitioner

La première classe qu’on doit setter étend de org.apache.hadoop.mapred.Partitioner. Cette classe a pour unique fonction de déterminer dans quelle partition notre map de sortie doit aller. On ne peut aller en dessous de 0 ou au dessus de numPartitions -1 dans notre retour. En général il est préférable de récupérer le HashCode d’une partie de la Clé et d’y appliquer un modulo du nombre de partitions.

Dans notre exemple, on récupère le hashcode de notre Clé qu’on module ensuite avec le numPartitions.

public int getPartition(IsinKey key, Tick val, int numPartitions) {
   int hash = key.getKey().hashCode();
   return hash % numPartitions;
}

L’ Output Value Grouping Comparator

L’OutputValueGroupingComparator dans les paramètres du JobConf utilise un org.apache.hadoop.io.RawComparator. Le RawComparator est utilisé pour déterminer dans quel Reducer notre ligne de sortie de mapping doit aller. Ce RawComparator ne trie pas la liste de Valeurs du Reducer, mais trie l’entrée du Reducer,  pour que le Reducer sache quand un nouveau groupe commence.

Dans notre exemple, le grouping comparator va trier par la «Key» de notre object IsinKey (c’est a dire «Isin-date»

public int compare(WritableComparable w1, WritableComparable w2) {
   IsinKey k1 = (IsinKey)w1;
   IsinKey k2 = (IsinKey)w2;
   return k1.getKey().compareTo(k2.getKey());
}

L’ Output Key Comparator

L’outputKeyComparatorClass dans les paramètre du JobConf utilise aussi un org.apache.hadoop.io.RawComparator. Ce RawComparator est utilisé pour trier les Clés que reçoit le Reducer. Les données envoyées au comparateur sont nos objets clés (IsinKey dans notre exemple). Il est très important aussi de retenir que le KeyComparator doit comprendre la règle définie dans l’OutputValueComparator.

Dans notre exemple, ça veut dire qu’on va d’abord comparer la Key de l’objet IsinKey, puis, si ces Key sont égales, alors on va comparer les champs Hours de l’objet IsinKey.

public int compare(WritableComparable w1, WritableComparable w2) {
   IsinKey k1 = (IsinKey)w1;
   IsinKey k2 = (IsinKey)w2;
   SimpleDateFormat f = new SimpleDateFormat("HH:mm:ss");
   int result = k1.getKey().compareTo(k2.getKey());

   if(0 == result) {
      try {
         result = f.parse(k1.getDate()).compareTo(f.parse(k2.getDate()));
      } catch (Exception e) {
         e.printStackTrace();
      }
   }
return result;
}

Grâce à ces trois classes redéfinies, le Reducer sera appelé une fois par clé IsinDate, puis lorsque l’on itère sur les «values», l’heure de la «Key» prend successivement ses différentes valeurs, ce qui nous permet  de déterminer la vwap à chaque tick, et de repartir à 0 pour chaque nouvelle journée

Lancement en “Stand-Alone” et reste des classes

Afin de démarrer le projet en mode «Stand-Alone», il suffit d’inclure les sources d’hadoop dans un projet eclipse par exemple, puis d’inclure ce projet dans le projet courant.

CalcVWAPDriver

public class CalcVWAPDriver {
   public static void main(String[] args) throws IOException, InterruptedException, ClassNotFoundException {

      Configuration conf = new Configuration();
      GenericOptionsParser parser = new GenericOptionsParser(conf, args);
      args = parser.getRemainingArgs();
      conf.setStrings("ISIN", "FR0010112524");
      conf.setStrings("DATES", "09:00:00", "12:00:00", "17:00:00");
      Job job = new Job(conf, "calcVWAP");
      job.setPartitionerClass(NaturalKeyPartitioner.class);
      job.setGroupingComparatorClass(NaturalKeyGroupingComparator.class);
      job.setSortComparatorClass(CompositeKeyComparator.class);
      job.setMapOutputKeyClass(IsinKey.class);
      job.setMapOutputValueClass(Tick.class);
      job.setInputFormatClass(TextInputFormat.class);
      job.setOutputFormatClass(TextOutputFormat.class);
      job.setMapperClass(CalcVWAPMapper.class);
      job.setReducerClass(CalcVWAPReducer.class);
      FileInputFormat.setInputPaths(job, new Path(args[0]));
      FileOutputFormat.setOutputPath(job, new Path(args[1]));
      System.out.println(job.waitForCompletion(true));
   }
}

Dans l’exemple, on attribue en dur des valeurs ISIN et DATES dans la configuration d’Hadoop (lignes 7 et 8) afin d’y avoir accès dans le Mapper et le Reducer. Il est tout à fait envisageable de le rendre paramétrable avec les arguments passés à la méthode main.

CalcVWAPMapper

public class CalcVWAPMapper extends Mapper<LongWritable, Text, IsinKey, Tick> {
   private String currFile = null;
   private String currDate = null;
   private String currHour = null;
   private String currIsin = null;
   private List<String> isins = null;

   public String getFileName(Context context) {
      FileSplit fileSplit = (FileSplit)context.getInputSplit();
      return fileSplit.getPath().getName().toString();
   }

   protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException {
      if (!getFileName(context).equals(currFile)) {
         currFile = getFileName(context);
         currDate = currFile.replace(".txt", "");
      }
      if (isins == null) {
         isins = Arrays.asList(context.getConfiguration().getStrings("ISIN"));
      }

      String line = value.toString();
      if (line.startsWith("N;")) {
         String[] result = line.split(";");
         if (result.length >= 5) {
            if (isins.contains(result[1])) {
               if (!result[1].equals(currIsin)) {
                  currIsin = result[1];
               }
               if (!result[2].equals(currHour)) {
                  currHour = result[2];
               }
               String volume = result[3];
               String price = result[4];
               context.write(new IsinKey(currIsin+"-"+currDate, currHour), new Tick(volume, price));
            }
         }
      }
   }
}

Le Mapper est assez simple. Si ce n’est pas déjà fait, on prend le nom du fichier traité afin d’en extraire la date. Puis pareil, on récupère la liste d’ISIN entrée  en paramètre dans la JobConf Hadoop. (lignes 14 à 20)

Ensuite, on lit ligne par ligne le fichier. Si la ligne commence par “N;” alors on la split (lignes 23 et 24). L’Isin est la deuxième partie, l’heure la troisième, tandis que le volume et le prix sont respectivement les quatrièmes et cinquièmes parties.

Enfin, on écrit dans le context nos objets. D’un côté, la Clé composé de l’Isin-Date et de l’heure, et de l’autre côté la Valeur qui est composé du volume et du prix. (ligne 35)

CalcVWAPReducer

public class CalcVWAPReducer extends Reducer<IsinKey, Tick, IsinKey, OutputVWAP> {

   private String isin = null;
   private float vwap = 0.0f;
   private long totalVolume = 0;
   private List<Date> hoursList = null;
   private SimpleDateFormat f = new SimpleDateFormat("HH:mm:ss");

   protected void reduce(IsinKey key, Iterable<Tick> values, Context context) throws IOException, InterruptedException {
      IsinKey lastKey = null;
      OutputVWAP lastOutput = null;
      int currIdx = 0;

      if (hoursList == null) {
         hoursList = new ArrayList<Date>();
         String []dates = context.getConfiguration().getStrings("DATES");
         for (int i = 0; i < dates.length; i++) {
            try {
               hoursList.add(f.parse(dates[i]));
            } catch (Exception e) {
               e.printStackTrace();
            }
         }
      }

      for (Tick value : values) {
         try {
            if (currIdx >= hoursList.size()) {
               return;
            }
            if (f.parse(key.getDate()).after(hoursList.get(currIdx))) {
               context.write(lastKey, lastOutput);
               if (currIdx < hoursList.size()-1) {
                  currIdx++;
               } else {
                  return;
               }
            }
            Float price = Float.parseFloat(value.getPrice());
            Integer volume = Integer.parseInt(value.getVolume());
            vwap = (volume * price + totalVolume * vwap)
               / (totalVolume + volume);
            totalVolume += volume;

            lastKey = new IsinKey(key.getKey(), f.format(hoursList.get(currIdx)));
            lastOutput = new OutputVWAP(vwap);
         } catch (Exception e) {
            e.printStackTrace();
         }
      }
   context.write(lastKey, lastOutput);
   }
}

Pour le Reducer, dans un premier temps, on récupère les heures rentrés dans la configuration d’hadoop (lignes 14 à 24). Le but est d’écrire en sortie la vwap pour les heures voulues et ordonnées.

Puis on itère sur les <Values>. A chaque itération on calcule la vwap et on stocke le retour. (lignes 26 à 50)

Si à l’itération d’après l’heure de la clé dépasse l’heure en paramètre, alors on écrit la dernière vwap calculé dans le context. Puis on passe à l’heure d’après en paramètre. Une fois qu’on a traité toutes les heures voulues, on sort de la méthode. (lignes 28 à 38)

Vous pouvez récupérer les sources complètes sur le GitHub Infine

Conclusion

Nous avons donc vu comment calculer les vwap en utilisant le framework Hadoop en mode Stand-Alone.
Mais la où Hadoop tire toute sa puissance, c’est dans la parallélisation et le clustering.
Je vous montrerai donc dans un prochain article comment monter, configurer et utiliser un cluster avec Hadoop.

The post Calcul de VWAP avec Hadoop en StandAlone first appeared on In Fine - Le Blog.

Tu viens de démarrer (ou vas bientôt démarrer) dans la vie active , tu sors d’une école d’ingénieur ou de l’université et tu as choisi d’être développeur (souvent java d’ailleurs). C’est cool, tu as choisi un beau métier pas forcément encore très reconnu et estimé à sa juste valeur en France, mais ça c’est une autre histoire.

Toujours est-il que je te vois très souvent, que ce soit en face à face lors d’un entretien ou directement sur un projet et si je peux me permettre j’aimerais te donner quelques conseils parce que … tu me déprimes.

• J2ee tu n’écriras plus sur ton CV : pour ton info ça s’écrit JEE (voire comme me le fait remarquer sami, Java EE). Et arrête de mettre spring, struts dans cette norme, mais jette un œil ici une fois pour toutes. Parfois tu n’écris pas j2ee mais java/j2ee (java-ji-deux-e) comme s’il s’agissait d’un seul mot. Tu as certainement du t’inspirer de CVs qu’on t’a recommandés à l’école ou  d’une version retravaillée par une ssii. Et au fait, depuis quand struts et spring font-ils partie de la norme Java EE.
• Le langage et le Sdk tu connaîtras : c’est quand même le minimum lorsqu’on programme dans un langage que de connaitre ses possibilités : et pourtant combien de fois je me surprends en train de t’expliquer l’intérêt d’utiliser telle collection plutôt que telle autre. Ça veut aussi dire que tu suivras les évolutions du jdk : on en est à la version 7 et combien de nouvelles fonctionnalités peux-tu me citer ?
• Au Jug tu iras : il y en a certainement un près de chez toi. Les cast codeurs tu écouteras (http://javaposse.com/ également si tu es anglophone). Les flux rss tu liras, et les bonnes personnes tu ‘followeras’ sur twitter. Si tu es plutôt du matin ce sera http://thecodersbreakfast.net/ ou du soir http://blog.paumard.org/ : bref, intéresse toi un minimum.
• A vie tu apprendras : c’est vrai pour n’importe quel programmeur mais tu devras le faire encore plus que tes collègues dans d’autres langages. Tu as choisi un écosystème de cinglé ou il ne se passe pas un jour sans qu’un nouveau framework/langage/concept ne sorte et il te faudra discernement et courage pour suivre le rythme car le tempo est soutenu.
• Les bases de l’informatique tu “réviseras” : j’écris tu réviseras mais c’est uniquement pour ne pas faire répétition avec le conseil précédent. C’est vrai que l’industrie du software n’est pas hyper poussée en France et qu’il y a de fortes chances pour que tu travailles sur une application de gestion (avec une base de données , des serveurs/services web …) ce n’est pas une raison pour ignorer tout ce qui est en dessous, la JVM et la façon dont sont utilisées les ressources que tu sollicites sans t’en rendre compte.
• Performance tu penseras : attention je n’ai pas dit “tu optimiseras” (chaque chose en son temps) : mais déjà essaye de penser que quand ton appli sera livrée, tu risques d’avoir légèrement plus de données à gérer, plus d’utilisateurs, plus de pression sur les ressources, plus de concurrence d’accès … : si tu en as la possibilité, prends une configuration pas trop puissante pour exécuter ton code, tu vas t’apercevoir des lenteurs plus tôt dans ton projet; utilise un jeu de données représentatif tant au niveau des valeurs qu’au niveau du volume. Pour coder en revanche, débrouille toi pour avoir la config la plus puissante : Quand je vois le temps perdu par jour et par développeur rien qu’à attendre que son build se termine ou que son serveur d’appli veuille bien démarrer …
• Le sql tu maîtriseras : tu penses que tu connais hibernate/jpa et tu penses que ce vieux langage (qui a ton age !?) qu’est le sql ne vaut pas la peine que tu t’y attardes parce que c’est “has been” : d’ailleurs avoue que tu n’as jamais pensé à regarder quelles étaient les requêtes générées par ta couche de persistance préférée. Et si je te demande pourquoi ton code rame ne me dis pas “je ne sais pas, mais, le dba regarde” ou “c’est hibernate” : il faut te rendre à l’évidence : le problème est avant tout entre la chaise et le clavier.
• D’ailleurs ton clavier par coeur tu connaîtras. Fais d’une pierre deux coups et profites-en pour en faire de même avec ton ide/éditeur : quand je te mets devant un écran pour observer comment tu codes, (en ayant bien entendu pris soin de te laisser le choix des armes – eclipse, netbeans, intellij, voire emacs ou vi), je ne te sens pas hyper à l’aise : tu regardes ton clavier, cherches tes touches, et passes un temps fou sur cette satanée souris pour fouiller dans les menus, lancer des commandes etc : tu es freiné par des considérations d’ordre purement techniques, des frottements qui t’empêchent de coder plus vite : débranche ton mulot et force toi à utiliser le clavier en le regardant un minimum voire en le cachant, apprends les raccourcis clavier : tu vas découvrir à quel point tu étais handicapé …
• Pour terminer, outille toi avec tout ce qui pourras améliorer la qualité et la rapidité de tes développements : analyse de code, profiler, couverture de code, tests unitaires, jrebel  …

Tu as choisi un langage dont la difficulté ne réside ni dans le langage en lui même ni dans le sdk déjà bien fourni, mais dans la recherche et le choix des bons composants/framework et dans leur configuration / paramétrage : tu as passé beaucoup de temps à essayer de faire fonctionner ton assemblage de composants et tu as oublié de creuser les sujets qui te donneront des bases solides pour la suite de ta carrière.

Bref tu auras compris, si tu veux être un bon développeur et ne pas être obligé de passer chef de projet ou côté métier par la force des choses plus que par choix, donne toi les moyens et prends tout de suite les bons réflexes, reprends les bases et ne brûle pas les étapes, reste humble (il y en toujours qui en savent plus que toi)  … et code !

The post Conseils à un jeune développeur Java first appeared on In Fine - Le Blog.

La première édition de Devoxx France s’est terminée depuis quelques jours, voici donc un bref retour d’expérience ainsi que les réponses au concours que nous avions organisé.

L’organisation était au top. Les gilets rouges ont bien pris en main l’organisation globale, et malgré la jeunesse de l’évènement, aucun aléa n’est venu perturbé ces 3 journées. Les sessions étaient très variées, et certaines demandaient un niveau technique assez élevé. D’autres au contraire permettaient de découvrir des sujets qui ne sont pas forcément connus des développeurs Java comme par exemple la session d’Alexandre Bertails sur la théorie des langages.

D’un point de vue personnel, j’ai adoré cette première édition. On sentait que l’expérience de Stephan Janssen a permis à Devoxx France de paraître déjà rodé. J’ai pu assisté à de nombreuses sessions très intéressantes et enrichissantes comme celle de Pablo Lopez présentant Hadoop pour gérer les 7Go de logs produites chez son client. J’en ai malheureusement loupé d’autres. Vivement que les sessions soient sur Parleys. Devoxx a vraiment été une cure technique revigorante de part la diversité des sujets et la maîtrise technique des speakers.
D’autre part, en jouant chez divers sponsors j’ai pu gagner un Samsung Galaxy Tab et un Kindle ! Un petit bonus qui a contribué à passer un excellent moment.

Application In Fine Devoxx France

Nous avions mis à disposition des utilisateurs Android une application permettant de gérer son planning pendant les 3 jours de Devoxx France. Les retours des utilisateurs ont été très bons et peu de bugs ont été recensés.
Lors du deuxième jour, le planning a pu indiquer des salles qui ne correspondaient pas à la réalité. Ceci est en fait dû une désynchronisation entre l’application et l’API du site Devoxx. L’API REST ne renvoyait pas les bonnes salles ce qui a pu en gêner certains. Le troisième jour, tout est rentré dans l’ordre et l’API renvoyait les données exactes.

Comme nous l’avons annoncé avant Devoxx France, nous mettons en open source le code de cette application. Le code source est en licence Apache 2 et est disponible sur mon GitHub.

Cette application est censée se connecter à un serveur qui renvoie des données JSON qui ont un format spécifiques. Cette partie peut être adaptée facilement pour récupérer les données renvoyées par le serveur devoxx.

Concours In Fine avec un Mac Book Air à la clé

En tant que sponsor, nous organisions un concours de code. Le gagnant pouvait emporter un Mac Book Air. Le principe était simple : modifier 6 morceaux de code en sept minutes trente.
La difficulté venait du fait que le code était édité dans un navigateur web et pas dans un IDE ! A chaque modification de code, une compilation automatique était envoyée à un serveur permettant de valider la réponse du candidat.

Les réponses aux questions ne nécessitaient pas de connaître les API du JDK par coeur, seules le nom des classes et leur constructeur étaient utiles. Les questions et réponses sont données un peu plus loin dans ce post.

Nicolas De Loof a emporté haut la main le concours en étant le seul à donner les 6 bonnes réponses dans le temps imparti. Les autres participants n’ont pas démérité, mais le fait de coder dans un navigateur a dû en déconcerter plus d’un.

Questions du concours

Chaque question comprend un énoncé, une partie de code éditable par l’utilisateur ainsi que du code non éditable. Les imports se font automatiquement.

Question 1

Comment faire en sorte que myMap puisse garder l’ordre d’insertion

// Début de la partie éditable

Map<String, Integer> myMap = new HashMap<String, Integer>();

// Fin de la partie éditable
myMap.put("val2", 2);
myMap.put("val1", 1);
myMap.put("val3", 4);

Iterator<Integer> i = myMap.values().iterator();
assert(result = i.next() == 2 && i.next() == 1 && i.next() == 4);

Réponse 1

Il faut une certaine connaissance des collections Java. TreeMap n’est pas utilisable ici car il réordonne les entréés à chaque insertion.

Map<String, Integer> myMap = new LinkedHashMap<String, Integer>();

Question 2

Le test est valide lorsque myVar vaut 66666

// Début de la partie éditable

long myVar = 5432l;

// Fin de la partie éditable
myVar += 12345;
assert(myVar == 66666);

Réponse 2

Il fallait mettre un 1 au lieu du l minuscule. Cette question est une référence à Josh Bloch.

long myVar = 54321;

Question 3

Ecrivez une méthode qui calcule la factorielle d’un nombre n . Si n est négatif alors on retourne Double.NaN

// Début de la partie éditable
double fact(int n) {
    return 0;
}
// Fin de la partie éditable

Réponse 3

Faire une fonction récursive était la manière la plus évidente et la plus naturelle.

double fact(int n) {
    if (n == 0)
        return 1;
    else if (n == 1)
        return 1;
    else if (n < 0)
        return Double.NaN;
    return n * fact(n-1);
}

Question 4

Ecrivez la méthode getDayOfWeek qui prend en entrée le nombre de jour depuis le 1 Janvier 1970 ( ce jour était un jeudi ) et qui retourne le jour correspondant.

public final static int SUNDAY = 1;
public final static int MONDAY = 2;
public final static int TUESDAY = 3;
public final static int WEDNESDAY = 4;
public final static int THURSDAY = 5;
public final static int FRIDAY = 6;
public final static int SATURDAY = 7;

// Début de la partie éditable
int getDayOfWeek(int day) {
    return 0;
}
// Fin de la partie éditable

Réponse 4

Cette question probablement était probablement la plus difficile. Ceux qui ont essayé de trouver une formule qui marche sur une ligne avec un modulo ont tous échoué. D’autres ont essayé d’utiliser la classe Calendar, mais sans auto-complétion et sans connaissance de l’API ils ont échoué également. La solution la plus simple est celle ci-dessous.

int getDayOfWeek(int day) {
    int moduloDay = day % 7;
    switch(moduloDay){
        case 0 : return THURSDAY;
        case 1 : return FRIDAY;
        case 2 : return SATURDAY;
        case 3 : return SUNDAY;
        case 4 : return MONDAY;
        case 5 : return TUESDAY;
        default : return WEDNESDAY;
    }
}

Question 5

Modifiez le code pour que le resultat de la soustraction soit égal à 0.9

void substract() {
// Début du code éditable

    BigDecimal a = new BigDecimal(2.00);
    BigDecimal b = new BigDecimal(1.10);
	
// Fin du code éditable
    assert(a.subtract(b).doubleValue() == 0.9);
}

Réponse 5

Un énoncé et une réponse simple encore une fois. Il fallait connaître les spécifités de ce constructeur. En initialisant un BigDecimal avec un double, la valeur initialisée est une valeur approchante au paramètre. En utilisant un paramètre de type String, alors c’est la valeur exacte qui est utilisée.

    BigDecimal a = new BigDecimal("2.00");
    BigDecimal b = new BigDecimal("1.10");

Question 6

Comment accède-t’on dans la méthode getSuperVal à l’attribut val de la classe B ?

class B {

    int val = 2;
    A a = new A();

    class A {
        final public int val = 3;

        int getSuperVal() {
            // Début du code éditable
            return ;
            // Fin du code éditable

        }
    }
}

Réponse 6

Syntaxe peu utilisée, mais encore une fois cette réponse était simple à donner dans un navigateur sans auto-complétion.

return B.this.val;

Question 7

NB : Cette question a remplacé 6 la question le dernier jour de Devoxx France.
Comment faire en sorte que myMap ait une taille de 3 ? La Map ne doit contenir que des clés “test”.

// Début du code éditable
Map<String, Integer> myMap = new HashMap<String, Integer>();
// Fin du code éditable

myMap.put(new String("test"), 1);
myMap.put(new String("test"), 2);
myMap.put("test", 3);

int size = myMap.size();
assert(size == 3);

Réponse 7

Encore une fois il fallait un peu connaître les classes qui composent l’API Collection.

Map<String, Integer> myMap = new IdentityHashMap<String, Integer>();

Merci à tous ceux qui sont venus nous voir sur le stand, on a passé de bon moments. A l’année prochaine !

The post Bilan de Devoxx France first appeared on In Fine - Le Blog.

Historique

Lors de la sortie de la version 2.1 de Google Web Toolkit, une nouvelle API : RequestFactory a fait son apparition. Cette API a été conçue dans le but de simplifier l’interaction et la manipulation de données côté serveur depuis le client (javascript).
Auparavant, les développeurs utilisaient essentiellement GWT-RPC pour les appels de service impliquant des manipulations de données côté serveur.
Etant donné que le code côté client interagit avec du Java côté serveur, GWT-RPC fournit nativement
un mécanisme de sérialisation de données puissant. Cependant, cela ajoutait également un certain nombre de contraintes. Entres autres, le fait que tout objet échangé entre le client et le serveur devait être Serializable (au sens GWT), l’utilisation du pattern DTO qui induisait une redondance du code métier serveur au niveau du client etc.

Différence entre GWT-RPC et RequestFactory

La différence fondamentale entre les deux API réside dans l’orientation. GWT-RPC  est une API orientée service. A la base, elle permet d’invoquer des méthodes distantes d’une couche service pour interagir avec les données.

RequestFactory quant à elle est une API orientée donnée. Elle invoque directement des méthodes exposées non pas sur une couche service, mais sur les entités métiers (selon la terminologie GWT) elles-mêmes. C’est comme si on rendait les données serveurs disponibles au niveau du client. Les méthodes invoquées sont alors les méthodes des objets métiers.

Concepts de base

RequestFactory se base sur la notion de Proxy. Pour effectuer des opérations sur les données côté serveur, il définit un objet proxy qui “représente” cet objet serveur au niveau du client. Ce proxy est en fait une “interface” qui définit l’ensemble des méthodes qu’on voudrait exposer sur l’objet métier lui-même. Pour déclencher l’exécution d’une action sur l’objet côté serveur, il suffit de l’invoquer sur l’interface du proxy et RequestFactory se charge de l’envoi de la requête ainsi que de la sérialisation/déserialisation des données. Il est à noter qu’il utilise un protocole de sérialisation qui lui est propre et qui est différent de GWT-RPC.

Quelques règles à respecter

Le fonctionnement interne de RequestFactory impose quelques contraintes au niveau des classes métiers dont :

L’objet métier doit avoir un constructeur sans argument

la nécéssité d’avoir un champ VERSION dans la classe métier (annoté @Version en JPA). Ce champ permet à RequestFactory de tester si un objet a changé d’état.

Chaque Entité doit également disposer d’une méthode statique permettant de retrouver une instance de l’objet par son identifiant. Par exemple, pour l’entité de type Person, ce sera :

public static findPerson(Long id) {

// retrieving object by Id using EntityManager

}

Cas d’utilisation

Supposons alors qu’on ait un objet métier Personne dans notre application. Les objets de cette classe sont déstinés à être sauvegardés dans une base de données. On les appelle tout naturellement des “Entités” dans RequestFactory. On supposera que la persistance est gérée par Hibernate dans notre application et que tout a déjà été configuré (hibernate.cfg.xml, etc.). Nous avons donc dans notre domaine, le code suivant :

@Entity public class Person {
  @Id
@Column(name = "id")
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

@Version
@Column(name = "version")
private Integer version;

@Version
@Column(name = "name")
private String name;
@Column(name = "surname")
private String surname;

  @JoinColumn(name="address_id")
  Address address;

  public Personne() { }  // Getters and setters ...

}

Après avoir défini notre objet métier, on va donc lui adjoindre un “Proxy” qui sera une représentation de cet objet métier côté client. RequestFactory se charge alors de
propager les opérations invoquées sur les proxy vers les entités côté serveur. Il est également important de noter que RequestFactory envoie seulement les différences entre
ce qu’il y a côté serveur et côté client, économisant ainsi la bande passante.

Entity Proxy

Une entity proxy est un proxy qui comme son nom l’indique, représente une entité côté serveur. Pour la définir il suffit de créer une interface qui étend EntityProxy
et d’indiquer la classe métier qu’il représente via l’annotation @ProxyFor.

@ProxyFor(Person.class)
public interface PersonProxy extends EntityProxy {
public Person() { }
// Les méthodes exposées ...
public String getName();
public void setName(String name);
public AddressProxy getAddress();
public void setAddress(AddressProxy address);
// Les méthodes exposées ...
public String getName();
public void setName(String name);
public AddressProxy getAddress();
public void setAddress(AddressProxy address);
}

Les méthodes qu’on a défini dans le proxy sont les méthodes “invocables” sur l’objet métier. Ainsi, si on veut restreindre l’appel à certaines méthodes de l’objet métier
côté serveur, il suffit de ne pas l’indiquer dans le proxy. Ici par exemple, on a omis les modificateurs de Surname, ce qui veut dire qu’on ne pourra pas invoquer la méthode
de modification du prénom depuis le côté client.
Remarquons également que si une Entité A possède une référence vers une autre Entité B, les signatures du proxy AProxy feront référence à des BProxy (dans notre cas, AddressProxy).

Le lien entre le client et le serveur : RequestFactory

Après avoir défini les entités et leurs proxy, on crée maintenant la RequestFactory elle-même. C’est une interface qui comme son nom l’indique va créer les “stubs”
permettant la communication entre le client et le serveur.

public interface ApplicationRequestFactory extends RequestFactory

{

    PersonRequest personRequest();

    AddressRequest addressRequest();
}

PersonRequest et AddressRequest sont nos stubs pour les opérations concernant respectivement les entités Person et Address.

@Service(PersonServiceDAO.class)
public interface PersonneRequestContext extends RequestContext {

Request<List<PersonProxy>> getPersonList();

Request<PersonProxy> findPersonById(Long id);

}

Notons que les stubs utilisent toujours Request comme type de retour, où X est le paramètre de retour de la méthode de service.
Le stub doit nommer via une annotation, la méthode qui implémente les services côté serveur. Ainsi, dans notre exemple on a deux méthodes qu’on peut invoquer côté serveur
pour les entités de la classe Personne : on peut retrouver la liste complète ou encore retrouver une Personne par son identifiant.
On pourrait imaginer une classe service comme la suivante ( j’ai omis volontairement toute la partie de gestion des exceptions liées à la persistance des données pour une raison de lisibilité) :

public class PersonServiceDAO {

public List<PersonProxy> getPersonList()
  {
      List<Person> personList = new ArrayList();
      EntityManager entityManager = PersistenceManager.getEntityManagerFactory().createEntityManager();
      try {
          personList = entityManager.createQuery("FROM Person").getResultList();
      } catch (Exception e) {
          e.printStackTrace();
      }
      return personList;
  }

public Personne findPersonById(Long id) {
      EntityManager entityManager = PersistenceManager.getEntityManagerFactory().createEntityManager();
      Person person = null;
      try {
          person = entityManager.find(Person.class, id);
      } catch (Exception e) {
          e.printStackTrace();
      }
      return person;
  }
}

Utiliser RequestFactory

Enfin la dernière étape pour l’exécution de RequestFactory est de l’invoquer depuis le code client. Dans un premier temps, on doit initialiser le bus d’évènement. Une manière de procéder c’est de faire l’initialisation dans le constructeur de la classe dans laquelle on va utiliser RequestFactory.

public class OurClassWindow {
final EventBus eventBus = new SimpleEventBus();
ApplicationRequestFactory requestFactory = GWT.create(ApplicationRequestFactory.class);

public OurClassWindow() {
// Initialize event bus
requestFactory.initialize(eventBus);
}

}

Le mécanisme d’appels dans RequestFactory est très similaire à ce que l’on retrouve dans GWT-RPC. Après avoir retrouvé la requestContext, on invoque la méthode tout en
passant un callback qui sera appelé par RequestFactory au retour de la fonction.

Receiver<List<PersonProxy>> receiver = new Receiver<List<PersonProxy>>(){
@Override 	public void onSuccess(List<PersonProxy> response) {

// Do something with the response from RequestFactory

} };

requestFactory.personRequestContext.getPersonList().fire(receiver);

receiver ici, représente la méthode callback qui sera appelée au retour de la fonction. Comme dans GWT-RPC, il dispose de méthodes onSuccess et onFailure permettant de gérer
les cas de réussite ou d’échecs après l’appel.

Conclusion

Si vous avez déjà codé en GWT, vous savez à quel point il est fastidieux d’écrire des services uniquement pour ramener des données stockées en base  : RequestFactory est une manière élégante simple pour effectuer à moindre coût des appels vers un backend. L’API et la mise en oeuvre sont similaires à ceux de GWT-RPC, il est ainsi très facile de l’appréhender même si on est habitué à GWT-RPC.

pour aller plus loin : https://developers.google.com/web-toolkit/doc/latest/DevGuideRequestFactory

The post RequestFactory ou comment faire du CRUD avec GWT first appeared on In Fine - Le Blog.

Cet article est destiné à ceux qui ont la ‘chance’ d’avoir Tomcat 6 comme serveur pour leurs applications et qui doivent paramétrer le pool de connexions par JNDI.

Voici un petit article issu d’une demande d’un client.

Le client : C’est bien la configuration par JNDI, ça serait mieux si on ne voyait pas le mot de passe en clair …

Moi: No problem, everything is possible (enfin je crois) …

Effectivement c’est possible. D’après la documentation, il suffit d’implémenter une classe de type ‘factory’ pour instancier les connexions avec la base de données.

Dans cet article, vous verrez comment crypter facilement un mot de passe ou autre mais aussi comment remplacer le pool de connexion DBCP  par le pool de connexion de Tomcat 7 (plus performant à  mon goût).

Tout ceci se fait en 3 étapes :

• Codage d’une classe ‘Factory’
• Configuration de la ressource JNDI
• Copier les jar dans le répertoire lib de Tomcat

Le processus de cryptage ne sera pas détaillé ici.
Pour plus d’information, vous avez une classe “EncryptHelper” dans les sources (voir à la fin).

1° La classe Factory

Ici j’utilise le pool de connexion de Tomcat 7 :

public class Tomcat7EncryptedFactory extends org.apache.tomcat.jdbc.pool.DataSourceFactory implements SecuredFactory{

	@SuppressWarnings("rawtypes")
	@Override
	public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable environment) throws Exception {
		Object o = super.getObjectInstance(obj, name, nameCtx, environment);
		if (o != null && o instanceof org.apache.tomcat.jdbc.pool.DataSource) {
			org.apache.tomcat.jdbc.pool.DataSource ds = (org.apache.tomcat.jdbc.pool.DataSource) o;
			// recuperation du login et mot de passe cryptes
			String cryptedUsername = ds.getUsername();
			String cryptedPassword = ds.getDbProperties().getProperty("password");
			// on decrypte le password
			if (cryptedPassword != null && cryptedPassword.length() > 0) {
				String pwd = EncryptHelper.decryptData(secretKeyPassword, cryptedPassword);
				ds.setPassword(pwd);
			}
			// on decrypte le login
			if (cryptedUsername != null && cryptedUsername.length() > 0) {
				String username = EncryptHelper.decryptData(secretKeyUser, cryptedUsername);
				ds.setUsername(username);
			}
			// on set la taille initiale avec le minimum idle
			// on doit laisser le initialSize a 0 car il ne faut pas cree de connexion tout de suite car on a les identifiants cryptes.
			int minIdleSize = ds.getMinIdle();
			ds.setInitialSize(minIdleSize);
			ds.setConnectionProperties(ds.getConnectionProperties());

			// on ferme le pool deja parametre
			ds.close();
			// on recree le pool avec les nouveaux parametres
			ds.createPool();
			System.out.println("Initialisation de la datasource JNDI : OK");
			return ds;
		} else {
			System.out.println("Initialisation de la datasource JNDI : KO");
			return null;
		}
	}
}

Juste que la rien de difficile ^_^

2° Configuration JNDI

Extrait du fichier de configuration des ressources de Tomcat 6 (conf/context.xml)

    auth="Container" type="javax.sql.DataSource"
    factory="fr.cnvt.tomcat.Tomcat7EncryptedFactory"
    username="sD20tsCeFQPP3HuQV17yXw=="
    password="LoPCUiDWD47S6wIOTZWvBX7X9XTLt2vS9Sv52csoEGo="
    driverClassName="my.driver.class"
    url="my.jdbc.url"
    initialSize="0" maxActive="20" minIdle="5" maxIdle="10"
    validationQuery="SELECT 1 FROM Dual" validationQueryTimeout="300"
    maxWait="30000"
    removeAbandoned="true" removeAbandonedTimeout="600" logAbandoned="true"
    timeBetweenEvictionRunsMillis="20000"
    testWhileIdle="true"
    connectionProperties="CHARSET=utf8;" />

Comme vous pouvez le voir, le login (username) et le mot de passe (password) sont cryptés.

Vous pouvez avoir le même login et mot de passe (c’est bizarre comme c’est fréquent…) , les 2 chaines cryptés seront différentes (normal j’utilise 2 clés de cryptage différentes ^_^)

3° Librairies dans Tomcat

Dernières étapes, il suffit de copier les fichiers tomcat-datasource-factory-1.0.0.jar et tomcat-jdbc-7.0.22.jar(dans le répertoire lib du zip) dans le répertoire “lib” de Tomcat 6.

Voila en 3 copié-collé, vous avez un pool de connexion sans mot de passe en clair ^_^

Pour générer vos propres login et password cryptés, il suffit d’utiliser la classe EncryptHelper comme ceci:

	@Test
	public void generateEncryptedValues(){
		String login = "monsupertest";
		String password = "monsupertestaussi";
		String cryptedLogin = EncryptHelper.encryptData(SecuredFactory.secretKeyUser, login);
		String cryptedPassword = EncryptHelper.encryptData(SecuredFactory.secretKeyPassword, password);
		String decryptedLogin = EncryptHelper.decryptData(SecuredFactory.secretKeyUser, cryptedLogin);
		String decryptedPassword = EncryptHelper.decryptData(SecuredFactory.secretKeyPassword, cryptedPassword);
		assertEquals(login, decryptedLogin);
		assertEquals(password, decryptedPassword);
		System.out.println("Login crypte : " + cryptedLogin);
		System.out.println("Mot de passe crypte : " + cryptedPassword);
	}

Pour les curieux, le fichier zip contient également un pool DBCP et C3P0 qui gèrent aussi le login et mot de passe cryptés. Les clés de cryptages sont dans l’interface SecuredFactory.

Enjoy

Les sources sont disponibles ici

The post Tomcat 6 – JNDI – password crypté et pool de connexion V7 first appeared on In Fine - Le Blog.

Comparatifs de frameworks web à Devoxx 2011

Cet article a pour but de présenter brièvement la présentation de Stijn Van den Enden, lors du Devoxx 2011, sur les performances brutes de plusieurs frameworks connus et de partager quelques impressions sur ce sujet.

Dans la première partie, il présente la méthodologie de tests ainsi que les outils : le coté test.
Dans la seconde partie, il nous montre les résultats qu’il a obtenu : le coté performance.
Les slides de la présentation sont disponibles ici

En résumé, on y voit la mise en place de la plateforme de tests ainsi que les outils utilisés.

Plateforme de tests :

Conclusion :

Sa conclusion étant qu’en terme de performance brute, on a :

1. GWT
2. Spring MVC
3. JSF 2.1.2 (Implementation Mojarra) ou Wicket
4. MyFaces (n’apparait pas dans le slide)

Dans sa conclusion, qui n’apparait pas dans les slides, il dit aussi que souvent, ce n’est pas le framework web qui est la principale cause de la mauvaise performance d’une application.
Pendant sa présentation, il a souligné que le seul framework qui a posé problème est JSF 2 (problème de mémoire, ce qui ne m’étonne pas).
Enfin, il nous rappelle qu’il faut aussi penser à la facilité de développement pour garder une bonne productivité.

Avis personnel

Pour ma part, la conclusion de Stijn Van den Enden ne doit pas tenir compte du temps de rendu de la page, sinon Spring MVC serait 1er avec GWT voire même devant.

Sur le point où il faut privilégier la facilité de développement, on regrettera l’absence du comparatif des frameworks Grails et Play qui sont tous deux excellents sur ce point.

Si vous avez envie de changer de framework, d’après plusieurs présentations vu sur le même sujet (par exemple l’article de Peter Thomas), il faut se fixer un prototype de page à faire et si cela vous parait trop difficile, c’est que celui-ci n’est surement pas adapté à vos besoins.

Personnellement, je me demande pourquoi il y a tant de personnes qui démarrent un projet encore avec JSF pour le web alors qu’il a autant de problèmes de performance et qu’il est parfois si compliqué de faire des choses simples avec (exemple pagination coté serveur…).

Pour finir, son approche de Spring MVC est intéressante car elle tend vers une pratique que j’ai adopté. Pour ma part, j’ai abandonné l’idée que le Java était fait pour le web, car c’est loin d’être le cas. Je préfère juste garder Java pour la partie serveur et utiliser essentiellement des langages du web pour la vue : très peu de JSP et EL(Expression Language) avec beaucoup de HTML, CSS et JQuery (avec des données fournies au format JSON, d’ailleurs Spring MVC fait très bien cela).

S’il fallait choisir un framework pour le web en ce moment, je prendrai Grails pour un projet ‘from scratch’ ou Spring MVC pour un projet existant. Je n’ai pas assez d’expérience sur GWT mais sa génération du javascript me fait hésiter… Je garderai dans les deux cas, JQuery pour les composants riches car il existe énormément de plugins pour ce framework javascript ou ExtJS ou voir même du flash (flex).

En ce qui concerne Wicket, sa programmation ressemble un peu à du Swing (client lourd) qui pourrait dérouter un développeur web. Tapestry est intéressant mais le temps d’apprentissage est assez important.

Comparatif plus étendu

Pour ceux qui comme moi ont regretté l’absence de Grails et Play, voici un article intéressant avec un comparatif des deux et surtout une légère ‘customisation’ pour gagner en performance.
Notez que l’utilisation de Japid pour Play booste grandement ses performances et que Netty semble plus rapide que Tomcat.

Extrait du site JT Dev (vous pouvez cliquer sur les images pour les agrandir)

Plus de détails ici

The post Devoxx 2011 – Comparatif de performances des frameworks web Java et plus encore … first appeared on In Fine - Le Blog.

La seconde édition de ce livre est sortie il y a déjà quelques mois. Cette nouvelle édition apporte le support de Maven 3 ainsi que des corrections. Je n’avais entendu que du bien de la première version, allons voir ce que donne cette seconde édition !
Depuis quelques années j’utilise 2 ressources principales afin de m’aider dans mon utilisation quotidienne de Maven : la documentation officielle et l’ebook Maven The Definitive Guide dont j’ai toujours une copie dans ma dropbox. Cet ebook a beaucoup de lacunes et n’approfondie par certaines notions Maven qui pourtant le mériteraient, mais je le consulte tout de même régulièrement.

Je me considère comme un bon utilisateur de Maven, mais je suis loin d’être un expert. Cela fait déjà plusieurs années que je le pratique, et je l’utilise quotidiennement dans le cadre de mes missions chez les clients. En lisant le livre Apache maven l’objectif était double :

• Apprendre de nouvelles choses ou appronfondir certaines notions que j’utilise peu
• Trouver un complément à Maven The Definitive Guide qui date désormais quelque peu

Ce livre propose un scénario…

Ceci peut paraître étrange pour un livre d’informatique, mais il y a effectivement un scénario. Arnaud et Nicolas sont 2 compères qui retrouvent un vieille application sur une disquette gérant une liste de courses. Cette application se construit grâce à des scripts spécifiques à chaque OS : un fichier .bat et un fichier .sh.

Ils décident d’améliorer l’application en lui ajoutant de nouvelles fonctionnalités. D’une simple application, elle deviendra un vrai gros site web. Qui dit grosse application, dit industrialisation dans le process de livraison, de tests etc… Et c’est là que Maven intervient.

Déboussolés par les divers problèmes qui se posent à eux, Nicolas et Arnaud seront aidés dans leur quête à créer l’application de gestion de course ultime, par d’autres personnes ayant les connaissances nécessaires afin de surmonter ces épreuves. Citons parmi ces seconds couteaux Olivier Lamy, Vincent Massol, Antonio Goncalves, Guillaume Laforge et bien d’autres.
Désolé de vous avoir spoilé une bonne part du scénario, mais je vous assure qu’il y a encore beaucoup de rebondissements dont je ne vous ai pas parlé.

Avoir un scénario est déroutant pour un livre d’informatique. La forme habituelle didactique est ici changé en “roman” avec ses rebondissements et une belle fin. Par conséquent ce livre se lit d’une traite malgré le sujet qui peut sembler difficile au premier abord. Le livre prend le parti de montrer des situations concrètes issues des expériences de Nicolas et Maven, et nous propose une solution généralement grâce à une fonctionnalité de Maven ou à l’un de ses plugins.

… Et du contenu

En effet Maven est généralement considéré comme compliqué. Cet ouvrage veut prouver le contraire. Maven est prévu pour répondre à plusieurs problématiques courantes des projets. Ce qui le rend difficile (son cycle de vie, ses plugins…) est abordé progressivement dans le livre au travers de problèmes que n’importe quel utilisateur de Maven pourrait rencontrer sur un projet.

Le livre n’aborde pas que les bases de Maven et par exemple des plugins peu courants sont présentés tels que le maven-osgi-compiler-plugin ou le flexmojos-maven-plugin. D’autres points liés à Maven sont abordés tels qu’une comparaison des IDE ou des différents gestionnaires de dépôt.

Cette seconde édition apporte évidemment quelques nouveautés. La plus importante est lié à Maven 3. Dans cette édition, la plupart des chapitres contiennent un encart détaillant les spécificités de Maven 3. Ces encarts ne sont pas très nombreux, Maven 3 étant en grande partie compatible avec Maven 2. Les autres nouveautés concernent les corrections de la première édition, ainsi que l’ajout d’un chapitre. Pour être clair, si vous possédez la première édition, les nouveautés ne justifient pas de se procurer la nouvelle.

Le livre parfait ?

Ce livre comporte de très nombreuses qualités. Le sujet est bien maitrisé et l’apprentissage est progressif sans pour autant être trop lent. L’approche est très pragmatique et les fonctionnalités de Maven sont présentées par une approche très pratique, plutôt que par une approche théorique que de nombreux ouvrages d’informatique indigestes privilégient. De plus les livres en français et de qualité sont rares, celui-ci en fait partie, et je le recommande vivement. Apprendre Maven ou se perfectionner n’aura jamais été plus facile.

Me concernant j’ai trouvé le parfait complément à Maven The Definitive Guide. Il ne me manque plus qu’une version électronique afin de l’avoir dans ma Dropbox, et je pourrais presque me passer de Maven The Definitive Guide.

Chaque lecteur, en fonction de sa propre expérience, trouvera des choses à redire. Pour ma part, j’aurais souhaité que certains points soient approfondis comme les extensions ou l’écriture de plugins. Cette seconde édition apporte certainement son lot de correction, mais inévitablement les nouvelles parties ajoutées comportent leur lot d’erreurs. Heureusement elles restent mineures et ne nuisent pas à la compréhension du passage concernée. La perle étant le listing du code de la page 185 (à lire si vous avez le bouquin sous la main ).

Assez de bavardages, cet excellent ouvrage est à mettre entre toutes vos mains, car vous utilisez tous Maven. Voici la page du livre chez l’éditeur contenant la table des matières ainsi que des extraits.

The post J’ai testé le livre : Apache Maven version 2 et 3 par Nicolas De Loof et Arnaud Héritier first appeared on In Fine - Le Blog.

Ceylon est un nouveau langage s’exécutant sur la JVM. Il rejoint une liste désormais assez longue qui comprend notamment :

• Groovy
• Jython
• Jruby
• Scala
• Kotlin
• Fantom
• Gosu
• …

Gavin King a créé Ceylon parce qu’il était frustré par les limitations de Java. Cette session a été animée par deux français, Emmanuel Bernard et Stéphane Epardaud qui sont commiters sur le projet. Ils ont débuté la session en définissant les objectifs de Ceylon, avant de continuer sur ses fonctionnalités à l’aide de code. Je ne vais pas reproduire le code qu’ils ont utilisé pendant la présentation dans cet article, je vais essayer d’être plus concis.

Emmanuel commence par nous indiquer les objectifs de Ceylon :

• Permettre d’écrire du code plus simple que l’équivalent en java
• Éviter au développeur de tomber dans les principaux pièges de java

Ceylon est pensé pour être lu facilement par des développeurs venant du monde Java. Emmanuel insiste bien sur ce point : Ceylon doit être simple à utiliser mais également simple à lire. Le code ne doit pas soulever d’ambiguïté.

Principes de base

Classe simple

shared class User(String username, Natural age) {
    shared String username = username;
    shared Natural age = age;

    shared void printUser() {
        print("User name : " username " with age " age " is printed");
    }
}

Cette classe est courte, mais il y a déjà plusieurs choses à dire dessus :

• Le mot-clé class indique évidemment qu’il s’agit d’une déclaration de classe
• Le mot-clé shared est l’équivalent du public de Java. Si le mot-clé shared est omis, alors la visibilité est privée (visibilité par défaut en Ceylon)
• A la suite de la déclaration de la classe User se trouvent des paramètres (String username, Natural age), il s’agit de la déclaration du constructeur. Je dis bien du car une Ceylon interdit la surcharge de méthode et donc un seul constructeur est autorisé
• Natural est l’objet représentant un nombre entier naturel. En Ceylon, il n’y a pas de type primitif
• Les attributs de la classe sont obligatoirement initialisés, il n’y a pas de valeur par défaut, même null n’est pas implicite. Ici, les valeurs sont celles fournies au constructeur
• La déclaration de la méthode printUser se fait comme en Java, le mot-clé shared en plus si on souhaite l’exposer
• La concaténation de chaîne de caractère peut se faire sans le caractère +. La concaténation avec le caractère + fonctionne également

Méthodes

shared class Parent() {
    shared default void printMe() {
         print("I'm in parent class");
    }

    shared void printMessage(String messageToPrint = "default argument value") {
         print("I'm in parent class and I print " + messageToPrint);
    }
}

shared class Child() extends Parent() {
    shared actual void printMe() {
         print("I'm in child class");
    }
}

void testCeylon() {
    // appel de méthodes
    Parent p = Parent();
    p.printMe();
    p.printMessage(); // default value of parameter used - will work on milestone 2
    p.printMessage("message given as argument");  // classic call
    p.printMessage {  // name argument used
        messageToPrint = "message with named arguments";
    };
}

Encore une fois, malgré la petite taille de code et sa lisibilité, plusieurs fonctionnalités sont à décrire :

• Comme dit plus haut, les méthodes ne sont pas surchargeables. Pour palier à cette obligation les paramètres peuvent avoir des valeurs par défaut (ligne 6), des varargs peuvent être utilisés (comme en java), ou des union types peuvent être utilisés (voir la doc pour plus de détails)
• Les paramètres des méthodes sont nommés – ligne 22
• Les méthodes peuvent être redéfinies dans les classes filles mais il faut l’autoriser explicitement grâce au mot clé default dans la classe parent (équivalent du virtual du C++ utilisé dans la classe parent) – ligne 2
• Lors de la rédéfinition de la méthode dans une classe fille, il faut obligatoirement utiliser le mot-clé actual (équivalent à l’annotation @Override de Java) – ligne 12

null et immuabilité

Par défaut toutes les variables sont immuables en Ceylon. Afin de les rendre modifiables il faut explicitement adapter la syntaxe de déclaration d’une variable en ajoutant le mot-clé variable et effectuer l’affectation avec l’opérateur := :

shared class ImmutableExample(Natural year) {
    // immutable
    Natural year = year;
    // Mutable
    variable Natural writableYear := year;
}

Afin d’éviter les trop nombreux NullPointerException de Java, une variable qui pourrait contenir la valeur null doit être déclaré à l’aide d’un ?. Ceci a des conséquences sur la manière d’utiliser ces variables comme le montre le code ci-dessous :

// myBestVariable can be null
String? myBestVariable = functionThatCanReturnNull();
// to work on myBestVariable, a null check must be done
if (exists myBestVariable) {
    functionThatNeedAString(myBestVariable);
}
else {
    functionThatNeedAString("default value");
}

Autres fonctionnalités

Emmanuel et Stéphane ont présenté d’autres fonctionnalités importantes de Ceylon telles que les union type et les intersection type. Pour plus de détails, reportez vous à la documentation officielle.
Malgré les arguments nommés, il est possible d’utiliser les generics. Les annotations sont également disponibles.
La compatibilité entre Java et Ceylon est également disponible. Ceylon peut utiliser du code écrit en Java, et Java peut appeler du code Ceylon.

En pratique

Emmanuel et Stéphane, après avoir transmis les bases à l’auditoire, effectuent une démo en live de Ceylon dans Eclipse. Un plugin Eclipse a été développé et est déjà fontionnel. L’autocomplétion fonctionne bien, la coloration syntaxique et le refactoring également. Plus d’infos sur le repo git associé.

Aucune version de Ceylon n’a encore été releasée. La prochaine version à sortir sera la milestone 1 qui ne comprendra pas encore toutes les fonctionnalités de la spécification. Trois milestones sont prévues avant que la version 1.0 ne sorte.

Test de Ceylon

Il est évidemment possible aujourd’hui de tester dès aujourd’hui Ceylon et pour cela, j’ai réalisé un petit screencast afin de vous montrer qu’avoir le compilateur Ceylon utilisable sur son poste est vraiment simple et rapide.

Les prérequis sont d’avoir sur sa machine Java 6, Ant et Git. Dans le screencast, je clone les trois repositories Git nécessaires à la création du compilateur. Chacun nécessite Ant afin d’être compilé. Une fois le compilateur généré, je le teste en compilant l’exemple de code que j’ai donné ci-dessus dans le paragraphe Méthodes, et je l’exécute.

Pour ceux qui veulent tester, je vous retranscrits les commandes utilisées dans le screencast afin de faciliter le copier coller

Une fois le compilateur généré, je l’ai testé. Mon fichier source se nomme florian_boulay.ceylon et se trouve dans le répertoire samples. Le répertoire build contient les fichiers Ceylon compilés. testCeylon correspond au nom de la fonction appelée pour lancer le programme.

Ceylon est un langage simple à comprendre pour qui vient de Java. En écrire est également à la portée de tous. Jusque là les objectifs de Gavin King sont atteints.

Fin de la session

Pour finir, Emmanuel nous indique que Ceylon a enfin sont site web : http://ceylon-lang.org

Il contient une documentation très complète, la spécification du langage écrite par Gavin King, un blog et tout ce qu’il faut pour contribuer au développement du langage. C’est là bas qu’il faut aller si vous souhaitez tester le langage qui n’a pas encore été releasé, mais peut être testé via la récupération du code source sur Github.

Comme vous le voyez, le logo de Ceylon est un éléphant, est-ce un hommage à PHP ? On peut lui souhaiter qu’il ait le même succès que PHP

De nombreux nouveaux langages ont émergé ces derniers mois fonctionnant sur la JVM (Eclipse Xtend, JetBrains Kotlin). Comme dit plus haut, Ceylon veut rester accessible à tout le monde en restant simple et facilement compréhensible. Est-ce que ces atouts seront suffisants pour faire de Ceylon une alternative à Java réellement utilisée, comme l’est Scala aujourd’hui ? Faites vous votre propre opinion et essayez le.

The post Devoxx 2011 – Ceylon first appeared on In Fine - Le Blog.