Troisi̬me journ̩e de conf̩rences РJeudi 03/06 РApr̬s-midi

Voilà, Jazoon c’est fini. A l’heure où je vous écris ces lignes, je suis en région parisienne, et met de l’ordre dans mes notes.

Je n’ai pas vraiment de point de comparaison avec les autres grands conférences de l’ecosystème Java (JavaOne, Devoxx), mais voici mon sentiment par rapport à celle-ci.

Je m’attendais à beaucoup plus de participants. Compte tenu de la portée, des sujets et de la renomée de la conférence. Sans être réellement confidentielle, la quantité de personnes présentes n’est pas plus impressionante que cela.

J’ai identifié une demi-douzaine de français, Emmanuel Bernard (RedHat, JBoss, Hibernate) qui était conférencier, et des représentants de Xebia et Sfeir. Il y avait d’autres francophones, venant de suisse romande, mais je ne suis pas combien. La grande majorité des participants étaient des germanophones.

La totalité des conférences était en anglais. Seul un évènement attaché, concernant un retour d’expérience sur la mise en place d’une carte/certificat pour signatures électroniques était en allemand (et partant je ne suis pas en mesure de vous en parler).

L’infrastructure est bien prévue et très bien gérée. Rien à redire, si ce n’est les problèmes de connexion WIFI le premier jour, qui ont été réparés par la suite. A charge des participants de faire attention à leur ligne : une consommation excessive de muffins ou de croissants est contre-indiquée pour la santé. L’évènement a lieu dans un énorme complexe cinématographique, ce qui présente des avantages (fauteuil, bar, toilette en conséquence, …), mais un petit inconvénient : il n’y a pas de tablette pour prendre des notes ou poser son portable. En ce qui me concerne, le lattitude E6500 a tendance à enormément chauffer au bout d’un moment, et prendre des notes en permanence n’a pas toujours été une partie de plaisir.

Les stands des sponsors (SSII ou clients finaux, surtout des banques) ne sont pas intrusifs et pas gênant du tout.

En ce qui concerne le fond, le choix des conférences, et surtout la répartition entre la grande salle et les autres, les choix n’ont pas toujours été pertinents. Par exemple, parmi les sessions auxquelles j’ai participé, celles sur la gestion des tests unitaires, et celle sur la programmation parallèle auraient été bien mieux dans la grande salle. Certains sujets n’étaient à mon sens plus vraiment à la mode.

Session technique : Building DSL with Eclipse, Peter Friese, Itemis

Cette session porte sur la création d’un DSL externe, en utilisant essentiellement l’outil Xtext, qui est un plugin Eclipse.

Il vallait mieux avoir suivit la conférence de Neal Ford sur les DSL au préalable, pour suivre celle-ci.

Peter Friese rappelle qu’un DSL est un language:

  • qui permet d’exprimer son intention
  • qui permet de résoudre uniquement UN problème

A cet égard, Java est un couteau suisse, un langage général avec lequel on peut tout faire, un DSL ne permet de faire qu’une seule chose.

Le conférencier donne deux exemples de DSL:

  • SQL
  • Ant

Selon lui, SQL est un bon exemple de DSL, on exprime uniquement ce que l’on a besoin d’exprimer, et il n’est pas possible de faire autre chose avec.

1  SELECT colonne1, colonne2
2  FROM maTable
3  WHERE colonne1.champX = colonne2.champY;

Il est important, dans cet exemple que le FROM soit avant le WHERE, même si, d’un point de vue sémantique, tout serait identique en inversant ces deux lignes, parce que si on a pas écrit auparavant la ligne 2, aucun IDE ne serait en mesure de vous faire de la completion automatique à partir des informations précédentes (il faut savoir que les colonnes proviennent de la table maTable pour proposer les champs champX et champY).

Il montre ensuite un exemple de script Ant, et exemple que, dans ce cas, on met dans le script beaucoup plus de choses que juste ce dont il y a besoin pour exprimer un build. Cela est du à des raisons historiques, l’auteur de Ant aurait créé cet outil dans lors d’un voyage, et il n’avait qu’un parser XML sous la main, et pas envie de redévelopper un parser.

Un SQL interne (ce qui n’est pas le sujet de cette session) est une API qui permet de faire une seule chose, comme par exemple :

   Mailer.mail()
         .to("receiver@example.com")
         .from("sender@example.com")
         .subject("Example of internal DSL")
         .body("Hello World !")
         .send();

Le conférencier cite l’ouvrage suivant : The definitive ANTLR reference, Building DSL de Terence Parr.
Ce livre donne une liste de ce qu’il y a à faire pour créer un DSL externe:
1/ Créer une grammaire ANTLR
2/ Générer un parseur lexical à partir de la grammaire
3/ Le parseur va créer un arbre représentant le parsing
4/ Transformer l’arbre en modèle sémantique
5/ Itérer sur le modèle
6/ Donner les élément du modèle à un template

Le conférencier a passé des extraits d’une vidéo introductive sur les DSLs dans laquelle Martin Fowler expliquait qu’il y avait des problématiques spécifiques concernant l’écriture de DSL externes :

  • Manque d’éléments symboliques d’intégration (accolades, …)
  • Ecriture d’un parseur compliquée
  • Intégration des DSL non native dans les IDE (complétion automatique, navigation par ctrl-click, outlines, …)

A fin de résoudre ces problèmatique, il existe un outil : Xtext, qui est un plugin Eclipse permettant de définir formellement des grammaires dans une syntaxe proche de EBNF.

La syntaxe de définition de ces grammaires est elle même définie par une grammaire (DSL) qui, à l’aide du moteur interne de Xtext permet de bénéficier des avantages d’un IDE pour ce language (complétion, outlines, navigation rapide, …).

Xtext contient à la fois la définition de la grammaire pour l’écriture des grammaires, mais également un mécanisme qui fabrique un meta-modèle ecore à partir d’une grammaire particulière. Ecore est l’API interne d’Eclipse permettant de modéliser un méta-modèle.

A partir de ce meta-modèle ecore, Xtext génère un IDE pour cette grammaire, et donc pour ce DSL.

Il y a ensuite un exemple d’utilisation pour créer un DSL de création d’application mobiles. Les étapes sont:

  • 1/ Analyser la problématique métier (du domaine)
  • 2/ Etablir une relation entre les concepts métier du domaine et un langage
  • 3/ Ecrire un générateur

Pour générer du code (en Objective-C en l’occurence, pour les applications mobiles) à partir des données exprimées avec ce DSL, il utilise un autre plugin Eclipse qui s’appelle Xpand (language specialized on code generation based on EMF models). Je ne connais pas ce plugin, mais visiblement, compte-tenu des réactions de certaines personnes dans la salle, ce plugin ne serait pas très pratique, ou très stable.

Pour conclure, implémenter un DSL avec Xtext est, sinon facile, au moins aussi facile que possible. Xtext fournit un support important des DSL ansin décrit sous Eclipse. Par ailleurs, une intégration entre des DSL et Java est possible (Xtext fournissant un meta-modèle ecore nativement pour Java).

Le présentateur a annoncé un futur (8 juin) Webinar sur Xtext.

Technical Session : Easy to use, Highly available, High performance, Java Database access: seriously ? Craig Russell, Oracle

Cette session parle d’un outil, ClusterJ, permettant d’établir des clusters sur des bases MySQL.

High Performance File I/O The Perl/Java battle, Daniel Echhorn, Stephan Rufer

Cette session ansi que la suivante étaient des sessions courte, d’une vingtaine de minute et présentant donc trés rapidement une chose/une idée. C’est à mon sens un très bon format de présentation.

La problématique de cette mini-session, avec un titre ayant une odeur de troll, était de montrer les différences de performances d’I/O entre un code legacy écrit en Perl et un code plus récent écrit en Java.

La forme de la présentation était très intéressante :

  • On pose le contexte, on explique ce qu’on a fait
  • Test qui se déroule en live (démo), sous une forme graphique qui fait penser à un « Google fight », et les conférenciers qui en rajoute (« Allez Java ! »)
  • On discute du résultat

En l’occurence, il s’agissait d’un batch qui traitait et parsait des lignes avec un format contraint. Le résultat, graphiquement est que Java est beaucoup plus mauvais au départ et rattrape quasiment au bout d’un moment les perfomances de Perl, sans toutefois tout à fait les atteindre.

Je n’ai pas la possibilité (ni le temps) de faire un audit sur leur code, mais à mon avis leurs conclusions sont un peu erronées. Il y a peu de chance que le programme Java optimise ses performances sur proprement les IO, je pense que le gain de performances observé entre le début et la suite est surtout du à la gestion des String en Java. Les mêmes patterns doivent se retrouver dans les jeux de données, et au début, cela instancie beaucoup de String, qui se retrouve dans le pool de String au bout d’un certain temps. Je leur ai demandé à la suite de la conférence s’ils avaient examiné cela, ce qui n’était pas le cas.

DROIDinfo and DROIDparade, two little helpers for Android developers, Jörg Pleumann & Felic Jost, Noser Engineering AG

2010 est une bonne année pour les smartphones en général et pour les Androids en particulier.

Google fait en sorte de faciliter les choses pour les développeurs

http://developer.android.com/resources/dashboard/platform-versions.html

http://developer.android.com/

DROIDinfo développé par la société du conférencier permet d’avoir:

  • des informations supplémentaires sur le matériel d’un Android particulier
  • des résultats de benchs

Cela a permit de se rendre compte que:

  • Le HTC Dream contient un thermometre
  • Le péripharique de stockage externe n’est pas toujours récupéré par « /sdcard »
  • La CPU et les différence d’IO varient énormément d’un modèle à l’autre

Conclusion:

  • Supposer que les smartphones sont lents
  • Réalisez les traitements de manière asynchrone par rapport aux actions de l’interface
  • DROIDinfo est disponible sur l’AndroidMarket (attention deux versions différentes selon la version d’Android)
  • DROIDparade (beta) est une base de donnée des périphériques Android avec les caractéristiques déterminées par DROIDinfo

End keynote : Software in the service of handicapped people, Hans-Willem van Vliet, R et D at Otto Bock

Je n’ai malheureusement pas pu rester à la keynote de fermeture, pour cause d’avion à prendre, et donc je n’ai pu assister à la conclusion de cette présentation.

Vous pouvez néanmoins vous référer au compte-rendu officiel de Jazoon sur cette troisième journée.

Comme la keynote d’ouverture de la journée, cette keynote commence (et je n’ai eu que le début) par des explications techniques métiers.

Otto Bock était un prothésiste qui a inventé la prothèse modulaire en 1919. En 1919 également, la fondation Otto Bock a été créée, originellement pour opérer les amputés de la première guerre mondiale, puis elle a été fermée pour réouvrir à l’issue de la seconde guerre mondiale.

En 2010, la fondation a 4000 employés, est le leader mondial de la prothèse avec 40 sites internationaux et une R et D très importante.

J’ai appris que l’essentielle des amputations dans les pays industrialisés n’est pas du aux accidents, mais au diabète qui créé des infections.

Conclusion

Je suis content d’avoir passé ces trois jours à Jazoon, j’ai la tête un peu pleine comme un melon (mais je deverse dans ce blogue pour faire de la place).

Les sessions les plus intéressantes à mon sens ont été celles sur:

  • La programmation parallèle
  • La sécurité (mais pas toutes)
  • Les DSLs
  • Le management de la boite à outils de tests unitaires
  • Les chargeurs de classe

N’hésitez pas à poser des questions dans le forum si vous voulez que je détaille quelque chose.

Laisser un commentaire