Wenn man die Handbuch-Seite zu isset() durchliest, klingt es, als wäre es problemlos möglich auch die Existenz von Array-Keys zu prüfen. Sogar ein schönes Beispiel gibt es dazu:

<?php
 
$a = array ('test' => 1, 'hello' => NULL, 'pie' => array('a' => 'apple'));
 
var_dump(isset($a['test']));            // TRUE
var_dump(isset($a['foo']));             // FALSE
var_dump(isset($a['hello']));           // FALSE
 
// The key 'hello' equals NULL so is considered unset
// If you want to check for NULL key values then try: 
var_dump(array_key_exists('hello', $a)); // TRUE
 
// Checking deeper array values
var_dump(isset($a['pie']['a']));        // TRUE
var_dump(isset($a['pie']['b']));        // FALSE
var_dump(isset($a['cake']['a']['b']));  // FALSE
 
?>

Doch ganz so einfach ist es leider nicht. Interessant ist hier vor allem die letzte Zeile. Erst auf den zweiten Blick fällt auf, dass als erster Schlüssel “cake” statt “pie” verwendet wird. Und das ist der einzige Grund dafür, dass FALSE zurückgegeben wird. Ändert man nämlich den ersten Schlüssel auf “pie”, wird TRUE zurückgegeben, auch wenn der dritte Key nicht existiert:

<?php
 
$a = array ('test' => 1, 'hello' => NULL, 'pie' => array('a' => 'apple'));
 
var_dump(isset($a['pie']['a']['b']));  // TRUE
 
?>

Das Problem und die Lösung wird auch in einem Kommentar von 2004 angesprochen. Die Prüfung mit isset() reicht nicht aus. Zusätzlich muss auf den vorletzen Key mit is_array() geprüft werden:

<?php
 
$a = array ('test' => 1, 'hello' => NULL, 'pie' => array('a' => 'apple'));
 
var_dump(isset($a['pie']['a']['b']) && is_array($a['pie']['a']));  // FALSE
 
?>

Wichtig ist hier auch, dass man zuerst das isset() und danach das is_array() schreibt, sonst bekommt man einen Undefined-index-Fehler, wenn der Schlüssel komplett nicht vorhanden ist. Ein alleinstehendes isset() in Verbindung mit einem Array sollte einen also immer misstrauisch machen. Je nach Fall sollte ein is_array() ergänzt oder ein array_key_exists() bevorzugt werden.

Ich habe mir dafür ein kleines PHP-Skript geschrieben. Vielleicht findet es ja sonst jemand nützlich:

<?php
// loggrep.php 2011-12-08
if (2 !== $argc && 3 !== $argc) {
    echo "USAGE: {$argv[0]} <pcre-pattern> <file>\n";
    exit(1);
}
 
$filename = 'php://stdin';
if (isset($argv[2])) {
    $filename = $argv[2];
}
$fp = fopen($filename, 'r');
 
// "2011-11-22T02:16:34+01:00 - "
$startPattern = '#^\d{4}(-\d{2}){2}T\d{2}(:\d{2}){2}\+\d{2}:\d{2} - #';
$searchPattern = $argv[1];
 
$found = false;
 
while ($line = fgets($fp)) {
    if (preg_match($startPattern, $line)) {
        if (true === $found) {
            foreach ($buffer as $bufferedLine) {
                echo $bufferedLine;
            }
        }
 
        $buffer = array();
        $found = false;
    }
 
    if (preg_match($searchPattern, $line)) {
        $found = true;
    }
 
    $buffer[] = $line;
}

Der Aufruf sieht dann so aus:

$ php loggrep "#Mage_Core_Block_Template#" exception.log

Wichtig ist, dass der Suchbegriff mit PCRE-Syntax (inklusive Delimiter) angegeben wird.

Update 08.11.2011

Jetzt neu: Falls keine Datei angegeben wird, kann das Skript auch von STDIN lesen. Damit kann man auch einfach in gepackten Dateien suchen:

$ zcat exception.log.1.gz | php loggrep "#Mage_Core_Block_Template#"

Im hauseigenen Blog erklären die Entwickler, dass diese Änderung sowohl Seiten über aktuelle als auch wiederkehrende Ereignisse wie beispielsweise die olympischen Spiele betrifft. Die Idee dahinter: Sucht jemand im Mai 2012 nach dem Begriff „Olympische Spiele“, so sollen dem User nicht die Auflistung der Leichtathletik-Medaillengewinner von 1956, sondern möglichst viele Informationen zu den Spielen 2012 in London als Ergebnisse weit oben in den SERPs präsentiert werden.

Betroffen werden vor allem viele alte Foreneinträge sein. Jedem ist es sicherlich schon einmal passiert, dass er bei einer Suche zu einem aktuellen Software-Problem zunächst Forendiskussionen aus dem Jahr 2003 zu Gesicht bekam, deren Lösungsansätze in der schnelllebigen IT-Welt natürlich mittlerweile unbrauchbar waren. Dies soll nun der Vergangenheit angehören.

Nach dem vor allem auf relevante und userfreundliche Inhalte abzielenden Panda-Updates, hat sich Google nur also dem Problemfeld „Aktualität“ angenommen. Das besondere: Die Google-Entwickler schätzen, dass 35% aller Suchanfragen betroffen sein werden. Eine deutlich höhere Anzahl als bei Panda.

Für Webseiteninhaber und Betreibern von Online Shops heißt dies nun, ebenfalls verstärkt auf neue Inhalte zu setzen. Ideal eignen sich dafür integrierte Blogs oder News-Ticker, die aktuelle und relevante Ereignisse oder Aktionen rund um die Webpräsenz behandeln und Google zeigen, dass auf diesen Seiten neue Inhalte zu finden sind. In Magento-Shops ist die Einbindung solcher Features relativ einfach möglich, wird allerdings bisher erst in wenigen Fällen genutzt. Auch der dynamische Bereich von Social Media wird dadurch weiter gefördert werden, denn es ist zu vermuten, dass Google auch diesen Faktor in seine Aktualitätsberechnungen berücksichtigen wird. In Kombination werden Social Media und aktuelle Inhalte sicher eine große Rolle unter den von Google berücksichtigten Ranking-Faktoren einnehmen und sollten deshalb auch verstärkt gepusht werden.

Das Problem ist warscheinlich eine veraltete PHP-Version. In dem aktuellen Fall ist Magento 1.4.0.1 im Einsatz. Magento setzt die Funktion SimpleXMLElement::getName vorraus, welche erst seit (PHP 5 >= 5.1.3) implementiert ist.
Die Lösung bei einem “Shared Host” wäre eine nette Mail an den Support mit der Bitte um Umstellung auf die aktuelle Version. Ein Wunder das Magento überhaupt läuft.

Funktionalität

Macht das Modul wirklich, was ich mir darunter vorstelle? Die Beschreibung passt, die Screenshots sehen sehr viel versprechend aus. Aber ob im Kern und im Detail dann auch wirklich ein Modul dahinter steckt, was genau die speziellen Anforderungen des jeweiligen Shops erfüllt, ist fraglich. Woher bezieht es seine Daten? Entspricht die Logik dem, was sich der Shop-Betreiber vorgestellt hat? Wie hoch ist der Aufwand, um eine “kleine Änderung” durchzuführen? Kann man die Ausgaben an die eigenen Vorstellungen anpassen? Die Antworten auf all diese Fragen können nicht mittels Screens und Co., sondern erst nach einer detaillierten Prüfung des Programms gegeben werden.

Sicherheit

Es sollte bei der Integration eines Moduls geprüft werden, ob die installierten Mechanismen grundlegende Regeln der Sicherheit einhalten. SQL Injection, Cross-Site-Scripting oder Cross-Site Request Forgery sind nur drei mögliche Angriffsmöglichkeiten, die in einem guten Magento-Modul nicht vorkommen sollten. Die Sicherheit sollte jedoch nicht als gottgegeben angenommen werden – hier ist der Betreiber einer Seite selbst aufgerufen, dies explizit zu überprüfen.

Performance

Jedes Modul wird die Leistungsfähigkeit des gesamten Systems ein Stück mehr bremsen. Das fängt mit einer Verlängerung der Konfiguration an und setzt sich über die Verarbeitung des eigentlichen Zwecks eines Moduls fort. Das wird man nicht verhindern können – allerdings sollte man darauf achten, dass ein Modul seine Arbeit möglichst effizient durchführt. Es sollte darauf geachtet werden, dass Caches genutzt und somit unnötige Rechenoperationen vermieden werden.

Skalierbarkeit

Ein Modul kann im Kontext eines kleinen Shops mit einer Handvoll Produkten und Kunden sehr gut funktionieren, bei der Verarbeitung eines Enterprise Stores mit einer Million Produkten jedoch komplett versagen. Im schlimmsten Fall hieße das: Der Shop ist bei eingeschalteter Funktionalität einfach nicht mehr zu erreichen.

Wartbarkeit

Für den Betrieb eines Online-Shops sowie dessen kontinuierliche Weiterentwicklung ist es von zentraler Bedeutung, dass alle eingesetzten Module die notwendigen Eingriffe “sanft” durchführen. Dies bedeutet zu allererst, dass Änderungen in dem Sinne ausgeführt werden, der von Magento zur Änderung vorgesehen wurde. Man muss sich auch im Klaren darüber sein, dass durch die Veränderung einiger Prozesse andere Änderungen oder Module von der Installation ausgeschlossen werden. Auch Updates auf neue Magento-Versionen werden durch die Vielzahl von installierten Magento-Modulen in der Regel deutlich erschwert.

Magento Module können der entscheidende Baustein zum Erfolg sein - oder aber auch das ganze System zum Einsturz bringen.

Noch etwas brisanter ist die Problematik im Rahmen von Professional- oder Enterprise-Editions. Hier bezahlt der Betreiber eines Shops für die professionelle Lizenz, durch die im Härtefall auch eine Verbesserung oder Kompensation von Magento erzielt werden soll. Je mehr Module jedoch in die Verarbeitung der Original-Prozesse eingreifen, desto unwahrscheinlicher wird jedoch der Haftungsfall für Magento, könnten doch eben die installierten Module für die fehlerhafte Leistung verantwortlich sein.

Ein großer Vorteil der Enterprise-Edition ist der Full-Page-Cache. Damit dieser jedoch ordnungsgemäß funktionieren kann, müssen auch die installierten Module hierzu kompatibel sein. In der Praxis schaut der Kunde hier gleichwohl aufgrund inkompatibler Entwicklung oft in die Röhre und der teuer bezahlte Full-Page-Cache bleibt ausgeschaltet.

Problematisch bei kommerziellen Modulen ist darüber hinaus, dass man die Qualität eines Moduls erst überprüfen kann, nachdem man bereits dafür bezahlt hat. Andernfalls müsste man beim Hersteller eines Moduls zunächst eine Test-Version beantragen, um bei positiver Prüfung die Vollversion zu erwerben. Kommerzielle Module sind darüber hinaus häufig mit IonCube verschlüsselt und können somit gar nicht oder nur mit hohem Aufwand auf Schwachstellen überprüft werden. Auch entstehen hiermit Aufwände für die Administration des IonCube-Moduls für PHP.

Wenn man nun bedenkt, dass oben genannte Punkte sowohl im Rahmen der Installation als auch bei jedem Update eines Moduls überprüft werden müssen, kann die vermeintlich kostenfreie Extension relativ schnell zeitintensiv und damit sehr teuer werden.

Insgesamt möchten wir nicht davon abraten, kostenfreie oder kostengünstige Module von der Stange einzusetzen – im Gegenteil: diese Möglichkeit stellt für viele Shop-Betreiber eine günstige Alternative dar, um oft gewünschte Funktionalitäten nachzurüsten. Auch wir stellen bekanntlich einige Module für Magento – selbstverständlich kostenfrei – zu Verfügung. Wir möchten aber gerade aufgrund unserer Erfahrung mit anderen Modulen umso dringender dazu raten, alle Erweiterungen detailliert zu überprüfen und im Zweifel eine externe Expertenmeinung einzuholen. Wenn hierdurch eine Downtime oder ein Datenverlust verhindert werden kann, ist eine tief greifende Untersuchung gut investierte Zeit bzw. gut investiertes Geld.

PS: Die Problematik ist nicht Magento-spezifisch! Diese Ausführungen lassen sich auf diverse andere Systeme genauso anwenden.

Danach stellte Jan Burkl von Zend das neue Package-Deployment-Feature von Zend Studio und Zend Server vor. Im Studio kann mann sich über ein nettes GUI eine deployment.xml erstellen lassen, mit der man sich anschließend eine Zend-Package (*.zpk, ein Zip mit anderer Dateiendung) erstellen lassen kann. Dieses kann man daraufhin auf den Zend Server deployen, wo definierte Vorraussetzungen geprüft und Abhängigkeiten aufgelöst werden können. Das Ganze ist in beiden Produkten sauber integriert und lässt sich auch über die Kommandozeile skripten.

In der Keynote “Cloud by Example” vor dem Mittagessen informierte Dr. Matt Wood, “Technology Evangelist for Amazon Web Services”, über die Features und Möglichkeiten mit AWS. Sehr schnell, sehr viel Inhalt, recht vertriebsorientiert.

Da heute DevOps-Day war ging es den restlichen Tag auch weiter um das Thema Deployment. Zunächst folgte Thorsten Rinne von Mayflower mit “One Click Deployment with Jenkins”. Dazu wird für jede Zielinstanz (testing, staging, production) ein Projekt in Jenkins angelegt, dass jeweils von den benötigten anderen Projekten durch die Build Pipeline abhängt. Das Projekt “Deployment Testing” kann dann automatisch angestoßen werden, sobald der Build des Hauptprojekts erfolgreich war. Somit wird verhindert, dass kaputte Versionen auf Testing gelangen. Anschließend kann der “Build” für das Deployment auf Staging oder Production manuell über Jenkins angestoßen werden.

Nachdem André Neubauer am Montag bereits über die Einführung von Scrum bei Immobilienscout24 berichtet hatte, waren heute die Fortschritte bei der Verkürzung der Deployment-Zyklen auf dem “steinigen Weg zum Continuous Live Deployment” das Thema. Immobilienscout hat dazu den Weg über Maven, den CI-Server TeamCity und den Repository Manager Nexus gewählt. Features werden mit dieser Infrastruktur regelmäßig einmal wöchentlich live gestellt, dringende Bugfixes natürlich schneller.

Im letzten Talk der Konferenz “Vom lokalen Build zum Deployment” stellte Manuel Pichler (Qafoo) sein neustes Open-Source-Projekt build-commons vor. Damit lässt sich das Problem angehen, dass Build-Skripte oft von Projekt zu Projekt kopiert werden, und das Rad in dieser Hinsicht noch zu oft neu erfunden wird. Die build-commons umfassen eine Vielzahl von Ant-Skripten, die in einer festen Reihenfolge ausgeführt werden, jedoch nahezu überall Erweiterungsmöglichkeiten bieten. Die Struktur der Verzeichnisse und Bezeichnungen der Skripte orientiert sich an Maven. Die Skripte benötigen Apache Ant 1.8+.

Alles in allem wieder mal eine interessante Konferenz von der man mit vielen Anregungen und Ideen zurückkommt. Jetzt muss ich mich erstmal ausschlafen, um morgen wieder für den Arbeitsalltag gewappnet zu sein

Den ersten Vortrag des Tages bildete somit “Zend Framework 2: State of the Art”. Enrico Zimuel (Zend) gab einen groben Überblick zu den Veränderungen und Neuerungen in ZF2 und zur aktuellen Zeitplanung: eine erste Beta soll noch im Oktober veröffentlicht werden. Das Autoloading in ZF2 wurde grundlegend erweitert. Zwar unterstützt der Autoloader nach wie vor die alte include-path-basierte Methode, zusätzlich kann man Namespaces mit Verzeichnissen verknüpfen woraufhin der Loader Klassen dieser Namespaces direkt aus dem spezifizierten Verzeichnis lädt. Das bringt laut den Zend-Benchmarks mit Opcode-Cache bis zu 40% Performancegewinn. Bis zu 60% schneller ist der Loader mit einer statischen Classmap. Dabei wird das gleiche Prinzip wie bei Arne Blankerts Autoload verwendet. Dependency Injection wird über Container, Interfaces und Setter ermöglicht, die auch über Annotationen konfigurierbar sind. Beispiele dazu finden sich auf Ralph Schindlers Git-Repository. Ebenfalls neu sein wird der EventManager sowie das eventgetriebene MVC-Framework, dass sich auch modular erweitern lassen soll.

Derick Rethans erläuterte Möglichkeiten, Herangehensweisen und Fallstricke beim Profiling von PHP Anwendungen. Er warnte auch davor “Tipps” aus dem Internet einfach zu glauben, da viele dieser “Verbesserungsvorschläge” nicht (mehr) stimmen (zum Teil stark abhängig von der PHP-Version) oder für Microoptimierungen die Wartbarkeit des Codes drastisch verschlechtern. Bei der Analyse von Performanceproblemen ist zunächst wichtig den Flaschenhals zu finden. vmstat erlaubt häufig bereits die Eingrenzung auf einen der Problembereiche Datenbank (langsame Queries), IO (zuviele Lese-/Schreiboperationen von der Festplatte), System (möglicherweise beschäftigt mit anderen Aufgaben) oder Code. Dazu lassen sich viele parallele Zugriffe mit siege oder httperf simulieren. Sollte sich dabei der Code als Flaschenhals herausstellen kann man sich mit Zeitmesspunkten (z.B. mit ezcDebug), der Analyse der includes mit inclued, der Auswertung von Xdebug-Traces mit den Vala Xdebug Tools oder KCachegrind, Valgrind oder die Verwendung (bei Bedarf mit entsprechender Konfiguration auch im Live-Betrieb) von XHProf und XHGui.

Nach der Mittagspause kam der David-Zülke-Doppelschlag (Bitextender) zu RESTful Webservices. Zuerst die Keynote “How the Web Evolves with Hypermedia” und direkt anschließend “Designing HTTP Interfaces and RESTful Web Services”. Im Zentrum beider Vorträge stand Roy Fieldings Aussage

“[...] if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API.”

sowie das Richardson Maturity Model. Wichtig ist vor allem die Verwendung der HTTP-Verben (GET, PUT, POST, DELETE) und der korrekten HTTP-Status-Codes, unveränderliche, logisch strukturierte URLs sowie die Verwendung von Hypermedia als treibende Kraft des Anwendungszustands. Ein gut geplanter und implementierter REST Webservice bedeutet am Anfang zwar etwas mehr Aufwand, bietet aber Zuverlässigkeit und Konsistenz für die Clients auf lange Zeit. Durch die Erweiterbarkeit von XML und die Navigierbarkeit über die Hypermedia-Informationen können Clients auf Änderungen automtisch reagieren und funktionieren auch weiterhin.

Lukas Smith (Liip) stellte in seinem Talk powerpointfrei das im Juli veröffentlichte Symfony2 anhand von Codebeispoielen vor. Dabei demonstrierte er unter anderem die Möglichkeiten zur Einbindung von bundles, das Routing, die Verwendung der Template-Engine, den generellen Ablauf der Anwendung und ging auf einzelne Fragen ein.

Nachdem Thorsten Suckow-Homberg als Referent für den Vortrag “‘Mobile’ Backends – Backend-Entwicklung für Ext JS/Sencha Touch” kurzfristig ausfiel, übernahm Hans-Christian Otto (Crosscan) spontan das Thema. Nach einem Überblick über Ext JS und Sencha Touch ließ sich feststellen, dass es zwischen beiden Bibliotheken, vor allem in Verwendungsdetails, zwar Unterschiede gibt, sie aber noch viel Gemeinsamkeiten haben. Vor allem die Anbindung von Datenbackends ist bei beiden Frameworks nahezu identisch, womit es problemlos möglich ist von beiden Oberflächen aus den selben Webservice anzusprechen. Da sich die einzelnen Komponenten von Ext JS schlecht herauslösen lassen, kann man sich als Alternative für den Datenzugriff ohne Ext JS backbone.js anschauen. Als Editor wurde Spket, dass auch als Eclipse-Plugin verfügbar ist, empfohlen.

Nach dem Vortragsprogramm gab es noch Abendessen, Freibier und -wein, Roulette, Black Jack, Texas Hold’em, Waffeln und Vanilleeis. Nachdem die Getränke alle waren und die Croupiers Feierabend machen wollten haben wir noch auf zwei oder drei Drinks in der Cuban Bar vorbeigeschaut.

Auf der Konferenz angekommen gab Johannes Schlüter (Oracle) zunächst ein Update bezüglich PHP 5.4. Dabei wurde unter anderem auf Traits, die neue Array-Syntax und den internen PHP-Dev-Webserver eingegangen. Verbunden war das Ganze mit der eindringlichen Aufforderung die Nightly-Builds zu testen um solche Bugs wie in PHP 5.3.7 und andere zu vermeiden. PHP würde zwar von einer Test-Suite getestet, doch “unbeabsichtigte” (sprich: nicht im Sinne der PHP-Entwickler) Verwendungen von Funktionen würden von dieser Test-Suite eben nicht erfasst, was auch zum aktuellen Problem mit der is_a()-Funktion führe.

Anschließend hat Kore Nordmann (Quafoo) “A generic PHP Application Installer” vorgestellt. Bei der Entwicklung des Projekttracking-Tools Arbit stellte sich das Problem der Installation. Da es für dieses Problem derzeit keine generische Lösung gibt, wird derzeit für jede Software ein eigener Installer entwickelt. Da das offensichtlich wenig effizient ist, haben sich die Jungs von Quafoo daran gemacht einen generischen, wiederverwendbaren Installer zu schreiben (svn://arbitracker.org/arbit/projects/installer/trunk). Damit lassen sich Aufgaben sowie optionale und verpflichtende Abhängigkeiten zwischen den Aufgaben definieren, die dann vom Installer in der gewünschten Reihenfolge abgearbeitet werden. Wiederrum als Unterprojekt des Installers entstand daraufhin Phync (svn://arbitracker.org/arbit/projects/phync/trunk), um die Dateien des zu installierenden Pakets an die richtigen Stellen zu kopieren. Phync nutzt dazu die PHP-Stream-Wrapper und ist ebenfalls erweiterbar ausgelegt.

Frisch gestärkt vom Mittagessen stellte André Neubauer (ImmobilienScout24) seine Erfahrungen bei der Einführung von Scrum vor. ImmobilienScout stellte 2008 seine internen Entwicklerteams schrittweise vom Wasserfallmodell auf Scrum um. Nach und nach wurden die ursprünglich reinen Entwicklerteams mit Mitarbeitern aus den Bereichen Qualitätssicherung, Grafik und Anwendungsbetrieb (Operations) verstärkt um eine vertikale Prozessdurchdringung zu erreichen. Wichtig für die Einführung sei neben der Verbindlichkeit (Commitment) und dem Einhalten der Scrum-Regeln die Hinzunahme von externer Hilfe. Zum einen hat ein externer Berater bringt zum einen die Erfahrung als auch einen unbefangenen Blick auf die bestehenden Prozesse und Hemmnisse (Impediments) mit. Inzwischen verfolgt ImmobilienScout eine Null-Bug-Strategie und setzt Scrum auch bei den externen Teams ein. Wobei die Einbindung der Externen aufgrund der räumlichen Entfernung nicht immer einfach ist.

Thementreu ging es danach bei den agilen Methoden mit einem Kanban-Planspiel von it-agile weiter. Das Zusammenspiel der “Analysten”, “Entwicklern” und “Testern” wurde so spielerisch erprobt und von den “Trackern” aufgezeichnet. Die Analysten mussten einfache mathematische Aufgaben zur Berechnung von Punkten im Koordinatensystem lösen. Diese wurden daraufhin von den Entwicklern ins Koorinatensystem auf Papier übertragen und zu Drei- oder Vierecken verbunden. Anschließend kontrollierten die Tester die Rechnungen sowie das Papierergebnis und setzen die Aufgabe bei Übereinstimmung auf “erledigt”. Zusätzlich zu den aus Scrum bekannten Unterscheidungen zwischen “Zu erledigen”, “In Bearbeitung” und “Erledigt” lassen sich mit Kanban auch besser aufeinanderfolgende, abhängige Prozessschritte wie eben Analyse, Entwicklung, Testen und Abnahme besser tracken. Durch die Limitierung der maximal erlaubten Tickets pro Prozessschritt lässt sich außerdem einfach ein starkes Druckmittel auf die anderen Prozessschritte installieren: wird das Limit bei einem Schritt erreicht, darf dieser solange kein neues Ticket ziehen, bis der darauffolgende Schritt erledigt ist. Durch den offensichtlichen Stillstand wird der Druck zur Bearbeitung auf die anderen Schritte erhöht, außerdem kann die freie Kapazität zur Unterstützung von überlasteten Schritten genutzt werden.

Zum Abschluss des heutigen Vortragsprogramms referierte Jordi Boggiano (Nelmio) über “Redis – Your advanced in-memory key-value Store”. Redis ist zunächst ein schneller Key-Value-Store, vergleichbar mit Memcached, speichert die Daten jedoch zusätzlich persistent auf der Festplatte. Außerdem bietet Redis eine Reihe von Features, mit denen Memcached nicht dienen kann. Es erlaubt die Speicherung von verschiedenen Datenmengen wie Sets, Maps und Listen inklusive der entsprechenden Operationen wie pop und push sowie Subskription von Variablen, Master-Slave-Setups, atomare In- und Dekrements und Transaktionen. Für PHP existieren die beiden Module phpredis und phpiredis sowie die Plain-PHP-Implementierung predis.

Nach einem kurzen Zwischenstopp im Hotel ließen wir den Tag mit einem Abendessen im Alex sowie dem einen oder anderen Getränk im Heiliggeist und Saustallitos ausklingen.

VirtualBox Guru Meditation

… heißt das, dass die VM abgestürzt ist. Schön, dass diese Fehlermeldung schon so alt ist und eine Tradition hat, das sie sogar einen eigenen Wikipedia-Artikel hat.