La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
Evénements de notre communauté en France et à l’étranger
Actualité éditeurs / SSII
Scala : la saga continue
Lors de notre précédente revue de presse nous vous avions parlé de l’article publié par Stephen Colbourne qui expliquait pourquoi il compare Scala aux EJB2. En réponse aux critiques qui l’accusaient de n’avoir pas assez utilisé Scala dans la vie réelle, il a publié un mail envoyé par Coda Hale (ingénieur infrastructure chez Yammer) à Donald Fischer (CEO de Typesafe) et Martin Odersky (créateur de Scala). Ce mail contient une série de critiques précises contre le langage (complexe, courbe d’apprentissage importante, forme idiomatique, outils de build immatures, incompatibilité des binaires entre versions majeures et des problèmes de performances de certaines formes fonctionnelles) qui ont amené Yammer à reconsidérer son utilisation.
Il s’avère ensuite que le mail est un échange privé dans lequel Coda Hale répondait à une demande de Typesafe sur les points d’amélioration possibles du langage, il avait été placé dans un gist de github pour relecture et s’est retrouvé partagé et repris par mégarde. Son contenu finit par être repris de façon générale.
Finalement, Yammer publie sa position officielle toujours par la plume de Coda Hale. Dans ce communiqué, il indique
- qu’ils suivent une philosophie très pragmatique, et qu’ils essayent de nombreux outils pour résoudre leurs problèmes.
- que tous les langages ont des défauts face aux types de problématiques rencontrées chez Yammer
- qu’ils ont construit plusieurs systèmes impressionnants avec Scala (gestion de centaines de milliers d’utilisateurs, de millions de recherches, etc avec des performance très élevées).
- que Scala est un langage encore jeune (il le compare à java 1.3) et qu’il est normal qu’il ait encore quelques bords à arrondir, que c’était justement le sens de la démarche de Typesafe.
En retrait de l’agitation, Martin Odersky adresse indirectement une partie des problèmes remontés lors de cette controverse dans un article publié sur le blog de Typesafe. Quelques points intéressants
- Support au développement avec l’annonce de la sortie en release candidate de scala IDE
- Courbe d’apprentissage réduite d’une part par l’IDE, par des sources gratuites dont un site de documentation collaboratif et pour le reste par des formations.
- Accélération du compilateur et soutient au travail accompli dans le compilateur incrémental de SBT.
- Community avec surtout le passage de Scala sous github
Il évoque également la performance, les frameworks (avec akka, et play2), les plans pour répondre aux problèmes de compatibilité binaire.
La bataille fait rage pour décider du langage qui remplacera Java sur la JVM, bataille qui ne manquera pas de s’amplifier avec les fonctionnalités annoncées pour Java 8 (Jigsaw, Lambda expressions, le reste du projet Coin, …) et l’arrivée de nouveaux challengers annoncés ces derniers temps (Kotlin et Ceylon)
VMWare, Cisco et Google jouent aux marionnettes
PuppetLabs, l’entreprise commerciale derrière l’outil Open source Puppet vient d’annoncer sur son blog que VMWare, Cisco et Google venaient de prendre des parts lors du dernier tour de table effectué par la société. En dehors du blabla marketing d’une telle annonce, il faut bien reconnaître que, comme elle le dit, ces partenaires utilisent déjà Puppet « en production et à grande échelle ». Et il est certain que cette association en jette !
En tout cas, il est certain que cette annonce se présente dans une dynamique très porteuse pour les outils de management de configuration. Avec le Cloud, la tendance à prendre en compte le Devops se confirme et c’est toute l’industrie qui va en bénéficier.
Rappelons que PuppetLabs édite aussi la solution commerciale Puppet Enterprise sortie il y a peu en version 2.0. Et pour ceux que ça intéresse, notons que ce récent article donne des pistes pour optimiser ses éditeurs texte et parle même de Geppetto, un IDE basé sur Eclipse pour Puppet.
Le coin de la technique
Hibernate et ses performances anti-patterns
Pour ceux qui n’ont pas encore vu cette présentation de Patrycja Wegrzynowic à Devoxx, Mathilde Lemée en reparle ici. Cet article détaillé revient avec des exemples précis sur des cas d’utilisation réel de l’outil. On y retrouve les exemples de N+1 SELECT, de problème de synchronisation en écriture et bien d’autres.
L’accroche de la présentation à Devoxx est simple « I do think Hibernate is a great tool ». De plus en plus de débats se lèvent sur l’utilisation de ce framework. Il est évertué par les uns pour son gain de productivité et son utilisation simple mais décrié par les autres pour les contraintes de modélisation qu’il entraîne et son côté opaque.
Lors de notre dernier XKE (Xebia Knowledge Exchange), nous avons eu la chance d’assister à une présentation de David Gageot sur la notion d’outil et de framework. Lors de cette session, il a codé sous nos yeux une application Web simple, sans utiliser de grand framework. L’idée était de nous amener à nous poser les bonnes questions face aux outils que nous utilisons tous les jours:
- En ai-je vraiment besoin ?
- A quoi sert-il vraiment ?
- Son utilisation m’amène-t-elle plus de valeurs ajoutées que de contraintes ?
L’idée directrice de David était de nous montrer que nous ne sommes pas obligés d’utiliser des outils très imposants pour des tâches très simples.
Un outil, à la différence d’un framework, n’imposera que peu de contraintes à son utilisateur. Il restreint son périmètre d’utilisation pour être « expert » dans une tâche bien précise. L’avantage cependant d’un framework est d’offrir des guides d’utilisation, afin d’assurer une homogénéité au sein de plusieurs projets.
Il faut savoir adapter l’outil à la tâche qui lui correspond. Mieux vaut utiliser des outils simples, non intrusifs pour faire correctement ce qui est demandé en se laissant la possibilité de changer plus tard.
De la même manière, Hibernate est un outil puissant, encore faut-il savoir l’utiliser correctement. Tous les cas d’utilisation n’en on pas l’utilité. Mais rappelons nous que si nous voulons l’introduire dans notre projet, apprenons d’abord à bien l’utiliser.Tout est une question d’adaptation. C’est le coeur de notre métier, comprendre le contexte pour lui apporter la meilleure réponse possible. La réponse universelle n’existe pas et c’est cela qui rend notre profession intéressante.
Gitblit : le nouveau gestionnaire de repositories Git
GitBlit est une application Web Open-Source (licence Apache Software Foundation version 2.0), reposant sur une stack pure Java, et qui a pour objectif de gérer, consulter et héberger des repositories Git. Il utilise pour cela JGit, une implémentation Java du gestionnaire de sources distribué.
L’application se présente sous deux modes :
- Gitblit GO : une solution clé en main basée sur Jetty. Il n’est pas nécessaire d’installer un quelconque serveur Web ou même Git lui-même, c’est l’option à privilégier si l’on veut démarrer le plus simplement et rapidement possible. L’objectif de ce mode est d’obtenir un serveur fonctionnel avec un minimum de configuration. En effet, un unique fichier texte permet de configurer le serveur et Gitblit. Aussi, un certificat pour communiquer via HTTPS est automatiquement généré pour localhost et un script permet d’en générer un pour n’importe quel hostname.
- Gitblit WAR : si vous utilisez déjà un conteneur de servlets où vous déployer vos différents outils, le mode WAR est à privilégier. Les versions 6, 7 et 8 de Jetty ainsi que les versions 6 et 7 de Tomcat sont supportées. De manière générale, n’importe quelle implémentation de Servlet 2.5 ou 3.0 devrait fonctionner.
Gitblit peut être utiliser de différentes manières :
- Comme une simple IHM Web (inspirée de Gitweb) pour consulter les repositories Git sans accès administrateur ou ou gestion de comptes utilisateurs.
- Comme une stack Git complète pour cloner, « pusher » et contrôler l’accès aux repositories.
- Gitblit peut être utiliser sans aucun outil relatif à Git (dont Git lui-même) ou il peut collaborer avec vos outils existants.
Les administrateurs peuvent gérer les repos et comptes utilisateurs soit via l’IHM Web, soit via une interface JSON RPC accessible depuis le Gitblit Manager (une IHM Swing pour gérer les repos Git et administrer un serveur Gitblit de manière distante) ou depuis un outil custom.
L’application requière au minimum un JRE/JDK 6.
Evénements de notre communauté en France et à l’étranger
L’Apache Software Foundation et Subversion
Ben Collins-Sussman, fondateur du projet Subversion et membre actuelle de l’Apache Software Foundation, vient donner son point de vue sur un débat qui fait rage : Pourquoi l’ASF choisit encore Subversion comme gestionnaire de source ?
La première réponse apportée par Jim Jagielski, un des leaders de l’ASF, est de garantir l’intégrité des projets sur le long terme et ne pas céder aux dernières modes. Ben Collins-Sussman pense lui que l’ASF est aussi présente pour fournir des protections légales face à l’utilisation des outils et d’assurer une cohérence aux long-termes et non seulement sur le software mais aussi sur les membres de la communauté.
Pour lui ce dernier point est assuré au sein de la fondation avec ces quelques mots « community over code ». Les réponses apportées aux différents problèmes des projets se font par consensus et système de vote au sein des projets.
Cet esprit de communauté et de protection légale est la raison pour laquelle Ben Collins-Sussman défend l’idée que les projets Apache doivent joindre le Grand Repository Subersion d’Apache. Mais l’utilisation de ce dépôt de source ne doit en aucun cas être unique. Certains projets pourraient selon lui utiliser Git et déposer de façon automatisée les sources au sein du Subversion d’Apache une fois par jour.
Pour reprendre le titre de son article, entrer dans une communauté, ce n’est pas être forcé d’utiliser tous ses outils.
En vrac
Sortie de Lucene 3.5.0 réduisant entre autre de façon significative la consommation mémoire lors de l’ouverture d’un IndexReader.
Sortie de ElasticSearch 0.18.5 comprenant des corrections de bugs mais surtout reprenant Lucene 3.5.0.
Sortie de Solr 3.5.0 reprenant également Lucene 3.5.0.
Sortie de SpringSource Tool Suite 2.8.1 dont le but principal est de réduire les couts de migrations de m2eclipse à m2e. Il y a d’ailleurs une FAQ intéressante sur m2e fournie par SpringSource (elle est bien sûr applicable aux utilisateurs d’Eclipse version « normale »).