Posts tagged ‘Groovy’

Code Kata Bunkai: Prime Factors

Bernd Schiffer has published a screencast of the Prime Factors Code Kata that we prepared.
When a programmer new to TDD watches such a code kata he has the same problem that an unexperiences karate student has when he watches a karate kata. He can see what’s happening but he has no idea why.
In karate there is a second kata flavour: Bunkai:

Bunkai literally meaning “analysis” or “disassembly”, is a term used in Japanese martial arts referring to the application of fighting techniques extracted from the moves of a “form” (kata) (see Wikipedia).

When watching a kata bunkai it becomes pretty obvious why the moves of the kata are done.
The same should be possible with code katas. Therefore we tried to transfer the bunkai concept to code katas. For now that simply means that the non obvious parts of the code kata are explained. I published the result for the prime factors code kata on YouTube.

I have to confess that I simply cut Bernds video. I think the real code kata bunkai should include the explanation in the kata – like it is in karate. We will work on that.

January 7, 2010 at 7:46 am 13 comments

Beispiel für Closure

Gerade habe ich einen Anwendungsfall für Closures. Ich habe sequenziellen Code a la:

tueA();
tueB();
tueC();

Ich möchte gerne mitloggen, wie lange die einzelnen Schritte dauern (um das Beispiel zu vereinfachen, logge ich durch Ausgabe auf die Konsole):

long startTime = System.currentTimeMillis();
tueA();
System.out.println("duration in sec: " +  ((System.currentTimeMillis() - startTime) / 1000));

startTime = System.currentTimeMillis();
tueB();
System.out.println("duration in sec: " +  ((System.currentTimeMillis() - startTime) / 1000));

startTime = System.currentTimeMillis();
tueC();
System.out.println("duration in sec: " +  ((System.currentTimeMillis() - startTime) / 1000));

Das funktioniert, nur den eigentlichen Code kann man kaum wiederfinden. Wenn ich Closures (wie z.B. in Groovy) zur Verfügung habe, ist es ganz einfach:

def timeLogged (Closure c) {
    long start = - System.currentTimeMillis()
    c.call()
    println "duration in sec: " + (System.currentTimeMillis() + start) / 1000;
}

timeLogged { tueA() }
timeLogged { tueB() }
timeLogged { tueC() }

Das ist kürzer, redundanzfreier und meiner Meinung nach deutlich besser lesbar.

P.S.: Redundanzfrei kann es ohne Closures in Java natürlich auch hinkriegen, mit anonymen Inner Classes. Dummerweise wird der Code dann noch länger und noch schwerer lesbar.

July 27, 2009 at 10:58 am 3 comments

Terminplaner in Prolog

Ich habe meine Prolog-Kenntnisse aufgefrischt und dazu das Terminplaner-Beispiel in Prolog implementiert. Die geringe Anzahl Lines of Code (LoC) der Prolog-Lösung finde ich ziemlich beeindruckend. Ich habe die Größe der Lösung in den verschiedenen Programmiersprachen mal gegenüber gestellt (LoC: ohne Leerzeichen und Kommentare).

Sprache LoC LoC Tests
Java 187 109
Groovy 155 79
Ruby 141 90
Lisp (CLOS) 63 77
Prolog 34 93

LoC ist sicher kein besonders gutes Maß, um die Mächtigkeit einer Programmiersprache zu bewerten. Wenn man allerdings nur 34 Zeilen braucht, wo man sonst 150-200 Zeilen braucht, finde ich das schon ziemlich denkanstößig.

Der Code steht unter github bereit: http://github.com/stefanroock/Terminplaner/tree/master (Achtung: Die Python-Lösung funktioniert noch nicht).

July 13, 2009 at 7:30 pm 5 comments

Grails: Schnell mal eine Web-Anwendung mit Groovy für die Java-Plattform

An anderer Stelle habe ich bereits Groovy kurz beleuchtet, die standardisierte Skriptsprache für die Java-Plattform.

Jetzt, wo man eine so mächtige und flexible Skriptsprache hat, lag es natürlich nahe, den Rails-Ansatz auch für Groovy nutzbar zu machen. Herausgekommen ist Grails.

Grails existiert erst in der Version 0.2.2, hat aber bereits einen erstaunlichen Entwicklungsstand. Mit wenigen Clicks ist eine erste Version der Webanwendung zusammengebaut, die man dann explorativ weiterentwickeln kann.

Die existierende Dokumentation reicht für erste Schritte aus, vieles kann man sich durch nachdenken erschließen.

Grails ist sicherlich eine sehr interessante Technologie für die Web-Projekte, die für die Java-Plattform entwickeln müssen/wollen. Die Java-ähnliche Syntax von Groovy erleichtert Java-Entwicklern den schnellen Einstieg.

September 18, 2006 at 5:09 pm Leave a comment

IDEs und der K(r)ampf zwischen Statik und Dynamik

Für Java existieren heute mit Eclipse, IntelliJ IDEA und Konsorten sehr mächtige Entwicklungsumgebungen. Cross-Referencing, Refactoring und Auto-Completion sind Features, die man nicht mehr missen möchte.
Dass diese Features für die aktuellen Skriptsprachen a la Python, Ruby oder Groovy nicht oder nur eingeschränkt existieren, wird häufig als Argument gegen diese Skriptsprachen verwendet.

Aber wird über diese Features wirklich reflektiert?

Cross-Referencing
Mit den Cross-Referencing-Möglichkeiten der IDE kann man auf Tastendruck oder Mausclick von einer Codestelle zum referenzierten Element gelangen (z.B. von einer Variablendeklaration zur Klasse, von deren Typ die Variable ist).

Natürlich sind die Cross-Referencing-Möglichkeiten in den IDEs deutlich mächtiger als eine Textsuche über Dateien. Aber ist der Unterschied wirklich so groß? Und ist die Textsuche häufig nicht sogar schneller?

Refactoring
Refactoring ist eine der großen Errungenschaften in der Neuzeit der Softwareentwicklung und ihr Automatisierungsgrad ist wirklich erstaunlich hoch. Aber welche automatisierten Refactorings nutzen wir überhaupt bei der täglichen Arbeit und wie häufig? Viele Entwickler verzichten sogar absichtlich auf bestimmte einfache Automatisierungen (z.B. “Introduce Variable”), weil sie von Hand schneller sind – die Mächtigkeit der IDEs führt bei großen Projekten leider dazu, dass die Arbeit mit ihnen mitunter doch etwas zäh wird.
Viele Refactorings kann man in der Tat mit vertretbarem Aufwand und Risiko auch von Hand durchführen. Einige andere (z.B. “Rename Class”) lassen sich auch auf anderem Wege automatisieren (Find&Replace über Dateien). Natürlich kann man sich dann oft nicht 100%ig sicher sein, dass alles korrekt geändert wurde. Man muss anschließend die Tests ausführen. Dass muss man in Java aber auch, weil es immer mehr untypisierte Referenzen in XML-Dateien (Struts, Spring, EJB etc.) gibt, die den IDEs auch mal durch die Lappen gehen.

Auto-Completion
Bei der automatischen Vervollständigung tippt man nur den Beginn eines Wortes ein und die IDE ergänzt die fehlenden Zeichen. Dadurch spart man Tippzeit, reduziert die Wahrscheinlichkeit von Tippfehlern und muss sich nur an den Anfang von Methodennamen erinnern.
Interessanterweise gibt es auch in programmiersprachen-unabhängigen Editoren wie Emacs oder JEdit Auto-Completion. Dabei werden viel einfachere Verfahren eingesetzt als in den Java-IDEs, die aber erstaunlich gute Ergebnisse liefern. Ein ganz einfacher Ansatz besteht z.B. darin, bei der Auto-Completion nur die Wörter zu berücksichtigen, die in der aktuellen Datei schon mal verwendet wurden. Etwas umfangreicher ist der Ansatz, die Wörter aller Dateien eines Projektes zu verwenden.
Ähnlich wie beim Cross-Referencing sind diese Auto-Completion-Features der Editoren qualitativ denen der IDEs unterlegen. Aber wie beim Refactoring sie sind schneller.

Und das ist ein Faktor, den man nicht unterschätzen sollte. Ich ertappe mich beim Java-Programmieren jedenfalls immer wieder dabei, dass ich Namen komplett manuell eintippe, weil ich damit schneller bin als die zäh reagierende Entwicklungsumgebung. Und wenn ich in einem einfachen Editor eine Skriptsprache programmiere, genieße ich es, dass der Editor immer sofort reagiert. Die IDEs sind nur Bruchteile von Sekunden langsamer, aber das reicht schon aus, um den Flow beim Programmieren zu beeinträchtigen.

August 24, 2006 at 4:16 pm Leave a comment