4Max/shutterstock.com

19. Dezember 2016 / von Simon Holthausen, Alexander Eiermann, Henning Sudbrock

Devoxx '16

 

Accsonauten 

berichten

November 2016, Belgien.

Es steht die alljährliche Devoxx im zweitgrößten Kinokomplex Europas, dem Metropolis in Antwerpen an.

Wie immer war das Programm vollgestopft mit Vorträgen zu interessanten Themen. Der Fokus lag dieses Jahr auf künstlicher Intelligenz, wie sie unseren Alltag verändert und wie wir sie sinnvoll in Projekten einsetzen können. Daneben gab es die üblichen Java-Talks, Neues rund ums Web, garniert mit auflockernden bis inspirierenden Allgemeinvorträgen. Auch drei Accsonauten tummelten sich in den Kinosälen, die je nach Vortrag mal angenehm leer, mal bis auf die Treppenstufen gefüllt waren. Welche Vorträge ihnen am besten gefallen haben, wollen sie euch nicht vorenthalten.

Missionsbericht von Accsonaut Alexander:

 

Refactoring to Java 8 – Trisha Gee

.. war für mich einer der informativsten und spannendsten Vorträge der diesjährigen Devoxx. Wie der Titel bereits nahelegt ging es bei diesem Vortrag darum wie sich „Standard“ Java Code mit Hilfe von Java 8 Features ersetzen lässt. Im Fokus standen hierbei natürlich die Stream API und lambda functions.

Der Vortrag selbst bestand im Wesentlichen aus vorbereiteten Code Snippets, welche live refactored wurden. In den meisten Fällen führte die konsequente Anwendung der Java 8 Features zu einer deutlichen Reduktion der Lines of Code, wodurch meist auch die Lesbarkeit deutlich verbessert wurde. Umso überraschender war die Tatsache, dass die ach so kompakt und effizient aussehenden Konstrukte oft gar nicht so effizient waren, wie man auf den ersten Blick hätte vermuten können.

Dies zeigte sich jedoch erst, als kurz darauf der ursprüngliche und der überarbeitete Code Block an Hand ihrer Performance verglichen wurden. In vielen Fällen ging der „Standard“ Java Code, zum Beispiel bestehend aus diversen geschachtelten for-Schleifen, als Sieger aus diesem Vergleich hervor. Punkten konnten die Streams oft nur bei paralleler Verarbeitung von großen Datenmengen mit 10.000 oder 100.000 Elementen.

Neben den wirklich interessanten „Standard Java“ vs. „Java 8“ Performance Benchmarks gab es auch noch einige praktische Tipps, wie sich die neuen Features nutzen lassen, um zum Beispiel das Logging zu optimieren oder um ConcurrentModificationExceptions elegant zu umgehen.

Flying services with the drone – Krzysztof Kudrynski and Blazej Kubiak

Dieser Vortrag war ein richtiger Glücksgriff, den ich nach vier spannenden, aber auch anstrengenden Tagen Devoxx eigentlich nur aus einer spontanen Laune heraus besucht habe. Trotzdem wurde er zu meinem persönlichen Highlight der ganzen Konferenz. Dieser Meinung waren wohl auch die meisten anderen Teilnehmer, denn obwohl es der n-1te Vortrag am n-ten Tag war, erhielt er mit 4.9 von 5.0 die beste Bewertung der gesamten Woche.
Im Prinzip ging es in diesem Talk um das Freizeitprojekt von zwei TomTom Angestellten, die eine autonom fliegende Drohne entwickeln wollten.
Obwohl der Vortrag selbst eher lustig und voller Anspielungen war, war er zugleich aber auch sehr informativ.

Die beiden Referenten berichteten von ihren ersten Flugversuchen, den ersten Crash Landungen und von den Problemen, auf die sie im Zuge des Projekts gestoßen sind. Viele dieser Probleme lagen im Bereich der Bildverarbeitung wie zum Beispiel „Template matching“ oder „Particle filtering“. Doch obwohl diese Probleme mitunter recht komplex sind, haben die beiden Referenten diese sehr anschaulich und gut verständlich erklärt. Letztendlich hat mich der Vortrag so begeistert, dass ich mir keine zwei Wochen später selbst eine Drohne zugelegt habe.

Missionsbericht von Accsonaut Henning:

 

Are you botching the security of your AngularJS application? Philippe De Ryck

Ein Vortrag über AngularJS? Aber die Devoxx ist doch eine Java-Konferenz! Dieser Vortrag zeigt beispielhaft, dass sich die Devoxx nicht auf Java beschränkt, sondern auch andere für Java-Entwickler interessante Technologien behandelt. Beispiele sind Javascript/AngularJS (Stichwort Full Stack Development), oder auch Sprachen wie Scala oder Frege, deren Programme in einer JVM ausgeführt werden können.
Im Vortrag beschreibt Phillippe de Ryck zum einen XSS (Cross Site Scripting) und CSRF (Cross Site Request Forgery), zwei recht gut verstandene, aber dennoch leider weiterhin häufig vorkommende Typen von Sicherheitslücken in Webanwendungen.

De Rycks Erklärung scheint mir gerade für Entwickler mit wenig Erfahrung im Bereich Security gut verständlich. Weiterhin erläutert er in seinem Vortrag, welche Mittel AngularJS bereitstellt, um solche Sicherheitslücken in der eigenen Anwendung zu vermeiden. Interessant ist hierbei insbesondere, wie Anti-CSRF-Tokens auch in Single-Page-Anwendungen, die über eine HTTP-API mit einem Backend kommunizieren, eingesetzt werden können.

Der wichtigste Punkt, den ich aus dem Vortrag für mich mitnehme, sind die noch recht wenig bekannten Content Security Policies (CSPs). CSPs sind Security Policies für auf einer Webseite erlaubten Inhalt, die eine Webanwendung an den Browser ausliefern kann. Die CSPs werden dann entweder vom Browser durchgesetzt, oder einfach nur überwacht, wobei der Browser Verletzungen der CSP automatisch an den Webserver zurückmelden kann.

Das Format der CSPs ist durch einen Standard formalisiert und wird bereits von vielen Browsern unterstützt. Aus meiner Sicht ein sinnvoller Schritt, um Browser zu einer sichereren Ausführungsumgebung für Client-Anwendungen zu machen.

Property-Based Testing for everyone Romeu Moura

Diesen Vortrag empfehle ich hier, weil ich durch diesen Vortrag darin bestärkt worden bin, in Entwicklungsprojekten öfter sogenanntes Property-based Testing einzusetzen.

Romeu Moura erläutert zum einen die Grundidee von Property-based Testing im Vergleich zu „klassischen“ Tests. Klassische Tests testen üblicherweise, dass für bestimmte Eingabedaten bestimmte Ausgabedaten berechnet werden. Möchte man dies für verschiedene beispielhafte Eingabedaten tun, dann werden üblicherweise einfach mehrere Testfälle geschrieben (bzw. durch eine Liste von Beispieldaten parametrisierte Tests).

Im Gegensatz dazu beschreiben Property-based Tests die Ausgabedaten in Abhängigkeit der Eingabedaten. Triviales Beispiel: Ruft man eine Funktion „sort“ für eine Liste auf, dann ist die Ausgabe sortiert und enthält die gleichen Elemente wie die Eingabeliste. Der Test wird dann mit vielen zufälligen Eingabedaten ausgeführt, und für jeden Testlauf werden die Ausgabedaten entsprechend überprüft. Neben einer dadurch möglicherweise höheren Testabdeckung liegt der Vorteil aus meiner Sicht darin, dass ein solcher Test eine Eigenschaft des getesteten Codes auf einer höheren Ebene beschreiben kann als eine Sammlung von Tests für konkrete Ein- und Ausgabedaten.

Interessant wird der Vortrag auch dadurch, dass Moura aufzeigt, wie typische Unit Tests für Enterprise-Anwendungen in Property-based Tests umgewandelt werden können. Dies zeigt er am Beispiel eines solchen typischen Unit Tests – und mit „typisch“ ist tatsächlich „typisch“ und nicht etwa „gut“ gemeint: Viele Zeilen Testdaten-Setup, und am Ende eine Zeile getestete Business-Logik, die im Rest der Testmethode fast untergeht (und den Zuhörern sah man an, dass bei vielen viele die Tests genauso aussehen…). Moura zeigt, wie man solche Testfälle in Property-based Tests überführen kann, indem die Ausgabe in Abhängigkeit von Teilen der Testdaten ausdrückt.

Für Java-Entwickler ist dieser Vortrag aus meiner Sicht interessant, um eine weitere Option für automatisierte Tests kennen zu lernen.

Missionsbericht von Accsonaut Simon:

 

How Google DeepMind conquered the game of Go – Roy van Rijn

Auch wenn der Vortrag “Google” im Namen hat – es war kein Google-Mitarbeiter, der ihn hielt. Deshalb gab es auch kein spannendes Insiderwissen, aber dennoch einen sehr kurzweiligen, unterhaltsamen und informativen Vortrag zum Thema Künstliche Intelligenz. Roj van Rijn ging zunächst auf simplere Spiele ein, und wie diese allein über das Berechnen aller Endzustände optimal gespielt werden können. Da das Spiel Go aber bereits nach wenigen Zügen Milliarden möglicher Ausgänge hat, ist die Herangehensweise des Berechnens möglicher Spielzustände nicht praktikabel.
Deshalb ging Google mit DeepMind einen anderen Weg und nutzte Deep Neural Networks, um den nächsten Zug und die Siegchance im aktuellen Zustand zu bewerten.

Das Programm lernte von tausenden Go-Partien sowie von Spielen gegen sich selbst. Der Ausgang ist bekannt: DeepMind gewann vier zu eins und spielte im Laufe des Turniers einige ungewöhnliche, von Go-Spielern dennoch als „schön“ beschriebene Spielzüge.

Was für mich den Vortrag allerdings erst wirklich herausragend machte, war die Einführung in Deep Neural Networks. Ich habe in der Universität in Vorlesungen mehrere Erklärungen dazu gehört, doch keine war nur annähernd so plastisch und greifbar wie diese. Fairerweise muss man sagen, dass dies zum großen Teil auch an der fantastischen Einführungsseite des Machine-Learning-Frameworks Tensorflow lag, die das Herumspielen mit verschiedenen neuronalen Netzen am Beispiel eines Datensatzes im Browser ermöglicht. Insgesamt ein sehr empfehlenswerter Vortrag.

 

Wait, what?! Our microservices have actual human users? – Stefan Tilkov

Hinter diesem etwas provokanten, aber auch nichtssagenden Titel verbirgt sich einer der für mich stärksten Vorträge der Devoxx. Im Kern ging es darum, wie wir Microservices richtig schneiden und die zu Microservices passende Struktur für unser Frontend finden. Vorgestellt wurde ein UI-zentrierter Ansatz. Was also zum Beispiel auf einer Webseite fachlich zusammengehört, sollte möglichst auch in einem Microservice vereint sein.

Der für mich stärkste Teil des Vortrags war jedoch der Vorschlag, wie man sein Frontend auf die Microservices anpasst – dann was haben wir davon, im Backend kleine Microservices zu haben, wenn unser Frontend ein großer Klotz ist?

Stefan Tilkov sprach sich hier dafür aus, auch das Frontend in fachliche Einheiten aufzuteilen, die den fachlichen Zuständigkeiten der Microservices entsprechen. Teams bearbeiten nun nicht mehr Frontend oder Microservice, sondern sind in diese fachlichen Einheiten aufgeteilt und entwickeln alles von Backend bis Frontend. So kann jedes Team sowohl über den kompletten Stack hinweg eine eigene Technologie wählen und Kommunikationsprobleme minimieren.

Damit sprach sich der Vortragende auch explizit gegen Single-Page-Applications aus, da sie dieses Schneiden erschweren – man ist nicht mehr frei in der Wahl seiner Werkzeuge. Gerade mich als SPA-Enthusiasten hat dieser Einwand sehr ins Grübeln gebracht, was den Vortrag für mich nur noch besser machte.

Autoren

Simon Holthausen
Simon Holthausen
Alexander Eiermann
Alexander Eiermann
Henning Sudbrock
Henning Sudbrock
Weitere Artikel

Das könnte Sie auch interessieren