Custom protocol mapper zur Anpassung des Keycloak JWT Tokens

Per Default schreibt Keycloak viele Dinge in den JWT token, wie zum Beispiel den bevorzugten Benutzernamen. Wenn das nicht genug ist, gibt es viele bereits eingebaute so genannte protocol mappers mit denen der JWT token, erzeugt von Keycloak,  noch mehr angepasst werden kann. Manchmal sind die eingebauten protocol mappers nicht genug. In diesem Fall können selbstgeschriebene protocol mapper Keycloak hinzugefügt werden. Ich habe hierfür eine Beispielprojekt bei github erstellt.

Leichgewichtige Architekturvalidierung mit ArchUnit

In meinem vergangenen Projekt mit mehreren zehntausend Zeilen Code fand ich jQAssistant gut, um einen Überblick über den Code zu bekommen und Architekturregeln einfach zu validieren. Siehe dazu auch meinen vorherigen Blogpost.

Aktuell arbeite ich in einem Projekt, das vor zwei Jahren auf der grünen Wiese gestartet ist. Dieses besteht aus mehreren Mikroservices und einem Angular Frontend. Nun ist es allerdings so, dass bei einem unser wichtigen größeren Services (ca. 7000 LOC), in dem sehr viel Fachlichkeit steckt, mir immer häufiger Verletzungen unserer hexagonalen Architektur aufgefallen sind – bspw. Zugriffe von Domänen Klassen auf Klassen des REST Ports.  Dabei handelte es sich häufig um Flüchtigkeitsfehler. Die Setupkosten von jQAssistant waren mir bisher für diese kleinen Services zu hoch. Daher habe ich nach einer „leichgewichtigen“ Alternative gesucht mit der ich des Wildwuchses Herr werden konnte und bin dann bei ArchUnit fündig geworden.

Weiterlesen

Nie wieder mühsam Code nach Mustern durchsuchen

Letztes Jahr habe ich den empfehlenswerten Steering Agile Architecture Kurs von Tudor Girba bei it-agile besucht. Der Aha-Effekt in diesem Kurs kam für mich, als es hieß, die gängige Vorgehensweise bei der Softwareentwicklung sei auf dem Stand der Technik von 1939. Damals wurden vier Millionen Fahrkarten unter immensen Kosten von Hand analysiert, um die Weiterentwicklung des Londoner U-Bahn-Systems zu steuern. Heute würde man dieselben Informationen innerhalb von Sekunden von Servern berechnet bekommen. Laut Tudor Girbas These ähnelte die aktuelle Vorgehensweise in der Softwareentwicklung sehr dem Zählen der Fahrscheine 1939. Um die Gemeinsamkeiten und mögliche Gegenmaßnahmen soll es in diesem Blog Beitrag gehen.

Weiterlesen

Voice user interface design mit Amazon Alexa

Ich war kürzlich auf einem von Amazon veranstalteten ganztägigen Workshop zum Thema Alexa hier in Hamburg und vorher auch schon mal bei einem Meetup der AWS User Group zu demselben Thema. Die Quintessenz aus beiden ist, dass die Prinzipien nach denen ein Voice User Interface (bspw. mit Alexa) entwickelt werden sollte, grundlegend von den Prinzipien nach dem bspw. eine Weboberfläche designed wird, abweicht. Eine Weboberfläche eins zu eins in eine Voice UI zu übersetzen, funktioniert nicht. Um einige dieser grundlegenden Prinzipien soll es im Folgenden gehen.

Weiterlesen

Hypermedia Links einer REST API in einem Client als ID nutzen

Schreibt man einen HTML Client für einen REST Api, so stellt sich die Frage, wie man die Urls des HTML Clients aufbaut. Auch die Url im HTML Client sollte dabei eindeutig zu einer Resource passen, damit man den Links auf die Seite des HTML Clients verschicken kann. Man muss also aus der Url des HTML Clients geschickt die Url der REST Api ableiten können. Darum soll es im Folgenden gehen.

Weiterlesen

Integration von Self-Contained Systems

Um das Frontend mehrerer Self-Contained Systems auf einer Seite zu integrieren, gibt es verschiedene Strategien. Im April war ich bei einem ganz interessanten Meetup der Java User Group Hamburg zu dem Thema „VueJS und Microservices für myhermes“. In diesem haben die Entwickler von Hermes vorgestellt, was für Probleme sie hatten und wie sie die mit ihrer neuen Self-Contained Systems Architektur gelöst haben die demnächst produktiv gehen und ihr monolithisches Altsystem ablösen soll. Interessant fand ich dabei, wie sie die Frontends verschiedener Self-Contained Systems auf einer Seite integrieren.

Weiterlesen

BDD UI Tests mit Serenity und JBehave

In meinem aktuellen Projekt schreiben wir die UI Tests als BDD Tests, da diese eher dazu führen, dass man fachliche Tests schreibt. Dazu verwenden wir Serenity zusammen mit JBehave.  Serenity verwendet dabei unter der Haube Selenium für die Browserautomatisierung. Dabei haben wir in meinem Team einen längeren Leidensweg hinter uns da zwischenzeitlich die Tests so schwer zu warten waren, dass wir mit dem Gedanken gespielt haben, die ganzen BDD /JBehave Tests wegzuschmeißen und durch reine Java Tests zu ersetzen. Letztendlich sind wir aber nach langer Zeit (dank Beratung eines anderen Teams) nun endlich bei einer Lösung angekommen, wo alles zusammenpasst und wir nun sehr zufrieden mit unseren UI Tests sind. Darum soll es in diesem Artikel gehen.  Weiterlesen

Klar formulierte Tests

In der Vergangenheit habe ich häufig Tests gesehen (und auch selber geschrieben), die schwer zu warten waren, da sie nicht klar formuliert waren. Nehmen wir beispielsweise folgenden (zugegebenermaßen noch recht einfachen) Test als Beispiel:

Der obige Test drückt sich nicht klar aus.  Dadurch könnten selbst bei einem so einfachen Test folgende Fragen bei dem Leser des Tests aufkommen:

  • Auf Grund des Namens DOOR2DOOR_BOOKING könnte sich der Leser fragen, warum ein Door to Door Booking benötigt wird, damit das Feld totalWeight konvertiert werden kann.
  • Wenn sich der Leser die Initialisierung von DOOR2DOOR_BOOKING ansieht, könnte er ziemlich verwirrt werden, da dieses Objekt auch noch von anderen Tests verwendet wird, die andere Felder von DOOR2DOOR_BOOKING  wie bspw. das Feld incoterm benötigen. Er muss daher recherchieren, welche dieser Felder für den Test wichtig sind. Es könnte bspw. sein, dass das Feld totalWeight nur in bestimmten Fällen kopiert wird. Das ist schwer offensichtlich wenn die wichtigen Felder, die für den Test gesetzt sein müssen, in der Masse der für den Test unwichtigen Felder (wie bspw. incoterm), untergeht.
  • Da das Objekt, das auf DOOR2DOOR_BOOKING zugewiesen wurde, von mehreren Tests verwendet wird, müsste man prüfen, ob es immutable ist. Wenn nein, so könnte es von anderen Tests verändert werden, was zu instabilen Tests führen kann und zusätzlich verwirrt.
  • Auch würde er sich vielleicht fragen, ob der Test überhaupt etwas testet, da der Test auch durchlaufen würde, wenn das Feld totalWeight sowohl in actual als auch in DOOR2DOOR_BOOKING null wären.

Für viele dieser Fragen würde man Vermutungen anstellen. Ich würde beispielsweise vermuten, dass das Feld einfach (unabhängig von irgendwelchen anderen Feldern) kopiert wird. Auch würde ich vermuten, dass das Feld totalWeight mit einem Wert initialisiert ist und somit auch durch die Zeile assertThat(actual.getTotalWeight()).isEqualTo(DOOR2DOOR_BOOKING.getTotalWeight()) auch wirklich geprüft wird, dass ein Wert kopiert wird. Eventuell wird der Leser sogar in den Code abtauchen, um seine Vermutungen zu verifizieren. Das ist schlecht, denn eigentlich möchte man nicht, dass sich der Leser unnötige Fragen stellt. Stattdessen sollte jeder Test für den Leser offensichtlich sein. Er sollte die Tests einer Klasse überfliegen und sehr schnell darüber erfassen können, wie eine Klasse funktioniert.

Schreibt man den Test nun ein wenig um, so kommuniziert der Test deutlich klarer, was wichtig ist:

Der Leser sieht hier sofort, dass wir nur irgendein Booking benötigen, bei dem das Feld totalWeight gefüllt ist. Dieses kommuniziert das Builder Pattern someBooking().withTotalWeight(weight).build(). Die Methode someBooking() baut irgendein Booking zusammen, so dass der Aufruf der Methode createPackageDetails(booking) nicht zu einer Exception führt. Danach werden dann die Felder überschrieben, die für unseren Test wichtig sind. Im obigen Fall wird lediglich das Feld totalWeight im Booking gesetzt. Damit wird an den Leser kommuniziert, dass nur dieses eine Feld für den Test wichtig ist. Er sieht also auf den ersten Blick, dass dieses eine Feld in diesem Test lediglich kopiert wird. Auch ist nun klar, dass das booking.totalWeight ungleich null ist und somit auch wirklich kopiert wird. Weiter erzeugt sich nun jeder Test ein neues Booking-Objekt so dass kein anderer Test es verschmutzen kann selbst wenn es mutable ist.

Das war nun noch eine ziemlich einfache Methode, die nur ein Feld kopiert. Wird die Methode die getestet wird und der zugehörige Tests komplizierter, ist es noch wichtiger drauf zu achten, dass der Test verständlich ausgedrückt ist. Ansonsten muss man später bei Anpassungen am Produktionscode zusätzliche Zeit aufwenden, um überhaupt erst einmal die Tests zu verstehen und zu refaktorisieren.

Jira Command-Line Client

Neuerdings verwenden wir in meinem Team ein physikalisches Kanban Board. Trotzdem haben wir noch ein Jira für folgende Dinge:

  • Zu Dokumentationszwecken. Dafür beinhaltet die Commit Message die Jira Ticketnummer. Stolpert ein Entwickler über eine Codestelle, kann er über die Commit ID das zugehörige Jira Ticket öffnen und sich somit Hintergrundinformationen besorgen.
  • Pflegen von Zeitaufwänden zur Abrechnung.
  • Unsere Continous Deployment Pipeline verwendet bspw. die Jira Tickets. So setzt diese nach dem Produktionsdeployment einen Status so dass sich unser Support über einen Jira Filter immer ansehen kann, welche Tickets zuletzt auf Produktion ausgerollt wurden. Auch führt diese ein Produktionsdeployment nur durch, wenn alle Tickets, die neu auf Produktion ausgerollt werden würden, abgenommen wurden und sich somit im richtigem Status befinden.

Auch mit physikalischem Board brauchen wir das Jira also noch. Glücklicherweise nicht mehr so häufig. Trotzdem muss man manchmal ein Ticket kommentieren oder den Status eines Tickets ändern. Das ist zumindest in meiner Firma recht umständlich da ich häufig ausgeloggt werde und der Webclient sehr langsam ist sowie man viel klicken muss. Nun bin ich durch einen Kollegen auf den Jira Command-Line Client von Netflix aufmerksam gemacht worden, mit dem sich Jira mit ein bisschen Bash Magic sehr bequem aus der Kommandozeile heraus bedienen lässt – unter Windows benutze ich übrigens Cmder inkl. Git als Kommandozeile.

Beispielweise kann man sich ein Jira Ticket über jira view <Ticketnummer> direkt in der Kommandozeile ansehen. Über jira take <Ticketnummer> kann man das Ticket sich selber zuweisen. Das funktioniert gut. Nun ist es allerdings so, dass wir bei uns in der Abteilung die Namenskonvention haben, dass die Jira Ticketnummer Bestandteil des aktuellen git branches ist (topic/<Ticketnummer>). Der zum Ticket KNFN-8918 gehörige Branch hat bspw. den Namen topic/KNFN-8918. Ist man also gerade in dem Projektordner, kann man sich über den folgenden git Befehl die Jira Ticketnummer aus dem Branchnamen parsen:

git rev-parse --abbrev-ref HEAD | sed -e "s|.*/||"

Nun habe ich mir folgende Aliase in meiner .bashrc angelegt:

Dadurch muss ich für die Befehle, die ich häufig benutze, die Jira Ticketnummer nicht mehr eingeben sondern sie wird automatisch aus dem aktuellen Git Branchnamen geparst. Gibt man bspw. jira_view_issue ein, so wird das Ticket zum aktuellen Branch in der Kommandozeile angezeigt:

Insgesamt bin ich recht begeistert von dem Jira Command-Line Client von Netflix. Er ist extrem schnell und ich muss nicht mehr so häufig den langsamen Web-Client bedienen. Außerdem ist dank Cmder (im Quake Modus) unter Windows die Kommandozeile nur eine Tastenkombination entfernt, so dass man schnell nur mit Tastenkombinationen zwischen IDE und Kommandozeile wechseln kann.

Ein paar kleine Kinderkrankheiten hat es zwar noch. So hat der Client beispielsweise aktuell Probleme mit unserem Firmenproxy. Dieses umgehe ich aber so, dass ich in dem Tab der Bash, in dem ich mit dem Jira interagiere, den Proxy per Bash Funktion ausstelle. Auch muss man aktuell (Version 4.0) manuell noch ein .jira.d Verzeichnis im Home-Verzeichnis anlegen da es ansonsten zu einem Fehler kommt da der Client keine cookies.js Datei anlegen kann. Rein grundsätzlich kann ich das Projekt nur empfehlen.

Troubleshooting von Spring MVC

Letztens hatten wir auf der Arbeit einen Fall wo nicht klar war, warum ein Request nicht beim Spring MVC Controller ankam. Die Ursache kann bei solchen Problemen normalerweise recht schnell gefunden werden, in dem man das DispatcherServlet von Spring debugged. Dazu am besten einen Breakpoint in dessen doDispatch Methode setzen und den Request danach erneut ausführen. Die Methode ist verständlich und man erkennt beim schrittweisen Ausführen der Methode normalerweise recht schnell, warum ein Request nicht wie erwartet verarbeitet wird. Häufig findet man bei genauere Betrachtung der getHandler Methode des Spring DispatcherServlets, die von der doDispatch Methode aufgerufen wird,  den Übeltäter:

Spring DispatcherServlet getHandler method

In dieser wird eine Liste von Handlermappings durchlaufen um zu prüfen, ob der aktuelle Request auf eines davon passt. Wird eine mit @RequestMapping annotierte Methode nicht aufgerufen, lohnt es sich bspw. bis zum Aufruf des RequestMappingHandlerMappings vorzulaufen und dann  zu debuggen, was diese für Mappings beinhaltet und warum keines davon auf den aktuellen Request passt. Ist man hier immer noch ratlos, vergleicht man es am besten noch mit einem Request, der erfolgreich aufgelöst werden kann.

Durch diese Vorgehensweise kann man häufig recht schnell die Lösung finden wenn man alles offensichtliche, wie bspw. falsche Pfade oder falsche Http Methode, schon geprüft hat.