Von kamome umidori am Do, 12. September 2019 um 14:49 #
> responsiv […], also … > widerstandsfähig […], wofür … > elastisch […], was bedeutet … > ereignisgesteuert, asynchron
Das Reactive-Bullshit-Bingo kann man doch abkürzen: Hochverfügbare, selbst-skalierende Echtzeitanwendung. Gute Sache, aber gibt es jetzt auch nicht erst seit gestern / seit reactive …
Von Echtzeit kann hier keine Rede sein. Für GUIs ist es nicht kritisch, wenn sie mal etwas länger brauchen. Allenfalls sehe ich hier eine "sehr weiche" Echtzeitanforderung.
Von kamome umidori am Do, 12. September 2019 um 20:48 #
„Weich“ sicher (im Sinne von nicht durch Hardware garantiert), und sicher nicht so kritisch wie manche Industrieanlage. Aber „Echtzeit“ heißt ja nicht unbedingt „sofort“, sondern meist „mit garantierter Antwortzeit“ (und die kann ja je nach Anwendungsfall ganz unterschiedlich ausfallen – z.B. 16 ms).
> widerstandsfähig […], wofür … > Wobei ich widerständsfähig durch resilient design ersetzt hätte. Und wenns schon ein Industriekonsortium ist, hätten sie wenigstens was von Industrie 4.0 oder besser Industrie 5.0 faseln können. Außerdem hätte ich betont, das das Ganze mit Hilfe von agilen Methoden implementiert wird.
Spielt aber alles keine Rolle. Im Text kommt weder das Stichwort Blockchain noch KI (oder wenigstens deep-learning) vor. Damit sehe ich für das Projekt ohnehin keine Zukunft.
Vorweg: Bisher habe ich noch nie eine raktive Bibliothek für das Model-Statemanagement einer Applikation eingesetzt.
Es geht vor allem darum, mit sich gegenseitig beinflussenden Eigenschaften und Regeln konsistent klarzukommen - auch asynchron temporal. Dafür wurde das Schema der funktionalen reaktiven Programmierung geschaffen. Ein Modul, das die Logik unabhängig von den konsumierenden (Gui-)Komponenten hält. Es gibt eine Menge von Variablen (=Store), die einen Zustand bilden und Transformationen derer mit weiteren Dingen (Observables, ...).
Meist wird reactive Programming für recht große Applikationen benutzt. Für "normale" Projekte gelten viele solche Bibliotheken als Overkill. Konkret eingesetzt wird das z.B. bei Single Page Applikationen (z.B. RxJS), aber es gibt auch genug Beispiele außerhalb der Javascriptwelt. Auch das Spring-Ökosystem ab Version 5 hält sowas bereit.
Die meisten Videos zu dem Thema haben eine Länge von mehr als einer Stunde Hier wird sich aber kürzer gefasst: https://www.youtube.com/watch?v=Bme_RiT9CK4
Hier noch etwas von Red Hat (mehrteilig) https://www.youtube.com/watch?v=o-cBfanMJ8A
Zuerst formuliert wurde es wohl von Erik Meijer, der bei Microsoft (den Erfindern von XML und Typescript) angestellt ist https://vimeo.com/222484804
> responsiv […], also …
> widerstandsfähig […], wofür …
> elastisch […], was bedeutet …
> ereignisgesteuert, asynchron
Das Reactive-Bullshit-Bingo kann man doch abkürzen:
Hochverfügbare, selbst-skalierende Echtzeitanwendung. Gute Sache, aber gibt es jetzt auch nicht erst seit gestern / seit reactive …
Von Echtzeit kann hier keine Rede sein. Für GUIs ist es nicht kritisch, wenn sie mal etwas länger brauchen. Allenfalls sehe ich hier eine "sehr weiche" Echtzeitanforderung.
„Weich“ sicher (im Sinne von nicht durch Hardware garantiert), und sicher nicht so kritisch wie manche Industrieanlage. Aber „Echtzeit“ heißt ja nicht unbedingt „sofort“, sondern meist „mit garantierter Antwortzeit“ (und die kann ja je nach Anwendungsfall ganz unterschiedlich ausfallen – z.B. 16 ms).
"Bullshit Bingo" war auch mein erster Gedanke - nicht, weil ich vom Thema große Ahnung hätte, sondern wegen der Ansammlung von Modewörtern.
> widerstandsfähig […], wofür …
>
Wobei ich widerständsfähig durch resilient design ersetzt hätte.
Und wenns schon ein Industriekonsortium ist, hätten sie wenigstens was von Industrie 4.0 oder besser Industrie 5.0 faseln können.
Außerdem hätte ich betont, das das Ganze mit Hilfe von agilen Methoden implementiert wird.
Spielt aber alles keine Rolle. Im Text kommt weder das Stichwort Blockchain noch KI (oder wenigstens deep-learning) vor. Damit sehe ich für das Projekt ohnehin keine Zukunft.
Für mich klingt das Projekt dagegen ganz erfolgversprechend Nur die Beschreibung würde ich mir etwas weniger „kreativ“ wünschen – aber was soll’s!
Vorweg:
Bisher habe ich noch nie eine raktive Bibliothek für das Model-Statemanagement einer Applikation eingesetzt.
Es geht vor allem darum, mit sich gegenseitig beinflussenden Eigenschaften und Regeln konsistent klarzukommen - auch asynchron temporal. Dafür wurde das Schema der funktionalen reaktiven Programmierung geschaffen. Ein Modul, das die Logik unabhängig von den konsumierenden (Gui-)Komponenten hält. Es gibt eine Menge von Variablen (=Store), die einen Zustand bilden und Transformationen derer mit weiteren Dingen (Observables, ...).
Meist wird reactive Programming für recht große Applikationen benutzt. Für "normale" Projekte gelten viele solche Bibliotheken als Overkill. Konkret eingesetzt wird das z.B. bei Single Page Applikationen (z.B. RxJS), aber es gibt auch genug Beispiele außerhalb der Javascriptwelt. Auch das Spring-Ökosystem ab Version 5 hält sowas bereit.
Die meisten Videos zu dem Thema haben eine Länge von mehr als einer Stunde
Hier wird sich aber kürzer gefasst:
https://www.youtube.com/watch?v=Bme_RiT9CK4
Hier noch etwas von Red Hat (mehrteilig)
https://www.youtube.com/watch?v=o-cBfanMJ8A
Zuerst formuliert wurde es wohl von Erik Meijer, der bei Microsoft (den Erfindern von XML und Typescript) angestellt ist
https://vimeo.com/222484804
Vielen Dank für den ersten Link!