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
Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?
-
ClanFamily (Mirco)
- Administrator
- Beiträge: 1412
- Registriert: 03.09.2012, 21:55
-
following
[quote="ClanFamily (Mirco)"]
PS: Following ist mit Beschluss der Jahreshauptversammlung 2016 aus Gründen nicht mehr Teil dieses Team und kann dies bis heute nicht akzeptieren.
[/quote]
Auf diesen Unsinn habe ich [url=http://forum.opencaching.de/http://localhost//viewtopic.php?t=1]hier[/url] geantwortet.
PS: Following ist mit Beschluss der Jahreshauptversammlung 2016 aus Gründen nicht mehr Teil dieses Team und kann dies bis heute nicht akzeptieren.
[/quote]
Auf diesen Unsinn habe ich [url=http://forum.opencaching.de/http://localhost//viewtopic.php?t=1]hier[/url] geantwortet.
[quote="ClanFamily (Mirco)"]
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
[/quote]
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.
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
[/quote]
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.
[quote="ClanFamily (Mirco)"]Auch in diesem Fall veränderten wir keinen Inhalt [...][/quote]
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.
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.
[quote="following"]
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.
[/quote]
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.
[quote="following"]
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.
[/quote]
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?
[quote="Samsung1"]
Wenn ihr so etwas schon machen wollt, dann schreibt darunter Geändert am $datum durch das OC-Team.
[/quote]
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 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.
[/quote]
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.
[quote="following"]
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.
[/quote]
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?
[quote="Samsung1"]
Wenn ihr so etwas schon machen wollt, dann schreibt darunter Geändert am $datum durch das OC-Team.
[/quote]
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
-
following
[quote="teiling88"]
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.
[/quote]
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 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.
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.
[/quote]
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 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.
Zuletzt geändert von following am 18.02.2017, 00:14, insgesamt 1-mal geändert.
[quote="following"]
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.[/quote]
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.
[quote="following"]
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.
[/quote]
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ß
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.[/quote]
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.
[quote="following"]
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.
[/quote]
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ß
-
following
@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 ...
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 ...
[quote="following"]
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.
[/quote]
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.
[quote="following"]
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 ...
[/quote]
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
[quote="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.
[/quote]
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.
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.
[/quote]
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.
[quote="following"]
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 ...
[/quote]
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
[quote="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.
[/quote]
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.
[quote="teiling88"]
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?
[quote="Samsung1"]
Wenn ihr so etwas schon machen wollt, dann schreibt darunter Geändert am $datum durch das OC-Team.
[/quote]
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
[/quote]
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.
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?
[quote="Samsung1"]
Wenn ihr so etwas schon machen wollt, dann schreibt darunter Geändert am $datum durch das OC-Team.
[/quote]
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
[/quote]
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.
[quote="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.[/quote]
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.
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.
[quote="mic@"]
[quote="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.[/quote]
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.
[/quote]
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
[quote="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.[/quote]
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.
[/quote]
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
[quote="FlashCool"]leider scheint es so, dass du den vorherigen Beitrag von Jiver78 nicht vollständig gelesen bzw. verstanden hast.[/quote]
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.
[quote="FlashCool"]Inhaltsänderungen am Listing sollten, egal wieviel Umfang sie haben, ausschließlich dem Owner obliegen.[/quote]
Und wo wurde nun der Inhalt geändert?
Der vorher vorhandene Smiley ist jetzt wieder da.
Ich sehe da KEINE Inhaltsänderung.
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.
[quote="FlashCool"]Inhaltsänderungen am Listing sollten, egal wieviel Umfang sie haben, ausschließlich dem Owner obliegen.[/quote]
Und wo wurde nun der Inhalt geändert?
Der vorher vorhandene Smiley ist jetzt wieder da.
Ich sehe da KEINE Inhaltsänderung.
[quote="mic@"]
[quote="FlashCool"]leider scheint es so, dass du den vorherigen Beitrag von Jiver78 nicht vollständig gelesen bzw. verstanden hast.[/quote]
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.
[quote="FlashCool"]Inhaltsänderungen am Listing sollten, egal wieviel Umfang sie haben, ausschließlich dem Owner obliegen.[/quote]
Und wo wurde nun der Inhalt geändert?
Der vorher vorhandene Smiley ist jetzt wieder da.
Ich sehe da KEINE Inhaltsänderung.
[/quote]
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.
[quote="FlashCool"]leider scheint es so, dass du den vorherigen Beitrag von Jiver78 nicht vollständig gelesen bzw. verstanden hast.[/quote]
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.
[quote="FlashCool"]Inhaltsänderungen am Listing sollten, egal wieviel Umfang sie haben, ausschließlich dem Owner obliegen.[/quote]
Und wo wurde nun der Inhalt geändert?
Der vorher vorhandene Smiley ist jetzt wieder da.
Ich sehe da KEINE Inhaltsänderung.
[/quote]
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.
[quote="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.[/quote]
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.
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.