Tout est dans le titre,
Après des mois (des années) à attendre Maven "2.1", finalement renommé Maven 3, de nombreux (re)développements et une interminable suite de tests de non-régression, voici enfin venu le renouveau de Maven.
Quel changements pour l'utilisateur ? Aucun ou presque - à part un build plus rapide et moins consommateur de mémoire - car le premier objectif de Maven 3 est d'être compatible (à quelques détails près) avec son prédécesseur. Par contre, le socle technique est autrement plus propice à de futures évolutions, et à son intégration dans d'autres outils comme en témoignent polyglot, tycho, mvnShell ou m2eclipse, et les premiers plugins hudson maven3.
Le meilleur est à venir.
08 octobre 2010
Agile Tour 2010 : Rennes
Pour sa seconde édition Rennaise, l'Agile Tour remporte un énorme succès, avec 200 inscrits (le max) et de nombreuses propositions de sujets. Il faut reconnaître que pour 20€ (contribution casse-croûte) c'est un évènement à ne pas manquer !
Après l'introduction, les sessions se répartissaient dans 4 salles, dont deux orientées ateliers. J'ai eu le plaisir d'ouvrir le feu, avec un public nombreux et de bonnes questions : l'interaction du public sur cette conférence est très bonne.
Entre autres sessions, j'ai beaucoup aimé celle de Sébastien Tanguy "Scrum vs XP (charue et boeufs)". Sébastien y a souligné la grande popularité de Scrum, orienté rôle, communication et processus, et son absence de solutions pour les dérives qu'il permet de constater dans la dégradation de la vélocité. XP est donc un complément indispensable pour l'agilité, et la conférence a permis de faire le point sur 4 pratiques XP, le TDD, le refactoring, le pair-programming et l'intégration continue. Détail notable : Sébastien a fait le lien avec des sessions de l'Agile Tour 2009 et celles proposés sur cette édition - dont la mienne ;) - ce qui est un point très positif pour les choix éditoriaux des organisateurs. Les références incontournables à Uncle Bob n'ont pas manquées, même si Sébastien a choisi de se limiter aux plus softs.
Pages Jaunes faisait un retour d'expérience sur son passage au tout agile pour sortir d'un "Time To Market" bien trop long. Ils sont passés de 12 à 4 mois, avec 10 versions mises en production par an - excusez du peu. De leur propre aveux, leur approche est encore perfectible et il manque des briques importantes dans l'outillage du projet pour soutenir efficacement le processus. Le secret de leur succès : impliquer tous les maillons de la chaîne, avec une généralisation des KanBan de l'expression de besoin marketing à la phase de maintenance. Un sujet particulièrement pointé du doigt est la difficulté de marier maintenance et développement, soit avec une équipe dédiée, soit en intégrant des tâches de maintenance. Les deux approches ont des défauts significatifs qui va obliger pagesjaunes à expérimenter d'autres organisations.
J'ai aussi suivi l'atelier rétrospective pendant lequel je me suis retrouvé transformé en Renne gréviste du père noël. Ce format atelier est très intéressant pour comprendre les processus de travail en équipe et les techniques proposées par l'agilité. Dans le cadre de la rétrospective, comment amener chaque participant à identifier les éléments positifs et négatifs et à envisager ensemble des axes d'amélioration de l'équipe, loin des règlements de compte et du classement dans l'armoire IQ d'un bilan de projet "traditionnel".
J'ai aussi suivi une conférence plus "outil" sur la mise en place de tests d'acceptance avec Concordion. Mis en place sur un projet wrokflow délicat à valider avant la recette, et qui faisait l'objet de nombreuses versions correctives, il a fallu 6 mois de lobbying pour passer du premier PoC à la généralisation, mais le succès est au rendez-vous et l'outil s'est progressivement propagé dans d'autres domaines du SI. Si le coût de maintenance des tests et des "fixtures" n'est pas nié, il s'avère "linéaire" en fonction des évolutions fonctionnelle, ce qui est un avantage majeur par rapport à une approche plus bas-niveau à base de jUnit.
Sans compter toutes les autres sessions pour lesquelles je n'ai pas pris de notes ou que je n'ai pas pu suivre, l'AgileTour Rennes 2010 était donc une réussite incontestable, avec une excellente ambiance et de très bons échanges entre participants. Si vous avez raté cet évènement, il y a des dates programmés dans de nombreuses villes françaises dans les semaines à venir.
Après l'introduction, les sessions se répartissaient dans 4 salles, dont deux orientées ateliers. J'ai eu le plaisir d'ouvrir le feu, avec un public nombreux et de bonnes questions : l'interaction du public sur cette conférence est très bonne.
Entre autres sessions, j'ai beaucoup aimé celle de Sébastien Tanguy "Scrum vs XP (charue et boeufs)". Sébastien y a souligné la grande popularité de Scrum, orienté rôle, communication et processus, et son absence de solutions pour les dérives qu'il permet de constater dans la dégradation de la vélocité. XP est donc un complément indispensable pour l'agilité, et la conférence a permis de faire le point sur 4 pratiques XP, le TDD, le refactoring, le pair-programming et l'intégration continue. Détail notable : Sébastien a fait le lien avec des sessions de l'Agile Tour 2009 et celles proposés sur cette édition - dont la mienne ;) - ce qui est un point très positif pour les choix éditoriaux des organisateurs. Les références incontournables à Uncle Bob n'ont pas manquées, même si Sébastien a choisi de se limiter aux plus softs.
Pages Jaunes faisait un retour d'expérience sur son passage au tout agile pour sortir d'un "Time To Market" bien trop long. Ils sont passés de 12 à 4 mois, avec 10 versions mises en production par an - excusez du peu. De leur propre aveux, leur approche est encore perfectible et il manque des briques importantes dans l'outillage du projet pour soutenir efficacement le processus. Le secret de leur succès : impliquer tous les maillons de la chaîne, avec une généralisation des KanBan de l'expression de besoin marketing à la phase de maintenance. Un sujet particulièrement pointé du doigt est la difficulté de marier maintenance et développement, soit avec une équipe dédiée, soit en intégrant des tâches de maintenance. Les deux approches ont des défauts significatifs qui va obliger pagesjaunes à expérimenter d'autres organisations.
J'ai aussi suivi l'atelier rétrospective pendant lequel je me suis retrouvé transformé en Renne gréviste du père noël. Ce format atelier est très intéressant pour comprendre les processus de travail en équipe et les techniques proposées par l'agilité. Dans le cadre de la rétrospective, comment amener chaque participant à identifier les éléments positifs et négatifs et à envisager ensemble des axes d'amélioration de l'équipe, loin des règlements de compte et du classement dans l'armoire IQ d'un bilan de projet "traditionnel".
J'ai aussi suivi une conférence plus "outil" sur la mise en place de tests d'acceptance avec Concordion. Mis en place sur un projet wrokflow délicat à valider avant la recette, et qui faisait l'objet de nombreuses versions correctives, il a fallu 6 mois de lobbying pour passer du premier PoC à la généralisation, mais le succès est au rendez-vous et l'outil s'est progressivement propagé dans d'autres domaines du SI. Si le coût de maintenance des tests et des "fixtures" n'est pas nié, il s'avère "linéaire" en fonction des évolutions fonctionnelle, ce qui est un avantage majeur par rapport à une approche plus bas-niveau à base de jUnit.
Sans compter toutes les autres sessions pour lesquelles je n'ai pas pris de notes ou que je n'ai pas pu suivre, l'AgileTour Rennes 2010 était donc une réussite incontestable, avec une excellente ambiance et de très bons échanges entre participants. Si vous avez raté cet évènement, il y a des dates programmés dans de nombreuses villes françaises dans les semaines à venir.
05 octobre 2010
@Properties
Comme de bons petit soldats, nous avons appris à définir nos attributs de classe en private et à générer des getter/setter pour y accéder. Nos classes se trouvent ainsi encombrées de ces méthodes sans grand intérêt. Après tout, pourquoi ne pas laisser nos attributs publics ? Pour l'encapsulation vous répondra maître Yoda, en ayant la possibilité (s'il le faut un jour) d'intervenir lors d'un accès aux données de la classe. OK, mais c'est bien dommage de polluer ainsi notre code :'(
On peut bien sûr utiliser exceptionnellement une syntaxe compacte, mais encore faut-il que le formateur de code et les règles Checkstyle de votre Q&A soient réglées en conséquence.
Des langages comme Groovy ou Scala disposent nativement du concept de propriété, qui permet d'intercepter les accès aux données de la classe via un getter/setter, mais seulement quand c'est nécessaire. Pour Java 7, le projet Coin proposait d'ajouter le concept de propriété dans le langage Java. Le sujet a fait débat et je ne suis même pas sur du statut de cette proposition.
Cependant, pour ceux qui aiment bien cette idée, il y a une alternative à attendre cette fonctionnalité dans Java 7 (ou 8 ? ou 9 ?) : lombok
Lombok utilise un hack de l'annotation processor de Java 6 : il vient modifier la structure du code source (la structure AST, pas le fichier .java) pour ajouter des getter et setter à chaque attribut annoté en conséquence. Votre .class comporte donc bien ces méthodes et votre IDE vous laissera les utiliser, mais elles resteront absentes du code source, tant que vous n'avez pas besoin de les définir vous même. Lombok peut faire même beaucoup plus, comme générer equals(), hashcode() et toString(), ou gérer les exceptions ou la synchronisation par simple apposition d'une annotation (dites "méta-programmation", ça fait plus classe). Si cette dernière option peut faire peur - mais rappeler vous la première fois que vous avez fait du spring-aop avec @Transactional - l'utilisation sur les getter/setter justifie l'outil à elle seule.
A tester d'urgence : http://projectlombok.org
On peut bien sûr utiliser exceptionnellement une syntaxe compacte, mais encore faut-il que le formateur de code et les règles Checkstyle de votre Q&A soient réglées en conséquence.
Des langages comme Groovy ou Scala disposent nativement du concept de propriété, qui permet d'intercepter les accès aux données de la classe via un getter/setter, mais seulement quand c'est nécessaire. Pour Java 7, le projet Coin proposait d'ajouter le concept de propriété dans le langage Java. Le sujet a fait débat et je ne suis même pas sur du statut de cette proposition.
Cependant, pour ceux qui aiment bien cette idée, il y a une alternative à attendre cette fonctionnalité dans Java 7 (ou 8 ? ou 9 ?) : lombok
Lombok utilise un hack de l'annotation processor de Java 6 : il vient modifier la structure du code source (la structure AST, pas le fichier .java) pour ajouter des getter et setter à chaque attribut annoté en conséquence. Votre .class comporte donc bien ces méthodes et votre IDE vous laissera les utiliser, mais elles resteront absentes du code source, tant que vous n'avez pas besoin de les définir vous même. Lombok peut faire même beaucoup plus, comme générer equals(), hashcode() et toString(), ou gérer les exceptions ou la synchronisation par simple apposition d'une annotation (dites "méta-programmation", ça fait plus classe). Si cette dernière option peut faire peur - mais rappeler vous la première fois que vous avez fait du spring-aop avec @Transactional - l'utilisation sur les getter/setter justifie l'outil à elle seule.
A tester d'urgence : http://projectlombok.org
04 octobre 2010
Mangez des pommes !
Premiers retours sur ma migration sous Mac ...
Le hard
La machine est particulièrement bien finie, avec son habillage aluminium on est loin de certains PC en mauvais plastique. Le clavier typique, aux touches plates et carrées, rappelle celui du minitel, mais est pourtant très confortable. Par contre, les petits cachottiers d'Apple ont caché les touches utiles (pour un développeur) derrières des combinaisons : pas d'indication sur l'accolade "{" à moins d'avoir le petit guide du Mac-iste sous les yeux. Le pad est large et réactif, et on s'y fait très vite. Je le trouve par contre plutôt dur au clic, et je n'aime pas non plus le mode "frappe" pour cliquer.
L'OS
MacOS est basé sur un coeur FreeBSD, et a été fortement optimisé pour la plateforme 64 bits multi-coeurs. Je ne sais pas si c'est la seule explication, mais je constate que l'OS est très réactif et réparti très bien les ressources entre process. Je ne constate aucun de ces "gels" si fréquents sous Windows lorsqu'on lance une grosse appli (genre, un document Word :P ). L'installation d'application est simple comme bonjour (glisser, déposer), et a priori la désinstallation tout aussi triviale et propre. Je ne parle pas de l'esthétique qui est un élément pour lequel on connait le soin d'Apple.
Les applications
Le Mac est livré avec tout un tas d'applications de bonne facture, qu'on complétera avec quelques outils complémentaires selon le travail qu'on désire réaliser. Je regrette qu'iWork ne soit pas packagé. Il ne coûte que 79€ et serait un argument pour un système "tout compris", mais il n'y a pas de petit profit chez Apple, comme en témoigne le prix des accessoires, ou la sortie mini DisplayPort, qui oblige à acheter un adaptateur, alors qu'un port HDMI ou DVI ferait le job (mais nécessiterait à Appel de reverser 4cts par Mac !)
On s'habitue assez vite à la disposition du clavier et au pad (le passage régulier du Mac au PC est assez perturbant, on fait des trucs bizarres pendant quelques minutes). Pour ma part, je n'ai pas rencontré de problèmes insoluble, surtout avec l'aide du support en ligne 24/24 : @aheriter et @jollivetc !
Le côté obscur
MacOS est donc basé sur un socle Unix-BSD. C'est aussi ce qui en fait l'intérêt pour les développeurs ! Le passage de la barrière est cependant assez net. La console bash utilise les raccourcis propres à ce terminal, à savoir [Esc + B] pour revenir un mot en arrière. Ca rappelle l'apprentissage douloureux de VI, mais après tout c'est aussi un garde fou pour ceux qui ne devraient pas s'aventurer au delà de la partie graphique. Rassurez-vous, on peut définir ses propres combinaisons de touches pour améliorer la convivialité de cette console.
En conclusion, après quelques jours d'utilisation, je m'habitue bien à la bête et j'ai contourné les principales difficultés. Je ne suis pas encore aussi efficace que sous Windows et je me goure encore souvent de combinaisons de touches, mais ça vient vite. De là à savoir si ça justifie le tarif de ce jouet, je vous le dirait dans un prochain biller. Prochaine étape : intégrer le Mac dans mon environnement de travail (Exchange, Office Communicator, etc) et l'utiliser au quotidien...
Le hard
La machine est particulièrement bien finie, avec son habillage aluminium on est loin de certains PC en mauvais plastique. Le clavier typique, aux touches plates et carrées, rappelle celui du minitel, mais est pourtant très confortable. Par contre, les petits cachottiers d'Apple ont caché les touches utiles (pour un développeur) derrières des combinaisons : pas d'indication sur l'accolade "{" à moins d'avoir le petit guide du Mac-iste sous les yeux. Le pad est large et réactif, et on s'y fait très vite. Je le trouve par contre plutôt dur au clic, et je n'aime pas non plus le mode "frappe" pour cliquer.
L'OS
MacOS est basé sur un coeur FreeBSD, et a été fortement optimisé pour la plateforme 64 bits multi-coeurs. Je ne sais pas si c'est la seule explication, mais je constate que l'OS est très réactif et réparti très bien les ressources entre process. Je ne constate aucun de ces "gels" si fréquents sous Windows lorsqu'on lance une grosse appli (genre, un document Word :P ). L'installation d'application est simple comme bonjour (glisser, déposer), et a priori la désinstallation tout aussi triviale et propre. Je ne parle pas de l'esthétique qui est un élément pour lequel on connait le soin d'Apple.
Les applications
Le Mac est livré avec tout un tas d'applications de bonne facture, qu'on complétera avec quelques outils complémentaires selon le travail qu'on désire réaliser. Je regrette qu'iWork ne soit pas packagé. Il ne coûte que 79€ et serait un argument pour un système "tout compris", mais il n'y a pas de petit profit chez Apple, comme en témoigne le prix des accessoires, ou la sortie mini DisplayPort, qui oblige à acheter un adaptateur, alors qu'un port HDMI ou DVI ferait le job (mais nécessiterait à Appel de reverser 4cts par Mac !)
On s'habitue assez vite à la disposition du clavier et au pad (le passage régulier du Mac au PC est assez perturbant, on fait des trucs bizarres pendant quelques minutes). Pour ma part, je n'ai pas rencontré de problèmes insoluble, surtout avec l'aide du support en ligne 24/24 : @aheriter et @jollivetc !
Le côté obscur
MacOS est donc basé sur un socle Unix-BSD. C'est aussi ce qui en fait l'intérêt pour les développeurs ! Le passage de la barrière est cependant assez net. La console bash utilise les raccourcis propres à ce terminal, à savoir [Esc + B] pour revenir un mot en arrière. Ca rappelle l'apprentissage douloureux de VI, mais après tout c'est aussi un garde fou pour ceux qui ne devraient pas s'aventurer au delà de la partie graphique. Rassurez-vous, on peut définir ses propres combinaisons de touches pour améliorer la convivialité de cette console.
En conclusion, après quelques jours d'utilisation, je m'habitue bien à la bête et j'ai contourné les principales difficultés. Je ne suis pas encore aussi efficace que sous Windows et je me goure encore souvent de combinaisons de touches, mais ça vient vite. De là à savoir si ça justifie le tarif de ce jouet, je vous le dirait dans un prochain biller. Prochaine étape : intégrer le Mac dans mon environnement de travail (Exchange, Office Communicator, etc) et l'utiliser au quotidien...
Inscription à :
Articles (Atom)
