Tag :Groovy

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!

Devoxx 2010

devoxx10-120x240-blackDevoxx est une conférence européenne indépendante qui porte sur les technologies Java/JVM . Organisée en Belgique, à Anvers, elle nous permettra d’entendre du 15 au 19 novembre 2010 des speakers de haut niveau. Un peu moins de 3000 développeurs venant de plus de 40 pays différents s’y retrouvent chaque année.

Les conférences

Les University Days.

Les 2 premiers jours sont appelés les University Days. On y retrouve principalement des ‘University Talks’, des conférences de 3 heures qui abordent un sujet en profondeur. Il y a à chaque fois plusieurs conférences sur un même créneau horaire. Les sujets sont variés, la plupart sont techniques. Ainsi, on retrouve des sujets :

Chacun peut participer à 2 sessions de 3 heures par jour, une le matin et l’autre en début d’après midi. Ensuite, place aux ‘Tools in action’. Ce sont des petites sessions de 30 minutes qui permettent aux speakers de nous faire découvrir un outil auquel ils ont participé. Les sujets sont variés, d’une présentation de spring developer tools (que j’apprécie énormément au quotidien), à visual VM (outil de monitoring) en passant par Apache Mahout.
Entre 19 et 22h, ont lieu des BOF (Bird-of-a-Feather) qui diffèrent beaucoup de tous les autres types de conférences.
Elles réunissent peu de personnes et sont beaucoup plus informelles. Elles sont généralement menées par un ou deux speakers de manière libre. Parfois, il y a une brève présentation puis des questions, parfois ce sont des discussions ouvertes sur un sujet précis. Actuellement, le planning n’est pas finalisé sur les BOFs.

Les Conference Days

Pour les 3 jours suivants, du mercredi au vendredi, le format diffère. Les conférences  ne sont plus de 3 heures mais d’une heure : cela permet de voir bien plus de sujets différents mais de manière un peu plus superficielle. Les sujets là encore tournent autour des mêmes thèmes dans 5 salles différentes. Les sessions ‘Tools in action’ disparaissent au profit des Quickies, qui durent 15 minutes pendant la pause déjeuner.

Duchess à Devoxx

Les duchess seront présentes toute la semaine à Devoxx et plusieurs nationalités seront présentes (France, Belgique, Hollande …). Le jeudi soir, les Duchess organiseront une BoF pour discuter en petits groupes (6) autour de sujets choisis sur le thème ‘Les femmes dans l’informatique‘.

Ce que j’aime à Devoxx

Pour un prix raisonnable, Devoxx apparait comme un des principaux rendez-vous européen. Les speakers y sont accessibles et l’organisation bien rodée. En une semaine, cela permet d’améliorer fortement sa ‘culture générale Java’, surtout si l’on est débutant. Anvers n’est qu’à deux heures de Paris en Thalys, les hôtels y sont à un prix abordable. Bref, pour un investissement moyen, cela permet vraiment de progresser au niveau technique et de rencontrer énormément de monde, ce qui est toujours un avantage. Certaines SSII l’ont bien compris et y envoient chaque année plusieurs consultants.  Ceux qui n’ont pas une entreprise pour les y envoyer peuvent tout à fait se le permettre au niveau financier. Les conférences sont bien sûr des endroits où l’on apprend beaucoup, mais toutes les discussions ‘off’ pendant la pause déjeuner ou autour d’une bière le soir permettent d’avoir des retours d’expérience très intéressants.

Infos Pratiques

Au niveau de la gestion à proprement parler, pour ceux qui assiste aux University Days, deux possibilités : soit dormir sur place le dimanche soir, soit il est tout à fait possible de prendre l’un des premiers Thalys, de passer à l’hôtel si celui ci est proche de la gare et en ne perdant pas de temps de prendre le tramway pour assister aux premières sessions.
Pour les hôtels, les français semblent se regrouper cette année à deux endroits différents : l’Agora (qui devient à partir d’octobre le ‘all seasons Antwerpen City Center’) et le Park Inn qui sont tous les deux placés juste à côté de la gare. Il vaut mieux éviter de prendre les hôtels qui semblent plus proche de la salle pour deux raisons : ils sont mal desservis en transport en commun et cela veut dire également que vous ferez le chemin seul le soir et le matin.
L’année dernière, le petit déjeuner était compris dans la conférence, tout comme le repas du midi.
Au niveau du train du retour pour le vendredi, beaucoup prennent les thalys de 14h30 ou de 15h30, et certains y restent le week end pour découvrir la Belgique !

Le Paris Groovy Grails User Group #1

Groovy User Group #1

Groovy User Group – Les organisateurs

Et un UG de plus …

Cette fois ci c’est le Paris Groovy Grails User Group qui a tenu sa première réunion le 10 juin chez VMWare. Deux autres sponsors ont également participé à cette soirée, Doc4Web qui a fournit le buffet et Balsamiq.

Une quarantaine de personnes pour cette première session (le programme), avec les habitués, quelques nouvelles têtes par rapport aux user groups Java, et pas mal de filles (environ 10% ce qui est un bon score pour des conférences techniques).

Pour le lancement de ce groupe, une session de présentation : quelles seront les activités de ce groupe, qu’est ce que Groovy, les principaux concepts, pourquoi c’est cool, et un tour d’horizon des principaux projets qui gravitent autour de Groovy.

Dans les activités prévues les classiques des UG (présentations, débats, sorties restau) mais aussi une originalité : organiser des soirées de coding.

Vous pourrez suivre l’activité de ce groupe sur Meetup à l’adresse suivante http://www.meetup.com/Paris-Groovy-Grails/

Groovy

Guillaume Laforge nous a présenté les principales caractéristiques de Groovy, le langage qui nous simplifie la vie :

  • Un langage dynamique
  • Des Closures, des blocs de code réutilisables que l’on peut manipuler comme des variables
  • Le typage optionnel
  • Le support de l’expression langage ( ${mavariable} )
  • les GString qui permettent d’étendre les chaînes (support de l’expression langage, chaînes sur plusieurs lignes, padding …)
  • Les facilité de création d’initialisation des collections
    Une liste fruits = ['Pomme', 'Orange']
    ou une map contact = [prenom='Guillaume', nom='Laforme']
  • La facilité de manipulation des documents XML (XmlParser, MarkupBuilder)
  • La facilité de création  de requêtes JDBC, d’IHM Swing ou plus généralement l’utilisation de templates et de DSL via les MarkupBuilder
  • Des opérateurs rigolos comme l’opérateur elvis ?: qui permet de simplifier l’écriture de l’opérateur ternaire en nom ?: 'anonyme' dans le cas où on veut juste vérifier que le nom existe ou l’opérateur ?. qui permet d’écrire un chemin de navigation dans des objets sans devoir vérifier la présence de valeur nulle à chaque étape
  • La manipulation de fichiers ou de résultats de requêtes SQL aussi simple que manipuler une collection

Groovy Elvis operator

Elvis operator

Pourquoi l’adopter ?

  • Tourne dans la JVM, portable et en général déjà présente
  • Intégration très complète avec Java (du code Java fonctionne dans Groovy même si ça n’est pas le but et les librairies Java sont utilisables
  • Prise en main très rapide pour les développeurs Java
  • Rapidité d’écriture du code

Pour avoir un peu codé en Groovy, c’est vrai que  la prise en main par un développeur Java est rapide, en particulier si on a l’habitude d’autres langages de scripting (Python dans mon cas) et de la programmation fonctionnelle.

C’est terriblement pratique pour écrire le code de test ou des scripts qui moulinent des fichiers et génèrent des rapports. Il y a bien sûr une contrepartie à cette productivité. Les manipulations de fichiers ne sont pas aussi instantanées que dans mes scripts Python et le débugging n’est pas toujours simple lorsque le typage optionnel ne produit pas le type qu’on suppose. Mais dans l’ensemble ça permet de réaliser très vite des outils dont on a besoin.

Groovy User Group #1

Groovy User Group – Les participants (si, si, il y a deux autres filles au fond)

Après une pause au buffet, Guillaume nous a présenté l’écosystème Groovy

L’écosystème

Groovy est utilisé dans un grand nombre d’outils de test ou de reporting. Ces activités ne sont pas critiques et la facilité d’usage de Groovy permet de mettre en pratique rapidement ses idées.

Il est également utilisé (via Grails en particulier) pour le développement d’IHM de ces outils.

Enfin un autre usage privilégié est l’utilisation de Groovy comme langage de commande, pour exprimer des règles métier ou des DSLs.

Même si Groovy peut utiliser les librairies Java, de nouvelles librairies plus dans l’esprit Groovy et plus intégrées sont également mises au point. Et pour finir, tous les outils pour faire du Groovy.

Voici un tour d’horizon

La gestion de dépendances :

  • Grape (The Groovy Adaptable Packaging Engine or Groovy Advanced Packaging Engine) et la commande @grab

Des librairies complémentaires :

Des frameworks applicatifs écrits en Groovy :

Des frameworks de test écrits en Groovy :

Des outils de build :

Un discours du directeur technique de VMWare, quelques questions des participants et on attend déjà la prochaine session pour en voir plus. En attendant, nous voilà avec plein d’idées en tête pour se simplifier la vie et des tas de nouveaux trucs à essayer.  Intéressés mais un peu paresseux  ? Grace à une application Gaelyk, vous pouvez tester Groovy en ligne sans rien installer.

La prochaine rencontre aura lieu le 20 Juillet :  http://www.meetup.com/Paris-Groovy-Grails/boards/view/viewthread?thread=9320461

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