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

[Thorben Thuermer]

On Tue, 17 Sep 2013 14:44:05 +0200
Patrik Karisch <patrik.karisch at gmail.com> wrote:
> Am 17. September 2013 14:33 schrieb Thorben Thuermer <r00t at constancy.org>:
> >
> > schon doctrine war schon immer overkill fuer das projekt...
> 
> Ok, das ist jetzt wirklich Ansichtssache. Aus Programmierersicht
> nicht, denn mit puren SQL Statements (ob prepared oder nicht), kann
> ganz schnell ungut werden und führt zu Spaqhetticode. Ein ORM macht
> das OOP-Handling um einiges einfacher. Was die Anwendersicht betrifft,
> ist Doctrine nicht so inperformant. Vorrausgesetzt sind natürlich auch
> die richtigen Indizes. Ich bin der Meinung Frameworks und passende
> Bibliotheken sind nie ein Overkill. Gut, aber das ist nur meine
> Meinung. Man sollte auch Bedenken, ein Framework bietet die
> Möglichkeit, dass sich das Projekt in größe Konzepte weiter entwickeln
> kann. Mit rein eigenen Code wird das schwieriger. Einarbeitungszeit
> für neue Entwickler ist dann immer recht hoch.

du ueberschaetzt die groesse des projekts.
in der praxis ist es eher so, dass eh nichts passiert,
und die zusaetzliche komplexitaet durch das framework eher ein problem
fuer neue entwickler ist,
die ganze abstraktion ist fuer die effektiv zwei tabellen die verwendet werden
(zaehlerdefinitionen und zaehlerdaten) einfach overkill,
die performance gerade wenn das ganze dann auf raspi&co laufen soll eher
problematisch.

ich denke im aktuellen zustand und auch fuer die absehbare zukunft waehren
wir mit ein paar zeilen handgeschriebenem code besser bedient.

> Ich finde ja eher MySQL für die Art von Daten ineffizient.

ja, ein RRD waehre zB besser,
an dem punkt wo man sowas aendert kann man dann eh den gesamten bestehenden
code wegwerfen.

> > der bugtracker ist ohnehin tot - keine aktivitaet seit 2012-03...
> 
> ja, da wäre es mal an der Zeit, einfach mal die Issues auf GitHub zu
> aktivieren.

naja, bei vzlogger ist er aktiv, und bringt auch nix.
effektiv ist findet entwicklung halt auf der mailingliste statt.

> Ansonsten kann es auch einfach sein, das hier noch die dev
> Community fehlt? ;p

es gibt kaum entwickler,
und das projekt zieht gerade unmengen von eher ahnungslosen usern an,
mit denen die paar nebenbei-entwickler nicht fertig werden.
(ich persoenlich habe die -users liste schon lange abbestellt...)

es scheitert momentan schon am reviewen/einbinden von patches,
zB weil (bei vzlogger) ein testen ohne entsprechende hardware
schwer moeglich ist, es an kompetenten usern mangelt (bin selber keiner),
etc...
das fuehrt momentan dazu das etliche forks mit verschiedenen features
existieren...


ich bewundere natuerlich deine motivation,
super wenn wir mir dir einen entwickler mehr haben,
aber jetzt anzufangen die middleware umzuschreiben und auf ein neues
framework zu setzen halte ich fuer kein sinnvolles projekt.

wenn dir sinnvolle tests fuer die middleware einfallen,
waehre sicher nett, aber ich sehe auch nicht ganz wo der aufwand lohnt.
(beispieldaten mit verschiedenen meter-typen konstruieren,
 pruefen ob die middleware korrkte daten daraus berechnet...?)

ein interessantes projekt das ich grob auf der agenda habe waehre,
fuer vzlogger beispieldaten von verschiedenen zaehlern zu sammeln
um die protokoll-parser ohne die hardware testen zu koennen.
bei zaehlern die mit kommandos angesprochen werden muessen und dabei noch
komplexes timingverhalten haben (genau die gibt es) wird das aber auch
schon wieder schwierig.

- Thorben