Gefunden via planet-php.org: Derik hat in seinem Blog ein Howto veröffenlicht das erläutert via man via dbgproxy mit mehreren Usern gleichzeitig eine XDebug zum Remote-Debuggen nutzen kann. Die Möglichkeit war mir bislang nicht bekannt und von daher das Interesse groß das ganze einmal auszuprobieren.
Gefunden via planet-php: Alex Netkachov zeigt wie man den internen File stream wrapper überschreiben kann. Sehr nett, vor allem eine weitere interessante Idee für meinen Vortag beim nächsten DevDusk.Mit dieser Technik lassen sich prinzipiell beliebige Dateien zur Laufzeit includen, abhängig von der Implementierung der StreamWrapper Klasse. Man könnte es wohl als "Erweiterung" zu der autoload Funktionalität sehen wobei sich diese ja "nur" auf das Einbinden von Klassen bezieht.
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.
Gefunden via Sebastian Bergmann's Blog: phpcpd - ein Copy & Paste Detector für PHP Code. Installiert wird das ganze via PEAR Installer. Nach einem ersten schnellen Test an unserem bitFramework freut es mich 0.00% duplizierten Code vorzufinden. Ich hatte auch schon länger vor auf Basis des PHP_CodeSniffers etwas ähnliches zu programmieren, mangels der nötigen Freizeit blieb es bisher bei dieser Idee.
Im Rahmen des DevDusk Events am 15.01.2009 der von der PHP Usergroup Frankfurt initiiert wurde darf ich zum Thema "Testing untestable code" einen Vortrag halten. Der Vortrag wird nicht TTD lastig werden, soll aber zeigen dass es entgegen einer weitverbreiteten Meinung doch möglich ist Anwendung mit stark gekoppelte Komponenten testen zu können. Die Ideen geistern schon lange in unseren Köpfen herum und wurden dieses Jahr im Rahmen von einigen Projekten differenziert betrachtet. Der Fokus unserer Betrachtungen lag vor allem darin ohne Refactoring des ursprünglichen Quellcodes das Ziel der Testbarkeit einzelner Komponenten zu erreichen. Die Ergebnisse möchte ich nun der blogheit vorstellen und bin gespannt welches Feedback ich dazu bekomme.
Im Zuge einer Evaluierung für eines unserer Kundenprojekte bin ich auf dropr aufmerksam geworden. dropr ist eine verteilte Message Queue für PHP und wird von Jimdo Mitarbeitern betreut. Der Vorteil von dropr liegt zum Einen darin vollständig in PHP entwickelt worden zu sein, zum Anderen wird dennoch sichergestellt dass die Datenübertragung zuverlässig und permanent funktioniert. Dank des dezentralen Architekturansatzes und der Modularisierung für die Message-Queues und den Transportmechanismen läßt sich dropr in den unterschiedlichsten Anwendungsbereichen einsetzen.
Die FireBug Extension für den Firefox Browser gehört zu unserem Handwerkszeug ebenso dazu wie die IE Developer Toolbar. Für das Debuggen von Ajax-Anwendungen allerdings sind beide Tools nicht sonderlich hilfreich. Zwar zeigt FireBug die Request und Response Daten an, dennoch wäre es hilfreich zu wissen was auf Serverseite (im Hintergrund) passiert um zu Erkennen wie die Response tatsächlich zusammengebaut wird.
Letzten Dienstag gab Johann Peter Hartmann von Mayflower in Zusammenarbeit mit MySQL ein Webseminar zum Thema Web 2.0 Security. Da ich an dem Webseminar kurzfristig leider nicht teilnehmen konnte bin ich froh, dass es den Seminar-Mittschnitt seit heute zum Download gibt. Fazit: sehens- und hörenswert!
Beim Arbeiten mit PHPUnit ist uns aufgefallen, dass es in Version 3.x von PHPUnit nicht möglicht ist, Mock Objekte so zu konfigurieren, dass Methodenaufrufe Exceptions werfen. Eine Nachfrage bei Sebastian Bergmann bestätigte, dass das Feature noch nicht implementiert ist. Wir entschieden uns kurzerhand dazu, es selbst zu implementieren und das Feature für kommende Versionen von PHPUnit bereitzustellen. Ab Version 3.1 wird man dann neben
Ein Tipp für alle PHPUnit User: Vor dem Rufen der Methode PHPUnit_Framework_TestSuite::addTestFile() darf die hinzuzufügende Testdatei nicht zuvor includiert/required werden. Da leider keine Fehlermeldung geworfen wird wenn die hinzuzufügende Testdatei zuvor schon eingebunden wurde kann die Fehlersuche ziemlich anstregend werden. Selbst im Pocket Guide von PHPUnit konnte ich keinen Hinweis auf das Verhalten finden.