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 und ja, heute ist wieder Johannes dabei, hi Johannes.

Hallihallo, hallo, hi Jochen, hallo, ich bin der Dominik, hallo, genau, ja, wollen wir direkt mit der DjangoCon starten oder haben wir noch andere News, die da irgendwie reingehören?

Ja, Django-Con sind die wichtigsten News.

Okay, also die paar News, die ich habe, die kann ich auch direkt, 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 musste man ja kurz ein bisschen warten.

Nee, dann.

Wir haben euch 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-Con?

Nein, ich nicht.

Achso, dann können wir dir ja davon erzählen.

Genau, ich wollte gerade sagen, es 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?

Ja, das ist auch gleich das erste große Highlight, würde ich sagen.

Ja, das war auch so ein Ding, was mich total überrascht hat.

Also 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 Daniele Prosida hat diesen Talk gehalten,

der erste Talk in der ganzen Konferenz

und war direkt großartig.

Ich hatte Daniele 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 total 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, da dachte ich so, ja, ja

voll gut

und dann kam irgendwann der Punkt, wo das dann

umschlug und ich so, ja, kann das 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

Erwischt

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

doch. Das ist schlecht, ich weiß.

Das hat mir jetzt jemand letztens in einem

Jungle-Con-Talk erzählt. Wo ist dein purpose-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 das 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 wieder vielleicht bei so einem

Quantifizierungsbeispiel, was das denn überhaupt ist.

Ja, das spielt keine Rolle.

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.

Und

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. Ja, 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 ja was anderes als ein quengelnder Manager, der wird dann

gerne mal... Ja, aber auch wenn man

den Kunden nie sieht. Aber ein quengelnder Manager hat jeder.

Ja, deswegen ja, also das ist nicht so effektiv.

Nee, überhaupt nicht.

Nee, das ist nicht so. Oder

Jira-Tickets, ja. Jira-Tickets machen jetzt nicht

unbedingt so empathische Reaktionen.

Ehrlich gesagt, ich

ja, also

das ist für mich aber auch

wie man die Tickets dann irgendwie schätzt, wie lange das dauert

das ist halt auch irgendwie so eine subjektive Sache und man kann halt

sich auch mal mehr Zeit lassen, mal weniger und so

mehr Zeit dann verbringen mit der

schönen ästhetischen Herangehensweise

diese Aufgabe zu

lösen, ne? Das ist für mich aber auch

so ein bisschen die Gegenhypothese, also auch

Software, die keinen Spaß macht zu schreiben, ist auch nicht gut

auch Kobol-Programme sind meistens nicht

super

und da möchte ich

niemandem vorwerfen, dass er Spaß dran hatte, die zu

schreiben. Kobalt, ist das nicht die 13. Kolonie in

Battlestar Galactica?

Ja, das ist...

Letztes Jahr hat man ja gesagt, das Schlimmste an Covid-19 ist,

dass es auch ein Jira-Ticket sein könnte.

Ja.

Ja.

Wir mussten ein Projekt intern umbenennen,

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 darunter leiden.

Also es ist auf jeden Fall schon so und das ist auch genau wie Daniel Poloschida 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 beruhigt.

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 nur sitze und nicht stehen kann.

Schön ist ja die Idee, die ich mal gesehen habe.

Genau, beim Standing-Desk mit einer

Laufwand drunter, fand ich ja ziemlich cool.

Das wäre so eine Sache, das müsste ich eigentlich noch machen.

Dann kannst du noch die Geschwindigkeit, kannst du dann auch noch

irgendwie übertragen auf die Maus-Geschwindigkeit

oder sowas.

Weil ich mache das wirklich

auch sehr gerne, auch in der Freizeit, also wenn man irgendwie

Zeit hat, Sachen zu bauen, das ist halt irgendwie

so ein was Schaffendes, so was Schönes,

Kreationistisches, das ist echt was Tolles.

Das ist halt so ein bisschen wie mit Lego spielen.

Ja, aber niemand von uns würde

in ein Lego-Haus einziehen wollen.

Ja, ja, ja. Das ist ja irgendwie so ein Handwerk.

Man hat hinterher was Richtiges in der Hand. Also vielleicht sowas wie mit

Holz. Also nicht, dass ich jetzt irgendwo gut mit Holz arbeiten

konnte, aber so vom Gefühl her.

Das kann man schön machen, dann noch

lackieren und dann mit einem Schwung, einem Bogen

rein, ein ganz tolles Holz auswählen,

dann mit einer schönen Maserung und so.

Und dann eine ganz tolle Sache zusammenfliegen.

Das ist ja fast schon was Klischeehaftes.

Gerade zusammengesteckt.

Fast schon klischeehaft, dass Softwareentwickler

dann irgendwann zu Woodworkers werden.

Ja, das ist wahrscheinlich

auch tatsächlich halt sowas Ähnliches, nur

dass die Rahmenbedingungen halt 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,

da was zu haben. Aber auch da,

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, so ganz

naiv, wenn man

sein eigener Kunde wird,

wo man dann quasi,

Ja, dass man sagt, okay, ich bin halt dann derjenige,

der am Ergebnis auch interessiert ist,

weil es ist halt auch mein Produkt.

Genau, das würde ich halt auch sagen.

Ganz richtig, 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 den ich ja meistens gar nicht.

Ja, genau, aber wenn das halt so ist und halt irgendwie

ein Management das halt nicht hinkriegt, was verkackt,

dass du halt so eine Informationsasymmetrie bekommst

zwischen User-Story oder Management,

weißt, 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.

Wir erzählen halt irgendwas 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 Teilen fertig und hast

wieder Zeit 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

und... Ja, das fällt halt auch dann

meistens mal runter, weil die Leute immer sagen, ja, das ist alles

total unwichtig, oder so

Refactorings oder sowas.

Für einen selber als Programmierer ist es nicht ganz so

wichtig, ja.

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 Furchier.

Der macht auch sonst gute Talks.

Der hat auch schon welche über Dokumentationen gemacht,

die ich auch sehr gut fand.

Sind die eigentlich schon online, die Talks?

Ich glaube nicht.

Die müssen aber jetzt in den nächsten Tagen

irgendwann auf YouTube erscheinen, oder?

Ich glaube, 30 Tage habe ich irgendwo gehört,

aber ich weiß es nicht.

Wann war die nochmal genau?

Am 2. Juni.

2. Juni.

2. bis 6. Juni.

Dann ist ja jetzt in 10 Tagen alles da.

Müsste demnächst soweit sein.

Also ich weiß nicht, wie sie es machen, aber ja.

Cool.

Was hat euch denn noch super gut gefallen?

Also ich meine, das habt ihr vielleicht noch gar nicht gesagt.

die beiden hatten auch einen Talk, beziehungsweise einen Worktop,

die ich natürlich beide dann doch getalkt habe.

Der nächste Talk, der mir sehr gut gefallen hat, war der von

Jochen Wersdorfer, war sehr, fand ich sehr, sehr gut.

Jochen, erzähl,

hast du den auch geguckt? Erzähl doch mal.

Ich habe gerade übrigens 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 gedoxed.

Kann man auch nicht wirklich verändern.

Ja,

nö, das, genau, also ich habe

den auch ein paar Mal, ich habe den, ich habe ja tatsächlich

so ein bisschen dann geübt und so

und dachte, oh, vielleicht kann ich

dann 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.

Um mal kurz euch vorzustellen, wie Jochen das macht.

Jochen schmeißt tatsächlich ein mega krasses

Technik-Setup, wie er schon mal gesagt hat. Oh, Content interessiert

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 cool im Setup da auch

mit seinem großen, was ist das

für ein Fernsehstudio

Kontrollpult. Genau, das war 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 da 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 da 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, 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 getalkt hast, aber über was denn?

Das ist ein Thema, mit dem ich seit einiger Zeit

irgendwie so ein bisschen hadere oder wo ich dann rumfeile.

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 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 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 Dateinahme

den Hash des Files nehmen oder so

und das irgendwo auf einen öffentlichen Webserver

packen und dann sagen, naja,

also wird schon keiner finden. Wird schon keiner erraten,

was der Hedge ist. 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 Client-Seite, dass halt irgendjemand

die Links verschickt. Speichert oder

das verschickt oder so. Ganz genau.

Und dann hat man halt. Du kannst es auch nie wieder zurücknehmen.

Ja. Wenn du es einmal jemandem gezeigt hast,

der hat es für immer. Genau.

Und das ist halt so ein bisschen

vielleicht nicht unbedingt das fassen will. Und wenn man dann sagt so,

oh, das ist aber eigentlich vielleicht nicht so ganz so optimal,

dann kommt halt häufig so, ja,

ach, das wird schon,

das ist jetzt,

das lösen wir dann später mal, keine Ahnung,

da müssen wir uns mal Gedanken drüber machen.

Ja, aber das ist halt dann schon eine relativ

zentrale Geschichte, dass Authentifizierung irgendwie

funktioniert. Und später

sich drum kümmern ist halt bei solchen Sachen oft ziemlich

schwierig, wenn man dann halt schon irgendwie

Dinge hat, die darauf basieren, dass das so funktioniert,

wie es funktioniert. Und wenn es kaputt funktioniert,

dann ist diese, das ist halt sehr schwer hinterher ein System nochmal reinzubringen und dann hat man halt eigentlich ein unsicheres System und das ist natürlich eigentlich nicht so richtig, dass man es 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 und die Art.

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?

Ja, ja.

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,

in der nur ein Header gesetzt ist.

Also Xen-File oder X-Excel heißt der, glaube ich, bei NGINX.

Wo dann drin steht, ja, ja, das ist schon okay.

Und dann ersetzt der Nginx die leere File-Response durch die echte File-Response.

Und wo kriegt der die her?

Ja, der braucht dann halt Zugriff auf, wie auch immer, das Verzeichnis oder was auch immer.

Also aus einer Datei, oder?

Ja, genau.

Okay, aber das ist ja schon mal ziemlich cool, oder?

Dann kann ich ja sagen, hier, 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 cool.

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

naja, also man hat

jetzt plötzlich zwei Systeme, die Zugriff auf alle

Daten haben müssen. Also

zumindest auf alle Dateien haben müssen.

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 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.

Man verschiebt quasi so ein bisschen was von dieser Testlast in den operativen Bereich.

Weil 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, wo

Daten rumliegen. Das passiert so gut wie

die, ja. Also auch

diese Leaks, die dann immer gibt.

Das passiert ja

nicht. Also ich meine, tatsächlich ist auch eine der häufigsten

Sachen, die man so sieht, dass dann irgendwo jemand

halt sich mal irgendwelche Sachen angeguckt hat

und dann, oh, was ist denn da? Hier sehe ich

meine Dateien. Hm, was ist denn? Da gibt es halt vielleicht noch mehr.

Oder dass irgendwelche Backup-Server

offen sind oder dass irgendwelche Log-Server

offen sind oder dass irgendwelche. Ja, 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. Es hört sich halt auch so ein bisschen an, als wäre es

ein bisschen komplexer, zu dem

NGINX zu erzählen, dass er die selben Sachen versteht

für Authentifizierung, Autorisierung, wie zum Beispiel

die Applikationshilfe mit dem Django dahinter

oder so.

Nee, das ist gar nicht das Problem.

Das muss er nicht. Der Request geht ja durch

einen Applikationsserver. Das heißt, der Applikationsserver

entscheidet. Der Nginx

sieht nur den Header und macht dann, oder

macht eben nicht. Das heißt, das Einzige, was man quasi macht,

muss die richtigen Header setzen und dann läuft es.

Vom Applikationsserver aus, ja genau.

Das ist auch sowas. Da gab es dann in der Reaktion

auf den Talk, glaube ich, im Slack

oder so, hat dann jemand gesagt, da gibt es doch in Nginx

auch ein Ding, wo man

der Nginx dann beim Applikationsserver nachfragt,

ob das authentifiziert ist oder nicht. Das ist auch sehr schön.

Das ist, also würde ich sagen,

funktioniert ähnlich gut und das ist vielleicht sogar noch mal

ein bisschen besser, weil man es dann

schlechter falsch konfigurieren kann, weil

ja.

Es ist leichter testbar, oder?

Es ist leichter testbar. Wenn die Authentifizierung

nicht da ist, darf der einfach nichts ausliefern.

Das kann man leichter nachweisen.

Also insofern, das kannte ich noch gar nicht und das

klingt eigentlich auch sehr gut.

Das ist durchaus eine Geschichte, die man machen kann.

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 kann ich ja auch auf Private schalten

oder Public. Gibt es denn da auch eine Möglichkeit?

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 im Grunde, die URL, die man an den Browser ausliefert,

da steht halt,

also ist halt eine Signatur drin. Ein Token

dran oder? Ja, so was. Also

es ist ein bisschen mehr Daten, es ist nicht nur

die Signatur, sondern es ist halt immer noch so

also ich weiß nicht, ob das dann letztendlich JSON ist

oder so, also das kann man auch, ist halt wahrscheinlich

gibt es verschiedene Techniken für, genau

da steht dann halt meistens noch sowas drin

wie, also diese URL ist

jetzt 30 Minuten gültig ab jetzt, oder ab

diesem Zeitstempel, oder die ist halt nur

gültig für IP-Adressen aus

dem Adressbereich oder sowas. Oder nur für einen Klick

oder sowas, oder für 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, da kommt es halt

darauf an, wie die Domains aussehen und so

und wenn das eine andere Domain ist, ist es manchmal vielleicht schwierig

also ob man jetzt als

Applikationsserver ein Cookie setzen kann für

die Domain, unter der dann tatsächlich

die Files liegen, aber wenn man 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

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 in Django Admin

sagt, diese Files, dieser User,

darf die nicht mehr sehen, dann

kann das halt nicht sofort funktionieren,

sondern wenn man halt eine gültige URL hat, dann

ja, funktioniert die erst mal

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 daraus zu kriegen.

Es ist halt so ein bisschen, also es ist

besser als nichts zu machen, aber es ist halt immer noch so ein bisschen

so, ah, 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?

hast du 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

steht immer drin, nee, macht das nicht. Also wenn ihr

irgendwie Files ausliefern wollt, macht das über einen

getrennten App-Server, der da statt

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-Fogged, also sozusagen

Es gibt mehrere Prozesse, die halt Requests beantworten, davon gibt es halt so ein paar, eine Handvoll vielleicht oder allgemein vielleicht zweimal Anzahl der Cores plus eins oder so, was halt halbwegs optimal ist und solange die irgendwas ausliefern, sind die halt belegt und wenn ich jetzt einen Pfeil ausliefer, das groß ist oder einen kleinen Tab, der sehr wenig Bandbreite hat, dann kann das halt lange dauern und solange wie das dauert, ist der Worker-Prozess sozusagen belegt

und wenn alle Worker-Prozesse belegt

sind, dann kann niemand mehr anrufen

und dann ist es schlecht.

das hinausläuft.

Und genau.

Ja, daher sollte man das nicht machen,

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 es 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 konkurrent bedienen.

Genau, und das kann dieses Pre-Forked-Worker-Modell-Synchronen-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 Standardschnittstelle zwischen Applikationsserver und Web-Framework ist halt WSGI.

Und WSGI kann das halt einfach nicht.

Da ist halt, das sind halt

synchrone Funktionsaufrufe, da kannst du auch nichts machen.

Und

ASGI, also der quasi

Nachfolger, der halt dann auch

sozusagen asynchrone

Dinge

kann, der ist halt noch nicht so alt,

ist auch quasi auch im Kontext von

im

Django-Kontext irgendwie entstanden.

Der Standard ist von Andrew Godwin geschrieben worden,

der halt auch... Ja, das habe ich im Janals-Projekt

aus dem Janals-Projekt, das ist rausgefallen.

Genau und damit geht das dann, aber Unterstützung für die Syntax war auch lange nicht möglich, weil 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 Await Syntax geht damit nicht und auch mit Python 3.5 ging das nicht gut.

ich weiß ehrlich gesagt nicht genau, woran das

liegt, also weil die Syntax kam eigentlich mit

3.5, aber alle Bibliotheken, die das

irgendwie, die Async Await 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-Springs und alle sagen so,

ach, wenn wir jetzt schon was Modernes haben, wollen wir auch F-Springs

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.

Auch Debian ist inzwischen auf 3.8

und oh wow, okay.

Ja, 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 ASGI und halt auch

prinzipiell die Möglichkeit

AsyncIO-Syntax zu verwenden in Django.

Aber es gab noch keine AsyncViews.

Das heißt, man konnte keine

AsyncFileResponse schreiben,

weil, naja,

Isingviews 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.

August 2019 meinst du?

Nee, 2020.

Letztes Jahr war doch 2019.

Ach ja, okay.

Ach ja.

Ja, okay,

auf jeden Fall gibt es das erst seit ungefähr einem Jahr.

Genau. Und damals hatte ich ja auch

schon ein bisschen... Warum ist das cool?

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 damals einen Artikel

auch drüber geschrieben, mit Dominik zusammen.

Genau, der ist sogar

in der Zeitung erschienen, auf Deutsch dann, unter deinem Blog.

Echt? Cool.

Darf man das sagen, Entwickler?

oder? Ja, ich glaube, ja.

Schickle-Magazin war das.

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 halt 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 der

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, halt gleichzeitig

los und

die Antworten kommen halt sozusagen dann

auch concurrent zurück und

nur, also 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ößenordnung schneller

bist oder so. Und das ist

dann ja schon praktisch.

Und das war so der Anwendungsfall.

Hatten wir da nicht auch drüber gesprochen in der

Async-Episode? Ja, ja, bestimmt.

Ja, genau, da hatten wir ja auch schon mal

zwei Episoden dazu gemacht.

Wir brauchen noch mehr.

Thema, da kann man immer noch mal drüber sprechen.

Ja, vielleicht sogar alle gleichzeitig.

Wenn man ein Thema einmal drin hat, dann muss man das auch ein bisschen ausschalten.

Ja, genau.

Aber jetzt, genau, ist mir dann halt irgendwann,

das war so Anfang des Jahres, dann dachte ich so,

ach, wenn man jetzt schon so Async-Evade hat,

vielleicht ist ja tatsächlich Files-Serven

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

hat so ein bisschen gedauert und irgendwann aber

dachte ich so, 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

genau, das war dann auch Thema

des Talks im Grunde und ja, es

funktioniert auch tatsächlich, ich habe jetzt

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 interessant 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 ASGI-Händler, das ist so

das Ding, was halt mit

die Applikation ist, quasi die

ASGI-Applikation, das ist halt der ASGI-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.

Ja gut, aber das ist in MPR auch prinzipiell möglich.

Oder dass man Subklassen anbietet oder sowas.

Ja, muss man

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 das halt

entweder get

Async-File-Response-Händler

oder Application

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 funktionieren.

Ja, genau, dafür gibt es Tests.

Ja.

Ja, klingt auf jeden Fall ziemlich cool. Das heißt, man kann jetzt

einfach mit dem Dango-Applikations-Server

seine Files direkt ausliefern.

Man muss sie nicht mehr irgendwie außen vom

Web-Server quasi routen lassen, sondern man kann direkt sagen,

Dango, hey, nimm die doch mal direkt aus.

Was nutzt man dafür? Dango-Storages raus oder so

und liefer die mal mit.

Ja, und das, achso,

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

auch mein Ziel. Ich habe es mit dem Filesystem gezeigt,

aber Filesystem 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 den 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.

Oder 7.

Geht alles, aber ist halt auch so ein bisschen

äh.

Ancient Relaying.

Ja, also die

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.

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 ihm 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.

Ich da vorsitze und keine Ahnung habe, was ich da eigentlich tue.

Genau, Jochen ist auch nur Mensch und macht die ganze Zeit Fehler und so und mir fällt

wenn ich da vorsitze, ich möchte die ganze Zeit

hier so einen Stock nehmen und

Bist du auch wünschend gegen Jochen? Kann man sich wünschen, was du

programmierst? Oder programmierst du 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... Immer wenn ich denke, hä, 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 irgendeiner

Library gefunden, sozusagen, und

dann sitzt 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, was man da so

rumsucht. Also Jochen benutzt dafür

übrigens NBDEV.

Da hatten wir auch schon mal eine Folge 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, kann ich das machen.

Du musst das ja nicht nochmal anders machen, also nochmal

in VI und einmal in VS Code

oder so, da können wir mal 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.

Vielleicht kriegen wir das ja auch mit dem Podcast nochmal

da so ein bisschen

den vielleicht so ein bisschen

Video-Live-

Live-Schalter gestalten.

Mal gucken, ob wir dafür Zuschauer

begeistern können.

Ja, cool. Genau.

Ich glaube, noch jemand hat halt tatsächlich

einen Workshop bei der dann begonnen.

Ja, ich bin ja

quasi schuld dran, dass der ja von dem

Talk überhaupt eingereicht hat, weil ich

hab das nämlich auch gemacht und das war bei mir auch so ein bisschen

so halb spontan.

Also lange geplant.

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 hatte. 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 ist ja noch 2020.

Ja, wieso?

Ich habe den Witz eben nicht verstanden, deswegen habe ich ihn noch nicht gefasst.

Wir müssen den Witz jetzt einfach so lange wiederholen, bis 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.

Und 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

mehr aufgeschrieben.

Während des Live-Talks

sind es 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.

Wagen euch auch ein bisschen mehr für Einsteiger

geeignet, glaube ich, den Talk, den du gemacht hast, das was doch

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, also 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. Und 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. Und ich

wechsle da immer so ein bisschen hin und her.

Ich sehe die Vorteile von beidem. Und 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 Apps-Folder.

Zum Beispiel der Apps-Folder, 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 Config-Verzeichnis

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.

Vollnützliche Informationen, ja. Echt sehr gut.

Ich habe da jetzt auch inzwischen

das so eben zusammengefasst,

dass man also mit Startproject

slash slash Template

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 noch

machen. Können wir mal zusammenprogrammieren.

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 auf jeden Fall mal angucken.

Kommt auch in zehn Tagen.

Genau, wir verlinken das.

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.

Ja, das fand ich auch, ehrlich gesagt, damit hätte ich nicht gerechnet,

wie oft man dann ein paar Mal aufgenommen

und dann passiert irgendein Scheiß.

Das war einfach nochmal.

Fällt einem die Kaffeetasse 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.

Audio-Aufnahme und Kamera-Aufnahme und

Screencast. Und da wollte ich

zusammenschneiden und dann war der Screencast kaputt.

Und dann habe ich gedacht, jetzt muss ich nochmal

eine Stunde mich hinsetzen und nochmal das

ganze Ding machen. Aber zum Glück war es nur die

Datei auf der SSD, die

auf der mobilen SSD, die ich fertig kopiert hatte.

Konnte ich dann tatsächlich noch retten.

Und da war ich so,

ich hätte sonst,

der Rest des Tages wäre sonst futsch gewesen.

Ja, also dein Probevideo ist auch abgestürzt, glaube ich,

30 Sekunden vor Ende. Das heißt, man hat deine Grußworte

nicht mehr ganz mitbekommen. Das hast du ja dann auch noch gefixt.

Habe ich auch noch gefixt, genau. Also es

gab da verschiedene Aufnahmen, die alle nicht so gut

waren und dann gab es alle, die ganz okay waren.

Also ihr merkt, es ist auch eine relativ viel technische Detailarbeit

hinten. Ja, aber tatsächlich

erstaunlich viel mehr Vorbereitung,

als ich gedacht hätte.

Genau. Und aber

was ich sagen muss, also das war

dann, da war Johannes' Vortrag auch echt

einer der

positiv herausstechendsten,

also sowohl Video- als auch Audioqualität war gut.

Während

das aber, das war...

Ja, ja.

Tatsächlich muss man leider sagen, also ich fand,

oft war das nicht so gut. Ich hab dann

ich hatte während der Konferenz gar nicht so richtig

Zeit, das live zu verfolgen, weil

Dinge

passieren, genau.

Aber ich habe die dann alle versucht

nachzuhören hinterher und habe die dann

halt auf dem Telefon

laufen lassen,

weil, ja, auch hier komme ich nicht von Rechner

setzen. Dinge passieren, man hat keine Zeit.

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 stellen sich halt

nehmen halt ihr Laptop oder sonst irgendwas und stellen sich dann

halt irgendwie 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 von irgendwie Zoom

oder so und dann gehen die Lüfter an und

dann ist es schwer zu

verstehen. Also ich hatte tatsächlich bei einigen

Talks das Problem, dass ich kaum verstanden

habe und 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,

dass es halt so schlecht ist, dass man sich

wirklich anstrengen muss, um es hören zu können.

Und da denke ich vielleicht

auch manchmal, vielleicht sollte man,

da gab es ja auch so einen Talk, den gab es

diesmal nicht, aber glaube ich bei der letzten

DjangoCon EU,

How to get on the stage.

Der war verlinkt,

der war verlinkt für die Sprecher, damit die wissen,

was auf sie zukommt.

Und vielleicht kann man irgendwie so, wie kriegt man

eigentlich zumindest verständliches Audio

und nicht so, beim Video ist

ja fast egal, das ist 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

vielen nicht gut. Es gab

ein paar Ausnahmen, eben Johannes 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.

Nicht mir ist doch völlig klar, dass ich hier damit beschäftigen möchte.

Was man eigentlich bräuchte, wäre irgendwie so Sets, die man verschickt, wo eine gute Kamera dabei ist und ein gutes Mikrofon und die dann hinterher wieder zurückgeschickt werden.

und irgendwie ein Tutorial, wie man das anschließt

und wie man das, weil es ist halt dummerweise,

es ist leider schwieriger, als man so denkt

und genau. Ja, eigentlich macht man alles mit

so bunten Kabeln, die immer genau an die richtigen Stecker passen,

also die Stecker sehen genau so aus, wie die klingen

und dann steckt man es ein und dann hat man auf einen Knopf und dann läuft es.

Ja, USB, einfach nur

einen USB-Anschluss.

Ja, was mich tatsächlich so ein bisschen,

was mir so ein bisschen

negativ aufgefallen ist, war, dass

diese Zoom-Meetings oft qualitativ

nicht so cool waren, ja.

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 so, 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 von der ganzen Technikkritik

jetzt hier und 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 dann nämlich, wenn man sich da live

begegnet, 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 ja bei der

Dango Condor Live im Gather Town.

Es hat einfach eine Räumlichkeit,

du bist nicht, 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, ja, weil

du mit allen Leuten gleichzeitig sprechen kannst, aber es ist auch

so ein bisschen erschreckend, weil dir alle Leute immer

zuhören, ja, weil alles public ist.

Ja und außerdem meinte ich, die Leute reden vielleicht dann gar nicht,

weil irgendwer immer redet halt. Ja genau, weil man sich

nicht traut.

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 nettes Gefühl.

Also man kann eigentlich gar nicht so richtig viel kritisieren,

außer eben die Bildqualität.

Jochen, du hast alle Talks angeguckt, oder?

Ja.

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.

Genau. Ansonsten fand ich die, also man muss auch unter, also ich meine, es gab halt, es gibt halt mehrere Dimensionen sozusagen. Es gab halt Text, Talks, die mich halt irgendwie inhaltlich überrascht haben, irgendwie so wie die.

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, ja. Hast du vielleicht noch

eine Empfehlung von einem Talk, den man unbedingt gucken sollte,

wenn du jetzt mal drauf bist? Also einer

meiner Lieblingstalks war auf jeden Fall

der von Carlton Gibson.

Static Sides.

Das ist auch generell großartig.

Static Sides mit Zwings, 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

hat eben auch Vor- und 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

sozusagen die Art, wie

der Dokumentations-Content

in die Django-Dokumentationsseite reinkommt,

ist halt über JSON.

Das war mir überhaupt nicht klar

und das ist eigentlich aber voll gut.

Total absurd.

Und deswegen, also den Talk fand ich

auch technisch gut. Also das Audio war

super. Carlton macht das auch total

gut. Er ist total entspannt und

ein bisschen flapsig und kurz und

echt cool. Carlton Gibson

Static Pages, ja.

Carlton Gibson ist generell so einer, der in der

Community ganz viel macht. Er ist

einer von den Django Fellows.

Der 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 Winston 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

in einem 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-Cons, 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

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

erst so, ja, interessant, die ganzen

Dinge, die sie da 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 daran 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

darum gekümmert haben, vielleicht nicht

alle Funktionen und nicht so

im Detail ausgefeilt,

aber dafür halt irgendwie

Stimmig. Integriert. Genau.

Integriert. Ja, aber

was wäre denn, wenn Django nicht ein

Paket wäre, sondern wenn Django ein Meta-Paket 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

die y haben. Ja. 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,

es ist ja jetzt schon so, dass du die verschiedenen

Bausteine miteinander kombinierst,

aber was wäre denn, wenn die auf technischer Ebene

auch modular wären?

Was im Django-Chat gesagt wurde, was wäre

denn, wenn man manche Pakete einfach ein bisschen

ausgliedern könnte?

Carlton Gibson möchte gerne das E-Mail-Paket

ausgliedern.

Was wäre denn, wenn

das möglich wäre? Und was wäre denn, wenn sich da

vielleicht ein eigener Maintainer dafür findet, der

E-Mail macht?

Was wäre denn, wenn es

ein E-Mail-Paket gibt, was automatisch alles

macht, dass ich über SendGrid

verschicke?

Ich muss nur PipInstall, Django, SendGrid machen

und dann ist das komplett nah.

Diese Frage ist

Das ist eine großartige, gute Frage.

Okay, ja, gut. Also so gesehen doch,

ja, weil im Grunde ist Django

ja schon, da sind viele Teile sind ja schon

pluggable, eben Storage oder halt

Authentication, halt nicht auf so einer

ich installiere dann halt ein anderes

Paket, sondern auf der Ebene von

in den Settings sage ich halt, ja,

du bist jetzt für mehrere Pakete

und dann stelle ich es in den Settings ein, welches benutzt

wird. Genau, aber

stimmt, also dass man

den Code gar nicht mit drin haben muss, das ist natürlich schon so ein

Punkt, ja.

Das ist aber auch noch

interessant. 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.

Ich bin auch live während des

Talks Jazzband beigetreten.

Ah, okay, genau. Ich habe es mir nur überlegt,

ich habe es noch nicht getan, aber ich

habe stark daran gedacht, es zu tun.

Und

genau, ich hatte das immer nur gesehen.

Was ist denn Jazzband, Jochen? Erklär mal.

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 gemantet wird,

Django Filter und weiß ich nicht,

ganz, ganz viel Zeug.

Storages und Comments.

Also ganz

viel und da 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 mantennen, dann kann man das vielleicht dahin

das loswerden.

Projekthalde meinst du?

Irgendwie, weiß ich nicht,

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 es ist 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, also dieses

Privileg bekommt man halt

Normalerweise, weiß ich nicht, nach ein paar erfolgreichen Pull-Requests oder so oft bei vielen Projekten. Und vielleicht bei so noch größeren ist es so, dass es dann Leute gibt, die dann überwiegend, ja, 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, du kannst halt einfach da reinkommitten. Es funktioniert halt. Und dann muss, es gibt halt nur weniger Release.

Und jeder kann beitreten.

Jeder 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, 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

fragst du, ja hier ist was und dann weißt du es schon alles

gar nicht mehr oder geht ganz unter.

Ja und was ich dann oft mache ist,

ach 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 da

drin sind und dann hätte ich dann so, okay

eigentlich hätte ich die direkt fixen

können und

dann wäre dieser ganze

ja, hätte man diesen ganzen Tanz

um GitHub-Pull-Request-Issue gar nicht

machen müssen, sondern jetzt einfach gefixt, committet

und fertig. Was heißt bei Django

Field-Hastorisches All-Outs?

Django Field-Hastorisches All-Outs? Ja, ganz viele von diesen Sachen,

die man kennt, ich glaube auch Django Extensions und

Debug-Toolbars sind inzwischen Jazzband-Projekte.

Ja. Oh, apropos

Debug-Toolbar, da gab es ja auch was für das.

Der Jazzband, weil

das irgendwie sozusagen,

ja, Django ist ja auch vom Namen her

wird das zurückgeführt

auf dem Django rein hat.

Ach so. Ja, daher kommt das.

Und Band. Cooler Name,

finde ich. Ja.

Django Extensions, hast du noch irgendwas Schönes

geteilt, Johannes? Und zwar hast du

da was entdeckt, das heißt die Kolo-App

heißt, 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 hingeteilt.

Kolo-App, das ist eine Django-Applikation

zum Debuggen. Vor allem auch in VS Code

Grundsätzlich. Du kannst halt so den

Thor Street anschauen.

Genau, das hat mich jetzt

gar nicht so richtig, hat mir gar nicht so richtig

geholfen, weil ich VSCode nicht benutze.

Aber

die haben eben einen Django-Debugger

in VSCode integriert und zwar so richtig tief.

Also der zeigt einem direkt alle Innereien.

Genau, Best Response,

die Queries und so.

Genau, und auch mit Profiling drin und wenn

Fehler auftreten, kommst du gleich an eine richtige Stelle.

Genau, man kann sogar den Executed-Code-Path

visualisieren und so.

Es ist ein richtig, richtig ausgefeilter

Debugger, geht allerdings nur in Visual Studio Code.

Also Celery 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.

Auch was, was ich da gesehen habe. Okay, ich habe noch eine andere

Sache, die mich überrascht hat da.

Bei der DjangoCon.

Und das war HTMX.

Oh ja. 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 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 dann, 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.

Und auch im Slack

kam das dann auf,

dass da jetzt schon wieder

HTMX 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, ja,

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 Form-Klasse

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.

Ja, ich habe letztens,

ja genau, würde ich auch sagen,

das war auf jeden Fall auch eines der großen Themenfelder,

die es auf der Django-Con gab.

Nämlich, wie macht man eigentlich,

sozusagen, ja,

etwas interaktivere

oder so modernere,

so Single-Page-App