Abseits der Sprint-Räume, die auch während der drei Session-Tage durchgehend gut besucht wurden, habe ich mir am Freitag verschiedene Vorträge zu Themen rund um Drupal 8 angehört, auf die ich im Folgenden kurze eingehen werde.

Kevin Kaland (wizonesolutions) zeigte mit Rewriting Contributed Modules for Drupal 8 am Beispiel eines Drupal-Moduls, dass Contrib-Module, die bisher für Drupal 7 verwendet werden, nicht nur portiert, sondern mehr oder weniger von Grund auf neu geschrieben werden müssen. Weil die grundlegenden Strukturen von Drupal mit dem Sprung auf Version 8 so massive Änderungen erfahren, bspw. durch die Integration von Symfony, die Neukonzeption von Routing und vom Menu-System sowie der Abkündigung vom Drupal-eigenen _hook-Mechanismus, ergibt es Sinn, die bisherigen Wege und architektonischen Entscheidungen auf den Prüfstand zu stellen, die gewünschten Funktionalitäten auf Basis der aktuellen Design Patterns neu zu implementieren und (bestenfalls) bestehende Inhalte in die neuen Systeme zu migrieren.

Das stellt kurzfristig Site-Buildern und Entwickler eine nicht unwesentliche Hürde zur Verwendung von Drupal 8 dar, da ein Upgrade mit ziemlicher Sicherheit wesentlich umfangreicher wird als bei bisherigen Upgrades. Mittel- bis langfristig ergeben sich jedoch zahlreiche positive Effekte aus diesem technologischen Bruch: Wir werden von Anfang an dazu erzogen, fortschrittliche Design Patterns zu implementieren, können möglicherweise Symfony-Komponenten wiederverwenden und uns von vielen Ärgernissen verabschieden, die seit langer Zeit zur Entwicklung mit Drupal dazugehörten (z.B. Konfiguration in der Datenbank, mäßig gutes Caching & Konzept-Wildwuchs).

In der nächsten Session, Perform code reviews inside your development team von Rodrigo Aguilera (rodrigoaguilera), wurden erstens die großen Vorteile von Peer-Reviews, und zweitens praktische Hinweise zur Einführung in bestehende Drupal-Entwicklungsprozesse vorgestellt.

Der Nutzen von Code-Reviews ist vielfältig: Sie setzen eine Definition und Einhaltung von Best Practices und Coding Styles voraus, die insbesondere für neue Entwickler, die ins Team eingeführt werden, hilfreiche Regeln und Hilfen bereitstellt. Darüber hinaus verteilt es den "Code Ownership", d.h. die Verantwortung für bestimmten Code, auf mehrere Schultern und kann für transparentere Entwicklungsprozesse und offenere Diskussionen über Code & Architektur sorgen. Und selbstverständlich steigt sowohl die Code-Qualität mit diesen Interaktionen als auch der Wissenstransfer zwischen den einzelnen Entwicklern.

Um Code-Reviews als festen Bestandteil von Entwicklungsprozessen zu etablieren, bedarf es entsprechender Infrastruktur und Tools. Das können einerseits computergestützte Reviews sein, die die Einhaltung von Coding Standards (z.B. PHP CodeSniffer) prüfen sowie verschiedene Arten von automatischem Testen durchführen, wie es u.a. mit PHPUnit oder Behat möglich ist. Und andererseits können bestimmte Tools, die sich in den Entwicklungs-Workflow integrieren lassen, Peer-Review ermöglichen oder vereinfachen; In verschiedenene Repository-Oberflächen (Github, Gitlab, Bitbucket) kann beispielsweise Quelltext Zeile für Zeile annotiert und kommentiert werden, und ermöglicht so einen dokumentierten Austausch über Code. Nicht zu vernachlässigen ist auch die Möglichkeit, ganz "old school" im Pair Programming mit mehreren Teammitgliedern zusammen zu entwickeln.

Auf sehr großes Interesse stieß außerdem Théodore Biadalas (nod_) Vortrag Javascript for Backend Developers, in dem Théodore zutreffend feststellte, dass kein Backend-Entwickler mehr ohne (zumindest) rudimentäre Javascript-Kenntnisse auskommt und sich zudem recht kritisch mit diversen "Buzzwords" und Hypes" aus der Javascript-Welt auseinandersetzte.

Wenngleich die Javascript-Innovationszyklen im Vergleich zu PHP ziemlich kurz ausfallen, lassen sich doch bestimmte Buzzword-übergreifenden Facetten und Grundsätze erkennen, die für eine nähere Beschäftigung mit Javascript-Frameworks sprechen:

  • Erstens steigt die Nachfrage nach "Headless"-Applikationen, Single Responsibility Networks stetig
  • zweitens ist die Einstiegshürde für Entwicklung mit Javascript-Frameworks weniger dramatisch als bei Symfony und ihrer weiteren PHP-Konkurrenz
  • drittens schafft die steigende Verbreitung von node.js (a.k.a. io.js a.k.a node.js) die Möglichkeit, [isomorphe](http://isomorphic.net/javascript) Anwendungen zu entwickeln, die sowohl auf dem Server als auch im Client denselben Code verwenden können.

Es wird entgegen der allgemeinen Euphorie davon abgeraten, Angular zu verwenden, und stattdessen Backbone empfohlen, das wesentlich kompakter und performanter sei. Die Drupal-Community entschied sich für genau dieses Javascript-Framework. Bleibt abzuwarten, ob diese Entscheidung ähnlich richtig und richtungsweisend sein wird wie die zugunsten von jQuery.

Einer von drei gut gefüllten Vortragsräumen

Peter Droogmans (attiks) präsentierte mit Responsive Images in Drupal 8 einen der vielen Gründe, warum Drupal 8 insbesondere hinsichtlich Responsive Webdesign einen riesen Schritt nach vorne machen wird: Das von Drupal 8 unterstützte HTML5-<picture>-Tag ermöglicht Webseiten, die für ein Bild unterschiedliche Dateien in verschiedenen Größen anbieten, von denen der verwendete Browser nur jene Bilddatei auswählt und lädt, die im jeweiligen Kontext Sinn ergibt.

Das entlastet Server, beschleunigt Ladezeiten und ermöglicht einfacheres, gerätetypenspezifisches Webdesign, und wird für ältere Browser (Internet Explorer 8), die das <picture>-Tag nicht unterstützen, mit einer Fallback-Option per Polyfill unterstützt. Drupal 8 bietet diese Möglichkeiten - ohne dafür Contrib-Module bemühen zu müssen - und kann für Image-Felder pro Breakpoint einen "Image Style" spezifizieren lassen. Wer sich diese Funktion für seine bestehenden Projekte auf Basis von Drupal 7 wünscht, wird sich über den Modul-Backport namens Picture freuen.