Alle Informationen zu der Veranstaltung findet ihr auf der Website Magento Hackathon @ mixxt.

Die wichtigsten Fragen und Antworten:

Was?

Laut Agenda gibt es am Freitag (30.03.) am Abend für alle bereits Anwesenden ein “Get Together” im Barschwein.

Am Samstag beginnt der Hackathon mit Vorträgen. Die Sprecher sind Vinai Kopp, Bastian Ike und Ivan Chepurnyi. Danach werden Coding-Teams zusammen gestellt und Programmierprojekte in Angriff genommen. In der Liste der potentiellen Projekte sind viele spannende Themen dabei, zum Beispiel ein Magento-2-Code-Review, das Testen von Layout-XML und Simulieren externer Services oder Verbesserungen der Performance durch Einsatz von NoSQL bei Bestelltransaktionen.

Aus dem Magento Hackathon soll eine Serie von Konferenzen entstehen. Daher haben die Organisatoren ganz ordentlich in einen Logo-Wettbewerb investiert. Die Abstimmung ist noch nicht gelaufen. Ihr könnt also mit bestimmen, welches Logo die Hackathons zieren soll.

Wann & Wo?

Der Hackathon findet am 31.03.2012 bis 01.04.2012 in München, genauer gesagt in der Leopoldstraße 62 (Jarlssen GmbH) statt. Laut Google Maps ist das in Nähe des Münchener Hauptbahnhofs.

Wer?

Für das Event haben sich bereits viele bekannte Gesichter der Magento-Community angemeldet. Einzelne Namen will ich da gar nicht heraus greifen, seht am besten in der Teilnehmerliste nach. Da ich die meisten davon noch nicht persönlich kennen gelernt habe, wäre ich gerne dabei. Ob es sich terminlich ausgeht, weiß ich allerdings noch nicht. Ich könnte wohl irgendwann am 31.03. dazu stoßen.

Wie viel?

Das Ticket für die Teilnahme kostet € 31,84. Der Preis spielt dabei also sicher keine Rolle. Die Anzahl der Teilnehmer ist begrenzt. Passt auf, dass ihr euch rechtzeitig einen Platz sichert.

Weitere Fragen?

Falls ihr noch etwas wissen wollt, wendet euch am besten an Damian Luszczymak (mixxt, Website, Twitter). Huch, ich habe ihn gar nicht gefragt, ob er das will. Auf jeden Fall engagiert er sich sehr dafür, also weiß er auch sehr gut Bescheid.

Backups in Magento 1.6

Rufen wir uns zuerst in Erinnerung, wie die Backup-Funktionalität bis inklusive Magento 1.6 aussieht:

Ein Klick auf “Create Backup” erstellt eine komprimierte SQL-Datei. Sie kann bei Bedarf über die Kommandozeile oder andere Tools wieder eingespielt werden.

Backups und Rollbacks in Magento 1.7

In Magento 1.7 wird dieses Feature ausgebaut. Man erreicht die Funktion wie bisher über das Navigationsmenü unter dem Punkt “System” > “Tools”  > “Backups”. Ein Screenshot verrät einige Neuerungen:

Anstelle eines simplen “Create Backup”-Buttons sind drei unterschiedliche Sicherungen möglich:

• System Backup: dieses Backup sichert (fast) alle Dateien der Magento-Installation. Wir kommen gleich zu den Details.
• Database and Media Backup: in dieser Datei werden Inhalte des Ordners “media” und ein Datenbank-Backup vorgehalten.
• Database Backup: hier wird wie gewohnt ausschließlich die Datenbank gesichert.

Über die Tabellenspalte “Action” kann ein Rollback durchgeführt, die Sicherung also wieder in das System eingespielt werden. Das Löschen von Backups ist über das Actions-Dropdown weiterhin möglich.

System-Backup

Klickt man auf den Button “System Backup”, wird eine Warnmeldung angezeigt:

Wie man sich gut vorstellen kann, dauert es mitunter lange Zeit, ein vollständiges System zu sichern. Daher muss diese Operation explizit bestätigt werden. Zugleich hat man die Möglichkeit, den Shop in der Zwischenzeit in den Wartungsmodus zu versetzen.

In meinem virtuellen Testsystem benötigte das Backup eines frisch installierten Shops 45 Sekunden. Man erhält eine tgz-Datei im Verzeichnis var/backups. Die Datei wird mit einem Timestamp versehen. Sie heißt z.B. snapshot-20111231101644.tgz

Gesichert wird im Prinzip die komplette Magento-Installation ausgehend vom Magento-Root-Verzeichnis. Einige Dateien und Verzeichnisse sind davon ausgenommen:

• .svn
• maintenance.flag
• var/cache
• var/full_page_cache
• var/locks
• var/log
• var/report
• var/session

Diese Liste wird in Mage_Backup_Helper_Data::getBackupIgnorePaths() definiert. Zusätzlich zu den “normalen” Dateien wird ein Datenbank-Backup erzeugt und in var/ abgelegt. Nach dem Backup wird der DB-Dump wieder gelöscht.

Datenbank- und Media-Backup

Vor der Ausführung des “Database and Media Backup” erscheint dieselbe Warnmeldung wie beim System-Backup. Zumindest in einem leeren System geht diese Operation allerdings natürlich schneller von der Hand. Im Testsystem war nach 7 Sekunden alles erledigt.

Hier werden ausschließlich die Verzeichnisse media/ und var/ in eine tgz-Datei gepackt. Der Dateiname ist wiederum mit dem Zeitpunkt der Sicherung versehen, z.B. media-20111231101820.tgz.

In media/ befinden sich die Files aus der Magento-Installation inklusive der catalog/product/cache-Dateien. Das var-Verzeichnis enthält den komprimierten Datenbankexport im SQL-Format.

Datenbank-Backup

Hierzu gibt es nicht viel zu sagen. Das von Magento erstellte .gz-Archiv (Dateiname z.B. db-20111231101839.sql.gz) enthält einen SQL-Dump-File.

Rollbacks (Wiedereinspielen von Backups)

Will man einen alten Stand wiederherstellen, so öffnet sich nach dem Klick auf den Rollback-Link folgendes Warnfenster:

Diese Meldung erscheint (zumindest in der Alpha 1) unabhängig davon, welche Art von Backup eingespielt wird. Hat man bestätigt, dass man fortfahren will, muss man zur Sicherheit das Passwort des Admin-Accounts eingeben:

Diese Maßnahme ist sinnvoll, damit kein Unbefugter Unsinn anstellen kann, wenn er durch Zufall gerade an einem PC mit angemeldetem Admin-User vorbei kommt. Außerdem kann man sich noch einmal überlegen, ob man das Rollback durchführen will.

Auch hier kann der Shop in den Wartungsmodus versetzt werden. Zusätzlich kann festgelegt werden, ob man zum Einspielen des Backups eine FTP-Verbindung verwenden will. Das ist unter Umständen wegen der Größe des Backups oder der Dateirechte nötig (schließlich muss der Linux-User das Recht haben, die Dateien und Verzeichnisse zu löschen/schreiben).

Führt man ein Rollback mittels eines System-Backups durch, sind auch beim Rollback einige Dateien und Verzeichnisse ausgenommen:

• .svn
• maintenance.flag
• /index.php
• /app/Mage.php
• /errors
• /var/locks
• /var/log
• /var/report
• /var/session

Diese Liste wird in Mage_Backup_Helper_Data::getRollbackIgnorePaths() definiert. Wie gleich auffällt, bestehen Unterschiede zu den beim Backup ignorierten Dateien. Meinem Gefühl nach ist das nicht besonders sinnvoll – vielleicht kann das jemand von euch in den Kommentaren logisch erklären.

Nach dem Einspielen der Dateien wird die Datenbank ebenfalls zurück gespielt. Ist der Vorgang abgeschlossen (bei mir ging es erfreulich schnell und dauerte ca. 30 bis 40 Sekunden), dann wird man zum Admin-Login-Formular zurück geleitet und kann wieder auf das alte System zugreifen. Neuere Backups dürften übrigens bestehenbleiben, was recht praktisch sein kann.

Fazit

Mit dem Ausbau der Backup- und Rollbackfunktionalität bietet Magento CE 1.7.0.0 vor allem für jene Shopbetreiber eine sehr nützliche Funktionalität, die ihren Shop nicht innerhalb eines größer angelegten Backup-/Deployment-/Rollback-Plans betreiben. Das trifft ohne Zweifel auf viele Händler zu. Magento hilft dieser Zielgruppe somit sehr, regelmäßig die Daten zu sichern und die Risiken beim Testen von Änderungen im Shop zu reduzieren.

Der bisherige Weg mit Magento 1.6 und älter

Wer bereits mit Magento arbeitet, fragt sich vielleicht: was soll da neu sein? Magento bietet bereits lange die Möglichkeit, Staffelpreise für Kundengruppen festzulegen. Da man einen Staffelpreis bereits für 1 Stück eingeben kann, kann man diese Funktion “missbrauchen”, um unterschiedliche Basispreise für verschiedene Kundengruppen einzupflegen.

Gehen wir im Beispiel von der folgenden Preisgestaltung aus (über den ökonomischen Sinn wollen wir hier nicht diskutieren ):

• Nicht angemeldete Kunden zahlen € 9,99 pro Stück.
• Angemeldete Kunden zahlen € 8,99 pro Stück.
• Einzelhändler zahlen € 6,79 pro Stück.
• Großhändler zahlen € 6,49 pro Stück.
• Einzelhändler zahlen ab 10 Stück nur noch € 6,59 pro Stück.
• Großhändler zahlen ab 10 Stück nur noch € 6,39 pro Stück.
• Großhändler zahlen ab 50 Stück gar nur noch € 6,19 pro Stück.
• Wenn irgend jemand tatsächlich mindestens 500 Stück bestellt, kommt er mit € 5,99 pro Stück davon.

In der Eingabemaske des Webshop-Backends sieht das so aus:

Jetzt wechseln wir in den Webshop und begutachten das Produkt als nicht angemeldeter Kunde.

Das Problem fällt schnell auf: der Basispreis des Produkts beträgt € 14,99. Ich bin in der Kundengruppe “NOT LOGGED IN” und muss für 1 Stück nur € 9,99 zahlen. Auf der Kategorieseite und an der auffälligsten Stelle der Produktseite wird jedoch nur der Basispreis € 14,99 angezeigt. Dass mich das Produkt nur € 9,99 kostet, fällt nur bei genauem Hinsehen auf.

Um diese Darstellung zu korrigieren und den Einzelpreis für die Kundengruppe auffälliger zu gestalten, muss in die Logik von Magento eingegriffen werden. Damit entsteht eine Erweiterung, die bei der Installation von Aktualisierungen und anderen Erweiterungen getestet und gewartet werden muss.

Basispreise in Magento 1.7

An dieser Stelle kommt die neue Magento-Version ins Spiel. Hier können neben dem Basispreis und den Staffelpreisen weitere Basispreise für Kundengruppen hinterlegt werden.

Wir nehmen dieselben Preisregeln wie im vorigen Beispiel an und werfen einen Blick auf das Backend in Magento 1.7:

Die Kundengruppen-Basispreise werden im neuen Punkt “Group Price” definiert.

Jetzt wechseln wir wieder in den Webshop und sehen uns die Anzeige für einen nicht angemeldeten Kunden an:

Die Darstellung gefällt uns schon besser. Man sieht sowohl auf der Kategorie- als auch auf der Produktseite, welchen Preis man als nicht angemeldeter Kunde erhält. Der Gruppenpreis wird sogar als Aktionspreis ausgelobt. Ob man das in seinen Shop haben will oder nicht, ist Geschmackssache. Eeinerseits handelt es sich dabei um einen Kaufanreiz, andererseits wird so mancher jeder Kundengruppe nur den eigenen Preis anzeigen wollen.

Basispreis, Gruppenpreis und Aktionspreis

Damit noch nicht genug der Preise: in Magento kann man zusätzlich zum Basispreis einen (zeitlich begrenzten oder dauerhaften) Aktionspreis angeben. Da wir gerade beobachtet haben, dass der Gruppenpreis als Aktionspreis gekennzeichnet wird, ist es interessant zu wissen, wo der Aktionspreis seinen Platz zwischen Basispreis und Gruppenpreis findet.

Hier drei verschiedene Fälle und die daraus resultierende Anzeige:

Fazit

Mit den Gruppenpreisen bringt die Version 1.7 eine nützliche, wenn auch nicht bahnbrechende neue Funktion. Bisher musste man selbst Hand anlegen, um die Grundpreise für verschiedene Kundengruppen vernünftig anzuzeigen. Das ist nun nicht mehr nötig.

Damit das möglich wird, müssen für die Aktion Gutscheine mit individuellem Code erzeugt werden. Bisher gab es in Magento hierfür drei Möglichkeiten:

1. Man setzt sich einen Tag lang vor den PC und legt alle Gutscheine händisch an.
2. Man erwirbt eine Erweiterung von einem Drittanbieter, welche die Funktionalität nachrüstet.
3. Man schreibt ein Skript (bzw. lässt eines programmieren), das sich um die Generierung kümmert.

Doch das ändert sich nun. Mit Magento 1.7 wird eine Funktion zur automatischen Erstellung von Coupon-Codes für Preisregeln eingeführt, sprich: Magento kann nun auf Knopfdruck beliebig viele Gutschein-Codes nach dem Zufallsprinzip generieren. Die Preisregel muss dafür nur einmal angelegt werden.

Anmerkung: ich habe diesen Artikel geschrieben, als Magento 1.7 in der Version Alpha 1 vorlag. Es kann also sein, dass es bis zur stabilen Version 1.7 noch Änderungen vorgenommen werden.

Automatisches Erstellen von Gutschein-Codes

Um die neue Funktionalität zu verwenden, meldet man sich wie gewohnt im Magento-Backend an und erstellt eine Warenkorb-Preisregel. Wenn man angibt, dass ein Gutschein-Code verwendet werden soll, wird ein Eingabefeld für den Gutschein-Code und – das ist nun neu – eine Option angezeigt, Codes automatisch zu generieren.

Man hakt die Option an und speichert die Preisregel ab. Nun kommt bei der Warenkorb-Preisregel im linken Menü ein neuer Punkt namens “Manage Coupons Codes” zum Vorschein, wie in diesem Screenshot zu sehen:

Klickt man auf dem Menüpunkt, erhält man eine leere Liste und ein Formular, um die Codes zu erstellen:

Folgende Optionen existieren für die Erstellung von Gutschein-Codes:

• Coupon Qty: Wie viele Gutschein-Codes sollen erstellt werden?
• Code Length: Aus wie vielen Zeichen besteht der Gutschein-Code?
• Code Format: Aus welchen Zeichen besteht der Gutschein-Code? Hier kann zwischen Buchstaben, Zahlen und einer Kombination von Buchstaben und Zahlen gewählt werden.
• Code Prefix: Soll dem Gutschein-Code eine fixe Zeichenkette vorangestellt werden? Zum Beispiel könnte man dem zufällig generierten Code “Ostern-2012-” voranstellen, um den Gutschein für eine Osteraktion zu branden.
• Code Suffix: Soll eine fixe Zeichenkette an das Ende des Gutschein-Codes angefügt werden?
• Dash Every X Characters: Soll der Code durch Gedankenstriche unterteilt werden? Zum Beispiel wird Kunden die Eingabe stark erleichtert, wenn die Zeichenfolge in Dreier-Gruppen unterteilt wird.

Nachdem die Parameter konfiguriert sind und man auf “Generate” klickt, werden die Codes erstellt. In meinem kleinen Testsystem mit deaktiviertem Cache dauerte die Generierung von 5.000 Codes knapp 20 Sekunden. Das Ergebnis sieht wie folgt aus:

Neben jedem Gutschein-Code ist zu sehen, wann er erstellt wurde sowie ob und wie häufig er benutzt wurde.

Fazit

In Magento 1.7 wird mit der automatischen Gutschein-Code-Generierung ein Feature eingeführt, das von Shop-Betreibern stark und häufig nachgefragt wird. Es ist somit nicht mehr zwingend nötig, eine Erweiterung eines Drittanbieters zu implementieren und diese bei Software-Aktualisierungen zu überprüfen sowie zu warten.

Man kann sich erhoffen, dass die Funktionalität in Zukunft noch weiter ausgebaut wird. Was zum Beispiel in der aktuellen Alpha-Version fehlt ist die Option, leicht verwechselbare Buchstaben (wie “1″ versus “I”) bei der Generierung nicht zu verwenden.

Method "createUser" is not defined in "Mage_Captcha_Model_Observer"

Das Problem lässt sich lösen, indem ihr app/code/core/Mage/Captcha/etc/config.xml öffnet und den Methoden-Aufruf für das Event “controller_action_predispatch_customer_account_createpost” ändert:

<controller_action_predispatch_customer_account_createpost>
    <observers>
        <captcha>
            <class>captcha/observer</class>
            <method>checkUserCreate</method>
        </captcha>
    </observers>
</controller_action_predispatch_customer_account_createpost>

Die ursprünglich angegebene Methode Mage_Captcha_Model_Observer::createUser() existiert nämlich nicht.

Das Zertifikat wird per Post in den nächsten vier bis sechs Wochen übermittelt. Für die Website magento.com wird aktuell ein Verzeichnis der zertifizierten Entwickler entwickelt und voraussichtlich im Jänner 2012 bereit stehen. Auch das Zertifizierungslogo wird später als Download verfügbar gemacht und sieht vermutlich ähnlich aus wie rechts abgebildet.

Auf der Magento-Website gibt es weitere Informationen zur Magento-Zertifizierung, darunter ausführliche Hinweise zur Prüfungsvorbereitung als PDF.

Falls ihr noch nichts von Magento TAF gehört habt, ist das kein Wunder, denn Yoav Kutner hat das Framework recht unspektakulär in einem Tweet vorgestellt:

Magento Test Automation Framework TAF now on github http://t.co/nDVVLPn1

Sehen wir uns an, was Magento TAF überhaupt ist und wie man es zum Laufen bekommt.

Was ist das Magento Test Automation Framework (TAF)?

Wenn man Software entwickelt, sollte man sie klarerweise auch testen. Wenn möglich, automatisiert man diesen Vorgang, denn:

1. Manuelles Testen ist fehleranfällig.
2. Manuelles Testen dauert lange.
3. Manuelles Testen ist mühsam.

Es wird zwischen verschiedenen Arten des Testens unterschieden. Zum Beispiel testet man kleine Code-Einheiten mittels Unit-Testing und das Zusammenspiel mehrerer Komponenten (Code-Einheiten) mittels Integration-Testing.

Magento TAF zielt auf Integrationstests ab. Genauer gesagt führt das Framework Frontend-Tests bzw. funktionale Tests aus. Es steuert einen Web-Browser (“gebe diese URL ein”, “Klicke auf jenes Element”, …) und überprüft das Ergebnis. Somit kann man grob die Funktionalität des Systems überprüfen, wie man es auch als Entwickler/Anwender mit seinem eigenen Web-Browser machen würde. Zum Einsatz kommen die weit verbreiteten Tools PHPUnit und Selenium.

Der Nachteil von Frontend-Tests: man kommt nicht auf alle Fehler. Wenn ich im Magento-Backend ein Produkt anlege, kann Magento mir (irrtümlich) eine Erfolgsmeldung zurück geben, obwohl eine Kleinigkeit im Hintergrund nicht funktioniert hat. Der Vorteil: man kann überprüfen, ob die Anwendung als Ganzes für den Endanwender (scheinbar) funktioniert.

Wie geschrieben: die Integrationstests bzw. funktionalen Tests von Magento TAF sind dazu da, um das Zusammenspiel von Komponenten zu prüfen. Um jede Kleinigkeit im Code zu überprüfen, sind Unit-Tests nötig, und die werden gerade für Magento 2 entwickelt.

Soweit ich gesehen habe, testet Magento TAF aktuell nur Webshop-Backend-Funktonalitäten. Es sollte aber genau so möglich sein, Teste der Oberfläche für Webshop-Kunden durchzuführen.

Disclaimer

Magento liefert für Magento TAF eine Installationsanleitung mit, die

1. ganz am Anfang mit der Einrichtung eines Webservers beginnt,
2. andere Anforderungen und Voraussetzungen als ich hat und
3. schon ein wenig älter sein dürfte.

Mein Weg weicht daher von der Anleitung ab. Sofern ich keinen Schritt vergessen habe (meinen Test habe ich doch schon vor einigen Tagen gemacht), bringt man Magento TAF aber auch so zum Laufen.

Ich habe mich bisher noch nicht mit den Details von Magento TAF beschäftigt: ich wollte nur einmal sehen, wie das Baby läuft. Für eure Tipps, Entdeckungen und Hinweise auf Fehler in den Kommentaren bin ich dankbar!

Szenario

Der Installation-Guide von Magento TAF geht von folgenden Grundlagen aus:

• Es ist noch kein Webserver eingerichtet.
• Der Webserver läuft auf einem Windows-System.
• Der Test-Browser läuft auf einem Windows-System.
• Webserver und Test-Browser laufen auf demselben System.

Meine Grundlagen:

• Ein Webserver mit umfangreicher Software ist bereits eingerichtet.
• Der Webserver läuft auf einem Linux-System ohne Desktop-Umgebung (Debian Squeeze, eine VM in Virtualbox).
• Der Test-Browser läuft auf einem Windows-System.
• Webserver und Test-Browser laufen auf unterschiedlichen Systemen.

Voraussetzungen

Egal, welchen Weg ihr wählt (den des Installation Guides, meinen oder einen eigenen): es kann nie schaden, sich vor Augen zu führen, was man auf jeden Fall benötigt.

Server:

• Webserver mit Apache, MySQL und PHP
• PEAR
• PHPUnit
• Git
• Java SDK
• Selenium
• Eine jungfräuliche Magento-Installation
• Magento TAF

Client:

• Java SDK
• Selenium
• Web-Browser (z.B. Firefox)

Installation & Einrichtung des Servers

Jetzt muss ich euch enttäuschen: ich liefere keine Anleitung von A-Z, wie man jede einzelne Komponente in einem Linux-System installiert. Das würde doch etwas zu weit führen, doch ich nehme an, dass die meisten von euch die Basics schon am Laufen haben.

Allgemein lässt sich sagen: gebt nicht zu viel auf die im Installation-Guide verwendeten Versionen. Er ist schon ein paar Tage alt, ich verwende die aktuellen Software-Versionen unter Debian Squeeze und fahre gut damit.

Apache, MySQL, PHP, PEAR, PHPUnit, Git, Java SDK

Folgende Versionen sind in meiner Test-VM installiert:

• Apache/2.2.16 (Debian)
• MySQL 5.1.49-3 (Debian)
• PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli)
• PEAR Version: 1.9.4
• PHPUnit 3.6.4
• Git 1.7.2.5
• Java OpeonJDK 1.6.0_18

Die normale Installation über den Paket-Manager sollte reichen.

Bei PHPUnit benötigt ihr die eine oder andere Komponente. Wenn ihr sicher gehen wollt, dass ihr alles beisammen habt, zieht das Dokument MagentoTestAutomationFrameworkInstallationGuide.pdf heran (siehe unten) und befolgt die Anweisungen im Abschnitt “Installing PHPUnit”.

Einrichtung der Magento-Testinstanz

Ich habe die aktuelle Version Magento CE 1.6.1.0 über mein Install-Skript im Verzeichnis /var/www/magento/shops/taf.magentoshops.vm/eingerichtet. Ihr könnt natürlich ein anderes Verzeichnis festlegen.

Baut die Indizes neu auf, markiert alle Backend-Benachrichtigungen als gelesen und deaktiviert den Cache.

Klickt euch zum Menüpunkt “System > Configuration > Advanced > Admin > Security” durch und setzt “Add Secret Key to URLSs” auf “No”.

Einrichtung von Magento TAF

Ich installiere TAF im Verzeichnis /var/www/magento/tests/taf.

Ihr könnt auch hier wieder ein anderes Verzeichnis wählen.

mkdir /var/www/magento/tests/
cd /var/www/magento/tests/
git clone https://github.com/magento/taf.git
Cloning into taf...
remote: Counting objects: 187, done.
remote: Compressing objects: 100% (77/77), done.
remote: Total 187 (delta 98), reused 187 (delta 98)
Receiving objects: 100% (187/187), 373.73 KiB | 303 KiB/s, done.
Resolving deltas: 100% (98/98), done.

Ihr findet im Repository zwei Dokumente vor:

• MagentoTestAutomationFrameworkInstallationGuide.pdf: die Installations-Anleitung. Wir werden sie gleich benötigen, um einige Einstellungen Firefox vorzunehmen.
• MagentoTestAutomationFrameworkUsersGuide.pdf: das Dokument geht näher auf die Verwendung von Magento TAF ein. Ich habe es mir bisher noch nicht angesehen.

Im nächsten Schritt müsst ihr die Konfigurationsdateien für PHPUnit und die Selenium-Konfiguration kopieren und anpassen.

cd /var/www/magento/tests/taf/
cp phpunit.xml.dist phpunit.xml # muss vorerst nicht angepasst werden
cp config/browsers.yml.dist config/browsers.yml # Browser- und Magento-Daten muessen angepasst werden; dazu kommen wir gleich
chmod 744 runtests.sh # runtests.sh startet den Testlauf
mkdir -m 777 tmp # wurde bei mir nicht automatisch erstellt

Einrichtung von Selenium

Die Installationsanleitung für Magento TAF empfiehlt die Installation von Selenium 1.x. Das ist allerdings nicht so toll, denn wie auch schon andere feststellen mussten, öffnet Firefox ein leeres Fenster und tut nichts mehr.

Daher: wir nehmen Selenium 2. Das hat auch den Vorteil, dass die Installation wesentlich einfacher ist. Der Nachteil ist, dass die Dokumentation für Selenium 2 noch ziemlich grottig ist. Am meisten hilft uns noch der Quick Start für Grid2.

Die Bezeichnungen für die Komponenten von Selenium haben sich geändert und sind etwas verwirrend. Das ganze ist in etwa so:

• In Selenium 1 sprach man von einer Server-Client-Konfiguration als Selenium Grid. Dazu setzt man einen Hub als Server auf  (oft synonym als Selenium Grid bezeichnet) und stellt mit einer oder mehreren Instanzen von Selenium RC (Remote Control) als Clients eine Verbindung zum Hub her.
• In Selenium 2 spricht man vom Selenium Server. Anstatt zwei getrennter Anwendungen gibt es ein einziges Java-Archiv (jar) für Server und Client. Beim Start gibt man an, ob Selenium Server als Hub (= Server) oder als Node (= Client) ausgeführt wird. Intern wird für den Hub auch noch die Bezeichnung “Grid” verwendet (siehe unten bzw. Google Code). Wie gesagt: es ist verwirrend.
  Zudem gibt es in der neuen Nomenklatur noch den “WebDriver”, doch damit wollen wir uns heute wirklich nicht beschäftigen.

Wenden wir uns also der Installation von Selenium zu. Sie ist denkbar einfach, denn man muss sich nur das entsprechende Archiv holen (aktuell 2.15):

mkdir /var/www/tools/selenium
cd /var/www/tools/selenium
wget http://selenium.googlecode.com/files/selenium-server-standalone-2.15.0.jar

Nun starten wir den Server mit dem folgenden Befehl

java -jar selenium-server-standalone-2.15.0.jar -role hub

und erhalten folgende Ausgabe:

15.12.2011 15:59:45 org.openqa.grid.selenium.GridLauncher main
INFO: Launching a selenium grid server
15.12.2011 15:59:48 org.openqa.jetty.http.HttpServer doStart
INFO: Version Jetty/5.1.x
15.12.2011 15:59:48 org.openqa.jetty.util.FileResource <clinit>
INFO: Checking Resource aliases
15.12.2011 15:59:49 org.openqa.jetty.util.Container start
INFO: Started org.openqa.jetty.jetty.servlet.WebApplicationHandler@19e15c
15.12.2011 15:59:49 org.openqa.jetty.util.Container start
INFO: Started WebApplicationContext[/,/]
15.12.2011 15:59:49 org.openqa.jetty.http.SocketListener start
INFO: Started SocketListener on 0.0.0.0:4444
15.12.2011 15:59:49 org.openqa.jetty.util.Container start
INFO: Started org.openqa.jetty.jetty.Server@161f10f

Gratuliere, der Selenium-Server läuft! Wie ihr sehen könnt, läuft der Server standardmäßig auf Port 4444. Wer will, gibt über den Parameter -port einen anderen Port an.

Wartet ein wenig, dann könnt ihr im Browser das noch sehr spartanische Webinterface aufrufen (IP bitte anpassen):

http://192.168.1.2:4444/grid/console

Wenn ihr ein Timeout bekommt, wartet 1 bis 2 Minuten und probiert es noch einmal.

Die Oberfläche sollte so aussehen:

Jetzt bereiten wir den Client auf seine Aufgabe als Tester vor und dann kann es losgehen.

Einrichtung des Clients

Meine Windows-Maschine weiß natürlich noch nichts von ihrem Glück. Deswegen muss ich nun in Windows das Java SDK und Selenium  installieren sowie Firefox einrichten.

Beginnen wir gleich mit der Anpassung von Firefox. Die Installationsanleitung schlägt vor, Firefox 3.6.x zu verwenden. Das ist Käse, denn die dort beschriebene Warnung “Selenium RC is not compatible with Firefox 4 currently” trifft auf Selenium 2 nicht mehr zu. Nehmt ruhig den aktuellen Firefox und befolgt die Anweisungen des Dokuments zum Erstellen eines speziellen Selenium-Profils unter “Creating Selenium Profile” und “Suggested Settings for Selenium Profile”. Selenium hat bei mir Firefox übrigens gefunden, ohne dass ich den Pfad bekannt geben oder anpassen musste. Vielleicht liegt das ja auch an Selenium 2.

Gut, dann auf zu Java und Selenium.

Zur Installation des Java SDK muss ich hoffentlich nicht viele Worte verlieren. Achtet darauf, die Umgebungsvariablen für Java richtig zu setzen.

Die Installation von Selenium ist auch auf dem Windows-System nicht der Rede wert. Holt euch dieselbe Datei wie zuvor vom Server und platziert sie in einem Verzeichnis eurer Wahl, z.B. C:\Programme\Selenium\.

Habt ihr alles richtig gemacht, könnt ihr in der Windows-Shell (Eingabeaufforderung) nun Folgendes eingeben:

cd C:\Programme\Selenium\
java -jar selenium-server-standalone-2.15.0.jar -role node -hub http://192.168.1.2:4444/grid/register

Als Hub gebt ihr IP und Port des vorhin gestarteten Servers an. Die Node lauscht standardmäßig auf Port 5555. Auch das lässt sich wieder ändern.

Eure Node sollte eine Antwort ausspucken:

15.12.2011 16:03:50 org.openqa.grid.selenium.GridLauncher main
INFO: Launching a selenium grid node
16:03:50.625 INFO - Java: Sun Microsystems Inc. 20.4-b02
16:03:50.625 INFO - OS: Windows XP 5.1 x86
16:03:50.640 INFO - v2.15.0, with Core v2.15.0. Built from revision 15105
16:03:50.734 INFO - RemoteWebDriver instances should connect to: http://127.0.0.1:5555/wd/hub
16:03:50.734 INFO - Version Jetty/5.1.x
16:03:50.734 INFO - Started HttpContext[/selenium-server/driver,/selenium-server/driver]
16:03:50.734 INFO - Started HttpContext[/selenium-server,/selenium-server]
16:03:50.734 INFO - Started HttpContext[/,/]
16:03:50.734 INFO - Started org.openqa.jetty.jetty.servlet.ServletHandler@76cbf7
16:03:50.734 INFO - Started HttpContext[/wd,/wd]
16:03:50.750 INFO - Started SocketListener on 0.0.0.0:5555
16:03:50.750 INFO - Started org.openqa.jetty.jetty.Server@186d4c1
16:03:50.750 INFO - using the json request : {"class":"org.openqa.grid.common.RegistrationRequest","capabiliti
es":[{"seleniumProtocol":"Selenium","browserName":"*firefox","maxInstances":5},{"seleniumProtocol":"Selenium",
"browserName":"*googlechrome","maxInstances":5},{"seleniumProtocol":"Selenium","browserName":"*iexplore","maxI
nstances":1},{"seleniumProtocol":"WebDriver","browserName":"firefox","maxInstances":5},{"seleniumProtocol":"We
bDriver","browserName":"chrome","maxInstances":5},{"seleniumProtocol":"WebDriver","browserName":"internet expl
orer","maxInstances":1}],"configuration":{"port":5555,"register":true,"host":"192.168.1.3","proxy":"org.open
qa.grid.selenium.proxy.DefaultRemoteProxy","maxSession":5,"hubHost":"192.168.1.2","role":"node","registerCyc
le":5000,"hub":"http://192.168.1.2:4444/grid/register","hubPort":4444,"url":"http://192.168.1.3:5555","rem
oteHost":"http://192.168.1.3:5555"}}
16:03:50.750 INFO - starting auto register thread. Will try to register every 5000 ms.
16:03:50.750 INFO - Registering the node to hub :http://192.168.1.2:4444/grid/register
16:03:56.343 INFO - Executing: org.openqa.selenium.remote.server.handler.Status@186df0f at URL: /status)
16:03:56.343 INFO - Done: /status
16:04:01.375 INFO - Executing: org.openqa.selenium.remote.server.handler.Status@16921fd at URL: /status)

Der Client hat sich somit beim Server angemeldet. Aktualisiert die Seite im Web-Browser und ihr seht hoffentlich diese Darstellung:

Sehr gut!

Test-Suite starten

Jetzt müssen wir nur noch die Konfiguration anpassen und dann geht es los! Dazu wechselt ihr wieder zum Server und bearbeitet die Datei /var/www/magento/tests/taf/config/browsers.yml.

Gebt unter “browsers” Host und Port des Clients an (im Beispiel 192.168.1.3 und 5555). Dass hier Chrome steht, war bei mir übrigens herzlich egal: gestartet wurde immer Firefox.

Dann definiert ihr unter “applications” den Pfad zum Webshop-Frontend und -Backend, gebt die Daten des Admin-Users an und ihr seid bereit.

Ich hoffe ihr habt ein wenig (viel) Zeit mitgebracht, denn wir lassen nun den vollständigen Test durchlaufen. Wechselt in das übergeordnete Verzeichnis /var/www/magento/tests/taf/ und ruft

./runtests.sh

auf.

In der Shell mit dem gestarteten Hub solltet ihr nun Aktivität bemerken. Nach ein paar Sekunden öffnen sich im Client zwei Firefox-Fenster und der Spaß geht los!

Bei mir dauerte der gesamte Test mit einer Browser-Instanz exakt 3 Stunden 30 Minuten.

Ergebnis

Nachdem der Test durchgelaufen ist, bekommt man ein Testergebnis in der typischen PHPUnit-Manier präsentiert:

PHPUnit 3.6.4 by Sebastian Bergmann.

The Xdebug extension is not loaded. No code coverage will be generated.

........................FSSSSSSFFFF...........F.F.F.F.F.F.F....  63 / 663 (  9%)
.F.......F....FF..........................................F.... 126 / 663 ( 19%)
...........F........FFFFFF....F......FSSSSSSSF........FS....... 189 / 663 ( 28%)
.......FSSSSSSSSSSSSSSSSSSS.................................... 252 / 663 ( 38%)
........................................................F...... 315 / 663 ( 47%)
...F.......F................................................... 378 / 663 ( 57%)
............................................................... 441 / 663 ( 66%)
...................FFFFF....................................... 504 / 663 ( 76%)
............................................................... 567 / 663 ( 85%)
............................................................... 630 / 663 ( 95%)
............F.....FSSSSSSSSSSS

Time: 03:30:00, Memory: 39.75Mb

There were 39 failures:

### Beschreibungen der Fehler

There were 44 skipped tests:

### Beschreibungen der übersprungenen Tests

FAILURES!
Tests: 619, Assertions: 26197, Failures: 39, Skipped: 44.

Ihr seht: insgesamt enthält die Testsuite im Moment 663 Tests mit über 26.000 Überprüfungen.

Auf die Zahl der fehlgeschlagenen Tests in meinem Listing dürft ihr nicht zu viel geben.

Ich habe zum Beispiel gesehen, dass ein Teil der Fehler dadurch entstand, dass die Index-Prozess-Lock-Dateien nicht schreibbar waren (/var/www/magento/shops/taf.magentoshops.vm/var/locks/index_process_*.lock). Das dürfte daran gelegen habe, dass ich die Testsuite mit einem User gestartet habe, der nicht in derselben Gruppe wie www-data ist. Zumindest wurden die Lock-Dateien unter diesem User angelegt. Nachdem ich ihnen die Rechte 666 verpasst habe, liefen die Tests.

Weitere Log-Dateien und Reports werden im Verzeichnis /var/www/magento/tests/taf/tmp abgelegt. Dort findet ihr

• das PHPUnit-Logfile im JSON-, TAP-, TXT- und XML-Format,
• den Selenium-Log sowie
• das testdox-Dokument mit einer leicht lesbaren Aufstellung der erfolgreichen und fehlgeschlagenen Dateien als HTML- und TXT-Datei.

Geprüfte Funktionen, erstellte Daten

Ich habe natürlich nicht die ganzen 3h30min zugesehen, doch es hat den Anschein, als ob bisher nur das Backend getestet wird – das dafür jedoch recht gründlich.

In den bei mir durchgeführten 619 Tests wurden folgende Datensätze erstellt:

• 6 Backend-Adminuser
• 1 Website, 3 Stores, 2 Store-Views
• 44 Kunden (+3 gelöschte Accounts)
• 109 Produkte (+ 14 gelöschte Produkte) – alle Produktarten verwendet
• 51 Produktattribute (verschiedene Formularelemente etc.)
• 5 Attributsets
• 23 Kategorien (bis zu 11 Ebenen tief)
• 46 Bestellungen
• 21 Rechnungen
• 12 Shipments
• 18 Credit Memos
• 2 Warenkorbpreisregeln

Fazit

Auf den ersten Blick macht Magento mit dem Test-Automation-Framework einen schönen Schritt in die richtige Richtung. Klarerweise wird es bei so einem großen System dauern, bis alle Funktionalitäten (auch im Webshop-Frontend) abgedeckt sind. In Kombination mit den für Magento 2 entwickelten Unit-Tests ist zu hoffen, dass die Stabilität von Magento in Zukunft erhöht wird.

Worauf ich noch gar nicht eingehen konnte ist das Cross-Browser-Testing sowie die Erstellung eigener Tests mit Magento TAF. Die mitgelieferten PDFs bieten einen Einstieg in das Schreiben von Tests sowie Testdaten. Vielleicht hat sich jemand von euch damit beschäftigt und schreibt etwas dazu – wäre spannend.

Der eine oder andere von euch hat es schon mitbekommen: wir bei LimeSoda veranstalten jedes Jahr eine Weihnachtsfeier für Kunden und Freunde. Weil es langweilig ist, nur eine Einladungsmail hinauszuschießen und ein paar Kekse zu verteilen, stellen wir die Party unter ein bestimmtes Motto und drehen ein Video dazu, um die Gäste einzustimmen. Passend zum Thema gibt es einen (freiwilligen) Dress-Code: wir ziehen also Fasching/Karneval schon ein wenig vor.

Limetology. Follow. Like. Share.

Nach ausgiebigem Brainstorming hatten wir unser Thema 2011: Limetology. Follow. Like. Share. Die Idee: wir nehmen den hirnlosen Social-Media-Hype auf die Schippe und gründen unsere eigene Sekte “Limetology”. Unser Symbol, die Limette, steht für die Erlösung und das Paradies, schlichtweg die Erfüllung aller Online-Marketing-Wünsche.

• Niemand gibt “like” oder “+1″ für eure Website?
• Google hat euch aus den Rankings geschmissen?
• Euer Twitter-Account zwitschert verlassen vor sich hin wie Oliver Pocher?

Schließt euch uns an und alle eure Sorgen sind passé!

Richtig erkannt: es handelt sich um eine Adaption des Sister-Act-Hits “I will follow him”. Natürlich kann man sich das Video direkt bei Youtube ansehen (Limetology: We will follow you (one of the best new songs 2012 in HQ)).

Für das volle Erlebnis geht ihr aber auf die in Windeseile zusammengeschusterte Limetology-Website: http://limetology.limesoda.at

Da geht es dann so richtig rund, mit Twitter- und Facebook-Postings, Zeitungsschlagzeilen und allem drum & dran.

Dankeschön

Wie jedes Jahr wäre unser Weihnachtsvideo nichts geworden ohne die großartige Arbeit von:

• Musik (Komposition, Aufnahme und Mastering): Lukas Bonomeo
• Director: Andreas Waldschütz
• Assistant Director: Merlin
• Kamera und Bearbeitung: Thomas Rath
• Make-Up: Steffi Lamm
• Choreographie: Conny Aitzetmüller
• Location & Setup: Asta C. Krejci-Sebesta

Es ist erstaunlich, was sich regelmäßig aus unseren talentfreien Darbietungen herausholen lässt. Danke dafür!

Vergangenes und Zukünftiges

Unser letztjähriger Weihnachtssong LimeSoda vs. Skero – Almhüttenparty vs. Kabinenparty hat so richtig eingeschlagen (ca. 100.000 Views für die Einladung zu einer kleinen Firmenfeier), darüber habe ich bereits geschrieben. Auch die Videos davor lösen bei uns regelmäßig Nostalgieanfälle aus – deshalb haben wir unsere eigene kleine Timeline der LimeSoda-Weihnachtsvideos mit “Making-Of”s geschaffen.

Da wächst natürlich der Druck: was fällt uns nächstes Jahr zum zehnjährigen Firmenjubiläum ein? Das steht in den Sternen, die Idee ändert sich sicher noch 5-mal. Wenn ihr Ideen habt oder Teil der legendären Videos werden wollt: wir sind für alles offen!

Lyrics

Und zum Abschluss die Lyrics zum Mitsingen – da könnt ihr euer Talent gleich überprüfen!

I will follow you…
Follow you whereever you may tweet
I will always subscribe to your feed
And nothing can keep me offline
you’re in my favourits

I will follow you
Ever since i liked your page I knew.
There isn’t a backlink too cheap
No wall so high it can keep
Keep me away,
Away from your posts

We love you
We love you
We love you
And what you’ll share
we like it
we like it
we like it

We will follow you
Ever since we liked your page we knew.
There isn’t a adword too cheap
Nofollow so high it can keep
Keep us away,
Away from your page

We like you
We like you
We like you
And what you tweet
We share it
We share it
We share it
You’ll always be
my best friend
my best friend
my best friend
from now until
forever,
forever,
forever.

There isn’t a timeline too deep
No wall so high it can keep
Keep us away,
Away from the lime

In dem Artikel gehe ich zuerst auf die Frage ein, was ein Widget überhaupt ist und welche Widgets in Magento mitgeliefert werden. Danach geht es ans Eingemachte.

Ich beschreibe die Grundlagen, und zwar

• wie man den Namen und die Beschreibung des Widgets festlegt,
• das Widget übersetzbar macht
• und für E-Mail-Templates freischaltet.

Danach gehe ich auf die Parameter ein, mit denen man dem Shop-Händler für die Konfiguration des Widgets ein Formular z.B. aus

• einzeiligen Textfeldern,
• einfachen Auswahlmenüs (Dropdowns),
• Mehrfachauswahlen (Multi-Selects) oder
• Zeitangaben

basteln kann.

Zur Abrundung beschreibe ich, wie man sein Widget im TinyMCE-Editor mit einem individuellen Icon versehen kann.

Leider hatte ich nur wenig Zeit, den Artikel fertig zu stellen (dafür 2 geduldige Adventkalender-Wächter ). Ich hoffe, dass der Artikel dennoch bei dem einen oder anderen Interesse an Widgets weckt.

Nachdem ich drei Reisen und mehrere Ausflüge mit dem Tamrac 3385 unternommen habe, ist es Zeit für einen Erfahrungsbericht.  In dem Review zu diesem DSLR-Rucksack gehe ich kurz auf zwei Alternativen, den Kata DR-467i und den Lowepro Fastpack 350 ein, die bei meiner damaligen Recherche weitere Favoriten waren.

Eckdaten & Features

Der Speed Pack 85 ist ein Rucksack, der speziell für Fotokameras und Laptops ausgelegt ist. Er verfügt über eine Kammer für Kamera und Zubehör, ein großes Fach für Laptops oder Unterlagen im A4-Format und eine Kammer für Sonstiges (Verpflegung o.ä.). Der Kamera- und der Laptop-Bereich sind speziell gepolstert und in der Fächer-Einteilung an das eigene Equipment anpassbar.

Laut der offiziellen Website von Tamrac hat der Rucksack Außenmaße von 36 x 23 x 50cm und wiegt alles inklusive 1626 Gramm. Durch die Polsterungen fällt das Gewicht gegenüber einem ordinären Backpack etwas höher aus. Die 1,6 Kg verteilen sich aber gut und fallen meiner Meinung nach nicht negativ auf. Zudem können nicht benötigte Trennelemente entfernt werden. Wie alle Taschen, die auch für Laptops ausgelegt sind, würde ich den 3385 nicht als “kompakt” beschreiben, zudem er klarerweise auch ziemlich formstabil ist, um die Ausrüstung zu schützen. Im Vergleich zu anderen Fotorucksäcken dieser Größe schlägt er sich gut.

Bevor wir uns den Aero Speed Pack 85 näher ansehen, verliere ich ein paar Worter darüber, für wen sich das Produkt meiner Meinung nach eignet.

Für wen ist dieser Rucksack geeignet?

Man sollte den Tamrac 3385 in Erwägung ziehen, wenn man:

• mit dem Foto-Rucksack auf Reisen fahren will.
• einen Laptop, A4-Unterlagen (oder größer) bzw. ähnlich sperriges Gepäck unterbringen muss.
• viel Equipment mit sich führt.
• Wert auf eine gute Polsterung und große Flexibilität bei der Fächereinteilung legt.

Mit einer anderen Fototasche wird man vielleicht glücklicher, wenn man:

• nur kurze Fotoausflüge in der Umgebung mit eingeschränkter Konfiguration macht.
• keinen Laptop oder große Unterlagen mit sich führt.
• wenig Equipment besitzt und nicht plant, das zu ändern.
• sehr sehr viel Equipment besitzt und auf wochenlangen Hikingtouren mit sich führen will.

Fächer und Taschen

Wie erwähnt verfügt der Tamrac über einen großen Bereich für die Kamera, ein Fach für den Laptop und eine Kammer, in der Verpflegung, leichte Jacken oder ähnliches verstaut werden können. Zudem verfügt er über Möglichkeiten, in Außentaschen weitere Gegenständen zu verstauen.

Außenbereich

Auf der rechten Seite (vom Rucksackträger aus gesehen) gibt es eine Netztasche. Hier lassen sich 0,5l-Getränkeflaschen problemlos unterbringen. Man kann die Tasche auch zweckentfremden und ein kleines Stativ wie den Joby Gorillapod SLR-Zoom mit Kugelkopf (bis 3kg) dort verstauen. Größere Stative lassen sich allerdings nicht gut unterbringen, da es keine Möglichkeit gibt, das Stativ oben zu fixieren (außer man bastelt sich selbst eine Lösung).

Für den Fall, dass man größere Stative mitnehmen möchte, gibt es am Boden 2 Plastikösen, in die man Schlaufen einführen kann. Solche Schlaufen sind nicht im Lieferumfang enthalten.

An der Frontklappe gibt es eine weitere Netztasche, in der man z.B. Reiseführer im üblichen Marco-Polo-/Polyglott-Format unterbringen kann.

Kamera-Bereich

Der für die Kamera vorgesehene Bereich befindet sich im unteren Teil des Rucksacks. Er ist auf alle Seiten hin gut gepolstert. Zur optimalen Verstauung des Equipments kann man 7 Elemente mittels Klettverschlüssen (nahezu) nach Belieben anordnen, um den Body, die Objektive und anderes Zubehör im Rucksack zu fixieren. Bei mir hat sich diese Konstruktion bisher als äußerst stabil erwiesen.

Wer nicht alle Raumtrenner benötigt, kann sie Zuhause lassen und das Gewicht reduzieren. Schlachtet man den Innenraum komplett aus (z.B. weil man ganz ohne Kamera unterwegs ist), kann man so immerhin 340 Gramm einsparen.

Zugänglich ist die Ausrüstung über die große Frontklappe und über den Schnellzugriff auf der Seite. Tamrac bezeichnet diese Lösung als “Dual Access System“.

Die Frontklappe bietet leichten Zugang zum gesamten unteren Teil des Speed Pack und ist vor allem dann zu verwenden, wenn der Rucksack flach hingelegt wird. Auf der Innenseite befinden sich zwei flache Taschen, die mittels eines Reißverschlusses geschlossen werden. Damit kein Regen über die Frontklappe eindringt, schützt eine Wetterklappe den Reißverschluss – diese überlappende Teil wirkt quasi wie eine Dachkante.

Ein besonderes Gimmick und für mich einer der Hauptgründe für den Kauf ist der Schnellzugriff auf der Seite. Mit dieser Seitentür ist es möglich, die Kamera aus dem Rucksack zu nehmen oder sie zu verstauen, ohne den Rucksack abnehmen zu müssen. Es reicht, aus dem rechten Schulterträger zu schlüpfen und den Rucksack an seine linke Seite zu holen – die Kamera ist nach wenigen Sekunden bereit und man kann den Rucksack auf der linken Schulter behalten. Eine Canon 60 D mit 18-135mm-Objektiv und Gegenlichtblende bekomme ich so locker hinein und hinaus. Laut Internetrezensionen ist das auch mit größeren Bodies und Battergriff möglich.

Auf der Innenseite verfügt die Seitentür über 3 Fächer (2 kleine, 1 größere) für Speicherkarten und ähnliche, flache Gegenstände. Sie werden über Klettverschlüsse geschlossen.

Auch beim Schnellzugriff ist der Regenschutz natürlich ein Thema. Hier wird der Zipp durch eine spezielle Konstruktion mit Gummi verschlossen, die auf mich sehr wasserresistent wirkt. Bisher war ich nur in normalem Regen mit dem Rucksack unterwegs. Hier gab es keine Anzeichen, dass irgend etwas feucht geworden wäre. Wär bei starkem Niederschlag unterwegs ist, wird sicher eine Regenhaut verwenden wollen. Die ist leider nicht im Lieferumfang enthalten.

Laptop-Fach

Der Rücken- und Bodenteil des Laptop-Faches sind mit Schaumstoff gepolstert. Wer möchte, kann die Bodenpolsterung herausnehmen, um den Raum noch geringfügig zu vergrößern. Das ist meiner Meinung nach aber nicht nötig. Man hat hier sehr viel Platz für seinen Laptop oder für Unterlagen, die nicht gefaltet werden sollen. Mein nicht gerade zierlicher 15,4-Zoll-Laptop verschwindet geradezu in dem Fach und auch 17-Zoll-Laptops gehen sich hier laut Rezensionen gut aus. Ich habe hier auch schon meinen Gorillapod hineingestopft und davon am Rücken nichts gespürt.

Verpflegungsfach

Das Verpflegungsfach eignet sich dazu, Gegenstände wie das Handy, die Geldbörse, Taschentücher, ein Jausenbrot, eine leichte Jacke oder ähnliches mitzunehmen. Allerdings muss man hier Kompromisse eingehen. Das Fach ist nicht besonders groß, so dass man eventuell etwas davon im Kamerabereich verstauen muss. Es gibt innen zwei Netztaschen, die allerdings nicht dafür geeignet sind, verschiedenen Krimskrams bombenfest bei sich zu halten.

Man merkt: ich finde dieses Fach nicht besonders gelungen. In der Praxis bringe ich hier z.B. Linsenputztücher, Taschentücher, Kaugummis, einen kleinen Reiseführer und ähnliches unter, bei dem es mir egal ist, wenn alles durcheinander purzelt.

Reisen

Meine Version ist in schlichtem Schwarz gehalten und für Nicht-Kenner nicht als Kamera-Rucksack erkennbar. Er eignet sich mit seinen Ausmaßen gut für Flugreisen: bei keinem Check auf einem der dafür “anfälligen” Flughäfen in den USA, Schweiz oder Deutschland wurde die Größe des Gepäckstücks bemängelt oder auch nur in Frage gestellt.

Die Schultergurte des Tamrac 3385 sind gut gepolstert. Ein Brustgurt ist nicht vorhanden. Ich persönlich verwende keine Brustgurte, falls man darauf Wert achtet, sollte man das aber im Auge behalten. An jedem Gurt ist eine Schlaufe angebracht, mit der weitere kleine Taschen befestigt werden können.

Die Rückenbelüftung ist in Ordnung. Im Hochsommer wird man bei längeren Touren schon ein wenig ins Schwitzen kommen – ähnlich wie bei anderen Backpacks aus dem Segment. Der Komfort ist gut, mit meinen bisherigen Rucksäcken war das Reisen weniger angenehm.

Meine “Pros”

Kommen wir zu den Argumenten, warum ich froh bin, den Tamrac 3385 gekauft zu haben:

• Das Dual Access System ist meiner Meinung nach ein echter Hit. Ich möchte nicht mehr ohne den Schnellzugriff auf der Seite unterwegs sein. In den Innenfächern habe ich den Ersatzakku und Speicherkarten untergebracht. Somit habe ich auf die drei wichtigsten Komponenten – Kamera, Speicher, Akku – sofort griffbereit. Mich würde es extrem nerven, wenn ich den Rucksack jedes mal abstellen müsste (womöglich noch auf staubigem/sandigem Boden), um an meine Kamera zu gelangen.
• Ich verfüge über jede Menge Stauraum. Was mir am Verpflegungsfach nicht so gut gefällt, gleicht das Kamerafach mehr als aus. Je nachdem, was ich an Ausrüstung dabei habe, kann ich die Fächereinteilung verändern und wenn nötig Gegenstände aus dem Verpflegungsfach in die Etage darunter verfrachten.
• Eben diese Flexibilität im Einsatz gefällt mir sehr gut. Egal, worum es geht: ich tweake meine PCs, meine Kameras, meine Einrichtung, … Der Tamrac gibt mir die Möglichkeit dazu, auch am Backpack zu optimieren.
• Obwohl der Aero Speed Pack 85 nicht der kleinste Rucksack der Welt ist, ist seine Größe und sein Gewicht aufgrund des Tragekomforts kein Problem. Er liegt gut auf dem Rücken und hat Halt, auch ohne Brustgurt. Ich bin recht klein, aber ich denke, dass auch große Menschen gut damit zurecht kommen.

Meine “Konktras”

• Wer das tolle Wetter unmittelbar vor, in oder nach einem Regenguss ausnützen will, muss seine Ausrüstung schützen. Einen Regenschutz liefert Tamrac allerdings nicht mit.
• Wer häufig auf einen Brustgurt angewiesen ist, muss testen, ob er den 3385 auch ohne Brustgurt verwenden kann oder ob er sich mit dem Schlaufen auf den Trägern eine andere Lösung basteln kann.
• Ein mittelgroßes Stativ zu transportieren, ist mit diesem Rucksack nicht leicht, da man es nicht auf der Seite befestigen kann. Natürlich kann man es unterhalb des Rucksacks fest machen, aber das ist nicht die komfortabelste Lösung.
• Das Verpflegungsfach ist mir persönlich etwas zu klein und/oder zu chaotisch. Hier muss man zugunsten des tollen Kamerafaches Kompromisse eingehen.

Fazit

Wer sich mit den wenigen Negativpunkten anfreunden kann, für den kann ich auf jeden Fall eine Empfehlung für den Tamrac 3385 Aero Speed Pack aussprechen. Der Rucksack trägt sich gut, das Equipment ist sehr gut geschützt, sowohl für Kamera und Zubehör als auch für den Laptop ist viel Platz vorhanden. Der Schnellzugriff durch das “Dual Access System” ermuntert einen dazu, die Kamera sicher zu verstauen und auch gleich wieder für einen tollen Schnappschuss heraus zu holen.

Alternativen

Wer einen Kamera-Rucksack mit denselben Kriterien wie ich sucht, aber nicht so richtig vom Tamrac 3385 überzeugt ist, könnte vielleicht mit einem Kata DR-467i oder einem Lowepro Fastpack 350 glücklich werden. Diese beiden Backpacks waren bei mir ebenfalls in der näheren Auswahl. Zu ihnen kann ich natürlich nicht so viel sagen, doch ich versuche kurz zu zeigen, was für mich für und gegen diese Rucksäcke gesprochen hat.

Der Kata DR-467i ist meiner Meinung nach ein heißes Teil. Vom Design finde ich ihn schick, durch den knallgelben Innenraum (zumindest in der einen Farbvariante) findet man sich im Innenraum gut zurecht und man kann die Innenfächer ebenfalls anordnen bzw. herausnehmen. Eine Regenhaut ist fix integriert und scheinbar kann man ein Stativ gut an der Seite unterbringen bzw. oben fixieren. Wenn ich mich recht erinnere, ist das Verpflegungsfach ein wenig größer (und dafür das Kamerafach etwas kleiner) als beim Tamrac.

Das KO-Kriterium für mich war, dass man nicht den Schnellzugriff auf die Kamera hat, sondern den Rucksack komplett abnehmen und auf den Boden stellen muss. Nett ist, dass der Rucksack scheinbar irgendwie die Balance hält und man das komplette Equipment erreichen kann, ohne die Tasche flach hinlegen zu müssen, aber trotzdem: ein Schritt zu viel für mich.

Der Lowepro Fastpack 350 verfügt wie der Tamrac über einen Seitenzugriff und die variable Inneneinteilung. Er wiegt etwas mehr als mein Rucksack, ist aber insgesamt sowohl was Funktionen als auch Ausmaße betrifft sehr ähnlich und erhält gute Bewertungen. Für mich hat damals vor allem gegen den Rucksack besprochen, dass er schlecht verfügbar war (was sich geändert haben dürfte) und er mir optisch nicht besonders gut gefällt. Irgendwie fehlt ihm ein gewisser Sexyness-Faktor. Den muss man halt durch die entsprechende Kamera wegmachen.