Entwickler besitzen einen gewissen befremdlichen Grundhumor, aber verstehen kann man sie durchaus. Den folgenden Code hab ich beim Debugging des Dojo-Sourcecodes gefunden:
|
1 2 3 4 5 6 7 |
}catch(e){ dojo.debug("dojo.widget.Parse: error:" + e); // note, commenting out the next line is breaking several // widgets for me // throw e; // <strong>IE is such a bitch sometimes</strong> } |
Ich bin fest der Überzeugung, dass wir jährlich Millionen, wenn nicht Milliarden Euro sparen könnten, wenn die Webbrowser nur korrekten Code akzeptieren würden und nicht in einen Ratemodus verfallen, wenn irgendwas im HTML nicht stimmt. Dieses Erbe aus den Zeiten der Browser-Kriege kann einen total in den Wahnsinn treiben, vor allem weil viele Leute nicht wissen, wie man mit (X)HTML und CSS korrekt arbeitet. Oft es aber damit begründen, dass der Browser es ja auch nicht korrekt macht… Henne und Ei sage ich nur!
Es ist unglaublich, was einem als Tester bzw. Performance Tester für Code vorgesetzt wird. Nicht nur, dass oft Tools und Browser unterschiedlicher Meinung sind, wenn es um die Interpretation von HTML geht, nein, auch der Code selbst ist grottenschlecht und stellt eine Wartungshölle dar.
Wenn man den Code zurückgehen lässt oder auf Fehlerbehebung drängt, dann kommt meist zurück: “Geht doch im Browser, was wollt Ihr denn?” Als Tester kann man da wahnsinnig werden. Erst recht, wenn man selbst weiss, wie man XHTML und CSS fehlerfrei schreiben kann und welchen Gewinn man dadurch erzielt.
Machmal kann es nützlich sein, bei der Arbeit mit XPath-Ausdrücken in HtmlUnit respektive XLT, Werte von HTML-Elementen direkt in der XPath-Expression zu vergleichen. Wenn aber jede Menge Whitespaces vorkommen, und bei automatisch generiertem HTML-Code ist es leider meist so, dann scheitert der Vergleich:
|
1 |
div[@class='stockstate' and . = 'unavailable'] |
Ein Hilfe ist hier die XPath-Funktion normalize-space(), die unnötige Whitespaces nach den Regel von XML reduziert. Also in der Regel doppelte Spaces, Spaces zwischen <> und dem Text, sowie Zeilenumbrüche entfernt. Damit sieht unser XPath-Ausdruck dann so aus:
|
1 |
div[@class='stockstate' and normalize-space(.) = 'unavailable'] |
P.S. Günstig wäre natürlich, wenn man diese unnützen Daten erst gar nicht transportieren würde. Ich möchte nicht wissen, was täglich an sinnlosen Whitespaces durch das Netz geschickt wird :)
Ich muss mich heute einfach mal über das Start-And-Go Feature von Xceptance Load Test (XLT) freuen. Früh im Hotel habe ich mich zum Cloud Service verbunden, den Lasttest hochgeladen und gestartet. Danach habe ich das Notebook abgeklemmt und bin Frühstücken gegangen.
Eine Stunde später sass ich im Büro, habe mein Notebook hochgefahren und mich wieder zur Cloud verbunden. Teststatus abgerufen und da der Test durch war, einfach die Ergebnisse runtergeladen.
Es ist echt praktisch, wenn man nicht ortsgebunden für einen Test ist und das Tool einen nicht zwingt, ständig mit den Testmaschinen verbunden zu sein. So machen auch die üblichen Netzunterbrechungen im Hotel oder via UMTS keine Probleme mehr.
Hatte ich schon erwähnt, dass ich beim letzten Mal vom Flughafen, ca. 30 min vor dem Boarding noch mehrere Lasttests laufen hatte? Auch sehr praktisch, dass XLT mit einer Shell auskommt und man den Controller ohne Probleme auf eine Drittmaschine verlagern kann, die man dann via Shell steuert.
Bei der heutigen Sicherheitslage in Rechenzentren bekommt man meist ja nur einen SSH-Zugang mit eigenem Schlüssel und sonst nichts. Aber genau dafür ist XLT gemacht. Mit wenig Ressourcen, viel zu erreichen.
Extrem coole Icons und Minibilder für seine tägliche Arbeit, teilweise frei oder unter Creative Commons Lizenzen kann man hier finden: 55 Free High Quality Icon Sets.
Das nebenstehende Beispiel stammt von Blog Perfume.