SW

Stefan Wachter

nicht verfügbar bis 15.03.2025

Letztes Update: 16.05.2023

Softwareentwickler (Java, Scala, TypeScript, Spring, JEE, Akka, ZIO, Angular, JSF, Play)

Firma: swachter
Abschluss: Promovierter Diplom Informatiker;
Stunden-/Tagessatz: anzeigen
Sprachkenntnisse: deutsch (Muttersprache) | englisch (gut)

Skills

Informatikstudium an der Universität Karlsruhe (TH) mit Mathematik als Nebenfach im Hauptstudium; Abschluss Diplominformatiker (Dipl. Informatiker (M.SC)); anschließende Promotion im Bereich Maschinensehen.

Programmiersprachen:

- Java
- Scala
- TypeScript
- JavaScript
- Groovy
- Xslt
- Bash
- Go

Produkte:

- Cloud: Kubernetes, Docker, CloudFoundry, OpenShift, AWS
- Datenbanken: MongoDB, PostgreSQL, MySQL, H2, InfluxDB
- Messaging: RabbitMQ, AWS-SQS
- Auth: Keycloak
- Redis
- Applikationsserver, Servletcontainer: Bea WebLogic, JBoss, Tomcat, Jetty, Felix, WebObjects
- Server-Frameworks: Spring, Akka, ZIO
- Apache (inkl. mod_jk, mod_auth_openidc)
- Persistenz: Hibernate, JPA, JDO, Slick, Quill
- Webapplikationsframework: Play, Struts, Pustefix
- HTML-Frontend: Angular, Google-Web-Toolkit (GWT), Twitter Bootstrap
- XML-Tools: Xerxes, Xalan, Saxon, XML Spy, XEP, FOP
- Logging, Monitoring: ElasticSearch, LogStash, Kibana, Grafana, Kamon

- Versionskontrolle: Git, SVN, CVS, VSS
- Entwicklungsumgebungen: IntelliJ IDEA, NetBeans, Eclipse
- Build-Tools: Ant, Maven, Gradle, SBT, Hudson/Jenkins

- Ticket-Systeme: Bugzilla, Jira
- RuleEngines: JESS, JRule
- Compiler-Compiler: Antlr, JavaCC, jay, jlex
- UML: TogetherJ
- WebServices: JaxWs, CXF, Axis
- Tests: JUnit, EasyMock, Mockito
- Netbeans Profiler
- OSGi container: Felix
- Java Content Repository: Jackrabbit
- Zabbix Server; Entwicklung eines Java-Zabbix-Clients
- VMWare Workstation

Linux:

Ich entwickle hauptsächlich unter Linux

Standards:

- OAuth 2.0
- Swagger / OpenAPI
- UML
- J2EE: (insbesondere Servlets, JSPs, Custom-Tags, JPA)
- XML: DTD, XML Schema, XSLT, XPath, XSL-FO, JAXP, JAXB, SAX, DOM
- Web: HTML, DHTML, XHTML, CSS, W3C
- JDBC
- JCR
- SOAP
- JaxWs
- REST
- JSON

Projekthistorie

01/2022 - 07/2023
Weiterentwicklung und Betrieb eines Internetshops
Otto (Konsumgüter und Handel)

Technologie: Scala, TypeScript, Spring-Boot, AWS, Jenkins
Eingesetzte Produkte: AWS, Docker, Jenkins, Gradle, Spring, Gattling, MongoDB, Atlassian JIRA,
Atlassian Confluence

Die Arbeit bestand aus 2 Schwerpunkten:
1. Weiterenwicklung / Wartung der Microservices eines Internetshops
Die Microservices sind backendseitig mit Scala / Spring-Boot und
frontendseitig mit HTML/CSS/TypeScript implementiert.
Es wurde an Microservices im Bereich der Zahlung und Lieferung
gearbeitet. Das Verhalten des Shops bei Lastspitzen wurde untersucht und
verbessert.
2. Migration / Wartung des Infrastruktur-Codes
Eine selbstgeschriebene Anwendung zum Aufsetzen der Infrastruktur soll
abgelöst werden. Die bisherige Anwendung basiert auf AWS-
CloudFormation. Zur Ablösung wurden mehrere AWS-CDK-Anwendungen
in TypeScript implementiert.

08/2020 - 12/2021
Weiterentwicklung und Wartung eine Netzwerk- Management-Systems
OpenNMS (Internet und Informationstechnologie, 50-250 Mitarbeiter)

Neben Wartungsarbeiten bestand der Einsatz aus den folgenden Phasen
mit Weiterentwicklungen:
Phase: Weiterentwicklung des Kernels und der Konfiguration eines IoT-
Devices
Technologie: Java, Kotlin, Docker, Azure
Das IoT-Device enthält einen in Kotlin geschriebenen Kernel und läuft
unter Linux entweder auf einem Hardware-Device oder innerhalb einer VM.
Der Kernel lädt Docker-Images und kontrolliert die Ausführung von
Docker-Containern, die die eigentiche Anwendungslogik enthalten.
Durch eine Azure-Cloud-Anwendung werden mit Azure-Functions und dem
Azure-IoT-Hub die IoT-Devices konfiguriert.
Phase: Weiterentwicklung einer Streaming-Anwendung zur Aggregation
von Netflow-Daten und der zug. Visualisierung
Technologie: Java, Apache Beam, Flink, Kafka, ElasticSearch, Grafana
In einer mit Apache Beam implementierten Streaming-Anwendung werden
Netflow-Daten zeitlich aggregiert und die Hosts / Anwendungen mit den
höchsten Kommunikationsvolumina bestimmt. Die Anwendung läuft auf
Flink-Clustern und kann mehrere 100.000 NetFlow-Pakete pro Sekunde
verarbeiten.
Es wurde eine weitere Aggregation nach "Differentiated Service Code
Points" (DSCP) und die Berücksichtigung der "Explicit Congestion Notification" (ECN) implementiert. Durch Optimierung der Streaming-
Pipeline-Struktur konnte die Last der Pipeline trotz der zusätzlichen
Funktionalität reduziert werden.
Flow-Aggregate werden in ElasticSearch gespeichert. Ein ElasticSearch-
Plugin wurde angepasst, das die Abfrage der Flow-Aggregate als Zeitreihen
erlaubt. Ein Grafana-Plugin wurde erweitert, um die Abfrage und
Visualisierung der zusätzlichen DSCP-Aggregation und ECN-Information zu
ermöglichen.
Phase: Signierung von Multi-Architektur-Docker-Images
Technologie: Docker, Notary, CircleCI
Die auf den oben beschriebenen IoT-Devices laufenden Docker-Images
werden mit Docker Content Trust signiert. Dazu wurden die benötigten
Public/Private-Key-Paare eingerichtet und der Build-Vorgang entsprechend
angepasst.
Da das IoT-Device auf unterschiedlichen Prozessoren laufen kann, handelt
es sich bei den Docker-Images um Multi-Architektur-Images. Signierte
Multi-Architektur-Images konnten zur Zeit der Umsetzung noch nicht durch
Docker selbst erzeugt werden sondern verlangten den direkten Einsatz des
zugrundeliegenden Notary-Service.
Phase: Nutzung von Cortex zur Speicherung und Visualisierung von
Netflow-Daten
Technologie: Java, Apache Beam, Flink, Kafka, Cortex, Prometheus,
Grafana
Es wurde eine Sink-Transformation für Apache-Beam implementiert, um
Flow-Aggregate in Cortex zu speichern. Hauptprobleme bei der Umsetzung
waren die zeitliche Ordnung von Ergebnissen und
Kardinalitätsbeschränkungen.
Cortex verlangt, dass Samples, die zur gleichen Zeitreihe gehören, zeitlich
geordnet geschrieben werden. Apache-Beam garantiert jedoch keine
zeitliche Ordnung von Ergebnissen. Zur Lösung wurden ein weiteres
Attribut in Zeitreihen eingeführt, das "verspätete" Ergebnisse anderen
Zeitreihen zuordnet. Über dieses Attribut kann bei der späteren Abfrage
aggregiert werden.
Cortex verlangt, dass das Produkt der Attribut-Kardinalitäten einer Metric
nicht zu groß wird. Um dieses Problem zu mildern wurde ein Teil der
Attribute in die Metrik-Namen kodiert.

07/2019 - 07/2020
Weiterentwicklung KFZ-Versicherungsanwendung
Mercedes-Benz Bank (Banken und Finanzdienstleistungen)

Technologie: Java, Scala, TypeScript, Spring, Angular, SQL, OAuth 2.0, Jenkins, OpenShift, Kubernetes, H2, MySQL, Gradle,
Apache, mod_auth_openidc

Die Anwendung besteht aus einem Spring-Boot-Backend und Angular-
Clients für Administratoren bzw. Versicherungsverkäufer.

Die Anwendung wurde durch folgende Maßnahmen modernisiert:
• Migration: Spring Boot 1.5 -> 2.0; Angular 2 -> Angular 9
• Deployment: Tomcat 8 -> Kubernetes / OpenShift
• Aufsetzen einer CI-Umgebung: Jenkins-Pipeline innerhalb von
OpenShift; inkl. Backend-Integration-Tests und Chrome-Headless-
Browser-Tests
• OAuth 2.0 Authentifizierung in vorgeschaltetem Apache mit
mod_auth_openidc
Am Code wurden zahlreiche Verbesserungen durchgeführt:
• Verwendung von Springfox zur automatischen REST-API-
Beschreibung. Automatische Angular-Client-Generierung.
• Verbesserung der Validierungslogik durch Einsatz von Cats Validated.
• Verbesserte Testabdeckung durch generierte Test-Fälle (property
based testing; tool: Scala Check).
• Bessere Nutzung von Angular-Mechanismen (insbesondere
vermehrter Einsatz von Services und Dependency-Injection)
• Vermehrter Einsatz von Observables

10/2018 - 06/2019
Mitarbeit an einer Big-Data-Analytics Plattform
Katana USU (Internet und Informationstechnologie)

Während des Einsatzes wurden einzelne Features full-stack bearbeitet
(Frontend und Backend). Dabei wurden bestehende Features überarbeitet
und neue Features entworfen und entwickelt. Die Frontend-Entwicklung
fand mit TypeScript, ScalaJS und Angular statt. In der Backend-
Entwicklung kam hauptsächlich Scala und etwas Go zum Einsatz.
Eine weiterer wichtiger Beitrag war die Einführung von Integration-Tests,
in denen Plattform-Bestandteile in lokalen Kubernetes Clustern deployt und
getestet werden. Dazu wurde Kubernetes in Docker (kind) innerhalb von
Gitlab-CI eingesetzt.
Der Einsatz gliederte sich grob in 3 Phasen:
Phase: Überarbeitung der Kommunikation mit Jupyter Kernels
Die Umsetzung basierte auf Akka. Der Kommunikationszustand wurde
durch Aktoren repräsentiert, die für eine verlässliche Sitzungs- / Jupyter-
Kernel-Verwaltung sorgten.
Phase: Entwicklung eines Ingress für die Funktionsausführung

Die Plattform erlaubt es, wiederkehrende Auswertungen als HTTP-
Funktionen zu deployen (basierend auf OpenFaaS). Es wurde ein Ingress
entwickelt, der die Authorisierung der Aufrufe vornimmt und
Aufrufergebnisse sowie zug. Log-Ausgaben persistiert. Der Ingress
unterstützt sowohl synchrone als auch asynchrone Funktionsaufrufe.
Ergebnisse können weitergeleitet, weitergeleitet und persistiert oder nur
persistiert werden. Durch Streaming ist sichergestellt, dass der Ingress
auch bei sehr großen Datenmengen mit begrenztem Speicher auskommt.
Phase: Rechte/Rollen-Konzept für Repository
Das Repository basiert auf Apache Oak. Es wurde ein Rechte/Rollen-
Konzept umgesetzt, das private, gemeinsame und geschützte
Arbeitsbereiche unterstützt.

Kenntnisse: Streaming, Scala, ScalaJS, TypeScript, Go, Bash, OAuth 2.0

Eingesetzte Produkte: Kubernetes, Docker, kind, Helm, OpenFaaS, Oak, Gitlab-CI, Angular,
Keycloak, Play, Akka, Jupyter, SBT, PostgreSQL

04/2015 - 09/2018
Entwicklungen und Evaluierungen im Bereich des Internet der Dinge (IoT)
Bosch

Während der Projektlaufzeit wurden 4 unabhängige Unterprojekte
bearbeitet.

Unterprojekt: Proof of Concept von Authorisierungsszenarien im IoT-
Umfeld

• Laufzeit: 2018/06-2018/09 (4 Monate)
• Rolle im Projekt: Entwickler, Architekt
• Technologie: Scala, Akka-HTTP, Scala.js, SBT, OAuth 2.0, OpenID
Connect, UMA 2.0, Keycloak

Detaillierte Beschreibung: Es wurden Nutzungsszenarien für EBikes
untersucht. Ein Fahrradbesitzer authorisiert mittels "User Managed Access"
(UMA) eine andere Person zur Nutzung des Fahrrads. Das Fahrrad wird
mittels OAuth 2.0 "Device Flow" authorisiert, auf Besitzer- und Nutzer-
Daten zuzugreifen. Verschiedene Nutzer authorisieren sich mittels UMA
gegenseitig, auf bestimmte Daten (z.B. aufgezeichnete Fahrten)
zuzugreifen.
Alle User-Interfaces wurden als "Single-Page Application" mittels Scala.js
umgesetzt. Das Backend (der Resource-Server) wurde mittels Akka-HTTP
implementiert. Die Kommunikation erfolgte mittels JSON und der circe-
JSON-Bibliothek, wodurch dieselben Datenmodelle sowohl in den User-
Interfaces als auch im Backend genutzt werden konnten.

Unterprojekt: Entwicklung eines Handshake-Endpunktes für IoT Devices
und eines zug. Konfigurationstools

• Laufzeit: 2018/03 - 2018/05 (3 Monate)
• Rolle im Projekt: Entwickler
• Technologie: Java, SpringBoot 1.5 / 2, Card Verifiable Certificates
(CVC), Certificate-Chains, EdDSA, Diffie-Hellman
Detaillierte Beschreibung: Mittels eines 2-Schritt-Handshakes wird ein
"shared secret" zwischen IoT-Devices und einem Backend etabliert und
beide Seiten zugleich authentisiert. Der Handshake ist an den Diffie-
Hellman Key-Exchange-Algorithmus angelehnt. Da es sich um
"Constrained Devices" handelt und um Bandbreite zu sparen, werden CVCs
und EdDSA-Schlüssel verwendet.

Unterprojekt: Bewertung möglicher Protokoll-Stacks,
Kommunikationspatterns, Kommunikationssetups und System-
Architekturen für IoT-Devices

• Laufzeit: 2018/01 - 2018/02 (2 Monate)
• Rolle im Projekt: Rechercheur, Entwickler, Tester
• Technologie: Scala, Eclipse Californium, UDP, DTLS, COAP(S), TCP, TLS, HTTP(S), LWM2M

Detaillierte Beschreibung: Die verschiedenen Protokoll-Stacks wurden
anhand der folgenden Kriterien bewertet: Direktheit, Sicherheit,
Zustandslosigkeit, Cloud-Support, Reifegrad, Kosten-Effizienz, Robustheit
und geeignete Nachrichtengrößen. Bei den Kommunikationspatterns wurde
untersucht, wie mit Devices kommuniziert werden kann, die die meiste
Zeit nicht erreichbar sind. Dabei wurde das Konzept "Digital Twin"
beleuchtet. Die Bewertung des Kommunikationssetup befasste sich damit,
wie eine sichere Kommunikation zwischen Devices und Backend hergestellt
werden kann. Hier wurden "pre-shared keys" bei denen Devices vorab im
System registriert werden müssen, mit der Verwendung von
Zertifikatsketten verglichen. Schließlich wurde eine Software-Architektur
aufgestellt, die dem Konzept des "Digital Twin" Rechnung trägt.

Unterprojekt: Anbindung von Devices an das Internet der Dinge (IoT)

• Laufzeit: 2015/04 - 2017/12 (33 Monate)
• Rolle im Projekt: Entwickler, Architekt
• Technologie: Scala, Akka, Streaming, Event Sourcing, MongoDB,
RabbitMQ, Redis, Docker, Cloud Foundry, ELK-Stack, Grafana, Kamon,
InfluxDB, LWM2M, Maven, SBT, Gatling

Detaillierte Beschreibung: Es wurde ein Backend zur Anbindung von
Devices entwickelt, die Status-Informationen senden (Telemetry) und
Befehle entgegennehmen können (Control). Die Devices sind nur zu
bestimmten Zeitpunkten erreichbar. Alle Events werden aufgezeichnet, um
daraus ein Bild vom momentanen Device Zustand ableiten zu können.
Das Backend ist in Form eines Flussgraphen implementiert, an das die Ein-
und Ausgaben als Daten-Sourcen bzw. -Senken angebunden sind.
Backpressure verhindert, dass das System überladen werden kann. Das
Backend kann in einer geclusterten Umgebung laufen, da zusätzliche
Instanzen ohne Datenverlust jederzeit gestartet und wieder beendet
werden können.
Die Implementierung des Backend basiert auf Akka Streams und Aktoren.
Außerdem kommen die Bibliotheken Shapeless, Cats und Monocle zum
Einsatz.

Kenntnisse: Scala, LWM2M, Streaming, Event Sourcing, UDP, DTLS, COAP, OAuth 2.0,
OpenID Connect, UMA 2.0

Eingesetzte Produkte: Akka, MongoDB, RabbitMQ, Redis, Docker, CloudFoundry, Elastic Search,
Logstash, Kibana, Grafana, InfluxDB, Maven, SBT, Keycloak, Kamon,
Gatling

01/2015 - 03/2015
Multi-Kanal Nachrichtenversand
GLS

Technologie: JEE 6, JMS, JSF 2.0, PrimeFaces, Drools 6.1, JBoss EAP 6.2, Antlr 4.5, Gradle

Beschreibung: Über eine JMS-Queue gelangen pro Tag bis zu 2 Mio Nachrichten in das
System; durch eine Regelauswertung wird entschieden, ob und wenn ja welche Nachrichten
versandt werden müssen; mit einer selbst entwickelten Template-Engine werden SMS- und EMail-
Nachrichten erzeugt, die abschließend an einen Rest-Service übergeben werden. Mit einer in JSF
realisierten Anwendung kann das System administriert werden.

04/2014 - 09/2014
Entwicklung einer Lieferanten-/Sortimentsverwaltung
Bader

Technologie: Java, Scala, JSF 2.0, PrimeFaces, Bootstrap, jQuery, EJB, JBoss, MongoDB, IBM-
REST, Play, ScalaTest, SBT

Beschreibung: Entwicklung einiger JSF-Composite-Komponenten (zur Eingabe komplexer
Datenmodelle inkl. Validierungen); Enwicklung einer Scala-Bibliothek zur Anbindung des Host-
Systems (IBM-IMS) via IMS-Connect (Implementierung in Form eines Monads, das eine
Konversation mit dem Host beschreibt. Außerdem eine interne DSL zur Definition der
Konversationen). Entwicklung eines Template-System zur Beschreibung semi-strukturierter
Produkteigenschaften (Implementierung mittels Scala-Parser-Combinators). Entwicklung mehrerer
"Boundaries" für den Zugriff auf eine MongoDB. Entwicklung eines Rest-Services zur Adressabfrage
(Implementierung durch JaxWs). Entwicklung einer flexiblen Daten-
Repräsentations/Darstellung/Binding-Schicht (an JSON angelehntes Objektmodell, einfache Schema-
Sprache, JSON-Path-Implementierung, automatischer Aufbau/Verarbeitung von HTML-Formularen)

Reisebereitschaft

Verfügbar in den Ländern Deutschland
anfangs max. 4 Tage vor Ort, später hoher Remote-Anteil notwendig

Sonstige Angaben

Bitte besuchen Sie mein Gulp-Profil (https://www.gulp.de/gulp2/home/profil/stefan.wachter?1)
Profilbild von Stefan Wachter Softwareentwickler (Java, Scala, TypeScript, Spring, JEE, Akka, ZIO, Angular, JSF, Play) aus Waiblingen Softwareentwickler (Java, Scala, TypeScript, Spring, JEE, Akka, ZIO, Angular, JSF, Play)
Registrieren