Surround Studio Metaphor

Multimedia durchdringt unseren Alltag. Wir teilen unsere schönsten Momente. Seien es Fotos oder Filmchen. Wir „streamen“ ständig Musik von Spotify und Filme von Netflix, Amazon Prime sowie den Mediatheken. Messaging -Send- ist allgegenwärtig.

 

Aber wir können dank Software nun  selbst zum Musik & Film Produzenten in einem virtuelles Studio im Wohnzimmer werden. Die „User Experience“ bei diesen Tools ist einfach super. Insbesondere Cubase zeigt eine unerreichte Oberfläche ohne jegliches Hängen und Knistern. Es legt die Meßlatte für „Gute Software“ sehr hoch. Das Aufnehmen von Musik und Video oder Sreencasts -Save- ist spielend einfach ebenso wie das vorführen -Show-.

 

Das Surround Studio will ein ähnliches Bedienkonzept für das „Mischen von Systemen“ umsetzen. Je Service wird es einen eigenen Track geben. Bei der Umsetzung des Surround Studio Story Boards werden uns immer wieder auch Begriffe begegnen, die von der Musik Produktion oder auch der Film-Vorführung stammen.

Surround Architektur

 

Seit vielen Jahren verfolge ich schon den Ansatz eines Dynamic OOAD. Das Grundprinzip ist eigentlich recht einfach. Eine Domain Modellierung muß man auf jeden Fall entwickeln, es geht nicht ohne diese Basis. Wenn man nun allerdings weiter in Richtung UI, Datenbanken und Messaging denkt, gibt es oft einen Haufen boiler plate code der das ganze aufbläht und unnötig kompliziert macht.
 
Mittlerweile hat man herausgefunden, daß die Anzahl Fehler pro Codezeilen konstant ist: er liegt zwischen 15 bis 50 Bugs pro 1000 loc. Daher die einfache Rechnung: mehr Codzeilen auch mehr Fehler. Und die sind noch teurer als das unötighe Beiwerk. Es ist Minimal Coding angesagt.

 

Wenn man nun die Domain Klassen um View Constraints erweitert, erhält man ein ViewModel = Model & View. Naheliegend ist dann eine „Model View Presenter“ Architektur. Man kann – ausgehend auf Standard-Presenter – dann alle Modelle out of the box in einer Dynamic UI darstellen. Für spezielle Datentypen möge es auch einen speziellen registrierten Presenter geben, bei den meisten reichen die Basis Presenter aus. Wenn man dann pro unterstützte Platform (wie HTML5, Eclipse RCP, Java FX ….) die Presenter bereitstellt und damit auch das Typsystem. So kann man beliebig den „Kanal“ wechseln.

 

Das besondere an dieser Architektur ist, daß sich die konkreten Technologien so leicht austauschen lassen. Dies ist der Traum eines jeden Architekten, denn damit fallen Entscheidungen über die eingesetzten Technologien leichter da auch  das Risiko geringer wird. Für jede verwendete Techologie gibt es einen schlanken „Surround Adapter“, der mit so wenig wie möglichen Glue Code implementiert wird.

 

Allerdings heißt das auch, dass der „Business Code“ ausschließlich die Surround Adapter benutzen muss – kein direkter Zugriff ist erlaubt. Nur so kann man die Austauschbarkeit gewährleisten.

 

Meine derzeitigen Technologieen sind:

 

  • Das Domain Modeling werde ich in Java und TypeScript implementieren.
  • Als Dynamic UI werde ich Eclipse RCP und React benutzen.
  • Elasticsearch und OrientDB sind die ausgewählten Datastores.
  • Als Middleware wird akka und vertx eingesetzt.

 

Die Kommunikation wird auch darüber erfolgen – verpackt durch Surround Messaging. Dabei wird Messaging auch in der UI eingeführt. Somit wird das ganze System dann reaktiv mehr info unter:
Instanttouch Stay Reactive.

 

Surround Technologies

Das Surround Studio basiert auf dem  Dynamic OO Ansatz
Somit werden aus allen Bereichen der Software Entwicklung Technologien “angedockt”, ob nun Datenbank, Backend und Middleware oder auch Fronend /UI.
  • Alle Surround Module werden als OSGI Bundles (eclipse plugins) umgesetzt und daher wird auch die Eclipse IDE benutzt.
  • Beim Build ist es daher nahe liegend auf maven / tycho zu setzen um plugins, features and update sites zu bauen und deployen
  • Als Datastore werden zumindest elasticsearch als auch orientDB angebunden. Damit hat man einen schönen Mix von Documentstore für hierarchische Json Dokumente verlinkt durch eine (multimodale) Graphendatenbank
  •  akka and play scheinen ideal als Messaging und reaktives Webframework das leichtgewichtige vertx soll jedoch auch nicht fehlen.
  • Die Entwicklung der Dynamischen UIs wird neben Rich Client Technologien wie Eclipse RCP und javafx, auch moderne Javascript Webframeworks wie angular2 / Typescript und React streifen
  • Apache Karaf ist ideal für das dynamische Starten und Stoppen von  Bundles und daher der “OSGI Microservice Container”
  • Fitnesse ist ein hilfreiches Werkzeug zur Erstellung von webbasierten Akzeptanz Tests,
  • Als Continuous Integration bietet sich Jenkins an, eventuell wird jedoch auch eine Bamboo Pipeline von bitbucket.org benutzt
  • Sourcecode: https://bitbucket.org/virtualsurround/surround/src/master/

Definition of Done

Über die Jahre habe ich immer wieder die Gelegenheit gehabt agile Vorgehensweisen auszuprobieren und die passenden Best Practices für den eigenen Process Baukasten zu übernehmen.

 

Eine der Schlüsselerlebnisse war die Definition of Done. Wenn man sich darauf einigt welche Anforderungen erfüllt sein müssen, damit eine Story fertig ist, dann wird man nicht leichtfertig sagen: es funktioniert oder geht schon, muss nur noch testen oder besser noch es kompiliert schon ;.)

 

Das hängt aber auch vom Produkt ab. Das Surround Studio ist ein Framework Projekt und muss daher härtere Anforderungen erfüllen. Neben guter Qualität muss auch gerade die Verständlichkeit erfüllt sein, da sich andere Entwickler darauf einlassen müssen und letztlich auch davon abhängen. Dafür braucht man einen guten Support und möglichst schnelle Umsetzung von dringenden Features und Bugfixes

 

So ergeben sich die folgenden Kriterien:

 

  • Die Story muss erwartungsgemäß umgesetzt sein und eine gute User Experience gewährleisten
  • Über einen automatisierten System Test ist die Funktionsweise belegt und als Beispiel verwendbar
  • eine Wiki Page erklärt die Zusammenhänge in einer einfachen und möglichst kurzen Beschreibung.
  • Für Details liefert ein Webinar eine gute Grundlage zur Benutzung ohne den “Kunden” zu langweilen

Team Cocktail – Die Band

Play in a Band – Die kollektive Improvisation


 

Wenn man das passende Team für die Entwicklung des Surround Studios sucht, drängt sich recht schnell der Vergleich mit einer Band auf. Dabei rechtfertigen die Anforderungen nicht eine Umsetzung im Orchester mit den dort drigend nötigen Dirigenten der den gesamten Ablauf vorgibt. Nein eine Rythmusgruppe aus Bass, Drums und Piano kann alleine drauf los spielen. Eventuell können dann noch weitere “Solo -Instrumente” dazukommen. Aber auch ein Klaviertrio kann schon schöne Musik “entwickeln”.

 

Die Musikrichtung Jazz passt dabei gut im Vergleich zur Software Entwicklung. Denn die Problemlöser Software Entwickler suchen auch ständig nach neuem Wegen um möglichst schönen “clean code” zu erreichen. Und der knappe Projektrahmen erfordert nur zu oft ein gutes Improvisations-Talent. Ähnlich wie ein Musiker sollte ein Entwickler an seiner Technik üben, indem er immer wieder seine “Coding Katas” trainiert.

 

Die Rollen

Der Bassist setzt das Fundament um, auf dem die anderen aufbauen können – seine Entwicklerrolle ist der Datenbank Spezialist.

 

Der Drummer sorgt für den Rythmus und gibt so den Takt für die “musikalische Kommunikation” an – seine Entwicklerrolle ist der Backend/Middleware Entwickler.

 

Der Pianist erschafft mit seinen Harmonien die “Farben” im Zusammenspiel – seine Entwicklerrolle ist der Frontend/UI Entwickler.

 

Nun mag der eine oder andere denken, dass der Saxophon Solist der “Star” im Team ist. Aber weit gefehlt – es findet eine kollektive Improvisation statt und die Rythmusgruppe unterstützt den Solisten, so dass gemeinsam etwas besonderes gelingt.
Solch ein “Cross Functional Team” hat alles was man zur Erstellung des kompletten Produktes braucht und ist daher ideal für die Entwicklung von Micro Services und Self Contained Systems.

 

Mittlerweile gibt es Dank Steinberg Cubase auch die Möglichkeit ein virtuelles Studio umzusetzen indem Musilker übers Internet verbunden ihre Parts einspielen. Auch Home Recording  (Home Office) ist bezahlbar und man kann mit Band in a Box  einen beliebigen Standard – in hunderten von Styles – generieren lassen. Ähnlich ist es auch in der Software Entwicklung. Über Skype oder Teamviewer kann man rund um die Welt die entfernten Kollegen erreichen.

 

Eine besondere Aufstellung ist hier das “Virtuelle Team”: Es ist nicht nur eine verteiltes Team, man trifft sich auch an besonderen Orten – im Kaffee oder zum Mittagessen oder auch zu einer After-Work-Party. Oft hilft ein Gespräch über das “Drum herum” – den Surround – einen neuen leicht umzusetzenden Werg einzuschlagen.

 

Auch das virtual surround team auf bitbucket.org agiert in dieser Weise – mittels Miniimal Coding – um mit minimalem Aufwand eine gemeinsame schöne Lösung zu enwickeln.

 

Surround Setup

 

wir haben nun erfolgreich unseren Sprint-0 hinter uns gelassen. Den weiteren Fortschritt werden wir als Stop Motion Scrum vorführen

Setup

1) download latest eclipse edition: [Eclipse Download](https://www.eclipse.org/downloads/)
In eclipse installer choose Eclipse DSL Tools. During installation follow all defaults (if it runs slowly choose another mirror during download)

2) install efxclipse 3.4.1 (was release on 12 2018) from eclipse marketplace (Help/Eclipse Marketplace search for efxclipse) and restart

tip: in ProblemView at the button choose special menu (on the right side) and Show Error/Warnings on Selection

3) from welcome page choose „Checkouts Projects from Git“->
clone Uri-> input https://instanttouch@bitbucket.org/virtualsurround/surround.git

4) start maven/tyco build for de.instanttouch.surround.releng/pom.xml DebugAs->install

5) refresh all projects -> finished with no more errors

6) configure preferences java installed JREs by adding a jdk as default

7) create a new Debug configuration (Run->Debug Configurations …). Choose a new Eclipse Application context menu new Configuration
use Surround as name. choose:

goto the Plugins-Tab:

choose plugins selected below only -> choose all workspace plugins -> Add Required Plug-ins:

start Application (should open without errors)

Stop Motion Scrum


 

Mein kleiner Sohn Fabian liebt es Trickfilme zu erstellen. Mit seinen Playmobil Männchen und Autos baut er einen Stop Motion Film aus ein paar hundert Fotos auf, wobei er von Bild zu Bild nur ein wenig die Autos verschiebt. Das Ganze fügt er dann in unser Filmora Videoschnitt Programm ein und hat so einen kleines hübschen Filmchen …

 

Anwendung im Scrum

 

Die Dokumentation ist insbesondere für ein Framework-Projekt – wie dem Surround Studio – immens wichtig. Wenn man jedoch zuviel auf einmal erzählt wird das recht schwierig mit der Nachvollziehbarkeit.  Ein 2 Wochen Sprint – 6 Mann Wochen Implementierung – erzeugt soviel Neues, daß nur noch die hauptsächlichen Ergebnisse präsentiert werden können. Ein Blick ins Detail fehlt. So reicht es nicht, nur das Review und die Retrospektive am Ende des Sprints zu verwenden.

 

Deshalb präsentieren wir im Surround Studio minimale Inkremente in einer Art Stop Motion Scrum. Jede kleine Momentaufnahme – getreu nach dem Motto Minimal Coding – wird in einem Webinar und Wiki “aufgezeichnet”. Über die Timeline kann man dabei beliebig zwischen den “Einzelbildern” scrollen, in einer Art Daumen Kino.

 

Aus meiner Erfahrung als Framework Entwickler schätze ich den Aufwand für die Umsetzung des kompletten Surround Studio auf 100000 Lines of Code.

 

Wenn man dabei in einer Momentaufnahme maximal 500 Zeilen geänderten Sourcecode vorführt, ergeben sich rund 200 Einzelbilder, bei zwei Szenen pro Woche also rund 2 Jahre Gesamtlaufzeit. Das deckt sich auch gut mit der gesamten nötigen Realisierungszeit.

 

Am Ende erhält man einen lückenlosen Film über das Surround Studio und man kann diesen beliebig im Zeitraffer oder der Zeitlupe abspielen. Bei ca. 8 Minuten pro “Take” erhält man am Ende ein 24h Epos.

 

Die Dramaturgie sollte dabei eine gewisse Anspannung und Entspannung vorweisen, bei der Erreichung von Etappenzielen als Zwischenprodukt. Auf diese Art und Weise wird es mit dem Surround Studio nie langweilig.
Also auf zum nächsten Tatort Modellierung.

Klappe 1 Szene 1 die Erste


 

Versionierung wird oftmals unterschätzt und stiefmütterlich behandelt. Im allgemeinen findet das Muster: Major-Minor-Patch Anwendung, wobei kleine Änderungen den Patchlevel hochzählen, bei mittleren kompatiblen Änderungen eine neue Minor erstellt wird und nur bei besonderen Auslieferungen oder inkompatiblen Änderungen die Major Number anzupassen ist.

 

Oftmals wird dies allerdings für unterschiedliche Projekten anders gehandhabt und bei einem Geflecht von Modulen entsteht dann die bekannte “Dependency Hell”.

 

Als ich bei der Firma IDS war, wurde dies anders gehandhabt. Alle Module hatten die eine gemeinsame Version und so wusste man stets was zusammen gehört. Dies ist besonders praktisch, wenn viele Kunden während der Wartung auch den gleichen Sofwarestand bekommen.

 

In Surround wollen wir einen ähnlichen Weg einschlagen. Da es nur eine handvoll Module (OSGI Bundles) geben wird, fällt es auch leicht für alle diese eine gemeinsame Versionsnummer zu wählen.

 

Abweichend vom obigen Schema gilt allerdings folgende Nummerierung
In der Backlog Story Map werden die einzelnen “Backlog Module” durchnummeriert:
Klappe 1, Szene 1 die Erste Aufnahme
  1. in der Backlog Storymap werden die einzelnen Kategorien nach der Priorität durchnummeriert, z.B. Klappe 1 für Modelling
  2. Die Story, welche bearbeitet wird, ergibt die Nummer für die Szene.
  3. Die Aufnahme spiegelt einen schrittweise erfassten Moment in der Versionsverwaltung da.

 

Da die Stories fest nach Plan umgesetzt werden, ergibt sich dann ein Film von der Anfängen bis hin zur ersten Vorführung des Surround Studios.

 

Einzelne Produkte können mehrere Szenen umfassen. Falls Änderungen am Backlog erfolgen müssen, sollten diese sinnvoll in die Story Map eingebracht werden. Wobei neue Backlogmodule allerdings nicht einfach dazwischen gefummelt werden können. Aber das Drehbuch zu unserem Film wird sich während der Abarbeitung sicher noch ändern, so daß neue Szenen entstehen können. Allerdings werden wir das bisher gedrehte nicht raus schneiden. Alles was wir im Kasten haben kann auch verwendet werden.

 

So und nun zur Ersten Aufnahme:
1 – Modelling
1 – as developer I want to design my domain classes using a rich type system with the most common types
1 – place a base (class)

All of Me – Place A Base

Intro

Nun geLearn Jazz Standardsht es endlich los mit dem Software entwickeln. Ich habe mir mal von ein paar Kollegen sagen lassen,
dass sich mit Musik viel besser coden lässt. So wollen wir das nun fortan halten. Ein Standard pro Aufnahme.

 
All Of Me von von Gerald Marks and Seymour Simon , 1931
 

 

Die Quintessenz

 
Von 1999 bis Ende 2000 hab ich mit meinem Freund Michael Rist die beste Zeit als Software Entwickler (bei der nettesten Firma: LS telcom AG) erlebt. Wir hatten “freie Fahrt” für die Erstellung eines Internet-Marktplatzes für Funknetz Standorte nach dem damals noch frühen J2EE Standard (mittlerweile in Java EE gereift). Und der Orion Server war einfach unglaublich.

Dem Vertrieb fiel ein super Slogan ein: Place a Base. Platziere zum Schließen von “Funklöchern” eine Basis Station auf dem Dach eines Hausbesitzers.
 
Diese Erinnerung möchte ich gerne umdeuten: “Wie führe ich eine Basisklasse ein” aufwärmen.

 

Dabei gibt es allerdings einen “Knackpunkt”:

Die Basisklasse enthält einen Namen und eine Referenz auf eine map of constraints  (diese ist so schlank wie möglich und belegt daher im “Normalfall” keinen zusätzlichen Speicher).
 
Der enthaltene Name stößt aufgrund des “Overheads” sofort auf Ablehnung. Allerdings ist dies wohl in den meisten Fällen eher unkritisch, denn man sendet sowieso nur die Daten, die zur Presentation in der Dynmaischen UI gebraucht werden. Für Massen Daten werden wir noch die leichtgewichtigen Value Types kennen lernen.
 
Über die Jahre – unter Benutzung von verschiedenen NoSQL Datastores – bin ich zur Überzeugung gekommen, dass man eigentlich mehr mit kleinen Model-/Dokument Schnipseln hantieren sollte, zusammen gewoben über einen Graph Datastore. Dies ist flexibel und unterstützt eine mächtige und performante Suche nach kleinen Model Graph Ausschnitten. Polyglotte Persistenz ist angesagt.
 
Als weitere Einschränkung gibt es keine einfachen Getter und Setter mehr und so muss man doch ein bisschen mehr boilerplate code schreiben. Dies lässt sich später durch eine DSL oder einen speziellen Generator (am besten direkt in der Eclipse IDE) leicht verbessern. Ein schönes Feature, jedoch mit geringerer Priorität.
 

Features

 
Schon in der Basis enthalten sind:

  • Naming
  • Constraints für die Validierung und zur Steuerung der dynamischen Anzeige
  • Type Konvertierung
  • Null Support
  • Liste der children
  • Find-Methoden
  • Basic Exceptions

Modeling Basic Types – Beautiful Love

Beautiful Love, Victor Young, Wayne King and Egbert Van Alstyne in 1931

Heute wollen wir nun unsere gemeinsame Sprache entwickeln – das Objektmodell der jeweiligen Domäne. Ähnlich wie ein Leedsheets der Jazzband als Grundlage dient und dabei die Akkordfolge jedem Musiker vor seinem geistigen Auge abläuft, bilden die Objekte den Wortschatz eines jeden Entwicklers.

Jede Domäne hat dabei ihre eigenen spezifischen Typen. Der Surround Modell Baukasten unterstützt dabei mit seinen vielen Basistypen eine komplexere „Sprache“ abzubilden. Später einmal wird eine DSL diesen Schritt noch vereinfachen.

Die eigentliche Aufgabe von Surround ist es jedoch eben die fachliche Domäne gut abzubilden und damit dann in allen möglichen Anwendungsgebieten einen Support out of the box zu gewährleisten.

Die Anwendung von Surround ist kein „General Purpose“ wie sonst in allen Frameworks angeboten um möglichst flexibel zu sein. Nein man reduziert das spezielle „Inhouse Framework“ auf den kleinsten gemeinsamen Nenner.

Und der applikative Code beruht nur darauf. Es soll keine direkten Aufrufe von einer im Surround bereitgestellten Techologie geben. Nur so kann man garantieren, dass später nur eine neuer Adapter zu einer neuen Technologie entwickelt werden muss und nicht der ganze Monolith.

Surround Modeling Composition – Fly Me to the Moon

 

Beautiful Love, Victor Young, Wayne King and Egbert Van Alstyne in 1931

Was wäre die Musik ohne Komposition? Eine recht holprige Folge von einfachen Liedchen?

Auch in der Software Entwicklung wird ständig komponiert – kleine Bausteine werden genutzt um die Entitäten aufzubauen. Aber auch Komponenten 😉 , Module, Subsystem und ganze System Landschaften.

Oft ist jedoch ein System über die Jahre gewuchert und die eigentlichen Funktionalitäten sind sehr verwässert. Es erscheint als nahezu unmöglich einen Teil herauszuschälen und dann losgelöst wieder zu verwenden. Aber auch dafür hat die Software Entwicklung ein Mittel: Die Dekomposition. Man zerlegt das System nach und nach in handliche Module – am besten mit analoger Modellierung auf Kartei Kärtchen. Und wenn es auch nur darum geht die Business Logik genau zu verstehen. Denn wenn man genau weiß was man will und braucht lässt sich dies recht schnell neu entwickeln, am besten mit den Leuten, die den Monolith „verbrochen“ haben

Modeling JSON IO – Watermelon Man

 

Watermelon Man, Herbie Hancock, originally for his 1962 (1973 headhunters)

Input/Output

Wenn man an ein Musikstudio denkt, so hat man es direkt vor Augen: das Mischpult. Hier werden viele Audio Kanäle auf einen Ausgangsbus zusammen geregelt.

Im Musikstudio gibt es allerdings auch die Midi Kanäle. Schon in früheren Zeiten hatte man ein Materkeyboard, das Midi-Kanäle an einen Klangerzeuger schickt. Heutzutage gibt es unzählige Softwareinstrumente die mit dieser Technik zu überzeugen wissen. Diese werden ebenfalls direkt zum Ausgang geleitet. Wobei minimale Latenz einen nicht am Musizieren hindert.

In der Software Entwicklung gibt in der Analogie Messaging Kanäle. Mit unzähligen Protokollen unterhalten sich die Komponenten, Client, Services, Aktoren. Allerdings scheint sich ein Nachrichten Format drchzusetzen:

JSON

Es gibt für jede beliebige Sprache einen Parser und so können alle mit reden. Nicht nur für Messaging auch für NoSQL Stores oder Javascript WebUIs.

Damit ergeben sich  viele Möglichkeiten. Wenn man nun sein Domain Modell mit wohlbekannten Basistypen umsetzt, so bekommt man die Surround Studio IO geschenkt:

das Modell läßt sich speichern, in den „Daten Ausgangs Bus strömen“, präsentieren in einer Dynamischen UI und verschicken zu allen Kommunikations Partnern.

Man muss nur für die jeweilige Target Technologie einen „Nachrichten Kanal“ implementieren. Und wenn das Surround Studio nun diese Kanäle verwaltet, so wird es auch einfach einen Kanal um zu lenken. Sei es zu Test Zwecken oder auch nur zum Monitoring, etc.