fhem.pl: CommandAttr

[RichardCZ]

Vielleicht könnte ich helfen CommandAttr ein wenig zu verbessern. Mangels Testsuite brauche ich aber Hilfe um zu wissen "wie was gedacht war".

Ich bin schonmal so weit gekommen um dann erstmal hart zu bremsen:

Code (perl) Auswählen Erweitern

    my $cl    = shift;  # whatever this is...
    my $param = shift;  # command attributes in string form - including optional flags

    my $mode;
    my $ret;
    my @a;

    # check if append or remove mode was given
    if ($param =~ s{\A-(a|r) \s+}{}xms) {
        $mode = $1;
    }

    @a = split(" ", $param, 3) if ($param);

    return "Usage: attr [-a|-r] <name> <attrname> [<attrvalue>]\n$namedef"
        if (@a && @a < 2);

CommandAttr behauptet ja

Usage: attr [-a|-r] <name> <attrname> [<attrvalue>]

aber das stimmt nicht. Mindestens gilt [-a -r|-a|-r] - ich vermute, gleichzeitig append und remove zu machen ist nicht so sinnvoll? Der Code macht das aber wenn man es ihm sagt.

Code Auswählen Erweitern

  my ($cl, $param) = @_;
  my ($ret, $append, $remove, @a);

  $append = ($param =~ s/^-a //);
  $remove = ($param =~ s/^-r //);
  @a = split(" ", $param, 3) if($param);

  return "Usage: attr [-a|-r] <name> <attrname> [<attrvalue>]\n$namedef"   # nope  [-a -r|-r|-a]
           if(@a && @a < 2);

...und später dann

    if($append && $attr{$sdev} && $attr{$sdev}{$attrName}) {
      $attrVal = $attr{$sdev}{$attrName} .
                        ($attrVal =~ m/^,/ ? $attrVal : " $attrVal");
    }
    if($remove && $attr{$sdev} && $attr{$sdev}{$attrName}) {
      my $v = $attr{$sdev}{$attrName};
      $v =~ s/\b$attrVal\b//;
      $attrVal = $v;
    }




Kann mir jemand sagen was gewollt ist? Exklusiv oder nicht? Sprich: Code oder Doku ändern?

Wenn exklusiv, mache ich unten eben ein if ($mode eq 'a' && ...) ... elsif ($mode eq 'r') ...

Die usage kommt auch nicht, wenn man z.B. nur CommandAttr(undef, '-r '); übergibt, dann weint sich $a1 = $a[1] aus - weil ja @a undefiniert ist etc. etc.
Aber eins nach dem anderen.

[rudolfkoenig]

$cl: Client Hash, zeigt ueber welchen Kanal das Befehl reingekommen ist, um Authorisierung, etc machen zu koennen.
-a und -r ist nicht so gedacht, dass man sie zusammen aufruft, und nach etwas nachdenken sollte das jedem normalen Benutzer einleuchten.
Wenn es doch gemacht wird, und was Unerwartetes passiert, ist mir eigentlich egal, ich bin nicht da, um Leute aus dem Fenster springen abzuhalten.

Es wird z.Zt. hier irre viel Energie auf Sachen aufgewendet, die fuer den Anwender keinen Nutzen haben. Das finde ich schade, es gibt naemlich auch viel zu tun, was konkret helfen wuerde. Im Zusammenhang mit Perl sind z.Bsp. diverse Speicherloecher zu erwaehnen, siehe unser Mega-Thread https://forum.fhem.de/index.php/topic,84372
Oder die vielen Module, die BlockingCall verwenden, anstatt sich in das globale select-loop einzuhaengen.
Usw, usf.

[RichardCZ]

$cl: Client Hash, zeigt ueber welchen Kanal das Befehl reingekommen ist, um Authorisierung, etc machen zu koennen.
-a und -r ist nicht so gedacht, dass man sie zusammen aufruft, und nach etwas nachdenken sollte das jedem normalen Benutzer einleuchten.
Wenn es doch gemacht wird, und was Unerwartetes passiert, ist mir eigentlich egal, ich bin nicht da, um Leute aus dem Fenster springen abzuhalten.

Es wird z.Zt. hier irre viel Energie auf Sachen aufgewendet, die fuer den Anwender keinen Nutzen haben. Das finde ich schade, es gibt naemlich auch viel zu tun, was konkret helfen wuerde. Im Zusammenhang mit Perl sind z.Bsp. diverse Speicherloecher zu erwaehnen, siehe unser Mega-Thread https://forum.fhem.de/index.php/topic,84372
Oder die vielen Module, die BlockingCall verwenden, anstatt sich in das globale select-loop einzuhaengen.
Usw, usf.

Ich weiß gar nicht, wo ich da anfangen soll. Vielleicht, dass ich das Geschriebene auch sehr schade bis traurig finde.

Ich finde es ja auch sehr schade, dass in Afrika Menschen an Malaria leiden. Aber deswegen investierte Energie in Malaria-Mittel oder Malariabekämpfung als "irre viel Energie, die für die Malariaopfer keinen konkreten Nutzen hat" zu deklarieren und am besten alle Malariaforscher dazu aufrufen, doch mal konkret nach Afrika zu fahren und dort den Malariaopfern Trost zu spenden...

Wie schon gesagt: traurig.

Was das Speicherproblem anbelangt: Diejenigen, die davon gebissen werden, sollen halt kein Perl 5.24 benutzen

Was BlockingCall verwendende Module anbelangt: "ist mir eigentlich egal, ich bin nicht da, um Leute aus dem Fenster springen abzuhalten."

[rudolfkoenig]

Was das Speicherproblem anbelangt: Diejenigen, die davon gebissen werden, sollen halt kein Perl 5.24 benutzen

Das ist nicht so einfach, das Problem kommt auch mit anderen Perl Versionen vor. Ich habe versucht den Speicherverbrauch der einzelnen Module zu messen oder zu lokalisieren, bin aber daran gescheitert. Sowohl mit "Eigenbau", wie auch mit CPAN-Modulen, die mit Segmentation-Fault abgestuerzt sind.

[RichardCZ]

Das ist nicht so einfach, das Problem kommt auch mit anderen Perl Versionen vor. Ich habe versucht den Speicherverbrauch der einzelnen Module zu messen oder zu lokalisieren, bin aber daran gescheitert. Sowohl mit "Eigenbau", wie auch mit CPAN-Modulen, die mit Segmentation-Fault abgestuerzt sind.

Kann ja sein, dass es mehrere Speicherlecks gibt. Devel::Size hat mir häufig geholfen (ich habe gesehen ist bekannt). Perl Debugger magst ja nicht. Ein gewisser Richard Foley hat da eine nette Referenz zu geschrieben: http://shop.oreilly.com/product/9780596005030.do

Kurzer Tipp aus dem Elfenbeinturm: Perl alloziert immer nur Speicher und gibt ihn nie frei - ans OS.
Perl wiederverwendet aber mal freigegebenen Speicher (also innerhalb des Prozesses).
Gut - hilft Dir jetzt vielleicht nicht viel, weil Speicherleck wie Speicherleck, Bedeutet jemand alloziert ständig.
Vermutlich wächst da ein hash oder Array ins Unendliche.

Ich könnte mich da ja umschauen, aber ich betreibe lieber Grundlagenforschung.

Wenn man sich anschaut, wieviele Fehler in den letzten Jahren in Perl geplättet wurden (perl-porters haben nämlich an Fahrt aufgenommen), dann will man da ein neues haben: https://perldoc.perl.org/index-history.html

Schaut euch nur die Perl 524x deltas an.  5.24.4 hat vermutlich auch kein Speicherleck mehr.

---

Unsere Vorgehensweisen unterscheiden sich halt beträchtlich. Ich sehe man hat den Code absolut nicht unter Kontrolle und es erstaunt mich nicht, dass er euch ab und zu auf die Füße fällt. Wenn ich Beispiele zeige wo der Code nicht unter Kontrolle ist, ernte ich von Dir zumeist ein "ist mir wurst". Kann man nur mit der Schulter zucken.

Ich würde ihn gerne unter Kontrolle bringen und es würde mir extrem helfen wenn ich einen Alteingesessenen gewisse Dinge fragen könnte bzw. gewisse Daten bekäme. Aber is halt nicht.

[rudolfkoenig]

Du redest von "nicht unter Kontrolle" und "auf die Fuesse fallen", aber die Sachen die du ansprichst haben mir in den letzten 10 Jahren keine Probleme gemacht.
Und das bedeutet nicht, dass ich keine habe.

Ich würde ihn gerne unter Kontrolle bringen und es würde mir extrem helfen wenn ich einen Alteingesessenen gewisse Dinge fragen könnte bzw. gewisse Daten bekäme. Aber is halt nicht.

Fragen darfst du ja, und ich beantworte auch alles nach meinem besten Wissen.

[herrmannj]

@richard: wenn ich mich zwischen einem fhem entscheiden muss welches bei critic glänzt und einem das über Jahre zuverlässig mein Zuhause steuert. ... Ich nehme letzteres.

Ein guter Plan heute ist besser als ein perfekter Morgen. Ich weiß deine Bemühungen zu schätzen! Denk aber dran: 80 Prozent machen ist besser als 100 Prozent wollen 

[Beta-User]

Zwischenruf vom kleinen DAM, der vermutlich nichts dazu beitragen kann, eventuelle Speicherlecks zu finden:

- Jeder darf selbst entscheiden, wie er seine Zeit einsetzt, ich habe auch noch ein paar FHEM-Hausaufgaben, die ich nicht vergessen habe...
- Über manches kann man denken, was man will (vor allem, wenn man wirklich weiß, was man tut - und das unterstelle ich den "Kern"-FHEM-Entwicklern rund um Rudi allen!), aber die Initiative rund um "besseres Perl" in FHEM erscheint mir durchaus sinnvoll, denn eine nicht ganz kleine Zahl der Maintainer scheinen nämlich eher meine "Qualität" zu haben - gut kopiert ist halb gecoded...
Vor letzterem Hintergrund: Und dass es ganz allgemein nicht schadet, älteren Codebestand mal wieder durchzusehen, ist wohl auch nicht ganz verkehrt. Das gilt in meinem Fall vor allem auch deswegen, weil es wie im Fall von WDT/RandomTimer so ist, dass ich grade eben "sowieso im Code" (und was er tun sollte) drin war und bei der Gelegenheit gerne checken wollte, ob das (v.a. WDT) eventuell irgendwelche programmiertechnischen Stolperfallen enthält, die ich in meinem "jugendlichen Leichtsinn" und begrenztem Horizont eventuell übersehen habe. Und die Diskussion rund um AnalyzePerlCommand/eval könnte so ein Punkt sein, wo es "lustig" wird, jedenfalls, wenn ich das richtig verstanden habe.

Wenn also der eine oder andere weitere Maintainer jetzt zwar auch sagt: k.A., wie man Speicherlöcher findet, aber mal einen automatisierten Check durchzuführen und vielleicht mal wieder nachzusehen, ob es nicht (zwischenzeitlich?) bessere Varianten gibt, wie mein Modul und fhem.pl zusammenarbeiten können, dann ist doch was gewonnen, oder?

@Richard:
Es ist hier in der Regel so, dass Dinge zumeist öffentlich diskutiert werden sollen und können. Wenn du den Eindruck hast, du könntest damit jemandem zu nahe treten: Frage ihn halt vorab direkt, die meisten kann man per pm oder email kontaktieren... (Das würde ich in Bezug auf deine Persönlichkeitsstruktur, auf die du an anderer Stelle hingewiesen hattest, im Zweifel auch empfehlen!
Dazu aber vielleicht noch eine OT-Anmerkung von einem, der hier gelegentlich auch für arrogant gehalten wird: Gerade weil du um diesen Zug weißt, ist es eigentlich keine geeignete Entschuldigung mehr... Schau' möglichst einfach alles nochmal durch die Brille eines virtuellen Dritten an, reduziere das Geschriebene um zwei Schärfegrade und du erreichst hier in unserem Rahmen (und ggf. auch anderswo) (noch) mehr .)

Ansonsten: Ich bin ein DAM, mich darfst du als solchen behandeln, aber andere wären für einen ihrem Level angemessenen Umgangston vermutlich dankbar...

[Martin Fischer]

Leute... mal im Ernst...

Worum geht es hier eigentlich? Geht es hier um ein Kräftemessen?

Auch mir geht die eine oder andere Formulierung von Richard auf den Sack ("nicht unter Kontrolle")... Aber die andere Seite sollte doch auch mal offensichtliche und nachvollziehbare Optimierungsvorschläge oder Code-Reviews sachlich betrachten.. auch wenn Richard nicht jedesmal diplomatisch formuliert...

Und wenn vermeintliche "Ungereimtheiten" in den letzten 10 Jahren keine Probleme bereitet haben, sind sie vielleicht die Summe der Nebeneffekte und führen dann vielleicht u.a. zu besagtem Speicherleck... Warum also nicht erst mal eine gute Basis schaffen um dann Stück für Stück tiefer zu gehen?

Was ich aber derzeit gefühlt erlebe ist, das sich Richard (manchmal aber eben nicht ausschliesslich "unvorteilhaft") einbringt, die andere Seite sich aber mehr mit dem "Wie er sich einbringt" als mit dem "Was er da macht" auseinander setzt.

Ich teile ebenfalls nicht die Meinung, das der bestehende Code "nicht unter Kontrolle" sei. Ich begrüße jedoch ein schrittweises Refactoring ausdrücklich.

Ich bin mir sicher, dass das in Summe die strukturellen Verbesserungen zu einem (noch) schlankeren, schnelleren, stabilen FHEM führen werden. Und dabei sollte das bestehende "Endergebnis", also das beim Anwender, möglichst ungestört bleiben.

Von den "alten Hasen" wird der Code gefühlt "im Sinne des zuverlässigen Hauses" und "der Community" verteidigt ohne mal über den Tellerrand zu schauen und sich Gedanken über Regelprozesse in der IT zu machen. Dazu gehört nämlich auch, "Lifecycles" kontinuierlich zu verbessern. Und das impliziert eben nicht, das sie zwangsläufig auch schlecht sind. Wenn aber Verbesserungen gefunden werden, dann sollten sie nach einer sachlichen Prüfung doch auch Einzug halten und nicht mit einem Fingerzeig abgewiesen werden. Find ich nicht ok!

Den einen oder anderen Tod muss man dann auch mal sterben. Und vorallem sollten sich beide Seiten mal die Hand reichen und überlegen, wie man hier gemeinsam an einem Strick ziehen kann!

my 2 cents...

[Martin Fischer]

Zwischenruf vom kleinen DAM, der vermutlich nichts dazu beitragen kann, eventuelle Speicherlecks zu finden:

Dein Beitrag hat meine vollste Zustimmung!

[herrmannj]

@Martin: interpretiere da nichts rein was nicht drin ist. Ich habe geschrieben "das weiß ich zu schätzen" und das meine ich genau so. Ich sehe das es angenommen wird und der geneigte Leser weiß das ich mich nicht immer zurückhalte wenn es um die Art geht wie einiges in der source von fhem geschrieben ist! 

- aber: wenn Rudi schreibt dass es läuft dann stimmt das! Ich habe gestern zum ersten mal wieder mein Produktiv anfassen müssen (jessie -> buster). up-time 2.5 Jahre. Auf die Füße fallen sieht anders aus.

Gibt es bei usern Probleme mit Speicherlecks ? Scheint so. Ist die Empfehlung, "geh halt auf 5.24" zielführend? Im verlinkten thread hilft's manchmal, aber nicht immer. Wo setzt man die Zeit ein? Wenn es ganz viel davon gibt dann sicher bei beidem. Ansonsten das wo es klemmt. Frag die user die an besagtem Speicherleck leiden doch mal.

Dies hier funktioniert recht zuverlässig auf vielen perl Varianten

Code Auswählen Erweitern

sub
test {
  my $a;
  my $b;

  $a->{b} = \$b;
  $a->{0} = [1..65535];
  $b->{a} = \$a;
  $b->{0} = [1..65535];
  return;
}
for (1..65535) {
  test();
}
for (1..65535) {
  test();
}


[Martin Fischer]

@Martin: interpretiere da nichts rein was nicht drin ist. Ich habe geschrieben "das weiß ich zu schätzen" und das meine ich genau so. Ich sehe das es angenommen wird und der geneigte Leser weiß das ich mich nicht immer zurückhalte wenn es um die Art geht wie einiges in der source von fhem geschrieben ist! 

Ich interpretiere dort nichts hinein, noch habe ich Interesse an einer Grundsatzdiskussion. Ich zitiere RichardCZ:

CommandAttr behauptet ja

Usage: attr [-a|-r] <name> <attrname> [<attrvalue>]

aber das stimmt nicht. Mindestens gilt [-a -r|-a|-r] - ich vermute, gleichzeitig append und remove zu machen ist nicht so sinnvoll? Der Code macht das aber wenn man es ihm sagt.

Rudi antwortet in den ersten 1.5 Sätzen sachlich und dann wird es polemisch und der Sache nicht dienlich:

...und nach etwas nachdenken sollte das jedem normalen Benutzer einleuchten.
Wenn es doch gemacht wird, und was Unerwartetes passiert, ist mir eigentlich egal, ich bin nicht da, um Leute aus dem Fenster springen abzuhalten.

Um dann sogleich noch darauf hinzuweisen, dass das alles vergebene Liebesmüh ist, da es viel, viel wichtigeres gibt:

Es wird z.Zt. hier irre viel Energie auf Sachen aufgewendet, die fuer den Anwender keinen Nutzen haben.

- aber: wenn Rudi schreibt dass es läuft dann stimmt das! Ich habe gestern zum ersten mal wieder mein Produktiv anfassen müssen (jessie -> buster). up-time 2.5 Jahre. Auf die Füße fallen sieht anders aus.

Ob das mal nicht zu kurz gesprungen ist? Schade, das hier so "eng" gedacht wird. Da wirken solch, sorry dafür, "Phrasen" wie "Ein guter Plan heute.." nicht gerade ermutigend. Da ich lange genug dabei bin, weiß ich, das es für FHEM keinen "Plan über heute hinaus gibt".

Auch ich könnte hier etliche Lobeshymnen auf FHEM (und vorallem die Entwickler) abfeuern. Ja, aber das hilft hier in Sache nicht weiter! Auch ich betreibe mehrere(!) vernetzte Produktivsysteme. Und sie laufen auch. Soll das jetzt die Begründung sein, dass wir hier ein "Codefreezing" a la "das lüppt, brauchen wa nicht anfassen..." zelebrieren?

Vor einigen Jahren hatte ich (u.a.) die neue Updateroutine zu FHEM beigesteuert. In dieser Zeit hatte ich externe Quellen für Module sowie Branches "stable", "devel" und "experimentel" (oder so) eingeführt. Da hättest Du (und andere, also auch ich) dann bei relevanten Systemen immer auf "stable" updaten können ohne, das man im Entwicklungszweig darauf hätte Rücksicht nehmen müssen. Die Diskussionen hierzu sind alle öffentlich und nachvollziehbar. Genau so wie "Internationalisierung", "Ticketsystem contra Google-Groups" (noch zu BerliOS), einheitliche Schreibweisen von Werten und Einheiten, etc., etc. Die Möglichkeit Branches zu nutzen, wurde dann nach einiger Zeit in einer "Nacht und Nebelaktion" von Rudi wieder ausgebaut, da nicht gewollt. So wie andere "Moderniesierungen" in den letzten rund 14 Jahren immer wieder mal gestartet und dann meist(!) (nicht immer) abgewiesen wurden. Die Erklärungen wiederholen sich. Wer es nicht glaubt: das FHEM Forum ist offen einsehbar.

Um es nochmal auf den Punkt zu bringen:
Es liegt mir fern, hier zu "richten". Ich möchte vermeiden, dass es zu einem Bruch kommt:
fhem.pl auf der einen Seite und hobo.pl auf der anderen. Der erste Schritt ist ja bereits getan:
https://gl.petatech.eu/root/HomeBot

Schon mal darüber nachgedacht, was das im Namen der Community (und der Maintainer) für FHEM bedeuten würde? Verlierer wären dann nämlich ALLE! Und hier hilft es dann wohl doch, auch einen "guten Plan" für Morgen (und nicht nur heute) zu haben. Keiner hat hier von "perfekt" geredet.

Abschliessend zitiere ich mich nochmal selbst:

...noch habe ich Interesse an einer Grundsatzdiskussion.

Ich will hier vereinen und nicht "Partei ergreifen".

Viele Grüße
Martin

[RichardCZ]

Martin, ich weiß nicht wie mein Text exakt bei Dir ankommt, aber Du solltest vorab wissen, dass ich Deine Sichtweise der Dinge (nicht nur in diesem Thread) für die ausgewogenste halte, die mir bislang im FHEM Forum begegnet ist.

Auch mir geht die eine oder andere Formulierung von Richard auf den Sack ("nicht unter Kontrolle")... Aber die andere Seite sollte doch auch mal offensichtliche und nachvollziehbare Optimierungsvorschläge oder Code-Reviews sachlich betrachten.. auch wenn Richard nicht jedesmal diplomatisch formuliert...

Ich weiß, man sollte auch Fakten diplomatisch formulieren, aber mir fällt nunmal für die folgenden Fakten keine diplomatischere Formulierung ein:

• Da wo FHEM heute hinsichtlich Development-Cycle ist (Versionskontrolle, CI/CD), war ich vor ca. 12 Jahren.
• Da wo FHEM heute hinsichtlich Codequalität ist (Code, Tests, Coverage), war ich vor ca. 18/19 Jahren.

Ich habe etliche viel diplomatischere Kollegen, die sicher  auf einem vergleichbaren Perl und Softwareengineering-Level sind, die FHEM kennen und passiv ignorieren "FHEM ist halt alt." (Thema beendet.) Oder aktiv ignorieren "Richard, tu Dir den Scheiss nicht an, das ist es nicht wert." (beides Reaktionen auf meine Vorschläge sie könnten doch mitmachen)

Wisst ihr wo der Hauptunterschied zwischen mir und diesen Kollegen ist? Ich bin a) oftmals bereit auch scheinbar hoffnungslose Schlachten aufzunehmen, b) wenn ich eine begründete Überzeugung habe, habe ich keine Scheu mich auch vor 1000 Leute zu stellen und zu sagen "Ihr liegt falsch".  Angenehm ist das nie, aber ich kann das ab.

Und genau deswegen ist hier keiner von den Kollegen aufgetaucht, sondern ich. Genau genommen ist auch offensichtlich keine bekannte Kapazität aus der Perl Community aufgetaucht, weil ab dem Augenblick ab dem er (oder sie - ein paar gibt es ja) erfahren hätte "CPAN - nehmen wir nicht, wir haben unsere tollen Cleanroom Implementierungen", wäre er/sie auf "Absatz kehrt" wieder entschwunden.

Das ist im übrigen - sollte das jemand nicht begriffen haben - 90% ein Seitenhieb auf die Perl Community und nur 10% auf die FHEM Community.

Was ich aber derzeit gefühlt erlebe ist, das sich Richard (manchmal aber eben nicht ausschliesslich "unvorteilhaft") einbringt, die andere Seite sich aber mehr mit dem "Wie er sich einbringt" als mit dem "Was er da macht" auseinander setzt.

Aber selbstverständlich. "Der Ton macht die Musik", "Es geht um das Wie, nicht um das Was."

Angeblich achtet man (nicht ich) nur zu 8% auf den Inhalt einer Präsentation und zu 92% darauf wie schön die Piecharts sind, wie angenehm der Vortragende auftritt und was er anhat. Irrsinn! Leute die das machen, werde ich weiter nach Kräften sabotieren. 

Ich teile ebenfalls nicht die Meinung, das der bestehende Code "nicht unter Kontrolle" sei. Ich begrüße jedoch ein schrittweises Refactoring ausdrücklich.

Ich bin bereit zu sagen, der Code ist teilweise unter Kontrolle, wenn wir bei der Testsuite eine Code Coverage von 40% hinbekommen. Das kann Dir jetzt auch auf den Sack gehen, aber die Code Coverage ist derzeit bei 0%. Das entspricht in etwa einem Blindflug bei Nacht und Nebel ohne Instrumente. Ich würde in so einem Fall nicht davon sprechen, das Flugzeug sei unter Kontrolle.

Klar, man kann einen erfahrenen Kapitän wie Rudolf haben, der dafür sorgt, dass nicht alle Passagiere sofort sterben und wie macht er das? Er sorgt dafür, dass sich am besten nix ändert. Gleiche Flughöhe, nix anfassen, alles bleibt wie es ist. Die Passagiere werden natürlich auch so sterben. Nämlich dann, wenn das Kerosin alle ist, aber bis dahin ist es noch lange hin. Heizung und Lüftung tut ja, ein paar Snacks sind auch noch da.

Ich sage auch nicht "Hey komm' Rudolf! Wer nicht wagt, der nicht gewinnt! Lass uns hier alles auf den Kopf stellen, wird schon irgendwie klappen." Das wäre nämlich jugendlicher Leichtsinn. Ich sage: "Lass uns versuchen ein Instrument nach dem anderen in Betrieb zu nehmen."

Ich würde mir wünschen darauf als Antwort nicht ein: "Wieso? Tut auch so." zu hören.

Gedanken über Regelprozesse in der IT zu machen. Dazu gehört nämlich auch, "Lifecycles" kontinuierlich zu verbessern. Und das impliziert eben nicht, das sie zwangsläufig auch schlecht sind. Wenn aber Verbesserungen gefunden werden, dann sollten sie nach einer sachlichen Prüfung doch auch Einzug halten und nicht mit einem Fingerzeig abgewiesen werden. Find ich nicht ok!

Dem kann ich nur zustimmen und sonst nix hinzufügen.

Den einen oder anderen Tod muss man dann auch mal sterben. Und vorallem sollten sich beide Seiten mal die Hand reichen und überlegen, wie man hier gemeinsam an einem Strick ziehen kann!

Wasch' mich aber mach mich nicht nass - davor sollte man sich hüten. Das geht nicht. zumindest weiß ich nicht wie.
Meine Hand reiche ich hier tagtäglich durch die "irrsinnige Energie" die ich hier reininvestiere. Das wird auch nicht ewig andauern (können).

[RichardCZ]

Und zu hobo.pl möchte ich sagen: Eine Abspaltung vom FHEM Projekt ist eigentlich das Letzte was ich möchte.
Derzeit ist das nix anderes als mein Playground.

Allerdings schneide ich da rigoros an Zöpfen herum und muss - aus Respekt vor dem FHEM Projekt - dem Kind einen anderen Namen geben (habe ich auch nicht großartig nachgedacht welchen - HomeBot war jetzt naheliegend), hobo ist eigentlich ein Witzchen: https://de.wikipedia.org/wiki/Hobo

Weil stellt euch vor, irgendjemand lädt hobo runter und schlägt dann hier auf und nervt mit Support.



Aber man muss auch offen sagen, dass es mir wohl leichter fallen würde meine Kollegen zu überzeugen bei hobo mitzumachen als bei fhem und auch ich bin nur ein Mensch. Wenn es hier vergebene Liebesmüh' sein sollte, dann kann ich ja - GPL sei dank - meine Schäufelchen in einen anderen Sandkasten tragen.

[Martin Fischer]

Martin, ich weiß nicht wie mein Text exakt bei Dir ankommt, aber Du solltest vorab wissen, dass ich Deine Sichtweise der Dinge (nicht nur in diesem Thread) für die ausgewogenste halte, die mir bislang im FHEM Forum begegnet ist.

Danke Richard, für die Ausführung..

Ich teile einige Deiner Ansichten und an dieser Stelle sind wir (nachweisbar) zu 100% seelenverwandt:

Ich bin a) oftmals bereit auch scheinbar hoffnungslose Schlachten aufzunehmen, b) wenn ich eine begründete Überzeugung habe, habe ich keine Scheu mich auch vor 1000 Leute zu stellen und zu sagen "Ihr liegt falsch".  Angenehm ist das nie, aber ich kann das ab.

Ich will hier aber nicht "Kommunikationstrainer" spielen... da wäre ich sicher komplett falsch... erlebe ich doch durch die gleiche Einstellung wie gerade zitiert, das ein oder andere Mal ähnliche Reaktionen... dies sind nun mal die Konsequenzen.. 

Dennoch erlaube ich mir eine Anmerkung: weniger "war ich vor ca. <xx> Jahren.", "Code nicht unter Kontrolle", etc. und es liest sich komplett anders. Dann steht nämlich die Sache wirklich im Vordergrund und nicht das von anscheinend vielen wahrgenommene "ich kann es besser".

Ich würde mir wünschen darauf als Antwort nicht ein: "Wieso? Tut auch so." zu hören.

Das teile ich zu 100%.

Meine Hand reiche ich hier tagtäglich durch die "irrsinnige Energie" die ich hier reininvestiere. Das wird auch nicht ewig andauern (können).

Streiche den Zusatz irrsinnige Energie, denn das ist wieder ein sidekick. Ansonsten nehme ich (und sicher auch andere) Deinen Einsatz (bezogen auf das "Was" ) wohlwollend wahr und befürchte aber letzteres.

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