Core-Entwicklung zu schnell?
-
@alcalzone sagte in Core-Entwicklung zu schnell?:
@oliverio Also zusammenfassend: es mangelt erheblich an der Doku. Trifft es das?
ja genau
-
@alcalzone sagte in Core-Entwicklung zu schnell?:
Also zusammenfassend: es mangelt erheblich an der Doku. Trifft es das?
Auch wenn es hier um die Dev-Doku geht, gilt das selbe analog auch für die User-Doku.
Und ich denke dass @Thomas-Braun diese meinte.Der Kernsatz war
@oliverio sagte in Core-Entwicklung zu schnell?:
Die Doku muss erster Anlaufpunkt für alle sein. Von dort aus kann gerne überall hin-verlinkt werden
und zwar für beide Dokus
-
Adapterchecker ...
Gutes Tool und ich denke auch die richtige Richtung. Travis ist gut. Automatisiert. Aber ich bin auch schon daran verzweifelt. Auch so eine Hürde. Ich bin wahrscheinlich der diletantestete Entwickler und sollte bei C+ bleiben. Ich finde es auf jeden Fall gut, dass man eine Selbstreflektion betreibt und hoffe, dass nur das Gute bleibt.Toll wäre auch ein Organigram der Core Entwickler und ein Ansprechpartner, wenn es um Adapter geht. Der könnte auch das Sprechrohr zu den Core Entwicklern sein.
-
@eisbaeeer
ich scheitere an der dependabot-integration in github
leider auch eine der unbeantworteten Fragen hier im Forum -
@eisbaeeer sagte in Core-Entwicklung zu schnell?:
Toll wäre auch ein Organigram der Core Entwickler und ein Ansprechpartner, wenn es um Adapter geht. Der könnte auch das Sprechrohr zu den Core Entwicklern sein.
Hm ... Organigram ... ich versuchs mal: Bluefox, Apollon77, AlCalzone, foxriver76 (gleichberechtigt mit nem kleinen Project owner Bonus für Bluefox); Admin- und andere FE Adapter: Bluefox
Ansprechpartner: GitHub Issues oder jeder von uns; ich denke indirekt landet das meiste am Ende bei mir momentan
Ansprechpartenr "Support": Die Entwickler Community Gruppen in Discord, telegram und Forum ... weil die Community Intelligenz ist besser als ne einzelne.Ich denke auch das es kein "Sprachrohr" braucht ... Lasst uns zusammenarbeiten. Dann kommt das beste raus.
-
@oliverio Auch wenn offtopic: Link? Wir haben weit über hundert Adater mit dependabot ... wäre ja gelacht
-
Hallo alle miteinander und vielen Dank für Eure Beiträge, Infos und Meinungen bisher.
Ich werde nicht alles kommentieren, sonst säße ich ja morgen früh noch und ist auch an vielen Stellen gar nicht nötig. Zu ein paar Dingen möchte ich aber gern meine Meinung sagen. Wird fürchte ich ein bissl länger und ob der Zeit auch definitiv nicht Schreibfehlerfrei - schon mal Sorry dafür.
Generell habe ich das Gefühl das wir manchmal zu sehr im "meckern" verweilen und gar nicht die Veränderungen bzw. an vielen Stellen Verbesserungen der letzten 2-3 Jahre sehen. Bis vor 3 Jahren war der js-controller und alles in Core weitestgehend eine One-Man-Show. Seit Mitte 2018 mischen auch weitere Entwickler am js-controller mit und hier versuchen wir die Kommunikation und viele Dinge zu verbessern. Das geht aber nicht von heute auf morgen sondern braucht Zeit, da wir das ALLE als Hobby machen (inklusive Bluefox bisher!).
Kommunikation
Seit Controller 1.5 in 2018 werden js-controller Releases geplant und von mir versucht bestmöglich zu organisieren und zu betreuen. Das war meine Form zu versuchen besser und transparenter zu kommunizieren.
Mit der Zeit kam zuerst Telegram als Kommunikationschannel zum Forum hinzu und später Discord. Seit Mitte 2020 gibt es die Developer-Meetings, wo oft frühe Einblicke in kommende Dinge gegeben werden. Eine Verbesserung in der Kommunikation - auch weil es Protokolle gibt. Dort wurden z.B. früh die Deprecations im Controller 3.3 angekündigt und auch dort hat niemand erwartet was dann beim Beta Release passiert ist. Wir haben sogar gemeinsam die Chance verpasst: Viele Entwickler haben nach Info im Meeting (sorry, facts) auch nicht die Chance genutzt Ihre Adapter, wie gebeten, vor dem Alpha Release in die Community mal zu testen. Als ich gefragt habe wer gecheckt hat gabs nur betretenes Schweigen ...
Ich bin ehrlich, dass ich manchmal nicht mehr weiss was ich noch auf welche Art und wie kommunizieren soll das es gelesen und auch beachtet wird oder Feedback kommt. Sagt mir gern (vllt direkt als PN) was ich anders tun kann. Neben Controller habe ich auch in Absprache mit Bluefox bei vielen anderen Adaptern versucht die Kommunikation sinnbringend zu machen im Forum und auch vorab - Admin 5 als Beispiel.
... am Ende bringt die beste Kommunikation nichts die nicht "ankommt" und bei Kommunikation ist es ja DAS was zählt ...Wir versuchen hier ebenfalls über automatisch generierte Issues alle Adapter-Entwickler zu Neuerungen zu erreichen - zuletzt in größerem Stil bei js-controller 3.3 und Node.js 14/16 passiert. Wir können hier nur Versuchen den Ball zuzuwerfen - aufnehmen muss Ihn schon der Entwickler selbst.
Ansonsten ist es inzwischen aber auch eine Herausforderung alle Kommunikationskanäle im Blick zu haben und ich persönlich versage dabei wenn ich nicht getaggt werde leider oft. In den meisten Fällen gibt es dann aber andere Entwickler die die Infos haben oder ggf. dann jemanden kennen/taggen der helfen kann. Zusammenarbeit ist Key.
Entwickler-Tooling
Es ist Wahnsinn was - vor allem im letzten Jahr - an Community-Initiativen und -Tools entstanden ist. Wir sind auf einem guten Weg und das sollten wir auch bewusst sagen und "feiern"!
Einige der Posts gehen noch auf Adapter zurück die das aktuelle Tooling nicht kennen bzw nutzen und ja - ohne das man sich selbst informiert sieht man das nicht. Wie gesagt - es hat sich einiges getan in den letzten 1-2 Jahren. Ein Release ist mit einem Shell Befehl heutzutage getan was früher mehrere manuelle Schritte waren
Auch der Dev-Server für die Entwicklung ist ein großer Fortschritt!
Für diese (komplett optionalen Dinge) erzeugen wir keine Massen-Issues auf GitHub und ja es kostet initial Zeit um danach Zeit zu sparen.Dokumentation
Auch dies ist ein Dauerbrenner seit 3+ Jahren und ich bin sehr froh das sich vor ein paar Wochen @UncleSamSwis das Thema genommen hat und jetzt mit einem Team als Community-Initiative treibt. Das ist einfach ein ganzes Haufen Holz was da in eine sinnvolle Form gebracht werden will und bisher hat dies zeitlich niemand hinbekommen. Umso dankbarer bin ich dem neuen Dev-Doku-Team.
Nachdem es steht werden wir sicherlich sinnvolle Prozesse finden das es auch wirklich aktuell bleibt - und hier bitte ich gleich das JEDER aus der Adapter-Dev-Community hier in Zukunft mithelfen sollte. Ohne Feedback und PRs für Fehler, fehlende oder unklare Themen diskutieren wir in 2 Jahren immer noch warum denn die Doku jetzt zentralisiert aber immer noch "blöd" ist
(was sehr frustrierend für die Devs wäre die sich dem Thema jetzt initial annehmen).Core-Entwicklungsprozess
Mir scheint das hier falsche Ansichten bzw. auch Erwartungen vorherrschen. Generell ist der ioBroker Entwicklungsstil eher agil und iterativ geworden - was Adapter angeht und auch was Core-Features angeht. Auch hier gilt: jemand hat eine Idee, diskutiert diese mit ausgewählten Entwicklern, dann wird Sie ggf. justiert und dann verworfen oder kommt auf den Plan in eins der Projekte - und derjenige oder ein anderer der Core-Devs implementiert die dann meistens auch. Das ganze im Normalfall via GitHub Issues. Oder ein erster Schritt wird gebaut, sodass man dann weitersehen kann was als nächstes Sinn macht und was wie gut von den Entwicklern und Usern angenommen wird. Ist damit ein Thema zu 100% "bis ins letzte Detail zu Ende gedacht"? Nein. Ist das das Ziel? Nein. Dennoch versuchen wir unser bestes keine losen Enden zu haben und uns für die Zukunft nichts zu verbauen. Das kostet viel Zeit das so zu durchdenken.
Wir haben bei mehreren Themen versucht mal frühe Diskussionen in größerer Runde zu führen ... Das Ergebnis war meistens das sich diese Diskussionen nie auf "das Ziel" fokussiert haben sondern immer in alle möglichen Sonderfälle und Kleinkram verstrickt haben. Am Ende steht der Entwickler mit einem Wunschkatalog da der das Feature aufbläht und er sich danach rechtfertigen muß wenn er genannte Wünsche nicht umgesetzt.
Auch hier gilt: Wir machen das als Hobby und das sollten wir alle bitte nicht vergessen wenn wir "Forderungen" an die Core-Entwicklung erheben.Bei allen größeren Themen haben wir in jedem Fall einen Plan ... der ist aber meist sehr langfristig angelegt und das ist auch gut so.
Bei allen Änderungen ist immer mindestens ein zweiter Entwickler da der den PR reviewt und auch hier wird kräftig diskutiert und die Risiken der Änderungen betrachtet. Wir machen beim Controller nichts leichtfertig.
Gleiches gilt aktuell für die Frontend-lastigen Adapter. Wir haben keinen UXer, keinen Grafiker, keinen Designer und sehr wenige Frontend-Entwickler. Die würden sich über Anforderungen freuen ... aber Sie müssen sich sich selbst ausdenken. Also tun Sie das nach bestem Wissen und Gewissen - und ja die persönliche Handschrift ist dann sichtbar. Feedback kann per GitHub kommen und dann entscheidet der Entwickler was er damit macht - wie jeder von Euch bei seinen Adapter auch! Warum sollte das denn hier anders sein?
@jey-cee sagte in Core-Entwicklung zu schnell?:
das andere sind Funktionen die eigentlich ein Zentraler Bestandteil sein sollten, müssen vom Adapter Entwickler selber gebaut werden. Mal so ein Beispiel: Das löschen von Objekten mit samt darunter liegenden Objekten. Gibt es diese Funktion mittlerweile?
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 ... es wurde irgendwie in nem Thread im Forum angesprochen das es fehlt und immer wieder Aufwände macht und Bluefox hat dann ein GitHub-Issue angelegt und in der nächsten Controller Version war es drin. Mal abgesehen vom "Umweg" über Bluefox ist das so gelaufen wie es sollte. Ich bin dagegen das die Core-Devs erraten was so alles gebraucht werden könnte, sondern das die Entwickler einfach Ihre Schmerzpunkte melden und wir schauen dann was wir tun können (oder es kommt gleich ein PR). That's the way to go!
"Nötige" Adapteranpassungen
@jey-cee sagte in Core-Entwicklung zu schnell?:
Es gibt doch gar keine Garantie dafür das man Sauber Arbeitet (siehe Konsistenz & Rückwärts-Kompatibilität). Und Rückblickend betrachtet gibt es keinen Grund an zu nehmen das nicht Plötzlich Themen auf der Agenda stehen, die Anpassungsarbeit erfordern. Klar ein Break in form von Admin 2 auf 3 ist selten, im Idealfall passiert das nie.
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 ...
Im Gegensatz zu den anderen oben genannten echt Breaking Fällen haben wir im Controller noch nichts relevantes wirklich ge-breaked und irgendwie kommt es mir immer unwahrscheinlicher vor das wir das jemals tun können ohne gewisse Adapter zu verlieren oder es selbst anpassen zu müssen. Wenn wir es gebreaked hätten, dann gäb es jetzt immer noch keinen js-controller 3.
Ein anderes Beispiel ist Admin 5 der jetzt übrigens neben JSONConfig (ausser für den Custom teil) immer noch die Konfig-UIs von Admin <=2, 3 und 4/5 unterstützt. Glaubt jemand das das jemals raus kann?
Aber kann denn das unser gemeinsames Ziel sein das wir solchen Technical Dept sammeln?Fazit
Am Ende sehe ich das wir alle das gleiche wollen: Ein gut dokumentiertes System was Spass macht und es "einfach" macht nen coolen Adapter zu entwickeln. Wenn jetzt jeder ein bissl über den Tellerrand schaut und auch schaut was andere tun müssen dafür und wo man am gleichen Strang ziehen sollte und sich gegenseitig helfen sollte/muss dann erreichen wir das gemeinsam auch. Aber es ist ein Weg - wir haben Ihn vor 2,5 Jahren begonnen und sind noch lange nicht am Ende ... ja es wird auf dem Weg noch ein paar Stolperstellen geben und auch mal wehtun. Zusammenarbeit hat uns schon dahin gebracht wo wir jetzt sind ... und bestimmt noch viel weiter
Gute Nacht (bzw. guten morgen, je nachdem wann Ihr es lest)
Ingo
-
@mickym mqtt ist seit Admin 5.2.1 mit erlaubt --> https://github.com/ioBroker/ioBroker.admin#521-2021-11-28
-
@apollon77 sagte in Core-Entwicklung zu schnell?:
@oliverio Auch wenn offtopic: Link? Wir haben weit über hundert Adater mit dependabot ... wäre ja gelacht
Feel free
https://forum.iobroker.net/topic/47468/dependabot-fehler-beim-automerge?_=1640650588063Wie ich gerade gesehen habe gab es tatsächlich eine Antwort, aber es war schon alles so angepasst wie in dem link vorgeschlagenen
-
@apollon77 sagte in Core-Entwicklung zu schnell?:
@mickym mqtt ist seit Admin 5.2.1 mit erlaubt --> https://github.com/ioBroker/ioBroker.admin#521-2021-11-28
Es ist zwar mehr erlaubt - als vorher, aber leider wird das nie den Ansprüchen genügen, weil sich mqtt nicht in das vorgegebene Schema pressen lässt. Ich kann die Hierarchie nicht an beliebigen Datenpunkten erweitern, Ordner sind anscheinend auf die 1. Ebene beschränkt. Im MQTT kann jede Ebene auch states enthalten - also auch Datenpunkte topics die Kinder haben und die keine Geräte oder Devices sind. Diese Struktur passt halt einfach nicht, weil sie Beschränkungen auferlegt, die es im Original nicht gibt (mqtt).
Auch unter userdata, das keinem Adapter gehört sind diese Beschränkungen nur lästig ohne irgendeinen Mehrwert. zumindest keinen den ich sehe.
Wie gesagt exportiere mal einen Teil von userdata oder irgendeinen anderen Ast mit dem mqtt-Adapter und reimportiere ihn wieder, das Protokoll ist so schnell rot und die states kaputt - das ich froh war, dass ich über die Objekte und States das schnell wieder herstellen konnte.
Das Prinzip dieser Hierachie und den Einschränkungen mit Ordners, Geräten usw. passt halt in meinen Augen nicht und die einzige brauchbare Lösung ist zumindest für bestimmte Namensräumen (userdata und mqtt), diese von den Prüfungen und der Struktur auszunehmen.
Mit dem Admin 5.2.1 hat man zwar etwas Abhilfe geschaffen, aber ist immer noch viel zu eingeschränkt.
Einen Datenpunkt unter ...relay.0 kann ich trotzdem nicht erstellen, weil es ja nicht mehr erlaubt ist unter states eine weitere Hierarchie zu erstellen. Das ist aber essentiell und wird nie in das nun eingeführte Schema passen.
Wie gesagt in meinen Augen gibt es sowohl für userdata, als auch für mqtt nur eine Lösung, nämlich für diese Namensräume die Regeln ausser Kraft zu setzen. Nun klar kann man der Meinung sein, warum muss iobroker ein mqtt Frontend sein, aber ist halt schade, dass man aufgrund von Prinzipien auf in meinen Augen wertvolle Funktionalität verzichten will.
Der Zwang auf jeder Ebene Objekte bzw, es keine generischen Objekte gibt für alle Namensräume festzulegen, ist in meinen Augen etwas was die Flexibilität des Systems unnötig einschränkt. Das kann man für Adapter machen, man kann auch Adapterklassen festlegen - aber es gibt meines Erachtens Namensräume, wo jegliche Prüfungen nur hinderlich und unnötig sind. Zumindest erkenne ich als Anwender bislang nicht den geringsten Mehrwert darin.
-
@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 ...
-
@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.
