Agile Back Craft

Il y a 14 ans -

Temps de lecture 11 minutes

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Agilité

RIA

SOA / Whatever

Le coin de la technique

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

Agilité

Conseils pour adopter le TDD

Mark Levison décrit sur InfoQ les difficultés rencontrées par les équipes qui essaient d’adopter le Test Driven Development (TDD). Il remarque que les formations classiques ne sont pas suffisantes : elles ne reflètent pas la complexité du monde réel et ne permettent pas assez de pratiquer.
Pour combler ces manques, il propose de combiner plusieurs éléments, voici les principaux :

  • Pair Programming quand un développeur est bloqué, même un débutant peut aider.
  • Coding Dojo pour explorer des problèmes simples en groupe.
  • Ateliers de lecture pendant lesquels un groupe discute d’un chapitre sur le TDD.
  • Le management doit supporter cet effort et relâcher la pression qui pèse sur les développeurs en montrant qu’il comprend que la transition au TDD ralentira l’équipe mais que la qualité gagnée en vaut la peine.

Cette stratégie vise à créer plus d’échanges et augmenter la collaboration autour du TDD. Il note également que les développeurs doivent être patients, fiers d’écrire du code propre et utiliser des outils de mesure de couverture des tests (Emma, Cobertura, NCover).

RIA

Flash vs Silverlight

Si vous avez aimé notre RIA Contest, vous allez aimer le blog Shine Draw (relayé par DotNetGuru).

L’auteur (Terence Tsang) s’amuse à comparer Flash et Silverlight, exemples et codes sources à l’appui, les différents effets/animations/outils… que les 2 plateformes proposent. On pourra ainsi comparer le rendu graphique, la vitesse d’exécution, la difficulté du code et le temps de développement des exemples.

Les lecteurs du site pourront alors voter, pour chaque article / contest, si Flash ou Silverlight est le meilleur. On remarque entre autres que le jeu de course du célèbre plombier à moustache adapté à ces plateformes donne actuellement Silverlight vainqueur, tout comme la sauvegarde locale et même le player vidéo.

La grande majorité des articles du blog nous prouve ainsi, et par l’exemple, à quel point Silverlight devient de plus en plus mature et qu’il faudra aussi compter sur lui. La course aux meilleures technologies RIA ne se limitera donc pas à GWT et Flex !

SOA / Whatever

Crise 2009, les analystes tuent le temps (à défaut de la SOA)

Anne Thomas Manes, s’est fait son petit plaisir de début d’année en publiant lundi dernier, sur le blog « Application Platform » du Burton Group, un billet intitulé « SOA is Dead; Long Live Services« .
Elle y annonce la couleur d’entrée de jeux : « SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. ». En substance, alors que les SOAs étaient annoncées comme le paradigme d’architecture qui allait sauver les SI, elles ont en fait, après moult millions investis, empirées les choses (à quelques exceptions).
Les causes de ce fiasco ? D’après Anne Thomas Manes, pas les SOAs en tant que telles, rassurez vous. Si aujourd’hui, le métier ne croit plus aux promesses des SOAs, c’est avant tout un problème d’approche : Ceux qui ont compris que les SOAs n’étaient qu’un des outils du changement (changement organisationnel profond) ont profités d’un ROI énorme. Ouf !

Ce n’est donc pas aux funérailles des Architectures Orientées Services que le Burton Group nous convie en ce début d’années mais à celles de l’acronyme « SOA », dont nous avons oublié le sens premier.

Bien que cette annonce (savamment provocatrice) n’apporte rien de bien neuf, elle clôture admirablement 2008, l’annus horribilis de la SOA durant laquelle la blogosphère SOAiste est passée de la crise de doute à la désillusion.
Ce qui est sûr, c’est que le billet d’Anne Thomas Manes a rapidement fait le tour de la blogosphère des analystes SOA qui s’en sont donnés à cœur joie. Je vous laisse découvrir le compte rendu des premiers jours proposé par infoQ : « Is SOA Dead?«  qui reprend les réactions de David Linthicum, Joe McKendrick, Miko Matsumura et Steve Jones qui ont étés (comme souvent) les plus prompts à réagir.
Durant toute la semaine les réactions se sont multipliées.
On retiendra tout particulièrement la proposition de Miko Matsumura de suivre l’exemple de Prince et de parler désormais de « the architecture formerly known as SOA« .
A noter également le billet en français d’Olivier Rafal (« SOA mort ? Le terme, oui, pas les principes« ) qui rappelle, entre autre, à juste titre que le financement des initiatives SOA a toujours été un gros problème que la crise n’arrangera pas.

Beaucoup de bruit pour rien ? C’est l’avis de Jack Vaughan (« New year – same old SOA tempests?« ). Anne Thomas Manes s’en défend et revient sur les réactions que son billet a suscitées.
Cette effervescente semaine aura au moins eu le mérite de rappeler que les SOAs, telles qu’elles ont été abordées dans de nombreux cas, n’ont pas su convaincre (Ces échecs trouvent leurs sources dans de nombreuses causes).
L’année 2009 devra donc, plus que jamais, être l’occasion de rectifier le tir et d’aborder les questions de refonte des SI de façon pragmatique.

Rassurez-vous, ce que nous avions coutume d’appeler SOA est bien vivant !

Le coin de la technique

CAFÉ BABE : les .class vous parlent-ils ?

Un petit « café babe » ? Vous ne le saviez probablement pas, il s’agit du magic number présent au début de chaque .class et qui permet de les identifier. Au-delà de cette anecdote, si le format des fichiers .class vous intéresse, un tutorial a été publié cette semaine présentant rapidement les différentes parties composant ces fichiers. Il ne vous permettra probablement pas à lui seul de faire votre décompilateur mais peut servir de bon point de départ.

Les fichiers .class sont donc structurés comme ceci :

  • CAFE BABE : le magic number permettant d’identifier des fichiers .class. Il est directement suivi par 4 octets représentant les versions majeur et mineur du format utilisé.
  • Pool de constantes : Sont stockées dans cette zone toutes les constantes du fichier : nom de la classe, des interfaces, signature des méthodes, valeurs des champs déclarés avec le mot clé final.
  • Access Flag : description sur deux octets de la nature de l’objet (classe ou interface), de sa visibilité et de son accessibilité.
  • Classe courante et super classe : adresse sur deux octets permettant de récupérer le nom de la classe courante à partir du constant pool, directement suivi par un index représentant le nom de sa mère.
  • Interfaces : tableau d’index permettant de récupérer les noms des différentes interfaces implémentées par la classe décrite dans le fichier. Cette zone débute par un chiffre représentant le nombre d’éléments présents dans ce tableau.
  • Champs, méthodes et attributs : ces parties contiennent les dernières descriptions manquantes à la structure de la classe.

Guide d’optimisation de votre site Web

Dans une précédente édition de notre revue de presse, nous vous avons présenté des règles qui permettant d’améliorer les performances d’affichage d’une page Web. Ces règles étaient issues des bonnes pratiques Yahoo!.

Cette semaine, Ethan Gardner, Web designer, a publié sur son blog une série d’articles présentant des règles d’optimisations d’un site Web :

Il aborde notamment l’intégration de votre site Web avec les moteurs de recherche, voici quelques règles importantes :

  • Avoir un contenu explicite est important pour les utilisateurs du site Web mais aussi pour les moteurs de référencement :
    • Avoir des titres de page explicites et idéalement uniques.
    • Avoir des liens explicites : évitez des liens avec « Cliquez ici » préférez le nom de la page destination « Produit télévision HB6723 ».
  • Utiliser les balises meta, en particulier la balise meta description, qui permet d’améliorer grandement l’analyse de votre page par les moteurs de recherche, et c’est souvent le contenu de cette balise qui est affiché dans les résultats de recherche sous le titre de la page.
  • Utiliser le fichier robots.txt ainsi que sitemap.xml afin d’aider les robots des moteurs de recherche à indexer votre site. Ceci permet, par exemple, de limiter le contenu à analyser en excluant certaines pages, comme une url d’administration par exemple).
  • Avoir des bonnes pratiques de développements : conception, implémentation et test :

Il y a donc beaucoup de leviers pour l’amélioration des performances de votre site Web. Retrouvez l’intégralité des règles dans son PDF : Website Optimization Checklist.

Voici une liste d’outil pour vous aidez à la mise en oeuvre de ces règles :

Web Beans, un énième modèle de composant pour Java EE ?

Gaving King, responsable de JSR 299: Web Beans, revient dans une interview à InfoQ sur le contenu de cette spécification. JSR-299 se définit comme un palliatif à des limitations des EJB 3 qui rendent difficile leur intégration à JSF [1]. Nous soulèverons les interrogations suivantes :

  • Pourquoi les très récents EJB 3 (Mai 2006) ont-ils du mal à s’intégrer aux récents Java Server Faces (Mars 2004) alors que les concepts de Dependency Injections se sont généralisés en Java en 2003 / 2004 (cf. History of Inversion Of Control) et que Google Guice, Pico Container ou Spring Framework s’intègrent élégamment à la plupart des frameworks web (Struts 2, Spring MVC, Wicket, etc) ?
  • Pourquoi résoudre les problèmes d’intégration des EJB 3 aux JSF en créant une couche intermédiaire Web Beans plutôt qu’en améliorant les EJB 3 ? Nous remarquerons à ce sujet que EJB 3.1 est une amélioration des EJB 3 pour faciliter leur utilisation, notamment avec les EJB Lite que l’on déploie dans le web container.
  • JSF est-il le seul framework qui a du mal à s’intégrer aux EJB 3 ? Y a-t-il d’autres champs d’applications de Web Beans ? Gaving King reconnait que Web Beans a un champ d’application beaucoup plus vaste que JSF et pense particulièrement aux frameworks web, aux moteurs de BPM, à JAX-RS et enfin, à tous les gens qui utilisent un framework d’injection de dépendances :-) Peut-on reformuler la formulation de Gaving King et y voir l’idée que Web Beans adresse tous les cas d’injection de dépendances et donc de cycle de vie de composants Java ?
  • Si Web Beans a un périmètre aussi vaste que de gérer le cycle de vie des composants Java, pourquoi s’appelle-t-il « Web » et pourquoi ne communique-t-il que sur le liant JSF-EJB ? Gaving King donne une dimension très politique à ce positionnement en disant « Well I’m not sure that Web Beans would have been politically viable if it had appeared to offer an alternative to EJB ». IBM avait exprimé son inquiétude de voir la création d’un nouveau modèle de composants Java lors du lancement de cette spécification.
  • Enfin, pourquoi les JSR de « cycle de vie des composants Java » (EJB, EJB Lite et Web Weans) se cantonnent-elles à la partie serveur et n’adressent-elles pas la partie cliente ? Les applications clientes (Swing, SWT, etc) ont elles aussi besoin de gérer le cycle de vie de leurs composants et la réponse se trouve aujourd’hui du côté de Spring, Guice ou Pico Container.

Au final, JSR 299 Web Beans peut être à court terme une source de confusion voire un frein pour les projets interessés par les EJB 3 en remplacement de frameworks à la Spring. A plus long terme, Web Beans ne laisse pas espérer l’émergence d’un standard unique d’assemblage des composants Java qui soit utilisable aussi bien côté client que côté serveur comme le font aujourd’hui Spring ou Guice … ou comme le propose OSGi, le challenger des standards Java ;-) .

Nous en saurons plus demain avec la présentation Java EE 6 d’Antonio Goncalves au Paris JUG.

[1] … the EJB component model still has some limitations: … The goal of this work is to enable EJB 3.0 components to be used…

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

Paris JUG

N’oubliez pas demain soir le Paris JUG qui se déroule dans les locaux de l’ISEP :

Published by

Publié par Publicis Sapient Engineering

Commentaire

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.

REJOIGNEZ-NOUS