Tag :Lyon Jug

Ecosystème NoSQL avec Rémy Girodon

Le 15 janvier prochain, le Lyon JUG invite Rémy Girodon pour un talk intitulé « NoSQL pour les Nuls ». Quand on a demandé à Rémy de présenter son sujet, voici sa réponse, on ne s’en lasse pas :

« On ne va pas se mentir (pas après 6 ans de Lyon Jug), si tu as 3 projets Cassandra dans les pattes, 5 projets MongoDB, 4 projets Neo4J et que tu es commiter sur Redis, tu ne vas pas apprendre grand chose à ce talk.
Par contre si as toujours stocké tes data dans un bon vieux SGBDR des familles et que tu te demandes si il y aurait pas eu moyen de faire un poil plus pertinent / performant / pratique / économique / simple (rayez ou pas la ou les mentions inutiles), alors ce talk est fait pour toi.
On va te prendre par la main et te faire découvrir les grandes familles du NoSQL, les Use Cases qu’elles adressent, et en bonus chaque famille un focus sur un produit caractéristique.
Allez viens ! « 

Rémy Girodon

Pour vous donner tout de suite un avant-goût de la soirée, allons poser quelques questions à Rémy.

Lire la suite

Soirée Android au Lyon JUG!

Le 20 novembre prochain, le Lyon JUG propose une soirée spéciale Android. Vous aurez la chance d’assister, en première partie, à une session Livecoding Android pour une introduction les mains dans le cambouis. Plutôt que de s’endormir devant des slides surchargés de code, le livecoding permettra de vous présenter progressivement tous les concepts clés. Suivra ensuite un talk sur le projet Android Annotations qui est un framework Open Source visant à simplifier et industrialiser les développements Android.

@PiwaiPour vous accompagnez tout au long de cette soirée, deux speakers vont co-animer les sessions! Tout d’abord Pierre-Yves Ricau qui est le créateur du projet Android Annotations. Après des expériences en tant que consultant Java/JEE, il tente désormais d’amener des bonnes pratiques au développement Android. Il a rejoint la startup Siine Ltd, basée notamment à Londres et Barcelone, fondée en 2007, qui édite un clavier Android révolutionnaire.

@dam_villeneuveDamien Villeneuve est le deuxième speaker! Damien est un développeur Web et mobilité. Axé principalement Java/JEE, Android et iOS, il aime savoir comment les choses fonctionnent pour mieux les simplifier. Il travaille avec Android Annotations au sein du groupe Excilys, sponsor du projet.

Pour vous donner tout de suite un avant-goût de la soirée, allons à la rencontre des speakers.

Cet interview a été préparé par la team du Lyon JUG, Agnès CREPET, Cédric EXBRAYAT, Alexis HASSLER, ainsi que Guillaume EHRET.

La team « élargie » du Lyon JUG : Peux-tu te présenter ? Comment es-tu arrivé dans le monde de la mobilité ?

Pierre-Yves : Bonjour ! Je suis Pierre-Yves Ricau, @Piwai sur Twitter. Il y a 3 ans, j’ai découvert le développement Android au cours de mon stage ingénieur et j’ai ensuite alterné les expériences Android et JEE / GWT au sein d’eBusinessInformation. Je travaille en freelance depuis un an, pour Siine.

Damien : Bonjour. Je suis Damien Villeneuve. J’ai toujours été passionné par les nouvelles technologies et la programmation. Après avoir testé du J2ME il y a 5 ans, j’ai eu l’occasion de travailler sur un projet Android et ça m’a tout de suite plu. Depuis je travaille principalement sur Android et JEE au sein d’eBusinessInformation.

 

La team « élargie » du Lyon JUG : Quelles sont les nouveautés notables des dernières versions Android ?

Pierre-Yves : L’essentiel est écrit ici et . D’un point de vue utilisateur, on s’oriente vers une intégration plus forte entre les produits Google, et une cohérence globale de la plateforme. D’un point de vue développeur, d’une part l’outillage (IDE, Lint, build, émulateurs) a beaucoup progressé, et d’autres part le design est devenu une préoccupation majeure des équipes Android.

Damien : Pierre-Yves a plutôt bien résumé la situation. J’ajouterais juste que l’expérience utilisateur est beaucoup plus simple et agréable depuis la version 4.0. On peut aussi noter des animations beaucoup plus fluide, ce qui commence à placer Android comme un sérieux concurrent à l’iPhone pour les fans du shiny.

 

La team « élargie » du Lyon JUG : As-tu déjà testé les frameworks qui permettent de faire des applications multiplateformes ? PhoneGap a notamment une grande popularité actuellement. L’as-tu testé et qu’en penses-tu ?

Pierre-Yves : Il y a un an j’ai testé PlayN en réimplémentant 2H4U (voici le résultat en html5). C’était marrant et pas très compliqué, mais encore beaucoup trop jeune. Je n’ai pas utilisé PhoneGap. Les retours qu’on m’a fait indiquent que PhoneGap permet d’arriver très rapidement à un premier résultat, mais qu’il est difficile de créer une application performante et iso-fonctionelle sur toutes les plateformes.

Damien : Il y a un an, on m’a demandé une étude préliminaire sur PhoneGap. On arrivait effectivement à avoir des résultats assez rapidement, mais on était assez limités pour l’accès aux ressources physiques (accéléromètre, gps, etc…). Aujourd’hui l’API semble avoir évolué, mais il reste toujours des contraintes de compatibilité entre les différentes plateformes.

 

La team « élargie » du Lyon JUG : En 2012, quand faut-il développer en natif et quand faut-il faire du Web ?

Pierre-Yves: Ça ne va pas plaire à tout le monde, et c’est pourtant une évidence : le Web sert à faire des sites Web, le natif des applications natives. Un site web mobile et une application native servent des objectifs différents, et sont souvent complémentaires en termes stratégiques.

Évidemment, développer une application native pour chaque plateforme est un investissement. On serait tenté d’utiliser un outil comme PhoneGap pour mutualiser ses développements. C’est payant à court terme, cela permet d’arriver rapidement à un prototype multiplateforme en utilisant des compétences Web répandues. Mais c’est une garantie d’échec à plus long terme. Les paradigmes de UI sont largement différents d’une plateforme à l’autre, en tentant de les unifier on réalise un produit médiocre sur toutes les plateformes. De même, les implémentations de « webview » varient, il vous faudra donc une équipe d’experts (chers?) pour résoudre les bugs et autres problèmes de performance.

Damien : Encore une fois, mon point de vue est très similaire à celui de Pierre-Yves. Je n’ai pas grand chose à ajouter, tout a été dit.

 

La team « élargie » du Lyon JUG : Comment se porte le marché des applications mobiles? À part les hits à la Angry Birds, est-il possible de vivre facilement du développement mobile?

Pierre-Yves : Oui! Au delà du développeur qui se lance seul, créé ses propres applications et devient riche, les entreprises ont besoin de développeurs mobiles. Les utilisateurs sont à la recherche d’applications qui soient plus que des applications vitrines développées en 3 semaines par une web agency. Le mobile est donc en train de quitter la direction marketing pour intégrer la DSI.

Damien : Les entreprises commencent effectivement à se tourner de plus en plus sur l’utilisation d’appareils mobiles en interne. Que ce soit dans les bureaux ou à l’extérieur dans des conditions plus difficiles, le marché du mobile n’explose pas que pour les particuliers.

 

La team « élargie » du Lyon JUG : Quelles sont les solutions actuelles aux problèmes de fragmentation des systèmes Android : versions, résolutions et capacités différentes ?

Pierre-Yves : Côté design, il vaut mieux fournir une expérience identique quelle que soit la version, le constructeur, etc. Le style Holo est top, pourquoi ne pas en faire bénéficier tous vos utilisateurs ? C’est pourtant simple en utilisant les bons outils : AndroidKickstartR, HoloEverywhere, ActionBarSherlock, Action Bar Style Generator, Android Holo Colors, …

Pour les versions, on décide d’une version minimale supportée (cf les stats), mais on configure la dernière version du SDK dans le projet, ce qui permet d’utiliser les dernières features. Lint se charge de nous avertir sur l’utilisation d’API non supportées dans la version minimale. Ensuite, on utilise d’une part le mécanisme de resources alternatives, et d’autre part des branchements dans le code avec des implémentations alternatives de classes.

En pratique, les différences de résolution et de dimension posent peu de problèmes : on utilise des layout fluides, des dimensions indépendantes de la résolution. Côté images, il faut à minima les fournir dans 2 dimensions (hdpi, xhdpi). C’est vraiment une question de bonnes pratiques, une fois qu’on a choppé le coup on n’y pense même plus.

Côté capacités, on note principalement des différences en terme de CPU et de mémoire.

Les problèmes de CPU concernent plutôt des usages spécifiques, comme les jeux, auquel cas on pourra utiliser le NDK. En général, les lags sont dus aux erreurs classiques comme des opérations d’IO sur le thread de la UI ou des hiérarchies de vues trop profondes. StrictMode et Traceview aident bien.

Pour la gestion de la mémoire, il faut penser à utiliser des caches ayant une taille maximale et une politique d’éviction, par exemple le LruCache. Petite anecdote marrante, le clavier Android standard (LatinIME) catch les OutOfMemoryError en plusieurs endroits, par exemple ici.

Damien : Que dire de plus… Google fourni régulièrement des stats sur cette fragmentation. Je pense qu’il est important d’aller y jeter un œil régulièrement et tailler son application en conséquence.

 

La team « élargie » du Lyon JUG : Quelles sont les difficultés pour un développeur Java pour commencer à développer pour Android ?

Pierre-Yves : Vous ne retrouverez pas vos outils habituels: pas de Spring, pas d’Hibernate, Maven est un enfer, l’introspection explose les perfs, les Logs fonctionnent différemment.

La documentation est telle qu’il est difficile de suivre un chemin d’apprentissage linéaire. Le web regorge de mauvais conseils (Read the source Luke). Les conventions de nommages internes au SDK nous viennent d’un autre siècle.

Bref, il faut s’armer de patience et savoir se faire aider.

 

La team « élargie » du Lyon JUG : Tu seras à Devoxx en novembre, tu vas présenter un Tools in Action sur ton projet AndroidAnnotations. Peux-tu nous présenter ce projet?

Pierre-Yves : AndroidAnnotations, AA pour les intimes, est un framework Open Source visant à simplifier et industrialiser les développements Android, sans impacter les performances.

AA utilise l’API d’Annotation Processing de Java 6 pour générer à la compilation le code d’infrastructure de vos applications Android, et permettre au développeur de se concentrer sur le code métier.

Ce projet est né il y a deux ans d’une frustration que j’ai ressenti en travaillant pendant un an sur un projet Android. J’avais du abandonner RoboGuice pour des raisons de performances. Olivier Croisier a présenté l’Annotation Processing au ParisJUG, et 8 jours plus tard AA était né.

 

La team « élargie » du Lyon JUG : Utilises-tu des tests unitaires dans tes projets Android (http://developer.android.com/tools/testing/testing_android.html) et est-ce que la simplification de l’écriture de ces tests est dans le scope d’AndroidAnnotations ?

Pierre-Yves : Pour tout ce qui est logique métier et composants techniques, j’écris des tests JUnit hors conteneur ne nécessitant pas de démarrer un émulateur, grâce à Robolectric qui reproduit le comportement du SDK. Combiné avec infinitest, ça permet un feedback très rapide.

AA n’a pas pour objectif de simplifier l’écriture des tests, mais c’est effectivement un effet induit par le découplage qu’il permet.

Je ne code pas de test d’IHM tournant sur de vrais devices, j’attends encore de découvrir comment faire ça simplement. C’est complexe à mettre en place, dur à maintenir, et long à exécuter.

 

La team « élargie » du Lyon JUG : Est-ce que l’utilisation d’AndroidAnnotations ne pose pas de problème avec Lint comme on peut avoir par exemple quand on utilise Lombok avec Sonar ?

Pierre-Yves : Non, car le code généré par AA est visible par Lint. Le problème de Lombok est que les modifications du bytecode ne sont pas visibles dans les sources. Ce n’est pas le cas d’AA, qui se contente de générer des classes supplémentaires, sans modifier le code existant.

 

Merci à Anne-Laure Rigaudon pour sa relecture.

 

Merci Pierre-Yves et Damien!

 Les inscriptions pour la session de Pierre-Yves et Damien au Lyon JUG le 20 novembre sont ouvertes! Rendez-vous sur le site du Lyon JUG pour vous inscrire!

Parlez-moi un peu de Guava et Lombok!

Thierry Leriche-DessirierThierry Leriche-Dessirier est invité par le Lyon JUG le 19 septembre prochain pour une soirée dédiée à Guava et Lombok. Agnès Crépet et ses camarades du Lyon JUG sont allés à sa rencontre pour lui poser quelques questions en amont de cette soiréé.

Agnès : Peux-tu te présenter? Quels genres de missions assures-tu en tant que Freelance?
Thierry: J’ai trente-cinq ans. Je suis marié, papa d’une petite fille et très gros consommateur de café. Je travaille depuis une douzaine d’années, quasi exclusivement sur le Web et sur Java. Quand j’étais en SSII, j’avais le poste d’architecte JEE. Depuis que je suis indépendant, je me présente comme consultant.
Mon activité principale, en semaine, est d’assister le leader français de la grande distribution dans ses développements. J’interviens sur plusieurs projets (SSO, référentiels client, portails, QR codes, intranet, drives, etc.) en Europe en en Asie.
A côté, je suis également professeur de Génie Logiciel à l’ESIEA, une très bonne école d’ingénieur sur Paris, et coach sur des projets de formation humaine. Pour compléter le tableau, entre deux biberons, je suis rédacteur pour Developpez.com et le magazine Programmez.

Agnès : Utilises-tu Guava par défaut les yeux fermés sur tous tes projets Java? Quel est le top 3 de tes fonctionnalités préférées de Guava, celles qui en font selon toi un outil incontournable?
Alexis : En quoi Guava est-il mieux que Apache commons ? Est-ce qu’il y a des domaines où il est moins bien ? Est-ce qu’il a d’autres concurrents ?

Thierry: J’ai découvert Guava à la machine à café juste avant de passer freelance. A l’époque, ça s’appelait encore « Google-Collections ». Ça a été un coup de cœur et, par chance, j’ai pu l’utiliser sur un vrai projet dès la mission suivante. Je vois cette bibliothèque comme un incontournable dans mon travail. J’ai tellement l’habitude de l’utiliser que j’ai du mal à écrire du code Java qui ne l’utilise pas.
Ce qui m’a initialement séduit dans les « Google-Collections », ce sont les « static factories » pour créer des collections facilement et sans devoir répéter les génériques de chaque côté du signe égal.
Avec Java 5 :


List primeNumbers = new ArrayList();
Map ages = new HashMap();

Avec Guava :


List primeNumbers = newArrayList() ;
Map ages = newHashMap();

J’ai découvert le concept d’immutabilité, qui existe en Java mais que Guava sublime. Et puis j’ai adoré la programmation fonctionnelle qui devenait enfin accessible en Java.
On trouve une très bonne vidéo de programmation fonctionnelle à l’aide des Google-Collections, présentée par Kevin Bourrillon (le team leader Guava) et Josh Bloch sur Youtube : http://www.youtube.com/watch?v=ZeO_J2OcHYM
Exemple de transformation d’un Dog en SuperChien à l’aide de la méthode « transform » et de la classe « Function » :


List superChiens = Lists.transform(dogs,
new Function() {
@Override
public SuperChien apply(Dog dog) {
SuperChien chien = new SuperChien();
chien.setSurnom("Super " + dog.getName());
chien.setPoids(dog.getWeight());
chien.setPouvoirs(newHashSet("Code en Java", "Vole"))
...
return chien;
}
});

Rapidement j’ai écrit un article sur mon site perso à propos des Google-Collections, que j’ai porté sur Developpez.com
Et par la suite, j’ai complété ce premier article par un blog dédié à Guava.
A l’occasion d’une intervention au Paris JUG, je me suis intéressé de nouveau aux Commons d’Apache dont j’avais oublié jusqu’à l’existence. J’avais alors le sentiment que ça avait mal passé le cap de Java 5 et plus particulièrement l’arrivée des génériques. Etait-ce seulement une fausse impression ? Et quelle bonne surprise ça a été de constater que les Commons valaient de nouveau le coup d’œil.
A mon sens, Guava et les Commons ne se font pas vraiment concurrence. Ils ont des domaines sur lesquels ils se chevauchent mais je trouve qu’ils se complètent assez bien. Sur la question de les comparer, lors de Devoxx France 2012, Kevin Bourrillon proposait de lire un sujet dédié sur Stackoverflow.
A titre personnel, je préfère Guava…

Cyril : Guava est-elle une librairie qui améliore simplement la productivité, ou améliore-t-elle aussi la qualité du code produit, notamment au niveau de la maintenabilité? Le coût d’apprentissage est-il important?
Thierry: Très clairement, Guava améliore la productivité et la qualité. La bibliothèque reprend tous les concepts du livre « Effective Java » à son compte et elle oblige les développeurs à se poser les bonnes questions. L’exemple qui me vient immédiatement est celui des immutables. Pour paraphraser, on se demande souvent si une collection doit être immutable alors que, dans la très grande majorité des cas, on devrait surtout se demander si elle a besoin d’être mutable.
Quand on regarde le code de Guava, à part certains points hyper spécifiques, il n’y a rien d’insurmontable. Je dirais même que tout est d’une clarté effrayante. C’est sans doute le signe de la qualité. Pendant longtemps, le gros point noir a été la documentation mais ce problème est désormais quasi réglé.
Je pense qu’il suffit de quelques heures pour bien prendre Guava en main, au moins pour les fonctionnalités courantes. Là où ça se complique, c’est quand on s’intéresse aux caches ou aux Futures par exemple. Là, il y a une petite mécanique à bien comprendre…

Agnès : Guava permet d’écrire du code Java en respectant une approche de programmation fonctionnelle. Est-ce que tu trouves cet aspect intéressant? Cela t’a-t-il poussé à t’intéresser aux langages respectant plus cette approche?
Alexis : De la programmation fonctionnelle alors que le langage Java n’est pas prévu pour ça, ce n’est pas risqué ? Est-ce qu’on ne risque pas de faire du code plus confus ?

Thierry: On peut répondre à ça de plusieurs manières. Au départ, j’ai trouvé que c’était super cool. Les Functions, les Predicates, les Filters, surtout combinés, c’est magique. Si on ajoute que les filtres renvoient des vues (lazzy loadées) et pas seulement des collections classiques, on a tendance à vouloir les utiliser à toutes les sauces. Et c’est là que ça devient mauvais. La team Guava le reconnait d’ailleurs volontiers. Les développeurs ont tendance à abuser de la programmation fonctionnelle offerte par Guava, là où une simple boucle « for » suffirait plus qu’amplement et serait moins verbeuse…
Ainsi, selon le cas d’usage, le code présenté plus haut pourrait honnêtement se résumer à :


List superChiens = newArrayList();
for(Dog dog : dog) {
SuperChien chien = new SuperChien();
chien.setSurnom("Super " + dog.getName());
chien.setPoids(dog.getWeight());
chien.setPouvoirs(newHashSet("Code en Java", "Vole"))
...
superChiens.add(chien);
}

En plus, avec l’arrivée de Lambda prévue pour Java 8, la donne risque de bien changer. J’en avais justement discuté un peu avec Kevin. Et pour lui c’est clair, il n’y aura plus aucun développement réalisé autour de la programmation fonctionnelle sur Guava. Ça ne remet pas en cause ce qui existe déjà. Ça signifie simplement que ça n’ira pas plus loin.
En ce qui me concerne, j’avoue être un peu perplexe. Je ne suis pas très fan de la direction que prend Java avec Lambda, notamment sur les interfaces. Pour le moment j’attends de voir. Pourquoi pas ?…

Agnès : Même question sur Lombok : Utilises-tu Lombok par défaut les yeux fermés sur tous tes projets Java? Quel est le top 3 de tes fonctionnalités préférées de Lombok?
Thierry: J’ai découvert Lombok cinq minutes avant de présenter Guava durant un JUG. C’était Florent Ramière qui parlait. Moi j’étais surtout concentré sur mon intervention et j’avais un peu le trac. Je n’écoutais donc que d’une oreille. Sur le coup, je me suis dit : « qu’est-ce que c’est que ce truc la ?… » Ca avait l’air tellement magique… Un peu plus tard, j’ai revu ça sur Parleys et ça m’a fait un choc : Lombok répondait à des problèmes d’écriture de code que je me posais depuis longtemps, sans vraiment trouver de réponse satisfaisante.
Ce que j’aime avant tout dans Lombok, c’est de pouvoir générer du code avec des annotations simples. Par exemple je peux générer les getters de tout mon bean en une seule ligne. Mais surtout ça va créer des méthodes standards. Ça veut dire que je n’aurais pas à vérifier qu’un accesseur de ma classe ne fait pas un truc imprévu. Qui n’a jamais rencontré ce cas, où c’est un setter qui faisait planter tout le programme car il faisait autre chose qu’une affectation simple ? C’est le genre de petite connerie qui prend des heures à détecter. Donc en résumé, ce que j’aime, c’est de pouvoir écrire des beans dont je suis sûr et qui sont lisibles.
J’aime bien « Lombok-pg », qui est le compagnon idéal de Lombok. Il apporte une série de nouvelles annotations (ie. fonctions) assez sympas. Je pense par exemple aux extensions qui permettent d’ajouter temporairement des méthodes à un objet.
Les Dogs manipulés dans la classe « DogWithExtension » bénéficient (localement) de toutes les méthodes de « MyDogExtensionClass » et notamment de « isTooFat() » :


@ExtensionMethod({ Dog.class, MyDogExtensionClass.class })
public class DogWithExtension {
public void foo() {
Dog milou = new Dog("Milou", 12.5, ...);
boolean isTooFat = milou.isTooFat();
}
}

class MyDogExtensionClass {
public static boolean isTooFat(final Dog dog) {
double imc = dog.getWeight() / pow(dog.getSize(), 2);
return 25 < imc;
}
}

Agnès : Certains reprochent à Lombok le côté “trop magique” (l’annotation @Data par exemple) ou encore le problème du contrôle de la qualité du code (warning en pagaille sur les attributs, pas de documentation sur les éléments générés)… Que penses-tu de ces limites? Sont-elles bloquantes pour toi? Cyril : Quels IDEs offrent un support correct de Lombok?
Thierry: Pour être franc, je n’utilise pas Lombok sur tous mes projets, loin de là même… Ce côté magique, ça fait peur à mes équipes. Ils n’aiment pas ça et je le comprends bien… En revanche, quand j’ai besoin d’aller vite, notamment pour des POCs, je l’intègre directement, en même temps que Guava.
J’avais écrit un petit article « rigolo » là-dessus!
J’avais fait un test : pour un bean simple, avec une dizaine d’attributs, il faut plus de deux cents lignes de code pour avoir les méthodes indispensables (constructeurs, getters, setters, hash code, etc.). Avec Lombok, il suffit d’ajouter @Data. C’est incomparable… Et c’est peut-être aussi son plus gros défaut, en plus de modifier le byte code…
Question IDE, je suis un grand fan d’Eclipse. Le Jar de Lombok permet d’ajouter le plugin à Eclipse mais aussi à Netbeans. Je crois qu’il y a quelque chose pour IntelliJ mais c’est à vérifier.

Alexis : On disait pendant un temps que Lombok ne fonctionne que sur un JVM Hotspot. Qu’en est-il aujourd’hui ?
Thierry: Là je ne peux pas répondre. Je n’utilise que la JVM de Sun…

Agnès : Question subsidiaire 😉
Tu es consultant freelance. Es-tu satisfait de ce statut? As-tu rencontré ou rencontres-tu encore des difficultés ?

Thierry: En fait je me demande pourquoi je ne l’ai pas fait avant. J’en avais pourtant eu l’occasion, à plusieurs reprises… A chaque fois, j’avais toujours une (fausse) bonne raison de ne pas me lancer : sécurité de l’emploi, paperasse, impôts, etc. Avec le recul, je réalise à quel point j’étais dans l’erreur. Devenir indépendant a changé ma vie.
Au début, j’avoue que j’avais peur tout le temps. Mon compte en banque était vide et je suis tombé sur des vrais salauds dans ma première mission. Ma petite fille venait alors de naitre. Mes nuits étaient courtes et le risque de me retrouver sans revenu amplifiait mon stress. Et puis au fur et à mesure des mois, j’ai pu souffler un peu. Ouf… A la fin de mon premier exercice, j’avais repris confiance et j’avais quelques mois d’avance à la banque pour voir venir.
Clairement, on ne devient pas freelance pour le fric. On ne le dira jamais assez. Néanmoins, c’est vrai que c’est une préoccupation importante la première année. Aujourd’hui, je peux me payer des formations, que mon ancien employeur me promettait sans arrêt mais dont je n’ai jamais vu la couleur. Je peux m’offrir le luxe d’aller à Devoxx ou de faire le tour des JUGs de France et de Navarre. Je choisis mes projets et mes clients. Je ne me laisse pas imposer ci ou ça parce que mon commercial a fait n’importe quoi. Je peux prendre des jours pour écrire ou lire un article. Bref…

Par contre, au niveau administratif, je me suis fait aider par mon comptable : le cabinet Eko. Dites que vous venez de ma part 😉 Il a écrit mes statuts, déposé tous les documents, etc. Il ne faut pas hésiter à se faire accompagner… Et tous les mois, il faut saisir les factures, faire les déclarations Urssaf, etc. Et j’avoue que ce n’est pas trop mon truc. Les boucles « for », je maitrise mais les bilans me laissent perplexe.
Je conseille le site « java-freelance.fr » qui m’a beaucoup aidé dans mes choix et mes démarches. Il est d’ailleurs tenu par une Duchesse 😉

Merci Thierry ! Rendez-vous donc au Lyon JUG le 18 septembre prochain!

Un petit tour dans Atmosphere, Comet et les WebSockets

Jeanfrançois ArcandJeanfrançois Arcand est invité par le Lyon JUG le 19 juin prochain pour une soirée dédiée à la création d’applications Web temps réel en utilisant le projet Atmosphere sur lequel travaille Jeanfrançois. Une soirée où on parlera donc des techniques Comet et du protocole WebSocket. Comme à son habitude, Agnès Crépet et ses camarades du Lyon JUG, Alexis Hassler et Cédric Exbrayat, sont allés à sa rencontre pour lui poser quelques questions en amont de cette soirée.

Agnès : Peux-tu te présenter? Quel est ton parcours professionnel et ta mission actuelle chez Wordnik?

Jeanfrançois: Je m’appelle Jeanfrancois Arcand, Québécois de souche. Je travaille dans le domaine depuis 1993. J’ai commencé ma carrière comme mathématicien, travaillant en intelligence Artificielle pour le groupe Roger Communications. En 1997, j’ai immigré en Bretagne, sur Lannion, pour travailler pendant 2 ans pour France Telecom. Je suis ensuite retourné au Québec et reparti pour habiter en Californie et travailler pour Sun Microsystem. J’ai passé 10 ans chez Sun Microsystem, travaillant sur Tomcat, Grizzly et GlassFish. Ensuite un court passage chez Ning et Sonatype et, depuis septembre 2011 chez Wordnik. Chez Wordnik je travaille 50% sur le projet Atmosphere et le reste sur l’architecture « temps réel » de Wordnik. Par exemple, le site du Wall Street Journal utilise la technologie de Wordnik (basé sur Atmosphere) et sert 40 millions de requêtes par jour.

 

Agnès : Tu as travaillé sur Grizzly, embarqué dans Glassfish, et qui est un des premiers frameworks NIO. Une extension de NIO, NIO2 (Asynchronous I/O), est proposée dans la version de Java SE 7. Quel intérêt représente pour toi cette évolution, notamment par rapport à son utilisation avec Grizzly?

Jeanfrançois: NIO.1 était très mal foutue d’où le grand nombre de framework qui ont tous essayé de rendre NIO plus facile à utiliser. NIO.2 est vraiment là pour réparer cette erreur. Jadis chez Sun NIO.2 m’intéressait, mais maintenant j’aime utiliser un framework plus haut niveau (comme Netty), ce qui me permet de me concentrer sur l’utilisateur et moins le « bas niveau ».

 

Agnès & Cédric : Tu vas nous parler lors de ta prochaine session au LyonJUG de Comet et de WebSocket. Y a t-il toujours un intérêt à faire du Comet alors que les Websockets existent?

Jeanfrançois: Encore plus! Actuellement, environs 40% des fureteurs* utilisent WebSockets (basé sur mes observation sur le site du Wall Street Journal ). C’est donc important de continuer à développer les techniques long-polling, Server Side Events et streaming (Comet) afin de pouvoir supporter des fureteurs* tels qu’Internet Explorer 6/7/8/9, qui sont malheureusement très utilisés :-). Le support WebSockets est également inexistant sur plusieurs serveurs et donc la technique Comet est encore très primée et d’actualité.

 

Agnès & Cédric : Quand on se lance dans l’aventure du développement d’application Websocket en Java, on peut vite rencontrer des difficultés. Il n’y a pas de standardisation (pas d’API standard) à l’heure actuelle, il faut donc choisir une solution et les implémentations vont être bien différentes en fonction de l’outil choisi (Play! qui utilise les ws natives de netty, Vert.X qui se base sur sockjs par exemple). Lors de ta session au LyonJUG, tu vas nous parler du projet Atmosphere. Peux-tu nous présenter ce framework et son intérêt vis-à-vis de l’écriture de la partie serveur d’application WebSockets / Comet?

Jeanfrançois: Atmosphere permet l’écriture d’applications asynchrones et « cache » les différentes API WebSockets et Comet à son utilisateur. Atmosphere offre une solution portable et unifié, et ce, coté client (Javascript) et coté server (java). Donc, une application peut dès maintenant être redigée et utilisée partout. Si le client ou serveur supporte les WebSockets, ils seront utilisés. Atmosphere supporte aussi une autre spécification HTML5: les « Server Side Events », qui peuvent également être utilisés comme transport lorsque les WebSockets ne sont pas disponibles. La beauté d’Atmosphere est donc de présenter des « API » unifiées et assure, par le fait même, la portabilité des applications. Atmosphere est également « embarqué » par la majorité des « frameworks » actuel comme RichFaces, Vlaadin, Wicket, GWT, etc. Atmosphere supporte aussi les protocoles Socket.IO, Bayeux/Cometd ainsi que SwaggerSocket.

 

Agnès : Atmosphere se positionne t-il principalement côté serveur? De quelles solutions disposons nous côté client pour développer des applications WebSockets sans être adhérent à une solution spécifique (Grizzly, Netty, …)?

Jeanfrançois: Non, Atmosphere se positionne fortement coté client. Wicket, GWT, RichFaces, Primefaces, Socket.IO (coté client), JQuery-Socket ainsi que atmosphere.js sont tous des clients qui fonctionnent avec Atmosphere.La librairie atmosphere.js permet une utilisation transparente des WebSockets et est en mesure de négocier, avec le coté serveur, le meilleur transport à utiliser. Par exemple, une application qui tourne sur Tomcat 7 (qui supporte les WebSockets) et qui utilise atmosphere.js fonctionnera sur tout les fureteurs* populaires. Les WebSockets seront utilisés par Chrome et Firefox, mais long-polling sera utilisé par Internet Explorer…de façon transparente. Donc le coté client du framework Atmosphere est très important.

 

Alexis: Comment se positionne Atmosphere par rapport à des technos comme Netty, Grizzly ou le mode async de Servlet 3, d’un coté, comme Vert.X d’un autre coté ou comme le mode asynchrone de JAX-RS 2 ? (concurrent, complémentaire, rien à voir,…?)

Jeanfrançois: Atmosphere fonctionne avec Netty (le projet NettoSphere) et pourrait également fonctionner avec Grizzly. Le mode Async permis par Servlet 3.0 est aussi supporté, lorsque disponible, par Atmosphere. Atmosphere « auto-détecte » le meilleur moyen de fournir de l’asynchrone basé sur le serveur utilisé. Atmosphere est un concurrent de Vert.X car il permet de faire la même chose (et en mieux, et portable).

JAX RS 2 est une standardisation du module « Atmosphere Jersey » (très primé) et ne fonctionnera que sur les serveurs Java EE 7. La spécification s’inspire d’Atmosphere, ce qui est positif pour Atmosphere! Par contre, Atmosphere fonctionne partout et support EE 4/5/6 de façon transparente.

 

Alexis: Atmosphere s’intègre avec des clients non-HTTP (JMS, JGroups,…). Quels types d’architectures utilisent cette intégration.

Jeanfrançois: JMS, JGroups, Redis ainsi que Hazelcast permettent la mise en production « nuage » d’une application Atmosphere. Ces types d’architectures permettent la communication entre les serveurs utilisés par Atmosphere, et ce, d’une façon transparente. Il est donc possible de faire fonctionner Atmosphere dans un nuage (cluster) et d’utiliser, de manière transparente, une technologie « nuage » de son choix.

 

Merci Jeanfrançois! Rendez-vous donc au Lyon JUG le 19 juin prochain! Vous pouvez- également aller consulter le blog de Jeanfrancois.

Merci à Anne-Laure Rigaudon, l’autre Duchess lyonnaise, pour sa relecture toujours précieuse!

* fureteur = navigateur

Parlons Groovy avec Guillaume Laforge

Guillaume LaforgeGuillaume Laforge est invité par le Lyon JUG le 15 mai prochain pour une soirée dédiée au langage dynamique Groovy. Agnès Crépet et ses camarades du Lyon JUG sont allés à sa rencontre pour lui poser quelques questions en amont de cette soiréé.

Guillaume Laforge est à la tête de l’équipe de développement Groovy chez SpringSource, une division de VMware. Guillaume est à la fois Project Manager officiel de Groovy et Spec Lead de la  JSR-241 qui standardise le langage Groovy. Il a initié la création du framework  Grails et a fondé le projet Gaelyk, un framework léger pour développer des applications en Groovy pour Google App Engine.
Il est aussi régulièrement speaker sur des sujets comme Groovy, Grails, Gaelyk, les Domain-Specific Languages à des conférences comme JavaOne, GR8Conf, SpringOne2GX, QCon ou encore Devoxx.
Il est également le co-auteur de Groovy in Action avec Dierk König et Paul King, deux committers célèbres sur Groovy.
Guillaume est aussi un membre fondateur du podcast français LesCastCodeurs.

Agnès : Peux-tu te présenter? Quelles sont tes activités chez SpringSource ?

Guillaume : Je m’appelle Guillaume Laforge. Chez SpringSource, je dirige et développe le projet Groovy, qui est un langage Accessoirement, je fais parti des Cast Codeurs ! Et je suis le fier détenteur d’un superbe mug des duchesses que j’ai eu l’honneur de recevoir lors de l’enregistrement live des Cast Codeurs à Devoxx 🙂

Agnès : Peux-tu nous raconter si ce n’est pas trop indiscret ton histoire d’amour avec Groovy ?

Guillaume : En 2003, je travaillais chez un petit éditeur logiciel qui faisait une sorte de générateur d’applications à partir d’un méta-modèle de données.

On pouvait définir des widgets graphiques pour différents types de données, et je cherchais une solution pour pouvoir définir et scripter ce genre de widgets pour personnaliser les applications pour les clients.

A l’époque, il n’y avait pas grand choix pour ce genre de besoins, et le project Groovy venait juste de se lancer.

Du coup, j’ai commencé à y jeter un coup d’œil, mais à l’époque, c’était très buggué. Du coup, j’ai commencé à contribuer à des patches pour corriger les problèmes que je rencontrais, et au bout d’un moment, le chef de projet d’alors en a eu marre d’appliquer les patches et m’a donné les droits de commit. Puis plus tard, il a quitté le projet, et j’ai repris les rennes du projet.

Et depuis, je travaille sur Groovy.

Cédric : As tu une idée des chiffres de l’adoption de Groovy ? Est ce en constante progression ?

Guillaume : C’est toujours difficile d’avoir un nombre d’utilisateurs d’un projet Open Source.

Les chiffres que je regarde de temps en temps sont le nombre de téléchargements de la distribution, et aussi le nombre de téléchargements à partir de Maven Central. Pour la distribution par exemple, à l’époque de la sortie de la 1.7, on avait eu pas loin de 400 000 téléchargements ou plus récemment sur les statistiques de Maven Central, on était aux alentours de 100 000 téléchargements par mois. Donc en combinant distributions et artifacts Maven, j’imagine qu’il y a sans doute un demi-million d’utilisateurs, ou quelque chose comme ça. Difficile à dire.

En tout cas, oui, les chiffres ont tendance à progresser. Les statistiques sur Maven Central montrent un bon doublement sur un an des téléchargements par exemple.

Agnès : Puisque nous sommes entre nous, peux-tu nous dévoiler tes histoires d’adultères langagières ? Quels sont notamment les autres langages dynamiques que tu as manipulé ? Et où en es-tu avec notre ami Java (amour platonique? histoire ancienne? le support des langages dynamiques est-il pour toi un sursis ou un sursaut?)

Guillaume : Je dois dire que malgré ma relation passionnelle avec Groovy, je reviens toujours voir maman Java 🙂

J’aime beaucoup ce langage. J’ai fait mes premières armes avec, et quoi qu’on en dise, c’est un langage que je trouve agréable à utiliser.

J’ai eu l’occasion de jouer avec d’autres langages, comme Python, Ruby ou PHP, et j’ai regardé un peu ce qui se faisait ailleurs comme chez Scala et les nouveaux langages comme Kotlin et Ceylon.

Agnès : Tu vas nous parler des nouveautés de Groovy 2.0 lors de ta session au Lyon JUG? Quel est ton top 3 des nouvelles features ? Peux-tu notamment, même si ce n’est pas dans ton top 3, nous parler du static type checking ?

Guillaume : Il y a en fait 4 grands thèmes dans Groovy 2.0, que j’aurai le plaisir d’aborder lors de la session au Lyon JUG :

Le support de JDK 7 avec Project Coin et Invoke Dynamic, la modularisation de Groovy, le static type checking et la compilation statique.

L’idée du static type checking, c’est surtout en réaction de l’utilisation qui est faite de Groovy. Souvent les développeurs Java utilisent Groovy comme un Java scripté (compilable / exécutable à la volée), voire un meilleur Java (pour rendre le code plus concis et lisible), et s’attendent à ce que le compilateur Groovy donne le même genre d’erreur que le compilateur Java. Mais ce qui est une erreur pour le compilateur Java, n’en est pas forcément une en Groovy, en ce sens qu’au runtime, certaines variables ou méthodes peuvent très bien être disponibles du fait que Groovy est un langage dynamique. Du coup, groovy ne râle pas forcément quand il y a une typo dans un nom de variable ou le nom d’une méthode. Mais quand on utilise Groovy « comme du Java » dans son application, on aimerait que le compilateur se plaigne lorsque l’on fait ce genre de bêtise… et c’est maintenant le cas avec le static type checking.

Cela va également plus loin que cela, car avec le static type checking, le compilateur va râler pour des erreurs de type de retour d’une méthode, pour des assignements de types pas compatibles, etc, grâce à de l’inférence de type.

Tout le monde n’a pas besoin des fonctionnalités dynamiques de Groovy, et le static type checking répond à ce besoin.

Mais pour aller plus loin, on s’est dit qu’également les utilisateurs seraient intéressés par avoir aussi le même niveau de performance que Java. Et donc, on a travaillé aussi sur la compilation statique, pour que le bytecode généré par Groovy soi grosso modo le même que celui de javac, afin d’avoir le même niveau de performances que Java lui même.

Agnès : Tu es à l’origine du Gaelyk project, peux-tu nous présenter ce projet ?

Guillaume : Oui, c’est moi qui ai lancé le projet Gaelyk !

C’est un petit framework tout léger pour développer des applications Groovy pour Google App Engine, en simplifiant l’utilisation du SDK de Google.

Au départ, ça a commencé simplement par une sorte de proof of concept : Google nous avait contactés un peu avant la sortie de Google App Engine Java pour montrer que d’autres langages alternatifs tournaient également sur la plateforme. Nous avons travaillé ensemble pour que cela fonctionne bien, et j’ai été invité à présenter ça à la conférence Google I/O. Pour ma démo, j’ai fait une intégration de Groovy et d’App Engine, et les gens m’ont demandé si c’était disponible et open source… Ce n’était que pour une démo… et puis finalement c’est devenu un vrai projet, avec maintenant une communauté, des contributeurs, etc.

Gaelyk est assez simple à utiliser : on écrit des scripts Groovy qui jouent le rôle de contrôleurs, et des pages qui ressemblent un peu à du JSP mais en Groovy, pour les vues. Dans l’un comme l’autre, on a à disposition des variables pour accéder aux services du SDK, et tout un tas de méthodes décoratrices pour simplifier l’usage du SDK.

Alexis : Grails a longtemps été considéré comme le RoR de Java. Ce statut lui est contesté par Play, qui semble l’avoir dépassé en popularité. Où en est Grails ? Est-ce que le développement Web reste un domaine de prédilection de Groovy ? Quels sont ses autres domaines ?

C’est intéressant cette impression que Play ait dépassé Grails en popularité. Il y a une différence entre « hype » et utilisation réelle. Et il faut aussi penser à l’aspect « cocorico » qui fait qu’on n’est beaucoup plus exposé en France au marketing de Play qu’à celui de Grails. De ma petite fenêtre plus globale mais certainement biaisée, je n’ai pas encore l’impression que Play ait dépassé Grails en quoi que ce soit, en fait 🙂

Cela étant dit, Grails a sorti sa version 2.0 il n’y a pas très longtemps (y compris quelques petits correctifs depuis).

Il y a eu pas mal de nouveautés, comme des améliorations du mode interactif et de la console, un agent pour le reloading des changements à chaud, de nouveaux rapports de tests plus sympas, de même qu’une version html-5-ifiée du scaffolding, des pages d’erreurs plus pratiques à lire, le support asynchrone, l’intégration de la gestion des resources statiques, des améliorations de performances, des améliorations aussi sur l’accès aux datastores (pas seulement relationnels mais aussi tout ce qui est NoSQL), et j’en passe.

Ce qui est intéressant aussi par rapport à Play, c’est que cette version majeure est toujours compatible avec les anciennes versions, et du coup, les gens peuvent très facilement migrer vers cette nouvelle version.

Grails 2.0 est vraiment très mature et performant.

Sinon concernant l’utilisation de Groovy, effectivement il y a une très grande utilisation de Groovy au niveau Web avec Grails, mais aussi pour le build avec Gradle, pour les applications swing avec Griffon, pour le test avec Spock, etc. Groovy est utilisé dans pas mal de scénarios et cas d’utilisation, et en particulier aussi en dehors de tous ces frameworks pour faire des Domain-Specific Languages, de la configuration / customisation d’application, etc.

Agnès : Utilises-tu d’autres langages tournant sur la VM comme Scala ou Clojure ? T’intéresses-tu aux petits nouveaux Ceylon ou Kotlin et que peuvent-ils, selon toi, apporter à la plateforme ?

Alexis : Est-ce qu’ils peuvent “nuire” à Groovy ? Est-ce que tu as envie de voir certaines de leurs fonctionnalités dans Groovy ?

Guillaume : Je joue ponctuellement avec d’autres langages, anciens comme nouveaux, mais essentiellement sur la JVM. J’aime bien regarder ce que les autres font de temps en temps, pour voir s’il y a de bonnes idées qui pourraient être adaptées à Groovy.

Dans les nouveaux venus, j’ai une petite préférence pour Kotlin, qui semble plus proche de mes aspirations (sans parler du fait que certaines features sont tout droit sorties d’idées déjà présentes dans Groovy). J’apprécie Ceylon aussi, mais je le trouve un peu trop verbeux, et trop explicite, alors que j’aimerais qu’un langage fasse plus confiance aux développeurs qui les utilisent. J’aime bien l’élégance de Clojure, même si je n’arrive pas à me faire aux parenthèses et à l’ordre des arguments et méthode. J’ai plus de mal avec Scala, car je trouve que le langage est assez dur à lire et à écrire, même si j’aime bien certaines choses, comme par exemple le pattern matching que j’aimerais bien avoir dans Groovy un jour.

Julien : Si tu pouvais changer une chose dans la JVM, ce serait quoi ?

Guillaume : En fait, c’est une chose qui va justement évoluer et bientôt être une réalité : supprimer la PermGen.

Il y a beaucoup d’entreprises qui utilisent Groovy comme langage business, comme DSL, intégré à leur application.

Ils évaluent et exécutent des tonnes de script Groovy représentant des règles métier, de filtrage, ou autre, et lorsqu’ils réévaluent sans cesse du code Groovy, cela crée de nouvelles classes qui consomment de la PermGen.

Donc plus de PermGen dans JDK 8, ce sera un plus intéressant pour Groovy.

Agnès : Tu es également membre fondateur (et grand humoriste!) du podcast les Cast Codeurs. Quel est selon toi l’intérêt de ce genre de diffusions médiatiques ? Qu’est-ce que cela t’apporte (statut de VIP parisien? bière à volonté? déversoir à blagues ? ;-)… ) et que penses-tu apporter à vos auditeurs ?

Bien que je n’en écoute pas beaucoup, je trouve que les podcasts sont une source assez originale d’information, pour savoir ce qui se passe dans notre domaine, savoir ce qui est à la mode, connaître les petits potins, etc. Surtout, ce qui est pas mal, c’est que ça peut s’écouter n’importe où, et en particulier… dans les transports en commun : c’est important de pouvoir profiter de ce temps inutile que sont les transports en commun pour apprendre quelque chose de nouveau ou passer simplement un bon moment.

Sinon, personnellement, ce que ça m’apporte, c’est surtout l’aspect « sociabilisant ». Comme je fais du télétravail, à part les conférences et la famille, je ne vois pas grand monde la journée, et du coup, ça m’aide à garder le contact, même virtuel, avec mes amis des Cast Codeurs. Faire des blagues tout seul devant son écran, ce n’est pas très marrant, alors c’est vrai que le podcast est aussi ma manière de m’exprimer et de me lâcher un peu 😉

Au final, j’espère qu’on apporte à nos auditeurs un peu de news qu’ils n’ont pas forcément le temps de lire, et un bon moment en compagnie de cette petite troupe sympathique. Après… si en plus l’auditeur se marre grâce à mes jeux de mot, tant mieux 🙂

Merci Guillaume! Rendez-vous donc au Lyon JUG le 15 mai prochain!

Les dessous de Spring Batch

Le Lyon JUG accueille Arnaud Cogoluegnès de la société Zenika le mardi 20 mars prochain. Au programme de la soirée : Spring Batch! Nous sommes allés à la rencontre d’Arnaud, auteur de Spring Batch in Action chez Manning, pour lui poser quelques questions afin de vous donner envie de venir! L’interview a été préparé par une partie de la team du Lyon JUG : Agnès CREPET, Cédric EXBRAYAT et Alexis HASSLER.

Agnès, Alexis & Cédric : Peux-tu te présenter?
Arnaud : Je travaille chez Zenika. J’assure des formations Spring pour VMware/SpringSource, mais aussi des formations Zenika sur d’autres sujets (Wicket, Java, AMQP). Cette activité de formateur prend la moitié de mon temps. Le reste est consacré à des activités de conseil et de développement.

Agnès, Alexis & Cédric : Tu vas venir parler de Spring Batch au LyonJUG, qui permet d’écrire des batchs en java. Peux-tu citer des exemples de problèmes récurrents quand justement on veut écrire des batchs en java?
Arnaud : L’exemple le plus courant est l’import ou l’export de données à partir de/vers des fichiers (XML, CSV). On partage souvent des données de référence de cette façon. Un autre exemple est le parcours d’enregistrements (contrats, dossiers), la vérification de règles et la mise en alerte de l’enregistrement parce qu’il est dans un état lambda depuis trop longtemps. On peut prendre aussi l’exemple d’envoi d’emails (“tous les nouveaux sujets sur un forum depuis 1 semaine”). Enfin, la consolidation de données (comptables, financières) et la génération de rapports. Il y a bien sûr d’autres cas, mais la plupart suivent le schéma lecture – vérification/transformation – écriture, cela pour de gros volumes de données.

Agnès, Alexis & Cédric : En quoi Spring Batch va nous aider face à ces problèmes? Est-il vraiment utile et / ou efficace ?
Arnaud : On peut résumer ce qu’apporte Spring Batch en 3 points :

  • il implémente le cycle lecture/transformation/écriture. Pour faire simple, il s’agit d’une super-boucle foreach, intelligente et configurable. Cela permet au développeur de gérer facilement et par configuration des sauts en cas d’erreur (au lieu de faire échouer la totalité du batch), du rejeu (“retry”), etc. Dans cette boucle, le framework gère aussi les transactions tous les n éléments, s’occupe des rollbacks, etc. Ce cycle est la spécialité de Spring Batch mais on peut tout à fait faire d’autres opérations (brancher n’importe quelle logique en Java).
  • il propose des composants réutisables pour les sources de données courantes (fichiers CSV/XML, base de données en JDBC/Hibernate/JPA, JMS, email, etc). On configure généralement ses composants qui s’occupent des tâches pénibles (I/O sur le système de fichiers) et on branche notre logique métier aux points stratégiques.
  • il conserve toutes les données d’exécution dans une base de données. Cela permet de faire du monitoring (“est-ce que le batch de cette nuit s’est bien passé ?”, “combien de temps l’exécution a-t-elle pris ?”) mais aussi de la reprise sur erreur.

A la question “Spring Batch est-il utile/efficace ?” oui, il l’est. Il fait son travail de framework : il fournit une excellente base technique, il prend les bonnes décisions par défaut et laisse la possibilité au développeur de paramétrer finement son comportement.

Agnès, Alexis & Cédric : Parmi les fonctionnalités de Spring Batch, laquelle mettrais-tu en avant pour nous convaincre de l’utiliser ? Partage de composants Spring, reprise sur incident, séparation des tâches de lecture/traitement/écriture,… ?
Arnaud : Pas forcément une fonction coeur : le monitoring. Pas mal d’applications ont finalement des besoins légers en termes de batch. Mais le besoin récurrent va être de savoir si ces batchs se sont bien exécutés, s’ils n’ont pas pris trop de temps, etc. Implémenter cela à la main prend du temps et n’a aucune plus-value pour l’utilisateur final. Spring Batch propose ce genre de monitoring : on peut utiliser Spring Batch Admin (une application web fournie avec Spring Batch), si on n’aime pas son apparence, on peut facilement la customiser. Si on aime vraiment pas Spring Batch Admin, on peut utiliser la couche d’accès aux données d’exécution que propose Spring Batch. On peut même taper directement sur les tables des données d’exécutions. Bref, c’est très souple.
Spring Batch est modulaire, chacun pourra y trouver au moins un élément qui l’intéresse et qui lui évitera des développements purement techniques, souvent très pointus. Chaque fois que je présente Spring Batch à une équipe projet, j’entends de la part des développeurs : “Spring Batch fait tout ce que j’ai passé tant de temps à re-développer sur de nombreux projets”.

Agnès, Alexis & Cédric : Pendant longtemps Spring Batch a souffert d’une réputation d’un outil complexe (notamment au niveau de la configuration). Comment a évolué le produit ces dernières années? Les créateurs ont-ils opté pour plus de simplicité?
Arnaud : La première version de Spring Batch était très verbeuse, puisqu’elle qu’elle n’avait pas de balises dédiées (elle utilisait les balises bean/constructor-arg/property de Core Spring). C’était un peu le syndrome Acegi Security. Depuis la version 2.0, Spring Batch a un namespace batch. Cela rend la configuration plus simple, maintenable et lisible. Les interfaces cœur ont aussi été simplifiées.
Le framework reste simple et souple : il utilise un contexte Spring, il peut tourner n’importe où (en ligne de commande, dans un conteneur). Il lui faut juste une base de données (et encore, si on souhaite bénéficier de la reprise sur erreur).

Agnès, Alexis & Cédric : Suis-tu le développement de la JSR 352, qui vise à standardiser le traitement des batchs en Java ?
Arnaud : Je suis de loin. La scope de la JSR est un peu plus large que celle de Spring Batch, puisqu’elle comprend le scheduling. Le travail vient de commencer (début février 2012 d’après la mailing list, nous sommes en mars). La version finale est annoncée pour le 2ème trimestre 2012, nous verrons bien. Spring Batch est très souvent évoqué dans la mailing list, il sera certainement une source d’inspiration.

Agnès, Alexis & Cédric : Comment Spring Batch gère-t-il les gros volumes de données ? Est ce que des passerelles avec Spring Hadoop sont possibles ? Même question pour les bases NoSQL et Spring Data ?
Arnaud : Spring Batch commence par gérer les I/O le plus efficacement possible (streaming des fichiers, pagination SQL ou utilisation de curseurs BD, etc). Il permet aussi de régler le nombre d’éléments par commit, un paramètre qui peut jouer beaucoup sur les performances. Même si le traitement est mono-threadé par défaut, cela fonctionne pour la plupart des applications.
Quand on commence à avoir des traitements lourds, qui nécessitent du calcul, ou de gros volumes (millions, voire milliards d’enregistrements), Spring Batch permet assez facilement de multi-threader les traitements. Le partitioning est une solution populaire, car elle est simple à mettre en place. Elle impose
cependant de pouvoir partitionner les données (ex. : plusieurs fichiers d’entrées, chaque fichier est lu et traité dans son propre thread).
Spring Batch permet aussi de distribuer les traitements. Un noeud maître lit les données et les envoit à des noeuds esclaves qui les traitent. On parle de “remote chunking”. C’est une solution puissante, mais plus complexe que le partitionning, puisqu’elle nécessite une solution de messaging comme JMS ou AMQP pour que le maître et les esclaves échangent les lots de données à traiter. Toutes ces solutions sont directement disponibles dans Spring Batch. Elles peuvent être mises en place avec de la configuration et très peu de développement spécifique. Après, on peut distribuer encore plus avec le récent projet Spring Hadoop, qui permet notamment de lancer un job Hadoop depuis Spring Batch. On bénéficie alors de l’injection de dépendances de Spring, de l’environnement Spring Batch (configuration du job, monitoring, reprise sur erreur) et de la puissance d’Hadoop.

Agnès, Alexis & Cédric : (joke) Quel est le sujet de ton prochain livre?
Arnaud : Pas de livre en cours, 3 livres en 3 ans, j’ai donné !

 

Merci Arnaud! Rendez-vous au LYON JUG le 20 mars pour la suite!

GlassFish, OpenSource et SSII, rencontre avec des Serliens

Marian MullerSerli est une SSII que vous connaissez sûrement! De part son implication dans l’opensource ou encore parce qu’Orianne Tisseuil, une Duchess française, en fait partie! Le Lyon JUG accueille, le 21 février prochain, deux Serliens : Marian Muller et Jérôme Petit. Marian commencera la soirée par un talk intitulé “GlassFish, Application versioning et rolling upgrade en haute disponibilité”. Dans le cadre des activités de R&D de la Serli, Marian participe au développement des serveurs Java EE GlassFish et JOnAS. Il a notamment conçu et développé la fonctionnalité de rolling upgrade pour GlassFish 4, et présenté le résultat de ses travaux à Devoxx 2011.

Jérôme Petit Jérôme qui dirige les activités Nouvelles Technologies du SI chez SERLI, société dont 80% de l’activité est tournée vers Java, enchaînera sur une session “Engagement des sociétés d’Ingénierie dans la contribution open source : un cercle vertueux”.
Nous sommes allés à leur rencontre, leur poser quelques questions en amont de leurs talks, afin de vous donner envie d’aller les rencontrer à Lyon, ou lors d’une session d’un autre JUG, puisqu’ils ont déjà donné ces talks dans plusieurs villes! On commence Marian autour de GlassFish, l’Application versioning et le rolling upgrade, pour échanger ensuite avec Jérôme sur l’OpenSource et les SSII.

Cet interview a été préparé par Agnès Crépet, avec l’aide d’une partie de la team du Lyon JUG : Cédric Exbrayat et Alexis Hassler. Merci à Cyril Lacôte pour la relecture.

Agnès : Pouvez-vous vous présenter ? Vos missions au sein de Serli ?
Marian: Je travaille comme ingénieur Java chez SERLI. En dehors des missions plus “classiques”, je participe notamment au développement des serveurs Java EE GlassFish et JOnAS.
En lien étroit avec Oracle, j’ai conçu et développé la fonctionnalité de rolling upgrade pour le futur GlassFish 4.
Jérôme: Je suis entré en 1998 à Serli comme développeur. Depuis 2005, je dirige le pôle Nouvelles Technologies du SI, que l’on appelle aussi pôle Java compte tenu de notre forte spécialisation technologique.
Avec Orianne Tisseuil, nous gérons les activités RH, commerciales, R&D et communautaires du pôle, qui regroupe 80% des effectifs de Serli.

Agnès : Marian, tu vas présenter lors de ta session au JUG la feature “Application Versioning” disponible depuis peu dans Glassfish (3.1?). Cela permet donc de déployer plusieurs versions de la même application sur Glassfish, en précisant laquelle est active. Quels sont pour toi les avantages de cette feature “Application Versioning”, combinée avec le rolling upgrade (que tu présenteras également dans ta session) ?
Marian: Le versioning d’applications a également été réalisé par Serli pour GlassFish 3.1. Je pense qu’il apporte un grand confort dans les opérations de déploiement et de rollback.
Couplé avec le rolling upgrade, il prend tout son sens en permettant d’assurer la disponibilité des applications lors d’un changement de version.

Agnès : Ces features “Application Versioning” et “rolling upgrade” peuvent-elles, selon toi, nous dispenser d’un serveur de pré-production dédié?
Marian: Ces features peuvent vous dispenser d’un serveur de pré-production dans certaines conditions. Elles s’adressent notamment à des mises à niveau relativement mineures, qui n’affectent pas (ou peu) les ressources externes.
Si la mise à niveau d’une application implique des changement majeurs, il est plus prudent de conserver un serveur de pré-production dédié.

Agnès : Quel est le scope des ressources (datasource, queues JMS, etc.) à déclarer pour une application? Au delà du niveau global (visible par toutes les applications) et application, est-ce que je peux déclarer des ressources spécifiques pour une version donnée de l’application?
Marian: Du point de vue de GlassFish, deux versions d’une même application sont des applications distinctes. Les ressources de niveau application sont donc spécifiques à une seule version.

Agnès : Les dernières versions (3.1 et 3.1.1) de Glassfish ont apporté leur lot de nouveautés concernant le déploiement et l’administration des applications. Peux-tu nous dire celles qui te semblent les plus utiles?
Marian: Le retour du clustering est la grande “nouveauté” de GlassFish 3.1.
Dans les évolutions plus mineures, je trouve l’”active redeploy” très utile. C’est lui qui permet à la feature rolling upgrade de conserver l’état des sessions et des EJB stateful.
Des progrès ont aussi été faits pour simplifier la procédure de rolling upgrade dans un cluster.

Alexis : Avez-vous prévu d’implémenter des fonctionnalités similaires dans d’autre serveurs d’applications ? Et est-ce que les autres serveurs d’applications (Tomcat, TomEE, JBoss,…) seraient susceptible d’accueillir de telles fonctionnalités, ou y a-t-il des prérequis ?
Marian: L’implémentation de ce type de fonctionnalité requiert une collaboration étroite avec les équipes de développement, car on touche au cœur du serveur, et le feu vert du responsable produit car la fonctionnalité est critique.
Notre proximité avec l’équipe GlassFish et la confiance d’Oracle nous permet de vivre cette aventure. Nous sommes tout à fait ouverts à la vivre avec d’autres communautés.
Techniquement rien n’empêche les autres serveurs d’applications de proposer de telles fonctionnalités. Tomcat 7 a une fonctionnalité de “parallel deployment” assez similaire, JOnAS possède également des capacités de déploiement avancé.

Agnès & Cédric: Dans quels projets open-source votre SSII Serli est-elle impliquée? Qui les choisit ? Est-ce une stratégie ou est-ce guidé par l’envie des développeurs ?
Jérôme: Serli est actuellement active sur les projets GlassFish, Ceylon, Weld, JOnAS.
Nous avons aussi récemment travaillé sur Sonar, JBoss, Infinispan, Hibernate Validator…
Le vivier de projets potentiels provient des échanges entre le management et les éditeurs, des propositions des développeurs Serliens ou encore des sollicitations directes de la communauté; puis nous décidons des moyens à allouer aux projets en fonction des objectifs stratégiques de l’entreprise.

Agnès : Comment gérez-vous les budgets et ressources sur ces projets OSS ? Pouvez-vous donner des chiffres sur votre participation à l’OSS (combien de jours/mois sur les collaborateurs impliqués dans des projets OSS)?
Jérôme: Nous avons essayé divers modes de gestion des projets OSS, nous sommes arrivés à la conclusion que le plus simple et le plus efficace est de piloter ces projets comme tous les autres projets de la société, avec leurs objectifs de périmètre, qualité, coût, délai, et leur “client” qui est en général l’éditeur porteur de la solution, ou la structure de gouvernance pour les projets communautaires.
Pour donner des chiffres, notre contribution non-commerciale représente environ 1200 jh/an soit 10% de la capacité de travail de Serli. A tout cela il faut ajouter le temps passé volontairement par les Serliens en dehors de leur temps de travail sur ces projets, ce qui n’est parfois pas négligeable.

Agnès & Cédric: En quoi cela peut-il être bénéfique pour une SSII d’être impliquée dans l’OpenSource? As tu des chiffres sur ces retours ?
Jérôme:

  • D’un point de vue qualité, c’est un moyen pour les Serliens de maintenir un haut niveau d’excellence technique et une culture de la diversité des process d’ingénierie (nous nous intégrons avec les équipes des éditeurs).
  • En terme de positionnement d’entreprise, les bénéfices sont multiples : pour résumer je dirais visibilité, crédibilité & attractivité.
  • D’un point de vue business, la contribution est clairement un facteur de croissance et de diversification, mais je serais bien en peine de calculer un retour sur investissement :) Globalement c’est un choix de mode de fonctionnement et d’attribution de budgets. Par exemple notre budget publicité “classique” ou communication “pure” est très faible.

Agnès : Arrive-t-il que le client “paie” (sur un forfait par exemple, certaines parties du code peuvent être en licence OSS) : si c’est le cas, est-il toujours enclin à “donner” son code?
Jérôme: Nous rencontrons trois cas de figures :

  • Le financement de la contribution par effet de bord : les forfaits ou une partie du code est en licence OSS, et/ou donnant lieu à des petites corrections / évolutions de librairies OSS. La valeur ajoutée de la reversion est maintenant bien comprise par les donneurs d’ordre, notamment par la mutualisation de la maintenance du code contribué.
  • Certains clients nous achètent du temps de développement pour contribuer directement à des projets OSS, notamment pour accélérer la disponibilité de nouvelles fonctionnalités ou de corrections de bugs; la reversion est alors un des objectifs directs de la prestation.
  • Enfin, le Graal : des éditeurs OSS nous commandent directement des développements, pour réduire le time-to-market de nouvelles fonctionnalités.

Agnès : Au delà de l’OSS, quelles sont les activités “non commerciale” de Serli “pour la communauté (JUG Summer Camp…) ?
Serli anime le Poitou-Charentes JUG, et prend en charge chaque année l’organisation du Jug Summer Camp, une conférence ouverte et gratuite d’une journée, à La Rochelle, au soleil et avec des speakers de référence dans la communauté.
Nous donnons aussi un coup de pouces aux événements communautaires comme, cette année, le BreizhCamp.
Nous participons aussi à la diffusion du savoir en donnant des talks dans les Jugs, et dans les conférences comme Devoxx, JavaOne, JudCon.
Serli contribue également à l’avancée de la spec Java par son activité au JCP, notamment au sein de l’expert group CDI 1.1.

Alexis : Quelles sont les projets sur lesquels tu aurais envie que Serli participe et pour lesquels ce n’est pas (encore) fait ?

  • Jenkins : Nicolas Deloof, de CloudBees, nous a invité à collaborer à la création d’un plug-in pour gérer de façon simple et propre des build-pipelines, les premiers travaux sont prometteurs.
  • J’aimerais bien que nous apportions notre savoir-faire en sécurité et gestion des identités à ForgeRock (nous avons commencé à en parler avec Ludovic Poitou).
  • Il y a aussi des choses intéressantes que nous pourrions faire pour Play!, il y a déjà des initiatives personnelles de Serliens à ce sujet, comme le projet Play-CDI de Mathieu Ancelin.
  • Je pense aussi à OpenJDK.

Merci Marian et Jérôme! Rendez-vous donc le 21 février prochain au Lyon JUG! Les inscriptions pour la soirée sont ouvertes!

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer