PHP-Entwicklung: Full-blown IDE vs. Text-Editor

Das Entwickeln von PHP-Applikationen ist die Tätigkeit, mit welcher ich die meiste Zeit des Tages beschäftigt bin. Das ist Grund genug, ständig nach Dingen zu suchen, die mir diese Arbeit erleichtern.

Das zentrale Tool für die Entwicklung ist dabei das Programm, in welchem ich Code eingebe, ändere, suche, ersetze, verwalte und vieles mehr. Gerade hier ist über die Jahre eine Menge passiert, vieles aber doch gleich geblieben. Anfangs – noch als Windows-Nutzer – habe ich Editoren wie z. B. SciTe, Notepad++, UltraEdit o. Ä. zum Coden benutzt. Da er bei der Arbeit auf Servern zu den wichtigsten Tools gehörte und allgegenwärtig war, lernte ich später auch Vim und nutzte ihn dann in der grafischen Version GVim als meinen primären PHP-Editor.

Mit dem Umstieg auf OS X rutschte Vim als Alltagseditor etwas aus dem Fokus, was auch daran lag, dass es damals noch keine anständige Umsetzung für den Mac gab (diese wurde dann in Form von MacVim um 2007 oder 2008 veröffentlicht). Zwischenzeitlich wechselte ich – wie vermutlich fast jeder zu dieser Zeit – auf TextMate, welcher mit seinen Plugins (im TextMate-Sprech Bundles genannt) unfassbar leistungsfähig war.

Hin und wieder wagte ich den Blick über den Tellerrand und schaute mir integrierte Entwicklungsumgebungen mit PHP-Support an. Es gab zwar durchaus einige (mir fallen spontan NetBeans, Komodo, Eclipse PDT und Zend Studio ein) aber nichts konnte mich überzeugen. Ich ließ mir aber ein fertig konfiguriertes NetBeans liegen, welches ich zum Step-by-Step Debuggen nutzte – das war das einzige wichtige Feature, das mir TextMate nicht bieten konnte.

Die IDE-Welt wurde dann mit dem Erscheinen von JetBrains PhpStorm hart durchgerüttelt. PhpStorm wuchs gerade in den letzten beiden Jahren zum defacto-Standard der PHP-IDEs heran. Nach und nach verlagerte ich meine PHP-Entwicklung auch komplett nach PhpStorm. JetBrains legt in einer unglaublichen Geschwindigkeit neue Features nach, auch die Unterstützung neuer PHP-Versionen und Tools wie Composer ließen nie lange auf sich warten.

Auch ein Grund, mit dem mich JetBrains überzeugen konnte, jedes Jahr etwas Geld auszugeben um die Lizenz zu verlängern, war der Umstand, dass PhpStorm für eine riesige Java-Desktop-Applikation ausreichend schnell war.

Leider hat sich das zuletzt geändert. Auch auf neuen Rechnern fühlt sich PhpStorm nicht mehr flüssig an, es ruckelt mittlerweile an allen Ecken und Enden. Dieser Umstand führte in letzter Zeit dazu, dass ich wieder öfter zum Text-Editor greife, statt PhpStorm zu booten.

Zum Glück ist der Markt der Text-Editoren lebendig wie nie zuvor. TextMate kommt seit einiger Zeit in Version 2 (Beta) daher und ist immer noch wunderbar zum Entwickeln von PHP-Applikationen mit allem was dazu gehört geeignet. Github hat mit Atom einen nagelneuen Editor entwickelt, auch wenn dieser konstruktionsbedingt (basiert auf dem Chromium-Browser) ein paar Nachteile hat. Seit einigen Jahren ist allerdings Sublime Text der Platzhirsch der Code-Editoren. Sublime Text bietet wie auch TextMate Unterstützung für Plugins und kann so auf den eigenen Bedarf angepasst werden und ist auch bei großen Projekten unfassbar schnell. Grund genug, dass ich seit einiger Zeit vermehrt Sublime Text als Editor statt PhpStorm zum Entwickeln nutze.

Gerade zuletzt musste ich sehr viele kleinere Änderungen in vielen Projekten in kurzer Zeit durchführen – die Geschwindigkeit von Sublime Text (in allen Belangen: Projekte öffnen, suchen über das gesamte Projekt, ersetzen usw.) hat das alles überhaupt erst erträglich gemacht.

Alles in allem ist es interessant zu sehen, wie sich der Kreis schließt und schlussendlich doch wieder der einfache Text-Editor das Tool meiner Wahl wird wenn es ums Coden geht.

Weiterleitung für WordPress-URLs bei Permalink-Änderung

Ich habe eben die URLs der Blog-Posts hier im WordPress geändert. Das geht an sich ganz einfach – in den Permalink-Settings von WordPress kann man sich den URL-Pfad für die Blog-Posts fast beliebig zusammenstellen.

Das Problem an der Sache ist, dass die Links zu bereits veröffentlichten Blog-Posts ungültig werden. Man möchte also für die alten Links einen Redirect einrichten.

Die alte Permalink-Struktur sah so aus:

https://www.marcusjaschen.de/fahrt-in-den-sommerlichen-sonnenuntergang/

Nach der Änderung sind die URLs etwas anders aufgebaut:

https://www.marcusjaschen.de/blog/2015/fahrt-in-den-sommerlichen-sonnenuntergang/

Um jetzt nicht alle Weiterleitungen per Hand anlegen zu müssen, habe ich mir die Arbeit vereinfacht und die fertigen Redirect-Direktiven für die Apache-Konfiguration direkt per SQL ausgeben lassen:

SELECT 
    CONCAT(
        'RedirectPermanent /',
        `post_name`,
        ' ',
        'https://www.marcusjaschen.de/blog/', 
        DATE_FORMAT(`post_date`, '%Y'), 
        '/', 
        `post_name`
    ) 
FROM 
    `wp_posts` 
WHERE
    `post_status` = 'publish'
    AND `post_type` = 'post'
ORDER BY `post_date` ASC

Da fällt dann z. B. so etwas heraus:

RedirectPermanent /kopf-hoch-lenin https://www.marcusjaschen.de/blog/2015/kopf-hoch-lenin
RedirectPermanent /airport-berlin-brandenburg-international https://www.marcusjaschen.de/blog/2015/airport-berlin-brandenburg-international
RedirectPermanent /fahrt-in-den-sommerlichen-sonnenuntergang https://www.marcusjaschen.de/blog/2015/fahrt-in-den-sommerlichen-sonnenuntergang

Es reicht die Ausgabe in die Apache-Konfiguration oder, falls vorhanden, in die .htaccess-Datei zu kopieren um alle bisherigen Links auf die geänderten URLs weiterzuleiten.

PHP: foreach vs. array_reduce

Ich habe letztens meine PHP-Library phpgeo mit Scrutinizer CI auf Code-Qualität untersuchen lassen. Es wurde an zwei Stellen Code-Duplication angemahnt, die ich dann auch gleich entfernt habe.

Dabei stieß ich auf eine foreach-Schleife, welche für die Berechnung der Länge einer Polyline (GPS-Track) zuständig ist.

Das Ergebnis der Schleife lässt sich auch wunderbar mit PHPs Funktion array_reduce berechnen. Die Frage war jetzt, ob ich es so lasse wie gehabt oder tatsächlich auf array_reduce umstelle.

Die betreffende Methode:

public function getLength(DistanceInterface $calculator)
{
    $distance = 0.0;

    if (count($this->points) <= 1) {
        return $distance;
    }

    foreach ($this->getSegments() as $segment) {
        $distance += $segment->getLength($calculator);
    }

    return $distance;
}

lässt sich auch so schreiben:

public function getLength(DistanceInterface $calculator)
{
    $distance = 0.0;

    if (count($this->points) <= 1) {
        return $distance;
    }

    return array_reduce(
        $this->getSegments(),
        function($carry, $item) use ($calculator) {
            return $carry + $item->getLength($calculator);
        }
    );
}

array_reduce müsste schon mindestens einen relevanten Vorteil gegenüber foreach bieten und außer der Geschwindigkeit und vielleicht ein bisschen mehr Eleganz fiel mir keiner ein. Die Geschwindigkeit lässt sich zum Glück schnell testen und ein kurzes Skript für diesen Zweck war schnell geschrieben:

<?php
/**
 * we need something to call
 */
function calculate_something($value) {
    return $value / ($value + 1);
}

$cycles = 100000;

// create some random data
$array = [];
for ($i = 0; $i < $cycles; $i ++) {
    $array[$i] = mt_rand(0, 0x7fffffff);
}

$timer['start'] = microtime(true);

$sumForeach = 0;
foreach ($array as $value) {
    $sumForeach += calculate_something($value);
}

$timer['foreach'] = microtime(true);

$sumArrayReduce = array_reduce($array, function($carry, $item) {
    return $carry + calculate_something($item);
});

$timer['array_reduce'] = microtime(true);

echo $sumForeach . " == " . $sumArrayReduce . PHP_EOL;
echo "foreach     : " . ($timer['foreach'] - $timer['start']) . PHP_EOL;
echo "array_reduce: " . ($timer['array_reduce'] - $timer['foreach']) . PHP_EOL;

Es zeigte sich, dass foreach deutlich schneller ist als array_reduce:

[mj@neptune:~/tmp]
% php test.php
99999.999335167 == 99999.999335167
foreach     : 0.068737030029297
array_reduce: 0.2411630153656

Wenn man darüber nachdenkt ist auch schnell klar warum das so sein muss: Für jeden Wert des Arrays wird in array_reduce ein – in PHP relativ teurer – Funktionsaufruf fällig (nämlich die Callback-Closure), was in foreach nicht notwendig ist.

Ende der Geschichte: Die Längenberechnung in phpgeo geschieht weiterhin in einer foreach-Schleife.

Es ist allerdings leicht vorstellbar, dass der Overhead eines Funktionsaufrufes bei anderen Anwendungen weniger ins Gewicht fällt und dort array_reduce die elegantere Alternative darstellen kann.

FFmpeg beim Erstellen von Standbildern auf die Beine helfen

Um in einem Videoplayer Vorschaubilder beim Bewegen der Maus über die Zeitleiste anzuzeigen, erstellt man vom jeweiligen Video ausreichend viele Standbilder und gibt diese dem Videoplayer zeitcodiert mit.

Das Erstellen eines Standbildes kann mit FFmpeg (bzw. avconv unter debianoiden Linuxen) relativ einfach erledigt werden:

ffmpeg -y -i videofile.mp4 -ss 10 \
-f image2 -s 1280x720 -vframes 1 \
-threads auto -an screenshot.jpg

FFmpeg bekommt in diesem Beispiel mit mit dem Argument -ss 10 gesagt, im Video zum Zeitpunkt 10 Sekunden „vorzuspulen“ (im Sinne von „den ganzen Film decoden und an der entsprechenden Stelle anhalten“) und ein Standbild dieser Stelle abzuspeichern. Ist der Zeitpunkt nah am Anfang des Videos geht das recht schnell. Je weiter sich der Zeitpunkt vom Start entfernt, desto länger dauert der ganze Vorgang; wir reden hier von etlichen Sekunden schon bei relativ kurzen Videos von wenigen Minuten Länge. Wenn man jetzt z. B. 80 dieser Bilder aus einem Video benötigt, dauert das schnell mal an die 10 Minuten. Und wenn man dann nicht nur eins, sondern rund 30.000 Videos hat, wird’s schnell ungemütlich.

Zum Glück gibt es einen Trick, wie ich gestern gelernt habe: Fast-Seeking.

Hierbei springt FFmpeg an den dem Zeitstempel am nächsten liegenden Keyframe, von dort zum gewünschten Zeitstempel und erzeugt dann den Screenhot. Sehr praktisch und für den gegebenen Anwendungsfall absolut ausreichend.

ffmpeg -y -ss 10 -i videofile.mp4 \
-f image2 -s 1280x720 -vframes 1 \
-threads auto -an screenshot.jpg

Was hat sich im Befehl geändert? Lediglich die Position des Arguments -ss 10: Steht dieses vor dem Input-Argument (-i) aktiviert FFmpeg das Fast-Seeking. Wer möchte kann auch eine Kombination von Slow- und Fast-Seeking einsetzen (das nennt sich dann Combined Seeking), die Details kann man auf der Wiki-Seite nachlesen.

Damit war es möglich die Dauer für das Extrahieren der 80 Screenshots eines Videos von 10 Minuten auf 5 Sekunden zu reduzieren. Es liegen immerhin rund zwei Größenordnungen zwischen den Werten – damit sind dann auch 30.000 Videos durchaus in vertretbarer Zeit abzuarbeiten.