La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
Actualité éditeurs / SSII
A vos radars!
ThoughtWorks vient de publier une nouvelle édition de son Technology Radar et, comme à chaque publication de ce désormais célèbre baromètre technologique, l’analyse conjoncturelle qu’y proposent Rebecca Parsons et Martin Fowler est souvent avant-gardiste, quelquefois controversée, mais ne laisse jamais indifférent.
Cette nouvelle mouture se situe nettement dans la mouvance du Software Craftsmanship avec pour maîtres-mots l’automatisation, la simplicité et la qualité.
En effet, quand on plonge dans le détail de l’analyse, on s’aperçoit que la tendance côté techniques est à l’automatisation. Les cultures prônant l’automatisation totale ou quasi-totale de la chaîne de build, jusqu’à la mise en production, sont l’objet d’un gain d’intérêt considérable, passant pour certaines d’entre elles du stade de Trial (à tester) à celui d’Adopt (à adopter): citons d’une part le concept de « Continuous Delivery » — véritable fer de lance de ThoughtWorks dont nous avions déjà fait l’écho ici-même — et d’autre part la culture » DevOps « , décidément de plus en plus en vogue.
Citons encore le concept de plus en plus répandu de infrastructure as code ou encore le concept novateur d’architecture évolutive (evolutionary architecture): il s’agit de promouvoir une architecture d’entreprise non pas chargée de prédire l’avenir mais constamment adaptée au besoin du moment; plutôt que de deviner comment un composant pourrait être réutilisé, il s’agit ici de prévoir son adaptabilité intrinsèque en favorisant un développement robuste, fondé sur les bonnes pratiques de code, les tests et l’intégration continue.
Côté performance et tests, ThoughtWorks estime que la problématique de la mise en cache des données et de son usage raisonné (thoughtful caching) est souvent négligée et reléguée au rang d’ajustement final, alors qu’il s’agirait d’un élément clé du succès d’une application. De même pour les tests de performance, qui gagneraient à être exécutés dès les phases initiales du projet et sur une base régulière; il n’est d’ailleurs pas nécessaire, pour cela, de faire appel à des frameworks lourds: un simple script peut suffire.
ThoughtWorks salue ensuite la maturité actuelle du développement mobile, en le faisant passer de Trial à Adopt. A l’aide d’outils comme jQuery Mobile et de Selenium (qui commence à se doter de quelques drivers pour mobiles), ainsi que des techniques comme le progressive enhancement (adaptation de l’application aux capacités du terminal mobile), il serait aujourd’hui aussi aisé de développer pour mobiles que pour des desktops. ThoughtWorks met en revanche en garde contre les kits de développement multi-plateformes qui engendreraient davantage de complexité qu’ils ne produisent de bénéfices.
En termes d’outils de développement, c’est sans doute Git et surtout GitHub qui sortent du lot, ce dernier passant d’un seul coup de Assess (à considérer) à Adopt. ThoughtWorks salue la rapidité et l’aisance de cet outil de contrôle de version, tout en récriminant contre des outils concurrents, comme ClearCase ou TFS, qui mettraient des freins à la productivité avec par exemple des contrôles de validité au moment du commit: décidément has been.
Parmi les langages de programmation, JRuby est à l’honneur: selon le radar, le couple Rails 3 + JRuby serait une « plateforme exceptionnelle » dont l’entreprise aurait tort de se priver. Clojure fait quant à lui son entrée dans le radar et se voit saluer une communauté vibrante et des librairies et outils toujours plus complets. Mais c’est HTML5 qui gagne en confiance en passant de Trial à Adopt, notamment grâce au stockage offline; selon ThoughtWorks, il s’agit d’un langage mûr malgré un standard encore sujet à évolution.
Un autre langage dont le radar vante les mérites est bien sûr JavaScript; mais ThoughtWorks met en garde contre un langage parfois trop puissant ou souvent mal maîtrisé, d’où la nécessité de le « cadrer » au travers d’outils de plus en plus répandus, comme Backbone.js (une implémentation du modèle MVC en JavaScript), ou même d’outils encore confidentiels, comme Coffeescript, un compilateur capable de compiler du « coffeescript » en javascript. (Nous nous permettons d’ailleurs d’ajouter à cette liste Require.js, un petit framework pour le chargement asynchrone de fichiers JavaScript.)
La simplicité et la facilité d’utilisation sont prônées un peu partout, notamment dans le domaine SOA, où REST et OAuth s’imposent face à SOAP et aux stacks WS-*; dans le domaine des frameworks web, où l’on voit Play! Framework prendre du galon au détriment de GWT ou des solutions de type portail, qui à force de masquer la complexité en finiraient par brider le développeur; ou encore lorsque ThoughtWorks sort le carton rouge pour les procédures stockées: trop lourdes, pas assez maintenables, elles ne seraient quasiment jamais une bonne solution.
Le cloud n’est pas oublié non plus et, d’une manière générale, le concept de PaaS (Platform as a Service) est à l’honneur: Amazon AWS passe au stade de Adopt tandis que Cloud Foundry fait son entrée dans le radar.
Enfin, la nécessité de métriques fiables et surtout consolidées et historisées de la qualité du code font enfin apparaître Sonar dans le radar: un comble!
Bref, on peut ne pas être d’accord sur tout, on peut mettre en doute l’impartialité du jugement, mais le Technology Radar reste une référence en matière d’analyse conjoncturelle et ses oracles sont de plus en plus suivis. Cette mouture ne préconise-t-elle pas d’ailleurs, assez ironiquement, que chaque entreprise conçoive son propre radar?
Le coin de la technique
Gaelyk v1.0: Google App Engine en Groovy
Guillaume Laforge, castcodeur émérite et surtout celui qui pousse le langage Groovy, nous apprend qu’il vient de sortir la version 1.0 de Gaelyk, son bébé. Démarré mi-2009, le framework se veut léger: il utilise la puissance de la syntaxe Groovy et tourne sur le cloud de Google. L’avantage, par rapport à Grails, est que Gaelyk est pensé des le départ pour tourner sur App Engine, alors que Grails y a souvent eu des problèmes. Bien sûr, on est limité à une version du Cloud, celui de Google, ce qui pose tout de même quelques limitations, mais il faut bien avouer que pour déployer rapidement une application Cloud bénéficiant de toute la puissance de Groovy (pour la syntaxe) et Java (pour les librairies), Gaelyk est très puissant.
La grosse nouveauté de cette version est sans conteste le tant attendu Query DSL qui permettra d’écrire des requêtes directement en Groovy. C’était vraiment la fonctionnalité qui était attendue depuis longtemps et permet au framework de combler le principal manque de manière à offrir une réelle uniformité.
Parmi les autres nouveautés, on notera l’ajout d’un fichier DSLD (descripteur utilisé par Eclipse pour permettre l’auto-complétion), des mises à jour des version de GAE et Groovy et quelques autres fix et ajouts, visibles sur le changelog.
A noter que Guillaume Laforge « eats his own dogfood » et cette release est l’occasion pour lui de migrer son propre blog sur Gaelyk. Il a annoncé qu’il utilisait pour cela un nouveau framework créé par ses soins pour l’occasion, Bloogaey, disponible pour tous sur Github.
Du coté de Grails, rappelons que la V2 se rapproche, nous vous avions annoncé la Milestone 1 la semaine dernière.
