CometVisu - (interner) Beta-Test

[makki]

Wie viele Images hast du denn?

Nicht so viele aktuell
Aber wir haben bei der letzten Visu ein paar "usability"-Tests und umfragen gemacht; das wurde als störend empfunden

Dann mach das mal, und dann ist das mit flot sicher machbar.

Ist das json so genehm? (siehe http://mm-ho-dyndns.org/cgi-bin/rrdf...-1day&res=1800 - das ist NICHT das in /oldvisu verwendete - 100x awk&grep weniger )
Hab kurz das rrdtool umgehacked, das es gleich json ausgibt, wie man das distributionstechnisch eintütet..
Die Timestamps sind UTC, die Daten %0.2float

Da in den Feature-Requests viel gutes und wichtiges steht und es in diesem Thread einfach zu unübersichtlich wird das alles wieder zu finden ohne dass etwas verloren geht, schlage ich vor, den dafür vorgesehenen Bug-Tracker auf SF zu nutzen:
SourceForge.net: Open Automation: Tracker

Klingt sinnvoll, ich schreib gleich mal was rein..

Makki

[Chris M.]

(*) Mein Ziel - aber noch nicht umgesetzt - war bei dem Styling zwei Level anzubieten, ein Design und als Variante dann ein "Flavour". Konkret wäre das Design das was man bisher gesehen hat und was netzkind gerade geändert hat. Das Flavour wäre bei dem klassischen Design unterschiedliche Farben, d.h. das bekannte Orange, oder ein Blau, oder Grün, oder ... - und das Sub-Seiten abhängig.
Die konkrete Umsetzung, v.a. die Auswirkung auf's CSS, habe ich mir aber noch nicht überlegt.

Hier bin ich jetzt einen kleinen Schritt weiter:

• jedes Design hat seinen eigenen Unterordner bekommen (könnte bisschen Platzverschwendung werden, wenn mehrere Designs die selben Dateien nutzen - aber die sind nur auf der Platte und da kostet's nix)
• Das Design ist nun in der normalen Config-XML einstellbar
• Die Flavours sind bereits einstellbar - die Umsetzung ist aber noch nicht implementierbar
• Wie der Editor mitbekommen wird, welche Designs es zur Auswahl gibt ist noch offen (evtl. auch ein PHP?); beim Editor habe ich auch keinerlei Integration diesbezüglich getrieben
• Für die Demo-Visu schreibe ich noch ein User-Widget, dass dynamisch durch die Designs toggelt - dann müssen wir uns nicht endgültig entscheiden, wass das Standard-Design ist und der Endanwender sieht die Möglichkeiten

[makki]

(könnte bisschen Platzverschwendung werden, wenn mehrere Designs die selben Dateien nutzen - aber die sind nur auf der Platte und da kostet's nix)

Mach Dir da mal keinen Kopp Wir haben 4GB, durch das löschen von 500 in den Basics überflüssigen Paketen könnte man nochmal >500MB einsparen aber das wurde bewusst nicht wegen 20 EUR kompliziert gekrippelt..
Ich mag "fette Systeme" der einfachheit halber; solange es keine Not gibt - 20 EUR lösen bei mir keine Not aus

(evtl. auch ein PHP?)

Finde ich Ok/egal. PHP (wie py/pl/whatever) ist ja "eh da".
Bei solchen geschichten IMHO egal, wenn es "gemein tackert" mache ich aber lieber etwas resourcenschonendes (weil die REG-Variante mit krüppel-ARM liegt nunmal schon aufm Tisch )
-> siehe RRD, da will ich einfach das die Grafik unterhalb der bekannten Akzeptanzschwelle von 300ms "da" ist - da will ich offengestanden P*&Co meiden wo es geht.
Man lernt ja auch dazu

Makki

[vento66]

So wenn jemand einem Doofen mal kurz erklärt, wie der Editor auf das Wiregate kommt wäre ich sehr dankbar (ich und Linux- das sind 2 verschiedene Sachen die sich erst noch finden müssen ) Aber langsam wirds

[Chris M.]

So wenn jemand einem Doofen mal kurz erklärt, wie der Editor auf das Wiregate kommt

Für die Doofen gilt die selbe Beschreibung wie für die Nicht-Doofen :

Im Visu-Verzeichnis musst Du im Browser nur die Datei edit_config.html aufrufen, d.h. typischerweise

http://wiregateXXX/visu/edit_config.html

PS: Linux-Kenntnisse sind dafür nicht notwendig

[vento66]

Naja soweit hatte ich das auch gedacht jedoch:
Ups! Dieser Link scheint nicht zu funktionieren.

jetzt hab ich mal auf der Konsole reingeschaut, und mein Browser hat recht!

Also jetzt doch noch mal für die "Geistig etwas unterbelichteten" Woher bekomme ich die edit_config.html?

[Chris M.]

Naja soweit hatte ich das auch gedacht jedoch:
Ups! Dieser Link scheint nicht zu funktionieren.

Wahrscheinlich nutzt Du nicht die Version aus dem SVN sondern das cometvisu Paket. Das ist zu alt - da gibt es noch keinen Editor...
D.h. entweder nimmst Du die aktuellste Version aus dem SVN (gut machbar, bedingt aber die Bereitschaft mit Entwickler-Tools zu arbeiten) oder Du musst warten, bis Makki ein neues Paket schnürt.

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?). 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

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

[vento66]

Ja Du hast recht, es ist das alte cometvisu Paket, ich war der Meinung das es das ein Update gab.....

Aber setzen wir doch mal hier an:

D.h. entweder nimmst Du die aktuellste Version aus dem SVN (gut machbar, bedingt aber die Bereitschaft mit Entwickler-Tools zu arbeiten)

Das bedeutet im Klartext?

[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...)

[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.]

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]

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

[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.....

[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 )

[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