Ankündigung

Einklappen
Keine Ankündigung bisher.

LBS Entwicklung best practices

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    LBS Entwicklung best practices

    Hallo zusammen,

    gibt es irgendwo schon eine Sammlung von best practices für die LBS Entwicklung? Ich meinte es hätte dazu mal einen Thread gegeben, finde ihn aber nicht.

    Mir geht es z.B. um folgende Fragen:
    - Debug Levels (nur 0/1 oder Bedeutung unterschiedlicher Level)
    - Error Handling (eigener Error Ausgang, nur Code oder auch Text?)
    - Log schreiben / writeToCustomLog (Name des Log, inkl. Instanz ID ....)
    - Benennung Parameter (Abkürzungen, englisch / deutsch ...)
    - Beschreibung deutsch / englisch?
    - Verwendung von HTML Tags in Beschreibungen
    - Versionierung (v1.0, V1.0, V 1.0, V 2020-03 ....)
    - Changelog im Code
    - Ausführung bei Änderung eines Eingang starten oder extra "Trigger" Eingang (hängt vermutlich vom use case ab)
    ....

    Viele Grüße
    Nils

    #2
    Hallo Nils,

    ich wüsste nicht, dass es da eine "Regelung" gibt. Wäre aber sicher hilfreich, wenn das mal jemand im Wiki (https://www.knx-home.net/wiki/index.php/Hauptseite) aufschreibt und Codeschnipsel bereitstellt. Ich habe oft bei jonofe abgeguckt. Er hat meiner Meinung nach eine sehr "schöne" Logging-Methode geschrieben, die man gut von jeder Stelle des LBS aus benutzen kann (mit entsprechenden Event-Level). Das finde ich persönlich besser als 0 und 1 (gerade bei komplexen LBS). Ich habe auch schon mehrfach überlegt, ob ich Christian ( gaert ) frage diese Methode in EDOMI zu implementieren, damit die LBS-Logs einheitlicher werden. Aber naja .. da steht soviel "uff Liste", dass das eher in die Kategorie "nice to have" gehört.

    Auch bei den Versionsnummern gibt es keine Vorgaben oder festes Schema. Die meisten Benutzen eine 0.x um den "Beta"-Status der LBS zu verdeutlichen. Aber letztendlich ist ja jeder der einen LBS verwendet auch ein Stück weit selbst verantwortlich. Auch im Downloadportal ist die Version ein Freitextfeld, welches keinen Regeln unterliegt. Das haben wir schon mal Diskutiert. Vorallem bzgl. des Überwachungs-LBS für LBS-Updates.

    Letztendlich ist es nur deinem eigenen Anspruch unterworfen und du entscheidest, was du für notwendig erachtest. Wie du schon schreibst, ist das alles auch von der Komplexität abhängig. Wenn ein LBS nur einen Mittelwert o.ä. bildet, was will ich dann mit 8 Log-Leveln, einem Changelog und einer Versionsnummer? Wenn ich an den Beschattungs-LBS von Yves starwarsfan denke, ist das alles schon berechtigt.
    Gruß
    Stefan

    Kommentar


      #3
      Perfekt zusammengefasst!

      Kommentar


        #4
        Moin,

        ich bin gerade dabei, ein neues LBS auf die Beine zu stellen, aber habe das Problem, dass ich irgendwo einen Fehler reingebastelt habe - Edomi meckert, dass da ein Fehler ist (wenn ich das Edomi-Drumherum weglasse, dann ist die PHP in Ordnung)

        Ich finde den Fehler so nicht, gibt es irgendwo eine Log-Datei, wo ich sehen kann, was da das Problem ist ?

        Danke schonmal!

        Kommentar


          #5
          Eingänge oder Ausgänge doppelt vergeben? Ansonsten mal den kompletten LBS mal hier checken http://sandbox.onlinephpfunctions.com

          Kommentar


            #6
            Ich entwickle unter Linux, vondaher kann ich da mit

            php -d display_errors=on datei.php

            direkt auf der Shell ausführen. Der Tipp mit dem doppelten Ausgang war gut, hier war der Fehler. Danke!


            Trotzdem stellt sich die Frage, wie man aus Edomi hier paar mehr Infos rausgekitzelt bekommt, "1 Fehler gefunden" ist doch etwas zu knapp.

            Kommentar

            Lädt...
            X