Transkript: DjangoCon Europe 2021

Hallo liebe Hörerinnen und Hörer, willkommen zum Python Podcast.

Heute in der Episode 2 to the Power of Five, Episode 32.

Heute geht es vor allen Dingen um Django Con 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, die DjangoCon 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 mal irgendwas zu tun.

Ja, Entschuldigung übrigens auch an der Stelle, dass wir euch hier so lange haben warten lassen in diese neue Episode, aber das war gerade absolut drunter und drüber im Privatleben.

Da musste man ja kurz ein bisschen warten.

Wir haben mich aber nicht vergessen.

Wir machen auch weiter.

Genau, genau.

Ja, da können wir eigentlich direkt einsteigen.

Waren wir alle auf der Django-Ponnen?

Nein, ich nicht.

Du nicht.

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

Genau, ich wollte gerade sagen, wir waren ja 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 vielleicht das erste große Highlight, würde ich sagen.

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.

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

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

Also für mich als Chef ist das jetzt totaler Mist.

Das heißt, ich muss jetzt irgendwie versuchen, euch anders zu erziehen.

Okay.

Eigentlich ja.

Also tatsächlich, ich fühlte mich, als ich das gehört, als ich den Vortrag gehört habe und ich dachte so, wir gingen ja auch schon so los, irgendwie so, ja, programmieren voll gut, ne?

Irgendwie total bessere.

Und jeder macht das ja auch selber zu Hause.

Ja, ja, voll hat es.

Voll gut.

Und dann kam irgendwann der Punkt, wo das dann ein Umschluck inside, 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.

Es ist aber 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

das ist schlecht doch.

Das ist schlecht, ich weiß.

Das hat mir jetzt jemand letztens in einem Jungle.

Wo ist dein

Curve-Driven Commitment?

Ja, das ist auch manchmal, aber das ist auch wirklich schwierig, finde ich, bei manchen Projekten.

Also, naja, und aber das Programmieren selber macht ja Spaß und da kann man sich auch drüber motivieren, aber das 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.

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

Aber 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 daran?

Da sind wir ja wieder vielleicht bei so einem Quantifizierungsbeispiel, was hast du denn überhaupt nicht?

Ja, das spielt keine Rolle.

Weniger Fehler wäre ja 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.

Und das ist halt normalerweise nicht das Ziel, mehr Software zu produzieren.

Und beziehungsweise da hat niemand was davon.

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 mal 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 Show sitzt und sagt, was ihm 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 Quängelner Manager, ne?

Der wird dann gerne mal.

Ja, oder aber auch wenn man die Kunden nie sieht.

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

Nee, überhaupt nicht mehr.

Nee, das ist nicht so.

Oder Jira-Tickets, ja.

Jira-Tickets machen jetzt nicht unbedingt so eine empathische Reaktionen.

Ehrlich gesagt, ich ist.

Ja, vor allem, die Art und Weise, wie man die Tickets dann irgendwie schätzt, wie lange das dauert, ist halt auch irgendwie so eine subjektive Sache und man kann halt 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 so ein bisschen die Gegenhypothese.

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

Au Cobol-Programme sind meistens nicht super.

Da möchte ich niemandem vorwerfen, dass er Spaß dran hatte, die zu schreiben.

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

Das muss man ein Projekt intern umbenennen, weil irgendjemand das Delta genannt hatte.

Ja, das ist das.

Aber ja, man fühlt sich auf jeden Fall adapt, weil ich meine, jeder von uns hat schon mal Sachen so vor sich hingedelt und die dann auf GitHub geladen und irgendjemand anders muss jetzt drunter leiden.

Also es ist auf jeden Fall schon so.

Und es ist auch genau wie Daniele Pruschida 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 Berufs.

Ich stelle mir gerade so einen Zahnarzt vor, der ist eine Sammlung von Gebissen in seinem

Garten liegt.

Ja, und dann vielleicht auch mal ein bisschen drin rumbohrt und sagt, ah, 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.

Ich finde ja die Idee, die ich mal gesehen habe bei jemand.

Genau, beim Standing Desk mit einem Laufwand drunter, fand ich ziemlich cool.

Das wäre so eine Sache, dass man.

Okay, ja.

Nein, aber ich möchte 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 was Tolles.

Es ist halt so ein bisschen wie mit Lego-Spielen oder und genau.

Ja, aber niemand von uns würde in ein Lego-Haus einziehen wollen.

Ja, ja, ja, ja.

Also irgendwie so

ein Handwerk, man hat hinterher was Richtiges in der Hand.

Also vielleicht sowas wie mit Holz.

Also nicht, dass ich jetzt irgendwann gut mit Holz arbeiten könnte, aber so vom Gefühl her, so das kann man schön machen, dann noch lackieren und dann schwungen einen Bogen rein, ein ganz tolles Holz auswählen, dann mit einem schönen Maserung und so und dann eine ganz tolle Sache sanftigen, was hier gerade zusammengesteckt.

Ich meine, ergibt sich.

Es ist schon klischeehaft, dass Softwareentwickler dann irgendwann zu Woodworkers werden.

Ja, das ist wahrscheinlich auch tatsächlich halt so was ähnliches, nur dass die Rahmenbedingungen halt nicht so schrecklich sind, wenn man schreien hat.

Und dass es auch egal ist, ja.

Da ist kein Manager, der hinter einem steht und sagt, ja, mach mal das hier, sondern es geht wirklich nur darum, da was zu haben.

Aber auch da, ja, 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.

Klar, Dogfooding.

Ja, dass man sagt, okay, ich bin halt dann derjenige, der im Ergebnis auch interessiert ist, weil es ist halt auch mein Produkt.

Ja, aber 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 es vorstellst, weil du halt diese User-Story quasi selber in dir drin trägst, ja, zum Benutzen.

Das sehe ich ja meistens gar nicht.

Ja, genau, aber da, also 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ßt, was richtig ist und du weißt, was du machen willst, das wird halt schwierig zu managen.

Also das ist eigentlich unmöglich Management.

Du kannst, die meisten Manager sind ja technisch jetzt nicht so affin.

Du kannst dir irgendwas vom Pferd erzählen und das machen dann auch irgendwann viele Leute, die halt keine Lust haben auf irgendwas.

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

Du bist nach zwei Zeilen fertig und du 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, also das fällt halt auch dann meistens mal runter, weil die Leute haben 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 mitentwickeln, vielleicht.

Das war auf jeden Fall ein großer Paukenschlag.

Direkt zur Eröffnung der Konferenz ist super gut angekommen und große Gebäude.

Programming for Pleasure, Daniel Fuchier.

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.

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

Bis 6.

Juni.

Dann ist er jetzt in 10 Tagen.

Müsste demnächst soweit sein.

Ja, also ich weiß nicht, wie sie es machen, aber.

Oh cool.

Was hat euch denn noch super gut gefallen?

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

Also die beiden hatten auch einen Talk bzw.

einen Workshop, die ich natürlich beide

dann noch getroffen habe.

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

Fand ich sehr, sehr gut.

Jochen, erzähl euch, 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 hab auf der Webseite war da auch schon irgendwie drauf.

Richtig gedopst.

Kann man noch nicht wirklich verändern.

Ja, nö, das, genau, also ich hab den auch ein paar Mal, ich habe da tatsächlich so ein bisschen dann geübt und so und dachte, oh, vielleicht kann ich ihn auch live halten.

Das hat dann irgendwie nicht geklappt, weil eben 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 vorstellen, wie Jochen das macht.

Jochen schmeißt tatsächlich ein mega krasses Technik-Setup, wie er schon mal gesagt hat, oh, Content interessiert ihn 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

S-Studio-Kontrollpult, ja.

So ein Atem Mini von Black Magic.

Und tatsächlich braucht man dann kein OBS mehr.

Das Ding streamt selber.

Ah ja, okay.

Also siehst du noch nicht mal OBS, hast du einfach selbst konfiguriert.

Und dann, ja, das sah 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 in einem Wikis.

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, weil ich hätte doch gar keine Slides fertig und so.

Ja, ich hab die Story, habe ich ja noch im Ohr.

Aber jetzt haben wir ja 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 dran 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 hat man das schon zu tun.

Und irgendwie diese 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 doch 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 da halt 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.

Dann wird schon keiner erraten, was ist.

Ja, das ist sicherlich 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 irgendwelche Logfiles oder auf der Client-Seite, dass halt irgendjemand die Links verschickt speichert oder das verschickt oder so.

Und dann hat man halt.

Du kannst es auch nie wieder zurücknehmen, 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, was man will.

Und man dann sagt so, oh, das ist aber eigentlich vielleicht nicht so ganz so optimal, dann kommt halt häufig so, ja, ach, das ist jetzt, das lösen wir dann später mal, keine Ahnung, oder dann, ja, da müssen wir uns mal Gedanken drüber machen, aber man sich denkt so, 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 Antwort, 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 das, was man 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, Mann?

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 die, diese Lösungsansatz, den habe ich ja mal, also den habe ich ja von dir, Johannes.

Ja, gibt es da was, was man mit Nginx machen kann?

Das weiß ich gar nicht, das kann man.

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 einen Header gesetzt ist.

Also Xen-File oder XExel 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.

Warum kriegt er die her?

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

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.

Genau.

Und das Ausliefern macht dann aber Nginx.

Also es ist ja schon mal

ziemlich cool.

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, naja, also man hat jetzt plötzlich zwei Systeme, die Zugriff auf alle Daten haben müssen.

Also zumindest alle auf alle Dateien haben.

Ja, okay, klar.

Ja 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 schief gegangen 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, ne?

Aber das ist halt

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 auch in der Echten Welt nicht, oder?

Dass irgendwas offen konfiguriert ist, wo Daten auch wie die.

Passiert so gut wie die, ja.

Also auch diese Nix, die dann immer gibt.

Das passiert ja nicht.

Also ich meine, tatsächlich ist es 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, was ist denn da?

Gibt es da vielleicht noch mehr?

Log-Server offen sind oder irgendwelche.

Ja, ja, und dann sind halt plötzlich alle Daten von allen Leuten irgendwie öffentlich und das ist halt furchtbar eigentlich.

Ja, und genau, also so kann man das halt machen, wenn man, 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, es hört sich halt auch so ein bisschen an, als wäre es ein bisschen komplexer, zu dem LGX zu erzählen, dass er die selben Sachen versteht für Authentifizierung, Autorisierung, wie zum Beispiel der Applikationsserver mit dem Dango dahinter oder so.

Nee, das muss er ja gar nicht.

Das muss er nicht.

Der Request geht ja durch einen Applikationsserver.

Das heißt, der Applikationsserver entscheidet.

Der Nginx legt nur den Header und macht dann oder macht ihn nicht.

Das heißt, das Einzige, was man quasi macht, muss die richtigen Header setzen und dann läuft das.

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, oh, da gibt es auch in Nginx auch ein Ding, wo man der Nginx dann beim Applikations-Server 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 nochmal ein bisschen besser, weil man es dann schlechter falsch konfigurieren kann, weil ja, dass man nicht mehr so gut ist.

Der Nginx ist auch leichter testbar, oder?

Ja, genau.

Es ist leicht getestbar.

Wenn die Authentifizierung nicht da ist, darf der einfach nichts ausliefern.

Ja, genau.

Das kann man leichter nachweisen.

Also insofern, das kannte ich noch gar nicht und das klingt eigentlich auch sehr gut.

Also 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 einen 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, ja?

Erzähl mal.

Genau, ja, also was man da tun kann, ist, man benutzt entweder Signed Cookies oder halt signierte URLs.

Und liefert die über den Applikationsserver aus.

Also das bedeutet im Grunde die URL, die man an dem Browser ausliefert.

Da steht halt, also ist halt eine Signatur drin.

Ein Token dran?

Ja, quasi sowas.

Also es ist ein bisschen mehr Daten, es ist nicht nur die Signatur, sondern es ist halt immer noch so ein, also ich weiß nicht, ob das dann letztendlich JSON ist oder so.

Also das kann man auch, ist halt wahrscheinlich.

Es gibt verschiedene Techniken.

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, 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 dann halt darauf an, wie die Domains aussehen und so, und dann 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 das kann, kann man das halt auch einfach so als Cookie setzen.

Und ja, das funktioniert halt auch.

Das ist 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 die nicht mehr sehen, dann funktioniert, 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.

Und 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 noch heutzutage noch besser machen?

Genau, meine Idee an der Stelle war, okay, naja, also 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?

Weil davon wird ja erstmal abgeraten, oder?

Weil er so Worker beschäftigt und dann hast du nur erstmal so und so viele App-Server und dann sind die langsam und brauchen viel Speicher und so.

Genau, genau, also in allen Tutorials und so steht immer drin so, nee, macht das nicht.

Also wenn ihr irgendwie Files ausliefern wollt, macht das über einen getrennten Web-Server, der da Files direkt ausliefern kann oder macht das mit White Noise und einem CDN oder so.

Aber macht das nicht über den Applikationsserver, weil das Problem beim Applikationsserver ist halt, dass es normalerweise standardmäßig ein Preforged, also zuzusagen es gibt mehrere Prozesse, die halt Requests beantworten.

Davon gibt es halt so ein paar, ein Handvoll vielleicht oder so im Allgemeinen 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 ausliefere, das groß ist oder einen Client habe, 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.

Worauf das hinausläuft.

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

Das heißt, man müsste die auch concurrent bedienen.

Genau, und das kann dieses Preforked-Worker-Modell synchronen Sachen ausliefern eigentlich nicht leisten.

Deswegen wird immer davon abgeraten.

Aber wir haben ja jetzt Async and Wait in Python seit einiger Zeit.

In Django noch nicht so lange, weil da konnte es halt lange nicht so richtig verwendet werden, weil, naja, die Standardschnittstelle zwischen Applikationsserver und Webframework 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 ist, glaube ich, von der Standard ist von Andrew Godwin geschrieben worden, der halt auch.

Ja, das glaube ich im Channels-Projekt.

Aus dem Channels-Projekt ist, das ist rausgefallen.

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

Also Async Await Syntax geht damit nicht.

Und auch mit Django 3, äh, 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, wenn wir jetzt schon was Modernes haben, wollen wir auch 11 auf 5 haben und dann geht das halt erst ab 3.6.

Ich habe keine Ahnung.

Ja, aber ich meine, 3.5 und 3.6 macht jetzt für uns nicht so den riesen Unterschied, oder?

Wir sind ja alle im modernen.

Auf Debian ist inzwischen auf 3.8 und.

Oh wow.

Okay.

Genau, jedenfalls also die Syntax kann man, also dass es überhaupt geht, ist dann, ist halt ab Django 3.0 so.

Support für Python 2.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 I.O.

Syntax zu verwenden in Django.

Aber es gab noch keine Async-Views.

Das heißt, man konnte keine Async-File-Response schreiben, weil, naja, 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.

2019 meinst du?

Nee, 2020.

Django 13.

Das Jahr war doch 2019.

Ach ja, ja, 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.

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 noch nicht tun kann, was auch total cool wäre, aber das wird halt auch 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 oben nichts zusammen.

Genau, der ist sogar in der Zeitung erschienen, auf Deutsch dann und auf deinem Blog.

Echt cool.

Darf man das sagen, Entwickler darf man da?

Ja, ich glaube, ja.

Schlichter 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 einer Dragon War-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 die Latenz nur so lange 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 kommen halt auch, 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.

Bestimmt, ja, genau.

Da hatten wir ja auch schon mal schon zwei Episoden dazu gemacht.

Ja, das ist halt.

Wir brauchen noch mehr.

Thema, da kann man immer nochmal drüber sprechen.

Thema einmal drin hat, dann muss man das auch ein bisschen ausschließen.

Ja, genauen.

Aber jetzt, genau, ist mir dann halt irgendwann, das war so Anfang des Jahres oder ich weiß nicht, dann dachte ich so, ach, wenn man jetzt schon so Async Awaitert hat, vielleicht ist er 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 ja, hat so ein bisschen gedauert und irgendwann aber dachte ich so, okay, das funktioniert tatsächlich.

Und ja, dann habe ich daraus halt einen, dann hat er Johannes erzählt, dass er dann irgendwas bei der DjangoCon EU eingereicht hat.

Und dann dachte ich, so das muss ich dann auch machen.

Den Talk eingereicht hat.

Der soziale Druck.

Genau.

Ja, und genau, das war dann auch Thema des Talks im Grunde.

Und es funktioniert auch tatsächlich.

Ich habe jetzt, ich habe dann 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 es.

Das ist ja schon deutlich sauberer und deutlich einfacher.

Wirst du das auch an Django schicken?

Ich mache dann einfach ein Sert-Party-Package draus.

Das wäre Prinzip 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 SGI-Händler, das ist so das Ding, was halt mit, was halt die Applikation ist, quasi die SGI-Applikation.

Das ist halt der SGI-Händler in Django.

Ach, den hast du einfach mal gemunke-patch, oder?

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

Lass mal vielleicht mal mit

jemandem drüber machst.

Ja, genau.

Da machst du halt den SC 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, muss man halt entweder get async File-Response-Händler oder so Application irgendwie importieren oder halt den Händler direkt und dann die Applikation selber instanzieren.

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.

Das ist halt, äh, da kann es schon sein, dass da einige Dinge nicht mehr funktionieren.

Ja, genau, dafür gibt es Tests, aber ja.

Ja, klingt auf jeden Fall ziemlich cool.

Das heißt, man kann jetzt einfach mit dem Dango-Applikationsserver seine Files direkt ausliefern.

Muss die nicht mehr irgendwie außen vom Web-Server quasi routen lassen, sondern kann direkt sagen, Django, hey, wir nehmen die doch mal direkt aus, du weißt nicht, was nutzt man da für Dango-Storages raus oder so und liefert 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, das war auch mein Ziel.

Ich habe es jetzt mit dem File-System gezeigt, aber File-System ist ja eigentlich so ein bisschen langweilig, weil.

Wie hostet man S3 selber?

Mino?

Mino, genau.

Weil man möchte eigentlich nicht, dass User selbst, also Content, Files, wo sie ein Content kontrollieren, in das gleiche Fallsystem nehmen kann, aus dem, in dem die Applikation läuft.

Das ist halt auch so ein bisschen gefährlich.

Und man hat dann das Synchronisationsproblem und kann man natürlich irgendwie so einen Samba-Share nehmen oder NFS oder was ist ich oder SF oder.

Geht alles, aber ist halt auch so ein bisschen Ancient-Relaying.

Ja, also die Standardgeschichte, wie man das selber hostet, momentan, also so ein Object-Store wie S3 oder so, ist halt wohl momentan Mino.

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

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 dem Talk einsetzen, da muss ich es doch für irgendwas anders benutzen.

Also falls ihr richtig könnt, 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önnte ihm ein bisschen beim Live-Programmieren mal zu gucken, dass es vielleicht ein bisschen was anderes ist als nur so zu theorisieren, sondern halt auch mal tatsächlich live zu sehen, wie Jochen das

denn so.

Ich mache der Vorsitzende und keine Ahnung, was ich dir eigentlich tue.

Genau, Jochen ist auch nur Mensch und macht den ganzen Fehler und so.

Und mir fällt, wenn ich davor sitze, ich möchte die ganze Zeit hier so einen Stock nehmen.

Ja, bitte.

Wünsche entgegen Jochen, kann man sich wünschen, was du programmierst.

Programmierst du nur, was dir Freude macht.

Ja, prinzipiell, kein Problem, ja, klar.

Vielleicht gegen eine kleine Spende kennst du vielleicht.

Ah, okay.

Requests annehmen.

Ja, genau.

Ja, also genau.

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

Immer wenn ich denke, hä, das hätte ich doch ganz anders gemacht, fällt Jochen dann eine halbe Stunde später auf.

Oh, jetzt kann man auch anders machen.

Ja, das, ja, aber ich meine, so ist das halt.

Also mir sind da auch schon tatsächlich live Dinge passiert.

Ich habe da live einen Bug in irgendeinem irgendeiner Library gefunden, sozusagen.

Und dann sitzt er dann.

Also ich habe dann 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, wenn man das rumsucht.

Also Jochen benutzt dafür übrigens NBD.

Da hatten wir auch schon mal eine Folge klein 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 so ein bisschen machen.

Ja, du musst das nämlich ja nochmal anders machen.

In VI und einmal in VS Code oder so.

Dann können wir schauen.

Vielleicht sogar in PyCharm, dass man so ein bisschen einmal teigt, wie das denn überall so geht.

Genau.

Genau, das habe ich auf jeden Fall auch vor.

Ja, genau.

Vielleicht kriegen wir das ja auch mit dem Podcast nochmal überhin da so ein bisschen vielleicht so ein bisschen Video.

Live-Schalten.

Ja, also müssen wir gucken, ob wir dafür Zuschauer bekommen, begeistern können.

Ja, cool.

Ja, ich glaube, es hat noch jemand hat halt tatsächlich einen Workshop, bei der dran gewonnen.

Ja, ich bin ja quasi schuld dran, dass der ja auch in 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 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's 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 hab's 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 Programmiereerfahrung.

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.

Ja.

Ist schon eine ganze Weile her, das war 2005.

Also ich habe jetzt tatsächlich 15 Jahre Django-Erfahrung.

15 wieder 15, das sind ja noch 2020?

Ja.

Wieso?

Ich habe den Wettbewerb eben nicht mehr dran, deswegen

habe ich doch mal Acht auf Wissen.

Wir müssen den jetzt jetzt einfach so lange wiederholen, wissen auch wirklich jeder.

Ein bisschen 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 so 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.

War, glaube ich, auch ein bisschen mehr für Einsteiger geeignet, glaube ich, den Talk, den du gemacht hast als das, was Jochen jetzt hast.

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

Wobei auch erfahrene Leute, ja, also ich wechsle da immer so hin und her.

Der Bereich, mit dem 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 wieder finde?

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 is, where all this is custom is.

Und es gibt Leute who are the Django Start Project.

And I wechsle da immer so ein bisschen hin und her.

Ich sehe die Vorteile von beidem.

And in the letzten yeah bin ich mehr so in Richtung Django Start Project gegangen.

Weil das schon eine gute Basis ist und weil das jeder machen kann.

And weil das jeder auch versteht.

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

Aber bei dem Projektverzeichnis sind ganz viele andere Sachen drin, mit 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 Start Project und für Start App.

Den kannte ich auch noch nicht.

Das fand ich auch sehr interessant.

Das wusste ich nicht und das ist voll nützliche Informationen, ja, echt sehr gut.

Ich habe da jetzt auch inzwischen das so eben zusammengefasst, dass man also mit StartProject slash slash 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 schön.

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, 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 es hat super gut funktioniert, ist auch, glaube ich, ganz gut angekommen.

Klingt spannend.

Müsst ihr euch auf jeden Fall mal angucken, ob es auch noch zehn Tagen ist.

Ja, genau, wir verlinken das auf jeden Fall.

Genau, und auf deiner Seite hast du.

Genau, oder

eben meine Aufnahme ist schon auf der Seite der, ja, das war so die sechste oder siebte Aufnahme, die ich gemacht habe.

Also die ist ganz okay.

Ja, das hatte ich auch ehrlich gesagt, damit hätte ich nicht gerechnet, wie oft man dann mit einer ein paar Mal aufgenommen und dann passiert irgendein Scheiß.

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

Oh, und dann habe ich gedacht, jetzt muss ich mich nochmal nochmal eine Stunde mich hinsetzen und nochmal das ganze Ding machen.

Aber zum Glück war es nur die Datei auf der SSD, auf der mobilen SSD, die ich fertig kopiert hatte.

Konnte ich dann tatsächlich noch retten.

Und da, oh, da war ich so.

Ja, ich hätte sonst, das wäre 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, dass es auch noch relativ viel technische Detailarbeit hinterher ist.

Ja, aber tatsächlich.

Es war erstaunlich viel mehr Vorbereitung, als ich gedacht hätte.

Genau.

Aber was ich sagen muss, also das war, also dann, da war Johannesvortrag auch echt einer der positiv herausstechendsten, also sowohl Video-Audioqualität war gut, während das aber.

Weil tatsächlich muss man leider sagen, also ich fand oft war das nicht so gut.

Ich hab dann, ich hatte jetzt 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 hab die dann halt auf dem Telefon laufen lassen, weil ja auch ich komme mich nicht von den Rechner setzen, muss halt Dinge passieren.

Und das ging auch ganz gut, aber zumindest, 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 sie kaum verstanden habe.

Und ich habe die Lautstärke auf dem Telefon komplett aufgedreht und trotzdem Schwierigkeiten gehabt, das richtig zu verstehen, weil es, und es ist vor allen Dingen auch anstrengend, selbst wenn man es verstehen kann, Audio zu hören, wo man immer so, das halt so schlecht ist, dass man es, dass man sich wirklich anstrengen muss, um es hören zu können.

Und da denke ich vielleicht auch manchmal, vielleicht sollte man, da gibt 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 für die Sprecher, damit die wissen, was auf sie zukommt.

Ja, 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 einen 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 löbliche Ausnahme, aber bei vielen war das nicht so richtig toll.

Das ist gut, was man kann.

Ja, das ist schade, dass das 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.

Und dann.

Nicht mehr ist doch völlig klar, dass ich hier damit beschrieben möchte, aber ja.

Was man eigentlich bräuchte, wären irgendwie so Sets, oder?

Die mal verschickt, wo eine gute Kamera dabei ist, ein gutes Mikrofon und die dann hinterher wieder zurückgeschickt werden.

Und irgendwie ein Tutorial, wie man das anschließt und wie man das, aber es ist halt dummerweise, es ist leider schwieriger als man so denkt.

Ja, eigentlich macht man alles mit so bunten Kabeln, die immer genau in die richtigen Stecker passen.

Also die Stecker sehen genauso aus wie klinken und dann steckt man es ein und auf einen Knopf dann läuft.

Ja, einfach nur ein USB-Anschluss.

Ja, cool.

Ja, was mich tatsächlich so ein bisschen, äh, 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, 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 ich bin echt

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

Oh ja, Gathertown ist großartig, ja.

Da kann man nicht rumlaufen mit einem kleinen Avatar und sich dann quasi live auf dem Konferenzgelände treppen mit so einem Pixel-Avatar.

Und dann 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 Dungeon Live in Gathertown.

Es hat einfach eine Räumlichkeit, ja.

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, weil alles public ist.

Ja, und außerdem manche Leute reden vielleicht dann gar nicht, weil irgendwer immer redet halt und

man sich nicht traut.

Und eine Gaza-Tompichenstellung und warten, wie man 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 er weiß, 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.

Und ja.

Jochan, was war denn der, 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 es ein bisschen langweilig, aber weil ja.

Da sprechen wir da nicht nochmal drüber.

Genau.

Ansonsten fand ich die, weil, also man muss auch unter, also ich meine, es gab halt halt mehrere Dimensionen sozusagen.

Es gab halt Talks, die mich halt irgendwie inhaltlich überrascht haben, irgendwie so wie der erste und ich auch gut fand.

Oder es gab halt 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 waren teilweise.

Hast du vielleicht noch eine Empfehlung von einem Talk, den man unbedingt gucken sollte, wenn den mal trocken ist?

Also einer meiner Lieblingstalks war auf jeden Fall der von Carlton Gibson mit Static Sites.

Static Sites 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 mal.

Ich habe da schon auch Dinge mitgemacht, für Dokumentation von Software verwenden soll.

Und dann, aber ja, und dann dieses, diese, diese Read the Docs-Geschichte, wie heißt das noch da?

Restructured Text, das ist eigentlich auch ganz nett, da kann man auch viele schöne Sachen, aber es ist meistens nicht so vielleicht unbedingt.

Hat 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, und das war mir auch völlig überhaupt gar nicht klar, dass die Django-Dokumentation das so macht, dass da nicht eine fertig gerendertes Start-HTML ist, sondern dass das dynamische Elemente hat und dass das halt, dass sozusagen die Art, wie der Dokumentations-Content in die Django-Dokumentations halt reinkommt, ist halt über JSON.

Das war mir überhaupt nicht klar und das ist eigentlich aber voll gut total absurd.

Das ist, und deswegen, also den Talk fand ich auch so auch technisch gut, also das Audio war super, Video

macht das auch total gut, der ist total entspannt und ein bisschen flapsig und kurz und ja, echt cool.

Carlton Gibson Static Pages, ja.

Genau.

Carlton Gibson ist generell so einer, der in der Community ganz viel, ganz viel macht er ist.

Einer von den Django Fellows.

Der macht die ganze Drecksarbeit.

Er bezeichnet sich selbst als Janitor.

Django's Janitor.

Und der ist schon jahrelang in der Community drin und der ist großartig.

Also ich kann ich jedem empfehlen.

Oh, er macht ja auch einen Podcast mit Will Winston zusammen, Django Chat.

Ach, das ist auch ein bisschen.

Hatte ich kürzlich im Auto die Zeit, acht Episoden anzuhören.

Also auch das muss man die Konkurrenz einmal hier hervorheben.

Du hast ja demnächst öfter mal Zeit wieder für die Podcasts mit 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 Consolen, ist Rewriting Django from Scratch in 2021 von Emma Delescore, die sich die Frage gestellt hat, wenn wir keinen 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 gerade so.

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 dem Ex 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 hatte ich, das habe ich, 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 halt eigentlich der Vorteil von Django, jetzt gegenüber zum Beispiel sowas wie Flask oder so, oh, da 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 darum gekümmert haben.

Vielleicht nicht alle Funktionen und nicht so nicht so im Detail ausgefeilt, aber dafür halt irgendwie stimmig.

Integriert.

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 du hast dann trotzdem die Möglichkeit, einen Baukasten zu haben.

Hast du 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 Contra-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.

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 es möglich wäre, ja?

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, das ich über Sendgrid verschicke?

Ja, ich dachte.

Pip Install Django Sendgrid machen und dann ist das komplett da.

Diese Frage 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, ich, in den Settings sage ich halt, ja, du bist jetzt für.

Ich stelle mir mehrere Pakete und dann stelle ich es in den Settings ein, welches benutzt werden.

Genau.

Aber stimmt, also dass man den Code da nicht mit drin haben muss, das ist natürlich schon so ein Punkt, ja.

Ah, das, ähm, das, äh, das ist aber auch noch ein 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 Janis Leidel, der Jazzband Talk.

Ja, habe ich gehört.

Was ist noch live während des Talks Jazzband beigetreten?

Ah, okay, genau.

Ich habe es mir überlegt, ich hab's noch nicht getan, aber ich habe stark daran gedacht, das zu tun.

Und genau, ich hatte das immer nur gesehen.

Ja, ich hatte das immer nur gesehen bisher, als das ist irgendwie eine Organisation, in der viele der im Django-Kosmos irgendwie befindlichen Pakete halt so auch mit drin sind und was da gemained hat wird, irgendwie sowas Django-Filter und weiß ich nicht, ganz, ganz viel Zeug.

Storages und Comments, 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 hatte, selber zu mainten, dann kann man das vielleicht dahin das losreten.

Irgendwie, weiß ich nicht, irgendwie ein Schleifchen dranbinden 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 hatte so ein bisschen die Anforderungen an Projekte, aber sie sind auch relativ leicht zu erfüllen und dann kann man quasi Projekte davon maintain 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 Chor-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 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 rein committen.

Du kannst halt einfach dann, es funktioniert halt.

Und dann muss halt, es gibt halt nur weniger Release.

Ja, kann beitreten.

Ja, kann beitreten und erst beim Release wird dann halt geguckt, okay, macht das dann irgendwie Sinn oder ist das irgendwie Quatsch?

Und das passiert halt deutlich seltener.

So dass du halt diese Hürde, dass du halt normal, das ist tatsächlich eine Hürde, das habe ich mir auch schon oft gedacht.

Muss ich das jetzt wirklich

stellen, dann hörst du acht Wochen lang nichts und dann frage, ja, hier ist was und dann weißt du schon alles gar nicht mehr.

Oder er geht ganz unter.

Ja, und was ich dann oft mache, ist, dann fork ich es doch mal schnell selber, fixe das da und dann.

Kurz meine eigene Version gemacht.

Dann vielleicht mache ich doch tatsächlich nochmal Pull-Requests, aber eigentlich auch egal.

Und tatsächlich habe ich das auch ein paar Projekten gemacht, die in Justment drin sind und dann hätte ich dann so, okay, eigentlich hätte ich die direkt fixen können.

Und dann wäre diese ganze, ja, hätte man diese ganzen Tanz um GitHub-Pull-Request-Issue gar nicht machen müssen, sondern hätte jetzt einfach gefixt-committet und fertig.

Was heißt bei Django?

Bitte?

Django Filter.

Ja, ganz viele von diesen Sachen, die man kennt.

Ich glaube auch Django Extensions und Debug-Toolbar sind inzwischen Jazzband-Praktik.

Oh, apropos

Debug-Toolbar, da glaubst du ja auch, was für ist.

Der Jazzband, weil das irgendwie sozusagen, ja, Django ist ja auch vom Namen her wird das zurückerführt auf eben Django Reinhardt.

Ach so.

Daher kommt das.

Cooler Name, finde ich.

Ja, also unter Django Extensions hast du noch irgendwas für das geteilt, Johannes.

Und zwar hast du da was entdeckt, das heißt die Colo-App heißt, was auch für Debug für Django relativ nützlich sein soll.

Da musst du mir auf die Sprünge helfen, Dominik, weiß gar nicht, was du meinst gerade.

Du hast halt so schon link geteilt.

Beim Colo-App, das ist eine Django-Applikation zum Debuggen.

Vor allen Dingen auch in VS Code sehr nützlich.

Du kannst halt so den Source-Street anschauen und.

Ja, genau, das hat mich jetzt gar nicht so richtig, äh, hat mir gar nicht so richtig geholfen, weil ich fürs Code Code Code 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, Request, Response, die Queries und so.

Genau, und auch mit Profiling drin und wenn Fehler auftreten, kommst du gleich an die Richtung.

Genau, man kann es aber den Executed Code Path visualisieren und so.

Es ist ein richtig, richtig ausgefeilter Debugger, geht allerdings nur in Visual Studio Code.

Also Salary Task kann man dann 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, bist du?

Ich bin sehr charming, ja.

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 es schon mal erwähnt, Jochen.

Ja.

Du hattest HTMX schon mal gesagt.

HTMX 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 Listeneinträ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 HTMX 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 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 so diesen einfachen Mitteln hinkriegen kann.

Also das, wo man früher jQuery verwendet hat, ja, Button.Click und dann Dollar Ajax machen, ist jetzt einfach in so ein 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, ja, 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, ja.

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 etwas interaktivere oder so modernere, so Single Page-Apple-mäßige Applikationen mit Django, weil wohl auch der Druck größer wird irgendwie von da außen.

Und vielleicht kann man aber, muss man dafür nicht jetzt irgendwie das, also es gibt einen Weg, den halt auch viele Leute beschreiten, der ist halt, naja, du machst halt Django Rest Framework oder halt GraphQL irgendwie Graffiti.

Ganz auch einen Talk dazu.

Ja.

Und machst halt deine Applikationen im Frontend halt quasi als, weiß ich nicht, ReactView, Angular.

Und Headless.

Und Headless, genau.

Und dein Backend ist sozusagen dein Django ist halt nur noch das Backend und macht halt, rennt halt nur noch JSON raus und sonst nichts.

Das ist eine mögliche Sache.

Ist aber eigentlich irgendwie traurig, was?

Ist irgendwie traurig, weil man die ganzen guten Teile halt.

Ja, es gibt halt schöne Teile von Django, die Formulare, ja, Form-Validation 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, also man verliert halt viele Dinge, die halt bei Django eigentlich total nützlich machen.

Und die muss man dann selber machen.

Und dann, wenn man das dann macht in JavaScript, stellt man oft fest,

ja, man schreibt sich halt die langweiligen Teile von Django, schreibt man sich dann in

JavaScript nochmal nach.

Genau, und das ist halt.

Und man hat dann immer noch eine andere Programmiersprache, die man halt auch noch, mit der man dann auch kämpfen muss.

Und das ist halt, ja, und dagegen.

In JavaScript muss man doch machen.

Deswegen nimmt man ja TypeScriptsprache.

Ja, also es ist besser geworden, sagen wir mal so.

Aber ehrlich gesagt, wirst du Python immer noch lieber auch die ganzen Sachen.

Ja, ja, durchaus.

Und eben als 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 und Rails, macht das ja auch, dass man halt sozusagen, oder Elixir, Phoenix, man rendert halt HTML auf der Serverseite und hat nur noch wenig JavaScript auf der Client-Seite, was halt dann irgendwie die Seite updatet.

Und tatsächlich fällt für mich HTMX halt auch in diese Klasse von Dingen rein.

Oder sagen wir so, also jQuery scheint jetzt wohl dann so endgültig irgendwie tot zu sein.

Ja, das ist ja mit ECMAScript 6 sind ja die meisten Sachen, für die man früher jQuery benutzt hat, einfach direkt in Vanilla.js drin und dann.

Genau, genau.

Und es gibt dann im Grunde, entweder verwendet man halt, wenn man noch mehr JavaScript machen möchte, dann sowas wie Alpine.js oder so, oder halt eben HTMX, wenn man nichts Kompliziertes macht oder obwohl da auch schon einige interessante Sachen gehen.

Und ich habe jetzt letztens auch eine Podcast-Episode gehört mit dem Autor 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 das das Ding HTMX nennt, heißt es kein Zufall.

Das ist tatsächlich, meinte er, 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, hatte irgendwie das Gefühl, das müsste ja eigentlich ein HTML oder so drin sein.

Und das bricht ja auch mit diesem ganzen REST-Ding.

Und er hat halt wohl auch die Dissertation von Roy Feeling da gelesen.

Und er meinte 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 hat, dass das JavaScript dafür nicht schreiben muss.

Also ich erweitere sozusagen HTML so, wie das eigentlich gehören würde, wenn es Browser-Supporter dafür gäbe und das mache ich dann halt in JavaScript.

Und das Ding nannte er irgendwie Intercooler.js.

Und das war am Anfang noch so ein bisschen krud und sehr JackQuery-mäßig.

Und das mal davon gehört.

Ja.

Ist aber irgendwie, er meinte ja so, naja, der Name ist halt schlecht, weil das JS hinten dran, das vermittelt so den Eindruck, es 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.

Wie nennen wir diesen Podcast?

Naja, gucken wir mal, Python ohne Python, dann immer es halt so.

Da hat er so, ja, eigentlich möchte ich HTML, aber erweitert, extended, HTMX, okay, HTMX, Org noch Frei.

Oh, super.

Und dann hieß das Ding halt HTMX.

Und die Idee ist.

Buchstaben Org-Domains 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 sozusagen Nachfolger von Intercooler Jazz.

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 Application State Dings und so quasi die Prinzipienbeibau halten möchte, die halt auch in dieser Dissertation von Roy Feeding drin sind.

Also ja, also das Hauptproblem, was nicht gut ist und weshalb alle irgendwie JavaScript zusätzlich machen, ist, dass sobald du irgendwas änderst in diesem alten Modell, hast du, musst du deinen kompletten DOM neu aufbauen, also ein Request-Response-Seite.

Du musst einen kompletten Page-Reload machen.

Und das ist halt etwas, was nicht gut funktioniert, weil das ist halt für, 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, irgendwie alles, das fühlt sich dann einfach nicht mehr flüssig an und das ist halt ja, aber mit Ajax und so konnte man ja da immer schon so ein bisschen was machen, so Web 2.0-mäßig.

Und aber das ist halt eben dann eben, und 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-Set ist jetzt halt im Frontend und Backend ist halt nur, liefert halt Daten, aber oder vielleicht so ein bisschen Sate, aber das ist eigentlich.

Du hast halt dieses Synchronisationsproblem, aber die eigentliche Applikation läuft halt im Browser.

Und er hat, 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 ein Post auslösen kann?

Warum kann das nur ein 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 führt 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 dann halt HTMX 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 zwischenschrift.

Und das ist eigentlich ein sehr, sehr interessanter Gedanke.

Also fand ich auch sehr gut.

Ja, und es

kam einfach so häufig vor.

Ja, also man merkt, man merkt sich.

Also es scheint irgendwie jetzt 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.

Na 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 zufällig in so einer VM laufen, die Browser und JavaScript heißt.

Und die aber im Wesentlichen ja selbstständig sind.

Und es geht ja bei vielen Sachen auch total gut, ja, 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, also klar, wenn man braucht

ja überhaupt gar keinen Anwendungen.

Ja, wenn man tatsächlich keine

Grille, dass das Internet da ist.

Ja, wenn man so eine Applikation hat, die selber sehr viel macht und die ab und zu 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.

Auch so tatsächlich die.

Genau, deshalb meine ich das ja.

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, ja, aber es eigentlich gar nicht nötig haben.

Und so diese Brücke dazwischen zu schaffen, ist, glaube ich, das ist eben das, weshalb es im Zeitgeist ist ja, dass man jetzt eben von den ganz statischen Webseiten sind wir ja schon lange weg oder sind wir ja schon 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 Internet-Requests 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 den Zwischenschritt zu gehen, dass du eigentlich eine, dass du 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, ja, 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, ja, in die Mitte ist richtig.

Smash-Gleichgewicht ist immer in der Mitte.

Na, wie heißt es bei Alexander Kluge, glaube ich?

In Gefahr und großer Not bringt der Mittelweg den Tod.

Ja, aber in der Mitte der Herde zu sein, ist der sicherste Ort, deshalb ist es.

Genau.

Das fällt mir auch eben zu der letzten Rest-Episode, da gab es dann auch eine Erwähnung im Potlovers-Podcast, wo es um die Entwicklung von so einer Podcast-Plattform geht im Grunde, basierend auf WordPress und so ein Plugin.

Und da wurde durchaus wahrgenommen, dass wir irgendwie über XML gelässert haben.

Sowas.

Sowas.

Habt ihr euch.

Ja, äh.

Wäre gerügt worden.

Ja.

Nee, aber 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, also was mir, ich war jetzt gar nicht so wahnsinnig da mit drin.

Also was mir persönlich gefehlt hat, war halt irgendwie der Kontakt mit den anderen Leuten, aber das ging halt einfach nicht.

Da kann man jetzt

keinen Vorwurf machen, dass du keinen Karte machen.

Ja, aber das ist halt der Grund, wo man eigentlich das.

Ja, also ich würde auch sagen, eigentlich, wenn man vor Ort sein könnte, ich wäre auch gerne mal nach Porto gefahren, wo das hätte eigentlich stattfinden sollen.

Ja, das ist

auf jeden Fall eine ganz andere Atmosphäre, ne?

Als wenn man da die ganze Zeit doch noch wieder vor demselben Deck macht.

Und auch mehr Fokus einfach.

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

Ob du es nicht genossen hättest, wenn du auch mal ausnahmsweise ohne die Familie und ohne die Kinder irgendwie frei im Ort, oder wie?

Klar, hätte ich auch genossen, wäre aber einfach schwieriger gewesen, das zu machen.

Ich glaube, ich glaube, in Zukunft wäre das sehr schön, wenn solche Konferenzen so ein Hybridmodell hätten.

Dass man da sein kann, aber dass man auch online sein kann.

Okay, finde ich ehrlich gesagt ein bisschen anstrengend.

Ja, mag sein, aber es sind einfach unterschiedliche Zielgruppen.

Und es gibt ganz viele Leute, die können nicht reisen oder die wollen nicht reisen oder die haben das sehr schwer zu reisen und machen es deshalb entsprechend selten.

Und ich glaube, Online-Konferenzen ist was, was bleiben wird.

Und dann müsste man irgendwas.

Ich habe da auch ganz eigene Ideen.

Ich finde es ganz cool, dass es Online-Konferenzen 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, ja.

Du kannst nicht bei allen Talks dabei sein, aber du kannst halt bei denen dabei sein, wo du dabei sein kannst und fertig.

Aber das ist mehr Umbruch als Django-Stat.

Also ich finde,

das hat auch ein bisschen was Familiäres, wenn man da hingehen kann, kann die Leute wirklich treffen, irgendwie, je kleiner das ist, desto familiärer ist das.

Und je größer es wird, desto anonymer wird das.

Und das Problem, was wir ja gerade schon beschrieben, an diesen Online-Talks ist halt vor allen Dingen dieses Frontalunterrichtsthema, dass irgendwie alle Leute einem 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 hast du sowas wie Gather Town so ein bisschen reproduzierbar, aber ist halt auch 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, was mir 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.

Also ich kann es jedem nur empfehlen, ja, 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 baue ich mein Baumhaus, das hat ihnen noch gefehlt.

Genau, also ich habe einfach in Heidelberg hat einer 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 von der DjangoCon 2019.

Oder 2018 war es, ich weiß nicht mehr.

Einfach weil es sowas 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 hinaus ging.

Weil es war schon sehr fokussiert auf Django, was ja okay ist, aber bei den Lightningstalks darf man durchaus, finde ich, auch so ein bisschen über die Stränge schlagen.

Und das hätte ich mir mehr gewünscht.

Ja.

Es ist keine Kritik an jetzt irgendjemandem, sondern es ist eher Kritik an jemanden, der nicht dabei war.

Schämt euch was, ihr hättet dabei sein sollen und hätte 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, ich bin da schon.

Bin schon adapt.

Ja, ansonsten was.

Ja, ja, stimmt.

Also das hat mir auch gewundert, dass ich die Lightning Talks war, oh, schon vorbei, hupsala.

Ja, waren zu wenige und waren auch nicht divers genug, sagen wir es mal so.

Ja, ansonsten so große Themen.

Wir hatten jetzt so, genau, dieses ganze HTMX, genau, das war, das war auf jeden Fall ein großes Thema, da gab es viele Talks zu.

Viele Talks gab es halt auch zu Datenbankgeschichten.

Das fand ich auch voll gut.

Also da waren auch einige super gut.

Der von Haki Benita, großartig.

Ja, Markus Holtermann,

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 irgendwie vielleicht nicht so verträgt, wenn man da mal.

Das auch, fand ich auch sehr gut.

Ich meine, klar, betrifft mich.

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 dass das geht, war mir schon klar und ich habe das auch ab und zu mal, aber was man da alles machen kann, das war mir jetzt gar nicht so präsent und das war auch super.

Und das SQL ja eigentlich auch eine sehr interessante Geschichte, dass man viel in SQL machen kann.

Kann man eine eigene Episode machen drüber.

Ja, ja, ja, ja.

Und Postgres wird immer besser.

Ja, Postgres wird so langsam zur Eier liegen, dann wollen wir das kann alles.

Ja, das war auf jeden Fall auch ein großes Thema.

Ja, dann, was hatten wir denn noch an größeren, dann GraphQL war halt auch ein großes Thema, aber auch vor allen Dingen in Kombination.

Ein Talk gab es, fand ich, äh, im Zusammenhang mit Domain-Driven Design.

Und genau, das ist sehr gut.

Genau, aber da war auch, das muss ich sagen.

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 hast, ach da, der ist ja in der Aufzeichnung.

Genau, wie macht man das eigentlich, wenn man jetzt wenn man jetzt irgendwie Business-Logik hat, wo packt man die denn jetzt in Django eigentlich hin?

Wenn doch viele sagen, was gar nicht so gut ist, das in die Models zu packen.

Server, Helpers, Services, Helpers, UD.

Jochen, da haben wir doch, haben

wir doch schon drüber gesprochen.

Wenn du das in die Models packst, das ist überhaupt nicht solid.

Die sind überhaupt nicht mehr Single Responsibility, die sind überhaupt nicht mehr ersetzbar, die sind überhaupt nicht mehr Buchstabe

von Solid ist direkt.

Ist direkt verletzt.

Aber ja, das Problem ist halt, andererseits auch irgendwie nicht, weil das andererseits ist.

Es ist halt auch schon sehr praktisch, das ist auch richtig.

Aber da, auf jeden Fall, mich, ich kam darauf, weil sich auch, glaube ich, eben in dieser Domain-Droven Design Plus GraphQL-Geschichte hat, hat sich auch, oder vielleicht war es ein anderes, vielleicht kriege ich es immer so richtig zusammen.

Talk, hat sich auch jemand 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 hat man da etwas, macht man da etwas, was man eigentlich nicht tun sollte.

Und ja, aber anders geht es irgendwie auch nicht gut.

Ja, ja, das ist einfach so eine ungelöste Frage.

Da ist auf jeden Fall irgendwie noch eine Baustelle und ich fand, man hat diesmal auch gemerkt, dass sie irgendeine ordentlichen 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 konnte.

Graphie statt einer Modusfy einkunden.

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 eine ganz große Klasse.

Und es gab quasi nichts, wo ich irgendwie eine negative Erfahrung machte.

Es gab nichts, wo jemand ausgelacht wurde oder wo ein unangenehmer Witz gemacht wurde oder wo irgendwas negativ betrachtet wurde.

Sondern es ist alles großartig und positiv.

Und das ist großartig, ja.

Das ist super für so eine Community und ich bin ja echt froh und dankbar, Teil so einer Community zu sein und jetzt nicht irgendwo so an so einer giftigen Community festzustecken, die alle fertig machen.

Also es ist wirklich großartig.

Und auch, dass es geschafft wurde, dass viele Frauen dabei sind, ja.

Auch vielleicht nicht-binäre, die waren jetzt, die standen jetzt hier nicht irgendwo im Vordergrund oder so, aber das wäre überhaupt gar kein Thema gewesen, ja.

Das wäre überhaupt gar kein Thema gewesen.

Großartig, ja.

Großartige Community, sehr inklusiv, sehr, sehr positiv.

Aber auch an manchen Stellen einfach ein bisschen zu positiv.

Du hast zu wenig über die schlechte Bildqualität, wo man geredet erstmal.

Ja, das meine ich gar nicht, sondern 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, ja, okay.

Die halt tun müssen, ja, weil sie nicht anders können.

Aber warum haben wir, warum haben wir denn nicht so viel Innovation in der Djungo 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, ja, mit diesen HTMX und mit den Full Stack without writing JavaScript.

Aber das sind immer nur Sachen, die, wir zeigen jetzt mal eine Lösung, die jemand gemacht hat.

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, ja, es ist schwer, das in Worte zu fassen, ohne zu negativ.

Das ist einfach so gut, dass man einfach den Need nicht hat, sich so schnell in eine andere Richtung zu verändern.

Ja, vielleicht.

Ja, aber das ist ja so ein lokales Maximum, ja.

Vielleicht ist das ja so.

Vielleicht ist ja Django so ein lokales Maximum, wo es eben sehr schwer ist, sich rauszuoptimieren, weil jeder Schritt nach draußen erstmal einen Schritt nach unten ist.

Und vielleicht ist es das, aber ich würde es mir halt wünschen, ja.

Ich habe bei den in den in der Rails-Welt total coole Sachen gesehen.

Hotwire kommt, glaube ich, aus der Rails-Welt.

Es wurde mehrmals darauf verwiesen, wie Rails das macht, während Konferenz-Talks.

Und das ist schade, weil Django sollte der Vorreiter sein.

Django ist nicht der Vorreiter.

Django ist die beste Lösung, aber nicht der Vorreiter.

Es ist Dango damit natürlich auch so ein bisschen wie Python selber, ne?

Irgendwie so das zweitbeste Framework.

Und es ist der absolut beste Platz, wo man sein kann, der zweitbeste zu sein, weil der erste wird immer angegriffen und zerlegt.

Der zweitbeste, der helfen.

Mach doch mal Johannes, sei doch mal innovativ.

Bring doch mal was Neues raus.

Ja, ich versuch's ja.

Ich versuch's ja, aber es erstmal muss ich Geld verdienen.

Da kommt wieder her, der Greet und so.

Ja, ja, ja.

Diese Sache mit Anvil Journal, die ist ja großartig.

Anvil ist ja ganz verrückte, abgefahrene Sache.

Was ist Anvil, ein Schmiedeamboss für.

Ja, das ist quasi JavaScript aus Python raus.

Also die haben einen Python-Compiler für JavaScript, der JavaScript erzeugt.

Das heißt, du kannst dein System komplett in Python schreiben und hast dann aber trotzdem hinterher eine JavaScript-Webseite.

Großartig, großartige Idee.

Funktioniert auch, ja.

Kann man sich, kann man jetzt schon benutzen.

Er hat auch eine Live-Demo gemacht, die dann sofort live war.

Auch sehr großartig.

Weiß nicht, ob das Ding noch live ist, müsste man mal gucken.

Aber ja, aber es geht auch, das ist dann schon nicht mehr Django, ja.

Envil ist, glaube ich, relativ wenig Django.

Ja, ja, ja.

Genau, ja.

Aber vielleicht ist das ja genau das Indiz dafür, dass das aus dem lokalen Maximum daraus.

Ich glaube auch, es ist einfach schwer, du kannst auch Django nicht mehr so leicht verändern.

Du kannst halt nicht einfach sagen, wir bauen ja Django so um, dass es sowas wie Envil ist.

Ja, das würde halt.

Das ist einfach so viel Arbeit, das kannst du.

Ja, das wäre möglicherweise ein Grund, das zu tun.

Wenn man sagt, also ich meine, es fängt ja schon bei sowas an wie Django Admin, haben ja auch schon viele Leute gesagt, es wäre doch auch cooler, wenn das irgendwie so ein bisschen reaktiver wäre und wenn man da irgendwie so ein paar Modellen.

Es geht halt nicht.

Oder weil man seine Angemacht

besser integrieren könnte.

Ja, aber es wird halt auch da wird dann immer gesagt, so ja, Django Admin neu schreiben, vergiss es einfach, das kriegst du nicht mehr hin.

Das ist nicht zu machen.

Ja, oder es ist halt nicht, es ist halt das lokale Maximum, ja.

Du kannst einen Django Admin schon neu schreiben, aber der wird erstmal eine ganze Weile lang sehr viel schlechter sein als der Django Admin, den du jetzt hast.

Und dann ist die Motivation schon so ein bisschen so, ach ja, ne, dann nehme ich halt den Django Admin.

Und das vielleicht, ja, vielleicht ist das der richtige Weg, das zu modularisieren.

Ja, ich meine, auf der anderen Seite, ich würde da sagen, Flask, um da nochmal, weil da gab es nicht noch News zu.

Das ist ja der andere Ansatz.

Das ist ja sozusagen,

da gibt es keine.

Alles ist modular und du bastelst dir das halt selber zusammen.

Und es gibt auch keine Standardmodule, sondern du musst dir selber Standardmodule suchen.

Da gab es jetzt eine neue Release, Flask 2.0 und ich hatte ja aber so irgendwie Kess behauptet, ah, das wird nie irgendwie, weil ich hatte das noch so in Erinnerung, dass da ja auch mal sehr, sehr stark geachtet wurde auf Abwärtskompatibilität und möglichst, also gerade, na, wie heißt du noch Dings da?

Armin Roter, der missfällt das ja total, dass irgendwie, der hat ja am liebsten Abwärtskompatibilität bis, weiß ich nicht, eigentlich bis ganz weit bis Jahrzehnte zurück.

Was ich ja auch verstehen kann, in gewisser Weise natürlich ist es.

Ja, ja, hat auch Vorteile.

Aber auf der anderen Seite würde das eben bedeuten, ja, sowas wie Async Await, das wird dann halt nie gehen, weil das oder und Flask ist halt auch direkt, setzt halt, ist eines der ersten Frames, das direkt auf WSGI aufsetzt, was halt ein Problem ist, weil, naja, das ist halt nicht Async und das kriegst du auch nicht dazu.

Und Django hat es da sogar ein bisschen einfacher, weil Django ist nämlich älter als WSGI und WSGI ist schon irgendwie da so dran gebastelt und jetzt kann man da halt auch noch was anderes ranbasteln.

Man hat auf jeden Fall eine schneller, an den man was ranbasteln kann, die bei Flask so nicht da ist.

Deswegen dachte ich so, naja, also das Flask Async-fähig wird das wird nicht passieren.

Aber es ist tatsächlich passiert, jetzt mit 2.0 geht das.

Und sie haben auch eine Menge eben, sie sind, haben halt die Abwärtskompatibilität beendet, jedenfalls aufgegeben.

Leichtfertig aufgegeben.

Okay, aber in einer Major, in einer Major Release natürlich machen.

Dann hätten sie es, geschickterweise hätten sie es Flask 3 nennen müssen, weil das ist doch das, wo in Python immer die Frage.

Genau, das braucht jetzt mindestens Python 3-6 und genau, man hat jetzt auch Async-Geschichten da drin und SGI.

Und es gab da immer so ein Ding dafür, Quart, das gibt es auch immer noch.

Das ist, ja, da hatte ich das übrigens auch her, die Idee aus einer Podcast-Episode mit dem jetzigen Mantener von Flask, dass man doch, weil der sagte so, ja, Async, wozu braucht man das denn?

Das ist doch irgendwie in der Flask-Welt machen wir das schon seit jeher mit Eventlets und Gvent.

So, okay.

Und das geht.

Und das geht.

Und dann habe ich es probiert und ja, es geht tatsächlich, und das kann man machen.

Und das ist halt möglicherweise auch tatsächlich eine einfachere Lösung für dieses File-Surve-Problem, einfach einen G-Event-Worker mitnimmt und der dann halt die Standardbibliothek monkey-patcht und alle synchronen I.O.-Calls ersetzt durch Nicht-Blockierende und das funktioniert dann einfach magisch.

Über Monkey Patching.

Ja, über Monkey-Patching.

Ist halt so ein bisschen gefährlich, aber wenn das nur für die Worker macht, die die Files ausliefern, ist es vielleicht auch nicht so schlimm.

Ah, okay.

Ja, aber und was ich auch jetzt, was man da auch machen kann, ist, man kann beides gleichzeitig machen.

Man macht halt G-Event irgendwie auf dem Main-Shread und packt halt, und das macht Django ja auch, und zwar auch aus dem Grund, um G-Event und Eventlets nicht zu brechen, den ganzen, lässt die Event-Group in einem anderen Thread laufen.

Und dann alles, was ISINCA WAIT macht, läuft dann halt in einem anderen Thread und trotzdem funktioniert diese ganze Event-Lead-G-Event-Geschichte weiterhin.

Also interessant, wusste ich alles gar nicht, aber auf der anderen Seite sagt die auch ja, also tatsächlich, um kompatibel zu sein zu moderneren Bibliotheken und so, wo man Await-Syntax, I think Awaitable-Syntax verwenden muss, dann, weil die nur noch das können.

Ja, bleibt uns wohl auch nichts anderes übrig, müssen wir das auch irgendwie können.

Weil du kannst halt in einem synchronen Funktionsaufruf nicht irgendwas erwaiten.

Das geht einfach nicht.

Ja, und deswegen ist es auch eine Flask jetzt drin und ja, das wird, also Flask immer noch weiterentwickelt voll gut.

Ich weiß nicht so recht, ich habe mit dieser ganzen Welt nicht so wahnsinnig viel zu tun, weil ich jetzt ehrlich gesagt auch keine Flask-Projekte oder sowas habe oder Dinge, wo ich was drin schreibe.

Ich benutze dann immer, ich habe noch ein paar Sachen, die Fast API sind und das finde ich auch sehr nett und ich glaube, das ist ja so ähnlich wie Flask quasi.

Also auch in der Hinsicht, dass es halt nicht dir vorgibt, was, also es ist halt nicht integriert, sondern es bringt gar nichts mit, sondern du musst alles dann halt selber konfigurieren und zusammenstecken.

Ja.

Aber es ist halt, war halt nativ direkt ASIC und macht alles über Type und Annotation und so.

Ja, insofern.

Aber ja, es ist schön, dass das Pflaster halt auch jetzt einen neuen Release hat.

Ja, sehr cool.

Wenn wir schon bei den ganzen Webperamic sind, liebt Pyramid eigentlich noch?

Ja, da gab es ja auch, weiß nicht, ist jetzt ein paar Monate her, glaube ich, aber gab es auch einen neuen Release.

Ja.

Habe ich allerdings auch nichts mit zu tun, keine Ahnung, kann ich nichts mehr drüber erzählen.

Aber in unserem bekannten Kreis gibt es Leute, die das ganz stark.

In der Pi DDF.

Ach, ja, ja, ja, klar.

Kommt immer wieder.

Kommt immer wieder was auf.

Ja.

Ja, genau.

Ja, ich finde, dann haben wir einen kleinen Überblick über die Django Kung tatsächlich jetzt gegeben.

Guckt euch doch die ganzen Videos an, wenn sie alle draußen sind.

Das ist bestimmt nochmal interessant.

Also ich habe auch noch eine gesagt, sobald sie da sind.

Ja, mache ich auf jeden Fall.

Haben wir noch was vergessen?

Habt ihr noch was dazu?

Wollen wir noch Picks machen?

Oh ja, können wir machen.

Johannes, was ist dein Pick dieses Mal?

Ich habe diesmal keinen Pick mitgebracht.

Na gut.

Doch, doch, ich habe einen Pick.

DevDogs.

DevDogs.

Ah, ja, ach so.

Tja, die hatten wir leider schon in der letzten Episode.

Hattet ihr schon?

Okay, gut.

Dann wiederhole ich das, dann bekräftige ich das.

Jeder sollte sich das sofort auf seinen Rechner runterladen und für alles benutzen.

Ich fand es ja sehr schön.

Ich habe das jetzt kürzlich gefunden und habe dann natürlich direkt alle Dokumentationen runtergeladen, die es runterzeichnet.

Vielleicht, weil du unseren Podcast gehört hast.

Habe ich es nachgeholt quasi.

Was mich sehr belustigt hat, war, ich habe diese Dokumentation runtergeladen in den Offline-Modus und die Django-Dokumentation sind, glaube ich, 6 Megabyte und die Python-Dokumentation sind etwas über 9 MB.

Und die Dokumentation für die DOM sind 64 MB.

Also 6,5 Django, 6,5 Pythons muss man komplett kennen, um die DOM benutzen zu dürfen.

Fand ich erschreckend.

Erschreckend, schräg, schrickbelüstend.

Ja, okay.

Ja, also damit ihr nochmal wisst, was das ist, man kann sich halt tatsächlich auf einer einzigen Seite die Dokumentation von verschiedensten Frameworks und Sprachen irgendwie auf seine Favorites legen und hat dann direkt einen Zugriff auf die Unterbuch.

Und auch offline.

Also gut.

Jochen, was deine

Tipps der Folge.

Was ich tatsächlich sehr schick fand, habe ich jetzt, meine ich, auch AIOSQL, ist so eine ganz eigene Art, wie man jetzt nochmal, also das, ich dachte dran, musste dran denken, ich weiß nicht mehr, wie ich drauf gekommen bin, als ich den Talk zu RAW, SQL und Django gehört hatte und dachte so, ja, also man kann, man kann halt auch sich so als alternatives Konzept zu den klassischen ORMs, die man so hat, einfach alles über Statements

definieren und dann diese Statements halt so ein bisschen parametrisierbar machen.

Und das ist halt, was auch alles A-Sync und so und das ist auch eine sehr nette Geschichte, kann man sich mal angucken.

Also GL-Stats aus Python.

Ja, ein ganz, ganz anderer Ansatz als der ORM-Ansatz, den man so kennt, aber auch irgendwie interessant.

Und ja, eine Geschichte, das fand ich sehr verwunderlich.

Ich dachte jetzt eigentlich, ich fange jetzt mal mit so einem Stream an.

Ich habe ja auch nirgendwo gesagt, dass ich das tue oder so.

Außer euch jetzt.

In dem Twitch-Stream waren eigentlich relativ sofort irgendwie Leute drin und ja, da muss ich mich auch erstmal dran gewöhnen.

Und da hat jemand gesagt, als ich da irgendwie mit Git die ganze Zeit so rumgemurxt habe auf der Command-Zeile, nimm doch einfach Tick.

So, das gebe ich jetzt einfach mal so weiter.

Ich habe es noch nicht benutzt, ich weiß gar nicht, ob das gut ist, aber das ist wohl ein End-Curses-Client für Git, der vielleicht ein bisschen besser ist.

Aha, interessant.

Muss man sich mal angucken.

Ja, ich habe auch noch einen kleinen Pick, ich würde diesmal eine Business-Anwendung nehmen.

Und zwar Lifetimes, das gibt es auf PiPy.

Und wenn man da quasi Bestelldaten von Kunden reinpipt, dann bekommt man quasi die Absprungrate, die Turnrate ausgerechnet.

Und das ist tatsächlich gar nicht so schlecht, wenn man so Sales machen möchte oder so.

Die habe ich da entdeckt und fand ich gut.

Funktioniert echt gut für gute Businesses.

Kann man wahrscheinlich auch verkaufen, ne?

Also an Endkunden oder so, die wollen das alle haben.

Die Library, dass du einfach nur die Library verkaufst.

Ja, du musst dich natürlich schon.

Rechnen euch die Turnrate durch die

Daten der Kundenpipen, aber ja.

Ja, klar, das L-Service anzubieten, ist eine coole Idee.

Ja, vielen Dank, dass ihr wieder eingeschaltet habt, dass ihr zugehört habt, bleibt uns gewogen, hört uns nachts morgens mittags, abends, am Wochenende unter der Woche beim Schwimmen gehen.

Ja, macht einen schönen Tag, schöne Zeit.

Bis dann.

Tschüss.

Tschüss.

Ja, spät.

Ja.

Tschüss.

Ja, diesmal lasst uns nicht so viel Zeit.

Ja.

Bis dann.

Tschüss.