DSGVO Mail from Provider

[pl]

hiermit möchten wir Sie auf die bevorstehenden Änderungen hinweisen:

1. Durch die DSGVO dürfen wir ab dem 25.05.2018 keine Logfiles mehr für den Endbenutzer bereitstellen. Aus diesem Grund werden am 25.05.2018 die Logfiles gelöscht und nicht mehr zur Verfügung gestellt.

Schlechte Zeiten für Entwickler die Logdateien als Entwicklerwerkzeuge auffassen -- Wie machen die das denn in Zukunft?

MfG

[beatovich]

hallo

hiermit möchten wir Sie auf die bevorstehenden Änderungen hinweisen:

1. Durch die DSGVO dürfen wir ab dem 25.05.2018 keine Logfiles mehr für den Endbenutzer bereitstellen. Aus diesem Grund werden am 25.05.2018 die Logfiles gelöscht und nicht mehr zur Verfügung gestellt.

Schlechte Zeiten für Entwickler die Logdateien als Entwicklerwerkzeuge auffassen -- Wie machen die das denn in Zukunft?

Wie bisher. Es ändert sich ja nichts.

Immerhin klärt sich damit ein Teil deiner DSE.

[pl]

hallo

hiermit möchten wir Sie auf die bevorstehenden Änderungen hinweisen:

1. Durch die DSGVO dürfen wir ab dem 25.05.2018 keine Logfiles mehr für den Endbenutzer bereitstellen. Aus diesem Grund werden am 25.05.2018 die Logfiles gelöscht und nicht mehr zur Verfügung gestellt.

Schlechte Zeiten für Entwickler die Logdateien als Entwicklerwerkzeuge auffassen -- Wie machen die das denn in Zukunft?

Wie bisher. Es ändert sich ja nichts.

Sehe ich auch so: Das Errorlog ist definitiv kein Entwicklerwerkzeug!

Immerhin klärt sich damit ein Teil deiner DSE.

Ja, man muss dem Besucher erklären daß jeder seiner Zugriffe geloggt wird. Steht bei mir auf jeder Seite übrigens. Ein Grund mehr, mit verschiedenen Schriftgrößen zu arbeiten.

MfG

[beatovich]

hallo

Sehe ich auch so: Das Errorlog ist definitiv kein Entwicklerwerkzeug!

Immerhin klärt sich damit ein Teil deiner DSE.

Ja, man muss dem Besucher erklären daß jeder seiner Zugriffe geloggt wird. Steht bei mir auf jeder Seite übrigens. Ein Grund mehr, mit verschiedenen Schriftgrößen zu arbeiten.

Nun, das tue ich nicht. Wenn es Logs gibt, dann wegen Script-Errors. Da spielen aber keine der üblichen ENV Variablen eine Rolle.

[1unitedpower]

Sehe ich auch so: Das Errorlog ist definitiv kein Entwicklerwerkzeug!

Dein Blogbeitrag lässt eine Erklärung vermissen, wieso man denn Fehlerspeicher eigentlich nicht zur Qualitätssicherung benutzen sollte. Du eröffnest mit einer Anekdote, wonach Kollegen mit der Auswertung des Fehlerspeichers überfordert gewesen seien, und infolgedessen hätten die zahlreichen Fehler wohl auch nicht zur Ergreifung sinnvoller QS-Maßnahmen geführt. So eine Situation liefert viele Ansatzpunkte, die man hätte kritisch hinterfragen können: War das Personal ausreichen geschult? Gab es evtl. eine toxische Fehler-Eingeständnis-Kultur? War das das Problem schlicht ein Ergebnis stiefmütterlichen Managements? Da hätte man sicher Interessantes zu berichten gehabt. Solche oder ähnliche Aspekte greifst du leider gar nicht auf. Stattdessen berichtest du von einer Scheinlösung des Konflikts: Ihr hättet den Fehlerspeicher vollkommen aufgegeben. Das heißt leider noch nicht, dass keine Fehler mehr auftreten, nur dass man sie nicht mehr sehen kann. Das verschlechert die Lage aller Beteiligten und ist damit Teil des Porblems, nicht Teil der Lösung.

Ja, man muss dem Besucher erklären daß jeder seiner Zugriffe geloggt wird.

Nein, man muss seine NuterInnen darüber aufklären, welche ihrer personenbezogenen Daten für welche Zwecke verwendet werden. Bei einem Fehlerspeicher gibt es erst mal keine größere Not überhaupt etwas Personenbezogenes zu speichern. Natürlich gibt es Ausnahmen davon, bspw. wenn ein Fehler im Bezahlprozess eines Online-Shops auftritt. Dann ist es in beidseitigem Interesse, dass der Fall lückenlos aufgeklärt werden kann, dafür ist es erforderlich zunächst das Einverständnis des Kunden bzw. der Kundin einzuholen.

[pl]

Sehe ich auch so: Das Errorlog ist definitiv kein Entwicklerwerkzeug!

Dein Blogbeitrag lässt eine Erklärung vermissen, wieso man denn Fehlerspeicher eigentlich nicht zur Qualitätssicherung benutzen sollte.

Da hast Du meinen Artikel nicht richtig gelesen. Denn ich zeige da sehr wohl die Alternativen auf. Und wie sie sich auswirken.

War das das Problem schlicht ein Ergebnis stiefmütterlichen Managements?

Du kannst Dir wahrscheinlich gar nicht vorstellen was manche Zeitgenossen für Probleme haben die als Ausrede für ihre unendliche Dummheit herhalten müssen.

MfG

[1unitedpower]

Da hast Du meinen Artikel nicht richtig gelesen.

Doch, jetzt sogar ein zweites Mal, um sicherzugehen dass ich keinen Aspekt übersehen habe, aber die Kritik bleibt bestehen.

Denn ich zeige da sehr wohl die Alternativen auf.

Ich habe ja erstmal kritisiert, dass im Beitrag keine nachvollziehbaren Gründe gegen Errorlogging genannt werden. Deine Alternative heißt RaiseError, damit teilst du DBI mit, dass bei internen Fehlern Perls die-Funktion aufgerufen werden soll und nicht die warn-Funktion. Und dann? Wie erfahre ich als EntwicklerIn davon, dass Exceptions im Produktivbetrieb aufgetreten sind? Was ist mit allen übrigen Fehlern, die zur Laufzeit auftreten können, die nicht mit der Datenbank zu tun haben? Und ich halte es auch für keine gute Idee den EndnutzerInnen Perl-Exceptions vor die Füße zu werfen. Im besten Fall ignorieren sie die Meldung nach kurzer Irritation.

[pl]

Wie erfahre ich als EntwicklerIn davon, dass Exceptions im Produktivbetrieb aufgetreten sind?

Genau dafür ist das Errorlog doch völlig fehl am Platz, merkst Du das nicht selber wie unsinnig das ist!?

Da wird nämlich ein Eskalationsprozess in Gang gebracht! Mit Mail, SMS usw. Das sind Sachen der fürs Projekt definierten Prozesse, ein Programmierer setzt diese nur um. Und mit meinem FW läss sich sowas besonders gut umsetzen, da ist das nämlich nur eine Frage der Konfiguration.

D.h., der Programmierer hat damit gar nichts mehr zu tun. Es sei denn die Exceptions liegen im Programm begründet. Und wie man Exceptions auch dazu nutzen kann, fehlerhafte Benutzereingaben abzufangen, habe ich auf meinem Blog sehr ausführlich beschrieben und sogar hier diskutiert.

MfG

[pl]

Da hast Du meinen Artikel nicht richtig gelesen.

Doch, jetzt sogar ein zweites Mal, um sicherzugehen dass ich keinen Aspekt übersehen habe, aber die Kritik bleibt bestehen.

Denn ich zeige da sehr wohl die Alternativen auf.

Ich habe ja erstmal kritisiert, dass im Beitrag keine nachvollziehbaren Gründe gegen Errorlogging genannt werden.

Es ist unkollegial!

Deine Alternative heißt RaiseError, damit teilst du DBI mit,

Falsch! RaiseError ist nicht auf DBI beschränkt!

Und ich halte es auch für keine gute Idee den EndnutzerInnen Perl-Exceptions vor die Füße zu werfen. Im besten Fall ignorieren sie die Meldung nach kurzer Irritation.

Unsinn. Der Benutzer weiß doch gar nicht, dass hinter der Fehlermeldung eine Exception steckt!

Beispiel:

# Benutzer gibt ein Datum ein
my $date = Date->new( $self->param('date') )
   or return $self->errmsg($@);

Der Benutzer sieht die Fehlermeldung die er gar nicht ignorieren kann! Und um das was da drinsteht, muss sich der Programmierer gar nicht kümmern, das wird in der Klasse Date geregelt. Der Programmierer muss auch nicht weiter darüber nachdenken, wo er die Fehlermeldung herbekommt, er nimmt ganz einfach $@ da steht sie nämlich drin.

Das Einzige was der Programmierer der Anwendung zu prüfen hat ist, ob mit der Benutzereingabe das Objekt erstellt werden konnte. Am Ende wirds ganz einfach!

MfG

[pl]

Hier ein bischen ausführlicher.

Das Thema hatten wir ja auch schon hier. Es geht darum, Exceptions zweckmäßig zu nutzen um den Code einer Anwendung zu vereinfachen. So können, siehe Beispiel, sämtliche Prüfungen auf gültige Benutzereingaben einer dafür zuständige Klasse überlassen werden.

Hintergründig ist, daß Perlintern jede Meldung die sich infolge einer Exception ergibt, in $@ zu finden ist. Das ist zwar eine globale Variable, aber die Prüfung auf eine Exception ist ja nicht eine Frage ob in $@ was drinsteht, sondern ob ein bestimmter Code erfolgreich ausgeführt werden konnte. So dient $@ lediglich dazu, die zu einer Exception gehörige Fehlermeldung zu transportieren.

MfG

[1unitedpower]

Ich habe ja erstmal kritisiert, dass im Beitrag keine nachvollziehbaren Gründe gegen Errorlogging genannt werden.

Es ist unkollegial!

Das ist mir zu dünn, aber wir kommen hier sowieso auf keinen grünen Zweig. Es ist Zeit für mich diese Diskussion mit dir abzubrechen.