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, ihr könnt uns gut verstehen. Letzte Folge war etwas audioschwankungen.
Dabei war sie inhaltlich sehr toll. Wir haben uns vergessen, den Podcast zu erwähnen.
Das war auch echt blöd.
Genau, der Podcast von Thomas heißt Pi Data Deep Dive.
Und ja, sehr empfehlenswert.
Ja, genau.
Ein sehr cooles Ding.
Ja, was machen wir heute?
Jochen ist natürlich wieder da.
Ich bin in meiner raubischen Zentrale, Jochen Wintergarten.
Ja, willkommen Dominik.
Es ist so eine etwas ungewohnte Situation.
Wir sind irgendwie beide remote.
Und wir haben hier auch noch so 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 naja.
Heute machen wir Frontend mit Python
und oder wie man das verbindet mit
Python. Ja.
So zumindest der Plan. Also als Thema uns
überlegt, ja, weil es halt gerade auch
sich anbietet, weil da
irgendwie wir beide halt so ein bisschen
irgendwie mehr mit zu tun haben im Moment.
Struggle.
Ja, genau. Aber
vielleicht, ich habe auch noch so, ich weiß nicht,
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.
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 ja eigentlich
ganz nett, wenn man mal Internet hätte und man hat es aber irgendwie
keins und so.
Stimmt.
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 ihr das Bescheid fandet
jetzt hier mit dem Remote, mit dem Setup, wie sich
das anhört im Vergleich zu sonst.
Übrigens,
die Liste, die du da geschrieben hast, Jochen,
es gibt so ein paar Menschen, die mir
dann eine Einkaufsliste schreiben, was ich alles so 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. 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
Das ist eigentlich ein Thema von daher.
Ich kriege das schon irgendwie alles hin, genau.
Also zum Beispiel, was ich an 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 Beyerdynamic
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 so ein bisschen
auf die Ohren.
Und bei dir sieht man auch die Haare gar nicht.
Die sind auch länger geworden. Wir alle in diesen Zeiten
jetzt alle, nicht beim Friseur, alle
so Matte und Bart.
Wie heißt der bei Harry Potter?
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. Ich würde auch sagen,
dass das der Charakter in Harry Potter, den du am nächsten
bekommst von der Optik, ja, ja.
Ja, und
genau, ich brauche halt
große, große Kopfhörermuscheln
und das bei dem
DT797 ist auch
ein Bayerdynamic Headset und da ist das halt irgendwie so
ein bisschen größer, dass es geschlossen ist.
Ich halte hier gerade welche rein, aber der hat jetzt leider kein
Mikrofon. Ah, okay, ja, das sieht auch
sehr gut aus. Das ist mein Studio-Kopfhörer. Das 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
die TD-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 immerhin bei dich Komfort ist ja auch wichtig.
Genau.
Wenn man jetzt so lange sitzt und die ganz lang folgen,
immer auf und weil wir viel zu erzählen haben,
dann sollte das auch beim Tragekomfort entsprechend, ja.
Ja, und dann hatten wir noch ein, genau.
Du hast gebastelt.
Du meinst diese mit dem HMC66, diese Bastelgeschichte, oder?
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.
Das ist, denkt man
sich eigentlich, diese ganzen Geschichten, das sollten doch
inzwischen gelöste Probleme sein,
irgendwie Headsets
für Computergeschichten, das gibt es doch alles schon lange
und, aber 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 Audiokram 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
HMC-66X
Superlux.
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 Beyerdynamic-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 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 echten 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 man da irgendwie,
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 und reagieren einfach so ein bisschen gutmütiger oft, kriegen nicht so feine Unterschiede hin und lösen nicht so fein auf wie jetzt ein Kondensatormikrofon.
Automikrofone 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.
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 so das, was man in
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 Sichtvektor.
Genau, also das ist alles so ein bisschen
hmm.
Daher mag ich das mit den Headsets eigentlich
lieber,
aber die klingen halt dann vielleicht nicht ganz
so gut, aber auch schon 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,
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,
sage ich mal so. Es gibt aber auch
24 Volt und es gibt sogar
12 Volt. Und
dieses HMC-66X,
das klingt bei 48 Volt und 24 Volt,
also funktioniert es zwar, aber es klingt schrecklich.
Deshalb
da muss man immer aufpassen. Da gibt es so ein paar Reviews
unter denen, wenn man das
irgendwo in einem
Online-Shop sieht oder so.
Oft ist dann so ein oder zwei dabei, die sagen so,
es wird immer so gelobt, es klingt ganz
scheußlich, ich verstehe das gar nicht.
Wie 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 Audiointerface
betreiben, das halt dann die falsche Phantomspannung hat
sozusagen und dann geht es halt nicht richtig.
Womit das gut funktioniert, ist
halt 12 Volt Phantomspannung
und was man halt
tun kann, ist entweder man lötet sich da so einen Widerstand
rein, das ist halt so eine beliebte Lösung.
Jetzt wird es interessant.
Aber für mich auch schon zu,
das ist zu weit, das ist, nee,
mach ich halt nicht.
Ich bin dann in den einfachen Weg gegangen
und habe dann so eine, man kann da
irgendwie so eine Box zwischen
das Mikrofoneingang
von dem Audiointerface und
das Headset schalten.
Ja, das kostet 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
kann man das irgendwie einstellen.
Und ja, das habe ich dann halt benutzt und dachte mir
so eigentlich, naja, selbst plus dieses
Ding und plus den ganzen Kabelaufwand
ist es immer noch für den Preis eigentlich
ziemlich unschlagbar.
was ich aber, und ich dachte immer,
Wie teuer ist denn das?
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, das ist halt, du brauchst halt
immer ein eigenes
Audio-Interface eigentlich.
normalerweise hat man an seinem Computer nicht
sofort oder als Standard
ZLR-Anschluss.
Genau.
Und dann hast du dir was gebaut, was richtig toll ist.
Nee, das hab ich auch gesehen.
Das hab ich in diesem Sendegate-Forum gesehen.
Ich hab da nix gebaut. Ich hab's auch wieder nur gekauft.
Man kann das bauen auch selber, wenn man das mag.
Aber ich hab's nicht gebaut. Ich hab's auch wieder nur gekauft.
Die Idee kauft dir die Welt, wenn die 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's auch nicht.
Jedenfalls hast du das Ding auf eine Klinke
adaptiert und jetzt kannst du
das tolle Headset sogar in dein Telefon stecken
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 Rode
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 halt ja nochmal die Trenden
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 da mit
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 gehalten ü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, da habe ich den Hintergrund verändert.
Weil es gerade so ein bisschen chaotisch ist.
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.
Nö, das war der Zoom-Client
und der macht das dann halt, da kann man das irgendwie einstellen.
Ach na dann, okay.
Ja, aber ich war tatsächlich mit dem
Headset schon dann halt im Park und hab
mit Leuten telefoniert und
das Erste, was sie sagten, war so, oh, du klingst aber gut.
Oh, ja, na dann.
Hat sich das vielleicht gelohnt.
Und das ist natürlich irgendwie,
ich hätte gar nicht gedacht, dass sowas so ist.
Also ich telefoniere auch immer im Park mit meiner Freisprechknopf,
der auf dem Display ist, da steht dann
Ton, Laut, Spreifwert.
Ja, aber das funktioniert nicht so richtig gut.
Vor allen Dingen, wenn es windig ist, ist es halt blöd.
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 naja, muss man gucken, vielleicht das nächste Mal
probiere ich das mit dem Headset, vielleicht geht das besser.
Ja, okay, Challenge accepted.
Challenge accepted. Und warum gehst du
über die Rheinbrücke? Ja, weiß nicht,
ich gehe da spazieren. Achso.
Ja, meistens. Um telefonieren.
Ja, ja, ja. Also meistens ist es halt so, wir sind halt im Hofgarten und dann kommt irgendwann die Ansage, ja, Steine ins Wasser werfen, dann müssen wir halt noch zum Rhein.
Und dann gehen wir über die Rheinbrücke und dann unten zum Rhein und dann werfen wir Steine ins Wasser.
Achso.
Jo.
Ah, wegen Steinen. Okay, jetzt verstehe ich.
Da siehst du mal, 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 und möglicherweise gibt es damit halt eine Möglichkeit, wenn man das jetzt noch irgendwie schaffen würde, irgendwie an Studio Link oder an Ultraschall beziehungsweise Reaper das anzudocken, dann könnte man Leuten einfach sagen, hier, nehmt diese Hardware, steckt das an eurer Telefon, setzt euch irgendwo hin, wo es eine Sichtverbindung 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...
Achso, 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 Phantomspeisung.
Also an dem Ding klingen die
HMC-66X auch direkt gut.
Was natürlich auch sehr praktisch ist.
Das war mein erster Plan,
das Ding einfach zu kaufen. Und dann habe ich festgestellt,
geht nicht, weil alle Leute Audio-Interfaces
kaufen, gerade wegen Corona.
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
Affiliate-Things oder so.
Ja, Moment, Moment, ich bin noch nicht mit der...
Nein, okay. Wir machen aber gleich
eine Chapter-Mark, ja? Also Leute, ihr wisst ja,
ihr könnt die Chapter-Marks und die Sachen, die euch nicht so
freuig sind, einfach überspringen und dann direkt aufs Frontend
klicken. Wolltest du mal so als Hinweis...
Ja, es gibt nämlich dann noch so ein bisschen mehr, wir sind ja jetzt auch mit, das hatten wir letztes Mal auch gemacht, oder 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 Synchronisation, alles nicht so schick.
dann haben, meistens
entschließt man sich dann, dann lebt man halt mit den Knacks an
und, aber das klingt
schon relativ furchtbar und jetzt haben wir halt hier
eine Beta-Version von Studio Link
und die knackst
praktisch gar nicht, jedenfalls
Ja, wir werden es hören. Wir werden es dann hören, aber
jedenfalls nicht, dass ich das jetzt irgendwie
bisher
bemerkt hätte, also für mich
klingt das momentan alles sauber
und mal schauen, weil 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.
Nee, du hast kein Kabel?
Ich habe ein Kabel.
Was ich vielleicht temporär machen könnte, ich kann einfach ein Kabel
dann halt immer hier durch die Tür legen, aber das Problem
ist ja, 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 und so, das ist
nicht so mein... Also ich habe hier tatsächlich
in die Etage ein LAN-Kabel
gelegt.
Ja, es gibt bestimmt irgendeine Lösung
und wahrscheinlich sollte ich da auch mal
was tun, weil WLAN ist auch echt
tatsächlich nicht so geil, muss ich sagen.
So richtig mit in der Wand und Dose und so.
Ja, das ist schon viel cooler.
Das war nicht Bohrmaschine, das war so
ein Pressstemmhammer.
Da musste man so die Wand aufruppeln
und dann in das Kabel rein und dann verspachteln und so.
Klingt alles sehr schrecklich.
Was zum Anfassen.
Ja, okay, lass mal überlegen, ist da noch irgendwas mit …
Da steht noch Zencast da drin auf der …
Ach so, ja, das wäre halt auch noch eine andere Möglichkeit gewesen, wie man das jetzt macht, ohne Studiolink, aber weiß ich gar nicht, also das ist halt, also interessant finde ich es deswegen, weil es einen ganz anderen Ansatz verfolgt, ja, während wir …
Was ist das?
Das ist sowas ähnliches wie Ultraschall sozusagen, also die Software, mit der wir das Ganze aufnehmen.
Das ist, ach so.
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 das ja so gut klappt mit dem
Browser und Audio und Video, wie man ja
jetzt an GT und so Dinge... Ja, es gibt da so ein paar komische
Geschichten, also das zum Beispiel, das hat mich dann gewundert,
als ich das dann mal ausprobiert habe, dass irgendwie alles
geht dann da auf 44,1
Kilohertz und das ist ja sehr unüblich.
Also normalerweise hast du ja immer Audio-Hardware,
Das ist immer alles auf 48 Kilohertz.
Und das ist natürlich dann seltsam.
Dann muss man das irgendwie umsamplen.
Und ich weiß nicht.
Aber Leute verwenden das und finden das gut.
Und ich habe es jetzt tatsächlich noch nicht für einen Podcast.
Ich habe es jetzt mal ausprobiert.
Ich fand es auch super.
Und ich finde die Idee halt total toll.
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 zu regeln.
Tragisch, tragisch, tragisch.
Ja, natürlich, wer braucht das auch?
Ja, ja, ich verstehe schon.
Nehmen wir mal an,
zum Beispiel eine Geschichte, für die man das schon braucht,
ist halt, wenn man jetzt einen Livestream hätte.
Ja, und dann hat man
so Dinge drin wie
Audiokompression oder so, die man dann halt
möglicherweise hoch und runter
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.
Naja. Ja, naja gut.
Okay, also ich weiß es nicht.
In dem Fall das, dann überlegen wir uns das nochmal.
Was hältst du eigentlich davon, wenn wir diese Metadiskussion,
diese Ausrufung dann an das Ende der Folgen
stellen oder schneiden, damit
unsere Hörer, die sich auf das Frontend und Python
freuen, nicht, wie lange?
20 Minuten?
20 Minuten schon.
Ich habe nicht genau
gestoppt. Nein, also ich
mag das und ich finde das super, aber es ist halt
off-topic und schreibt uns doch mal
an hallo-at-python-podcast.de
was ihr davon
haltet, ob ihr gerne vorher so
Sachen hört oder einfach sagt, nee, dann lieber vorher
das Python-Thema und am Ende dann mache ich einfach aus
oder ich höre das sehr gerne und bitte
weiter, die ganzen Meta-Sachen.
Ja, gut.
Sollte man vielleicht einen Schluss packen. 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
hier angeht und diese Geschichten ist Zoom
natürlich hat da 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.
Das habe ich tatsächlich selber noch nicht ausprobiert.
Das finde ich tatsächlich bisher am
schönsten. Das hat auch so verschiedene Räume. Das werden wir jetzt
ein Python-Camp,
das am Morgen stattfindet,
übermorgen,
wahrscheinlich benutzen.
Das ist sehr cool. Das ist auch Open-Source.
Ja, also falls ihr uns noch
hört, ich weiß nicht, wann wir die Folge wieder veröffentlicht bekommen,
ein Python-Camp ist übermorgen.
Das ist genau, das ist übermorgen.
Könnte knapp werden. Wir haben ja jetzt so ein bisschen
Erfahrung schon, der PIDDF
Sprint war ja auch
virtuell. Das hat eigentlich ganz gut geklappt.
Da haben wir Jetsi verwendet.
Das war jetzt auch nicht so
schlecht.
Ja, Jetsi ist gut, wenn es bis zu 10, 15,
20 Leuten ist, das ist ganz gut. Also sehr gut sogar.
Ja, also
Zoom haben wir jetzt bei dem letzten
PIDDF-Treffen benutzt.
Das fand ich ehrlich gesagt sogar ein bisschen
angenehmer.
Aber so viel nimmt sich das
alles nicht. Und dann ansonsten, was ich halt
häufig benutze, ist halt
Teams. Eher so, weil es halt
muss.
Das benutzt man eigentlich
fast nie, weil man es nicht ausgesucht hat.
Sondern das ist halt irgendwie dann so
die...
Ich dachte, das wäre bei Zoom so.
Ja, ich glaube,
die Idee dabei, das jetzt bei PyTDF
zu verwenden, war auch, dass
Marc André
wollte halt ausprobieren, was für unterschiedliche
Dinge, wie unterschiedlich funktionieren.
Auch im Hinblick auf die Europiten, die er da
Ja, EuroPython wird Zoom nehmen.
Ja?
Das ist schon fest, ja.
Ach so, das ist schon fest, okay.
Die haben sich auf Zoom geeinigt, ja.
Ja, naja.
Also GSC hat es nicht geschafft wegen dem Bug in Firefox,
das tatsächlich ja noch nicht behoben ist
und weil es vor allen Dingen sich nicht so gut skalieren lässt.
BigBlue-Platten ist rausgeflogen,
weil das ja mehrere Server bräuchte dann
oder viele, die vom Einrichtungsaufwand her ein bisschen höher sind.
Ja, da blieb ja nicht mehr so viel übrig.
Ja, keine Ahnung.
Also für mich ist diese Frage einfach auch noch nicht geklärt.
Das ist halt ...
Der Chat von EuroPython geht übrigens über Discord.
Ach, okay.
Weil er gesperrt werden soll, weil der geflutet worden war
zwischendurch mal von ein paar bösen Buben.
So was, so was.
Naja, also wie gesagt, Teams funktioniert auch so halbwegs okay,
aber ist ansonsten irgendwie nicht so meine favorisierte Software
für diesen Kram.
Was ich höre, was super sein soll,
ist Meet.
Also die Google
Geschichte. Habe ich aber selber auch noch nicht
probiert. Hangouts kenne ich. Habe ich früher immer gemacht.
Ist dasselbe.
Hangouts haben sie umgestellt auf Meet.
Hangouts haben sie geschlossen.
Es geht jetzt nur noch über Meet und ist eigentlich ganz gut.
Ich nutze auch öfter mal Whereby.
Ja, Whereby finde ich auch gut.
Das ist auch tatsächlich von der Qualität her in Ordnung.
Aber das ist halt, ab vier Leuten musst du
Premium Account bezahlen.
Ja, und ansonsten
nicht mehr. Gut, es gibt noch Skype und sowas, aber das ist alles,
das verwendet eigentlich auch fast niemand mehr.
Da nimmt das noch jemand Skype, ist tot, oder?
Ja. Aber man kann glaube ich sogar Videokonferenzen
in Slack machen, habe ich letztens gehört.
Eine Sache, die ich super finde,
tatsächlich, das benutze ich privat eigentlich.
Ich habe noch nicht erlebt, dass das jemand irgendwie
in so einem
Berufskontext verwendet hat, aber privat.
WhatsApp-Videocall.
Naja, gut.
Also, okay,
das sind halt...
Das habe ich tatsächlich, glaube ich,
noch nie gesehen. Aber
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
angezeigt und solche
Sachen. Und das ist halt
der Client auf den
iOS-Geräten ist halt super.
Es gibt ja auch keine anderen.
Wir wissen ja mittlerweile, dass du
diese Firma mit dem Apfel da ganz gerne magst.
Ja, tatsächlich, also das funktioniert einfach ziemlich gut. Kann man aber auch eben höchstens dann verwenden, wenn Leute eben zumindest irgendein IOS-Gerät da haben oder irgendwie Apple-Hardware, ja, also insofern.
Ja, also das passiert übrigens, liebe Hörerinnen und Hörer, wenn zwei Backender sich über Frontend unterhalten in einer Folge.
Dann reden wir über Videokonferenzsysteme.
Ich wollte tatsächlich sagen, das Modul aus der Standardbibliothek,
was wir noch vorstellen wollten, das wird Unitest Smog
sein, machen wir tatsächlich diesmal am Ende
und fangen jetzt tatsächlich
an, ein bisschen über das Thema Frontend zu reden, oder?
Ja.
Alles klar, können wir gerne machen.
Ja, News?
Na komm, News.
Warte mal, machen wir noch die News.
News aus Python jetzt.
Also jetzt geht's los, Leute, ihr dürft jetzt einschalten.
Ja, äh, was hatten wir denn da
so, äh, also
Du hast auch geschrieben, Language Creators Conversation
Mhm, das war irgendwie
ein Panel. Achso, das war das Panel
mit Guido und, äh,
dem Typen von Rust und, äh,
Nee, nicht Rust, äh,
ja, Larry Wall von Pearl,
dann James Gosling von
Java und, ähm,
äh, André Heilsberg,
äh, der hat
Turbo Pascal in den 80ern mal entwickelt,
äh, auf Delphi und sowas.
Ja, der ist
so, oh ja, da müsste ja jetzt jemand mit so einem
Krückstock und so ein uralter Greis,
der ist ja auch noch gar nicht so alt.
Und der hat jetzt auch irgendwie,
war da eine der treibenden,
oder vielleicht die treibende
Kraft hinter TypeScript, also
ganz interessant.
Ja, und
ich weiß gar nicht, in welchem Rahmen diese
Veranstaltung da
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
so ein Sideload-Ding. Das heißt,
ich sage
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 habe das Video
nicht gesehen, aber das Audio gehört.
Und das ist natürlich ein bisschen,
ja, das ist oft, auch bei vielen Talks
ist das Audio oft relativ schlecht.
Entweder muss ich dann die Lautstärke sehr hoch drehen
und man versteht halt manche Sachen.
Ja, also
Wir wissen ja, du bist ein bisschen picky, was das angeht.
Ja, gut, kann sein, aber das ist halt auch
das ist der Fluch, wenn man sich damit beschäftigt,
dass man das dann plötzlich hört, wenn es nicht gut ist.
Naja, aber das ist wirklich schrecklich, das war teilweise
kaum zu verstehen, weil so viele fiese
Nebengeräusche dabei waren.
Aber inhaltlich sehr interessant, also
ich meine, das ist natürlich auch
total toll, dass man da mal irgendwie
halt so zumindest vier der
wichtigsten
ja, Entwickler
von Programmiersprachen, die halt das, was wir hier so
tun, also einen großen Teil von dem, was Leute so
machen, halt wesentlich geprägt haben,
halt dann die ein oder zwei Mal alle zusammensitzen und
dann halt darüber reden, wie sie das so sehen,
was so diverse Dinge angeht und das
war schon sehr interessant.
Und ja,
kann ich nur empfehlen, sich das mal anzuhören.
Es
ist toll, ja.
Denkt man.
Habe ich noch nicht geschafft, tatsächlich reinzuhören.
Ja, also ich weiß nicht,
ob es da irgendwas gibt, was man da,
naja, muss man sich einfach mal anhören.
Also das fand ich, also als
Geschichte, die jetzt gerade passiert ist, die man sich mal
angucken kann, irgendwie sehr nett.
Ansonsten, weiß ich nicht,
was gab es noch alles für News-Geschichten?
Django 1.1 ist End of
End of Life, ja, das ist auch
dass das
irgendwann passieren wird, ist klar, aber
jetzt ist tatsächlich die letzte Python 2
unterstützende Django-Version
weg. Das heißt, Python 2 ist
wirklich auch bei Django so
endgültig raus.
Das heißt, ja, also wenn man da noch
irgendwie auf so einer Longtime
Support-Version gesessen hat,
dann ist jetzt auch mal Zeit, da irgendwie was dran zu machen.
Eine andere
Geschichte war noch, dass ich verwende meistens
PyTest statt dem Unit-Test-Modul
für, also Unit-Test-Mock
für Mocks, aber für
die normalen Tests, also
eher PyTest
weil ich das angenehmer
finde, also weil bei Unit-Test gibt es so ein paar
also bei einem Unit, 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
das ist halt
so ein bisschen komisch, das hinzuschreiben
ich meine, man gewöhnt sich zwar auch dran, aber
es ist irgendwie
und PyTest hat halt eine sehr
schicke Art, wie man Fixtures halt
definieren kann. Das heißt, wie man sozusagen
die temporäre Testdaten,
die man sich dafür generiert, um halt einen Test ausführen
zu können, wie man die halt
so baut, dass sie für die Fixtures
passen und nicht für die reale Welt.
Ja, genau. Und die kann man auch schön
verschachteln und aufeinander abhängen lassen und so.
Und das funktioniert eigentlich ganz,
ist halt nett. Und dass man halt irgendwie
direkt Asteroid verwendet und nicht irgendwie
Methoden, die man
dann aufspielt.
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.
Und das ist halt, und
ja, also insofern PyTest
mag ich durchaus
lieber, aber
das Projekt hat irgendwie so auch
ein bisschen eine unruhige Fahrbasis.
Es gab da irgendwie
vier Maintainer und jetzt sind drei davon weg.
Oh.
Ja. Das ist viel.
Ja. Das sind 75%.
Das sieht nicht so gut aus, ja.
und keine Ahnung.
Wird das geforkt?
Ja, keine Ahnung. Vielleicht gibt es dann nicht so etwas anderes.
Vielleicht, aber
für mich ist es halt blöd, weil
jetzt, oder ich meine für alle,
es ist insgesamt halt blöd, weil jetzt muss man sich
natürlich überlegen, okay, hm, was macht man denn jetzt?
Naja, ich hoffe mal,
dass sich das alles irgendwie
zum Guten wendet, aber
das ist natürlich so ein Problem generell,
bei Open Source-Geschichten.
Wie
stellt man das eigentlich sicher, dass so ein Projekt
nicht irgendwie plötzlich kaputt
geht an irgendwas, ne? Oder
Ja, dann meine ich
einige Sachen so ein bisschen nervig. Ich habe ja
PyEnv auch sehr lieb gewonnen, eigentlich.
Auch von dir hast du ja den
schönen Tipp gegeben und das habe ich dann auch auf Windows
zum Laufen gebracht, tatsächlich. Das ist
aber sehr schrottig in Visual Basic implementiert.
Diese Windows-Variante und
war nicht so super maintained.
Ich habe es jetzt aber hinbekommen, indem ich mir
einzelne, unbeantwortete Pull-Requests
gezogen habe, die Funktionalität so wiederherzustellen,
dass man damit einigermaßen arbeiten kann.
Aber ja, sowas ist halt ein bisschen ein Gefrickel.
Ja, aber ich würde sagen,
News hast du noch was?
Also außer, dass jetzt alles online ist,
was wir schon wissen.
Ja, ansonsten, ich habe hier noch einen Punkt
mir aufgeschrieben, weil das halt auch
vielleicht für andere interessant ist.
Es gab ein paar Artikel zu
Django-Architektur.
Ich weiß nicht, ob wir dieses Fass aufmachen
wollen. Lassen wir es auch einfach zu.
Du meinst für heute?
Ja, weil wir jetzt eh schon
FAD-Models und sowas. Genau, genau, genau.
Das wäre sozusagen Service Layer und dieser ganze
Kram.
Ja, wir wollten unbedingt dringend drüber reden.
Also was war eigentlich,
wann ist eigentlich das Django-Meetup Cologne?
Bitte, ey.
Das war schon, das war jetzt glaube ich am Dienstag.
Oh, dann habe ich es verpasst.
Ja. Du auch?
Ich auch, aber ich konnte Dienstag halt nicht.
Ja, ich auch nicht.
Ja.
Tja, so ist das.
Ich würde sagen, das verschieben wir mal auf irgendeine Django
Jango-Folge?
Wir reden jetzt übrigens über Django
Backend und JavaScript
Frontend. Ja.
Ja. Genau.
Wir sind beim Thema angekommen, Leute.
Unglaublich. Super, dass ihr noch da seid.
Manchmal dauert das halt so ein bisschen, da muss man sich auch
die Zeit nehmen, da auch mal irgendwie
Möchtest du jetzt unseren Hörern
vorschreiben, wie sie unseren Podcast
hören sollen?
Nein, da gibt es ja dann die Kapitelmarken
und da kann man sich das dann ja 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
habt. Ihr könnt sogar bei bestimmten Podcasts
auf Dauerschleife setzen
und zum Einschlafen
benutzen. Genau
So, ja, also
das, wie
kamen wir eigentlich auf diese Frontend-Geschichte?
Wie sind wir eigentlich auf den Hund gekommen, sozusagen?
Was ist,
oder was ist dein...
Ja, also wir entwickeln ja relativ viel
Web-Zeugs und
auch Dango natürlich, oder
Flask, aber hauptsächlich Dango.
Und
das muss man ja, wenn man nicht die Dango-eigene
Template-Engine benutzen möchte, was man natürlich machen kann
für so grundsätzliche HTML-Dinge
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 Django mit einem Frontend benutzen möchte, einem Framework. Da ist dann Vue drin oder React oder Angular und Django wird oft noch ohne Kopf, also Headless benutzt und dann per APIs angesprochen.
Und da gibt es immer so ein paar Fallstricke, wie man das implementiert und was da überhaupt alles dazu gehört und worüber redet man da überhaupt, was heißt denn der ganze Quatsch und diese ganze JavaScript-Welt ist ja gerade für Python-Entwickler erstmal so ein bisschen ein Buch mit sieben Siegeln.
Also ja, es gibt ja einige Backends, 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.
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 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.
Und vor allen Dingen
muss man das Frontend ja
auch irgendwann mit seinem Backend wieder zusammenschnüren können.
Das heißt, man muss zumindest ja
dann die Schuhe zubinden und das irgendwie auf den Server packen,
dass das dann auch beim Kunden
oder bei einem selber auf dem Server irgendwie rennt
und nicht wieder auseinanderfällt.
Und wie man das alles macht, das wäre doch eigentlich mal ganz interessant,
so ein bisschen zu besprechen.
Ja, genau.
Bei mir ist es so,
vor allen Dingen, dass ich schon immer mal View angucken wollte
und jetzt kam dann irgendwie so ein Ding vorbei.
Ich habe mich dann in diversen View-Meetup-Gruppen angemeldet,
aber da ist dann irgendwie nichts passiert.
Die Anmeldung ist immer das Wichtigste. Ich habe auch so mit auf Gruppe.
Da melden sich mir ganz viele Leute an, die kommen aber nie.
Ja.
50 Leute ist für bezahlte Leute
die Grenze, die man erreichen darf
an Anmeldungen,
bevor es noch teurer wird.
Und ja, ich habe halt wirklich 50 Leute
in der Gruppe drin, das füllt sich immer wieder auf. Also wir machen
Computerspiele und so.
Und es sind drei Leute immer da. Drei.
Ja, genau. Also das
passierte nicht, sondern dann gab es irgendwann so den
irgendwie diese Gruppe ist nicht mehr
mein Talent, möchtest du das nicht übernehmen, dann habe ich dann einfach
irgendwie, ohne darüber nachzudenken,
einfach auf ja, warum nicht, geklickt.
Und jetzt muss ich mal überlegen, was ich damit mache, aber ich wollte ja
sowieso Vue lernen, also das wäre auch noch so eine Idee,
dass man das eventuell, das wäre einfach eine virtuelle
Vue-Django,
weiß ich nicht, oder Gruppe draus machen,
wo man halt vielleicht mal so ein bisschen
interaktiver versuchen könnte,
rauszukriegen, wie man das Ganze so benutzt.
Und
ja, muss man mal überlegen, aber das wäre halt
auf jeden Fall eine Möglichkeit.
Aber Vue ist sowieso
also aus diversen Gründen das, was
ich mir jetzt mal demnächst näher angucken
möchte. Also ich finde das so, diese Komponenten
finde ich sehr intuitiv, schön.
Das hast du aber auch bei allen, das hast du
eigentlich inzwischen, also das ist
keine... Also ich muss gestehen,
ich habe mir Angular nur so ein bisschen angeguckt und
React habe ich noch gar nicht gesehen, aber
ich finde das mit Vue, die Komponenten hervorragend.
Vielleicht erzählen wir
erstmal so die, was das überhaupt ist, was das überhaupt macht,
was das denn so ein Frontend-Framework oder?
Ja, ja genau.
Also gerade für uns Price-Entwickler ist das erstmal so ein bisschen
Overhead, ne? Man installiert sich dann
über NPM oder
wie auch immer, also Node.js, was man da macht,
dann dieses Paket von Vue und startet
dann mit Ucreate ein Projekt
und es werden erstmal 20.000
Pakete aus dem
Repositorium gezogen und als Modul
irgendwo hingepackt.
Ja, das ist halt, das ist so ein bisschen JavaScript, ne?
Das gibt's halt keiner Standard-Bibliothek
und dann muss halt
irgendwie alles an Abhängigkeiten
bis ganz runter geholt werden, was man
irgendwie brauchen könnte.
Das ist schon, ui.
Naja, so ist
es halt. Ich kann jetzt auch
nichts mehr dran machen. Aber
also die Unterschiede, ich glaube,
also die drei großen,
so eben Vue, React, Angular,
oder ich würde eher sagen, React ist das größte
Ding zur Zeit wahrscheinlich.
Angular und dann Vue oder wie auch
mal, ist ja auch egal, die kann man alle benutzen,
die sind alle gut und
so wahnsinnig groß sind
die Unterschiede ja jetzt gar nicht.
Es ist nur so, dass für mich
ist Vue deswegen interessanter,
weil halt es nicht irgendwie
sozusagen das
Spiel, 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
sehr gut verfügbar ist, aber wenn ich jetzt
da irgendwas dran ändern 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 Facebook, dann kriege ich meine Pull-Requester
ja doch nicht durch, weil die bei Facebook
da drauf sitzt oder bei
Angular sitzt halt Google drauf und die entwickeln das halt.
Das heißt,
ja, das ist halt
vor allen Dingen an die Bedürfnisse von denen angepasst
und
da sehe ich bei Vue zumindest die Chance,
dass das halt so ist,
weil ich glaube nämlich tatsächlich, dass
die Anforderungen von Firmen wie
Facebook oder Google halt unter Umständen
ein bisschen anders sein könnten, als
das, was halt so man braucht,
wenn man jetzt halt
nur so ein bisschen, was kleineren Rahmen
irgendwie Dinge hochzieht.
Und...
Der kann klotzen, Jochen.
Ja, genau, warum nicht das nächste, genau,
einfach Google-Konkurrenz machen.
Ja, also es ist,
daher denke ich, ist Vue so
für unabhängige Leute
irgendwie schon die interessantere
das interessantere Projekt, aber
keine Ahnung, kann auch vollkommen falsch sein, wer weiß.
Jedenfalls,
wenn man sich,
wenn es halt eh mehr oder weniger egal ist, dann kann man
ja vielleicht das mal verwenden.
Und React und Angular
habe ich auch schon so ein bisschen mit Dinge gemacht
und React hat mir tatsächlich ziemlich gut
gefallen, Angular nicht so
richtig, ehrlich gesagt. Und warum?
Und was ist das überhaupt und was macht man da?
Vielleicht erklärst du nochmal so einen ganz Anfänger,
was das denn überhaupt ist
und wie man das so macht?
Also, ja, was, der Witz daran ist eigentlich,
also, das ist die Frage, wo man ansetzt.
Man könnte natürlich sagen, na ja,
zum nächsten Mal gibt es halt nur so Standard-Web
mit irgendwie HTML, CSS und JavaScript
eigentlich mehr oder weniger nur so als,
unterstützt halt irgendwie bestimmte visuelle Geschichten oder so.
Und dann irgendwann kam halt, da hat der Internet Explorer
halt diese XHTTP-Request-Geschichte
mit eingeführt
und damit wurde es dann halt interessant. Das Ganze
lief dann so in Richtung, das lief
dann halt unter dem Stichwort Web 2.0,
weil jetzt halt Webseiten
ohne eine komplette
Seite neu rendern zu
müssen, halt Dinge auf der Seite ändern
konnten und dann hat man da
irgendwie so ein bisschen dann, die Browser-APIs waren
alle unterschiedlich. Dann gab es halt eine Bibliothek,
die halt dann irgendwie die unterschiedlichen Browser-APIs
halt unter
einer gemeinsamen
API halt
angesteuert hat
und das war dann jQuery, das war sozusagen die Standard-API,
die man dann verwendet hat und
könnte man dann fragen, okay, jQuery,
super, dann ist aber alles
perfekt, alles tutti, 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 würde
sagen, tatsächlich für kleinere Geschichten kann man das auch immer noch so machen.
Eigentlich ist es gar kein
Problem.
Also eine Geschichte,
die halt dann irgendwann schwierig
wird, ist halt,
dass wenn man jetzt ganz
viel
State halten muss, also wenn man jetzt eine
Seite hat, auf der viele komplexe Sachen passieren,
dann ist halt die Frage, wie merkt
man sich jetzt eigentlich, was man alles tun muss,
wenn jetzt jemand per Drag-and-Drop irgendwas irgendwo hinzieht
oder so. Wo gehen überall
die Counter rauf und runter?
Wenn irgendein Event passiert, geht
dann noch eine Notifikation an?
dieses, das wird
dann halt, wenn die Applikation sehr komplex
wird oder die Webseite sehr komplex
wird, dann wird das halt irgendwann sehr, sehr unübersichtlich,
wenn man das halt mit jQuery macht.
Also State
nochmal für unsere Ganzanfänger ist
der Zustand, den ein Benutzer irgendwie erreicht hat,
den er irgendwann wieder sehen will.
Nee, 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.
Weil Request-Response. Genau.
Aber wenn du jetzt sozusagen
nicht nur das machst, sondern du machst halt
auch noch irgendwie
XHTTP-Requests, 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.
So
diesen State. Fehler, Server-Verbindung
abgebrochen. Ja, diesen State
musst du jetzt irgendwie verwalten.
Und den verwaltest du dann halt nicht mehr
nur auf dem Summer, sondern halt auch auf dem
Client. Und das geht dann halt
irgendwann nicht mehr so richtig gut mit
jQuery, weil das ist ja auch dann,
du hast das ganze Zeug ja irgendwie dann in so
JavaScript-Files, du hast nicht so richtig Module
oder so.
Geht alles nicht so. Also
du kannst natürlich schon unterschiedliche Files haben,
aber es ist halt irgendwie
mit jQuery wird das halt irgendwie nichts
ab einem gewissen Komplexitätslevel.
Und im Grunde diese ganzen Frameworks
sind halt alle
dafür gebaut,
um mit diesem Problem
umzugehen, sage ich mal jetzt, als jemand,
der eigentlich, ehrlich gesagt, gar keine Ahnung von diesem ganzen
Kram hat, aber so aus meiner Perspektive
von außen
ist es so grob, dass
die... Du hast jetzt absichtlich ein bisschen geflüstert.
Ja, es ist
schon so,
eigentlich, ehrlich gesagt, es ist so ein bisschen außerhalb von dem, was
ich normalerweise mache, daher
keine Ahnung, vielleicht rede ich
auch großen Unsinn gerade.
Aber...
Überprüf das, schlag das nach
und schreib es uns in die Kommentare.
Genau.
Während jetzt man
in jQuery zum Beispiel
den DOM, also sozusagen die
Baumrepräsentation der Webseite im Browser
direkt manipuliert, dann macht man das halt
in React View,
wie auch immer, üblicherweise nicht direkt,
sondern
in einer
Shadow DOM oder keine Ahnung.
Der SchattendOM.
Ja, das macht man, da gibt es immer Leute, die sagen,
so viel schneller, also, ja, direkte
DOM-Manipulation ist halt viel schneller als irgendwie
so virtuellen DOM irgendwie,
aber was einem das halt erlaubt
ist, dass man das halt
trennen kann, also den
State in dem
Gerinnerten von dem, was man halt, wo man die
Manipulationen macht, und das ist natürlich
unter Umständen sehr wertvoll, also
ich würde sagen, das halt...
Kannst du mir noch ein Beispiel dafür nennen, was passiert jetzt,
wenn man jetzt einen Schatten-DOM,
also das Dokument-Operation-Modell, also irgendwie
das, was da hinter steckt,
hinter der ganzen gebauten
Konfiguration. Die Idee ist so ein bisschen, dass du halt die
Manipulationen da in deinem Schatten-Dings da machst
und dann nur guckst, du diffst das halt nur noch
dann sozusagen gegen das, was du, und dann machst du halt
erzeugst du
den, oder machst die
eigentlichen Dommen-Manipulationen
halt dann
aus dem Diff zwischen
dem, was du eigentlich
in
seinen virtuellen Dommen 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
nicht so schön.
Weil
Da brauche ich lieber einen Schatten-DOM.
Ja, also keine Ahnung.
Also es ist
naja, ich bin da auch nicht der Beste,
um das zu erklären, glaube ich.
Jedenfalls
heutzutage kann man für das, was man früher mit
Jackquery gemacht hat, auch einfach irgendwie React oder Vue
oder so verwenden. Das geht natürlich alles.
Aber
man kann damit natürlich auch noch
mehr machen. Das ist zum Beispiel eine Geschichte, die
halt in letzter Zeit
sehr populär geworden ist, wobei ich auch mal sagen würde,
man muss ein bisschen vorsichtig sein, dass man da
nicht zu sehr
in diese Hype-Falle tappt, weil
das hat halt auch, also die Trade-Offs sind nicht so
ohne. Also das sind halt so
Single-Page-Apps,
dass du sozusagen
alle
Komponenten direkt mit
ausgeliefert hast und nicht
mehr, also praktisch gar keine
Requests mehr machst, die halt da zu einem
Reload der Seite führen.
Sondern immer nur noch über die API,
also deswegen Django Headless und REST,
Single-Page-Application und
asynchrone Fragen
an den Server über das JavaScript.
Früher hatte man da immer noch
so ein gewisses Problem, dass man
das dann halt unter einer URL hatte
und dass die Zurück- und
Vor-Buttons irgendwie nicht richtig funktioniert
haben, aber es gibt da, ich weiß jetzt gar nicht,
wie die heißt, die API, es gibt eine Browser-History,
sonst was API
und die ist mittlerweile auch stabil in allen
Browsern drin und das heißt, man kann auch
ordentliche URLs
haben, ordentliches URL-Routing
und Back- und
nach vorne Buttons und so,
das funktioniert alles und wenn man links klickt, dann
das klappt alles inzwischen super, man muss dann 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 dann 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 das halt auch sozusagen
gerendert, ja. Was halt viel
schneller ist, weil so ein kompletter Page Reload,
wenn das halt kompliziert ist, also wenn ich
allein, es reicht eigentlich schon, wenn das irgendwie
Bootstrap mit allem möglichen Kram drin ist,
dann ist das 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
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
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 einer
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
auf einer Server
Seite gerinnerten
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
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 halt auch dann irgendwie quasi direkt auf
Mobilgeräte und so deployen.
Und
so ein bisschen, also diese Progressive
Web-App-Geschichte, die sehen dann halt auch so ein bisschen aus
wie normale Apps, wie so native Apps
auf Telefonen und so. Warum macht
man nicht alles so? Das hat halt auch diverse
böse Nachteile. Ein böser
Nachteil ist halt
Google-Suchergebnissen,
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 halt darauf an, was man
für ein Problem hat. Für manche Probleme ist
halt irgendwie eine klassische
serverseitig 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 was man halt mit dieser
diesen Frameworks
halt gut machen kann.
Was man jetzt mit jQuery nicht machen
könnte.
Wobei, ja, doch,
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
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, wie soll man das beschreiben, eigentlich eher einen funktionalen Ansatz,
dass man halt sozusagen die Visualisierung der Seite erzeugt,
indem man ein State hat und da einfach dann Funktionen drauf ausführt,
die das dann halt hinrendern.
Und dass man halt nicht sozusagen irgendwelche Templates hat,
HTML, man kennt das ja von Django
vielleicht oder sonst wie von
einer serverseitig gerenderten Geschichte,
wo man
wo halt
dann irgendwie
Sachen ersetzt werden.
Man hat halt irgendwie HTML oder so mit
Platzhaltern für, da kommen jetzt dynamische Sachen rein,
sondern in
React ist es eher
umgekehrt. Du hast halt
zwar etwas, das so ein bisschen aussieht nach
HTML
und ein Template, aber das ist es
gar nicht in Wirklichkeit, sondern in Wirklichkeit ist es
einfach nur eine Funktion.
Und diese Funktion
rendert
halt, rendert sich selbst raus
zu HTML oder zu irgendwas,
was halt irgendwie im DOM angezeigt werden kann.
Und
dieser Ansatz hat sich dann durchgesetzt.
Das machen jetzt inzwischen alle anderen auch so.
Und
ja,
tatsächlich, also ich fand React
jetzt, ist jetzt auch schon wieder ein bisschen her.
inzwischen, ich habe nie
mit Hooks irgendwie was gemacht.
Also
man muss eigentlich viel zu viel erklären.
Also React hat mir eigentlich ganz gut
gefallen. Es ist eigentlich
gar nicht groß, es ist auch eher so
eine kleine Geschichte,
aber es gibt natürlich ein riesiges
Ökosystem drumherum.
Und
ja, Angular fand ich
ehrlich gesagt, es ist deutlich fetter
und
mit gewissen Sachen bin ich nie so richtig, also man
muss relativ viel Boilerplate außen rum
schreiben und es passieren komische Sachen
manchmal, aber ich meine, kann man auch
verwenden. Also Angular, letztendlich nimmt sich das
alles nicht viel, es ist halt auch so ähnlich
und jetzt
Vue ist, glaube ich, auch so ähnlich. Das ist auch
kein großer Unterschied.
Außer jetzt diese
diese URL-Routing-Geschichte, die bei Vue
noch so ein bisschen komisch ist, aber
naja.
Tja.
Ansonsten weiß ich nicht, was
ist das,
was wäre denn noch so interessant?
Einzelne
Frameworks jetzt. Ja, ich,
ehrlich gesagt, keine Ahnung. Ja, wenn du keine
News-Story hast, wo wir genau wissen,
hey, in dem Case ist jetzt Angular total super
und da lieber React und
da lieber Vue, sondern die sind alle austauschbar.
Das heißt, wir können mit Python tatsächlich jedes
dieser Frontends nehmen. Die Frage ist aber, wie man
das implementiert, weil wenn du jetzt versuchst,
in der Django-App einfach so
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
ganzen Frameworks gar nicht.
Du musst halt irgendwie mit dem Backend kommunizieren.
Also dieses Problem hast du natürlich weiterhin, dass du
irgendwie
ja, irgendwo die Daten
dann tatsächlich in der Datenbank halten willst
und du musst halt irgendwie, 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, ja, so eigentlich immer JSON,
aber es gibt halt auch unterschiedliche APs.
Die beiden Hauptgeschmacksrichtungen, die es da gibt,
sind halt, ja, REST oder eben GraphQL.
Etwas neuere Geschichte.
Nimmt sich aber letztlich
auch gar nicht so wahnsinnig viel.
Ich habe angefangen
mit REST und dann
das lange gemacht und dann
GraphQL fand ich dann ganz gut und
bin jetzt inzwischen wieder bei REST.
Es gibt Leute, die machen dann auch
irgendwie sagen, naja gut, also
GraphQL zum Lesen ganz gut, zum Schreiben
vielleicht nicht so und schreiben dann über REST
und lesen über GraphQL.
Naja, also aber
letztlich ist es ja auch
ist es ja auch egal, auf jeden Fall
der Trend geht so ein bisschen...
Ja, aber man braucht halt dann eine API dann, ne?
Dann bleibt bei Python nur noch das Bereitstellen der API übrig
und das ganze Frontend-Trainering
fällt weg. Ist das auch bei Async-Django
so?
Async-Django
ist jetzt eine andere
Geschichte, oder wie...
Ja, warum ist das eine andere Geschichte? Dann habe ich
wieder Unsinn erzählt.
Async heißt ja eigentlich nur, dass du
dass du
nicht
also
das Protokoll zwischen
Applikationsserver und
dem Web-Server außenrum ist
jetzt halt ein anderes und es geht
nicht nur Request-Response,
sondern du kannst halt auch
in beide Richtungen,
du kannst halt auch vom Server Sachen an kleinen schicken, das ist halt
schon mal ein großer Unterschied.
Und es ist halt auch
so, dass
dass du
fürs
IEO-Multiplexen das nicht nur über
Threads und Prozesse machen kannst, sondern du kannst es halt auch
über einen Event-Loop
machen.
Also wie Node.js auch.
Das ist halt so der große,
aber das ist,
das wirkt sich jetzt auf
AP oder nicht AP, das wirkt sich alles
darauf gar nicht aus.
Das geht beides.
Ja, okay, das heißt trotzdem, ich mache dann halt
meine API und
ob die async ist oder nicht, macht
ja gar keinen großen Unterschied mehr, weil
Naja doch, also
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 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 es jetzt irgendwas Neues oder
so, dann kannst du es halt wahrscheinlich so ein bisschen
Aber du kannst halt nicht
eine stehende, also wenn jetzt zum Beispiel ein Chat,
wenn du sowas wie Slack
nachimplementieren wolltest,
das geht nicht so richtig gut mit Django
ohne Async, weil
wie soll das gehen? Also
wenn jetzt jemand was schreibt
und 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?
Aber das ist natürlich, generiert
einen riesen Haufen Requests, die für alle völlig unnötig
sind.
Und. Aber es funktioniert. Ja, aber das ist ja, 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.
Dass die verstoffte Datenautobahn, die verstoffte Leitung auf der Datenautobahn sind da schon.
Das ist gar nicht so das Problem, das ist halt eher so, du machst die ganze Zeit Requests, also wenn du nicht zu Hause bist und dein Rechner läuft und der macht alle 100 Millisekunden so ein Request, dann macht der halt, keine Ahnung, 10 pro Sekunde und das heißt am Tag 86.400 mal 10, also fast eine Million Requests und die sind alle leer.
Ja, ich sag ja, Stau auf der Datenautobahn.
Ich glaube, das ist noch fast das
geringste Problem, dass da Daten übertragen werden, aber der Server
muss ja dann jedes Mal irgendwie die Datenbank fragen
und keine Ahnung.
Ja, also genau, es ist so ein bisschen
während, wenn halt...
Die Computerstunden und Strom dabei verbraucht wird.
Ja, ist halt alles so ein bisschen und das ist halt
wenn es jetzt anders gehen würde
mit Asyn geht das
halt dann, dass
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 überhaupt nichts
hin und her geschickt, bis zu dem Zeitpunkt, wo das
halt passiert.
Und das ist natürlich schon deutlich effizienter.
Und eben eskaliert
halt nicht. Mit 10 Leuten
ist es egal, wenn du in einem Channel bist, aber wenn du
sowas wie Slack betreibst mit hunderttausenden Leuten
oder Millionen, dann
bringen dich natürlich diese ganzen Requests
irgendwann um.
Da brauchst du irgendwas, was
dir ermöglicht, vom
Server aus auch dem Client irgendwas zu sagen.
Also das ist diese Async-Geschichte.
aber das hat mit,
ob jetzt APIs oder nicht APIs oder so,
das ist alles,
und eine API kann natürlich auch Async sein,
du kannst natürlich dich,
ja, also,
aber das geht,
eine API oder nicht API,
das geht beides.
Mit was redet man denn mit der Django-API?
Macht man dann ein Axios,
irgendwie so ein JavaScript-Framework,
oder nimmt man da einfach normale ...
Die unterschiedlichsten Clients,
also für GraphQL gibt es halt Relay
oder Apollo.
Für REST gibt es
dieses Axios oder
weiß ich nicht, es gibt ja unterschiedliche Geschichten, die man
verwenden kann.
Man könnte
ganz normale AJAX-Requests machen, oder?
Ja, klar. Also das ist
genau.
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 Jason
einfach
an einem XHTTP-Request
oder Ajax View
machst du halt einfach, gibst du eine JSON-Response
zurück, fertig, geht auch.
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
Sachen
so machen sollte, wie man die üblicherweise
so tut.
Das musst du jetzt zweimal begründen. Und zwar einmal
erstmal, warum man überhaupt Sachen so machen
sollte, wie man die üblicherweise so 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.
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 irgendwie
Kommunikation zwischen irgendwie
einer Webseite oder einem Client und
irgendwie ihrem
Backend machen
und ü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
also ich habe noch, also
lass mal überlegen, ob ich das jemals gesehen habe, dass das
tatsächlich der Fall war. Ich glaube nicht.
Ich glaube, 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,
es ist immer crud.
Es ist immer so, also
Create, Retrieve, Update und Delete.
Genau. Und du hast
immer Listen von Dingen und immer
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 auch von Applikationen so, 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 eigentlich
immer,
es geht immer so in die Richtung.
Und die Leute,
oder 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 dann 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 es halt dann Abstraktionen,
die sich bewährt
haben und das funktioniert dann gut, wenn man das genau so
macht und wenn man das halt anders macht, dann
hat man halt Schmerzen.
Und ja, das ist...
Au!
Ja.
Fußschießen oder Stolpern fallen, reintreten,
große Fehler durch die Ohren
sammeln oder...
Ja, ja, ja, aber ja, was genau, also 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, nicht nur, dass das halt irgendwie fett ist, also wenn man so eine Single-Page-App baut, ist es halt deutlich fetter, der erste Request ist deutlich größer,
es ist halt
brittle, ich weiß gar nicht, wie man das am besten
übersetzt, es ist halt so
es ist viel instabiler, als wenn man jetzt einfach nur
ein schnödes HTML und CSS verwenden würde
weil halt dieses ganze JavaScript funktionieren
muss, es ist halt, wenn du auf
einem Telefon bist, das schlechte
CPU hat, ist nicht so gut, wenn das auch in einer schlechten
Leitung ist, nicht so gut
also
diverse üble Nachteile
ein weiterer übler Nachteil ist
dass du jetzt State-Handling halt nicht
nur auf einer Seite hast. Also wenn das
serverseitig gerendert wird, hast du das halt nur auf dem Server.
Und da hast du halt dein,
weiß ich nicht, Framework,
dass das halt
dafür gebaut ist, mit diesem Problem umzugehen.
Weiß ich nicht, eben auch so, wenn man das
so, also die alles
All-in-One-Lösung wäre dann halt
sowas wie Ruby on Rails oder halt eben
Django.
Aber dieses Problem hast du dann halt nur da
und sonst eigentlich nicht mehr.
Und wenn du bei so einer
Single-Page-App, hast du 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.
Zweimal mit Logik umgehen heißt doppelter
Anteil an Fehlern.
Und auch doppelte Menge an Code.
Doppelte Menge an Code, bei dem irgendwas schief gehen kann.
Und exponentiell wachst du, das heißt
eine vielfache Menge an Bugs.
Exponentiell weiß ich nicht, aber
auf jeden Fall. Je nachdem, wer das entwickelt, Jochen.
Ja.
Ich gucke jetzt niemanden,
an?
Ich habe 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
die Menge an
unterschiedlichen, komischen
Technologien und so, der Stack wird halt immer größer
und das macht es halt auch alles viel schwerer.
Also das ist schon deutlich
komplizierter als so eine einfache Webseite.
Und ja, das ist halt
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. 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 der
Applikation verwalten
können muss und
ja.
Oder sagen wir so, der State ändert sich, wenn
zum Beispiel ein 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, anzeigt
und macht jetzt einen Request
ans Backend und kriegt jetzt
zurück, okay, diese 100
Dinger gibt es. So, diese
100 Dinger ändern jetzt den State
der Client-Applikation
und wie macht man das
jetzt ordentlich? Und dann
braucht man halt da auch irgendwie sowas wie
ja,
irgendeinen Platz, wo der State gehalten wird.
Bei Django oder Rear-and-Rails
wäre das halt jetzt die Datenbank, hat man
jetzt auf der Client-Seite
nicht so, aber da kann man halt auch sowas wie so
Redux-Store zum Beispiel haben,
wo das halt, wo man
halt den State hält
und
geordnete Methoden hat, wie man darauf zugreift,
wie auch unterschiedliche Teile der Applikation
auch darauf zugreifen und wie die halt
irgendwie Änderungen daran auslösen.
Und ja,
da gibt es dann auch nette,
nettes Zusatztooling,
dass man halt dann irgendwie
auch
da durchsteppen
kann. Man kann also
man kann sich halt angucken, wie sieht
der State aus
davor, danach,
wie man kann auch die
Applikation, wenn man das rumgesurft ist, man kann
die in jeden Zustand wieder zurück
bringen, dadurch,
das ist halt sowas, also React zum Beispiel
ist relativ funktional, das ist eigentlich
sehr nett, also da nie,
da immer nur
die Seite gerendert wird
aus dem Zustand, wenn du
weißt, wie sich der Zustand immer geändert hat und
immer gespeichert hast, kannst du die Seite in jeden Zustand
wieder zurückversetzen.
Die nennen das irgendwie da
Time-Travel-Debugging zum Beispiel.
Du kannst halt, wenn du jetzt
zum Beispiel, da gibt es so eine
Browser-Extension,
die
halt den State irgendwie
die ganze Zeit speichert
und das
mit Redux checkt und da kannst du halt,
wenn du ein bisschen auf der Seite rumgesurft bist,
die Seite auch wieder in jeden Zustand zurückversetzen.
Man kann es einfach sagen, okay, nimm diesen State
und dann sagt man React
einfach nur so, okay, jetzt rendert 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
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 Elemente ausgeben,
rausgerendert, sodass halt
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.
Und der State ändert sich halt auch.
Es gibt halt Aktionen, die...
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, rendere 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 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 dass du dir so einen einzelnen
Div-Container zum Beispiel aussuchst,
den du jetzt haben willst.
Das ist nicht der gleiche Baum
wie der von der Webseite.
Das ist nicht das gleiche.
Der State ist eine andere Geschichte.
Dann musst du mir das nochmal genau erklären.
Dann habe ich das noch nicht genau verstanden.
Also State ist im Grunde einfach nur so ein Baum
von Daten irgendwie.
Was ist denn ein Baum von Daten? Ein Graf?
Nee, kein Graf.
Nein, kein Graf. Warum ist das kein Graf?
Dinge drin sein. Also insofern, aber
ja, ich weiß nicht, ich musste.
Es ist halt irgendwie alles, was
letztlich wie ein Python im Dikt.
So kann man sich das vielleicht vorstellen.
Ja, okay. So ein verschachteltes Dikt halt.
Wie so ein JSON-Struktur
mit irgendwas.
Ja, exakt.
Und
du kannst halt, als Komponente kriegst du das
halt irgendwie einen Teil davon irgendwie reingereicht.
und diesen Kram benutzt du halt,
um halt letztlich, eine Komponente
ist in 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
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 immer
weißt, sozusagen an welchen Stellen
sich am State was geändert hat,
weißt du halt auch, welche Teile
du neu erinnern musst und welche nicht.
Das ist halt schon nett.
Aber naja, also
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 dem Komplett-State der Seite,
weil das interessiert sowieso, wenn es
keine andere Komponente interessiert, dann
ist es ja sinnlos, das in so ein allgemeines Ding zu
schreiben.
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, 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 Client-Seite machen, du musst es einmal wieder
auf Server-Seite machen, weil auf Server-Seite musst du es
natürlich immer noch machen.
Auf der anderen Seite bekomme ich dann ja aber dann wieder nur
meine API, meinen Rest oder was auch immer
und habe dann irgendwelche Error-Feedbacks,
die ich geben kann und wo dann irgendeine Message drinsteht
und das ist ja dann doppelt und dreifach hässlich.
Also dago baue ich ja
einmal die Formklasse,
pipe die da rein, mache dann
ein, zwei Widget-Einstellungen und das läuft, das Ding.
Und inklusive
Feedbacks und
Ja, aber es ist halt so,
also ich meine, gibt es keine,
kommen wir nicht drum rum, du verwendest halt
bei einer API dann nicht irgendwie
eine Form-Klasse, sondern halt ein 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 das auf der kleinen Seite halt nochmal.
Was macht denn ein Serializer
anders als eine Form?
Ich würde sagen, es ist
relativ ähnlich.
Aber
es
serialisiert und
Dinge nach
sozusagen Dict und
von irgendwie
Dict nach, also von Objekt
nach Dict und von Dict wieder zu Objekt.
Das ist halt das, was Serializer machen.
Und Formulare machen
das auch.
Mehr oder weniger. Aber die
Formulare,
lass mich überlegen,
das ist halt so ein bisschen anders.
Das ist halt nicht immer, also bei
den Serializern, die können natürlich auch nach XML oder so,
aber eigentlich ist es immer JSON.
Ja.
Und es ist tatsächlich
sehr ähnlich, was sie machen.
Also die Validierung ist, glaube ich,
vielleicht so ein bisschen anders.
Das ist 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, ja.
Ist aber auch, das sind halt Feinheiten,
das ist halt nicht mehr so. Also im Grunde
aber, du hast halt sowas wie Formular
Validierung, musst du an der API
natürlich auch machen.
Ja, und das
musst du auf dem Client halt auch machen, das heißt, musst du halt doppelt
machen.
Es gibt natürlich unter Umständen, wenn du jetzt rein in
JavaScript bleibst, die Möglichkeit, dass halt, 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 wird sich auf jeden Fall
sagen, dass wenn man das sowieso zweimal machen muss, dann
muss 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 reblassen, wenn ich nicht will. Also die muss ich ja
nicht mal im selben Repo halten, weil die
voneinander 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.
Nee, ja,
das kommt halt drauf an auf deine Anwendungszahl.
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.
Das ist halt, 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
bei kleinen repositories wäre es halt dass du dass du zum beispiel auch sachen rausgeben kannst zum
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 jetzt ein Teil ist, der nicht
den Kern von dem, was
du tust, irgendwie betrifft oder so.
Ja.
So war es zum Beispiel. Ich weiß es
nicht so genau. Aber
ja.
Wenn du ein Repository hast, wird es natürlich
einfacher, das Ganze zu verwalten. Ich meine, du musst halt
nicht,
hast halt
eben nicht das Problem, dass du dann vielleicht noch
irgendwie die Sachen, die
sowieso alle eigentlich mit zu deiner
Software gehören, nochmal alle zusätzlich
als Pakete installieren musst, was halt vielleicht
nicht so toll ist.
Also, ja.
Okay, aber Frontend
und Backend vielleicht dann wenigstens so ein bisschen
drin. Also ich würde es nicht machen.
ist Geschmackssache. Es gibt Leute, die machen das.
Ja.
Also
der
Nachteil ist halt, wenn du das so machst,
dann kriegst du die
ordentlich dazu zusammenzuarbeiten. Wie machst
du denn End-to-End-Tests? Das ist halt schwierig.
Ja.
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.
Was möchtest du machen?
Also ich habe jetzt mein Django Headless, ja.
Da ist die API und 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 dann
komplizierter.
Was wird umständlicher?
Allein sowas wie, wie testest du denn dann?
Wie testest du deine
Desktop-Applikation und deine View-
Test gibt es auch gar nicht.
Ja, aber
jetzt hast du das in unterschiedlichen Repositories.
Du hast jetzt deine Fixtures, 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 unanfänglich?
Ja, aber wenn du jetzt festgestellt hast,
oh, dieses Ding muss ich unbedingt testen,
das willst du doch vielleicht in einem anderen Ding auch getestet haben.
Und wie würdest du das machen,
wenn die beide gleichzeitig im selben Repository-Mann anordnen sind?
Dann sind deine Testdaten beide gleich.
Und das funktioniert auch.
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 groben bleibt?
Also, 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.
Tja, 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
ob diese Komplexität
gerechtfertigt ist. Ob die Vorteile so groß sind,
dass die zusätzliche Komplexität
halt irgendwie
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
ich meine, wenn man jetzt alleine entwickelt, dann braucht man
Docker nicht. Also es 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, benutze ich kein Docker.
Außer
ich deploy es halt irgendwie da.
Zum Deployen benutze ich schon Docker, aber
Ja, ist halt die Frage, also wann das halt
macht und wann nicht. Deployen ist auch noch so eine Sache,
also weil, wie die
planen sich dann überhaupt so ein Frontend? Also ich habe ja jetzt
tatsächlich irgendwie dann diese ganzen Systeme, die
Live-Development-Server haben,
also in JavaScript, da gibt es
irgendwie jetzt npm oder yarn und
node oder
warum benutze ich das eine, aber das andere
mal hin und her und, also ich habe
jetzt erst mal yarn benutzt, weil es so ein bisschen ähnlich von
Potree war. Ja, also yarn
ist ein bisschen neuer,
die 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 Django
zum Beispiel einbauen möchte,
dann muss ich die ja alle packen.
Ja, das ist alles...
Ich hab 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.
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 halt, 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's
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
ein Vortrag von
Jacob Captain Moss, also einem der
Django Gründer
und
der Talk hatte den Titel
Assets in Django without losing
your hair.
Ah, dann denkt man sich so,
das habe ich mir auch gedacht, dann habe ich mir
das so super endlich erklärt, wie man das richtig macht,
ohne dass es so kompliziert wird.
Und dann, ja, sagte er
dann halt so an den ersten Sätze,
die da, 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 fand 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 und man kann
nichts machen.
Tja, leider verloren, aber
ich erzähle euch jetzt trotzdem, was ich alles rausgefunden habe
und
ja, es ist leider
nicht einfach und
das ist, also eine Geschichte bei Django ist zum Beispiel
blöd, dass das 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 unbedingt, man kann ja
Static Files dir einfach auf Assets
setzen, Dango. 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ß der Teufel irgendwie.
Das
wird man halt nicht so leicht los.
Man kann aber immerhin da in die Konfigurationsparameter
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
der,
ja, also man,
es gibt
so eine Indirektion, die so ein bisschen komisch ist.
Die ist nicht so intuitiv.
Zum Beispiel,
das wird auch oft aufgerufen,
wenn man jetzt
deployed zum Beispiel oder halt auch
gibt es so ein Ding, das nennt sich
CollectStatic, ein Kommando, ein Management-Kommando.
Und was das macht, ist,
es kopiert halt alle
nackte
Dateien aus der Static-Files
oder
einzelnen Apps, die man irgendwie, kann man
einzelne Static-Files hinlegen, einzelne Assets
und die sammelt das alle ein, wenn das irgendwie
eingestellt ist richtig und speist das dann
alles in den Ordner Static-Files rein, wo man
es abrufen kann fürs Deployment.
Ja, nee, es macht sogar
auch noch mehr. Es deployed 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 weit neu schon mitbeteiligt?
Was ist das überhaupt?
Ja, weit neu ist
eine ganz andere Geschichte.
Also
diese Static-Files-Geschichte
in Django ist halt, also diese
Indirektionen 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 fertig.
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 verknüpfen? Kann man
es, ich weiß nicht,
ob das eine fehlenswerte Geschichte ist, ich möchte
ja nicht.
Gute alte Zeiten hier.
und ja, das ist halt
blöd und das wird man auch nicht so richtig los und
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 sich
im Entwicklungs
Umgebungsfall
halt einfach dann vom
Django-Entwicklungs-Server 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 Entwicklungsversion,
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 Produktions
Deployment auch
und dann
was auch in dem Vortrag
dann halt
gesagt wurde, ist halt, was man tun kann, ist man
Präfix das dann halt irgendwie mit, damit
man halt nicht Produktionsassets überschreibt oder so
Präfix das halt mit Entwicklungs
Version oder sowas
mit Develop davor oder so
und naja, aber
und hätte
dann halt sozusagen die gleiche Umgebung, 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.
Ja, aber
es ist natürlich auch irgendwie doof,
dass man dann immer, wenn sich irgendwas geändert hat,
dann das dann plötzlich, dass man
dann Collect Static aufrufen muss und so.
Ja, also direkt irgendwie kleine
zwei Pixel geändert und dann einmal bitteschön nach S3
ab und so. Ja, genau.
Das ist natürlich auch wieder so.
Aber es gibt halt keine tolle Lösung
dafür irgendwie. Das ist immer ein bisschen
doof, egal wie man es macht.
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.
Und früher ging das so gar nicht, aber mittlerweile mit White-Noise kann der Applikations-Server statische Files ausliefern. Das ist ein Teil von dem, was White-Noise macht. Der andere Teil ist, die Cache-Header richtig setzen.
So, das, was man dann tun kann, ist, man liefert irgendwie die Assets aus über den Applikations-Server und packt dann halt ein CDN davor, dem 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 Applikations-Server und caches halt.
Und die Cache-Header, die Cache-Control-Header,
die werden alle richtig gesetzt von White-Nose.
Und damit hast du halt ein System, das gut funktioniert.
Und White-Nose kannst du halt sowohl
in deiner Entwicklungsumgebung verwenden,
wie auch in deiner Produktionsumgebung.
Also eigentlich ganz, ganz cool.
Wo ich ein Problem, wo ich nicht weiß,
wie dieses Problem gelöst wird,
das ist, und das sind halt immer so Dinge,
so Authentifizierung, wie macht man das?
Was ist, wenn ich jetzt,
es gibt ja noch die Unterscheidung zwischen Static-Files
und Assets, wie sowas
wie CSS, irgendwelche Icons,
irgendwelche
JavaScript-Geschichten
oder so, die sich im Grunde ja auch
nicht wirklich ändern, die auch nicht dynamisch sind, wo auch Nutzer
irgendwie nichts damit machen können und halt sowas wie,
das ist in der Django-Welt, heißt das dann Media,
wo
zum Beispiel User-Uploaded
hochgeladene Geschichten drin landen.
Und
jetzt ist es halt auch so, manche von den Sachen willst du halt nur
Leuten, die sich irgendwie
authentifiziert haben, zugänglich machen.
Und
das ist halt auch so, wie macht man das
eigentlich richtig? Ich habe 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 irgendwie
einen Webserver
hast davor,
der das halt
ausliefern kann theoretisch, also irgendwie
in Nginx oder so.
Und da geht halt
ein Request
rein nach jetzt irgendeinem Bild
oder nach irgendeiner Datei.
Und
der Applikations-Server schickt dann halt bloß
zurück, okay,
der Request ist autorisiert oder nicht.
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 übel,
wie man das jetzt mit White-Noise hinkriegt.
Ich habe keine Ahnung.
Aber das sind alles Dinge, die sind nicht so richtig einfach.
Ja, aber tatsächlich
für so statische Assets ist wohl der
Weg zur Zeit
White-Noise
zum Ausliefern und dann halt,
wenn man skalieren muss, halt ein CDN
davor. Und vorher,
wenn man den JavaScript-Frontend dann quasi gebaut hat,
wird das mit Webpack
so ein Bundle gepackt und
Chunk-Vendors ausgeliefert. Das ist nochmal
ein anderes Problem im Grunde. Also das ist das Problem,
dass man halt, wenn man jetzt irgendwie
eine JavaScript-Applikation
im weitesten Sinne irgendwie entwickelt,
dass man
dann halt das
in einem Bundle zusammen
kopiert haben
möchte und halt auch vielleicht transpiliert, weil man
schreibt halt ES-Next oder man schreibt halt TypeScript
oder sonst irgendwas, was die Browser nicht verstehen.
Und dann muss das halt
irgendwie nach ES6 oder ES6.
Warum verstehen denn die Browser kein ES6?
Also ES6 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 wie
Babel oder was gibt es 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.
Das heißt, den ganzen neuen Code, wie er
schreibt, und was du gerade nicht all die S-T-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 allen diesen
20.000 Notpaketen, die unbedingt notwendig
sind für die ganze Anwendung,
insgesamt als Files ausdrehen.
Ja, also Webpack
ist im Grunde das Ding, was halt
einen Riesenhaufen, also das seine Applikation
irgendwie nimmt und dann spuckt es halt so ein paar
Bundles aus,
die dann halt
tatsächlich benutzt werden.
Das wäre das dann, was man in die Static Files reinpacken
kann. Genau, genau.
Aber
wo ich jetzt ein paar Mal noch mal
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
man schreibt ja auch die Pfade für die
Static-Files und so, da schreibt man ja auch
nicht direkt die Pfade
rein, sondern dafür nimmt man ja auch
das Static
Template-Tag.
Sodass halt egal, wenn ich jetzt meine
Storage, 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 dir 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 Bundles
und da gibt es dann irgendwas, Django Webpack Loader
oder so und dann
da sagt man dann irgendwie Render Bundle
und genau, dann
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
Developer-Server nicht kaputt geht.
Aber ja.
Ja, aber es ist ganz schön kompliziert
und ich meine, es gibt ja auch dann
tatsächlich muss man sagen,
Webpack ist halt wahrscheinlich das,
was man verwenden muss.
gibt es keinen, nicht so wirklichen Weg drumherum.
Es gibt auch noch Django-Kompressor und so,
also wenn man jetzt nur CSS und vielleicht ein ganz
kleines bisschen JavaScript,
dann geht das auch alles damit gut, aber wenn man
jetzt irgendwie kompliziertere Sachen macht, dann
kommt man halt um Webpack eigentlich nicht rum.
Auch die ganzen anderen Tools, die es da so gibt,
die sind alle nicht vergleichbar
mit dem, was Webpack so kann.
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.
Für die Sachen, die es kann, ist es super, aber
das Problem ist halt, ja,
es gibt ja noch das
Kompressor-Toolkit.
Ja,
also es ist irgendwie nicht,
ja, tatsächlich läuft es momentan
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, ja,
man muss das halt irgendwie alles
integriert kriegen, ja.
Ja.
Ja, das ist so eine
Geschichte. Das ist ganz schön hakelig,
wenn man da mal so ein bisschen guckt. Das ist ja nicht nur
Pixel-Grumm-Geschubse, wenn man mal so
ehrlich ist.
Es gibt so gute Witze. Ich habe letztens
wieder einen ganz tollen gesehen, wo
jemand ganz gemütlich frühstückt,
Müsli-Schale und ganz gemütlich
seine Cornflakes. Dann gibt es jemand, der
stillt Milch hin. Das ist ein Roboter, der nimmt
die Milchkanne und schüttet das dann so vor
in die Schüssel rein und er gibt dabei die Hälfte der Milch
so weg. Das ist dann so Frontend-Nutzer-Experience
und Backend der
Arm, der dann die Milch
in die Schüssel gießen muss, ja.
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,
aber 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 das,
ob da jemand Lust drauf hätte, mal irgendwie so
eine Vue-Lerngruppe
vielleicht mitzumachen
und... Ja, ich bin da freiwillig dabei.
Bitte? Ich bin da schon mal
freiwillig dabei und melde mich.
Super, dann sind wir
dann ja schon komplett.
Aber
genau,
halt auch mit viel Python und
vielleicht auch Django oder man kann auch
irgendwas anderes nehmen. Ich meine, ich hätte auch mal Lust,
irgendwie Fast-API zum Beispiel auszuprobieren.
So, Salet
unten drunter und so. Da gibt es ja auch ganz, ganz
nette Geschichten mittlerweile.
Aber halt View im
Frontend.
Genau, dann kann man da, dann schreibe
ich das vielleicht mal irgendwie auf und schicke
das mal in diese Gruppe. Das ist
View Cologne, glaube ich, irgendwie.
Die könnte man ja dann vielleicht einfach zur virtuellen
View
Da müssen wir auch nicht da wieder hinfahren.
Ja.
Und vielleicht kann man es ja dann auch irgendwie
wieder in die physische
Realität verlegen,
wenn es dann mal wieder möglich
sein sollte.
Dieser ganze Spuk,
wobei es aber... 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, sorry.
Können wir bestimmt auch noch irgendeinen,
ja, warten
jede Menge Wortwitze drauf, irgendwie.
Ja, ich glaube auch.
Verbrochen zu werden.
Ja, wir haben schon wieder
spät. Ja, es ist echt
genau. Ja, eigentlich, was haben wir
noch auf der Liste? TypeScript könnte man noch machen, aber ich meine
eigentlich, nee,
ich glaube,
ich würde auch das Unitests-Mock
vielleicht tatsächlich irgendwie einfach mal erstmal weglassen
wieder und dann...
Jetzt haben sich alle darauf gefreut, Jochen.
Ja, aber...
Wo muss ich denn jetzt aufstehen?
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 morgens, mittags, abends,
nachts, schön, dass ihr wieder eingeschaltet habt.
Habt ihr eigentlich gesagt, wenn wir das aufnehmen?
Ja, nicht, ne? Nicht konkret.
Wir haben gesagt, dass es zwei Tage
vor dem Python-Bahn-Camp 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 genau, demnächst
mehr Frontend
Backend-Integration
hier. Noch mehr.
Aber wir haben ja immer noch ein paar andere Sachen.
Vielleicht müssen wir die Frequenz ein bisschen erhöhen.
Ja, ja.
Wir haben noch einige ganz spannende Sachen. Wir brauchen
Gäste. 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
oder beißt. Ich hatte mal ein paar gefragt, aber
die haben sich alle nicht überreden
lassen.
Ja, vielleicht ändern wir das mal zu einer Jubiläumsfolge
oder sowas, aber ihr kennt das ja wahrscheinlich
in der Entwicklergemeinde, dass das leider
die Quote nicht ganz so super,
wie wir das gerne hätten.
Ja, naja.
Ja, aber das führt noch hin.
Also in Data Science, ja, ich glaube auch,
demnächst müssen wir uns mal ein bisschen darauf fokussieren.
Vielleicht liegt es auch einfach an uns und wir sind zu
beschroben.
Ja, das kann auch gut sein.
Ja, aber ansonsten, ja, alles klar.
Ja, genau.
Vielen Dank, dass ihr eingeschaltet habt.
Macht euch noch einen schönen Abendtag morgen.
Bleibt weiterhin gesund und
hoffentlich bald mal wieder in live
auf einem der schönen Events hier in der Ecke.
Alles klar. Tschüss.