Posts tagged ‘Groovy&Grails’

Groovy kann Typen

Ich hatte mir in einem früheren Blog-Eintrag für dynamische Sprachen wie Ruby gewünscht, dass man optional einen Typ nennen kann, der dann dynamisch zur Laufzeit geprüft wird. So kann man meiner Meinung nach die Lesbarkeit von Quellcode erhöhen. Nehmen wir als Beispiel folgende Methode (Syntax ist informell):

def loescheKunden(kunde)

Dann muss man die Doku oder die Methodenimplementation lesen, um herauszufinden, was hier übergeben werden muss. Das Kundenobjekt, die Kundennummer oder der Kundenname?

Eine Deklaration mit Typ würde diese Frage sofort beantworten:

def loescheKunden(Kunde kunde)

Jetzt habe ich mich näher mit Groovy beschäftigt und festgestellt, dass das genau so in Groovy funktioniert. Man kann optional Typen angeben, die dann dynamisch geprüft werden. Wenn man keinen Typ angibt, verhält sich Groovy wie die anderen dynamischen Sprachen und prüft den Typ auch nicht.

January 22, 2006 at 6:03 pm Leave a comment

Codelängen

Bei meinen Recherchen zu Groovy bin ich über ein interessantes Beispiel gestoßen. Dasselbe kleine Programm einmal in C#, in Java und in Groovy sowie Ruby (Achtung: Der Ruby-Quellcode findet sich in den Kommentaren zu der Groovy-Seite. Man muss dort also nach unten scrollen. Leerzeilen habe ich nicht mitgezählt und ich habe bei Java und C# ein paar Zeilen abgezogen, die der Formatierung im Web geschuldet waren):

  • C#: 45 Zeilen Code
  • Java: 56 Zeilen Code
  • Groovy: 14 Zeilen Code
  • Ruby: 17 Zeilen Code

Von der unterschiedlichen Zeilenanzahl zwischen Groovy und Ruby sollte man sich nicht verwirren lassen. Im Groovy-Beispiel wurde eine Methode einfach in eine Zeile geschrieben, für die im Ruby-Beispiel drei Zeilen verwendet wurden. Man kann sagen, dass die Implementation in Groovy und Ruby identisch ist – abgesehen von syntaktischen Kleinigkeiten.

Bedeutet das jetzt einen relevanten Unterschied für die Praxis? Moderne IDEs helfen, auch den umfangreicheren Java- und C#-Code schnell zu erstellen. Der Autor der Java-Version hat mit IntellJ IDEA nur 10% des Codes wirklich eingetippt.

Ich meine, da ist sehr wohl ein Unterschied. Schließlich wird Quellcode viel häufig gelesen als geschrieben. Für die Produktivität der Entwicklung ist daher ausschlaggebed, wie aufwändig das Lesen und Verstehen existierenden Codes ist und nicht wie schnell man den Code tippen kann. Und die einschlägigen Statistiken sagen, dass die Anzahl der Zeilen Code, pro Personentag entstehen ebenso konstant ist, wie die Anzahl der Fehler, die man durchschnittlich je 1.000 Codezeilen macht. Ob man also 1.000 Zeilen Code mit Java oder Groovy schreibt: Man braucht gleich lang und programmiert die gleiche Anzahl Fehler in den Code. Nur, dass man in 1.000 Zeilen Groovy viel mehr Funktionalität programmieren kann als in 1.000 Zeilen Java.

January 8, 2006 at 4:32 pm Leave a comment

Groovy

Dynamische Programmiersprachen a la Python und Ruby haben in den letzten Jahren viel Aufmerksamkeit erhalten. Ein wenig untergegangen ist da bisher Groovy. Groovy ist Bestandteil der Java-Platform und mit dem JSR-241 spezifiziert.

Groovy lehnt sich bei der Syntax an Java (Groovy-Syntax ist Java-Syntax mit weniger Regeln) an und ist von den Sprachkonstrukten ähnlich zu Python oder Ruby. Besonders interessant ist Groovy für Java-Programmierer, weil es insbesondere eine gute Integration mit Java gibt. Man kann Groovy-Code ganz einfach aus Java heraus aufrufen und umgekehrt auch Java-Code einfach aus Groovy. Damit hat man insbesondere gleich das ganze JDK in Groovy zur Verfügung.

Dadurch kann man z.B. Swing-Code mit Groovy schreiben und die Kernfunktionalität der Anwendung mit Java. Vorteil: Der Groovy-Swing-Code ist kürzer und verständlicher als derselbe Code in Java.

Und es gibt das Groovy-Äquivalent zu Ruby on Rails: Grails.

Weitere – gut strukturierte – Informationen zu Groovy gibt es hier.

January 8, 2006 at 3:56 pm Leave a comment

Vorträge

siehe auch meine Artikel und Bücher

  • Bernd Schiffer, Stefan Roock: Agile Entwicklung mit Grails, XP-User-Group-Hamburg und Java-User-Group-Hamburg, Dezember 2007
  • Stefan Roock: Einfachheit in Softwareprojekten, XP-Days Germany 2007, Karlsruhe, November 2007
  • Stefan Roock (Organisation): Agile Lightning Talks, XP-Days Germany 2007, Karlsruhe, November 2007
  • Stefan Roock, Bernd Schiffer, Henning Wolf: Agile Lego Hour, W-JAX 2007, München, November 2007
  • Stefan Roock, Henning Wolf: Festpreisvertrag und agil nützt nicht viel?, Agility Day auf der W-JAX 2007, München, November 2007, Folien
  • Stefan Roock (Organisation): Agile Lightning Talks, Agility Day auf W-JAX 2007, München, November 2007
  • Stefan Roock: Anforderungen, Usability und Agilität, Universität Konstanz, 2007, Folien
  • Stefan Roock, Henning Wolf: Scrum und Lean-Management in IT-Projekten, Arbeitskreis Projektmanagement, Nordakademie, 2007
  • Jürgen Ahting, Stefan Roock: Warum sind die Kunden in Softwareprojekten so schwierig?, JAX 2007, Wiesbaden, 26.04.2007
  • Robert Beeger, Matthias Lübken, Stefan Roock, Sebastian Sanitz: XP-Live-Demo, JAX 2007, Wiesbaden, April 2007
  • Stefan Roock, Henning Wolf: IT-Kaizen: Kontinuierliche Verbesserung in der Softwareentwicklung, XP-Days Germany 2006, Hamburg, 24.11.2006, Folien
  • Bernd Schiffer, Stefan Roock: Beispiel Grails – Brauchen wir neue Technologien für agile Entwicklung?, XP-Days Germany 2006, Hamburg, 24.11.2006, Folien
  • Arno Haase, Stefan Roock, Sebastian Sanitz: Hibernate 3 (ganztägiger Power-Workshop). JAX 2006, Wiesbaden, 08.05.2006
  • Stefan Roock, Henning Wolf: Aufwandsschätzung in agilen Projekten. Lehmanns Buchhandlung, Hamburg, Januar 2006.
  • Robert Beeger, Arno Haase, Stefan Roock: Hibernate 3. (ganztägiger Power-Workshop). W-JAX 2005, München, November 2005.
  • Bernd Schiffer, Stefan Roock: eXtreme Programming (Tutorial). ix-Konferenz, Köln, November 2005.
  • Jürgen Ahting, Stefan Roock: Der Kunde in agilen Projekten. ix-Konferenz, Köln, November 2005
  • Stefan Roock: Aufwandsschätzung in großen agilen Projekten. ix-Konferenz, Köln, November 2005.
  • Stefan Roock: Refactorings in großen Softwareprojekten, XP-Days 2004, Karlsruhe
  • Martin Lippert, Stefan Roock: Refactorings in großen Softwareprojekten, Java Forum Stuttgart 2004, 01.07.2004, Stuttgart.
  • Stefan Roock, Martin Lippert, Frank Westphal: Testing in the Extreme Programming World. (Full-Day Tutorial). ICS Test, Köln, http://www.icstest.com, 01.04.2003
  • Stefan Roock, Martin Lippert: Large Refactorings (Workshop). OT 2003, Cambridge, UK, http://www.ot2003.org, 2003
  • Stefan Roock: Requirements Engineering bei agilen Methoden. GI-Workshop “Requirements Engineering”, Ulm, http://www-lufgi3.informatik.rwth-aachen.de/GI/GI-FG2.1.6.html. 28.09.2002
  • Holger Breitling, Axel Schmolitzky, Stefan Roock: Extreme
    Programming (Half-Day Tutorial). Software Management Tagung, Hamburg, 06.11.2002
  • Holger Breitling, Petra Becker-Pechau, Stefan Roock: Agile Requirements Engineering (Full-Day Tutorial). RE 2002, Essen. 10.09.2002
  • Martin Lippert, Stefan Roock: Using and Adapting Extreme Programming (Full-Day Tutorial). ECOOP 2002, Malaga, Spanien, 11.06.2002
  • Martin Lippert, Stefan Roock: Extreme Programming in komplexen Projektsituatuionen (Full-Day Tutorial). OOP 2002, München. Januar 2002.
  • Stefan Roock: eXtreme Programming integrativ? GI-Workshop “Vorgehensmodelle”. 2001
  • Martin Lippert, Stefan Roock: Extreme Programming in Complex Project Settings (Half-Day Tutorial). ECOOP 2001, Budapest, Ungarn, Juni 2001
  • Stefan Roock: Anforderungsermittlung mit eXtreme Programming. GI-Workshop
    “Requirements Engineering”, 2001.
  • Stefan Roock, Henning Wolf: Framework-Entwicklung (Full-Day Tutorial). OOP
    2001, München, Januar 2001.
  • Stefan Roock: Object Oriented Design (3-Day Workshop). University
    of Roenneby, Schweden, März 2000.

January 1, 1990 at 9:10 pm Leave a comment

Newer Posts