CometVisu - (interner) Beta-Test

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

[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

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

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 )

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

(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

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

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]

im Detail ungeprüftes Problem: kann es sein das das "dim"-widget nicht auf die Statusadresse sondern nur auf die Wertadresse reagiert ?
(können wir übrigens auch gerne über den sf-tracker machen, ich mag strukturierte Tools aber im internen thread posten sich unbegründete verdachtsmomente leichter )

Makki

[Chris M.]

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

Du solltest jetzt dürfen

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

Richtig - das was es offiziell gibt würde ich auch offiziell nehmen (deswegen würde ich dann beides im SVN ablegen - dann sind wir uns sicher dass es das selbe ist).
Bei unserem haben wir z.Zt. 0% Komprimierung, d.h. alles ist ein Fortschritt. Den können wir aber gerne graduell machen.

(Übrigens: die 150 kb sind nicht für die normale Visu wichtig, sondern für die Handy-Visu über GSM...)

Wenn da einer Mist baut kann ich nicht mal nachvollziehen warum ich die ganze Partition mit Müll vollgeschrieben hab

Wenn da Mist steht, wird's halt gefixt. Dazu ist's ein Wiki und keine Granit-Platte.

(können wir übrigens auch gerne über den sf-tracker machen, ich mag strukturierte Tools aber im internen thread posten sich unbegründete verdachtsmomente leichter )

Gute Frage wo die Trennung zwischen Thread und Tracker ist. Wird man wohl nicht pauschal beantworten können. Aktuell ist Thread sicher schneller, mittelfristig Tracker nachvollziehbarer.

(Inhaltlich kann ich gerade nicht's sagen, da ich heute Abend nicht zum Coden gekommen bin sondern Laptop shoppen musste )

[makki]

Richtig - das was es offiziell gibt würde ich auch offiziell nehmen (deswegen würde ich dann beides im SVN ablegen - dann sind wir uns sicher dass es das selbe ist).

Jep, finde ich auch viel besser - Du/Ihr entscheidet welches jquery usw., ich muss es nicht 3x prüfen sondern nur die minified-version im package ersetzen; das ist easy-going..

Bei unserem haben wir z.Zt. 0% Komprimierung, d.h. alles ist ein Fortschritt. Den können wir aber gerne graduell machen.

zumindest den jsmin kann man IMHO wirklich schmerzfrei machen.. spart aktuell ca. 30-50% grösse, die anderen compressoren würde ich ehrlichgesagt in der Entwicklungsphase erstmal bleiben lassen.. wenn die User dann mit Fehler d in function a b=c kommen
(jsmin: schon faszinierend, 7J alte SW, die trotzdem einfach funktioniert )

(Übrigens: die 150 kb sind nicht für die normale Visu wichtig, sondern für die Handy-Visu über GSM...)

Ich bin da wirklich voll bei Dir, jedes kleine puzzleteil macht - wo es sinnvoll&machbar ist - den Unterschied zwischen lahmer bloatware und einer schmucken, schicken, schnellen Lösung!
Wo es offensichtliches potential gibt - so wie hier - sollte man das von anfang an auch nutzen. Anwender sind gnadenlos (auch wenn sie das nicht sagen): entweder es ist saugeil, sauschnell so wie jetzt. Oder eben nicht; schublade, zu, wird zu 90% danach nie mehr angeschaut..

Deswegen auch z.B. das rrdfetch-backend gleich so - es macht im anwenderempfinden nunmal einen Unterschied ob das 200 oder 750ms dauert, wir sind hier IMHO 100% auf dem richtigen weg, ich will eher bei den 20-200ms bleiben (ab 300ms sagen Studien merkt der AW eine "Verzögerung")
(->Feedback pending: passt das rrdfetch/json so?)

Gute Frage wo die Trennung zwischen Thread und Tracker ist. Wird man wohl nicht pauschal beantworten können. Aktuell ist Thread sicher schneller, mittelfristig Tracker nachvollziehbarer.

Das wird sich schon einspielen denke ich; finde die verwendung vorhandener Tools&Plattformen jedenfalls sinnvoll und richtig: für bugtracker&feature-request (den diskutiert man vielleicht vorher lieber im Forum aber wenn er "mal steht" ist er im Tracker IMHO besser aufgehoben)

sondern Laptop shoppen musste )

Du armer Technik-shoppen tun geeks ja aber doch auch ganz gern, mal schnell 20 Datenbätter auswendig gelernt, wenn das Budget endlich mal freigegeben wurde

Makki

[Chris M.]

(->Feedback pending: passt das rrdfetch/json so?)

Sah auf den ersten Blick vernünftig aus. Endgültige Antwort wohl erst beim Implementieren.

Du armer Technik-shoppen tun geeks ja aber doch auch ganz gern, mal schnell 20 Datenbätter auswendig gelernt, wenn das Budget endlich mal freigegeben wurde

Jain. Der ist halt nicht für mich, sondern meine Frau. D.h. meine Vorstellungen der Technik muss ich immer wieder auf den Prüfstand stellen und ggf. anders entscheiden als wie wenn's für mich wäre. Und dazu kommt, dass ich die einschlägigen Info-Medien natürlich immer nur nach so einem Teil für mich quergelesen habe und daher bei einem "Pentium T4500" erst mal rausfinden muss, was das überhaupt ist (und beim Core i7 für mich weiß ich schon, dass Intel hier schon maximales Chaos erzeugt hatte...)

[makki]

Sah auf den ersten Blick vernünftig aus. Endgültige Antwort wohl erst beim Implementieren.

Klar, also kommt in 24h kein widerspruch, blas ich das so raus
(nebenbei: den segfault in eibread-cgi sehe ich zwar aber kann ich nicht reproduzieren - any hint welcome!)
Dann beherzige auch mal die Hinweise von mkoegler

Jain. Der ist halt nicht für mich, sondern meine Frau.

Umso einfacher Geheimtipp: mein letztes Notebook lief nach dem Prinzip: Intel drin => wird schon passen (wieviele GHz der hat, ehrlich, das ist wurscht, ich brauch ein paar ssh-Konsolen, das Forum, meine eMails); geforce-schamotter drin => kostet gedacht bestimmt massig Akkulaufzeit -> aber wird schon passen -> kann ich was dran ändern: Nein -> also Augen zu & Haken dran.

Erstes&letztes Kriterium bei mir: kostet? <500 EUR -> ok. Haken dran. Ich hab früher auch schon Notebooks für knapp 20k DM gekauft, da leben wir mittlerweile im schlaraffenland

Makki

[vento66]

Gibt es eigentich auch schon eine Idee wie die Bilder auf das WG kommen? Damit man die in der Visu nutzen kann? Ich meine über die Konsole ist das ja kein Problem.....

[Chris M.]

Gibt es eigentich auch schon eine Idee wie die Bilder auf das WG kommen? Damit man die in der Visu nutzen kann? Ich meine über die Konsole ist das ja kein Problem.....

Du meinst statische Bilder, oder?

Da müsste im Zweifel der Editor erweitert werden (+ ein PHP o.ä. auf WG Seite um die Daten entgegen zu nehmen).

Das ist grundsätzlich kein großes Problem - aktuelle Lösung ist aber klar SCP (o.ä.). Das ist halt der Unterschied zwischen Entwickler- und Enduser-Version