Core-Entwicklung zu schnell?
-
@apollon77 sagte in Core-Entwicklung zu schnell?:
@mickym Ich denke diese Diskussion gehört dann wirklich in die Threads wo Sie hin gehören bzw in die GitHub Issues. Wenn Dinge fehlen dann bitte beschreiben und darstellen warum was nötig ist (hier musst Du uns - bzw Bluefox - bitte erklären was warum nötig ist ...) und dann sehen wir weiter. Am Ende der letzte Text mit nem praktischen Beispiel vllt ...
.. weißt Du genau damit habe ich etwas ein Problem. Ein System hat vorher super funktioniert, dann werden Beschränkungen eingeführt und ich bin nun in einer Art Rechtfertigungsposition, warum was gebraucht wird. Ich habs ja kurz erklärt, will aber ja gar nicht in die Details gehen. Sondern es ist die Vorgehensweise, wie das hier Admin bzw. JS Adapter diese Einschränkungen eingeführt haben ohne all diese Dinge zu beachten.
Warum geht man nicht den Schritt zurück und nimmt bestimmte Dinge eben aus diesen Regeln aus?
Mir geht es nicht um die technische Diskussion, sondern um die Vorgehensweise, das man Dinge einführt, die vorher keine Probleme gemacht haben und nun machen sie Probleme und man ist als Anwender in eine Anfordererposition gedrängt worden, die man eigentlich nicht haben wollte. Ich habe es jetzt und bereits mehrfach erklärt, dass zum Beispiel mqtt eine Hierachie von topics darstellt, die aber im Prinzip so offen und frei war, wie es der iobroker vor den Prüfungen und der Struktur eben auch war.
Auch meine Liste der Einschränkungen im Admin 5 im Vergleich zum Admin 4 (von Mausbedienung, Spaltenkonfig, Kopieren von Namen etc. über die Oberfläche, fehlende Dialoge für common Eigenschaften, unnötige Beschränkungen von Verzeichnisnamen, wenn diese Adapternamen ähneln wird eher länger anstelle kürzer und da sehe ich auch nach einem halben Jahr keine Entwicklung.
Es geht mir hier nicht um eine technische Diskussion, sondern gemäß dem Threadtitel "Core Entwicklung zu schnell" - wollte ich eigentlich mit meinen Beiträgen klar für ein JA votieren, da viele Dinge eben nicht mehr zusammen passen, die früher keine Probleme gemacht haben und jetzt eben schon und anstelle dass man diese Dinge wieder zurück nimmt und die Issues behebt, wird man eben als User zu jemand der nun um Fehlerbehebungen bitten muss, die vorher einfach nicht erforderlich waren.
-
@mickym sagte in Core-Entwicklung zu schnell?:
die früher keine Probleme gemacht haben
Jetzt wage ich es mal frech umzuformulieren: Aus Deiner Sicht früher keine Probleme gemacht haben... Und da sind wir wieder beim großen ganzen. Nur weil etwas technisch geht ist es nicht gut oder sinnvoll. Die Probleme entstehen dann ggf in Bereichen die Du gar nicht im Blick hast oder nutzt! Und das ist voll ok so. Und wie solche Beispiele zeigen sehen (natürlich) auch wir nicht alle Sonderfälle.
Es gibt gute Gründe für diese Beschränkungen und wenn Du Fälle hast wo es nicht passt dann kannst nur Du (jetzt mal plakativ) uns helfen es zu verstehen. Wenn Du das nicht willst dann wird es schwierig, sorry.
Wir sind auch nur Menschen und wir treffen (nicht allein sondern in Teams) Entscheidungen und zwar nach bestem Wissen und Gewissen. Hier geht es nicht darum sich zu rechtfertigen, sondern ein gemeinsames Verständnis über Requirements zu entwickeln.Und jetzt gehe ich erstmal ins Bett ... war ein langer Tag.
-
@apollon77 sagte in Core-Entwicklung zu schnell?:
@mickym sagte in Core-Entwicklung zu schnell?:
die früher keine Probleme gemacht haben
Jetzt wage ich es mal frech umzuformulieren: Aus Deiner Sicht früher keine Probleme gemacht haben... Und da sind wir wieder beim großen ganzen. Nur weil etwas technisch geht ist es nicht gut oder sinnvoll. Die Probleme entstehen dann ggf in Bereichen die Du gar nicht im Blick hast oder nutzt! Und das ist voll ok so. Und wie solche Beispiele zeigen sehen (natürlich) auch wir nicht alle Sonderfälle
Das an sich mache ich ja auch niemand zum Vorwurf. Was ich allerdings nicht verstehe warum es soviel Probleme macht, die Teile, die halt nicht gesehen wurden die Beschränkungen aufzuheben.
Es gibt gute Gründe für diese Beschränkungen und wenn Du Fälle hast wo es nicht passt dann kannst nur Du (jetzt mal plakativ) uns helfen es zu verstehen. Wenn Du das nicht willst dann wird es schwierig, sorry.
Ich glaube ich bin eigentlich prinzipiell schon kooperativ, bin aber auch kein Entwickler und eher weniger der Beta - Tester.
Ich mache auch niemand Vorwürfe für getroffene Entscheidungen, aber es muss doch auch möglich sein, Entscheidungen zu revidieren ohne dass das schlimm ist.
Ich habe halt eher das Gefühl, dass man den eingeschlagenen Weg nun halt auf Biegen und Brechen weiter gehen will.
Ich plädiere doch nur für Ausnahmen und wenn diese Ausnahmen Probleme in anderen Bereichen machen, dann würde ich sie schon gerne verstehen.
Das System ist doch aus meiner Sicht so flexibel, dass wenn man Beschränkungen einführt dies nicht immer gleich global machen muss, insbesondere wenn es vorher nicht der Fall war.Und jetzt gehe ich erstmal ins Bett ... war ein langer Tag.
Na dann liest Du es morgen und ich wünsche Dir erst mal ein gute, erholsame Nacht. Und ich will hier niemand ärgern, noch persönlich angreifen, sondern habe meine Meinung geäußert, dass ich dieses Update halt etwas unglücklich fand.
Wie gesagt die Probleme die die Flexibilität an Stellen gemacht hat, die ich nicht sehe, so sehr machen die Beschränkungen halt nun Probleme, die halt übersehen wurden. Und mein Vorschlag war doch nur, vielleicht kann man beidem gerecht werden, in dem man um das im Politikerjargon zu sagen - den Weg der unterschiedlichen Geschwindigkeiten einschlägt bzw. eben Ausnahmen macht, dort wo es nicht sinnvoll erscheint.
-
Guten Morgen alle zusammen,
wenn ich als normaler User diesen Thread lese, wenngleich ich auch nicht alles verstehe, so bleibt aber doch am Ende
eins hängen....Ich habe hier mindestens zweimal gelesen dass "ich keine neuen Adapter mehr entwickele", und ein drittes Mal gefühlt zwischen den Zeilen ....
sollten dann nicht die Alarmglocken klingeln ?
Ist es nicht das, was IOBroker so stark macht ? die Entwicklung von neuen Adaptern ? die unglaublich vielfältige Flexibilität ? Ist es nicht das, warum soviele User von anderen Systemen auf IOBroker umsteigen ? Ist es nicht das, warum sogar ich IOBroker nutze ?..... weil ich hier HUE, HMIP, Viesmann und Alexa kombinieren kann ?
Wenn das Grundgerüst IOBroker weiterentwickelt wird, was sicherlich wichtig und richtig ist, aber die Adapterentwicklung wegbricht, wo steht dann das System in 2-3 Jahren ?
Sorry, aber es war mir ein Bedürfnis diesen Kommentar loszuwerden.
Gruß Bernd
-
@skokarl Guten Morgen Bernd. Es ist sicher keine Weltuntergangsstimmung und die Argumente von den Core Entwicklern sind natürlich auch alle richtig. Iobroker wird nicht untergehen, nur weil zwei Hobbyprogrammierer keinen neuen Adapter mehr bauen möchten. War vielleicht auch etwas provokant ausgedrückt.
Fakt ist nun mal, das ein inzwischen so gewaltiges und gutes System wie iobroker sehr komplex wird. Und genau damit haben die Core Entwickler zu kämpfen. Ich weiß, was es bedeutet, denn Gesamtüberblick zu behalten. Und klar, es muss vorwärts gehen, auch wenn dabei ein paar "alte" ungepflegte Adapter rausfliegen. Im schlimmsten Fall findet sich dann jemand, der es fixt. Das ist der Vorteil einer Community.
Ich finde es gut und wichtig, dass wir diese Diskussion führen. Und auch deine Meinung aus User Sicht. Wie @apollon77 schon sagte, machen wir das alle als Hobby. Das kann uns nur weiterbringen.
Mein Resümee, ich werde mir Zeit nehmen müssen, um Änderungen mitzubekommen. Discord habe und will ich nicht, das forum hier war für mich bisher die Quelle. Dass es nun mehrere Orte gibt, an denen diskutiert wird macht es natürlich nicht einfacher.
Ich freue mich auf jeden Fall auf das Dev. Doku Team und bin gespannt. Mit guter Doku wird bestimmt auch vieles einfacher. Wahrscheinlich ist vieles doch einfacher, als ich es bisher mache und ich wusste nur nicht wie.
Grüße Eisbaeeer -
Ich sehe mich auch als beta tester und ich lese sehr viel, besonders ist es derzeit wirklich wichtig im discord channel zu lauschen. Oder auch mal ein thread im forum zu lesen der nicht unbedingt auf den ersten blick mit den eigenen Interessen konfirm zu sein scheint.
Und dabei fällt es eben auf, alle meckern über Kommunikation aber kaum einer schafft es einen Beitrag über seinem eigenen zu lesen. Sicherlich hat man nicht immer die Zeit alles zu lesen und wenn man dies zu sehr macht, dann kann einen das alles auch krank machen.
Also sehe ich es auch so, daß dies zentraler gemacht werden muss. Wichtig für mich sind immer die Infos aus den dev treffen. Super, diese werden jetzt auch im Blog veröffentlicht. Eine super Idee, leider brauchte ich ewig um diesen Blog zu finden, die Info dazu genauso.
Das ist auch wieder ein Beispiel dafür.Bei mir liegt es klar daran das ich nur mobil im forum und discord unterwegs bin, nie aber auf die iobroker Homepage gehe. Es gibt doch genug Möglichkeiten durch Ankündigung usw diese auch dort sinnvoll zu platzieren.
@mickym
Sorry, ohne dir jetzt zu nahe zu treten, aber bei dir lese ich immer nur, früher war alles besser. Dann lass dein System eingefroren und sei glücklich.
Mqtt ist ein uraltes System und ist meines Erachtens sowieso schon nicht mehr wirklich sinnvoll. Ich habe meine esps alle mqtt befreit und auf native api umgestellt.
Und wenn es jetzt ein bisschen wie Äpfel mit birnen vergleichen ist. Wenn dein Chef, deine Frau oder die Politik eine neue Regelung herausgibt, gehst du dann auch sofort auf Konfrontation und sagst: nööö, das habe ich schon immer so gemacht.
Egal ob es vorher falsch war, nur eben nicht reguliert?Ich habe mich immer aufgeregt weil meine Geräte nicht als Geräte erkannt werden. Nachdem ich mich mit dem Thema Rollen usw beschäftigt habe, weiß ich erst wie schwierig dies ist.
Nun muss ich alle Fehler beseitigen, die in den Adaptern sind und verlinke alle states auf die richtige rolle, Funktion, Einheit usw. mit linkeddevice und alias.
Dies ist sehr aufwendig und nervt mich auch, aber ich möchte gerne ein sauberes System haben was später überall schnell kompatibel ist.Und das ist eben manchmal eben auch Aufgabe des users selbst. Sicherlich könnte ich auch weiter die devs nerven, aber man merkt aus so das viele auf der kippe sind aufzugeben. Deswegen spare ich mir dies, obwohl es nicht wirklich zielführend für alle ist.
Ich glaube viele haben auch nicht mitbekommen, daß einige Adapter auch schnell und unkompliziert "gerettet" wurden. Gerade zum neuen js Controller gab es einige Adapter die nicht mehr gingen. Schnell wurden diese zum Community Adapter und ein oder mehrere devs versuchten diesen wieder zum laufen zu bringen.
Also so schnell stirbt kein Adapter, weil es eben ein wir gibt. Wer Probleme hat, sollte sich nur in der richtigen Form daran wenden.Eine Sache die mich dahingehend selbst stört, viele schwierige Fragen werden schlecht oder gar nicht beantwortet und andere zum 3000. Mal.
Aber dies ist leider ein Problem was gefühlt überall so ist und es keine Lösung für gibt.
Da diejenigen die diese beantworten könnten blockiert sind mit Spam der leseunwilligen.
Sorry, der Satz ist jetzt hart und wird einige aufstoßen lassen, aber es ist so. Und leider hilft auch da die beste Doku nichts. -
@e-s
ich würde gerne auch noch einmal etwas (mehr) dazu aus meiner Sicht schreiben.Hier sind zwei (für mich) sehr wichtige Informationen.
Zum einen die Anfrage von @mickym zu MQTT.
(speziell gehört das in einen eigenen Thread, aber) Allgemein möchte ich dazu, und zu der AussageEtwas was bisher lief später verbieten geht nicht.
(Sinngemäß - ich find es gerade nicht mehr)Auch bei den Adaptern läuft manchmal etwas "plötzlich" nicht mehr, weil der Hersteller etwas geändert hat.
z.B. der Harmony-Adapter. Dort (und eben auch bei anderen Adaptern) wurden undokumentierte Funktionen verwendet, die anschließend wegen möglicher Sicherheitslücken geschlossen wurden.
Einige Adapter funktionieren (aus meiner nicht Dev-Sicht) nur weil da etwas "gehackt" wurde.
Wenn dann so "eine Lücke" geschlossen wird -warum auch immer- klappt das bisherige Vorgehen nicht mehr.und genau so ist es mit ioBroker.
Ich schätze das Wissen und die Meinung von @mickym zu node-red sehr und MQTT ist wirklich ein Sonderfall.
Es ist ein altes Protokoll aber in meinen Augen lange noch nicht veraltet und kommt auch noch außer bei den ESP sehr häufig vor.
Aber auch wenn es unbequem ist, sollte eine Lösung möglich sein. Die allerdings ggf. anders aussieht als das bisher genutzte.Ähnliches gilt für die Strukturierung der Objekte.
Auch das ergibt in meinen Augen einen Sinn und beschert uns im Moment Mehrarbeit.
(Auch ich nutze noch Verzeichnisse aus der Vor-0_Userdata-Zeit, zum Glück alles einzeln manuell erzeugt und daher mit Objekten)
der zweite Punkt ist:
@e-s sagte in Core-Entwicklung zu schnell?:
Viele schwierige Fragen werden schlecht oder gar nicht beantwortet und andere zum 3000. Mal.
diesen Schuh ziehe ich mir mal an.
Mir geht es wie ein Mix aus @Thomas-Braun und @Eisbaeeer.
Ich habe früher die (User-) Dokus in Form des Github Wikis, und der ersten und dritten Wordpress Version nahezu allein geschrieben, auch die aktuelle Doku hatte ich mit viel Elan begonnen.
Vorher hatte ich keinerlei Berührungspunkte mit GitHub oder Wordpress.
Ich habe mich da jeweils eingearbeitet und dann Schritt für Schritt das Können und Wissen ausgebaut.
Das jetzige Framework ist jedoch für mich zu komplex. die Struktur hat eine hervorragende Idee, weil damit die automatisierte Erstellung in mehreren Sprachen ermöglicht wird.
Leider muss ich mich da jedesmal wieder neu einarbeiten wenn ich da nicht nahezu täglich mit arbeite.
Da schreibe ich lieber den selben Text mehrfach im Forum. (Wobei das Forum für mich die wichtigste Quelle für Informationen ist, was in der Doku für Einsteiger nicht passt)
Auch hier muss ich leider feststellen, dass die heutige automatisierte Doku wieder an einigen Stellen Gefahr läuft für Einsteiger unverständlich zu werden. Zu allem Überfluss wurden auch noch Artikel von mir anscheinend mit automatisierten (technischen) Beschreibungen ersetzt.Allerdings kann und will ich im Forum auch nur die Fragen beantworten, bei denen ich wirklich weiß was ich schreibe. Und das ist zwar einiges, aber da ich kein Entwickler bin und auch nicht alle Systeme besitze, halt nicht alles.
Manchmal versuche ich noch die Fragen etwas einzugrenzen um anderen Helfenden alle notwendigen Informationen zu verschaffen.
Aber dadurch werden einige Frage halt 3000 mal und ander gar nicht beantwortet
-
Was ich mir wünschen würde ist ein zentrales Eingangsdokument für meine Entwicklerfragen. Da muss am Anfang gar nicht soviel drinnstehen. Wichtig wäre nur, dass die Infos aktuell sind. Das können auch Links ins Forum, Github oder npm sein. Die Form wäre mir da gar nicht so wichtig, nur aktuell sollten die Infos halt möglichst sein. Was meine ich z.B.: wenn ein Dev mit einem Adapter startet, dann schau Dir ioBroker.example an, dann verwende für das Grundgerüst möglichst immer ioBroker.create-adapter. Wenn Du tiefer einsteigen willst, dann schau Dir iobroker.adapter-react an. So in der Art und das für möglichst viele dev-Themen fände ich super.
-
@carsten04 sagte in Core-Entwicklung zu schnell?:
Was ich mir wünschen würde ist ein zentrales Eingangsdokument für meine Entwicklerfragen.
Unser Ziel ist es, dass iobroker.dev genau dieser Einstiegspunkt wird. Wenn euch etwas fehlt, dann bitte Issue erfassen.
Die Entwickler-Doku wird im Verlauf des nächsten Jahres als GitHub Pages neu aufgebaut: https://iobroker.github.io/dev-docs/. Und auch hier: bitte Issue erfassen, wenn ihr Ideen habt.
Und ich bin jetzt mal so frech: wer an diesen Orten (und allen anderen "globalen" Repos) keine Issues erfasst und nicht in den Entwickler-Meetings und/oder auf Discord/Telegram im Entwickler-Chat mitredet, soll sich hier bitte zurückhalten mit Kritik(*). Wir haben Kanäle, wo man Fragen stellen kann und Kritik anbringen kann, die müssen aber auch genutzt werden!
@apollon77 und alle anderen, die sich angesprochen fühlen: sorry wenn ich immer negativ schreibe, das positive geht so schnell vergessen! Ich glaube mit (guter, konstruktiver) Kritik können wir wachsen. Und ja: es ist sehr erfreulich, zu sehen wie viele Fortschritte wir in den letzen Jahren gemacht haben, weiter so!
(*) Damit meine ich Entwickler. Das Feedback der anderen Power-User hier ist natürlich sehr willkommen, eure Stimmen sind genauso wichtig, auch wenn ihr nicht (aktiv) auf unseren anderen Kanälen unterwegs seid.
-
@homoran
Ich war früher mal in einigen Enigma2 Foren sehr aktiv, teils als mod, habe auch sehr viele Dokus erstellt. Gelesen wurden diese nur von wenigen.
Das war früher so und wird auch immer so bleiben. So sind die User eben. Kommen nur dann aus den löchern wenn es Probleme gibt, wollen dann sofort die Lösung auf dem silbertablett und lesen selbst die Antworten nicht welche auf ihre eigenen Fragen kamen.
Das kann man dann auch nicht verbessern, zumindest wüsste ich nicht wie.Das einzige was vielleicht sinnvoll wäre, das Leute wie @apollon77 sich mit den kleineren Problemen zurückhalten und dies eben den aktiven aber nicht allwissenden beantworten lassen. Um eben mehr Zeit für komplizierte Probleme zu haben.
Also so nach dem Motto, first Level Support für die aktiven User, 2. Level dann für Profis oder so.
Wie oben schon geschrieben, ist auch für mich das forum die erste Anlaufstelle, dort müsste alles sinnvoll und einfach verlinkt sein.
Die iobroker Seite selbst schaut man sich glaube ich nur einmal am anfang an, danach nie wieder. Deswegen würde man auch nichts mitbekommen wenn es neue Sachen gibt und dies dort publiziert wird. -
@e-s sagte in Core-Entwicklung zu schnell?:
Wie oben schon geschrieben, ist auch für mich das forum die erste Anlaufstelle, dort müsste alles sinnvoll und einfach verlinkt sein.
richtig! und dafür braucht es aber eine (vollständige und verständliche) Doku, damit man was zum Verlinken hat
-
@skokarl Wie meine Vor-Antworter bereits gesagt haben ist das kein "riesen Issue" aktuell, dennoch müssen wir es als Open-Source-Projekt schaffen auch solche Themen offen und transparent zu diskutieren.
Im Gegensatz zu den anderen Systemen ist bei ioBroker alles weniger zentral gesteuert, was aber andere Herausforderungen mit sich bringt. Aber mit anderen Ansätzen kommen auch wieder andere Challenges ...
-
@homoran sagte in Core-Entwicklung zu schnell?:
Es ist ein altes Protokoll aber in meinen Augen lange noch nicht veraltet und kommt auch noch außer bei den ESP sehr häufig vor.
MQTT ist DAS iot Protokoll und wird es auch bleiben. Es ist zum Defaktor Standard geworden ... von daher ist das Thema speziell, aber relevant ... Aber ja ein anderer Thread
-
Ich stell jetzt mal ganz Provokant eine Frage:
Wie viel Zeit, in welchem Intervall, soll/muss man als (Adapter) Entwickler den Investieren um auf dem Laufenden zu bleiben?Das würde mich brennend interessieren.
Die Frage von @Eisbaeeer warum das Adapter Gerüst so Komplex ist, ist schon berechtigt. @AlCalzone Antwortet darauf das es doch gar nicht Komplex ist, aber er Arbeitet auch Ständig damit und hat es zum Teil mit entwickelt. Logisch das er das anders sieht.
Aber jemand der nur von zeit zu Zeit mal einen Adapter Entwickelt oder ganz neu ist, dem erschließt sich das nicht.Versucht doch mal die Sichtweise derer an zu nehmen die nicht so Tief im ganzen Stecken und schmettert nicht gleich alles ab.
Die Dev Meeting Protokolle geben meistens nicht mal ein Bruchteil der Informationen wieder, die im Meeting tatsächlich besprochen wurden. Das ist gut um zumindest zu sehen worüber gesprochen wurde, nicht aber um an Detail Informationen zu kommen.
Auch die Changelogs sind nur bedingt als Informationsquelle zu sehen. Oft fehlt der Kontext zu einem Eintrag und man hat gar keine Vorstellung davon was sich geändert hat oder welche Auswirkungen es hat.
In einigen fällen würde es ausreichen wenn die Einträge Ausführlicher wären, nur reicht das eben nicht immer um zu verstehen was genau ein Change eigentlich bedeutet.Hier Übrigens mal was Positives dazu: Die Qualität der Changelogs hat sich deutlich verbessert.
Gefühlt geht die ganze Diskussion hier schon wieder nur um die Doku, aber das hat mit der Eingangsfrage nur zum Teil zu Tun.
Es betrifft die Kommunikation genau so wie die Entscheidungsfindung. @apollon77 hat schon recht das es bei einigen Themen den versuch gab das ganze zu Klären bevor man etwas umgesetzt hat.Das Dev Meeting ist meiner Meinung nach keine gute Umgebung um ein bestimmtes Thema zu Diskutieren, aber durchaus geeignet um eine Entscheidung zu treffen nachdem Diskutiert wurde.
Eigentlich wäre das Forum ein geeigneter Platz um zu Diskutieren, wenn die Diskussionen denn Zielgerichtet Verlaufen würden. Leider driften die fast immer ab und niemand sammelt am Ende die Themen bezogenen Ergebnisse zusammen.
Mal ganz davon abgesehen das die Beteiligung oft gering ist, am Ende ist es immer die selbe Handvoll Personen.Und daran sollten wir Arbeiten!
@apollon77 sagte in Core-Entwicklung zu schnell?:
Das ist ein schönes Beispiel. Ja gibt es - seit fast 2 Jahren mit js-controller 2.2.8 (2020-01-24), steht im Changelog
Darüber hinaus findet sich aber kein Hinweis darauf und genau deswegen hab ich es als Beispiel genommen. Ich müsste jetzt also alle Changelogs von Anfang an lesen um zu sehen das diese Funktion hinzugefügt wurde. Das ist absurd.
@apollon77 sagte in Core-Entwicklung zu schnell?:
Ja und auch ich kann dir diese Garantie nicht geben. Genauso wenig hast Du eine Garantie das Nodejs 18 nicht nen Breaking change enthält der dir alles kaputt macht oder eine deiner Libraries in einer neuen Version alles umstellt. Sorry, that's (Developer) Life ...
Genau das ist doch der Punkt, deine Aussage klang wie eine Garantie wenn man es nur richtig macht. Und damit hast du auch gleich Inkludiert das die Pflege eines Adapters dann nicht Zeitaufwändig ist.
Und damit kommen wir wieder zum Ausgangspunkt: Wieso Entwickler lieber keine neuen Adapter mehr erstellen, weil sie davon aus gehen das es immer (wieder) Aufwändiger wird sie zu erstellen und zu Pflegen.Irgendjemand hat das hier im Thema schon angesprochen, es wäre Sinnvoll den Aufwand zu reduzieren. Diverse Tools versuchen das, aber diese Tools verursachen auch erstmal wieder Aufwand weil man sich einarbeiten muss.
Ganz davon abgesehen das es mit den Tools auch Probleme geben kann, die einen Nerven kosten und man sich dann Entscheidet ohne zu Arbeiten.Beim Release Script hatte ich so einen Fall, es war für mich nicht Nutzbar. Die Fehlermeldung ergab keinen Sinn und irgendwann nach Stunden ging mir die Lust aus mich damit zu beschäftigen, also bin ich den weg zu Fuß gegangen.
Nach ein paar Wochen wollte ich es dann doch schaffen mit dem Release Script zu Arbeiten und hab das Problem nach weiteren Stunden zusammen mit @AlCalzone auch gefunden.Aber ich will mir nicht jedesmal so viel Zeit nehmen müssen wenn ich ein neues Tool nutzen möchte.
@apollon77 sagte in Core-Entwicklung zu schnell?:
Wir sind auf einem guten Weg und das sollten wir auch bewusst sagen und "feiern"!
Auf jeden Fall. Besonders das Feiern, den wenn wir etwas Feiern wird auch Kommuniziert was gefeiert wird.
Trotzdem sollte das nicht als Ablenkung genutzt werden.
-
@jey-cee sagte in Core-Entwicklung zu schnell?:
Mal ganz davon abgesehen das die Beteiligung oft gering ist, am Ende ist es immer die selbe Handvoll Personen.
Und daran sollten wir Arbeiten!Na ja, weil viele User nicht wissen das sie auch am DEV - Meeting teilnehmen können.
-
@sigi234 mir ging es speziell um die Diskussion Außerhalb der Dev Meetings. Da wo sich dann eben auch user beteiligen können.
Übrigens finde ich es ganz gut wenn nicht jeder User in das Dev Meeting kommt. Da geht es ja darum das sich die Entwickler austauschen.
-
@jey-cee sagte in Core-Entwicklung zu schnell?:
Da geht es ja darum das sich die Entwickler austauschen.
Ja das war vllt mal ein Einstiegsgedanke - ich glaube wir sind hier aber schon ein paar Schritte weiter ...
Aber auch Power User sind sehr sinnvoll oder andere die den Entwicklungs- und Testprozess unterstützen wollen. @sigi234 ist einer der immer bei neuen Controller Versionen oder anderen dingen fast der erste ist der testet. @Feuersturm ist beim testing und Issue management vom Admin und anderen Adapters und natürlich macht es großen Sinn das auch solche User mit dabei sind - und jeder der etwas beitragen will oder Informationen bekommen will was so kommt ist aus meiner Sicht immer herzlich eingeladen!
Ich glaube nicht das mehr Zuhörer hier probleme bereiten ... Und ja - die inhaltliche Zielsetzung ändert sich dadurch natürlich nicht. Aber mehr Zuhörer bzw bei Zielgerichteten Themen auch Mitredner aus der Community schadet uns alles nicht.
-
@jey-cee sagte in Core-Entwicklung zu schnell?:
Antwortet darauf das es doch gar nicht Komplex ist, aber er Arbeitet auch Ständig damit und hat es zum Teil mit entwickelt. Logisch das er das anders sieht.
Nur um das klar zu stellen: Hab ich nicht. Das war zumindest seit ich dabei bin schon immer so und ich habe es akzeptiert. Ich versuche lediglich, Dinge einfacher zu machen und zu zentralisieren:
- "neues" Testing ohne Kopie des kompletten Frameworks in jedem Adapter
- Einbindung des Controllers mittels adapter-core, anstatt Kopie des "wo ist controller?"-Codes in jedem Adapter
- Adapter creator
- Release Script
- Typdefinitionen, die dich anmeckern falls du die API falsch nutzt
-
@oliverio sagte in Core-Entwicklung zu schnell?:
Schau dir mal den Link hier an https://www.iobroker.net/#de/documentation (welche übrigens von https://iobroker.com/ aus überhaupt nicht verlinkt ist).
Öhh, www.iobroker.net ist die Startseite! Die verlinkt zur Doku:
iobroker.com kannte ich bis heute übrigens gar nicht
-
@alcalzone sagte in Core-Entwicklung zu schnell?:
iobroker.com kannte ich bis heute übrigens gar nicht
Das ist die Seite der GmbH und für kommerzielle Kunden.
Da sollte IMHO auch gar nichts zur Entwicklung zu sehen sein
