Du vergleichst "Barcode" mit "Binär", beides als böse Feinde einer Klartextlösung. Das ist ein sehr gutes Eigentor. Denn wie wir alle bei jedem Supermarkt sehen können, hat sich Barcode voll durchgesetzt. Weil er überlegen ist. Natürlich geht es schneller, die Ware über den Scanner zu ziehen, als Preise zu Fuß (und oft genug fehlerhaft) einzuklimpern. Aber es geht noch weiter: Was ich von der klassischen Kassiererin bekommen habe, war ein armseliger Kassenzettel mit einer langen Zahlenreihe. Sonst nix. Wenn ich nachprüfen wollte, ob die sich irgendwo vertippt hat, mußte ich bei einem größeren Einkauf lange raten und vergleichen- gehören die 2,99 jetzt zu den Äpfeln, oder doch zum Shampoo? Habe ich überhaupt einen Artikel gekauft, der 2,99 kostete, oder hat die sich vertippt? Halbwegs zugeordnete Zahlen mußte man mit Kuli durchstreichen, und wenn es am Ende nicht aufging- tja, vielleicht hatte man den Fehler auch selbst gemacht.

Soviel zu Klartext als Arbeitsformat. Dann kam Barcode. Er machte es erst möglich, jeden Artikel eindeutig zu identifizieren. Heute enthält der Kassenzettel eine beinahe ausführliche Artikelbeschreibung neben jeder Zahl. Das hätte Deine geliebte Klartext-Kassiererin früher von Hand dazuschreiben müssen, womit die letzten Kunden erst um Mitternacht aus dem Laden gekommen wären. Heute, dank des nicht-menschenlesbaren Barcode als Arbeitsformat, bekomme ich mehr Text zum Lesen als früher- paradox, nicht wahr? Ein zusätzliches Gimmick eben, für mich als Enduser, aber natürlich nicht als Arbeitsformat zu gebrauchen.

Das meinte ich auch mit dem SALT-Vergleich. Es sind nun einige Geräte in Umlauf, und doch schon sehr viele Flüge damit gemacht worden. Bisher hat sich noch keiner beschwert, weil er die Datei nicht lesen konnte- die ist selbstverständlich binär. Weils das bessere Arbeitsformat ist. Aber da kein vernünftiger Mensch auf die Idee käme, ohne Not das Arbeitsformat lesen zu wollen (so wie uns allen die Barcodestriche auf der Supermarktware völlig egal sind), hat noch keiner das Klartextformat vermißt. Wer trotzdem gerne Zahlen liest, der ruft das Gimmick namens "Protokoll" auf, da drin stehen dann alle Messwerte im Klartext samt Kommentar.

Ich denke, daß diese Diskussion durch ein halsstarriges und beratungsresistenes Beharren auf das archaische "Klartextformat" momentan blockiert ist. In dieser Form bringt sie mir nichts, sondern kostet mich nur Zeit. Ich hätte noch jede Menge wirklicher Formatprobleme zu besprechen, aber das werde ich nur noch mit denen tun, die sich auch praktisch und ergebnisorientiert damit beschäftigen. Die Hunde bellen, die Formatkarawane zieht weiter.

Geändert von Peter am 26. April 2008 um 12:34

Zitat:

---

Du vergleichst "Barcode" mit "Binär", beides als böse Feinde einer Klartextlösung. Das ist ein sehr gutes Eigentor. Denn wie wir alle bei jedem Supermarkt sehen können, hat sich Barcode voll durchgesetzt. Weil er überlegen ist. Natürlich geht es schneller, die Ware über den Scanner zu ziehen, als Preise zu Fuß (und oft genug fehlerhaft) einzuklimpern. Aber es geht noch weiter: Was ich von der klassischen Kassiererin bekommen habe, war ein armseliger Kassenzettel mit einer langen Zahlenreihe. Sonst nix. Wenn ich nachprüfen wollte, ob die sich irgendwo vertippt hat, mußte ich bei einem größeren Einkauf lange raten und vergleichen- gehören die 2,99 jetzt zu den Äpfeln, oder doch zum Shampoo? Habe ich überhaupt einen Artikel gekauft, der 2,99 kostete, oder hat die sich vertippt? Halbwegs zugeordnete Zahlen mußte man mit Kuli durchstreichen, und wenn es am Ende nicht aufging- tja, vielleicht hatte man den Fehler auch selbst gemacht.

---

Oh Peter, du lebst in einer trügerischen heilen Welt. Dein Beispiel mit dem kontrollieren des Kassenausdruck hast du falsch dargestellt. Nur weil da jetzt Joguhrt hinter steht bedeutet es noch lange nicht das es einfacher wird. Willst du die Beträge wirklich kontrollieren, so mußt du die selber am Regal dir merken. Kannst es aufschreiben oder auswendig lernen. Wenn du jetzt an der Kasse bist, bekommst du einen Ausdruck in die Hand. Da mußt du händisch jeden einzelnen Wert durchgehen. Der Text der da neben steht hilft dir dabei nicht. Der kann ja falsch sein. Einzig die Werte sind interessant. Den wenn das Shampoo 2,99 gekostet hat und der Joghurt auch, dann ist es egal wo die in der Liste auftauchen. Früher gab es auch schon Multiplikatoren. Also 2x 2,99 könnte dann die zwei Joghurt sein und nicht das Shampoo. Ist aber eigentlich egal, weil du drei Produkte a 2,99 hattest. Meist kontrollierst du eh die Endsumme und die Anzahl. Dadurch das da ein arcode verwendet wird, wird das System nicht sicherer. Es täuscht dir nur eine Sicherheit vor. Das schnellste System hatte übrigens Aldi mit Kassieren die die Preise auswendig konnten.

Jetzt aber mal wieder die Frage die du mir noch nie beantwortet hast, was hast du gegen Klartext wenn du da doch genau das gleiche mit machen kannst wie mit binär? Wenn nicht sogar noch mehr? Was genau stört dich an Klartext das du es nicht willst?
Schaut man übrigens hier mal in die Runde, so gibt es mehr Klartextbeführworter als für binär.

Gruß

Neil

Zitat:

---

Original geschrieben von Peter


Soviel zu Klartext als Arbeitsformat. Dann kam Barcode. Er machte es erst möglich, jeden Artikel eindeutig zu identifizieren. Heute enthält der Kassenzettel eine beinahe ausführliche Artikelbeschreibung neben jeder Zahl. Das hätte Deine geliebte Klartext-Kassiererin früher von Hand dazuschreiben müssen, womit die letzten Kunden erst um Mitternacht aus dem Laden gekommen wären. Heute, dank des nicht-menschenlesbaren Barcode als Arbeitsformat, bekomme ich mehr Text zum Lesen als früher- paradox, nicht wahr? Ein zusätzliches Gimmick eben, für mich als Enduser, aber natürlich nicht als Arbeitsformat zu gebrauchen.

---

Irgendwie wiedersprichst du dir hier selbst. Ich verstehe das so das du den Barcode nicht lesen kannst und das für dich als Arbeitsformat nicht in frage kommt. Das Byteformat ist ebenfals nicht lesbar aber damit kannst du arbeiten?

Die Daten sind allerdings nicht im Barcode gespeichert.

Noch etwas:
Wenn du im Laden nur Barcode auf den Artikeln hast dann wünsche ich dir viel Spass beim suchen ob die Preise auch passen die am Kassazettel stehen. Wenn die nicht lesbar bei den Artikeln angebracht sind hast du keine Chance das zu kontrollieren. Also wenn die Daten nicht im Klartext vorhanden sind dann hast du keine Chance sie auf ihre Richtigkeit zu überprüfen. Du musst den Vertrauen was du bekommst.

Ich klinke mich mal ganz kurz als Mac User hier ein. Habe jetzt nicht die volle Diskussion gelesen, da ich ansich nur Verwender von Schubkurven bin, kein Schubstandinhaber.
Ein Menschenlesbares Format kann auf jeder Plattform, egal ob Win, Mac, Linux oder sonstwas benutzt werden. Ich brauche kein Programm, ich kann einfach die Daten und Zeiten in meine Tabellenkalkulation einlesen, und als Diagramm anzeigen, schon sehe ich eine Kurve. Wie die meisten Hobbyprogramme wird wohl auch hier kein Programm extra für 5-10 Mac/Linux - User geschrieben. Ein Menschenlesbares Format lässt auch Programmierlaien eine Schubkurve erstellen.

Nur meine Meinung.
MfG Fabian

Ich stimme Neil und Fabian zu. Ein menschenlesbares, textbasiertes Format ermöglicht alles, was ein binäres Format auch erlaubt, gleichzeitig kann man es mit einem simplen Texteditor, oder per Excel-Import (oder anderer Software, als Beispiel sei hier Mathcad oder Matlab für die Fortgeschrittenen unter uns genannt) lesen und interpretieren. Die Konvertierung zwischen betriebssystemspezifischen Textformaten (Win, Unix, Mac) beherrscht jedes in Frage kommende Programm.

Speicherplatz kann hier nicht als Argument gelten. Die Schubkurven von 100 Motoren mit einer durchschnittlichen Brenndauer von 2 s, 40 Kilosamples pro Sekunde (totaler Overkill) und 20 Byte pro Sample (z.B. 6 für die Zeitmarke und 11 für den Schubwert plus Trennzeichen und Zeilenvorschub) würden 160 MB (152,6 MiB) beanspruchen. Das erscheint in Zeiten von 4 GB USB-Sticks und 500 GB-Platten als beinahe vernachlässigbare Menge.

Die Datenübertragung zwischen Prüfstand und Software sollte vom endgültigen Speicherformat getrennt werden, da bei ersterem die Datenrate kritisch ist (800 kB/s schafft wohl kaum ein µC), bei letzterem nicht.

Oliver