Codecamp 2016: Das Erlebnis in Bildern

Natürlich geht es im CodeCamp darum, an selbstbestimmten, interessanten Themen zu arbeiten, neue Technologien auszuprobieren und somit gemeinsam neues Know-how zu erlangen. Mindestens genauso wichtig ist dabei, im Team eine richtig gute Zeit zu haben. Das haben wir dieses Jahr auch wieder gut genutzt. Um einen Einblick in das Erlebte zu geben, hier eine kleine Auswahl dessen, was das CodeCamp dieses Jahr zu einem besonderen Erlebnis gemacht hat.

‍

Und hier ist ein kleiner Ausschnitt aus den Projekten die durchgeführt wurden:

Zeiterfassungs-Tool mit Scala.JS, AKKA und Event Sourcing

Für das CodeCamp 2016 haben wir uns das Ziel gesetzt, ein Projekt mit Scala, Scala.js und Akka unter Verwendung des Event Sourcing-Pattern umzusetzen.

Die Projektidee

Bereits vor einigen Jahren haben wir bei Cap3 ein Tool zur Zeiterfassung entwickelt und dann auch eine Zeit lang in Projekten eingesetzt. Ole und ich sind noch immer der Meinung, dass ein eigenes Zeiterfassungs-Tool eine coole Sache ist. Daher haben wir uns vorgenommen, das Zeiterfassungs-Tool als Web-Backend in Kombination mit einer Single-Page-Application neu aufzusetzen.

Ein Konzept und gute Designs von Moritz Schönfeld existierten bereits, sodass hier das Rad nicht neu erfunden werden musste.

Kurz zum Hintergrund des Zeiterfassungs-Tools: Um die Aufwände für unsere Projekte im Blick zu behalten, trackt jeder Entwickler die Zeit, die er an einem Projekt arbeitet. Auch Aufwände für Projektmanagement oder Designleistungen werden so erfasst. Die Zeiterfassung soll perfekt auf unsere Bedürfnisse zugeschnitten mit wenigen Klicks (so einfach wie möglich) erfolgen.

Am ersten Tag des CodeCamps haben wir zusammen mit Nicolas eine kurze Event Storming-Session für das Zeiterfassungs-Tool durchgeführt. Dadurch konnten wir sehr schnell die Kern-Features, die wir in der kurzen Zeit umsetzen wollten, identifizieren. Außerdem konnten wir die Events direkt in der Umsetzung des Backends verwenden.

Technische Details

Scala.js bietet die Möglichkeit, den kompletten Code eines webbasierten Frontends in Scala zu schreiben. Im Vergleich zu JavaScript bietet der Einsatz von Scala in unseren Augen viele Vorteile, z. B. statische Typisierung, bessere IDE-Unterstützung, bessere Wartbarkeit, weniger Code. Aber auch im Vergleich zu TypeScript bietet Scala.js weitere Vorteile, dazu zählen: Starke Typisierung, eine größere Standard-Bibliothek, Code wird durch Compiler optimiert.

In Kombination mit einem Backend, das ebenfalls mit Scala umgesetzt ist, kann außerdem Code zwischen Frontend und Backend geteilt werden. Das heißt, man erhält z. B. eine typisierte Kommunikationsschnittstelle zwischen Frontend und Backend, die im Code immer aktuell ist. Viele Fehler, die durch Änderungen an der Schnittstelle entstehen können, werden bereits beim Kompilieren gefunden.

Natürlich gibt es auch Nachteile, u. a. ist die Größe des Kompilats mindestens 45kB groß.

Im Frontend haben wir React und Diode (Bibliothek inspiriert durch Flux, Elm und Redux) eingesetzt. Das Backend haben wir mit dem Play-Framework und Akka/Akka Persistence/Akka Persistence Query unter Anwendung des Event Sourcing-Patterns umgesetzt. Entgegen der traditionellen Datenhaltung in einem relationalen Schema wird der Anwendungszustand als eine Sequenz von Events erfasst (vgl. martinfowler.com “Event Sourcing”). Eine Technik mit vielen Vorteilen, die wir gerne einmal in einem Kundenprojekt einsetzen möchten.

Auftauchende Probleme bei der Entwicklung

Insgesamt lief der Einsatz der neuen Technologie erstaunlich glatt. Ein nennenswertes Problem tauchte allerdings dennoch auf: Wir hatten bei Projektstart auf die Bibliothek Autowire gesetzt. Autowire bietet Mittel, den für die Netzwerkübertragung zwischen Front- und Backend nötigen Code automatisch erzeugen zu lassen. Zunächst sparte uns der Einsatz der Bibliothek Zeit und wir konnten direkt die Anwendungslogik implementieren. Als es allerdings ins Detail ging, mussten wir feststellen, dass wir nicht genug Kontrolle über die Kommunikation hatten. Beispielsweise war es nicht möglich, den zurückgegebenen HTTP-Statuscode zu beeinflussen. Das Hauptproblem war aber, dass Autowire nicht mit unserem Dependency-Injection-Ansatz zusammengespielt hat. Nachdem wir uns entschieden hatten, auf die Bibliothek zu verzichten, war die fehlende Kommunikationsschicht dann aber in knapp zwei Stunden nachgezogen.

Unser Fazit

Wir sind mit dem Projektergebnis sehr zufrieden. Die gewonnenen Erkenntnisse haben uns weiter darin bestärkt, auf Scala zu setzen. Die Erwartungen an Scala.js, worauf der Fokus lag, sind vollständig erfüllt worden: Scala.js bietet sehr gute Möglichkeiten, eine Webanwendung mit hoher Qualität zu entwickeln.

Terminbuchungssystem mit Techniken des Domain Driven Design

Frederic und ich haben uns für das CodeCamp vorgenommen, eine Terminbuchungsapp für „unseren Koch“ Marcel umzusetzen. Marcel bereitet uns schon seit vielen Monaten immer donnerstags bei Cap3 leckere vegetarische Gerichte zu (https://www.facebook.com/Mittagshoch).

Damit er eine Einschätzung hat, wie viele hungrige Cap3ler ein Mittagessen wünschen, nutzen wir momentan eine Doodle-Liste. Marcel verfolgt die Vision, sich mit seinem Geschäftsmodell an lokale Unternehmen und deren Mitarbeiter zu richten, und über gesundes und saisonales Essen am Arbeitsplatz eine Kontakt-Plattform zum Vernetzen anzubieten. Hierfür gilt es, verbindliche Zusagen der Teilnehmer zu erhalten, sowie bestenfalls auch schon im Voraus eine elektronische Bezahlung einzuholen. Marcel hat sein Mittagessen-Buchungssystem vor dem CodeCamp bei uns gepitcht und konnte ein Team für die prototypische Umsetzung seiner Idee gewinnen.

Wir nutzten dieses Projekt, um u. a. eine Methodik des Domain Driven Designs zu üben – das Event Storming nach Alberto Brandolini. Zunächst definierten wir alle Domain Events im Kontext der Idee (je Event ein orangenes Post-it), um diese anschließend zu Aggregaten zu gruppieren. Danach definierten wir externe Systeme – in unserem Falle die Bezahlung über PayPal (lilafarbenes Post-it) – und Prozesse bzw. Interaktionen (blaue Post-its) der zukünftigen Benutzer der App. Das klappte so weit schon ganz gut und die beim Event Storming entstehenden Diskussionen waren auf jeden Fall sehr aufschlussreich.

Die Entwicklung

Frederic und ich nutzen das entstandene Bild, um uns nach kurzer Einweisung von Nicolas am Event Sourcing zu versuchen. Das Event Sourcing beschreibt eine Methodik der Software-Entwicklung, bei der jede Veränderung des System-Zustands als Event gespeichert wird.

Dies hat zur Folge, dass – im Gegensatz zu Systemen, die nur den aktuellen Zustand vorhalten – immer die komplette Historie aller Änderungen verfügbar ist, sodass praktisch jeder beliebige Zustand des (Teil-)Systems zu jedem Zeitpunkt wiederhergestellt werden kann. Gerade bei Systemen, bei denen die Verfügbarkeit der Historie von Daten essenziell ist (z. B. Finance IT), ist der Einsatz von Event Sourcing meistens sinnvoll.

Durch die Verfügbarkeit der Historie können auch noch zu einem späteren Zeitpunkt bestimmte Abfragen an das System gestellt werden (z. B. wie viele Kunden haben 5 Minuten vor einer Bestellung Waren aus dem Warenkorb gelöscht?).

Durch die andere Art der Persistierung war diese Methodik für uns zunächst ungewohnt und erforderte eine andere Denkweise. Durch den Einsatz der Programmiersprache „Scala“ sowie „Akka-Persistence“ – einem Framework, welches Event Sourcing ermöglicht – konnten wir schnell erste Erfolge erzielen. Während wir also mit der Programmierung losgelegt haben, skizzierte unser User-Interface-Designer Ben anhand der Dokumentation zusammen mit Felix und Kira die einzelnen Sichten der App und machte sich anschließend an die Umsetzung der konkreten Entwürfe.

Zurück zu Frederics und meiner Entwicklung: So richtig gestartet mit der Umsetzung haben wir erst am Freitagmittag, das heißt uns blieben auch nur noch ca. 1,5 Tage für die weitere Umsetzung. Leider etwas zu wenig Zeit für eine komplette Entwicklung des Systems. Was wir allerdings auf die Beine stellen konnten ist das Grundsystem mit Event Sourcing, sodass später ohne viel weiteren Aufwand weiterentwickelt werden kann.

Fazit

Wir sind mit dem Projektergebnis zufrieden, obwohl wir uns gewünscht hätten, etwas mehr Zeit zu haben, um noch tiefer in das Thema einzusteigen. Durch dieses Projekt haben wir die Erkenntnis gewonnen, dass Software- Systeme von einer Event Sourcing-Architektur profitieren können. Event Sourcing wird zukünftig auch in Kundenprojekten bei Cap3 eingesetzt werden.

‍

Tower Defense mit .NET Core

Für unser CodeCamp haben Basti, Ben und ich uns zusammengefunden, um ein simples Spiel mit .NET Core zu entwickeln. Wir entschieden uns aufgrund der relativ leichten Umsetzung für ein Tower Defense-Spiel auf einem Hex-Grid.

Die Spielregeln von Tower Defense sind schnell erklärt: Jedes Hexagon stellt eine Position auf dem Spielfeld dar. Jeder Spieler hat seine Base auf dem Spielfeld, die es vor den Angreifern des anderen zu verteidigen gilt. Zur Verteidigung werden Türme auf dem Spielfeld platziert, die die Angreifer abwehren. Der Weg der Angreifer wird durch die Zwischenräume zwischen den Türmen definiert. Zwischen den Türmen muss also immer ein Weg frei bleiben.

Die Entwicklung

Das Besondere an unserer Entwicklung war die Verwendung einer Redux-Architektur, die wir normalerweise für unsere Web-Apps im Frontend nutzen. Für das Spiel wollten wir sie erstmals in einem verteilten Szenario einsetzen. Der Server sollte dabei als „Single Source of Truth“ gelten und den Zustand des Spiels verwalten. Die Spiel-Clients hatten so nur noch die Aufgabe, den aktuellen Zustand darzustellen und Aktionen der Spieler an den Server zu senden.

Die Entwicklung der Serverkomponente mit dem noch ganz neuen .NET Core 1.0 habe ich mir als Aufgabe ausgesucht. Mir war dabei wichtig, möglichst viel vom neuen .NET zu lernen, weswegen ich auf eine fertige Server-Bibliothek verzichtet habe. Für die Darstellung des Spiels hat Basti einen Client auf JavaScript-Basis mit Phaser.io umgesetzt. Phaser bietet viele Features, um ein 2D-Spiel umzusetzen, und stand schon länger auf Bastis „will-ich-mal-was-mit-machen"-Liste.

Neben der Programmierung ist gerade bei einem Spiel das Design besonders wichtig. Hier haben wir uns anfangs von Googles Material Design Guidelines inspirieren lassen, aber Ben hat da schnell was ganz Eigenes draus gemacht.

Fazit

Etwas so richtig Spielbares war in der kurzen Zeit nicht zu schaffen. Vor allem, weil wir neue Technologien getestet haben. Der Versuch, die Redux-Architektur auf ein Multiplayer-Spiel anzuwenden, hat mich aber voll überzeugt. Der größte Vorteil an einer solchen Architektur ist, dass man kaum noch verteilte Logik benötigt. Alle anfallenden Events werden zentral auf dem Server abgearbeitet und der neue, als Ergebnis entstandene, Spielzustand wird wieder über das Netzwerk an alle verbundenen Spieler geschickt. Das macht auch die Entwicklung des Clients entsprechend einfach, da dieser für nicht viel mehr als das Rendering zuständig ist.

Der Einsatz von .NET Core war zu diesem frühen Zeitpunkt so kurz nach dem Release eher eine Bremse. Der Kern ist zwar fertig, und damit kann auch schon sehr gut entwickelt werden, aber die vielen Bibliotheken, die man sonst gewohnt ist zu nutzen, fehlen zum großen Teil noch. Mit dem produktiven Einsatz von .NET Core sollte also noch ein bisschen gewartet werden. Ich vermute, dass es im Laufe des nächsten Jahres soweit sein wird, dass es sich lohnt umzusteigen.

‍

Project-Creator für neue Softwareprojekte bei Cap3

Ein neues Softwareprojekt aufzusetzen dauert gerne seine Zeit. Bei Cap3 nutzen wir separate Tools für Projektmanagement, Zeiterfassung, Versionsverwaltung des Quellcodes und das automatisierte Bauen der Software. Es können schon ein paar Stunden vergehen, bis alles eingerichtet ist.

Bei den allermeisten Projekten wird außerdem noch eine Testumgebung sowohl für die Entwickler als auch für den Kunden benötigt. Dazu müssen zusätzlich Datenbanken und Webserver entsprechend eingerichtet und dokumentiert werden, was schnell einen Tag oder mehr kosten kann.

Die Projektidee

Weil wir hier Potenzial sehen, unsere Prozesse effizienter zu gestalten, aber auch unter dem Aspekt des Wissenstransfers bei Cap3 (mit welchen Systemen, Frameworks und Libaries arbeiten wir?) waren Marc, Bettual, Jan und ich sofort sehr angetan von Pauls Idee für das CodeCamp, den initialen Projektsetup für eine neue Softwareentwicklung zu automatisieren. Das erwünschte Ergebnis sollte sein, dass mithilfe einer simplen Eingabemaske für den Projektnamen und den Projekttyp eine automatische Einrichtung der gesamten Infrastruktur stattfindet, so dass ein Entwickler direkt mit seiner eigentlichen Arbeit beginnen kann.

Neben der Einrichtung der Dienste soll auch ein zentraler Ort für Dokumentation geschaffen werden, wo Links zu den entsprechenden Diensten wie Projektmanagement, Zeiterfassung etc. aufgelistet werden, aber auch z. B. Login-Daten für die verwendeten Datenbanken stehen. Manch einer träumt sogar schon von einem Dashboard, welches uns direkt die Informationen der Dienste darstellen kann, wobei man z. B. an Work-Items, git commits, build results und Serverstatus denken kann.

Technische Details und Hintergründe

Erklärtes Ziel fürs CodeCamp 2016 war für uns also eine Webseite zu entwickeln, über die die Einstellungen vorgenommen werden können. Im Hintergrund verwendet das Tool dann die vorhandenen APIs der Anwendungen, mit denen wir bei Cap3 arbeiten. Um die Komplexität des Vorhabens, in Anbetracht der kurzen Zeit, in einem machbarem Rahmen zu halten, konzentrierten wir uns zunächst auf das Anlegen eines Webprojekts mit Scala und die folgenden Dienste:

• GitLab für den Source Code
• TeamCity als Build Server (für Continous Integration)
• YouTrack als unser Issue Tracking / Projektmanagement-System

Die Entwicklung des Frontends selbst haben wir ebenfalls mit Scala umgesetzt. Bettual und Marc bekamen die Möglichkeit, die für sie neue Technologie unterstützt durch Paul und mich auszuprobieren. Jan, Cap3-Praktikant, kümmerte sich um die Weboberfläche.

Eine der inhaltlichen Herausforderungen war es, aus den zu Beginn nahezu unendlich vielen Ideen ein erreichbares Ziel abzustecken. Deshalb haben wir uns am Freitag erst einmal zusammengesetzt und alle Ideen gesammelt und nach Machbarkeit und unmittelbarem Nutzen priorisiert. Auch wenn diese Aufgabe nach trockener Arbeit klingt, hat es uns geholfen, den Fokus auf das Wesentliche nicht zu verlieren.

Technisch interessant war für uns die Notwendigkeit, die verschiedenen APIs asynchron anzusprechen und dem Nutzer kontinuierlich Feedback über den Status zu geben. Während das Einrichten der Projektverwaltung relativ zügig geschieht, dauert es bei der Quellcode-Verwaltung schon mal etwas länger, da wir hier einen Checkout vornehmen, um bereits initiale Dateien (.gitignore, Readme) hinzuzufügen. Mithilfe des Akka-Frameworks konnten wir API-spezifische Aktoren schreiben, welche die Arbeitsschritte im Hintergrund ausführen. Im Frontend halten wir den Benutzer mithilfe einer dynamischen Ajax-Ansicht auf dem Laufenden.

Was wir erreicht haben

Wer in unserer Source-Code-Verwaltung, Continuous Integration Software, oder im Projektmanager einmal in Pauls Projektliste schaut, wird unschwer erkennen: Es funktioniert! Projekte wie "Testpaul1" bis" Testpaul23" bezeugen, dass wir die APIs von Gitlab, TeamCity und YouTrack inzwischen im Griff haben. Der Grundstein für die Weiterentwicklung ist also gelegt. In Zukunft wollen wir noch weitere Funktionen ergänzen und den Project Creator als Standard für neue Softwareprojekte bei Cap3 etablieren.

‍