Wo eigentlich ANFANGEN mit der Entstörung?
|
Seite 1 von 88
neuester Beitrag: 22.05.12 19:50
|
||||
| eröffnet am: | 07.06.09 12:57 von: | Teras | Anzahl Beiträge: | 2193 |
| neuester Beitrag: | 22.05.12 19:50 von: | Teras | Leser gesamt: | 46287 |
| davon Heute: | 95 | |||
| bewertet mit 87 Sternen |
||||
|
|
||||
|
--button_text--
interessant
|
|
witzig
|
|
gut analysiert
|
|
informativ
|
87
07.06.09 12:57
Krise wurde allzu oft nicht als CHANCE begriffen; mit dem Ergebnis, dass heute keiner mehr sagen kann, seit WANN es nur noch eine BANK http://www.ariva.de/quote/...urse.m?branche_id=101&herkunft_id=-1 gibt und seit WANN denn nun nur noch drei http://www.ariva.de/quote/...rse.m?branche_id=5000&herkunft_id=-1 HEDGE-Fonds. - Unzählige "verlorene" Graphiken lassen sich immerhin noch DATIEREN, da ja der entsprechende Link vielerorts noch im System steht, was aber offenbar niemanden veranlasst, das ohne Moderation Ausgeblendete bitteschön wieder sichtbar zu machen.
Was wir derzeit beobachten müssen, ist eine Unterlassung notwendiger Arbeit und eine Zerstörung bereits geleisteter Arbeit. - Unzählige in mühsamer Kleinarbeit gefertigte und mit ARIVA abgesprochene Plaquetten sind durch actives Zutun noch immer verschrumpelt, manche bis zur Unlesbarkeit. - Und weil offenbar keine ENTSTÖRUNGS-Kladde führt wird, in welcher getätigte Entstörungen protocolliert und nach-beobachtet werden, sind wir seit Monaten des seltsamen Schauspieles ansichtig, dass eine Actie, die niemals in €uro quotiert worden ist, hier bei uns auf ARIVA 'mal in €uro geben wird, dann wieder in DEMark, dann wieder in €uro... - Arbeits-Beschaffungsmaßnahme ad infinitum.
Zerschrumpelte LOGOs, trotz nicht vorhandener CURS-Bewegungen wie wild in der Gegend herumspringende CHARTs, verlorene GRAPHIKen, die eigentlich nicht verloren sein müssten, gekappte VOLUMINA, zerschliffene SPREADs, deren Differenz von 0,10 auf 0,11 in ein und derselben Actie an ein und demselben Tage 'mal ZEHN und dann wieder NULL Procent ausmachen soll - irgendwann REICHT es!
Als ARIVA-Users sind wir ja treu. - Doch wenn wir immer neue Zumutungen ertragen müssen; nur, um ARIVA weiter die Treue halten zu können, dann wird es kritisch. - Wir wollen jetzt nicht mehr weiter zurück. - Und deshalb gehen wir jetzt gemeinsam nach VORNE.
Die Debatte ist eröffnet. - Liebe Grüße vom Teras.
Optionen
7
16.05.12 17:42
wie auch die im Beitrag #2108 www.ariva.de/forum/BackSlash-Error-Teil-2-378449?page=84#jumppos2108 documentierte, REDUPLICATIVE Eigenschaft dieses INSERTION-Error's streng genommen auch durch MANUELLES Setzen von BackSlashs hätte hervorgebracht worden sein können,
habe ich diese lediglich MÖGLICHE Annahme im Beitrag #2109 dann Vorsichts-halber
www.ariva.de/forum/BackSlash-Error-Teil-3-378449?page=84#jumppos2109 falsificiert, indem ich dort einen SCREEN-Shot angehängt habe, der vom BackSlash-Error förmlich DURCHSETZT ist, wodurch die Unwahrscheinlichkeit seiner absichtlichen Hervorbringung documentiert worden ist:
Optionen
Angehängte Grafik:
2012-05-10-fehlende-user-triggerung-in-no-2109.gif (verkleinert auf 92%)
2012-05-10-fehlende-user-triggerung-in-no-2109.gif (verkleinert auf 92%)
7
16.05.12 18:01
Wer hat dazu Vorschläge? - Jede actuelle Fehler-Documentierung geht hier jederzeit absolut VOR, da die Entstörungs-systematischen Darlegungen zwar nicht weniger wichtig, wohl aber auf LÄNGER-fristige Verbesserung angelegt sind, wodurch sie,
rein ZEITLICH betrachtet, ganz eindeutig NACHRANGIG sind...
Optionen
5
16.05.12 19:31
Das sehe ich in dem direct darauf folgenden Beitrag #2163 www.ariva.de/forum/Zur-Beitrags-Nummer-2162-378449?page=86#jumppos2163 auch BESTÄTIGT, da dieser einen per LINK-Einfügen-Function erzeugten URL (Uniform Resource Locator) enthält, der alles Andere als "UNIFORM" ist, da er eine fette Standard-Abweichung aufweist!
Der CONCRETE Fehler besteht hier darin, dass der CORRECTE Resource-Locator http://www.spiegel.de/sport/fussball/...una-duesseldorf-a-833427.html auf http://www.spiegel.de/sport/fussball/...duesseldorf-a-833427.html%20 verändert wurde, wodurch er nicht mehr durchclickbar ist, sondern Zwangs-läufig auf den "Error 404" auflaufen muss (vergleiche hierzu auch das PHOTO).
Die Frage, die jetzt hierzu im Raum steht, ist ganz klar diese: Wie war es überhaupt MÖGLICH, ein als "%20" hindurch-masquiertes Anhängsel per LINK-Einfügen an einen ursprünglichen URL anzuhängen, obwohl eine CORRECTE Link-Einfügen-Function eine solche Aus-Commentierung als ANHÄNGSEL doch gar nicht ZULASSEN darf?
Optionen
Angehängte Grafik:
2012-05-16-masquiertes-suffix-wird-nicht-....gif
2012-05-16-masquiertes-suffix-wird-nicht-....gif
6
17.05.12 02:14
Mir geht es bei der Entwicklung in erster Linie auch um die Stabilität und Funktionalität der Anwendung. Sobald die Software mit allen Schnittstellen halbwegs stabil läuft, kommen neue Features vom Kunden. Da es jedoch eine hohe Entwickler-Fluktuationsrate gibt, haben in der Zwischenzeit mindestens fünf Entwickler ihre Spuren im Code hinterlassen. Dies habe ich gerade auch mal wieder bei Anbindung/Verschmelzung einer "alten" Software-Komponente mit der neuen Architektur feststellen müssen. Ich war heilfroh, dass alle Funktionalitäten der Anwendung mit den Backend-Systemen (Host, Oracle) laufen und dann kamen Bugs welche im "alten" Modul repariert werden mussten.
Nun kommen wir zur Kausalität in der Software-Entwicklung. Ich passe also den Code der "alten" Welt an den aktuellen Requirements an. Meine Entwicklertests sind auch erfolgreich. Eine Woche später meldet sich jedoch "QS-X", dass der Direkteinstieg mit Parameter "X,Y,Z" aus Komponente "A" nicht mehr funzt. So, ich hatte nur die Schnittstelle und die Businesslogik erweitert. Aber dass zur Laufzeit Variablen von außen verändert/manipuliert werden, war weder konzipiert noch dokumentiert...
Was ich aber auch zum Ausdruck bringen möchte ist, dass penible Ariva-Anwender GOLDwert sind...
PS: Wie unter Software-Entwicklern gemunkelt wird, liegt die Wahrheit im Code und nicht im Konzept ;)
5
17.05.12 07:00
Und wenn dann auch noch so genannte SALES-People dabei involviert sind, dann wird es gaaanz kritisch, und zwar auch wieder im DOPPELTEN Sinne:
Der Kunde kann den größten Schwachsinn fordern; spätestens aber dann, wenn er sich dazu versteigt, dass der von ihm gewünschte, ungenießbare Wunsch-Salat ja doch tatsächlich ein CONCEPT sei, schon wiehert der dümmliche Verkäufer-Spruch durch die Hallen: "Kein Problem, kein Problem - Alles ganz wirklich gar kein Problem!"
Dabei sind doch selbst GÜLTIGE Requirements, die dann im Rahmen gültiger Concepte auch UMGESETZT werden können, wohl ganz eindeutig ein PROBLEM!
Denn wenn der Kunde angeblich "gar kein Problem" hat, wieso muss er dann zu irgend Wem gehen, der ihm dies' Problem hoffentlich LÖST?
Optionen
5
5
17.05.12 21:00
Ganz liebe Grüße!
Der olle Teras.
Optionen
3
18.05.12 08:45
Bei meiner Meldung betr. REALTIME kann ich nach wie vor keine Besserung feststellen. Meine Höchst-Niedrigstkurse kann ich immer noch nicht ändern!
-----------
Meine Forderung: Stabiler Server und Entfernung ALLER Bilder, weil sie nur vom Text ablenken.
Meine Forderung: Stabiler Server und Entfernung ALLER Bilder, weil sie nur vom Text ablenken.
Optionen
3
18.05.12 08:59
ABER, die Änderungen in der REALTIME-Liste sind immer noch nicht möglich!
-----------
Meine Forderung: Stabiler Server und Entfernung ALLER Bilder, weil sie nur vom Text ablenken.
Meine Forderung: Stabiler Server und Entfernung ALLER Bilder, weil sie nur vom Text ablenken.
Optionen
6
5
5
18.05.12 17:20
http://www.kitcosilver.com/charts/24hoursspot.html
Optionen
Angehängte Grafik:
2012-05-18-und-hier-jetzt-mal-ein-gueltiger-chart.gif (verkleinert auf 92%)
2012-05-18-und-hier-jetzt-mal-ein-gueltiger-chart.gif (verkleinert auf 92%)
6
5
5
19.05.12 04:00
Bei sehr vielen Werten klappt diese Anzeige auch ganz vorzüglich, und zwar ohne das nervende Hin- und Her-Springen zwischen voll relevanten Börsen und denen eher irrelevanten Pseudo-Börsen als Referenz der jeweiligen Performance-Angabe.
Beim Thread www.ariva.de/forum/Quo-Vadis-Dax-2012-Krise-ohne-Ende-456414
klappt das aber eindeutig noch NICHT; und das, OBWOHL die BASIS dieser nützlichen Performance-Anzeige in Form des bei Thread-Eröffnung antreffbaren CURSES dort ganz eindeutig hinterlegt ist (vergleiche das PHOTO):
Optionen
Angehängte Grafik:
2012-05-19-keine-performance-seit-threadbeginn.gif (verkleinert auf 94%)
2012-05-19-keine-performance-seit-threadbeginn.gif (verkleinert auf 94%)
6
19.05.12 06:35
Dennoch ist hier bei uns 1 Ounce / 1 Unce SILBER angeblich auf 1 U$-Dollar gefallen:
http://www.ariva.de/silber-kurs/...se?month=2012-05-31&secu=38823
Hat uns hier ein Börsen-ferner Geselle
den NOMINAL-Wert des "Silver Eagle" mit dessen actuellem CURS-Wert verwechselt?
Optionen
Angehängte Grafik:
2012-05-18-ist-das-nominal-wert-statt-curs-wert.gif
2012-05-18-ist-das-nominal-wert-statt-curs-wert.gif
4
5
20.05.12 19:56
ENTSTÖRUNGS-Hinweis: Bitte einfach den BRIEF
"Dear Sir/Madam, LEISURE Shoppers Inc. is seeking Secret Shoppers to shop and get paid. You will be paid for what you love doing at your leisure hours. We are currently hiring members now. This is 100% free with no strings attached to it. You can get paid for driving your car, get paid for eating at restuarant. You can get paid for doing most things you love to do"...
mitnehmen und dann flugs beim
EUROPEAN COMMUNITIES COUNCIL FOR JOB APPOINTMENTS/LEISURE HIRING
c/o European Commission
B-1049 Brussels
Belgium
nachfragen, wo denn jetzt die CURSE bleiben!
Optionen
Angehängte Grafik:
2012-05-20-leisure-shoppers-inc-noch-ohne-curse.gif
2012-05-20-leisure-shoppers-inc-noch-ohne-curse.gif
4
21.05.12 02:20
Open-TAG-Probleme sind das immer wieder gern angeführte Parade-Beispiel für einen INSERTION-Error, und zwar für einen meist USER-inducierten Insertion-Error, der vom SYSTEM-inducierten Insertion-Error, wie er zum Beispiel an Hand des BackSlash-Error's ab dem Beitrag #2107 www.ariva.de/forum/Hallo-ARIVA-Ist-378449?page=84#jumppos2107 documentiert werden konnte, klar zu unterscheiden ist...
Deshalb wurde ja auch direct im Anschluss an die Documentierung des NICHT User-inducierten, reduplicativen BackSlash-Error's contrastierend schon im Beitrag #2111
www.ariva.de/forum/ZEIT-Druck-als-Feind-378449?page=84#jumppos2111 erneut an den USER-inducierten Open-TAG-Error erinnert.
Der wird nämlich meist von zur Gemüths-Aufwallung neigenden Users verursacht, denen erst einige Postings später dann auffällt, WAS sie mit ihrer Taggeritis eigentlich vor Allem hatten "herausstellen" wollen (womit wohl eine Hervorhebung gemeint wesen ist)...
Dennoch bleibt es Aufgabe der PLATTFORM-Entstörung, OPEN Tags am ENDE solcher Chaos-Beiträge SYSTEM-seitig - bevorzugt AUTOMATISCH! - jeweils zu SCHLIEßEN,
damit sich solch' ungeordnetes Denken nicht über die Folge-Beiträge ergießt:
www.ariva.de/forum/Vor-allem-463680?page=9#jumppos230
Doch hat das ARIVA-Team bislang keine MUßE zur Entwicklung eines solchen automatischen TAG-Schließers gefunden, womit wir wiederum beim PROCESS-schädlichen ZEIT-Druck angelangt wären, der am heutigen Montag ab 9:30 Uhr
HIER www.ariva.de/forum/RfC-1-Grober-RAHMEN-456432?page=0#jumppos14
in RUHE discutiert werden soll.
Optionen
Angehängte Grafik:
2012-05-20-nochmals-zur-open-tag-problematik.gif (verkleinert auf 92%)
2012-05-20-nochmals-zur-open-tag-problematik.gif (verkleinert auf 92%)
6
21.05.12 04:50
Dass das aber völliger QUATSCH ist, haben die sich selbst so nennenden Acausalen Entstörer als ein sehr wichtiges Ergebnis ihrer Untersuchung des ChatterBot's A.L.I.C.E. (Artificial Linguistic Internet Computer Entity) doch schon vor Jahren herausgefunden.
WIE lange hat es nochmal gedauert, bis der Zweifels-ohne GENIALE Entwickler Richard S. WALLACE seiner ALICE wenigstens den correcten PLURAL eingebläut hatte? - Von da an war ziemlich klar, dass GENIALE Entwickler - also genau jene ERUPTIV-Créativen, von denen man sagt, dass sie "keine 'burnt Tracks' kennen" - zwar weiterhin als die productivsten Entwickler angeseh'n werden können (solange ihre Serie nicht bricht); doch sollte man die 'burnt Tracks' zumindest WAHR-nehmen, da sich sonst der Objectivismus nicht einstellen kann, den man zum ENTSTÖREN zwingend BENÖTIGT.
Bleiben also noch die guten bis sehr guten Entwickler, von denen einige auch entstören können; also genau jene Entwickler, von denen man sagt, dass sie ihre 'burnt Tracks' nicht zu spüren scheinen, sie sich an ihnen jeden Falles nicht sonderlich STÖREN. - Und das ist im Falle der ENTWICKLUNG auch völlig CORRECT so! - Denn die ENTWICKLUNG, die ja etwas NEUES hervorbringt (oder hervorbringen SOLL), schreitet meist auf jenen Wegen voran, die eben noch nicht verbrannt worden sind; die 'burnt Tracks' erledigen sich in der Entwicklung also meistens von SELBER...
(Teil 2 folgt).
Optionen
5
21.05.12 05:30
Jeder 'burnt Track' in der Entstörung VERSTETIGT den Fehler. - Und wenn dann die 'burnt Tracks' gar nicht WAHR-genommen würden? - Dann passiert in der Entstörung etwas, was in der Entwicklung so NICHT passiert: Die Entstörung entgleitet als Ganzes.
Das wissen natürlich jene Entwickler, die auch zum ENTSTÖRER taugen. - Und noch etwas wissen sie: In der Entstörung muss man die 'burnt Tracks' nicht nur WAHR-nehmen, man muss sie Vorsichts-halber ALLE als einen ZUSÄTZLICHEN Fehler begreifen, der gegebenen Falles der SEPARATEN Entstörung bedarf. - Tut man das NICHT, dann ist die Gefahr viel zu groß, dass sich der ursprüngliche Fehler nicht nur VERSTETIGT, sondern obendrein noch VERBREITERT.
Hieraus ergibt sich, dass ein in die ENTSTÖRUNG geschickter Entwickler jeweils UMDENKEN muss. - Und geht es wieder zurück in die ENTWICKLUNG, dann muss er wiederum UMDENKEN; täte er das NICHT, dann wäre er als ENTWICKLER in seiner dortigen Productivität sehr schnell gemindert.
Und dieses jeweilige Umdenken bezüglich derer 'burnt Tracks' ist mit einer gewissen ANSTRENGUNG verbunden, und es kostet natürlich auch seine jeweilige ZEIT.
Und obwohl das eigentlich vollkommen KLAR ist, habe ich dennoch den Eindruck, dass unsere von der ENTWICKLUNG (tic) in die ENTSTÖRUNG (toc) geschickten Entwickler ohne Pause tic-toc-tic-toc, tic-toc-tic-toc hin und her springen müssen, an Statt ihnen einen viel gesünderen Rhythmus wie zum Beispiel tic-tic-tic-tic, toc-toc-toc-toc zu gestatten...
Wir werden das in RUHE besprechen.
Optionen
5
21.05.12 07:00
Die Spuren-Suche im ENGEREN Sinne verfolgt den als einen FEHLER erkannten ERROR möglichst weit im Zeit-Strahl ZURÜCK. - Diese Spuren-Suche im ENGEREN Sinne orientiert sich also in Richtung auf die jeweilige QUELLE, die ja trocken gelegt werden soll.
Die Spuren-Suche im WEITEREN Sinne hingegen verfolgt den ERROR ab seiner ersten Manifestation als ein FEHLER bis in alle Schad-Stellen HINEIN, wo er sich zeigt. - Diese Spuren-Suche im WEITEREN Sinne orientiert sich also in Richtung auf die VERBREITUNG des Fehlers, der ja eliminiert werden soll.
Die Spuren-Suche im WEITEREN Sinne ist oft leichter und schneller zu bewerkstelligen als die Spuren-Suche im ENGEREN Sinne, die ja in Bereiche ZURÜCK-stößt, in welchen der ERROR noch gar nicht als ein FEHLER erkannt war. Deshalb wird die ENGERE Suche (nicht nur auf ARIVA!) ja auch öfters schlichtweg "geschlabbert" oder "vergessen"...
Deshalb war es völlig correct, am 21.10. im Jahre 2010 per Beitrag #691 www.ariva.de/forum/Die-Spuren-Suche-378449?page=27#jumppos691
um die nötige ZEIT für die ENGERE Spuren-Suche zu bitten, deren Erfordernis im dortigen Beitrag leicht nachvollziehbar dargelegt worden ist.
Gleichwohl hat die verfügbare Zeit nicht einmal dazu gereicht, die WEITERE Spuren-Suche (Suche nur nach dem FEHLER, nicht nach dem ERROR) zu einem geordneten Abschluss zu bringen: http://www.ariva.de/quote/profile.m?secu=918119
Optionen
Angehängte Grafik:
2012-05-21-spuren-suche-noch-nicht-beendet.gif (verkleinert auf 96%)
2012-05-21-spuren-suche-noch-nicht-beendet.gif (verkleinert auf 96%)
4
4
1
22.05.12 19:50
Wird das in der Hektik vergessen, dann kann es zu einer ganzen Batterie von Erratiken kommen, zu welchen, wie im vorliegenden Falle, auch der SYSTEM-seitig inducierte INSERTION-Error gehört: Der auf eine solche Nicht-Geschlossenheit treffende User kann dann - zum Beispiel - nicht POSTEN.
Der Entwickler, dem dieser Schnitzer heute aus Zeit-Druck passiert ist, war jeden Falles zum Objectivismus, also auch zur Entstörung, befähigt.
Und innerhalb von knapp 3 Minuten war das Thema erledigt:
Optionen
Angehängte Grafik:
2012-05-22-string-constante-nicht-terminiert.gif (verkleinert auf 92%)
2012-05-22-string-constante-nicht-terminiert.gif (verkleinert auf 92%)
