Wunschliste FHEM Entwicklung

[RichardCZ]

1. Modernisierung der Dev-Infrastruktur.

Ich sehe, dass irgendwann 2016 auf einen eigenen Trac/SVN Server umgezogen wurde. Git wurde aus diversen Gründen verworfen, aber vielleicht wäre 2020 eine gute Gelegenheit die Sache nochmal zu begutachten. Subversion nutze ich selbst seit ca. 2006, Trac - glaube ich - so 2011 bis 2015.

Da gibt es mittlerweile echt Besseres. Heutzutage nutzt man Git und wenn man - wie ich - ein wenig cloudfeindlich eingestellt und knauserig ist, dann hat man einen eigenen GitLab server. Wenn gewünscht, kann ich "mal eben" eine GitLab VM aufsetzen und da FHEM trunk reinimportieren, damit man rumspielen kann.

Nota bene, wenn Trac derzeit bei FHEM eigentlich nur als Source Browser missbraucht wird. Ich würde mir zum Beispiel wünschen, dass anstelle dieser Wunschliste das Trac Ticketsystem benutzt wird. Wesentlich bessere Integration von Wunschliste, Bugreports etc. mit Patches. Ich meine dann wären "wir hier" so auf dem Stand von 2014.

2. FHEM source code und Qualität

Es soll sich bitte Niemand auf den Schlips getreten fühlen. FHEM ist real existierend und besser als nix. Auf jeden Fall besser als irgendwelche eleganten aber rein theoretischen Luftschlösser. Wollte ich gesagt haben, damit euch klar ist, dass mir das klar ist.

Aber...

Ich sehe im Code häufig etwas in der Art "Copyright 2005-2020 Mr. König". Der Perl Code ist technisch auf durchschnittlichem Prä-2005 Niveau. Es gibt kaum eine Programmzeile, die nicht gegen PBP verstößt (Und hey - das ist 2005 erschienen), es gibt keine Testsuite, die Namespaces und die Architektur sind sehr ... gewöhnungsbedürftig und fehleranfällig. Eine solide Grundlage sieht anders aus.

Das geht sicher besser. Die Hauptfrage lautet also: Will oder will man nicht? Ich schicke schon mal vorab: Die Antwort "Wasch mich, aber mach mich nicht nass" ist für mich gleichbedeutend mit "man will nicht". Mit anderen Worten: Ohne teils drastische Eingriffe in die Art und Weise wie der Code geschrieben wird kann man natürlich weiterhin - sicher auch noch die nächsten 10 Jahre - Feauturitis-Doctoring betreiben, aber so richtig Zukunft hat das nicht.

Das bitte ich zu bedenken, bevor nun (zeimlich sicher) die rechtfertigenden Antworten kommen warum alles in FHEM so ist wie es ist und dass doch eigentlich  alles bestens ist. Das ist es nämlich nicht. Ich kann jedoch für den Status Quo durchaus "Zeitmangel/Kapazitätsmangel/Man-möchte-gerne-weiß-es-aber-nicht-besser" als Erklärung akzeptieren.

Eventuell mal ausserhalb der Echokammer - in einer anderen Echokammer  - umschauen.

https://community.openhab.org/t/switching-from-fhem-to-openhab-2-what-to-expect/23221/13
https://openhabforum.de/viewtopic.php?t=1136

Ich möchte auch klarstellen, dass ich das Frontend erstmal komplett außen vor halte. Dazu kann und will ich mangels Kompetenz gar nix sagen. Ich rede rein über das Perl Backend. Da wäre also mein Wunsch, dass man mal richtig durchgreift. Bzw. ich sondiere ob der WIlle dazu überhaupt da ist, bevor ich Energie investiere.

3. Disclaimer

Nein, ich bin weder Besser- noch Alleswisser. Ich habe verglichen mit den meisten hier sicher wenig bis keinen Plan von Heimautomatisierung und will/muss da Vieles lernen. Ich habe - siehe oben - keinen Plan wie man gute responsive GUIs macht.

Ich habe nur 25 Jahre aktive Perl, Linux und DevOps Erfahrung und weiß wie man große Perl Projekte in größeren Teams durchzieht und robusten modernen Perl Code schreibt. That's all.

[CoolTux]

Hallo,

Erstmal herzlichen willkommen. Es gibt bereits ein weitere Möglichkeit über GitHub.
https://github.com/fhem

Privat verwende ich zum entwickeln zu Hause Gitea. Bin zufrieden damit.
Du baust bereits sehr früh eine ziemlich breite Kerbe. Eventuell wäre es hilfreich bei einigen Dingen die Dir auffallen in kleinen Schritten einfach Patches mit "besseren Code" beim jeweiligen Maintainer ein zu reichen.

Jede Hilfe ist willkommen.



Grüße

[herrmannj]

Moin auch von mir,

Um den Deckel auf dem Topf zu lassen:

- 80% "Machen" ist besser als 100% "Wollen" .
- Patch bitte als diff

Man muss verstehen, dass viele Module entstehen weil sich user hinsetzen und um einen, wie auch immer gearteten, eigenen Bedarf zu befriedigen, anfangen FHEM Module zu schreiben. Nicht notwendigerweise bringen die dann Programmiererfahrung mit, geschweige denn 25 Jahre Vollzeit programmieren.

Also, anstelle der Revolution ist der Weg eher die Evolution. Da kannst Du also perfekt unterstützen.

[justme1968]

zum verständiss von 1. ist vermutlich wichtig zu verstehen das es pro modul meist nur einen einzigen maintainer gibt und dieser sehr selten patches bekommt oder sie jemand anders an der entwicklung beteiligt. und nein, ich denke nicht das dies ein henne und ei problem bezüglich einer möglichen einfacheren beteiligung über git(hub) ist.

und zu 2. sollte man wissen das niemand interesse hat an einem 'fremden' oder dem eigenen modul das eventuell schon sehr lange funktioniert und für das keine wünsche offen sind dies auf den kopf zu stellen.

also einfach mit guten beispiel vorangehen und etwas besseres liefern .

ps: was die schicken frontends angeht: da gilt das erst recht.

pps: und dabei nicht vergessen: es geht um automatisierung die läuft idealer weise unsichtbar im hintergrund. ganz ohne schickes gui sondern ebenfalls unsichtbarer sprachsteuerung als frontend. vielleicht mit ein bisschen status ausgabe irgendwo.

[RichardCZ]

- 80% "Machen" ist besser als 100% "Wollen" .

Dann sind wir uns ja einig, weswegen ich ja auch schrieb

FHEM ist real existierend und besser als nix. Auf jeden Fall besser als irgendwelche eleganten aber rein theoretischen Luftschlösser. Wollte ich gesagt haben, damit euch klar ist, dass mir das klar ist.


Wo ich ein wenig Befürchtungen habe ist

- Patch bitte als diff

Also, anstelle der Revolution ist der Weg eher die Evolution. Da kannst Du also perfekt unterstützen.

Die "Evolution", die Du im Sinn hast (inkrementelle Änderungen), ist leider nur ein Teil dessen was Evolution wirklich ist.
Ein anderer Teil der Evolution sind Mutationen. Teils drastische, die u.U. nicht lebensfähige Organismen bewirken (die lässt man dann in den Experimental-Branches sterben).

Klar kenne ich refactoring. FHEM ist jetzt nicht das erste Perl Projekt, bei dem die Maintainer zwar gerne Verbesserungen hätten, aber bitteschön  "behutsam inkrementell". Alte riesige Legacy-Kodbasis in Firmen: gleiches Spiel.

Problem hier ist, dass offensichtlich mit einem bestimmten Codestandard angefangen wurde und nun haben sich alle dran gehalten. Dass der Code nicht von Profis stammt ist natürlich klar. Ebenso ist klar, dass man vermutlich viele Contributors nicht erreichen würde, wenn man wesentlich stringentere Anforderungen an den Code legen würde.

Auf der anderen Seite bitte ich zu bedenken (nichts anderes als eine Sondierung ist das was ich gerade hier mache), dass man aber einen Profi aber auch nicht mit Sandkastenspielen locken kann.

"Patch bitte als diff".

Pull request nennt sich das, und ja - gerne - aber ich hätte dann doch schon gerne vorab geklärt ob es nicht vergebene Liebesmüh' ist. Weil eine Woche zu investieren um z.B. die vermaledeiten Prototypen rauszuschmeissen nur um dann zu hören "Nö - wir mögen das aber so"... da hätte ich keine große Lust zu.

Ok. Folgende Idee. Es gibt hier doch so ne Ecke "Codeschnipsel". Vielleicht könnte ich da einen Thread "Richards Perl Ecke" aufmachen und kleine Sachen besprechen die mir so auffallen. Wenn wir dann feststellen, dass das Wert hat, kann man ja über größeres nachdenken.

Oder der klassische Weg, ich habe mir mal das Repo geholt und probiere mal ein wenig die lokale Hardware aus. Bei der Gelegenheit kann ich ja Patches liefern. Natürlich auch schon die ersten Fehler gefunden, Auch hier wäre es aber IMHO besser wenn man wenigstens das Trac Ticketsystem nutzen würde.

[herrmannj]

Auf der anderen Seite bitte ich zu bedenken (nichts anderes als eine Sondierung ist das was ich gerade hier mache), dass man aber einen Profi aber auch nicht mit Sandkastenspielen locken kann.

Ja, bekanntes "Dilemma". Dies aufzulösen ist Teil der Aufgabe.

Pull request nennt sich das, und ja - gerne - aber ich hätte dann doch schon gerne vorab geklärt ob es nicht vergebene Liebesmüh' ist. Weil eine Woche zu investieren um z.B. die vermaledeiten Prototypen rauszuschmeissen nur um dann zu hören "Nö - wir mögen das aber so"... da hätte ich keine große Lust zu.

Verständlich. Frag einfach vorher beim maintainer an und sprich das ab, dann bleiben derart unschöne "Überraschungen" aus. Manchmal haben bestimmte codeteile einen Sinn der sich erst aus der Erfahrung erschließt.

Neben "schönem" code zählt aber auch Funktion. Bevor ich ein modul anfassen würde dass seit Jahren problemlos läuft würde ich mir module vornehmen die verwaist sind oder wo der (möglicherweise weniger erfahrene) Autor sich über Unterstützung bei der Implementierung von non-blocking code  freut.

[CoolTux]

Was die Prototyp Geschichte an geht solltest Du bitte immer im Hinterkopf haben das aktuell ein Modul immer gleich eine Datei ist, egal wie viele Funktionen. Da kann man nicht mal eben Funktionen mit Prototyp in ein weiteres Modul aus lagern.

Ich Stelle mich aber gerne als Versuchskaninchen bereit.
https://git-tuxnet.ddns.net/FHEM

Kannst gerne mal schauen. Gardena zum Beispiel müsste eh komplett neu gemacht werden. Die API hat sich komplett geändert. Aber schau einfach mal allgemein drüber und erzähl mir was zum Code. Ich höre sehr gerne zu und bin lernwillig.



Grüße

[RichardCZ]

Was die Prototyp Geschichte an geht solltest Du bitte immer im Hinterkopf haben das aktuell ein Modul immer gleich eine Datei ist, egal wie viele Funktionen. Da kann man nicht mal eben Funktionen mit Prototyp in ein weiteres Modul aus lagern.

1 Modul = 1 Datei

Ja, so sollte das sein. Ist es aber nicht.

OpenWeatherMapAPI.pm:package OpenWeatherMapAPI;
OpenWeatherMapAPI.pm:package OpenWeatherMapAPI::Weather;
...
SHC_datafields.pm:package SHC_util;
SHC_datafields.pm:package UIntValue;
SHC_datafields.pm:package IntValue;
SHC_datafields.pm:package BoolValue;
SHC_datafields.pm:package EnumValue;


Und zweitens weiß ich nicht was Prototypen mit Funktionen auslagern zu tun haben sollen. Ich rede davon die ersatzlos zu streichen.

[CoolTux]

1 Modul = 1 Datei

Ja, so sollte das sein. Ist es aber nicht.

OpenWeatherMapAPI.pm:package OpenWeatherMapAPI;
OpenWeatherMapAPI.pm:package OpenWeatherMapAPI::Weather;
...
SHC_datafields.pm:package SHC_util;
SHC_datafields.pm:package UIntValue;
SHC_datafields.pm:package IntValue;
SHC_datafields.pm:package BoolValue;
SHC_datafields.pm:package EnumValue;


Und zweitens weiß ich nicht was Prototypen mit Funktionen auslagern zu tun haben sollen. Ich rede davon die ersatzlos zu streichen.

OpenWeatherMapAPI war mit eine der ersten API Module für das neue 59_Weather. Da mussten noch alte Brücken bleiben. Daher dieser Weg. Zu den anderen kann ich nichts sagen.

Ich kenne es so das wenn man Funktionen mit Prototypen los werden will ein weg ist die Funktionen in Module aus zu lagern und mit use ein zu binden.

[RichardCZ]

Das war nur ein Beispiel. Die ganze Codebasis ist voll davon


23_KOSTALPIKO.pm:package MyParser;
23_KOSTALPIKO.pm:package MyBatteryParser;
23_KOSTALPIKO.pm:package MyRadiationParser;
23_KOSTALPIKO.pm:package MyInfoParser;
...
52_I2C_DS1307.pm:package I2C_DS1307_IO;
52_I2C_DS1307.pm:package Device::DS1307;
...
55_DWD_OpenData.pm:package AstroSun;
55_DWD_OpenData.pm:package DWD_OpenData;


etc.

Code Auswählen Erweitern

grep -rP '\Apackage .+;' * | grep -v main ist Dein Freund.

Hinsichtlich Prototypen:

Ich rede davon statt

sub Define($$) {
...

halt

sub Define {

zu haben. Etc. Siehe PBP Seite 194-196 - die Diskussion ist 15 Jahre alt für mich.

[CoolTux]

Das war nur ein Beispiel. Die ganze Codebasis ist voll davon


23_KOSTALPIKO.pm:package MyParser;
23_KOSTALPIKO.pm:package MyBatteryParser;
23_KOSTALPIKO.pm:package MyRadiationParser;
23_KOSTALPIKO.pm:package MyInfoParser;
...
52_I2C_DS1307.pm:package I2C_DS1307_IO;
52_I2C_DS1307.pm:package Device::DS1307;
...
55_DWD_OpenData.pm:package AstroSun;
55_DWD_OpenData.pm:package DWD_OpenData;


etc.

Code Auswählen Erweitern

grep -rP '\Apackage .+;' * | grep -v main ist Dein Freund.

Hinsichtlich Prototypen:

Ich rede davon statt

sub Define($$) {
...

halt

sub Define {

zu haben. Etc. Siehe PBP Seite 194-196 - die Diskussion ist 15 Jahre alt für mich.

Jetzt verstehe ich was Du genau meinst mit dem Thema Prototyp

[RichardCZ]

Jetzt verstehe ich was Du genau meinst mit dem Thema Prototyp

Ja.

Und natürlich die Orgien wie in fhem.pl loswerden.

Code Auswählen Erweitern


...
61 sub Dispatch($$;$$);
62 sub DoTrigger($$@);
63 sub EvalSpecials($%);
64 sub Each($$;$);
65 sub FileDelete($);
66 sub FileRead($);
67 sub FileWrite($@);
68 sub FmtDateTime($);
69 sub FmtTime($);
70 sub GetDefAndAttr($;$);
...


[justme1968]

das es besser ist alle prototypen abzuschaffen ist zumindest im fhem fall falsch.

wenn die diskussion darauf hinausläuft dogmatisch ein 15 jahre altes buch umzusetzen ohne zu schauen ob es überhaupt passt und ohne zu schauen ob sich der stand der technik nicht doch weiter entwickelt hat und was die zielgruppe ist dann ist das der falsche ansatz. auf jeden fall ist es ein schlechtes beispiel für die verbesserungen die dir vorschweben.

die prototypen sind gerade im fhem fall nützlich weil:
- man sehr oft auf einen blick in fremdem code sieht was als parameter erwartet wird
- weil gerade für einsteiger die möglichkeiten (oder fallen) die ein weglassen erlaubt nicht überschaubar sind
- weil tatsächlich bestimmte fehler frühzeitig erkannt werden

das alles mag für einen profi der 20 jahre nichts anderes als perl gemacht hat eine einschränkung sein. für die hobby entwickler die in hinter freizeit code beisteuern sind sie aber hilfreich.

ganz abgesehen davon: das entfernen der prototypen änder das verhalten des codes. ganz unabhängig davon welches verhalten aus welchen gründen besser ist: so etwas blind vorzuschlagen ohne seitenefekte zu beachten und vorzuschlagen wie man testet und anderweitig in den griff bekommt ist fahrlässig.

auch wenn fhem nicht oben auf der liste der eingesetzten home automation systeme steht ist die zahl von 20000 - 30000 anwendern nicht zu unterschätzen.

[RichardCZ]

@justme1968

das es besser ist alle prototypen abzuschaffen ist zumindest im fhem fall falsch.

Dazu möchte ich eigentlich nur folgende Stichpunkte loswerden:

* Perl Best Practices ist kein "dogmatisch 15 jahre altes Buch"

Diesen Diskreditierungsversuch habe ich bereits ca. 40x gehört, meist von der mittleren - leicht unflexiblen - Entwicklerriege in Unternehmen, welche die Sachen "schon immer so gemacht haben".  Natürlich gibt es einige Dinge, die sich in den letzten 15 Jahren geändert haben und die man - so wie sie im Buch stehen - heute nicht mehr applizieren kann. Prototypes gehören nicht dazu.

Von daher kann in ca. 200 Fällen der 256 im Buch benannten Regeln eher sagen: Die haben seit 15 Jahren Bestand.
Prototypen sind einer dieser 200 Fälle und nein, auch im Fall FHEM ist das nicht falsch. Prototypen sind einfach scheisse. Auch bei FHEM. Punkt.

Diese Diskussion werde ich genau aus dem Grund nicht führen, weil es da 3 Seiten in dem Buch gibt, die genau erklären warum Prototypen scheisse sind und warum Deine Argumentation unzulässig ist (gerade weil man beim Blick auf den AUFRUF einer Funktion eben NICHT sieht was die mit den Argumenten anstellt).

Es werden nicht bestimmte Fehler frühzeitig erkannt, zumindest nicht wenn man andere moderne Paradigmen der Parameterübergabe praktiziert. Im Gegenteil, es werden neue Fehlerquellen eingeführt.


* Ich bin kein Profi, der 20 Jahre nichts anderes als Perl gemacht hat

Erstens warens 25 Jahre, zweitens mache ich auch andere Sachen.

* für die hobby entwickler die in hinter freizeit code beisteuern sind sie aber hilfreich.

Genauso gut könntest Du auch argumentieren, dass das Weglassen von use strict und use warnings für "hobby entwickler mit freizeit code" hilfreich ist. Oder der Verzicht auf Groß- und Kleinschreibung.

ganz abgesehen davon: das entfernen der prototypen änder das verhalten des codes. ganz unabhängig davon welches verhalten aus welchen gründen besser ist: so etwas blind vorzuschlagen ohne seitenefekte zu beachten und vorzuschlagen wie man testet und anderweitig in den griff bekommt ist fahrlässig.

Das ist natürlich eine böse Unterstellung. Soweit ich mich erinnern kann, war es gerade ich der in diesem Thread was von Tests und refactoring geschrieben hat. Vielleicht ist Dir das nur entgangen?

Sei mir nicht böse, aber das waren schon 3 Diskreditierungsversuche von Dir in einem Post. Das ist fast schon wie Kinderüberraschungseier.

auch wenn fhem nicht oben auf der liste der eingesetzten home automation systeme steht ist die zahl von 20000 - 30000 anwendern nicht zu unterschätzen.

Selbst wenn die Statistik belastbar wäre (Quelle?) ist das kein Argument was die Qualität des verwendeten Codes anbelangt. Oder sind alle 20-30k Anwender besagte "Hobby Entwickler"?

[RichardCZ]

Ich habe mir erlaubt mal trunk in ein privates Git unter GitLab zu exportieren.

https://gl.petatech.eu/root/FHEM

Das ist dort öffentlich und da werde ich ein wenig drauf rumklopfen. Schreibrechte in "FHEM Development", wären nett, weil ich doch einige Fragen zu dem Code habe - die ich vermutlich dort stellen sollte.