The future of testing is yellow

Pingdom, my favourite service for monitoring my servers, released a new tool yesterday that saves you from becoming a click monkey: Transaction Monitor.

What it does is accessing your webpage, clicking links, filling out forms and checking on the results (URL, Status Codes, etc.). I just implemented it for checking all of our stores checkout processes once a day.
Setting up is straigt forward and easy (as long as you have a check left in your Pingdom account). The Check editor offers context sensitive suggestions on actions and validations and has instant feedback on how long it took to perform the action and wether it was successful or not.
check-editor

So with the Transaction Monitor annyoing repetitive task can be automated and thanks to that performed even more often as when executed manually.

check

For some inexplicable reason however there is an artificial limit on the number of steps you can add to a check which is currently 25 and limits the usefulness unnecessarily.

Viel heiße Luft

Es gibt ja auch noch andere Shopbetreiber die bloggen. Und zumindest so tun, als würden sie der Community was zurückgeben.

Natürlich gilt es Chancengleichheit für alle Kollegen zu gewährleisten: wer die Präsentation ebenfalls haben möchte, schreibt mir einfach eine mail

Habe ich gemacht. Mehrmals. Und der Kollege auch. Reaktion: Keine. Auch Kommentare im ‘Blog’ werden ignoriert, indem sie einfach nicht freigeschaltet werden.

Da bleibt mir nur zu sagen: Put your money where your mouth is. Oder einfach keine leeren Versprechungen abgeben.

#btconf – Take 2

I was very exited to be part of beyond tellerrand 2012 and I didn’t get disappointed.

While the conference in 2011 was great, this year it was even greater. And I got a sneak peak on next years speakers and 2013 might be even greaterer. And there is another good news: We won’t have to wait a whole year this time as Marc switches the dates for Play! and Web and the later will take place in May 2013, 27th to 29th to be exact.

My fellow german colleagues often nickname Beyond Tellerrand as „Klassentreffen” (class reunion) for the german webworker scene and that exactly nails it. You can meet everybody in Düsseldorf and it was great to see Sandra, Eric, Christian, Marc and all the others again and meet new talented guys like Dennis and Andreas. Plus we had nice vegan food together.

Those who follow me on Twitter might have noticed that I didn’t tweet that much this time. And I barely took notes. This is because I was afraid to miss something from all these great talks. And all of them were fascinating, both those with more technical details and those without. So I won’t get into any details here, others have already done this and more will follow. Marc will most likely put a nice list of all posts on Lanyrd or somewhere else. Marc is collecting all write-ups on the conference’s lanyrd-page.

What I love most about this conference is most likely this familiar flair that’s everywhere. And this is most likely because of Marc. No matter how busy he might be, there is always time for a little chat or a beer. Thanks to this you don’t feel like just attending a conference but being part of it. Of course his team does also a tremendous job to run this so smoothly and a great thank you goes out to them, too.
The worst thing is that I’m in such a passive role. I’m just not used to it, I’m a maker in everything I do. You’ll for instance never see me in a baseball stadium just watching. So this is really hard for me. And I’ll have to change this one day.

Pictured above is BTW my brand new Wacom Bamboo Stylus which I ‘won’ at the conference. Thanks to Wacom for the Bamboo and thanks to Marc for throwing an orange one in my direction, as orange is my favorite color.

Der schnellste Erzgebirge-Palast, den es je gab.

Schnell ist der Erzgebirge-Palast ja eigentlich schon immer. Also spätestens seit Ende 2008, wo zum ersten Mal der Server etwas geschwächelt hat und ich viel optimiert habe. Seit dieser Zeit kommen auch die statischen Inhalte größtenteils von Amazons Cloudfront CDN. In den letzten Jahren hat es der Shop mit diesen Optimierungen in Google’s PageSpeed auf einen Wert von 95 (100 ist der Maximalwert) gebracht.

Ich habe auch viel dazu geschrieben, wie man mit einfachen Mitteln ähnliche Werte erreichen kann. Was ich nie erwähnt habe ist die Sache mit dem CDN, weil das schon eher Highlevel ist und weil mein bisheriger Workflow, Cloudfront war damals quasi frisch geschlüpft und konnte noch nicht wirklich viel, doch sehr umständlich ist:
Inhalte mussten auf Amazon S3 liegen, was man zwar mit einem Tool wie s3sync mehr oder weniger automatisieren kann, aber aufwendig ist es trotzdem. Und da ich lange Expire-Header nutze musste ich beispielsweise dem CSS immer ein Datum mitgeben, das ganze syncen und schließlich die Referenz im <head> auch noch anpassen. Nichts, was man irgendwem raten möchte, nachzubauen.

Beim Blättern in den Folien von Christian Schäfer kam mir dann der Gedanke, dass ich mir ja grad mal das PageSpeed-Resultat vom Shop anzeigen lassen könnte. Weiterhin 95, aber ein Punkt tauchte dort auf, der mich eigentlich schon immer nervt, seit ich auf das CDN umgestellt habe: Die CSS-Datei ist nicht gzip-komprimiert. Und wir reden hier von 65kB vs. 12kB! Aus dem Grund hatte ich da auch schon mal versucht, was zu bauen, was aber nie wirklich funktioniert hat (Datei bereits gezippt ablegen und mit entsprechendem Zusatzheader ausliefern). Kurz gegoogelt und darauf gestoßen, dass Cloudfront schon seit einiger Zeit ‘custom origin’ unterstützt. Das hat zwei Vorteile:

  1. Die Inhalte müssen nicht mehr wie bisher auf S3 liegen sondern können von einem beliebigen Webserver kommen.
  2. Header, die der Original-Webserver schickt, werden von Cloudfront genau so weitergegeben.

Man braucht dazu nur zwei Dinge:
Eine Domain, die cookieless arbeitet. Also einen vhost einrichten, der das selbe DocumentRoot hat wie der eigentliche Webauftritt und diesem sagen, dass er sämtliche Cookies verwerfen soll: Header unset Cookie.
Mit dieser Domain, nennen wir sie mal static.example.org, legen wir jetzt eine neue Distribution in Cloudfront an, geben an, dass die Header so übernommen werden sollen, wie sie von der Quelle kommen, warten einen Moment, bis das alles deployed ist und können das ganze dann wie bisher nutzen. Statt von S3 holt Cloudfront jetzt aber die Daten von unserem Server. Das passiert auch nur genau beim ersten Request, denn ab dann hat Amazon das ganze ja im Cache.

Damit kann man Cloudfront nicht nur mit gzip nutzen, sondern sogar mit mod_rewrite, denn die eigentlichen RewriteRules werden ja auf dem eigenen Server ausgeführt. Das eröffnet völlig neue Möglichkeiten und so hat mein CSS keinen von Hand eingetragen Datumsteil mehr, sondern einen dynamisch ausgelesenen Zeitstempel des letzten Modifikationsdatums:
http://cdn6.wstatic.com/templates/erzgebirge/styles-yui-min-1350656989.css

Wer sich übrigens dafür interessiert, wie ich das für xt:Commerce umgesetzt habe, dass die statischen Inhalte über Cloudfront ausgeliefert werden, möge dies bitte in den Kommentaren kundtun. Dann kann ich das auch mal in einem Artikel entsprechend aufbereiten.

Was das ganze gebracht hat sind zwei weitere Punkte auf der Skala: 97 von 100. Der Rest liegt nicht mehr wirklich in meiner Macht, außer, ich würde Google Analytics, olark und die SSL-Logos rauswerfen.

Page 3 of 912345...Last »