Publié par

Il y a 12 ans -

Temps de lecture 7 minutes

Revue de Presse Xebia

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

Actualité éditeurs / SSII

Agilité

Le coin de la technique


Actualité éditeurs / SSII

Rachat BEA/Oracle

Il fallait s’en douter, certains membres du board de BEA SYSTEMS se déclarent publiquement favorables à la fusion. A notre humble avis, ce n’est qu’une question de temps.
Carl Icahn, le plus gros actionnaire de BEA juge « fou » de rejeter l’offre d’Oracle, même s’il juge le prix de 17$ trop bas.

Lire l’article

Trimestriels de Microsoft: des records sont battus sur fond de 30ème anniversaire

Microsoft a fêté ses 30 ans le 22 Octobre et a pré annoncé ses résultats le 25 Octobre.
13,78 Milliards de $ de CA sur Q1 et une croissance du résultat de 23%, rien que ça!
Ce n’est pas la stratégie Web de Microsoft qui a sous tendu ces résultats, comme semblait le dire en filigrane Steve Balmer à la soirée anniversaire, mais bien l’arrivée de Vista qui a dopé les résultats.
A souligner l’amende record et l’accord signé avec l’Europe pour ouvrir Windows.
Enfin, la prise de participation de Microsoft dans FaceBook est un signe que les réseaux sociaux sont sous les feux de la rampe en ce moment. FaceBook est sans doute un des sites les plus consultés sur le web actuellement et pour information, le site est développé en PHP.

Lire l’article d’annonce des résultats
Lire le communiqué de Microsoft sur FaceBook

Agilité

Jeff Sutherland on Scrum and Not-Scrum

Une nouvelle interview de Jeff Sutherland, le co-auteur de Scrum, est disponible sur InfoQ. On y apprend notamment que Jeff estime aujourd’hui à 120 000 (!) le nombre d’équipes Scrum. Mais parmi ces équipes, quelles sont celles qui pratiquent réellement du développement agile ? Quelles sont celles qui ne font qu’appliquer un processus itératif ?
Pour répondre à cette question, Jeff utilise le (bientôt fameux) test de Nokia.
Selon Jeff, Nokia dispose sans doute de plus de ScrumMasters que n’importe quelle autre organisation – en fait, la Finlande est le pays dans lequel on trouve en proportion le plus de ScrumMasters au monde, principalement à cause de Nokia – et utilise quelques idées simples pour déterminer si une équipe utilise Scrum ou non.

Selon Nokia, vous ne faites pas de développement itératif et incrémental si :

  • Les itérations ne sont pas limitées dans le temps ou durent plus de 6 semaines.
  • Les itérations ne produisent pas un logiciel pleinement fonctionnel.
  • L’équipe attend que les spécifications soit parfaitement détaillées pour démarrer une itération.
  • Les itérations n’incluent pas de tests d’acceptance utilisateur durant le développement.

En général, la moitié des équipes que Jeff rencontre sont « éliminées » par ces 4 points avant même de passer aux points Scrum.

Toujours selon Nokia, vous savez que vous n’appliquez pas Scrum quand :

  • L’équipe ne dispose pas d’un product owner clairement identifié.
  • L’équipe dispose d’un product owner mais pas d’un backlog de produit (une liste de fonctionnalités à implémenter) dans lequel les éléments sont priorisés et estimés.
  • Durant le développement, vous ne disposez pas d’un graphique de burndown faisant apparaître le reste à faire de l’itération et permettant de mesurer la vélocité de l’équipe.
  • Un manager interfère dans le travail de l’équipe durant une itération.

Pour les détails, nous ne pouvons que vous inviter à vous reporter à l’interview. Bon visionnage.

The future of software development

Cet article présente l’évolution des modes de développement des projets. Ainsi l’auteur décrit le Waterfall Model qui passait par les étapes suivantes :

  • analyse des besoins
  • définition de l’architecture
  • implémentation
  • test

Au fur et à mesure des échecs, et de l’apparition de nouveaux outils, cette approche s’est révélée trop linéaire et rigide. Les maîtrises d’ouvrage pensaient pouvoir spécifier tout le logiciel au début du projet sans qu’aucune modification ne soit nécessaire par la suite. Nous savons pourtant tous que les besoins évoluent constamment…

En revanche les méthodes agiles permettent en permanence de réaligner le développement d’un projet avec les besoins des clients.

L’erreur principale du Waterfall Model était de croire qu’il était possible de définir un système du premier coup… Les méthodes agiles se concentrent sur le fait que les besoins d’aujourd’hui ne seront pas forcément les mêmes demain et que les changements doivent être appliqués rapidement.

Voici quelques principes du développement agile :

  • simplicité
  • faire face aux changements rapidement
  • communication
  • effectuer des releases règulièrement, démonstrations aux clients
  • test

Enfin l’auteur termine sur le fait que pour mener à bien un projet, ce n’est pas forcément le nombre de développeurs qui compte, mais la qualité et la motivation de ceux-ci, car avec les technologies dont nous disposons (langages de programmation, méthodes agiles…) il est possible d’arriver à mener des projets avec grand succès !

Le coin de la technique

Introduction à SpringFramework 2.5

Rod Johnson profite de la sortie de la version 2.5 de SpringFramework pour nous rappeler pourquoi SpringFramework est né : sa philosophie, les bénéfices qu’il apporte. Il fait aussi le tour des grandes fonctionnalités du framework à travers quelques exemples.

On retrouve dans Spring 2.5 les grandes tendances de la programmation Java :

  • Réduction et simplification des configurations XML
    • Java Config : il est désormais possible de configurer Spring sans XML ! Ceci grâce aux annotations comme @Configuration et @Bean qui permettent de remplacer respectivement les tags <beans/> et <bean/>
    • XML namespaces « jms » et « context » : Spring 2.0 avait introduit l’extension de configuration avec un certain nombre de namespaces (jee, aop, tx, etc) ; 2 nouveaux éléments viennent s’ajouter à la liste :
      • context : tags liés à la configuration du contexte comme <context:component-scan/> qui scanne le classpath pour détecter les beans Spring grâce aux annotations. Ou accessoirement <context:property-placeholder/> qui remplace l’ancien bean PropertyPlaceholderConfigurer
      • jms : permet de définir avec simplicité des message listeners (équivalents aux MessageListenerAdapter) et des listener containers :
        
        
    • Ce ne sont pas les seuls moyens de configurer Spring. Les différentes solutions de configuration sont décrites dans cette très bonne présentation de Costin Leau: Ways to configure the Spring container extraite du SpringOne’07
  • Componentisation avec OSGI : cet aspect concernera surtout les éditeurs de middleware/logiciels qui utilisent Spring. Après Eclipse et Websphere, la componentisation avec des bundles osgi se répand : Mule, ServiceMix, Websphere MQ client, …
  • Unification des accès aux systemes externes avec JCA 1.5 : Billy Newport prévoyait dès 2003 que JCA 1.5 unifierait l’accès aux ressources externes (JDBC, JMS, CCI). Spring 2.5 apporte la gestion unifiée des MessageListeners JMS et CCI (CICS, IMS, etc) grâce à un JCA 1.5 message endpoint managementOn retrouve notamment l’unification JCA/JMS dans Websphere et dans ActiveMQ
  • Support officiel de Websphere, fruit de la collaboration d’Interface21 avec le lab d’IBM Hursley, avec notamment l’introduction du WebSphereUowTransactionManager

Choisir un framework web Java

Matt Raible partage une de ses présentations récentes sur les frameworks web. Il présente plusieurs retours d’expérience de lecteurs de son blog, ayant utilisé/testé les différents frameworks, c’est un bon complément à notre récent concours de développement.
En vrac (sans accorder une confiance aveugle à ces commentaires, ils donnent tout de même une bonne idée générale…):

  • Wicket vs JSF: 6 jours pour développer l’UI avec JSF, 6 heures avec Wicket
  • Stripes vs Struts 1: au revoir Struts 1…
  • Grails vs Struts 1 ou Spring MVC: excellente productivité avec Grails
  • Tapestry 5 vs JSF: excellent retour sur Tapestry, JSF trop complexe, trop lourd
  • Tapestry 5 vs Wicket: Wicket impressionne, mais demande un temps d’adaptation

Ses conclusions:

  • C’est la guerre de l’après Struts1, et la compétition entre les frameworks a du bon!
  • Il vaut mieux éviter, pour le moment, de se spécialiser dans un seul framework comme à l’époque de Struts1, il n’y a pas encore de vainqueur
  • Ne croyez pas forcément ce qu’écrivent les experts, ces frameworks évoluent et se corrigent rapidement (à part JSF peut être ), testez par vous même!

A noter que Matt Raible reste parfaitement objectif, alors qu’il vient de rejoindre fin Septembre 2007 l’équipe de commiteurs Struts2.

Publié par

Publié par Xebia France

Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 15 ans, nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Commentaire

Laisser un commentaire

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

Nous recrutons

Être un Xebian, 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.