Anfrage Erweiterung der Verzeichnisstruktur

Begonnen von CoolTux, 12 Mai 2020, 09:05:22

Vorheriges Thema - Nächstes Thema

RichardCZ

Zitat von: CoolTux am 12 Mai 2020, 14:31:52
Wo das ganze am Ende liegt ist in der Tat egal.

Klar ist es egal, solange es unter lib liegt und

package FHEM::Nippel -> lib/FHEM/Nippel.pm
package FHEM::Rad::Neu -> lib/FHEM/Rad/Neu.pm


gilt. Dann ja, dann ist es komplett egal wo das liegt, so lange es so da liegt.  ;)
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Beta-User

Zitat von: RichardCZ am 12 Mai 2020, 14:30:20
Zur Antwort auf "wer soll da noch durchsteigen?": Nun - alle anderen.
Kein Problem, wenn dem dann wirklich so ist (ich hänge nicht an dem "Maintainer" und bin gefühlt nach wie vor deutlich eher User...). Ich versuche nur auf dme mir gegönnten Niveau zu verstehen, was "Sache" ist. Reicht wohl nicht (das ist nicht groß emotional zu verstehen, eher als objektive Feststellung).

Den Hinweis auf Residents&Co versteht der DAM allerdings auch nicht (und auch nicht, was die Splittung des Codes in eine "Initalize+Commandref"+dem eigentlichen Code für einen tieferen Sinn haben soll). Habe mir nur Residents+Roomate (je mit stk) angesehen und finde keine "besonderen" packages, und der *stk-Code ist auch nichts, was von fhem.pl unabhängig lauffähig sein dürfte. Da fehlt mir daher der Bezug zum Thema.

Aber ich verstehe wirklich nichts von diesen Sachen und bin daher jetzt still.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Wenn ich das richtig gezählt habe sind 2 dagegen und 5 dafür.

Wir können natürlich weiterhin endlos das für uns für und wieder Diskutieren bis dann in 3 Tagen die Diskussion zu erliegen kommt und der Thread in den untiefen des Forums versiegt.
Also

JA - wir erproben es

oder

Nein - wir lassen es

Wenn wir ständig darüber nachdenken müssen was das alles eventuell vielleicht für einen einzelnen für Mehraufwand bedeutet dann wird das alles hier nie was.
Niemand sagt das eine Änderung am Ende auf eine einzelne Person die Arbeit runter bricht. Über das ändern etwaiger Abhängigkeiten (die neben bei keine User betrifft) können wir uns dann zusammen Gedanken machen und sicherlich Arbeitsaufgaben teilen.
Meine vorgeschlagenen Änderung soll auch nicht für User sein sondern Entwicklern die Möglichkeit bieten Ihre Module entsprechend zu entwickeln und es einfacher machen Tests auf einzelne Komponenten dieser Module los zu lassen.


Grüße
Marko



Nägel mit Köpfen und einfach mal machen. Schwätzer gibt es zu Hunderten in diesem Forum, was FHEM weiter bringt sind die Macher.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

Zitat von: CoolTux am 12 Mai 2020, 18:30:51
Wenn ich das richtig gezählt habe sind 2 dagegen und 5 dafür.

Ich bin auch dagegen, da sich mir auch nach mehrmaligem sorgfältigem Lesen dieses Threads ein positiver Nutzen der angedachten Änderung immer noch nicht erschließt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

zap

Ich kann mir nicht vorstellen, dass nach gerade mal 7 abgegeben Stimmen hier irgendwelche weitreichenden Entscheidungen getroffen werden.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

CoolTux

Zitat von: zap am 12 Mai 2020, 21:50:31
Ich kann mir nicht vorstellen, dass nach gerade mal 7 abgegeben Stimmen hier irgendwelche weitreichenden Entscheidungen getroffen werden.


Den meisten ist es sicherlich schlicht egal, da sie der Meinung sind es betrifft sie nicht (womit sie ja Recht hätten, wer nicht expliziert daran Interesse hat als Entwickler den betrifft es auch nicht). Oder sie haben keine Meinung dazu, vielleicht weil sie nicht wissen was das genau bedeutet (Unwissenheit).

Ich will einfach nur eine Sicherheit und dazu wird halt eine Entscheidung benötigt. Wie die aus fällt ist mir egal, ich kann auch wie gehabt weiter machen. Ist halt gerade bei ASC mehr Aufwand da ich denke bei einer Aufteilung besser Tests laufen lassen zu können welche auch sinnvoll sind. Ändere ich in Klasse Shutters::Attr etwas kann ich testen ob dies meine Logiken in der Klasse ShuttersControl beeinflusst. Und ich denke das ich eine bessere Übersicht habe über meine eigene Klassenstruktur.

Aber wie gesagt egal wie es aus fällt ich werde damit leben können.

Mir geht es darum nicht um sonst eventuell Energie reingesteckt zu haben und eine fertige Lösung mit allen drum und dran zu haben in einem halben Jahr und dann passiert sowas wie jetzt wo gesagt wird nö ist unnütz. Dann lieber vorher sagen und entscheiden.



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Sidey

Zitat von: CoolTux am 12 Mai 2020, 18:30:51
Wir können natürlich weiterhin endlos das für uns für und wieder Diskutieren bis dann in 3 Tagen die Diskussion zu erliegen kommt und der Thread in den untiefen des Forums versiegt.
Also


Die Natur hat es uns vorgemacht. Hätte jemand darüber diskutiert ob es die Menscheit geben soll oder nicht, wer weiss ob es uns dann heute überhaupt geben würde.

Also ich bin für einfach mal machen und Prototypen eine Chance geben. Was der Prototoyp dann alles kann, da bin ich unsicher.
Aber jede Idee hier so lange zu diskutieren, bis die Lust vergeht, hmm, so ist das doch mit den Open Source Projekten und den Forks eher nicht gedacht oder?

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

Achso, fast vergessen. Es wurde nach Vorteilen gefragt.

Der Vorteil, sich an sogenannte "Perl" Standards oder "best practices" zu halten liegt darin, dass neue Entwickler auf ein breites Spektrum an Informationsmaterial zurückgreifen können wie z.B. eine Bibliothek erstellt wird.
GGf. kennen diese Entwickler ja bereits auch schon diese Vorgehensweise aus anderen Projekten und können so viel leichter einsteigen.
Außerdem reduziert sich der Dokumentationsaufwand, weil diese dinge schon xFach dokumentiert sind. Es müssen dann "nur" noch die FHEM Besonderheiten dokumentiert und "verstanden" werden. Bei allem anderen, verweisen wir auf "etablierte" Standards.

Onboarding wird so viel einfacher. Das sollte doch jeder aus der Arbeitswelt kennen, wenn er einen neuen Job angefangen oder jemanden Eingearbeitet hat.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Christoph Morrison

#23
Zitat von: Sidey am 12 Mai 2020, 22:27:17
Achso, fast vergessen. Es wurde nach Vorteilen gefragt.

Einen hätte ich noch!

Ich müsste meinen Code in erster Linie nicht darauf hin entwickeln, dass er im FHEM-Kontext läuft, sondern standalone als Modul. Man würde dann nur neben dem eigentlichen Modulcode noch eine Anbindung an FHEM produzieren, die aber in vielen Fällen recht generisch ist (def, undef, attr, set, get, etc.). Diese Anbindung könnte man wiederum in ein Modul auslagern und dann reduziert sich der Aufwand ein neues Modul zu produzieren auf die eigentliche Nutzlast + Anbindung. Und das sollte uns allen entgegen kommen, denn ich weiß ja nicht wie es euch geht, aber mir bluten die Finger wenn ich Code duplizieren muss, der eigentlich generalisiert in ein Modul gehört. Wie jetzt, wo ich in ein neues Modul Code aus Buienradar kopieren muss. Richtig mit copy-paste. Das kann es doch nicht sein. Und das ist uns bei Twilight + RandomTimer auch schon auf die Füße gefallen, wenn ich mal daran erinnern darf (*).

Am besten wäre es natürlich noch, wenn ich MeinModul sagen könnte: Hey, ich brauche MeinAnderesModul als Abhängigkeit, denn da ist Code drin, den ich gerne in MeinModul hätte, aber nicht duplizieren möchte - und FHEM schlägt dem User dann vor: Guck mal, du willst MeinModul installieren, dafür brauchst du aber auch noch MeinAnderesModul, soll ich das ebenfalls installieren? Und dann fügt FHEM meinetwegen eine controls hinzu, die MeinAnderesModul referenziert. Sowas könnte man dann natürlich auch mal für CPAN-Pakete machen und wir hätten das ganze Gewese mit "Ich kopiere Zeug aus CPAN-Module von anno dunnemals damit ich unsere DAUs nicht damit belasten muss, ein CPAN-Paket zu installieren" auch los. Loredo hat da doch tolle Vorarbeit geleistet und viel Zeit investiert, die aktuell nur ungenutzt rumliegt.

Für mich sind das alles Themen, die miteinander zusammen hängen. Eine gescheite Verzeichnisstruktur erlaubt mir eine bessere Modularisierung, die mir erlaubt, Dependencies zu definieren, was mir ermöglicht weniger Code zu duplizieren / Code mehr zu generalisieren - was mir erlaubt endlich mal eine sinnvolle Testabdeckung zu produzieren und nicht meine Modulnutzer als ewige Beta-Tester zu missbrauchen.

(* Das dietmar63 von uns gegangen ist, hat doch schmerzlich gezeigt, dass wir mehr Standardisierung im Code brauchen. Ich arbeite nicht an Twilight, weil es einfach die Pest ist, in den Code zu schauen. Der Aufwand so eine Ruine zu sanieren ist gigantisch: Bei BR - und da ist die Funktionalität viel einfacher - habe ich schon sicher um die 100 Stunden nur darin investiert, den Code zu sanieren damit jemand der mich mal beerbt nicht auf meinem Grab eine Kopie von PBP verbrennt und meine Kinder bis in die dritte Generation verflucht. Ohne Feature-Entwicklung. Bugfixing ist auch die Pest wenn der Code völlig unstrukturiert, unkommentiert und einfach oftmals nicht eindeutig ist.)

rudolfkoenig

ZitatIch müsste meinen Code in erster Linie nicht darauf hin entwickeln, dass er im FHEM-Kontext läuft, sondern standalone als Modul. Man würde dann nur neben dem eigentlichen Modulcode noch einen Anbindung an FHEM produzieren, die aber in vielen Fällen recht generisch ist (def, undef, attr, set, get, etc.)

Geht doch jetzt schon: CPAN Modul bauen, und diesen vom besagten "recht generischen" referenzieren.
Uebersehe ich etwas?

Christoph Morrison

Zitat von: rudolfkoenig am 13 Mai 2020, 11:01:17
Geht doch jetzt schon: CPAN Modul bauen, und diesen vom besagten "recht generischen" referenzieren.
Uebersehe ich etwas?

Ja. Was ist mit Modulen, die Funktionalität nur für FHEM bereitstellen und deshalb im CPAN nix verloren haben? Zum Beispiel wären perspektivisch HttpUtils, Meta, Units, FHEMWEB, etc. alles Dinge, die keine CPAN-Module sind und sein sollten, aber auch mal ordentlich modularisiert gehören. Und natürlich gibt es einige Leute, die gerne über das SVN ausliefern, z.B. CoolTux, der aber auch eine modernere Modul-Struktur benutzen möchte - und imho auch muss, denn  ASC ist z.B. so komplex und hat so viele Optionen, dass der Code auch riesig ist (und ich weiß das, weil ich jeden Commit den er auf Github macht, reviewe und mit nervigen Kommentaren versehe).

zap

Zitat von: CoolTux am 12 Mai 2020, 22:13:03
Den meisten ist es sicherlich schlicht egal, da sie der Meinung sind es betrifft sie nicht (womit sie ja Recht hätten, wer nicht expliziert daran Interesse hat als Entwickler den betrifft es auch nicht). Oder sie haben keine Meinung dazu, vielleicht weil sie nicht wissen was das genau bedeutet (Unwissenheit)

Dann habe ich das falsch verstanden. In dem Fall zähle ich mich zur "ist mir egal" Fraktion ;)
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

betateilchen

Zitat von: Sidey am 12 Mai 2020, 22:27:17
Achso, fast vergessen. Es wurde nach Vorteilen gefragt.

Welchen Vorteil hätte der Anwender?

Wir bauen doch FHEM nicht als Selbstzweck oder als Spielwiese für Entwickler, sondern für die Anwender.
Als CSM und CSPO stehen für mich immer die Kunden/Anwender im Vordergrund, denen eine Produktentwicklung einen Vorteil bringen muss, bevor entschieden werden kann, ob ein Aufwand betrieben wird oder nicht.
Einen solchen Vorteil auf seiten der Anwendung (= Benutzung) sehe ich einfach immer noch nicht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

CoolTux

Zitat von: betateilchen am 13 Mai 2020, 15:07:50
Welchen Vorteil hätte der Anwender?

Wir bauen doch FHEM nicht als Selbstzweck oder als Spielwiese für Entwickler, sondern für die Anwender.
Als CSM und CSPO stehen für mich immer die Kunden/Anwender im Vordergrund, denen eine Produktentwicklung einen Vorteil bringen muss, bevor entschieden werden kann, ob ein Aufwand betrieben wird oder nicht.
Einen solchen Vorteil auf seiten der Anwendung (= Benutzung) sehe ich einfach immer noch nicht.

Wenn Du es tatsächlich genau so siehst dann bin ich als Entwickler falsch hier.
Von einem Projekt für welches ich mich als Entwickler begeistere und Arbeiten beisteuern will erwarte ich auch Unterstützung für mich als Entwickler und nicht nur das ich ausschließlich hier bin um die User zu beglücken. Du kochst doch auch nur mit Liebe wenn entsprechendes Arbeitsmaterial hast und die Umgebung passt. Und nicht weil irgendwer sich deswegen super fühlt.

Deine Aussage empfinde ich als Entwickler für mich als Beleidigung.  >:(
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Christoph Morrison

Zitat von: betateilchen am 13 Mai 2020, 15:07:50
Welchen Vorteil hätte der Anwender?
Wir bauen doch FHEM nicht als Selbstzweck oder als Spielwiese für Entwickler, sondern für die Anwender.

Er bekommt langfristig ein stabilieres, besser getestetes und leichter zu installierendes System. Da du ja ...

Zitat von: betateilchen am 13 Mai 2020, 15:07:50
Als CSM und CSPO stehen für mich immer die Kunden/Anwender im Vordergrund, denen eine Produktentwicklung einen Vorteil bringen muss, bevor entschieden werden kann, ob ein Aufwand betrieben wird oder nicht.

... so wie ich, übrigens, CSM und CSPO bist, kennst du das Konzept der technischen Schulden sicher nur all zu gut. Und die fallen am Ende allen auf die Füße, aber den Usern gleich fünfmal, denn ich kann mir ein Log anschauen und meinen unmatched Regex selbst finden ohne auf das Forum angewiesen zu sein.

Allerdings, und da stimme ich CoolTux zu, entwickele ich hier nicht in erster Linie für irgendwelche abstrakte Benutzer die mich nicht mal dafür bezahlen, dass ich irgendwelche lumpigen APIs anbinde/ranzige Altmodule überarbeite oder Bugs in meiner Freizeit fixe, sondern weil ich a) selbst ein Interesse daran habe, dass es hier läuft (und keinen Bock auf Streit mit meiner Frau habe :-D ), b) weil ich mich selbstverwirklichen möchte (Übung in einer Programmiersprache, die ich sonst nicht benutze) und c) weil ich euch was zurück geben möchte, die auch Zeit in etwas investiert haben, von dem ich profitiere (so eine Art reziproker Altruismus). Und dabei ist eben ein guter Nebeneffekt, dass die Leute, die nichts weiter beitragen, auch davon profitieren (Surplus/Mehrwert).

Und auch da stimme ich CoolTux zu: Auch ein Projekt wie FHEM muss attraktiv für Entwickler sein, denn ohne Entwickler bekommen selbst interessiert User keinen Code/keine Funktionalität. Und tut mir leid, aber bisher sehe ich keine besonderen Anstrengungen vom harten Kern, Entwickler zur Mitarbeit zu motivieren: Es gibt keine Öffentlichkeitsarbeit (in Richtung Entwickler!) und das Toolset ist von anno tobak. Ich denke mit Grausen daran, wie mit Richard hier umgegangen wird, obwohl er nichts anderes getan hat, als den Finger in die Wunde zu legen. Insbesondere von euch/einigen "alten Herren" hier.