CometVisu - (interner) Beta-Test

[vento66]

Das sind doch ideale vorraussetzungen
Sooo gefährlich ist ein svn-checkout jetzt auch nicht, das maximale was passieren kann, ist das irgendwo ein paar sinnlose Files rumliegen.

Naja da sind schon ein paar Befehle zu ergooglen... Wenn da einer Mist baut kann ich nicht mal nachvollziehen warum ich die ganze Partition mit Müll vollgeschrieben hab



Sent from my iPhone using Tapatalk

[makki]

Aber wie soll auch einer der keine Ahnung hat ne Anleitung schreiben?

Das sind doch ideale vorraussetzungen
Sooo gefährlich ist ein svn-checkout jetzt auch nicht, das maximale was passieren kann, ist das irgendwo ein paar sinnlose Files rumliegen..

jsmin tut wohl (hat aber hat natürlich limitierten Effekt)
yui-compressor schrottet alles (Ok, das hätte ich vorher auch wissen können, ist ja schliesslich in Java geschrieben, also ein Standardfeature )
cc schaue ich mir jetzt noch an.

Beim jquery fühle ich mich nach diesen Tests wohler, lieber die "offizielle" minified-Version zu nehmen; bei den eigenen js tuts glaube ich auch erstmal die schmalspur-Variante ohne Variablennamen etc. vollständig zu obfuscaten

Makki

[vento66]

(Falls ich Dich dort noch freischalten muss, sag mir einfach Deinen SourceForge-Account Namen)

Nun ja so schwer ist der glaub ich nicht zu erraten: laugh: ist der selbe wie hier.




Sent from my iPhone using Tapatalk

[Chris M.]

@Chris zumindest hab ich das so gemacht, falls etwas nicht ganz richtig sein sollte sag einfach Bescheid, bevor der Artikel ins Wiki kommt

Sieht gut aus, jetzt muss der nur noch nach:
https://sourceforge.net/apps/mediawi...edit&redlink=1
Sollte es dann noch Verbesserungen geben, kann man das dort wunderbar nachträglich verbessern, ist ja schließlich ein Wiki
(Falls ich Dich dort noch freischalten muss, sag mir einfach Deinen SourceForge-Account Namen)

Ich würde vielleicht den Vorgang geringfügig anpassen - damit kann man dann updates schneller ziehen:

Das hätte ich auch noch vorgeschlagen - aber so kann ich nur sagen dass das passt

Aber wie soll auch einer der keine Ahnung hat ne Anleitung schreiben?

Das ist genau der Hintergrund: jemand der so was täglich macht, hat Schwierigkeiten ein HowTo zu schreiben, das genau auf die Schwierigkeiten eingeht, die ein Anfänger hat - betriebsblind halt. Und genau deswegen warst Du die perfekte Person für den Job

[vento66]

OK ich habs mal angepasst!

Aber wie soll auch einer der keine Ahnung hat ne Anleitung schreiben? Ich war schon froh das das überhaupt ohne grösseren Schaden am WG funktioniert.
(OK ein Image vom CF hab ich schon vorher gemacht )

[netzkind]

Ich würde vielleicht den Vorgang geringfügig anpassen - damit kann man dann updates schneller ziehen:

cd /var/www
svn co https://openautomation.svn.sourceforge.net/svnroot/openautomation/CometVisu/trunk/visu/ visu_svn

Dadurch spart man sich mkdir, cp, und man hat nicht die SVN-Daten im root-Verzeichnis liege.

Und: wenn es was neues im SVN gibt, macht man einfach:

cd /var/www/visu_svn/
svn update

Das funktioniert natürlich nur so lange bis sich im SVN mal die Verzeichnisstruktur ändert - aber das kann man ja dann entsprechend kommunizieren, und svn relocate machen.

Grüße,
Julian

[vento66]

So nach dem ich ein bekennender „Linux-Linkshänder“ bin, hab ich es mit einiger Unterstützung auch hinbekommen die Dateien für die Demovisu aus dem SVN Repository auf mein Wiregate zu übertragen. Dadurch ist es möglich einige Änderungen an der Visu vorzunehmen, die nicht in dem cometvisu Paket enthalten sind.
Als erstes sollte ihr euren root –Zugang im Wiregate freischalten. Dazu auf http://wiregatexxx:10000 gehen und den root Zugang aktivieren.
Am einfachsten ist es wenn ihr Windows nutzt mit dem Programm Putty (http://the.earth.li/~sgtatham/putty/.../x86/putty.exe)
Putty starten und eine SSH Verbindung zu eurem Wiregate aufbauen. Dazu einfach als Host „wiregateXXX“ eintragen, der Port bleibt auf 22
Dann werdet kommt ihr zur Anmeldung
Login as root
Password: Das Passwort vom eurem Wiregate
Jetzt benötigt ihr das Tool subversion, um die Dateien aus dem Sourceforge Server auszuchecken
Dazu einfach

apt-get install subversion

und Enter
Das Tool wird installiert.
Wenn das erledigt ist besorgt ihr euch die fehlenden Dateien vom Sourceforge Server

 cd ..

Das Leerzeichen Zwischen cd und den Punkt beachten!

Wenn das erledigt ist besorgen wir uns die Dateien aus dem Repository und kopieren sie in das Verzeichnis /var/www/visu_svn (das Verzeichnis wird hierbei mit erstellt)

 cd var/www
 svn co https://openautomation.svn.sourceforge.net/svnroot/openautomation/CometVisu/trunk/visu visu_svn

Zum Updaten der Dateien braucht ihr dann später nur

 cd var/www/visu_svn
svn update

Um die Visu Config über den Editor auch speichern zu können müssen für die Datei noch Schreibrechte eingerichtet werden:

chmod a+rw /var/www/visu_svn/visuconfig.xml

Jetzt ist eure Demovisu über

http://wiregatexxx/visu_svn/visu

erreichbar
Der Visueditor steht unter

http://wiregateXXX/visu_svn/visu/edit_config.html

zur Verfügung

@Chris zumindest hab ich das so gemacht, falls etwas nicht ganz richtig sein sollte sag einfach Bescheid, bevor der Artikel ins Wiki kommt

[vento66]

So Chris das hast Du jetzt davon!:

Ich kann keine Visuelemente anlegen die mit GA's in Verbindung stehen. (weder mit FF, IE( oder Chrome)
Also weder deine bestehenden ändern, noch neue anlegen. (ok kann man über das XML-File im Moment machen)
Vielleicht muss ich aber auch noch irgendwas beachten?


Auf dem Ipad ist nach "Update every 10sec" Schluss. Es gibt keine Möglichkeit nach unten zu scrollen _ Die Seite wird einfach abgeschnitten.

[netzkind]

<Theorie>
- beim packagen läuft über alle js/css yui-compressor oder jsmin (? letzterer klingt mir erheblich weniger heftig - ich teste das mal..)
</Theorie>

Sonst schau dir mal noch closure compiler an. cc und yuicompressor sind meist die bessere Wahl gegenüber jsmin, da sie ein Verständnis für jscode haben, und nicht nur über regex laufen.

Grüße,
Julian

[Chris M.]

So mal ne kurze Rückmeldung: Alle leben noch, und funktioniert (Sogar bei einem "Linux-Linkshänder"

Ich denke das dann alles im Visupaket installiert wird?! Dann brauchts das doch eigentlich nicht mehr. Oder sehe ich das falsch?

Jain.

Der gemeine User wird die CometVisu erst mal nur über's Package kennen (lernen).
Der Power-User wird dann erkennen, dass es ja wo anders eine neuere / mächtigere / ... Version gibt. Und diese Version ist ggf. die, die ein gerade benötigtes Feature hat.
Der Entwickler wird gleich zum SVN greifen - dann aber auch wissen, was er tut.

Dieses HowTo sehe ich für die Power-User, die im Rahmen der CometVisu zum ersten mal mit SVN in Berührung kommen (also genau so wie Du )

[vento66]

So mal ne kurze Rückmeldung: Alle leben noch, und funktioniert (Sogar bei einem "Linux-Linkshänder" Was ich jetzt nicht ganz kappiere:

Wenn Du das ganze machst, kannst Du gerne im Wiki das ganze als HowTo beschreiben, dass wenn wir das ganze im offenen Forum veröffentlichen diese Frage schon mal beantwortet ist (hier sind ja v.a. Entwickler unterwegs, die kennen dieses Vorgehen, da braucht's keine Erklärungen...)

Ich denke das dann alles im Visupaket installiert wird?! Dann brauchts das doch eigentlich nicht mehr. Oder sehe ich das falsch?
Ich meine ich schreibs gerne.....

[makki]

Was aus Package-Sicht wichtig(er) wird: JavaScript-Dateien sollten nicht in der Entwickler freundlichen, lesbaren Version verteilt werden, sondern aus Performance-Gründen in einer eingedampften, optimierten.

Ok, dann feilen wir die 150ms eben weg
<Theorie>
- beim packagen läuft über alle js/css yui-compressor oder jsmin (? letzterer klingt mir erheblich weniger heftig - ich teste das mal..)
</Theorie>

..und dabei noch jslint entdeckt

Makki

[Chris M.]

dringende Empfehlung: wenn man die SVN-Version nutzt: am besten in ein anderes Verzeichnis als /var/www/visu sonst wirds beim regulären Update immer dumme fragen von apt und geknatsche geben..

Richtig. Meine Empfehlung ist /var/www/visu_svn/ - wenn das alle so machen, ist's auf lange Sicht sicher für alle am einfachsten...

Klar, ich hab das jetzt eh schon gesplittet; Variante 1 ist: Du machst .tar.gz Releases auf sf: der build-rechner sieht das im cron-job und packaged automatisch, ich schiebe nach Sichtprüfung nur noch ins repo.
variante 2) dasselbe von hand angestossen - IMHO erstmal einfacher..

Ich mache v.a. erst mal einen Tag/Branch...

Was aus Package-Sicht wichtig(er) wird: JavaScript-Dateien sollten nicht in der Entwickler freundlichen, lesbaren Version verteilt werden, sondern aus Performance-Gründen in einer eingedampften, optimierten.
Die externen Bibliotheken (jQuery) gibt's bereits so, ich werde mittelfristig beide Versionen in's SVN legen und die SVN-Version auf die Entwickler-Version einstellen - aber die Paket-Version sollte auf die kleinen Versionen verweisen. Und die CometVisu-Dateien sollten möglichst automatisch auch komprimiert werden...

[makki]

Ein neues Paket wäre auch langsam an der Zeit - aber dazu würde ich gerne vorher den dynamischen Design-Wechsel noch einbauen (heute Abend?).

Wiegesagt: einfach bescheid geben - ist kein Akt..
dringende Empfehlung: wenn man die SVN-Version nutzt: am besten in ein anderes Verzeichnis als /var/www/visu sonst wirds beim regulären Update immer dumme fragen von apt und geknatsche geben..

Meine Vorstellung wäre dann, dass die Demo-Visu immer den aktuellen Paket-Stand zeigt. Und das das Paket auf einem Release aufsetzt, d.h. einem Tag/Branch im SVN. Aber evtl. können wir das dieses Wochenende mal üben

Klar, ich hab das jetzt eh schon gesplittet; Variante 1 ist: Du machst .tar.gz Releases auf sf: der build-rechner sieht das im cron-job und packaged automatisch, ich schiebe nach Sichtprüfung nur noch ins repo.
variante 2) dasselbe von hand angestossen - IMHO erstmal einfacher..

PS: nicht ausprobiert, aber wahrscheinlich funktioniert der Editor mit dem entsprechenden Link/Datei auf Makkis Demo-Visu

Der Editor ist drauf, die Demo-Visu ist aktuell SVN-Stand gestern, man kann jedoch nicht speichern (weil man sonst mit drei Klicks meine Haustüre öffnen kann - so braucht man wenigstens etwas mehr Detailwissen )
Ich glaube es ist der Zeitpunkt erreicht, wo ein bisschen mehr security Sinn machen würde.. Ich spiel mich da gerade mal ein bisschen..

Makki

[Chris M.]

[SVN]Das bedeutet im Klartext?

Im Klartext heißt dass, dass Du ein SVN-Client brauchst (unter Windows ist meine Empfehlung TortoiseSVN, unter Linux gerne die Kommandozeile, das ist nicht so schwer).
Dann checkst Du damit das Repository aus (vgl. die SourceForge-Seite des Projektres, bzw. konkret SourceForge.net: Open Automation: SCM wo steht, dass das (ganze) Repository https://openautomation.svn.sourcefor...openautomation heißt).
Davon musst Du nun nur noch das passende Unterverzeichnis auf das WireGate unter /var/www (z.B. als /var/www/visu_svn) kopieren und bist fertig

Wenn Du das ganze machst, kannst Du gerne im Wiki das ganze als HowTo beschreiben, dass wenn wir das ganze im offenen Forum veröffentlichen diese Frage schon mal beantwortet ist (hier sind ja v.a. Entwickler unterwegs, die kennen dieses Vorgehen, da braucht's keine Erklärungen...)