Mage::blog()

Ja, ich weiß: eval() is evil. Aber um dynamisch nachgeladenen JS-Code auszuführen geht halt kein Weg dran vorbei. Wenn man darin jedoch neue Funktionen definieren will, wird das ganze schnell eklig. Denn wohin (sprich: in welchem Scope) die definiert werden weiß keiner so recht.

Um euch die gleiche mühsame Fehlersuche zu ersparen: Übersicht über die Gültigkeitsbereiche. Fazit ist jedenfalls die Funktionen immer explizit auf window zu definieren:

var myEvalFunc = function() {

    eval('window.myAlert= function() {alert(123);};');

};

myEvalFunc();

myAlert();



				

Um die Vernetzung von (Web-)Applikationen zu ermöglichen sind APIs erforderlich, die den strukturierten Datenaustausch zwischen den Systemen ermöglichen. Dies ist eines der grundlegenden Konzepte des “Web 2.0″.

Die eigene Anwendung mit einem REST API auszustatten ist bei einer Zend-Framework-Anwendung dank Zend_Rest nicht schwer. Will man jedoch auch sicherstellen, dass die API das tut, was sie soll – auch nach einer noch so kleinen Änderung – kommt man um das Testen nicht herum.

Eine Möglichkeit ist hier das http4e-Plugin für Eclipse, das auch Import- und Export in verschiedene Formate erlaubt. Das ist zum Entwickeln und Debuggen einer API sehr komfortabel und angenehm. Bei größeren Projekten wird das ganze dann doch schnell unübersichtlich und nicht jeder will gleich Eclipse installieren um eine REST API zu testen. Die $9 für die Lizenz dürften wohl kaum den Ausschlag geben.

Als Alternative bin ich heute auf soapUI gestoßen. Durch die Baumansicht lassen sich auch größere Projekte übersichtlich verwalten. Die Online-Dokumentation erleichtert einem den Einstieg. Leider hat bei mir (unter Mac OS X) das Paste bei den Parametern nicht funktioniert und das Abtippen einer SHA1-Prüfsumme ist nicht gerade mein Lieblingssport. Welche Features die kostenpflichtige Version mehr bietet hat sich mir auf die Schnelle nicht erschlossen, aber vielleicht funktioniert da ja das das Copy & Paste

Wie testet ihr eure APIs? Die lassen sich ja – im Gegensatz zu irgendwelchen Interna – relativ gut testen.

Update:
Jetzt habe ich noch ein bisschen mir soapUI rumprobiert und festgestellt, dass man damit auch ganze Test-Cases erstellen kann und Bedingungen (XPath, XQuery, Script-Vergleiche, Contains, …) für die Response festlegen kann. Das klingt doch gut

Auch wenn an machen Stellen empfohlen wird, die Logfiles aus Performance-Gründen auszuschalten, halte ich nicht viel davon. Denn wenn einmal ein Fehler nicht reproduzierbar auftritt, erweisen sich die Logfiles oft als der einzige Ansatzpunkt zur Fehlersuche. Auch bei reproduzierbaren Fehlern erlauben die Logfiles Rückschlüsse darauf, wie oft der Fehler in der Vergangenheit aufgetreten ist. Wenn man die Logfiles jedoch einfach so immer weiter wachsen lässt, werden sie immer unübersichtlicher und verbrauchen einfach immer mehr Platz. Mit dem Unix-Tool logrotate kann man Logfiles einfach und bequem per Cronjob komprimieren, kopieren und nach einem konfigurierbaren Zeitraum löschen lassen.

Zunächste muss eine entsprechende Konfiguration angelegt werden. Die Pfadangaben beziehen sich auf Debian Lenny. Als Root am besten eine neue Datei /etc/logrotate.d/magento anlegen, ansonsten bietet sich ~/.logrotate.conf an. Im Beispiel werden im Wochenrhythmus verschoben (weekly) und jeweils 5 Versionen (rotate 5) vorgehalten. Die alten Logfiles automatisch komprimiert (compress).

/srv/www/var/log/exception.log {
        weekly
        rotate 5
        compress
}
/srv/www/var/log/system.log {
        weekly
        rotate 5
        compress
}

Die Konfigurationsdatei in /etc/logrotate.d sollte eigentlich bereits automatisch ausgeführt werden. Für andere Dateien muss noch ein separater Cronjob eingerichtet werden:

2 3 * * * /usr/sbin/logrotate -s ~/.logrotate.status ~/.logrotate.conf

Wie versprochen hier die Slides vom heutigen Vortrag auf der Meet Magento:

Alle Jahre wieder treffen sich Entwickler, Entscheider und Interessierte in Leipzig zur Meet Magento. Da sind wir natürlich dabei und mischen uns unter’s Volk, um die neuesten Informationen und Trends rund um Magento abzugreifen.

Die Keynote hält in Fortsetzung der Tradition wieder Roy Rubin. Viel Neues findet sich in dieser nicht wieder: Magento wächst. Entwickler sind knapp. Magento macht viele Leute reich. Wir haben uns alle lieb. Das füllt jedoch alles keinen Blog-Beitrag.

Eine Sache gefiel mir jedoch in der Keynote: Varien bzw. Magento Inc. alleine konnte den rasanten Aufstieg kaum stemmen. Roys Dank ging dementsprechend an alle Shop-Betreiber, Integratoren, Modulentwickler und sonstigen Mitarbeiter im großen Magento-Zirkus.

Da möchte ich mich anschließen: Vielen Dank an Vinai, Timo, Rico, Damian, Rouven, Alex, Ruben, Jörg, Freddy, Oliver, Allen, Stefan, Nicolai, Helge, Chris, Steffen, Patrick, Jean, Thorsten, (wieso sind das alles Männer?) Josi und last but not least natürlich den Mage::blog()-König David sowie alle, die ich sonst vergessen habe. Ohne Euch würde das alles auf alle Fälle weniger Spaß machen – in diesem Sinne: Weiter so!