Il y a 15 ans -
Temps de lecture 8 minutes
Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Agilité
RIA
SOA
Le coin de la technique
- Bonne utilisation des generics
- Websphere MQ v7 : un bouleversement discret appelé message properties
Actualité éditeurs / SSII
Fusion BEA / Oracle : présentation de la stratégie par Oracle
Le 1er juillet 2008 a été annoncée la stratégie d’intégration des offres BEA par Oracle. Thomas Kurian, patron du middleware chez Oracle, a notamment annoncé que les produits Weblogic et Tuxedo seront intégrés tel que à l’offre Oracle. Quant aux ESB et aux outils de développement d’Oracle et BEA, ils fusionnent.
Plus de détails sur la nouvelle offre Oracle :
Agilité
Techniques d’estimation des user stories
Jay Fields, consultant chez ThoughtWorks, présente différentes astuces pour estimer les user stories. Nous retiendrons :
- Utilisez 4 valeurs, des puissances de 2 : 1, 2, 4, 8. De manière générale, un nombre de choix réduit simplifie le vote et les valeurs qui s’éloignent de plus en plus évitent une fausse précision. La suite de Fibonacci fonctionne très bien aussi.
- Votez indépendamment les uns des autres. Des techniques simples comme le jeu pierre-feuille-ciseaux ou le planning poker permettent de voter simultanément sans être influencé par les autres.
- Les réunions d’estimation sont rarement un plaisir, motivez l’équipe avec des croissants par exemple !
Les déboires de Google avec Scrum
Jeff Sutherland revient dans cette présentation sur la première implémentation de Scrum chez Google.
En 2001, Google avait de gros problèmes pour tenir ses deadlines. Ils ont commencé à introduire Scrum en utilisant les backlogs et les burndown charts, puis les daily scrums. Pourtant les livraisons continuaient de prendre du retard. Après investigations, ils se sont aperçus que beaucoup de tâches étaient « en cours » en même temps. La principale leçon à retenir est de ne pas se disperser sur trop de tâches, l’équipe doit se focaliser sur le minimum de tâches possible jusqu’à ce qu’elles soient complètement terminées.
RIA
Le contenu Flash / Flex indexable
InfoQ rapporte une avancée majeure pour Adobe : le contenu des applications Flash (et donc Flex) est dorénavant indexable par les principaux moteurs de recherche que sont Google et Yahoo.
Avec un avantage non négligeable sur Ajax, à savoir que le contenu dynamique, récupéré du serveur est lui aussi indexé.
Le principe de fonctionnement est original : Adobe fournit à Yahoo et Google un lecteur Flash spécial, optimisé, qui parcourt tout le fichier SWF à la manière d’un utilisateur : instanciation des différents états de l’application, récupération des données dynamiques…
Aucune intervention des développeurs n’est nécessaire, aussi bien sur les nouvelles applications que sur les anciennes.
Certaines fonctionnalités de Flex 3, comme le « deep linking » (historique au sein du fichier SWF, bookmark intra-Flash) ne sont pas encore implémentées.
Un frein (le principal ?) au développement des RIA Flash vient d’être levé.
SOA
REST anti patterns
Stefan Tilkov, éditeur de la communauté InfoQ SOA, présente ses REST Anti Patterns :
- Utiliser uniquement des requêtes GET ou uniquement des requêtes POST : REST utilise la sémantique HTTP avec GET pour les lectures, PUT & DELETE pour les écritures indempotente avec ID et enfin POST pour le reste mais qui est à éviter.
- Ignorer les mécanismes de cache : le code retour HTTP
304 Not Modifiedet ses headers associésETag,Expirespermettent une grande souplesse de mise en cache par les clients et les proxies pour offrir une très grande tenue à la charge. - Ignorer les codes retour HTTP : les codes retour HTTP sont très expressifs (
201 Created,406 Not Acceptable,412 Precondition Failed, etc) ; se limiter aux inexpressifs200 OKet500 Internal Server Errornuit à l’auto-documentation. - Mal utiliser les cookies : REST est par essence sans état ; si les cookies peuvent maintenir des informations stateless comme l’authentification, ils ne doivent en revanche pas porter d’information stateful ou métier (id, etc).
- Oublier l’hypermedia : les hyperliens sont à REST ce que sont les clefs étrangères aux base de données relationnelles. On notera toutefois que l’utilisation d’hyperliens est aujourd’hui très délicate ; xlink reste confidentiel pour XML et les équivalents en JSON ou YAML restent à trouver.
- Ignorer les types MIME : chaque utilisateur a son format de prédilection et se limiter à un seul format limiterait les opportunités de ré-utilisation. On retiendra XML pour java / .Net, JSON pour javascript, YAML pour Ruby et HTML pour les humains.
- Casser l’auto-description : idéalement, tout message devrait contenir suffisamment d’information (headers, format, etc) pour qu’un client générique puisse le traiter. Toute invention de header, protocole ou format nuit très fortement à l’utilisabilité de la ressource.
Le coin de la technique
Bonne utilisation des generics
Introduits lors du jdk 5, les génériques sont maintenant utilisés dans la plupart des applications Java. Les développeurs, aussi bien débutants qu’expérimentés, ont dans l’ensemble bien compris leurs avantages. Ces ‘marqueurs’ permettant de détecter les problèmes de cast dès la compilation ce qui facilitent indéniablement la lecture et l’auto-documentation du code.
Si l’utilisation des génériques est relativement simple à comprendre, cela se complique lorsque vous vous essayez à créer votre propre API. En particulier, l’utilisation des wildcard n’est pas triviale. Qui ne s’est jamais tiré les cheveux pour se demander quand mettre un wildcard. 3 ans après la sortie du jdk 5, êtes-vous familiers avec les formes suivantes ? MyBox<?>, MyBox<? extends T>, MyBox<? super T>
Brian Goetz, l’auteur du bien connu Java Concurrency In Practice revient sur ces notions peu évidentes (cf. le lien en fin d’article). Pour illustrer cette difficulté, il prend l’exemple de la classe AbstractExecutorService introduite lors du jdk 5 dont la signature a été modifiée au jdk 6 : personne n’est à l’abri d’une erreur.
Bonnes pratiques à respecter pour l’utilisation d’une API utilisant les génériques
- Préférez l’utilisation des génériques (
List<String>) aux types raw traditionnels (List) - Proscrire les types raw dans du nouveau code
- Eliminez et documentez les warnings ‘unchecked’ en utilisant l’annotation suivante
@SuppressWarnings("unchecked")en essayant de minimiser sa portée. - Privilégiez l’utilisation des listes (
List<String>) aux tableaux (String[]), lorsque le contexte le permet. En effet, les tableaux sont covariants : contrairement aux génériques. (Si une classe A étend B, B[] peut être casté en A[], alors que List<B> ne peut pas être casté en List<A>).
L’exemple ci-dessous, tiré du livre Effective Java, montre en quoi la covariance peut-être dangereuse.
// Lance ArrayStoreException au runtime Object[] testArray = new Long[1] ; testArray[0] = "Incompatible value"; // Ne compile pas List
Bonnes pratiques à respecter pour la création d’une API utilisant les génériques
- Utilisez les types paramétrés simples
Tlorsque c’est possible - Utilisez les wildcards pour rendre vos API plus flexibles
- Utilisez les wildcards lorsque que vous désirez passer un type paramétré en entrée d’une méthode (remplacer
MyBox<T>parMyBox< ? extends T>ou parMyBox<? super T>) - N’utilisez pas de wildcard dans les types de retours
Comment choisir le bon wildcard ? Le get-put principe.
- Méthodes de type GET : utilisez le ‘upper bounded wildcard’ (
MyBox< ? extends T>) sur les méthodes qui permettent de sortir des données de la structure courante. - Méthodes de type PUT : utilisez le ‘lower bounded wildcard’ (
MyBox< ? super T>) sur les méthodes qui font rentrer des données de la structure courante.
D’une manière générale, si l’utilisateur d’une API se pose la question d’utiliser un wildcard, c’est probablement que l’API a été mal pensée.
Au final, notons que si l’utilisation du wildcard extends est relativement répandu, force est de constater que le wildcard super ne se déniche pas encore à tous les coins de rue.
Consultez l’article de Brian Goetz : Going wild with generics » >Going wild with generics
Websphere MQ v7 : un bouleversement discret appelé message properties
Nous avions déjà évoqué les nouveautés de Websphere MQ V7 lors du lancement du programme de beta testing.
Notre attention s’était portée sur l’intégration du moteur de publish/subscribe et l’amélioration des performances et nous n’avions pas vu passer une évolution sur la structure même des messages. MQ v7 intègre le principe JMS de propriétés de message sous une forme beaucoup plus simple à utiliser que les anciens « RFH2 Folders » qui rebutaient certaines équipes non Java lorsqu’on leur proposait d’abandonner le format MQSTR pour bénéficier des propriétés JMS.
Ces nouveaux Message Properties, toujours transparents pour les développeurs JMS, se manipulent facilement pour les développeurs MQI grâce à l’introduction des verbes MQSETMP et MQINQMP. Un mode de compatibilité ascendante transforme ces nouveaux Message Properties en header MQRFH2 lorsqu’ils sont envoyés à d’anciens Queue Managers.
On notera par ailleurs que l’intégration native du mode publish/suscribe dans MQ simplifie l’utilisation de ce mode pour les développeurs MQI avec la création de nouveaux verbes (MQSUB, …) qui remplacent les fastidieux headers RFH2.
Avec ces deux simplifications majeures, l’utilisation de la richesse de JMS ne devrait plus susciter de réticences dans les équipes MQI.
Tous les détails dans Websphere Technical Exchange : What is new in WebSphere MQ Version 7 et Redbook (Draft) : WebSphere MQ V7.0 Features and Enhancements
Commentaire
5 réponses pour " Revue de Presse Xebia "
Published by Anne Onyme , Il y a 15 ans
« Une avancée majeure pour Adobe » : euh ca sert à quoi d’indexer des applis Flash ?
Indexer des datas contenus dans du Flash, je veux bien, mais l’appli elle meme ? Et pis qui utilise Flash comme format de contenu ?
Au final, je vois pas bien l’intérêt : Fausse Bonne Idée ou tendage de perches d’Adobe pour faire mousser Flash vs Silverlight (vu que MS a pas au droit à la faveur) vs Java Fx ?
Ou encore, jetage de ponts vers Apple pour séduire iPhone ?
Published by Pablo Lopez , Il y a 15 ans
Bonjour.
Il faut voir cette annonce dans le cadre de la percée des RIA comme interface avec le grand public.
Dans cette optique, les pages HTML deviendraient de simples conteneurs d’applications Flash / Flex, et les tags d’indexation qu’elles contiennent ne seraient plus du tout utilisés (d’où la nécessité d’indexer le contenu Flash en lui même)
Un exemple pour illustrer mon propos :
Le site du constructeur de téléphones mobiles Sony Ericsson
L’ensemble des produits du constructeurs est présenté sous forme de catalogue Flex. Il y a bien sur une vraie pertinence à indexer le contenu de ce catalogue. Et il est souhaitable que tout nouveau modèle, saisi (on l’imagine) dans une interface d’administration, soit indexé immédiatement, sans avoir à redéployer un page html contenant les tags d’indexation ad’hoc.
On a donc à faire à une vraie avancée pour Adobe dans le monde des RIA.
Nous ne souhaitons pas nous lancer dans une guerre de clochers Flex vs Silverlight vs JavaFx. D’autant plus que le contenu Silverlight semble lui aussi indexable, mais cette technologie est moins utilisée et donc moins médiatisée. Quand à JavaFx, nous y consacrerons une plus grande attention lorsque la version 1.0 sera sortie.
Pablo (Xebia)
Published by Anne Onyme , Il y a 15 ans
Non bien sûr, je ne voulais pas lancer de guerre de clochers…
L’illustration proposée est effectivement une explication.
Pour ma part, je suis un peu sceptique quand la pertinence de Flex / Silverlight / JavaFx) en tant que RIA, car ce sont des réponses « fermées », pour au moins les 2 points suivants:
1. Souvent pas d’accessibilité (ne serait-ce qu’augmenter la taille de la police, les Flashers/Flexers ayant souvent une facheuse tendance à écrire tout petit « pour faire design ». Le « classique » boutn droit / zoom avant n’étant pas adapté du tout.
2. Le classique (X)HTML/CSS/Javascript (quelquesoit les frameworks qui les encapsulent), bien que technologiquement plus vieux/ancrée, est quand même un standard ou une cert
Published by Anne Onyme , Il y a 15 ans
(oups ! Faute de frappe qui a validé l’envoi…)
Non bien sûr, je ne voulais pas lancer de guerre de clochers…
L’illustration proposée est effectivement une explication.
Pour ma part, je suis un peu sceptique quand la pertinence de Flex / Silverlight / JavaFx) en tant que RIA, car ce sont des réponses “fermées”, pour au moins les 2 points suivants:
1. Souvent pas d’accessibilité (ne serait-ce qu’augmenter la taille de la police, les Flashers/Flexers ayant souvent une facheuse tendance à écrire tout petit “pour faire design”. Le “classique” bouton droit / zoom avant n’étant pas vraiment une bonne réponse. Souvent pas de copier/coller non plus. On régresse beaucoup de ce côté là. Cela va sans doute évoluer (- j’espère!)… C’est aussi (surtout ?) ces points là qui ont démocratisé le web.
2. Le classique trio (X)HTML/CSS/Javascript (quelquesoit les frameworks qui les encapsulent), bien que technologiquement plus « poussiéreux », est quand même un standard ou une certaine compétitivité « force » un certain respect de ces standards (c.f. IE / Firefox / Opera / Safari). Avec en bonus l’aspect « sémantique » qui existe, bien que non finalisé (quoi que Google sous entend qu’un site HTML bien structuré est un gage de bonne indexation).
Dans cette optique, on peut légitimement se demander si l’apprentissage / l’appropriation d’un Flex / Silverlight ou JavaFx pour reconquérir l’interface web en vaut bien la peine, en tout cas, aujourd’hui. Même si Adobe a ouverts les specs du runtime, l’ubiquité du Flash (mobile devices…) reste à prouver en dehors du desktop (probable raison de la publication des specs). Je pense bien sûr à iPhone ou autre N95.
Enfin, il est « amusant » de constater comment Flash veut passer du monde webdesign/gadget graphique au monde plus rigoureux de l’entreprise avec Flex, pendant que Javascript lorgne de plus en plus vers l’aspect graphique après avoir gagné un peu de plus de noblesse en tant que vrai langage de programmation (si, si). Ex de petites prouesses graphiques : http://www.p01.org/releases/DHTML_contests/files/20lines_hypno_trip_down_the_fractal_rug/ ou http://labs.mozilla.com/2008/06/next-generation-javascripting/ (avec un DSL a la clé !))