BOBKonf 2017: Erfahrungsbericht

Posted by in Konferenz

Das erste Mal auf der BOBKonf… Der Titel der Konferenz beinhaltet Best of Breed. Es geht darum, die besten Werkzeuge für moderne Softwareentwicklung auszusuchen. Interessanterweise heißt das für viele Teilnehmer funktionale Programmierung, allen Sprachen voran Haskell. Dadurch bekommt die Veranstaltung einen ganz eigenen Touch, da die Community sehr offen ist und man auch als hauptsächlich objektorienter Programmierer willkommen ist. Die Vielseitigkeit, Offenheit und Intelligenz der Teilnehmer wurde schon vor der Konferenz klar, da ich beim Pre-Dinner Einige kennen lernen durfte. Leider konnte ich nicht überall etwas beisteuern, da ich viele Dinge aus der Ecke funktionaler Programmierung noch nicht verstanden habe. Cool war es trotzdem (@Pascal: Framework Programmieren steht auf meiner TODO-Liste 🙂 )

Organisation

Die Organisatoren, sowie das Programmkommitee sind engagiert und guter Laune, das überträgt sich entsprechend auf alle. Es war ziemlich locker und trotzdem professionell. Großes Lob!
Auch der Veranstaltungsort ließ keine Wünsche offen. Die Beamer waren perfekt und die Akustik so, dass man sogar ohne Mikrofon alles verstehen konnte.

Die Keynote

Der Keynote-Vortrag von John Hughes bekommt von mir einen eigenen Punkt spendiert, da er unterhaltsam, auf den Punkt und informativ war. Es ging nämlich um die Geschichte der funktionalen Programmierung, in der er selbst eine große Rolle spielt. Einige Dinge konnte ich mitnehmen. Zum Beispiel, dass funktionale Programmierung schon 1940 eine Sache war und es eigentlich um eine mathematische Grundlage für die Programmierung geht. Dadurch begründet sich auch, dass es sogenannte Laws geben soll. So sollen verkette Funktionsaufrufe ausgetauscht werden können, ohne die Semantik eines Programms zu ändern. Herrlich war die Erklärung zu Lazy Evaluation „We go now! Wait! Wait a minute!“. Köstlich! Durch Lazy Evaluation bekommt man unendliche Folgen abgebildet. Weiterhin wurde auf die Komponierung von Funktionen eingegangen, um rekursive Bilder zu malen oder anspruchsvolle Probleme zu lösen. So hat sich vor vielen Jahren schon herausgestellt, dass Haskell viel aussdrucksstärker als jede andere Sprache ist. Leider hat es sich nicht durchgesetzt, da es zu elegant war und man dem Ergebnis eines Tests nicht vertraute. Es gab noch einige Punkte mehr, die ich nicht sinnvoll wiedergeben kann. Zum Glück gibt es diese Keynote auf YouTube.

Vormittag

Mein Vortrag über Mutationstesten mit PIT war einer der angenehmsten, die ich bis jetzt gehalten habe. Das Thema hat zu meiner Überraschung viele begeistert und bei der anschließenden Demo kamen rege Diskussionen mit vielen Fragen auf. Wahrscheinlich habe ich auch schon ein weiteres Thema für einen Vortrag gefunden. Ich bin gespannt wie sich das entwickelt!

Yevgen Pikus hat in seinem Vortrag Synergy of IOT and BPM eine Big-Data-Pipeline auf dem SMACK-Stack aufbauend vorgestellt. Dabei ging es darum, wie Sensordaten aus IOT-Geräten zum Treiber von Geschäftsprozessen werden können, indem sie über eine von Aktoren gesteuerte Pipeline analysiert, aggregiert und schließlich ausgewertet werden.

Um mir mal einen richtigen Haskell Vortrag anzusehen bin ich in Performance and Safety: an Example of using Liquid Haskell in the Real World von Philipp Kant gegangen. Zuerst wurde das Problem vorgestellt: Lesen und Schreiben in einen veränderlichen Buffer über das Netzwerk. Anschließend gab es einen Einblick in die Probleme, die bei der Entwicklung auftreten. Mit Liquid Haskell kann man über Kommentare seine Funktionen dann mit Vorbedingungen annotieren. Diese werden in einem zusätzlichen Schritt bei der Kompilierung überprüft. Und zwar jeder Pfad der zu dieser Funktion führt. Dadurch werden mögliche Fehler gefunden. Ich verstehe zwar nicht, ob es in jeder Situation sinnvoll ist seinen Code derart zu annotieren. Wenn die Qualität am Ende aber stimmt, ist dagegen wohl nichts einzuwenden.

Nachmittag

Die Testmethode Quickcheck (Eigenschaft-basiertes Testen) hat es in meiner Welt bis jetzt nicht gegeben. Lars Hupel hat dieses Thema in einem Tutorial vorgestellt und uns einige Probeübungen gestellt. Da QuickCheck für Haskell entwickelt wurde (unter anderem von John Hughes 🙂 ) war es eine echte Herausforderung für mich. Abgesehen davon, dass ich mehr mit der Syntax als mit dem Problem gekämpft habe, ist der Ansatz genial. Man spezifiziert, wie sich eine Methode verhalten soll und QuickCheck überprüft die Einhaltung der Spezifikation. Dabei geht es zuerst zufallsgetrieben vor, um dann im sogenannten Shrinking-Schritt den gesamten Testraum schließlich abzudecken. Das garantiert, dass der Test zu 100% alle Fälle abdeckt (Ganz glaube ich das insgeheim noch nicht, aber es sieht danach aus 😉 ). Im Laufe des Tutorials wurde aber dann auch klar, dass das Schreiben einer Spezifikation mitunter sehr schwierig sein kann. Trotzdem bin ich begeistert!

Lars Hupel hat mich darauf aufmerksam gmacht, dass es sich doch etwas anders verhält als von mir anfänglich verstanden (Quelle gibt hier):
Freut mich zu hören, dass dir der QuickCheck-Workshop gefallen hat! Ich möchte allerdings kurz eine kleine Korrektur anbringen.

QuickCheck garantiert in den allermeisten Fällen nicht, dass 100% des Testraums abgedeckt werden, denn dieser ist im Regelfall unendlich groß. Dazu müsste QuickCheck nämlich für alle Programmabläufe automatisch entscheiden, ob sie einen Fehler haben. Dies ist bekanntlich nicht möglich.

Stattdessen läuft QuickCheck zufällig im Testraum umher und hofft, dabei einen Wert zu finden, der einen Fehler auslöst. Anschließend wird zur Erleichterung der Fehlersuche und -behebung dieser Wert minimiert. In der Mathematik nennt man das „kleinstes Gegenbeispiel“. Logisch gesehen ist das aber für die Erschließung des Testraums unerheblich.

Wenn man, wie in unserem Beispiel (Sortierung), eine „vollständige Spezifikation“ hat, kann QuickCheck theoretisch, wenn es lang genug läuft, alle Fehler finden. Hier heißt „vollständig“, dass das Verhalten der Implementation rigoros durch die Spezifikation vorgeschrieben ist. (Oftmals hat man nur partielle Spezifikationen, die z.B. mehrdeutig sind.) Da wir aber nicht „lang genug“ warten können, bis QuickCheck ein Resultat findet, brechen wir oftmals die Suche nach 1000, 10000, … Schritten ab, um in beschränkter Zeit zu einem Ergebnis zu kommen.

100%-ige Sicherheit erhält man nur, wenn man einen formalen Beweis erbringt, dass die Spezifikation eingehalten wird. Im allgemeinen funktioniert das aber nicht automatisch, sondern erfordert manuelle Argumentation.

Szymon Warda hat dann Einiges über Graphdatenbanken erzählt in Graph databases – why and how. Der Rückblick über relationale Datenbanken und ihre Geschichte war höchst unterhaltsam. Gelernt habe ich einige Anwendungsbeispiele von Graphdatenbanken: Geldwäsche, Natural Language Processing und Empfehlungssysteme ala Amazon.

Fazit

Für mich war die Konferenz exotisch und aufregend. Ich konnte sehr viel Neues kennen lernen und bin motivierter denn je funktional zu programmieren. Mit dem Eigenschaft-basiertem Testen habe ich eine mächtige Methode in einem Tutorial ausprobiert und mitgenommen, die es auch für JVM-Sprachen gibt. Das werde ich demnächst anwenden.

Falls es möglich ist, komme ich in einem Jahr wieder. Ein mögliches Thema hat sich ja bereits aus der Diskussion nach meinem Vortrag ergeben!