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é

Actualité éditeurs / SSII

Vague de départs chez Sun/Oracle

Le rachat de Sun par Oracle constitue un changement de politique et d’identité majeur pour l’entreprise qui avait créé Java. On pouvait donc s’attendre à un certain nombre de départs de quelques personnes clé de Sun. Ces dernières semaines ont vu notamment les démissions de :

  • James Gosling : le créateur du langage Java. Après avoir passé 20 ans chez Sun, James Gosling quitte Sun/Oracle. Son départ a logiquement fait beaucoup de bruit au sein de la communauté Java.
  • Simon Phipps : le directeur de la stratégie Open Source de Sun. Il avait rejoint Sun 10 ans auparavant et était devenu Chief Open Source Officer il y a 5 ans.
  • Tim Bray : le co-rédacteur de la spécification XML et directeur des technologies Web chez Sun. Il rejoint Google dès à présent.

Ces départs retentissants, accompagnés de disparitions de produits et de changements de politiques, marquent bien la fin d’une époque…

Avec son OS4, Apple bride les développeurs

Apple a dévoilé la semaine dernière son nouvel OS, OS4, système d’exploitation destiné aux derniers iPhones, iPods et autres iPads. Nous ne reviendrons pas sur les nombreuses nouveautés techniques mais sur un simple paragraphe de la « iPhone Developer License Agreement » dont les termes ont depuis animé la blogosphère. L’ancienne version de ce document spécifiait que les développeurs devaient utiliser les API publiques de la manière prescrite par Apple et ne devaient pas utiliser d’appels à des API non publiées ou privées. Cette licence est maintenant beaucoup plus restrictive: elle spécifie explicitement que les applications devront être écrites en C, C++ ou Objective-C (voir Javascript à travers le Webkit d’origine). Tout programme destiné à être exécuté après une traduction ou se reposant sur une couche type machine virtuelle est interdit. La conséquence directe est que Flash, Java ou .Net se voient interdire l’accès à l’immense marché des applications iPhone.

La première question venant à l’esprit est « pourquoi ? ». Pourquoi se limiter alors que ces types de langages et technologies ont le vent en poupe ces temps ci et sont un fort moteur d’innovation. Une réponse apportée par Steve Jobs est que l’utilisation par les développeurs de couches intermédiaires produit des sous-applications non standard qui grèvent l’évolution de la plateforme.

En fait, selon John Gruber, Apple cherche à éviter à tout prix qu’une autre compagnie n’établisse ses propres outils comme un standard surtout si ceux ci permettent d’écrire un seul code et de l’exécuter indifféremment sur iPhone, Android ou Windows Mobile. Apple veut imposer sa plateforme de développement, que celle-ci devienne un standard, un passage obligé. Plus les développeurs seront familiers avec elle, plus ils développeront pour elle. De la même manière que Windows s’est imposé dans les années 90. Eviter le « write once, run anywhere », ca ne vous rappelle rien ?! Surtout que les applications iPhone représentent déjà la plus grosse part du gâteau des applications mobiles.

Les conséquences sont importantes. En premier lieu, l’avenir de Flash sur les machines de la Pomme semble compromis et de nombreux développeurs voient leurs efforts réduits à (presque) néant. Nous n’avons pas fini d’entendre parler de cette affaire et de débattre pour savoir si Apple préserve simplement la qualité de sa plateforme ou bien joue trop restrictif, ce qui, pour certains, n’est plus acceptable.

AWS s’enrichie d’un nouveau service de notification

Amazon enrichie son offre Cloud Computing AWS (Amazon Web Services) d’un nouveau service de notification. Baptisé Simple Notification Service (SNS), il permet à des systèmes externes de souscrire à un topic pour recevoir des notifications par SMTP, HTTP(S) ou Amazon SQS (Simple Queue Service). SNS vient donc en complément du service SQS existant puisque ce dernier était un broker de messages qui offrait une connectivité HTTP. SNS, quant à lui, se définit plutôt comme un publish-subscribe lié à une capacité d’intégration.

Ce type de traitement peut être effectué très simplement au sein des applications Java, par programmation. Tout l’intérêt de ce nouveau service est donc le même que pour la majorité des autres services de Cloud Computing offerts par Amazon : il s’agit d’un service clé en main pour lequel aucune tâche de déploiement, d’exploitation, et de planification de charge n’est requise. Le choix d’exploiter ce service peut alors être fait sur la base d’une projection de coût basé sur l’habituelle tarification linéaire d’AWS, tandis qu’en informatique traditionnelle ce choix aurait été basé sur les contraintes de mise en œuvre d’un middleware supplémentaire.

L’offre de Cloud Computing d’Amazon s’étoffe mois après mois avec l’arrivée de services supplémentaires, conférant ainsi à Amazon une position très confortable sur ce marché. Le Cloud Computing est un marché émergeant qui se cherche encore des standards. AWS, fort de son innovation régulière et de sa popularité pourrait s’octroyer une position de standard de facto telle celle gagnée par Spring. Le fait que le projet Eucalyptus – qui vise a offrir une solution de private cloud – soit basé sur les contrats des services d’AWS donne d’ailleurs un crédit supplémentaire à cette hypothèse.

Agilité

Maîtriser votre dette technique

La dette technique est généralement introduite à cause de raccourcis pris lors d’un développement pour tenter de gagner du temps, en lieu et place d’une conception propre, simple et évolutive. L’évolution et la maintenance de ce code se feront au prix d’efforts supplémentaires que l’on peut assimiler à des intérêts financiers.

Dans Monetizing the technical debt, Vikas Hazarati nous explique que la dette technique doit être maîtrisée faute de quoi, l’application risque de péricliter. En effet, au delà d’une certaine dette technique, la modification du code risque d’entraîner des comportements hasardeux (régressions) dans l’application. La diminution de la dette (capital) se fera en refactorant le code avant d’atteindre un niveau de dette trop élevé. L’article nous explique les bénéfices de monétiser notre dette technique et donne quelques éléments pour déterminer le niveau d’endettement (notamment via l’emploi d’un plugin Sonar).

La détermination d’un montant de dette technique pertinent semble difficile à mettre en œuvre et la détermination d’un seuil de maîtrise semble aussi particulièrement subjective. Le ressenti de l’équipe de développement sur le niveau (qualitatif) de la dette technique semble plus pertinent.

Comme l’explique Ward Cunningham, l’introduction d’une petite dette technique peut accélérer le développement à condition que celle-ci soit remboursée rapidement après sa souscription. Une bonne pratique pour vous aider à maîtriser votre dette technique est d’identifier le code à améliorer au moment où vous l’introduisez et de planifier les corrections nécessaires lors des itérations suivantes.

One Response

Laisser un commentaire