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.

Redmine – schnell begeistert

Eigentlich bin ich ja schwer von neuen Sachen zu begeistern, erst recht wenn es sich um Bugtracker handelt. Aber wie immer sucht man einen Tracker und ein Projekttool und und und…. Diesmal haben wir Redmine gefunden und was soll ich sagen, ich bin nach 25 Clicks begeistert.

Redmine is a flexible project management web application. Written using Ruby on Rails framework, it is cross-platform and cross-database.

Redmine is open source and released under the terms of the GNU General Public License v2 (GPL).

Eine aufgeräumte Oberfläche und gut miteinander integrierte Features. Was will man mehr? Besonders schön sind die Rollen und der Multi-Projekt-Support und wie beides zusammenspielt.

Wir haben es jetzt bei uns im Probebetrieb und werden uns wohl dauerhaft damit wohlfühlen. Alle Anwender von Xceptance Load Test (XLT) können sich damit jetzt schon auf ein umfangreiches Projektsystem freuen, das Bugtracking, Wiki, Dokumentation, Forum, Roadmap und vieles mehr bietet.