IRC Logs for #zfx


2022-06-15

05:17:48 Schrompf joined the channel
05:43:08 Schrompf: Gmöndbötter, verehrte Grönnel
06:36:05 xq: moin moin
06:53:43 Magister joined the channel
07:08:31 Magister: moin
07:31:01 Schrompf: hi
07:31:06 Schrompf: (bissl spät, ich weiß)
08:29:45 xq: und, was geht bei euch so?
09:02:35 Schrompf: mäh
10:25:11 joeydee joined the channel
10:25:15 joeydee: moin
10:33:56 Schrompf: hi
10:34:06 Schrompf: wo waren SIE gestern abend? hm? HM?
10:42:48 joeydee: Öhm
10:42:55 joeydee: Ääh
10:43:39 joeydee: Ich kann alles erklären.
10:46:02 joeydee: Zu müde, zu faul, aktuell zu wenig mit passenden Themen am Hut.
10:46:07 Schrompf: hm
10:46:14 Schrompf: das klingt leider ziemlich verständlich
10:46:46 Schrompf: scheichs war da, tilman / sternmull war da, und Hannes. Hab mit tilman über Agile und Scrum und so geschwatzt
10:46:58 xq: und? agiles gespräch?
10:47:05 joeydee: Ich habe seit Weentown eigentlich gar nix mehr gemacht.
10:47:12 Schrompf: dann kam antisteo rein, aber unter irgendnem anderen namen, und hat nochmal von seinen jit-optimierungs-ideen erzählt
10:48:02 Schrompf: klassischer antisteo: sehr viel selbstvertrauen, aber hat auch auf nachfrage nicht wirklich erklären können, wo die magie sein soll, dass die großen brauserhersteller dann diese tech von ihm lizenzieren wollen könnten
10:48:26 Schrompf: und dann haben wir ein bissl über krieg und ukraine und das leben damit gejammert
10:48:35 Schrompf: und ich hab nochmal werbung für Horizon Zero Dawn gemacht
10:49:02 Schrompf: und es wurde angeregt, für nächsten monat mal ne umfrage zu machen, welcher wochentag denn den meisten liegen würde
10:51:29 joeydee: Ich hab jetzt ne Beta-Invite für Midjourney (Noch so ein aktueller AI-Kunstbildgenerator). Aber noch nicht viel gemacht. Läuft über Discord, man tippt was in den Channel und 4 Bilder zum Prompt werden nach ca. 60 Sek. gepostet.
10:51:44 joeydee: Das öffentliche Testen finde ich doof.
10:52:31 Schrompf: "celebrity naked"
10:52:48 joeydee: imagine: frogs having sex with a naked hamster, in the style of rubens, hig detail
10:52:54 joeydee: Ups, falscher Thread.
10:52:57 Schrompf: :-)
10:53:29 joeydee: aber die Dinger sind schon echt gut geworden.
10:53:36 Schrompf: "Batman scrubbing MadMax car with squirrel"
10:54:09 Schrompf: hab den usecase nie so richtig verstanden. das ist doch ein reines "weil's geht"-ding, oder?
10:54:20 Schrompf: manche erzeugen concept art damit, und malen dann drüber
10:54:22 Schrompf: ok
10:54:29 Schrompf: aber das ist doch kein bussiness case
10:55:19 xq: ich glaube für concept art ist das relativ geil, weil man halt eine szene verbal beschreibt und dann zusätzlich noch input von der KI/Rng bekommt
10:56:03 joeydee: Ich denke, die trainieren die Netzte damit auch weiter. Was runtergeladen oder weiterverwurstet wird, ist "gut", die Vorschau die nicht angeklickt wird, ist "schlecht".
10:56:30 Schrompf: ja, ist jedenfalls ein kleiner feedback-kanal, den man mit anzapfen kann
10:56:49 Schrompf: ist zwar auch reichlich mehrdeutig, weil es tausend gründe haben kann, warum die userin das bild dann nicht anklickt
10:57:16 Schrompf: aber wenn du ML machst, lebst du ja eh damit, dass das ergebnis von tausend unwägbaren details abhängt und nachher primär deine unbewussten vorurteile repliziert
10:58:13 Schrompf: und das vermute ich, würde auch passieren, wenn meinetwegen fünf große game studios das für concept art benutzen: die kriegen bei gleichem input halt nahezu gleichen output, und irgendwann wird es deswegen als tool nutzlos
11:00:04 joeydee: Bei Midjourney weiß ich es nicht, aber du kannst bei den neueren an vielen Parametern schrauben, und auch ein generiertes Bild als Input für die nächste Trial-Runde nehmen. Also das verzweigt sich doch reichlich bei gleichem Thema.
11:01:07 Schrompf: hm, ok. vielleicht bin ich doch nur verbittert
11:01:51 joeydee: Im Prinzip imitieren die ja nur Vorhandenes. Wenn in wenigen Jahren das Netz voll mit AI-Kust ist, imitieren die sich irgendwann selbst ...
11:01:59 joeydee: Kunst
11:02:45 Schrompf: ja, vermute ich auch. das meinte ich, wenn auch reichlich diffus: wenn's alle nehmen, verliert es irgendwann seine selbständigkeit und damit teilweise seinen nutzen
11:02:51 Schrompf: als "kunst" ja sowieso
11:03:09 joeydee: Ich denke halt, die sind irgendwann so weit, dass du deinen eigenen Game-Content damit machst.
11:03:29 Schrompf: womöglich. daran zweifle ich
11:04:31 Schrompf: bislang sind die bilder primär wegen "wow, das geht" so bemerkenswert. aber die details sind immer verwaschen, verzogen, lokal einfach nur weird. du müsstest *alles* kontinuierlich perfekt kriegen, damit es benutzbar wäre
11:05:12 joeydee: Die bisherigen, ja. Die neuen Engines werden da gerade besser drin.
11:05:24 Schrompf: dieses GTA mit nem GAN auf "real" gerechnet ist ja am selben problem gescheitert. handverlesene Standbilder sahen großartig aus, in der bewegung hast du fiese verzerrungen, seltsame effekte wandern durchs bild
11:09:16 joeydee: Das meine ich aber nicht mit dem Einsatz einer KI.
11:13:08 joeydee: Z.B. lässt du dir ein Concept für nen Char machen, erstmal vage "big guy with a weapon".
11:14:04 joeydee: Da wird irgendwas generiert, ist noch nicht dein Thema (weil nicht angegeben), aber die Pose im 3. Vorschlag gefällt dir. Dann "V3, but with medieval character, bigger guy".
11:14:10 joeydee: Und das wird verstanden.
11:15:00 Schrompf: "meine diffuse kritik von vorhin, aber genauer"
11:17:36 joeydee: Du kannst da halt in Revision gehen wie mit einem Konzeptkünstler.
11:17:46 Schrompf: joa, das ist praktisch
11:17:59 Schrompf: mein einwand bezog sich auf dein "irgendwann erstellst du allen content damit"
11:18:21 joeydee: Und ich denke die sind nicht weit davon entfernt, "und jetzt mach mir ein rigbares Charakter-Modell daraus, hochdetailliert, mit allen Maps."
11:18:41 joeydee: Sind letztendlich auch nur "Daten mit Kontext zueinander".
11:19:08 Schrompf: und ich behaupte, dass das nichtmal für "felswand auf Wiese" funktioniert, geschweige denn für stadt oder mensch oder sechsbeinkäferkrallenmonster. das klappt nur, weil der grafikstil bisher halt bewusst wischiwaschi ist und lokale unstetigkeiten keinen stören
11:19:23 Schrompf: naja, wer weiß
11:19:29 Schrompf: vielleicht ist in zukunft auch alles wurscht
11:19:37 xq: Schrompf: hast du mal dall-e 2 gesehen?
11:19:45 Schrompf: ja, von denen rede ich
11:19:56 xq: okay
11:19:57 joeydee: Bei WomboArt wurden nur Bildschnipsel vermisch, mehr oder weniger. Midjourney u.a. scheint aber "dieses Ding ist was anderes als das restliche Bild" sowie Tiefe zu "können".
11:20:18 Schrompf: feinfein. schaumermal
11:20:36 joeydee: ich spiel gerade mal mit deinem Batman-Prompt von oben.
11:22:12 joeydee: In einem hast du recht: Gesichter (zumindest Personen in einem größeren Kontext im Bild) sind bis jetzt noch sehr "uncanny" und verzogen. aber auch nur eine Frage des Lernens. Portraits funktionieren glaube ich schon ganz gut.
11:23:04 xq: schick mal die ergebnisse rum
11:27:24 Schrompf: ja das fände ich auch spannend
11:35:32 joeydee: Die sind natürlich wischiwaschi, liegt auch am (unveränderten) Prompt, aber alles bereits deutlich besser als mit Wombo Dream. https://www.phoximages.de/uploads/2022/06/i70147bzunp1.jpg
11:36:23 joeydee: (hab ihn bei der weiteren Auswahl auf Comic-Style forciert)
11:37:13 Schrompf: das hier wurde mir gerade in die zeitlinie gespült
11:38:02 Schrompf: das ist schon geil :-) immer noch zweifle ich, dass das irgendwie nützlich ist, aber ich schaue es gerne an
11:38:23 Schrompf: äh
11:38:33 Schrompf: "das hier wurde mir gerade in die zeitlinie gespült: https://twitter.com/Gaxil/status/1536843305241219074?s=20&t=BDNKw-P-ZHg8uAhKRiOGYw"
11:45:20 joeydee: Wie gesagt, ich denke es ist kein allzu großer Schritt mehr, da passende 3D-Modelle generieren zu können. Vielleicht 2-3 Jahre max., wenn der Boom anhält.
11:45:37 xq: Schrompf: EmberGen, created by JangaFX, written in Odin?
11:45:41 Schrompf: ja, schaumermal
11:46:15 xq: joeydee: wunderbar absurde bilder :D
11:46:43 joeydee: Ich bin da ja auch nicht *zu* euphorisch, aber die Richtung, in welche sich die Tools in den letzten beiden Jahren entwickelt haben, geht halt dorthin.
11:46:51 joeydee: Manche "können" schon Filme.
11:47:28 Schrompf: feinfein. schaumermal
11:52:57 joeydee: Disco Diffusion lässt sich ziemlich weit parametrisieren, glaube ich. Habe aber noch nicht tief reingeschaut.
12:06:41 joeydee: Cyberpunk Fairy: https://www.phoximages.de/uploads/2022/06/i70148bxqtu3.jpg
12:10:06 joeydee: Cyberpunk alley with restaurants: https://www.phoximages.de/uploads/2022/06/i70149butouq.jpg
12:10:56 xq: "Wolf riding mechanical dinosaur at the sea"
12:12:10 Schrompf: die alley sieht sehr geil aus
12:13:57 joeydee: Und anders als bei der letzten Generation von AI-Kunst stimmt der Kontext der Bildteile untereinander schon besser.
12:16:08 IceMichael: moin
12:23:36 Schrompf: Moinchael
12:25:59 joeydee: hi
12:26:57 IceMichael: und, wie geht's euch?
12:31:27 Schrompf: scheiße
12:31:37 Schrompf: müde, genervt, dauer-abgelenkt
12:32:11 Schrompf: da guckt man einmal für ne abnahme eines tickets ganz genau in die logs. findet eine komische stelle. steigt dem nach. forscht im code. berät sich mit kolleg:innen
12:32:41 Schrompf: und dann stellt sich heraus: am montag hab ich was released, was ein anderes feature mittelbar kaputt macht
12:32:54 Schrompf: und das obendrauf auf die drei tickets, die ich eh gerade jongliere
12:33:00 Schrompf: mein hirn ist matsche
12:33:03 xq: shit
12:33:28 Schrompf: micro services my ass
12:33:50 Schrompf: sorgt eigentlich nur dafür, dass du jede menge impliziter abhängigkeiten und emergenter timingabhängiger effekte hast
12:41:08 IceMichael: klingt kacke :/
12:41:16 IceMichael: und, als wäre eure microservice-Architektur nicht gut
12:42:38 IceMichael: im Speziellen, dass die evtl. zu klein sind
12:42:59 IceMichael: und wieso catcht kein Test, dass was breaked?
12:43:11 IceMichael: (in der Firma sind wir auch sehr schlecht mit der Architektur, mir wird das nur immer klarer, lese gerade viel)
12:44:08 Schrompf: da breaked ja nichts. läuft im gegenteil alles wie geplant. die planung hatte halt was übersehen
12:44:31 IceMichael: du meintest ja, dein Release macht ein Feature kaputt?
12:45:16 Schrompf: ja, tut es. es gibt ne "ich kann dir gerade keine Ressourcen geben"-Antwort. Die wird verwendet, um alle möglichen Verbindungsabbrüche zu filtern, wenn eine Komponente neugestartet wird
12:46:06 Schrompf: Leider entsteht die auch, wenn in einem anderen Feature eine Engine die Füße stillhält, weil sie auf einem der fetten Importserver läuft und keinen Load verursachen soll, solange der Server seiner eigentlichen Aufgabe nachgeht
12:47:00 Schrompf: Importserver importiert was, Engine darauf merkt das und fährt ihr Ressourcen-Angebot runter, anfragender Server hält das für nen Shutdown und klinkt sich aus
12:47:21 Schrompf: 10s später hat er sich wieder eingeklinkt, aber da waren halt alle Requests im Flug schon verworfen
12:48:12 Schrompf: jedes einzelfeature hat funktioniert, wie's soll. die kommunikation war halt nicht eindeutig, aber das weißt du halt erst nachher
12:48:58 Schrompf: nuja, heimwärts. heute wird kacke geschaufelt im schrebergarten. einmal pro jahr ist das auch nötig
12:49:00 xq: mit was reden die services untereinander?
12:49:12 Schrompf: protobuf über TCP aktuell, GRPC ist in arbeit
12:49:32 xq: okay, also sehr sehr direkt :D
12:49:52 Schrompf: wie soll's denn weniger direkt gehen?
12:50:10 Schrompf: nebenbei: grpc schafft mitm go-client den traffic nicht :(
12:50:43 Schrompf: da müssmer uns auhc noch was ausdenken. unsre dicken c++-server schaffen ein paar zehntausend requests pro sekunde mit grpc, der go-client ist faktor 10 darunter :-(
12:50:57 Schrompf: da muss auch noch magic passieren, aber bisher haben wir immer alles irgendwie hingekriegt
12:51:22 Schrompf: nuja, spannende zeiten, nur matschige hirne
12:51:24 Schrompf: adios
13:02:05 IceMichael: TCP ist sehr direkt, ja. Weniger direkt ist zB NATS oder die üblichen Kandidaten wie RabbitMQ etc.
13:03:00 IceMichael: NATS ist sauschnell, sonst recht lightweight, und hat sub/pub schön eingebaut. Alle müssen nur die zentrale (skalierbare) NATS-IP kennen
13:03:22 IceMichael: weiß nicht, wie dick die Nachrichten sind, aber NATS schafft wesentlich mehr als 10k request pro sek
13:03:44 IceMichael: ist halt die Frage, was daran so lange dauert. Wenn du sagst, client, dann ist es vll das protobuf parsen? damit wäre das Übertragungsprotokoll ja egal
13:05:04 IceMichael: bei "jedes Feature allein tut" frag ich mich: meinst du damit, auf einem einzelnen microservice? Oder sind da auch Integrations/contract-driven-consumer-Tests mit drin?
13:05:13 IceMichael: wenn es wirklich nur ne bestimmte, komplizierte Konstellation ist... ja gut, Mist
13:05:22 xq: jo, hatte sowas wie NATS im Kopf
13:05:25 IceMichael: wenn es mehr als Integration ist, sollte der Akzeptanztest es trotzdem abbügeln
13:05:33 IceMichael: ja, nutze NATS jetzt privat und wir nutzen es auf der Arbeit, ist nice
13:05:40 IceMichael: stimmt, ist auch MQTT-kompatibel :)
13:06:14 IceMichael: Testen ist irgendwie echt mehr tricky, als ich dachte... und dann die Diskussion von mocks vs stubs
13:06:22 IceMichael: aber das richtig zu machen ist echt wichtig
13:06:49 xq: heh
13:06:58 xq: das, was ich grade für den hackerspace baue, ist super schwer zu testen
13:07:17 xq: also, potentiell schon mit stubbed mqtt services machbar
13:07:24 xq: aber alles danach wird schwer
13:07:37 IceMichael: ich hab in dem Buch letztens auch zu embedded nen Abschnitt gelesen. Die Idee ist, dass man alles service/firmware/hardware-bezogene strikt von den Logiksachen trennt. Dann kann man Logiksachen dennoch automatisiert testen
13:08:32 IceMichael: der Standard-Approach, den fast alle machen, ist ja alles zu vermanschen. Logik und Embedded-bezogene Sachen und UI...
13:08:40 IceMichael: MVC machen viele noch, das war's dann
13:09:22 IceMichael: was machst du denn und was ist da so schwer zu testen?
13:09:39 xq: es geht um das zusammenspiel von 5 türen ^^
13:09:48 xq: Zugangssteuerung für den Hackerspace
13:10:06 IceMichael: zumindest Logik und Sequenz des Zusammenspiels sollte ja gut testbar sein
13:10:12 xq: jo
13:10:17 xq: wird aber ne rießige fummelei
13:10:27 xq: erst mal muss man aber rausfinden, was die korrekte sequenz überhaupt ist
13:10:35 xq: und auf welchem abstraktionslevel wir reden :D
13:11:14 IceMichael: ja, ich würd's so abstrahieren, dass du es testen kannst und alles, was wirklich hardwaretechnisch ist, strikt getrennt ist. Also so ohne tieferen Einblick
13:11:26 xq: jo, müsste theoretisch gehen
13:11:27 IceMichael: kann eh sein, dass alles hardwarenahe dann 90% von allem ist und es somit keine Rolle spielt
13:11:38 xq: es gibt highlevel logik
13:11:44 xq: nur wird dann halt die test suite 30 minuten laufen
13:11:45 xq: oder so
13:11:52 IceMichael: hm, wieso so lang?
13:12:03 xq: weil unglaublich viele timeouts
13:12:11 xq: und zwar im minuten-bereich
13:12:34 IceMichael: also um die Logik zu prüfen würd ich Timeouts simulieren
13:13:02 IceMichael: zB nen Zeitraffer-Timer anbieten, der aus ner Minute ne 1/100 Sekunde macht oder so was... oder komplett von echter Zeitmessung losgelöst
13:13:28 IceMichael: also das wäre das UT-Level. Als integrativen Test mit echter Hardware, gut, das geht natürlich nicht schneller
13:13:29 xq: ja, das problem ist, dass ich aber trotzdem mehr als eine komponente gleichzeitig prüfen muss
13:13:32 IceMichael: ist halt nett beides zu haben
13:13:43 xq: 3 der Türen sind mit nem ESP32 ausgestattet
13:13:49 xq: die ESPs kümmern sich ums ent- und verriegeln
13:13:56 xq: sowie die sensorik, um zu erkennen, was die tür grade so tut
13:14:03 xq: zudem gibts nen button an jeder der türen
13:14:05 IceMichael: (euer Hackerspace klingt übrigens geil)
13:14:24 xq: wir ziehen grade um ^^
13:14:33 xq: darum auch neuentwicklung mit komplexität^10
13:14:55 IceMichael: ja gut, Sensorik, ob der Button klappt usw., das kann man ja nur durch wirklich testen testen
13:15:25 xq: yep
13:15:26 IceMichael: aber die Logik mit Timeouts sollte sich dennoch rauslösen lassen, denk ich
13:15:37 xq: jo, aber lass mich kurz weiter erzählen
13:15:39 IceMichael: wie viel der Teil des Testens bringt, weiß ich natürlich nicht. Ich würde da definitiv viele Bugs einbauen
13:15:45 IceMichael: ja klar
13:15:51 xq: zudem gibt es dann noch nen MQTT-Broker, welcher die Nachrichten dispatched
13:16:04 xq: und es gibt nen Daemon auf dem MQTT-Broker, welcher das System verwaltet
13:16:16 xq: und es erlaubt, Prozesse via SSH anzustoßen
13:17:10 xq: und die dinge, die ich für schwer zu testen halte, sind die ganzen dinge, die auf dem highlevel-prozess passieren
13:17:26 xq: weil: es gibt diverse varianten, alles auf/abzuschließen
13:17:34 xq: und aufschließen ist relativ komplex per se
13:18:08 IceMichael: hm, was meinst mit highlevel-Prozess und was wär da so ein Beispiel?
13:18:13 xq: okay
13:18:19 xq: der prozess sieht so aus:
13:18:30 xq: du ziehst das handy aus der hose, connectest dich mit dem wlan "portal"
13:18:41 xq: anschließend machst du nen ssh connect auf open-front@portal.shackspace.de
13:19:10 xq: das triggered den Daemon, dieser setzt ein Paket ab an den ESP(front)
13:19:28 xq: zudem ein weiteres paket an ESP(buzz)
13:19:52 xq: ESP(buzz) drückt dann quasi nur auf einen schalter an der vorhandenen türanlage und öffnet dir damit die gebäudetüre (türbuzzer, kennt man ja)
13:20:06 xq: ESP(front) empfängt das signal, und prüft seine türe
13:20:28 xq: wenn türe abgeschlossen, fängt der ESP an, den schlüsselmotor anzusteuern und die türe aufzuschließen
13:20:39 xq: wenn das geklappt hat, signalisiere ich den zustand "aufgeschlossen"
13:20:46 xq: danach 60 sekunden timeout
13:21:12 xq: wenn in der zeit die türe physisch geöffnet wird, signalisiere "successful unlock"
13:21:16 xq: ansonsten schließe ich wieder ab
13:21:43 xq: auf "successful unlock" folgt dann ein "unlock back", welches die hintertüre aufschließt, diesmal aber ohne den 60-Sekunde-Timeout
13:22:04 xq: danach schick ich dir ggf. in deine SSH-Session noch ein "erfolgreich aufgeschlossen"
13:22:11 xq: und setze den API-Status auf "Offen"
13:23:38 IceMichael: okay, klingt von der Logik ja sehr überschaubar
13:23:47 xq: jo, das war ja auch nur eine von 5 sequenzen /o\
13:24:01 xq: zuschließen, einzeltüren auf/abschließen, usw
13:24:26 xq: aber ja, den kram zwischen den einzelnen teilnehmern bekommt man halbwegs gut gemocked durch alternative MQTT-Teilnehmer
13:24:46 IceMichael: okay, aber die Logik zwischen den zwei ESPs, dem Handy, dem Daemon und dem MQTT-Broker kann man ja ohne Hardware aufschreiben
13:25:10 IceMichael: ja, gemocked oder gestubbed, irgendwie gedoubled, sollte alles klappen
13:25:26 IceMichael: also wenn die Sequenzen komplex genug sind, dass man sich da bei irgendwas vertuten kann
13:25:46 IceMichael: aber ich find's mittlerweile halt echt schön, die Logik unabhängig von jeder Peripherie aufzuschreiben, einfach weil es so nett self-documented ist
13:26:12 xq: jo, ich schreib den Kram auch primär als State Machine mit Events und Signalen
13:26:30 xq: aber wirklich lesbarer wird die (mechanisch) tür auf/abschließen-sequenz nicht :(
13:26:52 IceMichael: die ist halt verteilt auf diverse Spieler
13:27:07 IceMichael: das wird nur in einem Test lesbar, der die gesamte Interaktion testet, würd ich denken
13:28:12 IceMichael: hm, aber das mit signals und events klingt doch eigentlich nett
13:28:43 IceMichael: das ist an der Stelle komplett unabhängig von Nachricht-Senden/Empfangen usw.?
13:29:18 IceMichael: state machines sind halt eh immer so ne Sache... vll helfen coroutinen oder so, manchmal machen die es lesbarer, aber kA
13:29:24 xq: jop, isses
13:30:02 IceMichael: aber wenn da mehr oder minder nur die Logik steht, klingt das doch wirklich relativ einfach. ZB eine File pro Sequenz, darin dann nur die Logik hm
13:30:14 IceMichael: na ja, bleibt halt verteilt
13:31:37 IceMichael: ja, ich würd nach wie vor überall alles doublebar machen und dann vll nen Integrationstest schreiben, der quasi alle 5 (oder wie viele) Player instanziiert mit Doubles und dort kannst du die dann spielen lassen
13:32:24 IceMichael: und wenn das klappt, sollten eigentlich "nur" unerwartete Delays, Hardware-Failures irgendeiner Art, verschwundene Nachrichten (wenn NATS hier nicht replay mit Jetstream oder so macht), Übertragungsfehler usw. usf. Probleme machen, aber zumindest nicht die Logik selbst
13:32:47 IceMichael: aber wsl ist das wie gesagt halt nur ein winziger Bruchteil der Miete, also was soll's :D
13:33:05 xq: das größere problem ist:
13:33:07 IceMichael: btw nice... man kann in go einen method-pointer als function-pointer nutzen quasi
13:33:10 xq: ich hab keine zeit für extensive testing :(
13:33:55 IceMichael: hm... aber wenn es schiefläuft, bringt das ja auch nix
13:34:22 IceMichael: wenn ich so was mache, verbrate ich aber ewig Zeit, weil es nicht direkt klappt und ich dann doch rumteste. Zumindest würd ich die Tests dann so einsetzen, wo es dir wirklich Zeit spart
13:34:36 IceMichael: wsl machst du aber eh direkt alles viel korrekter und bugfreier und sparst dann vll einfach nix
13:35:34 xq: ich weiß es nicht
13:35:39 xq: hätte gerne ein testing framework
13:35:50 xq: einfach, damit ich ne gewisse garantie habe und auch zukünftig den prozess nicht zerhacke
13:36:30 xq: das lustige wird auch, den MQTT-Broker zu testen ^^
13:37:49 Magister joined the channel
13:37:54 IceMichael: was ist denn bei den Tests so aufwendig?
13:38:21 IceMichael: die Logik hast doch vermutlich schnell geschrieben und nen Integrationstest, der alle Einzelprojekte importiert und dann das mal durchspielt, zumindest für ein paar Basisszenarien klingt ja eigentlich machbar
13:38:36 IceMichael: was ist beim Broker das Problem? also welchen Teil willst da testen?
13:38:37 IceMichael: hi Magister
13:38:45 xq: allein die schiere menge an tests ist das problem ^^
13:39:11 xq: Integrationstest geht halt nich so wirklich, dafür müsste ich komplett virtuelle hosts aufm PC bauen
13:40:24 xq: Der Broker ist verdammt zugenagelt ^^
13:40:38 xq: Ich roll ne Hausinterne CA aus, welche die Zertifikate für alle Teilnehmer signieren muss
13:40:52 xq: und wenn du kein von dieser CA signiertes Zert hast: yeeeeet
13:43:39 IceMichael: ok, man könnte halt multi-player-Tests machen, die keine Integrationstests sind
13:43:43 IceMichael: kA, wie man das dann nennt
13:43:51 IceMichael: im Prinzip auch einfach UTs
13:44:06 IceMichael: aber das mit der CA ist doch kein Problem?
13:44:17 IceMichael: also ich mein, fakest halt ne CA, fakest Zertifikate usw. fürs Testen
13:45:37 xq: jo, das is klar
13:45:48 xq: aber ich muss halt auch einfach testen, ob die üblichen sachen gecheckt werden mit MQTT
13:45:52 xq: also "prüfen die clients den host name"
13:45:58 xq: "prüft der host die client certs"
13:48:04 xq: aber: erst mal muss der kram überhaupt tun
13:50:48 IceMichael: ja, ist so oder so aufwendig
13:50:59 IceMichael: weil das ist ja schon Integrationstest-Level
13:52:52 xq: ich weiß halt nicht, wie ich irgendeine art von staging-umgebung bauen soll...
13:57:47 xq: was ganz anderes:
13:57:57 xq: mir geht grade wieder C++ aufn Sack mit seinem "Aber void ist speziell!"
14:27:20 xq: übrigens, IceMichael: ich gebe grade langsam und genüsslich dem C++Builder die Kugel *rofl*
14:31:47 xq: ich hab jetzt ein eigenes buildsystem
14:31:55 xq: ich brauch die IDE nur noch, um die Forms zu designen
14:42:36 IceMichael: xq: oh endlich stirbt er!!
14:43:13 IceMichael: hm, brauchst für MQTTs immer eigene VMs, kannst nicht diverse clients aufbauen und server auf nem gewissen port usw.?
14:43:20 IceMichael: muss man doch testen können, gibt da sicherlich mechanismen
14:43:44 IceMichael: und inwiefern ist void speziell? also klar, man kann es nicht kopieren, keine Typen damit anlegen usw.
14:43:51 IceMichael: oh stark @ Forms
14:43:57 IceMichael: dafür ist es vermutlich ja sogar brauchbar
14:45:47 xq: MQTT ist ne einzelne Executable, brauchste keine VM für
14:45:50 xq: das wäre ja verrückt
14:46:04 xq: kannst ja alles auf einer maschine laufen lassen
14:46:14 IceMichael: hm und wie liegt bei staging area dann das problem?
14:46:21 xq: und@void: genau das was du meinst. Es gibt in Zig keinen hashset-type
14:46:30 xq: IceMichael: wo bau ich die staging area?
14:46:40 xq: "auf meinem laptop" wäre ja ne dumme idee, oder? ;)
14:47:17 IceMichael: mqtt basiert doch auch auf tcp oder nicht? dann wäre dein laptop schon ok, wenn mqtt server nen testport nutzt
15:04:26 xq: der kann ja auch production port nehmen
15:05:07 xq: aber trotzdem muss ich ja irgendwo halbwegs isoliert den kram nutzen
15:13:03 IceMichael: xq: wieso kriegst es lokal nicht isoliert?
15:13:27 xq: naja, du musst ja ein sauber dokumentiertes environment schaffen
15:13:36 xq: was ich lokal auf meinem laptop definitiv nicht kann
15:13:46 xq: vorallem ist ja der laptop nicht der richtige ort dafür
15:13:55 xq: also muss man irgendwie ne saubere, portable testumgebung bauen
17:34:52 IceMichael: xq: wieso nicht? Du könntest das alles mit so was wie docker (compose) machen. Dann kannst du es deployen , wo auch immer du willst. Und IaaC hat den Vorteil, dass es Self documented ist
17:35:26 IceMichael: -1a
17:35:57 IceMichael: Ich würde im Integration Test repo einfach ein subdir deploy oder so machen, wo der Kram steckt
17:40:29 IceMichael: oder man geht auf packer und ansible oder so, aber dann sind es halt full-fledged VMs, das willst wsl nicht
17:40:54 IceMichael: ok, man kann packansible auch für docker irgendwie nutzen ja gut
18:28:34 Schrompf joined the channel
18:34:33 IceMichael: hm, stubben geht in Go auch ganz nett
18:34:44 IceMichael: nur vom naming ist's etwas doof und es geht nicht ganz unintrusiv
18:34:45 IceMichael: hi Schrompf
18:35:23 IceMichael: also freie Funktionen zB
18:35:30 IceMichael: var MyFunc = MyFunImpl
18:35:34 IceMichael: und MyFuncImpl ist dann die eigentliche Funktion
18:35:59 IceMichael: und im Test dann einfach: MyFunc = MyFunTest
18:36:36 IceMichael: für Klassen halt interfaces basteln wie in andren OOP-Sprachen üblich
18:37:43 IceMichael: bin dennoch ne lahme Krücke
18:47:22 IceMichael: ok, meine Tests sind alle kacke irgendwie... ich prüf überhaupt nicht das Richtige lol
19:02:34 Schrompf: tut mir leid, das zu hören