Ab heute hat Xceptance LoadTest – XLT sein eigenes Logo, um die Wiedererkennbarkeit unseres Last- und Regressionstest-Tools zu erhöhen. Gleichzeitig schaffen wir uns damit mehr Gestaltungsmöglichkeiten für Prospekte, unsere Webseite und natürlich auch für die Reports von XLT.

Bei der Erstellung und der Auswahl eines passenden Designs hat uns die Plattform 99Designs geholfen. Mit 99Designs lassen sich Design-Wettbewerbe schnell und effizient organisieren und man bekommt Vorschläge aus der ganzen Welt eingereicht. Wir waren sehr zufrieden mit dem Service und der Abwicklung. Unsere Designer war sehr freundlich, hilfsbereit und haben auch noch zusätzliche Ideen  umgesetzt, um uns die Entscheidung zu erleichtern. Nochmal vielen Dank an alle!

Wenn man die Epoch-Daten (Sekunden seit 1970) in ein vernünftiges Format bekommen muss, dann hilft der Epochconverter bestimmt.

Für das Sun JDK deutet sich ein neuer Garbage Collector an, der ein anderes Herangehen hat und damit lange  Pausen noch deutlicher als der CMS vermeiden soll. Dem geneigten Leser sei dieser Artikel empfohlen: The Garbage First Collector!

Im JDK 6v14 könnten wir ihn vielleicht sehen. Ich bin schon ganz aufgeregt, da ich mittlerweile oft und viel mit GC-Internas hantiere… keine Wunder bei Lasttests gegen 120 CPUs mit Java drauf.

Heute gibt es einen Link über Cross-Site-Scripting (XSS), was es ist, was man dagegen tun kann oder kurz: Wie beugt man XSS vor?

Der Artikel stammt vom OWASP, der Authoriät im Sachen Internetsicherheit bzw. Informationen zur Sicherheit.

This article provides a simple positive model for preventing XSS using output escaping/encoding properly. While there are a huge number of XSS attack vectors, following a few simple rules can completely defend against this serious attack.

These rules apply to all the different varieties of XSS. Both reflected and stored XSS can be addressed by performing the appropriate escaping on the server-side. The use of an escaping/encoding library like the one in ESAPI is strongly recommended as there are many special cases. DOM Based XSS can be addressed by applying these rules on the client on untrusted data.

For a great cheatsheet on the attack vectors related to XSS, please refer to the excellent XSS Cheat Sheet by RSnake. More background on browser security and the various browsers can be found in the Browser Security Handbook.

Quelle: OWASP unter CC-BY-SA-3.0

Wer User-Agenten kennen muss oder User-Agenten zum Testen braucht, der ist auf user-agent.org super aufgehoben.

Wer den W3C-Validator benutzt, der kann jetzt seine Dankbarkeit mit einer Spende zum Ausbau des Dienstes zum Ausdruck bringen. Mehr als fair finde ich.

Wer schon immer mal wissen wollte, ob seine Passwörter ansatzweise sicher sind, der sollte das The Password Meter ausprobieren. Das Ding ist wirklich pingelig. Was andere Prüfwerkzeuge als stark und superstark bewertet haben, das fällt bei The Password Meter unter: 0% – Vergiss es Dude!

Die Anwendung steht unter GPL und kann runtergeladen werden. Das gute Stück ist 100%-Javascript und die Eingaben werden nicht übertragen. Man sollte aber trotzdem nicht seine echten Passwörter eingeben, sondern ähnliche Muster. Also statt Helga78 tut es ein Katja87

Das Ganze ist kein Informatiker-Geek-Spiel sondern wirklich ernst. Viele 0815-Internetnutzer haben solche weichen Passwörter, dass es ein Wunder ist, dass sie noch nicht ausgeplündert wurden.

Es gibt einen neuen Browser Lunascape. Der besondere Gag ist, dass man die Rendering-Engine wechseln kann. Er kann also als Internet Explorer, Firefox und Safari durchs Web browsen. Das könnte das Testen von Webapplikationen vereinfachen.

Wenn man über Webseiten-Performance spricht, dann denken die Meisten sofort an die Leistung des Servers bei der Auslieferung der Inhalte. Das ist im Prinzip auch nicht falsch, aber nur die halbe Wahrheit. Natürlich kann man eine Seite nicht schneller anzeigen, als sie ausgeliefert wird, so dass eine gute Leistung des Servers Grundvoraussetzung ist, aber es geht halt ohne grosse Anstrengungen langsamer.

Wie? Langsamer?

Moderne Webseiten bestehen aus vier Hauptkomponenten: Html, CSS, Javascript und statischen Inhalten, wie zum Beispiel Bildern und Flash. Die endgültige Webseite kommt nur im Browser zu Stande, wenn alle diese Einzelteile zusammengefügt wurden. Diese finale Schritt wird als Rendern bezeichnet.

Jede Einzelkomponente muss über das Netz geladen werden und die Komponenten werden in einer gewissen Reihenfolge geladen. So ist zum Beispiel immer zuerst die HTML-Hauptseite dran, dann Frames, dann CSS und Javascript aus dem Header, dann Bilder, dann anderer Content und irgendwo mittendrin wird noch das Javascript ausgeführt (denn Laden und Ausführen sind nicht das Gleiche). Um es kompliziert zu machen, macht es jeder Browser etwas anders.

Sollte ein Teil klemmen bzw. langsam sein, so können oder werden nachfolgende Teile nicht geladen und die Seite nicht bzw. unvollständig angezeigt. Oft fällt das beim Spiegel-Online, Welt-Online oder ähnlichen Angeboten auf, denn dort sieht man oft nur den Header und dann kommt einen Moment nichts… oder mehrere Momente nichts und endlich macht es Pling.

Da ich hier nicht alle Teile aus dem Yahoo-Performance-Guide kopieren möchte, wie man das Pling vermeiden kann und wie alles viel schneller geht, hier noch etwas erklärende Theorie für das Grundverständnis. Hier meine Favoriten und die bildliche Erklärung. Zuerst sei noch ein Missverständnis erklärt.

Meine Kunden haben doch Breitband, wo ist das Problem?

Breitband ist schön, Breitband ist toll, aber ein LKW mit Ladung ist auf einer 10-spurigen Autobahn nur unwesentlich schneller als auf den traditionellen zwei Spuren. Warum? Wenn ich Ware nach von A nach B bringe, dann muss ich den LKW be- und entladen, sowie der LKW muss auf die Autobahn auf- und abfahren. Egal wie breit die Autobahn dazwischen ist, diese Grundschritte sind immer dabei und immer gleich schnell. Eventuell haben wir nur weniger Stau unterwegs bzw. ich kann vier LKWs schicken, statt einem… sofern ich etwas zu transportieren habe und sich die LKWs nicht am Verladezentrum stauen.

Genauso verhält es sich mit Anfragen an einen Webserver. Das Datenpaket wird gepackt, versendet und ausgepackt, danach beantwortet, die Anfrage eingepackt, versandt und wieder ausgepackt. Nur die beiden Versandschritte gehen schneller mit einer dicken Leitung, der Rest bleibt.

Und wo ist nun das Problem?

Ja, ich habe es immer noch nicht richtig verraten, aber das Problem der meisten Webseiten ist, dass sie aus vielen vielen Einzelteilen zusammengesetzt werden und je mehr Teile es sind und je mehr Teile von unterschiedlichen Servern stammen, desto langsamer wird die Sache.

Das führt zum lustigen Effekt, dass das Laden von 5 Bildern a 50kB schneller geht, als das Laden von 10 Bildern a 15kB, obwohl die Gesamtgrösse der 10 Bilder deutlich geringer ist. Leider führen 10 Bilder zum Zweifachen Overhead im HTTP-Protokoll, in der DNS-Auflösung, in der Bestimmung der Serverantwort und und und.

Regel Nummer 1 heisst deswegen – Weniger HTTP-Anfragen

Diese Regel ist die absolut goldene Regel und lässt sich durch das Zusammenlegen von Einzel-CSS in ein CSS-File erreichen, durch das Zusammenführen von Javascript-Dateien und statt den Seiten-Header in 8 Bilder zu zerlegen, schickt man lieber nur 2 Bilder.

Man darf dabei auch nicht aus den Augen verlieren, dass diese Inhalte auch gecacht werden sollten, damit der Browser beim Weiterklicken nicht nochmal alles von vorn alles laden muss. Hier ist also zwischen Zerlegung, Grösse, und Wiederverwendung abzuwägen.

Regel 8 – Javascript und CSS gehören in Einzeldateien

Man sollte niemals CSS und Javascript in grossen Mengen in das HTML einbetten. Dieser Teile gehören extern und so aufbereitet, dass sie wiederverwendbar sind. Das macht die Pflege einfacher und die eigentlichen HTML-Seiten kleiner.

Regel 19 – Die Anzahl der DOM-Elemente reduzieren

Was der Browser nicht lesen muss, dass kostet keine Zeit und keinen Speicher. Jedes HTML-Element und vor allem jede Zeile Javascript-Code muss interpretiert und verwaltet werden. Damit ist eigentlich schon einleuchtend, dass der HTML-Code sauber und einfach strukturiert sein sollte.

Als Beispiel lässt sich bei

<div class="link"><span><a href="http://...">Linktext</a></span></div>

locker das span einsparen, denn a ist bereits ein Inline-Element und span fügt hier keine Struktur hinzu. Das ist aus der Praxis, das habe ich mir nicht gerade ausgedacht.

So, dass war eigentlich schon recht viel für den Anfang und deswegen gibt es demnächst mehr zu den anderen Tipps von Yahoo. Wer es eilig hat, der kann auch direkt nachlesen: Best Practices for Speeding Up Your Web Site.

Photo by 96dpi under CC-BY-2.0

Wenn jemand mal Bedarf an UUIDs hat und gerade keinen Generator zur Hand hat bzw. etwas mehr über das Thema wissen will, dann ist www.uuidgenerator.com ein Anlaufpunkt, um sich zumindest einiger UUIDs zu bemächtigen.

A Universally Unique Identifier is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination.

Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labelled with UUIDs can therefore be later combined into a single database without needing to resolve name conflicts.