Transcript: DjangoCon Europe 2021

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.

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.

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

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,