[Software] Web Brick Viewer

[D4wN]

Hallo liebe Community,

 

ich habe vor, für meine Masterarbeit den Brick Viewer als eine Singel Page Web-Applikation prototyphaft umzusetzen. Da der Brickv ja relativ groß ist, werden nicht alle Bereiche in dem Zeitraum umgesetzt werden können. Daher wollte ich euch Fragen, welche Bereiche Ihr am wichtigsten findet. Ich habe mir schon einmal eine Liste gemacht, mit Bereiche die ich gerne für die Version 1.0 umsetzten würde:

[*]Brick/Bricklets View - Vereinfacht

[*]RED Brick

Wobei der RED Brick in folgende Bereiche eingeteilt werden soll:

• Overview Tab
  
• Program(Java, Python, Javascript/Node.js)
  
• Console
  
• Versions(Libs)
  
• Import/Export(System Logs, Program)
   
  

 

Die Web-Applikation soll auch für Mobile Endgeräte angepasst sein. Im Anhang könnt Ihr ein Mockup einer vereinfachten- und erweiterten View für ein Bricklet finden.

Für die Entwicklung werden ich vor allem Node.js, Express und Angular benutzten. Generell soll die Software nachher autark auf dem RED Brick laufen(ob als Programm oder extra Service kann ich jetzt noch nicht sagen). Wenn ich etwas weiter bin mit dem Projekt, würde ich auch gerne von euch Meinungen einholen, für meine spätere Evaluation. Aber bis dahin dauert es noch ein wenig

 

Jetzt noch einmal von mir die Frage: Welche Bereiche des Brick Viewer würdet Ihr gerne in der Version 1.0 sehen?

Auch über generellen Feedback würde ich mich freuen

 

MfG

Marv

[Nic]

Angular und Express Frameworks wären mir zu "schwer", node.js als Server ok und JQuery Mobile (JQM) ev. als Frontend. Die Website soll man dann auch im kleinen Smartphone benutzen dürfen. Später wenn ich diese Anwendung auf meinen RED deploye, möchte ich ungern Installationsorgien von diversen Frameworks machen müssen.

 

Allerdings würde ich von der "Breitenwirkung" des aktuellen BrickV Abstand halten, dass würde ansonsten nicht so gut ins Smartphone Hochformat passen. Die Controls in JQM bieten genügend Alternativen.

 

Wenn Du RED Infos darstellen willst musst du mal erst in die veröffentlichte API schauen, ob da viele Fkt. die wir im BrickV gewohnt sind auch als API Methode existieren.

 

Es würde zu Beginn ev reichen der Hauptfkt. wie die wichtigsten Getter und Setter eines Bricks/Bricklets anzuzeigen.

Ganz praktisch: Die Darstellung des Master-Bricks und seine Extensions um quasi remote Konfigurationen anzupassen.

 

Prima wäre es diesen BrickV generisch zu gestalten, dass neue Bausteine, sofern die Tinkerforge-Lib aktualisiert wurde, dynamisch hinzugefügt werden können und nicht jedesmal eine Neuinstallation nötig ist.

 

Ansonsten prima Idee. Wird hier sicher auf reges Interesse stoßen. Hopefully...

[D4wN]

Angular und Express Frameworks wären mir zu "schwer"...

Angular und Express hatte ich ausgesucht, da ich dort schon einiges an Erfahrung habe. Alternativen sind aber natürlich nicht ausgeschlossen.

 

Allerdings würde ich von der "Breitenwirkung" des aktuellen BrickV Abstand halten...

Das war auch der Plan, kommt wahrscheinlich in dem Mockup nicht ganz so gut rüber.

 

Wenn Du RED Infos darstellen willst musst du mal erst in die veröffentlichte API schauen, ob da viele Fkt. die wir im BrickV gewohnt sind auch als API Methode existieren.

Das wird bestimmt eine der interessantesten Baustellen. Denke, dass man bei einigen Funktionen eventuell Umwege übers Backend nehmen muss, wenn die API diese nicht bereitstellt.

 

Es würde zu Beginn ev reichen der Hauptfkt. wie die wichtigsten Getter und Setter eines Bricks/Bricklets anzuzeigen....

Prima wäre es diesen BrickV generisch zu gestalten, dass neue Bausteine, sofern die Tinkerforge-Lib aktualisiert wurde, dynamisch hinzugefügt werden können und nicht jedesmal eine Neuinstallation nötig ist.

Genau das sollen die vereinfachten Views werden. Diese sollten automatisch generiert werden können(ähnlich wie im DataLogger, bzw. dem Views des Brickv). Bei den erweiterten muss ich gucken, inwiefern sich das automatisieren lässt. Man möchte ja nicht immer zwei(Brickv und der Web Brick Viewer) komplett verschiedene Views anpassen, wenn sich was ändert

 

Noch etwas zur "Installation". Ich hatte mir zwei verschiedene Arten gedacht:

[*]Software als Service implementieren(ggf. später direkt in dem Image des RED Bricks)

[*]Als Programm, welches man mit dem Brickv auf den RED Brick hochladen könnte(verteilt über GitHub o.ä.)

Zusätzliche Installation sollte man dann keine mehr vornehmen müssen, evt. ein paar Node Packages per npm. Ziel ist es, das der Benutzt mit möglichst wenig Aufwand das ganze zum laufen und aktualisiert kriegt.

 

 

[Nic]

Man möchte ja nicht immer zwei(Brickv und der Web Brick Viewer) komplett verschiedene Views anpassen

Verstehe ich nicht, ich dachte du willst in der Masterarbeit nur "einen" Web Brick Viewer erstellen ?

 

Ja als npm Pakete updaten usw. so wie wir das jetzt schon machen mit der Tinkerforge Lib. Aber bitte ohne einen Rattenschwanz von Dependencies und riesigen Frameworks, die haben später auf meinem RED nix zu suchen.

 

Wie gesagt AngularJS ist mehr was für unternehmensweite Lösungen, wenn du den Code später als OpenSource rausgibst, denke daran, dass so ein Projekt eher weiterleben könnte, wenn es mit einfachen Mitteln geschrieben wurde, dann ev. in JQuery, das meist mehr Leute lesen können.

[D4wN]

Man möchte ja nicht immer zwei(Brickv und der Web Brick Viewer) komplett verschiedene Views anpassen

Verstehe ich nicht, ich dachte du willst in der Masterarbeit nur "einen" Web Brick Viewer erstellen ?

Es geht um die Wartung. Ziel ist es, aus den bestehenden Views des Brickv(Python, PyQt), HTML Views generieren zu lassen. Damit "falls" das Projekt mal übernommen wird, man nicht zwei unterschiedliche Basen(PyQt und HTML) für die Views pflegen muss. So könnten theoretisch im Brickv neue Bricklets hinzugefügt werden und für den Web Brick Viewer dann per Knopfdruck von Python in HTML übersetzt werden. Ob und in wie weit sich dieses wirklich umsetzten lässt, muss ich noch herausfinden.