L’évolution ne s’arrête pas là et un nouveau buzzword est apparu : le web 3.0, qui serait pour certains le web sémantique. On est en effet passé d’une plate-forme de publication à une plate-forme de communication. Mais les échanges restent essentiellement entre humains. Quand vous lisez Paris, vous pensez soit à la tour Eiffel soit à une jet setteuse américaine mais vous êtes capable de faire la différence. Et vous pouvez ensuite affiner vos recherches en vous basant sur la confiance que vous accordez aux différentes sources.

Pour un agent automatisé, un robot, c’est plus compliqué. Le web sémantique décrit la stack nécessaire pour franchir le pas.

Les termes en gras désignent les technologies choisies. Sans rentrer dans les détails, la stack est loin d’être complètement opérationnelle mais les bases sont déjà utilisables. Ce qui nous intéresse maintenant est l’échange de données et plus particulièrement les microformats, un format d’échange alternatif permettant de structurer les données au sein de vos pages web.

L’intérêt est de rendre ces informations intelligibles sans intervention humaine. Cela peut donc aider votre SEO mais également permettre à vos visiteurs d’enregistrer vos coordonnées en un seul clic. Vous pouvez visualiser ces informations en utilisant Rich Snippets Testing Tools de Google. Le plugin firefox Operator permet également de détecter ces informations au sein de ce navigateur. Sur la page que vous êtes en train de lire, l’auteur, les personnes ayant laissé un commentaire et les tags sont décrits à l’aide de microformats. LinkedIn, Viadeo, Flickr ou YouTube font de même pour les profils utilisateurs.

Les cartes de visites sont surement le premier format à exploiter. Un outil de conversion peut vous aider pour vos premières réalisations.

Voici, un exemple pour Xebia :

<div class="vcard">
     <a class="url fn org" href="http://www.xebia.fr/">Xebia</a>
     <a class="email" href="mailto:info@xebia.fr">info@xebia.fr</a>
     <div class="adr">
          <div class="street-address">10/12 Avenue de L'Arche</div>
          <span class="locality">Courbevoie</span>,
          <span class="postal-code">92419</span>
          <span class="country-name">France</span>
     </div>
     <div class="tel">
          <span class="type">Work</span>+33 (0)1 53 89 99 99
     </div>
     <div class="tel">
          <span class="type">Fax</span>+33 (0)1 53 89 99 97
     </div>
     <a rel="me" class="url" href="http://fr.twitter.com/#!/XebiaFr">Twitter</a>
     <a rel="me" class="url" href="https://github.com/xebia-france">Github</a>
</div>

Les microformats sont simples d’utilisation. Avec une connaissance rudimentaire d’un langage de balisage comme le HTML, l’exemple doit être en lui-même suffisamment descriptif. Afin d’identifier les propriétés, il suffit d’ajouter une classe CSS sur les balises. La contrainte sémantique pour les hcards est que l’élément parent doit être marqué par la classe CSS vcard.

Ce bloc décrit une organisation (org) nommée (fn) Xebia et visible (url) sur son site institutionnel. Elle possède une adresse (adr) définie par la rue (street-adress), la ville (locality), le code postal (postal-code) et enfin le pays (country-name). On peut la joindre par email (email) ou encore par téléphone et fax (tel). D’autres profils sont disponibles en ligne (url), comme par exemple sur Twitter ou Github.

Une fois cet exemple assimilé et appliqué, il ne reste plus qu’à piocher dans la liste des formats, stables ou non, pour structurer d’avantage les informations que vous exposez. Il est ainsi possible par exemple de décrire des événements, la licence d’un contenu ou encore des tags.

Les microformats, par leur simplicité, constituent un premier pas vers la démocratisation du web sémantique et sont un des outils du software craftsman. Mais comme vous avez pu le constater, RDF est le format d’échange choisi pour la stack du web sémantique. Nous verrons dans un prochain article ce que RDF apporte.

NB : Le schéma de la stack du web sémantique appartient au domain publique.

À cette occasion, Jean-Luc Canela nous proposera une présentation sur specs2. specs2 est un framework de tests écrit en scala permettant d’écrire vos tests unitaires ainsi que vos tests d’acceptance (en mode BDD) avec une approche fonctionnelle.

Il reste encore des places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Quelques nouveautés…

Formations agiles

• Formations « Kanban » avec David Anderson
• Formations « Architectures Lean » avec James Coplien
• Formations « Software Craftsmanship » avec Jean-Laurent de Morlhon
• Formations « Agile for Management » avec Mac Adams
• Formations « Product Owner et User Story Mapping » toujours avec Mac Adams.

Formations techniques

• Formations « MongoDB » en partenariat avec 10Gen pour développeurs et pour administrateurs
• Formations certifiantes Cloudera pour développeurs et pour administrateurs pour Hadoop Apache
• Formations « HTML 5 » avec Seven Lemesle
• Formations « Android » avec Pascal Ognibene
• Formations « TDD » avec Simon Caplette
• Formations « DevOps pour Java » avec Cyrille Le Clerc
• Formations « Cloud Computing » toujours avec Cyrille Le Clerc.

Pour plus d’informations, n’hésitez pas à nous contacter  au 01 53 89 99 99 ou visitez notre site en suivant ce lien.

Joe a débuté sa carrière comme architecte logiciel, mais nous explique avec enthousiasme qu’il a découvert sa passion pour les interfaces utilisateur en travaillant sur des toolkits graphiques. Adepte de course automobile, il occupe aujourd’hui le poste de ses rêves : Tesla motors l’a chargé de concevoir le panneau de contrôle intérieur du futur Modèle S.

Comme on pouvait s’y attendre, sa présentation est très professionnelle, avec des diapositives minimalistes mais efficaces, qui rappellent Presentation Zen. Il s’attache surtout à définir des principes directeurs, à la façon de Don’t make me think, qu’il citera d’ailleurs comme référence.

Avant l’interface utilisateur, il faut s’intéresser à l’expérience utilisateur : peaufiner l’interface est la dernière étape. Il faut avant tout définir ce que fait le produit, comment il rend service à une personne. Le processus de design suit les étapes suivantes :

• L’expression du concept, c’est à dire du besoin métier ;
• L’architecture de l’information et la conception des interactions, qui se caractérisent par des itérations sur des prototypes de bas niveau (diagrammes de flux ou modèles en « fil de fer ») ;
• La conception visuelle, qui itère cette fois-ci sur des mockups très fidèles au rendu final ;
• Enfin, le plan de mise en production.

Le design est subjectif : il n’y a pas de réponse objectivement correcte à un problème donné. Cependant, l’interaction homme-machine repose sur quelques principes de base, qu’il faut respecter. Pour Joe, le design par comité ne marche pas : les discussions sont bénéfiques dans les phases d’itération, mais une seule personne doit prendre la décision finale. De même, il estime que le design par heuristique (mesurer les temps de réflexion, le nombre de clics…) fonctionne mais ne donne pas de bons résultats visuels (« looks assy » selon ses propres termes).

La seconde partie de la présentation est plus pratique, Joe nous livre ses « règles d’or » du design :

1. La structure des données sous-jacentes ne doivent pas influencer l’interface utilisateur. Inversement, l’interface ne doit pas non plus influencer l’implémentation. Souvent, une bonne interface évite ces problèmes grâce à une couche de transformation de données.
2. Le besoin doit primer sur la technologie. Il faut résister à la tentation de se « faire plaisir » sur la technique. Idéalement, les choix techniques doivent être repoussés le plus tard possible, une fois que le besoin est bien cerné.
3. Démarrer le processus avec de vrais cas d’utilisation. Voir comment les utilisateurs répondaient au besoin précédemment, ce qui marchait et ne marchait pas.
4. Identifier les catégories d’utilisateurs qui vont utiliser le produit. Les incarner sous forme de personnages avec un nom, une photo, qui aidera à les identifier. Envisager de leur proposer des interfaces différentes.
5. Penser en terme de flux, pas de fonctionnalités. Une interface est vivante, en mouvement. Par exemple, ne pas penser en terme d’écran de connexion, mais de processus de connexion. Ceci facilitera les retours des utilisateurs dès les premières itérations.
6. Prototyper souvent, jeter les prototypes souvent. Ne pas trop investir, construire rapidement et jeter sans regret.
7. Rendre la prochaine étape évidente. Joe nous donne l’exemple de la page principale de Google, où les boutons « Recherche » et « J’ai de la chance » sont côte à côte et ont exactement le même style. Si vous découvriez cette page pour la première fois, la différence entre ces deux boutons serait-elle évidente ?
8. Réduire le nombre d’éléments perçus. Face à un écran, le cerveau perçoit une charge cognitive, sur laquelle il se base pour estimer le travail nécessaire pour « gagner » l’écran. Il évalue dans l’ordre :
   • les formes négatives et l’esthétique, qui produisent une réponse émotionnelle ;
   • le nombre d’éléments, qui détermine la charge de travail perçue ;
   • et enfin l’emplacement du premier élément, qui déclenche l’exécution.
      Joe montre un exemple avec les mêmes champs organisés de deux manières différentes, le résultat est frappant : le premier écran, avec tous ses champs en colonne, est complètement rébarbatif ; le second, utilisant quelques regroupements et des titres de section, paraît beaucoup plus simple à remplir.
9. Utiliser la mémoire musculaire, être consistant.
10. Penser à ce qui peut être fait sans rechargement de page. Par exemple, une liste chargée progressivement en AJAX peut être plus efficace qu’une liste paginée : l’utilisateur se souviendra mieux de la position approximative d’un élément que d’un numéro exact de page.
11. Utiliser des transitions pour changer d’état. Montrer à l’utilisateur où il va, et comment revenir. Joe nous montre la page descriptive de la Tesla Modèle S, où la transition vers les sections se fait avec un défilement automatique vers le bas.
12. Itérer et raffiner, itérer et raffiner. Joe valorise les designers qui cherchent continuellement à améliorer leur produit.
13. Et avant tout, fournir une expérience de qualité à l’utilisateur. Ne pas juste « livrer cette fichue interface ».

Une présentation remarquable par la qualité de son orateur, et fourmillant de conseils utiles.

Comme annoncé, Xebia était présent pour la 3e édition du plus important rassemblement européen de la communauté Groovy : la GR8Conf de Copenhague (prononcez « Great Conf »). Pour tous ceux qui auraient voulu y être et n’ont pas pu, je vais tenter de vous résumer les sessions auxquelles j’ai assisté et vous donner la tendance du clan Groovy (en Europe tout du moins). Commençons par quelques chiffres :

• 3 jours
• 25 speakers
• plus de 100 participants
• 4 workshops
• 28 sessions
• 2421305344 octets de technologie Groovy sur clé USB (dans le pack de bienvenue)

La conférence s’est tenue dans les locaux de la IT University of Copenhagen, qui a prêté un amphithéâtre et une grande salle de cours pour l’occasion.

Toutes les sessions ont été filmées (je vous donnerai les liens dès qu’ils seront publiés). Je n’ai malheureusement pas pu assister à la première journée : « l’université ». Ce premier jour, les participants ont eu droit à une mise à niveau sur le langage Groovy et le framework Grails, puis ont enchaîné une après-midi de code pour apporter des contributions à certains projets open-source. Certaines features codées pendant ces workshops ont même été intégrées le soir même et utilisées pour les démonstrations des 2 jours de conférence qui ont suivis.

Groovy update

Après un rapide accueil de Søren Berg Glasius, la première journée de conférence commence par un retour sur les dernières nouveautés du langage Groovy, par Guillaume Laforge. Il ouvre la session avec quelques statistiques sur Groovy 1.7 :

• 185 000 téléchargements le premier mois suivant la sortie,
• 177 000 pour le 2e mois,
• une communauté de développeurs estimée à 362 000 (sans doute sous estimée puisque les téléchargements via le repository maven ne sont pas monitorés).

Puis il enchaîne en revenant en détail sur les principales nouveautés de Groovy 1.8 :

• command chain expression : pour des DSL plus proches du langage naturel. À utiliser avec rigueur pour ne pas se perdre entre ce qu’on passe comme paramètre et l’appel de la méthode suivante,
• GPars fait maintenant partie du core de Groovy, ce qui offre de façon directe actors, fork-join, dataflow et autres joyeusetés,
• Le support de JSON par défaut dans le langage.

Il y a également beaucoup d’annotations très pratiques comme @Log, @Singleton, @WithReadLock, @WithWriteLock. Pour le détail complet, rendez vous sur Slideshare.

Enfin, une perspective sur les chantiers prévus pour la prochaine version majeure :

• Utilisation de InvokeDynamic du JDK7,
• Amélioration de la modularité de Groovy pour permettre de n’embarquer que les modules utiles,
• Réécriture de la grammaire antlr3, prévue pendant le prochain Google Summer of Code,
• Remplacement du compilateur Joint par celui d’Eclipse,
• Multicatch (IOException | NullPointer e),
• et d’autres apports de syntaxe, comme l’intégration du projet Coin et le support des séparateurs pour améliorer la lisibilité des grands nombres.

Grails update

Dans la foulée des nouvelles, Peter Ledbrook nous a dressé le bilan de la branche 1.3 de Grails, avant de faire miroiter à l’auditoire les nouveautés qui se préparent pour la version 1.4. L’année écoulée a été celle de la version 1.3, avec énormément de nouveaux plugins, notamment pour fournir à l’abstraction GORM des implémentations sur NoSQL (comme Redis, MongoDB, Riak, Neo4j et d’autres). Il a également cité quelques gros comptes utilisant Grails comme framework de premier ordre dans leurs projets, comme Vodafone Music, par exemple.

La version 1.4 de Grails donne vraiment envie. Parmi les nombreuses améliorations attendues, on peut noter :

• Groovy 1.8,
• Mise à jour de Spring vers la 3.1,
• Mise à jour de Hibernate vers la 3.6,
• L’utilisation de Tomcat 7 en mode développement,
• Baptême de JQuery comme librairie Javascript de base,
• Améliorations des templates par défaut lors de génération de pages GSP, appliquant les bonnes pratiques HTML5.

Le but premier de cette version est d’améliorer encore l’expérience utilisateur (c’est à dire celle des développeurs). Ceux qui l’ont essayé peuvent en témoigner : Grails est déjà un framework très agréable. Espérons qu’ils arrivent à faire encore mieux. Il y aura également un système de feedbacks pour que, si les développeurs l’acceptent, leur installation de Grails puisse remonter chez SpringSource des données sur la version utilisée, les plugins installés, etc. Ces statistiques devraient permettre d’y voir plus clair dans le portail de plugins (qui a passé les 600 plugins), et ainsi connaître ceux qui servent et ceux qui dorment.

Adopter Grails

Après cela, Klaus Baumecker, architecte chez HP, est venu nous parler de l’adoption de Grails dans une équipe de développement interne.
Le cadre du projet :

• 2 équipes qui développent la prochaine version d’un produit, l’une en Grails, l’autre en J2EE standard,
• Modèle de données commun géré par Hibernate,
• Approche agile (SCRUM-like),
• Frontal Flex.

Le speaker nous a énuméré les principaux obstacles techniques qui se sont dressés sur la route, notamment l’intégration de BlazeDS, qui s’est révélée moins triviale qu’au premier coup d’œil. Mais chaque obstacle a trouvé sa solution et le projet a été une réussite. Il a terminé en résumant l’expérience tirée sous forme de bonnes pratiques pour l’adoption de Grails :

• Parlez des bénéfices techniques du framework, pas seulement des « cool stuff ». Il a notamment insisté sur la flexibilité de Grails, qui a permis de contourner rapidement beaucoup de contraintes techniques,
• Ne soyez pas trop enthousiaste : ça peut donner un aspect « fanboy » à votre argumentaire, là où vous voudriez être pris au sérieux,
• Créez une communauté locale, en convaincant en premier lieu vos collègues avant d’aller voir vos responsables,
• Appuyez vous sur la communauté Grails et aidez les gens autour de vous grâce à elle : se référer aux mailing lists, forums, IRC et autres blogs permet de fournir des points d’entrée utiles sur le long terme aux débutants,
• Apportez vos outils : parlez des plugins, des outils d’analyse statique, des IDE,
• Trouvez des situations dans lesquelles Grails fait une vrai différence : notamment quand on compare un ‘grails run-app’ par rapport à un redéploiement d’application classique,
• Restez dans la zone de confort du framework : même si le framework est flexible, rester dans les conventions permet aux débutants de s’y retrouver plus facilement en se référant aux ressources du web,
• Soyez disponible : si vous tentez d’introduire Grails, c’est surement que vous avez un peu plus de connaissance que le reste de votre équipe. Apportez votre aide autant que possible, proposez de faire des revues de code, du pair programming, tout pour accompagner vos collègues sur le chemin de la lumière.

Je ne saurais trop vous conseiller d’appliquer ces conseils pour tenter d’implanter Grails dans vos projets.

Grails en entreprise

Peter Ledbrook a assuré une 2e session sur l’intégration de Grails dans le monde de l’entreprise, plus précisément dans les processus de développement logiciel déjà en place. Il a débuté en nous parlant des 2 outils de build les plus implantés dans l’écosystème Java : Ant et Maven. Pour pouvoir dire que Grails s’intègre correctement à l’existant, il est indispensable de pouvoir construire un projet Grails avec ces 2 outils.

Pour Ant, le problème est assez simple, dans la mesure où le système de build propre à Grails est Gant, c’est à dire Ant, manipulé grâce à Groovy. Une commande Grails permet de générer build.xml et ivy.xml : grails integrate-with --ant. De cette façon, on peut construire son projet directement avec Ant.

Pour Maven, des plugins existent pour brancher les scripts Grails dans les phases d’un build Maven standard. Cependant, l’intégration avec Maven pose plus de problèmes. De base Grails gère ses dépendances grâce à Ivy, alors que Maven le fait lui même. De plus, le côté rigide d’un build Maven provoque des frictions avec celui, très flexible, des build Gant. Si vous pouvez vous le permettre, utilisez Gant et les conventions Grails.

À noter que pour la roadmap Grails 2.0, il est prévu de passer à Gradle, tout en conservant et améliorant les intégration Ant et Maven.

Peter a également axé une partie de sa présentation sur l’adaptabilité d’une application Grails à une base de données existante. Il est tout à fait possible de reprendre une base de données existante, par plusieurs stratégies:

• utilisation directe de fichiers de mapping Hibernate existant
• mapping fin (table, colonnes, clé primaire, …) d’entités définies dans l’application
• mixer les deux en fonction des besoins

Pour finir, il nous a parlé de déploiement. les mécanismes de customisation du contenu du war permettent de satisfaire toutes les fantaisies des différents serveurs d’application. Pour la production, il conseille fortement de s’appuyer sur les datasources JNDI et sur les mécanismes permettant d’externaliser la configuration (voir ce tips).

Puis il a terminé son exposé par quelques conseils d’ordre général sur les projets Grails :

• N’oubliez pas que Grails, c’est du Spring. Par conséquent, on bénéficie de tous les connecteurs du monde Spring, notamment JMS, ESB, AMQP, etc.
• Utilisez le plugin app-info, qui vous donnera des vues sur les entrailles de votre application. De la configuration de la datasource à l’utilisation mémoire en live.
• Réutilisez vos classes de domaines au maximum. Si une classe de domaine peut servir à plusieurs applications, mettez la dans un plugin et utilisez le.

La somme de toutes ces pistes et de tous ces conseils, c’est que Grails est intégrable à, virtuellement, tous les processus de développement logiciel en place. Il faut se donner un peu de peine, mais les outils sont là pour vous faciliter la tâche (à l’extrême).

CodeNarc & GMetrics

Tandis que se tenait la session de mise à niveau sur Griffon, j’ai assisté à une présentation de Hubert Klein Ikkink alias MrHaKi, l’auteur de billets Groovy Goodness sur son blog, véritable mine d’or de trucs et astuces techniques.

Il est venu parler de CodeNarc et de GMetrics, 2 outils d’analyse statique de code Groovy. Le premier permet de détecter les mauvaises pratiques d’utilisation du langage, comme des appels explicites là où Groovy ferait implicitement le travail. Au total,174 autres règles sont fournies. Quant à GMetrics, son domaine concerne le calcul de la complexité cyclomatique de votre code.

CodeNarc a été cité dans beaucoup d’autres sessions pendant la GR8Conf, voici ce qu’il faut en retenir :

• Utilisez le !
• Configurez le pour coller à vos bonnes pratiques maisons.
• Ecrivez vos propres règles, et si elles sont génériques, reversez les au projet.

Pour les détails techniques, je vous encourage à vous pencher sur les documentations respectives de CodeNarc et GMetrics.

Grails Application Tuning

Voilà l’une des sessions pour lesquelles j’ai eu envie de faire le déplacement jusqu’au Danemark… Je n’ai pas été déçu. En une heure, Peter Ledbrook, dans sa 3ème prestation de la journée, a peiné à faire tenir tous les conseils sur l’optimisation en Grails. La plupart des aspect d’optimisation sont d’ailleurs communs à toute application web Java.

Premier conseil à graver au dessus de votre écran :

Evitez toute optimisation prématurée : Profilez, optimisez, répétez.

Grails est basé sur une stack très classique, donc tous les outils de profiling fonctionnent.

Outils côté serveur

Voici quelques outils pour profilez le fonctionnement de votre application côté serveur :

• Spring Insight : avec STS, vous pouvez démarrer votre application Grails dans un tcServer et bénéficier de l’analyse live de chaque requête sur votre application.
• Le plugin profiler : qui facilite la collecte de temps d’exécution sur votre code.
• Le plugin p6spy : installe un proxy JDBC qui vous donnera la détail de toutes les requêtes en base.
• Les plugins app-info et hibernate-stats : qui vous donneront beaucoup d’informations sur les fonctionnements internes de votre application.

Tout cela devrait vous permettre de trouver plus rapidement les goulots d’étranglement dans votre code.

En vrac, voici un ensemble de pistes exploitables pour optimiser vos application Grails (ou autre d’ailleurs).

Outils navigateurs

• Google Spring Tracer, qui peut également s’intégrer à Spring Insight.
• YSlow, il nécessite Firebug donc l’utilisation de Firefox, mais il est très pratique.

Performance base de données

• Réduire le nombre de requête
• Analyser les requêtes et ajouter les index utiles
• Optimiser vos requêtes, notamment en utilisant des requêtes Criteria nommées.
• Faire attention aux stratégies de fetching
• N’hésitez pas à changer le modèle pour gagner en performance de requêtage.
• Dans certains cas, le chargement Eager peut être avantageux, n’hésitez pas à vous en servir (à bon escient).
• Utiliser un cache, surtout dans le cas où il y a plus de lecture que d’écriture. Pour info, Ehcache est disponible dans la stack Grails.

Performance sur les traitements métier

• Cachez les appels de méthodes de service idempotentes avec le plugin Springcache.
• Faites de l’asynchrone partout où c’est possible, par exemple en utilisant le plugin Spring Events.
• Utilisez le plugin Routing pour le messaging
• Utilisez Groovy++ pour vous affranchir du surcoût du dynamisme de Groovy quand c’est possible.
• Pour les tâches qui font beaucoup de calcul numérique, préférez le Java pur.

Optimisation réseau et navigateur web

• Utiliser les capacités de caching de contenu du plugin Springcache partout où c’est possible, pour éviter de recalculer les pages qui ne changent pas souvent.
• Définissez correctement vos header HTTP Expires.
• Packager vos css et votre javascript, un fichier unique pour chaque permet de diminuer le nombre de requête.
• Utiliser le spriting CSS plutôt que de multiples images.
• Minifier votre Javascript.
• Compresser vos données.

L’utilisation du plugin resources permet d’automatiser beaucoup de choses. Ce plugin très prometteur fera partie intégrante de Grails dès la version 1.4. Il permet notamment :

• de modulariser les ressources statiques.
• de les packager par type.
• définir les header HTTP Expires et de changer le nom des packages de ressources en cas de modification, ce qui forcera le rechargement par les navigateurs.
• de placer le Javascript toujours en bas de page pour un chargement plus rapide des éléments visuels.

Ciblez en priorité les victoires faciles. Il faut bien faire attention de ne pas investir trop de temps sur une petite optimisation. On ne vise pas les économies de bouts de chandelle. Une session très chargée et très intéressante. Peter a revendiqué le droit à une sieste après ce 3ème slot de la journée.

Effective Groovy

Pour clore la journée, Hamlet D’Arcy a présenté ses conseils pour être efficace dans l’usage du langage Groovy. Sa session était organisée autour d’une sélection de conseils tirés du livre culte Effective Java et appliqué au monde Groovy. Le speaker est à l’aise et captive son auditoire. Certaines vagues sur Twitter pendant sa présentation ont émis l’idée d’écrire un livre « Effective Groovy ». Parmi les conseils les plus utiles, vous pouvez noter :

• Utilisez Codenarc : pour détecter les erreurs les plus courantes, mais aussi pour écrire vos propres règles et les faire respecter au sein de votre équipe.
• Dans le cas où vous avez des appels de constructeurs avec un grand nombre de paramètres, utilisez des arguments nommés pour garder un code lisible.
• Utiliser GPars pour toute programmation conccurente.
• Apprendre à utilise Grab pour gérer les dépendances Groovy de ses scripts.

Les conseils prodigués ont tous été très bien justifiés mais il faudrait un article entier pour tout restranscrire ici. La racine commune à toutes ces bonnes pratiques est : utiliser le langage. Cela peut paraître simpliste mais c’est très vrai. Toute cette présentation ciblait les pratiques héritées du langage Java pur. Groovy, et à plus fort titre avec la version 1.8, fourni de nombreuses syntaxes et annotations permettant de gagner beaucoup de temps et de rendre le code plus lisible. Il faut s’en servir, à fond.

• Les slides complet ici.

Conclusion de la première journée : Meet & Greet

Après cette journée bien remplie, tous les participants, speakers et spectateurs, se sont retrouvés autour de bières belges et danoises aux couleurs de la conférence. Ce temps de détente a été l’occasion de discuter des outils, de l’adoption de Groovy dans les entreprises de chacun, de la qualité de la bière danoise… Certains ont même réussi à coincer Peter Ledbrook dans un coin pour une séance de pair programming sur un bug dans le plugin Maven pour Grails. Pendant ce temps d’échange, j’ai eu le plaisir de faire la connaissance de Franck Silvestre, qui participe à la réalisation de l’un des plus gros projet Grails en France : Lilie. C’est un projet destiné au secteur de l’enseignement et sous licence open-source, à voir absolument.

Deuxième journée, rester motivé : Grails Infinispan plugin

Après quelques agapes entre participants la veille, la 2ème journée démarre sur les chapeaux de roues, avec un exposé sur le plugin Grails pour Infinispan, la grille de données estampillée JBoss. Thomas Fuller nous présente des cas d’utilisation qui peuvent pousser à se servir d’une datagrid et quels gains on peut en retirer. Puis il fait le tour du plugin Grails pour s’interfacer avec Infinispan. Les exemples de code donnés sont d’une simplicité à toute épreuve, l’architecture de plugin de Grails est exploité à fond pour le confort du développeur.

Bien évidemment, ce n’est pas n’importe quel projet qui peut avoir besoin d’une datagrid, mais il est bon de savoir que des plugins existent déjà et sont utilisés et maintenus. Je regrette un peu trop de temps passé sur la première partie et la justification de l’utilité d’Infinispan. Le sujet était intéressant et j’aurais aimé voir plus de code que le strict minimum.

Groovy 1.8 Performance Improvements

Ensuite, Jochen Theodorou, alias Blackdrag vient nous parler des optimisations de performances apportées par la version 1.8 de Groovy. Il semble que les gens de chez SpringSource en ai assez de se faire ridiculiser dans les micro benchmarks qu’on peut trouver sur le net. Ils ont donc placé leur effort sur la satisfaction des fétichistes du micro-bench.

Le plupart des micro-bench Groovy contre Java qu’on peut trouver sont basés sur des calculs arithmétiques, comme le célèbre calcul de la suite de Fibonacci. Mais Groovy est un langage dynamique, par conséquent, toutes les opérations mathématiques sont en fait des appels de fonction, ce qui fait l’impasse sur les capacités de la JVM en calcul sur primitives. Les améliorations de performances de la 1.8 sont restreintes aux calculs sur entier et sont encore assez fragiles. Vous n’en profiterez que si vous travaillez sur des entiers sans mélanger les types d’opérations. Si vous lancer un a = b c d, vous êtes dans la zone verte. Si vous lancez a = b + c – d, vous êtes dans la zone rouge.

Pour les prochaines versions de Groovy, Springsource mettra l’accent sur la stabilisation et la généralisation de ces améliorations. A plus long terme, il est prévu de s’appuyer sur le InvokeDynamic fourni par le JDK7.

Les 2 conseils à retenir :

• Pour du calcul mathématique, préférez le Java pur
• Ne faites pas de micro benchmarks, préférez le prototypage d’application. Il est important de mettre tous les facteurs dans la balance : Confort et rapidité de développment, expérience développeur, statisfaction sur le produit fini.

GORM Optimisations

Burt Beckwith est venu nous parlé des différentes techniques pour optimiser GORM. Il est également auteur des billets « GORM Gotchas » sur le blog de Springsource, à lire absolument pour éviter certains pièges.

Parmi les techniques intéressantes je retiens :

• L’utilisation de classes de domaine avec mapping fin pour pointer sur des vues en base.
• D’une façon générale, il ne faut pas hésiter à utiliser des classes de domaines contenant en attribut un sous-ensemble des colonnes de la table requêtée. De cette façon, on s’assure de ne remonter ou de mettre à jour que les données utiles.
• Définir finement ses mappings dans les classes de domaines permet de customiser au mieux le schéma de la base de données.

De nombreux exemples de cas d’application ont été passés en revue. Une session très intéressante.

Grails Webflow

Pour clore la matinée, Ivo Houbrechts nous a parlé du plugin Grails WebFlow. Il a commencé par une petite démonstration (avec Grails 1.4 SNAPSHOT, derniers commit de la veille au soir). Comme son nom l’indique, ce plugin intègre Spring WebFlow à Grails. Il permet notamment d’obtenir sans effort :

• un flow de formulaire, ce qui encourage le découpage en formulaires simples plutôt qu’un unique formulaire énorme.
• un fil d’ariane des étapes déjà effectuée, très pratique.
• la gestion de la double soumission en cas d’utilisation du bouton ‘Back’ du navigateur

Quelques limitations par rapport à Spring WebFlow :

• l’héritage de flow n’est pas supporté
• les transisition globales non plus

La DSL de configuration est simple au départ mais peu vite devenir illisible si vous tentez des flow complexes (surtout si vous passez beaucoup de closures en paramètre). Restez autant que possible dans des cas flow simples pour éviter cela.

Grails and Neo4J

La dernière session que j’ai pu suivre a eu pour sujet le plugin Neo4J pour Grails. Stefan Armbruster a commencé par nous rappeler les bénéfices du paysage NoSQL parmi les options de stockage de données. Puis nous a expliqué de quelle façon GORM appliquait le mapping des classes de domaines à une base de données orientée graphes.

Le gros avantage de ce plugin est de s’intégrer de façon transparente avec GORM, ce qui ne rajoute aucune complexité et permet même de tester les résultats d’un remplacement de votre base par Neo4J sans effort. Pour les enthousiastes, faites bien attention à la licence de Neo4J avant de la faire adopter chez vous.

Conclusion

J’ai ensuite dû courir à l’aéroport pour rentrer au pays, en ratant les 2 dernières sessions de la journée. Ces deux journées ont été très riches en enseignement technique mais aussi humain. C’était pour moi une première immersion dans la communauté Groovy et j’en suis revenu convaincu par le langage, les librairies, les outils et la communauté. Il me paraît opportun de conclure en citant les « idées GR8Conf à emporter » (« GR8conf takeaway »), twittées par Dierk König le dernier jour :

• Groovy est une place d’innovation
• L’outillage Groovy est mature et activement maintenu par des équipes compétentes
• Groovy est mainstream, avec un nombre de téléchargement comparable à Spring
• La communauté Groovy est accueillante
• La communauté Groovy a une attitude orientée « Getting things done » (prouvée par le Hackgarten)

Je ne peux que tomber d’accord. Un grand merci aux courageux qui ont lu jusqu’à la fin. Groovy rocks !

• Dernière minute : les slides de toutes les conférences sont maintenant disponibles sur SlideShare.

C’est à ce titre que j’interviendrai le Mardi 24 Mai lors d’une présentation sur la dette technique. Le but sera de sensibiliser les futurs diplômés aux conséquences d’une dette non gérée sur les projets logiciels. Nous étudierons notamment les mécanismes de la dette et des bonnes pratiques pour la résorber.

Souhaitant montrer ce qu’il est possible de réaliser avec ce framework, je ferai une présentation jeudi 19 mai à 19h au Bordeaux JUG titrée « Les moteurs de recherche pour l’entreprise ».

Le but est d’y présenter quelques concepts théoriques suivi d’un tour d’horizon des possibilités offertes par Lucene et des indexes de recherche en général : gestion des fautes de frappe, moteurs de recherche conscients du métier, pondération statique et dynamique des résultats, faceted search, ou encore obtention des documents similaires. Le propos sera ensuite élargi vers les solutions disponibles pour mettre en oeuvre Lucene dans un environnement distribué : Solr, ElasticSearch, Hibernate Search, …

Des places sont encore disponibles, donc si vous êtes dans la région de Bordeaux ce jeudi, n’hésitez pas à nous rejoindre !

• Réponse 1 : Comment des éditeurs commerciaux peuvent-ils distribuer des programmes « close source » pour Linux alors que Linux utilise la licence « business unfriendly » GPL qui est censée être « contaminante » ?
• Réponse 2 : Comment CentOS peut-il distribuer gratuitement une version de Linux qui reprend quasiment toute la distribution payante Red Hat Enterprise Linux ?
• Réponse 3 : Pourquoi ai-je le droit de distribuer un logiciel « close source » qui embarque une JVM OpenJDK alors que celle-ci utilise la licence « contaminante » dérivée de la GPL ? Ai-je ce droit sur toutes les plateformes ? Y compris sur les terminaux mobiles ?
• Réponse 4 : L’Affero General Public License (aka Affero GPL) étend la notion de distribution de la licence GPL à la distribution sur le réseau. Quel est l’impact sur des sites web accessibles sur Internet ? Citer une librairie Java très connue licenciée sous AGPL ? Utilisez-vous iText ?

Comment des éditeurs commerciaux peuvent-ils distribuer des programmes « close source » pour Linux alors que Linux utilise la licence « business unfriendly » GPL qui est censée être « contaminante » ?

L’essentiel du code source de Linux est distribué sous la licence business unfriendly GPL qui est contaminante et requiert donc que le code qui lui est linké soit distribué sous une licence compatible GPL avec le code source disponible.

Cependant, pour s’exécuter sur Linux, un programme n’a pas besoin d’être compilé et/ou linké à ce code contaminant ; il lui suffit d’être compilé et linké sur les API POSIX / « Portable Operating System Interface for Unix » (e.g. cpio.h) qui ont une licence non contaminante BSD (en plus de licences LGPL et GPL) ou sur des librairies aux licences non contaminantes comme glibc (licence LGPL). Quant au compilateur GCC, il ne contamine pas non plus avec sa GCC Runtime Library Exception.

Comment CentOS peut-il distribuer gratuitement une version de Linux qui reprend quasiment toute la distribution payante Red Hat Enterprise Linux ?

Comme Noel Rocher (Red Hat / JBoss) nous l’a expliqué, Red Hat tient à disposition de ses clients RHEL le code source de l’OS ; c’est conforme à la licence GPL de Linux. En revanche, les logos et les termes Red Hat, RHEL, etc sont sous copyright Red Hat.

Il suffit aux membres du projet CentOS d’acheter une licence RHEL, de demander le source et de faire disparaitre les logos et termes copyrightés (RHEL, Red Hat, etc) pour constituer une version qu’ils ont le droit de distribuer gratuitement.

Il est donc possible d’obtenir une quasi-RHEL gratuitement mais on perd alors le support et les services que Red Hat propose à ses clients.

Pourquoi ai-je le droit de distribuer un logiciel « close source » qui embarque une JVM OpenJDK alors que celle-ci utilise la licence « contaminante » dérivée de la GPL ? Ai-je ce droit sur toutes les plateformes ? Y compris sur les terminaux mobiles ?

La JVM OpenJDK est disponible sous GNU General Public License, version 2, with the Classpath Exception. Le classpath exception protège le code qui s’exécute sur la JVM de la contamination habituelle des licences GPL. Une application peut donc être livrée avec une JVM OpenJDK sans être contaminée et donc sans devoir rendre son code source disponible sous licence compatible GPL.

Cela ressemble presque plus à une licence LGPL qu’à une licence GPL.

Pour ce qui est du monde mobile, Oracle (à l’époque Sun) n’a pas posé de classpath exception à la JVM ME (aka Mobile Edition). De ce fait, une application qui embarque une JVM ME open source d’Oracle est contaminée et doit proposer son code source sous licence compatible GPL. Cette disposition a incité les fabricants de téléphones mobiles et systèmes embarqués qui utilisaient Java ME à continuer à utiliser des JVM ME commerciale.

En revanche, rien n’interdit de bénéficier de la classpath exception en utilisant un Open JDK sur téléphone mobile ou tout autre embedded device. Le OpenJDK : Zero – Assembler Project travaille justement à porter OpenJDK sur les processeurs ARM qui sont communément utilisés dans les smartphones.

L’Affero General Public License (aka Affero GPL) étend la notion de distribution de la licence GPL à la distribution sur le réseau. Quel est l’impact sur des sites web accessibles sur Internet ? Citer une librairie Java très connue licenciée sous AGPL ? Utilisez-vous iText ?

L’Affero General Public License a été introduite en complément de la GPL pour combler l’oubli des Application Service Providers.

Cette licence stipule que la distribution ne se limite pas à la forme de binaires comme le définit la licence GPL mais concerne aussi la fourniture en mode service de ce logiciel au travers d’un réseau.

De ce fait, exposer un logiciel à des clients sous forme de services web relève d’une distribution aux yeux de l’Affero GPL. Par conséquent, une application web visible sur internet qui embarque une librairie Affero GPL est contaminée et doit rendre tout son code source disponible sous licence compatible AGPL !

Avis aux utilisateurs d’iText : la librairie est passée en dual licensing Affero GPL / commercial depuis la version 5. Si vous voulez continuer à bénéficier de la business friendly Mozilla Public License, il faut rester sur la version 2.1.7 d’iText (merci à Bertrand Dechoux pour l’historique).

Du 17 au 19 mai se tiendra à Copenhague la grand-messe des technologies Groovy en Europe : la GR8Conf. Xebia France y sera pour couvrir l’évènement.

Parmi les sujets abordés :

• Groovy : à tout seigneur, tout honneur
• Grails : et notamment son adoption en entreprise
• Gradle : l’outil de build qui monte
• Gaelyk : la boite à outil Groovy pour Google AppEngine
• Griffon : le framework inspiré de Grails pour les applications de bureau
• GPars : la librairie Groovy orientée concurrence, Actors, fork-join, etc

De nombreux speakers seront présents, notamment Guillaume Laforge, Burt Beckwith, Dierk König, et bien d’autres. Comme toujours dans ces grosses conférences, il faudra choisir entre des sessions en parallèle, mais nous essaierons de vous informer sur les plus intéressantes, pour dresser l’état de l’art et le futur des technologies Groovy en 2011.

Les 3 jours de conférence se découpent en :

• une journée « University », où les participants pourront réviser les bases du Groovy, de Grails et coder comme des fous au HackerGarten.
• 2 jours de conférence plus « classique » avec différents acteurs du monde Groovy

Vous trouverez le programme complet ici.

La journée a commencé par un jeu intitulé « Questions pour un Xebian » organisé par Cyrille Le Clerc et Jean-Laurent de Morlhon où il a été question de reconnaître ce que cachent plusieurs noms de technologies en vogue (sass, haml, hateoas, etc).

Nous avons ensuite poursuivi avec deux sessions en parallèle :

• Algorithme Min / Max et Tournoi de Puissance 4, animé par Morgan Renou
  L’objectif de cette session était de présenter l’algorithme MiniMax avec un élagage Alpha-Béta afin de développer de petites intelligences artificielles s’affrontant dans un tournoi puissance 4.
• Mule ESB, animé par Jean-Louis Rigau
  Après avoir expliqué les principes fondamentaux de Mule ESB, cette session a permis de détailler, étape par étape, la mise en place d’une boutique en ligne, axée sur les traitements back-office.

Après le déjeuner, deux nouvelles sessions en parallèle :

• Hands On JMS, animé par Guillaume Arnaud
  Après une présentation des concepts importants de l’API JMS, nous avons vu sa mise en place (connexion à un broker, émission et réception de messages sur des queues et topics durables / non durables).
• nexTep Designer, animé par nexTep
  Cette session a permis de présenter l’environnement de développement nexTep Designer.

Pour clore la journée, une nouvelle fois deux sessions en parallèles :

• Grails from Scratch, animé par Aurélien Maury
  Le framework Grails fut présenté dans ses grandes lignes (origines, concepts et fonctionnement) avant de poursuivre sur la réalisation d’un mini plugin Grails en Hands-On pour afficher les derniers tweets d’une recherche via une taglib.
• Flex 4, animé par Ellène Dijoux
  Après une présentation de Flex 4, nous avons réalisé une application de gestion des tâches. Le but était de faire le tour des nouveautés avec la librairie Spark, l’utilisation du skinning (habillage des composants) et la gestion des évènements et manipulation du XML. Le slot était accessible à tous et a permis d’introduire les notions de base que l’on peut retrouver dans Flex.

Quizz « licences Open Source »

Cette journée fut aussi l’occasion d’un tour d’horizon des licences Open Source (business friendly, business unfriendly, contaminantes, virales, etc) présenté par Cyrille Le Clerc. Nous vous proposons les points amusants sous forme de jeu :

• Comment des éditeurs commerciaux peuvent-ils distribuer des programmes « close source » pour Linux alors que Linux utilise la licence « business unfriendly » GPL qui est censée être « contaminante » ?
• Comment CentOS peut-il distribuer gratuitement une version de Linux qui reprend quasiment toute la distribution payante Red Hat Enterprise Linux ?
• Pourquoi ai-je le droit de distribuer un logiciel « close source » qui embarque une JVM OpenJDK alors que celle-ci utilise la licence « contaminante » dérivée le la GPL ? Ai-je ce droit sur toutes les plateformes ? Y compris sur les treminaux mobiles ?
• L’Affero Ceneral Public License (aka Affero GPL) étend la notion de distribution de la licence GPL à la distribution sur le réseau. Quel est l’impact sur des sites web accessibles sur Internet ? Citer une librairie Java très connue licensiée sous AGPL ? Utilisez-vous iText ?

Si ces questions suscitent votre curiosité, n’hésitez pas à répondre sous forme de commentaires dans ce billet. Nous publierons nos réponses d’ici la fin de la semaine .

Le mécanisme de validation de Grails est basé sur l’API Spring Validator. Il existe dans Grails un ensemble de validateurs permettant de couvrir la plupart des besoins simples, tels que champs obligatoires, taille mini/maxi, valeurs min/max pour les nombres, etc. Cependant, il arrive souvent d’avoir besoin de validateurs sur mesure, plus adaptés au métier de l’application. Aujourd’hui nous allons voir les différentes méthodes de validation avancées des classes du domaine qui s’offrent aux utilisateurs de ce framework web magique :

• Retour sur la contrainte validator
• Faire une contrainte réutilisable
• Le plugin Constraints

Suivez le guide…

Validation sur mesure

Il existe 16 contraintes applicables sur les attributs des classes de domaine dans une application Grails. Ces contraintes permettent de s’assurer de la validité du contenu de nos entités avant de les envoyer en base. Elles vont de la vérification de la nullité, de la taille d’une chaîne, à la correspondance à une expression régulière, et j’en passe.

Mais parfois, il est indispensable de valider nos attributs en fonction de critères plus fins, ou liés à des logiques métiers complexes. C’est alors que la 17ème contrainte livrée avec Grails peut servir : validator.

Grâce à cette contrainte, on peut glisser une closure qui sera exécutée lors de la validation de l’entité. Voici la page de la documentation officielle qui détaille son utilisation. Pour ceux qui n’ont pas le temps d’aller lire la documentation voilà un exemple assez parlant :

class User {
  String login
  String autreChamp
  static constraints = {
    login(validator: { val, obj ->
      return (val.length != 0 && obj.properties['autreChamp'] != 'magicString')
    })
  }
}

Dans cet exemple, si la contrainte n’est pas respectée, alors le message d’erreur associé sera, par convention : user.login.validator.invalid.

Ce mécanisme est très pratique et flexible, mais oblige à dupliquer du code si on souhaite utiliser la même contrainte complexe sur plusieurs classes de domaine. Poussons plus loin l’investigation.

Faire mieux, à la main

Il est possible d’écrire ses propres classes de contrainte et de les réutiliser plusieurs fois. Cet article décrit très bien la méthode à suivre. Je vais vous en tracer les grandes lignes ici, en français dans le texte.

Pour écrire un validateur réutilisable, il suffit d’étendre la classe AbstractConstraint et d’implémenter la méthode processValidate. En voici un exemple :

package myapp
import org.codehaus.groovy.grails.validation.AbstractConstraint
import org.springframework.validation.Errors
class LowerCaseConstraint extends AbstractConstraint {
// nom à utiliser dans les classes de domaine
    static NAME = 'lowerCase'
    String getName() {
        NAME
    }
// si le validateur ne s'applique qu'à certaines classes, cette méthode permet de filtrer l'application de la contrainte
    boolean supports(Class type) {
        true
    }
// code de la logique de validation
    protected void processValidate(Object target, Object value, Errors errors) {
        if (constraintParameter && value =~ /[A-Z]/)
            rejectValue target, errors, "default.invalid.${name}.message", "${name}.invalid",
                [constraintPropertyName, constraintOwningClass, value] as Object[]
    }
}

La place idéale dans votre arborescence projet pour cette classe se trouve dans le répertoire src/groovy. Une fois votre classe de contrainte terminée, il faut l’enregistrer auprès du framework pour que Grails sache où la retrouver. Pour ce faire, ajoutez cette ligne dans votre fichier grails-app/conf/Config.groovy :

org.codehaus.groovy.grails.validation.ConstrainedProperty.registerNewConstraint myapp.LowerCaseConstraint.NAME, myapp.LowerCaseConstraint.class

Il ne reste plus qu’à vous en servir dans vos classes de domaine :

static constraints = {
    myProperty size: 1..20, lowerCase: true
}

Le plugin existe déjà : Constraints Plugin

Mais comme souvent quand on parle de Grails : il y a un plugin pour ça ! Le plugin Constraints fourni des scripts pour générer des classes de contraintes réutilisables. En deux lignes de commandes, le tour est joué, installation et création de contrainte :

grails install-plugin constraints
grails create-constraint my.package.ContrainteSurMesure

Dans la classe générée, il ne vous restera plus qu’à coder une closure de validation, comme on l’aurait fait dans la première solution. Un grand merci à Geoff Lane qui s’est donné la peine de coder ce plugin. Il est possible de configurer certains comportements de ce plugin, mais je vous laisse consulter la documentation pour découvrir dans quelle mesure.

Conclusion

L’usage du plugin Constraint est très simple et permet beaucoup de choses. N’hésitez pas à vous en servir. Je vous encourage également à exploiter au maximum la formidable extensibilité de Grails. Pourquoi ne pas coder vos validateurs dans un nouveau plugin qui s’appuiera sur le plugin Constraints ? Ainsi vous disposerez d’un paquetage de validateur sur mesure, à installer en claquant des doigts dans tout nouveau projet Grails démarrant chez vous.

What else ?

Cette journée fut dédiée au développement mobile. Après un échange sur l’actualité, 4 groupes se sont formés autour de thèmes forts :

• Android, animé par Steve Klouvi
• Iphone, animé par Amin Fathallah
• Flex Mobile, animé par Julien Buret
• JQuery Mobile, animé par Alexis Kinsella

Suite à une brève introduction aux différentes technologies challengées, les xebians ont développé une application mobile en Pair Programming à l’aide de l’api JSON du blog de Xebia, proposant des fonctionnalités de listing des auteurs, des categories et des articles, ainsi que des fonctionnalités telles que la recherche. Certaines solutions telles que Windows Phone 7, Palm OS, BlackBerry ou encore BKRender n’ont pu être défendues lors de cette journée faute de participants pour ces challengers, ce qui n’est que partie remise.

Une restitution, suivie d’un débat a permis aux xebians de faire le point sur les différentes solutions testées, et de mettre en avant les forces et faiblesses de chacune des technologies. 

La journée s’est achevée sur deux sessions parallèles :

• L’urbanisation présenté par Nicolas Jozwiak.
• Les bases de la cryptographie et des infrastructures à clés publiques présenté par David Galichet.

La semaine prochaine se tiendra la conférence Mix-IT (prononcez « mixité ») à Lyon. 25 speakers animeront la journée dans 5 salles en parallèle. Le but est de fournir des sujets variés et complémentaires, autour de 5 thèmes :

• Techy : Java et son écosystème
• Agility : L’agilité pour débutants et passionnés
• Trendy : Tendances novatrices et avant-gardistes
• Mixy : Le meilleur de l’agilité et des technologies Java
• Gamy : Jeux agiles et coding dojos

Cet évènement est organisé par le Lyon JUG et le Club Agile Rhône-Alpes.

En vrac, on y parlera de : Play!, Product Owner, Clojure, Coaching agile, Apache Mahout, BDD, Grails, DevOps, Spock, HTML5, Code retreat et bien d’autres sujets.

Vous pouvez découvrir le programme complet à cette adresse.

Xebia participe à cet évènement en animant 2 slots :

• Grails from scratch to Prod, par Aurélien Maury (@aurelienmaury)
• Intelligence collective avec Apache Mahout, par Michaël Figuière (@mfiguiere)

Les places sont comptées (200 spectateurs) donc dépêchez-vous de vous inscrire !

Après la traditionnelle introduction où chacun partage les actualités du mois précédent, place aux présentations, en parallèle :

• Michael Figuière a présenté Apache Mahout, le framework de Machine Learning de l’ecosystème Hadoop ;
• Nicolas Jozwiak et Frédéric Dubois se sont quant à eux attaqués aux concepts SOLID.

Ont suivi deux nouvelles sessions parallèles :

• Erwan Alliaume, Julien Buret, Séven Le Mesle et Pablo Lopez ont animé un débat sur les problématiques de Load Balancing dans les architectures soumises à forte charge ;
• Nathaniel Richand a organisé un open space, où il a notamment été question de traitement des exceptions Java puis de gestion des émotions.

Après la pause déjeuner, les sessions sont redevenues plénières :

• Katia Aresti est revenue en détail sur son expérience MongoDb et nous a fait l’honneur de l’avant première de la présentation qu’elle donnera à Mongo Paris ;
• Romain Maton nous a proposé un aperçu des APIs Google Guava ;
• Nathaniel Richand nous a démontré à quel point la communication est un facteur déterminant dans la réussite d’une mission ;
• Et, une fois n’est pas coutume, ce sont des intervenants extérieurs qui ont clos la journée. Mais contrairement à l’habitude, ce n’est pas un éditeur qui est venu nous présenter sa solution, mais deux de nos clients, Vincent Jaouen et Jean-Yves Cronier, qui nous ont exposé comment une refonte complète de leur couche HTML a permis de diviser les temps d’accès à un site internet grand public par cinq. Un grand merci à eux pour avoir apporté leur pierre à cet échange de connaissances.

Malgré l’heure avancée (la journée a une fois de plus été dense), bon nombre de courageux ont poursuivi les discussions autour d’un verre (Ajax, Json, méthodes d’audit, Grid computing mais aussi vacances au soleil et cinéma ).

Cette formation de 2 jours abordera principalement les thèmes suivants :

• Justesse : Développer des logiciels utiles et faciles d’usage.
• Fiabilité : Développer des logiciels comportant peu de défauts et maintenant leur niveau de service dans des conditions précises et pendant une période déterminée.
• Efficience : Développer des logiciels nécessitant un dimensionnement rentable et proportionné de la plate-forme d’hébergement en regard des autres exigences.
• Evolutivité : Développer des logiciels demandant peu d’effort pour les rendre conformes à de nouveaux besoins.
• Performance : Développer des logiciels rapides et efficients.
• Exploitabilité : Développer des logiciels exploitables
• Maintenabilité : Développer des logiciels évolutifs et faciles à prendre en main.
• Interopérabilité : Développer des logiciels portables et interopérables.

Si cette formation vous intéresse ou si vous souhaitez de plus amples informations, n’hésitez pas à consulter le programme de la formation sur le site xebia-training.fr ou à nous contacter au 01 53 89 99 99.

Grails, c’est bien. Ça permet des développements rapides, simples et efficaces. Mais à moins de faire du jetable pour tester, un jour, il faut livrer. Se pose alors, souvent tard, la question de la configuration de l’application au runtime.

Nous allons voir ensemble quelques solutions pour externaliser proprement les clés de configuration pour un projet basé sur Grails.

Out of the box

Grails, par défaut, nous offre la possibilité de charger des fichiers de configuration externe de façon assez simple. Le chargement s’effectue suivant une logique simple :

• Tout ce qui se trouve dans le fichier Config.groovy vient en premier
• Toutes les clés présentes dans les fichiers externes viennent s’ajouter à la configuration, ou surcharger les valeurs de Config.groovy.

Ce mécanisme est documenté et très simple à mettre en œuvre. Il suffit de placer les quelques lignes suivantes au début du fichier grails-app/conf/Config.groovy :

grails.config.locations = [ "classpath:${appName}-config.properties",
                            "classpath:${appName}-config.groovy",
                            "file:${userHome}/.grails/${appName}-config.properties",
                            "file:${userHome}/.grails/${appName}-config.groovy" ]

Comme on peut le voir dans cet exemple tiré de la documentation, on peut même utiliser des variables dans les chemins spécifiés. Plutôt simple, n’est-il pas ? Le problème est réglé ? Ça conviendra très bien à la plupart des petits projets montés en local, cependant, l’utilisation de chemins en dur (ou modulo certaines variables) directement dans le Config.groovy est un peu rigide. Il est souvent problématique de livrer un war à un exploitant en lui expliquant que le fichier de configuration doit se placer à tel chemin et pas un autre.

Voyons si on peut trouver mieux…

Par variable d’environnement ou propriété JVM

L’idéal serait de pouvoir définir le chemin vers le fichier de configuration depuis l’extérieur du war. Pour faire cela, on peut se baser sur des variables d’environnement. Le fichier Config.groovy est, avant toute chose, un script Groovy ! Par conséquent, aucun problème pour inclure un peu de code dedans et récupérer des valeurs depuis le système.

On pourrait par exemple remplacer l’exemple du précédent paragraphe par :

// On fixe le nom de la variable d'environnement qui nous intéresse
def ENV_NAME = "APPNAME_CONFIG"
// Si la liste grails.config.location n'existe pas, on l'instancie
if(!grails.config.locations || !(grails.config.locations instanceof List)) {
    grails.config.locations = []
}
// Si la variable est présente dans l'environnement ...
if(System.getenv(ENV_NAME)) {
  // ... on inclut sa valeur dans les configuration à charger
  println "Including configuration file specified in environment: " + System.getenv(ENV_NAME);
  grails.config.locations << "file:" + System.getenv(ENV_NAME)
} else if (System.getProperty(ENV_NAME)) {
  // Sinon on regarde dans les propriétés JVM et on l'inclut si elle est présente
  println "Including configuration file specified on command line: " + System.getProperty(ENV_NAME);
  grails.config.locations << "file:" + System.getProperty(ENV_NAME)
} else {
  // Si vraiment on ne trouve rien, on le dit quand même, parce que ça se fait.
  println "No external configuration file defined."
}

Extrait de cet article et commenté maison

Si vos administrateurs sont complaisants, cette méthode peut être votre solution. Mais beaucoup rechigneront à toucher à leur environnement système pour faire plaisir à votre code chéri (du moins c’était le cas parmi ceux que j’ai rencontrés). Cela risque également de poser des problèmes dans le cas où l’on souhaite faire tourner plusieurs instances de notre application sur le même serveur avec des configurations différentes. Dans ce cas, la grimace de l’administrateur devant son environnement système se remplissant de toute une famille de variables vaut le coup d’œil.

Poussons donc un peu plus loin…

Par entrée JNDI

Plutôt que de toucher à l’environnement du système, nous pouvons nous contenter de toucher à l’environnement d’exécution de notre application. JNDI arrive à la rescousse. En s’appuyant non pas sur des variables système mais sur des variables JNDI, on cantonne nos modifications au serveur d’applications. Le lien entre l’instance et son fichier de configuration est plus étroit et donc plus évident à manipuler.

Modifions une dernière fois notre en-tête de chargement de configuration (toujours dans Config.groovy) :

import javax.naming.InitialContext
// Si la liste grails.config.location n'existe pas, on l'instancie
if(!grails.config.locations || !(grails.config.locations instanceof List)) {
    grails.config.locations = []
}
try {
  // On tente de récupérer la variable d'environnement JNDI
  String extConfFile = (String) new InitialContext().lookup("java:comp/env/myAppInstanceConfig")
  // Si on trouve notre valeur, on l'ajoute aux fichiers à charger
  if (extConfFile) {
    grails.config.locations << extConfFile
    println "External configuration file loaded : ${extConfFile}"
  }
} catch (Exception e) {
  // En cas d'absence de la variable, on log
  println "Unable to load external configuration, using default."
}

Il suffira pour appliquer une configuration particulière, de définir la variable JNDI pour notre déploiement. Si on prend un serveur d’applications au hasard, Tomcat par exemple (oui, le hasard fait bien les choses), cela donnerait un fichier de contexte ressemblant à ceci:

<Context path="/myAppInstance1" debug="0" docBase="/the/full/path/to/myApp.war">
  <Environment name="myAppInstanceConfig" type="java.lang.String" override="false"
               value="file:/the/full/path/to/myApp-instance1-config.properties"/>
</Context>

Conclusions

Même si toutes ces méthodes sont valides, j’avoue ma préférence pour la dernière. Elle présente à mon sens de multiples avantages:

• pas d’impact sur le système
• possibilité de multiplier les instances avec des configurations différentes
• lien fort entre l’instance d’application et le chemin vers son fichier de configuration

Ce qu’il faut retenir de ces propositions, c’est surtout que Config.groovy est avant tout un script. Il est donc très facile d’ajouter sa propre logique de récupération des fichiers de configuration à charger. On pourrait en imaginer d’autres, comme d’aller parser un fichier centralisé sur le système ou de se connecter à une base de données pour récupérer des clés de configuration.

Le système de configuration incrémentale sur lequel est basé Grails et la configuration par scripting, permettent une très grande flexibilité, ou comme dirait les Perlistes: Tim Toady!.

Ressources

• Documentation Grails, section configuration externe
• ConfigSlurper, l’aggrégateur de configuration
• Developing JNDI-based Application, notamment la section Declaring Environment Variables

Après le traditionnel café du matin, la journée a commencé par une session de Craftsmanship autour du Refactoring to Patterns animée par Simon Caplette et Benoit Guérout.

Nous enchainons avec un challenge amusant autour du langage Java animé par Nabil Gasri.

Après la pause déjeuner, Michael Figuière nous a présenté son retour d’expérience sur le développement d’applications web à fortes affluences.

La journée de XKE s’est achevée par deux sessions parallèles :

• Une présentation de Steve Klouvi autour de Google Native Client (NaCl) permettant d’exécuter du code natif dans Chrome / Chromium de façon sécurisée.
• Une présentation avancée de l’API OAuth par Mathieu Minh.

Pour les plus courageux, les discussions ont continué en soirée à l’occasion d’un pot improvisé.

Pour ma part j’y présenterai une session sur le sujet émergeant que sont les moteurs de recherche temps réel. En effet depuis que Lucene s’est doté d’une capacité de recherche Near Real-Time, il y a un peu plus d’un an, il est maintenant possible d’effectuer des recherches sur du contenu au fur et à mesure de son apparition, là où auparavant un délai était nécessaire en raison d’une indexation en batch. Cette nouvelle capacité offre de nouveaux défis, puisque les différents traitements doivent également être assurés en temps réel. Pour répondre à cette problématique, je montrerai comment S4, le récent framework distribué de traitement de flux de Yahoo! peut rendre possible les analyses les plus audacieuses sur un flux de documents d’une taille quelconque.

L’abstract de cette présentation est le suivant :

Search engines have been around for a while, but only recently focus has been made on allowing search on real-time content. To enable such a thing, the whole indexing pipeline has to be made real-time : that is the data processing, and the insertion in the index itself. Lucene has been extended to allow the latter, but the former still has to be handled.
S4 is an emerging technology from Yahoo that simplifies real-time distributed data processing. The goal of this presentation is to show how S4 can be used to enable some expensive pre-processing on a stream of incoming data, right before its indexing, thus bringing a powerful real-time search capability.

Pour rappel, FOSDEM est une conférence gratuite et ouverte à tous, alors si Bruxelles vous est accessible, n’hésitez pas à vous y rendre !

Après nos échanges de vœux pour la nouvelle année et un bon café, la journée commença par deux sessions parallèles :

• Une présentation de la gestion avancée de la mémoire en Java animée par Pablo Lopez. Ce slot se positionnait dans la continuité du concours de tuning de performance organisé l’année dernière.
• Un débat autour du concept de DTO animé par Cyrille Le Clerc et Jean-Laurent De Morlhon.

Ce fut ensuite au tour de Michael Figuière de prendre la parole et d’esquisser les tendances des architectures de demain : Cloud, Elasticité, NoSQL, Scalabilité, etc.
Cette présentation a donné lieu à des débats animés.

Après un copieux déjeuner, nous avons accueilli Thomas Sarlandie, CTO de Backelite, qui nous a présenté leur solution de développement de services mobiles BkRender. Ce framework sera d’ailleurs testé lors de nos prochains XKE face à des alternatives comme JQuery Mobile, Flex pour Mobile, etc.

L’après midi s’est poursuivie par une présentation du plugin More Unit pour Eclipse par Nicolas Demengel, contributeur sur le projet.

Erwan Alliaume a ensuite animé un Hands On autour du framework Play!.

La journée s’est achevée par un retour d’expérience sur la mise en place de MongoDB / Amazon EC2 / S3 par Katia Aresti et Jean-Laurent De Morlhon (Cf. MongoDB en pratique).

Elle vient compléter nos sélections des années précédentes:

• Bêtisier 2007
• Bêtisier 2008
• Bêtisier 2009

N’hésitez pas à poster en commentaire vos propres rencontres du troisième type … A vous de jouer !

Après le break dance, le break coding

while (mamethode()) {
 break;
}

En entier …

public static int toInteger(String value) {
     try {
            return new Double(Double.parseDouble(value)).intValue();
     } catch (NumberFormatException e) {
           return 0;
     }
}

Un Long ?

private static final String DOT = ".";
...
public static boolean isLongNumber(String value) {
     try {
           Double.parseDouble(value);
           return !value.contains(DOT);
     } catch (NumberFormatException e) {
           return false;
     }
}

Cherchez l’erreur

public static ColumnsTableManagement getInstance() {
     synchronized (ColumnsTableManagement.class) {
            instance = (ColumnsTableManagement) FacesContext.getCurrentInstance().getExternalContext().getSessionMap().get("columnsTableManagement");
            if (instance == null) {
                instance = new ColumnsTableManagement();
                FacesContext.getCurrentInstance().getExternalContext().getSessionMap().put("columnsTableManagement", instance);
            }
            return instance;
     }
}

Une jolie trouvée dans un test unitaire

if (messagesList.size() == 3) {
    assertEquals(true, true);
} else {
    assertEquals(true, false);
}

Quelques nulls fraîchement instanciés

if (null == new Integer(srt.getValuationType())) {
    //...
}

GetTrace response = new GetTrace();
if (response != null)
    cache_getTrace.putValue(signature, response);
else
    cache_getTrace.failRelease(signature);

Au cas où une exception n’hériterait pas de Throwable

try {
    //...
} catch (Exception e) {
    if (e instanceof Throwable) {
        throw new SecurityManagerException(e);
    }
    if (code == 2) {
        accountsummary.setIsBlocked(accountBlocked);
    }
}

Le but de cet article est de sensibiliser les développeurs aux notions de sécurité des applications web. L’idée n’est pas de faire de vous des experts de la sécurité (le sujet est, comme vous vous en doutez probablement, plutôt vaste) mais de vous donner les bases qui vous permettront d’appréhender les principales problématiques de la sécurité informatique, et plus particulièrement de la sécurité des applications Web. Cet article n’a donc pas vocation à être un état de l’art des techniques de cryptographie et de sécurité informatique, mais d’en introduire les concepts.

Lorsque nous travaillons sur la sécurisation d’une application, nous nous attachons principalement aux aspects suivant :

• l’authentification,
• les autorisations,
• l’intégrité,
• la confidentialité,
• l’identité,
• la non répudiation.

Nous allons traiter dans la suite de cet article ces différents principes, en essayant de rester simple et pragmatique.

Principes de la cryptographie

Avant d’entrer dans le vif du sujet, je vous propose un petit rappel des principaux principes de la cryptographie.

Les fonctions de hachage

Ces fonctions permettent de calculer une empreinte (appelée aussi hash) d’une donnée informatique. Les fonctions de hachage implémentent quelques propriétés que nous allons définir maintenant :

• le grand nombre d’empreintes possibles (entre 2^128 à 2^256 bits) implique une probabilité extrêmement faible de collisions,
• la taille de l’empreinte est fixe, quelle que soit la taille de la donnée hachée. L’empreinte d’un mot de passe de huit caractères aura donc la même taille que l’empreinte d’un fichier de plusieurs centaines de Mo,
• un changement infime dans la donnée hachée entraîne un changement important dans l’empreinte correspondante (ce qui rend une recherche inverse par dichotomie impossible),
• le calcul d’une empreinte est très rapide (pratique pour le calcul de sommes de contrôle de fichiers de plusieurs centaines de Mo),
• il n’est pas possible, en connaissant l’empreinte et la fonction de hachage utilisée, de calculer la donnée d’origine.

Ces fonctions sont généralement utilisées pour les besoins suivant :

• vérification de l’intégrité d’une donnée : dans ce cas, le hash (généralement appelée somme de contrôle ou checksum) est utilisé pour s’assurer qu’une donnée informatique n’a pas été corrompue,
• stockage des mots de passes : le hachage du mot de passe permet d’éviter que ce dernier soit stocké en clair. Nous reviendrons sur ce cas d’utilisation dans la suite de cet article,
• la construction de jetons : comme les jetons remember me.

Il existe différents algorithmes de hachage :

• MD5 (Message Digest 5) : probablement le plus connu, il est souvent utilisé pour les sommes de contrôle ou le stockage de mot de passes (notamment dans sa version salée dans diverses distributions Linux). Son empreinte est représentée sur 128 bits. Actuellement, le MD5 est mis de côté au profit des algorithmes SHA1 et SHA256 réputés plus sûrs.
• SHA1 (Secure Hash Algorithm) : cette fonction de hachage crée des empreintes sur 160 bits. Cet algorithme est lui aussi progressivement remplacé par le SHA256, beaucoup moins facile a casser grâce à son empreinte sur 256 bits.

Le cassage d’un mot de passe haché ne peut se faire que par brute force (si l’on a beaucoup de puissance de calcul et de temps), par dictionnaire (on parcourt successivement les mots de passe les plus courants), en utilisant des dictionnaires inversés qui permettent de retrouver le mot de passe à partir du hash ou encore plus efficacement par l’utilisation de Rainbow Tables.
Cette dernière technique reste la plus efficace pour retrouver un mot de passe faible, à condition d’avoir accès au hash d’origine. On peut l’imaginer comme une grosse HashMap dont la clé serait l’empreinte et la valeur la donnée d’origine. Les mots de passe les plus simples ont donc de grandes chances de s’y retrouver.

Le salage du hash est une technique efficace permettant de se prémunir des attaques par dictionnaire inversé. Cette technique consiste à ajouter à la donnée à hacher un sel, qui peut être une valeur arbitraire, et qui rendra donc les attaques par dictionnaire inversé inefficaces :
empreinte = hachage(mot_de_passe + sel)
Il n’est pas nécessaire que le sel soit une information secrète, son utilité étant de rendre les dictionnaires inversés inefficaces.

Les commandes unix md5pass et sha1pass permettent de générer des mots de passes salés :

% sha1pass password dupont@example.com
$4$dupont@example.com$hJLyOpYbVayE1Iq/ZY03Rx/r5Sk$
% sha1pass password martin@example.com
$4$martin@example.com$+LoO8eRzXhH23ozwXIDDpNE7ag4$

On voit ici que le salage d’un même mot de passe donne une empreinte totalement différente.

Nous reviendrons dans un prochain article sur la manière d’utiliser les algorithmes de hachage pour le stockage des mots de passe.

Le chiffrement symétrique

Les algorithmes de chiffrement symétriques reposent sur un secret (clé de chiffrement) partagé qui est utilisé pour chiffrer une donnée. Ils sont généralement utilisés pour sécuriser des informations ou des communications. Ses caractéristiques sont :

• un chiffrement rapide des données, nécessaire au chiffrement des communications ou d’un important volume de données,
• la même clé est utilisée pour chiffrer et déchiffrer.

Les algorithmes les plus couramment utilisés sont l’AES et le Blowfish. Il existe un grand nombre d’algorithme disponibles en Java (cf la documentation du projet Bouncycastle et la page de Wikipedia)

Le chiffrement asymétrique

Ce chiffrement repose sur une bi-clé, l’une publique et l’autre privée, dont l’une permet de chiffrer ce que l’autre va déchiffrer. Si la clé publique est utilisée pour chiffrer, la clé privée permettra le déchiffrement et inversement.
La clé publique est librement diffusée et peut être utilisée pour chiffrer une donnée à l’intention du détenteur de la clé privée.
La clé privée peut aussi être utiliser pour chiffrer et dans ce cas, seule la clé publique pourra déchiffrer le contenu. Ce type d’utilisation permet au détenteur de la clé privée de prouver son identité en signant une donnée. Nous y reviendrons dans la suite de cet article.

Le chiffrement asymétrique est principalement utilisé pour chiffrer des clés de chiffrement symétriques ou des hash pour une raison toute simple : les algorithmes de chiffrement asymétriques sont excessivement lents et ne peuvent pas être utilisés pour chiffrer des données dépassant quelques centaines d’octets. Son usage est donc principalement réservé au chiffrement de clés ou d’une empreinte (hash).

Un cas typique d’utilisation du chiffrement asymétrique est l’échange de clés de session (clé secrète) permettant le chiffrement d’une communication entre deux systèmes.
Un autre cas d’utilisation du chiffrement asymétrique est la signature d’un document. Dans ce cas, l’empreinte du document à signer est chiffrée à l’aide de la clé privée et déchiffrée avec la clé publique. Nous reviendrons plus tard sur ces types d’utilisation.

Les algorithmes asymétriques les plus connus sont le RSA (Rivest Shamir Adleman), le DSA (Digital Signature Algorithm) et le protocole d’échange de clés Diffie-Hellman.

Enfin, le chiffrement asymétrique est utilisé dans les certificats numériques X509 dont nous reparlerons bientôt.

Nous en avons fini avec les principes de base de la cryptographie. Un petit tour sur Wikipedia vous donnera de plus amples informations sur le sujet.

L’authentification

L’authentification est probablement la notion la plus simple à comprendre, mais en tant que développeur, c’est une de celles qui vous demandera le plus de travail d’implémentation.
Comme vous pouvez vous en douter, l’authentification consiste à fournir un moyen d’accès à une application.

Authentification par identifiant et mot de passe

Elle prend le plus souvent la forme d’un formulaire d’authentification où un identifiant unique ainsi qu’un secret (mot de passe secret que seul l’utilisateur rattaché à l’identifiant unique est sensé connaître) vous est demandé.
Dans ce cas de figure, le mot de passe est généralement stocké sous forme hachée le plus souvent dans un annuaire LDAP ou dans une base de donnée. La version salée de la fonction de hachage est chaudement recommandée afin d’éviter la découverte du mot de passe à l’aide d’un dictionnaire inversé.

Des techniques de durcissement de l’authentification par mot de passe, comme l’envoi de SMS, l’utilisation de Captchas ou encore l’utilisation de RSA SecurID, peuvent être employé avec des résultats plus ou moins satisfaisants.

Dans un prochain article, nous verrons qu’il est assez simple de mettre en œuvre ces bonnes pratiques d’authentification à l’aide du framework Spring Security.

Authentification par certificat

Les certificats numériques X509 sont généralement connus pour leur utilité dans le chiffrement des connexions SSL (utilisé avec le protocole HTTPS) et peuvent aussi être utilisés pour l’authentification à une application. Ils sont constitués d’une partie privée, généralement protégée par un mot de passe, qui est conservée par l’utilisateur et d’une partie publique qui est stockée sur le système hébergeant l’application à laquelle nous souhaitons accéder.

Là encore, un durcissement de cette technique d’authentification peut être réalisé à l’aide de tokens cryptographiques (clés USB, cartes à puce). Ces tokens cryptographiques ont la capacité de générer la bi-clé du certificat numérique et d’effectuer des opérations de chiffrement/déchiffrement asymétriques. L’intérêt majeur réside dans le fait que la clé privée ne sortira jamais du token et ne pourra donc pas être dupliquée (en cas de vol, le certificat sera simplement révoqué et deviendra inutilisable). La sécurité est donc assurée par une possession physique (le token) et par un secret (le mot de passe permettant l’utilisation du token).

Les certificats numériques sont un moyen de contrôle d’accès efficace mais potentiellement complexes à mettre en œuvre. Nous reviendrons sur le détail de leur fonctionnement et de leur utilisation dans un prochain article.

Authentification par Single Sign On (SSO)

Le Single Sign On permet la délégation de l’authentification à une application tierce qui va permettre aux utilisateurs d’accéder à toutes les applications du Système d’Information en ne s’authentifiant qu’une unique fois, pour la durée de la session d’authentification.

L’authentification par SSO peut être mise en place en interne, au sein du Système d’Information d’entreprise utilisant le Central Authenticate Service (CAS) par exemple, ainsi qu’en externe à l’aide de sites implémentant des protocoles tels qu’OpenID.

Là encore, un prochain article entrera dans les détails de l’utilisation du SSO dans vos applications web, ainsi que diverses bonnes pratiques et mises en garde sur leur utilisation (notamment en ce qui concerne OpenID).

Les autorisations

Une fois authentifié, l’utilisateur souhaite utiliser l’application et pour cela, il lui faut des droits ou autorisations. Chaque utilisateur aura donc un rôle lui accordant un ensemble de droits permettant d’effectuer des opérations ou d’accéder à certaines données.
Les rôles les plus communs sont « utilisateur » ou encore « administrateur » mais il est possible d’imaginer tous types de rôles en fonction des besoins de l’application.

L’intégrité

Les fonctions de hachage sont utilisées pour s’assurer de l’intégrité (la non altération) d’une donnée. Le calcul des sommes de contrôle est un élément important permettant de s’assurer qu’une donnée n’a pas été corrompue, frauduleusement ou non.

La confidentialité

L’un des enjeux de la sécurisation des sites web est de garantir la confidentialité des données. Cette confidentialité repose sur les mécanismes de chiffrement symétriques et asymétriques qui permettent de protéger des données locales (avec TrueCrypt par exemple) ou bien des communications.

L’un des mécanismes les plus connus est probablement le protocole Secured Socket Layer (SSL) (remplacé par Transport Layer Security normalisé par l’IETF) qui permet entre autre, le chiffrement des communications entre deux tiers. Le protocole utilise les algorithmes asymétrique pour chiffrer une clé de session (symétrique) qui est ensuite utilisée pour le chiffrement symétrique de la communication.

La confidentialité est d’une importance capitale dans tout mécanisme d’échange de données un tant soit peu sensibles (mot de passes, données bancaires …).

L’identité

Prouver son identité est probablement la tâche la plus complexe, et en même temps un des aspects fondamentaux de la sécurité. Lors d’une communication entre deux tiers, au hasard un client et un serveur, nous avons vu que certains mécanismes permettent de s’authentifier ou encore d’assurer la confidentialité.

Nous avons aussi vu que les algorithmes de chiffrement asymétriques, reposant sur une bi-clé dont l’une est privée et l’autre est publique, permettent l’échange de données sécurisé ou encore de prouver son identité.

Dans le premier cas de figure, nous utilisons la clé publique de notre interlocuteur afin de chiffrer une clé de session qui elle même a permis le chiffrement du document que nous souhaitons faire parvenir, en toute confidentialité, au possesseur de la clé privée. Dans ce cas, la seule chose dont nous sommes certains est que seul le possesseur de la clé privée sera à même de déchiffrer le contenu du document.

Dans un second cas de figure, nous souhaitons prouver que nous sommes à l’origine d’une donnée (une demande de congés par exemple). Une fois encore, le mécanisme de chiffrement asymétrique va venir à notre rescousse en nous permettant de chiffrer une empreinte du document que nous souhaitons envoyer à l’aide de notre clé privée. Ainsi, en déchiffrant l’empreinte à l’aide de la clé publique, nous nous assurons que la donnée provient bien du possesseur de la clé privée, mais aussi que cette donnée n’a pas été altérée, en recalculant l’empreinte du document et en la comparant à celle que nous venons de déchiffrer.

C’est plutôt pas mal, nous avons un mécanisme nous permettant d’envoyer un document de manière confidentielle à un tiers, mais aussi de prouver notre identité, juste à l’aide d’un mécanisme de clé publique que l’on distribue à ceux avec qui l’on souhaite communiquer. C’est malheureusement sur ce dernier point, « la distribution de la clé publique », que les choses se compliquent. Est-il toujours possible de remettre en main propre sa clé publique ? Comment puis-je m’assurer que la clé publique dont je dispose correspond bien à l’émetteur dont je crois connaître l’identité ?

Les certificats numérique dont le standard X509 est le plus répandu, apporte des réponses à nos questions. Ces certificats contiennent un certain nombre d’informations sur son propriétaire, sa clé publique ainsi qu’une empreinte signée du contenu du certificat.

Concernant la signature de l’empreinte nous avons deux cas de figure. Dans le premier cas, l’empreinte est signée à l’aide de la clé privée correspondant à la clé publique du certificat, c’est ce que l’on appelle un certificat auto-signé. Dans le second cas, une demande de certification est envoyée à une Autorité de Certification (AC), qui va ajouter sa propre identité dans le certificat (clé publique + informations sur l’Autorité de Certification) et signer l’empreinte du certificat.

L’Autorité de Certification peut être une entreprise dont les certificats sont reconnus dans la plupart des Systèmes d’Exploitation, Navigateurs, JVM…, comme Verisign par exemple, mais peut aussi être une DSI qui crée son propre certificat racine et l’implante dans les différentes postes de son SI.

Lorsque le navigateur, par exemple, recevra un certificat X509, celui-ci vérifiera qu’il est bien signé par une Autorité de Certification reconnue et le reconnaîtra comme valide. Dans le cas d’un certificat auto-signé et non reconnu, le système pourra proposer de l’accepter à ses risques et périls.

Afin d’augmenter la sécurité des certificats, les clés privées (qui sont sensées ne jamais être exposées), sont généralement protégées par un mot de passe. Le principe est que notre identité soit protégée par quelque chose que l’on possède (une clé privée) et un secret. Des mécanismes plus « durs » de sécurisation reposent sur des tokens cryptographiques qui contiennent le générateur de la bi-clé et l’espace mémoire pour stocker la clé privée. Dans ce cas, la clé privée peut être volée mais pas dupliquée. En cas de vol, le certificat numérique peut être révoqué ce qui empêche une utilisation délictueuse.

Nous n’entrerons pas plus dans les détails sur les certificats numériques dans cet article. Nous en reparlerons lorsque nous aborderons l’authentification X509 dans un prochain article. Sachez simplement que les certificats numériques sont mis en œuvre dans beaucoup de mécanismes tels que les connections HTTPS qui sécurisent nos communications sur le web, dans le protocole SSH ou encore dans les réseaux privés virtuels (VPN).

La non répudiation

La non répudiation consiste à s’assurer que l’émetteur d’une donnée ne puisse pas nier son implication en cas de litige. La non répudiation repose généralement sur des certificats numériques, qui restent le moyen le plus efficace pour s’assurer de l’identité d’une personne.

D’un point de vue légal, la non répudiation est particulièrement difficile à mettre en œuvre. Il est en effet difficile de remettre en cause la bonne foi d’une personne pouvant prétexter le vol de son identité numérique pour se défausser de sa responsabilité. Il peut par exemple être nécessaire de mettre en place des mécanismes de co ou de contre signature et de l’horodatage en fonction des besoins.

Ce sujet est particulièrement complexe, nous ne nous y attarderons pas plus. Vous pourrez trouver de plus amples informations sur internet, ici par exemple.

Conclusion

Cette introduction nous à permis de faire un tour des principes liés à la sécurisation des sites web. Les principes cryptographiques que sont le hachage et les algorithmes de chiffrement symétriques et asymétriques sont à la base de toute infrastructure web sécurisée.

Comme vous l’aurez compris, cet article est le prélude à une série d’articles sur la sécurisation des sites web, où nous utiliserons le très répandu framework Spring Security pour illustrer nos propos et quelques bonnes pratiques. Nous nous efforcerons par la même occasion d’aborder les failles les plus communes, référencées par l’OWASP Top Ten, et de montrer comment les traiter.

Avec un peu de retard sur les autres, voici le cinquième article de cette série sur Grails. Nous allons parler ici de :

• Tests unitaires
• Tests d’intégration
• Mesures de qualité de code
• Intégration continue

En appliquant le tout à notre projet test bien aimé : NoThunes.

Tout code sera testé, sinon par vous, alors par vos utilisateurs …

La nécessité de tester notre code, quel qu’il soit, a été largement décrite, soutenue et argumentée. Par conséquent, nous ne reviendrons pas dessus dans cet article. Je tiens à m’excuser pour avoir placé en dernier lieu l’activité qui devrait ouvrir le bal dans la rédaction d’une application (le TDD c’est bon, mangez-en). Cela m’a paru plus attractif de mettre les mains dans le cambouis de suite. Mais maintenant nous allons passer aux choses sérieuses : les Tests.

Scott Davis, sur le blog d’IBM, a rédigé une série d’articles Mastering Grails dont 2 nous concernent plus particulièrement ici :

• Mock Testing with Grails
• Testing your Grails application

Les tests à la mode Grails sont largement bien décrits dans ces 2 articles. Je vais donc vous fournir ici mon retour d’expérience sur l’application en conditions réelles de ces conseils. Les tests unitaires au sens propre sont très bien décrits dans ces 2 articles, nous allons donc directement sauter aux tests d’intégration.

Tests d’intégration Grails dans la pratique

Durant la phase des tests d’intégration, l’application est chargée entièrement, dans un mode test. C’est l’équivalent du lancement de grails test run-app. Par conséquent nous disposons d’une base de données et de tous nos composants.

D’après Burt Beckwith, membre de la team Grails, il ne faut pas utiliser le framework de mock de Grails pour tester les classes de domaine. Sinon, tout ce qui est testé, c’est le framework de mock en lui-même et il ne supporte pas toutes les fonctionnalités de GORM (comme les closures withCriteria par exemple !). Pour les classes de domaine, il faut donc utiliser uniquement des tests d’intégration. L’exception à cette règle concerne les tests de méthode n’impliquant ni GORM, ni la base de données, comme les tests de validation de contraintes (regarder du côté de mockForConstraintsTests() pour ça).

Cette méthode est un peu radicale et suppose que, dès qu’on fait usage, à un quelconque endroit, de requêtes nommées ou de closures Criteria, on se retrouve obligé de ne coder que des tests d’intégration. Une alternative consiste à utiliser GMock pour combler les manques actuels de Grails.

Jeux de données

Lorsqu’on code des tests d’intégration il est important de connaitre le contenu de la base de données avant chaque test. Il est donc utile de pouvoir se baser sur des jeux de données pour initialiser la base. Parmi les nombreuses solutions qui s’offrent à nous, voici celles qui ont retenu mon attention :

• Utiliser la classe de configuration Bootstrap.groovy : Cela suppose de charger l’intégralité des données utiles pour tous les tests d’intégration, ce qui peut vite devenir encombrant. De plus le code nécessaire à instancier, lier et sauver toutes les instances utiles est assez verbeux.
• Le plugin DbUnit Operator : Permet d’injecter à la demande des jeux de données écrits en XML. Ce plugin est basé sur la librairie du même nom. C’est robuste et souple à la fois. L’inconvénient est que le modèle XML est centré sur le schéma de la base et va nécessiter une maintenance non négligeable.
• Le couple de plugin Fixtures/BuildTestData : Fixtures permet de créer des jeux de données et de les sauvegarder en base rapidement avec une syntaxe concise. C’est la solution qui m’a semblée la plus pratique. L’association avec le plugin BuildTestData autorise à raccourcir encore la définition d’entités. Les champs non remplis manuellement dans une fixture peuvent être remplis automatiquement par BuildTestData.

Après expérimentation, la dernière solution s’est révélée la plus simple et efficace. La documentation du plugin est un peu succincte et ne décrit pas de façon explicite tous les cas d’utilisation. En exclusivité, je vais prendre comme exemple un cas non documenté, sous vos yeux ébahis : l’utilisation conjointe des 2 plugins dans une fixture externe. Commençons par l’installation :

grails install-plugin fixtures
grails install-plugin build-test-data

L’installation du plugin Fixtures entraine l’apparition d’un répertoire fixtures/ à la racine du projet. Tous les fichiers de fixtures déposés dedans seront rendus accessible pour être chargé dans le code de nos tests. Il est possible de mettre directement les fixtures dans notre code (comme décrit dans la documentation) mais j’ai préféré l’option de chargement de fichiers externes pour éviter d’introduire du bruit dans le code. Voici une fixture appliquée à notre modèle :

fixtures/initialDev.groovy

import fr.xebia.nothunes.domain.*
import fr.xebia.nothunes.security.*
def member = User.findByUsername('user')
member.confirmPasswd = member.passwd
build {
  rtnp(Band) {
    name = 'RTNP'
    webSite = 'http://rtnp.org'
    owner = member
  }
  promotionCanape(Album) {
    name = "Promotion Canapé"
    band = rtnp
  }
  zombieNow(Track) {
    name = "Zombie Now"
    album = promotionCanape
  }
}

Décryptons ce fichier. Nous commençons par récupérer une instance de compte utilisateur en base, pour lui attribuer un Band. Cet utilisateur a été inséré dans la base via la classe de configuration Bootstrap, on peut donc compter dessus. La closures build sera interprétée par Fixtures pour créer les objets et les sauver en base. Fixture permet d’utiliser une closure build, qui s’appuie sur le plugin BuildTestsData, qui remplira automatiquement les champs non definis dans la fixture, de façon à ce que l’instance créée respecte ses contraintes d’intégrité.

Il est important de noter que les liens tissés entre les objets de la fixture sont écrits de façon directe. Par exemple la propriété band de notre instance promotionCanape est directement le nom de l’instance décrite juste au dessus. Pas besoin de sauvegarde intermédiaire, ce qui fait gagner pas mal de temps d’écriture.

Maintenant que nous disposons d’un petit jeu de données, pour le charger dans un test, il suffit de faire comme ceci :

package fr.xebia.nothunes.domain
import grails.test.*
import fr.xebia.nothunes.domain.*
import fr.xebia.nothunes.security.*
class TrackIntegTests extends GrailsUnitTestCase {
  // definition de l'attribut fixtureLoader pour injection automatique
  def fixtureLoader
  protected void setUp() {
    super.setUp()
  }
  protected void tearDown() {
    super.tearDown()
  }
  void testLoadFixture() {
    // chargement du fichier fixtures/initialDev.groovy
    def fixture = fixtureLoader.load('initialDev')
    def result = Track.listOrderByName()
    assertEquals 1, result.size()
    assertEquals 'Zombie Now', result[0].name
  }
  void testNotLoadedFixture() {
    def result = Track.listOrderByName()
    assertEquals 0, result.size()
  }
}

Comme on peut le voir, la durée de vie des données en base ne dépasse pas la méthode de test. Ce comportement est plutôt pratique pour éviter que nos tests d’intégration se polluent les uns les autres.

Test fonctionnels

Pour aller encore un peu plus loin dans les tests, il faut monter encore d’un cran et passer aux tests d’IHM. Une référence dans le monde du web en Java : Selenium. C’est le premier nom qui m’est venu et j’ai donc cherché un plugin Grails. Il existe bel et bien mais la documentation initiale m’a fait faire demi-tour. Les tests peuvent être rédigés en trois formats différents, je vous colle des exemple de chacun pour que vous puissiez juger :

• HTML :

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>test1</title>
</head>
<body>
<table cellpadding="1" cellspacing="1" border="1">
<thead>
<tr><td colspan="3">test1</td></tr>
</thead><tbody>
<tr><td>open</td><td>/selenium-test/</td><td></td></tr>
<tr><td>clickAndWait</td><td>link=BookController</td><td></td></tr>
<tr><td>clickAndWait</td><td>link=New Book</td><td></td></tr>
<tr><td>type</td><td>title</td><td>book1</td></tr>
<tr><td>clickAndWait</td> <td>//input[@value='Create']</td> <td></td></tr>
<tr><td>clickAndWait</td> <td>link=Book List</td> <td></td></tr>
<tr><td>verifyTextPresent</td> <td>book1</td> <td></td></tr>
</tbody></table>
</body>
</html>

• Pipe separated values :

open|/selenium-test
clickAndWait|link=BookController
clickAndWait|link=New Book
type|title|book2
clickAndWait|//input[@value='Create']
clickAndWait|link=Book List
verifyTextPresent|book2

• Groovy Server Pages :

<g:set var="bookTitle" value="book0d"/>
<sel:test name="MyTest">
<sel:row command="open" target="${request.contextPath}"/>
<sel:row line="clickAndWait|link=BookController"/>
<sel:row line="clickAndWait|link=New Book"/>
<sel:row command="type" target="title" value="${bookTitle}"/>
<sel:row line="clickAndWait|//input[@value='Create']"/>
<sel:row line="clickAndWait|link=Book List"/>
<sel:row line="verifyTextPresent|${bookTitle}"/>
</sel:test>

Si l’une de ces syntaxes vous emballe, faites en bon usage. Personnellement j’ai été refroidi par l’aspect très compact et plutôt dur à relire. J’ai donc continué mes investigations, et suis finalement tombé sur le plugin WebTest, basé sur la librairie de Canoo. Une librairie beaucoup plus orienté Groovy que ne l’est le plugin Selenium. De plus WebTest fourni également de jolis rapports HTML plein de couleurs attrayantes, faciles à interpréter. Voici un exemple de ce que peut donner le code d’un test simpliste avec cette librairie :

package nothunes
import nothunes.common.WebTestsNoThunes
class BandWebTests extends WebTestsNoThunes {
  def fixtureLoader
  void testLogin() {
    invoke(url:'login')
    verifyText(text:'Please Login..')
    def fixture = fixtureLoader.load('initialDev')
    invoke(url:'/navigation')
    verifyText(text:'RTNP')
  }
}

Les actions sont basiques, l’API est nativement en Groovy, et pour ceux qui ont déjà utilisé Selenium sur des projets Java, ce n’est vraiment pas dépaysant. La facilité de prise en main et les rapports parlants en font ma préférence pour l’automatisation de tests d’IHM web.

Analyse statique du code

Outre la pose d’un filet de sécurité autour des fonctionnalités de l’application, il est également intéressant d’affiner la qualité du code source produit. L’analyse statique de code est une méthode rodée chez les développeurs Java pour permettre de trouver des duplications de code, des bugs éventuels, évaluer la complexité, etc. Du coté du langage Groovy, l’outillage est un peu moins riche mais on trouve quand même quelques petites choses intéressantes.

CodeNarc

Tout d’abord : CodeNarc. Ce programme permet de valider du code Groovy en regard de règles de programmation établie. Un jeu de règle est proposé par défaut mais il est possible de définir ses propres règles. Un packaging sous forme de plugin Grails existe également, pour permettre une installation et une utilisation simplifiées :

grails install-plugin codenarc
grails codenarc

Cela va lancer l’analyse et générer un rapport détaillé de toutes les violations de règles, au format HTML :

Extrait de CodeNarcReport.html

La présentation est spartiate, mais ça tourne ! Le rapport commence par une vision macro avec la consolidation des erreurs par package, puis viens la liste détaillée de chacun des packages concernés, et enfin la description de chaque type de violation rencontré.
On peut également écrire soit même des règles de programmation à respecter. Il est donc aisé de se baser sur cet outil pour faire respecter les normes de votre choix. Pour ceux d’entre vous qui l’utilise déjà, sachez que la dernière version (la 0.11) est sortie le 13 novembre avec notamment 50 règles supplémentaires.

GMetrics

GMetrics, quant à lui, est centré sur le calcul et la présentation de métriques. Le projet assure le calcul :

• de complexité cyclomatique
• du nombre de lignes par méthode
• du nombre de lignes par classe

Selon le même principe que CodeNarc, l’installation de cette librairie se fait comme un plugin au projet : il se lance simplement et génère un rapport HTML :

grails install-plugin gmetrics
grails gmetrics

Extrait d’un rapport GMetrics

GMetrics est encore assez léger dans les métriques collectées, mais il offre une excellente base de développement pour collecter ses propres métriques. Si par hasard vous en écrivez pour un projet, n’hésitez pas à en faire profiter la communauté.

Conclusions

Il y aurait de quoi écrire un livre entier sur le seul sujet des tests dans le cadre de Grails. Comme d’habitude, les affinités entre le langage Groovy et le Java font que beaucoup d’outils Java sont déjà pluginizé ou ne coûterai pas cher à l’être. Longtemps cantonné aux scripting Java, le langage Groovy trouve ses lettre de noblesse avec Grails. Il est agréable de voir se développer pour le langage Groovy des outils de qualité qui apportent tant au langage Java. En quelques recherches, un projet peut se doter de tout ce qu’il faut pour développer des tests unitaires, d’intégration, fonctionnels mais aussi tests d’acceptance (avec Fitnesse ou EasyB), ou même des tests de vos fonctions Javascript avec JsUnit.

Dans le framework Grails, les tests sont disponibles pour tous les goûts, toutes les tailles. Le véritable défi consiste à séparer le bon grain de l’ivraie au milieu du foisonnement de plugins disponibles (sans compter qu’il est toujours possible d’intégrer soit même des librairies Java). J’espère vous avoir apporté, sinon La réponse, au moins l’éclairage de mon expérience personnelle sur le sujet. Maintenant il ne reste plus qu’à trouver votre propre style de tests Grails.

Ressources :

• Tests unitaires sur le site Grails
• Section Testing de la documentation officielle
• Mock Testing with Grails
• Testing your Grails application
• NoThunes sur GitHub

La culture du partage de la connaissance étant la valeur fondatrice de Xebia, ces journées mensuelles réunissent nos passionné(e)s qui discutent, entre autres, des dernières technologies de l’écosystème Java JEE et font partager leurs retours d’expérience sur des sujets techniques (mais pas seulement) choisis à l’avance.

C’est donc à travers des présentations formelles, des sessions de travaux pratiques, des débats, que chacun peut faire profiter de son point de vue et de son expérience.

Après un vote collégial sur les sujets qui seront abordés au cours de cette journée, les volontaires ont plusieurs semaines pour travailler seuls ou en groupe sur leurs sujets plébiscités par l’ensemble de leurs collègues.

Xebia souhaitait vous en dévoiler un peu plus sur ces journées, au coeur de l’ADN et des synergies de Xebia.

Au programme ce mois ci :

Après le café du matin, qui aide à oublier le grand froid, la journée commence avec une session News / Actus au cours de laquelle les 45 consultants de Xebia échangent librement sur les actualités qui ont retenu leur attention ce mois-ci.

Pour continuer, les consultants ont eu le choix entre deux sessions parallèles :

• Une présentation sur la collecte de logs sur des architectures massivement distribuées, par Pablo Lopez.
• Un slot Acceptance Test Tools Contest, par Nathaniel Richand.

Après le déjeuner, qui est l’occasion de poursuivre les débats et discussions de la matinée et de faire connaissance avec les invités autour d’une pizza, nous accueillons Michaël Chaize évangéliste de la plateforme Flash qui nous présente les nouveautés des plateformes Flash et Flex d’Adobe.

L’après midi, se poursuit avec deux Hands On en parallèle :

• Un Hands On « BDD (Behaviour Driven Development) avec « jBehave », animé par Hamza Benmansour et Aurélien Masse.
• Un Hands On « Développement iPhone », animé par Amin Fathallah.

La dernière session de la journée est un retour complet sur Devoxx, par Ellène Dijoux, Romain Maton et Michael Figuière, nos reporters pour l’évènement !

Le XKE s’est terminé, comme à son habitude, par un apéritif improvisé pour célébrer une nouvelle journée d’émulation technique et de partage de connaissances…

Xebia a été classée 37ème du classement Deloitte Technology Fast 50 France 2010.
Deloitte a sélectionné les entreprises de ce palmarès en fonction du taux de croissance de leur chiffre d’affaires sur cinq exercices (2005-2009).

C’est donc avec fierté que Xebia s’est vue récompensée lors de la remise des prix du palmarès National, réunissant plus de 300 entrepreneurs, investisseurs et acteurs majeurs de la chaine de l’innovation et du développement des entreprise technologiques, lundi 22 novembre, au palais Brongniart.

Le Président de Xebia, Luc Legardeur, attribue au respect en toutes circonstances des valeurs fondatrices de la société (l’absence de compromis sur la qualité, la place de l’individu au centre de toutes décisions, le partage de la connaissance et l’instauration d’une intimité client forte), le taux de croissance de 1060% du chiffre d’affaires de Xebia sur ces cinq dernières années.
Il déclare : « Cette récompense est une récompense pour tous les Xebians ».

« Figurer au palmarès des Technology Fast 50 de Deloitte signifie faire partie des leaders français de la croissance pendant 5 années, ce qui démontre des qualités exceptionnelles dans le secteur d’activité si fortement concurrentiel qu’est la technologie aujourd’hui » déclare Pierre Marque, Associé Deloitte responsable du programme Technology Fast 50 de Deloitte. « Nous félicitons chaleureusement Xebia d’être l’une des premières entreprises technologiques de croissance en France ».

Contacts

• Julia Debienne : Relations Presse Deloitte : + 33 (0)1 55 61 41 69 / jdebienne@deloitte.fr
• Benjamin Sasu : Agence Rumeur Publique : + 33 (0)1 55 74 52 37 / Benjamin.sas@rumeurpublique.fr

A propos du programme Technology Fast 50

Le programme Technology Fast 50 a vu le jour en 1995 à San Jose en Californie, cœur de la Silicon Valley, et a ensuite été étendu à tous les Etats-Unis puis au Royaume-Uni, au Canada, aux Pays-Bas, à Israël et à la France. Il est désormais présent dans plus de 50 pays et régions dans le monde. Il a été créé afin de mettre en valeur la remarquable contribution des entreprises technologiques à la croissance de l’économie.

A propos de Deloitte

Deloitte fait référence à un ou plusieurs cabinets membres de Deloitte Touche Tohmatsu Limited, société de droit anglais (« private company limited by guarantee »), et à son réseau de cabinets membres constitués en entités indépendantes et juridiquement distinctes. Pour en savoir plus sur la structure légale de Deloitte Touche Tohmatsu Limited et de ses cabinets membres, consulter www.deloitte.com/about. En France, Deloitte SA est le cabinet membre de Deloitte Touche Tohmatsu Limited, et les services professionnels sont rendus par ses filiales et ses affiliés.
Deloitte mobilise un ensemble de compétences diversifiées pour répondre aux enjeux de ses clients, de toutes tailles et de tous secteurs – des grandes entreprises multinationales aux microentreprises locales, en passant par les entreprises moyennes. Fort de l’expertise de ses 6 500 collaborateurs et associés, Deloitte en France est un acteur de référence en audit et risk services, consulting, financial advisory, juridique & fiscal et expertise comptable, dans le cadre d’une offre pluridisciplinaire et de principes d’action en phase avec les exigences de notre environnement.