Die kommende Version von XLT (3.3) wird ein schönes neues Feature mitbringen: Die Möglichkeit des Vergleichs von Lasttest-Ergebnissen und die dazu gehörige Visualisierung. Hier nur ein kleiner Ausschnitt aus einem Report. So oder so ähnlich wird es dann aussehen.

Wie gewohnt, wird auch der Vergleich von Lasttest-Ergebnissen nur mit offenen Datenformaten arbeiten. Außerdem wird der Vergleich basierend auf den bereits existierenden Reports erstellt. Damit kann man schnell und einfach zwei Reports vergleichen und sich ein Bild von den Fortschritten oder aktuellen Problemen machen.

Alle Kunden, die bereits XLT einsetzen, sind herzlich zu einem Vorabtest der Entwicklungsversion 3.3 eingeladen.

Nächste Woche wollen wir XLT 3.2 releasen. Ich freue mich drauf, denn es ist wirklich gut geworden. Wir haben viele Dinge umgesetzt, die die Arbeit mit XLT schneller, effizienter und interessanter machen. Nichts davon ist praxisfern entstanden, sondern alle Verbesserungen und neuen Features sind aus der Arbeit mit XLT entstanden.

Mehr demnächst hier.

Wir hatten heute eine kurze Diskussion über Singletons und die Art und Weise ihrer Erzeugung, speziell wenn man sie faul (lazy) erzeugen möchte. Die Wikipedia hat dazu diesen schönen Eintrag – On Demand Holder Idiom:

In software engineering, the Initialization on Demand Holder idiom (design pattern) is a lazy-loaded singleton. The idiom can be implemented in both single-threaded/serial and concurrent environments, but care must be taken to correctly implement the idiom under concurrent conditions.

Ganz besondern wichtig ist die Erklärung, warum Lazy in diesem Fall so und nicht anders funktioniert:

The implementation relies on the well-specified initialization phase of execution within the Java Virtual Machine (JVM); see section 12.4 of Java Language Specification (JLS) for details.

When the class Something is loaded by the JVM, the class goes through initialization. Since the class does not have any static variables to initialize, the initialization completes trivially. The static class definition LazyHolder within it is not initialized until the JVM determines that LazyHolder must be executed. The static class LazyHolder is only executed when the static method getInstance is invoked on the class Something, and the first time this happens the JVM will load and initialize the LazyHolder class.

Wenn man in einer Webseite diesen Text findet und weiss, dass eine angeblich professionelle Webagentur/Webdesign-Firma ihre Hände im Spiel hatte, dann sollte man sich fragen, ob es die richtigen Leute für den Job sind… oder nicht?

<!--
Since margins/padding looked different in diff browsers, use a
transparent image to get spacing above and below actual footer...
-->

Heute habe ich sichtlich verwirrt geschaut und gesucht, wie ich beim Spiegel mir eine Online-Ausgabe kaufen kann, denn im Bestellprozess steht plötzlich Abrechnen auf einem Button.

Abrechnen habe ich noch nie gelesen. Meist steht nur Weiter, Kaufen oder Bestellen drauf. Das Problem ist, dass man auf den ersten Blick nämlich Abbrechen liest.

Da fällt mir das schöne Kunstwort Abbrechnen ein…

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

Mich erstaunen die Talente vieler Leute immer wieder. Jemand hat ein Script geschrieben, das Captchas automatisch löst und das ganze in JavaScript. Das Ding läuft auch noch im Browser… wow! Nun gut, es löst nicht alle Captchas… aber immerhin.

Wenn es interessiert, hier geht es zum Artikel: Captcha cracking in JavaScript with Canvas and neural nets

Wer sich einen virtuellen Server gemietet hat und sich quält, Java vernünftig zum Laufen zu bringen, dem sei dieser Artikel ans Herz gelegt: Java Web Hosting HowTo – vServer memory and Java heap size trouble.

Java Virtual Machines and Linux virtual Servers do not play well with each other all the time. Some tweaking and configuration will be necessary to get it working and optimize the use of the (memory) resources.

Die VPS / Virtuellen Server haben leider die Angewohnheit, den Speicher als zu gross zu melden. Sie melden den Gesamtspeicher des Hosts und nicht den Speicher des Virtuellen Servers. Deswegen schlägt Java gnadenlos zu, und versucht sich reinzuoptimieren. Die einzige Lösung ist die Limitierung des Speichers schon beim Start von Java mit -Xms und -Xmx, um die Selbstoptimierung von Java zu umgehen.

Softreferenzen (soft references) in Java sind eine tolle Sache, denn es lassen sich tolle Caches und Notfallszenarien damit bauen. Was kaum jemand weiß, dass Softreferenzen nicht nur im Falle von akuter Speicherknappheit freigegeben werden, sondern durchaus auch früher. Letzteres kann zu unerwarteten Nebenwirkungen führen, speziell mit Blick auf Caching.

Soft references are kept alive longer in the server virtual machine than in the client. The rate of clearing can be controlled with the command line option -XX:SoftRefLRUPolicyMSPerMB=<N>, which specifies the number of milliseconds a soft reference will be kept alive (once it is no longer strongly reachable) for each megabyte of free space in the heap.

The default value is 1000 ms per megabyte, which means that a soft reference will survive (after the last strong reference to the object has been collected) for 1 second for each megabyte of free space in the heap. Note that this is an approximate figure since soft references are cleared only during garbage collection, which may occur sporadically.

Quelle: JDK 6 Garbage Collection Tuning Guide

Nachtrag: Erwähnenswert ist auch dieser Blogeintrag von Jeremy Manson.

Heute habe ich einen interessanten Ansatz für eine Verbesserung von JUnit gefunden – TestedBy.

In a nutshell TestedBy aims to change the point of view regarding test classes and classes under test. What we would obtain is to put class under test (the most important classes of your projects) on the centre and link from there your test class and test method.

Ist einen Blick wert, da es scheinbar erstmal das Management der Tests verbessert.