Symfony kam dieses Jahr mit zwei Tagen Workshops und einem Tag Konferenz. Ich war am Konferenztag dabei:

Tobias Nyholm hat in seiner Keynote die ketzerische Frage gestellt, was denn Symfony heutzutage überhaupt ist. Vor ein paar Jahren war die Antwort klar, es ist eine Sammlung von Ordnern, Bundles, Funktionalitäten - eben ein Framework. Das stimmt so nicht mehr, da Symfony viel stärker modular aufgebaut ist und man sich einzelne Symfony-Komponenten für eine Anwendung zusammenstellen oder je nach Anwendungsfall sogar vollständig auf sie verzichten kann. Ersteres halte ich als notorisch zeitgeplagter Nutzer für abwegig, da unnötig kompliziert, zweiteres kann bei extrem einfachen Anwendungsfällen (Redirects) Sinn machen und macht sicherlich jeder intuitiv, zumal das einfach ist. Um einem vermeintlich lahmen Framework Beine zu machen hilft natürlich bekannterweise immer schnellere Hardware, Caching und weniger Code. Eine interessante neue Erkenntnis gab es dann doch: "Don't kill the chef!" PHP wird anscheinend üblicherweise in einem Modus ausgeführt, der für jeden Aufruf einen eigenen Prozess startet und diesen anschließend killt (was im Vergleich mit einem Restaurant nicht der Fall wäre; niemand würde pro Bestellung einen neuen Koch engagieren, um diesen nach Zubereitung der Gerichte einer Bestellung umzubringen). Dies verursacht unnötigen Overhead, der sich mit PHP-FPM verringern lässt, aber mit dem FastCGI-Servermodul zusammen mit dem FastCGI-Modul https://github.com/PHPFastCGI/SpeedfonyBundle noch weiter reduzieren lässt. Das war mir neu und ist doch mal anschauenswert. Achso, und was ist Symfony jetzt? - "Wir sind Symfony". Tschakka.

Andreas Braun, der Mitentwickler vom Doctrine-Bundle ist, erzählte erstmal vom Krieg. Das waren noch Zeiten, als wir ohne Getter und Setter in die Entities geschrieben haben. Und dann der Hammer: Das Maker-Bundle kann Relashionships: Das ist ja wie Weihnachten! Das hab ich völlig verpasst und wird sofort eingesetzt. Ansonsten gab es viele Insights zu allen Doctrine-Bundles und deren Aufgaben. Doctrine versucht immer mit den aktuellsten PHP-Versionen mitzugehen, ist aktuell bei 7.2 und wird auch bald auf 7.4 übergehen. Die Deprecation Notices sollte man daher ernst nehmen, wenn man sich bei Updates Aufwand sparen will. Doctrine hat den einen oder anderen Legacy-Code über die Jahre angesammelt und freut sich daher über Contributions.

Pimcore ist laut Christoph Lühr der Chuck Norris von einem Datenmanagementsystem. Und Shopsystem. Und CMS. Und CRM. Und basiert natürlich auf Symfony und ist OpenSource. Die Grundidee ist, dass man in dem System (Produkt-)Daten mit hoher Komplexität (Sprachen, Varianten und mit Assets) speichern und in diverse Kanäle (Webshops, Druck-PDFs etc.) ausspielen kann. Das Ganze scheint sich nicht nur für Produkte zu eignen, sondern auch für den Kundensupport. Der größte technische Clou ist aus meiner Sicht, dass das System anscheinend Datenbanktabellen modifiziert, wenn man im Backend (ohne Programmierung übrigens) das Datenbankschema anpasst. Das dürfte diverse teure Joins sparen und es damit schneller machen als andere ähnlich gelagerte Systeme wie z. B. Drupal machen. Trotz des Marketing-Rummels finde ich das System durchaus anschauenswert.

Petr Heinz hat den schwarzen Gürtel in GIT. Inline-Kommentare von Code können manchmal praktisch sein, aber irgendwann laufen die unverbunden mit dem sich ändernden Code nebenher und wer hat schon Tests für Inline-Kommentare. Eine aufgeräumte GIT-History mit erklärenden Kommentaren auf möglichst atomaren Commits ist die sauberere Variante. Und GIT bringt alles mit dazu: git commit --amend ändert den letzten Commit. git rebase verflacht verzweigte Commits, als wären sie nacheinander passiert. Es tut also was ähnliches wie merge, aber macht die Historie ggf. übersichtlicher. Mit --interactive kann man bei Bedarf sämtliche Commits dazwischen ändern (edit), löschen, nur deren Message ändern oder Commits zusammenfassen. Wenn man einen einzelnen Commit codeseitig in der Vergangenheit ändern will, kann man das über einen Fixup tun. Man committed die Änderung per git commit --fixup=HASH und diese wird dem alten Commit zugeordnet. Bei einem rebase mit dem Parameter autosquash werden solche Änderungen dann automatisch zusammengeführt und man sieht sie anschließend nicht mehr in der Historie. Die Präsi gibt's hier: http://shopsys.com/u/clean-git

Ole Rößner plädiert für mehr Handwerkskunst bei der Softwareentwicklung. Es handelt sich um einen Teamsport, man sollte seine Tools kennen, Shortcuts lernen und Wissen weitergeben, eben wie Handwerker. Dies kann man institutionalisieren z. B. durch Katas (Übungen) und Randoris (gemeinsame Übungen mit Wissensweitergabe), die man in Dojos (Übungsräumen) durchführt.

Trivago läuft auf Symfony, wow. Jorge Gonzales gab Einblicke, wie Trivago Blackfire und diverse andere Tools einsetzt zur kontinuierlichen Performanceüberwachung. Neuer Code wird auf Testservern u. a. auf Performance getestet, bevor er deployed wird. Ganz beeindruckend fand ich, dass man auf Funktionsebene sehen kann, wo ggf. ein neues Bottleneck aufgetreten ist.
Links:
https://tech.trivago.com/2017/10/27/continuous-performance-monitoring-for-php---the-tale-of-blackfire-at-trivago/
https://tech.trivago.com/2018/10/12/building-fast-and-reliable-web-applications/

Stefan Adolf von Turbine Kreuzberg, das weder ein Fußballclub, noch ein neues Berghain und auch kein Coworkingspace ist, soviel hab ich gelernt, berichtete über den Einsatz von Webpack im Zusammenspiel mit Encore. Webpack erleichtert das Bundling von Frontend-Ressourcen in Abhängigkeit von deren Notwendigkeit auf der jeweiligen Seite. Die Konfiguration ist eher umständlich und daher gibt's Encore. Das erlaubt einen extrem effizienten Entwicklungsworkflow, der z. B. Änderungen an CSS beim Speichern automatisch per SASS compiliert und einen Refresh des geänderten Inhalts (bzw. der ganzen Seite bei Encore) im Browser triggert. Mir fielen die Augen aus, als er dafür meinen neuen Lieblingseditor VS Code verwendete, aber er verriet mir hinterher, dass er das nur für Frontend tut. Für PHP und Symfony ist weiterhin PHPStorm State of the Art. Code zur Demo gibt's hier: https://github.com/elmariachi111/encore-demo

Christian Flothmann und Christopher Hertel sind beide Trainer bei Symfony und stellten launig zweieinhalb Wege vor, wie man in Symfony mit dem Rich Domain Model arbeiten kann. Was ist das Rich Domain Model? Also in etwa das Gegenteil von Datenbank-Entities, die eher ein Anemic Data Model haben und wenig bis keine eigene (Validierungs-)Logik mitbringen. Mit einem anemischen Datenmodell kann man potentiell Unsinn machen, während ein Rich Data Model eher sicherstellt, dass es konsistent ist. Das Ganze ist wohl eine Glaubensfrage. Symfony bietet von Haus aus kein Rich Domain Model an. Wenn man es trotzdem einsetzt dupliziert man potentiell Validierungscode und schafft sich neue Probleme. Mit dem Einsatz eines selbstgebauten DataMappers kann man sowas ähnliches wie ein Rich Domain Model einsetzen und muss insbesondere keine Validierer mehr nutzen, aber das macht Code schwer testbar. Die neue Lösung: RichModelFormsBundle, das noch beta ist. Der Datenfluss ist dabei der gleiche wie im jetzigen anemischen Datenmodell, was aus Codesicht relativ einfach ist. Ich stellte mir als Datenbänkler, der Formulare immer nur zur Datenübertragung in Tabellen versteht, die Warum-Frage. Wir haben jetzt schon eine doppelte (und damit schnell mal inkonsistente) Validierung einerseits durch Formularcode und dann nochmal durch die Datenbank. Ob diese Inkonsistenz durch Validierer im Formular oder in einem Rich Data Model entsteht, ist eigentlich egal - ich finde sie in beiden Fällen nervig und fast immer redundant. Aber vielleicht setzen andere Leute Formulare ja auch für anderes ein.

Alles in allem war das eine coole Konferenz, bei der auch das Networking nicht zu kurz kam (wenn man sich die Fachkräftemangel-bedingte Recruitinglastigkeit wegdenkt). Die nächste findet 24.-27.9.19 statt. Für Blind Bird Tickets: https://berlin2019.live.symfony.com/

Ergänzungen und Korrekturen sind übrigens willkommen.