Javaforum 2015

Ein kurzer Rückblick

Kaum hatte das Javaforum begonnen, war’s auch schon wieder vorbei – eine eintägige volle Breitseite an Vorträgen, Gesprächen und verschiedenen Eindrücken. Ich versuche mal festzuhalten, was mir aus meinen Vortragsbesuchen hängengeblieben ist.

Datenversionierung in Business-Anwendungen

Eine Art Versionsverwaltung in der Datenbank - Stände mit Tags fixieren und zwischen Varianten (Branches) wechseln, und das möglichst transparent für den Entwickler, der mit Hibernate als ORM arbeitet. Man kann sich leicht vorstellen, daß das eine eher knifflige Aufgabe ist! Eine universelle Lösung, die dann auch noch performant ist, kann es meiner Meinung nach nicht geben; der vorgestellte Ansatz ist durchaus geschickt und funktioniert für das Anwendungssetting (geringe Zahl von Branches mit wenig Aktivität darauf) auch flott.

Die gezeigte Lösung funktioniert nur in Zusammenspiel mit einer Oracle-Datenbank, über Verfügbarkeit wurde nichts gesagt. Die Idee kann man aber mal im Hinterkopf behalten.

Teile und herrsche - verteilte Javaanwendungen mit Docker

Eine Blitztour quer über Docker. Dockerfiles, Image-Layers, Container anlegen, starten, stoppen, Mounten lokaler Verzeichnisse für Konfiguration und persistente Daten… nicht viel neues für jemanden, der schon mal mit Docker herumgespielt hat. Für alle anderen eine schöne Einführung. IntelliJ hat (im Gegensatz zu Eclipse) Support für Dockerfiles? Muß ich mal ansehen.

Erfreulich: Das Thema „Patchen von Sicherheitsproblemen in Containern“ wurde angesprochen, auch wenn die Referenten dafür offenbar auch noch keine Patentlösung gefunden haben :-) Ansonsten bekommt der Talk von mir den Preis für die Livedemos mit dem coolsten Kommandozeilen-Prompt ;-)

Mach mit Eclipse SmartHome dein Zuhause intelligent

Nach kurzer Einführung eine Demo, wie man mit OpenHAB 2 Geräte einbindet und skriptet. Ich habe OpenHAB 1 vor zwei oder drei Jahren mal angeguckt und ich muß sagen: Wow, da hat sich einiges getan! Insbesondere das automatische Erkennen von Geräten macht sicher vieles einfacher. Das ganze macht richtig Lust auf Ausprobieren.

Im Anschluß hatte ich noch ein Gespräch bezüglich der Sicherheit der diversen Funkprotokolle im Heimautomations-Bereich. Mein letzter Kenntnisstand war, daß quasi alle Protokolle außer Z-Wave bekannte Schwächen haben - und Z-Wave vermutlich nur deshalb noch nichts bekannt ist, weil das proprietäre Protokoll noch nicht reverse-engineert wurde. Im Gespräch meinte der Referenz, daß Zigbee möglicherweise das kleinste Übel ist, das einzige bekannte Problem ist seiner Kenntnis nach ein Insecure Rejoin. Eine kurze Recherche führte diese Vortragsfolien zu Tage - mindestens gibt es wohl noch Replay-Probleme, ansonsten war das der Stand von 2011, unklar, was sich in der Zwischenzeit noch ergeben hat. Ich bleibe mal skeptisch.

Yes we scan! Software-Analysen mit jQAssistant

JQAssistant ist ein Tool, um Java-Artefakte (JARs, aber auch WARs, EARs, sogar Logfiles von Sonar o.ä.) rekursiv zu parsen und Struktur und Information in einer Neo4J-Datenbank abzulegen. Als Eingabe dienen einzelne Dateien, ganze Verzeichnisse oder sogar komplette Maven-Repositories. Auf den Daten kann man dann durch geeignete Queries das Wachsen der Komplexität beurteilen, oder die Einhaltung von Namensregeln, Packagestruktur-Vorgaben oder Architektur-Zugriffs-Constraints überprüfen.

Irgendwie kommen unterschiedliche Leute immer wieder auf ähnliche Ideen, JQAssistant kann vermutlich die Funktionalität von degraph abbilden, und sollten auch Funktionsaufrufe samt Zeilennummern in der Datenbank landen, wäre wohl auch mein Stacktrace Fingerprinting damit umsetzbar. In jedem Fall braucht jedes der drei Programme einen Scanner, der die Struktur von JARs (und beim Stacktrace Fingerprinting die Maven-Abhängigkeiten) parst - vielleicht können sich die Projekte da in irgendeiner Form ergänzen?

Effektiver Einsatz von Code Reviews

Der Vortrag war eine Liste von Empfehlungen und Erfahrungen des Referenten aus etlichen Jahren Code Review:

  • Code Reviews erfordern etwa 15% zusätzliche Zeit zur Entwicklungszeit (dafür sinkt die Zahl der Bugs und der Zeitbedarf für irgendwelche Refactorings, was allerdings sich schwer als Zeitgewinn messen läßt)
  • Code Reviews lohnen sich bei Projekten ab etwa einem Mann-Jahr; bei kleineren Anwendungen oder irgendwelchen Prototypen rentiert sich die zusätzliche Zeit nicht (außer man will hier gezielt Teamplay und Wissensaustausch trainieren).
  • Reviews sollten nach Abschluß jedes Features bzw. Bugfixes durchgeführt werden. In einem solchen Paket sollten maximal drei Tage Entwicklungszeit stecken.
  • Das Review machen der ursprüngliche Autor und ein Reviewer. Hier sollte im Team bunt gemischt werden, es soll „jeder mit jedem“, unabhängig vom Skill-Level.
  • Ein Code Review wird synchron (am selben Rechner oder per Screensharing) durchgeführt. Kontrolle über Tastatur und Maus bekommt der Reviewer, der Autor erläutert und beantwortet Fragen.
  • Ein Codereview sollte maximal 300 - 400 Zeilen Code betrachten und nicht länger als 1 - 2 Stunden dauern.
  • Sinnvoll ist das Protokollieren der Review-Ergebnisse: Welches Ticket bzw. welcher Feature-Branch wurde behandelt, wer waren Autor und Reviewer, wie lange waren Implementierungs- und Reviewzeit, wieviel Zeit wurde für die Nachbereitung aufgebracht, wie viele LOC hatte die Änderung, wieviele Bugs/Verbesserungen wurden eingebracht. Sehr hilfreich, um den Aufwand zu rechtfertigen, wenn man die zusätzlich investierte Zeit gegen die Anzahl der gefunden Bugs aufrechnet.
  • Ein Team sollte sich eine Checkliste geben, auf was bei Codereviews geachtet wird. Das strukturiert das Vorgehen und erlaubt es dem Programmierer, schon bei der Entwicklung geeignet vorzuarbeiten.
  • Review-Tools sind absolut zweitrangig! In erster Linie wird eine saubere diff-Anzeige benötigt. Viel wichtiger ist eine gute Continuous-Integration-Pipeline, welche im Vorfeld schon prüft, ob der Code kompiliert, alles Tests ok sind, Style-Richtlinien eingehalten wurden, etc.

Hack that website!

Mein Vortrag (Folien hier) fand im propper gefüllten Beethoven-Saal statt. Ich habe keine Ahnung, ob 500, 700 oder 800 Leute im Raum waren - als mir während der Livedemo spontan meine virtuelle Maschine von der Bildfäche verschwand (VirtualBox meinte nur “aborted”), guckte gefühlt das ganze Javaforum auf mich ;-)

Das Pokerface scheint aber gehalten zu haben:

Glücklicherweise ließ sich der VM-Neustart mit Erklärungen überbrücken, und glücklicherweise startete sie auch erneut :-) Mit einer Demo weniger als geplant lief dann der Vortrag vollends durch, den Zuschauern scheint’s trotz der Panne gefallen zu haben.

Top Java Performance Fehltritte

Ein wirklich äußerst unterhaltsamer Abschluß für den Konferenztag. Es ging um Fallbeispiele, in denen es aus verschiedenen Gründen zu Performanceproblemen kam - und wie man sie aufspüren konnte. Zahl der SQL-Queries pro Seitenaufruf, Datenmenge pro Query, etc. waren diverse klassische Metriken. Beim Messen im Code gilt häufig der Physiker-Spruch „wer mißt, mißt Mist“ - wer händisch im Code Start- und Stopzeit ermittelt, mißt damit nicht nur die Laufzeit seines Codes, sondern eben auch Zeit in anderen Threads oder Zwangspausen durch den Garbage Collector. Ansonsten bekommt dieser Talk von mir den Preis für die lustigsten Symbolbilder zu den einzelnen Kapiteln:

(War nicht genau das Bild aus dem Talk, aber so ähnlich ;-)

Fazit

Das Java-Form war wieder einmal große Klasse. Chapeau vor den Organisatoren, die für einen perfekten, reibungslosen Ablauf gesorgt haben. Thementechnisch war es eine gute Abdeckung, lediglich das Thema alternative JVM-Sprachen habe ich etwas vermißt. Trotzdem freue ich mich schon auf das nächste Jahr.

(Fotos von der JUG Stuttgart)