fhem.pl: CommandAttr

[herrmannj]

@Martin: wenn Dein Wunsch die Vermittlung ist dann stimme ich dem gern zu.

Zu dem fork habe ich eine schöne Geschichte. Mein erstes Modul war WifiLight. Damals hatte ich genau Null Ahnung von perl, aber ich hatte die Bulbs und ich hab erkannt dass das Sinn macht. Also habe ich mich hingesetzt und habe da was zusammen geklöppelt. (Ja das sieht man  ). Und dann habe ich mir gedacht das ist so Amateurhaft, das kannste nicht ins FHEM einchecken. Also ab zu Github, den Link zum git habe ich im forum geteilt und durch den Support den ich dafür geleistet habe konnte ich lernen. Erst ein Nutzer, dann einige, dann einige Hundert. Und da kam so 'ne 'Mütze', der hat gedacht super tolle Idee, hat mein repo ge-cloned - ein bischen rum ge-refactored und dann hat der das unter seinem Namen ins FHEM SVN eingecheckt. Da war ich erst mal ein bisschen angepisst. Trotzdem habe ich weitergemacht. Neue Bulbs reverse engineert, bugs beseitigt, neue features eingebaut. Da war die 'Mütze' schon längst weitergezogen. Keine Bugfixes, keine features. Keiner spricht mehr davon.

FHEM hat wirklich viele Baustellen. FHEMWEB zb ist da perönlicher mein Liebling. Aber jetzt kommen zwei tolle Erkenntnisse. Irgendwie funktioniert es - und noch viel wichtiger- : FHEM ist modular. Was hält mich persönlich (neben mangelnden Wissen) denn davon ab gute Module abzugeben? Muss ich da nach links schauen? Oder nach rechts? Nur wenn es an denn Schnittstellen knirscht und das hat sich immer lösen lassen. FHEM wird nicht durch forks besser, sondern dadurch dass jeder selbst seine eigenen Module verbessert.

Unter genau diesem Aspekt finde ich die "Lehrtätigkeit" von Richard wirklich sehr gut. Ernsthaft. Ehrlich. Und das wird angenommen weil da Bedarf besteht und viele genau das wollen. Selber besser werden.

Besagte "Kollegen", ja wenn die was drauf haben dann können die sicher Module auf höchstem Nivea einchecken. Ich habe im übrigen noch nie gehört dass jemand gesagt hat "FHEM nehme ich nicht, der code ist ja voll 90er". N

ee, was ich höre ist: "boah, die Oberfläche sieht aus wie aus den 90ern". Oder "Diese Regex Arien und Attribut Orgien.".

Ja, könnte kann man eine bessere Oberfläche schreiben ohne mit dem Bestand in Interferenzen zu kommen? So mit responsive und Touch, jung und sexy. Und (fhem-) Modul seitig, so richtig schön best pratice konform? Wäre das ein gutes Beispiel für test coverage? Ich glaube da wäre der Rückenwind noch viel größer.

Ja Richard, ich nehme Deinen Einsatz auch sehr wohlwollend wahr. Justiere halt Deine Ziele und Deinen Ton.

[rudolfkoenig]

Dafuer, dass 20k+ Benutzer seit Jahren Nachts im Nebel ohne Instrumente fliegen, passieren erstaunlich wenig Abstuerze. Das mit "nix anfassen" hinkt auch: FHEM wird mit allen Modulen in so vielen Kombination eingesetzt, dass vermutlich keine zwei gleiche Installationen existieren.

Wir haben hier gemeinsam mit etlichen Helfern in Jahren was aufgebaut, was mehr recht als schlecht funktioniert, und vielen Benutzern hilft. Dann kommt jemand, der sagt, das ist aber alles Kacke, freut euch wenn ich euch zeige wie man das richtig macht, ich war schon im Kindergarten viel besser als ihr alle zusammen. Und ich freue mich schon auf dem Erloeser, aber dann werden keine vorhandenen Probleme geloest, sondern alles nur "umformatiert", damit irgendwelche Tools uns beruhigen, dass das neue Code viel besser ist.

Ich bin zu pragmatisch, um dabei den Fortschritt zu sehen.

Bitte nicht falsch verstehen: ich freue mich, wenn jemand Perl lernt, oder sein Code optimiert. Und ich bin auch wirklich dankbar, wenn mir jemand Bugs zeigt, oder noch besser, wie man diese Bugs behebt. Aber ich brauche keine Noetigung, damit ich mein Code umformatiere, und noch weniger die implizite Aufforderung: schau zu, dass alle Anderen den Code auch umformatieren.

Ich habe auch nichts gegen automatisierte Tests, aber ich warne davor sie zu ueberschaetzen. Ich habe viel Code mit 90% Code-Coverage und schwerwiegenden Bugs gesehen. Wenn der Programmierer etwas nicht versteht, dann wird sein Testcode das auch nicht fixen. Und ich bezweifle, dass wir im FHEM-Umfeld Peer-Review machen koennen, mit unterschiedlichen Leuten fuer Programm- und Testcode schreiben. Ist genau das Gleiche wie mit STABLE und DEV branch. In der Theorie richtig, _wenn_ man genug Entwickler fuer die Aufgabe hat. Wir haben das mit FHEM getestet: keiner hat DEV nur ansatzweise getestet, nicht mal die anderen Entwickler. Beim switch von DEV aus STABLE kam dann die grosse Ueberraschung. In einer Firma kann man Entwickler dazu verdonnern, unangenehme Sachen zu machen, diese Moeglichkeit habe ich nicht.

[KernSani]

Ich habe es schon an anderer Stelle gesagt und wiederhole mich nochmal. ich finde Richards Arbeit sehr sinnvoll, gerade für die vielen copy/paste Programmierer wie mich, die im Grunde von perl keine Ahnung haben, d.h. einen Großteil der Modulprogrammierer. Ob man da jetzt soweit gehen muss PBP-Hitlisten zu erstellen und perlcritic scores hinterher zu jagen sei mal dahingestellt (Ich selbst verwende schon lange Sublime als Editor, mit perlcritic Add-in - da kommt sobald ich was "kritisches" mache ein roter Punkt in der betreffenden Zeile... ist mir aber herzlich egal, so lange es funktioniert. Das heisst aber nicht, dass ich es nicht annehme, wenn jemand einen besseren Vorschlag hat. Und solange die Diskussion sachlich ist ist das der Sache förderlich. Wenn mir jemand sagt der Code ist komplette Kacke und man muss alles neu machen, sage ich "Danke, dann mach's doch neu". Wenn ich umgekehrt Vorschläge mache, was man besser machen könnte (und so kam ja die ganze CommandAttr-geschichte ins Rollen) wünsche ich mir auch, dass das Gegenüber die Sache zumindest gründlich durchdenkt und nicht einfach abbügelt, so dass am Ende was rauskommt wovon alle - die Entwickler, aber insbesondere auch die Anwender profitieren.

Zurück zu CommandAttr, dem Thema dieses Threads. Das Ding ist in meinen Augen tatsächlich eine Krücke (die Implementierung will ich garnicht beurteilen, der Aufruf reicht mir schon). Wenn man die Funktionalität ernsthaft Modul-Entwicklern als API zur Verfügung stellen will, würde ich persönlich nicht an der bestehenden Implementierung rumdoktorn, sondern erstmal eine AttrSet, eine AttrAppend und eine AttrRemove sub (o.ä.) anbieten, die dann eine saubere Schnittstelle ($hash, $attr, $value, ggf. noch ein $separator) haben könnte. Damit würde man einige der möglichen Inkonsistenzen schonmal abfangen. Diese "APIs" könnten dann ja wiederum die bestehende CommanAttr aufrufen (die evtl. irgendwann geändert/optimiert wird)
Man kann nun natürlich argumentieren, Attribute sind Usersache, da hat das Modul sowieso nix zu tun, aber die Realität zeigt nunmal, dass es doch in einigen Fällen hilfreich ist, auch als Modulautor Attributwerte setzen zu können.



   

[Martin Fischer]

Pragmatisch zu sein, heißt das man nicht nach der Perfektion, sondern nach dem Nutzen strebt. Und ist dieser Nutzen für den Pragmatiker sichtbar, ist das für ihn Beweis genug, dass er seine Arbeit erfolgreich umgesetzt hat.

Das Pareto-Prinzip sagt, dass 80 % der Arbeit in 20 % der Gesamtzeit erledigt werden können, während die letzten 20 % der Arbeit 80 % der verfügbaren Zeit in Anspruch nehmen. Jedoch hat hier niemand von den letzten 20% gesprochen!

Wie so oft, besteht auch in diesem Thread keine Einigkeit über die Definition "Nutzen". Ein pragmatischer FHEM Entwickler, wird immer genau so viel Zeit in die Entwicklung (inkl. Design, Test) oder Dokumentation stecken, wie nötig ist, um den Nutzen des Features / des Moduls für alle Anwender für den Moment zu ermöglichen. Sobald der Nutzen aus Sicht der Beteiligten gegeben ist, gibt es ja auch keinen Grund mehr für Anpassungen.

Ein pragmatischer FHEM Entwickler, wäre aber kein Pragmatiker, wenn er keine Ausnahmen zulassen würde. Und dabei sollte er immer die Stakeholder (Betroffene und beteiligte Menschen mit Bedürfnissen und Erwartungen) im Auge behalten. Stakeholder in Bezug auf FHEM sind Anwender, Maintainer, Tester, Software-Architekten, Administratoren, Moderatoren, Verein, etc. gleichermaßen.

Bei jeder Überlegung sollte der zu schaffene Nutzen für die Stakeholder im Vordergund stehen. Dabei gilt es nicht alles stillschweigend hinzunehmen, sondern kritisch zu hinterfragen. Und diese Kultur wird hier im Forum auch gelebt. Kann jemand mit seiner "Anforderung" keinen sinnvollen Grund im Zusammenhang mit FHEM nennen, dann hat diese Anforderung vermutlich auch keinen Nutzen.

Hier nun dogmatisch zu agieren, sollte auch für einen Pragmatiker ein "no go" darstellen. Stattdessen sollten sich offensichtliche Lösungen, Optimierungen, etc., die dem pragmatischen FHEM Entwickler, vielleicht im ersten Moment suboptimal erscheinen, weil sie kein konkretes Modul oder ein konkreten Fehler betreffen, später dann als die vernünftige Grundlage im gesamten Zusammenhang erweisen.

Ich sehe in den Beiträgen von RichardCZ einen nachvollziehbaren Nutzen (Standardisierung, Transparenz, Lesbarkeit, etc.) und bedauere es ausdrücklich, dass die Diskussion um die Sache selbst (Zitat: "Vielleicht könnte ich helfen CommandAttr ein wenig zu verbessern.") komplett aus dem Fokus gerückt ist.

off topic:
Wie sich doch alles wiederholt... nur anders 

https://forum.fhem.de/index.php/topic,7339.0.html
https://forum.fhem.de/index.php/topic,7282.0.html

[RichardCZ]

Wir haben hier gemeinsam mit etlichen Helfern in Jahren was aufgebaut, was mehr recht als schlecht funktioniert, und vielen Benutzern hilft.

Das unterschreibe ich sofort. FHEM funktioniert mehr recht als schlecht. 100%

Aber es wartet und erweitert sich mehr schlecht als recht.

Dann kommt jemand, der sagt, das ist aber alles Kacke,

Nein. https://forum.fhem.de/index.php/topic,109511.0.html

Der Verfasser dieser Zeilen hat die gewöhnungsbedürftige Eigenschaft gute Sachen als normal (nicht der Rede wert) anzusehen und konzentriert sich nur auf die problematischen Sachen. Dadurch kann der Eindruck entstehen "Alles sei schlecht". Dieser Eindruck täuscht - bitte sich ab und zu daran erinnern.

Ich habe auch nichts gegen automatisierte Tests, aber ich warne davor sie zu ueberschaetzen. Ich habe viel Code mit 90% Code-Coverage und schwerwiegenden Bugs gesehen.

Wir alle sehen irgendwas in der Welt und biegen es uns schon so hin, dass es unser Glaubenssystem bestärkt. Zwischen 90% Coverage und 0% Coverage ist viel Luft. Nur weil Du schon Ziegen kotzen gesehen hast (ich im übrigen auch), bedeutet das noch lange nicht, dass automatisierte Tests und hohe Code Coverage schlecht wären und alle Welt einem Irrtum unterliegt.

Sei mir nicht böse, aber diese Sicht erinnert mich an meinen Großvater, der mal mit seinem klapprigen - aber damals neuen - Skoda Favorit mal nach (damals noch) Westdeutschland kam und dann allen ernstes meinte: "Naja - das ist vergleichbar mit einem Golf." Kompletter Selbstbetrug und nicht schön anzuschauen.

Wenn der Programmierer etwas nicht versteht, dann wird sein Testcode das auch nicht fixen.

Auch da stimme ich zu. Umso mehr verwundert es mich, wenn ich zeige wo der Code absolut nicht das macht was man offensichtlich glaubt dass er tut und ich höre - gerade von Dir - "ist mir wurst". Das ist IMHO auch nicht gerade vorbildlich, aber einige folgen diesem Vorbild ( => "IGNORE")

Testcode ist kein Allheilmittel. Perlcritic/PBP ist kein Allheilmittel. Versionskontrolle ist kein Allheilmittel. Aber jedes für sich hilft bei einem bestimmten Aspekt der Softwareentwicklung. Und zusammengenommen ist der Unterschied zwischen haben und nicht haben immens.

Ich zeige Code, der einfach falsch ist - die Definition eines Bugs - und Deine Standardantwort ist "das tut seit 20 Jahren". Auch sowas kann frustrierend sein. Hier werden Fehler mit noch schlimmerem Code gefixed und das wird als "Weiterentwicklung" angesehn. Ich will die Module/Autoren gar nicht konkret benennen, weil dann sagt man wieder ich sei undiplomatisch oder schlimmeres.

In einer Firma kann man Entwickler dazu verdonnern, unangenehme Sachen zu machen, diese Moeglichkeit habe ich nicht.

In einem OSS Projekt muss der Antrieb "von innen" erfolgen, aus Spaß an der Freude. Resourcenmangel (Zeit, Skills) ist ein Evergreen-Thema. Ich weiß das. Aber gerade diese Skill Geschichte ist ein zweischneidiges Schwert. Ich bekomme niemanden überzeugt hier mitzumachen, weil die zeigen mir alle den Vogel. "Subversion? Dieser Code? Keine Tests? Kein Wille/Einsicht zu PBP?"

Vielleicht geht's echt nicht anders. Vielleicht sollte ich einfach ne Weile an hobo arbeiten und "euch in Ruhe lassen" und wir sprechen uns in 1-2 Monaten wieder. Kann ja durchaus sein, dass ich dann mit einer Tüte Asche auf dem Haupt ankomme.

[rudolfkoenig]

Ich will keine Asche nirgendwo, ich will konstruktive Vorschlaege, um vorhandene Probleme mit realistischen Aufwand zu loesen.

Um guten Willen zu zeigen, habe ich das am Anfang beanstandate Problem gefixt, -a und -r sind ab sofort exklusiv.
Auch wenn keiner mit einer Fehlermeldung kam: "attr -a -r device name wert macht nicht das was ich denke, ich habe ... erwartet".
Was eigentlich?

[RichardCZ]

Ich will keine Asche nirgendwo, ich will konstruktive Vorschlaege, um vorhandene Probleme mit realistischen Aufwand zu loesen.

Um guten Willen zu zeigen, habe ich das am Anfang beanstandate Problem gefixt, -a und -r sind ab sofort exklusiv.
Auch wenn keiner mit einer Fehlermeldung kam: "attr -a -r device name wert macht nicht das was ich denke, ich habe ... erwartet".
Was eigentlich?

Es gab ein gemeldetes, kein beanstandetes Problem. Ich wollte nur Antworten auf Fragen vom Typ "wie ist es gedacht". Weil Kommentare gibt es keine, Tests gibt es keine, irgendwie ist das in meinen Augen der einzige Weg gewesen um an die implizite "Business Logik" in dem Code zu gelangen und ob ich tatsächlich den Code richtig verstehe.

Weder habe ich verlangt noch erwartet, dass Du es fixt. Sowas kann ich machen...
...und zwar gründlicher: https://gl.petatech.eu/root/HomeBot/-/commit/9bbcb697f140613d3911843bada590ad95da53a2

Ich denke unter den Umständen ist es echt schmerzfreier für alle Seiten, wenn ich mich alleine durch den Code kämpfe und ihn nach meinen Vorstellungen ändere. In meinem Repo bin ich nämlich so ein kleiner Pinochet. Da geht das und dann sehen wir schon was bei rumkommt.