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.
Ja.
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.
Oh.
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?
Ja.
Übrigens, die Liste, die du da geschrieben hast, Jochen.
Ja.
Also.
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.
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...
48.
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...
Nee.
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.
Yay!
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.
Ja.
Und dann gehen wir über die Rheinbrücke und dann unten zum Rhein.
Und dann werfen wir Steine ins Wasser.
Ach so.
Ja.
Ah, Steine.
Okay, jetzt verstehe ich.
Ja.
Und dann...
Da siehst du, da werft der einen Stein für mich mit.
Ja.
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.
Ja.
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?
Nee.
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.
Okay.
Ja.
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.
Ja.
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.
Ja.
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.
Ja.
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...
Naja.
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?
Ja.
Damit unsere Hörer,
die sich auf das Frontend und Python,
freuen sich wie lange?
20 Minuten?
20 Minuten schon.
Uiuiui.
Weiß ich nicht.
Ja.
Ich habe nicht genau gestoppt.
Ja.
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.
Ja.
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.
Mhm.
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,
ja,
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,
äh,
virtuell.
Das hat eigentlich ganz gut geklappt.
Da haben wir Jitsi verwendet, ne?
Ja.
Äh,
das war jetzt auch nicht so schlecht.
Ähm.
Ja, Jitsi ist gut,
wenn es bis zu 10, 15, 20 Leuten ist.
Das ist ganz gut.
Ja, also sehr gut sogar.
Ähm,
ähm,
ja,
also Zoom habe ich jetzt,
äh,
haben wir jetzt bei dem letzten PyTDF-Treffen,
äh,
benutzt.
Fand ich,
fand ich ehrlich gesagt sogar ein bisschen angenehmer.
Ähm,
aber,
so viel nimmt sich das alles nicht.
Und dann ansonsten,
was ich halt,
äh,
häufig benutze,
ist halt,
äh,
Teams.
Äh,
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,
ne?
Sondern das ist halt,
das ist halt irgendwie dann so die,
das ist komplett.
Ich dachte,
das wäre bei Zoom so.
Ja,
äh,
das,
äh,
ich glaube,
die Idee dabei,
das jetzt bei PyTDF zu verwenden,
war auch,
äh,
dass,
dass Marc,
ähm,
Marc-André wollte halt ausprobieren,
was für unterschiedliche Dinge,
wie unterschiedlich funktionieren,
auch im Hinblick auf die EuroPython,
die er da damit.
Ja,
EuroPython wird,
äh,
Zoom nehmen.
Ja?
Das ist schon fest,
ja.
Ach so,
das ist schon fest,
okay.
Die haben sich auf Zoom geeinigt,
ja.
Ja,
naja.
Äh,
also GSC hat es nicht geschafft,
wegen dem Bug in Firefox,
ähm,
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,
ja,
mehrere Server bräuchte dann,
oder viele,
die vom einen Richtungsaufwand her ein bisschen höher sind.
Ja,
da blieb ja nicht mehr so viel übrig.
Ja,
keine,
keine Ahnung.
Also,
äh,
für mich ist das,
ist diese Frage einfach auch noch nicht geklärt.
Das ist halt,
äh,
der Chat von EuroPython geht übrigens über Discord.
Ach,
okay.
Weil er gesperrt werden soll,
weil der geflutet worden war,
äh,
zwischendurch mal von ein paar bösen Buben.
Sowas,
sowas.
Naja,
also,
äh,
wie gesagt,
also Teams funktioniert auch so halbwegs okay,
aber ist ansonsten irgendwie nicht so meine favorisierte,
äh,
Software für,
für diesen Kram.
Ähm,
was ich höre,
was super sein soll,
äh,
ist Meet,
äh,
also die,
Google,
äh,
Google,
äh,
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.
Ja,
ja,
genau.
Also Hangouts haben sie geschlossen.
Und es geht jetzt nur noch über Meet und ist eigentlich ganz gut.
Also,
ich benutze auch öfter mal Wearby.
Ja,
Wearby finde ich auch gut,
ja.
Ja,
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.
Ja.
Äh,
ja,
und ansonsten,
ich meine,
gut,
es gibt noch Skype und sowas,
aber das ist alles,
das verwendet eigentlich auch fast niemand mehr,
ne?
Das ist halt,
ich würde gerade sagen,
nimm das noch hin,
weil Skype ist tot,
oder?
Ja.
Aber man kann ja auch sogar Videokonferenzen in Slack machen,
habe ich letztens gehört.
Oh,
aber was ich,
ah,
nein,
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,
äh,
Berufskontext verwendet hat,
aber privat.
WhatsApp-Videokonferenz.
Naja,
gut,
also,
äh,
okay,
das sind halt,
also,
nee,
das,
das habe ich tatsächlich,
glaube ich,
noch nie gesehen,
aber,
äh,
FaceTime,
Apple,
und das funktioniert auch sehr,
sehr gut.
Also,
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,
und,
ähm,
äh,
angezeigt und solche Sachen,
und,
äh,
das ist halt,
äh,
der,
der Client auf den,
auf,
äh,
iOS-Geräten ist halt super,
ne?
Also,
es gibt ja auch keine anderen,
es gibt ja nur die.
Ja,
wir wissen ja mittlerweile,
dass du diese Firma mit dem Apfel da ganz gerne magst.
Ja,
tatsächlich,
also,
das funktioniert einfach ziemlich gut,
äh,
ja.
Kann man aber auch,
äh,
eben höchstens dann verwenden,
wenn Leute,
äh,
eben zumindest irgendein iOS-Gerät da haben,
oder irgendwie Apple-Hardware,
ja,
also,
insofern,
hm.
Ja,
äh,
ja,
also,
ja,
also,
das passiert übrigens,
liebe Hörerinnen und Hörer,
wenn,
äh,
zwei Backender sich über Frontend unterhalten in einer Folge.
Dann reden wir über Videokonferenzen.
Ja,
ähm,
okay,
was machen wir?
Ich wollte tatsächlich sagen,
das Modul aus der Standardbibliothek,
was wir noch vorstellen wollten,
das wird Unitest-Mock,
äh,
sein.
Ja.
Machen wir jetzt tatsächlich diesmal am Ende.
Ja.
Und fangen jetzt tatsächlich,
äh,
an,
ein bisschen über das Thema Frontend zu reden,
oder?
Ja.
Alles klar,
können wir gerne machen.
Ja,
News?
Noch,
na komm,
News.
Wollen wir noch was News?
Okay,
warte.
Ja.
News aus Python jetzt.
Also,
jetzt geht's los,
Leute.
Ihr dürft jetzt einteilen.
Ja,
äh,
was hatten wir denn da so?
Äh,
also,
ach.
Aufgeschrieben in Language Creators Conversation.
Mhm.
Das war irgendwie ein Panel.
Ach so,
das war das Panel mit,
mit Guido und,
äh,
dem,
dem Typen von Rust und,
äh,
nee,
nicht Rust.
Pearl.
Ja.
Larry Wall von,
von Pearl.
Dann James Gosling von,
von,
von Java und,
ähm,
äh,
André Heilsberg
und,
äh,
der hat,
äh,
Turbo Pascal in den 80ern mal entwickelt.
Äh,
auf Delphi und sowas.
Ja,
äh,
ja,
der ist,
oh,
da müsste ja jetzt jemand mit so einem Kuckstock und so einem uralter Kreis,
ne?
Das ist ja auch noch gar nicht so alt.
Und,
ähm,
der hat jetzt auch,
äh,
irgendwie,
ähm,
war da eine der,
äh,
treibenden,
oder vielleicht die treibende Kraft hinter,
hinter TypeScript.
Also,
äh,
ganz interessant.
Äh,
ja.
Ja,
und,
äh,
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.
Also,
ich benutze dann immer an meinem Podcast-Player,
äh,
so ein,
so ein Sideload-Ding.
Das heißt,
ich sag,
äh,
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.
Und,
ähm,
das ist natürlich ein bisschen,
ja,
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.
Ja,
äh,
also,
äh,
wir wissen ja,
du bist ein bisschen picky,
was das angeht.
Ja,
gut,
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,
ne?
Naja,
aber das,
was wirklich schrecklich ist,
war teilweise kaum zu verstehen,
weil so viele,
viele Nebengeräusche dabei waren.
Ähm,
aber von inhaltlich sehr interessant.
Also,
ich mein,
das ist natürlich auch total toll,
dass man da mal irgendwie,
halt so,
zumindest hier der,
äh,
wichtigsten,
äh,
ja,
Entwickler von Programmiersprachen,
die halt das,
was wir hier so tun,
also einen großen Teil von dem,
was Leute so machen,
halt,
äh,
wesentlich geprägt haben,
halt dann die einen oder anderen alle zusammensitzen,
und dann halt darüber reden,
wie sie das so sehen,
äh,
was so diverse Dinge angeht,
und das war,
das war schon sehr interessant.
Und,
ähm,
ja,
äh,
kann ich nur empfehlen,
sich das mal anzuhören,
ähm,
es,
äh,
ist toll,
ja.
Den Freund,
äh,
hab ich noch nicht geschafft,
tatsächlich,
reinzuführen.
Ja,
also,
äh,
ich weiß nicht,
ob es da irgendwas gibt,
was man da,
naja,
muss man sich einfach mal anhören.
Also,
das fand ich,
äh,
also als,
als,
äh,
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,
ja,
das ist auch,
äh,
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.
Ähm,
das heißt,
ja,
also,
wenn man da noch irgendwie auf so einer Long-Time,
äh,
Support-Version gesessen hat,
dann ist jetzt auch mal Zeit,
da irgendwie was dran zu machen.
Ähm,
ne,
ne andere,
äh,
Geschichte war noch,
dass,
äh,
ich verwende meistens PyTest statt,
äh,
dem Unit-Test-Modul für,
also,
und Unit-Test-Mog für Mocs,
aber,
äh,
für,
für die normalen Tests,
also,
äh,
eher PyTest,
ja,
äh,
weil ich das angenehmer finde,
also,
weil bei Unit-Tests gibt es so ein paar,
also,
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,
und,
ähm,
das ist halt,
ähm,
ist halt so ein bisschen komisch,
äh,
das hinzuschreiben,
ich meine,
man gewöhnt sich zwar auch dran,
aber es ist irgendwie,
und,
äh,
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,
äh,
so baut,
dass sie für die Fixtures passen,
und nicht für die reale Welt.
Ja,
genau,
und,
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,
ja,
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,
weil,
da ist nichts mehr,
das ist halt,
und,
äh,
ja,
also insofern PyTest,
äh,
mag ich,
mag ich durchaus,
äh,
lieber,
aber,
ja,
das Projekt hat halt irgendwie so auch,
äh,
ist ein bisschen in unruhiger Fahrwasser,
der,
äh,
es gibt da,
irgendwie,
hat irgendwie vier Mentainer,
und jetzt sind drei davon weg,
oh,
ja,
das ist viel,
ja,
das sind 75 Prozent,
das sieht nicht so gut aus,
ja,
und,
äh,
keine Ahnung,
wird das geforkt?
Ja,
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,
okay,
hm,
was machen wir denn jetzt?
Naja,
na,
ich hoffe mal,
dass sich das alles irgendwie,
äh,
zum Guten wendet,
aber,
das ist natürlich so ein Problem generell,
ne,
bei,
bei Open Source-Geschichten,
wie,
wie stellt man das eigentlich sicher,
dass so ein Projekt nicht irgendwie,
äh,
plötzlich kaputt geht an irgendwas,
ne,
oder,
äh,
Ja,
da meine ich einige Sachen so ein bisschen nervig,
ich habe ja PyEnv,
ne,
auch sehr lieb gewonnen eigentlich,
äh,
auch von dir,
äh,
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,
äh,
diese Windows-Variante,
und,
äh,
war nicht so super-maintained,
ähm,
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.
Okay.
Aber ja,
sowas ist dann ein bisschen ein Gefrickel.
Ja.
Ja,
aber ich würde sagen,
News hast du noch ein,
hast du noch was?
Äh,
lass mal schauen.
Also außer,
dass jetzt alles online ist,
was wir schon wissen.
Ja,
äh,
ansonsten,
ich habe hier noch einen Punkt,
äh,
mir aufgeschrieben,
weil das halt auch vielleicht für andere interessant ist,
halt so,
es gab,
äh,
ein paar Artikel zu,
ähm,
ja,
Django-Architektur.
Ich weiß nicht,
ob wir dieses Fass aufmachen wollen,
vielleicht lassen wir das auch einfach zu.
Äh,
du meinst für heute,
du,
du meinst,
ja,
weil wir,
ich schon,
Fat Models und so weiter.
Genau,
genau,
das wäre sozusagen,
ja,
Service Layer und dieser ganze Kram,
ja.
Ja,
vielleicht.
Ja,
also,
ja,
wir wollten unbedingt dringend drüber reden.
Also,
was eigentlich,
wann ist eigentlich das Django-Metap-Colon?
Äh,
das war schon,
das war jetzt,
glaube ich,
am Dienstag.
Das war,
ja.
Oh,
dann habe ich es verfasst.
Ja.
Du auch?
Ich auch,
aber ich konnte Dienstag halt nicht,
das war,
ja,
ich auch nicht.
Ja,
ja,
so ist das.
Naja,
ich,
ich würde sagen,
das verschieben wir auf irgendeine Django,
äh,
Django-Folge.
Django-Reden.
Wir reden jetzt übrigens über Django-Backend und JavaScript-Frontend.
Ja.
Genau.
Wir sind beim Thema angekommen,
Leute,
das ist unglaublich.
Ja,
aber,
manchmal dauert das halt so ein bisschen,
da muss man sich auch die Zeit nehmen,
da auch mal irgendwie,
ja.
Möchtest du jetzt unseren Hörern vorschreiben,
wie sie unseren Podcast hören sollen?
Nee,
dann gibt es halt die Kapitelmarken
und da kann man sich das dann ja,
äh,
so.
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.
So,
äh,
ja,
also,
ähm,
das,
wie,
wie kamen wir eigentlich auf diese Frontend-Geschichte?
Wie kam,
wie sind wir eigentlich auf den Hund gekommen,
sozusagen?
Was ist,
äh,
oder was,
was ist dein,
ja,
also,
wir entwickeln ja relativ viel Web-Zeugs
und,
ähm,
auch Dango natürlich,
oder,
äh,
Flask,
aber hauptsächlich Dango.
Und,
das muss man ja,
wenn man nicht die Dango-eigene Template-Engine benutzen möchte,
was,
was man natürlich machen kann,
für so grundsätzliche HTML-Singer mit CSS
und ein bisschen Bootstrap vielleicht,
funktioniert das ja wunderbar.
Aber,
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.
Ähm,
da ist dann Vue drin,
oder React,
oder Angular.
Und,
Dango wird auch noch,
äh,
ohne Kopf,
also Headless benutzt
und dann per APIs angesprochen.
Und,
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,
und diese ganze JavaScript-Welt
ist ja gerade für Python-Entwickler
erstmal so ein bisschen
ein Buch mit sieben Siegeln.
Also,
ja,
es gibt da einige Backend-Entwickler,
die sagen,
oh,
Frontend,
aber wenn man da so ein bisschen drin ist,
merkt man so,
oh,
das ist gar nicht so einfach,
wie man früher vielleicht dachte,
sondern das ist tatsächlich ein ganz schöner Stack.
Ja.
Ja,
und da muss man auch ganz schön was können.
Das ist ganz schön was wert,
wenn man ein guter Frontendler ist.
Und,
ähm,
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.
Ja.
Und,
äh,
vor allen Dingen,
ähm,
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.
Ja,
äh,
genau.
Ja,
ich,
ähm,
bei mir ist es,
ist es so,
vor allen Dingen,
dass ich,
ja,
ich meine,
ähm,
genau,
äh,
mir schon immer mal View angucken wollte
und jetzt,
äh,
kam dann irgendwie so ein Ding vorbei,
äh,
ob ich nicht,
äh,
ich,
ich hab mich dann in,
in diversen,
äh,
View-Meetup-Gruppen,
äh,
irgendwie so angemeldet,
aber da ist dann irgendwie nichts passiert.
Die Anmeldung ist immer das Wichtigste.
Ich hab auch so eine Meetup-Gruppe.
Ja.
Da melde ich mir ganz viele Leute an,
die kommen aber nie.
Ja.
Also,
ich hab 50 Leute,
ist die,
für bezahlte Leute,
das,
die Grenze,
die man erreichen darf,
äh,
an Anmeldung,
bevor es,
äh,
noch teurer wird.
Äh,
und,
ja,
ich hab halt wirklich 50 Leute in der Gruppe drin,
das füllt sich immer wieder auf,
also wir machen Computerspiel-Unse,
ähm,
und es sind drei Leute immer da.
Drei.
Ja,
genau,
also,
das,
das passierte nicht,
sondern dann gab es irgendwann so den,
äh,
war,
äh,
dieser,
der,
irgendwie diese Gruppe ist nicht mehr mehr intent,
möchtest du das nicht übernehmen,
und dann hab ich dann einfach irgendwie,
äh,
ohne darüber nachzudenken,
einfach auf,
ja,
warum nicht,
äh,
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,
äh,
Django,
weiß ich nicht,
äh,
oder Gruppe draus machen,
wo man da halt vielleicht mal so ein bisschen interaktiver versuchen könnte,
rauszukriegen,
wenn man das Ganze so benutzt.
Und,
ähm,
ja,
muss man mal überlegen,
aber das wäre halt auf jeden Fall eine Möglichkeit.
Äh,
und,
äh,
aber Vue ist sowieso,
also aus diversen Gründen,
das,
was,
äh,
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,
Ja,
das hast du aber auch überall,
das hast du,
das hast du eigentlich inzwischen,
also das ist keine,
Ja,
wirklich so schön?
Das ist keine,
also ich muss gestehen,
ich hab mir Angular nur so ein bisschen angeguckt,
und,
und React hab ich noch gar nicht gesehen,
ähm,
aber ich finde das mit Vue,
die,
die Komponenten hervorragend.
Ich,
vielleicht erzählen wir erstmal so die,
die,
was das überhaupt ist,
was das überhaupt macht,
was das denn so ein Frontend-Framework,
oder?
Ja,
ja,
genau.
Äh,
also gerade für uns,
das ist erstmal so ein bisschen Overhead,
ne,
man installiert sich dann über,
ähm,
NPM oder wie auch immer,
also Node.js,
was man da macht,
äh,
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.
Tja.
Ja,
das ist halt,
das ist so ein bisschen JavaScript,
ne,
das gibt's halt keine Standard-Libriothek,
äh,
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,
ja.
Ui.
Naja,
so ist es halt.
Ich kann,
ja,
kann jetzt auch nichts mehr dran machen.
Aber,
äh,
also die,
die Unterschiede,
ich,
ich glaub,
äh,
also die,
die drei großen,
ne,
so eben Vue,
React,
Angular,
äh,
oder ich würde eher sagen,
React ist das größte Ding zur Zeit wahrscheinlich,
äh,
Angular und dann Vue,
oder wie auch immer,
ist ja auch egal,
äh,
die kann man alle benutzen,
die sind alle gut,
äh,
und,
äh,
so wahnsinnig,
äh,
groß sind die Unterschiede ja jetzt gar nicht.
Ist es nur so,
dass,
äh,
für mich,
äh,
ist Vue deswegen interessanter,
weil halt es nicht irgendwie,
sozusagen,
das,
äh,
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.
Weil,
ich meine,
klar,
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,
äh,
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,
äh,
oder weil bei Angular ist es halt Google drauf und die entwickeln das halt.
Äh,
das heißt,
ja,
das ist halt vor allen Dingen an die Bedürfnisse von denen angepasst und,
ähm,
da sehe ich bei Vue zumindest die Chance,
dass das halt,
äh,
so ist,
weil,
weil ich glaube nämlich tatsächlich,
dass die Anforderungen von,
von Firmen wie,
wie Facebook oder Google halt,
äh,
unter Umständen ein bisschen anders sein könnten,
als das,
was halt so man braucht,
wenn man jetzt halt,
äh,
nur so ein bisschen,
aus kleineren Rahmen,
irgendwie Dinge hochzieht.
Und,
ähm,
nicht,
der kann klotzen,
Junge.
Ja,
genau,
warum nicht das nächste,
genau,
einfach Google-Konkurrenz.
Ja,
also es ist,
ähm,
daher denke ich,
ist Vue so für,
äh,
unabhängige Leute irgendwie schon die interessantere,
äh,
das interessantere Projekt,
aber,
keine Ahnung,
kann auch vollkommen falsch sein,
wer weiß.
Ähm,
jedenfalls,
äh,
wenn man sich,
wenn es halt eh mehr oder weniger egal ist,
dann kann man ja vielleicht das mal verwenden.
Und,
ähm,
React und Angular habe ich auch schon so ein bisschen mit,
äh,
Dinge gemacht.
Und,
äh,
React hat mir tatsächlich ziemlich gut gefallen,
Angular,
äh,
nicht so richtig,
ehrlich gesagt.
Und warum?
Und was,
was ist das überhaupt?
Und was macht man da?
Also,
ähm,
vielleicht erklärst du nochmal so einen ganz Anfänger,
was das denn überhaupt ist und wie man das so macht.
Also,
äh,
ja,
was,
der,
der Witz daran ist eigentlich,
also,
ich,
naja,
das ist die Frage,
wo man ansetzt.
Man könnte natürlich sagen,
naja,
zunächst einmal gibt es halt nur so Standard-Web mit,
äh,
irgendwie HTML,
CSS und JavaScript eigentlich mehr oder weniger nur so als,
unterstützt halt,
äh,
irgendwie bestimmte visuelle Geschichten oder so.
Und dann irgendwann kam halt mit,
da hat der Internet Explorer halt diese XHTTP-Request,
äh,
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,
äh,
gemeinsamen API,
äh,
halt,
äh,
angesteuert hat.
Und das war dann jQuery,
das war sozusagen die Standard-API,
die man dann verwendet hat.
Und,
ähm,
könnte man dann fragen,
okay,
jQuery,
super,
dann ist aber alles,
oh,
perfekt,
alles tutti,
äh,
warum verwendet man das nicht heute immer noch?
Und da ist die Antwort im Grunde,
naja,
also,
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.
Ähm,
also eine,
eine Geschichte,
die halt dann irgendwann schwierig,
äh,
wird,
äh,
ist halt,
dass,
wenn man jetzt,
wenn man jetzt ganz viel,
äh,
State halten muss,
ne,
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,
ne?
Wo gehen überall die Counter rauf und runter?
Äh,
wenn irgendein Event passiert,
geht da noch eine Notifikation an?
Wie diese,
dieses,
äh,
das wird dann halt,
wenn die Applikation sehr komplex wird,
äh,
oder die Webseite sehr komplex wird,
dann wird das halt irgendwann sehr,
sehr unübersichtlich,
wenn man das halt in,
äh,
mit,
äh,
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.
Ne,
äh,
eher State ist halt sozusagen der Zustand der Seite.
Also,
den musst du ja selber handeln.
Also wenn du nur HTTP machst,
quasi,
dann ist der immer am Server.
Da ist es einfach.
Ja,
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.
Äh,
so,
diesen,
diesen State.
Fehler,
Serververbindung abgebrochen.
Ja,
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,
äh,
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.
Mh,
geht alles nicht so,
also du kannst natürlich schon
unterschiedliche Files haben,
aber,
also,
ne,
es ist halt irgendwie,
mit JQuery wird das halt irgendwie nix,
äh,
ab einem,
ab einem gewissen Komplexitätslevel
und im Grunde diese ganzen Frameworks
sind halt alle,
äh,
dafür gebaut,
um dieses,
mit diesem Problem umzugehen,
sag ich mal jetzt,
als jemand,
der eigentlich,
ehrlich gesagt,
ja,
keine Ahnung von diesem ganzen Kram hat,
ne,
aber so aus meiner Perspektive,
äh,
von außen,
so grob,
dass,
äh,
die,
das ist absichtlich ein bisschen geflüstert,
ja,
äh,
es ist,
äh,
es ist,
es ist schon so,
eigentlich ehrlich gesagt,
es ist ein bisschen außerhalb von dem,
was ich normalerweise mache,
daher,
äh,
keine Ahnung,
vielleicht rede ich auch großen Unsinn gerade,
ne,
ähm,
aber,
äh,
überprüft das,
schlagt das nach,
und schreibt es uns in die Kommentare,
äh,
genau,
äh,
während jetzt man in JQuery zum Beispiel den,
den,
dieses,
den DOM,
also sozusagen die Baumrepräsentation der Webseite im Browser direkt manipuliert,
dann,
äh,
macht man das halt in,
React View,
wie auch immer,
äh,
üblicherweise nicht direkt,
sondern,
äh,
in einer,
ja,
Shadow DOM,
oder keine Ahnung,
der Schatten DOM,
ja,
das macht man,
da gibt's immer Leute,
die sagen,
ach,
so viel schneller,
ja,
direkte DOM-Manipulation ist halt viel schneller als irgendwie so virtuellen DOM,
irgendwie,
äh,
aber,
äh,
was einem das halt erlaubt ist,
dass man das halt,
äh,
trennen kann,
also,
den State in dem Gerinnerten von dem,
was man halt,
wo man die Manipulationen macht,
und das ist natürlich,
äh,
unter Umständen sehr wertvoll,
also,
äh,
ich würde sagen,
kannst du noch ein Beispiel dafür nennen,
was,
was passiert jetzt,
wenn man jetzt einen Schatten DOM,
also das Dokument,
das Dokument-Objekt-Model,
also irgendwie das,
was da,
äh,
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,
äh,
den,
oder machst die,
die eigentlichen DOM-Manipulationen,
halt dann,
äh,
aus dem Diff zwischen dem,
was du eigentlich,
äh,
seinen virtuellen DOM,
ähm,
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,
halt,
äh,
nicht so schön,
weil,
äh,
dann,
da baue ich lieber einen Schatten drum,
mhm,
verstehe,
ja,
also,
äh,
keine Ahnung,
also es ist,
äh,
naja,
ich bin da auch nicht der Beste,
um das,
um das zu erklären,
glaube ich,
ähm,
jeden,
jedenfalls,
äh,
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,
ähm,
äh,
aber,
äh,
man kann damit natürlich auch noch mehr machen,
das ist zum Beispiel eine Geschichte,
die halt,
äh,
in,
in letzter Zeit,
äh,
sehr populär geworden ist,
wobei ich auch mal sagen würde,
man muss ein bisschen vorsichtig sein,
ne,
dass man da nicht zu sehr,
äh,
in diese Hype-Falle tappt,
weil das hat halt auch,
also die Trade-Offs sind nicht so ohne,
also das ist,
äh,
das sind halt so Single-Page-Apps,
ne,
dass,
äh,
dass du sozusagen,
äh,
alle,
äh,
alle Komponenten direkt mit ausgeliefert sind,
in JavaScript hast und nicht mehr,
also praktisch gar keine,
äh,
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,
äh,
ja,
asynchrone
Fragen an den Server
über JavaScript.
Ja,
du kannst,
man kann das,
also früher hat man das dann,
hatte man da immer noch so ein gewisses Problem,
dass man,
äh,
das dann halt unter einer URL hatte
und dass die
Zurück- und Vorbuttons
irgendwie nicht richtig funktioniert haben,
aber es gibt da,
äh,
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
für
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.
Und
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
ja,
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
und
dann aber React
hatte irgendwie alles so ein bisschen geändert. Das war halt so
das erste,
was
einen sehr neuen Ansatz
hatte, so diese,
na,
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.
Und,
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,
ähm,
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,
ja,
ä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,
äh,
hm,
man muss eigentlich viel zu viel erklären.
Das ist, äh,
ä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,
äh,
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,
äh,
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?
Ja.
Äh, außer jetzt diese, diese
URL-Routing-Geschichte, die bei Vue noch so
ein bisschen komisch ist, aber, äh,
naja, äh,
äh,
tja,
ansonsten, weiß ich nicht, was, äh,
ist das, hm, was, was,
was wäre da noch so interessant?
Äh,
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,
ä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
äh,
nicht,
äh,
also,
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.
Also,
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?
Also,
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,
mh.
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,
ja,
also,
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,
ähm,
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.
Au!
Ja.
Ja, also Fußschießen oder
Stolpernfallen, Reintreten,
große Fehler durch die Ohren zermüllen
oder mh. Ja, 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,
ähm,
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...
Ja.
Ich guck jetzt niemanden an.
Ja.
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.
Ähm,
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,
ja,
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,
ja.
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,
aber
ist
serialisiert und
Dinge nach
sozusagen Dict und
von
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
äh
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.
Ja.
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.
Ja.
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.
Ja.
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.
Aber
naja, ich meine,
der Vorteil ist halt,
äh,
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.
Mhm.
Also, also, ja.
Ja.
Okay.
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.
Ja.
Also,
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.
Ja.
Mhm.
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.
Okay.
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.
Ja.
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.
Ja.
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,
2019
einen Vortrag von
Jacob,
Captain Moss, also einem der
Jango-Gründer.
Und
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.
Und
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.
Und
ja,
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.
Aber
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.
Daher
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.
Und
ja, das ist halt blöd.
Das wird man auch nicht so richtig los.
Ja,
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.
Und
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...
Ja.
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.
Ähm,
und White Noise kannst du halt sowohl in deiner
Entwicklungsumgebung verwenden, wie auch in deiner
Produktionsumgebung. Also, eigentlich ganz,
ganz cool.
Ähm,
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
ähm,
ja,
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.
Und
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
hast,
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,
ähm,
dass man dann halt, äh,
das in einem Bundle zusammen,
äh,
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.
Aber,
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.
Mhm.
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,
äh,
ja,
ähm,
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.
Aber
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.
Ja.
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,
äh,
Ja, ich auch.
verbrochen zu werden.
Ja.
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...
Ja.
So, du musst jetzt aufstehen.
Haha,
gerade für dich.
Schrecklich, schrecklich.
Ja.
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
2020.
Ja. Und, ähm, genau.
Demnächst mehr, äh,
Frontend, Backend-Integration,
hier.
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.
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.