Empfangsbekenntnis 3.0 (STP LabsDay 2019)

Am vergangenen Donnerstag und Freitag (14.-15. November 2019) habe ich wieder am STP LabsDay teilgenommen. Diesen internen 24h-Hackathon veranstaltet STP jedes Jahr. Die Idee des LabsDays ist es, in kleinen Gruppen an einer eigenen Idee zu arbeiten. Wer kennt es nicht? Man wollte schon immer einmal Framework X oder Bibliothek Y ausprobieren, aber irgendwie ist man nie dazu gekommen. Genau dafür ist der LabsDay der perfekte Rahmen. Außerdem übernimmt STP an diesen beiden Tagen komplett die Verpflegung.

Insgesamt haben sechs Teams teilgenommen. Mein Kollege und ich bildeten eines dieser Teams. Während die anderen Teams sich primär mit künstlichen Intelligenzen beschäftigten, haben mein Kollege und ich uns einem Thema gewidmet, über das ich schon länger nachgedacht hatte: das Empfangsbekenntnis. Nach der §174 Zivilprozessordnung sind Anwälte, Gerichte und alle Personen und Institutionen, deren Arbeit besonders zuverlässig sein muss, dazu verpflichtet, den Erhalt von entsprechenden Dokumenten zu bestätigen. Auf die klassische Art und Weise passiert das mit der Post. Das Empfangsbekenntnis 1.0 ist ein spezielles Dokument, welches vom Anwalt unterzeichnet und dann an den Sender des ursprünglichen Dokuments zurückgeschickt werden muss. Der Hauptnachteil dieser Lösung liegt auf der Hand. Die Anwälte und Gerichte versinken in einer immer größer werdenden Papierflut. Deswegen wurde vor einigen Jahren das Empfangsbekenntnis 2.0 eingeführt. Mit beA- und EGVP-Postfächern wird eine digitale Empfangsbekenntnis automatisiert erstellt und verschickt, sobald der Anwalt das Dokument in seinem Software Client erhalten hat. Wenn ein digitales Empfangsbekenntnis auf einem zentralen Server oder einem Client gespeichert ist, besteht die große Gefahr eines Datenverlusts. Im Falle eines Brandes im Datenzentrum oder einer Sicherheitspanne bei den Betreibern sind die Daten gefährdet.

Wir wollten diese Situation verbessern. Meine Mission bei STP ist es, unseren Partnern, Kunden und Kollegen die Vorteile der modernen Technologien zu ermöglichen. Moderne Technologien sind zum Beispiel Cloud, Mobile, Artificial Intelligence und die Blockchain. Beim STP LabsDay haben wir deswegen das Empfangsbekenntnis 3.0 als Decentralized Application (DAPP) in Form eines Smart Contracts auf der Ethereum Blockchain realisiert. Mein Kollege hatte zu dem Thema Blockchain bereits seine Bachelor Thesis geschrieben und auch mir waren einige theoretische Konzepte bereits bekannt. Erwähnenswerte praktische Erfahrung hatte ich aber bisher noch keine. Also haben wir uns ein Tutorial gesucht und uns diesem Projekt spielerisch genährt. Schließlich wollten wir am Ende des Hackathons eine funktionsfähige Lösung präsentieren.

Der Prozess ist eigentlich ziemlich einfach. Ein Sender registriert sein Dokument und gibt es danach an den Empfänger weiter, welcher den Erhalt bestätigt. Diesen Prozess konnten wir problemlos in Form einer Abstract State Maschine in Solidity, der Programmiersprache der Ethereum Virtual Machine (EVM), implementieren. Dabei wollten wir nicht nur digitale Dokumente in unserer Lösung verwalten, sondern auch physikalische. Wir brauchten also eine Abstraktion von physikalischen und digitalen Dokumenten, um für diese Abstraktion ein Empfangsbekenntnis zu speichern. Unsere Abstraktion nennen wir Document Link. Wenn das Dokument bereits ein digitaler Datensatz ist, können wir den Document Link ganz einfach als Hash des digitalen Datensatzes erzeugen. Ist das Dokument allerdings ein physikalisches Dokument, können wir eine Zufallszahl generieren und diese in Form eines QR-Codes auf den Brief drucken. Natürlich können wir auch eine URL als Document Link verwenden. Damit haben wir die Möglichkeit geschaffen, um in einer vereinheitlichten Form sowohl digitale als auch physikalische Dokumente zu verwalten.

Ein Sender ermittelt den Document Link aus seinem Dokument und persistiert diesen in der Blockchain. Ein Empfänger des Dokuments kann dann den Document Link mit dem Empfangsbekenntnis ebenfalls in der Blockchain persistieren. Um sicherzustellen, dass nur die Person, die das Dokument tatsächlich erhalten hat und jetzt besitzt, das Empfangsbekenntnis ausstellen kann, nutzen wir eine Hashfunktion. Der Sender ermittelt den Hash des Document Links und persistiert diesen auf der Blockchain. Der Empfänger muss jetzt genau den Document Link auf der Blockchain speichern, der zu dem vom Sender persistierten Hash passt. Versucht er einen Document Link zu persistieren, dessen Hash nicht bereits vorher registriert wurde, wird die Transaktion abgelehnt.

Wenn das Dokument von einer zweiten Person gelesen wird, wird auch eine zweite Empfangsbekenntnis in der Blockchain gespeichert. Wenn ein Empfänger das gleiche Dokument, also mit dem selben Document Link, an eine weitere Person sendet, tritt der Empfänger jetzt als Sender auf und persistiert den Hash des Document Links. In diesem Fall wurde das gleiche Dokument von zwei unterschiedlichen Sendern registriert. Das ist auch für alle Beobachter erkennbar. Wenn jetzt eine dritte Person dieses Dokument empfängt, werden zwei Empfangsbekenntnisse ausgestellt, die jeweils einem Sender zugeordnet werden. Ein Sender kann also jederzeit feststellen, 1) wer sein Dokument wann empfangen hat und 2) wer es ebenfalls verschickt oder weitergeleitet hat.

Diese Prozesslogik lief nun in einem Smart Contract auf der Blockchain. Dazu haben wir noch ein Frontend mit React und Web3 gebaut und auf Azure gehostet. Unser Frontend listet alle getrackten Dokumente mit sämtlichen Empfangsbekenntnissen auf. Den Smart Contract selbst haben wir dann in das Ethereum Testnetzwerk Kovan deployt. Anschließend haben wir uns Szenarien für die Präsentation unserer Ergebnisse überlegt. Um die ganze Sache einfach demonstrieren zu können, hatten wir uns überlegt, dass wir auf ein Papier zwei QR-Codes drucken. Den einen QR-Code scannen wir um dieses Dokument zu registrieren und den anderen QR-Code scannen wir um das Dokument zu empfangen. Genauso haben wir es auch im Rahmen der Ergebnispräsentation demonstriert. Dazu öffneten wir die URLs hinter den QR-Codes jeweils mit MetaMask for iOS und konnten so die Transaktionen mit unseren Mobiltelefonen signieren. Natürlich würden Software Clients diesen Vorgang automatisiert im Namen des Anwalts durchführen.

Die Vorteile von Empfangsbekenntnis 3.0 verdanken wir der Blockchain. Das Empfangsbekenntnis ist unveränderlich, unabstreitbar und für alle sichtbar für immer persistiert. Dass wir uns bei unserem Prototypen für das öffentliche Ethereum Testnetz entschieden haben, hat die Konsequenz, dass Transaktionen nicht kostenlos sind. Wir müssen die Miner incentivieren, damit sie unsere Transaktionen in Blocks verpacken und der Blockchain hinzufügen. Dafür müssen wir bei jedem Schreibvorgang etwas Geld in der Ethereum-Kryptowährung namens Ether bezahlen (Gas). Wenn viele Transaktionen in die Blockchain gespeichert werden sollen, steigt außerdem die Latenz. Das bedeutet, dass wir ein paar Sekunden bis Minuten warten müssen, bis unsere Transaktion bestätigt und tatsächlich persistiert ist. Diese beiden Nachteile haben Consortium Blockchains nicht. Deswegen würden wir für einen real life Einsatz unserer Lösung eine Consortium Blockchain der Public Ethereum Blockchain vorziehen.
Ein weiterer Nachteil ist die komplizierte Weiterentwicklung von Smart Contracts. Genau wie Daten, ist auch der Code unveränderlich auf der Blockchain gespeichert. Das bedeutet, dass wir einen Fehler nicht einfach korrigieren können. Mit jeder Fehlerkorrektur müssen wir das Programm neu auf der Blockchain installieren und allen Verwendern mitteilen, dass sie jetzt diese neue Version verwenden sollen. Zusätzlich müssen natürlich die Daten aus der alten in die neue Version migriert werden. Idealerweise würde die alte Version abschließend auch deaktiviert werden, allerdings müssten wir den Smart Contract von Begin an dementsprechend fehlerfrei programmieren. Das macht das Weiterentwickeln von Smart Contracts umständlich. Im Rahmen des 24h-Projekts haben wir zwei Versionen deployen müssen.

Am Ende war unser Projekt ein ganzer Erfolg. Unser Smart Contract hat sehr gut funktioniert und unsere Präsentation hat einen guten Eindruck hinterlassen. Wir haben für unsere Arbeit den Vorstandspreis gewonnen. Der Kundenpreis und der Zuschauerpreis gingen an das Projekt unseres anderen geschätzten Kollegen, dessen Modell automatisiert Fristen in Dokumenten erkennen konnte.

Auch wenn nicht alle Teams einen Preis gewonnen haben, haben wir alle viel dazugelernt. Alle Projekte haben die Firma merklich motiviert und inspiriert. Wie jedes Jahr war der STP LabsDay ein echtes Highlight. Um 16 Uhr hatten wir uns das Wochenende dann auch redlich verdient. Ich freue mich jetzt schon auf den nächsten STP LabsDay. Ein großartiges Event!

 

Weiterentwicklung?

Unser Prototyp funktioniert. Doch bevor wir unseren Code produktiv einsetzen würden, müssten wir noch eine Sicherheitserweiterung einbauen. Damit die Miner unsere Daten in Form von Transaktionen in Blöcke verpacken können, müssen wir ihnen den Input für unsere Smart Contract Funktionen schicken. Aktuell muss ein Empfänger den Document Link im Klartext an den Miner schicken, damit der Smart Contract den Hash bilden und mit dem vom Sender gespeicherten Hash vergleichen und persistieren kann. Diesen Klartext des ersten Empfängers könnte eine andere Partei mitlesen und ebenfalls persistieren. Dadurch können nach einem ersten Empfangen weitere Parteien ein Empfangsbekenntnis für ein Dokument ausstellen, obwohl sie es gar nicht tatsächlich besitzen. Durch die Signatur der Transaktion ist jederzeit erkennbar, wer die Anfrage gestellt hat, sodass das System nicht gespooft werden kann. Dennoch schwächt dies die Sicherheit des Empfangsbekenntnis. Das Problem ist die Verwendung der Hashfunktion. Nachdem der entsprechende Klartext einmal bekannt ist, kann ihn jeder nutzen um den Hash zu berechnen. Um diesem Verhalten entgegen zu wirken, dürfte der Document Link niemals im Klartext an die Miner geschickt werden. Ihn einfach zu signieren oder mit der Adresse des Empfängers zu prefixen und anschließend zu hashen reicht leider nicht, da der Smart Contract den Klartext nicht kennt und die Signatur oder den Hash deswegen nicht validieren kann.

Die Idee ist, den Document Link wie einen Private Key zu verwenden. Mit diesem Private Key müsste ein Empfänger seine durch die Blockchain eindeutige Adresse signieren und diese anstelle des Klartexts an den Miner schicken. Nur die Parteien, die das Dokument tatsächlich besitzen und deswegen den Private Key kennen, können dies tun. Würde eine signierte Adresse von einer anderen Partei wiederverwendet werden, würde die Signatur nicht zur tatsächlichen Adresse des vermeintlichen Empfängers passen. In diesem Fall ist der Smart Contract nämlich in der Lage die Signatur mit dem vom Sender persistierten Public Key zum Private Key aka Document Link zu überprüfen.

Den Code unseres Prototypen finden Sie im Kovan Testnetz (0xf41930b233137f37b7cd770c3b36eaa51d38c8e2) oder auf Github.

STP LabsDay 2018

Innovation wird heutzutage sehr groß geschrieben und deswegen veranstaltet STP regelmäßg den STP LabsDay. Am vergangenen Donnerstag und Freitag (26. und 27. April 2018) habe ich wieder an diesem internen 24h-Hackathon teilgenommen. Während der Arbeitszeit haben wir an diesen zwei Tagen die Gelegenheit, eine neue Idee auszuprobieren. STP übernimmt an beiden Tagen komplett die Verpflegung und Marketing hat uns wieder mit einem stylischen Geschenk überrascht. Beste Voraussetzungen für zwei Tage Innovationsarbeit.

Aktuell beschäftigt mich das Thema “Intelligent Cloud & Intelligent Edge”, sodass ich in diesem Jahr unbedingt etwas mit Cloud und Web machen wollte. Aber nicht einfach nur das nächste Angular oder Aurelia Projekt. Ich wollte Bleeding Edge Web Technologien ausprobieren. Es musste also unbedingt eine Progressive Web App sein, am besten in Verbindung mit Push Notifications. Ein Use Case ist mir auch sofort eingefallen: Kundenbenachrichtigung, egal ob der Kunde ein Gläubiger oder ein anderer Mandant ist. Das Projekt Mandate Updates hatte begonnen. Glücklicherweise konnte ich einen meiner Kollegen für dieses Szenario und die erwähnten Technologien begeistern und somit einen Partner für mein LabsDay-Projekt gewinnen. Es gibt nämlich nur eine einzige LabsDay-Regel: man muss mindestens zu zweit sein.

Am Donnerstag um 11 Uhr ging es endlich los. Nachdem wir uns über den Umfang des Projekts im Klaren waren, haben wir uns aufgeteilt. Mein Kollege hat sich auf das mit Azure Active Directory gesicherte Backend in Form einer ASP.NET Core 2 Web API gestürtzt, während ich versuchte, den PushManager mit dem ServerWorker zu verbinden. Der Anfang fiel uns beiden leicht und wir kamen gut voran. Nachmittags konnte unsere PWA sich bereits auf Datenänderungen im Backend registrieren und wurde asychron benachrichtigt, wenn eine solche Datenänderung stattgefunden hatte. Die erste angezeigte Toast Push Notification war etwas ganz besonderes für mich. Wir brauchten nichts installieren und die Seite musste noch nicht einmal offen sein und wir wurden trotzdem asynchron informiert. Super. Jetzt hatten wir allerdings die ersten Schwierigkeiten. Solange die Seite offen ist, wollten wir keine Toast Notification sehen, sondern die Seite soll sich einfach aktualisieren. Ungefähr drei Stunden und 20 Zeilen ServiceWorker-JavaScript-Code später hatten wir das Problem gelöst. Danach wollten wir das bis jetzt noch unabhängige System in unser ERP-System LEXolution.KMS integrieren. Glücklicherweise hatte ich vor ein paar Monaten LEXolution.KMS bereits in die Cloud portiert und als KMSX mit Azure Active Directory Authentication gehostet. Mit Azure Active Directory konnten wir uns also an KMSX anmelden und ebenfalls ein JWT Access Token für unsere Mandate Updates API erhalten. Bis spät in die Nacht haben wir KMSX um die Mandate Updates Funktion erweitert. Sobald der Sachbearbeiter jetzt in LEXolution.KMS bei der Akte einen Text hinterlegt, wird dieser automatisch in alle Browser gepusht, die sich im Vorfeld für Benachrichtigungen bei dieser Akte registriert hatten. Dafür kann der Sachbearbeiter zu jeder Akte eine eindeutige URL ermitteln, die der Mandant im Browser besuchen und dort sämtliche Benachrichtigungen zu dieser Akte einsehen kann. Kommen neue Benachrichtigungen hinzu, wird die Seite automatisch aktualisiert oder es wird eine Toast Notification gezeigt. Nach einem Klick auf diese Notification kann der Mandant wieder direkt alle Akten-Benachrichtigungen sehen. Wir hatten es geschafft, unser Szenario war implementiert.

Am nächsten Morgen habe ich meinen Kollegen bereits in der Bahn getroffen. Dort konnten wir uns im Rahmen eines Daily Scrums direkt abstimmen, ohne wertvolle Präsentationsvorbereitungszeit zu verlieren. Wieder im Büro angekommen hatten wir noch vier Stunden Zeit, bis wir unser Projekt präsentieren würden. Zuallererst haben wir nochmal unsere Push Notifications getestet und zwar mit dem Handy meines Kollegen. Es funktionierte alles hervorragend. Obwohl alle Anwendungen auf seinem Smartphone geschlossen waren, wurde meine KMSX-Aktenänderung direkt in Form einer Push Notification auf seinem Handy anzeigt. Anschließend widmete sich mein Kollege der Integration von Mandate Updates in ein weiteres Software System der STP. Ich fing an die Präsentation vorzubereiten und die Demo zu planen. Plötzlich funktionierten meine Push Notifications nicht mehr. Sie wurden einfach nicht mehr angezeigt, sobald ich den Browser geschlossen hatte. Nach einiger Zeit habe ich dann bei einer Internet Recherche herausgefunden, dass Push Notifications nicht mehr dispatched werden können, wenn alle Browser-Fenster geschlossen sind. Wahrscheinlich hatte ich bei allen vorherigen Versuchen irgendwo noch ein Chrome-Fenster im Hintergrund offen, sodass die Notifications verarbeitet werden konnten. Dieser Unterschied zwischen Desktop und Mobile ist wirklich bemerkenswert. Irgendwie haben wir es dann noch geschafft unsere Präsentation vorzubereiten und auch noch etwas Essen zu gehen.

Anschließend haben alle Teams ihre Ergebnisse präsentiert. STP hatte zu dieser Präsentation wieder einen Kunden und alle Vorstände eingeladen. Während der Präsentation gingen unsere Push Notifications anfänglich wieder nicht, wurden dann aber mit etwas Verspätung doch noch angezeigt. Mandate Updates war ein voller Erfolg und wurde sogar mit dem Kundenpreis ausgezeichnet. Natürlich wird Mandate Updates mit asynchronen Push Notifications die Kommunikation mit Telefon und E-Mail nicht ablösen, aber es erweitert diese. Mit Mandate Updates bekommen Sie einen neuen Kanal zu Ihren Mandanten.

Mein Kollege und ich hatten viel Spaß bei der Umsetzung und wir haben beide eine Menge gelernt. Ich bin mir sicher, dass alle Teams eine Menge gelernt haben. Herzlichen Glückwunsch auch an 1nicerUploader und Time Rocket, die den “leider geil”- und den Vorstands-Preis gewonnen haben. Sieben Teams sind insgesamt gestartet und auch wenn nur drei Teams mit einem Preis ausgezeichnet werden konnten, alle STP-LabsDay-2018-Projekte haben die gesamte Firma deutlich motiviert und inspiriert. Ein großartiges Event!

STP LabsDay 2017

Am vergangenen Donnerstag und Freitag (6. und 7. April 2017) habe ich wieder am STP LabsDay teilgenommen. STP veranstaltet diesen firmeninternen 24h-Hackathon jährlich und es ist jedesmal eine perfekte Gelegenheit während der Arbeitszeit eine neue Idee auszuprobieren. Dieses Jahr hat unsere Marketing-Abteilung alle Teilnehmer mit einem schicken Polo-Shirt und einem coolen Bluetooth-Kopfhörer ausgestattet. Außerdem übernimmt STP die komplette Verpflegung an beiden Tagen. Beste Voraussetzungen für zwei Tage Innovationsarbeit.

Schon im Herbst letzten Jahres hatte ich RethinkDB auf meine ToDo-Liste gesetzt aber seit dem nicht die Zeit gefunden, mich mit dieser Datenbank zu beschäftigen. Das Interessante an RethinkDB ist, dass diese Datenbank nicht nach Änderungen gefragt werden muss, sondern diese direkt in die Clients pushen kann. Ein ziemlich coole Sache, die die Entwicklung von echtzeitfähigen Anwendungen unterstützt. Also habe ich mit einem Kollegen aus meinem Team am STP LabsDay teilgenommen. Im Rahmen unseres Projekts wollten wir Daten, die in LEXolution.KMS entstehen, also der Software, die wir täglich entwickeln, in Echtzeit im Browser anzeigen. “Echtzeit KMS-Logs im Browser” war unser Arbeitstitel.

Am Donnerstag um 11 Uhr ging es los. Nachdem wir uns über den Umfang des Projekts im Klaren waren, hat mein Teamkollege sich der Erweiterung von KMS angenommen, während ich mich in RethinkDB-Tutorials gestürzt habe. Dank Docker hatte ich ohne Aufwand eine RethinkDB-Testumgebung zur Verfügung. Da wir noch nicht wussten wie und welche Daten wir aus KMS in die RethinkDB schreiben müssen, hat mein Kollege KMS so erweitert, dass beliebige Datenquellen und Datensenken angebunden werde können, ohne dass KMS selbst angepasst werden muss. Dadurch hatten wir eine perfekte Entkopplung auf fachlicher, technischer und zeitlicher Ebene. Er war um ca 16 Uhr fertig. Bei mir lief es nicht so gut. Zwar hatte ich ein gutes Verständnis von RethinkDB aufgebaut aber schnell gemerkt, dass es die Änderungen nicht ohne Weiteres in Browser-Clients pushen kann. Für die asynchrone Kommunikation über das Web müsste entweder eine Menge Websocket-Code programmiert oder die RethinkDB-Erweiterung Horizon eingesetzt werden. Also habe ich noch Horizon lernen müssen. Horizon ermöglicht die Entwicklung von echtzeitfähigen Web-Apps auf eine Art und Weise, die mich sehr an Meteor erinnert. Mit Horizon habe ich dann einen Webserver entwickelt, der meine RethinkDB mit einem Browser-Frontend verknüpft. In der Vergangenheit habe ich viel mit Aurelia gearbeitet, sodass ich auch hier gerne Aurelia eingesetzt hätte um eine hübsche Oberflächliche im Browser zu gestalten. Leider waren alle Horizon-Beispiele entweder in Angular oder React. Von Angular halte ich nicht viel, also habe ich auch noch React gelernt. Der ReactComponent.render-Ansatz hat mich sehr an Control.OnPaint erinnert. Schließlich hatte ich eine echtzeitfähige React-App, die über Horizon mit der RethinkDB kommunizieren konnte. Neue Einträge in der Datenbank erschienen automatisch im Browser. Endlich. Mittlerweile war es 20 Uhr und alle LabsDay-Teams haben sich zum gemeinsamen Abendessen im Besprechungsraum getroffen.

Nach dem Essen habe ich mir das Speichern der Events, die in KMS passieren, in der RethinkDB vorgenommen. Mein Teamkollege hatte nach seinem Erfolgserlebnis seinen KMS-Agenten mittlerweile sogar dokumentiert. Für die Kommunikation zwischen seinem Endpunkt und meiner RethinkDB habe ich einen Message Bus als Infrastruktur-Komponente mit EasyNetQ auf RabbitMQ installiert, den Labs Service Bus. Jetzt brauchte ich nur noch eine Komponente, die auf die Events wartet, die der KMS-Agent im Auftrag von KMS auf dem Bus veröffentlicht und diese dann in die RethinkDB einfügt. Dazu habe ich in der Solution des KMS-Agenten pro Event eine Assembly mit dem .NET Standard 1.4 und jeweils einer Klasse “Message” angelegt. Diese Messages, Akte angelegt und Zeiteintrag erfasst, gehören logisch dem KMS-Agenten, der KMS am Labs Service Bus vertritt. In meiner Komponente, die auf diese Events hören soll, habe ich diese .NET Standard-Assemblies referenziert und entsprechende Event Handler implementiert. Zum ersten Mal konnte ich jetzt in KMS einen Zeiteintrag erfassen und augenblicklich erschien in meiner React-App die Zeile “5 Stunden Aktendurchsicht erfasst”. In diesem Moment hatte ich eine Idee für einen Namen für meine App. Meine Vision war es alle Vorgänge und Aktivitäten innerhalb einer Kanzlei im Echtzeit hier anzuzeigen. In einer aktiven Kanzlei würden dann ganz viele verschiedene Ereignisse durch den Browser scrollen. Ich würde den Herzschlag der Kanzlei visualisieren: LEXolution.Pulse war geboren.

Mittlerweile war es kurz vor 23 Uhr und ich war ziemlich müde. Nachdem ich noch Icons und ein Logo eingebaut hatte, fuhr ich nach Hause. Auf dem Heimweg sind mir dann noch viele andere KMS-Aktionen eingefallen, die ich auch noch anzeigen wollte. In dieser Nacht habe ich schlecht geschlafen, wahrscheinlich vor Aufregung.

Am nächsten Morgen bin ich wie gewohnt ins Fitnessstudio gefahren und habe den Tag in Gedanken durchgeplant. Ich würde noch genug Zeit haben, weitere KMS-Vorgänge zu visualisieren. Als ich dann im Büro angekommen war, war mein Teamkollege bereits da. Wir hatten bis um 11 Uhr Zeit, da ab diesem Zeitpunkt der Hackathon endet und die Präsentationsvorbereitung beginnt. Nachdem ich unser verteiltes System wieder in Betrieb genommen hatte, habe ich es geschafft noch zwei weitere KMS-Aktionen in LEXolution.Pulse zu visualisieren: Rechnung abgeschloßen und Zahlungseingang gebucht. Just in time.

Anschließend haben wir unsere Präsentation vorbereitet und um 13 Uhr mit allen LabsDay Teams zur Ergebnispräsentation getroffen. Bei der Präsentation waren Interessenten aus allen Abteilungen, unsere Vorstände und sogar ein Kunde anwesend. Unsere Präsentation verlief sehr gut. Die der anderen Teams auch. Es ist immer wieder erstaunlich zu sehen, was innerhalb von 24 Stunden umgesetzt werden kann. Nachdem alle Teams präsentiert hatten, wurden wieder die drei Preise verliehen. Eigentlich geht es ja nicht um Preise, sondern um unsere Idee und das Ausprobieren von neuen Technologien. Obwohl alle Teams beeindruckende Ergebnisse präsentiert haben, würden zwei ohne Preis nachhause gehen. Leider wurde unser Projekt dieses Jahr nicht mit einem Preis ausgezeichnet. LEXolution.Pulse wurde zwar sehr gelobt, aber die Preise gingen an LEXolution.RenoJane, Abonnieren mit PayPal und DMS-Importer-Android-App. Herzlichen Glückwunsch an meine Kollegen aus diesen Teams. Eure tollen Projekte haben die Preise wirklich verdient.

Mein Teamkollege und ich sind trotzdem sehr stolz auf LEXolution.Pulse. Wir hatten viel Spaß und konnten während der Arbeitszeit an einer eigenen Idee arbeiten. Ich habe gehört, Google Mail wäre auch so entstanden. Für mich war der LabsDay ein voller Erfolg. Ich konnte Erfahrung mit RethinkDB, Horizon, React und .NET Standard sammeln und habe viel gelernt. Wie auch immer es jetzt mit LEXolution.Pulse weitergeht, ich bin mir sicher, dass der STP LabsDay 2017 und seine großartigen Projekte unsere gesamte Firma motiviert und inspiriert haben.

 

Abends zuhause war ich ziemlich erschöpft. Endlich konnte ich RethinkDB von meiner ToDo-Liste streichen. Der nächste Punkt ist…

STP LabsDay 2015

Am Donnerstag und Freitag letzte Woche, dem 1. und 2. Oktober, habe ich am zweiten STP LabsDay teilgenommen. Die Firma für die ich arbeite veranstaltet diesen 24-Stunden-Hackathon jedes Jahr. Zusammen mit meinem Partner habe ich ‘einen’ alternativen Client für das STP KMS entwickelt, der im Browser und auf möglichst vielen Geräten läuft. Unser Ziel war es dabei nur eine Codebasis zu haben, plattformunabhängig.

Um dieses Ziel zu erreichen kamen entweder C# oder JavaScript in Frage. Mit Xamarin kriegt man C# auf Windows, Android, iOS und Mac und mit Silverlight in den Browser. Auf der anderen Seite läuft JavaScript sowieso schon im Browser und mit NW.js kriegt man JavaScript auf Windows und Mac und mit Apache Cordova auf Windows Phone, Android und iOS. Ich habe mich für JavaScript entschieden, da Silverlight mittlerweile uncool ist und das Silverlight-Plugin eh nicht mehr im Chrome läuft. Außerdem sehe ich C# jeden Tag und JavaScript nicht.

Was das Backend betrifft, konnten wir die externe Schnittstelle von STP KMS nutzen, sodass wir uns voll und ganz auf Client-Entwicklung konzentrieren konnten. Unser erster Prototyp lief nach ca. 7 Stunden dank NW.js und Apache Cordova auf allen uns zur Verfügung stehenden Platformen: Wir hatten Windows, Mac, Windows Phone, Android, iPhone und iPad dabei. Programmiert haben wir bis dahin wenig, die meiste Zeit ging für die Administration der Geräte und Deployment-Probleme drauf. Aber in diesem Prototyp hatten wir die Logik unter der Oberfläche mit AngularJS vollständig umgesetzt und uns um das Design überhaupt nicht gekümmert. Es lief dann zwar einwandfrei aber sah echt nichts aus. Also haben wir die restliche Zeit in UI-Design investiert und mit jQuery Mobile für Smartphones optimiert.

Wir hatten nach 24 Stunden eine harte Deadline. Aber das hat uns gereicht. Wir hatten sogar Zeit für Essen, Schlafen und Fitnessstudio. Dank Apache Cordova können wir unseren Client auch für BlackBerry, FirePhone, Tizen und alle anderen Geräte erzeugen, die wir heute noch gar nicht kennen.

Bei der Abschlusspräsentation des STP LabsDay haben wir dann die identische App auf Windows, Mac, Windows Phone, Android, iPhone und iPad gezeigt. Und das kam richtig gut an. Für unser Projekt “cross platform KMS-Aktensicht” haben wir anschließend zwei Awards gewonnen: Den “roadmapper”-Award (Kundenpreis) und den “leider geil”-Award (Zuschauerpreis). Ersteren hat ein echter Kunde der STP höchstpersönlich verliehen und für Letzteren haben alle Zuschauer der Ergebnispräsentation anonym abgestimmt. Den Vorstands-Award haben wir leider nicht mehr gewonnen, der ging an ein anderes Projekt. Dennoch haben wir mit modernen Web-Technologien in kurzer Zeit und ohne Vorwissen richtig viel erreicht und viele beeindrucken können. Und wir haben NW.js und Apache Cordova kennengelernt. Cross platform for the win!

WP_20151001_001
DSC_0105
DSC_0145

NDC Oslo 2015

I want to share a little about my first ever trip to Norway. Today I got back from Oslo, where I visited the NDC 2015 conference. Amazing conference, see some of the photos I took below. Everything else was a little too stressful.

It took me 6.5 hours to get from Karlsruhe to the hotel in Oslo. There I had to pay for the hotel room with my credit card because the hotel was not capable of dealing with the HRS booking my company did in advance. I did not sleep well because it doesn’t get dark in the nights. 11pm (first photo) in Oslo looks like 8pm in Karlsruhe and 3am looks like 9pm. It took me 7.5 hours to get from the hotel back to Karlsruhe.

I was at NDC on June 17th and 18th and those were two great days. The sessions of Ian Cooper and Udi Dahan inspired me the most. Now I need to digest and structure all the notes I took. Best conference I ever went to, thank you NDC! Hopefully I get to go again next year, different hotel maybe.

WP_20150616_001WP_20150617_002WP_20150617_010WP_20150618_001WP_20150618_004 WP_20150618_003 WP_20150618_002WP_20150617_007 WP_20150617_016WP_20150618_007WP_20150618_005 WP_20150617_014 WP_20150617_011WP_20150618_008 WP_20150618_010