Core-Entwicklung zu schnell?
-
@cash sagte in Core-Entwicklung zu schnell?:
wo gibt es denn kurz Protokolle zu den Dev-Treffen?
-
@cash sagte in Core-Entwicklung zu schnell?:
durch die "Zwangsumstellung" auf userdata
Das war aber Admin5 und nicht der Controller ;-)) (nur so der vollständigkeit halber)
-
@sigi234 ich kann ja blind sein aber ich finde dort kein Protokoll. Z. B. Dezembertreffen dort gab es ein Thema: Roles und typeDetector - "Welche neuen Rollen und ggf Gerätetypen haben wir eingeführt?"
Aber im dem Thread steht nicht was es nun gab oder nicht...
Oder der User e.s. fragt ob ein Thema angesprochen wurde. Antwort: "Ja. Lösung ist angedacht"
Unter Kurz-Protokoll verstehe ich etwas anderes...
-
@cash sagte in Core-Entwicklung zu schnell?:
Aber im dem Thread steht nicht was es nun gab oder nicht...
Letzte neue Typen gab es im Juni oder Juli ... wir haben das aber als eines der "immer auf der Agenda Themen". Von daher: Ja hätte ein "nichts neues" Klarheit gebracht ... @ldittmar
Oder der User e.s. fragt ob ein Thema angesprochen wurde. Antwort: "Ja. Lösung ist angedacht"
Wenn etwas "Zu kurz" ist -wie oben geschrieben - einfach im Thread Fragen und wir ergänzen das fehlende.
-
@cash sagte in Core-Entwicklung zu schnell?:
@sigi234 ich kann ja blind sein aber ich finde dort kein Protokoll. Z. B. Dezembertreffen dort gab es ein Thema: Roles und typeDetector - "Welche neuen Rollen und ggf Gerätetypen haben wir eingeführt?"
Aber im dem Thread steht nicht was es nun gab oder nicht...@ldittmar sagte in Meeting für ioBroker Core/Dev/Admin 15.12.21 20:30:
Alles was im Meeting besprochen wurde, wird hier unterhalb der Themen, stichpunktweise dokumentiert.
-
Dann geb ich auch mal noch meine Sichtweise dazu.
Ich fand „Entwicklung geht zu schnell“ für mich sehr treffend.
Es geht mir weniger um den js-controller und ggf. die deprecations aus der neuen Version, die sind zwar auch nerven, aber sehe eher das ganze drumherum was sich mal schnell ändert.Zum einen gibt es die Änderungen die außerhalb von ioBroker stattfinden:
- nodejs,
- 3rd-party API,
- die Geräte selbst (neue Funktionen, neue Gerätespektrum,…)
- … usw.
Teilweise gibt es nicht einmal eine offizielle Doku um etwas aufzubauen und man weiß auch nicht so recht was man da an dependencies einbindet.
Zum anderen sind es die Dinge in ioBroker selbst:
- Umstellung auf compact mode,
- template/create adapter (mit den best practices), was man dann auch nachziehen möchte
- neue Funktionsaufrufe (auch teilweise als Ersatz was man vorher im Adapter hatte)
- admin Umstellungen
- neue Parameter in io-package
- … usw
- und auch die richtige Definition der Objekte
(wobei das eher ein Adapterfehler aus der Vergangenheit ist)
Für mich ist es ein Hobby und hauptberuflich bin ich kein Entwickler, bin also nicht mit allen Tricks und best practices in JS bewandert. Aber man lernt dazu. Also ist es Spaß an der Freude, das etwas läuft und auch anderen dienlich ist.
Die neuen Tools und auch Testautomatisierung kann ich nur unterstützen. Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
@jey-cee
Die Frage nach dem Zeitaufwand für die Adapterentwicklung und Maintenance ist wirklich berechtigt.
Meine obigen Aspekte sind natürlich auch mit dem Verfolgen des Forums oder nun der Entwicklerseite machbar. Wendet man aber nicht die Zeit auf, dann wird man quasi kalt erwischt und es ist für einen selbst hektisch und gefühlt zu schnell.
D.h. zu der eigentlichen Entwicklung oder den Adapter auf Stand zu halten kommt ein nicht unwesentlicher Teil sich in die Dinge zu vertiefen.
Parallel möchte man aber auch gern andere neue Dinge/Adapter/Vis ausprobieren.Am Ende fehlt irgendwie die Zeit.
Und ja, auch ich habe mir schon des öfteren gesagt, daß ich keinen weiteren Adapter entwickeln sollte, da es doch recht viel Zeit in Anspruch nimmt.
Die Doku wird besser, aber auch die richtige Info finden ist immer noch eine Herausforderung. Immerhin gibt es nach dem aufmerksamen Lesen diese Threads einige neue Anlaufstellen, die ich vorher nicht kannt. In Vergangeheit war in der Tat eher „wie wurde es in einem anderen Adapter gelöst“ zielführender.
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.Gruß
Klaus -
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
Ich hab das in ein paar meiner Adapter drin (und auch ein paar Core-Adapter haben das recht viel wie sql/influxDB und History, auch MQTT, ical ...), teilweise sehr "exzesiv" ... und ehrlich: Der Aufwand das mit einer sinnvollen Abdeckung hinzubekommen war dabei mindestens so groß wie es den Adapter und die Lib zusammen zu schreiben
Den Aufwand sind nur wenige Entwickler bereit zu investieren. Auch weil ggf der Aufwand das ausgewählte Device oder den Service zu Mocken sehr schwierig (bis teilweise unmöglich). technisch möglich ist fast alles was mocking angeht ... HTTP sehr easy, aber auch Serialport und andere Network-Protokolle gehen ... man geht aber je nach Protokoll sehr tief runter und muss sich in vieles einarbeiten was sonst zB eine Lib die man nutzt für einen wegkapselt Rein faktisch kannst Du das alles mit dem testing Framewerk (sowohl alt wie auch neu) alles machen, wobei wir noch wenige Adapter haben die mit dem neuen Framework hier umfangreiche Tests gebaut haben.
-
@apollon77 sagte in Core-Entwicklung zu schnell?:
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
Ich hab das in ein paar meiner Adapter drin (und auch ein paar Core-Adapter haben das recht viel wie sql/influxDB und History, auch MQTT, ical ...), teilweise sehr "exzesiv" ... und ehrlich: Der Aufwand das mit einer sinnvollen Abdeckung hinzubekommen war dabei mindestens so groß wie es den Adapter und die Lib zusammen zu schreiben
Den Aufwand sind nur wenige Entwickler bereit zu investieren. Auch weil ggf der Aufwand das ausgewählte Device oder den Service zu Mocken sehr schwierig (bis teilweise unmöglich). technisch möglich ist fast alles was mocking angeht ... HTTP sehr easy, aber auch Serialport und andere Network-Protokolle gehen ... man geht aber je nach Protokoll sehr tief runter und muss sich in vieles einarbeiten was sonst zB eine Lib die man nutzt für einen wegkapselt Rein faktisch kannst Du das alles mit dem testing Framewerk (sowohl alt wie auch neu) alles machen, wobei wir noch wenige Adapter haben die mit dem neuen Framework hier umfangreiche Tests gebaut haben.
Ich mach es ja im neuen Framework auch schon mit dem fritzdect und musiccast
Ja, die wenigsten nutzen es überhaupt und noch weniger nutzen wahrscheinlich das Framework aus dem template.
Und ja, das ist aufwendig, aber hat sich bei meinen beiden Adaptern gelohnt. Man injiziert die unbekannten Antworten und der Adapter spuckt die gleichen Fehler in der eigenen Umgebung aus.
Wahrscheinlich wär es damals das Beste gewesen im neuen Framework die alten Tests zu belassen, aber die Möglichkeit hatte ich damals nicht erkannt (und man will ja auch auf Stand sein.)
-
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.
Du kannst dir ja mal das aktuelle rohe Gerüst anschauen und uns gerne Issues erfassen, wenn dir das etwas fehlt.
Genau eine solche Doku wie du sie wünschst scheint mir absolut wichtig und zentral. Aber es ist auch wichtig, dass wir Feedback wie deines (auf dem richtigen Weg) erhalten und als Basis für die Aktualisierung verwenden.
-
@unclesam sagte in Core-Entwicklung zu schnell?:
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.
Du kannst dir ja mal das aktuelle rohe Gerüst anschauen und uns gerne Issues erfassen, wenn dir das etwas fehlt.
Genau eine solche Doku wie du sie wünschst scheint mir absolut wichtig und zentral. Aber es ist auch wichtig, dass wir Feedback wie deines (auf dem richtigen Weg) erhalten und als Basis für die Aktualisierung verwenden.
Da steuere ich doch gern ein paar Ideen (issues) bei.
