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.
Vom Eclipse-Projekt gibt es jetzt auch einen Memory-Analyzer. Ich probiere das Ding gleich mal aus. Es soll grosse Hprof-Dumps effizient analysieren können. Das wäre genau richtig, schliesslich quälen wir uns oft mit 1-2 GB Files rum.
Es gibt selten Tools von Microsoft, die mich vom Hocker reissen. Gut, die ganzen Teile von SysInternals sind Klasse, aber schliesslich hat MS diese Firma auch aufgekauft. Richtig gut ist aber auch Fiddler, ein Proxy mit richtig viel Schnickschnack.
Fiddler macht das Leben eines jeden Testers oder Webentwicklers viel einfacher. Wer es nicht glaubt – Ausprobieren!
Viele Java-Programmiere denken oft beim Schreiben Ihres Codes wenig über Müll nach. Natürlich nimmt man zum Bauen eines Strings aus vielen kleinen Puzzleteilen einen StringBuilder. Den StringBuffer nimmt man nicht mehr, weil der im Regelfall unnötig synchronisiert ist. Schliesslich löst das im Java Memory Model ab JDK 5 eine Synchronisation mit dem Hauptspeicher aus (JSR-133), die wir überhaupt nicht wollen.
Einen kleinen Trick für unnötige Objekt-Erzeugung und damit für weniger Müll im System, gerade wenn immer wieder Strings gebaut werden müssen, ist die korrekte initiale Größe des StringBuilders. Ein new StringBuilder() reserviert zunächst nur ein Array mit 16 Characters. Wenn wir also recht viel zusammenbauen, muss mehrmals eine neues grösseres Array (2 * ggw. Grösse + 1) erzeugt und der Inhalt umkopiert werden.
Wer also weiss, dass er ca. 100 Zeichen aneinanderhängt, der lässt sich gleich einen StringBuilder mit Grösse 120 geben – new StringBuilder(120) – und spart damit das Anlegen von drei Arrays und drei Copy-Operation ein. Gerade bei intensiven Operationen mit Strings macht das eine Menge aus.
Wer würde schon bei einem Umzug zuerst mit dem kleinsten Karton anfangen und dann wegwerfen, weil nicht alles reinpasst? Man schätzt doch am Anfang schon vernünftig ab, wie groß der Karton sein sollte.
Heute habe ich eine wunderbare Webseite zum Thema Java Concurrency gefunden. Jakob Jenkov hat hier viele interessante Themen zur parallelen Programmierung mit Java zusammengefasst. Ein Bookmark wert und in einer ruhigen Minute unbedingt mal lesen.
Java was one of the first languages to make multithreading easily available to developers. Java had multithreading capabilities from the very beginning. Therefore, Java developers often face the problems described above. That is the reason I am writing this trail on Java concurrency. As notes to myself, and any fellow Java developer whom may benefit from it.
Wer gern mal wissen möchte, wie moderne grosse Webseiten laufen, der kann sich hier die LinkedIn-Architecture anschauen und durchlesen. Und wieder ist Lucene die Search-Engine der Wahl. Interessant ist der LinkedIn-Network-Graph, der in Memory gehalten wird… 12 GB RAM.
Einzig die Behauptung
Garbage Collection pauses were killing them. [LinkedIn said they were using advanced GC’s, but GC’s have improved since 2003; is this still a problem today?]
kann ich nicht glauben. Deswegen wurde die Graph-Engine in C geschrieben. Ich denke mal, da war komplett etwas falsch, wenn der GC austickt.