Learnings vom Java Forum Stuttgart 2023

Wie letztes Jahr waren wir wieder beim Java Forum Stuttgart.

Diesmal war die JSE  mit fünf Mitarbeitern auf der Konferenz vertreten.

Das waren unsere wichtigsten Erkenntnisse:

Allgemein:

Das Java Forum Stuttgart ist jedes mal wieder ein grandioses Community Event. Man kann der Java User Group Stuttgart nur ein absolutes Lob für die mega Organisation aussprechen. Respekt das ein gemeinnütziger Verein ein Event mit 7 parallelen  Tracks und fast 2000 Teilnehmern, so professionell durchzieht!

Networking:

Der Austausch unter Experten auf der Messe ist jedes mal wieder super.  Wer schon eine Weile in der Branche ist trifft auch immer wieder bekannte Gesichter und es findet sich Zeit zum fachsimpeln. Wer einen Job als Software Entwickler sucht ist auf dem Java Forum auf jeden Fall an der richtigen Adresse. Wer nicht bis zum Java Forum 2024 warten will kann auch mal auf unsere Karriereseite schauen.

Learnings von Adrian:

Keep it simple? My Ass! und You ain’t gonna need it

• Die immer komplexer werdenden Softwareentwicklungsprojekte und der steigende Trend zur Nutzung einer Vielzahl von Technologien und Microservices haben mehrere Gründe. Einerseits besteht der Druck, mit den neuesten technologischen Innovationen Schritt zu halten. Unternehmen und Entwickler streben danach, am Puls der Zeit zu sein und die neuesten, effizientesten Technologien zu nutzen, um Wettbewerbsvorteile zu erzielen.
• Ein psychologischer Aspekt ist ebenfalls beteiligt. Viele Entwickler wollen ihr Wissen und ihre Fähigkeiten in verschiedenen Technologien erweitern, um ihre Karrierechancen zu verbessern. Ein Lebenslauf, der eine Vielzahl von Technologien und Fähigkeiten zeigt, kann für potenzielle Arbeitgeber attraktiv sein.
• Der Trend zur Microservices-Architektur resultiert aus dem Versuch, Systeme skalierbar, flexibel und fehlertolerant zu gestalten. Jeder Microservice ist für eine spezifische Funktion verantwortlich, was die Wartung und Aktualisierung erleichtert. Allerdings führt dies oft zu zusätzlicher Komplexität, da nun zahlreiche Dienste koordiniert und verwaltet werden müssen.
• Die Alternativen könnten in einer stärkeren Standardisierung und einer konsequenteren Nutzung von Monolithen liegen, in denen alle Funktionen in einer einzigen Anwendung gebündelt sind. Dies reduziert die Notwendigkeit der Verwaltung mehrerer Dienste und kann den Entwicklungsprozess vereinfachen.
• Eine Vereinfachung der Softwareentwicklung könnte zahlreiche Vorteile bringen. Einfachere Systeme sind in der Regel leichter zu verstehen, zu warten und zu verbessern. Sie könnten auch die Produktivität der Entwickler steigern, da weniger Zeit für das Erlernen und Verwalten verschiedener Technologien und Dienste aufgewendet werden muss. Einfachere Systeme könnten auch weniger anfällig für Fehler sein und eine stabilere, zuverlässigere Leistung bieten.
• Die Vorteile der Einfachheit sind nicht nur auf die Softwareentwicklung beschränkt. Ob es um das Kochen, Sporttraining, Finanzmanagement, Innenarchitektur oder Kommunikation geht - in all diesen Bereichen führt Einfachheit oft zu besseren Ergebnissen, indem sie die Klarheit erhöht und Fehler minimiert.

Zusammenfassend lässt sich sagen, dass die Komplexität der Softwareentwicklung durch technologischen Druck, Karriereanreize und Bestrebungen nach Flexibilität und Skalierbarkeit vorangetrieben wird. Während die Nutzung von mehreren Technologien und Microservices ihre Vorteile hat, könnten Alternativen wie die Standardisierung und Nutzung monolithischer Architekturen zu einfacheren, effizienteren und stabileren Systemen führen.

Die Einfachheit sollte dabei immer ein Ziel bleiben, um die Effizienz und das Verständnis zu verbessern, Fehler zu reduzieren und das Gesamtergebnis zu optimieren.

Learnings von Lukas:

WSL-2: Der Warp-Antrieb für Windows-Entwickler

Als Software-Entwickler auf dem Windows Betriebssystem hatte ich bisher schon öfters die Erfahrung, dass Teamkollegen, die im selben Projekt am selben Code aber auf MacOS oder Linux arbeiten, sehr viel schnellere Kompilierzeiten haben. Einer der Hauptgründe, warum dies so ist, liegt an der unterschiedlichen Dateisystemleistung: Windows verwendet das NTFS-Dateisystem, welches nicht so effizient ist wie ext4. Dies führt unter anderem dazu, dass Dateizugriffe unter Windows langsamer sind und sich somit auf die Kompiliergeschwindigkeit auswirken.

Aber warum dann nicht einfach auf MacOS oder Linux umsteigen? Das wäre möglich, aber auch aufwendig und möglicherweise kostspielig. Da gäbe es dann auch noch die Möglichkeit in einer VM (Virtuelle Maschine) das Betriebssystem der Wahl zu installieren und einfach dort zu entwickeln, dies ist aber alles andere als performant.

Mirko Pleli von der Firma Sybit hat hier eine sehr gute Lösung für dieses Problem vorgestellt: Das WSL-2 (Windows Subsystem for Linux) in der Version 2. Ganz nach dem Motto: „Unter Windows entwickeln und unter Unix kompilieren.“

Doch was bedeutet dies alles jetzt in Zahlen? Hier hat Mirko Pleli eine klare Antwort darauf:

Anhand der Tabelle wird deutlich, wie stark der Performanceunterschied wirklich ist und wie sehr sich die Wartezeiten auf weniger als die Hälfte verkürzen lassen.

Wie genau das zu bewerkstelligen ist hat er uns in seinem knapp 45-minütigen Vortrag auch anhand einer Live-Demo gezeigt. Mit nur wenig Aufwand und out-of-the-box lässt sich ein Linux Betriebssystem direkt in Windows unter dem WSL-2 aufsetzen und man kann in wenigen Minuten loslegen. So wird konkret gesagt der ganze Source Code und die Entwicklungsumgebung in dem performanten ext4 Dateisystem eingerichtet und man kann ohne Mühen in Windows mit seiner IDE darauf zugreifen. So kann beispielsweise eine Plattform wie Java oder NodeJS direkt mit beiden Systemen geteilt werden, ohne sie erneut installieren zu müssen.

Es gibt auch die Möglichkeit seine IDE in dem WSL-2 unterzubringen und mit der grafischen Oberfläche von dort zu arbeiten, dies ist aber derzeit nur mit einem nicht nativ eingebundenem Windows Fenster möglich welches man von Hand in der Größe ändern muss.

Alle Infos und eine detaillierte Anleitung wie man das WSL-2 aufsetzt und seine Entwicklungsumgebung mit wenig Aufwand einrichten kann hat uns die Firma Sybit in diesem GitHub Repository zur Verfügung.

Learnings von Marcel:

You ain’t gonna need it! (YAGNI)

In der heutigen Zeit wird oft alles Mögliche an Frameworks und Software verwendet. Angefangen bei Angular über Gateways bis hin zu Kafka-Cluster und vielen Services die in der Cloud liegen.

• Doch macht dies immer Sinn?
• Braucht man immer alles an Technologien?
• Benötigt man zwingend 20 verschiedene Service, obwohl die Hoheit bei einem Team liegt?

Oftmals benötigen wir 30 Entwickler, um eine Software in solchen Größen überhaupt zu stemmen Und das obwohl auf der anderen Seite nur 3 User die Software verwenden müssen.

• Ist deswegen nicht manchmal weniger einfach mehr?
• Muss ich als Entwickler alles können und kennen, nur weil es gerade Mode ist?

Neu und groß ist nicht unbedingt schlecht. Aber man sollte nur das verwenden, was man wirklich benötigt. Und nicht, was man benötigen möchte. Das macht die Software einfacher, verständlicher und leichter zu warten. Auch wenn es manchmal schwer fällt Keep it simple, stupid.

Learnings von Chris:

Keine Angst vor dem Endgegner: Verbesserungsideen dem Management (besser) erklären

Die Kommunikation mit Kunden und Stakeholdern ist ein essentieller Bestandteil unserer Arbeit, welcher ein Make-Or-Break Kriterium für ein produktives, inspirierendes Arbeitsumfeld sein kann. Wir haben oftmals Wünsche und Anregungen, geniale Ideen oder Frustfaktoren, die wir gerne kommunizieren möchten; doch vor allem wir als Entwickler können leicht in die "Fisch-Wasser" Falle tappen: Wir arbeiten in einem sehr spezifischen Umfeld, das für außenstehende im Detail nur schwer zu überblicken ist. Kurz gesagt: Uns fällt der Ozean nicht auf, da wir täglich darin schwimmen. Dies ist ein Aspekt, den wir bei Gesprächen mit dem Kunden oder Management gerne vergessen. Wir sprechen über unsere technischen Frustpunkte, wie beispielsweise den Wunsch nach einer anderen IDE oder eines neuen Frameworks und stoßen dabei immer wieder auf Hürden in der Kommunikation. Aber wie lösen wir diese Problematik?

Wir machen Betroffene zu Beteiligten.

Wenn wir Außenstehenden von unseren Wünschen erzählen oder hilfreiche Anregungen an den Mann bringen wollen, so müssen wir lernen, ihre Sprache zu sprechen. Es nützt uns Nichts von den technologischen Details eines Frameworks zu schwärmen, wenn wir dies im Kontext unserer eigenen Bubble machen. Wenn wir das tun, schaffen wir lediglich Betroffene, welche von den positiven Aspekten unserer Ideen wenig Ahnung haben und somit nur die nötigen Aufwände verstehen.

Schaffen wir es aber, uns in den gedanklichen und sprachlichen Kontext unseres Gegenübers zu versetzen, so können wir es zu einem Beteiligten machen. Ein Beispiel hierfür wäre das Management. Bei Gesprächen dieser Art ist es sinnvoll sich auf Zahlen, Daten und Fakten zu fokussieren, denn das ist ihre Sprache: Das heißt wir benutzen messbare Metriken, um unsere Ideen zu vermitteln.

• Wir sparen Geld
• Wir sparen Zeit
• Wir erhalten neue Kunden

Auf diese Art uns Weise ist nicht nur verständlich, dass wir mit unseren Anliegen im Interesse des Unternehmens handeln, sondern wir holen unsere Gesprächspartner auch ab. 

Es geht also darum eine Gesprächskultur zu schaffen, in welcher jeder ins Boot genommen wird. Wir müssen realisieren, dass wir im Grunde alle am Erfolg unseres Projekts interessiert sind und uns deswegen nicht in unserer Bubble verkriechen können. Durch Klarheit, Fokus und Verständnis in unserer Kommunikation erreichen wir nicht nur die Umsetzung unserer Ideen, sondern halten alle fest an einem Strang und schaffen so reibungsfreie, inspirierende Arbeitsumgebungen.

Learnings von Jens:

Java Records

Da wir in diversen Projekten gerade auf Java 17 umgestiegen sind war die Frage wie wir mit Records in unseren Projekten umgehen.

Nach dem Vortrag kann ich sagen. Wir planen jetzt alle DTO die aktuell Lombok verwenden auf Records umzustellen. Die wichtigsten Erkenntnisse aus dem Vortrag sind:

• Ein Record hat Equals(), toString(), Constructor und Getter out of the Box.
• Die Member sind final und private Variablen sind nicht möglich.
• Der Canonical Constructor kann zur Validierung verwendet werden und wird im Gegensatz, zu einem normalen Constructor, auch bei der Deserialisierung aufgerufen. Was viele Probleme vermeidet!

• Jackson funktioniert auch mit Records.
• Die Lombok Funktionen @Builder und @NotNull funktionieren mit auch Records.

Hier noch ein paar Impression von der Konferenz: