Because I do not know what is the current state of the Java G1 Garbage Collector, I decided to try G1 with JDK6u20. Somehow I was disappointed because after a short moment of predictable GC performance, the entire VM stopped and some major collection was running. You can easily see that in the charts of that run. Right around 20:09:45, the threads were stopped and the entire VM behaved ugly.

So, the G1 is not yet ready for production, of course nobody stated that it is ready for production. If I read the release notes of JDK6u21 correctly, it delivers plenty of G1 changes, so I might try that soon.

I got a pretty nice link today. Check out that short article about the usual obstacles when trying or applying test automation: Why Test Automation Costs Too Much. Elisabeth covers the aspects of disconnected teams and the often practiced sharp distinction between programmers and testers pretty well.

Bottom line: the reason test automation costs so much is that it’s done in a silo far removed from the development effort.

Buffered from the consequences of design decisions that decrease testability, the developers continue to create software that’s nigh onto impossible to automate.

And isolated from the technical expertise of how the software was constructed, the test automation specialists are in a situation where they cannot help but be both inefficient and ineffective.

Enjoy reading!

Nati Shalom discusses in one of his latest blog entries the changes Google made to its page ranking algorithm and how it influences your Google page ranking.

Last month Google added Website speed to its site ranking algorithm: It’s Official: Google Now Counts Site Speed As A Ranking Factor… The rationale behind this move by Google is fairly straightforward:

Slow web sites lead to a poor user experience, and therefore should not appear at the top of the search list even if they contain relevant content.

This emphasizes once more the influence of performance on your daily business. A simple change to your site can now affect your entire page ranking and how users find your content. Continuous performance testing is now even more important than ever.

Just read about a nice small software problem at Opera. Their latest browser is version 10, but they couldn’t continue to use the version number in the user agent string, because some web sites try to identify the agent version and fail with 2 digit version numbers. Seems to be similar to the famous Y2K problem, but now it is a BVN problem – a browser version number problem.

“…It appears that a considerable amount of browser sniffing scripts are not quite ready for this change to double digits, as they detect only the first digit of the user agent string: in such a scenario, Opera 10 is interpreted as Opera 1. This results in sites mistakenly identifying Opera 10 as an unsupported browser, thereby breaking server, as well as client-side scripts…”

Read more at Dev.Opera.

If you want to stay in touch with cutting-edge technology in terms of scalability of databases, high traffic sites, and large storage volumes, you should read these two articles on the new hstack.org blog.

Cosmin Lehene wrote two excellent articles on Adobe’s experiences with HBase: Why we’re using HBase: Part 1 and Why we’re using HBase: Part 2. Adobe needed a generic, real-time, structured data storage and processing system that could handle any data volume, with access times under 50ms, with no downtime and no data loss. The article goes into great detail about their experiences with HBase and their evaluation process, providing a “well reasoned impartial use case from a commercial user”. It talks about failure handling, availability, write performance, read performance, random reads, sequential scans, and consistency.

(via High Scalability)

Last week, we released a small update of Xceptance LoadTest – version 3.3.2. It mainly adds support for Firefox 3.6 to the XLT script recorder..

Customers of XLT can access all information regarding this release at the Xceptance Information Center. This release is also publicly available for download.

As you might have noticed, the blog language has changed. All upcoming posts are going to be in English to reach a broader audience. Old articles and tags remain in German. As soon as Wordpress 3.0 comes out and offers its promised multi-language, we might split this blog and run it bi-lingual.

Thank you for your cooperation!

Just to quote the famous sentence again.

Heute mal wieder etwas aus der Reihe “Erfolgreiche Fehler” oder “Unsinnige Dialoge”. Gefunden im Nautilus von Ubuntu 9.10.

In den letzten Tagen kommen wir immer wieder an die Stelle, wo wir uns fragen, ob ein Blog in Englisch nicht Sinn machen würde. Allerdings sollte man den Aufwand zur Pflege von zwei Blogs in zwei Sprachen nicht unterschätzen.

Deswegen die folgenden Fragen an unsere Leser:

• Brauchen wir zwei Sprachen oder würde ein rein englisches Blog genügen?
• Ist ein deutschsprachiges Blog gewünscht oder spricht die IT-Welt nicht ohnehin meist Englisch?
• Würde ein gemischtsprachiges Blog funktionieren?

Wir freuen uns über alle Meinungen.

Mike Kus hat einen kurzen Artikel geschrieben, warum Webdesigner unbedingt coden können sollten. Gerade aus Sicht von QA kann ich ihm nur zustimmen.

Via T3N