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.

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.

Wie schon im letzten Jahr gebloggt findet in wenigen Tagen in Leipzig die Model-Driven Development and Product Lines: Synergies and Experience Konferenz statt. Wer aus dem Umfeld kommt bzw. sich für MDD und Produktlinienentwicklung interessiert, dem kann ich die Teilnahme nur empfehlen. Wir werden durch Patrick Otto und Thomas Wollny vor Ort vertreten sein und zu den Themen Entwicklungsprozess und Praxiseinsatz mit der Generativen Programmierung berichten.

Im Rahmen eines Einsatzes bei der Internet-Agentur Scholz & Volkmer stieß ich auf ein Problem, jQuery parallel zu der JavaScript Bibliothek Prototype zu benutzen.

Damit das VMware Server 2 Paket unter Debian Lenny mit dem Defaultkernel problemlos compiliert muss vor dem Start des Installers die folgende Umgebungsvariable gesetzt werden:

Es ist schon des Öfteren vorgekommen, dass ich den DBDesigner4 unter Linux installieren musste. Weil das ganze immer mit einer kleinen Recherche im Internet zusammenhängt, wurde mir vorgeschlagen das ganze mal festzuhalten.
Das sind die 4 Schritte für eine erfolgreiche DBDesigner4 Installation:

Es kann passieren, dass Ubuntu ein Kernel-Update zur Verfügung stellt, ohne dass das zugehörige virtualbox-ose-modules Paket bereitzustellen. Nach Upgrade und einem Neustart des Rechners kann dann die Virtualbox nicht mehr ausgeführt werden. Um Virtualbox in solch einem Fall dennoch ohne lange Wartezeit wieder nutzen zu können kann folgende Lösung verwendet werden:

Am Dienstag, den 02. September 2008, veröffentlichte Google die erste Beta seines Browsers Google Chrome. Chrome wurde von Grund auf neu entwickelt und auf die Anforderungen von Webapplikationen spezialisiert.
Google's Browser ist zudem OpenSource und steht unter der BSD Lizenz.

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.