Sven Ruppert
70 Beiträge
Sven Ruppert entwickelt seit 1996 in Java an Industrieprojekten. Er war über 15 Jahre als Berater weltweit in Branchen wie Automobil, Raumfahrt, Versicherungen, Bankwesen, UNO und WorldBank tätig.
Sven ist Groundbreaker Ambassador (ehem. Oracle Developer Champion) und arbeitete als Developer-Advocate für JFrog und Vaadin. Er spricht regelmäßig auf Konferenzen weltweit und schreibt für IT-Zeitschriften sowie Tech-Portalen.Von ClickUp zu Vaadin – Teil II
Der zweite Teil setzt das Modell aus Teil I in eine Vaadin-Anwendung mit EclipseStore und eingebettetem Jetty um und überführt den ClickUp-Bestand per Import. Der Werkstattbericht zeigt Redaktionstafel, browserlose Tests und eine Bilanz, die auch das Misslungene benennt.
Von Clickup zu Vaadin – Teil I
Warum ein über Jahre gewachsener ClickUp-Bestand einer eigenen Vaadin-Anwendung weichen soll und wie aus einem überladenen Statusfeld drei unabhängige Dimensionen werden. Der erste Teil führt von der Bestandsaufnahme über das gehärtete Modell bis zum Entwurf von sieben Ansichten.
Vaadin 25.2 und der Stellenwert sicherer Voreinstellungen
Vaadin 25.2 härtet sicherheitsrelevante Voreinstellungen: URL-Schema-Prüfung, HTML-Bereinigung per Safelist, X-Frame-Options als Standard und eine Karenzzeit für npm-Pakete. Der Beitrag ordnet die Neuerungen in das Sicherheitsmodell von Flow ein und nennt die Folgen für das Upgrade.
Die Vaadin-Oberfläche des Rezeptassistenten — Teil 2: Die Schritt-für-Schritt-Ansicht
Der zweite Teil der Reihe zeigt die Schritt-für-Schritt-Ansicht des Rezeptassistenten, die die MCP-Werkzeugschleife in einzeln auslösbare Phasen zerlegt. Der Leser erfährt, wie gemeinsamer Motor, wachsende Kartenspur, parallele Werkzeugaufrufe und Streaming in Vaadin Flow umgesetzt sind.
MCP-Server: Die Vaadin-Oberfläche des Rezeptassistenten — Teil 1
Der Beitrag zeigt die Vaadin-Oberfläche, die Antworten desselben Sprachmodells ohne und mit MCP-Server parallel nebeneinanderstellt. Behandelt werden der Start ohne Starter, virtuelle Threads, Streaming per @Push und UI.access, Markdown-Rendering und die sichtbare Protokoll-Zeitleiste.
Sichere SBOMs teilen, ohne zu viel zu verraten
Eine vollständige SBOM ist Nachweis und Bauplan zugleich und verrät Versionsstände, Abhängigkeiten und Angriffsflächen. Der Beitrag zeigt, wie Least Disclosure, empfängerbezogene Sichten, Schwärzung, Zugriffskontrolle und Release-Bindung SBOMs teilbar machen, ohne zu viel preiszugeben.
Eine CalDAV-Testbench für die testgetriebene Entwicklung — Teil 2: Die Test-Support-Schnittstelle in der Praxis
Der Beitrag zeigt die Einbindung der CalDAV-Testbench als Maven-Abhängigkeit, erste Tests mit CalDavFixture und CalDavExtension sowie strukturierte Zusicherungen. Fester Clock, ETag-Startwert und Wiederkehr-Obergrenze machen Tests deterministisch; Fehlerfälle und Zustandsinspektion ergänzen das Bild.
Eine CalDAV-Testbench für die testgetriebene Entwicklung — Teil 1: Vom Problem zum Prüfstand
Echte CalDAV-Server erschweren reproduzierbare Tests durch Altbestände, Netzlatenz, fortlaufende Zeit und Wiederkehrentfaltung. Der Beitrag begründet, warum ein Prüfstand kein verkleinerter Server ist, welchen Ausschnitt von RFC 4791 er abdeckt und wie er als ausführbare Dokumentation dient.
Vaadin Security, Teil 4.3 – Bootstrap des ersten Administrators: vier Adapter, eine SetupView (zweimal) und Bilanz
REST-Endpunkt, CLI-Subkommando init-admin und zwei Vaadin-SetupViews nutzen denselben InitialAdminBootstrapService; die beiden Views unterscheiden sich in einer Codezeile. Die Bilanz benennt, was die Architektur leistet und kostet und was Teil 5 aufgreift.
Vaadin Security, Teil 4.2 – Bootstrap des ersten Administrators: Token-Mechanik, PasswordHasher und Speicher-Verträge
Der Beitrag erklärt die drei Modi des Bootstrap-Tokens und seinen Lebenszyklus vom Serverstart bis zur Invalidierung. Hinzu kommen der PasswordHasher mit PBKDF2-HMAC-SHA256, die durchgehende char[]-Disziplin und der AdministratorAccountStore-Vertrag mit zwei Implementierungen.