Output buffers are stackable, that is, you may call ob_start() while another ob_start() is active.

Die Ausgabe-Puffer sind als Stack realisiert, so dass man sie schachteln kann:

ob_start();
  ob_start();
    echo "Hello world!";
  ob_end_flush();
ob_end_flush();

Schön, wenn es auch mal einfach geht.

Eine schöner Ansatz, der zumindest einen großen Teil dieses Gebietes abdeckt, bietet Adaptive Images. Die Software habe ich nicht getestet und sie dürfte für viele ohnehin nicht nutzbar sein, da sie PHP und einen Apache Webserver erfordert. Die Idee ist aber gut und einfach umsetzbar.

Client: Cookie mit Bildschirmdimensionen setzen

Wer generell gegen Cookies und Javascript ist kann jetzt aufhören zu lesen. Via JS setzen wir im Head ein(en?) Cookie mittels JS, in dem die maximale Bildschirmgröße gespeichert wird:

document.cookie = 
    'resolution=' + Math.max(screen.width,screen.height) + '; path=/';

Da wir das Maximum wählen, können wir sicher sein, dass Bilder auch nach dem Kippen des Gerätes ins Querformat noch ordentlich aussehen.

Das war es auch schon. Der Browser sendet ab sofort bei jedem Aufruf die Auflösung mit. Auch bei Bildern, ob aus Img-Element oder CSS.

Server: Bildanfrage abfangen, Bild in neuer Größe erzeugen und umleiten

Serverseitig muss die Anfrage nun auf irgend ein Serverprogramm umgeleitet werden. Dieses kennt den Pfad zum Bild und die gewünschte Dimension. Es nimmt also das Bild, skaliert es herunter und speichert es. Nun schickt es dem Client eine Weiterleitung auf die optimierte Datei. Diese kann sogar permanent sein, da sich die Dimensionen eines Browsers in aller Regel nicht ändern.

Die Skalierung des Bildes ist nur beim ersten mal für eine bestimmte Größe nötig. Später wird auf die bereits erzeugten Varianten verwiesen.

Nur ein Ansatz

Dies ist natürlich nur ein Ansatz. Welche Bilder skaliert werden sollen und wodurch diese vom Server erkannt werden muss für jede Website geklärt werden. Zudem sollte man sich Normgrößen überlegen, damit nicht unzählige Varianten ein und der selben Datei wegen zwei Pixeln Unterschied auf der Platte landen.

Gegenüber verbreiteten Ansätzen gibt es einen zentralen Vorteil. Browser müssen nicht erst alle kleinen Bilder laden um im Nachhinein via Javascript zu erfahren, dass sie diese durch für ihre Größe angemessene Varianten ersetzen sollen. Hier lädt der Client ein Bild und der Server liefert ihm was er braucht.

Der Ansatz funktioniert nicht ohne Javascript und Cookies. Sind diese deaktiviert oder nicht vorhanden, erhält der Browser eine Standardversion des jeweiligen Bildes. Die Website funktioniert somit dennoch wie erwartet, nur die Optimierung fehlt.

$result = pg_query("SELECT $rowName FROM $tableName;");
while ($row = pg_fetch_assoc($result)) {
    $fileHandler = fopen($filePath, 'wb');
    fwrite($fileHandler, pg_unescape_bytea($row[$rowName]));
    fclose($fileHandler);
}

Auf der Projektseite werden drei zentrale Dokumente bereitgestellt, die durch GitHub versioniert werden und verschiedenartige Vorgaben liefern.

PSR-0: Autoloading Standard

Dieses Dokument beschreibt, wie Namespaces und Klassennamen zu wählen sind. Anhand dieser Vorgaben lässt sich ein Autoloader definieren, der automatisch alle benötigten Klassen nachlädt.

PSR-1: Basic Coding Standard

In diesem Schriftstück finden sich die grundlegenden Coding-Standards. Eine Datei muss UTF-8-kodiert sein, PHP-Bereiche werden durch <?php oder <?= eingeleitet. Für zentrale Konzepte gibt es hier Vorgaben zur Schreibweise:

ClassName
CONSTANT_NAME
methodName

Zudem wird festgelegt, dass eine Datei entweder Symbole (wie Klassen, Funktionen) definiert oder Seiteneffekte (Ausgaben erzeugen u. ä.) hat – niemals jedoch beides.

PSR-2: Coding Style Guide

PSR-2 geht ins Formatierungsdetail und hält fest beispielsweise fest, wie Klammern auszurichten sind:

ClassName
{
    function methodName()
    {
        if (true) {
            functionName();
        } else {
            functionName($arg1, $arg2);
        }
    }
}

Zudem wird genau beschrieben, was etwa passiert, wenn z.B. eine Methodendefinition die maximale Zeilenlänge von 120 überschreitet.

ClassName
{
    function tooLongMethodName(
        $one,
        $argument,
        $per,
        $line
    ) {
        // ...
    }
}

Klar formuliert und umfangreich

Die von mir angesprochenen Details sind lediglich Ausschnitte. Das Projekt scheint noch in Bewegung zu sein, dennoch wirken die Vorgaben sehr durchdacht und auch für die meisten Spezialfälle gerüstet. Durch die vielen Beispiele lässt sich der Stil auch ohne langes Lesen einfach adaptieren. Jeder PHP-Entwickler sollte mal einen Blick darauf werfen.

Der Speicherfresser: Array zurückgeben

function getAllTableRows() {
  // ...
  return $allRows;
}
$allRows = getAllTableRows();

Dieser Ansatz führte nun leider regelmäßig dazu, dass PHP mit einer Speicherfehlermeldung abbrach.

Der sparsame Ansatz: Array als Referenzparameter

function getAllTableRows(&$allRows) {
  // alle Werte in $allRows schreiben
}
$allRows = array();
getAllTableRows($allRows);

Fast schon traurig, dass das für PHP so einen Unterschied macht. Ich vermute, dass das an PHPs Eigenheit liegt, mehr auf Werten als auf Referenzen zu arbeiten. Ironischerweise behauptet das PHP-Manual an ähnlicher Stelle, der Kern sei intelligent genug, dies selbst zu optimieren, zumindest was Rückgaben angeht.

Mangels ausreichend großer Beispiel konnte ich den folgenden Ansatz nicht testen:

function &getAllTableRows() {
  // ...
  return $allRows;
}
$allRows =& getAllTableRows();

$tmp[] = 'aaaaaaaaaaaaaaaaaaaa'; // 195 µs
$tmp[] = "aaaaaaaaaaaaaaaaaaaa"; // 193 µs

Ja, die Lehrbücher müssen neu geschrieben werden. Wie oft hat man nicht schon gehört und gelesen, dass das einfache Anführungszeichen ja soviel schneller ist, weil es sich selbst nicht auf enthaltene Variablen überprüfen muss. Klingt ja soweit auch schlüssig… Chris Vincent hingegen hat einfach mal einen Test gemacht. Er fand heraus, dass es ziemlich egal ist, welche Variante man nimmt.

Und genau auf diese Weise klärt die Seite viele Fragen, die man sich vielleicht noch nie gestellt hat. Einige überraschen, andere bestätigen was man schon immer gedacht hat:

• === ist schneller als ==
• Switch und If-Elseif-Else-Schleifen unterscheiden sich nicht
• Operationen im Schleifenkopf sind unfassbar schlecht, z.B. for($x=0; $x = sizeof($array); $x++)
• Noch ein Klassiker widerlegt: echo 'aa'.'aa' ist sehr viel schneller als echo 'aa','aa'

Aber all das kann die Seite selbst sehr viel besser darstellen und erklären. Hier sollte jeder PHP-Entwickler einmal drübergucken.

Links

• The PHP Benchmark

Der Name Reghex

Der Name des Tools war eine recht spontane Idee: Ein einfaches Wortspiel aus Regular Expressions bzw. Regex und einer Hexe (die Anwendung ist schließlich zauberhaft gut) formte zunächst die Reghexe, was sich dann später noch auf Reghex verkürzte. Wir haben sogar verschiedene Schreibweisen zu bieten: Die Seite selbst spricht von „reg[h]?ex“, im Code heißt es „RegHex“. Um es nicht so eindeutig zu lassen, habe ich mich hier für das typografisch korrekte Reghex entschieden.

Reguläre Ausdrücke testen

Bei Reghex kann man einen regulären Ausdruck und einen oder mehrere Teststrings eingeben. In Echtzeit prüft die Anwendung nun, ob der reguläre Ausdruck auf die Teststrings passt. Diese werden entsprechend farbig unterlegt: Rot passt nicht, grün wird durch den Ausdrück abgedeckt.

Für die Ausdrücke lassen sich die üblichen Optionen wie „i“ für die Beachtung von Groß- und Kleinschreibung oder „m“ für mehrzeilige Tests einfach über eine Liste auswählen.

Reguläre Ausdrücke für Javascript, PHP und Java

Ein besonderes Highlight ist die Umschaltbarkeit des Regex-Parsers. Neben regulären Ausdrücken, wie sie in Javascript verwendet werden, unterstützt die Anwendung auch die Dialekte, die in PHP und Java zur Verfügung stehen. Weitere Sprachunterstützungen sind hierbei einfach zu realisieren und auch geplant.

Open Source und fast nur Javascript

Die Webanwendung braucht fast nur Javascript, um ihren Dienst zu verrichten. Lediglich für die Dialekte von PHP oder Java wird der Server mittels Ajax bemüht. Hierbei wird eine PHP-Schnittstelle genutzt, welche die Anfrage an ein Programm der entsprechenden Sprache weiterleitet und das Ergebnis im JSON-Format zurück schickt.

Das Projekt mitsamt Quellcode liegt bei Github und kann somit von jedermann eingesehen und genutzt werden. Zwar ist die Entwicklung noch nicht abgeschlossen, generell sollte das Tool aber nutzbar sein.

Links

• Reghex-Repository bei Github
• Demoinstallation bei MGVmedia

Server: PHP und MySQL

Die Serverseite, welche Tweedback mit Ajaxdaten versorgt, wurde recht geradlinig und ohne Framework umgesetzt. Sie besticht vor allem durch ihre effiziente Nutzung der Datenbankperformance. Viele, teils recht komplexe Anfragen, wurden fast ausschließlich in einzelne Querys verpackt.

Hierbei hat sich aber vor allem ein Problem in den Vordergrund gestellt: Querys, die statt auf feste Tabellen wieder nur auf wiederum verschachtelte Subquerys zugreifen, sind schwer zu entwerfen und noch schwerer zu warten. Ein Quereinsteiger, der sich mit dem Code beschäftigen will, hat es hier sehr schwer. Hinzu kommt, dass ein Query meist als einzelne, abgeschlossene Aktion angesehen wird und daher im inneren schlecht oder gar nicht dokumentiert ist.

Hier sollten wir künftig mehr auf die Werkzeuge der Datenbanken eingehen und z.B. verschiedene Views und UDFs (User Defined Functions) nutzen.

GUI: J-Query Mobile

Die graphische Oberfläche läuft im Browser und basiert auf der dritten Beta von J-Query Mobile. Dieses befindet sich, wie der Name vermuten lässt, selbst noch in Entwicklung. Ärger gab es bei der Entwicklung dennoch nicht, JQM hat sich als zuverlässiges und intuitives Framework bewiesen.

Grundsätzlich ist eine J-Query-Mobile-Rohling auf Kleinstgeräte ausgerichtet. Um auch größere Displays angemessen bedienen zu können, wurde mit Hilfe von Media-Querys des CSS-3-„Standards“ ein sich selbst anpassendes Layout („Responsive Webdesign“) gewählt.

Alles andere folgt streng den Empfehlungen und Vorgaben des Frameworks.

Funktionsweise von Tweedback

Der Dozent

Der Dozent muss vor seinem Vortrag ein Veranstaltung anlegen, in welcher das Feedback gesammelt wird. Wichtig ist hier vor allem der Eventcode, welcher den Zuhörern mitgeteilt wird um am Event teilzunehmen und Rückmeldungen zu geben.

Anschließend befindet sich der Dozent in der Dozentenansicht der Veranstaltung, in welcher aufgekommene Fragen und Warnungen wie „zu schnell“ oder „unklar“ angezeigt werden. Diese Ansicht ähnelt sehr der normalen Veranstaltungsansicht eines Zuhörers, welche gleich noch gezeigt wird.

Nach einer gewissen Zeit werden Events geschlossen und der Dozent erhält einen Abschlussbericht, in welcher die gestellten Fragen aufgelistet und das Nutzerempfinden bezüglich Vortragsgeschwindigkeit und Verständlichkeit in Graphen dargestellt wird.

Der Zuhörer

Der Zuhörer wird nach dem Aufruf von Tweedback folgendermaßen begrüßt:

Wie bereits erwähnt wurde, muss hier der Eventcode eingetragen werden, der vom Dozenten festgelegt wurde. Zusätzlich hat der Zuhörer die Möglichkeit, seinen Namen oder ein Pseudonym einzugeben. Diese Möglichkeit findet sich im persönlichen Einstellungsmenü, welches über die Schaltfläche oben rechts erreichbar ist.

Die Tweedback-Teilnahme ist vollkommen anonym möglich. Ein wesentliches Ziel war ein Webdienst, der den Nutzer zu keiner Anmeldung oder ähnlichen persönlichen Angaben zwingt.

Nach der Eingabe des Eventcodes befindet sich der Zuhörer in der Veranstaltungsansicht. Hier kann dieser bestehende Fragen sehen und diese durch einen Klick auf den orangefarbenen Bereich unterstützen. So werden wirklich wichtige Fragen immer größer dargestellt.

Um die Fragen möglichst knapp zu halten, kann der Nutzer diese einer Kategorie wie Beispiel oder Erklärung zuordnen, um sich bei der eigentlichen Frage auf das zugehörige Stichwort beschränken zu können. Dies ist auf dem obigen Screenshot rechts unten erkennbar, wo neue Fragen erstellt werden können.

Ein weiteres Konzept sind die Schaltflächen Verständnis und Vortragsgeschwindigkeit: Hier kann der Nutzer sein derzeitiges Empfinden durch einen einfachen Buttondruck ausdrücken. Der Dozent erhält die Zusammenfassung dieser Angaben dann als Information (oder ab einer gewissen Stufe als Warnung).

Weitere Entwicklung

Derzeit ist von unserer Seite keine Weiterentwicklung von Tweedback geplant. Da wir mit dem Erreichten jedoch sehr zufrieden sind, bleibt die Hoffnung, dass das System zumindest genutzt oder im Zuge anderen Studienarbeiten erweitert wird.

Der Code ist einfach und verständlich, zudem gibt es eine ausführliche Entwicklerdokumentation. Somit ist auch eine Veröffentlichung des Codes etwa unter der GPL denkbar und von den Entwicklern generell auch vorgesehen. Da auch der betreuende Lehrstuhl über das weitere Vorgehen nachdenkt, wollen wir diese Entscheidung nicht voreilig im Alleingang treffen. Ein Termin für eine mögliche Veröffentlichung ist daher noch nicht abzusehen.

Zunächst mal die kleine Animation, die ich im Laufe des Tages erstellt habe. Sie soll hoffentlich bald auf der neuen MGVmedia-Seite erklären, was es mit „Responsive Webdesign“ auf sich hat:

Zumindest in Chrome sieht das alles sehr schön flüssig aus und benötigt nicht eine Zeile Javascript.

Bisher habe ich nur zwei Funktionen benötigt: Eine um Keyframes zu erstellen, die andere um eine Animation an HTML-Elemente mittels animation-name, animation-duration, animation-iteration-count und animation-direction zu binden.

Um zu verstehen, was das alles bedeutet, gibt es viele Tutorials. Für den Anfang kann ich CSS3 Animations von Rich Bradshaw empfehlen.

Wenn man dann weiß, wohin man will, sind die beiden Funktionen überschaubar und selbsterklärend:

• Github-Repo CSS-Animation-Helpers

Model, View und Controller mit Flow 3

Das MVC-Framework Flow 3 soll noch im Oktober diesen Jahres erscheinen. Ich habe daher mal einen kurzen Blick darauf geworfen und bin über einige tolle Sachen gestolpert, die ich sehr überzeugend finde.

Kommandozeile

In Flow 3 erzeugt man Webapplikationen weitgehend über die Kommandozeile. Die nötigen Dateistrukturen und wesentliche Inhalte von Controllern, Models, Repositorys und Templates werden bereits erzeugt und müssen lediglich angepasst werden. So erzeugt man für einen Blogpost beispielsweise ein recht einfaches Grundgerüst, indem man

./flow3 kickstart:actioncontroller
  --generate-actions
  --generate-related
  TYPO3.Blog Post

im Projektverzeichnis ausführt. Dies erzeugt einen neuen Controller „PostController“ (ein Actioncontroller ist den Zugriff durch den Browser; man kann auch Commandcontoller für die Kommandozeile erstellen). Hierbei werden gleich wesentliche Aktionen wie Hinzufügen und ändern erzeugt (–generate-actions). Die Option –generate-related erzeugt automatisch alles, was noch fehlt: Dies ist hier ggf. das Paket TYPO3.Blog (vorletzter Paramter) und das Model Post, welches passend zum Controller existieren muss. Der letzte Parameter benennt den Controller (ohne das Suffix Controller) und impliziert eine Verbindung zu einem entsprechenden Model.

All das nimmt einem sehr viel Dateiverwaltung und Code-Erzeugung ab. Einen weiteren schönen Einblick in die Kommandozeilenfähigkeiten bekommt man durch das folgende Video:

[vimeo clip_id=“28987131″]

Persistenz an Bord

Eine weitere schöne Sache ist die Verwendung von Doctrine 2: Statt sich hier etwas neues zu überlegen, setzt man auf diese bewährte Lösung, um Objekte ohne viel Aufwand auf Datenbanken zu mappen. Hierfür ist etwas mehr Aufwand im Model nötig. Alle Attribute müssen mittels PHP-Doc typisiert werden:

/**
 * The name
 * @var string
 */
protected $name;

Anschließend kann man diese Models aber mittels eines einfachen Kommandozeilenaufrufs in der Datenbank erzeugen

./flow3 doctrine:migrate

oder später nach Änderungen aktualisieren:

./flow3 doctrine:update

Doctrine ist mittlerweile sehr gut erprobt und bietet unzählige Möglichkeiten.

Wirkt überzeugend – aber was ist mit der Performance?

Was ich bisher gesehen habe, finde ich absolut intuitiv und auch einfacher, als ich es von anderen Frameworks kenne.

Das einzige, wovor ich auf lange Sicht doch ein wenig Angst habe, ist, dass die Entwickler die Performance ähnlich wie bei bisherigen Typo-3-Entwicklungen zu weit hinten anstellen. Schon hier auf dem eigenen Rechner dauerte es manchmal doch erschreckend lange, bis eine Seite vollständig erzeugt wurde. Allerdings war dies meist nur beim ersten Aufruf zu beobachten. Ich denke daher, dass Caching hier über die Geschwindigkeitsprobleme hinweg helfen soll.

Wer selber sehen möchte, was Flow 3 kann, dem sei das Quick-Start-Tutorial ans Herz gelegt.

Typo 3 5

Das neue Typo 3 wird wohl erst Ende nächsten Jahres erscheinen, dennoch zeigte T3N.de in einem Artikel mit Video ein paar schöne erste Eindrücke (das Interview davor ist… merkwürdig, aber wenigstens kurz):

[youtube clip_id=“ihOVcmo6OOI“]