Transcript: Javascript Frontends

24. April 2020 · Back to episode

Full episode transcript. Timestamps refer to the audio playback.

Ja, herzlich willkommen, liebe Hörer und Hörer. Willkommen beim Python-Podcast in der 20. Episode heute.

Wir sind wieder im Homeoffice, wie man es so macht, dieser Tage, remote dabei.

Ich hoffe, wir können uns gut verstehen. Letzte Folge war etwas audioschwanker.

Dabei war sie inhaltlich sehr toll.

Wir haben uns vergessen, den Podcast zu erwähnen von Thomas.

Das war auch echt blöd. Der Podcast von Thomas heißt PyData Deep Dive.

Sehr empfehlenswert.

Ja, genau. Ein sehr cooles Ding.

Was machen wir heute? Jochen ist natürlich wieder da. Ich bin in meiner Raumschutzzentrale, Jochen im Wintergarten.

Willkommen, Dominik.

Es ist eine etwas ungewohnte Situation. Wir sind beide remote und wir haben hier auch noch ein Video dabei laufen.

Aber das ist irgendwie so ein bisschen eigenartig.

Ja, es ist nicht so richtig zum Anfassen. Normalerweise sitzt man beim Podcast ja immer bei sich gegenseitig auf der Couch.

Und ich kenne das auch, wenn ich Podcasts höre, dass man immer bei den Menschen, die das machen, irgendwie mit dabei ist.

Und das ist gerade so ein bisschen schwierig.

Aber na ja.

Das ist nicht so richtig.

Heute machen wir Frontend mit Python und oder wie man das verbindet mit Python.

So zum Beispiel der Plan.

Also als Thema uns überlegt, ja, weil es halt gerade auch irgendwie sich anbietet, weil da irgendwie wir beide halt so ein bisschen,

irgendwie mehr mit zu tun haben im Moment und dann.

Struggle.

Ja, genau.

Aber vielleicht, ich habe auch noch so, ich weiß nicht, du hast, du hast ganz viele Fragen da in diese Themenliste reingeschrieben.

Und ich hatte mir die auch mal, ich habe dann auch selber noch Sachen reingeschrieben.

Und zwar zum Beispiel könnte man noch so ein bisschen metamäßig über Podcasts und Audio Hardware und so reden, weil da hat sich ja auch was getan.

Oh ja, oh ja.

Ich meine, das ist natürlich jetzt irgendwie, alle Leute beschäftigen sich jetzt so ein bisschen mit.

Man macht ganz viel mehr mit Video und Homeoffice und so.

Und komisch wäre eigentlich ganz nett, wenn man mal Internet hätte und man hat aber irgendwie keins und so.

Stimmt.

Könnte praktisch sein, ja.

Da ist es auch ein bisschen schwierig, jetzt so Audio Hardware zu kriegen, weil das ist alles irgendwie ausverkauft.

Ja, ich wollte auch sagen, wir wollten das tatsächlich schon, ja.

Ja, sag mal, wie ist das Bescheid von das jetzt hier mit dem Remote, mit dem Setup, wie sich das anhört im Vergleich zu sonst?

Übrigens, die Liste, die du da geschrieben hast, Jochen.

Es gibt so ein paar Menschen, die mir dann eine Einkaufsliste schreiben, was ich alles mitbringen soll.

Und die schreiben das auch völlig durcheinander.

Also ich organisiere das so, dass ich den Supermarkt durchlaufe von Anfang bis zum Ende.

Da muss ich nicht die Liste immer durchrollen.

Ja, ja, ja.

Ja, es gibt auch offenbar unterschiedliche Strategien.

Und ich wage nicht zu beurteilen, ob jetzt die eine sinnvoller ist als die andere.

Aber es sind alle valide.

Genau.

Aber das ist das Problem.

Wir machen das sowieso immer.

Wir reden immer durcheinander und kommen dann wieder zurück zum eigentlichen Thema von daher.

Wir kriegen das schon irgendwie alles hin.

Genau.

Zum Beispiel, was ich als neuer Audio-Hardware habe, ist, was ich schon immer mal ausprobieren wollte.

Und jetzt habe ich halt irgendwie das dann auch mal besorgt.

Ist ein neues Headset.

Normalerweise verwenden wir immer diese DT297 von Bayerdynamic.

Und die funktionieren auch super.

Also habe ich eigentlich nichts daran auszusetzen.

Nur das Problem ist, also ich bin so Brillenträger und habe große Ohren.

Eine etwas ungünstige Kombination.

Die drücken mir.

Wir drücken die so ein bisschen auf die Ohren.

Und bei dir sieht man auch die Haare gar nicht.

Die sind auch länger geworden.

Wir waren alle in diesen Zeiten jetzt alle nicht beim Friseur.

Alle so Matte und Bart.

Wie heißt der bei Harry Potter so?

Ich werde immer so ein bisschen nach und nach Hagrid ähnlicher.

Vorher hatte ich nur die Statur.

Jetzt habe ich auch die anderen Attribute.

Ja, tatsächlich.

Also ich würde auch sagen, dass das der Charakter in Harry Potter, den du am nächsten kommst von der Optik.

Ja, ja.

Und ähm.

Genau.

Ich brauche halt große, große Kopfhörer Muscheln.

Und das bei dem DT 797 ist auch ein Bayerdynamic Headset.

Und da ist das halt irgendwie so ein bisschen größer, dass es geschlossen ist.

Und ich weiß nicht welche rein, aber der hat das leider kein Mikrofon.

Ah, okay.

Ja, das sieht auch sehr gut aus.

Kann man jetzt natürlich im Podcast nicht sehen.

Aber genau.

Ja, das sind auch so Studio Abhörer.

Also das ist auch die Headset Variante von einem von dem DT 790 Pro oder so.

Das ist auch eigentlich ein Studio Kopfhörer.

Und da ist halt noch so ein Mikrofon dran gebastelt.

Und ein Kabel dran.

Und ehrlich gesagt gefällt mir das.

Und das Problem, was ich auch habe, ist halt dadurch, dass das halt nicht so richtig auf die Ohren passt.

Und dann liegt das halt auch auf der Brille so ein bisschen auf.

Und dann quetscht mir das die Brille so ein bisschen.

Und das ist jetzt tatsächlich mit dem hier deutlich besser.

Also ich bin mal gespannt.

Das Mikrofon sollte das gleiche sein.

Also da sollte es keinen großen Unterschied geben.

Ja, okay.

Aber im Endeffekt Komfort ist ja auch wichtig.

Genau.

Wenn man jetzt so lange sitzt und die ganz langen Folgen immer auf und weil wir viel zu erzählen haben,

dann sollte das auch beim Tragekomfort.

Dementsprechend, ja.

Und dann hatten wir noch ein...

Du hast gebastelt.

Du meinst diese mit dem HMC66, diese Bastelgeschichte?

Ja, du hast irgendwas gebastelt.

Du hast was zusammengesteckt und hast dann so eine Klinke an so einen XLR Kopfhörer dran gemacht

und hast das Ganze in ein Handy reingesteckt.

Ah, genau.

Das ist total cool.

Denkt man sich eigentlich diese ganzen Geschichten?

Das sollten doch inzwischen gelöste Probleme sein.

Irgendwie.

Headsets.

Audio-Computer-Geschichten.

Das gibt es doch alles schon lange.

Aber es ist irgendwie gar nicht so.

Also wenn man das so haben möchte, dass es ordentlich klingt,

dann ist das immer noch eine ziemliche Bastelei,

beziehungsweise muss man halt viele Dinge einfach wissen.

Und selbst wenn man sich damit so ein bisschen beschäftigt, reicht das nicht.

Es kann auch sein, dass ich jetzt totalen Unsinn alles erzähle,

weil so ein totaler Experte für diesen ganzen Audio-Kram bin ich natürlich auch überhaupt gar nicht.

Aber so nach und nach bekommt man dann halt Dinge mit.

Und eine sehr interessante Geschichte, die ich halt letztens gesehen habe,

war, dass...

Es gibt ein Headset, das auch sehr gut klingt.

Das ist das HNC66X Superlux.

Ich weiß nicht, was das für eine Firma ist, keine Ahnung.

Das ist auch super billig und klingt trotzdem super.

Also eigentlich alles ganz toll.

Ist natürlich nicht so gut verarbeitet wie die Biodynamic-Dinger,

aber eigentlich sehr empfehlenswert und verwenden auch ganz viele Leute.

Und das hat so ein Problem.

Also was einem immer dazu gesagt wird, wenn Leute das...

Oh oh.

Das benutzen, sagen sie so.

Ja, das ist total toll und eigentlich ideal.

Aber man muss so ein bisschen...

Es hat so ein paar Probleme, wie zum Beispiel normalerweise...

Also müsste man eigentlich mal ausholen,

wo ist eigentlich der Unterschied zwischen dynamischen und Kondensatormikrofonen.

Also nur mal so, um die Klammer aufzumachen.

Wir machen die gleich wieder zu.

Ich wollte da von der extra Folge hören.

Also die meisten kleinen Mikrofone sind tatsächlich Kondensatormikrofone,

weil man die deutlich kleiner bauen kann.

Und der Unterschied ist eigentlich in der Bauart sozusagen,

dynamische Mikrofone sind so ein bisschen wie ein umgekehrter Lautsprecher.

Die funktionieren auch ohne, dass die irgendwie selber aktiv sein müssen.

Das heißt, man kriegt ein Signal raus, ohne dass das irgendwie selber irgendwas macht.

Und das ist ganz praktisch.

Und sie haben halt so als Charakteristik, sie sind unempfindlicher gegenüber Störgeräuschen.

Ja, so reagieren einfach so ein bisschen gutmütiger oft.

Sind aber auch nicht so, kriegen nicht so feine Unterschiede hin

und lösen nicht so fein auf wie jetzt ein Kondensatormikrofon.

Kondensatormikrofone sind so ein bisschen anders.

Die sind nicht passiv, sondern da muss Strom dran sein, sonst funktionieren die gar nicht.

Und da kommt dann halt aktiv ein Signal raus, das die dann halt erzeugen.

Und das Problem dabei ist, dass wenn das...

Also man kann sie sehr klein bauen, das ist eigentlich schön.

Aber wenn sie sehr klein sind, dann je kleiner die sind, desto mehr muss man das Signal verstärken.

Was dann natürlich auch wieder Rauschen reinbringt und so.

Also es gibt auch sehr gute, sehr kleine Kondensatormikrofone, aber die werden dann halt sehr teuer, sehr schnell.

Was man normalerweise macht, wenn man guten Klang haben möchte, ist halt, man nimmt dann halt Großmembran-Kondensatormikrofone,

die halt dann schon mehr Signal, wo man halt weniger verstärken muss sozusagen.

Das ist halt so das, was man...

Studios verwendet für Sprachaufnahmen.

Und so ein Ding habe ich ja auch umliegen, könnte man auch verwenden,

aber man hat das normalerweise an so einem Arm und dann in so einer Spinne hängen.

Und das ist so ein bisschen unhandlich, weil man irgendwie immer den gleichen Abstand einhalten muss dazu und so.

Wenn du das nicht machst, dann steht das irgendwie vor dem Bildschirm und versperrt den ganzen Sicht, Viktor.

Genau, also das ist alles so ein bisschen...

Daher mag ich das mit den Headsets eigentlich lieber.

Ja, aber die klingen halt dann vielleicht nicht ganz so gut, aber auch schon ziemlich, ziemlich klasse.

Und jetzt kommt der Hack und wir sind übrigens beim Python-Podcast, lieber Jochen.

Ach ja.

Naja, also der Witz ist eigentlich, also deswegen, warum ich das eigentlich erzähle, ist, man braucht...

Also die brauchen halt Strom, ja, sonst funktionieren die nicht.

Und Standard für Stromversorgung, man nennt das dann irgendwie Phantomspeisung bei Kondensatormikrofonen, ist halt irgendwie...

24, 48 Volt normalerweise, sag ich mal so.

Es gibt aber auch 24 Volt und es gibt sogar 12 Volt.

Und dieses HMC66X, das klingt bei 48 Volt und 24 Volt, also funktioniert es zwar, aber es klingt schrecklich.

Deshalb, da musst du immer aufpassen.

Da gibt es so ein paar Reviews unter denen, wenn man das irgendwo in einem Online-Shop sieht oder so.

Und meistens ist dann so ein oder zwei dabei, die sagen so, es wird immer so gelobt, das klingt ganz scheußlich, ich verstehe das gar nicht.

Wie können Leute...

Kommen Leute auf die Idee, dass das gut ist?

Das klingt doch ganz, ganz...

Klingt doch total elend.

Und ich fürchte, der Grund dafür ist meistens, dass die Leute das dann halt irgendwie an einem Audio-Interface betreiben, das halt dann die falsche Phantomspannung hat, sozusagen.

Und dann geht es halt nicht richtig.

Womit das gut funktioniert, ist halt 12 Volt Phantomspannung.

Und was man halt tun kann, ist entweder man lötet sich da so einen Widerstand rein.

Das ist halt so eine beliebte Lösung.

Jetzt wird es interessant.

Aber für mich auch schon zu...

Das ist zu weit...

Das ist halt nicht...

Ich bin dann den einfachen Weg gegangen und habe dann so eine...

Man kann da irgendwie so eine Box zwischen das Mikrofoneingang von dem Audio-Interface und das Headset schalten.

Das kostet dann auch nochmal 20 Euro oder so, keine Ahnung.

Und dann halt auf 12 Volt Phantomspannung das runterriegeln.

Oder da kann man das dann auch in dieser Box irgendwie einstellen.

Und ja, das habe ich dann halt benutzt und dachte mir dann so, naja, selbst plus dieses Ding und plus den ganzen Kabelaufwand,

ist es immer noch für den Preis...

Das ist eigentlich ziemlich unschlagbar.

Und ich dachte immer...

Wie teuer ist denn das?

Bitte?

Wie teuer ist denn das?

Ich gucke gerade mal.

Das kostet 39 Euro oder so.

Also ist echt nicht teuer.

Und ich dachte immer, diese Kondensatormikrofone, die brauchen halt immer einen XLR-Anschluss.

Also dieses dreipolige Ding da.

Und ja, du brauchst halt immer ein eigenes Audio-Interface eigentlich.

Normalerweise.

Normalerweise hat man an seinem Computer nicht sofort oder als Standard einen XLR-Anschluss.

Man hat halt Pinkel.

Ja, das ist...

Genau.

Und dann hast du dir was gebaut, was richtig toll ist.

Nein, das habe ich auch gesehen.

Das habe ich auch in diesem Sendegate-Forum gesehen.

Ich habe da nichts gebaut.

Ich habe es auch wieder nur gekauft.

Man kann das bauen auch selber, wenn man das mag.

Aber ich habe es nicht gebaut.

Ich habe es auch wieder nur gekauft.

Die Idee.

Kauf dir die Welt, wie sie dir gefällt.

Ja, es ist...

Also, wenn mir das jetzt Spaß machen würde, das selber zu löten oder so, aber das...

Es macht keinen Spaß und ich kann es auch nicht.

Also jedenfalls hast du das Ding...

Auf eine Klinke adaptiert.

Und jetzt kannst du das tolle Headset sogar in dein Telefon stecken.

Genau.

Und kannst mit dem coolen Headset Podcasts aufnehmen über das Telefon.

Genau.

Ich dachte immer, irgendwie an der Klinke gehen nur dynamische Mikrofone.

Auch die meisten Mikrofone, die man über Klinke anschließt, sind dynamisch.

Und die klingen halt nicht so gut.

Und das stimmt aber gar nicht.

Zum Beispiel ist es halt so, dass die meisten wirklich kleinen Mikrofone,

also auch diese Dinge, die man sich so ans Hand steckt oder so.

Wir haben ja auch mal...

Am Anfang haben wir damit angefangen.

Mit diesen roten...

Ich weiß nicht, wie man das ausspricht.

Lavalier, Lavalier, keine Ahnung, Mikrofon.

Das sind auch üblicherweise Kondensatormikrofone.

Und die kriegen ihre Phantomspeisung halt über die Klinke

und da kommen halt so anderthalb Volt raus ungefähr.

Und diese anderthalb Volt reichen halt für dieses HMC-Headset auch.

Das funktioniert.

Das heißt, man braucht eigentlich nur eine Klinke auf XLR-Adapter

und dann halt nochmal ein Ding, was halt auch irgendwie dann das zusammenführt.

Weil man hat ja nochmal einen getrennten Kopfhörer.

Wir stellen euch da eine ausführliche und detaillierte Liste in die Shownotes.

Aber der Witz ist halt, also was ich jetzt habe, ist halt,

man steckt dieses Headset halt in diesen Adapter.

Aus dem Adapter kommt Klinke.

Dann steckt man irgendwie die Klinke.

Die Klinke steckt man dann halt in eine Klinke auf Lightning-Adapter.

Und dann steckt man diesen Adapter in halt ein Telefon zum Beispiel.

Und es funktioniert tatsächlich.

Und ich war letztens damit im Park unterwegs.

Das sieht so ein bisschen komisch aus.

Also ich wollte dich noch fragen.

Du hast gestern ja aufgenommen, hast einen kleinen Talk erhalten über Poetry beim Pi-DDF.

Da warst du im Park wirklich?

Weil ich habe kurz reingeguckt bei YouTube.

Oder hast du deinen Hintergrund geblendet?

Nee, ich habe da meinen, da habe ich den Hintergrund verändert.

Ah, okay.

Mit was machst du das?

Mit OBS Studio?

Was ist das denn?

Das kenne ich gar nicht.

Das ist so eine Software, da kann man das ganz cool mitmachen.

Da kann man so Green Screen oder...

Nö, das war der Zoom-Client und der macht das dann halt.

Ach so.

Ach, okay.

Na dann.

Ja, aber ich war tatsächlich mit dem Headset schon im Park und habe mit Leuten telefoniert.

Und das Erste, was sie gesagt haben, war so, oh, du klingst aber gut.

Oh, ja, na dann.

Hat dir das vielleicht gelohnt?

Und das ist natürlich irgendwie...

Also ich telefoniere auch immer im Park mit meinem Freisprechknopf, der auf dem Display ist.

Da steht dann Ton, Laut, Sprech.

Ja, aber das funktioniert nicht so richtig gut.

Vor allen Dingen, wenn es windig ist, ist es halt blöd.

Oder ich gehe dann ja auch manchmal in der Gegend rum.

Und dann...

Zum Beispiel, wo Leute sich regelmäßig beschweren, ist, wenn ich über die Rheinbrücke gehe,

weil da ist es windig und es fahren Autos vorbei.

Und da verstehen meistens Leute dann nichts mehr und sagen so, oh, das klingt aber schlecht.

Und na ja, muss man gucken.

Vielleicht das nächste Mal probiere ich das mit dem Headset.

Vielleicht geht das besser.

Ja, okay.

Challenge accepted.

Bitte?

Challenge accepted.

Und warum gehst du über die Rheinbrücke?

Ja, weiß nicht.

Ich gehe da spazieren.

Ach so.

Ja, meistens...

Um zu telefonieren.

Ja, ja, ja.

Also meistens ist es halt so, wir sind halt im Hofgarten.

Und dann kommt irgendwann die Ansage, ja, Steine ins Wasser werfen.

Dann müssen wir halt noch zum Rhein.

Und dann gehen wir über die Rheinbrücke und dann unten zum Rhein.

Und dann werfen wir Steine ins Wasser.

Ach so.

Ah, Steine.

Okay, jetzt verstehe ich.

Und dann...

Da siehst du, da werft der einen Stein für mich mit.

Genau.

Also dieses Headset ist wirklich cool.

Und was halt mit anderen wahrscheinlich gar nicht gehen würde, dass man das halt einfach

so an ein Telefon anschließt oder so.

Das kann man damit machen.

zwischen eurem WLAN-Accesspoint

und eurem Telefon gibt

und benutzt dieses Headset

und dann hat man da eine ziemlich gute Audio-Verbindung.

Und das wäre ja eigentlich schon...

Ach so, und ja, was auch praktisch ist,

wenn man das Zoom H6,

das ist auch so ein Audio-Interface,

wo man vier Headsets dranstecken kann,

wenn man das verwendet,

das kann auch 12 Volt direkt Phantom-Speisung.

Also an dem Ding klingen die HMC-66XR auch direkt gut,

was natürlich auch sehr praktisch ist.

Und das wollte ich eigentlich...

Das war mein erster Plan, das Ding einfach zu kaufen.

Und dann habe ich festgestellt, es geht nicht,

weil alle Leute Audio-Interfaces kaufen, gerade wegen Corona.

Aber...

Ich glaube, wir brauchen jetzt einen Webshop

für so Audio-Podcast-Hardware.

Denn der haben wir gerade großzügig beworben.

Vielleicht brauchen wir da irgendwie...

Das Thema heute ist Frontend.

Ja, Moment, Moment, Moment.

Ich bin noch nicht mit der...

Nein, okay.

Wir machen das aber gleich mit ChapterMark, ja?

Also Leute, ihr wisst ja,

ihr könnt die ChapterMarks und die Sachen,

die euch nicht so freuig sind, einfach überspringen

und dann...

Direkt aufs Frontend klicken.

Genau.

Wolltest du mal so als Hinweis...

Ja, es gibt nämlich da noch so ein bisschen mehr.

Wir sind ja jetzt auch mit...

Das hatten wir letztes Mal auch gemacht,

aber...

Oder wir benutzen wir ja immer,

wenn wir Remote-Geschichten machen,

StudioLink.

Und das knackste und knickste und so

immer mal so ein bisschen.

Und natürlich gibt es dann da so gewisse Lösungen,

dass man das dann halt lokal so Double-Ender-mäßig

irgendwie auch nochmal aufnimmt

und die Spur hinterher irgendwie mitverwendet.

Aber das ist alles schwierig.

Und dann gerät das von der Zeit her

irgendwie so aus Synchronisierung,

Synchronisation, alles nicht so schick.

Und dann haben...

Meistens entschließt man sich dann in der Lebmachheit

mit den Knackstern.

Aber das klingt schon relativ furchtbar.

Und jetzt haben wir halt hier eine Beta-Version

von StudioLink und die knackst

praktisch gar nicht.

Jedenfalls...

Ja, wir werden es hören.

Wir werden es dann hören, aber...

Und sagt nicht Bescheid aufs Netz.

...ich das jetzt irgendwie bisher

bemerkt hätte. Also für mich klingt das

momentan alles sauber.

Und mal schauen.

Das ist natürlich das Problem.

Also eigentlich ist es natürlich auch doof,

dass wir hier WLAN haben.

Müsste eigentlich ein Kabel liegen,

aber das ist halt alles irgendwie so...

Wie, das ist kein Kabel?

Ich habe ein Kabel.

Also ich könnte...

Was ich vielleicht temporär machen könnte,

ich kann einfach ein Kabel

dann halt immer hier durch die Tür liegen.

Aber das Problem ist hier,

der Wintergarten, der ist einfach

sozusagen getrennt.

Das ist eine Außenmauer dazwischen.

Und ich weiß nicht, wie ich dieses Kabel

durch die Außenmauer kriege.

Das geht halt einfach irgendwie nicht.

Bohrmaschine.

Ja, gut.

Ja, wo wir wieder beim Löten wären.

Das ist eigentlich nicht so mein...

Also ich habe hier tatsächlich...

...in der Etage ein LAN-Kabel gelegt.

Ja, es gibt bestimmt irgendeine Lösung.

Und wahrscheinlich sollte ich da auch mal was tun,

weil WLAN ist auch echt tatsächlich nicht so geil,

muss ich sagen.

So richtig mit in der Wand und Dose und so.

Ja, das ist schon viel cooler.

Ja, das war nicht Bohrmaschine,

das war so ein Pressstemmhammer.

Da musst du mal so die Wand aufruppeln

und dann in das Kabel rein

und dann verspachteln und so.

Klingt alles sehr schrecklich.

Das ist mal anfassend.

Okay, lass mal überlegen.

Ist da noch irgendwas mit...

Da steht noch Zencast da drin.

Ach so, ja, das wäre halt auch noch eine andere Möglichkeit gewesen,

wie man das jetzt macht ohne Studio Link.

Aber weiß ich gar nicht.

Also das ist halt...

Also interessant finde ich es deswegen,

weil es einen ganz anderen Ansatz verfolgt.

Was ist das?

Das ist sowas ähnliches wie Ultraschall sozusagen.

Also die Software, mit der wir das Ganze aufnehmen.

Das ist...

Ach so.

Das ist nur...

Das ist nur nicht,

dass es halt eine Applikation ist,

die nativ läuft,

sondern das läuft alles im Browser.

Und alle Leute connecten sich halt zu einem Server sozusagen

und dann...

Weil es ja so gut klappt mit dem Browser und Audio und Video,

wie man ja jetzt an GT und so...

Ja, es gibt auch ein paar komische Geschichten.

Also das zum Beispiel,

das hat mich dann gewundert,

als ich das dann mal ausprobiert habe,

dass irgendwie alles geht dann da auf 44,1 Kilohertz

und das ist ja sehr unüblich.

Also normalerweise hast du ja immer Audio-Hardware,

das ist immer alles auf 48 Kilohertz.

Und das ist natürlich dann seltsam.

Dann muss man dann halt irgendwie das irgendwie...

umsamplen und ich weiß nicht.

Aber also Leute verwenden das und finden das gut

und ich habe es jetzt tatsächlich noch nicht...

Für den Podcast,

ich habe es jetzt mal ausprobiert,

ich fand es auch super

und ich finde die Idee halt total toll.

Also eigentlich wäre es natürlich schon saukool,

wenn man das alles im Browser machen könnte

und nicht noch extra Software installieren müsste

und das halt automatisch überall funktioniert.

Aber gerade sowas wie...

Ich habe hier ja auch...

So ein Mischpult,

das geht alles nicht,

sondern es ist halt so,

alle verbinden sich halt mit ihrem Ding halt irgendwo hin

und dann werden dann auch mehrere Spuren aufgenommen,

aber du hast halt nicht die Möglichkeit,

das nochmal durch ein eigenes Mischpult zu schleifen

oder so und dann da so...

Tragisch, tragisch, tragisch.

Ja, natürlich, wer braucht das auch?

Ja, ja, ich verstehe schon.

Aber...

Nehmen wir mal an,

zum Beispiel eine Geschichte,

für die man das schon braucht,

ist halt, wenn man jetzt einen Livestream hätte

und dann hat man...

Dann macht man halt so Dinge drin wie Audiokompression oder so,

die man dann halt möglicherweise hoch und drunter regeln will

und vielleicht noch irgendwie so eine...

Weiß ich nicht,

eben so ein Soundboard und weiß der Teufel.

Und das ist dann alles ziemlich...

Das geht dann alles nicht mehr so richtig, aber...

Ja, naja gut, okay.

Also ich weiß es nicht.

Für den Fall das,

dann überlegen wir uns das nochmal.

Was hältst du eigentlich davon,

wenn wir diese Meta-Diskussion,

diese Ausrufung dann an das Ende der Folgen stellen oder scheinen?

Damit unsere Hörer,

die sich auf das Frontend und Python,

freuen sich wie lange?

20 Minuten?

20 Minuten schon.

Uiuiui.

Weiß ich nicht.

Ich habe nicht genau gestoppt.

Nein, also ich mag das und ich finde das super,

aber es ist halt off-topic

und schreibt uns doch mal an hallo-at-python-podcast.de,

was ihr davon haltet,

ob ihr gerne vorher so Sachen hört

oder einfach sagt,

nee, dann lieber vorher das Python-Thema

und am Ende dann mache ich einfach aus

oder ich höre das sehr gerne

und bitte jetzt weiter die ganzen Meta-Sachen.

Ja, gut.

Okay, alles klar.

Jochen, welche von den Videokonferenz-Tools

nimmst du eigentlich am liebsten?

Also wenn wir jetzt schon bei dem Thema sind.

Das ist ja gerade ganz aktuell.

Weiß ich nicht.

Also Zoom hat mir jetzt tatsächlich von der Anwendung,

also man hört immer ganz schreckliche Geschichten davon.

Sicherheitsrisiken und Private und...

Ja, also genau.

Also was Security angeht

und diese Geschichten ist Zoom,

natürlich hat er eine ziemlich,

vernichtende Bilanz so bisher.

Wenn man das bedient,

ist es aber tatsächlich relativ nett.

So fast am nettesten.

Also ich habe Zoom mal auf dem Windows-Rechner angemacht

und das hat mir direkt Dinge in die Registry reingeschrieben

und Rechte geklaut,

die ich niemals erlaubt hatte,

dass es hätte haben sollen.

Und es hat auch vor allen Dingen

nach Beenden der Applikation

nicht alles so entfernt,

wie man sich das vorstellt.

Das fand ich ehrlich gesagt ein bisschen frech.

Also was ich sehr cool finde

und auch fand,

ist BigBlueButton.

Was habe ich da?

Das habe ich selber noch nicht ausprobiert.

Das finde ich tatsächlich bisher am schönsten.

Das hat auch so verschiedene Räume.

Das werden wir jetzt ein Python-Camp,

das am Morgen stattfindet,

übermorgen,

wahrscheinlich benutzen.

Das ist ja cool.

Das ist auch Open Source.

Ja, also falls ihr uns noch fragt,

ich weiß nicht,

wann wir die Folge wieder veröffentlicht bekommen.

Das Python-Camp ist übermorgen.

Genau, das ist übermorgen.

Könnte knapp werden.

Wir haben ja jetzt so ein bisschen Erfahrung schon,

der PyTDF-Sprint war ja auch,

virtuell.

Das hat eigentlich ganz gut geklappt.

Da haben wir Jitsi verwendet, ne?

das war jetzt auch nicht so schlecht.

Ja, Jitsi ist gut,

wenn es bis zu 10, 15, 20 Leuten ist.

Das ist ganz gut.

Ja, also sehr gut sogar.

also Zoom habe ich jetzt,

haben wir jetzt bei dem letzten PyTDF-Treffen,

benutzt.

Fand ich,

fand ich ehrlich gesagt sogar ein bisschen angenehmer.

so viel nimmt sich das alles nicht.

Und dann ansonsten,

was ich halt,

häufig benutze,

ist halt,

Teams.

eher so,

weil es halt,

weil halt muss.

Nicht,

weil man sich,

das benutzt man immer nicht,

benutzt man eigentlich fast nie,

weil man es sich ausgesucht hat,

Sondern das ist halt,

das ist halt irgendwie dann so die,

das ist komplett.

Ich dachte,

das wäre bei Zoom so.

ich glaube,

die Idee dabei,

das jetzt bei PyTDF zu verwenden,

war auch,

dass Marc,

Marc-André wollte halt ausprobieren,

was für unterschiedliche Dinge,

wie unterschiedlich funktionieren,

auch im Hinblick auf die EuroPython,

die er da damit.

EuroPython wird,

Zoom nehmen.

Das ist schon fest,

Ach so,

das ist schon fest,

Die haben sich auf Zoom geeinigt,

also GSC hat es nicht geschafft,

wegen dem Bug in Firefox,

das tatsächlich ja noch nicht behoben ist,

und weil es vor allem nicht so gut skalieren lässt.

BigBlue-Platten ist rausgeflogen,

weil das,

mehrere Server bräuchte dann,

oder viele,

die vom einen Richtungsaufwand her ein bisschen höher sind.

da blieb ja nicht mehr so viel übrig.

keine,

keine Ahnung.

für mich ist das,

ist diese Frage einfach auch noch nicht geklärt.

Das ist halt,

der Chat von EuroPython geht übrigens über Discord.

Weil er gesperrt werden soll,

weil der geflutet worden war,

zwischendurch mal von ein paar bösen Buben.

Sowas,

sowas.

wie gesagt,

also Teams funktioniert auch so halbwegs okay,

aber ist ansonsten irgendwie nicht so meine favorisierte,

Software für,

für diesen Kram.

was ich höre,

was super sein soll,

ist Meet,

also die,

Google,

Geschichte.

Habe ich aber selber auch noch nicht probiert.

Hangouts kenne ich,

Habe ich früher immer gemacht.

Ist dasselbe.

Aber Hangouts haben sie umgestellt aufs Meet.

genau.

Also Hangouts haben sie geschlossen.

Und es geht jetzt nur noch über Meet und ist eigentlich ganz gut.

ich benutze auch öfter mal Wearby.

Wearby finde ich auch gut,

das ist auch tatsächlich von der Qualität her in Ordnung,

aber das ist halt,

ab vier Leuten musst du Premium Account bezahlen irgendwie deswegen.

und ansonsten,

ich meine,

es gibt noch Skype und sowas,

aber das ist alles,

das verwendet eigentlich auch fast niemand mehr,

Das ist halt,

ich würde gerade sagen,

nimm das noch hin,

weil Skype ist tot,

Aber man kann ja auch sogar Videokonferenzen in Slack machen,

habe ich letztens gehört.

aber was ich,

eine Sache,

die ich super finde tatsächlich,

das benutze ich privat eigentlich.

Ich habe noch nicht erlebt,

dass das jemand irgendwie in so einem,

Berufskontext verwendet hat,

aber privat.

WhatsApp-Videokonferenz.

das sind halt,

das habe ich tatsächlich,

glaube ich,

noch nie gesehen,

FaceTime,

Apple,

und das funktioniert auch sehr,

sehr gut.

gerade in Situationen,

wo man halt mit mehreren Leuten dann halt um so ein Gerät rumsitzt,

ist das eigentlich ziemlich klasse,

weil das dann halt auch so,

es hat auch so nette Effekte,

dass dann die Leute,

die reden,

werden dann halt größer,

angezeigt und solche Sachen,

das ist halt,

der Client auf den,

iOS-Geräten ist halt super,

es gibt ja auch keine anderen,

es gibt ja nur die.

wir wissen ja mittlerweile,

dass du diese Firma mit dem Apfel da ganz gerne magst.

tatsächlich,

das funktioniert einfach ziemlich gut,

Kann man aber auch,

eben höchstens dann verwenden,

wenn Leute,

eben zumindest irgendein iOS-Gerät da haben,

oder irgendwie Apple-Hardware,

insofern,

das passiert übrigens,

liebe Hörerinnen und Hörer,

zwei Backender sich über Frontend unterhalten in einer Folge.

Dann reden wir über Videokonferenzen.

was machen wir?

Ich wollte tatsächlich sagen,

das Modul aus der Standardbibliothek,

was wir noch vorstellen wollten,

das wird Unitest-Mock,

Machen wir jetzt tatsächlich diesmal am Ende.

Und fangen jetzt tatsächlich,

ein bisschen über das Thema Frontend zu reden,

Alles klar,

können wir gerne machen.

na komm,

Wollen wir noch was News?

warte.

News aus Python jetzt.

jetzt geht's los,

Leute.

Ihr dürft jetzt einteilen.

was hatten wir denn da so?

Aufgeschrieben in Language Creators Conversation.

Das war irgendwie ein Panel.

Ach so,

das war das Panel mit,

mit Guido und,

dem Typen von Rust und,

nicht Rust.

Pearl.

Larry Wall von,

von Pearl.

Dann James Gosling von,

von Java und,

André Heilsberg

der hat,

Turbo Pascal in den 80ern mal entwickelt.

auf Delphi und sowas.

der ist,

da müsste ja jetzt jemand mit so einem Kuckstock und so einem uralter Kreis,

Das ist ja auch noch gar nicht so alt.

der hat jetzt auch,

irgendwie,

war da eine der,

treibenden,

oder vielleicht die treibende Kraft hinter,

hinter TypeScript.

ganz interessant.

ich weiß gar nicht,

in welchem Rahmen diese,

gelaufen ist.

Ich hab's halt eh dann als Podcast quasi gehört.

Die Audioqualität ist leider ziemlich schrecklich.

ich benutze dann immer an meinem Podcast-Player,

so ein,

so ein Sideload-Ding.

Das heißt,

ich sag,

in meinem Browser auf dem Telefon,

Sideload an meinen Podcast-Player,

und dann leert es das Video runter,

schmeißt das Video weg,

und das Audio geht dann halt als Podcast-Episode in meinen Player rein.

Das heißt,

ich hab das Video nicht gesehen,

aber das Audio gehört.

das ist natürlich ein bisschen,

das ist oft,

auch bei,

bei vielen,

bei vielen Talks ist das Audio oft relativ schlecht,

sodass,

entweder muss ich dann das Lautstärke sehr hoch drehen,

oder man versteht halt manche Verhältnisse.

wir wissen ja,

du bist ein bisschen picky,

was das angeht.

kann sein,

aber das ist halt auch,

das ist halt,

das ist ein Fluch,

wenn man sich damit beschäftigt,

dass man das dann plötzlich hört,

wenn's nicht gut ist,

aber das,

was wirklich schrecklich ist,

war teilweise kaum zu verstehen,

weil so viele,

viele Nebengeräusche dabei waren.

aber von inhaltlich sehr interessant.

ich mein,

das ist natürlich auch total toll,

dass man da mal irgendwie,

halt so,

zumindest hier der,

wichtigsten,

Entwickler von Programmiersprachen,

die halt das,

was wir hier so tun,

also einen großen Teil von dem,

was Leute so machen,

wesentlich geprägt haben,

halt dann die einen oder anderen alle zusammensitzen,

und dann halt darüber reden,

wie sie das so sehen,

was so diverse Dinge angeht,

und das war,

das war schon sehr interessant.

kann ich nur empfehlen,

sich das mal anzuhören,

ist toll,

Den Freund,

hab ich noch nicht geschafft,

tatsächlich,

reinzuführen.

ich weiß nicht,

ob es da irgendwas gibt,

was man da,

muss man sich einfach mal anhören.

das fand ich,

also als,

Geschichte,

die jetzt gerade passiert ist,

die man sich mal angucken kann,

irgendwie sehr nett.

Ansonsten,

weiß ich nicht,

was gab es noch alles für News-Geschichten?

Django 1.1 ist End of,

End of Life,

das ist auch,

dass das irgendwann passieren wird,

ist klar,

aber es,

jetzt ist tatsächlich die letzte,

Python 2 unterstützende Django-Version weg.

Das heißt,

Python 2 ist wirklich auch bei Django so,

endgültig raus.

das heißt,

wenn man da noch irgendwie auf so einer Long-Time,

Support-Version gesessen hat,

dann ist jetzt auch mal Zeit,

da irgendwie was dran zu machen.

ne andere,

Geschichte war noch,

ich verwende meistens PyTest statt,

dem Unit-Test-Modul für,

und Unit-Test-Mog für Mocs,

für die normalen Tests,

eher PyTest,

weil ich das angenehmer finde,

weil bei Unit-Tests gibt es so ein paar,

wenn man,

wenn man Test-Case-Klasse zum Beispiel aus dem Unit-Test-Modul verwendet,

so ein paar Dinge,

die ich so ein bisschen komisch finde,

wie halt diese,

Camel-Case-Notation,

das kommt halt alles auch so ein bisschen,

ich glaube,

das ist halt auch irgendwie sehr inspiriert von JUnit,

das ist halt,

ist halt so ein bisschen komisch,

das hinzuschreiben,

ich meine,

man gewöhnt sich zwar auch dran,

aber es ist irgendwie,

PyTest hat halt eine sehr schicke Art,

wie man,

wie man Fixtures halt definieren kann,

das heißt,

wie man sozusagen die,

so Test,

temporäre Testdaten,

die man sich dafür generiert,

um halt einen Test ausführen zu können,

wie man die halt,

so baut,

dass sie für die Fixtures passen,

und nicht für die reale Welt.

genau,

und die kann man auch schön verschachteln,

und auch voneinander abhängen lassen,

und so,

und das funktioniert eigentlich ganz,

das ist halt,

ist halt nett,

und man,

und dass man halt irgendwie direkt Assert verwendet,

und nicht irgendwie Methoden,

die man dann auf,

weil man halt bei diesen Methoden sieht man nie so direkt,

was passiert bei dem Assert,

ist halt klar,

dass da nicht noch irgendwie versteckt,

was schief gehen kann,

da ist nichts mehr,

das ist halt,

also insofern PyTest,

mag ich,

mag ich durchaus,

lieber,

das Projekt hat halt irgendwie so auch,

ist ein bisschen in unruhiger Fahrwasser,

es gibt da,

irgendwie,

hat irgendwie vier Mentainer,

und jetzt sind drei davon weg,

das ist viel,

das sind 75 Prozent,

das sieht nicht so gut aus,

keine Ahnung,

wird das geforkt?

keine Ahnung,

vielleicht gibt es dann,

vielleicht ist es irgendwas anderes,

vielleicht,

aber ich,

das ist halt,

das ist jetzt natürlich,

für mich ist das halt blöd,

weil jetzt,

oder ich meine,

für alle,

das ist natürlich insgesamt halt blöd,

weil jetzt muss man sich natürlich überlegen,

was machen wir denn jetzt?

ich hoffe mal,

dass sich das alles irgendwie,

zum Guten wendet,

das ist natürlich so ein Problem generell,

bei Open Source-Geschichten,

wie stellt man das eigentlich sicher,

dass so ein Projekt nicht irgendwie,

plötzlich kaputt geht an irgendwas,

da meine ich einige Sachen so ein bisschen nervig,

ich habe ja PyEnv,

auch sehr lieb gewonnen eigentlich,

auch von dir,

hast ja den schönen Tipp gegeben,

und das habe ich dann auch auf Windows zum Laufen gebracht,

tatsächlich,

das ist aber sehr schrottig in Visual Basic implementiert,

diese Windows-Variante,

war nicht so super-maintained,

ich habe es jetzt aber hinbekommen,

indem ich mir einzelne,

unbeantwortete Pull-Requests gezogen habe,

die Funktionalität so wiederherzustellen,

dass man damit einigermaßen arbeiten kann.

Aber ja,

sowas ist dann ein bisschen ein Gefrickel.

aber ich würde sagen,

News hast du noch ein,

hast du noch was?

lass mal schauen.

Also außer,

dass jetzt alles online ist,

was wir schon wissen.

ansonsten,

ich habe hier noch einen Punkt,

mir aufgeschrieben,

weil das halt auch vielleicht für andere interessant ist,

halt so,

es gab,

ein paar Artikel zu,

Django-Architektur.

Ich weiß nicht,

ob wir dieses Fass aufmachen wollen,

vielleicht lassen wir das auch einfach zu.

du meinst für heute,

du meinst,

weil wir,

ich schon,

Fat Models und so weiter.

Genau,

genau,

das wäre sozusagen,

Service Layer und dieser ganze Kram,

vielleicht.

wir wollten unbedingt dringend drüber reden.

was eigentlich,

wann ist eigentlich das Django-Metap-Colon?

das war schon,

das war jetzt,

glaube ich,

am Dienstag.

Das war,

dann habe ich es verfasst.

Du auch?

Ich auch,

aber ich konnte Dienstag halt nicht,

das war,

ich auch nicht.

so ist das.

ich würde sagen,

das verschieben wir auf irgendeine Django,

Django-Folge.

Django-Reden.

Wir reden jetzt übrigens über Django-Backend und JavaScript-Frontend.

Genau.

Wir sind beim Thema angekommen,

Leute,

das ist unglaublich.

manchmal dauert das halt so ein bisschen,

da muss man sich auch die Zeit nehmen,

da auch mal irgendwie,

Möchtest du jetzt unseren Hörern vorschreiben,

wie sie unseren Podcast hören sollen?

dann gibt es halt die Kapitelmarken

und da kann man sich das dann ja,

Also Leute,

Kapitelmarken gehen so,

ihr klickt so lange auf weiter,

bis ihr das hören wollt,

was ihr hören wollt.

Oder auf zurück,

um es immer nochmal zu hören,

was euch besonders interessiert hat.

Ihr könnt sogar bei bestimmten Podcast-Klienten

das auf Dauerschleife,

setzen.

Und zum Einschlafen benutzen.

Genau.

wie kamen wir eigentlich auf diese Frontend-Geschichte?

Wie kam,

wie sind wir eigentlich auf den Hund gekommen,

sozusagen?

Was ist,

oder was,

was ist dein,

wir entwickeln ja relativ viel Web-Zeugs

auch Dango natürlich,

Flask,

aber hauptsächlich Dango.

das muss man ja,

wenn man nicht die Dango-eigene Template-Engine benutzen möchte,

was man natürlich machen kann,

für so grundsätzliche HTML-Singer mit CSS

und ein bisschen Bootstrap vielleicht,

funktioniert das ja wunderbar.

wenn man so ein bisschen größeres Projekt machen will,

dann ist es halt häufig so,

dass man Dango mit einem Frontend benutzen möchte,

einem Framework.

da ist dann Vue drin,

oder React,

oder Angular.

Dango wird auch noch,

ohne Kopf,

also Headless benutzt

und dann per APIs angesprochen.

da gibt es immer so ein paar Fallschritte,

wie man das implementiert

und was da überhaupt,

alles dazugehört.

worüber redet man da überhaupt?

Was heißt denn der ganze Quatsch?

und diese ganze JavaScript-Welt

ist ja gerade für Python-Entwickler

erstmal so ein bisschen

ein Buch mit sieben Siegeln.

es gibt da einige Backend-Entwickler,

die sagen,

Frontend,

aber wenn man da so ein bisschen drin ist,

merkt man so,

das ist gar nicht so einfach,

wie man früher vielleicht dachte,

sondern das ist tatsächlich ein ganz schöner Stack.

und da muss man auch ganz schön was können.

Das ist ganz schön was wert,

wenn man ein guter Frontendler ist.

wenn man irgendwann mal

diese Full-Stack-Richtung möchte,

dann muss man das mit Sicherheit auch mal

zumindest so gesehen haben,

dass man weiß,

was man da tun könnte.

vor allen Dingen,

muss man das Frontend ja

auch irgendwann mit seinem Backend

wieder zusammenschnüren können.

Das heißt,

man muss zumindest ja dann die Schuhe zubinden

und das irgendwie auf den Server packen,

dass das dann auch beim Kunden

oder bei einem selber auf dem Server irgendwie rennt

und nicht wieder auseinanderfällt.

Und wie man das alles macht,

das wäre doch eigentlich mal ganz interessant,

so ein bisschen zu besprechen.

genau.

bei mir ist es,

ist es so,

vor allen Dingen,

dass ich,

ich meine,

genau,

mir schon immer mal View angucken wollte

und jetzt,

kam dann irgendwie so ein Ding vorbei,

ob ich nicht,

ich hab mich dann in,

in diversen,

View-Meetup-Gruppen,

irgendwie so angemeldet,

aber da ist dann irgendwie nichts passiert.

Die Anmeldung ist immer das Wichtigste.

Ich hab auch so eine Meetup-Gruppe.

Da melde ich mir ganz viele Leute an,

die kommen aber nie.

ich hab 50 Leute,

ist die,

für bezahlte Leute,

die Grenze,

die man erreichen darf,

an Anmeldung,

bevor es,

noch teurer wird.

ich hab halt wirklich 50 Leute in der Gruppe drin,

das füllt sich immer wieder auf,

also wir machen Computerspiel-Unse,

und es sind drei Leute immer da.

genau,

das passierte nicht,

sondern dann gab es irgendwann so den,

dieser,

irgendwie diese Gruppe ist nicht mehr mehr intent,

möchtest du das nicht übernehmen,

und dann hab ich dann einfach irgendwie,

ohne darüber nachzudenken,

einfach auf,

warum nicht,

geklickt.

Und jetzt muss ich mal überlegen,

was ich damit mache,

aber ich wollte ja sowieso Vue lernen,

also das wäre auch noch so eine Idee,

dass man das eventuell,

das wäre einfach eine virtuelle Vue,

Django,

weiß ich nicht,

oder Gruppe draus machen,

wo man da halt vielleicht mal so ein bisschen interaktiver versuchen könnte,

rauszukriegen,

wenn man das Ganze so benutzt.

muss man mal überlegen,

aber das wäre halt auf jeden Fall eine Möglichkeit.

aber Vue ist sowieso,

also aus diversen Gründen,

was ich mir jetzt mal demnächst näher angucken möchte.

Was denn auch,

also ich finde das so,

diese Komponenten finde ich sehr intuitiv,

schön,

das hast du aber auch überall,

das hast du,

das hast du eigentlich inzwischen,

also das ist keine,

wirklich so schön?

Das ist keine,

also ich muss gestehen,

ich hab mir Angular nur so ein bisschen angeguckt,

und React hab ich noch gar nicht gesehen,

aber ich finde das mit Vue,

die Komponenten hervorragend.

vielleicht erzählen wir erstmal so die,

was das überhaupt ist,

was das überhaupt macht,

was das denn so ein Frontend-Framework,

genau.

also gerade für uns,

das ist erstmal so ein bisschen Overhead,

man installiert sich dann über,

NPM oder wie auch immer,

also Node.js,

was man da macht,

dann dieses Paket von Vue,

und startet dann mit Ucreate,

ein Projekt,

und es werden erstmal 20.000 Pakete,

aus dem Repositorium gezogen,

und als Modul irgendwo hingepackt.

das ist halt,

das ist so ein bisschen JavaScript,

das gibt's halt keine Standard-Libriothek,

und dann muss da halt,

wie alles,

an Abhängigkeiten bis ganz runter geholt werden,

was man irgendwie brauchen könnte,

und das ist natürlich eine sehr unterschiedliche Menge.

Das ist schon,

so ist es halt.

Ich kann,

kann jetzt auch nichts mehr dran machen.

also die,

die Unterschiede,

ich glaub,

also die,

die drei großen,

so eben Vue,

React,

Angular,

oder ich würde eher sagen,

React ist das größte Ding zur Zeit wahrscheinlich,

Angular und dann Vue,

oder wie auch immer,

ist ja auch egal,

die kann man alle benutzen,

die sind alle gut,

so wahnsinnig,

groß sind die Unterschiede ja jetzt gar nicht.

Ist es nur so,

für mich,

ist Vue deswegen interessanter,

weil halt es nicht irgendwie,

sozusagen,

spielt,

dass das Projekt irgendwie von einer Firma ist,

sondern es ist halt sozusagen unter den dreien das einzige Open-Source-Projekt in dem Sinne.

ich meine,

natürlich ist auch Angular und React ist irgendwie Open-Source in dem Sinne,

dass es halt jetzt sehr gut verfügbar ist,

aber wenn ich jetzt,

da irgendwas dran,

lernen möchte,

oder möchte,

dass sich das mehr in eine Richtung entwickelt,

die nützlicher für mich ist und nicht so sehr für,

für Facebook,

dann kriege ich meine Pull-Requester ja doch nicht durch,

weil die bei Facebook da drauf sitzt und,

oder weil bei Angular ist es halt Google drauf und die entwickeln das halt.

das heißt,

das ist halt vor allen Dingen an die Bedürfnisse von denen angepasst und,

da sehe ich bei Vue zumindest die Chance,

dass das halt,

so ist,

weil ich glaube nämlich tatsächlich,

dass die Anforderungen von,

von Firmen wie,

wie Facebook oder Google halt,

unter Umständen ein bisschen anders sein könnten,

als das,

was halt so man braucht,

wenn man jetzt halt,

nur so ein bisschen,

aus kleineren Rahmen,

irgendwie Dinge hochzieht.

nicht,

der kann klotzen,

Junge.

genau,

warum nicht das nächste,

genau,

einfach Google-Konkurrenz.

also es ist,

daher denke ich,

ist Vue so für,

unabhängige Leute irgendwie schon die interessantere,

das interessantere Projekt,

keine Ahnung,

kann auch vollkommen falsch sein,

wer weiß.

jedenfalls,

wenn man sich,

wenn es halt eh mehr oder weniger egal ist,

dann kann man ja vielleicht das mal verwenden.

React und Angular habe ich auch schon so ein bisschen mit,

Dinge gemacht.

React hat mir tatsächlich ziemlich gut gefallen,

Angular,

nicht so richtig,

ehrlich gesagt.

Und warum?

Und was,

was ist das überhaupt?

Und was macht man da?

vielleicht erklärst du nochmal so einen ganz Anfänger,

was das denn überhaupt ist und wie man das so macht.

der Witz daran ist eigentlich,

das ist die Frage,

wo man ansetzt.

Man könnte natürlich sagen,

zunächst einmal gibt es halt nur so Standard-Web mit,

irgendwie HTML,

CSS und JavaScript eigentlich mehr oder weniger nur so als,

unterstützt halt,

irgendwie bestimmte visuelle Geschichten oder so.

Und dann irgendwann kam halt mit,

da hat der Internet Explorer halt diese XHTTP-Request,

Geschichte mit eingeführt.

Und damit wurde es dann halt interessant.

Das Ganze lief dann so in Richtung,

das lief dann halt unter dem Stichwort Web 2.0,

weil jetzt halt Webseiten ohne eine komplette Seite neu rendern zu müssen,

halt Dinge auf der Seite ändern konnten.

Und dann hat man da irgendwie so ein bisschen dann die,

die Browser-APIs waren alle unterschiedlich.

Dann gab es halt eine Bibliothek,

die halt dann irgendwie die unterschiedlichen Browser-APIs halt unter einer,

gemeinsamen API,

angesteuert hat.

Und das war dann jQuery,

das war sozusagen die Standard-API,

die man dann verwendet hat.

könnte man dann fragen,

jQuery,

super,

dann ist aber alles,

perfekt,

alles tutti,

warum verwendet man das nicht heute immer noch?

Und da ist die Antwort im Grunde,

das wurde halt immer komplexer und irgendwann kriegst du halt,

wenn die Applikationen,

also ich,

ich würde sagen,

tatsächlich für kleinere Geschichten kann man das auch immer noch so machen.

Eigentlich ist das gar kein Problem.

also eine,

eine Geschichte,

die halt dann irgendwann schwierig,

ist halt,

wenn man jetzt,

wenn man jetzt ganz viel,

State halten muss,

also wenn man jetzt eine Seite hat,

auf der viele komplexe Sachen passieren,

dann ist halt die Frage,

wie merkt man sich jetzt eigentlich,

was man alles tun muss,

wenn jetzt jemand per Drag-and-Drop irgendwas irgendwo hinzieht oder so,

Wo gehen überall die Counter rauf und runter?

wenn irgendein Event passiert,

geht da noch eine Notifikation an?

Wie diese,

dieses,

das wird dann halt,

wenn die Applikation sehr komplex wird,

oder die Webseite sehr komplex wird,

dann wird das halt irgendwann sehr,

sehr unübersichtlich,

wenn man das halt in,

Query macht.

Also State,

nochmal für,

für unsere Ganzanfänger,

ist der Zustand,

den ein Benutzer irgendwie erreicht hat,

den er irgendwann wieder sehen will.

eher State ist halt sozusagen der Zustand der Seite.

den musst du ja selber handeln.

Also wenn du nur HTTP machst,

quasi,

dann ist der immer am Server.

Da ist es einfach.

weil Request,

Response.

Genau.

Aber wenn du jetzt sozusagen nicht nur das machst,

sondern du machst halt auch noch irgendwie,

XHTTP,

das heißt,

du schickst irgendwas zum Server,

merkst du halt so,

musst du halt dann irgendwie merken,

ich hab das jetzt schon da gespeichert

oder musst du halt merken,

ich hab's halt noch nicht gespeichert.

Also das ist schon beim Server,

das noch nicht,

aber trotzdem hast du ja vielleicht schon

irgendeine Aktion gemacht.

diesen,

diesen State.

Fehler,

Serververbindung abgebrochen.

diesen State musst du jetzt irgendwie verwalten

und den verwaltest du dann halt nicht mehr nur

auf dem Server,

sondern halt auch auf dem Client

und das geht dann halt irgendwann nicht mehr

so richtig gut mit,

JQuery,

weil das ist ja auch dann,

du hast das ganze Zeug ja irgendwie dann

in so JavaScript-Files,

du hast nicht so richtig Module oder so.

geht alles nicht so,

also du kannst natürlich schon

unterschiedliche Files haben,

es ist halt irgendwie,

mit JQuery wird das halt irgendwie nix,

ab einem,

ab einem gewissen Komplexitätslevel

und im Grunde diese ganzen Frameworks

sind halt alle,

dafür gebaut,

um dieses,

mit diesem Problem umzugehen,

sag ich mal jetzt,

als jemand,

der eigentlich,

ehrlich gesagt,

keine Ahnung von diesem ganzen Kram hat,

aber so aus meiner Perspektive,

von außen,

so grob,

das ist absichtlich ein bisschen geflüstert,

es ist,

es ist schon so,

eigentlich ehrlich gesagt,

es ist ein bisschen außerhalb von dem,

was ich normalerweise mache,

daher,

keine Ahnung,

vielleicht rede ich auch großen Unsinn gerade,

überprüft das,

schlagt das nach,

und schreibt es uns in die Kommentare,

genau,

während jetzt man in JQuery zum Beispiel den,

dieses,

den DOM,

also sozusagen die Baumrepräsentation der Webseite im Browser direkt manipuliert,

macht man das halt in,

React View,

wie auch immer,

üblicherweise nicht direkt,

sondern,

in einer,

Shadow DOM,

oder keine Ahnung,

der Schatten DOM,

das macht man,

da gibt's immer Leute,

die sagen,

so viel schneller,

direkte DOM-Manipulation ist halt viel schneller als irgendwie so virtuellen DOM,

irgendwie,

was einem das halt erlaubt ist,

dass man das halt,

trennen kann,

den State in dem Gerinnerten von dem,

was man halt,

wo man die Manipulationen macht,

und das ist natürlich,

unter Umständen sehr wertvoll,

ich würde sagen,

kannst du noch ein Beispiel dafür nennen,

was passiert jetzt,

wenn man jetzt einen Schatten DOM,

also das Dokument,

das Dokument-Objekt-Model,

also irgendwie das,

was da,

hinter steckt,

hinter der ganzen gebauten,

die Idee ist so ein bisschen,

dass du halt die Manipulationen da in deinem Schatten-Dings,

da machst du dann nur,

guckst,

du diffst das halt nur noch dann sozusagen gegen das,

was du,

und dann machst du halt,

erzeugst du,

oder machst die,

die eigentlichen DOM-Manipulationen,

halt dann,

aus dem Diff zwischen dem,

was du eigentlich,

seinen virtuellen DOM,

zu dem realen,

sozusagen,

aber du manipulierst den realen nicht tatsächlich,

also du könntest ja auch,

sozusagen,

du kannst ja auch deine ganzen Daten im echten DOM halten,

könntest du ja,

du kannst ja das in Attribute von irgendwelchen Elementen reinschreiben,

oder so,

aber das ist,

nicht so schön,

da baue ich lieber einen Schatten drum,

verstehe,

keine Ahnung,

also es ist,

ich bin da auch nicht der Beste,

um das,

um das zu erklären,

glaube ich,

jeden,

jedenfalls,

heutzutage kann man für das,

was man früher mit JackRary gemacht hat,

auch einfach irgendwie React oder Vue oder so verwenden,

das geht natürlich alles,

man kann damit natürlich auch noch mehr machen,

das ist zum Beispiel eine Geschichte,

die halt,

in letzter Zeit,

sehr populär geworden ist,

wobei ich auch mal sagen würde,

man muss ein bisschen vorsichtig sein,

dass man da nicht zu sehr,

in diese Hype-Falle tappt,

weil das hat halt auch,

also die Trade-Offs sind nicht so ohne,

also das ist,

das sind halt so Single-Page-Apps,

dass du sozusagen,

alle Komponenten direkt mit ausgeliefert sind,

in JavaScript hast und nicht mehr,

also praktisch gar keine,

Requests mehr machst,

die halt da zu einem Reload der Seite führen,

dass du ja,

sondern immer nur noch über die API,

also deswegen Django Headless und REST,

Single-Page-Application und,

asynchrone

Fragen an den Server

über JavaScript.

du kannst,

man kann das,

also früher hat man das dann,

hatte man da immer noch so ein gewisses Problem,

dass man,

das dann halt unter einer URL hatte

und dass die

Zurück- und Vorbuttons

irgendwie nicht richtig funktioniert haben,

aber es gibt da,

ich weiß jetzt gar nicht,

wie die heißt,

die API,

es gibt eine Browser History,

sonst was API,

und die ist mittlerweile auch stabil in allen Browsern

drin und das heißt, man kann auch

ordentliche URLs

haben, ordentliches URL-Routing

und Back- und

nach vorne Buttons und so,

das funktioniert alles und wenn man links klickt,

dann, ne, das klappt alles

inzwischen super, man muss halt nicht mit irgendwelchen komischen

Hashtag, irgendwie

Anchor-Tag-Dingern

irgendwie rumspielen, wobei das glaube ich

Vue auch in der Default-Konfiguration noch

so macht, das muss man halt irgendwie dann umstellen.

Also, das sieht dann aus

wie eine Webseite und

fühlt sich so an wie eine ganz normale Webseite, aber in Wirklichkeit

ist es so, das wird nie wirklich

neu geladen, sondern die wird immer nur

umgebaut, basierend auf dem, was

die JavaScript

Also die ganze Arbeit macht der Klient direkt

vor Ort. Genau,

da wird es halt auch sozusagen gerendert, ja.

Was halt viel schneller ist, weil so ein

kompletter Page-Reload, wenn das halt kompliziert

ist, also wenn ich, und allein das reicht

eigentlich schon, wenn das irgendwie Bootstrap und all möglichen

Kram drin ist, dann ist

es so fett, dass halt, wenn man

bei einer

Server gerenderten

Seite halt irgendwo auf den Link klickt und das dann neu

rendert, dann merkt

man das eigentlich immer, weil

auch wenn der Request selber schnell ist,

so oft ist es so, dass

tatsächlich irgendwie

alles, auch inklusive

Assets, halt innerhalb von, weiß ich nicht, 200 Millisekunden

zurückgekommen ist, dann denkt man sich so, ja,

das ist so schnell, dass man es eigentlich fast

nicht merken sollte und trotzdem

bemerkt man es und der Grund, warum man es trotzdem bemerkt, ist

halt, dass

das Rendern vom DOM

ist halt nicht so schnell. Das dauert

halt und selbst wenn da nichts mehr im Netzwerk

passiert, ist es so, dass

allein, dass der Browser das alles neu aufbauen

muss, das dauert

halt und das merkt

man und das ist halt nicht so flüssig wie eine native

App, die jetzt halt irgendwie auf dem Rechner

läuft und die nicht, ja,

also die nicht komplett neu gerendert werden muss. Und wenn man

das jetzt in JavaScript sozusagen hat,

die Applikation, und dann sich sozusagen

eine neue Seite immer nur neue Daten

geholt werden von der API und man kann

dann ja auch so, also wenn man zum Beispiel eine Liste hat, wo man

irgendwie so durchpaginiert oder so,

dann kann man sich ja auch für die nächsten drei, vier Seiten

die Daten schon mal geholt haben und dann drückt man

auf den Knopf und dann wird halt nur

der, wird halt nicht

das komplette

Template außenrum alles nochmal neu gerendert,

sondern dann wird halt nur der Inhalt der Tabelle, die man halt

da sieht, irgendwie vielleicht ausgetauscht.

Und das ist dann halt sehr schnell und das geht dann halt,

das sind halt so wenige,

ich weiß nicht wie viele Millisekunden, aber so

unterhalb der Wahrnehmungsschmelze,

man drückt da drauf und es ist sofort,

es hat sich sofort geändert.

Und das ist natürlich

sehr nett. Das ist halt etwas, was man mit

vom, auf einer Server

Seite gerenderten Webseiten

nicht hinkriegen kann eigentlich.

Es fühlt

sich halt viel mehr an wie eine native App.

Und das ist natürlich schon schön und gerade für kompliziertere

Geschichten ist das

ist das natürlich,

ist das natürlich schon sehr nett.

Also die sich halt mehr so wie

klassische Applikationen auf dem Desktop anfühlen sollen.

Und ja, das ist natürlich

alles schön. Warum macht man nicht alles so?

Man kann die Dinge auch dann

irgendwie quasi direkt auf

Mobilgeräte und so deployen.

Und so ein bisschen

so diese progressive Web App

Geschichte, sie sehen dann halt auch so ein bisschen aus wie

normale Apps, wie so native Apps auf

Telefon und so. Warum macht man nicht alles so?

Es hat halt auch diverse böse

Nachteile. Ein böser Nachteil ist,

dass halt SEO,

Google Suchergebnisse,

Single Page App, das funktioniert halt einfach nicht so gut.

Was auch nicht so schön ist, ist halt,

dass der erste Request unter Umständen sehr, sehr langsam ist,

weil da halt irgendwie tatsächlich vielleicht

megabyteweise JavaScript und anderer Kram

irgendwie geladen werden muss.

ja. Das hört sich so mittelgut

an für Menschen. Genau, das ist halt,

also ja, wahrscheinlich

es kommt ja darauf an, was man für ein Problem hat.

Für manche Probleme ist halt irgendwie

eine klassische Server-Seite,

seitlich gerenderte Geschichte das allerbeste.

Für manche andere Sachen ist halt

irgendwie eine Single Page App besser.

Aber, dass das überhaupt so geht

und dass man das machen kann, ist eine relativ neue

Geschichte und das

das ist auch etwas, das man halt mit diesen

Frameworks halt

gut machen kann.

Was man jetzt mit jQuery nicht machen könnte.

Wobei,

ja, doch, so,

vielleicht geht es da sogar, ich weiß es nicht genau,

aber es macht halt, ich weiß nicht, ob es irgendjemand macht,

könnte man vielleicht sogar auch, aber

es, naja, vielleicht keine so gute Idee.

Ja, die, genau,

Unterschiede,

also so React,

es gab ja früher nochmal sehr große

Unterschiede, also tatsächlich

die ersten

JavaScript

Frameworks, die halt dieses Problem

insgesamt angenommen haben,

die waren sehr unterschiedliche Ansätze,

da gab es halt irgendwie dieses Angular 1 halt,

das war eins der ersten,

also war vorher React auch da,

dann gab es irgendwie Ember und so

dann aber React

hatte irgendwie alles so ein bisschen geändert. Das war halt so

das erste,

einen sehr neuen Ansatz

hatte, so diese,

wie soll man das beschreiben, eigentlich

eher einen funktionalen

Ansatz, dass man halt sozusagen den,

die, die, die,

also das,

die, die,

die Visualisierung der Seite

erzeugt irgendwie,

indem man State hat und da einfach

dann Funktionen drauf ausführt,

die das dann halt

hinrendern.

dass man halt nicht

sozusagen irgendwelche Templates hat,

so HTML, man kennt das von

Django vielleicht oder sonst wie von

einer serverseitig gerenderten Geschichte,

ähm, wo man,

wo halt dann irgendwie, äh,

Sachen ersetzt werden,

ne, so man hat halt irgendwie HTML oder so

mit Platzhaltern für, da kommen jetzt

dynamische Sachen rein, sondern

in, äh, React

ist es eher umgekehrt, äh,

du hast halt, äh, zwar etwas, das so ein bisschen

aussieht nach, äh,

nach HTML und Template,

aber das ist es gar nicht in Wirklichkeit,

sondern in Wirklichkeit ist es einfach nur eine Funktion.

Und, äh,

diese Funktion

rendert halt,

rendert sich selbst raus zu HTML

oder zu irgendwas, was halt irgendwie im DOM

angezeigt werden kann.

Und, äh, dieser Ansatz

hat sich dann durchgesetzt. Das machen jetzt inzwischen

alle anderen auch so. Und, ähm,

äh, tatsächlich, also,

ich fand React jetzt, äh, ist jetzt

auch schon wieder ein bisschen her.

Äh, inzwischen,

ich hab nie mit Hooks irgendwie was gemacht.

Das, äh, also, ähm,

man muss eigentlich viel zu viel erklären.

Das ist, äh,

äh, also, man kann sagen, also, React

hat mir eigentlich ganz gut gefallen. Äh,

es ist eigentlich gar nicht groß, ist auch eher so ein,

kleine Geschichte, äh, aber es gibt

natürlich ein riesen Ökosystem drumherum.

Äh, und, ähm,

ja, Angular

fand ich, ehrlich gesagt, es ist deutlich fetter.

Äh, und,

mit gewissen Sachen bin ich nie so richtig,

also, man muss relativ viel Boilerplate

außenrum schreiben und es passieren

komische Sachen manchmal. Aber, ich meine,

kann man auch verwenden. Also, letztendlich

nimmt sich das alles nicht viel. Das ist halt auch so ähnlich.

Und, ähm,

jetzt, äh, Vue ist, glaube ich, auch so ähnlich.

Das ist auch kein großer Unterschied, ne?

Äh, außer jetzt diese, diese

URL-Routing-Geschichte, die bei Vue noch so

ein bisschen komisch ist, aber, äh,

naja, äh,

ansonsten, weiß ich nicht, was, äh,

ist das, hm, was, was,

was wäre da noch so interessant?

einzelne Frameworks jetzt.

Ja, ich, ehrlich gesagt, keine Ahnung.

Ja, also, du kannst, du kannst so eine News-Story hast, wo, wo halt,

wie genau das ist, na, hey, in dem Case ist jetzt Angular

total super und da lieber Vue

und da lieber Vue, sondern die sind alle

auszutauschbar. Das heißt, wir können mit Python tatsächlich

jedes davon entnehmen. Die Frage ist aber, wie man

das implementiert, weil, wenn du jetzt versuchst, jetzt in der

Django-App einfach so, äh,

ein JavaScript-Framework,

einzubauen, dann wirst du vor einige

Probleme kommen, weil du halt

diese dynamische Entwicklung gar nicht richtig

machen kannst. Oder

die Features der, äh, ganzen Frameworks gar nicht.

Ja, du musst halt irgendwie mit dem Backend

kommunizieren. Also, dieses Problem hast du natürlich weiterhin,

dass du, äh, irgendwie,

ja, äh,

irgendwo die Daten dann tatsächlich in der Datenbank

halten willst und du musst halt irgendwie, äh,

ja, die da

reinkriegen und die da auch wieder rauskriegen und so.

Und gut, vom Server kommt jetzt dann

nicht mehr HTML, sondern da kommt dann halt eher

irgendwie JSON oder, äh, ja,

also eigentlich immer JSON, aber

äh, gibt's halt auch unterschiedliche APIs,

die beiden, ja, Hauptgeschmacksrichtungen,

die es da gibt, sind halt,

äh, ja, REST oder,

oder eben GraphQL.

Etwas neuere Geschichte.

Ähm, nimmt sich aber

letztlich auch gar nicht

so wahnsinnig viel fürchtig. Aber jetzt auch,

ich hab, ich hab angefangen mit REST und dann,

äh, das lange gemacht und dann,

ähm, ist halt dann GraphQL, fand ich dann ganz gut

und, äh, bin jetzt,

bin inzwischen wieder bei REST.

Es gibt Leute, die machen dann auch irgendwie, die sagen,

naja, gut, also GraphQL zum Lesen

ganz gut, äh, zum Schreiben vielleicht nicht so,

äh, und schreiben dann über REST und, und lesen

über GraphQL. Naja,

also, aber, äh,

letztlich ist es ja auch, äh, ist es ja auch

egal, äh, auf jeden Fall,

der Teil geht so ein bisschen... Ja, aber eben, man braucht halt dann eine API

dann, ne, dann, dann bleibt bei Python nur noch die,

das Bereitstellen der API übrig und

das ganze Frontend-Trainering fällt weg.

Ja, nur noch... Ist das auch bei Async Django so?

äh, Async Django ist jetzt

eine andere Geschichte

oder wie man... Ja, warum ist das

eine andere Geschichte? Dann habe ich wieder Unsinn erzählt.

Ne, also, Async heißt ja eigentlich

nur, dass du so, dass du

nicht,

das Protokoll zwischen Applikations-Server

und, äh,

ähm, dem

Web-Server außenrum ist jetzt halt

ein anderes und es geht nicht nur,

es geht nicht nur Request-Response, sondern du kannst halt

auch, du kannst halt in beide, diese ASGI, du kannst halt

in beide Richtungen, du kannst halt auch vom Server

Sachen an kleinen schicken, das ist halt schon mal ein großer Unterschied.

Genau. Und, ähm,

es ist halt auch so, dass, äh,

du, ähm,

fürs IEO-Multiplexen

das nicht nur über Threads und Prozesse

machen kannst, sondern du kannst es halt auch über,

äh, einen Event-Club machen.

Äh, und so, also

wie Node.js auch.

So, das ist halt so der große, aber das ist,

pff, das, äh,

wirkt sich jetzt auf, was man, auf, auf,

AP oder nicht AP, das wirkt sich alles darauf gar nicht aus.

das geht beides, also.

Ja, okay,

das heißt halt trotzdem, ich mach dann halt meine, äh,

AP und

ob die ASGi ist oder nicht, macht halt gar keinen großen Unterschied

mehr, weil, ähm.

Naja, doch, also, äh, also,

es gibt, wenn du, es gibt natürlich schon

einen gewissen Unterschied,

was halt mit

Django sonst nicht so richtig gehen würde,

ist halt, dass du vom

Server, äh, Benachrichtigungen bekommen kannst.

Das geht halt nicht so richtig. Also, ich meine,

du kannst natürlich emulieren, du kannst halt irgendwie

alle 100 Millisekunden nachfragen,

gibt's jetzt irgendwas Neues oder so,

dann kannst du es halt wahrscheinlich so ein bisschen,

aber du kannst halt nicht eine stehende,

also wenn du jetzt zum Beispiel einen Chat,

wenn du sowas wie Slack nachimplementieren

wolltest, das geht

nicht so richtig gut mit Django, ohne Async.

Weil, äh, wie soll das gehen?

wenn jetzt jemand was schreibt und das,

die Webseite will dir das

anzeigen, wie macht sie das?

Ja, die Webseite fragt die ganze Zeit nach, was ist in dem Channel,

was ist in dem Channel, was ist in dem Channel, was ist in dem Channel?

Aber das ist natürlich, generiert einen riesen Haufen

Requests, die alle völlig unnötig sind.

Und, ähm,

aber es funktioniert.

Ja, aber das ist ja, äh, also,

das ist ja, das ist ja super hässlich.

Also, das ist, kann man natürlich,

aber ich meine, stell dir vor, dein Rechner steht zu Hause und ist halt

Datenautobahn, die verstopfte

Leitung auf der Datenautobahn sind da schon.

Das ist gar nicht, das ist gar nicht so das Problem,

das ist halt eher so, du machst dir

die ganze Zeit Requests, also,

wenn du nicht zu Hause bist und dein Rechner läuft

und der macht alle hundert Millisekunden so ein Request,

dann macht der halt, keine Ahnung, zehn pro

Sekunde und, äh,

das heißt, äh, am Tag,

äh, 86.400

äh, mal, äh,

äh, zehn, also,

fast eine Million Requests.

Und die sind alle leer. Also,

Ja, ich sag ja, Stau auf der Datenautobahn, also.

Also, ich glaube, das ist noch so

fast das geringste Problem, dass da Daten übertragen werden, aber

Server muss ja dann jedes Mal irgendwie die Datenbank

fragen und, äh, keine Ahnung.

Ja, also, äh, genau.

Ist so ein bisschen, während, wenn halt, äh,

Nicht die Computerstunden und Strom dabei verbraucht wird.

Ja, ist halt alles so ein bisschen, und das ist halt, äh,

wenn, wenn es jetzt anders gehen würde,

mit, mit Asyn geht

das halt dann, dass, äh, du, äh,

dass dann der Server dir halt

sagt, so, hier ist jetzt, zeig mal diese Nachricht an,

die hat dir jemand geschickt, dann passiert halt gar kein

Request und wird nicht, überhaupt nichts

hin und her geschickt, bis zu dem Zeitpunkt, wo

das halt passiert.

Und das ist natürlich schon deutlich effizienter. Und, äh,

eben eskaliert halt nicht.

Wenn du jetzt, äh, mit, mit 10 Leuten

ist es egal, wenn du in einem Channel bist, aber wenn du jetzt

irgendwas wie Slack betreibst, mit hunderttausenden Leuten

oder Millionen, dann

bringen dich natürlich diese ganzen Requests

irgendwann um. Und, ähm,

ja, du brauchst, da brauchst du irgendwas, was halt

irgendwie dir ermöglicht, vom

Server aus auf dem Client irgendwas zu sagen.

Also, das ist jetzt diese Asyn-Geschichte. Aber

das ist, ähm,

hat mit, äh, ob jetzt

APIs oder nicht APIs oder so, das ist alles,

und eine API kann natürlich auch Asyn sein. Du kannst

natürlich dich, äh,

aber das, aber das, das geht,

eine API oder nicht API, das geht beides.

Also, das, ja. Mit, mit was redet man denn

mit der Django-API? Macht man dann einen, einen Axios?

Irgendwie so ein JavaScript-Framework?

Oder, äh, nimmt man da einfach,

äh, normale, äh...

Also, für GraphQL gibt's halt, äh, Relay oder

Apollo. Ja.

Ähm, oder für REST gibt's dieses,

äh, ja, Axios oder weiß ich nicht,

es gibt ja unterschiedliche Geschichten, die man da verwenden kann.

Ähm, und, ähm...

Man könnte da ganz normale

AJAX-Requests machen, oder?

Ja, klar. Also, das ist, äh,

genau. Das, ja.

Ist es ja auch, du kannst auch einfach,

du könntest, du müsstest nicht REST machen.

Du kannst eben, genau, du kannst natürlich in Django,

könntest du einfach in, in, in JSON, äh,

äh, einfach an einem, an einem, äh,

XHTTP-Request, äh, oder

AJAX, äh, View machst du halt einfach,

irgendwie gibst du einen JSON-Response zurück, fertig.

Geht auch. Äh, aber,

natürlich bietet es sich schon an, das irgendwie halt

so halbwegs standardisiert zu machen, weil

das natürlich auch diverse Vorteile bringt und

man halt auch, ähm,

ja, Sachen so machen sollte, wie man

die üblicherweise so tut.

Äh, also, das, das musst du jetzt

zweimal begründen. Und zwar einmal erstmal, warum man

überhaupt Sachen so machen sollte, wie man die üblicherweise

tut. Man kann es ja einfach so machen, wenn man Lust drauf hat.

Ja, aber, das ist auch etwas, was ich halt

immer wieder sehe. Also, die meisten Leute

denken immer, wenn sie, oder denken,

oder sagen wir mal so,

etwas, was ich oft sehe, dass

Leute,

sich überlegen, wie sie denn jetzt, äh,

irgendwie Kommunikation zwischen

irgendwie einer Webseite oder einem

Client und, äh,

äh, irgendwie ihrem

Backend, äh, machen und, äh,

überlegen sich da irgendwas und denken, das ist

total kompliziert und das ist total,

sie haben irgendwie so ein Hightech-Problem, was sie irgendwie lösen müssen

und überlegen sich dann da irgendwie selber

ganz viele Sachen.

Und das ist, ich, also,

ich hab noch, also,

lass mal überlegen, ob ich das jemals gesehen habe, dass das tatsächlich

der Fall war. Ich glaube nicht.

Aber das war tatsächlich dann nie so.

Sondern es ist immer so, dass eigentlich

ist das alles immer das gleiche.

Das ist alles irgendwie,

du hast immer, äh,

es ist immer crud, ja, es ist immer so,

also, create,

create, retrieve, update und delete. Genau.

Äh, und du hast immer Listen

von Dingen und immer ein create auf der Liste

und immer dann eine Detailansicht,

auf die du dann weitergeleitet wirst oder halt

wieder auf die Liste zurück. Und das ist halt

alles immer gleich. Und ob das

jetzt dann, und das kennt man ja von

Applikationen so, ne, ob das jetzt Facebook ist, ob das

Twitter ist, die funktionieren alle ganz genauso.

Oder ob das dein Mail-Client ist,

der funktioniert auch so. Oder es ist,

äh, es ist eigentlich immer,

es geht immer so

in die Richtung. Und,

äh, die Leute, oder,

viel, man, mir ist es ja am Anfang auch so gegangen,

also, wenn man das nicht ein paar Mal gesehen hat, dann fällt

einem das halt nicht auf, dass das immer so ist.

Sondern denkt man sich so, ich muss das halt irgendwie alles selber

erfinden, aber das muss man eigentlich nicht. Und das

ist auch keine gute Idee. Weil tatsächlich dieses

crud-Ding, also, dafür gibt's halt dann,

die sich bewährt haben. Und das

funktioniert dann gut, wenn man das genauso macht.

Und wenn man das halt anders macht, dann hat man halt Schmerzen.

Und, ja.

Ja, also Fußschießen oder

Stolpernfallen, Reintreten,

große Fehler durch die Ohren zermüllen

oder mh. Ja, ja.

Aber, äh,

ja, ähm,

was, äh,

äh, genau, also, äh,

was halt auch noch interessant ist, wenn man jetzt

eine API abfragt, ist halt so,

die macht man dann eigentlich das Statement, man hat

jetzt, also, was die

bösen Trade-offs angeht, ne, nicht nur, dass das halt

irgendwie, äh, fett ist,

also, wenn man so eine Single-Page-App baut,

äh, ist es halt, äh, deutlich fetter,

der erste Request ist deutlich größer,

ähm, es ist

halt, äh, so

brittle, ich weiß gar nicht, wie man das am besten übersetzt,

ne, es ist halt so, es ist

viel instabiler, als wenn man jetzt einfach nur,

äh, ein schnödes HTML und CSS verwenden würde,

weil halt dieses ganze JavaScript funktionieren

muss, ne, es ist halt, äh, irgendwie, wenn du auf

einem Telefon bist, äh, irgendwie das schlechte

CPU hat, ist nicht so gut, wenn das auch in einer schlechten

Leitung ist, nicht so gut.

Also, ähm, diverse

üble Nachteile, ein, ein, ein,

ein weiterer, äh, übler Nachteil ist,

dass du jetzt State-Handling halt nicht

nur auf einer Seite hast, früher, also, wenn das

serverseitig gerendert wird, hast du das halt nur auf dem Server.

Und da hast du halt dein, weiß ich

nicht, äh, Framework, das,

äh, dass das halt, das dafür gebaut

ist, mit diesem Problem umzugehen, halt, weiß ich nicht,

eben auch so, wenn, wenn man das so, also,

wie alles, äh,

All-in-One-Lösungen wären dann halt sowas wie

Ruby und Rails oder halt eben Django.

Ähm, aber

dieses Problem hast du dann halt nur da und

sonst eigentlich nicht mehr. Und

wenn du bei so einer Single-Page-App hast,

dieses Problem an der Stelle dann halt auch nochmal,

das heißt, du hast halt zweimal das Problem,

dass du irgendwie mit Logik umgehen können musst

und...

Zweimal Logik umgehen heißt doppelter Anteil an Fehlern.

Ja. Und auch

doppelte Menge an Code. Doppelte Menge

an Code, bei dem irgendwas schiefgehen kann, ja, genau.

Und exponentiell wagst du, das heißt, eine vielfache Menge

an Bugs. Exponentiell weiß ich nicht, aber

äh, ja, es ist auf jeden Fall...

Je nachdem, wer das entwickelt, Jochen.

Ja, das ist...

Ich guck jetzt niemanden an.

Ich hab ja Gott sei Dank kein Spiel.

Nee, aber das ist natürlich ein Problem und das ist halt viel aufwendiger

und das ist alles viel schwieriger.

Und, äh,

natürlich, und,

die Menge an unterschiedlichen

komischen, äh, Technologien und so,

der Stack wird halt immer größer.

Und das macht's halt auch alles viel schwerer. Also, das

ist schon deutlich komplizierter als so eine

einfache Webseite. Und, ähm,

ja, das ist halt, äh,

aber auf der anderen Seite kann man damit auch coole Sachen hinkriegen,

die man sonst nicht hinkriegt. Insofern

muss man sich halt überlegen, ob sich das

für einen lohnt oder nicht. Ähm,

aber wenn man das jetzt macht, dann hat man eben genau dieses Problem.

Da kommt jetzt halt irgendwie ein State

von zum Beispiel einer API, den man

jetzt irgendwie in dem,

äh, in der, in der Applikation

verwalten, äh, können

muss. Und, äh, ja.

Oder sagen wir so,

der State ändert sich, wenn er jetzt zum Beispiel

einen API-Request zurückkommt.

Also man fragt jetzt, man hat halt irgendwie so eine

Applikation, die eine Liste von

irgendwelchen Dingen, wie auch immer, die aussehen, äh,

anzeigt und, äh,

macht jetzt einen Request an die, an die,

ans Backend und kriegt jetzt zurück, okay,

diese, diese 100 Dinger gibt es.

So, ähm, diese 100 Dinger ändern jetzt

den State der, äh,

der, der Client-Applikation.

Und wie macht man das jetzt ordentlich, ne?

Und dann, ähm, braucht man halt da auch

irgendwie sowas wie,

ja, irgendeinen Platz, wo der State

gehalten wird, ja. Bei Django

oder Real-N-Rates wäre das halt jetzt die Datenbank.

Ähm, hat man jetzt in, in,

auf der Client-Seite nicht so, aber da kann man halt

auch sowas wie so ein Redux-Store zum

Beispiel haben, wo das halt, äh,

wo man halt

den, den State hält und, ähm,

geordnete Methoden hat,

wie man darauf zugreift, wie auch unterschiedliche,

unterschiedliche Teile der Applikation auch darauf zugreifen

und wie die halt, äh, irgendwie Änderungen

daran auslösen. Und, ähm,

ja, äh,

da gibt's dann auch nette,

nettes Zusatztooling, äh,

dass man halt dann irgendwie, äh,

auch, äh,

da durchsteppen kann.

Man kann also, äh,

man kann sich halt angucken, was, wie sieht der State

aus, äh, bei

davor, danach, äh,

wie man kann auch die, die Applikation,

wenn man das rumgeschafft ist, man kann die,

äh, in jeden Zustand wieder zurückbringen,

äh, dadurch, das ist halt sowas,

äh, also React zum Beispiel ist relativ

funktional, das ist eigentlich sehr nett,

also da nie, äh,

da immer nur die Seite, der Zustand,

äh, die Seite gerendert wird aus dem Zustand.

Wenn du den, wenn du weißt,

wie sich der Zustand immer geändert hat und immer gespeichert hast,

kannst du die Seite in jeden Zustand wieder zurückversetzen.

die nennen das irgendwie da, äh,

Time Travel Debugging zum Beispiel, ne, du kannst halt,

äh, wenn du jetzt zum Beispiel,

so, da gibt's so eine, äh,

äh, Browser Extension,

äh, die

halt den, den State irgendwie die ganze

Zeit, äh, speichert, äh,

und das, äh,

mit Redux checkt und da kannst du halt,

wenn du ein bisschen auf der Seite rumgeschafft bist, die Seite

auch wieder in jeden Zustand zurückversetzen und kannst einfach sagen,

okay, nimm diesen State und dann

sagt man, äh, React einfach nur so,

okay, und zu Render halt die Seite und dann kommt genau

die Seite raus zu dem Zustand.

Und das ist natürlich schon sehr nett, also,

dass du halt, ja,

dass der Zustand nirgendwo,

irgendwie, dass da nicht irgendwie noch irgendwelcher,

irgendwelche Daten, die gebraucht werden,

in irgendwelchen

DOM-Elementen drin rumhängen oder so, sondern

die DOM-Elemente werden rein aus blöden

Funktionen, die halt State nehmen und, äh,

äh, Elemente ausgeben, rausgerendert,

sodass halt, äh,

ja, quasi immer klar ist, was passiert.

Das ist natürlich schon...

Also eine Liste von States hast du dann, um tatsächlich zu speichern,

wo du gerade bist oder warst oder sowas?

Ja, du hast halt den,

der State ist halt das,

was definiert, wie deine Seite aussieht.

Ja, okay, mhm, ja.

Und der State ändert sich halt auch.

Und es gibt halt Aktionen, die, also bei Redux ist es halt so,

du hast halt Actions, die halt den State verändern.

Und wenn du jetzt aber

den State vor und nach jeder Action

immer speicherst, dann kannst du

einfach sagen, okay, hier ist der State,

liebes React-Renderer,

alles mal so, dass es wieder wie eine Seite aussieht,

und dann ist die Seite genau in dem Zustand.

Also, um jetzt nochmal klarzustellen,

also ein State ist dann ein Gesamtstatus der gesamten

Seite und nicht der einzelnen Komponenten.

Ne, genau, der Gesamtseite.

Die Komponenten kriegen halt nur

einen Teil des States, der sie interessiert,

zu sehen.

Ja, die können dann zum Beispiel sagen, okay, ich hätte halt

jetzt gern alles an State unterhalb von,

State ist halt so wie so ein Baum,

und man ist üblicherweise immer nur an so einem Teil

davon interessiert.

Also wie das einzelne Div-Container

zum Beispiel aussuchst, den du jetzt haben willst.

Ne, das ist nicht der gleiche Baum,

wie der von der Webseite.

Das ist nicht das gleiche, ne.

Der State ist noch eine andere Geschichte.

Dann musst du mir das nochmal genau erklären,

da habe ich das noch nicht genau verstanden.

Im Grunde einfach nur so ein Baum von Daten

irgendwie.

Was ist denn ein Baum von Daten? Ein Graf?

Ne, kein Graf.

Nein, kein Graf.

Da können beliebige Dinge drin sein.

Also insofern, aber,

ich weiß nicht,

es ist halt irgendwie alles, was

letztlich wie ein Python im Dikt,

kann man sich das vielleicht vorstellen.

So ein verschachteltes Dikt halt.

Wie so eine JSON-Struktur.

Ja, ja, ja, exakt.

Und, ähm,

du kannst halt,

als Komponente kriegst du das halt irgendwie

einen Teil davon irgendwie reingereicht, ja,

und diesen Kram benutzt du halt, um halt letztlich

eine Komponente, ist ein React nichts anderes

als eine Funktion, die aufgerufen wird

mit bestimmten Daten,

und die spuckt dann halt irgendwas

Gerendertes aus. Fertig.

Das war's.

Aber die hält keinen eigenen State.

Die kann nicht, äh,

So, das, äh, ja.

Das ist halt sehr schön, weil

solange sich nichts an den Eingaben für diese Funktion ändert,

ändert sich auch nichts an der Ausgabe.

Nur, wenn sich da irgendwas ändert,

muss das neu gerendert werden. Und da du immer weißt,

sozusagen, an welchen Stellen sich am State

was geändert hat,

weißt du halt auch, welche Teile du neu rendern musst

und welche nicht.

Das ist halt schon nett.

Aber, äh, naja, also, sagen wir mal so,

das ist halt auch alles viel zu kompliziert

für so eine Seite, die irgendwas Kleines macht.

Also brauchst du das alles,

eigentlich nicht.

Und es gibt natürlich auch Komponenten, die nur

ihren eigenen State, also wenn du jetzt

ein Formular hast, das irgendwie so ein bisschen Fehlerbehandlung

macht, das muss jetzt nicht irgendwie

da unbedingt angebunden sein

an den Komplett-State der Seite,

weil das interessiert sowieso, wenn es keine

andere Komponente interessiert, dann ist das

ja sinnlos, das in so ein allgemeines Ding zu schreiben.

Und, äh...

Auch noch so eine spannende Frage, wenn du jetzt so ein Formular hast, was ja

normalerweise jetzt in Python über

so ein Django-Form validiert werden würde,

unter anderem, ja, mit den Feedbacks zum Nutzer und so,

ähm, wie macht man das denn dann

einfach in so einem JavaScript-Framework?

Da muss man ja alles wieder neu implementieren.

Du musst es halt einmal auf Fernseite machen, du musst es einmal wieder

auf Server-Seite machen, weil auf Server-Seite musst du es natürlich

immer noch machen.

Auf Server-Seite bekomme ich dann ja aber dann wieder nur meine

API, meinen Rest oder was auch immer,

und hab dann irgendwelche Error-Feedbacks,

die ich geben kann, und wo dann irgendeine Message schon steht.

Und das ist ja dann doppelt und dreifach hässlich.

Also Django baue ich ja

einmal die Formklasse,

pipe die da rein, mach dann

ein, zwei Widget-Einstellungen und das läuft, das Ding.

Ja, und

inklusive Feedbacks und

Nutzer.

Also ich meine, gibt's keinem,

kommen wir nicht drum rum, du verwendest halt

bei einer API dann nicht irgendwie

eine Formklasse, sondern halt einen Serializer,

der ist halt so ähnlich wie ein Form.

Aber klar,

du musst halt auch das wieder validieren

und dann halt eventuell Fehler zurückgeben und

ja, und das auf der kleinen Seite halt nochmal.

Und was macht denn ein Serializer anders

als eine Form?

Äh, das,

ich würde sagen, das ist relativ

ähnlich,

serialisiert und

Dinge nach

sozusagen Dict und

irgendwie Dict, also

von Objekt nach Dict und von Dict

wieder zu Objekt. Das ist halt das, was Serializer

machen. Und

Formulare machen das auch.

Ja, mehr oder

weniger, aber die

Das ist halt so ein bisschen anders.

Das ist halt nicht immer...

Bei den Serializern, die können natürlich auch nach XML oder so,

aber eigentlich ist es immer JSON.

Es ist tatsächlich sehr ähnlich,

was sie machen.

Also die Validierung ist, glaube ich,

vielleicht so ein bisschen anders.

Sehr ähnlich.

Also ich kann sagen, dass man mit Serializern noch ein bisschen mehr machen kann.

Aber naja, das ist immer so.

Das ist halt...

Ist aber auch...

Das sind halt Feinheiten.

Das ist halt nicht mehr so.

Also im Grunde, du hast halt sowas wie Formularvalidierung,

musst du an der API natürlich auch machen.

Und das musst du auf dem Client halt auch machen.

Das heißt, du musst es halt doppelt machen.

Es gibt natürlich unter Umständen,

wenn du jetzt rein in JavaScript bleibst,

die Möglichkeit, dass du das nur einmal hinschreibst

und den Code dann sowohl

auf dem Server wie auf dem Client verwendest.

Aber ja,

weiß ich gar nicht, ob das jetzt so reibungslos...

Also man hört immer, dass das geht,

aber ob das wirklich so reibungslos geht, weiß ich nicht.

Und du hast dann ja

die ganzen anderen Probleme.

Du musst das ja auch noch immer irgendwie in der Datenbank wieder speichern.

Das ist quasi nochmal das gleiche Problem.

Du musst ja auch da irgendwie

das wieder in eine

Tabellenform serialisieren und deserialisieren.

Da hast du immer ein ORM dazwischen.

Also und

ja, es ist alles

nicht so ganz einfach.

Ja, aber...

Ja, das würde sich auf jeden Fall sagen,

wenn man das sowieso zweimal machen muss,

dann müsste man ja fast schon zwei unterschiedliche Projekte nehmen.

Wenn ich ja so eine API habe in Django zum Beispiel,

dann muss ich die beiden ja gar nicht miteinander

reblasten, wenn ich nicht will.

Also die muss ich ja nun nicht mal im selben Repo halten,

weil die von einer gar nichts wissen brauchen

und nichts miteinander zu tun haben,

weil die eine Seite ja auch unabhängig von der anderen Seite

getestet werden muss.

Ja, also das kommt halt drauf an

auf der Anwendungsweise.

Also würde ich sagen, kann man so,

oder so machen, je nachdem unter welchen Bedingungen

ist es halt das eine oder das andere sinnvoller.

Also kann man nicht so sagen,

dass man das jetzt so machen sollte und das ist dann immer richtig

für alle Sachen, sondern das ist halt,

hängt davon ab.

Also kann man, also sowieso so.

Es gibt ja Leute, die mögen das eher,

wenn Sachen in vielen unterschiedlichen

Projekten sind. Andere Leute mögen es lieber,

wenn alles in einem ist.

Hat halt auch beides so Vor- und Nachteile.

Kann man nicht sagen, dass das eine besser ist

als das andere.

Jedenfalls nicht, dass ich wüsste.

Wann würdest du das zusammen machen?

Wann getrennt?

Ich glaube, ich bin eher

in dem Lager

ein Großrepository.

Also ich tendiere eher zu einem Repository

als zu vielen kleinen.

naja, ich meine,

der Vorteil ist halt,

bei kleinen Repositories wäre es halt,

dass du zum Beispiel auch Sachen rausgeben kannst.

Du kannst halt zum Beispiel Pakete daraus bauen

und das halt irgendwie zum Beispiel,

wenn du jetzt ein großes Repository hast,

kannst du halt nicht so leicht sagen,

den Kram machen wir jetzt mal Open Source.

Geht ja nicht so gut.

Wenn das schon ein Repository ist,

dann ist das viel leichter.

Wenn es ein Teil ist, der nicht

den Kern von dem, was du tust,

irgendwie betrifft oder so.

So war es zum Beispiel.

Ich weiß es nicht so genau.

Aber, äh, ja.

Wenn du ein Repository hast,

wird es natürlich einfacher, das Ganze zu verwalten.

Ich meine, das ist halt

nicht, äh, ja, das ist halt

eben nicht das Problem, dass du dann

vielleicht noch irgendwie

die Sachen, die sowieso alle eigentlich

mit zu deiner Software gehören, nochmal alle

zusätzlich als Pakete installieren musst.

Was halt vielleicht nicht so toll ist.

Also, also, ja.

Frontend und Backend vielleicht dann wenigstens

so ein bisschen drin.

Würde ich nicht.

Also, ich würde es nicht machen.

Aber, ähm,

ist Geschmackssache.

Es gibt Leute, die machen das.

also, ja,

Nachteil ist halt, wenn du das so machst,

dann wie kriegst du die ordentlich

dazu zusammenzuarbeiten.

Wie machst du dann End-to-End-Tests?

Das ist halt schwierig.

Also, aber kann man tun.

Also, es gibt ja dann,

unter Umständen, wenn du größere Applikationen hast,

dann auch so, dann ist das halt nach Teams unterschiedlich.

Dann gibt es halt

vielleicht ein Team, das nur Frontend macht.

Oder Teams, die nur Frontend machen.

Und Teams, die nur Backend machen.

Und, ja, dann willst du es vielleicht doch irgendwie auftrennen.

Also, nett ist das natürlich tatsächlich,

wenn man

das auch einfach austauschen kann.

Wenn man jetzt beispielsweise

jetzt sein Frontend in Vue gebaut hat

und man möchte aber noch eine Elektron-Applikation

dazu basteln oder so.

Dann muss man das Backend ja nicht mehr anfassen.

Sondern,

nur den Frontend-Ordner wegschmeißen

oder das Repo dann tauschen oder so.

Oh, das verstehe ich nicht.

Hast du nichts zu sagen?

Also, ich habe jetzt mein Django Headless, ja.

Das ist ja viel die ganze Logik

und die ganzen Modelle und die ganzen Daten,

man kennt Links, alle für mich erledigt.

Und ich möchte einmal eine

Web-Applikation haben mit Vue beispielsweise.

Und einmal eine native Desktop-Applikation

beispielsweise mit Elektronen.

Ich würde sagen, du nimmst zwei unterschiedliche Verzeichnisse, fertig.

Warum muss das ein anderes Repo sein?

Wenn es doch die gleiche Applikation ist.

Was ist denn jetzt,

wenn du testen möchtest?

Die Daten

für die Tests, hast du die dann doppelt

in beiden Repositories?

Was ist, wenn du die änderst?

Wie sorgst du dafür, dass jetzt

die Testdaten synchron bleiben?

Sodass halt auch die Tests

aussagekräftig bleiben?

Es ist halt irgendwie schwierig, wenn das zwei Repositories sind.

Dann wird das halt...

Also ich sag mal so, es kann sein,

dass das nötig wird, wenn man sehr stark skaliert oder so.

Aber es wird auch sehr viel...

Es wird umständlicher.

Es ist halt komplizierter.

Was wird umständlicher?

Bitte?

Was wird umständlicher?

Wie testest du denn dann?

Wie testest du deine Desktop-Applikation

und deine Vue-Applikation?

Tests gibt es auch gar nicht.

Ja, aber...

Jetzt hast du das in unterschiedlichen Repos.

Du hast jetzt deine Fixed-Chats,

die irgendwie Testdaten sind,

mit denen du deine Tests machst.

Jetzt hast du festgestellt,

oh, ich habe hier einen Testcase,

der ganz wichtig ist.

Den mache ich jetzt bei meiner Vue-Geschichte dazu.

Wie sorgt deine Desktop-App dafür,

dass das auch getestet wird?

Wie kommt dieser Testcase da rein?

Ja, ich meine, du machst doch sowieso eigene Tests

für die Desktop und für Vue, oder ist das...

Ja, aber wenn du jetzt festgestellt hast,

oh, dieses Ding muss ich unbedingt testen,

das willst du auch vielleicht in einem anderen Ding auch getestet haben.

Ja, und wie würdest du das machen,

wenn die beide gleichzeitig im selben Repository

mal in Ordnung sind?

Dann nenne deine Testdaten beide gleich.

Wenn das funktioniert, okay.

Wenn das eine Repository ist, geht das ja.

Ja, ja, ja.

Oder eben, ich meine sowas wie,

du musst ja vielleicht, um end-to-end-Tests machen zu können,

halt so ein Dummy-Backend hochziehen,

wenn das Schema da irgendwo steht.

Wie sorgst du dafür, dass das so krumm bleibt?

Ja, und dann kann man natürlich anfangen,

das mit irgendwie GIF-Submodules

zu machen, oder weiß der Teufel,

und dann, also, aber das ist alles...

Ja, also, sag mal so,

ich kann mir vorstellen, dass es Vorteile hat,

es in mehreren Repositories zu haben,

aber es wird halt auch komplizierter,

und die Frage ist, ob man es denn macht oder nicht,

hängt halt davon ab,

ob dir diese...

ob es gerechtfertigt ist, ne?

Ob die Vorteile so groß sind,

dass die zusätzliche Komplexität

halt irgendwie...

äh...

nicht so schlimm ist, demgegenüber.

Dockerisiert das Ganze und go, oder?

Nee, das würde ich auch nicht sagen,

dass man das unbedingt machen muss,

sondern es hängt halt auch davon ab,

was man...

Wenn man jetzt alleine entwickelt,

dann braucht man Docker nicht.

Das ist halt...

Das brauchst du ja nur dann,

wenn du mehrere Leute hast,

die unterschiedliche Entwicklungsumgebungen haben.

Dann ist halt Docker irgendwie sinnvoll,

aber...

Also, für Sachen, wo ich alleine dran entwickle,

da benutze ich kein Docker.

Außer, ich deploy es halt irgendwie da.

Zum Deployen benutze ich schon Docker, aber...

Ja, das war die Frage, ne?

Also, wann das halt so macht und wann nicht.

Deployen ist auch noch so eine Sache, ja?

Also, weil...

Wie deploye ich denn überhaupt so ein Frontend?

Also, ich habe ja jetzt tatsächlich irgendwie dann

diese ganzen Systeme,

die Live-Development-Server haben.

Also, in JavaScript-Fanatik ist irgendwie jetzt

npm oder yarn und...

Also, node oder yarn.

Warum benutze ich...

Das eine oder das andere mal hin und her und...

Also, ich habe jetzt erst mal yarn benutzt,

weil es so ein bisschen ähnlich von Potree...

Ja, also yarn ist ein bisschen neuer.

Irgendwie war mal schneller,

weil es halt Sachen gecached hat und so,

aber ich glaube, es macht heute

keinen großen Unterschied.

Nimmt sich nicht viel.

Und dann installiere ich halt dann da irgendwie meine Projekte

und dann kann ich halt irgendwie die bauen

oder surfen direkt und sehe dann alle Änderungen.

Das ist ja super.

Aber wenn ich jetzt in mein Dango zum Beispiel einbauen möchte,

dann muss ich die ja alle packen.

Ja, das ist alles.

Ich habe da ganz, ganz übel

jetzt in letzter Zeit so ein bisschen rumgefimmelt

mit Webpack und der Konfiguration davon,

bis es dann irgendwie mit gehashten

JavaScript-Files und so in den

Static-Ordnern landete, die ich das gerne wollte.

Und dann ist halt auch die Frage,

wenn man das dann in Production ziehen will,

wo deployt man das Ganze dann eigentlich hin?

Liegt das dann einfach auf dem Server rum, irgendwo lokal

und wird dann als File ausgeliefert mit

Django-Collect-Static oder

was heißt das?

Irgendwelche Tootsie-Wide-News,

habe ich gesehen und habe, wie gesagt, diesen Webpack-Loader genommen,

dass er automatisch weiß, welche Files das sind.

Und das ist schon

nochmal so eine Wissenschaft.

Ja, ja, ja.

Das ist halt leider,

ich wünsche mir auch, das wäre

irgendwie anders, aber es ist leider alles

nicht so einfach.

Und ich habe mich auch lange nicht

damit beschäftigt, mit diesem ganzen Deployment-Kram

und wie setzt man so komplette Systeme auf.

Aber ich fürchte, letztlich kommt man da

nicht so richtig drum rum.

Und es ist schlimm.

Es wird dann irgendwann besser.

Zuerst denkt man sich so, das kann auch alles,

man sieht kein Land und das wird irgendwie alles nicht besser,

aber irgendwann

geht es dann doch.

Und zu diesem Ganzen, also ich,

wie macht man das

mit den Assets

und so? Das ist ein Problem.

Es gab da letzte

PyCon,

also ungefähr fast ein Jahr her,

einen Vortrag von

Jacob,

Captain Moss, also einem der

Jango-Gründer.

der Talk hatte den Titel

Assets in Jango without losing

your hair.

Ah, das habe ich mir

auch gedacht.

Oh, super, endlich erklärt mir jemand, wie man das richtig macht,

ohne dass es so kompliziert wird.

Und dann

sagte er dann halt an den ersten Sätze,

also ja, der Titel ist so ein bisschen

bait and switch.

Also tatsächlich,

ich habe mir das,

ich habe das auch nie so, also ich hatte das auch mal

kompliziert und dachte mir, ach, dann halte ich mal einen Vortrag drüber.

dann muss ich es halt lernen und dann habe ich auch einen Grund,

das zu tun und mir das alles nochmal genau

anzugucken und jetzt habe ich das halt gemacht.

Und ich hatte den Titel aber vorher schon

hingeschrieben und ich

muss aber sagen, nachdem ich das jetzt alles gemacht habe, ist es leider

nicht einfach.

Ich kann nichts machen.

Tja, leider verloren.

Aber ich erzähle euch jetzt trotzdem, was ich alles rausgefunden habe.

es ist leider,

leider nicht einfach.

Also eine Geschichte bei Django ist zum Beispiel

blöd, dass es halt

Static heißt. Das ist halt so komisch,

weil damals gab es noch

keinen etablierten Begriff dafür. Heute würde

man das eher als Assets nennen.

man kann ja Static-Fights dir

einfach auf Assets setzen in Django.

Ja, kann man schon, aber das Problem ist, die

Konfigurationsparameter, die heißen ja immer noch so. Das heißt dann immer noch

Static Root und Static

weißer Teufel irgendwie.

Das wird

man halt nicht so leicht los.

Man kann aber immerhin in die

Konfiguration sagen, Assets root gleich, Static

root gleich. Das kann man natürlich machen,

aber naja.

Ja, hässlich.

Ja, okay. Also okay, wir haben jetzt Assets,

die liegen jetzt irgendwo, okay? Genau.

Also tatsächlich gibt es in Django

einmal die Geschichte, dass

es gibt so eine

Innendirektion, die so ein bisschen komisch ist.

Also die ist nicht so intuitiv.

Zum Beispiel,

das wird auch oft aufgerufen,

wenn man jetzt

deployt zum Beispiel oder halt auch

gibt es so ein Ding, das nennt sich

Collect Static, ein Kommando, ein Management-Kommando.

Was das macht, ist, es

kopiert halt alle

Nacktes

Dateien aus der Static-Files.

Genau, also

in den einzelnen Apps, die man irgendwie, kann man

einzelne Static-Files hinlegen, einzelne Assets und die

sammelt das alle ein, wenn das irgendwie die

eingestellt ist richtig und speist das dann alles

in die Ordner Static-Files rein, wo man es abrufen

kann fürs Deployment.

Ja, nee, es macht sogar

auch noch mehr, es deployt das Ganze, also

man kann es so einstellen, dass es zum Beispiel den Kram

auch direkt nach S3 packt und so. Also

wo ist das hin kopiert?

Das ist halt konfigurierbar.

Und es wird auch

minifiziert, also zusammengefasst und so.

Ist da auch ByteNorth schon mitbeteiligt?

Was ist das?

Ja, ByteNorth ist immer eine ganz andere Geschichte.

Okay, verdammt.

Also diese Static-Files-Geschichte

in Django ist halt, also diese

Indirektion gibt es halt deswegen,

weil Third-Party-Apps

ihre eigenen Geschichten mitbringen.

Ansonsten könnte man sich ja sagen,

warum surft man nicht einfach das Static-Directory?

Dann hat man es doch

schon.

Aber ist leider nicht so, sondern

man muss halt diese ganzen, muss auch die

Static-Assets, die Assets von allen Apps,

die man verwendet, einsammeln.

geht das halt nicht so leicht.

Sondern das muss halt alles eingesammelt werden.

Und dann gibt es ja auch eventuell Sachen,

ich könnte ja auch sagen, okay,

also meine Assets liegen halt

nicht in einem Verzeichnis, sondern die liegen halt

irgendwo eben in einem S3-Bucket

oder auf irgendwas, was

Django-Storage als Anbindung hat, also auch

auf einem FTP-Server oder sowas. Könnte auch sein.

Also, genau.

Das Collect-Static holt halt Dinge

irgendwo her und schreibt sie irgendwo hin.

Ich kann Django mit einem

FTP-Server verkaufen?

Kann man es?

Ich weiß nicht.

Ich weiß nicht, ob das eine fehlenswerte Geschichte ist.

Gute alte Zeiten hier.

ja, das ist halt blöd.

Das wird man auch nicht so richtig los.

das ist nur der eine Aspekt daran.

Das ist halt dieser,

was passiert mit den Assets, wie kommen die jetzt eigentlich dahin,

wo sie gesurft werden.

Und jetzt kann man das natürlich entweder so machen,

dass man das

im Entwicklungsumgebungsfall

halt einfach dann vom

Django-Entwicklungsserver ausliefern lässt

und dann halt damit lebt,

dass das irgendwie anders ist als im Produktionssystem,

weil im Produktionssystem surft das natürlich nicht Django,

sondern da liegt das halt irgendwie

auf S3

oder halt irgendwie

in irgendeinem CDN

oder halt irgendwie

hinter irgendeinem Nginx

oder was auch immer.

Und wenn das jetzt anders ist als

in der Entwicklungssaison, dann kann es natürlich sein, dass dann

Bugs passieren, weil man das halt in der Entwicklungsgeschichte

nicht gesehen hat, dass das so nicht funktioniert.

Was man dann aber machen kann, ist,

dass man sozusagen die gleiche Infrastruktur benutzt,

wie beim Produktions...

bei Produktionsdeployment auch.

dann, was auch

in dem Vortrag dann halt

gesagt wurde, ist halt, was man tun kann,

ist, man präfixiert das dann halt irgendwie mit,

damit man halt nicht Produktionsassets

überschreibt oder so.

Und präfixiert das halt dann mit Entwicklungs...

Versionen oder sowas.

Mit Develop davor oder so.

Und, ähm, naja.

Aber, äh...

Und hätte dann halt sozusagen die gleiche Umgebung

im Entwicklungssystem und Produktionssystem.

Habe ich bisher noch nicht so gemacht, aber dachte ich mir so,

oh, ja, okay, stimmt, so kann man das vielleicht machen.

Dann hat man auf jeden Fall dieses Problem nicht mehr.

Ähm...

Aber es ist natürlich auch irgendwie doof,

dass man dann immer, wenn sich irgendwas geändert hat,

dass dann plötzlich, dass man dann Collectionssystems,

Assetting aufrufen muss und so.

Ja, also direkt irgendwie kleine

zwei Pixel geändert und dann einmal bitte

schon nach der Reihe ab und so.

Ja, genau. Das ist natürlich auch wieder so, hm.

Aber es gibt halt keine tolle Lösung

dafür irgendwie, ne.

Das ist immer ein bisschen doof, egal wie man es macht, ne.

Äh, dann,

genau, das, was halt White Noise macht,

ist im Grunde nur eine andere Art.

Also, tatsächlich

ist es

wahrscheinlich das, was man jetzt

machen sollte, wenn man,

statisch Files ausliefert.

Früher ging das so gar nicht.

Aber mittlerweile

mit White Noise kann man,

kann halt der Applikationszauber

statische Files ausliefern.

Das ist halt sozusagen, das ist ein Teil von dem,

was White Noise macht.

Der andere Teil ist, die Cache Header

richtig setzen.

Was man dann tun kann, ist,

man liefert irgendwie die Assets aus

über den Applikationszauber

und packt dann halt

ein CDN davor, den man einfach nur

sagt. Also,

da kommen die Files eigentlich her.

Also, wenn du irgendeine URL unter der Domain kriegst,

frag eigentlich mal den

Server danach. Und dahinter liegt dann halt der

Applikationszauber.

Und Caches halt. Und die Cache Header,

die Cache Control Header, die werden alle richtig gesetzt

von White Noise. Und damit hast du

halt ein System, das gut funktioniert.

und White Noise kannst du halt sowohl in deiner

Entwicklungsumgebung verwenden, wie auch in deiner

Produktionsumgebung. Also, eigentlich ganz,

ganz cool.

wo ich ein Problem,

wo ich nicht weiß, wie dieses Problem gelöst ist,

und das sind halt immer so Dinge, so Authentifizierung,

wie macht man das?

Was ist, wenn ich jetzt, es gibt ja

noch die Unterscheidung zwischen Static Files

und Assets, wie sowas wie CSS,

irgendwelche Icons, irgendwelche

JavaScript-Geschichten oder so,

die sich im Grunde ja auch nicht wirklich

ändern, die auch nicht dynamisch sind, wo auch Nutzer irgendwie

nichts damit machen können und halt sowas wie, das ist,

das ist in der Django-Welt, heißt das dann Media,

äh, wo zum Beispiel

User-Uploaded, äh,

hochgeladene Geschichten drin landen.

jetzt ist es halt auch so, manche von den Sachen willst du halt

nur, äh,

Leuten, die sich irgendwie

authentifiziert haben, zugänglich machen.

Und, äh,

das ist halt auch so, wie macht man

das eigentlich richtig? Ich hab ehrlich gesagt keine Ahnung,

wie mir das mit White Noise richtig geht, weil

wenn das jetzt irgendwie in CDN draußen cached,

was ist,

wenn da jetzt ein Request von jemand anders kommt? Keine Ahnung.

Also, so wie ich das kenne, was man machen kann, ist,

dass du halt, äh, irgendwie ein,

äh, Web-Server

davor, der das halt

ausliefern kann theoretisch, also irgendwie

in Nginx oder so.

Und der, äh, da geht halt,

äh, ein, ein Request

rein, nach jetzt irgendeinem Bild

oder nach irgendeiner, nach irgendeiner

Datei. Und

der Applikations-Server schickt dann halt

bloß, äh, zurück, äh,

okay, der, äh, Request ist autorisiert

oder nicht, oder das ist halt...

Und dann nimmt der Nginx

das und ersetzt diese Response

halt durch die File-Response.

Weil er ja auf die Files

zugreifen kann. Sowas kann man halt machen.

Es ist halt auch alles ganz schön,

ganz schön übel, wie man das jetzt mit

White Noise hinkriegt. Ich hab keine Ahnung. Also,

es ist ein alles, aber das sind alles Dinge, die sind nicht so richtig

einfach.

Ja, aber, äh,

tatsächlich, für so statische Assets

ist wohl der Weg zur Zeit, ähm,

äh, White Noise,

äh, zum Ausliefern

und dann halt, wenn man skalieren muss, halt

ein CDN davor.

Und vorher, wenn man den JavaScript-Frontend

dann gerade gebaut hat, wird das mit Webpack,

äh, so ein Bundle gepackt

und ein Chunk-Vendor irgendwie ausgeliefert.

Das ist nochmal ein anderes Problem im Grunde.

Also, das ist das Problem, dass man halt, wenn man

jetzt irgendwie eine JavaScript-Applikation

im weitesten Sinne irgendwie entwickelt,

dass man dann halt, äh,

das in einem Bundle zusammen,

kopiert haben möchte und halt auch vielleicht transpiliert,

weil man schreibt halt ES-Next oder man schreibt

halt TypeScript oder sonst irgendwas, was die Browser nicht

verstehen und dann

muss das halt irgendwie nach ES-6 oder

Warum verstehen denn die Browser kein ES-6?

Also, ES-6

verstehen sie, aber ES-Next zum Beispiel nicht.

Aha. Ja.

Und halt TypeScript wahrscheinlich

auch nicht oder CoffeeScript oder was auch immer

man da verwenden möchte.

Und weil die das nicht verstehen, dann muss man

denen halt sagen, dass das transpiliert wird mit

was auch so wie Babel oder was gibt's da irgendwie.

Irgendwelche Transformatoren und Transpiler

und... Das ist die eine Geschichte,

dann ist es auch so, dass es halt unter Umständen günstiger ist,

wenn es halt alles in einem Ding ist und minifiziert

und nicht in vielen unterschiedlichen, sodass der Browser

nicht so viele Requests machen muss.

Und das heißt, den ganzen neuen Code,

wie er schreibt, und was ist gerade die S-C-S-S-S-S-S

oder die ganzen Frontend-Sachen, die man da bauen kann,

das nimmt Webpack dann

und baut daraus dann minifizierte,

also auch ohne alle Leerzeichen, damit sie schneller

geladen werden können, Pakete,

schraubt die zusammen zu verschiedenen Chunk-Vendors,

wie sich das nennt, und liefert das mit all diesen

20.000 Notpaketen, die unbedingt notwendig sind

für die ganze Anwendung, insgesamt

als Files aus.

Ja, also Webpack

ist im Grunde das Ding, was halt

einen Riesenhaufen, also seine Applikation

irgendwie nimmt und dann spuckt es halt so ein paar

Bundles aus,

die dann halt

tatsächlich benutzt werden.

Dass wir das dann, was man in die Static Files reinpacken kann.

Genau, genau.

wo ich jetzt ein paar Mal nochmal drüber gefallen bin,

ist, man könnte diese Files dann ja einfach

deployen und dann in Django einfach ganz normal laden,

indem man halt die Namen dann so reinpackt.

Aber bei jedem Bild ist natürlich die Hash anders und das heißt,

du wirst das jedes Mal, wenn du das Frontend irgendwas änderst,

dann das komplett neu bauen und das dann

in Django wieder anpassen und das willst du eigentlich nicht machen.

Aber dafür gibt es dann irgendwie sowas.

Genau, deswegen schreibt man ja auch die Pade für die Static

Files und so, da schreibt man ja auch nicht

direkt die Pade

rein, sondern dafür nimmt man ja auch das

Static

Template Tag.

So dass halt egal, wenn ich jetzt

von S3 auf

Compute Engine umsteige

oder auf sonst irgendwas Minio

oder dann muss ich halt nicht

überall meine URLs ändern,

sondern dann macht das Static Text das automatisch.

Ja, aber eventuell dann doch, weil

ja nämlich der

Bild von Webpack, die andere Hashes

und deswegen auch andere Namen für die einzelnen Files gibt

und dann müsstest du die Dateinamen halt ändern

und das ist halt blöd und da braucht man eine Wiederlösung.

Genau, du brauchst halt so eine ähnliche

Lösung dann halt jetzt für deine,

äh, Bundles und da gibt's dann irgendwas, äh,

Django Webpack Loader oder so und dann, äh,

da sagt man dann irgendwie

Render Bundle und, äh, genau,

dann, ähm,

dann funktioniert das auf jeden Fall dann, wenn man die gebildet hat.

Ja, ich bin jetzt gerade noch dabei herauszufinden,

wie das zum Beispiel mit Vue so funktioniert, dass dann

der Devil-Lock-Mon-Server nicht kaputt geht.

Ja, aber, äh, ja.

Jaja, aber es ist ganz schön, ganz schön

kompliziert und, äh, ich meine, es gibt ja

auch dann, tatsächlich muss man sagen,

Webpack ist halt

wahrscheinlich das, was man verwenden,

muss, gibt's kein, nicht so wirklich

einen Weg drumrum, äh, es gibt auch noch Django

Kompressor und so, also wenn man jetzt nur CSS und

vielleicht ein ganz kleines bisschen JavaScript

und dann geht das auch alles dann gut,

aber wenn man jetzt irgendwie kompliziertere Sachen

macht, dann kommt man halt um Webpack eigentlich

nicht drumrum, auch die ganzen anderen Tools, die es da so

gibt, die, äh, sind alle

nicht vergleichbar mit dem, was Webpack so

kann, äh, daher. Der Kompressor ist auch

irgendwie kaputt gegangen, als ich ihn angefasst habe, das lag natürlich

nur an mir, wahrscheinlich den falschen Gang reingehauen,

getrieben, kaputt gemacht. Ja, also für die Sachen, die es kann,

ist es super, aber das Problem ist halt, äh,

ja, es ist, äh,

Es gibt ja noch das Kompressor-Toolkit.

Ja, also es ist

irgendwie nicht, äh, ja,

tatsächlich läuft es momentan auf, äh,

auf Webpack hinaus, es gibt noch ein anderes Ding,

nennt sich Parcel, das könnte sein, dass das

irgendwann mal Webpack ablöst, aber momentan

ist es halt noch Webpack und,

ähm, ja, äh,

man muss das halt

irgendwie alles, äh, integriert

kriegen, ja, das, äh,

Ja, ja, ja.

Ja, das ist, äh, so eine Geschichte.

Ist ganz schön hakelig, wenn man

da mal so ein bisschen guckt, ist ja nicht nur

pixelrumgeschubse, wenn man mal so

ehrlich ist. Ja.

Gibt so gute Witze, ich hab letztens

wieder einen ganz tollen gesehen, wo

jemand ganz gemütlich frühstückt, ne,

Müsli-Schale und ganz gemütlich

seine Cornflakes, ähm, dann gibt's jemand, der

schnitt Milch hin, ähm, das ist ein Roboter, der nimmt

die Milchkanne und schüttet das dann so vor, vor ihm so

in die Schüssel rein und kriegt dabei die Hälfte der Milch

so weg. Das ist also Frontend-Nutzer-Experience

und Backend-Abend,

der dann die Milch

in die Schüssel gießen muss.

Tja, ja.

Ja, haben wir noch was auf der Liste?

Oder haben wir euch jetzt alles erzählt über das Frontend, was ihr

heute wissen wolltet?

Ja, das weiß ich nicht, ob das irgendjemand wissen wollte.

Wir haben es auf jeden Fall mal erzählt.

Also mit allen Dingen, die wir immer tun.

Aber im Grunde

ja, was halt interessant

wäre, ist, ob

da jemand Lust drauf hätte, mal irgendwie so eine

Vue-Lerngruppe

mitzumachen.

Ich bin da freiwillig dabei.

Bitte? Ich bin da schon mal

freiwillig dabei und melde mich.

Das ist immer dann ja

schon komplett.

genau,

halt auch mit viel Python und

vielleicht auch Django.

Man kann auch mal irgendwas anderes nehmen.

Ich hätte auch mal Lust, irgendwie Fast-API.

Zum Beispiel auszuprobieren.

So, Stralet unten drunter und so.

Da gibt es ja auch ganz, ganz nette Geschichten mittlerweile.

Aber halt

Vue im Frontend.

Genau, dann

schreibe ich das vielleicht mal irgendwie auf

und schicke das mal in diese Gruppe.

Das ist Vue Cologne, glaube ich,

irgendwie. Die könnte man ja dann vielleicht einfach

zur virtuellen

Vue...

Da müssen wir auch nicht wieder hinfahren.

Und vielleicht kann man es ja dann auch irgendwie wieder

in die physische,

äh, Realität verlegen, wenn es

dann mal wieder möglich sein sollte.

Diese ganze Spuk, die immer vorbei ist.

Ja, ist ja ganz witzig. Gerade genau die Sachen, mit denen

man sich die ganze Zeit um den Dom kümmert und den Dom,

die sind ja alle da unten in Köln.

Ja, äh, sorry.

Können wir bestimmt auch noch irgendeinen, äh,

ja, warten jede Menge

Wortwitze darauf, irgendwie,

Ja, ich auch.

verbrochen zu werden.

Wir haben schon wieder spät.

Ja, es ist echt, äh, äh, genau.

Ja, eigentlich, was haben wir noch auf der Liste?

TypeScript könnte man noch machen, aber ich meine eigentlich, ähm,

nee, äh, ich glaube,

ich glaube, ich glaube, ich würde auch das

Unitest-Mock vielleicht tatsächlich irgendwie einfach mal

erstmal weglassen wieder und dann...

Jetzt haben sich ja alle drauf gefreut, Jochen.

Ja, aber...

So, du musst jetzt aufstehen.

gerade für dich.

Schrecklich, schrecklich.

Ja, ich kann das verstehen.

Ja, also, hört uns auf jeden Fall, egal wo ihr seid,

bleibt uns gewogen und, äh, morgens, mittags, abends, nachts,

schön, dass ihr wieder eingeschaltet habt.

Habt ihr eigentlich gesagt, wann wir das aufnehmen?

Ja, nicht, ne?

Nicht konkret. Wir haben nicht, also, wir haben gesagt, dass es zwei Tage

vor dem Python-Wagencamp ist.

Wir haben gesagt, dass letztes Jahr 2019 ein, zwei interessante

Sachen gewesen sind. Also, das kann man

zurückrechnen. Wer möchte, es ist der 23. April

Ja. Und, ähm, genau.

Demnächst mehr, äh,

Frontend, Backend-Integration,

Noch mehr. Ja. Aber wir haben ja

immer noch ein paar andere Sachen. Also, vielleicht müssen wir

die Verkäufe ein bisschen erhöhen, ja.

Ja, ja. Wir haben noch einige ganz spannende Sachen.

Wir brauchen, äh, Gäste. Äh, wir

hatten noch, immer noch keine Frau

hier bei uns zu Gast. Was daran lag,

ja, wir hätten gerne eine mal da, die

etwas erzählen kann über Python. Ich hatte mal

ein paar gefragt, aber die haben sich alle nicht, äh,

überreden lassen.

Ähm, ja, vielleicht ändern wir das mal

zu einer Jubiläumsfolge oder sowas, aber

ihr kennt das ja wahrscheinlich, äh, in der Entwicklergemeinde

ist das, äh, leider die, die Quote

nicht ganz so super, wie wir das gerne hätten.

Ja, na ja.

Ja, aber das geht noch hin. Also, also, in Datastand,

ja, ich glaube auch, ja, demnächst müssen wir mal ein bisschen uns da auch

fokussieren. Vielleicht liegt es auch einfach an uns und wir

sind, äh, zu verschoben.

Ja, das kann auch gut sein.

Ja, aber ansonsten, ja, äh,

alles klar, dann, äh. Ja, genau.

Vielen Dank, dass ihr eingeschaltet habt. Ja.

Äh, macht euch noch einen schönen Abendtag morgen.

Wir auch. Äh, bleibt weiterhin gesund, ne,

und, äh, hoffentlich bald mal wieder in live

auf einen der schönen Events in der Ecke.

Alles klar. Tschüss. Ciao.