1 juin 2010
Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
6 mai 2010
SBT (simple-build-tool) pour Scala
Maintenant que vous êtes tous convaincus par Scala, nous allons regarder durant les prochaines semaines quelques outils et frameworks indispensables pour démarrer nos projets d’entreprise. En effet, tout comme dans nos projets Java, il n’est plus envisageable au jour d’aujourd’hui de commencer un projet sans un environnement minimum : un bon IDE, un outil de build, de l’intégration continue, un outil de couverture de tests et bien d’autres. Leurs buts : nous faciliter le développement et nous avertir d’éventuels problèmes dans notre code (manque de tests, trop de warnings…).
Le sujet de cet article n’est autre que le framework Scala qui monte (très vite) en ce moment à savoir sbt (pour simple-build-tool). Nous verrons dans cet article ce qu’est sbt, ses différentes fonctionnalités et en quoi cet outil va nous être très utile dans nos développements quotidiens.
9 avril 2010
Premiers pas avec GreenPepper XWiki
Adepte de longue date de Fitnesse, j’ai toujours aimé l’aspect collaboratif du wiki permettant de sortir les tests du code et de les exposer à d’autres populations moins technique. Cependant, malgré le succès du projet et la grande communauté qui l’entoure, Fitnesse reste compliqué à mettre en place et certaines fonctionnalités de bases font cruellement défaut. De plus, le passage de Fit à Slim a fortement contribué à complexifier le projet.
Pour moi, Fitnesse est un projet passionnant et porteur de nombreuses innovations. Cependant, l’absence de structuration et le manque de documentation le rend très difficile à mettre en oeuvre et demande une réelle expérience. Je vous conseille tout de même de garder un oeil sur celui-ci, car, depuis l’année dernière, le projet est redevenu très dynamique (pas moins de sept releases) et semble gagner en maturité (je vous conseille notamment cet article sur les nouveautés).
J’ai plusieurs fois dans le passé eu l’occasion de voir des présentations de GreenPepper par les équipes de Pyxis. GreenPepper partage le même concept que Fit/Fitnesse mais a fait le choix de s’appuyer sur un Wiki existant robuste et mature : Confluence. Ce choix est un des gros atouts de GreenPepper, mais c’est aussi la raison qui m’a toujours fait écarter cette alternative. En effet, j’ai toujours trouvé difficile de promouvoir un logiciel en expliquant qu’il faudrait non pas acheter une mais deux licences (pour les entreprises non équipées en Confluence) et qu’il faudrait configurer et maintenir les deux logiciels.
Cependant, ce point de blocage a été adressé lors de la version 2.6 sortie en novembre 2009, qui permet désormais de pouvoir faire reposer GreenPepper sur XWiki qui est gratuit et open source.
Je vous propose donc de m’accompagner dans le test de cette nouvelle version au travers de cet article qui aborde :
- l’installation de GreenPepper et la configuration de XWiki,
- la création des premiers tests,
- la configuration de Maven et Eclipse pour GreenPepper,
- la création des fixtures,
- un petit retour d’expérience,
- mes espoirs pour le futur.
Avant de vous lancer dans la lecture de cet article, notez que celui-ci est purement technique et nullement philosophique. La présentation de l’ATDD (Acceptance Test Driven Development) ne sera pas abordée ici.
23 mars 2010
Maven et Android, comment utiliser le plugin ?
Si vous êtes développeur Android, vous aurez sans doute remarqué qu’aucun mécanisme ne permet de partager des ressources entre plusieurs projets. Étant l’auteur d’une petite dizaine d’applications, la gestion des ressources communes commence à devenir un véritable problème. En effet, s’il est très simple de partager du code Java par l’intermédiaire de jars, il vous est impossible de partager des images ou des layouts entre plusieurs applications. Ceci vient de la gestion même des ressources dans un projet Android et de leur utilisation. En effet chaque ressource est référencée sous la forme d’une constante dans un fichier ‘R.java’ automatiquement généré. C’est cette constante que vous devez utiliser pour utiliser vos différentes ressources dans vos applications. Comme il n’est pas possible d’inclure un projet Android dans un autre, nous somme bloqués.
Étonnamment, ce besoin ne semble pas intéresser plus que cela la communauté Android. En consultant la liste des demandes d’évolutions, seule une fiche fait référence à ce type de besoin. Cette demande me paraissant pourtant légitime, j’en ai discuté avec Romain Guy, l’un des développeurs Android. Selon lui, la plateforme Android ne permet pas de répondre directement à cette problématique. Tournons-nous donc vers nos outils de builds.
Cet article présente une manière de configurer un build Maven sur une application Android. Après la lecture de cet article, vous saurez comment construire et déployer un projet Android en utilisant Maven, mais également comment découper vos applications pour partager du code entre votre application Android et sa partie serveur, et comment partager du code et des ressources entre différentes applications Android. Le contenu de cet article est largement inspiré de la traduction officielle du chapitre Android du Maven Reference Guide que je viens tout juste de terminer.
1 mars 2010
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
8 février 2010
Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
13 janvier 2010
Comment séparer ses tests d’intégration ?
Une question récurrente pour les équipes qui commencent à industrialiser leur build avec du Maven et qui utilisent de manière intensive JUnit. Au bout d’un moment, les tests d’intégrations ralentissent de manière conséquente le build et parfois découragent les développeurs à cause de leurs pré-requis plus importants que les tests unitaires.
Comment les séparer des tests unitaires et comment éviter qu’ils soient lancés à chaque build Maven?
4 décembre 2009
Maven Definitive Guide FR, relecture finale
Les 19 chapitres de la traduction officielle du Maven Definitive Guide terminés, il est grand temps de nous lancer dans la dernière ligne droite avant la fin du projet : la relecture publique complète de la traduction. En tant que participant à ce projet, c’est avec un certain enjouement (ndlr : ouf, c’est fini !) que je relaie donc cet appel pour relire les 430 pages de ce guide. Je profite de cette occasion pour remercier les relecteurs de la première partie, et espère vous voir au moins aussi nombreux cette fois-ci. Notez que nous avons besoin de tout type de contributeur : vous lancer dans la relecture ne signifie pas forcément vous engager sur la relecture complète du livre.
Pour ceux que ça intéresserait, veuillez noter les points suivants :
- Les chapitres 1 à 8 (toute la première partie) ont déjà été relus fin septembre, privilégiez les suivants.
- Il est préférable de nous contacter avant de vous lancer dans la relecture, nous pourrons ainsi répartir uniformément les relectures et éviter les corrections parallèles.
- Privilégiez les versions HTML ou PDF pour la relecture.
Pour bien démarrer :
- Build journalier de la traduction ;
- Sources de la traduction sur notre projet GitHub ;
- Créez un compte sur github pour pouvoir nous soumettre vos retours via l’Issue Tracker et télécharger la version XML du docbook ;
N’hésitez pas à en parler autour de vous, que ce soit à l’oral, par mail, ou sur vos blogs 
Bonnes relectures.
27 novembre 2009
Maven Definitive Guide FR – chiffrez vos mots de passe
Pour en avoir parlé fin septembre, vous savez peut-être que je participe à la traduction française du Maven Definitive Guide. Comme vous pouvez le constater, la traduction est maintenant bien avancée, nous lancerons d’ailleurs probablement très bientôt les demandes de relecture de la seconde et dernière partie (vous en serez informé sur ce blog).
Je profite de cette occasion pour vous en présenter un extrait en prenant l’exemple d’une fonctionnalité que je ne connaissais pas avant de m’y atteler : comment chiffrer vos mots de passe dans vos Settings Maven.
27 novembre 2009
Devoxx – Jour 4 – Maven Reloaded
Jason van Zyl, le leader emblématique du projet Maven, était présent à Devoxx pour présenter les nouveautés à venir dans l’environnement Maven : Maven 3.0 et 3.1, finalisation de M2Eclipse, améliorations à venir sur Nexus ; le contenu était dense.
Il commence sa présentation en s’excusant pour la version 1.0 de Maven qui relevait de l’expérimentation et n’était pas destinée à une telle diffusion. La version 2.0 présentait quant à elle de nombreux défauts, il le reconnaît également. Il promet alors un outil mature et abouti avec Maven 3.0.
Le projet a stagné pendant plusieurs années ne laissant la place à aucune amélioration majeure. La complexité du code source de Maven, basé sur Plexus, un conteneur d’injection de dépendances qui lui est propre, en est pour partie la raison. Jason van Zyl explique ainsi que peu de développeurs contribuent au core du projet, en comparaison de la large communauté travaillant sur des plugins.
Cette stagnation liée aux défauts de Maven 2.0 a conduit à la création de nombreux projets alternatifs qui gagnent en popularité : Ivy, Gradle, Buildr, … A ce sujet, le leader du projet Maven voit cette concurrence comme bénéfique mais insiste sur le besoin de conserver une compatibilité entre les artefacts produits par l’ensemble de ces outils.