Opencaching.de

Die Plattform opencaching.de => Entwicklung => Thema gestartet von: following am 16. Februar 2017, 09:47:27

Titel: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: following am 16. Februar 2017, 09:47:27
Vorgestern haben durch eine manuelle Änderung in der OC-Datenbank ca. 40.000 Logs und 700 Cachelistings die Markierung "zuletzt geändert am 14. Februar 2017" bekommen. Das sieht nun so aus, als hätten die Logger die Logs nacheditiert und die Owner die Cachebeschreibungen geändert. Tatsächlich sehen die Logs und Beschreibungen aber noch exakt genauso aus wie vorher.

Es ist technich möglich, das zu korrigieren und diese Daten zu >99% wieder auf den alten Stand zu bringen. Ich bekam aber eben vom OC-Entwicklungsvorstand (nachzulesen in Redmine-Ticket #1033) ohne weitere Diskussion oder Begründung die Antwort: "Wir werden das Datum nicht ändern." Stattdessen würde im Blog und OC-Talk darüber informiert.

Was haltet ihr davon? Wäre es nicht sinnvoller, diese Einträge zu korrigieren?
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: mic@ am 16. Februar 2017, 18:26:45
Zitat von: following
Das sieht nun so aus, als hätten die Logger die Logs nacheditiert und die Owner die Cachebeschreibungen geändert.

Was ist daran nun so schlimm?
Wenn Logs / Caches verloren gegangen wären, dann würde ich Dir zustimmen,
aber so handelt es sich doch "nur" um ein Änderungsdatum, was sogar passend
gesetzt ist, nur eben die falschen Schlussfolgerungen erlaubt. Also ich vermute mal,
das werden die Wenigsten wirklich bemerken.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Samsung1 am 16. Februar 2017, 19:36:25
Das soll so bleiben? 0o  Ich finde das reichlich unschön und es wirkt mega dilettantisch. Das stärkt nicht gerade die Akzeptanz der Plattform.  : \
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: mic@ am 16. Februar 2017, 22:52:28
Zitat von: Samsung1
Ich finde das reichlich unschön und es wirkt mega dilettantisch.

Dann auch die Frage an Dich: Was ist daran nun so schlimm?
Ich finde, hier wird aus einer Mücke ein Elefant gemacht.
Das einzige, was dadurch nun "falsch" ist, ist das neue Änderungsdatum.
Und technisch betrachtet ist dies ja noch nicht einmal falsch, denn es wurde ja etwas verändert.
Also in meinen Augen ist das hier kein Grund, so ein Fass aufzumachen.
Just my 0.02 Euro, Mic@
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: FlashCool am 17. Februar 2017, 07:18:46
Für mein Dafürhalten ist das ein eindeutiger Fehler seitens OC, der da passiert ist und der sollte so schnell wie möglich behoben werden. Ich kann mich der Meinung von Samsung1 nur anschließen. Für den Benutzer ist das so nicht nachvollziehbar und wirft Fragen auf, "stärkt" nebenbei auch das Misstrauen hinsichtlich Entwicklerkompetenzen.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Q-Owls am 17. Februar 2017, 10:15:33
Es ist technich möglich, das zu korrigieren und diese Daten zu >99% wieder auf den alten Stand zu bringen.
Das mal was schief geht ist normal.
Aber wenn machbar sollte man es  wieder in Ordnung bringen!
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: ClanFamily (Mirco) am 17. Februar 2017, 10:57:45
@FlashCool:
Hi. Es gab die Notwendigkeit, defekte Smilies in den Beschreibungen zu reparieren.
Dies wurde erledigt. Damit einhergehend wurde der Datensatz verändert. Das ist ein technischer Prozess und hat nichts mit Entwicklerkompetenz zu tun.
Logischer Weise ist es damit korrekt, dass das Änderungsdatum aktualisiert wurde (was nicht die Absicht war, sondern durch einen Datenbank Trigger funktionierte)

@Q-Owls:
Das Rückschreiben der Änderungen hat diverse Seiteneffekte inkl. entsprechendem Aufwand.
Das Entwicklerteam hat entschieden, hinter diesem Vorgang zu stehen und eine Lösung für die Zukunft zu finden.
Das wir im OC Support, mit Unterstützung von der Entwicklung Eingriffe in die Datensätze vornehmen, bleibt nicht aus.

Lerneffekt:
Es handelt sich hier rein um einen Datumsstempel, der keine Auswirkung auf Statsitik, Punke oder sonst was hat - außer, dass dort steht, das der Datensatz geändert wurde und nicht von wem.
Wir haben daher beschlossen, die notwendigen Eingriffe von uns, in naher Zukunft (ist bereits in der Entwicklung), per Audit Log kenntlich zu machen.
Somit ist klar, was haben wir wann geändert - ggfls mit Erklärung warum.

Wir verfassen darüber hinaus einen Blogbeitrag und besprechen diesen Fall im kommenden OC Talk.


Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Q-Owls am 17. Februar 2017, 11:09:17
Habe verstanden. Macht Sinn so.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: following am 17. Februar 2017, 11:15:08
@FlashCool:
Hi. Es gab die Notwendigkeit, defekte Smilies in den Beschreibungen zu reparieren.

Es gab und gibt keine Notwendigkeit, die Inhalte der Logs und Beschreibungen zu verändern. Für die Smilies wurde bereits eine andere Lösung gefunden; die Manipulation der von den Benutzern beigetragenen Inhalte ist völlig überflüssig.

Zitat
Das Rückschreiben der Änderungen hat diverse Seiteneffekte inkl. entsprechendem Aufwand.

Nein, es gäbe keine relevanten "Seiteneffekte". Den Aufwand bestünde darin, dass ein Datenbankdump aus dem Backup geholt wird, und dass ich mich ein paar Stunden hinsetze und die Daten repariere. Kein Problem.

Zitat
Das wir im OC Support, mit Unterstützung von der Entwicklung Eingriffe in die Datensätze vornehmen, bleibt nicht aus.

Der Support greift nur bei Listingvandalismus in Listinginhalte ein; alles andere ist tabu. Davon abgesehen sind Eingriffe auch bei defektem HTML-Code notwendig, dafür ist die Entwicklung zuständig.

In Fällen wie diesem hier ist ein Eingriff (er erfolgte im Alleingang durch die Entwicklung) unnötig.

Habe verstanden. Macht Sinn so.

Nein, macht keinen Sinn.


Allen Beteiligten ist klar dass das Ganze Mist ist, aber die Verantwortlichen sind nicht bereit den Mist wieder in Ordnung zu bringen, weil sie selbst nicht wissen wie es geht - und derjenige, der weiß, wie es geht, wird aus "politischen" Gründen daran gehindert, es zu reparieren. Auf Kosten der Nutzer.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: following am 17. Februar 2017, 11:53:22
Zur Erklärung für diejenigen, die was von Softwareentwicklung verstehen (die anderen bitte ignorieren):
... und trotzdem wird weiter an der Datumsmanipulation festgehalten. Sie ist unnötig und lässt sich rückgängig machen, und trotzdem hält man daran fest.

[Edit: Punkt 1 oben korrigiert; siehe Beitrag #20]
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Samsung1 am 17. Februar 2017, 16:58:46
Zitat von: Samsung1
Ich finde das reichlich unschön und es wirkt mega dilettantisch.

Dann auch die Frage an Dich: Was ist daran nun so schlimm?

 
Das ist ein technischer Prozess und hat nichts mit Entwicklerkompetenz zu tun.
Eben weil es ein technischer Prozess ist, würde ich sagen, dass er verdammt viel mit Entwicklerkompetenz zu tun hat :).


So viel zu meinen zwei Cent. Die Welt geht davon nicht unter - aber ich kann nur wiederholen, was ich oben gesagt habe: Ich finde das reichlich unschön und es wirkt mega dilettantisch.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: mic@ am 17. Februar 2017, 17:08:29
Zitat von: Samsung1
Es wirft so die Frage auf, was ihr noch so alles im Namen des Nutzers entfernt oder ergänzt.

Du kennst diesen Thread hier? http://forum.opencaching.de/index.php?topic=4203.msg55638#msg55638
Auch diese Änderungen geschahen zum Wohle von OC.


Zitat von: Samsung1
Haben wir da nicht irgendwie Gesetze mit einem Straftatbestand "Vortäuschung falscher Tatsachen"?

Wieso falsche Tatsachen. Es wurde ja zu diesem Zeitpunkt etwas geändert.
Also kein Grund zur Panik  8)
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: following am 17. Februar 2017, 17:11:44
Ich mache jetzt hier jetzt mal den Advocatus Diaboli: Haben wir da nicht irgendwie Gesetze mit einem Straftatbestand "Vortäuschung falscher Tatsachen"?

Wir haben auch eine Opencaching.de-Datenlizenz, die die Veränderung des von Benutzern beigetragenen Contents verbietet (CC ND). Nun wird überflüssigerweise der Eindruck erweckt, dass genau das passiert ist, obwohl de facto gar keine Änderung an dem erfolgt ist was der Nutzer eingegeben hat.

Wenn es tatsächlich notwendig wäre, solche Dinge nachträglich zu ändern (was hier nicht der Fall ist), dann kann man das mit Nachfilterung vor der Ausgabe des HTML-Codes machen, wie es bereits bei http-Bildpfaden in https-Seiten der Fall ist. In den Datenbankinhalten rumpfuschen ist nicht nötig.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Samsung1 am 17. Februar 2017, 17:32:26
Zitat von: Samsung1
Haben wir da nicht irgendwie Gesetze mit einem Straftatbestand "Vortäuschung falscher Tatsachen"?
Wieso falsche Tatsachen. Es wurde ja zu diesem Zeitpunkt etwas geändert.
Also kein Grund zur Panik  8)

Ich bin kein Jurist. Es erweckt den Anschein. Denke doch, das reicht.

Du kannst uns im relativ geschlossenen Kreis jetzt hier darlegen, warum diese Änderung sinnvoll war. Ich vertraue euch soweit, dass ich euren guten Willen als gegeben hinnehme. Aber eure Änderung hat eine immense Strahlkraft. Jeder, der so ein Log liest, bekommt potentiell ein ungutes Gefühl. Und diese Leute habt ihr damit geprägt. Die wenigsten von denen werden im Forum eine Erklärung suchen. So sind die Menschen nun mal.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Jiver78 am 17. Februar 2017, 21:36:09
Ich bin kein Jurist, aber...

Im letzten OC-Talk ging es um einen Copyright-Verstoß in einem Cachelisting, und dass der Owner das Anwaltsschreiben weitergelteitet bekam. Er ist ja als Publizierer des Caches für den Inhalt verantwortich.

Wenn OC nun Änderungen an den Cachelistings durchführt, egal wie marginal diese sind, wird OC selbst zum (Mit-)Publizierer des Listings und damit mit für den Inhalt verantwortlich.

Einzige Folgerung daraus: sowohl das Änderungsdatum muss zurückgesetzt als auch die Inhalte wiederhergestellt werden.




Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: ClanFamily (Mirco) am 17. Februar 2017, 21:38:05
Der einzige Treiber des Themas ist im Moment Following , der mal wieder Unruhe stiftet und das Team in derartige Unruhe bringt.
Eine rechtliche Diskussion Fang ich hier nicht an. Das ist hier nict die grüne Hölle.

Wie geschrieben. Der Trigger der die Änderung gesetzt hat weil wir Listig mit defekten Silies repariert haben ist der Grund für das Datum. Wir pflegen hier ständig die Datenbank. Dazu gehört aber keine inhaltliche Änderung. Auch in diesem Fall veränderten wir keinen Inhalt, sodern reparierten verlinkt gen die auf u Service Hosting verwiesen haben und die im Zuge der Weiterentwicklung ungültig wurden. Natürlich gibt es Hunderte Wege. Das TEAM hat sich nun für einen Entschieden.

PS: Following ist mit Beschluss der Jahreshauptversammlung 2016 aus Gründen nicht mehr Teil dieses Team und kann dies bis heute nicht akzeptieren. Weitere Stachelleien stärken diesen Beschluss eher.

Gesendet von meinem SM-G800F mit Tapatalk

Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: following am 17. Februar 2017, 22:22:24
PS: Following ist mit Beschluss der Jahreshauptversammlung 2016 aus Gründen nicht mehr Teil dieses Team und kann dies bis heute nicht akzeptieren.

Auf diesen Unsinn habe ich hier (http://forum.opencaching.de/index.php?topic=4771.0) geantwortet.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: FlashCool am 17. Februar 2017, 22:57:54
Der einzige Treiber des Themas ist im Moment Following , der mal wieder Unruhe stiftet und das Team in derartige Unruhe bringt.
Eine rechtliche Diskussion Fang ich hier nicht an. Das ist hier nict die grüne Hölle.

Wie geschrieben. Der Trigger der die Änderung gesetzt hat weil wir Listig mit defekten Silies repariert haben ist der Grund für das Datum. Wir pflegen hier ständig die Datenbank. Dazu gehört aber keine inhaltliche Änderung. Auch in diesem Fall veränderten wir keinen Inhalt, sodern reparierten verlinkt gen die auf u Service Hosting verwiesen haben und die im Zuge der Weiterentwicklung ungültig wurden. Natürlich gibt es Hunderte Wege. Das TEAM hat sich nun für einen Entschieden.

PS: Following ist mit Beschluss der Jahreshauptversammlung 2016 aus Gründen nicht mehr Teil dieses Team und kann dies bis heute nicht akzeptieren. Weitere Stachelleien stärken diesen Beschluss eher.

Gesendet von meinem SM-G800F mit Tapatalk

Mit etwas Abstand sehe ich persönlich hier zwei Dinge miteinander vermischt.

1) Persönliche Differenzen zweier Personen
2) Ein Datenfehler der passiert ist und nicht behoben wird

zu 2) Gekränkte Eitelkeiten sollten hier absolut keine Rolle spielen. Die Aussenwirkung für OC-Benutzer oder OC-Neulinge im Umgang mit Benutzer-Content ist m.E.n. fatal. Gründe wurden bereits aufgezeigt. Defizite in der Umsetzung einer Korrektur/Lösung werden polemisch abgebügelt.

Je mehr ich darüber nachdenke, wie mit klar und sachlich angesprochenen Problematiken vom OC-Team umgegangen wird, desto mehr festigt sich der Eindruck, dass die Entwicklung von OC so langsam in eine "kritische" Richtung abbiegt.

Just my 2 cents.

Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Jiver78 am 17. Februar 2017, 23:21:13
Auch in diesem Fall veränderten wir keinen Inhalt [...]

Ich finde es schon faszinierend wie man sich hier hinstellen und soetwas behaupten kann, wenn gleichzeitig die eigene Software das Gegenteil beweist.
Warum gibt es wohl ein neues Änderungsdatum durch die OC-Software? Weil der Inhalt verändert wurde.
Wäre kein Inhalt verändert worden, gäbe es das Problem nicht.

Auch wenn oberflächlich alles (wieder) in Ordnung ist da der neue Link nun auf eine Datei gleichen Inhalts verweist wie der alte, es wurde ein Link und damit der Inhalt des Listings verändert.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: teiling88 am 17. Februar 2017, 23:42:33
Wenn es tatsächlich notwendig wäre, solche Dinge nachträglich zu ändern (was hier nicht der Fall ist), dann kann man das mit Nachfilterung vor der Ausgabe des HTML-Codes machen, wie es bereits bei http-Bildpfaden in https-Seiten der Fall ist. In den Datenbankinhalten rumpfuschen ist nicht nötig.

In der modernen Softwareentwicklung gilt die Regel das man Fehler an der Wurzel behandeln sollte und nicht das Symptom behebt. Mehr infos können z.B. hier nachgelesen werden dazu: http://clean-code-developer.de/die-grade/roter-grad/#Root_Cause_Analysis Deine vorgeschlagenen Problemlösungen sind alles nur Behandlungsmöglichkeiten eines Symptoms.

Allen Beteiligten ist klar dass das Ganze Mist ist, aber die Verantwortlichen sind nicht bereit den Mist wieder in Ordnung zu bringen, weil sie selbst nicht wissen wie es geht - und derjenige, der weiß, wie es geht, wird aus "politischen" Gründen daran gehindert, es zu reparieren. Auf Kosten der Nutzer.

Das ist nicht wahr. Ich weiß wie ich das zurück setzen kann - habe aber eine andere Sichtweise die sich auch mit der Sichtweise des Entwicklungs-Teams deckt.

An alle:
Wir betreiben aktuell einen großen Aufwand um den vorhandenen Quellcode auf eine technische aktuelle Basis zu migrieren. Alte Zöpfe müssen abgeschnitten werden damit Platz für neues entstehen kann. Die Chance das wir das seit Jahren angekündigte Redesign mal endlich umsetzen können stehen schon lange nicht mehr so gut wie aktuell. Wir sind 4 aktive Entwickler und gerade dabei noch einen weiteren anzulernen.

Es wird in Zukunft bestimmt noch öfters solche Fälle geben wo man alte Links reparieren/anpassen muss. Ist euch dann lieber das wir das Änderungsdatum dann nicht aktualisieren? Wie sollen wir damit umgehen?

Wenn ihr so etwas schon machen wollt, dann schreibt darunter Geändert am $datum durch das OC-Team.

Dies könnten wir nachträglich mit wenigem Aufwand umsetzen - wäre das eine Lösung?

Beispiel:
Das Oc-Team hat defekte Links repariert.

Gruß, Thomas



Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: following am 17. Februar 2017, 23:58:56
In der modernen Softwareentwicklung gilt die Regel das man Fehler an der Wurzel behandeln sollte und nicht das Symptom behebt.

...

Das Oc-Team hat defekte Links repariert.

Es handelte sich nicht um einen Fehler sondern fehlerfreien Content. Den Fehler hat dann erst ein einzelner Entwickler eingebaut, indem er ein Verzeichnis mit Grafikdateien gelöscht hat, in dem sich dieser Hinweis (https://github.com/OpencachingDeutschland/oc-server3/blob/v3.0.15/htdocs/lib/tinymce/plugins/emotions/images/README) befand:

    Smiley images of old tinymce installation (removed with v3.0.9) which are
    still referenced in cache descriptions and logs.

Darum wäre die vorgeschlagene Meldung irreführend; allenfalls müsste sie heißen: "Das OC-Team hat Links kaputt gemacht und dann verbogen, damit sie wieder funktionieren."

Zudem gibt es im konkreten Fall bereits - wie oben erwähnt - die alternative Lösung eines Webserver-Rewrites, von dir selbst vorgeschlagen. Das Ganze kann daher in jeder Hinsicht problemlos in den Originalzustand zurückversetzt werden.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: teiling88 am 18. Februar 2017, 00:16:27
Es handelte sich nicht um einen Fehler sondern fehlerfreien Content. Den Fehler hat dann erst ein einzelner Entwickler eingebaut, indem er aus dogmatischen Erwägungen heraus Grafikdateien durch die Gegend geschubst hat, die niemandem weh getan hätten wenn sie da stehen geblieben wären.

Du kannst ruhig sagen das ich es war - ist auf github.com ja auch öffentlich einsehbar. Des Weiteren sind das keine dogmatischen Erwägungen sondern teil eines normalen Refaktorierungsprozesses. Würde man solche Punkte nicht anpassen hätte man nach einer gewissen Zeit X Verzeichnisse die man aus diversen gründen nicht löschen darf.

Würde man kein Refaktoring betreiben, was bis dato leider der Fall war (lib wurde nicht vollständig abgelöst, etc) entsteht daraus Legacy Code. Dieser wird mit der Zeit nicht mehr Erweiterbar geschweige vernünftig wartbar.

Zudem gibt es im konkreten Fall bereits - wie oben erwähnt - die alternative Lösung eines Webserver-Rewrites, von dir selbst vorgeschlagen. Das Ganze kann daher in jeder Hinsicht problemlos in den Originalzustand zurückversetzt werden.

Das wiederum ist eine Symptom Behandlung. Die Rewrite Regel habe ich auch _nur_ Vorgeschlagen für externe Inhalte die auf die Smilies verweisen. Bitte nicht aus dem Kontext heraus falsch zitieren.

Gruß
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: following am 18. Februar 2017, 00:51:07
@teiling88: (Du hast eine alte Version meines Postings zitiert, ich hatte es nochmal editiert was sich mit deiner Antwort überschnitt.)

Es gibt hier drei verschiedene technische Möglichkeiten, das Verfälschen des Contents zu vermeiden. Alle drei Möglichkeiten lehnst du deiner Darstellung nach ab, weil sie nicht in dein Lehrbuchverständnis von Softwareentwicklung passen - eben aus dogmatischen Gründen.

Mehrere Opencacher haben nun deutlich klargemacht, welcher Schaden hier für Opencaching.de droht. Aus dem gleichen Grund schreibe ich mir seit zwei Tagen die Finger wund. Interessiert dich alles nicht. Es muss mal wieder unbedingt so durchgezogen werden wie du es gewohnt bist und wie du es gelernt hast. Die Erfahrung eines OC-Teammitglieds, das schon länger Software entwickelt, als du auf dieser Welt bist, zählt da natürlich auch nichts ...
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: teiling88 am 18. Februar 2017, 07:28:01
Es gibt hier drei verschiedene technische Möglichkeiten, das Verfälschen des Contents zu vermeiden. Alle drei Möglichkeiten lehnst du deiner Darstellung nach ab, weil sie nicht in dein Lehrbuchverständnis von Softwareentwicklung passen - eben aus dogmatischen Gründen.

Ich lehne diese Gründe nicht alleine ab, verstehe es doch endlich das es 3 weitere Entwickler gibt die das gleiche Verständnis haben. Wir leben im Jahr 2017, ich kann hier zig namenhafte Personen zitieren wie Martin Fowler, Robert C. Martin  zitieren die dann genau so dogmatisch wären für dich. Es gibt gewisse Dinge auch in der Softwareentwicklung die haben sich nicht ohne Grund durchgesetzt. Des Weiteren hast Du auch fleißig Content "verfälsch" wenn HTML in Cache Beschreibungen etc nicht mehr korrekt war.

Mehrere Opencacher haben nun deutlich klargemacht, welcher Schaden hier für Opencaching.de droht. Aus dem gleichen Grund schreibe ich mir seit zwei Tagen die Finger wund. Interessiert dich alles nicht. Es muss mal wieder unbedingt so durchgezogen werden wie du es gewohnt bist und wie du es gelernt hast. Die Erfahrung eines OC-Teammitglieds, das schon länger Software entwickelt, als du auf dieser Welt bist, zählt da natürlich auch nichts ...

Peter Erfahrungen sind erst Recht in der Softwareentwicklung meistens nichts was von langer dauer ist. Diese Branche ist so schnelllebig da Dinge die man vor 3 Monaten gemacht hat schon heute überholt sind. Ich erinnere mich nur an Diskussionen um Coding-Standards, automatisiertes Testing usw. Man darf und kann sich in der Softwareentwicklung aktuellen Themen nicht verstellen, ansonsten sind die getätigten Erfahrungen sehr schnell wertlos. Objekt Orientierte Programmierung (OOP) hat sich nicht ohne Grund durchgesetzt, deine Einstellung dazu kann man hier wunderbar nachlesen: http://redmine.opencaching.de/issues/733

Zitat von: following
Das libse-Zeug ist ein kaum durchschaubarer Wust aus Abstraktionen; das ist durch ein paar Zeilen "straight PHP" bzw. eine Klasse für die persönlichen Notizen ersetzbar.

Wenn ich mich richtig erinnere unterstützt PHP 5.0.0 erstmalig ein vernünftiges OOP Konzept. Erschienen im Jahre 2004. Das man dann als erste Lösung eine Funktionale Umsetzung vorschlägt oder alles in eine Klasse zu packen was 1. allen best practices von OOP widerspricht und 2. Funktionaler Quellcode verschleiert in eine Klasse darstellt sagt für mich einiges aus. Das following ist für mich dogmatisch. Diese ganzen Prinzipien haben sich über die Jahrzente nicht umsonst durchgesetzt.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Jiver78 am 18. Februar 2017, 08:46:42
Es wird in Zukunft bestimmt noch öfters solche Fälle geben wo man alte Links reparieren/anpassen muss. Ist euch dann lieber das wir das Änderungsdatum dann nicht aktualisieren? Wie sollen wir damit umgehen?

Wenn ihr so etwas schon machen wollt, dann schreibt darunter Geändert am $datum durch das OC-Team.

Dies könnten wir nachträglich mit wenigem Aufwand umsetzen - wäre das eine Lösung?

Beispiel:
Das Oc-Team hat defekte Links repariert.

Gruß, Thomas

Wenn ich bei Wikipedia einen defekten Link repariere (weil z.B. die Quellen-pdf-Datei auf dem Zielserver umgezogen ist) werde ich automatisch zum Mitautor des Textes.
Für mein Verständnis sollte OC soetwas unterlassen. Einziger Bearbeiter des Listings muss der Owner sein und bleiben.

Mein Vorschlag: Nichts "reparieren", das im Listing steht.
Vergleichbar dazu: G$ hat vor einiger Zeit die Logs auf Markdown umgestellt. Ruf mal einen Deiner alten Log auf. Du wirst die alten Formatierungen vorfinden. Und diesen Infotext:
"Dein Logeintrag enthält HTML- oder UBB-Formatierungen. Wir benutzen jetzt Markdown-Formatierungen, denn die funktioniert sowohl fürs Internet als auch für Smartphones. Möchtest Du Deinen Logeintrag umwandeln?
 [Button Umwandeln]"

Analog dazu wäre (z.B. ebenfalls mit einen Info-Kasten, einem Pop-up, mit einer eMail) umsetzbar:
"OC hat im Rahmen der Neustrukturierung der Software auch die Verzeichnisstruktur verändert. Möchtest Du folgende, dadurch entstandene Konflikte in Deinem Log/Listing korrigieren?
- Verknüpfung zu den Smilie-Dateien (von http://alt zu http://neu)
- weitere Änderungen
[Button: Jetzt korrigieren]"

Damit lässt OC die Finger von den Listings, erlaubt dem Owner mit geringstmöglichen Aufwand eine Aktualisierung seiner Texte und es bleibt auch in Zukunft der Owner alleiniger Editor (und damit auch alleiniger Publisher) des Listings.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: mic@ am 18. Februar 2017, 09:06:01
Zitat von: Jiver78
Auch wenn oberflächlich alles (wieder) in Ordnung ist da der neue Link nun auf eine Datei gleichen Inhalts verweist wie der alte, es wurde ein Link und damit der Inhalt des Listings verändert.

Und das ist auch gut so.
Oder hättest Du es besser gefunden, daß der alte (nun nicht mehr funktionierende) Link weiterhin
in Deinem Log verbleibt? Ich jedenfalls kann keinen Schaden sehen, den die Link-Anpassung erzeugt hat.
Nochmal: Es wurde ein broken Link repariert, so daß der geänderte Logeintrag wieder genau so auussieht,
wie es vom Autor ursprünglich geschrieben wurde.

Erinnert sich noch jemand an den Wechsel bei GC von BB-Code zu Markdown?
Dort gab es den Wunsch, die durch den Wechsel kaputten Logformatiierungen wieder automatisch
zurückzudrehen, aber es wurde nicht vollzogen. Die User hatten dadurch also massenhaft falsch
formatierte Logs bekommen: http://jr849.de/allgemein/tschuss-logformatierung/
Insofern finde ich es persönlich gut, daß unsere Logs noch genauso aussehen wie vorher.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: FlashCool am 18. Februar 2017, 10:26:09
Zitat von: Jiver78
Auch wenn oberflächlich alles (wieder) in Ordnung ist da der neue Link nun auf eine Datei gleichen Inhalts verweist wie der alte, es wurde ein Link und damit der Inhalt des Listings verändert.

Und das ist auch gut so.
Oder hättest Du es besser gefunden, daß der alte (nun nicht mehr funktionierende) Link weiterhin
in Deinem Log verbleibt? Ich jedenfalls kann keinen Schaden sehen, den die Link-Anpassung erzeugt hat.
Nochmal: Es wurde ein broken Link repariert, so daß der geänderte Logeintrag wieder genau so auussieht,
wie es vom Autor ursprünglich geschrieben wurde.

Erinnert sich noch jemand an den Wechsel bei GC von BB-Code zu Markdown?
Dort gab es den Wunsch, die durch den Wechsel kaputten Logformatiierungen wieder automatisch
zurückzudrehen, aber es wurde nicht vollzogen. Die User hatten dadurch also massenhaft falsch
formatierte Logs bekommen: http://jr849.de/allgemein/tschuss-logformatierung/
Insofern finde ich es persönlich gut, daß unsere Logs noch genauso aussehen wie vorher.

Hallo mic@,

leider scheint es so, dass du den vorherigen Beitrag von Jiver78 nicht vollständig gelesen bzw. verstanden hast. Inhaltsänderungen am Listing sollten, egal wieviel Umfang sie haben, ausschließlich dem Owner obliegen. Eingriffe von OC sind da aus Urheberrechtlichen Gründen besorgniserregend. Auch die damaligen Korrekturen zum HTML-Code sind für mich nach nochmaliger Überlegung ein Fehler gewesen. Hier fehlte mir damals die zweite Sichtweise. Mea culpa.

Den Vorschlag für zukünftige Änderungen von Jiver78 halte ich für einen sehr guten und für den Benutzer einfachen Weg. Er ist verständlich und offen kommuniziert. Die Handhabe liegt beim Owner.

Beste Grüße
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: mic@ am 18. Februar 2017, 10:43:58
Zitat von: FlashCool
leider scheint es so, dass du den vorherigen Beitrag von Jiver78 nicht vollständig gelesen bzw. verstanden hast.

Keine voreiligen Schlüsse ziehen. Während ich mein Posting schrieb, hat Jiver78 parallel geschrieben.
Insofern kannte ich seinen Beitrag noch nicht, als ich meinen schrieb.


Zitat von: FlashCool
Inhaltsänderungen am Listing sollten, egal wieviel Umfang sie haben, ausschließlich dem Owner obliegen.

Und wo wurde nun der Inhalt geändert?
Der vorher vorhandene Smiley ist jetzt wieder da.
Ich sehe da KEINE Inhaltsänderung.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: FlashCool am 18. Februar 2017, 10:52:44
Zitat von: FlashCool
leider scheint es so, dass du den vorherigen Beitrag von Jiver78 nicht vollständig gelesen bzw. verstanden hast.

Keine voreiligen Schlüsse ziehen. Während ich mein Posting schrieb, hat Jiver78 parallel geschrieben.
Insofern kannte ich seinen Beitrag noch nicht, als ich meinen schrieb.


Zitat von: FlashCool
Inhaltsänderungen am Listing sollten, egal wieviel Umfang sie haben, ausschließlich dem Owner obliegen.

Und wo wurde nun der Inhalt geändert?
Der vorher vorhandene Smiley ist jetzt wieder da.
Ich sehe da KEINE Inhaltsänderung.

Lesen, verstehen, begreifen.

Es wurden Links zu Smilies in Listings und Logs geändert. Das beweist der angesprochene Datenbanktrigger. Ob das 'sichtbar' ist, spielt nach meinem Dafürhalten keine Rolle.

Vielleicht auch Entwicklertechnisch über den Schutz von Bestandsdaten und Abwärtskompatibilität nachdenken.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: mic@ am 18. Februar 2017, 11:03:16
Zitat von: FlashCool
Es wurden Links zu Smilies in Listings und Logs geändert. Das beweist der angesprochene Datenbanktrigger. Ob das 'sichtbar' ist, spielt nach meinem Dafürhalten keine Rolle.

Und genau da unterscheidet sich Deine Sichtweise von meiner.
Mir ist es schnuppe, welcher Link hinter einem Smiley steckt, Hauptsache ist, daß man den Smiley sehen kann.
Und wenn er durch serverseitige Aktionen nicht mehr vorhanden ist, dann freue ich mich, wenn der Smiley
wieder mit repariertem Link dargestellt wird und mein Inhalt wieder genauso aussieht wie vorher.

Oder um es mit anderen Worten zu sagen: Logs mit broken Links (Smileys) halte ich für unschön.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: FlashCool am 18. Februar 2017, 11:50:37
Zitat von: FlashCool
Es wurden Links zu Smilies in Listings und Logs geändert. Das beweist der angesprochene Datenbanktrigger. Ob das 'sichtbar' ist, spielt nach meinem Dafürhalten keine Rolle.

Und genau da unterscheidet sich Deine Sichtweise von meiner.
Mir ist es schnuppe, welcher Link hinter einem Smiley steckt, Hauptsache ist, daß man den Smiley sehen kann.
Und wenn er durch serverseitige Aktionen nicht mehr vorhanden ist, dann freue ich mich, wenn der Smiley
wieder mit repariertem Link dargestellt wird und mein Inhalt wieder genauso aussieht wie vorher.

Oder um es mit anderen Worten zu sagen: Logs mit broken Links (Smileys) halte ich für unschön.

Anzeigefehler halte ich auch für unschön, da bin ich bei Dir.

Nur: Wehret den Anfängen.

Jede Änderung am Owner-Inhalt und sei es "nur ein Zeichen" ist ein Eingriff dritter und verletzt nach meinem Dafürhalten Urheberrecht. Umstrukturierungen an der Basis müssen zwangsläufig vorgenommen werden, aber sollten diese nicht Manipulationen an Benutzerinhalten nach sich ziehen. Offene Kommunikation, was gemacht wurde und was der Owner im Nachgang machen sollte/kann ist der bessere Weg. Für den Nutzer ist es nicht ersichtlich, was sich geändert hat - "im schlimmsten Fall"' mal weiter gesponnen, hat sich doch inhaltlich etwas geändert.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Jiver78 am 18. Februar 2017, 12:25:41
Oder um es mit anderen Worten zu sagen: Logs mit broken Links (Smileys) halte ich für unschön.

Da sind wir einer Meinung.
Nur hat das Ästhetik-Gefühl hier kein Wort mitzureden. Es hat sich nicht einmal zu räuspern.

Oder werden zukünftig durch OC Bild-Verlinkungen korrigiert, weil z.B. auf Wiki-Commons die Datei umbenannt wurde?
Rechtschreib- und Grammatikfehler zukünftig korrigert? Die hässlichen Deppen-Apostrophe gibt's ja zur Genüge in Cachetiteln. Die halte ich für mindestens genauso unschön.
Also einfach mal ne Rechtschreibprüfung drüber laufen lassen? Die wird sicher auch bei meinen Listings und Logs fündig.

OC sollte sich folgende Frage stellen:
Ist OC (Mit-)Inhaber der Listings (was sich in den Nutzerbedingungen ja abbilden ließe)?
Falls ja: dann gehen Eingriffe ins Listing in Ordnung. Dann ist aber OC auch mitverantwortlich für die Listings und deren inhaltliche Richtigkeit (siehe meinen allerersten Post in diesem Thema).
Falls nein: dann hat OC auch von jedem noch so kleinen Fehler in Listings die Finger zu lassen. Auch wenn sie OC indirekt selbst verbockt hat.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: teiling88 am 18. Februar 2017, 12:28:05
Offene Kommunikation, was gemacht wurde und was der Owner im Nachgang machen sollte/kann ist der bessere Weg. Für den Nutzer ist es nicht ersichtlich, was sich geändert hat - "im schlimmsten Fall"' mal weiter gesponnen, hat sich doch inhaltlich etwas geändert.

Die Kommunikation diesbezüglich war auch anders geplant. Leider ist es nun mal so geschehen das es direkt ins Forum gepostet wurde.

Wir werden dies bei einer nächsten ggf. notwendigen Änderung berücksichtigen und diesbezüglich anders Kommunizieren. Ich würde dies gerne unter "Lektion gelernt" abhaken. Ihr wisst warum wir das Ganze machen und wir wissen nun wie ihr euch die Kommunikation wünscht.

Gruß, Thomas
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Samsung1 am 19. Februar 2017, 18:51:25
Offene Kommunikation, was gemacht wurde und was der Owner im Nachgang machen sollte/kann ist der bessere Weg. Für den Nutzer ist es nicht ersichtlich, was sich geändert hat - "im schlimmsten Fall"' mal weiter gesponnen, hat sich doch inhaltlich etwas geändert.

Die Kommunikation diesbezüglich war auch anders geplant. Leider ist es nun mal so geschehen das es direkt ins Forum gepostet wurde.

Ich denke, so etwas sollte kommuniziert werden, bevor gehandelt wird.
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: Siggiiiiii am 01. Mai 2017, 20:47:45
Zur Erklärung für diejenigen, die was von Softwareentwicklung verstehen (die anderen bitte ignorieren):
  • Das Ein Verzeichnis, in dem die Smiley-Grafiken liegen, wurde verschoben. Dadurch waren Smileys in vorhandenen Logs und Cachbeschreibungen defekt.
----- snip--- Siggi---

Konsolidiert Ihr die unterschiedlichen historisch gewachsenen Ordner mit tlw. redundanten Irons/Grafiken?
Titel: Re: Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
Beitrag von: teiling88 am 01. Mai 2017, 22:06:35
Konsolidiert Ihr die unterschiedlichen historisch gewachsenen Ordner mit tlw. redundanten Irons/Grafiken?

Das war der Beweggrund - ja.