19.12. Test Driven JavaScript Development

A couple of weeks ago, I was attending a three-day workshop for agile developer skills. The workshop was split into five topics: Colaboration, Refactoring, Design & Architecture, Continious Integration and Test Driven Development. Especially the session about Test Driven Development was very interesting. Although I know the principles of TDD I was really impressed by the demonstration of solving a simple exercise (a coding kata) done in Java by the instructors of the workshop. It was not so much the coding in Java that was interesting for me, it was the combination of writing a test, executing the test with a shortcut from the IDE, see the test fail, write the implementation and re-start the test again within the IDE. You will say “that´s test driven development- it´s nothing new!” and you are right! But is there a way to do Test Driven Development in the same way for JavaScript? I mean writing a test, execute the tests with a shortcut from the IDE, see the test fail, implement the method and re-start the test? Yes, there is a way! So let me show you what I have done to do the same coding kata (called Fizzbuzz) with JavaScript.

Weiterlesen

08.12. Agilere Datenbankentwicklung

Agile Entwicklung ist gescheitert.
Jedenfalls auf Datenbankseite.

Agile Entwicklung ist mehr als nur Scrum, hierzu kommen in den meisten Projekten noch weitere Tools und Vorgehensweisen zum Einsatz, um schnell auf neue Anforderungen zu reagieren.
Hierzu zählen in der eigentlichen Entwicklung Continuous Improvements, also das stetige Verbessern des Quellcode innerhalb eines Projektes, welche zum Beispiel durch Code Reviews und Refactorings unterstützt werden können.

Bedingt durch die sich schnell ändernden Anforderungen ändert sich auch der Code schneller und häufiger.
Um sich dennoch abzusichern, kommen hier Tools wie automatisierte Unittests, ausgeführt Beispielsweise in einer Continuous Integration Umgebung zum Einsatz.

Inzwischen haben viele Projekte zudem erkannt, dass die kurzen Entwicklungszyklen, die mithilfe, eben genannter Techniken möglich werden, entsprechend kurze Releasezyklen erfordern.
Im Idealfall führt dies zu einem Continuous Deployment, also der Fähigkeit ein Feature sofort nach der Fertigstellung zu releasen.

Ein Prozess ist jedoch immer nur so gut, wie seine Teilprozesse.
An dieser Stelle sollten wir unseren Blick auf die Datenbank lenken.

  • Wie läuft hier die Entwicklung?
  • Wie automatisieren wir Datenbankupdates?
  • Was für einen Stand hat unsere Datenbank auf Produktiv? Auf Staging? Auf dem Previewsystem?
  • Wie sichern wir Datenverluste bei nachträglichen Änderungen ab?

Bei uns lief es im Projekt bis vor kurzem so, dass vor einem Update der Datenbank händisch geprüft werden musste welche Änderungen noch nicht in der Datenbank existieren um dann entsprechende SQL Dateien zusammenfügen zu können, die die neuen Änderungen enthielten.
So ein Vorgehen ist nicht nur Fehleranfällig sondern auch Aufwendig.
Am stärksten Bemerkbar machte sich dies, beim migrieren von Daten, was bedeutete, dass die Reihenfolge von SQL Dateien und Migrationsskripten strikt beachtet werden musste.

Refactorings hingegen liefen so ab, dass die neue Datenstruktur in Form von neuen Tabellen angelegt wurde, die Daten mithilfe von Migrationsskripten überführt wurden und die ursprünglichen Tabellen erst beim nächsten Release vollständig gelöscht wurden, sofern dies nicht vergessen wurde.

Dieses Vorgehen kostete viel Zeit und Nerven, weshalb eine Alternative gesucht wurde.

Vor kurzem haben wir als Team ein neues Tool gefunden welches uns viel Arbeit abnimmt und vor allem zusätzliche Sicherheit auf Datenbankseite gibt.

Dies ist Liquibase, ein in Java geschriebenes Tool zum Refactoring und automatischen Update der Datenbank, welches unter der Apache 2.0 Lizenz zur freien Nutzung zur Verfügung steht.

Liquibase bringt eine eigene Beschreibungssprache für Datenbankänderungen mit, die auf XML basiert.
Durch diese abstrakte Beschreibung der Änderungen in XML wird Datenbankunabhängigkeit ermöglicht.
So kann Liquibase mit jeder Datenbank umgehen für die ein JDBC Treiber verfügbar ist, so zum Beispiel MySQL, Microsoft SQL Server, Oracle, PostgreSQL, SQLite, Apache Derby und vielen weiteren.

Definiert werden die Änderungen als sogenannte Changesets, die in beliebiger Anzahl innerhalb eines DatabaseChangelogs vorkommen können.
Jedes Changeset setzt die Angabe eines Autors und einer Id voraus, wobei die Id nur innerhalb des DatabaseChangelogs eindeutig sein muss.

Ein einfaches Changelog, der eine einzelne Tabelle mit 2 Spalten, id und name, anlegt sieht wie folgt aus:

 	
	        				
		            		
			                			
				            		
			            		
			                					
				            		
			            	
		    
	

Ausgeführt werden kann dieses Changelog entweder innerhalb eines vorhandenen Buildsystems, hierfür gibt es Tasks in ANT, Maven, Grails, Spring und in Phing als Erweiterung unter https://github.com/bitExpert/liquibase-phing, oder über die Kommandozeile:

java -jar liquibase.jar \
    --driver=com.mysql.jdbc.Driver \     
    --classpath=databasedriver/mysql-connector-java-5.1.17-bin.jar \     
    --changeLogFile=/path/to/changelog.xml \     
    --url="jdbc:mysql://127.0.0.1:3306/" \     
   --username= \     
   --password= \     
update

Bei diesem Aufruf wird der Treibertyp, in unserem Fall JDBC MySQL, das Verzeichnis des Treibers, der Pfad zum auszuführenden Changelog, sowie URL der Datenbank, Nutzername und Passwort angegeben und der Befehl update, um Liquibase zu veranlassen, dass alle Änderungen eingespielt werden, die noch nicht in der Datenbank sind.
Am Rande sei hier bemerkt, dass der JDBC Treiber für die jeweilige Datenbank nicht Teil von Liquibase ist, ergo separat heruntergeladen werden muss.

Wer sich jetzt fragt, woher Liquibase wissen kann, was bereits in der Datenbank vorhanden ist und was geupdatet werden muss, dem möge folgende kurze Erklärung dienen:
Liquibase speichert in der Tabelle DATABASECHANGELOG Metainformationen zu jedem erfolgtem Update ab.
Hierzu gehört für jedes ausgeführte Changeset der Autor, die Id, das Ausführungsdatum und eine Hashsumme des Changesets.
Die Hashsumme wird bei jedem neuen Update für alle bereits vorhandenen Changesets geprüft, so dass nachträgliche Änderungen an einem bereits ausgeführten Changeset nicht mehr möglich sind.
Es gibt zwar die Möglichkeit mit dem Kommandozeilenbefehl clearChecksums alle Hashsummen zu löschen, jedoch ist die saubere Vorgehensweise bei einem Fehler ein neues Changeset anzulegen, welches den Fehler behebt.

Der größte Vorteil, den man mit echten Changesets gewinnt, sind die Rollbacks.
Für alle Änderungen die neue Tabellen, Spalten oder ähnliches anlegen, oder bestehende Verändern, bietet Liquibase automatische Rollbacks.
Diese werden wichtig, sobald beim updaten etwas schief geht, denn dann wird der Rollback ausgeführt, so dass eine inkonsistente Datenbank verhindert wird.
Jedoch sind die Rollbacks auch in der Entwicklung sehr nützlich, da jederzeit zu einem bestimmten Stand der Datenbank zurück gekehrt werden kann.
Dies ist Changesetabhängig möglich, mit rollbackCount n, welches die letzten n Changesets zurück nimmt, Datumsabhängig mit rollbackDate <date>, welches alle Changesets die neuer als das angegebene Datum sind zurück nimmt und Tag abhängig.
Letzteres kehrt dabei zu einem in Liquibase gesicherten Stand der Datenbank zurück, einem sogenanntem Tag.

Für alle Rollbacks, die nicht mit einem Automatismus abgedeckt werden, kann auch manuell ein Rollback definiert werden.
Dies ist zum Beispiel der Fall wenn das Löschen einer Tabelle fehlschlägt und darauf entsprechend reagiert werden soll.
Das Definieren geschieht innerhalb des entsprechenden Changesets, indem nach der eigentlichen Anweisung eine oder mehrere Rollbackanweisungen geschrieben werden, die alle innerhalb des Tags <rollback> stehen müssen.

In den meisten Teams ist Dokumentation nicht gerade beliebt, jedoch ein notwendiges Übel um neuen Teammitgliedern den Einstieg zu erleichtern und nachvollziehbar zu machen, welche Änderungen wann gemacht wurden.
Auch hier Unterstützt uns Liquibase.
Mit dem Befehl dbDoc und einer nachfolgenden Pfadangabe ist es möglich, eine Dokumentation aller Änderungen zu generieren, die mit dem angegebenen DatabaseChangeLog durchgeführt werden würden.
Die dabei entstehende Änderungsdokumentation ist dabei stark an Java-Doc angelehnt.

Am meisten Zeit bei der Datenbankentwicklung mit Liquibase verschlingt das Schreiben der Changesets.
Zum Glück stellt auch hier Liquibase ein Tool bereit.
Die Methode diffChangeLog generiert anhand der Unterschiede zwischen zwei Datenbanken die entsprechenden Changesets.
Der Kommandozeilenaufruf dazu sieht ähnlich aus, wie beim updaten der Datenbank, jedoch werden zusätzlich die Daten der zweiten Datenbank angegeben, gegen welche geprüft wird:

java -jar liquibase.jar     \
	[...]    
	--changeLogFile=../data/sql/generatedChangelog.xml     \
	diffChangeLog   \  
	--referenceUrl=  \   
	--referenceUsername= \     	
	--referencePassword=

Die neuen Changesets werden im angegebenen changeLogFile gespeichert.
Dabei werden sowohl Stored Procedures und Functions, als auch Trigger und Check Constraints ignoriert.

Die Unterschiede können mit Liquibase auch zwischen verschiedenen Datenbanksystemen ermittelt werde, beispielsweise einer MySQL und einer SQLite Datenbank.

Auch wenn die Einarbeitung in Liquibase einige Zeit erfordert und vor allem eine Umstellung in der Arbeitsweise, so möchte ich dieses geniale Tool im täglichen Arbeiten nicht mehr missen, da uns als Team damit viele Sorgen und Mehraufwände abgenommen werden.

Agiles CSS

Bei Mayflower wird agil entwickelt. In erster Linie bedeutet dies für den Kunden, dass wir auf geänderte Anforderungen schnell reagieren können.
Schnell reagieren zu können heißt auch, neue oder geänderte Anforderungen so schnell wie möglich umzusetzen.
Dafür muss der Code so aufgebaut sein, dass man mit minimalen Aufwand Änderungen durchführen kann.
In PHP nutzen wir dafür entsprechende Abstraktionen und Kappselungen.

Aber wie schaut das Ganze im Frontend aus, insbesondere in CSS Dateien?
Was, wenn der Kunde das Blau aus dem vorgegebenen Farbschema eine Nuance dunkler haben möchte?
Weiterlesen

„Agile Estimation and Planning“ talk @Mayflower – Munich

Am kommenden Donnerstag, den 30.07.2009 findet wieder ein öffentlicher Vortrag im Mayflower Büro in München statt.
Begin ist um 18:00 Uhr, Thema des Vortrages ist „Agile Estimation and Planning“.

In diesem Vortrag gibt es einen Einblick in die Grundlagen der Agilen Software Entwicklung, der Planung und Abschätzung.

Wer teilnehmen möchte kann sich auf Facebook dafür registrieren.

Die „Donnerstag Vorträge“ werden sowohl in München als auch Würzburg gehalten. Bei Interesse einfach das Blog beobachten um auf dem laufenden zu bleiben.


Größere Kartenansicht

Sonntagslektüre: Agile Programmierung im Neuen Web

via Robert und dem popnutten Blog bin ich auf die Diplomarbeit zu „Agile Programmierung im Neuen Web“ gestoßen. Der dazugehörige Blog-Eintrag im mite Blog sagt:

„Was macht es neu, das Neue Web? Was ändert das ‘neu’ an den Strategien, ein Produkt wie mite zu entwickeln? Was ändert sich auf Programmiererseite, im Produktmanagement, im Projektmanagement? Was hat ein Begriff wie Leidenschaft im Softwarebereich zu suchen, bitte?“ und „Die Arbeit steht unter dieser Creative Commons Lizenz. Lesen, weitergeben, verfielfältigen, remixen, kritisieren, verbessern ist mehr als erwünscht, solange die Nutzung nicht-kommerziell erfolgt und ihr unsere Namen nennt. Wir haben uns während der Recherche über jede zugängliche Arbeit gefreut, und hoffen, so unseren kleinen Teil zurückgeben zu können. Viel Vergnügen!“

 

Indes macht der Abstract der Diplomarbeit neugierig:

„Iterative und agile Softwareentwicklungsmodelle führen zu einer Verbesserung der Qualität
des Produkts, zu einer erhöhten Zufriedenheit der Kunden sowie zu einer Steigerung der Produktivität
im Entwicklungsteam. Die Strömung, Funktionalität von Desktop-Anwendungen
ins Web zu transferieren, erfordert in Kombination mit raschen Veränderungen des Produktumfelds
die Adaption agiler Werte, Prinzipien und Praktiken an neue Grundannahmen.

Zielsetzung dieser Diplomarbeit ist der Entwurf eines ganzheitlich agilen Ansatzes für die
Produktentwicklung
im Neuen Web, unter Miteinbeziehung der Bereiche Produkt- und
Projektmanagement.

Anhand der Entwicklung und Markteinführung einer Webanwendung
zur Zeiterfassung
für Freiberufler und kleinere Unternehmen der Medienbranche soll das
Modell auf seine Tauglichkeit in der Praxis überprüft werden.

Die Ergebnisse der Arbeit zeigen, dass im Neuen Web mit einem kleinen Team und einem
gegen Null tendierenden Marketingbudget in Orientierung am entworfenen agilen Modell
erfolgreich eine Webapplikation entwickelt und auf dem deutschsprachigen Markt positioniert
werden kann, die von einer kontinuierlich wachsenden Anwenderschaft mit Zufriedenheit
eingesetzt wird.“

 

Für die Entwickler unter uns wird es erst ab Seite 45 so richtig interessant. Davor folgt eine meiner Meinung nach etwas langatmige Auflistung der typischen Web2.0 Dienste wie Flickr, YouTube usw., der Wichtigtuerei rund um Blogs (tendenziöse Wertung von mir, aber was soll ich auch schon anderes denken, wenn das „Person of the Year: YOU“ Cover der Time in der Diplomarbeit abgehandelt wird?), und einer wichtigen, allgemeinen Erklärung der einzelnen Webtechniken/Begriffe wie AJAX und XMLHttpRequest.

 

Aber wir waren ja bei Seite 45 resp. Kapitel 3 stehen geblieben. Es folgt die Einführung in das Wasserfallmodell, das sich für sequenzielle Entwicklung gut eignet, aber wohl bei „moving targets“, also beweglichen Zielen passen muss. Danach schwenkt die Arbeit über in iterative Entwicklung, agile Entwicklung und landet dann natürlich auch beim Agilen Manifest. eXtreme Programming, RUP und Konsorten dürfen nicht fehlen. In Kapitel 5 geht es dann ans Eingemachte: ab hier beschreiben die Autoren ihren Weg von der Auswahl des Frameworks bis hin zur fertigen Software, mite eben. Ebenfalls werden die Iterationen in der Entwicklung beschrieben und Schwierigkeiten beleuchtet, sowie eine Analyse über die Aufmerksamkeit für und den Erfolg vom Produkt abgehandelt.

 

Die Autoren schliessen mit dem Fazit: „Die Ergebnisse der Arbeit zeigten, dass im Neuen Web in Orientierung am entworfenen
ganzheitlich agilen Modell erfolgreich eine Webanwendung entwickelt werden kann, die der
Benutzer mit Zufriedenheit neben seinen Desktopanwendungen einsetzt. Pflegt das Unternehmen
eine offene und ehrliche Kommunikationskultur, lässt sich das Produkt mit einem
gegen Null tendierenden Marketingbudget unter Nutzung der Strukturen des Neuen Webs auf
dem (deutschsprachigen) Markt positionieren.“

So sei es, und mal sehen, ob sich der erste gute Eindruck auch bei näherem Hinsehen bewährt.

 

Daneben finde ich es schön, dass sich die Creative Commons Lizenz immer mehr durchsetzt (man beachte dazu auch diese und jene Erweiterungen auf sevenload).