Planung Release 0.8.1

[Chris M.]

Zwischen SVN und Release besteht ein feiner Unterschied:

• Bei SVN werden lauter Einzel-Dateien geladen und in der Reihenfole abgearbeitet. Insb. dazwischen läuft die Event-Loop, d.h. angestaute, asynchrone Kommandos werden ausgeführt.
• Beim Release wird alles in eine Datei kopiert (und die minimiert, was hier aber hoffentlich keinen Unterschied macht) - und folglich in einem Rutsch ausgeführt.

Ohne ein (Test-)Release zu machen, kann man das leider nicht testen. Und eigentlich ist extra ein Mechanismus drinnen der nach dem Abarbeiten noch einmal auf die Start-Seite wechseln soll (was genau solche Probleme verhindern sollte)


=> Wenn das jemand debuggen möchte, inzwischen sollte beim Release auch die nicht-minimierte Source-Datei mit dabei sein, d.h. einfach mal beide vertauschen und dann testen, bzw. optimieren.
(Ich fürchte ich komme die nächsten Tage nicht dazu - und einen Safari hab ich auch nicht)

[Tqm]

Wenn Du mitr noch verrätst wo ich die nicht-minimierte Source-Datei finde teste ich das mal ...

(Problem tritt mit dem Safari am Macbook (7.0.1) als auch am iPad(iOS 7.0.4) auf)

[Chris M.]

Ah, sorry, manchmal denke ich dass Dinge klar sind - was sie aber einfach nicht sind

Im Ordner /release/structure/ liegt die Monster-JavaScript-Datei, bei dem Release 0.8.1 mit dem Namen pure.20140208-172225.js
Die Nicht-Minimierte Version liegt genau daneben und heißt pure.20140208-172225.raw.js
(Bei anderen Versionen ist einfach der Zeitstempel im Namen anders)

Um nun auf die andere (also die Nicht-Minimierte) Datei umzuschalten musst Du folglich nur:

• /release/index.html - den Link auf die JS-Datei abändern, d.h. das raw einbauen
• /release/cometvisu.appchache - irgendwie ändern, z.B. oben beim Zeitstempel um die neue index.html laden zu lassen

[Tqm]

also einfach nur umschalten auf die pure.20140208-172225.raw.js bringt keine Änderung ...
...für mehr mangelt es am Wissen.
Aber wenn ich irgendwie unterstützen kann - gerne!

[Chris M.]

Ne, vom Verhalten sollte das keine Änderung bringen (kann man zwar nie ausschließen, genau so wenig wie einen Compiler-Fehler - aber die Auftritts-Wahrscheinlichkeit ist halt ähnlich gering)

Was das aber bringt, ist dass man eine Chance hat das andere Verhalten zu debugen und zu optimieren.

Hier sollte man übrigens auch voran kommen, wenn man noch nicht viel JavaScript-Erfahrung hat. Man braucht (als aktueller Nicht-CV-Entwickler) eher die Bereitschaft und Fähigkeit sich nicht durch einen großen komplexen Block (den Code...) abschrecken zu lassen und mit kleinen, gezielten Maßnahmen an Ziel kommen zu wollen.
D.h. der Erfolg wird hier von der Persönlichkeit und nicht zwingend vom Vorwissen abhängen.