Cette troisième et dernière journée de conférences démarre par une keynote au titre aussi étrange qu’exotique dont je n’ai pas compris le sujet pour l’instant. La keynote de fermeture est dédié à l’accessibilité numérique. C’est une bonne chose que l’accessibilité numérique soit mise en avant, c’est dommage que ce soit dans la keynote de fermeture, dans la mesure où de nombreux auditeurs (dont votre serviteur) devront écourter leur attention pour aller prendre leur avion ou train respectifs.

Keynote d’ouverture : The Gaïa satellite, data processing and challenges, William O’Mullane, ESAC

L’ESAC est le Centre Européen d’Astronomie Spaciale. Le présentateur est un spécialiste à l’ESAC du data mining. Le sujet de la keynote concerne les problématiques liées à la mise en place d’un satellite embarquant un télescope géant, Gaia.

Le présentateur commence en donnant un petit cours d’astronomie dont j’ai essentiellement retenu que l’origine du terme « voie lactée » vient du sein de Junon qui l’aurait généré.

Willian O’Mullane explique quelles sont les problématiques techniques physiques liées à l’environnement terrestre qui limitent fortement la précision possible pour les télescopes (atmosphère, gravité supérieure, …) qui imposent de créer des télescope sur un satellite. Il explique ensuite quel sont les besoins de précision, les quantités de données qui sont récupérées, puis persistées (de l’ordre de 10TB par jours il me semble).

Il donne ensuite les besoins des utilisateurs, par rapport au format de données récupérée et indique les types de traitement à effectuer pour avoir des rapports pertinents.

Compte tenu des problématiques on pourrait penser que la taille du projet informatique est gigantesque, mais il relative en comparant les nombres de ligne de code avec celles de projets comme Linux. D’un point de vue ordre de grandeur, le projet est cent fois plus petit que des projets comme Linux.

L’ESAC utilise Java pour le traitement des données, de manière quasiment exclusive, depuis 2000. Les raisons en sont :

• La portabilité : cela doit pouvoir fonctionner au moins jusqu’en 2020
• C’est plus facile d’écrire du code correct (typage statique : Eclipse!)

L’ESAC utilise :

• JUnit, Hudson;
• Apache common Math, log4J
• JBoss
• Aucun MPI particulier ou bibliothèque de grid

Du point de vue des performances, ils constatent de fait que le Java est plus rapide que le C, pour un code équivalent, métier, grâce au JIT sur un processeur Intel.

Il y a néanmoins un certain nombre d’inconvénients/limitation en Java :

• Java n’est pas la balle traçante (cela peut s’interpréter de différentes manière, je vous laisse interpréter);
• Trop peu de bibliothèques mathématiques maintenues (la meilleure étant ApacheCommon Math);
• Support numérique natif prévu non implémenté;
• Un respect des standards IEEE souvent défaillant et quasiment jamais corrigé.

Remarques supplémentaires :

• Il y a beaucoup de tests unitaires sur le projets;
• Les standards ont souvent besoins d’être adaptés sur mesure pour répondre aux besoins;

Des tests de virtualisation, en particulier de data grid ont été fait. Il semblerait qu’il y ait des problèmes sur le cloud d’Amazon quand on fait du DataGrid avec plus de 1000 noeuds (parce qu’en dessous ça vaut pas la peine, les noeuds sont même pas des super calculateurs, alors hein!).

Présentation très intéressante, comme tous les retours d’expérience, mais en l’occurrence, pour moi, le métier était trop pointu pour que je profite de tous ses apports.

Session technique : Essential of testing: the tools you need to know, Bettina Polasek, Marco Sicolini, AdNovum Informatik AG

On peut ajouter un sous-titre : One tool, one purpose

C’est fait, visiblement le sujet de cette présentation intéresse beaucoup: toutes les places (petite salle) sont prises et il y a une quarantaine de personnes assises sur les marches ou debout.

Les sessions d’aujourd’hui commencent fort avec cette présentation remarquable, qui portent plus sur la politique à avoir vis-vis des outils de tests, et de manière générale la manière de gérer ses outils, que sur les aspects les plus techniques, même si on a eu droit à toute une série de démo illustrant différents usage de tests.

Les équipes d’AdNovum ont poussé très loin les pratiques en matière de management des outils de travail, et en particulier des outils de développement.

Ces équipes ont fait le constat suivant :

• il y a de nombreux outils;
• chaque outils a ses avantages et ses inconvénients;
• il y a un recouvrement non négligeable entre ces outils.

Les objectifs sont:

• Savoir déterminer établir une bonne adéquation objectif / outil ;
• Pouvoir gérer et maintenir à niveau les compétences des équipes par rapport aux outils sélectionnés;
• Sélectionner un ensemble restreint mais suffisamment complet d’outils;
• Pouvoir gérer la mise à jour de cette boite à outil (et donc les compétences liées et l’historique de code).

Les critères de sélection sont:

• Technologiques:
  • Java
  • .NET
  • JavaFX
  • …
• Méthodologiques:
  • Statiques
  • Fonctionnels
  • De robustesse, de performance
  • D’ergonomie
  • De maintenabilité, de non-régression
  • …
• Couche concerné:
  • Web (UI)
  • Métier
  • Donnée

Ils considèrent que les décisions se prennent à différents niveau et qu’il faut en être conscient:

• Stratégique. Exemple: on choisit un contexte JEE
• Tactique. Exemple: on choisit JUnit
• Opérationnel. Exemple: on choisit JUnit 4.7

Les choix des différents niveau doivent être remis en question périodiquement, avec une période plus grande pour les hauts niveaux.

Avec cette approche, au jour présent, en ce qui concerne les tests, leur choix s’est porté vers les outils suivants (dans des catégories différentes):

• Grinder
• JUnit
• Selenium
• HtmlUnit
• Mockito
• Grinder
• Glassfish (embeddable)
• SOAP/REST Drivers
• SOAPUI
• PMD
• jDepends

Il y a ensuite toute une série de démos.

Avec Selenium, un test de niveau (UI). Remarque: il est possible de spécifier une vitesse inférieur pour voir le déroulement du test s’il est trop rapide.
Avec HtmlUnit, test de niveau UI également. Les développeurs ont le choix entre les deux, il y a un compromis à faire lorsqu’ils implémentent leurs tests sachant que :

• HtmlUnit est beaucoup plus rapide que Selenium;
• En contrepartie, Selenium utilise les vrais moteurs des navigateurs, alors que HtmlUnit comprend son propre interpréteur de requête, par ailleurs, avec Selenium, on peut vérifier la présence d’éléments dans le DOM, et donc tester des interactions Javascript, en particulier AJAX, alors que HtmlUnit est au niveau des requêtes HTTP.

Il y a ensuite un test d’un composant métier EJB, avec le moteur d’EJB embedabble de Glassfish (Dans la spéc. JavaEE6), sans démarrer le serveur d’application.
En dernier une démo d’un test d’un composant logique métier avec Mockito et JUnit.

Le message qui voulait être passé par ces démonstrations, est que, en fonction des développements, il faut faire des tests au niveau approprié, avec les outils appropriés.

Les retours d’expérience qui leurs semblent importants sont les suivants :

• Communiquer sur la stratégie de test à ses clients (internes ou externes);
• Concevoir des tests simples et performants;
• Décider de manière claire ce que l’on test;
• Avoir le bon niveau de test;
• Traiter votre code de tests comme un citoyen de première classe !! (documentation, qualité, performance, respect des patterns) Faites comme si vos tests allaient en production.
• Un outil : un usage;
• Les outils doivent simplifier les tests;
• Mettre en place des recommandations d’utilisation et de la documentation;
• Former des experts de référence pour ces outils;
• Entrainer les développeurs à l’usage des outils.

Les présentateurs nous ont également fait part des pistes qu’ils regardent pour intégrer de nouveaux outils à leur boite à outils :

• Tests unitaires polyglottes (Groovy ?) : L’idée serait de rendre les tests moins verbeux et partant faciliter leur maintenance;
• DSL ? Cela pourrait permettre que les analystes métiers puissent écrire leur tests.

Ils concluent en disant qu’une boite à outils (de test ou en général) de développement est extrêmement puissante, mais que cela nécessitait une maintenance régulière.

La salle était comble et le sujet et la présentation (et les présentateurs) étaient largement à la hauteur. Très bonne présentation.

Session technique : Spring Framework 3.0, Key themes and features, Jürgen Höller, SpringSource

Je pensais apprendre beaucoup de chose pendant cette conférence, des détails techniques et des annonces croustillantes. En fait Jörgen Höller s’est contenté d’introduire la manière intrusive de faire du Spring (c’est-à-dire avec des annotations, disponibles depuis Spring 2.5) et d’expliquer qu’avec Spring 3.0 (sorti en décembre dernier quand même), cela avait été amélioré, et en partie standardisé. J’ai donc passé la présentation, qui n’a pas semblé passionner grand monde non plus en dehors de moi, à rédiger les notes de la présentation précédente pour les lecteurs du Blogue.

Transition

Je prend l’avion ce soir et ne pourrai rédiger le compte-rendu des conférences de cet après-midi pour que vous l’ayez avec votre café demain matin. J’interromps donc ce billet après les sessions du matin, et vous proposerai un autre billet pour l’après-midi demain ou après-demain.

Si vous avez des commentaires, rendez-vous sur le forum