Mein Tag auf der JAX 2016
Meine diesjährige Teilnahme an der JAX 2016 beschränkte sich auf einen normalen Session-Tag - in meinem Fall war das dann der Donnerstag. Meine Kollegen und ich teilen uns die JAX jeweils untereinander auf. Den Auftakt machte in meinem Fall dann eine Session zum Thema reaktive Web-Anwendungen:
Beyond the Buzzword: a reactive Web Application in Practice
Die Session wurde von Manuel Bernhard gehalten - einem unabhängigen Consultant dessen Buch über „Reactive Webapplications“ in Kürze bei Manning erscheinen wird.
Er demonstrierte in seiner Session, wie man mit Scala, dem Playframework und Akka, reaktive Webanwendungen schreiben kann.
Es gab eine kurze Einführung in das Thema über die zeitliche Entwicklung der Hardware von single Core Rechnern mit immer mehr Megaherz bis hin zu multicore Systemen mit mehr Speicher und der Herausforderung alle Cores auch effizient zu nutzen, ohne hierbei allzu viel Speicher zu verbrauchen. Als Beispiel sei gesagt, dass eine Tomcat-Instanz per sé 200 Threads erzeugt, wobei jeder Thread erst einmal ein Megabyte Speicher benötigt. Somit hat man erst mal 200 MB an Speicher verbraten, ohne das hierbei etwas besonderes passiert.1
Nach einem kurzen Abstecher zum Playframework und dessen Aufbau – Convention over Configuration - ging es dann auch an die Entwicklung. Der Autor führte uns hierbei durch eine kleine Twitter App, die asynchron Feeds von der JAX im Browser darstellte. Die App wurde als Microservice mit JSON- Payload und Response gebaut. Die Kommunikation wurde dabei reaktiv über die Aktoren von Akka realisiert, welche das Playframework unter der Haube bereits mitbringt.
Alles in allem ein runder Vortrag mit abschließender Fragerunde. Aus zeitlichen Gründen konnte das Thema Deployment nur kurz angerissen werde, jedoch sei hier erwähnt, dass Play verschiedenen Möglichkeiten bietet, die fertige App als Jar-File, RPM/Debian-Paket inklusive Installations-Script, bereitzustellen. Einer Installation in einem Docker-Container mit anschließendem Deployment in der Cloud steht somit auch nichts mehr im Weg.
Es gibt auf seiner Website ein Video seines Talks mit dem gleichen Titel, den er auf den Voxxed Days Vienna 2016 gehalten hat.
Für Google Chrome gibt es eine Erweiterung, die beim Entwickeln von Playframework Applikationen helfen soll.
Penetrationstests für Entwickler: Don’t be the next Ashley Madison
Nach einer kurzen Pause ging es dann weiter mit dem wichtigen Thema Sicherheit in einem großen fast schon überfüllten Saal.
Philipp Burgmer, selbst Entwickler, sah sich mit einem nahenden Audit zu seiner App konfrontiert und beschloss selbst herauszufinden, wo die eigenen Sicherheitslücken steckten. Er befasste sich mit dem Thema Sicherheit und stellte in dieser Session seine Erkenntnisse der zahlreich erschienenen Allgemeinheit zur Verfügung.
Neben den OWASP Top 10, der OWASP Web Goat App mit seinem Tutorial gab er wertvolle Hinweise, Tips und Tricks. Es ging um’s Kodieren und Dekodieren von URLs und dessen Parametern, über die Eingabeprüfung bis hin zum sicheren Login u.a. mit OAuth, dessen Anbindung wohl anfänglich kompliziert ist, sich aber wohl doch lohnen soll. Ziel ist es mit frei zugänglichen Mitteln schon vorab die Lücken und Probleme zu finden, mit denen man nicht unbedingt einen Spezialisten behelligen möchte. Alleine auch schon aus Kostengründen. Erwähnen möchte ich hier noch ein spezielles Linux namens „Kali“, welches die gängigsten Hacker-Tools bereits vorinstalliert hat.
Six years of Scala and Counting
Kurz vor der Mittagspause gab es noch einen weiteren Vortrag von Manuel Bernhard zum Thema Scala.
Was man mitnehmen sollte ist, dass Scala nicht mehr langsam ist und das man nicht unbedingt alle Sprachfeatures benötigt wie beispielsweise die Makro und das es für das Erlernen der Sprache sogenannte Sprach-Levels gibt, an denen man sich heranarbeiten kann.
Die Levels reichen von A1 bis A3 für Applikationsentwickler und L1 bis L3 für Bibliotheksentwickler und gruppieren somit die Sprachfeatures um einen einfacheren Einstieg zu bekommen.
Hier eine kurze Übersicht der einzelnen Levels
(Auszug aus „Scala for the Impatient“):
Application-Programmer
Beginning = A1
Intermediate = A2
Expert = A3
Library Designer
Junior = L1
Senior = L2
Expert = L3
Overall Scala-Level
A1 = Beginner
A2 & L1 = Intermediate
A3 & L2 = Advanced
L3 = Expert
Die Sprache gewinnt langsam immer mehr an Fahrt2 3.
Über die Jobsuche bei Indeed ergibt sich folgender Trend an funktionalen Sprachen http://bit.ly/1VWLyHA.
Falls man Scala in echten Projekten einführen möchte, gilt der Tipp für ein neues Team auf jedenfalls jemanden mit in’s Team zu holen, der bereits Erfahrung mit Scala hat bzw. funktionalen Programmiersprachen wie z.B. Haskell.
Den Wald vor lauter Bäumen - Fallstricke verteilter Architecturen
In diesem Vortrag von Bernd Fondermann ging es um die Fallstricke in verteilten Architekturen. Da Container (Docker etc.) und Microservices derzeit in aller Munde sind, war es dem Sprecher ein besonderes Anliegen, hier auf die Tücken aufmerksam zu machen und Kriterien für eine bessere Systemauswahl zu geben.
Herausforderung Multi-Channel Architektur
Im letzten Vortrag des Tages erzählte Lars Röwekamp von der open knowledge GmbH etwas darüber, wie moderne Unternehmen heutzutage die Aufgabe bewältigen können unterschiedliche Webkanäle wie Web, Desktop, Mobile oder 3rd-Party Clients parallel zu bedienen. Es ging um Multi-Channel, Cross-Channel und Omni-Channel. Gezählt scheinen die Zeiten, in denen man mit einfachen Webanwendungen dieses Ziel erreichen könnte.
Lars zeigt auf, wie derzeitige monolithische Webanwendungen noch immer aufgebaut sind und das sich zwar dank RWD (responsive web design) schon einiges getan hat, dies aber in Zukunft nicht mehr ausreichen wird für eine multi-channel Architektur.
Die Lösung hierfür geht dabei immer mehr in Richtung Client-Rendering via JavaScript (z.B. via AngularJS) und Serverseitig vermehrt in Richtung REST-Microservices. Klassische CMS-Systeme wie TYPO3 oder Wordpress erfüllen derzeit noch nicht diese Kriterien.
Weitere Themen waren dann auch, wie man mit den verschiedenen Evolutionen einer REST-API umgeht insbesondere in Bezug auf Versionierung (unterschiedliche Versionen für verschiedene Clients) und das Deployment solcher Anwendungen.