Aber für all diejenigen, für die Continuous Integration noch ein Buch mit sieben Siegeln ist, hier noch mal die Schnelleinführung von dem, was die meisten glauben. was CI ist. Im nächsten Artikel schreibe ich dann, warum das nicht ganz richtig ist.

Wenn man einen CI-Server einsetzt, dann übernimmt der hauptsächlich eine Aufgabe. Er testet die Applikation. Grob zusammengefasst prüft er in wiederkehrenden Intervallen ein Source-Code-Repository (z.B. SVN), ob Änderungen am Code vorgenommen wurden. Falls es Änderungen gab, so wirft er die vorher definierte Test-Suite an und gibt einem das Ergebnis aus. Je nach Konfiguration bekommen die Teammitglieder dann eine Mail. falls etwas kaputt ist. In den meisten Fällen handelt es sich bei der Test-Suite um Unit Tests. Es ist aber auch problemlos möglich Tools wie Selenium, Code-Sniffer, PHPMD oder ähnliches einzuhängen. Alles was über die Kommandozeile funktioniert, funktioniert auch im CI-Server.

Vorteil von einem solchen Server ist somit, dass kaputter Code nicht lange unentdeckt bleibt, da es jemanden gibt, der sicher nicht vergisst die Tests auszuführen, so wie es einem Entwickler vielleicht passieren könnte. Schön ist es auch, dass es keine Zeit frisst. Niemand sitzt vorm Rechner und lässt die Tests laufen, das macht alles der dumme und günstige Server im Hintergrund.

Das war jetzt also die Quick-and-dirty-Version von dem, was die meisten Leute unter Continuous Intergration verstehen, dem Einsatz eines Continuous Integration Servers. Wie gesagt, im nächsten Artikel ergänzen wir das.

Ob Facebook, Google+ oder Twitter: alle verwenden als zentrales Element einen Stream, eine Pinnwand oder einen Newsbereich mit den aktuellsten Meldungen. Egal wie man es nennt, es handelt sich dabei immer um die erste Anlaufstelle über die sich der Benutzer über aktuelle Themen informieren kann, einen Überblick bekommt und mit wenigen Blicken weiß, was los ist. Ein Konzept, das so simpel wie nützlich ist. Nur ist das immer begrenzt auf die jeweilige Plattform und am Ende muss man sich durch die verschiedenen Netzwerke und Anwendungen klicken. Das schöne Prinzip vom einzelnen Informationsstrom ist damit dahin.

Nachdem ich schon länger einige interessante Frameworks und Bibliotheken testen wollte, war das für mich Grund genug eine Webanwendung zu bauen, welche aus den verschiedensten Quellen Informationen abgreift und in einem einzelnen Stream präsentiert. Praktisch ein beständiger Fluss an Informationen, weshalb ich die Anwendung nach dem schönen isländischen Wasserfall Selfoss benannt habe. Ein Bild das sehr gut passt, denn der Selfoss besteht aus zahlreichen kleinen Wasserfällen, also sozusagen aus viele einzelnen Informationsströme, die zusammen doch in einem Fluss münden. Genau so sollte das Programm funktionieren: Beliebige Quellen können als Plugins (ich habe sie spouts getauft) eingehängt werden und den Informationsstrom so mit Meldungen aus beliebigen Quellen (RSS Feeds, Twitter, Log Files, usw.) befüllen.

Requirements & Planung

Ich habe schon einige Erfahrung mit meinem letzten Projekt, dem RSS Reader rsslounge sammeln können und somit eine ganze Reihe an Anforderungen:

• Der Aufbau des Programms sollte simpel sein. Keine riesigen generischen Schnittstellen, keine fetten Frameworks und auch nicht die Möglichkeit alles abdecken zu können. Eine schlichte Architektur und einfacher Code sollten im Zentrum stehen.
• Ein einfaches Framework mit möglichst wenigen Dateien sollte verwendet werden. Bei rsslounge setze ich auf das Zend Framework und bin damit auch sehr zufrieden. Allerdings ist das ZF sehr umfangreich und somit wird ein Update auf eine neue Version sehr lästig, da sich sehr viele Dateien sich über FTP durch die Leitung quälen müssen.
• Leichte Erweiterbarkeit durch zusätzliche Datenquellen (Spouts).
• Selfoss sollte auf dem iPad und auf Android laufen.
• Selfoss sollte von seinem Einsatzgebiet nicht zu sehr eingegrenzt werden. Man kann das Programm also als zentrale Sammelstelle für Informationen nutzen, aber auch als mashup Tool verwenden. So kann Selfoss Informationen sammeln und als RSS Feed wieder zur Verfügung stellen. Oder man setzt Selfoss als Livestream ein und präsentiert Meldungen, die man selbst auf verschiedene Plattformen veröffentlicht hat, an einer zentralen Stelle.

Das MVC Pattern als Grundgerüst hat sich gut bewährt und ist mittlerweile auch zum letzten Entwickler durchgedrungen. Für das Anbinden der Spouts hatte ich bereits bei rsslounge einen ähnlichen Mechanismus entwickelt. Der sollte wieder recycelt und in abgewandelter Form eingesetzt werden.

Fat Free PHP Framework

Als Basis-Framework habe ich mich für das Fat Free PHP Framework entschieden. Dabei handelt es sich um ein sehr schlankes Framework, das mit einer Größe von 55kb beworben wird, tatsächlich dann aber doch 223kb und 27 Dateien umfasst. Im Vergleich zum Zend Framework aber immernoch super schlank.

Das Fat Free PHP Framework (kurz F3) benötigt auch PHP 5.3, da es die neuen Möglichkeiten, wie beispielsweise Lambda Funktionen verwendet. Für mich perfekt, die Sprachfeatures von PHP 5.3 mal vol auszuschöpfen. F3 bringt dabei alle wichtigen Funktionen mit, die man so benötigt:

• Routing Mechanismus (sehr einfach auch im MVC Style realisierbar)
• Datenbankzugriff (sogar mit einem mini ORM und einem MongoDB mapper)
• Template Engine
• Schnick Schnack wie: On-the-fly JavaScript/CSS compressor, CAPTCHA generator, OpenID, usw.

Was mich neben der kompakten Größe überzeugt hat, sind die einfachen Programmkonstrukte, die sich damit ergeben. Am besten sieht man das an einem Beispiel:

require __DIR__.'/libs/f3/base.php';

F3::set('AUTOLOAD','libs/f3/|libs/|libs/WideImage/|models/|libs/twitteroauth|libs/FeedWriter');

F3::route('GET /', 'controllers\Index->home');

F3::route('GET /mark/@item', 'controllers\Items->mark');

F3::route('POST /source', 'controllers\Sources->add');

F3::route('PUT /source/@id', 'controllers\Sources->write');

F3::run();

Hier wird als erstes das F3 Framework eingebunden. Dann werden die Verzeichnisse für das Autoloading gesetzt. Anschließend werden die Routen definiert. Da das F3 Framework grundsätzlich den REST Ansatz unterstützt, wird mit F3::route die HTTP Methode und die Ziel URL festgelegt. In einem zweiten Parameter steht dann die Klasse und Methode, die aufgerufen wird (z.B. in der Klasse \controllers\Index die Methode home). Man könnte auch direkt eine Funktion übergeben:

F3::route('GET /about',

function() {

echo 'No subliminal messages here...';

}

);

Wie die gesamte Initialisierung von Selfoss und die Definition der Routen erfolgt, könnt ihr euch hier ansehen: https://github.com/SSilence/selfoss/blob/master/index.php

Das Backend im Überblick

Was passiert noch im PHP Backend von Selfoss? Eine ganze Menge, aber dann doch mit erstaunlich wenig Code und eben simpel gestrickt.

Da mich die Templating Engine von F3 nicht überzeugen konnte und ich die PHP Programmierkonstrukte für ein Templating für ausreichend halte, habe ich mir selbst eine Hilfsklasse für das Rendern der PHP Templates erstellt: helpers/View.php. Die Klasse bietet die Methode render, welche einfach das übergebene Template einbindet, ausführt und als String zurück gibt. Es unterstützt auch eine JSON Ausgabe und bietet ein paar Hilfsfunktionen. Damit können Views wie im Zend Framework genutzt werden.

Ein ordentlicher Logger hat mir auch im F3 Framework gefehlt. Also habe ich einen ganz einfachen Logger erstellt: helpers/Logger.php, der ausschließlich in Dateien loggen kann.

Für den Datenbankzugriff wird die F3 Komponente verwendet. Die funktioniert auch sehr einfach. Hier ein Beispiel für einen MySQL Datenbankzugriff:

F3::set('DB',

new DB(

'mysql:host=localhost;port=3306;dbname=mysqldb',

'admin',

'p455w0rD'

)

);

DB::sql('SELECT brandName FROM wherever');

foreach (F3::get('DB->result') as $row) {

// whatever you want to do with $row

}

Neben MySQL wird aber auch Sqlite und MongoDB unterstützt. Zwei Modelklassen für die vom Benutzer definierte Quellen und eine für die Einträge kapseln sämtliche Datenbankzugriffe (siehe models).

Bibliotheken Backend

Ich bin nicht zimperlich, was den Einsatz von Bibliotheken angeht. Selber machen ist ganz nett, aber es gibt mittlerweile super OpenSource Libraries, die einfach hervorragend sind. Also habe ich auch hier wieder meine Bookmarks gewälzt und auf folgende Bibliotheken zurückgegriffen:

• SimplePie: Verwende ich zum Parsen von RSS Feeds. Eine spitzen Bibliothek, die auch mit fehlerhaften Feeds ganz gut umgehen kann.
• WideImage: Verwende ich zum Erstellen der Vorschaubildchen.
• htmLawed: Damit bereinige ich die Feed Einträge von schädlichen HTML und JavaScript Code. Das ist nicht nur aus Sicherheitsaspekten sinnvoll, sondern häufig wird auch fehlerhafter HTML Code ausgeliefert.
• jsmin: F3 besitzt zwar einen JavaScript Minifier. Der hat bei mir aber nicht funktioniert und somit setze ich auf diese Lib, die ich auch schon seit langem in rsslounge verwende
• cssmin: das Gleiche wie jsmin für CSS Dateien
• PHP Universal Feed Generator: Damit erzeuge ich ein neues RSS Feed aus den gesammelten Beiträgen.
• floIcon: Damit werden ICO Dateien verarbeitet

Spouts

Wie eigene Datenquellen ergänzt werden können, ist in der Dokumentation zu finden. Wer z.B. irgendeine Datenquelle (z.B. Logfiles, Email Account, Webseite ohne RSS) anzapfen will, muss dazu lediglich eine einzelne PHP Klasse implementieren. Eine Anleitung, wie das geht, findet ihr in meinem Blog.

Im Prinzip funktioniert die Anbindung wie folgt:

• Die Hilfsklasse ContentLoader.php lädt alle abzurufenden Quellen, die der Benutzer konfiguriert hat, aus der Datenbank
• Dann wird zu jeder einzelnen Quelle das dazugehörige Spout geladen (das macht die Hilfsklasse SpoutLoader.php mit Hilfe von Reflection). Einen solchen Spout könnt ihr einfach implementieren, ohne Selfoss genauer zu kennen.
• Der ContentLoader ruft die load Methode des jeweiligen Spouts auf, welche dann die Inhalte (z.B. via RSS) abruft.
• Dann holt sich der ContentLoader nacheinander alle abgerufenen Beiträge und speichert diese in der Datenbank ab (sofern noch nicht vorhanden).

Frontend

Für das HTML Grundgerüst konnte ich endlich einmal die HTML5 Boilerplate Vorlage ausprobieren. HTML5 war für mich die Technik der Wahl, nachdem alles auch auf mobilen Plattformen laufen sollte. Im Grunde verwende ich nichts von den HTML5 Neuerungen, aber wer weiß, was die Zukunft bringt.

HTML5 Boilerplate enthält auch die JavaScript Bibliothek modernizr. Diese prüft das vorhandene System und fügt zum html Tag CSS Klassen hinzu, welche unterstützte Features markieren. So kann sehr einfach geprüft werden, ob z.B. das aktuelle Device touch-Funktionen unterstützt:

if($(‘html‘).hasClass(‘touch‘)) {

…

Frontend Bibliotheken

Nein, ich bin ganz sicher nicht zimperlich was Bibliotheken angeht. Aber wieso das Rad neu erfinden? Hier die Liste mit Bibliotheken, die ich für das Frontend verwende und auch weiterempfehlen kann:

• Elastic CSS Framework: Mit Browserkompatibilität kann man Nächte verbringen. Gerade was mehrspalitge Layouts usw. angeht. Daher verwende ich Elastics, dass sehr viel out of the box mit bringt.
• iScroll: Der Stream ist in einem div Element untergebracht. Um das via touch scrollbar zu machen (z.B. auf dem iPad), verwende ich die JavaScript Bibliothek iScroll. Ein echter Tipp, denn diesbezüglich scheint es keine weiteren Alternativen zu geben.
• jQuery: Muss ich noch was dazu sagen?
• Keyboard Shortcuts: Ein sehr schönes Skript um ganz einfach mit Funktionen auf Keypress Aktionen zu reagieren.

Download

Selfoss ist natürlich OpenSource (GPLv3) und kann frei heruntergeladen werden:

http://selfoss.aditu.de/

Sämtliche Quellen können auch auf github eingesehen werden.

Gerne könnt ihr mich für Fragen kontaktieren: tobias.zeising@aditu.de. Und wenn jemand eine eigene nützliche Datenquelle (Spout) entwickelt hat, freue ich mich sehr über Feedback und Sourcecode.

Ok jetzt zum Artikel. Vor ein einigen Tagen waren wir in Köln zum Symfony Day und Fabien hat in seiner Keynote ein wenig über Symfony2 philosophiert. Dabei hat er auch über MVC-Frameworks gesprochen und erklärt, dass man so gut wie nie in der Symfony-Doku finden wird, dass es sich dabei um eines handelt. Aber warum? Ist Symfony2 denn kein MVC-Framework? Wäre ja grausam, denn MVC verstehen wir und damit können wir auch arbeiten. Ja, Symfony ist auch weiterhin ein MVC-Framework, aber warum hat der Franzose das dann gesagt? Es ist ihm einfach egal.

Nutzt das Framework doch wie ihr wollt und wie es am besten zu euch passt. Ihr braucht MVC, dann kommt ihr eben so gut mit Symfony zurecht, wie jemand der einfach einen Webservice auf die Beine stellen will. Dank der Komponentisierung kann man auch viel kleinteiliger arbeiten und zum Beispiel nur den Class-Loader benutzen.

Hinter dem ganzen “I don’t care” stecken zwei Ideen. Zum einen will er die Verbreitung von Symfony fördern und dabei ist es sinnvoll bekannt zu machen, dass es eben viel mehr als ein MVC-Framework ist und man es überall einsetzen kann. Wiederverwendbarkeit ist einfach was feines. Und je mehr Projekte sf nutzen, umso schwieriger wird es an dem Thema vorbei zu kommen. Genial für eine Firma, die damit ihr Geld verdient. Zweiter Punkt ist eher so etwas prinzipielles. Wenn euch MVC nicht 100% zusagt, dann nutzt es nicht zu 100%. Erweitert die Ideen, programmiert nicht zu engstirnig. Wenn ihr ein MVCD machen wollt, dann macht es. Frische Ideen haben noch nie geschadet. Erfindet aber bitte das Rad an dieser Stelle nicht neu.

Hier wird also damit gespielt, dass man gerne bei etwas großen dabei sein will. Und genau das treiben die Jungs um Fabien Potencier noch ein Stück weiter. In den nächsten Wochen soll ein neues Symfony-Community-Portal eröffnet werden, in dem man für alles mögliche Badges bzw. Buttons gewinnen kann. Wir kennen das ja alle von diversen Spielen wie zum Beispiel Little Big Planet oder Foursquare. Im Symfony-Context könnte das bedeuten, dass man beim ersten Commit ein Badge bekommt, wenn man mal an der Spitze der Liste saß, bekommt man einen anderen, wer Fabien eine Postkarte schreibt erhält den dritten und und und. Die Ideen sind einfach unendlich und bestimmt wird jemand eingestellt, der den ganzen Tag nur neue Trophäen erfindet.

Das klingt von mir jetzt vielleicht ein wenig überzogen, aber ich bin mir total sicher, dass diese Herangehensweise ein echter Erfolg wird. Es werden viele genau aus diesem Grund ein wenig Doku schreiben oder mal einen kleinen Performance-Tweak zur Verfügung stellen. Ich bin auf jeden Fall dabei und ich glaube das andere Open-Source-Frameworks sich relativ schnell was von der Idee abschneiden werden.

Die Information, dass so etwas in Planung ist, kommt übrigens direkt von Monsieur Potencier persönlich, der dies auf seiner Keynote im Freitag in Köln erzählt hat.

So jetzt seid ihr mal wieder gefragt, haltet ihr das für idiotisch und meint, dass ihr Entwickler seid und keine Spielkinder?

• Fehlende Framework-Unterstützung: ESI klingt zwar einfach, aber wenn das Framework es nicht unterstützt, dann kann es haarig werden. Das System muss ja so gebaut sein, dass jeder Snippet der Seite unabhängig vom Rest gerendert werden kann. Soviel ich weiß, ist Symfony2 das erste und einzige Framework derzeit auf dem PHP-Markt das es unterstützt. Nachträglich sowas einzubauen halte ich für sehr komplex.
• Overhead: Das ist jetzt für jedes Projekt eine eigenen Rechenaufgabe. Nehmen wir an, wir nutzen ein relativ schwergewichtiges Framework, welches 100ms braucht um hochzufahren. Jetzt besteht unsere Seite im einfachsten Fall aus zwei Teilen. Da wir dank ESI beide getrennt haben, müssen wir jetzt zwei mal das Framework hochfahren. 200ms einfach im Framework verbraten ist halt schon mal ein doofer Startpunkt für eine Hochlastseite. Wir wollten ESI vor kurzem auch bei einer relativ bekannten Seite einführen und sind daran gescheitert, dass zwei Teile der Seite gar nicht cachebar waren und somit ESI keine Beschleunigung gebracht hätte.
• Parallelität: Wer gerade den Overhead-Punkt nicht einfach nur überflogen hat, der hat sich sicherlich die Frage gestellt, warum man die zwei ESI-Includes nicht einfach parallel abholt und somit immer nur das Maximum der beiden Requests zu buche schlägt. Tja, ESI kann das leider nur sequentiell. Wobei ich gerade nicht genau weiß, ob es eine ESI-Einschränkung oder ob die Varnisch-Implementierung das Problem ist. Wenn man es aber mal genau betrachtet, kann es schon ganz logisch sein. Was wäre, wenn ein Include Cookies setzt und das andere darauf zurückgreifen will? Wenn immer mal eins von beiden zuerst fertig ist, hat man kein konsistentes Verhalten und debugging wird die Hölle. Heisenbug lässt grüßen.

Das waren jetzt erstmal die von mir gesehenen drei Nachteile. Ihr werdet sicherlich auch noch einiges beitragen können.

Ach ja, heute geht meine Elternzeit zu Ende. Nach zwei Monaten zu hause wieder mal richtig arbeiten. Ich sag euch dann wie es war.

Betrachtet man das Caching-Verhalten einer Webseite, dann bemerkt man, dass sie so lange gültig sein kann, wie das aktuellste Element auf ihr. Existiert zum Beispiel eine Box mit den aktuellsten Nachrichten, die jede Minute aktualisiert werden muss,  so kann man mit reinem HTML da nichts machen. außer die komplette Seite maximal für eine Minute im Cache des Nutzers zu legen. Eigentlich eine nicht wirklich optimale Vorgehensweise, da die meisten Systeme zusätzlich so aufgebaut sind, dass sie immer die ganze Seite berechnen wenn eine Anfrage kommt. Gut einiges liegt im Cache, aber vieles eben auch nicht.

ESI kann dazu genutzt werden, dieses Problem ein wenig abzuschwächen und vielleicht sogar zu lösen. Eigentlich von Akamai vor einigen Jahren erfunden, wurde es 2001 als offizieller Standard bei der w3c eingereicht. Man braucht also keine Angst haben, dass man sich bei Verwendung auf eine Technologie festlegt, die keine Zukunft hat. Fangen wir aber an das Feature zu beleuchten, dass uns bei unserem Problem helfen kann.

Edge Side Includes bieten einem die Möglichkeit die Webseite in einzelne Bestandteile aufzuteilen und diese somit auch wie eigene HTML-Seiten zu betrachten. Nehmen wir an, der Header unserer Seite würde als ein solcher Bestandteil gekennzeichnet werden. Wir haben nun die Möglichkeit genau diesen Header einzeln zu Cachen und das schöne ist, wir nutzen die HTTP-Header, die wir eh schon kennen. Im ESI-Jargon sprechen wir einfach mal von includes und es würde wie folgt aussehen:

<esi:include src="http://phphatesme.com/header.php" />

Ziemlich einfach und verständlich, oder? ESI wird, wie man sieht, über XML-Elemente direkt im HTML gesteuert. Natürlich immer im ESI-Namespace, so wie es sich gehört. Jetzt kann man sich natürlich fragen, wer ein solches Tag versteht, die header.php anruft und die eigentliche Seite zusammenbaut. Varnish oder Squid wären hier zum Beispiel zwei Kandidaten.

Um diese Tags zu verarbeiten schaltet man eine Instanz vor den Webserver, der diese interpretieren kann. Einige HTTP-Acceleratoren können dies. Wir haben gute Erfahrungen mit Varnish gemacht. Egal welches Tool, es werden die einzelnen Bestandteile zusammengefügt und nach allen HTTP-Gesichtspunkten verarbeitet. Caching funktioniert also weiterhin wie gehabt. Nachdem alle Schnippsel abgeholt wurden, wird eine ganze Seite zusammengesetzt, die ESI-Tags rausgeworfen und ausgeliefert. Einfach, oder? Also zumindest das Prinzip und wenn man ein wenig mit einem HTTP-Accelerator rumgespielt hat, sollte einem hier kaum etwas spanisch vorkommen.

Da alle Tags entfernt werden ist diese Technologie für den Endkunden, also die Person, die am Browser sitzt komplett transparent. Es hat keine Ahnung rauszufinden, was da im Hintergrund passiert und trotzdem gewinnt man in den meisten Fällen sehr viel Performance auf den Servern, denn nicht mehr die ganze Seite, sondern nur einzelne Teile müssen berechnet werden.

Suchmaschinen bekommen übrigens auch ein vollständiges HTML-File, was ein großer Vorteil gegenüber AJAX ist, mit welchem man dieses System ja auch ohne Probleme hätte umsetzen können.

Falls Interesse besteht, würde ich noch Folgeartikel schreiben, denn etwas über Symfony2 und ESI hätte ich noch parat, wann ESI keinen Vorteil bringt, was ESI noch kann und wo Fallstricke lauern. Wären also vier an der Zahl, die ich wohl aufs restliche Jahr verteilen werde.