All posts by Rene

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.

catch(IE){}

Entwickler besitzen einen gewissen befremdlichen Grundhumor, aber verstehen kann man sie durchaus. Den folgenden Code hab ich beim Debugging des Dojo-Sourcecodes gefunden:

Der Browser-Krieg und seine Nachwirkungen

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.

Whitespaces und XPath

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:

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:

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 :)

XLT – Start-and-Go Feature

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.