Am 15.05.2012 trifft sich die PHP Usergroup Rheinhessen in den Räumen der netz98 new media GmbH in Mainz. Ich freue mich als Sprecher dabei sein zu dürfen und werde etwas zu Dependency Injection erzählen und von unseren Erfahrungen berichten.
After reading a blog post about a Dependency Injection container in PHP I just tweeted for curiosity why PHP developers have not yet agreed on a common standard for the behaviour of an DI container. Stefan Koopmanschap jumped into the discussion and proposed I should start a movement in this particular area. He suggested that Fabien Potencier (Symfony Lead Developer) as well as David Zülke (Chief Agavi fanboy) and Matthew Weier O'Phinney (Zend Framework lead developer) should team up with me. David got hooked immediately, and I am looking forward to meet the gang at phpDay.it in Verona for the first round of discussions. In case you want to contribute as well feel free to join us or blog about this movement :)
Die Slides der Vorträge zu Real World Dependency Injection und Testing untestable code die auf dem PFCongres 2010 präsentiert wurden finden sich ab heute auf slideshare.net. Bewertungen der Vorträge können auf joind.in abgegeben werden.
Via diesem Beitrag von Jan Sorgalla bin ich auf das (relativ) neue Feature des Test-Driven Bugfixings aufmerksam geworden welches in PHPUnit seit Version 3.4.0 vorhanden ist. Out-of-the-box ist die Anbindung an Trac schon gegeben so dass dem Einsatz in unserer Development-Umgebung nichts entgegensteht, schließlich nutzen wir Trac seit 2005. Ich werde das Feature gleich mal in unsere Default-Framework-Konfiguration mitaufnehmen und bin gespannt was unsere Entwickler dazu sagen werden :)
In den letzten Monaten wurden in einigen Blogs immer mal wieder Beiträge zum Thema Dependency Injection (DI) in PHP verfasst. In einem aktuellen Beitrag von Fabien Potencier, dem Lead-Entwickler von Symfony, stellt er die These auf, dass man mitunter keinen IoC Container benötigt, um grundsätzlich vom DI Ansatz zu profitieren. Diese Ansicht kann ich nicht teilen. Aus seinem Beispiel und auch den Beispielen aller anderen Blogbeiträge wird der Nutzen von DI, vor allem im Rahmen eines kompletten Frameworks, meines Erachtens nicht klar genug dargestellt. Das Thema ist natürlich viel zu komplex um in einem kurzen Blogeintrag behandelt zu werden. Die Vorteile von DI sind schließlich vielfältiger Natur. Zu erkennen wie sauber der eigene Programmcode werden kann, wie einfach sich die einzelnen Schichten einer Anwendung testen lassen oder was die Austauschbarkeit einzelner Komponenten zur Laufzeit bedeutet, braucht seine Zeit. Das zeigt zumindest meine Erfahrung aus den letzten drei Jahren täglicher Arbeit mit DI mit unserem bitFramework.
Durch den Vortag von Mihai Corlan, einem Adobe Platform Evangelist, auf dem letzten DevDusk in Frankfurt bin ich auf den Charles Webproxy aufmerksam geworden. Im Grunde nichts anderes als ein HTTP Proxy. Was allerdings sehr schön ist, dass die Software das AMF Remoting Protokoll beherrscht und man so auf sehr einfache Weise sehen kann welche AMF Requests vom Flash / Flex Client abgesetzt und empfangen werden. Die Software erleichtert einem das Debugging sehr. Ein Wühlen in den serverseitig generierten Logfiles ist nicht mehr unbedingt nötig. Gerade wenn man nicht selbst dafür verantwortlich ist den Flash / Flex Code zu entwickeln und dementsprechend nicht direkt in der IDE debuggen kann, nimmt einem die Software doch einiges an Arbeit ab.