JUnit 4.5

JUnit 4.5 wurde heute veröffentlicht. Es gibt keine Features auf der Liste, die uns sofort wechseln lassen, aber gut zu wissen ist es immer.

JUnit 4.5 focuses on features that make life easier for JUnit
extensions, including new public extension points for inserting
behavior into the standard JUnit 4 class runner.

UUID gefällig?

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.

(Wikipedia.com)

Nach dem Lasttest

Ein Blick in die Lasttest-Mailbox

Nach vielen Lasttests in den letzten Tagen habe ich mal in meine Spezialmailbox geschaut und war ja etwas überrascht, dass es doch schon so viele Emails waren, die in der Zeit eingetrudelt sind. Man stelle sich mal vor, das wäre alles als auf dem Server hängen geblieben bzw. mit Beschwerde an den Admin gegangen.

Wobei ein Test mit Unzustellbarkeit auch ein schönes Testszenario ist…

Captchas brechen durch pure Masse

Ich habe einen interessanten Artikel über das bezahlte Knacken von Catchas gelesen: Inside India’s CAPTCHA solving economy

Bisher wusste ich nicht mal, dass es sowas schon kommerziell gibt. Schon unheimlich, wie sich billige Arbeitskräfte nutzen lassen. Statt mit Rechenpower und Algorithmen löst man Probleme einfach durch pure Masse. Leider wird dadurch das ganze Sinn von Captchas gebrochen und man kann sich quasi nur noch durch ganz doofe Rätsel vor Spam schützen.

Ich wollte doch nur – ZF612707.CAB fehlt

Software kann einem soviel Zeit klauen. Da wollte ich doch nur mein Office 2003 mit dem 2007er-Format-Support ausstatten, weil mir Kunden unbedingt 2007er Files schicken müssen. Und dann das:

“Eine erforderliche Installationsdatei ZF612707.CAB konnte nicht gefunden werden. Die ursprüngliche Installationsquelle ist erforderlich.”

Also CD rein – glücklicherweise bin ich gerade im Büro und nicht unterwegs – und die Fehlermeldung bleibt, sie klebt wie Teer. Also die Allmacht Google gefragt und diese Antwort bekommen:

Bei einer Fehlermeldung – <siehe oben> – hilft nur Office komplett zu deinstallieren und danach neu zu installieren. Eine Office-Reparatur führt nicht zum Erfolg. Die Datei ZF612707.CAB gibt es nicht auf der Office-CD noch im MSOcache-Ordner. Microsoft hat dieses Problem noch nicht behoben.

Das sind die Momente, wo verstehen kann, warum Millionen von Nutzern tiefe Verzweifelung und epischen Hass gegen diese eine Software-Firma empfinden.

Und wieder sinnvoll nutzbare Zeit dem Softwaremonster in den Rachen geworfen. Übrigens habe ich mir die Sache geknickt. Ich schreibe dem Kunden einfach zurück, dass ich eine lesbare Version brauche.

Docbook – der Beginn einer Liebe?

Wenn man Dokumentation schreiben muss, dann überlegt man sich zweimal, welches Format man nimmt. Na klar, am Ende ist es wohl fast immer ein PDF, aber ein PDF schreibt man nicht direkt.

MS Word? Hoher Frustrationsfaktor und man kann schlecht gemeinsam daran arbeiten, vor allem im Sinne einer Versionsverwaltung. Vom Ausschluss der Linux-Fans mal ganz schweigen.

OpenOffice? Schon besser, aber das mit der gemeinsamen Arbeit und der Versionverwaltung ist da noch nicht so perfekt, zudem quälen sich viele Leute mit Layoutfragen und weniger mit dem Inhalt. Das ist aber kein OO-Problem, sondern ein Verständnisproblem der Arbeit mit strukturierten Dokumenten. Ein visuelles Tool verführt einfach dazu, nicht über Struktur nachzudenken, sondern sich im Design zu verlieren.

LaTeX? TeX ist cool und produziert super Dokumente, wenn man es denn mal im Griff hat und eine gute Vorlage mit Paragrafen und Absätzen, die ausgezeichnet sind, sein eigen nennt. Pure LaTEX hilft nicht viel, weil alle wieder zum manuellen Formatieren neigen… auch wenn das Ergebnis super aussieht. Dafür lassen sich aber Dokumente sehr einfach gemeinsam schreiben und in einer Versionsverwaltung gut hinterlegen und pflegen.

Wenn man den Markt eine Weile studiert, dann findet man DocBook, quasi die konsequente Weiterführung der TeX-Idee mit den Mitteln von XML und XSL. Viele Linux-Projekte schreiben bereits ihre Dokumentation in DocBook.

Leider gibt es kaum vernünftige Editoren am Markt, die das Schreiben unterstützen und gleichzeitig etwas Luxus bieten, um zum Beispiel die Rechtschreibung zu prüfen. Ich als Programmierer mag auf jeden Fall schon mal das Format, die Klarheit und die Möglichkeiten, die sich durch XML/XSL ergeben. Gleichzeitig läuft die Sache auf allen Plattformen, da die Tools zur Produktion des finalen PDF in Java geschrieben sind.

Bin gespannt, ob DocBook eine große Liebe wird oder eine herbe Enttäuschung.

P.S. Nicht zu vergessen, dass O’Reilly DocBook als offizielles Anlieferungsformat für Bücher auserkoren hat. Ich wollte schon immer mal ein Buch schreiben.

Lasttest-Mailbox

Bild meiner Lasttest-Mailbox

Heute habe ich meine Lasttest-Mailbox aufgeräumt, denn es stauten sich mehr als 5000 Test-E-Mails. Aber was ist eine Lasttest-Mailbox?

Für die meisten Testszenarien im E-Commerce-Bereich benötigt man E-Mail-Adressen, weil oft Nutzer über die E-Mail identifiziert, Bestellbestätigungen oder schlicht Passwort-Erinnerungen verschickt werden. Für einige Fälle ist es ausreichend, erdachte Adressen zu verwenden, die nur dem allgemeinen Format einer E-Mail-Adresse (name@server.domain) genügen müssen.

Sobald aber das System unter Test wirklich diese Adressen nutzt und E-Mails verschickt, muss man auf gültige Daten achten, weil sonst das System unter der Flut von Rückläufen zu leiden beginnt und/oder man von den Administratoren eine Verwarnung kassiert.

Die beste Idee wären natürlich jede Menge Postfächer bei Google, aber wenn man 10000 Nutzer mit individuellen E-Mails braucht, dann kann und darf man bei Google keinen Pool anlegen. Allein die Unterscheidung, ob man beim bereits eine E-Mail im Test verwendet hat oder nicht, ist sehr schwer. Zusätzlich ist die Pflege von Testdatensätzen im Allgemeinen sehr zeitintensiv und fehleranfällig.

Wie soll es aber dann gehen?

Bewährt haben sich Catch-All Mailboxen beim eigenen E-Mailprovider oder auch Mailboxen auf virtuellen Servern. Hier kann man eine Domain und eine Mailbox konfigurieren und dann durch das Catch-All unendlich viele E-Mail-Adressen nutzen, die man einfach zufällig erzeugt.

Unter Java 6 ist diese Zeile Code sehr nützlich. Sie erzeugt recht zufällige E-Mail-Adressen mit einer Länge von 15 Zeichen für den Namen. Da die JDK 6 UUID-Klasse genutzt wird, ist eine ausreichende Eindeutigkeit garantiert. Nun gut, eigentlich darf man dann den String nicht einkürzen, aber die meisten Dienste können lange E-Mail-Adressen nicht leiden und so muss man sich beschränken.

Selbstverständlich muss die Domain yourdomainname54678765.net existieren, einem selbst gehören(!) und das Catch-All der Mailbox dafür korrekt konfiguriert sein.

P.S. Für den Test eines großen E-Mail Dienstes würde ich aber nicht darauf zurückgreifen, weil man zwar viele Mails erzeugen und versenden kann, aber diese Lösung nur für einen moderaten Verkehr ausgelegt ist. Schließlich gehen alle E-Mails den gleichen Weg und nisten sich im selben Briefkasten ein.

Für einen großen Test würde ich wohl eine Serverfarm bei Amazon-EC2 konfigurieren oder 20 virtuelle Server bei verschiedenen Hostern einkaufen.