|
|
|
|
Ich habe ne kleine Frontendfrage.
Ich habe in Javascript folgende Funktionen
|
Code: |
function addToList(task) {
(result =) callServer("add", task);
//Hier wird der Response nicht verarbeitet.
}
function callServer(action, task = "", status = 0, id = null) {
let xhttp = new XMLHttpRequest();
xhttp.open("GET", "src.php?action="+ action +"&id=" + id + "&task=" + task + "&status=" + status, true);
xhttp.send();
xhttp.onreadystatechange = () => {
if (xhttp.readyState === 4) {
result = JSON.parse(xhttp.responseText);
// Hier wird Response nicht verarbeitet//
(return result;)
}
};
}
|
|
Der Response wird zwar innerhalb der CallServer Funktion ausgeführt, aber wenn ich diesen Code auslager auf meine AddToList Funktion, bekomme ich ein leeren Wert.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Lightspeed am 03.10.2019 12:44]
|
|
|
|
|
|
Weil die callServer Methode ja auch nix returned.
Entweder das promise returnen (gut) oder nen callback machen (nicht so schön).
// ich glaube, dass du das meinst.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von derSenner am 03.10.2019 17:41]
|
|
|
|
|
|
Das. Und überhaupt würde ich fetch jederzeit bevorzugen, weil viel einfacher. Dann ist das mit den Promises auch direkt eingebaut.
|
|
|
|
|
|
|
lel
.
Wobei man sogar für Promises nen PolyFill in IE braucht. Auch lel. Gottseidank mach ich das immer nur so nebenbei.
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von derSenner am 03.10.2019 21:30]
|
|
|
|
|
|
Okay, vielleicht habe ich das nicht deutlich genug dargestellt.
Ich habe folgende beiden Ansätze probiert.
|
Code: |
function addToList(parmas){
callServer();
}
function callServer(){
//// logic
result = response
}
|
|
|
Code: |
function addToList(parmas){
result = callServer();
}
function callServer(){
//// logic
return response
}
|
|
Innerhalb des untrigen Codes im callServer verarbeitet er den Response ja auch, nur will ich diese Funktion nicht unnötig aufblähen sondern in die returnte Funktion mein Code ausführen lassen.
|
Code: |
if (xhttp.readyState === 4) {
result = JSON.parse(xhttp.responseText);
// Logic
}
|
|
Fetch werde ich mir morgen mal genauer angucken. Danke!
|
|
|
|
|
|
|
Naja, ich mache das ja eigentlich gar nicht. Aber mal ehrlich, eine anständige Buildpipeline mit Webpack und hoffentlich Typescript* wäre der einzige Weg wie ich sowas inzwischen machen würde. Browserkompatibilität ist so eine völlige Shitshow, dass man sich nur absichtlich Schmerzen zuführt ohne Toolassistance.
* Selbst eine Codebase in reinem Javascript profiert von TSC, weil viele der statischen Checks auch auf untypisiertem Code funktionieren. Nie. Mehr. Ohne.
|
|
|
|
|
|
|
TypeScript ist ja auch Abfall. Und hau mir ab mit dem ganzen Babel und Browserify Zeug, da bekomm ich Schlaganfälle im Minutentakt . Hab ich erst letztens wieder versucht, ne sinnvolle Buildschain zu basteln. Hab ich ums verrecken nicht ordentlich konfiguriert bekommen. Ging schon irgendwie, aber nicht so, wie ich mir das vorstelle. Naja, eventuell war ich da zu blöd dafür.
Wenn es nicht um große, eigenständige Apps im Browser wie z.B. Slack geht - wo ich immer sage, hätten die das doch in einer ordentlichen Sprache gemacht - dann schreib ich nur noch "native" JavaScript. Weg mit Babel und ES2016, ES123 und React und schlagmichtot; weg mit jQuery, weg mit den ganzen tollen, hippen JS-Libraries, die jedes Halbjahr rotieren, alles kübeln. Mittlerweile hat man eine ordentliche Web-API, das funktioniert eigentlich alles recht gut und komfortabel. Dazu 'n 20kb Polyfill für den IE, ab geht's.
Wenn man dann noch IE außer acht lässt, was man mittlerweile durchaus vertreten kann, dann geht auch ES6 von Haus aus und das Leben wird schon interessanter.
Und dann kommt die alte IT der Firma X her, "ey LDAP und so, Active Direcctory, only IE bei uns". Tja.
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von derSenner am 03.10.2019 21:55]
|
|
|
|
|
|
Jau, und all diese Contraints haste halt im Alltag. Deswegen 1x in den Sauren Apfel beissen, ordentliches Buildsystem aufstellen und Profit auf beiden Seiten.
Aber meine Perspektive ist da halt auch genau diese Fullblown Apps. Ich baue die Buildsystem und bin für die Integration von Crossplattformlösungen zuständig. Der einzige Weg wie man das überhaupt noch hinkriegt - vor allem wenn man dann noch separate "Plattformen" wie Electron oder Cordova berücksichtigen muss - ist eine möglichst abstrakte Ebene über dem Browser. Genau das ist mit Webpack möglich. Natürlich ist das ein bedeutender Mehraufwand. Aber wenn über Jahre dutzende / hunderte Leute an Codebases rumpfuschen, man irgendwie noch Qualitätstracibility mit Sonar einbauen will etc. führt halt einfach kein Weg mehr darum, zusätzliche Schritte einzubauen.
Prinzipiell würde ich natürlich auch eine simplere Lösung bevorzugen, aber fuck that shit. Bei der JVM hat's ja auch nur etwa 20 Jahre gedauert bis die Sachen irgendwie benutzbar geworden sind, und das mit einer grösstenteils einheitlichen API.
¤: Und Typescript ist genau deswegen so genial (im Kontext, wohlverstanden), weil alles statisch ist. Zur Laufzeit ohne Debugbuilds hast du optimiertes Javascript, aber halt trotzdem die Möglichkeit berühmte JS Quirks zu umgehen. Zumal mit modernen Integrationen das Hinting in grösseren Codebases einfach Gold wert ist. Gute Typebeschreibungen für Libraries machen entwickeln soooo viel einfacher.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 03.10.2019 22:04]
|
|
|
|
|
|
|
|
|
|
Schön wär's, wenn das nur Frontend betreffen würde. Hauptsächlich kommt das ganze ja von Node. Was einerseits den Vorteil hat, dass man Libraries über Front- und Backend teilen kann. Gleichzeitig hat das den Nachteil, dass man Libraries über Front- und Backend teilen kann.
Ich finde das auch nicht geil, aber kann absolut verstehen warum es entstanden ist. Je weiter Software zum User geht (und damit Plattformabhängiger wird, in der Regel), desto Hurensohniger wird das ganze.
¤: Apropos, ich werde morgen oder eher am Wochenende noch was zu deinem Problem schreiben Oli, auch wenn es wahrscheinlich keine wirkliche Lösung ist.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 03.10.2019 22:21]
|
|
|
|
|
|
Wie nennt man denn eine Queue, die ich vom Main Thread befülle und jeder Worker thread arbeitet die Queue _für sich_ ab, also jeder Worker muss jeden Eintrag in der Queue bearbeiten. Ich will im main thread dann also eine Nachricht pushen, und jeder Worker soll die dann verarbeiten. Gibt's sowas? Alle "normalen" Queues sind immer irgendwie shared.
Im Moment finde ich nur, dass man pro Thread eine Queue erstellt und die dann reihum befüllt, was ich sehr unschön finde. Aber nunja.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 05.10.2019 9:23]
|
|
|
|
|
|
Hm, im Prinzip hast du da nur wenige Möglichkeiten:
- die Queue selber hat keine Persistenz dahinter, dann bist du bei "normalen" Message Bus Systemen. Aber wenn eine Nachricht mal verpasst wurde, ist sie halt weg.
- die Queue hat eine Persistenz, dann hat man mehr Optionen. Sowas wie Apache Kafka kann auch für einen gewissen Zeitraum für ein Topic ein Replay anbieten. Bei einfacheren Lösungen wie r. B. RabbitMQ kann man Nachrichten als in Verarbeitung kennzeichnen (Vorsicht, da geht dir dann die Parallelität flöten), oder eben auf Kommando löschen (der richtige Zeitpunkt ist manchmal schwierig zu entscheiden, oder automatisch per Timeout). Hier musst du auch gucken, ob du eine garantierte Reihenfolge der Nachrichten brauchst oder nicht, und (oft) mit deliver-AT-LEAST-once klarkommen.
Häufig ist so eine Queue dann aber auch nur ein fancy Interface für eine Datenbank.
|
|
|
|
|
|
|
Über dein Problem habe ich auch so noch ein wenig nachgedacht:
Mir ist keine gut funktionierende einfache dezentrale Lösung eingefallen. Den Wurm Ansatz finde ich spannend, aber fast unkontrollierbar.
Der Push-Ansatz der Kommandos funktioniert in meinem Kopf auch nur, wenn man sicher weiß, wer es denn überhaupt bekommen soll, und die sich anschließend zurück melden, wieder an einer zentralen Instanz. Das wirft dann wieder die Frage nach Retries usw. auf, aber da wirst du auch schon überall mal drüber nachgedacht haben.
Also das einfachste und schnellste was mir eingefallen ist, wäre irgendwie in alle Knoten per sshfs ein Filesystem des oder der Command-Server zu mounten. Dann bräuchte man immer noch auf allen Nodes ein Script, was dort periodisch nachguckt und quasi blind ausführt, was da so rumliegt (dem Admin wird gerade der Kaffee schlecht). Wenn zu viele Nodes es gleichzeitig versuchen und den Server wegbrezeln, mehrere gespiegelte (rsync?) Instanzen (eine pro Rack?) hinstellen. Grund des mountens ist nur der damit mögliche Rückkanal des Schreibens an zentraler Stelle und der Datei-Austausch ist fertig. Wenn das egal ist, kann man das bestimmt auch mit rsync Magic weit kommen (braucht vermutlich weniger Rechte als ein mount).
Alles darüber hinaus ist meiner Meinung nach kein Vorteil gegenüber den von dir erwähnten (langsameren) Tools.
|
|
|
|
|
|
|
| Zitat von Oli
Wie nennt man denn eine Queue, die ich vom Main Thread befülle und jeder Worker thread arbeitet die Queue _für sich_ ab, also jeder Worker muss jeden Eintrag in der Queue bearbeiten. Ich will im main thread dann also eine Nachricht pushen, und jeder Worker soll die dann verarbeiten. Gibt's sowas? Alle "normalen" Queues sind immer irgendwie shared.
Im Moment finde ich nur, dass man pro Thread eine Queue erstellt und die dann reihum befüllt, was ich sehr unschön finde. Aber nunja.
| |
Du kannst natürlich auch eine "Queue" nehmen, wo jedes Item einen Consume-Zähler hat, aber das wird Performance-mäßig sicherlich nicht besser, eher deutlich schlechter, sein als eine Queue pro Thread (sofern Performance hier überhaupt relevant ist).
|
|
|
|
|
|
|
Ich habe es jetzt mit einer Queue pro Thread gemacht.
@smith: Es sind alle nodes und die genaue Topologie vorher bekannt. Da wird nichts 'entdeckt' oder so.
Ich bastle gerade ein bisschen herum, nächste Woche teste ich meine Lösung mal und werde hier berichten.
|
|
|
|
|
|
|
| Zitat von Oli
Wie nennt man denn eine Queue, die ich vom Main Thread befülle und jeder Worker thread arbeitet die Queue _für sich_ ab, also jeder Worker muss jeden Eintrag in der Queue bearbeiten. Ich will im main thread dann also eine Nachricht pushen, und jeder Worker soll die dann verarbeiten. Gibt's sowas? Alle "normalen" Queues sind immer irgendwie shared.
Im Moment finde ich nur, dass man pro Thread eine Queue erstellt und die dann reihum befüllt, was ich sehr unschön finde. Aber nunja.
| |
Naja, warum dann wirklich nicht einfach eine schmale (InMemory?) Datenbank dafür nehmen? Ein Thread schreibt rein, viele Threads lesen. Gibt dir zumindest auch ein wenig Persistenz wenn mal was abraucht, neugestartet wird oder sich zurückmelden muss.
|
|
|
|
|
|
|
Smith, alle deine Vorschläge sind so krasse Kanonen auf meine kleinen Spatzenanforderungen
|
|
|
|
|
|
|
Alles klar, wir leben wohl wirklich in sehr unterschiedlichen Entwicklerwelten
Viel Erfolg dann!
|
|
|
|
|
|
|
Nein, ich freue mich, dass du drüber nachdenkst, aber ich glaube meine Anforderungen sind ein paar Dimensionen unter deinen
|
|
|
|
|
|
|
Es ist nichtmal gerne gesehen, dass ich Python statt bash benutze.
|
|
|
|
|
|
|
Wat? Ich glaube, ich würde kündigen.
NEIN DAS MUSS ALLES IN BASH PROGRAMMIERT WERDEN! DAMIT ES JA AUCH MÖGLICHST SCHLECHT MAINTAINED WERDEN KANN!
|
|
|
|
|
|
|
Es ist komplizierter. Hab ich hier nicht mal ein bisschen erzählt?
|
|
|
|
|
|
|
Ich glaube schon, es macht mich trotzdem mett
|
|
|
|
|
|
|
Kennt jemand eine coole Data-Science-/ML-/KI-Firma in Karlsruhe und Umgebung, die im Energie- oder Nachhaltigkeitssektor aktiv ist? Oder eine Firma in dem Bereich (außer der EnBW), die "KI" (hate me, bitchez) einsetzt?
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von homer is alive am 05.10.2019 21:45]
|
|
|
|
|
|
Ich habe auf einer Messe mal mit Leuten von denen hier https://www.ptvgroup.com/de/ aus Karlsruhe gesprochen. Das klang sehr interessant, die machen so Verkehrs-Agentensimulationen usw. Vielleicht setzen die auch inzwischen KI für irgendwas ein. Hätte ich dort einen Job gesucht, hätte ich da mal angerufen.
|
|
|
|
|
|
|
Was zur Hölle geht schief wenn ich substituiere? Alles endet in 0.
|
|
|
|
|
|
|
| Zitat von Wraith of Seth
Was zur Hölle geht schief wenn ich substituiere? Alles endet in 0.
| |
Solltest du nicht eher substituieren?
|
|
|
|
|
|
|
Schon, aber sollte das nicht egal sein?
|
|
|
|
|
|
|
Also, ist doch gar nicht hilfreich, wegen . Mit hast du dann eben und das sollte das richtige Ergebnis liefern.
|
|
|
|
|
|
|
¤dit: Nein, klappt immer noch nicht. Damn.
Du antwortest aber auch bei LaTeX-Fragen mit "das willst du aus typografischen Gründen eh nicht", oder?
Eigentlich erwarte ich, dass beide Substitutionen das gleiche liefern. Tun sie nicht. Warum?
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Wraith of Seth am 11.10.2019 4:05]
|
|
|
|
|
Thema: pOT-lnformatik, Mathematik, Physik XXII ( Jetzt nehmen uns Computer schon die Memes weg! ) |