Am Samstag den 18.04.2015 wurde in Mannheim zum zweiten mal die sogenannte unKonf in den Räumlichkeiten der Kollegen von bitExpert ausgerichtet. Ich war wie auch schon im Vorjahr vor Ort.
Eine unKonf(-erenz) zeichnet sich wie eine Art Barcamp dadurch aus, dass es zuvor keine festen Session gibt. Jeder der Teilnehmer kann in einem Grooming Vorschläge einreichen. Man wird sogar dazu aufgefordert. In diesem Jahr belohnte der dpunkt.verlag jeden Redner mit einem Buchgutschein.
Über 18 Talks in 6 Slots verteilt auf 3 Lokalitäten wurde abgestimmt. Nachdem es im letzten Jahr gewünscht wurde, konnten diese nun in einer eigens für die unKonf entwickelten App (Android, IOS und HTM5) von jedem Teilnehmer eingesehen werden.
Eine Änderung bei den Sessions gab es jedoch. Es wurde eine Keynote eingeführt. Gehalten wurde diese von Stefan Koopmanschap, den man besser unter seinem Twitter Handle @skoop kennt.
Statt mit einem Vortrag über irgend eine coole Technik überraschte uns Stefan mit einem Thema, welches in bei den amerikanischen Kollegen bereits schon länger durch Ed Finkler (@funkatron) vertreten wird: Mental Health. Stefan hob hervor, wie wichtig es ist, in kniffligen Situationen im Arbeitsalltag einfach mal um Hilfe zu fragen. Die wenigsten weisen einen ab, sondern können meist durch einen zweiten Blick Probleme relativ schnell beheben. Zudem wäre es doch ziemlich schwierig in allen Bereichen perfekt zu werden. Er selbst würde es wohl niemanden zumuten, mit einem von ihm geschriebenen Frontend zurecht zu kommen. Auch muss man nicht jedesmal das Rad wieder neu erfinden, anstatt bestehende Lösungen für ein Problem zu nutzen. So stellte er die Frage: „Wer hat schon sein eigenes Framework zusammengebaut?“ Grundsätzlich ist das etwas, was man mal getan haben sollte, allerdings nicht für den produktiven Einsatz, sondern als Lernprojekt.
Im gesamten Vortrag nahm er immer wieder Bezug auf ein Buch was Ihn inspierierte: „The Art of Asking – Amanda Palmer“. Die Autorin ist keine Programmiererin, sondern Sängerin. Ihre Mutter jedoch schon. Und als die 13jährige Amanda Ihre Mutter fragte, ob sie denn keine Künstlerin sei, bekam sie folgende Antwort:
You can’t see my art, but … I’m one of the best artists I know. It’s just … nobody could ever see the beautiful things i made. Because you couldn’t hang them in a gallery.
— Antwort der Mutter auf die Frage der 13 jährigen Amanda
Für mich ist das eine der besten Beschreibungen eines Problems, das ich auch nur allzu gut kenne. Man versucht nicht-Geeks seine Arbeit zu zeigen, doch die eigentliche Magie hinter einem schicken Frontend kann sich kaum jemand vorstellen. Auch Stefan konnte dazu ein Beispiel nennen. Seinen Eltern hat er den nagelneuen von ihm gebauten E-Commerce Shop gezeigt, worauf er nur als Antwort bekam: Ja, bestellen kann man doch überall.
Die Slides und Diskussionen zu dem Vortrag findet man in joind.in.
Nach der Keynote gab es für mich dann noch 5 weitere Sessions, die sowohl Talk- als auch Diskussionscharakter hatten.
Diskussion – Microservice/Integration/Middleware
Leider wurde der als Diskussion angekündigte Slot hauptsächlich von 2 Personen bestritten. Trotzdem konnte ich hier für mich ein paar Sachen mitnehmen. Will man eine monolithische Architektur in kleine Services zerteilen, kommt es zum einem darauf an, wie man schneidet und wie die neues Services dann mit einander kommunizieren sollen. Von einem der Gesprächsteilnehmer wurden immer wieder Beispiele aus dem Prozess der Umstrukturierung von Otto vorgetragen. Diese können unter anderem in diesem Artikel im Blog der Otto-Developer nachgelesen werden. Kontrovers wird es bei der Frage „Wann ist micro zu micro“: Reicht eine simple Validierung einer Email-Addresse als Funktionalität schon aus? Was passiert wenn mehrere Services auf den selben Daten Arbeiten? Hier wurde hervorgehoben, dass wichtig ist, immer ein führendes System zu definieren, welches die Hoheit über einen bestimmten Bereich hat.
Vorstellung – VersionEye
Im Vortrag zum Thema VersionEye kam ich zu spät an. Als ich zuerst die Slides dazu an der Wand gesehen habe, fragte ich mich: „Warum werden hier nur die Daten aus Packagist nur anders dargestellt?“ Schnell musste ich aber feststellen, dass es sich bei VersionEye um eine Applikation handelt, die es mir ermöglicht veraltete Dependencies in meinem Projekt zu erkennen. Ich kann mich bei Änderungen sogar informieren lassen.
Dabei verwendet VersionEye die gängigen Konfigurationsdateien von Package-Managern wie composer.json, bowser.json, pom.xml oder package.json die auf Github oder Bitbucket liegen. Kommuniziert wird hierbei über die API beider Web-Anwendungen. Mit einem Community-Account kann man beliebig viele public und ein privates Repository von VersionEye tracken lassen. In der Enterprise-Version kann man zusätzliche private Repositories prüfen lassen und erhält ein nettes weiteres Feature: „Whitelisting von Lizenzen“.
In vielen Projekten verliert man schnell den Überblick über die Lizenzen die in der Kaskade der Dependencies zur Anwendung kommen. Mit VersionEye kann man sich diese nicht nur anzeigen lassen, man kann auch bestimmte Lizenzen für sein Projekt „whitelisten“ um vor ungewollten Lizenzen gewarnt zu werden. Dazu kannte VersionEye bereits schon nahezu 200 Lizenzen.
Vortrag – REST mit HATEOAS
Oliver Gierke stellte kurz die Grundprinzipien von REST und HTTP vor. (Methoden, URLs und Status). Schnell kam er zu dem Ergebnis „REST ohne HATEOAS ist kein REST“, was durchaus plausibel verargumentiert werden kann. Links können abhängig vom Zustand dargestellt werden (Ist der Nutzer eingeloggt oder nicht?). Die Beispiele des REST Servers waren in Java, der Content in JSON. Aufgrund des Content Types ging er kurz auf die sog. HAL-Spezifikation ein, denn grundsätzlich ist JSON für REST nicht geeignet, da es darin keine native Implementierung für Links gibt. Dies ist aber DER Grundbaustein für HATEOAS („Hypermedia as the engine of application state“). Ein geeigneter Client ist mit diesen Links in der Lage, selbständig alle Ressourcen für die Applikation zu finden.
Diskussion/Vortrag – ngAnimate in Verbindung mit Filtern
Der Referent hat ein Problem in Angular Applikationen dargestellt, das auftritt, wenn man große Datenmengen zum Beispiel über ein ngRepeat darstellen und filtern möchte. Denn kommt hier ngAnimate ins Spiel (auch implizit über Dependencies), sinkt die Performance signifikant. Das liegt daran, dass Angular mit ngAnimate unzählige Listener auf sämtlichen Knoten im DOM der Applikation registriert, um für mögliche Events gewappnet zu sein. So auch in einer langen Liste wie einer Tabelle mit ngRepeat über 5000 Zeilen. Nutzt man jetzt den Filter von Angular, wird die Suche nicht mehr so schnell sein wie gewohnt. Das liegt hier nicht an der großen Datenmenge, sondern am Overhead durch die Listener. Leider scheint es noch relativ schwer zu sein, ngAnimate entweder global oder in einem bestimmten Bereich zu deaktivieren. Der Referent berichtete, dass selbst ein in der Dokumentation aufgeführter Parameter ignoriert wird. Abhilfe schafft hier, ngAnimate ein anderes Pattern zu verpassen auf welche Klassen es angewendet werden soll. Ein selten passendes wie „/abc/“ verhindert den Effekt, so dass man später gezielt die gewünschten Knoten reintegrieren kann.
Conclusion zur unKonf
Auch in diesem Jahr war die unKonf wieder eine Bereicherung für mich. Allein die Keynote war riesig. Trotz kostenfreier Teilnahme bietet der Veranstalter ein rundum stimmiges Programm, nicht zuletzt durch App für die Sessions. Alle Sessions findet man in joind.in.
Schreibe einen Kommentar