Unser Kunde möchte seinen Mitgliedern das Training erleichtern und Schüsse auf Zielscheiben mit einer App erfassen lassen können. Dies soll auch offline mit einer späteren Synchronisierung in ein Back-End möglich sein. Zusätzlich möchten die zuständigen Trainer die Trainingsdaten ihrer Schützen einsehen und auswerten können.

Hierzu entwerfe und entwickle ich eine Anwendung für mobile Endgeräte und ein dazu gehöriges Back-End zur Auswertung der Trainingsdaten. Die mobile Anwendung wird mit React Native umgesetzt, für das Back-End wird C# mit ASP.NET erstellt. Die mobile Anwendung soll es den Nutzern mit minimalen Unterbrechungen so einfach wie möglich machen ihre Trainingsdaten zu erfassen. Zur Anmeldung der Nutzer nutze ich einen Keycloak-Server.

Unser Kunde möchte es seinen Kunden ermöglichen ihre Flotte an Feuerwehr-Kommunikations-Geräten über eine Web-Oberfläche einzusehen und zu verwalten.

Hierzu wird ein React-basiertes Front-End entwickelt, welches über WebSocket mit einem Back-End in einer Event-basierten Weise kommuniziert.

Die Geschäftsabläufe des Kunden setzen voraus, dass sich neu im Keycloak registrierende Nutzer schon in einer von mehreren Datenbanken des Kunden hinterlegt sind.

Hierfür habe ich ein Plugin für Keycloak entwickelt, welches anhand von Gruppeneinstellungen in Keycloak entscheidet zu welcher Datenbank es sich verbindet, dort nach dem sich registrierenden Nutzer sucht und nur bei schon angelegten Nutzern die Registrierung zulässt. Begleitend dazu habe ich Dokumentation sowohl für Entwickler-nahe Themen dieses Plugins, als auch für Keycloak-Administratoren zum Betrieb des Keycloak-Servers mit diesem Plugin geschrieben. Zusätzlich habe ich für diesen Keycloak-Server einen docker-compose-Stack erstellt, der sich mit einem bereits existenten nginx Reverse Proxy integriert, und diesen auf bestehender Hardware deployt.

Die gesamte Lösung ermöglicht es den Endkunden unseres Kunden, sich selber bei diesem Keycloak-Server zu registrieren, um später andere Anwendungen unseres Kunden mittels OIDC nutzen zu können. Unserem Kunden ermöglicht diese Lösung, einfach bestehende Datenbanken in den Keycloak zu integrieren, damit diese im Registrierungsablauf verwendet werden können.

Ich betreue eine Implementation eines von Freunden entworfenen Rollenspielsystems als FoundryVTT Modul. Dieses is in Typescript geschrieben und nutzt die vorher genannten Typendeklarationen.

Das System hat eine von mir entworfene Funktionalität, die es Nutzern zur Laufzeit erlaubt Werte von Charakteren und/oder Gegenständen nicht-destruktiv zu verändern. Das bedeutet, dass neben dem Ändern von Grundwerten, sogenannte Regeln erstellt werden können die, ähnlich CSS-Selektoren, Objekte und Eigenschaften auswählen und zu diesen eine Liste an Änderungen hinzufügen können. Der Grundwert wird dabei nie verändert und das System ist in der Lage dem Nutzer eine Aufschlüsselung der Berechnung des Endwertes jeder Eigenschaft anzuzeigen.

Des weiteren beinhaltet das Build-System des Moduls Tasks, welche verschiedene Typendeklarationen in zur Laufzeit konsumierbare Konfigurationen umwandeln.

Ich bin Teil einer Anstrengung Typescript Typendeklarationen für diese API zu erstellen. Die dafür nötigen Deklarationen sind sehr komplex, da FoundryVTT stark auf globale Konfiguration zur Laufzeit setzt. Dies führt dazu, dass die Deklarationen sehr viel mit Generics arbeiten müssen.

Das Projekt betrifft eine langjährig genutzte Applikation eines Plattformanbieters im Oil-&-Gas-Sektor mit einem umfangreichen europäischen Kundenstamm. Die bestehende Anwendung entsprach nicht mehr den aktuellen Anforderungen der Nutzer. Zunehmend bestand der Wunsch nach einer mobilen Lösung, die auf Tablets und Smartphones verfügbar ist und die Möglichkeiten moderner Sensorik integriert.

Zur Umsetzung dieser Anforderungen wurde eine neue Benutzeroberfläche auf Basis der bestehenden Datenstruktur entwickelt. Das neue Frontend entstand als Ensemble mehrerer in Vue 3 realisierter Progressive Web Apps (PWAs), implementiert in TypeScript unter Verwendung von Vite.

Neben der Frontend-Entwicklung gehörte auch die Implementierung mehrerer Verbindungsmodule zum Backend zu meinen Aufgaben. Diese Module ermöglichten die effiziente Abfrage und Aufbereitung großer Datenmengen (über 10.000 Einträge pro Abruf) bei minimaler Latenzzeit, um eine performante und reaktionsschnelle Benutzererfahrung sicherzustellen.

Die BashParty-Minispiele sind eine Event-Location im Herzen von Wiesbaden. Die BashParty-App erfüllt für die Location zwei Aufgaben. Zum einen bietet sie den Mitarbeitern die Möglichkeit den Standort mit seinen Räumen, Spielen und mehr zu verwalten. Zum anderen bietet sie den Spielern ein geführtes Erlebnis durch das Merken von Punkteständen, das Anzeigen von Anleitungen und das Führen durch die Spiele die der Besuchergruppe zugeordnet wurden. Diese Funktionen erleichtern den Mitarbeitern den Betrieb der Location und reduzieren den Personalaufwand.

Die Anwendung wurde mittels ASP.NET als ein einzelner Web-Server umgesetzt. Dieser Server ist sowohl für die Business-Logik im Back-End zuständig, als auch für das ausliefern von statischen Dateien für das Front-End. Ferner wird ein MS SQL-Server genutzt, mit dem mittels Entity-Framework kommuniziert wird. Das Back-End integriert außerdem mit der Reservierungs-Management-Platform CentralPlanner. Die Reservierungen für den Standort werden dort verwaltet und die BashParty-App ermöglicht es den Mitarbeitern die Reservierungen von CentralPlanner in die BashParty-App abzugleichen.
Das Front-End besteht größtenteils aus statischen Seiten. Diese wurden je nach bedarf mit simplen JavaScript oder mit Vue-3 Apps dynamisch erweitert. Teile der Anwendung werden ohne Interaktion des Nutzer proaktiv vom Server aktualisiert. Dies geschieht mittels SignalR/WebSocket. Die Anwendung wurde mittels Tailwind CSS und daisyUI designt und gestyled.
Die ganze Anwendung ist in Microsoft Azure gehostet.

Zu meinen Aufgaben gehörte die Beratung des Kunden beim Ursprünglichen Entwurf der Anwendung, die Software-architektonische Planung, die Umsetzung der Anwendung, das Einrichten des Azure-Stacks und das Erstellen der Deployment-Pipelines. Zusätzlich habe ich die Entwicklung mit einem Kollegen koordiniert, der mich zeitweise bei der Umsetzung von Anforderungen unterstützt hat und ihm Aufgaben zugeteilt.

Für eine interne Platform zur Vermittlung von firmeneigenen Leasingfahrzeugen,

in einen AWS EKS Cluster deployt.

Gates (Linter, Security Scans) erstellt.

Workflows benutzt.

Das Corporate Booking Tool (CBT) ist eine Webanwendung, die es Firmenkunden einfacher macht Hotelreservierungen zu vorher mit Hotels vereinbarten Vorzugsraten zu buchen.

Das Front-End musste ersetzt werden, da die Sicherheitsrichtlinien von Sabre eine Content-Security-Policy vorschreiben, welche Inline-JavaScript und Inline-Styles verbietet. Bis zu diesem Zeitpunkt wurden Scripte direkt in die JSP Templates geschrieben, und mitunter direkt mit Variablen aus den Templates gefüllt, welches an vielen Stellen Cross-Site-Scripting ermöglichte. Um diese Schwachstellen zu beheben habe ich sämtliche Inline-Scripte in eigene ES-Modul-Dateien extrahiert, welche mit esbuild in einzelne, für jede einzelne Seite angepasste und minifizierte Scripte kompiliert wurden. Ich nutzte die Gelegenheit um die Scripte auf Typescript um zu ziehen. Des weiteren entwarf und implementierte ich einen Client für Tabellenansichten. Dieser Client ist in der Lage Tabellendaten beim Back-End mit mehreren Filtern, Sortierungen und Paging an zu fragen. Dies geschieht auf eine typsichere Art und Weise, welche keine unbekannten Felder, Filter, Sortierungen usw. zulässt und SQL-Injection vermeidet. Zur Umsetzung nutzte ich Teilweise Widgets/Componenten des firmeneigenen UI-Frameworks. Dieses ist in JavaScript geschrieben, welches mich dazu veranlasste Typescript-Deklarationen für dessen ES-Module zu schreiben und den Erstellern zur Verfügung zu stellen.

Der Profile Manager ist einer von mehreren Services im Sabre Ökosystem, welches sich an einer (micro-)services Architektur orientiert. Dieser Service stellt Endpunkte zum Verwalten und anderer Aktionen rund um verschiedene Arten von Profilen zur Verfügung. (Gast-, Firmen-, Bucherprofile ?)

Sabre verfolgt im allgemeinen eine Microservice-Architektur, weshalb der Profile Manager als eigenständige Anwendung Funktionen rund um Profile zur Verfügung stellt. Dies ist besonders nützlich, um verschiedene externe Drittanbieter mit einer einheitlichen internen API abzubilden.

Der Service ist in C# implementiert und Teil eines Monorepos, welches fast sämtliche Software der Hotelsparte von Sabre umfasst.

Das Corporate Booking Tool (CBT) ist eine Webanwendung, die es Firmenkunden einfacher macht Hotelreservierungen zu vorher mit Hotels vereinbarten Vorzugsraten zu buchen.

Die Anwendung ist in Java (8) geschrieben und nutzt Spring Boot MVC als Back-End Framework mit Java Server Pages (JSP) Templates zum erstellen der HTML-Antworten. Zur Interaktion mit der Anwendungs-eigenen MySQL-Datenbank wird JPA und Hibernate eingesetzt. Das Front-End nutzt für diverse Tabellenansichten einen von mir entworfenen und in Typescript umgesetzten Client.

Meine Aufgaben bei dieser Anwendung bezogen sich auf Implementieren von neuen Features, das Anbinden der Anwendung an die APIs von Sabre und das Suchen nach und Beheben von Sicherheitslücken. Letztere machten es nötig einen Großteil des Back-End Controller-Codes und das Front-End neu zu schreiben.

Ich war ebenfalls involviert in den Umzug von Sabre Services von On-Premise nach Google Cloud Platform (GCP). Alle Services an denen ich beteiligt war, sind in C# geschriebene Services, die auf Windows Server laufen. Die Infrastruktur, um nach GCP umzuziehen umfasste Packer-Skripte für das Erstellen von Disk-Images, Puppet-Skripte für das Konfigurieren der Instanzen vor dem Erstellen eines Images, Terraform-Skripte als Infrastructure as Code (IaC)-Lösung für GCP und make-Files für den Build-Prozess.

Des weiteren wurde von Sabre ein internes Tool zum erfassen von Metadaten zu den eigenen Services erstellt, welches letztendlich einen Dependency-Graph der Services erstellen konnte. Dies wurde genutzt um Deployments mit Ansible und ServiceNOW zu verwalten und zu automatisieren. Die Grundlage bildeten hier in YAML umgesetzte Asset-Files. Ich hatte die Gelegenheit teile des JSON/YAML-Schemas für diese zu schreiben. Ebenfalls habe ich hier Teile eines Build-Skriptes in Python umgesetzt, welches den Dependency-Graph analysiert und entsprechende Deployments erstellt.

Das Corporate Booking Tool (CBT) ist eine Webanwendung, die es Firmenkunden einfacher macht Hotelreservierungen zu vorher mit Hotels vereinbarten Vorzugsraten zu buchen.

CBTs Back-End wurde von mir von einer Eigenbaulösung auf Spring MVC umgezogen. Dies war nötig um eine Cross-Site-Request-Forgery (CSRF) Schwachstelle zu beheben, welche fast jeden Endpunkt der Anwendung betraf. Ich behob außerdem weitere Schwachstellen, welche im Laufe dieses Projektes im Back-End-Code gefunden wurden. Dies Umfasste: Client-Side-Validation, SQL-Injection, Cross-Site-Scripting, Broken/Missing Object-Level Authorization, Broken Authentication.

Um die Broken Authentication zu beheben wurde die Anmeldelogik ebenfalls von einer Eigenbaulösung auf Spring Security umgezogen.

Das Corporate Booking Tool (CBT) ist eine Webanwendung, die es Firmenkunden einfacher macht Hotelreservierungen zu vorher mit Hotels vereinbarten Vorzugsraten zu buchen.

CBT läuft auf Linux-Systemen und wurde vor der Übernahme durch Sabre in Docker-Containern auf eigenen Servern deployt. Nach der Übernahme, bis heute, wird es auf EC2-Instanzen in AWS deployt. Das Schreiben und Anpassen der Cloudformation-Templates und Installationsskripte war im Zuge dieses Projekts meine Aufgabe. Diese Templates umfassten eine RDS-Datenbank, eine EC2 Autoscaling Group, zwei Load-Balancer (intern und extern), diverse Security Groups und Alarme.

Da durch den Umzug die Zugriffsrechte auf die in Produktion laufende Anwendung geändert wurden, mussten zwei Aspekte der Anwendung geändert werden. Zum einen basierte das Übersetzungssystem auf lokalen Dateien, sollte aber auch von Administratoren ohne Redeployment anpassbar sein. Zum anderen gab es die Möglichkeit das Aussehen der Anwendung für einzelne Kunden anzupassen. Dies erfolgte auch über lokale Dateien. Für einzelnen Seiten der Anwendung gab es eine Standardvariante und eine Angepasste für jeden Kunden. Für beide Aspekte wurde die Anwendung um die Fähigkeit erweitert, diese Konfigurationen dynamisch zur Laufzeit aus der eigenen Datenbank zu lesen und im Front-End zu bearbeiten. Besonders das Anpassen des Aussehens wurde so geändert, dass keine separaten Dateien mehr nötig sind und stattdessen ein dynamisches CSS generiert wird.

Das Open Source Software Projekt ?LSD? (LSDeluxe) ist ein in Rust geschriebener Klon des weit verbreiteten GNU Command-Line-Tools ?ls? mit erweiterten Funktionen. Das Tool brauchte eine Lösung um es den Nutzern möglich zu machen persistente Einstellungen für sein Verhalten festzulegen. Ein zusätzliche Anforderung war, dass die Nutzer genau darüber informiert werden sollten, ob und welche Fehler es in der Konfigurationsdatei gibt.

Um das möglich zu machen, habe ich ein Modul zu dem Tool beigetragen. Dieses Modul findet Konfigurationsdateien Betriebssystem-übergreifend auf Windows, MacOS and Linux an Standardisierten Orten. Das Tool hält sich für diese Orte an die XDG (X Desktop Group) Base Directory Spezifikation. Zusätzlich liest das Modul die dort hinterlegten Einstellungen. Um genaue Auswertungen und Rückmeldungen über die Art von Fehlern zu ermöglichen, habe ich auf direkte Deserialisierung in Structs verzichtet und eine eigene Auswertungslogik erstellt. Diese kann die Konfigurationsdatei genauer auswerten und den Nutzer über Fehler und ihre Art informieren. Das ist selbst dann noch möglich, wenn die Datentypen in der YAML-Konfigurationsdatei nicht den Erwartungen entsprechen. Zuletzt führt das Modul die gelesenen Einstellungen mit den gegebenen Command-Line-Flags zusammen und beeinflusst so das Verhalten des Tools.

Kurz nach der Übernahme von Trust durch Sabre bestand die Notwendigkeit bestimmte Daten von den Trust-Systemen in die Sabre-Systeme zu migrieren. Es bestand eine Limitierung darin, dass Sabre nur in der Lage war diese Daten in CSV oder Excel-Dateien einzulesen. Wir entschieden uns dann meine Erfahrung mit den Trust ETL-Prozessen zu nutzen, um diese Daten mit Ruby zu extrahieren, zu transformieren und in verschiedenen Formaten zu exportieren. Hier spielte wieder Leistung, Effizienz und einfache Anpassbarkeit eine besondere Rolle. Letzteres besonders da sich noch während der Migration die Anforderungen durch neue Erkenntnisse änderten. Diese Extraktionswerkzeuge waren als Command Line Interface (CLI)-Anwendungen implementiert.

Dieses Tool diente dem Auswerten von verschiedenen Daten im Trust Central Reservation System (CRS). Ein Teil davon waren eine Sammlung aus Extract, Transform, Load (ETL) Prozessen, die von mir in Ruby geschrieben waren. Diese hatten die Aufgabe die verschiedenen Rohdaten in ein Format zu bringen, welches von den Reports einfacher und Performanter ausgewertet werden konnte. Der Fokus lag hier auf Leistung, Effizienz und einfacher Anpassbarkeit unter sich ändernden Anforderungen. Diese Prozesse liefen in regelmäßigen Abständen und wurden durch Cron angestoßen.

Der LogAnalyzer war mein Abschlussprojekt in meiner Ausbildung zum Fachinformatiker für Anwendungsentwickling. Es war eine Command Line Interface (CLI)-Anwendung, die es dem Nutzer mit einer an SQL angelehnten Sprache ermöglichte strukturierte Log-Dateien zu durchsuchen, zu filtern und zu sortieren. Der LogAnalyzer sollte es dem Systemadministrator der GeoContent erleichtern Log-Dateien der verschiedenen Server der Firma zu analysieren.

Ich habe die Anwendung in einer ersten Version in Java implementiert, mit dem ich allerdings bei großen Dateien in Leistungsprobleme geriet. Daraufhin implementierte ich sie auf Anraten meines Ausbilders in C++ neu. Dies führte zu einer 12-fach besseren Leistung und einem Signifikant kleinerem Arbeitsspeicherbedarf.

Dieses Projekt war ein Versuch ein Bilderkennungs-Machine-Learning-Model darauf zu trainieren, Bäume auf Luftaufnahmen zu erkennen. Das Erkennen von Bäumen war zum Beispiel gewünscht um diese aus 3D Modellen heraus rechnen zu können, die durch parallaxe Luftaufnahmen erstellt wurde.