R.I.P. Lidl

Lidl ist durch ihre Mitarbeiter / Kundenüberwachung in letzter Zeit eigentlich genug in Kritik geraten. Man sollte sich nach diesen Vorwürfen nochmal überlegen ob man dort wirklich einkaufen will. Aber bei diesem Super Angebot heute konnte ich nicht widerstehen:

500 GB externe SATA Festplatte in Aluminiumgehäuse mit Netzwerk-, eSATA- und USB-Anschluss für gerade mal 139 EURO

Und da meine eine externe Festplatte vor kurzem sowieso seinen Geist aufgegeben hat, war dies (trotz Lidl) ein verlockendes Angebot. Soweit zur Theorie... Ich also vor genau drei Wochen um 9:00 Uhr vor dem Lidl gestanden und wollte eben diese Festplatte. Nachdem ich sie nirgends gefunden habe bin ich gleich an die Kasse um dort nachzufragen. Ich dachte ja ich höre nicht recht als man mir sagte, dass die Filiale nur zwei Festplatten geliefert bekommen hat. Ich mich natürlich erstmal total aufgeregt da dies ja nicht das erste Mal ist, dass Lidl vorher groß Werbung macht und dann kaum Exemplare auf Lager hat.

Die Mitarbeiterin, verwies mich allerdings sofort (anscheinend passiert das öfters...) auf die Service-Hotline die groß über dem Ausgang hängt. Ich natürlich gleich mein Handy ausgepackt und versucht dort anzurufen. Aber ich war wohl nicht der Einzige, der mit Lidl seine Probleme hatte. Gegen 11:30 habe ich dann endlich jemanden erreicht, der mir versicherte, dass es eigentlich nicht möglich sei. Er würde versuchen eine andere Festplatte vom Lager zu meiner Filiale zu schicken. Nachdem ich ihm (zugegeben etwas ungern) meine Kontaktdaten gegeben habe versprach er die Festplatte auf meinem Namen zu hinterlegen.

Eine Woche später wurde ich wieder angerufen. Im Lager sind noch Festplatten verfügbar und wenn ich noch Interesse habe, würde man mir eine in meine Filiale schicken. Ich hab mich natürlich erstmal gefreut und gewartet das sich, wie versprochen, meine Filiale meldet sobald die Platte dort eingetroffen ist.

Nachdem ich am Dienstag noch immer nichts von meiner Platte gehört habe, fragte ich halt nochmal nach (Die Nummer hatte ich ja mittlerweile eingespeichert). Wer hätte es gedacht? Mein Platte ist natürlich schon längst in der Filiale, man hatte nur vergessen mich anzurufen. Ich also gleich Abends zum Lidl und Platte abgeholt.

Ab hier wird es Technisch: Nachdem das Teil ja ein Netzwerkanschluss mitbringt bin ich davon ausgegangen das dort ein UNIX sein Dienst verrichtet und mir die Daten per SMB, FTP, NFS etc. zur Verfügung stellt. Das ganze kann man dann über ein Webinterface Verwalten (IP/DHCP etc.). Die Realität sah leider etwas anders aus: Das Laufwerk war von Targa und arbeitete mit ndas dazu in Wikipedia:

Network Direct Attached Storage (NDAS) ist ein proprietäres System für Speichermedien (meist Festplatten), die ohne einen PC oder Server direkt an ein Netzwerk angeschlossen werden können und auf dem Zielsystem wie ein lokaler Datenträger erscheinen.

Software war natürlich dafür nur Windows dabei allerdings habe ich auf der Herstellerseite auch ein "Source"-Paket gefunden. Bis auf ein paar Libs, die nur binär vorliegen, kann man es sich also kompilieren. Das Gentoo-Paket hat etwas ärger gemacht, deswegen habe ich es selbst kompiliert.

Das ganze läuft nun so ab: Die Platte hat eine eindeutige ID. Über die muss man die Platte auf jedem PC, auf dem man sie nutzen möchte, registrieren. Anschließend muss man einen ndas Dienst starten der schaut ob die Platte im Netzwerk ist. Wenn ja erscheint sie dann als Blockdevice und man kann sie wie gewohnt mounten. Blöder weiße kann immer nur ein Computer die Festplatte mounten und zwei mal ist mir beim unmount mein Laptop eingefroren (was mir unter Linux zuvor noch nie passiert ist). Und was das Fass zum überlaufen brachte: Die Funktion mit der ich ein erneutes Suchen nach der Platte anstoßen kann ist nicht eingebaut. So muss man immer den Dienst neu starten um zu suchen. Alles in allem muss ich sagen die Technik ist absoluter Bullshit!

Fazit: Ich habe die Platte gestern zurück getragen und hab mein Geld wieder abgeholt. Auch wenn das Angebot wirklich gut war, ist die Technik dahinter einfach nicht zu gebrauchen. Dann leg ich lieber noch 20€ drauf und hab eine funktionierende Festplatte. Ich muss sagen ich bin einerseits davon enttäuscht wie Lidl verkauft, da sie einfach absichtlich möglichst wenig Festplatten ausliefern. Andererseits auch was Lidl verkauft. Würde nicht mein Miteinkäufer unbedingt immer bei Lidl einkaufen wollen, würde ich wohl in nächster Zeit einen großen Bogen um Lidl machen. (Außer evtl. zum Spaß)

Ich kann nicht Programmieren...

... zumindest kam es mir letzte Woche so vor. Für eine Vorlesung musste ich einen (bis jetzt) vereinfachten Single Sign On - Server schreiben. Da wie gesagt dies bisher nur ein Prototyp ist, war die Implementierung relativ simpel und die Anwendung lief recht schnell. Die nächste Aufgabe bestand daraus den Prototyp mit vorgegebenen Unittests zu testen.

GRAUSAM! Ich dachte naja, zwei drei Tests werden wohl rot sein, aber das gut 60% fehlschlägt hat mich dann doch sehr betroffen gemacht. Die meisten Fehler waren einfach eine fehlende Überprüfung auf Null oder eine vergessene Negation in einer If Abfrage. Ich habe mich darauf hin gleich gefragt warum die Tests so schlecht ausgefallen sind bzw. was man besser machen könnte um solche Fehler zu vermeiden.

Natürlich Methoden wie Unittests, Design by Contract, TDD, etc. sind in aller Munde aber mal ehrlich, nutzt ihr die bei jedem Projekt so ausführlich wie man sollte? Ich bestreite nicht den Nutzen dieser Techniken, auch bin ich mir durchaus benutzt das diese bzw. vergleichbare Techniken in ernsthaften Projekten unabdingbar sind aber ich finde es sind immer noch zu viele Barrieren vorhanden so das die Techniken wirklich Sinn geben. Ich weiß nicht genau wie ich sagen soll, deshalb gibt es mal paar Beispiele:

Ein Unittest ist schnell geschrieben, aber man muss ja prinzipiell jede Mögliche Kombination von Input und Output Werten bzw. auch an Zuständen im System Abdecken. Ein enges System aus Unittests halte ich für sehr sinnvoll, aber wenn sich beispielsweise ein Nutzer mit Name und Passwort an einem Server anmelden will. Was muss ich alles Testen? Was ist wenn Nutzername und/oder Passwort Null sind? Was ist wenn Nutzer und/oder Passwort falsch sind? Was ist wenn der Server nicht erreichbar ist? Was ist wenn der Nutzer bereits angemeldet ist? Was ist wenn der Nutzer überhaupt nicht im System vorhanden ist? Was ist wenn Nutzername und/oder Passwort ein Leerer String sind? Und so weiter. Mir fällt bestimmt noch mehr ein. Und das nur für einen Vorgang! Man stelle sich das mal in einem Komplexen System vor! Außerdem ergibt sich früher oder später die otwendigkeit von Mock Objekten und GUI Tests. Diese Spirale dreht sich so lange hoch bis ich irgendwann mehr Testcode als produktiven Code habe. Und genau hier tritt für mich ein Widerspruch zwischen Theorie und Praxis auf. Ich weiß das es gut ist, ich weiß das man es braucht, aber ich habe keine Ahnung wie man sinnvoll (sowohl logistisch als auch zeitlich) alle Fälle abdecken soll.

Andere Möglichkeit sind Pre- Postconditons. Hier tritt, außer dem Umfangproblem der Unittests, auch noch das Problem der Mangelnden Verbreitung auf. Die Sprachen, die ich mehr oder weniger kenne (Java, Ruby, C(++), Python, Bash, Prolog(:D), ...) bringen Conditions von Haus aus nicht mit. Deshalb bleiben mir zwei Möglichkeiten: Entweder ich lade mir eine zusätzliche Erweiterung der Programmiersprache dazu (was leider wieder andere Probleme wie Kompatibilität und Overhead mit sich bringt) oder ich arbeite mit Asserts. Bringt meine Sprache der Wahl schon Asserts mit habe ich es etwas einfacher. Ansonsten muss man sich erst eine Assert Funktion schreiben (wofür es gerade in Ruby einige sehr schöne Ansätze gibt!). Das Problem was ich hier wieder sehe ist einfach das es keine gezielte Notation der Conditions gibt. Ich habe einfach am Anfang (oder auch am Ende) meiner Funktion 10,20 oder auch mehr Zeilen mit Assert Statements die alle Fälle die mir einfallen abdecken sollten. Blöd nur wenn die Methode selbst nur 5 Zeilen hat. Besser wäre ein Ansatz mit dem man durch die Erweiterung der Sprache eine gesonderte Syntax innerhalb des Methodenkopfes einführt. Und selbst da macht einem die Vielzahl der Möglichen Input- und Output-Werte Kopfzerbrechen.

Ich habe jetzt mal die beiden Methoden herausgegriffen und meine Bedenken dazu geäußert. Ich komme aber irgendwie aus diesem Widerspruch nicht heraus. Um robusten Code zu schreiben muss ich alle Fälle abdecken, wenn ich alle Fälle abdecke, komme ich nicht dazu Code zu schreiben. Klar der Mittelweg ist der beste, aber das dachte ich bei meinem Projekt auch und dann waren doch 60% rot. Es muss doch eine Möglichkeit geben schnell und kurz während ich die Methode schreibe alle Fälle auszuschließen die nicht auftreten dürfen. So eine Technik kann nur funktionieren wenn sei nebenbei, schon fast automatisch, abläuft (sei es nun wirklich automatisiert oder einfach nur durch den Autor). Aber irgendwie kämpfen die Methoden die mir spontan einfallen alle mit massig Overhead.

Wie handhabt ihr das? Schon mal TDD versucht? Geht es euch Ähnlich? Ich bin für Vorschläge dankbar!