EuroPython 2014: Mein Bericht

In der letzten Woche (vom 21.07.2014 bis 27.07.2014) durfte ich an der EuroPython2014 teilnehmen. Wahnsinn! Ich bin immer noch geflasht!

tl;dr

Fünf Tage mit Keynotes, Vorträgen, Essen, vielen Gesprächen und ein paar abendlichen alkoholischen Getränken. Nicht zu vergessen, die Lightning Talks, die fast das Beste an so einer Konferenz sind!

Und natürlich mit einer guten Liste an Dingen, die ich mir anschauen muss/will/sollte.

Was ich erlebt habe

Vorträge, die ich besucht habe

Anhand der Guidebook-App konnte ich rekonstruieren, welche Vorträge ich besucht habe:

• Am Montag gab es „nur” zwei Keynotes
  • „One year of Snowden, what's next?” von Constanze Kurz. Ein kurzer Überblick über ein Jahr Überwachungs-/Geheimdienstskandal und die politischen Folgen. Und der Versuch am Ende wieder etwas Hoffnung zu wecken.
  • „What can Python learn from Haskell?” von Bob Ippolito. Er beklagte hauptsächlich das Python so schrecklich untypisiert ist und statische Codechecker damit keine Chance hätten. Damit bemerkt man Typ-fehler erst, wenn der jeweilige Code ausgeführt wird. Für die meisten Python-Leute aber kein Problem, da wir beim Testen eine Codeabdeckung von 100% anstreben, also aller Code mindestens einmal ausgeführt wird.
• Am Dienstag ging es dann richtig los mit den Vorträgen
  • Die Keynote „Will I still be able to get a job in 2024 if I don't do TDD?” von Emily Bache. Von den Early Adopters zu der neue heiße Scheiss zu das macht man so zu das macht doch keiner mehr, jede Technologie macht diese Stufen durch. Und Emily hat ihre Einschätzung abgegeben, wo TDD derzeit steht. Wobei sie Unterschied zwischen Unittests, Integrationtests und Acceptancetests, die jeweils an recht unterschiedlichen Stellen stehen in der Durchdringung der Arbeitswelt.
  • In „The Magic of Attribute Access” hat Petr Viktorin gezeigt, welche Funktionen Python-intern aufgerufen werden, wenn man ein Attribut einer Klasse referenziert. Und wie man sich da einklinken kann, um verschiedene Sauereien zu machen.
  • „log everything with logstash and elasticsearch” von Peter Hoffmann. Mit logstash hatte ich schon mal rumgespielt, aber das es in Jruby geschrieben ist und damit eine Java-VM drunter braucht, lässt es mich dann doch immer wieder beiseite legen.
  • Bei „Full Stack Python” von Matt Makai hatte ich etwas anderes erwartet. Ich dachte, er erklärt, wie man ein System nur auf Python basierend aufbaut. Aber eigentlich hat der den Stack rund um eine Python-Web-Applikation beschrieben.
• Mittwoch
  • Keynote „Our decentralized future” von Pieter Hintjens. Der Titel war etwas irreführend, es ging mehr um Community-Management in Open-Source-Projekten. Pieter erzählte, das sie gute Erfahrung gemacht haben einfach fast alle Patches und Pull-Requests zu akzeptieren, solange sie einfachen Ansprüchen genügen. Falls dadurch Fehler in den Code kommen, ist es durch diese Regeln auch einfacher, das Fixes wieder in den Code kommen. Und es zeigt sich, das durch die existierenden Tests fast keine fehlerhaften Commits in den Code kommen...
  • Markus Zapke-Gründermann hat in „Writing multi-language documentation using Sphinx” erklärt, wie Sphinx gettext nutzt um mehrsprachige Dokumentation zu erstellen. Sehr interessant und es funktioniert etwa so, wie beim KDE-Projekt damals als ich da noch mit übersetzt habe.
  • In „Scaling with Ansible” hat Federico Marani eine Einführung in Ansible gegeben. Irgendwann schau ich mir das mal an.
  • Schlomo Schapiro hat dann in „Devops Risk Mitigation: Test Driven Infrastructure” erläutert, wie man mit Managementsystemen seine Infrastruktur automatisiert und dadurch dann auch testen kann. Und dadurch mit Tests Fehler im Produktivsystem vermeidet.
  • Ich meine, ich war nach der Mittagspause im Vortrag „Design your Tests” von Julian Bergman. Ich kann mich aber nicht mehr an den Inhalt erinnern...
  • Danach gab es mit „Graph Databases, a little connected tour” von Francisco Fernández Castaño einen Abriss, was Graph-Datenbanken können, vor allem, was sie besser (also schneller) können als klassische SQL Datenbanken: Beziehungen, vor allem die Verfolgung von Beziehungen über mehrere Stufen hinweg und mit Filtern für die Verknüpfungen.
  • „Advanced Uses of py.test Fixtures” von Floris Bruynooghe hat gezeigt, was py.test gut kann: Fixtures, also die für die Tests benötigten Daten zur richtigen Zeit zur Verfügung zu stellen.
• Der Donnerstag begann aus gutem Grund erst um 10 Uhr mit den regulären Vorträgen. Am Abend vorher war schliesslich das „Conference Dinner” mit anschließender Clubparty.
  • Das Tutorial „Iterators, Generators and Decorators” von Mike Müller hat mich etwas tiefer in den Kaninchenbau namens Python reingeführt. Iteratoren kennt man ja von anderen Programmiersprachen. Aber Generatoren und Dekoratoren sind schon ziemlich abgefahrene Konzepte. Generatoren sind eine Mischung aus Iteratoren, die aber keine Liste entlang gehen, sondern on-demand die Position errechnen und Daten zurückgeben, und aus Pipelines, denn man kann auch Generatoren schreiben, denen man auch Daten rein reicht umd dann neue Daten heraus zu bekommen. Und mit Dekoratoren kann man Funktionen (und Klassen) neue Funktionalitäten beibringen, ohne sie zu verändern. In Django etwa werden Dekoratoren verwendet um view-Funktionen mit Berechtigungsüberprüfung zu versehen ohne das in der Funktion selber zu schreiben. Einfach weil ein Dekorator eine Funktion aussen um die Funktion herum gebaut hat.
  • Bitbucket hat etwas aus dem Nähkästchen geplaudert in „The innter gut of Bitbucket” mit Erik van Zijst. Interessant.
  • „Packaging in packaging: dh-virtualenv” mit Jyrki Pulliainen: Python-Pakete mit Pip in einer virtualenv zu installieren ist schön, weil es die (Python-)Umgebung komplett kapselt. Abhängigkeiten werden also für dieses Paket installiert und beißen sich nicht mit anderen Paketen. Allerdings kann virtualenv keine nicht-Python Abhängigkeiten.
    Debian-Pakete hingegen können zwar Abhängigkeiten zu allen anderen Paketen, Python-Abhängigkeiten werden allerdings dann auch global gelöst. dh-virtualenv ist ein Helfer für Debian-Pakete, der die externen Anhängigkeiten per debian-Paketmanagement löst, die Python-App aber in einer virtualenv baut und damit Python-Abhängigkeiten lokal löst. Muss ich mir mal anschauen.
• Und schon war es Freitag:
  • In seiner Keynote „Python's Role in Big Data Analytics: Past, Present, and Future” hat Travis Oliphant seinen Weg zu und mit NumPy erläutert. Schön mal zu hören, aber ein typisch wissenschaftlicher „Past, Present and Future”-Vortrag.
  • Danach habe ich das Tutorial „Improving your automated testing with pytest” von Holger Krekel besucht. Obwohl ich schon ein paar Projekte mit pytest teste, war es doch gut mal so einen strukturierten Einstieg in die Materie von dem Erfinder selbst zu bekommen. Hat mir gut gefallen.
  • Danach war nur noch Zeit für die „Sprint Orientation”, wo verschiedene Leute vorgestellt haben, woran sie am Wochenende programmieren wollen. Und wo man sich also dazu gesellen kann.

Lightning Talks

An jedem Talk gab es eine ein bis anderthalb Stunden lange Sitzung „Lightning Talks”. Sowas wie „Open Mic”-Veranstaltungen. Man konnte sich jeweils vorher auf einem Flipchart eintragen und damit für einen 5-Minuten Slot registrieren und dann fünf Minuten lang über alles reden, was man wollte. Nur überziehen darf man bei sowas nicht, nach fünf Minuten wird gnadenlos geklatscht bzw. geht laute Musik an...

Dabei gibt es natürlich auch Kurzvorträge, die man nutzt um seine Emails zu checken. Aber es gibt eben auch gute und großartige Vorträge, an die man sich erinnert. Ein paar der Vorträge haben zu Punkten auf meiner Merkliste unten geführt. Bei einem Vortrag war ich währscheinlich nicht der einzige mit Pipi in den Augen: Ein 13-jähriges Mädchen (die bei Django-girls mitgemacht hatte) hat sich dem Feuer gestellt und darüber geredet, das sie in ihrer Umgebung anderen Mädchen/Jugendlichen zeigen will, das man Programmieren lernen muss um vom einfachen Konsumenten zum Produzenten zu wachsen.

Sprint

Wenn man anderthalb Tage Zeit hat um in Ruhe und mit vielen anderen an freier Software zu programmieren, was tut man?

Richtig, keine Zeile programmieren, sondern Dokumentation schreiben ;-)

Ich durfte den Django Girls ein Kapitel über Sicherheit in Django spendieren. Denn nachdem ich deren Tutorial durchgelesen hatte, stellte ich fest das es zwar sehr gut ist, aber leider jeder Teilnehmer ein Blog ins Netz bringt, in dem jederman einfach so Einträge erstellen, bearbeiten oder löschen kann. Nicht so prickelnd. Darum gibt es da nun eine Hausaufgabe um das System grundlegend ab zu sichern.

Gespräche

Neben den Lightningtalks sind die Gespräche in den Pausen (und auch auf dem Gang während Vorträge laufen) das wichtigste an einer Konferenz. Und natürlich die Gespräche bei den geplanten und spontanen Abendparties.

Da habe ich jede Menge interessante Leute kennen gelernt und viel Spaß gehabt. Den wahrscheinlich besten Burger Berlins gegessen. Als einziger Django-Freak auf dem Plone-Meeting gewesen. Im Görlitzer Park auf der Wiese gesessen und beim Rausgehen Tränengas geschnuppert. Einen Nutzer meiner Software JackMix getroffen. In der c-base alte Konsolenspiele gespielt und Bugs im Multiplayer-Tetris ausgenutzt:).

Was ich mir anschauen will/muss

• capturemock: Zeichnet Datenverkehr auf und spielt es bei weiteren Testdurchläufen ab.
• yamlreader: Config-Files in yaml lesen. Inklusive Support um conf.d zu einer config zusammen zu setzen
• dh-virtualenv: Debianpakete für python-Projekte bauen mit jeweils eigener virtualenv pro Paket.
  Vorteil gegenüber pip install: Auch nicht-python Abhängigkeiten möglich
• devpi: Ein lokaler pypi-mirror, ganz lokal oder im lokalen Netz. Lokale Repos mit triggern für Tests mit tox und Notiz der Ergebnisse.
• git lint: Als pre-commit-hook für git prüft es den Code vor dem commit auf Sauberkeit. Aber nur die Zeilen, die neu sind oder sich geändert haben. Damit man nicht für die Sünden der Vergangenheit bestraft wird aber der Code mit der Zeit sauberer wird.
• pytest --durations=<X> <tests> zeigt nach dem Durchlauf die X Funktionen mit der längsten Laufzeit an.
• quantifiedcode.com: Ein Codechecker im Netz.
• infrastructures.org: Haben zwei Papers über Infrastructure-as-Code. Und haben da schon 2002 viele Dinge gesagt, die jetzt bei DevOps relevant sind.
• InfluxDB: Als Alternative zu logstash oder munin. Kann logfiles bzw. klassische Logeinträge und kann Daten und Statistik.
  Kein Java, kein redis, kein elasticsearch. Nur Go ohne weitere Abhängigkeiten.