PHP unconference Europe 2013

Am Wochenende fand die PHP unconference Europe 2013 in Berlin statt. Aber was unterscheidet eigentlich eine unconference von einer normalen Konferenz? Die Idee bei einer unconference besteht darin, dass jeder der anwesenden einen Vorschlag abgibt, über was er eine kurze Präsentation halten könnte oder aber auch über was er gern einen Vortrag hören würde.

Zu Beginn der Veranstaltung trägt dazu jeder seine Idee auf einen Zettel ein und alle stimmen danach ab, was sie davon interessieren würde. Daraus entsteht dann kurzfristig, welche Themen überhaupt besprochen werden. Für alle die noch auf keiner unconference waren, kann ich dies nur sehr empfehlen, am besten natürlich mit ein paar Folien im Gepäck, damit gleich ein eigener Vortrag vorgestellt werden kann. Notwendig ist dies nicht, oft kommt es auch einfach zu einer Diskussion über ein bestimmtes Themengebiet und es gibt nur einen Moderator der Anfangs fünf Minuten alle unwissenden in das Thema einführt. Wichtiger Punkt bei einer unconference, wie auch einer normalen Konferenz, ist und bleiben die Kaffeepausen und das Social Event am Abend.

Kommen wir zurück zum dies jährigem europäischen Ableger der PHP unconference in Berlin. Viele interessante Themen wurden vorgeschlagen und ausgewählt. Alle Folien und Themen und eine kurze Zusammenfassung findet ihr im Wiki der PHPucEU. Mein Vortrag über den „International Tag Set 2.0“ hatte nicht genug Stimmen bekommen, aber bei der Konkurrenz auch kein Wunder.

Ein Thema, welches in Diskussionen und den Pausen, immer wieder aufkam war CouchDB. Auch, wenn es eine PHP Konferenz war, irgendwo müssen wir Daten ja auch speichern. Gelobt wurden dabei immer wieder, wie einfach eine Replikation von CouchDB auf mehreren Servern ist und zum Teil die Geschwindigkeit. Anwendungsgebiete reichen dabei von Message Queue Server über Cache Server bis hin zu kompletten Anwendungen. Sehr viel versprechend dazu fand ich Hood.ie. Hood.ie ermöglicht es, Webseiten (besonders MobileWebApps) den Local Storage (PouchDB) mit einer entfernten CouchDB zu synchronisieren. Hiermit kann eine App erstellt werden, welche auch Offline ohne Probleme funktioniert und sobald man wieder online ist, synchronisiert sich die Lokale Datenbank mit einer entfernten CouchDB. Auf der Serverseite läuft neben der CouchDB eine node.js-Applikation, falls zusätzliche Operationen benötigt werden. Im Normalfall muss man hier aber nichts machen, da alle Funktionen schon vorliegen. Das ganze Projekt klingt sehr vielversprechend und sollte in Zukunft näher betrachtet werden. Leider konnten wir keine Live Demo sehen, da Github Probleme mit dem Filesystem hatte und genau dieses eine Repository nicht zur Verfügung stand!

Aber auch sonst gab es Interessantes aus dem PHP Umfeld zu hören. So bietet MySQL einige Neuigkeiten ab Version 5.6. Für mich am interessantesten ist dabei, dass in MySQL 5.5 eingeführte und in 5.6 ausgereifte „performance schema“. Hiermit erhöht sich zwar die allgemeine Auslastung der Datenbank, es werden aber sehr hilfreiche Informationen zum Verbessern des eigenen Schemas und Anfragen gespeichert, womit dieser Verlust sehr leicht wieder gut gemacht werden kann. Ich bin gespannt dies einmal selbst auszuprobieren. Die Empfehlung liegt hier definitiv mindestens auf einem Datenbank Server je Projekt dieses Feature aktiviert zu haben.

Den letzten technischen Punkt, den ich hier noch nennen möchte ist Puppet, dazu gab es auch gleich mehrere Vorträge am Wochenende. Durch Puppet könnte zum Beispiel eine Serverkonfiguration im Projektrepository mit abgespeichert werden, welche den Liveserver widerspiegelt oder womit dieser initial komplett eingerichtet wird - von der Installation des Grundsystems bis hin zur Installation aller benötigten Pakete, wie Apache, MySQL, PHP und Solr. In Verbindung mit Vagrant könnte sich durch Puppet jeder Entwickler schnell eine Virtualbox erstellen, welcher exakt dem Livesetup widerspiegelt.

Im Vortrag über Code/Peer Review wurde „Inspection walkthrough“ vorgestellt. Dabei setzten sich die Entwickler eines Scrum Teams in der Mitte des Sprints zusammen und wählen einen Kern-Ausschnitt der aktuellen Webseite aus. Alle Anwesenden gehen dann gemeinsam diesen Ausschnitt durch und markieren Probleme, aus Zeitgründen sollten keine Lösungen gesucht werden. Der Entwickler sollte diese Probleme im Nachhinein verbessern. Durch diesen Prozess entsteht eine Art Wissensaustausch zwischen allen Entwicklern. Wichtiger dabei ist, dass alle Entwickler Kernkomponenten gesehen haben, mögliche Fehler und Sicherheitsprobleme frühzeitig erkannt werden können und eher auch jemand anderes als der eigentliche Autor an dieser Komponente später Bugs beheben kann. Jedenfalls ein gute Idee, über die einmal nachgedacht werden sollte.

Ich habe jedenfalls an dem Wochenende viele nette Menschen kennengelernt, neue Ideen bekommen und bin gespannt auf nächstes Jahr.