| 

.NET C# Java Javascript Exception

Zeit mit Grails verplempern

Dies ist das Archiv des ehemaligen Forums zum Thema Groovy, Grails, Griffon und Bean Scripting Framework, welches unter groovy-forum.de existierte. Die neue Adresse des Groovy-Forums ist: http://codekicker.de/fragen/themen/groovy.


Zeit mit Grails verplempern

christian - 24.06.2009 09:44
[abgetrennt von: Re: grails.views.default.codec="html" zerstört den Aufbau von <g:radiogroup]

Dass man mit Grails viel Zeit verplempern kann, kann ich leider bestätigen! Am Anfang ist es schön, man kommt verdammt schnell vorwärts, es ist einigermaßen klar aufgebaut, so dass man das Konzept schnell versteht ... aber dann, hängt man irgendwann an den ganzen Macken fest!

Grails ist zu schnell gewachsen und im Rausch, mit Ruby on Rails mitzuhalten oder es sogar zu übertreffen, ist leider die Qualität stellenweise auf der Strecke geblieben. Das ist sehr schade, denn von allen Rails-artigen Frameworks, die ich kenne, gefällt mir der Aufbau von Grails mit Abstand am besten. Bloß wenn man dann seine Tage damit verbringt, überflüssige kleine Fehler zu suchen und weitere Tage braucht, um sie zu umgehen, kann man von der Produktivität her auch gleich Java + Servlets pur nehmen.

Ich muss es leider mal so deutlich sagen:
Grails hat ein Qualitätsproblem!

Und wenn sich da nicht bald etwas ändert, wird Grails über kurz oder lang wieder in der Versenkung verschwinden. Ich kann deshalb nur appellieren, Fehler zu melden und am besten sogar Code zur Entwicklung beizusteuern. SpringSource hat zwar das Grails-Projekt übernommen, aber großartig Geld scheinen sie nicht investieren zu wollen - Hauptsache erstmal HABEN. Man sieht ja sehr schön, an der Verteilung der offenen Fehler, dass Graeme Rocher praktisch mehr oder weniger alles alleine macht.


Graeme war nicht mal für meinen Vorschlag offen, auf der Startseite von grails.org einen Link zum Melden von Bugs zu platzieren, stattdessen jammert er lieber, dass so wenig gemeldet werden. Vielleicht sollte man ernsthaft in Erwägung ziehen, einen Fork von Grails zu machen und es mit dem Schwerpunkt auf Qualität in einem unabhängigen Projekt weiterzuentwickeln. Aber besser wäre es natürlich das bestehende Projekt durch Engagement zu verbessern ...

Gruß
Christian



Dateianh&auml;nge:
&ouml;ffnen | Download - Grails-One-Man-Show.png (23.4&nbsp;KB)


Re: Zeit mit Grails verplempern

milkyman - 25.06.2009 10:24
Guten Morgen.

Interessante Diskusion! Find ich gut, dass da auch mal drüber gesprochen wird.

Wobei ich die Lage nicht ganz so kritisch sehe. Das mag aber auch immer an der "Ecke" liegen, aus der der einzelne kommt. Ich komme aus der Java Enterprise Umgebung (JSP, Struts, EJB 2 Session/Entitiy wobei letztere mittlerweile zum Glück von Spring/Hibernate abgelöst wurden). Also im Vergleich dazu ist Grails ein Quantensprung an Produktivität!!! :)

Dabei muss ich allerdings sagen, dass ich Grails bisher in Kunden-Projekten noch nicht eingesetzt habe, sondern nur in internen Projekten, um mich da erstmal einzuarbeiten.

Was den Aufhänger des Threads "Zeit verplempern" betrifft: Bisher ist mein Eindruck, dass die verplemperte Zeit bei Grails sicher nicht größer ist als bei anderen Technologien/Frameworks. Und vor allem bleibt bei mir die Zeit fast ausschließlich wegen Einarbeitung in die Groovy/Grails Details hängen (man muss eben alles mal gemacht haben, um zu wissen, wie es richtig geht) und kaum bei Grails-Bugs. Sicherlich, es könnte immer besser sein. Aber schaut doch mal, wie alt ist Java mit seiner JEE und welche Prozesse (JCP) gibt es da alles bzgl. Weiterentwicklung. Das direkt mit Grails zu vergleichen hat für mich was von Äpfel und Birnen.

Man sollte vielleich auch mit beachten, welche Art von Anwendung man erstellen will. Gerade bei Daten-lastigen Anwendungen mit viel CRUD und wenig anderem ist Grails doch kaum zu schlagen. Wenn man hingegen viele Interaktionen mit anderen Systemen hat und nur wenige aber funktional komplexe Domain-Objekte, dann kommt Grails nicht mehr so zum Zuge.

Schon alleine diese "Kleinigkeiten" wie das automatische Reloading bzw. die Datenbankgenerierung im Hintergrund sind das großartige Feautures, die die Produktivität unglaublich steigern.

Aber auch die Art *wie* man entwickelt ist immer entscheidend für die Produktivität. Klar, es gibt immer wieder Ecken und Kanten, bei denen man viel Zeit verplempert. Bei Grails genauso (aber nicht mehr) als bei anderen Technologien. Erst gestern habe ich wieder eine halbe Stunde lang gerätselt, wieso beim Import die neuen Properties nicht mit importiert werden. Hab x-mal neu gestartet, ein clean zwischendurch versucht, hat alles nichts geholfen. Und das Ende vom Lied? Ich hatte den save ohne Prüfung des Return-Values gemacht und nicht mitbekommen, dass letztlich GAR NICHTS gespeichert wurde. weil ein anderes Feld zwar NULL oder nicht "" sein durfte. Was ich damit sagen will: Wenn der Entwickler Fehler macht, kann das Framework auch nichts dafür. Man muss halt schon versuchen mit den vorhandenen Mitteln zu arbeiten und diese so effizient wie möglich einzusetzen.

Ich habe z.B. auch jetzt noch, wo das Projekt quasi fertig ist (ganz fertig wird sowas ja nie) die Möglichkeit mit einem "generate-all *" alles neu zu generieren. D.h. ich habe keine manuellen Anpassungen in den Domain-GSP und -Controllern. Stattdessen habe ich die Templates immer mehr erweitert und alles, was ich an Benutzerkomfort brauchte, da eingebaut. Manuelle Anpassungen sind nur in der Domain-Klasse notwendig. Außerdem gibt es natürlich Controller für Importe und Auswertungen. Das hat den unschlagbaren Vorteil, dass ich jede View-Änderung nur einmal am Template machen muss und diese dann ganz schnell auf allen Views erscheint. Ich will gar nicht drüber nachdenken, wie viel Arbeit es immer wäre, ein neues Feature überall manuell einzubauen. Aber klar, das geht nicht bei jeder Anwendung, keine Frage. Nur wenn Grails solche Möglichkeiten bietet, sollte man versuchen sie zu nutzen und nicht verschenken - zusammen mit der Produktivität. Es gibt immer viele Lösungen für eine Aufgabe, aber nicht jede Lösung ist auch eine gute Lösung.

Aber du hast natürlich auch Recht Christian, bei 1300 offenen Issues muss man nicht unbedingt über neue Features nachdenken, sondern erstmal hinter sich aufräumen. Auch wenn das immer weniger Spaß macht. Und Graeme Rocher muss eigentlich gar nicht meckern, dass so wenig gemeldet wird, solange es eh nicht abgearbeitet wird. Ich habe auch schon ein paar JIRA eingestellt, von den meisten höre ich aber immer nur dann was, wenn die Lösungsversion wieder eine Versionsnummer hochgeschoben wird. Aber klar, ich könnte es ja auch selber korrigieren. Mein Fehler.

Ich bin absolut gegen einen Fork, das bringt doch nichts. Dafür ich Grails noch nicht alt genug. Stattdessen ist die aktive Mitarbeit am Mainstream deutlich sinnvoller. Das ist ja auch wieder einer der Vorteile im Gegensatz zu JEE, man hat sehr viel leichter die Möglichkeit selbst was zu verbessern. Opensource lebt nun mal von der Gemeinschaft.

Was mich daher mal interessieren würde: Wer von euch hat denn schonmal min. 1 JIRA eingestellt und wer hat auch schonmal selber Code eingebracht?

Ein guter Vorsatz für die Zukunft wäre dann: Nicht an den Bugs vorbeiarbeiten und Work-Arounds suchen, sondern den selber Bug beheben!!! :)

Bye,
Horst


Stelle deine Groovy-Frage jetzt!


Diese Seite zeigt den Thread "Zeit mit Grails verplempern" der ehemaligen Webseite groovy-forum.de, welche durch einen Serverunfall zerstört wurde. codekicker.de hat viele Konversationen über die beliebte Programmiersprache Groovy und zugehörige Frameworks wie das Grails-Framework retten können.

Hast Du eine Frage zum Thema Groovy, Grails oder allgemein Java? Viele ehemalige groovy-forum.de Mitglieder beantworten dir auf codekicker.de deine Frage! Stelle jetzt eine Frage!

Viele weitere Diskussionen zu Grails und Groovy befinden sich auf der Threadübersicht des alten groovy-forum.de.