Skip to content

JSONL - JSON Lines text format

Mal wieder etwas Schönes aus dem Entwicklungs-Alltag und was so alles anders kommen kann. Es sollen einige Zehntausend Datensätze aus Export-Dateien in die Datenbank importiert werden.

Abgesprochen waren XML-Dateien, weil das in einer früheren Version der Applikation auch so gehandhabt wurde. Meine Bitte war, dass diese Dateien zumindest komprimiert bereitgestellt werden sollen, damit der Download nicht so lang dauert wie bisher.

Geliefert wurden dann *.json.gz-Dateien, zwar komprimiert, aber wie aus der Dateiendung ersichtlich - kein XML. Egal, ich nehme sehr gern auch JSON. Also die Dateien erstmal entpacken und gucken, ob die Daten auch so aufgebaut sind wie erwartet.

"JSONL - JSON Lines text format" vollständig lesen

Lokalen Virtual-Host von Android-Gerät aus aufrufen

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.

"Lokalen Virtual-Host von Android-Gerät aus aufrufen" vollständig lesen

PHPUnit für die Entwicklung von Serendipity-Plugins

Geben wir es ruhig zu, der PHP-Code von Serendipity ist nicht mehr State of the Art, sondern zum großen Teil noch auf dem Stand von PHP 4. Dass dieser Code immer noch sehr zuverlässig funktioniert, und ob und wie mit dem aktuellen Stand umzugehen ist, soll hier nicht das Thema sein. Ich möchte hier auf die Entwicklung von Serendipity-Plugins eingehen, die nicht umsonst in einem eigenen Repository leben. Deren Qualität lässt sich mithilfe von Unit Tests sicherstellen.

PHPUnit für Plugins

Auch wenn die Grundfunktionalität von Serendipity durch Unit Tests abgedeckt ist: Die Plugin-Entwicklung ist bisher nicht so einfach zu testen. In meinen letzten Projekten waren Unit Tests mit PHPUnit ein zunehmend zentraler Bestandteil der Entwicklung. Entweder damit ich nachträglich sicherstellen konnte, dass Klassen und Methoden bei Veränderungen und Refactoring noch taten, was sie tun sollten; oder weil ich testgetrieben entwickelte, das heißt zuerst die Unit Tests und dann erst den zu testenden Code schrieb. Dieses Vorgehen möchte ich nicht mehr missen, und es hat mich gestört, dass es bei der Entwicklung von Serendipity-Plugins nicht ohne Weiteres möglich war.

Screenshot einer Konsole mit erfolgreich durchlaufenen Unit Tests

Daher habe ich mich hingesetzt und PHPUnit so in meine lokale Serendipity-Installation, die ich zum Entwickeln verwende, integriert, dass ich einzelne (Event-)Plugins separat testen kann. Die spezifischen Herausforderungen ließen sich recht schnell überwinden:

  • In Serendipity werden Plugins stark getrennt vom Core über Event-Hooks ausgeführt. Diese Hooks müssen natürlich einzeln getestet werden können.
  • Viele Variablen sind als global deklariert oder werden per Referenz "herumgereicht". Das erfordert einige Workarounds, die heute dank Dependency Injection und ähnlichen Entwurfsmustern zum Glück überflüssig sind.
  • Data Fixtures: Um Serendipity für die Tests "hochzufahren", wird eine Datenbankverbindung benötigt. Mir ist es bisher nicht gelungen, eine der unter Database Testing aufgeführten Methoden umzusetzen. Besser gesagt: Ich war einfach zu faul und habe die nötigen Daten in einer SQLite-Datenbank hinterlegt.
"PHPUnit für die Entwicklung von Serendipity-Plugins" vollständig lesen