Discussion :

[FranT]

Bonjour, tout est dans le titre. J'entends depuis quelques temps parler de ce langage de script (bien que pour certains il s'agisse plus que d'un script) et j'aimerais vraiment savoir quel intérêt il y a à vouloir s'en servir.
Dans quelles situations peut-on être amené à faire appel à Groovy (ou à un autre d'ailleurs)?
Si l'intérêt existe (et il semblerait que c'est le cas), j'aimerais bien ne pas passer à côté. Merci d'avance d'éclairer ma lanterne.

[moritan]

Bonjour, tout est dans le titre. J'entends depuis quelques temps parler de ce langage de script (bien que pour certains il s'agisse plus que d'un script) et j'aimerais vraiment savoir quel intérêt il y a à vouloir s'en servir.
Dans quelles situations peut-on être amené à faire appel à Groovy (ou à un autre d'ailleurs)?
Si l'intérêt existe (et il semblerait que c'est le cas), j'aimerais bien ne pas passer à côté. Merci d'avance d'éclairer ma lanterne.

Je vais te redonner quelques justifications donner par son créateur aux Tech days.
Il y en a d'autre mais j'ai pas tout en tête.

- facilité de déploiement pas de recompile et pas de redéploiement dans un environnement WEB.
- simplification du langage donc compréhension accrue par un non développeur, utile pour la modélisation de règle métier par ex.
-Fonctionnalité accru, il nous à fait une démo ou en quelques lignes son code à ouvert IE, ouvert une page WEB et fait un copier/coller vers un document Word.
- langage concis et rapide pour la réalisation de prototype
-framework type Grail

[natha]

Il est par exemple possible d'utiliser Groovy dans iReport pour réaliser certaines instructions java lorsqu'on construit un rapport (par exemple des tests d'égalité, des transformations de chaîne, etc...) sans coder directement en java.
Ca s'avère donc plus léger d'utiliser Groovy que Java dans ce cas.

[khamamouch]

Bonjour,

Je me permet de déterrer ce sujet pour vous demander si vous avez des retours sur l'utilisation de Groovy et de Grails sur des projets avec des contraintes assez fortes en terme de volumétrie, gestion des transactions, gestion des conccurences d'accès, et autres choses basiques que l'on retrouve sur une application serveur (classique) codée en Java.

Est-ce que ça tient le coup, les perfs sont-elles bonnes, est-ce qu'on s'amuse bien pendant le dev et le debug, etc... tout un tas de questions dont j'aimerais avoir des réponses

Une autre question, et non des moindres, quelle est la courbe d'apprentissage (on va séparer Groovy lui même et Grails) pour avoir un niveau autonome et acquérir de bonnes pratiques, coder proprement et performant ? En clair si je lis Groovy In Action, est-ce que j'ai une autonomie sur le codage lui-même (l'organisation, avec Grails par exemple, c'est sans doute différent) ?

Voilà, je sais que j'ai un gros train de retard sur la techno mais comme j'ai envie de me lancer dans d'autres languages de la JVM et estimer les charges de dev, je me pose tout un tas de questions que des professionnels/pratiquants seront plus à même de répondre.

Merci d'avance

[madfu]

Salut,

Ce genre de retour m'intéresserait aussi, en attendant concernant les performances de Groovy je suis tombé là dessus
Je suis en train d'écrire un DSL pour faire de l'import de données je te donnerais des news

quelle est la courbe d'apprentissage (on va séparer Groovy lui même et Grails) pour avoir un niveau autonome et acquérir de bonnes pratiques, coder proprement et performant

Tout dépend des capacités de chacun mais je pense que si on vient du monde Java (et globalement du monde statique) le langage peut dérouter, ça a été mon cas au tout début

Je recommande effectivement la lecture approfondie d'un livre Groovy avant de démarrer un projet par contre je ne connais pas "Groovy in action", personnellement c'est un l'utilisant au quotidien, en regardant la doc du site (qui est assez complète) le code d'autres API, que j'ai fini par adopter petit à petit de bonnes pratiques ou du moins des pratiques me permettant de mieux tirer profit du langage.

Ce que je peux dire aussi côté bonnes pratiques c'est que j'écris beaucoup plus de tests depuis que j'utilise Groovy parce que sa souplesse implique tout de même une certaine rigueur

Maintenant que je me sens plus à l'aise je m'éclate, j'écris du code plus souple et plus simple (dans la syntaxe et l'organisation) et il me faudrait de bonnes raisons pour entamer un nouveau dev en Java

[ZnhaarX]

Bonjour,

Alors en ce qui concerne le Groovy et son utilisation, il est aussi utilisé dans les outils de build en java.

A l'heure actuelle tu trouves comme principaux outils de build Maven et Ant/Ivy (les plus utilisés selon moi).
Quoiqu'il en soit, tu trouves aussi un outil de build plus récent qui s'appelle Gradle. Ainsi, la gestion de dépendances se fait via un fichier qui est écrit entièrement en Groovy. De même, je crois que Maven3 a la possibilité d'utiliser le Groovy pour déclarer les dépendances d'un projet.

Ce n'est pas forcément l'utilisation de Groovy la plus pertinente qu'il soit (dans le sens où l'on exploite pas pleinement ses possibilités), mais ça te donne déjà un bon exemple concret de pourquoi il est utilisé.

Il faut préciser qu'à la base, les dépendances dans les outils de build sont plutôt déclaré dans un fichier XML. Donc, l'utilisation de Groovy ici est plus avantageuse dans le sens où c'est beaucoup moins verbeux que le XML et plus puissant.

[khamamouch]

Oui j'ai constaté que pas mal de projets se sont créés autour de Groovy ou Groovy/Java et qu'en ce moment c'est l'affrontement entre les langages de la JVM à coup (entre autre) de tu es plus lent que moi, etc... or le choix d'un langage est important (pour se changer les idées aussi, voir ce qui se fait dans d'autres )

Mais le problème avec les tutos et vidéos que j'ai pu voir, c'est que c'est toujours un peu la même chose présentée (exception faite d'une sur un Tweeter avec Grails). Je ne peux pas encore attaquer vraiment le langage et Grails pour le moment d'où mes questions un peu naïves destinées à des personnes qui peuvent faire un retour d'XP sur un projet full groovy ou mixte pour savoir ce que ça tient. (Si ça se trouve, la réponse est dans les livres :p )

[Robin56]

Je ne peux pas encore attaquer vraiment le langage et Grails pour le moment d'où mes questions un peu naïves destinées à des personnes qui peuvent faire un retour d'XP sur un projet full groovy ou mixte pour savoir ce que ça tient. (Si ça se trouve, la réponse est dans les livres :p )

J'ai participé à un projet en full Grails/Groovy il y a quelque temps (j'entends un vrai projet avec vrai client et tout et tout). Sa taille était assez réduite. Il consistait à une application de gestion :
+ La rapidité de développement qui a permis de rendre un projet en avance ! (Grails dans une appli. full-gestion c'est super efficace)
- L'intégration dans l'IDE (il y a 1 an, l'intégration du Groovy dans un IDE, ça consistait à développer sous Notepad, je ne sais pas si ça a changé).

Il est à noté aussi que je suis partis d'un projet sans aucune compétence Groovy/Grails avec un timing plutôt serré. Voilà pourquoi je peux dire que "c'est super efficace". Sinon niveau performance, je n'ai pas vu de différence avec une application comparable en J2EE. Mais je rappelle que l'application ne disposaient pas de contraintes en terme de connexion ou d'utilisation super élevées non plus. Voilà, je ne sais pas si ce témoignage te servira.

[nopnop77]

Bonsoir,

J'ai eu l'occasion de travailler,et c'est toujours le cas mais en tant que presta , pendant 2ans pour un site communautaire doté d'un webservice Grails. Son rôle est de gérer de façon intelligente les données et les contenus des pages via un moteur de règles (DROOLS).

Environnement côté webservice:
Tomcat <= Grails/Groovy + DROOLS => hibernate+JNDI => MySQL

Je synthétise grossièrement les choses:

Points forts pour le couple Groovy/Grails:
- Groovy: on se forme vite à ce langage, très simple et productif, presque plus proche du Javascript que du Java bizarrement. Dans son contexte, il est toujours possible de passer en Java pur ou d'inclure des lib Java sans problème. Le scripting groovy est intéressant aussi. L'écriture ou la réécriture d'algo se fait de façon plus compacte et lisible.
- Grails: Couche web, combinaison judicieuse entre hibernate+spring+groovy (de base), on peut obtenir de cela une très bonne architecture web et des manipulations aisées avec les données en base dû au langage groovy.

Points faibles:
- Groovy: On peut se laisser aller et ne plus rien typer. Lorsque plusieurs sont amenés à lire ou poursuivre le code, tout doit être parfaitement commenté si l'on veut du code parfaitement maintenable.
- Grails: Devient coûteux si on ne le configure pas bien. Attention à ne pas alourdir les services, car ces instances de classes sont permanentes. D'un autre côté, il faut également bien gérer les caches selon le taux de montée en charge de votre appli. De mon cas, avant le passage dans le moteur de règles, un contexte assez conséquent d'objets, extraits de la base, devait être créé.

Evidemment mon expérience ne permet pas de juger la qualité de la couche view (gsp/jsp) mais vue que la demande du post était plus centrée sur groovy que grails. J'ai eu aussi l'occasion de travailler sur serveur de jeu en groovy. Globalement, ces langages s’inscrit bien dans les développements AGILE d'application, à la portée d'une entreprise qui souhaite un produit correcte et plutôt rapide à mettre sur pied.

A bon entendeur.

[nopnop77]

IntelliJ est l'idéal à mon goût. Netbeans et Eclipse permettent également de développer en Groovy/Grails.

J'ai participé à un projet en full Grails/Groovy il y a quelque temps (j'entends un vrai projet avec vrai client et tout et tout). Sa taille était assez réduite. Il consistait à une application de gestion :
+ La rapidité de développement qui a permis de rendre un projet en avance ! (Grails dans une appli. full-gestion c'est super efficace)
- L'intégration dans l'IDE (il y a 1 an, l'intégration du Groovy dans un IDE, ça consistait à développer sous Notepad, je ne sais pas si ça a changé).

Il est à noté aussi que je suis partis d'un projet sans aucune compétence Groovy/Grails avec un timing plutôt serré. Voilà pourquoi je peux dire que "c'est super efficace". Sinon niveau performance, je n'ai pas vu de différence avec une application comparable en J2EE. Mais je rappelle que l'application ne disposaient pas de contraintes en terme de connexion ou d'utilisation super élevées non plus. Voilà, je ne sais pas si ce témoignage te servira.

[Robin56]

IntelliJ est l'idéal à mon goût. Netbeans et Eclipse permettent également de développer en Groovy/Grails.

Ça fait un petit moment que je n'ai pas retouché à Grails mais à l'époque je développais sous Eclipse. Et tout ce qui était auto-complétion, affichage du code groovy était plutôt mal géré. L'auto-complétion était parfois non disponible.

Je n'ai jamais développé sous IntelliJ ou NetBeans donc ma remarque concernait Eclipse mais merci du tuyau.

[professeur shadoko]

j'ai développé pour nos besoins internes un framework de test qui utilise groovy à la fois dans son code et comme base au langage de description de tests.
la "vision" groovy des codes java me permet de spécifier ces tests de façon élégante et pratique. Bien entendu un code de description de tests n'est pas une application avec tout ce que ça comporte de soucis de génie logiciel (maintenabilité, travail en équipe, etc.) donc la souplesse de ces petits scripts et la proximité avec Java font de Groovy un outil vraiment interessant.

[Robin56]

la "vision" groovy des codes java me permet de spécifier ces tests de façon élégante et pratique.

La "vision" Groovy permet aussi je trouve d'écrire des Beans épurés et très lisible.

[professeur shadoko]

La "vision" Groovy permet aussi je trouve d'écrire des Beans épurés et très lisible.

tant que ces beans ne sont pas support de code métier! (point de religion: j'estime que les beans sont une émanation du malin , j'en suis à utiliser des ruses diaboliques pour retirer tout pouvoir de malfaisance aux beans de mes petits camarades)

[Robin56]

tant que ces beans ne sont pas support de code métier! (point de religion: j'estime que les beans sont une émanation du malin , j'en suis à utiliser des ruses diaboliques pour retirer tout pouvoir de malfaisance aux beans de mes petits camarades)

Moi je parlais surtout des Beans utilisés avec l'ORM sous Grails. Qu'as tu contre eux ?

émanation du malin

Ézéchiel 25, verset 10.