BED-Con 2016

Posted by in Allgemein

Da bin ich also auf den Berlin Expert Days (bedcon.org) gelandet und das gleich mit zwei Vorträgen. Was für ein Erlebnis. Aber fangen wir von vorne an.

Location

Die Urania liegt mitten in Berlin. Man kann das KaDeWe sogar vom Eingang aus sehen. Das Gebäude scheint organisch gewachsen zu sein, denn die Gänge sind verwinkelt und den Raum für meinen ersten Vortrag hätte ich beinahe nicht gefunden 😉 . Ansonsten ist alles Top. Es gibt genug zu Essen und vor jedem Vortragsraum Kaffee und kalte Getränke. In jedem Raum sind Techniker vorhanden und man fühlt sich hier einfach wohl. In den unklimatisierten Räumen in den oberen Stockwerken ist es aber dennoch sehr heiß. Wer hat hier was von Herbst erzählt mitten im September?

Organisation

Den Organisatoren ist ein großes Lob auszusprechen. Von der Vorbetreuung per Email habe ich mich gleich aufgehoben gefühlt. Bei der Ankunft war schon alles bereit und man wurde freundlich empfangen. Marcel (einer der Betreuer) hat sogar vor meinem Vortrag noch Leute zum etwas schwer zu findenden Saal gelotst. Sehr gelungen alles. Wenn es geht, bin ich nächstes Jahr wieder dabei.

Erster Tag – Vormittag

Ich durfte im ersten Slot gleich ran und habe mich in das unbekannte Gewässer Livecoding mit TypeScript gewagt. Meiner Meinung nach hat das gut geklappt und wenigstens mir hat es viel Spaß gemacht. Diesmal war ich auch gut vorbereitet und Probleme mit der Lautstärke gab es nicht. Das Mikro war fest mit meinem Kopf verdrahtet (aus Fehlern lernt man ja, hoffe ich). Danke an alle die mir zugehört haben.

Weiter gings mit Jens Schauder, der eine Einführung in Junit5 gegeben hat. Leider habe ich nicht so viel verstanden, da ich noch nicht viel Kontakt mit den neuen Sprachfeatures in Java 8 hatte.

Vor der Mittagspause gab es noch ein wahres Feuerwerk an Ideen von Stefan Hildebrandt zum Thema wartbare Oberflächentests. Eine Zusammenfassung würde den Artikel sprengen. Deswegen hier nur die Kernideen:

  1. Am besten verwendet man eine JVM-Sprache die Closures erlaubt, da sich damit die Tests besser schreiben lassen. Am einfachsten für Java Entwickler ist Groovy.
  2. PageObjects sind die Mittel der Wahl, damit die ganze Logik darin gekapselt werden kann. (Assertions, Async Calls, Bedienung der Seite an sich)
  3. Fluent API ist ein muss für lesbare Tests.
  4. Für Fragmente gibt es eigentlich nichts wirklich Komplettes (Arquillian Graphene, Webtester, GEB <- Ist das Beste)
  5. Als Strategie bietet sich die grundlegene Isolation der Testlayer an (Unit, Service, UI)
    • Diese ist zu erreichen durch ständige Kommunikation der Teams untereinander
    • Außerdem sollten Mocks und Simulatoren verwendet werden. Letztere in Docker-Container gekapselt.
    • Dadurch sind sie leicht aufsetzbar und überall deploybar.

Erster Tag – Nachmittag

Am Nachmittag standen zuerst Kurzvorträge an. Niko Köbler hat AWS Lambda vorgestellt. Wie er es benutzt, wie es funktioniert und wieviel es kostet. Aber auch die Herausforderungen, die beim Administrieren und Monitoring entstehen, kamen nicht zu kurz.

Auch interessant fand ich, dass der ELK-Stack jetzt Elastic Stack heißt. Das liegt daran, dass der „Elch“ praktisch ausgedient hat und durch Beats ersetzt wird. Das ist mit allen möglichen Modulen ausgestattet, um alle möglichen Vorgänge zu loggen.

Einen herausragenden Talk hat meiner Meinung nach Uwe Friedrichsen abgeliefert, der auf die Konsistenzprobleme in Datenbanken eingegangen ist. Ich kann nur jedem das Nachlesen empfehlen. Jedenfalls ist Konsistenz selbst mit einem RDBMS nur unter größten Performanzeinbußen realisierbar. Die wichtigsten Dinge des Vortrags hier kurz zusammengefasst:

  • ACID ist nicht gleich Serialisierbarkeit
  • Daraus folgt, dass zwangsläufig Anomalien entstehen
  • Konsistenz wird in Zukunft mit auf die Applikationsebene verlagert
  • Ein einfaches Programmiermodell bekommt man mit ACID
  • Ein sehr schweres bekommt man mit BASE

Letzter und definitiv lustigster Talk war von Carola Lilienthal. Angereichert mit vielen Erfahrungen aus ihrem täglichen Alltag und einigen Comics von Geek&Poke hat sie über technische Schulden gesprochen. Das ist nur eine der 4 Schulden, die man in einem Softwareprojekt ansammeln kann. Es fehlen dann noch Fehlende Tests, Dokumentation und Implementation. Um Software pünktlich und schnell auszuliefern muss man aber immer Schulden aufnehmen. Wichtig ist nur, dass man einplant diese durch Refactorings abzubauen. Ansonsten droht mit der Zeit die Verrottung der Software.

Dafür notwendig sind kontinuierliche Analyse, Weiterbildung und Diskussion über die Architektur. Außerdem ein Soll/Ist-Vergleich der zu Aha-Effekten führen kann. Folgt man diesen Empfehlungen ergibt sich daraus Wartbarkeit und Flexibilität.

Dann gab es einen Ausflug in die kognitiven Prozesse des Menschen mit der Frage: Wie muss Code strukturiert sein, dass Menschen ihn verstehen können. Dazu gibt es drei Methoden die jeder schon im Alltag anwendet. Das Chunkin (Zerlegen von großen Teilen), Bildung von Hierarchien und Schemata. Daraus folgt, dass Code in Module zerlegt werden sollte, die auf höherer Ebene leichter zu verstehen sind. Das führt dann oft dazu, dass man eine hierarchische Organisation des Codes automatisch bekommt.

Mit Schemata will man vor allem eines erreichen:
Dass bestimmte Dinge immer konsistent gleich gemacht werden, was zu einem besseren Verständnis beiträgt.

Zuletzt ging sie noch darauf ein, dass Software nicht nur nach technischen Schichten, sondern auch nach fachlichen Schichten aufgeteilt werden sollte. Klingt verdammt nach Microservices, was sie auch andeutete.

Zweiter Tag – Vormittag

Der zweite Tag startete gleich mit einem richtigen „Kracher“ von Niko Köbler. Dieser stellte Lasttests mit Gatling vor. Neben der grundsätzlichen Arbeitsweise mit dem Gatling Recorder zur Aufzeichnung von HTTPRequests (URLs), ging es dann richtig zur Sache mit der speziellen Scala-DSL für die Tests. In diese übersetzt der Recorder die aufgezeichnete Simulation.

Außerdem wird Gatling noch durch Realtime Monitoring ergänzt, das die Tests(-Ergebnisse) in eine Datenbank wie InfluxDB schreiben kann. Das Gratana Dashboard rundet dieses Paket ab. Für Distributed Tests gibt es nichts Spezielles. Dort muss man auf Fat Jars oder Build Slaves zurückgreifen.

Der Talk über Architektur und UX hatte einige interessante Punkte. So sollten Querschnittsthemen nicht zu früh angegangen werden, um die fachlichen Tests nicht zu behindern. Außerdem kann auch probiert werden, beim Workflow des Benutzers anzusetzen. Also mit dem Ende/Ergebnis zu beginnen, das der Benutzer erreicht. Da das Beispiel auf einem Migrationsprojekt aufbaute, kam außerdem der Vorschlag das Backend getrennt vom Frontend abzulösen. Mit Feature Toggles lassen sich damit sogar einzelne Funktionen einfach auf das neue Backend umschalten.

Angenehm zuzuhören war kurz vor der Mittagspause dann Oliver Fischer, der zuerst allgemeine Kommunikationsprobleme im Bezug auf Architektur erläuterte. Fakt ist: Architektur ist schwierig. Und wenn keiner mehr da ist, der einem sagen kann, warum etwas gerade so gemacht wurde, wie es jetzt ist, dann ist guter Rat teuer. Denn meistens gab es für jede Entscheidung einen sinnvollen Grund. Insbesondere schwierig wird es, wenn sich Domänenexperten, Entwickler und User abstimmen müssen. Da helfen nur Regeln, sowohl informelle, als auch formelle. Die haben aber ihre eigenen Herausforderungen (Wiki: Wo Dokumentation zum Sterben hingeht!)

Besser ist da auf den ersten Blick für mich tatsächlich jQAssistant. Das liest die Codebasis in Neo4j ein. Damit lassen sich dann, auf der Abfragesprache Cypher als Grundlage, Regeln definieren, die eine bestimmte Codestruktur sicherstellen. Sonst geht der Build schief. Für mich ein geniales Tool, das sich relativ leicht mit Maven einbinden lassen sollte.

Zweiter Tag – Nachmittag

Über das Projekt Apache Tamaya zur Konfigurationsverwaltung von Applikationen habe ich im JavaMagazin schon gespannt gelesen. Es war echt interessant Anatole Tresch, der es maßgeblich treibt, live zu sehen und seinen Ausführungen zuzuhören, die Hand und Fuß hatten. Apache Tamaya löst eigentlich so ziemlich alle Probleme, die man mit verschiedenen Konfigurationsarten hat. Es abstrahiert von der eigentlichen Bereitsteilung auf eine einheitliche Annotationsweise. Außerdem kann man die sogenannten PropertySourcen dann auch priorisieren und beim Überschreiben nicht nur der stärkere gewinnt einstellen. Zusätzlich ist es nützlich auch die Konfiguration konfigurieren zu können. Die Meta-Konfiguration sozusagen. Auch das erlaubt Apache Tamaya. Bester Spruch des Tages: „Jeder hat schon eine eigene Konfigurationslösung gebaut“. Wie wahr!

Zu guter Letzt gab es noch Kurzvorträge, bei denen ich den zweiten selbst halten durfte. Im ersten wurde über Software Craftmanship referiert. Das war ein guter Überblick über die Philosphie und was es heißt die Softwareentwicklung an sich weiterzubringen.

Anschließend durfte ich ran mit „Debugging Sucks“. Ich wusste schon, dass mein Englisch nicht so der Bringer ist. Leider hat das Thema aber auch nicht so viel hergegeben, wie ich gedacht habe. So blieb es inhaltlich bei zehn Minuten.

Fazit

Die BED-Con war für mich eine durchweg positive Erfahrung. Ich konnte einiges an Ideen mitnehmen.
Vielen Dank!