Vorträge

Dies & das

Allerlei in aller Kürze

N. N.

Bookware

N. N.

Bookware

N. N.

Bookware

In dieser Keynote wird inzwischen traditionsgemäß in aller Kürze über Wissenswertes und Persönliches rund um die Software-Entwicklung referiert.

N. N.
Titel
Untertitel

N. N.
Titel
Untertitel

N. N.
Titel
Untertitel

Das Beste kommt zum Schluss

Verabschiedung

Herbstcampus-Team

Bookware

In der Abschlussveranstaltung wird noch einmal resümiert, die besten Sprecher gekürt und unter den Anwesenden einige wenige glückliche „gesucht“, die mit mehr als nur einem Wissensgewinn nach Hause gehen sollen.

Lass die Affen testen

Das Ende der Bananen-Software

Dr. Jeremias Rößler

ReTest

Wer hat den Teufelskreis aus Testing und Debugging noch nicht erlebt: In zwei Wochen ist Release-Date und die Tester finden täglich neue Fehler. Jeder Fehler führt zu einer Änderung im Programm. Und jede Änderung kann selbst wieder Fehler verursachen und muss deshalb getestet werden...

Kosten entstehen hauptsächlich durch manuelles Testen bzw. manuelle Testfallerstellung. GUI-Tests sind brüchig und bringen demzufolge einen hohen Pflegeaufwand mit sich – was die Amortisation verzögert. Deshalb werden heute 85% aller Oberflächentests noch manuell ausgeführt. Was wenn man automatisch Testen könnte? Und d. h. nicht manuell erstellte Tests (die will sowieso keiner erstellen und erst recht keiner pflegen) automatisch ablaufen lassen, sondern wirklich vollautomatisch Testen? Monkey-Testing bezeichnet zufallsbasiertes Testen von Software über die Benutzeroberfläche, und findet vollautomatisch und kostengünstig Fehler.

In diesem Vortrag zeigt der Referent, wie jeder Anwesende mit ein paar Zeilen Code einen eigenen primitiven Affen zum automatischen Testen programmieren kann. Davon ausgehend werden auch Ansätze und Konzepte gezeigt, wie man diesen Affen (u. a. mit genetischen Algorithmen) immer weiter verbessern kann, bis er teilweise bessere Ergebnisse als menschliche Tester bringt. Dazu gibt es Demos und Erfahrungsberichte aus großen Projekten.

Event Sourcing in einer Microservice-Architektur

Ein Erfahrungsbericht aus der Werkhalle

Michael Omann

Senacor Technologies AG

Microservices gelten als vielversprechender Lösungsansatz für Architekturprobleme, die in klassischen, monolithischen Anwendungen auftreten. In der Theorie ist alles ganz einfach. Bei großen Vorhaben mit hohen Anforderungen an Verfügbarkeit und Adaptierbarkeit, kristallisieren sich im Praxiseinsatz rasch komplexe Abhängigkeiten zwischen Services heraus. Die versprochenen Eigenschaften des Architekturkonzepts wie „unabhängig entwickelbare, lose gekoppelte Einheiten“ und „Skalierbarkeit“ erfüllen sich nicht von selbst. Event Sourcing kann helfen diese Abhängigkeiten aufzubrechen, gleichzeitig macht es Applikationen robuster und besser skalierbar.?Im Vortrag werden die Erkenntnisse aus einem großen eCommerce-Payment Umsetzungsvorhaben vorgestellt, das in hohem Maße auf Event Sourcing setzt. Können die Erwartungen im Ergebnis erfüllt werden? An welchen Punkten treten unerwartete Schwierigkeiten auf? 
Der Vortrag berichtet direkt aus der Werkhalle und spricht diejenigen an, die Event Sourcing aus der Theorie kennen und wissen wollen, wie sie in der Praxis funktionieren.

App-ocalypse now

The dark side of your App

Tim Bourguignon

MATHEMA Software GmbH

Thomas Künneth

MATHEMA Software GmbH

Cross-platform, Wiederverwendbarkeit, Performanz – welche Programmiersprache ist die Beste? C# natürlich. Oder vielleicht doch Java? Oder Objective-C, Swift, oder gar JavaScript? Diese Themen beschäftigen Entwickler jeden Tag und werden gerne und oft auf Konferenzen diskutiert. Letztlich berühren sie aber nur einen kleinen Bereich der App-Entwicklung. Viele spannende Fragen werden dafür nie gestellt, oder gar beantwortet. Was passiert mit der App, wenn sie im Store verfügbar ist? Auf welche Informationen kann ich als Entwickler zugreifen – Statistiken, Fehlerberichte, Kundenkommentare? Wie komme ich an mein Geld? Und wie viel verdiene ich überhaupt?

Dieser Vortrag blickt hinter die Kulissen von Google Play und des Microsoft App-Store. Dabei werden Gemeinsamkeiten und Unterschiede vorgestellt, gezeigt was die beiden Welten jeweils gut machen und wo sie voneinander lernen könnten.

Ich habe fertig!

Production-ready statt Feature-complete

Uwe Friedrichsen

codecentric AG

Agilität hat uns gelehrt, auf Geschäftswert zu achten – was wichtig ist. Clean Code hat uns gelehrt, wartbaren Code zu schreiben – was wichtig ist. Aber all das ist wertlos, wenn unsere Software nicht zuverlässig in der Produktion läuft, denn nur in Produktion macht unsere Software Umsatz und stellt unsere Kunden zufrieden. Damit unsere Software zuverlässig unsere Kunden zufrieden stellt, reicht es aber nicht, dass sie nur „Feature-complete“ ist, sie muss „Production-ready“ sein.

In diesem Vortrag lernen Sie Patterns und Prinzipien zum Schreiben von „Production-ready Software“ kennen, natürlich garniert mit Code und jeder Menge Tipps und Tricks. „It's all about production!“

Der Schmetterlingseffekt

CSS in größeren Projekten

Sebastian Reiners

open knowledge GmbH

Je größer ein Web-Projekt wird, umso komplizierter und nervenaufreibender wird die Wartung und erst recht die Änderung des bestehenden CSS. Jeder der schon einmal zwei Wochen vor dem Live-Gang das Web-Frontend komplett umstellen durfte oder ein in die Jahre gekommenes (und entsprechend gewachsenes) Stylesheet überarbeiten sollte, wird wissen wovon hier die Rede ist.

In diesem Vortrag werden kleine und größere Tipps gegeben, wie man solchen Situationen begegnet, sie unter Kontrolle behält und bestenfalls von vorneherein vermeidet. Der Fokus wird dabei auf dem Aufbau wartbarer Stylesheets, der Nutzung von CSS-Frameworks wie Bootstrap, CSS-Preprocessing mittels Less und der Integration ins Build-Management liegen.

Chicken Little, Cold Turkey etc.

Welche Migrationsstrategie ist die richtige?

Stephan Kaps

Bundesversicherungsamt

Unter Migration versteht man jegliche Art von Umstellung. Nicht selten sind davon ganze Anwendungssysteme betroffen, d. h. es ändert sich die Plattform, das Front-End, die Datenbank usw., wie es z. B. bei der Migration von Großrechnersystemen häufig der Fall ist. Die Gründe für eine Migration können vielfältig sein. Ziel dieser Umstellungen ist jedoch immer, die fachliche Funktionalität beizubehalten.

Der Vortrag stellt die folgenden sechs Migrationsstrategien aus Theorie und Praxis vor: Big Bang Approach (Cold Turkey Strategy); Chicken-Little Strategy; Database First Approach (Forward Migration Method); Database Last Approach (Reverse Migration Method); Composite Database Approach (Parallel Database Strategy); Butterfly Methodology.

„Sichere“ Software

Erkennen und Vermeiden von Angriffspunkten

Andreas Vombach

ABB Semiconductors, Lenzburg

Sicherheit auf Betriebssystemebene kennt jeder (?) und für Server-Sicherheit sind die Administratoren zuständig. Daher macht sich der gestresste Software-Entwickler (meist Mädchen für Alles, von Architektur bis zum Testen) wohl kaum auch noch Gedanken über zusätzlich mögliche Sicherheitsaspekte. Dabei fängt „Security by Design“ schon beim Konzept seiner Software an.
Dieser Vortrag beleuchtet sicherheitsrelevante Bereiche im gesamten?Entwicklungsprozess bis zu dem „sicheren“ Gefühl, das der Benutzer einer Software haben sollte.

Flyway vs. LiquiBase

Kampf der Datenbank-Migrationswerkzeuge

Stephan Kaps

Bundesversicherungsamt

Wenn es das Ziel ist, Software regelmäßig auszuliefern, gegebenenfalls mehrmals am Tag, darf bei all den derzeitigen Überlegungen zur Automatisierung von Tests, Deployments und Infrastruktur die Datenbank nicht vergessen werden. Die Automatisierung von Änderungen (Migrationen) ist auch hier unverzichtbar. Inzwischen existieren Tools für diese Aufgabe, die sich sehr gut in den Entwicklungsprozess integrieren lassen.

Die zwei bekanntesten Tools werden in diesem Vortrag vorgestellt und miteinander verglichen. Der Vergleich geht über sechs Runden:
1. Funktionen; 2. Einbindung in bestehende Projekte; 3. Integrationsmöglichkeiten; 4. Inbetriebnahme und Handhabung; 5. Verfügbare PlugIns; 6. Rahmenbedingungen

Container verschiffen

Continuous Delivery mit Docker – revisited

Dr. Halil-Cem Gürsoy

adesso AG

Bei Docker handelt es sich um ein System, mit dessen Hilfe sehr leichtgewichtige, selbstständige Container für Applikationen aufbauen lassen. Diese Container können einfache „echo-Hallo Welt“-Applikationen oder auch komplexe Application-Server-Installationen enthalten. Einmal gebaut, werden diese Container von der Entwicklung bis hin zur Produktion promoted.

Wie dies konkret umgesetzt werden kann und welche Vorteile wir daraus in Entwicklungsprojekten ziehen können, werden wir im Detail betrachten.

Die Flux Application Architecture

Facebooks Ansatz für Client-side Web Applications

Sven Kölpin

open knowledge GmbH

Facebooks ReactJS ist der neue Stern am Himmel der client-seitigen JavaScript-Bibliotheken. Neben diesem innovativen Framework hat der Software-Gigant zusätzlich ein Pattern veröffentlicht, welches die Nachteile des klassischen MVC-Prinzips umgehen soll: Die Flux-Architektur. Auf Basis dieser Architektur wurden bereits Web-Anwendungen wie facebook.com und instagram.com entwickelt.

Im Vortrag werden die Ideen und Vorteile dieses Architekturansatzes näher erläutert. Außerdem soll diskutiert werden, ob und wie sich die Flux Application Architecture auch abseits von ReactJS verwenden lässt.

Auch SQL ist Source-Code

Continuous Database Integration mit Flyway

Sandra Parsick

Skripte für relationale Datenbanken werden von Java-Entwicklern gerne stiefmütterlich behandelt. Beim ersten Release können sie dank ORM-Frameworks generiert werden. Doch spätestens beim zweiten Release, müssen Datenbankmigrationsskripte geschrieben werden. Sie werden dann gerne an Tickets angehangen, per E-Mail verteilt, in Release-Notes versteckt etc. Irgendwann gibt es keinen Überblick mehr, welche Datenbankskripte zu welcher Software-Version gehören.

Dieser Vortrag zeigt, – warum eine Einbindung von Datenbankskripten in den Continuous Integration-Prozess erstrebenswert ist, – welche Voraussetzungen dafür geschaffen werden müssen und – wie Flyway dabei helfen kann.

Puppenspielereien

Infrastruktur in Code mit Puppet beschreiben

Sebastian Hempel

IT-Consulting Hempel

Nicht erst seit der DevOps-Bewegung werden Entwickler mit der Konfiguration von Systemen konfrontiert. So gibt es in jedem Team einen „Auserwählte(n)“, der/die sich um die Konfiguration der Build-Umgebung kümmert. Neben der Erstellung und Pflege des/der Build-Skripte umfasst diese Rolle auch den Aufbau und die Pflege der zugehörigen Rechner und darauf laufender Dienste.
Meistens wird diese Arbeit mehr schlecht als recht durch Checklisten dokumentiert. Muss ein System neu gebaut oder ein zusätzliches System konfiguriert werden, hofft man mit diesen Checklisten den Aufwand für die Arbeiten so gering wie möglich zu halten. Änderungen an der
Konfiguration werden aber nur sehr selten in den Checklisten nachgezogen. Die in den Listen dokumentierte Konfiguration weicht somit so gut wie immer von der tatsächlichen Konfiguration ab. Das Thema Konfigurationsmanagement hat im Zuge der DevOps-Bewegung an Bedeutung gewonnen. Die Konfiguration eines Systems wird dabei nicht als Text sondern als Code/Programm „dokumentiert“. Ist eine Konfiguration einmal codiert, kann sie immer wieder auf ein System angewendet werden. Auch die Duplizierung einer Konfiguration ist ohne großen Aufwand möglich.

Der Vortrag zeigt die Nutzung des Konfigurationsmanagement-Systems Puppet für den Entwickler. Nach einer kurzen Einführung in Puppet werden die folgenden Fragen beantwortet. Wie kann die Konfiguration des Build-Systems mit Puppet beschrieben werden? Welche Möglichkeiten gibt es die Jobs im CI-System (Jenkins) mit Puppet zu definieren? Wie wird das Test-System (Application-Server) mit Puppet konfiguriert? Wie kann die auf dem Test-System definierte Konfiguration für die weiteren Stages bis hin zur Produktion weiterverwendet werden? Wie kann der „Konfigurations-Code“ von Puppet sowie der Code des eigentlichen Systems verwaltet werden?

REST ruck-zuck fertig

Microservices mit Dropwizard entwickeln

Alexander Schwartz

msg systems ag

Das Dropwizard-Projekt hat den Java EE-Stack ausgemistet und stellt eine Plattform für leichtgewichtige REST-Services auf Basis von JAX-RS bereit. Auf diese Weise lassen sich Services im Handumdrehen schreiben, dokumentieren, testen und absichern. Entwickler mit Java EE-Hintergrund finden sich sehr schnell zurecht. Automatische Tests fallen leichter. Die aufwändige Konfiguration eines Application-Servers entfällt. Deployment und Monitoring wurden auch deutlich vereinfacht.

Während des Vortrags entsteht Schritt für Schritt eine Anwendung. Dabei werden die Best Practices rund um Domain Driven Design wie z. B. Hexagon Architecture, Adapter, Repository und Inversion of Control verwendet. Dropwizard unterstützt dies mit Basisfunktionalität für Unit- und Integrations-Tests. Eine Swagger Live-API stellt die Dokumentation der REST-API bereit. OAuth 2 sichert die Services gegen unbefugten Zugriff ab.

Boldly go where no JUnit test has gone before

Außerirdisch gute Tests mit Spock

Tobias Ahlers

Smartsquare GmbH

Software, unendliche Weiten. Dies sind die Abenteuer des Spock-Frameworks, das mit uns Entwicklern unterwegs ist, fremden Code zu erforschen, zu spezifizieren und zu testen. Viele Lichtjahre von überflüssigem Boilerplate entfernt, dringt das Spock-Framework in Produktivitätsgalaxien vor, die nie ein JUnit-Test zuvor gesehen hat.

Dieser Vortrag stellt das Spock Testing-Framework vor und erklärt, warum es sich lohnt einmal über den JUnit-Tellerrand zu schauen. Mit seiner durch Groovy ermöglichten Testing-DSL bietet Spock nicht nur eine Reihe von Vereinfachungen und Verbesserungen im Vergleich zu JUnit, sondern auch ganz neue Ansätze wie das Data Driven-Testing. Neben einigen (wenigen) Folien werden wir die Eigenschaften von Spock am lebenden (Code-)Objekt erkunden.

JSF meets JS (2. ed.)

JSF-Komponenten mit JavaScript

Sven Kölpin

open knowledge GmbH

Komponentenbibliotheken wie Primefaces und Richfaces stellen für die Entwicklung von JSF-Anwendungen eine Vielzahl komplexer Komponenten bereit. Aber der ersten Euphorie folgt die Ernüchterung. Und statt der erhofften Vorteile muss man sich mit neuen Problemen befassen. Dabei kann man sich mit HTML5, JavaScript, Composite Components und der Behavior API maßgeschneiderte Erweiterungen für die eigene Anwendung schaffen.

Der Vortrag zeigt wie man für eine JSF-Anwendung dynamische und wiederverwendbare Bausteine für die eigene Anwendung realisieren kann.

Durchgemischt

Mixins und Traits mit Java 8

Michael Wiedeking

MATHEMA Software GmbH

Mit Java 8 haben neben den Lambda-Ausdrücken auch default-Implementierungen in Interfaces Einzug in die Sprache gehalten. Damit eröffnen sich ganz neue Gestaltungsmöglichkeiten, mit denen man Wiederverwendung von Code deutlich vereinfachen kann.
Dieser Vortrag zeigt, wie man mit Lambda-Ausdrücken Klassen beeindruckend konfigurierbar machen kann; und wie man mit Hilfe von Interfaces Code, vergleichbar zu Traits oder Mixins, einbetten kann.