Groovy trend grails / groovy

[zorla]

hi

bin grad überlegen groovy / grails für ein frontend projekt in financial bereich einzusetzen, da in diesem projekt viel flexibiltät und ständig änderungen gewünscht sind, dabei eine gewisse komplexität mit cross field validatierungen und ajax abhängige sichbarkeit von feldern etc.

aus dem bauch heraus hätte ich mit grails und vorallem groovy ein ganz gutes gefühl, allerdings sagt mir ein anderes gefühl, dass grails im allgemeinen nicht mehr auf so viel gegenliebe zu stossen scheint, wie das mal ürsprünglich prophezeit wurde.

daher würde mich dringend eure meinung interessieren, ob es überhaupt sinnvoll ist grails zu verwendung und vorrallem wie der trend ist.

danke.

gruß
zorla

 

[Gelöschtes Mitglied 5909]

Gerade im financial Bereich würde ich das nicht machen. Da wäre mir das Risiko einfach viel zu hoch, wenn da irgendeine Sache nicht funktioniert wo grails im Hintergrund magic macht und du nicht genau weißt warum das jetzt nicht funktioniert, dann siehst du alt aus und stehst blöd da.

Desweiteren habe ich in der Vergangenheit festgestellt, dass man nicht ohne weiteres von z.v. version 1.1(.x) auf version 1.2(.x) updaten kann. Da war es zumindest bei mir so, dass dann erstmal garnichts mehr funktioniert hat. Dann benutzt man bei grails ggf. Plugins. Die können dann auch nicht mehr funktionieren, oder sind nicht mehr aktuell (und werden nicht aktualisiert) etc. pp.

Für kleine Sachen die nicht kritisch sind und auch nicht besonders viele Nutzer haben, würde ich es durchaus nutzen.
Aber gerade im financial Bereich ehrlich gesagt auf keinen Fall. Da würde ich aber auch kein Lif/scala oder ruby on rails nehmen,
sondern Java (Spring/ JEE) mit JSF/Wicket/Tapestry.

Meine Meinung.

 

[bygones]

Gerade im financial Bereich würde ich das nicht machen. Da wäre mir das Risiko einfach viel zu hoch, wenn da irgendeine Sache nicht funktioniert wo grails im Hintergrund

sorry, das ist unsinn. Natürlich machen Groovy bzw Grails einem eingefleischten Javaianer zuviel magic, doch es ist nicht so, dass das Verhalten von Grails unvorhersehbar bzw nicht deterministisch ist. Es folgt gewissen Regeln - nicht irgendwelchem Hokuspokus.

Das Vorziehen von J2ee/spring etc basiert imo nur eben der Erfahrung und der Wertschätzung dieser Tools, nicht der qualitiativen Minderwertigkeit von groovy/grails.

@zorla
Auch wenn ich im Grunde nichts gegen einen einsatz von Grails in Großprojekten habe, so ist das eine wirklich schwerwiegende Entscheidung. Mal so eben, weils im Trend liegt, eine Applikation, die nicht ein Hobbyprojekt ist, auf ein komplett anderes Framework bzw andere Sprache umzustellen ist fragwürdig. Du brauchst mehrere Leute die gute und sehr gute Erfahrung mit Grails/Groovy haben. Alles andere führt zu Frust und wird das Projekt misslingen lassen (so wie es bei Java sein würde, wenn man mal eben J2ee ohe Expertenwissen nutzt).

Wie der Trend ist ?
Halte ich für ne ziemlich komische Frage... Ich würde nicht ein großprojekt nach Trends programmieren sondern nach der Wissensbasis meines Teams bzw der Flexibilität/neugierigkeit und Geduld des Kundens.
Für den Kunden ist es so ziemlich wurscht was dahinter steckt, ob nun J2EE, Grails, Lift, Rails etc, solange für ihn wichtige Punkte geklärt sind.

 

[Gelöschtes Mitglied 5909]

dann hast du mich falsch verstanden, aber egal.

 

[schalentier]

Gerade im financial Bereich würde ich das nicht machen. Da wäre mir das Risiko einfach viel zu hoch, wenn da irgendeine Sache nicht funktioniert wo grails im Hintergrund magic macht und du nicht genau weißt warum das jetzt nicht funktioniert, dann siehst du alt aus und stehst blöd da.

Ersetze grails durch <beliebige Technik, um das Vorhaben zu realisieren> und ich stimme dir 100% zu ;-)

Ansonsten gilt doch ein einfacher Grundsatz: Fuer Kunden/Arbeit nimmt man die Technologie, die man kennt und beherrscht (wenn man denn waehlen kann) - zum Spielen nimmt man etwas, was man nicht kennt und gerne beherrschen koennen moechte. Dabei lernt man wohl am meisten, wenn das Neue moeglichst weit weg vom Bekannten ist... aber ich schweife ab

Grails hab ich mal in nem kleineren/mittleren Projekt gesehen, allerdings haben die das dort hauptsaechlich als Buildsystem-Unterbau fuer nen aelteres Java Projekt genommen. Ansonsten wuerde ich mich fragen, warum den Nachbau, und nicht das Original (Ruby on Rails) nehmen?

 

[Gelöschtes Mitglied 5909]

Nunja um meinen Beitrag nochmal zu untermauern:

Grails - jira.codehaus.org

Mir ging es nicht drum, dass man das nicht beherrschen kann sondern darum, dass es aus meiner sicht viel zu instabil ist. Und ich habe keine Lust Grails selber zu patchen. Und ~1100 bugs/issues mit level >= major wäre mir dann doch zu viel.

 

[bygones]

achso... na dann hast du ja mit Tapestry https://issues.apache.org/jira/browse/TAP5, mit Wicket https://issues.apache.org/jira/browse/WICKET etc glück, da sinds weniger issues... und wer sagt nicht dass es einfach dort ne kleinere Community gibt und die anzahl der issues nicht gleich der Qualität/standard des produkts ist ?!

und weil man die Spring bugs nicht direkt sehen kann ists natürlich besser....

egal... du magst es nicht, ergo wirst du es auch nicht einsetzen... aber zwischen "instabil" und "unbekannte magic" was dein erstes argument war ist auch n kleiner Unterschied.

 

[Gelöschtes Mitglied 5909]

Das ich es nicht mag hast du gesagt. Ich habe gesagt ich würde es für so ein Projekt nicht einsetzen.
Und als ich es eingesetzt habe (in einem kleinen internen Projekt) fand ich es bis auf die Upgrade Problematik (wobei ich nicht sagen kann, ob sie das mittlerweile besser hingekriegt habe) eigentlich gut.

Ich habe lediglich meine Meinung gesagt, wenn du eine andere hast, dann akzeptiere ich die, hoffentlich kannst du das auch.

 

[schalentier]

Ich glaube die Pluginproblematik existiert auch bei nahezu allen anderen Technologien. Beim Umstieg Rails 2 auf 3 haste das gleiche Problem. Bei Spring wirds aehnlich sein. Sogar bei Checkstyle hatte ich neulich mit den Symptomen zu kaempfen (paar eigne Checks, die nicht mehr klappen, weil sich die API geaendert hat).

Natuerlich ist das Problem unterschiedlich stark und es gibt Dinge, um der Pluginhoelle Herr zu werden (mit z.B. Maven geht das bestimmt recht gut, glaub ich). Am besten also, keine externen Libraries verwenden :-D

 

[bygones]

Ich habe lediglich meine Meinung gesagt, wenn du eine andere hast, dann akzeptiere ich die, hoffentlich kannst du das auch.

natürlich, kein Problem damit... hatte nur Probleme mit der Argumentation die du aufgeführt hast, nicht mit der Grundmeinung