Pour les fêtes de fin d’année, offrez un petit bench à votre application préférée :
une soirée dédiée au Lyon JUG, mardi 21 décembre, animée par Claude Falguière.
C’est désormais une tradition gravée dans le marbre : préparez-vous avec l’interview teasing par les JDuchess.
Inscription et informations pratiques, as usual, sur la page officielle du Lyon JUG.
A mardi!
Nouvelle soirée au Lyon JUG, mardi 23 novembre : Gradle vs Maven 3.
Les JDuchess continuent leur teasing contributif avec des interviews des intervenants, permettant de venir profiter de la soirée plus armés sur les enjeux et perspectives de chacun de ces outils de construction : interview d’Arnaud Héritier sur Maven 3, et interview de Grégory Boissinot sur Gradle.
Inscription et informations pratiques, as usual, sur la page officielle.
Après une pause estivale, le Lyon JUG est de retour!
Il reprend son rythme habituel, et son moyen quasiment mnémotechnique : chaque troisième mardi du mois, toujours à l’Epitech.
La soirée du 21 septembre sera consacrée aux nouveaux systèmes de gestion de configuration décentralisée : GIT et Mercurial.
Le
s développeuses seront plus que jamais conviées : on y annoncera la création de l’antenne lyonnaise de JDuchess. Leur activité commence par une interview des intervenants à cette soirée.
Inscription et informations pratiques sur la page officielle.
Le dernier Paris JUG avant la pause estivale était consacré entièrement à Java EE 6.
Adam Bien, membre du JCP et Java champion, nous a fait une présentation en deux parties : d’abord les concepts et ensuite des exemples de code en direct.
Les concepts.
L’utilisation des annotations et du principe de « convention over configuration » fait souffler une brise légère sur notre vision de Java EE !
Java EE se veut maintenant rapide, simple, léger, « lean » et permettre des cycles de développement court. Bien sur la comparaison avec Spring arrive très vite : Spring nécessiterait plus de configuration et Java EE 6 serait plus basé sur les conventions.
D’abord j’aimerais insister sur le principe de « convention over configuration » qui a fait le succès de frameworks très productifs tels que Ruby on Rails, Grails ou encore Play. Si l’ensemble reste fortement configurable dans la joie des fichiers XML, ce principe permet d’alléger considérablement le travail de développeur et donc de le rendre plus productif. Cela permet aussi d’avoir un framework plus cohérent.
Adam Bien nous fait un retour sur l’ensemble des concepts phare de l’architecture : ECB, SOA et DDD.
Il nous présente d’abord le pattern Entity Control Boundary qui est un pattern similaire à MVC et son application avec JEE 6. Il en vient ensuite rapidement au concept du Domain Driven Design qu’il met en avant ! Ce qui fera plaisir à certains 
L’idée est d’avoir des entités riches et réellement utiles et d’enlever la couche DAO. Les domaines sont mis en avant au détriment des services. La logique s’oppose donc à l’architecture SOA classique qui s’articule autour du trio Service/DAO/Domain. C’est une approche avec état qui permet alors d’adresser certains problèmes plus simplement et de remettre la complexité du métier au sein de l’application. La synchronisation entre les objets et la base de données se fait grâce à JPA/Hibernate. Elle permet aussi d’avoir moins de couche technique et s’interface très bien avec REST.
Il présente aussi la facilité de mettre en place la vue avec JSF 2 qui permet d’accéder directement à des Managed Beans ou à des EJB, grâce à un Expression Language. La couche de configuration de la vue en devient presque inexistante.
Il fait bien sur le tour des apports et des nouveautés de Java EE 6 :
Dans la deuxième partie de cette soirée, Adam Bien fait le tour en direct des principales fonctionnalités de Java EE 6.
En conclusion, pour quelqu’un qui, comme moi, n’a pas une grand expérience sur toute l’architecture SOA et qui fuit les fichiers de configurations, Java EE 6 semble clair, facile à prendre en main et réellement efficace ! La mise en avant de l’approche DDD est aussi de bonne augure la qualité des applications.
Allez pour compléter, vous trouverez d’autres excellents résumés ici :
Tout d’abord, les différentes annonces qui ont eu lieu durant la soirée hier :
Entrons dans le vif du sujet ! La première partie de soirée est orientée « Share » avec un retour d’expérience sur le passage d’un CVCS (Gestionnaire de sources centralisé) à un DVCS (Gestionnaire de sources distribué) suivi d’une présentation du DVCS qui monte : Git. La seconde partie de soirée nous fourni une présentation de Maven 3 et de Deploy It.
La présentation du sujet a été faite par Sébastien Douche qui nous fait donc ici un retour d’expérience sur un ton décalé et des slides épurées … très agréable.
Arrivé il y a 2 ans dans son entreprise actuelle, il fait le constat de la (classique) sous utilisation de SVN et après analyse du problème, migre vers un DVCS. Son crédo : les tests automatisés et l’outil de versionning sont les 2 filets de sécurité indispensables à un développement logiciel.
Après avoir tenté une évangélisation des bonnes pratiques SVN, il constate tout de même une dégradation régulière de la qualité, impliquant une démotivation (il parle de souffrance) des développeurs allant se poser la question ultime : a-t-on fait le boulot qui nous a été demandé ?
Le problème ne se situe pas au niveau du travail effectué… mais vient plutôt du fait qu’il n’est pas bien partagé ! Notamment avec un phénomène de « micro-merge » : pour exagérer, les développeurs font des commit de chaque ligne de code modifiée pour éviter d’avoir un trop gros merge à faire par la suite ! Ce qui implique une version constamment instable sur le serveur d’intégration et des difficultés à savoir où l’on en est dans le projet.
Une première solution pointe le bout de son nez : si on faisait des branches SVN ? Hum … Attendez, je crois qu’on tente de nous expliquer comment éviter ça :-)
En règle générale, les outils de versionning centralisés sont utilisés principalement pour faire du suivi d’historique … et non leur boulot. On souhaite donc : un environnement constamment stable afin de connaitre l’état du projet tout le temps !
Pour cela, on va isoler le travail des développeurs en repensant notre façon de travailler, via une analyse des besoins réels, 3 workflows sont identifiés :
L’important, donc, est que ces workflows soient déconnectés les uns des autres.
Une fois la mise en place effectuée, le constat est le suivant : le développeur est concentré sur SON travail et non sur celui du voisin par peur des impacts qu’il pourrait-y avoir sur le sien. Avec cette fois un commit par fonctionnalité sur le repository central, plus de souplesse avec notamment la possibilité de faire de la revue de code et/ou une démonstration pour une et une seule fonctionnalité !
Il est à noter que ces nouveaux outils sont orientés contenu et non changement. Je pense que tout le monde s’accorde pour dire que SVN ne sais pas gérer le renommage de fichiers par exemple ! On voit donc disparaitre les dossiers ‘.svn’ et l’on gagne énormément en place et en vitesse.
En bonus, des repository sont accessibles en ligne. Un outil de binding permet une transition douce en intercalant le DVCS entre le développeur et son SVN.
Je crois que sa conclusion était plutôt claire :
Libérez-vous : utilisez un DVCS
Présentée par David Gageot, très proche et complémentaire de la session précédente. On part sur le même ton puisque qu’il commence par reprendre la conclusion de Sébastien Il insiste notamment sur le fait qu’un outil est fait pour ouvrir des possibilités … et non en fermer !
Git est donc un DVCS, le plus connu avec Mercurial. Pour faire court :
Mais pour l’utiliser à pleine puissance, il faut oublier comment SVN fonctionne !!!
En général, on ne fait pas de merge avec ce type d’outils.
Il nous fait ensuite une démo rapide d’une fonctionnalité majeure : bisect.
L’idée est de retrouver quel commit a cassé le build. Avez-vous déjà tenté le coup avec SVN ?
L’idée ici est de donner à cette commande un commit qui ne cassait pas le build ou les tests, celui qui ne fonctionne plus et le test à effectuer (manuel ou automatique). Et par dichotomie, elle va retrouver la version qui a cassé le build.
On peut pousser plus loin :de ce fait, il est possible de jouer un nouveau cas de test (qui devrait passer mais ne passe finalement pas), sur des anciens commit !
En effet, il est tout a fait envisageable (d’autant plus que c’est ce que David a mis en place dans son entreprise) d’écrire un script qui fait un « private build » avant de faire le commit réel seulement si ce build réussi. Cela est rendu possible par les performances de Git et il est tout à fait possible de travailler en même temps que ce script fonctionne.
Il y a énormément de nouveauté dans Git qu’il n’est pas possible de présenter dans le cadre du Paris JUG. Il nous conseille donc le livre Pro Git.
Il répète Sébastien en confirmant qu’il est possible de passer à Git en une commande : Git va importer le contenu du SVN et agir comme passerelle bidirectionnelle.
2 commiters Maven, Nicolas De Loof et Arnaud Héritier nous présentent Maven 3. La présentation est dynamique mais je reste sur ma faim quand aux nouveautés du produit : elles sont quasiment inexistantes … pour l’instant.
En effet, le gros sujet, de cette version était une remise à plat des bases avec une refonte du produit (Passage à Java 5) et l’écriture d’une batterie de tests à priori impressionnante. L’écriture de plugins en revanche devrait être simplifiée grâce aux nouvelles API.
Un build plan est mis en place : les plugins pourront savoir ce qu’il s’est passé auparavant dans le buid et donc travailler en conséquence. Notamment le plugin Eclipse pourra laisser Eclipse faire sont boulot (compilation incrémentale) et en tirer bénéfice.
Les pom pourront être écrits dans d’autres langages (groovy, python, …) et les profils ont été revus.
Une version 100% compatible avec les pom existants via un simple changement de MAVEN_HOME. Les impacts possibles se situent au niveau du plugin site qui n’est pas ou pas bien supporté et éventuellement dans les descripteurs de projet qui sont plus contrôlés.
Le gain que l’on peut avoir aujourd’hui en migrant se situe principalement sur les performances et de meilleurs logs.
Il y a peu de risques de régressions, et le passage de Maven 2 à Maven 3 devrait faire gagner du temps. Pour les développeurs Maven et/ou de plugins, le coût d’entrée est maintenant beaucoup plus bas étant donné la refonte. De ce fait la communauté revit et le produit se professionnalise.
La soirée se finit avec la présentation d’un outil d’automatisation des déploiements Java, réalisé par la société XebiaLabs. La présentation de l’outil est faite par Guillaume Bodet et Benoit Maussaud.
Le produit ne se contente pas d’une simple copie de WAR/EAR mais gère aussi :
Je dois avouer que je me suis arrêté là dans la présentation, l’outil n’étant pas open source et ayant l’air plutôt complexe pour une problématique ne me concernant pas …
Lundi soir (29 mars) c’est la 2ème soirée de l’Alpes JUG.
Arnaud Héritier, membre de la communauté Apache Maven et auteur d’un bouquin sur le sujet, vient présenter les nouveautés de Maven 3 ainsi que des retours d’expérience sur son utilisation dans une forge logicielle.
Si ça vous intéresse, n’hésitez pas à vous inscrire sur le site de l’Alpes JUG.
Rdv à 18H30 (début de conf à 19H) à l’amphi E de l’ENSIMAG.
PS : ne le répétez pas, mais Objet Direct est désormais sponsor de l’Alpes JUG. Plus de détail bientôt 
La soirée du Paris JUG a commencé par une présentation de JDuchess : communauté féminine autour de Java. Il s’agit d’un groupe international qui a été fondé en Hollande.
Ensuite, la soirée « Emmanuel Bernard » s’est déroulée en deux parties : la première sur Hibernate Search et la seconde sur le design des APIs.
Première partie : Hibernate Search : recherche full-text pour des applications utilisant Hibernate.
Pour la recherche, il existe plusieurs modules de recherche full-text (par exemple avec SQL Server). Cependant, il n’existe pas de standard sur ces modules de recherche. Une autre solution pour réaliser de la recherche full-text est d’utiliser une librairie. Hibernate Search est basé sur « Lucene », il permet de réaliser une recherche full-text avec les caractéristiques suivantes :
La recherche full-text va s’appuyer sur un analyseur et plusieurs filtres. Parmi les filtres, on peut mettre tout en minuscule (recherche insensible à la case), enlever certains mots (le, la les).
Il y a plusieurs techniques qui permettent de comparer deux mots et donc qui permettent une recherche :
D’un point de vue technique :
@Indexed mise sur une entité permet de l’indexer en full-text. L’index sera mis à jour pour toute modification de l’entité.@Field crée un champ de recherche dans LuceneRemarque : La recherche full-text se réalise uniquement sur du texte, des chaînes de caractères, Hibernate Search possède donc ses propres convertisseurs (date…)
Il est possible d’utiliser l’annotation @Fields qui permet de définir plusieurs types de recherche sur le même attribut. Il est possible de pondérer les différents critères. Par exemple, un mot trouvé dans un titre aura une meilleure pertinence que le même mot trouvé dans la description.
Astuce : il peut être judicieux de mettre plusieurs fields sur le même attribut pour pouvoir ajuster la pondération même en production.
Conclusion : Lucene est assez bas niveau, il peut donc être assez complexe à utiliser. Hibernate search est plus facile à mettre en place et permet de se concentrer sur le moteur de recherche.
Deuxième partie : Design d’API
Cette partie nous a exposé les bonnes pratiques pour faire de bonnes API (donc qui seront facilement utilisables par un maximum de personnes).
Bon pattern : method chaining pattern. La méthode renvoie l’objet lui-même, on peut donc appeler des méthodes à la chaîne.
Conclusion : pour une API, rendez les choses difficiles pour vous et simples pour les autres. Pour faire de bonnes APIs, il faut essayer et réessayer, penser aux utilisateurs et au futur de l’API.
Merci à Emmanuel Bernard pour cette soirée riche en enseignements. Une bonne présentation illustrée par de nombreux exemples de code et de démonstrations. Pour en savoir plus sur lui : http://blog.emmanuelbernard.com
Pour en savoir plus sur cette soirée, et si vous avez un compte google wave, une wave détaillant la dernière soirée du Paris JUG est accessible ici.
C’est bientôt le troisième mardi du mois.
OK, rien d’extraordinaire : c’est le cas tous les mois depuis que Dieu a créé la Terre en 7 jours (alors qu’Il a mis grosso modo 4,54 milliards d’années pour créer Java, c’est dire le niveau de maturité du truc).
Mais tous les troisièmes mardi du mois, c’est une nouvelle soirée au Lyon JUG, dont Objet Direct est un tout récent nouveau sponsor platinium.
Ce mardi 23 février, soirée JavaEE6, animée par Antonio Goncalves : pas moins qu’un Java Champion qui participe aux JSR des APIs Java EE 6, écrit des livres de référence sur JavaEE, et a accessoirement fondé le Paris JUG, premier JUG en France. Il continue sa tournée, après son passage à l’Alpes JUG.
Certes, ce n’est pas Dieu (Il demandait trop cher pour intervenir), mais on devrait donc pouvoir s’attendre à des informations plutôt pertinentes.
Inscription et détails pratiques : sur la page officielle, as usual.
Le Alpes JUG (Java User Group) consacre sa première soirée au Java EE 6.
Elle se déroulera le lundi 22 Février 2010 à UFR IMAG 60, rue de la Chimie dans l’amphithéatre F018 (Domaine universitaire de Saint-Martin d’Hères et Gières, à côté de Grenoble)
Détails pratiques et inscriptions sur la page officielle.
Le 25 février prochain aura lieu le premier Spring User Group français (SUG). A ne pas confondre avec l’autre SUG (Scrum User Group) !
La première session est consacrée à la présentation des nouveautés de SPRING 3.0. Elle sera animée par Arnaud Cogoluègnes.
Pour plus d’informations, je vous invite à vous rendre à l’adresse suivante : http://springusergroupfr.eventbrite.com/.
Derniers commentaires