Sperrobjekt Weblog

Karen Sandler bei ihrer Keynote "Cyborgs Unite!"

Auch in diesem Jahr bin ich am Samstag wieder früh aufgestanden, habe mich ins Auto gesetzt, den Unbillen der A3 zwischen Wiesbaden und Siegburg getrotzt, und habe schließlich an der diesjährigen FrOSCon teilgenommen.

In all den Jahren seit meiner ersten FrOSCon 2010 habe ich viele Menschen aus der Open Source- und insbesondere PHP-Community kennengelernt, die ich IRL oft nur einmal im Jahr treffe: eben auf der FrOSCon. Das ist immer wieder schön, und auch diesmal waren viele alte und ein paar neue Bekannte vor Ort. Manchmal reicht es nur kurz zum "Hallo"-Sagen zwischen zwei Talks, manchmal bleibt etwas mehr Zeit, um sich zu unterhalten. In diesem Jahr habe ich es ganz gut getroffen und ein paar nette Begegnungen gehabt.

Vor kurzem habe ich den Artikel What Is Snapshot Testing, and Is It Viable in PHP? von Christopher Pitt gelesen. Von Snapshot Testing hatte ich bis dahin noch nie gehört. Unter anderem fand ich interessant, wie er das Rendering von Templates testet.

It’s clear what the template should produce, given repeatable initial information. We could even mock the initial data, and assert the output.

Er nimmt einen kleinen HTML-Schnipsel, in den einige PHP-Variablen eingesetzt werden, befüllt diese einmal mit definierten Werten, und lässt einen Snapshot davon erstellen. Beim nächsten Testlauf lässt sich der Output mit diesem Snapshot vergleichen. Haben sich der HTML-Code oder die Werte aus welchen Gründen auch immer geändert, schlägt der Test fehl.

Mit spatie/phpunit-snapshot-assertions gibt es eine Bibliothek, die Snapshot-Testing mit PHPUnit bzw. Codeception möglich macht. Da ich gerade einige Codeception-Tests für ein älteres Zend Framework 1-Projekt geschrieben habe, das ich teilweise refactoren wollte, kam mir die Lib gerade recht.

Momentan dilettiere ich ein wenig an einer responsiven Webseite mit den Mitteln von Bootstrap herum. Klappt ganz gut, besonders dank des Device Mode der Chrome Dev Tools. Dazu heißt es aber auch:

Warning: Device Mode gives you a close approximation as to how your site will look on a mobile device, but to get the full picture you should always test your site on real devices. DevTools can't emulate the performance characteristics of mobile devices, for example.

Ich soll mir die Seite also auch auf einem echten Smartphone bzw. Tablet ansehen. Aber wie komme ich vom mobilen Endgerät an den Webserver, der bei mir lokal auf meinem Entwicklungsrechner (im folgenden einfach "Computer") liegt? Klar, die IP würde helfen, wenn ich nicht mehrere Virtual Hosts angelegt hätte. Klar, ich könnte jedem Virtual Host einen eigenen Port zuweisen oder ähnliches.

Was aber viel besser funktioniert und gar nicht so viel Aufwand bedeutet, ist ein weiteres Feature der Chrome Dev Tools: Remote Debugging Android Devices.

Dafür benötigen wir eigentlich nur ein USB-Kabel, um das Smartphone mit dem Computer zu verbinden, und einen lokalen Proxy (z.B. Squid) auf dem Computer.

Seit unsere Tochter klettern und laufen kann, tut sie das mit großem Vergnügen und steigt auch schon mal allein aus dem Bett aus, wenn sie keine Lust mehr auf Mittagsschlaf hat. Aus dem elterlichen Bett wohlgemerkt, denn für ihr Kinderbett mit den Gitterstäben ist sie offenbar zu freiheitsliebend Es kommt also vor, dass sie im Schlafzimmer umherläuft, ohne das wir das akustisch übers Babyfon mitbekommen. Wenn das Babyfon doch nur eine Kamera hätte …

Doch halt! Hier liegt doch noch ein ungenutzter Raspberry Pi der ersten Generation herum, einen USB-WLAN-Stick habe ich auch noch und ein paar alte Webcams - von denen leider keine so richtig unter Raspian funktionieren mag. Eine kurze Recherche ergibt, dass die günstigste lauffähige Alternative wohl eine Playstation Eye ist. Geklickt, geliefert, angesteckt: Funktioniert!

Die Babycam steht auf dem Schrank, der Karton enthält den Raspberry Pi

Ich hatte kürzlich mit einem Projekt auf Basis des Flow Frameworks zu tun. Zu den Besonderheiten dieses PHP-Frameworks gehört unter anderem die Unterstützung von Aspect-Oriented Programming (AOP), mithilfe dessen sich generische Funktionalitäten relativ sauber über verschiedene Klassen hinweg verwenden lassen (cross-cutting concerns). Wie das funktioniert, ist in der Dokumentation ausführlich beschrieben.

Zu diesem Zweck erstellt Flow automatisch Proxy-Klassen, welche die Original-Klassen erweitern und die nicht zuletzt aus Performance-Gründen gecachet werden. Dabei werden gegebenenfalls Aspekte, Pointcuts oder Advices in Klassen "eingewoben". Die Applikation verwendet die auf diese Weise generierten Klassen, in der Entwicklung wird aber weiterhin nur mit den Originalen gearbeitet.

Ein bedeutender Nachteil dieser Vorgehensweise ist, dass Debugging - z.B. mit XDebug - nicht mehr ohne Weiteres möglich ist, denn die IDE kennt nur die Original-Klassen, nicht aber die dynamisch erstellten Proxy-Klassen. Um dieses Problem zu lösen, wurde flow-debugproxy geschreiben, ein Flow Framework Debug-Proxy for XDebug in Go, der die Proxy-Klassen auf die Original-Klassen "mappt".

Da dieser Proxy nicht ganz trivial zu installieren ist, habe ich hier eine kurze Anleitung aufgeschrieben, die in dem genannten Projekt funktioniert hat (und mir nebenbei eine Kiste Bier eingebracht hat ):