Posts tagged ‘Groovy&Grails’

Clipboard2Web-Service ist online

Ich muss relativ häufig Abbildungen oder Bilder in die eine oder andere Web-Anwendung bringen – z.B. in Blogger oder Google-Docs. Das Verfahren dazu ist sehr umständlich. Häufig kopiere ich das Bild ins Clipboard, öffne dann Paint, paste das Bil in Paint, speichere das Bild auf der Festplatte, wechsele in die Webanwendung, öffne den Upload-Dialog, suche die Bilddatei auf der Platte und starte dann den Upload.

Clipboard2Web ist eine Internet-Anwendung, die das vereinfacht. Einfach Bild aus dem Clipboard nach Clipboard2Web pasten und schon steht im Gegenzug der Pfad zum Bild im Clipboard. Das muss man jetzt nur noch in den Upload-Dialog der gewünschten Webanwendung pasten und fertig.

Clipboard2Web enthält ein signiertes Applet, so dass man beim ersten Start der Anwendung das Zertifikat akzeptieren muss.

Technologisch ist Clipboard2Web in erster Linie ein signiertes Applet, eingebunden in eine sehr kleine Grails-Anwendung.

Ich freue mich jederzeit über Feedback zu Clipboard2Web.

October 13, 2008 at 12:24 pm 1 comment

mein erstes Grails-Projekt

Eigentlich bin ich eher skeptisch, was neue Technologien angeht. Zu häufig wird viel zu viel versprochen und der Gesamtnutzen bleibt zweifelhaft. Viele Technologien lösen auch schlicht Probleme, die ich gar nicht habe.
Bei Groovy und Grails verhält es sich anders. Ich hatte jetzt das Glück, dass ich zum Jahresausklang ein kleines Grails-Projekt machen konnte. Ich hatte Grails bereits vorher ein wenig ausprobiert und hatte daher eine Idee, was mich erwartete. Und diese Erwartungen wurden noch übertroffen.
Wir haben in sehr kurzer Zeit eine kleine aber komplette Internetanwendung mit lächerlich wenig Code geschrieben. (Sobald die Anwendung Live ist, werde ich den Link hier mal posten.)
Besonders beeindruckt hat mich die Klarheit des Programmiermodells. Struts, JSF und Spring Web-MVC haben bei mir immer das Gefühl hinterlassen, dass intern Dinge passieren, die ich nicht ganz verstehe. Dieses Gefühl habe ich mit Grails nicht.
Weiterhin ist interessant, dass wir – obwohl es für alle das erste Grails-Projekt war – jedes Problem in weniger als 2 Stunden lösen konnten. Bei anderen Java-Technologien hatten wir immer wieder Fälle, wo wir uns Tage oder gar Wochen die Zähne ausgebissen haben; teilweise konnten wir die Probleme gar nicht lösen und mussten dann mit Work-Arounds arbeiten.

December 21, 2007 at 4:48 pm 10 comments

Groovy: Wie aus Skripten Programme werden

Mein Kollege Bernd Schiffer hat in seinem Blog einen sehr schönen Eintrag zu Groovy geschrieben. Anhand eines einfachen Problems zeigt Bernd, wie man sich Groovy zuerst eine Skripting-Lösung baut und die dann schrittweise zu einer echten Anwendung wird.
Dabei werden auch einige Highlights von Groovy angesprochen wir Groovy-Beans, Categories, Swing-Builder etc. Besonders schön finde ich, dass durch das Beispiel sehr deutlich wird, wo in Praxis der Nutzen dieser Features liegt.

February 23, 2007 at 10:24 am Leave a comment

Für Groovy stimmen!

http://www.java.net/pub/pq/143

January 29, 2007 at 11:14 am Leave a comment

Groovy und Grails auf Konferenzen

Eindrücke aus erster Hand zu Groovy und Grails kann man sich auf verschiedenen Konferenzen in den nächsten Monaten besorgen:

September 18, 2006 at 7:34 pm Leave a comment

GroUnit: Unittests mit Groovy


Ursprünglich als reine Fingerübung gedacht, habe ich ein Unittest-Tool für Groovy geschrieben: GroUnit. Das ist nicht weiter schwer, weil Groovy bereits Unterstützung für Unit-Tests mitbringt, allerdings ohne UI. Man kann wg. der nahtlosen Groovy-Java-Integration JUnit auch für Groovy verwenden (siehe z.B. Groovy-Web). Das hat aber ein paar Nachteile:

  • Man muss die Groovy-Klassen nach Bytecode compilieren. Für Produktionscode ist das OK, aber während der Entwicklung verlängert es unnötig die Turn-Around-Zeiten.
  • Wenn ein Test fehlschlägt, bekommt man im Stack-Trace auch die ganzen Core-Reflection-Geschichten angezeigt, die Groovy im Hintergrund durchführt. Dadurch muss man immer erst mal eine Weile im Stacktrace suchen, bis man das eigentliche Problem überhaupt gefunden hat.
  • Seit JUnit 4.0 bringt JUnit keine eigene Benutzungsoberfläche mehr mit. Diese wird von den Entwicklungsumgebungen gestellt. Das ist für Jave wunderbar. Es erzwingt für Groovy aber, dass man eine schwergewichtige Java-Entwicklungsumgebung verwendet. Häufig wäre man mit einem mächtigen Editor besser bedient.

Ich habe versucht, in GroUnit diese Probleme zu adressieren. Sehr weit bin ich in der ersten Version 0.1 sicher noch nicht gekommen. Aber vielleicht engagieren sich noch weitere Leute für GroUnit und es wird noch was richtig Gutes.
Zur GroUnit-Homepage mit Download-Möglichkeit.

June 11, 2006 at 8:08 am Leave a comment

Groovy im Vergleich zu Java am Terminplaner-Beispiel

Ich habe den Terminplaner, den ich als Beispiel für testgetriebene Entwicklung programmiert hatte, von Java auf Groovy migriert. Für den Terminplaner in Java hatte ich testgetrieben ca. 180 Minuten benötigt. Für die Migration nach Groovy habe ich dann ca. 60 Minuten investiert.

Der erste Unterschied der Groovy-Lösung zur Java-Lösung ist der Wegfall der Klasse TeilnahmeStatus (war Enum bei Java). Die Teilnahme-Status-Informationen landen bei Groovy einfach in der Klasse Teilnahme.

Die equals– und compareTo-Methoden sind in Groovy einfacher zu implementieren, weil es für beides eigene Operatoren (== und ) gibt, die mit Null-Werten umgehen können.

Bei einer der compareTo-Methoden habe ich bei der Migrationen einen Fehler gefunden, der im Groovy-Code sofort offensichtlich wird. Im Java-Code kann man den Fehler durch die Klammerung beim flüchtigen Lesen übersehen (ist mir beim Schreiben der Java-Lösung ja offensichtlich auch passiert).

Die betroffene Java-Zeile sieht so aus:

int startZeitCompare = startZeit.compareTo(startZeit);

In Groovy wird der Problem sofort offensichtlich:

int startZeitCompare = startZeit startZeit

Es muss natürlich heißen:

int startZeitCompare = startZeit o.startZeit

Die Zahlen nach der Umstellung lesen sich so:

Java-Zahlen

  • 5 Fachklassen, 1 Exception-Klasse, 1 Testklasse
  • 37 Methoden inkl. Konstruktoren + 10 Methoden in Testklasse
  • 246 LOC operativ + 144 LOC für Testklasse (inkl. Leerzeilen)
  • 4 For-Schleifen, 4-If-Abfragen

Groovy-Zahlen

  • 4 Fachklassen, 1 Exception-Klasse, 1 Testklasse
  • 30 Methoden inkl. Konstruktoren + 9 Methoden in Testklasse
  • 203 LOC operativ + 123 LOC für Testklasse (inkl. Leerzeilen)
  • Alle 4 For-Schleifen wurden durch Closures ersetzt, die 4-If-Abfragen blieben bestehen.

Die Code-Ersparnis lässt sich im Wesentlichen auf folgende Groovy-Konzepte zurückführen:

  • Closures machen For-Schleifen überflüssig und sind kürzer aufzuschreiben.
  • Durch Properties werden Getter und Setter überflüssig.
  • Typecasts entfallen.
  • In den Tests spart die Uniformität von Arrays und Collections Konvertierungen.

In Groovy habe ich also ca. 80% der LOC (Lines of Code) benötigt, die ich für die Java-Lösung benötigte. Das hört sich erstmal nicht nach einem Quantensprung an. Allerdings muss man bedenken, dass ich „lediglich“ Java durch das doch sehr ähnliche Groovy ersetzt habe. Also hat eine Einzelmaßnahme 20% Code-Ersparnis gebracht. Setzt man das einfach mal naiv mit 20% Kostenersparnis gleich, ist man sehr schnell in Regionen, die interessant erscheinen (die meisten Offshoring-Untersuchungen sprechen von geringeren Einsparungspotenzialen).

Außerdem ist zu bedenken, dass mein Terminplaner-Beispiel die Strukturen in den Vordergrund stellt und die Daten ignoriert (so hat der Benutzer nur seinen Namen und der Termin nur 4 Datenfelder). In einer vollständigen Terminplaner-Anwendung sind viel mehr Datenfelder zu verwalten (MS-Outlook hat für Kontakte so um die 30 Datenfelder). Und gerade wenn es nur um das Halten von Datenfeldern geht, spielt Groovy seinen LoC-Vorteil aus. Die 30 Datenfelder würden in Groovy ca. 10 LoC bedeuten und in Java ca. 130 LoC (beide Zahlen inkl. Leerzeilen).

Nicht zuletzt habe ich die Terminplaner-Anwendung relativ stumpf auf Groovy umgestellt. Ich muss prüfen, ob sich der Code durch fortgeschrittene Groovy-Konzepte noch weiter vereinfachen lässt.

Der Groovy-Code findet sich hier zum Download.

June 9, 2006 at 11:47 am Leave a comment

Older Posts