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 :)

Die Sun Presenter Console unterstützt beim Vorführen einer Impress-Präsentation. Die Extension für OpenOffice Impress erweitert die Funktionalität der Präsentationssoftware so, dass beim Präsentieren auf Beamern der Bildschirm des PCs eine Folien- und Notizansicht angezeigt wird.

Als Alternative zur ODBC Verbindung in die Windows-Welt ist es möglich die MSSQL Extension für PHP nativ unter Linux zu kompilieren und einzubinden. Danne Lundqvist hat dazu in seinem Blog einen entsprechenden Artikel verfasst.

In einem aktuellen Projekt ist es notwendig, dass unsere Anwendung mit einem MSSQL Server kommuniziert. Grundsätzlich natürlich kein Problem, wenn wir die Möglichkeit hätten auf dem Server per PHP Skript einen direkten Zugriff zu erhalten, um von dort aus die Daten in unsere Postgres Datenbank zu pushen. Allerdings haben die Systemadministratoren des Kunden naturgemäß etwas dagegen. Es bleibt also nur der Direktzugriff per unixODBC / FreeTDS von einem der Debian-Server auf dem unsere Anwendung läuft. unixODBC ist eine Open Source Implementation der in der Windows-Welt populären ODBC API. Bei FreeTDS handelt es sich um die freie Implementation des TDS Protokolls, welches unter anderem auch vom Microsoft SQL Server genutzt wird.

Dank Robert Lemke vom Typo3 Projekt gibt es seit einigen Tagen einen RFC für sog. Custom Factories für PHP. Die grundsätzliche Idee des RFC ist es, via SPL die Objekterzeugung beeinflussen zu können, ähnlich wie es bsp. mit spl_autoload möglich ist, eigene Klassenloader zu definieren. Er möchte damit Einschränkungen in Legacy Bibliotheken aufbrechen, die es aufgrund von fest verdrahteten Abhängigkeiten nicht möglich machen, eigene Komponenten innerhalb der Legacy-Bibliothek zu verwenden. Im aufgeführten Beispiel wird dies gut anhand eines Logger-Beispiels aufgezeigt. Im Grunde halte ich die Idee für recht interessant. Ich denke, viele Entwickler sind in der Vergangenheit über das Problem gestoßen dass sich Frameworks oder Bibliotheken von Drittanbietern an manchen Stellen nicht optimal in die eigenen Anwendungsstrukturen einbinden lassen konnten bzw. es nur sehr umständlich möglich war, eine Integration zu erreichen.

Gefunden via Twitter: Nils Hartmann beschreibt in seinem Blog wie man mittels Eclipse Xtext und Xpand PHP Code anhand einer domänenspezifischen Sprache (DSL) generieren kann. Der leider etwas knappe Artikel macht Appetit auf mehr und zeigt auf, wie man durch eine DSL den Arbeitsablauf optimieren und Routinearbeiten automatisiert durchführen lassen kann. Ich werde mir XText einmal genauer ansehen und prüfen, inwiefern wir dieses Programm in unsere Arbeitsabläufe integrieren können.

Gefunden via planet-php.org: Derik hat in seinem Blog ein Howto veröffentlicht, 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 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.

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 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.