Softwaretests sind wichtig, das sieht jeder ein. Dennoch wird in vielen Unternehmen das Thema eher stiefmütterlich behandelt, oft auch, weil die notwendigen Ressourcen fehlen, oder das Fachwissen nicht ausreichend vorhanden ist.

Hier kann ich Abhilfe schaffen, indem ich als externer Tester für Sie zur Verfügung stehe. Dabei kann ich den kompletten Softwarelebenszyklus von der Spezifikation über die Implementierung bis hin zum Abnahmetest beim Endkunden begleiten und mit Rat und Tat zur Seite stehen; seit heute auch als zertifizierter Tester nach den Richtlinien des ISTQB, dem International Software Testing Qualifications Board.

Fragen Sie einfach unverbindlich an, wir finden eine Lösung, die Ihre Bedürfnisse abdecken kann.

Fehlerberichte oder Bug-Reports sind für viele ein Mysterium. Der Anwender macht sich die Mühe und schreibt eine Info an den Entwickler und wundert sich, warum nichts passiert, oder er nur Rückfragen bekommt. Der Entwickler wiederum erhält einen Fehlerbericht und versteht nicht, wo das Problem liegt und lässt es somit liegen. Vielen nicht-Programmierern ist einfach nicht klar, woraus ein Fehlerbericht bestehen muss, damit er schnell und zuverlässig bearbeitet werden kann.
Da ich dies in fast jedem Projekt einmal ansprechen muss, hier einmal die schriftliche Fassung zum Nachschlagen. Das Konzept greift für jede Programmiersprache, jedes Programm, praktisch jedes Softwareprojekt. Es ist egal, mit welchem Tool die Reports eingereicht werden (es kann auch eine einfache Email sein), die Grundbausteine sind immer gleich.

Die Basics

Wenn man dem Entwickler wirklich helfen will (und damit die Chancen drastisch erhöht, dass das Problem schnell bearbeitet wird), dann versucht man es erneut und merkt sich ganz genau die Schritte. Perfekt ist, wenn man Fehlermeldungen einfach durch einen Screenshot abfotografiert, dann geht keine Information verloren und der Entwickler sieht den Kontext. Dann kann man seinen Fehlerfall formulieren:

Ein aussagekräftiger Betreff

Der Problemempfänger wird zuerst nur den Betreff sehen und man kann davon ausgehen, dass schon danach gefiltert wird. Erfahrungsgemäß wird zuerst das bearbeitet, was man schnell versteht. Daher schon im Betreff darauf achten, dass

1) Das Fehlverhalten beschrieben wird und

2) Zeitpunkt und Ort des Auftretens erwähnt wird.

Schlecht: “Problem”

Gut: “Login zu Anwendung X funktioniert Montags nicht”

Zeitpunkt und User

Eine Information, die immer angegeben werden sollte, ist der Zeitpunkt (Datum + Uhrzeit) des Problems sowie der Anwender, bei dem es auftritt. Vielleicht läuft zur gegebenen Uhrzeit ein Backup und daher ist die Anwendung langsam, oder bestimmte Anwender haben andere Berechtigungen und sehen daher einige Eingabefelder nicht.

Eine Schritt-für-Schritt-Beschreibung

Ein Entwickler ist kein Anwender, weiß nicht, wie der Nutzer das Programm bedient und kann nicht raten, wie es zu einem Fehler kam. Daher immer darauf achten, dass der Kontext mitgegeben wird. Dies geschieht am einfachsten durch einen Schritt-für-Schritt-Beschreibung. Weiterhin kann man auf diese Art sehr gut prüfen, ob der Fehler immer auftritt, oder nur sporadisch.

Schlecht: “Ich bekomme manchmal bei der Anmeldung eine Fehlermeldung”

Gut: “Wenn man sich Montags in Anwendung X anmelden will, erscheint die Fehlermeldung blablabla. Ich habe User + Passwort in die korrekten Felder eingetragen und auf ‘login’ geklickt. An anderen Wochentagen klappt es.

Screenshots

Wenn man die Möglichkeit hat, vom Fehlerzustand einen Screenshot anzufertigen, dann sollte man dies tun. Dabei sollte man beachten, dass man möglichst den kompletten Bildschirm abfotografiert und keine Auswahl trifft. Vielleicht sieht der Entwickler im Hintergrund noch etwas wichtiges, das man selbst nicht beachtet hat. Auf jeden Fall aber hilft ein kompletter Screenshot bei der Einordnung im Kontext und der Entwickler muss nicht suchen, wo im Programm das gezeigte Bild auftritt.

Schlecht: Nur einen kleinen Bildschirmausschnitt als Suchbild abfotografieren

Gut: Den kompletten Bildschirm abfotografieren. Damit erkennt man sofort, wo im Programm der Anwender sich befindet, was er sieht, wie hoch seine Bildschirmauflösung ist etc.

Tipp: Tools wie Monosnap können den Screenshot sogar mit Anmerkungen versehen.

Eine realistische Einschätzung der Dringlichkeit

Wenn man die obigen Punkte beachtet, dann hat man bereits sehr gute Chancen, dass das Problem zügig bearbeitet wird. Wenn man es jetzt noch schafft, eine realistische Einschätzung der Dringlichkeit des Problems zu formulieren, dann steigen die Chancen noch weiter (sogar, wenn die Dringlichkeit gering ist). Man kann sich sicher sein, dass sich ein Entwickler merkt, wo die guten und wo die schlechten Fehlerbeschreibungen herkommen. Genauso wird er sich merken, wer Dringlichkeit gut einschätzen kann und sich nicht übermäßig wichtig nimmt.

Schlecht: “DRINGEND !!!” (am besten als alleinigen Betreff, die Anzahl der Ausrufezeichen multipliziert die Dringlichkeit der Aussage)

Gut: ”Login zu Anwendung X funktioniert Montags nicht – Erstellen von Rechnungen nicht möglich”

Hinweis für die Techniker

Die bisher genannten Angaben sind ein Muss und sollten in einem Fehlerbericht immer auftauchen. Je mehr Felder ich in einem Fehlerbericht freischalte, je mehr ich von einem Anwender an Entscheidungen verlange, je tiefer ich nach IT-Wissen versuche zu grabe, desto fehlerhafter wird mein Bericht werden und desto unwilliger die Anwender, diesen einzureichen. Also lieber Softwareentwickler, Tester, Projektmanager – beschränkt euch aufs Wesentliche.

Wenn ich bei einem Kunden ein Projekt begleite, begegnet mir oft eine Frage: Wie finde ich einen guten Softwareentwickler, eventuell einen Freiberufler, der meine Vorstellungen umsetzen kann? Viele Unternehmen haben schon negative Erfahrungen mit Kollegen aus der Softwareentwicklung gemacht, wollen auch daraus lernen, finden aber nicht den richtigen Ansatz. Oft gleitet die Diskussion sehr schnell in die Richtung “Wie soll ich denn erkennen, ob der Kollege gut programmieren kann? Ich bin doch kein Entwickler.” oder “Meine Administratoren können zwar System X aufsetzen und warten, sind aber nicht in der Entwicklung tätig und haben überhaupt keine Chance, einen Reinfall zu entdecken”. Man konzentriert sich also vor allem auf schlechten Code.

So wird manchmal ein Entwickler nach dem anderen durchprobiert, die Kosten steigen immer weiter und am Ende ist das Ergebnis leider doch mittelmäßig, wenn überhaupt verwendbar. Teilweise hat man Glück und findet nach ein paar Versuchen einen guten Kandidaten, doch der kann leider nur für ein Projekt zur Verfügung stehen und dann geht die Suche wieder los.

Aber es gibt Wege, auch als Nicht-Techniker einen guten Entwickler zu finden. Man muss nur wissen wie.

Der wichtigste Test ist das Verhalten bei der Vorstellung des konkreten Projekts. Erklären Sie genau, wie Sie sich das Ergebnis vorstellen. Achten Sie bei dem Gespräch vor allem darauf, ob Fragen nach Sinn und Unsinn von Funktionalitäten gestellt werden. Ein guter Entwickler nimmt keine Projektanforderung als Gott-gegeben hin, sondern hinterfragt wichtige Punkte. Ein Entwickler muss den Hintergrund von dem verstehen, was er entwickeln soll. Wenn das nicht geschieht, können Sie nahezu 100% sicher sein, dass der Kandidat nicht passt.

Fragen Sie nach Vorschlägen, wie man die Anforderungen eventuell anders umsetzen könnte. Vielleicht gibt es andere Möglichkeiten, an die Sie noch nicht gedacht haben. Ein guter Entwickler wird Ihnen Alternativen aufzeigen können und auch eine knappe Bewertung abgeben, warum das eine besser oder schlechter geeignet ist, als das andere.

Die Zeitschätzung ist ebenfalls ein gutes Indiz. Nach der Vorstellung des Projekts wird der Entwickler natürlich nach Zeitaufwand und Fertigstellungstermin gefragt (wenn dieser nicht bereits durch das Projekt vorgegeben ist). Sollte hier nach dem ersten Gespräch sofort eine exakte Zahl fallen, können Sie im Regelfall aufhören. Außer bei Mini-Projekten im 4-Stunden-Bereich ist es unmöglich, aus dem Stehgreif eine exakte Schätzung zu erhalten. Eine “Hausnummer” der Art “zwischen 4-5 Wochen” und “ca. X €” kann man erwarten, aber ein guter Entwickler sollte darauf hinweisen, dass man eine Zeitschätzung nicht aus dem Ärmel schüttelt und sich daher eine kurze Bedenkzeit erbeten für die Rückmeldung.

Auch ein Punkt, den viele allerdings nicht so gerne hören, ist die Frage nach den Kosten. Ein guter Entwickler ist selten auf den ersten Blick billig. Ich kenne keinen wirklich guten Entwickler, der für 20€ die Stunde arbeitet. Klar, es gibt manche, die nebenbei ein bisschen hacken und sich etwas dazuverdienen wollen, aber realistisch liegt der Stundensatz irgendwo zwischen 50€ und 150€ je nach Projekt und Anforderung. Softwareentwicklung ist ein Handwerk, das hohe kreative Anforderungen stellt und genauso ein systematisches Vorgehen bei der Durchführung erfordert. Der Zeitaufwand für die Weiterbildung ist auch nicht unbedingt gering. Spart man hier, kann man sich sicher sein, nachher bei der Wartungs- und Weiterentwicklungskosten ordentlich drauflegen zu müssen, um die gemachten Fehler auszubessern. Betrachten Sie also den Gesamtnutzen des Projektes. Wie hoch sind die Einsparungen oder die neuen Umsätze, die durch das Projekt generiert werden können im Gegensatz zu den Projektkosten?

Sollten Sie die Chance haben, doch einen Kollegen aus der Entwicklung hinzuziehen zu können, dann tun Sie das. Man kann damit den Horizont noch erweitern und folgende Themen ansprechen.

Neben der Primäranforderung, das heißt die Beherrschung der Programmiersprachen, gehören dazu aus meiner Sicht auch der sichere Umgang mit Entwicklungsumgebungen. Ja, absichtlich Plural. Klar hat jeder Entwickler seine Lieblingsumgebung inkl. -sprache, aber auskommen sollte er nach der üblichen Einarbeitungszeit mit fast allem. Sprechen Sie ihren Kandidaten auf dieses Thema an, fragen Sie nach, was seine Lieblingsumgebung ist und ob er mit der bei Ihnen verwendeten klar kommt. Hören Sie darauf, ob er bestimmte “Macken” anspricht, ins Detail geht, oder oberflächlich bleibt. Die meisten guten Entwickler sind leidenschaftlich bei der Sache und das hört man.

Sprechen Sie den Entwicklungsprozess als solchen an. Stellen Sie Ihren Prozess und die verwendeten Tools vor. Welches Quellcodeverwaltungssystem verwenden Sie (es gibt doch eines, oder?) und wie werden Fehler gemeldet und verfolgt? Normalerweise spricht ein Entwickler, der bei Ihnen eingebunden werden soll, solche Themen von sich aus an, oder kann zumindest mit dem Themenfeld etwas anfangen.

Fazit: Auch ohne technisches Verständnis kann man die Spreu vom Weizen trennen, man muss allerdings bereit sein, auch etwas Zeit zu investieren und sollte nicht zu viel Wert auf die Einschätzung einer Personalvermittlung legen. Letztere wollen nämlich hauptsächlich eines: die Provision kassieren.

Heute morgen habe ich für einen Kunden ein kurzes Infodokument zusammengestellt, um zu zeigen, wie man Webservices über GET oder POST in VBA anspricht. Ohne viel zu erklären, die zwei kurzen Codeschnipsel. Der erste Request holt sich über POST zu einem ISO2-Country-Code ein paar Infos als XML-Dokument, der zweite fragt Google per GET nach dem Begriff “test” und liefert das Ergebnis als json zurück.

' Democode für Webservice-Aufrufe über GET und POST
'
' 3.11.2012 - Waidner IT Solutions

Option Explicit
 
Sub XMLHttpTest()
    Dim XMLHttp As Object
    Dim strURL As String, strMethod As String, strUser As String
    Dim strPassword As String
    Dim bolAsync As Boolean
    Dim varMessage
 
    ' Microsoft XML HTTP Objekt erzeugen
    Set XMLHttp = CreateObject("MSXML2.XMLHTTP")
 
    ' -------------- POST-Request, der xml liefert -------------
    
    ' Parameter für einen simplen POST-Request ohne Authentifizierung füllen
    strMethod = "POST"
    strURL = "http://www.webservicex.net/country.asmx/GetCountryByCountryCode"
    bolAsync = False
    strUser = ""
    strPassword = ""
    varMessage = "CountryCode=DE"
 
    MsgBox "POST-Request, der XML liefert"
 
    ' Request absetzen
    Call XMLHttp.Open(strMethod, strURL, bolAsync, strUser, strPassword)
    Call XMLHttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded")
    Call XMLHttp.send(varMessage)
 
    ' Rückgabewerte ausgeben
    MsgBox "Status: " & XMLHttp.Status
    MsgBox "responseText: " & XMLHttp.responseText
    MsgBox "reponseXML: " & XMLHttp.responseXML.Text
 
    ' ---------------- GET-Request, der json liefert ----------------
    
    ' Parameter für einen simplen GET-Request ohne Authentifizierung füllen
    strMethod = "GET"
    strURL = "http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=test"
    bolAsync = False
    strUser = ""
    strPassword = ""
    varMessage = ""
 
    MsgBox "GET-Request, der JSON liefert"
 
    ' Request absetzen
    Call XMLHttp.Open(strMethod, strURL, bolAsync, strUser, strPassword)
    Call XMLHttp.send(varMessage)
 
    ' Rückgabewerte ausgeben
    MsgBox "Status: " & XMLHttp.Status
    MsgBox "responseText: " & XMLHttp.responseText
    MsgBox "reponseXML: " & XMLHttp.responseXML.Text
End Sub

Sobald man in Lotus Notes eine Anwendung entwickelt, die etwas aufwändiger als die üblichen Dokumentenablagen ist, kommt man unweigerlich mit dem Thema Performance in Berührung. Früher oder später beschweren sich die Anwender, dass das neue Tool viel zu langsam ist. Die Admins merken, dass ihre Agenten nicht durchlaufen und die Offline-Nutzer ärgern sich über lange Replikationszeiten.
Doch Notes kann schnell…man muss nur wissen wie.
Neben der reinen Optimierung im Code auf die ich hier nicht eingehe (aber natürlich gerne durchführen oder erörtern kann) gibt es serverseitig eine Liste von Optionen, die sich positiv auf eine Datenbank auswirken können. Diese finden sich in den Datenbankeigenschaften auf dem letzten Reiter. Alle Optionen, die hier nicht beschrieben sind, haben auf die Performance keinen Einfluss.

• Don’t maintain unread marks: ein – Sorgt dafür, dass keine ungelesen-Markierungen (die roten Sternchen) verwaltet werden. Wenn die Datenbank dies nicht benötigt, auf jeden Fall ausschalten.
• Optimize document table map: ein – Verknüpft Dokumente mit ihrem Formular und sorgt bei allen Ansichtsformeln der Art “Form = xxx” für eine Beschleunigung. Wenn Masken selten gewechselt werden, definitiv ein Plus.
• Don’t overwrite free space: ein – Platz, den gelöschte Dokumente einnehmen, wird nicht sofort überschrieben. Ist für Datenbanken, die nicht absolut sicherheitskritisch sind, einzuschalten
• Maintain last accessed property: aus – Wenn die Option eingeschaltet ist, werden auch Lesezugriffe protokolliert, was zu häufigeren Schreibzugriffen in der Datenbank führt.
• Disable transaction logging: ein – Wenn es die Backup-Strategie erlaubt, dann kann diese Option aktiviert werden. Die Schreibzugriffe werden damit reduziert.
• Don’t support specialized response hierarchy: ein – Wenn @AllChildren und @AllDescendants in der Datenbank nicht verwendet werden, kann dies aktiviert werden.
• Use LZ1 compression for attachments: ein – Aktiviert ein neueres, schnelleres Komprimierungsverfahren für Dateianhänge.
• Don’t allow headline monitoring: ein – Wenn die Datenbank keine headline-feeds unterstützen muss (und das müssen sicherlich die wenigsten, ich habe in meiner ganzen Notes-Laufbahn nicht einen Anwender gefunden, der dies verwendet hat), dann kann die Option eingeschaltet werden.
• Allow more fields: aus – Bei deaktivierter Option dürfen alle Felder in der DB zusammen 64k nicht überschreiten, was für ca. 3000 Felder ausreicht. Reduziert die Größe der Datenbank und erhöht damit die Performance.
• Support response thread history: aus – Hiermit erhalten Dokumente zusätzliche Felder, um Antworthierarchien zu unterstützen. Kann im Regelfall deaktiviert werden, außer man entwickelt ein Diskussionsforum.
• Compress database design: ein – Reduziert die Datenbankgröße durch Komprimierung und damit Replikations- und Ladezeiten.
• Compress document data: ein – Reduziert die Dokumentengröße durch Komprimierung und damit Replikations- und Ladezeiten.
• Disable automatic updating of views: aus/ein – Wenn aktiviert, sorgt es dafür, dass Views automatisch aktualisiert werden. Für die Datenbank an sich ist dies positiv, da Ansichten schnell zur Verfügung stehen. Sind allerdings viele Datenbanken auf einem Server mit dieser Option ausgestattet, senkt es die Performance, da der Server mit der Aktualisierung nicht mehr nachkommt und ständig unter Last stehe.
• Allow soft deletions: aus – Wenn man ein undo auf Löschungen nicht benötigt, dann sollte man dies deaktivieren.
• Limit entries in $UpdatedBy fields: 3 – Wenn man keine detaillierte Protokollierung der Änderer eines Dokuments benötigt, kann man den Wert niedrig ansetzen.
• Limit entries in $Revisions fields: 3 – Wenn eine hohe Replikationsfrequenz für die Datenbank vorhanden ist, oder überhaupt nicht repliziert wird, kann man diesen Wert reduzieren. Sehr niedrige Werte erhöhen die Chance von Replikationskonflikten.

Zusammengefasst sieht das ganze dann so aus:

Quellen für die Informationen ist u.a. IBM, kann man hier in Englisch nachlesen. Mehr Informationen finden sich auch hier in Deutsch. Details zur View-Aktualisierung stammen hierher.

Ein weiterer Schritt, um die Performance bei Datenbanken mit sehr hohen Dokumentzahlen und Dokumentlöschungen zu erhöhen, ist die Reduzierung der Löschmarkierungen. Um eine einwandfreie Replikation zu gewährleisten, speichert Notes bei jedem gelöschten Dokument eine Löschmarkierung und gibt diese bei Replikation an andere Server/Clients weiter, damit diese ebenfalls über Löschungen unterrichtet sind. Mal davon abgesehen, dass auch dieses Verfahren nicht 100% funktioniert (siehe hier den Artikel zu PIRC), sorgt es für eine Menge Einträge in der Datenbank. Diese kann man sich mit “show database kompletter/pfad/zur/datenbank.nsf” auf der Serverkonsole anzeigen lassen. Ganz oben in der Liste tauchen die gelöschten Dokumente auf.

Reduzieren kann man diese wie folgt:

• Replikationsoptionen der Datenbank aufrufen (Rechtsklick->Replication->Options…)
• Reiter “Space Savers” anwählen
• Ganz oben in der Box für “Remove documents not modified…” den eingetragenen Wert merken (im Regelfall 90)
• Wert 0 eintragen
• Den Haken AUF KEINEN FALL setzen, da er dafür sorgen würde, dass alte Dokumente komplett aus der Datenbank gelöscht werden
• Dialog mit OK bestätigen
• Die Optionen neu aufrufen, den Wert nun auf einen niedrigen Wert setzen oder den vorher gemerkten Wert eintragen. Lotus Domino hebt die Löschmarkierungen immer bis zu einem Drittel der hier eingetragenen Zeit auf.

Die Informationen stammen aus dieser Quelle.

Gerne stehe ich Ihnen für die Optimierung ihrer Datenbanken auf diese Art sowie natürlich auch für alle Fragen zur Performance-Verbesserung von Views oder Forms und dem in Datenbanken enthaltenen Programmcode zur Verfügung. Meine Kontaktinformationen für eine unverbindliche Anfrage finden Sie hier.

Wer einigermaßen aufmerksam durch das Netz surft, hat sicherlich in letzter Zeit die Passwortdiebstähle bei linkedIn, eHarmony oder last.fm mitbekommen. Inzwischen gehen solche Meldungen fast schon in der Masse unter, aber hier gibt es wieder einmal eine Besonderheit: Die Passworte waren mit absolut veralteter Technologie gesichert, so dass die kursierenden Listen schnell geknackt sein werden, wie dieser Artikel sehr schön zeigt. Dies nahm inzwischen eine Amerikanerin zum Anlass, eine Sammelklage gegen linkedIn einzureichen.

Klar, ein Teil der Schuld liegt beim Benutzer, die am schnellsten geknackten Passworte sind triviale Konstrukte wie “asdf” oder “Password”. Aber wie verhindere ich als Entwickler nun eine solche Katastrophe bei eigenen Anwendungen, und wie aufwändig ist eine wirklich sichere Speicherung von Passworten, so dass ich nicht sofort gehackt werde?

Die gute Nachricht: es ist recht simpel, man muss nur das Verfahren einmal verstanden haben. Der Artikel von crackstation beschreibt das Ganze extrem ausführlich, leicht verständlich und mit Beispielen garniert. Auch ich musste erst einmal nachlesen und lernen, aber genau dafür gibt es ja passende Artikel. Ich fasse hier nur noch einmal die wichtigsten Punkte auf deutsch zusammen, lest unbedingt danach noch das Original.

Regel Nummer 1:
Passworte NIEMALS im Klartext ablegen, immer one-way verschlüsselt, im Regelfall nutzt man dazu Hash-Algorithmen wie SHA256. Sollte man sich auf irgendeiner Website anmelden und in der Bestätigungsmail einmal sein Passwort erhalten, hilft nur: Account direkt löschen, hier ist garantiert kein Hashing verwendet worden.

Regel Nummer 2:
IMMER einen Salt verwenden. Dies bedeutet, das vom Nutzer eingegebene Passwort mit einem Zufallswert ergänzen, der pro Passwort neu berechnet wird. Erst dann das Passwort hashen und speichern.

Regel Nummer 3:
Aktuelle und für die Cryptographie geeignete Algorithmen verwenden. Niemals versuchen, eigene Verfahren zu implementieren, oder solch lustige Dinge wie Mehrfachverschlüsselung oder künstliche Beschränkungen einzubauen. Schon die Enigma wurde deswegen geknackt.

Regel Nummer 4:
Es auch machen und nicht nur darüber lesen!

Codebeispiele für PHP und C# finden sich im Artikel, es zählt also keine Ausrede mehr.

Eine kleine Geschichte zweier Lotus Notes Benutzer und ihrer Daten.

Herr User erzeugt sich eine lokale Replik einer Datenbank auf seinem Notebook. Herr User ist leider Chef und damit Gelegenheitsanwender, d.h. er braucht nur einmal im halben Jahr die Datenbank für ein paar Statistiken. Ansonsten wird auch nicht repliziert, da es ja zu viel Zeit kostet.

Frau Anwender ist regelmäßiger User der Anwendung, hat ebenfalls eine lokale Replik und arbeitet täglich damit. Mindestens 1x pro Tag wird repliziert. Im Zuge einer Aufräumaktion wird eines schönen Tages die Datenbank bereinigt, etliche Duplikate werden gelöscht. Die Datenqualität ist bestens, alles ist gut.

Ende des Jahres passiert das Unglück: Herr User braucht dringend die aktuellen Statistiken, schmeißt die Replikation an (“warum dauert das eigentlich immer so lange?”) und zieht eben den Report. Katastrophe, Einträge sind mehrfach vorhanden, völlig unbrauchbare Auswertung. Auch Frau Anwender trifft der Schlag, da auf einmal die ganze Aufräumaktion wieder hinfällig ist.

Was ist passiert? Notes hat eine unschöne Angewohnheit, die dazu führt, dass Löschmarkierungen entsorgt werden. In den Replikationsoptionen einer Anwendung findet sich eine scheinbar harmlose Option:

“Remove documents not modified in the last (days)” ist zwar auf 90 Tage gestellt, aber welcher Wahnsinnige aktiviert schon diese Option? Doof nur, dass Notes dies auch verwendet, um die Ablaufzeit von Löschmarkierungen zu ermitteln, und zwar egal, ob die Option aktiviert oder deaktiviert ist. Nach einem Drittel der eingestellten Zeit werden Löschmarkierungen (deletion stubs) entsorgt. Kann man hier nachlesen. Dies bedeutet für unser Beispiel, dass +/- 30 Tage nach der Aufräumaktion von Frau Anwender die Löschmarkierungen vom Server getilgt werden. Gibt es Repliken, wie die von Herrn User, die in dieser Zeit nicht repliziert haben, dann Pech: die Markierungen sind weg, die Dokumente dafür aber wieder da! Na Gratulation, da hat sich die IBM was feines ausgedacht.

Aber Rettung naht, es gibt nun PIRC (Purge Interval Replication Control). Wenn man einen 8.5.3er Server mit einem 8.5.3er Client paart, dann hat man eine neue Option auf der Replikationsseite:

Was macht diese? Verhindern, dass alter Mist wieder in die Datenbank repliziert wird. Funktioniert es? Ja, aber es muss leider pro Server pro Replik aktiviert werden. Es gibt auch einen langen Artikel, der alle Details erklärt, und einen Blogeintrag bei der Notes-Hexe, aber die Fakten sind einfach:

Repliziert eine nicht-PIRC-Replik mit einer PIRC-Replik, landen nur die Dokumente in der Datenbank, die innerhalb des angezeigten Intervals modifiziert worden sind. Nebenwirkung: Wenn man lange nicht repliziert, werden sehr alte Änderungen der lokalen Replik möglicherweise nicht übertragen. Aber das kann man zum Glück durch einfaches neu abspeichern umgehen.

Kleiner Gag am Rande: In der Doku zu 8.5.3 findet man nichts, weil es diese nicht gibt, sondern immer noch die 8.5.1 Doku ausgeliefert wird. Profiarbeit!

Es gibt viele Name dafür: Bananensoftware (weil sie beim Kunden reift), TdK-Software (Test durch Kunde), Alpha-release; man kann die Liste lange fortsetzen. Im Grunde wird ein Hauptproblem der Softwareentwicklung beschrieben: mangelnde Qualitätssicherung führt zu ausgelieferten Programmen, deren Fehler erst durch den Kunden entdeckt werden, oder deren Funktionalität einfach nicht zur Problemstellung passt.

Darf der Kunde also immer nur perfekte Software erhalten?

Für im Echtbetrieb eingesetzte Software gilt die Aussage in jedem Fall. Ein System, welches wie auch immer produktiv genutzt wird, sollte fehlerfrei sein, da sind wir uns einig.

Wenn es sich allerdings um Software handelt, die sich noch im Entwicklungsprozess befindet, kann man diesen Vorsatz oft außen vor lassen. Klar sollten die offensichtlichen Fehler bereits durch den Softwareentwickler und seine Test-Kollegen beseitigt worden sein, aber wenn es um inhaltliche oder Bedienerfragen geht, muss keine Perfektion erreicht sein. Ganz im Gegenteil habe ich bereits sehr gute Erfahrungen damit gemacht, den Kunden so früh wie möglich an “seinem” Produkt teilhaben zu lassen. Wenn man sich als Entwickler nicht monatelang in sein stilles Kämmerlein zurückzieht, sondern den Kontakt mit dem Kunden sucht, ihn oft nach seiner Meinung fragt, dann wird am Ende ein besseres Produkt entstehen. Und wenn ich diese Meinung oft haben will, dann muss ich als Entwickler den Mut haben, auch einmal ein unfertiges Produkt zu präsentieren. Wenn eine Demo nicht ganz perfekt durchläuft, auch mal etwas nicht so funktioniert, wie es sollte, und dafür beim nächsten Termin korrigiert ist, wird der Prozess der Softwareentwicklung deutlich.

Und genau dieser Prozess muss deutlich werden, es muss gezeigt werden, dass Softwareentwicklung ein Handwerk ist, bei dem Mitarbeit gefordert ist. Ohne die Integration des Kunden und seiner Mitarbeiter kann man noch so gut designen, das Endprodukt wird nicht richtig zufriedenstellen. Die beste Software habe ich entwickelt, wenn sich die Endanwender ganz früh beteiligen durften und sahen, wie ihre Tests Auswirkungen auf das fertige Produkt haben. Man nutzt hier aus, dass viele Menschen “etwas bewegen wollen”, auch wenn es nur Kleinigkeiten sind. Die Motivation steigt ungemein, wenn das eigene Wort Gehör findet.

Probieren Sie es als Entwickler: bringen Sie Software früh zum Kunden. Probieren Sie es als Kunde: lassen Sie ihre Anwender früh mit neuen Systemen “spielen”. Die Softwarequalität wird steigen.

Die MP3-Musiksammlung auch im Auto abspielen ist heute dank USB-Anschluss meist kein Problem mehr. Was allerdings bei vielen Autoradios nicht anständig funktioniert, ist die Sortierung der Titel nach Tracknummer des Albums. Den meisten Anwendern erscheint die Abspielreihenfolge zufällig, dem ist aber nicht so: meistens wird die Reihenfolge verwendet, in der die Dateien auf den Stick kopiert worden sind.

Um das Problem zu umgehen, und außerdem noch einmal eine gute Ausrede zu haben, etwas mit der Windows Presentation Foundation (WPF) in C# herumzuprobieren, habe ich den AudioSorter geschrieben. Das kleine Programm erwartet eine Laufwerksangabe und bei einem Klick auf “Sort” werden alle Stücke nach ihrer Tracknummer im ID3-Tag sortiert. Klappt bei meinem Autoradio einwandfrei, vielleicht hilft es auch anderen.

Das Programm kann kostenlos hier heruntergeladen werden: AudioSorter

Google+ hat Anfang November die Möglichkeit von Pages für Firmenpräsenzen eingeführt und seitdem habe ich auch mit Waidner IT Solutions dort eine Seite hinterlegt. Sie finden dort zusätzlich zu den längeren Blogeinträgen hier, aktuelle Neuigkeiten sowie kleinere Tipps und Anmerkungen oder den einen oder anderen Link auf spannende Artikel im Netz.
Ich würde mich freuen, wenn Sie mir auch dort folgen und diese weitere Möglichkeit zur Kontaktaufnahme nutzen.