Archiv

Archive for Februar 2013

TDD: Denken erlaubt

27. Februar 2013 2 Kommentare

Test-Driven Development (TDD) gibt auch heutzutage noch viel zu diskutieren. Was mir dabei immer wieder auffällt: Es scheint als ob vor lauter Red-Green-Refactor vergessen geht das man eigentlich Software entwickeln soll. Sobald man sich mit Tests beschäftigt vergisst man das grosse Ganze. Oder wieso schreiben gestandene Software-Entwickler einen Test nach dem anderen der ihnen nur bestätigt das 1 + 1 wirklich 2 ergibt?

 

Code Katas als Ursache?

Code Katas sollen einem dabei helfen sich bei einer Übung auf einen bestimmten Aspekt zu konzentrieren. Dieser Aspekt ist oft TDD, doch gibt es genügend andere Aspekte die man in den Vordergrund stellen kann (wie die Bedienung der IDE nur mit der Tastatur oder Patterns wie das Single Responsibility Principle).

Will man damit TDD erproben nimmt man in der Regel ein ganz einfaches Beispiel. Man will sich ja nicht lange mit dem Problem beschäftigen sondern TDD lernen. Entsprechend schreibt man viele Tests und denkt wenig über die Lösung nach – diese ist ja durch einfache Beispiele wie FizzBuzz gewollt. Man trainiert also ständig mit einfachen Beispielen und vielen Tests. Die Videos zu diesen Trainings zeigen entsprechend viele Tests und wenig Gedanken über die Lösung.

Kurzum: Der Feedback-Loop für den Entwickler zeigt ganz klar dass er TDD erst richtig macht wenn wer viel testet und wenig denkt. Das Problem ist nur das dies komplett falsch ist.

 

Software-Entwicklung vor TDD

Gehen wir einen Schritt zurück. Bevor man mit TDD Software entwickeln wollte machte man in der Regel diese Schritte:

  1. Problem analysieren
  2. Lösung erarbeiten
  3. Programmieren
  4. Testen
  5. Veröffentlichen
  6. Bugs fixen
  7. Veröffentlichen

Bei der iterativen Software-Entwicklung folgt man ebenfalls dieser Schrittfolge – einzig der Umfang behandelt nicht mehr das ganze System sondern nur einen Teil.

Die Idee von TDD war es ursprünglich einmal die Schritte 3 & 4 zu kombinieren. So hoffte man die teure Behebung von Bugs nach der Veröffentlichung zu minimieren. Nie war es das Ziel die Phase der Problemanalyse oder dem Erarbeiten der Lösung zu streichen.

 

Babysteps ins Chaos

Die Analyse der Problemstellung und das erarbeiten der Lösung ging irgendwo bei der Einarbeitung in TDD verloren. Irgendwann sollten Babysteps (wie 1+1 = 2) die Verständnislücken der Problemstellung füllen und die Lösung herausfallen. Nur wo passiert dies? Viel eher stehen all die minimalen Tests nur im Weg und erschweren die Weiterentwicklung der Software. Alleine mit Babysteps lösen wir das Problem nicht.

 

Schrittgrösse variieren

Wie aber geht man “richtig” vor? Kent Beck zeigt in “TDD By Example” wie man erst das Problem analysieren soll, eine Liste mit Testfällen (und noch anzugehenden Problemen) führt und vor allem wie man die Schrittgrösse variieren kann.

Das Red-Green-Refactor soll man beibehalten. Aber wenn man weiss wo hin man will und welche Lösung man verfolgt kann man grössere Schritte machen. Wie gross diese Schritte sind hängt vom konkreten Problem, der Vertrautheit mit der Technologie und dem angepeilten Lösungsweg ab.

Für den Lösungsweg greife ich oft auf Flussdiagramme zurück. So altmodisch die auch sein mögen, für eine grobe Skizzierung der Abläufe finde ich diese Art der Darstellung sehr hilfreich. Auch in der objektorientierten Programmierung gibt es unzählige Teilaufgaben die mit einem Flussdiagramm ideal abgebildet werden können.

Mit wenigen Worten pro Tätigkeit kann ich die einzelnen Kernaufgaben herausarbeiten. Ich sehe so auf einen Blick was alles zur Lösung dazu gehört und was es für Abhängigkeiten gibt. Passende Testfälle (und damit die Schrittgrösse) lassen sich so ebenfalls finden. Beim Programmieren tauchen dann immer noch genügend neue Testfälle auf. Diese können aber auch erst einmal nur auf eine Liste abgelegt und erst später priorisiert (oder gelöscht) werden.

 

Beispiele

Für das was ich bisher beschrieben habe gibt es zahlreiche gute Beispiele. Besonders empfehlen kann ich den Pluralsight-Kurs “Outside-In Test-Driven Development” von Mark Seemann. Darin wird erklärt wie man mit TDD bei den Akzeptanztests beginnt und schrittweise verfeinert bis der notwendige Code geschrieben ist. Beginnt man mit den Akzeptanztests verliert man das eigentliche Ziel nicht aus den Augen. Das Mantra Red-Green-Refactor bleibt gültig ohne dass man sich in den Babysteps verliert. Und sind diese kleinen Schritte doch nötig hat man ein Rahmenwerk das einem daran erinnert wann genug ist.

Wer Bücher bevorzugt findet in “Rails 4 in Action” von Ryan Bigg eine ausführliche Anleitung um testgetrieben eine Webanwendung zu erstellen. Hier wird noch mehr Wert auf die praktische Implementierung von TDD gelegt und gezeigt wie man mit unterschiedlichen Testebenen zu einer Lösung kommt.

 

Fazit

Nur weil man TDD macht muss man noch lange nicht aufhören selber zu denken. Eine Analyse der Lösung und ein grober Lösungsweg braucht es noch immer bevor man sich dem programmieren zuwendet. Verzichtet man auf diese grundlegenden Dinge schiebt man nur Code herum. Dies ist nicht nur ineffizient sondern auch teuer – sowohl beim erstmaligen schreiben wie auch bei all den kommenden Änderungen.

Daher unbedingt erst einmal abklären was man eigentlich machen will. Ist das “Was” klar geht es ans “Wie”. Ob man dazu ein Flussdiagramm oder eine sonstige Skizze macht spielt keine Rolle – wichtig ist das man sich überlegt wie man vorgehen will. TDD und Red-Green-Refactor können viel besser, klarer und sinnvoller angewendet werden wenn man diese Vorarbeiten macht.

Schlagworte: ,

Das passende Gem finden

24. Februar 2013 Kommentare aus

Für Ruby und Rails gibt es unzählige Helfer. Diese als Gem bezeichneten Pakete zu finden ist eine Herausforderung. Nicht weil es zu wenig Gems gibt, sondern weil so viele verschiedene Ansätze zur Auswahl stehen. Nicht nur für Einsteiger ist es schwer sich zu entscheiden. Soll man nun das nehmen was gerade “In” ist oder ist ein älteres Paket besser? Wie steht es um die Aktualität? Und wo findet man die Dokumentation?

Vor diesen Problemen stand auch Christoph Olszowka. Seine Lösung dazu war ein Verzeichnis zu starten bei dem die einzelnen Gems gesammelt und bewertet werden. Seit Ende 2011 ist diese Sammlung auf Ruby-Toolbox.com abrufbar.
 
The Ruby Toolbox

Die Gems werden nach Thema gruppiert und mit anderen Vertretern der gleichen Kategorie verglichen. Die Balkengrafik zeigt einem auf einen Blick welche Gems in der gewählten Kategorie beliebt sind. Links zur Webseite, der Dokumentation und zum Bug Tracker helfen einem sich schnell ein eigenes Bild zu machen. Und da man auch gleich sieht wie aktiv daran entwickelt wird erspart man sich böse Überraschungen.
 
Ruby Toolbox Details

Mir gefällt neben der Übersichtlichkeit der Seite vor allem die Erklärung wie die Werte zustande kommen. Hier gibt es keine “magische” Blackbox die die Projekte bewertet, sondern eine Formel die man selber überprüfen kann.
 
RubyToolox_Formula

Ruby-Toolbox.com ist für mich die Anlaufstelle wenn ich ein Gem für eine spezielle Aufgabe suche. Darüber hinaus ist es auch ein guter Platz um zu schauen wie vielfältig das Ruby-Ökosystem ist und was es alles für fertige Lösungen gibt.

Mein Tipp: Unbedingt anschauen!
 

Schlagworte:

MS SQL Server: Login mittels Passwort aktivieren

17. Februar 2013 Kommentare aus

Obwohl es kaum etwas Einfacheres gibt stosse ich bei der Arbeit mit dem SQL Server immer wieder auf ein Problem: Wieso kann ich nicht mit dem angegebenen Benutzernamen und Passwort auf die Datenbank zugreifen?

Die Fehlermeldung bleibt ja mit Absicht wage:

SQL Login Error

Schaut man ins Event Log findet man die Ursache:

Login failed for user 'demo'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. [CLIENT: ]

Auch bei diesem Server ist bisher nur ein Login mittels Windows-Authentifizierung erlaubt. Dies lässt sich aber schnell ändern. Dazu genügt es das Microsoft SQL Server Management Studio als Administrator zu starten und mittels Rechtsklick auf den Servernamen die Eigenschaften aufzurufen. Unter Security kann man dem SQL Server erlauben die Benutzer selber zu authentifizieren:

MS SQL Server Properties

Nach einem Neustart des SQL Server funktioniert der Login mittels Benutzername und Passwort wie gewünscht.

Kann man das SQL Server Management Studio verwenden ist diese Option schnell aktiviert – man muss nur daran denken dies auch zu tun. Hat man diese Möglichkeit wegen fehlenden Berechtigungen oder Security-Anforderungen nicht, wird es mühsam. In diesem Fall ist die Anleitung von Sven Schmalle sehr hilfreich.

Schlagworte: ,

Stolperfallen bei der Installation von SharePoint 2013

9. Februar 2013 5 Kommentare

SharePoint 2013 lässt sich ganz einfach installieren. Es sei denn man wählt eine falsche Option. In dem Fall endet man in einer Sackgasse aus der man kaum mehr herausfindet.

 

Niemals als Stand-alone installieren


Der Installationsdialog von SharePoint 2013 bietet gleich zu Beginn eine Auswahlmöglichkeit für den Server Typ:

  • Complete für den Produktiveinsatz
  • Stand-alone für Tests und Entwicklung

Egal in welchem Szenario man SharePoint nutzen will, man muss unbedingt die komplette Installation auswählen.

Bei meinem ersten Versuch wählte ich leider die Option „Stand-alone“. Die Installation läuft ohne Probleme durch und man kann am Ende gleich den Configuration Wizard starten lassen. Auch der beginnt wie gewohnt zu arbeiten. Bis dann plötzlich ganz spezielle Fehlermeldungen kommen:

„The SDDL string contains an invalid sid or a sid that cannot be translated“

Googelt man nach dieser Fehlermeldung findet man sehr viele Tipps. Irgendwann hat man die alle durch und jeder DB-User verfügt über alle möglichen Berechtigungen. Nur bleibt das Problem bestehen. Aus meinem Bekanntenkreis bekam ich den Tipp diese Übung abzubrechen, von vorne zu beginnen und „Farm“ oder „Complete“ als Installationstyp zu wählen. Damit war dieses Problem dann auch gehoben.

Martin Hinshelwood bringt es in seinem Blogpost auf den Punkt:

Everyone makes this mistake once so please take note… never… ever… select “Stand-alone” install option.

 

Installation mit lokalen Benutzern


Damit SharePoint 2013 voll funktioniert benötigt es für die Installation Domänen-Accounts. Der AD-Controller darf aber nicht auf dem gleichen System laufen wie SharePoint. Für ein produktives System ist dies kein Problem. Will man aber eine Entwicklungs- oder Testumgebung in einer virtuellen Maschine erzeugen sieht es anders aus.

Man kann nun entweder eine zusätzliche VM fürs Active Directory aufbauen oder einen Account aus dem (Firmen-) AD benutzen. Wenn man auf einige Features wie die Volltext-Suche verzichten kann gibt es noch eine weitere Möglichkeit: PowerShell.

Dazu startet man die Management Shell von SharePoint 2013 als Administrator und führt diesen Befehl aus:

New-SPConfigurationDatabase

Es folgen einige Fragen die man beantworten muss und in wenigen Minuten wird die Konfigurationsdatenbank für SharePoint erzeugt. Nun muss noch einmal der Configuration Wizard ausgeführt werden und schon läuft ein (fast vollständiger) SharePoint 2013.

 

Fazit


Wählt man den falschen Server-Typ wird aus einer einfachen Sache wie der Installation von SharePoint schnell ein ausgedehntes Abenteuer. Aber selbst wenn man die richtige Option wählt warten weitere „Gefahren“. Für die erste Installation von SharePoint 2013 sollte man daher genügend Zeit einplanen.

Schlagworte: ,

Buch-Rezension zu “Domain-Driven Design”

3. Februar 2013 1 Kommentar

Domain-Driven DesignWenn man sich mit Behavior Driven Development (BDD) und dem Schreiben von Akzeptanztests beschäftigt stösst man immer wieder auf ein Buch:
Domain-Driven Design: Tackling Complexity in the Heart of Software” von Eric Evans.

Dieses Buch gilt weit herum als Standardwerk das man unbedingt kennen muss. Beim Lesen merkt man schnell das Evans sehr viel Erfahrung hat und weiss wovon er schreibt. Leider macht er dies so ausführlich dass man kaum vorwärts kommt. “Man müsse die Informationen herausschürfen” ist eine Bemerkung über dieses Buch die man beim Lesen im Hinterkopf behalten sollte.

 

Kernpunkte

Von all den Themen die Evans behandelt stechen für mich diese Punkte besonders hervor:

Mit Hilfe einer Ubiquitous Language (einer einzigen gemeinsamen Sprache) sollen alle am Projekt beteiligten Personen kommunizieren. Dadurch das alle die gleichen Begriffe benutzen können Missverständnisse und Übersetzungsprobleme (im Sinne von Fachspezifisch zu Technisch) früh erkannt werden oder entfallen ganz. Auch ist es für Entwickler einfacher sich an die Spezifikationen zu halten wenn die Objekte im Code gleich heissen wie in den Anforderungen und den Testszenarios.

Bei Refactoring denkt man meistens an einen technischen Vorgang um Code besser zu strukturieren. Neben diesem technischen Aspekt gibt es aber auch einen fachlichen. Evens zeigt bei „Refactoring Toward Deeper Insight“ auf wie man nach und nach das Domänenmodell um neue Erkenntnisse verfeinern kann.

Entwickelt man nach Model Driven Design darf das Modell nicht in einem Vakuum erstellt werden. Ist dieses Modell technisch nicht umsetzbar wird in der Entwicklung gezwungenermassen eine Lösung gefunden die davon abweicht. Damit verliert man alle Vorteile und muss ständig zwischen mehreren Modellen hin und her wechseln. Neben höheren Kosten leidet dabei auch die Kommunikation.

Bounded Context: Das eigene Domänenmodell kann noch so gut sein, wenn man es nicht abgrenzt fliessen die unterschiedlichen Konzepte der Umsysteme hinein. Evens zeigt eine ganze Reihe von Ansätzen um dies zu verhindern (wie das Pattern “Anticorruption Layer”).

Software-Entwicklung ist mehr als das Schreiben von Code. Es geht um das Lösen von Problemen. Damit man die passende Lösung finden kann ist eine Zusammenarbeit mit allen beteiligten Parteien nötigt.

 

Kritik

Die gleichen Namen und Bezeichnungen zu verwenden ist ein grosser Schritt in die richtige Richtung. Nur ist es damit nicht getan. Mir fehlt wie man auch zu einer gemeinsamen Bedeutung kommt und überhaupt die Wiedersprüche aufdecken kann. (Wenn alle von Autos sprechen, wie merkt man das der eine einen Golf meint und der anderen einen Ferrari?)

Die ersten beiden Teile sind sehr schwerfällig geschrieben. Immer wieder springt Evans von einer Idee zur nächsten und wieder holt dieses hin und her mehrmals. Würde dies aus unterschiedlichen Perspektiven geschehen wäre dies ein Plus fürs Buch. Leider sucht man die ganze Zeit nach den Unterschieden zum bereits behandelten und findet meist keine. Dies bremst den Lesefluss und schlägt auf die Motivation.

Anstelle der vielen Wiederholungen wären Beispiele zur technischen Umsetzung hilfreich. Statt so viel über Code zu sprechen hätte Evens diesen zeigen können – dies ginge schneller und hätte einen Praxisnutzen. So bleibt zu viel eine schöne Idee ohne Hinweis auf deren Umsetzung.

 

Alternative

Abel Avram und Floyd Marinescu sahen ebenfalls einige Verbesserungsmöglichkeiten und schrieben 2006 das Mini-Book “Domain Driven Design Quickly“. Auf rund 100 Seiten gibt es all die Konzepte aus dem Buch von Evans, ein Interview mit ihm und es hat noch Platz für Ergänzungen aus “Applying DDD” von Jimmy Nilsson.

Wer ins Thema DDD einsteigen will sollte sich erst einmal das PDF bei InfoQ herunterladen.

 

Fazit

Mit Domain-Driven Design wurden viele wichtige Ideen erstmals in Buchform veröffentlicht. Die darin behandelten Themen sind auch heute noch aktuell und ein Umsetzen der von Evens vorgestellten Ansätze würde so manches aktuelle Problem lösen.

Leider verzettelt sich Evans mit seinen Erklärungen und macht es dem Leser äusserst schwer diese Konzepte zu verstehen. Als Einstiegslektüre ins Thema DDD kann ich dieses Buch daher nicht empfehlen. “Domain Driven Design Quickly” ist dafür die bessere Wahl, da die gleichen Konzepte viel besser auf den Punkt gebracht werden.
Kehrt man nach diesem Umweg zu Evens zurück versteht man seine Ideen viel besser und erkennt dann auch was sonst noch alles für Informationen in diesem Buch stecken.

 

Zum Buch

Domain-Driven Design: Tackling Complexity in the Heart of Software” von Eric Evans, 2003 Addison-Wesley, ISBN 978-0-3211-2521-7, 560 Seiten, Englisch

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 296 Followern an