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

[Patrik Karisch]

So, hab das mal abgespaltet vom anderen Thema.

Was die Codebasis von der Middleware betrifft, PHP ist Ansich kein Problem,
Doctrine ist kuhl, jep, aber vermisse trotzdem den Einsatz eines
Frameworks. Trotz Namespaces und Closures ist PHP ohne Framework naja ;)
Ansonsten trotzdem recht gut nach MVC (hab nur grob drübergeschaut)
umgesetzt. Aber alles noch Handarbeit. Wie steht denn die allgemeine
Meinung dazu, mehr auf ein Framework zu setzen?
Dazu gleich das Thema Tests. In Existenz mit Frameworks zum Teil die
leichtere Geschichte. Wobei bei der Middleware nicht so viel zum testen
ist. Aber es schadet nicht.

Hmm, was noch? Das GitHub Repo ist etwas komisch organisiert ;) Und warum
noch ein seperater Bugtracker, wenn GitHub recht gutes Issues Frontend
bietet?


Hoffe ich stoße euch damit jetzt nicht vor dem Kopf, sondern kann ein
nettes Gespräch anregen (:

Beste Grüße
Patrik

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

[Thorben Thuermer]

On Tue, 17 Sep 2013 14:10:49 +0200
Patrik Karisch  wrote:
> So, hab das mal abgespaltet vom anderen Thema.
> 
> Was die Codebasis von der Middleware betrifft, PHP ist Ansich kein Problem,
> Doctrine ist kuhl, jep, aber vermisse trotzdem den Einsatz eines
> Frameworks. Trotz Namespaces und Closures ist PHP ohne Framework naja ;)
> Ansonsten trotzdem recht gut nach MVC (hab nur grob drübergeschaut)
> umgesetzt. Aber alles noch Handarbeit. Wie steht denn die allgemeine
> Meinung dazu, mehr auf ein Framework zu setzen?
> Dazu gleich das Thema Tests. In Existenz mit Frameworks zum Teil die
> leichtere Geschichte. Wobei bei der Middleware nicht so viel zum testen
> ist. Aber es schadet nicht.

schon doctrine war schon immer overkill fuer das projekt...

> Hmm, was noch? Das GitHub Repo ist etwas komisch organisiert ;) Und warum
> noch ein seperater Bugtracker, wenn GitHub recht gutes Issues Frontend
> bietet?

der bugtracker ist ohnehin tot - keine aktivitaet seit 2012-03...

> Hoffe ich stoße euch damit jetzt nicht vor dem Kopf, sondern kann ein
> nettes Gespräch anregen (:
> 
> Beste Grüße
> Patrik

- Thorben

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

[Patrik Karisch]

Am 17. September 2013 14:33 schrieb Thorben Thuermer :
>
>
> 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.

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

> 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. Ansonsten kann es auch einfach sein, das hier noch die dev
Community fehlt? ;p

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

[Andreas Goetz]

Hallo Zusammen!

Nachdem ich wirklich viel Zeit in den Untiefen der MW verbracht habe und
mittlerweile auch ein paar Patches bis ins git steht es mir vielleicht zu
mich zu dem Thema auch mal zu äußern- meine 2cents, auch wenn einige Fragen
sicher reine Geschmackssache nennt.

2013/9/17 Patrik Karisch 

> Am 17. September 2013 14:33 schrieb Thorben Thuermer :
> >
> > schon doctrine war schon immer overkill fuer das projekt...
>

Zunächst mal muß ich sagen, dass ich die Codebasis wirklich genial finde.
Die Struktur aus Controllern, Interpretern und Views ist auf den ersten
Blick zwar nicht ganz offensichtlich, funktioniert in der Praxis aber
wunderbar.

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.


Das sehe ich etwas anders. Doctrine hat gerade auf langsamen Plattformen
wie dem RasPi einige Probleme- so war es mir nicht möglich trotz Query
Caching wirklich performant zu bekommen.

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

S.o.- der Code funktioniert und war für mich gut erweiterbar. Er ist aber
(dank Doctrine) auch nicht rasend schnell- einige Overheads kann mein
letzter Commit mildern.

Dazu kommt, dass die MW jetzt sehr lange stabil war- soweit ich sehen kann
gibt es sehr wenige Änderungen (und damit wohl auch Anforderungen).


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

Solche Kommentare finde ich besonders schwer zu greifen. Es ist halt eine
Datenbank und relationale DBs eignen sich i.A. ganz gut für "die Art von
Daten". Aber dafür gibts ja das Potential weitere DBs zu unterstützen.


> > 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. Ansonsten kann es auch einfach sein, das hier noch die dev
> Community fehlt? ;p
>

+1 für Issues im GitHub, idealerweile mit Mail an die Liste. Habe mit
ebenfalls schwer getan ich mit der Mailingliste anzufreunden.

2013/9/16 Justin Otherguy 

> Hi Patrik,
>
> Am 16.09.2013 um 21:07 schrieb Patrik Karisch:
>
> >> Anders formuliert:
> >> bitte testen und beschweren, wenn etwas kaputt ist.
> > Für das wären Unit-Tests und ein CI-Server gedacht ^^ -> travis-ci.org
> >
> > Zumindestens für die großteil einer Applikation.
> super Idee.
>
> Du hast den Job! ;-)
>
> Im Ernst: wenn du uns helfen kannst, das an den Start zu bringen - mich
> würd's freuen. Und ich wette: nicht nur mich :-)
>

Ich habe bereits einen Satz Unit Tests für diverse Meter- nicht schön aber
funktionieren. Ohne dieses Hilfsmittel hätte ich die Änderungen am Code
niemals machen können und habe damit Fehler in meinem, aber auch Unschärfen
in der Codebasis  entdeckt.
Entwickelt mit PHPUnit- bei Interesse bitte melden!

In diesem Sinne: ich würde mich freuen wenn etwas Schwung in die MW käme.
Primäres Ziel aus meiner Sicht wäre allerdings nicht Funktionalität,
sondern Performance und dazu Unittests als Basis für weitere Optimierungen.
Um ohne Tests arbeiten zu können ist die MW bereits deutlich zu komplex.

In diesem Sinne- Viel Spass beim Basteln!

vg
Andreas

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

[Thorben Thuermer]

On Tue, 17 Sep 2013 14:44:05 +0200
Patrik Karisch  wrote:
> Am 17. September 2013 14:33 schrieb Thorben Thuermer :
> >
> > 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

Re: [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

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

[W3ll Schmidt]

Hi Patrik,


Am 17. September 2013 21:44 schrieb Patrik Karisch :

>
> 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?
>


Haste mal überflogen?

http://sqlite.org/speed.html

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

[Patrik Karisch]

Hi

Am 23. September 2013 20:15 schrieb W3ll Schmidt :
> Haste mal überflogen?
>
> http://sqlite.org/speed.html

Das sqlite generell schneller ist, ist sowieso klar. Besonders auf dem
RPi dürften die Faktoren noch größer sein, da dieses nicht für MySQL
geeignet ist. Mir ging es eher darum, ob wirklich Doctrine
signifikante Performanceeinbußen hervorruft, oder ob es einfach nur
der MySQL ist.

LG Patrik

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

[Andreas Goetz]

Hallo Zusammen,

ich habe mal auf Basis von
https://github.com/frasermac/xively-visualizer/eine kleine
Visualisierung für alle öffentlichen Kanäle des VZ
zusammengedübelt.
Wenn man das auf demo.volkszaehler.org zeigen lässt hätten wir damit ein
schönes Frontend mit deutlich weniger Code (und ein paar weniger
Fähigkeiten) als das "richtige" Frontend. Das könnte eine schöne Basis für
eigene Weiterentwicklungen der Community sein.

Damit sowas geht bräuchten wir aber ein Repository in dem ich sowas
einbringen kann und das sich vielleicht generell etwas
interaktionsfreudiger gitb als die aktuelle Struktur:

- mehr Committer
- mehr Unterrepositories die eine Zusammenarbeit erlauben
- schnellere Bearbeitung von requests
- Nutzung der github Issues

Wie siehts aus?

vg
Andreas



2013/9/24 Patrik Karisch 

> Hi
>
> Am 23. September 2013 20:15 schrieb W3ll Schmidt :
> > Haste mal überflogen?
> >
> > http://sqlite.org/speed.html
>
> Das sqlite generell schneller ist, ist sowieso klar. Besonders auf dem
> RPi dürften die Faktoren noch größer sein, da dieses nicht für MySQL
> geeignet ist. Mir ging es eher darum, ob wirklich Doctrine
> signifikante Performanceeinbußen hervorruft, oder ob es einfach nur
> der MySQL ist.
>
> LG Patrik
>

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

[Patrik Karisch]

Servus Andreas

Am 24. September 2013 14:07 schrieb Andreas Goetz :
> Damit sowas geht bräuchten wir aber ein Repository in dem ich sowas
> einbringen kann und das sich vielleicht generell etwas interaktionsfreudiger
> gitb als die aktuelle Struktur:
>
> - mehr Committer
> - mehr Unterrepositories die eine Zusammenarbeit erlauben
> - schnellere Bearbeitung von requests
> - Nutzung der github Issues
Meine Worte ;) Bis jetzt hat sich weder Justin noch Steffen dazu
geäußert. Auch W3ll Schmidt ist mit noch eine Antwort schuldig, warum
seine Repos nicht in der Volkszählergruppe auf GitHub sind ^-^

LG Patrik

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

[W3ll Schmidt]

Am 24. September 2013 14:35 schrieb Patrik Karisch :

> geäußert. Auch W3ll Schmidt ist mit noch eine Antwort schuldig, warum
> seine Repos nicht in der Volkszählergruppe auf GitHub sind ^-^
>
> LG Patrik
>

Ähmm, ehrlich?

Ich habe mich damit noch nie wirklich tiefgründig beschäftigt ;-)

Ich schaffe gerade clone; commit, push & pull ...

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

[Rainer Gauweiler]

Hallo Patrick,

Am 24.09.2013 13:48, schrieb Patrik Karisch:

Das sqlite generell schneller ist, ist sowieso klar. Besonders auf dem
RPi dürften die Faktoren noch größer sein, da dieses nicht für MySQL
geeignet ist.


Kann ich so nicht bestätigen. Ich habe auf einer Dockstar mal sqllite im 
Einsatz gehabt und bin gnadenlos untergegangen.


Ursache war, dass die DB bem Öffnen komplett in den Hauptspeicher 
gelesen wurde, was auf den kleinen Dingern dann natürlich der Tod ist.


Mag inzwischen vielleicht anders sein. Ich bin damals auf mysql 
umgestiegen und versuche DBs auf den kleinen Kisten zu vermeiden.


Gruss
 Rainer

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

[Andreas Goetz]

Hallo,

2013/9/24 W3ll Schmidt 

> Am 24. September 2013 14:35 schrieb Patrik Karisch <
> patrik.kari...@gmail.com>:
>
>  geäußert. Auch W3ll Schmidt ist mit noch eine Antwort schuldig, warum
>> seine Repos nicht in der Volkszählergruppe auf GitHub sind ^-^
>>
>> LG Patrik
>>
>
> Ähmm, ehrlich?
>
> Naja- vielleicht etwas sehr unglücklich formuliert- von "schulden" kann
man sicher nicht sprechen.

Aber es ist aus meiner Erfahrung schon so, dass VZ sich relativ unnahbar
darstellt. Das sage ich trotz eigenem Git Account und seit mehreren Jahren
aktiv betriebenen Open Source Projekten.

Jetzt scheint es ein paar neue Leute zu geben die sich ebenfalls engagieren
möchten. Die Frage ist in welchem Rahmen und mit welchen Rechten- oder ob
überhaupt Interesse besteht.

Die eher verhaltene Diskussion zeigt vielleicht auch, dass die Maintainer
mit dem Stand von VZ eigentlich ganz zufrieden sind und tatsächlich gar
keinen großen Änderungsbedarf sehen?

vg
Andreas

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

[Patrik Karisch]

Am 24. September 2013 15:59 schrieb W3ll Schmidt :
>
> Ähmm, ehrlich?
>
> Ich habe mich damit noch nie wirklich tiefgründig beschäftigt ;-)
>
> Ich schaffe gerade clone; commit, push & pull ...
>
Wäre eigentlich kein Unterschied, außer das sich die Adresse des Repos
ändern würde, mehr nicht. Durch redirects seitens GitHub müsstest
nicht mal was an deiner Repokonfiguration ändern.
Aber es würde (meine Meinung nach) nach außen einen besseren Eindruck
der Community bilden, als wie wenn alle die (größeren/viel
verwendeten) Projekte über alle möglichen Accounts verteilt sind.

Am 24. September 2013 17:13 schrieb Andreas Goetz :
> Naja- vielleicht etwas sehr unglücklich formuliert- von "schulden" kann man
> sicher nicht sprechen.
Jetzt bitte nicht jedes Wort auf die Waagschale stellen :)

> Aber es ist aus meiner Erfahrung schon so, dass VZ sich relativ unnahbar
> darstellt. Das sage ich trotz eigenem Git Account und seit mehreren Jahren
> aktiv betriebenen Open Source Projekten.
Leider ja. Wundert mich einfach bei einen OS-Projekt.

> Jetzt scheint es ein paar neue Leute zu geben die sich ebenfalls engagieren
> möchten. Die Frage ist in welchem Rahmen und mit welchen Rechten- ob
> überhaupt Interesse besteht.
Na, da hat ja Git die besten Möglichkeiten. github.com/volkszaehler
ist ja kein Account, sondern eine Organisation. In dieser lassen sich
Gruppen erstellen, denen man nur Schreibrechte auf bestimmte Repos
erteilt. Als Beispiel mal, würde man @W3lls Repos in die Organisation
übertragen, erstellt man eine passende Gruppe die nur Schreibrechte
auf die übertragenen Repos hat und nur W3ll drinnen ist. Als Beispiel.
Ansonsten wie immer, Forks und Pull Requests, außer der
Hauptmaintainer eines Projekts/Repos erteilt einen fleisigen und
regelmäßigen Contributor auch direkte Schreibrechte.

> Die eher verhaltene Diskussion zeigt vielleicht auch, dass die Maintainer
> mit dem Stand von VZ eigentlich ganz zufrieden sind und tatsächlich gar
> keinen großen Änderungsbedarf sehen?
Hmm, ich hoffe immer noch darauf, dass einfach nicht jeder Zeit hat,
sofort immer alle Mails zu lesen/beantworten zu können, und nicht dass
die Diskussion absichtlich ignoriert wird o_^ Wäre nicht schön so ein
zukunftsträchtiges Projekt dem Stillstand preiszugeben und (bitte
nicht böse nehmen), die Meinung zweier muss nicht die Meinung der
Community widerspiegeln.

LG Patrik

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

[Jan Tamm]

Am 24. September 2013 18:56 schrieb Patrik Karisch :

> Am 24. September 2013 15:59 schrieb W3ll Schmidt :
>
> > Die eher verhaltene Diskussion zeigt vielleicht auch, dass die Maintainer
> > mit dem Stand von VZ eigentlich ganz zufrieden sind und tatsächlich gar
> > keinen großen Änderungsbedarf sehen?
> Hmm, ich hoffe immer noch darauf, dass einfach nicht jeder Zeit hat,
> sofort immer alle Mails zu lesen/beantworten zu können, und nicht dass
> die Diskussion absichtlich ignoriert wird o_^ Wäre nicht schön so ein
> zukunftsträchtiges Projekt dem Stillstand preiszugeben und (bitte
> nicht böse nehmen), die Meinung zweier muss nicht die Meinung der
> Community widerspiegeln.
>
Wenn ich von mir auf andere schließen kann, dann gibt es viele, die gerne
bereit sind, Verbesserungen zu entwickeln, aber vielleicht am git
scheitern. Ich habe mal schnell in die Posts geschaut und die Änderungen
von Peter Everts in vzlogger sind glaube ich noch nicht ins Repository
eingeflossen. Auf seinen Stand habe ich noch Erweiterungen hinzugebaut aber
nur das Binary mal verteilt. Ich würde mich freuen, wenn wir das geordnet
in den Master einbringen können. Ideen gibt es immer mal wieder auf der
Liste, ich denke da nur an die Punkte die Justin nach dem EC geschrieben
hat, z.B. die Nutzung des S0 meters in vzlogger und da bin ich gerne bereit
mitzuhelfen.

Schöne Grüße
Jan

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

[Thorben Thuermer]

On Tue, 24 Sep 2013 14:35:02 +0200
Patrik Karisch  wrote:
> Auch W3ll Schmidt ist mit noch eine Antwort schuldig, warum
> seine Repos nicht in der Volkszählergruppe auf GitHub sind ^-^

ich denke eher, du bist eine erklaerung schuldig, warum das denn so wichtig ist.


ich fand' gerade noch diesen commit,
der anscheinend die projekte von w3llschmidt als externe verlinkung im
repository einfuegt? (kenne mich da nicht so aus)
https://github.com/w3llschmidt/volkszaehler.org/commit/e4c619b7627ff34fddd7374d36e21eed1bd7278f

> LG Patrik

- Thorben

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

[Thorben Thuermer]

On Tue, 24 Sep 2013 14:35:02 +0200
Patrik Karisch  wrote:
> Bis jetzt hat sich weder Justin noch Steffen dazu geäußert.

damit da mal was zu gesagt wird:
justin ist der initiator des projekts,
eine antwort von ihm fehlt hier irgendwie,
er sagte mir er hat leider gerade keine zeit dafuer/anderes zu tun.
steffen ist schon laenger nichtmehr gross im projekt aktiv.

> Am 24. September 2013 14:07 schrieb Andreas Goetz :
> > Damit sowas geht bräuchten wir aber ein Repository in dem ich sowas
> > einbringen kann und das sich vielleicht generell etwas interaktionsfreudiger
> > gitb als die aktuelle Struktur:

persoenlich sehe ich nicht so ein grosses problem.
jedem steht frei einen fork anzulegen, aenderungen zu veroeffentlichen,
und hier zu diskutieren.
das mergen von aenderungen in den master mag gerade etwas hinterherhaengen,
dazu mehr weiter unten.

> > - mehr Unterrepositories die eine Zusammenarbeit erlauben
...?

> > - mehr Committer

ich stellte gerade fest, das ich auch commit-rechte habe... ;)
habe leider auch wenig erfahrung mit git.
habe aber inzwischen mal versucht ein paar sachen aufzuarbeiten.

wenn jemand meint, dass wir mehr brauchen und dass er einer davon ist,
wuerde ich vorschlagen justin zu kontaktieren.

> > - schnellere Bearbeitung von requests

ich sehe noch das problem, inwieweit aenderungen vorher reviewed/getestet
werden/sein sollten.
bei aenderungen die nicht vorher hier diskutiert wurden, oder wo nicht klar
ersichtlich ist worum es ueberhaupt geht (commit messages und kommentare 
helfen!),
bin ich auch erstmal skeptisch.

wobei aber wohl auch momentan ein allgemeines weiterkommen wichiger ist,
als der eine oder andere neue bug.
(ein schoenes beispiel war, wie justin zuletzt relativ hektisch
 diesen germerged hatte: 
https://github.com/volkszaehler/volkszaehler.org/pull/47
 und da prompt ein bug drin war, der die api unbrauchbar gemacht hat
 
http://www.mail-archive.com/volkszaehler-dev@lists.volkszaehler.org/msg01921.html
 und der bei einer kurzen review (justin ist kein programmierer),
 oder einem test woanders als beim autor, aufgefallen waehre.
 (was aber dann ja auch schnell behoben war!)
 https://github.com/volkszaehler/volkszaehler.org/pull/49 )


und das problem, dass die aenderungen schnell unuebersichtlich werden,
und man sich schwerer tut grosse pull requests zu mergen,
als kleinere fixes fuer einfache probleme.
(siehe den herrn hirsch, der herumlurkt und kleine aber wichtige commits
 blitzartig merged ;) )
ich denke es waehre da sinnvoll aenderungen vorher kurz zu diskutieren,
zB hier (oder in den github issues?) und zu einem konsens zu kommen.

es gab es ja zB den thread
"Feedback benötigt: vzlogger / aggregation / random meter / sml-pull / s0-meter"
( http://article.gmane.org/gmane.network.volkszaehler.devel/1572 )
der leider recht schleppend verlief.


die letzte meldung von justin dazu war...
http://volkszaehler.org/pipermail/volkszaehler-dev/2013-August/003005.html
On Wed, 28 Aug 2013 23:51:03 +0200 Justin Otherguy  
wrote:
> korrekt (leider). Die Patches lassen sich nicht "g'schwind(TM)" mergen.
> Scheitert an magischen git-Kräften (und der alternativ benötigten Zeit).
> Falls mir Jemand beispringen möchte: das ist eine gute Gelegenheit! ;-)

darauf hatte sich niemand gemeldet...
ich werde mir das sonst mal anschauen.


> > - Nutzung der github Issues

habe anscheinend nicht die rechte das einzustellen...
werde justin mal anhauen, wenn er nicht selber mitliest.


- Thorben

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

[Andreas Goetz]

Hallo Torben,


2013/9/27 Thorben Thuermer 

> On Tue, 24 Sep 2013 14:35:02 +0200
> Patrik Karisch  wrote:
> > Bis jetzt hat sich weder Justin noch Steffen dazu geäußert.
>
> damit da mal was zu gesagt wird:
> justin ist der initiator des projekts,
> eine antwort von ihm fehlt hier irgendwie,
> er sagte mir er hat leider gerade keine zeit dafuer/anderes zu tun.
> steffen ist schon laenger nichtmehr gross im projekt aktiv.
>
> > Am 24. September 2013 14:07 schrieb Andreas Goetz :
> > > Damit sowas geht bräuchten wir aber ein Repository in dem ich sowas
> > > einbringen kann und das sich vielleicht generell etwas
> interaktionsfreudiger
> > > gitb als die aktuelle Struktur:...
>


> wenn jemand meint, dass wir mehr brauchen und dass er einer davon ist,
> wuerde ich vorschlagen justin zu kontaktieren.
>
> Dh. außerhalb dieser Liste per Mail?


> > > - schnellere Bearbeitung von requests
>
> ich sehe noch das problem, inwieweit aenderungen vorher reviewed/getestet
> werden/sein sollten.
>

Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne
commit, sondern auch ohne Test- weil's einfach niemanden interessiert.
Vielleicht könnte ein -dev Zweig helfen solche Probleme wie den
eingeführten Fehler abzumildern.

ersichtlich ist worum es ueberhaupt geht (commit messages und kommentare
> helfen!),
> bin ich auch erstmal skeptisch.
>
> wobei aber wohl auch momentan ein allgemeines weiterkommen wichiger ist,
> als der eine oder andere neue bug.
> (ein schoenes beispiel war, wie justin zuletzt relativ hektisch
>

Du meinst nach 6 Wochen ist Hektik aufgekommen ;?


>  diesen germerged hatte:
> https://github.com/volkszaehler/volkszaehler.org/pull/47
>  und da prompt ein bug drin war, der die api unbrauchbar gemacht hat
>
> http://www.mail-archive.com/volkszaehler-dev@lists.volkszaehler.org/msg01921.html
>  und der bei einer kurzen review (justin ist kein programmierer),
>  oder einem test woanders als beim autor, aufgefallen waehre.
>

Korrekt- hat aber keine gemacht :/

 (was aber dann ja auch schnell behoben war!)
>  https://github.com/volkszaehler/volkszaehler.org/pull/49 )
>

So isses. Und um hier aktiv etwas beizutragen: ich habe immer noch einen
Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin-
die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von
keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen...

und das problem, dass die aenderungen schnell unuebersichtlich werden,
> und man sich schwerer tut grosse pull requests zu mergen,
> als kleinere fixes fuer einfache probleme.
>

Ich bin auch kein Git Experte, hatte aber das Problem dass Github alle
meine Commits in den schon bestehenden PR gepackt hat- kleiner ging erstmal
nicht...


> (siehe den herrn hirsch, der herumlurkt und kleine aber wichtige commits
>  blitzartig merged ;) )
> ich denke es waehre da sinnvoll aenderungen vorher kurz zu diskutieren,
> zB hier (oder in den github issues?) und zu einem konsens zu kommen.
>

Mehr als die Sachen per Mail hier anzupreisen kann ich wohl nicht tun. Oder
doch?

es gab es ja zB den thread
> "Feedback benötigt: vzlogger / aggregation / random meter / sml-pull /
> s0-meter"
> ( http://article.gmane.org/gmane.network.volkszaehler.devel/1572 )
> der leider recht schleppend verlief.
>
>
> die letzte meldung von justin dazu war...
> http://volkszaehler.org/pipermail/volkszaehler-dev/2013-August/003005.html
> On Wed, 28 Aug 2013 23:51:03 +0200 Justin Otherguy <
> jus...@justinotherguy.org> wrote:
> > korrekt (leider). Die Patches lassen sich nicht "g'schwind(TM)" mergen.
> > Scheitert an magischen git-Kräften (und der alternativ benötigten Zeit).
> > Falls mir Jemand beispringen möchte: das ist eine gute Gelegenheit! ;-)
>
> darauf hatte sich niemand gemeldet...
> ich werde mir das sonst mal anschauen.
>
>
> > > - Nutzung der github Issues
>
> habe anscheinend nicht die rechte das einzustellen...
> werde justin mal anhauen, wenn er nicht selber mitliest.
>
>
> - Thorben
>

Logger ist leider nicht mein Thema :(

vg
Andreas

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

[Thorben Thuermer]

On Fri, 27 Sep 2013 08:57:39 +0200 Andreas Goetz 
wrote:
> Hallo Torben,
 +h

> 2013/9/27 Thorben Thuermer 
> > wenn jemand meint, dass wir mehr brauchen und dass er einer davon ist,
> > wuerde ich vorschlagen justin zu kontaktieren.
>
> Dh. außerhalb dieser Liste per Mail?

z.B.

> > > > - schnellere Bearbeitung von requests
> > ich sehe noch das problem, inwieweit aenderungen vorher reviewed/getestet
> > werden/sein sollten.
> 
> Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne
> commit, sondern auch ohne Test- weil's einfach niemanden interessiert.

das ist aber kein problem des maintainers, sondern der community.
da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei
mir zB., alles selbst zu testen.

> Vielleicht könnte ein -dev Zweig helfen solche Probleme wie den
> eingeführten Fehler abzumildern.

macht den prozess aber noch traeger/langwieriger,
wenn dann noch zwei merges noetig sind,
user-fork -> dev-fork -> master...
siehe auch naechster punkt:

> > wobei aber wohl auch momentan ein allgemeines weiterkommen wichiger ist,
> > als der eine oder andere neue bug.

> > (ein schoenes beispiel war, wie justin zuletzt relativ hektisch
> >  diesen germerged hatte:
> > https://github.com/volkszaehler/volkszaehler.org/pull/47
> >  und da prompt ein bug drin war, der die api unbrauchbar gemacht hat
> 
> Du meinst nach 6 Wochen ist Hektik aufgekommen ;?

ja genau.
er hatte wohl (soll er mich korrigieren wenn ich das falsch
interpretiere) den relativ hektisch einfach ohne test gemerged,
nachdem er solange rumlag, und nachgefragt wurde warum er nicht
gemerged ist.

> > http://www.mail-archive.com/volkszaehler-dev@lists.volkszaehler.org/msg01921.html
> >  und der bei einer kurzen review (justin ist kein programmierer),
> >  oder einem test woanders als beim autor, aufgefallen waehre.
> 
> Korrekt- hat aber keine gemacht :/

wie gehabt, wir (bzw. wohl justin) sehen darin nicht die alleinige
verantwortung des maintainers, und haben auch nicht die resourcen
(zeit) dafuer.

> Und um hier aktiv etwas beizutragen: ich habe immer noch einen
> Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin-
> die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von
> keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen...

ich wollte schonmal dazu sagen:
was genau hindert dich daran, den test-code zu commiten und einen
pull-request zu stellen?
das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein
(wenig?) vorhandener code veraendert wird.

> > und das problem, dass die aenderungen schnell unuebersichtlich
> > werden,
> > und man sich schwerer tut grosse pull requests zu mergen,
> > als kleinere fixes fuer einfache probleme.
> 
> Ich bin auch kein Git Experte, hatte aber das Problem dass Github alle
> meine Commits in den schon bestehenden PR gepackt hat- kleiner ging erstmal
> nicht...

sehe ich auch so,
ist aber wohl auch eine eigenschaft von git?
(wobei ich gestern schonmal rausgefunden habe, wie man einzelne commits
 mergen kann, auch wenn's etwas umstaendlich erscheint.)

> > ich denke es waehre da sinnvoll aenderungen vorher kurz zu diskutieren,
> > zB hier (oder in den github issues?) und zu einem konsens zu kommen.
> 
> Mehr als die Sachen per Mail hier anzupreisen kann ich wohl nicht tun.
> Oder doch?

denke nicht, siehe community-problem.
siehe auch der naechste punkt.
(auch sprach ich von pull-requests, die manchmal reinkommen ohne dass
 es hier einen thread dazu gibt, die liegen dann noch laenger rum ;) )

> > es gab es ja zB den thread
> > "Feedback benötigt: vzlogger / aggregation / random meter / sml-pull /
> > s0-meter"
> > ( http://article.gmane.org/gmane.network.volkszaehler.devel/1572 )
> > der leider recht schleppend verlief.
> >
> > die letzte meldung von justin dazu war...
> > http://volkszaehler.org/pipermail/volkszaehler-dev/2013-August/003005.html
> > On Wed, 28 Aug 2013 23:51:03 +0200 Justin Otherguy <
> > jus...@justinotherguy.org> wrote:
> > > korrekt (leider). Die Patches lassen sich nicht "g'schwind(TM)" mergen.
> > > Scheitert an magischen git-Kräften (und der alternativ benötigten Zeit).
> > > Falls mir Jemand beispringen möchte: das ist eine gute Gelegenheit! ;-)
> >
> > darauf hatte sich niemand gemeldet...
> > ich werde mir das sonst mal anschauen.
>
> Logger ist leider nicht mein Thema :(

wobei's da eher um das git-thema geht,
(bei dem pull-request zeigt github nicht an, dass der automatisch
 merge-bar sei, sonst haette justin schon laenger auf den button
 geklickt.)

> vg
> Andreas

- Thorben

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

[Florian Knodt]

Hallo,

Am 27.09.2013 13:52, schrieb Thorben Thuermer:
> wie gehabt, wir (bzw. wohl justin) sehen darin nicht die alleinige
> verantwortung des maintainers, und haben auch nicht die resourcen
> (zeit) dafuer.

Kann es ja auch nicht sein - den Core mag man testen können, beim
Drumherum gibt es stellen, die nur sehr wenige Leute nutzen/kennen - wie
soll das jemand, der weder die Geräte noch das Wissen hat, testen? Da
müssen die passenden Tests - oder wenn es keinen Tester gibt eben dann
nachträglich Bug-Reports - von Außen kommen.

>> Ich bin auch kein Git Experte, hatte aber das Problem dass Github alle
>> meine Commits in den schon bestehenden PR gepackt hat- kleiner ging erstmal
>> nicht...
> sehe ich auch so,
> ist aber wohl auch eine eigenschaft von git?

Richtig - am besten eine Branch erzeugen und daraus den Pull-Request
commiten - dann kann man am Original weiterarbeiten ohne den Request zu
verändern. Generell sollte man seine Änderungen immer in Branches
halten, dann bleibt das Original auf dem Stand des offiziellen Repos und
darauf aufbauende Pull-Requests lassen sich wesentlich einfacher mergen.

-- 
Mit freundlichen Grüßen  ||  Sincerely yours
Florian Knodt ·· Im Teich 11 ·· 56648 Saffig
www.adlerweb.info · www.56648.de · @adlerweb



signature.asc
Description: OpenPGP digital signature

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

[Patrik Karisch]

Gibt es denn nun mal Meldungen, wie es konkret mit dem Projekt weitergehen soll?

Gut bugfixen ist klar, aber was ist mit zukünftigen Entwicklungen?

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

[Thorben Thuermer]

On Sat, 5 Oct 2013 12:22:23 +0200
Patrik Karisch  wrote:
> Gibt es denn nun mal Meldungen, wie es konkret mit dem Projekt weitergehen 
> soll?
> Gut bugfixen ist klar, aber was ist mit zukünftigen Entwicklungen?

dann entwickel' doch, viel spass.

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

[Justin Otherguy]

Hi Patrik,

Am 05.10.2013 um 12:22 schrieb Patrik Karisch:

> Gibt es denn nun mal Meldungen, wie es konkret mit dem Projekt weitergehen 
> soll?

zuerst mal danke für deinen Einsatz - ne Antwort ist das mindeste, was du dir 
verdient hast, da hast du absolut recht.
Danke, dass du diese Diskussion angestossen hast und sorry, dass ich mich erst 
jetzt zu Wort melde.

In diesem Thread wurden mehrere Dinge diskutiert - Thorben hat die meisten 
Aspekte schon beantwortet (und mir ist keine Stelle aufgefallen, an der ich ihm 
hätte widersprechen können; obwohl ich das ja gerne mal tue).

Drum will ich auf ner anderen Ebene antworten:
das Wesentliche, woran es uns m.E. hier im Projekt mangelt (vlt.: bisher 
gemangelt hat?) waren Leute, die Zeit an der richtigen Stelle(TM) investiert 
haben. Die richtigen Stellen(TM) sind m.E.:
- Code-Beiträge: m.E. fehlen uns nicht die Commiter (also die mit 
commit-Rechten), sondern Contributoren (also die, die PRs stellen) und Tester 
(also die, die PRs testen)
- Unterstützung in git (sowohl Erklärbären als auch Leute, die mit den PRs 
kämpfen - vlt. ist git an sich auch mehr Problem als Lösung)
- Tests: Thorben hat schon angemerkt, dass auch Jemand ohne commit-Rechte ein 
"ich hab das so bei mir getestet, und zwar die folgenden 5 Features und es 
läuft alles total super" auf der Liste absetzen kann; dann kann ein Zweiter mit 
commit-Rechten das viel entspannter mergen, auch wenn er selbst gerade [keine 
Zeit | kein Equipment | kein *] hat; das sagt noch nichts darüber aus, ob wir 
zu wenige Commiter haben; von mir aus können das auch mehr Leute sein; mir geht 
es hier eher um ein 4-Augen-Prinzip. Als Voraussetzungen für commit-Rechte sehe 
ich im Wesentlichen: treibt sich schon ne Weile hier rum; commitet erst, wenn 
er sich überzeugt hat, dass der Commit nicht weh tut (selbst oder indem er auf 
die passende Info per Mail oder IRC wartet); ich halte es für klug, das 
Verhältnis "Anzahl Contributoren"/"Anzahl Commiter" überschaubar zu halten; im 
Zweifel könnt ihr euch gerne als Commiter anbieten. Wie gesagt: dass wir 
derzeit zu wenige Commiter hätten, sehe ich nicht; ob Unit-Tests die richtige 
Lösung sind kann ich nicht beantworten; klingt für mich erst mal gut - 
wenngleich ich befürchte, dass das (im Moment) ne Nummer zu groß ist; eine 
Checkliste scheint mir persönlich ein besseres "Aufwand/Nutzen"-Verhältnis zu 
haben
- Issues: wir haben einen - ziemlich verwaisten - Bugtracker; ob wir diesen 
oder den von github nutzen - für mich ist beides ok; unser Problem ist hier 
m.E. nicht das Werkzeug, sondern ein Mangel an a) Leuten, die Issues melden und 
(das drückt wesentlich mehr) b) Leuten, die Issues angehen; von mir aus kann 
das auch auf github sein
- Doku: das scheint mir nicht mehr zu unseren großen Sorgen zu gehören; das 
funktioniert mit dem Wiki m.E. gut genug (klar - das kann natürllch auch noch 
besser werden); ich denke tatsächlich, dass die Software insgesamt auf einem 
Stand angelangt ist, der es den meisten, die hier "angespült" werden erlaubt, 
diese zum Laufen zu bekommen (zur Not mit Hilfe aus der ML oder/und dem IRC - 
danke an der Stelle auch nochmal an die Helfer!); wobei: Doku zu den paar 
Standard-github-Prozessen ("wie merge ich einen PR, der nicht automatisch 
gemergt werden kann?", "wie...") wäre m.E. hilfreich; auf die passende Doku zu 
verweisen (nein, "man git" ist keine gültige Antwort) würde ja vlt. ausreichen

So kommen wir m.E. zum schnelleren Mergen von Patches, ohne dass das zu Lasten 
der Qualität geht. Ob uns dann weitere Unterzweige helfen, lasse ich offen - 
ich bin nicht dagegen; glaube aber, dass sie uns im Moment nicht helfen, 
sondern uns behindern.

Und noch mehr grundsätzliche Anmerkungen:
- ein Fork ist mit git (im Gegensatz zu cvs) keine Revolte mehr, sondern der 
naheliegendste Schritt, wenn du zum Projekt beitragen möchtest. Das kannst du 
immer tun - ich freu mich über Forks und PRs
- den Vorteil, weitere Entwickler zur github-Gruppe hinzuzunehmen, habe ich 
auch noch nicht verstanden; wir haben das bei vzlogger so gemacht (Idee wurde 
auf dem EC geboren - dazu weiter unten mehr), da wir hier alle, die aktiv an 
vzlogger entwickeln, unter einem Hut haben wollten (wie gut das funktioniert 
ist eine andere Geschichte); wenn du Entwickler bist und gerne zur 
github-Gruppe gehören möchtest: melde dich - warum nicht? Ich bin übrigens auch 
nicht der Einzige, der diese Rechte vergeben darf.
- ich halte es für wichtig, sehr sparsam mit Zeit umzugehen; daraus ergibt 
sich: sind wirklich die Werkzeuge unser Problem? dann sollten wir sie 
auswechseln; sind wirklich fehlende Berechtigungen unser Problem? dann sollten 
wir diese verteilen. Anderenfalls verbringen wir zu viel Zeit mit den falschen 
Problemen.
- ich bin sehr skeptisch mit Änderungen, die viel Zeit (Einzelner oder 
Mehrerer) erfordern; die Unit-Tests klingen für mich sehr gut; @Andreas: wenn 
du das bauen kannst (mit oder ohne Unterstützung): prima! Mir ist nicht klar, 
inw

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

[Andreas Goetz]

Hallo *,

2013/9/27 Thorben Thuermer 

> > > > > - schnellere Bearbeitung von requests
> > > ich sehe noch das problem, inwieweit aenderungen vorher
> reviewed/getestet
> > > werden/sein sollten.
> >
> > Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne
> > commit, sondern auch ohne Test- weil's einfach niemanden interessiert.
>
> das ist aber kein problem des maintainers, sondern der community.
> da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei
> mir zB., alles selbst zu testen.
>

Ich engagiere mich gerade bzgl. der PRs zum Einsatz von Composer. Leider
ist mein Eindruck dass die Arbeit daran ziemlich für die Tonne ist da/wenn
die Maintainer keine Kommentare abgeben.


> > Und um hier aktiv etwas beizutragen: ich habe immer noch einen
> > Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin-
> > die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von
> > keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen...
>
> ich wollte schonmal dazu sagen:
> was genau hindert dich daran, den test-code zu commiten und einen
> pull-request zu stellen?
> das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein
> (wenig?) vorhandener code veraendert wird.
>
>
Genau das habe ich vor ca. 6 Wochen gemacht und vor 3 Wochen die letzten
offenen Anmerkungen behoben. Seitdem ruht der Request und die Bits setzen
langsam Staub an. Für mich als Contributer demotivierend...

...



> denke nicht, siehe community-problem.
> siehe auch der naechste punkt.
> (auch sprach ich von pull-requests, die manchmal reinkommen ohne dass
>  es hier einen thread dazu gibt, die liegen dann noch laenger rum ;) )
>
>
Ich bin mir nicht sicher wie's aktuell aufgesetzt ist- aber gehen die git
Notifications auch and die Entwickler-ML?

Im Moment bleibe ich bei meiner Einschätzung- VZ ist von Entwicklerseite
sehr schwer zugänglich. Voraussetzung für den Aufbau einer entsprechenden
Community ist aus meiner Sicht mehr Agilität.

vg
Andreas

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

[Thorben Thuermer]

On Tue, 12 Nov 2013 10:05:59 +0100
Andreas Goetz  wrote:
> 2013/9/27 Thorben Thuermer 
> > > > > > - schnellere Bearbeitung von requests
> > > > ich sehe noch das problem, inwieweit aenderungen vorher
> > reviewed/getestet
> > > > werden/sein sollten.
> > >
> > > Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht
> > > nur ohne commit, sondern auch ohne Test- weil's einfach niemanden
> > > interessiert.
> >
> > das ist aber kein problem des maintainers, sondern der community.
> > da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei
> > mir zB., alles selbst zu testen.
> >
> 
> Ich engagiere mich gerade bzgl. der PRs zum Einsatz von Composer.
> Leider ist mein Eindruck dass die Arbeit daran ziemlich für die Tonne
> ist da/wenn die Maintainer keine Kommentare abgeben.

hatte ich ja...
wollte gerade einen neuen schreiben, als deine mail kam.

neuer kommentar:
schick wieviel da aufeinmal passiert...
magst du dich erstmal mit robert absprechen, wessen loesung jetzt
besser ist, zumal ihr ja anscheinend an den gleichen sachen arbeitet,
und die patches vermutlich nicht kompatibel sind?

> > > Und um hier aktiv etwas beizutragen: ich habe immer noch einen
> > > Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit
> > > gekommen bin- die Sache ist nämlich tatsächlich recht filigran.
> > > Bisher gabs nur von keiner Seite Interesse die irgendwo
> > > aufzunehmen oder zu pflegen...
> >
> > ich wollte schonmal dazu sagen:
> > was genau hindert dich daran, den test-code zu commiten und einen
> > pull-request zu stellen?
> > das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein
> > (wenig?) vorhandener code veraendert wird.
>
> Genau das habe ich vor ca. 6 Wochen gemacht und vor 3 Wochen die
> letzten offenen Anmerkungen behoben. Seitdem ruht der Request und die
> Bits setzen langsam Staub an. Für mich als Contributer
> demotivierend...

ja, hangt bei mir daran, dass ich das nochmal testen wollte
(die erste version war ja nun eindeutig kaputt ;) ),
und nicht soviel zeit habe momentan.
(und die dann noch mit dem lesen von -users verschwende...)
(und ausserdem ich persoenlich composer nicht mag,
 und nicht soviele argumente dafuer kamen...
 (ausser dass travis-ci das braucht)
 aber mir soll's recht sein, hatte das auch gerade mit justin
 angesprochen, was er davon haelt.)

aber wie gehabt,
testen koennte das aber auch jeder andere mal,
und feedback geben ob's bei ihm funktioniert!
dafuer braucht man keine commit-rechte.

(wuerde vlt. helfen wenn die github-kommentare auch an die -dev liste
 gehen wuerden, justin, kann man das einrichten?)

> ...
> 
> > denke nicht, siehe community-problem.
> > siehe auch der naechste punkt.
> > (auch sprach ich von pull-requests, die manchmal reinkommen ohne
> > dass es hier einen thread dazu gibt, die liegen dann noch laenger
> > rum ;) )
>
> Ich bin mir nicht sicher wie's aktuell aufgesetzt ist- aber gehen die
> git Notifications auch and die Entwickler-ML?

hatte den satz oben gerade geschrieben, bevor ich deinen gelesen
hatte ;)
dass die notifications da momentan nicht hingehen solltest du sehen,
da du ja auf der liste bist.

> Im Moment bleibe ich bei meiner Einschätzung- VZ ist von
> Entwicklerseite sehr schwer zugänglich. Voraussetzung für den Aufbau
> einer entsprechenden Community ist aus meiner Sicht mehr Agilität.
> 
> vg
> Andreas

- Thorben

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

[Andreas Goetz]

Hi,

2013/11/12 Thorben Thuermer 

> On Tue, 12 Nov 2013 10:05:59 +0100
> Andreas Goetz  wrote:
> ...
> > > das ist aber kein problem des maintainers, sondern der community.
> > > da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei
> > > mir zB., alles selbst zu testen.
> > >
> >
> > Ich engagiere mich gerade bzgl. der PRs zum Einsatz von Composer.
> > Leider ist mein Eindruck dass die Arbeit daran ziemlich für die Tonne
> > ist da/wenn die Maintainer keine Kommentare abgeben.
>
> hatte ich ja...
> wollte gerade einen neuen schreiben, als deine mail kam.
>
> neuer kommentar:
> schick wieviel da aufeinmal passiert...
> magst du dich erstmal mit robert absprechen, wessen loesung jetzt
> besser ist, zumal ihr ja anscheinend an den gleichen sachen arbeitet,
> und die patches vermutlich nicht kompatibel sind?
>
>
Es gibt keine Überschneidung.  Robert macht einen Patch, ich nicht, wir
diskutieren im git -> passt.

...
> > > ich wollte schonmal dazu sagen:
> > > was genau hindert dich daran, den test-code zu commiten und einen
> > > pull-request zu stellen?
> > > das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein
> > > (wenig?) vorhandener code veraendert wird.
> >
> > Genau das habe ich vor ca. 6 Wochen gemacht und vor 3 Wochen die
> > letzten offenen Anmerkungen behoben. Seitdem ruht der Request und die
> > Bits setzen langsam Staub an. Für mich als Contributer
> > demotivierend...
>
> ja, hangt bei mir daran, dass ich das nochmal testen wollte
> (die erste version war ja nun eindeutig kaputt ;) ),
> und nicht soviel zeit habe momentan.
> (und die dann noch mit dem lesen von -users verschwende...)
> (und ausserdem ich persoenlich composer nicht mag,
>  und nicht soviele argumente dafuer kamen...
>

Composer hat mit den Unit Tests nichts zu tun.


>  (ausser dass travis-ci das braucht)
>

und Travis auch nicht. Zumindest Travis wird dadurch einfacherm, aber das
ist hier gar nicht das Thema, oder war jedenfalls nciht meins  (aber ich
habe hier tatsächlich noch einen Travis-Patch, aber mit dem warte ich auf
a) Unit Tests und b) Composer...)


> ...
> aber wie gehabt,
> testen koennte das aber auch jeder andere mal,
> und feedback geben ob's bei ihm funktioniert!
> dafuer braucht man keine commit-rechte.
>
>
Macht wohl keiner. Aber genau daher mein zweiter Kommentar zum Composer-PR
von Robert. Selbst wenn ich teste und kommentiere habe ich wenig Lust das
alles umsonst zu machen. Insofern wäre _ein_ Kommentar von den Committern
schon nett damit wir am Ende nicht mit viel Arbeit und ohne Commit dastehen.

> Ich bin mir nicht sicher wie's aktuell aufgesetzt ist- aber gehen die
> > git Notifications auch and die Entwickler-ML?
>
> hatte den satz oben gerade geschrieben, bevor ich deinen gelesen
> hatte ;)
> dass die notifications da momentan nicht hingehen solltest du sehen,
> da du ja auf der liste bist.
>
> > Im Moment bleibe ich bei meiner Einschätzung- VZ ist von
> > Entwicklerseite sehr schwer zugänglich. Voraussetzung für den Aufbau
> > einer entsprechenden Community ist aus meiner Sicht mehr Agilität.
> >
> > vg
> > Andreas
>
> - Thorben
>

Vmtl. könnte man für die ML (falls es nix anderes gibt) einen User mit
Adresse der ML bei github anlegen der das Repo abonniert. Geht sicher auch
eleganter...

vg
Andreas

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

[Robert Ewald]

Hi,

manchmal liest der Robert sogar mit :-) Bin bislang nicht auf die Idee
gekommen hier gross zu schreiben.

Ich kann Euch versichern, Composer ist für PHP-Projekte in jeder Hinsicht
ein Fortschritt: die Installation von externen Komponenten, die Handhabung
ihrer Abhängigkeiten, ihre Aktualisierung und auch die Benutzung wird
extrem vereinfacht.
Ein Beispiel:
$ git clone -b unittests https://github.com/r3wald/volkszaehler.org.git
$ cd volkszaehler.org/
$ composer update
$ vendor/bin/phpunit
Auf der anderen Seite schweben mir noch ein paar Dinge für das Projekt vor,
bei denen Composer die Grundlage wäre. Ich kann/will nicht für zusätzliche
Abhängigkeiten parallel Wiki und install.sh pflegen. Und lieber verwende
ich gut getestete Komponenten eines Frameworks (die ich so bequem
installieren kann), als das Rad neu zu erfinden.

Ich würde aber auch gerne mal ein paar Gegenargumente zu Composer hören.

Mein Fahrplan sieht im Moment so aus:
1. Composer
2. Unittests
3. erweitern und verbessern

Zu den Unittests kann ich nur schreiben, was ich hier schon schrieb:
https://github.com/volkszaehler/volkszaehler.org/pull/59 . Andreas' Tests
sind keine Unittests sondern Funktionstests. Das ist der Tatsache
geschuldet, dass es keine Units (siehe Wikipedia: funktionalen Einzelteile)
gibt, die man testen könnte. Beide Arten von Tests können sich aber
ergänzen.

Der Test für die Configuration-Klasse mag trivial sein, aber so
funktioniert das nunmal. Irgendwer hat doch mal im Quelltext gefragt, ob
man die Konfiguration nicht mit JSON kodieren könne. Klar, kann man. Aber
wer stellt sicher, dass die Klasse dann auf Anfragen noch ganz genauso
reagiert?
Das ist auch nur ein Anfang. Aber ein so kleiner, dass man ihn - denke ich
- ohne weiteres ins Projekt aufnehmen könnte.

Ich persönliche kämpfe noch mit den Feinheiten von Git und github. Alles
was über SVN-Funktionalität hinausgeht, macht mir Schwierigkeiten. Daher
auch unverständliche Commits und auch der zweite Pull Request.

@Andreas:
1. Welche Commits gefallen Dir denn nicht am neuen Pull Request?
cf0598c
ist
leider notwendig, weil dort Pfade fest in der Anwendung eingebrannt waren.
Und 
b2991be
habe
ich rückgängig gemacht.
2. Wenn Code zu komplex ist um ihn zu testen, dann ist er eben zu komplex.
Dann muss er überarbeitet werden bis man ihn testen kann.

Viele Grüße
Robert

PS: PEAR hat den großen Nachteil, dass es seine Bibliotheken immer zentral
installiert. Ich habe es selbst fast ein Jahrzehnt lang benutzt und ich
weiß, dass es schwierig ist unterschiedliche Versionen einer Bibliothek für
verschiedene Projekte zu verwenden, wenn diese per PEAR installiert werden
sollen. Mit Composer gibt es dieses Problem schlichtweg nicht. Jedes
Projekt ist für sich vollständig.


Am 12. November 2013 12:14 schrieb Andreas Goetz :

> Hi,
>
> 2013/11/12 Thorben Thuermer 
>
>> On Tue, 12 Nov 2013 10:05:59 +0100
>> Andreas Goetz  wrote:
>> ...
>>
>> > > das ist aber kein problem des maintainers, sondern der community.
>> > > da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei
>> > > mir zB., alles selbst zu testen.
>> > >
>> >
>> > Ich engagiere mich gerade bzgl. der PRs zum Einsatz von Composer.
>> > Leider ist mein Eindruck dass die Arbeit daran ziemlich für die Tonne
>> > ist da/wenn die Maintainer keine Kommentare abgeben.
>>
>> hatte ich ja...
>> wollte gerade einen neuen schreiben, als deine mail kam.
>>
>> neuer kommentar:
>> schick wieviel da aufeinmal passiert...
>> magst du dich erstmal mit robert absprechen, wessen loesung jetzt
>> besser ist, zumal ihr ja anscheinend an den gleichen sachen arbeitet,
>> und die patches vermutlich nicht kompatibel sind?
>>
>>
> Es gibt keine Überschneidung.  Robert macht einen Patch, ich nicht, wir
> diskutieren im git -> passt.
>
>  ...
>> > > ich wollte schonmal dazu sagen:
>> > > was genau hindert dich daran, den test-code zu commiten und einen
>> > > pull-request zu stellen?
>> > > das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein
>> > > (wenig?) vorhandener code veraendert wird.
>> >
>> > Genau das habe ich vor ca. 6 Wochen gemacht und vor 3 Wochen die
>> > letzten offenen Anmerkungen behoben. Seitdem ruht der Request und die
>> > Bits setzen langsam Staub an. Für mich als Contributer
>> > demotivierend...
>>
>> ja, hangt bei mir daran, dass ich das nochmal testen wollte
>> (die erste version war ja nun eindeutig kaputt ;) ),
>> und nicht soviel zeit habe momentan.
>> (und die dann noch mit dem lesen von -users verschwende...)
>> (und ausserdem ich persoenlich composer nicht mag,
>>  und nicht soviele argumente dafuer kamen...
>>
>
> Composer hat mit den Unit Tests nichts zu tun.
>
>
>>  (ausser dass travis-ci das braucht)
>>
>
> und Travis auch nicht. Zumindest Travis wird dadurch einfacherm, aber das
> ist hier gar nicht da

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

[justin]

Servus,

Am 12.11.2013 um 20:32 schrieb Robert Ewald :

> Ich kann Euch versichern, Composer ist für PHP-Projekte in jeder Hinsicht ein 
> Fortschritt: die Installation von externen Komponenten, die Handhabung ihrer 
> Abhängigkeiten, ihre Aktualisierung und auch die Benutzung wird extrem 
> vereinfacht.
> Ein Beispiel:
> $ git clone -b unittests https://github.com/r3wald/volkszaehler.org.git
> $ cd volkszaehler.org/
> $ composer update
> $ vendor/bin/phpunit 
[…]
> Ich würde aber auch gerne mal ein paar Gegenargumente zu Composer hören.

ich kenne Composer gar nicht (nein, das ist nicht das Gegenargument (c; ) - was 
sind die Ziele?
- [vereinfachte] Tests (und damit: potenziell höhere Code-Qualität)?
- vereinfachter Einstieg für neue Entwickler? (oder: wird der Einstieg damit 
[noch] schwieriger?)
- vereinfachte Installation der Middleware für neue Nutzer? (klingt für mich 
nicht so, muss aber auch kein Ziel sein; die Installation sollte m.E. dadurch 
zumindest nicht verkompliziert werden)


Gruss, J.

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

[Robert Ewald]

Hallo Justin,

Composer ist ein Werkzeug um Abhängigkeiten bei PHP-Projekten zu verwalten.
Du schreibst in eine Datei (composer.json) welche Bibliotheken Du in
welchen Versionen haben möchtest (optional *) und rufst Composer auf. Das
Tool installiert dann in einen Ordner vendor/ alle angegebenen Bibliotheken
und falls nötig deren Abhängigkeiten. Composer stellt einen Autoloader zur
Verfügung, so dass im Projekt nur noch "require 'vendor/autload.php' stehen
muss und alles steht zur Verfügung.
Die zur Verfügung stehenden Bibliotheken sind alle hier registriert:
http://packagist.org/, gehostet werden sie in der Regel auf Github.
Bei der Installation der Sachen kann zwischen Entwickler und Anwender
unterschieden werden, so dass beispielsweise ersterer PHPUnit oder
Debugging-Tools zusätzlich installiert bekommt und letzterer nicht.
Im Prinzip funktioniert Composer wie PEAR, nur projektspezifisch.

Genau erklärt wird alles hier: http://getcomposer.org/doc/00-intro.md

Vorteile:
* vereinfachte Installation von Abhängigkeiten, inklusive von deren
Abhängigkeiten
* ein sehr gut getesteter Autoloader, der auch für den eigenen Code
verwendet werden kann
* 3rd-Party-Software wandert in einen eigenen Ordner im Projekt

Ich möchte gerne Erweiterungen einbauen, die neue Abhängigkeiten einführen.
Ohne Composer müsste ich mir ein Skript schreiben, dass die Sachen
runterlädt und auspackt. Und die Anwendung müsste die einzelnen
Installationsorte kennen und die jeweiligen Autoloader laden.
Mit Composer beschränkt dich der Aufwand auf neue Einträge in der
composer.json und den Aufruf von "composer install" bzw "composer update".

Ich glaube Composer steht bei PHP für einen Paragimenwechsel in der
Programmierung. Von http://de.wikipedia.org/wiki/Not-invented-here-Syndrom geht
man über zu http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants
 .

Robert


Am 12. November 2013 22:52 schrieb :

> Servus,
>
> Am 12.11.2013 um 20:32 schrieb Robert Ewald :
>
> > Ich kann Euch versichern, Composer ist für PHP-Projekte in jeder
> Hinsicht ein Fortschritt: die Installation von externen Komponenten, die
> Handhabung ihrer Abhängigkeiten, ihre Aktualisierung und auch die Benutzung
> wird extrem vereinfacht.
> > Ein Beispiel:
> > $ git clone -b unittests https://github.com/r3wald/volkszaehler.org.git
> > $ cd volkszaehler.org/
> > $ composer update
> > $ vendor/bin/phpunit
> […]
> > Ich würde aber auch gerne mal ein paar Gegenargumente zu Composer hören.
>
> ich kenne Composer gar nicht (nein, das ist nicht das Gegenargument (c; )
> - was sind die Ziele?
> - [vereinfachte] Tests (und damit: potenziell höhere Code-Qualität)?
> - vereinfachter Einstieg für neue Entwickler? (oder: wird der Einstieg
> damit [noch] schwieriger?)
> - vereinfachte Installation der Middleware für neue Nutzer? (klingt für
> mich nicht so, muss aber auch kein Ziel sein; die Installation sollte m.E.
> dadurch zumindest nicht verkompliziert werden)
>
>
> Gruss, J.
>
>

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

[Andreas Goetz]

2013/11/12 Robert Ewald 

Genau erklärt wird alles hier: http://getcomposer.org/doc/00-intro.md
>
> Vorteile:
> * vereinfachte Installation von Abhängigkeiten, inklusive von deren
> Abhängigkeiten
> * ein sehr gut getesteter Autoloader, der auch für den eigenen Code
> verwendet werden kann
> * 3rd-Party-Software wandert in einen eigenen Ordner im Projekt
>
>
Abgesehen davon, dass sich Composer zum defacto Standard für PHP
Paketmangement zu entwickeln scheint (+/- PEAR) scheint es z.B. von
Doctrine (http://www.doctrine-project.org/downloads/) auch keine Pakete der
aktuellen 2.4er Version mehr zu geben.
Der einzige offzielle Installationsweg scheint mittlerweile Composer zu
sein.

vg
Andreas

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

[Andreas Goetz]

Hier nochmal ein  Beispiel zu "lessons learned" bzgl. Composer aus der
Reimplementierung meiner VideoDB Applikation (videodb.net):

1. Ich möchte meinen Code in eine Library verwandeln. Dafür kann ich
entweder alles in Komponenten verpacken oder ich nutze bestehende.
2. Also switche ich von meinem httpClient auf guzzle:

"require": {
"guzzle/guzzle": "~3.7",
},

3. Ich möchte http Requests auch cachen und switche dafür von meinem Cache
auf Doctrine (weil der nämlich von Guzzle unterstützt wird):

"require": {
"guzzle/guzzle": "~3.7",
"doctrine/cache": "~1"
},

4. Ich suche noch Hilfe bei der Fehlersuche während der Entwicklung:

"require-dev": {
"filp/whoops": "~1",
"phpunit/phpunit": "~3.7"
},

5. Ich brauche einen Autoloader für meinen neuen, besseren Code:

"autoload": {
"psr-0": {
"VideoDB": "."
}
}

6. Jetzt noch `composer update` und alles was ich brauche ist an Ort und
Stelle. Einfacher geht's nicht.

Insgesamt weniger als 30min Arbeit und der Code lief ohne dass ein einziger
require Statement notwendig gewesen wäre.

--

Hat alles mit Volkszähler nichts zu tun? Gestern fragte jemand nach
"Grafiken" aus dem VZ. Braucht leider JpGraph- auch da muss sich der Newbie
erstmal durchwühlen. Bei Installation über Composer wär's dabei...

vg
Andreas



2013/11/14 Andreas Goetz 

> 2013/11/12 Robert Ewald 
>
> Genau erklärt wird alles hier: http://getcomposer.org/doc/00-intro.md
>>
>> Vorteile:
>> * vereinfachte Installation von Abhängigkeiten, inklusive von deren
>> Abhängigkeiten
>> * ein sehr gut getesteter Autoloader, der auch für den eigenen Code
>> verwendet werden kann
>> * 3rd-Party-Software wandert in einen eigenen Ordner im Projekt
>>
>>
> Abgesehen davon, dass sich Composer zum defacto Standard für PHP
> Paketmangement zu entwickeln scheint (+/- PEAR) scheint es z.B. von
> Doctrine (http://www.doctrine-project.org/downloads/) auch keine Pakete
> der aktuellen 2.4er Version mehr zu geben.
> Der einzige offzielle Installationsweg scheint mittlerweile Composer zu
> sein.
>
> vg
> Andreas
>