Un push-to-deploy simple et gratuit pour votre frontend

Dans cet article, nous verrons ce qui a été mis en place pour le site http://www.bdx.io (une conférence pour les développeurs qui se tiendra sur Bordeaux en octobre ;-)) afin d’automatiser le déploiement d’un site statique, hébergé chez github, optimisé pour le web (pré-processing css, minification et concaténation, optimisation des images etc…) et ce, via un  simple commit Git.

Le principe de fonctionnement s’apparente un peu au fonctionnement d’heroku, à ceci près :

• Qu’il est déclenché automatiquement lors de l’apparition de nouveaux commits sur une branche de votre choix
• Qu’un processus d’optimisation des ressources statiques est appliqué en amont du déploiement

A travers cet article nous parlerons :

• De Github pages pour l’hébergement des ressources statiques du site
• De Yeoman qui nous servira à générer une ossature « clef en main » pour un site web optimisé
• D’un petit script sh maison permettant de pusher notre site web optimisé sur une branche de notre repository git
• D’un build Jenkins déclenché chez Cloudbees qui exécute un script Grunt pour optimiser votre site Web
• De hooks Git pour déclencher automatiquement ce job Jenkins, sans avoir à poller votre repository Git

Valider ses POJOs en REST avec Bean validation, Spring MVC et JQuery

Cela fait maintenant un bon moment que je n’ai rien écrit sur ce blog, je vais donc profiter de mes vacances pour traiter d’un sujet plutôt récurrent sur les applications Java d’entreprise : la validation de vos beans.

Dans cet article, j’aborderai notamment :

• Les principes de bean validation, sa mise en place et possibilités dans un contexte Spring MVC
• La mise en place d’un controller orienté REST via Spring MVC (ce sera très rapide, là n’est pas l’objectif de cet article)
• La validation d’un simple POJO via un test (un peu plus qu’unitaire) utilisant rest assured, illustrant la testabilité de votre application REST
• Comment aller plus loin : faire des validations conditionnelles, gérer de manière centralisée le comportement de vos controllers spring sur une erreur de validation
• Implémenter une validation unifiée client/serveur, basée sur la validation serveur via un appel AJAX

Le fil rouge du post sera simple : l’objectif est de fournir une page d’inscription dans lequel l’utilisateur doit pouvoir saisir un certain nombre d’informations plus ou moins obligatoires le concernant.

Un projet github a été créé pour l’occasion, avec l’ensemble des sources de cet article. N’hésitez pas à le consulter si vous avez des interrogations.

JugSummerCamp 2010 : Le MDA en 2010 : une vision pragmatique

Voici un compte rendu de la conférence du JugSummerCamp à propos de MDA. Il s’agit d’une présentation que j’ai apprécié car il s’agit d’un sujet auquel je touche de près ou de loin depuis quelques années, et il m’arrivait de m’interroger sur la pertinence de cette pratique.
Je tenterai de vous retranscrire les notes que j’ai pu prendre durant la conférence, sachant que les slides sont disponibles ici (et la présentation devrait être mis à disposition sur Parleys d’ici quelques temps).

JugSummerCamp à la rochelle

Vendredi 10 septembre, j’ai eu la chance d’assister, avec ma casquette SQLI, au JUG Summer Camp qui s’est déroulé dans le port de La Rochelle, à deux pas de l’Aquarium.

Pour rappel, un JUG (Java User Group) est un regroupement de passionnés Java, à l’occasion de conférences, généralement gratuites et ouvertes à tous, à raison d’une à deux fois par mois (en début de soirée généralement). A Bordeaux, par exemple, le Bordeaux JUG se réunit une fois par mois (la prochaine, c’est jeudi 16 septembre !.. et on parlera de Flex !) dans les locaux de l’ENSEIRB à partir de 19h (comptez ensuite une bonne heure et demie de présentation et, si vous avez de la chance, un buffet gratuit post-conférence).

Critique de Livre : Apache Maven de A. Heritier et N. De Loof

Durant mes vacances d’été en Crête, j’ai eu l’occasion de me dorer la pilule en lisant le livre Apache Maven chez Pearson, écrit par Arnaud Heritier et Nicolas De Loof.
Suivant ces deux zigotos sur twitter depuis début 2010,  et ayant déjà pu lire de bons echos dans la blogosphère java sur le livre,  cela m’a donné envie de le lire.

En terme d’expérience maven, je l’utilise tous les jours depuis maintenant 2 ans et demi en mode « utilisation avancée » (archetypes, poms parent, plugins maison, assurance qualité, industrialisation, intégration continue …) ; j’ai également eu l’occasion, à 4 reprises, de dispenser une formation Maven pour différents clients extérieurs : j’étais donc loin d’être débutant en commençant la lecture du livre et attendais beaucoup de ce dernier : qu’il soit à la fois didactique pour que je puisse le faire lire à des développeurs débutants (de mon équipe) sur le sujet, mais aussi qu’il m’apprenne des choses !

D’autre part, j’avoue avoir peu d’expérience dans la lecture de livres techniques puisque c’est le second livre technique que j’achète (et lit) avec le fameux Design Pattern du Gang of Four. A fortiori, il s’agit là de ma première critique de livre,  j’espère donc ne pas trop faillir dans cet exercice.

Plugins Hudson – Episode 3 : Des formulaires et des données

Suite de ma série de billets consacrés au développement de plugins Hudson. Dans cet épisode qui se situe dans le prolongement de l’implémentation de son premier plugin, je vais principalement traiter de  la gestion des données, depuis leur saisie par un utilisateur à leur persistance. Nous verrons également comment tirer partie du framework javascript en place dans Hudson.

Plugins Hudson – Episode 2 : Implémenter son premier plugin

Suite de ma série de billets consacrés au développement de plugin Hudson : aujourd’hui, nous allons parler développement et mettre davantage les mains dans le cambouis que dans l’épisode 1.

Nous allons voir notamment comment implémenter des points d’extension ainsi qu’une vue et un traitement coté serveur en utilisant les technologies Jelly et Stapler

Plugins Hudson – Episode 1 : La création du plugin

Aujourd’hui, nous allons traiter du développement de plugins pour Hudson.

Cela fait maintenant un peu plus d’un mois que je travaille sur un plugin hudson permettant de générer des statistiques globales sur l’état d’exécution des jobs hudson : le global-build-stats hudson plugin. Ce plugin est particulièrement utile pour du monitoring Hudson et permet de détecter des problèmes sur différents axes : temps, typologie de build, typologie de résultat du build.

A l’occasion de la première release stable du plugin (la 0.1), j’ai décidé de partager sur ce blog l’ensemble des facilités et problèmes que j’ai pu rencontrer durant les développements de ce plugin. Ces retours seront formalisés par un ensemble de billets (à priori trois ou quatre) s’organisant autours des problématiques suivantes :

• Mise en place d’un nouveau plugin
• Comment et où poser des points d’extension
• Présentation du framework MVC d’Hudson : Stapler
• Persister ses données
• Coté présentation : le scripting Jelly et les comportements javascript d’Hudson
• La première release : le déploiement et les outils de communication autours du plugin
• La mise en place de la sécurité

Présentation Portails & Portlets Java au JUG de Bordeaux

Vous n’avez pas pu vous déplacer pour participer à la dernière présentation du JUG de Bordeaux que j’ai eu le plaisir d’animer ?
Et bien vous êtes passé à coté d’une belle présentation (en toute objectivité/modestie bien sur ! ;-)).

Allez, je vais être sympa : les slides sont disponibles dans les ressources du JUG donc n’hésitez  pas à les parcourir !

En terme de ressenti :
– Bizarrement, j’étais beaucoup plus stressé à répéter le week end précédent tout seul devant mon ordi, que devant les 40 personnes présentes ce soir là
– Je n’ai pas assez utilisé le verre d’eau pendant la présentation (dur dur pour la gorge le lendemain !)
– Je n’ai malheureusement pas pu présenter beaucoup de « démos techniques » sur Liferay … j’en avais pourtant sous le coude mais manque de temps (je suis trop bavard !)
– Les questions / échanges étaient très constructifs … j’ai moi-même appris plein de choses sur le sujet en donnant la présentation (comme généralement lorsqu’on présente quelque chose … j’ai ce même ressenti lorsque je donne une formation)
– L’ensemble des retours que j’ai eu étaient bons (en même temps, je  vois mal quelqu’un me dire « c’était naze » ;-)) … certains non habitués du JUG (=non geeks) m’ont même dit « tu le répète pas hein … mais ça m’a même intéressé ! » (vous constaterez que je ne répète jamais les confidences qu’on me fait)
– En terme de charge de travail perso, cette présentation a été, pour moi, beaucoup moins gourmande que l’élaboration du Dojo randori TDD : du coup, ben j’ai bien envi de recommencer … faut juste que je trouve un sujet original/intéressant !… Un truc autours de maven, hudson et de plugins (hudson/maven) ?

Pour résumer : que du positif !

Merci encore à l’équipe du JUG de Bordeaux (Xavier, Greg et Fabrice), et longue vie à ce dernier !

Spring ROO : Premiers retours

SpringSource nous a fait un cadeau de fin d’année en nous annonçant, le 31 Décembre 2009, la release de la version 1.0.0 de Spring ROO. Pour rappel, Spring ROO est un interpréteur en ligne de commande, dont l’objectif est de vous permettre de développer rapidement des applications standards via de la génération de code. Pour illustrer l’outil, rien de mieux qu’une petite phrase issue de la documentation officielle :

[…] Most of the time you’ll just go about programming in your text editor or IDE as usual. As you make changes to your project, Roo intelligently determines what you’re trying to do and takes care of doing it for you automatically.

J’ai donc profité d’une journée de mauvais temps pour tester un peu tout ça. Ce billet illustre mes retours.

Mes attentes

Mes attentes sur cette étude sur Spring ROO étaient les suivantes :
– Avoir déjà un premier bagage sur les possibilités offertes par Spring ROO
– Etudier les possibilités de customisations de ce générateur de code
– L’idée sous-jacente étant l’industrialisation de mes développements récurrents

Les questions que je me posais en début d’analyse :

ROO est-il transparent dans les devs ? Quelle adhérence a-t-on avec ce dernier ?
Possibilité de customisation des templates utilisés ? (pour la génération d’une Entity par exemple)
Possibilité de rajout des commandes « à nous » pour générer des choses spécifiques à notre domaine fonctionnel ? (notion de « cartridges » en MDA)
Quelle customisation possible sur l’initialisation de projet ? (ex: utilisation d’archetype maven possible ?)
Quel mode de génération ? Plutôt one shot ou incrémental ? L’outil peut-il être utilisé dans une approche itérative de type MDA ?