[vz-dev] VZ Codebasis, Unit-Tests, und so

[Patrik Karisch]

So, ich lass hier mal die Vollzitate weg und antworte auf beides.

Wie gesagt, die Codebase ist gut umgesetzt und gut strukturiert. Komme
in dieser Hinsicht woanders her, der gerne auf vorhandenes
zurückgreift ^-^ Wobei es ja dort auch große Unterschiede gibt:
Full-Stack Frameworks, die wirklich alles mitbringen und das
umfangreich, oder Microframeworks die das wichtigste gut unterstützen
aber nicht aufgeblassen sind. Oder man kann (im Falle von Symfony) nur
auf einzelne Komponenten zurückgreifen, wie es z.B. schon mit Doctrine
gemacht wurde. Will ja jetzt auch die Codebase nicht umschreiben,
wollte nur mal eine Diskussion anstoßen.
Bei der Middleware bin ich mir nicht sicher ob es nun an Doctrine
liegt, oder einfach an MySQL was für einen RPi auch schon zuviel ist.
Schon mal Messungen gemacht, wie sich diese mit sqlite am RPi macht?
Ansonsten halte ich dokumentorienterte Datenbanken für Messdaten
besser geeignet. Ab 2/3 Messwerten die gespeichert werden sollen. Bin
selbst aktuell im Smart Metering Bereich beschäftigt und dort verwende
ich MongoDB für's Online Monitoring, womit gleich
Map/Reduce-Funktionalität an Board ist und sich sehr fein große
statistische Daten zusammenfassen lassen. Läuft natürlich online und
eben kein Ding für den RPi :-/ Wenn man den RPi bedenkt, kommen nicht
viele DBs in die Auswahl.

Zu den Issues: Da müsste man aber auch mal die Repo-Struktur
überarbeiten und die ganzen misc Sachen in eigene Repos auslagern. Da
wo das Zeug halt hingehört. Um das alles zu Verbinden, kann es ja ein
Topprojekt/Buildprojekt geben. Alles ein bisschen Arbeit, ich weiß.

Wie gesagt komme aus dem Smart Metering, sowohl Geräteseitig als auch
Monitoringseitig und würde hier gerne comitten, aber dazu sind eben
einiges an Informationen nötig. Was sind konkrete Probleme (von
Userseite), wohin geht die Zukunft, was will man weiter bewältigen,
etc. Auch die Lizenzfrage ist interessant. Da man ja gesagt hat, es
ist v0.2 (reine Definitionssache), darf sich keiner drauf verlassen,
das so ein Projekt eine stabile API für die Zukunft hat ;)

Testen ist immer schwierig, besonders im Nachhinein. Vorteilhaft sind
sie im Vorhinein, siehe TDD. Automatisierte Unit-Test stellen dann bei
Patches sicher, das nicht dadurch was anderes kaputt geht (sofern
durch Test-Fall abgedeckt). Machen also schon Sinn.

LG Patrik