JAX 2015

15.05.2015 16:28

von Florian Mutter

Am 21.04.2015 und 22.04.2015 waren wir für exensio zu zweit auf der JAX 2015 in Mainz. Die Konferenz bot viele gute Vorträge zu einem breiten Themen-Spektrum. Besonders im Mittelpunkt standen in diesem Jahr die Themen Microservices, die Neuerungen in Java 8, JavaFX, sowie die Integration von Java EE 7 mit modernen HTML5-Frontends. Hier folgt ein kurzer Überblick, über einige der Vorträge, die wir angehört haben.

Java-EE-7-Architekturen auf Java 8 werden zu Microservices

Der erste Vortrag, den wir uns angeschaut haben, war von Adam Bien zum Theme Microservices. Neben einer Einführung zu Microservices mit allerlei Beispielen war seine Kernaussage: Microservices sollten nicht eingesetzt werden, wenn es nicht unbedingt nötig ist. Es gibt Beispiele wo es Sinn machen kann, in vielen Fällen wird jedoch nur die Komplexität erhöht ohne eine echten Vorteil zu bringen.

Ganz im Stil vieler seiner Vorträge hat er auch diesen mit einer kleinen aber sehr unterhaltsamen Live-Coding-Session abgeschlossen.

Java-Concurrency für Fortgeschrittene

Arno Haase hat einen hervorragenden Einblick in das Thema Concurrency mit Java gegeben. Dabei hat er das Thema eher von einer High-Level-Perspektive beleuchtet und auf häufige Fehler und Probleme hingewiesen. So sollte man etwa bei der Verwendung von synchronized-Blöcken auf Deadlocks gefasst sein, oder den common ForkJoinPool nicht mit wartenden IO-Aufgaben blockieren, da dadurch alle anderen Tätigkeiten in diesem Pool zum Erliegen kommen. Einen möglichen Lösungsansatz, um generell seiteneffektfrei und damit threadsicher zu programmieren, sieht Arno darin, auf funktionale Programmierung zu setzen.
Für Performance-Tuning im Allgemeinen gilt außerdem: erst genau Testen, dann sehr selektiv optimieren. Dabei hilft auch ein sauberes Design mit eher kurzen Methoden.

Typensysteme für JavaScript

Oliver Zeigermann hat eine Übersicht zu Typensystemen für Javascript gegeben. Der Trend ist hier eindeutig zu Typensystem hin. So wird z.B. AngularJS 2 auf Microsoft's TypeScript aufbauen und die JavaScript Engine V8 von Chrome bekommt einen experimentellen Modus für typisiertes JavaScript. TypeScript scheint inzwischen das Typensystem der Wahl zu sein. Wobei der Newcomer Flow von Facebook einige Interessante Funktionen bietet, die inzwischen sogar von TypeScript übernommen wurde.

JavaScript-Webframeworks

Zu JavaScript-Webframeworks hat Oliver Zeigermann ebenfalls einen unterhaltsamen Vortrag gehalten. An kurzen Codebeispielen hat er JQuery, Backbone.js, AngularJS und React verglichen. Da AngularJS 2 völlig neu entwickelt wird und zu AngularJS 1 inkompatibel ist, ist hier Vorsicht geboten bei Einsatz der alten Version. Da immer mehr Logik vom Backend in den Browser wandert, Sein eigenes nächstes Projekt würde @djcordhose am liebsten mit React umsetzen, dem er einige glorreiche Jahre voraus sagt.

Na klar muss alles "gestern" fertig sein, wann denn sonst?

Der letzte Vortrag des Tages war von Matthias Bohlen. Der Einstieg war mit einigen Star Trek Referenzen direkt gut gelungen. Die Hauptthese war, dass man versuchen soll, die Zeiten zu messen, die für Tickets benötigt werden und auf diesen Daten dann Schätzungen abgeben und dabei eine Wahrscheinlichkeit angeben, mit der diese Schätzung stimmt. Das könnte sich zum Beispiel so anhören: "Wir sind zu 87% in 30 Tagen mit diesem Feature fertig." Eine weitere Empfehlung war der Einsatz von Kanban Boards mit strengen Limits, so dass keine Bottelnecks entstehen, weil ein Team viele Tickets abarbeitet, ein anderes aber nicht hinterher kommt. Generell gilt es Stress zu vermeiden. Bei der Umsetzung dieser Vorschläge kommt es, wie vermutlich überall, auf die jeweilige Situation in einer Firma an.

Vom Wiegen allein wird die Sau nicht fett - von Qualitätsanalyse zu wirksamer Qualitätsverbesserung

Elmar Jürgens von der CQSE GmbH gab Tipps und Tricks zum Thema Verbesserung der Code-Qualität. Die Grundaussage aus dem Titel ist natürlich, vom Erfassen von Qualitätsmetriken wird der Code nicht besser. Aber wie dann? Elmar schlägt vor, dass man „Findings“, also Meldungen von Qualitätsanalyse-Werkzeugen, wie Findbugs, Teamscale, oder SonarQube, zunächst nach Alter sortiert. Dann können sich Entwickler um die Neuesten kümmern, bei denen das Gedächtnis an den Code noch relativ frisch ist. Alternativ oder zusätzlich kann man nur die gravierendsten Meldungen aktivieren, damit die Entwickler nicht von der Zahl erschlagen werden. Elmar und seine Kollegen haben festgestellt, dass es im Projektalltag nicht möglich ist, in einem gewachsenen Projekt im Nachhinein tausende von Findings zu beheben. Darum postulieren sie zwei alternative Vorgehensweisen:

Keine neuen Probleme. Die Zahl der Probleme stagniert also, aber es dürfen keine neuen eingeführt werden.
Keine Findings in geändertem Code. Der Entwickler der eine Änderung an bestehendem Code vornimmt, muss diesen gleich mit von bestehenden Defiziten befreien. Dabei ist es wichtig, den Scope richtig zu definieren. Wenn man diesen zu groß wählt, führt es eher dazu, dass niemand mehr bestehenden Code anfasst und stattdessen Workarounds programmiert. In Projekten mit kleinen Klassen, kann der Scope daher ruhig auf Klassenebene liegen. Bei vielen tausende Zeilen langen Klassen, sollte man diesen eher auf Methoden einschränken.

Zum Thema Code-Reviews meint Elmar: manuelle Reviews ohne vorherige maschinelle statische Analyse sind vertane Zeit und vergleicht es mit einem Autor, der dem Redakteur einen Text gibt, ohne eine Rechtschreibprüfung auszuführen.

Reaktive Geschäftsanwendungen

Der zweite Vortrag von Arno Haase, den wir uns angeschaut haben, behandelte Möglichkeiten, wie man reaktive Geschäftsanwendungen umsetzen kann. Einzelne, von Anfang bis Ende transaktionale Anfragen können in asynchronen Aufrufen umgewandelt werden um eine schneller Reaktion an der Benutzeroberfläche zu ermöglichen. Wenn eine Anfrage mehrere Berechnungsschritte benötigt, können diese dann parallelisiert werden.
Besonders beachtet werden muss die Fehlerbehandlung. Es sollten immer Timouts definiert werden um einen Absturz oder ähnliches zu erkennen.
Es wurde außerdem auf das "Reactive Manifesto" hingewiesen, dass die wesentlichen Eigenschaften eines reaktiven Systems beschreibt.
Das Fazit des Vortrags war: Es gibt viele Fälle, wo reaktive System glänzen können, aber man erhält die Vorteile nicht ohne, dass man sich Nachteile wie höhere Komplexität einfängt.

Mut zur Fachlichkeit – Second Season

Lars Röwekamp ging in diesem Vortrag auf das Problem ein, dass Code heute häufig "unfachlich" ist. Er meint damit, dass z.B. in Domain-Klassen nur Attribute, getter und setter sind, aber fachlich eigentlich setNachname keinen Sinn macht. Der Nachname kann sich z.B. nur ändern, also müsste es hier changeNachname heißen. Außerdem kann der Nachname sich nur bei einer Heirat ändern, also müsste es hier keinen Setter geben, sondern eine Methode "married". Weiter Punkte waren, dass das Domain-Model selbst dafür sorgen soll, dass es immer in einem validen Zustand ist. Nicht nur beim Speichern in der Datenbank. Hier kann das Builder-Pattern eingesetzt werden um nicht-valide Zustände im Domain-Model zu vermeiden. Weitere Maßnahmen zu mehr Fachlichkeit, die vorgestellt wurden, sind Rich Entities, Aggregates und Bounded Context.

Die Erkenntnis des Tags, die man mitnehmen sollte ist:

Muss ich denn den Code ändern, wenn sich die Fachlichkeit ändert?
Zur Hölle, ja! Wann denn bitte sonst?

Zurück