Vom 19. bis 21.10. fand das diesjährige Leipziger Developer Open Space statt. Für Softwareentwickler, wie ich einer bin, ist das .NET Open Space eine interessante (Un-)Konferenz, bei der man viele neue Ideen und Eindrücke bekommt, und mit anderen aus der Branche Erfahrungen austauschen kann. Dieses Jahr gab es zum ersten Mal einen Workshoptag. Dadurch war das Open Space drei Tage lang, statt der bisher üblichen zwei. Hier das, was ich aus den Sessions mitgenommen habe:
Windows Azure Workshop
Sascha Dittmann hat uns gut in die Möglichkeiten eingeführt, welche Azure bereitstellt. Interessant war für mich insbesondere die gute Integration mit Visual Studio (direktes Deployment möglich) und github (Pushdeployment möglich). Ich hatte mir extra einen Testaccount bei Azure angelegt, damit ich während des Workshops die Features gleich testen konnte. Hier sind noch ein paar Slides, die Sascha verwendet hat: Einführung, Wege in die Cloud.
Persönlichkeitstypologie
Olga, die eigentlich auch Entwicklerin ist, sich aber sehr für Psychologie interessiert, bot eine zweistündige Einführung in die Persönlichkeitstypologie nach Myers und Briggs. Es war interessant darüber nachzudenken, welche Art von Person man ist, und wie man sich gegenüber anderen Typen verhält. In den USA ist diese Typisierung wohl weit verbreitet, und dient den Firmen dazu, Konfliktpotential zu reduzieren. Durch das Wissen um den Typen, der einem gegenübersteht, kann man entsprechend auf die Person eingehen. Klar geht das auch, wenn man Menschen besonders gut einschätzen kann. Ich bin vom Typ ISTJ.
Domain Driven Design + CQRS + Eventsourcing
Das war für mich eine gute Auffrischung der Konzepte und Möglichkeiten, die es bei Alternativen zu CRUD-Anwendungen gibt. Hier ging es speziell um komplexere Anwendungen, bei denen es besonders wichtig die Domäne gut zu erarbeiten, und die dort vorhandenen Aktionen am besten als Events zu verarbeiten. Dann ist natürlich auch CQRS sinnvoll, bei dem man einen Eventstore vorhält, aus dem dann die verschiedenen Sichten extrahiert werden können.
UI-Tests
Erst redeten wir allgemein über Testing, und wie die Erfahrungen der einzelnen Leute ist. Wir sprachen über UnitTests, Integrationstests, Behaviortests. Ich hatte in diesem Zusammenhang eine Session zu SpecFlow und Coypu vorgeschlagen. Folgende Erkenntnisse sammelte ich:
- UI-Tests dauern lange, und sind daher fürs Test Driven Development nicht geeignet.
- Einige lassen diese Tests nur ein Mal am Tag laufen.
- Sie eignen sich sehr gut zu Dokumentation und Besprechung der Features mit dem Kunden.
- Oft müssen die Entwickler, die die Tests schreiben, die Spezifikationen anpassen, damit die Tests einfacher umzusetzen und wiederverwendbar sind.
- Andere haben oft Probleme, dass mit Werkzeugen wie Selenium, die Tests mal durchlaufen und mal nicht, also kaum Verlässlichkeit entsteht.
- Andere Tools, die genutzt werden: White, MSTestContrib, PhantomJS mit CasperJS
Ruby on Rails
Auf dem Hof hörte ich mir eine kurze Einführung in die Welt von Ruby an, und was die Unterschiede zu Entwicklung in .NET sind. Sehr interessant.
Psychologie in der Entwicklung
Wieder Typeneinteilung, wie z.B. HOTS, OCEAN, und Farbkodierungen. Es ging darum Personen neutral einzuordnen, um danach effektivere Teams zusammenstellen zu können (mit der richtigen Mischung), und um besser untereinander kommunizieren zu könnnen (Verständnis für die Art und Weise wie andere denken).
Legacy Code
Zuerst wurde ein einfaches Tool für den Überblick vorgestellt: Signature Survey. Mit NDepend kann man natürlich noch viele andere Codestastiken bekommen. Danach ging es mehr darum, wie man es schafft in Brownfield nicht zu viel zu verändern, aber trotzdem seine Erweiterung gut einzubinden. Falls neue Funktionalität erforderlich ist, sollte man den neuen Code klar vom alten trennen (andere Klasse). Für neuen Code Tests schreiben. Im alten Code nur per Einzeiler (Methodenaufruf) den neuen Code aufrufen. Siehe hier auch den Blogpost von Johannes, der bei dieser Session und auch sonst sehr mitteilsam war.
Webanwendungen ohne Datenbanken
Mittels Lokad.CQRS (Sample, kein Framework) hat Jörg und sein Team die Webseite gebaut. Sie nutzt Eventsourcing (Events werden gespeichert, keine Objekte) und ein Eventstore. Sämtliche ViewModels sind vorbereitet und deren Daten werden als json-Dateien gespeichert. Dies ist auch in Azure möglich (über Blobstorage) – man braucht keine DB. Falls die views doch größer werden oder man Suchfunktionalitäten anbeiten möchte, so kann man später RavenDB einsetzen.
Webseite mit nanoc
Alex hat am Beispiel von grossweber.com gezeigt wie man mit nanoc Webseiten basierend auf markdown, haml und Layout erstellen kann. Nanoc bildet aus den Vorlagen und einer Konfiguration (Ruby) funktionierendes HTML. Das ist besonders für statische Seiten geeignet, jedoch muss man einige neue Sprachen und Tools erlernen.