Archiv

Archive for Januar 2011

Täglich reflektieren – nicht nur etwas für CCD

31. Januar 2011 1 Kommentar

Täglich über seine Arbeit zu reflektieren ist eine der Praktiken, die bei Clean Code Developer (CCD) im roten Grad gefordert werden. Der rote Grad ist der Beginn einer Reise, die einem als Softwareentwickler zu einem (inneren) Wertesystem führen soll. Dies geschieht durch eine bewusste Auseinandersetzung mit seinem Metier und dem verinnerlichen grundlegender Praktiken und Prinzipien.

Im roten Grad gibt es neben der Reflexion noch zahlreiche andere Praktiken und Prinzipien. Ich finde diese Praktik aber besonders wichtig und schliesse mich der Begründung von CCD an:

Keine Verbesserung, kein Fortschritt, kein Lernen ohne Reflexion. Aber nur, wenn Reflexion auch eingeplant wird, findet sie unter dem Druck des Tagesgeschäftes auch statt.

Wer nicht über seine Arbeit reflektiert hat keine Chance diese zu verbessern. Man findet sicher weitere Möglichkeiten seine Arbeit anders zu machen. Doch lernt man dabei auch etwas? Natürlich kann es spannend sein seine Arbeit jeden Tag ein wenig anders zu gestalten. Doch ist das wirklich lernen? Braucht es zum anders machen nicht auch die Erkenntnis, welche der vielen Möglichkeiten einem helfen?

Werde ich wirklich ein besserer Programmierer wenn ich LINQ an jeder Stelle einsetze – unabhängig davon ob es da Sinn macht? Wird mein Code wirklich leserlicher, wenn ich var in allen Bereichen verdamme? Gewinne ich wirklich etwas beim Einsatz optionaler Parameter für Parameter die ich in jedem Fall angeben muss? Oder folge ich damit nicht einfach einem Hype?

Um eine Antwort darauf zu finden, muss ich nachdenken – und über meine getane Arbeit reflektieren.

 
Reflektieren – aber wie?
Um zu überprüfen ob meine erledigte Arbeit mit meinen Zielen übereinstimmt brauche ich als erstes Ziele. So banal dies tönt, so wichtig ist es. Wenn ich täglich reflektieren will, muss mein Ziel idealerweise innerhalb des gleichen Zeitrahmens erreichbar sein. Ist mein Arbeitspaket grösser, muss ich meine Arbeit in Stücke teilen, die ich innerhalb eines Tages erledigen kann.

Habe ich die Ziele, kann ich überprüfen ob ich diese Ziele erreicht habe. (Konnte ich das GUI wie gefordert erstellen? Habe ich allen doppelten Code entfernt?) Diese Ziele müssen aber nicht nur technischer Natur sein. Ich kann dabei auch darüber nachdenken, wie ich diese Ziele erreicht habe. Was hat mir bei meinem Arbeitsablauf gefallen? Was hat mich Zeit gekostet? Wo sehe ich Möglichkeiten meine Effizienz zu steigern oder mich zu verbessern?

Mir hilft es wenn ich neben den Zielen auch 3 oder 4 Punkte zum Tag im Allgemeinen aufschreibe. Dies kann von technischen Kniffen und der Ursache hinter kryptischen Fehlermeldungen bis zu ganz allgemein gehaltenen Aussagen reichen. (wie: „Nach jedem erledigten Teil ein commit.“)
Wenn sich Punkte wiederholen, weiss ich dass ich dem nachgehen muss.

 
Und wann?
CCD schlägt vor am Abend jedes Tages zu reflektieren. Ein Arbeitstag ist eine gute und greifbare Einheit, die für ein längerfristig ausgelegtes Vorhaben genau genug ist.

Ich überprüfe am Ende jedes Arbeitstages ob auch wirklich alle Bugfixes vom branch in den trunk gemerged wurden und ob meine Issues alle nachgeführt sind. Da ich dabei eh über meine an diesem Tag erledigte Arbeit nachdenken muss, nutzte ich diese Gelegenheit zur Reflexion. Der Mehraufwand für CCD ist dadurch vernachlässigbar.

Aber auch ohne CCD und ohne Issues die gepflegt werden müssen ist eine tägliche Reflexion machbar. Es braucht gar nicht so viel Zeit wie man vermutet. Mit ein wenig Übung geht dies in kürzester Zeit in weniger als 10 Minuten.

Ein weiterer positiver Nebeneffekt ist der dadurch gemachte saubere Abschluss des Arbeitstages. Wenn alles abgeschlossen ist gibt es auch keinen Grund mehr im Feierabend darüber nachzudenken. Der Feierabend dient dann wie vorgesehen der Erholung – und nur der.

 
Fazit
Die tägliche Reflexion scheint so banal und vernachlässigbar. Sie ist aber der Garant für eine stetige Verbesserung und dadurch unverzichtbar. Mit wenig Aufwand kann man die Reflexion in seinen Arbeitsalltag aufnehmen. Nur wer weiss wo er steht kann sich sinnvolle nächste Schritte überlegen. Und für beides hilft das tägliche reflektieren.

Schlagworte: ,

Buch-Rezension zu “Dependency Injection in .Net”

23. Januar 2011 2 Kommentare

“Dependency Injection in .Net” von Mark Seemann erscheint 2011 bei Manning. Man bekommt das Buch aber bereits jetzt via MEAP. Da nur noch ein einziges Kapitel zu Spring.Net fehlt, wage ich mich bereits an eine Rezension.

Schon zu Beginn des Buches wird einem klar, dass man es hier mit etwas speziellem zu tun hat. Welches Buch zu irgendeinem IT-Thema beginnt mit einer Erklärung wie man eine Sauce béarnaise zubereitet? Man mag schon fast meinen Manning hätte die Bücher vertauscht, doch hat diese Einführung durchaus ihren Sinn.

Mark Seemann kocht gerne und sieht zwischen Dependency Injection (DI) und einer Sauce béarnaise parallelen: Bei beiden vermutet man es sei kompliziert und viele verzichten daher darauf. Die ersten Versuche können fehlschlagen, doch hat man mal den dreh raus wird man es überall anwenden können.

 
Klare Struktur
Will einem ein Buch beim Strukturieren der eigenen Programme helfen, so sollte es selber auch klaren Strukturen folgen. Dies gelingt „DI in .Net“ so gut, dass man die einzelnen Kapitel in beliebiger Reihenfolge lesen könnte.

Wer dem vorgegebenen Pfad folgt beginnt mit einer Einführung, lernt Patterns und wie man DI auch von Hand machen kann. Sind einem alle nötigen Abläufe bekannt, zeigt einem der letzte Teil die jeweiligen Vor- und Nachteile dieser DI-Container:

 
Patterns und Anti-Patterns
Im Kapitel zu Patterns werden einem die Anwendungsmöglichkeiten von DI in .Net gezeigt. Seemann bevorzugt ganz klar die Abhängigkeiten wie Konstruktor den Objekten zu übergeben. Geht dies nicht kann man auch über Properties die Werte setzen oder bei jedem Methodenaufruf einen entsprechenden Kontext mitgeben.

Bei jedem Pattern wird immer erst erklärt wie das Prinzip funktioniert. Anhand der .NET Base Class Library (BCL) wird dann gezeigt, wo dies von Microsoft selber umgesetzt wurde. So zeigt Seemann wo man dieses Konzept schon bei der täglichen Arbeit nutzt – ohne das man DI verwendet. Ein ausführliches Beispiel rundet die jeweilige Vorstellung ab.

Bei den Anti-Patterns läuft es ähnlich ab. Nach einer Erklärung was er unter diesem Pattern versteht beschreibt Seemann wieso dies ein Problem ist. Die kleinen Abkürzungen ziehen Probleme mit sich die zwar harmlos aussehen aber zu grossen Verrenkungen führen. Gut gemeint ist halt noch lange nicht gut gemacht – dies gilt auch für die Konzepte rund um DI. Die vorgeschlagenen Refactorings zur Korrektur fand ich sehr hilfreich und sind das Geld fürs Buch bei weitem wert.

 
DI und Manning – war da nicht schon etwas?
Vor ein wenig mehr als einem Jahr habe ich schon ein anderes Buch zu diesem Thema mit dem Titel “Dependency Injection” vorgestellt. Mein Fazit war damals durchzogen und ich schlug vor, auf eine 2. Ausgabe zu warten. “Dependency Injection in .Net” ist zwar nicht diese 2. Ausgabe, aber es erfüllt meine damals erhofften Verbesserungspunkte. Das Buch ist sehr angenehm zu lesen und bekommt die Prinzipien und Vorteile auf eine sehr einfache Art erklärt.

 
Trotz MEAP bereits jetzt kaufen?
In der Mitte Januar vorliegenden Version ist das Buch noch nicht ganz fertig. Laut der Übersichtsseite fehlen noch ein Kapitel, das Vorwort, die Danksagung und der Index. Auch im Layout wird es in den nächsten Monaten noch zahlreiche Änderungen geben. Mir hat das Buch in der aktuellen Form schon sehr geholfen. Mir gefällt es aber auch schon bei der Entstehung Verbesserungen anregen zu können (via Online-Forum).

Wer grossen Wert auf ein perfektes Layout legt, sollte lieber noch bis zur offiziellen Veröffentlichung warten. Diese ist derzeit für den Juni 2011 geplant.

 
Fazit
Das Buch bietet eine gute Einführung ins Thema Dependency Injection. Durch den Aufbau und die vielen Tipps und Tricks ist es auch für Leute geeignet die mehr wollen als nur eine Einführung. Ich kann das Buch daher ohne Einschränkung weiterempfehlen.

Ich gehe sogar soweit dieses Buch als „Must Read“ zu deklarieren. Die darin vorgestellten Konzepte und Ideen sind so grundlegend, das man als Entwickler nicht darum herum kommt.

 
Zum Buch
“Dependency Injection in .Net” von Mark Seemann, 2011 Manning, ISBN 978-1-935182-50-4, >500 Seiten, [Englisch]

Java: String von der Kommandozeile lesen (mit java.util.Scanner)

11. Januar 2011 Kommentare aus

Warum ist das Einlesen eines Strings von der Kommandozeile in Java so kompliziert?

war eine Frage die mir heute gestellt wurde. Fragt man Google nach einer Lösung um einen String einzulesen wird meist so etwas unter den ersten Treffern landen:

BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
String input = in.readLine();

Mit Hilfe von BufferedReader und InputStreamReader kann man nach dem gleichen Prinzip sowohl einen String aus einer Datei, von der Kommandozeile oder jedem beliebigen Stream lesen. Wenn man es häufig genug anwendet, braucht man da gar nicht mehr gros zu überlegen.

Dies ist allerdings doch recht viel Code, wenn man bedenkt das man in C# mit dieser Zeile auskommt:

string input = Console.ReadLine();

 
Scanner als Alternative
Seit Java 5 gibt es die Klasse java.util.Scanner, die man auch zum einlesen von Werten aus der Kommandozeile nutzen kann:

Scanner scanner = new Scanner(System.in);
String input = scanner.nextLine();

Es sind zwar auch 2 Zeilen Code, doch braucht man keine InputStreams und *Reader zu kombinieren. Für Strings ist der Vorteil wohl zu wenig gross, sonst würde nicht in so vielen Schulungsunterlagen die Variante mit dem BufferedReader erklärt.

 
Und Zahlen?
Der Scanner ermöglicht die Prüfung ob der nächste Wert vom gewünschten Datentyp ist. So genügt es den Scanner zu fragen und man spart sich den Aufwand den Wert selber zu überprüfen:

	public static void main(String[] args) {
		Scanner scanner = new Scanner(System.in);

		if (scanner.hasNextDouble()) {
			System.out.println("Ihre Zahl: " + scanner.nextDouble());
		} else {
			System.out.println("Leider kein Double gefunden.");
		}
	}

Ich finde dies deutlich angenehmer als mit dem BufferedReader-Ansatz und einer eigenen Validierungsmethode:

	public static void main(String[] args) throws IOException {
		BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
		String input = in.readLine();
		
		if (isDouble(input)) {
			double x = Double.valueOf(input).doubleValue();
			System.out.println("Ihre Zahl: " + x);
		} else {
			System.out.println("Leider kein Double gefunden.");
		}
	}

	public static boolean isDouble(String string) {
		try {
			Double.valueOf(string);
			return true;
		} catch (NumberFormatException e) {
			return false;
		}
	}

Vergisst man vor der Konvertierung zu prüfen ob es auch wirklich ein gültiger Wert ist, läuft man sehr schnell in diese Fehlermeldung:

Exception in thread "main" java.lang.NumberFormatException: For input string: "h"
at sun.misc.FloatingDecimal.readJavaFormatString(Unknown Source)
at java.lang.Double.valueOf(Unknown Source)
at ch.jgraber.blog.DemoTraditionalReadLine.main(DemoTraditionalReadLine.java:18)

 
Fazit
Java bietet mit java.util.Scanner eine einfache Möglichkeit um Strings oder Zahlen von der Kommandozeile zu lesen. Mir scheint als ob diese einfache Möglichkeit bisher zu wenig Beachtung findet. Suche ich nur falsch oder ist dies wirklich so?

Schlagworte:

SQL WHERE Bedingung erzeugen mit dem Composite Pattern

7. Januar 2011 6 Kommentare

In “Refactoring to Patterns” bin ich auf das Refactoring “Replace One/Many Distinctions with composite” gestossen. Dort wird ein Beispiel gezeigt bei dem verschiedene Kriterien (Gleich, Und, Oder) zu einem Entscheidungsbaum kombiniert werden.

Als ich mir die Grafik mit all den AND und OR anschaute, entdeckte ich darin eine mögliche Lösung für ein Problem mit SQL Abfragen. Bei einem Projekt nutzen wir DTOs um Daten aus der Datenbank zu unserem GUI zu bringen. Die Abfragemöglichkeit ist bisher auf AND limitiert, was aber für unseren Einsatzzweck ausreicht. Für Verknüpfungen mit OR und jede beliebige Mischung davon fehlt uns bisher eine elegante Lösung.

 
Ein Spike wird gestartet
Bei Extreme Programming gibt es sogenannte Spikes. Dies sind minimalisierte Projekte um genau ein Problem zu untersuchen. Ich finde diesen Ansatz recht praktisch und habe daher einen Spike gestartet um die Möglichkeiten des Composite Patterns auszutesten.

Für die Umsetzung braucht es ein Interface, dass von allen Klassen der WHERE Bedingung implementiert werden muss. Ich entschied mit für IWhereClause und die Methode GetClause():

interface IWhereClause
{
    string GetClause();
}

Am häufigsten wird wohl auf die Gleichheit von Werten geprüft werden müssen. Die Klasse EqualsClause soll dies ermöglichen:

class EqualsClause : IWhereClause
{
    private readonly string _leftSide;
    private readonly string _rightSide;

    public EqualsClause(string leftSide, string rightSide)
    {
        _leftSide = leftSide;
        _rightSide = rightSide;
    }

    public string GetClause()
    {
        return String.Format(" ({0} = '{1}') ", _leftSide, _rightSide);
    }
}

Erzeugt man ein Objekt mit den Parametern “x” und “done” wird dieses Ergebnis von GetClause() geliefert:

(x = ‘done’)

Soweit alles andere als spektakulär, aber dennoch ein wichtiger Grundstein. Der nächste Schritt ist die Verknüpfung mittels AND. Dazu dient die Klasse AndClause:

class AndClause : IWhereClause
{
    private readonly IWhereClause _leftSide;
    private readonly IWhereClause _rightSide;

    public AndClause(IWhereClause leftSide, IWhereClause rightSide)
    {
        _leftSide = leftSide;
        _rightSide = rightSide;
    }

    public string GetClause()
    {
        return String.Format(" ({0} AND {1}) ", _leftSide.GetClause(), _rightSide.GetClause());
    }
}

Dieser Klasse kann man nun Objekte die das Interface IWhereClause implementieren übergeben. Bis hier her erfüllen diese Bedingung EqualsClause und auch AndClause. So können nun mehrere AndClause Objekte ineinander verschachtelt werden.

 
Die WHERE Bedingung erzeugen
Analog der beiden Klassen habe ich mir noch NotEqualsClause und OrClause erzeugt. Diese variieren durch die veränderte Bedingung (OR statt AND und <> statt =) in GetClause(). Mit diesen 4 Klassen kann ich nun Werte auf Gleichheit oder Ungleichheit prüfen und die Ergebnisse mit AND oder OR verknüpfen. Es wird nun Zeit diese Möglichkeiten im Code zu nutzen.

Ziel ist es, so einen Entscheidungsbaum in C# zu erzeugen:

Die erzeugten Klassen werden dazu nun miteinander verschachtelt:

static void Main()
{
    // basic nodes with equals / not equals
    IWhereClause creationIsDone = new EqualsClause("creation", "done");
    IWhereClause paymentIsOpen = new EqualsClause("payment", "open");
    IWhereClause stateNotShipped = new NotEqualsClause("state", "shipped");

    // composites of nodes with and / or
    IWhereClause createdAndnotPaid = new AndClause(creationIsDone, paymentIsOpen);
    IWhereClause waitForPaymentORnotShipped = new OrClause(createdAndnotPaid, stateNotShipped);

    // This could build the SQL statement to get all created Orders  
    // who wait for payment or shipping
    Console.WriteLine("SELECT * FROM orders \nWHERE " + waitForPaymentORnotShipped.GetClause());

    Console.ReadLine();
}

Die Ausgabe kombiniert alle Objekte und liefert die Abfrage um alle erzeugten aber nicht bezahlten Aufträge sowie diejenigen die noch nicht verschickt wurden auszugeben:

SELECT * FROM orders
WHERE ( ( (creation = ‘done’) AND (payment = ‘open’) ) OR (state <> ‘shipped’) )

 
Fazit
Mit dem Composite Pattern kann man relativ einfach die WHERE Bedingung erzeugen. Für einen produktiven Einsatz benötigt dieser Spike allerdings noch einige Umbauten und Erweiterungen (wie ein Equals für long). Als Grundlage für weitere Diskussionen wird er aber seinen Zweck erfüllen.

Wer selber noch ein wenig experimentieren will findet den Source Code auf BitBucket unter http://bitbucket.org/jgraber/spike-whereclause.

Schlagworte:
Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 296 Followern an