...
- node-stats: Brücke zwischen Hopglass und Graphite / Temporale Erfassung von quantitativen Knotendaten
- node_hierarchy: Tool zur optimierung der Firmware-Verteilung und Berücksichtigung von Abhängigkeiten (sowie ein paar Statistiken)
- geo_info: Knotenstatistiken nach geographischen Relationen
- node_stats.py: Script zur Ermittlung historischer Nutzerentwicklung
- ...
Problem
Bei der Vielzahl an Quellen und Anwendungen werden häufig viele gleiche (oder zumindest sehr ähnliche) Programmteile für jede Anwendung separat entwickelt. Bei Änderungen an den Daten / Datenstrukturen müssen in allen Programmen, teils sehr Umfangreiche, Änderungen vorgenommen werden. Obwohl der Inhalt der Daten meist gleich bleibt werden manchmal sogar ganze Programmteile obsolet bzw. erst erforderlich. Die Wartung dieser Anwendung ist zum totalen Horror geworden.
Hopglass Server
Der hopglass-server (geschrieben in nodejs) verspricht prinzipiell eine Abhilfe in dem es (mehr oder weniger) modularisiert ist. Es gibt zwei Typen von Modulen: receiver (Datenakquisition, respondd, ...) und provider (Datenlieferanten, hopglass, meshviewer,...). Leider, dazu genügt ein flüchtiger Blick in den Quelltext, werden hier auch sehr viele Operationen redundant, und somit sehr wahrscheinlich auch inkonsistent, in den einzelnen Modulen gepflegt, obwohl sie auch generisch an einer Stelle im Code gelöst werden könnten.
Außerdem ist die Performance der Anwendung eher mäßig. Das liegt zu einen daran, dass es nicht nur redundante Codeblöcke gibt sondern, dass viele dieser Blöcke auch, unnötigerweise, redundant ausgeführt werden. Dutzendfache, redundante, Ausführung auf Daten von mehreren Tausend Knoten und mindestens so vielen Links lässt das Ganze eher im Schneckentempo ablaufen. Außerdem scheint nodejs und insbesondere die Auswahl der verwendeten Frameworks sein Übriges zur eher mäßigen Performance beizutragen.
Abschließend lässt sich noch anmerken, dass man beim Verwenden der Hopglass-Server Struktur an die Sprache nodejs gebunden ist.