Hallo liebe Hörerinnen und Hörer, willkommen zum Python-Podcast, heute in der Episode 2 to the Power of 5, Episode 32.
Heute geht es vor allen Dingen um DjangoCon und so ein paar Sachen drumherum.
Jochen hat einen kleinen Stream aufgemacht und sowas.
Heute ist wieder Johannes dabei. Hi Johannes.
Hallo.
Hi Jochen.
Hallo.
Ich bin der Dominik.
Ich bin der Dominik, hallo.
Genau.
Jao.
Wollen wir direkt mit der DjangoCon starten oder haben wir noch andere News, die da irgendwie reingehören?
Ja, DjangoCon sind die wichtigsten News.
Okay.
Also die paar News, die ich habe, die kann ich auch sagen, weil ich habe nicht so viel verfolgt, weil es passieren die ganze Zeit irgendwelche Dinge und ich habe keine Zeit mehr irgendwas zu machen.
Ja, Entschuldigung übrigens auch an der Stelle, dass wir euch so lange haben warten lassen, diese neue Episode, aber das war gerade absolut drunter und drüber im Privatleben, da mussten wir mal kurz ein bisschen warten.
Ja, das habe ich aber nicht vergessen. Wir machen auch weiter.
Genau, genau. Ja, dann können wir eigentlich direkt einsteigen.
Ja, genau.
Waren wir alle auf der Django-Kon?
Nein, ich nicht.
Du nicht?
Hm.
Ach, dann können wir dir ja davon erzählen
Genau, ich wollte gerade sagen, war mir zu virtuell
und ich bin gespannt, was da losgeht. Ich habe gehört, es ging los
mit Programming for Pleasure
oder wollt ihr erstmal generell was sagen?
Das ist auch gleich das erste große Highlight, würde ich sagen
Ja
Ja, ja, das war auch so ein Ding, was mich total überrascht
hat, also hätte ich jetzt
mit so einem Talk hätte ich gar nicht
gerechnet. Vielleicht mal kurz am Anfang
worum es ging, jemand hat erzählt
die meisten Menschen programmieren aus Spaß
weil es irgendwie cool ist, aber das ist gar nicht so toll
Ja, das ist so ein bisschen die Hypothese davon, genau. Also Daniela Prosida hat diesen Talk gehalten, der erste Talk in der ganzen Konferenz und war direkt großartig. Ich hatte Daniela Prosida 2018 in Heidelberg schon mal gesehen und auch da hat er einen großartigen Talk gehalten, auch völlig untechnisch, aber sehr relevant.
und die Hypothese, die er da aufstellt, ist halt, dass Programmierer Spaß an ihrem Job haben
und dass das gut für die Programmierer ist, aber schlecht für alle anderen,
weil dann machen wir das nämlich zum Spaß und nicht für das Ergebnis.
Das heißt, für uns als Softwareentwickler ist es viel wichtiger,
dass wir möglichst viel und möglichst lange programmieren können
und was dann dabei rauskommt, ist gar nicht so wichtig, weil das ist nicht das, woran wir Interesse haben.
Für mich als Chef ist das jetzt totaler Mist, das heißt, ich muss jetzt irgendwie versuchen, euch anders zu erziehen.
Also tatsächlich, ich fühlte mich, als ich den Vortrag gehört habe, und ich dachte so, wir gingen ja auch schon so los,
irgendwie so, ja, programmieren, voll gut, irgendwie total bessere...
Jeder macht das ja auch selber zu Hause.
Zu Hause noch, und ja, dachte ich so, ja, ja, voll gut.
Und dann kam irgendwann der Punkt, wo das dann umschlug und ich so, ja, kann es nicht auch sein, dass das vielleicht total schlecht ist?
und da fühlte ich mich schon ziemlich ertappt, weil ich fürchte, auf mich trifft das ziemlich genau zu.
Er wischt, oh ja.
Und es ist auch leider tatsächlich so, dass ich das Gefühl habe manchmal so, ja,
aber das ist halt auch, manchmal sind halt auch die Projekte, die man macht,
so vom Ergebnis her, da ist man gar nicht so sehr am Ergebnis interessiert, weil...
Aber das ist schlecht, Jochen.
Das ist schlecht, ich weiß.
Das hat mir jetzt jemand letztens in einem Jungle-Con-Talk erzählt.
Wo ist dein Perfect Driven Commitment?
Ja, das ist auch manchmal, aber das ist auch wirklich schwierig, finde ich, bei manchen Projekten.
also, naja
aber das Programmieren selber macht ja Spaß
und da kann man sich auch drüber motivieren, aber
stimmt, dann hat man halt mit dem Ergebnis
wenn es dann nicht so richtig passt, dann denkt man sich so
naja Gott, also mir hat es schon Spaß gemacht
Ja genau
deshalb gibt es so viel schlechte Software
und das Schlimmste ist ja, selbst wenn es schlecht ist
dann bedeutet es ja nur, dass wir noch mehr
programmieren müssen
Was ich noch nicht verstanden habe ist, warum wird die Software
denn schlechter, wenn man Spaß dabei hat?
Die wird nicht automatisch
schlechter, aber
sie wird auch nicht automatisch besser.
Und das ist so das Problem.
Was heißt denn besser? Da sind wir ja wieder
vielleicht bei so einem Quantifizierungsbeispiel.
Was das denn überhaupt ist? Ja, das spielt keine Rolle.
Weniger Fehler wäre vielleicht auch was, was Spaß macht.
Das spielt gar keine Rolle, wie du es quantifizierst,
weil das ist nicht das Ziel der Sache. Du orientierst
dich nicht daran, wie kann ich die Software besser machen,
sondern du orientierst dich
erstmal und unterbewusst daran,
wie kann ich mehr Software machen.
Das ist halt normalerweise
nicht das Ziel, mehr Software zu produzieren.
Beziehungsweise
da hat niemand was davon.
Da ist doch einer.
Ja, genau.
Derjenige, der ist hinterher nicht bezahlt.
Ja.
Okay.
Ich meine natürlich, also besonders schlimm
und das ist natürlich auch so etwas, das wird ja auch immer
gesagt und ich erlebe das auch in Projekten so,
dass es halt besonders dann
schwierig ist, wenn man halt wenig
Kontakt zu den tatsächlichen
Benutzern und zum Endkunden hat.
und das kann natürlich auch nochmal sein, dass das da so eine Rolle spielt, weil
wenn einem sozusagen der Endnutzer tatsächlich
mehr oder weniger häufiger auf dem Schoß sitzt und sagt, was ihn
quält, dann kann man ja da vielleicht so eine gewisse
Empathietransferleistung erbringen und sagen, na gut, okay,
wenn der so drunter leidet, dann kann ich da vielleicht auch mal was machen.
Das ist was anderes als ein Quengel der Manager, der wird dann gerne mal...
Ja, aber auch wenn man die Kunden nie sieht.
Quengel der Manager hat jeder.
Ja, deswegen, das ist nicht so effektiv.
oder Jira-Tickets.
Jira-Tickets machen jetzt nicht unbedingt
so eine empathische Reaktion.
Ehrlich gesagt nicht.
Ja, also
Vor allem die Art und Weise, wie man
diese Tickets dann irgendwie schätzt, wie lange das dauert,
ist halt auch so eine subjektive Sache und man kann
sich auch mal mehr Zeit lassen, mal weniger und so.
Mehr Zeit verbringen mit der
schönen ästhetischen Herangehensweise,
diese Aufgabe zu
lösen. Das ist für mich aber auch
ein bisschen die Gegenhypothese. Also auch
Software, die keinen Spaß macht zu schreiben, ist auch nicht gut.
Auch Kobol-Programme sind meistens nicht
super.
Da möchte ich niemandem vorwerfen, dass er
Spaß dran hatte, die zu schreiben.
Ist das nicht die 13. Kolonie in Battlestar Galactica?
Ja, das ist wahr.
Letztes Jahr hat man ja gesagt, das Schlimmste an
Covid-19 ist, dass es auch ein Jira-Ticket sein könnte.
Ja.
Wir müssen ein Projekt intern umbenennen, weil
weil irgendjemand das Delta genannt hatte.
Ja.
Aber ja, man fühlt sich auf jeden Fall
ertappt, weil ich meine,
jeder von uns hat schon mal Sachen so
vor sich hingedudelt und
die dann auf GitHub hochgeladen
und irgendjemand anderes muss jetzt drunter leiden.
Ja.
Also es ist auf jeden Fall schon so.
Und es ist auch genau wie
Daniel Puschida da sagt,
nicht gängig in anderen
Berufsgruppen, dass die ihre Arbeit mit nach Hause
nehmen. Also das Beispiel, was er da bringt, ist, dass
der Zahnarzt in seiner Freizeit normalerweise
keine Zähne richtet.
Sondern das macht er halt nur
Beruf. Ich stelle mir gerade so einen Zahnarzt vor,
der eine Sammlung von Gebissen in seinem Garten
legt. Ja, und dann
vielleicht auch mal ein bisschen drin rumbohrt und sagt,
hier ist aber ein Wurzelkanal, den wir
mal ganz dringend rausbohren müssen.
Ich glaube, zu so einem Zahnarzt würde
ich nicht gehen wollen. Ja, das Einzige, was mich
tatsächlich nervt am Weiterprogrammieren ist, dass ich
und Jochen unterhalten sich über die Programmiersprache Python
und das ist ja auch so ein bisschen
und so etwas Ähnliches, nur dass die Rahmenbedingungen nicht so schrecklich sind, wenn man einen Schrein hat.
Ja, und dass es auch egal ist.
Es ist kein Manager, der hinter einem steht und sagt, mach mal das hier, sondern es geht wirklich nur darum.
Aber auch da geht es ja auch tatsächlich mehr um das Ergebnis.
Da ist auch das Ergebnis sichtbarer.
Du kannst hinterher sagen, der Schrank ist gerade oder nicht.
Genau, wäre dann nicht ein möglicher Ausweg, ganz naiv, wenn man sein eigener Kunde wird,
wo man dann quasi...
Dogfooding.
Ja, dass man sagt, okay, ich bin halt dann derjenige, der am Ergebnis auch interessiert ist, weil es ist halt auch mein Produkt.
Genau, also das würde ich halt auch sagen, ganz wichtig, halt dieses Purpose Driven, dass du halt wichtig dafür brennst, dass du das machst, so wie du dir das vorstellst, weil du halt diese User Story quasi selber in dir drin trägst, ja, zum Benutzen.
Aber will ich ja meistens gar nicht.
Ja, genau, aber wenn das halt so ist
und halt irgendwie ein Management das halt nicht hinkriegt,
das verkackt, dass du halt so eine
Informationsasymmetrie bekommst zwischen
User-Story oder Management,
weiß, was richtig ist und du weißt, was du machen willst,
das wird halt schwierig zu managen.
Also das ist eigentlich unmöglich zu managen, weil du kannst,
die meisten Manager sind ja technisch jetzt nicht so affin,
kannst du irgendwas vom Pferd erzählen und das machen dann auch
irgendwann viele Leute, die halt keine Lust haben auf
irgendwas, erzählen halt auch noch von ganz, ganz
komplizierten Funktionen, die da geschrieben werden
müssen und so und dann dauert das
halt gefühlt ein bisschen länger,
bis nach zwei Zeilen fertig
und hast wieder Teil für die schönen Dinge oder so.
Du meinst,
dann kannst du noch ein paar Unit-Tests schreiben?
Ja, zum Beispiel.
So nutzt man doch dann
die Zeit, oder? Man schreibt Tests und
Dokumentation.
Ja, das fällt ja auch dann meistens immer runter, weil die Leute
sagen, ja, das ist alles total unwichtig.
Oder so Refactoring oder sowas.
Für einen selber als Programmierer
ist das nicht ganz so wichtig.
Ja, für alle Leute, die mitarbeiten, vielleicht.
Das war auf jeden Fall ein großer Paukenschlag
so direkt zur Eröffnung der Konferenz
hat auch, ist super gut
angekommen und
Programming for pleasure, Daniel Fruchti
Der macht auch sonst gute Talks, der hat auch schon welche über Dokumentation
gemacht, die ich auch sehr gut fand
Sind die eigentlich schon online, die Talks?
Ich glaube nicht, ne?
Ich glaube 30 Tage
habe ich irgendwo gehört, aber ich weiß es nicht
Wann war die nochmal genau?
Am 2. Juni
2. bis 6. Juni
Dann ist er jetzt in 10 Tagen
Müsste demnächst soweit sein
Also ich weiß nicht, wie sie es machen
Aber cool
Was hat euch denn noch super gut gefallen?
Das habt ihr vielleicht noch gar nicht gesagt
Die beiden hatten auch einen Talk
Ja, der nächste Talk, der mir sehr gut gefallen hat
war der von Jochen Wersdorfer
Fand ich sehr, sehr gut
Jochen, hast du den auch geguckt?
Ja, ich habe gerade das erste Mal
deinen vollen Namen gesagt in diesem Podcast
Oh je
Ich glaube auf der Webseite war der auch schon irgendwie drauf
Hab ich dich gedockt
Ja
Nö, das, genau
Also ich hab den auch ein paar mal
Ich hab den tatsächlich so ein bisschen dann geübt und so
Und dachte
Oh, vielleicht kann ich den auch live halten
Das hat dann irgendwie nicht geklappt, weil
mein Video, mein
vielleicht ein wenig zu elaboriertes Video-Setup
das nicht zugelassen hat, weil wenn man das als Webcam
bei Zoom registriert, dann
wird die Schrift so unscharf, dass man es nicht mehr lesen kann
und... Also um mal kurz euch vorzustellen, wie Jochen das macht.
Jochen schmeißt tatsächlich ein megakrasses
Technik-Setup, wie er schon mal gesagt hat. So, oh, Content
interessiert dich gar nicht so. Technik ist das, was wichtig ist.
Schmeißt er dann alles
halt irgendwie in OBS rein mit einer ziemlich
krassen Webcam und ziemlich coolem
Setup da auch mit seinem großen...
Was ist das für ein...
Fernsehstudio-Kontrollpult.
So ein Atem-Mini von Blackmagic.
Und tatsächlich braucht man dann keinen OBS mehr.
Das Ding streamt selber. Ah ja, okay.
Also siehst du noch nicht mal OBS, du hast einfach selbst
konfiguriert und dann...
Ja, das sah auch schon ziemlich cool aus, muss ich sagen.
Aber wir wollten das gar nicht annehmen,
hast du gerade gesagt. Ja, zurück zum Content.
Genau, das hat halt dann nicht funktioniert live.
Sonst hätte ich das auch live gemacht.
Ach, wegen Zoom? Genau, und dann musste halt die Aufnahme
verwendet werden, die überraschend früh
eingereicht werden musste. Das hatte mich auch so ein bisschen
Schweiß gekostet. Oh ja.
Und ja,
so, weil ich hatte doch gar keine Slides fertig
und so.
Ja, die Story habe ich ja noch im Ohr.
Aber jetzt haben wir schon darüber gesprochen,
was oder wie du getrugt hast.
über was denn?
Das ist ein Thema, mit dem ich seit einiger
Zeit irgendwie so ein bisschen hadere oder wo ich
dann rum
feile und zwar
was ich irgendwie ein bisschen
doof finde, ist, wenn man so
mit Files zu tun hat, also tatsächlich Dateien
irgendwie größere vor allen Dingen, also Bilder
können auch schon größer werden oder Videos
oder Audiodateien und Audiodateien hat man natürlich
irgendwie beim Podcasten
hat man das schon zu tun und
irgendwie die Seite für
diesen Podcast hier, den habe ich ja auch mal irgendwann gebaut
und da
ist es so, da verwende ich so ein CDN, um
die Audio-Files auszuliefern und
auch wenn ich das bei, jetzt in irgendwelchen
Kundenprojekten sehe oder so, wenn Leute mit Files umgehen,
dann hinterlässt das meistens
so ein, das ist irgendwie
noch nicht so richtig optimal Ding
bei mir, weil oft
hat man dann so Anforderungen wie, das habe ich
jetzt beim Podcast nicht, aber
so in
quasi, ja, wo man so
Auftragsarbeiten, dann hat man halt oft
Leute, die irgendwie Authentifizierung
und Autorisierung haben wollen
für die Dateien, weil das Sachen sind,
die nicht unbedingt öffentlich sind.
Und dann wird es schon schwierig.
Und das, was halt alle machen eigentlich, oder die meisten
jedenfalls, wo ich das bisher gesehen habe, ist,
dass sie
einfach irgendwie als Dateiname
den Hash des
Files nehmen oder so
und das irgendwo auf den öffentlichen Webserver packen
und dann sagen, naja, also
wird schon keiner finden.
Wird schon keiner erraten.
Ja, genau.
Ja, das ist wirklich so, das wird schon keiner erraten.
Nee, das ist richtig, aber das Problem ist, es kann halt
irgendwie aus anderen Kanälen halt auch rausliegen,
wie zum Beispiel irgendwelchen Logfiles oder
auf der kleinen Seite, dass halt irgendjemand
die links verschickt.
Oder das verschickt oder so.
Und dann hat man halt...
Du kannst es auch nie wieder zurücknehmen, wenn das einmal jemandem gezeigt hat,
der hat es für immer.
Genau. Und das ist halt so ein bisschen
vielleicht nicht unbedingt das, was man will.
Und wenn man dann sagt so, oh, das ist aber eigentlich vielleicht nicht so ganz so optimal,
dann kommt halt häufig so,
und Jochen unterhalten sich über die Programmiersprache Python
eigentlich nicht so richtig, dass man das haben möchte.
Und das hat mich schon immer so ein bisschen geärgert.
Also ich habe auch schon gesehen, dass Leute das richtig machen,
aber das ist halt eher so die Ausnahme.
Was wäre denn richtig?
Was gibt es denn für Alternativen?
Genau, also das, was man tun kann,
wäre halt, wenn man
jetzt quasi
das komplett alles selber hosten möchte,
vielleicht so ein Nginx davor
zu nehmen, davor zu haben.
Man hat ja sowieso immer irgendeine Art
Reverse-Proxy vom Applikationsserver
bei Django.
und da kann man ja jetzt,
also auch
diesen Lösungsansatz,
den habe ich ja von dir, Johannes.
Gibt es da was, was man mit Nginx
machen kann?
Genau.
Dann geht der Request
vom Browser aus, geht halt
direkt zum Applikationsserver, aber der
Applikationsserver schickt halt nicht
das File zurück, sondern
der schickt halt eine leere Response zurück,
der nur in Header gesetzt ist
also Xen-File oder
X-Excel heißt der glaube ich bei
Nginx, wo dann drin steht
ja, das ist schon okay und dann ersetzt der
Nginx die
leere File-Response durch die echte File-Response
und dann hat man
Wo kriegt der die her? Ja, der braucht dann halt
Zugriff auf, wie auch immer
das Verzeichnis oder was auch immer
Also halt aus einer Datei, oder?
Ja, genau
Okay, aber das ist ja schon mal ziemlich cool, oder?
dann kann ich ja sagen, diese Datei darfst du nur ausliefern, wenn folgende Vorbedingungen gelten.
Also ich kann die Vorbedingungen in meinem App-Server prüfen und das Ausliefern macht dann aber Nginx.
Also das ist ja schon mal ziemlich gut.
Und damit ist eigentlich ziemlich super, also das funktioniert tatsächlich.
Das einzige Problem, wo ich sagen würde, naja, das ist halt so ein bisschen hässlich an der Lösung,
ist, dass man jetzt plötzlich zwei Systeme hat, die Zugriff auf alle Daten haben müssen.
Also zumindest auf alle Dateien haben müssen.
Ja, okay, klar. Und es muss halt auch so verbunden sein, dass die das beide korrekt finden.
Genau, und du kannst es halt nicht mehr gut testen, ob jetzt deine
Applikation alle Sicherheitsanforderungen noch erfüllt, kannst du in Django-Tests
allein nicht mehr machen, weil dein Applikationsserver kann ja sagen,
nee, da darf jemand nicht drauf zugreifen, dein Test überprüft das und sagt so, super, hier ist
alles richtig und dein Nginx kann aber die Datei trotzdem ausliefern, weil der irgendwie falsch
konfiguriert ist oder keine Ahnung, weil da sonst irgendwie was schiefgegangen ist
und das heißt, du merkst unter Umständen nicht, wenn dein System kaputt geht, weil du jetzt
weil du den einen Teil nicht mehr so wirklich
mittesten kannst, weil es halt auch schwierig ist
das komplette System dann halt immer beim entwickeln
hochzufahren mit Nginx und dem ganzen Kram
also eigentlich müsstest du es ja dann mittesten
aber das ist halt
man verschiebt quasi so ein bisschen
was von dieser Testlast in den
operativen Bereich
im Endeffekt musst du ja dann das operative System
testen und überprüfen
und du müsstest ja eigentlich sogar
einen negativen Test machen, du musst ja nachweisen
dass Nginx diese Datei unter
keinen Umständen ausliefert, außer wenn
und das ist natürlich sehr, sehr schwierig.
Aber gibt es denn da
Echtweltbeispiele? Das passiert doch in der Echten Welt nicht, oder?
Dass irgendwas offen konfiguriert ist?
Passiert so gut wie die.
Also auch diese Leaks, die dann immer gibt.
Das passiert ja nicht.
Also ich meine, das ist auch eine der häufigsten Sachen, die man so sieht,
dass dann irgendwo jemand sich mal
irgendwelche Sachen angeguckt hat und dann
oh, was ist denn da? Hier sehe ich meine Dateien.
Was ist denn da? Gibt es da vielleicht noch mehr?
oder dass irgendwelche Backup-Server offen sind
oder dass irgendwelche Log-Server offen sind
oder dass irgendwelche...
Ja, und dann sind halt plötzlich alle Daten von allen Leuten
irgendwie öffentlich und das ist halt furchtbar eigentlich.
Genau.
Also so kann man das halt machen,
aber dafür muss man jetzt, also ich würde sagen,
das ist auf jeden Fall schon somit die beste Lösung,
die ich so gesehen habe,
wie man das richtig machen kann.
Man kann das auch noch machen,
also wenn man jetzt die eigene Infrastruktur
komplett unter Kontrolle hat, wenn man das nicht hat...
Ja, das hört sich halt auch so ein bisschen an, als wäre es ein bisschen komplexer,
zu dem NGINX zu erzählen, dass er
dieselben Sachen versteht für Authentifizierung
und Autorisierung, wie zum Beispiel die Applikations-Server
mit dem Django dahinter oder so.
Nee, das muss er ja gar nicht.
Das muss er nicht. Der Request geht ja durch
eine Applikations-Server. Das heißt, der Applikations-Server
entscheidet. Der NGINX
sieht nur den Header und macht dann
oder macht eben nicht. Das heißt, das Einzige, was man quasi machen muss,
die richtigen Header setzen und dann läuft.
Vom Applikations-Server aus, ja genau.
Das ist auch sowas. Da gab es dann in der Reaktion
auf den Talk, glaube ich, in Slack
oder so, hat dann jemand gesagt, da gibt es doch in der NGINX
und Jochen unterhalten sich über die Programmiersprache Python
und das Einzige, was daran so ein bisschen blöd ist,
ist halt, es funktioniert nur, wenn man,
also es macht die Infrastruktur komplizierter
und es funktioniert nur, wenn man die komplette Kontrolle drüber hat.
Wenn man jetzt ein CDN verwendet oder so,
geht das halt nicht mehr so richtig.
Ja, was könnte ich denn machen, wenn ich meine Dateien auf S3 habe?
Die könnte ich ja auch auf Private schalten
oder Public. Gibt es denn da auch eine Möglichkeit,
Jochen, erzähl mal. Genau, ja, also was man da tun kann,
ist, man benutzt entweder
signed cookies oder halt
signierte URLs
und
über den Applikationsserver aus. Also das bedeutet,
und Jochen unterhalten sich über die Programmiersprache Python
oder sowas, einen Aufruf oder sowas?
Ja, weiß ich nicht, ob man das da einstellen kann.
Also IP-Adressen und Zeit weiß ich,
dass es bei Amazon geht auf jeden Fall.
Und das kann man halt entweder in die URL packen
oder man kann es halt sozusagen
vom Server aus als Cookie setzen.
Und wenn das dann quasi,
wenn dieser Request, der kommt
dann darauf an, wie die Domains aussehen
und wenn das eine andere Domain ist, ist es manchmal vielleicht schwierig.
Also ob man jetzt
als Applikationsserver einen Cookie setzen kann
für die Domain, unter der dann tatsächlich
die Files liegen. Aber wenn das kann,
kann man das halt auch einfach so als Cookie setzen.
Und
ja, das
funktioniert halt auch.
Das ist auch
richtig, eigentlich sozusagen
in Anführungsstrichen ordentlich, aber
man hat halt immer noch das gleiche Problem,
dass, oder eigentlich ist es ein bisschen
schlechter als die Lösung mit
dem Nginx, weil man halt nicht wirklich
von dem CDN aus überprüfen kann,
ob die Autorisierung noch da ist oder nicht.
Also wenn man jetzt im Django-Admin sagt,
diese Files dieser User darf ich nicht mehr sehen,
dann kann das halt nicht sofort
funktionieren, sondern wenn man halt eine gültige URL hat,
dann
funktioniert die erstmal weiter,
zumindest 30 Minuten lang oder so. Gut,
ist dann halt nicht mehr so schlimm, als wäre die für immer gültig,
aber
auch da reicht es ja unter Umständen schon,
um irgendwie die Daten
rauszukriegen.
Es ist halt so ein bisschen, also es ist besser als nichts
zu machen, aber es ist halt immer noch so ein bisschen so,
so richtig schön ist es eigentlich nicht.
ja, und
genau.
Ja, also das sind halt so die beiden Ansätze, wie man das ordentlich macht eigentlich.
Aber was ist denn jetzt die richtige Lösung? Was kann man denn heutzutage noch besser machen?
Genau, meine Idee an der Stelle war, okay, naja, es muss im Grunde über den Applikationsserver gehen, weil der der Einzige ist, der weiß, ob jetzt ein User irgendwas sehen darf oder nicht.
Das kann man auch nicht irgendwie großartig anders machen, ohne Probleme zu bekommen.
wie wäre es denn, wenn der einfach selber
die Files ausliefert?
Aber davon wird ja erstmal abgeraten,
oder? Weil dann sind die Worker beschäftigt
und dann hast du nur so und so viele
App-Server und dann
sind die langsam und brauchen viel
Speicher und so. Genau, also
in allen Tutorials und so steht immer drin so,
ne, macht das nicht, also wenn ihr irgendwie Files ausliefern wollt,
macht das über einen getrennten
App-Server, der da statische Files direkt ausliefern kann, oder
macht das mit White Noise und CDN oder so,
aber macht das nicht über den Applikations-
Server, weil das Problem beim Applikations-
Server ist halt, dass es normalerweise standardmäßig
ein Pre-Forked
also sozusagen es gibt
mehrere Prozesse, die halt Requests
beantworten, davon gibt es halt so ein paar, eine Handvoll
vielleicht oder sagen wir mal so im Allgemeinen
vielleicht zweimal Anzahl der
Koas plus eins oder so, was halt
halbwegs optimal ist
und
solange die irgendwas ausliefern,
sind die halt belegt und wenn ich jetzt ein File
ausliefer, das groß ist oder
und Jochen unterhalten sich die Programmiersprache Python und wenn alle Workerprozesse belegt sind dann kann niemand mehr anrufen Ah ich wei worauf das hinausl Und genau Ja daher sollte man das nicht machen weil wenn und das kann schnell passieren
wenn man eine Webseite hat, da sind ja viele Bilder drauf.
Auch die Browser, die
fragen ja inzwischen concurrent ab
und so, dann ist halt relativ schnell
vorbei mit den Workern.
Und ja, dann
müssen halt andere Clients
warten und das ist natürlich schlecht, weil das
hat halt direkten Einfluss auf die
User Experience, weil entweder dauert es länger oder
noch schlimmer, es gibt halt eine Fehlermeldung, weil
irgendwas timeoutet. Das heißt, man müsste
die auch concurrent bedienen. Genau.
Und das kann dieses Preforged Worker
Modell synchron Sachen ausliefern
eigentlich nicht leisten.
Deswegen wird immer davon abgeraten.
Aber wir haben
ja jetzt Async Await
in Python seit einiger Zeit.
In Django
noch nicht so lange, weil da konnte es halt lange
nicht so richtig verwendet werden, weil
die Standard-Schnittstelle zwischen Applikationsserver
und Web-Framework
ist halt WSGI
und WSGI kann das halt einfach nicht.
Das sind halt
synchrone Funktionsaufrufe, da kannst du auch nichts machen.
Und
ASGI, also der
Nachfolger, der halt dann auch
sozusagen asynchrone
Dinge
kann, der ist halt noch nicht so alt,
ist auch quasi im Kontext von
im
Django-Kontext irgendwie entstanden.
Der ist, glaube ich, von Andrew Godwin geschrieben worden.
Ja, das ist, glaube ich, ein Janals-Projekt.
Ja.
Genau, und damit geht das
dann, aber Unterstützung
für die Syntax war auch lange nicht möglich, weil
weil halt
Django lange Zeit noch Python 2 zum Beispiel
unterstützt hat, bis Dezember 2019,
also bis Django 3 rausgekommen ist.
Und mit Python 2 geht es gar nicht,
weil da gibt es einfach nicht die Syntax für,
so Async-Awaid-Syntax
geht damit nicht
und auch mit
Python 3.5 ging das nicht gut
ich weiß ehrlich gesagt nicht genau, woran das liegt
also die Syntax kam eigentlich mit 3.5
aber alle Bibliotheken, die das irgendwie
die Async-Awaid unterstützen, die sagen alle immer
ja, erst ab Python 3.6, da ist wohl irgendwas
Wichtiges noch passiert, aber ich habe nie so richtig rausgefunden
was, vielleicht sind es auch einfach nur
die F-Strings und alle sagen so
wenn wir jetzt schon was Modernes haben, wollen wir auch F-Strings haben
und dann geht das halt erst ab 3.6
ich habe keine Ahnung
und
Ja, aber ich meine 3.5 und 3.6
macht jetzt für uns nicht so den Riesenunterschied, oder?
Wir sind ja alle modern.
Debian ist inzwischen auf 3.8 und
Oh wow, okay.
Genau, jedenfalls also
die Syntax kann man
also dass es überhaupt geht
ist halt ab Django 3.0 so
Support für Python 2
und für Python 3.5
gedroppt und seitdem
gibt es auch Unterstützung für SGI
und halt auch prinzipiell die Möglichkeit
Async-IO-Syntax zu verwenden
in Django. Aber es gab noch keine
Async-Views. Das heißt, man
konnte keine Async-File-Response
schreiben, weil
Async-Views gab es halt einfach nicht.
Und das kam erst dazu im
August letzten Jahres, August 2020.
Das heißt, es geht noch gar nicht so lange.
Also 2019 meinst du?
Nee, 2020.
Django 3.2.
Ja, war doch 2019.
Ach ja.
Ja, okay, auf jeden Fall gibt es das erst seit ungefähr einem Jahr
Genau, und damals hatte ich ja auch schon
Warum ist das cool?
Ja, das ist eigentlich, genau, das ist halt total cool, weil
das bedeutet eigentlich, dass man jetzt so richtig
Async-Sachen mit Django tun kann
was man auch nicht tun kann, was auch
total cool wäre, aber das wird halt noch ein bisschen dauern, ist halt
tatsächlich
Async die Datenbank fragen
oder so, aber man hat zumindest schon mal Async-Views
und das ist halt
hilfreich, ich hatte dann
Ich hatte damals einen Artikel auch drüber geschrieben
mit Dominik zusammen.
Genau, der ist sogar in der Zeitung erschienen,
auch bei euch dann und auf deinem Blog.
Echt? Cool.
Darf man das sagen, Entwickler?
Ja, schick das Magazin.
Und
genau, da haben wir
überlegt, okay, was für Anwendungsfälle gibt es denn
jetzt eigentlich, wenn man schon Async-Kram machen kann?
Und
der Anwendungsfall, den wir dann
da benutzt haben, war, du machst halt
in der Django-Applikation
vielleicht ganz viele API-Zugriffe irgendwo nach außen hin
und möchtest halt nicht, dass
sich die Latenzen, die du dann beim
Abfragen dieser Requests hast, halt
aufsummieren, sondern dass halt
die Latenz nur
so lang ist wie der längste Request, den du machst.
Und dann schickst du einfach all die Requests, die du zu
irgendwelchen APIs machst, gleichzeitig los
und die Antworten
kommen halt sozusagen dann auch concurrent zurück
und nur
die Latenz wird bestimmt durch die
langsamste API, aber nicht mehr
durch die Summe aller Requests.
Und das macht es dann halt schon deutlich
schneller. Also wenn du da viele APIs fragst,
dann kann es sein, dass du da halt in Größenordnungen
schneller bist oder so.
Und das ist dann ja schon praktisch.
Und das war so der Anwendungsfall.
Haben wir da nicht auch drüber gesprochen
in der Async-Episode?
Ja, ja, bestimmt.
Da haben wir ja auch schon mal zwei Episoden dazu gemacht.
Ja, das ist halt...
Wir brauchen noch mehr.
Da kann man immer noch mal drüber sprechen.
Wenn man ein Thema einmal drin hat,
Da muss man das auch ein bisschen ausschlafen.
Ja, genau.
Aber jetzt ist mir dann halt irgendwann,
das war so Anfang des Jahres,
dann dachte ich so, ach, wenn man jetzt schon so async await hat,
vielleicht ist ja tatsächlich Files-Serve
ein guter Anwendungsfall,
weil es ist ja immer so ein bisschen hässlich,
so richtig toll ist es nie
und eigentlich könnte man ja jetzt
eine async-file-response schreiben,
die die Daten sozusagen
da so asynchron rausstreamt,
ohne zu blockieren
und dann müsste das ja eigentlich,
müsste ich ja quasi beliebig viele
Clients
den Files ausliefern können.
Und dann habe ich dann halt so ein bisschen rumprobiert
und ja, hat so ein bisschen gedauert
und irgendwann aber
okay, das funktioniert tatsächlich und
ja, dann habe ich daraus halt
dann hat der Johannes
erzählt, dass er dann irgendwas bei der
Django EU eingereicht hat und da dachte ich so
das muss ich dann auch machen.
Den Talk eingereicht haben.
Der soziale Druck.
Ja und
und genau, das war dann auch Thema des Talks im Grunde und es funktioniert auch tatsächlich.
Ich habe unterwegs auch Methoden gefunden, wie man das Gleiche hinkriegt und auch schon vorher hinkriegen konnte, ohne sich so zu verrenken.
Insofern war es vielleicht alles nicht so richtig notwendig.
Ja, aber das ist ja schon sauberer, was du da geschrieben hast.
Wir haben ja die Tests gesehen und in einigen Tagen kann vielleicht jeder auch sich diesen Talk selber angucken.
Ja, ich packe das.
Ist ja schon deutlich sauberer und deutlich einfacher.
Wirst du das auch
an Django schicken?
Ich mache dann einfach ein
Party-Package draus.
Das wäre ja prinzipiell was, was
vielleicht auch für Django an sich ein Gegenstand ist.
Ja, das Problem ist,
leider funktioniert es nicht so
richtig, kann man es nicht einfach in Django,
könnte man es nicht in Django reinbauen
oder könnte man schon, aber dazu müsste man
den SGI-Händler,
das Ding, was halt mit
die Applikation ist, quasi die
SGI-Applikationen, das ist halt der
SGI-Händler in Django.
Ach, den hast du einfach mal gemunkeypatcht, oder?
Naja, den müsste man
anpassen und das ist natürlich nicht so schön.
Aber das ist in NPR auch prinzipiell möglich.
Oder dass man Subklassen
anbietet oder sowas.
Ja, muss man vielleicht mal
mit jemandem drüber sprechen.
Ja genau, dann machst du halt den ASCII mit
Async-File-Response-Händler.
Genau, aber den habe ich jetzt einfach
erstmal in einem anderen Paket drin und wenn man
das verwenden möchte, dann muss man halt
muss man halt entweder get
async-file-response-handler
oder so eine Application
irgendwie importieren oder halt den Händler direkt
und dann die Applikation selber instanziieren
und dann geht das, aber das ist halt schon
ein Umbau an Django. Das Problem ist, ich weiß halt nicht, was das
alles kaputt machen würde.
Da kann es schon sein, dass einige Dinge nicht mehr
auf der Händler sind.
Ja, klingt auf jeden Fall ziemlich cool.
Das heißt, man kann jetzt einfach mit dem Django-Applikations-Server
seine Files direkt ausliefern.
Man muss sie nicht mehr irgendwie außen
vom Web-Server quasi routen lassen.
Man kann direkt sagen, Django, hey, nimm die doch mal direkt aus.
Weiß nicht, was nutzt man dafür? Django Storage ist raus
oder so und liefert die mal mit.
Ja, und das war damals,
als ich den, damals, vor zwei Wochen,
war das noch nicht so klar.
Also man kann auch
irgendwie ein selbst gehostetes
S3 oder so benutzen, weil das ist ja eigentlich,
das war auch mein Ziel. Ich habe es mit dem
File-System gezeigt, aber File-System ist ja eigentlich so ein bisschen langweilig,
weil... Wie hostet man S3 selber?
Minio? Minio, genau.
weil man möchte eigentlich nicht, dass
User
selbst so Content
Files, wo sie Content kontrollieren, in das gleiche Filesystem
nehmen kann, in dem die Applikation läuft
das ist halt auch so ein bisschen gefährlich
und man hat dann das Synchronisationsproblem
kann man natürlich irgendwie so ein
Samba-Share nehmen oder NFS oder was weiß ich
geht alles
aber ist halt auch so ein bisschen
Ancient Relay
ja
also die Standard
Standard
Geschichte, wie man das selber hostet momentan,
also so ein Object Store wie S3
oder so, ist halt
wohl momentan Minio.
Da müssen wir ja quasi direkt so einen kleinen Exkurs machen,
weil an der Stelle, das hast du alles gezeigt
auf deinem neuen Twitch-Stream.
Genau, genau, genau.
Das und die Entwicklung daran,
die habe ich jetzt gerade mal gestreamt, weil ich dachte so,
jetzt konnte ich dieses Atem-Mini-Dings da gar nicht
auf den Talk einsetzen, da muss ich es
auf irgendwas anderes benutzen.
Also Jochen hat tatsächlich in der letzten Woche oder in den letzten
zwei Wochen ein bisschen mehr auf Twitch gestreamt und auf YouTube
gleichzeitig und da seine Sachen hochgeladen,
da könnt ihr ein bisschen beim Live-Programmieren mal gucken,
das ist vielleicht ein bisschen was anderes, als nur so zu
theorisieren,
sondern halt auch mal tatsächlich live zu sehen, wie Jochen
das denn so macht. Wie ich da vorsitze und keine Ahnung, was ich da eigentlich
tue. Genau, Jochen ist auch noch Mensch und macht die ganze Zeit
Fehler und so und mir fällt es, wenn ich da vorsitze,
ich möchte die ganze Zeit hier so einen Stock nehmen.
Ja, bitte?
Kann man sich wünschen, was du programmierst?
Du programmierst nur, was dir Freude macht.
Ja,
prinzipiell kein
Problem, ja klar.
Vielleicht gegen eine kleine Spende
kannst du vielleicht
Requests annehmen.
Ja, genau.
Mir sind auch immer wieder aufgefallen, schöne Sachen da bei dir,
die du schön gemacht hast.
Ich packe den Link mal rein, mal gucken,
ob da...
Das hätte ich doch ganz anders gemacht, fällt Jochen dann eine halbe Stunde
später auf, oh, das kann man ja auch anders machen.
Ja, aber ich meine, so ist das halt.
Mir sind da auch schon tatsächlich live Dinge
passiert, wie...
Ich habe da live einen Bug in irgendeinem
in einer Library gefunden sozusagen
und dann sitzt er da. Also ich hatte
bisher immer so den Impuls dann zu sagen so, okay,
das muss ich dann mal irgendwann debuggen, wenn ich Zeit
habe, weil das ist zu langweilig.
Immer wieder.
Aber das ging, glaube ich. Also ich meine,
aber es ist ja vielleicht auch ganz gut mal zu sehen,
wie man das rumsucht.
Also Jochen benutzt dafür übrigens NBDEV.
Da hatten wir auch schon mal ein bisschen eingeleitet.
Genau, das mache ich eigentlich nur, weil
ich das Projekt ganz cool fand.
Das mache ich jetzt nicht unbedingt mit allen Sachen so, aber
für das Ding dachte ich...
Ja, du musst das nämlich dann nochmal anders machen.
Also nochmal in VI
und einmal in VS Code oder so, da kann man schauen.
Vielleicht sogar in PyCharm, dass man so ein bisschen einmal zeigt,
wie das denn überall so geht.
Genau, das habe ich auf jeden Fall auch vor.
Ja, genau.
Ja, vielleicht kriegen wir das ja auch mit dem Podcast
nochmal so ein bisschen
ja, den
vielleicht so ein bisschen Video
live schalten.
Ja, also jetzt mal gucken, ob wir dafür
Zuschauer bekommen, begeistern können.
Ja, cool.
Genau, so, das war das
Ja, ich glaube, noch jemand hat halt tatsächlich einen Workshop bei der
Dank bekommen. Was, noch jemand?
Ja, ich bin ja quasi schuld dran,
dass Jochen den Talk
überhaupt eingereicht hat, weil ich habe das nämlich auch gemacht
und das war bei mir auch so ein bisschen
so halb spontan
Also danke, klar
Nee, eigentlich überhaupt nicht, weil
die Botschaft auf der Webseite
die die Organisierer, die übrigens
großartig sind
so verbreiten, ist ja
ja, selbst wenn du dir nicht sicher bist, probier es halt
mal. Komm, reich was ein, im schlimmsten Fall machst du keinen Talk. Im schlimmsten Fall musst du einen Talk machen.
Und so war es dann auch so ein bisschen. Ich habe mir überlegt, was
andere Menschen interessieren könnte und was ich Interessantes sagen könnte
und habe es einfach mal so ein kleines bisschen reingeschrieben. Die Talk-Beschreibung
hat sich dann auch im Laufe der Zeit noch mehrmals geändert. Es ist auch nicht
genau das gewesen, was ich mir anfänglich gedacht hätte. Aber ja, ich habe einen
Talk eingereicht, der dann als Workshop akzeptiert wurde.
und es ging so ein bisschen darum, wie ich Django-Projekte mache.
Also so ein bisschen das, was du auch von dir in unseren Podcast-Folgen erzählt hast wahrscheinlich.
Genau, so ein bisschen Best Practices oder Programmierer-Erfahrung.
Ich programmiere jetzt schon sehr lange in Django.
Ich habe mal nachgeguckt, welches die erste Version war, die ich benutzt habe.
Das war die 0.96.
Ist schon eine ganze Weile her, das war 2005.
Also ich habe jetzt tatsächlich 15 Jahre Django-Erfahrung 15? Das sind ja noch 2020 Ja, wieso? Ich habe das eben nicht verstanden Wir müssen das jetzt einfach so lange wiederholen, bis wirklich jeder glaubt Ich habe also über 15 Jahre Django-Erfahrung und da sammeln sich einfach so Dinge an, die man sich angewöhnt, an die man tut und die dann auch sinnvoll sind
Best Practices dazu zu sagen, ist ein bisschen zu hoch geflogen, weil Best Practices heißt ja, dass das jeder so macht oder jeder so machen sollte und so weit will ich gar nicht gehen. Ich will eigentlich nur sagen, hier folgende Dinge haben sich für mich bewährt und hier ist auch die Begründung.
und ja, das habe ich dann so ein bisschen da reingepackt.
Also ich hatte vier Bereiche
mir aufgeschrieben.
Während des Live-Talks
sind es dann leider nur drei Bereiche geworden,
aber es gibt ja genau
wie beim Jochen auch eine sehr frühzeitig
eingereichte Aufnahme,
die auch auf meiner
Webseite zur Verfügung steht. Können wir nachher gerne
verlinken. War glaube ich auch ein bisschen mehr
für Einsteiger geeignet, glaube ich, den Talk, den du gemacht hast,
als das, was Jochen jetzt... Ja, es
war so ein bisschen gedacht, dass ich vier verschiedene
Bereiche habe und manche sind für Einsteiger
gut und manche sind eher für
Fortgeschrittenere gut.
Was dann halt am Ende
so ein kleines bisschen rausgefallen ist.
Diese Einsteiger-Sachen, wobei auch
erfahrene Leute,
ich wechsle da immer so hin und her,
der Bereich, der mich da
hauptsächlich beschäftigt war, ist Projektstruktur.
Wo kommt Code hin?
Wie heißen die Dateien? Wie sorge ich
dafür, dass ich die Sachen alle wiederfinde?
Wie sorge ich dafür, dass ich auch
in einem großen Projekt den Überblick bewahre?
und sowas halt.
Ich wechsle da immer so hin und her. Es gibt ja Leute,
die sind da ganz krass drauf. Die haben dann ihre
extrem angepassten Cookie-Cutter-Vorlagen,
wo alles anders ist,
wo alles Custom ist.
Und es gibt Leute, die benutzen
Django Start Project.
Ich wechsle da immer so ein bisschen hin und her.
Ich sehe die Vorteile von beidem.
In den letzten Jahren bin ich mehr so in Richtung
Django Start Project gegangen,
weil das schon eine gute Basis ist
und weil das jeder machen kann.
und
weil das jeder auch versteht.
Aber das hat so ein paar Dinge, die mir
da nicht so gut gefallen. Zum Beispiel das Appsfolder.
Zum Beispiel der Appsfolder, ja.
Ich finde, alle Apps, die man
selbst in seinem Code hat, die gehören in ein eigenes
Verzeichnis. Die gehören nicht in das Projektverzeichnis
rein. Bei dem Projektverzeichnis sind ganz viele
andere Sachen drin. Config zum Beispiel.
Und dass das Configverzeichnis nicht Config heißt,
ist auch sowas.
Passe ich in jedem meiner Projekte an, ja.
Und das einfach mal sozusagen
zusammenzuholen und zusammenzufassen und ein bisschen
drüber zu sprechen, auch was
da für Schritte drin sind.
War super hilfreich.
Inzwischen habe ich das Ganze auch in ein Template verpasst.
Django hat tatsächlich
einen Template-Mechanismus für Startproject und
für Startapp. Den kannte ich auch noch nicht.
Das fand ich auch sehr interessant.
Das wusste ich nicht und das ist voll nützliche Information.
Echt sehr gut.
Ich habe da jetzt auch inzwischen
das so eben zusammengefasst, dass man also mit
Startproject
Template dir geht tatsächlich
sogar von GitHub direkt.
dass man da meine
Konventionen reinnehmen kann, die fast
genauso sind wie die von Django
und eben da mehr Struktur
reinbringen. Oh, das finde ich
auch nochmal interessant, wie man das nochmal aufsetzt und das editiert
dass man sein eigenes Skeleton
Start Template über das Django
Start Project Kommando reinbekommt, das fände ich auch nochmal
spannend. Ja, können wir gerne mal
besprechen oder vielleicht machen wir da einfach
eine Bibliothek dafür, Dominik. Wollte ich sowieso
nochmal, können wir mal
zusammenprogrammieren. Ja, machen wir. Genau, also es war einfach
so ein bisschen, wie entwickle ich und was hat sich für mich bewährt und dann eben
genau so ein bisschen im Dialog so ein bisschen drüber sprechen, was bei den anderen so ist.
Und das hat super gut funktioniert.
Das ist auch, glaube ich, ganz gut angekommen.
Klingt spannend.
Müsst ihr euch auch hinterher mal einbuchen, kommt auch in zehn Tagen.
Ja, genau.
Wir verlinken das.
Und auf deiner Seite hast du das.
Genau.
Oder eben meine Aufnahme ist schon auf der Seite.
Das war so die sechste oder siebte Aufnahme, die ich gemacht habe.
Also die ist ganz okay.
Okay.
Ja, das hatte ich auch ehrlich gesagt, damit hätte ich nicht gerechnet, wie oft man dann ein paar Mal aufgenommen und dann passiert irgendein Scheiß.
Fällt einem die Kaffeekante aus der Hand.
Bei der letzten Aufnahme, die ich nehmen wollte, das war dann auch schon am Tag der Abgabe, habe ich drei verschiedene Aufnahmen gemacht, Audioaufnahme und Kameraaufnahme und Screencast.
Und da wollte ich zusammenschneiden und dann war der Screencast kaputt.
und Jochen unterhalten sich über die Programmiersprache Python
gut waren und dann gab es alle die ganz okay.
Also ihr merkt, dass es noch relativ viel technische
Detailarbeit hängt. Ja, aber tatsächlich
erstaunlich viel mehr Vorbereitung
als ich gedacht hätte.
Genau, aber
was ich sagen muss, also das war
dann, da war Johannes' Vertrag auch
echt einer der
positiv herausstechendsten,
also sowohl Video-Audio-Qualität war gut,
während
das aber...
Ja, ja.
Weil tatsächlich muss man leider sagen,
Also ich fand, oft war das nicht so gut.
Ich hatte dann
während der Konferenz gar nicht so richtig Zeit, das live zu verfolgen,
weil
Dinge passieren.
Aber ich habe
die dann alle versucht nachzuhören,
hinterher, und habe die dann halt
auf dem Telefon
laufen lassen, weil
ja, auch ich komme nicht von Rechner sitzen, muss halt
Dinge passieren.
Und das ging auch ganz gut,
aber was mich halt dann schon
so nach dem dritten, vierten Talk, den ich gehört habe,
angenervt hat, ist halt, dass die Audioqualität
oft nicht gut ist. Weil was
viele Leute dann machen ist, sie
nehmen halt ihr Laptop oder sonst irgendwas
und stellen sich dann halt ein paar Meter dahinter, damit sie
halt irgendwie zu sehen sind und dann
sind sie halt weit vom Mikrofon weg und das
Mikrofon ist schon schlecht und dann
wird das nochmal kaputt komprimiert.
Dann geht der Laptop-Lüfter an.
Und dann ist es
schwer zu verstehen. Also ich hatte tatsächlich
bei einigen Talks das Problem, dass ich sie kaum
verstanden habe. Ich habe die Lautstärke
auf dem Telefon komplett aufgedreht und trotzdem
Schwierigkeiten gehabt, das richtig zu verstehen.
Und es ist vor allen Dingen auch anstrengend,
selbst wenn man es verstehen kann,
Audio zu hören, wo man immer
so schlecht ist, dass man
sich wirklich anstrengen muss, um es zu hören zu können.
Und da denke ich
vielleicht auch manchmal,
da gab es ja auch so einen Talk,
ich glaube es diesmal nicht, aber glaube ich bei der letzten
DjangoCon EU,
How to get on the stage.
Der war verlinkt
für die Sprecher, damit die wissen,
was auf sie zukommt.
Ja, und
vielleicht kann man auch irgendwie so, wie kriegt man eigentlich
zumindest verständliches Audio und
nicht so, beim Video ist ja fast egal,
das ist ja gar nicht so furchtbar wichtig, aber ich finde
das Audio ist halt schon so das halt, was
man verstehen können sollte, wenn man
den Inhalt mitbekommen möchte
und wie kriegt man das so hin, dass man das verstehen kann
und dass das nicht total schrecklich ist
und ja, weil das war durchgängig
fand ich bei den, bei vielen
nicht gut. Es gab ein paar Ausnahmen,
eben Johannes eine
eine löbliche Ausnahme, aber bei vielen war das nicht so richtig toll.
Man tut, was man kann.
Ja, das ist schade, dass es dann oft an so technischen Sachen auch hängt,
aber das ist halt wirklich bei so einer Remote-Konferenz eine sehr inhomogene Mischung
von Technik und Menschen und Ideen und Anforderungen und Zeit auch.
Ja, das liegt mir jetzt auch völlig klar, dass ich hier damit sprechen möchte.
und Jochen unterhalten sich über die Programmiersprache Python
Was mir so ein bisschen negativ aufgefallen ist, war, dass diese Zoom-Meetings oft qualitativ nicht so cool waren. Also ich habe jetzt auch nicht die beste Kamera aufgestellt gehabt, aber ich sah halt auf dem Bild echt krümelig aus auch.
und danach, nach den Talks, waren immer noch Jitsi, hatten sie immer noch einen Jitsi-Raum für den jeweiligen Talk, auch super, ja, großartige Idee,
dass man sozusagen noch so dieses Gefühl hat, ich gehe jetzt vor zu dem Sprecher, ich gehe zur Bühne und spreche noch fünf Minuten mit dem,
haben sie super hingekriegt und da war die Bildqualität bei den Sprechern dann oft wesentlich besser als vorher in diesem Zoom-Meeting.
Das ist natürlich schon irgendwie schade.
Das ist schon irgendwie schade.
Aber vielleicht noch eine ganze Technikkritik
jetzt hier an den Bildern.
Was hat euch denn inhaltlich noch super gefallen?
Aber das ist halt das Einzige, was man kritisieren kann.
Das alles andere war halt super.
Die Vorträge waren super
und die Community war super.
Die hatten ein Tool, das heißt
Gather Town.
Oh ja, Gather Town ist großartig.
Da kann man nicht rumlaufen mit einem kleinen Avatar
und sich dann quasi live auf dem Konferenzgelände treffen
mit so einem Pixel-Avatar.
Und da kann man sich auch dann sehen, weil wenn man sich da live begegnet,
und dann geht nämlich die Kamera an und man kann den Ton hören
und dann kann man sich irgendwie auf dem Dorfplatz versammeln
oder ich weiß jetzt nicht genau, ich war gar nicht bei der Dankokon
live im Gettertau.
Es hat einfach eine Räumlichkeit.
Wenn du in einem Jitsi bist oder
in einem Slack oder so, dann bist du ja immer mit allen Leuten
gleichzeitig am Sprechen.
Und das ist zwar schön, weil du mit
allen Leuten gleichzeitig sprechen kannst, aber es ist auch so ein bisschen
erschreckend, weil dir alle Leute immer
zuhören, weil alles public ist.
Und außerdem meinten sich die Leute vielleicht dann gar nicht, weil
irgendwer immer redet. Ja genau, weil man sich nicht traut.
und den Gersatron
habe ich in der Ecke gestellt und warte, bis jemand vorbeikommt.
Ja, genau. Oder man kann an den Stand gehen von den Sponsoren
und kann sich da was zeigen lassen.
Oder man kann sich an den Tisch setzen, wo schon vier Leute
sitzen und dann weißt du, es sind genau vier Leute da
und nicht 80.
Und das macht einfach ein ganz hartes Gefühl.
Also man kann eigentlich gar nicht so richtig
viel kritisieren, außer eben die Bildqualität.
Und ja.
Jochen, was war denn der...
Du hast alle Talks angeguckt, oder?
Was war denn der Talk, der dich am meisten überrascht hat?
Tatsächlich der erste, würde ich sagen, insofern ist das ein bisschen langweilig immer.
Dann sprechen wir da nicht nochmal drüber.
Ansonsten fand ich die, also man muss auch unterhalten, es gibt halt mehrere Dimensionen
sozusagen es gab halt Talks die mich halt inhaltlich haben so wie der erste und die ich auch gut fand Oder es gab welche die ich technisch gut fand Oder es gab welche
wo ich den Inhalt fachlich super fand.
Aber das muss alles nicht
unbedingt gleichzeitig passiert sein,
sondern das war teilweise...
Hast du vielleicht noch eine Empfehlung von einem Talk,
den man unbedingt gucken sollte, wenn du jetzt beitraust bist?
Also einer meiner Lieblingstalks
war auf jeden Fall der von Carlton Gibson.
Carlton ist auch generell großartig.
Static Sites mit Sphinx,
weil ich hatte auch selber da schon mal so Dinge
gemacht. Ich habe auch überlegt, ob ich da nicht
irgendwie
ViewPress oder WhitePress,
ich habe da schon auch Dinge mitgemacht,
für Dokumentation von Software verwenden soll
und dann
dieses, diese
Read the Docs
Geschichte, wie heißt das noch da?
Restructured Text, das ist ja eigentlich auch
ganz nett, da kann man auch viele schöne Sachen, aber es ist meistens
nicht so vielleicht unbedingt
eben auch vor Nachteile
und das, was er da vorgestellt hat,
das fand ich schon großartig, dass man halt sozusagen
auf der einen Seite diese
etablierte Dokumentations-
Erstellungsgeschichte benutzen kann,
aber auf der anderen Seite dann halt, das war mir auch
völlig überhaupt gar nicht klar, dass die Django-Dokumentation
das so macht, dass da nicht
ein fertig gerendertes statisches HTML
ist, sondern dass das dynamische Elemente hat
und dass das halt, dass sozusagen
die Art, wie der Dokumentations-
Content in die Django-Dokumentations-
reinkommt, ist halt über Jason.
Das war mir
überhaupt nicht klar und das ist eigentlich aber
voll gut.
Und deswegen, also
den Talk fand ich auch technisch gut,
also das Audio war super.
Carlton macht das auch total gut, der ist total entspannt
und ein bisschen flapsig und kurz
und echt cool.
Carlton Gibson, Static Pages.
Genau. Carlton Gibson ist generell
so einer, der in der Community ganz viel
macht. Er ist einer von den Django Fellows.
Der macht die ganze
und er macht die ganze Drecksarbeit. Er bezeichnet sich
selbst als Janitor.
Django ist Janitor und
der ist schon
jahrelang in der Community
drin und der ist großartig. Also das kann ich jedem
empfehlen. Oh, er macht ja auch einen Podcast
mit Will Vincent zusammen,
Django Chat. Ach, das ist auch gut.
Hatte ich kürzlich im Auto die Zeit, acht Episoden
anzuhören.
Also auch das, da muss man die Konkurrenz
einmal hier hervorheben. Du hast ja demnächst
öfter mal Zeit wieder für die Podcasts
im Auto, habe ich gehört. Ja, es kann passieren,
dass ich demnächst mehr Auto fahren muss.
Der Talk, der mich am meisten
überrascht hat, wusste ich aber
vorher schon, weil ich kenne die Person auch
von anderen
Django-Kons, wo ich schon war, ist
Rewriting Django from Scratch in 2021
von Emma Deliscore,
die sich die Frage gestellt hat, wenn wir
kein Django hätten
und es aus
Bibliotheken zusammensetzen müssten, wie
schwierig wäre das denn?
Und die Antwort ist, erstaunlich wenig.
Ja, wäre gar nicht so schwer.
Ja genau, man findet quasi für alle Bauteile
was und sie hat dann eben wenige
wenige hundert Zeilen Glue-Code geschrieben,
die das Ganze zu einem Django machen und
das so als Denkanstoß für Django 4,
weil das steht ja demnächst
an, wo wohl
auch einige technische Änderungen drin sein sollen.
Fand ich super spannend.
Ja, ja, aber ich meine,
also in gewisser Weise wäre das,
aber das kann auch sein, dass ich das nicht so
richtig verstanden habe, weil ich dachte so
Er ist so, ja, interessant, die ganzen Dinge, die sie dann nennt, aber warum sollte man das so machen?
Weil für mich ist ja eigentlich der Vorteil von Django jetzt gegenüber zum Beispiel sowas wie Flask oder so,
oder könnte man auch gleich nochmal kurz was zu sagen, dass man das eben nicht machen muss,
dass man auch nicht sich darum kümmern muss, dass die ganzen Sachen immer noch gemaintained sind
und wenn sie das nicht mehr sind, das austauscht, sondern Django kriegst du sozusagen das Komplettpaket,
wo andere Leute sich drum gekümmert haben
vielleicht nicht alle Funktionen
und nicht so
im Detail ausgefeilt, aber dafür
halt irgendwie stimmig.
Integriert.
Ja, aber was wäre denn, wenn Django
nicht ein Paket wäre, sondern wenn Django
ein Metapaket wäre, was
zwölf andere Pakete reinzieht
wo wenn du Django installierst, kriegst du es immer noch
integriert und immer noch stimmig
aber hast dann trotzdem die Möglichkeit
einen Baukasten zu haben. Hast trotzdem die
Möglichkeit zu sagen, ah, Moment mal, ich möchte
eigentlich lieber Templates haben, die
X machen oder Templates Y haben.
Oder auch eben so Contrib-Pakete.
Was ist denn, wenn ich mal den Admin nicht brauche?
Was ist denn,
wenn ich mal eine Seite habe, die den Admin nicht braucht?
Im Moment kann ich ja nicht viel machen.
Ich kann die App deaktivieren
und ich kann die URLs deaktivieren.
Aber der Code ist auf jeden Fall drin, ja.
Aber der Code ist immer noch da.
Und sich diese Frage zu stellen,
was wäre denn, wenn Django modular wäre?
Es ist ja modular, ja.
und Python.
dass ich über SendGrid
verschicke.
Ich muss nur pip install django sendgrid machen
und dann ist das komplett nach.
Diese Frage ist
eine großartige, gute Frage.
Okay, ja, gut. Also so gesehen doch.
Weil im Grunde ist Django ja schon,
viele Teile sind ja schon pluggable.
Eben Storage oder halt
Authentication.
Ich installiere dann halt ein anderes
Paket, sondern auf der Ebene von
in den Settings sage ich halt,
du bist jetzt für mehrere Pakete
und dann stelle ich sie in den Settings ein, welche sie benutzen werden.
Genau. Aber stimmt.
Also, dass man den Code
gar nicht mit drin haben muss, das ist natürlich schon so ein Punkt.
Ah, das
ist aber auch noch ein interessanter...
Genau, jetzt fällt mir doch noch was ein,
zu welcher Talk hat mich am meisten überrascht.
Und zwar, ich weiß nicht, ob ihr den, oder
Johannes, ob du den auch gehört hast,
von Jannis Leidl, der
Jazzband
Talk. Ja, habe ich gehört.
Er ist auch live während des Talks
Jazzband beigetreten. Ah, okay.
Genau, ich habe es mir nicht getan, aber ich habe stark daran gedacht, das zu tun.
Und genau, ich hatte das immer nur gesehen,
Was ist denn JS-Fan, Jochen? Erklär mal.
Ja, ich hatte das immer nur gesehen bisher als, das ist irgendwie eine Organisation,
in der viele der im Django-Kosmos befindlichen Pakete halt so auch mit drin sind
und was da gemainted wird, irgendwie so Django-Filter und weiß ich nicht, ganz, ganz viel Zeug.
Storages und viele Anwendungen.
Ja, und Commands.
All of.
Ja, also ganz viel
und dann dachte ich immer so, ja
und dann wusste ich auch irgendwie so, ja das ist halt irgendwie so, wenn man keine Lust mehr hat
das selber zu maintainen, dann kann man das vielleicht dahin
das loswerden
irgendwie
weiß ich nicht, irgendwie ein Schleifchen dran binden
und das dann da aussetzen, wie an der Autobahnraststätte
Die Apache Foundation
der Django-Welt
Ja, aber
genau
Die sind ja tatsächlich sehr aktiv, habe ich jetzt gehört
in dem Talk
Ja, aber
dann, was mich in dem Talk dann halt
überrascht hat und was ich nicht wusste, ist,
dass das tatsächlich etwas ist, wo man
selber sehr leicht
beitreten kann und
man hat so ein bisschen die Anforderungen
an ein Projekt, aber sie sind auch relativ leicht zu erfüllen
und dann kann man
quasi Projekte davon
maintainen lassen und also der entscheidende Punkt
und der war mir überhaupt nicht klar, ist
bei diesen Projekten ist es so,
dass man das so ein bisschen umkehrt, weil normalerweise
hast du halt immer in vielen Projekten
irgendwie so Core-Entwickler oder Leute, die
halt da reinkommitten dürfen.
Dieses Privileg
bekommt man halt normalerweise, weiß ich nicht, nach ein paar
erfolgreichen Pull-Requests oder so oft bei vielen
Projekten.
Und vielleicht bei noch größeren ist es
so, dass es dann Leute gibt, die überwiegend
sich um den Issue-Tracker kümmern
oder sowas. Und es gibt halt einen Unterschied
zwischen diesen sozusagen offiziell
Beteiligten und den ganzen
Leuten, die halt tatsächlich die
Pull-Requests erstellen
und
dieses Jazzband dreht das halt um
und sagt, also du kannst halt einfach da
reinkommitten, kannst halt einfach dann
es funktioniert halt und dann
es gibt halt nur weniger Release.
Jeder kann beitreten. Ja, kann beitreten und erst beim Release
wird dann halt geguckt, okay, macht das denn irgendwie Sinn
oder ist das irgendwie Quatsch?
Und das passiert halt deutlich seltener, sodass du halt
diese Hürde, dass du halt
das ist tatsächlich eine Hürde, das habe ich mir auch schon oft gedacht
muss ich das jetzt wirklich
Ja und ein Pull-Request stellen
und dann hörst du acht Wochen lang nichts
und dann sagst du, ja hier ist was und dann
weißt du schon alles gar nicht mehr oder geht ganz unter
Ja und was ich dann oft mache ist
dann fork ich es doch mal schnell selber
fix das da und dann
dann vielleicht
mache ich doch tatsächlich nochmal ein Pull-Request, aber
eigentlich auch egal und
tatsächlich habe ich das auch bei Projekten gemacht, die in
Jasmine drin sind und dann hätte ich dann so
okay, eigentlich hätte ich die
direkt fixen können.
Und dann hätte man
diese ganzen
Tons um GitHub-Pull-Requests-Issue
gar nicht machen müssen, sondern ich hätte es einfach gefixt,
committet und fertig.
Was heißt bei Django Field?
Django Field ist all out.
Ja, ganz viele von diesen Sachen,
die man kennt, ich glaube auch Django Extensions
und Debug-Toolbar sind inzwischen Jazzband-Projekte.
Wo, apropos
Debug-Toolbar, da gibt es ja auch was für.
Der Jazzband, weil
das irgendwie sozusagen
und ja, Django ist ja auch vom Namen her, wird das drückerführt auf Django Reinhardt und daher kommt das.
Ein Band.
Cooler Name, finde ich.
Ja, also Django Extensions, hast du noch irgendwas Schönes geteilt, Johannes?
Und zwar hast du da was entdeckt, das heißt die Kolo-App, was auch für Debug für Django relativ lustig sein soll.
Da musst du mir auf die Sprünge helfen, Dominik, weiß gar nicht, was du meinst gerade.
Du hast das schon schon link geteilt, am Kolo-App, das ist eine Django-Applikation zum Debuggen.
Vor allem auch in VS Code, du kannst halt so den Toast-Tweet anschauen.
Ja, genau, das hat mir gar nicht so richtig geholfen, weil ich VS Code nicht benutze.
Aber die haben eben einen Django-Debugger in VS Code integriert und zwar so richtig tief, also der zeigt einem direkt alle Innereien.
Genau, Best Response, die Queries und so.
und auch mit Profiling drin und wenn Fehler auftreten,
kommst du gleich an eine richtige Stelle.
Man kann sogar den Executed-Code-Pass visualisieren.
Es ist ein richtig, richtig ausgefeilter Debugger,
geht allerdings nur in Visual Studio Code.
Das ist ein Salary-Task, kann man damit machen.
Also der zeigt dann wirklich alles an
und das ist sehr beeindruckend.
Ja, ich habe es leider nicht weiter benutzt,
weil ich bin ja, ich komme ja aus einer anderen Richtung.
Charming.
Ich bin sehr charming, ja.
Hi, charming.
Ja
Auch was, was ich da gesehen habe
Okay, ich habe noch eine andere Sache, die mich überrascht hat
bei der DjangoCon
und das war HTMLX
Du hattest das schon mal erwähnt, Jochen
Ja
Du hattest HTMLX schon mal gesagt
HTMLX ist eine JavaScript-Bibliothek
ohne JavaScript
Das heißt, anstatt
dass ich selber JavaScript schreibe
schreibe ich nur spezifische Tags
an meinen HTML dran
die dann irgendwelches dynamisches Verhalten auslösen
zum Beispiel kann ich einem Button sagen, dass er das
Formular submitten soll. Oder
ich kann sagen, wenn
ein Item
in den Bildschirmbereich gescrollt wird, dann
refresht sich das mit einem
dann macht das ein AJAX-Request und holt
neue Listen-Einträge
und kann ich Infinite Scrolling machen.
Oder ich kann sagen, ich möchte Formvalidierung haben
oder ich kann sagen, ich möchte Animationen haben oder so.
Und das Ganze nur über HTML-Tags
ohne selbst
JavaScript schreiben zu müssen.
Und
das kam in drei oder vier
Talks hintereinander, haben sie alle
auf HTMLX verwiesen
und offensichtlich auch nicht
abgestimmt, weil
die Sprecher dann auch gesagt haben, ja, es ist
jetzt schon wieder, ich weiß, es kam jetzt eben schon in den
anderen Talks, aber jetzt ist es schon wieder.
Auch im Slack kam das
dann auf,
dass da jetzt schon wieder HTMLX vorkommt
und ich glaube, das ist was, was ich
mir, also ich wusste, dass es das gibt,
aber mir war gar nicht
so klar gewesen, wie sinnvoll das ist und wie
nützlich das ist. Und dass man ja
tatsächlich sehr viel Dynamik in seiner
Seite mit diesen einfachen Mitteln
hinkriegen kann. Also das, wo
man früher jQuery verwendet hat,
Button.click
und dann
$ajax machen, ist
jetzt einfach in dieses
htmx-Attribut reingewandert.
Und ich glaube, ich muss mir das
mal noch genauer angucken,
wie weit man da gehen
kann. Also ich meine, einen
Talk gab es damit, der hat es quasi zu Ende
gedacht. Was ist denn, wenn wir diese Sachen alle
aus dem Django Form,
aus der Formklasse generieren und aus dem Django
Modell generieren? Auch
großartige Idee.
Data Binding automatisch erzeugen
über Django
Template Syntax. Geht vielleicht
einen Schritt zu weit.
Möchte ich schon noch die Kontrolle drüber haben.
Aber
ja, dass man quasi JavaScript schreibt
ohne JavaScript schreiben zu müssen.
Großartige Idee.
noch genauer anschauen.
Ja, genau, würde ich auch sagen.
Das war auf jeden Fall auch eines der großen Themenfelder,
die es auf der DjangoCon gab, nämlich
wie macht man eigentlich sozusagen
etwas interaktivere
oder so modernere, so
Single-Page-App
mäßige
Applikationen mit Django, weil wohl auch
der Druck größer wird von da außen.
Und vielleicht kann man aber,
muss man dafür nicht jetzt irgendwie,
Es gibt einen Weg, den halt auch viele Leute beschreiben,
der ist halt, naja, du machst halt Django REST-Framework
oder halt, weiß ich nicht, GraphQL irgendwie.
Gab's auch einen Talk dazu.
Ja, und machst halt deine Applikationen im Frontend
halt quasi als, weiß ich nicht, ReactView, Angular.
Django Headless.
Und Headless, genau.
Und dein Backend ist sozusagen, dein Django ist halt nur noch das Backend
und rennt halt nur noch JSON raus und sonst nix.
Das ist eine Möglichkeit.
Das ist aber eigentlich irgendwie traurig, oder?
Das ist irgendwie traurig.
Genau.
weil man die ganzen guten Teile
hat. Ja, es gibt halt
schöne Teile von
Formulare, Formvalidation
oder so, das kann man halt alles nicht mehr nutzen.
Template, da gibt es sehr schöne Geschichten für.
Authentifizierung auch, alles mögliche.
Genau, man verliert halt
viele Dinge, die halt
Django eigentlich total nützlich machen
und die muss man dann selber machen und dann,
wenn man das dann macht in JavaScript, stellt man
auch fest,
Ja, man schreibt
Die langweiligen Teile von Django schreibt man sich dann in JavaScript nochmal nach.
Genau.
Und man hat dann immer noch eine andere Programmiersprache,
mit der man auch kämpfen muss.
Aber mit JavaScript muss man doch.
Das findet man ja teils in der Programmiersprache.
Ja, also es ist besser geworden, sagen wir mal so.
Aber ehrlich gesagt, mir ist Python immer noch lieber.
Auch angenehmer.
Ja, ja, durchaus.
Und eben, was kann man denn jetzt eigentlich noch tun?
da gibt es ja dann mehrere Gegenbewegungen
aber wir hatten das ja auch schon ein paar Mal
sowas wie dieses ganze
Hotwire
Zeugs, irgendwie Ruby on Rails macht das ja auch
dass man halt sozusagen, oder Elixir
Felix
man rendert halt HTML
auf der Serverseite und
hat nur noch wenig JavaScript auf der kleinen
Seite, was halt dann irgendwie
die Seite updatet und
tatsächlich fällt für mich HTMLX halt auch in diese
Klasse von Dingen rein
oder sagen wir mal so
und
von HTMX.
Und
der beschrieb so ein bisschen, was er damit vorhatte
und das fand ich auch sehr interessant, weil das hat mich tatsächlich an die
Episode, wo wir das
letzte Mal zusammengesetzt haben, REST erinnert.
Und da
haben wir auch das erste Mal
HTMX erwähnt.
Und
dass er das Ding HTMX nennt, heißt,
das ist kein Zufall.
Er hat
aber mit jQuery angefangen
und dann hat er sich überlegt, okay, eigentlich ist das ja blöd.
und hat
dann versucht, die Funktionalität
da hat er irgendwie das Gefühl,
das müsste ja eigentlich in HTML oder so drin sein
und das bricht ja auch mit diesem ganzen REST-Ding
und er hat wohl auch die Dissertation
von Roy Feeley da gelesen
und er hat so, was wäre denn, wenn ich eine Bibliothek
schreiben würde, die es
erlaubt, dass das irgendwie so ist,
wie das eigentlich sein sollte,
aber man selber das
JavaScript dafür nicht schreiben muss. Also ich
erweitere sozusagen
HTML so, wie das
eigentlich gehören würde, wenn es Browser-Supporter
für gäbe und das mache ich dann halt in JavaScript.
Und das Ding nennt er irgendwie Intercooler.js
und das war am Anfang noch so ein bisschen grude und sehr
Jackfairy-mäßig und das
hat man schon mal davon gehört,
auch noch gelobt heutzutage.
Ist aber irgendwie, er meinte so, naja,
der Name ist halt schlecht, weil das JS am
hinten dran, das vermittelt so den Eindruck,
das wäre so eins von diesen
JavaScript-Frameworks, was es eigentlich nicht ist
von den Frameworks und Intercooler
versteht auch keiner und dann hat er
irgendwie so ein bisschen, so ähnlich
auch wie wir, wie nennen wir diesen Podcast?
Naja, gucken wir mal, Python oder Python,
dann macht es halt so.
Eigentlich möchte ich HTML, aber erweitert,
Extended, HTMLX, okay, HTMLX.org
noch frei, oh super.
Und dann ist das Ding halt HTMLX.
Und die Idee ist...
Die Buchstaben Org Demands ist auch nicht schlecht.
Ja, gibt es eigentlich gar nicht mehr so häufig,
aber hat wohl funktioniert.
Und deswegen hat er das
dann halt jetzt nochmal so, ist halt so
ein Nachfolger von Intercooler.js.
und die Idee ist
tatsächlich, was wäre denn,
also was ist das Hauptproblem bei,
wenn man jetzt einfach nur ganz stinknormal
HTML rendert
und dieses HateOS
verwenden möchte,
also Hypermedia ist die Engine of
Replication State Dings und
quasi die Prinzipien beibringen möchte,
die halt auch in dieser
Dissertation von Ray Frieden drin sind,
also das Hauptproblem, weshalb
das nicht gut ist und weshalb alle irgendwie
JavaScript zusätzlich machen, ist, dass
sobald du irgendwas änderst
in diesem alten Modell,
musst du deinen kompletten DOM neu aufbauen,
also einen Request-Response-Type.
Du musst einen kompletten Page-Reload machen.
Und das ist halt etwas, was
nicht gut funktioniert, weil
wenn die Seite komplizierter wird,
dann dauert das halt einfach schon mal über eine Sekunde,
bis sich die Seite wieder aufgebaut hat.
Und das heißt, alles fühlt sich dann einfach
nicht mehr flüssig an.
Ja, aber
mit AJAX und so,
konnte man ja da immer schon so ein bisschen was machen, so
Web 2.0 mäßig.
Aber das ist halt eben dann
JQuery, aber das ist halt eben nicht
REST eigentlich.
Und auch diese Single-Page-Apps sind auch
nicht REST, weil die sind halt, die sagen, okay,
naja, der Application-State ist halt im
Frontend und Backend ist halt nur,
liefert halt Daten, aber, oder vielleicht so ein bisschen
State, aber es ist eigentlich, du hast halt
Synchronisationsproblemen,
aber die eigentliche Applikation läuft
halt im Browser. Und er meinte,
okay, wie ist es denn, wenn wir jetzt sagen, okay, wir erweitern
HTML eigentlich um die Elemente,
warum ist es so, dass nur
Form, nur das Form-Tag
einen Post auslösen kann?
Warum kann das nur einen Post auslösen? Warum gibt es nichts,
was irgendwie einen Put auslösen kann?
Ja, okay, aber
gut, man kann das ja einfach dann so machen,
weil aus JavaScript heraus kann man das ja dann tun,
dann schüttet man halt Attribute ein, wo dann
Elemente eben auch einen Put machen können oder halt
eben auch andere Elemente einen Post machen können
und dann kommt
dabei, wenn man das dann halt sozusagen
so ein bisschen standardisiert, kommt halt
HTML eigentlich raus, sodass du halt
sozusagen diese ganzen anderen netten Sachen
halt auch einfach nur in deinem
HTML sozusagen machst und
ja, es gibt halt dann noch so eine Bibliothek,
die das, solange die Browser das nicht unterstützen,
halt dann für dich in JavaScript tut,
aber im Grunde könnte man das auch einfach so...
Ja.
Und das ist eigentlich ein sehr, sehr
interessanter Gedanke, also fand ich auch sehr gut.
Ja.
Ja, und es kam einfach so häufig
vor. Ja, so man merkt,
und man merkt, dass man gezwungen war, sich das anzusehen.
Also es scheint irgendwie so im Zeitgeist
drin zu sein oder im Gedanken
der Moment, das Moment ist.
Ja, der Zeitgeist geht auf jeden Fall Richtung
ja, was wäre denn, wenn wir einfach HTML
rüberschicken und nicht irgendwie JSON.
So ein bisschen, ja.
Ja gut, diese ganzen
Single-Page-Apps,
so eine React-App oder so eine Angular-App
oder so eine Ember-App oder was auch immer,
sind ja im Wesentlichen gar keine Webseiten.
Das sind ja Desktop-Anwendungen,
die halt, okay, zufällig
in so einer VM laufen, die Browser und
JavaScript heißt.
Die aber
im Wesentlichen ja selbstständig sind.
Und es geht ja bei vielen Sachen auch
total gut, dass du halt
eine Anwendung hast im Vordergrund. Also es gibt ja inzwischen
alle möglichen Sachen. Es gibt ja Fotobearbeitungssoftware
im Browser.
Ja, gut.
Es braucht ja überhaupt gar keinen
Riller, dass das Internet da ist.
Ja, wenn man so eine Applikation hat, die
selber sehr viel macht und die ab und zu
oder vielleicht mal mit einem Backend reden muss, okay,
dann ist das dafür vielleicht auch super geeignet.
Aber ich meine, die meisten Webseiten sind
ja gar nicht unbedingt so.
Genau, das meine ich.
Das meine ich ja. Es gibt ja ganz viele solche
Anwendungen, die halt einfach Desktop-Anwendungen
sind, die zufällig im Browser laufen.
Und es gibt aber auch
sicherlich den größeren Teil
der Webseiten, die halt
die gerne so wären,
aber es eigentlich gar nicht nötig
haben. Und so diese
Brücke dazwischen zu schaffen,
und das ist glaube ich
das ist eben das, was im Zeitgeist ist
dass man jetzt eben von den ganz
statischen Webseiten
sind wir ja schon lange weg
auf eine gewisse Art und Weise lange weg
die ganz dynamischen Sachen, die ja eigentlich Anwendungen sind
selbst freistehende Anwendungen
die zufällig halt auch noch Internetrequests
machen
das ist die andere Seite und eine Weile lang hat man versucht
das alles, ja alles muss so eine Anwendung
sein, was ja aber auch nicht sinnvoll ist
so auf einen Zwischenschritt
zu gehen, dass du eigentlich statische
Informationen anzeigst, die aber trotzdem
irgendwie auf Events reagieren können und sich dann
trotzdem so ein bisschen zumindest verändern können.
Ist glaube ich einfach
der Kompromiss in der Mitte
und der deckt sicherlich da
super viele Use Cases ab und super viele
Sachen ab, die man eben
früher entweder so oder so machen musste
und deshalb
in die Mitte ist richtig.
Das Nash-Gleichgewicht ist immer in der Mitte.
Na, wie heißt es bei Alexander Kluge, glaube ich, in Gefahr und großer Not, es bringt der Mittelweg den Tod.
Ja, aber in der Mitte der Herde zu sein, ist der sicherste Ort, das hört man.
Genau, zu der letzten Rest-Episode, da gab es dann auch eine Erwähnung im Podlovers-Podcast,
wo es um die Entwicklung von so einer Podcast-Plattform geht, im Grunde, basierend auf WordPress und so einem Plugin.
und da wurde durchaus wahrgenommen dass wir irgendwie XML gel haben So was So was Habt ihr euch ger worden Ja
Es wurde sogar ein gewisses Verständnis dafür gezeigt, dass Entwickler vielleicht doch lieber JSON mögen
unter Umständen als XML.
Was hat dir denn gefehlt an der DjangoCon? Was müsste die DjangoCon mehr haben?
Schwer zu sagen.
und Jochen unterhalten sich über die Programmiersprache Python
Das ist ja Vor- und Nachteil.
Ich habe das auch sehr genossen, dass ich da nicht hinfahren musste,
weil ich konnte mich halt trotzdem um meine Kinder kümmern,
konnte trotzdem dann abends mit der Familie essen
und dann trotzdem abends noch die Talks machen.
Ob du es nicht genossen hättest, wenn du auch mal ausnahmsweise
ohne die Familie und ohne die Kinder irgendwie frei in den Ort runterbiegst.
Klar, hätte ich auch genossen,
wäre aber einfach schwieriger gewesen, das zu machen.
Ich glaube, in Zukunft wäre das sehr schön,
wenn solche Konferenzen so ein Hybridmodell hätten.
und Jochen unterhalten sich über die Programmiersprache Python
gibt, aber eigentlich, wenn man die Online-Konferenz
macht, dann braucht man keine DjangoCon
EU und keine DjangoCon
India und keine DjangoCon Amerika,
sondern es müsste eigentlich eine DjangoCon Worldwide geben
und dann ist die Sache
klar, du kannst nicht bei allen Talks dabei sein, aber
du kannst halt bei denen dabei sein, wo du dabei sein kannst.
Aber das ist
mehr Umbruch als
Also ich würde sagen,
das hat auch ein bisschen was familiäres, wenn man da hingehen kann,
kann die Leute wirklich treffen, wie
kleiner das ist, das familiäre ist das und je größer es wird,
desto anonymer wird das und das Problem, was wir gerade
schon beschrieben an diesen Online-Talks,
dass halt vor allen Dingen dieses Frontalunterrichtsthema,
dass irgendwie alle Leute einen Speaker
in einem Raum hängen und sich diese ganzen
Nebengespräche halt nicht entwickeln, sich diese ganze soziale
Interaktion irgendwie nicht so entwickelt, wie man sich das wünscht,
man sich nicht mal gemeinsam Kaffee trinkt,
irgendwelche zufälligen Bekanntschaften auf einem Gang
hat oder so. Und das ist ja auch das, wovon
irgendwie so eine Community lebt und so.
Und das ist halt virtuell,
ja, vielleicht ist sowas wie Gather Town
so ein bisschen repräsierbar,
aber ist halt doch
schon was ganz anderes.
Ja klar, aber du schließt halt auch manche Leute aus, die das nicht können oder nicht wollen
und die Leute sind auch ein wichtiger Teil der Community
die irgendwie mitnehmen und deshalb denke ich
es wird Mischlösungen geben in der Zukunft
und muss es auch geben. Okay, aber ich habe noch was ganz konkretes
was mir jetzt leider gefehlt hat an der Konferenz
und das waren die Lightning Talks. Es gab Lightning Talks
Oh ja, stimmt. Und die waren auch alle sehr gut
und sehr schön und es war wirklich cool, dass da die Leute sich
Ich kann es jedem nur empfehlen.
Das ist ein guter Einstieg. Fünf Minuten, das schafft jeder.
Die waren alle
pre-recorded, das heißt, man hat auch nicht den
Stress des Live-Daseins
gehabt. Ich kann es jedem nur empfehlen.
Aber die Auswahl war dieses Mal
nicht so groß.
Es waren alles technische Talks.
Es waren auch nur eine Handvoll.
Und die
waren nicht so promoted, wie sie bei einer
Konferenz wären. Also so ganz cool wie
bei euch beim Baumhaus, das hat Ihnen noch gefehlt.
Genau. Also ich habe einfach
in Heidelberg hat einen einen Talk gehalten, wie baue ich ein Baumhaus?
Fünf Minuten Lightning Talk.
Großartig, ja. Hatte überhaupt nichts mit der DjangoCon zu tun, aber war großartig.
Es ist so ein bisschen so ungefähr der einzige Talk, an den ich mich erinnern kann,
von der DjangoCon 2019 oder 2018 war es, ich weiß nicht mehr.
Einfach, weil es so etwas ganz anderes war und das gab es dieses Mal gar nicht.
und das fand ich ein bisschen schade,
dass es da nicht mehr
so ein bisschen drüber hinausging,
weil es war schon sehr fokussiert
auf Django, was ja
okay ist, aber bei den Lightning Talks darf man
durchaus, finde ich, auch so ein bisschen über die Stränge
schlagen und das hätte ich mir
mehr gewünscht.
Ja.
Das ist keine Kritik an irgendjemandem, sondern das ist eher
Kritik an jemandem, der nicht dabei war.
Schämt euch was, ihr hättet dabei sein sollen
und hättet coole Talks über abgefahrene Dinge.
halten können. Jeder hat ein Hobby und jeder kann das
fünf Minuten präsentieren. Das interessiert ganz viele Leute.
Meine Hobbys sind alle illegal.
Meine Hobbys sind Python und Django.
Deshalb bin ich schon
als Habt.
Ja.
Das ist ein Bereich.
Ja, stimmt. Das hat mich auch
gewundert, dass ich die Lightning-Stocks
schon vorbei hupsala.
Ja, waren zu wenige und waren auch
nicht divers genug, sagen wir mal so.
Ja, ansonsten so große, große Themen. Wir hatten jetzt so genau dieses ganze HTMLX. Das war auf jeden Fall ein großes Thema. Es gab viele Talks zu Datenbankgeschichten. Das fand ich auch voll gut.
Also da waren auch einige...
Der von Haki Benita, großartig.
Ja, Markus Holtermann auch.
Let's use another index.
Can we do better? You've been in this talk
long enough to know that yes, we can do better.
Ja, oder
auch der, wie macht man Migration eigentlich
ordentlich, wenn man ein Produktionssystem hat, das
vielleicht nicht so verträgt.
Das fand ich auch sehr gut.
Oder auch, was können wir denn machen,
ohne den Django ORM zu benutzen? Was ist denn, wenn wir
nur SQL benutzen wollen? Auch super.
Fand ich auch gut, weil
und das war auf jeden Fall auch ein großes Thema.
und
ja, dann, was hat man denn noch
an größeren, dann
GraphQL war halt auch
war halt auch ein großes Thema,
aber auch vor allen Dingen in Kombination, ein Talk
gab es, fand ich,
in Zusammenhang
mit Domain-Driven Design
und genau.
Sehr gut. Genau, aber da war
auch, das muss ich, ja, es ist halt
tatsächlich nicht so ganz einfach, das miteinander
zu verknüpfen. Da wäre auch nochmal
interessant gewesen, wie du das in dem
dritten Teil, der da nicht vorgekommen ist,
der ist ja in der Aufzeichnung.
Genau,
wie macht man das eigentlich, wenn man jetzt
erfüllt?
Genau, wenn man jetzt
irgendwie
Business-Logik hat, wo packt man die denn jetzt in Django
eigentlich hin, wenn
doch viele sagen, dass es gar nicht so gut
ist, das in die Models zu packen.
Server, Helpers, Services,
Helpers, Utils.
Jochen, da haben wir doch schon drüber gesprochen.
Wenn du das in die Models packst, ist das überhaupt nicht Solid.
Die sind überhaupt nicht mehr
Single Responsibility, die sind überhaupt nicht mehr
ersetzbar, die sind überhaupt nicht mehr...
Ja, ist das jetzt der klassische
Strafrecht? Fad Models gegen Sin Models.
Ist direkt verletzt.
Aber ja, das Problem ist halt
andererseits auch irgendwie nicht, weil das
andererseits ist... Das ist halt auch schon sehr praktisch.
Das ist auch richtig.
Aber da
Auf jeden Fall, ich kann darauf erinnern, weil ich auch, glaube ich, eben in dieser
Domain-Driven-Design-Plus-GraphQL-Geschichte
hatte ich auch, oder vielleicht war es ein anderer,
vielleicht kriege ich es nochmal zusammen,
hatte ich auch jemanden dann so, ja, wie macht man das eigentlich mit Django?
Und dann, okay, irgendwie geht es
nicht so richtig gut, weil
wenn man es in die Models schreibt,
dann macht man da etwas,
was man eigentlich nicht tun sollte.
Aber anders geht es irgendwie auch nicht gut.
Ja, das ist einfach so eine ungelöste
Frage.
Da ist auf jeden Fall noch eine Baustelle
und ich fand, man hat diesmal auch gemerkt, dass
irgendeine ordentliche Menge,
ordentlichen Anteil der Leute tut es halt weh,
aber es gibt irgendwie keine Lösung,
jedenfalls keine Best Practice, die man einfach so verwenden könnte.
Die Graphs heilen statt in der Modus Phi.
Das ist so ein bisschen
der letzte Punkt, den ich bringen möchte,
der letzte Kritikpunkt, den ich bringen möchte.
Die
Django-Community ist großartig,
die ist ganz große Klasse und es gab
quasi nichts, wo
und Jochen unterhalten sich über die Programmiersprache Python
Django wurde auch auf der Konferenz mehrmals als
the boring old framework bezeichnet
und
das ist was, was man Django und der Community
vorwerfen kann. Die Innovation
kommt aus anderen Sachen.
Die innovativen Sachen kommen aus der
Ruby-Welt, die viel kleiner ist.
Aus der Rails-Welt.
Die innovativen Sachen kommen aus der JavaScript-Welt,
die halt
tun müssen, weil sie nicht anders können.
Aber
warum haben wir denn nicht
so viel Innovation in der Django und in der Python-Welt?
Warum beäugen wir die Sachen nicht auch mal viel skeptischer und sagen,
ja, das ist ja schon ganz gut, aber es könnte noch viel cooler sein?
So ein bisschen sieht man das ja mit dem HTMLX und mit dem Fullstack without writing JavaScript.
Aber das sind immer nur Sachen, die, wir zeigen jetzt mal eine Lösung, die jemand gemacht hat.
und es gab wenig so, lasst uns doch mal Folgendes machen oder lasst uns mal ausprobieren
oder hier ist was, was ihr noch nie gesehen habt, weil es das noch nicht gibt irgendwo anders.
Und ich hatte das Gefühl, oder ich habe schon länger das Gefühl,
dass die Django-Community eben so ein kleines bisschen weniger,
weniger, ja, es ist schwer das in Worte zu fassen ohne zu negativ zu sein.
Das ist einfach so gut, dass man einfach den Nied nicht hat,
sich so schnell in eine andere Richtung zu bringen.
Ja, vielleicht.
Ja, das wäre natürlich gut.
Ja, aber das ist ja so ein lokales Maximum.
Vielleicht ist das ja so.
Vielleicht ist ja Django so ein lokales Maximum,
wo es eben sehr schwer ist,
sich rauszuoptimieren, weil
jeder Schritt nach draußen erstmal ein Schritt nach unten ist.
Vielleicht ist es das, aber ich würde es mir halt wünschen.
Ich habe in der Rails-Welt
total coole Sachen gesehen.
Hotwire kommt, glaube ich, aus der Rails-Welt.
Es wurde mehrmals darauf verwiesen,
wie Rails das macht, während Konferenztalks.
Transparenz Talks. Und das ist schade, weil Django sollte der Vorreiter sein. Django ist nicht der Vorreiter. Django ist die beste Lösung, aber nicht der Vorreiter.
Ja, das ist das, was man auf der anderen Seite ist. Django damit natürlich auch so ein bisschen wie Python selber, das zweitbeste Framework.
Und es ist der absolut beste Platz, wo man sein kann, der zweitbeste zu sein, weil der erste wird immer angegriffen und zerlegt.
Mach doch mal, Johannes, sei doch mal innovativ. Bring doch mal was Neues raus.
Ja, ich versuch's ja.
Ich versuch's ja, aber
erstmal muss ich Geld verdienen.
Ja, da kommt wieder her
der Greed und so.
Ja, ja, ja.
Diese Sache mit
Anvil, Jochen, die ist ja großartig.
Anvil ist ja eine ganz
verrückte, abgefahrene Sache.
Was ist Anvil? Ein Schmiede-Amboss
für... Ja, das ist quasi
JavaScript aus Python.
Die haben dann
Compiler für
JavaScript, der JavaScript erzeugt.
Das heißt, du kannst dein System komplett in Python
schreiben und hast dann aber
trotzdem hinterher eine JavaScript-Webseite.
Großartig.
Großartige Idee.
Funktioniert auch, ja. Kann man
jetzt schon benutzen. Er hat auch eine Live-Demo
gemacht, die dann sofort live war.
Auch sehr großartig. Weiß nicht,
ob das Ding noch live ist. Müsste man mal gucken.
Aber
Ja, aber es geht auch, das ist dann schon nicht mehr Django.
Anvil ist, glaube ich, relativ wenig Django.
Ja, ja, ja. Genau.
Aber vielleicht ist das ja genau das Indiz dafür, dass das aus dem lokalen Maximum da raus...
Ich glaube auch, es ist einfach schwer, du kannst auch Django nicht mehr so leicht verändern.
Du kannst ja nicht einfach sagen, wir bauen ja Django so um, dass es sowas wie Anvil ist.
Ja, das würde halt...
Das ist einfach so viel Arbeit.
Das ist so, dass Johannes eben gesagt hat, dass wir Module daraus machen.
Ja, das wäre möglicherweise ein Grund, das zu tun.
wenn man sagt, also ich meine, es fängt ja schon bei sowas an wie
Django Admin, haben ja auch schon viele Leute gesagt
aber es wäre doch auch cooler, wenn das irgendwie
ein bisschen reaktiver wäre und wenn man da irgendwie so ein paar
Modellere, es geht halt nicht, weil Django Admin
neu schreiben könnte.
Ja, aber es wird halt
auch da wird dann immer gesagt, so ja, Django Admin neu schreiben
vergiss es einfach, das kriegst du ja nicht mehr hin.
Das ist nicht zu machen.
Es ist halt das lokale
Maximum, ja, du kannst ein Django Admin schon neu schreiben
aber der wird erstmal eine ganze Weile lang
sehr viel schlechter sein als der Django Admin, den du jetzt hast.
und dann ist die Motivation
schon so ein bisschen so, ach ja,
dann nehme ich halt wieder ab.
Und das vielleicht, ja,
vielleicht ist das der richtige Weg, das zu
modularisieren.
Ich meine, ich würde da sagen
Flask, um da nochmal,
weil da gab es noch News zu.
Das ist ja der andere
Ansatz, das ist ja sozusagen,
alles ist modular und du
bastelst dir das halt selber zusammen.
Und es gibt auch keine Standardmodule, sondern du musst
dir selber Standardmodule suchen.
Da gab es jetzt
eine neue Release, Flask 2.0
und ich hatte ja mal so
irgendwie, Cass behauptet,
das wird nie async,
weil ich hatte das
noch so in Erinnerung, dass
da ja auch mal sehr, sehr stark geachtet wurde
auf Abwechskompatibilität und möglichst, also
gerade, na, wie heißt der noch?
Dings da,
Armin, der
hält das ja total, dass irgendwie
der hätte ja am liebsten
Abwechskompatibilität bis
weiß ich nicht, eigentlich bis ganz weit
bis Jahrzehnte zurück,
was ich auch verstehen kann in gewisser Weise.
Ja, hat auch Vorteile.
Aber auf der anderen Seite würde das eben bedeuten,
sowas wie Async Await, das wird dann halt nie gehen.
Und Flask ist halt auch direkt
als der erste Frame, das sich direkt auf
WSGI aufsetzt, was halt
ein Problem ist, weil
naja, das ist halt nicht Async
und das kriegst du auch nicht dazu.
Und Django hat es da sogar ein bisschen einfacher, weil Django ist
nämlich älter als WSGI
und WSGI ist schon irgendwie da so
dran gebastelt
und jetzt kann man halt auch noch was anderes ranbasteln.
Man hat auf jeden Fall eine Stelle, an der man was ranbasteln kann,
die bei Flask so nicht da ist.
Deswegen dachte ich so, naja, also das Flask
asyncfähig wird nicht passieren.
Aber es ist tatsächlich passiert, jetzt mit 2.0
geht das und sie haben auch
eine Menge, eben sie haben halt
die Abwärtskompetitivität
beendet,
jedenfalls.
Aufgegeben.
gleichzeitig aufgegeben.
Aber in einer Major-Release kann man das auch machen.
Aber dann hätten sie es geschickt,
weil sie hätten das Flask 3 nennen müssen.
Weil das ist doch das, wo in Python immer die
Kompetenzen zerbrechen.
Genau.
Das braucht jetzt mindestens Python 3.6.
Und genau, man hat jetzt auch
Async-Geschichten da drin und SGI.
Und es gab da immer so ein
Ding dafür, Quad. Das gibt es auch immer noch.
Ja, da hatte ich
ist übrigens auch her die Idee
aus einer Podcast-Episode mit
dem jetzigen Mentainer von
Flask,
dass man doch,
weil der sagte so, ja, irgendwo, wozu braucht man das denn?
Das ist doch irgendwie, in der Flask-Welt
machen wir das schon seit jeher
mit Eventlets und
G-Vent.
Okay.
Und das geht?
Und das geht? Und dann habe ich es probiert und ja, es geht.
Tatsächlich, das kann man machen. Und das ist halt
möglicherweise auch tatsächlich eine einfachere Lösung für
dieses File-Surf-Problem
einfach einen G-Event-Worker
nimmt, der dann halt die Standard-Bibliothek
monkeypatcht und alle synchronen
I.O. Calls ersetzt durch
nicht-blockierende und
das funktioniert dann einfach magisch.
Über monkeypatching ist halt so ein bisschen gefährlich,
aber wenn das nur für die Worker macht, die die
Files ausliefern, ist es vielleicht auch nicht so schlimm.
Ja, aber
und was man da auch machen kann,
ist, man kann das gleichzeitig machen. Man macht halt
G-Event irgendwie auf dem
Main-Thread und
packt halt, und das macht Django ja auch, und zwar auch aus dem Grund, um G-Event und Eventlets
nicht zu brechen, den ganzen, die lässt die Event-Gloob in einem
anderen Thread laufen. Und dann alles, was I think await macht, läuft dann halt in einem anderen Thread
und trotzdem funktioniert diese ganze Eventlet-G-Event-Geschichte
weiterhin. Also interessant wusste ich alles gar nicht,
aber auf der anderen Seite sagten die auch, ja, also tatsächlich, um kompatibel zu sein
zu moderneren Bibliotheken und so, wo man await-Syntax
als ein erweitertes Syntax verwenden
muss dann, weil die nur noch das können.
Ja, bleibt uns wohl auch nichts anderes übrig,
müssen wir das auch irgendwie können, weil
du kannst halt in einem synchronen Funktionsaufruf
nicht irgendwas erweiten, das geht einfach nicht.
Ja, und deswegen ist es auch
in Flask jetzt drin und ja, das wird
also Flask immer noch weiterentwickelt
voll gut. Ich weiß nicht so recht,
ich habe mit dieser ganzen
Welt nicht so wahnsinnig viel zu tun,
weil ich jetzt ehrlich gesagt auch keine Flask-Projekte
oder sowas habe oder Dinge, wo ich was
schreibe. Ich benutze dann immer,
ich habe noch ein paar Sachen, die Fast
API sind und das finde ich auch sehr nett und ich glaube,
das wäre so ähnlich wie Fast quasi.
Also auch
in der Hinsicht, dass es halt nicht
dir vorgibt, was, also
es ist halt nicht integriert, sondern
es geht gar nichts mit, sondern du musst alles
dann halt selber
konfigurieren und zusammenstecken.
Ja, aber es ist halt, war halt
nativ direkt Async und macht alles über Type
Annotation und so.
Ja, insofern,
Aber ja, es ist schön, dass das
Pflaster halt auch jetzt einen neuen Release hat.
Ja, sehr cool. Wenn wir jetzt schon bei den ganzen
Webprogrammings sind, liebt Pyramid eigentlich noch?
Ja, da gab es ja auch,
weiß nicht, ist jetzt ein paar Monate her, glaube ich, aber
gab es auch einen neuen Release.
Ja, habe ich allerdings auch nichts
mehr zu tun, keine Ahnung, kann ich nicht mehr drüber erzählen.
Aber es ist,
in unserem Bekanntenkreis gibt es Leute, die
das ganz stark
ja, in der
Pi-DDF-Politik.
Kommt immer wieder was auf.
Ja, genau.
Ja, ich finde, dann haben wir einen kleinen Überblick
über die Jungle-Kurve tatsächlich jetzt gegeben.
Guckt euch die ganzen Videos an,
wenn sie alle draußen sind. Das ist bestimmt nochmal
interessant.
Ja, mache ich auf jeden Fall.
Genau.
Wollen wir noch was vergessen? Habt ihr noch was dazu?
Wollen wir noch Pics machen?
Oh ja, können wir machen.
Jochen, was war dein Pick dieses Mal?
Ich habe
dieses Mal keinen Pick mitgebracht.
Na gut. Doch, doch, ich habe einen Pick.
DevDocs.
DevDocs, ah, ja, achso.
Tja, die hatten wir leider schon in der letzten
Episode. Hattet ihr schon? Okay, gut.
Dann wiederhole ich das, dann bekräftige ich das.
Jeder sollte sich das sofort auf seinen Rechner
runterladen und für alles benutzen.
Ich fand es ja sehr schön, ich habe das
jetzt kürzlich gefunden und habe dann natürlich
direkt alle Dokumentationen runtergeladen, die es runtergeladen hat.
Vielleicht, weil du unseren Podcast gehört hast?
Natürlich.
Ich habe es nachgeholt, quasi.
Was mich sehr belustigt hat war, ich habe diese Dokumentation runtergeladen in den Offline-Modus
und die Django-Dokumentation sind glaube ich 6 MB
und die Python-Dokumentation sind etwas über 9 MB
und die Dokumentation für die DOM sind 64 MB
Also 6,5 Pythons muss man komplett kennen, um die DOM benutzen zu dürfen
Fand ich erschreckend.
Erschreckend-belüstigend.
Ja,
damit ihr nochmal wisst, was das ist, man kann
sich halt tatsächlich auf einer einzigen Seite
die Dokumentation von verschiedensten Frameworks
und Sprachen irgendwie auf seine
Favorites legen und hat dann direkt einen Zugriff
auf das Buch.
Jochen, was ist deine
Faktion?
Was ich tatsächlich sehr schick fand,
habe ich jetzt, meine ich auch,
habe ich das,
AIO SQL ist so eine ganz
eigene Art, wie man
jetzt nochmal, also ich dachte dran,
musste dran denken, ich weiß nicht mehr, wie ich drauf gekommen bin,
als ich den Talk
zu RAW, SQL und Django
gehört hatte und da hatte ich so,
ja, also man kann halt
auch sich
so als alternatives Konzept zu
dem klassischen ORMs, wie man so hat,
einfach alles über
Statements definieren und dann dieses
Statements halt so ein bisschen parametrisierbar machen
und das ist halt, das ist auch alles Async und so
und das ist
auch eine sehr nette Geschichte, kann man sich mal angucken.
Also direkt erst so GEL-Statements aus Python.
Ja, ganz, ganz anderer Ansatz als
der OAM-Ansatz, den man so kennt, aber auch
irgendwie interessant.
Und, ah, eine Geschichte,
das fand ich sehr verwunderlich,
ich dachte jetzt eigentlich, ich fange jetzt mal mit so einem Stream an,
ich habe ja auch nirgendwo gesagt, dass ich das tue oder so,
außer euch jetzt.
In dem Twitch-Stream waren eigentlich relativ sofort irgendwie Leute drin und da muss ich mich auch erstmal dran gewöhnen.
Und da hat jemand gesagt, also als ich da irgendwie mit Git die ganze Zeit so rumgemurkst habe auf der Kommandozeile, nimm doch einfach Tick.
So, das gebe ich jetzt einfach mal so weiter. Ich habe es noch nicht benutzt, ich weiß gar nicht, ob das gut ist, aber das ist wohl ein Endcursus-Client für Git, der vielleicht ein bisschen besser ist.
Aha, interessant. Muss man sich mal angucken.
Ja, ich habe auch noch einen kleinen Pick. Ich würde
diesmal eine Business-Anwendung nehmen
und zwar Lifetimes, das gehört auf PyPy
und wenn man da quasi
Bestelldaten von Kunden reinpipet,
dann bekommt man quasi die
Absprungrate, die Turnrate ausgerechnet.
Das ist tatsächlich
gar nicht so schlecht, wenn man so Sales machen möchte
oder so.
Das habe ich so entdeckt und fand ich gut.
Das funktioniert echt gut für gute Businesses.
Kann man wahrscheinlich auch verkaufen, also an Endkunden
oder so, die wollen das alle haben.
die Library, dass du einfach nur die Library
verkaufst. Ja, du musst ja natürlich schon
rechnen auf die Churnrate.
Durch die Daten der Kundenpipen, aber ja.
Ja klar,
das als Service anzubieten,
ist eine coole Idee.
Ja, vielen Dank, dass ihr wieder eingeschaltet habt,
dass ihr zugehört habt. Bleibt uns gewogen, heute
nachts, morgens, mittags, abends,
am Wochenende und seit der Woche beim Schwimmen gehen.
Ja,
schönen Tag, schönen Zeit.
Bis dann. Tschüss.
Das hoffe ich nicht so. Tschüss.
Spät, ja. Tschüss!
Ja, diesmal lassen wir uns nicht so viel Zeit.
Bis dann, tschüss!