Revue de Presse Xebia

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

• Le programme partiel du Scrum Day 2012 est disponible (Par Gilles Mantel)

Le coin de la technique

• Retour d’expérience Selenium 2 (Par Jean Helou)
• Programmer, un jeu d’enfant (Par Olivier Michallat)
• Soyez plus efficace avec Scala grâce aux conseils de Twitter (Par François Sarradin)
• Les préfixes éditeurs des navigateurs web créent la tempête (Par Jean Helou)
• Bonne pratique pour les framework MVC Javascript (Par Xavier Bucchiotty)

Evènements de notre communauté en France et à l’étranger

• Presentation smells (Par Jean Helou)

Agilité

Le programme partiel du Scrum Day 2012 est disponible

Le Scrum Day est une conférence annuelle qui rassemble tous les amateurs de la méthode SCRUM, et plus largement de l’agilité, autour d’un programme s’adressant aux novices, aux experts, mais aussi aux sceptiques. Le prochain Scrum Day se déroulera à Paris le 27 Mars 2012 dans le centre de conférence CAP15 à Paris, un cadre prestigieux.

La semaine dernière, après un premier tour de votes, le French Scrum User Group a publié un ensemble de sessions qui sont déjà retenues au programme. Si cet aperçu vous séduit, n’hésitez pas à vous inscrire dès maintenant et à réserver dans votre agenda la date du 27 Mars. Les sessions déjà proposées et qui ne figurent pas à ce programme préliminaire sont encore en course pour compléter les créneaux restants.

Si vous vous sentez en verve pour restituer votre expérience de SCRUM, présenter un sujet d’expertise, ou animer un jeu, sachez également que l’appel à orateur est toujours ouvert, et ce jusqu’au 22 Février.

Le coin de la technique

Retour d’expérience Selenium 2

Un retour d’expérience sur la façon dont @cascrum et son équipe ont mis en place des tests selenium2 avec webdriver, selenium grid 2, page object pattern et testng. Le retour d’expérience, sous la forme d’une présentation qui parcours une sorte de mindmap, explore les différents problèmes rencontrés et propose des solutions ou des pistes de réflexion:

• Inutilité de l’IDE Selenium au delà de l’exploration initiale.
• La nécessité de séparer le test en 2 visions : testeur & développeur.
• L’importance de dissocier le test du jeu de données.
• La difficulté de définir la granularité d’un test.
• Les problèmes de performance.

La présentation est très facile à suivre, avec beaucoup d’éléments intéressants et des références vers des documentations plus détaillées, on regrettera seulement l’impossibilité de faire du copier-coller et l’absence apparente d’intégration dans des outils type FitNesse, Greenpepper, Jbehave, ou RobotFramework. Un retour d’expérience qui propose de bonnes pistes en tout cas.

Programmer, un jeu d’enfant

Il y a les développeurs qui ont dix ans d’expérience, et ceux qui ont dix ans tout court. Dans cette vidéo, un informaticien en herbe résout en direct un problème du projet Euler :

Même si certains doutent de la spontanéité de la présentation, elle reste sympathique, et l’auteur semble maîtriser les concepts qu’il utilise. Au passage, on y voit une mise en œuvre élégante des Streams en Scala.

(PS : merci à @samklr pour le lien)

Soyez plus efficace avec Scala grâce aux conseils de Twitter

Continuons sur notre lancée Scalaïenne. Dans un article dénommé Effective Scala, Marius Eriksen de Twitter Inc. nous propose d’améliorer notre façon d’écrire nos programmes Scala. Scala possède une expressivité plutôt large. On peut très bien résoudre un même problème en Scala par une approche objet, par une approche fonctionnelle, en utilisant le pattern matching, en jouant avec les monades ou en abusant de l’approche one-liner avec des sigles cabalistiques histoire de faire jaser les communautés environnantes (j’dis ça, j’dis rien). Ce que propose Marius Eriksen, ce n’est pas d’indiquer quand utiliser tel ou tel approche / paradigme / idiome. Ce que propose Marius, c’est de nous montrer un ensemble de bonnes pratiques que l’équipe Twitter utilise dans la mise en œuvre d’un système réparti de service permettant de gérer une forte volumétrie. Voici quelques morceaux choisis :

• Utilisez des noms dont la longueur est plus ou moins proportionnel à son scope (comme en Java en somme).
• Évitez toute utilisation abusive de set et get sur les accesseurs.
• Utilisez le jocker à partir de six noms importés du même package : import a.b.c._
• Éviter les accolades pour les expressions simples : def square(x: Int) = x * x
• Les implicit doivent être utilisés avec prudence.
• Les opérations sur les collections immuables doivent être covariantes et invariantes sur les collections muables.
• Préférez les collections immuables.
• Le fait de formuler vos problèmes en termes récursifs les simplifient. Bonus, si vous faites du récursif terminal : vous avez droit à une optimisation en Scala aussi performante qu’un while
• La liaison déstructurante (destructuring binding) sont intéressantes avec les tuples et les case classes : val Tweet(text, timestamp) = tweet
• N’hésitez pas à créer des traits minimalistes, pour assurer une meilleure orthogonalité de votre code.

Nous vous laissons lire le reste de l’article qui fourmille de riches conseils. Pour finir, je vous propose une petite réflexion que nous expose Marius dans son article : « La complexité est une taxe sur la sophistication — vous devez toujours vous assurer que son utilité excède son coût. » (Thus complexity is the tax of sophistication — you must always ensure that its utility exceeds its cost.)

Les préfixes éditeurs des navigateurs web créent la tempête

Les préfixes éditeurs (aussi appelés vendor prefixes) sont les préfixes de propriétés CSS non standardisées et dépendent du navigateur web utilisé. On retrouve, par exemple -moz- pour Mozilla, -webkit- pour WebKit ou encore -ms- pour Internet Explorer. Ces préfixes font beaucoup parler d’eux en ce moment tant ils font craindre le retour d’un navigateur dominant le web et ne respectant pas les standards. Explication.

Les préfixes permettent aux développeurs web d’accéder à des fonctionnalités CSS expérimentales non encore standardisées par le CSS Working Group, ce dernier étant connu pour prendre un certain temps avant de mettre à jour les standards du monde du web.

En décembre 2011, Safari et Chrome représentaient environ 30% du traffic européen des PC sur Internet. Ces deux navigateurs se basant sur le même moteur de navigation, à savoir WebKit, lequel est également au coeur des navigateurs intégrés à Android et à iOS. Ce moteur évolue aujourd’hui plus rapidement que les autres, et intègre un grand nombre de fonctionnalités expérimentales, en particulier dans le domaine du web mobile.

Les développeurs de sites, soumis à des contraintes concurrentielles extrêmes, tendent à utiliser de plus en plus de fonctionalités spécifiques à WebKit et préfixées par -webkit-. La situation est telle qu’un grand nombre de sites mobiles ne fonctionnent correctement qu’avec ce moteur. Malheureusement, les règles actuelles du Working Group indiquent que les navigateurs doivent implémenter les fonctionnalités non standardisées dans leur propre préfixe. Quand un site souhaite utiliser une fonctionnalité en cours de standardisation, ses développeurs devraient (en théorie) chercher tous les équivalents dans les différents préfixes et les ajouter tous à leur site. Très peu le font, se contentant souvent de mettre la fonctionnalité avec le préfixe -webkit- et rendant de facto leur site incompatible avec les autres navigateurs.

Dans un appel ouvert à la communauté, Daniel Glazman, co-président du CSS Working Group, a lancé l’alerte, indiquant que la spécialisation incompatible des sites ne doit pas se reproduire. Elle est déjà arrivée avec IE6 et le web a mis 10 ans pour s’en remettre. Si la situation ne change pas, certains éditeurs ont annoncé qu’ils arrêteraient de respecter les règles du Working Group, et dupliqueraient des fonctionalités très utilisées dans le préfixe -webkit- en implémentant eux aussi ce même préfixe, ce qui rendrait inutile la notion même de préfixe éditeur.

En réponse à l’alerte lancée par Daniel Glazman, Peter-Paul Koch, auteur du site Quirksmode célèbre pour sa table de compatibilité croisée entre les navigateurs web, a proposé de changer les règles du Working Group. Demander aux développeurs de sites et d’applications web de supporter le poids du système de préfixe actuel et de connaître tous les équivalents des navigateurs est un travail fastidieux et inutile. Sa première proposition, remplacer les préfixes éditeur par le préfixe -beta-, a été accueillie avec un bon nombre de commentaires dans la communauté. L’un de ces commentaires fait par @PhilippeAntoine, l’a amené à revoir sa proposition pour rajouter le préfixe -alpha- en plus de -beta-.

Le préfixe -alpha- servirait aux developpeurs des moteurs de navigation pour tester de nouvelles innovations, il n’y aurait aucune garantie de compatibilité. Après que les éditeurs aient atteint un consensus sur la syntaxe de la fonctionnalité, et l’aient présentée au processus de standardisation du Working Group, la fonctionnalité serait ajoutée au préfixe -beta-. Les fonctionnalités dans le préfixe -beta- pourraient être utilisées sans trop de risque par les développeurs web. Leurs implémentations n’étant pas complètement standardisées, les comportements pourraient être encore légèrement différents mais fonctionneraient.

La situation évolue encore et promet une saga riche en rebondissements !

Bonne pratique pour les framework MVC Javascript

Paul Hammant, célèbre architecte chez ThoughtWorks, nous propose dans blog la comparaison d’un large choix de framework MVC Javascript. Il se livre à une petite expérience avec ces frameworks. Il supprime tout simplement toutes les librairies javascript et charge la page principale. Il compare ensuite les résultats de rendu.
La bonne pratique mise en avant ici est de garder une page lisible, même sans framework activé. Nous comprenons vite l’intérêt de cette bonne pratique:

• pouvoir changer rapidement le template
• découpler réellement Modèle et Vue
• au final, être libre de changer à tout moment de framework de présentation à moindre coût

A la vue de ce test, on remarque trois grandes familles de framework:

• Angular et Knockout se basent sur l’ajout d’attributs dans le code HTML standard. Le code est aussi dans une balise SCRIPT standard, bien séparé du templating. Le code HTML est lisible et la séparation des concepts bien respectée.
• Pour Backbone.js ainsi que la majorité des autres framework, le code HTML est dans une balise SCRIPT. Il reste lisible mais ne s’affiche pas complètement. On pourrait tout aussi bien dire que le code de présentation n’a rien à faire dans une balise de type SCRIPT. Ces frameworks sont souvent plus léger et délègue le templating à un autre framework, à la discrétion du développeur.
• Certains comme Broke, ou ExtJS, intègre complètement le code HTML à générer dans le code Javascript. Il rend la lisibilité du code plus difficile et induit un fort couplage.

Si vous souhaitez avancer sur le sujet, n’hésitez pas à consulter l’article d’Yves Amsellem sur Backbone.js C’est sur notre blog et c’est ici.

Evènements de notre communauté en France et à l’étranger

Presentation smells

Vous êtes en train de préparer une présentation pour DevoxxFR ? pour les ScrumDays ? vous revoyez la présentation que vous avez donné aux TechDays ? Vous devez vendre la mise en place du continuous delivery à votre product owner et à sa hiérarchie demain ? Je vous conseille la lecture de l’article PresentationSmells par Martin Fowler. L’article en anglais liste quelques points connus et moins connus :

• Des phrases sur des slides aka Slideuments.
• L’invasion des marqueurs (logos, copyright, …).
• La répétition par pointeur (autant indiquer la répétition dans la diapo).
• Le retour en arrière.
• Le titre de diapo systématique.
  De même que les CodeSmells doivent vous alerter et vous amener a repenser le code que vous êtes en train d’écrire ou de relire, les PresentationsSmells sont les signes avant-coureurs de la distraction de votre audience. Une audience distraite ne vous écoute pas et rate l’essentiel de votre message, il faut donc l’éviter autant que possible.

Dans la foulée vous pouvez également lire l’article de Gojko Adzic présentant également ses trucs et astuces pour réussir une présentation en conférence. Comme souvent avec les articles de Gojko le ton est humoristique et l’article est étayé d’exemples.